Fragment-Rahmen: Ist und Soll
Links steht jeweils, was der Server heute zeichnet, unverändert. Rechts dasselbe SVG, bei dem nur die Fragment-Rahmen (Rahmen, Kennung, Bedingung, else-Linie) nach einer vorgeschlagenen Regel verschoben sind. Pfeile, Lifelines und Labels sind identisch. Jede Regel lässt sich einzeln beschließen.
Verschachtelte Fragmente einrücken
Ein Fragment, das in einem anderen liegt, rückt je Ebene 8 px nach innen. Heute liegen
loop und alt links und rechts deckungsgleich. Man sieht nicht, dass die Schleife
im alt-Zweig liegt, und die Rahmenlinie wirkt doppelt so dick.
Die Schachtelungstiefe aus den Index-Bereichen in SequenceLayout ermitteln, der Renderer rückt um 8 px ein.
Reine Ganzzahl-Geometrie, keine Textmessung, ein Test (innerer Rahmen liegt strikt innen).
Die Struktur wird überhaupt erst lesbar. In UML ist das Standard.
Rahmen nur über die beteiligten Lifelines
Der Rahmen reicht von der äußersten links bis zur äußersten rechts beteiligten Lifeline (links 44 px, rechts 24 px), aber mindestens so breit, dass Kennung und Bedingung hineinpassen. Heute spannt jedes Fragment über alle Lifelines, auch wenn nur Web-App und API miteinander reden.
Beteiligte je Fragment aus den Nachrichten im Bereich, Mindestbreite, die else-Linie folgt dem Rahmen.
Die Mindestbreite hängt an der geschätzten Breite der Bedingung, und die Skins haben 8–10 px Schrift. Ein Fragment nur aus Self-Nachrichten wird sehr schmal. Schon beim Bau dieser Seite trat es auf: Mit 24 px links lag die Kennung ALT auf der ersten Lifeline, im Circuit Breaker sogar auf dem Aktivierungsbalken. Deshalb jetzt 44 px. Folge davon: Die Bedingung ([bis zu 3 Versuche]) kreuzt jetzt die erste Lifeline. Das löst erst die Text-Kontur aus MZP-184, R2 hängt also an MZP-184.
Man sieht sofort, wen der Zweig betrifft. Mermaid und PlantUML zeichnen aber auch über alle, der Zustand heute ist also nicht falsch.
Self-Labels im Rahmen halten
Der rechte Rand wächst, bis das Label einer Self-Nachricht im Fragment hineinpasst. Heute ragt „Template rendern“ aus dem opt-Rahmen, und man kann es für eine Nachricht außerhalb des Zweigs halten.
Dieselbe Label-Breitenrechnung wie für MZP-184 Punkt 2 (Self-Label abgeschnitten). Am besten zusammen.
Hängt an der geschätzten Zeichenbreite. In kontrast (10 px) wird der Rand zu knapp, falls die Schätzung den Skin nicht kennt.
Eindeutige Zugehörigkeit. Bei langen Labels werden die Rahmen aber sehr breit, siehe unten.
Alle drei zusammen
So sähe es aus, wenn alle drei Regeln gelten. Oben fällt auf: Das lange Self-Label „Datenbank-Lookup …“ zieht den alt-Rahmen weit nach rechts. Das ist der Preis von R3 bei langen Labels.
Zur Entscheidung
| Regel | Aufwand | Risiko neuer Runden | Empfehlung |
|---|---|---|---|
| R1 Verschachtelung einrücken | ~30 min | gering | machen |
| R2 Breite nur über Beteiligte | ~1–1,5 h | mittel | optional, Geschmacksfrage; nur nach MZP-184 |
| R3 Self-Labels umschließen | ~30 min | gering–mittel | zusammen mit MZP-184 (gleiche Breitenrechnung) |
Wie die Soll-Bilder entstanden sind: Die Seite lädt die echten SVGs des Servers
(Kopien von seq-test-circuit-breaker, seq-test-oauth, seq-test-events-hell) und verschiebt
im Soll-Bild nur die x-Koordinaten der Fragment-Elemente. Die Zielwerte hat ein Skript nach der jeweiligen Regel berechnet. Es ist eine Simulation, kein
neuer Renderer-Code. Die Label-Breite ist mit 5,28 px je Zeichen geschätzt (Plex Mono 8 px), dieselbe Annahme hätte die Umsetzung.