Verhaltensdiagramm

Zustandsdiagramm

Welche Zustände hat ein Objekt und was löst den Wechsel aus?

Eine Bestellung ist erst offen, dann bezahlt, dann versandt, und je nachdem, wo sie gerade steht, ist etwas anderes möglich. Genau das hält das Zustandsdiagramm fest: die Zustände, die ein einzelnes Objekt über seinen Lebenszyklus annimmt, und die Ereignisse, die den Wechsel auslösen. In der Prüfung erkennst du die Aufgabe daran, dass nach den Zuständen eines Objekts gefragt wird und nicht nach einem Ablauf mit mehreren Beteiligten.

Bestellung · Zustandsdiagramm UML 2.5.1
Zustandsdiagramm einer Bestellung: Offen, Bezahlt, Versandt, Storniert mit Ereignissen, Guard und Aktion Offen entry / reservieren Bezahlt do / kommissionieren Versandt Storniert zahlung [betrag = summe] versand / mailen zugestellt storno storno / erstatten

Notation im Vergleich.

Transition Offen Bezahlt zahlung [betrag = summe] / quittung
Interne Aktivitäten Kommissionierung entry / lager sperrendo / artikel packenexit / lager freigeben
Selbsttransition Warten auf Zahlung entry / erinnerung senden timeout
Zusammengesetzter Zustand In Bearbeitung Offen Bezahlt Storniert zahlung storno
Entscheidung Prüfung Freigegeben Abgelehnt geprüft [ok] [else]
Historie Wiedergabe H Spielt Pausiert Aus pause aus an

Die Beschriftung einer Transition: ereignis [guard] / aktion.

Ein Pfeil allein sagt nur, dass es weitergeht. Er soll aber auch sagen, was den Wechsel auslöst, unter welcher Bedingung er gilt und was dabei passiert. Dafür hat die Beschriftung drei Teile in fester Reihenfolge: das Ereignis vorn, der Guard in eckigen Klammern, dann hinter dem Schrägstrich die Aktion. Jeder der drei Teile darf fehlen. Fehlt an einer Transition aus einem Zustand das Ereignis, kann sie bei dessen Abschluss und erfülltem Guard feuern; UML nennt das eine Completion-Transition.

entry, do und exit gehören zum Zustand selbst.

Manches hängt nicht an einem einzelnen Übergang, sondern am Zustand. Solche internen Aktivitäten stehen unter dem Namen in einem eigenen Kompartiment: entry läuft einmal beim Betreten, exit einmal beim Verlassen, do startet nach entry und läuft bis zu seinem Abschluss oder bis zum Verlassen des Zustands. Weil entry und exit für jeden Weg hinein und hinaus gelten, notierst du sie einmal im Zustand statt an jeder Kante. Ist die do-Aktivität durchgelaufen, darf eine Transition ohne Ereignis feuern.

Die Selbsttransition verlässt den Zustand und betritt ihn neu.

Manchmal soll ein Ereignis den Zustand nicht wechseln, sondern ihn neu starten, etwa ein Timeout, das die Erinnerung erneut verschickt. Dafür zeichnest du eine Schleife vom Zustand zurück auf denselben Zustand. Diese Selbsttransition verlässt den Zustand wirklich, deshalb laufen exit und entry noch einmal. Soll das nicht passieren, notierst du das Ereignis als interne Transition im Kompartiment; dann bleibt der Zustand aktiv.

Ein zusammengesetzter Zustand bündelt Unterzustände.

Wenn mehrere Zustände dieselbe Ausnahme teilen, etwa ein Storno aus jedem Bearbeitungsschritt heraus, brauchst du sonst aus jedem Zustand eine eigene Kante. Stattdessen fasst du die Zustände in einem größeren Zustand zusammen und setzt die Transition an dessen Rand an. Sie gilt dann für alle Unterzustände darin. Innen bekommt der zusammengesetzte Zustand einen eigenen Startzustand, damit klar ist, wo es beim Eintritt über den Rand losgeht.

Die Entscheidung verzweigt über Guards an den Ausgängen.

Manchmal hängt das Ziel von einem Wert ab, der erst während des Übergangs feststeht. Dann führst du die Transition auf eine Raute und hängst an jede ausgehende Kante einen Guard. Ausgewertet wird erst beim Erreichen der Raute, also nach der Aktion der eingehenden Transition; [else] deckt ab, wenn kein anderer Guard zutrifft. Die Kreuzung (Junction) als kleiner gefüllter Kreis sieht ähnlich aus, wertet aber nichts dynamisch aus.

