Sequenzdiagramm

Das Aktivitätsdiagramm aus L3 zeigt einen Prozess-Ablauf: was passiert in welcher Reihenfolge, wer macht was. Das Sequenzdiagramm bewegt sich eine Schicht tiefer: es zeigt die Kommunikation zwischen Objekten. Wer ruft wen auf? Welche Nachrichten werden ausgetauscht? In welcher Reihenfolge?

Sequenzdiagramme sind der UML-Standard, um technische Interaktionen zu modellieren – zwischen Klassen, Komponenten, Systemen oder externen Services. In modernen Architekturen mit vielen verteilten Bausteinen (siehe spätere Lektionen zu Schichtenarchitektur und Microservices) sind sie unverzichtbar. In IHK-Klausuren tauchen sie regelmäßig auf.

1) Die Grundidee: Zeit fließt nach unten

Stell dir vor, du müsstest in einem Drehbuch festhalten, welche Schauspieler in welcher Reihenfolge welche Worte miteinander wechseln. Ein Sequenzdiagramm ist genau so: die Beteiligten stehen oben nebeneinander (jeder auf seiner Linie), die Zeit fließt von oben nach unten, und Pfeile zwischen den Linien zeigen, wer mit wem spricht – welche Nachrichten gesendet werden.

Das ist ein fundamental anderes Bild als beim Aktivitätsdiagramm: dort steht was passiert im Vordergrund, hier zwischen wem. Beide ergänzen sich – ein Use-Case kann in einem Aktivitätsdiagramm den Ablauf und in einem Sequenzdiagramm die Kommunikation zwischen technischen Komponenten zeigen.

2) Die fünf Grundelemente

Bevor wir komplette Diagramme bauen: hier die wichtigsten Elemente eines Sequenzdiagramms. Wer diese fünf kennt, kann jedes Standard-Sequenzdiagramm lesen:

Die Bausteine

Lebenslinie

Rechteck oben mit Objekt- oder Klassen-Name, darunter gestrichelte vertikale Linie. Repräsentiert einen Teilnehmer über die Zeit.

Aktivierungsbalken

Dünnes Rechteck auf der Lebenslinie. Zeigt, dass das Objekt gerade aktiv arbeitet / einen Aufruf bearbeitet.

Synchrone Nachricht

Durchgezogener Pfeil mit gefüllter Spitze. Aufrufer wartet auf Antwort. Klassischer Methodenaufruf.

Asynchrone Nachricht

Pfeil mit offener Spitze. Aufrufer wartet nicht. Z.B. Events, Message Queues.

Rückgabe

Gestrichelter Pfeil. Ergebnis eines synchronen Aufrufs – „die Antwort kommt zurück".

Damit sind die zentralen Elemente abgedeckt. Hinzu kommen noch Fragmente für Schleifen und Bedingungen (mehr dazu in Abschnitt 7) und Spezialnotationen für Objekt-Erzeugung und -Zerstörung. In den meisten IHK-Aufgaben reichen aber diese fünf plus die Fragmente.

3) Ein vollständiges Beispiel: Login-Vorgang

Schauen wir uns ein komplettes Sequenzdiagramm an. Das Szenario: ein Nutzer loggt sich in eine Web-Anwendung ein. Beteiligt sind vier Teilnehmer – der Nutzer, das Frontend (Browser/UI), der Auth-Service auf dem Server und eine Datenbank. Lies das Diagramm von oben nach unten:

Sequenzdiagramm: Login-Vorgang

Lies das Diagramm Zeile für Zeile: (1) der Nutzer tippt Login-Daten ins Frontend, (2) das Frontend ruft login() beim AuthService auf, (3) der AuthService fragt die Datenbank nach dem User, (4) bekommt User-Daten (oder null) zurück, (5) prüft das Passwort intern, (6) erzeugt eine Session, (7) die DB gibt die SessionId zurück, (8) der AuthService antwortet dem Frontend, (9) das Frontend zeigt das Dashboard. Die Aktivierungsbalken zeigen schön, wer gerade „dran ist": das Frontend wartet die ganze Zeit auf die Antwort. Der AuthService wartet zwischendrin auf die DB. Sequenzdiagramme machen Wartezeiten und Abhängigkeiten sichtbar.

4) Die Schritt-für-Schritt-Erzählung

Manchmal hilft es, das Diagramm in Worte zu fassen – besonders zu Beginn, wenn man sie selbst lesen lernt. So liest sich der obige Login-Flow als Geschichte:

