Modellierung artefaktzentrierter Geschäftsprozesse

Transkript

1 Bachelorarbeit Modellierung artefaktzentrierter Geschäftsprozesse Universität Rostock Institut für Informatik Lehrstuhl Theorie der Programmiersprachen und Programmierung vorgelegt von: Martin Nyolt, geboren am Gutachter: Zweitgutachter: Prof. Dr. rer. nat. habil. Karsten Wolf Dr.-Ing. Niels Lohmann Abgabedatum: 21. März 2011

2

3 Kurzbeschreibung In den letzten Jahren hat sich der artefaktzentrierte Ansatz zur Modellierung von Geschäftsprozessen entwickelt, in dem die Objekte eines Prozesses im Vordergrund stehen und nicht der Aktivitätsfluss wie in herkömmlichen Modellen und Beschreibungssprachen, zum Beispiel BPMN. Bei den bisherigen Untersuchungen zu dem Thema standen vor allem formale Modelle im Vordergrund wie sich solche Modelle mit einfachen grafischen Notationen (wie z. B. in BPMN) darstellen lassen war bisher nicht Mittelpunkt der Forschung. In dieser Arbeit wird ein konkreter Ansatz als Basis genommen, welcher auf Petrinetzen basiert und in dem das artefaktzentrierte Paradigma um Orte und Agenten erweitert wurde, und gezeigt wie sich diese formalen Modelle mit BPMN darstellen lassen. Dazu wird die Notation von BPMN passend erweitert und gezeigt, wie sich solche BPMN Modelle automatisch zu einem formalen Modell transformieren lassen. Abstract Over the past few years, the artifact centric approach of modeling business processes has emerged in which the objects, which are acted upon, come first; in contrast to the activities of traditional models and graphical notations like BPMN. Previous research was focused on formal models how such models can be represented by easy-to-use notations (like BPMN) was usually not investigated. This paper shows how a specific approach, which is based on Petri nets and extends the artifact centric paradigm by agents and locations, can be represented using BPMN. For this purpose, BPMN is extended by new elements, and it is shown how such BPMN models can be automatically transformed to a formal model.

4

5 Kapitel 1. Einführung Das Modellieren von Geschäftsprozessen ist für Unternehmen ein wichtiger Bestandteil zur Optimierung der verschiedenen Vorgänge in diesem Unternehmen, sowohl intern als auch mit anderen Organisationen. Ein Beispiel für solche Vorgänge ist zum Beispiel ein Bestellprozess, der das Aufnehmen, Bearbeiten und Versenden einer Bestellung beinhaltet. Die Modelle geben für alle Beteiligten einen Überblick über die Prozesse und erlauben eine Planung und Koordinierung der Abläufe. Anhand der Modelle können die Prozesse analysiert und optimiert werden. Gleichermaßen werden für neue Abläufe zuerst Modelle erstellt, bevor die Abläufe in den Unternehmenseinsatz eingeführt werden. Die Verwendung von formalen Modellen mit einer wohldefinierten Semantik erlaubt zusätzlich die computergestützte oder vollständig automatische Bearbeitung von Geschäftsvorgängen. Auch ist dadurch erst die automatische Überprüfung der Richtigkeit eines Prozesses möglich, ob also der Prozess immer terminiert (frei von Deadlocks und Livelocks) und einen gewünschten Zielzustand erreicht. Eine weit verbreitetes Mittel zur Modellierung von Geschäftsprozessen ist die Business Process Model and Notation [BPMN]. Ein Beispiel ist in Abbildung 1.1 zu sehen. BPMN ist wie viele Modellierungssprachen Fluss oder Ablauf Orientiert, das heißt in dem Modell steht die Reihenfolge der Aktionen im Vordergrund. Das Ziel von BPMN ist es eine leicht verständliche Sprache zu sein, die von jedem verstanden werden kann. BPMN wurde also nicht mit dem Ziel einer formalen Semantik entwickelt, wodurch es sich nicht zum automatischen Ausführen von komplexen Prozessen oder deren Verifikation eignet. In der Version 2.0 von BPMN wurde erstmals eine Ausführungssemantik für Prozesse eingeführt, aber diese deckt noch lange nicht alle Bereiche von BPMN ab. In den letzten Jahren hat sich das artefaktzentrierte Paradigma entwickelt [NC03, NK05, Hul08]: im Vordergrund stehen verschiedene Geschäftsartefakte wie zum Beispiel Bestellungen oder Rechnungen. Dadurch wird nicht in erster Linie modelliert, wie der Prozess bearbeitet wird, sondern welche wichtigen Daten und Objekten (z. B. Formulare) während des Prozesses bearbeitet werden. 5

6 Kapitel 1. Einführung order beer Buyer choose order fill debit send debit to receive cargo from order wine load beer Shipper receive debit from process debit confirm payment send cargo to load wine Abbildung 1.1.: Beispiel eines BPMN-Prozesses zur Bearbeitung einer Bestellung Welche Aktivitäten auszuführen sind wird für jedes Artefakt separat bestimmt. So kann die Komplexität von umfangreichen Abläufen verringert werden, sodass die Modelle effizienter erstellt und vor allem bearbeitet und gewartet werden können. Auch haben Erfahrungen gezeigt, dass die Verständigung von interorganisationellen Abläufen mit dem artefaktzentrierten Ansatz einfacher ist, da man sich schneller darauf einigt was bearbeitet werden muss, als wie etwas bearbeitet werden muss [GBS07]. Die meisten bisher veröffentlichten Ansätze zur artefaktzentrierten Modellierung konzentrierten sich auf Modelle zur Ausführung von Prozessen, die stark an die Softwaretechnik angelehnt sind [KNH + 03, NK05, WK05], oder formale Modelle zur Verifikation bestimmter Eigenschaften [LBW07, BGH + 07, GS07, DHPV09, FHS09]. Im Gegensatz zu BPMN sind diese Modelle (falls sie überhaupt eine natürliche graphische Darstellung besitzen) für Personen ohne einschlägiges Studium in der Regel nicht oder nur schwer lesbar. In dieser Arbeit wird untersucht wie sich das von Lohmann und Wolf vorgeschlagene formale Modell [LW10] mit intuitiveren Modellierungssprachen wie BPMN nutzen lässt. In dem vorgeschlagenen Ansatz werden Artefakte um Agenten (oder Ortsinformationen) erweitert. Ziel dieser Arbeit ist es BPMN so zu erweitern, um Artefakt Modelle zu erstellen und diese automatisch in (Petrinetz )Modelle des Papers zu transformieren. 6

7 Der Rest der Arbeit ist wie folgt gegliedert: In Kapitel 2 wird der Ansatz kurz skizziert, um anschließend einzelne, wichtige Aspekte zu konkretisieren. Im Kapitel 3 wird gezeigt wie sich BPMN erweitern lässt um artefaktzentrierte Prozesse wie in dem Paper beschrieben zu modellieren und aus dem erweiterten BPMN Modell automatisch zu erzeugen. Ein Überblick über weitere Literatur zur artefaktzentrierten Modellierung wird im Kapitel 4 gegeben. Die Ergebnisse der Arbeit werden schließlich in Kapitel 5 zusammengefasst. 7

8

