Geschäftsprozessmodellierung mit BPMN 2.0: Business Process Model and Notation 9783486721218, 9783486718058

Citation preview

Geschäftsprozessmodellierung mit BPMN 2.0 Business Process Model and Notation von

Prof. Dr. Jochen Göpfert Dipl. oec. Heidi Lindenbach

Oldenbourg Verlag München

Wichtiger Hinweis für den Benutzer Der Verlag und die Autoren haben alle Sorgfalt walten lassen, um vollständige und akkurate Informationen in diesem Buch zu publizieren. Autoren und Verlag übernehmen weder Garantie noch die juristische Verantwortung oder irgendeine Haftung für die Nutzung dieser Informationen, für deren Wirtschaftlichkeit oder fehlerfreie Funktion für einen bestimmten Zweck, auch nicht für die Verletzung von Patentrechten und anderen Rechten Dritter, die daraus resultieren könnten. Der Verlag und die Autoren übernehmen keine Gewähr dafür, dass die beschriebenen Verfahren, Programme usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigen deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Specifications referenced and quoted in this book copyright 2012 by Object Management Group, used with permission.

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © 2013 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0 www.oldenbourg-verlag.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Lektorat: Dr. Stefan Giesen Herstellung: Constanze Müller Einbandgestaltung: hauser lacour Gesamtherstellung: Grafik & Druck GmbH, München Dieses Papier ist alterungsbeständig nach DIN/ISO 9706. ISBN 978-3-486-71805-8 eISBN 978-3-486-72121-8

Vorwort Die Geschäftsprozessmodellierung mit BPMN dient der Beschreibung von Workflows in einem Unternehmen und dessen Zusammenarbeit mit Geschäftspartnern. Der Standard „Business Process Model and Notation“, Version 2.0, gilt zurzeit als State of the Art bei der Modellierung von Geschäftsprozessen und deren Automatisierung. Er hat sich weltweit in einem atemberaubenden Tempo verbreitet und ist in unzähligen Unternehmen fest etabliert. Die Vermittlung dieses Standards durch Erklärungen und anschauliche Beispiele ist ein wichtiges Ziel dieses Buches. Der BPMN-Standard hat seinen Durchbruch vor allem der Tatsache zu verdanken, dass BPMN als erste Beschreibungssprache für Geschäftsprozesse zwei Welten erfolgreich zusammenführt, die Welt der Fachabteilungen und die IT-Welt. Die Basis dafür bilden die zwei Ebenen, eine graphische Modellierungssprache für Betriebswirte, Wirtschaftsingenieure und Wirtschaftsinformatiker sowie eine formale Prozess-Grammatik für Wirtschaftsinformatiker und Informatiker. Die formale Prozessbeschreibung bildet neben den im Standard enthaltenen Klassendiagrammen eine ausgezeichnete Grundlage für die Entwicklung von Process Engines und diese wiederum für die teilweise oder vollständige Automatisierung von Geschäftsprozessen. Letzteres ist nicht Gegenstand dieses Buches. Allein schon die graphische Prozessbeschreibung führt zu einem tieferen Prozessverständnis bei allen Beteiligten und für mehr Präzision, was sich nachweislich in einer höheren Prozessqualität niederschlägt. Das moderne Qualitätsmanagement von Unternehmen verlangt von seinen Business Analysten, die meist in Organisationsabteilungen tätig sind, eine übersichtliche und allgemeinverständliche Strukturierung der Unternehmensprozesse. BPMN ist ein ausgezeichneter methodischer Ansatz, diesem Anspruch gerecht zu werden. Das vorliegende Buch ist ein Lehr- und Übungsbuch für Studentinnen und Studenten sowie für Praktiker, die die Prozessmodellierung bis zur Anwendungsreife treiben wollen. In vielen Curricula von Hochschulen und Universitäten gibt es Module zum Business Process Management. Das Buch enthält weit über einhundert Beispiel-Prozess-Definitionen, die sowohl für Dozenten als auch Studenten recht nützlich sein können, weil sie auch schwierige Modellierungsprobleme behandeln. Das betrifft vor allem auch die Vielfalt von Ereignistypen, illustriert mit sinnfälligen Beispielen. Neben dem Studium kann das Buch wegen seiner Anschaulichkeit und der vielen Beispiele aus der Praxis auch sehr gut für Praxisseminare eingesetzt werden, denn die BeispielProzess-Definitionen stammen weitestgehend aus dem realen Wirtschaftsleben. Aus didaktischen Gründen wurden sie vereinfacht. Alle Prozess-Definitionen liegen nicht nur im Graphikformat, sondern auch im XML-Format vor. Sie sind alle gegen die formale ProzessGrammatik von BPMN 2.0 geprüft. Trotzdem sind insbesondere semantische Fehler nicht ganz auszuschließen. Kritische Hinweise von Lesern sind jederzeit willkommen. Das Buch enthält vielfältige Übungsaufgaben von unterschiedlichem Schwierigkeitsgrad. Durch die Übungen erwirbt der Leser auf dem Gebiet des Business Process Managements

VI

Vorwort

(BPM) praktische Handlungskompetenz. Etwa einhundert Kontrollfragen ermöglichen es dem Leser, sein Wissen zu testen und zu festigen. Wir wünschen dem Leser beim Denken, Lernen und Üben viel Erfolg. Nicht zuletzt bedanken wir uns bei den BPMN-Tool-Herstellern BizAgi und Visual Paradigm für die wertvolle Unterstützung des Buchprojekts. Zum Zweck der Einheitlichkeit sind alle Diagramme im Buch mit Agilian von Visual Paradigm modelliert worden.

Inhaltsverzeichnis Vorwort

V

1

Einführung

1

1.1

Definition ................................................................................................................... 1

1.2

Nutzenpotentiale von BPMN ..................................................................................... 3

1.3

Eine erste Prozess-Definition ..................................................................................... 4

1.4

Pools und Lanes ......................................................................................................... 6

1.5

Aktivitäten und Ereignisse ......................................................................................... 7

1.6

Gateways.................................................................................................................... 7

1.7

Verbindende Objekte ................................................................................................. 8

1.8

Artefakte .................................................................................................................... 9

1.9

Prozessdarstellung ..................................................................................................... 9

1.10

Das Marken-Konzept ............................................................................................... 11

2

Aktivitäten

2.1

Aufgaben.................................................................................................................. 13

2.2 2.2.1 2.2.2 2.2.3

Markierung von Aufgaben ....................................................................................... 17 Schleife .................................................................................................................... 17 Mehrfach-Instanz-Aufgabe ...................................................................................... 18 Kompensation .......................................................................................................... 20

2.3

Globale Aufgabe und Aufruf-Aktivität .................................................................... 21

2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6 2.4.7 2.4.8

Unterprozesse .......................................................................................................... 22 Unterprozesse allgemein .......................................................................................... 23 Schleifen-Unterprozess ............................................................................................ 25 Mehrfach-Instanz-Unterprozess ............................................................................... 25 Ad-hoc Unterprozess ............................................................................................... 26 Kompensations-Unterprozess .................................................................................. 27 Transaktions-Unterprozess ...................................................................................... 28 Globaler Unterprozess ............................................................................................. 30 Ereignis-Unterprozess .............................................................................................. 31

13

VIII

Inhaltsverzeichnis

3

Gateways

35

3.1

Exklusives Gateway .................................................................................................35

3.2

Paralleles Gateway ...................................................................................................38

3.3

Inklusives Gateway...................................................................................................40

3.4

Komplexes Gateway .................................................................................................41

3.5

Ereignisbasiertes Gateway ........................................................................................42

3.6

Prozessmodellierung ohne Gateways .......................................................................47

4

Ereignisse

4.1 4.1.1 4.1.2 4.1.3

Systematik und Überblick.........................................................................................51 Gliederung der Ereignisse nach Ergebnissen und Auslösern ....................................51 Gliederung der Ereignisse nach ihrer zeitlichen Anordnung im Prozess ..................54 Tiefergehende Gliederung von Ereignissen ..............................................................55

4.2 4.2.1 4.2.2 4.2.3 4.2.4

Startereignisse...........................................................................................................57 Startereignisse auf oberster Prozessebene ................................................................58 Warum es bestimmte Top-Level-Startereignisse nicht gibt ......................................63 Abbrechende und nicht abbrechende Startereignisse für Ereignis-Unterprozesse ....64 Warum es bestimmte Startereignisse bei den Ereignis-Unterprozessen nicht gibt ...81

4.3 4.3.1 4.3.2 4.3.3 4.3.4

Zwischenereignisse...................................................................................................82 Sendende und empfangende nicht angeheftete Zwischenereignisse .........................83 Warum es bestimmte nicht angeheftete Zwischenereignisse nicht gibt....................94 Angeheftete abbrechende und nicht abbrechende Zwischenereignisse ....................95 Warum es bestimmte angeheftete Zwischenereignisse nicht gibt...........................107

4.4

Endereignisse ..........................................................................................................108

5

Artefakte, Datenobjekte und Datenspeicher

5.1 5.1.1 5.1.2 5.1.3

Artefakte .................................................................................................................117 Anmerkungen .........................................................................................................117 Assoziationen .........................................................................................................118 Gruppierungen ........................................................................................................118

5.2

Datenobjekte und Datenspeicher ............................................................................119

6

Kollaboration, Choreographie und Konversation

6.1

Kollaboration ..........................................................................................................127

6.2 6.2.1 6.2.2 6.2.3 6.2.4

Choreographie ........................................................................................................131 Möglichkeiten der Verwendung und Darstellung ...................................................132 In eine Kollaboration eingebettete Choreographie .................................................134 Choreographie-Unterprozess ..................................................................................135 Globale Choreographie-Aufgaben und -Unterprozesse ..........................................135

6.3

Konversation...........................................................................................................135

51

117

127

Inhaltsverzeichnis

IX

7

Übungsaufgaben und Kontrollfragen

139

7.1

Übungsaufgaben .................................................................................................... 139

7.2

Beispiel-Lösungen ................................................................................................. 156

7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7

Kontrollfragen mit Antworten ............................................................................... 172 Zu Kapitel 1 Einführung ........................................................................................ 172 Zu Kapitel 2 Aufgaben .......................................................................................... 176 Zu Kapitel 3 Gateways .......................................................................................... 183 Zu Kapitel 4 Ereignisse.......................................................................................... 184 Zu Kapitel 5 Artefakte, Datenobjekte und Datenspeicher ..................................... 187 Zu Kapitel 6 Kollaborationen, Konversationen, Choreographien .......................... 188 Zum Marken-Konzept............................................................................................ 189

Fachbegriffe Englisch-Deutsch

195

Literatur

199

Index

201

1

Einführung

Das erste Kapitel führt in die Grundkonzepte von BPMN 2.0 [3] ein. Es behandelt die Basics von Aktivitäten, Gateways und Ereignissen, von Teilnehmern an einer Kollaboration sowie dem Nachrichtenfluss zwischen diesen Teilnehmern. Für das Verständnis der Ablauflogik von BPMN 2.0 erfolgt eine Einführung in das Marken-Konzept. Es sei angemerkt, dass diverse Konzepte auf bekannte Workflow Patterns zurückgehen. Eine ausführliche Beschreibung dieser Patterns findet der interessierte Leser z. B. in BPMN 2.0 Distilled [2], S. 179 ff., oder bei Sexana „Workflow Patterns with BPMN 2.0“ in [11], S. 93 ff. Wer auf kurzweilige Art etwas über die Basics von BPMN 2.0 erfahren möchte, dem sei das Buch „The Process“ von Großkopf et al [5] empfohlen.

1.1

Definition

