Zustandsdiagramm und Komponentendiagramm

Zustands- und Komponentendiagramm

Wir haben in den letzten Lektionen drei UML-Diagrammtypen kennengelernt: Use-Case (Was tut das System?), Aktivität (In welcher Reihenfolge?) und Sequenz (Wer redet mit wem?). Diese Lektion ergänzt zwei weitere wichtige Diagrammtypen, die in der IHK-Prüfung gefragt werden: Zustandsdiagramme und Komponentendiagramme.

Beide haben sehr unterschiedliche Aufgaben: Zustandsdiagramme zeigen, welche Zustände ein Objekt annehmen kann und wie es zwischen ihnen wechselt. Komponentendiagramme zeigen die technische Struktur eines Systems – aus welchen Bausteinen es besteht und wie sie verbunden sind. Wir behandeln beide in einer Lektion, weil sie alleine etwas kompakter sind und unterschiedliche Aspekte derselben Architektur-Sicht beleuchten.

1) Das Zustandsdiagramm: Objekte haben Zustände

Viele Objekte in Software-Systemen haben einen Zustand, der sich im Laufe der Zeit ändert. Eine Bestellung kann „neu", „bezahlt", „versendet" oder „storniert" sein. Eine Ampel ist „rot", „gelb" oder „grün". Ein Dokument ist „Entwurf", „in Prüfung" oder „veröffentlicht". Diese Zustände und die Übergänge zwischen ihnen zu modellieren, ist Aufgabe des Zustandsdiagramms.

Eine schöne Analogie: stell dir das Zustandsdiagramm als Lebensgeschichte eines Objekts vor. Es wird geboren (Startzustand), durchläuft verschiedene Phasen (Zustände), und am Ende endet sein Leben (Endzustand). Auslöser für die Phasenwechsel sind Ereignisse – etwa „Zahlung eingegangen" oder „Stornierung".

2) Die Grundelemente des Zustandsdiagramms

Zustandsdiagramme sind angenehm minimalistisch. Nur vier Hauptelemente reichen für die meisten Diagramme aus:

Notations-Bausteine

Startzustand

Gefüllter Kreis. Anfangspunkt des Diagramms. Genau einmal pro Diagramm.

Endzustand

Ring mit Punkt. Lebensende des Objekts. Optional, kann mehrfach auftreten.

Zustand

Abgerundetes Rechteck mit Substantiv-Bezeichnung. Eine Phase im Leben des Objekts.

Transition

Pfeil mit Ereignis-Beschriftung. Übergang zwischen zwei Zuständen.

Die Beschriftung einer Transition folgt dem Schema Ereignis [Bedingung] / Aktion. Beispiel: bezahlen [Betrag > 0] / Quittung drucken. Bedingung und Aktion sind optional – das Ereignis allein reicht oft.

3) Ein klassisches Beispiel: Bestell-Lebenszyklus

Schauen wir uns das vermutlich häufigste Klausurbeispiel an: der Lebenszyklus einer Bestellung. Eine neue Bestellung beginnt im Zustand „Neu". Wenn sie bezahlt wird, geht sie in „Bezahlt" über. Nach dem Versand wird sie „Versendet" und schließlich „Geliefert". Zu jeder Zeit kann der Kunde stornieren. So sieht das im Zustandsdiagramm aus:

Zustandsdiagramm: Bestell-Lebenszyklus

Beachte mehrere Details: (1) der Hauptpfad geht von „Neu" über „Bezahlt" und „Versendet" zu „Geliefert" und endet. (2) Aus den ersten beiden Zuständen geht eine Storno-Transition zum Zustand „Storniert". Aus „Versendet" oder „Geliefert" ist Stornieren nicht möglich – das wird gezielt nicht eingezeichnet und ist Teil der Geschäftslogik. (3) Es gibt zwei Endzustände – einer für den normalen Abschluss, einer für die Stornierung. Das ist erlaubt und macht das Diagramm klarer als ein einzelner Endpunkt.

4) Zustände interaktiv erleben

