Business Process Diagramms Zusammenfassung der BPMN Specifikation 1.1

Transkript

1 Business Process Diagramms Zusammenfassung der BPMN Specifikation 1.1 Business Process Diagramme bestehen aus 4 Grundarten von Objekten: 1. Flow Objekte 2. Connecting Objekte 3. Swimlanes 4. Artifacts Die Flow Objekte sind die wichtigsten grafischen Elemente, es gibt drei verschiedene Arten: 1. Events 2. Activities 3. Gateways Die Flow Objekte können auf drei verschiedene Arten mittels der Connecting Objekte verbunden werden: 1. mittels Sequence Flows 2. mittels Message Flows 3. mittels Associations Unter Swimlanes versteht man Elemente, die der Gruppierung von Flow-Objekten dienen: 1. Pools 2. Lanes Zusatzinformationen können über Artifacts ins Diagramm gebracht werden, hiervon sind drei verschiedene spezifiziert: 1. Data Objekte 2. Groups 3. Annotations Events: Events repräsentieren Dinge, die während der Ausführung eines Prozesses passieren können, sie haben Einfluss auf den Ablauf des Prozesses, führen zur Erzeugung eines Triggers oder eines Ergebnisses. Start Event: stellt den Eintrittspunkt für den Prozess dar. Kann einen Trigger beinhalten, der angibt, was der Grund für das Event ist (bsp. Message). Kann lediglich auf Trigger reagieren, aber selbst keine Aussenden, das bedeutet, es gibt Start Events nur in der Catching Form. Ein StartEvent darf keine eingehenden Flows haben. Jedes StartEvent muss mindestens einen ausgehenden Flow haben. Wenn mehrere Flows von einem StartEvent ausgehen, werden mehrere parallele Pfade geöffnet, für jeden wird ein Token generiert. Ein StartEvent darf keine ConditionalFlows als abgehende Kanten haben. Ein Sub-Prozess muss kein StartEvent haben. Ansonsten ist StartEvent zwingend erforderlich, sobald es ein EndEvent gibt. Beim Vorkommen mehrerer StartEvents soll bei jedem Start eine neue Instanz des Prozesses instantiiert werden. Sobald ein StartEvent auftritt wird ein neuer Prozess instantiiert und ein Token für jeden ausgehenden Flow vom StartEvent generiert und auf die Reise geschickt. Jedes Token hat eine eindeutige id. (Siehe Token). Die Tokens

2 beginnen sofort mit dem Ablaufen des Prozesses und warten nicht auf weitere StartEvents. PlainStartEvent: Dient als Einstiegspunkt des Prozesses, Token werden generiert und der Ablauf des Prozesses begonnen. MessageStartEvent: Eine Message kommt an und triggert somit den start des Prozesses. Nur MessageStartEvents dürfen das Ziel eines MessageFlow sein, der damit den Trigger schaltet und den Prozess zum Starten bringt. message: Message Nachricht, welche den Start des Prozesses triggert. TimerStartEvent: Time-Date oder bestimmter Rhythmus (jeden Montag) triggern den Start. timer:timerdate Zeitpunkt oder Intervall, der den Start triggert. Conditional: Dieses Event wird getriggert, wenn eine boolsche Bedingung erfüllt wird, die mit dem Event assoziiert ist. condition:condition Bedingung, welche erfüllt werden muss, um den Start zu triggern. SignalStartEvent: Wird getriggert, wenn ein assoziiertes Signal ankommt. Signale werden per Broadcast gesendet, haben also kein spezifisches Ziel, sondern werden von allen Elementen, die auf dieses Signal warten, aufgenommen und verarbeitet. signal:signal Signal, welches per Broadcast empfangen werden muss, um Start zu triggern. MultipleStartEvent: Es gibt verschiedene Möglichkeiten das Event zu triggern. MultipleStartEvents dürfen nur dann Ziel eines MessageFlow sein, wenn sich eine Message in der Attributliste befindet.