9 Kapitel 2. Petrinetz Artefakte Im ersten Abschnitt dieses Kapitels wird das Paper, auf dem diese Arbeit hauptsächlich aufsetzt, kurz vorgestellt. In dem Paper wurden aber nicht alle Konzept konkret herausgearbeitet; damit ist gemeint, dass nicht beliebige Petrinetze in den Artefakten erstellt werden dürfen, sondern dass diese bestimmten Pattern folgen[loh11]. Deshalb werden in den weiteren Abschnitten alle wichtigen Konzepte und Pattern entwickelt und dargestellt, um daraus BPMN angemessen zu erweitern Überblick über Petrinetz Artefakte Bei den artefaktzentrierten Choreographien [LW10] werden zu den Artefakten auch Agenten modelliert und so die Verteilung der Artefakte beschrieben. Die Idee ist, dass ein Artefakt von Agenten bearbeitet wird, die sich an unterschiedlichen Orten aufhalten; ein Artefakt befindet sich immer bei genau einem Agenten. Insbesondere soll damit auch die Modellierung von interorganisationellen Geschäftsprozessen erleichtert werden. Die Agenten werden aber nicht explizit modelliert, sondern nur das Artefakt, die Modellierung der Agenten ist implizit. Dazu wird jedem Zustandsübergang / jeder Aktivität eines Artefaktes eine Beschriftung aus einer Menge L gegeben, und jeder Beschriftung wird ein Agent zugeordnet, der diesen Zustandsübergang auslösen darf. Ein Artefakt wird dabei als Petrinetz modelliert (im folgenden Petrinetz Artefakt genannt), dazu gehört die Beschriftung der Transitionen und die erlaubten Endzustände: Definition 1 (Petrinetz Artefakt). Ein Petrinetz Artefakt A = (N, l, Ω) besteht aus einem Petrinetz N = (P, T, F, m 0 ), einer Transitionsbeschriftung l : T L, die jeder Transition eine Aktivität zuordnet, und einer Menge Ω von Endmarkierungen des Petrinetzes N. In dem PN Artefakt werden die Daten also nicht zusätzlich modelliert, konzentriert wird sich auf den Zustand. In dem Zustand (und damit dem Petrinetz) wird auch die Information kodiert, bei welchem Agenten sich das Artefakt befindet und welche Aktionen zu welchem 9

10 Kapitel 2. Petrinetz Artefakte Zeitpunkt ausgeführt werden können. Ein Beispiel ist in Abbildung 2.1 zu sehen 1 dargestellt sind die Artefakte des Bestellprozesses, der Zielzustand und die Policies sind nicht abgebildet. debit fill receivefromshipper sendtoshipper unpaid undecided order filled intransittobuyer intransittoshipper confirm payment orderbeer orderwine process sendtobuyer receivefrombuyer paid beerordered wineordered Ω = {[paid, beerordered], [paid, wineordered]} unloaded processed Ω = loadbeer loadwine receivefrombuyer sendtobuyer intransittobuyer beerloaded sendtoshipper wineloaded Ω = Abbildung 2.1.: Der Bestell Prozess mit Petrinetz Artefakten und Agenten modelliert (ohne Policies) Neben den einzelnen Artefakten gehört zu einem Petrinetz Artefaktmodell noch die Menge A aller Agenten, die vorher schon genannte Menge L von Aktionen und eine Abbildung c : L A, die regelt welche Aktion von welchem Agenten ausgeführt werden darf. Beispiel 1. Für den Prozess aus Abbildung 2.1 ergeben sich die Mengen A = {, } und L = {confirm payment, orderbeer, orderwine, fill, process, loadbeer, loadwine, receivedebitfromshipper, senddebittoshipper,...} Für die Abbildung c gilt unter anderem c(confirm payment) =, c(orderbeer) =, c(loadwine) =. 1 Diese Grafik und der gesamte Bestellprozess, welcher in dieser Arbeit als laufendes Beispiel dient, wurden aus dem Paper entnommen; es wurde lediglich eine Aktivität aus dem Debit Artefakt entfernt. 10

11 2.2. Trennung von Zustand und Ortsinformationen Seien t 1, t 2, t 3 die drei Transitionen des Order Artefaktes von links nach rechts, dann gilt für die Abbildung l dieses Artefaktes l(t 1 ) = confirm payment, l(t 2 ) = orderbeer, l(t 1 ) = orderwine. In dem Paper wird die Bedeutung der Ortsinformationen für verschiedene Artefakttypen untersucht. So gibt es Artefakte, die immer nur von dem Agenten bearbeitet werden können, bei dem sie gerade sind (meist physische Dokumente), mobile Artefakte genannt. Sie lassen sich wie in dem Beispiel des Debit oder Cargo Artefaktes gezeigt modellieren. Es gibt aber auch persistente Artefakte, die von allen Agenten jederzeit zugänglich sind (z. B. das Order Artefakt); in diesem Fall muss das Petrinetz nicht weiter ergänzt werden. Es werden auch noch so genannte transiente Artefakte genannt, für die eine besondere Berechtigung erst einmalig erteilt werden muss, bevor eine Aktion ausgeführt werden darf. Dies lässt sich durch eine zusätzliche Stelle im Petrinetz modellieren, die mit einem Token belegt ist wenn die Berechtigung vorhanden ist. Neben den Ortsinformationen wird auch noch die Möglichkeit eingeführt, weitere Bedingungen (Richtlinien) an das Ausführen von Transitionen zu knüpfen. Solch eine Richtlinie ist nötig, um ungewolltes Verhalten auszuschließen, z. B. das eine Transition nicht vor einer anderen schalten darf. Richtlinien (Policies) werden auch mit Petrinetzen modelliert und werden mit dem eigentlichen Petrinetz Artefakt zusammengeführt. Dabei werden zwei Transitionen t 1, t 2 mit gleichem Label (l(t 1 ) = l(t 2 )) zu einer Transition zusammengefasst, die Vor und Nachbereiche vereinigt. Um aus den Petrinetz Artefakten einen Prozess zu generieren, werden alle Artefakte zu einem einzigen Artefakt vereinigt. Darauf baut dann ein Verfahren auf, bei dem aus dem großen Artefakt und einer gegebenen Menge von Zielzuständen Γ eine Choreographie erzeugt wird (das Artefakt wird als offenes Netz, einer Repräsentation von Services als Petrinetzen, interpretiert das genaue Verfahren wird in [Wol09] beschrieben). Die Autoren benennen ein paar offene Fragen. So ist es unklar, wie mit einer unbegrenzten Zahl an Artefakten umgegangen werden soll. In diese Richtung könnten auch Forschungsergebnisse aus der Programmverifikation dienlich sein. Ein für den praktischen Einsatz interessanter Aspekt ist das Generieren von lokalen Prozessen für jeden Agenten Trennung von Zustand und Ortsinformationen Ein zentrales Konzept des Ansatzes ist die Trennung der Zustände (bzw. Aktivitäten) des Artefaktes, die den Bearbeitungsfortschritt anzeigen, und die Information welcher Agent das Artefakt besitzt. 11