Was passiert wann?

Der Nutzer gibt E-Mail und Passwort in die UI ein und klickt „Anmelden".

Das Frontend ruft login(email, pw) beim Auth-Service auf – synchron, es wartet auf eine Antwort.

Der Auth-Service braucht den User-Datensatz und fragt die Datenbank mit findUser(email).

Die Datenbank liefert den User zurück (oder null, wenn nicht gefunden). Gestrichelter Pfeil = Rückgabe.

Der Auth-Service prüft das Passwort intern – mit gehashtem Vergleich (vgl. K11 Hashing). Die kleine Schleife auf der eigenen Lebenslinie markiert einen Selbstaufruf.

Bei erfolgreicher Prüfung wird createSession(user) auf der DB aufgerufen.

Die DB liefert die neue SessionId zurück.

Der Auth-Service gibt das Ergebnis an das Frontend zurück – SessionToken bei Erfolg oder Fehlermeldung.

Das Frontend rendert das Dashboard und der Nutzer ist eingeloggt.

Diese Schritt-Erzählung ist in der Praxis sehr nützlich – sie ist quasi der textuelle Begleiter zum Diagramm. Wenn du in einer Klausur ein Sequenzdiagramm zeichnen sollst, ist es oft sinnvoll, erst diese Reihenfolge in Worten festzuhalten und dann das Diagramm zu zeichnen.

5) Synchron vs. asynchron – ein zentraler Unterschied

Eine der wichtigsten Unterscheidungen in Sequenzdiagrammen ist die Art der Nachricht. Synchron heißt: der Aufrufer wartet, bis er eine Antwort bekommt. Klassischer Methodenaufruf. Asynchron heißt: der Aufrufer schickt die Nachricht ab und macht sofort weiter, ohne auf eine Antwort zu warten.

Drei Pfeil-Arten im Detail

Synchron

Durchgezogener Pfeil, gefüllte Spitze. Aufrufer wartet. Beispiel: Methodenaufruf in Java/Python. Browser wartet auf HTTP-Response.

Asynchron

Durchgezogener Pfeil, offene Spitze (zwei Striche). Aufrufer macht sofort weiter. Beispiel: Event auf Message Queue, Notification senden.

Rückgabe

Gestrichelter Pfeil. Antwort auf einen synchronen Aufruf. Pfeilrichtung geht vom Aufgerufenen zurück zum Aufrufer.

Eselsbrücke für die Pfeilspitzen: gefüllt = der wartet, offen = der ist weg. Bei asynchronen Aufrufen gibt es typischerweise keine direkte Rückgabe – die Antwort (falls überhaupt eine kommt) ist eine separate asynchrone Nachricht in die andere Richtung. Das ist typisch für ereignisgesteuerte Architekturen, Message Queues (Kafka, RabbitMQ – siehe L7 Microservices) oder Webhooks.

6) Aktivierungsbalken – wer ist gerade dran?

Die schmalen Rechtecke auf den Lebenslinien sind die Aktivierungsbalken (engl. activation bar oder execution specification). Sie zeigen, dass ein Objekt gerade einen Aufruf bearbeitet – also „aktiv ist". Sehr nützlich, um auf einen Blick zu sehen, wer wartet und wer gerade arbeitet.

Eine schöne Analogie: stell dir die Lebenslinien als Mitarbeiter*innen vor, die am Schreibtisch sitzen. Die Aktivierungsbalken sind die Zeitspannen, in denen sie konkret an einer Aufgabe arbeiten. Wer keinen Balken hat, sitzt da und macht nichts – wartet vielleicht auf einen Anruf. Wer einen Balken hat, ist beschäftigt. Wenn ein Balken einen anderen aufruft, kann der erste „daneben hängen" und auf das Ergebnis warten – beide Balken aktiv, aber nur einer wirklich arbeitet.

In IHK-Klausuren ist das Zeichnen von Aktivierungsbalken oft optional, aber es zeigt Verständnis. Bei automatischen Tools sind sie meist eingeschaltet – das macht Diagramme deutlich besser lesbar.

7) Fragmente: Bedingungen und Schleifen

Bisher waren alle Beispiele linear – ein Schritt nach dem anderen. Aber was, wenn es Verzweigungen oder Schleifen gibt? Dafür gibt es kombinierte Fragmente: ein Rahmen um einen Teil des Diagramms mit einem Operator in der oberen linken Ecke. Die wichtigsten Fragmente, die in IHK-Aufgaben auftauchen:

Wichtige Fragmente

opt

optional

Block wird nur ausgeführt, wenn eine Bedingung wahr ist. Ähnlich wie if ohne else.

alt

alternative

Mehrere Alternativen, getrennt durch eine gestrichelte Linie. Wie if/else if/else.

loop

Block wird wiederholt – mit Bedingung oder Zähler (z.B. loop [1..n]). Wie eine Schleife.

par

parallel

Bereiche laufen parallel ab – ähnlich dem Fork im Aktivitätsdiagramm.

ref

reference

Verweis auf ein anderes Sequenzdiagramm – um große Diagramme zu modularisieren.

break

Wird ausgeführt und beendet dann den umgebenden Block. Ähnlich break in einer Schleife.

Schauen wir uns ein Beispiel mit einem alt-Fragment an: nach dem Login soll das System unterscheiden, ob das Passwort korrekt war oder nicht. Bei korrekt: Dashboard zeigen. Bei falsch: Fehlermeldung. So sieht das im Diagramm aus:

alt-Fragment: Passwort-Prüfung mit zwei Fällen

Der Rahmen um die zwei Pfade ist das alt-Fragment. Die obere Hälfte gilt, wenn die Bedingung [result == OK] wahr ist, die untere Hälfte (durch gestrichelte Trennlinie abgegrenzt) für [else]. Beide Pfade sind innerhalb des Rahmens – nur einer wird tatsächlich ausgeführt. Das ist die UML-Antwort auf if/else im Sequenzdiagramm.

8) Sequenzdiagramm vs. Aktivitätsdiagramm

Beide zeigen zeitliche Abläufe – aber sie sind grundverschieden in dem, was sie betonen. Diese Tabelle hilft bei der Entscheidung, welches Diagramm passt:

Wann welches Diagramm?

Sequenzdiagramm: „Wer ruft wen wann auf?"

Im Fokus stehen Objekte / Komponenten und ihre Interaktion. Pro Lebenslinie ein Teilnehmer. Zeit fließt von oben nach unten. Ideal für API-Calls, Methodenaufrufe, Komponentenkommunikation, technische Architektur. Antwortet auf: „Wer übermittelt welche Nachricht an wen?"

Aktivitätsdiagramm: „Was passiert in welcher Reihenfolge?"

Im Fokus steht der Prozess-Ablauf. Wer den Schritt macht, ist zweitrangig (oder über Swimlanes). Ideal für Geschäftsprozesse, Use-Case-Abläufe, Workflows. Antwortet auf: „Welche Schritte werden in welcher Reihenfolge ausgeführt?"

Eine grobe Faustregel: technisch / zwischen Komponenten → Sequenzdiagramm. fachlich / Geschäftsprozess → Aktivitätsdiagramm. In großen Projekten kommen oft beide vor – das Aktivitätsdiagramm zeigt den fachlichen Ablauf, das Sequenzdiagramm die technische Umsetzung. Beide ergänzen sich, anstatt zu konkurrieren.

9) Praktische Anwendungsgebiete

Wofür werden Sequenzdiagramme in der echten Software-Entwicklung verwendet? Die häufigsten Anwendungsfälle:

API-Dokumentation: wie ein Client mit einem Service kommuniziert – welche REST-Calls in welcher Reihenfolge.
Architektur-Reviews: wie die einzelnen Schichten oder Services miteinander reden.
Bug-Analyse: ein Sequenzdiagramm hilft, eine komplexe Interaktion zu rekonstruieren und zu erkennen, wo es schiefläuft. Klassisch beim Debugging.
Use-Case-Verfeinerung: ein Use-Case wird in einem Sequenzdiagramm technisch konkret gemacht.
Onboarding: neue Teammitglieder verstehen ein komplexes System schneller, wenn die zentralen Abläufe als Sequenzdiagramm dokumentiert sind.
Authentifizierungs- und Autorisierungs-Flows: OAuth, OpenID Connect, JWT-Validierung – fast immer mit Sequenzdiagrammen dokumentiert.

10) Häufige Fehler in Klausuren

Diese Stolperfallen tauchen in fast jeder Klausur auf:

Klassische Fehler

Zeit-Richtung vergessen

Sequenzdiagramme fließen von oben nach unten. Aktivitätsdiagramme fließen auch von oben nach unten – aber Sequenzdiagramme haben keine Pfeile nach unten auf einer Lebenslinie, sondern nach rechts/links zwischen Lebenslinien.

Rückgaben weggelassen