3 multiple:eventlist Liste von möglichen Eventtypen, die vorkommen können, um den Start des Prozesses zu triggern. Intermediate Event: liegt irgendwo im Pfad zwischen Beginn und Ende des Prozesses. Kann einen Trigger beinhalten, der den Grund für das Event angibt. Sie können Trigger sowohl Aussenden, als auch darauf reagieren, die unterschiedliche Verhaltensweise wird durch gefüllte ( catching ) bzw. ungefüllte ( throwing ) Symbole innerhalb des Events dargestellt. Einige IntermediateCatchingEvents können an Kanten von Activites auftreten, um spezielles Verhalten zu beschreiben. Bei Throwing Events wird der Trigger sofort ausgelöst und das Token läuft sofort auf der ausgehenden Kante weiter. Bei Catching Events verbleibt das Token so lange im Event, bis der Trigger vorhanden ist. IntermediateEvents die auf der Kante einer Activity liegen dürfen keine eingehenden Kanten haben, aber müssen genau eine ausgehende Kante haben. CompensationIntermediateCatchingEvents dürfen keinerlei Flow haben, sondern sind über Association mit einer CompensationActivity verbunden. PlainIntermediateEvent: wird benutzt um gewisse Änderungen im Prozessstatus anzuzeigen. MessageIntermediateCatchingEvent: Eine Nachricht trifft ein und triggert damit das Event. Wenn der Prozess auf die Nachricht gewartet hat wird er nun weitergeführt. message:message target:activity Nachricht, auf welche gewartet wird. Gibt an, dass das Event an der Kante der Activity haftet und für Fehlerbehandlung benutzt wird. MessageIntermediateThrowingEvent: Eine Nachricht wird gesendet und der Prozess läuft sofort weiter. Dieses Event kann Ziel eines MessageFlow sein. message:message Nachricht, welche versendet werden soll. TimerIntermediateCatchingEvent: Event wird von einem Timer getriggert. Kann als Verzögerung benutzt werden. timer:timerdate Zeitpunkt oder Intervall, der das Event triggert.

4 target:activity Gibt an, dass das Event an der Kante der Activity haftet und für Fehlerbehandlung benutzt wird. ErrorIntermediateCatchingEvent: Dieses Event kann nur an der Kante einer Activity verwendet werden. Es reagiert auf einen bestimmten Fehler oder auf alle, falls kein bestimmter angegeben ist. Dieses Event kann Quelle eines MessageFlow sein. error:string target:activity Fehlercode des Fehlers, auf welchen reagiert wird. Gibt an, dass das Event an der Kante der Activity haftet und für Fehlerbehandlung benutzt wird. CancelIntermediateCatchingEvent: wird an einer Transaction benutzt. Es kann nur an dessen Kante benutzt werden. Es wird getriggert, wenn ein CancelEndEvent innerhalb der Transaction erreicht wird und wenn eine Cancel Nachricht auf dem Transaction Protokoll ankommt. target:transaction Gibt an, dass das Event an der Kante der Transaction haftet und für Fehlerbehandlung benutzt wird. CompensationIntermediateCatchingEvent: wird auf der Kante einer Activity benutzt und zeigt an, dass diese kompensiert werden kann. Wird von einem auftretenden CompensationIntermediateThrowingEvent getriggert, wenn die Activity, an welcher es haftet identifiziert wird, oder wenn keine identifiziert wurde und alle bisherigen Activities kompesiert werden sollen. Das Triggern bewirkt, dass die über eine Assoziation mit dem Event verbundene CompensationActivity durchlaufen wird. target:activity Gibt an, dass das Event an der Kante der Activity haftet und für Kompensation benutzt wird. CompensationIntermediateThrowingEvent: wird benutzt, um Kompensation zu aktivieren. Es zeigt an, dass diese notwendig ist. Es kann eine bestimmte Activity anspringen, oder aber alle bisher abgelaufenen. ToCompensate:Acti vity Identifiziert die Activity die kompensiert werden soll. ConditionalIntermediateCatchingEvent: wird getriggert, wenn die assoziierte Bedingung wahr wird.

5 condition:condition target:activity Bedingung, welche das Event triggert. Gibt an, dass das Event an der Kante der Activity haftet und für Kompensation benutzt wird. LinkIntermediateCatchingEvent: Links können benutzt werden um unterschiedliche Prozesse miteinander zu verbinden oder Loops zu erzeugen. Außerdem können sie als Off-Page Verbindung benutzt werden. Es kann immer nur ein CatchingEvent mit einem bestimmten Namen geben, der aber von mehreren ThrowingEvents aus angesprungen werden kann. link:link Link der benutzt werden soll. LinkEvents werden über den linkname miteinander verbunden. Catching und Throwing Events welche zusammengehören haben denselben linkname. LinkIntermediateThrowingEvent: ist die Quelle der Link-Verbindung und verweist auf ein CatchingEvent, welches als Ziel dient. link:link Link der benutzt werden soll. SignalIntermediateCatchingEvent: Kann benutzt werden um Signale zu empfangen. Kann nur an Kanten von Activities verwendet werden. target:activity signal:signal Gibt an, dass das Event an der Kante der Activity haftet und für Kompensation benutzt wird. Signal auf welches gehört werden soll. SignalIntermediateThrowingEvent: sendet ein spezielles Signal an alle aus, die an diesem Signal interessiert sind. signal:signal Signal welches gesendet werden soll. MultipleIntermediateCatchingEvent: Kann auf mehrere Trigger reagieren. Kann auf der Kante einer Activity liegen. Nur einer der angegebenen Trigger ist notwendig, um das Event zu aktivieren.