Ein Geschäftsprozess besteht aus einer Folge von koordinierten Aktivitäten. Diese sind entweder Aufgaben oder Unterprozesse. Aufgaben sind immer atomar, d. h. sie werden im Rahmen einer Prozess-Definition nicht weiter detailliert. Der Ablauf von Geschäftsprozessen kann verzweigen und er kann wieder zusammengeführt werden. Ein Geschäftsprozess benötigt Zeit, er verbraucht Ressourcen und verursacht Kosten. Er hat einen definierten Beginn und ein definiertes Ende. Der Ablauf eines Geschäftsprozesses wird in der Regel durch Ereignisse beeinflusst. Geschäftsprozesse sind planbar und steuerbar. Die Planung erfolgt vor dem Prozessablauf, die Steuerung während des Prozessablaufs. Planbar heißt, Geschäftsprozesse können vorausgedacht werden. Steuerbar heißt, bei Abweichungen von Plan- und Ist-Verlauf kann der Ist-Verlauf mittels diverser Steuerungsmaßnahmen an den Plan-Verlauf angenähert werden. Für Geschäftsprozesse als Ganzes und für Teilprozesse gibt es Verantwortliche und beteiligte Organisationseinheiten. Typische Ziele von Geschäftsprozessen sind Kunden- und Mitarbeiterzufriedenheit, Einhaltung von Terminen, hohe Ressourcenauslastung, niedrige Kosten etc. In Anlehnung an das Capability Maturity Model unterscheiden wir fünf Reifegrade von Geschäftsprozessen (CMM, vgl. z. B. http://de.wikipedia.org/wiki/Capability_Maturit_Model). Die Reifegrade werden auch CMM-Levels genannt.

2

1 Einführung

Tab. 1.1: Reifegrade von Geschäftsprozessen

1 initial (im Anfangsstadium)

2 repeatable (wiederholbar)

3 defined (definiert)

4 managed (beherrscht)

5 optimizing (optimierend)

Die Geschäftsprozesse sind gar nicht, unvollständig oder konfus dokumentiert. Sie erfolgen mehr oder weniger sporadisch und chaotisch. Der Erfolg ist von individuellen Anstrengungen abhängig. Zeit, Kosten und Qualität sind nicht steuerbar. Nachvollziehbare, aber unvollständige Aufzeichnungen minderer Qualität sind vorhanden (quick and dirty). Mit einiger Anstrengung kann man das gewünschte Ergebnis wiederholt erzielen. Die Geschäftsprozesse sind dokumentiert, standardisiert und aufeinander abgestimmt, d. h. integriert. Die Prozessgüte wird mit einem Kennzahlensystem überwacht, die Ergebnisse werden ausgewertet. Zeit, Kosten und Qualität sind gut steuerbar. Es wird ein kontinuierlicher Verbesserungsprozess durchgeführt mit innovativen Ideen von unmittelbaren Prozessbeteiligten.

Dem CMM wird hier bewusst der Vorzug gegeben vor dem CMMI (Capability Maturity Model Integration – siehe z. B. [7] Kneuper 2003), weil CMM etwas allgemeingültiger ist. CMMI zielt ausschließlich auf den Software-Entwicklungsprozess. Der folgende Cartoon des Karikaturisten Heinz Jankofsky zeigt eindrucksvoll, wie verwirrend Geschäftsprozesse sein können, wenn sie schwach strukturiert sind.

Abb. 1.1:

Geschäftsprozessmodellierung ohne „Model and Notation“

BPMN – Business Process Model and Notation – ist der Standard für graphische und XMLbasierte Geschäftsprozessmodellierung [3]. Mit seinen Symbolen und Elementen wird eine einheitliche, standardisierte Sprache, Darstellung und Analyse der Prozesse möglich. XML steht für Extensible Markup Language. Man muss immer zwischen der Definition eines Geschäftsprozesses, z. B. in Form eines BPMN-Diagramms, und der Erzeugung und Ausführung einer Prozess-Instanz unterscheiden. Eine Prozess-Instanz ist ein ausführbarer Prozess,

1.2 Nutzenpotentiale von BPMN

3

der entsprechend der Prozess-Definition erzeugt wird. Es kann viele Prozess-Instanzen bezüglich einer Prozess-Definition geben. Nehmen wir an, eine Prozess-Definition lege fest, dass ein Prozess infolge des Empfangs eines Kundenauftrags gestartet wird. Dann bewirkt jede Ankunft eines Kundenauftrags die Erzeugung und Ausführung einer Prozess-Instanz. Die Ausführung einer Prozess-Instanz wird im Fall der Prozessautomatisierung durch eine Business Process Management Engine (BPME) unterstützt, im Weiteren kurz Process Engine genannt. Letzteres ist eine Software, die BPMN interpretieren und ausführen kann. Ausführen heißt zum Beispiel, eine ServiceAufgabe abzuarbeiten durch Aufruf eines Web Services. Im Text wird der Einfachheit wegen meist nur der Begriff „Prozess“ verwendet, wobei es sich aus dem Kontext ergibt, ob es um die Prozess-Definition oder um eine Prozess-Instanz geht. Die für Standards im Softwarebereich, z. B. UML, bekannte Object Management Group (OMG) hat erstmals in 2006 BPMN 1.0 als Standard angenommen. Diese Tatsache veranlasste bereits viele Unternehmen, auf BPMN als Modellierungsstandard umzusteigen. Die Spezifikation für die Version 2.0 mit grundlegenden Neuerungen wurde in 2010 verabschiedet und im Januar 2011 veröffentlicht. BPMN hat eine sehr reichhaltige, gleichzeitig aber auch präzise Semantik. Diese ist in XML-Schemen und in der Standardbeschreibung (http://www.omg.org/spec/BPMN/2.0) definiert.

1.2

Nutzenpotentiale von BPMN

In Abhängigkeit von der Situation, den Ansprüchen und Zielen der einzelnen Unternehmen ergeben sich vielfältige Nutzenpotenziale durch die Anwendung von BPMN: 

Verständliche Definition und Dokumentation von Prozessen für die tägliche Anwendung und zur Orientierung von Managern und Mitarbeitern.  Die Standardisierung des Modells und der Notation stellen weitgehend sicher, dass alle Prozessbeteiligten eine gegebene Prozessdefinition gleich interpretieren.  Verbesserung der Zusammenarbeit zwischen Fachabteilung und IT-Dienstleister durch eine anschauliche graphische Prozessmodellierung einerseits und eine präzise ProzessDarstellung entsprechend einer Prozess-Grammatik andererseits.  Steigerung der Effizienz durch Vermeidung von Mehrfach-Arbeit und Definition klarer Zuständigkeiten und Abläufe.  Optimierung von bestehenden Prozessen, ggf. unter IT-Einsatz zum Zweck der (Teil-) Automatisierung von Prozessen.  Erfüllung von Anforderungen des Qualitätsmanagements im Rahmen von Zertifizierungen.  Möglichkeit der präzisen Definition von Kollaborationen mit Geschäftspartnern weltweit. Entscheidend für eine erfolgreiche Umsetzung ist immer der konkrete Nutzen, der sich direkt für Unternehmen oder Institutionen und deren Mitarbeiter ableitet. Nur so kann eine Akzeptanz für Neues gesichert und das „Leben“ von Prozessen gefördert werden. Bedeutende Global Player der IT-Branche haben Ihre BPMN-Lösung zu einer strategischen Plattform ausgebaut – siehe z. B. Java Magazin [6]. Das unterstreicht die Relevanz des Busi-

4

1 Einführung

ness Process Managements (BPM) im Allgemeinen und von BPMN 2.0 im Besonderen als substantiellen Beitrag zum Unternehmenserfolg.

1.3

Eine erste Prozess-Definition

Einfache BPMN-Diagramme sind der beste Weg, um BPMN kennen und verstehen zu lernen. Abb. 1.2 zeigt einen bekannten Ablauf, nämlich die Terminvereinbarung in einer Zahnarztpraxis, denn auch Arztpraxen haben im Rahmen des Qualitätsmanagements ihre Prozesse zu dokumentieren. Das Diagramm zeigt zwei Teilnehmer an einer Kollaboration, einen Kunden und eine Zahnarztpraxis. Zwischen beiden ist der Austausch von Informationen durch gestrichelte Pfeile dargestellt. In der Zahnarztpraxis gibt es zwei Partnerrollen, den Zahnarzthelfer bzw. die Zahnarzthelferin und den Zahnarzt bzw. die Zahnärztin.

Abb. 1.2:

Terminvergabe in einer Zahnarztpraxis

Auch ohne Kenntnis von BPMN ist diese Prozess-Definition für jeden ein stückweit intuitiv verständlich. Eine Patientin bzw. ein Patient (im Weiteren zusammengefasst als Patient bezeichnet) nimmt zur Zahnarztpraxis Kontakt auf und fragt nach einem Termin. Die mittels eines Nachrichtenflusses eingehende Terminanfrage wird im kreisförmigen Start-Symbol als Briefumschlag dargestellt. Die Terminanfrage bewirkt, dass der Prozess in der Zahnarztpraxis gestartet wird. Um die Dauer abzuschätzen, fragt in der Regel eine Zahnarzthelferin nach der Art der gewünschten Behandlung und prüft danach den Terminkalender. Ist keine Rücksprache mit der Ärztin bzw. dem Arzt (im Weiteren zusammengefasst als Arzt bezeichnet) erforderlich, wird der Termin von der Zahnarzthelferin vergeben. Es kann aber auch sein, dass sie den behandelnden Arzt wegen spezieller Anforderungen, z. B. bei einer Kieferopera-

1.3 Eine erste Prozess-Definition

5

tion, einbeziehen muss und erst danach den Termin unter Berücksichtigung von eventuellen terminlichen Restriktionen von Patientenseite vergibt. Der Patient erhält noch eine abschließende Information und der Prozess ist zu Ende. Die Reihenfolge der Aktivitäten ist durch die Pfeile, in der BPMN-Terminologie Sequenzflüsse genannt, festgelegt. Die Verzweigung und die Zusammenführung der alternativen Pfade werden durch Gateways realisiert, die als Rhomben dargestellt sind. Das kreisförmige Ende-Symbol deutet mit dem ausgefüllten Briefumschlag an, dass eine Information, hier ein Termin, an den Patienten vergeben worden ist. Die Aktivitäten, dargestellt durch Rechtecke mit abgerundeten Ecken, zeigen durch ein Symbol an, um welchen Aufgabentyp es sich handelt, hier um Manuelle und um BenutzerAufgaben. Natürlich könnte man den Dialog zwischen dem Patienten und der Arztpraxis detaillierter darstellen. Die BPMN-Elemente werden insgesamt in fünf Kategorien gemäß Abb. 1.3 eingeteilt:

Abb. 1.3:

Prozess-Elemente

Die BPMN-Semantik ist u. a. in XML-Schemen definiert. Darunter versteht man eine Grammatik zur Definition von Geschäftsprozessen. Die Ausführungen in der BPMNSpezifikation (http://www.omg.org/spec/BPMN/2.0) erklären und ergänzen die formale Grammatik. So werden z. B. die Ablaufregeln allesamt nur verbal definiert. Eine Möglichkeit der formalen Beschreibung der Ablaufregeln findet der interessierte Leser z. B. in Dijkman/Van Gorp, BPMN 2.0 Execution Semantics Formalized as Graph Rewrite Rules, in Mendling et al (Eds.) [8], S. 16 ff. Abb. 1.3 gibt eine Übersicht über die wichtigsten Prozess-Elemente, welche in den folgenden Kapiteln ausführlich behandelt werden.

6

1 Einführung

1.4

Pools und Lanes

Ein Prozess wird häufig für eine (juristisch) selbständige Geschäftseinheit (Business Unit) oder Organisation modelliert. Eine solche Geschäftseinheit kann Teilnehmer (participant) an einer Kollaboration (Zusammenarbeit) zwischen zwei oder mehreren Geschäftspartnern sein. Den Terminus technicus „Teilnehmer“ kann man durchaus mit „Beteiligter“ übersetzen. Der Fachbegriff „Kollaboration“ kommt dem dt. Begriff „Kooperation“ sehr nahe, wenn man von der Mehrdeutigkeit des Begriffs im Englischen absieht und darunter Zusammenarbeit versteht. Der Begriff „Kollaboration“ hat im Deutschen einen negativen Beigeschmack im Sinne einer Zusammenarbeit mit Okkupationsbehörden. Deshalb bevorzugen wir eigentlich den Begriff „Kooperation“. Da sich der Begriff „Kollaboration“ aber als Fachbegriff im Sinne von Zusammenarbeit in der BPMN Community verbreitet hat, verwenden wir ihn trotz unserer Bedenken. Jeder Teilnehmer ist für seinen eigenen Prozess und komplementär für die Kommunikation in der Kollaboration verantwortlich. Der Pool, d. h. ein Rechteck, dient als grafische Darstellung einer selbständigen Business Unit bzw. eines Teilnehmers (Abb. 1.4) an einer Kollaboration. Das kann z. B. ein Wirtschaftsunternehmen oder wie in Abb. 1.2 eine Zahnarztpraxis sein. In Abb. 1.2 und Abb. 1.4 ist der Pool in zwei Lanes (lanes), d. h. Schwimmbahnen, unterteilt. Diese können untergeordnete Organisationseinheiten, spezifische Partnerrollen (z. B. Vertrieb, Projektleitung, Beschaffung) oder Komponenten eines Systems sein, und sie zeigen, für welche Aktivitäten sie verantwortlich sind. Der Pool ist den Lanes übergeordnet und enthält die Lanes. Lanes können in Sub-Lanes unterteilt werden. Diese wiederum in SubSub-Lanes usw.

Abb. 1.4:

Ein Pool für eine Business Unit, unterteilt in zwei Lanes (Schwimmbahnen)

Beim Anlegen von Lanes sollten zusammengefasst folgende Punkte beachtet werden:    

Lanes können beliebig beschriftet werden und stellen häufig Abteilungen (z. B. Vertrieb, Produktion, Personal), einzelne Stellen in der Abteilung (z. B. Sachbearbeiter Vertrieb, Sachbearbeiter Personal) oder spezifische Rollen (wie Teamleiter) dar. Lanes können zu Detailierungszwecken in Sub-Lanes aufgeteilt werden. Aktivitäten, Gateways und Ereignisse dürfen nur innerhalb einer Lane und nicht Laneübergreifend gezeichnet werden. Bei gleichen Aufgaben, die in zwei oder in mehreren Lanes enthalten sind, modelliert man die Aufgabe bei jedem Verantwortlichen einzeln und fasst sie durch entsprechende

1.5 Aktivitäten und Ereignisse

7

Umrahmung zu einer Gruppe zusammen, z. B. wenn ein Arbeitszeugnis gemeinsam durch die Personal- und die Fachabteilung unterzeichnet werden muss.  Ein Sequenzfluss kann die Lane-Grenzen überschreiten. Es besteht mit BPMN die Möglichkeit, im Rahmen einer Kollaboration das Zusammenwirken mehrerer Teilnehmer zu modellieren. Das wird in Kapitel 6 beschrieben. Eine umfangreiche wissenschaftliche Untersuchung von BPMN durch Recker [9] und Recker et al [10] hat Folgendes ergeben: „BPMN users will have difficulty differentiating between Lane and Pool construct use for the graphical articulation of real world objects in process models.“ Vgl. z. B. [9], S. 53. Dieser Aussage liegt eine repräsentative wissenschaftliche Fragebogenauswertung zugrunde. Deshalb ist es notwendig, den Unterschied zwischen Pools und Lanes präzise herauszuarbeiten, was im Kapitel 6 dieses Buches geschieht. Wer sich tiefergehend mit den Problemen insbesondere der Praxiseinführung von BPMN beschäftigen möchte, dem sei das Praxishandbuch BPMN 2.0 von Freund/Rücker [4] empfohlen.

1.5

Aktivitäten und Ereignisse

Ein Prozess startet und endet in der Regel mit einem Ereignis (Startereignis bzw. Endereignis). BPMN schreibt nicht zwingend vor, dass Start-und Endereignisse zu modellieren sind. Es ist aber erstens guter Stil und zweitens kann man feststellen, wo ein Prozess beginnt, wodurch er ausgelöst wird und wo er zu Ende ist. Ereignisse werden durch einen Kreis dargestellt. Startereignisse sind durch eine schmale nicht unterbrochene Kreislinie , Endereignisse durch eine dicke durchgehende Kreislinie gekennzeichnet. In Abb. 1.2 handelt es sich um ein Nachrichten empfangendes Startereignis und um ein Nachrichten sendendes Endereignis. Daneben gibt es eine Vielzahl von weiteren Start-, Zwischen- und Endereignissen, die in Kapitel 4 ausführlich behandelt werden. Der Kern eines Prozesses sind die Aktivitäten (activities), denn da sollte etwas Nützliches getan werden. Unter dem Oberbegriff „Aktivitäten“ sind Aufgaben, Unterprozesse und Aufruf-Aktivitäten zu verstehen. In der Einführung konzentrieren wir uns zunächst auf die Aufgaben (Tätigkeiten), die verrichtet werden müssen. Man beschriftet sie am sinnvollsten mit einer „Objekt+Verb“-Verbindung (z. B. „Terminkalender prüfen“). Die Aktivitäten werden als Rechteck mit abgerundeten Ecken dargestellt . Der Charakter einer Aufgabe kann durch verschiedene Aufgabentypen näher spezifiziert werden. In Abb. 1.2 ist die Aktivität „Termin vergeben“ z. B. als Benutzer-Aktivität gekennzeichnet. Hier werden Eingaben des Benutzers in einen elektronischen Terminkalender erwartet.

1.6

Gateways

Gateways werden zur Kontrolle bzw. Steuerung des Prozessablaufs eingesetzt. Man kann sich ein Gateway als einen Tor-Mechanismus vorstellen, der bestimmt, auf welchen Pfaden ein Prozess fortgesetzt wird. Das Zeichen dafür ist eine Raute

. In Abb. 1.2 handelt es

8

1 Einführung

sich um zwei exklusive Gateways (exclusive gateways). Exklusiv bedeutet, dass die ausgehenden Pfade alternativ gewählt werden müssen. Nachdem der Terminkalender der Praxis geprüft wurde, kann nur genau ein (exklusiver) Zweig gewählt werden: Entweder die Terminvergabe ist sofort möglich oder der Termin muss erst noch mit dem Vorgesetzten abgestimmt werden. Im nachfolgenden Gateway werden die alternativen Pfade wieder zusammengeführt, nachdem genau eine der beiden alternativen Aufgaben ausgeführt wurde.

1.7

Verbindende Objekte

In welcher Reihenfolge (sequence) die vorgenannten Elemente durchlaufen werden, wird durch Folgeflüsse bzw. Sequenzflüsse (sequence flows) dargestellt. Es handelt sich hierbei um einen durchgängigen Verbindungspfeil mit „ausgefüllter“ Spitze. Diese können entsprechend Abb. 1.2 jedoch nur innerhalb eines Pools, auch Lane-übergreifend, verwendet werden. Jeder Sequenzfluss hat genau eine Quelle und genau ein Ziel. Der Austausch zwischen zwei Pools erfolgt entsprechend Abb. 1.5 mit Nachrichtenflüssen (message flows), welche durch einen „gestrichelten“ Verbindungspfeil mit leerer Spitze gekennzeichnet sind. Ein kleiner Kreis symbolisiert das „Andocken“ an Pools, Aufgaben und Nachrichtenereignisse.

Abb. 1.5:

Darstellung von Sequenz- und Nachrichtenflüssen

Bei der Modellierung von Nachrichtenflüssen sollten folgende Regeln beachtet werden: 



Nachrichtenflüsse können mit sendenden (throwing) oder empfangenden (catching) Nachrichten-Ereignissen verbunden werden, d. h. Nachrichtenflüsse können nur mit Ereignissen vom Typ „Nachricht“ (siehe Kapitel 4.1) und sollten nur mit Sende- und Empfangsaufgaben (siehe Kapitel 2.1) verbunden werden. Nachrichtenflüsse dürfen nicht in ein Nachrichten-Ereignis hinein- und gleichzeitig wieder herausführen, da jedes Nachrichten-Ereignis entweder sendend oder empfangend ist, aber nicht gleichzeitig sendend und empfangend.

1.8 Artefakte   

9

Nachrichtenflüsse dürfen nicht mit Gateways verbunden werden, da Gateways den Prozessablauf regeln und weder in der Lage sind, Nachrichten zu senden, noch zu empfangen. Nachrichtenflüsse haben genau einen Anfang (kleiner runder Kreis) und immer genau ein Ende (Pfeilspitze). Nachrichtenflüsse müssen die Poolgrenzen überschreiten und dürfen nicht nur innerhalb eines Pools verlaufen.

1.8

Artefakte

Artefakte (Am. artifacts, Engl. artefacts) ergänzen die Prozessdefinition um zusätzliche Informationen, die keinen direkten Einfluss auf den Prozess haben. Wörtlich könnte man unter Artefakt etwas vom Menschen zu einem Diagramm geschickt Hinzugefügtes verstehen. Vermutlich gibt es keine direkte Übersetzung mit einem einzigen dt. Begriff. Deshalb wollen wir bei dem Begriff „Artefakt“ bleiben. In Abb. 1.2 handelt es sich um eine „Gedächtnisstütze“. Die Anmerkung – dargestellt in einer geöffneten eckigen Klammer – besagt, dass der vergebene Termin noch im Terminplaner vermerkt werden muss. Anmerkungen werden über Assoziationen (associations) – dargestellt als „gepunktete“ Linien – an das jeweilige Flussobjekt angebunden

1.9

.

Prozessdarstellung

Ein Pool kann horizontal oder vertikal angeordnet werden (Abb. 1.6 und Abb. 1.7), wobei die horizontale Modellierung meist bevorzugt wird. Der farblichen Gestaltung sind je nach Tool kaum Grenzen gesetzt, und es gibt oft verschiedene Möglichkeiten, einzelne Prozesse zu modellieren. Mit wachsender Erfahrung bildet sich ein eigener Modellierungsstil heraus, den man zur Wahrung der Kontinuität und schnelleren Verständlichkeit durchgängig anwenden sollte. Eine ausführliche Beschreibung erprobter und bewährter Stilregeln findet der interessierte Leser bei Silver in [12]. Wichtige Stilhinweise finden sich aber auch an passender Stelle im vorliegenden Buch.

Abb. 1.6:

Pool in horizontaler Ausrichtung

10

Abb. 1.7:

1 Einführung

Pool in vertikaler Ausrichtung

Prozesse sollten auch bei hoher Komplexität immer so gestaltet sein, dass sie für den Nutzer überschaubar bleiben. Bei komplexen Workflows kann man auf einem Bildschirm leicht die Orientierung verlieren, besonders wenn man sich gezoomte Ausschnitte ansieht. Hier bietet sich das Arbeiten mit Unterprozessen zum separaten Öffnen als ideales hierarchisches Strukturierungsmittel an. Auch Hervorhebungen mit Farben und Gruppierungen verhelfen oft zu mehr Übersicht.

Abb. 1.8:

Komprimierte Darstellung durch Verwendung von Unterprozessen

1.10 Das Marken-Konzept

1.10

11

Das Marken-Konzept

In der Praxis kommen häufig komplexe Prozessmodelle (Definitionen von Prozessen) vor. Das Marken-Konzept ist ein theoretisches Konzept, das eine präzise Formulierung der Ablaufregeln für Gateways und ereignisgesteuerte Abläufe ermöglicht. Es trägt wegen seiner Anschaulichkeit dazu bei, sich den Prozessablauf besser vorstellen zu können. Beim Erzeugen einer Prozess-Instanz, d. h. eines ausführbaren Prozesses, wird immer wenigstens eine Marke generiert. Zum Beispiel erzeugt die Nachfrage nach einem Termin in der Zahnarztpraxis eine Instanz des Prozesses „Terminvergabe“. Immer wenn eine ProzessInstanz gebildet wird, dann werden im Startereignis so viele Marken (tokens) erzeugt, wie es ausgehende Sequenzflüsse gibt, in der Regel eine Marke. Abb. 1.9 zeigt fünfzehn Momentaufnahmen des Markenflusses aus Abb. 1.2. Er folgt bestimmten Regeln, die in den einzelnen Kapiteln noch ausführlich behandelt und präziser gefasst werden. Die Momentaufnahme 1 zeigt die Marke, nachdem sie im Startereignis erzeugt wurde. Solange der von da ausgehende Sequenzfluss nicht verzweigt, ist ihr Weg allein durch den Sequenzfluss bestimmt – Momentaufnahmen 2 bis 7. Im verzweigenden Exklusiven Gateway wird in Abhängigkeit von einer Bedingung verzweigt. Die Bedingung lautet, ob eine Belegung, d. h. Terminvergabe, sofort möglich ist. Wenn ja, dann fließt die Marke zum zusammenführenden Exklusiven Gateway – Momentaufnahmen 8b und 11. Wenn die Bedingung nicht erfüllt ist, dann fließt die Marke zur Aufgabe „Termin abstimmen“, dann weiter zum zusammenführenden Exklusiven Gateway – Momentaufnahmen 8a bis 11. Danach gibt es keine Verzweigung mehr. Die Marke fließt deshalb entlang des Sequenzflusses – Momentaufnahmen 12 bis 15. Im Endereignis wird die Marke schließlich konsumiert. Eine Prozessinstanz, d. h. ein ausführbarer Prozess ist beendet, wenn alle zu Beginn oder im Verlauf des Prozesses erzeugten Marken konsumiert worden sind.

Abb. 1.9:

Das Marken-Konzept

12

1 Einführung

Zusammenfassung zu Kapitel 1  

  



Geschäftsprozesse laufen zwischen Geschäftspartnern ab (Business to Business oder kurz B2B). B2B-Geschäftsprozesse werden vor allem über ihren Nachrichtenaustausch definiert. Ein wichtiger Aspekt innerbetrieblicher Geschäftsprozesse sind ihre Arbeitsabläufe bzw. Workflows. Geschäftsprozesse benötigen Zeit, verbrauchen Ressourcen und verursachen Kosten. Deshalb ist ihre zielgerichtete Planung und Steuerung von herausragender Bedeutung. Geschäftsprozesse lassen sich u.a. nach dem Capability Maturity Model (CMM) beurteilen. Man unterscheidet fünf Level mit definierten Eigenschaften: Initial, Repeatable, Defined, Managed und Optimizing. Als Nutzenpotenziale der Geschäftsprozessmodellierung mit BPMN seien exemplarisch genannt: Standardisierung, verbesserte Schnittstelle zwischen Business und IT, klare Zuständigkeiten und Abläufe, Optimierung. Die elementaren Prozess-Elemente sind Flussobjekte (Aktivitäten, Gateways und Ereignisse), Verbindende Objekte (Nachrichtenfluss, Sequenzfluss, Datenassoziation, Assoziation), Daten (Datenobjekt, Daten-Input, Daten-Output, Datenspeicher) und Artefakte (Anmerkungen, Assoziationen, Gruppierungen) sowie Pools und Lanes. Für diverse Prozess-Elemente, insbesondere für Gateways, gibt es Ablaufregeln. Zur Erklärung dieser Regeln bietet sich das Marken- bzw. Token-Konzept an. Die Ablaufregeln können damit vor allem anschaulich und leicht verständlich beschrieben werden.

2

Aktivitäten

Das zweite Kapitel behandelt alle Typen von Aktivitäten. Dabei nehmen die detaillierte Behandlung der Vielfalt von Aufgaben und Unterprozessen sowie deren Sinn und Zweck einen breiten Raum ein.

2.1

Aufgaben

Unter dem Oberbegriff Aktivitäten werden Aufgaben, Aufruf-Aktivitäten und Unterprozesse verstanden. Zunächst beschäftigen wir uns mit den Aufgaben, die in unterschiedliche Typen unterteilt werden. Die nachfolgende Abb. 2.1 gibt einen Überblick und die Tab. 2.1 fasst die einzelnen Aufgabentypen und deren Bedeutung zusammen. Die marktgängigen Tools benutzen zum Teil noch unterschiedliche Symbole in der linken oder rechten oberen Ecke der Aufgabe, was jedoch seit der Einführung von BPMN 2.0 und den entsprechenden Versionsverbesserungen mehr und mehr vereinheitlicht wird.

Abb. 2.1:

Übersicht der unterschiedlichen Aufgabentypen

In der folgenden Tabelle sind die Aufgabentypen im Einzelnen beschrieben.

14

2 Aktivitäten

Tab. 2.1: Übersicht über die Aufgabentypen

Unspezifizierte Aufgabe (unspezified task)

Der Aufgabentyp wird nicht näher spezifiziert, d. h. es wird nicht festgelegt, ob es sich z. B. um eine Benutzer-Aufgabe (mit SoftwareUnterstützung) oder eine Manuelle Aufgabe (ohne SoftwareUnterstützung) handelt. Sobald man bei der Analyse von Geschäftsprozessen Klarheit über den Aufgaben-Typ gewonnen hat, sollte man die betrachtete Aufgabe näher spezifizieren, d. h. den genauen Typ festlegen.

Service-Aufgabe (service task)

Sie wird automatisch durch eine Software ausgeführt (im Normalfall Ausführung als Web-Service; beispielsweise könnte das ein Bezahlsystem-Web-Service sein). Sinn und Zweck einer Service-Aufgabe bestehen in Folgendem: – Wiederverwendung vorhandener Anwendungssoftware, – flexible Einbindung von Software in Geschäftsprozesse, – Nutzung einer einfachen standardisierten Schnittstelle, – Einbindung von Altsystemen (legacy systems), – hohe Qualität der Aufgabenerfüllung, – vergleichsweise geringe Kosten für die Ausführung der Aufgabe.

Skript-Aufgabe (script task)

Ein Modellierer definiert ein Skript (Folge von Anweisungen) in einer Sprache, die von einer speziellen Software interpretiert und ausgeführt werden kann. Der Interpreter wird von der Process Engine aufgerufen. Typische Skript-Sprachen sind in diesem Zusammenhang: – XSLT (XML Stylesheet Language for Transformations) – XSL-FO (XML Stylesheet Language – Formatting Objects) – XQuery (XML Query Language incl. Update Facility). Sinn und Zweck einer Skript-Aufgabe besteht z. B. darin, eine Rechnung im kryptischen XML-Format in das visuell gut lesbare PDFFormat oder in das zum Drucken geeignete Postscript-Format zu transformieren.

BenutzerAufgabe (user task)

Hier erfolgt die Aufgabenbearbeitung mit Software-Unterstützung oder im Zusammenspiel von Anwender, Anwendungssoftware und Process Engine, deren Task List Manager dem Benutzer eine Aufgabe oder eine Liste von abzuarbeitenden Aufgaben vorgibt. Die Bearbeitung kann im Dialog erfolgen. Am Schluss muss der Benutzer die Erledigung der Aufgabe bestätigen. Beispiele für eine Benutzeraufgabe sind das Ausfüllen eines HTML-Formulars für einen Kreditantrag, die Nutzung eines Projektmanagement-Tools u.v.a.m.

Manuelle Aufgabe (manuell task)

Sie wird ohne jegliche Software-Unterstützung durchgeführt, z. B. telefonische Terminabsprache in der Arztpraxis, Abspülen von Instrumenten im Rahmen der Desinfektionsvorganges, Ablage von Unterlagen in Aktenordnern, händisches Sortieren der Eingangspost usw.

2.1 Aufgaben

15

Sende- und EmpfangsAufgabe (send task and receive task)

Mit diesen Aufgabentypen werden Nachrichten über Nachrichtenflüsse an andere Teilnehmer versandt oder von diesen empfangen. Sie können als Alternative zum sendenden oder empfangenden Nachrichtenereignis modelliert werden. Wenn eine Nachricht verschickt bzw. empfangen wurde, dann ist die Aufgabe beendet.

Anwendung von Geschäftsregeln (business rule task)

Mit Geschäftsregeln wird bestimmt, unter welchen Bedingungen welche Aktionen auszuführen sind. Die Regeln werden außerhalb des Prozessmodells beschrieben (z. B. in Form einer Matrix oder einer Tabelle, die ausweist, wer einen Kreditantrag in welcher Höhe unter welchen Bedingungen genehmigen darf). Eine Geschäftsregel-Aufgabe veranlasst die Process Engine, eine Business Rule Engine aufzurufen. Diese Engine setzt diejenigen Regeln (rules) auf eine Agenda zur Ausführung, deren Prämissen erfüllt sind. Stehen mehrere Regeln gleichzeitig zur Ausführung, dann wird eine Konfliktlösungsstrategie benötigt, um diejenige Regel zu bestimmen, die als unmittelbar nächste ausgeführt wird. Regelstruktur: Wenn die Bedingungen (Prämissen) einer Regel erfüllt sind, dann führe bestimmte Aktionen aus. Beispiel: Wenn ein Paket bestimmte Abmessungen und ein bestimmtes Gewicht nicht überschreitet, dann setze den Preis auf einen bestimmten Wert. Sinn und Zweck einer Geschäftsregel-Aufgabe besteht darin, die Vorteile von Business Rule Management Systems (BRMS) und insbesondere Business Rule Engines zu nutzen. Ein wichtiger Aspekt ist die Trennung von Geschäftslogik und übriger Anwendungslogik, wodurch Ingenieure, Betriebswirte etc. in die Lage versetzt werden, die Geschäftslogik ohne Unterstützung von Informatikern zu formulieren und bei Bedarf zu ändern. Besonders sinnvoll ist die Anwendung von Geschäftsregel-Aufgaben, wenn die Geschäftsregeln einer gewissen Dynamik unterliegen.

Den Aktivitäten, insbesondere also auch den Aufgaben, können Ressourcen zugordnet werden. Sie haben einen Namen und sie können diverse Ressourcenparameter referenzieren. Eine Ressourcen-Rolle kann diverse Ressourcen zusammenfassen. Die Ressourcen-Rolle legt fest, welche Ressourcen den Prozess ausführen werden bzw. für ihn verantwortlich sind. Das kann eine einzelne Personalstelle, ein Gruppe, eine bestimmte Position in der Unternehmenshierarchie oder die Organisation selbst sein. Diese Ressourcen können einer Aktivität zugewiesen (assigned) werden. Das geschieht in Form eines Ressourcen-ZuweisungsAusdrucks (resource assignment expression). Die folgenden BPMN-Diagramme zeigen Beispiele für die Anwendung der o. g. Aufgabentypen.

16

2 Aktivitäten

Im Beispiel in Abb. 2.2 wird bei einem Maschinenbauer aus einer Lieferung von n Baugruppen zunächst manuell jede k-te Baugruppe (k und n natürliche Zahlen, k 93% ist, so wird der Ereignis-Unterprozess „Zufluss stoppen“ gestartet, ohne jedoch den umgebenden Unterprozess abzubrechen. Das bedeutet, dass die obere und die untere Schranke auch weiterhin beobachtet werden. Fällt der Füllstand unter 83%, wird der nicht abbrechende EreignisUnterprozess „Zufluss zuschalten“ gestartet. Die Ausführung der Ereignis-Unterprozesse kann sich vielfach wiederholen.

72

Abb. 4.22:

4 Ereignisse

Darstellung eines nicht abbrechenden Bedingungs-Ereignis-Unterprozesses

Abbrechendes und nicht abbrechendes Mehrfach-Startereignis für den Ereignis-Unterprozess Ein Mehrfach-Startereignis hat mehrere mögliche Auslöser. Diese werden dem Startereignis als Anmerkung hinzugefügt. In einem ausführbaren Prozess verweist das MehrfachStartereignis für den Ereignis-Unterprozess auf mehrere Ereignis-Definitionen. Es sei hier noch einmal daran erinnert, dass das Mehrfach-Startereignis durch mehrere Einzel-Ereignisse ersetzt werden kann, denn beim Mehrfach-Startereignis wird eine ProzessInstanz gebildet, immer wenn ein bestimmtes Ereignis aus einer vom Modellierer festgelegten Menge von möglichen Ereignissen eintritt. Das Mehrfach-Startereignis referenziert zu diesem Zweck eine Menge von Ereignis-Definitionen. Der Vorteil einer solchen Ersetzung besteht darin, dass die Nennung der Ereignis-Definitionen, die das multiple Ereignis auslösen, nicht nur in Form einer Anmerkung, also eines Kommentars, geschieht, sondern durch die Symbole der Ereignistrigger in den Startereignissen eindeutig definiert sind. Natürlich kann auch dort ein zusätzlicher Kommentar nicht schaden. Ein abbrechendes Mehrfach-Startereignis eines Ereignis-Unterprozesses tritt ein, wenn wenigstens ein Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert ist. Der umgebende Unterprozess wird abgebrochen.

4.2 Startereignisse

73

Wird im Beispiel in Abb. 4.23 eines der Ereignisse „Stromausfall“ oder „Defekt eingetreten“ registriert, dann wird der Ereignis-Unterprozess gestartet und der umgebende Prozess „Fahrzeug reinigen“ abgebrochen. Am Rande sei bemerkt, dass es noch einen dritten Grund gibt, den Unterprozess „Fahrzeug reinigen“ abzubrechen, nämlich wenn die Zeit abgelaufen ist, die man sich mit dem Einwurf einer Münze gekauft hat. Dieser Abbruch des Unterprozesses „Fahrzeug reinigen“ kann sich mehrfach wiederholen. Das Angeheftete Zeitereignis tritt aber nur dann ein, wenn die vorgegebene Zeit abgelaufen ist, bevor das Fahrzeug komplett gereinigt wurde. Sonst wird der Unterprozess über den regulären Fluss verlassen. Es folgt die Aufgabe „Fahrzeug aus Waschanlage fahren“. Wir unterstellen hier der Einfachheit wegen, dass der reguläre Fluss und nicht der Ausnahmefluss gewählt wird, wenn exakt zum Zeitpunkt der regulären Beendigung des Unterprozesses „Fahrzeug reinigen“ auch gerade die vorgegebene Zeit abgelaufen ist. Sonst müsste man nach dem Zeitereignis noch die Entscheidung einbauen, ob die Fahrzeugreinigung beendet ist. Wenn nein, dann müsste man wieder Geld einwerfen, wenn ja, dann müsste man das Fahrzeug aus der Anlage fahren.

Abb. 4.23:

Darstellung eines abbrechenden Mehrfach-Ereignis-Unterprozesses

Ein nicht abbrechendes Mehrfach-Startereignis eines Ereignis-Unterprozesses tritt ein, wenn wenigstens ein Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert ist. Der umgebende Unterprozess wird nicht abgebrochen. Für Kredit-Kunden einer Bank wird mit Blick auf Basel II und III (Basel II-Reformpaket des Basler Ausschusses der Bank für Internationalen Zahlungsausgleich für die bereits bestehende Bankenregulierung Basel II – vgl. http://de.wikipedia.org/wiki/Basel_III) das KundenRating periodisch überprüft.

74

4 Ereignisse

Abb. 4.24 zeigt, dass dafür die Kundenbonität zu analysieren ist, die Sicherheiten zu bewerten sind und letztlich das Rating zu aktualisieren sowie zu genehmigen ist. Der Unterprozess „Kundenbonität analysieren“ enthält einen Ereignis-Unterprozess, der gestartet wird, sobald wenigstens eines der einzelnen Ereignisse des Mehrfach-Startereignisses eingetreten ist (Bonitätsunterlagen älter als 1 Jahr oder Negativ-Merkmal in der Schufa [Schutzgemeinschaft für allgemeine Kreditsicherung – http://www.schufa.de/de/private/wissenswertes/faq/faq.jsp] oder Zahlungsschwierigkeiten). Dabei wird der umgebende Unterprozess nicht abgebrochen.

Abb. 4.24:

Beispiel für einen nicht abbrechenden Mehrfach-Ereignis-Unterprozess

Abbrechendes und nicht abbrechendes Parallel-Mehrfach-Startereignis für den Ereignis-Unterprozess Das Parallel-Mehrfach-Startereignis für den Ereignis-Unterprozess verweist auf mehrere Ereignis-Definitionen. In der graphischen Prozess-Darstellung geschieht das in Form einer Anmerkung. Ein abbrechendes Parallel-Mehrfach-Ereignis eines Ereignis-Unterprozesses tritt ein, wenn alle Auslöser einer vom Modellierer festgelegten Menge von Auslösern aktiviert sind. Der umgebende Unterprozess wird abgebrochen.

4.2 Startereignisse

75

Abb. 4.25 zeigt den Prozess einer auftragsbezogenen Herstellung von Maschinen in einer Fertigungsabteilung. Im Unterprozess „Montage durchführen“ werden aus Einzelteilen verschiedene Baugruppen montiert und zu Maschinen zusammengebaut. Danach erfolgt die Qualitätssicherung. Treten währenddessen die beiden Einzel-Ereignisse „Ausschussprozentsatz an Bauteilen > vereinbarter Prozentsatz“ und „Nachlieferungsfrist Bauteile > 1 Tag“ ein, d. h. zusammengefasst, es tritt das im Diagramm definierte Parallel-Mehrfach-Ereignis ein, dann wird der Ereignis-Unterprozess gestartet und die Versandabteilung über die Verzögerungen informiert. Gleichzeitig wird die Montage von Maschinen entsprechend des Fertigungsauftrags abgebrochen, weil nicht ausreichend viele Bauteile verfügbar sind. Es macht in diesem Fall Sinn, einen anderen Fertigungsauftrag vorzuziehen, z. B. weil sich eine Zulieferung unerwartet verzögert hat. Der Montagevorgang wird, wenn man es umgangssprachlich so formulieren will, unterbrochen. Streng genommen wird er aber abgebrochen und später unter besseren Voraussetzungen wieder gestartet. Es erscheint sicher merkwürdig, dass die Montage von Baugruppen und von Maschinen als Manuelle Aufgaben dargestellt sind. Das hat aber seine Richtigkeit, denn es sind im Sinne von BPMN weder Sende- oder Empfangsaufgaben, noch Service- oder Skript-Aufgaben, noch Benutzer- oder Geschäftsregelaufgaben. Es bliebe noch die Möglichkeit, die Aufgaben nicht näher zu spezifizieren, also keinen Aufgabentyp festzulegen.

Abb. 4.25:

Beispiel für einen Ereignis-Unterprozess mit dem abbrechenden Parallel-Mehrfach-Startereignis

Ein nicht abbrechendes Parallel-Mehrfach-Ereignis eines Ereignis-Unterprozesses tritt ein, wenn alle Auslöser einer vom Modellierer festgelegten Menge von Auslösern akti-

76

4 Ereignisse

viert sind. Diese Menge von Auslösern wird bestimmt, indem das Parallel-MehrfachEreignis eine vom Modellierer festgelegte Menge von Ereignis-Definitionen referenziert. Der umgebende Unterprozess wird nicht abgebrochen. Im Beispiel in Abb. 4.26 führt ein Pflegedienst Pflegeleistungen aus. Dazu gehört der Unterprozess „Körperpflege, Ernährung und Hauswirtschaft durchführen“. Treten während dieses Unterprozesses die Ereignisse „Zeit für Körperhygiene und Ernährung > 46 Minuten pro Tag“ und „Zeit für Hauswirtschaftshilfe > 46 Minuten pro Tag“ ein, dann wird der EreignisUnterprozess gestartet, was zum Stellen des Antrags auf Pflegestufe I führt. Die Pflege als umgebender Unterprozess wird deshalb nicht abgebrochen.

Abb. 4.26:

Beispiel für einen nicht abbrechenden Ereignis-Unterprozess mit dem Parallel-Mehrfach-Startereignis

Abbrechendes und nicht abbrechendes Eskalations-Startereignis für den Ereignis-Unterprozess Die Verwendung des Triggers Eskalation (escalation) erfolgt im Wesentlichen bei Problemen. Es erfolgt eine Meldung an den nächsthöheren Prozess und damit auch den nächsthöheren Prozess-Verantwortlichen, wo ein Reagieren erforderlich wird. Dies geschieht zum Beispiel, wenn ein Ziel nicht oder nicht in der verfügbaren Reaktionszeit erreicht wird. Ein abbrechendes Eskalations-Startereignis eines Ereignis-Unterprozesses tritt ein, wenn eine Eskalation erforderlich ist (Auslöser). Der umgebende Unterprozess wird abgebrochen.

4.2 Startereignisse

77

Das Beispiel in Abb. 4.27 zeigt den Prozess der Erstellung einer Abmahnung. Die Fachabteilung beauftragt die Personalabteilung mit der Erstellung einer Abmahnung. In der Personalabteilung wird in dem Unterprozess „Abmahnung erstellen“ der Sachverhalt juristisch gewürdigt und gleichzeitig die Personalakte geprüft. Treten bei einer der beiden Aufgaben Komplikationen auf, wird der Ereignis-Unterprozess infolge des sendenden EskalationsEndereignisses gestartet. Der umgebende Unterprozess wird – zum Beispiel wegen zeitlich zu später Reaktion auf ein Fehlverhalten des Mitarbeiters – abgebrochen. Im EreignisUnterprozess werden dann noch die beiden Aufgaben „Vorgang bewerten“ und „Vorgang archivieren“ ausgeführt. Dann wird die im Ereignis-Unterprozess befindliche Marke an den Oberprozess durchgereicht, wo sie entlang des Sequenzflusses weitergegeben wird.

Abb. 4.27:

Beispiel für einen abbrechenden Ereignis-Unterprozess mit dem Eskalations-Startereignis

Ein nicht abbrechendes Eskalations-Zwischenereignis eines Ereignis-Unterprozesses tritt ein, wenn eine Eskalation erforderlich ist (Auslöser). Der umgebende Unterprozess wird nicht abgebrochen.

78

4 Ereignisse

In Abb. 4.28 erhält der Anbieter ein Beschwerdeschreiben von einem Kunden. Im Unterprozess „Beschwerdebearbeitung“ wird die Beschwerde analysiert und beantwortet. Im Rahmen der Analyse wird offenbar, dass die Ursache der Beschwerde ein Systemfehler ist. Entsprechend wird der Eskalations-Ereignis-Unterprozess gestartet und der Systemfehler behoben. Der umgebende Unterprozess wird nicht abgebrochen.

Abb. 4.28:

Beispiel für ein nicht abbrechendes Eskalations-Startereignis für den Ereignis-Unterprozess

Die folgenden beiden Startereignisse für den Ereignis-Unterprozess brechen den umgebenden Prozess immer ab. Kompensation (compensation) Ein Kompensations-Startereignis eines Ereignis-Unterprozesses tritt ein, wenn eine Kompensation erforderlich ist (Auslöser). Der umgebende Unterprozess wird im Falle einer Kompensation immer abgebrochen. Der Kompensations-Ereignis-Unterprozess wird entweder infolge eines sendenden Kompensations-Zwischenereignisses oder infolge eines Kompensations-Endereignisses ausgeführt. Letzteres ist immer sendend. Befinden sich innerhalb eines Prozesses mehrere empfangende Kompensations-Ereignisse, so sind diese eindeutig den sendenden Kompensations-Ereignissen zuzuordnen. Entfällt diese Zuordnung, werden bei Eintritt eines sendenden Kompensations-Ereignisses alle empfangenden Kompensations-Ereignisse in dem betreffenden Bereich (scope) auf die erkannte Notwendigkeit einer Kompensation reagieren. Ein Ereignis-Unterprozess kann nicht nur in einem Unterprozess angelegt werden, sondern auch in einem Top-Level-Prozess, weil die Steuerung nicht an den unmittelbar übergeordneten Prozess übergeben wird, den es in Bezug auf einen Top-Level-Prozess nicht gibt. Es gibt folgenden Zusammenhang des Kompensations-Startereignisses mit dem FehlerStartereignis:

4.2 Startereignisse

79



Tritt in einer Aktivität ein Fehler auf und es gibt keinen dazu spezifizierten FehlerEreignis-Unterprozess innerhalb des betreffenden Unterprozesses, so werden automatisch alle Aktivitäten des den Fehler auslösenden Unterprozesses kompensiert, sofern die entsprechenden Kompensations-Aktivitäten modelliert wurden.  Schlägt eine Aktivität fehl und löst sie deshalb ein Fehler-Ereignis aus, ist eine Kompensation für diejenigen Aktivitäten nicht mehr notwendig, die infolge einer Fehlerbehandlung bereits kompensiert wurden. Das Beispiel in Abb. 4.29 zeigt noch einmal die Buchung einer Dienstreise. Anders als in Abb. 4.14 wird hier kein angeheftetes Kompensations-Zwischenereignis verwendet, sondern anstelle dessen ein Ereignis-Unterprozess innerhalb des Unterprozesses „Hotel- und Flugbuchung“.

Abb. 4.29:

Beispiel für einen Unterprozess mit eingebettetem Kompensations-Ereignis-Unterprozess (Abb. 4.30)

Die Kompensation wird hier nicht im übergeordneten Prozess angestoßen, sondern in dem im Unterprozess eingebetteten Ereignis-Unterprozess – siehe Abb. 4.30. Trifft während des aktiven Unterprozesses „Hotel- und Flugbuchung“ eine Stornierungsmeldung für den Flug oder das Hotel ein, wird der Unterprozess abgebrochen. Gleichzeitig wird infolge eines der beiden Kompensations-Endereignisse – mit CUP gekennzeichnet – der Ereignis-Unterprozess gestartet – ebenso mit CUP markiert, so dass der Zusammenhang hergestellt ist. Die Kompensations-Zwischenereignisse lösen die Kompensations-Aufgaben „Kompensiere Flugbuchung“ und „Kompensiere Hotelbuchung“ aus.

80

Abb. 4.30:

4 Ereignisse

Beispiel für einen Kompensations-Ereignis-Unterprozess

Fehler (error) Ein Fehler-Startereignis eines Ereignis-Unterprozesses tritt ein, wenn ein Fehler aufgetreten ist. Infolgedessen wird der Fehler-Ereignis-Unterprozess gestartet und der umgebende Unterprozess wird immer abgebrochen. Die Verwendung erfolgt im Wesentlichen bei technischen Problemen. Wie mit dem Fehler umgegangen wird, z. B. wenn ein Ersatzteil nicht (mehr) lieferbar ist, liegt bei der Fehlerbehandlung im Oberprozess. Im Beispiel in Abb. 4.31 und Abb. 4.32 ist der Unterprozess „Füllstand beobachten“ modelliert. Tritt in diesem Unterprozess eine Abweichung von der Norm auf, wird der FehlerEreignis-Unterprozess „Auf Störung reagieren“ gestartet und die Anlage wird heruntergefahren. Das sendende Fehler-Endereignis „Störung S2“ bewirkt, dass der Prozess über das an den Unterprozess angeheftete Fehler-Zwischenereignis „Störung S2“ in einem Ausnahmefluss fortgesetzt wird. Das sendende Fehler-Ereignis „Störung S1“ ist im Diagramm nicht explizit dargestellt. Wollte man das tun, dann müsste man die Service-Aufgaben „Obere Schranke beobachten“ und „Untere Schranke beobachten“ jeweils in einem Unterprozess detaillierter darstellen. Das empfangende Fehler-Startereignis „Störung S1“ startet den Ereignis-Unterprozess „Auf Störung reagieren“ und bricht den umgebenden Unterprozess ab. Ist das wartungsfreie Intervall abgelaufen, dann startet ein alternativer Ausnahmefluss. In Abb. 4.32 werden die Ereignis-Unterprozesse zur Regulierung des Behälterfüllstands dargestellt. Sie können beliebig oft aufgerufen werden.

4.2 Startereignisse

Abb. 4.31:

Darstellung des Oberprozesses für Abb. 4.32

Abb. 4.32:

Darstellung eines abbrechenden Fehler-Ereignis-Unterprozesses

4.2.4

81

Warum es bestimmte Startereignisse bei den EreignisUnterprozessen nicht gibt

Nicht abbrechendes Kompensations-Startereignis (non-interrupting compensation start event) Eine Kompensation wird ausgeführt, sobald sich die Notwendigkeit ergibt, in einem Prozess oder Unterprozess eine Aktivität bzw. deren Ergebnisse rückgängig zu machen. So muss man z. B. eine Hotelbuchung rückgängig machen, wenn sich plötzlich ein Verhinderungsgrund für eine geplante Geschäftsreise ergibt. Der reguläre Ablauf des betreffenden Prozesses bzw. Unterprozesses und die von ihm erzielten Ergebnisse sind nicht mehr erwünscht. Deshalb sind Kompensations-Startereignisse für Ereignis-Unterprozesse immer abbrechend. Nicht abbrechendes Fehler-Startereignis (non-interrupting error start event) Im Fehlerfall wird der Unterprozess, in dem ein Fehler auftritt, immer abgebrochen, denn es macht keinen Sinn, einen fehlerbehafteten Prozess fortzusetzen. Deshalb sind FehlerStartereignisse für Ereignis-Unterprozesse immer abbrechend. Transaktions-Abbruch-Startereignis (cancel start event) Beim Abbruch einer Transaktion muss die Steuerung immer an den übergeordneten Prozess übergeben werden. Ein Ereignis-Unterprozess innerhalb eines Transaktions-Unterprozesses

82

4 Ereignisse

macht demzufolge keinen Sinn, weshalb für Ereignis-Unterprozesse kein AbbruchStartereignis benötigt wird, weder abbrechend noch nicht abbrechend. Link-Startereignis (link start event) Links sind nur innerhalb eines Prozesses oder Unterprozesses möglich, denn es macht keinen Sinn mit einem Link zu beginnen, denn dann kann man ja gleich dort starten, wo der Link hinführt. Abbruch-Startereignis (terminate start event) BPMN lässt nach dem Abbruch eines Prozesses oder Unterprozesses keine Aktivitäten mehr zu, auch keine Kompensation oder eine Fehlerbehandlung. Deshalb benötigt man auch kein Abbruch-Startereignis für Ereignis-Unterprozesse.

4.3

Zwischenereignisse

Abb. 4.33 gibt einen Überblick über alle Zwischenereignisse (intermediate events).

Abb. 4.33: Systematik der Zwischenereignisse

4.3 Zwischenereignisse

83

Bei der Modellierung von Zwischenereignissen sollten folgende Punkte beachtet werden: 

 

Zwischenereignisse befinden sich immer innerhalb eines Prozesses – also weder am Anfang noch am Ende. Eine eintreffende Marke wartet, bis ein bestimmtes Zwischenereignis eingetreten ist. Erst danach fließt die Marke weiter und der Prozess wird fortgesetzt. Die meisten Zwischenereignisse haben einen eingehenden und einen ausgehenden Sequenzfluss. Es gibt aber diverse Ausnahmen, wie bereits im Detail ausgeführt. Innerhalb der Gruppe „Zwischenereignisse“ wird unterschieden zwischen: – sendenden und empfangenden Zwischenereignissen sowie – angehefteten abbrechenden und angehefteten nicht abbrechenden Zwischenereignissen.

4.3.1

Sendende und empfangende nicht angeheftete Zwischenereignisse

Bei nicht angehefteten Zwischenereignissen gilt es folgendes zu berücksichtigen:  

 



Während Startereignisse allesamt empfangende Ereignisse (catching events) und alle Endereignisse sendende Ereignisse (throwing events) sind, gibt es sowohl sendende als auch empfangende Zwischenereignisse. Ein empfangendes Zwischenereignis (catching intermediate event) – wie in der linken Spalte von Abb. 4.34 dargestellt – tritt ein, wenn eine Nachricht oder ein Signal empfangen worden ist, wenn eine Frist abgelaufen ist oder wenn eine Bedingung erfüllt ist usw. Eine ankommende Marke wartet an einem empfangenden Zwischenereignis so lange, bis das erwartete Ereignis eingetreten ist. Unmittelbar danach wird die Marke entlang des Sequenzflusses weitergereicht. Ein sendendes Zwischenereignis (throwing intermediate event) – wie in den beiden ganz rechten Spalten dargestellt – tritt ein, wenn eine bestimmte Nachricht versandt oder ein bestimmtes Signal ausgesendet worden ist, wenn eine Eskalation oder eine Kompensation angestoßen worden ist. Optisch unterscheiden sich das sendende und das empfangende Zwischenereignis dadurch, – –

dass der Marker, hier als Bespiel ein Nachrichtenmarker , beim empfangenden Zwischenereignis unausgefüllt bleibt und dass der Marker, hier wiederum beispielhaft ein Nachrichtenmarker, beim sendenden Zwischenereignis

  

ausgefüllt wird.

Auch hier gibt es wieder die Möglichkeit, in einem Prozess sendende und empfangende Mehrfach-Zwischenereignisse zu modellieren. Darüber hinaus gibt es auch wieder die Möglichkeit, empfangende Parallel-MehrfachZwischenereignisse in einem Prozess zu verwenden. Nur die folgenden, empfangenden Zwischenereignisse können unmittelbar auf ein ereignisbasiertes Gateway folgen und mit ihm zusammenwirken:

In Abb. 4.34 sind alle nicht angehefteten, sendenden und empfangenden Zwischenereignisse dargestellt.

84

Abb. 4.34:

4 Ereignisse

Zusammenfassung der sendenden und empfangenden, nicht angehefteten Zwischenereignisse

Sendendes und empfangendes Nachrichten-Zwischenereignis Die Teilnehmer, die eine Nachricht senden oder empfangen, sollten durch Abbildung eines entsprechenden Nachrichten-Flusses erkennbar sein. Ein sendendes Nachrichten-Zwischenereignis tritt ein, wenn eine Nachricht versandt worden ist (Ergebnis). Es gibt bei dem Adressaten zwei Möglichkeiten darauf zu reagieren, entweder mit einer Empfangs-Aufgabe oder mit einem empfangenden Nachrichten-Ereignis. Ein empfangendes Nachrichten-Zwischenereignis tritt ein, wenn eine Nachricht empfangen worden ist (Auslöser). In Abb. 4.35 wird ein ähnliches Beispiel wie in Abb. 3.14 dargestellt. Allerdings wird es hier nicht mit sendenden und empfangenden Nachrichten-Aufgaben modelliert, sondern alternativ mit sendenden und empfangenden Nachrichten-Zwischenereignissen. Nachfolgend wird der Prozess beim Kunden beschrieben. Nachdem der Kunde seine Seminaranforderungen formuliert hat, versendet er sie an den Bildungsträger. Nun wartet der Kunde auf eine Nachricht, konkret auf ein Angebot. Ist das Angebot eingetroffen, d. h. das empfangende Nachrichtenereignis ist eingetreten, dann wird die Marke weitergereicht an das XOR-Gateway. Der Kunde muss nun entscheiden, ob er noch spezielle Wünsche in das Angebot eingearbeitet haben möchte. Falls nicht, sendet er die Annahmeerklärung an den Bil-

4.3 Zwischenereignisse

85

dungsträger zurück. Das Zurücksenden wird implizit ausgedrückt durch das sendende Nachrichten-Ereignis. Danach ist der Prozess beendet. Wenn der Kunde noch spezielle Wünsche hat, dann teilt er diese dem Bildungsträger mit, und es entsteht ein Pool-übergreifender Zyklus.

Abb. 4.35:

Beispiel für sendende und empfangende Nachrichten-Zwischenereignisse

In Abb. 4.36 werden zwei alternative Modellierungsvarianten dargestellt. Das Prozessfragment links zeigt, dass an einen Bankkunden zunächst eine Einladung zu einem Gespräch versandt wird. Danach wartet eine ankommende Marke im Ereignisbasierten Gateway darauf, dass eines der unmittelbar nachfolgenden Zwischenereignisse eintritt. Im Gegensatz zum XOR-Gateway, welches auf Basis von Daten routet, werden am ereignisbasierten Gateway keine Bedingungen angegeben. Sobald ein unmittelbar nachfolgendes empfangendes Zwischenereignis eintritt, wird die Marke den entsprechenden Sequenzfluss nehmen. Ruft z. B. als erstes der Eingeladene an und bestätigt den Termin für das Gespräch, d. h. das Ereignis „Zusage eingetroffen“ ist eingetreten, wird dieser Prozesspfad verfolgt. Tritt danach das Zeitereignis „Fristablauf für die Zu- oder Absage“ ein, wird es ignoriert. Alternativ zu den empfangenden Nachrichten-Zwischenereignissen können auch Nachrichten empfangende Aufgaben modelliert werden (rechts). Gleiches gilt für Nachrichten sendende Aufgaben bzw. Zwischenereignisse. Das Nachrichten sendende Zwischenereignis impliziert das Versenden einer Nachricht und das Nachrichten empfangende Zwischenereignis impliziert das Empfangen einer Nachricht.

86

Abb. 4.36:

4 Ereignisse

Alternative Modellierung mit sendenden und empfangenden Aufgaben bzw. Zwischenereignisse

Sendendes und empfangendes Signal-Zwischenereignis Ein Signal wird für die allgemeine Kommunikation quer über Pool-Grenzen hinweg verwendet, ohne einen speziellen Adressaten. Es kann mit einer Unwetterwarnung im Radio verglichen werden. Jeder, der sie hört, kann mit vorbeugenden Maßnahmen darauf reagieren. Ein sendendes Signal-Zwischenereignis tritt ein, wenn ein bestimmtes Signal ausgesendet worden ist (Ergebnis). Ein potentieller Empfänger kann mit einem empfangenden Signalereignis darauf reagieren. Ein empfangendes Signal-Zwischenereignis tritt ein, wenn der Prozess registriert, dass ein bestimmtes Signal empfangen worden ist (Auslöser). Im Beispiel in Abb. 4.37 überarbeitet die Abteilung „Software-Entwicklung“ ein Anwendungsprogramm. Nach erfolgter Qualitätssicherung wird ein Signal ausgesendet, das mitteilt, dass das Anwendungsprogramm aktualisiert wurde.

Abb. 4.37:

Anwendung eines sendenden Signal-Zwischenereignisses

Die User in Abb. 4.38 müssen warten, bis ihr Anwendungsprogramm aktualisiert worden ist, um es danach auf Plausibilität zu prüfen usw.

4.3 Zwischenereignisse

Abb. 4.38:

87

Modellierung eines empfangenden Signal-Zwischenereignisses

Empfangendes Zeit-Zwischenereignis Dieses Ereignis tritt ein, wenn ein bestimmter Zeitpunkt (z. B. ein Liefertermin) erreicht worden ist, ein bestimmter Zeitraum (z. B. eine Zahlungsfrist) abgelaufen ist oder sich ein Zeitzyklus wiederholt (z. B. die Semesterferien). Es gibt also 3 alternative Auslöser. Das Zeit-Zwischenereignis gibt es nur in der empfangenden Variante, da die Zeit objektiv und unabhängig vom Prozess existiert und von einem externen Zeitgeber gesendet wird. Ein empfangendes Zeit-Zwischenereignis kann als Verzögerungsmechanismus dienen. Der BPMN-Standard definiert nur die empfangende Variante des Zeit-Zwischenereignisses, da die permanente Überprüfung der Zeit nicht durch den Prozess selbst, sondern durch einen externen Zeitgeber erfolgt. Empfangendes Bedingungs-Zwischenereignis Dieses Ereignis tritt ein, wenn eine bestimmte Bedingung erfüllt ist, die vorher nicht erfüllt war (Auslöser). Es gibt nur die empfangende Variante, da die permanente Überprüfung der Bedingungen nicht durch den Prozess selbst erfolgt, sondern durch eine Business Rule Engine. Sendende Zeit- und Bedingungs-Zwischenereignisse treten immer implizit in der Prozessumgebung ein und sind niemals Bestandteil eines zu modellierenden BPMNProzesses. Deshalb gibt es in BPMN auch keine Symbole dafür. Das Beispiel in Abb. 4.39 beschreibt die Beauftragung eines Gutachtens. Nachdem das Gutachten und die Rechnung erstellt und an den Auftraggeber versandt worden sind, wartet eine ankommende Marke im Ereignisbasierten Gateway auf einen Ereignis-Eintritt aus der Prozessumgebung. Die Marke nimmt entweder den Sequenzfluss zum Zeit-Zwischenereignis, wenn zuerst das Zahlungsziel überschritten worden ist, oder sie läuft über das BedingungsZwischenereignis, wenn die Bedingung „Rechnungsbetrag eingegangen“ zuerst eingetreten ist usw. entlang des Sequenzflusses. Zur Möglichkeit des gleichzeitigen Eintritts der unmittelbar auf ein ereignisbasiertes Gateway folgenden Ereignisse sagt der Standard nichts. Wie in diesem Fall verfahren wird, bleibt damit den Herstellern von Process Engines überlassen.

88

Abb. 4.39:

4 Ereignisse

Verwendung von Zeit- und Bedingungs-Zwischenereignissen

Sendendes und empfangendes Mehrfach-Zwischenereignis Mehrfach-Zwischenereignisse referenzieren eine vom Modellierer festgelegte Menge von Ereignis-Definitionen. Ein sendendes Mehrfach-Zwischenereignis tritt ein, wenn alle Einzel-Ergebnisse aus einer vom Modellierer festgelegten Menge von Einzel-Ergebnissen herangezogen werden. Ein empfangendes Mehrfach-Zwischenereignis tritt ein, wenn wenigstens ein EinzelAuslöser aus einer vom Modellierer festgelegten Menge von Einzel-Auslösern aktiviert ist. Ist in Abb. 4.40 das multiple Zwischenereignis – „Vorgesetzter informiert und Erfassung in Datenbank erfolgt“ – eingetreten, wird eine ankommende Marke weitergereicht.

Abb. 4.40:

Modellierung eines sendenden Mehrfach-Zwischenereignisses

Dem empfangenden Mehrfach-Zwischenereignis sind mehrere Ereignis-Definitionen zugeordnet. Tritt eines dieser Ereignisse ein, dann läuft der Prozess weiter. In Abb. 4.41 wartet die Marke am Ereignisbasierten Gateway, welches der unmittelbar nachfolgenden Ereignisse zuerst eintritt. Ist nach der Vorsorgeuntersuchung alles in Ordnung, ist der Prozess beendet. Tritt das Mehrfach-Zwischenereignis „Abweichung von Norm aufgetreten oder Beschwerden aufgetreten“ ein, läuft die dort ankommende Marke zur Aufgabe „Folgetermin vereinbaren“ weiter.

4.3 Zwischenereignisse

Abb. 4.41:

89

Beispiel für ein empfangendes Mehrfach-Zwischenereignis

Das Mehrfach-Zwischenereignis sollte im Sinne einer verbesserten Aussagekraft und klaren Modellierung besser durch geeignete Einzelereignisse ersetzt und durch ein Inklusives Gateways verknüpft werden. Empfangendes Parallel-Mehrfach-Zwischenereignis Dieses Ereignis tritt ein, wenn alle Einzel-Auslöser aus einer vom Modellierer festgelegten Menge von Einzel-Auslösern aktiviert sind. Das empfangende Parallel-MehrfachZwischenereignis referenziert also mehrere Ereignis-Definitionen mit verschiedenen Auslösern bzw. Triggern. Eine an einem empfangenden Parallel-Mehrfach-Zwischenereignis ankommende Marke wartet dort so lange, bis das Parallel-Mehrfach-Zwischenereignis eingetreten ist. Unmittelbar danach wird die Marke weitergeleitet. Wenn im Beispiel von Abb. 4.42 der Kredit genehmigt wurde und der Kreditvertrag unterzeichnet vorliegt und die Sicherheiten vom Kunden gestellt wurden, erfolgt die Kreditauszahlung.

Abb. 4.42:

Beispiel für ein Parallel-Mehrfach-Zwischenereignis

Ein sendendes Parallel-Mehrfach-Ereignis ist in BPMN 2.0 nicht definiert. Sendendes Eskalations-Zwischenereignis Ein sendendes Eskalations-Zwischenereignis kann nur innerhalb eines Unterprozesses vorkommen, d. h. also nicht in einem Top-Level-Prozess und auch nicht in einem EreignisUnterprozess. Ein sendendes Eskalations-Zwischenereignis tritt ein, wenn die Notwendigkeit einer bestimmten Eskalation erkannt worden ist (Ergebnis).

90

4 Ereignisse

Ein empfangendes Eskalations-Zwischenereignis kann ausschließlich als angeheftetes Zwischenereignis vorkommen – siehe Punkt 4.3.3. Es tritt ein, wenn die Notwendigkeit einer Eskalation besteht (Auslöser). Man muss hier zwei Fälle unterscheiden: a) der Unterprozess wird infolge der Eskalation abgebrochen und b) der Unterprozess wird trotz Eskalation parallel fortgesetzt. Man muss sich den weiteren Ablauf wie folgt vorstellen. Im Fall a wird eine im Unterprozess ankommende Marke an den Ausnahmefluss weitergeleitet, beginnend am empfangenden, nicht unterbrechenden Eskalations-Zwischenereignis. Es wird dort eine zusätzliche Marke generiert, die entlang des Ausnahmeflusses fließt. Die zusätzliche Marke muss am Ende des Ausnahmepfades konsumiert oder vorher mit einer anderen Marke vereinigt werden. Im Fall b wird eine im Unterprozess ankommende Marke an den regulären Sequenzfluss weitergeleitet. Im Beispiel in Abb. 4.43 tritt unter bestimmten Umständen das sendende EskalationsZwischenereignis „Budgeterhöhung“ ein (Ergebnis), gefolgt vom Eintreten des angehefteten Eskalations-Zwischenereignisses. Es wird eine neue Marke generiert, die ausgehend vom angehefteten Eskalations-Zwischenereignis entlang des Ausnahmeflusses fließt. Die Eskalationsmaßnahme besteht darin, die Budgeterhöhung sicherzustellen. Beachte: Im Beispiel werden die am zusammenführenden Inklusiven Gateway ankommenden Marken synchronisiert. Das bedeutet, dass beim Vorhandensein von zwei Marken die erste Marke auf die zweite Marke im Inklusiven Gateway wartet, bevor der Prozess fortgesetzt wird. Die Modellierung eines Parallelen Gateways wäre nicht korrekt, da der Ausnahmefluss in diesem Beispiel ja nicht in jedem Fall verfolgt wird.

Abb. 4.43:

Anwendung des Eskalations-Zwischenereignisses

4.3 Zwischenereignisse

91

Sendendes Kompensations-Zwischenereignis Im Kapitel 2.2.3 wurde die Kompensation bereits im Rahmen der Markierung von Aufgaben und in Kapitel 4.2.3 im Rahmen von Ereignis-Unterprozessen behandelt. Hier an passender Stelle eine Ergänzung dazu. Ein sendendes Kompensations-Zwischenereignis tritt ein, wenn sich die Notwendigkeit einer Kompensation ergeben hat (Ergebnis). Bei den sendenden Kompensations-Zwischenereignissen gilt es folgendes zu beachten: 

Das sendende Kompensations-Zwischenereignis muss die rückgängig zu machenden Aktivitäten erkennen können. Dabei gilt, dass sich – das Kompensations-Zwischenereignis in derselben Prozessebene befinden muss oder – innerhalb eines Ereignis-Unterprozesses, der in einen Unterprozess eingebettet ist, der – letzterer – die zurückzusetzenden Aktivitäten enthält.  Um kompensiert zu werden, muss eine Aktivität entweder ein angeheftetes Kompensations-Ereignis haben oder, im Fall eines Unterprozesses, einen Kompensations-EreignisUnterprozess beinhalten.  Unter bestimmten Umständen erfolgt das Zurücksetzen aller erkennbaren Aktivitäten in der umgekehrten Reihenfolge dem Sequenzfluss rückwärts folgend. Ein empfangendes Kompensations-Zwischenereignis gibt es nur als angeheftetes Ereignis – siehe Punkt 4.3.3. Abb. 4.44 zeigt noch einmal das Beispiel aus Abb. 2.7. Wird ein neuer Termin gewünscht, gelangt eine im verzweigenden Exklusiven Gateway ankommende Marke zum Kompensations-Zwischenereignis, welches die beiden Kompensationsaufgaben anstößt. Damit wird der zwischen dem Gutachter und dem Kunden abgestimmte, aber von der Förderbank nicht akzeptierte Termin rückgängig gemacht. Im Zyklus wird versucht, einen alternativen Termin zu finden.

Abb. 4.44:

Beispiel für ein auslösendes Kompensations-Zwischenereignis

92

4 Ereignisse

Sendendes und empfangendes Link-Zwischenereignis Links kommen nur als sendende oder empfangende Zwischenereignisse vor. Das Beispiel in Abb. 4.45 zeigt, dass die beiden Link-Ereignisse einen Sequenzfluss unterbrechen und wieder zusammenführen und somit als Konnektor fungieren. Dies wendet man z. B. an, wenn sich die Diagramme über mehrere Seiten erstrecken und der Anwender zur Fortsetzung auf der nächsten Seite gelangen möchte, oder um lange Sequenzflüsse mit unschönen Umgehungen oder Linien-Kreuzungen zu vermeiden. Sinnvoll ist die eindeutige Kennzeichnung der Anschluss-Stellen – im Beispiel mit „A“.

Abb. 4.45:

Verwendung des sendenden und des empfangenden Link-Zwischenereignisses

Man kann die Link-Trigger auch zur Darstellung von Schleifen bzw. Zyklen verwenden (Abb. 4.46).

Abb. 4.46:

Link-Zwischenereignis als Schleife

Unspezifiziertes Zwischenereignis Dieses Ereignis ist gemäß Spezifikation nur als „sendendes“ Zwischenereignis definiert, obwohl kein Ergebnis erzielt wird. Das Attribut „unspezifiert“ sollte man besser durch die Formulierung „nicht näher spezifiziert“ ersetzen, da ja ein Zwischenereignis definiert wird, wenn auch ohne Ergebnissymbol. Das nicht näher spezifizierte Zwischenereignis wird für methodische Zwecke genutzt, um z. B. einen Status-Wechsel im Prozess anzuzeigen (siehe Beispiele in Abb. 4.47 und Abb. 4.48).

4.3 Zwischenereignisse

93

Abb. 4.47:

Beispiel für die Verwendung des unspezifizierten bzw. nicht näher spezifizierten Zwischenereignisses

Abb. 4.48:

Weiteres Beispiel für das unspezifizierte bzw. nicht näher spezifizierte Zwischenereignis

94

4.3.2

4 Ereignisse

Warum es bestimmte nicht angeheftete Zwischenereignisse nicht gibt

Bei allen nachfolgend genannten Ereignistypen wird unterstellt, dass sie nicht angeheftet sind. Empfangendes Unspezifiziertes Zwischenereignis (intermediate none-event) Unspezifiziert bzw. nicht näher spezifiziert heißt, dass es keinen Auslöser gibt und damit auch nichts, worauf man reagieren müsste. Empfangendes Eskalations-Zwischenereignis (catching escalation intermediate event) Die Notwendigkeit einer Eskalation kann sich lt. Standard ausschließlich in einem Unterprozess ergeben. Man kann auf zwei Arten darauf reagieren. Erstens mit Hilfe eines angehefteten Zwischenereignisses (siehe Punkt 4.3.3) oder mittels eines Ereignis-Unterprozesses, der aber mit einem Startereignis und nicht mit einem Zwischenereignis beginnt. Empfangendes Kompensations-Zwischenereignis (catching compensation intermediate event) Auf die Notwendigkeit einer Kompensation kann lt. Standard auf zwei Arten reagiert werden, erstens mit Hilfe eines angehefteten Zwischenereignisses (siehe Punkt 4.3.3) oder mittels eines Ereignis-Unterprozesses, der aber mit einem Startereignis und nicht mit einem Zwischenereignis beginnt. Empfangendes Abbruch-Zwischenereignis für Transaktions-Unterprozesse (catching cancel intermediate event) Ein empfangendes Abbruch-Zwischenereignis kann lt. Standard nur ein angeheftetes Ereignis sein – siehe Punkt 4.3.3, denn der Unterprozess muss im Fall eines Abbruchs verlassen werden. Empfangendes Abbruch-Zwischenereignis für Prozesse (catching terminate intermediate event) Bei einem Prozessabbruch gibt es keine Fehlerbehandlung (error handling). Folglich braucht man auch kein empfangendes Abbruch-Zwischenereignis. Sendendes Zeit- bzw. Zeitgeber-Zwischenereignis (throwing timer intermediate event) Sendende Zeit-Zwischenereignisse sind generell unabhängig von dem zu modellierenden Prozess. Sie kommen deshalb implizit immer von der Prozessumgebung, genauer gesagt, von einem Zeitgeber (timer). Sendendes Parallel-Mehrfach-Zwischenereignis (throwing parallel multiple intermediate event) Sendende Parallel-Mehrfach-Ereignisse und insbesondere auch sendende Parallel-MehrfachZwischenereignisse sind in BPMN 2.0 nicht definiert. Der Grund ist vermutlich, dass ein Prozess an einem solchen Zwischenereignis hängen bleiben könnte, weil möglicherweise nicht alle geforderten Ergebnisse für das Eintreten des multiplen Ereignisses zustande kommen. Im Standard wird kein Grund angegeben.

4.3 Zwischenereignisse

95

Sendendes Eskalations-Zwischenereignis (throwing escalation intermediate event) Ein Sendendes Eskalations-Zwischenereignis ist in Unterprozessen zulässig, jedoch nicht in Top-Level-Prozessen und nicht in Ereignis-Unterprozessen, denn wohin sollte in diesen beiden letztgenannten Fällen eskaliert werden? Der Top-Level-Prozess hat keine übergeordnete Prozess-Ebene und der Ereignis-Unterprozess kann im Gegensatz zum normalen Unterprozess die Steuerung nicht an den übergeordneten Prozess übergeben. Sendendes Fehler-Zwischenereignis (throwing error intermediate event) Nach einem Fehler wird ein Prozess oder ein Unterprozess immer abgebrochen. Folglich kann es kein sendendes Fehler-Zwischenereignis geben. Sendendes Abbruch-Zwischenereignis für Transaktionen (throwing cancel intermediate event) Nach einem Zwischenereignis wäre ein Transaktions-Unterprozess nicht beendet, also kann eine Transaktion nicht durch ein Zwischenereignis, sondern nur durch ein Endereignis abgebrochen werden. Sendendes Abbruch-Zwischenereignis für Prozesse (throwing termination intermediate event) Nach einem Zwischenereignis ist der Prozess nicht zu Ende, also kann er nicht durch ein Zwischenereignis, sondern nur durch ein Endereignis abgebrochen werden.

4.3.3

Angeheftete abbrechende und nicht abbrechende Zwischenereignisse

Mit den Zwischenereignissen, die an Aufgaben oder Unterprozesse angeheftet werden (boundary intermediate events) und dabei abbrechende (interrupting) oder nicht abbrechende (non-interrupting) Wirkung entfalten, kommen wir nun zur vertiefenden Behandlung von Ausnahmen, Sonderfällen und Fehlern. Abb. 4.49 zeigt alle angehefteten Zwischenereignisse.

96

4 Ereignisse

Abb. 4.49:

Übersicht über die angehefteten Zwischenereignisse

Was bei der Modellierung von angehefteten Zwischenereignissen zu beachten ist:    



An eine Aktivität können ein oder mehrere empfangende Zwischenereignisse angeheftet werden. Angeheftete Zwischenereignisse haben keinen eingehenden Sequenzfluss, sondern in der Regel einen ausgehenden. Der Kompensations-Trigger hat weder einen eingehenden noch einen ausgehenden Sequenzfluss. Er hat anstelle eines ausgehenden Sequenzflusses eine Verknüpfung zu einer Kompensations-Aktivität. Sollen mehrere Sequenzflüsse aus einem angehefteten Zwischenereignis herausführen, werden mehrere parallele Ausnahmepfade modelliert. In diesem Fall muss eine eingehende Marke gesplittet werden, so dass an jeden ausgehenden Sequenzfluss genau eine Marke übergeben wird. Das angeheftete Zwischenereignis kann nur während der Ausführung der Aufgabe bzw. des Unterprozesses eintreten. Ein Auslöser wird vor und nach der Ausführung einer Aktivität ignoriert. Das könnte z. B. beim verspäteten Eintreffen einer Stornomeldung der Fall sein.

4.3 Zwischenereignisse 

97

Innerhalb der Gruppe angehefteter Zwischenereignisse wird unterschieden zwischen – abbrechenden angehefteten Zwischenereignissen mit zwei durchgezogenen Kreisli-

–

nien und nicht abbrechenden angehefteten Zwischenereignissen mit zwei gestrichelten Kreislinien

.

Beachte: Im Fall des nicht abbrechenden Zwischenereignisses wird eine zweite Marke generiert, die durch ein Endereignis konsumiert werden muss.

Angeheftetes abbrechendes und nicht abbrechendes NachrichtenZwischenereignis Der Auslöser ist bei diesen Ereignissen außerhalb des Pools zu suchen, in dem ein entsprechendes sendendes Ereignis eintritt, denn eingehende Nachrichten können nur von anderen Pools kommen. Ein angeheftetes abbrechendes Nachrichten-Zwischenereignis tritt ein, wenn von einem Geschäftspartner eine bestimmte Nachricht eingegangen ist (Auslöser). Der Unterprozess wird abgebrochen. Ein angeheftetes nicht abbrechendes Nachrichten-Zwischenereignis tritt ein, wenn von einem Geschäftspartner eine bestimmte Nachricht eingegangen ist (Auslöser). Der Unterprozess wird nicht abgebrochen. In Abb. 4.50 stellt der Kunde einen Kreditantrag, was bei der Bank zum Prozess-Start führt. Während der Bearbeitung des Kreditantrages in einem Unterprozess, reicht der Kunde weitere Unterlagen ein. Dieser Nachrichteneingang löst das angeheftete, nicht abbrechende Nachrichten-Ereignis aus. Der reguläre Ablauf wird fortgesetzt. Man kann sich den Ablauf im Ausnahmefall wie folgt vorstellen. Es wird eine zusätzliche Marke generiert, die über den Ausnahmefluss (exception flow) zur Aufgabe „Unterlagen zur Erfassung geben“ weitergereicht wird. Diese zusätzliche Marke muss am Ende des Ausnahmepfades konsumiert werden. Zieht der Kunde während des Unterprozesses seinen Kreditantrag zurück, tritt das den Prozess abbrechende Nachrichten-Zwischenereignis ein. Eine im Unterprozess befindliche Marke fließt über den Ausnahmefluss zur Aufgabe „Unterlagen an den Kunden zurück senden“, und der Prozess ist beendet.

98

Abb. 4.50:

4 Ereignisse

Anwendung des angehefteten abbrechenden und nicht abbrechenden Nachrichten-Zwischenereignisses

Angeheftetes abbrechendes und nicht abbrechendes Signal-Zwischenereignis Ein zu empfangendes Signal kann im umgebenden Unterprozess, aber auch in anderen Prozessen und Pools ausgesendet worden sein. Ein angeheftetes abbrechendes Signal-Zwischenereignis tritt ein, wenn ein bestimmtes Signal empfangen worden ist (Auslöser). Der Unterprozess wird abgebrochen. Ein angeheftetes nicht abbrechendes Signal-Zwischenereignis tritt ein, wenn ein bestimmtes Signal empfangen worden ist (Auslöser). Der Unterprozess wird nicht abgebrochen. Das Beispiel in Abb. 4.51 zeigt, dass während der Erfassung der Daten in einer Datenbank ggf. ein Ausfallsignal empfangen wird. Die Aufgabe wird deshalb abgebrochen und die in der Aufgabe angekommene Marke fließt auf dem Ausnahmefluss zur Aufgabe „BackgroundArbeiten erledigen“ weiter. Wurde das Signal-Zwischenereignis „Störung behoben“ empfangen, wird wieder zur Ursprungsaufgabe zurückgekehrt.

4.3 Zwischenereignisse

Abb. 4.51:

99

Beispiel für ein angeheftetes abbrechendes Signal-Zwischenereignis

Das angeheftete nicht abbrechende Signal-Zwischenereignis kommt in Abb. 4.52 vor. Während des Administrierens einer Datenbank signalisiert die Schichtleitung ein offenes Zeitfenster für Wartungsarbeiten. Es wird eine zweite Marke generiert, die über den Ausnahmefluss zur Aufgabe „Recovery Training durchführen“ fließt. Nach Ausführen dieser Aufgabe wird die Marke im Endereignis konsumiert. Sollte während des Recovery-Trainings die Datenbank nicht mehr verfügbar sein, verlässt die Marke die abgebrochene Aufgabe „Recovery Training durchführen“ über den Fehler-Ausnahmefluss oder das Recovery-Training wird normal beendet.

Abb. 4.52:

Beispiel für ein angeheftetes nicht abbrechendes Signal-Ereignis

Angeheftetes abbrechendes und nicht abbrechendes Zeit-Zwischenereignis Es sei an dieser Stelle noch mal daran erinnert, dass es in BPMN keine sendenden Zeitereignisse gibt, weil dafür ein externer Zeitgeber verantwortlich ist.

100

4 Ereignisse

Ein angeheftetes abbrechendes Zeit-Zwischenereignis tritt ein, wenn entweder ein Zeitpunkt erreicht ist oder eine Frist abgelaufen ist oder sich ein Zeitzyklus wiederholt (3 alternative Auslöser). Der Unterprozess wird abgebrochen. Ein angeheftetes nicht abbrechendes Zeit-Zwischenereignis tritt ein, wenn entweder ein Zeitpunkt erreicht oder eine Frist abgelaufen ist oder sich ein Zeitzyklus wiederholt (3 alternative Auslöser). Der Unterprozess wird nicht abgebrochen. In Abb. 4.53 wird die Aktivität „Füllstand beobachten“ ausgeführt. Läuft in dieser Zeit das wartungsfreie Intervall ab, tritt das Zeit-Zwischenereignis ein. Die Aktivität wird abgebrochen und der Prozess wird über den Ausnahmefluss fortgesetzt. Während des wartungsfreien Intervalls wird der Füllstand geregelt. Die Ausnahmeflüsse nach den Aufgaben „Zufluss zuschalten“ bzw. „Zufluss stoppen“ können wiederholt durchlaufen werden, d. h. jeweils wenn die untere bzw. obere Schranke für den Füllstand unter- bzw. überschritten wird.

Abb. 4.53: Beispiel für ein abbrechendes Zeit-Zwischenereignis und zwei nicht abbrechende BedingungsZwischenereignisse

Abb. 4.54 zeigt den Prozess einer Antragsbearbeitung. Während die Aufgabe „Antrag bearbeiten“ ausgeführt wird, löst der Zeit-Trigger „14 Tage nach Antragseingang“ das ZeitZwischenereignis aus. Man muss sich den Ablauf so vorstellen, dass eine zusätzliche Marke generiert wird, die ausgehend vom angehefteten Zeitzwischenereignis entlang des Ausnahmeflusses fließt. Ein Zwischenbescheid wird an den Kunden versandt und die Marke konsumiert, wobei kein Abbruch der Antragsbearbeitung als Ganzes erfolgt.

4.3 Zwischenereignisse

Abb. 4.54:

101

Anwendung des angehefteten nicht abbrechenden Zeit-Zwischenereignisses

Angeheftetes abbrechendes und nicht abbrechendes BedingungsZwischenereignis Auch hier sei noch mal daran erinnert, dass es in BPMN keine sendenden BedingungsEreignisse gibt, weil dafür eine Business Rule Engine verantwortlich ist. Ein angeheftetes abbrechendes Bedingungs-Zwischenereignis tritt ein, wenn eine bestimmte Bedingung erfüllt ist (Auslöser). Der Prozess wird abgebrochen. Ein angeheftetes nicht abbrechendes Bedingungs-Zwischenereignis tritt ein, wenn eine bestimmte Bedingung erfüllt ist (Auslöser). Der Prozess wird nicht abgebrochen. Im Beispiel in Abb. 4.55 wurde eine Anlage auf Handbetrieb umgestellt. Während des Handbetriebs tritt die abbrechende Bedingung „Automatik wieder intakt“ ein. Der Handbetrieb wird abgebrochen. Man muss sich den Ablauf so vorstellen, dass die im Unterprozess angekommene Marke den Unterprozess über den Ausnahmefluss verlässt.

Abb. 4.55:

Verwendung des angehefteten abbrechenden Bedingungs-Zwischenereignisses

102

4 Ereignisse

Für das angeheftete nicht abbrechende Bedingungs-Zwischenereignis kommen wir auf das Beispiel in Abb. 4.53 zurück. Wenn der Füllstand während des Beobachtens z. B. die Bedingung größer 93% erfüllt hat, tritt das Bedingungs-Zwischenereignis ein und es wird eine zusätzliche Marke erzeugt, die die Aktivität über den Ausnahmefluss verlässt. Die Aktivität „Füllstand beobachten“ wird nicht abgebrochen. Die zusätzlich generierten Marken werden jeweils infolge eines Endereignisses konsumiert. Angeheftetes abbrechendes und nicht abbrechendes MehrfachZwischenereignis Die Definition eines angehefteten Mehrfach-Zwischenereignisses referenziert eine bestimmte Menge von Ereignis-Definitionen. Ein angeheftetes abbrechendes Mehrfach-Zwischenereignis tritt ein, wenn wenigstens ein Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert ist. Der Unterprozess wird abgebrochen. Man muss sich den weiteren Ablauf so vorstellen, dass die im Unterprozess angekommene Marke den Unterprozess über das angeheftete MehrfachZwischenereignis verlässt und entlang des Ausnahmeflusses weiterfließt. Ein angeheftetes nicht abbrechendes Mehrfach-Zwischenereignis tritt ein, wenn wenigstens ein Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert ist. Der Unterprozess wird nicht abgebrochen. Man muss sich den weiteren Ablauf so vorstellen, dass die im Unterprozess angekommene Marke entlang des regulären Sequenzflusses weiterfließt. Im angehefteten Mehrfach-Zwischenereignis wird eine zusätzliche Marke generiert, die entlang des Ausnahmeflusses fließt und am Ende des Ausnahmepfades konsumiert werden muss. Wenn wie in Abb. 4.56 dargestellt, ein Auto den TÜV nicht erfolgreich passiert hat, wird anschließend die Aufgabe „Fehler analysieren und Reparatur durchführen“ ausgeführt. Tritt währenddessen eines der Ereignisse „Reparatur nicht mehr möglich“ oder „Kosten zu hoch“ ein, wird die Aufgabe abgebrochen. Man muss sich den weiteren Ablauf so vorstellen, dass die im Unterprozess angekommene Marke den Unterprozess über das angeheftete MehrfachZwischenereignisses verlässt und dann entlang des Ausnahmeflusses weiterfließt.

Abb. 4.56:

Beispiel für ein angeheftetes abbrechendes Mehrfach-Zwischenereignis

4.3 Zwischenereignisse

103

Wenn in Beispiel Abb. 4.57 wenigstens eines der beiden Einzel-Ereignisse „Allokierter Speicherplatz erschöpft“ oder „Betriebssystem-Update notwendig“ eingetreten ist, dann ist auch das nicht abbrechende Mehrfach-Zwischenereignis eingetreten, und eine zu generierende zweite Marke nimmt ihren Weg über den Ausnahmefluss. Dabei wird der Unterprozess nicht abgebrochen.

Abb. 4.57:

Beispiel für ein angeheftetes nicht abbrechendes Mehrfach-Zwischenereignis

Angeheftetes abbrechendes und nicht abbrechendes Parallel-MehrfachZwischenereignis Die Definition eines angehefteten Parallelen Mehrfach-Zwischenereignisses verweist auf eine bestimmte Menge von Ereignis-Definitionen. Ein angeheftetes abbrechendes Mehrfach-Zwischenereignis tritt ein, wenn alle Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert sind. Der Unterprozess wird abgebrochen. Man muss sich den Ablauf so vorstellen, dass eine im Unterprozess ankommende Marke den Unterprozess über das angeheftete MehrfachZwischenereignis verlässt und entlang des Ausnahmeflusses weiterfließt. Ein angeheftetes nicht abbrechendes Mehrfach-Zwischenereignis tritt ein, wenn alle Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert sind. Der Unterprozess wird nicht abgebrochen. Man kann sich den weiteren Ablauf so vorstellen: Die im Unterprozess ankommende Marke fließt entlang des regulären Sequenzflusses weiter, und im angehefteten Mehrfach-Zwischenereignisses wird eine zusätzliche Marke generiert, die entlang des Ausnahmeflusses fließt und an dessen Ende konsumiert wird. In Abb. 4.58 befindet sich ein Blechbearbeitungszentrum im Dauerbetrieb. Ist die Automatik ausgefallen und die maximale Laufzeit des manuellen Betriebes abgelaufen, wird der Unterprozess abgebrochen und eine im Unterprozess befindliche Marke fließt über den Ausnahmefluss weiter, bis sie an dessen Ende konsumiert wird.

104

Abb. 4.58:

4 Ereignisse

Beispiel für ein angeheftet abbrechendes Parallel-Mehrfach-Zwischenereignis

Das Beispiel aus Abb. 4.26 wurde in der folgenden Abb. 4.59 abgewandelt, indem der Ereignis-Unterprozess aus dem Unterprozess „Körperpflege, Ernährung, Hauswirtschaft“ entfernt und nun bei der Aufgabe „Pflegedaten erfassen“ ein nicht abbrechendes Parallel-MehrfachZwischenereignis mit selber Wirkung angeheftet wurde. Wird während der Erfassung festgestellt, dass das Parallel-Mehrfach-Ereignis „Zeit für Körperhygiene und Ernährung > 46 Minuten pro Tag und Zeit für Hauswirtschaftshilfe > 46 Minuten pro Tag“ eingetreten ist, wird eine zweite Marke erzeugt und über den Ausnahmefluss zur nächsten Aufgabe weitergeleitet. Der reguläre Ablauf wird dabei nicht unterbrochen.

Abb. 4.59:

Beispiel für ein angeheftetes nicht abbrechendes Parallel-Mehrfach-Zwischenereignis

Angeheftetes abbrechendes und nicht abbrechendes EskalationsZwischenereignis Zum Mittel der Eskalation greift man meist, wenn in einem Unterprozess ein Problem aufgetreten ist, das dort nicht ohne Hilfe oder gar nicht gelöst werden kann. Mit einem angehefteten Eskalations-Zwischenereignis kann auf die Notwendigkeit der Eskalation reagiert werden. Je nachdem wie schwerwiegend der Grund für die Eskalation ist, wird der Unterprozess entweder abgebrochen oder nicht.

4.3 Zwischenereignisse

105

Ein angeheftetes abbrechendes Eskalations-Zwischenereignis tritt ein, wenn die Notwendigkeit einer Eskalation besteht (Auslöser). Infolge des Abbruchs verlässt die vorhandene Marke den Unterprozess über den Ausnahmefluss. Ein angeheftetes nicht abbrechendes Eskalations-Zwischenereignis tritt ein, wenn die Notwendigkeit einer Eskalation besteht (Auslöser). Wegen der Fortsetzung des Unterprozesses wird für den Eskalations-Ausnahmepfad eine weitere Marke generiert, die ausgehend vom angehefteten Eskalations-Zwischenereignis entlang des Ausnahmeflusses fließt. Die zusätzliche Marke muss am Ende eines Prozesszweigs konsumiert werden. In Abb. 4.60 soll beispielhaft der Prozess einer Abmahnungserstellung modelliert werden. Um den zeitlichen Zusammenhang zwischen Fehlverhalten eines Mitarbeiters und der Aushändigung einer Abmahnung herzustellen, ist eine 14-Tages-Frist im Allgemeinen nicht zu überschreiten. Die Fachabteilung bittet die Personalabteilung um die Erstellung einer Abmahnung. Fällt während dieser Aufgabe der Bearbeiter aus (und es droht die Überschreitung der 14-TagesFrist), wird der Eskalations-Trigger ausgelöst, die Aufgabe wird abgebrochen und die Marke fließt über den Ausnahmefluss zur nächsten Aufgabe.

Abb. 4.60:

Anwendung des angehefteten abbrechenden Eskalations-Zwischenereignis

Im folgenden Beispiel in Abb. 4.61 geht beim Service-Anbieter eine Kundenbeschwerde ein. Diese wird analysiert. Dabei wird ein systematischer Fehler beim Service-Anbieter erkannt und das angeheftete nicht abbrechende Eskalations-Zwischenereignis ausgelöst. Die Beschwerde wird im „normalen“ Ablauf weiter bearbeitet und gleichzeitig wird eine zweite

106

4 Ereignisse

Marke generiert, welche über den Ausnahmefluss zur nächsten Aufgabe fließt und anschließend konsumiert wird.

Abb. 4.61: Anwendung des angehefteten nicht abbrechenden Eskalations-Zwischenereignisses

Behandlung der Ausnahmen: Kompensation , Fehler und Abbruch Ausnahmen erfordern immer einen Ausnahmefluss zur Ausnahmebehandlung. Ein angeheftetes Kompensations-Zwischenereignis tritt ein, wenn die Notwendigkeit einer Kompensation besteht (Auslöser). Ein angeheftetes Fehler-Zwischenereignis tritt ein, wenn ein Fehler aufgetreten ist und folglich die Notwendigkeit einer Fehlerbehandlung besteht (Auslöser). Das Abbruch-Zwischenereignis kann nur an einen Transaktions-Unterprozess angeheftet werden. Ein Abbruch-Zwischenereignis tritt ein, wenn die Notwendigkeit eines Rollbacks besteht. Die Transaktion wird als Ganzes zurückgerollt (roll back). Es werden alle im Transaktions-Unterprozess enthaltenen Kompensationsaktivitäten ausgeführt. Die vorgenannten Ausnahmen sollen alle am Beispiel in Abb. 4.62 erläutert werden. In der Auftragsbearbeitung geht ein Auftrag ein, welcher automatisiert durch eine Software-Lösung analysiert wird. Anschließend wird die in der Aufgabe befindliche Marke zum TransaktionsUnterprozess weitergereicht. Dort wird zunächst das Kreditkartenkonto belastet und danach der Auftrag (in einem Unterprozess) abgearbeitet. Tritt bei der Auftragsbearbeitung ein Fehler ein, z. B. dass der bestellte Artikel nicht verfügbar ist, wird diese Aktivität abgebrochen. Die im Unterprozess „Bearbeite Auftrag“ befindliche Marke wird über das angeheftete Fehler-Zwischenereignis weitergeleitet und erreicht das Abbruch-Endereignis , das sich immer innerhalb eines Transaktions-Unterprozesses befinden muss. Gleichzeitig werden alle mit dem Kompensations-Zwischenereignis versehenen Aufgaben zurückgesetzt, d. h. das Kreditkartenkonto wird entlastet. Danach läuft die Marke über das wiederum nur für Tran-

4.3 Zwischenereignisse

107

saktionen verwendete Abbruch-Zwischenereignis „Storniere Auftrag“ weiter. Eine Stornierungsmeldung wird automatisiert erstellt und versendet, und der Prozess ist beendet.

Abb. 4.62:

Beispiel für das angeheftete Kompensations-, Fehler- und Abbruch-Zwischenereignis

Bei angehefteten abbrechenden Ereignissen (immer Zwischenereignisse) gilt es folgendes zu beachten: 





 

Die Auslöser von angehefteten abbrechenden Nachrichten-, Zeit- und Bedingungsereignissen wirken von außerhalb auf den Unterprozess und brechen diesen ab. Die Wirkung wird verfehlt, wenn der Unterprozess entweder noch nicht gestartet oder schon beendet ist. Die Auslöser von angehefteten Signalereignissen wirken aus dem Unterprozess heraus, an den sie angeheftet sind, oder von einer anderen Stelle her, z. B. vom Geschäftsprozess eines Kooperationspartners. Sie bewirken den Abbruch des Unterprozesses. Kommt das Signal nicht aus dem Unterprozess selbst, dann wird die Wirkung verfehlt, wenn der Unterprozess noch nicht gestartet oder schon beendet ist. Die Auslöser von angehefteten Kompensations-Ereignissen wirken meist von einer Fehlerbehandlungsroutine aus oder von einem (Unter-)Prozess aus. Eine Wirkung von außerhalb des Unterprozesses, an den das Kompensations-Zwischenereignis angeheftet ist, verfehlt seine Wirkung, wenn der Unterprozess noch nicht gestartet oder bereits beendet ist. Die Auslöser von angehefteten abbrechenden Fehler-, Abbruch- und Eskalationsereignissen wirken vom Unterprozess aus. Alle diese sendenden Zwischenereignisse werden von den entsprechenden empfangenden Zwischenereignissen registriert und von dem dort beginnenden Ausnahmefluss behandelt.

4.3.4

Warum es bestimmte angeheftete Zwischenereignisse nicht gibt

Nicht abbrechendes angeheftetes Kompensations-Ereignis (boundary non-interrupting compensation event) Im Falle einer Kompensation werden die Ergebnisse einer Aktivität rückgängig gemacht, weil sie nicht mehr benötigt werden. Eine reguläre Fortsetzung ist dann nicht mehr möglich, weshalb ein Abbruch erfolgen muss.

108

4 Ereignisse

Nicht abbrechendes angeheftetes Fehler-Ereignis (non-interrupting error event) Analoges gilt für den Fall eines Fehlers im Unterprozess. Der Unterprozess kann nicht fehlerhaft fortgesetzt werden. Die Fehlerbehandlung erfolgt, soweit möglich, im übergeordneten Prozess. In der Regel wird nach dem Schreiben von Protokoll-Informationen auch der übergeordnete Prozess beendet. Nicht abbrechendes angeheftetes Abbruch-Ereignis für eine Transaktion (non-interrupting cancel event) Im Fall des Abbruchs einer Transaktion wird ein Transaktionsmechanismus genutzt, um den Prozess auf den letzten konsistenten Zustand zurück zu setzen. Die Fortführung eines Prozesses, der sich in einem inkonsistenten Zustand befindet, macht keinen Sinn. Link-Ereignis (link event) Bei einem Link-Ereignis wird der Unterprozess an einer Stelle, z. B. auf Blatt 1, unterbrochen, um ihn an einer anderen Stelle, z. B. auf Blatt 2, fortzusetzen, d. h. die Übergabe der Steuerung an den übergeordneten Prozess würde dem Sinn des Link-Ereignisses widersprechen. Deshalb gibt es weder ein angeheftetes abbrechendes noch ein angeheftetes nicht abbrechendes Link-Zwischenereignis. Abbruch-Ereignis für einen Prozess oder Unterprozess (terminate event) Ein angeheftetes Abbruch-Zwischenereignis wird nicht benötigt, denn ein angeheftetes Ereignis ist immer ein Zwischenereignis, d. h. der Prozess wird nach einem Zwischenereignis fortgesetzt, was dem Abbruch (Termination) widersprechen würde.

4.4

Endereignisse

Bei der Modellierung von Endereignissen sollten folgende Punkte berücksichtigt werden:        

Endereignisse beenden den Prozesspfad und konsumieren eine Marke. Wenn in einem Prozess keine weitere Marke existiert, dann ist auch der Prozess als Ganzes beendet. Gehen mehrere alternative Sequenzflüsse in das Endereignis ein, werden die Marken in der Reihenfolge konsumiert, wie sie über die einzelnen Pfade ankommen. Gibt es im Prozess ein Startereignis, muss es auch ein Endereignis geben. Ist kein Endereignis vorhanden, markieren alle Flussobjekte ohne ausgehenden Sequenzfluss das Ende eines Prozesspfades. Sind alle Marken konsumiert, ist der Prozess vollständig ausgeführt und beendet. Wie der Name schon impliziert, hat das Endereignis keinen ausgehenden Sequenzfluss. Es wird mit einer dicken Kreislinie entweder blanko oder mit ausgefülltem Symbol dargestellt. Das Endereignis mit Symbol hat die gleiche auslösende Wirkung wie das auslösende Zwischenereignis – nur das hiernach der Prozess beendet ist. Endereignisse sind immer sendende Ereignisse.

Abb. 4.63 zeigt alle Endereignis-Typen im Überblick.

4.4 Endereignisse

Abb. 4.63:

109

Überblick über die Endereignisse

Unspezifiertes Endereignis (non-specified end event) Ein unspezifiziertes bzw. nicht näher spezifiziertes Endereignis symbolisiert, dass eine ankommende Marke konsumiert und der Prozess beendet wird. Wenn es wie in Abb. 4.64 zur Auftragsannahme gekommen ist und als letzte Aufgabe die Rechnung versandt wurde, fließt die in der Aufgabe „Rechnung versenden“ befindliche Marke zum Endereignis. Sie wird dort konsumiert, und der Prozess ist beendet. Nachrichten-Endereignis (message end event) Ein Nachrichten-Endereignis tritt ein, wenn eine bestimmte Nachricht versandt worden ist (Ergebnis). Der Prozess wird beendet. Das Nachrichten-Endereignis und der empfangende Teilnehmer sollten mit einem Nachrichtenfluss verbunden werden. In Abb. 4.64 wird ein Nachrichten-Endereignis verwendet. Nach dem Eintreffen des Kundenauftrages und der Analyse erfolgt entweder die Annahme oder die Ablehnung des Auftrages. In jedem der beiden Zweige folgt ein Nachrichten-Ereignis. Beim NachrichtenEndereignis ist der Prozess nach dem impliziten Versenden der Nachricht beendet.

110

Abb. 4.64:

4 Ereignisse

Verwendung des Nachrichten-Triggers als Start-, Zwischen- und Endereignis

Signal-Endereignis (signal end event) Ein Signal-Endereignis tritt ein, wenn ein Signal ausgesendet worden ist (Ergebnis). Der Prozess wird beendet. Das Signal kann über Prozessebenen und Teilnehmer hinaus von jedem empfangen werden, der dazu in der Lage ist. Das Beispiel in Abb. 4.65 zeigt, dass nach Durchführung der Wartungsarbeiten und Erstellen eines Wartungsreleases ein Signal versendet wird, dass das Wartungsrelease verfügbar ist.

Abb. 4.65:

Beispiel für ein Signal-Endereignis

Mehrfach-Endereignis (multiple end event) Ein Mehrfach-Endereignis tritt ein, wenn alle Einzel-Ergebnisse aus einer vom Modellierer festgelegten Menge von erwarteten Einzel-Ergebnissen vorliegen. Der Prozess wird beendet. In Abb. 4.66 kommen wir auf das TÜV-Beispiel aus Abb. 4.56 zurück. Wenn das Auto nicht erfolgreich durch den TÜV gekommen ist, wird der Fehler analysiert. Ist eine Reparatur nicht mehr möglich, wird gleich die Rechnung erstellt. Danach wird der Kunde informiert und die Rechnung übersandt. Der Prozess ist damit beendet.

4.4 Endereignisse

111

Abb. 4.66: Anwendung eines Mehrfach-Endereignisses

Eskalations-Endereignis (escalation end event) Ein Eskalations-Endereignis tritt ein, wenn die Notwendigkeit einer Eskalation erkannt worden ist (Ergebnis). Das Eskalations-Endereignis kann nur innerhalb eines Unterprozesses verwendet werden (vgl. Abb. 4.68). Es tritt ein, wenn die Notwendigkeit einer Eskalation erkannt wurde (Ergebnis). Es gibt zwei Möglichkeiten, an anderer Stelle im Prozess darauf zu reagieren, entweder mittels eines angehefteten Eskalations-Zwischenereignisses oder durch ein Eskalations-Startereignis in einem Ereignis-Unterprozess. Kompensations-Endereignis Ein Kompensations-Endereignis tritt ein, wenn die Notwendigkeit einer Kompensation erkannt worden ist (Ergebnis). Das folgende Beispiel Abb. 4.67 dient noch einmal der Darstellung eines KompensationsEndereignisses (siehe auch Abb. 2.7).

Abb. 4.67: Verwendung des Kompensations-Endereignisses

112

4 Ereignisse

Fehler-Endereignis (error end event) Ein Fehler-Endereignis tritt ein, wenn ein Fehler und damit die Notwendigkeit einer Fehlerbehandlung erkannt worden ist (Ergebnis). Tritt das Fehler-Endereignis ein, werden im Ergebnis alle noch aktiven Pfade im (Unter-)Prozess abgebrochen. Das Fehler-Endereignis kann innerhalb eines Unterprozesses auftreten (vgl. Abb. 4.68). Es gibt auch hier zwei Möglichkeiten, darauf zu reagieren, entweder mit Hilfe eines angehefteten Fehler-Zwischenereignisses oder mittels eines empfangenden Fehler-Startereignisses in einem EreignisUnterprozess. Transaktions-Abbruch-Endereignis (cancel event) Ein Abbruch-Endereignis in einem Transaktions-Unterprozess tritt ein, wenn die Notwendigkeit des Abbruchs einer Transaktion erkannt worden ist (Ergebnis). Das AbbruchEndereignis kann nur innerhalb eines Transaktions-Unterprozesses auftreten. Sobald eine Marke das Abbruch-Endereignis erreicht, wird die Transaktion zurückgerollt (roll back), und die Marke verlässt über das angeheftete Abbruch-Zwischenereignis den TransaktionsUnterprozess. Vgl. Erläuterungen zu Abb. 4.62. Prozess-Abbruch-Endereignis (terminate end event) Ein Prozess-Abbruch-Endereignis tritt ein, wenn eine Marke an diesem Symbol angekommen ist (Ergebnis). Alle Aktivitäten des Prozesses oder Unterprozesses werden unverzüglich beendet. Alle Marken derselben Instanz und aller weiteren Instanzen des Prozesses oder Unterprozesses werden konsumiert. Kompensationen und Fehler-Behandlungen werden nicht mehr durchgeführt. Damit werden natürlich auch alle Unter-Prozesse bzw. UnterUnter-Prozesse usw. aus Sicht des abzubrechenden Prozesses oder Unterprozesses beendet. Die Steuerung wird an den übergeordneten Prozess übergeben. Die Wirkungsweisen des Eskalations-, Fehler- und Abbruch-Endereignisses sollen am Beispiel in Abb. 4.68 erläutert werden. Der Prozess wird durch den Wunsch ausgelöst, ein Mobiltelefon mit Vertrag zu kaufen. Die Auswahl des Telefons und des passenden Tarifes erfolgen parallel (Splitten einer ankommenden Marke im Parallelen Gateway). Innerhalb des Unterprozesses „Mobiltelefon bestellen“ wird ggf. festgestellt, dass das Wunschtelefon nicht verfügbar und eine Alternative dazu nicht gewünscht ist. In diesem Fall tritt ein Fehler-Endereignis ein. Die Fehlerbehandlung beginnt mit Eintreten des an den Unterprozess angehefteten Fehler-Zwischenereignisses. Es wird Werbematerial erstellt und an den Kunden versandt, bis schließlich alle Marken aller Instanzen dieses Prozesses konsumiert werden. Damit ist der Prozess beendet. Im Unterprozess „Tarif bestellen“ ist das Alter des Käufers wegen der Dauer und Höhe der laufenden Zahlungen für den Geschäftsabschluss massgebend. Bei Käufern unter 18 Jahren tritt ein Eskalations-Endereignis ein. Auf dem Ausnahmezweig, beginnend mit dem angehefteten Eskalations-Zwischenereignis, wird auf die Notwendigkeit einer Eskalation reagiert. Über den Ausnahmefluss läuft eine Marke weiter zur Aktivität „Zustimmung des Erziehungsberechtigten einholen“. Im Ereignisbasierten Gateway wartet eine ankommende Marke auf einen Ereignis-Eintritt. Trifft innerhalb von zwei Wochen eine Ablehnung der Eltern ein oder wird die 2-Wochen-Frist überschritten, erfolgt durch das jeweilige Terminate-Endereignis der unverzügliche Abbruch des gesamten Prozesses, weil ohne die

4.4 Endereignisse

113

Zustimmung der Erziehungsberechtigten der Vertrag nicht wirksam werden kann. Trifft die Zustimmung vor Ablauf der 14 Tage ein, wird der Prozess entsprechend fortgesetzt.

Abb. 4.68:

Beispiel für die Verwendung des Eskalations-, Fehler- und Terminate-Endereignis

114

4 Ereignisse

Zusammenfassung zu Kapitel 4 



 





Ein Ereignis ist etwas, was eintritt, wie z. B. die Erfüllung einer bestimmten Bedingung, die vorher nicht erfüllt war, oder der Eingang eines Kundenauftrags. Ein Ereignis kann nur dann eintreten, wenn eine durch einen Prozess fließende Marke an dem Ereignissymbol angekommen ist. Bei einem empfangenden Start- oder einem empfangenden Zwischenereignis wird die Marke erst dann entlang des Sequenzflusses weitergereicht, wenn ein Auslöser bemerkt wurde (catch event). Bei einem sendenden Zwischenereignis wird eine ankommende Marke erst dann entlang des Sequenzflusses weitergereicht, wenn das erwartete Ergebnis vorliegt (throw event). Bei einem Endereignis wird eine ankommende Marke erst dann konsumiert, wenn das erwartete Ergebnis vorliegt. Man gliedert Ereignisse u. a. danach, ob sie eintreten, wenn ein bestimmtes Ergebnis vorliegt (throwing events), oder ob sie eintreten, wenn sie einen bestimmten Auslöser bemerken und darauf reagieren (catching events). Es hat sich ein stückweit eingebürgert, diese Ereignisse sendende bzw. empfangende Ereignisse zu nennen in Anlehnung an das Senden bzw. Empfangen einer Nachricht oder das Aussenden bzw. Empfangen eines Signals. Ein weiteres Kriterium für die Gliederung von Ereignissen ist das konkrete Ergebnis bzw. der konkrete Auslöser. Typische Ergebnisse sind: – Eine Nachricht wurde versandt. – Ein Signal wurde ausgesendet. – Ein Ergebnis aus einer Menge mehrerer möglicher Ergebnisse liegt vor. – Die Notwendigkeit einer Eskalation wurde erkannt. – Ein Fehler und damit die Notwendigkeit einer Fehlerbehandlung wurden erkannt. – Die Notwendigkeit einer Kompensation wurde erkannt. – Die Notwendigkeit des Abbruchs einer Transaktion wurde erkannt. – Der Abbruch aller Instanzen eines Prozesses wurde angestoßen. Typische Auslöser, auf die reagiert werden muss, sind: – Eine Nachricht wurde empfangen. – Ein Signal wurde empfangen. – Entweder eine definierte Frist ist abgelaufen, ein bestimmter Zeitpunkt wurde erreicht oder ein Zeitzyklus wiederholt sich. – Eine bestimmte Bedingung ist erfüllt, die vorher nicht erfüllt war. – Ein Auslöser aus einer vom Modellierer festgelegten Menge mehrerer möglicher Auslöser ist aktiviert. – Alle Auslöser aus einer vom Modellierer festgelegten Menge mehrerer möglicher Auslöser sind aktiviert. – Es besteht die Notwendigkeit einer bestimmten Eskalation. – Es besteht die Notwendigkeit einer bestimmten Kompensation. – Ein bestimmter Fehler ist aufgetreten und muss behandelt werden. – Der Abbruch eines Transaktions-Unterprozesses muss vollzogen werden. Ein weiteres Gliederungskriterium für Ereignisse ist ihre zeitliche Abfolge. Danach unterscheidet man Start-, Zwischen- und Endereignisse.

4.4 Endereignisse        

115

Startereignisse sind immer empfangende Ereignisse, Endereignisse immer sendende Ereignisse. Es gibt sowohl sendende als auch empfangende Zwischenereignisse. Zu den Startereignissen zählen die Top-Level-Startereignisse und die Startereignisse für normale und für Ereignis-Unterprozesse. Empfangende Zwischenereignisse sind Zwischenereignisse für Prozesse, normale Unterprozesse und Ereignis-Unterprozesse sowie angeheftete Ereignisse. Sendende Zwischenereignisse sind Zwischenereignisse für Prozesse, normale Unterprozesse und Ereignis-Unterprozesse. Endereignisse untergliedern sich in Endereignisse für Prozesse, normale Unterprozesse und Ereignis-Unterprozesse. Die angehefteten Zwischenereignisse untergliedern sich in solche, die den umgebenden Unterprozess abbrechen und solche, die das nicht tun. Ereignis-Unterprozesse werden in (Unter-)Prozessen definiert. Sie benötigen für ihren Start einen Auslöser. Normale Unterprozesse starten immer mit einem nicht näher spezifizierten Startereignis. Sie werden allein durch den Sequenzfluss des Oberprozesses angestoßen.

5

Artefakte, Datenobjekte und Datenspeicher

In den vorangegangenen Kapiteln wurden alle Flussobjekte (Aufgaben, Gateways, Ereignisse) behandelt. In diesem Kapitel werden die Möglichkeiten der Modellierung von Artefakten sowie von Datenobjekten und Datenspeichern erläutert. Letzteren kommt in der Geschäftsprozessmodellierung große Bedeutung zu.

5.1

Artefakte

Artefakte (artifacts) sind Informationen, Erläuterungen oder Daten, die in einem Geschäftsprozess verwendet werden können bzw. von ihm erzeugt werden, jedoch in keinem direkten Zusammenhang zum Sequenz- oder Nachrichtenfluss stehen. Es gibt drei Typen von Artefakten: Anmerkungen (text annotations), Assoziationen bzw. Verknüpfungen (associations) und Gruppierungen (groups). Artefakte dürfen weder Ausgangspunkt noch Ziel eines Sequenz- oder Nachrichtenflusses sein.

5.1.1

Anmerkungen

Anmerkungen bieten dem Modellierer die Möglichkeit, zusätzliche Informationen für den Diagramm-Nutzer zur Verfügung zu stellen. Sie werden durch eine geöffnete rechteckige Klammer dargestellt und mit einer Assoziation (ohne Pfeil) an das entsprechende Objekt angebunden. Für den Inhalt dieser Hinweise oder zusätzlichen Informationen gibt es keine Vorschriften. Die Beispiele in Abb. 5.1 zeigen mögliche Anwendungen. Anmerkungen können auch bei Schleifen oder Gateways als Bedingungen formuliert werden. Von einer Process Engine werden diese Anmerkungen jedoch nicht verarbeitet.

Abb. 5.1:

Beispiele für Anmerkungen

Grundsätzlich können alle BPMN-Elemente in dem vom Standard vorgegebenen Rahmen modifiziert werden. Bereits anhand dieses Buches sind die Darstellungsunterschiede in Schattierung, Schriftart etc. sichtbar und gewollt. Eine gute Möglichkeit, die Übersicht zu verbessern, bietet auch die farbliche Gestaltung. Entscheidend jedoch ist, dass die ursprünglichen Formen gemäß Spezifikation klar erkennbar sind. Selbst eigene Artefakte können durch den Modellierer kreiert werden. Abb. 5.2 zeigt einige Beispiele dafür.

118

Abb. 5.2:

5.1.2

5 Artefakte, Datenobjekte und Datenspeicher

Nutzerdefinierte Gestaltungsmöglichkeiten in BPMN

Assoziationen

Assoziationen werden verwendet, um Informationen oder Artefakte mit Fluss-Objekten zu verknüpfen. Die Darstellung erfolgt durch eine gepunktete Linie mit oder ohne offene Pfeilspitze und ohne einen kleinen Kreis am Beginn. Assoziationen werden auch verwendet, um eine Kompensationsaufgabe an das Kompensations-Zwischenereignis zu koppeln.

Abb. 5.3: Beispiele für Assoziationen

Zum Vergleich: Der Nachrichtenfluss ist gestrichelt dargestellt mit einer geschlossenen, nicht ausgefüllten Pfeilspitze und mit einem nicht ausgefüllten Kreis am Beginn .

5.1.3

Gruppierungen

Gruppierungen werden genutzt, um Zusammenhänge hervorzuheben. Das können z. B. inhaltlich zusammenhängende Aktivitäten oder Hervorhebungen für Analyse- und ReportingZwecke sein. Insgesamt sollen damit der Überblick und die Lesbarkeit verbessert werden. Gruppierungen können frei verwendet und selbst über Poolgrenzen hinaus gezogen werden. Sie haben keinen Einfluss auf die Prozess-Semantik. Die Gruppierung ist durch eine StrichPunkt-Linie gekennzeichnet. Das Beispiel in Abb. 5.4 zeigt die Aufzeichnung von Daten in einer Arztpraxis im Rahmen des Qualitätsmanagements. Die externe Sicherung und die Archivierung wurden als Gruppe „Aufbewahrung“ zusammengefasst. Eine Besonderheit bei der Modellierung dieses Diagramms liegt in einem Zyklus, der das Aufzeichnen der einzelnen Objekte über den ganzen Tag sicherstellen soll (in der Lane „Mitarbeiter“). Auch wenn über einen ganzen Arbeitstag kein Aufzeichnungsobjekt vorhanden ist, gerät der Prozess nicht ins Stocken, sondern wird über den Konnektor A fortgesetzt. Ein weiteres Beispiel für eine Gruppierung findet sich auch in Abb. 5.8.

5.2 Datenobjekte und Datenspeicher

Abb. 5.4:

5.2

119

Externe Datensicherung und Archivierung – zusammengefasst zur Gruppe „Aufbewahrung“

Datenobjekte und Datenspeicher

Datenobjekte (data objects) sind alle möglichen Daten in beliebiger Form und Beschaffenheit (Ausdruck auf Papier, Plastikkarten, Datensätze, Dateien, e-Mails, Briefe usw.), die zur Erfüllung einer Aufgabe benötigt oder als Ergebnis einer Aufgabe erzeugt werden. Sie werden über Daten-Assoziationen (data associations) mit oder ohne Richtung (Pfeilspitze) an die Aufgabe oder den Sequenzfluss angebunden (s. Abb. 5.5). Daten-Inputs (data inputs) und Daten-Outputs (data outputs) sind eine spezielle Form von Daten. Externe Daten, die die Voraussetzung für einen ganzen Prozess oder für einen AufrufUnterprozess bilden, werden als Daten-Input bezeichnet. Der Daten-Output wird als Ergebnis eines Prozesses oder eines Aufruf-Unterprozesses erzeugt.

120

5 Artefakte, Datenobjekte und Datenspeicher

Entsprechend wird der Daten-Input als Quelle über die Daten-Assoziationen und der DatenOutput als Ziel der Daten-Assoziation an den Prozess angebunden. Die grafische Darstellung ist die gleiche wie beim Datenobjekt – nur dass jeweils ein Blockpfeil enthalten ist, der beim Daten-Input nicht ausgefüllt und beim Daten-Output ausgefüllt ist (s. Abb. 5.5). Eine Datenobjekt-Sammlung (data object collection) stellt eine Kollektion (in Java z. B. BitSet, Vector, Stack, ArrayList, diverse Sets, PriorityQueue, Hashtable usw.) von Daten dar (s. Abb. 5.5). Datenspeicher (data stores) dienen zum Abrufen und Aktualisieren von permanent gespeicherten Daten. Es kann sich bei Datenspeichern nicht nur um Datenbanken, sondern z. B. auch um Aktenschränke usw. handeln, die unabhängig von der Prozess-Instanz existieren. Sie werden über gerichtete Daten-Assoziationen als Ausgangspunkt oder Ziel mit dem Prozess verbunden (s. Abb. 5.5).

Abb. 5.5

Modellierung von Datenobjekten und den entsprechenden Daten-Assoziationen

Abb. 5.6 links zeigt ein Beispiel für die Modellierung von Datenobjekten. Bei der gerichteten Daten-Assoziation zeigt die Pfeilrichtung an, dass die Aufgabe 1 das Datenobjekt als Output (Daten B) erzeugt und die Aufgabe 3 es als Input benötigt. Bei der rechten Darstellung handelt es sich um eine aussagegleiche, alternative Modellierung, die angewendet werden kann, wenn eine hohe Anzahl von Datenflüssen ein Diagramm unübersichtlich werden lässt. Der Output (Daten A) aus Aufgabe 2 kann direkt als Input für die Aufgabe 3 an den Sequenzfluss angekoppelt werden, da die Aufgaben unmittelbar aufeinander folgen.

5.2 Datenobjekte und Datenspeicher

Abb. 5.6:

121

Ankopplung von Datenobjekten

Daten-Assoziationen und Datenobjekte können nur innerhalb eines Pools modelliert werden. Sollen Daten mit anderen Pools ausgetauscht werden, so erfolgt dies wie in Abb. 5.7 dargestellt über Nachrichtenflüsse. Es gibt z. B. folgende Möglichkeiten, einen Zusammenhang zu Nachrichtenflüssen herzustellen: 

Über einen Nachrichtenfluss implizit ankommende Datenobjekte (hier eine Kreditanfrage) gehen mittels einer Daten-Assoziation von einer Empfangs-Aufgabe in ein Datenobjekt (hier Kreditunterlagen) ein.  Von einer Sende-Aufgabe mittels einer Daten-Assoziation ankommende Datenobjekte (hier ein Nachforderungskatalog) gehen in einen ausgehenden Nachrichtenfluss implizit ein (hier Nachforderung). Datenobjekte dürfen nicht direkt an Nachrichtenflüsse gekoppelt werden.

Abb. 5.7: Empfang und Versand von Datenobjekten

122

5 Artefakte, Datenobjekte und Datenspeicher

Abb. 5.8 zeigt einen etwas umfangreicheren Prozess einer Kreditanfrage für eine Objektfinanzierung mit Artefakten, Datenobjekten und Datenspeichern. Ein Bankkunde bekommt von einem Dritten – aus Vereinfachungsgründen nicht mit modelliert – ein Objekt zum Kauf angeboten. Sofern er sich nach Begutachtung und Auswertung für einen möglichen Erwerb entscheidet, ihm jedoch das nötige Eigenkapital dazu fehlt, sendet er eine Finanzierungsanfrage mit entsprechenden Bonitäts- und Objektunterlagen an seine Hausbank. Die eingegangenen Kundenunterlagen stellen bei der Hausbank einen Dateninput dar, welcher sich im Status „zu prüfen“ befindet. Ein Zustand wird lt. Standard durch eckige Klammern gekennzeichnet. Im Beispiel sind das die Zustände „zu prüfen“, „erzeugt“, „zu überarbeiten“ und „freigegeben“. Der Kreativität sind hier keine Grenzen gesetzt. Weitere Zustände könnten „geprüft“, „abgelehnt“ usw. sein. Die Analyse wird durch einen Bankmitarbeiter durchgeführt, der die entscheidungsrelevanten Daten erzeugt (und aufbereitet), welche allgemein als Datenobjekt dargestellt sind. Dazu können z. B. bankinterne Bonitätsratings, Bilanzanalysen, Sicherheiten-Bewertungen, der elektronische Kreditantrag und Analysen von Spezialabteilungen (für Hotel-, Schiffs-, Stadion-, Einkaufszentrumsbau etc.) gehören. Der Teamleiter, welcher über die Kreditvergabe entscheiden soll, benötigt dafür sowohl das Datenobjekt, dargestellt über die gerichtete Assoziation, als auch den formalen Kreditantrag. Genehmigt er den Kredit, so gibt er auch die Kreditdaten frei. Anschließend verfasst der Bearbeiter die Kreditzusage und legt alle Datenobjekte – ob elektronisch oder physisch – zusammen mit dem Zusage-Schreiben in der „Kundenakte“ ab. Mit dem sendenden Endereignis ist dieser Prozess beendet. Wird die Kreditvergabe abgelehnt, werden die Kreditdaten natürlich nicht freigeben. Der Kunde erhält auch in diesem Fall ein Schreiben und die Unterlagen werden abgelegt. Ist die Genehmigung des Kredites grundsätzlich denkbar, reichen dafür jedoch die Unterlagen nicht aus oder ergeben sich offene Fragen, sind – wie Abb. 5.8 zeigt – diverse Verzweigungen zu modellieren, die letztlich auch das Abbrechen des Prozesses ermöglichen, wenn der Kunde nach einer bestimmten Zeitspanne weder Unterlagen liefert noch Fragen beantwortet. Auch in diesem Fall werden die Datenobjekte permanent gespeichert. Sie stehen weiterhin zur Verfügung, auch wenn der Prozess beendet ist.

5.2 Datenobjekte und Datenspeicher

Abb. 5.8:

123

Prozess mit Datenobjekten und Datenspeicher

Abb. 5.9 zeigt im Gegensatz zu Abb. 5.8 eine Modellierung mit einem zentralen Datenspeicher, in dem sämtliche Datenobjekte gespeichert bzw. abgelegt werden und auf den alle Beteiligten in der Bank zugreifen können.

124

Abb. 5.9:

5 Artefakte, Datenobjekte und Datenspeicher

Verwendung eines zentralen Datenspeichers

5.2 Datenobjekte und Datenspeicher

125

Zusammenfassung zu Kapitel 5       





Es gibt drei Typen von Artefakten: Anmerkungen, Assoziationen und Gruppen. Artefakte haben keinen Einfluss auf den Ablauf von Geschäftsprozessen. Sie dienen lediglich dem besseren Verständnis. Anmerkungen dienen dazu, BPMN-Elemente mit Erklärungen zu versehen. Assoziationen zeigen an, auf welches Element sich eine Anmerkung genau bezieht. Gruppierungen fassen Elemente eines Diagramms durch eine Umrahmung (StrichPunkt-Linie) zusammen, um inhaltliche Bezüge herzustellen und insbesondere eine engere Zusammengehörigkeit hervorzuheben. Datenobjekte werden zur Erfüllung einer Aufgabe an eine Aktivität übergeben oder von einer Aktivität erzeugt. Bei einem Data-Input handelt es sich um Daten, die an einen Prozess übergeben werden. Diese Daten werden verarbeitet, um als Ergebnis eines Prozesses einen DataOutput zu erzeugen. Ein Datenobjekt stellt Daten zur Ausführung von Aktivitäten bereit. Diese Datenobjekte sind oft formalisierte Geschäftsdokumente wie z. B. Rechnung, Lieferschein, Kreditantrag usw. Daten existieren in Form einzelner Objekte oder auch als DatenKollektionen wie z. B. Listen oder als einzelner Wert. Datenspeicher dienen dazu, Prozessdaten persistent zu machen, d. h. sie auch über die Prozesslaufzeit hinaus noch zur Verfügung zu haben und sie in weiteren ProzessInstanzen zu nutzen. Datenspeicher können hinsichtlich ihrer Kapazität als unbegrenzt angesehen oder auch limitiert werden. Alle Daten müssen item-aware elements sein. Zum Beispiel Geschäftsdokumente im XML-Format, die nach einem gegebenen XML-Schema gültig sind, haben immer diese Eigenschaft, aus Items zu bestehen, d. h. aus einzelnen Einträgen. Ein typisches Geschäftsdokument wäre z. B. eine Rechnung mit Rechnungspositionen als Items.

6

Kollaboration, Choreographie und Konversation

Bereits im einführenden Kapitel wurden einige Ausführungen zu Kollaborationen gemacht. Es sollen hier einige weitere Aspekte behandelt werden. Eng im Zusammenhang damit stehen die Themen „Choreographie“ und „Konversation“.

6.1

Kollaboration

Eine Kollaboration (collaboration) zeigt mehrere Teilnehmer, die als Pools dargestellt werden. Die Wechselwirkung bzw. Zusammenarbeit zwischen ihnen wird über Nachrichtenflüsse modelliert. Abb. 6.1 und Abb. 6.2 stellen Kollaborations-Diagramme mit zwei Teilnehmern dar, die beide ihre Prozesse autonom steuern. Entscheidungen eines Teilnehmers beeinflussen den Prozessablauf des anderen Teilnehmers nur insoweit, dass über entsprechende Nachrichtenflüsse verschiedene Zwischenereignisse eintreten oder diverse Sende- und Empfangsaufgaben ausgeführt werden müssen. Bei der Kollaboration in Abb. 6.1 ist die Bank als Black Box Pool dargestellt. Das kann bedeuten, dass   

die Bank interne Prozesse nach außen nicht transparent darstellt oder der Bankkunde den Prozess der Bank nicht kennt, ggf. es ihn nicht interessiert oder unwichtig für ihn ist bzw. der Prozess aus vereinfachten Darstellungsgründen nicht expandiert bzw. nicht öffentlich gemacht wird.

128

Abb. 6.1:

6 Kollaboration, Choreographie und Konversation

Kollaboration mit Mehrfachteilnehmer und Black-Box Pool

In Abb. 6.2 wird die Darstellung der Zusammenarbeit der beiden Teilnehmer noch weiter vereinfacht. Es werden lediglich die auszutauschenden Nachrichten, die bei zusammengeklappten Pools immer an der Poolgrenze enden, abgebildet. Allerdings sind dadurch Abhängigkeiten, Schleifen, die Reihenfolge der Nachrichtenflüsse oder Bedingungen – wie in Abb. 5.8 beispielsweise die Absage an den Kunden wegen Fristablauf – nicht mehr sichtbar. Für eine ausgefeilte Darstellung der Ablauflogik von Nachrichtenflüssen wurden ChoreographieDiagramme eingeführt (siehe Kapitel 6.2). Die Pools – wie hier die Bank – können auch als Mehrfachteilnehmer (siehe Marker – 3 parallele Striche – an der unteren Begrenzungslinie des Banken-Pools) modelliert werden.

Abb. 6.2:

Kollaboration mit zugeklappten Pools

6.1 Kollaboration

129

BPMN unterscheidet den Nachrichtenfluss und den zu übertragenden Inhalt, der durch einen Briefumschlag bzw. Nachrichtenmarker dargestellt wird. Ob man ihn verwendet, hängt vom jeweiligen Modellierungsstil ab. Bei automatisierten Prozessen sind die Nachrichteninhalte allerdings unverzichtbar. Die Briefumschläge werden entweder direkt auf dem Nachrichtenfluss positioniert oder über eine Assoziation an ihn angekoppelt (Abb. 6.3). Dunkle Briefumschläge stellen in der Regel eine Antwort auf mit hellen Briefumschlägen modellierte Nachrichten dar. Die Symbole können mit einem Text versehen werden.

Abb. 6.3:

Nachrichtenflüsse und -inhalte

Im Beispiel in Abb. 6.4 tauschen die Teilnehmer über die Nachrichtenflüsse Informationen aus. Schwerpunkt dieses Beispiels sind Sende- und Empfangs-Aufgaben und ihr Wechselspiel, das sich in einem Zyklus wiederholen kann. Das Zusammenspiel von zwei Teilnehmern an einer Kollaboration ist hier etwas komplizierter, aber durchaus typisch für die Zusammenarbeit von Geschäftspartnern. Der Kunde eines Bildungsträgers formuliert zunächst seine Anforderungen an ein Seminar, die er daraufhin an den Bildungsträger schickt. Die Sende-Aufgabe ist durch einen ausgefüllten Nachrichtenmarker dargestellt. Mittels eines Nachrichtenflusses gelangt die Seminaranfrage zum Bildungsträger. Der Bildungsträger empfängt diese Nachricht mittels einer Empfangsaufgabe. Sie ist an dem nicht ausgefüllten Nachrichtenmarker zu erkennen. Im Bildungsträger-Prozess folgt ein Gateway, das zwei Sequenzflüsse zusammenführt und weiterleitet zu den Aufgaben „Angebot erarbeiten“ und „Angebot versenden“. Der Bildungsträger sendet sein Angebot mittels einer Sende-Aufgabe an den Kunden. Der Kunde empfängt das Angebot durch die Empfangsaufgabe „Angebot empfangen“. Jetzt muss der Kunde entscheiden, ob er das Angebot entweder so akzeptiert oder ob er zusätzlich spezifische Wünsche berücksichtigt haben möchte. Diese alternative Entscheidung wird durch ein Exklusives Gateway – siehe leerer Rhombus – realisiert. Exklusiv heißt hier ausschließend, d. h. es können nicht beide Pfade verfolgt werden, sondern entweder der Jaoder der Nein-Zweig.

130

6 Kollaboration, Choreographie und Konversation

Ist der Kunde mit dem Angebot zufrieden und hat er keine weitergehenden Wünsche, dann sendet er dem Bildungsträger eine Bestätigungsnachricht, die der Bildungsträger seinerseits empfängt. Beide Prozesse, d. h. der Kunden- und der Bildungsträger-Prozess, werden beendet. Hat der Kunde aber spezielle zusätzliche Wünsche zum Seminarangebot, dann sendet er diese an den Bildungsträger. Daraufhin wird der Sequenzfluss im Kunden-Prozess zurückgeführt zu einem zusammenführenden Gateway, wo sich ein Zyklus schließt. Der Durchlauf durch diesen Zyklus wird beendet, wenn der Kunde nach einem verbesserten Angebot des Bildungsträgers keine zusätzlichen speziellen Wünsche mehr hat. Der Bildungsträger empfängt die speziellen Wünsche des Kunden und der Sequenzfluss führt den Bildungsträgerprozess zu einem zusammenführenden Gateway, wo sich ebenso ein Zyklus schließt. Der Durchlauf durch diesen Zyklus wird beendet, wenn der Bildungsträger anstelle weiterer speziellen Wünsche eine Nachricht über die Angebotsannahme durch den Kunden erhält. Die notwendige alternative Verzweigung im Bildungsträger-Prozess wird durch ein Ereignisbasiertes Gateway realisiert – siehe Rhombus mit Symbol. Es wird derjenige Pfad gewählt, auf dem eine Nachricht eingeht, also entweder eine Annahmeerklärung oder weitere spezielle Wünsche. Die beiden Zyklen, einer im Kunden-Prozess und einer im Bildungsträger-Prozess, sind über die Nachrichtenflüsse miteinander zu einem Pool-übergreifenden Zyklus verbunden. Alternativ könnte man diesen Prozess anstelle von Sende- und Empfangsaufgaben mit Nachrichten-Zwischenereignissen modellieren. Das entsprechende BPMN-Diagramm dazu findet sich bei den Nachrichten-Zwischenereignissen im Kapitel 4.3.1. als Abb. 4.35.

Abb. 6.4:

Zyklische Kollaboration

6.2 Choreographie

131

Abb. 6.5 enthält einen Pool mit zwei Lanes, dem Aussteller eines Ursprungszertifikats, in der Regel die IHK, und einem Exporteur, der ein Ursprungszertifikat beantragt. Sowohl die IHK als auch der Exporteur müssten eigentlich als unabhängige und selbständige Organisationen und folglich als Pools dargestellt werden. Das hätte aber den Nachteil, dass man den unternehmensübergreifenden Prozess nur als Kollaboration abbilden könnte. Die beiden Geschäftspartner könnten dann nur Nachrichten miteinander austauschen, es wäre aber nicht möglich, deren Workflows in einem Prozess zu integrieren, was aber aus Sicht der Praxis wünschenswert ist. Der gemeinsame Prozess könnte – die Unabhängigkeit wahrend – auf einer singulären Process Engine ablaufen. Man bildet also ein Netzwerk kooperierender Partner, eine interessante Idee, die auf Allweyer zurückgeht – vgl. [1], S. 56.

Abb. 6.5:

6.2

Netzwerk kooperierender Partner

Choreographie

In Choreographien wird der Ablauf der Nachrichtenflüsse zwischen den Teilnehmern ähnlich wie ein Prozess dargestellt, so dass deutlich wird, welche Choreographie-Aktivitäten in welcher Reihenfolge aufeinander folgen, welche alternativen Abläufe möglich sind, welche Ereignisse den Ablauf wie beeinflussen usw. Die Choreographie ist damit eine wesentlich

132

6 Kollaboration, Choreographie und Konversation

qualifiziertere und informativere Darstellung des Nachrichtenaustauschs zwischen zwei oder mehreren Teilnehmern einer Kollaboration, als das in einer einfachen Kollaboration ohne Choreographie der Fall ist. Eine Choreographie muss im Gegensatz zur Orchestrierung eines Prozesses in einem Pool ohne zentrale Prozesssteuerung auskommen.

6.2.1

Möglichkeiten der Verwendung und Darstellung

Die Choreographie-Aktivität (choreography activity) ist der Oberbegriff für die Choreographie-Aufgabe (choreography task), den Choreographie-Unterprozess (choreography subprocess) und die Aufruf-Choreographie (call choreography). Bei Choreographien sollten folgende Punkte beachtet werden: 



      

Die jeweilige Choreographie-Aktivität wird von demjenigen Teilnehmer ausgelöst, der die erste Nachricht sendet. Er steht am oberen oder unteren Rand mit hellem Hintergrund. Der Teilnehmer, der die Nachricht empfängt, wird vor dunklem Hintergrund genannt (Abb. 6.6a). Es ist gleich, wo die Teilnehmer angeordnet sind, d. h. ob oben oder unten. Sinnvoll ist eine einheitliche Anordnung der Teilnehmer, so dass sie in Richtung der gedachten Pools zeigen. In den Abb. 6.6a-f ist demnach der Kunde immer am oberen Rand und die Bank am unteren Rand der Choreographie-Aktivität positioniert. Gruppierungen und Textanmerkungen mit Assoziationen sind darstellbar (Abb. 6.6c). Sequenzflüsse, insbesondere auch Default- und bedingte Flüsse, können modelliert werden. Es können alle Gateways verwendet werden. Es können nur bestimmte Ereignistypen als Start-, Zwischen- und Endereignisse verwendet werden. Auch können bestimmte Ereignistypen (abbrechend und nicht abbrechend) angeheftet werden. Choreographie-Aufgaben können als Mehrfach-Aufgaben parallel (Abb. 6.6a) oder sequentiell (Abb. 6.6b) bzw. als Schleife (Abb. 6.6c) modelliert werden. Es gibt auch Choreographie-Unterprozesse (Abb. 6.6d), welche auf- oder zugeklappt abgebildet werden können. Wie bereits bei den Aufruf-Aktivitäten beschrieben, können auch globale Choreographie-Aufgaben (Abb. 6.6e) oder globale Choreographie-Unterprozesse (Abb. 6.6f) dargestellt werden.

6.2 Choreographie

Abb. 6.6:

133

Möglichkeiten der Modellierung von Choreographie-Aktivitäten

Die Kollaboration aus Abb. 5.9 wird nun in Abb. 6.7 als Choreographie-Diagramm dargestellt. Der erste Nachrichtenaustausch erfolgt durch die Anfrage des Bankkunden (heller Hintergrund als Initiator) bei der Hausbank. Je nachdem, zu welchem Ergebnis die Hausbank kommt, erhält der Bankkunde entweder eine Zusage, eine Absage oder eine Nachforderung von der Hausbank (jeweils heller Hintergrund als Nachrichtensender). Schickt der Bankkunde nach drei Wochen nicht die geforderten Unterlagen, erhält er über das ZeitZwischenereignis eine Absage.

Abb. 6.7:

Choreographie zur Finanzierungsanfrage eines Bankkunden an die Hausbank

134

6.2.2

6 Kollaboration, Choreographie und Konversation

In eine Kollaboration eingebettete Choreographie

Mit BPMN besteht die Möglichkeit, eine Choreographie in eine Kollaboration einzubetten. Dabei werden die Choreographie-Aktivitäten zwischen den kollaborierenden Pools platziert und die Nachrichtenflüsse laufen durch die Aktivitäten hindurch. In einer eingebetteten Choreographie ist direkt ablesbar, wer Initiator und wer Empfänger der Nachricht ist, weshalb die Bezeichnung der Teilnehmer an der Choreographie-Aktivität entfallen kann. Das Beispiel aus Abb. 5.9 wird in Abb. 6.8 als in eine Kollaboration eingebettete Choreographie dargestellt.

Abb. 6.8:

In eine Kollaboration eingebettete Choreographie

6.3 Konversation

6.2.3

135

Choreographie-Unterprozess

Abb. 6.9 zeigt den oben dargestellten Prozess unter Verwendung eines ChoreographieUnterprozesses. Um die detaillierte Unterprozess-Darstellung zu sehen, kann der zugeklappte Unterprozess (gekennzeichnet durch das „+“) expandiert werden (Abb. 6.10).

Abb. 6.9:

Zugeklappter Choreographie-Unterprozess

Abb. 6.10:

Expandierter Choreographie-Unterprozess

6.2.4

Globale Choreographie-Aufgaben und -Unterprozesse

Wie bereits in den Kapiteln 2.3 und 2.4 dargestellt, können Aktivitäten als globale Aufgaben oder globale Unterprozesse gestaltet werden. Das gleiche Prinzip gilt auch für Choreographien. Sie werden einmalig als Globale Choreographie-Aufgabe oder als Globaler Choreographie-Unterprozess modelliert, und verschiedene Prozesse können mittels einer AufrufAktivität darauf zugreifen, d. h. sie sind mehrfach verwendbar. Die Kennzeichnung erfolgt jeweils durch eine dicke Umrandung, und der Unterprozess kann auch hier zusammengeklappt oder expandiert dargestellt werden.

6.3

Konversation

Eine Konversation (conversation) stellt eine Menge von Nachrichtenflüssen zwischen zwei oder mehreren Teilnehmern dar. Der logische Zusammenhang zwischen Nachrichtenflüssen einer Konversation kann durch einen gemeinsamen Identifikator (correlation key) hergestellt werden, z. B., wenn es sich um Nachrichtenflüsse in Bezug auf ein- und dasselbe Objekt handelt. Damit erhalten alle Nachrichtenflüsse einer Konversation u. a. einen eindeutigen Identifikator wie z. B. eine Kundennummer, Kontonummer, Auftragsnummer usw., wodurch

136

6 Kollaboration, Choreographie und Konversation

sie einer bestimmten Prozess-Instanz zugeordnet werden können. Der Workflow einer Prozess-Instanz wird immer in Bezug auf ein ganz konkretes Objekt, z. B. in Bezug auf einen bestimmten Kunden durchgeführt, der eindeutig identifiziert werden kann über seine Kunden-Nr. Die Teilnehmer bzw. Partner einer Konversation werden gemäß Abb. 6.11 links jeweils einzeln als verkleinerter Pool modelliert. Der Nachrichtenaustausch wird über eine doppelte Verbindungslinie (conversation link) zum Konversationsknoten (conversation node) dargestellt. Das Hexagon ist der Konversationsknoten. Die rechte Darstellung ist aussagegleich zur linken und eine typische Kollaboration, wo der Konversationsknoten in seine Bestandteile (Nachrichtenflüsse) aufgespaltet worden ist.

Abb. 6.11:

Nachrichtenaustauch mittels Konversation (links) und Kollaboration (rechts)

Ein Konversationsdiagramm (conversation diagram) könnte man vor diesem Hintergrund als eine vereinfachte Darstellung einer Kollaboration verstehen. Diese zusammenfassende Modellierungsform kann sinnvoll sein, wenn man komplexe Kommunikationsabläufe vereinfacht und damit übersichtlicher darstellen möchte. Somit erhält man mit einem Konversationsdiagramm eine Übersicht darüber, welche Teilnehmer gemeinsam zu welchen Themen kommunizieren bzw. daran arbeiten. Die Details können in einem Choreographie- oder Kollaborationsdiagramm ausmodelliert werden. Der Konversationsknoten in Abb. 6.12 kann folgende Ausprägungen annehmen (von oben nach unten): a) Er wird als Kommunikation (communication) bezeichnet, wenn er nicht weiter unterteilbar ist. b) Eine Konversation kann hierarchisiert werden. Dazu gibt es die Unterkonversation (subconversation). Die zweite Abb. von oben zeigt das Prinzip: Es können an einer Unterkonversation nur die Teilnehmer des übergeordneten Diagramms teilnehmen, weil nur zwischen ihnen die Kommunikation besteht. Die Unterkonversation kann z. B. in eine untergeordnete Kommunikation und eine Menge von Nachrichtflüssen (mittlere Abb.) oder komplett in Nachrichtenflüsse erweitert werden (rechte Abb.). Die HierarchieEbenen müssen über den Identifikator klar zuordenbar sein. Die Unterkonversation erhält z. B. den Identifikator „Auftrags-Nr.“. Da die Nachrichtenflüsse bei der Erweiterung in der mittleren Darstellung zur Hierarchie-Ebene der Unterkonversation gehören, wird der Identifikator „Auftrags-Nr.“ beibehalten. Die untergeordnete Kommunikation erhält einen eigenen Idendifikator, z. B. „Konto-Nr.“. Bei der weiteren Aufspaltung der untergeordneten Kommunikation im Bild rechts müssen diese Nachrichtenflüsse dann beide Identifikatoren „Auftrags-Nr.“ + „Konto-Nr.“ aufweisen. c) Eine Aufruf-Konversation ruft eine an einem anderen Ort definierte, wiederverwendbare Konversation (bzw. Kommunikation) als globale Konversation (global conversation) zur Nutzung auf. d) Eine Aufruf-Konversation ruft eine an einem anderen Ort definierte, wiederverwendbare Kollaboration auf. Die globale Konversation beinhaltet weder Knotenpunkte noch an-

6.3 Konversation

e)