Die Historie H setzt beim zuletzt aktiven Unterzustand fort.

Wird ein zusammengesetzter Zustand verlassen und später wieder betreten, beginnt er normalerweise erneut bei seinem Startzustand. Oft soll es aber dort weitergehen, wo es aufgehört hat. Dafür führst du die Transition auf den Historienzustand H im Inneren, und der Eintritt landet im zuletzt aktiven Unterzustand. Beim allerersten Eintritt gibt es nichts zu erinnern, dann greift die Kante, die von H abgeht. H merkt sich nur die Ebene direkt darunter, H* (tiefe Historie) auch verschachtelte Unterzustände.

Wann entry, do und exit?

Und wann sie überflüssig sind

Meistens reicht der Zustand allein. Offen Bezahlt zahlung / quittung

Meistens reicht der Zustand allein.

Wenn beim Betreten und Verlassen nichts Besonderes passiert, bleibt das untere Kompartiment weg. Was beim Wechsel geschehen soll, steht dann als Aktion an der Transition. Ein Diagramm ganz ohne entry, do und exit ist in der Prüfung vollständig richtig.

entry, wenn jeder Weg hinein dasselbe auslöst. Offen Bezahlt Storniert entry / kunde informieren storno storno

entry, wenn jeder Weg hinein dasselbe auslöst.

Führen mehrere Transitionen in denselben Zustand und soll jedes Mal dieselbe Aktion laufen, müsstest du sie an jede Kante schreiben. Stattdessen notierst du sie einmal als entry im Zustand. Für das Verlassen gibt es exit nach demselben Muster, das brauchst du aber selten.

do, wenn im Zustand etwas länger läuft. Bezahlt do / kommissionieren Versandbereit

do, wenn im Zustand etwas länger läuft.

Während eines Übergangs wird kein weiteres Ereignis abgearbeitet; UML legt seine Dauer aber nicht fest. Soll ein länger laufendes Verhalten wie Kommissionieren oder Herunterladen durch Ereignisse unterbrechbar sein, gehört es als do in den Zustand. Ist die do-Aktivität fertig, darf eine Transition ohne Ereignis feuern.

  • Aktion an der Transition: passiert nur auf diesem einen Weg.
  • entry im Zustand: passiert auf jedem Weg hinein, einmal notiert.
  • do im Zustand: läuft nach entry bis zum eigenen Abschluss oder zum Verlassen des Zustands.
  • exit im Zustand: Aufräumen beim Verlassen, egal wohin. Selten.

Symbole und Notation.

14 Elemente

Zustand Bezahlt

Zustand

Rechteck mit runden Ecken, Name innen

Eine Situation, in der das Objekt eine Zeit lang bleibt, weil es auf ein Ereignis wartet oder eine do-Aktivität ausführt. Der Name benennt den Zustand und nicht die Tätigkeit, also "Bezahlt" und nicht "Bezahlen".

Startzustand Offen

Startzustand

Gefüllter Kreis

Markiert, wo der Lebenszyklus beginnt. Pro Region gibt es höchstens einen initialen Pseudozustand. Für den Standard-Eintritt führt von ihm eine Transition zum ersten Zustand oder zu einer weiteren Verzweigung. Sie hat keinen Guard und normalerweise kein Ereignis.

Endzustand Zugestellt

Endzustand

Gefüllter Kreis mit Ring

Zeigt den Abschluss seiner Region. Sind alle obersten Regionen fertig, endet der Zustandsautomat. Der Endzustand hat keine ausgehenden Transitionen.

Transition Offen Bezahlt zahlung

Transition

Pfeil mit offener Spitze

Der Wechsel von einem Zustand in einen anderen. Beschriftet wird sie nach dem Muster ereignis [guard] / aktion, wobei jeder dieser drei Teile fehlen darf.

Ereignis Offen Verfallen after 14 d

Ereignis

ereignis, ganz vorn in der Beschriftung

Der Auslöser des Wechsels. Das kann ein Signal von außen sein, ein Aufruf, ein Zeitablauf wie after 14 d oder eine Bedingung, die wahr wird, wie when x > 0.

Guard Offen Bezahlt zahlung [betrag = summe]

Guard

[bedingung], hinter dem Ereignis