6 target:activity multiple:eventlist Gibt an, dass das Event an der Kante der Activity haftet und für Kompensation benutzt wird. Liste von möglichen Eventtypen, die vorkommen können, um das Event zu triggern. MultipleIntermediateThrowingEvent: Kann mehrere Trigger generieren. Beim aktivieren werden alle Events gleichzeitig generiert und ausgegeben. multiple:eventlist Liste von möglichen Eventtypen, die vorkommen können, um das Event zu triggern. End Event: kennzeichnet das Ende eines Prozesses. Kann ein Result beinhalten, welches angibt, welche Konsequenz das Beenden des Prozesses an dieser Stelle haben wird. Kann lediglich ein Result erzeugen, aber nicht auf einen Trigger reagieren, das bedeutet es gibt sie nur in der Throwing Form. Ein EndEvent konsumiert ein Token, welches von einem StartEvent generiert wurde. Bei parallel ankommenden Flows werden die Token in der Reihenfolge, in welcher sie eintreffen konsumiert. Alle Tokens eines Prozesses müssen konsumiert werden, bevor der Prozess abgeschlossen ist. Es kann innerhalb eines Prozesses mehrere EndEvents geben. Wenn ein StartEvent vorhanden ist, muss es mindestens ein EndEvent geben. EndEvents sollten die einzigen Objekte ohne ausgehende Kanten sein. Jedes EndEvent muss Ziel mindestens eines Flows sein. Die EndEvents dienen als Senke für alle Tokens, die während des Prozesses generiert wurden. Ein Prozess ist im Status laufend solange nicht alle Tokens von EndEvents komsumiert wurden. Ein EndEvent kann niemals Ziel eines MessageFlows sein. PlainEndEvent: Identifiziert den Endpunkt des Prozesses oder Subprozesses. Wenn es in einem Sub-Prozess verwendet wird, geht die Abflusskontrolle wieder eine Stufe nach oben, zum Elternprozess. id:objekt Textbeschreibung des Objektes, Name MessageEndEvent: Eine Nachricht wird zu einem anderen Teilnehmer gesendet und damit der Prozess abgeschlossen. Ein MessageEndEvent kann Quelle eines MessageFlow sein. id:objekt message: Message Textbeschreibung des Objektes, Name Nachricht, welche gesendet werden muss, und das Ende des Prozesses markiert.

7 ErrorEndEvent: Ein benannter Fehler wird generiert und muss von einem ErrorIntermediateCatchingEvent gefangen werden, welches den gleichen Fehlercode oder gar keinen hat. Dieses Event sollte an der Kante der umschließenden Activity gehen. id:objekt error:error Textbeschreibung des Objektes, Name Fehler, welcher erzeugt wird. CancelEndEvent: wird nur innerhalb einer Transaction verwendet. Zeigt an, dass die Transaction gelöscht werden sollte. Hiermit wird das CancelIntermediateCatchingEvent auf der Kante der Transaction getriggert. Es zeigt auch an, dass eine Cancel Nachricht über das Transaction Protocol zu allen Entitäten gesendet werden soll. id:objekt Textbeschreibung des Objektes, Name CompensationEndEvent: zeigt an, dass Compensation notwendig ist. Wenn eine bestimmte Activity mit einem CompensationEvent versehen ist, wird diese kompensiert, ansonsten werden alle bereits abgelaufenen Activities kompensiert. Dies geschieht in umgekehrter Reihenfolge. Um kompensiert zu werden muss eine Activity das entsprechende Event an der Kante tragen. id:objekt compensation:com pensation Textbeschreibung des Objektes, Name Kompensation des Events SignalEndEvent: ein Signal wird per Broadcast gesendet, dieses Signal wird zu allen Prozessen, welche ein Signal erhalten können gesendet, das Signal kann über verschiedene Hierarchielevel des Prozesses und sogar über Poolgrenzen hinweg empfangen werden. id:objekt signal:signal Textbeschreibung des Objektes, Name Signal, welches ausgesendet wird. TermintateEndEvent: gibt an, dass alle Activities dieses Pools sofort beendet werden müssen. Der Prozess endet ohne Compensation und ohne EventHandling. id:objekt Textbeschreibung des Objektes, Name MultipleEndEvent: es gibt mehrere Konsequenzen bei Prozessende.

