DanielandClaude Opus 5.5
012509b6d1
Übernommen ohne Historie aus AG_QGIS/Projektwissen (main @ decd2a0), Skill sn-bpmn vom Branch BPMN-Skill @ 6efcac4 (ADR 0001). - Skripte hallo.py, gitea.py, setup_workspace.py auf die Organisation AG_Prozesse umgestellt; das Workspace-Repo zählt über [workspace] repo als Ticket-Repo, auch ohne weitere [[repos]]. - pruefe_umlaute.py prüft jetzt die .py-Dateien des Workspace selbst. - Branchmodell main plus Arbeitsbranches (ADR 0002). - AGENTS.md, README, Leitfäden, Skills, Vorlagen, Fallstricke und Glossar auf die Prozessmodellierung zugeschnitten; QGIS- und Plugin-Spezifisches entfernt. - Tests: python -m pytest -q .agents/skills -> 32 bestanden. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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.
|