12 Kapitel 2. Petrinetz Artefakte Diese beiden Konzepte sollten, wie in den Beispielen des Papers, auch vollständig getrennt bleiben und zwei disjunkte Petrinetze bilden (lediglich die Zugriffsregelung verbindet diese beiden Netze). Davon ungeachtet können natürlich die Aktivitäten selber in disjunkte Petrinetze zerfallen, wenn die Aktivitäten unabhängig sind Ortsinformationen Die Ortsinformationen modellieren den Austausch der Artefakte zwischen den Agenten. Wenn, wie das Order Artefakt aus Abbildung 2.1, der physische Ort des Artefaktes keine Rolle spielt, oder das Artefakt sich immer nur physisch bei einem Agenten befindet, kann dieses Petrinetz auch leer sein. Sonst muss es folgendem Aufbau entsprechen: Für jeden zu berücksichtigenden Agenten gibt es genau eine Stelle. Zwischen je zwei Agenten darf es zwei gerichtete Verbindungen geben entweder eine einzelne Transition (synchrone Kommunikation), oder zwei Transitionen mit einer zusätzlichen Stelle (asynchrone Kommunikation, wie in Abbildung 2.1). Es muss aber nicht jeder Agent mit jedem verbunden sein, und zwischen zwei Agenten muss keine zwingende Verbindung bestehen 2. Damit können verschiedene Wege des Artefaktes modelliert. So kann es auch denkbar sein, das zwischen zwei Agenten das Artefakt nur in eine Richtung ausgetauscht werden kann, oder dass das Artefakt nur auf einem bestimmten Pfad die Agenten passieren darf (zum Beispiel weil der Transport zu aufwändig wäre). Jeder Agent, der nicht mit einem Start oder End Event verbunden ist, muss mindests eine Aktivität in dem Artefakt existieren, welches von diesem Agenten ausgeführt wird. Ein Agent, der das Artefakt nicht verändert, braucht in der Regel auch nie das Artefakt besitzen. Dies ist lediglich für erste oder letzte Agenten denkbar, die das Artefakt erzeugen oder archivieren, zum Beispiel Zugriffsregelung In dem Paper wurden mobile, persistente und transiente Artefakte unterschieden. In dieser Arbeit wird das Konzept feingranularer gestaltet, sodass sich einzelne Aktivitäten unterscheiden können. Diese Zugriffsregelung ist die Verbindung zwischen den Ortsinformationen und den Aktivitäten. Andere als die nachfolgenden Pattern dürfen nicht verwendet werden. 2 Das Petrinetz sollte aber zusammenhängend sein, damit das Artefakt auch irgendwann jeden modellierten Agenten erreichen kann. 12

13 2.5. Policies Es ist erlaubt, dass Transitionen (Aktivitäten, Zustandswechsel) mit keiner Stelle aus den Ortsinformationen verbunden sind. Dies entspricht dem persistenten Artefakt und bedeutet, dass diese Aktivität remote ausgeführt werden darf und sich das Artefakt nicht im Besitz desjenigen Agenten befinden muss. Falls dies gewünscht ist, muss solch eine Transition mit der Stelle verbunden werden, die dem Agenten entspricht der diese Aktion ausführt (siehe Abschnitt 2.3). Die transienten Artefakte werden derart erweitert, dass pro Agent mehrere Berechtigungen vergeben werden können, auch können mehrere Agenten sich eine Berechtigung teilen. Dazu wird pro Berechtigung eine Stelle hinzugefügt, die im Vor und Nachbereich aller Transitionen ist, deren Ausführung diese Berechtigung erfordert. Zusätzlich muss diese Stelle im Nachbereich mindestens einer Transition sein, sodass diese Berechtigung auch irgendwann erteilt wird Policies Die Policies, die auch wieder durch eigene Petrinetze modelliert werden, sollen auch Einschränkungen unterliegen. So sollen in Policies keine Entscheidungen getroffen werden nur in Artefakten wird Entschieden, in welche Richtung sich der Geschäftsprozess entwickelt. Die Policies sind nur dazu da, die Reihenfolge von Aktivitäten festzulegen, um damit unerwünschtes Verhalten auszuschließen; das heißt in diesem Petrinetz folgt auf eine Stelle höchstens eine Transition. Das bedeutet weiterhin, dass jede verwendete Transition auch eine Entsprechung in einem Artefakt besitzen muss, es dürfen also nur Aktivitäten verwendet werden die auch in irgendeinem Artefakt existieren. Dazu gehören auch die Transitionen der Ortsinformationen, um in der Policy das Besitzen eines Artefaktes modellieren zu können, und das Versenden des Artefaktes einschränken zu können. 13

14

15 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten In diesem Kapitel wird dargestellt wie BPMN erweitert werden kann um artefaktzentrierte Geschäftsprozesse zu modellieren (auf Basis des in Abschnitt 2.1 besprochenen Papers). Im folgenden werden Modelle, die in der erweiterten BPMN dargestellt sind, Artefakt Modelle genannt (im Gegensatz zu Petrinetz Artefakten). In BPMN steht wie schon erwähnt der Aktivitäts oder Kontrollfluss im Vordergrund, der von einzelnen Akteuren bzw. Agenten, Participants in BPMN genannt, ausgeführt wird. Zu den Aktivitäten gehört auch der Austausch von Nachrichten zwischen verschiedenen Participants. Die Modellierung der Daten die von einer Aktivität ausgeführt wird ist nicht direkt in BPMN vorgesehen, es können lediglich anderweitig definierte Daten mit bestimmten Elementen wie Aktivitäten verknüpft werden. Da die Daten aber in dem hier betrachteten Paper nicht betrachtet werden wird darauf nicht weiter eingegangen. Folgende Elemente müssen für eine Modellierung von artefaktzentrierten Modellen nach dem Ansatz in BPMN integriert werden: Partitionieren des Modells in einzelne Artefakte Die auszuführenden Aktivitäten bzw. Zustände des Artefakts Ortsinformationen, wann welcher Agent das Artefakt besitzt Modellieren der verschiedenen Zugriffsarten (mobile, transiente, persistente Artefakte) Definieren der Endzustände eines Artefaktes Definieren der Endzustände des gesamten Modells Policies zur Beschränkung des Verhaltens von Artefakten 15