137

dere Elemente. Sie ist ein beschränkter Typ der Kollaboration und besteht lediglich aus Pools und Nachrichtenflüssen mit den entsprechenden Identifikatoren. Wie bei Kollaboration und Choreographie kann auch bei der Konversation ein Mehrfachteilnehmer modelliert werden (siehe Hausbank-Pool).

Abb. 6.12:

Darstellungsmöglichkeiten des Knotenpunktes

Abb. 6.13 zeigt ein Beispiel eines Konversationsdiagramms, welches weder Prozesse innerhalb der Pools noch Choreographien zwischen den Teilnehmern enthalten darf.

Abb. 6.13:

Beispiel für ein Konversationsdiagramm

138

6 Kollaboration, Choreographie und Konversation

Zusammenfassung zu Kapitel 6 

 

   

   

Die Kollaboration ist eine Form der Zusammenarbeit zwischen zwei oder mehreren Geschäftspartnern. Diese Zusammenarbeit definiert sich im Wesentlichen über Nachrichtenflüsse zwischen den Partnern. Die Geschäftspartner werden als Pools dargestellt. Spezielle Formen der Kollaboration sind die Konversation und die Choreographie. Ein Konversationsdiagramm besteht aus Pools, Konversationen und KonversationsVerknüpfungen (Links). Konversations-Links verknüpfen Konversationen mit den beteiligten Konversationspartnern, in der Regel mit Geschäftspartnern, dargestellt als Pools. Konversationen gruppieren Nachrichtenflüsse zu Konversationsknoten und verknüpfen sie mit Pools. Es gibt Sub-Konversationen, Aufruf-Konversationen und Globale Konversationen. Eine Aufruf-Konversation dient dazu, eine globale Konversation aufzurufen. Eine Globale Konversation wird einmal angelegt und steht dann allen Kollaborationen als Baustein für die Organisation des Nachrichtenaustauschs zur Verfügung. In der Regel stellen Pools Unternehmen als Geschäftspartner oder allgemeine Partnerrollen dar wie z. B. Zulieferer, Hersteller usw. Ein Pool kann in Lanes unterteilt werden, diese wiederum in Sub-Lanes usw. Lanes werden in der Regel dazu verwendet, speziellere interne Partnerrollen zu repräsentieren. Der Ablauf der Kommunikation zwischen den Pools kann als Workflow in Form von Choreographien beschrieben werden. Sie verwenden annähernd die gleichen Elemente wie Prozesse zur Beschreibung ihrer Interaktion. Es gibt Sub-Choreographien, Aufruf-Choreographien und Globale Choreographien. Eine Aufruf-Choreographie dient dazu, eine globale Choreographie aufzurufen. Eine Globale Choreographie wird einmal angelegt und steht dann allen Kollaborationen als Baustein für die Organisation des Nachrichtenaustauschs zur Verfügung. Man kann die Prozesse von Geschäftspartnern nicht nur über Nachrichtenflüsse aufeinander abstimmen, sondern auch indem man die Geschäftspartner zu einem Netzwerk kooperierender Partner vereinigt und damit die Prozesse der Partner integriert.

