Modellierung adaptiver Oberflächen

Blended Interactive Spaces unterstützen Nutzer durch technische Möglichkeiten bei kollaborativen Arbeitsprozessen. Dabei steht die Nutzerinteraktion als zentrales Element der Anwendung im Vordergrund. Die Oberflächen müssen sich selbstständig zur Laufzeit an wechselnde Anforderungen anpassen. Dies bedeutet, dass sich die Struktur der Oberflächen, die Eigenschaften der Oberflächeneinheiten und deren Verhalten kontextabhängig verändert werden muss. Leider existiert heute noch kein einheitliches Oberflächenmodell, das die Elemente der konkreten Plattform (z.B. Java Swing, Android UI, iOS etc.) abstrahiert. Aus diesem Grund ist es heute nur schwer möglich, diese Konzepte plattformübergreifend zu spezifizieren.

Im Rahmen von SysPlace wurde das SMAGs Komponentenmodell dahingehend erweitert, dass es auch zur Definition von Oberflächenkomponentensystemen geeignet ist. Dafür wurde zunächst das Metamodell dahingehend erweitert dass der neue Komponententyp Oberflächenkomponententyp (ui component type) eingeführt wurde. Darüber hinaus wurde eine abstrakte plattformunabhängige Meta-Architektur aus den konkreten Oberflächentechnologien Microsoft XAML, Android, Java SWT und HTML extrahiert.

• Die Typbibliothek umfasst alle komplexen Datentypen und Enumerationen, die zur Modellierung von Oberflächenkomponenten notwendig sind. Dies umfasst Farben, Schriften, Abstände, und Ereignisdatentypen.
• Die Porttypen definieren die abstrakte Hierarchie der Oberflächenkomponenten über eine Vererbungsbeziehung. Generell wird zwischen kompositen (IPanel), dekorierenden (IUIContentControl) und atomaren Komponenten unterschieden. Komposite Komponenten können zur Laufzeit wiederum mehrere Unterkomponenten besitzen, die über die benötigte Schnittstelle vom Typ IUIControl verbunden werden. Auf diese Weise entsteht ein hierarchisches Oberflächenkomponentenmodell. Dekorierende Oberflächenkomponenten haben eine Referenz auf eine Subkomponente, die in ihrem Aussehen oder ihrem Verhalten erweitert/verändert wird. Neben diesen strukturellen Schnittstellen werden auch verhaltensbezogene (z.B. ITextControl) und ereignisbasierte Schnittstellen (z.B. IClickable) deklariert. Darüber hinaus werden die Schnittstellen für generische Standardoberflächenkomponenten (z.B. IButton) definiert.
• Die Komponenten werden über das Schlüsselwort ui component type explizit als Oberflächenkomponententypen deklariert. SMAGs Oberflächenmodelle werden komponentenbasiert modelliert, wobei jede Komponente die Schnittstelle IUIComponent anbietet. In der Meta-Architektur werden lediglich die plattformunabhängigen Komponententypen definiert, die dann auf einer konkreten Plattform implementiert werden müssen. In der Meta-Architektur werden ausschließlich die Oberflächenkomponenten definiert, die in allen untersuchten Plattformsystemen vorkommen. Für andere Interaktionsformen (z.B. Kommandozeile) würden nur wenige tatsächlich implementiert werden. Welche von diesen dann tatsächlich auf einer Plattform zur Verfügung stehen und wie diese auf die Plattformoberflächenkomponenten abgebildet werden, wird im Folgenden erläutert.

Diese Meta-Architekturen müssen dann auf einer Plattform implementiert werden. Allerdings hat sich gezeigt, dass die einzelnen Systeme für die Implementierung von visuellen Schnittstellen (z.B. Android) noch eigene Voraussetzungen an die Instanziierung und Verwaltung der Benutzerschnittstellenelemente haben. So muss in Android immer ein Bezug zur gerade ausgeführten Aktivität hergestellt werden und zur Einbindung in die Oberfläche ist die komplexe Sicht (View) notwendig. Aus diesem Grund wurde für die Umsetzung unter Android die oben beschriebene generische Meta-Architektur durch eine Android-spezifische Meta-Architektur erweitert. Diese ist dann nicht mehr vollkommen plattformunabhängig und schränkt die Instanziierung auf Oberflächen ein, die ähnlich zu Android aufgebaut sind. Dennoch beziehen sich alle verwendeten Oberflächenkomponenten immer noch auf die Elemente der generischen Meta-Architektur. Trotz dieser Spezialisierung ist es möglich, Oberflächenteile auf andere Endgeräte zu transferieren. In diesem Auszug wurde lediglich auf einige Oberflächenkomponenten eingegangen, da sich die Spezifikation für alle weiteren gleicht. Darüber hinaus wurden zahlreiche weitere Typen, Schnittstellen und Komponententypen zur Interaktion mit der Gerätesensorik (z.B. Beschleunigungssensor, Bluetooth etc.) definiert, die aus Platzgründen nicht mit aufgelistet wurden.

