Previous: 3. Konzepte Up: 3. Konzepte Next: 3.2 Validierung des GUI-Modells
Interessant wird es nun, wenn zusätzlich zum Verhalten der GUI deren Aussehen modelliert werden soll. Der GUI soll es dabei möglich sein, in jedem Zustand ein anderes Aussehen anzunehmen. Die Grundidee, welche aus dem OMMMA-Ansatz entliehen wurde, besteht also darin, jedem Zustand ein Layout-Diagramm (kurz: Layout) zuzuordnen, welches das Aussehen der GUI in diesem Zustand beschreibt (siehe Abb. 3.1).
Das Modell der GUI besteht also aus einer Kombination zweier Diagrammarten. Statecharts modellieren das Verhalten der GUI, und Layouts beschreiben deren Aussehen.
Ein Layout besteht dabei aus sogenannten GUI-Elementen (vgl. Abb. 3.2). Ein GUI-Element ist ein in der Regel graphisches Element, welches ein Bestandteil des Aussehens bzw. der Ansicht der GUI ist. Es gibt viele verschiedene Arten von GUI-Elementen. Es existieren einfache geometrische Formen (Shapes), Bedienelemente (Widgets) oder Grafikelemente, die Bilder anzeigen. Neben diesen graphischen GUI-Elementen gibt es auch nicht-graphische Elemente, wie zum Beispiel das Sound-Element, das Musik oder Effekte wiedergeben kann.
Ein GUI-Element setzt sich dabei aus einer Menge von Eigenschaften (Properties) zusammen, denen sich Werte zuweisen lassen (siehe Abb. 3.3). Jedes GUI-Element wird durch die Wertzuweisungen seiner Eigenschaften in seinem Aussehen bestimmt. Je nachdem welche Art von GUI-Element vorliegt, unterscheiden sich die vorhandenen Eigenschaften. Form-Elemente (Shapes) besitzen zum Beispiel eine Füllfarbe, wogegen Grafik-Elemente den Verweis auf eine Grafikdatei als eine Eigenschaft aufweisen. Es gibt aber natürlich auch gemeinsame Eigenschaften wie zum Beispiel die Position und Größe.
Die unterschiedlichen Typen der GUI-Elemente spiegeln sich also in den vorhanden Eigenschaften wider, so dass eine hierarchische Organisation der GUI-Elemente auch in Bezug auf ihre Eigenschaften Sinn macht. GUI-Elemente können aufgrund ihres Typs und ihrer Eigenschaften in Klassen und Unterklassen organisiert werden, wobei gemeinsame Eigenschaften in der entsprechend gemeinsamen Oberklasse definiert werden. Eigenschaften, die zum Beispiel alle Form-Elemente besitzen, werden bereits in der Klasse der Shapes definiert. Diese Klasse wird dann von den einzelnen Formen spezialisiert, indem die gemeinsamen Eigenschaften durch weitere Eigenschaften erweitert werden, welche die jeweiligen Spezialisierungen des Elements betreffen.
Ein Layout besteht also aus GUI-Elementen, die verschiedene Eigenschaften (Properties) besitzen, welche für jede Art von GUI-Element das Aussehen festlegen. Im einfachsten Fall, in dem sich die GUI lediglich in einem einfachen Zustand (State) befindet, der keinerlei Vaterzustände besitzt, entspricht dies auch der Wahrheit. In diesem Fall besteht die Ansicht der GUI nämlich nur aus dem Layout, das mit dem einfachen Zustand verknüpft ist.
Unser Modell zur Verknüpfung von Statecharts mit Layouts belässt es jedoch nicht bei diesem einfachen Ansatz, sondern erweitert diesen auf komplexe Zustände. Komplexe Zustände werden in der UML dazu verwendet, um das Verhalten eines Zustands durch Kindzustände weiter zu verfeinern. Diese Möglichkeit der Strukturierung von Verhalten im Statechart-Modell macht sich unser Konzept zunutze.
In dem von uns konzepierten Modell erlauben wir es daher auch, dass Layouts komplexen Zuständen zugeordnet werden können. Befindet sich die GUI also in einem komplexen Zustand mit entsprechenden Kindzuständen, so geht nicht nur das Layout des eingenommenen einfachen Zustands in die GUI-Ansicht ein, sondern auch die Layouts der ebenfalls eingenommenen komplexen Vaterzustände. Die GUI-Ansicht ist also unter Umständen eine Komposition aus mehreren Layouts. Dies gilt ebenfalls bei möglicherweise parallel aktiven Zuständen.
Die hierarchische Struktur der Zustände im Statechart wird also auf die Layout-Ebene übertragen (vgl. Abb. 3.4). Verfeinert man das Verhalten eines Zustands durch Unterzustände, so verfeinert man ebenfalls das mit diesem Zustand verbundene Layout durch die Layouts der Unterzustände. Die Komposition mehrerer Layouts zu einer resultierenden GUI-Ansicht geschieht dabei folgendermaßen:
Zuerst einmal werden Layouts übereinandergestapelt. Die Reihenfolge, in der sich die Layouts dabei überdecken, ist durch die Hierarchie der zugehörigen Zustände festgelegt. Layouts von Kindzuständen überdecken dabei jeweils die Layouts ihrer Vaterzustände. Dass sich zwei Layouts überdecken, bedeutet, dass alle GUI-Elemente des überdeckenden Layouts die des unteren Layouts überdecken. Eine Überdeckungsreihenfolge zwischen parallel aktiven Zuständen ist nicht definiert.
Damit ist die Komposition allerdings noch nicht abgeschlossen. Vorhin haben wir gesagt, dass Layouts aus GUI-Elementen bestehen. Diese Definition ist noch unvollständig. Layouts bestehen in unserem Modell zudem noch aus sogenannten Property-Changes. Property-Changes sind Veränderungen (auch als Modifikationen bezeichnet) an GUI-Elementen, die aus Layouts von Vaterzuständen stammen. Das bedeutet, dass alle GUI-Elemente, die in Layouts von übergeordneten Zuständen definiert bzw. erzeugt wurden, sich modifizieren lassen, indem die Werte ihrer Eigenschaften (Properties) abgeändert werden (vgl. Abb. 3.5). Aus Sicht des Layouts, welches die Modifikationen vornimmt, bezeichnet man solche GUI-Elemente als geerbte GUI-Elemente. Ein Property-Change kapselt die Wertänderung einer Eigenschaft eines geerbten GUI-Elements und stellt damit eine solche Modifikation dar. Die Wertänderung erfolgt in dieser Version des Modells noch ausschließlich in absoluter Weise. Relative Wertänderungen sind von uns für zukünftige Versionen aber eingeplant.
Durch diese Erweiterung des Layout-Begriffs lässt sich eine neue Sicht auf das bereits Gesagte gewinnen. Man kann ein Layout nämlich als bloße Liste von Änderungen auffassen, wobei die Erzeugung eines GUI-Elements eine spezielle Änderung ist. Diese Liste von Modifikationen wird nun zur Komposition der GUI-Ansicht verwendet, indem für jedes Layout die Liste an Änderungen abgearbeitet wird. Die zuvor definierte Reihenfolge der Layouts legt dabei die Reihenfolge fest, in der die Änderungslisten angewendet werden. Als Ergebnis dieses Prozesses erhält man die finale Komposition der GUI-Ansicht (siehe Abb. 3.6).
Denkt man an den Ablauf, der sich dadurch ergibt, so werden beim Verlassen eines Zustands die von seinem Layout an der GUI-Ansicht vorgenommenen Änderungen unwirksam und durch die Änderungen des Layouts des neu eingenommenen Zustands ersetzt, wobei Änderungen von eventuell weiterhin aktiven Vaterzuständen beibehalten werden.
Durch die Konzeptionierung der Komposition der GUI-Ansicht ergeben sich viele Vorteile, die sich in der Möglichkeit der strukturierten Modellierung einer GUI niederschlagen. GUIs setzen sich häufig aus einer überschaubaren Anzahl von wirklich grundlegend verschiedenen Ansichten zusammen, die dann eine deutlich höhere Anzahl von kleineren Änderungen erfahren, um verschiedene Zustände der GUI innerhalb einer grundlegenden Ansicht zu vermitteln. Diese Strukturierung kann natürlich für die jweiligen Unteransichten beliebig weiter fortgesetzt werden.
Ohne das von uns angebotene Konzept der hierarchischen Komposition von Layouts mit der Möglichkeit, Änderungen an geerbten GUI-Elementen vornehmen zu können, müsste man für jede noch so kleine Änderung an der GUI-Ansicht diese komplett neu modellieren und damit von einem großen Teil der Ansicht eine Kopie anlegen. Abgesehen von dem nicht unerheblichen Aufwand bei der Modellierung würde eine solche Konzeptionierung zu Modellen führen, die weder leicht erweiterbar noch modifizierbar wären, da sie zu großen Teilen aus redundanten Informationen bestünden. Ein erfolgreicher Einsatz wäre damit praktisch ausgeschlossen.
Durch das von uns präsentierte Konzept hingegen lassen sich kleine Änderungen an einer GUI-Ansicht als das modellieren, was Sie sind: Modifizierungen bereits existierender GUI-Elemente. Es müssen auch keine Kopien von GUI-Elementen erstellt werden, wenn die Struktur der zu modellierenden GUI korrekt auf die Struktur des Statecharts abgebildet wurde. Layouts, die also kleine Änderungen an einer Ansicht vornehmen und damit Spezialisierungen dieser Ansicht sind, müssen entsprechend auch Verfeinerungen des entsprechenden Zustands der GUI-Ansicht sein und können deshalb auf die von ihm geerbten GUI-Elemente Einfluss nehmen.
Das Anlegen von mehreren Kopien eines GUI-Elements bleibt also aus. Dieses Vorgehen beseitigt nicht nur die bereits erwähnten Nachteile, sondern bringt zudem noch viele Vorteile. Ein GUI-Element, das einmal im Layout eines Vaterzustands definiert ist, und dann in Layouts von unterschiedlichen Kindzuständen in einer bestimmten Eigenschaft modifiziert wird, kann nachträglich in anderen Eigenschaften in seinem Layout verändert werden, so dass sich diese Veränderungen auf alle davon erbenden Layouts auswirken. So können nachträgliche Änderungen am Originalelement zentral an einer Stelle vorgenommen werden, und haben automatisch die gewünschten Auswirkungen auf alle erbenden Layouts.
Ein weiterer Vorteil des Modifzierungskonzepts ergibt sich bei dem bisher noch unerwähnten Aspekt der Interaktion (Manipulation) von GUI-Elementen. Der Benutzer soll schließlich mit GUI-Elementen interagieren können, indem er beispielsweise durch Mausinteraktionen Zustandsübergänge im Statechart und damit Änderungen der GUI-Ansicht auslöst. GUI-Elemente könen dabei je nach ihrem Typ unterschiedliche Interaktionsmöglichkeiten anbieten, die letztendlich in der Auslösung eines Signals enden, das als Ereignis im Statechart Zustandsübergänge bewirken kann. Mehr zu diesem Thema erfahren Sie in Abschnitt 3.3.
Ein Signal, das mit einer der Interaktionsmöglichkeiten des GUI-Elements gekoppelt ist, ist ebenfalls lediglich ein Property des GUI-Elements. Somit gelten alle genannten Eigenschaften von Properties auch für die Signale, die ein GUI-Element auslösen kann. Das bedeutet insbesondere, dass sich die Signale geerbter GUI-Elemente modifizieren lassen. Auf diese Weise ist es nicht nur möglich, das Aussehen, sondern auch die Funktion eines GUI-Elements zu verändern, indem man für eine spezifische Interaktionsmöglichkeit ein anderes Signal als Wert angibt.
D. Hannwacker - A. Gebel - M. Dürksen 
