Zurück zur Übersicht

UMLi

Christian Maugg

Motivation

UML hat sich heute als allgemeingültiger Standard zur abstrakten Modellierung und Darstellung von Software-Architekturen, programmgesteuerten Abläufen und Interaktivität und -operabilität zwischen Komponenten, Objekten und Instanzen durchgesetzt. Graphische Benutzerschnittstellen können mit der UML jedoch bis heute nicht modelliert werden. UMLi [1] versucht, Benutzerschnittstellen zu abstrahieren und anhand einer Metasprache (in seiner konkreten Ausprägung eine Erweiterung des UML-Sprachstandards) unter Zuhilfenahme spezieller Werkzeuge, sogenannter modellbasierter User Interface IDEs, zu beschreiben.

Konkrete Ausprägung der UMLi

Die Implementierung von Benutzerschnittstellen wird durch eine abstrakte Modellierung optimiert und standardisiert. Eine Erweiterung der UML beschreibt visuelle Elemente wie Fenster, Aktionsgeber (bspw. Buttons oder Hyperlinks) und -nehmer (bspw. Textfelder oder Radiobuttons). Der Designer erzeugt das Meta-Modell durch spezialisierte Entwicklungsumgebungen, allgemeinhin als MB-UIDE (modellbasierte User Interface Development Environment) bezeichnet. Beispielhaft für eine solche Gattung von IDEs sei Teallach [2] genannt. Teallach kann zur modell-gestützten Generierung von Source Code für Benutzerschnittstellen genutzt werden; es wird unterschieden zwischen Task, Domain und Presentation Models zur Generierung des Codes. Task Models dienen der Modellierung von Verhaltensweisen der betrachteten Komponenten und entsprechen in der UMLi Aktivitätsdiagrammen. Domain Models dienen der Modellierung von Eigenschaften eines Systems oder Komponenten und entsprechen in der UMLi den Klassendiagrammen. Presentation Models beschreiben Komponenten, die für die visuelle Repräsentation der Benutzerschnittstelle verantwortlich sind, beschreiben also die Eigenschaften von Widgets. Teallach konzentriert sich als Tool zur ausschließlichen Entwicklung von Benutzerschnittstellen nicht auf Design und Verknüpfung von Anwendungen und ihrer visuellen Repräsentation, sondern dient lediglich der Schnittstellen-Entwicklung. Das von den Entwicklern der UMLi empfohlene Entwicklungswerkzeug, welches sowohl zum Anwendungsdesign als auch zur Planung graphischer Schnittstellen herangezogen werden kann, heißt ARGOi [3] und basiert auf dem bekannten Open-Source-UML-Tool ARGO-Uml [4].

Wie oben beschrieben, führt UMLi neue Entitäten in die herkömmliche UML ein. Die UML wird um den neuen Diagramm-Typ user interface diagram und um eine Menge von Aktivitätsdiagramm-Konstruktoren erweitert. Das user interface diagram ermöglicht die abstrahierte Darstellung von visuellen Elementen inklusive ihrer Rollen und Aufgaben, die Aktivitätsdiagramm-Konstruktoren erweitern die UML um die implizite Deklaration von neuen Zuständen.

Modellierung der Repräsentationen graphischer Elemente

Jedes user interface besteht aus einem Free Container, der das für den Nutzer sichtbare Fenster repräsentieren soll. Free Container können andere Container, Editors, Displayers, Inputters und ActionInvokers beinhalten. Container haben den Zweck, andere Komponenten zu unterteilen und logisch zu gliedern. Solche Komponenten werden in der UMLi als InteractionClasses bezeichnet.

PrimitiveInteractionClasses, eine Untermenge der InteractionClasses, definieren Objekte, die Events vom Benutzer empfangen und weitergeben können; zu dieser Gruppe gehören Inputters, Displayers und Editors. Displayers senden visuelle Informationen zum User; in einer konkreten Implementierung ist ein nicht editierbares Textfeld oder ein aufpoppende Fehlermeldung ein Displayer. Ein Inputter ist das Gegenstück zu einem Displayer; er empfängt Informationen vom Nutzer. Ein Eingabefeld oder ein Radio Button (der lediglich zur Auswahl dient, aber noch keine Aktion startet) ist ein Inputter. Editors sind gleichzeitig Inputter und Displayer. Ein editierbares Textfeld wäre bspw. ein Editor. ActionInvokers sind Elemente, die Informationen vom Nutzer als Event empfangen - ein Event ist in diesem Zusammenhang bspw. ein Klick auf einen Button. Container bündeln mehrere Entitäten in sich; der Typ der gebündelten Entitäten ist beinahe beliebig - lediglich ein Free Container ist nicht erlaubt, da dieser das "Top-Level-Window" repräsentiert.