16 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten Zusätzlich müssen während des Transformierungsprozesses noch die Menge aller Agenten A, die Menge aller Transitionsbeschriftungen L und die den Zugriff regelnde Abbildung c : L A aufgebaut werden. In den folgenden Abschnitten wird erklärt wie BPMN um diese Elemente erweitert werden kann. In den jeweiligen Abschnitten wird auch erklärt, wie ein so erzeugtes Artefakt Modell wieder automatisch in ein Petrinetz Artefakt transformiert werden kann. Einen Überblick über alle neuen oder in der Bedeutung veränderten (bzw. erweiterten) Elemente ist im Anhang zu finden. Anschließend wird in Abschnitt 3.8 kurz dargelegt, wie mögliche zukünftige Werkzeuge den Modellierer beim Erstellen von artefaktzentrierten Geschäftsprozessen unterstützen können. Als letztes wird an einem Beispiel in Abschnitt 3.9 ein kleiner Vergleich zwischen klassischen BPMN Modellen und der in dieser Arbeit entwickelten Erweiterung vorgenommen Partitionieren des Modells in einzelne Artefakte In klassischen BPMN Collaborations ist das Modell in einzelne Participants partitioniert, jeder Participant wird mit einer Lane dargestellt (siehe Abbildung 1.1). Diese umrandete Darstellung bietet sich auch für die Artefakte an, sie werden dadurch klar voneinander getrennt. Damit solch ein Artefakt Diagramm von einer Collaboration unterschieden werden kann sollte aber ein Artefakt anders aussehen als ein Participant, deshalb steht der Name nicht an der Seite über die ganze Lane verteilt, sondern ist durch ein Kästchen in einer Ecke gekennzeichnet. Außerdem wird in Anlehnung an die Daten Objekte in BPMN jedes Artefakt mit einer geknickten Ecke dargestellt werden, welches die Artefakte deutlich als solche sichtbar macht.[loh11] Ein einzelnes leeres Artefakt ist in Abbildung 3.1 zu sehen. Debit Abbildung 3.1.: Ein leeres Debit Artefakt Modell In einer Collaboration ist es erlaubt einen Prozess als Hauptprozess zu definieren, indem kein Rahmen um diesen gezeichnet wird. Der Participant muss in diesem Fall aus dem Diagramm hervorgehen, zum Beispiel das eigene Unternehmen das mit anderen Unternehmen 16

17 3.2. Festlegen der Aktivitäten kommuniziert. Für ein Artefakt Modell ist dies aber hinderlich, da es kein Participant spezifisches Artefakt gibt. Deshalb muss jedes Artefakt mit Namen versehen sein. Aus jedem Artefakt aus dem Artefakt Modell wird ein Petrinetz Artefakt (N, l, Ω) erzeugt. Die Bestimmung der Zielzustände (oder Zielmarkierungen) Ω wird separat in Abschnitt 3.5 erläutert. Die Zuordnung von Transitionen zu Aufgaben l entsteht aus der Vereinigung der beiden Teil Abbildung l Activities und l Agents, deren Konstruktion in den Abschnitten 3.2 bzw. 3.3 erläutert wird. Genauso entsteht N aus der Vereinigung der zwei Petrinetze N Activities und N Agents, und dem Hinzufügen aller Kanten aus F Access, die die beiden disjunkten Netze N Activities und N Agents verbindet und aus den Zugriffsarten erstellt wird (Abschnitt 3.4). Beispiel 2. Für das Artefakt Modell aus Abbildung 3.1 ergibt sich das Petrinetz Artefakt wobei (N, l, {[]}) N = (,,, []) das leere Petrinetz (da, wie später zu sehen, N Activities, N Agents und F Access ihrerseits leer sind) und l nirgends definiert ist ([] bezeichne die leere Markierung) Festlegen der Aktivitäten Jedes Artefakt muss bearbeitet werden und durchläuft mehrere Zustände, der Zustand (entspricht einer Markierung im Petrinetz Artefakt) bestimmt welche Aktivitäten noch ausgeführt werden müssen um zu einem Endzustand zu gelangen. Die Zustände / Aktivitäten in einem Artefakt entsprechen einem normalen Fluss wie in üblichen flusszentrierten Geschäftsprozessen, nur auf das eine Artefakt beschränkt. Deshalb basiert die Modellierung der Aktivitäten auf einem normalen (privaten 1 ) BPMN Prozess, jedoch mit einigen der artefaktzentrierten Modellierung geschuldeten Einschränkungen und Modifizierungen. In BPMN werden Aktivitäten dargestellt durch ein abgerundetes Rechteck mit dem Titel der Aktivität in der Mitte, der ausführende Participant ist durch die Lane (bzw. den Pool) bestimmt. Dies ist bei Aktivitäten eines Artefaktes nicht der Fall, da ein Artefakt von mehreren Participants / Agenten bearbeitet werden kann. Deshalb muss der Agent zusätzlich dargestellt werden. 1 Öffentliche BPMN Prozesse enthalten keine internen Aktivitäten und stellen nur den Nachrichtenaustausch mit anderen Prozessen dar, deshalb spielen sie hier keine Rolle. 17

18 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten Die Darstellung orientiert sich dabei an der Darstellung von Aktivitäten in BPMN Choreographies, wo eine Aktivität einen Nachrichtenaustausch zwischen zwei Participants darstellt und neben dem Titel der Aktivität auch die beiden beteiligten Participants in Streifen am oberen und unteren Rand der Aktivität angezeigt werden, jeweils getrennt durch eine Linie mit dem Rest der Aktivität. Da bei den Aktivitäten eines Artefaktes nur ein Agent beteiligt ist, reicht nur ein solcher Streifen aus. Dieser Streifen befindet sich am unteren Ende des Artefaktes, der obere Streifen wird nicht dargestellt, er ist aber für die Definition von Policies reserviert und wird dort benutzt (siehe Abschnitt 3.7). Ein weiterer Vorteil durch diese Darstellung mit einem Streifen ist, dass das BPMN Diagramm nicht mit normalen BPMN Prozessen, Collaborations oder Choreographies verwechselt werden kann. Es bildet ein eindeutiges Unterscheidungsmerkmal welches das Diagramm sofort als Artefakt Modell erkennbar macht. Das hier verwendete Verfahren zur automatischen Transformation der einzelnen Prozesse in Petrinetze stammt aus einem Artikel von Dijkman et al. [DDO08]. Deshalb gelten die dort aufgeführten Einschränkungen und Annahmen für die BPMN Modelle hier ebenso. Insbesondere zählen dazu: Start und End Events haben genau eine ausgehende bzw. eingehende Kante Aktivitäten besitzen genau eine eingehende und eine ausgehende Kante Gateways sind entweder Entscheidungs oder Parallel Gateways mit genau einer eingehenden und mehreren ausgehenden Kanten, oder Join Gateways mit mehreren eingehenden und genau einer ausgehenden Kante Da sich Inklusiv Oder Gateways mit Parallel und Exklusiv Oder Gateways darstellen lassen werden diese nicht weiter betrachtet Compensations und Transactions werden nicht betrachtet Zusätzlich werden aufgrund der artefaktzentrierten Modellierung weitere Einschränkungen gemacht. So ist die Verwendung von Events grundsätzlich nicht vorgesehen, mit Ausnahme der in Abschnitt 3.4 eingeführten. Es ist lediglich denkbar, Aktivitäten mit einem Kreis wie ein übliches BPMN Event darzustellen (z. B. Timer Event statt warte auf Ablauf der Frist ). Dies kann die Übersichtlichkeit erhöhen, aber da diese Notation keinen echten Mehrwert bietet wird im Folgenden davon abstrahiert. Insbesondere nicht erlaubt sind alle Arten von Message Events. Das Versenden von Nachrichten zwischen Agenten als explizite Aktion eines Artefaktes ist nicht vorgesehen. Nach dem artefaktzentrierten Paradigma entsprechen die Artefakte selbst den ausgetauschten Nachrichten. 18