Anschließend muss noch eine plattformspezifische Implementierung der Meta-Architektur für Oberflächenmodelle erfolgen. Dies geschieht mit Hilfe eines Anwendungsmodels. Im Folgenden wird der Auszug aus dem Android Anwendungsmodell dargestellt. Dieses definiert vier SMAGs Komponenten für die Umsetzung komponentenbasierter Oberflächen auf der Android Plattform. Wie zu sehen ist, existiert kein Initialisierungsskript. Da es sich bei diesem Anwendungsmodell nicht um eine spezifische Applikation, sondern um die plattformspezifische Implementierung des generischen Oberflächenmodells handelt, kann die Initialisierung der Komponenten an dieser Stelle noch nicht angegeben werden. Erst, wenn eine konkrete Applikation entwickelt wird, die dieses Oberflächenmodell verwendet, können Komponenten instanziiert werden. Das Beispielt zeigt dies an einem Beispiel, bei dem ein Stackpanel als Wurzelelement der Oberfläche deklariert wird, dem zwei Kindelemente (ein Button und eine Textbox) zugeordnet werden.

Da es sich bei diesen Oberflächenkomponente um ganz normale SMAGs-Komponenten handelt, können diese rollenbasiert (über Ports) adaptiert werden. Dabei stehen alle drei Adaptionsmechanismen zur Verfügung (siehe Abschnitt 1.1):

• Mittels parametrisierter Adaptation können kontextabhängig die Parameter der Oberflächenkomponenten verändert werden (z.B. Erhöhen der Schriftgröße, wenn der Nutzer sich von dem Display entfernt).

• Mittels kontrollflussgesteuerter Adaption kann die Funktionalität einer Oberflächenkomponente kontextabhängig angesteuert werden (z.B. Setzen des Fokus auf ein Textfeld, wenn der Nutzer nah an das Textfeld herantritt).

• Mit der kompositionellen Adaption können Oberflächen in ihrem Verhalten und ihrer Struktur verändert werden. Über das Hinzufügen/Löschen und Verbinden von Komponenten kann die Struktur der Darstellung verändert werden (z.B. detaillierte Informationen anzeigen, wenn der Nutzer vor einen großen Bildschirm tritt). Mit der Bindung von Ports kann das Verhalten der Oberfläche verändert werden (z.B. Aktion die ausgelöst wird, wenn auf einen Button geklickt/gedrückt wird). Auch können Ports verwendet werden um die Ereignisse von Oberflächenkomponenten miteinander zu verbinden (z.B. Aktualisieren eines Labels, wenn der Text in einer Textbox geändert wird). Wie in Abschnitt 1 näher erläutert wird, kann die Verbindung von Ports auch über Geräte- und Plattformgrenzen hinweg erfolgen. Auf diese Weise lassen sich kollaborative Oberflächen modellieren (z.B. Aktualisierung eines Labels auf Gerät A, wenn auf Gerät B ein Textfeld editiert wird).

Da sich die konkreten Komponenten, die plattformspezifisch implementiert wurden, immer auf eine plattformunabhängige Oberflächenkomponente beziehen, ist auch die Migration von Teilen der Oberfläche durchführbar. Dazu wird ein Teil der Oberflächenhierarchie von einer Anwendung in eine andere Anwendung überführt, in dem sie mit Hilfe der Meta-Architektur transformiert wird. Dazu müssen alle vorhandenen Oberflächenkomponententypen eine Implementierung auf der jeweiligen Zielplattform haben. In diesem Fall ist eine automatische Überführung problemlos möglich. Abbildung 6 veranschaulicht dies an einem Beispiel.