Komplexität orchestrieren: Sequenzielle vs. konkurrierende Untierzustände bei der Zustandsmaschinenmodellierung – Einführung

Einführung

Da moderne Softwaresysteme an Umfang und Funktionalität zunehmen, werden flache Zustandsdiagramme schnell unübersichtlich. Reale Anwendungen arbeiten selten in einer einfachen linearen Weise; vielmehr verwalten sie abhängige Arbeitsabläufe, Hintergrundprozesse und vom Benutzer ausgelöste Interaktionen, die eine präzise Orchestrierung erfordern. Um diese Komplexität zu bewältigen, führt die Zustandsmaschinenmodellierung einzusammengesetzte Zustände, die interne Verhaltensweisen innerhalb eines einzelnen übergeordneten Zustands kapseln. Die architektonische Entscheidung, wie diese internen Verhaltensweisen strukturiert werden, beruht auf zwei grundlegenden Paradigmen:Sequenzielle (Oder-)UnterzuständeundKonkurrierende (Und-)Unterzustände.

Die Wahl zwischen diesen Paradigmen ist nicht lediglich eine Frage der Diagrammgestaltung; sie beeinflusst direkt die Systemarchitektur, die Handhabung von Konkurrenz, die Fehlerbehebung und die Wartbarkeit. Diese Fallstudie untersucht die praktische Anwendung beider Ansätze innerhalb eines modernen E-Commerce-Bestelllebenszyklus und zeigt, wie sequenzielle und konkurrierende Unterzustände genutzt werden können, um widerstandsfähige, skalierbare und logisch konsistente Zustandsmaschinen zu entwickeln.

Grundlegende Konzepte

Bevor wir uns der Fallstudie widmen, ist es unerlässlich, den theoretischen Unterschied zwischen den beiden Unterzustandsarchitekturen zu klären.

Sequenzielle Unterzustände (Oder-Zustände)

Bei einer sequenziellen Konfiguration kann ein zusammengesetzter Zustand nureinen Unterzustand gleichzeitig. Übergänge verlaufen entlang einer vorbestimmten, linearen Bahn, bei der jeder Zustand abgeschlossen sein muss, bevor der nächste beginnt.

• Logische Bedingung: Zustand A ODER Zustand B.

• Am besten geeignet für: Schritt-für-Schritt-Abläufe, Assistenten, Validierungs-Pipelines und sich gegenseitig ausschließende Betriebsmodi.

Konkurrierende Unterzustände (Und-Zustände)

Bei einer konkurrierenden Konfiguration wird ein zusammengesetzter Zustand in mehrere unabhängige Regionen aufgeteilt. Wenn der übergeordnete Zustand aktiv wird,werden alle Regionen gleichzeitig aktiviert, wobei jede Region ihren eigenen unabhängigen Lebenszyklus und Zustandsübergänge beibehält.

• Logische Bedingung: Region 1 (Zustand A) UND Region 2 (Zustand X).

• Am besten geeignet für:Parallele Prozessausführung, Hintergrundüberwachung neben der Benutzeroberflächennutzung und koordinierte, entkoppelte Subsysteme.

Struktureller Vergleich

Fallstudie: Lebenszyklus eines E-Commerce-Auftrags

Um diese Konzepte in der Praxis zu veranschaulichen, werden wir zwei kritische Phasen der Auftragsverarbeitung eines E-Commerce-Plattform-Pipelines modellieren: Zahlungsabwicklung und Auftragsabwicklung. Jede Phase zeigt, warum eine bestimmte Untertatsarchitektur die optimale Wahl ist.

Phase 1: Sequenzielle Untertate bei der Zahlungsabwicklung

Die Zahlungsabwicklung ist inhärent linear und zustandsabhängig. Die Autorisierung muss der Betrugsprüfung vorausgehen, die wiederum der Einziehung der Mittel vorausgehen muss. Schritte auszulassen oder sie parallel auszuführen würde die finanzielle Compliance verletzen und die Integrität der Transaktion gefährden. Daher ist eine sequenzielle (Oder-) Konfiguration zwingend erforderlich.

@startuml
skinparam architecture {
    Hintergrundfarbe Weiß
    Pfeilfarbe #222222
    Randfarbe #222222
}

title Sequenzielle Untertate - Zahlungsabwicklung

state Zahlungsabwicklung {
    [*] --> Bereit
    Bereit --> Authentifizierung : Benutzer sendet Zahlung
    Authentifizierung --> Genehmigt : Kartenvalidierung erfolgreich
    Genehmigt --> Erfassung : Settlement auslösen
    Erfassung --> Abgeschlossen : Mittel gesichert
    
    Zustand Authentifizierung : entry/ Prüfung von Betrugsmetriken
    Zustand Erfassung : entry/ Übertragung von Mitteln aus Treuhand
}

Abgeschlossen --> [*]
@endum

Architektonische Erkenntnis: Das sequenzielle Modell erzwingt eine strenge Reihenfolge. Eingangs-/Ausgangsaktionen (z. B. Betrugsprüfungen, Treuhandübertragungen) werden vorhersehbar ausgelöst, was Debugging, Audits und Rollback-Strategien vereinfacht.

Phase 2: Konkurrierende Untertate bei der Auftragsabwicklung

Sobald die Zahlung gesichert ist, muss das System den Auftrag zur Versendung vorbereiten. Die Logistikvorbereitung und die Bestandsverwaltung arbeiten jedoch mit unterschiedlichen Datenspeichern, beteiligen unterschiedliche Teams/Services und hängen nicht voneinander ab, um weiterzumachen. Ihre sequenzielle Modellierung würde künstliche Engpässe erzeugen. Eine konkurrierende (Und-)Konfiguration ermöglicht es, beide Workflows parallel auszuführen, wodurch die Gesamtverarbeitungszeit erheblich sinkt.