19 3.2. Festlegen der Aktivitäten Zur Verdeutlichung der ausgeführten Aktivität können auch die verschiedenen BPMN Task Types benutzt werden (z. B. Service Task, User Task, aber keine Message Tasks), sie haben aber keinen Einfluss auf die erzeugten Petrinetz Artefakte. Aktivitäten können auch noch mit weiteren Zeichen versehen sein, die die Zugriffsinformationen regeln. Eine genaue Darstellung wird in Abschnitt 3.4 gegeben. Der Kontrollfluss zwischen den Aktivitäten entspricht dem BPMN Standard, Gateways sind, mit Ausnahme der Event basierten, erlaubt. Da Inklusiv Oder Gateways hier (o. B. d. A.) nicht betrachtet werden, bleiben nur die Exklusiv Oder und Parallel Gateways übrig. Um den üblichen Konventionen von BPMN zu folgen muss der Kontrollfluss von einem Start Event begonnen und einem End Event beendet werden, besondere Typen von Events sind nicht erlaubt, die Kreise dürfen also keine Symbole enthalten. Für einen Prozess sind auch mehrere End Events erlaubt, die verschiedene Zielzustände repräsentieren (siehe dazu Abschnitt 3.5). Wichtig ist bei der Verwendung der Gateways, dass die zwei alternativen Pfade eines XOR Gateways entweder durch ein XOR Gateway zusammengeführt werden oder in Endzuständen enden. Dasselbe wird analog für Parallel Gateways gefordert. Dadurch wird auch ausgeschlossen, dass zwei parallele Pfade durch ein XOR Gateway zusammengeführt werden und umgekehrt. Dies ist für die Bestimmung der Endzustände des Artefaktes notwendig, damit genau bestimmt werden kann welche End Events gleichzeitig erreicht werden und welche sich gegenseitig ausschließen. In dem Verfahren von Dijkman et al. können auch BPMN Prozesse mit Exceptions in Petri Netze umgewandelt werden, daher kann dieser Mechanismus auch in den Artefakt Modellen verwendet werden 2. Wichtig ist nur, dass auch bei einer Exception ein Endzustand erreicht wird, das heißt ein End Event erreicht werden kann. Analog können Sub Prozesse zur Kapselung von mehreren Aktivitäten verwendet werden, auch in Kombination mit Exceptions. Das um Aktivitäten erweiterte Debit Artefakt ist in Abbildung 3.2 dargestellt. Noch nicht modelliert sind die Ortsinformationen (siehe Abschnitt 3.3). Um in einem Artefakt mehrere unabhängige Aktivitäten wie in dem Order Artefakt zu ermöglichen, können mehrere solcher Prozesse mit Start und End Events in einem Artefakt existieren. Die Prozesse dürfen dann keine gemeinsamen Aktivitäten oder andere Elemente besitzen. Ein Beispiel ist in Abbildung 3.5 dargestellt. Aus den modellierten Aktivitäten eines Artefaktes kann nach dem Verfahren von Dijkman et al. [DDO08] das Petrinetz N Activities automatisch generiert werden (inklusive der Startmarkierung). Wenn mehrere unabhängige Teilprozesse in einem Artefakt spezifiziert 2 Nur lokal in den Artefakten, Exception Handling über mehrere Artefakte ist damit nicht möglich und nicht Gegenstand dieser Arbeit 19

20 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten Debit fill process used Abbildung 3.2.: Das Debit Artefakt um Aktivitäten erweitert (ohne Agenten) worden sind, so wird das Verfahren für jeden Teilprozess angewandt und die entstehenden (disjunkten) Petrinetze zu einem einzigen vereinigt. Um die Anzahl der während des Verfahrens entstandenen stillen Transitionen zu minimieren, wird bei der Konstruktion eine erweiterte Menge an Ersetzungsregeln verwendet. Diese stillen Transitionen entsprechen keiner Activity aus dem Modell (und haben auch keine Auswirkung auf den Zustand des Prozesses), sondern sind nur für das Routing der Token verantwortlich [DDO08]. Deren Anzahl zu minimieren ist nicht zwingend notwendig, aber motiviert durch das Ziel, dass die automatisch generierten Petrinetze möglichst klein und übersichtlich bleiben, sodass diese auch manuell leicht bearbeitet werden können. In Abbildung 3.3 sieht man Beispiele für neue Ersetzungsregeln. Die meisten stillen Transitionen werden durch die Gateways erzeugt, da mehrere Gateways hintereinander erlaubt sind. Wird ein Gateway direkt von einer Activity gefolgt, so muss zwischen dem Gateway und der Activity keine zusätzliche Transition geschaltet werden. Analog ist eine Transition unnötig, wenn auf eine Activity direkt ein Gateway folgt. In dem Verfahren werden Start und End Events mit einer gesonderten Transition versehen, die das Starten und Beenden des Prozesses signalisieren. Da dies in dem hier verwendeten artefaktbasierten Ansatz nicht notwendig ist, können Start und End Events auf eine einzelne Stelle ohne weitere Transitionen abgebildet werden. Das Netz N Activities kann aufgrund der Zugriffsarten noch um Stellen und Transitionen erweitert werden, wenn die Modellierung der Zugriffsarten dies erfordert. Das wird aber näher im passenden Abschnitt 3.4 besprochen. Die zum Petrinetz Artefakt gehörende Abbildung l Activities kann anhand der Aktivitäten auch auf natürliche Art und Weise automatisch generiert werden: jeder einer Aktivität entsprechende Transition aus N Activities wird der Titel der Aktivität zugeordnet, der in der entsprechenden Aktivität im Modell steht. Anhand jeder Aktivität wird während der Konstruktion von N Activities auch die für das gesamte Modell globale Abbildung c erweitert, 20

21 3.3. Modellieren der Ortsinformationen task y1 task1 y1 x y2 x task y2 y1 x task2 y2 x task1 task2 y1 y2 x1 task start task y task y x2 y x1 x2 task y Abbildung 3.3.: Vier Beispiele der hinzugefügten Ersetzungsregeln indem jedem Titel der in dem Streifen stehende Agent zugeordnet wird. Gleichzeitig wird jeder Titel und jeder Agent auch den beiden globalen Mengen A und L hinzugefügt. Beispiel 3. Für das Debit Artefakt aus Abbildung 3.2 ergibt sich folgendes Petrinetz N Activities : t 1 t 2 l erhält die Zuordnungen t 1 fill und t 2 process. Die Menge A wird um die Elemente und erweitert, L um fill und process. c wird um die Zuordnung fill und process erweitert Modellieren der Ortsinformationen Die Ortsinformationen bilden den zweiten Teil der Petrinetze der Petrinetz Artefakte. Mit ihnen wird festgelegt, an welchen Orten, das heißt bei welchen Agenten, sich ein Artefakt befindet, und wann es sich im Besitz von welchem Agenten befindet. Welche Agenten ein Artefakt besitzen können lässt sich in der Regel schon aus den Aktivitäten herleiten um eine Aktion auszuführen, muss sich bei (mobilen) Artefakten das Artefakt im Besitz des Agenten befinden (für andere Zugriffsarten siehe Abschnitt 3.4). In 21

