Sequenzdiagramme: Was sie sind und wie man sie erstellt (Leitfaden 2026)

Wenn etwas in einem verteilten System bricht, lautet die erste Frage meist „Was hat mit was kommuniziert und in welcher Reihenfolge?" Genau das beantworten Sequenzdiagramme. Sie zeigen, wie Objekte, Services oder Benutzer im Laufe der Zeit interagieren — und machen unsichtbare Kommunikationsmuster sichtbar.

Sequenzdiagramme sind einer der praktischsten UML-Diagrammtypen für Software-Teams. Sie überbrücken die Lücke zwischen übergeordneter Architektur und tatsächlichem Code und sind daher unschätzbar wertvoll für API-Design, das Debuggen von Microservice-Aufrufen, die Dokumentation von Authentifizierungsabläufen und das Onboarding von Ingenieuren in unbekannte Systeme.

Was ist ein Sequenzdiagramm?

Ein Sequenzdiagramm ist eine Art Interaktionsdiagramm, das zeigt, wie Teilnehmer (Objekte, Services, Benutzer oder Systeme) miteinander in einem bestimmten Szenario kommunizieren, geordnet nach Zeit. Die vertikale Achse repräsentiert die nach unten fließende Zeit. Die horizontale Achse listet die Teilnehmer auf.

Im Gegensatz zu Flussdiagrammen, die sich auf die Logik eines einzelnen Prozesses konzentrieren, konzentrieren sich Sequenzdiagramme auf die zwischen mehreren Teilnehmern ausgetauschten Nachrichten und die Reihenfolge, in der diese Austausche stattfinden.

Grundstruktur:

Client          Auth-Service       Datenbank
  |                  |                 |
  |──── login() ────>|                 |
  |                  |── findUser() ──>|
  |                  |<── userData ────|
  |                  |── verifyPwd()   |
  |<── JWT-Token ────|                 |
  |                  |                 |

Jede vertikale Linie ist eine Lebenslinie. Jeder horizontale Pfeil ist eine Nachricht. Zeit fließt von oben nach unten.

UML-Notation für Sequenzdiagramme

Lebenslinien

Eine Lebenslinie repräsentiert einen Teilnehmer in der Interaktion. Sie besteht aus einem Kasten oben (der den Namen des Teilnehmers zeigt) und einer gestrichelten vertikalen Linie, die nach unten verläuft.

┌──────────┐   ┌──────────────┐   ┌──────────┐
│  Client  │   │  API-Server  │   │ Datenbank│
└────┬─────┘   └──────┬───────┘   └────┬─────┘
     │                │                │
     │  (gestrichelte Linie setzt sich nach unten fort)

Namenskonventionen:

Systeme/Services: CamelCase oder PascalCase (PaymentService, AuthAPI)
Akteure/Benutzer: einfache Namen (User, Admin, Customer)
Instanzen: objektName:Klassenname-Notation (bestellung:Bestellung)

Nachrichten

Nachrichten sind horizontale Pfeile zwischen Lebenslinien. Vier Typen:

Nachrichtentyp	Pfeilstil	Bedeutung
Synchroner Aufruf	`────────>`	Aufrufer wartet auf Antwort
Rückgabenachricht	`- - - - ->`	Antwort auf einen synchronen Aufruf
Asynchrone Nachricht	`────────>`	Aufrufer wartet nicht (oft mit offenem Kopf)
Selbstaufruf	Pfeil kehrt zurück	Objekt ruft seine eigene Methode auf

Aktivierungsbalken

Ein Aktivierungsbalken (oder Ausführungsvorfall) ist ein schmales Rechteck auf einer Lebenslinie, das zeigt, wann dieser Teilnehmer aktiv ist — eine Anfrage verarbeitet oder Logik ausführt.

     │              │
     │──── Aufruf ──>│
     │              ██  <- Aktivierungsbalken (Teilnehmer verarbeitet)
     │<── Rückgabe ──│
     │              │

Kombinierte Fragmente

Kombinierte Fragmente ermöglichen es Ihnen, bedingte und wiederholte Logik innerhalb eines Sequenzdiagramms darzustellen. Sie erscheinen als rechteckige Kästen mit einer Beschriftung in der oberen linken Ecke.

Fragment	Beschriftung	Zweck
Schleife	`loop`	Sequenz wiederholen (Bedingung oder Anzahl angeben)
Alt	`alt`	Alternative Pfade — wie ein if/else-Block
Opt	`opt`	Optionale Sequenz — wird nur ausgeführt, wenn Bedingung gilt
Par	`par`	Parallele Ausführung — Sequenzen laufen gleichzeitig
Ref	`ref`	Verweis auf ein anderes Sequenzdiagramm

