Aufbau eines Sequenzdiagramms
Ein Sequenzdiagramm (sequence diagram) beantwortet eine Frage: Wer schickt wem wann welche Nachricht? Die Beteiligten stehen oben nebeneinander, die Zeit läuft von oben nach unten. Was weiter unten steht, passiert später. Mehr Leserichtung gibt es nicht, und genau das macht das Diagramm so gut prüfbar.
Lebenslinien
Jeder Beteiligte bekommt eine Lebenslinie (lifeline): oben ein Rechteck mit dem Namen, darunter eine senkrechte gestrichelte Linie. Der Name folgt dem Muster rolle: Klasse, zum Beispiel b: Buchungsservice. Brauchst du keinen Rollennamen, lässt du ihn weg und schreibst :Buchungsservice; der Doppelpunkt bleibt stehen und zeigt, dass ein Objekt dieser Klasse gemeint ist. Ein Mensch, der von außen mit dem System arbeitet, darf als Strichfigur erscheinen wie im Use-Case-Diagramm.
Aktivierungsbalken
Ein schmales Rechteck auf der Lebenslinie zeigt, wann ein Objekt gerade arbeitet: Es beginnt, wenn eine Nachricht ankommt, und endet mit der Antwort. Ruft ein Objekt während dieser Zeit selbst andere auf, bleibt sein Balken stehen, denn es wartet auf deren Antwort. Aktivierungsbalken (execution specification) sind in der Prüfung selten Pflicht, machen dein Diagramm aber deutlich lesbarer und bringen manchmal einen Zusatzpunkt.
Nachrichten: synchron, asynchron, Antwort
Eine Nachricht (message) ist ein waagerechter Pfeil von der Lebenslinie des Senders zur Lebenslinie des Empfängers, beschriftet mit dem Methodenaufruf, etwa istFrei(radNr, zeitraum). Welche Art gemeint ist, erkennst du nur an Spitze und Linie. Genau hier gehen in der Prüfung die meisten Punkte verloren.
| Pfeil | Art | Bedeutung |
|---|---|---|
| Synchrone Nachricht | Gefüllte Spitze. Der Sender wartet, bis die Antwort kommt. Der normale Methodenaufruf. | |
| Asynchrone Nachricht | Offene Spitze. Der Sender arbeitet sofort weiter, etwa bei einer Benachrichtigung oder einem Webhook. | |
| Antwort (reply) | Gestrichelt mit offener Spitze (eine gefüllte Spitze ist ebenfalls erlaubt). Rückgabe an den Aufrufer, beschriftet mit dem Ergebnis. |
Die Antwort beschriftest du mit dem Rückgabewert, also frei oder buchungsNr. Eine Antwort ohne vorherigen synchronen Aufruf gibt es nicht. Umgekehrt darfst du Antworten weglassen, wenn die Aufgabe sie nicht verlangt; zeichnest du sie, dann gestrichelt.
Selbstaufruf
Ruft ein Objekt eine eigene Methode auf, läuft der Pfeil von seiner Lebenslinie nach rechts, ein Stück nach unten und zurück auf dieselbe Lebenslinie. Dort beginnt ein zweiter, leicht versetzter Aktivierungsbalken. Im Beispiel unten lädt der Buchungsservice so mit ladeBelegung(radNr) die bestehenden Buchungen.
Objekt erzeugen und zerstören
Entsteht ein Objekt erst während des Ablaufs, zeigt ein gestrichelter Pfeil mit «create» auf den Kopf seiner Lebenslinie, der dann auf dieser Höhe beginnt. Wird ein Objekt zerstört, endet seine Lebenslinie mit einem großen X, meist ausgelöst durch eine Nachricht mit «destroy».
Fragmente: alt, opt und loop in Kürze
Verzweigungen und Wiederholungen zeichnest du mit einem kombinierten Fragment (combined fragment): ein Rahmen über die beteiligten Lebenslinien, links oben der Operator in einem kleinen Fünfeck. Jeder Bereich bekommt einen Wächter (guard) in eckigen Klammern. Bei alt trennt eine gestrichelte Linie die Bereiche, der letzte heißt oft [else].
| Operator | Bedeutung | Beispiel |
|---|---|---|
| alt | Alternativen, genau ein Bereich wird ausgeführt | [frei] buchen, [else] Hinweis |
| opt | Optional, ein Bereich, der nur bei erfüllter Bedingung läuft | [Newsletter gewünscht] Mail senden |
| loop | Wiederholung, solange der Wächter gilt | [für jede Position] Preis addieren |
UML kennt noch weitere Operatoren wie par für parallele Bereiche oder break. In Prüfungen reichen fast immer alt, opt und loop.
Beispiel: Ein Lastenrad buchen
Auf der Buchungsplattform der Stadtwerke Mittelstadt bucht ein Kunde in der Web-App ein Lastenrad für einen Zeitraum. Die Web-App fragt beim Buchungsservice an, ob das Rad frei ist; dieser lädt dazu die vorhandenen Belegungen. Ist das Rad frei, legt der Buchungsservice die Buchung an und lässt den Betrag beim Zahlungsanbieter reservieren. Der Kunde erhält eine Bestätigung. Sobald die Zahlung endgültig durch ist, meldet der Zahlungsanbieter das von sich aus an den Buchungsservice. Ist das Rad belegt, bekommt der Kunde einen Hinweis.
So liest du das Diagramm von oben nach unten:
- Der Kunde ruft
buche(radNr, zeitraum)auf. Die Web-App wird aktiv und bleibt es bis zur Antwort an den Kunden. - Die Web-App fragt synchron
istFrei(…)an und wartet. Der Buchungsservice ruft sich selbst mitladeBelegung(radNr)auf und antwortet mitfrei. - Das
alt-Fragment verzweigt: Im Fall[frei]folgt die Buchung mit Reservierung beim Zahlungsanbieter, jede synchrone Nachricht bekommt ihre gestrichelte Antwort. - Die Meldung
bestaetigt(zahlungsId)kommt später und asynchron: Der Zahlungsanbieter wartet auf keine Antwort, darum die offene Spitze und kein Rückpfeil. - Im Fall
[else]antwortet die Web-App dem Kunden nur mit einem Hinweis.
Das Zustandsdiagramm
Ein Zustandsdiagramm (state machine diagram) beschreibt ein einzelnes Objekt über seine Lebenszeit: in welchen Zuständen es sein kann und welches Ereignis es in den nächsten bringt. Eine Bestellung ist neu, dann bezahlt, dann versandt. Mehr Objekte oder Nachrichten gibt es hier nicht.
- Zustand (state): abgerundetes Rechteck mit einem Namen, der eine Situation beschreibt, etwa „Bezahlt“ oder „Wartet auf Kunde“.
- Startzustand: gefüllter Kreis. Genau ein Pfeil führt heraus, ohne Ereignis und Bedingung; eine Aktion ist erlaubt.
- Endzustand: Kreis mit gefülltem Kern. Es darf mehrere geben, aber keiner hat einen Pfeil nach draußen.
- Übergang (transition): Pfeil mit offener Spitze von einem Zustand zum nächsten, beschriftet nach dem Muster
ereignis [bedingung] / aktion.
| Teil | Bedeutung | Beispiel |
|---|---|---|
| Ereignis | Was den Übergang auslöst (Trigger) | zahlungEingang |
| [Bedingung] | Wächter: Übergang nur, wenn sie wahr ist | [vollständig] |
| / Aktion | Was beim Übergang ausgeführt wird | / rechnungSenden |
Alle drei Teile sind optional, die Reihenfolge ist aber fest. Soll ein Zustand beim Betreten, während er aktiv ist oder beim Verlassen etwas tun, schreibst du das unter einen Trennstrich in den Zustand: entry / …, do / … und exit / ….
Beispiel Bestellstatus
Eine neue Bestellung wird bezahlt, sobald die Zahlung vollständig eingegangen ist; dabei wird die Rechnung verschickt. Beim Versand erhält der Kunde die Sendungsnummer per Mail. Meldet der Paketdienst die Zustellung, ist die Bestellung abgeschlossen. Eine neue oder bezahlte Bestellung kann storniert werden, bei einer bezahlten wird der Betrag erstattet. Versandte Bestellungen lassen sich nicht mehr stornieren.
Achte auf das, was fehlt: Von „Versandt“ führt kein Pfeil nach „Storniert“, weil der Text das ausschließt. Ein Zustandsdiagramm sagt also nicht nur, was möglich ist, sondern auch, was nicht geht. Und ein Ereignis wie zahlungEingang wirkt nur im Zustand „Neu“; in jedem anderen Zustand wird es ignoriert.
Beispiel Ampel
Eine Verkehrsampel wechselt zeitgesteuert. Zeitereignisse schreibst du mit after(…), gemessen ab dem Betreten des Zustands. Weil die Ampel endlos läuft, hat ihr Diagramm keinen Endzustand. Das ist erlaubt und hier sogar richtig.
Sequenz, Aktivität oder Zustand?
Alle drei beschreiben Verhalten, und in der Aufgabe ist nicht immer der Name des Diagramms genannt. Frag dich, was im Mittelpunkt steht:
| Leitfrage | Diagramm | Erkennungsmerkmal |
|---|---|---|
| Wer ruft wen in welcher Reihenfolge auf? | Sequenzdiagramm | Mehrere Objekte, Zeit läuft nach unten, Nachrichten zwischen Lebenslinien. |
| Welche Schritte hat ein Prozess, mit Entscheidungen und Parallelität? | Aktivitätsdiagramm | Ein Ablauf aus Aktionen, Rauten und Balken, oft über mehrere Beteiligte. |
| Welche Zustände durchläuft ein einzelnes Objekt? | Zustandsdiagramm | Ein Objekt, Zustände als abgerundete Rechtecke, Ereignisse an den Übergängen. |
Faustregel: Stehen im Text Klassen oder Systemteile, die sich gegenseitig aufrufen (App, Server, Datenbank, Schnittstelle), ist es ein Sequenzdiagramm. Stehen dort Tätigkeiten von Menschen oder Abteilungen mit „wenn, dann“ und „gleichzeitig“, ist es ein Aktivitätsdiagramm. Geht es um die Zustände eines Objekts (Ticket, Auftrag, Gerät), ist es ein Zustandsdiagramm.
Zeichenaufgaben
Zeichne erst selbst, dann klapp die Musterlösung auf und vergleiche Punkt für Punkt.
Die Nordwerk AG baut ein Mitarbeiterportal. Ein Nutzer meldet sich auf der LoginSeite mit Benutzername und Passwort an. Die LoginSeite übergibt beides an die Benutzerverwaltung. Diese berechnet zunächst den Hash des eingegebenen Passworts und gibt dann zurück, ob die Anmeldung korrekt ist. Stimmt sie, startet die LoginSeite eine Sitzung und zeigt die Startseite an. Andernfalls erhält der Nutzer eine Fehlermeldung.
Aufgabe: Stellen Sie den Ablauf der Anmeldung als Sequenzdiagramm mit den drei Beteiligten dar. Verwenden Sie für die Fallunterscheidung ein geeignetes kombiniertes Fragment.
Zeichne auf Papier oder im Diagramm-Tool nachzeichnen: Es steckt in den Übungsprüfungen und öffnet sich dort bei jeder Zeichenaufgabe.
Musterlösung anzeigen
Die Benutzerverwaltung vergleicht den Hash, darum der Selbstaufruf berechneHash(passwort) auf ihrer Lebenslinie und nicht auf der LoginSeite. Das alt-Fragment umfasst nur, was sich je nach Ergebnis unterscheidet. Die Antworten an den Nutzer sind gestrichelt, weil sie den synchronen Aufruf anmelden(…) beantworten. Andere sinnvolle Methodennamen sind natürlich ebenso richtig.
So wird typischerweise bewertet
- 2 Punkte: drei Lebenslinien, Nutzer (Strichfigur oder Rechteck), :LoginSeite und :Benutzerverwaltung, mit Doppelpunkt.
- 2 Punkte: synchrone Aufrufe anmelden(…) und pruefe(…) mit gefüllter Spitze und Parametern.
- 1 Punkt: Selbstaufruf berechneHash(…) auf der Benutzerverwaltung.
- 1 Punkt: Antwort ok gestrichelt zurück an die LoginSeite.
- 3 Punkte: alt-Fragment mit Operator, Wächtern [ok] und [else] und gestrichelter Trennlinie.
- 1 Punkt: starteSitzung() im ersten Bereich, Startseite und Fehlermeldung als Antworten an den Nutzer.
Der IT-Service der Nordwerk AG verwaltet Störungstickets. Ein neues Ticket ist offen. Wird es einem Techniker zugewiesen, ist es in Bearbeitung, und der Techniker wird per Mail informiert. Braucht er weitere Informationen, stellt er eine Rückfrage, und das Ticket wartet auf den Kunden. Antwortet der Kunde, geht es in Bearbeitung zurück; antwortet er 14 Tage lang nicht, wird das Ticket geschlossen. Trägt der Techniker eine Lösung ein, gilt das Ticket als gelöst. Meldet der Kunde, dass das Problem weiter besteht, ist es wieder in Bearbeitung. Bestätigt er die Lösung oder meldet er sich 7 Tage lang nicht, wird das Ticket geschlossen und nicht mehr verändert.
Aufgabe: Erstellen Sie ein Zustandsdiagramm für ein Störungsticket mit den Zuständen Offen, In Bearbeitung, Wartet auf Kunde, Gelöst und Geschlossen. Beschriften Sie alle Übergänge.
Zeichne auf Papier oder im Diagramm-Tool nachzeichnen: Es steckt in den Übungsprüfungen und öffnet sich dort bei jeder Zeichenaufgabe.
Musterlösung anzeigen
Zwischen „In Bearbeitung“ und „Gelöst“ laufen zwei Übergänge in entgegengesetzte Richtungen, ebenso zwischen „In Bearbeitung“ und „Wartet auf Kunde“; jeder bekommt sein eigenes Ereignis. Die beiden Wege von „Gelöst“ nach „Geschlossen“ darfst du als einen Übergang mit zwei Auslösern schreiben (durch Komma getrennt) oder als zwei getrennte Pfeile. Die 14 und 7 Tage sind Zeitereignisse, darum after(…). Die Mail an den Techniker steht als Aktion am Übergang zuweisen und nicht als entry in „In Bearbeitung“: Ein entry würde bei jeder Rückkehr aus „Wartet auf Kunde“ die Mail erneut auslösen, gewollt ist sie nur bei der Zuweisung.
So wird typischerweise bewertet
- 2 Punkte: Startzustand mit Pfeil nach Offen, Endzustand nach Geschlossen.
- 2 Punkte: alle fünf Zustände als abgerundete Rechtecke mit passenden Namen.
- 4 Punkte: Übergänge vollständig und in der richtigen Richtung, auch die beiden Rückwege nach In Bearbeitung.
- 2 Punkte: Beschriftung nach dem Muster Ereignis [Bedingung] / Aktion, darunter die Aktion technikerMailen und die Zeitereignisse after(14 Tage) und after(7 Tage).
Typische Fehler
Jetzt selbst testen
Fünf Fragen zu beiden Diagrammen. Du hast so viele Versuche, wie du willst.
Ein Pfeil im Sequenzdiagramm ist durchgezogen und hat eine gefüllte Spitze. Was bedeutet das?
Wie beschriftest du den Kopf einer Lebenslinie für ein Objekt der Klasse Warenkorb ohne eigenen Rollennamen?
Ein Webshop soll für jede Position im Warenkorb den Preis beim Lagerservice abfragen. Welches Fragment passt?
Welche Beschriftung eines Übergangs ist nach UML richtig aufgebaut?
Die Aufgabe lautet: „Stellen Sie dar, welche Status ein Reparaturauftrag durchläuft.“ Welches Diagramm zeichnest du?