Eine Bedingung in eckigen Klammern, die zusätzlich erfüllt sein muss. Tritt das Ereignis ein und der Guard ist falsch, feuert die Transition nicht und das Objekt bleibt im Zustand.

Aktion Bezahlt Versandt versand / mailen

Aktion

/ aktion, am Ende der Beschriftung

Was während des Wechsels ausgeführt wird. Während des Übergangs wird kein weiteres Ereignis abgearbeitet. Ein Verhalten, das auf Ereignisse reagieren und unterbrochen werden soll, gehört als do-Aktivität in einen Zustand.

entry / do / exit Bezahlt entry / quittungdo / kommissionierenexit / lager buchen

entry / do / exit

Eigenes Kompartiment unter dem Namen

Aktivitäten, die zum Zustand selbst gehören: entry beim Betreten, do während des Aufenthalts, exit beim Verlassen. Weil sie für jeden Weg hinein und hinaus gelten, stehen sie einmal im Zustand statt an jeder Kante.

Selbsttransition Warten timeout

Selbsttransition

Schleife vom Zustand auf sich selbst

Ein Ereignis, das den Zustand verlässt und sofort wieder betritt, deshalb laufen exit und entry erneut. Eine interne Transition im Kompartiment tut das nicht, dort bleibt der Zustand durchgehend aktiv.

Zusammengesetzter Zustand Aktiv Offen Bezahlt zahlung storno

Zusammengesetzter Zustand

Größerer Zustand mit Unterzuständen

Fasst mehrere Unterzustände zu einem gemeinsamen Zustand zusammen. Eine Transition, die am Rand ansetzt, gilt für alle Unterzustände darin, ein Abbruch braucht deshalb nur eine Kante. Für den Standard-Eintritt über den Rand gibt es innen einen initialen Pseudozustand.

Entscheidung Freigegeben Abgelehnt [ok] [else]

Entscheidung

Raute mit Guards an den Ausgängen

Verzweigt einen Übergang abhängig von Bedingungen. Die Guards werden erst ausgewertet, wenn die Raute erreicht ist, also nach der Aktion der eingehenden Transition.

Historie Wiedergabe H Spielt

Historie

Kreis mit H, tief als H*

Merkt sich, welcher Unterzustand zuletzt aktiv war. Eine Transition auf H setzt den zusammengesetzten Zustand dort fort statt bei seinem Startzustand. H betrifft die Ebene direkt darunter, H* auch verschachtelte Unterzustände.

Terminierung Fehler

Terminierung

Kreuz am Ende der Transition

Das Objekt hört sofort auf zu existieren, ohne den Endzustand zu erreichen. Das passt für Abbrüche, bei denen nichts mehr geordnet abgeschlossen wird, etwa ein leerer Akku.

Kreuzung A B C

Kreuzung

Kleiner gefüllter Kreis

Bündelt mehrere Transitionen zu einem gemeinsamen Weg oder teilt einen Weg wieder auf. Anders als bei der Raute wird hier nichts dynamisch ausgewertet, die Guards stehen schon beim Verlassen des Ausgangszustands fest.

So liest und zeichnest du ein Zustandsdiagramm.

Wozu das Diagramm da ist

In der Prüfung steht im Aufgabentext ein einzelnes Ding: eine Bestellung, ein Ticket, ein Gerät. Gefragt ist, welche Zustände es durchläuft und was den Wechsel auslöst. Das Zustandsdiagramm beschreibt genau das, nämlich ein Objekt oder alle Objekte einer Klasse über den gesamten Lebenszyklus. Ein Zustand ist dabei eine Situation, in der das Objekt bleibt, bis ein Ereignis eintritt oder sein Verhalten abgeschlossen ist.

Woher die Notation kommt

UML wird von der Object Management Group (OMG) standardisiert, einem Gremium, das Modellierungssprachen pflegt. Die aktuelle Fassung ist UML 2.5.1, dort steht das Zustandsdiagramm in Kapitel 14. Die Spezifikation legt fest, welche Symbole es gibt und was sie bedeuten. Wie du das Diagramm auf dem Blatt anordnest, welche Farben du nimmst und mit welchem Werkzeug du zeichnest, regelt sie nicht.

So liest du es