Bei synchronen Aufrufen erwartet man eine Rückgabe (gestrichelter Pfeil). Bei vielen Pfeilen lohnt es sich, alle Rückgaben zu zeichnen – sonst fehlt der Kontext, was zurückkommt.

Pfeilspitzen verwechselt

Synchron = gefüllt, asynchron = offen, Rückgabe = gestrichelt. Diese drei werden gerne durcheinander gebracht. In IHK-Klausuren oft 1-2 Punkte wert.

Objekt- statt Klassen-Notation

Im UML-Sequenzdiagramm ist die Notation :Klasse (Doppelpunkt + Klassenname) oder name:Klasse (mit Objektname). Nicht einfach „Klasse". Dieser Doppelpunkt ist Pflicht.

Datenfluss statt Methoden

Pfeile sind Nachrichten/Methodenaufrufe – keine Datenflüsse. Beschriftung ist ein Verb / Methodenname (login(), findUser()), kein Substantiv (UserDaten).

Kausalität verdreht

Eine Nachricht weiter unten kann nicht „vor" einer weiter oben liegen. Wenn du eine Antwort brauchst, bevor du fragst – Diagramm-Fehler. Reihenfolge muss zeitlich konsistent sein.

11) Stärken und Grenzen

Sequenzdiagramme sind großartig für eine bestimmte Sicht – aber sie sind nicht das Schweizer Taschenmesser für alles.

Stärken: sehr präzise zeitliche Abläufe, klare Kommunikationspfade, perfekt für API- und Service-Dokumentation, gut für Architektur-Reviews, machen Engpässe und Wartezeiten sichtbar.

Grenzen: komplexe Abläufe werden schnell unübersichtlich (mehr als 5-6 Lebenslinien oder 20+ Nachrichten sind hart zu lesen). Geschäftsregeln und Bedingungen sind besser im Aktivitätsdiagramm aufgehoben. Zustände einzelner Objekte sind im Zustandsdiagramm (L5 dieses Kurses) besser dargestellt.

Faustregel: ein Sequenzdiagramm zeigt einen konkreten Ablauf. Wer alle möglichen Abläufe in einem Diagramm abbilden will, produziert ein unverständliches Wirrwarr. Lieber 3 saubere Sequenzdiagramme (Happy Path, Fehlerfall, Sonderfall) als ein einziges mit zu vielen Fragmenten.

Zusammenfassung

Das Sequenzdiagramm ist ein UML-Diagrammtyp, der die Interaktion zwischen Objekten/Komponenten über die Zeit zeigt. Zeit fließt von oben nach unten, Teilnehmer stehen als Lebenslinien (vertikale gestrichelte Linien) nebeneinander, Nachrichten sind Pfeile zwischen den Lebenslinien. Aktivierungsbalken (schmale Rechtecke auf den Lebenslinien) zeigen, dass ein Teilnehmer gerade „aktiv" einen Aufruf bearbeitet. Pfeil-Arten: synchron (durchgezogen, gefüllte Spitze – Aufrufer wartet), asynchron (durchgezogen, offene Spitze – Aufrufer macht sofort weiter), Rückgabe (gestrichelt – Antwort auf synchronen Aufruf). Kombinierte Fragmente ermöglichen Verzweigungen und Schleifen: opt (optional), alt (alternative Pfade – das if/else der Sequenzdiagramme), loop (Schleife), par (parallel), ref (Verweis), break. Abgrenzung: Aktivitätsdiagramm zeigt den fachlichen Prozess-Ablauf, Sequenzdiagramm zeigt die technische Interaktion zwischen Komponenten. Beide ergänzen sich. Anwendung: API-Dokumentation, Architektur-Reviews, Bug-Analyse, Use-Case-Verfeinerung, Authentifizierungs-Flows. Typische Fehler in Klausuren: Pfeilspitzen verwechselt, Objekt-Notation ohne Doppelpunkt, Methoden als Substantive, fehlende Rückgaben, zeitliche Inkonsistenz. Faustregel: ein Sequenzdiagramm pro einem konkreten Ablauf. Praxis: Sequenzdiagramme glänzen, wenn die Architektur aus mehreren Komponenten besteht – wie in der Schichtenarchitektur (L6) oder bei Microservices (L7), und sie sind das Standard-Werkzeug zur Dokumentation von REST-API-Abläufen (L8). Nächste Lektion: Zustands- und Komponentendiagramme – die letzten beiden UML-Diagrammtypen, die in IHK-Prüfungen abgefragt werden.