8 multiple:eventlist Liste von möglichen Eventtypen, die vorkommen können. Activities: Hierunter werden alle Arbeitspakete, die in irgendeiner Form während des Prozesses zu passieren haben zusammengefasst. Die Activity kann einfach gehalten, oder aber sehr komplex ausgearbeitet sein. Task: Der Task wird benutzt, wenn die Arbeit, die in diesem Schritt durchgeführt werden soll nicht weiter in Unterschritte heruntergebrochen werden soll. Ein Task darf Ziel mehrerer Flows sein, sowohl von parallelen als auch von alternativen Pfaden. Hat ein Task mehrere eingehende Kanten, so wird er instantiiert sobald ein Token auf einem dieser Pfade eingeht. Kommt ein weiteres Token an wird eine neue Instanz des Tasks erstellt. Ist dies nicht gewünscht muss ein Gateway vor dem Task dies behandeln. Ein Token kann mehrere ausgehende Flows haben. Für jeden ausgehenden Pfad wird ein eigenes Token erzeugt. Die TokenId sollte erkennbar machen, dass alle Tokens aus einem parallelen Pfad sind und wie viele Tokens in diesem Pfad vorhanden sind. Ein Task kann Ziel von MessageFlows sein. Es kann pro MessageFlow immer nur eine Nachricht empfangen werden. Hat der Task mehrere eingehende MessageFlows, so kann über alle nur dieselbe Nachricht empfangen werden. Ein Task kann Quelle von MessageFlows sein. Hat er mehrere ausgehende MessageFlows wird diesen nur eine einzige Nachricht zugeordnet, welche über alle MessageFlows gesendet wird. startquantity:integer Darf nicht weniger als 1 sein. Gibt an, wie viele Token den Task erreichen müssen, bevor er gestartet wird. 1 ist die default Belegung completionquantity:integer Sollte beim Task immer 1 sein! Sub-Process: Hierbei handelt es sich um eine Activity, welche einen Unterprozess beinhalten kann. Ein Sub-Prozess kann vor der normalen Ablaufdauer gestoppt werden. Dies geschieht durch IntermediateEvents, welche an der Kante des Sub-Prozesses angebracht sind. Bsp.: Error, Exception. In diesem Fall werdend die Tokens innerhalb des Sub-Prozesses von diesem Event konsumiert. Ein Sub-Prozess kann Ziel mehrerer Flows sein, die sowohl von parallelen als auch von alternativen Pfaden kommen können. Hat der Sub-Prozess mehrere eingehende Kanten, so wird er instantiiert sobald ein Token auf einem der Pfade ankommt. Kommt ein weiteres Token an wird eine weitere Instanz des Sub- Prozesses erzeugt. Falls dies nicht der Fall sein soll, muss mit Gateways vor dem Sub-Prozess gearbeitet werden. Ein Sub-Prozess kann mehrere ausgehende Flows haben. Für jeden wird ein Token generiert. Die TokenId sollte so gewählt werden, dass erkennbar ist, dass sie alle aus dem gleichen Sub-Prozess kommen und parallel sind und wie viele parallele Tokens existieren. Ein Sub-Prozess kann sowohl Ziel als auch Quelle eines MessageFlow sein. startquantity:integer Darf nicht weniger als 1 sein. Gibt an, wie viele

9 Token den Task erreichen müssen, bevor er gestartet wird. 1 ist die default Belegung completionquantity:integer Sollte beim Task immer 1 sein! graphicalelements:object Definiert all die Elemente, die im Subprozess enthalten sind AdHoc Activity: Diese Activity kann Tasks beinhalten. Die Tasks sind nicht durch Flows miteinander verbunden oder dadurch kontrolliert. Die Reihenfolge der Ausführung wird vom zuständigen Bearbeiter festgelegt. startquantity:integer completionquantity:integer adhocordering:string completioncondition:condition Darf nicht weniger als 1 sein. Gibt an, wie viele Token den Task erreichen müssen, bevor er gestartet wird. 1 ist die default Belegung Gibt an, wie viele Token von der Activity generiert werden sollen. Zulässige Werte sind Sequential und Parallel. Gibt an, ob die enthaltenen Tasks alle parallel oder sequentiell nacheinander bearbeitet werden müssen. Muss angegebenen werden und definiert, wann ein AdHoc Prozess endet. Loop Activity: Prinzipiell können auch Sub-Processes Loop Activities sein. Looping kann auch ganz ohne entsprechene Activity mit Sequence Flows beschrieben werden, dies geschieht über rücklaufende Kanten, die somit einen Loop beschreiben. startquantity:integer Darf nicht weniger als 1 sein. Gibt an, wie viele Token den Task erreichen müssen, bevor er gestartet wird. 1 ist die default Belegung completionquantity:integer Gibt an, wie viele Token von der Activity generiert werden sollen. loopcondition:condition loopcounter:integer loopmaximum:integer testtime:string Bedingung die beim durchlauf getestet werden soll. Wird zur Laufzeit benutzt um die Anzahl an Loops zu zählen. Wird automatisch bearbeitet. Muss am Beginn des Loops inkrementiert werden. Optionales Attribut. Kann eine Maximalzahl an Loops angeben. Sie sollte in der loopcondition beachtet werden. Zulässige Werte sind before und after. Gibt an, ob die Bedingung am Anfang oder am Ende des Schleifendurchlaufs geprüft werden soll. Multiple Instances Activity: Spezielle Loops, die foreach repräsentieren. Die Loop expression ist numerisch und wird nur einmal am Beginn der Activity

