Seite 13. UML-Sequenzdiagramm

UML-Sequenzdiagramm

Diese Seite erklärt das UML-Sequenzdiagramm so, dass du es schnell für IHK-Aufgaben und Programmierlogik anwenden kannst.

Ein UML-Sequenzdiagramm zeigt:

Welche Objekte oder Teilnehmer beteiligt sind
welche Nachrichten zwischen ihnen ausgetauscht werden
in welcher zeitlichen Reihenfolge die Kommunikation abläuft
welche Rückgaben erfolgen
welche Prozesse nacheinander oder parallel ablaufen

Wichtig:

Ein Sequenzdiagramm zeigt einen konkreten Ablauf.
Der Ablauf wird von oben nach unten gelesen.

Grafik 1: UML-Sequenzdiagramm – Grundlagen

Diese Grafik zeigt die wichtigsten Bestandteile:

Teilnehmer / Objekte
Lebenslinien
Aktivierungsbalken
Nachrichten
Rückgaben
Zeitachse

Wofür braucht man ein UML-Sequenzdiagramm?

Ein Sequenzdiagramm wird verwendet, um die Kommunikation zwischen Objekten oder Systemteilen darzustellen.

Typische Beispiele:

Login prüfen
Bestellung aufgeben
Produkt speichern
Datenbankabfrage ausführen
Benutzeroberfläche ruft Service auf
Service ruft Datenbank auf

Es zeigt also nicht nur, was passiert, sondern vor allem:

wer mit wem spricht
in welcher Reihenfolge
welche Antwort zurückkommt

Woran erkenne ich in einer Aufgabe, dass ein Sequenzdiagramm gemeint ist?

Typische Signalwörter:

Grundidee

Ein Sequenzdiagramm zeigt einen konkreten Ablauf als Szenario.

Beispiel:

Benutzer gibt Login-Daten ein.
Die Oberfläche sendet die Daten an den LoginService.
Der LoginService fragt die Datenbank ab.
Die Datenbank gibt einen Benutzer zurück.
Der Service gibt den Loginstatus zurück.
Die Oberfläche zeigt eine Meldung an.

Daraus entsteht ein zeitlicher Ablauf zwischen:

Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository

Teilnehmer / Objekte

Teilnehmer stehen im Sequenzdiagramm oben.

Beispiele:

Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository

Wichtig:

Ein echter Benutzer kann als Akteur dargestellt werden.
Objekte werden häufig als instanz:Klasse geschrieben.

Beispiele:

loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository

Lebenslinie

Unter jedem Teilnehmer verläuft eine Lebenslinie nach unten.

Darstellung:

Teilnehmer
    |
    |
    |

In UML wird die Lebenslinie meistens gestrichelt dargestellt.

Merksatz:

Lebenslinie = zeigt, dass ein Teilnehmer während des Ablaufs existiert.

Zeitliche Reihenfolge

Ein Sequenzdiagramm wird von oben nach unten gelesen.

oben = früher
unten = später

Merksatz:

Die Reihenfolge der Nachrichten ergibt sich aus ihrer Höhe im Diagramm.

Nachricht / Methodenaufruf

Eine Nachricht zeigt, dass ein Teilnehmer einen anderen Teilnehmer aufruft.

Beispiel:

loginGUI → loginService: pruefeLogin(name, passwort)

Typisch im Diagramm:

durchgezogene Linie mit Pfeilspitze

Beispiele:

loginDatenEingeben(name, passwort)
pruefeLogin(name, passwort)
findeBenutzer(name)

Rückgabe

Eine Rückgabe zeigt das Ergebnis eines Aufrufs.

Beispiel:

userRepository --> loginService: benutzer

Typisch:

gestrichelte Linie zurück

Beispiele:

benutzer
loginStatus
dashboardDaten
benutzerKontext

Wichtig:

Rückgaben sind oft optional, aber in Lern- und Prüfungsdiagrammen sehr hilfreich.

Aktivierungsbalken

Ein Aktivierungsbalken zeigt, dass ein Teilnehmer gerade aktiv ist.

Beispiel:

loginService prüft gerade die Login-Daten.
userRepository sucht gerade den Benutzer.

Darstellung:

schmaler senkrechter Balken auf der Lebenslinie

Merksatz:

Aktivierungsbalken = Teilnehmer verarbeitet gerade etwas.

Grafik 2: Beispiel – Login prüfen

Diese Grafik zeigt einen Login-Ablauf.

Beteiligte Teilnehmer:

Benutzer
loginGUI:LoginGUI
loginService:LoginService
userRepository:UserRepository
dashboard:Dashboard

Ablauf:

1. Benutzer gibt Login-Daten ein.
2. LoginGUI ruft den LoginService auf.
3. LoginService fragt UserRepository ab.
4. UserRepository gibt Benutzer zurück.
5. LoginService gibt Loginstatus zurück.
6. Danach laufen zwei Prozesse parallel:
   Prozess A: Dashboard laden
   Prozess B: Benutzerkontext laden