7

Übungsaufgaben und Kontrollfragen

Übungsaufgaben und Kontrollfragen sind den einzelnen Kapiteln zugeordnet. Bei den Aufgaben werden die Elemente aus den vorhergehenden Kapiteln benötigt. Die angegebenen Lösungen sind als Beispiel-Lösungen zu verstehen, da es hier und da auch alternative Möglichkeiten gibt. So kann man z. B. eine Empfangsaufgabe als empfangendes NachrichtenEreignis, eine Sendeaufgabe als sendendes Nachrichten-Ereignis usw. modellieren. Wichtig ist nicht, dass Sie genau dieselbe Lösung finden, sondern dass Ihre Lösung die verbale Prozessbeschreibung exakt umsetzt. Dabei werden Sie feststellen, dass ein auch noch so sorgfältig verfasster Text nicht zwangsläufig eine nachvollziehbare und anschauliche Vorstellung von einem zu modellierenden Prozess ergibt. Ein BPMN-Diagramm ist einer verbalen Prozessbeschreibung in zwei Punkten deutlich überlegen. Erstens kann man bei einem BPMNDiagramm im Vergleich zur verbalen Beschreibung in einem Bruchteil der Zeit erfassen, wie der definierte Prozess abläuft, und zweitens sind verbale Aussagen in der Regel nicht so klar und eindeutig wie ein Diagramm. Versuchen Sie, diese Erfahrung selbst zu machen!