22 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten diesem Abschnitt wird erläutert wie festgelegt werden kann, in welcher Reihenfolge Agenten die Artefakte austauschen dürfen, und welcher Agent das Artefakt als erstes besitzt und welche Agenten das Artefakt am Ende besitzen müssen. Die Darstellung der Agenten erfolgt in dem oberen Teil des Artefaktes, die Aktivitäten werden durch einen horizontalen Strich getrennt. Die Agenten werden als abgerundetes Rechteck gezeichnet, ähnlich wie gewöhnliche BPMN Tasks, mit dem Namen des Agenten in der Mitte; Abbildung 3.4 zeigt das Debit Artefakt 3. Zur deutlichen Unterscheidung von Agenten und Aktivitäten befindet sich links neben dem Namen des Agenten zusätzlich ein einheitliches Symbol, welches einen Agenten kennzeichnet. In dieser Arbeit werden einfache (UML )Strichmännchen verwendet. Debit fill process used Abbildung 3.4.: Das Debit Artefakt inklusive Agenten Zwischen den Agenten geben Pfeile an in welcher Richtung das Artefakt ausgetauscht werden kann. Wenn es möglich sein soll zu unterscheiden, ob das Versenden und Empfangen von Artefakten entkoppelt sein soll oder nicht (synchrone / asynchrone Kommunikation), dann kann ein kleines Symbol (zum Beispiel eine kleine Uhr) an einem Übertragungsweg für eine Entkopplung sorgen. Im Folgenden wird aber davon ausgegangen, dass Senden und Empfangen immer entkoppelt ist, und deshalb wird kein Symbol an den Pfeilen stehen. Als weiteres Modell Element sind, wie bei den Aktivitäten zwingend vorgeschrieben, BPMN Start und End Events möglich. Es muss genau ein Start Event existieren und muss auf genau einen Agenten zeigen; dadurch wird festgelegt welcher Agent als erstes im Besitz 3 Im Gegensatz zum Paper von Lohmann und Wolf wird der gewünschte Endzustand, dass das Debit Artefakt beim Shipper sein soll, direkt im Artefakt modelliert statt im globalen Endzustand. 22

23 3.3. Modellieren der Ortsinformationen des Artefaktes ist, das heißt dadurch wird die Startmarkierung des generierten Petrinetzes N Agents festgelegt. Die Verwendung von End Events ist optional, jeder Agent darf mit höchstens einem End Event verbunden sein. Dabei kann entweder ein gemeinsames Event verwendet werden, oder für jeden Agenten ein einzelnes. Jeder Agent, der mit einem End Event verbunden ist, stellt einen möglichen Zielzustand dar. Ist kein Agent mit einem End Event verbunden, so sind alle Agenten mögliche letzte Agenten. Näheres zu den Zielzuständen eines Artefaktes wird in Abschnitt 3.5 besprochen. Es können auch mehrere End Events vorhanden sein, die jeweils von mehreren Agenten geteilt werden, um die möglichen letzten Agenten in Gruppen zu ordnen. Dies kann für die Verwendung mit Policies hilfreich sein (Abschnitt 3.7). Anhand des Agenten Diagramms kann das Petrinetz N Agents = (S, T, F, m 0 ) automatisch generiert werden. Für jeden Agenten a in dem Diagramm existiert eine Stelle s a S ). Für jeden (gerichteten) Pfeil zwischen zwei Agenten a und b existiert weiterhin eine Stelle s a,b S, die anzeigt dass sich das Artefakt auf dem Weg von A nach B befindet ( intransitfromatob ); außerdem werden zwei Transition t a,b, t a,b erzeugt und in T gespeichert, diese beiden Transitionen repräsentieren das Senden bzw. Empfangen des Artefaktes ( sendfromatob, receivefromatob ). Die Flussrelation F wird dann um die Menge {(s a, t a,b ), (t a,b, s a,b ), (s a,b, t a,b), (t a,b, s b )} erweitert. Die Startmarkierung m 0 entspricht der Markierung [x], wenn x der Agent ist, der mit dem Start Event verbunden ist. Dies gilt für die asynchrone Kommunikation, der synchrone Fall geht analog, es wird bloß keine intransit Stelle erzeugt, sondern die beiden Stellen der Agenten direkt durch eine Transition verbunden. Zusätzlich muss aus den Agenten noch die Beschriftungsfunktion l Agents erzeugt werden, die jeder Transition aus dem Netz N Agents einen Titel zuordnet. Dazu bekommt jede Sende Transition t a,b T den Titel l Agents (t a,b ) = sendartifactf romat ob, und jede Empfangs Transition t a,b T den Titel l Agents(t a,b ) = receiveartifactf romat ob, wobei Artifact durch den Namen des Artefakts ersetzt wird. Man beachte, dass die generierten Titel eine längere Form haben als etwa in Abbildung 2.1. Dies ist nötig, da die kurze Variante spätestens bei mehr als zwei Agenten zu Kollisionen führt, daher ist ein kanonischer Name notwendig. Diese Titel werden bei der Generierung des Petrinetzes auch der globalen Menge L hinzugefügt. Gleichzeitig wird sichergestellt, dass jeder Agent auch in der Menge A enthalten ist es ist möglich, dass der Agent keine Aktivität im Artefakt ausführt, aber trotzdem 23

24 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten das Artefakt (als erstes oder letztes) besitzen muss. Als letztes muss noch die Abbildung c erweitert werden, die jeder Aufgabe aus L einen Agenten aus A zuordnet. Dazu wird jeder Transition t a,b T der Agent a zugeordnet, und jeder Transition t a,b T der Agent b. Wenn höchstens ein Agent den Besitz des Artefaktes zum Ausführen von Aktivitäten benötigt (siehe auch den folgenden Abschnitt), dann müssen die Agenten nicht modelliert werden. Abbildung 3.5 zeigt solch ein Beispiel. Dies ist möglich, da die Ortsinformationen irrelevant sind: in beiden Fällen muss das Artefakt nie den Besitzer wechseln, es ist entweder egal (es gibt keinen Agenten, der das Artefakt zur Ausführung einer Aktivität besitzen muss), oder der Agent ist über die gesamte Lebenszeit des Artefaktes eindeutig definiert. In jedem Fall ist N Agents das leere Petrinetz und l Agents die nirgends definierte Funktion. Beispiel 4. Für das Debit Artefakt aus Abbildung 3.4 ergibt sich folgendes Petrinetz N Agents receivedebitfromshippertobuyer intransittobuyer senddebitfrombuyertoshipper intransittoshipper senddebitfromshippertobuyer Für den wahrscheinlich häufig anzutreffenden Spezialfall, dass das Artefakt von jedem Agenten zu jeden Agenten bewegt werden darf, ist es theoretisch auch möglich die Modellierung der Agenten wegzulassen. Für den Fall, dass mehrere unabhängige Aktivitäten (d. h. Start Events) in dem Artefakt sind ist es aber unklar bei welchen Agent das Artefakt sich zuerst befinden soll. Allerdings werden durch diese Vereinfachung mehr Spezialfälle eingeführt, wodurch das Diagramm unter Umständen nicht mehr so einfach zu lesen ist. Deshalb wird von dieser theoretischen Möglichkeit kein Gebrauch gemacht Bestimmen der Zugriffsarten Die Zugriffsart einer Aktion legt fest, wann ein Agent diese Aktion ausführen darf. Wie schon in Abschnitt 2.4 diskutiert, gibt es drei Bedingungen wann eine Aktion von einem 24