7. Danach wird die Startseite angezeigt.

Parallele Prozesse

In der IHK-nahen Darstellung können parallele Abläufe durch zwei parallele Linien markiert werden.

In unserem Beispiel:

Prozess A: Dashboard laden
Prozess B: Benutzerkontext laden

Wichtig:

Parallel bedeutet:
Die Prozesse müssen nicht streng nacheinander ablaufen.
Sie können gleichzeitig oder unabhängig voneinander gestartet werden.

Merksatz:

Parallele Linien = paralleler Ablaufbereich

Beispiel als Textablauf

Aufgabe:

Ein Benutzer gibt seine Login-Daten ein.
Die Oberfläche sendet Name und Passwort an den LoginService.
Der LoginService sucht den Benutzer über das UserRepository.
Das UserRepository gibt den Benutzer zurück.
Der LoginService gibt den Loginstatus zurück.
Nach erfolgreichem Login werden Dashboarddaten und Benutzerkontext geladen.
Danach wird die Startseite angezeigt.

Daraus entsteht:

Benutzer → loginGUI: loginDatenEingeben(name, passwort)
loginGUI → loginService: pruefeLogin(name, passwort)
loginService → userRepository: findeBenutzer(name)
userRepository --> loginService: benutzer
loginService --> loginGUI: loginStatus

parallel:
loginGUI → dashboard: ladeDashboard()
dashboard --> loginGUI: dashboardDaten

loginGUI → loginService: ladeBenutzerKontext()
loginService --> loginGUI: benutzerKontext

loginGUI → Benutzer: startseiteAnzeigen()

Sequenzdiagramm vs. Aktivitätsdiagramm

Merksatz:

Sequenzdiagramm = Wer ruft wen wann auf?
Aktivitätsdiagramm = Was passiert als nächstes?

Sequenzdiagramm vs. Klassendiagramm

Merksatz:

Klassendiagramm = Bauplan
Sequenzdiagramm = Ablauf zwischen den Bauteilen

Typische IHK-Fehler

Vorgehensweise in der Prüfung

Wenn du ein Sequenzdiagramm erstellen sollst, gehe so vor:

Prüfungs-Merksätze

Teilnehmer stehen oben.
Lebenslinien laufen nach unten.
Zeit läuft von oben nach unten.
Nachrichten sind horizontale Pfeile.
Synchrone Aufrufe werden durchgezogen gezeichnet.
Rückgaben werden gestrichelt gezeichnet.
Aktivierungsbalken zeigen Verarbeitung.
Parallele Prozesse müssen erkennbar markiert werden.
Ein Sequenzdiagramm zeigt ein konkretes Szenario.

Mini-Beispiel 1

Aufgabe:

Ein Benutzer klickt auf Speichern.
Die Oberfläche sendet die Daten an den Controller.
Der Controller speichert die Daten in der Datenbank.
Die Datenbank gibt eine Bestätigung zurück.

Lösungsidee:

Benutzer → GUI: speichernKlicken()
GUI → Controller: speichern(daten)
Controller → Datenbank: insert(daten)
Datenbank --> Controller: ok
Controller --> GUI: gespeichert
GUI → Benutzer: bestätigungAnzeigen()

Mini-Beispiel 2

Aufgabe:

Ein Kunde gibt eine Bestellung auf.
Die Oberfläche sendet die Bestellung an den BestellService.
Der BestellService prüft den Lagerbestand.
Danach wird die Bestellung gespeichert.

Lösungsidee:

Kunde → ShopGUI: bestellungAufgeben()
ShopGUI → BestellService: bestellungPruefen()
BestellService → LagerService: bestandPruefen()
LagerService --> BestellService: bestandOK
BestellService → BestellungRepository: speichern()
BestellungRepository --> BestellService: gespeichert
BestellService --> ShopGUI: bestellungOK

Mini-Beispiel 3: Paralleler Ablauf

Aufgabe:

Nach dem Login werden Dashboarddaten und Benutzerdaten parallel geladen.

Lösungsidee:

parallel:
GUI → DashboardService: ladeDashboard()
DashboardService --> GUI: dashboardDaten

GUI → BenutzerService: ladeBenutzerDaten()
BenutzerService --> GUI: benutzerDaten

Merksatz:

Wenn zwei Abläufe unabhängig voneinander starten können,
kann ein paralleler Bereich sinnvoll sein.

Mini-Testfragen

Wer ruft wen wann auf?

oben = früher
unten = später

userRepository --> loginService: benutzer

Nachricht = Aufruf
Rückgabe = Ergebnis

Dashboard laden
Benutzerkontext laden

Der Ablauf wird von oben nach unten gelesen.

Nächste Seite

Danach kommt die eigene Trainer-Seite:

UML-Sequenzdiagramm-Trainer

Dort übst du:

Teilnehmer erkennen
Nachrichten richtig beschriften
Rückgaben unterscheiden
Reihenfolge beachten
parallele Prozesse erkennen
Sequenzdiagramme aus Textaufgaben ableiten