7.1

Übungsaufgaben

Nachfolgende Tabelle gibt Auskunft darüber, welche Kapitel man für die Lösung welcher Aufgabe durchgearbeitet haben muss. Die Lösungen finden Sie im Anschluss an die Aufgabenstellungen in Kapitel 7.2. Tab. 7.1: Überblick über die Übungsaufgaben

Aufgaben

Benötigte Kapitel

Schwerpunkte

1

1

Kollaboration

2–4

1–2

Aktivitäten

5–7

1–3

Gateways

8–18

1–4

Ereignisse

19

1–5

Datenobjekte und Datenspeicher

20–21

1–5

Artefakte

22–24

1–6

Konversation und Choreographie

Aufgabe 1: Modellieren Sie folgende vereinfachte Kollaboration zwischen zwei Geschäftspartnern: Ein Abiturient (Bewerber) bewirbt sich an einer Hochschule. Er erhält zunächst eine Eingangsbestätigung für seine Bewerbung, später entweder eine Zusage oder eine Absage. Gegebe-

140

7 Übungsaufgaben und Kontrollfragen

nenfalls werden von der Hochschule fehlende Unterlagen angefordert, die der Bewerber dann nachsendet. Die internen Prozessabläufe an der Hochschule und beim Bewerber sollen im Rahmen dieser Aufgabenstellung nicht mit modelliert werden. Beantworten Sie für sich selbst u. a. folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wie viele Teilnehmer an dieser Kollaboration gibt es? b) Wie werden Teilnehmer graphisch dargestellt? c) Welches BPMN-Element wird für die Kommunikation zwischen den an einer Kollaboration Beteiligten verwendet? Aufgabe 2: Ein PC-User wendet sich an einen Computer-Service wegen eines Software-Problems. Der Service analysiert das Problem, erarbeitet und unterbreitet dem PC-User einen Lösungsvorschlag. Der PC-User gibt danach ein Feedback, wonach der Service das Problem behebt und dem PC-User eine Fertigmeldung zukommen lässt. Damit ist der Prozess beendet. Es ist die Kollaboration darzustellen und der Service-Prozess zu modellieren. Legen Sie für alle Aufgaben einen sinnvollen Aufgabentyp fest. Wir empfehlen Ihnen, vor Beginn der Modellierung erst mal folgende Fragen zu beantworten: a) Wie viele und welche Kollaborationsteilnehmer gibt es? b) Wodurch wird der Service-Prozess ausgelöst? c) Welche Kommunikation findet zwischen den Teilnehmern statt? d) Welches BPMN-Element wird für die Kommunikation zwischen den an einer Kollaboration Beteiligten verwendet und wie könnte man diese Elemente sinnvoll bezeichnen? e) Welchen Typs sollten die Aufgaben im Service-Prozess sein? Aufgabe 3: In einer Organisationsabteilung ist eine statistische Untersuchung durchzuführen, konkret eine Durchlaufzeitenanalyse. Als erste Aufgabe ist ein statistischer Versuchsplan zu erstellen. (Der Versuchsplan legt fest, welche Daten in welchem Format vorliegen müssen, wie sie zu erfassen und aufzubereiten sind. Diese Details dienen nur der Erläuterung und sollen im Diagramm nicht mit dargestellt werden.) Nach dem Erstellen des Versuchsplans ist der Versuch durchzuführen. Die Erfassung erfolgt in einer Excel-Tabelle. Der Inhalt dieser Tabelle ist mit Hilfe eines Visual Basic Skripts in ein XML-File zu transformieren, das gegen das XML-Schema DLZ.xsd zu prüfen und ggf. zu korrigieren ist. Ausgehend von diesem XMLFile ist zunächst ein Ausreißer-Test durchzuführen, der Ausreißer ermittelt, d. h. extrem lange Durchlaufzeiten z. B. infolge einer Havarie. Danach sind die Ausreißer aus dem XMLFile zu eliminieren. Dann ist ein Anpassungstest durchzuführen. (Damit soll z. B. festgestellt werden, ob die untersuchte Grundgesamtheit einer Beta-Verteilung genügt.) Die Ergebnisse des Anpassungstests sind zu dokumentieren. Legen Sie für alle Aufgaben einen sinnvollen Aufgabentyp fest. Der Einfachheit wegen sollen die Datenobjekte nicht mit modelliert werden.

7.1 Übungsaufgaben

141