Du beginnst am gefüllten Kreis und folgst den Pfeilen. Über jedem Pfeil steht die Beschriftung in der Reihenfolge ereignis [guard] / aktion, wobei jeder Teil fehlen darf. Im Zustand steht oben der Name, darunter durch eine Linie getrennt entry, do und exit. Jede Stelle beantwortet damit dieselbe Frage: Was passiert, wenn dieses Ereignis eintritt, während das Objekt gerade hier steht?

Dabei gilt Run-to-Completion: Das Objekt verarbeitet ein Ereignis vollständig, bevor es das nächste annimmt. Ereignisse, die währenddessen eintreffen, warten.

Der Unterschied zum Aktivitätsdiagramm

Das ist die häufigste Verwechslung in der Prüfung. Ein Aktivitätsdiagramm zeigt einen Ablauf, also Schritte, die nacheinander abgearbeitet werden, oft über mehrere Beteiligte hinweg. Ein Zustandsdiagramm zeigt ein einziges Objekt, das in einem Zustand verharrt und auf Ereignisse reagiert. Am schnellsten siehst du es an den Namen: im Aktivitätsdiagramm stehen Tätigkeiten in den Knoten ("Zahlung prüfen"), im Zustandsdiagramm Zustände ("Bezahlt").

So zeichnest du es in der Prüfung

  1. 1Lege fest, welches eine Objekt du beschreibst. Steht im Text "Bestellung", beschreibt jeder Zustand im Diagramm eine Bestellung und nicht das System drumherum.
  2. 2Sammle die Situationen, in denen dieses Objekt eine Zeit lang bleibt, und benenne sie als Zustand: Offen, Bezahlt, Versandt.
  3. 3Setze links den Startzustand als gefüllten Kreis und dorthin, wo der Lebenszyklus endet, den Endzustand als Kreis mit Ring.
  4. 4Verbinde die Zustände in der Reihenfolge des Normalfalls und schreibe an jede Kante das Ereignis, das den Wechsel auslöst.
  5. 5Ergänze Abbrüche und Rückwege wie Storno oder Retoure. Gehen sie aus mehreren Zuständen gleich ab, fasse diese zu einem zusammengesetzten Zustand zusammen und setze die Kante an dessen Rand an.
  6. 6Trage Guards in eckigen Klammern nach, wo eine Bedingung gilt, und Aktionen hinter dem Schrägstrich, wo beim Wechsel etwas passiert. entry, do und exit nur dort, wo sie wirklich etwas beitragen.
  7. 7Geh das Diagramm einmal von vorn durch: höchstens ein initialer Pseudozustand pro Region, ein definierter Standard-Eintritt und keine Kante aus einem Endzustand heraus. Sind alle vorgesehenen Zustände erreichbar? Ein normaler Zustand darf ohne ausgehende Transition dauerhaft aktiv bleiben.

Prüfe dich selbst: Ein Seminarplatz kann gebucht, bezahlt und storniert werden, und wenn zwei Wochen vor Beginn keine Zahlung eingegangen ist, verfällt die Buchung. Welche Zustände zeichnest du, und an welcher Kante steht ein Zeitereignis statt eines Ereignisses von außen?

Typische Prüfungsfehler.

6 Paare

Zustände als Tätigkeiten benannt.

falsch Falsch: Zustände als Tätigkeiten benannt. Bezahlen Versenden
richtig Richtig: Zustände als Tätigkeiten benannt. Bezahlt Versandt versand

Wer den Ablauf im Kopf hat, notiert beim Zeichnen automatisch, was gerade getan wird. Ein Zustand beschreibt aber, worin sich das Objekt befindet, während es wartet oder etwas dauert. Aus "Bezahlen" wird deshalb "Bezahlt" oder "Wartet auf Zahlung". Die Tätigkeit selbst wandert als Aktion an die Transition oder als do-Aktivität in den Zustand. Tätigkeitsnamen sind kein UML-Syntaxfehler; hier passen sie aber nicht zu den gemeinten, bereits erreichten Zuständen.

Transition ohne Ereignis, obwohl etwas passieren muss.

falsch Falsch: Transition ohne Ereignis, obwohl etwas passieren muss. Offen Bezahlt
richtig Richtig: Transition ohne Ereignis, obwohl etwas passieren muss. Offen Bezahlt zahlung

Der nächste Schritt ist beim Zeichnen so selbstverständlich, dass die Beschriftung wegbleibt. Eine Transition aus einem Zustand ohne Ereignis kann aber bei dessen Abschluss und erfülltem Guard von selbst feuern. Wartet das Objekt auf etwas von außen, gehört genau dieser Auslöser an die Kante.