10 berechnet. Das Ergebnis ist eine Integer, die angibt, wie oft die Activity wiederholt werden soll. Auch Sub-Prozesse können Multi-Instances sein. condition:condition Muss numerisch sein und ein Integer zurückliefern. loopcounter:integer flowcondition:string ordering:string Zählt die Anzahl der Loops. Muss am Beginn des Loops inkrementiert werden. Zulässige Werte sind None, One, All. None: bedeutet, dass alle Instanzen der Activity ein Token generieren, welches durch den Rest des Pfades traversiert. One: bedeutet, dass das eingehende Token weiterlaufen soll, sobald eine der Instanzen der Activity durchlaufen wurde. All: bedeutet, dass das Token weitergeführt werden soll, wenn alle Instanzen beendet wurden. Zulässige Werte sind sequential und parallel. Gibt an ob die einzelnen Instanzen sequentiell oder parallel durchlaufen werden sollen. Transaction: ist eigentlich nur ein Sub-Prozess, aber mit einem speziellen Protokoll das sicher stellt, dass alle Parteien, die an der Arbeit beteiligt sind darüber im Einklang sind, ob die Aktion fertig gestellt oder abgebrochen werden soll. Es gibt drei mögliche Ergebnisse einer Transaction. Erfolgreicher Abschluss (angezeigt durch normalen Flow, der die Transaction verlässt), fehlgeschlagener Abschluss (hier werden beispielsweise die Compensation Activities ausgeführt und ein ausgehender Flow mit einer IntermediateCancelAction an der Kante der Transaction wird entlanggelaufen, nachdem die Compensation beendet ist. Dieser Fall tritt ein, wenn entweder eine CancelEndEvent innerhalb der Transaction erreicht wird, oder aber eine Cancel Message über das Protokoll gesendet wird.) die dritte Möglichkeit ist ein Hazard, dies gibt an, dass etwas komplett schief gegangen ist. Ein normales Abschließen der Transaction, sowie ein Cancel sind nicht mehr möglich. Die Transaction wird ohne Kompensation unterbrochen und ein ausgehender Flow mit einem IntermediateErrorEvent an der Kante wird entlanggelaufen. Beim korrekten Abschluss einer Transaction wird die Ablaufkontrolle nicht sofort an den Elternprozess zurückgegeben, zunächst muss sichergestellt sein, dass alle Teilnehmer der Transaction korrekt abgeschlossen haben. Sollte einer der Teilnehmer in einen Fehler laufen wird die entsprechende Kante der Transactiong gewählt, obwohl diese eigentlich bereits zuverlässig beendet worden war. Gateways: Sie kontrollieren das Auseinander- und Zusammenlaufen des Prozess-Ablaufs. An diesen Stellen können verschiedene Pfade des Diagramms zusammengeführt, synchronisiert, parallelisiert oder auseinander gebrochen werden. Alle Arten von Gateways beeinflussen sowohl die eingehenden als auch die ausgehenden Kontrollfluss-Kanten. Wie der Begriff schon wiederspiegelt handelt es sich um eine Sammlung aus Gates, die das passieren entweder erlauben oder verbieten. Tokens können an dieser Stelle zusammengefasst und/oder auseinander gebrochen werden.

11 Es existiert immer ein Gate für jeden ausgehenden Flow. Ein Gateway kann Ziel und Quelle mehrerer Flows sein. Ein Gateway darf weder Ziel, noch Quelle von MessageFlows sein. Exclusive-Data-Based: Nur einer der ausgehenden Pfade kann während der Laufzeit entlanggelaufen werden. Die Entscheidung welcher der Pfade dies ist (Branching) wird anhand der Bedingungen an den ausgehenden Sequence Flows bestimmt. Sollte keine der Bedingung gültig sein, wird der Default Flow entlanggelaufen. Wenn es keinen Default Flow gibt, muss sichergestellt sein, dass immer eine der Bedingungen während des Ablaufs erfüllt ist, sonst ist das Diagramm ungültig. Die Bedingungen der Gates müssen in einer bestimmten Reihenfolge überprüft werden, die erste Bedingung, die wahr wird stellt das Gate dar, welches passiert werden darf und entscheidet somit, welcher der ausgehenden Flows genommen wird. Dieser Gateway kann auch zum mergen von parallelen Pfaden benutzt werden. Dies ist notwendig, wenn zuvor über einen Gateway der Pfad aufgesplittet wurde, da ansonsten im weiteren Prozessverlauf nicht absehbar ist, auf wie viele Tokens gewartet werden muss. (siehe Spec. Seite 76). Falls mehrere eingehende Flows vorhanden sind werden alle für die Entscheidung über den weiteren Ablauf des Prozesses benutzt. Sobald ein Token auf einem der Flows ankommt wird es durch den Gateway geführt. Jedes ankommende Token wird separat behandelt, es geschieht keine Synchronisation der eingehenden Tokens. Es wird immer nur einer der ausgehenden Flows entlanggelaufen. Dieser Flow wird basierend auf den Conditions gewählt. Die Überprüfungsreihenfolge sollt die Reihenfolge in der Liste der Gates widerspiegeln. Sobald eine Condition wahr wird, wird das entsprechende Gate ausgewählt, die verbleibenden müssen nicht weiter überprüft werden. Falls keine der Conditions wahr wird, wird das default Gate entlanggelaufen. Das Token wird auf dem entsprechend gewählten Flow weitergeschoben. gates:gate defaultgate:gate Beliebige Anzahl an Gates. Ein default Gate kann angegebenen werden. Exclusive-Event-Based: Nur einer der ausgehenden Pfade kann während der Laufzeit entlanggelaufen werden. Die Entscheidung welcher der Pfade dies ist (Branching) wird anhand des Events zur gegebenen Zeit im Prozess durch das spezifische Event (Message o.ä) bestimmt. Die unterschiedlichen Events, die entstehen können werden nach dem Gateway durch die entsprechenden Event Symbole gekennzeichnet, es wird der Pfad des gültigen Events gegangen. Alle von diesem Gateway ausgehenden Flows müssen ein Event als Ziel haben. gates:gate Beliebige Anzahl an Gates. Inclusive: auch hier liegen an den ausgehenden Kanten des Gateways Bedingungen an, jedoch sind diese unabhängig voneinander. Sie werden alle zur Laufzeit evaluiert und jede der gültigen Kanten kann benutzt werden, dies bedeutet insbesondere auch, dass mehrere Tokens (für jede gültige Kante) den Gateway verlassen können. Dieser Gateway entspricht gewissermaßen einer Gruppierung von unabhängigen JA/NEIN Entscheidungen. Der Ablauf sollte so modelliert sein, dass mindestens einer der Pfade entlanggelaufen wird. Anstatt des Gateways können auch mehrere Conditional Flows an einer Activity angebracht werden. Für jede tatsächlich entlanggelaufene ausgehende Kante wird ein Token mit einer entsprechenden Id erzeugt.

