Konverter: Vorwärtskanten laufen durch Elemente, wenn eine Querverbindung das Layout verschiebt #22

New Issue

2026-09-25T14:19:09Z

Daniel commented

2026-09-25 14:19:09 +00:00

Ziel

Auch wenn ein Modell Verbindungen zwischen parallelen Zweigen oder Sprünge in einen Zweig hinein enthält, läuft
keine Vorwärtskante durchs Innere eines Elements.

Betroffen

Bereich: Konverter md_to_bpmn.py
Dateien (falls bekannt): orthogonal_points(), ggf. compute_layers() / layout_vertical() / layout_lanes()
Ändert Markdown-Syntax oder Ablageformat der Prozessbibliothek? nein – .bpmn können sich ändern

Fachlicher Hintergrund

Gefunden bei #12 mit einem Belastungstest: jede mögliche zusätzliche Rückwärtsverbindung in zwei kleinen
Testmodellen, mit und ohne Lanes (126 Fälle). In 21 Fällen läuft eine Vorwärtskante durch ein Element, auf
main vor #12 genauso wie danach. Typisch sind zwei Lagen:

Eine Verbindung zwischen Geschwisterzweigen (z. B. „Mitte → Links“) oder ein Sprung von hinten in einen Zweig
(z. B. „Danach → Rechts“) macht die Zielaufgabe zu einem späteren Schritt. Sie rückt eine Ebene tiefer.
Die Kante vom verzweigenden Gateway zu dieser Aufgabe läuft dann gerade durch die Aufgabe, die dazwischen steht.
orthogonal_points() kennt die übrigen Elemente nicht.

Nachstellbar, ohne Lanes:

S1 Start: A
  -> S2
S2 Gateway XOR: W?
  a -> S3
  b -> S4
  c -> S5
S3 Task: Links
  -> S6
S4 Task: Mitte
  -> S6
S5 Task: Rechts
  -> S6
S6 Gateway XOR: Z
  -> S7
S7 Task: Danach
  zurück -> S5
  -> S8
S8 Ende: E

Hier läuft die Kante S2 → S5 (Flow_4) durch S3. Verfahren des Belastungstests, als Ausgangspunkt für einen
parametrisierten Test: In ein kleines Modell je eine zusätzliche Kante zurück -> <früherer Schritt> einfügen, für
alle Paare, jeweils ohne Lanes, mit einer Lane und mit zwei abwechselnden Lanes. Dann kreuzungen() aufrufen.
Fachlich sind solche Querverbindungen selten, sie kommen aber bei Nachforderungen und Korrekturschleifen vor.

Abnahmekriterien

Das Beispiel oben erzeugt keine Kante durch ein Element (Test mit kreuzungen() aus
tests/test_referenzmodelle.py)
Ein Test über die Varianten des Belastungstests: keine Kreuzung durch Vorwärtskanten
Test je neuem Verhalten vorhanden (Konverter, Skripte), python -m pytest -q grün
PICTURE-Import: nötig, falls sich .bpmn der Beispiele ändern

Nicht Teil dieses Issues