Beantworten Sie am besten erst mal folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Geht es hier um eine Kollaboration? b) Welche Geschäftseinheit soll abgebildet werden? c) Welche Aufgaben sind im Prozess vorzusehen und von welchem Typ sollten sie sein? Aufgabe 4: Erstellen Sie aus der folgenden verbalen Beschreibung eines Geschäftsprozesses der allgemeinen Rolle „Gepäckabfertigung“ ein BPMN-Diagramm: Ein Passagier (soll nicht explizit dargestellt werden) kommt am Flughafen an. Bei der Gepäckabfertigung am Flughafen wird das Handgepäck zunächst auf die zulässigen Maximalabmessungen geprüft. Wenn das Handgepäck zu groß ist, dann ist es als normales Reisegepäck aufzugeben. Das normale Reisegepäck ist zu wägen und das Gewicht auf den zulässigen oberen Grenzwert zu prüfen. Ist das Reisegepäck zu schwer, dann ist vom Reisenden eine Gebühr einzufordern. Ob zu schwer oder nicht, das Reisegepäck ist in jedem Fall mit einem Etikett zu versehen. Schließlich ist das normale Reisegepäck per Band in den Transport-, Umschlag- und Lagerraum auf den Weg zu bringen. Damit ist die Gepäckabfertigung beendet. Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wie ist eine allgemeine Partnerrolle im Unterschied zu einer spezifischen Partnerrolle in einem BPMN-Diagramm darzustellen? b) Welche Gateway-Typen sollten verwendet werden? c) Von welchem Typ sollten die einzelnen Aufgaben sein? Aufgabe 5: Erstellen Sie aus der nachfolgend gegebenen verbalen Beschreibung eines Geschäftsprozesses ein BPMN-Diagramm mit dem Schwerpunkt „Sende- und Empfangsaufgaben“: Ein Kunde formuliert seine Anforderungen an ein gewünschtes Seminar. Dann sendet er seinen Seminarwunsch an einen bestimmten Bildungsträger. Der Bildungsträger erarbeitet nach Erhalt der Anfrage ein Angebot und sendet es dem Kunden. Danach entscheidet der Kunde, ob er das Angebot entweder annimmt oder nicht. Er sendet dem Bildungsträger je nach Ergebnis entweder eine Zusage oder eine Absage. Dementsprechend empfängt der Bildungsträger entweder eine Zusage oder ein Absage. Damit sind beide Prozesse beendet. Es erscheint hilfreich, wenn Sie zunächst folgende Fragen beantworten, bevor Sie mit der Modellierung beginnen: a) Welche Teilnehmer an dieser Kollaboration gibt es? b) Wie werden Sende- und Empfangsaufgaben dargestellt? c) Wodurch wird der Bildungsträger-Prozess ausgelöst? d) Welche Nachrichten werden versendet bzw. empfangen? e) Welches Gateway sollte man verwenden, um entweder zur Aufgabe „Zusage senden“ oder zur Aufgabe „Absage senden“ zu gelangen? f) Welche Art Gateway empfiehlt sich für die Verzweigung entweder zur Aufgabe „Zusage empfangen“ oder „Absage empfangen“?

142

7 Übungsaufgaben und Kontrollfragen

Aufgabe 6: Bei dieser Aufgabe geht es um die Kollaboration zwischen einem Bewerber und einer Hochschule. Modellieren Sie den Bewerber-Prozess und verwenden Sie dafür nachfolgende Prozess-Beschreibung. Ein Bewerber erstellt eine Bewerbung um einen Studienplatz und sendet diese an eine bestimmte Hochschule. Falls notwendige Unterlagen fehlen, verlangt die Hochschule eine Nachforderung vom Bewerber. Der Bewerber sendet daraufhin die nachgeforderten Unterlagen an die Hochschule und erhält entweder eine Zusage oder eine Absage, wonach der Bewerberprozess beendet wird. Auch eine wiederholte Nachforderung von fehlenden Unterlagen soll möglich sein. Insgesamt ist die Prozess-Beschreibung aus didaktischen Gründen stark vereinfacht. Das schwierigste Modellierungsproblem ist die Fallunterscheidung, ob entweder eine Nachforderung, eine Zusage oder eine Absage beim Bewerber eingeht. Der Prozess auf Seiten der Hochschule soll nicht ausmodelliert werden. Beantworten Sie für sich selbst am besten erst mal folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Mit Hilfe welchen Gateways kann auf die Alternativen „Empfange Zusage“, „Empfange Absage“ und „Empfange Nachforderung“ reagiert werden? b) Welche Aufgaben sind zu modellieren und von welchem Aufgabentyp sollten sie sein? c) Welche Nachrichten sind zu versenden bzw. zu empfangen? d) Wie kommt ein Zyklus zustande, wenn von der Hochschule wiederholt Unterlagen nachgefordert werden, die vom Bewerber an die Hochschule gesendet werden. Aufgabe 7: Modellieren Sie einen einfachen Geschäftsprozess der allgemeinen Partnerrolle „Kunde“ nach folgender verbalen Prozess-Beschreibung: Ein Kunde empfängt eine Lieferung von N (N natürliche Zahl) Einzelteilen eines bestimmten Typs. Aus der Lieferung werden n 0 ist. Wenn nein, setzt sich der Prozess noch einmal nach dem Prüfen der Stellenausschreibung fort. Wenn ja, werden die Bewerbungen geprüft und danach wie folgt parallel abgearbeitet: Für ungeeignete Bewerber werden die Absagen verfasst und die Unterlagen mit Ablehnungsschreiben zurück gesendet. Geeignete Bewerber werden zum Gespräch bzw. Probearbeiten eingeladen. Die parallelen Zweige werden wieder zusammengeführt. Der Einfachheit wegen wird unterstellt, dass es sowohl geeignete als auch ungeeignete Bewerber gibt. Danach werden die Gespräche bzw. das Probearbeiten durchgeführt, der beste Bewerber wird ausgewählt, ein Vertrag formuliert und dieser dem Bewerber zugesandt. Wird der Vertrag nicht innerhalb von zwei Wochen vom Bewerber unterzeichnet zurückgesandt, gilt der Vertrag als abgelehnt. In diesem Fall wird mit dem nächst besten Bewerber, falls vorhanden, dasselbe Prozedere durchgeführt. Wenn kein geeigneter Bewerber mehr vorhanden ist, wird die Ausschreibung wiederholt – siehe Gruppierung. Wird die 2-Wochen-Frist eingehalten, muss in der Arztpraxis geprüft werden, ob der Bewerber den Vertrag angenommen hat. Wenn ja, wird er eingestellt (zugeklappter Unterprozess). Eine Anmerkung soll sicher stellen, dass die Personalakte angelegt und dass das Steuerbüro wegen Anmeldung bei den Ämtern informiert wird. Die übrigen Bewerber erhalten Ihre Unterlagen zurück und der Prozess ist beendet.

7.1 Übungsaufgaben

149

Wenn nicht, ist zu prüfen, ob noch geeignete Bewerber vorhanden sind, die bereits zum Vorstellungsgespräch bzw. Probearbeiten in der Praxis waren. Wenn ja, wird genauso verfahren wie mit dem besten Bewerber. Wenn nein, läuft der Prozess nach dem Prüfen der Stellenausschreibung weiter. Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Welche Teilnehmer sind an der Kollaboration beteiligt? b) Mit welchem Ereignis sollte der Prozess starten? Überlegen Sie sich alle Eigenschaften dieses Ereignisses! c) Welcher Gateway-Typ ist geeignet, die möglichen Ausschreibungsvarianten zu wählen? Hinweis: Wenigstens eine Variante muss realisiert werden. d) Welche Aufgaben sollten als Mehrfachaufgaben modelliert werden? e) Welche Teilnehmer sollten als Mehrfachteilnehmer modelliert werden? f) Mit welchem Gateway-Typ kann die Fallunterscheidung zwischen den beiden Alternativen „Empfang eines Vertragsangebots“ und „Ablauf der 2-Wochenfrist“ abgebildet werden? g) Von welchem Typ sollten die einzelnen Aufgaben sein? Aufgabe 18: Modellieren Sie die Kollaboration inkl. der Nachrichtenflüsse zwischen einem Firmenkunden und mehreren Fluggesellschaften. Der Einfachheit wegen unterstellen wir, dass die Geschäftsprozesse bei allen Fluggesellschaften gleich ablaufen. Der Firmenkunde spezifiziert nach dem Start des Prozesses zunächst einen Flug. Danach wird automatisch der Status der Reisenden geprüft. Danach verfasst ein Firmenmitarbeiter eine Angebotsanfrage, die sodann an mehrere Fluggesellschaften gesendet wird. Nachfolgend empfängt der Firmenkunde entweder ein Angebot oder eine Absage von jeder Fluggesellschaft. Nach einer 2-Tagesfrist wird die Empfangsaufgabe abgebrochen. Danach wird geprüft, ob es wenigstens 1 Angebot gibt. Wenn nein, dann stellt sich die Frage, ob ein alternativer Flug spezifiziert werden soll, wenn nein, dann ist der Prozess beendet. Wenn ja, ist zur Aufgabe „Flug spezifizieren“ zurück zu kehren. Wenn die Anzahl der Angebote größer als Null ist, dann werden die Angebote geprüft und das beste Angebot wird ausgewählt. Danach wird der ausgewählten Fluggesellschaft eine Buchungszusage zugesandt. Danach empfängt der Firmenkunde noch die Flugunterlagen (Flugticket und Rechnung) von der Fluggesellschaft und der Prozess ist zu Ende. Die Fluggesellschaften starten ihren Prozess, wenn eine Fluganfrage eingeht. Jede einzelne Fluggesellschaft prüft und entscheidet, ob sie ein Angebot abgeben wird. Wenn nein, dann wird eine Absage verfasst und versendet. Danach wird der Zweig beendet. Wenn ja, dann wird ein Angebot verfasst und versendet. Geht die Buchungszusage des Firmenkunden nicht innerhalb von zwei Tagen ein, beendet die Fluggesellschaft ihren Geschäftsprozess. Geht sie vor Fristablauf ein, wird der Flug gebucht und die Kreditkarte belastet. Mit dem Senden des Flugtickets und der Rechnung an den Firmenkunden geht der Fluggesellschaftsprozess zu Ende. Entscheiden Sie selbst, welche Aufgabentypen für die einzelnen Aufgaben geeignet sind. Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Welche Teilnehmer bzw. Beteiligte, die durch einen Pool darzustellen sind, gibt es in der Kollaboration?

150

7 Übungsaufgaben und Kontrollfragen b) Welche Aufgaben müssen als Mehrfachaufgaben deklariert werden und welche Nuance gibt es dabei? c) Welche Aufgabe sollte als sequentielle Mehrfachaufgabe dargestellt werden? d) Welche Aufgaben müssen als parallele Mehrfachaufgaben modelliert werden? e) Welche Teilnehmer müssen Mehrfachteilnehmer sein? f) Durch welches Symbol werden Mehrfachteilnehmer gekennzeichnet?

Aufgabe 19: Stellen Sie sich vor, ein Eigentümer (Vermieter) eines Vermietungsobjektes sucht eine geeignete Hausverwaltung für sein Objekt. Bilden Sie den Prozess für beide Teilnehmer nach folgender Prozessbeschreibung in einem BPMN-Diagramm ab. Die Aufgabe ist vergleichsweise schwierig und aufwendig. Falls Sie nicht direkt zum Ziel kommen, dann studieren Sie am besten die Beispiel-Lösung und versuchen danach, diese Lösung zu rekonstruieren oder eine ähnliche Lösung zu entwickeln. Im Eigentümer-Prozess sind nacheinander zunächst zwei Aufgaben zu erledigen, das Auswählen einer Hausverwaltung und das Versenden einer Anfrage und von Objektunterlagen an die Hausverwaltung. Danach verzweigt der Prozess in Abhängigkeit davon, welches der folgenden beiden Ereignisse zuerst eintritt: Entweder a) Empfangen einer Ablehnung von der Hausverwaltung oder b) Empfangen eines Vertrages und einer Vollmacht für die Hausverwaltung. Im Fall a) geht der Sequenzfluss zurück zur Aufgabe „Hausverwaltung auswählen“. Da nun zwei Sequenzflüsse in diese Aufgabe einmünden, wäre es guter Stil, diese vor der Aufgabe zusammenzufassen. Im Fall b) werden Vertrag und Vollmacht vom Eigentümer unterzeichnet und danach an die Hausverwaltung zurückgesandt. Weiter folgen im Fall b) die Aufgaben „Verwaltungsunterlagen empfangen“ und „Unterlagen prüfen und ablegen“. Damit ist der Prozess zu Ende. Im Eigentümer-Prozess werden folgende Daten in einem Datenspeicher abgelegt: Anfrage, entweder Ablehnung oder Vertrag und die HV-Unterlagen (HV = Hausverwaltung). Von der Aufgabe „Verwaltungsunterlagen empfangen“ zur Aufgabe „Unterlagen prüfen und ablegen“ wird das Datenobjekt „HV-Unterlagen“ weiter gereicht. Das Datenobjekt befindet sich im Status „zu prüfen“. Der Hausverwalter-Prozess startet mit dem Eingang der Anfrage vom Eigentümer, gefolgt von einem Unterprozess „Übernahme der Hausverwaltung (HV) prüfen“. Für die Aufgabe gibt es einen Data Input „Objektunterlagen und Anfrage“. Auf den Unterprozess „Übernahme der Hausverwaltung (HV) prüfen“ folgt eine alternative Verzweigung. Wenn die Hausverwaltung den Verwaltungsauftrag nicht übernimmt, dann wird eine Ablehnung an den Eigentümer versandt, und der Zweig wird beendet. Wenn die Hausverwaltung den Auftrag übernimmt, dann geht es wie folgt weiter. Zunächst werden ein Vertrag und eine Vollmacht verfasst. Dafür wird das Datenobjekt „HV-Daten“ aus dem vorgelagerten Unterprozess übernommen. Anschließend werden Vertrag und Vollmacht an den Eigentümer versandt. Danach sendet der Eigentümer den Vertrag und die Vollmacht unterschrieben an die Hausverwaltung zurück. Nach Eingang erstellt die Hausverwaltung Unterlagen für den Eigentümer in einem Unterprozess. Der Output dieses Prozesses sind die „Verwaltungsunterlagen für Vermieter“. Der Prozess endet damit, diese Verwaltungsunterlagen an den Eigentümer zu senden. In der Aufgabe „Vertrag und Vollmacht verfassen“ werden „HV-Daten und Schriftwechsel“ in einem Datenspeicher abgelegt. In der Aufgabe „Vertrag und Vollmacht empfangen“ werden Vertrag und Vollmacht im Datenspeicher abgelegt. In der Aufgabe „Unterlagen für Vermieter anfertigen“ werden Daten vom Datenspeicher gelesen und in den Datenspeicher geschrie-

7.1 Übungsaufgaben

151

ben. Entscheiden Sie selbst, welche Aufgabentypen für die einzelnen Aufgaben besonders geeignet sind. Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wie werden in BPMN Datenobjekte dargestellt? b) Wie werden in BPMN Datenspeicher abgebildet? c) Welche Inputs und Outputs sollten dargestellt werden? d) Wie werden Inputs symbolisiert? e) Wie werden Outputs abgebildet? f) Wie können Daten-Inputs und Daten-Outputs mit Aktivitäten verknüpft werden? g) Welche Datenobjekte sollten abgebildet werden? h) Wie werden Datenobjekte symbolisiert? i) Wie werden Datenobjekte mit Aktivitäten verknüpft? j) Mit welchem Symbol wird das Speichern von Daten in einen Datenspeicher modelliert? k) Wie wird das Abfragen von Daten und Übertragen von Daten aus einem Datenspeicher an eine Aktivität dargestellt? l) Mit welchem Gateway-Typ kann die notwendige Fallunterscheidung im Eigentümer-Prozess realisiert werden? Aufgabe 20: Erstellen Sie aus der nachfolgenden verbalen Beschreibung eines Geschäftsprozesses ein BPMN-Diagramm. Im zu modellierenden Prozess geht es um die Business Unit „Hypothekenbank“. Der Prozess „Antrag auf Gewährung eines Darlehens“ startet, wenn von einem (potentiellen) Kunden ein Antragsformular bei der Hypothekenbank angefordert wird. Fügen Sie dem Startereignis eine geeignete Anmerkung hinzu. Die erste Aufgabe ist es, dem potenziellen Antragsteller ein Antragsformular nebst Erläuterungen zuzusenden. Nach dieser Aktivität soll der Zustand konstatiert werden, dass ein Zähler für die Anzahl Mahnungen bzw. Erinnerungen beim Eintritt in einen nachfolgenden Zyklus den Wert 0 hat. Dieser Zustand soll erläutert werden. An dieser Stelle verzweigt der Prozess in einen Zweig A und in einen Zweig B. Der Zweig A enthält einen Zyklus, der sich unmittelbar nach dem Parallelen Gateway schließt. Im Zyklus wird alle 7 Tage geprüft, ob der Darlehensantrag des Kunden eingetroffen ist. Wenn ja, dann ist der Zweig A zu beenden. Wenn nein, sollen max. 2 Erinnerungen an den (potentiellen) Kunden gesendet werden. Nach den 2 Erinnerungen soll der Kundenkontakt abschließend archiviert werden. Danach ist der gesamte Geschäftsprozess (nicht nur der Zweig A) zu beenden. Wenn bisher weniger als 2 Erinnerungen versandt wurden, dann ist der Wiederholungszähler um 1 zu erhöhen und eine Erinnerung an den (potentiellen) Kunden zu schicken. Der Zyklus wird geschlossen. Im Zweig B wird das Ereignis „Darlehensantrag eingetroffen“ erwartet. Ist dieses Ereignis eingetreten, dann folgen zwei Aufgaben. Die erste soll die Kreditwürdigkeit des Kunden prüfen und die zweite soll entscheiden, ob ein Kreditangebot unterbreitet werden soll oder nicht. Mit Hilfe einer Verzweigung sollen 2 Fälle unterschieden werden. Entweder wird dem Kunden ein Angebot unterbreitet oder eine Absage erteilt. Die beiden alternativen Zweige sind wieder zusammenzuführen. Danach ist darzustellen, dass der Geschäftsprozess beendet ist.

152

7 Übungsaufgaben und Kontrollfragen

Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wie kann der notwendige Zyklus gestaltet werden? b) Wie kann sichergestellt werden, dass der Zyklus maximal zweimal durchlaufen wird, wenn bei der Hypothekenbank zwischenzeitlich kein Darlehensantrag eingeht? c) Mit welchem Endereignistyp müssen die einzelnen Prozesszweige abgeschlossen werden und warum? d) Wie kann die Wiederholungsfrist von 7 Tagen berücksichtigt werden? Aufgabe 21: Die Aufgabe besteht in der Modellierung eines Sterilisationsprozesses entsprechend den Qualitätsmanagement-Anforderungen an eine Arztpraxis (Pool). Alle sterilisationsfähigen Instrumente und Hilfsmittel in einer Arztpraxis sind zu sterilisieren. Der Prozess soll jederzeit ohne spezifischen Auslöser gestartet werden können. Zunächst werden alle sterilisationsfähigen Instrumente und Hilfsmittel in einem Sammelbehälter gesammelt. Danach beginnt das Desinfizieren mit folgendem Ablauf: Die Instrumente werden unter fließendem Wasser in einem Behälter oder Becken grob gereinigt (Beachte: zerlegter Zustand der Instrumente). Danach werden sie in einem vollständig gefluteten Sterilisationsbad desinfiziert (Beachte: Dauer der Sterilisation und verwendetes Mittel für jeweiliges Instrument). Anschließend müssen die Hände desinfiziert werden. In der Folge ist die Sauberkeit der Instrumente nach deren Trocknung visuell zu prüfen. Sind die Teile optisch nicht sauber, werden sie wieder in den Sammelbehälter gelegt. Sind sie optisch in Ordnung, beginnt der Sterilisationsvorgang mit folgendem Ablauf: Zunächst sind die Instrumente danach zu unterscheiden, ob eine Verpackung erforderlich ist oder nicht. Wenn ja, sind die Teile zuerst zu verpacken und dann mit den anderen Instrumenten zu sterilisieren (Herstellervorgaben sind zu beachten). Danach ist das Ergebnis zu prüfen (Nach der Abkühlung: Hat der Sporenteststreifen farbliche Veränderungen? Sind verpackte Teile dicht?). Gibt es nach der Ergebnisprüfung Mängel und sind nur einzelne Teile nicht steril, sind diese wieder in den Sammelbehälter zu legen. Sind alle Teile mangelhaft, muss die Praxisleitung eingebunden und das Problem gelöst werden (Hinweis: ggf. Sterilisationsgerät warten lassen oder ersetzen). Die Ergebnisse aus der Einbindung der Praxisleitung und aus der Prüfung des Sterilisationsergebnisses sind zu dokumentieren (Wie? Ausfüllen einer Sterilisations-Checkliste). Zum Abschluss wird die Sauberkeit der Anlage hergestellt und danach ist der Prozess beendet. Versuchen Sie durch eine sinnvolle Gruppierung das Diagramm übersichtlich zu gestalten. Arbeiten Sie ggf. mit Konnektoren. Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wozu dienen Gruppen bzw. Gruppierungen? b) Wie werden Gruppierungen graphisch dargestellt? c) Wie könnten Gruppierungen im zu modellierenden Prozess aussehen? d) Wie werden Anmerkungen dargestellt? e) Wie können Anmerkungen mit Flussobjekten verknüpft werden? Aufgabe 22: Eine Brauerei hat Ihre Informationsverarbeitung durch Outsourcing an einen externen ITDienstleister übertragen. Sie liefert täglich Ist-Produktionsdaten an den IT-Dienstleister.

7.1 Übungsaufgaben

153

(Diese Daten werden benutzt, um eine Trendanalyse sowie eine Analyse periodischer Schwankungen durchzuführen. Der Vorsagewert für zehn Arbeitstage wird unter Verwendung weiterer Informationen, z. B. Fest- und Feiertage korrigiert.) Auch die Wetterdaten gehen in diese Korrektur ein. Die Wetterdaten bezieht der IT-Dienstleister vom Wetterdienst. Erstellen Sie ein Konversationsdiagramm für die drei beteiligten Teilnehmer an der Konversation. Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wie werden Kollaborations-Teilnehmer in einer Konversation dargestellt? b) Wie werden in BPMN Konversationsknoten abgebildet? c) Wie werden Konversationsknoten und Teilnehmer miteinander verbunden? d) Welche Teilnehmer und welche Konversationsknoten sind im Diagramm darzustellen? Aufgabe 23: Ein Kunde wendet sich an einen Bildungsträger, nachdem er seine Anforderungen an ein gewünschtes Seminar formuliert hat. Er sendet seinen Seminarwunsch an den Bildungsträger. Der Bildungsträger erarbeitet nach Erhalt der Anfrage ein Angebot und sendet es dem Kunden. Der Kunde hat möglicherweise in Bezug auf das Angebot ergänzende spezielle Wünsche. Wenn ja, denn wendet er sich mit seinen zusätzlichen speziellen Wünschen an den Bildungsträger, der daraufhin ein (präzisiertes) Angebot sendet usw. Wenn nein, dann nimmt der Kunde das Angebot an und teilt das dem Bildungsträger mit. Damit sind beide Prozesse beendet. Entwickeln Sie zu obiger Beschreibung einer Kollaboration eine Choreographie! Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wie werden in BPMN Choreographie-Aufgaben symbolisiert? b) Wodurch wird in einer Choreographie-Aufgabe angezeigt, welcher Teilnehmer eine Nachricht sendet und wer sie empfängt? c) Mit welchem Gateway-Typ kann die notwendige alternative Verzweigung abgebildet werden? d) Welche Choreographie-Aufgaben müssen im Diagramm dargestellt werden? Aufgabe 24: In der Ausgangssituation (siehe Abb. 7.1) gibt es zwei Prozess-Definitionen, zum Ersten für den Teilnehmer „Brauerei“ und zum Zweiten für den Teilnehmer „IT-Dienstleister“. Die Zusammenarbeit bzw. Kollaboration zwischen beiden erfolgt mittels Nachrichtenaustausch. Bei diesem Austausch gibt es ereignisbasierte und datenbasierte Verzweigungen sowie eine Parallelisierung, die in dem angegebenen Kollaborationsdiagramm nicht sichtbar wird. Zur Präzisierung der Abläufe des Nachrichtenaustauschs soll das angegebene Diagramm um eine eingebettete Choreographie ergänzt werden. Modellieren Sie mit Ihrem Tool zunächst die Ausgangssituation entsprechend Abb. 7.1 und nutzen Sie dann, wenn Sie die beiden Prozesse und ihre Kommunikationsbeziehungen durchdacht haben, die nachfolgende verbale Beschreibung der Choreographie, um sie im Diagramm zu ergänzen. Hinweis: Die Choreographie ergibt sich bereits aus dem Kollaborationsdiagramm in Abb. 7.1. Sie könnten also versuchen, ohne die nachfolgende verbale Choreographie-Beschreibung auszukommen.

154

Abb. 7.1:

7 Übungsaufgaben und Kontrollfragen

Kollaboration – Ausgangssituation zu Aufgabe 24

7.1 Übungsaufgaben

155

Die Choreographie beginnt mit einem Startereignis, gefolgt von einem zusammenführenden Gateway, das dazu dient, zwei Zyklen zu schließen. Weitere Informationen hierzu an gegebener Stelle. Die erste Choreographie-Aufgabe besteht darin, die Tagesmeldung der Produktionsdaten von der Brauerei an den IT-Dienstleister weiterzuleiten. Die zweite Choreographie-Aufgabe besteht darin, eine vom IT-Dienstleister erstellte 2Wochen-Prognose für den Bierverbrauch an die Brauerei weiterzuleiten. An dieser Stelle ist zu prüfen, ob der Vertragszeitraum abgelaufen ist, wenn nein, dann ist der erste Zyklus zu schließen und mit der o. g. ersten Choreographie-Aufgabe fortzusetzen. Wenn ja, d. h., wenn der Vertragszeitraum noch nicht abgelaufen ist, dann verzweigt der Sequenzfluss in zwei parallele Zweige A und B. Im Zweig A sorgt ein ereignisbasiertes Gateway dafür, dass jeweils durch eine Choreographie-Aufgabe entweder eine Absage der Brauerei an den IT-Dienstleister (keine Vertragsverlängerung seitens der Brauerei) oder eine Zusage der Brauerei an den IT-Dienstleister weitergeleitet wird (Vertragsverlängerung seitens der Brauerei). Wurde von der Brauerei eine Absage erteilt, dann ist die Choreographie zu Ende. Im Zweig B sorgt ein ereignisbasiertes Gateway dafür, dass jeweils durch eine Choreographie-Aufgabe entweder eine Absage des IT-Dienstleisters an die Brauerei (keine Vertragsverlängerung seitens des IT-Dienstleisters) oder eine Zusage des IT-Dienstleister an die Brauerei weitergeleitet wird (Auftragsverlängerung seitens des IT-Dienstleisters). Wurde vom IT-Dienstleister eine Absage erteilt, dann ist die Choreographie zu Ende. Wenn beide Partner einer Vertragsverlängerung zugestimmt haben, werden diese Zweige zusammengeführt und der zweite Zyklus geschlossen, wobei mit der Choreographie-Aufgabe „Tagesmeldung etc.“ fortgesetzt wird. Beantworten Sie für sich selbst folgende Fragen, bevor Sie mit der Modellierung beginnen: a) Wie werden Nachrichtenflüsse mit Choreographie-Aufgaben verknüpft? b) Welche Fallunterscheidungen sind zu treffen und mit welchem Gateway-Typ können sie realisiert werden? c) Welche Choreographie-Abläufe sind wie zu parallelisieren? d) Welche Zyklen sind vorzusehen?

156

7.2

7 Übungsaufgaben und Kontrollfragen

Beispiel-Lösungen

Beispiel-Lösung zu Aufgabe 1:

Abb. 7.2:

Kollaboration zwischen zwei Geschäftspartnern

Beispiel-Lösung zu Aufgabe 2:

Abb. 7.3:

Kollaboration zwischen zwei Teilnehmern mit verschiedenen Aufgabentypen

7.2 Beispiel-Lösungen Beispiel-Lösung zu Aufgabe 3:

Abb. 7.4:

Anwendung unterschiedlicher Aufgabentypen im Rahmen einer Durchlaufzeitanalyse

Beispiel-Lösung zu Aufgabe 4:

Abb. 7.5:

Anwendung von Manueller und Benutzer-Aufgabe im Rahmen der Gepäckabfertigung

Beispiel-Lösung zu Aufgabe 5:

Abb. 7.6:

Schwerpunkte: Sende- und Empfangsaufgaben sowie die Verwendung verschiedener Gateways

157

158

7 Übungsaufgaben und Kontrollfragen

Beispiel-Lösung zu Aufgabe 6:

Abb. 7.7:

Kollaboration von zwei Geschäftspartnern mit Zyklus

Beispiel-Lösung zu Aufgabe 7:

Abb. 7.8:

Anwendung des XOR-Gateways und Verwendung von Konnektoren

Hinweis: Das sendende und das empfangende Verknüpfungsereignis (jeweils zwei konzentrische Kreise mit einem ausgefüllten bzw. nicht ausgefüllten Pfeil innen) werden hier lediglich zum Erhalt kleiner Abmessungen des Diagramms verwendet. Diese Ereignisse sind also

7.2 Beispiel-Lösungen

159

verzichtbar, so dass man die Aufgabe mit den Elementen aus den Kapiteln 1 bis 3 lösen kann. Das Verknüpfungsereignis ist auch nicht wirklich ein Ereignis, sondern es ist im Wesentlichen ein Konnektor. Hinweis zu den Aufgaben 7 und 9: Die Aufgaben „Empfange Warenlieferung“ (Abb. 7.8) und „Ware versenden“ (Abb. 7.10) werden nicht als Empfangs- bzw. Sende-Aufgaben modelliert, weil damit streng genommen nur elektronische Nachrichtenflüsse dargestellt werden können. Solange der Prozess nicht automatisiert wird, könnte man die Aufgaben „Empfange Warenlieferung“ und „Ware versenden“ auch als Empfangs- bzw. Sende-Aufgaben durchgehen lassen. Beispiel-Lösung zu Aufgabe 8:

Abb. 7.9:

Schwerpunkt: Anwendung des Parallelen Gateways und Angehefteter Ereignisse

Beispiel-Lösung zu Aufgabe 9:

Abb. 7.10:

Schach-Versandhandel, Variante I; Schwerpunkt: Ereignisse

160

7 Übungsaufgaben und Kontrollfragen

Beispiel-Lösung zu Aufgabe 10:

Abb. 7.11:

Schwerpunkt: Unterprozesse und Kompensation

7.2 Beispiel-Lösungen Beispiel-Lösung zu Aufgabe 11:

Abb. 7.12:

Schwerpunkt: Endereignisse

Beispiel-Lösung zu Aufgabe 12:

Abb. 7.13:

Schachversandhandel, Variante II; Schwerpunkt: Transaktion, Kompensation

161

162

7 Übungsaufgaben und Kontrollfragen

Hinweis zu Aufgabe 12, Abb. 7.13: Erreicht eine Marke das Abbruch-Endereignis, wird der Prozess durch die Transaktion auf den letzten konsistenten Zustand zurückgesetzt. Das bedeutet, dass die zweite vorhandene Marke, welche durch den Parallel-Split erzeugt wurde, konsumiert wird. Das Terminate-Endereignis wirkt sich nicht auf höhere Prozessebenen aus. Beispiel-Lösung zu Aufgabe 13:

Abb. 7.14:

Schwerpunkt: Prozessgestaltung mit Zyklus und Datenobjekten

Beispiel-Lösung zu Aufgabe 14:

Abb. 7.15:

Schwerpunkt: Ereignisse

7.2 Beispiel-Lösungen Beispiel-Lösung zu Aufgabe 15:

Abb. 7.16:

Schwerpunkt Mehrfach-Teilnehmer und Mehrfach-Aufgabe, Ereignisse

163

164

7 Übungsaufgaben und Kontrollfragen

Beispiel-Lösung zu Aufgabe 16:

Abb. 7.17:

Modellieren mit mehreren spezifischen Partnerrollen

7.2 Beispiel-Lösungen Beispiel-Lösung zu Aufgabe 17:

Abb. 7.18:

Mehrfach-Teilnehmer und Mehrfach-Aufgabe, verschiedene Gateway-Typen, Gruppierung

165

166

7 Übungsaufgaben und Kontrollfragen

Beispiel-Lösung zu Aufgabe 18:

Abb. 7.19:

Kollaboration mit Mehrfach-Teilnehmer und Mehrfach-Aufgabe

7.2 Beispiel-Lösungen Beispiel-Lösung zu Aufgabe 19:

Abb. 7.20:

Schwerpunkt: Datenobjekte und Datenspeicher

167

168

7 Übungsaufgaben und Kontrollfragen

Beispiel-Lösung zu Aufgabe 20:

Abb. 7.21:

Darstellung von „Zuständen“ mit dem unspezifizierten Zwischenereignis

7.2 Beispiel-Lösungen Beispiel-Lösung zu Aufgabe 21 – 2 Varianten:

Abb. 7.22:

Schwerpunkt: Prozessgestaltung mit Gruppierungen; Variante 1 ohne Verknüpfungsereignisse

169

170

Abb. 7.23:

7 Übungsaufgaben und Kontrollfragen

Schwerpunkt: Prozessgestaltung mit Gruppierungen; Variante 2 mit Verknüpfungsereignissen

Beispiel-Lösung zu Aufgabe 22:

Abb. 7.24:

Konversationsdiagramm zwischen drei Geschäftspartnern

Beispiel-Lösung zu Aufgabe 23:

Abb. 7.25:

Choreographie mit zwei Teilnehmern