12 Gibt es mehrere eingehende Flows, so wird der Gateway geschaltet sobald alle der eingehenden Kanten, auf denen ein Token erwartet wird, ein Token geliefert haben. Es sollte mindestens ein, es können aber auch mehrere der ausgehenden Flows über ihr Gate selektiert werden. Alle Gates werden immer überprüft. Sobald eine Condition wahr wird, wird das entsprechende Gate geschaltet, egal was im weiteren Verlauf noch passieren wird. gates:gate Beliebige Anzahl an Gates. defaultgate:gate Ein default Gate kann angegebenen werden. Complex:Diese Art von Gateways wird dazu benutzt Situationen zu behandeln, für die die übrigen Gateways nicht ausreichen. Wird der Gateway als Decision benutzt, wird der zu wählende ausgehende Flow anhand einer Condition berechnet, welche angibt, wann der Prozess weiter läuft. Eine Expression kann beispielsweise Prozessdaten überprüfen und darauf basierend verschiedene ausgehende Flows wählen. Die Expression sollte so gewählt sein, dass mindestens eine der ausgehenden Kanten gewählt wird. Wenn der Gateway als Merge benutzt wird, so bestimmt eine Expression welche der eingehenden Kanten benötigt werden, damit der Prozess weiterlaufen kann. Die Expression kann ihre Berechnungen anhand von Prozessdaten und den eingehenden Flows tätigen. (Bsp.: irgendwelche 3 von 5 eingehenden Token werden durchgeleitet). Bei mehreren eingehenden Kanten läuft der Prozess weiter, sobald die richtige Anzahl an Tokens von den richtigen Flows eingetroffen ist. Es dürfen auch weitere Tokens eintreffen, diese werden aber für die Entscheidung über das weiterlaufen nicht berücksichtigt. Es kann ein, oder auch mehrere der ausgehenden Flows entsprechend der Condition benutzt werden. gates:gate Beliebige Anzahl an Gates. incomingcondition:conditi on outgoingcondition:conditio n Muss gesetzt werden, wenn es mehrere eingehende Kanten gibt. Benutzt Flow Namen und Prozessdaten zur Berechnung. Muss gesetzt werden, wenn es mehrere ausgehende Kanten gibt. Benutzt Flow ids und Prozessdaten zur Berechnung. Parallel: Der Term Fork beschreibt das Aufteilen eines Pfades in zwei oder mehr parallele Pfade. Dies kann zum einen durch diesen Gateway, jedoch auch durch das anfügen von mehreren Sequence Flows an eine Activity geschehen (uncontrolled Flow). Der Term Join hingegen bezeichnet das zusammenführen mehrerer paralleler Pfade mittels Gateway zu einem Pfad. Diese Art von Flow wird benutzt um parallele Pfade zu synchronisieren, aber auch, um einen Pfad in mehrere parallele Pfade aufzuteilen. Wenn es mehrere eingehende Kanten gibt, werden alle von diesen benutzt um den Prozessfluss weiterzuführen. Alle Token werden synchronisiert. Der Prozessfluss geht weiter, sobald auf allen eingehenden Kanten ein Token angekommen ist. Der Prozess wartet also auf alle notwendigen Signale. Tokens werden aus dem Gateway auf alle ausgehenden Flows gelegt. Hier ist die TokenId zu beachten, die so vergeben werden sollte, dass die parallele Natur der Flows, soweie die Anzahl an parallelen Pfaden erkennbar ist.

