| Info |
|---|
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 Funktionsweise der Syntaxprüfung eingegangenausführlich erläutert. |
Inhaltsverzeichnis
| Inhalt | ||||||
|---|---|---|---|---|---|---|
|
Was ist das Ergebnis der Syntaxprüfung?
Durch die Verwendung der Die Syntaxprüfung - BPMN 2.0 erhalten Sie gibt Ihnen einen Überblick , ob über die Einhaltung der grundlegenden Regeln der durch die BPMN 2.0-Spezifikation der Object Management Group (OMG) spezifizierten BPMN 2.0 eingehalten wurden und ob die durch die . Außerdem unterstützt die Syntaxprüfung die Beachtung der empfohlenen Modellierungsregeln der PICTURE-GmbH empfohlenen Modellierungsregel beachtet wurden. .
| Hinweis |
|---|
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 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 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 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 |   |   | 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 , das diesem Kriterium nicht entspricht, kann entweder nicht erreicht werden und hat somit keinen Einfluss auf den Prozess , oder es kann keinen Endzustand erreichen, wodurch . In diesem Fall gerät der Prozess in einen sogenannten „Dead Lock“ erreicht und nicht durchgeführt werden kann."Deadlock" und kann nicht durchgeführt werden.
| Fehler | ||||
 |  | Duplizierten 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 werden dieses Element und alle folgenden Elemente doppelt ausgeführt. Falls dies explizit gewollt ist, sollte dies durch eine Wiederholdung des Bausteins 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 zzu 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 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 |