Navigation in Benutzerschnittstellen mit UML-Zustandsdiagrammen planen
https://bildung.social/@oerinformatik/113350667437731167
https://oer-informatik.de/geschaeftsprozess-ui-states-entwerfen
UML-Zustandsdiagramm, GUI-Entwurf, Navigation, Benutzeroberfläche, Maske, Transition, Trigger, Guard, Effekt, zusammengesetzter Zustand, Historie, Rollenkonzept
tl/dr; (ca. 12 min Lesezeit): Der Ablauf des Geschäftsprozesses steht fest, jetzt geht es darum, die einzelnen Masken zu modellieren. Jede Maske repräsentiert dabei einen Zustand, den die Benutzeroberfläche einnimmt. Diese Zustände und deren Übergänge werden mit einem UML-Zustandsdiagramm geplant, hierfür gibt es einige Kniffe, um bei größeren Seitenkomplexen eine übersichtliche Modellierung sicherzustellen (Teil der Artikelserie zur Gestaltung und Entwicklung von Benutzeroberflächen für Geschäftsprozesse) [AI-Assisted]. (Zuletzt geändert am 29.10.2026)
Dieser Artikel ist Teil einer Artikelreihe über Benutzerschnittstellen für Geschäftsprozesse: Ist-Analyse und Prozessanalyse: Geschäftsprozesse erfassen, bewerten und verbessern / Geschäftsprozesse digitalisieren und optimieren / Digitalisierte Geschäftsprozesse mit dem UML-Aktivitätsdiagramm entwerfen / Navigation in Benutzerschnittstellen mit UML-Zustandsdiagrammen planen / Usability, User Experience und Barrierefreiheit: Software, die alle gern nutzen / GUI-Seiten mit Wireframes und Mockups entwerfen
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Dieser Artikel baut auf der Kann-Liste des Artikels UML-Zustandsdiagramm auf.
Als GUI-Entwurf-Grundlagen kann ich nach Durchlesen des Artikels…
… erklären, warum sich die Masken bzw. Seiten einer Benutzeroberfläche als Zustände eines UML-Zustandsdiagramms modellieren lassen.
… die Beschriftung einer Transition
Trigger [Guard] / Effektnotieren und die drei Bestandteile unterscheiden.… für eine einfache WebApp (Login, Registrierung, angemeldeter Bereich) Zustände und Transitionen in einem Zustandsdiagramm darstellen.
… eine Navigation, die je nach Bedingung zu unterschiedlichen Masken führt, mit einem Auswahl-Pseudozustand (choice) und Guards modellieren.
… gemeinsames Verhalten mehrerer Seiten (z. B. Abmelden) über einen zusammengesetzten Zustand mit Unterzuständen und Startzustand zusammenfassen.
Darüber hinaus kann ich als GUI-Entwurf-Expertenwissen…
… beurteilen, ob Rollen mit unterschiedlichen Rechten besser über eigene Zustände mit Guards oder über verschachtelte zusammengesetzte Zustände abgebildet werden.
… die Wirkung von Startzustand (initial state) und tiefer Historie (deep history) beim Eintritt in einen zusammengesetzten Zustand erklären.
Abfolge der GUI-Masken als Zustände begreifen
Graphische Oberflächen bestehen zumeist aus unterschiedlichen Masken/Webseiten, die sich nicht nur in den angezeigten Texten, Grafiken und Widgets unterscheiden, sondern auch in ihrem Verhalten.
Wir können jede Maske/Seite als einen eigenen Zustand begreifen, der mit bestimmten Attributwerten und einem definierten Verhalten verknüpft wird. Zwischen den unterschiedlichen Masken kann oft nicht in beliebiger Reihenfolge navigiert werden, sondern es sind mitunter einige Abfolgen vorgegeben und andere unmöglich.
Um nicht gleich mit der Tür ins Haus zu fallen, wollen wir die GUI einer WebApp zunächst Stück für Stück planen.
Schritt eins: Login
Drei erste Masken liegen bei einer WebApp auf der Hand: Man muss Benutzernamen/Passwort eingeben, die Möglichkeit haben, ein neues Konto zu registrieren, und es gibt einen Bereich für angemeldete Nutzende:
Schritt zwei: Transitionen eintragen
Zwischen den Masken muss die Navigation eingezeichnet werden. Im UML-Zustandsdiagramm wird dies in der Form…
TRIGGER [GUARD] /EFFEKT… vorgenommen, wobei der Trigger das Ereignis ist, das den Zustandsübergang auslöst, der Guard (Wächterbedingung) die Bedingung ist, die wahr sein muss, damit der Zustandsübergang ausgeführt wird, und der Effekt (effect) das Verhalten ist, das ausgeführt wird, wenn der Zustand gewechselt wird.
Bereits in unserem einfachen Beispiel erhalten wir ein recht anspruchsvolles Diagramm:
Es existieren mehrere Zustandsübergänge zwischen denselben Zuständen mit unterschiedlichen Triggern (Speichern / Abbrechen). Außerdem gibt es Trigger, die über einen Auswahl-Pseudozustand (choice) je nach Guard zu unterschiedlichen Zuständen führen (Credentials == ok / else).
Einen Effekt haben wir im Beispiel bei der Speicherung der Registrierungsdaten (/saveUserLogin()).
Schritt drei: Unterseiten ergänzen
Wir fügen drei Standardseiten als Muster ein: eine Übersichtsseite (die beispielsweise eine Liste darstellt), eine Seite, die für einen Listeneintrag Details darstellt und eine dritte Seite, die diese Details zur Bearbeitung zur Verfügung stellt.
Es wird bereits jetzt klar, dass das Diagramm für die gesamte Struktur schnell unübersichtlich wird, wenn man von jedem Zustand (also jeder Maske) aus die Loginmaske und das Ende erreichen will. Im folgenden Beispiel sind die Transitionen ohne Trigger rot eingezeichnet, es ist bereits so schon recht unübersichtlich.
Ein Hilfsmittel, um dieser Unübersichtlichkeit Herr zu werden, sind Unterzustände. Alle Seiten, die angemeldete Nutzende sehen, teilen ein gemeinsames Verhalten (Abmelden/Schließen der Seite). Wir können sie also als Unterzustände des existierenden Zustands Angemeldet verstehen:
Es ist festgelegt, dass zunächst immer der Subzustand Übersicht erreicht wird, wenn man angemeldet ist – ein gangbarer Weg.
Schritt vier: Rollendetails einfügen
Das obige Diagramm modelliert einen Ablauf, bei dem alle Nutzenden dasselbe sehen und dürfen. In der Praxis ist dies aber häufig nicht der Fall: es gibt häufig Rollen wie Administratoren, Moderatoren, Benutzer, Gäste. Jede dieser Rollen sieht andere Details und darf in andere Masken navigieren.
Ein Weg wäre, für jede dieser Gruppen eigene Seiten zu generieren, zu denen jeweils nur navigiert werden kann, wenn die Guards zutreffen. Das führt aber zu einer Vielzahl von möglichen Kombinationen.
Ein anderer Weg ähnelt dem oben gewählten: Sofern die Rollen hierarchisch angeordnet sind, können die jeweiligen Seiten über Subzustände abgebildet werden. Jede Rolle verfügt über einen zusammengesetzten Zustand (composite state), in dem mindestens das zugehörige Dashboard liegt sowie die zusammengesetzten Zustände der spezialisierten Rollen. Die Seitenzustände aller Unterseiten der jeweiligen Rolle können ebenso Subzustände sein. Die Login-Transitionen führen jeweils in den zusammengesetzten Zustand der Rolle, dessen Startzustand (Initial State) auf das Dashboard dieser Rolle zeigt. So landet jede Rolle nach dem Login im eigenen Dashboard, ohne dass es dafür weiterer Guards bedarf.
Einige Details wurden gegenüber dem vorigen Diagramm der Übersichtlichkeit wegen ausgelassen (z. B. Abmelde-Transitionen). Man erkennt aber gut die Kaskaden der verschachtelten Rollen und die Login-Transitionen, die jede Rolle über ihren Startzustand zum eigenen Dashboard führen. Für Rücksprünge (etwa „Zurück“ aus einer Unterseite) genügt das allein nicht: Eine Transition, die am Rand eines zusammengesetzten Zustands endet, betritt ihn über dessen Startzustand – im Diagramm käme ein Admin nach onClick(Zurück) aus DetailAnzeigen also im BenutzerDashboard an. Eine (tiefe) Historie stellt beim Wiedereintritt den zuletzt aktiven Unterzustand wieder her, wirkt nach UML 2.5.1 aber nur, wenn eine Transition auf den History-Pseudozustand (H bzw. H*) selbst zeigt; der wiederhergestellte Zustand kann dann auch eine Unterseite statt des Dashboards sein. Wie zusammengesetzte Zustände und Historie genau funktionieren, zeigt der Artikel UML-Zustandsdiagramm.
Beispiel für die KongressApp
Für alle Schritte der GUI-Planung und Realisierung füge ich immer ein Beispiel für eine KonferenzApp an. Da die obige Modellierung mit dem Tool PlantUML bei großen Oberflächen an die Grenzen stößt, habe ich die Modellierung mit Enterprise Architect umgesetzt (es geht sicher auch mit diagrams.net). Die oben angeschnittenen Designentscheidungen wurden ebenso umgesetzt wie die Zusammenfassung der „Zurück“- bzw. „Abbrechen“-Transitionen der Unterseiten zum jeweiligen Dashboard - wieder über einen zusammengesetzten Zustand und Subzustände:
Fazit
Die Struktur der Seitenabfolge sowie die Navigation mit jeweiligen Triggern, Guards und Effekten sind damit festgelegt. Was noch fehlt, ist der Aufbau der einzelnen Seiten. Er wird im folgenden Artikel GUI-Seiten mit Wireframes und Mockups entwerfen zunächst mit Wireframes grob geplant.
Leitfragen
- Warum lassen sich die Masken einer Benutzeroberfläche als Zustände modellieren?
Jede Maske hat eigene Inhalte und ein eigenes Verhalten, und zwischen den Masken ist nur eine bestimmte Navigation möglich. Das entspricht Zuständen und Transitionen eines UML-Zustandsdiagramms. siehe Abschnitt „Abfolge der GUI-Masken als Zustände begreifen“
- Aus welchen Bestandteilen besteht die Beschriftung einer Transition?
Trigger [Guard] / Effekt: Der Trigger ist das auslösende Ereignis (z. B. onClick(Login)), der Guard die Bedingung, die erfüllt sein muss, und der Effekt das Verhalten beim Zustandswechsel (z. B. /saveUserLogin()). siehe Abschnitt „Schritt zwei: Transitionen eintragen“
- Wie modellierst Du, dass ein Klick je nach Bedingung zu unterschiedlichen Masken führt?
Der Trigger führt auf einen Auswahl-Pseudozustand (choice); von dort gehen Transitionen mit unterschiedlichen Guards ab, z. B. [Credentials == ok] zum angemeldeten Bereich und [else] zurück zur Loginmaske. siehe Abschnitt „Schritt zwei: Transitionen eintragen“
- Wie verhinderst Du, dass das Diagramm durch die Abmelde- und Schließen-Transitionen jeder einzelnen Seite unübersichtlich wird?
Alle Seiten mit gemeinsamem Verhalten werden Unterzustände eines zusammengesetzten Zustands (z. B. Angemeldet). Die gemeinsamen Transitionen gehen nur einmal vom Rand dieses Zustands ab, ein Startzustand darin legt die erste Seite fest. siehe Abschnitt „Schritt drei: Unterseiten ergänzen“
- Welche Wege gibt es, Rollen mit unterschiedlichen Rechten im Zustandsdiagramm abzubilden?
Entweder bekommt jede Rolle eigene Seiten, die nur über Guards erreichbar sind; das führt schnell zu vielen Kombinationen. Oder hierarchisch angeordnete Rollen werden als ineinander verschachtelte zusammengesetzte Zustände modelliert, sodass Login-Transitionen je Rolle direkt in den passenden Bereich führen. siehe Abschnitt „Schritt vier: Rollendetails einfügen“
Links und weitere Informationen
zum Nachlesen: UML-Zustandsdiagramm mit allen Notationselementen (zusammengesetzte Zustände, Historie, Choice)
zum Üben: Übungsaufgaben zum UML-Zustandsdiagramm
im Zusammenhang: GUI-Seiten mit Wireframes und Mockups entwerfen
als Nachschlagewerk: OMG Unified Modeling Language (UML) 2.5.1, Kapitel 14 „StateMachines“ und PlantUML-Dokumentation zu Zustandsdiagrammen
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Navigation in Benutzerschnittstellen mit UML-Zustandsdiagrammen planen” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/geschaeftsprozess-ui-states-entwerfen veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/software-entwurf/gui-entwurf. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 29.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
