Navigation in Benutzerschnittstellen mit UML-Zustandsdiagrammen planen
https://bildung.social/@oerinformatik/113350667437731167
https://oer-informatik.de/geschaeftsprozess-ui-states-entwerfen
tl/dr; (ca. 6 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 das UserInterface 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). (Zuletzt geändert am 22.10.2024)
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, sonder 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 Benutzer:
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, dass den Zustandsübergang auslöst, der Guard ist die Bedingung, die wahr sein muss, damit der Zustandsübergang ausgeführt wird und der Effekt ist das Verhalten, dass 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). Ausserdem gibt es Trigger, die 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, wie man dem Herr werden kann, sind Unterzustände. Alle Seiten, die angemeldete Benutzer 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 das gleiche 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 und sowie die zusammengesetzten Zustände der spezialisierten Rollen. Die Seitenzustände aller Unterseiten der jeweiligen Rolle können ebenso ein Subzustand sein. Die Transitionen reichen immer bis zum zusammengesetzten Zustand der jeweiligen Rolle, über Initial States und Deep History wird dafür gesorgt, dass jede Rolle nur das eigenen Dashboard sieht, ohne dass es weiterer Guards bedarf.
Einige Details wurden gegenüber dem vorigen Diagramm er Übersichtlichkeit wegen ausgelassen (z.B. Abmelde-Transitionen). Man erkennt aber gut die Kaskaden der verschachtelten Rollen und die Login-Transitionen für jede Rolle.Da zwischen den Dashboards selbst keine Transitionen vorhanden sind, ist sichergestellt, dass die tiefe Historie immer wieder das rollenzugehörige Dashboard angezeigt wird.
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 diagramms.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 ist damit festgelegt, was fehlt ist die Struktur der einzelnen Seiten. Diese werden im folgenden Artikel zunächst mit Wireframes grob geplant.
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/frontend. Stand: 22.10.2024.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
