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 auf dieser Seite ausführlich auf die Funktionsweise der Syntaxprüfung eingegangen.
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).
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.
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 |
|---|---|---|---|
 |  | 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. Falls Sie ihren gesamten Prozess in einem Pool modellieren, reicht es aus, wenn die Start- und End-Ereignisse ebenfalls im Pool modelliert wurden. | 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 was diesem Kriterium nicht entspricht kann entweder nicht erreicht werden und hat somit keinen Einfluss auf den Prozess, oder kann keinen Endzustand erreichen, wodurch der Prozess einen sogenannten „Deadlock“ erreicht und nicht durchgeführt werden kann. | 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 wird das Element doppelt ausgeführt. Falls dies explizit gewollt ist, sollte dies durch eine Wiederholung des Bausteins 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 |
  |   | Ein Teilprozess muss ein eindeutiges leeres Start-Ereignis besitzen. Damit ein eindeutig definierter Prozessablauf gewährleistet ist, muss der Start eines Teilprozesses klar definiert und vorhanden sein. Deshalb ist es nicht möglich ein Start-Ereignis mit einem Ereignistypen als ausschließlichen Prozessauslöser zu verwenden oder mehrere nicht differenzierbare Prozessauslöser zu besitzen. | Fehler |
TODO | TODO | Ein Teilprozess darf kein Start-Ereignis besitzen. Formal ist es möglich kein Start-Ereignis anzugeben. In diesem Fall werden alle Elemente ohne eingehenden Sequenzfluss-Verbinder als Start-Ereignis verwendet. Diese werden anschließend parallel durchgefü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 |