Syntaxprüfung für BPMN-2.0-Prozessmodelle

Auf dieser Seite können Sie sich über die Syntaxprüfung für BPMN 2.0 informieren. Hier erfahren Sie, wozu und wie Sie diese Syntaxprüfung verwenden können. Außerdem wird die Funktionsweise der Syntaxprüfung ausführlich erläutert.

Inhaltsverzeichnis

Was ist das Ergebnis der Syntaxprüfung?

Die Syntaxprüfung - BPMN 2.0 gibt Ihnen einen Überblick über die Einhaltung der grundlegenden Regeln der BPMN 2.0-Spezifikation der Object Management Group (OMG). Außerdem unterstützt die Syntaxprüfung die Beachtung der empfohlenen Modellierungsregeln der PICTURE-GmbH.

Das Ergebnis hat jedoch keinen Anspruch auf Vollständigkeit, da die BPMN 2.0-Spezifikation sehr umfangreich ist. Die Syntaxprüfung - BPMN 2.0 dient lediglich als Werkzeug zur Unterstützung eines Modellierers.

Beim Verstoß gegen eine dieser Regeln wird eine entsprechende Fehler- bzw. Warnmeldung ausgeben. Weitere Details werden im Folgendem beschrieben.

Bedienung

Öffnen Sie den zu prüfenden Prozess mit BPMN-Detailmodell im BPMN-Editor. Klicken Sie anschließend auf den 1.) „Analyse“ Dropdown-Button und wählen Sie 2.) „Syntaxprüfung - BPMN 2.0“ (siehe Abbildung 1).

Abbildung 1: Klickpfad zum Starten der Syntaxprüfung.

Das Ergebnis der Syntaxprüfung wird im Editor links neben dem Steckbrief und dem Prozessmodell angezeigt. Falls keine Fehler gefunden wurden, erhalten Sie ein kurzes positives Feedback. Falls jedoch Fehler gefunden werden, wird eine Liste mit Verstößen (rot) und Warnungen (gelb) angezeigt (siehe Abbildung 2). Wenn sie den Mauszeiger über einen Fehler oder eine Warnung halten, wird ein ergänzender Tipp angezeigt.

 

Abbildung 2: Darstellung exemplarischer Fehler (rot) und Warnungen (gelb). Zusätzlich wird ein ergänzender Tipp als Tool-Tipp angezeigt.

 

Jeder Eintrag der Ergebnis-Liste besteht aus drei Teilen. Die erste Zeile des Eintrags gibt das Diagramm an, in dem sich der Fehler befindet. Die zweite Zeile bezeichnet den Typen oder die Bezeichnung des betroffenen Elements (blau). Durch einen Klick auf den blauen Link springen Sie automatisch zum betroffenen Element. Ab der dritten Zeile wird der Grund für den Fehler oder die Warnung gegeben.

 

Mit dem runden Pfeil können Sie die Ergebnisse aktualisieren, um zu überprüfen, ob die von Ihnen durchgeführten Änderungen erfolgreich waren.

Mit dem X-Symbol können Sie das Seitenpanel mit den Ergebnissen schließen.

 

Syntaxregeln für die BPMN 2.0

Im folgenden Abschnitt werden die einzelnen Syntaxverstöße dargestellt, welche für die BPMN 2.0 und alle darauf basierenden Modellierungssprachen (z.B. PICTURE-BPMN und FIM) gelten. Es wird jeweils ein falsches und ein richtiges Beispiel gezeigt. Außerdem wird der Verstoß erklärt.

Falsch

Richtig

Begründung

Typ

Falsch

Richtig

Begründung

Typ

 

 

Elemente (Nodes) benötigen stets eine Bezeichnung.

Um den Prozessfluss inhaltlich nachvollziehen zu können, müssen Elemente unbedingt eine Bezeichnung haben.

Ausnahmen: Alle schließende Gateways, das parallele Gateway und ereignisbasierte Gateway.

Fehler

 

 

Ein Sequenzfluss-Verbinder muss mit zwei Elementen verbunden sein.

Ein nicht verbundener Sequenzfluss, führt zu Fehlern bei der BPMN 2.0 Analyse. Klicken Sie auf den Sequenzfluss-Verbinder und ziehen Sie den unverbundenen Startpunkt oder Endpunkt auf ein geeignetes Element.

Fehler

 

Sequenzfluss-Verbinder, die aus einem XOR- bzw. OR-Gateway herausführen, benötigen eine Beschriftung.

Das XOR- bzw. OR-Gateway ist immer eine Fallunterscheidung, welche durch eine Frage am Gateway definiert wird. Diese muss durch die ausgehenden Sequenzfluss-Verbinder beantwortet werden.

Fehler

 

 

Ein Diagramm benötigt stets mindestens ein Start- und ein End-Ereignis.

Sobald eine Aufgabe auf der Diagrammfläche vorhanden ist, muss ebenfalls ein klar definierter Anfang und Ende existieren.

Fehler

 

 

Jeder aufgeklappte Pool braucht mindestens ein Start- und End-Ereignis.

Ein Pool ist eine für sich abgeschlossene Prozesseinheit und benötigt deshalb ebenfalls einen definierten Anfang und ein definiertes Ende.

Fehler

 

 

Alle Elemente (Ereignisse, Aufgaben / Bausteine, Teilprozesse, Gateways) müssen - ausgehend von einem Start-Ereignis und mündend in ein End-Ereignis - miteinander durch Sequenzfluss-Verbinder verbunden sein.

Ein Element, das diesem Kriterium nicht entspricht, kann entweder nicht erreicht werden und hat somit keinen Einfluss auf den Prozess oder es kann keinen Endzustand erreichen. In diesem Fall gerät der Prozess in einen sogenannten "Deadlock" und kann nicht durchgeführt werden.