@startuml
title Konkurrierende Untertate - Auftragsabwicklung

state Auftragsabwicklung {
    
    ' Logistikregion
    [*] --> PaketVorbereitung
    note on link: **Logistikregion**
    PaketVorbereitung --> VersandetikettErstellen : Artikel verpackt
    VersandetikettErstellen --> PaketBereit : Etikett gedruckt
    
    --
    
    ' Bestandsregion
    [*] --> BestandZuweisen
    note on link: **Bestandsregion**
    BestandZuweisen --> ERPAktualisieren : Bestand überprüft
    ERPAktualisieren --> BestandAbgezogen : ERP-Synchronisation abgeschlossen
}

Auftragsabwicklung --> Versand : Beide Regionen abgeschlossen (Verbindung)
@endum

Architektonische Erkenntnis: Das konkurrierende Modell spiegelt die Parallelität der realen Welt wider. Jede Region arbeitet unabhängig, sodass der Logistikservice Etiketten drucken kann, während der Bestandsservice mit dem ERP synchronisiert. Der übergeordnete Zustand wechselt erst zu Versand sobald beide Regionen natürlicherweise abgeschlossen sind, fungiert dies als implizierter Synchronisationsbarriere.

Architektonische Überlegungen und Best Practices

Die Auswahl zwischen sequenziellen und konkurrierenden Untertaten geht über das Zeichnen von Diagrammen hinaus; sie bestimmt das Laufzeitverhalten und die Infrastrukturanforderungen.

Wann sequenzielle Gestaltung priorisiert werden sollte

• Zustandsabhängige Regeln: Wenn Untertate B auf Daten, Tokens oder Nebenwirkungen angewiesen ist, die ausschließlich von Untertate A erzeugt werden, garantiert die sequenzielle Modellierung eine deterministische Ausführung.

• Regulierte Abläufe: Compliance-getriebene Prozesse (z. B. KYC-Überprüfung, Zahlungsgateways, mehrfache Authentifizierung) erfordern nachvollziehbare, schrittweise Fortschritte.

• Benutzergeführte Schnittstellen: Mehrschrittige Assistenten oder Konfigurationsabläufe, bei denen Benutzer keine Validierungsprüfungen umgehen können.

Wann konkurrierende Gestaltung priorisiert werden sollte

• Entkoppelte Subsysteme: Ideal für Architekturen, bei denen unabhängige Dienste unterschiedliche Domänen bearbeiten (z. B. Hardware-Sensorabfragen, die parallel zur Benutzeroberflächenrenderung laufen).

• Leistungs-Optimierung: Konkurrierende Untertate identifizieren explizit Möglichkeiten für asynchrone Ausführung, Worker-Queues oder die Parallelisierung von Mikrodiensten.

• Kontinuierliche Überwachung:Hintergrundprozesse, die unbegrenzt laufen (z. B. Gesundheitsüberprüfungen, Protokollierung, Telemetrie), neben der primären Geschäftslogik.

Umgang mit Synchronisationsfallen (Verzweigungen und Zusammenführungen)

Konkurrierende Untertate bringen spezifische Lebenszyklus-Herausforderungen mit sich, die Architekten vorhersehen müssen:

1. Implizite Verzweigung beim Eintritt:Beim Betreten des übergeordneten Zustands wird der Ausführungsfluss automatisch über alle Regionen aufgeteilt. Die Initialisierungslogik muss sorgfältig eingeschränkt werden, um widersprüchliche Zustandskonfigurationen zu vermeiden.

2. Zusammenführung beim Verlassen:Ein ordnungsgemäßes Verlassen erfordert in der Regel, dass alle Regionen einen Endzustand erreichen. Wenn Regionen zu unterschiedlichen Zeiten abschließen, muss das System den Abschlussstatus verfolgen, ohne sich unbegrenzt zu blockieren.

3. Unterbrechungsbehandlung:Äußere Übergänge, die ein Verlassen eines konkurrierenden Zustands erzwingen, werdenplötzlich alle parallelen Regionen beenden, unabhängig von ihrem Fortschritt. Architekten müssen kompensierende Transaktionen, Bereinigungs-Hooks oder idempotente Operationen implementieren, um Datenkorruption bei vorzeitigen Beendigungen zu verhindern.

Fazit

Die Zustandsmaschinenmodellierung bietet eine leistungsstarke Abstraktion zur Verwaltung der Systemkomplexität, ihre Wirksamkeit hängt jedoch von der korrekten Strukturierung zusammengesetzter Zustände ab. Sequenzielle Untertate zeichnen sich durch die Durchsetzung deterministischer, schrittweiser Fortschritte aus und sind für compliance-intensive, zustandsabhängige Workflows unverzichtbar. Konkurrierende Untertate hingegen ermöglichen echte Parallelität und erlauben unabhängigen Subsystemen, gleichzeitig ohne künstliche Engpässe zu arbeiten.

Der E-Commerce-Fallstudie zeigt, dass keiner der Ansätze universell überlegen ist; vielmehr sind sie ergänzende Werkzeuge im Architekten-Toolkit. Durch die sorgfältige Zuordnung von Geschäftsanforderungen zur geeigneten Untertaten-Architektur können Teams Systeme entwickeln, die nicht nur funktional korrekt sind, sondern auch leistungsstark, wartbar und fehlerresistent. Da moderne Anwendungen weiterhin asynchrone, ereignisgesteuerte und verteilte Architekturen übernehmen, wird das Beherrschen des Unterschieds zwischen Oder-Zuständen und Und-Zuständen weiterhin eine grundlegende Fähigkeit für die Gestaltung robuster, skalierbarer Software-Systeme bleiben.