Theorie ist gut, aber Zustandsdiagramme „spürt" man am besten, wenn man sie durchspielt. Hier eine Live-Simulation: du bist die Bestellung. Klick auf die verfügbaren Ereignisse und sieh, wie der Zustand wechselt. Nicht alle Buttons sind in jedem Zustand verfügbar – das ist Sinn der Sache:

Zustands-Simulator: Bestellung

Neu

Die Bestellung ist gerade eingegangen. Verfügbare Aktionen: bezahlen, stornieren.

Trace: Neu

Spiel ein bisschen damit herum: versuche „verpacken" gleich nach „Neu" zu klicken – geht nicht, weil das Diagramm diese Transition nicht hat. „bezahlen" funktioniert nur aus „Neu". Das ist der Sinn von Zustandsdiagrammen: sie machen ungültige Übergänge unmöglich. Wenn der Programmierer das Modell einhält, kann eine Bestellung nicht plötzlich von „Geliefert" zurück zu „Neu" springen. Genau diese Garantie ist der Wert des Modells.

5) Transitions im Detail: Ereignis, Bedingung, Aktion

Eine Transition wird im einfachsten Fall durch ein Ereignis ausgelöst. Es gibt aber drei Bestandteile, die in beliebiger Kombination an einen Pfeil geschrieben werden können. Das volle Format einer Transition-Beschriftung lautet: Ereignis [Bedingung] / Aktion

Ereignis (Trigger): was hat den Übergang ausgelöst? Z.B. bezahlen, timeout, onClick.
Bedingung (Guard) in eckigen Klammern: zusätzliche Voraussetzung für den Übergang. Z.B. [Betrag > 0] oder [Lager verfügbar]. Wenn die Bedingung falsch ist, findet der Übergang nicht statt, auch wenn das Ereignis eintritt.
Aktion (Action) nach Schrägstrich: was passiert während des Übergangs? Z.B. / Mail senden oder / Bestand reduzieren.

Ein konkretes Beispiel: bezahlen [Betrag > 0] / Quittung erstellen – heißt: wenn das Ereignis „bezahlen" eintritt UND der Betrag größer als 0 ist, wechselt der Zustand UND es wird eine Quittung erstellt. Bei Betrag = 0 findet der Übergang nicht statt.

6) Erweiterte Notation: Aktionen innerhalb von Zuständen

Zustände können zusätzlich zur Bezeichnung interne Aktionen enthalten. Drei Aktivitäten sind besonders wichtig:

entry / Aktion: wird beim Betreten des Zustands einmalig ausgeführt.
exit / Aktion: wird beim Verlassen einmalig ausgeführt.
do / Aktion: läuft kontinuierlich, solange der Zustand aktiv ist.

Beispiel: ein Zustand „Wird verarbeitet" könnte als entry / Statusanzeige aktualisieren, do / Daten validieren und exit / Log-Eintrag schreiben definiert sein. So lassen sich auch komplexe Zustände kompakt beschreiben, ohne jede Aktion in eine eigene Transition zu pressen.

7) Das Komponentendiagramm: Bausteine und ihre Verbindungen

Wir wechseln zum zweiten Thema dieser Lektion. Während das Zustandsdiagramm das Verhalten eines einzelnen Objekts zeigt, dokumentiert das Komponentendiagramm die technische Struktur eines Systems – aus welchen Bausteinen es besteht und wie sie miteinander verbunden sind.

Stell dir ein Komponentendiagramm wie einen Stadtplan vor: nicht detailliert genug, um jede Hauswand zu zeigen, aber so abstrakt, dass man die Bezirke, Hauptstraßen und Brücken erkennt. Genauso zeigt ein Komponentendiagramm das System auf der Ebene größerer Bausteine – nicht einzelne Klassen, sondern Module, Services, Bibliotheken oder Subsysteme.

8) Komponenten und Schnittstellen

Eine Komponente ist ein selbstständiger Software-Baustein mit klar definierten Schnittstellen. In modernen Systemen sind das oft Services oder Module mit eigenen Verantwortlichkeiten. Eine Komponente bietet Funktionalität an (provided interface, „Lutscher") und benötigt Funktionalität von anderen (required interface, „Halbschale"):

