5 Konventionen

5.1 Eindeutige Namen

Namen identifizieren verschiedenste Dinge. In der BPMN können sie Prozesse, Rollen, Tasks, Events, Nachrichten, Datastores usw. bezeichnen. Damit diese Dinge eindeutig sind, dürfen Namen nicht mehrfach vergeben werden.

  • Alle Prozesse haben eindeutige, nicht mehrfach verwendete Namen.
  • Alle Organisationen und Rollen haben eindeutige, nicht mehrfach verwendete Namen.
  • Alle Datastores haben eindeutige, nicht mehrfach verwendete Namen.
  • Alle Events haben eindeutige, nicht mehrfach verwendete Namen. Dies ist vor allem über Prozessgrenzen hinweg wichtig, wenn ein End-Event der Start eines anderen Prozesses ist.
  • Alle Nachrichten haben eindeutige, nicht mehrfach verwendete Namen. Dies sollte mindestens innerhalb eines Prozesses gelten.
  • Alle Tasks haben eindeutige, nicht mehrfach verwendete Namen. Dies sollte mindestens innerhalb eines Prozesses gelten.

5.3 Nur ein Startereignis

BPMN erlaubt jedem Prozess beliebig viele Startereignisse zu besitzen. Es ist völlig in Ordnung mehrere Startereignisse und Endereignisse anzulegen, wenn sich eine wirkliche Notwendigkeit für den Prozess ergibt.

  • Hat der Prozess mehrere Start- oder Endereignisse?
  • Falls dies daran liegt, dass der Prozess von anderen Prozessen aus aufgerufen wird und die Ereignisse alle unterschiedlich benannt sind sollte ein einheitlicher Name bestimmt werden und sollten alle Prozesse vereinheitlicht werden.
  • Mehrere Startereignisse können auch ein Hinweis darauf sein, dass ein Prozess eine Mixtur von zwei (oder mehr) Prozessen ist. In diesem Fall empfiehlt sich ein Refactoring, bei dem die unterschiedlichen Prozesse getrennt werden.

5.4 Mehrere Endereignisse vermeiden

BPMN erlaubt einem Prozess verschiedene Endereignisse zu besitzen. Wie im Fall der Startereignisse ist es völlig in Ordnung mehrere Endereignisse zu modellieren, falls der Prozess unterschiedliche Ergebnisse haben kann.

Endereignisse können wiederverwendet werden. Es ist nicht empfehlenswert lange Flows zu modellieren, nur um alle zu einem Endereignis zu bringen. In so einem Fall ist es besser die Ereignisse zu duplizieren, da sie logisch betrachtet weiter nur ein Ereignis darstellen.

5.5 Explizites Splitten von Flows

Es ist möglich den Prozess dadurch aufzuteilen, dass man mehrere Ausgänge aus einem Task modelliert. Allerdings erzeugt dies versteckte Parallelität und diese durch die Lesbarkeit nicht einfach zu finden.

  • Aus einem Task fließt nur eine Verbindung zum nächsten Element.

Aus einem Task fließt nur ein Weg

5.6 Expliziten Zusammenführen von Flows

Genauso wie das Splitten ist es auch möglich, mehrere Flüsse auf einem Task zusammenzuführen. Der besseren Lesbarkeit halber sollte das immer vermieden werden.

  • Flüsse werden immer durch Gateways zusammengeführt.

5.7 Gateways

  • Ein Task erzeugt die Entscheidungsgrundlage für das Gateway und sollte immer vor dem (Exklusiv-oder) Gateway stehen.
  • Der Prozessfluss wird immer (bis auf extrem wenige Ausnahmen) mit der gleichen Art Gateway geteilt und wieder zusammengeführt.
  • Vorsicht bei Parallelität: Sie sollte nur eingesetzt werden, falls unbedingt notwendig.
  • Sequenzflüsse lassen sich auch ohne Gateways modellieren. Davon möchte ich aber dringend abraten, da z.B. Parallelität implizit und schwerer erkennbar wird!
  • Für splitten und Zusammenführen werden getrennte Gateways eingesetzt.

Kein splitten und gleichzeitiges Zusammenführen

5.8 Bedingungen an Gateways

Bedingungen an Gateways müssen in Summe alle Optionen abdecken und dürfen sich zugleich nicht überlappen.

Beispiel: Ein Firma liefert Waren aus.

  • Bestellt man mehr als 100 gibt es einen Rabatt
  • Lücke was geschieht bei exakt 100?
  • Bestellt man unter 100 bleibt der Basispreis bestehen

5.9 Gateways vom gleichen Typ splitten und führen den Flow zusammen

Werden verschiedene Typen von Gateways kombiniert, kann es zu nicht beabsichtigtem Verhalten kommen.

Task wird zweifach ausgeführt, da vorher ein Gateway Parallelität erzeugt

5.10 Participants

Viele Prozesse sollten eigentlich als Orchestrierung mehrerer Participants (Teilnehmer) modelliert werden. Doch durch Unwissen oder Bequemlichkeit werden Lanes benutzt. Dazu können die folgenden Checks helfen.

  • Finden Aufgaben in anderen Organisationen statt? Dann müssen diese Aufgaben in Participants ausgelagert werden. Generell sollten Dinge außerhalb des Einflusses des eigenen Systems nur modelliert werden, falls unbedingt notwendig.
  • Gibt es jemanden, der mehrere Teilnehmer/Rollen orchestriert? Falls nicht müssen Participants und Nachrichten verwendet werden.
  • Werden die Participants durch Nachrichten informiert oder gesteuert? Falls nicht sind unbeteiligte Participants zu löschen.
  • Ist das Innenleben eines Participants relevant für die Betrachtung? Falls nein muss er zugeklappt modelliert werden. Generell ist eine Black Box-Sicht für Participants zu bevorzugen.