Guard und Aktion vertauscht.

falsch Falsch: Guard und Aktion vertauscht. Offen Bezahlt zahlung / [betrag = summe]
richtig Richtig: Guard und Aktion vertauscht. Offen Bezahlt zahlung [betrag = summe] / quittung

Guard und Aktion stehen beide hinter dem Ereignis, deshalb geraten sie leicht durcheinander. Die Reihenfolge ist aber festgelegt: erst das Ereignis, dann der Guard in eckigen Klammern, dann nach dem Schrägstrich die Aktion. Der Schrägstrich leitet immer eine Aktion ein, nie eine Bedingung.

Zwei Startzustände auf einer Ebene.

falsch Falsch: Zwei Startzustände auf einer Ebene. Gast Angemeldet
richtig Richtig: Zwei Startzustände auf einer Ebene. Gast Angemeldet [kein Token] [Token]

Wenn ein Objekt auf zwei Arten anfangen kann, wirkt es naheliegend, zwei Anfänge zu zeichnen. Ein Objekt beginnt aber genau einmal, und pro Region ist höchstens ein initialer Pseudozustand erlaubt. Die beiden Wege modellierst du hinter dem Startzustand über eine Entscheidung mit Guards.

Transition aus dem Endzustand heraus.

falsch Falsch: Transition aus dem Endzustand heraus. Versandt Retour retoure
richtig Richtig: Transition aus dem Endzustand heraus. Versandt Zugestellt Retour zugestellt retoure

Der Endzustand wird oft als "vorerst fertig" gelesen, gemeint ist aber der Abschluss seiner Region. Aus ihm führt keine Transition heraus. Wenn es weitergehen kann, war die Situation ein normaler Zustand, hier "Zugestellt", von dem aus die Retoure abzweigt.

Ereignis in eckigen Klammern.

falsch Falsch: Ereignis in eckigen Klammern. Offen Storniert [storno]
richtig Richtig: Ereignis in eckigen Klammern. Offen Storniert storno

Eckige Klammern sehen nach Beschriftung aus, deshalb landet das Ereignis manchmal darin. Sie sind aber für Bedingungen reserviert. Das Ereignis steht ohne Klammern am Anfang der Beschriftung, der Guard folgt erst danach.

Zwei vollständige Beispiele.

Support-Ticket: zusammengesetzter Zustand, interne Aktivitäten und ein Zeitereignis.

Das Diagramm verfolgt ein einzelnes Ticket von der Meldung bis zum Abschluss. In Bearbeitung fasst drei Unterzustände zusammen und hat einen eigenen Startzustand, deshalb landet die Kante zuweisen über den Rand zunächst bei Zugewiesen. Wieder öffnen zeigt den Unterschied dazu: Sie zielt direkt auf Aktiv und überspringt den inneren Start. after 14 d ist ein Zeitereignis, es braucht keinen Auslöser von außen.

Support-Ticket · Zustandsdiagramm UML 2.5.1
Zustandsdiagramm eines Support-Tickets In Bearbeitung Neu entry / nummer vergeben Zugewiesen Aktiv do / bearbeiten Wartet auf Kunde Gelöst entry / kunde informieren Geschlossen zuweisen / mail annehmen rückfrage antwort lösung [getestet] after 14 d wieder öffnen

Mediaplayer: Historie, Entscheidung und Terminierung.

Aus bedeutet hier Standby: Das Player-Objekt und seine Historie bleiben im Speicher. Beim ersten Einschalten führt H über seine Defaultkante zu Bereit, später in den zuletzt aktiven Unterzustand. Die Historie merkt sich dessen Identität, nicht automatisch die Abspielposition; eine do-Aktivität startet beim erneuten Betreten neu. Nach stop aus Pausiert führt die Entscheidung bei vorhandenen Titeln zu Bereit, sonst in den Standby. Nur entsorgen aus dem Standby beendet die Lebensdauer dieses Player-Objekts über das Terminierungssymbol. Ein leerer Akku wäre kein Grund, das Gerät als Objekt zu zerstören.

Mediaplayer · Zustandsdiagramm UML 2.5.1
Zustandsdiagramm eines Mediaplayers mit Historie Eingeschaltet Aus H Bereit Spielt do / audio ausgeben Pausiert entsorgen power power play [titel gewählt] pause play stop [titel vorhanden] [else]