13 gates:gate Beliebige Anzahl an Gates. Sequence Flows: Beschreiben die Ablaufreihenfolge. Für die Vorlesung SEII können beide als Sequence Flow angesehen werden und müssen nicht unterschieden werden. Normal Flow: Hiermit wird die Ablaufreihenfolge vom Start Event ausgehend durch verschiedene Activities und Pfade bis zum End Event bezeichnet. Uncontrolled Flow: Ablauf, der nicht bedingungsgesteuert ist und nicht durch Gateways fließt. Jeder Flow hat nur eine Quelle und ein Ziel. Quelle und Ziel dürfen nur Events, Activities und Gateways sein. Während des Ablaufs eines Diagramms wird ein Token von der Quelle des Flows über den Flow zum Ziel gesendet. Name des Objektes source:objekt target:objekt conditiontype:string Identifiziert das Objekt, von dem der Flow ausgeht. Identifiziert das Objekt, zu dem der Flow geht. Ist bei dieser Art von Flow mit dem Wert None belegt. Exception Flow: liegt außerhalb des Normal Flow. Verbindet ein Intermediate Error Event, welches auf der Kante einer Aktivität liegt mit der entsprechenden Fehlerbehandlung. Conditional Flow: Hat eine Bedingung, die zur Laufzeit evaluiert wird. Diese Bedingung gibt an, ob der Flow benutzt wird oder nicht. Das Quellobjekt dieses Flows darf kein Event und kein Gateway sein (Gateways haben ihre eigenen Conditions!). Wenn der Flow von einer Activity ausgeht muss es mindestens einen weiteren ausgehenden Flow von dieser Activity geben. Name des Objektes source:objekt target:objekt condition:condition conditiontype:string Identifiziert das Objekt, von dem der Flow ausgeht. Identifiziert das Objekt, zu dem der Flow geht. Bedingung die erfüllt sein muss, damit der Flow entlanggelaufen werden kann. Ist bei dieser Art von Flow mit dem Wert Expression belegt. Default Flow: Dieser Flow ist die Default Belegung, bei Bedingungen, er wird nur benutzt, wenn alle anderen ausgehenden Flows nicht benutzt werden können.

14 source:objekt target:objekt condition:condition conditiontype:string Name des Objektes Identifiziert das Objekt, von dem der Flow ausgeht. Identifiziert das Objekt, zu dem der Flow geht. Bedingung die erfüllt sein muss, damit der Flow entlanggelaufen werden kann. Ist bei dieser Art von Flow mit dem Wert Default belegt. Message Flows: zeigt Nachrichtenfluss zwischen verschiedenen Teilnehmern eines Prozesses. Es ist nicht möglich, mittels Message Flows Elemente zu verbinden, die sich im selben Pool befinden. MessageFlows können auch Elemente innerhalb eines Sub-Prozesses zum Ziel haben. Name des Objektes source:objekt target:objekt message:message Identifiziert das Objekt, von dem der Flow ausgeht. Identifiziert das Objekt, zu dem der Flow geht. Optionales Attribut, identifiziert die Nachricht, die gesendet wird. Association: Mit ihrer Hilfe können Zusatzinformationen an Objekte gehängt werden. Können gerichtet und ungerichtet sein. Name des Objektes source:objekt target:objekt Identifiziert das Objekt, von dem der Flow ausgeht. Identifiziert das Objekt, zu dem der Flow geht. Compensation Association: Sie verbindet eine Intermediate Compensation Event auf er Kante einer Aktivität mit der entsprechenden Compensation Activity. (Dargestellt durch ein rewind ( <<) Symbol) Pool: repräsentiert einen Teilnehmer im Prozess. Kann in mehrere Abschnitte unterteilt werden, die sich dann Lane nennen. Es können mehrere Pools innerhalb eines Prozesses vorhanden sein. Flows können die Grenzen zwischen Lanes desselben Pools überschreiten. Zwischen unterschiedlichen Pools kann eine Kommunikation nur mittels MessageFlows stattfinden. Jedes Diagramm muss mindestens einen Pool enthalten. Name des Pools/Teilnehmers

