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 Funktionweise der Syntaxprüfung eingegangen.
Inhaltsverzeichnis
Was ist das Ergebnis der Syntaxprüfung?
Durch die Verwendung der Syntaxprüfung - BPMN 2.0 erhalten Sie einen Überblick, ob die grundlegenden Regeln der durch die Object Management Group (OMG) spezifizierten BPMN 2.0 eingehalten wurden und ob die durch die PICTURE-GmbH empfohlenen Modellierungsregel beachtet wurden. Das Ergebnis hat jedoch nicht den Anspruch vollständig zu sein, da die BPMN 2.0-Spezifikation zu umfangreich ist und 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.
Syntaxregel für die BPMN 2.0
Im folgenden AIm 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, sollten Elemente unbedingt eine Bezeichnung haben. | 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 ein 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 |
  |   | Ein Teilprozess muss ein eindeutiges leeres Start-Ereignis besitzen, oder darf kein 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 Ereignis als ausschließlichen Prozessauslöser zu verwenden oder mehrere nicht differenzierbare Prozessauslöser zu 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. | Fehler oder Warnung |
 |  | 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 „Dead Lock“ erreicht und nicht durchgeführt werden kann. | Fehler |
 |  | Duplizierten 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 Wiederholdung 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 |
 |  | 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 zzu 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 Gateway 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 |
 |  | Die Bezeichnung eines Elements sollte von seiner Default-Bezeichnung abweichen. Ein Modell ist wesentlich aussagekräftiger wenn die standarttexte der Elemente an die individuelle Aufgabenstellung angepasst sind. | Warnung |