Alt-Fragment-Beispiel:

┌─ alt ─────────────────────────────────────────────────┐
│ [Anmeldedaten gültig]                                  │
│   AuthService ──── Token ausstellen ───> Client        │
├────────────────────────────────────────────────────────┤
│ [Anmeldedaten ungültig]                                │
│   AuthService ──── 401-Fehler ─────────> Client        │
└────────────────────────────────────────────────────────┘

Loop-Fragment-Beispiel:

┌─ loop [für jedes Element im Warenkorb] ───────────────┐
│   BestellService ── Lagerbestand prüfen ──> Inventar   │
│   Inventar ─── verfügbar? ──> BestellService           │
└────────────────────────────────────────────────────────┘

Sequenzdiagramm vs. Flussdiagramm

Beide Diagramme modellieren Prozesse, aber sie beantworten unterschiedliche Fragen.

Aspekt	Sequenzdiagramm	Flussdiagramm
Hauptfokus	Kommunikation zwischen Teilnehmern	Logikfluss innerhalb eines einzelnen Prozesses
Achse	Zeit (vertikal) + Teilnehmer (horizontal)	Schritte verbunden durch Richtungspfeile
Zeigt	Nachrichten, Reihenfolge, Timing	Entscheidungen, Verzweigungen, Schleifen
Mehrere Akteure	Nativ — jeder bekommt eine Lebenslinie	Möglich, aber ohne Swimlanes unhandlich
Am besten für	APIs, Protokolle, verteilte Systeme	Algorithmen, Geschäftsprozesse
Paralleles Verhalten	Über `par`-Fragment unterstützt	Schwieriger darzustellen
Typische Nutzer	Software-Ingenieure, Architekten	Business-Analysten, Produktteams

Verwenden Sie ein Sequenzdiagramm, wenn die Schlüsselfrage lautet „Was sagt System A zu System B und wann?" Verwenden Sie ein Flussdiagramm, wenn die Frage lautet „Welche Entscheidung trifft dieser Prozess als nächstes?"

Wann Sequenzdiagramme verwenden

API-Design und -Dokumentation

Bevor eine einzige Codezeile geschrieben wird, ermöglichen Sequenzdiagramme die Validierung von API-Verträgen. Zeichnen Sie die Abfolge von Aufrufen für ein Feature und überprüfen Sie es mit dem Team. Sie werden fehlende Endpunkte, falsche Datenabhängigkeiten und mehrdeutige Antwortformate erkennen, bevor sie zu Fehlern in der Produktion werden.

Microservice-Kommunikation

Microservice-Architekturen sind schwer nachzuvollziehen, weil der Ablauf einer einzelnen Benutzeraktion oft fünf oder mehr Services umfasst. Ein Sequenzdiagramm macht dies sichtbar:

Benutzer    Gateway    BestellSvc    InventarSvc    ZahlungSvc    NotifSvc
  |            |            |              |              |            |
  |── POST /bestellung ────>|              |              |            |
  |            |            |── prüfen() ──>|              |            |
  |            |            |<── ok ────────|              |            |
  |            |            |── belasten() ──────────────────>|          |
  |            |            |<── Quittung ──────────────────|            |
  |            |            |── senden() ──────────────────────────────>|
  |<── 201 Erstellt ─────────|              |              |            |

Authentifizierungsabläufe

Auth-Abläufe beinhalten mehrere Parteien (Benutzer, Browser, Identitätsanbieter, Ressourcenserver) und strenge Anforderungen an die Reihenfolge. Sequenzdiagramme sind der Standardweg zur Dokumentation von OAuth-Abläufen, SAML-Assertions und JWT-Validierungsketten.

Debuggen von Produktionsvorfällen

Wenn ein Vorfall auftritt, erfordert die Rekonstruktion des Geschehenen das Verfolgen von Aufrufen über Services hinweg. Ein aus Logs und Traces erstelltes Sequenzdiagramm hilft dem Team, die Fehlersequenz zu verstehen und die Ursache schneller zu identifizieren als beim Lesen von Rohlogs.

Onboarding und Wissenstransfer

Neue Ingenieure, die einem Team beitreten, können ein Sequenzdiagramm lesen und einen komplexen Ablauf in Minuten verstehen. Dies ist effizienter als das Lesen von Code oder Prosadokumentation für interaktionsreiche Systeme.

Schritt-für-Schritt-Erstellungsleitfaden

Schritt 1: Szenario definieren

Wählen Sie ein spezifisches Szenario, nicht das gesamte System. Guter Umfang:

„Benutzer meldet sich mit Google OAuth an"
„Kunde gibt Bestellung mit abgelehnter Karte auf"
„Service A ruft Service B auf, der einen Timeout hat"

Vermeiden Sie: „das Authentifizierungssystem" (zu breit). Ein Szenario pro Diagramm.

Schritt 2: Teilnehmer identifizieren

Listen Sie jeden Akteur oder jedes System auf, das an diesem Szenario beteiligt ist. Häufige Teilnehmer:

Externe Akteure: Benutzer, Browser, Mobile App
Services: API-Gateway, Auth-Service, Bestellservice
Datenspeicher: Datenbank, Cache, Message Queue
Drittanbieter: Stripe, Twilio, SendGrid

Ordnen Sie sie von links nach rechts in der Reihenfolge, in der sie zuerst erscheinen, mit dem Initiator ganz links.

Schritt 3: Nachrichten auflisten

Schreiben Sie für jeden Schritt im Szenario auf:

Wer die Nachricht sendet
Wer sie empfängt
Was die Nachricht ist (Methodenname, Ereignisname oder Beschreibung)
Ob sie synchron oder asynchron ist

Schritt 4: Sequenz zeichnen

Platzieren Sie Teilnehmer als Lebenslinien oben. Zeichnen Sie Nachrichten als horizontale Pfeile in chronologischer Reihenfolge (von oben nach unten). Fügen Sie Aktivierungsbalken hinzu, um die Verarbeitungszeit anzuzeigen. Gruppieren Sie bedingte oder wiederholte Logik in kombinierten Fragmenten.

┌──────────┐         ┌──────────────┐         ┌──────────┐
│ Browser  │         │  Auth-Server │         │  UserDB  │
└────┬─────┘         └──────┬───────┘         └────┬─────┘
     │                      │                      │
     │──── POST /login ─────>│                      │
     │                      ██                      │
     │                      │── SELECT user ───────>│
     │                      │<── Benutzerdatensatz ──│
     │                      ██                      │
     │<── 200 + JWT ─────────│                      │
     │                      │                      │

Schritt 5: Fragmente und Notizen hinzufügen

Fügen Sie alt-, loop- oder opt-Fragmente hinzu, wo die Sequenz bedingte oder wiederholte Logik hat. Fügen Sie Notizen (in UML als gefaltete Rechtecke dargestellt) für wichtige Einschränkungen oder Erklärungen hinzu, die nicht sauber in Nachrichtenbeschriftungen passen.

Schritt 6: Mit Stakeholdern validieren

Gehen Sie das Diagramm mit den Ingenieuren oder Architekten durch, die jeden Teilnehmer verantworten. Überprüfen:

Ist die Nachrichtenreihenfolge korrekt?
Sind Rückgabenachrichten dort enthalten, wo sie benötigt werden?
Sind Fehlerpfade dargestellt?
Fehlt etwas?

Häufige Muster

Request-Response

Das grundlegendste Muster. Ein Aufrufer sendet eine synchrone Nachricht und wartet auf eine Rückgabe.

Client          Server
  │                │
  │──── Anfrage ──>│
  │                ██
  │<─── Antwort ───│
  │                │

Asynchrones Messaging mit Queue

Verwendet in ereignisgesteuerten Architekturen. Der Produzent wartet nicht darauf, dass der Konsument die Nachricht verarbeitet.

Produzent      Message Queue     Konsument
    │                │               │
    │── publish() ──>│               │
    │<── ack ────────│               │
    │                │── deliver() ──>│
    │                │               ██
    │                │<── fertig ─────│

Fehlerbehandlungsmuster

Modellieren Sie immer den Fehlerpfad neben dem Happy Path.

┌─ alt ────────────────────────────────────────────────────┐
│ [Erfolg]                                                  │
│   Service ──── 200 OK ─────────────────────────> Client  │
├──────────────────────────────────────────────────────────┤
│ [Nicht gefunden]                                          │
│   Service ──── 404 Not Found ────────────────── > Client │
├──────────────────────────────────────────────────────────┤
│ [Serverfehler]                                            │
│   Service ──── 500 Internal Error ─────────────> Client  │
└──────────────────────────────────────────────────────────┘

Timeout und Wiederholung

┌─ loop [Wiederholungsanzahl < 3] ──────────────────────────┐
│   Client ──── Anfrage ──────────────────────> Service     │
│   ┌─ opt [keine Antwort innerhalb von 5s] ───────────────┐│
│   │   Client ──── Timeout erkannt                        ││
│   └──────────────────────────────────────────────────────┘│
└───────────────────────────────────────────────────────────┘