Komponentendiagramm: Webshop-Architektur

Die kleinen Kästchen links und rechts an jeder Komponente sind Ports, die kleinen Kreise auf den Verbindungslinien sind Schnittstellen. Der „Lollipop"-Kreis (auf einer Seite) zeigt eine angebotene Schnittstelle. Die „Halbschale" (auf der anderen Seite) zeigt eine benötigte. Vereinfacht werden beide oft als ein Kreis dargestellt, der die Verbindung markiert. Das Diagramm zeigt klar: jede Komponente hat genau definierte Verantwortlichkeiten, alle Datenzugriffe laufen über die zentrale Datenbank-Komponente, das API-Gateway ist die einzige externe Anlaufstelle.

9) Wozu Komponentendiagramme?

Komponentendiagramme glänzen in zwei Phasen der Software-Entwicklung. Erstens beim Entwurf: bevor man Code schreibt, klärt das Diagramm, welche Bausteine das System hat und wo die Schnittstellen liegen. Wer hängt wovon ab? Was kann unabhängig deployed werden? Diese Diskussionen lassen sich am Diagramm wesentlich effizienter führen als in reinem Text.

Zweitens bei der Dokumentation bestehender Systeme: ein neues Teammitglied versteht in 5 Minuten, wie die grobe Architektur aussieht. Auch Architektur-Reviews und Refactoring-Entscheidungen ruhen auf dieser Sicht. Im Kontext von Microservices (L7) sind Komponentendiagramme nahezu Pflicht – sonst verliert man schnell den Überblick.

Typische Anwendungsgebiete

Architektur-Skizzen

Erste Strukturentwürfe: welche Bausteine braucht das System überhaupt?

Modul-Dokumentation

Komponenten eines monolithischen Systems mit ihren Abhängigkeiten.

Microservice-Übersicht

Service-Landschaft mit ihren Schnittstellen und Abhängigkeiten.

Deployment-Vorbereitung

Welche Komponenten laufen wo? Vorstufe zum Deployment-Diagramm.

Bibliotheks-Übersicht

Welche externen Bibliotheken / Frameworks werden genutzt?

Onboarding

Neue Teammitglieder verstehen die Architektur in Minuten statt Tagen.

10) Zustands- vs. Komponentendiagramm: ein Vergleich

Die zwei Diagrammtypen dieser Lektion sind völlig unterschiedlich – beide sind UML, aber sie beantworten gegensätzliche Fragen:

Direkter Vergleich

Zustandsdiagramm

Verhalten eines Objekts über die Zeit. Frage: welche Zustände kann das Objekt annehmen? Wie wechselt es zwischen ihnen? Beispiel: Lebenszyklus einer Bestellung. Pro Diagramm: ein Objekt / eine Klasse. Dynamisch.

Komponentendiagramm

Struktur eines Systems. Frage: aus welchen Bausteinen besteht es? Wie sind sie verbunden? Beispiel: Webshop mit Frontend, Backend, DB, Auth-Service. Pro Diagramm: ein System / Subsystem. Statisch.

Eselsbrücke: Zustandsdiagramm = Verhalten über Zeit, Komponentendiagramm = Struktur zum Stichtag. Beide werden in der Praxis selten zusammen verwendet, weil sie unterschiedliche Aspekte beleuchten – aber beide gehören in den Werkzeugkasten jeder Software-Architektin.

11) Häufige Klausurfehler

Diese Fehler tauchen bei beiden Diagrammtypen regelmäßig auf:

Klassische Stolperfallen

Zustände als Verben

„Bezahlen" oder „Liefern" sind Aktionen, keine Zustände. Zustände sind Substantive oder Partizipien: „Bezahlt", „Versendet", „Geliefert".

Komponenten als Klassen

Komponenten sind größere Bausteine – Services, Module. Einzelne Klassen gehören ins Klassendiagramm. Komponentendiagramm ist auf grober Architektur-Ebene.

