Modellbasierte Generierung von Benutzungsoberflächen
Modellbasierte Generierung von Benutzungsoberflächen
Modellbasierte Generierung von Benutzungsoberflächen
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Modellbasierte</strong> <strong>Generierung</strong> <strong>von</strong> <strong>Benutzungsoberflächen</strong><br />
vorgelegt <strong>von</strong><br />
Dissertation<br />
zur<br />
Erlangung des akademischen Grades<br />
Doktor-Ingenieur (Dr.-Ing.)<br />
der Fakultät für Informatik und Elektrotechnik<br />
der Universität Rostock<br />
Andreas Wolff, geboren am 27. Oktober 1978 in Berlin-Köpenick<br />
aus Rostock<br />
Rostock, 1. Dezember 2010
Inhaltsverzeichnis<br />
Abstract vii<br />
1 Einleitung 1<br />
1.1 Einordnung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.1.1 Einführung in die Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 2<br />
1.1.2 Forschungsfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4<br />
1.1.3 Ergebnisüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
1.2 Einführung in Modelle und <strong>Benutzungsoberflächen</strong> . . . . . . . . . . . . . . . . . . . . . 6<br />
1.2.1 Modellierung in der Softwaretechnik . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
1.2.2 Modelle für die Nutzerinteraktion . . . . . . . . . . . . . . . . . . . . . . . . . . 8<br />
1.2.3 Historische Entwicklung <strong>von</strong> UI Modellierung . . . . . . . . . . . . . . . . . . . 8<br />
1.3 Interaktionsdefinition mit XML-Derivaten . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
1.3.1 XML-basierte UI-Beschreibungssprachen . . . . . . . . . . . . . . . . . . . . . . 14<br />
1.3.2 Schlußfolgerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
2 Modellgetriebene <strong>Generierung</strong> <strong>von</strong> <strong>Benutzungsoberflächen</strong> 23<br />
2.1 Beschreibung des Rostocker Prozessmodells . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
2.1.1 Quellmodelle des modellgetriebenen Ansatzes . . . . . . . . . . . . . . . . . . . 26<br />
2.1.2 Dialogmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
2.1.3 Abstrakte Oberfläche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
2.1.4 Modelle für konkrete Oberflächen . . . . . . . . . . . . . . . . . . . . . . . . . . 42<br />
2.2 Transformationstechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48<br />
2.2.1 Model-To-Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49<br />
2.2.2 Model-To-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
3 Patterns und Komponenten 53<br />
3.1 Pattern-Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
3.2 Pattern Language Meta Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
iii
3.2.1 Sprachstandard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
3.2.2 Erweiterungsvorschläge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58<br />
3.3 Textuelle domänenspezifische Sprache für PLML . . . . . . . . . . . . . . . . . . . . . . 59<br />
3.4 Grafische Darstellung <strong>von</strong> Pattern-Katalogen . . . . . . . . . . . . . . . . . . . . . . . . 63<br />
3.5 Pattern als Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67<br />
3.5.1 Klassifikation der Komponentisierbarkeit <strong>von</strong> Patterns . . . . . . . . . . . . . . . 67<br />
3.5.2 Aufbau eines Katalogs <strong>von</strong> Patternkomponenten . . . . . . . . . . . . . . . . . . 71<br />
3.5.3 Deklarationsmodell für Patternkomponenten . . . . . . . . . . . . . . . . . . . . 77<br />
3.5.4 Einordnungen <strong>von</strong> Einzelpatterns . . . . . . . . . . . . . . . . . . . . . . . . . . 81<br />
4 Reengineering Interaktiver Systeme 87<br />
4.1 Reverse Engineering und modellgetriebene Softwareentwicklung . . . . . . . . . . . . . . 88<br />
4.1.1 Reverse Engineering <strong>von</strong> Objektmodellen . . . . . . . . . . . . . . . . . . . . . . 89<br />
4.1.2 Kriterien für die Ableitung <strong>von</strong> MOF-Modellen aus Java-Quellcode . . . . . . . . 91<br />
4.1.3 Durchführung der Java⇒Ecore Transformation . . . . . . . . . . . . . . . . . . . 95<br />
4.1.4 Reduzierung der Modelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98<br />
4.2 Reverse Engineering des Oberflächenmodells . . . . . . . . . . . . . . . . . . . . . . . . 100<br />
4.2.1 Erzeugen eines Swing-Modells aus einer existierenden Oberfläche . . . . . . . . . 100<br />
4.2.2 Modellinstanzen für XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104<br />
4.2.3 Ableitung des abstrakten Oberflächenmodells . . . . . . . . . . . . . . . . . . . . 110<br />
4.3 Forward Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110<br />
4.4 Herausforderungen und Grenzen des vorgestellten Reengineering-Ansatz . . . . . . . . . 111<br />
5 Zusammenfassung 113<br />
5.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113<br />
5.2 Vorschläge für weiterführende Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 116<br />
5.2.1 Multimodale Nutzerschnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . 116<br />
5.2.2 Vorschläge für weiterführende Forschungsansätze . . . . . . . . . . . . . . . . . . 116<br />
A System- und Sprachbeschreibungen 119<br />
A.1 Allzweckmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119<br />
A.1.1 UIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119<br />
A.1.2 DON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120<br />
A.1.3 HUMANOID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122<br />
A.2 Modellierung für Spezialbereiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124<br />
A.2.1 DRIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124<br />
A.2.2 TEALLACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125<br />
iv
A.3 Systeme mit Aufgabenmodellierungshintergrund . . . . . . . . . . . . . . . . . . . . . . 127<br />
A.3.1 ADEPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127<br />
A.3.2 MASTERMIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128<br />
A.3.3 FUSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129<br />
A.3.4 TADEUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130<br />
A.3.5 TRIDENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131<br />
A.3.6 L-CID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132<br />
A.3.7 MECANO, MOBI-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132<br />
A.4 XML Derivate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133<br />
A.4.1 TERESA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133<br />
A.4.2 UIML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135<br />
A.5 Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136<br />
A.5.1 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136<br />
A.5.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137<br />
A.5.3 Einbettung CSS, Javascript und XUL . . . . . . . . . . . . . . . . . . . . . . . . 137<br />
B Quelltexte 139<br />
B.1 PLML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139<br />
B.1.1 Grammatik für die Sprachversion 1.1 . . . . . . . . . . . . . . . . . . . . . . . . 139<br />
B.1.2 Grammatik der Sprachversion 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . 141<br />
B.1.3 xText-Grammatik für PLML 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 143<br />
B.1.4 Beispielkatalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145<br />
B.2 XUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147<br />
C Technische Beschreibungen / Implementierungsdetails 149<br />
C.1 Korrektur des Ergebnis des XUL-XSLT-EMF Importers . . . . . . . . . . . . . . . . . . . 149<br />
C.2 Erläuterungen zum XUL-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150<br />
C.3 Pattern Language Meta Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151<br />
C.3.1 Erläuterte Änderungen gegenüber PLML 1.1 . . . . . . . . . . . . . . . . . . . . 151<br />
C.3.2 Erläuterungen zur xText-Grammatik . . . . . . . . . . . . . . . . . . . . . . . . . 153<br />
C.3.3 PLML Metamodell für den grafischen PLML-Editor . . . . . . . . . . . . . . . . 155<br />
C.4 Technischer Ablauf der Swing-Abbildung auf Ecore . . . . . . . . . . . . . . . . . . . . . 155<br />
D Patternkomponenten 159<br />
D.1 Tabellarische Einordnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159<br />
Abkürzungsverzeichnis 171<br />
v
Tabellenverzeichnis 173<br />
Abbildungsverzeichnis 176<br />
Listings 177<br />
Algorithmenverzeichnis 179<br />
Literaturverzeichnis 190<br />
Artefakte zum Promotionsantragsverfahren 191<br />
vi
Abstract<br />
Diese Dissertation ist eine Arbeit im Bereich der modellbasierten Erstellung <strong>von</strong> <strong>Benutzungsoberflächen</strong>.<br />
Durch die Erarbeitung <strong>von</strong> geeigneten Metamodellen und Transformationen dieser Modelle werden die<br />
Schnittstellen der Mensch-Maschine-Kommunikation spezifiziert. Die erstellten Spezifikationen werden<br />
benutzt, um verwendungsfähigen Quellcode zu generieren. Zum Einsatz gelangen Basistechniken des<br />
MDA-Paradigmas: Model-to-Model- und Model-to-Text-Transformationen. Besonderen Fokus legt die Arbeit<br />
auf die Integration <strong>von</strong> Best-Practices in die User Interface (UI) <strong>Generierung</strong>. HCI-Pattern werden auf<br />
Formalisierbarkeit untersucht und sofern möglich, als anwendbare Komponenten in den UI-Erzeugungsprozess<br />
eingebracht. Als dritter wichtiger Aspekt wird eine Möglichkeit zur Durchführung <strong>von</strong> Reengineering untersucht.<br />
Existierende Softwaresysteme können analysiert und mit Instanzen der zuvor erarbeiteten Metamodelle<br />
beschrieben werden. Auf diese Art kann das MDA-Paradigma auch auf bestehende Alt-Software<br />
angewendet werden. Die Pattern-Verwendung und das Reverse Engineering werden an Beispielen demonstriert.<br />
vii
viii
Kapitel 1<br />
Einleitung<br />
1.1 Einordnung der Arbeit<br />
Kaum ein Forschungsthema steht für sich allein und kann vollständig und erschöpfend in einer einzelnen<br />
Publikation dargestellt und bearbeitet werden. Auch diese Dissertationsschrift führt die Ideen anderer<br />
Forscher weiter, greift bekannte Konzepte auf und verwendet bereitgestellte Frameworks und Werkzeuge.<br />
Die detaillierten Zusammenhänge zu anderen Arbeiten werden in den folgenden Kapiteln hergestellt<br />
und erläutert. Im Rahmen dieser Einführung soll zunächst nur eine allgemeine Einordnung vorgenommen<br />
werden.<br />
Als geeignetes Mittel für eine solche Darstellung hat sich das Forschungsframework für Informationssys-<br />
Umgebung<br />
• Interaktive Systeme<br />
• Grafische <strong>Benutzungsoberflächen</strong><br />
• Legacy-Software<br />
• Verwaltung komponentisierbarer<br />
Patterns<br />
Offene<br />
Probleme<br />
Praktische<br />
Anwendung<br />
Arbeitsergebnisse<br />
• Metamodelle für Java<br />
Swing und XUL<br />
• Werkzeuge und Editoren<br />
• modellbasiertes<br />
Reverse-Engineering<br />
• Revision PLML<br />
• vereinheitlichter Patternkatalog<br />
mit PLML<br />
• Bewertung komponentisierbarer<br />
HCI-Patterns<br />
genutzte<br />
Konzepte<br />
Beiträge zur<br />
Wissensbasis<br />
Wissensbasis<br />
• MDSE/MDA<br />
• EMF/MOF<br />
• mehrstufige UI-<strong>Generierung</strong><br />
/ Cameleon<br />
• PLML<br />
• HCI-Patterns und Patternkataloge<br />
• Reengineering<br />
Abbildung 1.1: Inhaltsübersicht, als Instanz des Forschungsframeworks nach Hevner [60]<br />
1
2 KAPITEL 1. EINLEITUNG<br />
teme nach Hevner [60] erwiesen. Dabei handelt es sich um einen Strukturierungsformalismus für Forschungsarbeiten.<br />
In der Abbildung 1.1, wird angelehnt an Hevner, der Inhalt dieser Arbeit zusammengefasst.<br />
Der Grafik ist zu entnehmen das die hier betrachteten Forschungsfragen die Problematik der Mensch-<br />
Maschine-Kommunikation mit modellbasierten Methoden berühren. Herausgehoben behandelt wird der<br />
Bereich der grafischen <strong>Benutzungsoberflächen</strong>.<br />
Die dem allgemeinen Stand der Forschung entnommenen, als Wissensbasis bezeichneten, Konzepte und<br />
Techniken bilden den Ausgangspunkt und Rahmen der Arbeiten. Der Inhalt dieser Dissertationsschrift<br />
liefert einen nützlichen Beitrag zur Erweiterung dieser Wissensbasis.<br />
1.1.1 Einführung in die Problemstellung<br />
Seit der Entstehung mechanischer, elektrischer und elektronischer Rechenanlagen ab den 30er Jahren des<br />
20. Jahrhunderts besteht die Herausforderung, diese Maschinen adäquat zu steuern. Diese Steuerung besteht<br />
auf unterster Ebene aus Folgen <strong>von</strong> Instruktionen, die das Rechenwerk eines Computers ausführt. In<br />
der Regel beschreiben diese Instruktionen Operationen auf Daten. Eine Abfolge solcher Instruktionen wird<br />
als Programm bezeichnet. Der Begriff Software wird oft als allgemeiner Sammelbegriff für Programme 1<br />
benutzt. In seiner heutigen Verwendung umfasst die Software dabei, neben den reinen Ausführungsinstruktionen,<br />
auch Daten und Dokumentationen, die für den Ablauf eines Programms notwendig sind.<br />
Die Herangehensweise an die Programmierung <strong>von</strong> Rechenanlangen hat sich im Laufe der Zeit mit den<br />
sich entwickelnden technischen Möglichkeiten gewandelt. Während die ersten Rechner mittels Lochstreifen<br />
2 oder Lochkarten gesteuert wurden, ermöglichten Verbesserungen bei der Datenspeicherung die Hinterlegung<br />
<strong>von</strong> Programmen und Daten auf Massenspeichermedien. Insgesamt hatte Software im Laufe der<br />
Zeit die Tendenz größer und komplexer zu werden. Um mit diesem Problem umzugehen, wurde bei der<br />
Erstellung der Programme immer weiter vom eigentlichen Rechenwerk abstrahiert.<br />
Die konkrete und damit unterste Ebene einer solchen Abstraktion sind die Instruktionsfolgen für das Rechenwerk,<br />
welche in einer Maschinensprache programmiert werden. Assemblersprachen, die nächsthöhere<br />
Abstraktionsebene, entstanden als eine menschenlesbare Abstraktion der Maschinensprachen. Assembler<br />
und Maschinensprachen sind immer an die zugrundeliegende Rechnerarchitektur gebunden, Höhere Programmiersprachen<br />
wiederum abstrahieren <strong>von</strong> Assembler-Quellcode. Solche Programmiersprachen haben<br />
eine eigene wohldefinierte Syntax und ein Typsystem. Beides ist im Wesentlichen 3 <strong>von</strong> der zugrundeliegenden<br />
Architektur unabhängig und wird erst <strong>von</strong> Hilfsprogrammen, den Compilern, in die entsprechende<br />
Zielmaschinensprache übersetzt.<br />
Seit dem Beginn der Entwicklung dieser Sprachen zum Anfang der 1950er Jahre entstand eine ungezählte<br />
Vielzahl solcher Sprachen. Es kam dabei zur Diversifizierung in Spezialsprachen für Teilbereiche der<br />
Informatik und zur Entwicklung <strong>von</strong> Allzwecksprachen. Diese Sprachen lassen sich nach verschiedenen<br />
Charakteristika klassifizieren und verfolgen in aller Regel hauptsächlich ein bestimmtes Programmierparadigma.<br />
Die Erstellung einer Software verläuft mit diesen Programmiersprachen immer sehr ähnlich. Die reine<br />
Entwicklung besteht aus dem Bearbeiten des Quellcodes, in der Syntax der Sprache, dem Übersetzen in<br />
Maschinensprache, dem Testen und der anschließenden Fehlerbehebung oder sonstigen Weiterbearbeitung<br />
des Quellcodes. Dieser Zyklus bildet den Kern der Programmiertätigkeit und ist damit auch integraler<br />
1Die Erstverwendung des Begriffes in diesem Sinne wird J. W. Tukey 1958 zugeschrieben<br />
2bereits bei Zuses Z-Serie und Colossus<br />
3durchaus abhängig bei Datentypenspeicherbreite, Reihenfolge bei Bitwertigkeit
1.1. EINORDNUNG DER ARBEIT 3<br />
Bestandteil <strong>von</strong> Softwareentwicklung.<br />
Da Quellcode <strong>von</strong> Menschen geschrieben wird, gibt es eine Reihe <strong>von</strong> Problemen damit. Das Schreiben<br />
ist erstens ein sehr langwieriger Prozess; für einen durchschnittlichen Entwickler in einer modernen Hochsprache<br />
kann mit 200 Zeilen Quellcode pro Tag kalkuliert werden. Diese Zahl beinhaltet dann bereits<br />
Layout, Kommentare und Ähnliches, was nur als Lese- und Interpretationshilfe für den Quellcode dient.<br />
Bei der Berechnung über den gesamten Verlauf eines Softwareprojekts, wobei die eigentliche Programmierung<br />
dann meist nur einen kleineren Teil des Gesamtaufwandes umfasst, ergeben sich sogar Werte <strong>von</strong><br />
durchschnittlich nur noch 10-20 Quellcodezeilen pro Tag [141]. Obwohl die Metrik Quellcodezeilenzahl,<br />
englisch Lines of Code, sehr problematisch 4 ist, mag sie zur Verdeutlichung des Problems dienen, wenn<br />
man als Vergleichsgröße die immer wieder berichteten 40 Millionen Zeilen Quellcode für Windows XP<br />
heranzieht. Für eine kleinere Bürosoftware 5 sind 100.000 Zeilen Quellcode ebenfalls erreichbar.<br />
Die Wartung, Weiterentwicklung und Fehlerbehebung derartig großer Software ist ein Problem. Moderne<br />
Entwicklungswerkzeuge, insbesondere hochentwickelte Programmierumgebungen, und Vorgehensweisen<br />
wie Kapselung und Wiederverwendung machen das Problem beherrschbar, lösen es jedoch nicht. Mit jeder<br />
weiteren Generation einer Software wird diese komplexer, die Abhängigkeiten größer und gleichzeitig weniger<br />
offensichtlich. Die Einarbeitung und das Hineindenken in existierende Software ist eines der größten<br />
Probleme im Alltag <strong>von</strong> Programmierern.<br />
Eine weitere Problemdimension entsteht durch die Art und Weise wie Softwareentwicklung durchgeführt<br />
wird. Normalerweise arbeiten mehrere Personen an einem Programm, es wird also verteilt entwickelt. Die<br />
Synchronisation der Arbeitsergebnisse, also des Quellcodes, birgt oft Komplikationen.<br />
Als Ausweg aus dieser Problematik bietet sich eine abermalige Abstraktion an. Statt Programme durch das<br />
manuelle Eingeben <strong>von</strong> Quellcode zu entwickeln, sollten Entwickler Modelle spezifizieren. Diese Spezifikation<br />
erfolgt in Modellierungssprachen mit eigener Syntax und Semantik.<br />
Aus den spezifizierten Modellinstanzen wird die auszuführende Sequenz <strong>von</strong> Maschinensprachenbefehlen<br />
generiert. Diese Erzeugung läuft meist als mehrstufiger Prozess ab. Ein Code-Generator erzeugt Quellcode<br />
welcher anschließend <strong>von</strong> einem Compiler in Maschinensprache übersetzt wird. Heutige Compiler sind im<br />
Allgemeinen recht ausgereift, bei den Code-Generatoren wird an der Erreichung eines vergleichbaren Reifegrades<br />
gearbeitet. Ebenfalls denkbar wären Generatoren welche direkt Maschinensprache erzeugen, denn<br />
das Zwischenprodukt Quellcode könnte als redundant betrachtet werden und dementsprechend entfallen.<br />
Quellcode einer Hochsprache zu erzeugen bietet jedoch den Vorteil, die gesamte vorhandene und durchaus<br />
nützliche Palette <strong>von</strong> Hilfsprogrammen der Softwareentwicklung weiter zu nutzen, wie zum Beispiel<br />
Debugger, Deployment 6 -Tools und hochentwickelte integrierte Entwicklungsumgebungen. Darüberhinaus<br />
bietet diese Vorgehensweise die Möglichkeit, Alt-Quellcode in die Neuentwicklungen zu übernehmen.<br />
Dies kann aus diversen Gründen nützlich sein und ist prinzipiell der Möglichkeit ähnlich, Assembler-<br />
Instruktionen in höheren Programmiersprachen einzubetten.<br />
Gemäß den Erfahrungen mit der Einführung der letzten beiden Abstraktionsebenen, wird die Einführung<br />
modellbasierter Techniken zur Erhöhung der Produktivität bei der Softwareerstellung und zur Reduktion<br />
der Komplexität bei der Bearbeitung der Software führen.<br />
Neben einer verbesserten Handhabbarkeit <strong>von</strong> großen Softwareprojekten muss der Ansatz des Verwendens<br />
<strong>von</strong> Modellen weitere Vorteile bieten um breite Akzeptanz zu finden. Zwei wesentliche Dinge sind hier<br />
hervorzuheben.<br />
4 Zählweise, Abstraktionsebene, Sprachabhängigkeit<br />
5 DocFactory [62]: 80.000 Zeilen Java + 35.000 Zeilen Stored Procedures<br />
6 Software-Verteilung
4 KAPITEL 1. EINLEITUNG<br />
Modelle als Abstraktion über Quellcode bieten die Möglichkeit, aus den gleichen Modellen Quellcode<br />
für diverse variierende Nutzungsumgebungen zu erstellen. Dies ist vergleichbar mit der ursprünglichen<br />
Motivation bei der Einführung der höheren Programmiersprachen. Aus dem Quellcode einer höheren Programmiersprache<br />
kann Maschinencode für verschiedene Architekturen erzeugt werden, ebenso kann aus<br />
Modellen der Quellcode für verschiedene Hochsprachen erzeugt werden. Die dafür nötigen Hilfsprogramme<br />
werden als Model-To-Text Transformatoren bezeichnet.<br />
Ein weiterer Vorteil bei der Anwendung <strong>von</strong> Modellen und Modellierungskonzepten liegt in der einfachen<br />
Integrierbarkeit <strong>von</strong> bekannt guten Lösungen und einer generell verbesserten Wiederverwendbarkeit <strong>von</strong><br />
Spezifikationen. Bei der Planung einer Softwareentwicklung ist man in der Regel bestrebt, das bestmögliche<br />
Ergebnis zu erreichen. Die Kenntnisse und Fähigkeiten der jeweils an einer Entwicklung beteiligten<br />
Personen sind oft unterschiedlich verteilt. Indem man jedem Entwickler Zugriff auf, <strong>von</strong> überdurchschnittlich<br />
guten Entwicklern, erstellte Muster-Lösungen bietet und deren Verwendung abfordert, läßt sich<br />
möglicherweise die Gesamtqualität der entstehenden Software heben. Solcherart hervorgehobene (Muster-<br />
)Lösungen werden als Best-Practices, dies meint erwiesenermaßen bestmögliche Vorgehensweisen, bzw.<br />
Patterns bezeichnet. Patterns finden sich in vielen Bereichen der Informatik und werden in diversen Sammlungen<br />
publiziert. Prominentes Beispiel einer solchen Sammlung sind die objektorientierten Patterns der<br />
Gruppe um Erich Gamma [48], andere Patternsammlungen, für HCI-Patterns, werden in Kapitel 3 vorgestellt.<br />
Die Verwendung <strong>von</strong> Modellierungssprachen führt zu dem Paradigma der modellgetriebenen Softwareentwicklung.<br />
Natürlich rechtfertigt die bloße Verwendung <strong>von</strong> Modellen in verschiedenen Phasen der Softwareentwicklung<br />
es noch nicht <strong>von</strong> einem eigenen Paradigma zu sprechen. Die modellgetriebene Softwareentwicklung<br />
stellt Modelle in das Zentrum der Entwicklung, sie treiben die Entwicklung gewissermaßen<br />
voran. Das Programmieren mit diesem Paradigma besteht daher aus dem Instanziieren <strong>von</strong> Modellen und<br />
der Festlegung <strong>von</strong> Transformationen zwischen Modellinstanzen. In diesen Kontext ordnet sich diese Dissertation<br />
ein.<br />
1.1.2 Forschungsfragen<br />
Das grundlegende Ziel dieser Arbeit ist die Erstellung <strong>von</strong> <strong>Benutzungsoberflächen</strong> unter Verwendung der<br />
modellgetriebener Softwareentwicklung. Dazu ist es erforderlich, über geeignete Metamodelle für alle vorzusehenden<br />
Abstraktionsebenen zu verfügen. Der Stand der Forschung bietet bereits eine Vielzahl ausgearbeiteter<br />
Metamodelle für abstrakte Beschreibungen <strong>von</strong> Nutzerschnittstellen. Deshalb sind Metamodelle<br />
für die Deklaration konkreter grafischer <strong>Benutzungsoberflächen</strong> <strong>von</strong> besonderem Interesse.<br />
Somit ergibt sich als erste Forschungsfrage:<br />
1. Lassen sich umfassende Metamodelle moderner grafischer <strong>Benutzungsoberflächen</strong> erstellen?<br />
Aus einer angenommenen positiven Antwort auf diese Frage und auf Grund der Vielzahl <strong>von</strong> Darstellungsmöglichkeiten<br />
und Steuerparametern aktueller Grafiksysteme, erwachsen daraus die Anschlussfragen:<br />
2. Wie kann die inhärente Komplexität solcher Metamodelle handhabbar gemacht werden?<br />
3. Inwieweit kann nützliche Werkzeugunterstüzung gestellt werden?<br />
Die Konzeption der Mensch-Maschine-Kommunikation ist ein ausführlich erforschter Bereich. Es wäre<br />
wünschenswert die dort gewonnenen Erkenntnisse im Rahmen der MDA nutzbar zu haben, daher:
1.1. EINORDNUNG DER ARBEIT 5<br />
4. Welche Möglichkeiten zur Integration <strong>von</strong> HCI-Patterns sind denkbar?<br />
5. Welche Patterns sind soweit formalisierbar, dass sie direkt in einem Gesamtprozess anwendbar<br />
sind?<br />
Die modellgetriebene Softwareentwicklung steht nicht allein, eine nicht abschätzbare Menge Software<br />
wurde ohne Beachtung dieses Paradigmas entwickelt:<br />
6. Welche Möglichkeiten bestehen zur Überführung existierender Softwaresysteme in den<br />
modellgetriebenen Ansatz?<br />
7. Lässt sich die Nutzerschnittstelle solcher Altsysteme automatisiert als Modellinstanz<br />
abbilden?<br />
Die letzte, über allem schwebende Frage muss der Effizienz des Vorgehens nach diesem Paradigma gelten:<br />
8. Welche Vorteile und Verbesserungen lassen sich für die modellgetriebene Entwicklung<br />
<strong>von</strong> <strong>Benutzungsoberflächen</strong> zeigen?<br />
1.1.3 Ergebnisüberblick<br />
Es soll bereits an dieser Stelle überblicksartig eine Vorschau auf die erarbeiteten Ergebnisse gegeben werden.<br />
Die Antwort auf die Frage 1 fällt in der Tat positiv aus: es ist möglich, ausführliche Metamodelle für<br />
aktuelle grafische Benutzungsschnittstellen nach der Windows Icon Menu Pointer (WIMP) Idee anzugeben.<br />
Für die – <strong>von</strong> einer öffentlichen Community getragenen UI-Sprache – XUL wird in Punkt 2.1.4.2 gezeigt,<br />
wie aus deren frei verfügbaren Modellfragmenten ein umfassendes Ecore-Metamodell erstellt werden kann.<br />
Gänzlich anders gelagert sind die Probleme bei der Erstellung eines Metamodells des Swing-Frameworks<br />
der Sprache Java. Ein Verfahren zu dessen Erstellung wird in Unterabschnitt 4.2.1 vorgestellt. Sowohl<br />
bei XUL als auch bei Swing handelt es sich um moderne, komplexe, ausgereifte und weitverbreitete User<br />
Interface (UI)-Systeme.<br />
Zur Beantwortung der Fragen 2 und 3 für XUL; das Metamodell<strong>von</strong> XUL wurde unter anderem verwendet<br />
um damit Teile eines grafischen Editor zu generieren, die Herangehensweise und das Ergebnis sind<br />
in Punkt 2.1.4.3 kurz beschrieben. Im Fall des sehr großen Swing-Metamodells wurde ein, in Unterabschnitt<br />
4.1.4 beschriebenes, Verfahren zur regelbasierten Modellreduzierung (Model-Pruning nach [112])<br />
erfolgreich genutzt. Dadurch konnte das Swing-Metamodell erheblich verkleinert und damit handhabbarer<br />
gemacht werden. Dieses Swing-Modell wird, wie in Kapitel 4 demonstriert, unter anderem in den<br />
Reengineering-Werkzeugen benutzt, womit ebenfalls die Fragen 2 und 3 für Swing beantwortet sind.<br />
Eine schwache Form der Integration <strong>von</strong> Patterns in einen MDA-Gesamtprozess ist es, wenigstens die Patterns<br />
als Instanzen eines geeigneten Metamodells zu beschreiben. In Abschnitt 3.2 wird ein Metamodell<br />
für diesen Verwendungszweck erarbeitet und anschließend, in Unterabschnitt 3.5.2, verwendet, um aus<br />
frei verfügbaren Pattern-Deklarationen einen einheitlichen Patternkatalog zu erzeugen. Zur weitergehenden<br />
Integration <strong>von</strong> Patterns in einen modellgetriebenen Prozess muss sich die Lösung eines Patterns als<br />
Transformationsalgorithmus auf eine Modellinstanz anwenden lassen. Soweit ermittelt werden konnte, ist<br />
dies nur für eine Minderheit der in der Literatur beschriebenen HCI-Patterns sinnvoll möglich. Details zur<br />
Vorgehensweise werden in Abschnitt 3.5 präsentiert. Das Ergebnis dieser Überlegungen, die Patternkomponenten,<br />
werden unter anderem durch einen eigens entwickelten XUL-Editor benutzt.<br />
Die Fragen zur Überführung <strong>von</strong> Alt- oder Legacy-Software in einen modellgetriebenen Prozess werden<br />
insbesondere im Kapitel 4 behandelt. Unter bestimmten Umständen ist es möglich äquivalente Modellinstanzen,<br />
geeignet zur Weiterverarbeitung, aus nicht modellbasiert entwickelten Systemen zu generie-
6 KAPITEL 1. EINLEITUNG<br />
ren. Beispielsweise konnte in Punkt 4.2.1.2 und Unterabschnitt 4.2.2 gezeigt werden, dass es prinzipiell<br />
möglich ist, aus den Nutzerschnittstellen derartiger Systeme Modellinstanzen für den modellgetriebenen<br />
UI-Entwicklungsprozess (MD-UID Prozess) zu gewinnen.<br />
Zur Beantwortung der Frage 8 sei an dieser Stelle auf die Zusammenfassung im Kapitel 5 verwiesen.<br />
Abschließend noch ein genereller Überblick über die Organisation der Arbeit. In dieser Einleitung werden<br />
im Folgenden noch Technologien <strong>von</strong> allgemeiner Bedeutung erläutert, sowie artverwandte Ansätze<br />
kurz vorgestellt. Im daran anschließenden Kapitel 2 wird ein umfassender Gesamtprozess für die modellgetriebener<br />
Entwicklung <strong>von</strong> Benutzeroberflächen mit allen notwendigen Teilmodellen beschrieben.<br />
Das Kapitel 3 erklärt wie HCI-Patterns formalisiert, katalogisiert und im modellgetriebenen Ansatz benutzt<br />
werden können. Den Abschluß bildet Kapitel 4, worin eine Methodik zur Überführung vorhandener<br />
System in den modellgetriebenen Ansatz vorgestellt wird.<br />
1.2 Einführung in Modelle und <strong>Benutzungsoberflächen</strong><br />
1.2.1 Modellierung in der Softwaretechnik<br />
Mit dem Ziel der Erstellung eines allgemeinen Modellbegriffes definierte Stachowiak 1973 [113] drei Kernmerkmale<br />
für Modelle: Abbildung, Pragmatik und Verkürzung. Demnach ist ein Modell immer ein Abbild<br />
oder Vorbild einer beliebigen Entität; eine Darstellung künstlicher, natürlicher, realer oder virtueller Originale.<br />
Die Pragmatik ist der Einsatzzweck in welchem ein Modell das Original ersetzt oder repräsentiert.<br />
Charakteristisch für jedes Modell ist außerdem die Abstraktion, es werden nicht alle Eigenschaften des<br />
Originals in das Modell übernommen.<br />
Modellierung und Modelle werden in der Softwaretechnik schon seit langer Zeit eingesetzt. Beispiele dafür<br />
sind unter anderem Entity-Relationship-Modelle [19] für die Datenmodellierung, Zustandsautomaten für<br />
die Verhaltensmodellierung oder auch Architekturmodelle wie etwa das Seeheim-Modell [125] oder PAC 7<br />
als Überlegungen zur Gestaltung <strong>von</strong> Softwaresystemen. Die derzeit bekanntesten Modelle sind wohl diejenigen<br />
der UML 8 , bei denen es sich um Modelle zur objektorientierten Softwareentwicklung handelt.<br />
Oft wird Modellierung „nur“ für die Anforderungsanalyse, das Systemdesign und Dokumentationszwecke<br />
verwendet.<br />
In der modellbasierten Softwareentwicklung geht es demgegenüber darum, Modelle<br />
während des gesamten Softwarelebenszyklus einzusetzen. Je nachdem wieweit die Modelle<br />
den Kern eines solchen Lebenszyklusmodells bilden, spricht man entweder <strong>von</strong> modellbasierter<br />
oder <strong>von</strong> modellgetriebener Softwareentwicklung.<br />
Unter Modellbasierung, als der schwächeren Integrationsform, wird dabei die regelmäßige<br />
Verwendung <strong>von</strong> dedizierten Modellen verstanden. Eine modellgetriebene Entwicklung,<br />
oft als Model-Driven Software-Development (MDSD) bezeichnet, geht darüber hinaus. Es<br />
ist eine Softwareentwicklungsmethodik die (halb)automatisch durch Modelle vorangetrieben<br />
wird.<br />
Transformationen zwischen Modelleninstanzen bzw. die Erzeugung <strong>von</strong> Text aus Modellinstanzen sind<br />
wesentliche Arbeitsschritte in diesem Paradigma. Das Abbilden einer Modellinstanz auf eine andere Instanz<br />
wird Model-To-Model (M2M) Transformation genannt. Die Erzeugung <strong>von</strong> Text aus einem Modell,<br />
oftmals Quellcode, wird im Allgemeinen als Model-To-Text (M2T) Transformation bezeichnet.<br />
7 Presentation, Abstraction und Controller nach [125]<br />
8 Unified Modelling Language [130]
1.2. EINFÜHRUNG IN MODELLE UND BENUTZUNGSOBERFLÄCHEN 7<br />
Eine wichtige Ausprägung innerhalb der MDSD ist die durch die Object Managegement Group (OMG)<br />
standardisierte Model-Driven-Architecture (MDA). MDA ist ein Vorschlag zur Lösung des Problems der<br />
plattformunabhängigen Spezifikation <strong>von</strong> Anwendungslogik. Diese Lösung besteht in der Anwendung diverser,<br />
ebenfalls durch die OMG definierter, objekt-orientierter Techniken. Zum Einsatz gelangen UML<br />
und MOF [80] für die Modellierung und etwa QVT 9 für M2M-Transformationen.<br />
Die Meta Object Facility (MOF), frei übersetzt etwa Objektbeschreibungssprache, definiert einen Beschreibungsmechanismus<br />
für Modelle. Dieser besteht aus einer Hierarchie <strong>von</strong> Meta-Modellen, also Modellen<br />
die Modelle beschreiben, und einer Definitionssprache. Ursprünglich [80] eine 4-Ebenen Architektur definierend,<br />
besteht in den aktuellen Ausprägungen des Standards Complete und Essential MOF (EMOF) nach<br />
MOF 2.0 [81] nur noch die Forderung nach mindestens zwei Ebenen:<br />
„The minimum number of layers is two so we can represent and navigate from a class to its<br />
instance and vice versa.“<br />
Der Großteil der Modelle in dieser Arbeit fußt auf Ecore [36], dem Metamodell des Eclipse Modeling<br />
Framework. Zwischen Ecore und Essential MOF besteht ein enger Zusammenhang, nach [115]:<br />
„. . . with a focus on tool integration, rather than metadata repository management, Ecore avoids<br />
some of MOF’s complexities, resulting in a widely applicable, optimized implementation“. . .<br />
„Essential Meta-Object Facility (EMOF) is the new lightweight core of the metamodel that<br />
quite closely resembles Ecore. Because the two models are so similar, EMF is able to support<br />
EMOF directly as an alternative XMI serialization of Ecore.“<br />
Die Abbildung 1.2 versucht eine Visualisierung des Metamodellzusammenhangs. Da der Standard MOF<br />
2.0 keine vordefinierten Modellebenen mehr vorgibt sind die in der Grafik verwendeten Mx Nummerierungen<br />
keine offiziellen Benennungen. Insbesondere sind sie nicht als äquivalent zu den in der UML Infrastructure<br />
Specification [130] benutzten Ebenennummerierungen zu verstehen. Die dortige 4-Ebenen Architektur<br />
9 Query View Transformation [98]<br />
Essential MOF<br />
M2: (Meta-)Modell zur Modellbeschreibung M1<br />
Name Name Name<br />
M1: Modell der Instanzen<br />
M0: Instanzen-Ebene<br />
Abbildung 1.2: Instanzen und Modelle im EMOF-Zusammenhang
8 KAPITEL 1. EINLEITUNG<br />
fußt auf einer Unterscheidung zwischen Runtime M0 und Designtime M1, eine Betrachtungsweise, die für<br />
die Modelle in dieser Arbeit nicht die sinnvoll ist.<br />
In Abbildung 1.2 ist die unterste Schicht M0 die Ebene der gespeicherten Informationen bzw. der instanziierten<br />
Modellobjekte. In der Hierarchie darüber steht die Modellebene M1 welche die Struktur der Einträge<br />
auf der M0-Ebene festlegt. Auf der Ebene M2, der ersten Metamodellebene, wird die Struktur des Modells<br />
der M1-Ebene definiert.<br />
Vereinfachend kann gesagt werden, dass die Struktur der Elemente einer Mn−1-Schicht durch die darüberliegende<br />
Mn-Schicht definiert wird. Der EMOF-Standard sieht prinzipiell eine beliebig tiefe Metamodellebenenstruktur<br />
vor.<br />
1.2.2 Modelle für die Nutzerinteraktion<br />
Die Schnittstellen in der Mensch-Maschine Kommunikation sind seit den Tagen der ersten automatischen<br />
Rechner ein Standardproblem der Programmierung. Je nach System und Umgebung ist die jeweilige<br />
Schnittstelle anders ausgeprägt. Es existieren insbesondere textuelle, grafische, sprachbasierte sowie<br />
berührungs- und bewegungsgesteuerte Interfaces. Ebenso wurden Interfaces entwickelt die mehrere dieser<br />
Interaktionsmöglichkeiten in einer Schnittstelle, in einem sogenannten multi-modalen Interface, kombinieren.<br />
Die Programmierung der Nutzungsschnittstellen ist ein aufwändiges Problem und seit langer Zeit Gegenstand<br />
der Forschung. Seit etwa dem Ende der 1980er Jahre wird in der modellbasierten UI-Erstellung eine<br />
Lösung dieses Problems gesucht. Die Erforschung begann mit Systemen für textuelle User-Interfaces 10 .<br />
Nachfolgende Frameworks, Systeme und Ansätze zogen dann auch grafische UIs sowie Weboberflächen in<br />
Betracht bzw. wurden gleich auf multi-modale Interfaces ausgelegt.<br />
Im Jahr 2005 haben Gomaa et al. eine Übersicht [54] der bis dato eingeführten oder vorgestellten modellbasierten<br />
UI-<strong>Generierung</strong>systeme zusammengestellt. Sie identifizierten 27 Ansätze, wo<strong>von</strong> allerdings<br />
drei als XML-UI-Beschreibungssprachen 11 für sich genommen keine eigenen Ansätze darstellen, sondern<br />
in anderen verwendet werden. Die verbleibenden 24 Umgebungen oder Systeme enthalten ebenfalls bei<br />
weitem nicht alle bekannten Verfahren. Nicht enthalten sind beispielsweise die in Frankreich am INRIA 12<br />
entwickelten Verfahren zu selbstanpassenden User Interfaces [122] oder AMF [106] - Agent Multi-Facets<br />
- ebenfalls ein Framework für die oberen Abstraktionsebenen einer Multiple-UI Entwicklung. Ebenfalls<br />
nicht in [54] aufgeführte System sind die lokal an der Universität Rostock entwickelten Ansätze USGP<br />
und die Weiterentwicklung des TADEUS-Projektes. Die Abbildung 1.3 stellt die Veröffentlichungszeitpunkte<br />
diverser Projekte, der modellbasierten UI-Entwicklung, vergleichend in einem Zeitstrahl dar. Die<br />
angegebenen Zeitpunkte entstammen [54] und eigenen Recherchen.<br />
1.2.3 Historische Entwicklung <strong>von</strong> UI Modellierung<br />
Im Folgenden werden diverse Ansätze der Modellierung <strong>von</strong> Benutzeroberflächen vorgestellt, die in der<br />
Vergangenheit verfolgt und untersucht wurden. Natürlich ist es, in diesem Rahmen, nicht sinnvoll alle der<br />
im Zeitstrahl <strong>von</strong> Abbildung 1.3 eingetragenen Systeme vorzustellen. Daher wurde eine Kategorisierung<br />
vorgenommen. Es stellte sich heraus, dass sich die Systeme grob in drei Gruppen einteilen lassen. Jede<br />
dieser drei Gruppen wird kurz erläutert und es werden einzelne typische Vertreter vorgestellt.<br />
10UIDE [41], beispielsweise stammt aus dem Jahr 1988<br />
11XUL, XIML, UIML<br />
12Institut national de recherche en informatique et en automatique
1.2. EINFÜHRUNG IN MODELLE UND BENUTZUNGSOBERFLÄCHEN 9<br />
ITS<br />
UIDE [41]<br />
HUMANOID [119]<br />
TRIDENT [138]<br />
DON [42] GENIUS<br />
DRIVE [77]<br />
JANUS<br />
MECANO [93]<br />
TADEUS [108]<br />
MASTERMIND [120]<br />
ADEPT [73]<br />
FUSE [111]<br />
1985 1990 1995 2000 2005<br />
AME<br />
WML [143]<br />
MOBI-D [97]<br />
TEALLACH [56]<br />
USGP<br />
XIML [94]<br />
UIML [1]<br />
AUIML [12]<br />
XUL [71]<br />
Markopoulos<br />
AURORA<br />
Pebbles<br />
Dygimes<br />
AMF INCITS/V2<br />
[106]<br />
XAML [76]<br />
VRIXML [27]<br />
TERESA [13]<br />
IM2L [39]<br />
M6C<br />
ISML [24]<br />
useML [103]<br />
X3USGP [78]<br />
GIML [70]<br />
UsiXML [140]<br />
Abbildung 1.3: Zeitliche Einordnung diverser MB-UID Systeme und Umgebungen<br />
T:XML [101]<br />
Die erste Gruppe, im gewissen Sinne die allgemeinste Gruppe, bilden diejenigen Systeme, die ohne Beschränkung<br />
der Einsatzdomäne arbeiten und in ihren Prozessen nicht die Verwendung <strong>von</strong> Aufgabenmodelle<br />
vorsehen. Vertreter dieser Gruppe werden im Abschnitt A.1 vorgestellt.<br />
Schränkt man den Einsatzbereich bzw. die Domäne der zu erstellenden Software genügend ein wird es<br />
möglich, diverse Hilfsmodelle domänenspezifisch auszulegen. Auf diese Art wird es wesentlich leichter,<br />
bzw. überhaupt erst sinnvoll möglich, die generierten <strong>Benutzungsoberflächen</strong> mit realer Geschäftslogik zu<br />
verknüpfen. Zwei Systeme aus dieser zweiten Gruppe werden im Punkt 1.2.3.2 vorgestellt.<br />
Die dritte Gruppe <strong>von</strong> Systemen bilden die auf Aufgabenmodellen basierenden Ansätze. Ursprünglich<br />
stammt die Idee der Aufgabenmodelle aus der Verhaltensforschung und dient zur Beschreibung der Ziele,<br />
die menschlichen Verhaltensweisen zugrundeliegen. In der Softwaretechnik werden Aufgabenmodelle typischerweise<br />
im Rahmen der Anforderungsanalyse eingesetzt. Die in diese Gruppe eingeordneten Ansätze<br />
gehen darüber hinaus und nutzen die erstellten Aufgabenmodelle zur Strukturierung, Hierarchisierung und<br />
Modellierung der Funktionalitäten einer Anwendung. Aufbauend auf den in den Aufgabenmodellen identifizierten<br />
Funktionalitäten und Zusammenhängen werden schließlich <strong>Benutzungsoberflächen</strong> generiert. Die<br />
generelle Idee der Aufgabenmodelle wird in verschiedenen Ausprägungen umgesetzt. Als etablierte Vorgehensweisen<br />
seien hier GOMS 13 , TKS 14 oder CTT 15 genannt. Die konkreten Unterschiede dieser Ansätze<br />
sollen hier nicht diskutiert werden. Dennoch werden bei den Erläuterungen in Punkt 1.2.3.3 und Abschnitt<br />
A.3 nicht nur die Systeme vorgestellt die Aufgabenmodelle verwenden, sondern jeweils auch das<br />
im Ansatz benutzte Konzept für Aufgabenmodelle kurz angerissen.<br />
Im Anhang der Arbeit wird eine Auswahl an Systemen, Ansätzen und Frameworks vorgestellt, bei denen<br />
es sich um wesentliche bzw. repräsentative Kandidaten der drei vorstehend charakterisierten Gruppen dar.<br />
1.2.3.1 Ansätze ohne Beschränkung des Einsatzbereichs<br />
Idealerweise sollte ein modellbasiertes System funktionsfähige <strong>Benutzungsoberflächen</strong> für beliebige Anwendungsbereiche<br />
liefern. UIDE, DON und HUMANOID gehören zu den zeitlich frühesten Ansätzen die<br />
versuchten diesen Anspruch mittels deklarativer UI-Beschreibungen zu erfüllen. Die UI-Deklarationen erstrecken<br />
sich daher nicht nur auf Layout- und Designaspekte, sondern definieren auch die Anbindung an<br />
die Systemumgebung. In allen drei Ansätzen werden die UI-Deklarationen zur Laufzeit interpretiert und<br />
einem Benutzer als funktionsfähige Anwendung dargestellt. Unterschiede bestehen in der Zielmodalität,<br />
13 Goals, Objects, Methods, Selection Rules [18]<br />
14 Task Knowledge Structures [66]<br />
15 Concurrent Task Trees [87]<br />
MARIA XML [88]
10 KAPITEL 1. EINLEITUNG<br />
textuell oder grafisch, den benutzten Hilfsmodellen und der Notation der Deklarationen. Letztlich konnte<br />
sich zwar keines dieser Systeme durchsetzen, die in Abschnitt A.1 dargelegten Überlegungen zu den<br />
Grundprinzipien sind aber auch heute noch relevant.<br />
1.2.3.2 Modellierung für Spezialbereiche<br />
Beschränkt man den Einsatzbereich, also die Domäne, für welche Anwendung und Benutzeroberfläche<br />
erzeugt werden sollen, können genau auf den Problembereich zugeschnittene Modelle verwendet werden.<br />
Das ist eine erhebliche Erleichterung gegenüber den breiter angelegten Ansätzen zur allgemeinen<br />
unbeschränkten Modellierung, insbesondere gestaltet sich die Anbindung <strong>von</strong> Verarbeitungslogik an die<br />
modellierte und generierte Oberfläche einfacher. Die Einschränkung des Einsatzbereich führt oft auch zur<br />
Reduzierung der in Frage kommenden UI-Elemente und generell der möglichen Nutzerinteraktionen. Diese<br />
Reduzierung der Problemkomplexität wirkt sich so gravierend aus, dass die im Abschnitt A.2 vorgestellten<br />
Ansätze DRIVE und TEALLACH in der Lage sind, funktionsfähige Software zu erzeugen.<br />
1.2.3.3 Systeme mit Aufgabenmodellierungshintergrund<br />
Die Aufgabenmodellierung, ist eine Grundlagentechnik der Anforderungsanalyse. Eine kurze Charakterisierung<br />
dieses Ansatzes findet sich bei Markopoulos [73]:<br />
„A task model is a symbolic representation of that which the modeller considers significant<br />
about a task. Task models may be used descriptively, predictively, and prescriptively, though<br />
in practice few existing techniques have the power to do all.“<br />
Es existieren diverse Umsetzungen der Aufgabenmodell-Idee. Allen gemeinsam ist die Vorstellung, Anwendungen<br />
vom Standpunkt der späteren Nutzer zu beschreiben. Von diesen Nutzern wird angenommen,<br />
mit dem Einsatz der Software für ihre Zwecke, ein Ziel erreichen zu wollen. Zur Erreichung dieses Zieles<br />
sind bestimmte Aufgaben zu absolvieren und dabei Artefakte zu bearbeiten. Normalerweise werden die<br />
identifizierten Aufgaben dazu in einer Hierarchie angeordnet. Zur Festlegung der Abarbeitungsreihenfolge<br />
kommen temporale Operatoren zur Anwendung. Diese Operatoren definieren die zeitliche Relation zwischen<br />
Aufgaben, etwa Parallelität oder Nacheinanderausführung. Die hinter diesen Operatoren stehende<br />
Logik hat ihre Wurzeln in der Prozessalgebra.<br />
Aufgabenmodelle sind im Prinzip für alle denkbaren Domänen einsetzbar. Daher existiert theoretisch auch<br />
keine Beschränkung für aus Aufgabenmodellen erzeugte Anwendungen.<br />
Das Erzeugen <strong>von</strong> <strong>Benutzungsoberflächen</strong> ausgehend <strong>von</strong> Aufgabenmodellen wurde in der Forschung ausführlich<br />
untersucht. Die in Abschnitt A.3 vorgestellten Systeme nutzen die in den Aufgabenhierarchien<br />
enthaltenen Informationen um mittels Heuristiken prototypische Nutzungsoberflächen zu kreieren. Allerdings<br />
beschreiben die <strong>von</strong> den Ansätzen jeweils eingesetzten Aufgabenmodelle die späteren Anwendungen<br />
auf einer hohen Abstraktionsebene. Verwendet man sie als Datenquelle in einem modellbasierten UI-<br />
Entwicklungsprozess liefern sie im Wesentlichen die Namen der vorgesehenen Aktionen und welche dieser<br />
benannten Aktionen zu einem gegebenen Zeitpunkt ausführbar sind. Allein auf Basis dieser Informationen<br />
ist es kaum denkbar, gebrauchstaugliche Nutzungsschnittstellen zu generieren. Die vorgestellten Systeme<br />
benutzen dementsprechend weitere Modellarten als Primärquellen in ihrem jeweiligen Ansatz.
1.2. EINFÜHRUNG IN MODELLE UND BENUTZUNGSOBERFLÄCHEN 11<br />
1.2.3.4 Fazit<br />
Insgesamt haben die in der Vergangenheit entwickelten Systeme bisher noch nicht den Reifegrad erreicht,<br />
der es ermöglicht, produktive Anwendungen mit ihnen zu entwickeln. Wieder und wieder findet sich auch<br />
diesbezügliche Kritik in Veröffentlichungen, beispielhaft seien Puertas MECANO-Paper [93] und Szekely<br />
Ausführungen zu Mastermind [120] genannt. Die Kritik bei [120] fällt eher generell aus, während Puerta<br />
bereits 1996 zwei Forderungen [93] an erfolgreiche modellbasierte UI-Systeme aufstellt:<br />
„The two central ingredients for success in model-based systems are: (1) a declarative, complete,<br />
and versatile interface model that can express a wide variety of interface designs, and (2)<br />
a sufficiently ample supply of interface primitives, elements such as push-buttons, windows,<br />
or dialogue boxes that a model-based system can treat as black boxes.“<br />
Diese Hauptzutaten sah er in den zum damaligen Zeitpunkt bekannten Systemen nicht enthalten. Leider<br />
erfüllen auch Puertas eigene Veröffentlichungen rund um MECANO und das bis heute nicht öffentlich<br />
freigegebene XIML diesen selbstgestellten Anspruch nicht voll.<br />
Die Schwächen der im Bereich der MB-UID vorgestellten Systeme liegen eher nicht im Bereich der Aufgabenmodellierung<br />
oder der Ableitung abstrakter Oberflächen. Ganz im Gegenteil, trotzdem im Einzelfall<br />
diverse Operatoren in einem Ansatz möglicherweise nicht vorhanden sind, und falls benötigt über andere<br />
Konstrukte nachgebildet werden müssen, scheint die Ausdruckskraft der Aufgabenmodelle im Zusammenspiel<br />
mit den Operatoren der Communicating Sequencing Processes zur Beschreibung der Nutzerziele<br />
ausreichend zu sein. Selbst aktuellere Arbeiten, wie die ConcurTaskTrees [87] oder HOPS [32], nutzen im<br />
Kern immer wieder diese bereits durch Hoare 1978 [61] bekannt gemachte Technik.<br />
1.2.3.5 Einheitliche Klassifikation<br />
Die Abfolge der Abstraktionsebenen und die benutzten Ausgangs- und Hilfsmodelle ähneln sich in den<br />
diversen Ansätzen aller drei Gruppen. Das ist kein Zufall sondern ergibt sich aus der verfolgten Verfeinerungsstrategie.<br />
Es existiert eine vereinheitlichte Klassifizierung - das CAMELEON Referenzframework -<br />
dessen zugrundeliegenes Ebenenmodell in Abbildung 1.4 dargestellt ist.<br />
CAMELEON wurde primär als Referenzframework zur Klassifizierung <strong>von</strong> MB-UID Ansätzen vorgesehen,<br />
es gibt keine eigene Softwareimplementierung oder ähnliches. Im Abstract <strong>von</strong> [17] wird das CAME-<br />
LEON Referenzframework beschrieben als ein<br />
„framework that serves as a reference for classifying user interfaces supporting multiple tar-<br />
Verfeinerung<br />
Aufgabenmodell und Konzepte<br />
Abstrakte Oberfläche<br />
Konkrete Oberfläche<br />
Endgültige Oberfläche<br />
Abbildung 1.4: Die vier Abstraktionsebenen des CAMELEON-Referenzframeworks nach [17]<br />
Abstraktion
12 KAPITEL 1. EINLEITUNG<br />
gets, or multiple contexts of use in the field of context-aware computing.“.<br />
Die Klassifizierung nach CAMELEON besteht darin die in einem Ansatz auftretenden Modellarten in<br />
die Referenz-Layer einzuordnen. Ebenso werden möglichen Übergänge zwischen den Layern, sowie die<br />
daran jeweils beteiligten Teilmodelle gekennzeichnet und klassifiziert. Da eine Reihe <strong>von</strong> Systemen, wie<br />
z.Bsp. MECANO über eine eigene Laufzeit-Umgebung, mit eventuell eigenen Modellarten, verfügen, ist<br />
bei CAMELEON auch eine Unterscheidung in Design- und Runtime vorgesehen.<br />
Die (Teil-)Modelle eines zu klassifizierenden Verfahrens werden in vier Referenzebenen eingeordnet. In<br />
der Reihenfolge des absteigenden Abstraktionsgrads sind dies: Task Model and Concepts, Abstract Interface,<br />
Concrete Interface und Final Interface. Diese wurden in der Grafik <strong>von</strong> Abbildung 1.4 ins Deutsche<br />
übertragen. Eine erwähnenswerte Abweichung in der Verwendung <strong>von</strong> Begrifflichkeiten, gegenüber den<br />
Termini in dieser Arbeit, liegt in der Unterscheidung zwischen konkretem und endgültigem Userinterface.<br />
Nach CAMELEON ist das konkrete Oberflächenmodell ein Teilmodell welches konkrete Interaktionsobjekte<br />
verwendet, das jedoch nach [17] nur in der Modellierungsumgebung benutzt wird:<br />
„[. . . ] a Concrete UI makes explicit the final look and feel of the Final User Interface, it is still<br />
a mockup than runs only within the [. . . ] development environment.“<br />
Erst auf der Modellebene der endgültigen Oberfläche (Final UI = FUI) liegt demnach eine werkzeugunabhängige<br />
Form der Oberfläche vor, dabei wird es sich typischerweise um generierten Quellcode handeln. Deklarative<br />
UI-Beschreibungen welche <strong>von</strong> unabhängigen Renderern interpretiert werden zählen ebenfalls zur<br />
FUI. CAMELEONs Unterscheidungsebenen tragen zwar zur besseren Klassifizierbarkeit historischer MB-<br />
UI Ansätze bei, wirken jedoch insbesondere bei Verwendung XML-basierter UI-Beschreibungssprachen<br />
künstlich; eine nützliche Unterscheidung zwischen CUI und FUI ist zumeist nicht gegeben.<br />
Die Abbildung 1.5 zeigt eine, durch die CAMELEON-Entwickler selbst vorgenommene, Beispielklassifikation.<br />
Zur Erklärung einzelner Syntaxelemente sei auf [17] verwiesen. Im linken Bereich der Darstellung<br />
sind werden die <strong>von</strong> dem jeweiligen Ansatz benutzten Metamodelle aufgeführt, bei CAMELEON als ontologische<br />
Modelle bezeichnet. Rechts da<strong>von</strong> sind zwei Konfigurationen dargestellt. Als Konfiguration<br />
bezeichnet man ein Ensemble <strong>von</strong> Modellen und die Notation <strong>von</strong> deren Zusammenhängen.<br />
Abbildung 1.5: Beispielhafte CAMELEON-Klassifikation, nach [17]
1.3. INTERAKTIONSDEFINITION MIT XML-DERIVATEN 13<br />
Unter dem Namen Konfiguration 1 werden die zur Designtime verwendeten Modelle und deren Abhängigkeiten<br />
dargestellt. Aus dieser Darstellung des Beispielansatzes ist ersichtlich, dass während der Designtime<br />
keine Modelle zur Beschreibung <strong>von</strong> abstrakter oder endgültiger Oberfläche verwendet werden.<br />
Erst im Zusammenhang mit Konfiguration 2, hier die Laufzeit-Modellzusammenhänge visualisierend, wird<br />
ersichtlich, dass das Modell der abstrakten Oberfläche aus den D8 (Concepts and Task Models) zugeordneten<br />
Teilmodellen abgeleitet wird. Die Erzeugung der endgültigen Oberfläche findet ebenso zur Laufzeit statt<br />
und benötigt dazu das Modell der abstrakten und der konkreten Oberfläche, sowie die Laufzeit-Instanzen<br />
<strong>von</strong> Nutzer- und Plattform-Modell. Die Laufzeitumgebung selbst wird derweil in einer Instanz des Umgebungsmodells<br />
beschrieben.<br />
Durch die gewählte Abstraktionsebene und die inhärente Flexibilität des CAMELEON-Referenzframeworks<br />
lassen sich die allermeisten modellbasierten- und modellgetriebenen Oberflächenerstellungssysteme klassifizieren.<br />
Selbstverständlich auch Systeme die auf etablierten XML-UI Beschreibungssprachen aufsetzen,<br />
trotz der bereits angedeuteten fraglichen Nützlichkeit der FUI-Ebene für deren Fall.<br />
1.2.3.6 Motivation für diese Arbeit<br />
Nach Betrachtung vieler Veröffentlichungen zu den MB-UI Systemen entstand für mich der Eindruck,<br />
dass das Ziel der tatsächlichen Erzeugung funktionsfähiger und vollständig gestalteter Interfaces nicht im<br />
Vordergrund des Interesses steht. Meist werden einfache Beispiele mit wenigen Labels und Push-Buttons<br />
gezeigt deren Layout und Design durch eine nicht weiter erklärte Laufzeitumgebung bereitgestellt wird.<br />
Dieser letzte Schritt der tatsächlichen Oberflächenerzeugung bleibt in den Systembeschreibungen oft zu<br />
vage, oder es werden anscheinend vorhandene Widgetbibliotheken und Metamodelle nicht weiter beschrieben.<br />
Bei oberflächlicher Betrachtung fallen keine besonderen oder gravierenden Probleme auf, die die Entwicklung<br />
ausführlicher Metamodelle für CUI oder FUI behindern. Klar scheint das Metamodelle zur Beschreibung<br />
realer Oberflächen wesentlich größer sein werden als die verhältnismäßig übersichtlichen Modelle<br />
der höheren Abstraktionsebenen. Dies ist nicht gleichbedeutend damit das sie komplexer oder schwieriger<br />
sind. Sie sind nur erheblich größer.<br />
Zusätzlich besteht ein Zwang, sich an bestehende UI-Toolkits anzulehnen. Da es nicht ausreichend ist,<br />
einfach ein neues Metamodell zu entwerfen, die damit modellierten Instanzen müssen auch interpretiert<br />
oder gerendert werden.<br />
Da aus meiner Sicht kein überzeugender Grund besteht nur für die MB-UID ein neues eigenes UI-Toolkit<br />
zu entwickeln, muss man sich an die existierenden Toolkits anlehnen. Das bedeutet Transformationen zu<br />
erstellen, seien es Generatoren, Compiler oder Interpreter, die die Instanzen des eigenen Metamodells in<br />
eine dem Toolkit gerechte Form überführen.<br />
Letztlich handelt es sich dabei um eine langwierige Ingenieursarbeit, die allerdings aus meiner Sicht unbedingt<br />
durchgeführt werden muss, um die modellgetriebene UI-Entwicklung voranzubringen. Die in Punkt-<br />
2.1.4.2 dargelegte Ableitung eines XUL-Metamodells und die in Unterabschnitt 4.2.1 beschriebene Erstellung<br />
des Metamodells <strong>von</strong> Java Swing sollen genau diese Lücke füllen.<br />
1.3 Interaktionsdefinition mit XML-Derivaten<br />
XML [154] wurde ursprünglich für den Datenaustausch im Internet, konkreter im HTML-dominierten<br />
World Wide Web, konzipiert. Das Standardisierungsgremium legte daher Wert darauf das die Daten in
14 KAPITEL 1. EINLEITUNG<br />
einer für Menschen lesbaren und erfassbaren („legible and reasonably clear“) Form enkodiert würden.<br />
Natürlich ist, unabhängig vom Übertragungsmedium, für einen Datenaustausch immer auch eine Standardisierung<br />
des benutzten Datenformates nötig. Designziel für XML war es, das Format der Daten schnell<br />
definierbar, so kurz wie möglich aber formal korrekt zu beschreiben. Zur Umsetzung dieser Ziele wurden,<br />
in der Notation und Semantik, an EBNF angelehnte Grammatiken verwendet. Es war ausdrücklich kein<br />
Ziel <strong>von</strong> XML, kurze, kleine bzw. knapp gehaltene Dateninstanzen zu enthalten.<br />
Diese Designziele können wohl als erreicht bezeichnet werden, denn die XML hat seit ihrer Entstehung<br />
1996 weite Verbreitung gefunden. Die bei XML-Dokumenten anzutreffende Kombination aus, zur automatisierten<br />
Weiterverarbeitung ausreichender, Formalisierung bei gleichzeitiger Lesbarkeit für Menschen<br />
ist offenbar für viele Anwendungsgebiete hinreichend und nützlich. Negativ an XML-Dokumenten kann<br />
der inhärente Zwang zur Hierarchiebildung in der Datenstruktur sein, ebenso wird oft die teils ausufernde<br />
Größe <strong>von</strong> XML-Dateien kritisiert.<br />
XML findet auch in der modellbasierten Softwareentwicklung häufig Anwendung. In den letzten Jahren<br />
ist es hier zum dominierenden Speicherformat für Modelle und Modellinstanzen aufgestiegen. Einen wesentlichen<br />
Anteil daran hat aus meiner Sicht das Eclipse Modeling Project [37]. Daneben setzen auch eine<br />
Vielzahl der außerhalb <strong>von</strong> EMP bestehenden Lösungen, wie TERESA [13] und CTTE [26] oder Puertas<br />
UI-FIN [95] für ihre Datenhaltung auf XML.<br />
Selbstverständlich sind nicht alle aktuellen System XML-basiert. Ein Beispielansatz welcher weder auf<br />
XML noch auf das EMP aufsetzt ist MOOSE [9]. MOOSE nutzt als Basismodell den FAMIX-Core [8],<br />
ein Metamodell zur Beschreibung der statischen Struktur objektorientierter Systeme; Parallelen zu Ecore<br />
lassen sich finden. Als Speicher- und Austauschformat wird MSE [10] genutzt, dieses ist wie XML textbasiert<br />
und generisch. MSE verwendet eine LISP-ähnliche Syntax und bietet zusätzlich einen integrierten<br />
Referenzierungsmechanismus.<br />
Der große Vorteil <strong>von</strong> XML ist eine reichhaltig vorhandene Technologie-Infrastruktur. Damit meine ich die<br />
Vielzahl an vorhandener Software zur Bearbeitung, Darstellung und Transformation <strong>von</strong> XML-Dokumenten.<br />
Eventuelle Vorteile <strong>von</strong> beispielsweise MOOSE erachte ich als nicht so gravierend, diesen XML-Vorteil<br />
aufzuwiegen.<br />
1.3.1 XML-basierte UI-Beschreibungssprachen<br />
Strebt man nun an die Modellierung <strong>von</strong> <strong>Benutzungsoberflächen</strong> auf Basis <strong>von</strong> XML zu betreiben, ist<br />
es wünschenswert, diese Oberflächen ebenfalls mit XML zu beschreiben. In den letzten Jahren entstand<br />
daher eine schwer überschaubare Anzahl XML-basierter Oberflächenbeschreibungssprachen; ein ITEA-<br />
Projektbericht zu UsiXML [134] listet siebenundzwanzig UIDLs auf. Teilweise handelt es sich um reine<br />
Markupsprachen zur Deklaration <strong>von</strong> CUI beziehungsweise FUI Instanzen, andere wiederum sind hybrid<br />
konzipiert und versuchen zusätzlich noch andere Abstraktionsebenen des CAMELEON-Frameworks in ein<br />
und derselben Sprache zu integrieren.<br />
In Tabelle 1.1 sind eine Reihe XML-basierter Sprachen und MB-UID Systeme aufgeführt. Soweit diese<br />
Sprachen der Deklaration <strong>von</strong> CUIs dienen werden sie gewöhnlich als UIDL - User Interface Description/-<br />
Declaration Language - bezeichnet. Neben reinen UIDLs enthält die Tabelle auch vollständige Ansätze,<br />
die wesentlich auf XML-Technologie aufsetzen.<br />
Wie in der Informatik, und besonders auch im XML-Umfeld, üblich, ist jede Sprache unter einem Kürzel<br />
bekannt; dieses wird in Tabelle 1.1 in der Spalte Kurzname angegeben, den eigentlichen Namen zeigt die<br />
Spalte Bezeichnung. In der mit CAMELEON überschriebenen Spalte findet sich eine Grobzuordnung der<br />
durch die jeweilige Sprache abgedeckten Abstraktionsebenen des Referenzframeworks. Die Abkürzung
1.3. INTERAKTIONSDEFINITION MIT XML-DERIVATEN 15<br />
„TC“ steht für die oberste CAMELEON-Ebene Task and Concepts.<br />
In den nachfolgenden Unterabschnitten wird versucht, Zweck und Inhalt einiger der in Tabelle 1.1 aufgezählten<br />
Sprachen kurz zu umreißen. Eine erschöpfende Übersicht oder ein Vergleich wurde nicht angestrebt.<br />
1.3.1.1 <strong>Modellbasierte</strong> UI-Entwicklungsansätze auf XML-Basis<br />
Die XML-Sprachen dieses Abschnittes dienen nicht primär der Deklaration konkreter Benutzungsschnittstellen.<br />
Vielmehr sehe ich sie als Fortführung der Ideen der in Unterabschnitt 1.2.3 dargelegten Ansätze<br />
zur modellbasierten UI-<strong>Generierung</strong> auf Basis <strong>von</strong> XML. Das im Unterabschnitt A.4.1 vorgestellte TE-<br />
RESA [82] ist ein Beispiel für die Kontinuität der Idee bei wechselnder Technologie. Nachfolgend werden<br />
die drei zur Zeit wichtigsten Vorgehensweisen auf diesem Gebiet etwas ausführlicher vorgestellt: MARIA,<br />
als Fortführung <strong>von</strong> CTT und TERESA, UsiXML, als aktuelles EU-gefördertes Forschungsprojekt und<br />
XIML, ein kommerziell erfolgreicher Ansatz.<br />
MARIA<br />
MARIA führt die Ideen <strong>von</strong> TERESA fort, es ist in vielerlei Hinsicht deren Nachfolger. Im Kern verfolgt<br />
MARIA den selben modularen Aufbau und nutzt die gleichen Abstraktionsebenen.<br />
Nach Aussage der Entwickler [88] konzentriert sich das MARIA-Projekt auf die Modellierung <strong>von</strong> <strong>Benutzungsoberflächen</strong><br />
für Web-Service basierte Anwendungen. Das Projekt ruht auf zwei Säulen, dem MARIA-<br />
Tool und der Sprache MARIA-XML. MARIA-XML dient der Deklaration abstrakter Oberflächen, die<br />
Modellierung der eigentlichen konkreten User Interfaces wird wie bei TERESA externen XML-Sprachen<br />
übertragen. MARIA-Tool ist sowohl Modelleditor als auch Transformations- und Laufzeitumgebung.<br />
Kurzname CAMELEON Bezeichnung<br />
AUIML CUI Abstract User Interface Markup Language<br />
AMF TC, AUI Agents Multi-Facets<br />
GIML CUI Generalized Interface Markup Language<br />
ISML TC, CUI Interface Specification Meta Langugae<br />
IM 2 L AUI Interaction Multimodal Markup Language<br />
MARIA TC,AUI,CUI Model Based Language For Interactive Applications<br />
TERESA TC, AUI Transformation Environment for Interactive Systems Representations<br />
T:XML CUI —<br />
UIML CUI User Interface Markup Language<br />
useML AUI Useware Markup Language<br />
UsiXML AUI,CUI User Interface Extensible Markup Language<br />
VRIXML CUI Virtual Reality Interaction XML<br />
WML CUI Wireless Markup Language<br />
X3USGP AUI, CUI XML-based User Interface Specification and Generation Process<br />
XAML CUI Extensible Application Markup Language<br />
XIML CUI Extensible Interface Markup Language<br />
XUL CUI XML User Interface Language<br />
Tabelle 1.1: Aufzählung bekannterer XML-basierter Sprachen zur UI-Definition
16 KAPITEL 1. EINLEITUNG<br />
Rücktransformation<br />
Abstrakte<br />
UI<br />
Konkrete<br />
UI<br />
Existente<br />
FUI-Instanz<br />
Semantisches<br />
Redesign<br />
Statuserhaltung<br />
<strong>Generierung</strong><br />
Abstrakte<br />
UI<br />
Konkrete<br />
UI<br />
Generierte<br />
FUI-Instanz<br />
Abbildung 1.6: Modellzusammenhänge im MARIA-Migrationsprozess, nach [88]<br />
Erfahrungen aus dem TERESA-Projekt haben Paternò und seinen Kollegen gezeigt das die ausschließliche<br />
Fokussierung auf das Aufgabenmodell den Möglichkeiten und Anforderungen an moderne User Interfaces<br />
nicht gerecht wird. MARIA-XML führt daher gegenüber seinem TERESA-Pendant eine Reihe zusätzlicher<br />
Konzepte ein.<br />
Mit MARIA-XML gibt es nun ein explizites Datenmodell für die <strong>von</strong> der UI dargestellten Daten. Im<br />
Grunde entspricht dies der Einführung eines Domänenmodells, wie es ja auch in den klassischen Verfahren<br />
(siehe Unterabschnitt 1.2.3) vielfach benutzt wird. Mit der Einführung eines Event-Konzeptes, auf der<br />
Ebene der Interface-Deklaration, wird der UI-Kontrollfluss in die Sprache integriert. In den Grundzügen<br />
ist dieses Konzept mit dem Ereignis-System <strong>von</strong> Humanoid, siehe Seite 122, vergleichbar.<br />
Dazu kommen weitere Zugeständnisse an real existierende Oberflächensysteme. So ist es in MARIA-XML<br />
Deklarationen möglich, bestimmte Interaktionselemente als kontinuierlich-aktualisierend zu markieren.<br />
Als besonders nützlich wird diese Annotation in Zusammenhang mit AJAX 16 bezeichnet; seine Einführung<br />
wirkt daher zunächst wie eine Konzession an den Web 2.0-Hype hat aber dennoch das Potential, in<br />
späteren Ausbaustufen für vielerlei Zwecke nützlich zu sein.<br />
Teile der mit MARIA-XML beschriebenen Oberflächen können als dynamisch austauschbar deklariert werden.<br />
Die alternativen Darstellungen werden dazu als Komponenten vordeklariert und aufgrund definierter<br />
Einsatzbedingungen oder durch explizite Auswahl eingesetzt.<br />
Die bereits mit TERESA begonnenen „Migratory Interfaces“ , siehe Unterabschnitt A.4.1, werden auch bei<br />
MARIA weiter betrachtet, allerdings aus einem leicht anderen Blickwinkel. Da die UI-Sprache MARIA-<br />
XML bereits Datenmodell und Kontrollfluss enthält, bietet ein übergeordnetes CTT-Aufgabenmodell kaum<br />
zusätzlichen Informationsgewinn für die Übertragung <strong>von</strong> Oberflächenzuständen zwischen verschiedenen<br />
Geräten. Die Migration setzt daher nur noch auf die unteren drei CAMELEON-Ebenen auf. Den Zusammenhang<br />
der Modelle in diesem Prozess zeigt Abbildung 1.6. Darin visualisieren Pfeile, ähnlich wie bei<br />
den Darstellungen des CAMELEON-Referenzframeworks, die Richtung des Informationsflusses, es handelt<br />
sich nicht notwendigerweise um Modelltransformationen.<br />
Für MARIA-XML wird mittelfristig die Standardisierung durch ECMA oder W3C angestrebt. Ein diese<br />
16 Asynchrones JavaScript und XML
1.3. INTERAKTIONSDEFINITION MIT XML-DERIVATEN 17<br />
Richtung vorbereitender Workshop 17 fand im Mai 2010 in Rom statt.<br />
UsiXML<br />
UsiXML zählt ebenfalls zu den einflussreicheren XML UIDLs. Veröffentlichungen über und zu UsiXML<br />
finden sich zahlreich seit 2004, z.B. [140]. Die Sprache wurde im Jahr 2006 dem W3C zur Standardisierung<br />
vorgeschlagen.<br />
UsiXML ist nicht nur eine Sprachdefinition, es ist ein vollständiges Framework zur Durchführung modellgetriebener<br />
Entwicklung <strong>von</strong> <strong>Benutzungsoberflächen</strong>. Dementsprechend gehören zum UsiXML-Projekt<br />
diverse Editoren, Werkzeuge und Laufzeitumgebungen.<br />
Ein bemerkenswerter Unterschied zwischen UsiXML und anderen, auf dem MDA-Konzept der OMG beruhenden<br />
Systemen ist, dass UsiXML auf Graphtransformationen setzt. Statt Sequenzen <strong>von</strong> Model-To-<br />
Model Transformationen abzuarbeiten, wird bei UsiXML immer der Baum des XML-Dokumentes transformiert.<br />
In der Konsequenz bleibt man also immer in derselben Modellinstanz.<br />
Dennoch werden in einem UsiXML-Dokumente eine Reihe <strong>von</strong> Teilmodellen unterschieden, in Abbildung<br />
1.7 sind alle vorgesehenen Teilmodelle dargestellt. Selbstverständlich ist es nicht erforderlich das<br />
für eine einzelne Oberflächenbeschreibung alle Teilmodelle instanziiert werden. Für ein Minimalmodell<br />
genügt die Definition einer einzelnen CUI-Instanz.<br />
Die Teilmodelle decken alle oberen Ebenen des CAMELEON-Frameworks ab. Im UsiXML-Ansatz gibt es<br />
jedoch keine explizite FUI-Ebene. Die Laufzeitumgebungen interpretieren direkt die Instanzen der CUI.<br />
Das UsiXML-Projekt ist <strong>von</strong> Anfang an sehr ambitioniert angelegt. Leider haben aus meiner Sicht wichtige<br />
Teile des Frameworks nicht die notwendige Reife entwickelt. Im Rahmen einer studentischen Arbeit [147]<br />
wurde UsiXML als CUI-Modell für den Rostocker USGP [78]-Ansatz genutzt. Es erwies sich jedoch als<br />
schwierig die generierten, und nachprüfbar standardkonformen, Oberflächenbeschreibungen in den verfügbaren<br />
UsiXML-Renderern darstellen zu lassen.<br />
Einzelne Teilmodelle <strong>von</strong> UsiXML lassen sich kaum sinnvoll in das CAMELEON-Framework einordnen.<br />
Das Ressourcen-Modell etwa, ein Datencontainer für die Kontextanpassung <strong>von</strong> UI-Resourcen. Bei<br />
17 http://www.w3.org/2010/02/mbui/cfp.html<br />
Abbildung 1.7: Klassendiagrammdarstellung des UsiXML-Schema, nach [139]
18 KAPITEL 1. EINLEITUNG<br />
wechselnden Kontexten, die naturgemäß im Kontext-Modell beschrieben sind, werden die Interaktionselemente<br />
gemäß den Informationen aus dem Ressourcen-Modell adaptiert. Die bis dato einzig funktionierende<br />
Kontext-Resourcenkombination ist die Internationalisierung <strong>von</strong> Teilen der Oberfläche. Beschriftungen<br />
und andere Texte können bei Sprachwechseln entsprechend übersetzt angezeigt werden, verantwortlich<br />
dafür ist allein die Laufzeitumgebung, dieser Mechanismus wird ohne Graphtransformationen umgesetzt.<br />
Von den übrigen Teilmodellen werden Mapping- und Transformationsmodell dazu genutzt, die Graphentransformationen<br />
in UsiXML selbst zu beschreiben. Sie enthalten daher Knotenselektoren für das Matching,<br />
Ergebniskonfigurationen sowie Anwendbarkeitsbedingungen.<br />
An der Weiterentwicklung <strong>von</strong> UsiXML wird aktuell gearbeitet. Angefangen im April 2009, läuft ein gesamteuropäisches<br />
Projekt mit dreieinhalbjähriger Laufzeit und 28 Partnern aus Industrie und Wissenschaft<br />
mit dem Ziel ein neues UsiXML zu spezifizieren und mit Werkzeugunterstützung zu versehen. Dieses<br />
ITEA 18 -Projekt definiert sich selbst folgendermaßen [133]:<br />
„The UsiXML project develops an innovative model driven language to improve the UI design,<br />
for the benefit of both industrial end-users actors in term of productivity & reusability;<br />
usability & accessibility by supporting the „μ7“ concept: multi-device, multi-user multiculturality/linguality,<br />
multi-organisation, multicontext, multi-modality and multi-platform.“<br />
Über die endgültige Ausgestaltung des überarbeiteten UsiXML kann zum gegenwärtigen Zeitpunkt noch<br />
keine Aussage getroffen werden. Wenn das Projektziel erreicht und ein stabiles Fundament für MB-UID<br />
geschaffen wird, könnte UsiXML zu einem gewichtigen Standard der nächsten Jahre oder Jahrzehnte werden.<br />
XIML<br />
XIML ist die Fortführung des bereits vorgestellten MECANO-Ansatzes. Begonnen hat XIML 1998 als<br />
XML-Variante <strong>von</strong> MIMIC, der ursprünglichen MECANO-Modellierungssprache. Es zählt damit zu den<br />
Vorreitern der XML-Verwendung bei der MB-UID.<br />
Gemäß der MECANO-Idee definiert XIML nur die Schnittstellen der Mensch-Maschine-Kommunikation.<br />
Zusammenfassend gesagt: Welche Aktionen und Informationen einem Nutzer bereitgestellt werden, welche<br />
Domänenobjekte dabei betroffen sind und welche Interaktionskomponenten prinzipiell zur Verfügung<br />
stehen. XIML ist jedoch keine UIDL. Dies hat insbesondere zur Folge das damit keine CUI oder FUI-<br />
Instanzen beschrieben werden können. Modellinstanzen benötigen immer eine Laufzeitumgebung die den<br />
Modellzusammenhang interpretiert und eine geeignetes Interface erstellt.<br />
Soweit bekannt wird an XIML weiterhin gearbeitet und eine Standardisierung angestrebt. Aufgrund der<br />
kommerziellen Interessen der, hinter XIML stehenden, Firma „RedWhale Inc“, ist die Verwendung <strong>von</strong><br />
XIML bisher nur eingeschränkt möglich. Nach Aussage <strong>von</strong> Angel Puerta, im Rahmen seiner Präsentation<br />
<strong>von</strong> [95], sollte im Oktober 2009 die Veröffentlichung <strong>von</strong> XIML 2.0 erfolgen. Dies ist nicht erfolgt.<br />
Zumindest war es bei dieser Gelegenheit möglich einen Blick auf die aktuelle Laufzeitumgebung namens<br />
„UI-Fin“zu werfen. UI-FIN wird demnach zur Zeit für genutzt, um Software im Umfeld <strong>von</strong> Krankenhäusern<br />
zu erstellen.<br />
Puertas bereits zitierte Anforderung, siehe Punkt 1.2.3.4, dass MB-UID zwingend ein gut ausgearbeitetes<br />
und vielseitiges Metamodell für CUI bzw. FUI benötigt, gilt natürlich auch für seine eigenen Arbeiten.<br />
Hier kam er letztlich zu dem Schluss, dass die Entwicklung, Fortführung und Wartung eines solchen Metamodells<br />
und besonders auch der zugehörigen Renderer die Kapazitäten einzelner Forschungsgruppen oder<br />
18 Information Technology for European Advancement
1.3. INTERAKTIONSDEFINITION MIT XML-DERIVATEN 19<br />
mittelständischer Firmen überfordern.<br />
Seine Lösung besteht darin, die Laufzeitumgebung nicht mehr als Renderer und Applikationsumgebung zu<br />
verwenden, sondern als Generator für Interfacedeklarationen etablierter XML-UIDLs. RedWhale Inc. setzt<br />
zur Zeit auf Microsoft, daher erstellt UI-FIN aus XIML-Instanzen XAML-<strong>Benutzungsoberflächen</strong>. Diese<br />
lassen sich in .Net-Anwendungen integrieren und ansteuern.<br />
XAML und eine Auswahl anderer XML-basierter UIDLs werden im nachfolgenden Punkt 1.3.1.2 erklärt.<br />
Prinzipiell ließe sich wohl jede dieser UIDLs in der aktuellen Ausprägung des XIML-Ansatzes als CUI-<br />
Modell verwenden.<br />
1.3.1.2 User Interface Definition Languages<br />
In diesem Unterkapitel werden XML-Sprachen vorgestellt die primär auf die Beschreibung <strong>von</strong> realen Nutzerschnittstellen<br />
ausgerichtet sind. Es existiert eine Vielzahl solcher Sprachen. Die schon erwähnte Übersicht<br />
[134] listet neun veröffentlichte UIDLs 19 auf, für die nachgewiesenermaßen auch Renderer verfügbar<br />
sind. Darüberhinaus existieren weitere XML-UIDLs die in [134] nicht erwähnt werden. Beispielhaft sei<br />
SwiXML [89] genannt, eine Möglichkeit Java Swing UIs per XML-Dialekt zu deklarieren.<br />
Urahn der Forschungssprachen zur deklarativen Oberflächenbeschreibung mit XML ist das in Unterabschnitt<br />
A.4.2 erläuterte UIML, diese Sprache konnte sich letztlich jedoch nicht durchsetzen.<br />
Von überragender Bedeutung für diese Arbeit ist XUL – die XML User Interface Language <strong>von</strong> der Mozilla<br />
Corporation. Mit dieser Sprache werden unter anderem die <strong>Benutzungsoberflächen</strong> der sogenannten<br />
Web-Suite SeaMonkey und des derzeit populären Browsers Firefox beschrieben. XUL und die damit gesammelten<br />
Erfahrungen werden, im Rahmen der Vorstellung der Forschungsergebnisse, in Punkt 2.1.4.1<br />
detaillierter vorgestellt.<br />
XAML<br />
Microsofts XAML [76] ist eine Möglichkeit innerhalb des .Net-Frameworks <strong>Benutzungsoberflächen</strong> der<br />
Windows Presentation Foundation (WPF) XML-basiert zu deklarieren. Das .Net-Framework ist in der Lage<br />
zur Laufzeit einer Anwendung XAML-Deklarationen nachzuladen und darzustellen und darüberhinaus<br />
ein Data Binding zu aktuellen Instanzen des Domänenmodells herzustellen. Mit XAML lassen sich daher<br />
lauffähige funktionale WIMP-Oberflächen beschreiben wobei die Anwendungslogik über eine beliebige<br />
.Net-Sprache implementiert werden kann. Mit XAML und der .Net-Integration verfolgt Microsoft ein sehr<br />
interessantes Konzept. Es dürfte lohnenswert sein, bei künftigen MD-UID Entwicklungen XAML zu berücksichtigen.<br />
MXML<br />
Adobes MXML [2] vervollständigt das Trio der industriell gepflegten und mit einem verbreiteten Renderer<br />
ausgestatteten XML UIDLs. Veröffentlicht wurde es 2004 <strong>von</strong> der damals noch eigenständigen Firma<br />
Macromedia. Normalerweise werden MXML-Oberflächen in das Binärformat SWF 20 kompiliert und dann<br />
durch Flash-Player gerendert.<br />
In MXML-Dokumente können komplette Applikationen deklariert werden. Die Anwendungslogik wird<br />
dabei durch eingebettetes ActionScript bereitgestellt. Ansonsten lassen sich die wichtigen Aspekte einer<br />
CUI festlegen; die verwendeten Widgets, deren Aussehen und Anordnung, sowie das Data-Binding an<br />
19 VRML,X3D,MXML,XAML,XUL,VOICEXML,GIML,SUNML,UIML<br />
20 Shockwave Flash
20 KAPITEL 1. EINLEITUNG<br />
Objekte des Domänenmodells als Datenquellen.<br />
Die aus meiner Sicht gravierendste Einschränkung <strong>von</strong> MXML ist die Tatsache, dass scheinbar kein interpretierender<br />
Renderer zur Verfügung steht und somit immer eine Kompilierung in das Flash-Format<br />
erforderlich ist. Dies erschwert die Einbettung in andere Applikationen, was im Rahmen der MD-UID<br />
wünschenswert wäre, erheblich.<br />
Sonstige WIMP-UIDLs<br />
Eine weitere XML-UIDL ist WML - die Wireless Markup Language [143]. WML entstammt einer Zeit<br />
in der die Fähigkeiten mobiler Endgeräte noch nicht weit genug entwickelt waren um übliche HTML-<br />
Webseiten darzustellen. Für diese Endgeräte wurde daher vom W3C eine eigene Sprache mit reduziertem<br />
Funktionsumfang spezifiziert, spezielle Rücksicht wurde auf kleine Displays, geringen Speicherausbau<br />
und schmalbandige Anbindung genommen. Dabei ist WML weder eine Untermenge <strong>von</strong> HTML noch <strong>von</strong><br />
XHTML.<br />
Zentrales Konzept WMLs ist die Kartenmetapher, eine Webseite wird jeweils komplett als Aggregation<br />
einzelner Karten, auch als Kartendeck bezeichnet, übertragen. Auf dem Endgerät wird immer genau eine<br />
Karte angezeigt; jede Karte kann Text, Steuerelemente oder auch multimediale Elemente enthalten. Das<br />
Navigieren auf einer Webseite entspricht dann dem Austauschen der jeweils angezeigten Karte.<br />
Ein anderes Beispiel ist die Forschungssprache GIML [70], die im Rahmen einer Promotion an der TU<br />
Dresden entstand. Konzeptioneller Rahmen ist die Erstellung eines generischen Interface Toolkits, GITK<br />
genannt, für WIMP-Oberflächen. GITK wird als Meta-Framework bezeichnet, als ein Wrapper um andere,<br />
dadurch austauschbar werdende, Toolkits wie etwa GTK oder QT.<br />
GIML übernimmt im GITK-Framework die Deklaration der Oberflächenkomponenten. Die Sprache wurde,<br />
nach Betrachtung existierender XML UIDLs, <strong>von</strong> Grund auf neu entworfen. Zur Begründung der Notwendigkeit<br />
einer neuen Sprache führt der Autor Stefan Kost bei [70] an, dass vorhandene UIDLs zu viele<br />
Sprachelemente beinhalten, welche inkonsistent benannt sind und ein unausgewogenes Verhältnis <strong>von</strong><br />
Element-Tags und Attributen aufweisen.<br />
Diese Kritik teile ich nur bedingt. Sie scheint ungerechtfertigt, insbesondere da er selbst das Sprachdesign<br />
<strong>von</strong> GIML als „demand driven“ bezeichnet; dies meint, dass nach und nach genau solche UI-Elemente<br />
in GIML eingeführt werden welche er selbst benutzt. Diese Vorgehensweise führt geradezu mit Sicherheit<br />
zu Inkonsistenzen und läuft aus meiner Sicht auch dem Anspruch einer generischen Sprache zuwider. Die<br />
Entwicklung <strong>von</strong> GITK und GIML im Besonderen scheint mit Abschluss der Dissertation eingestellt.<br />
SwiXML [89], ToolkitModel [46] und XWT [11] sind drei gleichartige XML-UIDLs die ich an dieser<br />
Stelle noch erwähnen möchte. Bei XML-Dokumenten in diesen Sprachen handelt es sich eher um XML-<br />
Serialisierungen <strong>von</strong> Oberflächendeklarationen mit bekannten objektorientierten Frameworks, denn um eigenständige<br />
UI-Modellierungssprachen. Die Nutzung dieser Sprache erfolgt prinzipiell ähnlich dem bereits<br />
beschriebenen XAML.<br />
Statt Java-Quellcode für Swing-Oberflächen zu implementieren, kann mit SwiXML die Oberfläche als<br />
XML-Dokument deklariert werden und dieses zur Laufzeit in Swing-Objekte und damit einer Benutzungsoberfläche<br />
umgesetzt werden. Ähnliches gilt für XWT, dem XML Windowing Toolkit, jedoch wird<br />
hier SWT genutzt. Das sogenannte ToolkitModel ist im Moment Bestandteil <strong>von</strong> Eclipse E4, es abstrahiert<br />
vom konkreten Toolkit und unterstützt dadurch die <strong>Generierung</strong> sowohl <strong>von</strong> Swing als auch SWT-<br />
Applikationen; das ToolkitModel ist gewissermaßen eine Fortführung der Ideen aus dem eingestellten<br />
AUIML [12]-Projekt <strong>von</strong> IBM.
1.3. INTERAKTIONSDEFINITION MIT XML-DERIVATEN 21<br />
Nicht-WIMP UIDLs<br />
Selbstverständlich existieren XML-Deklarationssprachen auch speziell für User Interfaces die andere Interaktionsmetaphern<br />
bzw. Modalitäten verfolgen. Da sie sich damit zumeist außerhalb des WIMP-Bereichs<br />
bewegen haben diese Sprachen mit dem Themenbereich dieser Arbeit nur am Rande zu tun.<br />
SVG - Scalable Vector Graphics - ist ein Beispiel für eine solche Sprache. Standardisiert [118] durch<br />
das W3C, wird SVG genutzt um zweidimensionale Vektorgrafiken und Animationen solcher Grafiken zu<br />
beschreiben. Prinzipiell handelt es sich um eine unidirektionale Visualisierungsschnittstelle. Nutzerinteraktionen<br />
sind seitens SVG nicht definierbar. Allerdings kann SVG wegen seiner XML-Abstammung leicht<br />
in andere XML-UIDLs integriert werden. Beispielsweise haben wir SVG in XUL-UI-Deklarationen [153]<br />
eingebettet. Durch diese Herangehensweise lassen sich Nutzerinteraktionen auf SVG-Oberflächenbeschreibungen<br />
steuern.<br />
Eine gänzlich andere Modalität unterstützt VoiceXML [142] - die Voice Extensible Markup Language -<br />
ebenfalls durch das W3C standardisiert. Gemäß des Abstract in [142] ist VoiceXML eine modulare Sprache<br />
zur Erstellung interaktiver Dialoge welche Sprachsynthese, Sprach- und Tonwahlerkennung oder sonstige<br />
digitale Audio- und Videodaten verwenden. Eine regelmäßige Anwendung <strong>von</strong> VoiceXML ist, unter dem<br />
Namen „X+V“, die Einbettung <strong>von</strong> VoiceXML-Konstrukten in XHTML. Paternò und andere an TERESA<br />
Beteiligte haben sich unter anderem in [13] mit der Benutzung <strong>von</strong> X+V im modellgetriebenen Kontext<br />
beschäftigt.<br />
Als letztes Beispiel soll hier noch VRIXML [27] - Virtual Reality Interaction XML - genannt werden. Deren<br />
Einsatzkontext sind 3-dimensionale virtuelle Umgebungen. Soweit aus den Veröffentlichungen ersichtlich<br />
kommen bei VRIXML letztlich typische WIMP-Widgets zum Einsatz, ergänzt um Positionierungsund<br />
Ausrichtungsangaben in einer 3D-Welt. Das Prinzip ist jedoch offen für Erweiterungen, wie etwa spezialisierte<br />
3-dimensionale Widgets.<br />
Andere Aspekte <strong>von</strong> XML-Technologien bei UIDLs<br />
Eine Reihe bekannterer Ansätze benutzt XML-Technologien um aus eigenen Deklarationen Oberflächenbeschreibungen<br />
mit den beschriebenen XML-UIDLs zu erzeugen. useML [103] aus dem Useware-Ansatz<br />
zählt in diese Kategorie. In der ursprünglichen Fassung [103] <strong>von</strong> 2003 handelt es sich um ein Beschreibungsmittel<br />
für betriebliche Abläufe. Es wird der Zusammenhang zwischen Arbeitsmitteln und Werkzeugen<br />
im Produktionsprozess XML-basiert beschrieben. Wofür Konzepte wie Funktionen, Nutzer, Vorgabewerte<br />
und -belegungen und ähnliches genutzt werden. Mittels XSL-Transformationen, siehe Punkt 2.2.1.1,<br />
werden diese useML-Deklarationen später in diverse FUIs überführt. Das bei [131] veröffentlichte Beispiel<br />
enthält Transformationen für verschiedene webbasierte Endgeräte; WML und verschiedene HTML-<br />
Ausprägungen, diese differieren je nach Fähigkeiten des Ziel-Endgerätes. Erwähnenswert an dieser Version<br />
<strong>von</strong> useML ist, dass die Sprache deutschsprachige XML-Tags benutzt, überwiegend werden englischsprachige<br />
Bezeichner gewählt. An useML, und generell an dem Useware-Ansatz für die intelligente Fabrik,<br />
wird weiterhin gearbeitet. In neueren Sprachversionen, ersichtlich in Veröffentlichungen wie [15], erfolgte<br />
eine Umstellung auf einen mehrstufigen, in CAMELEON einordbaren, Prozess.<br />
Die spanische Universität La Mancha stellte 2009 [101] einen eigenen Ansatz zum besseren Umgang mit<br />
UsiXML, und letztlich allen anderen XML-UIDLs, vor. Sie identifizierten in der bisherigen Verwendung<br />
dieser Sprache einen Mangel an Anpassbarkeit der engültigen Oberfläche. Ihr Ansatz ist, dass sich <strong>Benutzungsoberflächen</strong><br />
im Laufe der Zeit schrittweise verändern, eine parallele Weiterentwicklung und -<br />
benutzung des ursprünglichen UsiXML-Dokumentes jedoch so nicht vorgesehen ist.<br />
Diese Lücke versucht T:XML zu füllen, es handelt sich um ein Werkzeug das mit einem Metamodell für
22 KAPITEL 1. EINLEITUNG<br />
Modelltransformationen arbeitet. Genau wie die Transformationsregeln innerhalb UsiXML, werden die<br />
schrittweisen Anpassungen über Graphentransformationen definiert und dann in Instanzen des T:XML-<br />
Metamodells abgelegt. Aus diesen Instanzen wird XSLT, oder später womöglich QVT, generiert; mit diesen<br />
Techniken wird dann die eigentliche Transformation des UsiXML-Ausgangsmodells vorgenommen. Bei<br />
der Vorgehensweise nach T:XML handelt es sich um eine einigermaßen spezielle Lösung des Problems<br />
der Modellversionierung. Der Ansatz ist für Spezialprobleme der Anpassung an diverse Nutzungskontexte<br />
sicherlich nützlich und die Entwicklung eines vereinheitlichten Metamodells für Modelltransformationen<br />
wäre auch sehr wertvoll, diese Arbeiten stehen aber zur Zeit noch am Anfang.<br />
1.3.2 Schlußfolgerung<br />
Die Modellierung und Deklaration <strong>von</strong> Benutzungsschnittstellen ist eine seit mehr als 12 Jahren erprobte<br />
Technik. Aus den Anfängen XIML, UIML und XUL hat sich eine Vielzahl, teils erfolgreicher und oft<br />
genutzter, Sprachen mit interessanten und weitgespannten Einsatzbereichen entwickelt. Darüberhinaus hat<br />
XML seine Eignung auch für User Interfaces bewiesen die nicht das WIMP-Paradigma einsetzen.<br />
Wegen ihres deklarativen Charakters eigenen sich die XML-UIDLs besonders zur Verwendung in einem<br />
modellbasierten oder -getriebenen Entwicklungsprozess. Einige vorgestellte Frameworks und Systeme die<br />
XML-Technologien auch für höhere Abstraktionsebenen anwenden unterstreichen dies. Im nachfolgenden<br />
Kapitel wird der an der Universität Rostock verfolgte Prozess detailliert vorgestellt. Darin spielt die XML-<br />
UIDL XUL eine wichtige Rolle, eingesetzt als Haupt-Deklarationssprache für konkrete Oberflächen.
Kapitel 2<br />
Modellgetriebene <strong>Generierung</strong> <strong>von</strong><br />
<strong>Benutzungsoberflächen</strong><br />
In diesem Kapitel werden Metamodelle und deren Einsatz in einem konkreten Vorgehens- oder Prozessmodell<br />
zur modellgetriebenen Erzeugung <strong>von</strong> User Interfaces erläutert. Dies ist Gegenstand des nachfolgenden<br />
Abschnittes. In den daran anschließenden Abschnitten werden die Grenzen des Ansatzes diskutiert sowie<br />
die eingesetzten Techniken kurz dargestellt.<br />
2.1 Beschreibung des Rostocker Prozessmodells<br />
In diesem Abschnitt werden die grundsätzlichen Möglichkeiten der <strong>Generierung</strong> <strong>von</strong> Nutzeroberflächen auf<br />
der Grundlage <strong>von</strong> Modellen diskutiert. Den Schwerpunkt dieser Betrachtungen werden Modelle bilden,<br />
die zur Deklaration typischer WIMP-Oberflächen dienen. Inwieweit diese Beschränkung möglicherweise<br />
die allgemeine Verwendbarkeit des präsentierten Gesamtprozesses herabsetzt, wird in Unterabschnitt 5.2.1<br />
erörtert.<br />
Automatisch oder Semi-Automatisch<br />
Ein immer wieder hervortretender Problemkreis bei modellbasierten und modellgetriebenen Konzepten ist<br />
die Frage nach dem Grad der Automatisierung des Entwicklungsprozesses. Es gibt, zumindest im Bereich<br />
der UI-Modelle, keine allgemein akzeptierte Fixierung <strong>von</strong> Automatisierungsgraden. Dennoch lassen sich<br />
drei Schwerpunkte identifizieren:<br />
manuell: Sämtliche Transformationen und Entscheidungen werden durch menschliche Designer vorgenommen.<br />
Diese Situation wird nicht weiter betrachtet.<br />
semi-automatisch: Injektive und surjektive Transformationen werden automatisiert vorgenommen. Entscheidungen<br />
bei Mehrdeutigkeiten sind Prozessbestandteil und werden durch menschliche Designer<br />
vorgenommen.<br />
automatisch: Wie semi-automatisch, jedoch werden notwendige Auswahlentscheidungen durch Heuristiken,<br />
Constraints oder sonstige Entscheidungsmodelle getroffen.<br />
23
24 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Neben der Betrachtung der reinen Transformationen könnte, zur Unterscheidung zwischen automatisiert<br />
und semi-automatisiert, auch noch die Frage der Durchführung einer Endaufbereitung herangezogen werden.<br />
Damit ist gemeint, inwieweit die Resultate der Transformationen vor ihrer Verwendung, einer Nachbearbeitung<br />
durch menschliche Designer unterzogen werden sollen. Dazu ist jedoch zu bemerken, dass bei<br />
allen bekannteren Techniken eine wie auch immer geartete nachträgliche Anpassung des erzielten Transformationsergebnisses<br />
vornehmbar ist. Dies degradiert das Kriterium der Nachbearbeitbarkeit zu einem<br />
Aspekt mit nurmehr sehr schwacher Unterscheidungswirkung. Aus diesem Grund wurde es bei der obigen<br />
Charakterisierung der drei Schwerpunkte ausgelassen.<br />
Der überwiegende Teil der Forschungen zu MDD-UI geht da<strong>von</strong> aus, dass semi-automatische Transformationsprozesse<br />
die beste Alternative darstellen. Bereits in einer Veröffentlichung [119] <strong>von</strong> 1992 schreiben<br />
Luo, et. al:<br />
„Most difficult design decisions are best left to the human designer, as they require knowledge<br />
which is more easily and quickly modelled by humans than by a system. E.g. knowledge about<br />
end-users and application domain.“<br />
Demnach sollen die schwierigsten Entscheidungen im Design einer Anwendung menschlichen Designern<br />
überlassen werden. Begründet wird dies damit, dass Menschen über Wissen über den Anwendungsbereich<br />
und die späteren Endnutzer verfügen, welches in einem Modellsystem nur schwierig und mit hohem Zeitaufwand<br />
beschreibbar ist.<br />
Ansätze zur Vollautomatisierung finden sich beispielsweise bei TEALLACH (siehe Unterabschnitt A.2.2),<br />
aber auch bei den Enabling Task Sets (ETS) im Rahmen der CTTE. David Paquettes Veröffentlichung [86]<br />
stellt Techniken rund um die automatisierte <strong>Generierung</strong> <strong>von</strong> Oberflächen aus Aufgabenmodellen dar, ETS<br />
spielen in diesem Kontext die wichtige Rolle des Navigationsmodells. Leider ist die Qualität der Ergebnisse<br />
vollautomatischer Transformationen derzeit selbst auf niedrigem Niveau als bescheiden zu bezeichnen.<br />
Prozessübersicht<br />
Meine Arbeit ordnet sich in den Kontext des an der Universität Rostock verfolgten und in Abbildung 2.1<br />
gezeigten Ansatz zur Erstellung <strong>von</strong> <strong>Benutzungsoberflächen</strong> ein. Es handelt sich hierbei um einen hybriden<br />
Ansatz, welcher auf den Arbeiten zum TADEUS-Projekt aufbaut, siehe Unterabschnitt A.3.4. Neben der<br />
Betrachtung der zu erzeugenden Benutzungsschnittstelle werden ebenfalls Transformationen <strong>von</strong> Modellen<br />
zur <strong>Generierung</strong> und Erstellung der Anwendungslogik im Prozess integriert. Klassifiziert werden kann<br />
dieses Vorgehensmodell als semi-automatisches modellgetriebenes Prozessmodell. Die Entscheidungen,<br />
welche menschliche Designer im Rahmen dieses Modells zu treffen haben sind vielfältig. Bei den Erläuterungen<br />
zu den einzelnen Sub-Modellen wird auf den Einfluss des menschlichen Faktors eingegangen.<br />
Im Rostocker-Ansatz werden vier Quellmodelle betrachtet. Im Zentrum steht das Aufgabenmodell. Hier<br />
erfolgt eine Zerlegung des Anwendungsziels in atomare Teilaufgaben. Über die Definition temporaler Abhängigkeiten<br />
zwischen diesen Teilaufgaben, werden auf abstrakter Ebene die möglichen Abläufe in der<br />
späteren Anwendung modelliert. Relevante Charakterisierungen der späteren Endbenutzer werden im Nutzermodel<br />
vorgenommen. Der Kontext in welchem die Anwendung später eingesetzt ist, wird über das<br />
Domänenmodell spezifiziert. Alle Artefakte die durch die Anwendung benutzt oder modifiziert werden<br />
definiert das Objektmodell der Geschäftslogik. Den inneren Zusammenhang zwischen diesen vier Quellmodellen<br />
stellt das Aufgabenmodell, über Referenzen, bereit.<br />
Transformationen der Quellmodelle führen über Zwischenmodelle zu zwei Ergebnismodellen. Dies sind<br />
das Anwendungsmodell und das Modell des konkreten Interfaces. Durch Kombination beider Modelle soll
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 25<br />
Geschäftslogikobjekte<br />
Aufgabenmodell<br />
Domänenmodel<br />
Nutzermodell<br />
Klassendiagramm<br />
(Analyse)<br />
Dialoggraph<br />
Zusammenhang<br />
Transformation<br />
patternbasiert<br />
Klassendiagramm<br />
(Design)<br />
Abstraktes<br />
Interface<br />
Anwendungsmodell<br />
Konkretes<br />
Interface<br />
Abbildung 2.1: Transformationsorientierter MDD-Entwicklungsprozess<br />
schließlich mittels geeigneter Model-To-Text Transformationen ausführbarer oder interpretierter Quellcode<br />
erzeugt werden.<br />
Nun besteht zwischen den Quellmodellen und lauffähigem Quellcode ein erhebliches Abstraktionsgefälle.<br />
Sämtliche auf den höheren Abstraktionsebenen nicht betrachtete Informationen müssen daher im Verlauf<br />
des Transformationsprozesses hinzugefügt werden. Diesem Zweck dienen die Zwischenmodelle.<br />
Die Modellierung des Anwendungsmodells soll dabei ausgehend <strong>von</strong> den Quellmodellen über die Schritte<br />
Analysemodell und Designmodell erfolgen. Bei dem Analysemodell handelt es sich um ein Klassenmodell,<br />
welches die Erkenntnisse aus Nutzer-, Geschäftsbjekt- und Domänenmodell zu einem Klassenmodell<br />
kondensiert. Das Designmodell ist im gewissen Sinne die Konsolidierung des Analysemodells in Hinblick<br />
auf Umsetzbarkeit. Durch Transformation des Designmodells wird das Anwendungsmodell erzeugt. Hinter<br />
diesem Transformationspfad stehen also Standardvorgehensweisen der Softwaretechnik zur Ableitung <strong>von</strong><br />
Anwendungsmodellen aus den Ergebnissen des Requirements Engineering. Einzelheiten dazu werden im<br />
Rahmen dieser Arbeit nicht betrachtet.<br />
Stattdessen soll der untere Transformationspfad ausgearbeitet werden. Die Modell-Sequenz lautet hier:<br />
Quellmodelle →Dialoggraph→Abstrakte Oberfläche→Konkrete Oberfläche. Die möglichen Hindernisse<br />
auf dem Weg vom Aufgabenmodell zu lauffähigem Quellcode sind manigfaltig. Das zu überwindende<br />
Problem kann als Versuch zusammengefasst werden, eine Zeichenkette schrittweise zu einem semantisch<br />
passenden ausgestalteten Oberflächenelement zu transformieren.<br />
Diese Ausgangszeichenkette ist der Name der jeweiligen Teilaufgabe, der eine grafische Darstellung zuzuordnen<br />
ist. Beispielsweise sollte eine Aufgabenbeschreibung wie „Email lesen“ dazu führen, dass letztlich<br />
eine Email-Auswahl erfolgen kann und deren Textteil formatiert angezeigt wird. Die hierfür erforderlichen<br />
Konzepte, dazu Dinge wie Layout und Design, müssen im Laufe der einzelnen Transformationsschritte<br />
nach und nach der initialen Aussage hinzugefügt werden. Dies soll über die Zwischenmodelle, erweiternde
26 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Transformationen und insbesondere über die Entscheidungen und Gestaltungen der menschlichen Designer<br />
umgesetzt werden.<br />
Daraus ergibt sich die Frage, welche Informationen konkret in den Zwischenschritten hinzugefügt werden<br />
müssen. Eine WIMP-Benutzungsoberfläche wird durch mehrere Merkmale charakterisiert:<br />
1. der Auswahl der zur Verfügung stehenden Interaktionselemente<br />
2. deren grafische Gestaltung, also das Aussehen<br />
3. ihre räumliche Anordnung, innerhalb des Window-Containers, im Allgemeinen als Layout bezeichnet<br />
4. sowie eventuell bestehende dynamische Abhängigkeiten, die eine Navigation begründen<br />
Keines der Quellmodelle liefert substantielle Informationen zu auch nur einem Aspekt oder deckt ihn anderweitig<br />
adäquat ab. Es sind daher weitere Modellspezifikationen notwendig. Das in der Bearbeitungssequenz<br />
<strong>von</strong> Abbildung 2.1 erste Folgemodell, der Dialoggraph, dient der Definition der Grundstruktur des<br />
späteren Interfaces. Durch Festlegung <strong>von</strong> Sichten, im Endeffekt der Zuordnung <strong>von</strong> Aufgaben zu Fenstern,<br />
und den Übergängen zwischen Sichten wird die Navigation (4) vorgezeichnet und in gewisser Weise<br />
eine Vorauswahl zu den Interaktionselementen (1) vorgenommen.<br />
Auf dieser Grundlage wird ein Modell für die abstrakte Oberfläche (AUI) gewonnen. Innerhalb dieses<br />
Modells findet eine Fixierung der Visualisierung jeder Aufgabe auf ein Element einer Interaktionskategorie<br />
(1) statt, beispielsweise wird die Entscheidung für eine Schaltfläche oder eine Tabelle getroffen. Je<br />
nach verwendetem Metamodell kann bereits auf der Ebene der abstrakten Oberfläche eine Gruppierung<br />
<strong>von</strong> Elementen vorgenommen werden und es können ggf. Richtlinien zur Elementanordnung innerhalb<br />
solcher Gruppen vorgegeben werden. In diesem Fall wird bereits auf der Ebene des AUI ein Layout (3)<br />
vorgezeichnet.<br />
Die nächste Verfeinerungsebene ist das Modell der konkreten Oberfläche. Hier erfolgt das Mapping der<br />
abstrakten Interaktionsobjekte auf konkrete Widgets eines Zielmodells. Darüberhinaus wird das Design (2)<br />
jedes Widgets in diesem Modell beschrieben sowie das finale Layout (3) für die Benutzungsoberfläche der<br />
Anwendung festgelegt. Das Modell der konkreten Oberfläche stellt dann, in Kombination mit dem Anwendungsmodell,<br />
das Quellmodell für eine Model-To-Text Transformation zur Erzeugung des Quellcodes der<br />
Anwendung dar.<br />
Das Vorgehensmodell nach Abbildung 2.1 sieht für die Modellabfolge bidirektionale Beziehungen vor.<br />
Modell-Transformationen sind demnach in beide Richtungen möglich, sowohl abstrahierend als auch konkretisierend.<br />
Ziel des Ansatzes ist es für alle Transformationsschritte Pattern zu identifizieren und diese<br />
dann mit Hilfe einer geeigneten Pattern Language, siehe dazu auch Abschnitt 3.5, Benutzern der Methodik<br />
zur semi-automatischen Anwendung bereitzustellen.<br />
2.1.1 Quellmodelle des modellgetriebenen Ansatzes<br />
Die in der Einführung angerissenen Quellmodelle werden im Folgenden im Detail vorgestellt. Hierzu werden<br />
jeweils die verwendeten Metamodelle vorgestellt und erklärt.<br />
Diese Metamodelle sind in einem Systemkontext eingebunden welcher in den abgebildeten Klassendiagrammen<br />
auf zwei verschiedene Arten angedeutet wird. Die Beziehungen zum Kontext werden durch die<br />
Klassen Model und ModelElement hergestellt. Die Klasse Model dient dabei als Wurzelklasse aller Modelle.<br />
ModelElement markiert diejenigen Typen, die die Struktur der Metamodellinstanzen aufbauen. Anders<br />
formuliert, diejenigen die im System direkt durch Editoren bearbeitet werden können.
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 27<br />
2.1.1.1 Metamodell für Aufgabenmodelle<br />
Die Aufgabenmodellierung ist eine etablierte Technik der Anforderungsanalyse. Bereits in Punkt 1.2.3.3<br />
wurden diverse Systeme vorgestellt, welche Aufgabenmodelle als Ausgangspunkt einer modellbasierten<br />
Oberflächengenerierung verwenden. Der Punkt 1.3.1.1 gibt einen Überblick über weiter verbreitete Ansätze<br />
zur Aufgabenmodellierung.<br />
Abbildung 2.2 zeigt das Metamodell für das Aufgabenmodell in unserem modellgetriebenen Ansatz. Wir<br />
verstehen es als eine Evolution des Metamodells der ConCurTaskTrees.<br />
Eine Aufgabe wird als Instanz der Klasse Task angelegt. Für jeden Task können beliebig viele Vorbedingungen<br />
als Precondition definiert werden. Ebenso ist die Anzahl der Effects nicht beschränkt, hier sollen<br />
die Auswirkungen der Aufgabenabarbeitung notiert werden. Auswirkungen und Vorbedingungen werden<br />
durch Ausdrücke in einer nicht im Metamodell spezifizierten Sprache angegeben. Der referenzierte Typ<br />
Expression fungiert als Containertyp für Assoziationen zu beliebigen konkreten Sprachen.<br />
Die Aufzählung TaskCategory überträgt die vier Aufgabenkategorien des CTT als benannte einfache Werte<br />
in das Metamodell. Verwendet wird dies im category-Attribut einer jeden Aufgabe. TemporalOperator ist eine<br />
Aufzählungsklasse und definiert Literale für die <strong>von</strong> CTT definierten temporalen Operatoren. Der Wert<br />
notspecified wurde zusätzlich aufgenommen, um als Standardwert für den Operationstyp <strong>von</strong> Instanzen der<br />
TemporalOperation-Klasse zu dienen. Dabei handelt es sich um ein Zugeständnis an die Usability. Der Wert<br />
notspecified wirkt als Marker für eine ungültige Modellinstanz und zwingt Designer explizit zum Setzen<br />
eines gültigen temporalen Operators.<br />
Jedes TaskModel, welches die Verwaltungsklasse für das jeweilige Aufgabenmodell ist, enthält die Referenzen<br />
zu den anderen Quellmodellen, außerdem noch genau eine Referenz zu dem Wurzelknoten des<br />
Aufgabenbaums.<br />
Im Gegensatz zu CTT werden in unserem Ansatz die Operatoren als Knoten in die Baumstruktur integriert.<br />
Operatorknoten dürfen wiederum Operatorknoten als Kinder haben, das Verschachteln temporaler<br />
Operatoren ist somit zugelassen. Daher kann die Knotenabfolge als abstrakter Syntaxbaum eines, darüber<br />
definierten, Prozessalgebra-Terms angesehen werden. Das Beispiel in Abbildung 2.3 illustriert diese<br />
Struktur.<br />
Die Beziehungen zwischen TemporalOperation, Iteration und TaskComposite sind Kompositionen. Dadurch<br />
wird erzwungen, dass die Blattknoten des Baumes immer Instanzen des Typs Task, also Aufgabenknoten,<br />
Abbildung 2.2: Metamodell für das Aufgabenmodell nach [150]
28 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Abbildung 2.3: Aufgabenmodell für die Klausurenkontrolle in der Rostocker Notation<br />
sind. Zwar nicht durch Kardinalitäten unterbunden, jedoch per Syntaxregel verboten sind:<br />
• Iterationsknoten als Kind eines Iterationsknoten<br />
• Syntaxverletzungen der CTT-Notation, insbesondere die Anforderungen an die Knotenkategorisierung<br />
Warum existiert ein spezieller Knotentyp für Iterationen? Aus zwei Gründen, bei der Iteration handelt es<br />
sich weder um einen Operator noch um eine Aufgabe. Es handelt sich um die Aussage, dass der Teilbaum<br />
unter der iterierten Aufgabe beliebig oft wiederholt werden kann. Ein Iteratorknoten unterscheidet sich<br />
zusätzlich <strong>von</strong> einem Operatorknoten darin, dass er genau einen Kindknoten hat. Nämlich die Wurzel des zu<br />
wiederholenden Teilbaumes. Da zusätzlich die Angabe eines Intervalls für die Anzahl der Wiederholungen<br />
ermöglicht werden sollte, schien ein eigener Typ gerechtfertigt.<br />
Die Originalbedeutung der Iteration im CTT-Ansatz ist, dass eine iterierter Aufgabe nur nach deren Beendigung<br />
neu gestartet werden kann. Es ist bei CTT nicht möglich, verschränkte Iterationen zu spezifizieren.<br />
Das kann für Aufgaben nützlich sein, die wiederholt gestartet werden sollen, obwohl die vorherige Iteration<br />
noch nicht beendet wurde. In der Rostocker Methodik wird der Begriff Instanziteration dafür<br />
verwendet. Im Metamodell wird dieser Spezialfall eines Iterationsknoten als Unterklasse InstanceIteration<br />
der allgemeinen Iteration reflektiert.<br />
Ein Beispielszenario für Instanziteration bietet die Kontrolle <strong>von</strong> Klausuraufgaben. Die oft eingesetzte Strategie<br />
ist, diese in Eingangsreihenfolge abzuarbeiten. Schwierige Fälle jedoch, etwa Abweichungen <strong>von</strong> der<br />
Standardvorgehensweise oder Bewertungen bei denen es auf einzelne Punkte ankommt, werden gesondert<br />
behandelt. Deren endgültige Benotung wird herausgezögert und stattdessen die Benotung andere Klausuren<br />
vorgezogen. Die angefangene Kontrolle der Problemarbeiten wird zu einem späteren Zeitpunkt, aber<br />
noch innerhalb der gleichen Aufgabe, fortgesetzt und beendet. Durch Verwendung <strong>von</strong> Instanziterationen<br />
kann dieses Szenario leicht modelliert werden.<br />
Die Abbildung 2.3 zeigt ein entsprechendes Aufgabenmodell. Der Instanzoperatorknoten findet sich als<br />
Kindknoten der abstrakten Aufgabe Bewerten, markiert mit dem Operatorsymbol #. Alle weiteren grafischen<br />
Elemente sind in ihrer Semantik äquivalent denen der CTT-Notation: Die Aufgabe Klausurenkontrolle<br />
wird in vier atomare Aufgaben zerlegt. Am Anfang steht die Entgegennahme der Klausuren, modelliert<br />
als die Nutzeraufgabe Klausuren erhalten. Nachdem diese Aufgabe abgeschlossen ist, wird der<br />
Teilaufgabenbaum unterhalb der abstrakten Aufgabe Bewerten aktiviert. Die Aufgaben Fehler markieren
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 29<br />
und Benotung sind sequentiell abzuarbeiten. Diese Sequenz kann bereits vor deren Beendigung im Rahmen<br />
einer neuen Instanz neu gestartet werden. Die nachfolgende Aufgabe Weitergeben kann nur gestartet<br />
werden, nachdem alle Iterationsaufgaben abgeschlossen sind. Das Starten der Folgeaufgabe deaktiviert in<br />
jedem Fall die Iterationen.<br />
Der in den bisherigen Erläuterungen nicht behandelte Typ AggregationHint ist insbesondere bei der Erstellung<br />
des Dialoggraphen relevant. Er wird daher im Unterabschnitt 2.1.2 erklärt.<br />
2.1.1.2 Metamodell für Nutzermodelle<br />
In diesem Modell werden die Nutzer des späteren Systems beschrieben. Diese Beschreibung sollte nur die<br />
Merkmale umfassen, die für die Interaktion der Nutzer mit der Anwendung <strong>von</strong> Bedeutung sind.<br />
Das Metamodell für Nutzer, dargestellt in der Abbildung 2.4, reflektiert diesen Minimalansatz: Nutzer<br />
werden rein über Rollen charakterisiert. Die Rollen selbst werden durch den Typ UserRole umgesetzt. Für<br />
diesen Typ sind die <strong>von</strong> der Klasse ModelElement geerbten Attribute ausreichend.<br />
Das bedeutet, dass Nutzerrollen in diesem Ansatz nicht mehr als bloße Namen sind. Eine Hierarchie oder<br />
Rollenzusammenhänge sind auf dieser Modellebene nicht vorgesehen. Falls es im Einzelfall gewünscht<br />
sein sollte, eine Rolle mit weiteren Informationen auszustatten, kann hierfür die Aggregation properties<br />
genutzt werden. Die Metaklasse Entity entstammt dem allgemeinen Objektmodell der Abbildung 2.5 und<br />
wird im Folgenden erläutert.<br />
2.1.1.3 Domänenmodell und Geschäftslogik<br />
Die in Abbildung 2.5 dargestellte Metamodell-Variante ist eine Umsetzung der Basiskonzepte der Objektorientierung.<br />
Es kann sowohl zur Beschreibung <strong>von</strong> Geschäftsobjekten als auch des Nutzungskontexts<br />
verwendet werden. Das an dieser Stelle weder das Ecore- noch das UML-Metamodell zum Einsatz kommen<br />
hat im Wesentlichen historische und softwarearchitektonische Gründe. In ihrer Ausdrucksfähigkeit<br />
und Interoperabilität wären diese genannten Alternativen mächtiger.<br />
Zentrale Metaklasse dieses Modells ist die Entitätsmenge, jedes Objektmodell (ObjectModel) besteht aus<br />
Instanzen des Typs Entity. Eine Entitätsmenge lässt sich mit den Attributen des Typs ModelElement (Name,<br />
ID und Kommentar) hinreichend genau beschreiben, auf weitere Attribute in der Metaklasse wurde<br />
verzichtet. Zur Spezifikation einer Entitätsmenge gehören im OO-Paradigma immer die Eigenschaften der<br />
Instanzen, sowie Methoden welche die Instanzen ausführen können.<br />
Die Attribute der Instanzen einer bestimmten Entitätsmenge beschreibt die Aggregationsbeziehung zu<br />
Abbildung 2.4: Metamodell für das Nutzermodell
30 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Abbildung 2.5: Allgemeines Objekt-Metamodell<br />
Attribute. Die Signatur eines Attributes besteht aus seinem Namen und seinem Typ. Der Typ wird bei<br />
Anwendung des Metamodells <strong>von</strong> Abbildung 2.5 als Instanz <strong>von</strong> Entity spezifiziert. Zur Namensangabe<br />
dient das <strong>von</strong> ModelElement geerbte Attribut. Durch Angabe einer expliziten multiplicity können Vektoren<br />
und Optionalität ausgedrückt werden. Die Wertsemantik folgt hier derjenigen der UML, der Standardwert<br />
„1“ entspricht einem einfachen nicht-optionalem Attribut.<br />
Methoden werden, über die Klasse Method, grundsätzlich auf die gleiche Weise definiert. Methodensignaturen<br />
enthalten typischerweise noch Eingabeparameter. Da für diese Parameter nicht nur der Typ, sondern<br />
auch die Reihenfolge bedeutsam ist, wurde die Assoziationsklasse Parameter eingeführt. Deren einziges<br />
Attribut position definiert die Indexposition in der Parameter-Folge. Jedem Parameter ist eine Instanz der<br />
Klasse Attribute zugeordnet, dies dient der Definiton <strong>von</strong> Name und Typ des jeweilige Parameters. Optional<br />
kann die Angabe des Rückgabetyps einer Methode, mittels der Assoziation zu returnType:Entity, erfolgen.<br />
Das finale Ziel des hier vorgestellten Ansatzes ist es, ausgehend <strong>von</strong> den Modellen lauffähige Anwendungen<br />
zu generieren. Dafür kann es sinnvoll sein, insbesondere für die Methoden der Objekte der Geschäftslogik,<br />
Quellcode für die Implementierung vorzugeben. Die Metaklasse SourceCodeReference dient<br />
der Deklaration entsprechender Quellcodebestandteile. Für jede Methode können beliebig viele Quellcode-<br />
Ausschnitte definiert werden.<br />
Die Abbildung 2.5 sieht Mehrfachvererbung für die Entitätsmengen vor. Die Assoziationsende mit dem<br />
Rollennamen superType kann zur Deklaration beliebig vieler Oberklassen genutzt werden. Es sind keine<br />
Ansätze zur Lösung oder Verhinderung der typischen Probleme bei Mehrfachvererbung vorgesehen. Das<br />
Vermeiden <strong>von</strong> Namenskonflikten, die Herstellung <strong>von</strong> Typsicherheit und das Verhindern <strong>von</strong> zyklischen<br />
Vererbungen sind damit dem Designer überlassen.<br />
Zu Illustration findet sich in Abbildung 2.6 eine Darstellung der Anwendung des Metamodells und sowie<br />
eines damit gleichbedeutenden UML-Klassendiagramms. In der linken Hälfte findet sich die Darstellung<br />
im Standard-Ecore-Editor, rechts das gleichbedeutende UML-Modell. Da es sich um keinen spezialisierten<br />
Ecore-Editor handelt, sind Einzelheiten insbesondere Typ und Multiplizität, nur über die Eigenschaftenansicht<br />
der einzelnen Typen einseh- und änderbar.
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 31<br />
Abbildung 2.6: Gegenüberstellung Objektmodelleditor und UML-Modell<br />
Im Beispiel wurden die Domänen-Objekte einer fiktiven Anwendung zur Unterstützung der Klausurenkontrolle<br />
modelliert. Die Entitätsmengen Matrikel, Zeichenkette und Zensur sind auf dieser Abstraktionsebene<br />
als reine Datentypen modelliert, es wurden keine Eigenschaften oder Methoden festgelegt. Diese Datentypen<br />
werden benötigt, um den Wertebereich der Attribute der beiden Entitätsmengen Klausur und Zensur<br />
festzulegen.<br />
Gerätemodell als Spezialfall des Domänenmodells<br />
Ein wichtiger Grund für die Verwendung modellbasierter Techniken ist die vereinfachte Anpassbarkeit an<br />
sich ändernde Nutzungsbedingungen. Im Rahmen <strong>von</strong> <strong>Benutzungsoberflächen</strong> sind dabei besonders zwei<br />
Änderungsdimensionen zu betrachten.<br />
Zum einen die Geräteplattform und zum anderen die Modalität der Nutzerinteraktion. Wird beispielsweise<br />
der Interaktionsmodus <strong>von</strong> einer WIMP-Methodik auf akustisch-taktile Interfaces umgestellt, dürfte im Regelfall<br />
ein komplettes Re-Design der Benutzerschnittstelle notwendig sein. Der in dieser Arbeit vorgestellte<br />
Ansatz kann in Teilen auch für derlei Interfaces eingesetzt werden. Insbesondere sind die Quellmodelle<br />
unabhängig <strong>von</strong> der eingesetzten Interaktionsmodalität. Die im weiteren Verlauf vorgestellten Modelle für<br />
konkrete Oberflächen sind mit Schwerpunkt auf WIMP-Oberflächen entwickelt. Diese sind nur unzureichend<br />
für die Beschreibung multimodaler Nutzerinterfaces einsetzbar, weil sie in keiner Weise auf deren<br />
Besonderheiten eingehen.<br />
Nutzungskontextänderungen die aus einem Wechsel der Geräteplattform bestehen, können mit den Modellen<br />
gut behandelt werden. Hardware-Plattformen werden typischerweise in einem Gerätemodell beschrieben.<br />
Es wäre möglich, ein spezielles Metamodell zu deren Beschreibung vorzugeben. Allerdings würde<br />
dieses strukturell sehr ähnlich dem des Objektmodells sein, siehe dazu Punkt 2.1.1.2. Statt ein weiteres<br />
Metamodell einzuführen, sollte das Gerätemodell unter Benutzung des Objekt-Metamodell aus Abbildung<br />
2.5 spezifiziert werden. Dies ermöglicht flexible, aber dennoch formale, Geräte-Beschreibungen, die<br />
in den nachfolgenden Transformationen verwendet werden können.<br />
2.1.2 Dialogmodell<br />
Im Prozessmodell zur modellgetriebenen Oberflächenerzeugung, siehe Abbildung 2.1, folgt auf die Instanziierung<br />
der Quellmodelle die Prozessstufe Dialogmodell. Im Dialogmodell wird die Navigationsstruktur<br />
der Nutzungsoberfläche beschrieben.
32 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Da wir eine WIMP-Anwendung mit diesem Mittel beschreiben, ist die Basisstruktur des Dialogmodells<br />
das Fenster. Die Abstraktionsebene des Dialogmodells sieht jedoch noch keine deratig konkreten Objekte<br />
vor, deshalb wird stattdessen der Begriff der Sicht, bzw. View, verwendet. Eine Sicht ist ein Gruppierungscontainer.<br />
Jede Aufgabe, d.h. entweder Blattaufgabe oder eine mit Gruppierungsinformationen angereicherte Nicht-<br />
Blattaufgabe, aus dem Taskmodell wird einer Sicht zugeordnet. Durch das Erledigen oder Beenden einer<br />
Aufgabe wird typischerweise eine nachfolgende Aufgabe aktiviert. Wurde diese Aufgabe einer anderen als<br />
der aktuellen Sicht zugeordnet, ist es nötig einen Übergang zu dieser Sicht durchzuführen.<br />
Ein solcher Übergang kann sequentiell oder nebenläufig sein. In beiden Fällen wird die neue Sicht, die<br />
Zielsicht, angezeigt. Im Falle einer sequentiellen Transition wird die Quellsicht <strong>von</strong> der Anzeige entfernt,<br />
bei nebenläufigen Transitionen würden simultan Quell- und Zielsicht dargestellt.<br />
Das Dialogmodell wird durch eine Graphenstruktur beschrieben, dem sogenannten Dialoggraphen. Die<br />
Syntax und die zulässigen Elemente <strong>von</strong> Dialoggraphen, d.h. die Kanten und Knotentypen, werden in [107]<br />
erläutert und definiert. In der zusammenfassenden Darstellung <strong>von</strong> Abbildung 2.7 findet sich ein Überblick.<br />
Bei der Erstellung des Graphen sollte jeder Sicht ein Name zugewiesen werden. Darüberhinaus gilt, dass<br />
die Kanten, welche die Übergänge zwischen den Sichten definieren, immer gerichtet sind. Nur Endknoten<br />
haben keine ausgehenden Kanten.<br />
Eine exemplarische Darstellung eines Dialoggraphen ist Abbildung 2.8. Hier wurde eine Anwendung zur<br />
Anlage und Erweiterung <strong>von</strong> Börsenportfolio beschrieben. Nicht alle möglichen Syntaxkonstrukte wurden<br />
verwendet, so fehlt etwa eine explizite Endsicht. Die grafische Darstellung ist [105] entnommen, an<br />
gleichem Ort findet sich auch das zugehörige Aufgabenmodell.<br />
Die Anfangssicht ergibt sich implizit aus den gerichteten Transitionen, in diesem Fall „Anmelden“ . In<br />
dieser Sicht entscheidet der Nutzer ob er sich mit einem vorhandenen Account anmelden möchte, oder eine<br />
Neuregistrierung vornimmt. Entsprechend dieser Auswahl wird der obere oder der untere Pfad verfolgt.<br />
Beide Pfade führen zur Sicht „Portfolio“. Bis hierher waren alle Transitionen sequentiell. Entscheidet sich<br />
der Nutzer an diesem Punkt dafür, die Aufgabe „Aktien hinzufügen“ auszuführen, erfolgt der Übergang<br />
in die Sicht „Aktiensuche“ nebenläufig. In der konkreten Anwendung blieben also beide Fenster geöffnet<br />
und es wäre sogar möglich, durch wiederholtes Ausführen <strong>von</strong> „Aktien hinzufügen“ beliebig viele weitere<br />
Fenster zu öffnen. Die <strong>von</strong> der Sicht „Aktiensuche“ weiterführenden Transitionen sind sequentiell. Wenn<br />
der durch „Aktien hinzufügen“ gestartete Transitionszyklus wieder die Sicht „Portfolio“ erreicht, wird<br />
das zusätzliche Fenster geschlossen.<br />
Das Metamodell des Dialoggraph-basierenden Dialogmodells zeigt Abbildung 2.9. Es stellt weitere Funktionalität<br />
für Dialogmodelle bereit, welche nicht durch [107] gefordert wird, aber auch schon im Beispiel<br />
<strong>von</strong> Abbildung 2.8 verwendet wurde. Die wesentlichen Erweiterungen gegenüber [107] sind die Einführung<br />
eines Port-Konzeptes, die Möglichkeit der Gruppierung <strong>von</strong> Sichten und die Hierarchisierung <strong>von</strong><br />
Sichtname<br />
Einzelsicht<br />
Nebenläufig Sequentiell<br />
Sichtname<br />
Mehrfachsicht<br />
Sichtname<br />
modale Sicht<br />
Sichtname<br />
Abbildung 2.7: Syntaxelemente eines Dialoggraphen<br />
komplexe Sicht Endsicht
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 33<br />
Dialoggraphen.<br />
Abbildung 2.8: Beispiel eines Dialoggraphen, entnommen aus [105]<br />
Bei einem Port handelt es sich um eine vereinheitlichte Ein-/Ausgangsschnittstelle in eine Sicht oder auch<br />
in einen vollständigen Dialoggraphen. Transitionen, insbesondere auch sichtinterne Übergänge, lassen sich<br />
mittels des Portkonzeptes feingranularer steuern. Die Hierarchisierung entspricht in ihrer Natur derjenigen<br />
bei den UML-Statecharts. Eine Sicht kann, an Stelle einer Folge <strong>von</strong> Aufgaben, genau einen vollständigen<br />
Dialoggraphen enthalten. Innerhalb dieses können wiederum Sichten Dialoggraphen enthalten. Eine<br />
Limitierung der Verschachtelungstiefe ist nicht vorgesehen.<br />
Sichten können in Gruppen zusammengefasst werden. In Abbildung 2.8 wurden zwei Gruppen definiert.<br />
Das eine Tripel enthält die Sichten („Persönliche Daten“ ,„Anmeldedaten“ ,„Anschrift“ ), das andere wird<br />
durch („Aktiensuche“ ,„Aktienauswahl“ ,„Aktienkauf“ ) gebildet. Zur Kenntlichmachung sind beide Tripel<br />
in der Abbildung farblich hinterlegt. Die Gruppenkennzeichnung „PC“ indiziert die Anwendung dieser<br />
Abbildung 2.9: Metamodell Dialoggraph nach [44]
34 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Sichten-Gruppe/-Abfolge nur für die Plattform Desktop-Rechner.<br />
Ableiten des Dialoggraphen aus dem Aufgabenmodell<br />
Das Erstellen <strong>von</strong> Dialoggraphen kann durch eine Reihe <strong>von</strong> Softwarewerkzeugen unterstützt werden. So<br />
zeigt das Beispiel in Abbildung 2.8 einen Ausschnitt aus einem Screenshot <strong>von</strong> DiaTask, in der Version als<br />
GEF-Plugin. Auch mit Werkzeugunterstützung bleibt die Dialogmodellierung zunächst eine rein manuelle<br />
Tätigkeit. Die laut der Prozessübersicht, siehe Abbildung 2.1, anzustrebende patternbasierte Transformation<br />
ist noch zu erforschen. Ansätze dazu existieren bereits, der in [30] erarbeitete und in [150] in den<br />
weiteren Prozesskontext eingebettete Vorschlag, soll im Folgenden kurz erläutert werden.<br />
Diebow schlägt in [30] vor, dass eine automatische Ableitung des Dialogmodells aus dem Aufgabenmodell<br />
durch bereits im Aufgabenmodell annotierte Zusatzinformationen erfolgen kann. Die Annotierung erfolgt<br />
durch menschliche Designer während der normalen Erstellung des Taskmodells. Dabei wird für ausgewählte<br />
Knoten, also Tasks, ein Algorithmus ausgewählt, nach dessen Regeln der Knoten oder dessen Kindern<br />
auf Sichten verteilt werden sollen. Diebow identifizierte vier Strategien, welche durch ihre englischsprachigen<br />
Abkürzungen bezeichnet werden:<br />
ICV - Integrate Children into View: Alle Kindaufgaben des jeweiligen Aufgabenknotens werden der selben<br />
Sicht zugeordnet.<br />
IN - Ignore Node: Der jeweilige Task, und der gesamte darunterliegende Teilbaum, werden ignoriert. Das<br />
bedeutet, dass keiner der darin enthaltenen Aufgabenknoten im Dialogmodell verwendet wird.<br />
PUNM - Pick Up for Navigation Model: Derartig annotierte Aufgabenknoten werden in jedem Fall im<br />
Dialogmodell verwendet.<br />
VL - View List: Hier erfolgt eine explizite Sichtzuweisung mittels einfacher Terme. Die EBNF-Grammatik<br />
für einen solchen Term lautet:<br />
✞ ☎<br />
Kind ::= 1{"0" .. "9"}.<br />
Term ::= "{" Kind {"," Kind } "}" {"," "{" Kind {"," Kind } "}" }.<br />
✝ ✆<br />
Listing 2.1: EBNF Grammatik für die Sichtzuordnung <strong>von</strong> Aufgaben<br />
Die Kindknoten werden nummeriert, ein Paar der geschweiften Klammern im Term entspricht einer<br />
Sicht im Dialogmodell. Sichten können nicht verschachtelt werden. Eine kommagetrennte Folge <strong>von</strong><br />
Kindknotennummern definiert die View-Zuordnung der jeweiligen Aufgabe.<br />
Die Strategien IN und PUNM sind nur im Zusammenhang mit Rollen oder Gerätemodellen sinnvoll einsetzbar.<br />
Die Abbildung 2.10 zeigt die Vorgehensweise an einem abstrakten Beispiel. Die Darstellung illustriert<br />
auch, dass jeder Knoten des Aufgabenmodells annotiert werden kann, neben Aufgaben auch die Operatorknoten.<br />
Zur Vereinfachung wurden die Strategien ICV, IN und PUNM hier nicht angewendet. Für den<br />
Enabling-Operator wurde die Konversionsreihenfolge mit einem Term über der Grammatik aus Listing 2.1<br />
definiert. Der Term {0}{1,2}{3} besagt, dass drei Sichten anzulegen sind. Die Erste und die Dritte sind<br />
mit nur einer Aufgabe zu belegen. In die zweite Sicht sind die beiden Tasks, die an den Kindpositionen 1<br />
und 2 liegen, zuzuordnen. Würde anstelle der VL-Strategie am gleichen Knoten die ICV-Strategie gewählt,<br />
ergäbe sich nur eine einzige Sicht welche alle vier Kindknoten enthielte.<br />
Bei der Erklärung des Metamodells des Aufgabenmodells wurde die Aufzählungsklasse AggregationHint<br />
ausgelassen und stattdessen hierher verwiesen. Sie dient über die aggregation*-Attribute der Task-Metaklasse<br />
zur Annotation der zu verfolgenden Dialogmodell-Erzeugungsstrategie.
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 35<br />
Abbildung 2.10: Annotiertes Aufgabenmodell und abgeleiteter Dialoggraph, nach [150]<br />
Mockup-Prototypen aus dem Dialoggraph<br />
Sobald das Dialogmodell spezifiziert wurde ist es möglich, einen Prototypen der Anwendungsoberfläche<br />
zu generieren. Die dabei entstehende Oberfläche kann, zu einem sehr frühen Zeitpunkt im Softwareentwicklungsprozess,<br />
genutzt werden um gemeinsam mit technisch weniger versierten Stakeholdern die Navigationsstruktur<br />
zu testen.<br />
Auf dieser Abstraktionsebene liegen kaum verwendbare Informationen darüber vor wie die jeweiligen Aufgaben<br />
in der Oberfläche reflektiert werden sollen. Es scheint daher notwendig, Standardabbildungen vorzudefinieren.<br />
Die nötige Interaktivität der Oberfläche muss mit den gewählten Standard-Mappings umsetzbar<br />
sein.<br />
Ein simples aber funktionales Mapping verwendet eine Kombination der Techniken XUL und HTML.<br />
Eine HTML-Seite soll als Startcontainer für die Simulation dienen, die eigentlichen Views werden per<br />
XUL dargestellt. Aus jeder View wird ein XUL-window generiert, jede Aufgabe als XUL-button umgesetzt<br />
und die Navigation durch Klicken auf die erstellten Buttons ausgelöst und über Javascript umgesetzt.<br />
Die Startmaske für den Einsprung in die zu erstellende Anwendung wird mit einer Model-To-Text Transformation<br />
im Kontext des Wurzel-Dialoggraphen erstellt. Listing 2.2 zeigt den Quellcode für ein xPand-<br />
Template zur <strong>Generierung</strong> der HTML-Startmaske. Über OCL-Ausdrücke wird die Referenz auf den Start-<br />
Port ermittelt und für die darin referenzierte Zielansicht die Transformation des Gesamtgraphen gestartet.<br />
Zur Interpretation der Selektorausdrücke kann Abbildung 2.9 hilfreich sein.<br />
Nach Durchführung der Transformation nach Listing 2.2, wurde eine HTML-Datei mit dem Namen des<br />
Dialoggraphen erstellt. Diese Datei definiert nicht mehr als einen Link zu einer XUL-Datei.
36 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
✞ ☎<br />
«DEFINE root FOR Dialoggraph»<br />
«FILE name+".html"»<br />
Dialoggraph−Simulation<br />
«EXPAND Dialoggraph (this.Port.selectFirst(port|port.type.toString()==’in’))»<br />
<br />
«ENDFILE»<br />
«ENDDEFINE»<br />
«DEFINE Dialoggraph (Port startPort) FOR Dialoggraph»<br />
«LET startPort.outgoing.at(1).inputport.DialogView AS startView»<br />
Simulation <strong>von</strong> «name» starten<br />
«ENDLET»<br />
«ENDDEFINE»<br />
✝ ✆<br />
Listing 2.2: Ausschnitt aus einem xPand-Template<br />
Die XUL-Dateien entstehen als Transformationergebnis der einzelnen DialogViews. Der Dateiname der<br />
XUL-Datei ergibt sich aus dem Namen der Sicht, dieses Wissen wurde für die <strong>Generierung</strong> des Linkziels im<br />
Template Dialoggraph (Port startPort) bereits verwendet um die Start-Sicht zu verlinken. Jede Transition wird<br />
in eine JavaScript-Navigationsanweisung übersetzt. Da Transitionen nach Aufgabenbeendigung durchgeführt<br />
werden, werden diese Navigationsinstruktionen in einem Attribut des jeweiligen Aufgaben-button als<br />
Event-Handler abgelegt. Auf die Abbildung der dazu notwendigen xPand-Templates soll an dieser Stelle<br />
verzichtet werden.<br />
Das visuelle Ergebnis der Mockup-<strong>Generierung</strong> ist vom ästhetischen Standpunkt her sicher unbefriedigend.<br />
Einen Eindruck da<strong>von</strong> gibt Abbildung 2.11, darin wird das abstrakte Beispiel aus Abbildung 2.10<br />
zu einem Navigationsprototypen fortgeführt. Die Oberflächen wurden durch Seamonkey gerendert. Links<br />
befindet sich die HTML-Einsprungsmaske, daran schließen sich in der Reihenfolge aus dem Dialogmodell<br />
die weiteren Sichten an.<br />
Das der generierte Prototyp optisch roh und unfertig wirkt, hat durchaus auch positive Seiten. Van Buskirk<br />
et al. [135] bemerken, dass unfertig wirkende GUIs stimulierend auf die Diskussion mit künftigen Benutzern<br />
und anderen Stakeholdern wirken. Wohingegen bei aufwendig gestalteten Oberflächen dieselben<br />
Nutzer Änderungsvorschläge nur eher zögerlich vorbringen. Van Buskirk leitete aus dieser Beobachtung<br />
das „Keep it ugly“-Prinzip für die Diskussion <strong>von</strong> Gestaltungsalternativen ab.<br />
Abbildung 2.11: Screenshot-Sequenz eines generierten Navigationsprototypen
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 37<br />
2.1.3 Abstrakte Oberfläche<br />
Die abstrakte Oberfläche ist die Modellebene zur plattformunabhängigen Beschreibung der Benutzerschnittstelle.<br />
Den Plattform-Begriff definiert die OMG in [85] folgendermaßen:<br />
„Platform: A set of subsystems/technologies that provide a coherent set of functionality through<br />
interfaces and specified usage patterns that any subsystem that depends on the platform can<br />
use without concern for the details of how the functionality provided by the platform is implemented“<br />
Diese Definition entstammt den Begriffserklärungen zu dem <strong>von</strong> der OMG vertretenen Paradigma der<br />
Model-Driven Architecture. Eine Plattform ist demnach eine Menge <strong>von</strong> Untersystemen bzw. Technologien,<br />
welche eine zusammenhängende Funktionalität zur Verfügung stellt. Da der Begriff in engem Zusammenhang<br />
zu den OMG-MDA Modellarten steht, lohnt möglicherweise noch die Betrachtung der Definition<br />
des Plattform-Modells:<br />
„Platform Model: A set of technical concepts, representing the different kinds of parts that<br />
make up a platform and the services provided by that platform.“<br />
Leider führt dies auch nicht zu mehr Erkenntsgewinn als jede andere Formalisierung eines offensichtlichen<br />
Sachverhaltes. Es bleibt festzuhalten, dass eine noch generische Festlegung des Plattform-Begriffes kaum<br />
erfolgen kann.<br />
Um die angemessene Abstraktionsebene für das Modell des Abstract User Interface (AUI) zu identifizieren<br />
ist es daher zwingend notwendig, sich für eine Plattform-Bedeutung zu entscheiden. Beschränkt man sich<br />
auf den Bereich der Softwaretechnik, werden in unterschiedlichen Kontexten mindestens diese Plattformbedeutungen<br />
unterschieden:<br />
1. Oberflächenframeworks<br />
2. UI-Beschreibungssprachen<br />
3. Betriebssysteme und deren verschiedene Versionen<br />
4. Geräteklasse, wie etwa Mobiltelefon oder Notebook<br />
5. andere formalisierte Befähigungsklassifizierungen, wie beispielsweise über Java Specification Requests<br />
(JSR)<br />
Zusätzlich können auch Faktorkombinationen aus mehreren dieser Gruppen eine Plattform charakterisieren.<br />
Plakativer ausgedrückt: einerseits bildet ein Symbian-Smartphone eine andere Plattform als ein Mobiltelefon<br />
auf der Basis <strong>von</strong> Windows Mobile. Andererseits sind beide zumeist in der Lage Applikationen<br />
der Java Micro Edition ablaufen zu lassen, aus dieser Sicht gibt es zunächst keine Plattformunterschiede.<br />
Solche Unterschiede finden sich jedoch mit hoher Wahrscheinlichkeit bei der Menge der umgesetzten<br />
Spezifikationen aus den JSRs.<br />
JSRs sind Vorschläge für APIs für neue Funktionalität oder Änderungen an bestehenden Java-APIs. Sie<br />
werden im „Java Community Process“ [65] öffentlich diskutiert, formalisiert und verabschiedet. Oftmals<br />
werden die verfügbaren Features mobiler Geräte über die implementierten JSRs angegeben.<br />
Im Rahmen dieser Arbeit werden besonders 2-dimensionale menü- und mausbasierte <strong>Benutzungsoberflächen</strong><br />
untersucht. Die zu Grunde liegende Hardware soll hier nicht betrachtet werden. Ebenfalls nicht im
38 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Fokus stehen die anderen Aspekte der tatsächlichen technischen Umsetzung einer Oberfläche; die Geräteklasse<br />
und die speziellen Fähigkeiten einer Umgebung sind zunächst irrelevant.<br />
Die Plattform für den hier betrachteten modellgetriebenen Prozess bilden Oberflächenframeworks und UI-<br />
Beschreibungssprachen für WIMP-Oberflächen. Die Anforderung an ein plattformunabhängiges AUI Modell<br />
ist daher, diese Art <strong>von</strong> Oberflächen allgemein zu definieren. Ein solches Metamodell enthielte theoretisch<br />
die abstrakte Beschreibung der Schnittmenge aller in Frage kommenden Plattformen.<br />
In Abschnitt 1.3 wurden bereits einige Ansätze zur Erstellung derartiger Metamodelle diskutiert. Zur Verwendung<br />
im Rostock MD-UID Prozess kommen zwei Metamodelle. Bei einer Variante handelt es sich um<br />
eine Weiterentwicklung des in [78] entwickelten Modells für abstrakte Oberflächen aus dem X3USGP [78]<br />
Prozessmodell. Alternativ wird auch oft eine Untermenge <strong>von</strong> XUL als Ersatz-AUI-Modell, für Mockup-<br />
Prototypen, verwendet. Diese Untermenge wurde nie formal fixiert und die Auswahl der enthaltenen Elemente<br />
ist willkürlich. Wegen dieser Schwächen sei diese Alternative hier nur erwähnt, aber nicht weiter<br />
ausgearbeitet.<br />
Das AUI-Metamodell des X3USGP-Prozesses nennt sich X-AIM, es handelt sich um ein XML-Derivat,<br />
welches als DTD 1 definiert vorliegt. Abbildung 2.12 und Abbildung 2.13 stellen das Ergebnis der Übertragung<br />
dieser Grammatik in die MDA-Methodik dar. Beide Grafiken wurden mit dem EMF-eigenen Diagrammeditor<br />
erstellt.<br />
Das EMF-Metamodell für X-AIM entstand als das Ergebnis manueller Bearbeitung. Theoretisch ist es<br />
möglich aus der X-AIM DTD direkt ein zugehöriges EMF-Metamodell zu generieren. Dazu müsste zunächst<br />
das der DTD äquivalente XML-Schema generiert und dieses anschließend in ein Ecore-Metamodell<br />
übertragen werden. Eine Reihe manueller Eingriffe wären allerdings auch in diesem Prozess notwendig. So<br />
entsprechen etwa die in der DTD vorgesehenen Element-Namen nicht den Syntaxanforderungen für Ecore-<br />
Metaklassen, weiterhin sind geeignete EMF-Typen für die unterspezifizierten DTD-Attribute festzulegen.<br />
Die komplett manuelle Modellerstellung schien daher in diesem Fall daher die angemessenste Variante zu<br />
sein.<br />
Die Darstellung des Metamodells wurde in zwei Segmente aufgeteilt. Die Abbildung 2.12 zeigt die Grundstruktur<br />
des Modells. Die in dieser Abbildung referenzierten Metaklassen Table, ListN und Tree werden in<br />
Abbildung 2.13 definiert.<br />
Instanzen der Klasse UI dienen der Beschreibung jeweils eines Fensters. Sie enthalten mindestens eine Instanz<br />
eines InteractionElement. Interaktionselemente dienen entweder zur Ausgabe an oder der Eingabe <strong>von</strong><br />
Informationen durch den Benutzer. Instanzen der Klasse UIO sind unspezifizierte UI-Elemente, sie enthalten<br />
ihrerseits wieder beliebig viele InteractionElement-Instanzen als Kindobjekte. Über diesen Mechanismus<br />
können Gruppierungen vorgenommen werden. Das X-AIM Metamodell enthält sonst keine Metaklassen<br />
welche zur Angabe <strong>von</strong> Layoutinformationen verwendet werden können. Es ist lediglich indirekt möglich,<br />
aus der Elementverschachtelung und -reihenfolge per Heuristik Layouthinweise abzuleiten.<br />
Vorgesehene Eingabewidgets sind Eingabefelder (InputString), Tabellen(InputTable), Bäume(InputTree), Auswahllisten<br />
(Input1N und InputMN) und Schaltflächen (InputTrigger). Mit Ausnahme der Schaltflächen sind<br />
die gleichen Widgets für die Ausgabe <strong>von</strong> Informationen verfügbar. Die Angabe 1N bzw. MN der Auswahllisten,<br />
ist als Einfachselektion (1 aus N) bzw. Mehrfachauswahl (M aus N) zu interpretieren. Abweichend<br />
<strong>von</strong> der X-AIM Spezifikation des Typs InputString, und seinem Ausgabeäquivalent, wurde der Stringwert<br />
als Attribut der Metaklasse modelliert. Bzw. wurde an Stelle des in X-AIM definierten string_value-Typen<br />
der Ecore-Standardtyp EString verwandt.<br />
1 Doctype Definition
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 39<br />
Abbildung 2.12: Metamodell für AUI im X-AIM Prozess, Grundstruktur nach [78]<br />
Abbildung 2.13: Metamodell für AUI im X-AIM Prozess, Widgets nach [78]<br />
Die komplexeren Ein-/Ausgabewidgets nutzen weitere Metaklassen um genauer beschrieben zu werden.<br />
Eine Tabelle besteht gemäß dem Metamodell in Abbildung 2.13 aus Tabellenkopf oder Tabellendaten. Im<br />
Tabellenkopf werden die Überschriften der Spalten bzw. Zeilen, das ist interpretationsabhängig, angegeben.<br />
Der Tabellenkörper definiert die Informationen in den einzelnen Tabellenzellen.<br />
Bäume haben ein eigenes Label, das Attribut head. Dieses wird zur Darstellung des Wurzelknotens verwendet.<br />
Neben diesem Label gibt es eine Sequenz <strong>von</strong> Kindknoten, dies sind die Knoten mit der Tiefe 1 im<br />
Baum. Die Baumknoten selbst werden über die Metaklasse TreeItem spezifiziert. Jedem Knoten ist wiederum<br />
ein Label zugeordnet, sowie eine Auswahlmarkierung. Ein Knoten kann Vaterknoten einer beliebigen
40 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Anzahl Kindknoten sein. Bei der vorliegenden Definition des Metamodells, kann die Baumeigenschaft<br />
<strong>von</strong> Tree-Instanzen nur über Constraint-Prüfungen sichergestellt werden. Aus der ursprünglichen DTD-<br />
Grammatik folgt in jedem Fall, dass die Baumwidgets des X-AIM Bäume im Sinne der Graphentheorie<br />
sind. Auf der Klassenmodell-Ebene ist diese Forderung ohne Hinzufügung weiterer Attribute nicht umzusetzen.<br />
Listen sind lediglich eine Sequenz <strong>von</strong> ListItems. Jedes Listenelement kann selektiert sein und verfügt<br />
über ein beschreibendes Label. Es sind keine Gruppierungen oder Hierarchisierungen vorgesehen. Die<br />
Unterscheidung zwischen Einfach- und Mehrfachselektion hat keinen Einfluss auf die Objektstruktur einer<br />
Liste.<br />
Adaption als AUI-Modell im MDA-Prozess<br />
Die Erstellung eines die DTD reflektierenden Ecore-Modells ist nur ein erster Schritt zur Integration des X-<br />
AIM Metamodells in den MDA-Ansatz. Es war beispielsweise nötig, den Modell-Klassen die ModelElement<br />
und Model-Eigenschaft zuzuordnen. Weiterhin entstand X-AIM als XML-Format und seine Konzeption ist<br />
dementsprechend nicht auf die Umsetzung mit Klassenmodellen als Metamodellen ausgelegt. Es war daher<br />
zu prüfen inwieweit die gleichen Konzepte eventuell mit weniger oder anders strukturierten Metaklassen<br />
umgesetzt werden können.<br />
Natürlich ist auch die Querreferenzierung zu den anderen Modellen aus dem Gesamtansatz <strong>von</strong> Abbildung-<br />
2.1 zu integrieren. Wichtigstes Element da<strong>von</strong> ist es, die UI-Widgets einer bestimmten Aufgabe zuordnen<br />
zu können. Andere Änderungen umfassen das Ändern <strong>von</strong> Eigenschaftennamen, um sie dem aktuellen<br />
Sprachgebrauch anzupassen, und das Überarbeiten der Relationen allgemein.<br />
Das Ergebnis dieser Überlegungen stellen Abbildung 2.14 und Abbildung 2.15 dar.<br />
Die Grundstruktur einer abstrakten Oberfläche nach dem adaptierten X-AIM Metamodell wird in Abbildung<br />
2.14 gezeigt. Die Klasse UI ist weiterhin der Modellcontainer, welcher Sequenzen beliebig vieler<br />
InteractionElement-Instanzen enthält. Ebenfalls beibehalten wurde die Unterteilung in Input, Output und UIO,<br />
als allgemeinem Container. Im Gegensatz zu X-AIM wird nun jedem Interaktionselement ein Task, vgl.<br />
Abbildung 2.2, zugewiesen.<br />
Instanzen der Input und Output Klassen enthalten jeweils genau ein Widget des Typs IOElement. Die verfügbaren<br />
Widgets werden nun nicht mehr in zwei separaten Hierarchieebenen dupliziert. Als Widgettyp-<br />
Abbildung 2.14: Adaptiertes AUI-Metamodell, Grundstruktur
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 41<br />
en stehen weiterhin Tabellen, Auflistungen, Textfelder, Bäume und Schaltflächen Trigger zur Verfügung.<br />
Schaltflächen können nun auch als Ausgabe-Widgets verwendet werden. Elemente konkreter Oberflächen,<br />
welche als Schaltflächen zur Informationsausgabe genutzt werden, sind zum Beispiel Umschalter, auch als<br />
Togglebuttons bekannt. Schaltflächen können nun ebenfalls auch mit einem Label versehen werden.<br />
Der Widget-Typ List steht für beliebige Auswahllisten. Der genaue Selektionstyp einer Liste wird über<br />
das Attribut selection, mit den Werten aus der Aufzählung SELECTION_MODE, gesteuert. Die Attribute<br />
rangeInterval und rangeWindow aus dem X-AIM Metamodell wurden nicht übernommen.<br />
Tabellen sind weiterhin NxM-Gitter. Die Angabe der Tabellengröße erfolgt prinzipiell genau wie im X-AIM<br />
Metamodell, es wurden lediglich die Attributnamen in die derzeit allgemein üblichen geändert. Gleiches<br />
gilt für das caption-Attribut eines Baumes, hier wurde ebenso lediglich der Eigenschaftenname angepasst.<br />
Keine Änderungen ergaben sich für die Metaklasse StringValue.<br />
Außerdem wurden die in Abbildung 2.12 dargestellten Kompositionsbeziehungen, soweit zutreffend, zu<br />
Aggregationen reduziert. Die Zuordnung der ModelElement-Eigenschaft ist trivial, auf dieser Ebene sollen<br />
alle Instanzen der Metamodellklassen im Editor bearbeitbar sein. Dementsprechend wurden diese als<br />
Unterklassen <strong>von</strong> ModelElement modelliert.<br />
Die Modifikationen an den Metaklassen der komplexeren Widgets zeigt Abbildung 2.15. Alle hier dargestellten<br />
Klassen sind als Unterklassen <strong>von</strong> ModelElement bearbeitbar.<br />
Von links nach rechts: Für Bäume wurde sichergestellt das die Instanzen die Baumeigenschaft erfüllen. Die<br />
children-Assoziation ist nun bidirektional mit den Kardinalitäten 0..1↔0..∗. Damit wird erreicht das jeder<br />
Knoten nur genau einen Vaterknoten haben kann. Tree ist in diesem Metamodell nicht mehr gleichzeitig<br />
die Wurzel des Baumes. Daher enthält die Aggregation root der Klasse Tree keine Sequenz <strong>von</strong> Kindknoten<br />
mehr, sondern nur die Referenz auf die Baumwurzel. Dies entspricht der typischen Modellierung <strong>von</strong><br />
Bäumen als Klassendiagramm. Damit verbunden ist eine Semantikänderung der caption-Eigenschaft <strong>von</strong><br />
Tree-Instanzen. Es handelt sich nicht mehr um das Label der Wurzel, sondern eher um einen beschreibenden<br />
Text im Sinne eines Titels oder einer Bildunterschrift.<br />
Für die Elemente <strong>von</strong> Auflistungen ergaben sich keine Änderungen gegenüber dem X-AIM Modell. Da die<br />
Kardinalitäten eine 1..∗ Beziehung vorsehen, konnte auch die Komposition beibehalten werden. Ähnliches<br />
Abbildung 2.15: Adaptiertes AUI-Metamodell, Widgets
42 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
gilt für die Tabelle. Mit Ausnahme der Attributsumbenennung <strong>von</strong> indexX und indexY nach gridX sowie<br />
gridY ergaben sich keine Änderungen.<br />
2.1.4 Modelle für konkrete Oberflächen<br />
Das konkrete Oberflächenmodell (CUI) ist das plattformspezifische Modell im modellgetriebenen Oberflächenentwicklungsprozess.<br />
In dieser letzten Prozessstufe wird die Anwendungsoberfläche mit den UI-<br />
Widgets der ausgewählten Plattform gestaltet.<br />
Im Allgemeinen entsteht eine CUI-Instanz durch Model-To-Model Transformation aus einer Instanz eines<br />
abstrakten Oberflächemodells. Alternativ kann aber auch der aus dem Dialoggraph abgeleitete Mockup-<br />
Prototyp, siehe Unterabschnitt 2.1.2, als AUI angesehen werden und zu einer CUI-Instanz weiterverarbeitet<br />
werden.<br />
Die in Unterabschnitt 2.1.3 angeführten Betrachtungen zum Begriff der Plattform treffen für die Positionierung<br />
des konkreten Oberflächenmodells ebenso zu. Dort wurde begründet, dass im Rahmen dieser<br />
Arbeit Frameworks für WIMP-Oberflächen als Plattform angesehen werden. Auch mit dieser Einschränkung<br />
ist die Menge der in Frage kommenden Metamodelle noch sehr groß. Zwei verschiedene Arten <strong>von</strong><br />
Metamodellen sollen hier betrachtet werden.<br />
1. die XML-abgeleiteten Oberflächenbeschreibungssprachen, siehe auch Abschnitt 1.3<br />
2. Metamodell <strong>von</strong> Java-Swing, siehe Unterabschnitt 4.2.1<br />
XML-abgeleitete Sprachen<br />
In Tabelle 2.1 wird die Verfügbarkeit <strong>von</strong> formalen Beschreibungen der in Unterabschnitt 1.3.1 vorgestellten<br />
XML-UI Beschreibungssprachen gezeigt. Für drei der Modellierungssprachen scheint kein öffentlich<br />
verfügbares Modell (mehr) zu existieren. Ebenfalls drei Sprachen stellen nur eine DTD bereit.<br />
DTD-Grammatiken sind ausreichend zur Prüfung <strong>von</strong> Syntax und Struktur der jeweiligen XML-Strukturen.<br />
Wie bereits in Unterabschnitt 2.1.3 angedeutet, ist es auch möglich, ausgehend <strong>von</strong> einer DTD zu einem<br />
Metamodell als Klassendiagramm zu gelangen. Weil jedoch eine DTD, ihrer Natur nach, eine Reihe <strong>von</strong><br />
Informationen über Datentypen und Wertebereiche nicht enthält, dürfte diese Transformation sinnvoll nur<br />
Name verfügbare Grammatik/Taxonomie/Metamodell<br />
GIML Grammatik liegt als DTD [51] vor<br />
VRIXML keine öffentliche Grammatik, in Grenzen aus [27] ableitbar<br />
ISML keine öffentliche Grammatik<br />
XUL XML Schema verfügbar, Details in Punkt 2.1.4.2<br />
X3USGP DTDs liegen in [78] vor<br />
useML XML Schema verfügbar [131]<br />
UsiXML XML Schema, Rational Rose Modelle verfügbar [132]<br />
XAML XML Schema verfügbar<br />
XIML DTD für XIML1 für Forschungszwecke freigegeben, XIML2 weiter nicht veröffentlicht<br />
UIML XML Schema verfügbar [128]<br />
IM2L keine Spezifikation verfügbar<br />
Tabelle 2.1: Verfügbarkeit eines Metamodells für UIDLs aus Tabelle 1.1
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 43<br />
manuell durchführbar sein. Die fehlenden Puzzlestücke der Semantik müssten durch einen menschlichen<br />
Designer, in Kenntnis der Semantik der einzelnen Sprachelemente, ergänzt werden. Mangels verfügbarer<br />
(X3USGP) oder nicht mehr weiterentwickelter (GIML) Renderer scheint es nicht sinnvoll diesen Aufwand<br />
für GIML und X3USGP zu betreiben. Im Falle <strong>von</strong> XIML ist da<strong>von</strong> auszugehen, dass Puerta und seine<br />
Firma RedWhale Inc. längst über aussagekräftige Modelle verfügen, diese jedoch aus lizenz- oder firmenpolitischen<br />
Gründen nicht veröffentlichen.<br />
Für fünf der UIDLs sind Spezifikationen erhältlich, welche als Quelle zur Erstellung eines Klassenmodells<br />
im MD-UI Prozess tauglich sind. Für UsiXML wird ein solches Modell im Rational Rose Format öffentlich<br />
[132] bereitgestellt.<br />
Woitzel untersuchte im Rahmen einer studentischen Arbeit [147] die Verwendung <strong>von</strong> UsiXML als CUI-<br />
Metamodell. Dabei wurde festgestellt, dass die Erstellung einer konkreten Oberfläche aus dem AUI-Modell,<br />
nach Unterabschnitt 2.1.3, ohne wesentliche Schwierigkeiten machbar ist. Allerdings stellte er auch fest,<br />
dass die Gebrauchstauglichkeit und vor allem die Standardkonformität der veröffentlichten UsiXML-Renderer<br />
unzureichend war. Es scheint daher zur Zeit nützlicher andere UIDLs als UsiXML zu verwenden.<br />
Das im Rahmen des Useware-Ansatzes spezifizierte useML, kurz umrissen dargestellt in 1.3.1.2, wäre<br />
<strong>von</strong> der Papierform ein Kandidat hierfür. Das öffentlich verfügbares Schema der Sprachversion useML<br />
1.0, dient allerdings nur zur Beschreibung <strong>von</strong> Abläufen. Erweiterungen in Richtung CUI-Modellierung<br />
sind derzeit in Arbeit, jedoch lässt sich im Moment das useML-Metamodell nicht als CUI-Metamodell<br />
verwenden.<br />
Für UIML, Kurzvorstellung im Anhang auf Seite 135, sind laut der Projektwebseite [129] bis zu elf verschiedene<br />
Renderer verfügbar. Problematisch ist, dass bei dieser Aufstellung nicht nach den verschiedenen<br />
Sprachversionen unterschieden wird. Dies hat jedoch letztlich keine Relevanz, da aktuell keiner der elf Renderer<br />
tatsächlich öffentlich verfügbar ist. Aus der Kurzbeschreibung der Renderer ist jedoch zu ersehen,<br />
dass UIML zur Anzeige zumeist in HTML, WML oder VoiceXML 2 übersetzt wurde. Leider scheint die<br />
Entwicklung an UIML in den letzten Jahren stillzustehen. Laut Jan van den Bergh wird an UIML weitergearbeitet,<br />
dennoch ist bis auf weiteres die vorläufige Spezifikation 3.1 vom März 2004, verfügbar bei [128],<br />
die aktuellste Veröffentlichung. Die Nichtverfügbarkeit <strong>von</strong> Renderern und das auch sonst augenscheinlich<br />
verwaiste Projekt, lassen da<strong>von</strong> abraten, UIML als CUI-Metamodell einzusetzen.<br />
Damit bleiben <strong>von</strong> den UIDLs aus Tabelle 2.1 noch zwei Sprachen zur Auswahl: XUL und XAML. Beide<br />
werden aktiv weiterentwickelt, stellen aktuelle Renderer bereit und es sind XML-Schemata als Sprachspezifikation<br />
erhältlich. Gleichzeitig sind beide sehr umfangreich, daher war es erforderlich, sich für eine<br />
Sprache zu entscheiden. Die Wahl fiel auf XUL, weil im Rahmen der Arbeitsgruppe bereits eine Reihe<br />
<strong>von</strong> Werkzeugen für diese Sprache entstanden war. Dies ist jedoch nicht als Wertung gegen XAML zu<br />
verstehen.<br />
2.1.4.1 XUL<br />
XUL - das Akronym steht für XML User Interface Language - ist die XML-UIDL für konkrete <strong>Benutzungsoberflächen</strong><br />
im Prozessmodell nach Abbildung 2.1. Die Entwicklung und Spezifikation dieser Sprache<br />
ist eng mit der Gecko-Rendering Engine [49] verbunden. Gecko stellt die Implementierung <strong>von</strong> XUL<br />
und spezifiziert damit den de facto Standard. Eine formale Spezifikation existiert nicht. Aus den öffentlich<br />
verfügbaren Ressourcen kann dennoch ein Metamodell abgeleitet werden, die Vorgehensweise wird in<br />
Punkt 2.1.4.2 erläutert.<br />
2 für Sprachinterfaces
44 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Hauptsächlicher Bestandteil der XUL sind Widgets zur Deklaration <strong>von</strong> WIMP-Oberflächen. Das Sprachdesign<br />
sieht eine Trennung <strong>von</strong> Layout, Design und Dynamik vor. Dazu wird XUL eng verzahnt mit zwei<br />
weiteren Sprachen eingesetzt. Das ist zum einen die Auszeichnungssprache CSS - Cascading Style Sheets,<br />
erläutert in Unterabschnitt A.5.1 - und andererseits die Programmiersprache JavaScript, bzw. seit deren<br />
Standardisierung auch als ECMAScript bekannt. Eine kurze Ausführung zu JavaScript findet sich im Unterabschnitt<br />
A.5.2.<br />
Der XUL-Teil einer Oberflächenbeschreibung deklariert nur die eingesetzten Widgets und deren Layout.<br />
Das Design wird mit CSS definiert, JavaScript kommt zur Definition der Nutzerinteraktionen zum Einsatz.<br />
Verwendung <strong>von</strong> JavaScript und CSS innerhalb XUL<br />
Die Elemente der XUL dienen der Beschreibung der Struktur der Oberfläche und definieren die anzuzeigenden<br />
Daten. Details der Darstellung, auch grundlegende Dinge wie Farben und Schriftarten, werden nicht<br />
mit den Sprachmitteln der XUL ausgedrückt. Jeder XUL-Renderer setzt zur Darstellung hierfür eigene<br />
Standardwerte ein.<br />
Die Anpassung der Visualisierung erfolgt über CSS. Dazu verfügt jedes XUL-Widget über ein style-Attribut<br />
in welchem die relevanten CSS-Schlüssel, und die dafür gesetzten Werte, für dieses Element hinterlegt<br />
werden. Der in Unterabschnitt A.5.1 dargestellte Selektor-Mechanismus ist für die meisten Renderer zwar<br />
möglich, bevorzugt eingesetzt werden soll jedoch das style-Attribut.<br />
JavaScript wird im Rahmen der XUL für den gleichen Zweck verwendet wie in HTML-Webseiten. Es dient<br />
zur Implementierung wesentlicher Teile der Dynamik der Oberfläche. Im Gegensatz zu der Integration <strong>von</strong><br />
CSS erfolgt der JavaScript-Einsatz nicht über ein einziges spezielles Attribut 3 . Stattdessen existiert eine<br />
Reihe Attribute, die im Sinne <strong>von</strong> Eventhandlern die Reaktion des Widgets auf ein Oberflächen-Ereignis<br />
festlegen. Der Sprachstandard <strong>von</strong> XUL definiert über 30 solcher Events, z.B. onfocus wenn ein Widget den<br />
Focus erhält oder onkeypress für Tastendrücke. Einen Eindruck über das Zusammenspiel aller drei Sprachen<br />
gibt das Beispiel in Unterabschnitt A.5.3.<br />
2.1.4.2 XUL Metamodell<br />
Wie bereits dargelegt, existiert keine formale Spezifikation für XUL, und betrachtet man dessen Entwicklungsprozess,<br />
wird es auch in absehbarer Zeit keine solche geben. Einer Spezifikation am nächsten kommen<br />
die in unregelmäßigen Abständen, halb-offiziell und etwas indirekt, veröffentlichten XML-Schema<br />
<strong>von</strong> XUL.<br />
Indirekt meint in diesem Fall, dass das Schema selbst nicht bereitgestellt wird. Wie man zu einem Schema<br />
gelangen kann, beschreibt [155]. Es läuft darauf hinaus, aus zwei Quelldateien im XML-Format über ebenfalls<br />
bereitgestellte XSLT-Transformationen das Schema zu generieren. Die Quellen sind die sogenannte<br />
XUL-Elementreferenz und die XUL-Strukturreferenz. Beide liegen in einem proprietären Format vor und<br />
enthalten sowohl die Grammatik als auch die notwendigen Typinformationen.<br />
Zu den Standardmechanismen <strong>von</strong> EMF gehört ein sogenannter Model-Importer für XML-Schemata. Dessen<br />
Zweck ist es, für ein Schema das korrespondierende Ecore-Modell zu erzeugen. Dieser Importalgorithmus<br />
wurde für das XUL-Schema benutzt.<br />
Wie bei vielen Automatismen war das Ergebnis dieser Model-To-Model Transformation nicht sofort zufriedenstellend.<br />
Als Problem zu nennen sind hier die möglicherweise etwas unübliche Benennung der Metaklassen,<br />
die Aufteilung der Eigenschaften jedes Widgets auf zwei Klassen, eine große Anzahl numme-<br />
3 Ausnahme ist das -Tag mit seinem Attribut script
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 45<br />
rierter und anonymer Typen sowie generell eine unnötig komplizierte Typstruktur. Möglicherweise ergaben<br />
sich diese Probleme als Konsequenz daraus, dass es sich bei der Ecore-Erzeugung um die zweite komplett<br />
automatische Transformation der Ausgangsdaten (XUL Element- und Strukturreferenz) in Folge handelte.<br />
Die Behebung dieser Unzulänglichkeiten ist im wesentlichen ein rein manueller Prozess. Er kann ergebnisneutral<br />
sowohl im XML-Schema als auch im erzeugten Ecore-Modell durchgeführt werden. Ich habe mich<br />
dafür entschieden die notwendigen Modifikationen im Ecore-Modell vorzunehmen. Einerseits waren dort<br />
ohnehin die zuvor bereits angerissenen Änderungen vorzunehmen, andererseits war die mir zur Verfügung<br />
stehende Werkzeugunterstützung besser zur Ecore- als zur Schema-Bearbeitung geeignet. Ausführlichere<br />
technische Details finden sich im Anhang, siehe Abschnitt C.1.<br />
In Abbildung 2.16 wird ein Ausschnitt des resultierenden XUL-Metamodells dargestellt. Wegen der Dimensionen<br />
dieses Modells scheint eine vollständige Angabe an diesem Ort nicht sinnvoll, es wird stattdessen<br />
unter anderem hier [79] bereitgestellt.<br />
Insgesamt enthält das XUL-Metamodell in der nachbearbeiteten Version 151 Klassen und Interfaces mit<br />
insgesamt 443 Attributen, dazu kommen weitere 31 Datentypen. Dabei handelt es sich ausschließlich um<br />
Enumerations. Selbstverständlich werden nicht alle der 131 Klassen genutzt um UI-Widgets zu beschreiben.<br />
Insbesondere enthält XUL eine eigene Templatesprache, Metaklassen die Elemente dieser Sprache<br />
definieren sind für ein CUI-Modell nicht unbedingt notwendig. Es besteht jedoch ebenfalls kein zwingender<br />
Grund diese zu entfernen, daher wurden sie beibehalten. Für eine ausführliche Erläuterung des<br />
XUL-Metamodells sei auf den Anhang, Abschnitt C.2, verwiesen.<br />
Zusammenfassung zum modellgetriebenen Prozess<br />
In den vorstehenden Abschnitten wurden Metamodelle, Konzepte und Transformationsansätze vorgestellt,<br />
mit denen der transformationsorientierte modellgetriebene UI-Entwicklungsprozess gemäß Abbildung-<br />
2.1 umgesetzt werden kann. Das XUL-Metamodell für die konkrete Oberfläche bildet gewissermaßen den<br />
Abschluss des Prozesses.<br />
Im Rahmen dieser Arbeit wurde noch ein weiteres Metamodell für konkrete <strong>Benutzungsoberflächen</strong> entwickelt.<br />
Das in Unterabschnitt 4.2.1 erstellte Oberflächenmodell für das Swing-Framework kann nach<br />
Einführung <strong>von</strong> Task-Referenzen ebenfalls im hier beschriebenen modellgetriebenen Prozess eingesetzt<br />
werden.<br />
Abbildung 2.16: Ausschnitt des XUL-Metamodells
46 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
2.1.4.3 Grafischer XUL-Editor<br />
Bei der Entwicklung <strong>von</strong> grafischen <strong>Benutzungsoberflächen</strong> kann permanentes visuelles Feedback eine<br />
sehr nützliche Hilfe sein. Viele Werkzeuge zur Unterstützung und Durchführung des Rostocker modellgetriebenen<br />
Prozesses sind daher in der Lage die Auswirkungen der getroffenen Designentscheidungen<br />
grafisch darzustellen. Auch für die Modellebene der konkreten Oberfläche existiert ein solches Tool, der<br />
grafische XUL-Editor. Die Abbildung 2.17 zeigt einen Screenshot dieser Anwendung.<br />
Die Wurzeln dieses Editors liegen im Jahr 2003, ursprünglich entwickelt als grafischer WYSIWYG 4 GUI-<br />
Builder für Java Swing namens V4ALL [7]. Er verfügt über die gewöhnlichen Basisfeatures solcher Editoren,<br />
bietet beispielsweise Drag&Drop für Elementerzeugung und Platzierung. Die ursprüngliche Version<br />
[7] des Editors wurde außerhalb und komplett unabhängig <strong>von</strong> der Universität Rostock entwickelt. Da<br />
V4ALL aber als quelloffene Software zur Verfügung gestellt wurde, konnten studentische Arbeiten, sowie<br />
eigene Änderungen, darauf aufbauen und den aktuellen Entwicklungsstand schaffen.<br />
Hier in Rostock wurde V4ALL im Laufe der Zeit zur Test- und Integrationsumgebung für diverse Ideen und<br />
Konzepte im Rahmen der modellgetriebenen UI-Entwicklung. Zu den durchgeführten Änderungen zählt,<br />
dass V4ALL um Funktionalität ergänzt wurde deklarative Oberflächen mit XUL zu designen. Anfangs noch<br />
vorgesehene Mechanismen zur <strong>Generierung</strong> <strong>von</strong> Java-Quellcode sind im Zuge mehrfacher Umgestaltungen<br />
der Software entfernt worden. V4ALL wurde damit zu einem reinen XUL-Editor. In seiner aktuellen<br />
Inkarnation wird der Editor daher schlicht als XULE, für XUL-Editor, bezeichnet.<br />
XULE ist ein Eclipse-Plugin und seine technische Grundlage das Graphical Editing Framework (GEF) [47]<br />
des Eclipse-Projekts. Das GEF forciert einen Model-View-Controller Ansatz für die damit erstellten Editoren,<br />
dementsprechend folgt auch XULE diesem Pattern. Ursprünglich wurden alle dafür notwendigen<br />
Klassen einmal manuell erzeugt. Schon bei der erstmaligen Erstellung eine beeindruckende Fleißarbeit,<br />
erwuchsen bei der späteren Wartung und Weiterentwicklung eine Reihe <strong>von</strong> Schwierigkeiten. Zu nennen<br />
wären hier Doppel- und Mehrfachimplementierungen, regelmäßige Inkonsistenzen im Lade- und Speicher-<br />
4 What You See Is What You Get<br />
Abbildung 2.17: XULE - XUL-UI im Bearbeitungsmodus geöffnet
2.1. BESCHREIBUNG DES ROSTOCKER PROZESSMODELLS 47<br />
zyklus, fehlende Eigenschafteneditoren und Weiteres. Besonders unpraktisch war auch, dass es nie gelang,<br />
den durch XULE generierten XUL-Quellcode vollständig standardkonform 5 zu erhalten.<br />
Seit dem Vorliegen des XUL-Metamodells konnte darüber nachgedacht werden, dieses Metamodell in geeigneter<br />
Form für das interne Modell <strong>von</strong> XULE nutzbar zu machen. Denn vermutlich ließen sich dadurch<br />
einige der zuvor erwähnten Schwierigkeiten mit den manuell erstellten Modellen beheben. Als Hauptvorteil<br />
für Nutzer würde sich eine hundertprozentige Standardkonformität der bearbeitbaren Eigenschaften<br />
und des erzeugten Modells ergeben. Aus softwaretechnischer Sicht gäbe es ebenfalls eine Reihe signifikanter<br />
Vereinfachungen. Die internen Modellklassen des MVC-Paradigmas würden entfallen und Standardaufgaben<br />
wie die Modell(de-)serialisierung könnten durch erprobte EMF [36]-Mechanismen erfolgen.<br />
Prinzipiell sollte, bei konsequenter Umsetzung des MVC-Patterns, das Austauschen des Modells einfach<br />
möglich sein und lediglich Anpassungen in der Controller-Komponente notwendig werden.<br />
Leider wichen auch im Falle des XULE Theorie und Praxis <strong>von</strong> einander ab. Es zeigte sich, dass das via<br />
EMF generierte XUL-Modell das bisherige interne Modell nicht vollständig ersetzen konnte; beispielsweise<br />
sei an dieser Stelle an die Nichtabbildbarkeit <strong>von</strong> Farben und Schriftarten in XUL erinnert, obwohl<br />
dieses nicht das gravierendste Problem darstellte. Es gab zwei Alternativen: entweder müsste das XUL-<br />
Metamodell um XUL-fremde Eigenschaften erweitert werden oder aber die bisherige interne Modellstruktur<br />
würde beibehalten werden, jedoch so modifiziert, dass das die XUL-Eigenschaften in Instanzen des<br />
XUL-Metamodells gespeichert würden. Trotzdem die zweite Variante bereits im Vorhinein als umständlicher<br />
erkannt wurde, wurde entschieden diesen Weg zu gehen. Diese Variante ermöglichte es nämlich,<br />
die Umwandlung des internen Modells schrittweise vorzunehmen und zwar indem nach und nach Teilfunktionalitäten<br />
des ehemaligen internen Modells an die XUL-Instanz ausgegliedert wurden. Zusätzliche<br />
Schwierigkeiten ergaben sich auch daraus, dass die im MVC-Paradigma vorgesehene strikte Trennung aller<br />
drei Teile, nach Jahren ständiger Umbauarbeiten, nicht mehr bestand. Letztlich führte die Ersetzung bzw.<br />
5 d.h. Interpretationsidentisch zur Gecko-Engine<br />
Abbildung 2.18: XULE - Strukturübersicht und Eigenschaftenbearbeitung
48 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
Ergänzung des internen Modells durch das generierte XUL-Modell zur einem umfangreichen mehrmonatigen<br />
Redesign des XULE Quellcodes.<br />
Die wesentlichen Ergebnisse dieser Re-Implementierung des XULE sind in der Abbildung 2.18 zu sehen.<br />
Im unteren Bereich, d.h. bei den „Properties“, können nun alle im Metamodell definierten Eigenschaften<br />
eines Elementes bearbeitet werden. Diese Ansicht wird nahezu vollständig mittels des automatisch<br />
generierten XUL Ecore-Editors dargestellt. Minimale Änderungen waren lediglich erforderlich um Änderungsbenachrichtigungen<br />
und damit die Undo/Redo-Funktionalität des XULE sicherzustellen.<br />
Die ebenfalls erkennbare „Outline“-Ansicht stellt die effektive Hierarchie der XUL-Modellelemente dar.<br />
Genutzt wird dieser Mechanismus insbesondere zur Bearbeitung der implizit visualisierten Sprachelemente.<br />
Dazu zählen beispielsweise die Spaltenüberschriften in Bäumen oder Listen sowie deren zugehörige<br />
Kontrollstrukturen. Diese Sprachelemente werden zwar nicht direkt als Widget an der Oberfläche dargestellt,<br />
es muss aber dennoch möglich sein, deren Eigenschaften zu bearbeiten.<br />
Oberflächenwidgets sind bei der XUL nicht immer 1 : 1 als ein Sprachelement umgesetzt. Diese Fällen bedürfen<br />
besonderer Beachtung bei der Implementierung eines grafischen modellbasierten Editors. Bei Bäumen,<br />
Listen und Tabellenstrukturen ist der Zweck dieses Sprachdesigns offensichtlich, bei anderen konkret<br />
„GroupBox“en und „Tabs“ ˜weniger. Die Überschriften der beiden letztgenannten Widgets werden separat,<br />
d.h. mit jeweils eigenen Metaklassen, definiert. Beide dieser Metaklassen definieren nur wenige Attribute<br />
welche problemlos ebenso in der eigentlichen Widget-Hauptklasse hätten definiert werden können.<br />
Im Ecore-Modell könnte diese Herangehensweise genutzt werden, um eine Überschrift einmalig zu definieren,<br />
aber <strong>von</strong> mehreren Widgets benutzen zu lassen. Mit den in XUL benutzten XML-Mechanismen<br />
kann dieser Vorteil aus technischen Gründen nicht genutzt werden. Da scheinbar ohnehin eine Sonderbehandlung<br />
notwendig werden würde, konnte bei der Umsetzung in XULE ausprobiert werden, inwieweit<br />
es nützlich wäre, jeweils die Klasse des Überschriftenelementes und die „Haupt“-Widgetklasse, per Mehrfachvererbung,<br />
zu einem einzigen Typ zusammenzuführen.<br />
Für die „Tabs“wurde die Klasse CombinedTabpanelType im XUL-Metamodell eingeführt, als Unterklasse<br />
<strong>von</strong> TabpanelType und TabType. Damit wurden alle Tab-bezogenen Eigenschaften, wie geplant und erwartet,<br />
in einem Typ vereint und bearbeitbar. Leider wird dieser neue Elementtyp <strong>von</strong> keinem XUL-Renderer, außer<br />
dem XULE, interpretiert. Es musste eine aufwändige Einzelfallbehandlung beim Laden und Speichern<br />
der Modellinstanzen implementiert werden, die zur Serialisierung wiederum auf die Standardsprachelemente<br />
zurückgreift. Im Vergleich mit den „GroupBox“en, bei denen als Vergleichselement zunächst kein<br />
spezieller verschmolzener Untertyp erstellt wurde, ergaben sich auch keine signifikanten Erleichterungen<br />
bei der Benutzung <strong>von</strong> XULE. Diese Vereinfachungsidee erwies sich insgesamt als unpraktisch und wurde<br />
daher nicht weiterverfolgt.<br />
Mit XULE steht ein standardkonform arbeitender grafischer XUL-Editor zur Verfügung. Wesentliche Teile<br />
dieses Werkzeugs wurden modellbasiert entwickelt und sind vergleichsweise einfach an Weiterentwicklungen<br />
der XUL anpassbar.<br />
2.2 Transformationstechniken<br />
Modelltransformationen sind der Kern einer modellgetriebenen Entwicklung. Normalerweise werden die<br />
denkbaren Transformationen in zwei Klassen eingeteilt. Die texterzeugenden Model-To-Text (M2T) Transformationen<br />
erstellen aus Modellinstanzen beliebigen Text. Transformationen zwischen Modellen werden<br />
dagegen als Model-To-Model (M2M) Transformationen bezeichnet. Je nach Betrachtungsweise, insbesondere<br />
dessen was man als Modell ansieht, kann man M2M-Transformationen als Spezialfall der M2T
2.2. TRANSFORMATIONSTECHNIKEN 49<br />
auffassen.<br />
Im Folgenden werden aktuell verbreitete Modelltransformationstechniken skizziert und deren jeweilige<br />
Verwendung im Rahmen dieser Arbeit erklärt. Diese Auflistung erhebt keinen Anspruch auf Vollständigkeit,<br />
denn neben den erwähnten Techniken existiert eine schwer überblickbare Anzahl weiterer Techniken.<br />
2.2.1 Model-To-Text<br />
Die Texterzeugung ist eine häufig wiederkehrende Aufgabe in Anwendungssystemen. Oftmals folgen diese<br />
Texte einem generellen Muster und müssen für den jeweiligen Adressaten nur an wenigen Stellen angepasst<br />
werden. Für diesen Einsatzzweck werden sogenannte Template Engines genutzt. Zwar ist Quantität<br />
kein zulässiger Indikator für Qualität, dennoch illustriert die Tatsache, dass in dem Wikipedia-Artikel zum<br />
Thema „Template Engine“ [145] über 40, der Community öffentlich bekannte, Template Engines erwähnt<br />
sind, dass es sich hier um ein typisches wiederkehrendes Problem handelt.<br />
In der modellgetriebenen Softwareentwicklung werden M2T-Transformationen oft genutzt um Quellcode<br />
zu erzeugen. Im Fall der MD-UID etwa den Quellcode der endgültigen Benutzungsoberfläche (FUI).<br />
2.2.1.1 XSLT<br />
XSLT, die Extensible Stylesheet Language Transformations, sei hier als erster Vertreter genannt. Dabei<br />
handelt es sich um eine deklarative Programmiersprache zur Umwandlung <strong>von</strong> XML-Dokumenten. Der<br />
besondere Vorteil dieser Sprache liegt in ihrer fast flächendeckenden Verbreitung, da nahezu alle modernen<br />
Browser XSLT Transformatoren enthalten. XSLT wird durch das World Wide Web Consortium (W3C)<br />
standardisiert [21], aktuell liegt die Version 2.0 vor.<br />
Primärer Einsatzzweck, und eine Reihe <strong>von</strong> Sprachkonstrukten ist nur hierfür sinnvoll, <strong>von</strong> XSLT ist<br />
die Erzeugung <strong>von</strong> XML-Dokumenten aus XML-Dokumenten. Während die Eingabedaten stets XML-<br />
Dokumente sein müssen, kann XSLT ebenfalls eingesetzt werden um beliebigen Text zu generieren.<br />
XSLT ist für diese Arbeit nur am Rande ein Thema. In einer der Vorstufen des XUL-Metamodells wird diese<br />
Transformationstechnik benutzt, um aus einem XML-Dokument eine XML-Schemadeklaration zu generieren.<br />
Neben dieser Anwendung, wurde ebenfalls versucht XSLT-Deklarationen zu definieren welche aus<br />
JavaDoc Ecore-Klassendeklarationen extrahieren bzw. generieren. Nachdem die prinzipielle Machbarkeit<br />
dieses Ansatzes gezeigt war, d.h. aus dem JavaDoc trivialer Klassen konnten äquivalente Ecore-Klassen<br />
erzeugt werden, wurde diese Idee nicht weiterverfolgt. Das Vorgehen erwies sich als zu unpraktisch und<br />
unflexibel, außerdem sind diverse nützliche Typ-Informationen bereits nicht mehr in den JavaDoc-HTML<br />
Dateien enthalten. Statt daher umständlich JavaDoc zu parsen, wurde für diesen Anwendungsfall das in<br />
Punkt 4.1.3.1 dargestellte Prinzip des Eingriffs in die JavaDoc-Erzeugung entwickelt.<br />
2.2.1.2 xPand<br />
Die Template-Sprache xPand aus dem openArchitectureWare-Projekt [34] wurde inzwischen ein Kernbestandteil<br />
des Eclipse Modeling Project (EMP). Ein typischer Anwendungsfall für xPand ist die Erzeugung<br />
<strong>von</strong> Quellcode aus Modellinstanzen. Im EMP wird xPand zur Erzeugung beliebiger Texte aus Ecore-<br />
Instanzen genutzt. Neben der reinen Texterzeugung bietet die Sprache eine Reihe zusätzlicher Mechanismen<br />
wie Modellvalidierung, Aspektorientierung und polymorphe Template-Aufrufe.<br />
Auch im Rostocker MD-UID Prozeß wird xPand angewendet. Beispielsweise bei der in Unterabschnitt<br />
2.1.2 gezeigten Erstellung der Mockup-Prototypen aus Dialoggraphen. Das dort angeführte Listing 2.2
50 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
vermittelt einen Eindruck der xPand-Syntax.<br />
Für die im Abschnitt 3.3 weiterentwickelte Pattern-Beschreibungssprache PLML wird ebenfalls xPand<br />
genutzt. Die xPand-Templates dienen hier dazu, aus den Patterndefinitionen in einer selbst definierten Deklarationssprache,<br />
Patternbeschreibungen in einer standardisierten Sprache (PLML) zu generieren. Es existieren<br />
verschiedene Templates, die jeweils an die Ziel-Sprachversion <strong>von</strong> PLML angepasst worden.<br />
Eine weitere Verwendung für xPand ergab sich bei einer gemeinsamen Arbeit mit Brüning [16], es ging um<br />
den Versuch MD-UID mit deklarativer Workflow-Modellierung zu verbinden. Ein Ergebnis dieser Kombination<br />
waren objektorientierte Prozessmodelle, deren Visualisierung über das XUL-Metamodell definiert<br />
wurde. Die <strong>Generierung</strong> der tatsächlichen <strong>Benutzungsoberflächen</strong> übernahmen bei diesem Ansatz xPand-<br />
Templates. Leider traten im Laufe dieser Zusammenarbeit einige Schwierigkeiten im Zusammenhang mit<br />
dem Polymorphie-Konzept <strong>von</strong> xPand zu Tage, unter bestimmten Umständen waren die Template-Aufrufe<br />
nicht deterministisch, sondern scheinbar bei jedem Durchlauf zufällig gewählt. Unter anderem auf Grund<br />
dieses Problems erfolgte für weiteren Arbeiten der Wechsel zu Acceleo als Standard-M2T Sprache.<br />
2.2.1.3 Acceleo<br />
Auch Acceleo [83] gehört inzwischen zu den Kernprojekten des Eclipse Modeling Projects, entwickelt<br />
wurde die Sprache ursprünglich <strong>von</strong> der französischen Firma Obeo. Das Ziel <strong>von</strong> Acceleo ist die pragmatische<br />
Umsetzung des OMG Model-To-Text Standards [58] im Sinne einer Referenzimplementierung. Eine<br />
vollständige Umsetzung des Standards wird wegen dessen diverser Errata nicht angestrebt.<br />
Grundsätzlich dient Acceleo zur Transformation <strong>von</strong> Ecore-Instanzen in beliebigen Text. Es ist eng an die<br />
OCL [84] gekoppelt, OCL-Terme werden z.B. für Selektions- und Iterationsausdrücke eingesetzt.<br />
Zur Unterstützung des MD-UID Prozess wurden eine Reihe <strong>von</strong> Acceleo-Transformationen entwickelt. In<br />
einer typischen M2T-Anwendung wird die Sprache z.B. genutzt, um aus Instanzen des Swing-Ecoremodells,<br />
siehe Unterabschnitt 4.2.1, lauffähigen Java-Quellcode zu erstellen. Auch wurde eine Reihe Grafiken und<br />
Tabellen dieser Dissertation mittels Acceleo aus Ecore-Modellinstanzen erzeugt. Eine wichtige Rolle spielt<br />
Acceleo auch bei der Erstellung der Patternkataloge im Unterabschnitt 3.5.2. In diesem Prozess werden<br />
M2T-Transformationen eingesetzt, um die dynamisch instantiierten PLML-Kataloge korrekt in ihrer tDSL-<br />
Form zu serialisieren.<br />
2.2.1.4 Java Emitter Templates<br />
Die Java Emitter Templates [22] (JET) sind eine Basistechnologie des EMP. Denn die <strong>Generierung</strong> des<br />
Java-Quellcodes für die Ecore-Modelle, für den Standardeditor und das Testgerüst erfolgen über JET. Die<br />
JET sind eine Entwicklung der IBM, die aktuelle Version ist die JET2-Template Engine.<br />
Das Grundprinzip ist ähnlich dem der Java Server Pages: so enthält ein JET-Template statischen Inhalt und<br />
JET-Direktiven. Bei den ursprünglichen JET sind diese Direktiven, bis auf einige wenige Spezialkommandos,<br />
normaler Java-Quellcode. Die JET-Engine verwebt die Direktiven mit dem statischen Inhalt, dabei<br />
entsteht Quellcode einer Java-Klasse, dieser wird kompiliert und dann für die Eingabedaten ggf. mehrfach<br />
ausgeführt. Mit JET2 wurde die Anbindung verwandter Technologien wesentlich vereinfacht, beispielsweise<br />
kann nun XPath verwendet werden, außerdem wurden Sprachkonstrukte für regelmäßig auftretende<br />
Tätigkeiten wie Iterationen oder Auswahlen eingeführt.<br />
Außer selbstverständlich zur <strong>Generierung</strong> des Java-Modellquellcodes für die diversen Ecore-Modelle wird<br />
JET im Rostocker MD-UID Prozess nicht genutzt. Dies ist insbesondere dem nur schwer realisierbaren<br />
Tracing und dem damit sehr umständlichen Debugging geschuldet, d.h. aus rein praktischen Grün-
2.2. TRANSFORMATIONSTECHNIKEN 51<br />
den. Die Erfahrungen mit JET entstammen einem Versuch, die internen Klassen des XULE mittels JET-<br />
Transformationen über dem XUL-Metamodell zu erzeugen. Dies sollte zunächst durch Anpassen der Standard-Ecore-Templates<br />
realisiert werden. Im Erfolgsfall wären die Vorteile gewesen, nicht alles neu implementieren<br />
zu müssen und den ausgereiften Build- und Konfigurationsmechanismus des EMP mitbenutzen<br />
zu können. Die Komplexität und Wartungsresistenz der Ecore-JET-Templates, in Kombination mit<br />
den langwierigen Debugging-Prozessen, führten jedoch zur Einstellung dieses Versuchs. Alternativ wäre<br />
es möglich gewesen anstelle der Anpassung der Ecore-JET-Templates mit vollständig selbst entwickelten<br />
Templates zu arbeiten. Da aber die Vorteile JETs, insbesondere die Ausführungsgeschwindigkeit bei großen<br />
Modellen dank der Compilierung, die genannten Nachteile aus meiner Sicht nicht egalisieren können, kam<br />
JET in der Folge nicht weiter zum Einsatz.<br />
2.2.2 Model-To-Model<br />
Wie bereits in der Einführung dargelegt, sind Transformation zwischen Modellen das Wesen einer modellgetriebenen<br />
Softwareentwicklung. Dennoch existieren vergleichsweise wenige Transformationssprachen<br />
für diesen Zweck. Die vermeintlich bekanntesten Techniken im Umfeld des Eclipse Modeling Projects<br />
sind ATL, QVT und Kermeta. Diese werden nachfolgend kurz vorgestellt.<br />
Wenn, wie im EMP üblich, die Serialisierungen der Modelle textuelle XML-Strukturen sind, dann lassen<br />
sich Model-To-Text Techniken ebenfalls bis zu einem gewissen Grad als Model-To-Model Transformationen<br />
verwenden. Außerhalb des EMP werden oft auch Graphentransformationen für diesen Zweck genutzt.<br />
Das in Punkt 1.3.1.1 vorgestellte UsiXML setzt z.B. auf diese Technologie.<br />
2.2.2.1 QVT operational<br />
Der OMG-Standard zu QVT [98] - Query View Transformation - definiert eine hybride, d.h. eine deklarative<br />
und imperative, Sprache für Modelltransformationen. QVT als OMG Standard integriert OCL [84]<br />
sehr eng. Die Unterebenen QVT Relations (QVTr) und QVT Core (QVTc) bilden den deklarativen Teil<br />
<strong>von</strong> QVT. Während mit QVT Operational (QVTo) im Standard eine imperative Modelltransformationssprache<br />
definiert wird. Es existieren Abhängigkeiten zwischen den drei QVT-Sprachteilen, diese sind hier<br />
allerdings nicht <strong>von</strong> Bedeutung.<br />
Zum Einsatz im Rahmen dieser Arbeit und im vorgestellten MD-UID Prozess gelangt ausschließlich QVT<br />
Operational.<br />
Hauptsprachbestandteile sind Mappings, die eigentlichen Transformationsbeschreibungen, und Queries,<br />
OCL-Aufrufe mit Wertrückgaben. Beide werden jeweils wie Funktionen normaler Programmiersprachen<br />
deklariert, d.h. mit Funktionsnamen, Eingabe und Ausgabeparametern. Eine QVTo-Transformation beginnt<br />
immer mit dem parametrisierten Aufruf eines Mappings. Dabei werden die in dem Mapping festgelegten<br />
Objekterzeugungen oder Funktionsaufrufe sequentiell abgearbeitet und das Verarbeitungsergebnis dem<br />
Aufrufer zur Verfügung gestellt. Patternmatching und andere deklarative Konzepte sind QVTr vorbehalten<br />
und werden <strong>von</strong> QVTo nicht unterstützt.<br />
Im Rostocker MD-UID Prozess wird QVTo für mehrere Zwecke genutzt. Bei der Erstellung, Wartung<br />
und Pflege der Patternkataloge wird das Verweben der Instanzen <strong>von</strong> PLML mit den Ergänzungen aus<br />
den PLMLComponent-Instanzen, siehe Unterabschnitt 3.5.3, mittels QVTo durchgeführt. Eine andere<br />
Verwendung ist das Mapping <strong>von</strong> Swing-Ecore-Instanzen auf XUL-Ecore-Instanzen, eine CUI-To-CUI<br />
Transformation. Darüber hinaus können die Implementierungen einiger Patternkomponenten mit QVTo<br />
beschrieben werden.
52 KAPITEL 2. MODELLGETRIEBENE GENERIERUNG VON BENUTZUNGSOBERFLÄCHEN<br />
2.2.2.2 Atlas Transformation Language<br />
Die Atlas Transformation Language [67] (ATL) ist eine französische Entwicklung und entstand als Bestandteil<br />
der sogenannten ATLAS Model Management Architecture (AMMA). Auch ATL gehört inzwischen<br />
zu den Bestandteilen des Eclipse Modeling Projects. Gemäß der Selbstdarstellung der ATL-Entwickler<br />
Jouault et al. in [67] ist ATL eine QVT-ähnliche Transformationssprache. Beide Sprachen unterscheiden<br />
sich zwar in ihrer Syntax, es finden sich jedoch ein Reihe ähnlicher Konzepte.<br />
Besonders erwähnenswert ist ATL auch wegen seines sogenannten „Modell-Zoos“ [45]. Einer öffentlich<br />
bereitgestellten Sammlung <strong>von</strong> ATL Transformationen die für eigene Projekte eingesetzt werden können.<br />
Dennoch wird ATL im Rostocker MD-UID Prozess an keiner Stelle für Transformationen benutzt. Das<br />
liegt daran, dass eine Auswahlentscheidung zwischen QVT und ATL getroffen werden musste. Weil ATL<br />
über keine einzigartigen Funktionalitäten verfügt, die für diese Arbeit nützlich wären, fiel die Wahl auf die<br />
offiziell standardisierte Sprache QVT.<br />
2.2.2.3 Kermeta<br />
Das Projekt Kermeta [68] stellt neben der Sprache auch noch eine komplette Entwicklungsumgebung bereit.<br />
Auch dabei handelt es sich um Eclipse-Plugins, die jedoch ohne offizielle Anbindung an das Eclipse<br />
Modeling Project entwickelt werden. Dennoch kann Kermeta Ecore-Modelle verarbeiten.<br />
Kermeta ist zunächst eine textuelle domänenspezifische Sprache zur Deklaration <strong>von</strong> Metamodellen, deren<br />
Syntax diverse Parallelen zu der der Sprache USE [53] hat, USE selbst wurde unter anderem in dem bereits<br />
erwähnten Versuch [16] zur Verbindung <strong>von</strong> Workflow und MD-UID Entwicklung genutzt. Die mit Kermeta<br />
deklarierten Modelle, konkret die implementierten Operationen der Metaklassen, lassen sich in der<br />
Projekt- Umgebung ausführen.<br />
In Unterabschnitt 4.1.4 wird diese Fähigkeit Kermetas benutzt, um mit einer Model-To-Model Transformation<br />
das Metamodell <strong>von</strong> Java Swing zu reduzieren. Ansonsten erfolgte bisher kein weiterer Einsatz <strong>von</strong><br />
Kermeta im hier vorgestellten MD-UID Prozess.<br />
Zusammenfassung<br />
Das Kapitel 2 stellte alle wesentlichen Modelle, Verfahren und Techniken vor, die im Rostocker Forschungsansatz,<br />
eines modellgetriebenen Oberflächenentwicklungsprozesses, relevant sind. Dieser Prozess<br />
stellt den konzeptuellen Rahmen der nachfolgend vorgestellten weiteren Arbeiten und ist daher <strong>von</strong> grundlegender<br />
Bedeutung.
Kapitel 3<br />
Patterns und Komponenten<br />
Allgemein versteht man unter Patterns anerkannte, nachgewiesenermaßen erfolgreiche und daher empfohlene<br />
Lösungen für regelmäßig auftretende Designprobleme. Der Begriff geht zurück auf Alexander [4], er<br />
führte die Idee mit einer Veröffentlichung über Pattern in der Architektur ein. Auch in vielen Bereichen<br />
der Softwaretechnik, bzw. der Informatik allgemein, konnten seitdem eine Reihe <strong>von</strong> Pattern identifiziert<br />
werden. Die vermutlich bekannteste Patternsammlung ist die <strong>von</strong> Gamma et al. [48] über Patterns in der<br />
Objektorientierung, im Folgenden als GoF (Gang of Four) abgekürzt.<br />
Für den Bereich der Human Computer Interaction wurden ebenfalls Patterns vorgeschlagen und gesammelt.<br />
Die in dieser Domäne vorgeschlagenen Patterns beschreiben unter anderem „best-practices“ für die<br />
Navigation innerhalb <strong>von</strong> Anwendungen, für das Layout <strong>von</strong> Oberflächen oder deren Eingabemodalitäten.<br />
Manche Autoren sehen auch die Konzeption ganzer Webseiten 1 als so typisch an, dass sie deren Arrangement<br />
als Pattern vorschlagen.<br />
3.1 Pattern-Languages<br />
Prinzipiell kann ein Autor jedes wiederholbare Muster und jede nutzbare Vorlage als Pattern bezeichnen.<br />
Es gibt keine Normierungskörperschaft für Patterns, einen gewissen legislativen Charakter hat lediglich<br />
die Veröffentlichung in einem allgemein anerkannten Pattern-Katalog. Solche Sammlungen <strong>von</strong> Patterns<br />
existieren seit Alexander [4], der diese Idee publik gemacht hat.<br />
Im englischen Sprachraum werden Patternsammlungen oftmals als „pattern language“- Patternsprache -<br />
bezeichnet, andere Autoren benutzen den Begriff des Patternkatalogs. Den Unterschied zwischen diesen<br />
beiden Sammlungsbezeichnungen arbeiteten Finlay und Dearden in [28] heraus. Patternsprachen sind demnach<br />
Sammlungen stark vernetzter Pattern, so ergeben sich bei Alexander aus der Wahl eines Patterns sofort<br />
Verzweigungen zu anderen Patterns. Patternkataloge erreichen nicht diesen Vernetzungsgrad, Querbeziehungen<br />
zwischen Patterns existieren zwar, genügen jedoch nicht den Anforderungen an eine Sprache im<br />
Sinne Alexanders. Prominentes Beispiel eines Patternkataloges sind die bereits erwähnten GoF-Patterns.<br />
Es gibt mehrere solcher Kataloge innerhalb der HCI Community. Die beiden bekannten Kataloge sind<br />
insbesondere der <strong>von</strong> Jennifer Tidwell [123] und Martijn van Welie’s [136]. Daneben ist die Existenz eines<br />
IBM-internen Katalogs, unter anderem erwähnt in einem Workshop bei der Interact 2005, bekannt.<br />
Die Concordia-Universität Montreal führte ebenfalls für eine geraume Zeit einen kleinen Katalog, dieser<br />
1 vgl. das Pattern „Museum Site“ bei [136]<br />
53
54 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
umfasste etwas mehr als ein Dutzend Einträge. Insgesamt existieren zum gegenwärtigen Zeitpunkt mindestens<br />
fünf öffentliche Patternkataloge für HCI-Patterns. Neben Tidwells und van Welies sind das die<br />
Yahoo!-Sammlung [23], Anders Texboes [126] und der auf Patterns in Spiele-UIs konzentrierte Katalog<br />
<strong>von</strong> Eelke Folmer [43]. Im Rahmen dieser Arbeit werden im Weiteren nur die Patternlanguages <strong>von</strong> Welie<br />
und Tidwell betrachtet. Aus zwei Gründen: der Welie-Katalog ist der umfangreichste im World Wide Web;<br />
derjenige <strong>von</strong> Tidwell wurde in Buchform [124] veröffentlicht und die enthaltenen Patterns sind aus meiner<br />
Sicht am Besten ausgearbeitet, begründet und präsentiert.<br />
Beide Kataloge sind zum gegenwärtigem Zeitpunkt öffentlich im World Wide Web verfügbar. Wobei der<br />
Umfang des Webkatalog der Tidwellschen Patterns jedoch gegenüber der Buchform erheblich verkleinert<br />
ist. Im Buch [124] werden 94 Patterns erklärt, der Webkatalog enthält deren 44. Der Unterschied entsteht<br />
vor allem dadurch, dass der Fokus des Webkatalogs auf WIMP-Patterns liegt. Wohingegen sich das erste<br />
Kapitel „What Users Do“ des Buches sich allgemeinen Mustern der Mensch-Maschine-Kommunikation<br />
widmet und dazu zwölf Patterns vorstellt. Beispielsweise das Pattern „Instant Gratification“- die Forderung<br />
nach sofortiger Belohnung in Form <strong>von</strong> Erfolgserlebnissen für den Nutzer. Oder das Pattern „Keyboard<br />
Only“ welches eine, zumindest alternative, Bedienbarkeit aller Funktionen einer Anwendung nur mit der<br />
Tastatur propagiert.<br />
Alle weiteren Kapitel des Buches entsprechen den Kategorien des Webkatalogs. Dabei werden jeder Kategorie<br />
im Buch mindestens drei zusätzliche Patterns zugeordnet. Eine namentliche Auflistung der hinzugefügten<br />
Patterns wurde in Tabelle 3.1 vorgenommen. Die Kapitelreihenfolge darin folgt <strong>von</strong> oben nach<br />
unten derjenigen des Tidwell-Kataloges, zu beachten ist dass das Kapitel „Doing Things“ im Webkatalog<br />
als „Commands and Actions“ benannt wird und dass das Pattern „Corner Treatments“ zwar im Webkatalog<br />
namentlich eingeordnet aber nicht vorgestellt wird.<br />
Der Unterschied im Umfang der beiden Instanzen des Tidwell-Katalogs ist möglicherweise dem kommerziellen<br />
Interesse der Vermarktung des Buches geschuldet. Für die in beiden Katalogversionen enthaltenen<br />
Patterns ergaben Stichproben eine direkte textuelle Übereinstimmung der Beschreibungstexte und Beispielillustrationen<br />
und somit der Patterndeklarationen. Ähnliche Vergleiche mussten für den Welie-Katalog<br />
nicht angestellt werden, da er nur in einer Veröffentlichungsform vorliegt.<br />
Untersucht man die beiden maßgeblichen Kataloge vergleichend, fallen eine Reihe Inkonsistenzen und<br />
Diskrepanzen auf. So gibt es keine konsistente Benennung oder ein allgemein verbreitetes Namensschema<br />
für die enthaltenen Patterns. Das bedeutet unter anderem, dass eine erhöhte Wahrscheinlichkeit für<br />
Mehrfacheinträge besteht und - gravierender - dass gleiche Patterns nicht gleich benannt werden.<br />
Kapitel Patterns<br />
Organizing the Content Canvas plus Palette, Alternative Views, Multi-Level Help<br />
Getting Around Hub and Spoke, Pyramid, Modal Panel, Sequence Map, Breadcrumbs,<br />
Annotated Scrollbar, Escape Hatch<br />
Organizing the Page Right/Left Alignment, Diagonal Balance, Property Sheet<br />
Showing Complex Data Datatips, Dynamic Queries, Data Brushing, Local Zooming, Multi-Y<br />
Graph, Small Multiples, Treemap<br />
Getting Data from Users Structured Format, Autocompletion, List Builder, Same-Page Error<br />
Messages<br />
Builders and Editors Spring-Loaded Mode, Magnetism, Guides, Paste Variations<br />
Making It Look Good Corner Treatments, Borders That Echo Fonts, Hairlines, Contrasting<br />
Font Weights, Skins<br />
Tabelle 3.1: Nicht im Webkatalog [123] enthaltene Patterns des Tidwell-Katalog [124]
3.1. PATTERN-LANGUAGES 55<br />
Die Beziehungen zwischen Patterns werden fast nur katalogintern angegeben und es existiert überhaupt<br />
keine Referenz zum jeweils anderen Katalog. Überhaupt unterscheiden sich beide Kataloge signifikant in<br />
der Häufigkeit der Angabe <strong>von</strong> Patternbeziehungen. Details dazu werden in Unterabschnitt 3.5.2 vorgestellt.<br />
Leider unterscheiden sich die Kataloge auch in den spezifizierten Aspekten der jeweiligen Patterns. So<br />
unterläßt Welie [136] eine explizite Problembeschreibung, während Tidwell [123] die Musterlösung des<br />
Patterns uneinheitlich verteilt über eine „Example“-Sektion und einen „How“-Block vorstellt.<br />
Weiterhin variiert das Abstraktionsniveau der Patterns erheblich. So schlägt Welie, für eine Webseite, das<br />
Pattern „Fun“ vor, mit der Problembeschreibung: „Users want to have fun or feel entertained“ 2 . Ein anderes<br />
Pattern des gleichen Kataloges ist „Action Button“. Darin geht es darum, dass Schaltflächen die<br />
wichtige Aktionen auslösen, in ihrer Beschriftung die auszulösende Aktion in ihrer Verbform enthalten<br />
sollen. Beides kann unter Umständen als Pattern angesehen werden, die jeweilige Lösung muss jedoch auf<br />
völlig verschiedenen Ebenen der Softwareentwicklung umgesetzt werden. Hier handelt es sich um einen<br />
bemerkenswerten Unterschied zu den GoF-Pattern, deren Anwendungsebene immer Klassendiagramme<br />
sind.<br />
Die Patternlanguages <strong>von</strong> Tidwell [124] und Welie verfolgen hauptsächlich das Ziel, Entwicklern und Designern<br />
die präsentierten HCI-Patterns zur Kommunikation zu vermittlen. Ziel ist es, dass alle Stakeholder<br />
im Entwicklungsprozess unter einem Patternnamen das Gleiche verstehen. Falls möglich, sollen die eigentlichen<br />
Designideen durch Kombination <strong>von</strong> Patterns ausgedrückt werden. In allen Fällen handelt es sich<br />
um textuelle Beschreibungen, zu Demonstrationszwecken meist unterstützt durch illustrierende grafische<br />
Darstellungen. Diagramme in standardisierten Notationen werden nicht verwendet. In der Konsequenz liegt<br />
die vorgeschlagene Patternlösung immer nur informal definiert vor. Auch hierin liegt ein erheblicher Unterschied<br />
zum Katalog der GoF-Pattern <strong>von</strong> [48], dort wird für jedes Pattern ein Klassendiagrammen und<br />
Beispielquellcode angegeben.<br />
Selbstverständlich sind diese Beobachtungen zu den Patternkatalogen keine neuen Erkenntnisse. Es existieren<br />
mindestens zwei Ansätze zur Reduzierung der Inkonsistenzen durch Formalisierung. Ein wesentlicher<br />
Formalisierungsschritt ist die Anwendung einer standardisierten Pattern-Language für Patternkataloge.<br />
Genau dafür wurde im Rahmen eines CHI-Workshops das XML-Derivat Pattern Language Meta Language<br />
PLML [38] geschaffen. Darüberhinaus wurde um 2005 das TROST [59]-Pattern Description Template<br />
veröffentlicht. Es entstand aus vergleichenden Betrachtungen der Alexander, GoF und weiteren Patternsammlungen<br />
und ist letztlich eine Sammlung <strong>von</strong> Stichworten oder Aspekten die ein Pattern beschreiben.<br />
Die Unterschiede zu PLML sind nicht gravierend, bemerkenswert ist, dass auch Themen wie Usability,<br />
Testbarkeit, Support, Sicherheit und weiteres in den TROST-Beschreibungen berücksichtigt werden.<br />
Für meine eigene Arbeit setzte ich auf PLML auf, da hier<strong>von</strong> auch Berichte über den tatsächlichen Einsatz<br />
vorliegen.<br />
Die Entwicklung <strong>von</strong> PLML begann mit dem Ziel eine gemeinsame Basis zur Spezifikation <strong>von</strong> Patterns<br />
zu schaffen. Darüberhinaus sollte es als Austauschformat zur Übertragung <strong>von</strong> Pattern zwischen verschiedenen,<br />
möglicherweise spezialisierten, Katalogen dienen.<br />
Die Sprache PLML wurde darauf ausgelegt, Patterns für jeden Anwendungsbereich zu beschreiben, ihre<br />
Spezifikation sieht keine Sprachelemente speziell für HCI-Patterns vor. Der GoF-Patternkatalog könnte<br />
daher mit PLML beschrieben werden, mit einer entscheidenden Abwandlung; Quellcode und UML-<br />
Diagramme sind in PLML nicht formalisiert. Ohne eine Beschränkung auf eine bestimmte Anwendungsdomäne<br />
war es naturgemäß nicht möglich, für den Wertebereich der Sprachelemente Vorgaben zu machen.<br />
2 d.h. Pattern „Spaß“←Besucher wollen Spaß haben oder unterhalten werden
56 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Die Konsequenz daraus ist, dass mit PLML das Problem der unzureichenden Formalisierung der Patternlösung<br />
nicht behoben werden kann.<br />
Es wäre unzutreffend zu behaupten, dass PLML keine Verbreitung fand, immerhin stellen fünfzig Prozent<br />
der öffentlichen Patternkataloge ihren Inhalt auch über PLML bereit. Von einem regen Gebrauch kann<br />
allerdings ebenfalls nicht die Rede sein, zumal die Diskrepanzen zwischen dem Webkatalog- und dem<br />
PLML-Eintrag beim Welie-Pattern „Send-a-Friend Link“ 3 darauf hindeuten, dass Welie nicht PLML als<br />
Backend für seinen Patternkatalog verwendet.<br />
PLML wird im Rahmen dieser Arbeit verwendet, um den hiesigen Pattern-Katalog zu verwalten. Der<br />
Abschnitt 3.2 gibt einen Überblick über die Sprache PLML so wie sie zunächst spezifiziert wurde. Dabei<br />
werden diverse Unzulänglichkeiten des Sprachstandards aufgezeigt. Deren Behebung und eigene Erweiterungen<br />
werden vorgeschlagen und die daraus resultierende neue Sprachversion präsentiert. Mit dieser<br />
neuen Version <strong>von</strong> PLML wurde ein vereinheitlichter Patternkatalog, als Kombination <strong>von</strong> Welie und Tidwell<br />
angereichert um eigene Überlegungen, aufgebaut.<br />
Der Katalog selbst wird mit einer textuellen domänenspezifischen Sprache gepflegt. In Abschnitt 3.3 wird<br />
deren Aufbau und Anwendung gezeigt. Der vereinheitlichte Patternkatalog ist kein Selbstzweck. Die darin<br />
enthaltenen Patterns wurden daraufhin untersucht, inwieweit es möglich ist, für die jeweiligen Patternlösungen<br />
Algorithmen als Model-To-Model oder Model-To-Text Transformation anzugeben. Der Abschnitt 3.5<br />
stellt die Vorgehensweise und die dabei gewonnenen Erkenntnisse, also das Ergebnis dieser Untersuchungen,<br />
dar.<br />
3.2 Pattern Language Meta Language<br />
3.2.1 Sprachstandard<br />
Die Pattern Language Meta Language PLML [38] wurde 2003 durch Fincher, Tidwell, Welie et al. im<br />
Rahmen eines Workshops auf der CHI’2003 entwickelt. Ziel war die Formalisierung <strong>von</strong> Patternbeschreibungen,<br />
um auf diesem Weg alle damals existierenden HCI-Patternkataloge zu einem verteilten Katalog zu<br />
verschmelzen oder zumindest ein universelles Datenaustauschformat für diese Kataloge zu schaffen. Das<br />
Sprachdesign folgt der Vorgabe, mit PLML Patterns auf jeder Abstraktionsebene und aus jeder Domäne<br />
beschreiben zu können.<br />
Neben Angaben zur Spezifikation der Patterns ist es in einem Katalog wünschenswert, auch diverse Metadaten<br />
zu den Pattern-Einträgen zu notieren. Beispiele dafür sind die Namen der Autoren und Versionierungsinformationen.<br />
Da PLML nicht offiziell standardisiert ist, muss der Workshop-Report [38] als die wesentliche verbindliche<br />
Sprachdefinition dienen. Geeignet dafür ist dieser Bericht auch deswegen, weil er neben der reinen PLML-<br />
Definition auch Erläuterungen zu den Sprachelementen liefert.<br />
✞ ☎<br />
<br />
3.2. PATTERN LANGUAGE META LANGUAGE 57<br />
change−log?, credits?)><br />
<br />
<br />
<br />
✝ ✆<br />
Listing 3.1: DTD des PLML-Standard [91]<br />
Listing 3.1 zeigt den Kern des Sprachstandards als Document Type Definition, in seiner offiziellen Version<br />
1.1.2. Für sämtliche Elemente, d.h. XML-Tags, die in Listing 3.1 referenziert werden, aber nicht weiter<br />
spezifiziert sind, gilt als Typdefinition: #PCDATA oder ANY. Die Tabelle 3.2 gibt eine Erläuterung zu den<br />
Sprachbestandteilen, zu jedem Element ist eine Kurzbeschreibung angegeben. Die im Element management<br />
gekapselten Metadaten sollen wegen ihres selbsterklärenden Charakters hier nicht genauer erläutert<br />
werden.<br />
Element Description<br />
patternID Katalogweit eindeutige Id eines Pattern<br />
name Name, so kurz wie möglich<br />
alias Bekannte Namensalternativen<br />
illustration Grafische Darstellung einer besonders überzeugenden Pattern-Instance<br />
problem Designproblem welches das Pattern löst<br />
context Bedingungen unter denen die Patternanwendung am nützlichsten wird.<br />
forces Zwänge die durch die Anwendung des Patterns gelöst werden.<br />
solution Anweisungen deren Befolgung die Pattern-Idee umsetzen.<br />
synopsis Zusammenfassung des Patterns<br />
diagram Schematische Visualisierung des Pattern, skizzenhaft oder formal<br />
evidence Nachweis das es sich tatsächlich um ein Pattern handelt durch entweder:<br />
example - Bekannte Verwendungen<br />
rationale - Prinzipielle Überlegungen, Axiome, Gesunder Menschenverstand o.ä.<br />
confidence Sternwertung (0 bis 2 Sterne), ob der Eintrag tatsächlich als Pattern besteht<br />
literature Referenzen auf vergleichbare Arbeiten oder Pattern<br />
implementation Quellcode, oder Fragmente dessen, oder sonstige technische Dokumentation<br />
related-pattern Container-Element für Verbindungsdefinitionen zu anderen Pattern<br />
pattern-link Assoziation zu einem anderen Pattern, im Detail:<br />
type - Art der Verbindung, entweder is-a, is-contained-by, contains<br />
patternID - Verbindungsendpunkt<br />
collectionID - ggf. in anderem Katalog<br />
label - Beschreibendes Label<br />
Tabelle 3.2: Kurzübersicht der Semantik der PLML-Sprachelemente [38]<br />
Bei genauerer Betrachtung der PLML-DTD fällt auf, dass es keine Vorgaben für die zugelassenen Inhal-
58 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
te der patternbeschreibenden Elemente gibt. Dieser dadurch erreichte hohe Freiheitsgrad für die Patterneinträge,<br />
entspringt der Absicht eine breitestmögliche Anwendbarkeit zu sichern. Der standardsetzende<br />
Workshop-Bericht [38], erwähnt allerdings eine Reihe <strong>von</strong> Einschränkungen, z.B. für den Wertebereich<br />
des Confidence-Ratings, die jedoch nicht in die DTD des Standards eingeflossen sind. Im anschließenden<br />
Unterabschnitt 3.2.2 werden unter anderem diese zusätzlichen Erläuterungen in die Sprache eingeführt,<br />
sowie andere Erweiterungen die sich aus den Erfahrungen im praktischen Einsatz ergaben, integriert.<br />
3.2.2 Erweiterungsvorschläge<br />
Der Versuch des Erstellens eines Pattern-Katalogs unter Verwendung der PLML zeigt schnell ein erstes<br />
Problem auf. Der Fokus der PLML liegt auf dem einzelnen Pattern, an eine umschließende Verwaltungsentität<br />
wurde nicht gedacht. Mit anderen Worten, es ist kein Wurzelelement vorgesehen, welches als<br />
Container für die Einzelelemente dient. Per Definition können daher auch keine Metadaten über den aufzubauenden<br />
Katalog hinterlegt werden, weder Autoren, Versionsinformationen, Änderungszeitpunkte noch<br />
nicht einmal eine eindeutige Katalog-ID kann notiert werden. Dies ist in gewisser Weise erstaunlich, da für<br />
Pattern-Querreferenzierungen explizit die Angabe des Zielkatalogs, in welchem das Pattern definiert ist,<br />
über dessen ID gefordert ist.<br />
Die erste DTD-Erweiterung aus Listing 3.2 führt diese Basis-Funktionalität in PLML ein. Das neue Element<br />
catalog dient künftig als Katalog-Wurzelelement. Das dringend notwendige Attribut zur Fixierung<br />
einer eindeutigen Katalog-ID wurde bei dieser Gelegenheit ebenfalls eingeführt.<br />
✞ ☎<br />
<br />
<br />
<br />
<br />
<br />
<br />
✝ ✆<br />
Listing 3.2: Einführung eines Elementes für Katalog-Metadaten<br />
Im Listing 3.2 wurden zwei verschiedene Definitionen für catalog angegeben. Die Erste, jene für v1.1.2,<br />
ist minimal gehalten, um weiterhin so nah wie möglich am Standard zu bleiben. Die mit dem Terminus<br />
Einsatzversion gekennzeichnete untere Definition ist etwas ausführlicher gehalten. Sie ermöglicht es, zusätzlich<br />
zur Katalog-Id eine Katalogbezeichnung als name anzugeben und Katalogmetadaten zu hinterlegen.<br />
Darüberhinaus lassen sich Kategorien zur kataloginternen Klassifikation <strong>von</strong> Einzelpatterns definieren.<br />
Eine kleine Verschärfung oder Präzisierung der originalen Sprachdefinition liegt in der Bewertung der<br />
confidence. Also dem Vertrauen darin, dass es sich bei dem jeweiligen Eintrag im Patternkatalog tatsächlich<br />
um ein allgemein akzeptiertes Pattern handel. Laut Workshop-Report soll diese Bewertung mit einer<br />
Sternwertung vorgenommen werden.<br />
Dieses Rating ist der allgemeinen Patternbeschreibung <strong>von</strong> Alexander [4] entlehnt. Ebenfalls <strong>von</strong> Alexander<br />
stammt die Festlegung des Wertebereichs für die confidence: ∗∗ → sicher, ∗ → vieleicht, sowie 0 →<br />
Patternstatus unklar. Es ist mit wenig Aufwand möglich, diese Wertausprägungen im Standard zu definieren.<br />
Details dazu hält Unterabschnitt C.3.1 bereit.
3.3. TEXTUELLE DOMÄNENSPEZIFISCHE SPRACHE FÜR PLML 59<br />
In den Erläuterungen zur PLML wird oft Bezug auf Abbildungen genommen, welche zur Beschreibung<br />
diverser Aspekte <strong>von</strong> Pattern verwendet werden sollen. Die Sprachdefinition selbst wurde jedoch mit unzureichend<br />
wenig Unterstützung zur Einbettung <strong>von</strong> Grafiken oder Bildreferenzen vorgenommen. Änderungsvorschläge<br />
zu diesem Aspekt sind in Punkt C.3.1.1<br />
Für die Einträge des Patternkatalogs sollten, wiederum laut PLML-Standard, Literaturreferenzen angegeben<br />
werden. Unter anderem um jeweils die Existenz und Validität eines Patterns zu untermauern. Ich fand<br />
es daher geboten, auch für Literaturreferenzen einen minimalen formalen Rahmen vorzugeben, definiert<br />
und erläutert in Punkt C.3.1.2.<br />
Gemäß dem Originalstandard ist die Notation <strong>von</strong> pattern−links im Content beinahe jedes XML-Elementes<br />
zulässig. Welie [136] macht auch regelmäßigen Gebrauch da<strong>von</strong>, in dessen Katalogs finden sich pattern−<br />
links unter anderem bei den Beispielen und auch den Illustrationen. Das entspricht meiner Meinung nach<br />
nicht unbedingt dem Sprachstandard und wichtiger auch nicht der Idee des pattern−link wie in Tabelle<br />
3.2 erläutert. Meiner Meinung nach geht es darum, explizit semantische Zusammenhänge zwischen<br />
Pattern zu deklarieren. Die Verwendung der pattern−links bei Welie zur Querverweisung <strong>von</strong> Beispielen, ist<br />
etwas anderes. Es wurde daher entschieden, pattern−links nur noch als Unterelemente <strong>von</strong> related−pattern<br />
zuzulassen. Auch die Implementierungsdetails dieser Änderung finden sich im Anhang bei Punkt C.3.1.3.<br />
Neben den drei bereits in Tabelle 3.2 vorgestellten Relationsarten werden an dieser Stelle drei weitere<br />
Verbindungstypen in die PLML eingeführt. Das sind uses, comparable und contradicts zugelassen. Die Semantik<br />
<strong>von</strong> uses ist die Aussage, dass Patterninstanzen des referenzierten Zielpatterns <strong>von</strong> der Lösung des<br />
aktuellen Patterns verwendet werden. Patternbeziehungen vom Typ contradicts identifizieren Patterns deren<br />
Lösung konträr zu der Lösung des referenzierten Patterns ist. Ein Beispiel ist das Pattern „Input Prompt“ 4<br />
welches gewissermassen das Gegenteil des Patterns „Good Defaults“ 5 fordert. Die Benutzung des Markers<br />
comparable verdeutlicht, dass die Lösung(-sstrategie) des einen Patterns vergleichbar dem des jeweils anderen<br />
ist.<br />
Je mehr Einträge ein Katalog hat, desto sinnvoller wird es, die enthaltenden Patterns Kategorien zuzuweisen.<br />
Sowohl Tidwell als auch Welie ordnen ihre Patterns in Kategorien. Welie verwendet eine 2-stufige<br />
Kategorisierung, Tidwell beläßt es bei einer Ebene. Das mag daran liegen, dass der Welie-Katalog etwa<br />
drei mal soviele Einträge enthält wie derjenige <strong>von</strong> Tidwell.<br />
Der Sprachstandard <strong>von</strong> PLML sieht keine Kategorisierung <strong>von</strong> Patterns vor. Auch dies kann möglicherweise<br />
der Pattern-zentrierten Denkweise zugeschrieben werden, auf Grund jener bereits auf ein umschließendes<br />
Katalog-Element verzichtet wurde. Warum auch immer diese Entscheidung getroffen wurde, für<br />
den Einsatz <strong>von</strong> PLML für real existierende Kataloge ist die Einordnung und Gruppierung <strong>von</strong> Patterns in<br />
einer geeigneten Klassifizierungshierarchie sehr sinnvoll. Die notwendigen Anpassungen der PLML-DTD<br />
erläutert Punkt C.3.1.4.<br />
3.3 Textuelle domänenspezifische Sprache für PLML<br />
Patternkataloge, die mit PLML zusammengestellt werden, liegen in XML-Form vor. Für ein Speicher- und<br />
Datenaustauschformat ist das eine geeignete Form. Die Definition, Erweiterung und Wartung eines PLML-<br />
Patternkatalogs verlangt daher ebenfalls das Operieren auf XML-Baumstrukturen. Dies ist bei größeren<br />
XML-Strukturen allerdings unpraktisch und fehlerträchtig. Zur Bearbeitung <strong>von</strong> PLML-Katalogen durch<br />
4 Erklärende Texte als Vorgabewerte in Textboxen oder Dropdown-Feldern die den Nutzer darauf hinweisen was er eingeben oder<br />
auswählen soll<br />
5 Sinnvolle Standardwerte vorauswählen
60 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
menschliche Designer sind bessere Möglichkeiten denkbar.<br />
Es wäre selbstverständlich in jedem Fall möglich, eine eigene Applikation zur Katalogwartung zu implementieren.<br />
Da<strong>von</strong> abgesehen kann mit bereits existierenden Werkzeugen viel erreicht werden. Die einfachste<br />
Möglichkeit wäre es sicherlich, spezialisierte XML-Editoren zu verwenden. Im Zusammenspiel<br />
mit der DTD sind derartige Tools durchaus in der Lage, einigen Komfort zu bieten. Dazu gehören Syntaxvervollständigung,<br />
Templates oder auch Drop-Down Menüs zur Wertauswahl bei den Attributen deren<br />
Wertebereich durch Entitäten eingeschränkt ist. Leider können diese Werkzeuge keine Unterstützung bei<br />
Querreferenzierung bieten, also etwa bei pattern−links die Gültigkeit der Ziel-ID testen oder Ziel-IDs automatisch<br />
vervollständigen. Dies ist technologisch bedingt, die dazu notwendigen semantischen Informationen<br />
können in einer DTD-Grammatik schlicht nicht definiert werden.<br />
Anders sieht dies bei XML-Schemata aus, diese XML-Modellbeschreibungen würden die notwendigen<br />
Informationen enthalten. Allerdings müsste ein entsprechendes Schema definiert werden. Auch dies wäre<br />
eine manuelle Aufgabe, denn ein XML-Schema kann nicht aus der DTD generiert werden. Beziehungsweise<br />
kann man nur ein Schema-Gerüst daraus generieren, die fehlenden semantischen Informationen müssten<br />
ja weiterhin aus einer anderen Quelle kommen.<br />
Eine solche Quelle könnte eine andere Grammatik, ein Ecore-Metamodell oder eine Kombination aus beidem<br />
sein. Dies und mehr bietet das xText-Framework [35].<br />
xText, eine Entwicklung <strong>von</strong> Itemis [64], ist inzwischen ein Bestandteil des Eclipse Modeling Project, dort<br />
ist es das wesentliche Textual Modeling Framework. Vom xText-Framework werden, ausgehend <strong>von</strong> einer<br />
Grammatik, Metamodelle und Editoren generiert. Die Grammatik beschreibt dabei die Syntax einer textuellen<br />
domänenspezifischen Sprache (tDSL). Die Sprachgrammatik beschreibt eine Programmiersprache<br />
für einen dedizierten Einsatzzweck. Das xText-Framework generiert eine komplette Einsatzumgebung, als<br />
Eclipse-Plugins, für die neue Sprache.<br />
Die Einsatzumgebung umfasst insbesondere das Ecore-Modell der Sprache und einen Texteditor mit einer<br />
Reihe Komfortfunktionen. Es ist nicht notwendig den erstellten Texteditor zur Bearbeitung <strong>von</strong> Dateien<br />
der tDSL zu benutzen. Jeder beliebige Dateieditor kann genutzt werden.<br />
Der Zweck einer eigenen domänenspezifischen Sprache ist es Sachverhalte präziser und prägnanter als<br />
mit generischen Formalismen möglich zu fixieren. Es geht im allgemeinen aber nicht nur darum eine eigene<br />
Notation zu haben, sondern die damit beschrieben Sachverhalte auch weiterverarbeiten zu können.<br />
An dieser Stelle ist das aus der Grammatik erzeugte Metamodell <strong>von</strong> Bedeutung. Bestandteile des xText-<br />
Frameworks parsen die Textdateien der tDSL und stellen den Dateiinhalt als Instanzen des Metamodells der<br />
tDSL dar. Diese Metamodelleninstanzen lassen sich mit den üblichen Model-To-Model und Model-To-Text<br />
Technologien weiterbearbeiten.<br />
Die Definition einer tDSL für PLML mit xText hat eine Reihe <strong>von</strong> nützlichen Konsequenzen. Die vermutlich<br />
Praktischste ist der Texteditor. Dank der, in der xText-Grammatik, vorhandenen Semantik der<br />
ID-Referenzen, kann dieser Texteditor die Gültigkeit der Referenzen testen, bietet Autovervollständigung,<br />
Syntax-Hervorhebung und eine anklickbare Baumübersicht des Kataloges. Alternativ wäre es möglich,<br />
EMF aus dem PLML-Ecore-Metamodell ein XML-Schema generieren lassen und dieses in externen XML-<br />
Editoren zu verwenden. Je nach Reifegrad des eingesetzten XML-Werkzeuges ließe sich dabei eine vergleichbare<br />
Funktionalität, dann auf XML-Basis, erhalten.<br />
Wie erwähnt, lassen sich über dem Metamodell beliebige Transformationen durchführen. Das xText-Framework<br />
kann dabei unterstützend tätig werden, indem es ein eigenes Generatorprojekt anlegt. Transformationen<br />
mit diesem Generator werden über die Modeling Workflow Engine (MWE) gesteuert. Als Transformationstechnik<br />
ist standardmäßig xPand, und damit zunächst eine Model-To-Text Transformation, vor-
3.3. TEXTUELLE DOMÄNENSPEZIFISCHE SPRACHE FÜR PLML 61<br />
gesehen. Natürlich ist dies konfigurier- und änderbar. Sowohl MWE als auch xPand sind Itemis [64]-<br />
Entwicklungen.<br />
Zur Erstellung <strong>von</strong> xPand-Templates, die dann in einem Generatorprojekt genutzt werden können, gibt es<br />
<strong>von</strong> xText in der aktuellen Version keine weitere Unterstützung, abgesehen <strong>von</strong> den üblichen Bearbeitungshilfen<br />
durch den xPand-Editor. Zwei wesentliche Templates zur PLML-Verarbeitung wurden entwickelt.<br />
Diese generieren aus den mit der tDSL beschriebenen PLML-Katalogen, eine der Sprachdefinition entsprechende<br />
XML-Version des Kataloges. Es existiert jeweils ein xPand-Template zur Erstellung des Patternkataloges<br />
nach dem Standard der offiziellen PLML-Version und ein Template für das in der Arbeit erweiterte<br />
PLML v1.5.<br />
Transformationen außerhalb des Generator-Projektes sind selbstverständlich auch möglich. So entstanden<br />
Abbildung 3.7 und Abbildung 3.8 aus Unterabschnitt 3.5.2 als Model-To-Text Transformationen mit<br />
Acceleo, siehe Punkt 2.2.1.3. Hier wurde aus der jeweiligen PLML-Kataloginstanz der LATEX-Quellcode<br />
für die Grafiken generiert.<br />
Listing B.4 auf Seite 145 zeigt einen mit der PLML-tDSL spezifizierten Beispielkatalog. Das abgebildete<br />
Listing ist ein Ausschnitt aus einem grösseren Katalog. Das Original ist die nach PLML umgewandelte<br />
Form des Webkatalogs <strong>von</strong> Martijn van Welie, <strong>von</strong> dem in diesem Beispiel nur zwei Einträge gezeigt werden.<br />
Vollständig abgebildet sind die Katalog-Metadaten und die Kategorie-Definitionen. Der erste Eintrag<br />
dieses Beispielkatalogs ist semantisch fehlerhaft, so fehlen z.B. die Problembeschreibung und einiges mehr.<br />
Dennoch illustriert das Listing B.4 die Referenzierungsmechanismen und die Einbettung <strong>von</strong> HTML für<br />
Bildverlinkung und Textformatierung.<br />
Die vollständige PLML-tDSL Grammatik <strong>von</strong> xText ist im Anhang auf Seite 143 angegeben. Darüber hinaus<br />
finden sich in Unterabschnitt C.3.2 Detailerklärungen zu einem Ausschnitt dieser Grammatik. Das<br />
daraus vom xText-Framework erzeugte Metamodell wird in Abbildung 3.1 und Abbildung 3.2 dargestellt.<br />
Die Aufteilung in die Teilgrafiken wurde nach inhaltlichen Gesichtspunkten vorgenommen, alle Metaklassen<br />
sind Bestandteil eines Modells; insbesondere ist die in beiden Abbildungen enthaltene Klasse Pattern<br />
dieselbe. Weil es sich dabei um ein Ecore-Modell handelt, werden die Basistypen EString und EBoolean<br />
genutzt, und nicht deren UML::*-Entsprechungen.<br />
In Abbildung 3.1 werden die Klassen des PLML-Metamodells dargestellt, die der Strukturierung sowie<br />
der Notation <strong>von</strong> Stammdaten des Katalogs dienen. Instanzen <strong>von</strong> Model bilden die Wurzel eines instanziierten<br />
Kataloges. Im Typ MasterData werden die Referenzen auf die typischen Stammdateneinträge vorgehalten.<br />
Entsprechend der Definition in der Grammatik sind einige da<strong>von</strong>, via Kardinalitäten, als Pflichtoder<br />
Optionalangaben definiert. Über die Assoziation subCategory:CategoryDef läßt sich eine beliebig tiefe<br />
Abbildung 3.1: Hilfsklassen im PLML-Metamodell
62 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Kategoriehierarchie erstellen.<br />
Die für die Beschreibung der einzelnen Patterns genutzten Klassen sind in Abbildung 3.2 dargestellt.<br />
Jeder Aspekt eines Patterns wird in einer eigenen Metaklasse beschrieben. Der Name der Klasse leitet<br />
sich letztlich vom ursprünglichen PLML-Elementnamen ab und folgt nicht hundertprozentig den UML-<br />
Namensgebungsrichtlinien. Referenziert wird dies alles <strong>von</strong> PatternDescription-Objekten aus, jedes Pattern<br />
hat genau eines da<strong>von</strong>. Im oberen rechten Teil <strong>von</strong> Abbildung 3.2 sind die Metaklassen, die bereits in der<br />
Diskussion zu Listing C.7 erläutert wurden, abgebildet.<br />
Dieses Metamodell für PLML weist eine Reihe Schwächen auf. Als menschlicher Designer würde man ein<br />
solches Modell eher nur in einer frühen Phase der objektorientierten Analyse modellieren. Optimierungspotential<br />
bietet zum Beispiel PatternDescription, die hier definierten Assoziationen könnten ohne Schwierigkeiten<br />
innerhalb Pattern definiert werden. Ebenso scheint es nur mäßig sinnvoll, sechs Klassen die jeweils<br />
nur aus dem Attribut data:EString bestehen zu definieren. Auch diese Information ließe sich ohne Semantikverlust<br />
in Pattern integrieren. Darüberhinaus sind sämtliche has*-EBoolean Attribute überflüssig, und die<br />
Modellierung der Confidence-Klasse scheint umständlich. Für die Stammdatensektion lassen sich ähnliche<br />
Kritikpunkte aufzählen.<br />
Es handelt sich also weniger um ein geeignetes Metamodell für beliebige Patternkataloge, sondern nur<br />
um ein praktikables Metamodell für PLML. Trotz dieser teilweise unglücklichen Modellierung wurde an<br />
diesem Metamodell festgehalten, um nicht in die Automatismen <strong>von</strong> xText eingreifen zu müssen. Da die<br />
vorgeschlagenen alternativen Modellierungen keine Semantikänderung bewirken würden, sind die möglichen<br />
negativen Konsequenzen der Beibehaltung des suboptimalen Modells vernachlässigbar gering und<br />
Abbildung 3.2: Kern des PLML-Metamodells, Deklaration eines Patterneintrags
3.4. GRAFISCHE DARSTELLUNG VON PATTERN-KATALOGEN 63<br />
schienen weniger gravierend als auf die Vorteile der Anwendung der xText-Automatismen zu verzichten.<br />
3.4 Grafische Darstellung <strong>von</strong> Pattern-Katalogen<br />
Bei der Benutzung der tDSL für PLML zeigte sich schnell, dass diese Art der Katalogbearbeitung dem<br />
direkten Editieren <strong>von</strong> XML-Strukturen überlegen ist. Da es nun eine textuelle Notation gibt, kann vergleichend<br />
untersucht werden, welche Vorteile eine grafische Notation erbringen könnte.<br />
Offenbar zieht eine erhebliche Anzahl Menschen grafische Modellierungsmöglichkeiten gleichwertigen<br />
Textuellen vor. Andererseits argumentierten bereits Grönninger et al. [57] gegen die These, dass grafische<br />
Editoren und Notationen „besser sind weil sie grafisch sind“. Sie identifizierten als Vorteile der Benutzung<br />
<strong>von</strong> textuellen Notationen für DSLs: Skalierbarkeit, einfache Benutzung sowie die vergleichsweise<br />
einfache Wiederverwendbarkeit der damit erstellten Artefakte für andere Zwecke.<br />
Grafische Bearbeitungswerkzeuge sind naturgemäß aufwändiger zu entwickeln als textuelle. Es schien<br />
daher nützlich, die Idee der Machbarkeit eines grafischen PLML-Editors im Vorhinein geeignet zu prüfen,<br />
bevor Ressourcen durch eine entsprechende eigene Entwicklung gebunden würden.<br />
Wünschenswert ist darüber hinaus eine auf dem PLML-Metamodell aufsetzende Editor-Entwicklung, um<br />
den Aufwand für Pflege und Wartung bei Modelländerungen minimal zu halten. Eine technologisch sinnvolle<br />
Möglichkeit, für die Entwicklung eines prototypischen grafischen PLML-Editors auf Basis des Metamodells,<br />
ist die Verwendung des Graphical Modeling Framework (GMF) ins Spiel. GMF ist Bestandteil<br />
des Eclipse Modeling Project, es handelt sich um ein Framework zur modellgetriebenen Erzeugung grafischer<br />
2D-Editoren für beliebige Ecore-Metamodelle. Diese generierten Werkzeugen werden als Diagramm-<br />
Editoren bezeichnet. Das heisst insbesondere, dass eine graphenbasierte Darstellungsmethapher zum Einsatz<br />
kommt. Damit sind die Grundelemente dieser Editoren Knoten und Kanten.<br />
Bei dem GM-Framework selbst handelt es sich um eine Reihe <strong>von</strong> Metamodellen und Generatoren. Die<br />
einzige Verwendungsanforderung für das GMF ist, über ein Ecore-Modell der Zieldomäne zu verfügen. Da<br />
dies für PLML zutrifft, schließlich existiert dank xText ein PLML-Metamodell als Ecore-Modell, konnte<br />
die Idee der grafischen PLML-Bearbeitung mit GMF umgesetzt und getestet werden.<br />
In einem Ecore-Metamodell liegt typischerweise keine Information darüber vor, wie dessen Instanzen grafisch<br />
dargestellt werden sollen. Diese Information muss daher dem GMF zusätzlich zur Verfügung gestellt<br />
werden.<br />
Darüber hinaus ist zu beachten, dass es sich bei dem generierten Editor um eine eigenständige RCP 6 -<br />
Anwendung handelt. Demzufolge müssen, neben der reinen grafischen Anzeige, auch noch Menüs und<br />
Bearbeitungsaktionen bereitgestellt werden. Auch deren Ausgestaltung muss GMF aus anderen Quellen<br />
als dem darzustellenden Metamodell bekannt gemacht werden.<br />
Die benötigten zusätzlichen Informationen werden dem GMF über eine Reihe verschiedener Modelle bereitgestellt.<br />
Die Metamodelle dieser Hilfsmodelle sind als Ecore-Modelle spezifiziert, ihre Instanzen lassen<br />
sich daher mit den Standardmechanismen des EMP bearbeiten. Dies ist jedoch nur in Grenzen empfehlenswert.<br />
Die Instanzen dieser Hilfsmodelle übersteigen regelmäßig die Größe des ursprünglichen darzustellenden<br />
Metamodells, [110] nennt Faktor 10-20 als Größenordnung. Daher stellt das GMF selbst eine Reihe<br />
Wizards bereit, die zumindest bei der Erstellung der Grundstruktur der Hilfsmodelle behilflich sind.<br />
Einen Übersicht über die (Teil)-Modelle im GMF-Prozess gibt Abbildung 3.3. Durchgezogene Pfeile<br />
kennzeichnen diejenigen Modelle die <strong>von</strong> dem Modell an der Pfeilspitze benutzt werden. Gestrichelte<br />
6 Rich Client Platform
64 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Graphical Def Model<br />
Tooling Model<br />
PLML Domain Model<br />
PLML Domain Generation Model<br />
Mapping Model Editor Generation Model<br />
Abbildung 3.3: Zusammenhang der Modelle des GMF<br />
Pfeile kennzeichnen Transformationen, in der Prozessdarstellung sind zwei Transformationen enthalten.<br />
Erstens die Model-To-Model Transformation zwischen Mapping und Editor Generation-Modell<br />
und als Zweite die Model-To-Text Transformation welche den fertigen Editor als Eclipse-Plugin erstellt.<br />
Die erwähnten Wizards zur <strong>Generierung</strong> <strong>von</strong> Graphical Definition- und Tooling-Modell, welche<br />
ebenfalls als Model-To-Model Transformationen betrachtet werden können, sind in der Darstellung<br />
nicht enthalten.<br />
Zuerst soll das Graphical Definition-Modell, im folgenden GMFGraph genannt, kurz erläutert werden.<br />
Dieses Teilmodell definiert Form und Gestaltung der später verwendeten grafischen Primitive. Im Metamodell<br />
<strong>von</strong> GMFGraph sind Basis-Primitive als Metaklassen vorgegeben, wie alle Metaklassen haben<br />
diese Attribute und Referenzen. Über die Referenz-Beziehungen können die Basis-Primitive kombiniert<br />
werden, und so komplexe Figuren beschrieben werden. Die so im GMFGraph-Modell festgelegten Kombinationen<br />
bilden später die Grundbausteine des generierten Editors. In der aktuelle Version <strong>von</strong> GMF sind<br />
die folgenden Basis-Primitive definiert: Label, Rechteck, abgerundetes Rechteck, Ellipse, sowie offene und<br />
geschlossene Polygonenzüge. Darüber hinaus können SVG-Grafiken [118] eingebettet werden, und sogar<br />
eigene extern implementierte Basis-Primitive referenziert werden. Oft werden allerdings nur die bereits<br />
eingebauten Basis-Primitive verwendet.<br />
Die Basis-Primitive können nicht nur aneinandergereiht sondern auch über Containerbeziehungen verschachtelt<br />
werden. Die Darstellung einer UML-Klasse ließe sich etwa über ein Rechteck mit drei darin<br />
angeordneten Labels und zwei offenen Polygonenzügen für die Trennlinien realisieren. Für die Anordnung<br />
innerhalb eines Containers, in diesem Fall innerhalb des Rechteckes, werden Layoutmanager eingesetzt.<br />
Auch diese, genau wie deren mögliche Parameter, sind als Metaklassen im GMF definiert.<br />
Soweit zur prinzipiellen Darstellung, im Detail ist das Erstellen des Graph-Modells ein langwieriger Prozess.<br />
Als besonders beschwerlich und zeitaufwändig erweist sich das Debugging und Tracing, da Veränderungen<br />
im Graph-Modell nur im generierten Editor geprüft werden können und dieser erst als Ergebnis<br />
<strong>von</strong> zwei nachgelagerten Transformationsschritten entsteht.<br />
Im zweiten GMF-Basismodell, dem Tooling-Modell (GMFTool), werden die später möglichen interaktiven<br />
Bearbeitungsaktionen vorbereitet. Insbesondere sind dies das neu Anlegen <strong>von</strong> Objekten im Editor<br />
und das Herstellen <strong>von</strong> grafischen Verbindungen zwischen Editor-Objekten. Es sind prinzipiell beliebige<br />
weitere Aktionen denkbar, für die vorgenannten existiert jedoch bereits explizite Unterstützung durch<br />
GMF. Letztlich definiert das GMFTool-Modell im Wesentlichen die Menüstruktur und die Verteilung der<br />
Aktionen auf die verschiedenen Menüarten, wie Palette, Popup- oder Hauptmenü.<br />
Das Mapping-Modell (GMFMap) fügt nun die Einzelteile zusammen. Unter anderem wird hier die Verbindung<br />
zwischen den einzelnen Metamodell-Elementen mit den in GMFGraph beschriebenen Figuren
3.4. GRAFISCHE DARSTELLUNG VON PATTERN-KATALOGEN 65<br />
und den Bearbeitungsaktionen hergestellt. Wie erwähnt verfolgt GMF die Graph-Metapher, dies zeigt sich<br />
im Mapping-Modell sehr deutlich. Hier entsteht aus der Zusammenführung <strong>von</strong> GMFGraph-, Tooling- und<br />
PLML-Domänenmodell zu den Diagramm-Knoten. Ein solcher Knoten führt eine Referenz auf die darstellende<br />
Figur und das darzustellende Metamodell-Element, er bildet den Controller-Teil des MVC-Pattern.<br />
Darüberhinaus wird im GMFMap-Modell festgelegt, zwischen welchen Knoten überhaupt Verbindungen,<br />
also Kanten, zugelassen werden. Jede Kante muss detailliert, d.h. auf der Ebene der sie speichernden<br />
Metamodell-Attribute, definiert werden. Dasselbe gilt für Verschachtelungen bei Container-Figuren, auch<br />
für diese muss die sie speichernde Ecore-Containment-Beziehung festgelegt werden.<br />
Eine verhältnismäßig gravierende Folge der Art und Weise wie diese Knotenmetapher in GMFMap umgesetzt<br />
ist, dass es nicht möglich ist beliebige Verschachtelungstiefen vorzusehen. Außerdem können nur<br />
konkrete Visualisierungsfiguren, verbunden mit Elementen konkreter Metamodell-Klassen, in Containern<br />
verschachtelt werden. Man kann zwar festlegen, dass ein Container A beliebige Unterelemente vom Typ B<br />
enthält. Es ist aber mit GMF nicht möglich in der gleichen Relation ein Unterelement des Typs C zu speichern,<br />
auch wenn C eine Unterklasse <strong>von</strong> B ist. Stattdessen muss zwangsweise eine explizite Container-<br />
Beziehung zwischen A und C spezifiziert werden.<br />
Wahrscheinlich entstammt diese Einschränkung der Art und Weise, wie später das GEF 7 für den Editor<br />
benutzt wird. In jedem Fall macht es die Modellierung umständlich und läßt die damit erstellten Editoren<br />
gleichartig erscheinen.<br />
Als Quellmodell für die <strong>Generierung</strong> des eigentlichen grafischen Editors dient das Editor Generation-<br />
Modell (GMFGen). Neben dem Metamodell der Zieldomäne wird vom GMFGen zusätzlich noch das <strong>Generierung</strong>smodell<br />
für das Metamodell der Zieldomäne benötigt. In diesem <strong>Generierung</strong>smodell sind die<br />
Steuerungsparameter für die Java-Codegenerierung der Zieldomäne hinterlegt. Da der grafische Editor Instanzen<br />
des Zieldomänenmodells erstellen und manipulieren soll, wird dessen Modellimplementierung und<br />
De-/Serialisierungsmechanismus benötigt. Um deren korrekte Benutzung durch den Editor zu ermöglichen<br />
ist das Zieldomänen-<strong>Generierung</strong>smodell nötig.<br />
Im GMFGen lassen sich darüberhinaus noch künftige Klassennamen, diverse Labels und andere implementierungsnahe<br />
Eigenschaften festlegen. Der letzte Schritt im GMF-Prozess ist dann die Transformation<br />
des GMFGen-Modells in den Editor.<br />
Mappings für den PLML-Editor<br />
Bevor ein Editor spezifiziert werden kann, muss man sich natürlich Gedanken darüber machen, welche<br />
Teile der Sprache sinnvoll grafisch bearbeitet werden können. So auch für PLML. Offensichtlicher Kandidat<br />
für die Visualisierung sind die Patternbeziehungen. Wie in Tabelle 3.2 dargelegt, handelt es sich bei<br />
den meisten weiteren Sprachelemente um Texte, abgesehen <strong>von</strong> Abbildungen die ihrer Natur nach grafisch<br />
sind.<br />
Im Ergebnis der Überlegungen sollte jedes Pattern als eigener Diagrammknoten und Patternbeziehungen<br />
als Kanten dargestellt werden. Um einen Knoten identifizieren zu können, schien es plausibel die Pattern-<br />
Id und den Namen im Knoten anzuzeigen. Beim Vertrauen (confidence) in den Patterncharakter eines<br />
Eintrags, ist ebenfalls eine hinreichend kleine Information um sie im Knoten unterzubringen. Für die textuelle<br />
Einträge wie etwa das, durch das Pattern gelöste, Problem oder die Patternlösung können auch im<br />
Knoten dargestellt werden. Da längere Texte den Umfang eines Knotens aufblähen, sollten diese jedoch in<br />
einklappbaren Teilcontainern untergebracht werden.<br />
7 Graphical Editing Framework
66 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Damit ergeben sich für das GMFMap des PLML-gDSL 8 Editors folgende Zuordnungen (vgl. Abbildung<br />
3.2 und Abbildung 3.1 für die Metaklassen). Die Typen Pattern, PatternDescription und Management<br />
werden durch grafische Container-Knoten im Editor dargestellt. Ein Pattern-Diagrammknoten bildet dabei<br />
jeweils den Wurzelcontainer einer einzelnen Patternbeschreibung, diese umfasst auch deren Stammdaten.<br />
PatternLinks werden als Verbindungen im Editor dargestellt und Labels an diesen Verbindungen stellen den<br />
Typ der Patternbeziehung dar. Für die textuellen Eigenschaften werden deren String-Attribute ebenfalls als<br />
editierbare Labels bereitgestellt und sind daher direkt im Editor bearbeitbar.<br />
Zu den nicht im grafischen Teil des Editors bearbeitbaren Eigenschaften gehören die Boolean-Attribute der<br />
Confidence und der PatternLinkType. Das bedeutet nicht, dass diese Merkmale nicht änderbar sind. Denn, im<br />
generierten Standardeditor wird für jedes Modellelement auch noch ein sogenannter PropertySheet-Editor<br />
bereitgestellt. Dabei handelt es sich um eine tabellarische Schlüssel/Wert-Auflistung aller Attribute der<br />
Metaklasse. Nach Auswahl einer konkreten Instanz, im Diagramm-Editor, werde an dieser Stelle die Wertbelegungen<br />
der Attributwerte der aktuellen Instanz angezeigt. Die Instanzwerte können im PropertySheet-<br />
Editor nicht nur angezeigt, sondern auch bearbeitet werden. Das gilt selbstverständlich auch für die Eingangs<br />
erwähnten Merkmale.<br />
Nach Festlegung aller Mappings für PLML generiert GMF einen grafischen PLML-Editor als Eclipse Plugin,<br />
eine Eindruck <strong>von</strong> diesem Werkzeug gibt Abbildung 3.4. In diesem speziellen Editor wurden auch<br />
die Stammdaten des Katalogs als eigener Diagramm-Knoten grafisch dargestellt. Der Katalog enthält zwei<br />
Patterns und es wurde eine bidirektionale Beziehung zwischen beiden definiert, es handelt sich um die Visualisierung<br />
einer Variante des Kataloges <strong>von</strong> Listing B.4. Zur Demonstration des PropertySheet-Editors,<br />
wurde in Abbildung 3.4 die Pattern-Beziehung „contains“ zwischen Yes-No-Cancel und Yes-No selektiert.<br />
Das Property-Sheet, also die Eigenschaftentabelle, im unteren rechten Drittel zeigt dementsprechend alle<br />
Eigenschaften dieser Relation; alle Attribute die im Metamodell für den Typ PatternLink existieren. Änderungen<br />
an diesen Eigenschaftswerten im PropertySheet haben direkte Auswirkung sowohl auf die Anzeige<br />
8 graphische DSL<br />
Abbildung 3.4: Screenshot eines exemplarischen graphischen PLML-Editors als Eclipse-Plugin
3.5. PATTERN ALS KOMPONENTEN 67<br />
grafischen Editor als auch auf die Werte der Modellinstanz.<br />
Der in Abbildung 3.4 präsentierte grafische Editor wurde ausgehend <strong>von</strong> einer früheren Version des Metamodells<br />
<strong>von</strong> PLML gebaut. In der Benutzung als Bearbeitungswerkzeug zeigte sich jedoch schnell, dass<br />
ein grafischer Editor nicht unbedingt die Optimallösung zur Pflege <strong>von</strong> PLML-Katalogen darstellt, das<br />
Projekt wurde demnach nicht weiter aktuell gehalten. Neben den Abweichungen die sich aus der Verwendung<br />
einer älteren PLML-Variante ergeben, erwiesen sich weitere Anpassungen am PLML-Metamodell als<br />
notwendig. Weitere Details zu diesem Thema finden sich in Unterabschnitt C.3.3<br />
Sicherlich lassen sich mit dem GMF grafisch ansprechendere Diagramm-Editoren als jener aus Abbildung<br />
3.4 bauen. Generell kann durch das Verwenden anderer Mappings eine große Menge verschiedener<br />
grafischer Editoren für das PLML-Metamodell erzeugt werden. Limitierend in der Gestaltungsfreiheit bei<br />
GMF-Editoren wirken aber immer die bereitgestellten Grundfiguren, die Graph-Metapher und die Umsetzung<br />
des Containerkonzeptes.<br />
Mögliche Änderungen am PLML-Editor müssen sich dabei nicht nur auf eine veränderte grafische Darstellung<br />
beschränken, theoretisch sind gänzlich andere Arten der Visualisierung möglich. Pattern-Beziehungen<br />
könnten beipielsweise durch grafische Container statt durch Verbindungspfeilen dargestellt werden. Und<br />
sicherlich ist die Anzeige der Stammdaten auch nicht unbedingt ständig erwünscht.<br />
Als vorläufiges Fazit der Untersuchung bleibt festzuhalten, dass ein grafischer Editor leider keine nennenswerte<br />
Verbesserung oder Vereinfachung bei der Pflege eines PLML-Kataloges bietet. Das Editieren<br />
<strong>von</strong> Texten in den Eingabefeldern des Diagramm-Editors erwies sich als umständlich, die Einbettung der<br />
Pattern-Illustrationen in die Knoten verbesserte nicht deren Erklärungspotential und generell litt die Übersichtlichkeit<br />
schon bei wenigen Pattern-Einträgen in einem Katalog.<br />
Die Eignung speziell des PLML-Metamodell als generelles Metamodell für HCI-Patterns wurde bereits am<br />
Ende <strong>von</strong> Abschnitt 3.3 kritisch diskutiert. Daher könnten einige der Unzulänglichkeiten der automatisch<br />
erzeugten Editoren eventuell auch dem nicht-optimalen Metamodell zuzuschreiben sein. Jedoch war das<br />
PLML-Metamodell zu keiner Zeit der Grund dafür, dass eine bestimmte Visualisierung nicht durchgeführt<br />
werden konnte, im Gegensatz zu den restriktiven Vorgaben durch das GMF.<br />
Aufgrund meiner Untersuchungen denke ich, dass sich wohl ansprechende grafische Darbietungsformen<br />
für einen Patternkatalog finden lassen. Bis auf weiteres überwiegen jedoch die Vorteile einer textuellen<br />
Katalogbearbeitung.<br />
3.5 Pattern als Komponenten<br />
3.5.1 Klassifikation der Komponentisierbarkeit <strong>von</strong> Patterns<br />
Ein Kernaspekt des im Abschnitt 2.1 vorgestellten MDD-UI Prozessmodells ist es, in und zwischen allen<br />
Stufen Patterns zu integrieren. Dazu wird im Rahmen dieses Kapitels untersucht, welche HCI-Patterns<br />
sich für die Umsetzung in automatische oder halb-automatische Transformationen eignen können. Kann<br />
für ein Pattern ein solche Transfomation gefunden werden, dann ist es ein komponentisierbares Pattern.<br />
Die nötigen Entscheidungskriterien, eine Klassifikation sowie die Erkenntnisse zur möglichen Umsetzung<br />
eines Patterns als Komponente werden im folgenden vorgestellt.<br />
Grundsätzlich sind mit Begriff HCI-Patterns Best-Practices aus allen denkbaren Bereichen der Mensch-<br />
Maschine-Kommunikation abgedeckt. Der Versuch allgemeingültige Kriterien für dieses weite Feld zu definieren<br />
scheint aussichtslos. Deshalb beschränke ich mich wiederum auf Patterns für WIMP-Oberflächen,
68 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Geschäftslogikobjekte<br />
Aufgabenmodell<br />
Domänenmodel<br />
Nutzermodell<br />
Dialoggraph<br />
Zusammenhang<br />
Transformation<br />
patternbasiert<br />
Abstraktes<br />
Interface<br />
Abbildung 3.5: Verwendung <strong>von</strong> Pattern im MDD-UI Prozess<br />
die dabei gewonnenen Erkenntnisse lassen sich jedoch in Grenzen generalisieren.<br />
Anwendungsmodell<br />
Konkretes<br />
Interface<br />
In Abbildung 3.5 ist der UI-relevante Ausschnitt des zugrundeliegenden MDD-UI-Prozess dargestellt. Die<br />
Modelle der abstakten und konkreten Oberfläche, sowie die Transformation dazwischen wurden besonders<br />
hervorgehoben, da es sich dabei um den Einsatzbereich der hier betrachteten Patterns handelt.<br />
Komponentisierbarkeit, Algorithmenbegriff und Komponenten<br />
Der Begriff Komponente hat eine sehr allgemeine Bedeutung. Dementsprechend kann auch Komponentisierbarkeit<br />
weit ausgelegt werden. In dieser Arbeit wird unter dem Konzept einer Patternkomponente<br />
die Idee verstanden, Patterns algorithmisch zu erfassen und umzusetzen. Komponentisierbarkeit meint in<br />
diesem Kontext die Möglichkeit der Erstellung einer Patternkomponente für ein gegebenes Pattern.<br />
Zur Durchführung dieses Ansatzes ist zunächst der Begriff des Algorithmus zu klären. In [109] findet sich<br />
die folgende Definition:<br />
„Der Begriff Algorithmus (algorithm) bezeichnet eine Vorschrift zur Lösung eines Problems,<br />
die für eine Realisierung in Form eines Programms auf einem Computer geeignet ist.“<br />
Viele intuitive Begriffsklärungen folgen dieser Sichtweise. Eine formalere Herleitung, über Turing-Maschinen,<br />
verfolgt [69] und kommt zu dieser Definition:<br />
„Eine Berechnungsvorschrift zur Lösung eines Problems heißt Algorithmus genau dann, wenn<br />
eine zu dieser Berechnungsvorschrift äquivalente Turingmaschine existiert, die für jede Eingabe,<br />
die eine Lösung besitzt, stoppt. “<br />
Wichtiger als der konkrete Wortlaut dieser Definition sind die sich daraus ableitenden formalen Kriterien,<br />
diese sind nachstehend aufgelistet.<br />
1. Operative Finitheit – endlich viele verschiedene Operatoren im Programm
3.5. PATTERN ALS KOMPONENTEN 69<br />
2. Dynamische Finitheit – das Programm darf nur endlich viel Speicherplatz benötigen<br />
3. Finitheit – der Programmtext muss endlich sein<br />
4. Terminierung – der Programmablauf muss in endlicher Zeit terminieren<br />
5. Vollständigkeit – zu jedem Zeitpunkt muss das Programm die nächste Operation eindeutig festlegen<br />
Die zu identifizierenden Patternkomponenten für den modellgetriebenen Ansatz werden letztlich mit den<br />
in Unterabschnitt 2.2.2 beschriebenen Model-To-Model Transformationstechniken, unter Benutzung der<br />
Oberflächenmetamodelle, deklariert. Diese Festlegung limitiert die einsetzbaren Operatoren, somit erfüllen<br />
alle erstellbaren Patternkomponenten das Kriterium der operativen Finitheit (1). Das Kondensat der<br />
Kriterien (2) bis (5) ist die Forderung nach einem endlichen terminierenden deterministischen Programm,<br />
beziehungsweise in diesem Fall: Transformationsbeschreibung. Transformationsdeklarationen, als interpretierte<br />
Spezifikationen, sind immer endlich (3) und, zumindest gemäß der jeweiligen Sprachdefinitionen,<br />
deterministisch (5). Terminierung (4) und Speicherplatzbedarf (2) lassen sich nicht im Vorhinein entscheiden,<br />
sondern bedürfen einer Untersuchung der jeweiligen Transformation.<br />
Komponentisierbarkeit der GoF-Patterns<br />
In einer ähnlichen Untersuchung kategorisierte Arnout [6] die bekannten objektorientierten Patterns <strong>von</strong><br />
Gamma [48] und der GoF. In ihrer Dissertation ermittelte sie, welche der GoF-Patterns sich in der Programmiersprache<br />
Eiffel als vordefinierte Komponenten umsetzen lassen. Allerdings ist ihr Ansatz zur Komponentisierbarkeit<br />
ein anderer. Angepasst an die Einsatzdomäne der GoF-Patterns, handelt es sich bei Arnouts<br />
Komponenten um Klassen, vordefiniert und zur Verfügung gestellt in einer Bibliothek. Zur Nutzung dieser<br />
Patternkomponenten erstellt man eigene Klassen die <strong>von</strong> den bereitgestellten Komponentenklassen erben.<br />
Dabei sind zumeist abstrakte Methoden zu implementieren oder die Typen der generischen Klassen festzulegen.<br />
Zu den Erkenntnissen Arnouts zählt, dass nicht für alle GoF-Patterns sinnvolle Eiffel-Komponenten angegeben<br />
werden können. Zur genaueren Klassifikation entwickelte sie in [6] eine Hierarchie mit 14 Kategorien.<br />
Von den ursprünglichen 23 Patterns der GoF [48] lassen sich 15 in Komponenten darstellen. Von diesen<br />
15 Patterns sind wiederum nur 9 Komponenten als nützliche Patternkomponenten klassifiziert. Die sechs<br />
weiteren Patterns sind entweder bereits als Basisfeature <strong>von</strong> Eiffel vorhanden (Prototype), nicht vollständig<br />
umsetzbar (Builder, Proxy, State), nur abweichend <strong>von</strong> der Patternidee komponentisierbar (Strategy) oder<br />
aber eine Komponente ist möglich aber letztlich nicht nutzlos (Memento). Die quantitativen Ergebnisse<br />
<strong>von</strong> Arnouts GoF-Pattern Klassifikation sind in Tabelle 3.3 zusammengefasst.<br />
Klassifikationskriterien<br />
Zur Klassifikation der einzelnen Patternkomponenten stellt Arnout in [6] die nachfolgenden Kriterien zur<br />
Bewertung <strong>von</strong> Patternkomponenten auf:<br />
Vollständigkeit – Sind alle in der Patternbeschreibung enthaltenen Fälle enthalten?<br />
Nützlichkeit – Ist die Verwendung der Patternkomponente sinnvoll im Vergleich zu einer jeweils eigenen<br />
Implementierung der Patternidee?<br />
Performanz – Ist die Verwendung der Patternkomponente genauso effizient wie eine separate Implementierung<br />
der Patternlösung?
70 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Referenz Kategorieinhalt # zugeordnete GoF-Pattern<br />
1. Komponentisierbare Patterns 15, da<strong>von</strong><br />
1.1 Sprachinhärent 1<br />
1.2 Unterstützt durch Sprachbibliothek -<br />
1.3. Entwickelte Komponenten 14, da<strong>von</strong><br />
1.3.1 vollständig Komponentisierbar 9<br />
1.3.2 unvollständig Komponentisierbar 3<br />
1.3.3 Komponentisierbar, abweichend <strong>von</strong> Patternidee 1<br />
1.3.4 Komponentisierung möglich, Komponente jedoch nutzlos 1<br />
1.4 Kandidat für Komponentisierung -<br />
2. Nicht komponentisierbare Patterns 8, da<strong>von</strong><br />
2.1 Komponentengerüst erstellbar 4, da<strong>von</strong><br />
2.1.1 Komponentengerüst mit Methoden 2<br />
2.1.2 Komponentengerüst nur ohne Methoden 2<br />
2.2. Komponentengerüst grundsätzlich denkbar 1<br />
2.3. gewisse Unterstützung durch Sprachbibliothek 1<br />
2.4. keine Unterstützung möglich 2<br />
Tabelle 3.3: Klassifikationskategorien zur Komponentisierbarkeit <strong>von</strong> Pattern, nach [6]<br />
Ideentreuheit – Entspricht die Umsetzung des Patterns der vorgegebenen Patternlösung?<br />
Typsicherheit – Ist die Komponente typsicher?<br />
Erweiterte Anwendbarkeit – Deckt die Patternkomponente womöglich mehr Fälle als die ursprüngliche<br />
Pattern-Idee ab?<br />
Diese Punkte sind ein geeigneter Startpunkt zur Identifikation eigener Kriterien. Eine 1 : 1-Umsetzung und<br />
Anwendung für WIMP-Patterns ist aus mehreren Gründen kaum sinnvoll.<br />
Wesentlich ist dies in der unterschiedlichen Einsatzdomäne begründet, außerdem verhindert der hohe Abstraktionsgrad,<br />
bei gleichzeitig mangelnder Formalisierung der WIMP-Patterns, eine direkte Kriterienübernahme:<br />
Die GoF-Patterns wurden in den Programmstrukturen objektorientierter Software identifiziert und<br />
sind als Klassendiagramme, in einer prä-UML Notation, formal beschrieben. Wie in der Einleitung <strong>von</strong><br />
Kapitel 3 dargelegt, trifft dies auf die WIMP-Patterns so nicht zu. Deren Komponentisierung baut zwar auf<br />
Klassenstrukturen auf, da die Implementierung auf Ecore-Metamodellen aufsetzt, letztlich handelt bei den<br />
Komponenten aber um textuell deklarierte Transformationen.<br />
In der Konsequenz bedeutet dies zunächst, dass das Kriterium der „Typsicherheit“ für WIMP-Patterns nicht<br />
zielführend sein kann. Ebenfalls kritisch zu hinterfragen ist die „Performanz“. Im Kontext einer Eiffel-<br />
Implementierung ist diese Frage sehr angebracht, unter modellgetriebenen Gesichtspunkten jedoch nicht<br />
wirklich <strong>von</strong> Bedeutung. In der MD-UID ist es das Ziel überhaupt geeignete Transformationen zu finden,<br />
die Performanz hat nur für zur Laufzeit interpretierte Modelle eine herausgehobene Bedeutung. Dies trifft<br />
für die Anwendung der hier für die Komponentisierbarkeit betrachteten Metamodelle nicht zu.<br />
Von genereller Bedeutung ist hier die ähnlich gelagerte Frage, inwiefern sich Patternkomponenten in den<br />
üblichen Transformationstechniken eingebetten lassen. Dies ist jedoch kein Problem einzelner Patterns<br />
sondern eines des gesamten Ansatzes. Dazu ist festzustellen, dass die eingesetzten Techniken jeweils das<br />
Aufrufen externer Transformationen, quasi API-/Bibliotheksaufrufe, jeweils als Sprachbestandteil zulassen.<br />
Mit anderen Worten, QVTo-Transformationen können andernorts deklarierte QVTo-Transformationen<br />
benutzen. Der Ansatz an sich ist daher plausibel und durchführbar.
3.5. PATTERN ALS KOMPONENTEN 71<br />
Eine Erweiterung gegenüber Arnouts Kriterien ergibt sich aus der Tatsache, dass ich die Komponentisierbarkeitsuntersuchungen<br />
für zwei CUI Metamodelle, Swing und XUL, vergleichend durchgeführt habe.<br />
Dabei stellte sich heraus, dass die Komponentisierbarkeit eines Patterns auch vom zugrundeliegenden Metamodell<br />
der konkreten Oberfläche abhängig ist.<br />
Nach diesen einführenden Betrachtungen zum Gegenstand und Aspekten der Komponentisierung <strong>von</strong> Patterns<br />
geht es im Folgenden darum, eine einheitliche Basis <strong>von</strong> Patternbeschreibungen zu finden. Die Patterns<br />
in dem dabei vorgestellten Patternkatalog werden anschließend in Unterabschnitt 3.5.4 auf ihre Eignung<br />
als Komponenten untersucht und schließlich die Ergebnisse summarisch präsentiert.<br />
3.5.2 Aufbau eines Katalogs <strong>von</strong> Patternkomponenten<br />
Das Ziel dieser Arbeiten ist die Erstellung <strong>von</strong> direkt nutzbaren Patternkomponenten. Diese sollen möglichst<br />
in einem Katalog unter Verwendung der in Abschnitt 3.3 entwickelten textuellen domänenspezifische<br />
Sprache gesammelt werden.<br />
Der zu erstellende Patternkatalog soll keine vollständig neue Eigenentwicklung werden, sondern das in<br />
den vorhandenen Patternlanguages gesammelte Wissen aufnehmen. Das erste Ziel ist daher einen vereinheitlichten<br />
Pattern-Katalog aus den vorliegenden Patternlanguages zusammenzustellen. Das ist mit PLML<br />
möglich, auch wenn zur Umsetzung der Idee mehrere Probleme zu lösen waren.<br />
Im Grunde ist ein vereinheitlichter monolithischer Katalog nicht unbedingt notwendig, stellt PLML doch<br />
Sprachfeatures bereit, die den Zusammenhang zwischen diversen Katalogen abbilden können. Bei der praktischen<br />
Anwendung erweist es sich jedoch schnell als unvorteilhaft gleichartige Patterns lokal in verschiedene<br />
PLML-Kataloge aufzuteilen. Insbesondere geraten die Transformationen und Abfragen komplexer,<br />
und damit auch fehleranfälliger, ohne das dieser Nachteil durch entscheidende Vorteile eines verteilten<br />
Kataloges aufgewogen werden kann.<br />
Die prinzipielle Vorgehensweise zur Erstellung eines vereinheitlichten Kataloges ist wie folgt:<br />
1. Übernahme existierender Patternlanguages in den eigenen Katalog, dabei:<br />
(a) Formatumwandlung Input→PLML<br />
(b) Verschmelzung, inklusive der Entfernung <strong>von</strong> Doppeleinträgen<br />
(c) Identifikation <strong>von</strong> Querbeziehungen zwischen Patterns<br />
2. Komponentenerstellung:<br />
(a) Bewertung der Komponentisierbarkeit jedes Patterns<br />
(b) i. ggf. Entwicklung eines Algorithmus für die Patternlösung<br />
ii. ggf. Entwicklung eines Templates für die Verwendung der Patternlösung in der Transformationsengine<br />
des XUL-Editors<br />
3. Bereitstellung des Kataloges zur Nutzung in einem MD-UID Prozess<br />
Ausgangspunkt der Arbeiten waren in unserem Fall die Web-Inkarnationen des Welie und Tidwell-Katalogs.<br />
Es wurde entschieden, Tidwells Webkatalog zu benutzen, anstelle der Buchfassung, weil für den Web-<br />
Katalog die Möglichkeit einer automatisierten Datenübernahme bestand; die Benutzung der Buchfassung<br />
hätte einen erheblichen manuellen Aufwand erfordert. Ein Mehraufwand der für eine Proof-Of-Concept<br />
Implementierung unangemessen erschien.
72 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
In den Erörterungen zu PLML wurde mehrfach auf die Beibehaltung einer Abwärtskompatibilität hingewiesen.<br />
Dies geschah nicht grundlos, denn der Webkatalog <strong>von</strong> Welie stellt seine Patternbeschreibungen als<br />
PLML zur Verfügung. Welies PLML-Patternbeschreibungen in die eigene PLML-Variante zu konvertieren<br />
wäre demnach verhältnismäßig einfach. Allerdings ist die durch Welie verwendete Fassung <strong>von</strong> PLML<br />
ebenfalls nicht mehr identisch zu dem in [38] definierten. Leider ist das XML-Schema seiner Version nicht<br />
mehr verfügbar, so dass ein Vergleich der Sprachversionen manuell erfolgen musste.<br />
Im Wesentlichen hat Welie ein Element hinzugefügt, zwei umbenannt und setzt für die eigentliche Patternbeschreibung<br />
auf die Sprache XHTML. Welie verwendet zur Deklaration <strong>von</strong> Aliasnamen das Element<br />
„aka“ statt „alias“ und hinterlegt die Zusammenfassung der Patternidee in einem Element „pattlet“ anstelle<br />
des PLML-Sprachelementes „synopsis“. Der Begriff Pattlet scheint im Umfeld <strong>von</strong> Microsoft geprägt<br />
zu sein und steht, z.B. nach [75], für die Kurzbeschreibung einer Musterlösung zu einem wiederkehrenden<br />
Problem - meint somit ebenfalls eine Patternzusammenfassung. Das neu hinzugekommene Element<br />
„code-link“ dient zur Verlinkung <strong>von</strong> Beispielquellcode über HTML-Mechanismen.<br />
Importframework für externe Patternlanguages<br />
Die Schrittfolge zur Übernahme aus anderen Katalogen ist jeweils sehr ähnlich, die folgenden Punkte sind<br />
abzuarbeiten:<br />
1. Beschaffung einer XML-Serialisierung<br />
2. Instanziieren eines semantisch gleichwertigen PLML-Ecoremodells<br />
3. Generieren der tDSL-Beschreibung aus dem PLML-Ecoremodell<br />
Es wurde ein Framework implementiert, das diese Aufgaben weitestgehend übernimmt. Die Anpassung<br />
an die variable Struktur der Eingaben, also der wechselnden Katalog-XML-Serialisierungen, folgt der Lösung<br />
des GoF-Patterns „Erbauer“. Der Implementierungsaufwand zum Parsen eines weiteren Webkatalog<br />
besteht daher in der Implementierung weniger Interfaces.<br />
Das Framework benutzt für die Erstellung des korrespondieren PLML-Ecoremodells die durch EMF bereitgestellte<br />
Technik der dynamischen Modellinstanziierung. Nach abgeschlossenem Importvorgang wird dieses<br />
Modell schließlich mit den EMF-Mechanismen serialisiert. Diese Serialisierung, ein XML-Dokument,<br />
wird abschließend über eine Model-To-Text Transformation mit Acceleo in die tDSL-Serialisierung <strong>von</strong><br />
PLML überführt.<br />
Die Abbildung 3.6 illustriert wie dieser Prozess für den Fall der Tidwell-Patterns durchgeführt wurde. Das<br />
Problem mit diesem Webkatalog liegt darin, dass die Patterns in HTML-Form präsentiert werden. HTML<br />
als Seitenauszeichnungssprache ist zwar zur Präsentation <strong>von</strong> Daten geeignet, jedoch nicht unbedingt zu<br />
deren Weiterverarbeitung prädestiniert. Die unzähligen üblichen Abweichungen vom Sprachstandard erschweren<br />
das automatisierte Parsen <strong>von</strong> HTML. Vor einer Weiterverarbeitung bietet sich daher eine Transformation<br />
der HTML-Dateien in XML-Dokumente an.<br />
HTML<br />
Tidy<br />
XHTML<br />
Framework<br />
Ecore<br />
Acceleo<br />
tPLML<br />
Abbildung 3.6: Verarbeitungskette zur Erstellung des PLML-Kataloges aus dem Tidwell-Webkatalog
3.5. PATTERN ALS KOMPONENTEN 73<br />
Natürlich ist es kaum sinnvoll, einen eigenen Format-Umwandler zu entwickeln, daher wurde ein bekanntes<br />
Tool für diesen Zweck eingesetzt, das vom W3C initiierte Programm „HTML Tidy“ [92]. HTML Tidy<br />
behebt nicht nur einfache Syntaxfehler im HTML-Code sondern verfügt auch über Heuristiken um fehlerhafte<br />
Elementverschachtelungen und fehlende Element-Tags zu ermitteln. Das Ergebnis der Anwendung<br />
<strong>von</strong> HTML Tidy auf die HTML-Seiten der Patternbeschreibungen sind valide XHTML- und damit XML-<br />
Dokumente. Diese Dokumente werden vom Framework interpretiert und dabei die Nutzinformationen in<br />
einem Laufzeit-PLML-Ecoremodell aggregiert. Für die Einträge des Welie-Kataloges ist natürlich die Normalisierung<br />
mit HTML-Tidy entbehrlich.<br />
Zu den dargestellten Erweiterungen, siehe Unterabschnitt 3.2.2, der PLML gehört das Kategorienkonzept.<br />
Beide hier untersuchte Kataloge machen Gebrauch da<strong>von</strong>. Welie nutzt sogar Unterkategorien, Tidwell beschränkt<br />
sich auf eine Kategorisierungsebene. Im Rahmen des Katalogimports werden diese Katalogstrukturen<br />
nachgebildet und die dementsprechenden Modellzuordnungen vorgenommen.<br />
Patternbeziehungen innerhalb der Kataloge<br />
Nach Durchlaufen des Importframeworks liegen die Patternkataloge als Textdateien mit der Syntax der<br />
PLML-tDSL vor. Die in den Webkatalogen enthaltenen grafischen Abbildungen wurden dabei als externe<br />
Links mit ihrer URL übernommen.<br />
Patterns stehen nicht als isolierte Aufzählungen in den Katalogen. Oftmals kann für die Umsetzung eines<br />
Patterns die Idee anderer Patterns benutzt werden. Die typisierten kataloginternen Referenzen <strong>von</strong> PLML<br />
dienen dazu derartige Beziehungen auszudrücken.<br />
Die Kataloge <strong>von</strong> Tidwell und Welie unterscheiden sich erheblich in Bezug auf die angegebenen Beziehungen.<br />
Die beiden Darstellungen <strong>von</strong> Abbildung 3.7 und Abbildung 3.8 sind ein Versuch diesen Sachverhalt<br />
zu visualisieren.<br />
Beide Abbildungen wurden durch eine Acceleo-Transformation der jeweiligen PLML-tDSL Kataloge in<br />
LATEX-PSTricks Quellcode erstellt. Alle Patterns eines Kataloges sind als einzelner Kreisknoten abgebildet.<br />
Über die Färbung des Kreises wird der Vernetzungsgrad des Patterns nochmals hervorgehoben. Weiß ausgefüllte<br />
Kreise stehen für Patterns die mindestens ein weiteres Pattern benutzen. Graue Füllungen weisen<br />
Patterns aus welche <strong>von</strong> mindestens einem anderen Pattern referenziert werden. Rot sind schließlich diejenigen<br />
Patterns hervorgehoben die andere Patterns weder durch andere Patterns referenziert werden noch<br />
ein anderes Pattern verwenden.<br />
Im Tidwell-Katalog befinden sich demnach sechzehn Patterns die überhaupt keine Verbindung zu anderen<br />
Patterns haben. Zehn weitere Patterns werden zumindestens referenziert. Somit bleiben insgesamt nur<br />
achtzehn Patterns (40,9 Prozent) die zur Erklärung oder Lösung auf andere Patterns zurückgreifen. Die<br />
höchstintegrierten Patterns dieses Kataloges sind, mit jeweils fünf Referenzierungen, „Wizard“, „Two-<br />
Panel Selector“und „Titled Sections“.<br />
Anders stellt sich das für den Welie-Katalog dar. Nicht nur durch die dichtere Positionierung aufgrund der<br />
höheren Anzahl <strong>von</strong> Patterns finden sich in Abbildung 3.8 optisch mehr Verbindungen. Nur neun der 131<br />
Patterns der Welie-Sammlung sind mit keinem andern Pattern-Eintrag verbunden. Zwanzig weitere Einträge<br />
werden nur referenziert, referenzieren selbst aber keine weiteren Patterns. Somit werden in immerhin<br />
102 (77,9 Prozent) Patternbeschreibungen andere Patterns mitbenutzt. In diesem Katalog benutzt das Pattern<br />
„Museum“ 15 andere Patterns, „Search Results“ verwendet 12, an dritter Stelle folgen „Application<br />
“ und „Information-Experience“ mit jeweils 11 Referenzierungen. Vergleichend fällt beispielsweise auf,<br />
dass das Pattern „Wizard“ bei Welie im Gegensatz zu Tidwell nur ein einziges anderes Pattern referenziert.
74 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Einheitlicher Patternkatalog<br />
Abbildung 3.7: Intrakatalogreferenzen beim Tidwell-Katalog [123]<br />
Nachdem die Kataloge als PLML-Modellinstanzen bereitstehen, ist gemäß der in 3.5.2 vorgestellten Vorgehensweise,<br />
der nächste Schritt zur Erstellung eines vereinheitlichten Kataloges die Verschmelzung (1b).<br />
Dieser Prozessabschnitt erfordert eine Reihe menschlicher Entscheidungen und wird daher eine manuelle<br />
Tatägkeit bleiben.<br />
Im Einzelnen ist für jedes Pattern zu entscheiden, ob es sich um einen Doppeleintrag oder Aliasnamen<br />
handelt, die referenzierten Patterns anzupassen und über die Angemessenheit des Confidence-Wert<br />
zu befinden. Bei der Übertragung externer Patternkataloge wird zunächst da<strong>von</strong> ausgegangen, dass jeder<br />
Eintrag ein nachgewiesenes Pattern darstellt. Dies wird, wie in Unterabschnitt 3.2.2 erläutert, durch den<br />
Confidence-Wert: ∗∗ ausgedrückt.<br />
Nötig kann eine solche Confidence-Abwertung z.B. bei unvollständigen Patterndeklarationen sein. Offensichtlich<br />
könnten derlei Patterns auch sofort aus dem Katalog entfernt werden, allerdings könnten dabei<br />
Konsistenzprobleme auftreten, falls diese Einträge anderweitig referenziert sind, außerdem nimmt man sich<br />
die Möglichkeit den Patterneintrag später, eventuell aus anderen Quellen, zu vervollständigen. Die Abwertung<br />
der Confidence hat keine deratigen Konsequenzen und ist als Problemmarkierung ausreichend.<br />
In Tabelle 3.4 sind die unterspezifizierten Patterns der beiden Webkataloge aufgeführt. Es werden die Patterns<br />
aufgeführt für die, nach der Datenübernahme, keine Angaben zur Problembeschreibung (Problem),<br />
dem Kontext (Context), der Patternlösung Solution oder zum Nachweis des Patterncharakters (Evidence)<br />
vorliegen. Bei einer Ausnahme: die bei Welie angegebene Patternlösung für „Tutorial“ besteht<br />
aus dem Verweis auf einen Buchtitel, nicht aus einer qualifizierten Beschreibung. Der Eintrag wurde daher
3.5. PATTERN ALS KOMPONENTEN 75<br />
in die Problem-Auflistung übernommen.<br />
Abbildung 3.8: Intrakatalogreferenzen beim Welie-Katalog [136]<br />
Nicht alle in Tabelle 3.4 aufgelisteten Patterns müssen im Confidence-Wert herabgestuft werden. So<br />
lassen sich ohne Schwierigkeiten Beispiele für das „One-Off Mode“ 9 -Pattern finden und in den Katalog<br />
einpflegen. Die fehlende Lösung des „Send-To-Friend“-Patterns erklärt sich durch Diskrepanzen zwischen<br />
HTML-Version der Welie-Webseite und dem ausgelieferten PLML. Insgesamt betrachtet sind sechs bzw.<br />
vier problematische Patterns <strong>von</strong> 175 Datensätzen ein handhabbares Problem, das spricht für die Qualität<br />
der beiden Kataloge.<br />
9 Modusumschaltung nur für eine Aktion, danach Rückkehr in vorherigen Modus<br />
fehlender Aspekt Katalog Welie Katalog Tidwell<br />
Problembeschreibung Details-on-Demand, Storytelling, Tutorial —<br />
Kontext Details-on-Demand, Storytelling, Travel Site, Tutorial —<br />
Patternlösung Send-To-Friend, (Tutorial) —<br />
Existenznachweis — One-Off Mode<br />
Tabelle 3.4: Problematische Patterneinträge in den Webkatalogen
76 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Durchführung der Verschmelzung<br />
Nach Revision der Problempatterns erfolgt die tatsächliche Verschmelzung, d.h. die Punkte 1b und 1c in<br />
der Prozessbeschreibung nach 3.5.2. Beides läßt sich semi-automatisch durchführen; zum Einsatz gelangt<br />
wiederum selbstentwickelte Java-Software und QVT, welche auf Ecore und OCL aufsetzen.<br />
Prinzipiell ist die Katalogverschmelzung eine Model-To-Model Transformation und hätte mit den hierfür<br />
vorgesehenen Transformationsmechanismen, siehe Unterabschnitt 2.2.2, implementiert werden können.<br />
Da jedoch das Import-Framework eine Java-Implementierung und die Katalogverschmelzung ein dem nahestehender<br />
Verarbeitungsprozess ist, wurde an dieser Stelle noch kein Technologiewechsel vorgenommen.<br />
Vor der Darlegung des Verschmelzungsergebnis sollen noch einige kurze Erläuterungen zu den spezifischen<br />
Problemen der Vermischung erfolgen. Die Implementierung ist darauf ausgerichtet, immer genau zwei<br />
Kataloge (K1,K2)zusammenzuführen, dies hat keine Einschränkung der allgemeinen Anwendbarkeit zur<br />
Folge da mehrere Kataloge sequentiell paarweise vermischt werden können.<br />
Für die Transformation gilt dann, dass alle Patterns Pi mit Pi∈ Km∧Pi /∈ Kn wobei m,n∈{1,2}∧m= n, also<br />
alle nur in einem Katalog enthaltenen Patterns, direkt in den neuen Ergebniskatalog KT übertragen werden.<br />
Die Entscheidung auf Enthaltensein basiert ausschließlich auf dem Vergleich der Pattern-ID, erfordert<br />
daher zwangsweise eine manuelle Nachbearbeitung. Da die Vergabe, Zusammensetzung oder Syntax einer<br />
Pattern-ID nicht festgelegt sind und daher <strong>von</strong> den Autoren der Patternkataloge frei gewählt werden<br />
können. Im Rahmen der Arbeiten zur Katalogerstellung wurde dennoch eine Normalisierung der IDs vorgenommen:<br />
alle Zeichen die nicht im lateinischen Alphabet enthalten sind werden durch den Unterstrich<br />
„_“ und alle Großbuchstaben durch ihren jeweiligen Kleinbuchstaben ersetzt.<br />
Der Ergebniskatalog KT wird neu angelegt. Bei der Übertragung der Patterns müssen daher alle Modell-<br />
Verlinkungen, dass sind neben den Patternbeziehungen auch die jeweilige Kategoriezuordnung, neu aufgebaut<br />
werden. Der Kategoriebaum <strong>von</strong> KT ergibt sich aus der Vereinigung der Kategoriebäume <strong>von</strong> K1 und<br />
K2. Weil für Kategorien keine weiteren Abhängigkeiten bestehen, ist dessen Erstellung der erste Schritt bei<br />
der Katalog-Verschmelzung.<br />
Das Übertragen und Auflösen <strong>von</strong> Intrakatalog-Patternreferenzen kann nicht in einem Durchlauf erfolgen,<br />
da oft der Fall auftreten wird, dass ein neuer Eintrag für KT einen Patterneintrag aus seinem Quellkatalog<br />
referenziert, welcher jedoch noch nicht in KT angelegt ist. Zur Überwindung dieses Hindernisses wird während<br />
der Übernahme-Phase der alternative Referenzierungsmechanismus über die Pattern-IDs genutzt. Erst<br />
nach Eintragung aller Patterns in KT werden diese Pattern-IDs, mittels OCL-Queries, in die korrekten Objektassoziationen<br />
umgerechnet. Außerdem erfolgt noch eine aufsteigende Sortierung der Katalogeinträge<br />
nach der Pattern-ID, dies erwies sich als praktisch für die nachgelagerte manuelle Duplikatsuche. Natürlich<br />
wird im Rahmen der Referenzierungskorrektur ebenfalls der Fall gehandhabt, dass eine interkatalog<br />
Patternreferenz auf einen Eintrag im Verschmelzungspartnerkatalog zeigt; die Konsequenz dieses Falles ist<br />
schlicht, dass aus der interkatalog eine lokale intrakatalog Referenz wird.<br />
Etwas aufwändiger gestaltet sich die Vermischung falls ein Pattern, beziehungsweise dessen ID, in beiden<br />
Katalogen auftritt. Die Grundannahme für die automatische Transformation ist, dass ID-Äquivalenz<br />
auch semantische Äquivalenz beinhaltet. Selbstverständlich erfordert jeder einzelne Fall eine gründliche<br />
Überprüfung dieser Annahme.<br />
Für die Vermischung der Welie und Tidwell-Kataloge trifft die Annahme zu. Insgesamt existieren lediglich<br />
drei gleichbenannte Patterns, im Einzelnen: „Wizard“, „Liquid Layout“und „Center Stage“. Wie bereits<br />
dargelegt, unterscheidet sich die Qualität der Beschreibungen in den Katalogen. Das Mischen zweier Einträge<br />
verfolgt daher das Konzept, einen Eintrag als Primärquelle auszuwählen und diesen durch die Informationen<br />
aus der Sekundärquelle aufzufüllen oder zu ergänzen. Für die Welie-Tidwell-Transformation
3.5. PATTERN ALS KOMPONENTEN 77<br />
habe ich mich für die Patterneinträge <strong>von</strong> Tidwell als Primärquelle entschieden, weil diese subjektiv besser<br />
ausgearbeitet und durchdacht erscheinen.<br />
Einen wirklichen Unterschied ergibt sich durch diese priorisierte Quellenwahl nur für die URL-Einträge zu<br />
Context, Diagram und Illustration. Ist in der Primärquelle bereits ein Wert für diese Eigenschaft gesetzt, wird<br />
derjenige der Sekundärquelle verworfen und nicht in KT übernommen.<br />
Viele Aspekte eines Patterns werden auch in PLML durch reinen Text beschrieben. Beim Zusammenführen<br />
dieser textuellen Informationen werden die Ausgangstexte jeweils in eigene HTML- Blöcke verpackt.<br />
Dies ist einerseits ein deutlicher Indikator dafür, dass an dieser Stelle menschliche Nachbearbeitung notwendig<br />
ist, ermöglicht aber gleichzeitig einem PLML-Renderer die beiden Textblöcke geeignet zu trennen<br />
oder auch nur einen der Texte darzustellen.<br />
Bei Eigenschaftswerten mit der Multiplizität 1 : ∗ werden die Einträge aus der Sekundärquelle, nach bestehen<br />
eines einfachen Duplikat-Checks, den Einträgen der Primärquelle hinzuaddiert. Das betrifft zum<br />
Beispiel Literature, Evidence und RelatedPatterns.<br />
Ich habe mich entschieden bei dem Wert für Confidence <strong>von</strong> dem Primär-/Sekundärschema abzuweichen.<br />
Aus meiner Sicht ist die Abqualifizierung eines Patterneintrags zu einem Patternkandidat oder der Entscheidung<br />
auf „Nicht-Pattern“ ein gravierender Schritt der auf sorgfältigen Erörterungen beruht. Dem angemessen<br />
wird immer der minimale Confidence-Wert der beiden Patterneinträge als Confidence-Wert des KT -<br />
Eintrages eingesetzt. Alle Patterns sowohl des Tidwell- als auch des Welie-Katalog sind mit dem Confidence<br />
-Wert „**“ ausgezeichnet, die vorstehenden Betrachtungen sind für deren Mischung, mit Ausnahme der in<br />
Tabelle 3.4 erwähnten Abstufungen, nicht relevant.<br />
Keine Änderungen im Vermischungsfall ergibt sich für die Vorgehensweise der Auflösung der Patternverlinkungen,<br />
diese werden genauso im Post-Verschmelzungdurchlauf in Objektreferenzen umgesetzt. Die<br />
Kategoriezuordnung des verschmolzenen Patterneintrags erfolgt wiederum entsprechend der Kategorie der<br />
Primärquelle.<br />
Im Ergebnis der Welie-Tidwell-Katalogverschmelzung entsteht ein Katalog mit 26 Kategorien und 172<br />
Pattern-Einträgen. Die Analyse des Transformationsergebnisses ergibt, dass das Duplikat des Patterns „Color<br />
Coded Sections“ nicht erkannt wurde und somit zweifach im Ergebniskatalog vorliegt. Grund war,<br />
dass Tidwell das Pattern „. . . Sections“ nennt, während Welie auf das Plural-S verzichtet. Diese Patternverschmelzung<br />
war also noch manuell anzustoßen, wodurch sich letztlich der vereinheitlichte Katalog auf 171<br />
Patterneinträge reduziert.<br />
3.5.3 Deklarationsmodell für Patternkomponenten<br />
Für die Beziehungen zwischen den Pattern im verschmolzenen Katalog sind selbstverständlich mehr Aspekte<br />
als die reine Namensgleichheit zu betrachten. Dazu zählt insbesondere die genauere Spezifikation der<br />
Pattern-Querbeziehungen. Andere Angaben die, im Rahmen der menschlichen Nachbearbeitung, nachträglich<br />
korrigiert oder hinzugefügt werden sind die Confidence-Klassifizierung, die Kategorisierung des<br />
Patterns aber auch so grundlegende Informationen wie der offizielle bzw. vereinheitlichte Name des Patterns.<br />
Grundsätzlich könnten diese Informationen direkt durch manuelle Anpassung der PLML-Beschreibung<br />
erfolgen. Bei der Betrachtung des Gesamt-Workflows wäre eine solche Vorgehensweise jedoch mindestens<br />
als hinderlich zu bezeichnen. Denn, ausgehend <strong>von</strong> den Web-Inkarnationen der Kataloge konnte bis<br />
hierhin der verschmolzene Katalog ausschließlich über automatisierte Transformationen generiert werden.<br />
Im Falle <strong>von</strong> Aktualisierungen der Webkataloge lassen sich diese Informationen somit sehr schnell neuer-
78 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
lich auslesen. Editierte man nun das PLML-Transformationsergebnis manuell, dann stellte sich, bei einer<br />
anschließenden Neugenerierung ausgehend <strong>von</strong> den Webkatalogen, das Problem, wie diese Nachbearbeitungsvorgänge<br />
geeignet in den neugenerierten Katalog übertragen werden könnten.<br />
Eine verwendbare Lösung dieses Problem bietet PLMLComponent, das PLML Komponentenmodell. Modellinstanzen<br />
dieses Metamodells dienen dazu Komponenten zu beschreiben welche Patterns umsetzen.<br />
Der Aufbau dieses Hilfs- oder Ergänzungsmodells ermöglicht es, PLMLComponent gleichzeitig als Reparaturmodell<br />
für PLML-Kataloge einzusetzen.<br />
PLML bietet, abgesehen <strong>von</strong> den Implementation-Objekten, keine Möglichkeit der Definition <strong>von</strong> Patternkomponenten.<br />
Anpassungen <strong>von</strong> PLML in dieser Richtung sind natürlich denkbar. Dabei ist jedoch zu<br />
beachten, dass PLML auf Grund seiner Sprachauslegung nicht auf eine bestimmte Art <strong>von</strong> Patterns beschränkt<br />
ist. Daraus läßt sich die Forderung ableiten, die Patternkomponenten ebenfalls domänenunabhängig<br />
zu definieren. Dies hätte wiederum ein sehr allgemeines, schwach typisiertes und zur automatischen<br />
Weiterverarbeitung der Komponentendeklarationen wenig geeignetes Modell zur Folge. Für die Deklaration<br />
eines separaten, und PLML nur ergänzenden, Komponentendeklarationsmodells mussten diese PLML-<br />
Beschränkungen nicht beachtet werden.<br />
Das Ergebnis der Überlegungen zu PLMLComponent ist in Abbildung 3.9 als Klassendiagramm angegeben.<br />
Um die Modellinstanzen <strong>von</strong> PLML und PLMLComponent möglichst unabhängig <strong>von</strong>einander<br />
definieren zu können, habe ich darauf verzichtet aus dem PLMLComponent-Modell heraus direkt Pattern<br />
-Instanzen in PLML-Katalogen zu referenzieren, stattdessen wird der Fallback-Mechanismus, über den<br />
Abbildung 3.9: Metamodell für PLMLComponent
3.5. PATTERN ALS KOMPONENTEN 79<br />
Primärschlüssel patternId:String, eingesetzt. Die einzige direkte Verwendung <strong>von</strong> Bestandteilen des PLML-<br />
Metamodells ist die Enumeration PatternLinkType zur Deklaration der Art des Links.<br />
Die Anordnung der Klassen <strong>von</strong> Abbildung 3.9 ist nicht beliebig. Im oberen Teil dieser Abbildung sind<br />
die domänenunabhängigen Bestandteile des PLMLComponent-Modells angeordnet. Wohingegen die untere<br />
Hälfte die notwendigen Spezialisierungen für die HCI-Domäne deklariert. Würde man PLMLComponent<br />
erweitern, um damit Komponenten für andere Patternarten zu deklarieren, sollten wiederum konkrete<br />
Unterklassen <strong>von</strong> Entry und Component gebildet werden welche die spezifischen Adaptionen an diese neue<br />
Domäne beinhalten.<br />
Die Klasse Components dient als Modellwurzel und Container für Katalogeinträge (Entry). Deren Instanzen<br />
definieren jeweils ein Pattern und dessen zugeordnete Komponenten. Die Klassen LinkPattern, für das<br />
Hinzufügen <strong>von</strong> Patternbeziehungen, NameLabel zur Korrektur <strong>von</strong> ID oder Bezeichnung des Patterns und<br />
Confidence setzen den PLML-Wartungszweck <strong>von</strong> PLMLComponent um, d.h. sie deklarieren ergänzende<br />
oder überschreibende Informationen über ein Pattern.<br />
Die getroffene Auswahl der wartbaren Patterninformationen deckt lediglich die Basisbedürfnisse der Katalogwartung,<br />
konkret sind das die bei der Katalogverschmelzung aufgetretenden Probleme, ab. Prinzipiell ist<br />
es denkbar, auch für die hier nicht betrachteten Pattern-Aspekte eigene Informationsergänzungsklassen für<br />
PLMLComponent zu spezifizieren oder wahlweise direkt die PLML-Metaklassen geeignet zu referenzieren<br />
und weiterzuverwenden. Das entscheidende Problem ist weniger die Auswahl der Aspekte <strong>von</strong> PLML<br />
die via PLMLComponent editiert werden können, als wie die Instanzen <strong>von</strong> PLMLComponent genutzt<br />
werden können um einen PLML-Katalog zu überarbeiten.<br />
Prinzipiell soll PLMLComponent auch zur Deklaration der Algorithmen der Patterntransformationen eingesetzt<br />
werden. Die Einbindung der jeweiligen Transformation kann über das data-Attribut der Klasse Entry<br />
erfolgen. Leider scheint es nicht sinnvoll den Datentyp dieser Assoziation genauer als als EObject zu definieren.<br />
Dies ist dadurch beding, dass an dieser Stelle alle theoretisch denkbaren Transformationstechniken<br />
angebunden werden können sollen. Weil kein übergeordnetes allgemeines Metamodell für Transformationen<br />
existiert, musste der kleinste gemeinsamen Nenner genutzt werden.<br />
Einsatz des Komponentenmodells zur Katalogbereinigung<br />
Das Zusammenführen zweier Instanzen <strong>von</strong> PLMLComponent und PLML bezeichne ich als Verweben,<br />
angelehnt an die Bedeutung dieses Wortes in der aspektorientierten Softwareentwicklung. Das Verweben ist<br />
eine ordinäre Model-To-Model Transformation. Als Transformationsergebnis entsteht ein neuer Katalog,<br />
d.h. eine neue PLML-Instanz, welcher die korrigierten und gefilterten Patterneinträge enthält.<br />
Die Abbildung 3.10 illustriert das Zusammenspiel <strong>von</strong> PLMLComponent, PLML und QVT-operational<br />
(QVTo) als Transformationssprache. Selbstverständlich wird vor dem Verweben eine Reihe <strong>von</strong> Plausi-<br />
PLML<br />
PLMLComponent<br />
Weiterverarbeitung<br />
QVTo<br />
PLML<br />
QVTo<br />
Verweben Generator<br />
PLMLComponent<br />
Abbildung 3.10: Zusammenhänge und Transformationen <strong>von</strong> PLML und PLMLComponent
80 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
bilitätschecks durchgeführt. Durch die Nutzung <strong>von</strong> QVTo ließen sich diese verhältnismäßig einfach als<br />
OCL-Abfragen implementieren.<br />
Bei dem nachfolgenden Listing 3.3 handelt es sich um einen dieser Checks. Die dort deklarierte QVT-<br />
Query liefert eine Liste aller Entry-Objekte einer PLMLComponent-Instanz für die die Patternquerbeziehungen<br />
unzureichend spezifiziert sind. Diese Query wird in vier Tests benutzt, die im Einzelnen sicherstellen<br />
dass die contradicts und comparable-Relationen bidirektional spezifiziert sind, sowie die<br />
contains und is-contained-by jeweils paarweise in beide Richtungen deklariert werden.<br />
Die is-a-Beziehung wird im Zusammenhang des Verwebens als Äquivalenzmarker zweier Patterns betrachtet.<br />
Eine solche Patternbeziehung führt dazu, dass bei der Transformation das Pattern in welchem<br />
der is-a Eintrag vorliegt aus dem Katalog entfernt wird. Während der Entfernung eines Katalogeintrages<br />
werden sämtliche bisher auf dieses Pattern verweisenden kataloginternen Verlinkungen auf das jeweils<br />
per is-a-referenzierte Pattern umgeschrieben. Zur Konsistenzsicherung wird deshalb im Rahmen eines<br />
weiteren PLMLComponent-Checks sichergestellt, dass für neudefinierte is-a Patternbeziehungen keine<br />
zirkulären Abhängigkeiten bestehen.<br />
✞ ☎<br />
//Liefert alle Entry−Objekte für die es einen Link vom Typ fromSelector gibt,<br />
//ohne das es im damit referenzierten Entry einen Link zurück vom Typ reverseSelector gibt<br />
query Components::checkCrossRelation<br />
(in fromSelector : PatternLinkType, in reverseSelector : PatternLinkType ) : OrderedSet(Entry) {<br />
return self.entry<br />
−>select(links.type−>includes(fromSelector))<br />
−>select(ent|ent.links−>select(type=fromSelector)<br />
−>select(link|self.entry−>select(link.patternId=patternID).links−>select(type=reverseSelector).patternId<br />
−>includes(ent.patternID))<br />
−> size()=0);<br />
}<br />
✝ ✆<br />
Listing 3.3: QVTo/OCL Testselektion zur Qualitätssicherung der PLMLComponent-Instanz<br />
Die Angaben in Tabelle 3.5 vermitteln einen Eindruck über den Umfang der, während der Modellverwebung<br />
eingearbeiteten, manuellen Nachbearbeitungen. Zur Erläuterung dieser Tabelle, bei den Namensanpassungen<br />
handelt es sich um achtzehn Patternbezeichnungen des Welie-Kataloges, die in dessen PLML-<br />
Daten nicht angegeben waren und um eine Pattern-ID Korrektur, ebenfalls bei Welie, ein Tippfehler. Ebenfalls<br />
aufgrund <strong>von</strong> Tippfehlern im Welie-PLML mussten die beiden Kategoriezuordnungen nachträglich<br />
manuell vorgenommen werden, hier handelt es sich um reine Fehlerbehebungen.<br />
Im Gegensatz dazu sind sämtliche neu definierten Patternbeziehungen manuell getroffene Klassifikations-<br />
Modifizierte Patterns: 98<br />
Anzahl Namensanpassungen: 19<br />
Anzahl Kategoriezuordnungen: 2<br />
Anzahl is-contained-by-Beziehungen: 7<br />
Anzahl contains-Beziehungen: 7<br />
Anzahl is-a-Beziehungen: 36<br />
Anzahl comparable-Beziehungen: 18<br />
Anzahl contradicts-Beziehungen: 6<br />
Anzahl Confidence-Reratings: 22<br />
Tabelle 3.5: Größenordnungen zur Nacheditierung des verschmolzenen Katalogs
3.5. PATTERN ALS KOMPONENTEN 81<br />
entscheidungen. Aufgrund der bereits erwähnten PLMLComponent-Checks ist die Anzahl der is-contained-by<br />
und contains natürlich gleich, und die Anzahl der comparable und contradicts<br />
gradzahlig. Bei den 22 Confidence-Neubewertungen handelt es sich durchgängig um Abwertungen,<br />
die ist die logische Konsequenz daraus, dass bei der ursprünglichen automatischen Datenübernahme alle<br />
Einträge der Webkataloge mit dem Alexander-Confidence-Rating ∗∗ aufgenommen wurden.<br />
3.5.4 Einordnungen <strong>von</strong> Einzelpatterns<br />
Im Anhang der Arbeit finden sich ausführliche Tabellen zur Klassifikation der einzelnen Patterns. Daher<br />
soll an dieser Stelle nur kurz ein Eindruck über die Art der Einträge gegeben werden.<br />
Den Anfang macht die Tabelle 3.6. Hierin ist aufgelistet, welche Patterns als äquivalent, in Idee bzw.<br />
Lösung, einem anderen Pattern sind. In der linken Spalte sind die Patterns aufgelistet die die jeweilige<br />
Pattern-Idee umfassend darstellen, während die auf der rechten Seite aufgeführten Patterns nur Teilaspekte<br />
desselben Patterns enthalten oder anderweitige Kopien sind.<br />
Einzelne Patterns wie „Wizard“ und „Accordion“ sind in dem verschmolzenen Katalog in sehr vielen<br />
ähnlichen Variationen anzutreffen. Andere Einträge, insbesondere einige 1 : 1-Zuordnungen wie bei „Row<br />
Striping“ und „Sortable Table“ sind wiederum nur Patterndoppelungen die mit der einfachen Heuristik,<br />
Primärpattern Zuordnungen via is-a<br />
Map Navigator Store Locator<br />
Flyout Menu Dropdown Chooser, Pulldown button<br />
Guided Tour Virtual Product Display, Wizard<br />
Wizard Guided Tour, Help Wizard, Product Advisor, Product Configurator<br />
Sortable Table Table Sorter<br />
Center Stage Overview and Detail, View<br />
Global Navigation Footer bar, Main Navigation, Repeated Menu, Footer sitemap<br />
Collector Purchase Process, Shopping Cart<br />
Input Hints Search Tips<br />
Slideshow Scrolling Menu, Stepping<br />
Article Page Product Page<br />
Progress Indicator Processing Page<br />
Simple Search Search Area<br />
Forms Comment Box<br />
Accordion Closable Panels, Collapsible Panels, Inplace Replacement, Navigation Tree<br />
Scrolling Menu Carrousel, Illustrated Choices, Slideshow<br />
Row Striping Zebra Table<br />
Fill-in-the-Blanks Shortcut Box<br />
Cascading Lists Double tab, Two-Panel Selector<br />
Card Stack Tabbing<br />
Extras On Demand Details On Demand, Inplace Replacement<br />
Tree-Table Product Comparison<br />
Directory Navigation Faceted Navigation, Sitemap, Split Navigation<br />
Illustrated Choices Image Menu, Scrolling Menu<br />
Overview Plus Detail Panning Navigator<br />
Tabelle 3.6: Tabelle der als äquivalent zugeordneten Patterns
82 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
über die ID-Gleichheiten, bei der ursprünglichen Welie/Tidwell-Verschmelzung nicht als gleich erkannt<br />
wurden.<br />
Durch das Entfernen der 36 is-a Einträge aus dem verschmolzenen Katalog konnte dieser auf 135 Patterns<br />
reduziert werden. Für diese war nun zu untersuchen welche Patterns vermutlich komponentisierbar<br />
sind.<br />
Technisch geschieht dies durch Aufbau und Pflege einer weiteren Instanz des PLML-Component Metamodells.<br />
Die darin vorgenommenen Eintragungen sind nunmehr keine Eintragskorrekturen mehr, sondern<br />
enthalten ergänzende Komponentisierbarkeitsinformationen zu dem jeweiligen Patterneintrag. In der Prozessdarstellung<br />
in Abbildung 3.10 wird diese Weiterverarbeitungsmöglichkeit des PLML-Kataloges auf<br />
der rechten Seite der gestrichelten Linie angedeutet.<br />
Die dazu notwendige Datenerfassung und der Aufbau der notwendigen Modellinstanz ist eine manuelle<br />
Tätigkeit. Dennoch lässt sich z.B. mit einer Model-To-Model Transformation eine gewisse automatisierte<br />
Hilfestellung geben. Da die Struktur der PLMLComponent-Ecoreinstanz, in welcher die Komponentisierbarkeitsinformationen<br />
hinterlegt werden, bekannt ist, kann eine Eintragungsschablone per QVTo aus dem<br />
zu beschreibenden PLML-Katalog generiert werden. Die benötigte Transformation legt einfach ein neues<br />
PLML-Component Modell und darin für jedes Pattern des PLML-Katalogs eine HCIEntry-Instanz mit den<br />
vorgegebenen Standardwerten an. Die Standardwerte können dem in Abbildung 3.9 dargestellten Metamodell<br />
entnommen werden.<br />
Im Rahmen der Arbeit wurde keine zusätzliche Werkzeugunterstützung zur Pflege des Komponentenmodells<br />
erstellt, die Möglichkeiten des im Eclipse Modeling Framework stets verfügbaren reflektiven Ecore-<br />
Editors zeigten sich ausreichend.<br />
Vorgehensweise<br />
Die Entscheidung zur Vermutung über die Komponentisierbarkeit eines Patterns erfolgte nach folgendem<br />
Schema:<br />
1. Kategorisierung, d.h. Zuordnung des zutreffenden Literals der Enumeration Categorization<br />
2. Einordnung in eine CAMELEON-Ebene, zur Zuordnung dient die Enumeration CameleonLayer<br />
3. Entscheidung Komponentisierbarkeit, sofern grundsätzlich komponentisierbar, jeweils für XUL und<br />
Swing:<br />
(a) Komponentisierbarkeitsklassifikation, Zuweisung eines Literals <strong>von</strong> Classification<br />
(b) Einbettung der Komponente/Komponentenreferenz über das data:Object-Attribut<br />
(c) Komponententyp setzen, d.h. Zuordnung zu einem Literal der Enumeration ComponentType<br />
(d) Hinweismarker für die mögliche Komponentenverwendung setzen, d.h. Zuordnung zu einem<br />
Literal der Enumeration ComponentUsage<br />
Kategorisierung der Einträge<br />
Bereits in der Einführung wurde begründet, dass die Darstellbarkeit einer Patternlösung als Instanz eines<br />
Algorithmus eine Komponentiesierbarkeitsvoraussetzung sein dürfte. Da die Einträge des erstellten<br />
Pattern-Kataloges eine breite Streuung bezüglich Einsatzdomäne und Anwendungsebene aufweisen, finden<br />
sich in ihm eine Reihe Patterns für die prinzipbedingt kein Algorithmus angegeben werden kann. in
3.5. PATTERN ALS KOMPONENTEN 83<br />
einer Grobkategorisierung wird versucht solche Patterneinträge zu identifizieren. Im PLMLComponent-<br />
Metamodell sind sieben Patternkategorien vordefiniert. Die nachfolgende Auflistung nennt die Einzelkategorien<br />
und gibt jeweils ein Beispiel eines zugeordneten Patterns.<br />
• CUIPattern – Pattern für konkrete oder endgültige Userinterfaces (z.B.: „Date Selector“)<br />
• Layout – Pattern schlägt eine bestimmte Anordnung, teilweise im Sinne eines Layoutmanagers vor<br />
(z.B.: „Grid-based Layout“)<br />
• Workflow – Patterneintrag beschreibt im Wesentlichen einen Prozessablauf (z.B.: „Purchase Process“)<br />
• HumanToHuman – Marker für Verfahren der zwischenmenschlichen Kommunikation (z.B.: „Storytelling“)<br />
• Template – fertige Designvorlage/-vorschrift (z.B.: „Input Error“)<br />
• Concept – bezeichnet Patterns die eine Konzeption oder einen Entwurf für eine Vorgehensweise<br />
beschreiben, ohne den Detailgrad <strong>von</strong> CUIPatterns oder Layout zu erreichen (z.B.: „Few Hues, many<br />
Values“)<br />
• Unspecified – Platzhalterkategorie für nicht in die vorigen Kategorien einordbare Fälle<br />
Die Einordnung in eine der Kategorien „HumanToHuman“, „Concept“ oder „Template“ bedeutet implizit,<br />
dass wohl keine Komponente für das jeweilige Pattern angebbar ist. Insbesondere für die „Template“-<br />
Kategorie kann diese Festlegung hinterfragt werden, da je nach Betrachtungsweise Templates sehr wohl<br />
als Instanzen <strong>von</strong> Patterns betrachtet werden könnten. Die Entscheidung wurde nach Untersuchung der<br />
Einträge des Kataloges so getroffen. Bei den dort als „Template“ kategorisierten Pattern handelt es sich<br />
oftmals um Vorlagenideen für Web-CMS 10 , etwa zur Gestaltung künstlerischer Homepages („Artist Site“)<br />
oder für Webseiten sozialer Netzwerke („Community“). Für eine sinnvolle Umsetzung dieser Patterns im<br />
Rahmen des modellgetriebenen Prozess nach Kapitel 2 müssten auch die dem Interface vorgelagerten Modellebenen<br />
Aufgabenmodell und Dialoggraph einbezogen werden. Die dabei zu überwindenden Probleme<br />
sind derweil noch zahlreich und in absehbarer Zeit eher nicht in Algorithmen abbildbar.<br />
Quantitative Angaben über die Zuordnungen aller Patterns zu diesen Kategorien enthält die Tabelle 3.7.<br />
Die Kategorie „Unspecified“ wurde im Fall des verschmolzenen Patternkatalogs nicht benötigt, alle Patterneinträge<br />
konnten kategorisiert werden. Zusätzlich findet sich in der dritten Spalte der Tabelle 3.7 eine<br />
Information darüber, für wieviele Patterneinträge der jeweiligen Kategorie die Deklaration <strong>von</strong> Komponenten<br />
bzw. Komponentenreferenzen möglich scheint.<br />
10 Content Management Systeme<br />
Kategorie Anzahl eingeordneter Patterns Anzahl Komponentenangaben<br />
CUIPattern 77 77<br />
Concept 26 0<br />
HumanToHuman 3 0<br />
Layout 4 4<br />
Template 21 0<br />
Unspecified 0 –<br />
Workflow 4 2<br />
Tabelle 3.7: Kategorisierung der 135 Patterns des verschmolzenen Katalogs
84 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Einordnung gemäß CAMELEON<br />
Als eine weitere Klassifizierung der Vielzahl der Patterns scheint es nützlich zu sein, den primären Anwendungsbereich<br />
der Patternlösung im Rahmen des modellgetriebenen Gesamtprozesses einzuordnen. Mit<br />
dem bereits vorgestellten CAMELEON-Referenzframework steht dazu ein geeigneter allgemein akzeptierter<br />
Standard zur Verfügung. Nach der Einordnung der Einträge des erstellten Gesamtkatalogs ergaben sich<br />
die folgenden Zuordnungen für die einzelnen CAMELEON-Ebenen:<br />
• Task and Concepts – 21 Patterns, da<strong>von</strong> lassen sich vermutlich für zwei Patterns („Login“, „Registration“)<br />
auf CUI-Ebene nutzbare Komponenten entwickeln<br />
• Abstract User Interface – dieser Abstraktionsebene wurden 0 Patterns zugeordnet. Das ergab sich<br />
daraus, dass die Ausdruckskraft der Modelle dieser Ebene äußerst beschränkt ist, siehe auch Unterabschnitt<br />
2.1.3, und deren Instanzen kaum dazu geeignet sind die Patterns <strong>von</strong> Welie oder Tidwell<br />
abzubilden.<br />
• Concrete User Interface – gemäß dem Zweck der Ausgangskataloge ist dies die Hauptgruppe der<br />
Zuordnungen. 87 Pattereinträge werden der CUI zugeordnet, Angaben zur Komponentisierbarkeitsvermutung<br />
existieren für 81 da<strong>von</strong>.<br />
• Final User Interface – 23 Patterns, insbesondere alle 21 als Template kategorisierten Patterns sowie<br />
die beiden, letztlich nur auf der FUI-Ebene umsetzbaren, Konzepte „Forgiving Format“ und„Enlarged<br />
Clickarea“.<br />
• Unzutreffend – vier Patterns lassen sich nicht nach CAMELEON einordnen: die drei HumanToHuman-Patterns<br />
und das Konzept-Pattern „Fun “.<br />
Sprachabhängigkeit<br />
Mit den bisherigen Erörterungen und Abgrenzungen zur Komponentisierbarkeit ließ sich die Anzahl der in<br />
Frage kommenden Patterneinträge auf 83 reduzieren. Jedes einzelne da<strong>von</strong> wurde daraufhin untersucht, ob<br />
es unter Verwendung <strong>von</strong> XUL beziehungsweise Java Swing als Komponente umsetzbar wäre. Besonders<br />
interessant war die Frage, ob es zwischen den beiden UI-Systeme Unterschiede in Bezug auf die Komponentisierbarkeit<br />
geben würde. Die Eingangsvermutung, dass es solche Unterschiede existieren, bestätigte<br />
sich im Zuge der Untersuchung.<br />
Arnouts in Tabelle 3.3 wiedergegebene Komponentisierbarkeits-Klassen werden als allgemeines Einordnungsschema<br />
für die Komponenten weiterbenutzt. Lediglich die beiden Punkte 2.1.1 „Komponentengerüst<br />
mit Methoden“ und 2.1.2 „Komponentengerüst ohne Methoden“ lassen sich in diesem Anwendungsfall<br />
nicht nutzbringend verwenden, stattdessen wird nur deren Obergruppe 2.1 „Komponentengerüst erstellbar“<br />
zur Einordnung benutzt.<br />
Die Klassendiagrammdarstellung ( Abbildung 3.9) des PLMLComponent-Metamodells zeigt unter anderem<br />
die Enumeration Classification. Deren Wertliterale dienen der modellbasierten Umsetzung der Klassifikation.<br />
In der Tabelle 3.8 wird der semantische Zusammenhang der Literale zum Klassifikationsschema<br />
definiert. Die erste Spalte enthält die Ordnungsnummer der Arnout-Referenzklasse und die zweite Spalte<br />
führt das zugeordnete Literal der Aufzählung auf.<br />
Größenordnung der Klassifikationsergebnisse<br />
Die Komponentisierbarkeitsabschätzung der in Frage kommenden 83 Patterns ergab für die Benutzung <strong>von</strong><br />
XUL als CUI-Sprache die in Tabelle 3.9 präsentierte Vermutung. Von den 83 Patterneinträgen lassen sich
3.5. PATTERN ALS KOMPONENTEN 85<br />
Arnout-Referenz PLMLComponent Classification-Literal<br />
1.1 LanguageBuiltin<br />
1.2 LibrarySupported<br />
1.3.1 FullyComponentizable<br />
1.3.2 IncompleteComponentizable<br />
1.3.3 ComponentizableWithDeviationFromPatternIdea<br />
1.3.4 ComponentizableButUseless<br />
1.4 CandidateForComponent<br />
2.1 ComponentSkeleton<br />
2.2 PossibleComponentSkeleton<br />
2.3 SomeLibrarySupport<br />
2.4 NotComponentizable<br />
Tabelle 3.8: Zuordnung der Classification-Literale zur Arnout’schen Einordnung<br />
demnach wahrscheinlich 31 Patterns direkt als Komponenten umsetzen. Das umfasst alle Einträge welche<br />
entweder bereits in der Sprache XUL integriert, vermutlich als Komponentenalgorithmus dargestellt werden<br />
können oder <strong>von</strong> denen bekannt ist, dass sie in externen Bibliotheken verfügbar sind. Für zwanzig der<br />
83 Patterneinträge lassen sich nach den Resultaten der Untersuchung wohl keine Komponenten angeben<br />
oder erstellen.<br />
Die Tabelle 3.10 führt die numerische Aufstellung der Komponentisierbarkeitsvermutungen mit Java<br />
Swing als CUI-System auf. In diesem Framework sind 37 der 83 Einträge vermutlich als Komponente<br />
umsetzbar oder werden bereits vom System bereitgestellt. Bei Swing lassen sich für elf Patterns wahrscheinlich<br />
keine Komponenten angeben.<br />
Vergleichende Betrachtung<br />
Eine vergleichende Auswertung der Auswirkung der CUI-Sprache auf die Komponentisierbarkeit ist natürlich<br />
ebenfalls reizvoll. Da es sich bei der Klassifizierung um eine Modellinstanz <strong>von</strong> PLMLComponent<br />
handelt, kann wiederum QVTo für numerische oder statistische Auswertungen eingesetzt werden.<br />
Per OCL-Anfragen lassen sich diverse Aspekte untersuchen und Abhängigkeiten oder Zusammenhänge<br />
identifizieren.<br />
Klassifikation eingeordnete Patterns<br />
LanguageBuiltin 7<br />
LibrarySupported 6<br />
FullyComponentizable 18<br />
IncompleteComponentizable 6<br />
ComponentizableWithDeviationFromPatternIdea 12<br />
ComponentizableButUseless 10<br />
CandidateForComponent 4<br />
ComponentSkeleton 6<br />
PossibleComponentSkeleton 2<br />
SomeLibrarySupport 2<br />
NotComponentizable 10<br />
Tabelle 3.9: Komponentisierbarkeitsvermutung mit XUL als CUI-Sprache
86 KAPITEL 3. PATTERNS UND KOMPONENTEN<br />
Klassifikation eingeordnete Patterns<br />
LanguageBuiltin 9<br />
LibrarySupported 9<br />
FullyComponentizable 19<br />
IncompleteComponentizable 4<br />
ComponentizableWithDeviationFromPatternIdea 16<br />
ComponentizableButUseless 12<br />
CandidateForComponent 3<br />
ComponentSkeleton 5<br />
PossibleComponentSkeleton 0<br />
SomeLibrarySupport 2<br />
NotComponentizable 4<br />
Tabelle 3.10: Komponentisierbarkeitsvermutung mit Java Swing als CUI-System<br />
Eine Möglichkeit für eine entsprechende QVT-Abfrage zeigt Listing 3.4. Aufgerufen auf ein Components-<br />
Objekt liefert diese Query alle Entry-Instanzen deren Komponenten in einer ersten Sprache als classification<br />
eingeordnet wurden, deren Komponentenklassifikation in der zweiten Sprache jedoch da<strong>von</strong> abweicht.<br />
Damit lassen sich beispielsweise diejenigen Patterns identifizieren, für die möglicherweise keine XUL-<br />
Komponenten erstellbar sind, aber Swing-Komponenten denkbar oder zumindest die Vermutung einer<br />
Komponentenunterstützung besteht. Das Parameter-Tripel zur Abfrage dieser konkreten Konstellation mit<br />
der angegebenen OCL-Query wäre: (ComponentType::Swing, ComponentType::XUL, Classification::Not-<br />
Componentizable). Damit erhielte man als Vergleichsergebnis die Katalogeinträge „Thumbnail“ , „ Diagonal<br />
Balance“ , „Movable Panels“ , Constrained Resize“ , „Inplace Replacement“ und „Composite Selection“.<br />
Bei Umkehrung der Sprachreihenfolge ist die Ergebnismenge leer, d.h. es liegen keine Einträge vor,<br />
für die eine Komponentisierbarkeit mit Swing nicht wahrscheinlich ist, jedoch für XUL möglich erscheint.<br />
✞ ☎<br />
// Vergleich der Komponentisierbarkeit nach Sprachen, liefert alle HCIEntry−Objekte deren Komponenten<br />
// in lang1, jedoch nicht in lang2, in classification eingeordnet worden sind<br />
query Components::compareLanguages(<br />
in lang1:ComponentType, in lang2:ComponentType, in classification:Classification) : Set(Entry) {<br />
return<br />
let entries = self.entry−>select(components−>size()>0) in<br />
entries−>select(components.oclAsType(HCIComponent)−>any(type=lang1).classification=classification)−><br />
−(entries−>select(components.oclAsType(HCIComponent)−>any(type=lang2).classification=classification)); }<br />
✝ ✆<br />
Listing 3.4: QVTo/OCL Sprachvergleichsabfrage über dem PLMLComponent-Metamodell<br />
Zusammenfassung und Verwendung<br />
Der mit den Metamodellen PLML und PLMLComponent aufgebaute Patternkatalog, ergänzt um die Komponenteneinträge,<br />
soll zukünftig die Transformationen für den patternbasierten modellgetriebenen Entwicklungsprozess<br />
nach Kapitel 2 bereitstellen. Zur Untersuchung der Machbarkeit wurde in einer ersten<br />
Phase ein weniger ambitioniertes Ziel verfolgt. Der Katalog wurde an den, in Punkt 2.1.4.3, vorgestellten<br />
XUL-Editor angebunden. Damit ist es mit diesem Werkzeug und der damit verbundenen Engine möglich,<br />
die XUL-Komponenten der Patterneinträge für die Gestaltung <strong>von</strong> Oberflächen einzusetzen. Zwar zeigt<br />
dies die prinzipielle Verwendbarkeit und Plausibilität des Ansatzes, überläßt gleichwohl eine Vielzahl noch<br />
notwendiger Schritte nachfolgenden Arbeiten.
Kapitel 4<br />
Reengineering Interaktiver Systeme<br />
Unter der Bezeichnung Reengineering werden Methoden zur Modifikation des Quellcodes <strong>von</strong> bereits bestehenden<br />
und im Einsatz befindlichen Anwendungen subsummiert. Typischerweise werden die Systeme<br />
auf welche Reengineering angewendet wird als Legacy-Systeme bezeichnet. Das englische Substantiv Legacy<br />
1 impliziert, dass es sich zumeist um bereits langlaufende Systeme handelt. Die genaue Schwelle,<br />
ab welcher ein System als Legacy-Software eingeordnet wird, ist jedoch bestenfalls weich definiert und<br />
kontextabhängig. Als zeitlich gesehen unterer Extrempunkt ist folgende Definition anzusehen: „Sobald<br />
man die 2. Zeile Quellcodes beginnt handelt es sich bei der 1. Zeile um Legacy-Code“ . Diese Aussage,<br />
eines Kollegen bei einem Workshop [102], ist zutreffend aber wenig hilfreich. Eine anschauliche Klassifizierungshilfe<br />
stammt <strong>von</strong> Bruce Trask [127]: „Legacy-Software ist Software deren Quellcode-Basis sich<br />
Wartung und Erweiterungen widersetzt“ .<br />
Unter Quellcode sind hierbei jegliche Artefakte der softwaretechnischen Basis zu sehen, welche zur Bereitstellung<br />
einer einsatzfähigen Version der Software nötig sind. Das sind unter anderem Build-Skripte,<br />
auch solche für Datenbank-Schemata, jegliche Art <strong>von</strong> Resourcen-Dateien wie Bilder oder Sounds, Zertifikate<br />
und Übersetzungsdateien. Ferner zählen API-Schnittstellen, etwa Header-Files, oder komplette Bibliotheken<br />
dazu. Diese Auflistung ist nicht abschließend und kann daher, je nach den Anforderungen an<br />
die konkrete Software, Weiteres umfassen.<br />
Der Vorgang des Reengineering zerfällt grundsätzlich in die zwei Teilbereiche Reverse- und Forward-<br />
Engineering. Oftmals fehlen für Legacy-Systeme Dokumentationen über Schnittstellen, Build-Umgebung<br />
und Packaging oder auch Teile des eigentlichen Quellcodes. Das Ermitteln und Bereitstellen dieser notwendigen<br />
Informationen wird als Reverse-Engineering bezeichnet. Der RE-Begriff umfasst also alle Verfahren<br />
und Methoden, um solche fehlenden Quellcode-Artefakte aus dem Legacy-System selbst zu extrahieren.<br />
Das Verändern und die Neukombination der so zusammengesammelten Artefakte wird dann als Forward-<br />
Engineering bezeichnet, es unterscheidet sich im Allgemeinen nicht <strong>von</strong> der jeweils üblichen Vorgehensweise<br />
zur Softwareerstellung in der jeweiligen Domäne. Im Ergebnis eines erfolgreich durchgeführten<br />
Reengineerings entsteht eine einsetzbare modifizierte Variante des ursprünglichen Legacy-Systems.<br />
Nachfolgend beschreibt Abschnitt 4.1 eine allgemeine Vorgehensweise zur Erzeugung <strong>von</strong> Modellen aus<br />
Quellcode, diese Methode wird benutzt um ein Ecore-Metamodell für Java Swing zu erzeugen. Im anschließenden<br />
Abschnitt 4.2 wird gezeigt, wie aus der Benutzungsoberfläche einer vorhandenen, nicht modellbasiert<br />
entwickelten, Java-Anwendung eine äquivalente deklarative Instanz des zuvor erzeugten Swing-<br />
Metamodells erstellt werden kann.<br />
1 Altlast, Hinterlassenschaft, o.ä.<br />
87
88 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
4.1 Reverse Engineering und modellgetriebene Softwareentwicklung<br />
Im Mittelpunkt dieser Arbeit steht das Paradigma der modellgetriebenen Softwareentwicklung. Die bei<br />
weitem überwiegende Mehrzahl der heutigen Software wurde jedoch nach anderen Paradigmen entwickelt.<br />
Um die Akzeptanz <strong>von</strong> MDSE weiter zu erhöhen ist eine Methodik wünschenswert, welche es ermöglicht,<br />
existierende Softwareprojekte soweit als möglich in die MDSE-Welt zu überführen. Gleichzeitig ist es<br />
anzustreben, die Vorteile <strong>von</strong> MDSE auch auf die Wartung und Weiterentwicklung <strong>von</strong> Legacy-Software<br />
anzuwenden. Schließlich ist es eines der Kernversprechen des Paradigmas in genau diesen Problemfeldern<br />
Vorteile gegenüber den klassischen Verfahren zu haben.<br />
Die Möglichkeit zur Übertragung existierender Systeme in einen modellgetriebenen Ansatz wird durch<br />
mehrere Faktoren bestimmt.<br />
Konformität die Konzeption der Software sollte sich mittels des Beschreibungsmittel der Meta<br />
Object Facility darstellen lassen.<br />
Granularität für die Software sollte sich eine Modellhierarchie ergeben.<br />
Assoziativität es sollten sich Relationsbeziehungen zwischen Modellelementen ergeben.<br />
Der Aspekt der Konformität spielt auf den Fakt an das die Methodik der MOF-MDSE inhärent einen<br />
objekt-orientierten Ansatz verfolgt. Je weiter das zu beschreibende System <strong>von</strong> dieser Konzeption entfernt<br />
ist, desto weniger nutzbringend wird eine Modellierung sein. Dies liegt in der Tatsache begründet, dass<br />
die Hauptbeschreibungsmittel der Objektorientierung Klassen und Objekte sowie deren Beziehungen untereinander<br />
sind. Das Anwenden dieser Beschreibungsmittel auf funktionale oder logische Programme ist<br />
natürlich möglich, erscheint aber nicht übermäßig nützlich. So kann die Syntax eines Prolog-Term oder<br />
einer Funktionsdeklaration in Haskell ohne große Probleme als Instanz eines geeigneten Meta-Modells<br />
dargestellt werden. Dennoch, die eigentliche Mächtigkeit dieser Sprachen bzw. Paradigmen entstammt ja<br />
nicht ihrer Syntax sondern den damit beschriebenen Konzepten wie Unifikation, Backtracking oder Rekursion,<br />
um nur einige Beispiele zu nennen. Dies sind jeweils Denkmodelle die sich nur schwer vollständig in<br />
MOF-Modellen abbilden lassen.<br />
Die Granularität einer Modellbeschreibung ist ein wesentlicher Qualitätsmaßstab der Modellierung. Idealerweise<br />
ist eine solche Beschreibung so konkret wie nötig und so allgemein wie möglich. Das Modell der<br />
Anwendung muss in der MDSE die Möglichkeit bieten, daraus Quellcode zu generieren. Gleichzeitig muss<br />
das Modell, um der Wartbarkeit etc. Genüge zu tun, einen guten und korrekten Überblick über das System<br />
liefern. Aus dieser Anforderung lässt sich somit der Zwang zu einer Hierarchiebildung ableiten. Die oberste<br />
Ebene einer solchen Hierarchie liefert dabei die grundlegende Einteilung, etwa im Sinne eines Kontextdiagramms,<br />
und ein entsprechender Drill-Down auf die unterste Ebene führt bis zu den Quellcodeeinheiten in<br />
welchen die eigentliche Datenhaltung und Verarbeitungslogik definiert wird.<br />
Ein nachgelagertes Kriterium für die Modellgüte ist der Grad der Definition <strong>von</strong> Assoziationen. Die Beziehungen<br />
zwischen den Modellobjekten sollten so genau wie möglich beschrieben werden. Die hierfür<br />
zur Verfügung stehenden Beschreibungsmittel, das sind insbesondere die Typisierung sowie die Kardinalitätenangaben<br />
<strong>von</strong> Relationen und die Angabe <strong>von</strong> Aggregationsbeziehungen, sollten ausgiebig verwendet<br />
werden. Neben den direkten Beziehungen sind an dieser Stelle auch Präzisierungen mittels der OCL anzubringen.<br />
Je genauer das Modell beschrieben werden kann, desto besser bildet es das Problem ab und desto<br />
nutzbringender wird dessen Einsatz sein.<br />
Sicherlich muss man sich an dieser Stelle Gedanken über eine etwaige Überspezifikation machen. Unter<br />
Überspezifikation versteht man dabei im Allgemeinen exzessives Definieren <strong>von</strong> Details, ohne das dem
4.1. REVERSE ENGINEERING UND MODELLGETRIEBENE SOFTWAREENTWICKLUNG 89<br />
ein adäquater Nutzwert auf der entsprechenden Modellebene entgegensteht. Beispielsweise wäre das Hereinziehen<br />
<strong>von</strong> Implementierungsdetails auf die Modellebene, wie etwa mit OCL möglich, ein Fall <strong>von</strong><br />
Überspezifikation. Dazu ist jedoch grundsätzlich zu sagen, dass eine Überspezifikation zwar das allgemeine<br />
Handling des Modells erschwert, aber im Gegensatz zu unterspezifizierten Modellen keine zusätzlichen<br />
falschen Interpretationen des Modells oder falsche Aktionen zulässt. Die Wahrscheinlichkeit <strong>von</strong> Bugs,<br />
also Fehlern des Modells, ist in erster Linie <strong>von</strong> der Qualifikation der Modellierer abhängig und weniger<br />
<strong>von</strong> der Größe des Modells. Aus diesem Grund stellt Überspezifikation kein wesentliches Problem dar.<br />
Lässt sich für das zu modellierende Legacy-System keine aussagekräftige Hierarchie definieren oder enthält<br />
das resultierende Modelle nur wenige Relationen zwischen den Modellobjekten so sind dies beides Kontraindikatoren<br />
für den Einsatz <strong>von</strong> MOF-MDSE Methodik und im speziellen Fall für dessen Anwendung<br />
im Rahmen <strong>von</strong> Reengineering. Insgesamt eignet sich also Software, welche nach dem objektorientierten<br />
Paradigma entwickelt wurde, am besten für ein MOF-MDSE Reverse Engineering.<br />
4.1.1 Reverse Engineering <strong>von</strong> Objektmodellen<br />
Das Objektmodell der Geschäftslogik ist eines der zentralen Modelle bei Anwendung <strong>von</strong> MDSE zur Softwareentwicklung.<br />
In diesem Abschnitt werden die Möglichkeiten zur Gewinnung <strong>von</strong> Objektmodellen <strong>von</strong><br />
objektorientierten Legacy-Anwendungen diskutiert.<br />
Die grundsätzliche Vorgehensweise ist dabei mehrstufig und wird mit dem Ziel betrieben ein MOF, bzw.<br />
EMF, konformes Klassenmodell zu erzeugen. Die Vorgehensweise ist dabei an die oben beschriebenen<br />
Anforderungen für erfolgreiches Reengineering angelehnt und besteht aus folgenden Schritten:<br />
1. Bereitstellung oder Beschaffung des Quellcodes<br />
2. Ermittlung der Package-Struktur<br />
3. Aufbauen einer Klassenhierarchie über die gefundenen Klassen im Quellcode<br />
4. Bestimmen der Attribut- und Assoziationstypen sowie der Kardinalitäten<br />
Bereitstellung oder Beschaffung des Quellcodes<br />
Natürlich ist das Vorhandensein auswertbaren Quellcodes die Grundvoraussetzung für die hier dargestellte<br />
Vorgehensweise. Für alle nicht interpretierten Sprachen ist dessen Beschaffung keine triviale Aufgabe.<br />
Aus eigener Erfahrung bei der Softwareentwicklung <strong>von</strong> produktiv eingesetzter Software kann ich sagen,<br />
dass es schon mehrfach unmöglich war den genauen Quellcode für eine ganz bestimmmte Einsatzversion<br />
zu rekonstruieren. Meine Erfahrungen entstammen dabei kommerzieller OpenSource-Software. Von<br />
einer Grundversion einer Software DF4.0 wurden dabei mehrfach zum Installationszeitpunkt bestimmte<br />
ausgewählte Bugfixes oder Funktionalitätserweiterungen in den Einsatzquellcode eingepflegt, jedoch aus<br />
nicht dokumentierten Gründen nie alle. Der dabei entstandene Quellcode-Snapshot wurde normal übersetzt<br />
und das Resultat, bei zufriedenstellender Funktionalität, so beibehalten. Unglücklicherweise wurde<br />
dieser Snapshot jedoch nicht ausreichend protokolliert und dokumentiert, sondern in letzter Konsequenz<br />
gelöscht. Die Situation in diesem Szenario war letztlich so, dass zwar im Grunde bekannt war welche Evolution<br />
der Software eingesetzt wurde und der dementsprechende Quellcode auch vorlag, dennoch traten<br />
diverse Programmfehler nicht bei allen Installationen oder aber nicht mit den gleichen Folgen auf. Sicherlich<br />
hätten diese Effekte mit besserer Organisation vermieden werden können, allerdings treten sie in der<br />
Praxis offenbar immer wieder auf und sollten daher betrachtet werden.
90 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Wenn der Quellcode einer bestimmten Anwendung nicht mehr vorliegt, und auch nicht aus Versionskontrollsystemen<br />
oder ähnlichem beschafft werden kann, muss versucht werden, durch Dekompilierung äquivalenten<br />
Ersatz zu beschaffen. Je nach dem Grad des Schutzes, welchen die originalen Entwickler der<br />
Software gegen derartige Methoden vorgesehen haben, wird die Qualität des Dekompilates ausfallen.<br />
Dekompiler übersetzen die einzelnen Maschinensprachbefehle, oder auch Befehlssequenzen etwa bei Schleifen,<br />
in Standardsyntaxkonstrukte. Schon bei dieser Rückübersetzung stehen eine Reihe <strong>von</strong> Informationen<br />
aus dem Originalquellcode nicht mehr zur Verfügung.<br />
Ein Beispiel: Bekannterweise lassen sich alle drei Hauptarten <strong>von</strong> Schleifen (kopf- oder fussgesteuert,<br />
sowie Zählschleifen) ineinander überführen, das wissen auch die Entwickler <strong>von</strong> Compilern. Auf der Ebene<br />
der Maschinensprache gibt es daher oftmals nur einen Schleifentyp. So gibt es im Bytecode der Sprache<br />
Java nur kopfgesteuerte Schleifen, also while-Konstrukte.<br />
Ein weiterer wichtiger Aspekt ist die Art der im Kompilat enthaltenen Debug-Informationen und generell<br />
der Symboltabellen. Bereits die Namensgebung <strong>von</strong> Methoden, Klassen und Variablen gibt oft einen guten<br />
Hinweis auf deren Verwendung. Im Normalfall wird, sowohl in der Lehre als auch in der bezahlten Softwareentwicklung,<br />
darauf gedrungen, dass eine sprechende Namensgebung durch den jeweiligen Entwickler<br />
angewendet wird, da dies eine nachgewiesenermaßen große Hilfe bei der Interpretation und dem Verstehen<br />
<strong>von</strong> Quellcode ist.<br />
Eine beliebte Methode zur Verschleierung des eigenen Quellcodes ist es daher, diese Benennungskonvention<br />
zu hintertreiben. Das Ziel ist es, im Kompilat keine aussagekräftigen Namen mehr zu behalten.<br />
Weil man dennoch nicht darauf verzichten möchte das der eigene Quellcode lesbar bleibt, übernehmen<br />
sogenannte Code-Obfuskatoren die Umbenennung <strong>von</strong> Variablen als Präprozessoren vor dem eigentlichen<br />
Compiler. Nachteil dieser Vorgehensweise sind insbesondere unleserliche Fehlermeldungen und schwer<br />
interpretierbare Stack-Traces.<br />
Weitere Werkzeuge zur Erschwerung der Dekompilierung sind Exe-Packer und sämtliche Ansätze mit<br />
selbstmodifizierendem Quellcode. Exe-Packer komprimieren die Compiler-Ergebnisse. Bei der Ausführung<br />
wird zunächst ein Bootstrap-Programm geladen und gestartet welches dann online, zur Laufzeit im<br />
Speicher, dekomprimiert und das eigentliche Programm startet. Gepackte Programmdateien lassen sich<br />
jedoch auch wieder entpacken und dann einer Dekompilierung zuführen. Selbstmodifizierender Code ändert,<br />
wie der Name impliziert, sich selbst durch absichtliches Überschreiben <strong>von</strong> Instruktionen im Speicher<br />
durch andere Anweisungen. Das Dekompilieren der statischen Dateien führt daher zu vollkommen anderen<br />
Erkenntnissen als eine Untersuchung der im Speicher vorliegenden Version.<br />
Zusammenfassend kann festgestellt werden, dass wenn derjenige Entwickler, welcher die Einsatzversion<br />
einer objektorientierten Legacy-Software erstellt hat, diese mit Debug-Informationen und ohne Code-<br />
Verschleierung kompiliert hat, ein Dekompiler möglicherweise Quellcode liefern kann der qualitativ ausreichend<br />
zur Einsteuerung in den Modellbildungsprozeß ist.<br />
Im einfachen Fall, und sicherlich auch gar nicht so selten, steht der originale Quellcode einer Legacy-<br />
Software zur weiteren Verarbeitung direkt zur Verfügung.<br />
Ermittlung der Package-Struktur<br />
Zur Gruppierung <strong>von</strong> Funktionalitäten und Zuständigkeiten sieht die Objektorientierung den Mechanismus<br />
der Packages vor. Darunter werden hierarchische Container-Strukturen verstanden. Die Klassen, aus welchen<br />
ein solches Softwareprojekt besteht, werden dem jeweils semantisch passenden Container zugeordnet.<br />
Neben dieser Kategorisierungsfunktion der Package-Container sind mit einer solchen Zuordnung zumeist<br />
auch noch Konsequenzen in Bezug auf die Sichtbarkeit der einzelnen Klassen verbunden. Was wiederum
4.1. REVERSE ENGINEERING UND MODELLGETRIEBENE SOFTWAREENTWICKLUNG 91<br />
Auswirkungen auf die Zulässigkeit <strong>von</strong> Assoziationen zwischen Klassen disjunkter Packages haben kann.<br />
Aufbauen einer Klassenhierarchie über die gefundenen Klassen im Quellcode<br />
Das Mapping zwischen den im Quellcode vorgefundenen Klassen sowie den im resultierenden MOF-<br />
Modell anzulegenden Klassenobjekten wird zunächst 1:1 sein. Für jede Klasse des Originalquellcodes,<br />
inklusive innerer Klassen oder generischer Typparameter, wird ein entsprechendes Klassenobjekt angelegt.<br />
Dabei ist besonders darauf zu achten die Vererbungsbeziehungen korrekt abzubilden oder sie, im Falle<br />
der Typparameter, so weit wie möglich einzuschränken. Jede Klasse wird dabei genau einem Package<br />
zugeordnet. In diesem Schritt ist auch die genaue Art der Klasse zu berücksichtigen. Klassenobjekte im<br />
EMF-Ecore können abstrakte oder konkrete Klassen, Interfaces, Enumerations oder unspezifizierte Datentypen<br />
sein. Unspezifizierten Datentypen kommen zum Einsatz wenn es nicht möglich oder erwünscht ist<br />
Details zur Beschreibung eines Typs anzugeben. Diese Datentypen enthalten maximal eine Referenz zu einer<br />
sie implementierenden, meist nicht modellierten, Klasse. Für jede im Quellcode vorgefundene und als<br />
Typ identifizierte Klasse ist derjenige Datentyp zu wählen welcher dem originalen Charakter am nächsten<br />
kommt. Dies ist kein triviales Problem und hat im Einzelfall weitreichende Konsequenzen. Der gewählte<br />
Datentyp ist dann in dem passenden Package dem Modell hinzuzufügen.<br />
Bestimmen der Attribut- und Assoziationstypen sowie der Kardinalitäten<br />
Das Vorhandensein einer innerhalb <strong>von</strong> Packages aufgebauten Typ- bzw. Klassenhierarchie ist die Grundlage<br />
für die Spezifikation <strong>von</strong> Attributen und Assoziationen. In einem letzten Schritt wird also der Legacy-<br />
Quellcode auf diese Eigenschaften hin untersucht. Hierbei ist es wiederum nötig auf die Spezifika der<br />
MOF-Modelle einzugehen, also Assoziationen mit ihren Kardinalitäten einzutragen und Spezialfälle wie<br />
Aggregationen zu erkennen und so genau wie möglich umzusetzen. Besondere Probleme stellen in diesem<br />
Schritt die Sichtbarkeitsbeschränkungen und konstante Werte dar.<br />
4.1.2 Kriterien für die Ableitung <strong>von</strong> MOF-Modellen aus Java-Quellcode<br />
Der in Unterabschnitt 4.1.1 skizzierte allgemeine Ablauf wurde für Quellcode der Programmiersprache<br />
Java umgesetzt. Dabei wird als MDSE-Zielmodell ein EMF-Ecore Modell erstellt. Zur Durchführung war<br />
es nötig einige Entscheidungen bezüglich der Übertragung <strong>von</strong> Java-Konzepten auf das Ecore-Metamodell<br />
zu treffen.<br />
Sichtbarkeiten<br />
Für jede Klasse, jedes Interface und Attribut, wird in Java eine Sichtbarkeit bzw. Zugriffseinschränkung<br />
festgelegt. Die Angabe kann explizit mittels Schlüsselwort erfolgen, zugelassen sind private, public und<br />
protected. Durch Weglassen eines Schlüsselwortes nutzt man die Standardsichtbarkeit. Die Zugriffsbeschränkung<br />
resultiert teilweise auch implizit aus dem Kontext. Spezifiziert man beispielsweise ein Attribut,<br />
inklusive Wertzuweisung, innerhalb eines Interfaces, wird im Endeffekt eine public-Konstante angelegt.<br />
Im EMF-Metamodell (Ecore) sind keine solchen Zugriffsbeschränkungen vorgesehen. Jedes Modellelement,<br />
welches über die formatinhärenten Mechanismen, als „XPath-like“ im Standard beschrieben, adressiert<br />
werden kann, kann referenziert werden. Dies entspricht einer public-Sichtbarkeit für alle Modellobjekte.<br />
Das Ecore-Modell erlaubt es, jedes Element mit beliebigen Schlüssel/Wert-Annotationen zu versehen. Über<br />
diesen Mechanismus wäre es in jedem Fall möglich, die Sichtbarkeitsinformation in das resultierende
92 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Modell zu übernehmen. Dies wäre jedoch nicht standardisiert und die im Ecore-Umfeld allgemein verwendeten<br />
Werkzeuge schenkten einer solchen Annotation keinerlei Beachtung. Aus diesem Grund wurde<br />
entschieden nicht auf diese Art der Implementierung zu setzen.<br />
Stattdessen wurden die möglichen Konsequenzen dieser omnipräsenten public-Sichtbarkeit evaluiert. Negative<br />
Folgen im Sinne eines ungültigen Modells können nur bei folgender Konstellation auftreten: Namensgleichheit<br />
aber Typwidersprüchlichkeit <strong>von</strong> Attributen in einer Oberklasse und einer in der Vererbungshierarchie<br />
darunter liegenden Unterklasse. Zusätzlich müssen diese betroffenen Features in der Vererbungskette<br />
versteckt worden sein. Dies ist zum Beispiel der Fall wenn ein Attribut in der Oberklasse private<br />
war oder wenn es sich um eine Vererbung <strong>von</strong> Attributen mit Standardsichtbarkeit über Packagegrenzen<br />
handelt. Listing 4.1 illustriert den ersten Fall. Im daraus resultierenden Modell hätte die Unterklasse zwei<br />
Attribute gleichen Namens, aber mit unterschiedlichem Typ. Da Attribute in EMF nur über den Namen,<br />
nicht über deren komplette Signatur, identifiziert werden, ist in diesem Fall das Modell mehrdeutig und<br />
somit ungültig.<br />
✞ ☎<br />
class Oberklasse {<br />
private String lokalesAttribut;<br />
}<br />
class Unterklasse extends Oberklasse {<br />
private Character lokalesAttribut;<br />
}<br />
✝ ✆<br />
Listing 4.1: Sichtbarkeitsüberlagerung bei gleichbenannten Attributen<br />
Listing 4.1 ist kein Beispiel für einen guten Programmierstil, dennoch treten solche Fällen in der Praxis<br />
auf. Im Ergebnis ist das resultierende Ecore-Modell ungültig. Tritt eine solche Situation auf, muss immer<br />
ein menschlicher Modellierer entscheiden wie weiter zu verfahren ist. Eine pragmatische Lösung scheint<br />
zunächst zu sein, dass in der Oberklasse auftretende Attribut aus dem Ecore-Modell zu löschen; mit der<br />
Begründung, dass das Verstecken des Attributes der Oberklasse offenbar die Intention der Entwickler war.<br />
Diese Strategie könnte jedoch zu kurz greifen, denn die Tatsache, dass in einem Ast des Vererbungsbaums<br />
eine Kollision auftrat, impliziert nicht dass die Eigenschaft in den Instanzen der Oberklasse nicht benötigt<br />
wird.<br />
Varianz bei Vererbungen in Java<br />
Um bei Vererbungsbeziehungen zwischen Java-Klassen eine Methode zu Überschreiben müssen deren<br />
Eingabeparameter invariant definiert werden und der Typ der Ausgabe invariant oder kovariant sein. Dies<br />
ist eine strengere Forderung als sie aus dem Liskovschen Substitutionsprinzip [146] folgt, erfüllt dieses<br />
jedoch und ist damit typsicher. Die vorstehend dargestellten Namenskollisionen können bei Methoden<br />
ebenfalls auftreten, konkret dann, wenn eine Methode mit invarianten Eingabeparametern weiter oben in<br />
der Typhierarchie definiert und über private o.ä. versteckt war.<br />
In dem Fall aus Listing 4.2 würde sich kein gültiges Ecore-Modell ergeben. Eine Methodensignatur in EMF<br />
besteht aus dem Namen und der Sequenz der Eingabeparametertypen der Methode. Für jede dieser Signaturen<br />
wird in Ecore-Modellen Eindeutigkeit innerhalb eines Typs gefordert. Im Beispiel <strong>von</strong> Listing 4.2<br />
resultieren im Typ Unterklasse zwei Methoden mit der Signatur methode(ParamObertyp p), dies ist nicht zulässig.<br />
Die Art der Varianz des Ausgabetyps bzw. generell dessen Typ spielt für diese Art <strong>von</strong> Problemen<br />
keine Rolle, da der Ausgabetyp nicht zur Methodensignatur innerhalb EMFs zählt.<br />
✞ ☎<br />
class ParamObertyp { };
4.1. REVERSE ENGINEERING UND MODELLGETRIEBENE SOFTWAREENTWICKLUNG 93<br />
class ParamUntertyp extends ParamObertyp { }<br />
class Oberklasse {<br />
private ParamObertyp methode(ParamObertyp p) {return new ParamObertyp();}<br />
}<br />
class Unterklasse extends Oberklasse {<br />
ParamUntertyp methode(ParamObertyp p) {return new ParamUntertyp();}<br />
}<br />
✝ ✆<br />
Basistypen<br />
Listing 4.2: Potentielles Modellierungsproblem bei kontravariantem Ausgabeparametertyp<br />
Aus Praktikabilitätsgründen existieren sowohl in Java als auch in Ecore EMF vordefinierte Basistypen. Es<br />
ist sinnvoll die Basistypen <strong>von</strong> Java, sowie deren objektorientierte Äquivalente die sogenannten Wrapperklassen,<br />
auf die entsprechenden Ecore-Typen abzubilden. Tabelle 4.1 stellt die vorgenommenen Abbildungen<br />
vor.<br />
Die interessanteren Einträge in Tabelle 4.1 sind sicherlich diejenigen mit dem „-“ in der ersten Spalte.<br />
Die Klassen String und Date zählen zwar nicht zu den Basistypen, werden jedoch so häufig eingesetzt, dass<br />
ein Standardmapping sinnvoll erscheint. Mit java.lang.Object existiert außerdem noch eine Art „catchall“-<br />
Mapping, es dient zur Übertragung <strong>von</strong> unspezifizierten Referenzen.<br />
Relationen<br />
Auf der Basis der Signatur eines Attributes zu entscheiden ob dieses eine navigierbare Referenz oder einen<br />
Wertcontainer darstellt ist schwierig. Da für Ecore-Modelle eine solche Unterscheidung vorgesehen ist,<br />
und es nicht sinnvoll erscheint nur den einen oder den anderen Ansatz zu verfolgen, wurde eine Heuristik<br />
zur Unterscheidung entwickelt.<br />
Jedes Attribut einer Klasse wird auch im EMF-Modell als Attribut angelegt falls es vom Typ, oder ein<br />
da<strong>von</strong> abgeleiteter Untertyp, eines der in Tabelle 4.1 vorgestellten Basistypen ist. Ist dies nicht der Fall,<br />
wird stattdessen eine Referenz angenommen und im Modell angelegt. Die Konsequenz ist also, dass die<br />
Java (basis) Java (Wrapper) →Ecore<br />
boolean java.lang.Boolean EBoolean<br />
byte java.lang.Byte EByte<br />
byte[] java.lang.Byte[] EByteArray<br />
char java.lang.Character EChar<br />
- java.util.Date EDate<br />
double java.lang.Double EDouble<br />
float java.lang.Float EFloat<br />
int java.lang.Integer EInt<br />
long java.lang.Long ELong<br />
- java.lang.Object EJavaObject<br />
short java.lang.Short EShort<br />
- java.lang.String EString<br />
Tabelle 4.1: Mapping <strong>von</strong> Java-Typen auf die Ecore-Äquivalente
94 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
automatische Transformation für Beziehungen zwischen den Klassen eines Modells stets Assoziationen<br />
erzeugt und diese nie als Attribute angelegt werden.<br />
Aggregationen<br />
Komposition und Aggregation, als spezielle Assoziationen, sind wichtige Konzepte der Objektorientierung.<br />
Jedoch finden sich weder in Java noch in EMF Syntaxkonstrukte um diese explizit umzusetzen. Ecore kennt<br />
die Spezialbeziehung Containment, welche in der Modellierung einer Aggregation entspricht.<br />
Zur Erkennung <strong>von</strong> Aggregationen im Java-Quellcode wurde wiederum eine Heuristik entwickelt. Indikatoren<br />
für eine Containment-Beziehung finden sich in der Typsignatur. Entspricht diese einem 1-dimensionalem<br />
Array oder handelt es sich dabei um einen Untertyp des java.util.List oder java.util.Collection Interfaces<br />
wird das Vorliegen einer Aggregation angenommen und eine solche mittels der Ecore Entsprechung angelegt.<br />
Diese möglicherweise trivial erscheinende Herangehensweise erwies sich bis dato als durchaus<br />
nützlich.<br />
Generische Klassen<br />
Seit geraumer Zeit, konkret seit der Java Version 1.5, sind auch in dieser Sprache generische Klassen<br />
möglich. Damit einher gehen die Syntaxkonstrukte der Typparameter, dies sind normalerweise einfache<br />
Namenssymbole. Durch das Anlegen dieser Namenssymbole als eigenen Typ im Ecore-Modell kann das<br />
Konzept direkt abgebildet werden.<br />
Es ist jedoch wünschenswert, diese Pseudotypen etwas genauer zu beschreiben. Oft ist es möglich den<br />
Typen des Parameters auf einen weniger allgemeinen Typen als java.lang.Object aufzulösen. Wenn dies<br />
zutrifft, wird statt des Namenssymbols dieser Typ an den Stellen des Typparameters eingesetzt.<br />
Getter and Setter<br />
Den Zugriff auf Attribute nur über spezialisierte Lese(get) und Schreibmethoden(set) zuzulassen ist ein<br />
Standardkonzept, nicht nur in Java-Programmen. Da das Ecore-Modell jedoch <strong>von</strong> der Implementierung<br />
abstrahiert, und diese Methoden auch nicht zur Präzisierung des Modells bzw. des Problems beitragen, ist<br />
es nicht zweckmäßig solche Methoden im Modell beizubehalten. Im Gegenteil, verwendet man das EMF<br />
Modell als Ausgangsbasis für die Codegenerierung so kommt es mit den Standardtemplates zu Namenskollisionen<br />
bei Beibehaltung der Get-/Set-Methoden, da diese ohnehin automatisch generiert werden.<br />
Aufzählungen<br />
Aufzählungen, bzw. Enumerationen, werden oft angewendet um diskrete Wertebereiche zu definieren. Aktuellerer<br />
Java-Quellcode, wiederum ab Sprachversion 1.5, kann sich dafür des Sprachkonstruktes enum<br />
bedienen. Enumerations wurden <strong>von</strong> den Sprachdesigner als Klassen umgesetzt. Diese können wie normale<br />
Klassen mit Attributen und Methoden versehen werden. EMF bietet hierfür den Spezialtyp EEnum, für<br />
diesen sind keine Attribute oder Methoden möglich. Die Abbildung <strong>von</strong> Java auf den Ecore-Typ kann demgemäß<br />
nicht verlustfrei erfolgen. Es ist nur möglich die Literale und ggf. den Ordinalwert im Ecore-Modell<br />
anzulegen, für die große Mehrzahl der Fälle scheint dies jedoch ausreichend.<br />
Simple Enumerationen, also einfache Name→Wert-Beziehungen werden oft auch über simple Listen <strong>von</strong><br />
Konstanten implementiert. Diese Art Aufzählung kann möglicherweise über Heuristiken identifiziert werden.<br />
Es wurde hier jedoch kein solcher Ansatz verfolgt.
4.1. REVERSE ENGINEERING UND MODELLGETRIEBENE SOFTWAREENTWICKLUNG 95<br />
Konstanten<br />
Konstanten werden in Java als unveränderliche Klassenattribute, abgelegt in den Meta-Klassen, implementiert.<br />
Eine Unterscheidung zwischen Objektattribut und Klassenattribut existiert in EMF nicht, auch sonst<br />
kein Konstantenkonzept. Um dennoch nicht auf das in den Konstanten abgelegte Wissen zu verzichten,<br />
wird versucht über Steuerattribute die Konstanteneigenschaft bestmöglich abzubilden.<br />
Jede Konstante einer Klasse wird dazu als normales Attribut der Klasse angelegt, jedoch als nicht änderbar<br />
und unveränderlich deklariert. Zusätzlich wird natürlich der eigentliche Wert im Modell abgelegt. Dieses<br />
Vorgehen ist nicht optimal, aber mit der EMF-Philosophie kaum anders vereinbar.<br />
Sonstige technische Aspekte<br />
Die Konzepte Interface, abstrakte Klasse und Vererbung existieren in EMF und werden beim Java⇒Ecore-<br />
Mapping umgesetzt. Die Tatsache, dass Java Mehrfachvererbung nur für Interfaces zulässt, für normale<br />
Klassen jedoch nicht, stellt bei der <strong>Generierung</strong> eines Ecore-Modells kein Problem dar, da EMF hier<br />
mächtiger ist.<br />
Wie in Unterabschnitt 4.1.1 beschrieben ist die Package-Struktur ein wichtiger Punkt eines Modells. Da<br />
Java selbst dieses Konzept bietet ist hier wiederum nur eine einfache 1:1 Abbildung erforderlich; zwecks<br />
Inter- und Intramodellreferenzierung ist es dabei nötig, für jedes EMF-Package eine eindeutige URI sowie<br />
ein eigenes Präfix zu definieren. Beides kann einfach aus dem Packagenamen abgeleitet werden, schließlich<br />
sind diese zumindest in der vollklassifizierten Fassung eindeutig.<br />
Ein weiteres Problem stellen diejenigen Typen dar, welche zwar referenziert werden, aber im untersuchten<br />
Quellcode-Abschnitt selbst nicht definiert sind. Hier kann es sich z.B. um Bestandteile der Java-API<br />
handeln oder um andere Klassen, die erst zur Laufzeit aus diversen anderen Quellen bereitgestellt werden.<br />
Diese externen, aus Sicht der Quellcode-Auswertung, Referenzen müssen dennoch definiert werden,<br />
um die Referenzierungsbeziehungen beizubehalten. Für diesen Zweck wird ein eigenes Package mit dem<br />
eindeutigen Namen nonlocal angelegt und die externen Referenzen als unspezifizierte Typen dorthin zugeordnet.<br />
4.1.3 Durchführung der Java⇒Ecore Transformation<br />
Unter Berücksichtigung der in Unterabschnitt 4.1.2 festgelegten und begründeten Kriterien wurde eine Anwendung<br />
entwickelt, welche in der Lage ist den Quellcode beliebiger Java-Anwendungen in EMF Modelle<br />
umzusetzen. Dazu bedient sie sich des bekannten JavaDoc-Frameworks.<br />
Das JavaDoc-Framework wurde aus mehreren Gründen für diesen Einsatzzweck ausgewählt. Zum einen<br />
ist es frei erhältlich, zum anderen findet die Untersuchung des Java-Quellcodes mittels des gleichen Parser<br />
statt welcher auch vom Java-Compiler verwendet wird. Dadurch ist sichergestellt, dass alle Sprachfeatures<br />
korrekt, d.h. in diesem Fall genau so wie sie der Compiler interpretiert, aus dem Quellcode ausgelesen<br />
werden. Neben diesem Parser stellt das Framework ein Metamodell zur Verfügung, welches der Beschreibung<br />
der geparsten Informationen dient. Die eigentliche EMF-Erzeugung kann als eine Model-To-Text<br />
Transformation <strong>von</strong> diesem Metamodell in EMFs XMI-Serialisierung durchgeführt werden.<br />
4.1.3.1 Java-Metamodell und M2T-Transformation<br />
Die Abbildung 4.1 stellt die Typen und die Vererbungsbeziehungen in JavaDocs Metamodell dar. Das Modell<br />
wurde mittels der hier beschriebenen Anwendung erzeugt. Dazu wurde das Package com.sun.javadoc
96 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Abbildung 4.1: JavaDocs Java-Metamodell ohne Methoden<br />
vom frei erhältlichen Java-Quellcode transformiert wurde. Die Erzeugung der graphischen Darstellung<br />
erfolgte mittels der Standard EMF-Mechanismen. Wie zu sehen ist, besteht dieses Metamodell im Wesentlichen<br />
aus Schnittstellenbeschreibungen mit der Ausnahme einer Enumeration. Die Verwendung der beide<br />
dort definierten Literale an geeigneter Stelle entscheidet darüber ob der Parser <strong>von</strong> JavaDoc die neueren<br />
Spracherweiterungen ab Java 1.5 berücksichtigt oder nicht. Die diversen Interfaces spezifizieren eine Reihe<br />
get-Methoden welche bei der Auswertung verwendet werden um die gewünschten Informationen des<br />
jeweiligen Typs auszulesen. In Abbildung 4.1 wurden diese Methoden aus Platzgründen nicht mit dargestellt.<br />
Die zugehörigen, also die Schnittstellen implementierenden, konkreten Klassen sind nicht <strong>von</strong><br />
Belang.<br />
Ablauf der Transformation<br />
Das Generieren eines EMF-Modells aus dem Quellcode unterscheidet sich im Ablauf nicht <strong>von</strong> der Erzeugung<br />
der bekannten JavaDoc API-Übersicht. Zunächst erstellt der Parser die entsprechende Instanz des<br />
Metamodells, sämtliche Informationen darin sind ausgehend <strong>von</strong> einer Instanz des Interface com.sun.javadoc<br />
.RootDoc erreichbar. Dieses RootDoc-Objekt wird einer Template-Engine übergeben, diese ist für die weitere<br />
Transformation zuständig. In der JavaDoc-Terminologie wird die Template-Engine Doclet genannt. Jede<br />
Klasse welche eine Methode mit der Signatur public static boolean start(RootDoc rootDoc ) bereitstellt, ist<br />
ein solches Doclet. Es bestehen prinzipiell keine weiteren Anforderungen. Das Standard-Doclet generiert<br />
die typische HTML API-Übersicht. Für die Erzeugung des Ecore-XMI musste also ein adäquates Doclet<br />
erstellt werden.<br />
Die Tabelle 4.2 zeigt die wesentlichen Einstellparameter des EMF-Doclets und deren Voreinstellung für<br />
die Transformation. Die obersten fünf Stellgrößen, welche Elemente überhaupt im Ergebnismodell angelegt<br />
werden, scheinen nicht erklärungsbedürftig. Zu den weiteren Einstellungen: standardmäßig erfolgt<br />
die Erkennung <strong>von</strong> Gettern und Settern rein namensschemabasiert. Dennoch können Fälle auftreten, in<br />
denen diese vereinfachte Erkennung nicht ausreicht und false positives auftreten. Um dem entgegenzuwirken,<br />
kann optional zusätzlich zum Namensschema eine invariate Typübereinstimmung der Parameter zur
4.1. REVERSE ENGINEERING UND MODELLGETRIEBENE SOFTWAREENTWICKLUNG 97<br />
Eigenschaft Standardwert<br />
Methoden in Modell anlegen ja<br />
Attribute in Modell anlegen ja<br />
Konstanten in Modell anlegen ja<br />
Getter in Modell anlegen nein<br />
Setter in Modell anlegen nein<br />
Typinvarianz zur Accessor-Erkennung fordern nein<br />
Innere Klassen in Modell anlegen ja<br />
Eigene Packagehierarchie für innere Klassen nein<br />
Leere Packages verhindern ja<br />
vollqualifizierten Klassennamen als Attributwert setzen ja<br />
Serialisierungsidentifikatoren unterdrücken ja<br />
Sichtbarkeitslevel protected<br />
Verzeichnisse, Packageselektor-Muster, diverse JavaDoc-Steuerparameter<br />
Tabelle 4.2: Parameter zur Steuerung der Java⇒Ecore Transformation<br />
Getter- und Setter-Ermittlung gefordert werden.<br />
Einen eigenen Problemkreis stellen die inneren und anonymen Klassen dar. Anonyme Klassen entstehen,<br />
wenn Interfaces oder abstrakte Klassen direkt bei Zuweisungen implementiert werden, ohne zuvor explizite<br />
Klassendeklarationen durchzuführen. Anonyme Klassen sind also nur konkrete Instanzen anderer, nicht<br />
instanziierbarer, Modelltypen. Es ist daher nicht notwendig sie dem Modell hinzuzufügen.<br />
Innere Klassen sind in anderen Klassen eingebettet. Praktisch können Instanzen innerer Klassen nur über<br />
Instanzen ihrer Host-Klassen erstellt werden. Es besteht also ein enger semantischer Zusammenhang zwischen<br />
diesen Typen, dieser kann jedoch in einem Ecore-Modell nicht mit den Mitteln des EMF nachmodelliert<br />
werden. Stattdessen werden die inneren Klassen ebenfalls als Klassentypen im Ecore-Modell angelegt.<br />
Aus zwei Gründen ist jedoch im Java⇒Ecore-Generator eine Sonderbehandlung vorgesehen. Zum einen<br />
wird durch das Vergeben eines Namenspräfixes, nämlich dem Namen des Host-Typs, zumindest marginal<br />
der ursprüngliche Zusammenhang dargestellt. Wichtiger ist jedoch ein praktisches Problem. Innere<br />
Klassen können zahlreich verwendet worden sein und es kann dabei tatsächlich der Fall auftreten, dass<br />
zu viele Typen innerhalb eines Ecore-Packages definiert werden. Zu viele sind in diesem Fall mehrere<br />
hundert verschiedene Typen in einem Package. Theoretisch stellt dies kein Problem dar, praktisch entsteht<br />
ein unüberwindliches Problem mit dem EMF-Codegenerator für Java. Dieser generiert Methoden deren<br />
kompilierter Bytecode größer als 64kByte wird. So große Methoden sind nach dem Sprachstandard nicht<br />
zugelassen und im Bytecode-Format nicht darstellbar. Im Standard sind für lokale Sprünge 2 Byte große<br />
Zeiger vorgesehen, welche daher keinen größeren Adressraum adressieren können. Zur Umgehung dieser<br />
Problematik, oder vielmehr um den Schwellwert ab welchem diese auftritt nach oben zu verlegen, ist es<br />
möglich, die generierten Typen für die inneren Klassen in einer eigenen Packagehierarchie abzulegen.<br />
Die folgenden beiden Parameter der Tabelle 4.2, vollqualifizierte Klassennamen und Identifikatattribute,<br />
dienen gleichfalls der Behandlung <strong>von</strong> Eigenheiten der Codegenerierungstemplates <strong>von</strong> EMF. Der Quellcode<br />
einer Java-Anwendung ist im Allgemeinen in einen mehrere Hierarchieebenen tiefen Packagebaum<br />
aufgeteilt. Oft enthalten die Knoten nahe der Wurzel keine Klassen, sondern dienen nur der Strukturierung<br />
und Namensgebung. Aus praktischen Gründen sollte diese Eigenschaft so nicht in das EMF-Modell<br />
übertragen werden. Leider handhaben die Code-<strong>Generierung</strong>stemplates typleere Packages fehlerhaft und<br />
generieren ungünstigen oder auch falschen Quellcode dafür. Es ist deswegen vorgesehen, dass das Doclet<br />
in Packages welche keine anderweitigen Typdeklarationen enthalten explizit einen eigenen leeren Typen
98 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
anlegt.<br />
Aus einem ähnlichen Grund ist die Übernahme des vollqualifizierten Klassennamen in das dafür eigentlich<br />
vorgesehene Attribut instanceClassName abschaltbar. Denn, ist dieses EMF-Attribut für einen Typ mit einem<br />
Wert belegt, so wird für diesen Typ kein Quellcode generiert, sondern das Vorhandensein einer externen<br />
Implementierung angenommen und diese lediglich importiert. Dies gilt zumindest für die Verwendung der<br />
standardmäßigen Code-Erzeugungstemplates.<br />
Serialisierungsidentifikatoren, das ist insbesondere das Attribut serialVersionUID, sind Klassenattribute zur<br />
entwicklergesteuerten feingranularen Angabe der Implementierungsversion einer Klasse. Für alle serialisierbaren<br />
Klassen, d.h. Implementierungen des Interfaces java.lang.Serializable, ist die Vergabe einer solchen<br />
ID vom Sprachstandard vorgesehen. Mit dem Übergang in einen MDSE-Prozess ist eine derartige Versionierung<br />
auf Klassenebene meist nicht mehr notwendig. Daher kann insbesondere dieses Attribut bei der<br />
Transformation explizit herausgelöscht werden.<br />
Neben den EMF-Doclet spezifischen Stellgrößen stehen weiterhin alle Einstellparameter <strong>von</strong> JavaDoc<br />
selbst zur Verfügung. Von besonderem Interesse sind dabei die minimale Sichtbarkeit und die Parameter<br />
zur Auswahl der gewünschten Packages.<br />
Nachbearbeitung<br />
Im Ergebnis der Transformation entsteht eine Ausgabedatei in welcher das Modell als Ecore-XMI serialisiert<br />
ist. Dieses Modell ist nicht notwendigerweise valide, es kann also die Erfordernis zu manueller<br />
Nacharbeit bestehen. Das EMF stellt einen Validator bereit, mit welchem die Modelle getestet werden<br />
können.<br />
Neben dem bereits erwähnten Themenkomplex der Sichtbarkeitsproblematiken bei Vererbungen treten<br />
typischerweise weitere Probleme auf. Beispielsweise bei der Namensgebung, Java unterscheidet Groß-<br />
/Kleinschreibung und EMF im Prinzip auch, allerdings wird bei Ecore dringend da<strong>von</strong> abgeraten. Bei<br />
der Codegenerierung werden diverse Variablen- und Konstantennamen aus den Namen der Attribute und<br />
Methoden des Typs abgeleitet. Diese Ableitung erfolgt für Features welche sich nur in der Schreibweise<br />
unterscheiden, nicht eindeutig. Daher wird der EMF-Modellvalidator in solchen Fällen eine Warnung<br />
ausgeben. Aus ähnlichen Gründen dürfen sich Namen nicht nur in der Anzahl der vorangestellten Unterstriche<br />
unterscheiden, es darf also beispielsweise nicht _x und __x als Namen innerhalb desselben Typs<br />
geben. Bei Auftreten solcher Fälle muss manuell einer der betroffenen Namen geändert werden oder die<br />
betroffene Eigenschaft ganz entfernt werden, eine automatische Behandlung erscheint nicht sinnvoll.<br />
4.1.4 Reduzierung der Modelle<br />
Die Modelle, die als Ergebnis der Transformationen in Punkt 4.1.3.1 entstehen, können sehr groß werden.<br />
Für den Quellcode eines Releases der Java-Version 1.5 ergaben sich die in Tabelle 4.3 gezeigten Größenordnungen.<br />
Selbst das kleinste Modell, welches beim Sichtbarkeitslevel public entsteht, ist zu groß um es<br />
Sichtbarkeit Typen Methoden Attribute Externe Typen leere Packages<br />
public 12.689 79.993 891 80 99<br />
protected 13.380 87.193 3.660 96 101<br />
default 16.418 106.007 7.010 102 109<br />
private 18.323 120.736 18.243 152 108<br />
Tabelle 4.3: Modellgrößen für diverse Sichtbarkeitsstufen beim JDK-Parsing
4.1. REVERSE ENGINEERING UND MODELLGETRIEBENE SOFTWAREENTWICKLUNG 99<br />
sinnvoll mit den zur Zeit zur Verfügung stehenden Werkzeugen des EMF zu behandeln.<br />
Beim Studium der Tabelle 4.3 fällt auf, dass die Anzahl der leeren Packages mit zunehmender minimaler<br />
Sichtbarkeit abnimmt, ein zunächst überraschender Effekt. Dieser erklärt sich aus der Art und Weise wie<br />
Packages identifiziert werden. In der vorliegenden Implementierung werden nur die Packages angelegt, in<br />
welchen Datentypen existieren und natürlich deren übergeordnete Packages. Mit der reduzierten Anzahl<br />
der erkannten Klassen sinkt somit im Regelfall auch die Anzahl der erkannten Packages, und damit auch<br />
die Anzahl der leeren Packages.<br />
Bei diesen großen Modellen erweisen sich sowohl der Speicherbedarf als auch die Laufzeit <strong>von</strong> Transformationen<br />
als problematisch, beispielsweise wenn versucht wird, eine graphische Übersicht ähnlich derjenigen<br />
<strong>von</strong> Abbildung 4.1 zu generieren. Dies ist kein besonderer Nachteil des EMF, auch andere Modellierungswerkzeuge<br />
skalieren schlecht bei größer werdenden Modellen.<br />
Um dennoch einen Nutzen aus derartig großen Modellen zu ziehen ist eine Modellverkleinerung anzustreben.<br />
Für eine Reihe <strong>von</strong> Einsatzzwecken in der MDSE wird nicht das gesamte Modell benötigt, sondern es<br />
sind Ausschnitte ausreichend. So werden Transformationen, mit Ausnahme kleiner Modelle, nur in seltenen<br />
Fällen alle Typen und alle deren Eigenschaften eines Modells ändern oder auslesen. Die EMF-Modelle<br />
die durch die Java⇒Ecore Transformation entstehen, enthalten neben den Domänen-Konzepten in aller<br />
Regel auch eine Reihe <strong>von</strong> implementierungsspezifischen Eigenschaften. Beispielhaft seien hier Methoden<br />
für Tracing-Ausgaben oder zur Behandlung <strong>von</strong> Bedienungs- oder Eingabefehlern genannt. Zur weiteren<br />
Bearbeitung im Rahmen der MDSE kann es wünschenswert sein, solche Modelleigenschaften zu entfernen<br />
oder diese zumindest auszublenden.<br />
EMF selbst sieht zur Bildung <strong>von</strong> Modellausschnitten nur das bereits mehrfach angesprochene Konzept<br />
der Packages vor. Dieses führt, je nach Qualität der Umsetzung, zu einer gewissen lokalen Clusterung <strong>von</strong><br />
Typen nach deren Verwendung.<br />
Sen et al. [112] verfolgen einen algorithmischen Ansatz. Der in Algorithmus 1 vorgestellte Prozess dient<br />
dazu, aus einem übergebenen Modell M0 ein reduziertes Ergebnismodell E0 zu generieren welches konform<br />
zu M0 ist. Konformität ist definiert als Enthaltenseinsbeziehung auf der Ebene der Klasseneigenschaften:<br />
Ein Metamodell E0 ist konform zu einem Metamodell M0, wenn für jede Klasse C in E0 genau<br />
eine Klasse C ′ in M0 existiert, so dass alle Eigenschaften und Methoden <strong>von</strong> E0.C mit gleicher<br />
Signatur in M0.C ′ definiert sind. Eine solche Beziehung wird mit dem Operator „< #“ , als<br />
E0 < #M0 notiert.<br />
Der Algorithmus nach Sen basiert auf der Idee, ausgehend <strong>von</strong> einer kleinen Menge initial bestimmter<br />
Typen und Eigenschaften „<strong>von</strong> Interesse“ ein minimales beschnittenes Modell zu erzeugen, welches dennoch<br />
konform zum Ausgangsmodell ist. Es werden verschiedene Strategien zur Durchführung der Modell-<br />
Beschneidung vorgeschlagen, die prinzipielle Strategie stellt Algorithmus 1 vor.<br />
Die Referenz-Implementierung des Algorithmus erfolgte durch Sen innerhalb der Kermeta-Umgebung<br />
[68]. Dabei handelt es sich um spezialisiertes Framework zur Bearbeitung und Transformation <strong>von</strong> Metamodellen,<br />
vergleichbar dem Eclipse Modeling Project. Kermeta ist in der Lage Ecore-Modelle zu imund<br />
exportieren, die Resultate der Java⇒Ecore Transformation lassen sich daher innerhalb Kermeta weiterbearbeiten.<br />
Insgesamt ist festzuhalten, dass die Qualität und der Umfang des resultierenden verkleinerten<br />
Ergebnismodell <strong>von</strong> der geeigneten Wahl der initial geforderten Eigenschaften abhängig ist.
100 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Algorithmus 1 Modellreduzierungsalgorithmus nach [112]<br />
1. Wähle Typen und Eigenschaften aus M0 die das beschnittene Modell enthalten muss<br />
2. Initialisiere das Ergebnismodell E0 mit der Auswahl <strong>von</strong> 1<br />
3. Validiere E0, wenn valide und konform zu M0 ⇒ 8.<br />
4. Entferne nicht referenzierte Attribute (unter Beachtung der Vererbungshierarchie) aus den E0-<br />
Datentypen<br />
5. Füge nicht enthaltene referenzierte Vererbungsobertypen aus M0 in E0 ein<br />
6. Füge nicht enthaltene referenzierte Datentypen aus M0 in E0 ein<br />
7. Wiederholen bei ⇒3<br />
8. Ergebnismodell liefern<br />
Zusammenfassung<br />
Im vorliegenden Kapitel wurde eine grundsätzliche Möglichkeit diskutiert, um aus Java-Quellcode Ecore-<br />
Modelle abzuleiten. Die praktische Umsetzbarkeit wurde gezeigt, aber auch die dabei auftretenden Probleme<br />
herausgestellt. Im nachfolgenden Abschnitt 4.2 wird die Methodik eingesetzt, um ein EMF-Modell<br />
für das Oberflächenframework Swing zu erstellen. Mittels dieses Swing-Metamodells, welches als CUI-<br />
Modell betrachtet wird, können die Oberflächen <strong>von</strong> Swing-Anwendungen in einem UI-MDSE Prozess<br />
beschrieben werden.<br />
4.2 Reverse Engineering des Oberflächenmodells<br />
In diesem Abschnitt wird dargestellt, wie unter Verwendung der in Abschnitt 4.1 vorgestellten Techniken<br />
aus existierenden Nutzeroberflächen <strong>von</strong> Legacy-Anwendungen ein konkretes Oberflächenmodell gewonnen<br />
wird. Die Grundidee dafür ist, zur Laufzeit die Objektstruktur der Oberfläche auszuwerten und diese<br />
in einer Instanz eines geeigneten Metamodells abzubilden. Durch Transformation einer solchen Modellinstanz<br />
ist es in einem weiteren Schritt möglich ein abstraktes Oberflächenmodell abzuleiten. Auf diesem<br />
Weg kann eine Einsteuerung in den normalen modellgetriebenen Oberflächenerzeugungsprozess, siehe<br />
Kapitel 2, erreicht werden.<br />
Die Programmierung <strong>von</strong> Oberflächen ist eine komplexe Aufgabe. Zwar gibt es seit langer Zeit unterstützende<br />
Werkzeuge und verschiedene strukturierende Vorgehensmodelle, wie etwa das MVC-Pattern, viele<br />
Detailaspekte dynamischer Nutzerschnittstellen werden jedoch weiter manuell implementiert. Eine Folge<br />
da<strong>von</strong> scheint zu sein, dass oftmals UI-relevante Quellcode-Teile über den gesamten Quelltext verteilt werden<br />
und nicht ausschließlich in spezialisierten Packages zu finden sind. Daher ist es sehr schwierig, mit<br />
Hilfe der Methodik aus Abschnitt 4.1 oder auch über andere Mechanismen, durch rein statische Code-<br />
Analyse ein zutreffendes Modell der Oberfläche zu gewinnen. Eine gangbare Alternative ist es das zur<br />
Laufzeit instanziierte Objektmodell des Oberflächenframeworks zu untersuchen und, falls möglich, in eine<br />
CUI-Instanz zu transformieren.<br />
4.2.1 Erzeugen eines Swing-Modells aus einer existierenden Oberfläche<br />
Die Grundforderung für den erfolgreichen Einsatz dieser Vorgehensweise ist es, dass die verwendete Oberflächentechnologie<br />
überhaupt Objekthierarchien zur Beschreibung des Nutzerinterfaces einsetzt. Programme<br />
die das Anzeigegerät direkt pixelweise ansteuern erfüllen diese Forderung typischerweise nicht. Vie-
4.2. REVERSE ENGINEERING DES OBERFLÄCHENMODELLS 101<br />
le Oberflächenframeworks der letzten Jahre verwalten jedoch intern den UI-Zustand über baumähnliche<br />
Objektstrukturen. Inwiefern deren Objektinstanzen zur Laufzeit der Introspektion offenstehen ist weiter<br />
abhängig vom Betriebssystem, allgemeinen Sicherheitsmechanismen und ob es sich um eine interpretierte<br />
oder kompilierte Sprache handelt. UI-Toolkits <strong>von</strong> interpretierten objektorientierten Sprachen sind ideale<br />
Kandidaten für diesen Ansatz. Für die Sprache Java stehen drei weitverbreitete Toolkits zur Verfügung:<br />
Swing, AWT und SWT.<br />
Für eine Fallstudie zur Prüfung inwieweit der Laufzeit-Capturing Ansatz praktikabel ist, wurde entschieden<br />
die Oberfläche <strong>von</strong> Swing-Applikationen als Modellinstanzen eines CUI-Modells abzubilden. Zur Durchführung<br />
waren, neben einer entsprechenden Swing-Anwendung, mehrere technologische Voraussetzungen<br />
zu schaffen. Einerseits musste ein geeignetes Metamodell für Swing erstellt werden, andererseits musste<br />
ein Weg gefunden werden auf Objektinstanzen einer aktiven Java-Laufzeitumgebung zuzugreifen.<br />
Das Swing-Metamodell wurde mit dem in Punkt 4.1.3.1 vorgestellten Ansatz erzeugt. Hierzu wurde der<br />
Quellcode unterhalb der Packages javax.swing und java.awt geparst. Wie oben beschrieben, ergänzt Swing<br />
AWT, viele Konzepte und vorhandene Implementierungen für Teilprobleme aus AWT werden <strong>von</strong> Swing<br />
daher weiter benutzt. Darunter sind Kernkonzepte wie die Implementierungen zu Schriftarten und Farben.<br />
Für ein sinnvolles, d.h. aussagekräftiges, Swing-Modell schien es daher angebracht, auch die AWT-Klassen<br />
in das Metamodell zu übernehmen.<br />
Beim Studium des Quellcodes <strong>von</strong> Swing wurde festgestellt, dass in den Klassen viele Methoden implementiert<br />
wurden, die für ein rein die Oberfläche beschreibendes Metamodell irrelevant sind. Als weitere<br />
Einschränkung kam hinzu, dass ein Screenshot nach seiner Natur statisch ist; es besteht demgemäß keine<br />
Möglichkeit die Dynamik des Nutzerinterfaces abzubilden. Im Ergebnis dieser Überlegungen wurde zunächst<br />
entschieden, aus den vorgenannten Java-Packages nur die Attribute und Klassen mit der minimalen<br />
Sichtbarkeit protected zu parsen. Bei der Benutzung dieser Variante des Metamodells stellte sich jedoch<br />
heraus, dass viele Eigenschaften der UI-Widgets als private Attribute deklariert und nur über diverse public<br />
Accessormethoden zugänglich waren. Um diese Attribute dennoch in das Meta-Modell zu übernehmen,<br />
musste die minimale Sichtbarkeit doch auf private reduziert werden.<br />
Im Ergebnis dieses Parsing-Durchlaufs entstand ein Meta-Modell aus 3.128 Typen mit 4.982 Attribute, dazu<br />
147 externe Referenzen. Es handelte sich also wiederum um ein sehr großes Modell. Durch Anwendung<br />
des Model-Pruning Ansatzes <strong>von</strong> Unterabschnitt 4.1.4 konnte das Modell auf circa ein 20stel seiner Größe<br />
reduziert werden. Auf diese Weise ließ sich die Handhabung innerhalb des EMF, beziehungsweise generell<br />
innerhalb des Eclipse Modeling Project, erheblich erleichtern.<br />
Die verhältnismäßig drastische Reduktion erklärt sich insbesondere dadurch, dass viele Klassen im Swing-<br />
Quellcode nur aus Implementierungsgründen notwendig sind. Für die hier angewendete Modellierung sind<br />
aber eigentlich nur die Schnittstellen interessant, diese definieren letztlich die überall verfügbare Funktionalität<br />
<strong>von</strong> Swing. Beispiele für entfernte Modellelemente sind Standardimplementierungen für allgemeine<br />
Aktionen wie Cut&Paste, Behandlung <strong>von</strong> Maus-Ereignissen oder auch die Datenmodelle der verschiedenen<br />
UI-Widgets.<br />
4.2.1.1 Zugriff auf die Swing-Objektstruktur<br />
Wie bereits dargelegt, verwaltet das Swing-Framework die dargestellte Oberfläche intern in einem Objekt-<br />
Graph. Es kann dabei nicht <strong>von</strong> einem Baum gesprochen werden, da navigierbare Querbeziehungen zwischen<br />
den Objekte zugelassen und vorgesehen sind. Der Einstiegspunkt in diesen Graphen ist das oberste<br />
Fensterobjekt: der javax.swing.JFrame. Ausgehend <strong>von</strong> diesem sind sämtliche Eigenschaften aller dargestellten<br />
UI-Widgets erreich- und auslesbar.
102 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Die primäre Herausforderung bestand daher darin, Zugriff auf die durch eine Anwendung erzeugten JFrame<br />
-Instanzen zu erhalten. Selbstverständlich existiert innerhalb des Swing-Framework eine Liste aller erzeugten<br />
JFrames. Zum Abrufen dieser Verwaltungsinformation ist es allerdings erforderlich, einer Java-<br />
Applikation Zugriff auf den gleichen Speicherbereich wie die zu untersuchende Anwendung zu ermöglichen.<br />
Dies erscheint nur durchführbar wenn beide Programme in der gleichen Laufzeitumgebung existieren.<br />
Weil es sich bei der Java-Laufzeitumgebung um einen einzelnen Prozess handelt, kann eine parallele<br />
Existenz nur über Threading-Mechanismen implementiert werden. Daher werden sowohl der Swing-Parser<br />
als auch die Anwendung als eigener Thread gestartet. Das Starten und Konfigurieren dieser Threads übernimmt<br />
eine eigene Steuerungsapplikation. In Abbildung 4.2 sind die Architektur und der schematische<br />
Ablauf dargestellt. Die umgebende Steuerungsapplikation wird in Abbildung 4.2 als Container bezeichnet.<br />
Hauptzweck dieses Containers, neben dem Starten der Threads, ist es, die Ladepfade des Klassenlademechanismus<br />
der Java-Laufzeitumgebung so zu konfigurieren, dass das Laden der Resourcen und des Bytecodes<br />
der Klassen in der <strong>von</strong> der Applikation ursprünglich vorgesehenen Art und Weise funktioniert. Generell<br />
hat sich diese Architektur als tauglich für den gedachten Einsatzzweck erwiesen. Als problematisch haben<br />
sich jedoch verteilte Anwendungen und Programme die einen eigenen Classloader einsetzen herausgestellt.<br />
Im Gegensatz zur sonst üblichen Struktur <strong>von</strong> Swing gibt es für Änderungen an der Liste der JFrames in der<br />
Standard-API keinen Listener-Mechanismus. Der EMF-Generator kommt im Prinzip auch ohne derartige<br />
Meldungen über neu erstellte oder endgültig zerstörte JFrames aus. Es erwies sich jedoch als praktisch,<br />
über eine Tastenkombination direkt aus dem jeweiligen JFrame die EMF-Erzeugung zu starten. Dazu war es<br />
nötig, in jedem neu erzeugten JFrame diese Tastenkombination zu registrieren. Ein eigener Überwachungs-<br />
Thread wertet daher mehrmals pro Sekunde die Liste der aktiven Frames aus. Für neu erkannte JFrames<br />
wird dadurch sehr schnell der Tastatur-Event zur Ecore-<strong>Generierung</strong> registriert.<br />
4.2.1.2 Erstellen der EMF-Instanz<br />
Das Erzeugen einer Instanz des Swing-Metamodells stellt sich im Prinzip als 1 : 1-Abbildung des Swing-<br />
Objektgraphen als Ecore-Modell dar. Der Graph wird grundsätzlich in einem preorder-Durchlauf über das<br />
component-Attribut der Swing-Componenten durchlaufen, beziehungsweise transformiert. Alle Untertypen<br />
<strong>von</strong> java.awt.Container, und das sind alle Java-Widgets, verfügen über dieses Attribut mit der Kardinalität<br />
Container<br />
überwachte Anwendung<br />
JFrame<br />
JFrame<br />
EMF-<br />
Generator<br />
EMF-Instanzen<br />
Abbildung 4.2: Zusammenhang zwischen Wrapper und EMF-Generator
4.2. REVERSE ENGINEERING DES OBERFLÄCHENMODELLS 103<br />
0..∗. Der Werttyp <strong>von</strong> component ist java.awt.Component, welcher wiederum die Wurzel der Typhierarchie<br />
aller AWT und Swing-Widgets ist.<br />
Bei diesem Durchlauf wird, über die Standardmechanismen der dynamischen Modellinstanziierung des<br />
EMF, im Speicher die Ecore-Instanz aufgebaut. Zur Weiterbearbeitung dieses Modells ausserhalb der<br />
Container-Anwendung wird dieses Modell in einer Datei abgelegt. Als finales Ergebnis der Transformation<br />
entsteht daher eine XML-Datei welche die XMI-Serialisierung des Ecore-Modells darstellt.<br />
Die Modellserialisierung, d.h. die Umwandlung der Ecore-Instanz aus dem Speicher in die persistente<br />
XMI-Form, erfolgt über die durch die Code-Generatoren erzeugten Methoden zur Modellspeicherung.<br />
Diese Vorgehensweise war zwar zunächst praktisch, andererseits wegen der eingeschränkten Verfügbarkeit<br />
<strong>von</strong> Dokumentationen zum verwendeten XMI-„Dialekt“ zum Implementierungszeitpunkt auch kaum<br />
anders möglich. Als besonders hinderlich für eine eigene Implementierung erwies sich, dass keine genauen<br />
Angaben 2 zur Kreuzreferenzierung <strong>von</strong> Modellobjekten aufzufinden waren. Der gravierende Nachteil bei<br />
der Verwendung des EMF eigenen Serialisierungsmechanismus ist, dass es hierzu unbedingt notwendig<br />
ist vorher mit den EMF-Codegeneratoren aus dem Swing-Metamodell den Modell-Quellcode generiert zu<br />
haben.<br />
Dieser Zwang stellt sich insbesondere nach Änderungen am Metamodell als hinderlich und zeitintensiv<br />
heraus, dies begründet sich folgendermaßen: Das Swing-Metamodell ist auch nach der Reduktion noch ein<br />
großes Modell. Dementsprechend entstehen bei der Code-<strong>Generierung</strong> viele Dateien. Ändert man nun das<br />
Modell und startet die <strong>Generierung</strong> erneut, wird logischerweise jede dieser Dateien erneut generiert. Die<br />
bisher vorliegenden Dateien werden jedoch nicht einfach überschrieben, sondern miteinander verschmolzen.<br />
Das ist nötig damit manuelle oder sonstige externe Änderungen am „Quellcode“ nicht verloren gehen.<br />
Dieser Verschmelzungsprozess ist zeitaufwändig und noch nicht perfekt, oftmals sind manuelle Nacharbeiten<br />
notwendig. Als besonders problematisch, im Sinne <strong>von</strong> fehlerproduzierend, hat sich das Entfernen<br />
<strong>von</strong> Typen und teilweise auch Attributen aus dem Modell herausgestellt. Zusätzlicher Aufwand ist nach<br />
jeder Modelländerung zu betreiben, um nach Abschluss der Code-Erzeugung das Ergebnis wiederum neu<br />
zu packagen und es dem EMF-Generator zugänglich zu machen.<br />
Erweiterung des Swing-Metamodells<br />
Natürlich ergaben sich während des Arbeitens mit dem Swing-Modell diverse praktische Hindernisse. Zu<br />
nennen sind hier die Widrigkeiten mit dem durch EMF generierten Editor. Dieser erlaubt es zwar, den<br />
Baum der UI-Widgets aufzubauen, bot jedoch zunächst keine Unterstützung um diejenigen Eigenschaften<br />
welche in eigenen Typen definiert werden anzulegen und zu bearbeiten.<br />
Ein konkretes Beispiel: Die maximale Größe der Swing-Widgets lässt sich über das Attribut maxSize:<br />
Dimension festlegen. Der Typ Dimension entstammt dabei den AWT-Packages, und definiert lediglich die<br />
beiden ganzzahligen Attribute height und width, deren Werte begrenzen also Breite und Höhe der jeweiligen<br />
Swing-Komponente. Die Eigenschaft maxSize:Dimension wurde, gemäß der Festlegungen aus Unterabschnitt<br />
4.1.2, als Assoziation im Typ java.awt.Component angelegt. Der mit den Standardheuristiken erzeugte<br />
EMF-Editor ist in der Folge nicht in der Lage diese Eigenschaft anzulegen oder wenigstens zu bearbeiten.<br />
Das liegt daran, dass die Instanzen des Dimension-Typs nicht als eigene Knoten in der Baumhierarchie<br />
auftreten. Nur diejenigen Attribute des Metamodells die Containment-Beziehungen, d.h. Aggregationen,<br />
definieren werden standardmäßig im Editor als mögliche Kanten für den Objektbaum angelegt. Anders<br />
formuliert, nur Objekte die über Aggregationsbeziehungen mit dem Wurzelobjekt verbunden sind, werden<br />
als eigene Knoten im Editor dargestellt.<br />
2 im Standard ist die Rede <strong>von</strong> „XPath-like“ Referenzen
104 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Der Code-<strong>Generierung</strong>sprozess wird im EMF über ein eigenes Modell gesteuert, das sogenannte Genmodel.<br />
Änderungen des <strong>Generierung</strong>sverhalten sollten zunächst über dieses Steuermodell veranlasst werden. Hier<br />
wäre es unter anderem möglich, auch für normale Assoziationen das Anlegen <strong>von</strong> Knoten im erzeugten<br />
Editor zu veranlassen. Dies müsste dann für jedes Attribut, das änderbar sein soll, durchgeführt werden.<br />
Alternativ besteht die Möglichkeit, an entsprechender Stelle der Vererbungshierarchie ein neues Attribut<br />
einzuführen, welches seinerseits eine allgemeine Aggregation vom Typ EObject bereitstellt. Es wurde entschieden<br />
nach dieser Variante zu verfahren. Der Typ PropertyRegistry, bestehend aus einer 0..∗-Aggregation<br />
properties:EObject wurde dem Package javax.swing hinzugefügt. Dieser wird als Attribut propertiesRegistry<br />
der Klasse java.awt.Component im Swing-Metamodell integriert. Da alle UI-Widgets Unterklassen der<br />
Component-Klasse sind, steht somit für jedes Widget ein eigener Eigenschaftencontainer zur Verfügung.<br />
Der besondere Vorteil dieses Ansatzes ist, dass damit auch die Möglichkeit, besteht Instanzen <strong>von</strong> Eigenschaftenklassen<br />
anzulegen die nicht in einem UI-Widget referenziert werden. Somit können beispielsweise<br />
Designs vordefiniert abgelegt werden und bei deren Verwendung sind nur noch die entsprechenden Referenzen<br />
zu setzen. Durch die separate PropertyRegistry werden dem Modell keine neuen Ausdrucksmöglichkeiten<br />
oder ähnliches hinzugefügt, es handelt sich ausschließlich um eine praktikable Arbeitserleichterung.<br />
Die Beschreibung weiterer Details des technischen Ablaufs sind im Anhang im Abschnitt C.4 dargestellt.<br />
Dessen letztliches Ergebnis zeigt Abbildung 4.3. Hierin wird eine beispielhafte Java-Applikation<br />
sowie deren resultierendes Ecore-Modell dargestellt. Es handelt sich um einen einfachen, vollfunktionsfähigen<br />
Taschenrechner welcher als Demonstrationsapplikation implementiert wurde. Dieser wurde gemäß<br />
der obigen Beschreibung über den Wrapper gestartet.<br />
4.2.2 Modellinstanzen für XUL<br />
Die Technik des Einhängens in den Swing-Objektgraphen ist nicht auf die Verwendung des Swing-Metamodells<br />
beschränkt. Zur Erzeugung anderer Modellinstanzen ist es lediglich notwendig den Transformationsalgorithmus<br />
auszutauschen. Ein weiterer Transformator wurde für das XUL-Metamodell implementiert.<br />
Die vorbereitenden Arbeiten zu diesem Einsatz, insbesondere die Injektion in die Legacy-Anwendung, erfolgen<br />
analog dem Vorgehen beim Swing-Generator. Genau genommen ist es möglich beide Generatoren<br />
gleichzeitig im Container aktiv zu haben. Die Abbildung 4.4 stellt die um die XUL-<strong>Generierung</strong> erweiterte<br />
Infrastruktur aus Abbildung 4.2 dar.<br />
Abbildung 4.3: Taschenrechner-Anwendung und geparste Modellinstanz im Standardeditor
4.2. REVERSE ENGINEERING DES OBERFLÄCHENMODELLS 105<br />
Container<br />
Legacy-<br />
Anwendung<br />
JFrame<br />
JFrame<br />
XUL-<br />
Generator<br />
EMF-<br />
Generator<br />
XUL<br />
<br />
XUL<br />
<br />
Abbildung 4.4: Container-Infrastruktur mit Swing-Ecore und XUL-Generator<br />
4.2.2.1 Der XUL-Generator<br />
Swing-<br />
Ecore-<br />
Instanzen<br />
Der prinzipielle Ablauf der XUL-Erzeugung unterscheidet sich nicht <strong>von</strong> der zuvor beschriebenen Swing-<br />
Transformation. Es handelt sich wiederum um einen preorder-Graphendurchlauf. Ebenfalls wird für jeden<br />
Knoten das Äquivalent aus dem XUL-Metamodell ermittelt, instanziiert und im Ergebnisbaum angelegt.<br />
Selbstverständlich waren auch für die XUL-Erzeugung eine Reihe praktischer Probleme zu überwinden.<br />
Zunächst zu den Eigenschaften. Wie bereits in Punkt 2.1.4.1 ausgeführt, erfolgt die Festlegung der grafischen<br />
Eigenschaften der Oberflächenelemente für XUL mittels CSS. Es gibt also im Metamodell keine<br />
Attribute zur Festlegung <strong>von</strong> Farben oder der zu verwendenden Schriftart. Nur das Attribut style existiert,<br />
in welchem die Definition dieser Eigenschaften in der CSS-Syntax erfolgt.<br />
Es war also ein CSS-Exporter zu schreiben, dessen Zweck darin besteht, die Eigenschaften eines Swing-<br />
Objektes in eine CSS-Beschreibung zu übersetzen. Die vorliegende Implementierung des Exporters ist<br />
nicht vollständig, sondern eher als minimal zu beschreiben. Es wurden lediglich CSS-Schlüssel für die<br />
oben bereits erwähnten Farben und Schriftarten umgesetzt. Die Begründung für diese Einschränkung ist,<br />
dass es im Rahmen dieser Arbeit nicht um eine vollständige Umsetzung des CSS-Standards geht, sondern<br />
darum, das Konzept zu evaluieren.<br />
Eine gewisse Vereinfachung gegenüber dem Swing-Modell entstand dadurch, dass im XUL-Metamodell<br />
keine Referenztypen für die Eigenschaften verwendet werden. Ein eigener Objekt-Cache für die Transformation<br />
war demzufolge nicht <strong>von</strong> Nöten.<br />
Die Hauptschwierigkeit bei der XUL-<strong>Generierung</strong> lag jedoch nicht in der Eigenschaftenübertragung oder<br />
dem Knotenmapping. Als aufwändig stellte sich die Übertragung des Layouts der Oberfläche heraus.
106 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Layouterzeugung<br />
XUL-Oberflächenbeschreibungen erfolgen normalerweise ohne Angabe fixer Größen und Koordinaten. Im<br />
Metamodell sind zwar Attribute für diese Merkmale vorgesehen, im Hinblick auf den Verwendungszweck<br />
einer XUL-Definition sollten diese jedoch nicht verwendet werden. Stattdessen wird dem jeweiligen Renderer<br />
die Platzierung und die Festlegung der effektiven Größe der UI-Widgets überlassen. Dem Renderer<br />
können jedoch über diverse Sprachkonstrukte Richtlinien für das Layout vorgegeben werden.<br />
Zu diesen Sprachkonstrukten zählen Containertypen wie beispielsweise vbox und hbox. XUL-Widgets,<br />
die direkte Kindknoten unterhalb einer vbox sind, werden in Knotenreihenfolge vertikal angeordnet. Für<br />
eine hbox gilt sinngemäß das Gleiche, es handelt sich jedoch um eine waagerechte Anordnung. Container<br />
können verschachtelt werden, eine vbox kann also etwa eine hbox enthalten. Durch die Wahl einer geeignete<br />
Verschachtelung kann die Grobstruktur der Oberfläche festgelegt werden.<br />
Die Anordnung und die Größenverteilung innerhalb eines Containers kann ebenfalls relativ fein definiert<br />
werden. Durch Zuweisung einer Gewichtung an die Kindelemente wird der verfügbare Oberflächen-Raum<br />
anteilig verteilt. Ein Beispiel: Eine hbox habe drei Kindelemente E0, E1 und E2. Die Gewichtung g(e) sein<br />
folgendermaßen belegt: g(E0)=0.2, g(E1)=0.3 und g(E2)=0.05. Der Renderer ermittelt nun, dass der<br />
Container, in horizontale Richtung, 200 Pixel breit sein wird.<br />
Damit ergibt sich die Breite eines Elementes folgendermaßen: breite(e)=200px∗<br />
∑ 2 Das Element<br />
i=0 g(Ei)<br />
E2 wird in diesem Fall mit einer Breite <strong>von</strong> 200∗ = 18,18≈18 Pixeln dargestellt.<br />
0.05<br />
0.2+0.3+0.05<br />
Durch Einfügen <strong>von</strong> gewichteten Zwischenräumen kann die Positionierung, bei fixer Gesamtgröße, nahezu<br />
pixelgenau erfolgen. Die Genauigkeit ist dabei einerseits abhängig <strong>von</strong> eventuellen Rundungsfehlern, aber<br />
hauptsächlich da<strong>von</strong>, wie der jeweilige Renderer den den Untercontainern zur Verfügung bereitgestellten<br />
Platz berechnet. Beispielsweise kommt es vor, dass einige Pixel für einen imaginären Rand reserviert werden.<br />
Eine tatsächlich pixelgenaue Positionierung über die Container und Gewichtung ist daher immer nur<br />
für einen bestimmten Renderer möglich; mit anderen Worten, es ist nicht sinnvoll das anzustreben.<br />
Die Umkehrung des Prinzips der Anteilsverteilung liefert einen Algorithmus um Koordinatenangaben in<br />
Gewichte umzurechnen. Es müssen „nur“ die Container geeignet gefunden werden und <strong>von</strong> deren Inhalt<br />
die Position sowie die Größe in eine Gewichtung umgerechnet werden.<br />
Die Identifikation der Container kann automatisch erfolgen. Die Grundidee ist, die dargestellten UI-Widgets<br />
nach Überlappung in genau einer Ebene, waagerecht oder senkrecht, zu gruppieren. Jede so entstehende<br />
Gruppe wird zu einem Container. Anschliessend werden die Container, die mehrere Widgets enthalten,<br />
rekursiv weiter in der jeweils alternierenden Dimension zerlegt. Die Rekursion endet, sobald sich jedes<br />
UI-Widget einzeln innerhalb eines eigenen Containers befindet.<br />
Für die Gewichte biete sich eine triviale Herangehensweise an. Es besteht keinerlei Zwang das Gewicht als<br />
Prozentsatz oder sonstige rationale Zahl anzugeben. Die Gewichtsverhältnisse, die sich hier für die Oberflächen<br />
ergeben, können in jedem Fall durch natürliche Zahlen definiert werden. Die Ausgangsgröße für<br />
die Verteilung der Gewichte ist die Größe des untersuchten JFrame, also ein Wert (hoehe,breite) wobei<br />
ebenfalls hoehe,breite ∈ N. Die Idee welche sich aufdrängt ist daher, für den Gewichtswert jeweils die<br />
Ausdehnung in Pixeln zu setzen. Selbstverständlich als dimensionslose Zahl. Dadurch entfällt die Notwendigkeit<br />
zur Berechnung <strong>von</strong> Verhältniszahlen komplett.<br />
Der Algorithmus 2 beschreibt die Durchführung des Layoutings unter Benutzung <strong>von</strong> Pseudocode.<br />
Die Abbildung 4.5 stellt die Anwendung dieses Algorithmus für ein kleineres Beispiel dar. Erstellt und<br />
dargestellt wurde die Beispieloberfläche mit dem XUL-Editor.<br />
Alle vier Teilabbildungen in Abbildung 4.5 zeigen das gleiche Nutzerinterface, jedoch mit verschiedenen<br />
g(e)
4.2. REVERSE ENGINEERING DES OBERFLÄCHENMODELLS 107<br />
Algorithmus 2 Layout-Bildung mit relativen Koordinatenangaben<br />
1. Setze Containerausdehnung = Gesamtframe, Vaterknoten = window, Durchlau f richtung = vertikal<br />
2. Bilde Cluster sich überlappender Elemente innerhalb Containerausdehnung in Durchlaufrichtung<br />
3. Für jeden Cluster, in Abhängigkeit <strong>von</strong> der Durchlau f richtung<br />
vertikal: für Cluster einen hbox-Knoten anlegen, als dessen Gewicht wird die überdeckte Höhe in<br />
Pixeln gesetzt<br />
horizontal: für Cluster einen vbox-Knoten anlegen, als dessen Gewicht wird die überdeckte<br />
Breite in Pixeln gesetzt Pixeln gesetzt<br />
4. Erzeugten Cluster-Knoten als Kind unterhalb des Vaterknoten anlegen<br />
5. Cluster-Zwischenräume als spacer-Knoten, wiederum mit der Ausdehnungsgewichtung in Pixeln,<br />
zwischen den Containern unterhalb des Vaterknoten anlegen<br />
6. Für jeden Cluster-Knoten:<br />
(a) Falls mehr als 1 Widget im Cluster, oder das Einzel-Widget nimmt nicht den gesamten<br />
Clusterbereich ein: Alterniere Durchlau f richtung, Vaterknoten=Cluster-Knoten,<br />
Containerausdehnung = Koordinatenbereich des Clusters; weiter bei 2.<br />
(b) Sonst, Widgetübertragung <strong>von</strong> Swing→XUL<br />
7. Ausgabe der Ergebnisstruktur<br />
a) b)<br />
c) d)<br />
Abbildung 4.5: Visualisierung des Layoutalgorithmus für XUL
108 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
Overlays. In Abbildung 4.5a) ist als Ausgangssituation eine schematische Nutzeroberfläche mit fünf Widgets<br />
dargestellt. Die Schaltflächen B1 bis B5 seien in diesem Fall die Repräsentanten beliebiger Widgets.<br />
In Abbildung 4.5b)-d) wird Schritt für Schritt die Zerlegung in Containern gezeigt. Schraffiert dargestellt<br />
wurden erkannte leere Zwischenräume. Neu erkannte Cluster und damit die anzulegenden Container wurden<br />
dick-gestrichelt dargestellt.<br />
Die Ausgangszerlegung des Gesamtframes findet sich in Abbildung 4.5b). Durch vertikale Aufspaltung<br />
wurden drei Cluster erkannt.<br />
1. die Vertikalausdehnungen der Widgets B5 und B1 überlappen sich<br />
2. das Höhenintervall des Widgets B3 liegt innerhalb dessen <strong>von</strong> B4<br />
3. die Y-Koordinaten <strong>von</strong> Widget B2 überschneiden sich mit keinem anderen Widget, es handelt sich<br />
um einen 1-elementigen Cluster<br />
Zudem wurden oberhalb, unterhalb sowie zwischen den Clustern insgesamt vier Zwischenräume erkannt.<br />
Diese werden einfach als spacer angelegt, der dadurch umschlossene Raum auf der Oberfläche wird nicht<br />
weiter betrachtet. Das Widget B2 füllt seinen Container nicht vollständig aus, daher wird auch dieser im<br />
nächsten Schritt rekursiv weiter zerlegt. Die Aufspaltungsrichtung war vertikal, also wird für jeden Cluster<br />
eine hbox angelegt.<br />
Die Zerlegung dieser drei hbox-Gruppen wird in Abbildung 4.5c) dargestellt.<br />
• ∀Bn ist bereits nach dieser Aufspaltung die Breite festgelegt<br />
• für B2 und B4 sind deren Position und Grösse so genau wie mit diesem Ansatz möglich definiert<br />
⇒ Abbruch der Layout-Rekursion und Transformation des Widgets in das korrespondierende XUL-<br />
Element, hier button<br />
• eine weitere Clustering-Rekursion muss für die Container um B1, B3 und B5 durchgeführt werden<br />
Die Abbildung 4.5d) zeigt diesen letzten Rekursionsschritt. Da in jeder Rekursionsstufe die Aufspaltungsrichtung<br />
alterniert, wird in diesen Containern wiederum vertikal gruppiert. Über die dabei ermittelten<br />
Zwischenräume sind die Lage und Größe aller Widgets relativ beschrieben. Der Quellcode-Ausschnitt<br />
in Listing B.5 zeigt das vorläufige Endergebnis der Layoutbemühungen.<br />
Die Zerlegung wurde in diesem in Fall in vertikaler Richtung begonnen. Strukturell das selbe Ergebnis<br />
würde man erhalten, wenn die Clusterung in horizontaler Richtung begonnen hätte. In der Beispieloberfläche<br />
ist initial keine horizontale Gruppierung möglich, weil sich die Koordinatenbereiche in X-Richtung<br />
aller Widgets überlappen. Es ergäbe sich daher eine umschliessende hbox, innerhalb welcher dann mit der<br />
vertikalen Aufsplittung begonnen wird. Generell gilt, dass, solange die Widgets nicht übereinander liegen,<br />
immer entweder eine vertikale oder eine horizontale Clusterung möglich ist. Die Entscheidung ob in waagerechter<br />
oder senkrechter Richtung mit dem Algorithmus begonnen wird ist unerheblich für das erzeugte<br />
Endergebnis.<br />
Zu den Grenzen dieses Algorithmus: Es ist in dieser einfachen Version nicht möglich Nutzeroberflächen<br />
nach XUL zu überführen, in denen Widgets verwendet werden, die sich überlagern. Diese Beschränkung<br />
ergibt sich aus der Art der Clusterung. Elemente welche übereinander liegen können weder in horizontaler<br />
noch in vertikaler Richtung auseinander gruppiert werden. Daher würde bei Anwendung des Verfahrens<br />
eine Endlosrekursion auftreten und kein Ergebnis erzeugt werden. In der Implementierung für den
4.2. REVERSE ENGINEERING DES OBERFLÄCHENMODELLS 109<br />
Swing→XUL Konverter werden derartige Fälle zwar erkannt und abgefangen, eine Lösung wird jedoch<br />
nicht erzeugt.<br />
Die Sprachmittel <strong>von</strong> XUL erlauben übereinander liegende Widgets. Man kann sich dafür unter anderem<br />
des integrierten Layer-Konzeptes bedienen, Widget-Stacks benutzen, oder aber die Positionierungsangaben<br />
über CSS-Angaben vornehmen. Gleichwohl sind gestapelte Widgets eher ein Sonderfall bei Nutzeroberflächen.<br />
Daher erscheint das Weglassen einer geeigneten Layouter-Implementierung für diese Situationen<br />
keine gravierende Einschränkung zu sein.<br />
Die Abbildung 4.6 zeigt das Ergebnis der Transformation der Oberfläche der Taschenrechner-Beispielanwendung<br />
nach XUL. Auf der linken Seite findet sich ein Screenshot des Ecore-Standardeditors, rechts<br />
oben das Rendering-Ergebnis <strong>von</strong> SeaMonkey und in der unteren rechten Hälfte die gleiche XUL-Datei<br />
dargestellt im XUL-Editor. Im direkten Vergleich der beiden Renderer ist zu sehen, dass das obere Textfeld<br />
im SeaMonkey-Browser breiter dargestellt wird als im XUL-Editor und auch in der ursprünglichen Java-<br />
Anwendung. Das liegt daran, dass die Gecko-Engine das Label welches sich rechts vom Textfeld befindet<br />
nur dann ins Layout einrechnet wenn es eine nicht-leere Zeichenkette darstellt. Da im Moment des Snapshots<br />
in diesem Label nur ein Leerzeichen als Wert vorlag, wird es nicht dargestellt und sogar auch dessen<br />
Gewichtung ignoriert. Damit erhöht sich der relative Anteil an der Breite für das Gewicht des Textfeldes,<br />
und es wird etwas breiter. Unabhängig da<strong>von</strong>, welcher der Renderer in diesem Fall falsch rechnet, zeigt es<br />
einmal mehr die Abhängigkeit der konkreten Darstellung XULs vom jeweiligen Interpreter.<br />
Abbildung 4.6: Drei Renderer des XUL-Snapshots der Taschenrechneranwendung
110 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
4.2.3 Ableitung des abstrakten Oberflächenmodells<br />
Der Prozess des Reverse Engineering ist auf der Ebene des konkreten Oberflächenmodells noch nicht<br />
abgeschlossen. Wie bereits in Abschnitt 2.1 dargelegt, ist das CUI Bestandteil eines, idealerweise bidirektionalen,<br />
Gesamtprozesses. In diesem Prozess ist die dem CUI vorgelagerte Abstraktionsebene die des<br />
Abstrakte Oberflächenmodells (AUI).<br />
Typischerweise entsteht die CUI-Instanz als Ergebnis einer Model-To-Model Transformation aus einer<br />
AUI-Instanz. Aber auch die Umkehrung dieser Transformation ist denkbar und wird angewendet. So ist<br />
beispielsweise in Paternòs MARIA-XML [88] diese Transformationsrichtung Bestandteil der „Migratory<br />
Interface“, d.h. der Übergabe <strong>von</strong> <strong>Benutzungsoberflächen</strong> zwischen Geräten.<br />
Bei dem MARIA-XML Use Case handelt es sich nicht um Reverse Engineering, das Modell der abstrakten<br />
Oberfläche ist vordefiniert und wird nicht aus der vorhanden Instanz des CUI generiert. Die prinzipielle<br />
Möglichkeit der <strong>Generierung</strong> einer AUI-Instanz aus einer CUI-Instanz untersuchte Rathsack [99]. Die<br />
<strong>von</strong> ihm erarbeitete Transformation generierte aus XUL-Oberflächenbeschreibungen, ohne Verwendung<br />
des XUL-Metamodell aus Punkt 2.1.4.2, Instanzen des X-AIM AUI-Metamodells. Zwar erfolgte seine<br />
damalige Implementierung ohne Einsatz <strong>von</strong> MDSE-Techniken, es handelt sich um ein manuell erstelltes<br />
Java-Programm, die Machbarkeit konnte dennoch gezeigt werden. Die Erstellung ähnlich mächtiger<br />
Model-To-Model Transformationen ist zumindest für den Rostocker MD-UID Ansatz bisher noch nicht<br />
erfolgt.<br />
Überdenkt man die Mechanismus der Ableitung der AUI aus einem CUI-Modell, so gelangt man schnell<br />
in das Themengebiet der Pattern-Erkennung, bzw. Pattern-Matchings. Die Identifikation der in der untersuchten<br />
Oberfläche eingesetzten Patterns bietet eine nützliche Zusatzinformation, insbesondere auch im<br />
Hinblick auf weiteren Bearbeitungsschritte. Möglicherweise finden sich Wege des maschinellen Abgleichs<br />
mit Patternkatalogen wie dem in Abschnitt 3.5 erstellten. Dabei handelt es sich jedoch um ein nicht triviales<br />
Problem, welches in weiteren Arbeiten, z.B. unter Einsatz <strong>von</strong> QVT Relations, weiter beleuchtet<br />
werden sollte.<br />
4.3 Forward Engineering<br />
Reengineering wird nicht als Selbstzweck betrieben. Das Ziel des hier vorgestellten Reengineering ist es,<br />
bereits existierende Software mit den Mitteln der modellgetriebenen Softwareentwicklung weiter zu Pflegen<br />
und zu Warten. Dieses Ziel ist weit gesteckt und seine Erreichung steht in der nächsten Zeit nicht<br />
unbedingt zu erwarten. Dennoch lohnt es sich, auf der Basis des heute Bekannten und Möglichen, Überlegungen<br />
zum Forward Engineering, d.h. der Rückrichtung des Reverse Engineering anzustellen.<br />
Grundsätzlich unterscheidet sich das Forward Engineering eines durch Reverse Engineering gewonnenen<br />
Oberflächenmodells nicht <strong>von</strong> der Bearbeitung einer nativ modellgetrieben entwickelten Benutzungsoberfläche.<br />
Mit den bisherigen Mitteln ist es möglich, aus einer Instanz des Swing-Ecore Modells wiederum Java<br />
Swing-Quellcode zu erstellen. Je ausgefeilter die an dieser Stelle eingesetzte Model-To-Text Transformation<br />
ausgestaltet wird, desto genauer wird das Ergebnis der Quelle entsprechen. Gleichfalls existieren<br />
M2M-Transformationen, bidirektional, zwischen XUL und Java Swing CUI-Modellinstanzen. Für diese<br />
Algorithmen gilt gleichfalls, dass sie wohl nie vollends fertiggestellt werden können, aber bei genügendem<br />
Aufwand ein hoher Reifegrad errreicht werden kann.<br />
Eine Anwendungsmöglichkeit für die Überführung <strong>von</strong> Swing-Oberflächen in Instanzen des XUL-Meta-
4.4. HERAUSFORDERUNGEN UND GRENZEN DES VORGESTELLTEN REENGINEERING-ANSATZ111<br />
modells ist es, diese UIs grafisch mit dem XUL Editor XULE zu bearbeiten, sie anschließend wieder<br />
nach Java Swing zu transformieren und dabei wiederum die Anbindung an die bisherige Anwendungslogik<br />
herzustellen. Dabei entsteht im Idealfall eine funktional identische Software, die sich lediglich durch ihre<br />
Benutzungsoberfläche <strong>von</strong> der ursprünglichen Anwendung unterscheidet. Zwar ist ein solches Vorgehen<br />
bei der Reife der aktuellen Werkzeuge und Transformationen nur bedingt vorteilhaft, gleichwohl gelang<br />
der Nachweis der prinzipiellen Machbarkeit dieses in [149] vorgestellten Ansatzes.<br />
Die per Reverse Engineering gewonnenen Modellinstanzen weisen keine besonderen Charakteristika auf,<br />
die den Einsatz der bereits diskutierten Patternkomponenten beeinflussen. Für das Forward Engineering<br />
kann daher auf die im Patternkatalog definierten oder referenzierten Patternkomponenten zurückgegriffen<br />
werden. Somit können auf diesem Weg, im Idealfall, Legacy-UIs auf die Verwendung moderner HCI-<br />
Patterns umgestellt werden.<br />
4.4 Herausforderungen und Grenzen des vorgestellten Reengineering-<br />
Ansatz<br />
In diesem Kapitel wurden Methoden und Techniken vorgestellt die es ermöglichen können, die Vorteile<br />
der modellgetriebenen Softwareentwicklung auch für Software nutzbar zu machen die nicht mit diesem<br />
Paradigma entwickelt wurden. Dabei wurde der Aspekt der <strong>Benutzungsoberflächen</strong> in den Vordergrund<br />
gestellt und anhand dieses Problems gezeigt wie Modelle zur Laufzeit aus Legacy-Software gewonnen<br />
werden können.<br />
In den Erläuterungen zu diesem Prozedere wurden die Bedingungen dargestellt, welche zu dessen Anwendbarkeit<br />
notwendig sind. Treffen diese Voraussetzungen nicht zu, ist dies nicht gleichbedeutend damit,<br />
dass prinzipiell kein Reverse Engineering möglich wäre. Es sollten dann jedoch andere Verfahren gewählt<br />
bzw. entwickelt werden.<br />
Auch das präsentierte Vorgehen bietet noch eine Vielzahl Herausforderungen. Bisher wurden nur Betrachtungen<br />
zu den unteren CAMELEON-Ebenen angestellt, AUI und CUI. Allerdings sind im Rostock MD-<br />
UID Prozess ebenfalls noch die höheren Abstraktionsebenen Dialoggraph und Aufgabenmodell zu betrachten.<br />
Die in Punkt 4.2.1.2 vorgestellte Snapshot-Technik erstellt zunächst ein statisches Abbild des aktuellen Zustands<br />
des Objektgraphen der Benutzungsoberfläche. Dynamische Aspekte, wie etwa die Navigation durch<br />
die Anwendung und Anpassungen <strong>von</strong> Teilen der Oberfläche als Konsequenz <strong>von</strong> Aktionen, bleiben im<br />
Prinzip unberücksichtigt. Implizite Informationen dazu liegen jedoch durchaus vor, da der Zugriff auf den<br />
Objektbaum auch den Zugriff auf alle per Anwendungslogik definierten Aktionen einschließt. Eine semantische<br />
Auswertung des zugrundeliegenden Quellcodes könnte, zumindest für einige einfache Sonderfälle,<br />
die gesuchten Navigationsinformationen liefern. Der dazu notwendige Aufwand ist ohne gründliche Überlegungen<br />
kaum abschätzbar. Dennoch scheint für ein tatsächlich praktisch anzuwendendes Werkzeug die<br />
zumindest annähernd korrekte Ermittlung der sichtinternen Navigation und damit auch des Kontrollfluss<br />
nahezu unverzichtbar.<br />
Zu den mit dem jetzigen Stand der Werkzeuge schon denkbaren praktischen Einsatzzwecken zählt das automatische<br />
Testen <strong>von</strong> <strong>Benutzungsoberflächen</strong>. Momentane UI-Testverfahren automatisieren Tests durch<br />
Aufzeichnungen <strong>von</strong> Beispielabläufen. In einem Durchlauf werden die Interaktionsevents, wie Mausklicks<br />
an Stelle (x,y) oder Tastendrücke, aufgezeichnet. Bei der eigentlichen Testdurchführung wird der Musterablauf<br />
gestartet und Abweichungen gegenüber dem als richtig bekannten Ergebnis gemeldet. Diese Verfahren<br />
sind verhältnismäßig empfindlich gegenüber Layout- und Designänderungen der Benutzungsoberfläche. Es
112 KAPITEL 4. REENGINEERING INTERAKTIVER SYSTEME<br />
ist z.B. ein reales Problem, dass sich nach Änderung an der Corporate Identity einer Firma, auf Grund <strong>von</strong><br />
Schriftarten- und Logo-Änderungen, die Position <strong>von</strong> UI-Elementen ändert. Die Anwendung der oben skizzierten<br />
Testverfahren kann es daher durchaus notwendig werden, die Musterabläufe neu aufzuzeichnen.<br />
Das in diesem Kapitel vorgestellte Verfahren der Nutzung der UI-Objektstruktur, kann stattdessen den<br />
Testgegenstand über Objektidentitäten identifizieren und ist nicht auf pixelgenaue Positionsangaben angewiesen.<br />
Er ist daher sehr robust gegenüber Layoutveränderungen auf Grund <strong>von</strong> Grössen-, Schriftartenund<br />
sonstigen dekorativen Änderungen. Vielversprechende Möglichkeiten bieten sich auch bei der Definition<br />
der Testbedingungen, denn diese können auf der Basis des Metamodells z.B. mit OCL [84] sehr<br />
präzise formuliert werden.<br />
An seine Grenzen trifft der vorgestellte Ansatz bei verteilten Anwendungen, da mit dem Wrapper-Mechanismus<br />
immer nur der Teil der Software untersucht werden kann welcher auch lokal vorhanden ist.<br />
Ebenfalls scheint es kaum erfolgversprechend auf diese Weise UIs zu untersuchen die permanenten dynamischen<br />
Änderungen unterliegen. Beispielsweise grafisch anspruchsvolle Spiele oder andere in irgendeiner<br />
Weise gezeichnete Oberflächen.<br />
Neben der bereits erwähnten Dialogmodell-Problematik, stellt das Aufgabenmodell eine kaum zu überwindende<br />
Grenze dar. Die Konkretisierung und Formalisierung <strong>von</strong> Nutzerzielen ist ein inhärent manueller<br />
Prozess. Im Fall der Bottom-Up Ableitung, d.h. abstrahierend beginnend auf der CUI-Ebene, ist zur Zeit<br />
kaum denkbar, wie aus einem Screen- bzw. Snapshot einer Benutzungsoberfläche auf das aktuelle oder<br />
globale Nutzerziel geschlossen werden kann. Ein solches Vorgehen bedarf mit hoher Wahrscheinlichkeit<br />
einer Vielzahl manueller Eingriffe. Im Augenblick laufen Arbeiten [55], die die Möglichkeiten zur Ableitung<br />
<strong>von</strong> Aufgaben- oder Prozessmodellen aus Nutzeraktionen untersuchen. Vielleicht lassen sich diese<br />
Ergebnisse in Zukunft einmal für das hier dargestellte Reverse Engineering anwenden.
Kapitel 5<br />
Zusammenfassung<br />
5.1 Überblick<br />
Der Inhalt dieser Dissertationsschrift ist eine Untersuchung zu Möglichkeiten der Erstellung grafischer<br />
<strong>Benutzungsoberflächen</strong> mit Methoden der modellgetriebenen Softwareentwicklung. Als Ergebnis wurde<br />
herausgearbeitet, dass diese Technik für WIMP-Oberflächen anwendbar ist und in diesem Kontext nutzbringende<br />
Vorteile bieten kann.<br />
Diese Vorteile ergeben sich insbesondere aus der modellinhärenten Abstraktion. Durch spezialisierte und<br />
strukturierte Abstraktionsebenen gelingt die Aufgliederung, auch komplexer, <strong>Benutzungsoberflächen</strong> in<br />
handhabbare Teilmodelle. Pflege, Wartung und Weiterentwicklung einer Anwendung erfolgen zentral in<br />
Modellinstanzen, langwierige Such- und Bearbeitungsprozesse direkt im Quellcode werden im Prinzip<br />
obsolet, bleiben aber dennoch möglich.<br />
Weil die Oberflächenbeschreibungen in der MD-UID jeweils einer bekannten formalisierten Beschreibung<br />
entsprechen können standardisierte Automatismen zu deren Bearbeitung entwickelt werden. In der Arbeit<br />
wurde weiter untersucht inwieweit HCI-Patterns in diesem Kontext als Modelltransformationsautomatismen<br />
umgesetzt werden könnten. Unter anderem erwies sich dabei eine Klassifikation und modellbasierte<br />
Beschreibung <strong>von</strong> HCI-Patterns als notwendig. Ein Vorschlag hierfür wurde entwickelt und damit das Konzept<br />
eines Katalogs <strong>von</strong> Patterntransformationen begonnen. Dessen initialer Inhalt wurde, soweit möglich,<br />
modellgetrieben aus öffentlich verfügbaren HCI-Patternsammlungen generiert.<br />
Ein weiteres Schwerpunkt der Arbeit ist der Untersuchung <strong>von</strong> Techniken zum modellbasierten Reengineering<br />
gewidmet. Das Ziel war es, einen Weg zu finden, Modelle bzw. Modellinstanzen aus Software<br />
zu generieren oder abzuleiten welche ursprünglich nicht modellbasiert entwickelt wurde. Die Motivation<br />
zu den ausgearbeiteten Ansätzen ergab sich aus zwei praktischen Problemen. Erstens war es nicht anders<br />
möglich an ein vollständiges Klassenmodell des Java-Swing Frameworks zu gelangen. Zweitens ist die<br />
Deklaration einer komplexen Benutzungsoberfläche, auch bei Einsatz der MD-UID, eine durchaus zeitaufwändige<br />
Angelegenheit. Ein Verfahren das es ermöglicht, bereits ausprogrammierte Oberflächen als Quelle<br />
für Modellinstanzen zu nutzen, erhöht daher die Produktivität in bestimmten Einsatzfällen ganz erheblich.<br />
Eng verbunden ist die Arbeit mit dem an der Universität Rostock verfolgten modellbasierten Gesamtprozess<br />
zur Softwareentwicklung. Aus diesem Grund wurde dieser Prozess, sowie eine Reihe weiterer in der<br />
Forschung diskutierter Ansätze, vorgestellt.<br />
Wie bei den allermeisten Forschungsarbeiten, fand sich bei der Bearbeitung der jeweiligen Problemstel-<br />
113
114 KAPITEL 5. ZUSAMMENFASSUNG<br />
lungen eine Vielzahl <strong>von</strong> Anknüpfungspunkten für weiterführende Arbeiten. Einige wurde bereits in den<br />
vorstehenden Kapiteln skizziert, eine Zusammenfassung dieser Ideen und zusätzliche Gedanken werden in<br />
Abschnitt 5.2 diskutiert.<br />
Im Einleitungskapitel wurden acht Fragen aufgestellt, die eine Einordnung <strong>von</strong> Motivation und Kontext<br />
dieser Arbeit bieten. Die vorstehenden Kapitel bearbeiteten diese Forschungsfragen im Detail. Hier soll<br />
nun deren summarische Zusammenfassung und Beantwortung erfolgen.<br />
1. Lassen sich umfassende Metamodelle moderner grafischer <strong>Benutzungsoberflächen</strong> erstellen?<br />
Die Antwort auf diese Frage fällt positiv aus, beispielsweise wurde für die Oberflächen-Deklarationssprache<br />
XUL ein Metamodell aufgestellt. XUL zählt durchaus zu den modernen Beschreibungssprachen für<br />
grafischen <strong>Benutzungsoberflächen</strong>. Für die Erzeugung dieses Metamodells konnten Techniken der modellgetriebenen<br />
Softwareentwicklung genutzt werden, es wurde über manuell nachbearbeitete Modelltransformationen<br />
erzeugt.<br />
Auch das Java GUI-Framework Swing ist ein übliches modernes UI-System. Durch Kombination mehrerer<br />
Verfahren konnte auch für Swing ein Metamodell aufgestellt werden.<br />
2. Wie kann die inhärente Komplexität solcher Metamodelle handhabbar gemacht werden?<br />
Bei dieser Frage ist zu nächst zu validieren, ob die erhaltenen Metamodelle tatsächlich komplex sind.<br />
Tatsache ist das sie tendenziell eine hohe Anzahl an Metaklassen, mehrere Dutzend bis einige Hundert,<br />
aufweisen. Genauere Zahlen finden sich bei den Modellerläuterungen. Weiterhin existiert in den Modellen<br />
eine Vielzahl <strong>von</strong> Attributen, Assoziationen und Vererbungsbeziehungen.<br />
Da an dieser Stelle kein Maß für Modellkomplexität herangezogen oder gar erarbeitet werden soll bleibt<br />
nur der Rückzug auf einen praktischen Standpunkt. Zum gegenwärtigen Zeitpunkt bringt die Größe des<br />
unreduzierten Swing-Modells die Werkzeuge des Eclipse Modeling Projects an den Rand der Praktikabilität.<br />
Bei der Suche nach Wegen die Dimensionen des Metamodells zu verkleinern fand sich im Ansatz des<br />
Model-Prunings eine gangbare Lösung. Rein quantitativ betrachtet gelang es, mit diesem Verfahren das<br />
Swing-Modell auf etwa ein zwanzigstel seiner Größe zu reduzieren ohne die Ausdrucksmächtigkeit entscheidend<br />
zu verringern.<br />
Eine alternative Vorgehensweise zur Komplexitätsreduktion ist die Einführung zusätzlicher Abstraktionsebenen.<br />
Wie bei der Diskussion der laufenden und historischen Forschung herausgearbeitet wurde, ist dies<br />
eine bei der MD-UID etablierte und häufig eingesetzte Technik. Auch in dieser Arbeit wurde da<strong>von</strong> Gebrauch<br />
gemacht.<br />
3. Inwieweit kann nützliche Werkzeugunterstüzung gestellt werden?<br />
Die Nützlichkeit eines Werkzeuges für die MD-UID ist kaum objektiv bewertbar. Zunächst ist die Frage zu<br />
stellen, ob überhaupt Tool-Support nötig und in zweiter Stufe, auch möglich ist. Prinzipiell kann die Bearbeitung<br />
der meisten Modellinstanzen mit jedem beliebigen Texteditor erfolgen. Die zweite Forschungsfrage<br />
impliziert jedoch das die Modelle im Allgemeinen sehr umfangreich sind. Übliche generische Texteditoren<br />
werden daher eher nicht das Mittel der Wahl für die alltägliche Modellierung sein. Nützlich scheinen eher<br />
integrierter Entwicklungsumgebungen, wie sie auch bei der klassischen Softwareentwicklung zum Einsatz<br />
kommen. Aktuelle Untersuchungen darüber, was geeignete Werkzeugunterstützung leisten können sollen,<br />
führt beispielsweise Opoka [20] mit der Zielsetzung der Gestaltung einer Entwicklungsumgebung für OCL.
5.1. ÜBERBLICK 115<br />
Für den Rostocker modellgetriebenen Prozess wurde eine Vielzahl, zumeist grafischer, Entwicklungswerkzeugen<br />
geschaffen. Diese unterstützen Modellierer und Designer bei der Bearbeitung der wichtigsten<br />
Teilmodelle. In dieser Arbeit wurde mit dem grafischen Editor XULE in Punkt 2.1.4.3 ein Werkzeug zur<br />
manuellen Bearbeitung konkreter <strong>Benutzungsoberflächen</strong> erstellt. XULE ermöglicht die Bearbeitung aller<br />
Modellparameter, liefert soweit möglich sofortiges visuelles Feedback und leitet und unterstützt den Benutzer<br />
indem nur gültige Modellierungen zugelassen werden. Für andere Teilmodelle und Transformationen<br />
des Gesamtprozesses ist die Werkzeugunterstützung weniger weit entwickelt.<br />
4. Welche Möglichkeiten zur Integration <strong>von</strong> HCI-Patterns sind denkbar?<br />
Es lassen sich alle diejenigen HCI-Patterns in den MD-UID Prozess integrieren, deren Pattern-Lösung als<br />
Modelltransformation oder Modellinstanz ausgedrückt werden können. Dies trifft aus mehreren Gründen<br />
auf viele HCI-Patterns nicht zu. In der Arbeit wurde ein existierendes Metamodell für Patternkataloge<br />
erweitert, sowie ein ergänzendes Metamodell ausgearbeitet, das zur formalisierten Speicherung möglicher<br />
Patternlösungen geeignet ist. Die Metamodelle für diesen Katalog wurde im Hinblick auf Integrierbarkeit in<br />
den vorgestellten Prozess konstruiert. Ein eigens erstellter Patternkatalog, als Instanz dieser Metamodelle,<br />
wurde aus öffentlich verfügbaren Quellen befüllt.<br />
5. Welche Patterns sind soweit formalisierbar, dass sie direkt in einem Gesamtprozess anwendbar<br />
sind?<br />
Wie vermutet lassen sich nur wenige HCI-Patterns soweit formalisieren das ihre Lösung direkt auf Modellinstanzen<br />
anwendbar ist. Eine zahlenmäßige Aufstellung einer manuellen Klassifikation bietet Unterabschnitt<br />
3.5.4.<br />
6. Welche Möglichkeiten bestehen zur Überführung existierender Softwaresysteme in den modellgetriebenen<br />
Ansatz?<br />
Die in dieser Arbeit untersuchte Lösungsmöglichkeit ist das Reverse Engineering – andere Verfahren sind<br />
selbstverständlich denkbar. In Kapitel 4 konnte gezeigt werden das mehrere geeignete Möglichkeiten zur<br />
Erstellung <strong>von</strong> Modellinstanzen aus Software-Artefakten denkbar sind. Konkret demonstriert wurde die<br />
<strong>Generierung</strong> <strong>von</strong> Ecore-Klassenmodellen aus Java-Quellcode.<br />
7. Lässt sich die Nutzerschnittstelle solcher Altsysteme automatisiert als Modellinstanz abbilden?<br />
Diese Frage lässt sich ebenfalls positiv beantworten. Liegen geeignete Metamodelle der Oberflächensysteme<br />
dieser Altsysteme vor, so können deren Oberflächen prinzipiell automatisiert als Modellinstanzen<br />
beschrieben werden. Der Einsatz des in der Arbeit vorgestellten Proof-Of-Concepts - die Benutzungsoberfläche<br />
einer Java-Swing Anwendung wurde als Instanz des Swing-Metamodell abgebildet - ist allerdings<br />
auf bestimmte Rahmenbedingungen beschränkt.<br />
8. Welche Vorteile und Verbesserungen lassen sich für die modellgetriebene Entwicklung <strong>von</strong> <strong>Benutzungsoberflächen</strong><br />
zeigen?<br />
Der Nachweis direkter Vorteile der modellgetriebenen Entwicklung ist für die Erzeugung <strong>von</strong> <strong>Benutzungsoberflächen</strong><br />
schwer zu führen. Die mit den Mitteln und Ergebnissen dieser Arbeit erstellten GUIs halten<br />
einem Vergleich mit aktuellen, klassisch entwickelten, Oberflächen kaum Stand. Allerdings bieten die erarbeiteten<br />
umfangreichen Modelle nun, zumindest theoretisch, die Möglichkeit, GUIs gleicher Qualität zu<br />
erstellen.<br />
Mag das Layout- und sonstige designerische Ergebnis derzeit noch nicht unbedingt höchsten Ansprüchen<br />
genügen, kommen doch die allgemeinen Vorteile eines MDSE zum Tragen. Die Entwicklung <strong>von</strong>
116 KAPITEL 5. ZUSAMMENFASSUNG<br />
Software-Prototypen gelingt schnell. Die Separation-Of-Concerns funktioniert gut, durch Aufteilung einer<br />
UI-Deklaration auf verschiedene Modellebenen sind auch komplexe GUIs einfach wartbar. Gleichzeitig ist<br />
das Abstraktionsniveau so variabel das sogar die Einbettung <strong>von</strong> HCI-Patterns gelingt.<br />
5.2 Vorschläge für weiterführende Arbeiten<br />
5.2.1 Multimodale Nutzerschnittstellen<br />
Die Arbeit ist primär mit Modellen für grafische <strong>Benutzungsoberflächen</strong> nach dem WIMP-Prinzip befasst.<br />
Daneben existiert jedoch noch eine Vielzahl weiterer Techniken für Benutzungsinterfaces, z.B. taktile Verfahren,<br />
Gestenerkennung, Sprachsteuerung oder 3-dimensionale Darstellungsverfahren. Eine Abschätzung<br />
inwiefern die präsentierten Modelle und Vorgehensweise auf andere UI-Modalitäten übertragbar sind ist<br />
daher interessant.<br />
Grundsätzlich anwendbar ist der in Abschnitt 2.1 vorgestellte Gesamtprozess. Gerade der Fokus auf<br />
Plattform- und Geräteunabhängigkeit der Oberflächenbeschreibungen führte zu dessen Teilmodellen und<br />
Abstraktionsebenen. Dies beinhaltet ausdrücklich auch andere Interface-Modalitäten.<br />
Ebenfalls problemlos geeignet für Nicht-WIMP UIs sind selbstverständlich die benutzten Transformationstechniken.<br />
Für die Anwendbarkeit <strong>von</strong> Model-To-Model oder Model-To-Text Transformationstechniken<br />
spielt keine Rolle, welche konkreten Wertausprägungen die Modellinstanzen haben, oder welchem Zweck<br />
die Modelle dienen. Entscheidend ist allein die Konformität zu den entsprechenden Metamodellen.<br />
Die Metamodelle sind dagegen sehr wohl abhängig <strong>von</strong> der umzusetzenden oder angestrebten Modalität.<br />
Die vorgestellten und vorgeschlagenen Modelle für konkrete Oberflächen lassen sich kaum nutzbringend<br />
für andere Interface-Arten anwenden. Beispielsweise könnten die WIMP-Modelle auch in 3D-<br />
Umgebungen benutzt werden, sie wären nicht zur Beschreibung aller denkbaren und für diese Interface-Art<br />
markanten Features geeignet.<br />
Je näher der Abstraktionsgrad der Zielplattform ist desto spezialisierter werden die beschreibenden Modelle<br />
sein. Wahrscheinlich ist es daher günstig für andere UI-Modalitäten spezialisierte Metamodelle zu<br />
definieren. Bei deren Konstruktion sollen und können natürlich Anleihen bei den WIMP-Modellen genommen<br />
werden, die Definition technischer oder semantischer Abhängigkeiten über Assoziationen oder<br />
Vererbungen usw. scheint jedoch zunächst wenig vielversprechend.<br />
5.2.2 Vorschläge für weiterführende Forschungsansätze<br />
Das Thema der modellgetriebenen Entwicklung <strong>von</strong> <strong>Benutzungsoberflächen</strong> hält noch viele interessante<br />
Fragestellungen bereit. Neben der bereits angesprochenen Anpassung des Prozesses für multi-modale Interfaces<br />
bietet auch der ordinäre WIMP-Erzeugungsprozess viele Ansatzpunkte für vertiefende Arbeiten.<br />
Beispielsweise bei der Erzeugung eines Dialoggraphen aus Aufgabenmodellen, dem ersten Transformationsschritt<br />
im Rostocker Gesamtprozess. Derzeit handelt es sich dabei um einen, im Wesentlichen, manuellen<br />
Prozess. Zwar existiert ein Ansatz zur tatsächlichen Automatisierung der Transformation, dieser ist aber<br />
erst in groben Zügen ausgearbeitet und seine praktische Anwendbarkeit nicht ausreichend untermauert.<br />
Bidirektionale Modelltransformationen sind ein integraler Bestandteil des vorgestellten MD-UID Prozess,<br />
denn dadurch werden sowohl Reverse Engineering als auch Migratory Interfaces wesentlich nützlicher.<br />
Obwohl die Bidirektionalität als Konzept gut verstanden und in ihrer Bedeutung anerkannt ist, wird der Erstellung<br />
<strong>von</strong> Rücktransformationen für den Prozess wenig Beachtung geschenkt. Für den Rostocker Prozess
5.2. VORSCHLÄGE FÜR WEITERFÜHRENDE ARBEITEN 117<br />
sind derzeit verschiedene Transformationen zwischen konkreten Oberflächenmodellen sowie zur Ableitung<br />
einer abstrakten Oberfläche aus XUL-Instanzen vorhanden.<br />
Das generelle Problem der Entwicklung geeigneter Rücktransformation besteht auch für andere Ansätze,<br />
z.B. bei MARIA, und wird <strong>von</strong> einer Reihe <strong>von</strong> Forschern untersucht. Eine Besonderheit im hiesigen Prozessmodell<br />
ist die Fragestellung nach der Ableitung <strong>von</strong> Dialoggraphen aus AUI-Deklarationen. An diesem<br />
Übergang liegt eine doppelte Schwierigkeit vor, die ersichtlich wird, wenn man sich die Kernelemente <strong>von</strong><br />
Dialoggraphen vor Augen hält: Sichten, Aufgaben und Transitionen zwischen Sichten. Neben dem sich<br />
daraus ergebenden, bereits für sich schwierigen, Problem der Identifikation der Dynamik einer Oberfläche<br />
muss gleichfalls ein Aufgabenmodell aus den Quellmodellen generiert werden. Unter anderem um diesem<br />
Ziel näher zu kommen wird gegenwärtig die Synthetisierung nützlicher Aufgabenmodelle aus konkreten<br />
Rohdaten am Lehrstuhl untersucht. Ähnlich gelagerte Probleme werden weiterhin unter dem Stichwort<br />
„Process Mining“ erforscht.<br />
Teilweise könnte es gelingen, in einem Swing-Oberflächensnapshot Merkmale zu identifizieren, die Rückschüsse<br />
auf die vorgesehene Navigation beziehungsweise den Steuerfluss ermöglichen. Zielführend dürften<br />
solche Untersuchungen aber nur im Zusammenhang mit gleichzeitiger Analyse des zugrundeliegenden<br />
Java-Quellcodes sein. Womit sich die Frage stellt, ob hier überhaupt eine automatische Erkennungsheuristik<br />
anzustreben ist oder gleich untersucht werden sollte, wie ein menschlicher Modellierer bestmöglich<br />
unterstützt werden kann.<br />
Solange für beide genannten Probleme, also Aufgabenmodell- und Dynamikerkennung, keine stabilen zufriedenstellenden<br />
Lösungen vorliegen, wird die Ableitung <strong>von</strong> Dialoggraphen aus den konkreteren Teilmodellen<br />
zur Oberflächendeklaration eine schwierige und offene Frage bleiben.<br />
Weitere Ansätze für Forschungsarbeiten ergeben sich aus dem Patternkatalog. Einerseits bleibt das große<br />
Thema der Patternerkennung in vorhandenen Modellinstanzen relevant und andererseits hat sich herausgestellt,<br />
dass bestimmte Interface-Patterns geradezu bestimmte Strukturen in der Geschäftslogik oder den<br />
Datenstrukturen erfordern. Es sollten also die Zusammenhänge zwischen Patterns ausführlich erörtert werden,<br />
möglicherweise lassen sich dann einige Pattern-Ensembles finden, d.h. Pattern-Instanzen die oftmals<br />
gemeinsam auftreten.<br />
Besonders erfolgversprechend scheint das Gebiet der Testautomatisierung zu sein. Einige der im Rahmen<br />
des Reverse Engineering diskutierten Methoden zur Instanzableitung <strong>von</strong> CUI-Modellen aus laufender<br />
Software, bieten interessante Ansatzpunkte zur Fremdsteuerung der untersuchten Software. Derzeit werden<br />
die Objekteigenschaften nur gelesen, es existiert jedoch kein prinzipielles Hindernis welches einen<br />
schreibenden Zugriff verhindern würde. Denkbar wäre es daher, die CUI-Instanzen zur Definition <strong>von</strong><br />
Testskripten heranzuziehen, und die Testvalidierung ebenfalls mit typischen Methoden, etwa OCL, vorzunehmen.<br />
Natürlich sind auch die Arbeiten an den CUI-Metamodellen nicht als abgeschlossen zu betrachten, interessant<br />
scheint beispielsweise auch das XUL-Metamodell dem Modellpruning zu unterziehen. Vermutlich<br />
ergibt sich hierfür keine Reduktion auf ein Zehntel oder Zwanzigstel wie bei dem Swing-Metamodell, aber<br />
es könnte gelingen, alle nicht darstellungsrelevanten Metaklassen aus dem Modell zu entfernen.<br />
Eine abschließende Bemerkung gilt dem aktuell zur Verfügung stehenden Tool-Support. Generell sollten<br />
auch weiterhin Ressourcen in dessen Verbesserung gesteckt werden. Die Anwendung der meisten Werkzeuge<br />
des EMP wird Endanwendern nicht ohne Weiteres gelingen da die Tools wenig fehlertolerant, gleichzeitig<br />
aber schwer zu tracen und zu debuggen sind.<br />
Konkrete, teils schwerwiegende, Probleme ergaben sich an mehreren Punkten. So war das unreduzierte<br />
Swing-Metamodell so umfangreich das die <strong>Generierung</strong> des Modellquellcodes, insbesondere mit Dif-
118 KAPITEL 5. ZUSAMMENFASSUNG<br />
ferenzanalyse zu existierendem Quellcode, praktikable Zeit- und Speicherplatzgrenzen überschritt. Eine<br />
zweite gravierende Einschränkung trat im Bereich der Model-To-Text Transformationen mit Acceleo zutage;<br />
mit den verfügbaren Versionen war es nicht möglich mehr als eine Modellinstanz als Eingabe für Transformationen<br />
zu verwenden. Dies schränkt Acceleos Anwendungsmöglichkeiten derzeit noch empfindlich<br />
ein, beispielsweise ließ es sich auf Grund dieser Einschränkung nicht für Vergleiche <strong>von</strong> Modellinstanzen<br />
nutzen und konnte ebenfalls nicht direkt für die Wartung des Patternkatalogs eingesetzt werden.<br />
Wünschenswert wären auch Arbeiten auf dem Gebiet der XML-Schema zu Ecore-Transformation. Wie bereits<br />
dargestellt, war das Ergebnis dieser <strong>Generierung</strong> nicht zufriedenstellend. Möglicherweise ließen sich<br />
die manuell durchgeführten Verfeinerungsschritte als Algorithmen definieren und zur Verbesserung dieses<br />
Prozesses einsetzen. Insbesondere sollte die Identifikation einer geeigneten Klassenhierarchie angestrebt<br />
werden.
Anhang A<br />
System- und Sprachbeschreibungen<br />
A.1 Allzweckmodellierung<br />
A.1.1 UIDE<br />
UIDE [41], <strong>von</strong> 1988, ist ein System zur Erzeugung textueller User Interfaces. Die Benutzeroberflächen<br />
werden dynamisch zur Laufzeit, durch Interpretation eines Modells, erzeugt und dargestellt. Dieses allem<br />
zugrundeliegende Modell ist die sogenannte Knowledge-Base.<br />
Die Idee ist es, das gesamte Designwissen zu einer Anwendung in dieser Wissensdatenbank zu speichern.<br />
Zum Designwissen zählt in diesem Fall insbesondere auch das Modell der Anwendung, d.h. es werden<br />
die Domänenobjekte und deren Operationen in der Wissensdatenbank abgelegt. Diese Beschreibung ist<br />
formalisiert und definiert für die Operationen ordentliche Signaturen mit korrekten Datentypen für die Einund<br />
Ausgaben. Um dies zu erreichen ist die Wissensbasis als Objekt-Metamodell strukturiert. Aufgrund<br />
des frühen Entwicklungszeitpunktes liegt dieses Metamodell natürlich nicht als UML-Klassendiagramm<br />
vor. Die Definition des Metamodells erfolgt durch ART 1 -Schemata.<br />
Modellinstanzen, also die Einträge in die Wissensbasis, werden über eine sogenannte Interface Definition<br />
Language (IDL) beschrieben. Diese IDL ist eine typische textuelle domänenspezifische Sprache.<br />
Listing A.1 vermittelt einen Eindruck da<strong>von</strong>, zur Erklärung: Hier wird eine Aktion, d.h. Methode, create_shape<br />
in der Wissensbasis deklariert. Bei der Modellinitialisierung wird eine Variable shape vom Typ number<br />
deklariert und mit 0 als Startwert belegt. Es wird keine Vorbedingung zur Auslösung der Aktion verlangt,<br />
bzw. diese ist immer true und damit irrelevant. Die darauffolgende Zeile definiert die Eingabeparameter<br />
der Methode, es sind hier keine Rückgabetypen vorgesehen. Die Typen der Parameter müssen an anderer<br />
Stelle in der Wissensbasis vorliegen. Nach dem Methodenende wird als Nachbedingung dieser Aktion die<br />
Anzahl der shape hochgezählt.<br />
✞ ☎<br />
initial: number(shape)=0<br />
pre−condition: true<br />
create_shape(p: position, c: color, a:angle, object_type: shape_class)<br />
post−condition: number(shape)=number(shape)+1<br />
✝ ✆<br />
Listing A.1: Ausschnitt einer UI-Spezifikation mit der UIDE-IDL<br />
1 Automated Reasoning Tool<br />
119
120 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Die Laufzeitkomponente, d.h. der Generator der als UI-Management System bezeichnet wird, soll aus der<br />
Wissensdatenbank ein voll-funktionales textuelles Nutzungsinterface erstellen. Dies scheint in Grundsätzen<br />
vergleichbar zu dem in dieser Arbeit verfolgten Ansatz, aus einem Klassenmodell die Benutzungsoberfläche<br />
abzuleiten. Auch die Entwickler <strong>von</strong> UIDE hatten das Problem, dass die Wissensbasis als solche<br />
bei weitem nicht genügend Informationen bereitstellt um nützliche Oberflächen daraus abzuleiten. Daher<br />
bilden sogenannte Constraints einen weiteren integralen Modellbestandteil <strong>von</strong> UIDE. Dabei handelt es<br />
sich um deklarative Regeln zur Steuerung des Generators. Letzlich sind die Constraints Abbildungs- oder<br />
Transformationsregeln. Sie definieren wie die einzelnen Parametertypen der Wissenbasis dargestellt werden<br />
sollen.<br />
Der <strong>Generierung</strong>sprozess läuft folgendermaßen: Über die Auswertung der Vorbedingungen der Aktionen<br />
werden die zum jeweiligen Zeitpunkt ausführbaren Aktionen ermittelt. Die Methoden-Signaturen der Aktionen<br />
liefern dann die Informationen darüber, welche Daten vom Nutzer bereitzustellen sind. Und über die<br />
Constraints ist die UI-Darstellung für jeden abzufragenden Datentyp festgelegt. Damit ist es schlussendlich<br />
möglich, eine Eingabemaske darzustellen.<br />
Selbstverständlich gibt es weitere syntaktische Konstrukte um Feinheiten der Oberflächenerzeugung zu<br />
steuern. Operationsparameter können als implizit, explizit oder optional definiert sein, mit den dementsprechende<br />
Auswirkungen auf die dem Nutzer zur Datenabfrage bereitgestellte UI. Ebensfalls wurden Vorkehrungen<br />
zur Ableitung <strong>von</strong> Menüstrukturen getroffen, es existiert ein sogenanntes Slot-Konzept. Diejenigen<br />
Aktionen die dem gleichen Slot zugewiesen werden bilden ein Menü. In Grenzen können Abhängigkeiten<br />
zwischen Menüeinträgen spezifiziert werden. Beispielsweise bewirkt die Definition als mutually−exclusive<br />
action für Aktionspaare, dass immer nur eine der beiden Aktionen dem Nutzer bereitgestellt wird. Der<br />
Effekt ist, dass beide Aktionen ein und dieselbe Menüposition belegen. Weitere Eigenschaften, Syntaxelemente<br />
und deren Konsequenzen in der Constraint-Sprache werden in [50] diskutiert.<br />
Eine Reihe <strong>von</strong> grundsätzlichen Problemen bleibt im UIDE-Ansatz offen, bzw. werden durch die Beschränkung<br />
auf kleine Systeme mit textuellen Interfaces nicht relevant. So ist zum Beispiel die Anordnung und<br />
Visualisierung der zur Auswahl stehenden Aktionen nicht spezifiziert. Betrachtet man einen typischen Arbeitsprozess<br />
bleibt auch die Frage offen, wie die Ausgaben einer Operation sinnvoll als Eingaben für eine<br />
daran anschließende Operation benutzt werden können, ohne sie manuell einzugeben. Untersucht man das<br />
motivierende Beispiel zur Nutzung <strong>von</strong> UIDE in [40] fällt zudem auf, dass bereits bei kleinen Problemen<br />
die Spezifikation widerspruchsfreier Vor-/Nachbedingungen für die Aktionen ein nicht-triviales Problem<br />
darstellt. Eine Machbarkeitsstudie für eine reale Software mit UIDE steht, soweit ich das beurteilen kann,<br />
weiter aus.<br />
A.1.2 DON<br />
Anfang der 1990er Jahre wurde UIDE für graphische <strong>Benutzungsoberflächen</strong> weiterentwickelt. Diese Weiterentwicklung<br />
erhielt den Namen DON, der Name entstammt dem englischen „to don = Sachen anziehen“.<br />
Die Entwickler bezeichnen DON als einen User Interface Presentation Design Assistant [42].<br />
Aufgrund des GUI-Focus liegt ein Schwerpunkt <strong>von</strong> DON im Dialog-Design und der Menüerzeugung für<br />
WIMP-Oberflächen. Entsprechend seiner Abstammung verwendet DON ebenfalls eine globale Wissensbasis<br />
und Constraints. DON tritt mit dem Anspruch an, in den Constraints das Wissen und die Vorgehensweisen<br />
<strong>von</strong> menschlichen Designern in Algorithmen umzusetzen und diese zur Erzeugung besserer<br />
Benutzeroberflächen anzuwenden.<br />
Die Interface Definition Language wurde gegenüber UIDE erweitert. Beispielsweise können nun Mengenund<br />
Aufzählungstypen deklariert werden. Insgesamt steigt dabei die Ausdrucksmächtigkeit und der Detail-
A.1. ALLZWECKMODELLIERUNG 121<br />
grad der Spezifikationen.<br />
✞ ☎<br />
style: set(1,4) of (Bold, Underline, Shadow, Italic) sequenzing ALPHABETICAL<br />
✝ ✆<br />
Listing A.2: Regeldefinition für DON<br />
Listing A.2 definiert den Mengentyp style. Parameter dieses Typs müssen genau einen der vier zur Auswahl<br />
gestellten Werte annehmen. Wenn ein Nutzer die Wertbelegung auswählt, sollen ihm die Optionen in<br />
alphabetischer Reihenfolge präsentiert werden. In der interpretierten Oberfläche könnte DON für style z.B.<br />
eine Dropdown-Box anbieten.<br />
Das Erstellen <strong>von</strong> Benutzeroberflächen mit DON gleicht dem UIDE-Prozess. Die erste Schritt ist immer<br />
die Strukturierung der gewünschten Aktionen in der Wissensbasis, also die Festlegung auf ein Anwendungsmodell,<br />
mit Typen und Operationen. Unter Anwendung der Constraints des Regelsystems findet im<br />
Anschluß daran das Mapping <strong>von</strong> Aktionen auf passende Userinterface-Objekte (UIO) statt.<br />
Im Unterschied zu UIDE wird <strong>von</strong> DON das Problem der Anordnung der Oberflächenelemente behandelt.<br />
Auch Layouting-Verfahren können in Constraints umgesetzt werden. Das hierfür innerhalb <strong>von</strong> DON aufgestellte<br />
und implementierte Regelsystem soll generelle Design-Prinzipien, die auf Erkenntnissen aus der<br />
Gestaltungspsychologie [144] basieren, umsetzen.<br />
Das bedeutet, dass die Wertheimerschen Kriterien Nähe (proximity), Gleichartigkeit (similarity), Ausrichtung<br />
(direction) und ggf. Enthaltensbeziehungen (closure) in Constraints umgesetzt wurden. Zusätzlich<br />
identifizierte Foley, ein Mitglied des DON-Entwicklunsteams, während seiner Arbeit an DON die Kriterien<br />
Balance (balance) als Objektverteilung auf der Oberfläche, Proportionen (proportion) und die Ausrichtung<br />
an Gittern (gridding). Da die Transformationsregeln erweiterbar sind, ist diese Kriterienliste prinzipiell<br />
nicht abgeschlossen, sondern eine Erweiterung um weitere Kriterien war immer möglich und angestrebt.<br />
Im Gegensatz zu UIDE können für die Ausführbarkeitsentscheidung und die Konsequenzen einer Aktion<br />
mehrere Vor- und Nachbedingungen festgelegt werden. Die Definition <strong>von</strong> Aktionsabfolgen muss auch bei<br />
DON deklarativ, über die geeignete Festlegung <strong>von</strong> Vor- und Nachbedingungen, erfolgen. DON versucht,<br />
durch Auswertung der über die Bedingungen definierten Aktionszusammenhänge zu ermitteln, welche Aktionen<br />
zusammengruppierbar sind. Dies ist insoweit bedeutsam, da es sich dabei um die Aktionen handelt,<br />
die gleichzeitig auf der Oberfläche dargestellt werden müssen.<br />
Die Durchführung dieser Gruppierung wird automatisiert durch zwei Hauptkomponenten, Manager genannt,<br />
vorgenommen. Diese Manager sind im Wesentlichen Regelsammlungen welche die Weinheimerschen<br />
und Foleys Layout-Prinzipien so weit als möglich umsetzen.<br />
Die erste Komponente ist der Organisation-Manager, dieser gruppiert die im Anwendungsmodell hinterlegten<br />
Aktionen entsprechend ihrer Parameter und erstellt eine Struktur darüber. Diese Struktur bildet die<br />
Grundlage für das Menü der Anwendung. Der Organisation-Manager wertet dazu den Detailgrad, die gegenseitigen<br />
Abhängigkeiten und den Geltungsbereich der Spezifikationen der Operationen aus und ordnet<br />
die Aktionen zunächst in eine Prioritätsklasse ein. Im DON-Ansatz wurden 9 Klassen bzw. Gruppierungen<br />
identifiziert. Die Klassen 1-7 sind dabei direkt aus der Spezifikation ableitbar, beispielsweise ist die Bedingung<br />
für die Einordnung in die Klasse 6, dass Vor- und Nachbedingung der Operation identisch sind. Für<br />
die beiden Klassen 8 und 9 wird menschliches Wissen bzw. eine manuelle Designentscheidung benötigt. In<br />
Klasse 8 wird die „Erwartete Wichtigkeit“ und in Klasse 9 die „Erwartete Nutzungshäufigkeit“ bewertet.<br />
Vom Organisation-Manager wird ausserdem das Mapping <strong>von</strong> Aktionen auf User Interface Objekte nach<br />
den Auswahlregeln durchgeführt. Die Auswahl der gewünschten Mappings kann über Profile gesteuert<br />
werden, durch Austausch der verwendeten Profile kann eine Anpassung an unterschiedliche Nutzungsszenarien<br />
erfolgen.
122 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Die zweite Hauptkomponente ist der Presentation-Manager, er ist für das eigentliche Layout <strong>von</strong> Menüs<br />
und Dialogboxen verantwortlich. Der Presentation-Manager nutzt die Ergebnisse der Mappings des Organisation-Managers<br />
und die Einträge in der Wissensbasis. Seine Hauptaufgabe ist die Zuordnung der<br />
Interface-Objekte zu Layoutcontainern.<br />
Der Zweck dieses Managers ist, es Probleme wie Überfüllung oder Verletzung der Gestaltungskriterien<br />
der Oberfläche zu handhaben. Als Hauptproblem hat sich beim Einsatz <strong>von</strong> DON die Überfüllung herausgestellt.<br />
Im Rahmen des sogenannten Overflow-Handling entscheidet der Presentation-Manager welche<br />
Elemente der Oberfläche angezeigt, modifiziert oder ausgeblendet werden. Hierfür werden verschiedene<br />
Strategien verfolgt, diese sind in der Reihenfolge ihrer Auswirkungen auf die Gestaltung der Benutzeroberfläche<br />
priorisiert. Als Low-Impact Problembehebungsstrategie, und damit eine der bevorzugten Strategien,<br />
wird z.B. Größenanpassung einzelner Oberflächenelemente angesehen. Demgegenüber zählt das Austauschen<br />
der Visualisierung einer Aktion durch eine andere Darstellungsform zu den High-Impact Strategien.<br />
Beispielsweise könnte ein Slider-Control durch ein schmales Textfeld ersetzt werden, welches horizontal<br />
weniger Platz benötigt. Dieser Austausch ändert das Aussehen der Benutzeroberfläche erheblich, behält<br />
aber dennoch die gleichen Ein- und Ausgabemöglichkeiten bei. Das Ziel des Presentation-Manager ist<br />
es, innerhalb der durch den Organisation-Manager aufgebauten logischen Ordnung, eine passend layoutete<br />
Umgebung zu erstellen. Ein Durchbrechen dieser genannten Ordnung ist in den Strategien zwar vorgesehen,<br />
jedoch als High-Impact Strategie entsprechend niedrig priorisiert.<br />
Organisations- und Presentation-Manager erzeugen zum Start der Applikation die gesamte Oberfläche. Im<br />
Unterschied zu UIDE findet bei DON keine Anpassung der Benutzungsoberfläche zur Laufzeit mehr statt.<br />
DON ist ein interessanter Ansatz für GUI-Oberflächen. Anscheinend treten jedoch die gleichen Schwierigkeiten<br />
wie bei UIDE auf. Alle möglichen Handlungsfolgen einer realen Anwendung rein deklarativ<br />
zu beschreiben ist sehr aufwändig. Darüberhinaus für jeden erreichbaren Anwendungszustand die Benutzungsoberfläche<br />
vorgeneriert zur Verfügung zu halten ist ebenfalls ein äußerst schwieriges Unterfangen.<br />
Es ist daher nicht wahrscheinlich, dass die Kombination dieser beiden Probleme die anzustrebende Lösung<br />
der modellgetriebenen Oberflächenentwicklung darstellt. Die Tatsache das in den letzten zwanzig Jahren<br />
keine DON-basierten Anwendungen entstanden unterstreicht dieses Urteil.<br />
A.1.3 HUMANOID<br />
HUMANOID [119] ist prinzipiell ein Designwerkzeug für grafische Nutzerinterfaces, das Anfang der<br />
1990er Jahre entstand. Gleichzeitig handelt es sich hierbei um die Proof-Of-Concept Implementierung<br />
einer speziellen Designherangehensweise. HUMANOID liegt die Idee zugrunde, dass die schwierigsten<br />
Designentscheidungen menschlichen Designern überlassen werden sollen. Die Designer sollen durch Automatisierung<br />
bei repetitiven Standardtätigkeiten und -entscheidungen entlastet werden. Das besondere im<br />
Ansatz <strong>von</strong> HUMANOID ist es, das High-Level Design eines User Interface als das zu erreichende Ziel zu<br />
definieren und sich diesem Ziel durch Dekomposition in Design-Teilziele anzunähern.<br />
Ein High-Level Design-Ziel im Sinne <strong>von</strong> HUMANOID ist eine Beschreibung dessen was mit dem betrachteten<br />
Teil des User-Interface erreicht werden soll. Das Design-Ziel ist also explizit kein UI-Mockup<br />
oder Prototyp, sondern eine teilformalisierte textuelle Beschreibung einer Interface-Aktion.<br />
Für HUMANOID wurde eine Ontologie <strong>von</strong> sogenannten Top-Level Interface-Zielen und diesen zugeordneten<br />
Unterzielen entwickelt. Beispielsweise ist das Top-Level Ziel „Made-Object-Draggable“ definiert,<br />
d.h. ein UI-Objekt ziehbar machen. Diesem werden die Unterziele „Dragging-Interactor (Behaviour)-<br />
Elaborated “, etwa Zieh-Auslöser ausgearbeitet, und „Feedback-Template-Elaborated“ , etwa als Rückmeldung<br />
ausgearbeitet übersetzbar, zugeordnet. Viele Unterziele in der HUMANOID-Ontologie enthalten
A.1. ALLZWECKMODELLIERUNG 123<br />
selbst weitere Unterziele. Diese Schlagworte erinnern Designer, welche Probleme noch bedacht und geklärt<br />
werden müssen.<br />
Durch Zusammensetzung solcher Haupt- und Unterziele wird die Abarbeitung einer Nutzeraktion beschrieben.<br />
Wenn auf diese Weise die Beschreibung fertiggestellt ist, folgt der automatisierte Teil <strong>von</strong> HUMA-<br />
NOID, die Prototypen-<strong>Generierung</strong>. HUMANOID wurde als ein modellbasiertes System umgesetzt.<br />
Im Ergebnis einer Modellierung mit HUMANOID entsteht eine, in der HUMANOID-Laufzeitumgebung,<br />
ausführbare UI. Es handelt sich dabei um einen Oberflächen-Prototyp. Außer der in HUMANOID selbst<br />
hinterbaren Modifikation <strong>von</strong> Anwendungsobjekten und bietet dieser Prototyp normalerweise keine Anbindung<br />
an extern programmierte Geschäftslogik.<br />
Bei HUMANOID gibt es ein Modell der Anwendung, welches inhaltlich sehr ähnlich der Wissensbasis <strong>von</strong><br />
DON/UIDE ist. Es enthält Informationen über die Objekte und Operationen der Anwendungslogik. Und<br />
ähnlich der DON-Idee definieren auch hier die Operationen implizit die gewünschten Funktionalitäten auf<br />
der Oberfläche. Dieses Modell wird nach [119] in fünf „halb-unabhängige“Dimensionen unterschieden.<br />
Letztlich sind unter diesen Dimensionen Teilmodelle zu verstehen.<br />
Die erste Dimension, Application semantics entspricht in etwa einem Domänenmodell, beschreibt also die<br />
Einsatzumgebung der Software. Hier werden die Anwendungsobjekte und ausführbare Befehle (Commands)<br />
definiert und dabei deren Datentypen festgelegt. Auch in HUMANOID existiert das aus UIDE bekannte<br />
Slot-Konzept, allerdings werden hier Commands zu Slots zugewiesen. Commands unterscheiden sich <strong>von</strong><br />
den Aktionen bei UIDE dadurch, dass zusätzlich die Aspekte Dateneingabe und CallBack-Procedure 2 definiert<br />
werden können.<br />
Das Presentation-Modell als zweite Dimension beschreibt die grafische Darstellung <strong>von</strong> Daten und Commands.<br />
Dieses Teilmodell benutzt hierarchisch organisierte Templates. Die Blattknoten in diesem Hierarchie-<br />
Baum sind direkte grafische Primitive, Widgets oder sonstige building-blocks des zugrundeliegenden Grafiksystems.<br />
Über ebenfalls Slots genannte Parameter werden den Templates die darzustellenden Informationen<br />
übergeben. Die HUMANOID-Umgebung stellt diverse Template-Bibliotheken zur direkten Weiterverwendung<br />
zur Verfügung.<br />
Die dritte Dimension ist das Manipulation-Modell. Dieses Modell stellt die Verbindung zwischen Nutzer-<br />
Eingaben und den Objekten des Presentation-Modells her. Die betrachtete Grundeinheit sind Gestures, das<br />
Wort ist ein Versuch sind sämtliche Interaktionsmöglichkeiten in einen Begriff zu fassen. Unter Gestures<br />
ist daher die Gesamtheit <strong>von</strong> Tastendrücken, Mouseevents und anderen denkbaren Interaktionsmöglichkeiten<br />
zu verstehen. Dieses Teilmodell fügt letztlich eine Verhaltensspezifikation zu den Templates des<br />
Presentation-Modells hinzu. Es kann mit dem Dialog- bzw. dem Präsentationsmodell anderer Systeme<br />
verglichen werden. Der Inhalt dieses Modell sind Schlüssel-Wert Paare der Art: (“Cursortaste runter gedrückt“,“reduziere<br />
Wert um 4“).<br />
Im vierten Teilmodell Action side effects werden regelmäßig benutzte Informationsaktionen definiert. Darunter<br />
werden in HUMANOID Tonausgaben oder Hinweisnachrichten verstanden, welche den Nutzer sofort<br />
über den Status einer Aktion informieren können. Die verwendeten Schlüsselwörter dazu sind selbsterklärend,<br />
z.B.: Beep−When−Correct oder Message−When−Correct. Es gibt eine Bibliothek mit derlei Standardaktionen,<br />
die allgemeine Wirkungsweise entspricht jener <strong>von</strong> Templates im Dialogmodell.<br />
Die fünfte Dimension ist das Sequencing-Modell. Es ist ein Dialog-Modell und beschreibt die Abfolge der<br />
Eingabemasken der Anwendung sowie die Aktivitätenreihenfolge für einzelne in einer Maske enthaltene<br />
Elemente. Es werden keine expliziten Aktivierungsanweisungen durch die Designer definiert, sondern die<br />
Reihenfolge wiederum mittels geeigneter Constraints deklarativ spezifiziert. Die Constraint-Sprache zur<br />
2 Aufzurufende Methode nach Durchführung der Operation
124 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Beschreibung der Sequenzierung unterscheidet zwischen Eingabe-, Gruppierungs- und Befehlselementen.<br />
Die Laufzeitumgebung <strong>von</strong> HUMANOID wertet die Reihenfolge während des Programmablaufes aus und<br />
schaltet zwischen den entsprechenden Masken und Aktivitäten um. Auch für diesen Teilaspekt existiert<br />
eine Bibliothek mit typischen Sequenzierungen.<br />
Die Erstellung einer Oberfläche mit HUMANOID zerfällt somit in zwei sehr unterschiedliche Teile. Zunächst<br />
sind alle erwünschten Top-Level Ziele zu identifizieren. Durch Anwendung der Begrifflichkeiten aus<br />
der Ontologie ist das Erreichen dieser Hauptziele durch Einsetzen erforderlicher Unterziele zu beschreiben.<br />
Gleichzeitig sind die zuvor beschriebenen Teilmodelle zu erstellen.<br />
Abschließend müssen die Verbindungen zwischen der Zielhierarchie und den Teilmodellen, und ggf. die<br />
Beziehungen zwischen den Teilmodellen, aufgebaut werden. So könnte z.B. einem Teilziel „Show-Object-<br />
Contents“ eine Textbox zur Darstellung und ein Domänenobjekt als Inhaltslieferant zugewiesen werden.<br />
Ebenfalls könnten die Auswirkungen <strong>von</strong> Cursorbewegungen in der Textbox festgelegt werden. Das Ergebnis<br />
dieser Mappings wird durch die HUMANOID-Umgebung interpretiert und dargestellt.<br />
HUMANOID wurde nie verwendet um reale Anwendungen zu gestalten. Die verwendeten Teilmodelle<br />
scheinen jedoch durchaus detailliert zu sein. Die Idee der Zerlegung der Designziele hat sich nicht durchgesetzt,<br />
möglicherweise weil die Abstraktionsebene auf welcher operiert wurde bereits zu niedrig, zu implementierungsnah<br />
war.<br />
A.2 Modellierung für Spezialbereiche<br />
A.2.1 DRIVE<br />
Als erstes System dieser Kategorie soll DRIVE [77] aus dem Jahr 1995 vorgestellt werden. Hierbei handelt<br />
es sich um eine experimentelle Softwareumgebung und ein Framework für die Definition und Erstellung<br />
<strong>von</strong> Benutzeroberflächen <strong>von</strong> Datenbank-Anwendungen.<br />
Im Selbstverständnis der DRIVE-Entwickler sollte eine UI-Erprobungsumgebung („sketch-pad“) für neue<br />
Techniken bei Nutzungsoberflächen geschaffen werden. Besonderer Fokus wurde auf die Möglichkeit der<br />
Anbindung 3-dimensionaler Visualisierungstechniken gelegt. Um zur Evaluierung verschiedener Techniken<br />
eine Vergleichbarkeit zwischen den diversen Oberflächenprototypen herzustellen, sollte die Präsentation<br />
gleicher Daten und das Auslösen der gleichen Geschäftslogik ermöglicht werden. Zur Vermeidung<br />
zeitintensiver und fehlerträchtiger Mehrfachimplementierungen bei Daten und Programmlogik, wurden<br />
auf modellbasierte Techniken eingesetzt. Der Name DRIVE steht daher für Database representation<br />
independent visual environment, frei übersetzt etwa „Datenmodellunabhängige Visualisierungsumgebung“.<br />
Das DRIVE-Framework besteht aus mehreren Teilen, deren Zusammenspiel in Abbildung A.1 angedeutet<br />
wird. Es handelt sich dabei um eine <strong>von</strong> mir vorgenommene Verallgemeinerung der Abbildung 4 aus [77].<br />
Zur Interpretation ist die Darstellung <strong>von</strong> Rechts nach Links zu lesen, die Originalautoren entschieden sich<br />
für diese Leserichtung.<br />
Das Fundament des DRIVE-Ansatzes bilden zwei Modelle, das Nutzer- und das Datenmodell. Wie üblich<br />
besteht das Datenmodell aus einem Klassenmodell der Anwendungsobjekte. DRIVE wurde speziell für objektorientierte<br />
Datenbanken entwickelt. Das Datenbankschema der Anwendung ist daher gleichzeitig das<br />
Datenmodell im DRIVE-Ansatz. Außerdem wird durch die DB-internen Methodenimplementierungen die<br />
Geschäftlogik bereitgestellt. Für das Nutzermodell <strong>von</strong> DRIVE wird ein eigenes Metamodell vorgeschlagen,<br />
dieses soll hier nicht weiter betrachtet werden.
A.2. MODELLIERUNG FÜR SPEZIALBEREICHE 125<br />
UI-Framework Umgebungsmanager Modellebenen der DRIVE-Modellierung<br />
FW-Obj1<br />
FW-Obj4<br />
FW-Obj2<br />
FW-Obj3<br />
FW-Obj5<br />
Widget1_Impl<br />
Widget2_Impl<br />
Widgetn_Impl<br />
Widget1<br />
Widget2<br />
Widgetn<br />
UIO1<br />
UIO2<br />
UIO3<br />
UIOn<br />
Nutzer<br />
Visualisierung Schnittstelle Daten<br />
Abbildung A.1: DRIVE - Modellsystem, nach [77]<br />
Rolle1<br />
Rollen<br />
Objekt1<br />
Objektn<br />
Ausgehend <strong>von</strong> Nutzer- und Datenmodell wird im DRIVE-Ansatz die Visualisierungsschnittstelle modelliert.<br />
Im ersten Schritt wird entschieden welche Interaktionsobjekte (UIO) die Nutzungsoberfläche zur<br />
Verfügung stellen soll. Dabei wird auch festgelegt, an welchen UIOs Instanzen <strong>von</strong> Daten- oder Nutzermodell<br />
beteiligt sind, sei es als Datenquellen/-senken oder Interaktionsauslöser. Die gefundenen Beziehungen<br />
werden als Assoziationen auf Klassenmodellebene, mit einer eigenen Modellierungssprache ausgedrückt,<br />
spezifiziert. Mit einiger Berechtigung kann die Visualisierungsschnittstelle als abstrakte Oberfläche angesehen<br />
werden.<br />
Nachdem die Schnittstelle fixiert ist, kann die eigentliche Visualisierung festgelegt werden. Dies besteht<br />
im Wesentlichen aus einer Zuordnung der UIOs zu bestimmten vordefinierten Widgettypen. Diese Beziehungen<br />
zu den vordefinierten Widgets des DRIVE-Frameworks werden wiederum durch Assoziationen auf<br />
Klassenebene modelliert. Bemerkenswert ist hier, dass das Klassenmodell der Widgets selbst editiert werden<br />
soll; heutzutage würde vermutlich eher ein Plugin-Mechanismus oder Vererbung eingesetzt werden.<br />
Damit ist die DRIVE-Modellierung im Grunde abgeschlossen.<br />
Für die vorgegebenen DRIVE-Widgetklassen existieren C/C++ Implementierungen, diese Bilden den Kern<br />
des sogenannten Umgebungsmanagers. Dieser Bestandteil der DRIVE-Laufzeitumgebung nutzt die Informationen<br />
aus dem Visualisierungsmodell um die notwendigen Instanzen der vorimplementierten Zwischenmodellklassen<br />
zu instanziieren. Die Laufzeitumgebung berücksichtigt dabei auch die spezifizierte<br />
Assoziationskette zu Daten- bzw. Nutzermodell. Damit ist an dieser Stelle der ursprüngliche Anspruch <strong>von</strong><br />
DRIVE erfüllt; Daten, Geschäftslogik und ein Interface-Modell werden Datenbankunabhängig zur Visualisierung<br />
bereitgestellt. Natürlich kann, solange kein UI-Framework zur eigentlichen Darstellung angegeben<br />
wurde, noch keine Nutzungsoberfläche dargestellt werden. Das DRIVE-Framework sieht hierfür spezialisierte<br />
Editoren und die Benutzung <strong>von</strong> Drag&Drop-Techniken vor. In [77] wurde auf diesem Weg eine<br />
Beispielobefläche für einen Museumsführer entwickelt. DRIVE selbst fand kaum Verbreitung, Ideen dieses<br />
Ansatzes wurden aber in TEALLACH weitergeführt.<br />
A.2.2 TEALLACH<br />
Bei TEALLACH [56] handelt es sich ebenfalls um ein Framework zur modellbasierten Entwicklung <strong>von</strong><br />
Nutzeroberflächen für Datenbankanwendungen. Es ist eine Entwicklung, die am Ende der 1990er Jah-
126 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
re aus einer Zusammenarbeit der britischen Universitäten Glasgow, Manchester und Edinburgh entstand.<br />
Schwerpunkt des damaligen Forschungsverbundes war die <strong>Generierung</strong> <strong>von</strong> UIs für Applikationen welche<br />
auf objektorientierte Datenbankmanagementsysteme aufsetzen. Die Hauptentwicklungsplattform für<br />
TEALLACH war das DBMS POET 3 .<br />
TEALLACH nutzt drei Hauptmodelle; ein Domänenmodell, ein Aufgaben-Modell und ein Präsentationsmodell.<br />
Das Domänenmodell bildet die Ausgangsbasis der Modellierung. Für dieses Teilmodell sind keine<br />
Referenzen zu den anderen Modellen zugelassen. Die Instanzen <strong>von</strong> Aufgaben- und Präsentationsmodell<br />
dürfen durchaus auf Einträge untereinander verweisen, wie auch auf Objekte des Domänenmodells.<br />
Die Motivation für diese Einschränkung ist möglicherweise auf technischer Seite zu finden. Ähnlich DRIVE<br />
ist das Domänenmodell ein objektorientiertes Klassenmodell. Und dieses entsteht durch Ableitung, soweit<br />
möglich, direkt aus dem Datenbankschema der zu erstellenden Anwendung. Referenzen zu einem<br />
Präsentations- oder Aufgabenmodell sind in solchen Datenbankschemata im allgemeinen nicht vorgesehen.<br />
Die Schemadefinitionen des OO-DBMS POET erfolgten mit der ODL 4 . Wegen der zum damaligen Zeitpunkt<br />
eingeschränkten Akzeptanz <strong>von</strong> ODL wurden <strong>von</strong> Anfang an auch alternative Konfigurationsmöglichkeiten<br />
vorgesehen. Dazu wurde eine Möglichkeit geschaffen, auch nicht ODL-konforme Schemadefinitionen<br />
zu interpretieren und als Domänenmodell zu verwenden.<br />
Das Aufgabenmodell TEALLACHs entspricht in seiner Grundstruktur den Aufgabenmodellen anderer<br />
MB-UID Systeme. Es handelt sich um eine zielorientierte Aufgabenhierarchie, in deren Blattknoten, auch<br />
primitive Aufgaben genannt, die eigentlichen Interaktionen und Systemaktionen spezifiziert werden. Zur<br />
Beschreibung der Ablaufbeziehungen werden zwischen den Geschwisterknoten des Aufgabenhierarchiebaums<br />
temporale Operatoren notiert. Bei TEALLACH-Modellen können die in Tabelle A.1 beschriebenen<br />
sieben Operatoren verwendet werden. Die primitiven Aufgaben referenzieren direkt die für ihre Ausführung<br />
notwendigen Datenobjekte und besonders auch die auszulösenden Methoden des Domänenmodells.<br />
Im Präsentationsmodell wird die Nutzungsoberfläche definiert. Es unterscheidet zwei Abstraktionsebenen;<br />
das abstrakte (APM) und das konkrete Präsentationsmodell (CPM). Im APM wird die Oberfläche skizziert,<br />
hierbei wird für die diversen Interaktionsvorgänge eine sogenannte Darstellungskategorie gewählt. Da die<br />
Interaktionen als Blattknoten im Aufgabenmodell definiert sind, findet auf dieser Modellebene die Koppelung<br />
<strong>von</strong> Aufgaben- und Präsentationsmodell statt. Beispiele für die im TEALLACH-APM vorgesehenen<br />
Kategorien sind Chooser - Elementauswahl, Editor, Display - Datenanzeige und ActionItem - Aktionsauslösung.<br />
Zur genaueren Charakterisierung des jeweiligen abstrakten Interaktionselementes sind für die<br />
3 inzwischen als Versant FastObjects vermarktet<br />
4 Spezifikationssprache der ODMG<br />
Operator Bedeutung<br />
Sequential Sequentielle Ausführung<br />
Order-Independent Ausführungsreihenfolge egal, Ziel nach Beendigung aller Tasks erreicht<br />
Concurrent Parallele Ausführung, Ziel nach Beendigung aller Tasks erreicht<br />
Repeatable Iteration, Anzahl oder Bedingungsbeschränkt<br />
Choice Auswahl durch den Nutzer, impliziter Choice<br />
Optional 0..n aller Subtasks eines Tasks auszuwählen durch den Nutzer<br />
parallele Ausführung, Beendigung aller Subtasks ˆ= Zielerreichung<br />
Conditional Bedingte Auswahl, expliziter Choice<br />
Tabelle A.1: Temporale Operatoren zwischen Aufgaben in TEALLACH [56]
A.3. SYSTEME MIT AUFGABENMODELLIERUNGSHINTERGRUND 127<br />
einzelnen Kategorien noch Steuerparameter vorgesehen.<br />
Über die Wertbelegung dieser Parameter erfolgt die Feinjustierung der Mappings des konkreten Präsentationsmodells.<br />
In dem CPM wird die Implementierung der APM-Kategorie für die einzelnen Oberflächenbestandteile<br />
fixiert. Diese Implementierung wird durch die Widgets <strong>von</strong> realen UI-Frameworks gestellt,<br />
in [56] wurde <strong>von</strong> Java Swing genutzt.<br />
Ein besonderes Merkmal <strong>von</strong> TEALLACH ist, dass Objekte des Domänenmodells direkt als Vorlage für<br />
ihre Repräsentation im konkreten Präsentationsmodell verwendet werden können. Mittels Introspektion<br />
wird dabei für alle Getter und Setter eine Standarddarstellung gemäß des benutzten Datentypes gewählt.<br />
Aus diesen Standarddarstellungen wird eine fertig konfigurierte Komponente für die Oberfläche generiert.<br />
Offen bleibt, wie die Ableitung des zugehörigen APM aus den so erstellten CPM-Instanzen, d.h. eine geeignete<br />
Kategorisierung dieser Komponenten für die Verwendung im abstrakten Präsentationsmodell, erfolgen<br />
kann. Gravierender scheint jedoch, das ohne APM eigentlich keine Verbindung zum Aufgabenmodell und<br />
damit zur Geschäftslogik erstellt werden kann.<br />
Die für TEALLACH erstellte Werkzeugunterstützung unterstützt bereits das visuelle Editieren <strong>von</strong> Modellen<br />
und Assoziationen mittels Drag&Drop. Nachdem alle Teilmodelle spezifiziert sind, generiert das<br />
TEALLACH-Framework den Quellcode einer vollständigen Anwendung; normalerweise Java.<br />
Die Entwicklung <strong>von</strong> TEALLACH wurde anscheinend Anfang der 2000er Jahre eingestellt. Der Ansatz,<br />
aus der in einer Datenbank gekapselten Anwendungslogik über ein, wie auch immer geartetes Zwischenmodell<br />
zur Oberflächenbeschreibung, eine voll-funktionsfähige Anwendung zu erzeugen, wird in der Praxis<br />
durchaus weiterverfolgt. So ist etwa die „Oracle Forms“-Technologie ein prominentes Beispiel dieser<br />
Herangehensweise.<br />
A.3 Systeme mit Aufgabenmodellierungshintergrund<br />
A.3.1 ADEPT<br />
ADEPT [73], der Advanced design environment for prototyping with tasks, ist ein solches Framework für<br />
aufgabenmodellbasiertes User-Interface Design. Es wurde im Jahr 1992 vorgestellt.<br />
Zur Aufgabenmodellierung nutzt ADEPT ein an die sogenannten Task-Knowledge-Structures – TKS [66]<br />
angelehntes Aufgabenmodell. TKS sind Aufgabenmodelle deren Struktur speziell darauf zugeschnitten<br />
wurde, Interface-Designer bei der Gestaltung gebrauchstauglicher <strong>Benutzungsoberflächen</strong> zu unterstützen.<br />
In TKS werden Aufgaben in eine Taxonomie eingeordnet, zielorientiert strukturieriert und die zu ihrer<br />
Durchführung notwendigen Handlungen notiert.<br />
Unter einer zielorientierten Struktur ist die für Aufgabenmodelle typische hierarchische Zerlegung des<br />
obersten Nutzerziels zu verstehen. Zur Notation dieser Dekomposition nutzt ADEPT zusammenhängende<br />
Graphen. Die Abfolge der Teilaufgaben wird durch Operatoren gesteuert, die in den ADEPT-Graphen direkt<br />
an die Kanten angezeichnet werden. Die bereitgestellten Operatoren sind eine Untermenge derjenigen<br />
<strong>von</strong> Hoare in [61] für Communicating Sequencing Processes (CSP) vorgestellten.<br />
ADEPT nutzt neben dem Aufgabenmodell noch ein explizites User und ein Interface-Modell. Das User-<br />
Modell besteht aus (Schlüssel,Wert)-Tupeln, genannt Facts. Diese beschreiben die Nutzer genauer, d.h.<br />
deren Fähigkeiten und Fertigkeiten. Es enthält Informationen der Art: (’application experience’, ’high’)<br />
oder (’frequency of use’,’high’). Eine Ontologie für die möglichen Schlüssel dieses Modells ist nicht öffentlich<br />
verfügbar.
128 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Benutzt werden die Facts durch die sogenannten Design Rules, dies sind 3-Tupel (Schlüssel k, Falls-Wert<br />
v, Dann-Regel r), mit der Bedeutung: falls ein Fact mit dem Schlüssel k und dem Wert v existiert, dann<br />
wende Regel r an. Diese Regeln beeinflussen die Ableitung des abstrakten Oberflächenmodells aus dem<br />
Aufgabenmodell.<br />
Das 3-Tupel: ( ′ typingskills ′ , ′ low ′ , ′ f ill− in f orms ′ ) beschreibt eine solche Regel. Sie besagt, dass langsam<br />
tippenden Nutzern ein Formular bereitgestellt werden sollte. Fortgeschrittenen Tastaturnutzern soll<br />
nach der Regel ( ′ typingskills ′ , ′ high ′ , ′ f ree− f orm text ′ ) ein Freitextbereich für die Dateneingabe erzeugt<br />
werden.<br />
In ADEPT wird zwischen abstrakten und konkreten Oberflächen unterschieden. Beide Abstraktionsebenen<br />
enthalten Interfacebeschreibungen als eine Hierarchie zusammengesetzter Objekte. Aussagen über den<br />
Charakter der darin referenzierbaren Interfaceobjekte sind kaum zu finden. Es liegt anscheinend kein öffentlich<br />
zugängliches Metamodell hierfür vor; es findet sich jedoch eine Absichtserklärung der ADEPT-<br />
Entwickler, welche die Interfaceobjekte bis auf die Ebene <strong>von</strong> Input-Ereignissen und Zustandsautomaten<br />
spezifizieren wollten.<br />
Der Gesamtprozess des ADEPT-Ansatzes beginnt mit der Spezifikation <strong>von</strong> Aufgabenmodell und Nutzermodell.<br />
Eine Interface-Generator genannte Komponenten erzeugt aus Aufgaben- und Nutzermodell ein<br />
abstraktes UI-Modell. Dieses wird durch den UI-Generator in ein konkretes Oberflächenmodell transformiert.<br />
Im Ergebnis des ADEPT-Prozesses entsteht der UI-Quellcode für eine Programmiersprache. ADEPT<br />
selbst wurde mit Smalltalk implementiert und generiert standardmäßig Quellcode dieser Sprache.<br />
A.3.2 MASTERMIND<br />
MASTERMIND [120] ist eine Modellierungs- und <strong>Generierung</strong>sumgebung aus der Mitte der 1990er Jahre,<br />
Veröffentlichungen finden sich zwischen 1995 und 1998, der Name des Systems wird als „Models<br />
Allowing Shared Tools and Explicit Representations to Make Interfaces Natural to Develop“ erklärt. Zur<br />
Enstehungszeit <strong>von</strong> MASTERMIND lagen bereits einige Erfahrungen mit älteren MB-UID Werkzeugen<br />
und Ansätzen vor. Die Untersuchung <strong>von</strong> UIDE, ADEPT, HUMANOID und MECANO schienen einen<br />
kurz- oder mittelfristigen Erfolg des Paradigmas nicht erwarten zu lassen. Das Forschungsteam stellte sich<br />
daher die Frage, welche Schwächen denn diese Systeme hatten, die eine breite Anwendung verhinderten.<br />
Sie identifizierten in [120] drei Problemschwerpunkte: eine insgesamt mangelnde Flexibilität, sowie dürftige<br />
Qualität der Ergebnisse bei zumeist umständlicher Benutzung. Der Anspruch <strong>von</strong> MASTERMIND ist<br />
es, diese Probleme zu beheben oder zumindest im Ausmaß drastisch zu reduzieren.<br />
Der Lösungsvorschlag <strong>von</strong> MASTERMIND besteht darin, zum einen die Abstraktionsebenen zu reduzieren<br />
und zum anderen erprobte und verbreitete Technologien, anstelle <strong>von</strong> Insellösungen, einzusetzen. Daher<br />
sind viele Aspekte der Modellierung <strong>von</strong> MASTERMIND an CORBA angelehnt, einer damals aufstrebenden<br />
und auch heute noch relevanten OMG-Technologie. Prinzipiell finden sich auch hier die üblichen<br />
Modellarten der MB-UID; Application-, Task- und Präsentationsmodell werden verwendet.<br />
Die MASTERMIND-Umgebung strebt die Unterstützung verteilter Anwendungsentwicklung an. Dazu<br />
werden alle Modellinstanzen und Modellbeschreibungen zentral auf einem Modell-Server bereitgestellt.<br />
Alle Werkzeuge, Generatoren und Editoren greifen auf dieses einheitliche Repository zurück. Dank der<br />
einheitlichen CORBA-Schnittstelle zu den Modellen ist auch eine verhältnismäßig einfache Austauschbarkeit<br />
der Werkzeuge möglich.<br />
Eine andere Besonderheit <strong>von</strong> MASTERMIND ist die vordergründige Unterscheidung in Runtime- und<br />
Design-Time Modelle. Die Runtime-Modelle werden als komprimierte und kompilierte Variante der Design-<br />
Time Modelle dargestellt. Hauptzweck dieser expliziten Runtime-Modelle ist es die erzeugte Anwendung,
A.3. SYSTEME MIT AUFGABENMODELLIERUNGSHINTERGRUND 129<br />
durch Wegfall der sonst nötigen Modell-Interpretation, zu beschleunigen. Auf den Komprimierungsvorgang<br />
an sich wird nicht direkt eingegangen, so dass offen bleibt ob damit nicht ohnehin nur die kompilierten<br />
Versionen der CORBA-Objekte gemeint sind.<br />
Zum Application-Modell ist wenig zu sagen, es handelt sich um das Domänenmodell der Anwendung welches<br />
mit einer CORBA-IDL ähnlichen Sprache definiert wird. Dabei entsteht naturgemäß ein OO-typisches<br />
Modell mit Klassen, Attributen und Methoden. Interessanter ist das Aufgabenmodell. MASTERMIND verwendet<br />
den Begriff des Ziels nicht, wie oft üblich, als das Wurzelelement der Aufgabenhierarchie. Jedem<br />
einzelnen, auch atomaren, Task kann ein Ziel zugeordnet sein. Entweder textuell ausgedrückt oder als formalisierter<br />
Term, MASTERMIND bietet hierfür eine eigene Constraint-Sprache. Sofern das Ziel als Text<br />
angegeben wird handelt es sich um wenig mehr als Dokumentation. Terme hingegen werden zur Ausführungszeit<br />
im Kontext der Aufgabe ausgewertet und bestimmen darüber ob der Task überhaupt auszuführen<br />
ist. Ebenfalls vom Standardkonzept für Tasks abweichend ist, dass Aufgaben immer <strong>von</strong> vordefinierten<br />
Aufgabenprototypen erben. Als Beispiel wird eine Aufgabe „Email ausdrucken“ genannt, welche eine<br />
Spezialisierung der generischen Aufgabe „Ausdrucken“ ist. Eine öffentliche verfügbare Bibliothek dieser<br />
Aufgabenprototypen ist jedoch anscheinend nicht erhältlich. Auch in MASTERMINDs Aufgabenmodell<br />
werden Tasks zu Kategorien zugeordnet, in Task-Hierarchien strukturiert und die Abarbeitungsabfolge mittels<br />
temporaler Operatoren gesteuert.<br />
Wie das Aufgabenmodell wird auch MASTERMINDs Interface-Modell mit einer eigenen Sprache textuell<br />
spezifiziert. Im Interface-Modell werden die Interaktions-Objekte (UIO) der Anwendung beschrieben.<br />
Ähnlich der Situation bei den Tasks, muss jeder neudefinierte UIO-Typ <strong>von</strong> einem vordefinierten UIO-<br />
Prototypen erben. Die Beschreibungsebene der abstrakten Oberfläche entfällt in MASTERMIND, es werden<br />
nur konkrete UI-Widgets beschrieben. Layout und Aussehen der Widgets werden im Interfacemodell<br />
bereits pixelgenau beschrieben, auch dies ist eine bemerkenswerte Abweichung zu anderen MB-UID Ansätzen.<br />
Komplette <strong>Benutzungsoberflächen</strong> entstehen auch bei MASTERMIND durch Aggregationen <strong>von</strong><br />
UIOs. Verhältnismäßig viel Wert legen die Autoren noch darauf, dass im Interface-Modell nicht mit Tabellen,<br />
oder anderweitig verschachtelten horizontalen und vertikalen Boxen, gearbeitet wird, sondern mit<br />
Gitterstrukturen und Ausrichtungshilfslinien. Für die präsentierten Beispiele scheint das jedoch nicht besonders<br />
relevant zu sein, d.h. diese liessen sich auch mit der Tabellentechnik umsezten.<br />
Die Herstellung der Modellzusammenhänge wurde im ursprünglichen MASTERMIND-Toolkit an die den<br />
Modell-Server nutzenden Werkzeuge ausgelagert und nicht direkt betrachtet. In den späteren Veröffentlichungen<br />
z.B. in [116] aus dem MASTERMIND-Umfeld wurde dann das Aufgabenmodell nicht mehr<br />
betrachtet. Stattdessen wurde der Fokus wurde auf die Ablaufsteuerung der Benutzungsoberfläche gelegt.<br />
Hierzu wurden Dialogmodelle, konzeptionell vergleichbar den in Unterabschnitt 2.1.2 vorgestellten,<br />
in den Ansatz eingeführt. Über diese zusätzliche Modellart, und einer unter anderem dafür neugestalteten<br />
Runtime-Komponente, konnte dann auch der Zusammenhang zwischen Domänenmodell und UI-<br />
Beschreibung hergestellt werden.<br />
A.3.3 FUSE<br />
FUSE [111], die Formal User Interface Specification Environment, ist als Softwareentwicklungsumgebung<br />
konzipiert worden, in der eine Reihe <strong>von</strong> Werkzeugen zusammenspielt um <strong>Benutzungsoberflächen</strong> auf<br />
Basis formaler Spezifikationen zu generieren. Es ist eine Entwicklung der TU München aus der Mitte der<br />
1990er-Jahre.<br />
Auch FUSE benutzt Domänenmodell, Aufgabenmodell und Nutzermodell als Ausgangsmodelle der MB-<br />
UID. Die Kombination der Informationen aus diesen Teilmodellen ergibt jedoch zunächst kein abstraktes
130 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Modell der Oberfläche. Eine Besonderheit des FUSE-Ansatzes ist es, zunächst Datenfluss und Abarbeitungsreihenfolge<br />
zu spezifizieren, bevor mit der Erzeugung der eigentlichen UI begonnen wird. Die dabei<br />
notwendigen Transformationen werden wesentlich durch sogenannte Design-Guidelines gesteuert. Das<br />
Transformationsergebnis kann und soll in jedem Schritt durch menschliche Nacharbeit angepasst werden.<br />
Sowohl die Modelle als auch die Guidelines werden formal, mit einer eigenen Sprache, textuell spezifiziert.<br />
FUSE generiert keinen Quellcode, sondern interpretiert seine CUI-Instanzen zur Laufzeit.<br />
Das FUSE-Framework besteht aus vier Teilkomponenten mit unterschiedlichen Verantwortlichkeiten welche<br />
aufeinander aufbauen. Das FLUID-Subsytem, FormaL User Interface Development, spielt die Rolle<br />
eines automatischen Dialog-Designers. Durch Zusammenführen <strong>von</strong> Dialogdesign-Guidelines und den<br />
drei Basis-Modellen werden die statischen und dynamischen Eigenschaften einer Oberfläche ermittelt und<br />
als sogenannte logische Oberfläche formalisiert. Zur Formalisierung werden Hierarchic Interaction graph<br />
Templates - HIT - benutzt. HIT sind eine Kombination aus dynamischen attributierten Grammatiken und<br />
Datenflussdiagrammen, ergänzt um Ereignis- und Timing-Konzepte. Die Herangehensweise an die Modellierung<br />
ist ähnlich jener der strukturierten Analyse [29]: Eine HIT-Spezifikation, und damit die logische<br />
Oberflächenspezifikation, ist ein Baum <strong>von</strong> Templates. Den Templates werden die im Aufgabenmodell<br />
identifizierten Funktionen zugeordnet. Ebenfalls hinterlegt werden die Datenflüsse zwischen den Funktionen,<br />
diese Information lässt sich aus dem Domänenmodell ableiten. Ein Template ist also zunächst einmal<br />
ein Datenflussdiagramm, allerdings bietet die HIT-Notation natürlich noch weitergehende Syntaxkonstrukte.<br />
Außerdem wird in dem Template-Baum definiert in welcher Relation die jeweiligen Untertemplates<br />
eines Knotens stehen. Letztlich bilder der Baum eine hierarchische Dekomposition der Zieloberfläche und<br />
beschreibt welche Templates wie zu einem User-Interface aggregiert werden sollen.<br />
Die UI-Darstellung wird durch die Komponente BOSS, das BedienOberflächen-SpezifikationsSystem,<br />
durchgeführt. Layout-Guidelines nutzen die logische Oberflächenbeschreibung um für die einzelnen Funktionen<br />
ein passendes Interaktionsobjekt zu identifizieren. Dies geschieht durch Auswertung der Datenflüsse,<br />
wodurch sich Typ und Kardinalitäten der Ein- und Ausgabeparameter ergeben. Daraus kann, ähnlich<br />
der Idee bei UIDE, ein passendes Interaktionsobjekt ausgewählt werden. Durch Austauschen der relevanten<br />
Guidelines können verschiedene Oberflächen für die selbe logische Oberfläche erzeugt werden.<br />
Die Komponente PLUG-IN,PLan-based User Guidance for Intelligent Navigation, erstellt aus dem Aufgabenmodell<br />
und der logischen Oberfläche dynamisch Hilfeseiten, Zustandsautomaten der Anwendung<br />
und daraus wiederum animierte Durchläufe durch die Anwendung. Die vierte Komponente wird als FIRE,<br />
Formal Interface Requirements Engineering, bezeichnet. Dabei handelt es sich um graphische Editoren<br />
die die Bearbeitung der sonst eigentlich textuellen Spezifikationen erleichtern.<br />
A.3.4 TADEUS<br />
Unter dem Namen TADEUS sind in den 1990er Jahren zwei Systeme, getrennt jedoch in Zusammenarbeit,<br />
entwickelt worden. Eines an der Universität Rostock und eines an der Johannes Kepler Univerität Linz.<br />
Hier soll das Rostocker TADEUS [108] erläutert werden, da die darin vertretenen Ideen seit langem Grundlagen<br />
der Arbeit am Lehrstuhl Softwaretechnik sind. TADEUS, Task based Development of User interface<br />
Software, teilt den UI-Entwicklungsprozess in drei Phasen. In der Ersten Phase, der Bedarfsanalyse werden<br />
eine Zielhierarchie, Klassendiagramme und Nutzermodelle spezifiziert. Die Definition folgt dem üblichen<br />
Schema, ein Ziel wird dabei durch ein Tupel aus Teil-Aufgaben, betroffenen Rollen und zu bearbeitenden<br />
Domain-Objekten beschrieben. Es erfolgt eine hierarchische Dekomposition der Nutzerziele mit Definition<br />
expliziter temporaler Beziehungen zwischen den Zielen. Dieses Vorgehen entspricht dem der auch <strong>von</strong><br />
ADEPT genutzten Task Knowledge Structures.
A.3. SYSTEME MIT AUFGABENMODELLIERUNGSHINTERGRUND 131<br />
Das Domain-Modell wird in TADEUS objektorientiert per OMT 5 definiert. Die Beziehungen zwischen<br />
Tasks und Domain-Objekten werden dabei explizit modelliert.<br />
Das User-Modell beschreibt potentielle oder existierende Nutzergruppen in den modellierten Domains. Es<br />
definiert die verfügbaren Rollen und stellt Beziehungen zwischen Rollen und Aufgaben her. Die Rollen<br />
können in Hierarchien eingeordnet sein. Beschrieben werden sie durch taskabhängige oder -unabhängigen<br />
Eigenschaften. So kann z.B. die Ausprägung der Nutzererfahrung mit interaktiven Systemen eine Rolle<br />
charakterisieren.<br />
In der zweiten Phase des TADEUS-Ansatzes, dem Dialog-Design, wird die Zuordnung der einzelnen<br />
Tasks zu den jeweiligen Views vorgenommen. Diese Zuordnung erfolgt durch Annotationen im Aufgaben-<br />
Modell. Neben der Einteilung in eine bestimmte Sicht wird für jeden Task seine Dialogform bestimmt.<br />
Ein Task zur Dateneingabe enthält etwa die Dialogform ’data input’ zugeordnet. TADEUS’ Dialog-Modell<br />
verwendet die Notation der Dialog-Graphen [107].<br />
Die eigentliche Interface-<strong>Generierung</strong> erfolgt in der dritten Phase. Zunächst erfolgt die Festlegung <strong>von</strong><br />
Standardlayouteigenschaften für das ganze Projekt, z.B. Details wie Fensterhintergrundfarbe usw. Danach<br />
wird das Dialog-Modell abgearbeitet, dabei wird für jede im Dialog-Graph enthaltene View die Task-<br />
Dialogform in abstrakte Interaktionsobjekte (AIO) umgesetzt. Die diversen Dialogformen können Subtypen<br />
definiert haben, welche zur speziellen AIO-Umsetzung verwendet werden. Für die beispielhaft erwähnte<br />
Dialogform ’data input’ existieren etwa die folgenden Untertypen-Mappings. Der Sub-Typ Free wird auf<br />
das AIO:input field abgebildet, der Subtyp 1:m als AIO:single selector (Einfachauswahl) und der Sub-Typ<br />
n:m als AIO:multiple selector (Mehrfachauswahl) in die abstrakte Oberflächenspezifikation übernommen.<br />
Der letzte Schritt auf dem Weg zu einer Oberfläche ist die Umsetzung der AIO in konkrete Interaktionsobjekte.<br />
Die Umsetzung erfolgt unter zu Hilfenahme sogenannter Interaction Tables und kann neben<br />
1:1 Abbildungen unter Beachtung <strong>von</strong> zusätzlichen Randbedingungen ablaufen. Randbedingungen dafür<br />
kann z.B. eine vorgegebene Maximalzahl <strong>von</strong> Elementen in einer GroupBox mit RadioButtons, bei deren<br />
Überschreitung dann auf die Darstellungsform ListBox ausgewichen wird. Der Mechanismus ist grob<br />
vergleichbar mit den Layout-Priosierungsalgorithmen <strong>von</strong> DON.<br />
Das Ergebnis des TADEUS-Ansatzes ist eine Schnittstellenbeschreibung welche interpretiert werden muss,<br />
Anwendungslogik für eine ablauffähige Anwendung wird nicht integriert.<br />
Das andere TADEUS wurde unter der Leitung <strong>von</strong> Stary in Linz zu TADEUS++ [114] entwickelt. Außer<br />
dem Namen gibt es inzwischen kaum noch Gemeinsamkeiten der beiden Systeme.<br />
A.3.5 TRIDENT<br />
Das TRIDENT [138]-System, Tools for an interactive development environment, <strong>von</strong> 1995 entstand mit<br />
dem Fokus auf interaktive geschäftsorientierte Anwendungen. Dabei wurde darauf hingearbeitet im Designprozess<br />
eine größtmögliche Automatisierung zu erreichen. Dennoch beginnt auch bei TRIDENT die<br />
Entwicklung mit der Aufgabenanalyse und dem Aufstellen eines Domänenmodells. Das TRIDENT-Aufgabenmodell<br />
entspricht den Anforderungen der TKS-Methodik.<br />
Besondere Beachtung erhalten bei TRIDENT diejenigen Aufgaben, die als Interaktion-Aufgaben kategorisiert<br />
werden. Solcherart werden die Aufgaben klassifiziert, die die Nutzer direkt durch Nutzung des zu<br />
erstellenden Systems ausführen. Sie werden mittels sogenannter Aktivitätsverkettungsgraphen, bzw. activity<br />
chaining graph (ACG), spezifiziert. Ein solcher ACG beschreibt dabei den Informationsfluß, also<br />
die Ein- und Ausgabedaten, zwischen den, im Domänenmodell definierten, Funktionen der Anwendung.<br />
5 Object Modeling Technique, inzwischen in UML aufgegangen
132 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Die im ACG verketteten Funktionen sind die Operationen deren Ausführung, gemäß der Semantik des<br />
Aufgabenmodells, zur Zielerreichung nötig ist. Auch hier bietet sich wiederum der Vergleich zu den Datenflussdiagrammen,<br />
ähnlich dem Vorgehehn bei der FUSE-Methodik, an.<br />
Zur Erzeugung einer Benutzungsoberfläche nutzt auch TRIDENT das Konzept der Interaktionsobjekte.<br />
Es werden konkrete und abstrakte Interaktionsobjekte (AIO/CIO 6 ) unterschieden. Das CIO-Modell TRI-<br />
DENTs definiert reale UI-Komponenten wie Labels, Buttons oder diverse Widgets.<br />
Ausgehend <strong>von</strong> der Aktivitätsverkettung im ACG werden Darstellungseinheiten (PU) 7 identifiziert. Eine<br />
Darstellungseinheit ist eine Menge <strong>von</strong> gleichzeitig darzustellenden Aufgaben. Ein Expertensystem weist<br />
den Aufgaben geeignete abstrakten Interaktionsobjekte zu. Zur Laufzeit werden die AIOs durch CIOs der<br />
Ausführungsplattform dargestellt.<br />
Das TRIDENT-System ist darüber hinaus auch ein dreigliederiges Architekturmodell. Dieses besteht aus<br />
Interaktions-, Steuerungs- und Anwendungsobjekten und somit aus den gleichen Teilen wie das bekannte<br />
MVC 8 -Pattern. Im Gegensatz zu diesem wird jedoch der Fokus auf die Hierarchie der Steuerungsobjekte<br />
und deren Verantwortlichkeiten gelegt, während die Interaktions- und Anwendungs(modell)objekte nur auf<br />
der Blattebene der CIOs eine Rolle spielen.<br />
A.3.6 L-CID<br />
Ein regelmäßig wiederkehrendes Problem der bis hierher vorgestellten Systeme ist es, durch Benutzung<br />
<strong>von</strong> Heuristiken, Algorithmen oder Expertenwissen einer Aufgabe oder Funktion eine passende Darstellungsart<br />
zuzuordnen. Ein Ansatz zur Lösung dieses Zuordnungsproblems ist es, Methoden der Künstlichen<br />
Intelligenz darauf anzuwenden. L-CID [96] aus dem Jahre 1991 macht den Versuch die Technik des machinellen<br />
Lernens (machine learning) zur Ermittlung optimierter Lösungen einzusetzen. L-CID generiert<br />
seine Interface-Vorschläge aus drei Basismodellen; es nutzt Aufgaben-, Domänen- und Nutzermodell.<br />
Verwendet wurde ein expertengestützter Lernansatz 9 . Sämtliche verfügbaren Präsentationstechniken wurden<br />
in einem Pool zur Auswahl gestellt und das System wählte mit Hilfe diverser Heuristiken eine passende<br />
Präsentationstechnik für die anstehende Aufgabe aus. Passte keine Heuristik, z.B. für eine bis dato<br />
unbekannte Aufgabe, war die Auswahl zufällig. Menschliche Experten bewerten diese getroffene Auswahl<br />
und L-CID nutzt diese Bewertung, um die Auswahl beim nächsten Auftreten dieses Tasks zu optimieren.<br />
Der Schwerpunkt bei L-CID ist insgesamt nicht auf einen Interface-Generator gelegt, sondern auf<br />
die Erstellung einer hinreichend großen Wissensbasis für die Zuordnung sinnvoller Visualisierungen bzw.<br />
Visualisierungstechniken zu Aufgaben.<br />
A.3.7 MECANO, MOBI-D<br />
Das MECANO-Projekt [93] der Universität Stanford <strong>von</strong> 1996 ist ein weiterer Versuch, geeignete Modelle,<br />
Modellierungssprachen und eine Laufzeitumgebung für modellbasierte Oberflächenentwicklungen zu<br />
entwickeln. Es wurden die wesentlichen Ideen der bis dato bekannten Vorgänger zusammen gefasst und<br />
eine generische Sprache (MIMIC 10 ) zur Spezifikation <strong>von</strong> Interface-Modellen entwickelt. MIMIC ist eine<br />
textuelle domain-spezifische Sprache (tDSL), deren Grammatik in der BNF-Notation veröffentlicht wurde.<br />
6 Concrete Interaction Object<br />
7 Presentation Units<br />
8 Model View Controller<br />
9 entsprechend einem Blackboard-System<br />
10 MECANO Interface Language
A.4. XML DERIVATE 133<br />
Das MECANO-Projekt stellt die zu erstellenden Interfaces in den Mittelpunkt. Jede dieser Schnittstellen<br />
der Mensch-Maschine-Kommunikation wird durch Instanzen <strong>von</strong> sechs Modellarten definiert. Dies sind<br />
Aufgaben-, Präsentation-, Dialog-, Design-, Nutzer- und Domänenmodell. Es ist jedoch nicht zwingend<br />
notwendig alle diese Teilmodelle für ein Interface zu instanziieren. Die Instanzen der Teilmodelle und deren<br />
Zusammenhänge werden mit MIMIC beschrieben. Eine Besonderheit der MECANO-Teilmodelle ist,<br />
dass in allen eine hierarchische Ordnung vorgenommen wird. Allgemein üblich ist dies nur für Aufgabenmodelle.<br />
Neben den damals bereits üblichen Angaben in einem hierarchischen Aufgabenmodell wurde bei MECA-<br />
NO <strong>von</strong> Anfang an vorgesehen, explizite Vor- und Nachbedingungen für die Durchführung einer Aufgabe<br />
zu notieren. Das Domänen-Modell definiert nur Typ und Relationen der Objekte der Anwendungsdomäne,<br />
deren etwaiige Methoden werden nicht mitmodelliert. Mittels des Präsentationsmodells werden die<br />
zu Verfügung stehenden Interaktionskomponenten und im Nutzermodell die Systemnutzer definiert. Die<br />
Metamodelle beider Modellarten sind isomorph dem des Domänenmodells. Die Interface-Komponenten<br />
werden daher wie beliebige Objekte beschrieben, im Gegensatz zu anderen Ansätzen findet keine Festlegung<br />
auf eine bestimmte Interface-Modalität statt. Das Nutzermodell ist in vielen anderen Ansätzen ohnehin<br />
unterspezifiziert; der MECANO-Gedanke Nutzer als methodenlose Objekte zu behandeln scheint eine<br />
gangbare Formalisierung zu sein.<br />
Die Interaktion wird bei MECANO durch Kommandos gesteuert. Diese werden im Dialog-Modell definiert.<br />
im Gegensatz zur typischen Verwendung dieses Begriffes, werden in diesem Modell jedoch nicht die<br />
Transitionen zwischen verschiedenen Dialogen einer Anwendung beschrieben. Kommandos sind Aktionen<br />
die ein bestimmtes Nutzerziel, aus dem Aufgabenmodell, erfüllen und deren Ausführung Konsequenzen<br />
für die Anwendungsobjekte hat. Diese Auswirkungen werden über Vor- und Nachbedingungen oder auch<br />
explizite Wertsetzungen modelliert. Kommandos können, da sie hierarchisch organisiert sind, verschachtelt<br />
werden.<br />
Das Design-Modell stellt die Assoziationen zwischen den Teilmodellen. So wird hier z.B. der Zusammenhang<br />
zwischen Aufgaben und Domänenobjekten hergestellt. Ebenfalls wird entschieden, mit welchen<br />
Präsentationskomponenten die Kommandos bzw. Aufgaben visualisiert werden sollen.<br />
Zur Interpretation und Darstellung der Modellierungsergebnisse kommt MOBI-D 11 [97] zum Einsatz. Es<br />
wurde im Rahmen desselben Projektes entwickelt. MOBI-D dient zur Interpretation der MIM-Schnittstellenbeschreibungen.<br />
Dazu war zwingend eine Festlegung <strong>von</strong> Interface-Modalität und Zielplattform notwendig.<br />
Die Entscheidung fiel, wenig überraschend auf Standard-WIMP Oberflächen. Zur Implementierung<br />
wurden C++ Toolkits benutzt. Die mit dem MIM/MOBI-D Ansatz erstellten <strong>Benutzungsoberflächen</strong><br />
wurden praktisch eingesetzt; mit MOBI-D sind die diverse Anwendungen im Bereich der militärischen und<br />
medizinischen Logistik erstellt worden. Ein anderes weitreichendes Ergebnis des MECANO-Projektes ist<br />
die Schnittstellenbeschreibungssprache XIML, siehe Seite 18, sie ist wesentlich <strong>von</strong> den Erkenntnissen des<br />
Projektes beeinflusst bzw. daraus hervorgegangen.<br />
A.4 XML Derivate<br />
A.4.1 TERESA<br />
Viel Wert legt wird bei TERESA auf die Multi-Plattform Idee gelegt. Der Grundtenor des TERESA-<br />
Ansatzes ist: „One Model, Many Interfaces“. Für die bis dato allgemein akzeptierten User Interface-<br />
11 Model based interface designer
134 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Modellierungsebenen wurden XML-Äquivalente erstellt.<br />
Dieses „eine Modell“, sozusagen das Kernmodell, ist ein Concurrent Task Tree (CTT), ein Aufgabenmodell.<br />
Das Metamodell für CTT wurde in [82], dort Abbildung 3, veröffentlicht; aktuelle Versionen sind<br />
bei [121] verfügbar. Das im hiesigen M6C-Ansatz benutzte Metamodell ist durch die CTT-Arbeiten deutlich<br />
inspiriert, in Abbildung 2.2 wird dessen aktueller Stand vorgestellt. Auch der CTTE genannte Editor<br />
für die TERESA-Aufgabenmodelle hat beachtliche Verbreitung gefunden und wird oftmals zur Visualisierung<br />
<strong>von</strong> Aufgabenmodell benutzt.<br />
Die endgültige Umsetzung eines Interfaces ist nicht Kern <strong>von</strong> TERESA. So existiert keine eigene CUI<br />
Sprache, sondern es werden je nach Modalität passende Sprachen als Ausgabeformat gewählt. Etwa VoiceXML<br />
für Sprachinterfaces oder diverse XHTML-Varianten für WIMP-artige GUIs. Die Erzeugung <strong>von</strong><br />
deren XML-Dokumenten erfolgt durch mehrstufige Modell-Transformationen, ausgehend <strong>von</strong> den CTT-<br />
XML-Dokumenten.<br />
Das TERESA-Projekt untersucht besonders Möglichkeiten zur Verschiebung <strong>von</strong> Oberflächen zwischen<br />
Geräten, sogenannte „Migratory Interfaces“. Die Prozessdarstellung in Abbildung A.2 zeigt wie sich die<br />
TERESA-Autoren diese Migration vorstellen. In der Darstellung werden die Komponenten und der Informationsfluss<br />
bei einer Migration der Benutzungsoberfläche <strong>von</strong> einer Desktop-Applikation an eine stimmenbasierte<br />
PDA-Steuerung abgebildet.<br />
Wegen der unterschiedlichen UI-Modalität, GUI gegenüber Stimme, sind die beiden Benutzungsschnittstellen<br />
nicht Instanzen desselben abstrakten Oberflächenmodells. Aber das Aufgabenmodell ist in beiden<br />
Geräten dasselbe, es muss daher die Rolle des Fixpunktes der Zuordnung <strong>von</strong> UI-Verantwortlichkeiten<br />
übernehmen. Zur eigentlichen Migration sind sowohl die beiden Aufgabenmodellinstanzen als auch die<br />
konkreten UI-Schnittstellen zu synchronisieren.<br />
Synchronisation bedeutet hier, sie in einen semantisch äquivalenten Status zu versetzen. Eine Aufgabe<br />
die durch Heuristiken und Algorithmen zur Statuserkennung sowie automatischen Transformationen<br />
durchgeführt werden soll. Die vorläufigen Ergebnisse <strong>von</strong> TERESA und aktuelle Arbeiten etwa des DAI-<br />
Labors [31] lassen jedoch vermuten, dass in diesem Bereich noch viel Arbeit offen, und der aufgabenmo-<br />
Desktop<br />
GUI<br />
Tasks<br />
Abstrakte<br />
UI<br />
XHTML<br />
Task Mapping<br />
Engine<br />
Statusermittlung<br />
und Anpassung<br />
Tasks<br />
Abstrakte<br />
UI<br />
Abbildung A.2: Schrittfolge im TERESA-Migrationsprozess zur Übertragung der Benutzeroberfläche,<br />
nach [13]<br />
PDA<br />
X+V
A.4. XML DERIVATE 135<br />
dellzentrierte Ansatz möglicherweise nicht der fruchtbringendste ist.<br />
A.4.2 UIML<br />
UIML [1], <strong>von</strong> 1999, ist der Urahn der Forschungssprachen zur deklarativen Oberflächenbeschreibung mit<br />
XML. Die Autoren sehen UIML als eine:<br />
[..] solution [..] to build interfaces with a single, universal language free of assumptions about<br />
appliances and interface technology.<br />
In diesem Selbstverständnis ist UIML eine, an keine Interface-Modalität oder Geräteklasse gebundene,<br />
Universalsprache.<br />
Der Fokus der UIML-Entwicklung lag stets auf Oberflächen für WWW-Anwendungen. So lag bereits seiner<br />
Entstehung die Beobachtung zugrunde, das Anzahl und Diversität der für Internet-Zugang zur Verfügung<br />
stehenden Geräte „explodierenden“ [1]. Viele der um die Jahrtausendwende vermarkteten Gerätschaften<br />
und Technologien wurden über proprietäre Sprachen gesteuert. Aus der Sicht der UIML-Entwickler war<br />
das der „Turmbau zu Babel“ im Bereich der Benutzungsschnittstellen. Und ihre neuentwickelte Sprache<br />
die Lösung dieses Problems.<br />
Die Kernidee <strong>von</strong> UIML ist es, Benutzungsschnittstellen generisch zu beschreiben und die Anpassung an<br />
den tatsächlichen Nutzungskontext in Style-Definitionen auszulagern. Auf diesem Weg kann die Ansteuerung<br />
der UI-Komponenten plattformunabhängig erfolgen und der weitgehend der gleiche Quellcode für<br />
Schnittstellendeklaration und deren Datenanbindung genutzt werden.<br />
Eine deklarative Oberflächenbeschreibung mit UIML besteht aus sechs Teilen, Abbildung A.3 stellt diese<br />
dar. Der generische Kern der UIML-Beschreibung erfolgt in der Schnittstelle. Im Strukturmodell werden<br />
die Teile deklariert aus welchen sich das User Interface zusammensetzt. Dieser Teil entspricht in der<br />
Idee einer abstrakten Oberfläche im CAMELEON-Sinn. Das Gestaltungsteilmodell definiert Anzeigeeigenschaften<br />
für die im Strukturmodell definierten UI-Teile. Hier erfolgen gemäß [128] Angaben zu Farben<br />
oder Schriftarten und anderen geräteunabhängig definierbaren Eigenschaften. In den meisten Fällen werden<br />
die Informationen in diesem Modell implizit die Ausgabemodalität fixieren; Festlegungen zur Schriftfarbe<br />
sind etwa bei Sprachinterfaces gegenstandslos. Den UI-Teilen kann bereits auf der Ebene der UIML-<br />
Deklaration ein darzustellender Inhalt zugewiesen sein. Ein Beispiel der Spezifikation [128] nutzt diesen<br />
Mechanismus um Schaltflächenbeschriftungen zu internationalisieren. Prinzipiell können den UI-Teilen<br />
aber auch komplexere Inhalte, wie Bilder, Filme oder Sprachdateien, zugeordnet werden.<br />
Darstellung<br />
Mapping<br />
(Gerät/Plattform<br />
UI-Metapher)<br />
Schnittstelle<br />
Struktur<br />
Gestaltung<br />
Inhalt<br />
Verhalten<br />
Logik<br />
(Anwendung<br />
Datenquellen)<br />
Abbildung A.3: UIML – Teilmodelle und Zusammenhänge nach [1]
136 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
Das Verhalten einer Benutzungsschnittstelle kann vergleichsweise weitreichend innerhalb eines UIML-<br />
Dokumentes definiert werden. Über das integrierte Event-Konzept in Verbindung mit Schaltbedingungen,<br />
Regeln und Aktionsdefinitionen können einfache Algorithmen umgesetzt werden. Selbstverständlich handelt<br />
es sich bei UIML dennoch nicht um eine Programmiersprache. In diesen Algorithmendeklarationen<br />
werden Funktionen referenziert deren Implementierung im Logik-Teilmodell auf real existierende Anwendungslogik<br />
der Nutzungsumgebung abgebildet wird.<br />
Das Mapping der deklarierten UI-Teile auf die Widgets einer Zielplattform wird schließlich im Präsentationsmodell<br />
beschrieben. Diese Art Abbildungen werden bei UIML als „Vocabulary“ , also etwa Wortschatz,<br />
bezeichnet. Einmal definierte Vocabularies lassen sich verhältnismäßig einfach als Standardmappings für<br />
die Zielplattform wiederverwenden. Für die Sprachversion 3.1 stehen bei [1] elf Vocabularies zur Verwendung<br />
bereit. Sie ermöglichen die Verwendung <strong>von</strong> UIML zur Deklaration <strong>von</strong> Oberflächen mit folgenden<br />
FUIs: HTML mit CSS, WML, Java-AWT und Java-Swing, VoiceXML sowie einer GenericJH genannten<br />
Kombination aus Java und HTML.<br />
UIML konnte sich letztlich nicht durchsetzen. Über die Gründe lässt sich nur spekulieren. Beigetragen dazu<br />
hat sicherlich der Fakt, dass die Qualität der vorhandenen UIML-Renderer der eigentlichen Mächtigkeit<br />
der Sprache nicht gerecht wurde. Die Art und Weise die Mappings zu definieren, als zwar austauschbare<br />
aber dennoch 1:1-Abbildungen, limitiert die Einsetzbarkeit weiter. Dedizierte Transformationen mit dafür<br />
geeigneten Model-To-Model und Model-To-Text Sprachen scheinen eine bessere Steuerbarkeit und im<br />
Endeffekt eine qualitativ bessere Benutzungsoberfläche zu ermöglichen.<br />
A.5 Sonstiges<br />
A.5.1 CSS<br />
CSS, ist eine standardisierte [25] Sprache zur Festlegung <strong>von</strong> Designeigenschaften über Schlüssel-Wert<br />
Beziehungen. Im CSS-Standard werden die Schlüsselnamen und der mögliche Wertebereich definiert. Die<br />
Verfügbarkeit einzelner standardisierter Schlüssel ist abhängig <strong>von</strong> der eingesetzten Sprachversion.<br />
Ausdrücke der CSS bestehen aus einem Selektor-Ausdruck, zur Identifikation und Auswahl der auszuzeichnenden<br />
Elemente siehe dazu Tabelle A.2, und einer Auflistung der Eigenschaften welche den so ausgewählten<br />
Elemente zugeordnet werden. Die Selektor-Ausdrücke erwarten implizit eine Baumstruktur der<br />
Gastsprache, mit der Möglichkeit an den einzelnen Knoten benannte Eigenschaften zu notieren. Mit anderen<br />
Worten eine XML-Struktur. Listing A.3 zeigt im oberen Teil die Grundstruktur eines CSS-Ausdruckes.<br />
Innerhalb eines CSS-Dokumentes können beliebig vieler solcher Blöcke definiert sein. Der Zweite CSS-<br />
Block in Listing A.3 definiert einen Selektor für alle Kindelemente eines Opel-Elementes dessen direkte<br />
Kinder ein motor-Attribut mit dem Wert "benzin" aufweisen. Im anschließenden XML-Beispiel würde damit<br />
der Knoten Omega selektiert werden, und für seine visuelle Darstellung die Eigenschaft Textfarbe:Rot<br />
gesetzt werden.<br />
✞ ☎<br />
Selektormuster {<br />
Eigenschaft 1: Wert für Eigenschaft 1;<br />
Eigenschaft 2: Wert für Eigenschaft 2;<br />
...<br />
Eigenschaft n: Wert für Eigenschaft n;<br />
}<br />
Opel *[motor="Benzin"] {
A.5. SONSTIGES 137<br />
color: red;<br />
}<br />
<br />
farblos<br />
<br />
Dieser Text wird Rot<br />
ebenfalls keine explizite Farbzuweisung<br />
<br />
<br />
✝ ✆<br />
Listing A.3: Syntaxstruktur und beispielhafte Verwendung <strong>von</strong> CSS<br />
A.5.2 JavaScript<br />
Bei JavaScript, inzwischen als Derivat des als ECMA-Standard 262 spezifizierten ECMAScript [33] klassifiziert,<br />
handelte es sich ursprünglich um eine schwach getypte objekt-orientierte Skriptsprache. Der Einsatzzweck<br />
bei seiner Inkarnation um 1996, Interaktion auf sonst statischen HTML-Webseiten, ist auch<br />
heute noch die dominante Verwendung. Im Laufe seiner Evolution wurde JavaScript unter anderem um<br />
funktionale Aspekte erweitert, zusätzlich ist ebenfalls die Programmierung nach dem imparativen Paradigma<br />
möglich. Seine Syntax ist an diejenige <strong>von</strong> C angelehnt, es finden sich jedoch auch Einflüsse anderer<br />
Sprachen, beispielsweise aus Pascal die Schlüsselworte function zur Deklaration <strong>von</strong> Sub-Routinen oder<br />
var zur Deklaration und Initialisierung <strong>von</strong> Variablen.<br />
A.5.3 Einbettung CSS, Javascript und XUL<br />
Der Quellcode aus Listing A.4 zeigt die Verwendung <strong>von</strong> CSS und JavaScript in einem kleinen XUL-<br />
Beispiel. Ein Renderer erstellt aus dieser UI-Beschreibung ein Fenster mit einer Schaltfläche. Diese ist<br />
mit einem blauen Schriftzug „Hallo“ bezeichnet. Sobald diese Schaltfläche angetippt wird, entsteht ein<br />
Click-Event welcher im onclick-Eventhandler abgefangen wird. Die Abarbeitung des Eventhandlers lässt<br />
ein Hinweisfenster mit dem Text „Welt“ erscheinen. Bei Listing A.4 handelt es sich also um ein typisches<br />
Selektor-Pattern Bedeutung<br />
* jedes Element<br />
E jedes Element vom Typ E<br />
E F jedes Element vom Tyo F unterhalb eines Element vom Typ E<br />
E > F jedes Element vom Typ F das ein Kindknoten eines Elementes vom Typ E ist<br />
E: jedes Element vom Typ E das die Bedingungen der benannten Pseudoklasse erfüllt, z.B.:<br />
E:first-child jedes Element vom Typ E das das 1. Kind seines Vaterknoten ist<br />
E:focus jedes Element vom Typ E das während bestimmter Nutzeraktionen im fokussiert ist<br />
E:lang(c) jedes Element vom Typ E in der natürlichen Sprache c<br />
F + E jedes Element E dessen Vorgänger ein Element vom Typ F ist<br />
E[foo] jedes E dessen Attribut foo gesetzt ist<br />
E[foo="bar"] jedes Element E dessen Attribut "fooäuf den Wert "bar"gesetzt ist<br />
E#foobar jedes Element vom Typ E mit der ID "foobar", Syntaxabkürzung für [id="foobar"]<br />
Tabelle A.2: Syntaxelemente für Selektorausdrücke in CSS, nach [25]
138 ANHANG A. SYSTEM- UND SPRACHBESCHREIBUNGEN<br />
„Hallo Welt“ Einführungsbeispiel.<br />
✞ ☎<br />
<br />
<br />
<br />
✝ ✆<br />
Listing A.4: XUL-Minimalbeispiel mit CSS und JavaScript<br />
Die Anwendung der JavaScript-Kommandos für die Navigationsinstruktionen bei der <strong>Generierung</strong> des<br />
Mockup-Prototypen aus dem Dialoggraph, siehe Unterabschnitt 2.1.2, ist ein weiteres Beispiel für die<br />
Einbettung externer Sprachen in XUL.
Anhang B<br />
Quelltexte<br />
B.1 PLML<br />
B.1.1 Grammatik für die Sprachversion 1.1<br />
✞ ☎<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
140 ANHANG B. QUELLTEXTE<br />
label CDATA #REQUIRED<br />
><br />
<br />
<br />
<br />
<br />
<br />
<br />
✝ ✆<br />
Listing B.1: PLML DTD, Sprachversion 1.1
B.1. PLML 141<br />
B.1.2 Grammatik der Sprachversion 1.5<br />
✞ ☎<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
142 ANHANG B. QUELLTEXTE<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
✝ ✆<br />
Listing B.2: PLML DTD, Sprachversion 1.5
B.1. PLML 143<br />
B.1.3 xText-Grammatik für PLML 1.5<br />
✞ ☎<br />
grammar de.unirostock.informatik.swt.patterns.PLML with org.eclipse.xtext.common.Terminals<br />
generate plml "http://wwwswt.informatik.uni−rostock.de/deutsch/Mitarbeiter/andreas/uri/plml/1/"<br />
Model: catalog=CatalogDef (categories+=CategoryDef)* (pattern+=Pattern)*;<br />
PatternDescription:<br />
confidence=Confidence<br />
evidence=Evidence<br />
problem=Problem<br />
relations=RelatedPatterns<br />
(alias+=Alias)*<br />
(_context=Context)? //Umbenannt, da sonst Namenskollision mit OCL−Syntax bei M2T mit Acceleo<br />
(diagram=Diagram)?<br />
(forces=Forces)?<br />
(illustration=Illustration)?<br />
(implementation=Implementation)?<br />
(literature=Literature)?<br />
(solution=Solution)?<br />
(synopsis=Synopsis)?;<br />
MasterData: "MasterData" "{"<br />
author=Author<br />
("Category" category=[CategoryDef|(PATTERN_ID)])?<br />
(credits=Credits)?<br />
creationDate=CreationDate<br />
(lastModified=LastModifiedDate)?<br />
revision=Revision<br />
"}";<br />
CategoryDef: "CategoryDef" "{"<br />
name=PATTERN_ID //Attribut heisst name, um keinen Extraaufwand für Referenzierungen zu haben<br />
(hasLabel?="label=" label=STRING)?<br />
(subCategory+=CategoryDef)*<br />
"}";<br />
Alias: "Alias" aliasId=STRING (hasCollection?="collection=" collection=PATTERN_ID)?;<br />
Author: "Author" text=STRING;<br />
CatalogDef: "Catalog" name=PATTERN_ID (label=STRING)? masterData=MasterData;<br />
Confidence: "Confidence" (zero?="0"|one?="*"|two?="**");<br />
Context: "Context" (hasURL?="url=" url=URL)? (text=STRING)?;<br />
CreationDate: "CreationDate" date=DATE;<br />
Credits: "Credits" text=STRING;<br />
Diagram: "Diagram" (hasURL?="url=" url=URL)? (text=STRING)?;<br />
Evidence: "Evidence" "{" (examples+=Example)* (rationale=Rationale)? "}";<br />
Example: "Example" (description=STRING)? (hasURL?="url=" url=URL)?;<br />
Forces: "Forces" text=STRING;<br />
Illustration: "Illustration" (hasURL?="url=" url=URL)? text=STRING;<br />
Implementation: "Implementation" text=STRING;
144 ANHANG B. QUELLTEXTE<br />
LastModifiedDate: "LastModified" date=DATE;<br />
Literature: "Literature" "{" references+=Reference+ "}";<br />
Pattern: "Pattern" name=PATTERN_ID (label=STRING)?<br />
"{" masterData=MasterData desc=PatternDescription "}"; //name statt id, wegen Referenzierung<br />
PatternLink: type=PatternLinkType<br />
(("name=" targetId=PATTERN_ID (hasCollection?="collection=" collection=PATTERN_ID)?)<br />
|patternRef=[Pattern|(PATTERN_ID)]) (hasLabel?="label=" label=STRING)?;<br />
Problem: "Problem" text=STRING;<br />
Rationale: "Rationale" text=STRING;<br />
Reference: "Reference" ((hasURL?="url=" url=URL) | (hasBibtex?="bibtex=" "{" bibtex=STRING "}"));<br />
RelatedPatterns: "RelatedPattern" "{" (references+=PatternLink)* "}";<br />
Revision: "Revision" rev=VERSION_TYPE;<br />
Solution: "Solution" text=STRING;<br />
Synopsis: "Synopsis" text=STRING;<br />
//Typen:<br />
enum PatternLinkType: uses="uses" | containedIn="is−contained−by" | contains="contains" | isA="is−a" |<br />
comparable="comparable" | contradicts="contradicts";<br />
terminal VERSION_TYPE: (’0’..’9’)+(’.’’0’..’9’)*;<br />
terminal DATE: ((’2’’0’..’9’’0’..’9’’0’..’9’)’−’((’0’’1’..’9’)|(’1’’1’..’2’))’−’(((’1’|’2’)’0’..’9’)|(’0’(’1’..’9’))<br />
|(’3’(’0’..’1’))));<br />
terminal URL: ((’http’|’file’|’ftp’)’://’((’a’..’z’|’A’..’Z’|’0’..’9’|’:’|’/’|’.’|’@’|’−’|’+’|’%’|’_’|’#’)*));<br />
terminal PATTERN_ID: (’a’..’z’|’A’..’Z’|’0’..’9’|’:’|’.’|’−’|’_’)+;<br />
✝ ✆<br />
Listing B.3: PLML xText Grammatik, Sprachversion 1.5
B.1. PLML 145<br />
B.1.4 Beispielkatalog<br />
✞ ☎<br />
Catalog welie "Welie’s Pattern"<br />
MasterData {<br />
Author "Andreas Wolff"<br />
Credits "Sammlung <strong>von</strong> www.welie.com/patterns −− automatisch transformiert"<br />
CreationDate 2009−06−15<br />
LastModified 2010−03−15<br />
Revision 0.9.0<br />
}<br />
CategoryDef { UserNeeds label="User needs"<br />
CategoryDef { NavigatingAround label="Navigating around" }<br />
CategoryDef { BasicInteractions label="Basic interactions" }<br />
CategoryDef { Searching label="Searching" }<br />
CategoryDef { DealingWithData label="Dealing with data" }<br />
CategoryDef { Personalizing label="Personalizing" }<br />
CategoryDef { Shopping label="Shopping" }<br />
CategoryDef { MakingChoices label="Making choices" }<br />
CategoryDef { GivingInput label="Giving input" }<br />
CategoryDef { Miscelleaneous label="Miscelleaneous" }<br />
}<br />
CategoryDef { ApplicationNeeds label="Application needs"<br />
CategoryDef { DrawingAttention label="Drawing attention" }<br />
CategoryDef { Feedback label="Feedback" }<br />
CategoryDef { SimplifyingInteraction label="Simplifying interaction" }<br />
}<br />
CategoryDef { ContextOfDesign label="Context of design"<br />
CategoryDef { SiteTypes label="Site types" }<br />
CategoryDef { Experiences label="Experiences" }<br />
CategoryDef { PageTypes label="Page types" }<br />
}<br />
Pattern details−on−demand "" {<br />
MasterData {<br />
Author "Martijn van Welie"<br />
Category DealingWithData<br />
CreationDate 2010−03−15<br />
LastModified 2010−03−15<br />
Revision 1.0<br />
}<br />
Confidence **<br />
Evidence {<br />
Example url=http://www.welie.com/patterns/#<br />
Example ""<br />
Rationale ""<br />
}<br />
Problem ""<br />
RelatedPattern {<br />
uses retractable−menu<br />
}<br />
Context ""
146 ANHANG B. QUELLTEXTE<br />
Solution "Isn’t even a fly−out menu an instance of this pattern? sort of a retractable−menu"<br />
Synopsis ""<br />
}<br />
Pattern doormat "Doormat" {<br />
MasterData {<br />
Author "Martijn van Welie"<br />
Category NavigatingAround<br />
CreationDate 2010−03−15<br />
LastModified 2010−03−15<br />
Revision 1.0<br />
}<br />
Confidence **<br />
Evidence {<br />
Example url=http://www.welie.com/patterns/images/doormat−att−small.png<br />
Example ""<br />
Rationale "The doormat give users a quick and informative overview of the primary choices they need to<br />
make. Nothing important is hidden and all options in the doormat are accessible in one click."<br />
}<br />
Problem "Users need to be directed to the right section of the website"<br />
RelatedPattern {<br />
uses corporate<br />
uses homepage<br />
uses information−experience<br />
}<br />
Context "You are designing thehomepageof<br />
an information rich website. Typically a<br />
corporateor an<br />
information−experience."<br />
Solution "Divide your site into very few main sections. Three or four main sections is preferable because the<br />
clean and informative effect of the doormat is otherwise rapidly diminishing. Place the labels of each<br />
main section above a list of sub−items of that section. The sub−items must also not be too numerous,<br />
typically 4−8 items."<br />
Synopsis "List the main categories with the elements in the center of the home−page"<br />
}<br />
✝ ✆<br />
Listing B.4: Beispielkatalog mit der PLML-tDSL
B.2. XUL 147<br />
B.2 XUL<br />
✞ ☎<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
✝ ✆<br />
Listing B.5: XUL mit relativer Positionierung für das Demonstrationsbeispiel
148 ANHANG B. QUELLTEXTE
Anhang C<br />
Technische Beschreibungen /<br />
Implementierungsdetails<br />
C.1 Korrektur des Ergebnis des XUL-XSLT-EMF Importers<br />
Zwei Klassen pro XUL-Widget<br />
Nach dem Import besteht die Definition eines XUL-Widget immer aus einer abstrakten Klasse (Namenschema:<br />
„ElementType“) und einer konkreten Unterklasse dieser abstrakten Klasse, benannt<br />
nach dem Schema „Type“. In der abstrakten Klasse werden die Elementbeziehungen,<br />
d.h. die Assoziationen zu anderen Widgets, festgelegt. Alle Eigenschaften die keine Assoziationen sind<br />
werden als Attribute der konkreten Klasse definiert. Im Zuge der Umarbeitung des Metamodells nach<br />
dem Import wurde ein Großhteil dieser Typ-Doppelung entfernt, indem die Typen zu einem einzigen verschmolzen<br />
wurden. Da Ecore eine semantische Trennung zwischen Assoziationen (EReference) und Attributen<br />
(EAttribute) vorsieht, bleibt diese ursprüngliche Unterscheidung auch im verschmolzenen Typ weiter<br />
erhalten. Das vom Importer vorgelegte Namensschema wurde beibehalten.<br />
Nummerierte und anonyme Typen<br />
Die Vielzahl der nummerierten und anonymen Typen entstanden offentsichtlich als Folge nicht erkannter<br />
Typ-Äquivalenzen, d.h. es wurden homomorphe Typdefinitionen, mit unterschiedlichen Namen, mehrfach<br />
angelegt. Durch geeignete manuelle Nachbearbeitung des XML-Schemas ließ sich dieses Problem beheben.<br />
Andere Datentypen wurden im XML-Schema nicht genauer spezifiziert, als dass es sich um Unterklassen<br />
<strong>von</strong> String handelt. Ein Beispiel hierfür ist der Typ ColorHex zur Angabe <strong>von</strong> RGB-Farben als<br />
Zeichenkette. In diesen Fällen wurde die automatisch generierte Metaklasse komplett entfernt und stattdessen<br />
das jeweilige Attribut als EString typisiert.<br />
Weiterhin wurde vom Modellimporter für jeden Aufzählungstyp, neben der Metaklasse, noch eine eigene<br />
Objekt-Metaklasse angelegt. Beispielsweise werden die möglichen Werte für die Eigenschaft cropping,<br />
d.h. das Kürzen eines Textlabels falls der Platz zur Darstellung nicht ausreichend ist, über die Aufzählung<br />
CropAttributeType definiert 1 . Die Ecore-Erzeugungstransformation legte darüberhinaus noch die Metaklasse<br />
CropAttributeTypeObject an, welche als Pointer auf einen EMF-internen Implementierungstyp für<br />
1 möglich sind „start“, „end“, „center“ und „none“<br />
149
150 ANHANG C. TECHNISCHE BESCHREIBUNGEN / IMPLEMENTIERUNGSDETAILS<br />
Aufzählungen dient. Diese *Object-Metaklassen sind für die Verwendung als CUI-Modell irreführend und<br />
unnötig, sie wurden daher entfernt.<br />
Mangelnde Nutzung <strong>von</strong> Vererbung<br />
Das Transformationsergebnis der XSLT-Transformation war aus objektorientierter Sicht unbefriedigend,<br />
insbesondere die begrenzte Verwendung <strong>von</strong> Vererbung erschwert die Weiterverarbeitung. Das erstellte<br />
Metamodell definierte die meisten Attribute eines jedes XUL-Elements bei dessen jeweiliger Deklaration.<br />
Übergeordnete Typen zur Vererbung <strong>von</strong> Standardattributen wurden nicht verwendet. Ein Beispiel mag<br />
das Problem verdeutlichen: Für nahezu jedes XUL-Element kann dessen relative Größe über das Attribut<br />
flex angegeben werden. Dementsprechend wurde dieses Attribut auch in den meisten Metaklassen-<br />
Deklarationen der XUL-Elemente aufgeführt. Das hat allerdings zur Folge, dass unter dem Gesichtspunkt<br />
der Typsicherheit bzw. -hierarchie, die Eigenschaft Button.flex nicht das Gleiche wie die Eigenschaft VBox.<br />
flex ist. Beide müssten separat ausgewertet werden, die Folge wären unnütze und fehlerträchtige Mehrfacharbeiten.<br />
Eine wesentliche Strukturänderung für die Attribute schien daher unumgänglich.<br />
Im Rahmen der Nachbearbeitung mussten sinnvolle Ober-/Unterklassenbeziehungen identifiziert und eine<br />
Vererbungshierarchie im Modell aufgebaut werden. Das XUL-Schema liefert dazu wertvolle Hinweise, genauer<br />
betrachtet, liegt im Schema bereits eine sinnvolle Klassifizierung vor. Jedoch werden dort an Stelle<br />
der Vererbung <strong>von</strong> Attributen Referenzen auf Attributgruppen vererbt, dabei handelt es sich um ein besonderes<br />
Sprachelement <strong>von</strong> Schemadefinitionen. Der EMF-Schema-Importer setzt diese Gruppen leider in<br />
der oben beschriebenen - unpraktischen und eigentlich auch semantisch abweichenden - Weise um.<br />
C.2 Erläuterungen zum XUL-Metamodell<br />
Zur Erklärung der Abbildung 2.16 und des Metamodells. Die Klasse XULElement bildet die Wurzel der<br />
Typhierarchie. Alle Widgetklassen werden <strong>von</strong> dieser abgeleitet. Hierin werden eine ganze Reihe der allgemeingültigen<br />
Standardattribute, wie z.B. flex siehe oben, definiert. Die Werte dieser Attribute werden<br />
mit Standardwerten vorbelegt, dass betrifft im Wesentlichen die Eigenschaften die durch Enumerations<br />
deklariert werden, oder bleiben ungesetzt.<br />
Alle Unterklassen <strong>von</strong> TemplateControl werden genutzt um die Template-Engine zu steuern. Die Klasse<br />
InfoElement ist die Oberklasse für alle Sprachelemente die keine Widgets sind und nicht unterhalb<br />
TemplateControl einzugruppieren sind. Dazu zählen die Festlegung <strong>von</strong> Tastaturkürzeln, Popupgruppen und<br />
ähnlichem.<br />
Die Metaklasse VisibleElementType ist die Wurzelklasse der UI-Widgets. Diese werden in zwei Gruppen<br />
unterschieden, einerseits diejenigen die andere Widgets enthalten können und andererseits diejenige für<br />
die eine solche Verschachtelung nicht möglich ist. Das Metamodell nutzt Mehrfachvererbung um zwischen<br />
diesen beiden Gruppen zu unterscheiden.<br />
Unterklassen der abstrakten Klasse ContainerElement sind diejenigen Widgets, in welchen andere Widgets<br />
verschachtelt werden können. Für eine Reihe <strong>von</strong> UI-Elementen ist es nicht sinnvoll beliebige Kindelemente<br />
zuzulassen. Deshalb existiert weiterhin eine Unterscheidung zwischen GenericContainerElement und<br />
ContainerElement. Erstere können beliebig viele Widgets, die Unterklassen <strong>von</strong> ContainerChild sind, enthalten.<br />
Bei UI-Widgets, die nur Unterklasse <strong>von</strong> ContainerElement sind, muss die Containment-Beziehung auf<br />
der Ebene des jeweiligen Types definiert werden.<br />
Ein Beispiel dafür ist die Klasse TabsElementType, ebenfalls in Abbildung 2.16 enthalten. Als Unterklasse
C.3. PATTERN LANGUAGE META LANGUAGE 151<br />
<strong>von</strong> ContainerElement kann sie, bzw. die Instanzen <strong>von</strong> TabsType, Kindelemente aufnehmen. Allerdings nur<br />
solche vom Typ TabsType. TabsType seinerseits ist ein GenericContainerElement, es kann damit beliebige<br />
ContainerChilds enthalten. Im Listing C.1 ist ein Minimalbeispiel dazu angegeben, es zeigt die vorstehend<br />
erläuterte Verschachtelung der Elemente auf XUL/XML-Ebene.<br />
✞ ☎<br />
<br />
<br />
<br />
<br />
✝ ✆<br />
Listing C.1: Minimal-XUL zur Illustration der Tab-Verschachtelung<br />
Einfache, oder auch atomare, Widgets sind direkte konkrete Unterklassen <strong>von</strong> VisibleElementType. Die<br />
Widgets welche als Kindknoten innerhalb <strong>von</strong> GenericContainerElementen auftreten, erben zusätzlich <strong>von</strong><br />
ContainerChild. Neben der Markierung als gültiger Kindknoten, erhält das Widget auf diesem Weg auch<br />
eine Assoziation parent zum Vaterknoten.<br />
In Abbildung 2.16 werden sieben Widgets gezeigt. Es sind dies die konkreten Klassen im unteren Bereich<br />
der Darstellung. Bei LabelType handelt es sich um eine gewöhnliche Beschriftung, ButtonType sind Schaltflächen<br />
und Instanzen <strong>von</strong> TextBoxType beschreiben Textfelder. Instanzen <strong>von</strong> RadioType werden zu 1 : N-<br />
Auswahlen verwendet und stellen dabei jeweils eine Auswahloption dar. Diese Auswahlmöglichkeiten werden<br />
in sogenannten Radiogroups zusammengestellt, im Metamodell über den Typ RadiogroupElementType<br />
abgebildet. Da RadioType eine Unterklasse <strong>von</strong> ButtonType ist, können deren Instanzen jedoch als Kindknoten<br />
beliebiger GenericContainerElement-Instanzen verwendet werden. Das Metamodell ist damit konsistent<br />
zur, den Standard definierenden, Gecko-Engine. Inwieweit die Verwendung <strong>von</strong> RadioType-Instanzen außerhalb<br />
<strong>von</strong> RadiogroupElementType sinnvoll sein kann, ist der Entscheidung des jeweiligen Verwenders überlassen.<br />
BboxType ist ein Spezialfall eines -Containers, also einer Box mit horizontaler Aneinandereihung<br />
ihrer Kindknoten. In -Container werden die Kindknoten zusätzlich noch an einer gemeinsamen<br />
Linie, der sogenannten „baseline“ ausgerichtet, daraus leitet sich auch das erste B ab→„BaselineBox“.<br />
Einbettung in den Gesamtprozeß<br />
Um das entstandene XUL-Metamodell als CUI für den Rostock MD-UID Prozess verwenden zu können,<br />
ergaben sich noch zwei kleine Änderungen am Modell. Zum einen musste, um weiterhin den mit jedem<br />
Widget assoziierten Task notieren zu können, der Klasse XULElement eine Referenz task:Task hinzugefügt<br />
werden. Die zweite Änderung stellt sich eher als Arbeitserleichterung dar. Es erwies sich für diverse Transformationen<br />
als praktisch, mehr als ein Fenster innerhalb einer XUL-Modellinstanz haben zu können. Der<br />
dafür eingeführte Metatyp MultiRoot stellt die entsprechenden Referenzen bereit, andere Eingriffe in das<br />
Metamodell waren dazu nicht nötig.<br />
C.3 Pattern Language Meta Language<br />
C.3.1 Erläuterte Änderungen gegenüber PLML 1.1<br />
✞ ☎<br />
<br />
<br />
<br />
✝ ✆<br />
Listing C.2: Einschränkung des Wertebereichs für confidence-Angaben
152 ANHANG C. TECHNISCHE BESCHREIBUNGEN / IMPLEMENTIERUNGSDETAILS<br />
Listing C.2 zeigt die dafür nötigen Erweiterungen. Darin wird die XML-Entität confidenceLevels, die genau<br />
einen der drei möglichen Werte annehmen kann, deklariert. Diese Entität wird als Wertebereich für das<br />
Attribut level festgelegt. Gleichzeitig wird confidence als inhaltsloses Element redefiniert, d.h. es darf nun<br />
keinen Inhalt irgendeiner Art enthalten. Mit dieser Anpassung wird die Notierung <strong>von</strong> Confidence-Werten<br />
formalisiert, es bedarf keiner Interpretation eines eventuellen Textinhaltes mehr um ein Pattern einer der<br />
drei Kategorien zuzuordnen.<br />
C.3.1.1 Abbildungsreferenzierung<br />
Prinzipiell ist es möglich, Abbildungen als Binärdaten in XML-Dokumente einzubetten, der Standard selbst<br />
untersagt dies auch nicht. Dies wäre jedoch eine zumindest unübliche Vorgehensweise, für die kaum Vorteile<br />
zu erwarten sind. Praktischer, format- und plattformunabhängiger, ist jedoch die Einführung <strong>von</strong> Referenzen<br />
nach dem etablierten URL-Standard [104].<br />
Illustrationen werden in Patternkatalogen vielfach eingesetzt; um Beispiele zu geben, den Kontext zu erläutern<br />
oder in Diagrammen die Patternlösung zu fixieren. Listing C.3 definiert optionale url Attribute für<br />
die drei entsprechenden PLML Elemente.<br />
✞ ☎<br />
<br />
<br />
<br />
✝ ✆<br />
Listing C.3: Annotation <strong>von</strong> Illustrations-URLs<br />
C.3.1.2 Literaturreferenzen<br />
✞ ☎<br />
<br />
<br />
<br />
<br />
✝ ✆<br />
Listing C.4: Notation <strong>von</strong> Literaturreferenzen<br />
Literaturreferenzen werden gemäß der Grammatik aus Listing:PLMLLiterature notiert. Das bedeutet das zwei<br />
Notationsformen zugelassen werden, URLs und komplette Bibtex-Einträge. Beide sind jeweils als Textinhalt<br />
des literatureEntry anzugeben. Natürlich kann mit den Ausdrucksmitteln einer DTD keine Formatprüfung<br />
des Textes auf eine valide URL oder gar Bibtex erfolgen.<br />
C.3.1.3 Patternquerverweise<br />
Analog zum Vorgehen bei den Literaturreferenzen und der Confidence-Wertung, wurde wiederum eine<br />
XML-Entität benutzt um den gültigen Wertebereich zur Angabe des Typs der Patternbeziehungen zu fixieren.<br />
✞ ☎<br />
<br />
<br />
C.3. PATTERN LANGUAGE META LANGUAGE 153<br />
type %linkType #REQUIRED<br />
patternID CDATA #REQUIRED<br />
collection CDATA #IMPLIED<br />
label CDATA #IMPLIED<br />
><br />
✝ ✆<br />
Listing C.5: Notation <strong>von</strong> Patternverlinkungen<br />
Das redefinierte Element pattern−link zeigt Listing C.5. Die Angabe des Zielkataloges (collection) und eines<br />
beschreibenden Labels sind im Gegensatz zum PLML-Standard nach Listing 3.1 optional. Die neue XML-<br />
Entität linkType enthält die drei, bereits in Tabelle 3.2, vorgestellten Relationsarten. Zusätzlich werden die<br />
Verbindungstypen uses, comparable und contradicts zugelassen.<br />
C.3.1.4 Kategoriemechanismus<br />
✞ ☎<br />
<br />
<br />
✝ ✆<br />
Listing C.6: Notation <strong>von</strong> Kategorien<br />
Es stellte sich die Frage wo die Kategorien sinnvoll zu hinterlegen sind. Ich habe mich dafür entschieden,<br />
sie in den jeweiligen Katalog einzubetten. In Listing C.6 wird das XML-Element category definiert. Jeder<br />
Kategorie muss eine eindeutige Identifikation zugewiesen werden. Das der Name der Kategorie in einem<br />
eigenen Element hinterlegt wird, ist möglicherweise unüblich; typischerweise würde man dies ebenfalls als<br />
Attribut modellieren. Da aber im PLML-Standard für Pattern-Einträge genauso vorgegangen wird, wurde<br />
die Benennung der Kategorien aus Konsistenzgründen gleich gestaltet. Jede Kategorie kann beliebig viele<br />
Unterkategorien haben, dies ist inspiriert <strong>von</strong> Welies 2-stufiger Hierarchie, und ermöglicht grundsätzlich<br />
eine beliebig tief verschachtelte Kategoriehierarchie. Die Zuordnung eines Patterns zu einer Kategorie erfolgt<br />
innerhalb dessen Stammdaten-Element (managagement), per Attribut wird die ID der (Sub-)Kategorie<br />
angegeben.<br />
C.3.2 Erläuterungen zur xText-Grammatik<br />
Eine xText-Grammatik ist eine kontextfreie Grammatik, deren Notation an EBNF angelehnt ist. In der<br />
Informatik wird unter einer Grammatik normalerweise das 4-Tupel(T,N,P,s0) verstanden. T ist die Menge<br />
der Terminalsymbole, N die Menge der Nicht-Terminale, P die Produktionsregeln und s0 das Startsymbol,<br />
meist gilt s0 ∈ N.<br />
In einer xText-Grammatik sind Nichtterminale Zeichenketten die mit Grossbuchstaben beginnen. Terminalsymbole<br />
sind dadurch gekennzeichnet, dass sie in Anführungszeichen stehen. Eine Produktionsregel<br />
wird durch den Namen eines Nichtterminals eingeleitet, gefolgt <strong>von</strong> einem Doppelpunkt hinter dem der<br />
Inhalt der Regel notiert wird.<br />
✞ ☎<br />
RelatedPatterns:<br />
"RelatedPattern" "{" (references+=PatternLink)* "}";<br />
PatternLink: type=PatternLinkType (<br />
("name=" targetId=PATTERN_ID (hasCollection?="collection=" collection=PATTERN_ID)?)<br />
| patternRef=[Pattern|(PATTERN_ID)]
154 ANHANG C. TECHNISCHE BESCHREIBUNGEN / IMPLEMENTIERUNGSDETAILS<br />
)<br />
(hasLabel?="label=" label=STRING)?;<br />
enum PatternLinkType:<br />
uses="uses" | containedIn="is−contained−by" | contains="contains" |<br />
isA="is−a" | comparable="comparable" | contradicts="contradicts";<br />
✝ ✆<br />
Listing C.7: xText-Grammatikausschnitt zur Eintragung <strong>von</strong> Patternbeziehungen<br />
Einen Ausschnitt der PLML-Grammatik zeigt Listing C.7. Um den Sinn des Listings zu erfassen, sollte<br />
man wissen, dass im aus der Grammatik generierten Metamodell alle Nichtterminale als Metaklassen angelegt<br />
werden. Diese Klassen verfügen über Attribute und Referenzen, jedoch nicht über eigene Methoden.<br />
Der Name und der Typ der Attribute leitet sich aus der Grammatik ab. Zeichenketten die mit Kleinbuchstaben<br />
beginnen und keine Terminale sind, werden zu Attributen des Nichtterminals in dessen Produktionsregel<br />
sie notiert sind. Über den, sich an den Attributnamen, anschließenden Operator wird der Typ festgelegt:<br />
Bei = entspricht der Attributtyp dem Typ der rechten Seite der Zuweisung, bei ?= handelt es sich einen<br />
Boolean-Wert und mit += werden Listen deklariert, genauer Listen <strong>von</strong> Elementen vom Typ der rechten<br />
Zuweisungsseite.<br />
ID und STRING sind vordefinierte xText-Typen, für Zeichenketten und Identifikationsliterale, sie werden<br />
im Metamodell auf EString gemappt. Das xText-Schlüsselwort Enum auf der linken Seite einer Regel vor<br />
dem Nichtterminal, dient der Definition <strong>von</strong> Aufzählungstypen. Die Teilterme auf der rechten Regelseite<br />
deklarieren dann die möglichen Werte, für deren Syntax gilt: Wertname=”Wertliteral”. Die Bedeutung<br />
der Metasymbole ∗,? und + ist äquivalent zu EBNF-Grammatiken.<br />
Eckige Klammern [,] werden zur Deklaration <strong>von</strong> Referenzen genutzt, die Syntax ist [Nichtterminal |<br />
(TypderIdenti f izierungseigenscha ft)]. Unglücklicherweise kann der Name der identifizierenden Eigenschaft<br />
nicht in der Grammatik angegeben werden. Standardmäßig muss dieses Attribut name heissen, alternative<br />
Namen sind grundsätzlich möglich, erfordern aber eigens implementierte Java-Klassen. Um auf<br />
diesen Aufwand zu verzichten, werden die Id-Attribute in der PLML-xText Grammatik durchgehend als<br />
name benannt. Das dies im Widerspruch zur originalen Sprachdefinition, und auch zur eigenen PLML-v1.5<br />
steht, ist irrelvant, da die Benennung der Attribute des Metamodells keine Rolle für die Funktionalität des<br />
PLML-Editors und -Generators spielt.<br />
Zur Erläuterung des Grammatikausschnitts aus Listing C.7. Hier wird zum einen die Struktur der Metaklasse<br />
RelatedPatterns definiert und auch die Deklaration ihrer Instanzen in der PLML-tDSL festgelegt. Demnach<br />
wird eine Instanz <strong>von</strong> RelatedPatterns im Textkörper der tDSL mit dem Schlüsselwort RelatedPattern<br />
eingeleitet. Die Metaklasse enthält außerdem genau ein Attribut, eine Liste <strong>von</strong> beliebig vielen Referenzen<br />
auf Instanzen des Typs PatternLink. Diese werden zwischen öffnenden und schließenden geschweiften<br />
Klammern notiert.<br />
Das Nichtterminal PatternLink ist komplexer. Dessen Metaklasse wird mit sieben Attributen angelegt. Die<br />
beiden Boolean-Attribute hasCollection und hasLabel dienen als Marker, ob ein Zielkatalog (collection) gesetzt<br />
oder eine Linkbeschriftung (label) gesetzt wurden. Im Attribut type wird die Art der Patternreferenz,<br />
über die Literalen des Aufzählungstyps PatternLinkType, deklariert. Eine Pattern-Referenz kann entweder<br />
durch Angabe einer beliebigen Id, ggf. in einem beliebigen Katalog, oder durch direkte Referenzierung<br />
eines Patterns im selben Katalog erfolgen.
C.4. TECHNISCHER ABLAUF DER SWING-ABBILDUNG AUF ECORE 155<br />
C.3.3 PLML Metamodell für den grafischen PLML-Editor<br />
Bei genauerer Betrachtung der, im Screenshot Abbildung 3.4 im unteren Bereich zu erkennenden, Eigenschaftentabelle<br />
fallen zwei Attribute auf, die nicht in der Metaklasse PatternLink nach Abbildung 3.2<br />
enthalten sind, dafür fehlt das Attribut patternRef:Pattern. Die beiden hinzugefügten Attribute, source und<br />
target sind vom Typ Pattern und wurden als abgeleitete und transiente Attribute definiert. Das bedeutet, dass<br />
ihr konkreter Wert aus den Belegungen der anderen Attribute hergeleitet werden kann und der jeweilige<br />
Wert auch nicht in die Serialisierung des Modells übernommen wird. Mit anderen Worten: er wird nicht in<br />
den Katalog eingetragen. Der Wert des target-Attribute leitet sich dabei aus der Auflösung der targetID des<br />
Typs PatternLink in das konkrete referenzierte Pattern ab. Es entspricht also dem patternRef:Pattern aus dem<br />
aktuellen PLML-Metamodell.<br />
Das Attribut source speichert das Pattern-Objekt das die Quelle der Pattern-Referenzbeziehung ist. Verwendet<br />
wird source im GMFMap-Modell. Wie erwähnt werden dort die möglichen Kanten des Graphen<br />
detailliert auf Metaklassen-Attribute abgebildet. Das source-Attribut dient dort der Speicherung des Ausgangsknotens<br />
einer Patternreferenz.<br />
Einen weiteren erwähnenswerten Unterschied gibt es bei der Darstellung des Confidence Wertes. Im durch<br />
xText generierten Metamodell wird dieser durch drei Boolean-Attribute dargestellt, eine Konsequenz aus<br />
der Art wie diese Information in der Grammatik spezifiziert wurde. Diese Attribute sind gewissermaßen eine<br />
technische Notwendigkeit, aber im Handling unpraktisch. Um Nutzern die Sternwertung besser zu signalisieren,<br />
als durch die Boolean-Attribute, war die direkte Anzeige <strong>von</strong> deren Wertbelegung wünschenswert.<br />
Hierfür wurde wiederum ein transientes abgeleitetes Attribute label definiert, dessen Wert die Belegung<br />
der Boolean-Variablen Menschen-lesbar darstellt. Im Diagramm-Editor wird der Wert <strong>von</strong> Confidence.label<br />
daher als Beschriftung des Confidence-Wertes eingesetzt und grafisch angezeigt.<br />
Selbstverständlich müssen die jeweiligen Werte der <strong>von</strong> target, source und label irgendwo berechnet werden.<br />
Dazu muss die Modellebene verlassen werden und eigener Quellcode implementiert werden. Nach<br />
geeigneten Anpassungen in dem Metamodell-Editierungsquellcode, der durch Nutzung des PLML-<strong>Generierung</strong>smodells<br />
erzeugt wurde, modifiziert das Ändern der abgeleiteten Werte im Editor die zugrundeliegenden<br />
Attribute und wird der im Editor angezeigte Wert der Eigenschaften aus den zugrundeliegenden<br />
Attributen berechnet.<br />
C.4 Technischer Ablauf der Swing-Abbildung auf Ecore<br />
Weil es möglich ist, eine direkte Beziehung zwischen dem zukünftigen EMF-Objekt und dem effektiven<br />
Swing-Objekt herzustellen, kann der Implementierungsaufwand für den eigentlichen Mapping-Prozess reduziert<br />
werden. Durch Benutzung <strong>von</strong> Reflection bzw. Introspection kann vermieden werden, dass das<br />
Übertragen jeder einzelnen Eigenschaft ausprogrammiert werden muss. Dazu wird aus der Meta-Klasse<br />
für das jeweilige Swing-Widget die Liste <strong>von</strong> dessen potentiellen Eigenschaften ausgelesen. Diese sind im<br />
Namen identisch mit den Namen der Objekteigenschaften des Swing-Objektes. Für jeden Eigenschaften-<br />
Namen wird schließlich die Belegung des gleichbenannten Attributes per Introspection ausgelesen. Der<br />
erhaltene Wert muss dann nur noch als Eigenschaftwert in der Ecore-Instanz gesetzt werden. Theoretisch<br />
also ein Vorgang ohne wesentliche Schwierigkeiten.<br />
Praktisch war es allerdings notwendig, einen Weg zu finden um Eigenschaftswerte an den Sichtbarkeitsbeschränkungen<br />
vorbei auszulesen. Wie bereits erwähnt, ist ein gewisser Teil der Eigenschaften als private<br />
-Attribut implementiert und nur über public-Accessor Methoden auslesbar und modifizierbar. Es wäre nun<br />
möglich gewesen, dass Swing-Metamodell so umzugestalten, dass die Zugriffsmethoden für diese Attri-
156 ANHANG C. TECHNISCHE BESCHREIBUNGEN / IMPLEMENTIERUNGSDETAILS<br />
bute in das Modell übernommen werden; soweit dabei nicht die Getter/Setter-Problematik getriggert würde.<br />
Dann müsste auf Metamodellebene die Verbindung zwischen Attribut und Zugriffsmethode markiert<br />
werden, etwa über eine Annotation. Zu guter Letzt ließe sich diese Information dann vom Swing→EMF-<br />
Konverter auslesen und zum Auslesen des Wertes verwenden.<br />
Insgesamt ein gangbarer Weg, obwohl hierbei die Sauberkeit des methodenlosen Swing-Modells reduziert<br />
würde. Ebenfalls müsste hierfür der Modellreduzierungsprozeß neu überdacht werden, denn sowohl dessen<br />
vorliegende Kermeta-Implementierung als auch die dahinterstehende Methodik berücksichtigt keine<br />
Methoden.<br />
Java bietet im Rahmen der Reflection-Mechanismen allerdings auch die Möglichkeit den syntaktischen<br />
Schutz der Sichtbarkeiten zu durchbrechen. Voraussetzung hierzu ist das Setzen eines geeigneten Security-<br />
Managers für die Laufzeitumgebung. Diese Variante hat den Charme, dass keinerlei Sonderbehandlung für<br />
das Auslesen bestimmter Eigenschaften notwendig ist, zudem ist der Aufwand gegenüber der Alternative<br />
wesentlich geringer. Aus diesem Grund wurde daher dieser Weg verfolgt.<br />
Ein Security-Manager ist in der Sprachumgebung Javas der Standardmechanismus um die Zulässigkeit<br />
diverser Aktionen einer Applikation zu entscheiden. Einen solchen Security-Manager zu implementieren<br />
ist recht einfach. Man muss eine eigene Unterklasse <strong>von</strong> java.lang.SecurityManager erstellen und diejenigen<br />
Methoden überschreiben, die für die gewünschten Rechte zuständig sind. Beispielsweise testet die Methode<br />
public void checkDelete(String file), ob der Java-Runtime erlaubt werden soll die Datei file zu löschen, bzw.<br />
dies überhaupt zu versuchen. Löst der Aufruf <strong>von</strong> checkDelete eine bestimmte Exception aus, dann verbietet<br />
die Java-Runtime dem Aufrufer diese Dateioperation. Endet die Methode durch einfachen Rücksprung, ist<br />
die Datei-Operation zugelassen.<br />
Damit das Durchbrechen der Sichtbarkeitsbeschränkungen via Reflection möglich wird, muss public void<br />
checkMemberAccess(Class clazz, int which) überschrieben werden. Der Parameter which bezeichnet dabei<br />
das angeforderte Sichtbarkeitslevel. Die Standardimplementierung dieser Methode setzt die bekannten<br />
Java-Sichtbarkeitsregeln um. Durch Überschreiben mit einer leeren Implementierung, werden diese Regeln<br />
ausser Kraft gesetzt. Der so entstandende eigene Security-Manager muss der Java-Runtime zum Start des<br />
Containers bekannt gegeben werden.<br />
Zurück zum eigentlichen Ablauf, wie erwähnt, erfolgt die Transformation mit einem preorder-Durchlauf<br />
durch den Objektgraphen. Über den vollqualifizierten Namen der dabei angetroffenen Objekte wird die<br />
Meta-Klasse des anzulegenden Ecore-Objekts ermittelt. Deren Modellspezifikation wird im nächsten Schritt<br />
benutzt um die zu mappenden Eigenschaften zu identifizieren. Hierfür erfolgt eine Iteration über alle Features<br />
des Metamodell-Typs und via des oben angerissenen Reflektionsverfahrens wird versucht den Eigenschaftswert<br />
auszulesen. Erwähnenswert hierzu ist, dass auf der Suche nach einem bestimmten Eigenschaftswert<br />
auf der Javaseite, die komplette Typhierarchie bottom-up durchlaufen wird bis ein entsprechendes<br />
Attribut gefunden wird, bzw. mit dem Typ java.lang.Object die Wurzelklasse aller Typen erreicht ist. Die<br />
Notwendigkeit zu dieser Vorgehensweise ergibt sich wiederum aus den etwaigen Sichtbarkeitsbeschränkungen.<br />
Auch im Swing-Metamodell wird zwischen Werten und Referenzen unterschieden. Werte, d.h. Instanzen<br />
der Java-Basis-typen, stellen kein Problem dar. Sie können direkt übertragen werden. Etwas aufwendiger<br />
gestaltet sich die Übernahme komplexer Eigenschaften, also solche die als Referenzen ins Modell eingetragen<br />
werden müssen. Für diese wird ebenfalls über deren vollqualizierten Namen der Abbildungstyp im<br />
Metamodell identifiziert und eine entsprechende Instanz dessen angelegt. Diese Instanz wird in einer geeigneten<br />
PropertyRegistry abgelegt. Geeignet hierfür sind Typen welche eine Kombination dieser beiden Kriterien<br />
darstellen: möglichst lokal an der Stelle der Verwendung und möglichst weit oben im Objektbaum.<br />
Querreferenzierungen sind im Objektgraphen häufig anzutreffen, beispielsweise wird die standardmäßige
C.4. TECHNISCHER ABLAUF DER SWING-ABBILDUNG AUF ECORE 157<br />
Hintergrundfarbe nur einmal als ColorUIResource-Objekt angelegt, aber <strong>von</strong> allen Widgets referenziert. Um<br />
diese Referenzen im Ecore-Modell nachzuvollziehen werden während der Transformation alle erstellten<br />
Instanzen in einem Objekt-Cache eingetragen. Dieser Objekt-Cache wird immer konsultiert bevor eine<br />
neue Instanz eines Eigenschaftenobjekts angelegt wird. Liegt für einen Eigenschaftenwert ein Cachetreffer<br />
vor, wird die bereits existierende Instanz referenziert.<br />
Im Prinzip könnte die Übernahme der Attributwerte aus den komplexen Eigenschaftswerten über das selbe<br />
Reflektionsverfahren durchgeführt werden, wie dies oben für die Ermittlung der Attribute der ursprünglichen<br />
Widgets beschrieben wurde. Dabei ist es jedoch problematisch, dass das Swing-Metamodell nicht<br />
deckungsgleich dem Java-Metamodell ist. Es kommt also zu Fällen, in denen die Attributtypen der komplexen<br />
Eigenschaftswerte nur als leere Klassen im nonlocal-Package angelegt sind. Diese lassen sich dann<br />
nicht mehr adäquat über die Metamodellinformationen auswerten. Ein anderes Problem stellen Arrays bzw.<br />
Vektoren dar, wie sie z.B. bei der RGB-Definition <strong>von</strong> Farben auftreten. Diese werden im Metamodell als<br />
EList umgesetzt, wofür wiederum eine Sonderfallbehandlung nötig ist. Daneben existieren auch noch Eigenschaften<br />
der UI-Widgets, die gar nicht als Attribute in deren Klassen hinterlegt sind. Dies gilt etwa für<br />
Tooltips, diese sind in einer Schlüssel/Wert-Tabelle abgelegt und nur über Accessormethoden auszulesen.<br />
Wegen der Vielzahl an Ausnahmebehandlungen, wurde entschieden die Wertübernahme aus komplexen<br />
Eigenschaftstypen jeweils in eigenen Java-Methoden auszuprogrammieren.
158 ANHANG C. TECHNISCHE BESCHREIBUNGEN / IMPLEMENTIERUNGSDETAILS
Anhang D<br />
Patternkomponenten<br />
D.1 Tabellarische Einordnung<br />
Tabelle D.1: Patternkurzbeschreibungen und Komponentisierbarkeitsvermutung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
accordion Navigating around **<br />
„Accordion “ 1.3.1 1.3.1<br />
Stack panels vertically or horizontally and open up one panel at the time while collapsing the other<br />
panels<br />
action_button Basic interactions **<br />
„Action Button “ 1.3.4 1.3.4<br />
Use push-button with the action ’verb’ as part of the label.<br />
action_panel Commands and Actions **<br />
„Action Panel “ 1.3.4 1.3.4<br />
Instead of using menus, present a large group of related actions on a UI panel that’s richly organized<br />
and always visible.<br />
advanced_search Searching **<br />
„Advanced Search “ 1.3.3 1.3.3<br />
Offer a special advanced search function with extended term matching, scoping and output options.<br />
animated_transition Getting Around **<br />
„Animated Transition “ 1.2 1.2<br />
Smooth out a startling or dislocating transition with an animation that makes it feel natural.<br />
application Site types **<br />
„Web-based Application “ 2.4 2.4<br />
Structure the site around ’views’ and allow users to work inside views<br />
article_page Page types **<br />
„Article Page “ 2.4 2.4<br />
Fortsetzung auf nächster Seite<br />
159
160 ANHANG D. PATTERNKOMPONENTEN<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
Present the article in a consistent and structured format, and place it in the center of the page.<br />
artist_sites Site types **<br />
„Artist Site “ 2.4 2.4<br />
Create a site with background information, timely information and "digital merchandise".<br />
autocomplete Searching **<br />
„Autocomplete “ 1.4 1.2<br />
Suggest possible label names as users are typing<br />
automotive Site types **<br />
„Automotive Sites “ 2.4 2.4<br />
Offer heavily branded overview of cars and related information supporting purchasing<br />
blog Page types **<br />
„Blog Page “ 2.4 2.4<br />
Create a page with daily news ’blobs’ and archived news blobs<br />
booking Shopping **<br />
„Booking “ 2.4 2.4<br />
Allow users to search for the ’object’ flexibly, especially concerning date/time versus prize. Then<br />
allow that to make the actual booking.<br />
brand_promo_site Site types **<br />
„Branded Promo Site “ 2.4 2.4<br />
Provide info and entertainment related to the brand<br />
campaign_site Site types **<br />
„Campaign Site “ 2.4 2.4<br />
Create small thematic site that markets a product in a different way than simply listing its features<br />
captcha Drawing attention **<br />
„Captcha “ 1.2 1.2<br />
Present users with a mangled image containing numbers and letters that humans can still ’decipher’<br />
but is hard for machines to read.<br />
card_stack Organizing the Page **<br />
„Card Stack “ 1.1 1.1<br />
Put sections of content onto separate panels or "cards,änd stack them up so only one is visible at a<br />
time; use tabs or other devices to give users access to them.<br />
cascading_lists Showing Complex Data **<br />
„Cascading Lists “ 1.3.2 1.3.2<br />
Express a hierarchy by showing selectable lists of the items in each hierarchy level. Selection of any<br />
item shows that item’s children in the next list.<br />
case_study Page types **<br />
„Case Study “ 2.4 2.4<br />
Describe a case by describing the problem, the solution and the value of that solution<br />
center_stage Organizing the Page **<br />
„Center Stage “ 2.4 2.4<br />
Put the most important part of the UI into the largest subsection of the page or window; cluster secondary<br />
tools and content around it in smaller panels. — Create a large "center stage"that dominates<br />
on the page<br />
Fortsetzung auf nächster Seite
D.1. TABELLARISCHE EINORDNUNG 161<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
clear_entry_points Getting Around **<br />
„Clear Entry Points “ 2.4 2.4<br />
Present only a few entry points into the interfaces; make them task-oriented and descriptive.<br />
color_coded_sections Getting Around **<br />
„Color-Coded Sections “ 2.4 2.4<br />
Use color to identify which section of an application or site that a page belongs to. — Color each<br />
major section with it’s own color<br />
column_ f ilter Dealing with data *<br />
„Table Filter “ 2.2 1.3.1<br />
Allow the users to select a subset of the information items directly above the table<br />
combined_menu Navigating around **<br />
„Header-less Menu “ 1.3.3 1.3.3<br />
Combine menus in a vertical menu using different visual clues instead of headers<br />
command_history Commands and Actions **<br />
„Command History “ 1.4 1.3.3<br />
As the user performs actions, keep a visible record of what was done, to what, and when.<br />
commerce Site types **<br />
„E-Commerce Site “ 2.4 2.4<br />
Create a ’virtual’ store where visitors can browse, choose and pay for all their selections in one go.<br />
community Site types **<br />
„Community Site “ 2.4 2.4<br />
Create a simple site offering information about the topic and the group.<br />
community_building Experiences **<br />
„Community Creation “ 2.4 2.4<br />
Create a site where users can collect, share, relate and donate<br />
composite_selection Builders and Editors **<br />
„Composite Selection “ 2.4 1.4<br />
Use different gestures – or mouse clicks in different screen areas, such as the composite’s edges<br />
versus its insides – to determine whether you should select a composite itself or allow its contained<br />
objects to be selected.<br />
constrained_resize Builders and Editors **<br />
„Constrained Resize “ 2.4 1.4<br />
Supply resize modes with different behavior, such as preserving aspect ratio, for use under special<br />
circumstances.<br />
contact_us Page types **<br />
„Contact Page “ 2.4 2.4<br />
Provide a special page that tells users how to get in touch with the organization<br />
content_lock Drawing attention **<br />
„Premium Content Lock “ 1.3.1 1.3.1<br />
Show previews of premium content and mark it visually<br />
corporate Site types **<br />
„Corporate Site “ 2.4 2.4<br />
Fortsetzung auf nächster Seite
162 ANHANG D. PATTERNKOMPONENTEN<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
Structure the site based on the primary questions of potential visitors.<br />
country_selector Making choices **<br />
„Country Selector “ 1.3.1 1.3.1<br />
Place a language, and region, selector on the home-page.<br />
creating Experiences **<br />
„Information Management “ 2.4 2.4<br />
Allow users to manage sets of objects using overviews and detail-views<br />
crumbs Navigating around **<br />
„Breadcrumbs “ 1.3.4 1.3.4<br />
Show the hierarchical path from the top level to the current page and make each step clickable<br />
customization_window Personalizing *<br />
„Customization Window “ 2.4 2.4<br />
Use "windows"with select items that users can adapt or click away.<br />
date_selector Making choices **<br />
„Date Selector “ 1.1 1.2<br />
Use a combination of an edit box and a graphical click able calendar<br />
deep_background Making It Look Good **<br />
„Deep Background “ 1.3.3 1.3.3<br />
Place an image or gradient into the page’s background that visually recedes behind the foreground<br />
elements.<br />
diagonal_balance Organizing the Page **<br />
„Diagonal Balance “ 2.4 1.3.4<br />
Arrange page elements in an asymmetric fashion, but balance it by putting visual weight into both<br />
the upper-left and lower-right corners.<br />
directory Navigating around **<br />
„Directory Navigation “ 1.3.3 1.3.3<br />
Sum up level 1 and 2<br />
doormat Navigating around **<br />
„Doormat “ 1.3.3 1.3.4<br />
List the main categories with the elements in the center of the home-page<br />
edit_in_place Builders and Editors **<br />
„Edit-in-Place “ 2.4 2.4<br />
Use a small, dynamic text editor to let the user change text ïn place": position the editor directly over<br />
the original text, rather than using a separate panel or dialog box.<br />
enlarged_clickarea Simplifying interaction *<br />
„Enlarged Clickarea “ 2.4 2.4<br />
Enlarge the click area to include neighboring areas<br />
event_calendar Page types **<br />
„Event Calendar “ 2.4 2.4<br />
Present a list of events starting from the current date and allow users to select/search for other dates<br />
extras_on_demand Organizing the Content **<br />
„Extras On Demand “ 1.3.1 1.3.1<br />
Fortsetzung auf nächster Seite
D.1. TABELLARISCHE EINORDNUNG 163<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
Show the most important content up front, but hide the rest. Let the user reach it via a single, simple<br />
gesture.<br />
f aq Searching **<br />
„Frequently Asked Questions (FAQ) “ 2.4 2.4<br />
Create a page with Frequently Asked Questions (FAQ) and provide short answers<br />
f avourites Dealing with data **<br />
„Collector “ 2.1 1.3.3<br />
Allow users to build their list of items by selecting the items as they are viewing them. Place a link<br />
to the collected items list on every page in the site.<br />
f ew_hues_many_values Making It Look Good **<br />
„Few Hues, Many Values “ 2.4 2.4<br />
Choose one, two, or at most three major color hues to use in the interface. Create a color palette by<br />
selecting assorted values (brightnesses) from within those few hues.<br />
f ill_in_the_blanks Getting Input From Users **<br />
„Fill-in-the-Blanks “ 2.4 2.4<br />
Arrange one or more fields in the form of a prose sentence or phrase, with the fields as "blanks"to be<br />
filled in by the user.<br />
f ly_out_menu Navigating around **<br />
„Flyout Menu “ 1.2 1.2<br />
Combine horizontal navigation with a sub-menu that flies-out when the users hovers over the main<br />
menu-item<br />
f ont_enlarger Simplifying interaction *<br />
„Font Enlarger “ 1.3.1 2.1<br />
Allow users to increase/decrease the font size of the text using special controls in the page.<br />
f orgiving_ f ormat Getting Input From Users **<br />
„Forgiving Format “ 2.4 2.4<br />
Permit users to enter text in a variety of formats and syntaxes, and make the application interpret it<br />
intelligently.<br />
f ormat Giving input **<br />
„Constrained Input “ 1.3.4 1.3.4<br />
Only allow the user to enter data in the correct syntax.<br />
f orms Giving input *<br />
„Forms “ 1.3.4 1.3.4<br />
Offer users a form with the necessary elements<br />
f orum Page types **<br />
„Forum “ 2.4 2.4<br />
Create a list of topics and allow users to place comments on the topic<br />
f un Experiences 0<br />
„Fun “ 2.4 2.4<br />
Add challenging and surprising elements to your site, supported by additional visual fun-adding<br />
details, to create a highly interactive and visual experience.<br />
global_navigation Getting Around **<br />
„Global Navigation “ 1.3.3 1.3.3<br />
Fortsetzung auf nächster Seite
164 ANHANG D. PATTERNKOMPONENTEN<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
Using a small section of every page, show a consistent set of links or buttons that take the user to<br />
key sections of the site or application.<br />
good_de f aults Getting Input From Users **<br />
„Good Defaults “ 2.4 2.4<br />
Wherever appropriate, prefill form fields with your best guesses at the values the user wants.<br />
grid_based_layout Drawing attention **<br />
„Grid-based layout “ 1.1 1.1<br />
Use a grid system for the placement and alignment of all visual objects on the web page<br />
guestbook Page types **<br />
„Guestbook “ 2.4 2.4<br />
Show comments and give the users the opportunity to give comments.<br />
guided_tour Basic interactions **<br />
„Guided Tour “ 2.4 2.4<br />
Show users how to do it in several interactive steps<br />
hel p_page Page types **<br />
„Help Page “ 2.4 2.4<br />
Place a link on every page to the Help page where users find help with the most common problems<br />
home Navigating around **<br />
„Home “ 1.3.1 1.3.4<br />
Use a fixed element, such as the site’s logo, as a link to the home page<br />
homepage Page types **<br />
„Home-page “ 2.4 2.4<br />
Create a home-page that introduces the site to users and that helps them to get on their way on the<br />
site<br />
hotlist Miscelleaneous **<br />
„Hotlist “ 2.4 2.4<br />
Show a hot-list of most popular items<br />
illustrated_choices Getting Input From Users **<br />
„Illustrated Choices “ 2.4 2.4<br />
Use pictures instead of words (or in addition to them) to show available choices.<br />
in f ormation_experience Experiences *<br />
„Information Seeking “ 2.4 2.4<br />
Primarily allow users to browse the information but combine it with more specific search tools that<br />
support other types of searching.<br />
inplace_replacement Dealing with data **<br />
„Inplace Replacement “ 2.4 2.1<br />
When selecting an item, create more space for the item and display additional details<br />
input_error Feedback **<br />
„Input Error Message “ 2.4 2.4<br />
Tell the users that there is a problem and how to solve the problem. Also tell the users where the<br />
problem occurred.<br />
input_hints Getting Input From Users **<br />
„Input Hints “ 1.3.3 1.3.3<br />
Fortsetzung auf nächster Seite
D.1. TABELLARISCHE EINORDNUNG 165<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
Beside an empty text field, place a sentence or example that explains what is required.<br />
input_prompt Getting Input From Users **<br />
„Input Prompt “ 1.3.4 1.3.4<br />
Prefill a text field or dropdown with a prompt that tells the user what to do or type.<br />
intriguing_branches Organizing the Content **<br />
„Intriguing Branches “ 2.3 2.3<br />
Place links to interesting content in unexpected places, and label them in a way that attracts the<br />
curious user.<br />
jump_to_item Showing Complex Data **<br />
„Jump to Item “ 1.1 1.3.1<br />
When the user types the name of an item, jump straight to that item and select it.<br />
language_selector Making choices **<br />
„Language Selector “ 1.3.1 1.3.1<br />
Ask the language spelled in the specific language<br />
learning Experiences **<br />
„Learning “ 2.4 2.4<br />
Construct a learning experience from the basic learning tasks that is in line with your audience and<br />
site<br />
liquid_layout Organizing the Page **<br />
„Liquid Layout “ 1.1 1.1<br />
As the user resizes the window, resize the page contents along with it so the page is constantly<br />
"filled.– Allow certain parts of the page to scale<br />
list_builder Dealing with data **<br />
„List Builder “ 2.1 2.1<br />
Present the total list and provide editing functionality next to it.<br />
list_entry_view Dealing with data *<br />
„List entry “ 2.1 2.1<br />
Show a simple entry form directly above the total list of items<br />
login Personalizing **<br />
„Login “ 1.3.3 1.3.3<br />
When needed, ask the users to login using a combination of an email-address and a password<br />
map_navigator Navigating around **<br />
„Map Navigator “ 1.2 1.2<br />
Show a map with the points of interest and provide navigation links in all corners<br />
meta_navigation Navigating around **<br />
„Meta Navigation “ 1.3.1 1.3.1<br />
Reserve an area on every page for communication and secondary navigation elements.<br />
minesweeping Navigating around **<br />
„Minesweeping “ 2.3 2.3<br />
Show graphical elements that upon mouse-over reveal their meaning<br />
movable_panels Organizing the Page **<br />
„Movable Panels “ 2.4 1.1<br />
Fortsetzung auf nächster Seite
166 ANHANG D. PATTERNKOMPONENTEN<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
Put different tools or sections of content onto separate panels, and let the user move them around to<br />
form a custom layout.<br />
multi_level_undo Commands and Actions **<br />
„Multi-Level Undo “ 1.4 1.3.3<br />
Provide a way to easily reverse a series of actions performed by the user.<br />
multinational Site types **<br />
„Multinational Site “ 2.4 2.4<br />
Create an proxy site that leads users to sub-sites.<br />
museum Site types **<br />
„Museum Site “ 2.4 2.4<br />
Create an informative site focussing on the museum main collection, activities and visitor information.<br />
Complement the site by offering online ticket sales, memberships and online shop.<br />
my_site Site types **<br />
„Personalized ’My’ Site “ 2.4 2.4<br />
Create a part of the site that belongs to a user and that is controlled by that user.<br />
news Miscelleaneous *<br />
„What’s new? “ 2.1 2.1<br />
Add a news section to the home page that contains the most recent news headlines.<br />
news_site Site types **<br />
„News Site “ 2.4 2.4<br />
Create a site with categorized articles that are accessible via headlines<br />
news_ticker Miscelleaneous *<br />
„News Ticker “ 1.3.1 1.3.1<br />
Use a box with scrolling text to display the latest info and place it at the top part of the page.<br />
newsletter Page types **<br />
„Newsletter “ 2.4 2.4<br />
Send users a newsletter regularly<br />
one_o f f _mode Builders and Editors **<br />
„One-Off Mode “ 2.4 2.4<br />
When a mode is turned on, perform the operation once. Then switch back automatically into the<br />
default or previous mode.<br />
one_window_drilldown Organizing the Content **<br />
„One-Window Drilldown “ 1.3.1 1.3.1<br />
Show each of the application’s pages within a single window. As a user drills down through a menu<br />
of options, or into an object’s details, replace the window contents completely with the new page.<br />
outgoing_links Drawing attention **<br />
„Outgoing Links “ 1.3.1 1.3.1<br />
Mark links to external sites with an icon after the label<br />
overlay_menu Navigating around **<br />
„Overlay Menu “ 1.3.1 1.1<br />
Present the menu at the mouse pointer location after the users click<br />
overview_plus_detail Showing Complex Data **<br />
Fortsetzung auf nächster Seite
D.1. TABELLARISCHE EINORDNUNG 167<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
„Overview Plus Detail “ 2.1 1.1<br />
Place an overview of the graphic next to a zoomed "detail view.Äs the user drags a viewport around<br />
the overview, show that part of the graphic in the detail view.<br />
paging Basic interactions **<br />
„Paging “ 1.3.3 1.3.3<br />
Present the results grouped in pages with a fixed number of items and allow the users to move easily<br />
from one page of items to another<br />
parts_selector Dealing with data **<br />
„Parts Selector “ 2.1 1.3.1<br />
Show all the parts and allow the user to add or remove a part from the selection list.<br />
poll Making choices **<br />
„Poll “ 1.3.1 1.3.1<br />
List the statements as exclusive options and present the results directly after voting.<br />
portals Site types **<br />
„Portal “ 2.4 2.4<br />
Create several sub-sites, one per topic, with one overall home-page<br />
printable_pages Page types **<br />
„Printable Pages “ 2.4 2.4<br />
Place a link to a printer-friendly version of the page the users are viewing next to the page content<br />
progress_indicator Commands and Actions **<br />
„Progress Indicator “ 1.1 1.1<br />
Show the user how much progress was made on a time-consuming operation.<br />
purchase_process Shopping **<br />
„Purchase Process “ 2.4 2.4<br />
Present users with the purchase steps<br />
rating Making choices **<br />
„Rating “ 1.3.3 1.3.3<br />
Present a rating next to the product and the option to rate it<br />
registration Personalizing **<br />
„Registration “ 1.3.3 1.3.3<br />
Offer users to possibility to store their personal information for later use<br />
responsive_disclosure Organizing the Page **<br />
„Responsive Disclosure “ 1.3.2 1.3.2<br />
responsive_enabling Organizing the Page **<br />
„Responsive Enabling “ 1.3.2 1.3.2<br />
Starting with a UI that’s mostly disabled, guide a user through a series of steps by enabling more of<br />
the UI as each step is done.<br />
retractable_menu Navigating around **<br />
„Retractable Menu “ 1.2 1.2<br />
Create a menu that can be put aside and easily retrieved again.<br />
row_striping Showing Complex Data **<br />
Fortsetzung auf nächster Seite
168 ANHANG D. PATTERNKOMPONENTEN<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
„Row Striping “ 1.3.4 1.3.3<br />
Use two similar shades to alternately color the backgrounds of the table rows.<br />
scrolling_menu Navigating around **<br />
„Scrolling Menu “ 1.3.1 1.3.1<br />
Show the items on a linear scrolling menu<br />
search Searching *<br />
„Simple Search “ 1.3.1 1.3.1<br />
Offer a search<br />
search_results Searching **<br />
„Search Results “ 2.4 2.4<br />
Present sorted results with a short description<br />
send_to_ f riend Miscelleaneous *<br />
„Send to a friend “ 1.3.1 1.3.4<br />
Offer a the possibility to send a email with a link to the item<br />
service Experiences **<br />
„Assistence Site “ 2.4 2.4<br />
Create a support section and back it up with additional searching facilities<br />
shopping Experiences **<br />
„Shopping Experience “ 2.4 2.4<br />
Create an online shopping experience that matches off-line shopping experiences<br />
site_index Searching *<br />
„Site Index “ 1.3.4 1.3.3<br />
Show all pages in an alphabetical index or by topic.<br />
slideshow Basic interactions **<br />
„Slideshow “ 1.2 1.2<br />
Show each image for some seconds and provide controls to manually navigate back and forward,<br />
pause/resume and stop/return<br />
smart_menu_items Commands and Actions **<br />
„Smart Menu Items “ 1.3.4 1.3.4<br />
Change menu labels dynamically to show precisely what they would do when invoked.<br />
smart_selection Builders and Editors **<br />
„Smart Selection “ 2.4 2.4<br />
Make the software smart enough to automatically select a coherent group of items, rather than making<br />
the user do it.<br />
sortable_table Showing Complex Data **<br />
„Sortable Table “ 1.3.2 1.3.1<br />
Show the data in a table, and let the user sort the table rows according to the column values.<br />
storytelling Experiences 0<br />
„Storytelling “ 2.4 2.4<br />
tag_cloud Searching **<br />
„Tag Cloud “ 2.2 1.2<br />
Fortsetzung auf nächster Seite
D.1. TABELLARISCHE EINORDNUNG 169<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
List the most common tags alphabetically and indicate their popularity by chaning the font size and<br />
weight<br />
teaser_menu Navigating around **<br />
„Teaser Menu “ 1.3.2 1.3.2<br />
Show a partial menu with ëxpand"capabilities<br />
testimonials Shopping *<br />
„Testimonials “ 2.4 2.4<br />
Allow users to give independent feedback on the quality product or services<br />
thumbnail Dealing with data *<br />
„Thumbnail “ 2.4 1.1<br />
Display a smaller version of the movie, image or page.<br />
titled_sections Organizing the Page **<br />
„Titled Sections “ 1.1 1.1<br />
Define separate sections of content by giving each one a visually strong title, and then laying them<br />
all out on the page together.<br />
top Navigating around **<br />
„To the Top “ 1.3.4 1.3.4<br />
Provide a link to the top of the page at locations in the main content<br />
topic_pages Searching **<br />
„Topic Pages “ 2.4 2.4<br />
Offer special topic pages with links to most relevant documents<br />
trail_menu Navigating around **<br />
„Trail Menu “ 1.3.3 1.3.3<br />
Show the traversed path in the menu<br />
travel_site Site types **<br />
„Travel Site “ 2.4 2.4<br />
Present a searchable database with booking possibilities<br />
tree_table Showing Complex Data **<br />
„Tree-Table “ 1.3.2 1.3.1<br />
Put hierarchical data in columns, like a table, but use an indented outline structure in the first column<br />
to illustrate the tree structure.<br />
tutorial Page types **<br />
„Tutorial “ 2.4 2.4<br />
two_panel_selector Organizing the Content **<br />
„Two-Panel Selector “ 1.3.1 1.3.1<br />
Put two side-by-side panels on the interface. In the first, show a set of items that the user can select<br />
at will; in the other, show the content of the selected item.<br />
visual_ f ramework Organizing the Page **<br />
„Visual Framework “ 1.4 1.4<br />
Design each page to use the same basic layout, colors, and stylistic elements, but give the design<br />
enough flexibility to handle varying page content.<br />
wizard Organizing the Content **<br />
Fortsetzung auf nächster Seite
170 ANHANG D. PATTERNKOMPONENTEN<br />
Tabelle D.1 – Fortsetzung<br />
Pattern-Id Kategorie Confidence<br />
Bezeichnung Klassifikation XUL Klassifikation Swing<br />
Kurzbeschreibung<br />
„Wizard “ 1.3.1 1.3.1<br />
Lead the user through the interface step by step, doing tasks in a prescribed order. — Take the user<br />
through the entire task one step at the time. Let the user step through the tasks and show which steps<br />
exist and which have been completed.
Abkürzungsverzeichnis<br />
AUI Abstract User Interface<br />
AWT ist das Abstract Windowing Toolkit. Es ist das ursprüngliche UI-Toolkit der Sprache Java und entstand<br />
als die Schnittmenge der auf allen Plattformen darstellbaren UI-Elemente. Diesem Ziel der<br />
maximalen Plattformunabhängigkeit wurden erweiterte Fähigkeiten verschiedener Plattformen geopfert.<br />
CUI Concrete User Interface<br />
DSL Domain Specific Language<br />
EMOF Essential MOF<br />
EMP Eclipse Modeling Project<br />
FUI Final User Interface<br />
GMF Graphical Modeling Framework<br />
HCI Human Computer Interaction / Mensch-Maschine-Kommunikation<br />
MD-UID Model Driven User Interface Development<br />
M2M Model To Model (Transformation)<br />
M2T Model To Text (Transformation)<br />
MDA Model Driven Architecture<br />
MDSD Model Driven Software Development<br />
MOF Meta Object Facility<br />
OMG Object Management Group<br />
PLML Patern Language Meta Language<br />
Swing als der Nachfolger und Komplementär <strong>von</strong> AWT wurde entwickelt, um solche erweiterten UI-<br />
Fähigkeiten, wie z.B. Drag&Drop, Tooltips oder Multi-Document-Interfaces auch für Java-Programme<br />
plattformunabhängig bereitzustellen. Um dies zu erreichen werden die Bildschirmelemente durch<br />
Swing selbst gezeichnet, es erfolgt keine Koppelung mit plattform-nativen Widgets.<br />
171
172 ABKÜRZUNGSVERZEICHNIS<br />
SWT ist das Standard Widget Toolkit, die Mächtigkeit <strong>von</strong> Swing und SWT ist vergleichbar. SWT koppelt<br />
jedoch die UI-Elemente mit nativen Widgets. Stellt die Plattform Widgets oder Funktionalitäten<br />
nicht zur Verfügung, werden diese durch SWT emuliert. SWT ist nicht auf alle Plattformen welche<br />
Java unterstützen portiert worden, dementsprechend sind Java-Programme die SWT nutzen nicht<br />
plattformunabhängig.<br />
tDSL textuelle DSL<br />
UI User Interface / Benutzungsschnittstelle<br />
UIDL User Interface Definition/Declaration Language<br />
WIMP Windows Icon Menu Pointer<br />
WPF Windows Presentation Foundation<br />
XHTML Extensible HyperText Markup Language, erweiterbares HTML, XML-konform
Tabellenverzeichnis<br />
1.1 Aufzählung bekannterer XML-basierter Sprachen zur UI-Definition . . . . . . . . . . . . 15<br />
2.1 Verfügbarkeit eines Metamodells für UIDLs aus Tabelle 1.1 . . . . . . . . . . . . . . . . 42<br />
3.1 Nicht im Webkatalog [123] enthaltene Patterns des Tidwell-Katalog [124] . . . . . . . . . 54<br />
3.2 Kurzübersicht der Semantik der PLML-Sprachelemente [38] . . . . . . . . . . . . . . . . 57<br />
3.3 Klassifikationskategorien zur Komponentisierbarkeit <strong>von</strong> Pattern, nach [6] . . . . . . . . . 70<br />
3.4 Problematische Patterneinträge in den Webkatalogen . . . . . . . . . . . . . . . . . . . . 75<br />
3.5 Größenordnungen zur Nacheditierung des verschmolzenen Katalogs . . . . . . . . . . . . 80<br />
3.6 Tabelle der als äquivalent zugeordneten Patterns . . . . . . . . . . . . . . . . . . . . . . . 81<br />
3.7 Kategorisierung der 135 Patterns des verschmolzenen Katalogs . . . . . . . . . . . . . . . 83<br />
3.8 Zuordnung der Classification-Literale zur Arnout’schen Einordnung . . . . . . . . . . . . 85<br />
3.9 Komponentisierbarkeitsvermutung mit XUL als CUI-Sprache . . . . . . . . . . . . . . . . 85<br />
3.10 Komponentisierbarkeitsvermutung mit Java Swing als CUI-System . . . . . . . . . . . . . 86<br />
4.1 Mapping <strong>von</strong> Java-Typen auf die Ecore-Äquivalente . . . . . . . . . . . . . . . . . . . . . 93<br />
4.2 Parameter zur Steuerung der Java⇒Ecore Transformation . . . . . . . . . . . . . . . . . . 97<br />
4.3 Modellgrößen für diverse Sichtbarkeitsstufen beim JDK-Parsing . . . . . . . . . . . . . . 98<br />
A.1 Temporale Operatoren zwischen Aufgaben in TEALLACH [56] . . . . . . . . . . . . . . 126<br />
A.2 Syntaxelemente für Selektorausdrücke in CSS, nach [25] . . . . . . . . . . . . . . . . . . 137<br />
D.1 Patternkurzbeschreibungen und Komponentisierbarkeitsvermutung . . . . . . . . . . . . . 159<br />
173
174 TABELLENVERZEICHNIS
Abbildungsverzeichnis<br />
1.1 Inhaltsübersicht, als Instanz des Forschungsframeworks nach Hevner [60] . . . . . . . . . 1<br />
1.2 Instanzen und Modelle im EMOF-Zusammenhang . . . . . . . . . . . . . . . . . . . . . 7<br />
1.3 Zeitliche Einordnung diverser MB-UID Systeme und Umgebungen . . . . . . . . . . . . . 9<br />
1.4 Die vier Abstraktionsebenen des CAMELEON-Referenzframeworks nach [17] . . . . . . 11<br />
1.5 Beispielhafte CAMELEON-Klassifikation, nach [17] . . . . . . . . . . . . . . . . . . . . 12<br />
1.6 Modellzusammenhänge im MARIA-Migrationsprozess, nach [88] . . . . . . . . . . . . . 16<br />
1.7 Klassendiagrammdarstellung des UsiXML-Schema, nach [139] . . . . . . . . . . . . . . . 17<br />
2.1 Transformationsorientierter MDD-Entwicklungsprozess . . . . . . . . . . . . . . . . . . . 25<br />
2.2 Metamodell für das Aufgabenmodell nach [150] . . . . . . . . . . . . . . . . . . . . . . . 27<br />
2.3 Aufgabenmodell für die Klausurenkontrolle in der Rostocker Notation . . . . . . . . . . . 28<br />
2.4 Metamodell für das Nutzermodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
2.5 Allgemeines Objekt-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
2.6 Gegenüberstellung Objektmodelleditor und UML-Modell . . . . . . . . . . . . . . . . . . 31<br />
2.7 Syntaxelemente eines Dialoggraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
2.8 Beispiel eines Dialoggraphen, entnommen aus [105] . . . . . . . . . . . . . . . . . . . . 33<br />
2.9 Metamodell Dialoggraph nach [44] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
2.10 Annotiertes Aufgabenmodell und abgeleiteter Dialoggraph, nach [150] . . . . . . . . . . . 35<br />
2.11 Screenshot-Sequenz eines generierten Navigationsprototypen . . . . . . . . . . . . . . . . 36<br />
2.12 Metamodell für AUI im X-AIM Prozess, Grundstruktur nach [78] . . . . . . . . . . . . . 39<br />
2.13 Metamodell für AUI im X-AIM Prozess, Widgets nach [78] . . . . . . . . . . . . . . . . . 39<br />
2.14 Adaptiertes AUI-Metamodell, Grundstruktur . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />
2.15 Adaptiertes AUI-Metamodell, Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41<br />
2.16 Ausschnitt des XUL-Metamodells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45<br />
2.17 XULE - XUL-UI im Bearbeitungsmodus geöffnet . . . . . . . . . . . . . . . . . . . . . . 46<br />
2.18 XULE - Strukturübersicht und Eigenschaftenbearbeitung . . . . . . . . . . . . . . . . . . 47<br />
3.1 Hilfsklassen im PLML-Metamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61<br />
175
176 ABBILDUNGSVERZEICHNIS<br />
3.2 Kern des PLML-Metamodells, Deklaration eines Patterneintrags . . . . . . . . . . . . . . 62<br />
3.3 Zusammenhang der Modelle des GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64<br />
3.4 Screenshot eines exemplarischen graphischen PLML-Editors als Eclipse-Plugin . . . . . . 66<br />
3.5 Verwendung <strong>von</strong> Pattern im MDD-UI Prozess . . . . . . . . . . . . . . . . . . . . . . . . 68<br />
3.6 Verarbeitungskette zur Erstellung des PLML-Kataloges aus dem Tidwell-Webkatalog . . . 72<br />
3.7 Intrakatalogreferenzen beim Tidwell-Katalog [123] . . . . . . . . . . . . . . . . . . . . . 74<br />
3.8 Intrakatalogreferenzen beim Welie-Katalog [136] . . . . . . . . . . . . . . . . . . . . . . 75<br />
3.9 Metamodell für PLMLComponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78<br />
3.10 Zusammenhänge und Transformationen <strong>von</strong> PLML und PLMLComponent . . . . . . . . . 79<br />
4.1 JavaDocs Java-Metamodell ohne Methoden . . . . . . . . . . . . . . . . . . . . . . . . . 96<br />
4.2 Zusammenhang zwischen Wrapper und EMF-Generator . . . . . . . . . . . . . . . . . . 102<br />
4.3 Taschenrechner-Anwendung und geparste Modellinstanz im Standardeditor . . . . . . . . 104<br />
4.4 Container-Infrastruktur mit Swing-Ecore und XUL-Generator . . . . . . . . . . . . . . . 105<br />
4.5 Visualisierung des Layoutalgorithmus für XUL . . . . . . . . . . . . . . . . . . . . . . . 107<br />
4.6 Drei Renderer des XUL-Snapshots der Taschenrechneranwendung . . . . . . . . . . . . . 109<br />
A.1 DRIVE - Modellsystem, nach [77] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125<br />
A.2 Schrittfolge im TERESA-Migrationsprozess zur Übertragung der Benutzeroberfläche, nach<br />
[13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134<br />
A.3 UIML – Teilmodelle und Zusammenhänge nach [1] . . . . . . . . . . . . . . . . . . . . . 135
Listings<br />
2.1 EBNF Grammatik für die Sichtzuordnung <strong>von</strong> Aufgaben . . . . . . . . . . . . . . . . . . 34<br />
2.2 Ausschnitt aus einem xPand-Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36<br />
3.1 DTD des PLML-Standard [91] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56<br />
3.2 Einführung eines Elementes für Katalog-Metadaten . . . . . . . . . . . . . . . . . . . . . 58<br />
3.3 QVTo/OCL Testselektion zur Qualitätssicherung der PLMLComponent-Instanz . . . . . . 80<br />
3.4 QVTo/OCL Sprachvergleichsabfrage über dem PLMLComponent-Metamodell . . . . . . 86<br />
4.1 Sichtbarkeitsüberlagerung bei gleichbenannten Attributen . . . . . . . . . . . . . . . . . . 92<br />
4.2 Potentielles Modellierungsproblem bei kontravariantem Ausgabeparametertyp . . . . . . . 92<br />
A.1 Ausschnitt einer UI-Spezifikation mit der UIDE-IDL . . . . . . . . . . . . . . . . . . . . 119<br />
A.2 Regeldefinition für DON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121<br />
A.3 Syntaxstruktur und beispielhafte Verwendung <strong>von</strong> CSS . . . . . . . . . . . . . . . . . . . 136<br />
A.4 XUL-Minimalbeispiel mit CSS und JavaScript . . . . . . . . . . . . . . . . . . . . . . . . 138<br />
B.1 PLML DTD, Sprachversion 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139<br />
B.2 PLML DTD, Sprachversion 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141<br />
B.3 PLML xText Grammatik, Sprachversion 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . 143<br />
B.4 Beispielkatalog mit der PLML-tDSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145<br />
B.5 XUL mit relativer Positionierung für das Demonstrationsbeispiel . . . . . . . . . . . . . . 147<br />
C.1 Minimal-XUL zur Illustration der Tab-Verschachtelung . . . . . . . . . . . . . . . . . . . 151<br />
C.2 Einschränkung des Wertebereichs für confidence-Angaben . . . . . . . . . . . . . . . . . 151<br />
C.3 Annotation <strong>von</strong> Illustrations-URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152<br />
C.4 Notation <strong>von</strong> Literaturreferenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152<br />
C.5 Notation <strong>von</strong> Patternverlinkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152<br />
C.6 Notation <strong>von</strong> Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153<br />
C.7 xText-Grammatikausschnitt zur Eintragung <strong>von</strong> Patternbeziehungen . . . . . . . . . . . . 153<br />
177
178 LISTINGS
Algorithmenverzeichnis<br />
1 Modellreduzierungsalgorithmus nach [112] . . . . . . . . . . . . . . . . . . . . . . . . . 100<br />
2 Layout-Bildung mit relativen Koordinatenangaben . . . . . . . . . . . . . . . . . . . . . 107<br />
179
Index<br />
ADEPT, 127<br />
CAMELEON, 11<br />
CSS, 136<br />
DON, 120<br />
DRIVE, 124<br />
EclipseXML, 20<br />
FUSE, 129<br />
GIML, 20<br />
HUMANOID, 122<br />
JavaScript, 137<br />
L-CID, 132<br />
MASTERMIND, 128<br />
MDA, 7<br />
MDSD, 6<br />
MECANO, 132<br />
MOBI-D, 133<br />
SwiXML, 20<br />
T:XML, 21<br />
TADEUS, 130<br />
TEALLACH, 125<br />
TRIDENT, 131<br />
UIDE, 119<br />
UIML, 135<br />
useML, 21<br />
WIMP, 23<br />
WML, 20<br />
XAML, 19<br />
XIML, 18<br />
180
Literaturverzeichnis<br />
[1] Marc Abrams, Constantinos Phanouriou, Alan L. Batongbacal, Stephen M. Williams, and Jonathan<br />
E. Shuster. Uiml: an appliance-independent xml user interface language. Comput. Netw.,<br />
31(11-16):1695–1708, 1999.<br />
[2] Adobe. Mxml 2009 - functional and design specification. http://opensource.adobe.com/<br />
wiki/display/flexsdk/MXML+2009, 2010-05-25.<br />
[3] Pierre alain Muller, Franck Fleurey, Zoé Drey, Damien Pollet, and Frédéric Fondement. On executable<br />
meta-languages applied to model transformations. In in Model Transformations In Practice<br />
Workshop, Montego, 2005.<br />
[4] Christopher Alexander. A Pattern Language. Towns, Buildings, Construction. Oxford University<br />
Press, 1977.<br />
[5] Antlr - another tool for language recognition. http://www.antlr.org, 2009-06-06. University<br />
of San Francisco.<br />
[6] Karine Arnout. From Pattern to Components. PhD thesis, ETH Zurich, 2004.<br />
[7] Ramin Assisi. Visual builder for eclipse. http://v4all.sourceforge.net, 2009-06-06.<br />
[8] Moose Association. Famix core 3.0. http://www.moosetechnology.org/docs/famix/<br />
3.0, 2010-05-25.<br />
[9] Moose Association. Moose - a platform for software and data analysis. http://www.<br />
moosetechnology.org/, 2010-05-25.<br />
[10] Moose Association. Mse - ein generisches datenformat. http://scg.unibe.ch/wiki/<br />
projects/fame/mse, 2010-05-25.<br />
[11] Moose Association. Xwt. http://www.moosetechnology.org/docs/famix/3.0,<br />
2010-05-25.<br />
[12] Auiml - abstract user interface markup language toolkit. IBM Alphaworks, Projekt eingestellt.<br />
[13] Silvia Berti and Fabio Paternò. Migratory multimodal interfaces in multidevice environments. In<br />
ICMI ’05: Proceedings of the 7th international conference on Multimodal interfaces, pages 92–99,<br />
New York, NY, USA, 2005. ACM.<br />
[14] Christian Beutenmüller. Deklarative xml-sprachen für benutzerschnittstellen. http://<br />
ebus.informatik.uni-leipzig.de/www/media/lehre/uiseminar05/<br />
ausarbeitung-beutenmueller.pdf, 2010-05-25, 2005. Seminararbeit.<br />
181
182 LITERATURVERZEICHNIS<br />
[15] Alexander Boedcher, Kizito Mukasa, and Detlef Zuehlke. Capturing common and variable design<br />
aspects for ubiquitous computing with mb-uid. In MDDoAUI 2005, Proceedings, 2005.<br />
[16] Jens Brüning and Andreas Wolff. Declarative models for business processes and ui generation using<br />
ocl. In The Pragmatics of OCL and Other Textual Specification Languages, Workshop at MODELS<br />
2009, 2009.<br />
[17] Gaëlle Calvary, Joëlle Coutaz, David Thevenin, Quentin Limbourg, Laurent Bouillon, and Jean Vanderdonckt.<br />
A unifying reference framework for multi-target user interfaces. Interacting with Computers,<br />
15(3):289 – 308, 2003. Computer-Aided Design of User Interface.<br />
[18] Thomas K. Card, Thomas P. Moran, and Allen Newell. The psychology of human-computer interaction.<br />
Lawrence Erlbaum Associates Inc., 1983.<br />
[19] Peter Pin-Shan Chen. The entity-relationship model—toward a unified view of data. ACM Trans.<br />
Database Syst., 1(1):9–36, 1976.<br />
[20] Joanna Chimiak–Opoka, Birgit Demuth, Darius Silingas, and Nicolas F. Rouquette. Requirements<br />
analysis for an integrated ocl development environment. In The Pragmatics of OCL and Other<br />
Textual Specification Languages, Workshop at MODELS 2009, 2009.<br />
[21] World Wide Web Consortium. Xsl transformations (xslt) version 2.0. http://www.w3.org/<br />
TR/xslt20/, 2010-06-06. W3C Recommendation 23 January 2007.<br />
[22] IBM Corporation. Generate code with eclipse’s java emitter templates. http://www.ibm.com/<br />
developerworks/library/os-ecemf2/, 2010-06-06. Online Tutorial.<br />
[23] Yahoo! Corporation. Yahoo! design pattern library. http://developer.yahoo.com/<br />
ypatterns/, 2010-06-06.<br />
[24] Simon Crowle and Linda Hole. Isml: An interface specification meta-language. In Interactive<br />
Systems. Design, Specification, and Verification, pages 255–268, 2003.<br />
[25] Cascading style sheets level 2 revision 1 (css 2.1) specification. http://www.w3.org/TR/<br />
CSS2/, 2010-02-05.<br />
[26] Concurtasktrees environment. http://giove.isti.cnr.it/tools/ctte/index.<br />
html, 2010-02-15.<br />
[27] Erwin Cuppens, Chris Raymaekers, and Karin Coninx. Vrixml: A user interface description language<br />
for virtual environments. In Developing User Interfaces with XML: Advances on User Interface<br />
Description Languages, pages 111–117, Mai 2004.<br />
[28] Andy Dearden and Janet Finlay. Pattern languages in hci: A critical review. Human-Computer<br />
Interaction 21(1), Januar 2006.<br />
[29] T. DeMarco. Structured analysis and system specification. Yourdon Press, Upper Saddle River, NJ,<br />
USA, 1979.<br />
[30] Christian Diebow. Entwicklung eines konzeptes zur interaktiven transformation <strong>von</strong> aufgabenmodellen<br />
in navigationsmodelle. Master’s thesis, Universität Rostock, 2008.<br />
[31] Sahin Albayrak Dirk Roscher, Marco Blumendorf. Multimodal user interface model for runtime<br />
distribution. In MDDoAUI 2010, Proceedings, pages 5–8, April 2010.
LITERATURVERZEICHNIS 183<br />
[32] Anke Dittmar and Peter Forbrig. Task-based design revisited. In EICS ’09: Proceedings of the<br />
1st ACM SIGCHI symposium on Engineering interactive computing systems, pages 111–116, New<br />
York, NY, USA, 2009. ACM.<br />
[33] Ecmascript language specification, ecma-262. http://www.ecma-international.org/<br />
publications/files/ECMA-ST/ECMA-262.pdf, 2010-02-05.<br />
[34] Sven Efftinge, Peter Friese, Arno Haase, Dennis Hübner, Clemens Kadura, Bernd Kolb,<br />
Jan Köhnlein, Dieter Moroff, Karsten Thoms, Markus Völter, Patrick Schönbach, Moritz<br />
Eysholdt, Dennis Hübner, and Steven Reinisch. openarchitectureware user guide, version<br />
4.3.1. http://www.openarchitectureware.org/pub/documentation/4.3.1/<br />
openArchitectureWare-4.3.1-Reference.pdf, 2010-09-30.<br />
[35] Sven Efftinge and Markus Voelter. oaw xtext: A framework for textual dsls.<br />
http://eclipsesummit.org/summiteurope2006/presentations/<br />
ESE2006-EclipseModelingSymposium12_xTextFramework.pdf, 2009-06-06.<br />
[36] Eclipse modeling framework project. http://www.eclipse.org/modeling/emf/?<br />
project=emf, 2009-06-06. Eclipse Foundation.<br />
[37] Eclipse modeling project. http://www.eclipse.org/modeling/, 2010-05-25. Eclipse<br />
Foundation.<br />
[38] Sally Fincher. Perspectives on hci patterns: concepts and tools (introducing plml). In Workshop at<br />
CHI 2003, September 2003.<br />
[39] D. Fogli, G. Fresta, A. Marcante, and P. Mussio. Im2l: A user interface description language supporting<br />
electronic annotation. In Proc. Workshop on Developing User Interface with XML: Advances<br />
on User Interface Description Languages, pages 135–142, May 2004.<br />
[40] J. Foley, C. Gibbs, and S. Kovacevic. A knowledge-based user interface management system. In<br />
CHI ’88: Proceedings of the SIGCHI conference on Human factors in computing systems, pages<br />
67–72, New York, NY, USA, 1988. ACM.<br />
[41] James Foley, Won Chul Kim, Srdjan Kovacevic, and Kevin Murray. Uide—an intelligent user interface<br />
design environment. In Intelligent user interfaces, pages 339–384, New York, NY, USA, 1991.<br />
ACM.<br />
[42] Won Chul Kim; James D. Foley;. Don: User interface presentation design assistant, 1990.<br />
[43] Eelke Folmer. Interaction design patterns for games library. http://www.helpyouplay.<br />
com/wiki/index.php5?title=Main_Page, 2010-06-06.<br />
[44] Peter Forbrig, Daniel Reichard, and Andreas Wolff. User interfaces from task models. In MDSE’08,<br />
2008.<br />
[45] Eclipse Foundation. Atl modell-zoo. http://www.eclipse.org/m2m/atl/<br />
atlTransformations/, 2010-06-06.<br />
[46] Eclipse Foundation. Eclipse toolkit model. http://wiki.eclipse.org/E4/UI/<br />
Toolkit_Model, 2010-05-25.<br />
[47] Eclipse Foundation. Graphical editing framework. http://www.eclipse.org/gef/, 2010-<br />
05-25.
184 LITERATURVERZEICHNIS<br />
[48] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns - Elements of<br />
Reusable Object-Oriented Software. Addison-Wesley, 24th edition, 2002.<br />
[49] Gecko rendering engine für xul. https://developer.mozilla.org/de/Gecko, 2010-03-<br />
05. Mozilla Corporation.<br />
[50] Gibbs, Kim, and Foley. Case studies in the use of udl: Interface definition language, 1990.<br />
[51] Dtd der giml. http://gitk.sourceforge.net/giml.dtd, 2010-03-04. GITK Sourceforge<br />
Projekt.<br />
[52] Eclipse graphical modeling framework project. http://www.eclipse.org/modeling/<br />
gmf/, 2009-06-06. Eclipse Foundation.<br />
[53] Martin Gogolla, Fabian Büttner, and Mark Richters. Use: A uml-based specification environment<br />
for validating uml and ocl. Science of Computer Programming, pages 69:27–34, 2007.<br />
[54] Mohammed Gomaa, Akram Salah, and Syed Rahman. Towards a better model based user interface<br />
development environment: A comprehensive survey. http://www.micsymposium.org/<br />
apache2-default/mics_2005/papers/paper72.pdf, 2009-07-02, 2005. Midwest Instruction<br />
and Computing Symposium.<br />
[55] Peter Forbrig Gregor Buchholz. Analyse <strong>von</strong> handlungsprotokollen zur modellbildung. Mensch &<br />
Computer 2010 München: Oldenbourg Verlag, pages 361–370, 2010.<br />
[56] Tony Griffiths, Peter Barclay, Jo Mckirdy, Norman Paton, Philip Gray, Jessie Kennedy, Richard<br />
Cooper, Carole Goble, Adrian West, and Michael Smyth. Teallach: A model-based user interface<br />
development environment for object databases. In In Proceedings of UIDIS’99, pages 86–96. IEEE<br />
Press, 1999.<br />
[57] Hans Grönniger, Holger Krahn, Bernhard Rumpe, Martin Schindler, and Steven Völkel. Text-based<br />
modeling. In 4th International Workshop on Language Engineering (ATEM 2007), 2007.<br />
[58] Object Management Group. Mof model to text transformation language. http://www.omg.<br />
org/spec/MOFM2T/1.0/, 2010-06-06. Sprachstandard Version 1.0.<br />
[59] Dennis E. Hamilton. Trost pattern format. http://trosting.org/info/2005/08/<br />
i050803c.htm.<br />
[60] Alan R. Hevner, Salvatore T. March, Jinsoo Park, and Sudha Ram. Design science in information<br />
systems research. MIS Quarterly, 28(1):75–105, 2004.<br />
[61] C. A. R. Hoare. Communicating sequential processes. Commun. ACM, 21(8):666–677, 1978.<br />
[62] et al. HSH Nordbank AG. Docfactory. http://wwwswt.informatik.uni-rostock.de/<br />
deutsch/Mitarbeiter/andreas/docfactory.html, 2010-06-06.<br />
[63] Workshop im Rahmen Advanced Visual Interfaces 2004. Linking gui elements to tasks – supporting<br />
an evolutionary design process. In Developing User Interfaces with XML: Advances on User<br />
Interface Description Languages, Gallipoli, Italy, 2005.<br />
[64] Open architecure ware - projekthauptseite. http://oaw.itemis.de/, 2010-03-18. Itemis AG.<br />
[65] Java community process, fragen und antworten zu. http://www.jcp.org/en/<br />
introduction/faq#general, 2010-03-05.
LITERATURVERZEICHNIS 185<br />
[66] Hilary Johnson and Peter Johnson. Task knowledge structures: Psychological basis and integration<br />
into system design. Acta Psychologica, 78(1-3):3 – 26, 1991.<br />
[67] Frédéric Jouault, Freddy Allilaire, Jean Bézivin, Ivan Kurtev, and Patrick Valduriez. Atl: a qvt-like<br />
transformation language. In OOPSLA ’06: Companion to the 21st ACM SIGPLAN symposium on<br />
Object-oriented programming systems, languages, and applications, pages 719–720, New York, NY,<br />
USA, 2006. ACM.<br />
[68] Kermeta meta programming environment. http://www.kermeta.org, 2010-01-28.<br />
[69] Thomas Kirste. Lehrmaterialien programmierungstechnik i, ws 2006.<br />
[70] Stefan Kost. Dynamically generated multi-modal application interfaces. PhD thesis, Technical<br />
University Dresden, 2006.<br />
[71] Eric Krock. Welcome to the navigator 5 xul newsgroup! http://groups.<br />
google.com/group/netscape.public.dev.xul/browse_thread/thread/<br />
d75112c638f8f72e, 2010-05-25, 1999. Usenet-Posting durch verantwortlichen Netscape-<br />
Mitarbeiter.<br />
[72] Quentin Limbourg, Costin Pribeanu, and Jean Vanderdonckt. Towards uniformed task models in a<br />
model-based approach. In Lecture Notes in Computer Science Volume 2220/2001, pages 164–182,<br />
2001.<br />
[73] P. Markopoulos, J. Pycock, S. Wilson, and P. Johnson. Adept - a task based design environment,<br />
1992.<br />
[74] Mda guide version 1.0.1. http://www.omg.org/cgi-bin/doc?omg/03-06-01, 2009-<br />
07-06. Object Management Group.<br />
[75] Microsoft. Pattlet definition. http://guidanceexplorer.codeplex.com/wikipage?<br />
title=GuidanceExplorerOverview, 2010-06-06.<br />
[76] Microsoft. Extensible application markup language. http://msdn.microsoft.com/<br />
en-us/library/ms752059.aspx, 2010-05-25, 2004. XAML.<br />
[77] Kenneth Mitchell and Jessie B Kennedy. An environment for the organised construction<br />
of user-interfaces to databases. http://www.soc.napier.ac.uk/publication/op/<br />
getpublication/publicationid/4151, 2009-07-01, 1995. Technischer Bericht, freigegeben<br />
zur Veröffentlichung.<br />
[78] Andreas Müller. Spezifikation geräteunabhängiger Benutzerschnittstellen durch Markup-Konzepte.<br />
PhD thesis, Universität Rostock, 2003.<br />
[79] Metamodelle im mdd-prozess. http://www.ptbv.de/metamodels, 2010-01-01. Eigene<br />
Homepage.<br />
[80] Meta object facility (mof), version 1.4. http://www.omg.org/cgi-bin/doc?formal/<br />
2002-04-03, 2009-07-01, 2002. öffentliche Spezifikation.<br />
[81] Meta object facility (mof), version 2.0. http://www.omg.org/cgi-bin/doc?formal/<br />
2006-01-01, 2010-07-23, 2006. öffentliche Spezifikation.
186 LITERATURVERZEICHNIS<br />
[82] Giulio Mori, Fabio Paternò, and Carmen Santoro. Design and development of multi-device user<br />
interfaces through multiple logical descriptions. IEEE Transactions on Software Engineering,<br />
30(8):507–520, Aug 2004.<br />
[83] Obeo. Acceleo : Mda generator. http://www.acceleo.org/pages/home/en, 2010-06-<br />
06.<br />
[84] Object constraint language, version 2.2. http://www.omg.org/spec/OCL/2.2/, 2010-10-<br />
01, 2010. öffentliche Spezifikation.<br />
[85] Mda guide version 1.0.1. http://www.omg.org/cgi-bin/doc?omg/03-06-01, 2010-<br />
02-15.<br />
[86] David Paquette and Kevin A. Schneider. Task model simulation using interaction templates. pages<br />
78–89, 2006.<br />
[87] Fabio Paternò. Model-Based Design and Evaluation of interactive applications. Springer, ISBN<br />
1-852-33155-0, 1999.<br />
[88] Fabio Paterno’, Carmen Santoro, and Lucio Davide Spano. Maria: A universal, declarative, multiple<br />
abstraction-level language for service-oriented applications in ubiquitous environments. ACM Trans.<br />
Comput.-Hum. Interact., 16(4):1–30, 2009.<br />
[89] Wolf Paulus. Swixml. http://www.swixml.org, 2010-06-03.<br />
[90] Roland Petrasch. Model based user interface design: Model driven architecture und hci<br />
patterns. http://pi.informatik.uni-siegen.de/stt/27_3/03_Technische_<br />
Beitraege/MDA_HCI_Patterns_Petrasch_Short.pdf, 2009-06-06.<br />
[91] Dtd of plml. http://www.hcipatterns.org/tiki-download_file.php?<br />
fileId=7, 2009-06-06.<br />
[92] Sourceforge Projekt. Html tidy library project. http://tidy.sf.net, 2010-03-03.<br />
[93] Angel Puerta. The mecano project: Comprehensive and integrated support for model-based interface<br />
development. In In Computer-Aided Design of User Interfaces, pages 5–7. Namur University Press,<br />
1996.<br />
[94] Angel Puerta and Jacob Eisenstein. Ximl: A universal language for user interfaces. http://www.<br />
ximl.org/documents/XimlWhitePaper.pdf, 2010-05-25.<br />
[95] Angel Puerta and Martin Hu. Ui fin: A process-oriented interface design tool. In IUI 2009 - Sanibel<br />
Island, Florida, USA, pages 345–354, 2009.<br />
[96] Angel R. Puerta. Rapid prototyping of self-adaptive interfaces with the l-cid model. In In Proceedings<br />
of the Intelligent Multimedia Interfaces Workshop, AAAI-91, pages 37–46, 1991.<br />
[97] Angel R. Puerta and David Maulsby. Mobi-d: a model-based development environment for usercentered<br />
design. In CHI ’97: CHI ’97 extended abstracts on Human factors in computing systems,<br />
pages 4–5, New York, NY, USA, 1997. ACM.<br />
[98] Query view transformation. http://www.omg.org/spec/QVT/1.0/, 2010-08-11, 2008. öffentliche<br />
Spezifikation.
LITERATURVERZEICHNIS 187<br />
[99] Robert Rathsack. <strong>Generierung</strong> <strong>von</strong> geraetespezifikationen aus abstrakten spezifikationen unter beachtung<br />
<strong>von</strong> hci pattern. Master’s thesis, Rostock University, 2006.<br />
[100] Robert Rathsack, Andreas Wolff, and Peter Forbrig. Using hci-patterns with model-based generation<br />
of advanced user-interfaces. In Andreas Pleuss, Jan Van den Bergh, Heinrich Hussmann, Stefan<br />
Sauer, and Alexander Boedcher, editors, Proceedings of the MoDELS’06 Workshop on Model Driven<br />
Development of Advanced User Interfaces, Genova, October 2006.<br />
[101] Lopez-Jaquero; Montero; Real. Designing user interface adaptation rules with t:xml. In IUI 2009 -<br />
Sanibel Island, Florida, USA, 2009.<br />
[102] In R.E.M. 2009, Workshop at WCRE 2009, October 2009.<br />
[103] Achim Reuther. Systematische Entwicklung <strong>von</strong> Maschinenbediensystemen mit XML. PhD thesis,<br />
Technische Universität Kaiserslautern, 2003.<br />
[104] Uniform resource locators. http://www.ietf.org/rfc/rfc1738.txt, 2009-06-19. IETF<br />
- RFC 1738.<br />
[105] Sven Rieckerhoff. Modularisierung <strong>von</strong> navigationsspezifikationen unter berücksichtigung <strong>von</strong> hcipatterns.<br />
Master’s thesis, Universität Rostock, 2006.<br />
[106] Kinan Samaan and Franck Tarpin-Bernard. Task models and interaction models in a multiple user<br />
interfaces generation process. In TAMODIA ’04: Proceedings of the 3rd annual conference on Task<br />
models and diagrams, pages 137–144, New York, NY, USA, 2004. ACM.<br />
[107] Edgar Schlungbaum and Thomas Elwert. Dialogue graphs - a formal and visual specification technique<br />
for dialogue modelling. In BCS-FACS Workshop on Formal Aspects of the Human Computer<br />
Interface. BCS, British Computer Society, 1996.<br />
[108] Thomas Schlungbaum, Egbert; Elwert. Dialogue graphs - a formal and visual specification technique<br />
for dialogue modelling. In Procedings of the BCS-FACS Workshop on Formal Aspects of the Human<br />
Computer Interface, 1993.<br />
[109] Uwe Schneider and Dieter Werner. Taschenbuch der Informatik. Fachbuchverlag Leipzig, 2000.<br />
[110] Enrico Schnepel. Gengmf: Efficient editor development for large meta models using the graphical<br />
modelling framework. In SIG-MDSE 2008, Transformations and Tools, 2008.<br />
[111] Lonczewski; Schreiber. The fuse system: an integrated user interface design environment, 1996.<br />
[112] Sagar Sen, Naouel Maha, Benoit Baudry, and Jean-Marc Jezequel. Meta-model pruning. In Models<br />
2009, Proceedings, pages 32–46, 2009.<br />
[113] Herbert Stachowiak, editor. Allgemeine Modelltheorie. Springer, Wien [u.a.], 1973.<br />
[114] C. Stary. Tadeus: seamless development of task-based and user-oriented interfaces. Systems, Man<br />
and Cybernetics, Part A: Systems and Humans, IEEE Transactions on, 30(5):509 –525, sep 2000.<br />
[115] David Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks. EMF Eclipse Modeling<br />
Framework, Second Edition. Addison-Wesley, 2009.<br />
[116] K. Stirewalt and S. Rugaber. Automating ui generation by model composition. Automated Software<br />
Engineering, International Conference on, 0:177, 1998.
188 LITERATURVERZEICHNIS<br />
[117] R. E. Kurt Stirewalt. The design and implementation of the mastermind toolkit. http://<br />
smartech.gatech.edu/handle/1853/3540, 2010-11-30.<br />
[118] Scalable vector graphics. http://www.w3.org/TR/SVG11/, 2010-02-15. W3C-Standard,<br />
V1.1.<br />
[119] Pedro Szekely, Ping Luo, and Robert Neches. Facilitating the exploration of interface design alternatives:<br />
the humanoid model of interface design. In CHI ’92: Proceedings of the SIGCHI conference<br />
on Human factors in computing systems, pages 507–515, New York, NY, USA, 1992. ACM.<br />
[120] Pedro A. Szekely, Piyawadee Noi Sukaviriya, Pablo Castells, Jeyakumar Muthukumarasamy, and<br />
Ewald Salcher. Declarative interface models for user interface construction tools: the mastermind approach.<br />
http://portal.acm.org/citation.cfm?id=645348.650690, 2010-11-30,<br />
1996.<br />
[121] Teresa xml standards. http://giove.isti.cnr.it/tools/TERESA/teresa_xml.<br />
html, 2010-02-15.<br />
[122] David Thevenin and Joelle Coutaz. Plasticity of user interfaces: Framework and research agenda. In<br />
Human-computer interaction INTERACT’99, pages 110–116. IOS Press, 1999.<br />
[123] Jennifer Tidwell. Patterns for effective interaction design. http://www.<br />
designinginterfaces.com, 2009-06-06.<br />
[124] Jennifer Tidwell. Designing Interfaces. O’Reilly Media, Inc., 1005 Gravenstein Highway North<br />
Sebastopol, CA 95472 USA, 2006.<br />
[125] Frederic Toussaint. Grafische Benutzungsunterstützung auf Befehlsebene für die Entwicklung massivparalleler<br />
Programme. PhD thesis, Universität Karlsruhe, 2007.<br />
[126] Anders Toxboe. User interface design patterns. http://ui-patterns.com, 2010-06-06.<br />
[127] Bruce Trask and Angel Roman. Model driven engineering. In R.E.M. 2009, Workshop at WCRE<br />
2009, September 2009.<br />
[128] Spezifikation <strong>von</strong> uiml. http://www.oasis-open.org/committees/download.php/<br />
5937/uiml-core-3.1-draft-01-20040311.pdf, 2010-03-04. UIML Projekt.<br />
[129] Auflistung/verlinkung uiml-renderer. http://www.uiml.org/tools/index.htm, 2010-<br />
09-24. UIML Projekt.<br />
[130] Uml infrastrucutre specifikation, version 2.3. http://www.omg.org/spec/UML/2.3/<br />
Infrastructure/PDF/, 2010-07-23, 2006. öffentliche Spezifikation.<br />
[131] Schema und werkzeuge für useml. http://www.uni-kl.de/pak/useML/, 2010-03-04.<br />
UsiXML Projekt.<br />
[132] Schema und modelle für usixml. http://www.usixml.org/index.php?mod=pages&<br />
id=5, 2010-03-04. UsiXML Projekt.<br />
[133] Usixml itea projekt. http://itea.defimedia.be/about-the-project, 20010-25-05.<br />
[134] State of the art of user interface description languages. http://itea.defimedia.be/<br />
sites/default/files/UsiXML_D1.1_Final.doc, 2005-06-02. Zum Abrufzeitpunkt als<br />
Rohversion vorliegend.
LITERATURVERZEICHNIS 189<br />
[135] R. Van Buskirk and B. W. Moroney. Extending prototyping. IBM Syst. J., 42:613–623, October<br />
2003.<br />
[136] Martijn van Welie. Patterns in interaction design. http://www.welie.com/patterns/<br />
index.php, 2009-06-06.<br />
[137] Martijn van Welie and Gerrit C. van der Veer. Pattern languages in interaction design: Structure and<br />
organization. In M. Rauterberg et al., editor, Proceedings of Interact 2003, pages 527–534, 2003.<br />
[138] François Bodart; Anne-Marie Hennebert; Jean-Marie Leheureux; Isabelle Provot;Benoît Sacré; Jean<br />
Vanderdonckt. Towards a systematic building of software architectures: the trident methodological<br />
guide. In Eurographics Workshop on Design, Specification, Verification of Interactive Eurographics<br />
Workshop on Design, Specification, Verification of Interactive Systems DSV-IS’95, 1995.<br />
[139] Jean Vanderdonckt and Juan Manuel Gonzalez Calleros. Usixml, a user interface<br />
model and language engineering approach. http://www.w3.org/2008/10/mbui/<br />
UsiXML-MBUI-W3C2008.pdf, 2010-05-25. Präsentation auf W3C-Workshop.<br />
[140] Jean Vanderdonckt, Quentin Limbourg, Benjamin Michotte, Laurent Bouillon, Daniela Trevisan,<br />
and Murielle Florins. Usixml: a user interface description language for specifying multimodal user<br />
interfaces. In W3C Workshop on Multimodal Interaction, Juli 2004.<br />
[141] J.M. Voas. Certifying off-the-shelf software components. Computer, 31(6):53–59, Jun 1998.<br />
[142] Voice extensible markup language. http://www.w3.org/TR/voicexml30/, 2010-02-15.<br />
W3C-Standard, V3.0.<br />
[143] W3C. Wireless markup language, version 2, spezifikation. http://www1.wapforum.org/<br />
tech/terms.asp?doc=WAP-238-WML-20010911-a.pdf, 2010-05-25, 2001.<br />
[144] Max Wertheimer. Gestalt Theory. Social Research, Volume 2, 1944.<br />
[145] Wikipedia.de. Template engine. http://de.wikipedia.org/w/index.php?<br />
title=Template_Engine&oldid=78943646, 2010-09-30.<br />
[146] R.J. Wirfs-Brock. Principles in practice. Software, IEEE, 26(4):11 –12, 2009.<br />
[147] Felix Woitzel. UsiXML im USG-Prozess. Lehrstuhl Softwaretechnik, Universität Rostock, Mai<br />
2009. Studienarbeit.<br />
[148] Andreas Wolff. Ein konzept zur integration <strong>von</strong> aufgabenmodellen in das gui-design. Master’s<br />
thesis, Rostock University, 2004.<br />
[149] Andreas Wolff and Peter Forbrig. Model-based reengineering of user interfaces. In MDDoAUI 2007,<br />
Proceedings, 2007.<br />
[150] Andreas Wolff and Peter Forbrig. Deriving user interfaces from task models. In MDDoAUI 2009,<br />
Proceedings, 2009.<br />
[151] Andreas Wolff, Peter Forbrig, Anke Dittmar, and Daniel Reichart. Development of interactive systems<br />
based on patterns. In Workshop on Mapping User Needs into Interaction Design Solutions at<br />
Interact, Rome, Italy, September 2005.<br />
[152] Andreas Wolff, Peter Forbrig, Anke Dittmar, and Daniel Reichart. Linking gui elements to tasks –<br />
supporting an evolutionary design process. In Tamodia 2005 - Danzig, Polen, 2005.
190 LITERATURVERZEICHNIS<br />
[153] Andreas Wolff, Peter Forbrig, and Daniel Reichart. Tool support for model-based generation of<br />
advanced user-interfaces. In MDDoAUI 2005, Proceedings, 2005.<br />
[154] Xml standard. http://www.w3.org/TR/2008/REC-xml-20081126/, 2010-05-24. W3C<br />
Recommendation 26 November 2008.<br />
[155] Gecko rendering engine für xul. http://mozilla.doslash.org/xulschema/<br />
generating.html, 2010-03-05. Mozilla Corporation.
Selbständigkeitserklärung<br />
Hiermit erkläre ich, dass ich die vorliegende Dissertation mit dem Titel<br />
<strong>Modellbasierte</strong> <strong>Generierung</strong> <strong>von</strong> <strong>Benutzungsoberflächen</strong><br />
selbständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel angefertigt habe.<br />
Die den benutzten Quellen oder Hilfsmitteln wörtlich oder inhaltlich entnommenen Stellen sind in der Arbeit<br />
als solche erkenntlich.<br />
Rostock, den 1. Dezember 2010<br />
Ort, Datum Andreas Wolff<br />
191
Lebenslauf<br />
Berufserfahrung<br />
seit 06/10 Freiberufliche Softwareentwicklung:<br />
- für die Westdeutsche ImmobilienBank AG<br />
- im Auftrag der PPI AG bei deren Kunden<br />
11/04–10/10 Wissenschaftlicher Mitarbeiter am Lehrstuhl Softwaretechnik der Universität Rostock<br />
- Lehre und Ausbildung im Bereich Programmierungstechnik und Software Engineering<br />
- Tätigkeitsschwerpunkt und Promotionsthema: <strong>Modellbasierte</strong> <strong>Generierung</strong> <strong>von</strong><br />
<strong>Benutzungsoberflächen</strong><br />
seit 04/04 Nebentätigkeit als freiberuflicher Softwareentwickler für die HSH Nordbank AG<br />
09/02–02/03 Praktikum in der Softwareentwicklung bei Hewlett-Packard<br />
HP Open View, Böblingen<br />
Studium<br />
04/05–03/11 Informatik, Promotionsstudium<br />
10/99–10/04 Wirtschaftsinformatik, Universität Rostock<br />
Abschluß: Diplom-Wirtschaftsinformatiker<br />
Wehrdienst<br />
07/98–04/99 4. Batterie/Panzer-Artillerie-Bataillon 415, Eggesin<br />
Schulbildung<br />
08/91–06/98 „Max Steenbeck“ Gymnasium Cottbus<br />
Abschluß: Abitur<br />
09/85–07/91 Polytechnische Oberschule „Kurt Werner“, Walddrehna
Thesen<br />
1. Die manuelle Erstellung <strong>von</strong> Benutzungsschnittstellen ist ein langwieriger Prozess. Die Fehlerquellen,<br />
sowohl bezüglich Konzeption, Gestaltung und Programmierung, sind manigfaltig. Derzeit zur<br />
Verfügung stehende Software-Werkzeuge für die UI-Erstellung sind oft nicht anwendbar oder zwingen<br />
ihren Benutzern diverse Vorgehensweisen auf welche mit deren Entwicklungsverfahren teilweise<br />
nicht vereinbar sind.<br />
2. Die händische Programmierung des User Interfaces ist heutzutage nur noch in Spezialfällen wünschenswert,<br />
beispielsweise falls, wie bei Computerspielen oder diversen mobilen Geräten, ein extremer<br />
Zwang zur Optimierung der Ablaufgeschwindigkeit oder des Speicherplatzbedarfs vorliegt.<br />
Für die meisten Anwendungsfälle ist es sinnvoll eine deklarative Beschreibung der geplanten Benutzungsoberfläche<br />
zu erstellen und aus dieser Deklaration automatisiert den notwendigen Anwendungsquellcode<br />
generieren zu lassen. Manuelle Eingriffe in den derart erstellten Quellcode sind nur<br />
in begründeten Einzelfällen ratsam.<br />
3. Deklarative Oberflächenbeschreibungen sind geeignet gängige User Interfaces zu beschreiben. Trotzdem<br />
die tatsächlichen Möglichkeiten der Mensch-Maschine-Kommunikation sehr vielfältig sind, benutzt<br />
ein überwiegender Teil der real existierenden Software verhältnismäßig einfache 2-dimensionale<br />
Grafiken und Standard-Widgets. Das WIMP-Konzept zählt in diese Klasse. Modellierungswerkzeuge<br />
und -sprachen für WIMP-Oberflächen existieren seit geraumer Zeit. Es ist möglich aus diesen<br />
Sprachdefinitionen geeignete Metamodelle zur Verwendung in der modellgetriebenen Entwicklung<br />
<strong>von</strong> <strong>Benutzungsoberflächen</strong> (MD-UID) abzuleiten.<br />
4. Die deklarative Beschreibung der Ziel-UI ist nur der letzte Schritt in einem MD-UID Prozess. Dieser<br />
Prozess beginnt idealerweise in der Frühphase der Softwareentwicklung, bei der Anforderungsanalyse.<br />
Die geeignete Notation der aufgenommenen Requirements, z.B. in Form <strong>von</strong> Aufgabenmodellen,<br />
ist der Ausgangspunkt einer modellgetriebenen Softwareentwicklung. Der Abstraktionsgrad <strong>von</strong><br />
Aufgabenmodellen ist so hoch, dass sie bei weitem nicht alle, für reale GUIs benötigten Informationen<br />
und Steuerparameter enthalten können. Wichtiger Zweck eines MD-UID Vorgehensmodells ist<br />
daher, in einem strukturierten Prozess die notwendigen Details mittels Hilfsmodellen und geeigneten<br />
Transformationen beizusteuern und somit die letztlich darzustellende UI zu konkretisieren.<br />
5. Das am Lehrstuhl Softwaretechnik entwickelte Vorgehensmodell definiert einen vollständigen Softwareentwicklungsprozess,<br />
<strong>von</strong> der Anforderungsanalyse bis zur lauffähigen Software. Es werden<br />
mehrere Zwischenmodelle benutzt, die Übergänge zwischen diesen Modellen sind als bidirektionale<br />
semi-automatische Transformationen geplant. Das Rostocker Vorgehensmodell ermöglicht iterative<br />
Entwicklungskonzepte und lässt gleichzeitig die frühzeitige Evaluation vorläufiger Prototypen und<br />
Arbeitsergebnisse mit den Stakeholdern zu.<br />
6. Entwickler, Analytiker, Designer, Psychologen und viele weitere Interessengruppen haben im Laufe<br />
der letzten Jahre viele UI-Gestaltungsvariationen ausprobiert. Für bestimmte Probleme haben sich<br />
dabei jeweils typische Lösungen als optimal herausgestellt, die sogenannten „Best Practices“ oder<br />
auch Patterns. Patterns in den MD-UID Prozess und das Rostocker Vorgehensmodell zu integrieren<br />
wird die Qualität der Ergebnisse signifikant erhöhen. Die für den HCI-Bereich beschriebenen Patterns<br />
werden in wenigen öffentlichen Katalogen gesammelt. Der Großteil dieser Patterns bezieht sich<br />
auf Gestaltungen im World Wide Web und WIMP-Oberflächen.<br />
7. Die Patterndefinitionen sind uneinheitlich in Bezug auf Kontext und Abstraktionsebene, die Lösungsund<br />
Problem-Beschreibungen erfolgen in aller Regel textuell oder sind grafische Darstellungen. Zur
Integration <strong>von</strong> Patterns in das Vorgehensmodell müssen diese geeignet formalisiert werden. Eine<br />
formalisierte Patternbeschreibung ist mit der Sprache PLML möglich.<br />
8. PLML kann für die modellgetriebene Entwicklung eines Patternkatalogs genutzt werden. Die notwendige<br />
maschinenlesbare/-verwertbare Beschreibung der Pattern-Idee kann PLML nicht liefern.<br />
Dazu sind Hilfsmodelle wie PLMLComponent erforderlich welche in PLML-Kataloge einbettbar<br />
sind. Mit dem PLMLComponent-Metamodell können Pattern-Instanz-Komponenten beschrieben werden.<br />
PLML und PLMLComponent sind geeignet konzipiert um Patterns für die Verwendung bei den<br />
Transformationen des Rostocker Vorgehensmodells definieren zu können.<br />
9. Der Großteil der derzeit verfügbaren Software wurde nicht modellbasiert entwickelt. Es ist wünschenswert<br />
die Vorteile der MDA, wie einfache Wartbarkeit und Anpassung an andere Nutzungskontexte,<br />
auch für solche Anwendungen bereitzustellen. Dazu ist es notwendig, die Software-Artefakte<br />
solcher Legacy-Systeme in Instanzen geeigneter Modelle zu überführen.<br />
10. Modelle <strong>von</strong> Legacy-Software lassen sich sowohl aus deren Quellcode, durch Reverse Engineering,<br />
als auch zur Runtime, durch Introspektion, direkt aus der jeweiligen Anwendung gewinnen. Dem Reverse<br />
Engineering sind jedoch Grenzen gesetzt, nicht aus allen Legacy-Systeme lassen sich geeignete<br />
Modelle und Modellinstanzen für die Weiterverwendung im Rostocker Vorgehensmodell erstellen.
Zusammenfassung<br />
Diese Dissertation ist eine Arbeit im Bereich der modellbasierten Erstellung <strong>von</strong> <strong>Benutzungsoberflächen</strong>.<br />
Durch die Erarbeitung <strong>von</strong> geeigneten Metamodellen und Transformationen <strong>von</strong> Instanzen dieser Modelle<br />
werden die Schnittstellen der Mensch-Maschine-Kommunikation spezifiziert.<br />
Die als Modellinstanzen erstellten UI-Spezifikationen werden benutzt um daraus verwendungsfähigen<br />
Quellcode zu generieren. Dabei gelangen Basistechniken des MDA-Paradigmas zum Einsatz: Model-to-<br />
Model- und Model-to-Text-Transformationen.<br />
Besonderen Fokus wird in der Arbeit weiterhin auf die Integration <strong>von</strong> Best-Practices in die User Interface<br />
(UI) <strong>Generierung</strong> gelegt. Dazu werden bekannte Human-Computer-Interaction Patterns auf Formalisierbarkeit<br />
untersucht und klassifiziert. Ziel dieser Untersuchungen ist der Aufbau eines Kataloges direkt, für<br />
die UI-Erzeugung, anwendbarer Komponenten.<br />
Dritter Schwerpunkt ist eine Analyse der Möglichkeiten zur Durchführung <strong>von</strong> Reengineering im Kontext<br />
der modellbasierten Softwareentwicklung. Es wird erläutert, wie existierende Softwaresysteme analysiert<br />
werden können und mittels Instanzen zuvor generierter (Meta-)modelle beschrieben werden können. Der<br />
diskutierte Lösungsvorschlag ermöglicht die Anwendung des MDA-Paradigmas auf bereits bestehende<br />
Alt-Software.<br />
Sowohl der erstellte Pattern-Katalog als auch das Reverse Engineering werden an Beispielen demonstriert.<br />
Summary<br />
This thesis presents work from the area of model-based development of user interfaces (UI). These interfaces<br />
for human-computer interaction get specified by means of suitable meta models and transformations<br />
between those models.<br />
UI specifications – created as instances of the aforementioned models – are used to generate executable<br />
source code. For this purpose typical techniques of the well-known MDA-paradigm are used: model-tomodel<br />
and model-to-text transformations.<br />
The community has generated an extensive experience and knowledge about proper user-interface design.<br />
Much of this wisdom has been semi-formalized as patterns, or HCI-patterns (Human-Computer-<br />
Interaction) to be more specific.<br />
It is not an easy task to integrate HCI-patterns into a model-driven UI-development. This work proposes to<br />
use executable formalizations of HCI-patterns, called pattern instance components, organized in a specially<br />
designed pattern catalog. As part of these considerations, a classification of patterns that may be candidates<br />
for successful formalization has been made.<br />
The third major topic of this work is an analysis of how reengineering can be applied in the context of<br />
model-based software engineering. It is discussed how legacy systems can be analyzed and described by<br />
instances of previously generated (meta) models. The ultimate goal of such a process is to enable the<br />
benefits of MDA to non-MDA software.<br />
The created pattern catalog as well as the reverse engineering concept are illustrated by examples.