7.2 Beispiel-Lösungen Beispiel-Lösung zu Aufgabe 24:

Abb. 7.26:

Eingebettete Choreographie

171

172

7 Übungsaufgaben und Kontrollfragen

7.3

Kontrollfragen mit Antworten

Es wird hier und da nicht ganz einfach sein, die Fragen zu beantworten. Deshalb erscheint es sinnvoll, sich beim ersten Mal die Antworten anzusehen, bei Wiederholungen die Antworten abzudecken und dann mehr und mehr ohne Hilfen auszukommen. Wenn sich ein Leser bereits tiefergehend mit BPMN beschäftigt hat, dann wird er feststellen, dass die Diagramme eine Vereinfachung der tatsächlichen präzisen Semantik darstellen. Alle Antworten werden in der Sprache von Business Analysten gegeben und nicht in der präziseren und vollständigeren, aber damit leider auch komplizierteren Terminologie von Informatikern, denn die Adressaten des Buches sind Betriebswirte, Wirtschaftsingenieure und Wirtschaftsinformatiker. Letztere müssen sich zusätzlich natürlich auch mit den technischen Details befassen, wofür wir den Standard, insbesondere die Klassendiagramme und das XML-Schema semantic.xsd empfehlen.

7.3.1

Zu Kapitel 1 Einführung

1.

Welche Eigenschaften hat ein Geschäftsprozess? Ein Geschäftsprozess hat einen Beginn und ein Ende, und er enthält koordinierte Aktivitäten (Aufgaben und Unterprozesse), wobei die Aufgaben atomar sind. Es können Verzweigungen und Zusammenführungen sowie Ereignisse auftreten, die den Ablauf beeinflussen. Ein Geschäftsprozess ist planbar und steuerbar, er verbraucht Ressourcen und Zeit und damit Kosten. Ziele und Verantwortlichkeiten sollten festgelegt sein.

2.

Worin besteht der Unterschied zwischen Planung und Steuerung? Eine Prozessdefinition (BPMN-Diagramm) beschreibt den Plan-Ablauf. Über den BPMN-Standard hinausgehend werden für Aktivitäten Bearbeitungszeiten vorgeben, z. B. für die Bearbeitung eines Bauantrags. Wird die geplante Zeitvorgabe nicht eingehalten, dann wird mit geeigneten Steuerungsmaßnahmen versucht, den Ist-Verlauf an den Plan-Verlauf anzupassen. Das könnte z. B. durch einen erhöhten Ressourceneinsatz gelingen.

3.

Welche Reifegrade haben Geschäftsprozesse nach dem CMM-Modell? Initial, repeatable, defined, managed und optimizing.

4.

An welchen Anforderungen macht man fest, welchen Reifegrad ein Prozess nach dem CMM-Modell erreicht hat? Ein höheres Level setzt immer die Erfüllung der Anforderungen für die geringeren Level voraus. – 1 initial Individuelle Anstrengungen, die zum Erfolg führen. – 2 repeatable Quick and dirty, aber nachvollziehbare Aufzeichnungen. – 3 defined Geschäftsprozesse dokumentiert, standardisiert und integriert. – 4 managed Kennzahlensystem. – 5 optimizing Kontinuierlicher Verbesserungsprozess. Welches Strukturierungsmittel verwendet BPMN für komplexe Geschäftsprozesse? Unterprozesse.

5.

7.3 Kontrollfragen mit Antworten 6.

7.

8.

173

Welche Nutzenpotenziale hat BPMN? – Verständliche Definition und Dokumentation von Prozessen für die tägliche Anwendung und zur Orientierung von Managern und Mitarbeitern, – Steigerung der Effizienz durch Vermeidung von Mehrfach-Arbeit und Definition klarer Zuständigkeiten und Abläufe, – Optimierung von bestehenden Prozess-Definitionen ggf. unter IT-Einsatz zum Zweck der (Teil-) Automatisierung der Ausführung von Prozess-Instanzen, – Erfüllung von Anforderungen an das Qualitätsmanagement im Rahmen von Zertifizierungen, – Mit BPMN als weltweitem Standard bestehen gute Möglichkeiten der Definition des globalen Zusammenwirkens mit Geschäftspartnern. Welche fünf grundlegenden Kategorien von BPMN-Elementen gibt es? – Flussobjekte – Verbindende Objekte – Daten – Artefakte – Swimlanes. Welche Elementtypen gehören zu den einzelnen Kategorien? – Flussobjekte (Aktivitäten, Gateways, Ereignisse) – Verbindende Objekte (Sequenzfluss, Datenfluss, Assoziation, Datenassoziation) – Daten (Datenobjekt, Daten In- und Output, Datenspeicher) – Artefakte (Anmerkungen, Assoziationen, Gruppen) – Swimlanes (Pools und Lanes) Die Assoziationen (Verknüpfungen) werden bewusst zweimal genannt, weil sie sowohl zu den verbindenden Objekten als auch zu den Artefakten gehören.

9.

Was repräsentieren Pools? – Business Units oder Organisationen, z. B. eine Hypothekenbank, häufig als Teilnehmer an einer Kollaboration, – Allgemeine Partnerrollen, z. B. Akademisches Auslandsamt. 10. Was repräsentieren Lanes? Spezifische Partnerrollen, z. B. Projektleiter, IT-Koordinator, Personalabteilung. 11. Welcher Zusammenhang besteht zwischen Pools und Lanes? In einem BPMN-Diagramm kann ein Pool in Lanes unterteilt werden, ein Lane in SubLanes usw. 12. Können Pools und Lanes gegensätzlich angeordnet werden (z. B. Pool horizontal, Lanes vertikal)? Nein. 13. Was ist unter einem Sequenzfluss zu verstehen? Der Sequenzfluss legt die Reihenfolge von Fluss-Objekten (Aktivitäten, Gateways und Ereignissen) fest. Jeder Sequenzfluss hat eine Quelle, z. B. ein Startereignis, und eine Senke, z. B. eine Aufgabe oder ein Endereignis.

174

7 Übungsaufgaben und Kontrollfragen

14. Dürfen Sequenzflüsse Pool-Grenzen überschreiten? Nein. 15. Dürfen Sequenzflüsse Lane-Grenzen überschreiten? Ja. 16. Was ist unter einer Aktivität zu verstehen? Eine Aktivität hat einen Beginn und ein Ende. Es wird ergebnisorientierte Arbeit verrichtet, manuell, mit Software-Unterstützung, teil- oder vollständig automatisiert. Der Begriff „Aktivität“ ist ein zusammenfassender Oberbegriff für die Unterbegriffe „Aufgabe“ und „Unterprozess“. 17. Was ist unter einem Ereignis zu verstehen? Ereignisse sind z. B. der Eingang eines Kundenauftrags, die Stornierung eines Auftrags, das Erreichen einer Signalnorm in der Lagerhaltung, der Ablauf einer Frist usw. Ein Ereignis ist etwas, was im Laufe eines Prozesses passiert oder sich ereignet. 18. Was sind Gateways und wie funktionieren sie? Gateways sind Verzweigungen und Zusammenführungen von Prozesspfaden. Sie werden zur Kontrolle und Steuerung eines Prozesses eingesetzt. Die Funktionsweise von Gateways lässt sich mit dem Markenkonzept erklären. Bei einem verzweigenden Parallel Gateway mit 1 Eingang und n Ausgängen kommt im Gateway 1 Marke an. Infolge dieser Ankunft werden n-1 Marken generiert, so dass durch jeden der n Ausgänge genau 1 Marke fließt. Bei einem zusammenführenden Parallelen Gateway mit n Eingängen und 1 Ausgang erfolgt eine Synchronisation des Ablaufs, d. h. es wird so lange gewartet, bis alle n Marken im Gateway angekommen sind. Die n Marken werden zu 1 Marke verschmolzen und 1 Marke wird vom Gateway an den ausgehenden Sequenzfluss weitergeleitet. 19. Was ist unter einer Kollaboration zu verstehen und welche Darstellungen der Kommunikationsbeziehungen stehen damit in engem Zusammenhang? Bei dem Begriff „Kollaboration“ geht es um die Zusammenarbeit von zwei oder mehreren Geschäftspartnern. In einem Kollaborationsdiagramm werden zwei oder mehrere Teilnehmer, z. B. Geschäftspartner, und der Nachrichtenfluss zwischen diesen dargestellt. Konversationsdiagramme dienen einer vereinfachten und damit sehr übersichtlichen Darstellung der Kommunikation zwischen Geschäftspartnern. Wenn der Nachrichtenfluss zwischen den Partnern etwas komplexer und komplizierter wird, dann empfehlen sich dafür Choreographien. 20. Was ist unter einem Nachrichtenfluss zu verstehen? Ein Nachrichtenfluss dient dem gerichteten Austausch von Nachrichten. Jeder Nachrichtenfluss hat eine Quelle, z. B. eine Sende-Aufgabe von einem Teilnehmer A, und eine Senke, z. B. eine Empfangsaufgabe von einem Teilnehmer B. 21. Welche Regeln gelten für Nachrichtenflüsse? Quelle und Senke eines Nachrichtenflusses müssen zu verschiedenen Pools gehören, wobei die Pools Teilnehmer an einer Kollaboration repräsentieren.

7.3 Kontrollfragen mit Antworten

175

Quelle von Nachrichtenflüssen können nur Pools, sendende Nachrichtenereignisse und Sende-Aufgaben sein, d. h. ein Nachrichtenfluss darf bspw. nicht von einem Gateway ausgehen. Senke von Nachrichtenflüssen können nur Pools, empfangende Nachrichtenereignisse und Empfangsaufgaben sein, d. h. ein Nachrichtenfluss darf bspw. nicht zu einem Gateway führen. Streng genommen lässt der Standard zum Senden und Empfangen auch andere Aktivitäten zu. Wir raten aber davon ab, denn wozu gibt es Sende- und Empfangsaufgaben. 22. Müssen Nachrichten- und Sequenzfluss gelegentlich zusammenwirken? Ja. Es gibt Elemente (Aufgaben, Ereignisse), in die sowohl ein Nachrichten- als auch ein Sequenzfluss eingehen. Solche Aufgaben oder Ereignisse werden erst dann aktiviert bzw. treten erst dann ein, wenn sowohl eine Marke über den Sequenzfluss eingetroffen ist als auch eine Nachricht eingegangen ist. 23. Was ist unter dem Markenkonzept von BPMN zu verstehen und wozu dient es? Das Marken-Konzept (token concept) ist ein theoretisches Denkmodell, das es ermöglicht, die Regeln für den Ablauf von Geschäftsprozessen einfach und präzise zu formulieren. Mit Hilfe des Markenkonzepts werden die Funktionsweisen der einzelnen Gateway-Typen spezifiziert. Tool-Hersteller sind nicht verpflichtet, das Marken-Konzept anzuwenden. Sie müssen aber die durch das Marken-Konzept beschriebenen Ablaufregeln auf irgendeine Art und Weise implementieren. 24. Wie fließt eine Marke durch ein Exklusives Gateway mit einem Eingang und zwei Ausgängen mit zugeordneten alternativen Bedingungen (entweder Bedingung 1 oder Bedingung 2 trifft zu)? Siehe Abb. 7.27.

Abb. 7.27:

Entscheidung für das geeignetste Transportmittel

Die gedachte Marke wird erzeugt, wenn das Startereignis eingetreten ist. Sie durchläuft die Aufgabe „Entfernung bestimmen“ und gelangt jeweils entlang des Sequenzflusses zu dem verzweigenden exklusiven (ausschließenden) Gateway. Ausschließend heißt das Gateway deshalb, weil die Marke auf genau einem der alternativen Pfade fließen wird, die von dem verzweigenden Gateway ausgehen. Es wird also entweder die Aufgabe „Flug buchen“ oder „Zug buchen“ ausgeführt. In jedem der beiden möglichen Fälle gelangt die Marke an das zusammenführende Exklusive Gateway. Die dort ankommende Marke wird an das Ende-Ereignis weitergeleitet und schließlich konsumiert.

176

7.3.2

7 Übungsaufgaben und Kontrollfragen

Zu Kapitel 2 Aufgaben

25. Welche zwei speziellen Aktivitätstypen gibt es? Hinweis: „Aktivität“ ist ein Oberbegriff. Gesucht sind zwei abgeleitete Begriffe. Aufgabe (task) und Unterprozess (sub-process). 26. Was ist unter einer Aufgabe zu verstehen? Eine Aufgabe ist eine atomare Aktivität. Atomar heißt, sie ist nicht weiter zerlegbar oder sie wird nicht weiter zerlegt, weil für den Zweck der Prozess-Definition für eine weitere Zerlegung keine Notwendigkeit besteht. Ein Unterprozess dagegen ist ein Prozess mit Aktivitäten, Ereignissen, Sequenzflüssen usw. 27. Was ist unter einem Unterprozess zu verstehen und welchen Sinn und Zweck hat er? Ein Unterprozess ist ein Prozess mit besonderen Eigenschaften, z. B. der Eigenschaft, einem umgebenden Prozess untergeordnet zu sein. Sinn und Zweck eines Unterprozesses ist es, als Strukturierungsmittel in komplexen Prozessen zu dienen und damit Prozesse übersichtlich und nachvollziehbar zu gestalten. Eine besondere Rolle spielt der Ereignis-Unterprozess. 28. Welche zwei verschiedenen Typen von Mehrfach-Instanz-Unterprozessen gibt es und worin besteht der Unterschied? Es gibt den parallelen und sequentiellen Mehrfach-Unterprozess. Parallel bedeutet, dass mehrere Unterprozess-Instanzen parallel abgearbeitet werden. Sequentiell bedeutet, dass mehrere Unterprozess-Instanzen nacheinander abgearbeitet werden. 29. Das nachfolgende Diagramm in Abb. 7.28 zeigt die Kollaboration zwischen einem Bewerber und einer Hochschule. An einer Hochschule bewerben sich aber im Bewerbungszeitraum viele Bewerber. Wie könnte man das im Diagramm ausdrücken? Nehmen Sie eine kleine Einfügung im Diagramm vor.

7.3 Kontrollfragen mit Antworten

Abb. 7.28:

177

Bewerbung eines einzelnen Bewerbers um einen Studienplatz

Man wandelt den Teilnehmer Bewerber in einen Mehrfach-Teilnehmer, in dem man in der Mitte des unteren Rands des Bewerber-Pools durch drei senkrechte parallele Striche anzeigt, dass es sich um einen sogenannten Mehrfachteilnehmer (genauer: mehrere Teilnehmer) handelt.

Abb. 7.29:

Bewerbung mehrerer Bewerber um einen Studienplatz

178

7 Übungsaufgaben und Kontrollfragen

30. Wozu dient und wie funktioniert ein Kompensations-Unterprozess? Kompensieren bedeutet immer das Rückgängigmachen von Ergebnissen, die nicht mehr benötigt werden. Zum Beispiel kann es sich dabei um das Rückgängigmachen einer Hotelbuchung infolge der Absage eines Termins handeln. 31. Welche Eigenschaften haben Aufgaben (tasks) und Unterprozesse (sub-processes) gemeinsam? Sowohl Aufgaben als auch Unterprozesse sind Aktivitäten. Aufgaben und Unterprozesse haben eine Reihe gemeinsamer Elemente wie „loopCharacteristics“ sowie eine Reihe gemeinsamer Attribute wie „isForCompensation“, die in der abstrakten Superklasse „Aktivität“ zusammengefasst wurden. Diese Eigenschaften werden vom Supertyp „Aktivität“ an die beiden Subtypen „Aufgabe“ und „Unterprozess“ vererbt. 32. Welche acht spezifischen Aufgabetypen werden im BPMN-Standard definiert? – – – – –

Service- und

Script-Aufgabe,

User- und Manuelle Aufgabe, Sende- und Empfangsaufgabe, Geschäftsregel-Aufgabe, Choreographie-Aufgabe.

33. Was kennzeichnet eine Service-Aufgabe? Eine Service-Aufgabe wird im Background ohne Benutzerbeteiligung von Software übernommen. Service-Aufgaben werden in der Regel als Web-Service-Aufrufe realisiert. 34. Welchen Sinn und Zweck haben Service-Aufgaben? Service-Aufgaben dienen im Wesentlichen der Wiederverwendung vorhandener Software-Module über eine standardisierte Schnittstelle. Die Web Services müssen meist nicht neu entwickelt werden, sondern sie werden als fertige Lösung von Service Providern angeboten. 35. Auf welchen Standards basieren Service-Aufgaben? WSDL (Web Services Description Language) als Schnittstellenbeschreibungssprache, z. B. SOAP (Simple Object Access Protocol) als Kommunikationsprotokoll und z. B. HTTP als Transportprotokoll. 36. Wie funktioniert eine Service-Aufgabe vom Prinzip her? Die Geschäftsprozess-Definition im XML-Format, gültig nach BPMN20.xsd, verweist auf ein WSDL-File (WSDL – Web Services Description Language). Dieses File enthält oder verweist auf alle notwendigen Informationen, die von einer Process Engine benötigt werden, um einen Web Service automatisiert aufzurufen. 37. Was ist unter einer Skriptsprache zu verstehen? Skript-Sprachen gibt es für vielfältige spezielle Zwecke. Nehmen wir als Beispiel die Skript-Sprachen XSLT (eXtensible Style Sheet Language for Transformation) und XSLFO (eXtensible Style Sheet Language – Formatting Objects). Sie dienen einmal dazu,

7.3 Kontrollfragen mit Antworten

179

XML-Daten zu transformieren, und zum anderen dazu, das generalisierte Zwischenformat FO zu erstellen, um daraus je nach Bedarf Dokumente im PDF-, RTF- oder Postscript-Format zu erzeugen. 38. Was kennzeichnet eine Skript-Aufgabe? Eine Skript-Aufgabe läuft wie ein Web Service im Background ohne Benutzerbeteiligung ab. Bei der Ausführung dieses Tasks wird ein Script von einer speziellen Software interpretiert. Zum Beispiel könnte eine Rechnung im etwas kryptischen XML-Format mittels der Skriptsprache XSL-FO in ein druckbares Format wie PDF oder Postscript transformiert werden. Aus einem für den Computer perfekten Format wird ein für den Menschen ideales Format erzeugt. Bestimmte Aufgabenklassen wie z. B. Transformationsaufgaben lassen sich mit speziell dafür geschaffenen Skriptsprachen auf effiziente Weise lösen. 39. Was haben Benutzer- und Manuelle Aufgaben gemeinsam und wodurch unterscheiden sie sich? Benutzer- und Manuelle Aufgaben werden beide von einer Mitarbeiterin oder einem Mitarbeiter (human performer) ausgeführt. Benutzer-Aufgaben werden mit Softwareunterstützung ausgeführt, z. B. mit einem Tabellenkalkulationsprogramm, Manuelle Aufgaben ohne Softwareunterstützung, z. B. manuelles Sortieren der Eingangspost. 40. Was leisten die Sende- und die Empfangs-Aufgabe? Mit diesen Aufgabentypen werden Nachrichten über Nachrichtenflüsse von anderen Teilnehmern empfangen oder an diese versandt. Sie können als Alternative zum Nachrichten-Ereignis modelliert werden. Wurde eine Nachricht verschickt oder empfangen, ist die Aufgabe beendet. 41. Was ist unter einer Geschäftsregel zu verstehen? Eine Geschäftsregel legt fest, unter welchen Bedingungen welche Aktionen auszuführen sind. Sie werden außerhalb des Prozessmodells beschrieben. Der Vorteil besteht darin, dass z. B. Fachabteilungen die Geschäftsregeln in einer Excel-Tabelle ohne eine ITBeteiligung selbst ändern können. Das geht oft schneller, ist effektiver und kostengünstiger. Manchmal ist es jedoch ratsam, wenn sich die Mitarbeiter in Fachabteilungen von Informatikern beraten und unterstützen lassen, weil in den Fachabteilungen mögliche Auswirkungen und eventuelle Nebeneffekte einer Regeländerung nicht komplett überschaut werden. Zur Ausführung von Geschäftsregel-Aufgaben setzt man sogenannte Business Rule Engines ein. 42. Wozu dient eine Geschäftsregel-Aufgabe? Eine Geschäftsregel-Aufgabe dient dazu, die Geschäftsregeln von der übrigen Software zu separieren. Durch die Separation führt eine Regeländerung nicht zu einer Softwareänderung. Des Weiteren dient eine Geschäftsregel-Aufgabe dazu, die Vorzüge einer Business Rule Engine, z. B. Drools, zu nutzen. 43. Welche Grundstruktur hat eine Geschäftsregel? Eine Geschäftsregel hat einen Bedingungsteil und einen Aktionsteil. Beispiel: Wenn Signalnorm eines (sinkenden) Lagerbestands erreicht, dann löse Bestellung aus.

180

7 Übungsaufgaben und Kontrollfragen

44. Erklären Sie die Funktionsweise einer Geschäftsregel-Aufgabe! Wenn die Bedingungen einer Regel erfüllt sind, dann „feuert“ diese Regel, d. h. es wird ihr Aktionsteil ausgeführt. Infolge dieser Aktionen können die Bedingungen anderer Regeln erfüllt werden, was dazu führt, dass jetzt auch diese Regeln „feuern“ usw., bis keine Regel mehr ausführbar ist. 45. Welchen Aufgabentyp würden Sie für die nachfolgende Aufgabenbeschreibung vorsehen und warum? Die Preise für die Produkte eines Unternehmens werden wöchentlich aktualisiert. Zur Preisbildung werden diverse Kriterien herangezogen, die sich nach bestimmten Gesetzmäßigkeiten auf den erzielbaren Preis auswirken: – Die Preise vom Vergleichszeitraum des Vorjahres. – Das prognostizierte Verhältnis von Angebot und Nachfrage im Verkaufszeitraum. – Die Produktqualität. – u.v.a.m. Man sollte eine Geschäftsregel-Aufgabe (business rule task) vorsehen, weil sich die zu erledigende Aufgabe gut in Regeln fassen lässt, die von einer versierten Fachabteilung erstellt und aktualisiert werden können. Die Beteiligung eines IT-Dienstleisters ist dann ggf. nicht mehr erforderlich. Die Überprüfung der Regeln und die Ausführung von Aktionen während der Prozess-Laufzeit werden von einer Business Rule Engine übernommen. 46. Welche zwei Darstellungsvarianten gibt es für Unterprozesse? Hinweis: zusammenfassende und detaillierte Darstellung Zugeklappt (collapsed) und aufgeklappt (expanded). Zusammengeklappt bzw. kollabiert wird mit einem „+“ und aufgeklappt bzw. expandiert wird mit einem „-“ ausgedrückt. Die expandierte Darstellung kann innerhalb des Oberprozesses oder in einem separaten Fenster erfolgen. Die Darstellung in einem separaten Fenster ist vorzuziehen, weil die Expansion des Unterprozesses im Diagramm des Oberprozesses häufig zu deformierten Darstellungen führt. 47. Was ist unter einer Transaktion zu verstehen? Eine Transaktion besteht aus mehreren Operationen, z. B. aus den beiden Operationen „Abbuchung von einem Bankkonto“ und „Zubuchung zur Kasse“ (Aktivtausch). Diese beiden Operationen müssen immer beide vollständig ausgeführt werden. Gelingt das nicht, dann muss derjenige Zustand wieder hergestellt werden, der vor Beginn der Transaktion bestand. Wenn in unserem Beispiel die erste Operation gelänge und die zweite Operation fehlschlagen würde, dann würde die Bilanz eine Differenz aufweisen. Setzt man auf den Zustand vor Beginn der Transaktion zurück, dann hat man wieder eine korrekte Bilanz. Korrekte Zustände nennt man in der Fachsprache des Informatikers auch konsistente Zustände. 48. Welchen Sinn und Zweck haben Transaktionen? Datenbestände, z. B. eine Bilanz, von einem konsistenten Ausgangszustand in einen konsistenten Folgezustand zu überführen. Geht dabei wider Erwarten etwas schief, wird auf den letzten konsistenten Zustand zurückgesetzt.

7.3 Kontrollfragen mit Antworten

181

49. Wie funktioniert das Zurücksetzen einer Transaktion? Das Zurücksetzen einer Transaktion geschieht in BPMN mittels Kompensation. Das bedeutet, dass man nicht wie bei einem Datenbankmanagementsystem auf einen RollbackMechanismus zurückgreifen kann, sondern dass das Zurücksetzen (Rollback) durch Kompensationsaufgaben oder Kompensations-Unterprozesse bewerkstelligt werden muss. 50. Welche Marker gibt es für Aufgaben und wofür sind sie gut? Der Standard-Schleifen-Marker (standard loop marker) zeigt an, dass die Aufgabe bei ihrer Aktivierung wiederholt abgearbeitet werden muss, z. B. mit einer gegebenen Anzahl von Wiederholungen, oder mit einer Abbruchbedingung, die entweder am Anfang oder am Ende der Schleife geprüft wird. Eine Wiederholung wäre z. B. in einem iterativen Näherungsverfahren sinnvoll, wenn dadurch eine (weitere) Resultatverbesserung erzielt werden kann. Der Parallele-Mehrfachaufgabe-Marker (parallel multi-instance loop marker) bedeutet, dass von dieser Aufgabe mehrere Instanzen gebildet werden, wenn diese Aufgabe an der Reihe ist. Diese Instanzen laufen parallel. Mehrere parallel arbeitende Instanzen sind sinnvoll, wenn sie unabhängig voneinander sind. Ein Beispiel wäre die parallele Berechnung der Quartalsumsätze für die Filialen eines Unternehmens. Der Sequentielle-Mehrfachaufgabe-Marker (sequential multi-instance loop marker) bedeutet, dass von dieser Aufgabe mehrere Instanzen gebildet werden, wenn diese Aufgabe an der Reihe ist. Diese Instanzen werden nacheinander aufgerufen. Ein solches Verhalten wird dann benötigt, wenn die (i+1)-te Instanz das Resultat der i-ten Instanz berücksichtigen muss, z. B. bei einer n-stufigen Zufallsauswahl (1 =< i < i+1 =< n). Der Kompensationsmarker bedeutet, dass es sich um eine Aufgabe zu Kompensationszwecken handelt, d. h. mit Hilfe dieser Aufgabe soll das Ergebnis einer Aktivität rückgängig gemacht werden, um auf den letzten konsistenten Zustand des Prozesses zurückzusetzen. Das kann z. B. notwendig sein, wenn es gelungen ist, für einen wichtigen Termin ein Hotelzimmer in Wellington zu buchen, aber die Buchung eines Fluges dorthin fehlschlägt. Dann müsste die Hotelbuchung natürlich rückgängig gemacht werden. Der Aufruf-Aktivität-Marker (fette Umrandung) zeigt an, dass an dieser Stelle im Prozess eine globale Aktivität aufgerufen wird. Nach Abarbeitung der globalen Aufgabe geht es entlang des Sequenzflusses nach der Aufruf-Aktivität weiter. 51. Welche Marker gibt es für Unterprozesse und wofür sind sie gut?

Der Marker bedeutet, dass es sich um einen zugeklappten Unterprozess handelt.

Der Standard-Schleifen-Marker (standard loop marker) funktioniert bei Unterprozessen wie bei Aufgaben – s.o.

182

7 Übungsaufgaben und Kontrollfragen

Der Parallel-Mehrfach-Unterprozess-Marker (parallel multi-instance loop marker) funktioniert bei Unterprozessen wie bei Aufgaben – s.o.

Der Sequentiell-Mehrfach-Unterprozess-Marker (sequential multiinstance loop marker) funktioniert bei Unterprozessen wie bei Aufgaben – s.o.

Der abbrechende (interrupting) Ereignis-Unterprozess-Marker, hier dargestellt am Beispiel eines Zeitereignisses und der gepunkteten Umrandung, bedeutet, dass der unmittelbar umgebende Prozess oder Unterprozess abgebrochen wird, wenn der Ereignis-Unterprozess – hier zeitgesteuert – startet.

Der nicht abbrechende Ereignis-Unterprozess-Marker, hier dargestellt am Beispiel eines Nachrichtenereignisses und der gepunkteten Umrandung, bedeutet, dass der unmittelbar umgebende Prozess oder Unterprozess nicht abgebrochen wird, wenn der Ereignis-Unterprozess – hier infolge eines Nachrichtereignisses – startet.

Der Marker für ein angeheftetes Transaktionsabbruch-Zwischenereignis bedeutet, dass der Ausnahmefluss an dieser Stelle beginnt, wenn der TransaktionsUnterprozess (doppelte Umrandung) abgebrochen wird.

Der Kompensationsmarker hat bei Unterprozessen die gleiche Bedeutung wie bei Aufgaben – s.o.

Der Ad-hoc-Unterprozess-Marker bedeutet, dass der Unterprozess aus irgendeinem Grund nicht ausmodelliert worden ist, z. B. weil man nicht genau weiß, was in einem nicht genau vorhersehbaren Fall zu tun ist. Man könnte sinnvolle Aktivitäten benennen, ohne einen genauen Ablauf anzugeben.

Der Aufruf-Aktivität-Marker (fette Umrandung) zeigt an, dass an dieser Stelle im Prozess ein globaler Prozess aufgerufen wird. Nach Abarbeitung des globalen Prozesses geht es entlang des Sequenzflusses nach der Aufruf-Aktivität weiter.

7.3 Kontrollfragen mit Antworten

183

52. Welchen Sinn und Zweck haben Globale Aufgaben? Werden definierte Aufgaben in mehreren Prozessen verwendet, können diese als globale Aufgaben (global tasks) modelliert werden. Diese globalen Aufgaben können von beliebig vielen Prozessen aus aufgerufen werden. 53. Wie wirken Globale Aufgaben und Aufruf-Aktivitäten zusammen? Eine globale Aufgabe wird einmalig angelegt und von verschiedenen Prozessen mit der Aufruf-Aktivität (call activity) aufgerufen. Die Aufruf-Aktivität und die globale Aufgabe erkennt man an einer dickeren Umrandung als sie „normale“ Aufgaben haben.

7.3.3

Zu Kapitel 3 Gateways

54. Wie wirken ein verzweigendes Exklusives und ein zusammenführendes Exklusives Gateway zusammen? Bei einem verzweigenden Exklusiven Gateway muss genau eine Bedingung an den ausgehenden Sequenzflüssen den Wert true haben, d. h. genau eine Marke wird auf genau einen Sequenzfluss ausgegeben. In das zusammenführende Exklusive Gateway können mehrere Sequenzflüsse eingehen. Nur auf genau einem Sequenzfluss kommt eine Marke an, die vom Gateway an den ausgehenden Sequenzfluss weitergeben wird. 55. Worin besteht der Unterschied zwischen einem datenbasierten und einem ereignisbasierten Exklusiven Gateway? Bei einem ereignisbasierten Exklusiven Gateway wird der Prozess fortgesetzt, sobald eines der im Prozess unmittelbar nachfolgenden Ereignisse eingetreten ist oder eine Nachricht in einer unmittelbar nachfolgenden Empfangs-Aufgabe empfangen wurde. Ein datenbasiertes Exklusives Gateway (XOR-Gateway) gibt die Marke an denjenigen Sequenzfluss aus, dessen Bedingung zutrifft. 56. Wie wirken ein splittendes und ein verschmelzendes Paralleles Gateway zusammen? Ein splittendes Paralleles Gateway splittet die ankommende Marke in so viele Marken auf, wie es ausgehende Sequenzflüsse hat. Auf allen Sequenzflüssen wird je eine Marke ausgegeben. Das verschmelzende Parallele Gateway wartet, bis alle ausgegebenen Marken angekommen sind, vereinigt sie und gibt eine Marke auf dem ausgehenden Sequenzfluss weiter. 57. Wodurch unterscheiden sich ein einfaches Paralleles Gateway und ein ereignisbasiertes Paralleles Gateway? Ein einfaches Paralleles Gateway splittet eine ankommende Marke in die Anzahl der ausgehenden Sequenzflüsse und gibt sie an die ausgehenden Sequenzflüsse weiter. Bei einem Ereignisbasierten Parallelen Gateway wird der Prozess erst fortgesetzt, wenn alle unmittelbar nachfolgenden Ereignisse eingetreten sind oder wenn alle Nachrichten in unmittelbar nachfolgenden Empfangs-Aufgaben empfangen wurden. 58. Wie wirken ein splittendes und ein verschmelzendes Inklusives Gateway zusammen? Das splittende Inklusive Gateway splittet eine ankommende Marke in so viele Marken, wie ausgehende Sequenzflüsse existieren, deren Bedingung wahr ist. Als Modellierer muss man unbedingt dafür sorgen, dass immer wenigstens eine dieser Bedingungen

184

7 Übungsaufgaben und Kontrollfragen wahr ist. Das verschmelzende Inklusive Gateway wartet solange, bis alle zuvor ausgegebenen Marken eingetroffen sind, verschmilzt sie und gibt eine Marke auf dem ausgehenden Sequenzfluss weiter.

59. Welchen besonderen Vorzug hat das Komplexe Gateway und wie funktioniert es? Das Komplexe Gateway hat folgende Eigenschaften und folgendes Verhalten: Den ausgehenden Pfaden eines splittenden Komplexen Gateways müssen wie beim Inklusiven Gateway Bedingungen zugeordnet werden. Es muss dabei sicher gestellt sein, dass mindestens eine dieser Bedingungen wahr ist. Um das sicher zu stellen, kann man wie gehabt einen Default-Fluss hinzufügen. Die Marken von den in ein verschmelzendes Komplexes Gateway eingehenden Pfaden werden synchronisiert. Es gibt zwei InstanzAttribute, die ein etwas komplexeres Verhalten als beim verschmelzenden Inklusiven Gateway ermöglichen. Diese Attribute sind activationCounter und waitingForStart. Der activiationCounter zählt die Anzahl der Marken, die im zusammenführenden Gateway angekommen sind. waitingForStart hat im Gateway zunächst den Wert true. Das bedeutet, dass das Gateway schaltet, wenn eine bestimmte Anzahl von m Marken von insgesamt n zum Gateway unterwegs befindlichen Marken im Gateway angekommen ist (m ≤ n). Dabei ist n die Anzahl derjenigen Marken, die nach dem Splitten auf den Pfaden zum vereinigenden Gateway unterwegs sind, m ist die Anzahl der Marken, die angekommen sein müssen, damit das Gateway schaltet. Nach dem Schalten geht das Gateway in den Zustand waitingForStart = false über. Wenn dann im Laufe der Zeit die verbleibende Anzahl k=n-m Marken eingetroffen ist, erfolgt ein Reset des Gateways. Die Variable waitingForStart nimmt dann wieder den Wert true an und das Gateway befindet sich wieder im schaltbaren Ausgangszustand.