Achtung: In Analysen, welche den modellierten Sequenzfluss innerhalb eines Prozesses auswerten, unterstützt die Prozessplattform die Verwendung von Zwischen-Ereignissen vom Typ “Link (sendend)“ und “Link (empfangend)” nur eingeschränkt.

Um Prozessmodelle, in denen die o.g. Zwischen-Ereignissen verwendet werden, dennoch weitestmöglich auf Grundlage dieser Regel prüfen zu können, nimmt die Prozessplattform während der Prüfung intern folgende Vereinfachungen vor:

  • Zwischen-Ereignisse vom Typ "Link (sendend)" werden wie End-Ereignisse behandelt.

  • Zwischen-Ereignisse vom Typ "Link (empfangend)" werden wie Start-Ereignisse behandelt

Fehler

 

 

Duplizierte Kanten, das heißt Kanten mit gleichem Start- und Ziel-Element sind nicht erlaubt.

Ein Element mit zwei ausgehenden Sequenzfluss-Verbindern würde beiden Sequenzfluss-Verbindern parallel folgen. Ein Element mit zwei eingehenden Sequenzfluss-Verbindern würde alle eingehenden Sequenzflüsse ausführen. Als Konsequenz werden dieses Element und alle folgenden Elemente doppelt ausgeführt. Falls dies explizit gewollt ist, sollte dies durch eine Wiederholung der Elemente modelliert werden.

Fehler

 

 

Ein Gateway mit genau einem eingehenden und genau einem ausgehenden Sequenzfluss ist überflüssig.

Ein Gateway hat immer die Funktion einen Sequenzfluss aufzuspalten oder zu vereinigen. Ein Gateway mit genau einem ein- und aus-gehendem Sequenzfluss-Verbinder erfüllt diese Bedingung nicht.

Fehler

 

 

Es dürfen keine Elemente einen geschlossenen Pool überlagern.

Ein geschlossener Pool repräsentiert eine Einheit, auf die der Prozess keinen Einfluss hat. Dies könnte zum Beispiel eine externe Organisation sein. Deshalb soll und kann der Prozessablauf der externen Organisation nicht modelliert werden.

Text-Annotationen oder Gruppen sind jedoch erlaubt, um ergänzende Informationen hinzuzufügen.

Fehler

 

 

Nach einem ereignisbasierten Gateway dürfen nur Ereignisse bzw. “nachrichten-empfangende” Aktivitäten folgen.

Für die korrekte Auswertung eines ereignisbasierten Gateways wird immer dem Sequenzfluss gefolgt, dessen Pfad zum Ereignis zeigt, welches zuerst erfüllt wird. Deshalb dürfen nur Ereignisse, oder “nachrichten-empfangende” Aktivitäten folgen. Dies sind der PICTURE-Baustein „Dokument/Information entgegennehmen“ oder der BPMN 2.0-Baustein „Aufgabe (empfangend)“.

Fehler

Das Startereignis eines aufgeklappten Teilprozesses muss eindeutig und untypisiert sein (oder der Teilprozess darf kein Startereignis besitzen).

Aufgeklappte Teilprozesse werden durch von außen eingehende Sequenzflüsse ausgelöst. Damit der Beginn des Ablaufes innerhalb eines aufgeklappten Teilprozesses eindeutig definiert ist, muss dieser ein eindeutiges (untypisiertes) Startereignis besitzen. Mehrere (und somit nicht eindeutige) Startereignisse sind nicht zugelassen.

Fehler

Das Startereignis eines aufgeklappten Teilprozesses muss eindeutig und untypisiert sein (oder der Teilprozess darf kein Startereignis besitzen).

Aufgeklappte Teilprozesse werden (ausschließlich) durch einen von außen eingehenden Sequenzfluss ausgelöst. Daher darf das Startereignis eines aufgeklappten Teilprozesses keinen spezifischen Typ haben (z.B. Nachrichten-Ereignis, Bedingungs-Ereignis).

Fehler

 

 

Ein Teilprozess ohne Startereignis führt alle Elemente ohne eingehenden Sequenzfluss parallel aus.

Grundsätzlich ist es erlaubt, einen Teilprozess ohne Start-Ereignis zu modellieren. In diesem Fall werden allerdings alle Elemente ohne eingehenden Sequenzfluss-Verbinder parallel ausgeführt. Da diese Modellierungsart anfällig für Missverständnisse ist, raten wir zu einer explizierten Modellierung.

Warnung

 

 

Sequenzflüsse sollten nicht implizit in einer Aktivität gegabelt werden, sondern stets über ein Gateway.

Um eine bessere Modellierung zu erhalten, sollte auf Sonderegeln wie das implizierte parallele Gateway verzichtet werden. Es empfiehlt sich eine parallele Aufspaltung ausschließlich durch ein paralleles Gateway zu modellieren.

Warnung

 

 

Mehrere eingehende Sequenzflüsse in eine Aktivität sollten zuerst in einem Gateway vereint werden.

Um eine bessere Modellierung zu erhalten, sollte auf Sonderegeln wie die implizierte Modellierung einer exklusiven datenbasierten Vereinigung verzichtet werden. Es empfiehlt sich die Vereinigung ausschließlich über das exklusive datenbasierte Gateway zu modellieren.

Warnung

 

 

Gateways sollten Sequenzflüsse entweder nur vereinen oder nur gabeln.

Um die Modellierungsqualität zu erhöhen, sollten Kurzformen wie das simultane Vereinen und Aufspalten eines Sequenzflusses vermieden werden. Es empfiehlt sich stattdessen zwei Gateways zu verwenden.

Warnung