25 3.4. Bestimmen der Zugriffsarten Agenten ausgeführt werden darf: das Artefakt muss sich im Besitz des Agenten befinden, der Agent muss vorher eine Berechtigung erhalten haben, oder der Agent darf die Aktion immer ausführen. Im letzten Fall kann die Aktion remote ausgeführt werden, das heißt welcher Agent das Artefakt besitzt ist irrelevant. In den Artefakt Modellen wird standardmäßig davon ausgegangen, dass zur Ausführung der Aktivität der betreffende Agent im Besitz des Artefaktes sein muss. Das heißt das Debit Artefakt in Abbildung 3.4 ist vollständig und entspricht nach der kompletten Transformation dem Petrinetz aus Abbildung 2.1. Ist dies nicht gewünscht und die Aktion darf von dem Agenten remote ausgeführt werden, so wird dies durch ein kleines Symbol, einem geschlängelten Pfeil, rechts neben dem Namen des Agenten gekennzeichnet. Ein Beispiel dafür ist in Abbildung 3.5 dargestellt. Order confirm payment paid order beer beer ordered choose order order wine wine ordered Abbildung 3.5.: Das Order Artefakt keine Aktion ist an den Besitz des Artefakts gebunden Weiterhin muss es die Möglichkeit geben Aktivitäten zu modellieren die eine vorherige Berechtigung erfordern. Dabei darf eine Aktivität (oder mehrere) solange nicht ausgeführt werden, bis eine Berechtigung erteilt wurde. Dies entspricht genau der Semantik von BPMN Events, welche deshalb dazu verwendet werden[loh11]. Dazu wird vor jeder Aktivität, die solche eine Berechtigung erfordert, ein empfangendes Event ( catching event ) gesetzt (mit einem Schlüssel Symbol in der Mitte). Analog dazu wird ein zugehöriges sendendes Event ( throwing event ) dem Kontrollfluss hinzugefügt, wenn diese Berechtigung erteilt werden soll. Ein Beispiel (ohne Bezug zum Bestellprozess) ist in Abbildung 3.6 zu sehen. 25

26 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten Dabei werden die Events (sendend und empfangend) nicht durch einzelne Transitionen dargestellt, sondern sind immer mit einer (oder mehreren) Aktivitäten verknüpft. Zusätzlich kann jedes Event mit einem Namen versehen werden, um pro Artefakt mehrere Berechtigungen zu modellieren. Secret send link keeper gaze Abbildung 3.6.: Ein Artefakt mit einer Aktivität, die eine Freischaltung benötigt Die Zugriffsarten auf Aktivitäten bestimmen die Flussrelation F Access und somit die Verbindung zwischen den beiden Teilpetrinetzen N Activities und N Agents, außerdem muss N Activities um Stellen und Kanten erweitert werden, um die Berechtigungen abzubilden. Für jede Berechtigung r die im Artefakt enthalten ist wird das Petrinetz N Activities = (S, T, F, m 0 ) zusätzlich noch um eine Stelle s r erweitert diese zeigt eine vorhandene Berechtigung an. Zusätzlich wird für jede Transition t einer Aktivität auf der ein Event folgt, das eine Berechtigung r erteilt, F um das Paar (t, s r ) erweitert. F Access setzt sich zusammen, indem für jede Aktivität folgende Kanten hinzugefügt werden: Sei t die zur Aktivität gehörende Transition aus N Activities, a der Agent der die Aktivität ausführt und s a die zu a gehörende Stelle aus N Agents und, falls vorhanden, s r (aus N Activities ) die Stelle, die eine vorhandene Berechtigung r anzeigt. Für jede Aktivität, die mit keinem Symbol gekennzeichnet ist (der Besitz ist notwendig), und von einem Agenten a ausgeführt wird, enthält F Access die Paare (s a, t) und (t, s a ) dadurch kann die Aktivität nur ausgeführt werden, wenn der Agent das Artefakt besitzt. Für jede Aktivität, die eine vorherige Berechtigung erfordert, enthält F Access die Paare (s r, t) und (t, s r ) dadurch kann die Aktivität nur ausgeführt werden, wenn die Berechtigung erteilt wurde. 26

27 3.5. Generieren der Endzustände eines Artefaktes Für jede Aktivität, die eine eine Berechtigung erteilt, enthält F Access das Paar (t, s r ) dadurch wird die Berechtigung eingeräumt. Für jede andere Aktivität, das heißt solchen die mit einem Pfeil gekennzeichnet sind, wird F Access um nichts erweitert die Aktion kann unabhängig vom Besitz oder anderen Berechtigungen ausgeführt werden. Beispiel 5. Das Secret Artefakt aus Abbildung 3.6 wird wie folgt in ein Petrinetz transformiert: send link keeper accessable gaze Die Flussrelation F Access besteht aus den beiden Kanten zwischen der accessable Stelle, welche noch zum Netz N Activities gehört, und der gaze Transition des Netzes N Agents. Für das Debit Artefakt aus Abbildung 3.4 ist F Access deutlich in Abbildung 2.1 zwischen den beiden Teilnetzen zu sehen Generieren der Endzustände eines Artefaktes In diesem Abschnitt wird besprochen wie für ein Artefakt die Menge der Zielzustände Ω automatisch generiert werden kann. Die Zielzustände basieren auf den Aktivitäten (Abschnitt 3.2) und den Agenten (Abschnitt 3.3). Die Zielzustände dieser beiden Teile können unabhängig voneinander betrachtet werden, daher wird im Folgenden zuerst erläutert wie die Zielzustände Ω Activities, und danach wie Ω Agents generiert werden. Dazu sei nachfolgend die Komposition oder Vereinigung von zwei Markierungen m 1 eines Petrinetzes N 1 = (S 1, T 1, F 1, m 01 ) und m 2 eines Petrinetzes N 2 = (S 2, T 2, F 2, m 02 ) definiert als (m 1 m 2 )(p) := m i (p) gdw. p P i, i {1, 2} [LW10]. Diese Markierung ist in den hier verwendeten Fällen immer wohldefiniert, da nur Markierungen von disjunkten Petrinetzen vereinigt werden. Weiterhin sei die Kombination von zwei Markierungsmengen Ω 1 und Ω 2 definiert als Ω 1 Ω 2 := {m 1 m 2 m 1 Ω 1, m 2 Ω 2 }. Das heißt von zwei (unabhängigen) Petrinetzen ist für einen Endzustand jede beliebige Kombination der Endzustände der Teilnetze erlaubt. 27