Transitions ohne Ereignis

Jede Transition zwischen zwei Zuständen muss ein Ereignis auf dem Pfeil haben. Ein Übergang ohne Auslöser ist undefiniert – woher soll das System wissen, wann er stattfindet?

Komponenten ohne Schnittstellen

Zwei Komponenten direkt mit einer Linie zu verbinden ohne Schnittstellen-Notation ist unscharf. Lieber explizit: welche Schnittstelle wird angeboten / benötigt?

Mehrere Startzustände

Pro Zustandsdiagramm gibt es genau einen Startzustand. Mehrere Startpunkte wären undefiniert: wo beginnt das Objekt? Endzustände dürfen mehrfach sein.

Komponentendiagramm zu detailliert

Wenn ein Komponentendiagramm 30+ Komponenten hat, ist es zu fein. Abstraktion! Lieber 5-10 Komponenten auf hoher Ebene und bei Bedarf Sub-Diagramme.

12) Die UML-Landschaft im Überblick

Damit hast du die wichtigsten UML-Diagrammtypen kennengelernt, die in IHK-Prüfungen abgefragt werden. UML kennt insgesamt 14 Diagrammtypen, aber die folgenden fünf decken über 90 % der Praxis und der Klausuren ab:

Use-Case-Diagramm – was tut das System? Anforderungs-Übersicht.
Aktivitätsdiagramm – wie läuft ein Prozess ab? Workflow-Sicht.
Sequenzdiagramm – wer redet mit wem? Interaktions-Sicht.
Zustandsdiagramm – welche Zustände hat ein Objekt? Verhaltens-Sicht.
Komponentendiagramm – welche Bausteine bilden das System? Struktur-Sicht.

Hinzu kommt das Klassendiagramm, das in K48 OOP ausführlich behandelt wird. Mit diesen sechs Diagrammtypen bist du sowohl praktisch als auch klausurtechnisch sehr gut aufgestellt.

Zusammenfassung

Diese Lektion behandelte zwei UML-Diagrammtypen mit sehr unterschiedlichen Aufgaben. Das Zustandsdiagramm zeigt das Verhalten eines Objekts über die Zeit: welche Zustände kann es einnehmen, durch welche Ereignisse wechselt es zwischen ihnen? Bausteine: Startzustand (gefüllter Kreis), Endzustand (Ring mit Punkt), Zustand (abgerundetes Rechteck mit Substantiv-Bezeichnung), Transition (Pfeil mit Ereignis [Bedingung] / Aktion). Zusätzlich können Zustände interne Aktionen haben: entry (beim Betreten), exit (beim Verlassen), do (während aktiv). Klassisches Beispiel: Bestell-Lebenszyklus (Neu → Bezahlt → Versendet → Geliefert, mit Storno-Pfaden). Das Komponentendiagramm zeigt die statische Struktur eines Systems: aus welchen Bausteinen besteht es, wie sind sie verbunden? Bausteine: Komponente (Rechteck mit «component»-Stereotyp, oft mit Port-Kästchen), angebotene Schnittstelle (Lollipop), benötigte Schnittstelle (Halbschale), Verbindungen. Anwendung: Architektur-Skizzen, Microservice-Übersicht, Modul-Dokumentation, Onboarding. Gegenüberstellung: Zustandsdiagramm zeigt Verhalten über Zeit (dynamisch, pro Objekt), Komponentendiagramm zeigt Struktur zum Stichtag (statisch, pro System). Typische Klausurfehler: Zustände als Verben formuliert, Transitions ohne Ereignis, Komponenten zu klein-granular, fehlende Schnittstellen-Notation. Damit ist die UML-Tour dieses Kurses abgeschlossen – die fünf wichtigsten Diagrammtypen für IHK-Prüfungen liegen vor dir: Use-Case, Aktivität, Sequenz, Zustand, Komponente. Die nächste Lektion verlässt die Modellierungs-Sicht und wechselt zur konkreten Architektur: Schichtenarchitektur (3-Tier) – das wichtigste Architektur-Pattern überhaupt.