Grundsätzlich sagt ein user interface diagram nichts aus über die graphische Anordnung, Aussehen und Implementierung von Widgets, sondern dient der konzeptuellen Modellierung einer Benutzerschnittstelle.

Modellierung von Verhalten graphischer Elemente

Wie oben beschrieben, werden Aktivitätsdiagramme um Konstruktoren erweitert, um bestimmte Zustände und Zusammenhänge von Widgets zu modellieren. Ein neuer Pseudo-Zustand selection state kann benutzt werden, um Zustände zu definieren, in denen sich ein Widget nach Aktivierung befinden kann. interaction object flows werden benutzt, um Zusammenhänge und Abhängigkeiten entweder zwischen einzelnen interaction objects (also Objekten aus der Presentation) oder nicht-visuellen Objekten (also Objekten aus der Domain) zu beschreiben.

UMLi spezifiziert drei Arten von selection states. Der OrderIndependentState impliziert die Ausführung wenigstens zwei oder mehrerer Aktionen bei Aktivierung eines Widgets, allerdings in nicht festgelegter Reihenfolge. Jede assoziierte Aktion muss ausgeführt werden. Einem OrderIndependentState müssen wenigstens zwei selektierbare Aktivitäten zugewiesen sein. Der OptionalState erlaubt die Ausführung einer Untermenge von assoziierten Aktionen. Anzahl und Wiederholung der Ausführung von Aktionen sind hierbei nicht festgelegt; das impliziert auch 0 Wiederholungen, also gar keine Ausführung einer Aktion. Ein OptionalState muss wenigstens zwei assoziierte Aktionen haben. Ein RepeatableState modelliert die dauerhafte Wiederholung genau einer Aktion. Im Gegensatz zu den anderen definierten Zuständen darf mit diesem Zustand nur genau eine Aktion assoziiert sein.

Ein object flow besteht aus einem ClassifierInState (eine Repräsentation des auslösenden Objekts) und einem ObjectFlowState (einem Pfeil, der das auslösende Objekt mit einer Aktivität, einem ActionState oder einem selection state verbindet). Ein ClassifierInState kann vom Typ einer im Modell spezifizierten Klasse sein. Es existieren mehrere Kategorien von ObjectFlowStates. Ein <<presents>>-Pfeil verbindet meist einen Free Container mit einem ActionState und bildet die Aktion "Öffnen" (Herstellen einer visuellen Repräsentation) oder "Schließen" (Entfernen einer visuellen Repräsentation) nach. Ein <<interacts>>-Pfeil verbindet eine PrimitiveInteractionClass oder einen ActionInvoker mit einem ActionState und bildet Aktivierung und Deaktivierung einer Komponente nach. Ein <<cancels>>-Pfeil verbindet einen ActionInvoker mit einer Aktivität oder einem selection state und bildet einen Abbruch eines Vorgangs nach. Ein <<confirms>>-Pfeil verbindet ActionInvoker und OptionalState und beendet die Ausführung assoziierter Aktionen. Ein <<activates>>-Pfeil verbindet einen ActionInvoker mit einer Aktivität oder einem ActionState und stößt die Ausführung der assoziierten Aktivität bzw. der Aktivität selbst an.

Fallstudie: UML-basiertes UI-Design [5]

In der Fallstudie wurde der Versuch unternommen, anhand der Unified Modelling Language eine Benutzerschnittstelle für ein Bibliothekssystem zu beschreiben. Der Autor stand der UML ausreichende Flexibität für diese Aufgabe zu. Er kritisierte jedoch das Fehlen einer Notation für eine abstrakte Repräsentation einer graphischen Komponente sowie zum einen das Fehlen einer logischen Verbindung zwischen einer abstrakten Repräsentation einer graphischen Komponente und einer Aktivität und zum anderen das Fehlen einer logischen Verbindung zwischen Use Cases und Aktivitäten. Eine persönliche Erfahrung des Autors bestand in der Erkenntnis, dass UI Design und Anwendungsdesign implizit zusammenhängen und UI Design deswegen integraler Bestandteil jedes Software-Entwicklungsprozesses sein sollte.

Literatur und Referenzen

[1] The Unified Modelling Language for Interactive Applications

[2] Teallach

[3] ArgoUML

[4] ARGOi

[5] Paulo Pinheiro da Silva and Norman W. Paton: User Interface Modelling with UML