Best Practices

Ein Szenario pro Diagramm. Ein Sequenzdiagramm, das alle möglichen Pfade abzudecken versucht, wird unleserlich. Zeichnen Sie separate Diagramme für den Happy Path, Fehlerpfade und Randfälle.

Teilnehmer auf 5–7 begrenzen. Mehr als sieben Lebenslinien machen horizontalen Platz zu einem Problem. Wenn Sie mehr Teilnehmer haben, gruppieren Sie verwandte Services in einen einzigen Teilnehmer und erstellen Sie ein separates Diagramm für die Internals dieser Gruppe.

Rückgabenachrichten für synchrone Aufrufe immer einbeziehen. Fehlende Rückgabepfeile implizieren, dass der Aufrufer nie eine Antwort erhält. Seien Sie explizit.

Nachrichten präzise beschriften. „getMessage()" ist besser als „Daten holen". Geben Sie den Methodennamen, HTTP-Verb und -Pfad oder Ereignisnamen an. Vermeiden Sie vage Beschriftungen wie „Anfrage" oder „Antwort".

Den initiierenden Akteur zeigen. Beginnen Sie beim Benutzer oder externem System, das die Sequenz auslöst, nicht in der Mitte des Ablaufs.

Notizen sparsam verwenden. Notizen sind nützlich für Einschränkungen („muss in < 200ms abgeschlossen sein"), überfüllen das Diagramm aber bei übermäßiger Verwendung.

Fehlerpfade zeichnen. Der Happy Path ist offensichtlich. Das Diagramm wird wertvoll, wenn es auch zeigt, was passiert, wenn Dinge schiefgehen.

Häufige Fehler

Das gesamte System in einem Diagramm modellieren. Dies erzeugt ein Diagramm, das zu komplex zum Lesen oder Warten ist. Den Umfang jedes Diagramms auf ein spezifisches Interaktionsszenario beschränken.

Rückgabenachrichten überspringen. Nur den ausgehenden Aufruf ohne die Rückgabe zu zeigen, ergibt ein unvollständiges Bild. Rückgabenachrichten für synchrone Aufrufe einbeziehen.

Sequenzdiagramme mit Flussdiagrammen verwechseln. Das Hinzufügen von Entscheidungsrauten und Verzweigungspfeilen verwandelt das Diagramm in ein Flussdiagramm-Hybrid. Stattdessen alt- und opt-Fragmente für Bedingungen verwenden.

Falsche Zeitreihenfolge. Nachrichten, die höher im Diagramm platziert sind, werden als früher angenommen. Das Platzieren einer Antwort über dem entsprechenden Aufruf ist ein häufiger Fehler.

Zu viele Details in Nachrichtenbeschriftungen. Vollständige JSON-Payloads in Nachrichtenbeschriftungen machen Diagramme unleserlich. Den Nachrichtennamen für die Beschriftung verwenden; eine Notiz hinzufügen, wenn die Payload-Details wichtig sind.

Asynchrone Interaktionen ignorieren. Jede Nachricht als synchron zu behandeln, verbirgt wichtige Architekturmerkmale. Asynchrone Nachrichten explizit markieren.

Sequenzdiagramme mit Flowova erstellen

API-Abläufe und Service-Interaktionen manuell zu dokumentieren ist langsam. Das Sequenzdiagramm-Erstellungstool von Flowova ermöglicht es Ihnen, Ihren Ablauf in Klartext zu beschreiben und ein strukturiertes Diagramm zu generieren, das Sie visuell bearbeiten können. Fügen Sie eine Beschreibung wie „Benutzer reicht Anmeldeformular ein, Auth-Service validiert Anmeldedaten gegen die Datenbank, gibt bei Erfolg ein JWT zurück" ein und erhalten Sie ein funktionierendes Diagramm, das Sie mit Ihrem Team verfeinern können.

Fazit

Sequenzdiagramme sind das richtige Tool, wenn Sie die Reihenfolge und Richtung von Nachrichten zwischen mehreren Teilnehmern verstehen oder kommunizieren müssen. Sie überzeugen bei der API-Dokumentation, dem Design von Microservice-Interaktionen, der Auth-Ablauf-Spezifikation und Incident-Post-Mortems. Der Schlüssel ist, den Umfang jedes Diagramms auf ein Szenario zu begrenzen, sowohl Happy als auch Fehlerpfade einzubeziehen und das Ergebnis mit den Personen zu validieren, die jeden Teilnehmer verantworten. Beginnen Sie mit dem einfachen Request-Response-Muster und fügen Sie Komplexität nur dann hinzu, wenn das Szenario es erfordert.