7.3.4

Zu Kapitel 4 Ereignisse

60. Worin besteht der Unterschied zwischen sendenden und empfangenden Ereignissen? Ein sendendes Ereignis tritt ein, wenn eine Marke an dem entsprechenden Ereignissymbol angekommen ist und ein Ergebnis vorliegt, z. B. dass eine Nachricht versandt worden ist. Empfangende Ereignisse reagieren auf Auslöser (Trigger). Ein empfangendes Ereignis tritt ein, wenn eine Marke an dem Ereignissymbol angekommen ist und ein Auslöser für dieses Ereignis wahrgenommen worden ist, z. B. ein woanders ausgesandtes Signal. 61. Was kennzeichnet Top-Level-Startereignisse? Ein Top-Level-Startereignis tritt ein, wenn ein Auslöser wahrgenommen wurde, z. B. der Eingang eines Kundenauftrags. Hat ein Top-Level Startereignis keinen Auslöser (Trigger), dann wird er nicht infolge eines Ereignisses gestartet, sondern er wird manuell gestartet oder infolge eines Aufrufs durch eine Aufruf-Aktivität. 62. Welche Trigger sind zulässig für Top-Level-Startereignisse? Folgende Trigger kommen für Startereignisse von Top-Level-Prozessen in Frage: Message, Signal, Timer, Conditional, Multiple, Parallel Multiple. 63. Was haben ein Top-Level-Nachrichten- und Top-Level-Signal-Ereignis gemeinsam und welchen Unterschied gibt es zwischen beiden?

7.3 Kontrollfragen mit Antworten

185

Ein empfangendes Top-Level-Nachrichten-Ereignisses tritt ein, wenn eine bestimmte Nachricht empfangen worden ist. Ein empfangendes Top-Level-Signal-Ereignis tritt ein, wenn ein bestimmtes Signal wahrgenommen worden ist. Wenn es sich um Startereignisse handelt, wird in beiden Fällen eine Prozessinstanz gebildet, es werden so viele Marken generiert, wie es aus dem Startereignis ausgehende Sequenzflüsse gibt, und der Prozess wird gestartet. Das sendende Top-Level-Nachrichten-Ereignis tritt ein, wenn eine Nachricht an einen bestimmten Adressaten versandt worden ist. Das sendende TopLevel-Signal-Ereignis tritt ein, wenn ein Signal an alle denkbaren Empfänger ausgesandt worden ist. 64. Was haben Top-Level-Mehrfach-Startereignisse und Top-Level-Parallel-MehrfachStartereignisse gemeinsam und worin besteht der Unterschied zwischen beiden? Ein Top-Level-Mehrfach-Startereignis tritt ein, wenn wenigstens ein Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert ist. Ein Top-LevelParallel-Mehrfach-Startereignis tritt ein, wenn alle Auslöser aus einer vom Modellierer festgelegten Menge von Auslösern aktiviert sind. In beiden Fällen wird eine Prozessinstanz gebildet, es werden so viele Marken generiert, wie es aus dem Startereignis ausgehende Sequenzflüsse gibt, und der Prozess wird gestartet. Bei beiden, d. h. bei TopLevel-Mehrfach-Ereignissen und bei Top-Level-Parallel-Mehrfach-Ereignissen, werden verschiedene Ereignis-Definitionen in Textform angegeben. Im Fall der Automatisierung müssen die Mehrfach-Ereignisse mehrere Ereignis-Definitionen referenzieren. 65. Was ist unter einem Ereignis-Unterprozess zu verstehen und wofür ist er geeignet? Ein Ereignis-Unterprozess befindet sich innerhalb eines Prozesses oder Unterprozesses und hat die Aufgabe, auf einen Auslöser eines bestimmten Typs zu reagieren und das Notwendige zu tun. Je nachdem, ob das Startereignis des Ereignis-Unterprozesses abbrechend oder nicht abbrechend ist, wird der umgebende Prozess entweder abgebrochen oder fortgesetzt. 66. In welchen Fällen verwendet man abbrechende und in welchen nicht abbrechende Startereignisse in einem Ereignis-Unterprozess? Abbrechende Startereignisse werden genutzt, um den Ereignis-Unterprozess einmalig zu starten und den umgebenden Prozess oder Unterprozess abzubrechen. Nicht abbrechende Startereignisse werden verwendet, wenn der Ereignis-Unterprozess beliebig oft gestartet und ausgeführt werden soll, solange der umgebende Prozess aktiv ist. Der umgebende Prozess wird beim Start des Ereignis-Unterprozesses nicht abgebrochen. 67. Was ist unter einer Ausnahmebehandlung (exception handling) im Zusammenhang mit einem Unterprozess zu verstehen? Wenn in einem Unterprozess eine Ausnahme, z. B. ein Fehler, auftritt, wird nach einem Unterprozess nicht mehr auf dem normalen, vom Unterprozess ausgehenden Sequenzfluss fortgesetzt, sondern auf einem Ausnahmefluss, der mit einem angehefteten Ereignis zum Zweck der Ausnahmebehandlung beginnt. Die Ausnahmebehandlung kann auch durch einen Ereignis-Unterprozess erfolgen, der in einem Prozess oder Unterprozess eingebettet ist.

186

7 Übungsaufgaben und Kontrollfragen

68. Was ist unter Inline Event Handling zu verstehen, wozu ist es geeignet und welche Alternative gibt es dazu? Inline Event Handling wird realisiert durch das Reagieren auf Ereignisse mittels Ereignis-Unterprozessen. Die Steuerung wird nicht an den übergeordneten Prozess übergeben. Der Unterprozess kümmert sich selbst um die Ausnahmebehandlung. Eine Alternative wäre, das Event Handling dem unmittelbar übergeordneten Prozess zu überlassen. 69. Was ist unter einem Zwischenereignis zu verstehen und wie sind sie in Sequenzflüsse eingebunden? Zwischenereignisse befinden sich zwischen Prozessstart und Prozessende. Die meisten Zwischenereignisse haben eingehende und ausgehende Sequenzflüsse. Eine Ausnahme bildet das sendende (hat nur einen eingehenden, keinen ausgehenden Sequenzfluss) und das empfangende (hat nur ausgehenden, keinen eingehenden Sequenzfluss) Verknüpfungsereignis (link event). Eine weitere Ausnahme bilden angeheftete Ereignisse. (Sie sind immer empfangende Zwischenereignisse.) Angeheftete Zwischenereignisse haben keinen eingehenden Sequenzfluss. Das angeheftete Kompensationszwischenereignis hat auch keinen ausgehenden Sequenzfluss. 70. Was kann alternativ zu einem Nachrichten sendenden bzw. Nachrichten empfangenden Zwischenereignis modelliert werden? Eine Sende- bzw. eine Empfangs-Aufgabe. 71. Wofür wird das nicht näher spezifizierte, im Standard unspezifiert genannte, Zwischenereignis verwendet? Das nicht näher spezifizierte Zwischenereignis wird für methodische Zwecke verwendet, z. B. für die Anzeige eines Status‘ oder eines Statuswechsels. Ein Statuswechsel kann beispielsweise durch einen Wiederholungszähler, dessen Wert von i auf i+1 gesetzt wird, modelliert werden. 72. Welchen Sinn und Zweck haben das angeheftete Abbruch-Ereignis (boundary cancel event) und das Abbruch-Endereignis (cancel end event)? Das angeheftete Abbruch-Zwischenereignis und das Abbruch-Endereignis (cancel end event) werden ausschließlich für Transaktionen verwendet. Das Abbruch-Endereignis tritt ein, wenn die Notwendigkeit des Abbruchs einer Transaktion erkannt und das Zurücksetzen auf den letzten konsistenten Zustand des Prozesses angestoßen worden ist (Ergebnis). Das angeheftete Abbruch-Zwischenereignis ist ein empfangendes Ereignis. Es registriert, wenn der Transaktions-Unterprozess, an den es angeheftet ist, abgebrochen wird (Auslöser). An dieser Stelle beginnt der Ausnahmefluss infolge Transaktionsabbruchs. 73. Was passiert, wenn ein angeheftetes Ereignis eintritt, jedoch die Aktivität schon beendet ist? Ein angeheftetes Ereignis – das ist immer ein empfangendes Zwischenereignis – kann nur eintreten, wenn die Aktivität, an die das Ereignis angeheftet ist, (bereits bzw. noch) aktiv ist. Wenn an einen Unterprozess ein empfangendes Nachrichten-Zwischenereignis, z. B. eine Stornomeldung, angeheftet ist und die Stornomeldung eintrifft, wenn der Unterprozess bereits beendet ist, dann ist die Stornomeldung wirkungslos.

7.3 Kontrollfragen mit Antworten

187

74. Wann ist ein Prozess vollständig ausgeführt und beendet? Wenn alle Marken im Prozess konsumiert wurden. 75. Kann ein Fluss aus einem Endereignis hinausführen? Wenn ja, welcher? Ja, ein Nachrichtenfluss. 76. Was passiert, wenn man das Abbruch-Endereignis (terminate end event) verwendet? Das Abbruch-Endereignis (terminate end event) führt zum Abbruch eines Prozesses. Es konsumiert die ankommende Marke und alle sonst noch im Prozess befindlichen Marken derselben Prozessinstanz. Damit ist die Prozess-Instanz beendet. Es werden auch alle anderen Prozess-Instanzen beendet. Es erfolgt keine Ausnahmebehandlung und keine Kompensation.

7.3.5

Zu Kapitel 5 Artefakte, Datenobjekte und Datenspeicher

77. Welche drei Typen von Artefakten gibt es? Anmerkungen, Assoziationen und Gruppierungen. 78. Was ist unter Datenobjekten zu verstehen? Datenobjekte sind Daten jeglicher Form und Beschaffenheit, die zur Aufgabenerfüllung benötigt oder als Ergebnis erzeugt werden. Die Ankopplung erfolgt über DatenAssoziationen an die Aufgabe oder den Sequenzfluss. 79. Wozu dienen Datenspeicher und wie werden sie in BPMN-Prozess-Definitionen verwendet? Datenspeicher dienen dazu, Daten in relationaler oder anderer Form oder als Geschäftsdokumente im XML-Format über die Prozessdauer hinaus permanent zu speichern, d. h. es kann auch von späteren Prozess-Instanzen darauf zugegriffen werden. 80. Wozu dienen Gruppierungen? Gruppierungen fassen inhaltlich zusammengehörige Flusselemente, d. h. Aktivitäten, Gateways, Events und die verbindenden Sequenzflüsse zusammen mit dem Ziel der optischen Hervorhebung und der Betonung des Zusammenhangs. Gruppierungen haben keinerlei Semantik (Bedeutung) für den Prozessablauf, aber sie erleichtern dem Leser das Erkennen von inhaltlich eng zusammenhängenden Elementen im Diagramm. 81. Wie werden Artefakte mit Prozesselementen verknüpft? Zur Verknüpfung von Artefakten mit Prozess-Elementen werden Assoziationen verwendet. 82. Können Gruppierungen über Poolgrenzen hinaus modelliert werden? Ja. 83. Womit können Daten-Objekte mit Prozesselementen verknüpft werden? Die Verknüpfung erfolgt mit gerichteten Datenassoziationen.

188

7 Übungsaufgaben und Kontrollfragen

84. Wodurch wird der Informationsaustausch zwischen Teilnehmern sichergestellt? Der Informationsaustausch zwischen Teilnehmern wird durch Nachrichtenflüsse sichergestellt. 85. Worin besteht der Unterschied zwischen Data-Input und Data Output? Prozesse und Aktivitäten benötigen in der Regel Daten. Wenn von Data-Input die Rede ist, dann von einem Input in einen Prozess bzw. in eine Aktivität. Wenn von einem Data-Output die Rede ist, dann aus einem Prozess bzw. aus einer Aktivität. Entscheidend ist hierbei, dass sich „in“ und „out“ auf einen Prozess bzw. eine Aktivität beziehen.

7.3.6

Zu Kapitel 6 Kollaborationen, Konversationen, Choreographien

86. Eine Kollaboration kann Konversationsknoten und Konversationslinks referenzieren. Was ist unter einer Konversation, einem Konversationsknoten und unter einem Konversationslink zu verstehen? Eine Konversation ist eine Gruppierung oder besser Zusammenfassung von Nachrichtenflüssen zwischen bestimmten Teilnehmern einer Kollaboration. Ein Konversationsknoten kann u. a. Teilnehmer an einer Kollaboration und Nachrichtenflüsse zwischen diesen Teilnehmern referenzieren. Diese Zusammenhänge werden auch im Diagramm deutlich, wenn ein Konversationsknoten expandiert wird. Ein Konversationslink ist eine Verknüpfung von einem Konversationsknoten mit einem Teilnehmer der Kollaboration. 87. Was ist unter einer Choreographie zu verstehen? Eine Choreographie beschreibt die Interaktionen zwischen Teilnehmern einer Kollaboration und insbesondere die logische Abfolge von Nachrichtenflüssen zwischen zwei oder mehreren Teilnehmern einer Kollaboration. Mit Hilfe von Choreographie-Aktivitäten wird dargestellt, in welcher Reihenfolge welche Nachrichten gesendet bzw. empfangen werden, unter welchen Bedingungen alternative Zweige durchlaufen werden usw. Eine Choreographie ist einem Geschäftsprozess in der Darstellung ähnlich. 88. Welche Startereignisse sind in Choreographien zulässig? Nicht näher spezifizierte Ereignisse, Zeitgeber-Ereignisse, Bedingte Ereignisse, Signalund Mehrfach-Ereignisse. 89. Welche Endereignisse dürfen in Choreographien vorkommen? Das nicht näher spezifizierte Endereignis und das Abbruch-Endereignis (terminate end event). 90. Welche Zwischenereignisse dürfen in einer Choreographie vorkommen? Das nicht näher spezifizierte Zwischenereignis, Nachrichten-, Zeitgeber-Ereignisse im Zusammenhang mit Ereignisbasierten Gateways, empfangende Abbruch- (cancel) Ereignisse, empfangende Kompensationszwischenereignisse, Bedingungs-, Link, Signalund Mehrfach-Zwischenereignisse. Bei dem einen oder anderen Gateway sind diverse Feinheiten zu beachten.

7.3 Kontrollfragen mit Antworten

189

91. Welche Gateways sind in einer Choreographie zulässig? – Ereignisbasiertes Gateway, – Exklusives Gateway, – Inklusives Gateway, – Parallel-Gateway, – Komplexes Gateway. 92. Für die Verwendung von Gateways in Choreographien gibt es Restriktionen. Welche wichtigen Restriktionen gibt es für die Verwendung von Exklusiven Gateways in Choreographien? Es stellt sich die Frage, woher die Daten kommen sollen für datenbasierte Entscheidungen in Exklusiven Gateways, da Choreographien nicht zentral gesteuert werden und sie auf keinen zentralen Datenspeicher zurückgreifen können. Die einzige Möglichkeit, einem datenbasierten Gateway die notwendigen Informationen zur Verfügung zu stellen, besteht darin, dass der Absender einer Nachricht die notwendigen entscheidungsrelevanten Daten in der Nachricht unterbringt und damit dem Exklusiven Gateway als Entscheidungsgrundlage zur Verfügung stellt.

7.3.7

Zum Marken-Konzept

93. Was ist unter dem Markenkonzept des BPMN-Standards zu verstehen und wozu dient es? Eine Process Engine erzeugt beim Auslösen eines definierten Prozesses eine Prozessinstanz und generiert eine Marke. Um sich den Prozessablauf besser vorstellen zu können, lässt man die Marke durch die Prozesselemente fließen. Die wichtigste Aufgabe des Markenkonzepts ist es, die Ablaufregeln für Prozesse zu definieren. Tool-Hersteller sind allerdings frei in der Wahl der Mittel für die Ablaufsteuerung. Entscheidend sind die Regeln, nicht die Art ihrer Implementierung. 94. Wo steckt der Fehler in dem nachfolgenden BPMN-Diagramm? Tipp: Verwenden Sie zum Beantworten der nachfolgenden Fragen das BPMN-Marken-Konzept!

Abb. 7.30:

Fehlerhafte Füllstandregelung

190

7 Übungsaufgaben und Kontrollfragen Entsprechend diesem Diagramm wird jeweils eine zusätzliche Marke generiert, sobald eines der beiden nicht abbrechenden Bedingungs-Ereignisse, nämlich Füllstand > 93% bzw. < 88%, erfüllt ist. Eine Marke verbleibt in der Aufgabe „Füllstand beobachten“ und die zweite Marke fließt von einem der beiden angehefteten Zwischenereignisse entlang des Ausnahmeflusses. Sie wird jedoch nicht nach der nächsten Aufgabe konsumiert, sondern fließt wieder in die noch aktive Aufgabe „Füllstand beobachten“ hinein. Damit gelangt eine zweite Marke zur Aufgabe „Füllstand beobachten“, was nicht korrekt ist, weil diese Aufgabe ja noch aktiv ist. Insofern erfüllt das Diagramm nicht den beabsichtigten Zweck. Die Marke, die über ein angeheftetes, nicht abbrechendes Zwischenereignis eine Aktivität verlässt, muss durch ein Endereignis konsumiert werden. Abb. 7.31 zeigt eine korrekte Darstellung der Füllstandregelung.

Abb. 7.31:

Korrekte Füllstandregelung

95. Wo stecken die Fehler in der folgenden Prozessdefinition?

Abb. 7.32:

Fehlerhafte Kollaboration

7.3 Kontrollfragen mit Antworten

191

Der Bildungsträger-Prozess enthält einen Zyklus, wodurch er in die Lage versetzt wird, dem Kunden wiederholt ein verbessertes Angebot zu senden, falls dieser (weitere) spezielle Wünsche hat. Ein Fehler besteht nun darin, dass der Kunde nicht in der Lage ist, ein verbessertes Angebot zu empfangen, weil der Kundenprozess keinen entsprechenden Zyklus enthält und unmittelbar nach dem Versenden spezieller Wünsche beendet wird. Zudem muss die Aufgabe „Seminaranfrage empfangen“ instanziierend sein (Kreis um den Briefumschlag), weil mit dieser Aufgabe der Prozess startet und eine Marke generiert wird. Die nachfolgenden 3 Fragen beziehen sich auf Abb. 7.33:

Abb. 7.33:

Prozess in Hypothekenbank

96. Wie viele Marken können in dem Geschäftsprozess maximal gleichzeitig existieren und warum? Siehe Abb. 7.33! Es können maximal 2 Marken existieren, weil es genau ein verzweigendes Paralleles Gateway gibt, das genau einmal von einer Marke durchlaufen wird. Von diesem Parallelen Gateway gehen zwei Pfade ab. Auf jedem dieser beiden Pfade fließt eine Marke. Es wird keine weitere Marke generiert, also sind es maximal zwei. 97. Ist der Geschäftsprozess definitiv beendet, wenn eine Marke das Endereignis E1 erreicht? Wenn ja, warum, wenn nein, warum nicht? Siehe Abb. 7.33! Nein, denn es muss noch eine zweite Marke existieren, die noch nicht am AbbruchEndereignis (terminate end event) ganz rechts angekommen ist, denn sonst wäre der Prozess bereits vorher beendet worden. Solange noch eine Marke im Prozess unterwegs ist, so lange ist der Prozess als Ganzes noch nicht beendet. 98. Welche Ereignisse sind in dem gegebenen BPMN-Diagramm Prozess-AbbruchEreignisse (terminate events) und weshalb sind sie in dem gegebenen BPMNDiagramm, so wie es ist, unverzichtbar? Siehe Abb. 7.33!

192

7 Übungsaufgaben und Kontrollfragen Die Abbruchereignisse sind notwendig, weil bei Ankunft einer Marke bei einem der beiden Endereignisse der Prozess als Ganzes beendet werden muss. Wurde der Kunde zweimal erfolglos erinnert, dann muss man nicht länger darauf warten, dass er einen Darlehensantrag stellt. Und umgekehrt, hat der Kunde einen Darlehensantrag gesendet, dann muss man ihn nicht noch einmal erinnern.

Die nächsten 5 Fragen beziehen sich auf Abb. 7.34. Hinweis: Bei der Empfangsaufgabe (receive task) „Seminaraufgabe empfangen“ im Bildungsträger-Prozess ist der Briefumschlag eingekreist , um die Aufgabe als Startaufgabe zu kennzeichnen, weil mit dem Eintreffen einer Seminaranfrage eine Instanz des Bildungsträger-Prozesses erzeugt werden muss. Vgl. BPMN-Standard 2.0, S. 161 f., Figure 10.16.

Abb. 7.34:

Seminarbuchung

99. Wie viele Marken fließen minimal und wie viele maximal im Kunden-Prozess? Siehe Abb. 7.34! Minimal und maximal eine, denn der Prozess startet mit einer Marke infolge des Startereignisses, und während des Prozesses wird keine Marke erzeugt. Die eine Marke wird erst durch das Ende-Ereignis konsumiert. 100. Wie viele Marken fließen minimal und wie viele maximal im Bildungsträger-Prozess? Siehe Abb. 7.34! Minimal und maximal eine, denn der Prozess startet mit genau einer Marke infolge des Eintreffens einer Seminaranfrage, und im Laufe des Prozesses wird keine zusätzliche Marke erzeugt. Die eine Marke wird infolge des Ende-Ereignisses konsumiert.

7.3 Kontrollfragen mit Antworten 101. Wie viele Zyklen enthält der Kunden-Prozess? Genau einen. Der Kundenzyklus ist fett markiert. Siehe Abb. 7.35!

Abb. 7.35:

Kundenzyklus

102. Wie viele Zyklen enthält der Bildungsträger-Prozess? Genau einen. Der Bildungsträger-Prozess ist fett markiert. Siehe Abb. 7.36!

Abb. 7.36:

Bildungsträger-Zyklus

193

194

7 Übungsaufgaben und Kontrollfragen

103. Wie viele Pool-übergreifende Zyklen enthält die Kollaboration? Genau einen. Der Pool-übergreifende Zyklus ist fett markiert. Siehe Abb. 7.37! Er kann nur im Zusammenwirken mit dem Zyklus im Kundenprozess und mit dem Zyklus im Bildungsträger-Prozess funktionieren.

Abb. 7.37:

Pool-übergreifender Zyklus

Fachbegriffe Englisch-Deutsch Englisch activity ad-hoc sub-process annotation association attached event

Deutsch Aktivität Ad-hoc-Unterprozess Anmerkung Assoziation, Verknüpfung angeheftetes Ereignis, auf der Begrenzungslinie einer Aktivität liegendes Ereignis

boundary event

angeheftetes, auf der Begrenzungslinie einer Aktivität liegendes Ereignis Geschäftsregel-Aufgabe Geschäftseinheit, z. B. Abteilung Vertrieb oder Personal

business rule task business unit call activity cancel event catching event

collaboration collapsed sub-process compensation compensation event complex gateway conditional event conditional sequence flow conversation conversation link conversation node compensation correlation key

Aufruf-Aktivität Transaktions-Abbruch-Ereignis (ausschließlich für Transaktionen) (eine Nachricht) empfangendes Ereignis, (ein Signal) wahrnehmendes Ereignis, (eine Bedingungsänderung) erfassendes Ereignis usw. Kollaboration, Zusammenarbeit in Form von Nachrichtenaustausch zwischen zwei oder mehreren Teilnehmern zugeklappter Unterprozess Rückgängigmachen der Ergebnisse einer Aktivität Kompensations-Ereignis Komplexes Gateway Bedingtes Ereignis Bedingter Sequenzfluss Konversation Verbindungslinie zu Konversationspartnern Konversationsknoten Kompensation, Rückgängigmachen Zuordnungsschlüssel für Nachrichten

196

Fachbegriffe Englisch-Deutsch

data object data-based exclusive gateway data-store default flow defined

Datenobjekt Datenbasiertes Exklusives Gateway (XOR) Datenspeicher Standardfluss definiert

end event error event escalation event event event-based exclusive gateway event sub-process expanded sub-process

Endereignis Fehler-Ereignis Eskalations-Ereignis Ereignis Ereignisbasiertes Exklusive Gateway Ereignis-Unterprozess aufgeklappter Unterprozess

gateway global sub-process global task group

Gateway Globaler Unterprozess Globale Aufgabe Gruppe, Gruppierung

inclusive gateway initial initiate intermediate event interrupting

Inklusive Gateway (OR) beginnend, Anfangsauslösen, initiieren Zwischenereignis abbrechend

lane link event loop loop activity

Lane, Schwimmbahn Link-Ereignis Schleife Schleifen-Aktivität

managed manual task message message event message flow multi-instance multiple event multiple instance

beherrscht Manuelle Aufgabe Nachricht Nachrichten-Ereignis Nachrichtenfluss Mehrfach-Instanz, mehrere Instanzen Mehrfach-Ereignis Mehrfach-Instanz, mehrere Instanzen

Fachbegriffe Englisch-Deutsch

197

none event non-interrupting

nicht näher spezifiziertes Ereignis nicht abbrechend

optimizing

optimierend

parallel gateway parallel multiple event participant pool process

Paralleles Gateway (AND) Paralleles Mehrfach-Ereignis Teilnehmer, Beteiligter Pool Prozess

receive task repeatable

Empfangs-Aufgabe wiederholbar

script task sequence flow send task service task signal event start event sub-process

Skript-Aufgabe Sequenzfluss Sende-Aufgabe Service-Aufgabe Signal-Ereignis Startereignis Unterprozess

task terminate event throwing event timer event transaction

Aufgabe Prozess-Abbruch-Ereignis (eine Nachricht) sendendes Ereignis, (ein Signal) aussendendes Ereignis usw. Zeit-Ereignis Transaktion

user task

Benutzer-Aufgabe

Literatur 1) Allweyer, Thomas, BPMN 2.0 Business Process Model and Notation, Introduction to the Standard for Business Process Modeling, Norderstedt 2010 2) Briol, Patrice, The Business Process Modeling Notation BPMN 2.0 Distilled, 1. Auflage, 2010 3) Business Process Model and Notation (BPMN), Version 2.0, OMG Document Number: formal/2011-01-03, Standard document URL: http://www.omg.org/spec/BPMN/2.0 4) Freund, Jakob und Rücker, Bernd, Praxishandbuch BPMN 2.0, 3. Auflage, München Wien 2012 5) Großkopf, Alexander, Decker, Gero und Weske, Mathias, The Process. Business Process Modeling Using BPMN, Tampa (Florida) 2009 6) Java Magazin, Business Modelling Notation. Vermittler zwischen den Welten; Teil 1 in 9.2009, S. 72 ff.; Teil 2 in 10.2009, S. 72 ff.; Teil 3 in 11.2009, S. 73 ff.; Teil 4 in 12.2009, S. 61 ff. 7) Kneuper, Ralf, CMMI. Verbesserung von Softwareprozessen mit Capability Maturity Model Integration, Heidelberg 2003 8) Mendling, Jan, Weidlich, Matthias und Weske, Mathias (Eds.), Business Process Modeling Notation, Second International Workshop, BPMN 2010, Potsdam, Germany, October 2010 Proceedings, Berlin-Heidelberg 2010 9) Recker, Jan, Evolutions of Process Modeling Grammers, Ontological, Qualitative and Quantitative Analysis Using the Example of BPMN, Berlin Heidelberg 2011 10) Recker, Jan, Indulska, Marta, Rosemann, Michael und Green, Peter, The ontological deficiencies of process modeling in practice, European Journal of Information Systems (2010) 19, S. 501–525 11) Shapiro, Robert, White, Stephan A., Palmer, Nathaniel, zur Muehlen, Michael, Allweyer, Thomas, Gagné, Denis et al, BPMN 2.0 Handbook, Lighthouse Point (Florida) 2011. 12) Silver, Bruce, BPMN Method and Style, Aptos (Californien) 2009

Index Ad-hoc Unterprozess 26 Aktivitäten Definition 13 Angeheftete Zwischenereignisse 95 Anmerkungen 117 Artefakte 117 Assoziationen 118 Aufgabe Anwendungsbeispiele 15 Aufgabentypen 13 Benutzer-Aufgabe 14 Geschäftsregel-Aufgabe 15 Globale Aufgabe 21 Kompensation 20 Manuelle Aufgabe 14 Markierungen 17 Mehrfach-Instanz 18 Schleife 17 Sende- und Empfangs-Aufgabe 15 Service-Aufgabe 14 Skript-Aufgabe 14 Unspezifiziert 14 Aufruf-Aktivität 21 Aufruf-Choreographie 132 Aufruf-Konversation 136 Auslöser 52 Ausnahmefluss 97 Ausnahmen 95 Bedingter Fluss 47 BPMN V, 1 Business Unit 6 call activity 59, 183 Cancel 30 Capability Maturity Model 1, 2, 12, 199 Reifegrade 1 Choreographie Aktivität 131 Aufgabe 131 Diagramm 133 eingebettet in Kollaboration 134 globale Choreographie-Aufgabe 135 globaler Choreographie-Unterprozess 135 Unterprozess 131, 135 Dateninputs 119 Datenobjekte 119 Ankopplung 120 Datenobjekt-Sammlung 120

Datenoutputs 119 Datenspeicher 119 Empfangende Ereignisse 52 Empfangs-Aufgabe 15 Endereignisse Eskalation 111 Fehler 112 Kompensation 111 Mehrfach 110 Nachricht 109 Prozess-Abbruch 112 Signal 110 Transaktions-Abbruch 112 Übersicht 108 Unspezifiert 109 Ereignisbasiertes Gateway 42 Modellierungskonventionen 43 Ereignisse angeheftet 95 empfangend 52 Endereignisse Übersicht 108 Gesamtübersicht 55 sendend 52 Startereignisse Übersicht 57 Überblick 51 Zwischenereignisse Übersicht 82 Ereignis-Unterprozess allgemein 31 Beispiele 64 Ergebnisse 51 Exklusives Gateway 35 Arten 36 Modellierungskonventionen 36 Gateway Ereignisbasiertes Gateway 42 Exklusives Gateway 35 Inklusives Gateway 40 Instanziierend 45 Komplexes Gateway 41 Paralleles Gateway 38 Geschäftsprozess Definition 1 Geschäftsprozessmodellierung 2 Geschäftsregel-Aufgabe 15

202 Globale Aufgabe 21 Globale Choreographie-Aufgaben 132 Globale Choreographie-Unterprozesse 132 Globale Konversation 136 Globaler Unterprozess 30 Gruppierungen 118 Inklusives Gateway 40 Instanziierende Gateways 45 Kollaboration 127 Zyklische 129 Kompensation angeheftetes Zwischenereignis 106 Aufgabe 20 Endereignis 111 Ereignis-Unterprozess 78 Unterprozess 27 Komplexes Gateway 41 Konversation 135 Konversations-Diagramm 137 Konversations-Knoten 136 Konversations-Link 136 Lane Eigenschaften 6 Manuelle Aufgabe 14 Marken-Konzept 11, 39, 175, 189 Definition 11 Markierung von Aufgaben 17 Mehrfach-Aufgabe 163, 165, 166 Mehrfach-Instanz Aufgabe 18 Unterprozess 25 Mehrfachteilnehmer 128, 137, 147, 149, 150, 165, 177 Mehrfach-Teilnehmer 163, 166 Nachrichtenfluss Eigenschaften 8 Übertragener Inhalt 129 Nutzenpotenziale 3 Paralleles Gateway 38 Übersicht 40 Partnerrollen allgemeine 138 spezifische 6 Pool Anordnung 9 Eigenschaften 6 Prozess 7 Prozess-Elemente Übersicht 5 Prozess-Instanz 2, 3, 11, 40, 45 Schleife 17, 25, 92, 132 Aufgabe 17 Unterprozess 25 Sende-Aufgabe 15 Sendende Ereignisse 52

Index Sequenzfluss Eigenschaften 8 Skript-Aufgabe 14 Standardfluss 40 Startereignisse Modellierungskonventionen 57 Übersicht 57 Unspezifiziert 58 Startereignisse Ereignis-Unterprozess Bedingung 70 Eskalation 76 Fehler 80 Kompensation 78 Mehrfach 72 Mehrfach-Parallel 74 Nachricht 65 Signal 67 Übersicht 64 Zeit 69 Teilnehmer 6 Terminate 112 Transaktionsunterprozess 28 Unspezifizierte Aufgabe 14 Unterprozess Ad-hoc 26 allgemein 22 Arten 23 Ereignis-Unterprozess 31, 64 Globaler Unterprozess 30 Kompensation 27 Mehrfach-Instanz 25 Modellierungskonventionen 23 Schleife 25 Transaktion 28 Zwischenereignisse Übersicht 82 Zwischenereignisse – angeheftete Abbruch 106 Bedingung 101 Eskalation 104 Fehler 106 Kompensation 106 Mehrfach 102 Nachricht 97 Parallel-Mehrfach 103 Überblick 95 Zeit 99, 101 Zwischenereignisse – nicht angeheftete Eskalation 89 Kompensation 91 Link 92 Mehrfach 88 Nachricht 84 Parallel-Mehrfach 89 Signal 86 Unspezifiert 92