15 Data Objekte: Haben keinerlei Einfluss auf den Ablauf des Prozesses, dienen nur der zusätzlichen Information über Anforderungen und Ergebnisse einer Activity oder anderer Teile des Prozesses. DataObjekte dürfen nicht über Flows mit den übrigen Objekten eines Diagramms verbunden werden. DataObjekte dürfen nicht über MessageFlows mit den übrigen Objekten eines Diagramms verbunden werden. DataObjekte werden über Assoziationen mit anderen Objekten verbunden. Sie können sowohl an Activities, wie auch an Flows und MessageFlows gebunden werden. Sie haben in keinem Fall einen Einfluss auf den Ablauf des Diagramms. Um Input oder Output einer Activity anzuzeigen können DataObjekte mit gerichteten Assoziationen verwendet werden. Name des DataObjekts state:string Optional. Gibt wieder, welchen Einfluss der Prozess auf das Objekt hatte. Group: gruppiert Activities derselben Kategorie. Die Gruppierung hat keinen Einfluss auf den Ablauf des Prozesses. Ist lediglich eine visuelle Gruppierung. Eine Group ist weder eine Activity, noch kann sie mittels Flows verbunden werden. Sie können Pool Grenzen und Lane Grenzen überschreiten. category:string Die Kategorie von Objekten, die von der Gruppe umspannt werden, graphicalelements:objekt Alle Objekte, die in der Gruppe enthalten sind. Text Annotation: stellt Zusatzinformationen für den Leser des Diagramms bereit. TextAnnotationen werden mittels Assoziationen an die übrigen Objekte geheftet. Sie haben keinen Einfluss auf den Ablauf des Diagramms. text:string Text, welcher als Information im Diagramm angezeigt werden soll. Für den Interpreter: Token: Für den Interpreter wird der Begriff des Tokens eingeführt, welches durch den vom Diagramm dargestellten Prozess traversiert. Hierbei besucht es die auf seinem Weg liegenden Flow Objekte. Das Interpretieren eines Prozesses geschieht über das mitschreiben der Pfade, die von dem/den Token/s durchlaufen werden, auf dem Weg vom Start zum Ende des Prozesses. Dies wird innerhalb einer Protokolldatei gespeichert. Ein Token besitzt eine Unique id, welche es von allen anderen Tokens des

16 Prozesses unterscheidet. Innerhalb eines Prozesses können mehrere Token existieren, weil es nebenläufige oder parallele Pfade im Ablauf geben kann. Beim Parallelisieren sollte eine TokenId von niedrigerem Level zugewiesen werden, sodass klar wird, dass dies eine Parallelisierung bereits vorher vorhandener Token war. Es kann später eine Verscmelzung dieser parallelen Pfade geben, bei welchen die ursprüngliche Token id sich auf diesem Wege wiederherstellen lässt. Ein Token wird vom StartEvent generiert und muss vom EndEvent konsumiert werden. Es muss immer möglich sein, den Pfad des Tokens zu verfolgen, das bedeutet insbesondere, dass es keinen impliziten Fluss im Diagramm gibt, sondern dass immer mittels Flows oder Events klar ist, welchen Weg das Token zu nehmen hat. Ein Token kann auch über Exception Handling Events durch den Prozess dirigiert werden. Ein Token passiert NIEMALS einen Message Flow, für jeden Pool existiert ein eigenes Token, welches den Pfad entlang läuft! Weitere Klassen und Diagram version (0-1):String author (0-1):String language (0-1):String querylanguage:string creationdate:string unique ID, die das Diagramm von anderen Diagrammen unterscheidet Name des Diagramms, textuelle Beschreibung des Diagramms Definiert Versionsnummer des Diagramms Beinhaltet den Namen des Autors des Diagramms Name der Sprache in der Text geschrieben wird (Englisch) Sprache für syntax queries, optional Definiert das Erstellungsdatum des Diagramms modificationdate:string Letzte Änderung des Diagramms pools(1-n):pool documentation:string Ein Diagramm muss immer mindestens einen Pool beinhalten. Textdokumentation über das Diagramm (optional) Gate: stellt die Gates dar, aus denen sich ein Gateway zusammen setzt. OutgoingSequence Flow:Flow Der Flow, der entlanggelaufen werden soll, wenn das Gate schaltet. Bei Exclusive-Date-Based und Inclusive Gateways muss das Gate eine Condition besitzen, die evaluiert werden kann. Bei allen anderen darf keine Condition vorhanden sein. Default Gates haben keine Condition! condition:condition Bedingung, die erfüllt werden muss, um den assoziierten Flow zu passieren. Alle unten stehende Klassen außer EventList erben von EventDetail!!! Message: Nachricht, die gesendet, oder empfangen werden soll. Name:String Textbeschreibung der Nachricht. from:bpmnelement Sender der Nachricht.

17 to:bpmnelement Empfänder der Nachricht. Timer-Date: Timer für das Triggern eines TimerEvents. Eines der beiden Attribute muss gesetzt werden. timedate:string Zeitpunkt des Events timecycle:string Intervall des Events Condition: Bedingung, welche zum Triggern des entsprechenden Events wahr sein muss. Name der Condition expression:string Expression welche geprüft werden soll. Signal: Signal, welches per Broadcast gesendet oder empfangen wird Name des Signals Error: ErrorCode:String Fehlercode des Fehlers Compensation: tocompensate:acti vity Optionales Attribut, gibt die Activity an, die kompensiert werden soll. Link: Name des Links EventList: viele mögliche Typen können beinhaltet sein. Alle sind vom Obertyp EventDetail.