74 lines
4.4 KiB
Markdown
74 lines
4.4 KiB
Markdown
 
|
# BPMN-Modellierregeln
|
|||
|
|
|
|||
|
|
Fachliche Regeln, an denen sich ein Entwurf (`entwuerfe/<name>.md`) und die
|
|||
|
|
daraus erzeugte BPMN-Datei messen lassen müssen – zusätzlich zur reinen
|
|||
|
|
Markdown-Syntax aus `Anleitung.md`. Beim Erzeugen und beim Prüfen eines
|
|||
|
|
Entwurfs (Schritt 2 in `SKILL.md`) gegen diese Liste abgleichen und
|
|||
|
|
Verstöße im Annahmen-/Hinweis-Abschnitt benennen. Welche Elemente es
|
|||
|
|
überhaupt gibt und wofür sie stehen, steht in `Elementkatalog.md`.
|
|||
|
|
|
|||
|
|
1. **Verzweigungen laufen passend zusammen.** Verzweigte Pfade müssen in
|
|||
|
|
einem Verzweigungselement (Gateway) zusammenlaufen, das zur Art der
|
|||
|
|
Verzweigung passt, bevor der Pfad in den nächsten Arbeitsschritt nach
|
|||
|
|
der Verzweigung mündet. Pfade nicht einfach ohne zusammenführendes
|
|||
|
|
Gateway in denselben Folgeschritt münden lassen. Welcher Gateway-Typ
|
|||
|
|
zusammenführt, hängt vom Split ab – und die drei Typen unterscheiden
|
|||
|
|
sich fachlich, nicht nur formal:
|
|||
|
|
- **XOR-Split** (genau ein Pfad wird genommen) → **XOR-Merge**
|
|||
|
|
(Entweder-Oder-Zusammenführung): die ankommenden Pfade laufen
|
|||
|
|
unabhängig voneinander einfach weiter, es wird auf nichts gewartet.
|
|||
|
|
- **AND-Split** (alle Pfade parallel) → **AND-Merge** (Verschmelzung):
|
|||
|
|
wartet, bis **alle** eingehenden Pfade angekommen sind, bevor es
|
|||
|
|
weitergeht. Ein AND-Split ohne passenden AND-Merge am Ende der
|
|||
|
|
parallelen Pfade führt zu mehrfach durchlaufenen Folgeschritten.
|
|||
|
|
- **OR-Split** (ein oder mehrere Pfade) → **OR-Merge**
|
|||
|
|
(Oder-Verschmelzung): wartet auf alle **aktiven** eingehenden Pfade,
|
|||
|
|
nicht zwingend auf alle theoretisch möglichen.
|
|||
|
|
- **Ereignisbasierte Verzweigung** ist ein Sonderfall: Sie darf nicht
|
|||
|
|
spiegelbildlich als Zusammenführung genutzt werden, also nie mehr
|
|||
|
|
als eine eingehende Kante haben (`md_to_bpmn.py` lehnt das ab).
|
|||
|
|
|
|||
|
|
2. **Nachrichtenfluss nur zwischen Pools.** Ein Nachrichtenfluss verbindet
|
|||
|
|
ausschließlich Elemente unterschiedlicher Pools (z. B. den eigenen
|
|||
|
|
Prozess mit einem externen Beteiligten). Innerhalb desselben Pools
|
|||
|
|
werden Informationsübergaben über den normalen Sequenzfluss
|
|||
|
|
modelliert, nie über Nachrichtenfluss.
|
|||
|
|
|
|||
|
|
3. **Datenobjekte, Datenspeicher und Gruppen sind keine Ablaufelemente.**
|
|||
|
|
Sie hängen nicht am Sequenzfluss (kein `->` zu/von ihnen) und werden
|
|||
|
|
sparsam eingesetzt – nur wenn der Sachverhalt (z. B. ein zentrales
|
|||
|
|
Dokument oder eine geteilte Ablage) für das Verständnis des Prozesses
|
|||
|
|
wirklich wichtig ist, nicht für jede beiläufig erwähnte Unterlage.
|
|||
|
|
|
|||
|
|
4. **Jede Kante bekommt einen eigenen Anschlusspunkt.** Jeder Eingang und
|
|||
|
|
jeder Ausgang an einem Element muss einen eigenen Verbindungspunkt am
|
|||
|
|
Element nutzen, nicht denselben Punkt wie eine andere Kante. Laufen
|
|||
|
|
mehrere Kanten sichtbar in einem einzigen Punkt zusammen, sieht das
|
|||
|
|
Diagramm so aus, als wären mehrere fachlich getrennte Verzweigungen
|
|||
|
|
eine einzige Linie – das verschleiert genau die Verzweigung, die
|
|||
|
|
dargestellt werden soll. `md_to_bpmn.py` setzt das automatisch um, aber
|
|||
|
|
je nach Elementtyp unterschiedlich:
|
|||
|
|
- **Bei Task/Ereignis/Datenobjekt usw.** werden mehrere Punkte entlang
|
|||
|
|
der tatsächlichen Kontur verteilt (Rechteckkante bzw. Kreisbogen).
|
|||
|
|
- **Bei einem Gateway hat PICTURE nur vier feste Anschlusspunkte** – je
|
|||
|
|
einen bei 0°/90°/180°/270° (Ost/Süd/West/Nord), die Kante verläuft
|
|||
|
|
dort immer gerade. `md_to_bpmn.py` weist deshalb jeder Kante an einem
|
|||
|
|
Gateway einen dieser vier Eckpunkte zu, nicht einen Punkt auf der
|
|||
|
|
Rautenkante dazwischen. **Daraus folgt eine harte Obergrenze: ein
|
|||
|
|
Gateway kann höchstens vier Kanten insgesamt (eingehend plus
|
|||
|
|
ausgehend zusammengerechnet) eindeutig darstellen.** Ein XOR-Split
|
|||
|
|
mit einer eingehenden Kante hat also nur für maximal drei ausgehende
|
|||
|
|
Zweige Platz; bei vier oder mehr Zweigen muss mindestens eine Kante
|
|||
|
|
sich einen Punkt mit einer anderen teilen – das ist eine Grenze von
|
|||
|
|
PICTURE selbst, kein Darstellungsfehler von `md_to_bpmn.py`. Bei
|
|||
|
|
einer Verzweigung mit vielen Zweigen und einer eingehenden Kante
|
|||
|
|
lohnt sich daher, die Entscheidung in mehrere, weniger stark
|
|||
|
|
verzweigte Gateways aufzuteilen, wenn jeder Zweig einzeln sichtbar
|
|||
|
|
bleiben soll.
|
|||
|
|
|
|||
|
|
Wirkt ein Diagramm trotzdem so, als würden Verzweigungen an einem
|
|||
|
|
Punkt zusammenlaufen, zuerst in einem originalgetreuen BPMN-Viewer
|
|||
|
|
(z. B. `demo.bpmn.io`) prüfen, ob es an der erzeugten Datei liegt oder
|
|||
|
|
tatsächlich an der Vier-Punkte-Grenze eines Gateways mit mehr als vier
|
|||
|
|
Kanten.
|