Rücksprungkanten (#12, erledigt); Nachrichtenflüsse (#13); ein allgemeines Layoutverfahren mit Hindernissuche,
falls sich die Fälle mit Regeln lösen lassen.

## Ziel Auch wenn ein Modell Verbindungen zwischen parallelen Zweigen oder Sprünge in einen Zweig hinein enthält, läuft keine Vorwärtskante durchs Innere eines Elements. ## Betroffen Bereich: Konverter `md_to_bpmn.py` Dateien (falls bekannt): `orthogonal_points()`, ggf. `compute_layers()` / `layout_vertical()` / `layout_lanes()` Ändert Markdown-Syntax oder Ablageformat der Prozessbibliothek? nein – `.bpmn` können sich ändern ## Fachlicher Hintergrund Gefunden bei #12 mit einem Belastungstest: jede mögliche zusätzliche Rückwärtsverbindung in zwei kleinen Testmodellen, mit und ohne Lanes (126 Fälle). In 21 Fällen läuft eine **Vorwärtskante** durch ein Element, auf `main` vor #12 genauso wie danach. Typisch sind zwei Lagen: - Eine Verbindung zwischen Geschwisterzweigen (z. B. „Mitte → Links“) oder ein Sprung von hinten in einen Zweig (z. B. „Danach → Rechts“) macht die Zielaufgabe zu einem späteren Schritt. Sie rückt eine Ebene tiefer. - Die Kante vom verzweigenden Gateway zu dieser Aufgabe läuft dann gerade durch die Aufgabe, die dazwischen steht. `orthogonal_points()` kennt die übrigen Elemente nicht. Nachstellbar, ohne Lanes: ``` S1 Start: A -> S2 S2 Gateway XOR: W? a -> S3 b -> S4 c -> S5 S3 Task: Links -> S6 S4 Task: Mitte -> S6 S5 Task: Rechts -> S6 S6 Gateway XOR: Z -> S7 S7 Task: Danach zurück -> S5 -> S8 S8 Ende: E ``` Hier läuft die Kante S2 → S5 (`Flow_4`) durch S3. Verfahren des Belastungstests, als Ausgangspunkt für einen parametrisierten Test: In ein kleines Modell je eine zusätzliche Kante `zurück -> <früherer Schritt>` einfügen, für alle Paare, jeweils ohne Lanes, mit einer Lane und mit zwei abwechselnden Lanes. Dann `kreuzungen()` aufrufen. Fachlich sind solche Querverbindungen selten, sie kommen aber bei Nachforderungen und Korrekturschleifen vor. ## Abnahmekriterien - [ ] Das Beispiel oben erzeugt keine Kante durch ein Element (Test mit `kreuzungen()` aus `tests/test_referenzmodelle.py`) - [ ] Ein Test über die Varianten des Belastungstests: keine Kreuzung durch Vorwärtskanten - [ ] Test je neuem Verhalten vorhanden (Konverter, Skripte), `python -m pytest -q` grün - [ ] PICTURE-Import: nötig, falls sich `.bpmn` der Beispiele ändern ## Nicht Teil dieses Issues Rücksprungkanten (#12, erledigt); Nachrichtenflüsse (#13); ein allgemeines Layoutverfahren mit Hindernissuche, falls sich die Fälle mit Regeln lösen lassen.

Daniel referenced this issue from a commit

2026-09-25 16:42:06 +00:00

Kanten an Aufgaben rechtwinklig ansetzen (#23)

Daniel referenced this issue

2026-09-25 16:42:42 +00:00

Kanten an Aufgaben rechtwinklig ansetzen (#23) #25

Daniel commented

2026-09-25 16:43:32 +00:00

Ergänzung aus #23: Seit dem Stub am Aufgaben-Ende (Kanten zwischen Aufgabe und Gateway) haben sich im
Belastungstest vier Fälle dieser Art verschoben. Die Kanten gehen jetzt zuerst senkrecht und dann waagrecht statt
umgekehrt und treffen dabei die verrutschte Aufgabe:

drei Zweige, S4 -> S3, eine Lane: neu Flow_7 → Task_S3
drei Zweige, S5 -> S3, eine Lane: neu Flow_6 → Task_S3
drei Zweige, S5 -> S4, ohne Lanes: neu Flow_5 → Task_S4
parallel, S5 -> S4, zwei Lanes: neu Flow_7 → Task_S4 (S5 → Gateway S6 läuft auf Höhe von S6 durch S4)

In zwei anderen Fällen (S4 -> S3 bzw. S5 -> S3, zwei Lanes) verschwindet dafür eine Kreuzung. Kern bleibt, dass
orthogonal_points() die übrigen Elemente nicht kennt. Welche der beiden gleichwertigen Reihenfolgen, erst senkrecht
oder erst waagrecht, frei ist, lässt sich nur mit Hinderniskenntnis entscheiden. Das gehört zu diesem Issue.

Ergänzung aus #23: Seit dem Stub am Aufgaben-Ende (Kanten zwischen Aufgabe und Gateway) haben sich im Belastungstest vier Fälle dieser Art verschoben. Die Kanten gehen jetzt zuerst senkrecht und dann waagrecht statt umgekehrt und treffen dabei die verrutschte Aufgabe: - drei Zweige, `S4 -> S3`, eine Lane: neu `Flow_7` → `Task_S3` - drei Zweige, `S5 -> S3`, eine Lane: neu `Flow_6` → `Task_S3` - drei Zweige, `S5 -> S4`, ohne Lanes: neu `Flow_5` → `Task_S4` - parallel, `S5 -> S4`, zwei Lanes: neu `Flow_7` → `Task_S4` (S5 → Gateway S6 läuft auf Höhe von S6 durch S4) In zwei anderen Fällen (`S4 -> S3` bzw. `S5 -> S3`, zwei Lanes) verschwindet dafür eine Kreuzung. Kern bleibt, dass `orthogonal_points()` die übrigen Elemente nicht kennt. Welche der beiden gleichwertigen Reihenfolgen, erst senkrecht oder erst waagrecht, frei ist, lässt sich nur mit Hinderniskenntnis entscheiden. Das gehört zu diesem Issue.

Daniel referenced this issue from a commit

2026-09-25 17:39:45 +00:00

Vorwärtskanten weichen Elementen über freie Linien aus (#22)

Daniel referenced a pull request that will close this issue

2026-09-25 17:40:32 +00:00

Vorwärtskanten weichen Elementen über freie Linien aus (#22) #26

Daniel closed this issue

2026-09-25 17:40:42 +00:00

Daniel referenced this issue from a commit

2026-09-25 17:40:42 +00:00

Merge pull request 'Vorwärtskanten weichen Elementen über freie Linien aus (#22)' (#26) from bugfix/22-vorwaertskanten-querverbindung into main

Sign in to join this conversation.