28 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten Sind wie nachfolgend erklärt Ω Activities und Ω Agents bestimmt worden, so ist Ω = Ω Activities Ω Agents, da beide Netze unabhängige Endzustände haben und jede Kombination möglich ist. Wie schon beschrieben ist es möglich, mehrere unabhängige Aktivitätsflüsse in einem Artefakt zu modellieren (zum Beispiel Abbildung 3.5). Da diese unabhängig sind können die verschiedenen Zielzustände also beliebig kombiniert werden (dies kann aber mit den Endzuständen des Gesamtsystems und Policies eingeschränkt werden, siehe die nächsten beiden Abschnitte). Wenn für n unabhängige Aktivitätsflüsse die Zielzustände, wie im Folgenden beschrieben, als Ω 1,..., Ω n ermittelt wurden, so ergibt sich für die Menge der Zielzustände Ω Activities = Ω 1 Ω n. Wenn ein Aktivitätsfluss genau ein End Event besitzt, welches zu einer Stelle p im Petrinetz überführt wurde, so ist für diesen Fluss die Menge der Zielzustände einfach {[p]}, da der Teil Prozess nur dann beendet wird, wenn das einzige End Event erreicht wird. {[1, 2, 4], [1, 3, 4]} {[p, b], [p, w]} {[1, 2, 4], [1, 3, 4]} {[2], [3]} {[1, 2], [1, 3]} {[2, 4], [3, 4]} {[p, b], [p, w]} {[1]} {[4]} {[b], [w]} {[p]} {[2], [3]} {[w]} {[b]} (a) Order Artefakt mit expliziter Parallelität {[2]} {[3]} (b) Beispiel wo nicht jede Kombination von Zielzuständen zulässig ist Abbildung 3.7.: Zwei Beispiele zur Bestimmung des Endzustandes Wenn mehrere End Events existieren, dann muss Ω Activities so gewählt werden, dass End Events auf parallelen Pfaden in jeder Kombination auftreten, und End Events auf sich 28

29 3.5. Generieren der Endzustände eines Artefaktes ausschließenden Pfaden nie zusammen in einem Endzustand existieren. Zur Konstruktion von Ω Activities kann folgendes Verfahren verwendet werden: 1. Zur Vereinfachung wird davon ausgegangen, dass Gateways höchstens zwei ausgehende bzw. eingehende Kanten haben. Das heißt Gateways mit mehr als zwei ein / ausgehenden Kanten werden durch eine entsprechende Verkettung mehrerer Gateways ersetzt 2. Der einzelne Prozess wird auf die Gateways reduziert, das heißt alle Aktivitäten werden entfernt, sodass ein zusammenhängender, gerichteter Graph entsteht, der ein Start Event besitzt, das mit einem Netzwerk von Gateways verbunden ist, und dessen Blätter End Events sind 3. Jedem Element x (Start /End Event, Gateway) wird eine Zielzustandsmenge Ω(x) zugeordnet die angibt, welche Zielzustände an diesem Element möglich sind. Außerdem wird jeder Menge von Zielzuständen (Markierungen) deren gemeinsamer Definitionsbereich D(x) zugeordnet (Zielzustände einer Menge beziehen sich immer auf die gleichen, gemeinsamen Stellen) 4. Jedem End Event e wird eine (einelementige) Zielzustandsmenge Ω(e) = {[p e ]} zugeordnet, die nur die dem Event entsprechende Stelle p e des Petrinetzes N Activities enthält. Außerdem ist D(e) = {p e } 5. Sei g s das eindeutig bestimmte Gateway, welches mit dem Start Event verbunden ist. Dann gilt Ω Activities = Ω(g s ), wobei für jedes Gateway g des Graphen Ω(g) und D(g) sich wie folgt bestimmen: Ist g ein Gateway, welches zwei (parallele oder alternative) Pfade zusammenführt (das heißt mit einer ausgehenden Kante), so sind die möglichen Endzustände an dem Gateway gleich der möglichen Endzustände am nachfolgenden Element e (End Event oder anderes Gateway): Ω(g) = Ω(e), und folglich ist D(g) = D(e) Ist g ein splittendes Gateway (das heißt zwei ausgehenden Kanten, e 1, e 2 seien die beiden nachfolgenden Elemente), so entspricht der Definitionsbereich der Vereinigung der beiden Definitionsbereiche der Nachfolger: D(g) = D(e 1 ) D(e 2 ) Ist g ein splittendes Exklusiv Oder Gateway, so sind an dem Gateway sowohl die Endzustände von e 1 als auch von e 2 möglich, das heißt: Ω(g) = Ω(e 1 ) Ω(e 2 ) Ist g ein splittendes Parallel Gateway, so sind prinzipiell alle Kombinationen der Endzustände von e 1 oder e 2 möglich (wie auch bei der Kombination der Endzustände Ω Activities von unabhängigen Prozessen), das heißt auf den ersten Blick gilt Ω(g) = Ω(e 1 ) Ω(e 2 ). Dies stimmt aber nicht, wenn die Definitionsbereiche D(e 1 ) und D(e 2 ) nicht disjunkt sind, da in diesem Fall die Kombination m 1 m 2 nicht 29

30 Kapitel 3. Erweiterung von BPMN und Transformation zu Petrinetz Artefakten eindeutig definiert ist, wenn beide Markierungen sich für eine Stelle unterscheiden. Deshalb dürfen nur solche Markierungen kombiniert werden, die an gleichen Stellen die gleichen Werte haben 4 : Ω(g) = Ω(e 1 ) Ω(e 2 ) := {m 1 m 2 m 1 Ω(e 1 ), m 2 Ω(e 2 ), p D(e 1 ) D(e 2 ) : m 1 (p) = m 2 (p)} In Abbildung 3.7 sind für zwei beispielhafte Prozesse die Graphen mit dem zu jedem Knoten zugeordneten Endzuständen zu sehen: Abbildung 3.7(a) entspricht dem Order Artefakt, bei dem die beiden parallelen Prozesse explizit modelliert wurden und in Abbildung 3.7(b) ist ein Beispiel zu sehen, wo bei einem (dem ersten) Parallel Gateway nicht jede Kombination zulässig ist. Die Generierung von Ω Agents ist einfacher und lässt sich direkt aus dem Diagramm bestimmen. Wenn die Agenten nicht modelliert wurden, weil höchstens ein Agent den physischen Besitz benötigt, dann ist wie in Abschnitt 3.3 beschrieben N Agents das leere Petrinetz, also gilt in dem Fall Ω Agents =. Sonst ist N Agents = (S, T, F, m 0 ), S. Jetzt sind zwei Fälle zu unterscheiden: entweder es wurde mindestens ein Agent mit einem End Event verbunden, oder kein Agent ist mit einem End Event verbunden. Im ersten Fall sind also nur die Markierungen als Endzustände erlaubt, die die Stelle von Agenten enthalten die mit einem End Event verbunden sind. Sei S die Menge der Stellen, deren entsprechenden Agenten mit einem End Event verbunden sind, dann ist Ω Agents = {[s] s S }. Für den zweiten Fall wurde in Abschnitt 3.3 festgelegt, dass jeder Agent der letzte Agent sein darf, welches das Artefakt besitzt, das heißt Ω Agents = {[s] s S}. Beispiel 6. Für das Cargo Artefakt aus Abbildung 3.8 sei s die Stelle aus dem Petrinetz N Agents, die anzeigt dass sich das Artefakt beim Buyer befindet und seien s beer und s wine die Stellen aus N Activities, die den beiden End Events entsprechen. Dann ergibt sich nach obigem Verfahren Ω Activities = {[s beer ], [s wine ]} und Ω Agents = {[s ]}, wodurch die gesamten Endzustände des Artefakts Ω = Ω Activities Ω Agents = {[s beer, s ], [s wine, s ]} sind Definieren der Endzustände des Gesamtprozesses Die Endzustände Γ des gesamten modellierten Geschäftsprozesses legen gültige Endzustandskombinationen der einzelnen Artefakte fest, da nicht jede Kombination erwünscht 4 Dies entspricht einem natürlichen Verbund aus der Relationenalgebra 30