Generierung aufgabenbasierter dialogorientierter ...

Generierung aufgabenbasierter dialogorientierter 

Benutzerschnittstellen von Web-Anwendungen 

WIRTSCHAFTSWISSENSCHAFT 

Bachelor - Master - Zusatzstudium für Juristen 

Informationen zum Studium 

Dissertation zur Erlangung des akademischen Grades Doktor der Naturwissenschaften 

(Dr. rer. nat.) der Fakultät für Mathematik und Informatik der FernUniversität in Hagen 

im Fach Informatik 

Vorgelegt von: 

Dipl.-Inform. Stefan Betermieux 

Hagen im November 2008

Danksagung 

Bei der Durchführung meines Dissertationsprojekts haben mich viele Menschen unterstützt, 

denen ich an dieser Stelle besonderen Dank sagen möchte: 

Herrn Prof. Dr. Gunter Schlageter danke ich für die jahrelange Begleitung auf meinem 

Weg als Wissenschaftler. Er hat bereits 2002 meine Diplomarbeit betreut und mich 

während meiner Exkurse in die Wirtschaft, auf die Konferenzen dieser Welt und in 

abendliche Strategiesitzungen immer wieder daran erinnert, dass ich eigentlich noch 

eine Doktorarbeit schreiben wollte. 

Herrn Prof. Dr. Jörg Haake danke ich für seine freundliche Bereitschaft, das Zweitgutachten 

meiner Arbeit zu übernehmen. Die Zusammenarbeit war stets fruchtbar und die 

vorliegende Arbeit profitierte von seinen Ratschlägen und Empfehlungen. 

Die Zusammenarbeit mit Dr. Birgit Bomsdorf kann ich nicht hoch genug bewerten. 

Sie war es, die mir das Themengebiet dieser Arbeit näherbrachte und die in meinen 

Augen unglaubliche These vertrat, dass Computer sich den Menschen anpassen sollten – 

und nicht umgekehrt. Durch sie lernte ich die internationale HCI-Gemeinschaft kennen 

und war auf allen Konferenzen von bekannten Gesichtern umgeben. Für persönliche 

Gespräche und Ratschläge möchte ich vor allem Prof. Dr. Peter Forbrig, Dr. Anke Dittmar, 

Prof. Dr. Gerd Szwillus und Dr. Marco Winckler danken. 

Patrick Langer danke ich für das gemeinsame Studium und die ersten Jahre als Wissenschaftler; 

ohne ihn hätte dieses Promotionsprojekt wohl nicht mal begonnen. Allen 

Kolleginnen und Kollegen am Lehrgebiet Informationssysteme und Datenbanken 

möchte ich für anregende Gespräche und die gute Arbeitsatmosphäre danken. Besonders 

die Zusammenarbeit mit Dominic Becking hat mir viel Freude bereitet; ich möchte 

ihm für gemeinsame Projekte, gelegentliche „didaktisch-pädagogische“ Hinweise und 

gute Zeiten auf Vortragsreisen danken. Frank Laskowski danke ich dafür, ihn kennen 

zu dürfen. Als Wandler zwischen den Welten der Informatik, der Philosophie und der 

Theologie hat er einen nicht wieder gut zu machenden Eindruck hinterlassen. Gerd Rademacher 

und seinen Mitarbeitern danke ich herzlich für ihre kompetente Unterstützung 

in allen technischen Belangen. Regina Braun und Barbara Wohlfeil waren stets für 

Fragen der Organisation ansprechbar und haben mir in dieser Hinsicht oft geholfen. 

Sehr am Herzen liegt mir auch der Dank an meine Eltern, meinem Bruder und meine 

Freunde, die mir stets den Rücken frei gehalten und mich über so manche Unwägbarkeit 

hinweggetragen haben. Und zu guter Letzt gilt mein ganz besonderer Dank der 

wichtigsten Person überhaupt, meiner Frau. Olga, Du hast mehr zu dieser Arbeit beigetragen, 

als Du Dir vorstellen kannst. Die grafische Gestaltung dieser Arbeit, die Du in 

wochenlangen Nachtsitzungen aus meinen laienhaften Entwürfen gezaubert hast, sind 

vielleicht der Beleg für Außenstehende. Nico und Elisa sind der Beleg für mich. Danke 

für alles! 

iii

Danksagung 

iv

Abstract 

Klassischerweise wird die Navigation in Web-Anwendungen als Zustandsübergang von 

einer Webseite auf die folgende Webseite definiert. Viele Anwendungen erwarten aber 

keine freie Navigation, sondern einen geführten Dialog; die Anforderungen an diese 

Dialoge führen zu unübersichtlichen und schwierig zu modellierenden Zustandsübergangsdiagrammen. 

Ziel der Arbeit ist die Modellierung der Dialoge mittels Aufgabenbäumen, 

welche die Komplexität reduzieren. Diese Arbeit wird ein spezielles Interaktionsmodell 

für Web-Anwendungen vorstellen, welches Ansätze aus klassischen Aufgaben-, 

Dialog- und Präsentationsmodellen vereint und zur Laufzeit in eine Benutzerschnittstelle 

umgesetzt wird. Weiterhin wird gezeigt, wie spezielle Anforderungen an 

Web-Anwendungen mit diesem Ansatz behandelt werden können, z. B. das Persistieren 

des Zustands, oder die Erkennung von Navigation außerhalb des Dialogs. 

Neben der Definition des Interaktionsmodells wird auch die Architektur vorgestellt, 

mit der das Modell zur Laufzeit in eine Benutzerschnittstelle umgewandelt werden 

kann. Das Verhalten zur Laufzeit muss definiert werden, weil die Präsentation zur Modellierungszeit 

als Fragmente nur lose an die Aufgaben gekoppelt ist und erst zur Laufzeit 

basierend auf dem Anwendungszustand endgültig zu einer Benutzerschnittstelle 

zusammengestellt wird. Diese Flexibilität kann genutzt werden, um, abhängig vom Benutzer 

und anderen Kontextinformationen, eine angepasste Benutzerschnittstelle der 

Web-Anwendung zu generieren. 

v

Abstract 

vi

Inhaltsverzeichnis 

Danksagung iii 

Abstract v 

I Grundlagen 1 

1 Einleitung 3 

1.1 Problemstellung und Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.2 Entwurfsmethoden für Web-Anwendungen . . . . . . . . . . . . . . . . . 4 

1.3 Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.4 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2 Architekturen für Web-Anwendungen 9 

2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2 Architekturkonzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.1 Fortschritt der Softwareentwicklung . . . . . . . . . . . . . . . . . 10 

2.2.2 Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.3 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.2.4 Modularitätsprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.2.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.3 Schichtenarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.3.1 Ein-Schicht-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.3.2 Zwei-Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . 13 

Client/Server Hintergrund . . . . . . . . . . . . . . . . . . . . . . . . 14 

Client/Server als Schichtenarchitektur . . . . . . . . . . . . . . . . . 14 

2.3.3 Drei-Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . 15 

2.3.4 Mehrschichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . 16 


2.4 Schichtenarchitektur für Web-Anwendungen . . . . . . . . . . . . . . . . 16 

2.4.1 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

2.4.2 Web-Applikationsserver . . . . . . . . . . . . . . . . . . . . . . . . . 18 

2.5 Portalarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

vii


2.5.1 Referenzarchitektur Portalserver . . . . . . . . . . . . . . . . . . . . 19 

2.5.2 Basisdienste mit Relevanz für unseren Ansatz . . . . . . . . . . . . 20 

Anwendungsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 21 

Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

Rechteverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

Single-Sign-On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Prozessunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

Layoutmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

2.5.3 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . . 22 

2.6 Architekturmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.6.1 Model View Controller . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.6.2 Front Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

2.6.3 Dialogsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

2.6.4 Komponentenbasierte Präsentation . . . . . . . . . . . . . . . . . . 27 


2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

3 Modellbasierte Entwicklung 31 

3.1 Modelle im Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . 31 

3.1.1 Modelldefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.1.2 Metamodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

3.1.3 Modellbasierte und modellgetriebene Entwicklung . . . . . . . . . 33 


3.2 Modellbasierte Entwicklung von Web-Anwendungen . . . . . . . . . . . 35 

3.3 Domänenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

3.4 Aufgabenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

3.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

3.4.2 Methoden der Aufgabenmodellierung . . . . . . . . . . . . . . . . 38 

Hierarchical Task Analysis (HTA) . . . . . . . . . . . . . . . . . . . . 39 

Goals, Operators, Methods, and Selection rules (GOMS) . . . . . . 41 

Task Knowledge Structures (TKS) . . . . . . . . . . . . . . . . . . . 42 

Model for Activity Description (MAD) . . . . . . . . . . . . . . . . . 43 

User Action Notation (UAN) . . . . . . . . . . . . . . . . . . . . . . 45 

Concurrent Task Trees (CTT) . . . . . . . . . . . . . . . . . . . . . . 48 

3.4.3 Gemeinsamkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

3.5 Dialogmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

3.5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

3.5.2 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

3.5.3 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

3.5.4 Vom Aufgabenmodell zum Dialogmodell . . . . . . . . . . . . . . . 55 

Umsetzung der temporalen Operationen . . . . . . . . . . . . . . . 56 

3.5.5 Fehlerquellen bei der Dialogmodellierung . . . . . . . . . . . . . . 58 


3.6 Präsentationsmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

3.6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

viii


3.6.2 Abstraktionsstufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 

Abstrakte Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . 60 

Konkrete Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . 62 

Finale Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . 62 



II Konzepte 65 

4 Überblick über den Lösungsansatz 67 

4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

4.2 Aufgabenmodell als Basis des Interaktionsmodells . . . . . . . . . . . . . 68 

4.2.1 Temporale Operatoren . . . . . . . . . . . . . . . . . . . . . . . . . 68 

4.2.2 Unterbrechbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 

4.2.3 Rollenkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

4.3 Erweiterung des Interaktionsmodells . . . . . . . . . . . . . . . . . . . . . 69 

4.3.1 Dialogmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

4.3.2 Präsentationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 

4.3.3 Anbindung an das Domänenmodell . . . . . . . . . . . . . . . . . . 70 

4.4 Laufzeitsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

4.5 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

5 Aufgabenbasiertes Interaktionsmodell für Web-Anwendungen 71 

5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

5.2 Aufgabenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

5.2.1 Das Ausführen von Aufgaben . . . . . . . . . . . . . . . . . . . . . 72 

5.2.2 Der Aufgabenkontext . . . . . . . . . . . . . . . . . . . . . . . . . . 72 

5.3 Kardinalität von Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

5.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 

5.3.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

5.4 Hierarchiebeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

5.4.1 Allgemeine Hierarchiebedingungen . . . . . . . . . . . . . . . . . . 75 

5.4.2 Ordnung der Unteraufgaben . . . . . . . . . . . . . . . . . . . . . . 76 

5.4.3 Ausprägungen der Hierarchiebeziehungen . . . . . . . . . . . . . . 77 

Sequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 

Selektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 

Parallel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

Überlappend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

Verschachtelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 

Arbiträr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

5.4.4 Semantik der Hierarchisierung . . . . . . . . . . . . . . . . . . . . . 84 

5.4.5 Zusammenfassung der Hierarchiebeziehungen . . . . . . . . . . . 85 

5.4.6 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

5.5 Der Aufgabentyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

ix


5.5.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

5.5.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

5.6 Unterbrechbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

5.6.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

5.6.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 

5.7 Zugriffskontrolle über Rollenkonzept . . . . . . . . . . . . . . . . . . . . . 91 

5.7.1 Rollenkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 

5.7.2 Integration in das Aufgabenmodell . . . . . . . . . . . . . . . . . . 92 

5.7.3 Rollenspezifische Adaption der Benutzerschnittstelle . . . . . . . . 94 

5.7.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

5.8 Wiederverwendbarkeit von Aufgabenhierarchien . . . . . . . . . . . . . . 95 

5.8.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 

5.8.2 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 


6 Aufgabenbasierte Dialogfragmente für Web-Anwendungen 101 

6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

6.2 Erweitertes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 

6.2.1 Finale Benutzerschnittstelle eines Dialogzustands . . . . . . . . . . 102 

6.2.2 Konkrete Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . 105 


6.3 Anbindung an das Aufgabenmodell . . . . . . . . . . . . . . . . . . . . . . 106 

6.3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 

6.3.2 Dialogfragmente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 

6.3.3 Zustandsautomat für Aufgaben . . . . . . . . . . . . . . . . . . . . 109 

Algorithmus zur Kontrolle der Aufgabenautomaten . . . . . . . . 111 

Aufgabenautomaten zur Laufzeit . . . . . . . . . . . . . . . . . . . 112 

6.3.4 Aufgabenbasierte Komposition . . . . . . . . . . . . . . . . . . . . 115 

Algorithmus zur Seitengenerierung . . . . . . . . . . . . . . . . . . 117 

Ergebnis der Seitengenerierung . . . . . . . . . . . . . . . . . . . . 118 

Exkurs in dynamische Oberflächengenerierung . . . . . . . . . . . 119 

6.3.5 Erweiterung des Aufgabenmetamodells . . . . . . . . . . . . . . . 120 

Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 

Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 


6.4 Anbindung des Domänenmodells . . . . . . . . . . . . . . . . . . . . . . . 121 

6.4.1 Arten der Anbindung . . . . . . . . . . . . . . . . . . . . . . . . . . 123 

6.4.2 Offene Fragen beim Domänenzugriff . . . . . . . . . . . . . . . . . 124 

Domänenmodell für unser Beispiel . . . . . . . . . . . . . . . . . . 124 

Probleme bei der Anbindung des Domänenmodells . . . . . . . . . 126 

6.4.3 Domänenzugriffsobjekte . . . . . . . . . . . . . . . . . . . . . . . . 127 

Unterbrechbarkeit im Bezug auf Domänenzugriffsobjekte . . . . . 127 

Gültigkeitsbereich der Domänenzugriffsobjekte . . . . . . . . . . . 129 

6.4.4 Unterbrechbarkeit und Nebenläufigkeit . . . . . . . . . . . . . . . 133 

6.4.5 Erweiterung des Aufgabenmetamodells . . . . . . . . . . . . . . . 134 

x


Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 

Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 


6.5 Erweiterung der Aufgaben um dialogspezifische Attribute . . . . . . . . 137 

6.5.1 Automatisches starten und beenden der Aufgaben . . . . . . . . . 137 

Autostart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 

Autostop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 

Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 

6.5.2 Aufgabenzustandsabhängige Erweiterungen . . . . . . . . . . . . 140 

6.5.3 Generische Aufgabendarstellung . . . . . . . . . . . . . . . . . . . 140 

6.5.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 


7 Architektur für das Laufzeitsystem 145 

7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

7.2 Ablaufübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

7.3 Architekturübersicht Laufzeitumgebung . . . . . . . . . . . . . . . . . . . 147 

7.3.1 Domain Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

7.3.2 User Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

7.3.3 Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

7.3.4 Task Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 

7.3.5 Dialog Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 

7.3.6 User Management Dialog . . . . . . . . . . . . . . . . . . . . . . . . 157 

7.3.7 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 


8 Bewertung der Ergebnisse 161 

8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 


8.3 Abschließender Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

8.4 Modifizierungen am Aufgabenmodell . . . . . . . . . . . . . . . . . . . . 162 

8.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

8.4.2 Eine Aufgabe hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . 163 

8.4.3 Eine Aufgabe entfernen . . . . . . . . . . . . . . . . . . . . . . . . 164 

8.4.4 Reihenfolge der Unteraufgaben verändern . . . . . . . . . . . . . 164 

8.4.5 Eine Aufgabe verschieben . . . . . . . . . . . . . . . . . . . . . . . 165 


9 Ausblick 167 

9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

9.2 Werkzeugunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

9.3 Aufgabenspezifische Dialogelemente . . . . . . . . . . . . . . . . . . . . . 168 

9.4 Transformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

9.5 Laufzeitumgebung für andere Bereiche . . . . . . . . . . . . . . . . . . . 169 

xi


9.6 Usability Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

9.7 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

9.8 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 

III Anhänge 171 

A Übersicht aller Interaktionselemente 173 

B Beispiel- und Schemadefinition 177 

B.1 Vollständiges Beispiel in Diagramm-Notation . . . . . . . . . . . . . . . . 177 

B.2 Vollständiges Beispiel in XML-Notation . . . . . . . . . . . . . . . . . . . . 181 

B.3 Schemabeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

Literaturverzeichnis 193 

xii

Abbildungsverzeichnis 

2.1 Beispiel gute/schlechte Softwarearchitektur . . . . . . . . . . . . . . . . . 12 

2.2 Ein-Schicht-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.3 Zwei-Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.4 Drei-Schichten-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

2.5 Referenzarchitektur für Web-Anwendungen . . . . . . . . . . . . . . . . . 17 

2.6 Detaillierte Referenzarchitektur für Web-Anwendungen . . . . . . . . . . 18 

2.7 Detaillierte Referenzarchitektur für Portal-Anwendungen . . . . . . . . . 20 

2.8 MVC Architekturmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 

2.9 MVC Architektur für Web-Anwendungen . . . . . . . . . . . . . . . . . . 26 

2.10 MVC Architektur mit Dialogsteuerung für Web-Anwendungen . . . . . . 27 

2.11 Komponentenbasierte Präsentationsarchitektur . . . . . . . . . . . . . . 28 

3.1 Phasen der modellbasierten Entwicklung . . . . . . . . . . . . . . . . . . . 36 

3.2 Zeitlinie der Aufgabenmodelle . . . . . . . . . . . . . . . . . . . . . . . . . 39 

3.3 CTT – Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 

3.4 Dialogmodell – Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 

3.5 Dialog und Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 

3.6 Verfeinerung der Präsentation aus den Aufgaben . . . . . . . . . . . . . . 60 

5.1 Beispiel Aufgabenmodell – Standard . . . . . . . . . . . . . . . . . . . . . 72 

5.2 Beispiel Aufgabenmodell – Kardinalitäten . . . . . . . . . . . . . . . . . . 74 

5.3 Allgemeine Hierarchie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 

5.4 Hierarchiebeziehung – Sequenz . . . . . . . . . . . . . . . . . . . . . . . . 78 

5.5 Hierarchiebeziehung – Selektion . . . . . . . . . . . . . . . . . . . . . . . . 79 

5.6 Hierarchiebeziehung – Parallel . . . . . . . . . . . . . . . . . . . . . . . . . 80 

5.7 Hierarchiebeziehung – Überlappend . . . . . . . . . . . . . . . . . . . . . 81 

5.8 Hierarchiebeziehung – Verschachtelt . . . . . . . . . . . . . . . . . . . . . 82 

5.9 Hierarchiebeziehung – Arbiträr . . . . . . . . . . . . . . . . . . . . . . . . 83 

5.10 Abarbeitung der Aufgaben als Sequenz (erste Variante) . . . . . . . . . . 84 

5.11 Abarbeitung der Aufgaben als Sequenz (zweite Variante) . . . . . . . . . 84 

5.12 Beispiel Aufgabenmodell – Hierarchie . . . . . . . . . . . . . . . . . . . . . 86 

5.13 Beispiel Aufgabenmodell – Aufgabentypen . . . . . . . . . . . . . . . . . 88 

5.14 Beispiel Aufgabenmodell – Unterbrechung . . . . . . . . . . . . . . . . . . 91 

xiii


xiv 

5.15 Hierarchischer RBAC Standard nach ANSI 359-2004 . . . . . . . . . . . . . 92 

5.16 Um Gruppen erweiterter RBAC Standard . . . . . . . . . . . . . . . . . . . 93 

5.17 Beispiel Aufgabenmodell – Zugriffsrollen . . . . . . . . . . . . . . . . . . . 95 

5.18 Gerichteter azyklischer Graph und gerichteter zyklischer Graph . . . . . . 96 

5.19 Beispiel Aufgabenmodell – Wiederverwendung . . . . . . . . . . . . . . . 97 

5.20 Interaktionsmetamodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 

6.1 Beispiel Aufgabenmodell – Kleinanzeige Erstellen . . . . . . . . . . . . . . 103 

6.2 Beispiel einer finalen Benutzerschnittstelle (HTML Seite) . . . . . . . . . . 104 

6.3 Generierung der Benutzerschnittstelle zur Laufzeit . . . . . . . . . . . . . 107 

6.4 Zustandsautomat einer Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . 110 

6.5 Dialogzustand als Teilbaum mit Aufgabenzuständen . . . . . . . . . . . . 115 

6.6 Generierte konkrete Benutzerschnittstelle . . . . . . . . . . . . . . . . . . 119 

6.7 Dialogspezifische Erweiterung des Aufgabenmetamodells . . . . . . . . . 120 

6.8 Beispiel Interaktionsmodell – Dialogfragmente (Auszug) . . . . . . . . . . 122 

6.9 Domänenmodell – Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 

6.10 Domänenzugriffsobjekte – Beispiel . . . . . . . . . . . . . . . . . . . . . . 127 

6.11 Domänenzugriffsobjekte – Unterbrechbarkeit . . . . . . . . . . . . . . . . 128 

6.12 Domänenzugriffsobjekte – Gültigkeitsbereich . . . . . . . . . . . . . . . . 130 

6.13 Domänenzugriffsobjekte – Gültigkeitsbereich als Sequenzdiagramm . . . 131 

6.14 Erweiterung des Aufgabenmetamodells um Domänenzugriffsobjekte . . 135 

6.15 Beispiel Interaktionsmodell – Domänenzugriff (Auszug) . . . . . . . . . . 136 

6.16 Beliebige Sequenz (mit Dialogfragmenten) . . . . . . . . . . . . . . . . . . 141 

6.17 Beliebige Sequenz (generische Darstellung) . . . . . . . . . . . . . . . . . 142 

6.18 Interaktionsmetamodell – mit dialogspezifischen Erweiterungen . . . . . 143 

7.1 Ablaufübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

7.2 Architekturübersicht Laufzeitumgebung . . . . . . . . . . . . . . . . . . . 147 

7.3 Architektur – Domain Base . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

7.4 Architektur – User Management . . . . . . . . . . . . . . . . . . . . . . . . 149 

7.5 Architektur – Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . 151 

7.6 Architektur – Task Controller – Modellierung . . . . . . . . . . . . . . . . 153 

7.7 Architektur – Task Controller – Laufzeit . . . . . . . . . . . . . . . . . . . . 154 

7.8 Architektur – Dialog Controller . . . . . . . . . . . . . . . . . . . . . . . . 156 

7.9 Umsetzung der Einstiegsseite . . . . . . . . . . . . . . . . . . . . . . . . . . 158 

8.1 Modifikation – Original Aufgabenmodell . . . . . . . . . . . . . . . . . . . 163 

8.2 Modifikation – Eine Aufgabe hinzufügen . . . . . . . . . . . . . . . . . . 163 

8.3 Modifikation – Eine Aufgabe entfernen . . . . . . . . . . . . . . . . . . . 164 

8.4 Modifikation – Unteraufgaben vertauschen . . . . . . . . . . . . . . . . . 164 

8.5 Modifikation – Eine Aufgabe verschieben . . . . . . . . . . . . . . . . . . 165 

B.1 Vollständiges Beispiel – detailliert . . . . . . . . . . . . . . . . . . . . . . . 178 

B.2 Vollständiges Beispiel – kompakt . . . . . . . . . . . . . . . . . . . . . . . 180


Die Rechte aller Abbildungen (bis auf Abbildung 3.3) liegen bei demedio | das atelier (Dipl. Des. Olga Merkulova, 

Witten). Die Abbildungen stehen unter der Creative Commons Namensnennung-Keine kommerzielle Nutzung- 

Keine Bearbeitung 3.0 Deutschland Lizenz. 

http://creativecommons.org/licenses/by-nc-nd/3.0/de/ 

xv


xvi

Tabellenverzeichnis 

3.1 MAD – Konstruktoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

3.2 MAD – Aufgabeneigenschaften . . . . . . . . . . . . . . . . . . . . . . . . 44 

3.3 UAN – Benutzeraktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

3.4 UAN – Systemreaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

3.5 UAN – Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

3.6 UAN – temporale Operationen . . . . . . . . . . . . . . . . . . . . . . . . . 47 

3.7 CTT – temporale Operationen . . . . . . . . . . . . . . . . . . . . . . . . . 48 

3.8 CTT – Aufgabenkategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

3.9 CTT – Aufgabeneigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . 50 

3.10 Vergleich der temporalen Operatoren . . . . . . . . . . . . . . . . . . . . 51 

3.11 Vergleich der Aufgabeneigenschaften . . . . . . . . . . . . . . . . . . . . 52 

5.1 Hierarchiebeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 

5.2 Aufgabentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 

5.3 Aufgabendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 

6.1 Unterstützung von Autostart . . . . . . . . . . . . . . . . . . . . . . . . . . 139 

6.2 Generische Ereignisse für Aufgabenautomaten . . . . . . . . . . . . . . . 141 

6.3 Aufgabendialogdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

6.4 Aufgabenzustandsdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

A.1 Interaktionselemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 

xvii

Tabellenverzeichnis 

xviii

Listings 

3.1 HTA Beispiel – Hausputz Hierarchie . . . . . . . . . . . . . . . . . . . . . . 39 

3.2 HTA Beispiel – Hausputz Pläne . . . . . . . . . . . . . . . . . . . . . . . . . 39 

3.3 HTA Beispiel – Hausputz Pläne (erweitert) . . . . . . . . . . . . . . . . . . 40 

3.4 GOMS Beispiel – Übertrage Änderungen aus einem Manuskript . . . . . . 41 

3.5 Beispiel einer abstrakten Benutzerschnittstelle . . . . . . . . . . . . . . . 61 

3.6 Beispiel einer konkreten Benutzerschnittstelle . . . . . . . . . . . . . . . . 62 

3.7 Beispiel einer finalen Benutzerschnittstelle . . . . . . . . . . . . . . . . . . 63 

6.1 Beispiel einer konkreten Benutzerschnittstelle (XML Format) . . . . . . . 106 

6.2 Dialogfragment – Vorname angeben . . . . . . . . . . . . . . . . . . . . . 108 

6.3 Dialogfragment – Nachname angeben . . . . . . . . . . . . . . . . . . . . 108 

6.4 Dialogfragment – Name angeben . . . . . . . . . . . . . . . . . . . . . . . 108 

6.5 Dialogfragment – Adresse angeben . . . . . . . . . . . . . . . . . . . . . . 108 

6.6 Dialogfragment – Kleinanzeige erstellen . . . . . . . . . . . . . . . . . . . 109 

6.7 Dialogfragment (Ursprungsversion) – Name angeben . . . . . . . . . . . . 116 

6.8 Dialogfragment (revidierte Version) – Name angeben . . . . . . . . . . . 116 

6.9 Dialogfragment (revidierte Version) – Adresse angeben . . . . . . . . . . 117 

6.10 Dialogfragment (revidierte Version) – Kontaktinformationen angeben . 117 

6.11 Dialogfragment (revidierte Version) – Kleinanzeige erstellen . . . . . . . 117 

B.1 Komplettes Beispiel im XML-Format . . . . . . . . . . . . . . . . . . . . . . 181 

B.2 XSD Schemabeschreibung des Aufgabenmetamodells . . . . . . . . . . . 187 

xix

Listings 

xx

Teil I 

Grundlagen 

1

Kapitel 1 

Einleitung 

Inhalt 

1.1 Problemstellung und Motivation . . . . . . . . . . . . . . . . . . . . . . 3 

1.2 Entwurfsmethoden für Web-Anwendungen . . . . . . . . . . . . . . . 4 

1.3 Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

1.4 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

1.1 Problemstellung und Motivation 

Web-Anwendungen nehmen mittlerweile einen großen Teil des World-Wide-Webs ein. 

In der Anfangszeit des Webs wurden nur statische Seiten erstellt, später kamen rudimentäre 

Serversysteme zum Einsatz, die einfache dynamische Webseiten erstellen 

konnten. Mit dem Wunsch, klassische Anwendungen ins Web zu übertragen, stieg auch 

die Komplexität des Softwareentwicklungsprozesses für die neu geschaffene Kategorie 

der Web-Anwendungen. Große E-Commerce-Anwendungen müssen beispielsweise adaptierte 

Benutzerschnittstellen für verschiedene Nutzergruppen und Endgeräte erzeugen 

können. Zudem muss die Anwendung zwei Ziele vereinen: Ein Benutzer erwartet 

eine möglichst einfach bedienbare Anwendung und ein Entwickler erwartet eine möglichst 

einfach erstellbare und erweiterbare Anwendung [de Troyer und Leune, 1998]. In 

dieser Arbeit werden wir einen Blick auf die Probleme bei der Erstellung von Benutzerschnittstellen 

für Web-Anwendungen werfen und Lösungsansätze vorstellen. 

Während die Beschreibung der Präsentation einer Webseite mit komponentenbasierten 

Web-Frameworks zufriedenstellend gelöst ist, ist die Beschreibung des Dialogs, 

also der Interaktionsabläufe zwischen Benutzer und Web-Anwendung, bis heute wenig 

intuitiv modellierbar. In den gängigen Web-Frameworks (Struts, Java ServerFaces) 

werden Dialogschritte als Zustände in einem Zustandsübergangsdiagramm modelliert, 

die Transitionen zwischen den Zuständen beschreiben die Verzweigungsmöglichkeiten. 

Während diese Modellierung einfach und funktional ist, besitzt sie den Nachteil, dass 

Abläufe nur schwer aus dem Zustandsautomaten ablesbar sind und die Flexibilität unter 

der fehlenden Kapselung (z. B. bzgl. Wiederverwendbarkeit) von Teildialogen leidet. 

Im Gegensatz zum freien Navigieren in Datenbeständen (Stöbern in Produktdatenbanken, 

freies Navigieren in großen Texten), zeigt sich dieses Problem besonders deutlich 

3

1 Einleitung 

bei der Modellierung von geleiteten Dialogen mit vielen Verzweigungsmöglichkeiten 

(Fahrkartenkauf bei der Bahn, Bestellprozesse mit Warenkorb). 

Folgende Probleme haben wir also bei der Modellierung von dialogorientierten Web- 

Anwendungen ausgemacht: 

Abläufe sind nur über Zustandsübergangsdiagramme modellierbar und damit für 

den Entwickler wenig intuitiv 

Teilabläufe sind schwierig wiederzuverwenden, Abläufe in Web-Anwendungen 

sind monolithisch 

Ziel dieser Arbeit wird ein Ansatz sein, welcher diese Nachteile nicht aufweist. Zwar 

existieren bereits Lösungen, die aus einem Zustandsübergangsdiagramm eine Teilmenge 

der Zustände und Transitionen als Dialog definiert. Allerdings wollen wir noch weiter 

gehen und uns von den Zustandsübergangsdiagrammen zur Beschreibung des Dialogs 

lösen. Das Forschungsgebiet der Mensch-Computer-Interaktion (MCI, engl.: HCI) 

stellt den Benutzer ins Zentrum der Modellierung und verwendet hierarchische Aufgabenmodelle 

um Abläufe auf einer konzeptuellen Ebene aus Sicht des Benutzers zu 

beschreiben. Wir werden dieses Modell als Basis benutzen, um die oben genannten Probleme 

zu lösen. Bevor wir unseren Lösungsansatz vorstellen, werden wir im nächsten 

Abschnitt einen Blick auf den aktuellen Stand der Technik zur Entwicklung von Web- 

Anwendungen werfen. 

1.2 Entwurfsmethoden für Web-Anwendungen 

Für die Modellierung von Web-Anwendungen wurde eine Vielzahl von Entwurfsmethoden 

entwickelt. Zu den Wichtigsten gehören: 

WebML Web Modeling Language [Ceri u. a., 2001] 

OOHDM Object-Oriented Hypermedia Design Method [Güell u. a., 2000] 

UWE UML-based Web Engineering [Kraus und Koch, 2003] 

WSDM Web Site Design Method [de Troyer und Leune, 1998] 

Alle Methoden orientieren sich an den modellbasierten Entwurfsmethoden für klassische 

Desktop-Anwendungen (z. B. die UML) und werden unter der Kategorie Web-Engineering 

zusammengefasst. Die besonderen Anforderungen der Web-Anwendungen 

integrieren die Entwurfsmethoden mit zusätzlichen Modellen, z. B. dem Navigationsmodell 

in UWE zur Beschreibung der Navigationsmöglichkeiten eines Benutzers um eine 

Information oder eine Funktion zu erreichen. Das Navigationsmodell, welches alle 

Methoden des Web-Engineering zur strukturierten Erstellung der Benutzerschnittstelle 

verwenden, ist dabei nicht fest definiert. Ansätze wie WebML beschreiben Interaktionen 

zwischen Benutzer und Anwendung in dem Navigationsmodell und definieren damit 

eigentlich den Dialog. In dieser Arbeit werden wir den Begriff des Dialogmodells 

zur Beschreibung der dynamischen Interaktionen zwischen Benutzer und Anwendung 

verwenden und nur auf den Begriff des Navigationsmodells zurückgreifen, wenn eine 

Navigation in statischen Informationen beschrieben werden soll. 

4

1.3 Lösungsansatz 

Ein Schwachpunkt des Web-Engineerings ist das fehlende eigenständige Dialogmodell, 

das interaktive Verhalten ist implizit im Navigationsmodell enthalten und wird nur 

unzureichend modelliert. Im HCI-Bereich existieren demgegenüber formale Ansätze für 

die modellbasierte Erstellung des Dialogs und der Benutzerschnittstelle eines interaktiven 

Systems: 

GTA Groupware Task Analysis [van der Veer u. a., 1996] 

CTT Concurrent Task Trees [Paternò u. a., 1997] 

UsiXML User Interface XML [Vanderdonckt und Limbourg, 2004] 

Der Entwicklungsprozess spannt sich von der Analyse der gewünschten Benutzerinteraktionen 

bis zu konkreten Benutzerschnittstellen. Ein Aufgabenmodell, welches die 

ausführbaren Aufgaben eines Benutzers auf einem Computersystem modelliert, steht 

im Zentrum der Ansätze. Schwachstelle der HCI-Ansätze ist die Fokussierung auf die Erstellung 

klassischer Benutzerschnittstellen, Web-Anwendungen werden zwar nicht ausgeschlossen, 

aber auch nicht explizit unterstützt. 

Erste Schritte wurden deshalb unternommen, beide Bereiche anzunähern und die 

Schwachstellen zu beseitigen. In WSDM wird ein Aufgabenmodell zur Beschreibung 

des Dialogs verwendet, welches dann in die Erstellung des Navigationsmodells einfließt. 

In OOHDM werden Aufgabenbeschreibungen analysiert, um die Daten zu identifizieren, 

die zwischen dem Benutzer und dem System ausgetauscht werden. Auch die anderen 

Ansätze des Web-Engineering werden zunehmend ergänzt durch eine benutzerzentrierte 

Modellierung (siehe [Brambilla u. a., 2006; Cachero und Koch, 2002]). Die 

benutzerzentrierten Ergänzungen werden allerdings nur informell für die Erstellung 

des Domänenmodells, des Navigationsmodells und des Präsentationsmodells verwendet. 

Die Modellierung des Dialogs von Web-Anwendungen sollte aber im Zentrum der 

Entwicklung stehen und nicht eine Erweiterung einer ansonsten datenzentrierten Entwurfsmethode 

sein. 

In dieser Arbeit wollen wir deshalb einen neuen Ansatz für das Web-Engineering vorstellen, 

welches Kernelemente aus dem HCI-Bereich in Form eines neu zu schaffenden 

Interaktionsmodells integriert. 

1.3 Lösungsansatz 

Wenn wir das Aufgabenmodell in das Zentrum unserer Modellierung stellen, und die 

Benutzerschnittstelle davon ableiten, dann können wir die in der Problemstellung skizzierten 

Probleme lösen. Das Aufgabenmodell wird als Baumstruktur modelliert und unterscheidet 

sich damit von einem flachen Zustandsübergangsdiagramm: 

Wir können Teilbäume kapseln und wiederverwenden 

Über die Hierarchie lässt sich ein Überblick über den Dialog erhalten 

Die Hierarchie vereint kurzlebige (Blätter) und langlebige (Wurzel) Aufgaben 

Diese grundlegende Vorgehensweise werden wir aus dem HCI-Bereich in das Web- 

Engineering übertragen. Anders als in den bestehenden Ansätzen, bei denen Aufgabenmodelle 

üblicherweise sehr früh im Modellierungsprozess in andere Modelle um- 

5

1 Einleitung 

gewandelt werden, wird in dieser Arbeit ein kombiniertes Interaktionsmodell vorgestellt, 

welches Aufgaben-, Dialog- und Präsentationsmodell in sich vereint. Das Aufgabenmodell 

ist dann z. B. nur eine der drei Sichten auf das Interaktionsmodell. Anders 

als Domänenmodelle, die zur Modellierungszeit in eine Anwendung transformiert und 

kompiliert werden, bietet es sich an, das Interaktionsmodell erst zur Laufzeit zu interpretieren 

und eine benutzerspezifische Oberfläche zu generieren. Dieses Ziel wird in 

drei Schritten erreicht: 

Kern des Interaktionsmodells wird im ersten Schritt die Definition eines Aufgabenmodells 

speziell für Web-Anwendungen sein. Ziel ist, aus dem Aufgabenmodell zur Laufzeit 

die Interaktion zwischen dem Benutzer und der Web-Anwendung zu generieren. 

Dazu erweitern wir das klassische Aufgabenmodell um folgende Aspekte: 

Temporale Relationen speziell für Dialoge 

Definiertes Laufzeitverhalten der temporalen Relationen 

Unterbrechbarkeit aufgrund der Zustandslosigkeit des Webs 

Dies reicht allerdings noch nicht aus, um die Benutzerschnittstelle zu beschreiben, 

deshalb werden wir in einem zweiten Schritt das Interaktionsmodell um dialogspezifische 

Informationen erweitern. Im Zentrum stehen die Dialogfragmente und die Anbindung 

an das parallel zu erstellende Domänenmodell. Ein Dialogfragment ist ein modelliertes 

Fragment einer Benutzerschnittstelle, welches dem Benutzer die Möglichkeit 

gibt, eine Aufgabe des Aufgabenmodells zu bearbeiten. Wir werden an dieser Stelle 

komponentenbasierten Web-Frameworks verwenden, um die Präsentation der Fragmente 

zu beschreiben. Größte Herausforderung in diesem Teil ist die Definition einer 

Komposition der Fragmente basierend auf der Hierarchie des Aufgabenmodells. Diese 

Komposition wird uns, abhängig vom Zustand des Aufgabenmodells zur Laufzeit, die 

Benutzerschnittstelle generieren. Das Aufgabenmodell beschreibt, welche Aufgaben in 

welcher Reihenfolge bearbeitet werden und die Dialogfragmente beschreiben, wie die 

Aufgaben bearbeitet werden. Weitere präsentations- und dialogspezifische Erweiterungen 

vervollständigen das Interaktionsmodell. 

Die Laufzeitkomponente wird im dritten Schritt definiert. Während die Definition eines 

Aufgabenmodells und die Erstellung von Dialogfragmenten zur Modellierungszeit 

geschehen, werden erst zur Laufzeit die möglichen Dialogschritte bestimmt und die Benutzerschnittstelle 

aus den Dialogfragmenten zusammengebaut. Zu diesem Zweck wird 

in dieser Arbeit eine Referenzarchitektur des Laufzeitsystems vorgestellt. Diese wird, 

vergleichbar mit einem Portalserver, Basisdienste bereitstellen und Aufgabenmodelle 

in einer gemeinsamen Oberfläche ausführen können. Eine Umsetzung der Konzepte 

wird zeigen, dass die Ideen praktikabel sind. 

Weil, im Gegensatz zu dem klassischen HCI-Aufgabenmodell, bei diesem Ansatz die 

Struktur und der Zustand des Aufgabenmodells auch zur Laufzeit noch zur Verfügung 

stehen, kann diese auch in verschiedener Weise in der Benutzerschnittstelle visualisiert 

werden. Sinnvoll ist eine automatische Umsetzung bestimmter Interaktionsmuster, z. B. 

einer Breadcrumb-Leiste, in der der Weg des Benutzers zur aktuellen Aufgabe angezeigt 

wird, oder der Aufbau von Navigationsmenüs basierend auf der Aufgabenstruktur. 

6

Vorteile der Lösung 

1.4 Gliederung der Arbeit 

Modelle werden nicht umgewandelt, sondern basieren auf einem zentralen 

Modell, dem Interaktionsmodell. 

Zu allen Elementen des Interaktionsmodells existiert eine Definition der 

Laufzeitsemantik. 

Die Benutzerschnittstelle wird in Form von Dialogfragmenten definiert, 

welche mittels einer hierarchischen Komposition zusammengesetzt 

werden. 

Aufgaben-, Dialog- und Präsentationsaspekte können unabhängig und 

parallel modelliert werden. 

Das Laufzeitsystem hat Zugriff auf alle Informationen des Interaktionsmodells 

und kann kontextabhängige Benutzerschnittstellen generieren. 

Nachteile der Lösung 

Der Dialog in unserem Ansatz muss die Vorgaben der Aufgabenhierarchie 

umsetzen. Klassische Dialoge in Form von Zustandsübergangsdiagrammen 

bieten mehr Freiheiten. 

Reduzierung des Präsentationsmodells auf Benutzerschnittstellen von 

Web-Anwendungen. 

Zusammenfassung 

Das Laufzeitsystem erstellt die Präsentation und den Dialog aus einem Interaktionsmodell 

für Web-Anwendungen. Für die Modellierung von prozesslastigen 

Benutzerschnittstellen ist dieser Ansatz besser geeignet als die Modellierung 

mit Zustandsübergangsdiagrammen oder die Verwendung von 

Navigationsmodellen. 

1.4 Gliederung der Arbeit 

Die Arbeit ist in drei Bereiche unterteilt: den Grundlagen, dem Konzept und den Anhängen. 

In den Grundlagen betrachten wir die Vorarbeiten, auf die unsere Arbeit aufbaut. 

Dazu werden in Kapitel 2 (Architekturen für Web-Anwendungen) zuerst die klassischen 

Elemente einer Web-Anwendung in Form einer Architekturübersicht beschrieben. Wir 

beschreiben die geschichtliche Entwicklung und definieren Architekturbegriffe, auf die 

wir uns in dieser Arbeit beziehen. Im darauf folgenden Kapitel 3 (Modellbasierte Entwicklung) 

betrachten wir die existierenden Entwurfsmethoden, um Web-Anwendungen 

zu erstellen. Detailliert stellen wir dort auch die Aufgabenmodelle vor, welche wir 

als zentrales Modell in unseren Ansatz integrieren wollen. 

In den Konzepten beschreiben wir unseren Lösungsansatz. Dazu werden wir im Kapitel 

4 (Überblick über den Lösungsansatz) die Elemente unseres Interaktionsmodells 

7

1 Einleitung 

als Gesamtübersicht vorstellen. Im Kapitel 5 (Aufgabenbasiertes Interaktionsmodell für 

Web-Anwendungen) wird dann, basierend auf den Eigenschaften existierender Aufgabenmodelle, 

ein Aufgabenmodell speziell für Web-Anwendungen hergeleitet. Das 

Aufgabenmodell wird nicht in andere Modelle umgewandelt, sondern um dialogspezifische 

Elemente in Kapitel 6 (Aufgabenbasierte Dialogfragmente für Web-Anwendungen) 

erweitert. Ergebnis ist ein Interaktionsmodell, welches Aufgaben-, Dialog- und 

Präsentationssichten bietet, und für das wir im Kapitel 7 (Architektur für das Laufzeitsystem) 

eine Laufzeitumgebung vorstellen. In den Kapiteln 8 (Bewertung der Ergebnisse) 

und 9 (Ausblick) fassen wir unser Konzept zusammen und beschreiben die noch 

offenen Punkte für eine Weiterentwicklung. 

Die Anhänge fassen unseren Lösungsansatz als Referenz zusammen. In Anhang A 

(Übersicht aller Interaktionselemente) werden die verfügbaren Interaktionselemente, 

die wir zur Beschreibung der Benutzerschnittstelle verwenden können, tabellarisch aufgeführt. 

In Anhang B (Beispiel- und Schemadefinition) definieren wir das Beispiel, das 

wir im Laufe dieser Arbeit aufgebaut haben, noch einmal als vollständiges XML-Dokument. 

Das zugrundeliegende XML-Schema ist dort ebenfalls aufgeführt. 

8

Kapitel 2 

Architekturen für Web-Anwendungen 

Inhalt 

2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2 Architekturkonzeption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.3 Schichtenarchitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.4 Schichtenarchitektur für Web-Anwendungen . . . . . . . . . . . . . . . 16 

2.5 Portalarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

2.6 Architekturmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 

2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 

Die in dieser Arbeit vorgestellten Konzepte werden nicht den gesamten Entwicklungsprozess 

von Web-Anwendungen abdecken, sondern bestehende etablierte Vorgehensweisen 

erweitern. In diesem Kapitel werden die Architekturen von Web-Anwendungen 

vorgestellt, um ein in dieser Arbeit verwendetes Vokabular zu definieren und 

die Stellen, an denen für unseren Ansatz eine Erweiterung stattfinden kann, herauszuarbeiten. 

2.1 Motivation 

Web-Anwendungen machten seit ihrer Entstehung verschiedene Entwicklungsstufen 

durch. Booch [2005] beschreibt, wie eine solche Evolution ohne Architekturkonzeption 

aussieht: 

Eine global erreichbare Webseite zu erstellen ist einfach: HTML lernen, Webseite 

schreiben und einen Server finden. Wie wir gesehen haben, qualifizieren 

sich statische Webseiten nicht als Webanwendungen. Um dauerhaft Nutzer 

zu binden, müssen anspruchsvollere Ideen umgesetzt werden. Obwohl 

einfache Webseiten von einer einzelnen Person ohne Modellierung und mit 

einfachen Hilfsmitteln erstellt werden können, sollten komplexe Web-Anwendungen 

durch ein Team mit anspruchsvollen Modellierungswerkzeugen 

und einem definierten, wiederholbaren Prozess erstellt werden. Es ist anfangs 

einfach, eine bestehende, einfache Webseite zu nehmen und iterativ 

9

2 Architekturen für Web-Anwendungen 

an verschiedene Stellen „bewegliche Teile“ zu integrieren (die Programmiersprache 

Perl ist dafür ein berüchtigtes Beispiel), um daraus eine komplexe 

Web-Anwendung zu erstellen. Viele Webseiten sind heutzutage „Hochhäuser, 

die durch das Stapeln von Lehmhütten entstanden sind“. Wenn nur das 

Ergebnis betrachtet wird, ist dies nicht weiter bemerkenswert, allerdings 

sind solche Systeme mit jeder Änderung exponentiell schwieriger zu pflegen. 

Solche Systeme skalieren nicht mit den Anforderungen, die im Laufe 

der Zeit an eine Web-Anwendung gestellt werden. Ein Mehraufwand am 

Anfang bei der Konzeption kann eine Zeitersparnis in späteren Phasen der 

Entwicklung bringen. 

2.2 Architekturkonzeption 

2.2.1 Fortschritt der Softwareentwicklung 

Auf den ersten Rechnern, die Programme verarbeiten konnten, war Softwareentwicklung 

ein einfacher Prozess. Die Möglichkeiten und Kapazitäten waren begrenzt, die 

Hardware wurde in Assembler programmiert. Der Fortschritt bezüglich der Speicherkapazität 

der Hardware und die Entwicklung neuer Programmierparadigmen machten es 

aber notwendig, von der Implementierung eines Programms zu abstrahieren, um eine 

„höhere Sicht“ auf die Struktur eines Programms zu erhalten. Die Geschichte der 

Softwareentwicklung zeigt diese steigenden Abstraktionen in allen Bereichen ([Booch, 

2005]): 

Sprachen Assembler → Fortran/COBOL → Simula → C++ → Java 

Plattformen Hardware → BIOS → OS → Middleware → Domänen spezifisch 

Prozesse Wasserfall → Spiral → Iterativ → Agile 

Paradigmen Prozedural → Objekt orientiert → Service orientiert 

Werkzeuge Kommandozeile → Integrierte Umgebungen 

Die Softwarearchitektur betrachtet diese Abstraktionen. Doch bevor wir in die Softwarearchitektur 

einsteigen, werden wir zuerst den Architekturbegriff definieren. 

2.2.2 Architekturen 

Der Begriff der Architektur ist weit allgemeiner gefasst, als dass er nur auf Softwaresysteme 

anwendbar wäre. Ausgehend von dem klassischen Architekturbegriff im Bauwesen 

wird der Begriff auch für den strukturellen Aufbau einer Sache oder eines Konzepts 

verwendet 1 . Die Architektur setzt sich mit grundsätzlichen Überlegungen zum Aufbau 

1 zum Beispiel: 

Politik: politische Architektur Europas 

Ingenieurwesen: Architekturentwurf eines Flugzeuges 

Informatik: Rechnerarchitektur, Softwarearchitektur 

10

2.2 Architekturkonzeption 

komplexer Systeme auseinander (siehe [Winter, 2005]). Dabei geht es um die Identifizierung 

einzelner, möglichst unabhängiger Komponenten des Gesamtsystems und ihren 

Schnittstellen untereinander. Gute Architekturen zeichnen sich dadurch aus, dass 

sie möglichst einfach wiederverwendbar sind und den strukturellen Aufbau eindeutig 

beschreiben. 

Eine Zerlegung eines Konzeptes in abgegrenzte Komponenten und deren Schnittstellen 

bietet drei zentrale Vorteile (illustriert am Beispiel eines Großflugzeugprojektes): 

1. Sie dient der Komplexitätsreduzierung, weil eine große Aufgabe in überschaubare 

Teile zerlegt wird. Bei der Realisierung können die Entwickler sich auf das 

Erfüllen der Teilbereiche konzentrieren, der Architekturentwurf bietet trotzdem 

eine abstrakte Gesamtsicht auf das Projekt. Motoren sind unabhängig von der 

Flügelkonstruktion, wenn die Schnittstellen sauber definiert sind. 

2. Sie dient der Skalierung des Projektentwurfs, weil mehrere Entwickler parallel an 

verschiedenen Komponenten arbeiten können. Es besteht die Möglichkeit, Spezialisten 

auszubilden, die sich nur auf Teilkomponenten konzentrieren. Motoringenieure 

haben andere Aufgaben und durchlaufen andere Ausbildungen als 

Aerodynamikspezialisten. 

3. Sie dient der Modularisierung, weil einzelne Komponenten austauschbar sind, ohne 

andere Komponenten zu beeinflussen. Bei einem Flugzeug besteht die Möglichkeit, 

aus einer Auswahl von Motoren die passende Variante für den jeweiligen 

Einsatzzweck auszuwählen. 

2.2.3 Softwarearchitektur 

Übertragen auf die Softwarearchitektur 2 bedeutet dies, ein Softwaresystem in Bausteine 

zu zerlegen, die dem Prinzip der losen Kopplung, dem Prinzip der hohen Kohäsion 

und dem Modularitätsprinzip folgen (siehe [Vogel u. a., 2005], [Posch u. a., 2004]). 

Die Kopplung beschreibt den Grad der Abhängigkeiten zwischen den Bausteinen in 

einem Softwaresystem. Kopplungen entstehen beispielsweise durch die Verwendung 

von Schnittstellen anderer Bausteine oder durch Vererbungshierarchien, in denen von 

Klassen anderer Bausteine abgeleitet wird. Das Prinzip der losen Kopplung besagt, die 

Abhängigkeiten zwischen den Bausteinen gering zu halten sind, um die Komplexität 

des Gesamtsystems zu reduzieren. 

2 Der erste formale Standard der Softwarearchitektur „ANSI/IEEE 1471-2000: Recommended Practice for Architecture 

Description of Software-Intensive Systems„ (siehe [IEEE, 2000]) definiert die Architektur von Softwaresystemen 

als . . . 

. . . the fundamental organization of a system embodied in its components, their relationships to 

each other and to the environment and the principles guiding its design and evolution, where: 

fundamental organization means essential, unifying concepts and principles 

system includes application, system, platform, system of systems, enterprise, . . . 

environment is the developmental, operational, programmatic, . . . context of the system 

Wir werden die Softwarearchitektur aber nur in den für Web-Anwendungen relevanten Teilen behandeln. 

11


hohe Kohäsion, geringe Kopplung 

Baustein 1 Baustein 2 

geringe Kohäsion, hohe Kopplung 

Baustein 1 Baustein 2 

Abbildung 2.1: Beispiel für eine gute Softwarearchitektur (hohe Kohäsion, geringe Kopplung) und 

eine schlechte Softwarearchitekur (geringe Kohäsion, hohe Kopplung) 

Die Kohäsion beschreibt den Grad der Abhängigkeiten der Elemente innerhalb eines 

Bausteins. Das Prinzip der hohen Kohäsion besagt, dass ein Baustein möglichst viele 

interne Abhängigkeiten besitzen sollte, damit im Rahmen der Abstraktion von dem 

Softwaresystem auch von einem Baustein mit eindeutiger Funktionalität gesprochen 

werden kann. Wenn z. B. innerhalb eines Bausteins zwei (fast) disjunkte Abhängigkeitsgraphen 

existieren, spricht vieles dafür, dass es sich bei dem Baustein in Wirklichkeit um 

zwei Bausteine handelt und diese auch entsprechend modelliert werden sollten. 

Abbildung 2.1 zeigt ein abstraktes Beispiel, das die Prinzipien verdeutlichen soll. Auf 

der linken Seite ist eine gute Softwarearchitektur abgebildet, die Bausteine besitzen 

hohe interne Abhängigkeiten und niedrige externe Abhängigkeiten. Auf der rechten 

Seite ist eine schlechte Softwarearchitektur abgebildet, die Bausteine besitzen viele 

Abhängigkeiten untereinander. Intern existieren disjunkte Elementmengen, durch eine 

weitere Verfeinerung der zwei Bausteine in vier Bausteine könnten die Grade der 

Kopplung und der Kohäsion verbessert werden. 

2.2.4 Modularitätsprinzip 

Das Modularitätsprinzip besagt, dass die Bausteine sowohl den Kopplungs- und Kohäsionsprinzipien 

folgen, als auch eindeutig definierte Schnittstellen anbieten sollten, um 

eine leichte Austauschbarkeit der modularisierten Bausteine zu gewährleisten. 

Das Modularitätsprinzip zu erfüllen ist das Ziel, das eine gute Softwarearchitektur 

anstreben sollte. Wir werden in dieser Arbeit das Modularitätsprinzip auch für die Benutzerschnittstellen 

für Web-Anwendungen aufgreifen, um Dialogabläufe modular zu 

gestalten (z. B. hinzufügen neuer Dialoge in einem bestehenden Dialogentwurf, Wiederverwendung 

von Dialogen aus anderen Entwürfen). 

2.2.5 Zusammenfassung 

Die Beachtung der vorgestellten Prinzipien beim Entwurf erlaubt es, von einem Problem 

abstrahierte, wiederverwendbare und auf andere Problembereiche übertragbare 

12

2.3 Schichtenarchitekturen 

Softwarearchitekturen zu erschaffen. Nachdem wir die Erwartungen an eine gute Softwarearchitektur 

vorgestellt haben, werden wir in den nächsten Abschnitten etablierte 

Architekturen für Web-Anwendungen vorstellen. Wie wir sehen werden, können auf 

den verschiedenen Abstraktionsebenen unterschiedliche Architekturen verwendet werden, 

die sich zu einer Gesamtarchitektur kombinieren lassen. 


Schichtenarchitekturen werden verwendet, um komplexe Anwendungen in logische 

Schichten 3 zu unterteilen, welche nur über definierte Schnittstellen mit den untergeordneten 

Schichten kommunizieren können. Dies erlaubt eine Reduktion der Abhängigkeiten 

innerhalb der Anwendung und erhöht durch Kapselung die Möglichkeiten 

der Modularisierung. Die Schichtenarchitektur beschreibt klassischerweise eine vertikale 

Unterteilung der Serveranwendung, wobei eine Anfrage alle Schichten der Anwendung 

von oben nach unten und wieder zurück durchquert. 

Die folgenden Abschnitte zeigen den Zusammenhang zu Client/Server Systemen auf 

und beschreiben die unterschiedlichen Ausprägungen der Schichtenarchitektur bis hin 

zur Drei-Schichten-Architektur, auf die wir im Verlauf dieser Arbeit zurückgreifen werden. 

2.3.1 Ein-Schicht-Architektur 

Terminal 

Server 

Abbildung 2.2: 

Ein-Schicht-Architektur 

In den Anfängen der IT-Entwicklung gab es einfache Terminal/Server-Systeme, 

bei denen auf Mainframes ein Server 

eingesetzt wurde, welcher über eine direkte Verbindung 

mit einem Terminal kommunizierte. Diese Konzeption 

nennt sich Ein-Schicht-Architektur (siehe Abbildung 

2.2). 

Obwohl die Trennung von Terminal und Server mehrere 

Ebenen nahelegt, ist die Verbindung sehr statisch und 

lässt z. B. nur ein Terminal zu, über das der Server gesteuert 

wird. Die Anwendungen liefen im Batch-Betrieb ohne 

Benutzeroberfläche auf dem Server und wurden über 

externe Kommandos der Eingabekonsole gesteuert, es existierte nur eine (implizite) 

Modellebene. 

2.3.2 Zwei-Schichten-Architektur 

Die Definition des Schichtenbegriffs ist eng an den Aufstieg der Client/Server-Systeme 

Anfang der 90er Jahre gekoppelt. Aus diesem Grund werden wir kurz die Entstehung 

3 engl.:layers. Der englische Begriff tiers wird oft synonym verwendet, legt aber auch eine physische Trennung 

nahe, bei dem verschiedene tiers auf verschiedenen Rechnern im Netzwerk verteilt werden können. Diese Unterscheidung 

geht uns zu weit, weshalb wir den Begriff layer im Sinne von logische Schicht bevorzugen. 

13


des Client/Server-Begriffs skizzieren, um dann den Einfluss auf die Schichtenarchitektur 

zu erklären. 

Client/Server Hintergrund 

Das Client/Server Paradigma (siehe [Comer, 2006]) entstand ursprünglich im Datenbankumfeld, 

in dem eine Workstation über ein Netzwerk mit einem SQL-Datenbankserver 

kommunizierte. 

In der gröbsten Vereinfachung der Client/Server Architektur bietet ein Server-System 

(Dienstleister) einem Client-System (Dienstnutzer) Informationen an. Spezieller beschreibt 

eine Client/Server Architektur ein im Allgemeinen netzwerkfähiges System, bei 

dem ein Client den Kontakt zu einem separaten Server initiiert, um einen bestimmten 

Dienst zu verwenden 4 . Der Client steht dem Server als Anfragender gegenüber. 

Seitdem sich in den letzten Jahren komplexe Informationssysteme im Umfeld des 

Internets entwickelt haben, hat das Client/Server Konzept als Applikationsarchitektur 

ebenfalls an Bedeutung gewonnen. Im Bereich des World Wide Webs basieren fast alle 

Dienste auf der Client/Server Architektur. Ein Dienst wird als Server im Netzwerk gestartet 

und kann Anfragen von Clients beantworten. Falls dieser Server seinerseits Informationen 

von anderen Servern anfordern will, wird er zum Client, die Bezeichnungen 

identifizieren also nur logisch die Kommunikationspartner. 

Client/Server als Schichtenarchitektur 

Clientschicht 

(Präsentation) 

Serverschicht 

(Daten) 


Zwei-Schichten-Architektur 

In einer Zwei-Schichten-Architektur sind Client und Server 

getrennte Schichten, einer Schicht für die grafische 

Benutzerschnittstelle und einer Datenschicht (siehe Abbildung 

2.3). Die Zwei-Schichten-Architektur setzte sich 

gegenüber der Ein-Schicht-Architektur aufgrund der Verbreitung 

von lokalen Netzen und der damit bedingten 

geringeren Latenzzeiten bei der Kommunikation Anfang 

der 90er Jahre durch. Die grafischen Benutzerschnittstellen 

konnten Daten ausgeben und relationale Operationen 

auf Datenbankservern durchführen. 

Probleme gab es aber, wenn z. B. Berechnungen durchgeführt oder Eingaben validiert 

werden sollten. Dies konnte entweder in der grafischen Benutzerschnittstelle geschehen 

(Fat Client) oder im Datenbankserver als Stored-Procedure abgelegt werden (Thin 

Client). Beides hatte Nachteile: Benutzerschnittstellen waren meist seitenbasiert, häufig 

auftretende Berechnungen waren redundant in mehreren Seiten gespeichert. Stored-Procedures 

als Ablageort für Berechnungslogik in der Datenbank waren nicht Teil 

des SQL Standards sondern proprietäre Erweiterungen der Datenbankhersteller, viele 

Nutzer entschieden sich aufgrund fehlender Wechselmöglichkeit auf Produkte anderer 

Hersteller gegen diese Möglichkeit. 

4 Ausprägungen der Schichtenarchitekturen für monolithische Anwendungen, die nur auf dem Rechner des 

Benutzers ausgeführt werden, werden hier aufgrund des Fokus auf Web-Anwendungen nicht weiter betrachtet. 

14

2.3.3 Drei-Schichten-Architektur 

Präsentationsschicht 

Anwendungsschicht 

Datenschicht 


Drei-Schichten-Architektur 


Kurze Zeit, nachdem sich Client/Server Systeme etabliert 

hatten, wurden objektorientierte Programmiersprachen 

populär. Mit diesen ließen sich nicht redundante Berechnungen 

durchführen, die zusätzlich unabhängig vom Datenbanksystem 

sind. Die Drei-Schichten-Architektur (siehe 

Abbildung 2.4) präzisiert deshalb die Zwei-Schichten-Architektur, 

indem eine weitere Schicht, die “Anwendungsschicht”, 

hinzugefügt wurde. Die objektorientierten Programmiersprachen 

sind allerdings nicht der alleinige Beweggrund, 

dass sich die Drei-Schichten-Architektur durchgesetzt 

hat. Erst die rasche Verbreitung des Webs machte 

es notwendig, Anwendungslogik auf dem Server auszu- 

führen; Webbrowser waren nicht in der Lage, Berechnungen oder Validierungen durchzuführen. 

Die unterste Schicht bleibt weiterhin die Datenschicht (englisch: data source layer 5 ) 

mit den Schnittstellen für die Datenbankabfragen. In der mittleren Schicht entsteht 

eine Anwendungsschicht (englisch: application layer 6 ), die die Anwendung von der Datenhaltung 

trennt und als eigenständige Schicht die Applikation repräsentiert. Oben 

schließt sich die Präsentationsschicht (englisch: presentation layer) an, die nur für die 

Präsentation der Daten zuständig ist. Bei Web-Anwendungen wird diese Präsentation 

auf dem Server als HTML-Beschreibung aufbereitet und vom Client im Webbrowser dargestellt. 

Der Webbrowser ist ein generischer Thin Client. 

Die Verwendung einer Drei-Schichten-Architekturen bietet folgende Vorteile im Vergleich 

zu einer Zwei-Schichten-Architektur: 

Die Benutzerschnittstelle ist von der Datenhaltung getrennt. Beide Komponenten 

können getrennt entwickelt und neuen Bedürfnissen angepasst werden. Die 

Applikation verknüpft beide Teile und ist in einer eigenen Schicht abstrahiert. Verbunden 

werden die Schichten über definierte Schnittstellen. 

Die Flaschenhälse im Netzwerk werden minimiert, es werden nur Daten an die 

nächste Schicht weitergeleitet, die sie für das Erfüllen ihrer Funktion benötigen. 

Vorher, als die Applikationen im Client liefen, konnten eventuell mehr Daten übertragen 

worden sein, als für die Darstellung wirklich notwendig waren. 

Falls die Applikation sich ändert, muss nur an dem Server die Änderung eingespielt 

werden. Bei einer Zwei-Schichten-Architektur müssen im ungünstigsten Fall (Fat 

Clients) alle Clients ersetzt werden. 

Der Client wird von der Datenbank abstrahiert. Er muss nicht Ort und Art der 

gespeicherten Daten kennen, sondern kann über eine Schnittstelle Daten mit höherer 

Abstraktion abrufen. 

5 alternativ: data access, persistence 

6 alternativ:Geschäftslogik, Domäne, domain, business logic 

15


Die Applikationsentwicklung ist nicht mehr auf die vom Datenbankhersteller vorgegebene 

Sprache beschränkt, sondern kann in einer beliebigen Sprache erfolgen. 

Voraussetzung dafür ist eine gemeinsame Schnittstelle, die sowohl die Datenbank 

als auch die gewünschte Programmiersprache unterstützt. 

2.3.4 Mehrschichten-Architektur 

Basierend auf der Drei-Schichten-Architektur wurden verschiedene weitere Schichten 

identifiziert, die allerdings nicht den allgemeingültigen Charakter der drei Hauptschichten 

aufweisen und sich nicht in diesem Maße als Schichtenarchitektur durchgesetzt haben. 

In [Brown u. a., 2001] werden die zwei möglichen Bindeschichten der Drei-Schichten- 

Architektur beschrieben: Die data mapping Schicht zwischen der Anwendungs- und der 

Datenschicht enthält die Methoden zum Abbilden der objektorientierten Daten der Anwendungsschicht 

auf die relationalen Daten der Datenschicht 7 . Die controller Schicht 

zwischen der Präsentations- und Anwendungsschicht enthält die für die Präsentation 

notwendigen Kontrollstrukturen. Dies entspricht dem Controller 8 im MVC-Architekturmuster 

(siehe Abschnitt 2.6.1). 

In [Alur u. a., 2001] wird die Präsentationsschicht in zwei Schichten aufgeteilt: Die 

client presentation Schicht, in der client-seitige Präsentation modelliert wird (z. B. Darstellung 

mit Javascript), und die server presentation Schicht, in der die auf dem Server 

generierte Präsentation modelliert wird (z. B. HTML-Generatoren). 


Wie wir gezeigt haben, hat sich die heute verbreitete Drei-Schichten-Architektur aus 

den geschichtlichen Zwängen und Notwendigkeiten entwickelt. Ob und wie sie sich 

weiter entwickeln wird, ist jetzt noch nicht abzusehen. Das Hinzufügen weiterer Schichten 

wird sich wahrscheinlich nicht durchsetzen, weil es dem obersten Ziel einer Architekturkonzeption 

– den Überblick über das Gesamtsystem zu erlangen und Komplexität 

zu reduzieren – zuwiderläuft. Vielmehr wird es wohl bei den drei Schichten bleiben und 

in weiteren Verfeinerungsschritten der Architekturkonzeption können Architekturmuster 

in die Schichtenarchitektur integriert werden. 

Im Folgenden werden wir erläutern, weshalb sich die Drei-Schichten-Architektur gerade 

für die Konzeption von Web-Anwendungen eignet und Architekturmuster vorstellen, 

die für Web-Anwendungen sinnvoll verwendbar sind. 

2.4 Schichtenarchitektur für Web-Anwendungen 

Für Web-Anwendungen wird in den meisten Fällen die Drei-Schichten-Architektur verwendet. 

Conallen [2000] beschreibt dies als kanonische Architektur, nach der sich, in 

7 objekt/relationales Mapping [Fowler, 2003] 

8 Model ist die Anwendungsschicht, View ist die Präsentationsschicht 

16

Webbrowser 

2.4 Schichtenarchitektur für Web-Anwendungen 

Präsentationsschicht Anwendungsschicht 

Internet 

Webserver 

Applikationsserver 

Client-Schicht Server-Schicht 

Datenschicht 

physische physische 

Daten 

Abbildung 2.5: Referenzarchitektur für Web-Anwendungen nach [Conallen, 2000] 

dieser groben Abstraktion, fast alle Web-Anwendungen aufgliedern lassen (siehe Abbildung 

2.5). Die Präsentationsschicht wird durch den Webserver und den Webbrowser 

repräsentiert. Die Anwendungsschicht findet ihre Realisierung im Applikationsserver. 

Die Datenschicht wird in Form einer relationaler Datenbank umgesetzt. Wie in der Abbildung 

deutlich wird, haben sich die Schichten im Vergleich zur Zwei-Schichten-Architektur 

verschoben, von den physischen Schichten Client und Server zu logischen Schichten, 

wobei die Präsentationsschicht sich zum Teil in der Client- und in der Serverschicht 

wiederfindet. 

2.4.1 Beispiel 

Am Beispiel eines Buchversandhändlers sollen die Schichten erläutert werden. In der Datenschicht 

sind die verfügbaren Bücher, die Autoren, die Kunden, die Bestellpositionen, 

etc . . . strukturiert abgelegt. Nur die Anwendungsschicht darf auf die Datenschicht zugreifen 

und bietet Dienste nach außen an. Diese Dienste sind von der Datenschicht abstrahiert 

und setzen im Regelfall Anwendungsfälle um, z. B. nach Büchern suchen oder 

Buch bestellen. Die Anwendungsschicht ist auch die geeignete Stelle um Querschnittsthemen 

umzusetzen, z. B. zur Berechtigungsprüfung, zur Definition von Transaktionsgrenzen 

oder zum Erstellen von Log-Dateien. Die Präsentationsschicht regelt den Dialog 

zwischen Benutzer und Applikation, nimmt also Eingaben des Benutzers entgegen, erzeugt 

daraus Aufrufe in die Applikationsschicht und wandelt die Rückgaben der Applikation 

in eine für den Benutzer auswertbare Form (bei Web-Anwendungen fast immer 

HTML) zurück. 

17


Client-Schicht Präsentationsschicht 


Browser 

Browser 

(asynchrones 

Javascript) 

Websevice 

Konsument 

Desktop 

Anwendung 

Präsentationskontrolle 

Webservice 

Anbieter 

Präsentationslogik 

Webserver 

Anwendungsimplementation 

SQL 

Treiber 

Cache 

Http 

Zugriff 

Smtp 

Zugriff 

Abbildung 2.6: Detaillierte Referenzarchitektur für Web-Anwendungen 

2.4.2 Web-Applikationsserver 

ORM 

Datenschicht 

Datenbank 

Dateisystem 

Externe 

Webservices 

Emailsystem 

In diesem Abschnitt wollen wir einen detaillierteren Blick auf die Architektur von Web- 

Anwendungen werfen (siehe Bild 2.6). Im Mittelpunkt steht die Anwendungsschicht, 

welche die fachlichen Anforderungen der Web-Anwendung umsetzt. Um häufig verwendete 

Funktionen nicht selbst umsetzen zu müssen, laufen Anwendungen in einem 

Applikationsserver, welcher diese Funktionen bereitstellt. Im Bild sind Integrationsdienste 

angedeutet, die z. B. den Zugriff auf Datenbanken, Webservices und Dateisystemen 

abstrahieren. Weitere Vorteile der Applikationsserver sind die Unterstützung 

der oben genannten Querschnittsthemen (Transaktionen und Logging) und die implizite 

Skalierbarkeit der Anwendung (durch Clustering der Server). 

Die Anwendung bietet eine definierte Schnittstelle nach außen, auf die die Präsentationsschicht 

zugreifen kann. Im einfachsten Fall über eine rein client-seitige Anwendung, 

die direkt auf diese Schnittstelle zugreift. Die Schnittstelle kann auch als Webservice 

nach außen freigegeben werden, dazu müssen die Dienste der Anwendungsschnittstelle 

über ein XML-Format ansprechbar sein (Webservice Anbieter). 

Für Web-Anwendungen — bei denen der Client ein Webbrowser ist — muss der Applikationsserver 

den Dialog verwalten (Präsentationskontrolle) und die Daten der Anwendung 

auf die Präsentation übertragen (Präsentationslogik). Nicht immer kann einer 

Web-Seite genau ein Anwendungsaufruf zugeordnet werden; manchmal kann daraus 

ein Prozess entstehen, der in der Präsentationsschicht verwaltet werden muss. Zum Beispiel 

müssen für einen Bestellvorgang erst in mehreren Schritten die Adresseingabe 

und die Zahlungsmodalitäten eingegeben werden, um dann im letzten Schritt die Bestellung 

endgültig in die Anwendungsschicht weiterzuleiten. 

18

2.5 Portalarchitektur 

Wie der Dialog definiert wird und wie die Anwendungs- und die Benutzerschnittstelle 

in den Dialog integriert werden, wird im Zentrum dieser Arbeit stehen. 


In einem Web-Applikationsserver können mehrere Anwendungen parallel verwendet 

werden. Jede Anwendung besitzt allerdings eine eigene Web-Schnittstelle, eine Integration 

der Anwendungen in eine konsistente Oberfläche ist nur mithilfe weiterer Basisdienste 

möglich. Diese erweitern den Web-Applikationsserver zu einem Portalserver, 

indem sie nicht nur die visuelle Integration erlauben, sondern auch z. B. die Benutzerverwaltung 

oder die Suche über dem Datenbestand aller Anwendungen zentralisieren. 

Für unseren Ansatz verfolgen wir ähnliche Ziele wie Portalserver: Wir wollen verschiedene 

Dialoge in eine konsistente Oberfläche integrieren. Der Hauptunterschied zu Portalservern 

liegt in unserem Fokus auf der Präsentationsschicht. Während die Portalanwendungen 

klassisch die Dialoge als Zustandsübergangsautomaten umsetzen, werden 

wir den neuen Ansatz der zur Laufzeit ausgeführten Aufgabenmodelle verwenden. Abstriche 

machen wir allerdings bei den Basisdiensten der Datenschicht (z. B. die Suche), 

welche wir im Kontext dieser Arbeit nicht genauer betrachten werden. 

Trotz dieser Einschränkung sind einige Basisdienste auch für das Ausführen von Dialogen 

und damit für unseren Ansatz sinnvoll verwendbar. Zu diesem Zweck stellen wir 

erst eine allgemeine Referenzarchitektur für Portalserver vor und betrachten dann die 

für uns verwendbaren Basisdienste genauer. 

2.5.1 Referenzarchitektur Portalserver 

Eine Referenzarchitektur für Portalserver ist in Abbildung 2.7 dargestellt (nach [Kirchhof 

u. a., 2004]). Die Portalarchitektur basiert auf der Applikationsserverarchitektur aus 

Abbildung 2.6, erweitert um portalspezifische Basisdienste. Die anderen Schichten neben 

der Anwendungsschicht sind zum besseren Verständnis ausgeblendet, aber unverändert 

vorhanden. Die Anwendungsschnittstelle ist jetzt nicht mehr von außen erreichbar, 

die Anwendung erhält stattdessen über eine definierte Portalschnittstelle Zugriff 

auf die Portal-Basisdienste. Die Anwendung wird nicht mehr aus der Präsentationsschicht 

direkt angesprochen, sondern jede Anfrage erreicht erst die präsentationsspezifischen 

Basisdienste, welche dann entscheiden, wo welche Portalanwendung in die 

zurückgelieferte Seite integriert werden soll. 

Die Liste der aufgeführten Basisdienste ist eine lose Sammlung der Dienste mit hohem 

Querschnittsanteil, die also sinnvollerweise zentral verwaltet werden und auf die 

alle Portalanwendungen zugreifen können. Auf die weiß hervorgehobenen Basisdienste, 

welche eine Relevanz für die Präsentation haben, werden wir in den nächsten Abschnitten 

eingehen. An dieser Stelle wird nur kurz auf die verbleibenden Dienste eingegangen. 

Unter Content Management versteht man das Verwalten von Inhalten, die in der 

Portalanwendung Verwendung finden. Im Beispiel des Buchversandhändlers wäre z. B. 

die Pflege des Buchbestandes eine typische Funktion des Content Managements. Die 

19


Client-Schicht 


Portal Basisdienste 

Layout Management 

Struktur Management 

Content Management 

Benutzerverwaltung 

Suche 

Prozessunterstützung 

Single-Sign-On 

weitere Module 


Portalschnittstelle 

Anwendungsverwaltung 

individuelle Anwendung 





Abbildung 2.7: Detaillierte Referenzarchitektur für Portal-Anwendungen 

Abbildung des Lebenszyklus eines Inhaltsobjektes und die Versionierung der Inhalte 

erzeugen eine Komplexität, die dank der Realisierung als Basiskomponente nicht für 

jede Portalanwendung erneut umgesetzt werden muss. 

Die Portalanwendungen sind unabhängig voneinander und haben nur Zugriff auf 

ihren eigenen Datenbestand. Um dem Benutzer die Möglichkeit zu bieten, über alle 

Inhalte des Portalservers zu suchen (zentrale Suchmaske in der Oberfläche), muss der 

Basisdienst Suche verwendet werden. Dieser kann die Daten der Portalanwendungen 

indizieren, eigenständig die Suche durchführen und auf die entsprechende Portalanwendung 

verweisen, wenn der Benutzer ein Suchergebnis ausgewählt hat. 

Diese beiden Basisdienste werden wir nicht weiter betrachten, weil sie hauptsächlich 

die Datenschicht betreffen und damit als Basisdienst in unserem Ansatz keine Verwendung 

finden. In der umgekehrten Richtung können komplexe Dialoge für das Content 

Management oder die Suche natürlich auch mit unserem Ansatz umgesetzt werden. 

2.5.2 Basisdienste mit Relevanz für unseren Ansatz 

Die im Folgenden aufgeführten Basisdienste sind für unseren Ansatz interessant, weil 

sie Funktionalität zur Verfügung stellen, auf die wir uns bei der Modellierung beziehen 

20 

Integrationsdienste 

Datenschicht


und die wir zur Laufzeit verwenden können. Wir wollen uns vom spezifischen Portal 

lösen und die Dienste als allgemeine Komponenten einer Architektur vorstellen. Die 

Anwendungen, die diese Dienste nutzen, können dabei Portalanwendungen oder Dialoge 

aus unserem Ansatz sein. 

Anwendungsverwaltung 

Anwendungen sollten unabhängig voneinander im Applikationsserver ausgeführt und 

verwaltet werden. Anwendungen besitzen einen Lebenszyklus, der den aktuellen Zustand 

der Anwendung widerspiegelt, mögliche Transitionen im Lebenszyklus sind zum 

Beispiel: 

installieren Macht die Anwendung im Applikationsserver verfügbar. 

pausieren Keine neue Instanzen der Anwendung erlauben. 

aktivieren Pausierte Anwendung wieder fortsetzen. 

entfernen Entfernt eine Anwendung aus dem Applikationsserver. 

Weil die Anwendungen unabhängig voneinander ausgeführt werden, sollten diese Aktionen 

für eine Anwendung auch im laufenden Betrieb des Applikationsservers möglich 

sein, um einen reibungslosen Ablauf der restlichen Anwendungen zu gewährleisten. 

Benutzerverwaltung 

Benutzer sollten zentral verwaltet werden, damit Benutzerinformation (z. B. Vorname, 

Emailadresse, etc . . . ) konsistent abgefragt werden können und nicht jede Anwendung 

eine eigene redundante Benutzerverwaltung umsetzen muss. Auch wird häufig ein externer 

Verzeichnisdienst mit Benutzerinformationen angeschlossen, die Benutzerverwaltung 

dient dann als Abstraktionsschnittstelle für die Anwendung zu diesen Diensten. 

Die Benutzerverwaltung nimmt auch die Rolle des zentralen Authentifizierungsdienstes 

wahr, mit ihr lässt sich die Identität eines Benutzers durch die Anwendung überprüfen 

9 . 

Rechteverwaltung 

Neben der Authentifizierung sollte auch die Autorisierung der Benutzer (der Zugriffsschutz 

eines Benutzers auf eine Ressource) zentral verwaltet werden. Zu diesem Zweck 

hat sich der rollenbasierte Zugriffsschutz [INCITS, 2004] etabliert, bei dem zentral Zugriffsrollen 

verwaltet werden, die den Zugriff auf die Ressourcen bestimmen. Die Rechteverwaltung 

kann dann, unabhängig von den Anwendungen, die Rollen den Benutzern 

zuordnen. 

9 Im einfachsten Fall über Name/Passwort-Kombinationen, oder aber auch über biometrische Verfahren 

21


Single-Sign-On 

Einmal authentifiziert, sollte der Benutzer für alle Anwendungen innerhalb des Applikationsservers 

identifizierbar sein, bis der Benutzer sich explizit wieder abmeldet. Als 

Basisdienst erlaubt dies auch die automatische Übernahme einer bereits getätigten Authentifizierung 

von einer externen Quelle, z. B. einer Anmeldung am Betriebssystem. 

Prozessunterstützung 

Es existieren eine Vielzahl von Ansätzen [Keller u. a., 1992; OMG, 2008], um Prozesse 

und Abläufe innerhalb von Anwendungen abzubilden. Prozesse können in verschiedenen 

Schichten der Anwendung Verwendung finden, z. B. in der Anwendungsschicht als 

Geschäftsprozess oder in der Präsentationsschicht als Dialog. 

Als Basisdienst kann die Prozessunterstützung allen Anwendungen eine einheitliche 

Schnittstelle bieten. Auch die Integration von Prozessen, z. B. eine Anwendung als Subprozess 

einer anderen Anwendung, ist damit möglich. 

Layoutmanagement 

Wenn mehrere Anwendungen dargestellt werden, sollten diese vom äußeren Erscheinungsbild 

10 zusammenpassen. Um dies zu erreichen, sollten die Anwendungen nicht direkt 

die Benutzeroberfläche generieren, sondern die Oberfläche abstrakt beschreiben. 

Das Layoutmanagement erzeugt dann für eine Anwendung erst zur Laufzeit aus der 

abstrakten Beschreibung eine endgültige Benutzeroberfläche, die einem einheitlichen 

Stil folgt. 

Außer dem Generieren der Benutzeroberflächen einzelner Anwendungen sorgt das 

Layoutmanagement auch für die Integration mehrerer Anwendungen in eine kombinierte 

Oberfläche. Dies kann nur zentral geschehen und erlaubt dem Benutzer, übergangslos 

verschiedene Anwendungen zu benutzen. 

2.5.3 Zusammenfassung und Ausblick 

In diesem Abschnitt haben wir – auf einer allgemeinen Ebene – die notwendigen Basisdienste 

beschrieben, um mehrere Anwendungen parallel auf einem Applikationsserver 

und in einer kombinierten Benutzeroberfläche auszuführen. 

Im Laufe dieser Arbeit werden wir aufgabenbasierte Dialoge definieren, welche als 

einzelne Anwendungen betrachtet werden können. Wir werden die hier beschriebenen 

Basisdienste adaptieren und in unsere Architektur aufnehmen, damit z. B. das Aufgabenmodell 

mit Zugriffsrollen der Rechteverwaltung ausgestattet werden kann, oder 

damit eine Benutzeroberfläche aus der Menge der abstrakten Oberflächenelemente 

des Layoutmanagements erstellt werden kann. 

10 engl.:look and feel 

22

2.6 Architekturmuster 


Während die Schichtenarchitektur einen abstrahierten Blick auf das Gesamtsystem beschreibt, 

bieten sogenannte Architekturmuster generische Lösungen für die Modellierung 

eines Teilbereiches einer Anwendung. Diese Lösungen sind kombinierbar, sodass 

in einer Anwendung eine Vielzahl an Architekturmuster verwendet werden können. 

Auch schließen die Architekturmuster und die Schichtenarchitektur sich nicht gegenseitig 

aus, die meisten Architekturmuster lassen sich einer Schicht zuordnen und bieten 

damit Lösungen für einen dedizierten Teil einer Anwendung. 

Booch [2005] beschreibt die Erkenntnis, dass „gut-strukturierte“ Anwendungen inhärente 

und generische Entwurfsmuster aufweisen, als eine der wichtigsten Fortschritte 

in der Softwareentwicklung der letzten Jahre. In der klassischen Definition, nach dem 

Architekten Christopher Alexander [Alexander u. a., 1977], ist ein Muster eine Lösung 

für ein Problem in einem festgelegten Kontext. Ein Muster beschreibt auf wiederverwendbare 

Weise das empirische Wissen einer Domäne. 

Der Begriff Entwurfsmuster 11 wurde geprägt von [Gamma u. a., 1995], welche für objektorientierte 

Anwendungen einen Satz von wiederverwendbaren Mustern beschrieben. 

Die einzelnen Muster können meist nur auf einen kleinen Teil der Anwendung 

angewandt werden, bleiben dadurch aber kompakt und übertragbar. Ein großer Vorteil 

war die Vereinheitlichung der Begriffswelt, die sich durch die weite Verbreitung der 

Entwurfsmuster aus [Gamma u. a., 1995] ergab. Entwickler konnten Konzepte referenzieren, 

indem sie den Namen des entsprechenden Musters verwendeten. Vor allem die 

Klassenbibliotheken der objektorientierten Programmiersprachen, welche von vielen 

Entwicklern verwendet werden, profitieren durch die Referenzen auf die Entwurfsmuster 

durch die Namensgebung der Klassen 12 . 

Architekturmuster sind von Entwurfsmustern zu unterscheiden, weil sie nicht nur lokale 

Teilprobleme lösen, sondern den Grundaufbau der Anwendung vorgeben. Aus 

diesem Grund ist das bei Entwurfsmustern übliche Refactoring, also das strukturelle 

Verbessern einer bestehenden Anwendung durch die Einführung von Patterns, bei Architekturmustern 

nur schwer umsetzbar. Architekturmuster müssen von Anfang an im 

Entwurfsprozess eingebunden werden. 

Im Folgenden wollen wir einige etablierte Architekturmuster vorstellen, die wir im 

Laufe der Arbeit verwenden werden. 

2.6.1 Model View Controller 

Model View Controller (MVC) ist das bekannteste Architekturmuster für die Trennung 

der Präsentationsschicht von der Anwendungsschicht. Ursprünglich von Trygve Reenskaug 

für die Smalltalk-Plattform entwickelt [Reenskaug, 1979], hat es auch heute noch 

11 engl.:Design Patterns 

12 Beispiele aus dem Java Development Kit: 

java.util.ListIterator als Umsetzung des Iterator-Musters 

java.awt.image.BufferStrategy als Umsetzung des Strategy-Musters 

23


View 

Model 

Controller 

Abbildung 2.8: MVC Architekturmuster 

Einfluss auf die neuen Plattformen. Im deutschsprachigen Raum ist das Architekturmuster 

auch bekannt geworden als Seeheim-Modell 13 [Pfaff, 1985]. 

Wie der Name MVC andeutet, wird die Trennung in drei Bereichen vollzogen (siehe 

Übersicht in Abbildung 2.8): 

Modell (engl.: Model): Das Modell beschreibt die Inhalte, die dargestellt werden 

sollen. Es ist darstellungsneutral, d. h., die Inhalte sind noch nicht für eine Darstellung 

aufbereitet und könnten auf verschiedene Weisen visualisiert werden. Das 

Modell ist Teil der Anwendungsschicht und kann beispielsweise über die Anwendungsschnittstelle 

angesprochen werden. 

Präsentation (engl.: View): Die Präsentation bereitet die Inhalte des Modells visuell 

auf und erzeugt daraus eine Benutzerschnittstelle, z. B. könnte die Präsentation 

aus dem Modell eine Liste aller Benutzer holen und daraus eine grafisch 

aufbereitete Tabelle erzeugen. Wenn die Inhalte unterschiedlich präsentiert werden 

sollen, kann auch mehr als eine Präsentation für ein Modell erstellt werden. 

Steuerung (engl.: Controller): Während die Präsentation nur für die Ausgabe der 

Modellinhalte verantwortlich ist, nimmt die Steuerung Eingaben vom Benutzer 

entgegen. Diese Eingaben werden an das Modell weitergeleitet, danach wird die 

Präsentation angewiesen, die geänderten Modellinhalte zu präsentieren. 

Fowler [2003] beschreibt zwei wesentliche Vorteile des MVC-Architekturmusters: die 

Trennung der Präsentation vom Modell und die Trennung der Steuerung von der Präsentation. 

Die Trennung der Präsentation vom Modell ist eine notwendige Voraussetzung für 

eine gute Architekturkonzeption und ist aus folgenden Gründen wichtig: 

13 benannt nach dem Workshop User Interface Management Systems 1983 in Seeheim 

24


Präsentationsmodellierung und die Modellierung der Anwendungsschicht decken 

zwei verschiedene Bereiche mit unterschiedlichen Anforderungen ab. Bei der Präsentationsmodellierung 

steht die Interaktion des Benutzers mit der Anwendung 

im Vordergrund, das Ziel ist eine effizient bedienbare Benutzerschnittstelle. Ziel 

der Modellierung der Anwendungsschicht ist, die Anwendungsfälle umzusetzen 

und technische Anforderungen zu beachten, z. B. Transaktionsgrenzen zu definieren. 

Durch eine klare Trennung der beiden Bereiche können sich Entwickler 

spezialisieren. 

Modelle können unterschiedlich visualisiert werden. In derselben Benutzerschnittstelle 

können die gleichen Inhalte unterschiedlich aufbereitet werden, z. B. als Tabelle 

oder als Balkendiagramm. Das Modell kann aber auch unverändert bleiben, 

wenn eine neue Benutzeroberfläche erstellt werden soll, z. B. beim Wechsel von 

einer Desktop-Anwendung auf eine Web-Anwendung. 

Modellobjekte sind einfacher zu testen als Benutzerschnittstellenobjekte. Für Modellobjekte 

lassen sich Tests schreiben, die die technischen und fachlichen Anforderungen 

automatisch überprüfen können. 

Die Trennung wird in der Abbildung 2.8 durch die zwei vertikal angeordneten Kästen 

hervorgehoben. Sowohl die View, als auch der Controller haben Zugriff auf das Model, 

um Daten auszulesen oder zu verändern. Das Modell hat aber keine Beziehung 

zu den anderen Elementen, die Entwickler des Modells können unabhängig von den 

Anforderungen an die Benutzerschnittstelle die Anwendungsschicht entwerfen, Änderungen 

an der Benutzerschnittstelle wirken sich nicht auf die Anwendungsschicht aus. 

Bei einer Änderung der Anwendungsschicht müssen allerdings alle davon abhängigen 

Benutzerschnittstellen aktualisiert werden. 

Die zweite Trennung, die Trennung der Steuerung von der Präsentation, ist im Architekturmuster 

zwar vorgesehen, wird allerdings in den meisten Umsetzungen 14 nicht 

realisiert. Das klassische Beispiel für diese Trennung sind nicht-editierbare und editierbare 

Versionen derselben Komponente, z. B. eine Tabelle, die die Daten nur ausgibt 

oder auch editierbar macht. In diesem Fall könnten, für die gleiche Präsentation, zwei 

Steuerungen modelliert werden, welche das unterschiedliche Verhalten umsetzen. In 

der Praxis wird meistens zu jeder Präsentation nur eine Steuerung erstellt und die beiden 

Teile deshalb verschmolzen. Im nächsten Abschnitt werden wir allerdings zeigen, 

dass gerade im Bereich der Web-Anwendungen eine solche Trennung wieder sinnvoll 

ist. 

2.6.2 Front Controller 

Ein Architekturmuster, welches in der Präsentationsschicht sinnvoll eingesetzt werden 

kann, ist der Front Controller von Fowler [2003]. In den Anfangstagen der Web-Anwendungsentwicklung 

wurde in jeder dynamisch aufgebauten Seite eigene Steuerungslo- 

14 Ironischerweise fehlt die Trennung auch in der Smalltalk-Umsetzung, welches eigentlich der Ursprung dieses 

Architekturmusters ist. 

25


Client 

Front Controller 

Dialogsteuerung 

Seite 



Steuerung 

Präsentation 

Seitensteuerung 



Abbildung 2.9: MVC Architektur für Web-Anwendungen 

gik integriert, also die Präsentation mit der Steuerung verschmolzen. So konnte die Seite 

Eingaben an die Anwendungsschicht weiterleiten und sogar Abläufe wie Schleifen 

oder Bedingungen enthalten, um die Ausgabe zu erzeugen. In einer Web-Anwendung 

müssen allerdings bei einer Seitenanfrage viele Aktionen wiederholt durchgeführt werden, 

z. B. Zugriffsrechte müssen überprüft, Texte müssen internationalisiert oder eine 

Zugriffsstatistik muss geführt werden. Wenn diese Funktionen redundant in jeder Seite 

wiederholt werden, ist das nachträgliche Ändern der Funktionen schwierig. 

Im Gegensatz dazu wird bei diesem Architekturmuster jede Seitenanfrage durch eine 

zentrale Steuerung – den Front Controller – geleitet, die die oben erwähnten Funktionen 

an einer Stelle umsetzt (siehe Abbildung 2.9). Im Anschluss ruft die Steuerung die 

zur angefragten Seite passende Seitensteuerung auf, die die seitenspezifische Verarbeitung 

der Eingabedaten vornimmt. Als letzter Schritt wird die Präsentation in Form 

einer HTML-Seite generiert. Die Präsentation enthält keinerlei Steuerungslogik mehr, 

die vom MVC-Architekturmuster geforderte Trennung von Präsentation und Steuerung 

ist damit gewährleistet. 

Um dieses Architekturmuster umzusetzen, muss dem Front Controller die Zuordnung 

der Seitenanfrage zu den Seitensteuerungen bekannt sein. Die restliche Verarbeitung 

und die Erzeugung der Präsentation werden von den einzelnen Seitensteuerungen verwaltet. 

2.6.3 Dialogsteuerung 

Ein Architekturmuster, welches den Front Controller ergänzt, ist die Dialogsteuerung 

von Fowler [2003] 15 . Im vorigen Abschnitt ist die Steuerung zwar von der Präsentation 

getrennt, allerdings leitet die Seitensteuerung am Ende der Eingabeverarbeitung den 

15 Dort unter dem allgemeinen Namen Application Controller vorgestellt, wir werden die Ausprägung in Form 

einer Dialogsteuerung verwenden. 

26 


Datenschicht

Client 



Seite 



Steuerung 

Präsentation 

Seitensteuerung 





Abbildung 2.10: MVC Architektur mit Dialogsteuerung für Web-Anwendungen 

Kontrollfluss an die Präsentation weiter, muss diese also kennen. Damit sind die möglichen 

Dialogschritte der Web-Anwendung in den Seitensteuerungen statisch abgelegt 

und mit der Eingabeverarbeitung vermischt. Die Dialogstruktur der Web-Anwendung 

ist in allen Seitensteuerungen verteilt. 

Die Dialogsteuerung sieht hingegen eine zentrale Verwaltung der Dialogstruktur vor. 

Dazu wird das Architekturmuster aus dem letzten Abschnitt um einen zusätzlichen Verarbeitungsschritt 

erweitert. Nachdem die Seitensteuerung die Eingabeverarbeitung abgeschlossen 

hat, gibt sie den Programmfluss an die zentrale Dialogsteuerung weiter, 

damit die, basierend auf einem Dialogmodell, die folgende Präsentation bestimmt (siehe 

Abbildung 2.10). 

Um dieses Architekturmuster umzusetzen, muss die Seitensteuerung die zentrale Dialogsteuerung 

aufrufen, damit diese den Folgezustand im Dialog bestimmt. Auf die Definition 

des Dialogs werden wir später noch eingehen, üblicherweise wird dieser als 

endlicher Automat modelliert. 

2.6.4 Komponentenbasierte Präsentation 

Eine weitere Ergänzung der oben genannten Architekturmuster ist die komponentenbasierte 

Präsentation [Heineman und Councill, 2001]. Bis jetzt wurden die Steuerung 

und die Präsentation seitenbasiert erstellt, d. h., jede Anfrage ist einer Seite zugeordnet 

und zu dieser Seite müssen eine Seitensteuerung und eine Präsentation existieren. 

Wir haben zwar schon Querschnittsfunktionalität in den Front Controller ausgelagert, 

trotzdem kann z. B. die Anforderung bestehen, in zwei verschiedenen Seiten die gleiche 


Datenschicht 

27


Client 



Komponentenbaum 

1 

2 

Komponente 1 

1 

2 

1 


Steuerung 

Präsentation 

Anwendungszugriff 



Komponente 2 

Abbildung 2.11: Komponentenbasierte Präsentationsarchitektur 

Tabelle darzustellen. Bis jetzt müsste die Steuerungslogik dieser Tabelle in die verschiedenen 

Seitensteuerungen redundant eingefügt werden. Die Seite ist für die Steuerung 

und die Präsentation die kleinste Einheit. 

Die komponentenbasierte Präsentation sieht eine feinere Zerlegung der Präsentationsschicht 

vor. Die Seite wird nicht mehr atomar betrachtet, sondern in Interaktionskomponenten 

zerlegt, die hierarchisch angeordnet werden (siehe Abbildung 2.11). Interaktionskomponenten 

(z. B. Knöpfe, Listen, Tabellen, Textausgaben oder Eingabefelder) 

werden zentral vorgegeben und können vom Modellierer zu einer Seite zusammengesetzt 

werden, die Hierarchie bestimmt die Anordnung der Komponenten auf 

der Seite. Anstelle einer Seitensteuerung definiert der Modellierer Komponentensteuerungen, 

die die Eingabeverarbeitung einzelner Komponenten durchführt. Redundanz 

wird verhindert, weil die Komponentensteuerung auch in anderen Hierarchien wiederverwendet 

werden kann. 

Auch die Präsentation wird komponentenbasiert durchgeführt. Für jede Komponente 

existiert eine eigene Präsentation, die Seite wird erzeugt, indem die Struktur des 

Komponentenbaums mit der Präsentation der Komponenten gefüllt wird. 

28 

Die Verarbeitung einer Seitenanfrage besteht aus folgenden Schritten: 


Datenschicht

2.7 Zusammenfassung 

1. Komponentenbaum aufbauen: Der Front Controller nimmt die Seitenanfrage entgegen 

und muss diese einem vom Modellierer definierten Komponentenbaum zuordnen. 

2. Komponentensteuerungen aufrufen: Die Eingaben, die der Front Controller zusammen 

mit der Seitenanfrage erhalten hat, müssen den einzelnen Komponenten 

zugeordnet werden. Jede Komponentensteuerung bekommt nur die für die 

Komponente relevante Teilmenge der Eingaben zur Verarbeitung überreicht. 

3. Dialogsteuerung aufrufen: Im Anschluss an die Eingabeverarbeitung wird die Dialogsteuerung 

aufgefordert, den Folgezustand zu bestimmen. Basierend auf der 

Zustandsänderung wird ein neuer Komponentenbaum bestimmt. 

4. Komponentenbaum darstellen: Die Ausgabe wird erstellt, indem die Präsentationen 

der Komponenten des neuen Baums auf einer Seite angeordnet werden. 

Das MVC-Architekturmuster macht keinerlei Aussage über die Granularität der Präsentation, 

der Steuerung oder des Modells. Sowohl der seitenbasierte als auch der komponentenbasierte 

Ansatz genügen dem Anspruch an die Trennung von Modell und 

Präsentation. Der Vorteil der komponentenbasierten Präsentation ist die Vermeidung 

von Redundanz bei der Beschreibung von Benutzerschnittstellen. Die Entwicklung von 

Oberflächen für Web-Anwendungen nähert sich damit der Entwicklung von Oberflächen 

für Desktop-Anwendungen an 16 . 


Die Trennung der Präsentation, der Dialogstruktur und der Steuerungslogik ist ein Ziel, 

das wir in dieser Arbeit verfolgen werden. Mithilfe des MVC-Architekturmusters und 

den Erweiterungen in Form des Front Controllers, der Dialogsteuerung und der komponentenbasierten 

Präsentation können wir die diese Trennung innerhalb der Drei- 

Schichten-Architektur umsetzen. 


In diesem Kapitel haben wir die Anforderungen an eine Softwarearchitektur für Web- 

Anwendungen erörtert. Dabei haben wir einen Blick auf die geschichtliche Entstehung 

16 Folgende Plattformen unterstützen die komponentenbasierte Erstellung von Web-Oberflächen: 

Sun JavaServer Faces [McClanahan u. a., 2004] 

Apache Tapestry [Ship, 2004] 

Apache Wicket [Dashorst und Hillenius, 2008] 

Microsoft ASP.NET [Liberty und Hurwitz, 2005] 

Apple WebObjects [Hill und Mallais, 2004] 

29


der Schichtenarchitekturen geworfen und den aktuellen kanonischen Stand beschrieben. 

Die Verwendung von Architekturmustern als orthogonale Ergänzung zur Schichtenarchitektur 

hilft bei der Modellierung von Detailaspekten, in unserem Beispiel in 

der Präsentationsschicht. Wie gezeigt, lassen sich Architekturmuster auch untereinander 

kombinieren. 

Architekturkonzepte können allerdings niemals endgültig oder vollständig sein, sie 

unterliegen einer fortwährenden Umgestaltung durch die Weiterentwicklung der Softwaresysteme: 

Softwarearchitekturen sind empirische Konstrukte. Dieses Kapitel definiert 

deshalb die Architekturbegriffe, auf die wir im Laufe dieser Arbeit aufbauen und 

verweisen werden. 

Aufgrund der empirischen Entstehung beschreibt Booch [2005] Architekturen nicht 

als Definition, sondern in Form von Erfahrungen, welche wir zum Abschluss dieses Kapitels 

zusammenfassend wiedergeben wollen: 

Wir wissen, dass wir wissen 

Wir wissen, was Architekturen ausmacht und was nicht dazugehört. 

Jedes Softwaresystem besitzt eine (eventuell implizite) Architektur. 

Strukturierte Softwaresysteme benutzen (eventuell implizite) Architekturmuster. 

Wir glauben, dass wir wissen 

Softwarearchitektur sollte explizit eingesetzt werden. 

Architekturmuster sollten explizit eingesetzt werden. 

Wir wissen, dass wir nicht wissen 

Wir haben keine beständigen Architekturkonzepte. Für alle bestehenden 

Probleme wurden im Laufe der Jahre immer wieder bessere Architekturkonzepte 

gefunden, die das Vorhergehende nicht nur erweitern, 

sondern oft auch ersetzen. 

Wir haben keine objektiven Kriterien, um die Qualität von Architekturkonzepten 

zu überprüfen. Wir verlassen uns auf die Empirie. 

Damit fasst Booch zusammen, dass die Methoden zur Definition einer Softwarearchitektur 

noch weithin unbekannt sind und wir, bis auf die Empirie, nur wenig qualitatives 

Wissen besitzen. Trotzdem sind Architekturen unverzichtbar, denn sie geben die Struktur 

des Softwaresystems vor, Fehler durch unstrukturierte oder redundante Umsetzungen 

werden so verhindert. 

Im nächsten Kapitel werden wir zeigen, wie der Entwicklungsprozess zur Modellierung 

der Bausteine einer Architektur für Web-Anwendungen aussieht. 

30

Kapitel 3 

Modellbasierte Entwicklung 

Inhalt 

3.1 Modelle im Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . 31 

3.2 Modellbasierte Entwicklung von Web-Anwendungen . . . . . . . . . . 35 

3.3 Domänenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

3.4 Aufgabenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

3.5 Dialogmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

3.6 Präsentationsmodellierung . . . . . . . . . . . . . . . . . . . . . . . . . 59 


In der Einleitung und in der Architekturübersicht haben wir bereits angedeutet, dass 

Softwaresysteme selten von einem Programmierer „auf der grünen Wiese“ entwickelt 

werden, sondern von einem Team erstellt und in ein bestehendes Umfeld integriert 

werden müssen. Der Entwicklungsprozess muss deshalb in getrennt bearbeitbare Entwicklungsschritte 

(seperations of concerns) zerlegt werden, die zusammen das Softwaresystem 

ergeben. Die modellbasierte Entwicklung bietet sich als Umsetzung dieses 

Konzeptes an; Modelle beschreiben jeweils einen Aspekt des Softwaresystems im Detail, 

während die anderen Aspekte ausgeblendet werden. Erst die Kombination aller 

Modelle ergibt das Gesamtsystem. 

Während die modellbasierte Entwicklung in der initialen Phase der Softwareentwicklung 

mit Mehrarbeit verbunden ist, verringert sie den Aufwand für die Wartung, Weiterentwicklung 

und Wiederverwendung des Softwaresystems. Änderungen können von 

Fachexperten an einem Modell durchgeführt werden, die anderen Modelle bleiben im 

besten Fall unbeeinflusst. 

In diesem Kapitel werden wir die bestehenden Modelle für die Entwicklung von Web- 

Anwendungen vorstellen und uns dabei vor allem auf die Modellierung der Präsentationsschicht 

auf Basis von Aufgabenmodellen konzentrieren. 

3.1 Modelle im Entwicklungsprozess 

Bevor wir uns konkreten Modellen für die Erstellung von Web-Anwendungen zuwenden, 

wollen wir zuerst den Modellbegriff definieren. 

31

3 Modellbasierte Entwicklung 

3.1.1 Modelldefinition 

In der allgemeinsten Bedeutung ist ein Modell eine Abstraktion von der Realität, mit 

der Konzentration auf einige zu betrachtende Aspekte, während andere Aspekte vernachlässigt 

werden. Es kann mehrere Modelle des gleichen realen Objektes oder Sachverhaltes 

geben, zum Beispiel: 

Realität Modell 

Reale Eisenbahn Konstruktionszeichnung 

Reale Eisenbahn Modelleisenbahn 

Stadt Stadtplan 

Stadt Buslinienplan 

Modelle können nicht nur parallel existieren, sondern auch zur Reduzierung eines komplexen 

Sachverhalts aufeinander aufbauen. So kann z. B. ein Modell Hausansicht auf 

einem Modell Grundriss basieren, wenn sich der Grundriss ändert, so muss auch die 

Hausansicht aktualisiert werden. Modelle bieten sich deshalb an, um eine Architekturkonzeption, 

wie in Abschnitt 2.2 beschrieben, umzusetzen. 

Im Softwareentwicklungsprozess soll ein existierendes (oder nur in Form von Anforderungen 

bestehendes) Konzept als Anwendung umgesetzt werden. Deshalb besteht 

die Modellierung aus zwei Schritten: 

Abstraktion Die Realität muss in ein für die Softwareentwicklung relevantes abstraktes 

Modell umgeformt werden. 

Konkretisierung Das abstrakte Modell wird (eventuell über mehrere Zwischenmodelle) 

in eine konkrete Anwendung umgeformt. 

Selbst wenn bei der Entwicklung keine expliziten Modelle verwendet werden, so müssen 

diese Schritte doch implizit vom Entwickler im Kopf durchgeführt werden. Wir betrachten 

im Folgenden die explizite und formale Erstellung von Modellen im Softwareentwicklungsprozess. 

3.1.2 Metamodelle 

Um Modelle definieren zu können, ist ein Metamodell hilfreich. Ein Metamodell ist 

ein Modell, das beschreibt, wie Modelle definiert werden. Um z. B. die Konstruktionszeichnung 

einer Eisenbahn anzufertigen, ist es sinnvoll, zu beschreiben, aus welchen 

Elementen die Zeichnung bestehen darf. Dazu müssen sowohl die Syntax als auch die 

Semantik der Elemente in einem Metamodell definiert werden: 

32 

Die Syntax beschreibt, wie die Elemente im Modell dargestellt werden. Dies kann 

eine textuelle Syntax sein, oder aber eine grafische, z. B. Darstellungen von Rädern 

und Achsen in einer Konstruktionszeichnung. Die Syntax gibt auch an, wie die Elemente 

kombiniert werden können, zum Beispiel, dass ein Rad mehrere Speichen 

enthält aber eine Speiche nicht mehrere Räder. Mithilfe der Syntax kann ein Programm 

das Modell auf Korrektheit überprüfen.

3.1 Modelle im Entwicklungsprozess 

Die Semantik beschreibt die Bedeutung der Modellelemente. Modelle sollen nicht 

nur vom Computer interpretiert, sondern auch vom Modellierer erstellt werden. 

Dazu muss diesem die Bedeutung der Elemente klar sein, es muss eindeutig definiert 

sein, dass die (eventuell abstrakte) Syntax eines Elements z. B. einer Achse 

entspricht. 

Wir könnten beispielsweise die Regeln der deutschen Grammatik als Metamodell für 

in deutsch verfasste Texte verwenden und eine Prüfung auf Korrektheit (Fehlersuche) 

durchführen. Aufgrund der vielen Ausnahmen und Sonderfälle in der deutschen Grammatik 

werden wir dies hier nicht weiter fortführen, aber in der Softwareentwicklung ist 

es sinnvoll, die Elemente der Modelle mit Metamodellen zu beschreiben. Natürlich kann 

auch zu einem Metamodell ein Meta-Metamodell erstellt werden, um das Metamodell 

zu definieren. Die Meta Object Facility (MOF, siehe [OMG, 2006]) bietet eine solche Abstraktion 

für UML Modelle 17 . Nicht für jedes Modell muss ein Metamodell definiert sein, 

im nächsten Abschnitt werden wir zeigen, dass die Definition eines Metamodells für die 

Weiterverarbeitung des Modells aber sinnvoll ist. 

3.1.3 Modellbasierte und modellgetriebene Entwicklung 

Wenn Modelle explizit im Entwicklungsprozess verwendet werden, dann wird klassischerweise 

von der modellbasierten Entwicklung oder der modellgetriebenen Entwicklung 

gesprochen. Diese beiden Begriffe sind dabei nicht synonym zu verwenden, sie 

unterscheiden sich vor allem darin, wie die Modelle weiterverwendet werden. 

Bei der modellbasierten Entwicklung wird die Anwendung basierend auf den Modellen 

entwickelt. Die Modelle müssen nicht unbedingt einem Metamodell folgen, z. B. 

kann eine handgemalte Skizze einer Webseite als Modell für die Umsetzung verwendet 

werden. Der Entwickler ist dafür zuständig, die Vorgaben des Modells einzuhalten. 

Eine spätere Änderung des Modells bedeutet demnach auch ein manuelle Anpassung 

der Anwendung; der Entwickler muss die Änderungen im Modell von Hand auf die 

Anwendung übertragen. 

Bei der modellgetriebenen Entwicklung (Model Driven Software Development, siehe 

[Stahl u. a., 2007]) wird die Anwendung basierend auf den Modellen von einem Programm 

generiert. Dazu werden die Modelle entweder in Zwischenschritten zu konkreteren 

Modellen (Modell-zu-Modell-Transformation) oder im letzten Schritt in ein Programmgerüst 

(Modell-zu-Code-Transformation) transformiert. Der Entwickler kann das 

Programmgerüst dann zu einer endgültigen Version der Anwendung erweitern. Trotzdem 

bleibt der Generator in der Lage, ein verändertes Modell in ein Codegerüst zu 

17 Zum Beispiel definiert MOF folgende Modellebenen: 

Instanz (M0) Modell (M1) Metamodell (M2) Meta-Metamodell (M3) 

Radreifen 312 Rad UML Klasse MOF::Class 

32 cm Durchmesser UML Attribut MOF::Class 

Die erste Zeile beschreibt den Radreifen 312 einer Instanz der Klasse Rad welche eine Instanz einer UML Klasse 

welche Instanz einer MOF::Class ist. In der zweiten Zeile ist ein Attribut beschrieben: 32 cm ist die Instanz 

eines Durchmessers, welches ein UML Attribut welches ebenfalls Instanz einer MOF::Class ist. Mittels einer 

MOF::Association könnte der Durchmesser als Attribut der Klasse Rad definiert werden. 

33


transformieren, ohne die manuellen Erweiterungen zu überschreiben 18 . Die Generierung 

eines Programmgerüsts geschieht über Transformationsregeln, die einmalig definiert 

werden müssen. Um die Transformationsregeln anwenden zu können, muss der 

Generator das Modell interpretieren können, dieses muss deshalb zwingend einem Metamodell 

folgen. Bei der modellgetriebenen Entwicklung kann das Modell als Grundlage 

für eine Umsetzung auf verschiedenen Plattformen und unterschiedlichen Programmiersprachen 

verwendet werden, solange die passenden Transformationsregeln existieren. 

Wenn die Modelle bereits alle notwendigen Informationen für die Erzeugung der 

Anwendung enthalten, dann kann die Generierung auch automatisch zur Laufzeit erfolgen. 

In diesem Fall enthält das Laufzeitsystem alle Transformationsregeln und benötigt 

das Modell der Anwendung als Eingabe in einem über die Syntax definierten 

Format. Wir werden später den Weg der modellgetriebenen Entwicklung verfolgen, indem 

wir für unsere Modelle passende Metamodelle und eine Laufzeitarchitektur mit 

Transformationsregeln definieren. 


Wie wir diskutiert haben, bringt die Einführung von Modellen im Entwicklungsprozess 

folgende Vorteile: 

Geringere Umsetzungsdauer bei Designänderungen oder neuen Vorgaben. 

Gleichzeitige Erstellung von Anwendungen für unterschiedliche Plattformen und 

Programmiersprachen. 

Die Transformationsregeln bestimmen die Qualität des Quellcodes, die Einhaltung 

der Architekturkonzepte kann ebenfalls in den Regeln definiert werden. 

Bessere Integration von Fachexperten durch eine Trennung von fachlichen und 

technischen Aspekten. 

Einfacher Übergang zu einer neuen Technologie durch das Ändern der Transformationsregeln. 

Teilweise oder vollständige Generierung der Anwendung aus den Modellen. 

Dem stehen allerdings folgende Nachteile gegenüber: 

Erhöhter einmaliger Aufwand für die Entwicklung der Transformationsregeln. 

Für den Entwickler zusätzlicher Einarbeitungsaufwand in die Modellierungssprache 

und das Modellierungswerkzeug. 

18 Z. B. mit folgenden Verfahren: 

protected-regions innerhalb einer Klasse, die vom Entwickler gefüllt werden, und die der Generator nicht 

überschreibt. 

subclassing, bei der der Generator abstrakte Oberklassen generiert, von denen der Entwickler Unterklassen 

ableitet und implementiert. 

34

3.2 Modellbasierte Entwicklung von Web-Anwendungen 

Abhängigkeit vom Modellierungswerkzeug. Selbst bei UML-Werkzeugen mit XMI- 

Unterstützung (XML Metadata Interchange) ist die Interoperabilität mit anderen 

Werkzeugen nicht gewährleistet. 

Schwieriger Kompromiss zwischen zu großem Ausdrucksumfang (Modelle werden 

komplex) und zu kleinem Ausdrucksumfang (fehlende Flexibilität, Entwickler fühlen 

sich eingeschränkt) der Modelle. 

Als Fazit bleibt festzuhalten, dass eine modellbasierte oder modellgetriebene Entwicklung 

dann sinnvoll ist, wenn die Anwendung über verschiedene, miteinander verknüpfte 

Modelle beschrieben wird. Die Modelle sollten jeweils einen genau umrissenen Bereich 

der Anwendung beschreiben und die anderen Bereiche ausblenden. Die Identifikation 

dieser Bereiche wird das Ziel der nächsten Abschnitte sein. 

3.2 Modellbasierte Entwicklung von Web-Anwendungen 

Wir wollen mit unserem Ansatz den gesamten Entwicklungsprozess von Web-Anwendungen 

unterstützen. Zu diesem Zweck betrachten wir die existierenden systemzentrierten 

und benutzerzentrierten Ansätze und analysieren Gemeinsamkeiten, fehlende 

Konzepte und Möglichkeiten der Integration. 

Der systemzentrierte Ansatz basiert auf der Idee, eine Anwendung über die Abläufe 

und Strukturen innerhalb eines Softwaresystems zu beschreiben. Zu diesem Zweck hat 

die Object Management Group in den 90er Jahren die UML zusammengestellt [OMG, 

2005], eine Sprache für die Modellierung von Software, basierend auf Erkenntnissen 

und Erfahrungen aus Softwareprojekten der vorangegangenen Jahrzehnte. Die Sprache 

definiert in den Bereichen der Struktur- und Verhaltensmodellierung eine Vielzahl 

von Diagrammarten mit standardisierter Notation. Mithilfe dieser (und anderer, weniger 

relevanter) Sprachen werden im Bereich des Web Engineerings (WE) (ein Abkömmling 

des Software Engineerings für Web-Anwendungen) die Softwaresysteme beschrieben. 

Der benutzerzentrierte Ansatz hat seinen Ursprung im Bereich der Human Computer 

Interaction (HCI) und basiert auf der Idee, über die Wünsche, Ziele und Aufgaben eines 

Benutzers zu einer Benutzerschnittstelle zu gelangen. Basierend auf dem Entwurf der 

Benutzerschnittstelle wird der Rest der Anwendung umgesetzt. In Abbildung 3.1 haben 

wir die wichtigsten Modelle des systemzentrierten (links) und des benutzerzentrierten 

Ansatzes (rechts) aufgeführt. 

Der Entwicklungsprozess wird in drei Phasen zerlegt, wir beschreiben die Modellierung 

der Anwendungsschicht (im Folgenden Domänenmodellierung genannt) auf der 

linken und die Modellierung der Benutzerschnittstelle auf der rechten Seite der Abbildung. 

In der Analysephase werden die Anforderungen an die Anwendung formalisiert. Dazu 

wird in der Regel ein Glossar angelegt, in dem die verwendeten Begriffe definiert, 

sowie die Konzepte textuell beschrieben werden. Das Aufgabenmodell als Vorstufe des 

Benutzerschnittstellenentwurfs hat für unseren Ansatz zentrale Bedeutung, wir werden 

35


Analyse 

Konzepte/Glossar 

Task 

Anwendungsfälle Controller 

Aufgabenmodell 

Entwurf 

Klassendiagramm 

Task 

Sequenzdiagramm 

Controller 

Aktivitätsdiagramm 

Implementierung 

Klassen Benutzerschnittstelle 

Datenbankschema 

Dialogmodell 

Präsentationsmodell 

Abbildung 3.1: Phasen der modellbasierten Entwicklung 

im Abschnitt 3.4 auf die bestehenden Modelle eingehen. Die Anwendungsfälle dienen 

der groben Beschreibung der zu entwerfenden Anwendung. 

In der Entwurfsphase wird die Anwendung modelliert. Das Klassendiagramm, Sequenzdiagramm 

und Aktivitätsdiagramm sind Teil der UML-Domänenmodellierung, die 

wir in Abschnitt 3.3 aufgreifen werden. Das Dialogmodell und Präsentationsmodell werden 

aus dem Aufgabenmodell abgeleitet, wir werden sie in den Abschnitten 3.5 und 3.6 

behandeln. 

In der Implementierungsphase wird die Anwendung für eine Plattform umgesetzt, 

d. h., Klassen werden in einer Programmiersprache verfasst, ein Datenbankschema wird 

für eine Datenbank erstellt und die Benutzerschnittstelle wird mit einer geeigneten Beschreibungssprache 

umgesetzt. Bei einem modellgetriebenen Ansatz können die Elemente 

dieser Phase aus den Modellen der Entwurfsphase generiert werden. 

3.3 Domänenmodellierung 

Die UML ist eine bewährte Modellierungssprache, um ein Domänenmodell zu erzeugen, 

welches als Abstraktion einer Fachdomäne dient. Ziel des Domänenmodells ist die 

Umsetzung der fachlichen Aspekte in eine implementierbare Anwendung. Der Fokus 

36

3.4 Aufgabenmodellierung 

liegt auf der Modellierung der Anwendungsschicht und der Datenschicht in einer Drei- 

Schichten-Architektur (siehe Abschnitt 2.3.3). 

Die UML bietet zur Domänenmodellierung eine Reihe von Diagrammarten, von denen 

wir einige im linken Teil der Abbildung 3.1 aufgeführt haben. Details finden sich 

dazu in [OMG, 2005], wir geben in dieser Arbeit nur einen Überblick über die Diagramme, 

unterteilt werden sie in Strukturdiagramme (Auszug): 

Klassendiagramm: Eine Darstellung der Klassen und deren Beziehungen untereinander. 

Objektdiagramm: Beispielhafte Ausprägungen der Klassen des Klassendiagramms 

als Objekte. 

Komponentendiagramm: Eine Darstellung der zu Komponenten zusammengefassten 

Klassen und deren Abhängigkeiten untereinander. 

und in Verhaltensdiagramme (Auszug): 

Sequenzdiagramm: Beschreibt den Austausch von Nachrichten zwischen Objekten 

mittels Lebenslinien. 

Aktivitätsdiagramm: Stellt die Vernetzung von Aktionen und deren Verbindungen 

mit Kontroll- und Datenflüssen grafisch dar. 

Anwendungsfalldiagramm: Stellt Anwendungsfälle und Akteure mit ihren Beziehungen 

und Abhängigkeiten dar. 

Die Diagramme können als Sichten auf ein zentrales Domänenmodell aufgefasst werden, 

wenn sich z. B. der Klassenname in einem Klassendiagramm ändert, sollte sich auch 

derselbe Name in einem Sequenzdiagramm ändern. 

Bei der Verwendung der UML gibt es nur eine rudimentäre Unterstützung für die 

Beschreibung des Dialogs zwischen Benutzer und Computersystem (in Form von Aktivitätsdiagrammen). 

Die Benutzerschnittstelle wird erst spät im Entwicklungsprozess 

definiert, sie folgt damit eher den Strukturen des Klassenmodells als den Erwartungen 

eines Benutzers, was eine schlechte Usability nach sich ziehen kann. Die Modellierungssicht 

ist datenzentriert, wünschenswert wäre ein stärkerer Fokus auf den Dialog und 

die Interaktionen. 

Wir werden deshalb für die Domänenmodellierung die Diagramme der UML verwenden, 

aber für die Modellierung der Präsentationsschicht Ansätze aus dem Bereich der 

Human Computer Interaction verwenden, welche im rechten Teil der Abbildung 3.1 

aufgeführt sind und in den nächsten Abschnitten behandelt werden. 


3.4.1 Einleitung 

Das Aufgabenmodell steht im Zentrum der modellbasierten Entwicklung von Benutzerschnittstellen. 

Aufgabenmodellierung wird bereits seit Ende der 60er Jahre betrieben, 

37


allerdings hat sich – im Gegensatz zur UML – keine einheitliche Sprache oder Notation 

durchgesetzt. In den nächsten Abschnitten werden wir deshalb erst eine allgemeine Definition 

der Aufgabenmodellierung geben, um danach die für diese Arbeit relevanten 

Methoden der Aufgabenmodellierung zusammenzufassen. 

3.4.2 Methoden der Aufgabenmodellierung 

Im Bereich der Human Computer Interaction steht der Benutzer und seine Interaktion 

mit einem Computersystem im Vordergrund. Die Aufgabenanalyse hat sich als fundamentale 

Methode zur Ermittlung und Beschreibung der Benutzerinteraktion durchgesetzt. 

Ergebnis der Aufgabenanalyse ist in den meisten Fällen ein Aufgabenmodell, in 

dem die Interaktionsaufgaben eines Benutzers mit einem Computersystem beschrieben 

werden. Diese Interaktionsaufgaben müssen später von einer Benutzerschnittstelle realisiert 

werden, damit die Anwendung den Anforderungen der Analysephase erfüllt. 

Die Aufgabenanalyse ist, laut Dix u. a. [1993],. . . 

. . . the process of analyzing the way people perform their jobs: the things 

they do, the things they act on and things they need to know. 

Eine Aufgabe in ihrer allgemeinsten Form ist eine Aktion, die der Benutzer auf der 

Anwendung auslösen kann. Im Verlauf der Aufgabenanalyse wird die Menge aller Aufgaben 

identifiziert und die Abhängigkeiten von Aufgaben untereinander definiert. 

Als Ergebnis der Aufgabenanalyse entsteht eine Beschreibung der zu erfüllenden 

Aufgabe in einer von der Aufgabenanalyse abhängigen Notation. Das Identifizieren 

der Aufgaben kann auf verschiedene Weisen geschehen [Paternò, 1999]: 

Kognitionspsychologie: Analysiert die Art und Weise, wie ein Benutzer mit einer 

Benutzerschnittstelle interagiert, um eine Aufgabe zu erfüllen. Dabei werden die 

kognitiven Prozesse und Strukturen des Benutzers analysiert, indem deren Veränderung 

im Verlauf einer Aufgabenbearbeitung betrachtet wird. Ziel ist, die Aufgaben 

so zu definieren, dass die kognitive Last möglichst gering ist. 

Aufgabenzuordnung: Die Aufgaben werden für den Benutzer fest vorgegeben, 

z. B. durch die Geschäftsführung in einer Organisation. 

Software Engineering: Die Aufgaben werden anhand der Anforderungen des Domänenmodells 

identifiziert, also systemzentriert bestimmt. 

Ethnografie: Eine Methode der Soziologie, die die Erwartungshaltung einer Gruppe 

von Benutzern analysiert, um daraus erwartungskonforme Aufgaben zu definieren. 

Abbildung 3.2 (basierend auf einer Abbildung aus van Welie [2001]) zeigt eine Zeitlinie 

mit den für unsere Arbeit relevanten Methoden. Die Hierarchical Task Analysis (HTA) 

von Annett und Duncan [1967], die Methode Goals, Operators, Methods, and Selection 

rules (GOMS) von Card u. a. [1983], die Task Knowledge Structures (TKS) von Johnson 

u. a. [1988], das Model for Activity Description (MAD) von Scapin und Pierret-Goldbreich 

38

HTA goms Tks mAd uAn cTT 

1970 1975 1980 1985 1990 1995 2000 

Abbildung 3.2: Zeitlinie der Aufgabenmodelle [van Welie, 2001] 


2005 

[1989], die User Action Notation (UAN) von Hix und Hartson [1993] und die Concurrent 

Task Trees (CTT) von Paternò u. a. [1997]. In den nächsten Abschnitten werden wir die 

verschiedenen Methoden genauer vorstellen. 

Hierarchical Task Analysis (HTA) 

Mittels der hierarchischen Aufgabenzerlegung wird eine Aufgabe in eine Hierarchie 

von Teilaufgaben aufgeteilt und es wird eine Ordnung definiert, in der die Teilaufgaben 

auszuführen sind. Diese Vorgehensweise, die die Basis von vielen nachfolgenden 

Methoden ist, wurde erstmals von Annett und Duncan [1967] unter dem Namen Hierarchical 

Task Analysis vorgestellt. Damals gab es noch keine Verbindung zum HCI-Bereich 

(diese wurde erst von Shepherd [1989] hergestellt), sondern die Methode wurde zur 

Beschreibung von allgemeinen Aufgaben und Abläufen verwendet. Ein typisches Aufgabenmodell 

im Stile von HTA zeigt das folgende Beispiel (basierend auf dem HTA- 

Beispiel aus Dix u. a. [1993]): 

Listing 3.1: HTA Beispiel – Hausputz Hierarchie 

1. Hausputz durchführen 

1.1. Hole Staubsauger 

1.2. Säubere die Räume 

1.2.1. Säubere die Diele 

1.2.2. Säubere das Wohnzimmer 

1.2.3. Säubere das Schlafzimmer 

1.3. Leere den Staubsaugerbeutel 

1.4. Verstaue Staubsauger 

Das Beispiel zeigt die Hierarchie der Aufgaben, um ein Haus zu putzen. Die Oberaufgabe 

Hausputz durchführen wird in vier Unteraufgaben unterteilt, erkenntlich durch die 

Einrückung und der Nummerierung (1.1. bis 1.4.). Die Aufgabe 1.2. Säubere die Räume 

wird erneut in drei Unteraufgaben (1.2.1. bis 1.2.3.) unterteilt. Für die hierarchische 

Unterteilung muss noch eine Ordnung definiert werden, dies geschieht bei HTA durch 

sogenannte Pläne: 

Listing 3.2: HTA Beispiel – Hausputz Pläne 

Plan 1.: Führe 1.1. - 1.2. - 1.4. in dieser Reihenfolge aus. 

Wenn Staubsaugerbeutel voll, führe 1.3. aus. 

Plan 1.2.: Führe 1.2.1 - 1.2.2. - 1.2.3. beliebig aus. 

39


Die Pläne sind mit der Nummer der Aufgabe versehen, für die sie ein Bearbeitungsplan 

definieren. So beschreibt der Plan 1. den Ablauf der Unteraufgaben von Hausputz 

durchführen. Wie wir sehen, müssen nicht alle Unteraufgaben ausgeführt werden, der 

Ablaufplan lässt die Freiheit, wann und ob der Staubsaugerbeutel geleert wird, entweder 

beim Holen, beim Säubern, beim Verstauen oder gar nicht. Wenn der Staubsaugerbeutel 

nur während des Säuberns der Räume geleert werden soll, dann könnte die 

Aufgabe in der Hierarchie verschoben werden, aus der Aufgabe 1.3. würde dann z. B. 

1.2.4. werden. 

Plan 1.2. beschreibt die Reihenfolge, in der die Unteraufgaben der Aufgabe Säubere 

die Räume ausgeführt werden sollen. Im Beispiel dürfen die Aufgaben in einer beliebigen 

Reihenfolge ausgeführt werden. Der Plan lässt allerdings keine Wahlfreiheit, ob 

die Aufgaben ausgeführt werden, die Räume müssen immer alle gesäubert werden. 

Wenn man bedenkt, dass nicht alle Räume gleich schnell verschmutzen, so sollte der 

Plan angepasst werden, z. B. folgendermaßen: 

Listing 3.3: HTA Beispiel – Hausputz Pläne (erweitert) 

Plan 1.2.: Führe 1.2.1 - 1.2.2. - 1.2.3. beliebig aus. 

Führe 1.2.1. täglich aus. 

Führe 1.2.2. wöchentlich aus. 

Wenn Gäste kommen, führe 1.2.3. aus. 

Der Plan beschreibt, dass die Unteraufgaben nur noch an definierten Zeitpunkten ausgeführt 

werden müssen. Wenn mehrere Aufgaben zum gleichen Zeitpunkt anstehen, 

können sie in einer beliebigen Reihenfolge ausgeführt werden. 

Eine umgangssprachliche Definition der Pläne ist für die Erstellung von Aufgabenmodellen 

nicht sinnvoll, weil diese zu allgemein und damit für Mensch und Computer nur 

schwer zu interpretieren ist. Deshalb werden in HTA Kategorien definiert, aus denen 

die Elemente der Pläne stammen dürfen. Andere Methoden werden diese Kategorien 

später in Form von temporalen Operationen aufgreifen: 

40 

Sequenzielle Reihenfolge: Unteraufgaben sind in einer festgelegten Reihenfolge 

nacheinander auszuführen. 

Beliebige Reihenfolge: Unteraufgaben sind in einer beliebigen Reihenfolge nacheinander 

auszuführen. 

Nebenläufigkeit: Unteraufgaben können unabhängig voneinander parallel ausgeführt 

werden. 

Optionale Aufgabe: Unteraufgaben können vom Benutzer übersprungen werden, 

damit lassen sich wenn-dann Beziehungen ausdrücken. 

Warten auf Ereignisse: Erst wenn ein Ereignis eintrifft, kann die Aufgabe ausgeführt 

werden, z. B. wöchentliche Aufgabenausführung. 

Zyklen: Unteraufgaben können wiederholt werden, bis eine Bedingung den Zyklus 

abbricht.


Die Hierarchical Task Analysis ist vermutlich die erste Methode zur Aufgabenanalyse 

und hat bis heute einen großen Einfluss auf die anderen Methoden. Die Verwendung 

einer Hierarchie, sowie die Definition von temporalen Relationen, legen den Grundstock 

für die weiteren Arbeiten. 

Goals, Operators, Methods, and Selection rules (GOMS) 

Eine der ersten Methoden zur Modellierung von Aufgaben mittels hierarchischer Zerlegung 

speziell im HCI-Bereich war GOMS (Goals, Operators, Methods, and Selection 

rules), vorgestellt von Card u. a. [1983]. 

In GOMS werden die Aufgaben als Ziele definiert, welche hierarchisch in Unterziele 

aufgeteilt werden können. Methoden beschreiben das Verfahren zum Erreichen eines 

Ziels, sie werden als Folge von Operatoren und Unterziele eines Ziels definiert, welche 

sequenziell ausgeführt werden müssen. Operatoren beschreiben elementare motorische 

oder kognitive Aktionen des Benutzers, sie dienen bei GOMS dazu, die Aktionen 

des Benutzers als Teilschritt zur Erfüllung des Zieles zu modellieren. Methoden können 

auch noch einfache Kontrollanweisungen enthalten, z. B. if für einen Operator, der 

nur bedingt ausgeführt wird oder repeat until für einen Operator, der in einer Schleife 

ausgeführt wird. Die Kontrollanweisungen werden bei GOMS hinter den Operatoren 

platziert. Als letztes Element existieren noch Auswahlregeln, mit deren Hilfe der Benutzer 

einen Operator aus einer Menge von Operatoren selektieren kann. Folgendes 

Beispiel verdeutlicht die Struktur eines GOMS-Aufgabenmodells: 

Listing 3.4: GOMS Beispiel – Übertrage Änderungen aus einem Manuskript 

GOAL: bearbeite Manuskript 

GOAL: bearbeite Änderung(repeat until keine mehr verfügbar) 

GOAL: hole Änderungswunsch 

rufe nächste Seite auf (if am Ende der Manuskriptseite) 

suche nächsten Änderungswunsch 

GOAL: führe Änderungswunsch durch 

GOAL: suche Zeile 

[select: benutze Suchfunktion 

benutze Scrollfunktion] 

GOAL: Änderung durchführen 

[select: ersetze den Text 

verändere den Text] 

überprüfe Änderungen 

Die Hierarchie wird durch die Einrückungstiefe der Ziele beschrieben. Das Hauptziel 

bearbeite Manuskript soll von einem Benutzer erfüllt werden, der zu einem elektronischen 

Text ein handschriftlich korrigiertes Manuskript mit Änderungswünschen erhalten 

hat, die er nun in den Text einpflegen soll. Dazu wird das Ziel bearbeite Änderungswunsch 

wiederholt, bis keine mehr verfügbar sind. Dieses Ziel besteht aus den beiden 

Unterzielen hole Änderungswunsch (aus dem Manuskript) und führe Änderungswunsch 

(im elektronischen Text) durch. Das erste Ziel besteht aus den beiden Operatoren rufe 

nächste Seite auf (falls der Benutzer sich gerade am Ende einer Seite befindet) und 

41


suche nächsten Änderungswunsch. Im zweiten Ziel befinden sich noch mehrere Auswahlregeln, 

die dem Nutzer die Wahl lassen, z. B. entweder mit der Suchfunktion oder 

über das Scrollen auf eine Zeile im Text zu gelangen. 

Das Ziel von GOMS ist, die internen kognitiven Prozesse einer Person bei der Ausführung 

einer Aufgabe zu verstehen. Die beschriebenen Operatoren und Ziele sind daher 

auch sehr grobgranular. Für die Aufgabenanalyse eignet sich dieses Modell deshalb nur 

bedingt, denn dort wird das Verhalten des Benutzers von außen betrachtet, es wird das 

analysiert, wie der Benutzer eine Aufgabe ausführt, weniger interessiert, warum er es 

tut [Dix u. a., 1993]. Ein weiterer Kritikpunkt an GOMS bezüglich Aufgabenmodellierung 

ist das Fehlen von Möglichkeiten, nicht-sequenzielle Abläufe, wie z. B. Nebenläufigkeit, 

zu modellieren. 

GOMS-Modelle werden deshalb auch seltener zur Erzeugung von Benutzerschnittstellen, 

sondern häufiger zur Analyse des Verhaltens einer Benutzergruppe auf einer 

bestehenden Anwendung verwendet, z. B. um Aussagen über die Häufigkeit einer Selektionsoption 

zu treffen oder um die durchschnittliche Bearbeitungszeit eines Operators 

zu ermitteln. 

Task Knowledge Structures (TKS) 

Die Task Knowledge Structures von Johnson u. a. [1988] stellen den Prozess der Erstellung 

eines Aufgabenmodells in den Vordergrund. Während die hierarchische Aufgabenzerlegung 

und die temporalen Relationen von TKS sich klar an HTA orientieren, 

wurde für die Analyse der Aufgaben eine umfangreiche Methodik entwickelt, die auch 

rollenspezifische (Wer darf eine Aufgabe ausführen?) und objektspezifische (Welche 

Objekte werden zur Ausführung einer Aufgabe benötigt?) Elemente enthält. 

Für unsere weitere Arbeit interessiert uns weniger die Notation der Aufgabenmodelle 

in TKS, sondern vielmehr der Analyseprozess. Angelehnt an die Zusammenfassung 

von Jonassen u. a. [1999], lässt sich der Prozess der Aufgabenanalyse von TKS folgendermaßen 

beschreiben: 

42 

1. Informationen über die zu bewältigende Aufgabe sammeln 

a) Personen im Kontext der Aufgabe beobachten 

Personen von außen beobachten, wie und mit welchen Hilfsmitteln sie eine 

Aufgabe erfüllen. 

b) Personen befragen 

Eine Befragung der Personen durchführen, um ihre Überlegungen während 

der Erfüllung einer Aufgabe festzuhalten. 

c) eventuell Schritte wiederholen 

2. Identifizierung der Wissensbereiche, die zur Erfüllung einer Aufgabe notwendig 

sind 

a) Identifizierung der hierarchischen Ziele 

Identifizierung der Ziele und Unterziele durch Befragung der Personen, Analyse 

von Handbüchern.


b) Identifizierung von Methoden 

Befragung von Personen zu den Strategien, die sie zur Zielerreichung einsetzen. 

c) Identifizierung von Objekten 

Objekte, die bei der Ausführung der Aufgaben involviert sind, identifizieren 

und mit den Methoden in Verbindung bringen. „Um die Aufgabe Rad 

wechseln zu erfüllen, habe ich mit dem Schraubenschlüssel die vier Muttern 

gelöst.“ 

3. Identifizierung repräsentativer Eigenschaften von Aufgaben 

a) Wichtigkeit der Objekte aus 2c festlegen 

Die Menge der Objekte nach Relevanz für die Aufgabenerfüllung bewerten. 

Von mehreren Personen identifizierte Objekte sind wahrscheinlich wichtiger 

für die Aufgabenerfüllung als einmalig genannte Objekte. 

b) Wichtigkeit der Methoden aus 2b festlegen 

Die Menge der Methoden nach Relevanz für die Aufgabenerfüllung bewerten. 

4. Konstruktion des Aufgabenmodells 

a) Konstruktion einer Zielhierarchie 

Die Ziele in eine Zielhierarchie überführen, die temporalen Operatoren definieren. 

b) Beschreiben der Methoden auf unterster Ebene Die Ziele der untersten Hierarchieebene 

werden mit Methoden versehen, um diese Ziele zu erfüllen. In 

der Hierarchie höhere Ziele sind Kompositionen der Blätter der Zielhierarchie. 

c) Beschreiben der benutzten Objekte Zusätzlich zu den Methoden werden die 

Ziele noch mit den zur Zielerfüllung verwendeten Objekten versehen. 

5. Vermittlung und Validierung des Modells. 

Einfluss auf die weiteren Arbeiten hat TKS vor allem durch die methodische Analyse 

eines realen Prozesses. Auch wenn die resultierenden Aufgabenmodelle bei TKS nicht 

direkt zur Erzeugung einer Benutzerschnittstelle geeignet sind, kann in den aktuellen 

Ansätzen mit dem (eventuell angepassten) TKS-Analyseprozess ein initiales Aufgabenmodell 

konstruiert werden. 

Model for Activity Description / Méthode Analytique de Description des tâches (MAD) 

Mit dem Model for Activity Description (ursprünglich hieß die Methode auf französisch 

„Méthode Analytique de Description des tâches“) formulierten Scapin und Pierret- 

Goldbreich [1989] eine Notation für hierarchische Aufgabenmodelle, welche die hierarchische 

Aufgabenzerlegung von HTA übernimmt, anstelle der Pläne aber sogenannte 

Konstruktoren einführt. 

43


In MAD existieren zwei Arten von Aufgaben: komplexe Aufgaben und elementare 

Aufgaben. Elementare Aufgaben sind Blattaufgaben der Aufgabenhierarchie und werden 

nicht weiter unterteilt. Komplexe Aufgaben sind Aufgaben, die in Unteraufgaben 

zerlegt werden, und welche, ähnlich wie in HTA, einen temporalen Operator, hier Konstruktor 

genannt, für die Unteraufgaben definieren müssen. Folgende Konstruktoren 

stehen zur Verfügung: 

Konstruktor Definition 

Tabelle 3.1: MAD – Konstruktoren 

SEQ Die Aufgaben werden in der angegebenen Reihenfolge ausgeführt 

SET Die Aufgaben werden in unbestimmter Reihenfolge ausgeführt 

SIM Die Aufgaben werden parallel ausgeführt 

ALT Von den Aufgaben wird nur eine ausgeführt 

COND Die Aufgabe wird nur ausgeführt, wenn die Bedingung erfüllt ist 

OPT Die Aufgabe kann optional ausgeführt werden 

LOOP Die Aufgabe wird mehrfach ausgeführt 

Im Gegensatz zu HTA kann eine Aufgabe nur einen gemeinsamen Konstruktor für alle 

Unteraufgaben verwenden. Bei der Erstellung der Aufgabenhierarchie ist dieser Umstand 

zu beachten, eventuell müssen zusätzliche Hierarchieebenen eingefügt werden, 

zum Beispiel, wenn ein Teil der Unteraufgaben sequenziell und ein Teil gleichzeitig ausgeführt 

werden soll. 

Jede Aufgabe besitzt bei MAD Eigenschaften, die die Aufgabe formalisierter als eine 

textuelle Beschreibung definieren. Folgende Eigenschaften sind u. a. vorgesehen: 

Eigenschaft Definition 

Tabelle 3.2: MAD – Aufgabeneigenschaften 

Vorbedingungen Bedingungen, die erfüllt sein müssen, um die Aufgabe anzufangen. 

Nachbedingungen Bedingung, die erfüllt sein müssen, um die Aufgabe zu beenden. 

Name Name der Aufgabe (text) 

Ziel Ziel, das durch die Aufgabenerfüllung erreicht wird (text) 

Unterbrechbar Darf die Aufgabe durch andere Aufgaben unterbrochen werden? 

(ja,nein) 

Modalität Wie wird die Aufgabe ausgeführt? (manuell,automatisch,interaktiv) 

Typ Welche Leistung muss der Benutzer erbringen? (kognitiv,sensomotorisch) 

44 

(Tabelle wird auf der nächsten Seite fortgesetzt)

(fortgesetzt von der vorigen Seite) 



Erfahrung Welche Erfahrung muss der Benutzer besitzen? (Anfänger, 

Durchschnitt, Experte) 

MAD modelliert zwar keine Rollen oder Objekte, dafür werden die Aufgaben mit hohem 

Detaillierungsgrad beschrieben, andere Methoden verwenden meist nur textuelle 

Beschreibungen. Wenn z. B. eine Unteraufgabe in einer Sequenz ausgeführt wird, dann 

kann die Vorbedingung – zusätzlich zu der impliziten Bedingung, dass die Unteraufgabe 

erst nach der vorherigen Unteraufgabe gestartet wird – weitere Einschränkungen 

angeben. Die Modalität gibt an, ob eine Unteraufgabe in einer Sequenz automatisch 

gestartet wird, wenn die vorherige Unteraufgabe beendet wurde. 

Die formalisierten Eigenschaften sind z. B. bei der Simulation des Aufgabenmodells 

durch ein Programm sinnvoll, dieses kann die Informationen auswerten und das Aufgabenmodell 

besser simulieren, als wenn nur eine nicht interpretierbare textuelle Beschreibung 

verfügbar wäre. 

User Action Notation (UAN) 

Die User Action Notation wurde von Hix und Hartson [1993] entwickelt, um die Interaktion 

eines Benutzers mit einer grafischen Benutzerschnittstelle zu modellieren. Sie ist 

stark an das Grundkonzept moderner grafischer Benutzeroberflächen geknüpft 19 und 

kann auch nur die Aktionen modellieren, die der Benutzer auf einer solchen Benutzerschnittstelle 

auslösen kann. Für uns ist die UAN interessant, weil sie Konzepte der 

hierarchischen Aufgabenzerlegung und der temporalen Relationen verwendet, um die 

Interaktionen zu beschreiben. UAN-Modelle beschreiben die Aktionen des Benutzers 

und die Reaktionen des Systems (reduziert auf die Ausgaben der Benutzerschnittstelle) 

beim gemeinsamen Ausführen einer Aufgabe. 

Elementare Aufgaben werden in der UAN in einer dreispaltigen Tabelle definiert: 

die erste Spalte enthält die formalisierten Benutzeraktionen, die zweite Spalte die Systemreaktionen 

und die dritte Spalte beschreibt den aufgrund der Interaktion veränderten 

Systemzustand. Für die Benutzeraktionen sieht die Spezifikation folgende Elemente 

vor: 

Symbol Definition 

∼ Bewegen des Mauszeigers 

Tabelle 3.3: UAN – Benutzeraktionen 

∼ [X ] Bewegen des Mauszeigers in den Kontext des Objektes X , z. B. der 

Mauszeiger wird auf ein Icon bewegt. 

(Tabelle wird auf der nächsten Seite fortgesetzt) 

19 Auch bekannt unter dem WIMP-Paradigma, benannt nach den englischen Begriffen der vorherrschenden Elemente: 

Window (Fenster), Icon (Piktogramm), Menu (Menüs) und Pointer (Mauszeiger). 

45




[X ] ∼ Bewegen des Mauszeigers aus dem Kontext des Objektes X . 

∼ [x, y]∗ Bewegen des Mauszeigers um eine beliebige Strecke. 

M∨ Drücken der Maustaste 

M∧ Maustaste loslassen 

M ∨ ∧ Mausclick 

K ′ xyz ′ 

Eingabe der Zeichenkette xyz 

Für die Systemreaktionen sieht die Spezifikation folgende Elemente vor: 


Tabelle 3.4: UAN – Systemreaktionen 

X ! Objekt X wird selektiert, z. B. ein Icon wird hervorgehoben. 

X −! Objekt X wird deselektiert. 

X >∼ Objekt X wird mit dem Mauszeiger gezogen 

Die Änderungen am Systemzustand in der dritten Spalte werden nicht weiter formalisiert. 

Folgendes Beispiel verdeutlicht die Definition einer Aufgabe in der UAN: 

Aufgabe: lösche Datei 

Tabelle 3.5: UAN – Beispiel 

Benutzeraktion Systemreaktion Systemzustand 

∼ [dateisymbol]M∨ dateisymbol! selektiert = datei 

∼ [x, y]∗ dateisymbol >∼ 

∼ [muelleimersymbol] muelleimersymbol! 

M∧ muelleimersymbol−! lösche(selektiert) 

Aufgabendefinitionen in UAN werden wie geschriebene Texte interpretiert, zeilenweise 

von links nach rechts. Die Aufgabe lösche Datei beschreibt eine Interaktion, um eine 

Datei mittels der Maus in den Mülleimer zu verschieben. Die Aufgabe startet mit der 

Benutzeraktion „bewege Mauszeiger auf Dateisymbol und drücke die Maustaste“. Als 

Reaktion markiert das System das Dateisymbol, intern verändert es den Systemzustand, 

indem die Variable selektiert auf die selektierte Datei gesetzt wird. In der nächsten Zeile 

verschiebt der Benutzer die Maus bei immer noch gedrückter Maustaste. Das System 

sorgt dafür, dass das Dateisymbol mit dem Mauszeiger verschoben wird. In der nächsten 

Zeile bewegt der Benutzer den Mauszeiger auf das Mülleimersymbol, das System hebt 

46


jetzt auch den Mülleimer hervor. In der letzten Zeile lässt der Benutzer die Maustaste 

los, das System entfernt die Hervorhebung des Mülleimers und löscht die selektierte 

Datei. 

Dieses vereinfachte Beispiel zeigt die Definition einer atomaren Aufgabe. Zusammengesetzte 

Aufgaben erlaubt die UAN über eine Reihe von temporalen Operatoren 

(siehe folgende Tabelle 3.6), mit denen sich zusammengesetzte Aufgaben erstellen lassen. 

So könnte eine komplexe Aufgabe kopiere Dateien beispielsweise folgendermaßen 

zusammengesetzt werden: ((selektiereDatei + ) (zuWenigSpeicherplatzWarnung → 

fügeDateienInOrdnerEin)). Der Benutzer selektiert zuerst eine oder mehrere Dateien, 

welche danach in ein vom Benutzer selektiertes Zielverzeichnis kopiert werden. Diese 

Aufgabe kann von der Aufgabe unterbrochen werden, wenn zu wenig Speicherplatz 

zum Kopieren zur Verfügung steht. 

Operator Definition 

Tabelle 3.6: UAN – temporale Operationen 

(U1U2) Sequenz von U1 und U2: U2 kann erst begonnen werden, wenn U1 ausgeführt 

wurde. 

(U ∗ ) Iteration mit beliebig vielen Ausführungen von U: n Wiederholungen 

von U mit 0 ≤ n ≤ ∞. 

(U + ) Iteration mit mindestens einer Ausführung von U: n Wiederholungen 

von U mit 1 ≤ n ≤ ∞. 

(U n ) Iteration mit festgelegter Anzahl an Ausführungen von U: U muss nmal 

wiederholt werden. 

{U} Optionale Ausführung: Aufgabe U kann, muss aber nicht ausgeführt 

werden. 

(U1|U2) Auswahl: Entweder U1 oder U2 werden ausgeführt. 

(U1&U2) Beliebige Ausführung: U1 und U2 können in beliebiger Reihenfolge 

ausgeführt werden. 

(U1 → U2) Unterbrechbarkeit: Aufgabe U1 kann Aufgabe U2 unterbrechen. Nach 

Beendigung von U1 kann U2 fortgesetzt werden. 

(U1 ⇔ U2) Gegenseitige Unterbrechbarkeit: Aufgabe U1 kann Aufgabe U2 und 

Aufgabe U2 kann Aufgabe U1 unterbrechen. 

 nicht unterbrechbare Aufgabe: Die Aufgabe U darf nicht durch eine 

andere Aufgabe unterbrochen werden. 

(U1||U2) Nebenläufigkeit: Aufgabe U1 und Aufgabe U2 können gleichzeitig und 

unabhängig voneinander ausgeführt werden. 

Aufgrund der Festlegung auf Interaktionen einer grafischen Benutzeroberfläche eignet 

sich die UAN kaum für die Aufgabenanalyse im klassischen Sinn. Allerdings definiert die 

UAN sehr feingranulare temporale Operatoren, die die Definition der Operatoren bei 

47


der HTA wesentlich erweitern und in den nachfolgenden Methoden wieder aufgegriffen 

werden. 

Concurrent Task Trees (CTT) 

Die bisher vorgestellten Methoden liefern eine textuelle Beschreibung der Aufgabenhierarchien, 

welche zwar eine hohe Ausdruckskraft besitzen, aber deren Abläufe nicht 

leicht erfassbar sind. UAN wurde für die textuelle Notation kritisiert, weil weder die 

Aufgabenbeschreibungen, noch die Hierarchien leicht lesbar sind [Paternò, 1999]. Grafische 

Notationen können die gleiche Mächtigkeit besitzen, erleichtern aber durch die 

Verwendung von grafischer Gestaltung die Erfassung der Gesamtsicht. Auch können 

einfacher benachbarte Aufgaben betrachtet werden (Unteraufgaben, Elternaufgabe 

oder Aufgaben der gleichen Hierarchieebene), um den Kontext einer Aufgabe zu ermitteln. 

Die Concurrent Task Trees von Paternò u. a. [1997] setzen aus diesem Grund 

konsequent auf eine grafische Notation. 

Die Beziehungen der Aufgaben untereinander basieren auf LOTOS, einer formalen 

Beschreibungssprache, die ursprünglich für Protokollspezifikationen eingesetzt wurde 

(siehe Standard ISO 8807 [1989]). Die Elemente von LOTOS ermöglichen, das beobachtbare 

Verhalten eines Systems ohne Kenntnis der internen Zustände zu beschreiben. CTT 

verwendet die von LOTOS definierten temporalen Operatoren, welche wir in ähnlicher 

Form auch bereits bei den anderen Ansätzen kennengelernt haben. Im Gegensatz zu 

den anderen Methoden, werden bei CTT mit einem temporalen Operator nicht die 

Beziehung der Unteraufgaben zu einer Oberaufgabe beschrieben, sondern die Beziehung 

von zwei benachbarten Unteraufgaben. Die folgende Tabelle listet die verfügbaren 

Operatoren auf: 


U1[]U2 

U1 >> U2 

U1[] >> U2 

U1| = |U2 

U1|||U2 

48 

Tabelle 3.7: CTT – temporale Operationen 

Auswahl: Aus den Aufgaben U1 und U2 kann nur eine ausgewählt und 


Sequenz: Die Aufgabe U2 kann erst ausgeführt werden, wenn die Aufgabe 

U1 beendet wurde. 

Sequenz mit Informationsaustausch: Die Aufgabe U2 kann erst nach 

U1 ausgeführt werden, bekommt allerdings Informationen von dieser 

übermittelt, z. B. die Interaktionsaufgabe Mail schreiben liefert den 

Text an die Systemaufgabe Mail verschicken weiter. 

beliebige Reihenfolge: Die Aufgaben müssen nacheinander, aber in 

beliebiger Reihenfolge ausgeführt werden. 

Nebenläufigkeit: Die Aufgaben U1 und U2 können in beliebiger Reihenfolge 

parallel ausgeführt werden. 




U1|[]|U2 

U1[> U2 

U1| > U2 


Nebenläufigkeit mit Informationsaustausch: Die Aufgaben U1 und U2 

können gleichzeitig ausgeführt werden. Beide Aufgaben beeinflussen 

sich gegenseitig, z. B. eine Länderauswahl und die Anzeige der Versandkosten. 

Deaktivierung: Die Aufgabe U1 kann ausgeführt werden, solange U2 

noch nicht ausgeführt wurde, z. B. die Aufgabe durchlesen einer Webseite 

und die Aufgabe Auswahl eines Links, welche auf eine andere 

Webseite führt. 

Unterbrechung: Die Ausführung der Aufgabe U1 kann durch eine Aufgabe 

U2 unterbrochen werden. Wenn U2 beendet wurde, kann U1 fortgesetzt 

werden, z. B. ein modaler Dialog, der die Anwendung unterbricht. 

Aufgaben werden bei der grafischen CTT-Notation in fünf verschiedene Kategorien 

eingeteilt, welche über Symbole repräsentiert werden. Aus der Vogelperspektive können 

bei einem großen Aufgabenmodell die Symbole einfacher erkannt werden als die 

Bezeichnungen der Aufgaben. Sie unterstützen damit den Modellierer beim Navigieren 

oder Erfassen der Aufgabenhierarchie. 


Tabelle 3.8: CTT – Aufgabenkategorien 

Benutzeraufgabe: Aufgaben, die der Benutzer ohne Beteiligung der 

Anwendung durchführt. Dies sind z. B. kognitive Prozesse zur Entscheidungsfindung. 

Systemaufgabe: Aufgaben, die die Anwendung ohne Beteiligung des 

Benutzers durchführt, z. B. Daten zur Ausgabe aufbereiten, Emails versenden 

oder Transaktionen durchführen. 

Abstrakte Aufgabe: Eine Aufgabe, die in Unteraufgaben mit unterschiedlichen 

Aufgabentypen zerlegt wird, muss diese Typen in sich vereinen. 

Die Aufgabe wird deshalb als abstrakt bezeichnet. 

Interaktionsaufgabe: Aufgaben, die der Benutzer in Interaktion mit 

dem System ausführt, z. B. Auswahl aus einer Liste, Bearbeitung eines 

Textes oder drücken eines Knopfes. 

Kooperationsaufgabe: Aufgaben, die von mehreren Benutzern in Zusammenarbeit 


Die Einordnung einer Aufgabe in eine Kategorie hängt von den Kategorien der Unteraufgaben 

in der Aufgabenhierarchie ab. Wenn alle Unteraufgaben aus der gleichen Ka- 

49


tegorie stammen, dann muss auch die Oberaufgabe zu dieser Kategorie gehören. Wenn 

die Unteraufgaben aus unterschiedlichen Kategorien stammen, dann muss die Oberaufgabe 

zur abstrakten Kategorie zählen. Blattaufgaben sollten nicht abstrakt sein, ihre 

Kategorie wird anhand der Aufgabenanalyse bestimmt. 

Die CTT-Notation sieht auch eine weitere Unterkategorisierung vor, so kann eine 

Aufgabe der Kategorie Benutzeraufgabe beispielsweise in eine der Unterkategorien 

Planen, Vergleich oder Problem lösen zerlegt werden. Da diese Unterkategorien aber 

nicht weiter verwendet werden und auch kein eigenes Symbol erhalten, werden wir sie 

auch nicht weiter betrachten. 

Die Aufgaben werden in der CTT-Notation mit Eigenschaften versehen, um sie formal 

zu beschreiben. Dabei orientieren sie sich an den Aufgabeneigenschaften anderer 

Notationen, z. B. MAD. 


U ∗ 

Tabelle 3.9: CTT – Aufgabeneigenschaften 

Iteration: Die Aufgabe U wird wiederholt, bis sie von einer anderen 

Aufgabe unterbrochen wird. Diese Aufgabeneigenschaft ist nur mit 

dem Deaktivierungsoperator ([>) sinnvoll einsetzbar, weil sonst die 

Iteration niemals beendet wird. 

U(n) festgelegte Iterationen: Die Aufgabe U wird n mal wiederholt. 

[U] optionale Aufgabe: Die Aufgabe U kann übersprungen werden. 

Name Name der Aufgabe, der in der grafischen Darstellung unter dem Aufgabensymbol 

dargestellt wird. 

Vorbedingungen Bedingungen, die erfüllt sein müssen, um die Aufgabe auszuführen. 

Objekte Objekte, die zur Aufgabenausführung verwendet werden. 

Abbildung 3.3 zeigt ein Beispiel in der CTT-Notation (aus [Paternò, 2003]), welches 

den Prozess einer Hotelzimmerreservierung als Aufgabenhierarchie abbildet. Die Wurzelaufgabe 

HotelReservation wird aufgeteilt in die beiden Unteraufgaben SelectRoom- 

Type und MakeReservation, welche in einer Sequenz mit Informationsaustausch ausgeführt 

werden. Die erste Unteraufgabe wird in eine Selektion zerlegt, bei der der Benutzer 

sich entscheiden muss, ob ein Einzel- oder Doppelzimmer reserviert werden soll. 

Beides sind Benutzeraufgaben, deshalb wird auch SelectRoomType zu einer Benutzeraufgabe. 

Im rechten Teil des Aufgabenmodells wird der gewählte Zimmertyp reserviert, 

indem zuerst die Verfügbarkeit vom System angezeigt wird und dann vom Benutzer ein 

Zimmer ausgewählt wird, wiederum als Sequenz mit Informationsaustausch. 

In CTT-Aufgabenmodellen können Unteraufgaben der gleichen Oberaufgabe mit unterschiedlichen 

temporalen Operatoren verknüpft werden, weil die CTT-Notation nur 

binäre Operatoren vorsieht 20 . Dies hat Vorteile bezüglich der Flexibilität (Unteraufga- 

20 Im Gegensatz zu den anderen Ansätzen, bei denen der Operator der Oberaufgabe sich auf alle Unteraufgaben 

beziehen und deshalb n-är sind. 

50

Abbildung 3.3: CTT – Beispiel [Paternò, 2003] 


ben können temporal gemischt ausgeführt werden und müssen nicht erst temporal sortiert 

und hierarchisiert werden), aber auch Nachteile (eine Auswahl mit mehr als zwei 

Aufgaben muss auf mehrere Hierarchieebenen verteilt werden). 

3.4.3 Gemeinsamkeiten 

Die verschiedenen Ansätze unterscheiden sich in ihren Zielsetzungen, nicht bei allen 

steht die Erzeugung einer Benutzerschnittstelle im Vordergrund. Die Zielsetzungen umfassen 

nach [Limbourg u. a., 2001] folgende Aspekte: 

Aufgabenmodelle sollen Aussagen über die Benutzbarkeit treffen (z. B. in HTA). 

Das Verhalten von Benutzern bei der Verwendung einer Anwendung soll analysiert 

werden (z. B. in GOMS). 

Aufgabenmodelle sollen den Entwurf einer Anwendung unterstützen durch: detaillierte 

Aufgabenhierarchien, verwendete Objekte, etc. (z. B. in TKS, CTT). 

Es soll ein Prototyp der Benutzerschnittstelle generiert werden (z. B. in CTT). 

Allen vorgestellten Methoden ist gemein, dass sie die Aufgaben in Unteraufgaben zerlegen 

und dass sie eine zeitliche Anordnung der Unteraufgaben vornehmen. Die Anzahl 

und Semantik der temporalen Operatoren variiert stark, folgende Tabelle fasst die Gemeinsamkeiten 

und Unterschiede zusammen: 

Tabelle 3.10: Vergleich der temporalen Operatoren 

Operator HTA GOMS TKS MAD UAN CTT 

Sequenz 

beliebige Sequenz 

Auswahl 


51



Operator HTA GOMS TKS MAD UAN CTT 

Nebenläufigkeit 

Unterbrechbarkeit 

Auch ein Vergleich der Aufgabeneigenschaften ist sinnvoll. Die Methoden definieren 

für die Aufgabenanalyse ähnliche Eigenschaften, um eine Aufgabe zu spezifizieren. Die 

folgende Tabelle fasst dies zusammen: 

Tabelle 3.11: Vergleich der Aufgabeneigenschaften 

Eigenschaft HTA GOMS TKS MAD UAN CTT 

Name 

Optionalität 

Iteration 

Vorbedingungen 

Aufgabentyp 

Aufgabenobjekte 

Benutzerrolle 

Die vorgestellten Methoden der Aufgabenanalyse haben trotz ihrer Unterschiede 

viele Gemeinsamkeiten. Wenn wir im weiteren Verlauf von einem Aufgabenmodell 

sprechen, so beziehen wir uns auf ein allgemeines hierarchisches Aufgabenmodell mit 

temporalen Relationen, welches alle Methoden liefern können. Die CTT-Notation sticht 

heraus, weil sie alle untersuchten Operatoren und Eigenschaften unterstützt. Bei der in 

dieser Arbeit nicht weiter betrachteten Werkzeugunterstützung hat die CTT-Notation 

ebenfalls Vorteile, zwei Diagrammeditoren unterstützen den Modellierer bei der Arbeit: 

ConcurTaskTreeEnvironment (CTTE) von Mori u. a. [2002] und Teresa von Paternò 

u. a. [2008]. 

3.5 Dialogmodellierung 


Im Entwicklungsprozess folgt auf die Aufgabenmodellierung die Dialogmodellierung, 

welche Gegenstand dieses Abschnitts ist. Zuerst werden wir den Dialogbegriff definieren 

und die möglichen Notationen eines Dialogmodells erörtern. Am Schluss steht eine 

Betrachtung, wie ein Aufgabenmodell in ein Dialogmodell umgewandelt werden kann. 

52

3.5.2 Definition 


Laut Dix u. a. [1993] ist ein Dialog, im Gegensatz zu einem Monolog, eine Konversation 

zwischen zwei oder mehr Beteiligten, mit dem Ziel eine Aufgabe oder Konflikt 

zu lösen. Bei dem Entwurf von Benutzerschnittstellen wird eine engere Definition des 

Dialogs verwendet: Er beschreibt die Struktur der Konversation zwischen dem Benutzer 

einer Anwendung und der Anwendung selbst. Wichtig ist der Strukturbegriff, ein 

Dialog beschreibt nur den Ablauf der Interaktionen, nicht wie Ein- und Ausgaben der 

Interaktionen präsentiert werden. 

Ein Dialog beschreibt die Konversation eines Benutzers mit einer Anwendung, welche 

aus einer Folge von Dialogschritten besteht: 

1. Der Benutzer tätigt eine Eingabe 

2. Die Anwendung generiert eine Ausgabe 

Im idealen Fall kann die Anwendung auf eine natürlichsprachige Anfrage des Benutzers 

antworten, z. B. können in Kinofilmen per Sprachsteuerung ganze Raumschiffe gesteuert 

werden. Dies ist Forschungsgegenstand der künstlichen Intelligenz [Helbig, 1996], 

wir beschränken uns auf die realen Dialogmöglichkeiten eines Benutzers mit einer Web- 

Anwendung. In diesem Fall können wir die oben genannte Folge von Dialogschritten 

detaillierter spezifizieren: 

1. Der Benutzer tätigt eine Eingabe und sendet eine Anfrage an die Anwendung 

2. Die Anwendung verarbeitet die Anfrage und ändert den internen Zustand basierend 

auf der Eingabe. 

3. Die Anwendung generiert eine Ausgabe basierend auf dem neuen internen Zustand. 

4. Der Benutzer verarbeitet die Ausgabe der Anwendung und fängt den nächsten 

Dialogschritt bei Punkt 1 an. 

In herkömmlichen Anwendungen, die keine Trennung von der Struktur der Konversation 

und der Anwendungslogik vorsehen, ist der Dialog implizit im Programm enthalten. 

Mittels Sprüngen, Schleifen und Wenn-Dann-Bedingungen wird der Ablauf der 

Anwendung basierend auf den Eingaben des Benutzers gesteuert und eine Ausgabe 

generiert. Während diese Abläufe im Quelltext kleiner Anwendungen leicht zu erkennen 

sind, sind diese bei großen Anwendungen nicht mehr von der Anwendungslogik 

trennbar. Die Nachteile sind offensichtlich, eine Änderung des Dialogs ist nicht trivial 

durchführbar, wenn z. B. in einer Sequenz von Dialogschritten die Reihenfolge zweier 

Schritte vertauscht werden soll, dann zieht das tief greifende Änderungen am Quelltext 

nach sich. Auch eine Verifikation des Dialogs kann nicht stattfinden, z. B. um die 

Erreichbarkeit von Dialogschritten zu prüfen, oder um Abweichungen vom „normalen“ 

Programmablauf bei fehlerhaften Eingaben zu testen. 

53


authentifiziert 

entry / Zugang erlaubt 

Passwort korrekt 

abmelden 

passwort korrekt 

nicht authentifiziert 

entry / Bitte authentifizieren 

Passwort inkorrekt 

Abbildung 3.4: Dialogmodell – Beispiel 

Passwort falsch 

entry / Erneuter Versuch 

Passwort inkorrekt 

Ziel der Dialogmodellierung ist die Entwicklung eines Dialogmodells, welches die 

möglichen Dialogschritte eines Benutzers auf einer Anwendung vorgibt. Das Dialogmodell 

drückt nur die Struktur der Interaktionen aus, die Anbindung einer Benutzerschnittstelle 

und eines Domänenmodells muss in späteren Entwicklungsschritten folgen. 

Wie Dialogmodelle definiert werden können, werden wir im nächsten Abschnitt 

präsentieren. 

3.5.3 Notation 

Dialogmodelle können sowohl grafisch als auch textuell notiert werden. Üblicherweise 

werden in Dialogmodellen die Zustände des Dialogs und Transitionen zwischen Zuständen 

beschrieben 21 . Ein Dialogschritt ist die Transition von einem Dialogzustand in einen 

Folgenden. 

Mit einem endlichen Automaten wird der Zustandsraum der Anwendung beschrieben, 

durch das Hinzufügen von Transitionen kann der Modellierer den Dialog erzeugen. 

Zur Laufzeit würde ein Dialogschritt folgendermaßen abgearbeitet: 

Die Eingabe des Benutzers wird als Ereignis an den endlichen Automaten weitergeleitet, 

der die entsprechende Transition für den aktuellen Zustand auslösen 

kann. 

Eventuelle Vorbedingungen können den Zustandsübergang verhindern. 

Die Ausgabe der Anwendung wird über die Eintrittsaktion des Zielzustandes ausgelöst 

22 . 

Für die grafische Notation der Dialoge werden Zustandsübergangsdiagramme benutzt, 

welche endliche Automaten abbilden. Eine textuelle Darstellung ist aber beispielsweise 

auch über Zustandstabellen möglich. 

Die Abbildung 3.4 zeigt ein Beispiel als Zustandsübergangsdiagramm. Beim Aufruf 

der Anwendung befindet sich der endliche Automat in dem Zustand nicht authenti- 

21 Auf die zweite Möglichkeit, die Beschreibung des Dialogs mittels einer BNF-Grammatik, werden wir in dieser 

Arbeit nicht eingehen. Sie hat sich für diesen Zweck nicht durchgesetzt und wird kaum noch verwendet. 

22 Je nach Umsetzung des endlichen Automats kann auch eine Ausgabefunktion der Transition verwendet werden. 

In diesem Fall wäre das Dialogmodell flexibler, weil die Ausgabe eines Zustandes davon abhängen könnte, 

über welchen Zustandsübergang der Zustand erreicht wurde. 

54


fiziert und erzeugt die Ausgabe Bitte authentifizieren. Wenn der Benutzer ein Passwort 

eingegeben hat, generiert die Anwendung entweder das Ereignis Passwort korrekt 

oder Passwort inkorrekt. Falls das Passwort korrekt war, wird der endliche Automat 

in den Zustand authentifiziert überführt und die Ausgabe Zugang erlaubt wird erzeugt. 

Falls das Passwort nicht korrekt war, bekommt der Benutzer die Möglichkeit, das Passwort 

im Zustand Passwort falsch erneut einzugeben. Ein einmal angemeldeter Benutzer 

kann sich über das abmelden-Ereignis in den Zustand nicht authentifiziert zurückversetzen. 

3.5.4 Vom Aufgabenmodell zum Dialogmodell 

Aufgabenmodellierung und Dialogmodellierung haben das gemeinsame Ziel, die Aufgaben 

und Ziele des Benutzers früh im Entwicklungsprozess zu erfassen und in geeigneten 

Modellen zu beschreiben. Während die Aufgabenmodelle eine abstrakte Sicht 

auf die Interaktion des Benutzers mit einer Anwendung bieten, orientieren sich Dialogmodelle 

an der Beschreibung von Dialogschritten [Betermieux u. a., 2005]. 

Wie kann aus einem Aufgabenmodell, welches in der Analysephase angelegt wurde, 

ein Dialogmodell erzeugt werden? Dialogschritte können als Aufgaben betrachtet 

werden, z. B. könnte die Transition vom Zustand nicht authentifiziert in den Zustand 

authentifiziert die Umsetzung einer imaginären Aufgabe Benutzer anmelden sein. Ein 

Dialogmodell könnte also beispielsweise automatisch generiert werden, indem die Aufgaben 

zu Zustandsübergängen umgeformt werden und passende Zustände erzeugt 

werden. In den meisten Fällen hätte solch ein Dialogmodell aber zu viele Zustände, um 

praktikabel umsetzbar zu sein. Methoden wie CTT bieten eine semi-automatische Transformation, 

bei der Aufgaben mittels heuristischer Methoden zu einer Aufgabenmenge 

zusammengefasst werden, die in einem Dialogschritt gleichzeitig bearbeitet werden 

können [Paternò und Santoro, 2002]. Damit können Benutzer, auch ohne Nebenläufigkeit, 

mehrere Aufgaben in einem Dialogschritt durchführen. In weiteren Arbeiten 

setzen sich Luyten u. a. [2003] und Clerckx u. a. [2004] detailliert mit der Erzeugung 

von Aufgabenmengen zur Transformation eines Aufgabenmodells in ein Dialogmodell 

auseinander. 

Um die Definition der Dialogschritte zu erfüllen, muss jede Aufgabe aus einem Teil 

Benutzereingabe und einem anschließenden Teil Anwendungsausgabe bestehen. Bei 

Methoden, die keine Aufgabenkategorisierung vorsehen, werden die Aufgaben implizit 

als Doppelaufgabe betrachtet: ein Aufgabenteil wird vom Benutzer ausgeführt, ein 

Aufgabenteil von der Anwendung (siehe Abbildung 3.5). Bei Methoden, die eine Aufgabenkategorisierung 

vorsehen, lässt sich dies auch explizit in der Aufgabenhierarchie 

modellieren. Bei der CTT-Notation ist dabei aber zu beachten, dass die Benutzereingaben 

eines Dialogschritts von einer Interaktionsaufgabe 23 und die Anwendungsausgabe 

von einer Systemaufgabe erzeugt werden können, welche im Wechsel einen Dialog beschreiben 

können. 

23 Nicht geeignet ist die naheliegende Benutzeraufgabe, weil diese Aufgaben kategorisiert, die der Benutzer 

eben nicht im Dialog mit der Anwendung durchführt. Leider liefert die Interaktionsaufgabe keine klare Trennung 

zwischen Benutzereingabe und Anwendungsaufgabe, wünschenswert wäre eine Aufgabenkategorie, die 

nur die Benutzereingabe beschreibt. 

55


Zustand 1 

Benutzer- 

Aufgabe 

System- 

Aufgabe 

Eingabe Ausgabe 

Dialogmodell 

Zustand 2 

Transition Transition 

Umsetzung der temporalen Operationen 


Benutzer- 

Aufgabe 

Abbildung 3.5: Dialog und Aufgaben 

System- 

Aufgabe 

Eingabe Ausgabe 

Nach der allgemeinen Betrachtung der Transformation einer Aufgabenhierarchie in ein 

Zustandsübergangsdiagramm wollen wir in diesem Abschnitt die Umsetzung der temporalen 

Operatoren und der Aufgabeneigenschaften analysieren. Als Ausgangsaufgabenmodell 

dient uns eine Aufgabenhierarchie mit einer Wurzelaufgabe, die in die Unteraufgaben 

Aufgabe 1 und Aufgabe 2 zerlegt wurde. Abhängig von dem temporalen 

Operator der Wurzelaufgabe für die beiden Unteraufgaben ergeben sich folgende Dialogmodelle: 

Sequenz: In der Abbildung links ist das Zustandsübergangsdiagramm 

für zwei Aufgaben dargestellt, die sequenziell ausgeführt werden 

sollen. Für die Modellierung des Dialogs wird im Zustandsübergangs- 

Zustand 1 diagramm ein Startzustand eingefügt, in dem die Bearbeitung des 

Dialogs beginnt. Vom Startzustand Zustand 1 kann nur die Transi- 

Aufgabe 1 

tion von Aufgabe 1 einen Zustandswechsel in Zustand 2 auslösen. 

Zustand 2 Danach kann die Bearbeitung von Aufgabe 2 den endlichen Auto- 

Aufgabe 2 maten in Zustand 3 versetzen. Eine sequenzielle Bearbeitung der 

Aufgaben liegt also immer dann vor, wenn von den Zuständen einer 

Zustand 3 

Zustandsmenge nur eine Transition ausgeht. Die Umsetzung von optionalen 

und iterativen Aufgaben müssen zusätzlich in das Zustandsübergangsdiagramm 

eingebracht werden, diese zu den temporalen Operatoren orthogonalen 

Konzepte werden wir am Ende dieses Abschnitts vorstellen. 

56 

Zustand 3


Aufgabe 1 

Auswahl: Zustände besitzen bei einer Auswahl, im Gegensatz 

zu einer Sequenz, mindestens zwei ausgehende Transitionen. 

In der Abbildung links ist das Zustandsübergangs- 

Zustand 2 

diagramm für eine Auswahl aus zwei Aufgaben dargestellt. 

Zustand 1 

Vom Startzustand gehen zwei Transitionen zu unterschiedlichen 

Zielzuständen. Je nachdem, ob Aufgabe 1 oder Auf- 

Aufgabe 2 

Zustand 3 

gabe 2 ausgeführt wird, wird Zustand 2 oder Zustand 3 erreicht. 

Eine Auswahl liegt also immer dann vor, wenn mehr 

als eine Transition von einem Zustand ausgeht. 

Nebenläufigkeit: Nebenläufigkeit 

ist in Zustandsübergangs- 

Zustand 1 Aufgabe 1 Zustand 2 

diagrammen schwer darstellbar, 

der endliche Automat darf 

Zustand 3 

Aufgabe 2 

Zustand 4 sich zu jeder Zeit nur in einem 

Zustand befinden. Bei nebenläufigen 

Prozessen muss das 

kartesische Produkt der Zustandsmengen der einzelnen nebenläufigen Prozesse gebildet 

werden, damit für jede Situation nur ein Zustand existiert. Die resultierende 

Zustandsmenge wird dabei allerdings schnell groß, bei zwei nebenläufigen Sequenzen 

mit jeweils drei Zuständen wären es bereits neun Zustände. In einem UML-Zustandsübergangsdiagramm 

lässt sich dies leichter über orthogonale Zustände ausdrücken. Ein 

Zustand wird in zwei unabhängige Bereiche geteilt, die Unterautomaten aufnehmen 

können. In der Abbildung sind zwei nebenläufige Aufgaben in einem Zustandsübergangsdiagramm 

dargestellt. Der unbenannte Startzustand startet zwei nebenläufige 

Unterautomaten, welche von Zustand 1 die Aufgabe 1 und von Zustand 3 die Aufgabe 

2 parallel verarbeiten können. 

beliebige Sequenz: Bei der beliebigen Se- 

Aufgabe 1 

Aufgabe 2 quenz ergeben sich ähnliche Probleme wie 

Zustand 2 

bei der Modellierung der Nebenläufig- 

Zustand 1 

Zustand 4 keit. Z. B. müssen wir, um eine beliebige 

Sequenz von drei Aufgaben (A, B, C) 

Zustand 3 

Aufgabe 2 

Aufgabe 1 abzubilden, Zustände für folgende erledigte 

Aufgabenkombinationen erstellen: 

{∅, A, B, C, AB, BC, AC, ABC}. Die Zustandsmenge entspricht der Potenzmenge der 

Aufgaben, welche eine Kardinalität von 2 n besitzt. Leider gibt es für diesen Fall keine 

Unterstützung seitens der UML-Notation, sodass die Zustände ausformuliert werden 

müssen. In der Abbildung ist ein vereinfachtes Beispiel mit nur zwei Unteraufgaben 

dargestellt, bei dem nur vier Zustände zu modellieren sind. Vom Startzustand aus 

können entweder zuerst Aufgabe 1 oder Aufgabe 2 ausgeführt werden. Je nach 

Wahl kann aus dem Zielzustand dann nur noch die verbleibende Aufgabe ausgeführt 

werden. 

Nach der Vorstellung der Umsetzung der temporalen Operatoren im Zustandsübergangsdiagramm, 

werden wir im Folgenden die Umsetzung der dazu orthogonalen Kon- 

57


zepte der Aufgabeneigenschaften vorstellen (siehe Tabelle 3.11). Exemplarisch zeigen 

wir die Transformation der Eigenschaften Optionalität, Iteration und Vorbedingung. 

Zustand 1 

Aufgabe 2 Aufgabe 1 

Zustand 1 

Zustand 1 

Zustand 2 

Zustand 2 

Zustand 3 

Aufgabe 2 

Aufgabe 1 

Aufgabe 1 

[Vorbedingung] 

Optional: Bei optionalen Aufgaben wird im Zustandsübergangsdiagramm 

eine zusätzliche Transition zum Überspringen der Aufgabe 

eingefügt. In der Abbildung links ist eine Sequenz aus zwei 

Aufgaben abgebildet. Die erste Aufgabe soll optional sein, deshalb 

wurde vom Zustand 1 eine zusätzliche Transition für die Ausführung 

der Aufgabe 2 eingefügt. Der Benutzer hat im Zustand 1 

die Wahl, entweder Aufgabe 1 oder Aufgabe 2 auszuführen (und 

damit Aufgabe 1 zu überspringen). 

Iteration: Eine Aufgabe, die mehrfach ausgeführt werden kann, 

wird im Zustandsübergangsdiagramm als Zustand mit einer reflexiven 

Transition dargestellt. Weil die Ausführung der Aufgabe 

zurück auf den Ursprungszustand führt, kann die Aufgabe im 

nächsten Dialogschritt wieder ausgeführt werden. 

Vorbedingung: Eine Aufgabe, die nur unter Vorbedingungen 

ausgeführt werden kann, wird im Zustandsübergangsdiagramm 

über eine Transition beschrieben, die mit einem sogenannten 

Wächterausdruck geschützt wird. Die Transition kann nur durchlaufen 

werden, wenn dieser Wächterausdruck erfüllt ist. In der 

Abbildung ist eine Aufgabe als Transition zwischen zwei Dialogzuständen 

mit einer Vorbedingung der Aufgabe geschützt. Diese 

könnte z. B. eine Aufgabe Hotelreservierung nur zulassen, wenn 

Hotelzimmer zurzeit verfügbar sind. 

3.5.5 Fehlerquellen bei der Dialogmodellierung 

Bei der Erstellung eines Dialogmodells mittels eines Zustandsübergangsdiagramms muss 

gewährleistet sein, dass der endliche Automat auch als Dialog ausführbar ist. Dass dem 

nicht immer so ist, zeigen die folgenden gängigen Fehlerquellen [Dix u. a., 1993]: 

58 

nichtdeterministische Automaten: Wenn von einem Zustand zwei Transitionen zu 

verschiedenen Zielzuständen mit dem gleichen Ereignis (und erfüllten Vorbedingungen) 

existieren, dann ist bei Auslösen dieses Ereignisses der Zielzustand nichtdeterministisch. 

Dieses Problem kann mittels Werkzeugunterstützung beim Erstellungsprozess 

erkannt und vom Modellierer behoben werden. 

Erreichbarkeit: Alle Zustände des endlichen Automaten sollten über eine (möglichst 

kurze) Folge von Transitionen erreicht werden können. Eine Verletzung dieser 

Regel ist zum Beispiel, wenn zwei Zustandsmengen eines Dialogmodells über 

keine Transition verbunden sind. Weil der endliche Automat ein gerichteter Graph

3.6 Präsentationsmodellierung 

ist, können aber auch andere fehlende Transitionen zu einer Unerreichbarkeit eines 

Zustands führen. Dies kann mittels Werkzeugunterstützung überprüft werden. 

Konsistenz: Der Benutzer erwartet, dass Eingaben konsistent von der Anwendung 

verarbeitet werden. Dix u. a. [1993] geben folgendes Beispiel: In einem Texteditor 

rückt die Tab-Taste den Text um einige Leerzeichen ein. Wenn allerdings ein Dialogfenster 

geöffnet wird, kann mit der Tab-Taste zum nächsten Eingabefeld gewechselt 

werden. Diese Änderung der Funktionalität ist inkonsistent, weil sie vom 

Benutzer nicht vorhergesehen wird. Eine konsistente Benutzerführung ist nicht 

automatisch überprüfbar, weil hier die Semantik der Aktionen von Bedeutung ist. 

gefährliche Zustände: In einem Dialog sollen die Zustände grundsätzlich schnell zu 

erreichen sein. Es gibt allerdings Ausnahmen, wenn z. B. eine Aktion die Festplatte 

formatiert, so soll diese nicht versehentlich ausgelöst werden können. Zu diesem 

Zweck kann eine Sicherheitsabfrage der eigentlichen Aktion vorgelagert werden, 

ein zusätzlicher Dialogzustand, bei dem der Benutzer die Wahl hat, im nächsten 

Schritt die Aktion durchzuführen oder doch noch abzubrechen. Diese potenziell 

„gefährlichen“ Zustände können nicht automatisch erkannt werden, weil auch 

hier die Semantik der Aktionen von Bedeutung ist. 


Das Dialogmodell beschreibt die Struktur der möglichen Interaktionen eines Benutzers 

mit einer Anwendung. Wir können aus dem Aufgabenmodell ein Dialogmodell in Form 

eines Zustandsübergangsdiagramms erzeugen, welches zur Laufzeit ausführbar ist und 

den Dialog steuert. Im nächsten Abschnitt werden wir die Präsentationsmodellierung 

vorstellen, um die bis jetzt abstrakt beschriebenen Dialogzustände mit einer Benutzerschnittstelle 

zu versehen. 



Als Vorstufe zur Benutzerschnittstelle wird in der Entwurfsphase das Präsentationsmodell 

erstellt (siehe Abbildung 3.1). Ziel ist, die Interaktionsmöglichkeiten eines Dialogzustands 

zu beschreiben, um aus diesem Modell in einem späteren Schritt eine Benutzerschnittstelle 

zu erzeugen. 

Die Benutzerschnittstelle soll es dem Benutzer ermöglichen aus einem Dialogzustand 

heraus die aktuell möglichen Aufgaben des Aufgabenmodells auszuführen. Dazu muss 

sie mehrere Aspekte kombinieren: 

Sie muss dem Benutzer Interaktionsmöglichkeiten für die aktuell ausgeführten 

Aufgaben anbieten. 

59


abstrakt 

konkret 

Aufgaben & Konzepte 

abstrakte Benutzerschnittstelle (AUI) 

konkrete Benutzerschnittstelle (CUI) 

finale Benutzerschnittstelle (FUI) 

CUI 1 


AUI 

CUI 2 

FUI 1 FUI 2 FUI 3 

Abbildung 3.6: Verfeinerung der Präsentation aus den Aufgaben 

Sie muss dem Benutzer die Möglichkeit geben, mögliche Folgeaufgaben zu starten. 

In den nächsten Abschnitten werden wir die gängige Vorgehensweise präsentieren, 

um aus einem bestehenden Aufgaben- und Dialogmodell eine Benutzerschnittstelle zu 

erzeugen, die diese Aspekte erfüllt. 

3.6.2 Abstraktionsstufen 

UsiXML ist ein Ansatz von Vanderdonckt und Limbourg [2004] zur Erzeugung multikontextueller 

Benutzerschnittstellen. Bei UsiXML kann ein zentrales Aufgabenmodell 

als Grundlage für unterschiedliche Benutzerschnittstellen dienen, z. B. für klassische 

Desktop-Applikationen (Java Swing), für Web-Anwendungen (HTML), für 3D-Anwendungen 

(VRML) oder für Sprachdialogsysteme (VoiceXML). Um dies zu erreichen, wird 

die Erstellung einer Benutzerschnittstelle in drei Schritte zerlegt (siehe Abbildung 3.6). 

Nach jedem Schritt entstehen Modelle der Benutzerschnittstelle, welche von den Modellen 

der vorigen Schicht abgeleitet sind. Diese Beziehungen sind auf der rechten Seite 

der Abbildung dargestellt. Die einzelnen Verfeinerungsschritte werden wir im Folgenden 

vorstellen. 

Abstrakte Benutzerschnittstelle 

Aus dem Aufgabenmodell wird im ersten Schritt eine abstrakte Benutzerschnittstelle erstellt. 

In diesem Schritt ist zuerst ein Dialogmodell für das Aufgabenmodell zu erstellen 

(welches wir bereits vorgestellt haben) und anschließend für jeden Dialogzustand eine 

60


XML-Beschreibung der abstrakten Interaktionsmöglichkeiten zu erzeugen. Diese zeichnen 

sich dadurch aus, dass die Elemente der Benutzerschnittstelle unabhängig von der 

Sinnesmodalität 24 beschrieben werden. Die abstrakte Benutzerschnittstelle ist die Menge 

der XML-Beschreibungen aller Dialogzustände. 

UsiXML beschreibt die Benutzerschnittstelle eines Dialogzustands als XML-Baum, die 

Elemente des Baums gehören entweder den abstrakten Interaktionselementen oder 

den abstrakten Gruppierungselementen an. 

Abstrakte Interaktionselemente bestimmen eine Interaktionsmöglichkeit und sind 

die Blattelemente der XML-Benutzerschnittstellenbeschreibung, zum Beispiel: 

– Auswahl: Der Benutzer kann eine Auswahl aus zwei oder mehr Möglichkeiten 

treffen. 

– Ausgabe: Eine Ausgabe von der Anwendung, die der Benutzer nicht verändern 

kann. 

– Eingabe: Ein Eingabeelement, das vom Benutzer bearbeitet werden kann. 

– Kommando: Ein Interaktionselement, mit dem der Benutzer eine Aktion auslösen 

kann. 

Abstrakte Gruppierungselemente dienen der Anordnung von Interaktionselementen 

und sind die Nicht-Blattelemente in der XML-Benutzerschnittstellenbeschreibung, 

zum Beispiel: 

– Container: Die Unterelemente sollen in beliebiger Reihenfolge zusammen in 

der Benutzerschnittstelle erscheinen. 

– Gruppe: Die Unterelemente sollen in angegebener Reihenfolge zusammen in 

der Benutzerschnittstelle erscheinen. 

Das folgende Beispiel fügt einige der oben genannten Interaktionselemente in eine 

XML-Hierarchie zusammen: 

Listing 3.5: Beispiel einer abstrakten Benutzerschnittstelle 

1 

2 

3 

4 

5 

6 

7 

8 

Dieser Teil einer abstrakten Benutzeroberfläche beschreibt die Interaktionselemente 

für den Dialogzustand nicht authentifiziert. In Zeile 5 wird eine Eingabemöglichkeit 

definiert, die dem Benutzer erlaubt, ein Passwort einzugeben. Das Attribut id wurde 

zum Verständnis der Elemente eingefügt. In Zeile 4 wird noch ein Ausgabeelement eingefügt, 

welche eine erklärende Beschriftung zum Eingabefeld ausgeben soll. In Zeile 

24 Sehen, Hören, Riechen, Schmecken und Fühlen 

61


3 und 6 werden die beiden eingeschlossenen Interaktionselemente als zusammengehörige 

Gruppe definiert, die später möglichst zusammen und in dieser Reihenfolge in 

der Oberfläche erscheinen sollen. Zeile 2 beschreibt eine Überschrift und Zeile 7 eine 

Möglichkeit, die Eingaben abzuschicken. Die Zeilen 1 und 8 fassen die gesamte Benutzerschnittstelle 

als Gruppe zusammen. 

Eine abstrakte Benutzerschnittstelle beschreibt nur, welche Interaktionselemente der 

Benutzer präsentiert bekommen soll, sie beschreibt nicht, wie diese später aussehen. 

Deshalb muss auch nur eine abstrakte Benutzerschnittstelle erstellt werden, welche als 

Grundlage für alle folgenden Benutzerschnittstellen dient. 

Konkrete Benutzerschnittstelle 

Die nächste Verfeinerungsstufe, die UsiXML vorsieht, ist die konkrete Benutzerschnittstelle. 

In dieser Stufe muss sich der Modellierer festlegen, für welche Modalität und 

welchen Kontext die Benutzerschnittstelle umgesetzt werden soll. Dazu werden die Interaktionselemente 

der abstrakten Benutzerschnittstelle durch kontextbezogene Interaktionselemente 

ersetzt. Für eine zwei-dimensionale Benutzeroberfläche können beispielsweise 

die Gruppierungen in vertikale oder horizontale Gruppierungen umgesetzt 

werden. Die Ein- und Ausgaben werden nach den Möglichkeiten des ausgewählten 

Kontextes verfeinert, beispielsweise in Knöpfe, Eingabefelder und Überschriften. 

Im folgenden Beispiel wurde aus der abstrakten Benutzerschnittstelle eine konkrete 

Benutzerschnittstelle erzeugt. Um die Beziehung zum Beispiel in Listing 3.5 zu verdeutlichen, 

sind die Namen der Interaktionselemente aus dem abstrakten Basistyp und der 

konkreten Ausprägung für den gewählten Kontext zusammengesetzt: 

Listing 3.6: Beispiel einer konkreten Benutzerschnittstelle 

1 

2 

3 

4 

5 

6 

7 

8 

Auf dieser Abstraktionsstufe (siehe Übersicht in Abbildung 3.6) können mehrere kontextbezogene 

Benutzerschnittstelle definiert werden, die parallel vom Modellierer aus 

der abstrakten Benutzerschnittstelle erzeugt wurden. 

Finale Benutzerschnittstelle 

Im letzten Schritt sieht UsiXML die Erzeugung einer plattformbezogenen Benutzerschnittstelle 

vor, der sogenannten finalen Benutzerschnittstelle. Dies bedeutet, dass aus 

der kontextbezogenen konkreten Benutzerschnittstelle aus dem letzten Schritt eine Benutzerschnittstelle 

für eine Zielplattform erstellt wird, für eine zwei-dimensionale Benutzeroberfläche 

beispielsweise Java Swing oder HTML. 

62


Eine Umsetzung als finale Benutzerschnittstelle in HTML könnte folgendermaßen 

aussehen: 

Listing 3.7: Beispiel einer finalen Benutzerschnittstelle 

1 

2 

3 

4 

5 

6 

7 

8 


Beim Erzeugen einer Benutzerschnittstelle über die abstrakten und konkreten Zwischenschritte 

steigert sich in den Präsentationsmodellen der Detailgrad, die Kontextunabhängigkeit 

wird allerdings kleiner. Wenn z. B. die Anforderung besteht, eine mit dem 

UsiXML-Ansatz erstellte Desktop-Anwendung auch als Web-Anwendung zu entwerfen, 

dann muss nur die bestehende konkrete Benutzerschnittstelle in eine neue finale Benutzerschnittstelle 

für Web-Anwendungen umgeformt werden. 

Weil der Kontext der Benutzerschnittstellen in dieser Arbeit festgelegt ist – die Erstellung 

von Benutzeroberflächen für Web-Anwendungen – werden wir nicht von allen 

Abstraktionstufen Gebrauch machen. Nach der Aufgabenmodellierung werden wir 

direkt kontextbezogene konkrete Benutzerschnittstellen für zwei-dimensionale Benutzeroberflächen 

erstellen, welche, im Gegensatz zu finalen HTML-Benutzerschnittstellen, 

gut geeignet sind, um unabhängig von der Zielplattform zu sein. Zukünftig könnten 

dann auch neue Technologien, wie z. B. Flash oder Silverlight, unterstützt werden. 

Im Anhang A sind die in dieser Arbeit verwendeten abstrakten und konkreten Interaktionselemente 

zusammengefasst. Die Anbindung der Benutzerschnittstelle an das 

Domänenmodell, z. B. die Verbindung des Passworteingabefeldes mit einer Variablen 

oder die Erzeugung eines Ereignisses durch den Knopf, werden wir an späterer Stelle 

erörtern. 


Wir haben gezeigt, welche Modelle aus dem Bereich der Softwareentwicklung und der 

Human Computer Interaction (HCI) im Entwicklungsprozess einer Web-Anwendung erstellt 

und kombiniert werden können. Einen besonderen Fokus haben wir auf die Aufgabenmodellierung 

gelegt. Sie wird im Zentrum unseres Ansatzes für die Erstellung 

einer Benutzerschnittstelle stehen. Als Nachteil des hier vorgestellten klassischen Entwicklungsprozesses 

bleibt festzuhalten, dass die Benutzerschnittstelle zwar auf einem 

Aufgabenmodell basiert, die Aufgabenstruktur allerdings bei der semi-automatischen 

Transformation in ein Dialogmodell verloren geht. Bei einer Änderung des Aufgabenmodells 

in einer weiteren Entwicklungsiteration müssten auch ein neues Dialogmodell 

63


und eine neue Benutzerschnittstelle erstellt werden. Im nächsten Kapitel werden wir 

deshalb den Kern dieser Arbeit vorstellen, ein kombiniertes Aufgaben-, Dialog- und 

Präsentationsmodell, welches zur Laufzeit ausgeführt wird. 

64

Teil II 

Konzepte 

65

Kapitel 4 

Überblick über den Lösungsansatz 

Inhalt 

4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 

4.2 Aufgabenmodell als Basis des Interaktionsmodells . . . . . . . . . . . . 68 

4.3 Erweiterung des Interaktionsmodells . . . . . . . . . . . . . . . . . . . 69 

4.4 Laufzeitsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

4.5 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 

4.1 Einleitung 

In den vorigen Kapiteln haben wir gezeigt, dass sich mit den existierenden Ansätzen 

bereits Web-Anwendungen mit den Modellen des Softwareengineering und der HCI 

erstellen lassen (siehe Abbildung 3.1). Zwischen den beiden Modellierungsansätzen gibt 

es aber noch einen entscheidenden Unterschied: 

Bei der Verwendung der UML für den Bereich des Softwareengineerings basieren 

die Modelle auf einem zugrundeliegenden zentralen Datenmodell. Die Diagramme 

der UML modellieren jeweils Teilaspekte des zentralen Datenmodells und 

blenden andere Teile aus. Wenn zwei Diagramme auf die gleichen Informationen 

des zentralen Datenmodells zugreifen, z. B. das Klassendiagramm und das 

Sequenzdiagramm auf einen Klassennamen, dann beeinflusst eine Änderung das 

jeweils andere Diagramm ebenfalls. Die Diagramme der UML sind synchronisiert. 

Bei den Modellen der HCI (Aufgabenmodell, Dialogmodell und Präsentationsmodell) 

gibt es noch kein zugrundeliegendes Datenmodell. Bei der Transformation 

von einem Aufgabenmodell zu einem Dialogmodell werden z. B. die temporalen 

Relationen der Aufgaben in komplexe Zustands- und Transitionsmengen zerlegt. 

Diese Transformation ist nicht umkehrbar, bei einer Änderung am Dialogmodell 

besteht keine Möglichkeit, diese Änderung in den temporalen Relationen des Aufgabenmodells 

einfließen zu lassen. Die Modelle der HCI sind unsynchronisiert. 

Wir wollen im Folgenden ein zentrales Interaktionsmodell vorstellen, welches die 

Informationen des Aufgaben-, des Dialog- und des Präsentationsmodells vereint. Das 

Aufgabenmodell ist dann z. B. nur eine Sicht auf das Interaktionsmodell, in der nur die 

67

4 Überblick über den Lösungsansatz 

aufgabenrelevanten Teile dargestellt werden. Vorteil des zentralen Modells ist die freie 

Wahl der Bearbeitungsreihenfolge der Modelle. Während beim klassischen Ansatz zuerst 

ein Aufgabenmodell komplett erstellt werden muss, danach ein Dialogmodell und 

schließlich das Präsentationsmodell, haben wir jetzt die Möglichkeit, die Modelle parallel 

zu entwickeln. Die Bearbeitung der HCI-Modelle gleicht sich damit der Bearbeitung 

der Softwareengineering-Modelle an, wo eine parallele Bearbeitung der Diagramme 

möglich ist. 

Als Basis unseres zentralen Interaktionsmodells dient ein an unsere Bedürfnisse angepasstes 

Aufgabenmodell, welches wir im weiteren Verlauf um Dialog- und Präsentationsaspekte 

erweitern werden. 

4.2 Aufgabenmodell als Basis des Interaktionsmodells 

Im Abschnitt 3.4 haben wir bereits die existierenden Methoden der Aufgabenmodellierung 

vorgestellt und die Gemeinsamkeiten zusammengefasst. Wir wollen diese Eigenschaften 

aufgreifen und in Kapitel 5 eine Methode zur Aufgabenmodellierung für 

Web-Anwendungen vorstellen. Dazu werden wir nicht nur die bestehenden Methoden 

um Aspekte für Web-Anwendungen erweitern, sondern auch für die existierenden gemeinsamen 

Eigenschaften ein Laufzeitverhalten definieren. 

4.2.1 Temporale Operatoren 

Die bereits bekannten temporalen Operatoren sind bei den klassischen Aufgabenmodellen 

nur qualitativ definiert, z. B. ist unklar, ob zwei parallel zu bearbeitende Aufgaben 

über die gesamte Ausführungsdauer parallel bearbeitet werden müssen, oder ob 

die Aufgaben nur parallel angefangen werden müssen, dann aber eine Aufgabe vor 

der anderen beendet werden kann. Wir werden die existierenden temporalen Operatoren 

für unser Aufgabenmodell mit der temporalen Logik von Allen [1983] eindeutig 

definieren, damit das Laufzeitsystem die Aufgabenmodelle später konsistent ausführen 

kann. 

Zusätzlich werden wir noch weitere temporale Operatoren einführen. Klassische Aufgabenmodelle 

verwenden nur eine kleine Menge temporaler Operatoren, um die Bearbeitungsreihenfolge 

der Aufgaben möglichst abstrakt zu beschreiben. Weil wir die Aufgabenmodelle 

speziell für Web-Anwendungen definieren, können wir temporale Operatoren 

einführen, die auf die Generierung dieser Benutzerschnittstellen zugeschnitten 

sind. 

4.2.2 Unterbrechbarkeit 

Ein weiteres Problem bei der Modellierung von Web-Anwendungen ist in der Zustandslosigkeit 

des Webs begründet. Ein Dialog, wie z. B. ein Fahrkartenkauf, wird das Aufgabenmodell 

für einen Benutzer ausführen, d. h., die einzelnen Aufgaben des Aufgabenmodells 

werden den temporalen Operatoren gemäß bearbeitet und der Zustand wird 

von Dialogschritt zu Dialogschritt auf dem Server verwaltet. Problematisch ist dabei 

68

4.3 Erweiterung des Interaktionsmodells 

die Zustandslosigkeit des Webs, weil der Benutzer jederzeit den angefangenen Dialog 

verlassen kann und ein gestartetes Aufgabenmodell gelöscht werden würde. Wir werden 

dem Laufzeitsystem die Möglichkeit geben, unterbrochene Aufgabenmodelle zu 

persistieren. Allerdings wird dabei wird nicht zwingend das komplette Aufgabenmodell 

gespeichert, der Modellierer kann im Aufgabenmodell für Teilbäume definieren, 

ob diese persistiert werden sollen oder verworfen werden. Dies ist z. B. bei Aufgaben 

sinnvoll, deren erneute Ausführung mit wenig Aufwand für den Benutzer verbunden 

ist. 

4.2.3 Rollenkonzept 

Für Web-Anwendungen, auf die verschiedene Nutzergruppen über einen gemeinsamen 

Einstiegspunkt Zugriff haben, ist es sinnvoll, ein Rollenkonzept in die Aufgabenmodellierung 

zu integrieren. Auch hier werden wir die Semantik der Benutzerrolle aus 

den klassischen Aufgabenmodellen genauer definieren, z. B. welche Konsequenzen verschiedene 

Benutzerrollen entlang der Hierarchie für eine Blattaufgabe haben. 

4.3 Erweiterung des Interaktionsmodells 

Nachdem wir das Aufgabenmodell als Basis für unser Interaktionsmodell beschrieben 

haben, werden wir in Kapitel 6 dialog- und präsentationsspezifische Erweiterungen integrieren. 

4.3.1 Dialogmodell 

Um zu einem Interaktionsmodell zu gelangen, werden wir zuerst zeigen, wie aus dem 

Aufgabenmodell zur Laufzeit ein rudimentärer Dialog erzeugt werden kann. In weiteren 

Schritten werden wir dem Interaktionsmodell Dialoginformationen hinzufügen, 

um die Ausführung des Aufgabenmodells zu optimieren. 

An dieser Stelle können wir dann einen Dialog generieren, der, basierend auf unserem 

Aufgabenmodell, die Struktur der Benutzerschnittstelle vorgibt. Es fehlt allerdings 

noch die Beschreibung der Präsentation und die Integration mit dem Domänenmodell. 

4.3.2 Präsentationsmodell 

Im Gegensatz zu den klassischen Ansätzen werden wir nicht Aufgaben- und Dialogmodell 

in ein Präsentationsmodell umwandeln, sondern alle drei Modelle in einem Interaktionsmodell 

bündeln. Dies macht es notwendig, die Präsentation nicht mehr seitenbasiert, 

sondern aufgabenbasiert zu definieren. Zu jeder Aufgabe muss vom Modellierer 

ein Fragment der Benutzerschnittstelle definiert werden, aus denen das Laufzeitsystem, 

basierend auf dem Dialogzustand, die Benutzerschnittstelle generiert. Wir werden dazu 

eine hierarchische Komposition der Benutzerschnittstelle vorstellen, mit der reale Web- 

Anwendungen umgesetzt werden können. 

69

4 Überblick über den Lösungsansatz 

4.3.3 Anbindung an das Domänenmodell 

Es fehlt noch die Anbindung an das Domänenmodell, damit die Eingaben des Benutzers 

von der Anwendung verarbeitet werden können und die Ausgaben in der Benutzerschnittstelle 

erscheinen. Das Domänenmodell ist dabei nicht Teil des Interaktionsmodells, 

sondern wird parallel entwickelt; der Drei-Schichten-Architektur folgend, besitzt 

das Domänenmodell (Anwendungsschicht) keine Beziehungen zum Interaktionsmodell 

(Präsentationsschicht). 

Wir werden zeigen, wie das Interaktionsmodell auf das Domänenmodell zugreifen 

kann. Dabei werden wir die Aufgabenhierarchie ausnutzen, um den Fragmenten der 

Benutzerschnittstelle nur Zugriff auf den Teil des Domänenmodells zu geben, den sie 

für die Aufgabenausführung auch benötigen. Diese zusätzliche Kapselung zwingt den 

Modellierer der Präsentation, die Vorgaben des Aufgabenmodells umzusetzen. 

4.4 Laufzeitsystem 

Zusätzlich zum Interaktionsmodell werden wir in Kapitel 7 auch die Architektur des 

Laufzeitsystems vorstellen, welches Basisdienste bereitstellt und die Instanzen der Interaktionsmodelle 

in einer Oberfläche vereint. Während wir bei der Definition der Modelle 

auch schon das Laufzeitverhalten der Modelleigenschaften festgelegt haben, werden 

wir an dieser Stelle die Architektur vorstellen, die dieses Verhalten umsetzt. Dabei 

werden wir uns an das Modularitätsprinzip halten, um die Architektur in unabhängige 

Module aufzuteilen. 

4.5 Beispiel 

Bei der Herleitung unseres Interaktionsmodells werden wir in dieser Arbeit ein durchgängiges 

Beispiel verwenden. Ziel ist die Erstellung eines Kleinanzeigenmarktes als 

Web-Anwendung. Benutzer können durch die Liste der Kleinanzeigen blättern und Details 

zu einer Kleinanzeige einblenden lassen. Neue Kleinanzeigen können in einem 

geführten Dialog erstellt werden. Eine Suchmaske erlaubt es dem Benutzer, nur die 

Kleinanzeigen eines gewählten Suchkriteriums anzuzeigen. 

Das Beispiel wird im Laufe der Arbeit die Möglichkeiten des Interaktionsmodells beschreiben. 

Bei jeder neu vorgestellten Modelleigenschaft wird das Beispiel ebenfalls 

erweitert. Zur Referenz ist das Beispiel in Anhang B komplett aufgeführt. 

70

Kapitel 5 

Aufgabenbasiertes Interaktionsmodell für 

Web-Anwendungen 

Inhalt 

5.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

5.2 Aufgabenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 

5.3 Kardinalität von Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . 73 

5.4 Hierarchiebeziehungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

5.5 Der Aufgabentyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 

5.6 Unterbrechbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

5.7 Zugriffskontrolle über Rollenkonzept . . . . . . . . . . . . . . . . . . . 91 

5.8 Wiederverwendbarkeit von Aufgabenhierarchien . . . . . . . . . . . . 95 



In diesem Kapitel werden wir die Basis für unser zentrales Interaktionsmodell definieren: 

ein erweitertes Aufgabenmodell, das die bestehenden Varianten der Aufgabenmodelle 

zusammenfasst. Weil dieses erweiterte Aufgabenmodell später auch zur Laufzeit 

für die Dialoggenerierung eingesetzt wird, werden wir die Auswirkungen der Aufgabenattribute 

und der temporalen Operatoren zwischen den Aufgaben anhand von 

Laufzeitaspekten, wie z. B. Start- und Endzeitpunkt konkret definieren. Auch die Menge 

der temporalen Operatoren werden wir im Gegensatz zur klassischen Aufgabenmodellierung 

erweitern, um ein ausdrucksstarkes und detailliertes Aufgabenmodell zu 

erstellen. Trotz der Fokussierung auf das Laufzeitverhalten wird dieses Kapitel nur die 

Elemente des Aufgabenmodells vorstellen, erst im nächsten Kapitel wird diese Basis 

dann um Dialoginformationen erweitert. 

5.2 Aufgabenmodell 

Wie im Kapitel 3.4 beschrieben, existieren Aufgabenmodelle für verschiedene Bereiche 

mit verschiedenen Ausprägungen. Um Aufgabenmodelle für Web-Anwendungen zu erstellen, 

werden wir deshalb in diesem Kapitel die Ansätze aufgreifen und erweitern, um 

71

5 Aufgabenbasiertes Interaktionsmodell für Web-Anwendungen 

Kontaktinformationen 

angeben 

Abbildung 5.1: Beispiel Aufgabenmodell – Standard 

ein neues Aufgabenmetamodell zu definieren. Auf Basis dieses Aufgabenmetamodells 

lassen sich Aufgabenmodelle erstellen, die die Besonderheiten von Web-Anwendungen 

berücksichtigen und die sich mit einem Laufzeitsystem ausführen lassen. 

Anhand eines Beispiels werden die Bestandteile des Aufgabenmetamodells bestimmt. 

Von einem Benutzer sollen die Kontaktinformationen (z. B. Telefonnummer) abgefragt 

werden, Abbildung 5.1 zeigt diese Aufgabe in ihrer abstraktesten Form. Im Augenblick 

besitzt die Aufgabe nur das Attribut name. Zusätzlich muss jede Aufgabe innerhalb 

des Aufgabenmodells eindeutig identifizierbar sein, jede Aufgabe besitzt deshalb auch 

noch ein Attribut id, welches die Aufgabe eindeutig identifiziert. Dieses ist vorbelegt 

mit dem Aufgabennamen und muss nur angepasst werden, wenn im Aufgabenmodell 

zwei Aufgaben mit dem gleichen Namen existieren. Im vorliegenden Fall ist die id gleich 

dem Namen und wird deshalb nicht explizit dargestellt. 

Diese Aufgabe ist allerdings noch sehr generisch und sollte sowohl in ihrer Hierarchie 

als auch in ihrer Beschreibung noch weiter verfeinert werden. Die nächsten Abschnitte 

beschreiben die für unseren Ansatz sinnvollen Verfeinerungen. 

5.2.1 Das Ausführen von Aufgaben 

Da es sich bei dem Ausführen von Aufgaben um temporale Operationen handelt, wollen 

wir die Ausführung anhand der Start- und Endzeitpunkte auf einer Zeitachse betrachten 

und dazu die Grundlagen der temporalen Intervalle von [Allen, 1983] aufgreifen. 

Sei start(X ) der Startzeitpunkt einer Aufgabe X und ende(X ) der Endzeitpunkt von 

X . Sowohl start(X ) als auch ende(X ) sind undefiniert, solange die Aufgabe X noch nicht 

ausgeführt wurde. Um die temporale Integrität zu gewährleisten, muss für start(X ) und 

ende(X ) immer gelten: 

ende(X ) = ∅ → start(X ) = ∅ ∧ start(X ) ≤ ende(X ) (5.1) 

Wenn eine Aufgabe beendet wurde, so muss ein Startzeitpunkt existieren und vor 

oder auf dem Endzeitpunkt liegen (Bedingung 5.1). 

5.2.2 Der Aufgabenkontext 

Aus Sicht eines Laufzeitsystems ist das Aufgabenmodell statisch, für jeden Benutzer 

wird anfangs eine identische Instanz des Aufgabenmodells erstellt. Mit dem Anfangs- 

72

5.3 Kardinalität von Aufgaben 

und Endzeitpunkt einer Aufgabe haben wir allerdings die ersten Elemente des Aufgabenkontexts 

beschrieben, welche die zur Laufzeit variablen Werte einer Aufgabe aufnimmt 

und damit den Aufgabenzustand definiert. Bei der Definition der Laufzeitarchitektur 

werden wir auf den Aufgabenkontext ausführlich eingehen, an dieser Stelle ist 

vor allem entscheidend, dass sich eine Aufgabeninstanz zur Laufzeit aus zwei getrennten 

Teilen zusammensetzt: 

Einer Aufgabendefinition mit statischen Werten aus dem Aufgabenmodell (z. B. 

Aufgabenname) 

Einem Aufgabenkontext mit laufzeitabhängigen Werten (z. B. Startzeitpunkt) 

Die Aufgabenkontexte werden wir an dieser Stelle nicht weiter bei der Modellierung 

der Aufgabenmodelle betrachten. Sie helfen aber, wie im Beispiel der Start- und Endzeitpunkte, 

die Elemente des Aufgabenmodells anhand von laufzeitabhängigen Werten 

zu definieren. 

5.3 Kardinalität von Aufgaben 


Unter der Kardinalität versteht man in der Mathematik die Mächtigkeit einer Menge, 

also die Anzahl Elemente einer Menge. Die Definition einer Kardinalität bei Aufgaben 

hilft, Aussagen über die Anzahl an möglichen und notwendigen Aufgabeniterationen 

zu treffen. Zu diesem Zweck werden zwei Kardinalitäten definiert. 

Die minimale Kardinalität (minKardinalität) definiert die Anzahl der notwendigen 

Aufgabeniterationen, also die minimale Anzahl der Iterationen, die eine Aufgabe wiederholt 

werden muss, um als erledigt zu gelten. Der Wertebereich beträgt N0, also alle 

natürlichen Zahlen von null bis unendlich. 

Die maximale Kardinalität (maxKardinalität) definiert die Anzahl der möglichen Aufgabeniterationen, 

also die maximale Anzahl der Iterationen, die eine Aufgabe wiederholt 

werden kann. Der Wertebereich beträgt N + ∪{∞}, also alle natürlichen Zahlen von 

1 bis unendlich einschließlich des Symbols für unendlich 25 . 

Mit diesen beiden Kardinalitäten können die sinnvollen Iterationsmöglichkeiten definiert 

werden. Exotischere Definitionen, wie z. B. „die Anzahl der Aufgabeniterationen 

soll ungerade sein“ können später als Ausführungsbedingungen hinzugefügt werden. 

In den meisten Fällen ist die Definition der beiden Kardinalitäten bereits zu fein, weshalb 

sich einige vordefinierte Werte anbieten. Falls keine Kardinalitäten explizit angegeben 

werden, dann werden die Aufgaben mit folgenden Werten initialisiert: minKardinalität 

= 1, maxKardinalität = 1. Die Aufgabe kann und muss genau einmal durchgeführt 

werden, das entspricht auch dem erwarteten Verhalten in Abbildung 5.1. Die 

folgenden beiden Bezeichner können (auch in Kombination) verwendet werden, um 

die Vorbelegung zu verändern und die gängigsten Kardinalitätsanforderungen abzudecken: 

25 Das Unendlichzeichen wird in UML beispielsweise als „∗“ ausgedrückt, ER-Diagramme verwenden meist ein 

„n“. 

73



angeben 

Kardinalität = 1…5 

Abbildung 5.2: Beispiel Aufgabenmodell – Kardinalitäten 

Optional Die Aufgabe wird als optional gekennzeichnet, sie muss nicht ausgeführt werden, 

sondern kann z. B. übersprungen werden. minKardinalität = 0 

Iterativ Eine iterative Aufgabe kann, je nach Benutzerwunsch, beliebig häufig ausgeführt 

werden. maxKardinalität = ∞ 

Bei einer optionalen übersprungenen Aufgabe ist der Zeitpunkt, an dem übersprungen 

wurde, gleichzeitig Start- und Endzeitpunkt. Es gilt start(X ) = ende(X ) = ∅, die 

Bedingung 5.1 ist weiterhin erfüllt. Falls eine Aufgabe mehrfach iteriert wird, dann definiert 

start(X ) den Startzeitpunkt der ersten Iteration und ende(X ) den Endzeitpunkt 

der letzten Iteration. 


Abbildung 5.2 zeigt die um Minimal- und Maximalkardinalität erweiterte Ursprungsaufgabe. 

Es soll mindestens einmal die Kontaktinformationen eingegeben werden, maximal 

sollen fünf Kontaktinformationen möglich sein, z. B. verschiedene Anschriften und 

Telefonnummern. 

5.4 Hierarchiebeziehungen 

Gemäß den klassischen Ansätzen aus Abschnitt 3.4 werden Aufgaben in Unteraufgaben 

verfeinert. Eine Oberaufgabe kann in eine beliebige Anzahl von Unteraufgaben verfeinert 

werden (siehe Bild 5.3). Die Unteraufgaben können wiederum verfeinert werden, 

sodass ein Aufgabenbaum entsteht. 

Die Semantik der Hierarchiebeziehung der Oberaufgabe zu den Unteraufgaben wird 

eine hohe Bedeutung beigemessen. In allen Fällen wird durch eine hierarchische Verfeinerung 

eine Komposition ausgedrückt. Wir verwenden hier den Kompositionsbegriff 

aus der UML [OMG, 2005], welche die Beziehung eines Ganzen zu seinen Teilen beschreibt: 

74 

Eine Unteraufgabe gehört nur zu genau einer Oberaufgabe 

Die Oberaufgabe bestimmt den Lebenszyklus der Unteraufgaben 

Eine Unteraufgabe kann nicht für sich alleine existieren

Oberaufgabe 

Unteraufgabe Unteraufgabe 

Unteraufgabe 

Abbildung 5.3: Allgemeine Hierarchie 


Wir werden in den nächsten Abschnitten durch Bedingungen – basierend auf Start- und 

Endzeitpunkt der Aufgaben – die Kompositionseigenschaften sicherstellen. Zusätzlich 

zum Kompositionsbegriff der UML, welche keine Aussage über die Semantik der Beziehung 

des Ganzen zu seinen Teilen trifft (z. B. die Reihenfolge der Teile), wollen wir 

verschiede Ausprägungen der Hierarchiebeziehung definieren, welche entscheiden, ob 

und in welcher Reihenfolge die Unteraufgaben ausgeführt werden. An dieser Stelle 

werden wir die klassischen Hierarchiebeziehungen der Aufgabenmodellierung aufgreifen 

und um Beziehungen erweitern, die für die Modellierung von Benutzerschnittstellen 

sinnvoll sind. 

5.4.1 Allgemeine Hierarchiebedingungen 

Wir werden unsere Hierarchiebeziehungen als Relation zwischen einer Aufgabe und 

ihren Unteraufgaben definieren 26 . Sei A die Oberaufgabe und A1 bis An die Unteraufgaben. 

Aufgrund der Kompositionseigenschaft gilt bei allen Hierarchiebeziehungen die 

allgemeine Bedingung: 

∀Ai ∈ {A1, ... , An} ( 

(start(Ai) = ∅ → start(A) ≤ start(Ai)) ∧ 

((ende(A) = ∅ ∧ start(Ai) = ∅) → (ende(Ai) = ∅ ∧ ende(Ai) ≤ ende(A))) 

) 

(5.2) 

Alle Unteraufgaben einer Oberaufgabe dürfen erst gestartet werden, wenn die Oberaufgabe 

gestartet wurde. In der letzten Klausel wird sichergestellt, dass alle gestarteten 

Unteraufgaben beim Beenden der Oberaufgabe vorher beendet wurden. Dies lässt viel 

Spielraum für die Ausführung der Unteraufgaben, die nächsten Abschnitte werden diesen 

in verschiedenen Varianten sinnvoll einschränken. 

26 Weitere formale Definitionen auf Basis von temporalen Beziehungen finden sich unter [Dittmar, 2000] und 

[Dittmar, 2002]. Im Gegensatz zu unserem Vorgehen werden dort allerdings binäre Verknüpfungen zwischen 

zwei Aufgaben behandelt, wir werden die Verknüpfung einer Aufgabe mit beliebig vielen Unteraufgaben betrachten. 

75


5.4.2 Ordnung der Unteraufgaben 

Bevor wir uns den verschiedenen Ausprägungen der Hierarchiebeziehungen zuwenden, 

wollen wir zuerst eine weitere allgemeine Bedingung definieren, die bei allen Beziehungen 

optional verwendet werden kann und das Verhalten bezüglich der Ordnung 

der Unteraufgaben ändert. Unteraufgaben können entweder strikt geordnet oder in 

beliebiger Reihenfolge ausgeführt werden. Wir definieren deshalb das Attribut Ordnung 

für Beziehungen, welches zwei Werte annehmen kann: 

beliebig Die Reihenfolge, in der die Unteraufgaben ausgeführt werden, unterliegt keiner 

Einschränkung. Der Benutzer muss bei der Ausführung des Aufgabenmodells 

aus den möglichen Unteraufgaben wählen. 

strikt Die Reihenfolge, in der die Unteraufgaben ausgeführt werden, ist durch die Position 

in der Menge der Unteraufgaben festgelegt. Die zweite Unteraufgabe kann 

erst begonnen werden, nachdem die erste Unteraufgabe begonnen wurde. 

Für die beliebige Ordnung ist keine Änderung der allgemeinen Hierarchiebedingungen 

(5.2) notwendig, für die strikte Ordnung muss folgende Bedingung immer erfüllt 

sein: 

∀Ai ∈ {A2, ... , An}, ∀Aj ∈ {A1, ... , Ai−1} ( 

start(Ai) = ∅ → start(Aj) = ∅ ∧ start(Aj) ≤ start(Ai) 

) 

(5.3) 

Die Startzeitpunkte aller Unteraufgaben A1 bis Ai−1 müssen vor oder auf dem Startzeitpunkt 

von Ai liegen. Diese Bedingung erzwingt auch, dass die Startzeitpunkte aller 

Unteraufgaben vor Ai definiert sein müssen, bevor Ai gestartet werden kann. Daraus 

folgert, das zuerst start(A1) definiert sein muss, also entweder gestartet oder übersprungen, 

danach start(A2), usw. 

Damit die Unterscheidung strikt/beliebig für alle Ausprägungen der Hierarchiebeziehungen 

verwendbar ist, wurden nur die Startzeitpunkte und nicht die Endzeitpunkte 

in der Bedingung berücksichtigt. Wie wir sehen werden, ist die strikte Ordnung auch 

bei überlappenden oder parallelen Unteraufgaben sinnvoll. Diese Flexibilität würden 

wir aufgeben, wenn wir in der Ordnungsbedingung den Start einer Unteraufgabe vom 

Beenden der vorherigen Unteraufgabe abhängig gemacht hätten. 

Die Ordnung der Unteraufgaben kann für jede Hierarchiebeziehung an jeder Stelle 

des Aufgabenmodells vom Modellierer angegeben werden, d. h., jede Hierarchiebeziehung 

steht als geordnete oder beliebige Version dem Modellierer zur Verfügung. 

Aus der Praxis hat sich gezeigt, dass für die einzelnen Ausprägungen der Hierarchiebeziehungen 

entweder die strikte oder die beliebige Ordnung die „intuitive“ Wahl 

ist. Deshalb werden wir für die einzelnen Hierarchiebeziehungen sinnvolle Ordnungen 

vorgeben, die dann vom Modellierer nur in Ausnahmefällen angepasst werden müssen, 

Näheres dazu im nächsten Abschnitt. 

76

5.4.3 Ausprägungen der Hierarchiebeziehungen 


In den nächsten Abschnitten werden wir untersuchen, wie die allgemeine Hierarchiebeziehung 

(Bedingung 5.2) zu spezialisierten Hierarchiebeziehungen erweitert werden 

kann. Diese spezialisierten Hierarchiebeziehungen (im Folgenden Ausprägungen genannt) 

besitzen jeweils eine definierte temporale Semantik für die Ausführung der Unteraufgaben. 

Im Gegensatz zur klassischen Aufgabenmodellierung (siehe Kapitel 3.4), 

wollen wir das Aufgabenmodell zur Laufzeit weiterverwenden, um daraus den Dialog 

zwischen Benutzer und Web-Anwendung zu erzeugen. Dazu werden wir zum einen für 

die Ausprägungen der klassischen Hierarchiebeziehungen das Laufzeitverhalten festlegen, 

zum anderen werden wir neue, dialogorientierte Hierarchiebeziehungen aufnehmen. 

Folgende Ausprägungen werden wir vorstellen: 

Sequenz 

Selektion 

Parallel 

Überlappend 

Verschachtelt 

Arbiträr 

Jede Ausprägung ist in einer strikten und in einer beliebig geordneten Variante verwendbar, 

sodass wir insgesamt zwölf Ausprägungen für die Aufgabenmodellierung zur 

Verfügung haben. Das Laufzeitverhalten werden wir über zusätzliche Bedingungen bezüglich 

der Start- und Endzeitpunkte definieren, die allgemeine Bedingung (5.2) muss 

in allen Ausprägungen weiterhin erfüllt sein. Zu jeder Ausprägung werden wir ein Beispiel 

zeigen und die Anwendungsmöglichkeiten vorstellen. 

Sequenz 

Die Hierarchiebeziehung Sequenz schränkt die allgemeine Bedingung (5.2) weiter ein, 

indem sie die Ausführung der Unteraufgaben nur in einer beliebigen Reihenfolge hintereinander 

erlaubt. Dazu wird eine Bedingung eingefügt, die in der Intervall-Trichotemie 

(Ai wird vor Aj ausgeführt, Ai überschneidet sich mit Aj und Ai wird nach Aj 

ausgeführt) die Überschneidung verbietet: 

∀Ai ∈ {A1, ... , An} ( ∀Aj ∈ {A1, ... , An} \ Ai ( 

start(Aj) ≤ start(Ai) → ende(Aj) ≤ start(Ai) 

)) 

(5.4) 

Eine Unteraufgabe Ai kann nur ausgeführt werden, wenn das Zeitintervall sich nicht 

mit einer anderen Aufgabe Aj überschneidet. Im Beispiel in Abbildung 5.4 wird auf einer 

Zeitachse die Ausführung einer Oberaufgabe und dreier Unteraufgaben dargestellt. 

Nachdem die Oberaufgabe begonnen wurde, kann auch eine Unteraufgabe begonnen 

werden (Bedingung 5.2). Nachdem die Unteraufgabe beendet wurde, darf eine zweite 

Unteraufgabe starten (Bedingung 5.4). Eine dritte Unteraufgabe darf erst angefangen 

77


Oberaufgabe 

Unteraufgabe 1 Unteraufgabe 2 Unteraufgabe 3 

Abbildung 5.4: Hierarchiebeziehung – Sequenz 

t (Zeit) 

werden, wenn die zweite Unteraufgabe beendet wurde (Bedingung 5.4) und muss beendet 

worden sein, bevor die Oberaufgabe beendet wird (Bedingung 5.2). 

Ordnung - Sowohl die strikte als auch die beliebige Ordnung kann im Aufgabenmodell 

für die Sequenz verwendet werden. Falls die strikte Ordnung 

verwendet wird, wird die Sequenz die Unteraufgaben aufgrund der Bedingungen 

5.3 und 5.4 der Reihe nach abarbeiten, angefangen bei A1. 

Falls die beliebige Ordnung verwendet wird, können die Unteraufgaben 

in einer beliebigen Sequenz ausgeführt werden. Falls die Ordnung nicht 

explizit festgelegt wird, wird die strikte Ordnung verwendet. 

Anwendung - Die Sequenz ist eine relevante Hierarchiebeziehung sowohl für die Modellierung 

von Prozessen (z. B. zur Modellierung von sequenziellen Abläufen) 

als auch in Benutzerschnittstellen (z. B. Assistenten, die Eingaben 

in mehrere Schritte zerlegen). 

Selektion 

Die Hierarchiebeziehung Selektion schränkt die allgemeine Bedingung (5.2) weiter ein, 

indem sie nur die Ausführung einer der Unteraufgaben erlaubt. Die zusätzliche Bedingung 

lautet: 

unteraufgaben = {x|x ∈ {A1, ... , An} ∧ start(x) = ∅} 

|unteraufgaben| ≤ 1 

(5.5) 

Aus der Menge der Unteraufgaben gibt es maximal eine, die gestartet wurde, mehr 

dürfen nicht gestartet werden. Im Beispiel in Abbildung 5.5 wurde die zweite Unteraufgabe 

gestartet. Nach dieser Selektion innerhalb der Unteraufgaben kann die zweite 

Unteraufgabe nur noch beendet werden, weitere Operationen sind für die Unteraufgaben 

nicht mehr zulässig. 

Ordnung - Die strikte Ordnung ist bei der Selektion kaum sinnvoll, weil nur die erste 

Unteraufgabe ausgeführt werden könnte. Falls die Ordnung nicht explizit 

angegeben wird, wird die beliebige Ordnung verwendet. 

78

Oberaufgabe 

Unteraufgabe 1 

Abbildung 5.5: Hierarchiebeziehung – Selektion 


t (Zeit) 

Anwendung - Die Selektion findet häufig Anwendung bei der Modellierung von Prozessen 

(z. B. für Entweder-Oder Entscheidungen) und in Benutzerschnittstellen 

(z. B. bei der Auswahl eines Elements aus einer Liste). 

Parallel 

Die Hierarchiebeziehung Parallel schränkt die allgemeine Bedingung (5.2) weiter ein, 

indem sie nur die parallele Ausführung der Unteraufgaben erlaubt. Die zusätzliche Bedingung 

lautet: 

∀Ai ∈ {A1, ... , An} ( ∀Aj ∈ {A1, ... , An} \ Ai ( 

start(Ai) = ∅ → start(Ai) = start(Aj) 

)) 

(5.6) 

Falls aus der Menge der Unteraufgaben eine Unteraufgabe gestartet wurde, müssen 

auch alle anderen Unteraufgaben zum selben Zeitpunkt gestartet worden sein. 

Dies wird zum parallelen Bearbeiten der Unteraufgaben verwendet, wie das Beispiel 

in Abbildung 5.6 zeigt. Über den Endzeitpunkt der Unteraufgaben wird keine Aussage 

getroffen, sodass der Benutzer die verschiedenen Unteraufgaben unterschiedlich lange 

ausführen kann. Nur dass die Endzeitpunkte der Unteraufgaben vor dem Endzeitpunkt 

der Oberaufgabe liegen müssen, wird aufgrund der allgemeinen Bedingung (5.2) gewährleistet. 

Ordnung - Die Verwendung der Ordnungsbedingung ist irrelevant, weil alle Unteraufgaben 

zum gleichen Startzeitpunkt ausgeführt werden und demnach 

keine Ausführungsreihenfolge existiert. Falls die Ordnung nicht explizit 

angegeben wird, wird die beliebige Ordnung verwendet. 

Anwendung - Die parallele Abarbeitung von Unteraufgaben wird in Prozessen verwendet, 

um den Prozessfluss in zwei oder mehr parallel zu bearbeitende 

Stränge zu teilen. Bei Benutzerschnittstellen können parallele Unteraufgaben 

verwendet werden, um die aus dem Web geläufige freie Navigation 

(stöbern) im Aufgabenbaum abzubilden. 

79


Überlappend 

Oberaufgabe 




Abbildung 5.6: Hierarchiebeziehung – Parallel 

t (Zeit) 

Die Hierarchiebeziehung Überlappend schränkt die allgemeine Bedingung (5.2) weiter 

ein, indem sie die Ausführung einer Unteraufgabe nur erlaubt, wenn eine vorher gestartete 

Unteraufgabe noch nicht beendet wurde. Analog darf eine Unteraufgabe erst 

beendet werden, wenn die folgende Unteraufgabe bereits gestartet wurde. Die zusätzliche 

Bedingung lautet: 

∀Ai ∈ {A1, ... , An} ( 

start(Ai) = ∅ ∨ 

(∀Aj ∈ {A1, ... , An} \ Ai (start(Aj) = ∅ ∨ start(Ai) ≤ start(Aj))) ∨ 

(ende(Ai) = ∅ → ∃Ak ∈ {A1, ... , An} \ Ai (start(Ak) ≤ start(Ai) ≤ ende(Ak) ≤ ende(Ai))) 

) 

(5.7) 

Jede Unteraufgabe Ai wird entweder gar nicht ausgeführt, oder sie ist die erste ausgeführte 

Unteraufgabe vor allen anderen Unteraufgaben, oder sie muss von einer vorherigen 

Unteraufgabe Ak überlappt werden. Dies kann als eine Mischform von Sequenz 

und Parallel angesehen werden, bei der der Benutzer die Unteraufgaben zwar in Reihe 

durchlaufen soll, dabei aber mehrere Unteraufgaben gleichzeitig bearbeitet (siehe 

Abbildung 5.7). 

Ordnung - Ähnlich wie bei der Sequenz wird eine strikte Ordnung dazu führen, 

dass die Unteraufgaben nur der Reihenfolge nach ausgeführt werden 

können. Falls die Ordnung nicht explizit angegeben wird, wird die strikte 

Ordnung verwendet. 

Anwendung - Diese Hierarchiebeziehung ist nicht aus der klassischen Aufgabenmodellierung 

entstanden, sondern wurde eingeführt, um die Benutzerschnitt- 

80

Verschachtelt 

Oberaufgabe 




Abbildung 5.7: Hierarchiebeziehung – Überlappend 


t (Zeit) 

stelle bei Aufgaben mit vielen sequenziellen Unteraufgaben bedienbarer 

zu machen. Der Benutzer behält Überblick über die aktuelle Position 

innerhalb der Aufgabensequenz, weil nicht immer nur eine Unteraufgabe 

sichtbar ist, sondern immer auch die vorher Bearbeitete. 

Die Hierarchiebeziehung Verschachtelt definiert eine Ausprägung der Sequenz, die bei 

der Verwendung von iterativen Unteraufgaben sinnvoll ist. Das Ausführen der Iterationen 

einer Aufgabe ist atomar definiert: Eine Aufgabe gilt nur dann als beendet, wenn 

alle Iterationen beendet wurden. Bei der sequenziellen Abarbeitung der Unteraufgaben 

kann dieses unerwünscht sein, weil nach dem Beenden einer Unteraufgabe und 

dem Starten der nächsten Unteraufgabe noch nicht durchgeführte optionale Iterationen 

der ersten Unteraufgabe nicht mehr ausgeführt werden können. 

Die Hierarchiebeziehung Verschachtelt definiert im Sinne der Sequenz, dass immer 

nur eine Iteration einer Unteraufgabe gleichzeitig bearbeitet werden darf, allerdings 

müssen nicht mehr alle Iterationen einer Unteraufgabe gesammelt ausgeführt werden, 

sondern können mit den Iterationen der anderen Unteraufgaben verschachtelt werden. 

Zu diesem Zweck werden in die Bedingung nicht wie bei der Sequenz die Start- und 

Endzeitpunkte der Unteraufgabe, sondern die Start- und Endzeitpunkte der Iterationen 

aufgenommen. Sei iter(X ) die Menge aller Unteraufgabeniterationen einer Aufgabe 

X . Sei startI (X ) der Startzeitpunkt der Iteration X und endeI (X ) der Endzeitpunkt der 

Iteration X . 

∀Ii ∈ iter(A) ( ∀Ij ∈ iter(A) \ Ii ( 

startI (Ij) ≤ startI (Ii) → endeI (Ij) ≤ startI (Ii) 

)) 

(5.8) 

81



Iteration 1 

Oberaufgabe 


Iteration 1 


Iteration 2 

Abbildung 5.8: Hierarchiebeziehung – Verschachtelt 

t (Zeit) 

Im Unterschied zur Bedingung 5.4 wird hier die Exklusivität der Ausführung auf Basis 

der Iterationen und nicht auf Basis der Unteraufgaben getroffen. Es muss auch weiterhin 

gelten, dass am Ende der verschachtelten Ausführung die minimale Kardinalität 

aller Unteraufgaben erreicht wurde, damit die Oberaufgabe beendet werden kann. 

Abbildung 5.8 zeigt, wie die beiden Iterationen der ersten Unteraufgabe mit der zweiten 

Unteraufgabe verschachtelt sind. Übertragen auf ein reales Beispiel wäre das die 

Aufgabe „Emails bearbeiten“, die in die verschachtelten und beliebig oft iterierbaren 

Unteraufgaben „Emails abrufen“ und „Email schreiben“ verfeinert ist, welche beliebig 

oft und beliebig gemischt ausgeführt werden könnten, allerdings nie gleichzeitig. 

Hätten wir eine Sequenz verwendet, könnten wir erst beliebig oft die Emails abrufen 

und danach beliebig oft Emails schreiben, was in diesem Anwendungsfall unerwünscht 

wäre. 

Die Idee, die Verfeinerung (anstelle des Startzeitpunkts start(X ) den Startzeitpunkt 

der Iteration startI (X ), und ebenso für die Endzeitpunkte) nicht nur für die Sequenz, 

sondern verallgemeinert auch für die anderen Ausprägungen zu verwenden, liegt nahe. 

Dies ist allerdings nicht sinnvoll, 

weil bei der parallelen Ausführung auch jetzt schon die Iterationen verschiedener 

Unteraufgaben beliebig gemischt werden können. 

weil bei der Selektion nur eine Unteraufgabe ausgeführt wird und die Iterationen 

verschiedener Unteraufgaben keine Rolle spielen. 

weil bei der überlappenden Ausführung die Iterationen verschiedener Unteraufgaben 

nicht beliebig gemischt werden sollen, sondern sich nur mit der Vorgängeraufgabe 

überlappen sollen. 

Ordnung - Die strikte Ordnung definiert Einschränkungen bezüglich des Startzeitpunktes 

der ersten Iteration der Unteraufgaben. Diese kann auch für 

diese Hierarchiebeziehung verwendet werden und definiert die Reihenfolge 

der ersten Iterationen der Unteraufgaben. Auf die Reihenfolge 

der weiteren Iterationen hat die strikte Ordnung keinen Einfluss. Falls 

die Ordnung nicht explizit angegeben wird, wird die beliebige Ordnung 

verwendet. 

82

Oberaufgabe 


Unteraufgabe 3 Unteraufgabe 2 

Abbildung 5.9: Hierarchiebeziehung – Arbiträr 


t (Zeit) 

Anwendung - Diese Hierarchiebeziehung stammt nicht aus der klassischen Aufgabenmodellierung, 

sondern ist sinnvoll, um Auswahlstrukturen (Menüs, Symbolleisten, 

etc . . . ) im Hinblick auf die Benutzerschnittstelle zu modellieren. 

Wenn z. B. die Unteraufgaben in beliebiger Reihenfolge mehrfach 

ausgeführt werden sollen, aber immer nur eine gleichzeitig bearbeitet 

werden soll. 

Arbiträr 

Die Hierarchiebeziehung Arbiträr entspricht der allgemeinen Bedingung (5.2) und fügt 

keine weiteren Bedingungen hinzu. Sie lässt damit, im Rahmen der allgemeinen Bedingung, 

dem Benutzer beliebige Ausführungsreihenfolgen der Unteraufgaben. Das Beispiel 

in Abbildung 5.9 zeigt eine arbiträre Ausführung der Unteraufgaben, bei denen 

einige Unteraufgaben parallel und einige sequenziell ausgeführt werden. 

Bei der Verwendung dieser Hierarchiebeziehung ist zu beachten, dass sie nur eingesetzt 

werden sollte, wenn die übrigen Ausprägungen der Hierarchiebeziehungen zu 

restriktiv sind. Sonst wird das Aufgabenmodell zu generisch und das Laufzeitsystem 

wird keinen geeigneten Dialog für die Benutzerschnittstelle generieren können. 

Ordnung - Die strikte Ordnung bewirkt, dass arbiträr auszuführende Unteraufgaben 

der Reihe nach gestartet werden müssen. Über die Reihenfolge des 

Beendens der Unteraufgaben wird keine Aussage getroffen. Falls die 

Ordnung nicht explizit angegeben wird, wird die beliebige Ordnung verwendet. 

Anwendung - In Benutzeroberflächen können arbiträr auszuführende Unteraufgaben 

verwendet werden, um die aus dem Web geläufige freie Navigation (stöbern) 

im Aufgabenbaum abzubilden. 

83


Oberaufgabe 


t (Zeit) 

Abbildung 5.10: Abarbeitung der Aufgaben als Sequenz (erste Variante) 

5.4.4 Semantik der Hierarchisierung 

Bei der Einführung der Hierarchie entstehen zwei Sichtweisen auf die Komposition von 

Aufgaben. Bei der ersten Variante wird durch eine Dekomposition in Unteraufgaben 

die Ursprungsaufgabe vollständig ersetzt, die Bearbeitung der Unteraufgaben ergibt 

als Summe genau die Erfüllung der Oberaufgabe. Wenn die Dauer der Bearbeitung 

einer Aufgabe A als dauer(A) = ende(A) − start(A) definiert wird, dann gilt dauer(A) = 

dauer(A1)+dauer(A2)+...+dauer(An) (siehe Abbildung 5.10). Für einen Aufgabenbaum 

bedeutet dies, dass nur die Blattaufgaben vom Benutzer ausgeführt werden und die 

im Baum gelegenen Aufgaben der Strukturierung und Komposition der Blattaufgaben 

dienen. 

Die zweite Variante erlaubt den Nicht-Blattaufgaben einen eigenständigen Anteil an 

der Erfüllung der Aufgabe. Es gilt dauer(A) ≥ dauer(A1) + dauer(A2) + ... + dauer(An) 

(siehe Abbildung 5.11). Vor, zwischen und nach den Ausführungen der Unteraufgaben 

kann die Aufgabe selbst bearbeitet werden. 

Wir werden im Verlauf dieser Arbeit die zweite Variante verwenden, sie ermöglicht 

in den späteren Phasen der Modellierung das Hinzufügen von Dialogelementen an alle 

Aufgaben des Aufgabenbaums, nicht nur an die Blattaufgaben. Diese erlaubt auch eine 

flexible Handhabung des Lebenszyklus einer Aufgabe, z. B. kann, aber muss nicht immer 

das Starten einer Unteraufgabe das Beenden einer vorherigen Unteraufgabe nach sich 

ziehen, wie dies im Beispiel der ersten Variante notwendig ist. 

84 

Oberaufgabe 


t (Zeit) 

Abbildung 5.11: Abarbeitung der Aufgaben als Sequenz (zweite Variante)

5.4.5 Zusammenfassung der Hierarchiebeziehungen 


Tabelle 5.1 beschreibt zusammenfassend die möglichen Hierarchiebeziehungen im Aufgabenmodell, 

sowie deren implizite Ordnungsbedingung. An dieser Stelle führen wir 

auch die Symbole der Hierarchiebeziehungen ein, die wir fortan in der grafischen Notation 

des Aufgabenmodells verwenden werden. Jede Nicht-Blattaufgabe muss eine 

dieser Hierarchiebeziehungen verwenden, um die Ausführungsreihenfolge der Unteraufgaben 

zu bestimmen. Falls eine von der impliziten Ordnung abweichende Ordnung 

verwendet werden soll, muss diese bei der Oberaufgabe angegeben werden. 

Tabelle 5.1: Hierarchiebeziehungen 

name symbol beschreibung impl. ordnung 

sequenz Die Unteraufgaben können nur nacheinander 

ausgeführt werden, eine gleichzeitige 

Ausführung ist untersagt. 

selektion Nur eine der Unteraufgaben darf ausgeführt 

werden. Wenn diese gestartet ist, 

kann keine andere gestartet werden. 

parallel Die Unteraufgaben müssen gleichzeitig 


überlappend Die Unteraufgaben werden nacheinander 

ausgeführt, allerdings darf sich eine Unteraufgabe 

mit der Vorherigen überlappen. 

verschachtelt Die Iterationen der Unteraufgaben müssen 

nacheinander ausgeführt werden, können 

aber mit denen anderer Unteraufgaben 

verschachtelt werden. 

arbiträr Die Unteraufgaben dürfen beliebig ausgeführt 

werden, auch eine gleichzeitige Ausführung 

ist gestattet. 


strikt 

beliebig 

beliebig 

strikt 

beliebig 

beliebig 

Das Aufgabenmodell in Abbildung 5.12 zeigt ein um Hierarchiebeziehungen erweitertes 

Beispiel. Die Eingabe der Kontaktinformationen wird auf zwei Unteraufgaben 

verteilt, die alternativ ausgewählt werden können. Falls eine Adresse als Kontaktinformation 

angegeben werden soll, wird wiederum in zwei Unteraufgaben verzweigt, die 

die Adresseingabe in zwei sequenziellen Schritten erledigt. Die Ordnung wird dabei 

vom vordefinierten strikt auf beliebig geändert, sodass die einzelnen Unteraufgaben in 

beliebiger Reihenfolge bearbeitet werden können. Nachdem die Oberaufgabe „Kontaktinformationen 

angeben“ durchgeführt wurde, sind aufgrund der Bedingungen des 

85


Strasse 

angeben 

Adresse 

angeben 

Stadt 

angeben 


angeben 


Telefonnummer 

angeben 

Abbildung 5.12: Beispiel Aufgabenmodell – Hierarchie 

Aufgabenbaums mindestens eine und maximal fünf Adressen und Telefonnummern im 

beliebigen Verhältnis vom Benutzer angegeben worden. 

5.5 Der Aufgabentyp 


Aufgaben als Beschreibung der Mensch-Maschine-Interaktion können grundsätzlich in 

vier verschiedene Kategorien aufgeteilt werden (nach Paternò u. a. [1997], siehe Abschnitt 

3.4.2). Diese Kategorien beschränken später bei der Aufgabenausführung den 

Benutzerdialog und erlauben schon früh im Modellierungsprozess eine Festlegung, ob 

und wie der Benutzer mit der Anwendung interagieren soll. 

Benutzeraufgaben werden ausschließlich vom Benutzer ausgeführt, sie beinhalten die 

kognitive Aktivität des Benutzers ohne direkte Interaktion mit der Anwendung. 

Zum Beispiel ist das Lesen einer Angebotsliste mit der anschließenden Auswahl eines 

Angebots eine Benutzeraufgabe. Diese Definition nach [Paternò u. a., 1997] ist 

für unser ausführbares Aufgabenmodell allerdings zu restriktiv, denn der Benutzer 

müsste zumindest der Anwendung mitteilen, wann seine Aktivität beendet 

ist, damit die Abarbeitung des Aufgabenmodells fortgesetzt werden kann. Wir 

definieren eine Aufgabe als Benutzeraufgabe, wenn sie nur mit der Präsentationsschicht 

interagiert und keine Auswirkungen auf die Anwendungsschicht hat 27 . 

27 Eine Definition der Schichten einer Web-Anwendung fand in Abschnitt 2.4 statt. 

86

5.5 Der Aufgabentyp 

Damit sind z. B. einfache Eingaben möglich und der Benutzer kann die weitere 

Ausführung des Aufgabenmodells anstoßen. 

Systemaufgaben werden ausschließlich von der Anwendung ohne Einflussnahme des 

Benutzers ausgeführt. Zur Laufzeit kann die Anwendung, wenn sie auf eine solche 

Aufgabe stößt, diese starten und beenden, der Benutzer kann erst in einer darauf 

folgenden Aufgabe auf den Erfolg (oder Misserfolg) dieser Aufgabe reagieren. 

Beispiele hierzu sind die Kommunikation mit einem Mailserver zum Verschicken 

einer Nachricht oder die endgültige Buchung eines Fluges. 

Interaktionsaufgaben werden vom Benutzer und von der Anwendung gemeinsam ausgeführt. 

Der Benutzer liefert Eingaben an die Anwendung, worauf diese die Eingaben 

verarbeitet und eine Ausgabe produziert. Ein Beispiel hierzu ist die Formulierung 

einer Suchanfrage für Flüge vom Benutzer und die darauf folgende 

Generierung einer Flugliste von der Anwendung. Als Abgrenzung zur Benutzeraufgabe 

muss eine Interaktionsaufgabe mit der Anwendungsschicht interagieren. 

Abstrakte Aufgaben enthalten komplexe Aktivitäten, welche nicht durch eine der drei 

vorhergehenden Aufgabentypen beschrieben werden können. Dieser Aufgabentyp 

tritt vor allem in dem oberen Teil eines Aufgabenbaums auf, welche erst durch 

Unteraufgaben konkretisiert werden und dem entsprechend die Aufgabentypen 

der Unteraufgaben zusammenfassen müssen. 

Die Aufgabentypen müssen der Logik der Aufgabenhierarchie folgen, eine Benutzeraufgabe 

kann z. B. nicht in eine abstrakte Aufgabe oder in eine Systemaufgabe verfeinert 

werden. Wenn A wieder die Oberaufgabe ist, Ai ∈ {A1, ... , An} die Unteraufgaben 

sind und typ(X ) den Typ einer Aufgabe X bestimmt, dann können wir definieren: 

typ(A) = abstrakt → typ(Ai) ∈ {abstrakt, interaktion, benutzer, system} 

typ(A) = interaktion → typ(Ai) ∈ {interaktion, benutzer, system} 

typ(A) = benutzer → typ(Ai) ∈ {benutzer} 

typ(A) = system → typ(Ai) ∈ {system} 

(5.9) 

In der grafischen Notation werden wir die Aufgaben mit folgenden Symbolen typisieren: 

Tabelle 5.2: Aufgabentypen 

name symbol 

Benutzeraufgabe 

Systemaufgabe 

Interaktionsaufgabe 

abstrakte Aufgabe 

87



Strasse 

angeben 

Adresse 

angeben 

Stadt 

angeben 


angeben 


Telefonnummer 

angeben 

Abbildung 5.13: Beispiel Aufgabenmodell – Aufgabentypen 

In Abbildung 5.13 ist unser Beispiel um Aufgabentypen ergänzt. Während die meisten 

Aufgaben rein vom Benutzer ausgeführt werden (Informationen werden in strukturierter 

Form eingegeben), ist die Aufgabe Kontaktinformationen angeben als Interaktionsaufgabe 

ausgelegt. Bei der späteren Modellierung ist dann die Weitergabe der eingegebenen 

Kontaktinformationen aus der Präsentationsschicht in die Anwendungsschicht 

möglich, um z. B. die Kontaktinformationen persistent in einer Datenbank abzulegen. 

5.6 Unterbrechbarkeit 


In diesem Abschnitt werden wir den Lebenszyklus von Aufgaben betrachten und die 

Frage beantworten, warum dieser Lebenszyklus bereits im Aufgabenmodell integriert 

werden sollte. 

Web-Anwendungen müssen im Gegensatz zu klassischen desktop-basierten Anwendungen 

mit einer Vielzahl von Unterbrechungen rechnen. Wir unterscheiden zwei Kategorien 

von Unterbrechungen: vom Benutzer ausgehende und vom System ausgehende. 

Vom Benutzer ausgehende Unterbrechungen entstehen, wenn der Benutzer Aufgaben 

ausführen möchte, die laut Aufgabenmodell aktuell nicht ausführbar sind. Dies 

kann beispielsweise durch die Verwendung der Navigationsknöpfe des Webbrowsers 

88

5.6 Unterbrechbarkeit 

geschehen (Rücksprung auf eine jetzt nicht mehr ausführbare Aufgabe), durch das Anwählen 

eines Lesezeichens (direkter Sprung auf eine Aufgabe, die noch nicht ausführbar 

ist) oder auch durch die Eingabe einer URL in den Webbrowser. Diese Navigation 

außerhalb des Aufgabenkontexts ist vom System zwar erkennbar, aber nicht automatisch 

korrigierbar. Der Aufgabenmodellierer sollte entscheiden können, wie später bei 

einer solchen Unterbrechung zu verfahren ist. In klassischen desktop-basierten Anwendungen 

können diese Unterbrechungen nicht auftreten, weil dort in der Benutzeroberfläche 

die Navigationsmöglichkeiten außerhalb des Aufgabenkontexts nicht existieren. 

Aufgrund der Zustandslosigkeit des hypertext-transfer-protocol (http) muss der Server 

jede Benutzeranfrage mit einem im Serverspeicher abgelegten Aufgabenkontext 

assoziieren, in dem der Zustand der Anwendung für diesen Benutzer vorgehalten wird. 

Weil der Serverspeicher endlich ist und ein Benutzer, der einen Aufgabenkontext initiiert 

hat, eventuell seinen Webbrowser schließt und nicht wiederkehrt, muss dieser 

Serverspeicher aufgeräumt werden. Üblicherweise geschieht dies mit einer Zeitüberschreitung 

nach der letzten Benutzeranfrage, und in dem beschriebenen Fall ist dies die 

korrekte Vorgehensweise. Was geschieht aber, wenn der Benutzer nur eine Weile den 

Arbeitsplatz verlassen hat und im jetzt nicht mehr vorhandenen Aufgabenkontext weiter 

arbeiten möchte? In diesem Fall hat eine vom System ausgehende Unterbrechung 

stattgefunden. In klassischen desktop-basierten Anwendungen können diese Unterbrechungen 

nicht auftreten, weil dort die Benutzeroberfläche entweder Teil der gesamten 

Anwendung ist und deshalb nicht einzeln beendbar ist, oder aber die Anwendung über 

ein zustandsbehaftetes Protokoll angebunden wird und damit die oben skizzierte Unsicherheit 

nicht existiert. 

Egal welcher Art die Unterbrechungen sind, das Laufzeitsystem sollte sie erkennen 

und darauf definiert reagieren. Anstelle einer einzigen Unterbrechungsstrategie für 

alle Aufgabenmodelle wollen wir dem Modellierer die Wahl lassen, wie einzelne Aufgaben 

eines Aufgabenmodells auf Unterbrechungen reagieren. 

Folgende Strategien fügen wir dem Aufgabenmodell hinzu: 

flüchtig Im Falle einer Unterbrechung wird der Aufgabenkontext verworfen. Dies ist 

die Standardstrategie, wenn sonst keine Strategie angegeben wird. 

unterbrechbar Im Falle einer vom Benutzer ausgehenden Unterbrechung wird der Aufgabenkontext 

im Speicher vorgehalten. Dem Benutzer wird in der Oberfläche die 

Möglichkeit gegeben, das unterbrochene Aufgabenmodell fortzusetzen. 

persistent Im Falle einer vom System ausgehenden Unterbrechung wird zusätzlich zum 

Verhalten von „unterbrechbar“ der Aufgabenkontext auf einem Langzeitspeicher 

(z. B. Datenbank) persistiert. Dies funktioniert nur für Benutzer, welche beim 

nächsten Besuch reidentifiziert werden können, z. B. über eine Name/Passwort- 

Registration oder ein sogenanntes Site-Cookie. Der Benutzer arbeitet an der gleichen 

Stelle weiter, an der die Unterbrechung stattgefunden hat. 

Diese Strategien können innerhalb einer Aufgabenhierarchie auch gemischt werden, 

solange die Ordnung persistent→unterbrechbar→flüchtig gewahrt bleibt. Eine persistente 

Aufgabe kann persistente, unterbrechbare und flüchtige Unteraufgaben enthalten. 

Unterbrechbare Aufgaben können unterbrechbare und flüchtige Unteraufgaben 

89


enthalten. Flüchtige Aufgaben können nur flüchtige Unteraufgaben enthalten. Aus 

dieser Ordnung geht hervor, dass an der Wurzelaufgabe ablesbar ist, welche Strategie 

im Falle einer Unterbrechung anzuwenden ist. Auch verhindert diese Ordnung Inkonsistenzen 

zur Laufzeit, weil von einem rekonstruierten Aufgabenkontext einer Unteraufgabe 

die Aufgabenkontexte alle Elternaufgaben bis zur Wurzel ebenfalls rekonstruiert 

werden. Falls ein Aufgabenkontext in der Kette der Aufgabenkontexte bis zur Wurzel 

nicht gespeichert werden würde, hätte dieser bei der Rekonstruktion seine Startund 

Endzeitpunkte verloren. Die Bedingung 5.2 wäre nicht mehr erfüllt, obwohl sie es 

vor der Unterbrechung war. Aus diesem Grund kann die Unterbrechungsstrategie auf 

den Ebenen im Aufgabenbaum von der Wurzel- bis zu den Blattaufgaben nur abgeschwächt, 

niemals jedoch verstärkt werden. 

Um die Konsistenz der Hierarchiebedingungen nicht zu gefährden, weil z. B. auf der 

Ebene der Unteraufgaben einige persistiert werden und einige nicht, definieren wir 

die Unterbrechungsstrategien auf den Hierarchiebeziehungen. Wenn z. B. eine Aufgabe 

mit der Hierarchiebeziehung Sequenz und der Unterbrechungsstrategie persistent 

ausgezeichnet ist, so bedeutet dies, dass die Aufgabenkontexte sämtlicher Unteraufgaben 

im Falle einer Unterbrechung persistiert werden. Über die Unterbrechungsstrategie 

der Aufgabe selbst wird an dieser Stelle keine Aussage getroffen, diese muss in der Hierarchiebeziehung 

der Elternaufgabe definiert sein. Als Ausnahme ist die Wurzelaufgabe 

zu betrachten, die keine Nachbaraufgaben und keine Elternaufgabe besitzt. In diesem 

Fall gilt die Unterbrechungsstrategie der Wurzelaufgabe sowohl für den Aufgabenkontext 

der Wurzelaufgabe selbst als auch für die Hierarchiebeziehungen und damit die 

Unteraufgaben. 


Ein Beispiel verdeutlicht das Konzept der Unterbrechungsstrategie in unserem Interaktionsmodell. 

Abbildung 5.14 zeigt ein um Unterbrechungsstrategien erweitertes Aufgabenmodell. 

Die Wurzelaufgabe ist mit der Strategie persistent ausgezeichnet, im Falle 

einer Unterbrechung wird der Zustand dieser Aufgabe und aller Unteraufgaben persistiert. 

Wenn der Benutzer also gerade die Aufgabe Telefonnummer angeben bearbeitet, 

würden die bis dorthin eingegebenen Daten gesichert. Die Unteraufgaben von Adresse 

angeben sind hingegen als flüchtig gekennzeichnet, die bis zur Unterbrechung eingegebenen 

Daten in den Unteraufgaben würden verworfen werden. Der Aufgabenkontext 

von Adresse angeben selbst würde hingegen gesichert werden, weil die Aufgabe 

eine Unteraufgabe von Kontaktinformationen angeben ist und damit von deren Unterbrechungsstrategie 

kontrolliert wird. 

Dem Modellierer bietet sich die Möglichkeit, die Aufgaben anhand der Lebensdauer 

ihres Zustands zu klassifizieren. Langfristig interessante Informationen, wie z. B. der 

Inhalt eines Warenkorbes, sollten persistiert werden. Kurzfristig interessante Informationen, 

wie z. B. die Abfrage des Kinoprogramms eines spezifischen Tages, könnten als 

flüchtig markiert werden, sie wären beim nächsten Besuch des Benutzers wahrscheinlich 

veraltet. 

90

Strasse 

angeben 

Adresse 

angeben 

Strategie = flüchtig 

Stadt 

angeben 

5.7 Zugriffskontrolle über Rollenkonzept 


angeben 

Strategie = persistent 


Telefonnummer 

angeben 

Abbildung 5.14: Beispiel Aufgabenmodell – Unterbrechung 


Dieser Abschnitt beschäftigt sich mit der Integration einer Zugriffskontrolle in das Aufgabenmodell. 

Zugriffskontrolle besteht in der Informatik meist aus zwei Konzepten: 

Unter Authentifizierung versteht man die eindeutige Identifizierung eines Benutzers 

am System. Dies kann – je nach Sicherheitsanforderung – durch Wissen (z. B. 

Passwort), Besitz (z. B. qualifizierte Signaturkarte) oder durch körperliche Merkmale 

(z. B. Fingerabdruck) geschehen. Die Authentifizierung ist nicht Teil des Aufgabenmodells, 

wir gehen davon aus, dass der Benutzer sich am Laufzeitsystem 

authentifizieren kann und Zugriff auf die Authentifizierungsdaten (englisch: Principal) 

besteht. 

Die Autorisierung beschreibt die Rechte, die eine authentifizierte Person im Umfeld 

der Anwendung besitzt. Autorisierungsdaten können in vielfältiger Weise 

abgelegt werden, wobei speziell auf die Integration in das Aufgabenmodell Wert 

gelegt werden muss. So eignet sich eine direkte Beziehung zwischen authentifiziertem 

Benutzer und zu schützender Aufgabe nicht, da die möglichen Benutzer 

während der Aufgabenmodellierung gar nicht fest stehen, bzw. große Gruppen 

umfassen können. Wir konzentrieren uns im Folgenden auf das Rollenkonzept, 

welches die notwendige Abstraktion bietet. 

91


Role Hierarchy 

User 

User Assignment 

Role Permission Assignment 

Domain 

Operations Objects 

Abbildung 5.15: Hierarchischer RBAC Standard nach ANSI 359-2004 ([INCITS, 2004]) 

5.7.1 Rollenkonzept 

Das Rollenkonzept führt ein weiteres Element zwischen authentifiziertem Benutzer und 

den zugriffsbeschränkten Ressourcen ein: die Rolle. Rollen bündeln Zugriffsrechte für 

verschiedene Einsatzzwecke und erlauben eine Entkoppelung von Benutzern und Ressourcen. 

Zum Beispiel kann eine Rolle „Buchhaltung“ eingeführt werden, die der Ressource 

„Lohnabrechnungen“ zugeordnet wird. Durch eine Zuordnung dieser Rolle zu 

einem Benutzer wäre eine Autorisierungskette Benutzer → Rolle → Ressource definiert 

und die Berechtigung des Benutzers auf eine Ressource kann einwandfrei bestimmt 

werden. Die Kardinalität der Beziehung zwischen Benutzer und Rolle, sowie zwischen 

Rolle und Ressource ist in beiden Fällen n : m. 

Der ANSI Standard 359-2004 (siehe [INCITS, 2004]) definiert ein entsprechendes Rollenkonzept, 

welches als Role Based Access Control (RBAC, rollenbasierte Zugriffskontrolle) 

bezeichnet wird und breite Verwendung findet (z. B. in Identitätsmanagementsystemen). 

Das Bild 5.15 zeigt die Übersicht über die Komponenten des Standards, wobei 

Ressourcen in Objekte und Operationen geteilt sind. Weiterhin wird eine Hierarchisierung 

der Rollen vorgeschlagen, um die Zugriffsrechte großer Anwendungen besser 

verwalten zu können. Im obigen Beispiel könnte die Rolle Buchhaltung alle allgemeinen 

Rechte der Buchhaltung besitzen und weitere Unterrollen wie zum Beispiel Anlagenbuchhaltung 

und Lohnbuchhaltung speziell für diese Aufgaben notwendige Rechte. 

Die Menge der Berechtigungen setzt sich dann aus den Rechten aller Rollen zusammen, 

die sich auf dem Weg der vergebenen Rolle bis zur Wurzel der Rollenhierarchie 

befinden. 

Rollen sind dabei nicht mit Gruppen zu verwechseln. Bild 5.16 zeigt eine gängige 

Erweiterung des RBAC Standards um Gruppen. Die Gruppenzugehörigkeit beschreibt 

eine Mitgliedschaft zu einer Personengruppe, zum Beispiel einer Abteilung. Im häufig 

anzutreffenden Fall, dass Berechtigungen auch Personengruppen zugeordnet werden 

können, kann eine Rolle auch einer Gruppe zugeordnet werden, alle Mitglieder dieser 

Gruppe erhalten dann die zugeordnete Rolle. Gruppen können ähnlich hierarchisch 

angeordnet werden wie Rollen. 

5.7.2 Integration in das Aufgabenmodell 

Zur Integration des Rollenkonzeptes in das Aufgabenmodell betrachten wir zuerst die 

Integration einer einzelnen Aufgabe in das Rollenkonzept aus Abbildung 5.16. Die ab- 

92


Hierarchical RBAC Domain Specific 

User 

0..* 

0..* belongs to 0..* 

0..* 

0..1 

Group 

is in role 

0..* 

0..1 

is child of 

is in role 0..* 

Role 1 

0..* accessible by 

0..* 

1 

is child of 

accessible by 

0..* 

Domain 

Operations 

0..* 

Abbildung 5.16: Um Gruppen erweiterter RBAC Standard 

Objects 

zusichernden Objekte und Operationen sind dort in der Domäne zusammengefasst. Da 

unsere Aufgabe aus Sicht des Rollenkonzeptes auch domänenspezifisch ist und wir sie 

zur Laufzeit absichern wollen, müssen wir sie mit den Rollen assoziieren. Die Zuweisung 

der Rollen zu den Aufgaben soll bereits bei der Modellierung im Aufgabenmodell 

erfolgen. Zu diesem Zweck wird im Aufgabenmodell eine Liste der Zugriffsrollen (eine 

Aufgabe kann durch mehrere Rollen autorisiert sein, wobei ein Benutzer nur eine der 

Rollen besitzen muss, um auf die Aufgabe zuzugreifen) für jede Aufgabe definiert. Das 

Laufzeitsystem muss dann diese Rollen mit der vorhandenen Benutzerverwaltung abgleichen 

und damit die Kette Benutzer → Rolle → Aufgabe herstellen können, um den 

Zugriff auf eine Aufgabe zu erlauben oder zu verwehren. 

Bei der Modellierung des Aufgabenmodells sind keine Informationen darüber bekannt, 

wie Rollenobjekte aussehen und welche überhaupt existieren. Wir schlagen deshalb 

vor, die Rollen über Namen zu identifizieren. Das Laufzeitsystem sollte vor dem 

Ausführen des Aufgabenmodells eine Konsistenzprüfung der verwendeten Rollennamen 

durchführen und eventuell die Ausführung abbrechen, falls nicht alle Rollennamen 

in Rollenobjekte der zur Laufzeit vorhandenen Benutzerverwaltung aufgelöst werden 

können. 

In einer Aufgabenhierarchie ist die Auswertung der benötigten Rollen, um auf eine 

Aufgabe zugreifen zu dürfen, aus zwei Gründen komplexer: 

Rollen vererben sich auf Unteraufgaben. Obwohl in den Unteraufgaben die in 

den Elternaufgaben verwendeten Rollen nicht erneut explizit erwähnt werden, 

sind diese trotzdem in Kraft. 

Die Rollen, die innerhalb einer Aufgabe verwendet werden, sind oder-verknüpft. 

Die Rollen, die auf dem Weg der Aufgabe bis zur Wurzelaufgabe verwendet werden, 

sind und-verknüpft. 

93


Eine Aufgabe, die selbst die Rollen lohnbuchhaltung und anlagenbuchhaltung verwendet 

und deren Oberaufgabe nur den Rollen vorgesetzter oder administrator Zugriff 

gestattet, muss deshalb folgende Bedingung auswerten: 

(lohnbuchhaltung ∨ anlagenbuchhaltung) ∧ (vorgesetzter ∨ administrator) (5.10) 

Dies ist aber ein recht kompliziertes Beispiel. In den meisten Fällen werden nur einzelne 

Zugriffsrollen für Aufgaben verwendet und auch in der Hierarchie werden sich 

selten mehrere Rollen überlappen. Die Verwendung von Zugriffsrollen kann auch zu 

nicht erreichbaren Aufgaben führen, eine klare Rollenmodellierung sollte deshalb parallel 

zur Aufgabenmodellierung erfolgen. 

5.7.3 Rollenspezifische Adaption der Benutzerschnittstelle 

Aufgabenmodelle für mehrere Rollen müssen nicht in durch Rollen voneinander getrennten 

Teilen erstellt werden, also z. B. nicht in zwei disjunkte Aufgabenbäume für 

zwei verschiedene Rollen. Rollen können auch innerhalb der Aufgabenhierarchie feingranular 

gemischt werden und dadurch die gleichen Aufgaben für unterschiedliche Rollen 

im Detail unterschiedlich ausgestalten. Zur Laufzeit erhalten wir dann eine rollenspezifische 

Adaptierung der Benutzerschnittstelle. Dies erfordert eine Nachbetrachtung 

der Hierarchiebeziehungen, denn z. B. in einer Sequenz könnte eine der Unteraufgaben 

aufgrund der Rollenrestriktion nicht erreichbar sein. Die Sequenz könnte wie folgt ausgeführt 

werden: 

Es wird angezeigt, dass eine nicht ausführbare Aufgabe in der Sequenz wartet, 

eventuell mit der Angabe der fehlenden Rollen (Die Rollenbedingung kann, wie 

oben erwähnt, komplex werden und damit schlecht darstellbar sein). Die Ausführung 

ist dann entweder an dieser Stelle beendet oder kann erst durch einen 

Rollenwechsel des Benutzers fortgesetzt werden. 

Die Aufgaben mit den beim Benutzer nicht vorhandenen Rollen werden aus der 

Menge der Unteraufgaben entfernt, die Sequenz wird auf die verbleibenden Aufgaben 

reduziert. Entfernte Aufgaben werden nie in der Benutzerschnittstelle auftauchen. 

Der Modellierer des Aufgabenmodells muss dies beachten, und darf Unteraufgaben 

nur mit Rollen auszeichnen, die nicht essenziell wichtig für die Erfüllung 

der Oberaufgabe sind. 

Die erste Variante eignet sich, um einen Workflow für verschiedene Benutzer zu erstellen, 

die an einer Aufgabe beteiligt sein sollen, z. B. eine Dokumentenfreigabe mit 

Autoren und Redakteuren. Dies ist allerdings nicht der Fokus dieser Arbeit 28 , wir wollen 

Aufgabenmodelle für Webanwendungen definieren, die von mehreren unabhängig 

und parallel arbeitenden Benutzern verwendet werden 29 . Wir werden deshalb die 

28 Das ConcurTaskTrees-Environment [Paternò u. a., 1997] bietet dazu z. B. den sogenannten Cooperative mode 

29 Natürlich arbeiten mehrere Benutzer niemals wirklich unabhängig auf einem System, z. B. ist die Menge an 

verfügbaren Sitzplätzen für einen Flug in einem Flugbuchungssystem begrenzt. Diese Abhängigkeiten werden 

allerdings im Domänenmodell verwaltet und sind nicht Teil unseres Aufgabenmodells 

94

Strasse 

angeben 

Adresse 

angeben 


Stadt 

angeben 

5.8 Wiederverwendbarkeit von Aufgabenhierarchien 


angeben 



Telefonnummer 

angeben 

existierende 

Adresse kopieren 

ZugriffsRolle = »admin« 

Abbildung 5.17: Beispiel Aufgabenmodell – Zugriffsrollen 

zweite Variante verwenden, sie eignet sich dazu, aus einem Aufgabenmodell über die 

Rollen unterschiedliche Ausprägungen für unterschiedliche Benutzer zu generieren. 

Bei der Modellierung muss dieser Unterschied bekannt sein, denn sobald eine Aufgabe 

mit Rollen ausgezeichnet wird, kann sie eventuell verworfen werden. Hierarchiebeziehungen, 

Kardinalitäten und Unterbrechbarkeit dieser Aufgabe werden dann nicht 

weiter betrachtet. 


Abbildung 5.17 zeigt ein um Zugriffsrollen erweitertes Aufgabenmodell. Zusätzlich zu 

den Möglichkeiten eines Nutzers ohne Zugriffsrollen (Adresse angeben und Telefonnumer 

angeben) darf ein Benutzer in der Rolle admin aus der Liste der bereits verfügbaren 

Adressen eine existierende Adresse kopieren. Diese Aufgabe ist als Interaktionsaufgabe 

ausgelegt, weil aus der Anwendung die Liste aller Kontaktinformationen geholt werden 

muss, aus der der Benutzer dann einen zu kopierenden Eintrag auswählt. 


5.8.1 Motivation 

Bei der Modellierung eines Aufgabenmodells kann es vorkommen, dass an verschiedenen 

Stellen im Aufgabenbaum die gleiche Funktionalität gefordert wird. Die triviale 

95


Abbildung 5.18: Gerichteter azyklischer Graph und gerichteter zyklischer Graph 

Herangehensweise wäre das Kopieren eines Teilbaums an eine andere Stelle im Aufgabenbaum. 

Dies führt allerdings zu Redundanzen und zu einem schlecht wartbaren 

Aufgabenmodell, wenn z. B. später eine Änderung an den duplizierten Aufgaben erfolgen 

soll, muss diese an verschiedenen Stellen im Aufgabenmodell stattfinden. 

Eine bessere Lösung ist das Verwenden von Referenzen. Teilbäume werden einmal 

im Aufgabenmodell definiert und von anderen Stellen referenziert (Ursprungsaufgabenmodell). 

Dazu werden Platzhalteraufgaben in das Aufgabenmodell eingefügt, die 

als einzige Eigenschaft eine Referenz auf den zu referenzierenden Aufgabenteilbaum 

besitzt. Zur Laufzeit werden dann diese Referenzen aufgelöst und eine Kopie des Teilbaums 

anstelle der Referenz eingefügt (Zielaufgabenmodell). Damit ein Zielaufgabenmodell, 

in dem die Aufgabenreferenzen aufgelöst wurden, weiterhin eine Baumstruktur 

ergibt, muss Folgendes gelten: 

Im Ursprungsaufgabenmodell darf eine Referenz niemals direkt oder indirekt 

auf eine Elternaufgabe oder sich selbst verweisen. 

Dadurch würden Zyklen entstehen, die im Zielaufgabenmodell nicht mehr als Baumstruktur 

abbildbar wären. Wenn die Kanten im Ursprungsaufgabenmodell als gerichtete 

Kanten von der Wurzel zu den Blättern betrachtet werden und die Referenzen als 

zusätzliche gerichtete Kanten von der Referenz zur referenzierter Aufgabe, dann muss 

der daraus resultierende gerichtete Graph zyklenfrei sein 30 . 

Abbildung 5.18 zeigt auf der linken Seite einen gerichteten azyklischen Graph in 

Form eines Aufgabenbaums mit einer Platzhalteraufgabe. Diese Referenz lässt sich problemlos 

zu einem Zielaufgabenmodell auflösen. Auf der rechten Seite ist ein gerichteter 

zyklischer Graph abgebildet, welcher als Aufgabenmodell nicht zulässig ist, weil 

eine Auflösung der Referenz zu einem Teilbaum wiederum die Referenz enthält und 

dadurch ein rekursiver, unendlicher Aufgabenbaum entstehen würde. 

Im Aufgabenmodell lässt sich diese Restriktion allerdings nicht ohne Weiteres integrieren, 

Referenzen sind grundsätzlich zu beliebigen Aufgaben möglich. Ein Aufgabeneditor 

kann aber automatisch Zyklenfreiheit garantieren (z. B. unter Verwendung von 

30 englisch: directed acyclic graph (DAG) 

96

Name 

angeben 

Vorname 

angeben 

Adresse 

angeben 

Ordnung = beliebig 


Strasse 

angeben 

Nachname 

angeben 



angeben 



Stadt 

angeben 

Telefonnummer 

angeben 

Rufname 

angeben 

existierende 



Rufnummer 

angeben 

Abbildung 5.19: Beispiel Aufgabenmodell – Wiederverwendung von Aufgabenhierarchien 

Algorithmen aus [Mitchell, 2001]) und das Laufzeitsystem sollte Aufgabenmodelle mit 

Zyklen abweisen. Ein wichtiger Aspekt ist allerdings vom Modellierer bei der Aufgabenmodellierung 

zu beachten: 

Alle Eigenschaften der referenzierten Aufgabe, die durch Vererbung von einer Elternaufgabe 

gelten (z. B. Zugriffsschutz durch eine Rollenzuweisung in der alten Elternaufgabe), 

sind in der Referenz nicht mehr wirksam. Stattdessen werden die Eigenschaften 

neu evaluiert und es gelten die Eigenschaften der neuen Elternaufgabe. 


Wir erweitern unser bekanntes Beispiel um die Möglichkeit, zu den Adressen und Telefonnummern 

einen Namen anzugeben (siehe Abbildung 5.19). Dazu wurde der Aufga- 

97


be Adresse angeben einen Aufgabenteilbaum Name angeben mit den Unteraufgaben 

Vorname angeben und Nachname angeben hinzugefügt. Weil die Aufgabe Telefonnummer 

angeben auch einen ähnlichen Aufgabenteilbaum benötigt, wurde eine Referenz 

in Form der Platzhalteraufgabe Rufname angeben mit einer Referenz zu Name 

angeben eingefügt. Zur Laufzeit würde diese Aufgabe durch den Aufgabenteilbaum ersetzt. 

Hierbei ist zu bemerken, dass die vererbten Eigenschaften neu evaluiert werden, 

der Teilbaum Name angeben hätte unter Adresse angeben die Unterbrechungsstrategie 

flüchtig, und unter Telefonnummer angeben die Unterbrechungsstrategie persistent 

(von Kontaktinformationen angeben vererbt). 


In diesem Kapitel haben wir ein Aufgabenmodell als Basis unseres Interaktionsmodells 

vorgestellt, welches die gemeinsamen Aspekte der allgemeinen Aufgabenmodelle aus 

Abschnitt 3.4 aufgreift und um Aspekte für Web-Anwendungen ergänzt wurde. 

Tabelle 5.3 fasst die Attribute einer Aufgabendefinition zusammen und beschreibt 

deren Bedeutung. Abbildung 5.20 definiert die erste Version des Metamodells unseres 

Interaktionsmodells als UML-Klassendiagramm, sämtliche Beispiele dieses Kapitels sind 

damit in strukturierter Form umsetzbar und für ein Laufzeitsystem auswertbar. In den 

nächsten Kapiteln werden wir das Metamodell erweitern und zeigen, wie das Laufzeitsystem 

aus dem Interaktionsmodell eine Benutzerschnittstelle erzeugen kann. 

98


name definition optional standard 

id Eindeutiger Identifizierer innerhalb des Aufgabenbaums, 

keine Leer- und Sonderzeichen 

name Kurzer Name der Aufgabe, sollte nicht kryptisch 

sein, kann zur Laufzeit im Dialog angezeigt werden 

beschreibung Längere Beschreibung der Aufgabe, kann ebenfalls 

im Dialog angezeigt werden 

kardinalität Minimale und maximale Anzahl der Ausführungen 

der Aufgabe 

nein name 1 

nein - 

ja - 

oberaufgabe Verweis auf die Oberaufgabe nein 2 

ja 1,1 

unteraufgaben Verweise auf die Unteraufgaben ja - 

beziehung Hierarchiebeziehung der Unteraufgaben zur 

Oberaufgabe, Wertebereich siehe Tabelle 5.1 

ordnung Strikt oder beliebig geordnete Ausführung der 

Unteraufgaben 

zugriffsRollen Menge der autorisierten Rollen, die diese Aufgabe 

ausführen dürfen 

nein 3 

- 

- 

ja 4 

ja - 

strategie Persistenzstrategie der Hierarchiebeziehung ja fluechtig 

1 

Falls der Name als ID übernommen wird, sollte dieser den Bedingungen an IDs automatisch angepasst werden. 

2 

Nur optional, wenn es sich um die Wurzel des Aufgabenbaums handelt. 

3 

Nur optional, wenn es sich um eine Blattaufgabe handelt (|unteraufgaben| = 0). 

4 

Standardwerte hängen von der verwendeten Hierarchiebeziehung ab, siehe Tab. 5.1. 

Tabelle 5.3: Aufgabendefinition 

99


 

AufgabenTyp 

abstrakt 

interaktion 

benutzer 

system 

 

AufgabenBeziehung 

sequenz 

parallel 

selektion 

verschachtelt 

ueberlappend 

arbitraer 

 

UnterbrechungsStrategie 

fluechtig 

unterbrechbar 

persistent 

100 

-typ 

 

Ordnung 

beliebig 

strikt 

-beziehung 

-strategie 

-ordnung 

Aufgabe 

-id : String 

-name : String 

-beschreibung : String 

-kardinalitaet : int [2] 

-zugriffsRollen : Set 

-elternaufgabe 

0..1 

Abbildung 5.20: Interaktionsmetamodell 

Platzhalteraufgabe 

1 

0..* 

-referenz 

-unteraufgaben 

0..*

Kapitel 6 

Aufgabenbasierte Dialogfragmente für 

Web-Anwendungen 

Inhalt 

6.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 

6.2 Erweitertes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 

6.3 Anbindung an das Aufgabenmodell . . . . . . . . . . . . . . . . . . . . 106 

6.4 Anbindung des Domänenmodells . . . . . . . . . . . . . . . . . . . . . 121 

6.5 Erweiterung der Aufgaben um dialogspezifische Attribute . . . . . . . 137 



Wir werden, gemäß unserem Ansatz, nicht zur Modellierungszeit das Aufgabenmodell 

in ein oder mehrere statische Dialogmodelle überführen, sondern unser aufgabenbasiertes 

Interaktionsmodell um Dialoginformationen erweitern, und erst zur Laufzeit 

einen für den Benutzer angepassten Dialog erstellen. 

Das Aufgabenmodell aus dem vorigen Kapitel ist noch nicht ausreichend, um einen 

Dialog zwischen dem Benutzer und der Anwendung zu generieren. Ein Dialog beschreibt, 

wie Eingabe- und Ausgabe-Interaktionen stattfinden (siehe Abschnitt 3.5), und 

um diese Interaktionen müssen wir das Aufgabenmodell erweitern. 

Aus Sicht des Benutzers entspricht ein Dialogzustand der „Position“ des Benutzers 

innerhalb des Dialogs. Der Zustand wird dem Benutzer in Form einer Webseite visualisiert, 

diese Seite muss die Interaktionen der gerade ausgeführten Aufgaben zusammenfassen. 

Wir werden den Aufgaben Eingabe- und Ausgabe-Elemente zuordnen, welche 

es dem Benutzer erlauben, die Aufgabe zu bearbeiten und den Dialogzustand damit 

zu verändern. Dazu müssen geeignete Interaktionselemente definiert werden, wir werden 

auf die komponentenbasierten Interaktionselemente der Präsentationsmodellierung 

(siehe Abschnitt 2.6.4) zurückgreifen, welche den modularen Aufbau einer Webseite 

ermöglichen. 

101

6 Aufgabenbasierte Dialogfragmente für Web-Anwendungen 

6.2 Erweitertes Beispiel 

Bevor wir die Dialoginformationen in das Interaktionsmodell integrieren, wollen wir 

erst das Beispiel aus dem vorigen Kapitel erweitern. Auf dem Weg zur Beispielanwendung 

– ein Kleinanzeigenmarkt als Web-Anwendung – integrieren wir den Aufgabenbaum 

Kontaktinformationen angeben in ein größeres Aufgabenmodell Kleinanzeige 

erstellen, welches wir in diesem Kapitel als Beispiel verwenden. 

Abbildung 6.1 zeigt das erweiterte Aufgabenmodell. Aufgrund der Zugriffsrolle benutzer 

der Wurzelaufgabe Kleinanzeigen erstellen dürfen nur registrierte und angemeldete 

Benutzer Kleinanzeigen erstellen, dies aber beliebig oft (Kardinalität 0 – ∞). 

Zum Erstellen einer Kleinanzeige muss der Benutzer vier Unteraufgaben in einer beliebigen 

Sequenz ausführen. 

Die Unteraufgabe Informationen angeben fasst einige allgemeine Informationen einer 

Kleinanzeige zusammen, die in beliebiger Abfolge eingegeben werden können: 

den Titel der Kleinanzeige, den angestrebten Preis, den Zustand der angebotenen Ware 

und eine allgemeine Beschreibung. 

Die Unteraufgabe Bild auswählen erlaubt es dem Benutzer, ein vorher erstelltes Bild 

auszuwählen und zu der Kleinanzeige hinzuzufügen. Diese Aufgabe ist optional, nicht 

jede Kleinanzeige muss mit einem Bild versehen sein. 

Mit der Unteraufgabe Tags zuweisen werden der Kleinanzeige Metainformationen 

in Form von Tags zugeordnet. Tags 31 sind kurze Schlüsselwörter, die die Kleinanzeige 

beschreiben. Im Gegensatz zu einer einmaligen Einordnung in hierarchische Kategorien, 

kann eine Kleinanzeige mit beliebig vielen Tags beschrieben sein. Dies erlaubt eine 

flexible Suche der Kleinanzeigen, welche wir in der Gesamtanwendung noch vorstellen 

werden. 

Die Unteraufgabe Kontaktinformationen angeben ist das aus dem vorigen Kapitel 

übernommene Beispiel. Zu einer Kleinanzeige sollen ein bis fünf Kontaktinformationen 

(Adress- oder Telefonkontakte) angegeben werden können. 

6.2.1 Finale Benutzerschnittstelle eines Dialogzustands 

Nachdem wir das Aufgabenmodell vorgestellt haben, wollen wir betrachten, wie der 

zur Laufzeit generierte Dialog aussehen könnte. Zu diesem Zweck werden wir nicht 

den Dialog als Ganzes betrachten (welcher aufgrund der Generierung zur Laufzeit auch 

nicht statisch darstellbar ist), sondern eine Momentaufnahme des Dialogs in Form eines 

möglichen Dialogzustandes. Auf Basis der Dialogzustände werden wir zeigen, wie wir 

eine Benutzerschnittstelle für ein Aufgabenmodell dynamisch erzeugen können. 

Wir wollen den Dialogzustand betrachten, in dem der Benutzer die Aufgaben Vorname 

angeben und Nachname angeben für die Erstellung einer Kontaktadresse einer 

Kleinanzeige ausführt. Zu diesem Dialogzustand könnte der Benutzer über den folgenden 

Weg unter Berücksichtigung der Hierarchiebeziehungen des Aufgabenmodells 

gelangen: 

31 aus dem Engl. für: Etikett, Markierung 

102

Kleinanzeige 

erstellen 

Kardinalität = 0…∞ 


ZugriffsRollen = »benutzer« 


angeben 

Tags 

zuweisen 

Bild 

auswählen 

Informationen 

angeben 



existierende 


Telefonnummer 

angeben 

Adresse 

angeben 

Beschreibung 

angeben 

Preis 

angeben 

Zustand 

angeben 

Titel 

angeben 

ZugriffsRollen = »admin« 



Rufnummer 

angeben 

Rufname 

angeben 

Stadt 

angeben 

Strasse 

angeben 

Name 

angeben 

Nachname 

angeben 

Vorname 

angeben 

103 

Abbildung 6.1: Beispiel Aufgabenmodell – Kleinanzeige Erstellen


Abbildung 6.2: Beispiel einer finalen Benutzerschnittstelle (HTML Seite) 

1. Der Benutzer möchte eine Kleinanzeige erstellen und fängt die Aufgabe Kleinanzeige 

erstellen an. 

2. Weil diese eine beliebige Sequenz der Unteraufgaben vorgibt, muss erst eine der 

Unteraufgaben ausgewählt werden. Der Benutzer wählt Kontaktinformationen 

angeben. 

3. Der Benutzer wählt die Aufgabe Adresse angeben aus der Selektion der Unteraufgaben. 

4. Aufgrund der Sequenz wird die Aufgabe Name angeben mit ihren Unteraufgaben 

Vorname angeben und Nachname angeben gestartet 

Diesen letzten Dialogzustand wollen wir genauer betrachten. Abbildung 6.2 zeigt die 

Benutzerschnittstelle, die aufgrund des Dialogzustandes für den Benutzer generiert 

werden könnte. Zu erkennen ist dabei, dass einzelne Elemente der Benutzerschnittstelle 

zu unterschiedlichen Aufgaben des Aufgabenmodells gehören, z. B. die Eingabe 

des Vornamens zu Vorname angeben oder die Überschrift und die darunter befindliche 

Navigationsleiste, die anscheinend zur Wurzelaufgabe Kleinanzeige erstellen gehören. 

Diese Zusammenhänge werden wir in diesem Kapitel untersuchen, jetzt bleibt nur festzuhalten, 

dass die Benutzerschnittstelle eine mögliche Repräsentation des beschriebenen 

Dialogzustandes ist. 

Die Benutzerschnittstelle in Abbildung 6.2 ist, gemäß der Kategorisierung in Abschnitt 

3.6.2, eine finale Benutzerschnittstelle, realisiert in HTML. Für die weitere Betrachtung 

ist dies zu detailliert, wir werden uns zur Modellierungszeit auf abstrakte 

und konkrete Benutzerschnittstellen beschränken, welche dann zur Laufzeit in eine finale 

Variante transformiert werden. 

104

6.2.2 Konkrete Benutzerschnittstelle 


Aufgrund der Beschränkung auf Web-Anwendungen werden wir die Modellierung der 

abstrakten und der konkreten Benutzerschnittstelle als einen Modellierungsschritt betrachten. 

Während eine abstrakte Benutzerschnittstelle z. B. auch in ein Sprachdialogsystem 

umsetzbar ist, ist bei der konkreten Benutzerschnittstelle der Kontext vorgegeben, 

also z. B. grafische Benutzeroberfläche. Anders als die finale Benutzerschnittstelle 

ist dies immer noch abstrakt genug, um daraus eine Web-Anwendung, ein lokales 

Anwendungsprogramm oder eine Anwendung für mobile Endgeräte zu erzeugen, für 

unseren Zweck also mehr als ausreichend. 

Wie in Abschnitt 2.6.4 beschrieben und in Anhang A aufgeführt, werden wir ein komponentenbasiertes 

Framework verwenden, um die konkrete Benutzeroberfläche zu beschreiben. 

Wir verwenden exemplarisch das JSF-Framework [McClanahan u. a., 2004], 

die anderen Frameworks sind aber gleichwertig und können bei Bedarf verwendet werden. 

Wir wollen eine, zu der finalen Benutzerschnittstelle aus Abbildung 6.2 passende, 

konkrete Benutzerschnittstelle vorstellen (siehe Listing 6.1). Von der grafischen Darstellung 

wird weitgehend abstrahiert und nur noch die Struktur und der Inhalt modelliert. 

Textausgaben werden mit OutputText umgesetzt, Eingaben mit InputText, Beschreibungen 

der Eingabefelder mit OutputLabel und Schaltflächen mit CommandButton. Die 

Gestaltung wird erst bei der Generierung der finalen Benutzeroberfläche hinzugefügt, 

zum Beispiel, dass der erste ausgegebene Text als Überschrift erscheinen soll, und dass 

die Schaltflächen rechtsbündig angeordnet sind. 

Grundlegende Strukturierung der Komponenten, wie z. B. ein zweispaltiges Layout, 

wird im Beispiel über die Komponente PanelGrid erstellt: Sämtliche Unterkomponenten 

werden zweispaltig angeordnet. Die Komponente NavigationBar erzeugt die komplexe 

Navigationsleiste. 

Die abstrakte Variante, der dieser konkreten zugrunde liegt, lässt sich ablesen, indem 

von den Komponentennamen nur der erste Teil verwendet wird. Dann werden z. B. 

aus den zwei verschiedenen Komponenten OutputText und OutputLabel die gleiche 

abstrakte Komponente Output. Details finden sich dazu im Anhang, wir verwenden im 

Folgenden immer die konkrete Form. 

Um das Beispiel zu vereinfachen, haben wir die Komponenten noch nicht an das Domänenmodell 

der Anwendungsschicht angebunden. Das Beispiel zeigt z. B. nicht, wo 

die Eingabefelder ihre eingegeben Werte ablegen oder welche Aktionen die Schaltflächen 

auslösen. Die fehlenden Anbindungen sind im Beispiel durch Auslassungspunkte 

gekennzeichnet (. . . ). Auf die Anbindung werden wir noch genauer eingehen. 

Auch sind die Ausgaben noch statischer Natur, zugunsten einer mehrsprachigen Anwendung 

sollten diese dynamisch eingefügt werden. Dies ist aber für unsere Betrachtung 

nicht relevant und kann bei Bedarf integriert werden. 


Das Beispiel in diesem Abschnitt haben wir zum besseren Verständnis rückwärts entwickelt 

(von der fertigen Webseite zur abstrakten Beschreibung). Klassischerweise werden 

105


Listing 6.1: Beispiel einer konkreten Benutzerschnittstelle (XML Format) 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

von der Benutzerschnittstelle zur Modellierungszeit zuerst die konkrete und dann die 

finale Version erstellt. Wir wollen im Folgenden betrachten, wie wir die konkrete Benutzerschnittstelle 

(z. B. wie in Listing 6.1) auf Basis eines Aufgabenmodells zur Laufzeit 

erstellen können. Die weitere Umwandlung in eine finale Benutzeroberfläche können 

wir den bestehenden Ansätzen überlassen (siehe Abschnitt 2.6.4). 

6.3 Anbindung an das Aufgabenmodell 

Um zu dem Ergebnis in Listing 6.1 zu gelangen, wollen wir schauen, wie wir das Aufgabenmodell 

in die Generierung der Benutzerschnittstelle integrieren können. Die Semantik 

und temporalen Abhängigkeiten des Aufgabenmodells sind in der konkreten 

Benutzerschnittstelle nur noch indirekt zu erkennen. Wir wollen die Benutzerschnittstelle 

so an das Aufgabenmodell binden, dass dieses als zentrales Gerüst für die Generierung 

dient und zur Laufzeit für den Benutzer zugeschnittene Dialoge generieren 

kann. 

6.3.1 Überblick 

Abbildung 6.3 zeigt den Ablauf der Generierung einer Benutzerschnittstelle, welcher in 

jedem Dialogschritt durchlaufen wird. Der Benutzer löst ein Ereignis und damit einen 

Dialogschritt von einem Dialogzustand in einen folgenden aus. Der Ablauf besteht aus 

drei Phasen: 

106 

1. Die Aufgabenbearbeitung verwaltet eine Instanz des Aufgabenmodells und bildet 

das Benutzerereignis auf Aufgabenaktionen ab (Aufgabe starten, Aufgabe 

stoppen, etc.). Der Zustand aller Aufgaben entspricht dem Dialogzustand. Die folgenden 

Phasen dienen dazu, die veränderten Aufgabenzustände zu visualisieren. 

2. Die Seitengenerierung holt sich die zu visualisierenden Aufgabenzustände und 

generiert eine konkrete Benutzerschnittstelle (z. B. wie in Listing 6.1). Dazu wer-

Benutzerereignis 

Aufgabenverarbeitung 


Zustandsbaum 


konkrete 

Benutzerschnittstelle 

1 2 3 

Seitengenerierung 

Dialogfragmente 

Seitentransformation 

Komponenten 

Abbildung 6.3: Generierung der Benutzerschnittstelle zur Laufzeit 

den zusätzlich noch sogenannte Dialogfragmente verwendet, auf die wir in Kürze 

genauer eingehen werden. 

3. Die Seitentransformation übernimmt dann den letzten Schritt, die Generierung 

der finalen Benutzerschnittstelle aus der konkreten. Dazu wird jede Komponente 

der konkreten Benutzerschnittstelle in eine HTML-Darstellung transformiert, um 

eine endgültige HTML-Seite zu erhalten. 

In den folgenden Abschnitten werden wir die zusätzlich zum Aufgabenmodell zu modellierenden 

Informationen vorstellen und den hier beschriebenen Überblick über den 

Ablauf verfeinern. 

6.3.2 Dialogfragmente 

Die Aufgaben sollen unabhängig voneinander Interaktionselemente zu der konkreten 

Benutzerschnittstelle beitragen können. Im Umkehrschluss bedeutet dies auch, dass zu 

jedem Interaktionselement der konkreten Benutzerschnittstelle genau eine Aufgabe 

zugeordnet ist. Es tauchen keine Elemente auf, die nicht einer Aufgabe entstammen, 

und auch keine Elemente, die mehreren Aufgaben zugeordnet sind. 

In diesem Abschnitt wollen wir untersuchen, welche Elemente der konkreten Benutzerschnittstelle 

welchen Aufgaben des Aufgabenmodells in Abbildung 6.1 zuzuordnen 

sind. Die Menge aller Elemente, die einer Aufgabe zuzuordnen sind, nennen wir im 

Folgenden Dialogfragment einer Aufgabe, weil aus diesen Fragmenten die Benutzerschnittstelle 

des Dialogs zur Laufzeit erzeugt wird. 

Bei den klassischen Ansätzen (z. B. in [Vanderdonckt und Limbourg, 2004] und [Mori 

u. a., 2003]), werden nur den Blattaufgaben Interaktionselementen zugeordnet. Alle 

Nicht-Blattaufgaben dienen dort nur der Strukturierung und werden weiter verfeinert. 

Wir werden, wie in Abschnitt 5.4.4 beschrieben, den Nicht-Blattaufgaben die Möglichkeit 

geben, zu der Benutzerschnittstelle beizutragen. Dies hat den Vorteil, dass die 

Oberaufgabe den Teil der Benutzeroberfläche beschreiben kann, der für alle Unteraufgaben 

gleich ist, z. B. eine Überschrift. Dies erlaubt uns Redundanzen zu vermeiden, 

indem wir wiederholt verwendete Interaktionselemente weiter oben in der Aufgabenhierarchie 

einfügen, wo sie für alle Unteraufgaben angezeigt werden. Die Interakti- 

HTML 

Seite 

107


onselemente, die wir als Dialogfragment der Wurzelaufgabe zuordnen, werden immer 

angezeigt. 

Wie gelangen wir jetzt von der konkreten Benutzerschnittstelle aus Listing 6.1 zu aufgabenspezifischen 

Dialogfragmenten? Die Dialogfragmente der aktiven Blattaufgaben 

können am einfachsten identifiziert werden, mit diesen werden wir anfangen. Zu der 

Aufgabe Vorname angeben gehören die Elemente aus Zeile 8 und 9: 

 

 

Listing 6.2: Dialogfragment – Vorname angeben 

Zu der Aufgabe Nachname angeben gehören die Elemente aus Zeile 6 und 7: 

 

 

Listing 6.3: Dialogfragment – Nachname angeben 

Die Oberaufgabe dieser beiden Blattaufgaben, Name angeben, trägt den Text aus 

Zeile vier, das Layout aus Zeile 5 und 10, sowie die Schaltfläche zum Fortsetzen aus Zeile 

11 bei. Fortsetzen würde diese und die Unteraufgaben beenden und in der Sequenz zu 

der Aufgabe Straße angeben weiterleiten. 

Listing 6.4: Dialogfragment – Name angeben 

 

 

 

 

Zur nächsten Oberaufgabe, Adresse angeben, gehört ein weiterer Text aus Zeile 3, 

damit für den Benutzer ersichtlich ist, in welchem Teilbaum des Aufgabenmodells er 

sich befindet: 

Listing 6.5: Dialogfragment – Adresse angeben 

 

Die Oberaufgabe Kontaktinformationen angeben fügt keine weiteren Elemente in 

die Benutzerschnittstelle ein, deshalb ist das Dialogfragment leer. 

Die Wurzelaufgabe Kleinanzeige erstellen trägt die Überschrift aus Zeile 1 und die 

Navigationsleiste aus Zeile 2 zur Benutzerschnittstelle bei. Die Navigationsleiste hätte 

auch zur Unteraufgabe Adresse angeben gehören können, denn diese definiert ebenfalls 

eine Sequenz, die man visualisieren könnte. Aber um die Übersichtlichkeit zu wahren, 

stellt die Navigationsleiste die länger andauernde beliebige Sequenz dieser Aufgabe 

dar. Auch die Abbrechen-Schaltfläche aus Zeile 12 gehört zu dieser Aufgabe. Die 

Schaltfläche wird diese Aufgabe und damit den gesamten Dialog der Kleinanzeigeneingabe 

zurücksetzen und die getätigten Eingaben verwerfen: 

108

Listing 6.6: Dialogfragment – Kleinanzeige erstellen 

 

 

 


Auch für die bis jetzt noch nicht betrachteten Aufgaben können Dialogfragmente 

modelliert werden. Zur Laufzeit würde dann, basierend auf den Zuständen der Aufgaben, 

eine konkrete Benutzerschnittstelle erzeugt werden. Um diese wie in Listing 6.1 

zu erzeugen, fehlen allerdings noch einige Details: 

In welchen Zuständen können sich Aufgaben befinden und wie wirken sich diese 

auf die Generierung der Benutzeroberfläche aus? 

Wie können die Dialogfragmente verschachtelt werden, sodass der Aufbau der 

Benutzerschnittstelle möglichst flexibel ist? Eine einfache Verkettung der Dialogfragmente 

reicht nicht aus, um die oben skizzierte Benutzerschnittstelle zu erstellen. 

Diese Aspekte werden wir in den nächsten beiden Abschnitten behandeln. 

6.3.3 Zustandsautomat für Aufgaben 

Wie wir im letzten Abschnitt gezeigt haben, kann die Benutzerschnittstelle in Form 

von Dialogfragmenten den Aufgaben zugeordnet werden. In diesem Abschnitt werden 

wir zeigen, dass dies noch nicht detailliert genug ist und die Dialogfragmente den 

Zuständen der Aufgaben zugeordnet werden sollten. Z. B. kann zum Starten einer Aufgabe 

eine Schaltfläche dargestellt werden, die dem Benutzer erlaubt, die Aufgabe zu 

beginnen. Während der Ausführung der Aufgabe darf diese Schaltfläche nicht mehr 

verfügbar sein, sondern z. B. Interaktionselemente zur Eingabe des Namens. Bevor wir 

die verschiedenen Möglichkeiten der Anbindung vorstellen, wollen wir erst einen Blick 

auf die Zustände des Aufgabenautomaten werfen. 

Ein Aufgabenautomat (siehe Abbildung 6.4, basierend auf [Bomsdorf, 2007]) ist ein 

Zustandsautomat, welcher zur Laufzeit für jede Aufgabe angelegt wird und ihren Lebenszyklus 

verwaltet. Der Aufgabenautomat besteht aus den Zuständen, in denen sich 

die Aufgabe befinden kann und aus den Zustandsübergängen, die aufgrund von Ereignissen 

ausgelöst werden. Alle Aufgabenautomaten eines Aufgabenmodells werden 

getrennt voneinander verwaltet und nur über Konditionen bezüglich der Zustandsübergänge 

miteinander verknüpft. Eine Aufgabe kann z. B. nur gestartet werden, wenn die 

Oberaufgabe und dessen Hierarchiebeziehung dies erlaubt. Im nächsten Kapitel werden 

wir das Verhalten zur Laufzeit genauer betrachten, an dieser Stelle werfen wir nur 

einen Blick auf die möglichen Zustände und deren Einfluss auf die Modellierung einer 

Benutzerschnittstelle: 

Initialisiert Bevor eine Aufgabe ausgeführt werden kann, befindet sie sich im Anfangszustand 

Initialisiert. Sowohl der Start- als auch der Endzeitpunkt sind noch nicht 

bekannt (start(X ) = ende(X ) = ∅) 32 . Von diesem Zustand aus kann die Aufgabe 

32 Wir beziehen uns im Folgenden auf die temporalen Definitionen aus Abschnitt 5.2. 

109


überspringen 

starten 

Initialisiert 

zurücksetzen 

Übersprungen Ausgeführt 

zurücksetzen 

unterbrechen 

Gestartet fortsetzen Unterbrochen 

beenden abbrechen abbrechen 

Abbildung 6.4: Zustandsautomat einer Aufgabe 

Abgebrochen 

bearbeitet (Start-Ereignis) oder aber übersprungen (Überspringen-Ereignis) werden. 

Gestartet Während die Aufgabe bearbeitet wird, befindet sich der Aufgabenautomat 

im Zustand Gestartet. Auf der Zeitachse bedeutet dies, dass der Startzeitpunkt 

start(X ) in der Vergangenheit liegt, der Endzeitpunkt ende(X ) aber noch undefiniert 

ist. In diesem Zustand kann der Benutzer auch weitere Unteraufgaben unter 

Beachtung der Hierarchiebeziehungen starten und beenden. Im regulären Ablauf 

kann die Aufgabe beendet werden (ende Ereignis) oder aber in den Anfangszustand 

zurückgesetzt werden (zurücksetzen Ereignis). Die Ereignisse unterbrechen 

und abbrechen sind Sonderfälle, auf die wir bei den entsprechenden Zielzuständen 

eingehen. 

Ausgeführt Die Aufgabe wurde beendet. Sowohl der Start- als auch der Endzeitpunkt 

liegen in der Vergangenheit. Keine Unteraufgabe befindet sich mehr im Zustand 

Gestartet 33 . Die weitere Bearbeitung des Aufgabenmodells kann nur noch in den 

Oberaufgaben stattfinden. Wenn die Wurzelaufgabe beendet wurde, ist die Bearbeitung 

des Aufgabenmodells abgeschlossen. 

33 Dies bedeutet nicht, dass alle Unteraufgaben sich im Zustand Ausgeführt befinden, z. B. bleiben bei einer 

Selektion alle Unteraufgaben bis auf eine im Zustand Initialisiert 

110


Übersprungen Die Aufgabe wurde übersprungen und nicht ausgeführt. Der Start- ist 

gleich dem Endzeitpunkt (start(X ) = ende(X ) = ∅). Die Unteraufgaben werden 

ebenfalls nicht ausgeführt. Die Aufgabe ist damit zwar nicht ausgeführt, aber 

doch beendet. Folgeaufgaben, z. B. in einer Sequenz, können dann angefangen 

werden. 

Unterbrochen Um das Konzept der Unterbrechbarkeit (siehe Abschnitt 5.6) umzusetzen, 

fügen wir den Zustand Unterbrochen in den Aufgabenautomaten ein. Falls 

eine Unterbrechung bei einer gestarteten und unterbrechbaren Aufgabe stattfindet, 

wird der Aufgabenkontext gespeichert und kann später beim Fortsetzen 

wiederhergestellt werden. Falls die Aufgabe nicht unterbrechbar ist, wird sie zurückgesetzt 

und befindet sich beim Fortsetzen im Zustand Initialisiert, alle bereits 

getätigten Eingaben dieser Aufgabe und aller Unteraufgaben sind verloren. 

Abgebrochen Die Aufgabe wurde aufgrund eines Systemfehlers abgebrochen. Der Aufgabe 

wird die Möglichkeit gegeben, auf diesen Abbruch zu reagieren, z. B. um 

Ressourcen freizugeben, eine Email zu versenden, etc. Zu einer normalen Abarbeitung 

kann aber nicht mehr übergegangen werden. Dies ist nicht zu verwechseln 

mit dem regulären Zurücksetzen einer gestarteten Aufgabe in den Zustand Initialisiert, 

bei der die aktuelle Bearbeitung verworfen wird und die Aufgabe erneut 

gestartet werden kann. 

Die Zustände Unterbrochen und Abgebrochen sind besondere Zustände, die für die 

Modellierung der Benutzerschnittstelle nicht relevant sind, in beiden Fällen ist der Dialog 

unterbrochen und es wird keine Benutzerschnittstelle generiert. 

Im Gegensatz dazu können die restlichen Zustände einer Aufgabe mit Dialogfragmenten 

versehen werden. Im Zustand Initialisiert könnte beispielsweise eine kurze Beschreibung 

der bevorstehenden Aufgabe ausgegeben werden, zusammen mit einer 

Schaltfläche, um die Aufgabe zu starten und eventuell einer Schaltfläche, um die Aufgabe 

zu überspringen. Im Zustand Gestartet erfolgt die eigentliche Bearbeitung der 

Aufgabe, mit den entsprechenden Interaktionselementen und einer Schaltfläche, um 

die Aufgabe zu beenden. Im Zustand Ausgeführt könnte nochmal eine Zusammenfassung 

der Eingaben erscheinen und im Zustand Übersprungen eine Ausgabe, dass die 

Aufgabe übersprungen wurde. 

Algorithmus zur Kontrolle der Aufgabenautomaten 

Der erste Schritt in der Übersichtsgrafik (siehe Abbildung 6.3) verarbeitet ein Benutzerereignis 

und verändert die Aufgabenautomaten. Als Ergebnis kann der folgende 

Schritt auf die neuen Zustände der Aufgabenautomaten zugreifen und diese darstellen. 

Die Aufgabenautomaten werden zur Laufzeit nicht alle gleichzeitig initialisiert, sondern 

nur nach Bedarf. Die initiale Menge der Aufgabenautomaten AA (und damit der 

erste Dialogzustand) besteht nur aus dem Aufgabenautomaten der Wurzelaufgabe im 

Zustand Initialisiert. Erst wenn eine Aufgabe gestartet wurde, werden Aufgabenautomaten 

für die Unteraufgaben angelegt. Wenn eine Aufgabe beendet wird, werden die 

111


Aufgabenautomaten der Unteraufgaben wieder entfernt. Die Menge der Aufgaben, 

zu denen es Aufgabenautomaten in AA gibt, wird immer ein Teilbaum des gesamten 

Aufgabenmodells sein. Dieser Teilbaum entspricht dem aktuellen Dialogzustand und 

enthält die aktuell vom Benutzer bearbeiteten Aufgaben. 

Jedes zu verarbeitende Benutzerereignis ist von einer Benutzerschnittstelle ausgelöst 

worden, welche in einem vorherigen Durchlauf – basierend auf den aktuellen Zuständen 

der Aufgabenautomaten – erstellt wurde. Die Zuordnung des Benutzerereignisses 

zu einer Aufgabe geschieht über den folgenden eindeutigen Pfad: Jedes Benutzerereignis 

wird genau von einem Interaktionselement (meist einem CommandButton) ausgelöst. 

Die komponentenbasierten Web-Frameworks können diese Arbeit abnehmen und 

liefern uns zum Ereignis auch das auslösende Interaktionselement. Jedes Interaktionselement 

ist eindeutig einem Dialogfragment und jedes Dialogfragment eindeutig einer 

Aufgabe zugeordnet. Für die gefundene Aufgabe muss auch ein Aufgabenautomat in 

AA existieren. 

Falls diese Beziehungskette an einer Stelle unterbrochen ist, so ist das Benutzerereignis 

illegal erzeugt worden (z. B. durch die Verwendung des Zurück-Knopfes des Browsers) 

und die gesamte Verarbeitung muss unterbrochen werden. Alle Aufgabenautomaten 

in AA werden unterbrochen und der Benutzer bekommt im nächsten Schritt die 

Möglichkeit, den Dialog fortzusetzen. 

Im Regelfall haben wir jedoch zum Benutzerereignis den passenden Aufgabenautomaten 

gefunden und können eine Transition einleiten. Der Aufgabenautomat wird 

die Vorbedingungen für die Transition, z. B. die der temporalen Relationen, überprüfen 

und ggf. einen Zustandswechsel veranlassen. Im Anschluss daran wird überprüft, ob der 

Automat gestartet wurde und damit die Aufgabenautomaten für die Unteraufgaben 

initialisiert oder ob der Automat beendet wurde und damit die Aufgabenautomaten 

der Unteraufgaben entfernt werden müssen. 

Basierend auf den neuen Aufgabenzuständen wird später eine aktualisierte Benutzerschnittstelle 

generiert. Der Algorithmus 1 fasst dieses Vorgehen zusammen. 

Aufgabenautomaten zur Laufzeit 

Der zu visualisierende Dialogzustand entspricht den Zuständen der aktuellen Aufgabenautomaten, 

dessen Aufgaben einen Teilbaum des Aufgabenmodells sind. Das umgangssprachliche 

Beispiel aus Abschnitt 6.2.1 können wir jetzt mit dem Algorithmus 

auf die Aufgabenautomaten übertragen, um das Konzept zu verdeutlichen. Der Initialzustand 

des Dialogs ist nur der initialisierte Aufgabenautomat der Wurzelaufgabe. Zu 

diesem Zustand sollte ein Dialogfragment existieren, welches dem Benutzer die Möglichkeit 

gibt, die Aufgabe zu starten: 

Kleinanzeige erstellen (Initialisiert) 

Der Benutzer entscheidet sich, eine Kleinanzeige zu erstellen und startet die Wurzelaufgabe. 

Die Aufgabenautomaten der Unteraufgaben werden initialisiert. In der Wurzelaufgabe 

wird nicht mehr das Dialogfragment vom Zustand Initialisiert verwendet, 

sondern das vom Zustand Gestartet. 

112


Eingabe : Benutzerereignis E, Menge der Aufgabenautomaten AA 

Ausgabe : veränderte Menge der Aufgabenautomaten AA 

Beginn 

Suche das E auslösende Interaktionselement I ; 

Suche das Dialogfragment F zu dem I gehört; 

Suche die Aufgabe A der F zugeordnet ist; 

Suche den Aufgabenautomat AA ∈ AA von A; 

wenn AA nicht gefunden wurde dann 

// illegales Benutzerereignis; 

für jedes Aufgabenautomat AA ∈ AA tue 

Unterbreche AA; 

Ende 

Breche Verarbeitung ab; 

sonst 

// reguläres Benutzerereignis; 

Löse das Ereignis E auf AA aus; 

unterscheide Zustand von AA tue 

Fall Gestartet 

für jedes Unteraufgabe UA von A tue 

wenn ∄ Aufgabenautomat für UA in AA dann 

Erzeuge initialen Aufgabenautomat UAA für UA; 

Füge UAA der Menge AA hinzu; 

Ende 

Fall Übersprungen,Ausgeführt 


wenn ∃ Aufgabenautomat für UA in AA dann 

Entferne Aufgabenautomat von UA aus der Menge AA; 

Ende 

Ende 

Ende 

Ende 

Algorithmus 1 : Verarbeitung der Aufgabenereignisse 

Kleinanzeige erstellen (Gestartet) 

Informationen angeben (Initialisiert) 

Bild auswählen (Initialisiert) 

Tags zuweisen (Initialisiert) 

Kontaktinformationen angeben (Initialisiert) 

Der Benutzer wählt aus der beliebigen Sequenz die Aufgabe Kontaktinformationen 

angeben aus und startet diese, ihre Unteraufgaben werden initialisiert. Die Aufgaben 

auf gleicher Ebene (Bild auswählen, etc.) bleiben initialisiert, können aber nicht gestartet 

werden, solange die Aufgabe Kontaktinformationen angeben ausgeführt wird, 

weil die Sequenz eine parallele Ausführung verbietet. 

113






Kontaktinformationen angeben (Gestartet) 

Adresse angeben (Initialisiert) 

Telefonnummer angeben (Initialisiert) 

existierende Adresse kopieren (Initialisiert) 

Der Benutzer entscheidet sich bei der Selektion, eine Adresse anzugeben. Die entsprechende 

Aufgabe wird vom Benutzer gestartet, ihre Unteraufgaben initialisiert. Bis 

jetzt hat der Benutzer die Aufgaben manuell gestartet, aber an dieser Stelle bietet sich 

für das Laufzeitsystem die Möglichkeit, den Dialog automatisch anzupassen: 

Aufgrund der strikten Sequenz muss die Aufgabe Name angeben als nächstes ausgeführt 

werden und wird deshalb automatisch gestartet. Ihre Unteraufgaben werden 

daraufhin initialisiert. 

Diese Unteraufgaben können arbiträr ausgeführt werden, aufgrund von Kontextinformationen 

entscheidet sich das Laufzeitsystem in diesem Fall beispielsweise, 

die beiden Aufgaben ebenfalls automatisch zu starten und gleichzeitig auszuführen. 

Hätte der Benutzer nur wenig Platz für die Benutzeroberfläche zur Verfügung, 

so könnte das Laufzeitsystem diese Aufgaben auch nacheinander ausführen. 

Auf die möglichen automatischen Adaptionen des Laufzeitsystems werden wir später 

noch genauer eingehen. Als Ergebnis entsteht folgender Aufgabenbaum: 






Adresse angeben (Gestartet) 

Name angeben (Gestartet) 

Vorname angeben (Gestartet) 

Nachname angeben (Gestartet) 

Straße angeben (Initialisiert) 

Stadt angeben (Initialisiert) 



In den meisten Fällen werden Dialogfragmente den Gestartet-Zuständen der Aufgaben 

zugeordnet, weil in diesem Zustand die Aufgabe von dem Benutzer zu bearbeiten 

ist. Wie beschrieben können in den Initialisiert-Zuständen Interaktionselemente zum 

Starten einer Aufgabe definiert werden, aber wir werden später zeigen, wie sich z. B. 

das Beenden-Ereignis einer Aufgabe mit dem Start-Ereignis einer Folgeaufgabe ver- 

114


knüpfen lässt und damit die Dialogfragmente in den Initialisiert-Zuständen zum Starten 

einer Aufgabe selten notwenig macht. 

Die bis jetzt identifizierten Dialogfragmente im Beispiel sind deshalb auch alle den 

Gestartet-Zuständen zugeordnet. Prinzipiell könnten aber auch die nicht gestarteten 

oder bereits beendeten Aufgaben in der Benutzerschnittstelle erscheinen, wenn den 

Zuständen der entsprechenden Aufgaben Dialogfragmente zugeordnet wären. Um bei 

dem einfachen Beispiel zu bleiben, blenden wir alle Aufgabenautomaten aus, zu denen 

wir keine Dialogfragmente identifiziert haben (alle außer den gestarteten Aufgaben), 

übrig bleibt folgender Aufgabenbaum: 




Name angeben (Gestartet) 

Vorname angeben (Gestartet) 

Nachname angeben (Gestartet) 

Abbildung 6.5: Dialogzustand als Teilbaum mit Aufgabenzuständen 

Basierend auf diesem Teilbaum mit Aufgabenzuständen (ab jetzt Aufgabenzustandshierarchie 

genannt) wollen wir im nächsten Abschnitt die Komposition der Benutzerschnittstelle 

betrachten. 

6.3.4 Aufgabenbasierte Komposition 

Die Aufgabenzustandshierarchie aus dem letzten Abschnitt gibt an, welche Dialogfragmente 

zur Laufzeit zu einer konkreten Benutzerschnittstelle zusammengesetzt werden 

sollen. Uns fehlt aber noch die Information, wie diese auf der Seite angeordnet werden 

sollen. Nach den ersten Konzepten in [Betermieux und Bomsdorf, 2007] und [Betermieux 

und Bomsdorf, 2008], werden wir hier eine aufgabenbasierte Komposition für 

Interaktionsmodelle vorstellen. 

Wir wollen das Aufgabenmodell mit seiner Hierarchie auch als Basis für das Layout 

heranziehen, d. h., das Aufgabenmodell gibt die grundlegende Struktur der Benutzerschnittstelle 

vor, in die sich die Dialogfragmente einfügen müssen. Für diesen Ansatz 

stellen wir folgende Forderungen: 

Die Dialogfragmente der Unteraufgaben müssen sich innerhalb des Dialogfragments 

der Oberaufgabe einfügen. 

Dialogfragmente sind unabhängig voneinander definiert, d. h., das Dialogfragment 

der Oberaufgabe kann keine Annahmen über die Dialogfragmente der Unteraufgaben 

machen. Abhängig vom Zustand der Unteraufgaben zur Laufzeit 

müssen evtl. unterschiedlich viele Dialogfragmente eingefügt werden. 

115


Dazu wird das Laufzeitsystem bei jedem Dialogschritt zuerst die Aufgabenzustandshierarchie 

erstellen. Danach wird es, angefangen bei der Wurzelaufgabe, die zugehörigen 

Dialogfragmente entlang der Hierarchie miteinander verknüpfen. Wir haben bereits 

im Beispiel Dialogfragmente identifiziert. Uns fehlen aber noch die Mittel – unter 

Berücksichtigung der Forderungen – um zur Laufzeit mit den Dialogfragmenten und 

den Zuständen der Aufgaben die Benutzerschnittstelle zu generieren. 

Problematisch sind vor allem die Dialogfragmente der Nicht-Blattaufgaben, weil diese 

eventuell Dialogfragmente von Unteraufgaben integrieren müssen (Dialogfragmente 

der Unteraufgaben nennen wir ab jetzt Unterfragmente). Betrachten wir die Aufgabe 

Name angeben. Laut Aufgabenzustandshierarchie aus dem letzten Abschnitt müssen 

die Unterfragmente von Vorname angeben und Nachname angeben für den betrachteten 

Dialogzustand integriert werden. Das zu der Aufgabe Name angeben gehörende 

Dialogfragment lautete: 

Listing 6.7: Dialogfragment (Ursprungsversion) – Name angeben 

 

 

 

 

Um das Ergebnis in Abbildung 6.2 zu erhalten, sollte die Überschrift vor den Unterfragmenten 

erscheinen, die Schaltfläche fortsetzen jedoch erst dahinter. Wir benötigen ein 

Platzhalterelement, welches in die Dialogfragmente eingefügt werden kann: 

Insert: Definiert einen Platzhalter innerhalb eines Dialogfragments, welches zur Laufzeit 

mit den Dialogfragmenten der Unteraufgaben gefüllt wird. Die Unterfragmente 

werden in der Reihenfolge der Definition ihrer Aufgaben im Aufgabenmodell 

nacheinander eingefügt. 

Mit diesem Platzhalterelement können wir in einem Dialogfragment eine Einfügeposition 

der Unterfragmente bestimmen, die Dialogfragmente bleiben weiterhin unabhängig 

voneinander. 

Wir müssen unsere Dialogfragmente revidieren und bei der Modellierung das Platzhalterelement 

angeben, damit das Laufzeitsystem die Dialogfragmente korrekt verschachteln 

kann. Das revidierte Dialogfragment sieht jetzt folgendermaßen aus: 

Listing 6.8: Dialogfragment (revidierte Version) – Name angeben 

 

 

 

 

 

Die restlichen drei Oberaufgaben können wir ebenfalls mit dem Platzhalterelement 

ausstatten. Bei der Aufgabe Adresse angeben sollen die Unterfragmente hinten angefügt 

werden: 

116


Listing 6.9: Dialogfragment (revidierte Version) – Adresse angeben 

 

 

Bei der Aufgabe Kontaktinformationen angeben war das Dialogfragment leer. Damit 

aber trotzdem noch Unterfragmente angezeigt werden können, füllen wir es nur mit 

dem Platzhalterelement: 

 

Listing 6.10: Dialogfragment (revidierte Version) – Kontaktinformationen angeben 

Bei der Wurzelaufgabe Kleinanzeige erstellen sollen die Überschrift und die Navigationsleiste 

vor den Unterfragmenten erscheinen, die Schaltfläche dahinter, also: 

Listing 6.11: Dialogfragment (revidierte Version) – Kleinanzeige erstellen 

 

 

 

 

Mit diesen revidierten Dialogfragmenten kann das Laufzeitsystem jetzt die konkrete 

Benutzerschnittstelle erstellen. Bei jedem Dialogschritt aktualisiert es zuerst die Aufgabenzustandshierarchie 

und fängt die Seitengenerierung mit dem Dialogfragment der 

Wurzelaufgabe an. Anstelle des Insert-Elements fügt es die Dialogfragmente der Unteraufgaben 

ein, in diesem Fall das der Aufgabe Kontaktinformationen angeben. Dieses 

wird rekursiv fortgeführt, bis die Blattaufgaben anstelle des letzten Insert Elements eingefügt 

wurden. Weil zwei Blattaufgaben gestartet sind, müssen zwei Dialogfragmente 

anstelle des Insert-Elements der Aufgabe Name angeben eingefügt werden. Diese werden 

in der Reihenfolge der Definition der Aufgaben im Aufgabenmodell (zuerst der 

Vorname, dann der Nachname) nacheinander eingefügt. 

Algorithmus zur Seitengenerierung 

Der Algorithmus zur Seitengenerierung lässt sich als rekursive Funktion definieren (siehe 

Algorithmus 2 auf Seite 118). Initial wird diese Funktion vom Laufzeitsystem mit der 

Wurzelaufgabe als Eingabeparameter aufgerufen. 

Weil die Rekursion nur aufgerufen wird, wenn ein Aufgabenautomat zu einer Unteraufgabe 

existiert, wird sie nur die aktuelle Aufgabenzustandshierarchie durchlaufen. 

Die Seite wird rekursiv zusammengesetzt und entspricht am Ende der Rekursion unseren 

Vorgaben. Dieser Algorithmus definiert auch zwei Detailverbesserungen: 

Wenn zu einer Aufgabe kein Dialogfragment definiert ist, wird die Seite trotzdem 

mit den Dialogfragmenten der Unteraufgaben gefüllt. Ein leeres Dialogfragment 

nur mit einem Insert-Element, wie wir in Kontaktinformationen angeben revidiert 

haben, kann weggelassen werden. 

117


Eingabe : Aufgabe A 

Ausgabe : Generierte Seite S 

Beginn 

Erzeuge leere Seite S; 

Hole Dialogfragment F für den aktuellen Zustand von A; 

wenn F existiert dann 

Suche Position pos des Insert-Element in F ; 

wenn pos existiert dann 

Füge den Anfang von F bis zu pos in S ein; 

sonst 

Füge F komplett in S ein; 

Ende 

Ende 


wenn Aufgabenautomat für UA existiert dann 

Rufe generiereSeite(UA) auf und hänge Ergebnis an S an; 

Ende 

Ende 

wenn F existiert und pos existiert dann 

Hänge den Schluss von F ab pos an S an; 

Ende 

Liefere S zurück; 

Ende 

Algorithmus 2 : generiereSeite(A) 

Wenn zu einer Aufgabe zwar ein Dialogfragment angegeben wurde, dieses aber 

kein Insert-Element enthält, so fügt der Algorithmus zuerst dieses Dialogfragment 

komplett in die Seite ein und danach die Dialogfragmente der Unteraufgaben. 

Wenn ein Insert-Element fehlt, existiert immer ein scheinbar implizites Insert-Element 

am Ende des Dialogfragments, damit Dialogfragmente der Unteraufgaben 

nicht unterdrückt werden. Die Revision des Dialogfragments von Adresse angeben 

ist also optional, sollte aber aus Gründen der besseren Lesbarkeit beibehalten 

bleiben. 

Ergebnis der Seitengenerierung 

Abbildung 6.6 zeigt das Ergebnis der Seitengenerierung. Die Hierarchie (welche der 

Aufgabenzustandshierarchie entspricht) und die Aufgabennamen sind zur Übersicht 

eingefügt worden, um den rekursiven Ablauf des Algorithmus zu verfolgen. Die generierte 

Seite enthält nur die fett gedruckten Interaktionselemente ohne hierarchische 

Informationen. 

Die generierte konkrete Benutzerschnittstelle ist fast identisch mit der gewünschten 

konkreten Benutzerschnittstelle aus Listing 6.1. Auf die Abweichung bezüglich der Reihenfolge 

der Vor- und Nachname-Dialogfragmente werden wir später noch eingehen. 

118

Kleinanzeige erstellen 

 

 

Kontaktinformationen angeben 

 

Adresse angeben 


Name angeben 

 

 

Vorname angeben 

 

 

Nachname angeben 

 

 

 

 

 

Abbildung 6.6: Generierte konkrete Benutzerschnittstelle 

Exkurs in dynamische Oberflächengenerierung 

Bei den klassischen Ansätzen wird das Aufgabenmodell in ein Dialogmodell umgewandelt 

und dann für jeden Dialogzustand eine Benutzeroberfläche modelliert. Dabei muss 

beachtet werden, dass die zwischen zwei Zuständen konstanten Elemente der Benutzeroberfläche 

auch an gleicher Stelle in der finalen Benutzeroberfläche erscheinen, damit 

der Benutzer nicht durch eine „springende“ Benutzeroberfläche irritiert wird. Aus 

Sicht des Aufgabenmodells ist es z. B. egal, wie zwei parallel abzuarbeitende Aufgaben 

ausgeführt werden. Für den Benutzer sollten diese Aufgaben aber nicht von Dialogzustand 

zu Dialogzustand die Platzierung in der Benutzeroberfläche wechseln, sondern 

möglichst stabil dargestellt werden. 

Wir gehen dieses Problem durch die Definition von Dialogfragmenten für die Oberaufgaben 

an. Dadurch verhindern wir nicht nur Redundanz in den Dialogfragmenten 

der Unteraufgaben, sondern stabilisieren auch das Layout der Benutzeroberfläche insgesamt. 

Wenn wir die Zustandswechsel in den Aufgabenautomaten während eines 

längeren Dialogs betrachten, so ist erkennbar, dass der untere Teil der Aufgabenzustandshierarchie 

sich häufig ändert und sich dementsprechend in der Benutzeroberfläche 

häufig wechselnde Dialogfragmente erscheinen. Je weiter allerdings der obere 

Teil der Hierarchie betrachtet wird, desto stabiler werden die Aufgabenzustände (sie 

ändern sich nicht mehr von Dialogschritt zu Dialogschritt, sondern sind über längere 

Zeiträume stabil) und desto länger werden auch die zugeordneten Dialogfragmente 

dargestellt. Die Wurzelaufgabe ist schließlich fast während des ganzen Dialoges im Ge- 

119


Aufgabe 

1 -dialog AufgabenDialog -aufgabenZustaende 

ZustandsInformation 

0..1 

0..6 

-dialogfragment : String 

ausgefuehrt 

initialisiert 

-zustand 

gestartet 

 

AufgabenZustand 

uebersprungen 

unterbrochen 

abgebrochen 

Abbildung 6.7: Dialogspezifische Erweiterung des Aufgabenmetamodells 

startet Zustand und das zugehörige Dialogfragment wird entsprechend oft dargestellt. 

Weil in den Dialogfragmenten der oberen Aufgaben auch die sonst redundanten Interaktionselemente 

(Titelbereich, Menüstrukturen, Überschriften, etc.) zusammengefasst 

sind, werden diese in der Benutzeroberfläche auch immer wieder an dieselbe Stelle 

generiert. 

Nach einem Dialogschritt wird die generierte Benutzeroberfläche für die unveränderten 

Aufgabenzustände gleich bleiben und nur abweichen für die unteren Aufgaben mit 

veränderten Zuständen. Mit unserem Ansatz haben wir deshalb eine konsistente Positionierung 

der Dialogfragmente sichergestellt. Beim klassischen Ansatz ist dies nicht 

sichergestellt und der Entwickler muss bei der Modellierung jedes Dialogzustandes die 

Einhaltung des Layouts überprüfen. 

6.3.5 Erweiterung des Aufgabenmetamodells 

Definition 

Nach der Herleitung von der fertigen Webseite zu zustandsabhängigen Dialogfragmenten 

wollen wir unser Aufgabenmetamodell um diese Dialoginformationen erweitern 

(Ursprungsmodell siehe Abbildung 5.20). Zur besseren Trennung der dialogspezifischen 

Informationen von der klassischen Aufgabendefinition führen wir einen optionalen 

Aufgabendialog ein, welcher genau einer Aufgabe zugeordnet sein muss (siehe Abbildung 

6.7). Diese Trennung soll auch die Modellierungsschritte widerspiegeln: Zuerst 

wird das Aufgabenmodell erstellt, danach die dialogspezifischen Erweiterungen modelliert. 

Reine Aufgabeneditoren könnten diese Erweiterungen später ausblenden und 

nur das Aufgabenmodell bearbeiten. 

Der Aufgabendialog ist im Augenblick nur eine Komposition aus bis zu sechs zustandsspezifischen 

Informationen (Zustandsinformation). Später werden wir sehen, dass 

es weitere dialogspezifische Informationen einer Aufgabe gibt, welche wir dort einfügen 

können. Jede Zustandsinformation muss ihren zugeordneten Zustand definieren 

und kann eine Referenz auf ein Dialogfragment enthalten. Der Übersichtlichkeit halber 

werden wir die Dialogfragmente nicht im Aufgabenmodell darstellen, sondern hier 

nur in Textform besprechen. Mit der Erweiterung des Metamodells kann zu jedem Zustand 

einer Aufgabe ein Dialogfragment zugeordnet werden. 

120

Beispiel 

6.4 Anbindung des Domänenmodells 

Wir betrachten erneut unser Beispiel und erweitern das Interaktionsmodell um die zustandsspezifischen 

Dialogfragmente (siehe Abbildung 6.8). Wir beschränken uns auf die 

Aufgaben, die wir bereits in den vorhergehenden Abschnitten textuell betrachtet haben, 

die restlichen Aufgaben können analog erweitert werden. 


Wir haben gezeigt, wie mit Hilfe von Aufgabenautomaten und einem speziellen Platzhalterelement 

zur Laufzeit eine Benutzerschnittstelle aus den Dialogfragmenten generiert 

werden kann. Im nächsten Abschnitt werden wir die Anbindung des Domänenmodells 

an unsere generierte Benutzerschnittstelle betrachten. 


Das Domänenmodell zur Modellierung der Anwendungslogik ist unabhängig von der 

Modellierung der Benutzerschnittstelle. Es existieren verschiedene Vorgehensweisen, 

wie Benutzerschnittstellen modellbasiert erstellt werden können: 

Systemzentrierter Ansatz: Zuerst wird das Domänenmodell modelliert, das die gewünschte 

Funktionalität abbildet. Danach wird eine Benutzeroberfläche modelliert, 

die die Anwendung entsprechend ihrer Vorgaben anspricht. Dies ist auch die 

zwangsläufig erforderliche Vorgehensweise, wenn zu einem bestehenden Altsystem 

34 eine neue Benutzerschnittstelle erstellt werden soll. 

Benutzerzentrierter Ansatz: Zuerst wird eine Benutzerschnittstelle modelliert, die 

dem Benutzer ermöglicht, die gewünschte Aufgabe zu erfüllen. Danach wird für 

die Benutzerschnittstelle das Domänenmodell erstellt. 

Unser Ansatz unterstützt beide Vorgehensweisen, der Modellierer der Benutzerschnittstelle 

ist bei dem ersten Ansatz allerdings gefordert, die Funktionen der Anwendungslogik 

zu berücksichtigen, also nur Benutzerschnittstellen zu entwerfen, die sich mit den 

gegebenen Funktionen umsetzen lassen. 

Wenn sowohl das Domänenmodell als auch die Benutzerschnittstelle modellbasiert 

erstellt werden, können beide Vorgehensweisen auch parallel eingesetzt werden, z. B. 

könnte zuerst ein einfaches Domänenmodell erstellt werden, zu dem dann eine Benutzerschnittstelle 

auf Basis eines Aufgabenmodells erstellt wird. Nach einer Verfeinerung 

des Aufgabenmodells könnte dann auch eine Anpassung des Domänenmodells notwendig 

sein. Änderungen in einem Modell ziehen also evtl. Änderungen im anderen 

Modell nach sich. 

34 engl: legacy system 

121


122 

Name 

angeben 

zustand = gestartet 

dialogfragment = »enterName« 

Vorname 

angeben 


dialogfragment = »enterFirstName« 

Adresse 

angeben 



dialogfragment = »enterAdress« 

Strasse 

angeben 


dialogfragment = »enterStreet« 

Nachname 

angeben 


dialogfragment = »enterLastName« 

Kleinanzeige erstellen 





dialogfragment = »createClassified« 


angeben 



dialogfragment = »enterContacts« 

Stadt 

angeben 


dialogfragment = »enterCity« 

Abbildung 6.8: Beispiel Interaktionsmodell – Dialogfragmente (Auszug)

6.4.1 Arten der Anbindung 


Nach dem klassischen MVC-Ansatz (siehe Abschnitt 2.6.1) ist das Domänenmodell das 

Model und die Benutzerschnittstelle die View. Die Frage, die wir in diesem Abschnitt 

beantworten werden, lautet, wie unsere View – in Form von Interaktionselementen der 

Dialogfragmente – auf das Modell zugreifen kann. Wir müssen dabei zwei verschiedene 

Zugriffsarten unterscheiden: 

Anbindung von Aktionen: Interaktionselemente, die in einer Benutzerschnittstelle 

eine neue Anfrage an die Anwendung auslösen, müssen die weitere Verarbeitung 

beschreiben. Wir verwenden dazu das Action-Attribut der Interaktionselemente, 

um eine Methode im Domänenmodell aufzurufen. Dieses wird vom Laufzeitsystem 

ausgewertet, wenn der Benutzer das jeweilige Interaktionselement „ausgelöst“ 

hat. Beispiele hierfür sind: 

– Links (CommandLink) 

– Absendeknöpfe von Formularen (CommandButton) 

Charakteristisch für diese Interaktionselemente ist, dass jeder Anfrage genau eine 

Aktion zugeordnet ist (der Benutzer kann nur einen Knopf gedrückt haben, um 

eine Anfrage auszulösen) und damit für das Laufzeitsystem eindeutig definiert 

ist, wo die Anwendung aufgerufen werden muss. Diese Interaktionselemente erzeugen 

entweder direkt oder indirekt Ereignisse für die Aufgabenverarbeitung 

(siehe Abbildung 6.3). Indirekt, indem die aufgerufene Methode ein Ereignis generiert 

und direkt, indem sie eine vom Laufzeitsystem vordefinierte Methode zum 

Auslösen eines konkreten Benutzerereignisses verwendet. 

Anbindung von Werten: Viele Interaktionselemente verwenden oder verändern 

nur den Wert einer Variable im Domänenmodell, dazu muss die Referenz auf die 

Variable vom Modellierer über das Value-Attribut des Interaktionselements angegeben 

werden. Beispiele hierfür sind: 

– Texteingabefelder (InputText) werden an eine Zeichenkettenvariable gebunden 

– Checkboxen (SelectBooleanCheckbox) werden an boolesche Variablen gebunden 

Charakteristisch für diese Interaktionselemente ist, dass sie nicht bei jeder Veränderung 

eine Anfrage auslösen, sondern erst bei einer anderweitig ausgelösten 

Anfrage (z. B. über ein Interaktionselement mit einer Anbindung an einer Aktion) 

gesammelt übertragen werden. Das Laufzeitsystem sorgt für den Abgleich der 

Werte, d. h., beim Ausliefern der Seite werden die Werte aus der Anwendung in 

die Formularelemente eingefügt und beim Verarbeiten einer Rückantwort werden 

die übermittelten Formulardaten in die Variablen der Anwendung übertragen. 

Zusammengefasst bedeutet dies, dass ein Interaktionselement mit einem Action-Attribut 

eine Anfrage auslöst, die zuerst die Werte von anderen Interaktionselementen mit 

123


einem Value-Attribut mit der Anwendung abgleicht und danach eine Methode aufruft. 

Damit das Laufzeitsystem diese Attribute als Zugriff auf die Anwendung interpretiert, 

muss der Inhalt speziell ausgezeichnet werden. Im von uns verwendeten Web-Framework 

geschieht das über die sogenannte Expression Language, die dem Laufzeitsystem 

anweist, den in #{ und } geklammerten Text als Referenz auf ein Domänenobjekt zu 

interpretieren, also verbindet z. B. das Eingabefeld 

mit einer Zeichenkette name in dem Objekt Person 35 . 

Die Definition eines Methodenaufrufs in einem Action-Attribut verläuft analog, diesmal 

wird jedoch keine Variable sondern eine Methode referenziert, z. B. könnte das 

Interaktionselement zum Absenden und Validieren der Vor- und Nachname-Eingaben 

lauten. 

Die Umsetzung dieser Vorgaben können wir den bestehenden komponentenbasierten 

Web-Frameworks überlassen, welche diese Funktionalität üblicherweise bereitstellen. 

Für uns ist vor allem interessant, wie wir die Vorgaben des Aufgabenmodells bei der 

Modellierung der Domänenanbindung umsetzen können. In den nächsten Abschnitten 

werden wir deshalb die offenen Fragen der aufgabenspezifischen Kapselung der Anwendungslogik 

diskutieren und unsere Lösung in Form von Domänenzugriffsobjekten 

vorstellen. 

6.4.2 Offene Fragen beim Domänenzugriff 

Um die Probleme bei der Domänenanbindung aufzuzeigen, werden wir zuerst ein Domänenmodell 

für unser Beispiel vorstellen und dann auf die offenen Fragen eingehen. 

Domänenmodell für unser Beispiel 

Abbildung 6.9 zeigt ein exemplarisches Domänenmodell, welches die Verarbeitung der 

Daten unseres Beispiels – ein Kleinanzeigenmarkt als Web-Anwendung – vornehmen 

soll. Die Domänenmodellierung werden wir nur kurz betrachten, auf diesem Feld gibt 

es bereits etablierte und mächtige Modellierungssprachen und -notationen, wir werden 

die UML verwenden [OMG, 2005]. 

Das Domänenmodell ist minimal, aber alle notwendigen Funktionalitäten, um die 

Aufgaben unseres Aufgabenmodells zu erfüllen, sind abgedeckt. Im Sinne der Drei- 

Schichten-Architektur für Web-Anwendungen (siehe Abschnitt 2.4.2) wird die Anwendungsschicht 

in eine Schnittstelle (Service) und eine Implementation (Domain) aufgeteilt. 

35 Wir haben in unseren Dialogfragmenten bereits einige Elemente mit Value-Attributen mit statischem Text 

definiert. Weil aber alle Value-Attribute Referenzen auf die Anwendung erlauben, könnten wir mithilfe der 

Expression Language auch die OutputText-Elemente dynamisch zur Laufzeit aus der Anwendung füllen, also z. B. 

würde bei jedem Aufruf den Titel aus der Anwendung 

holen. 

Manche Interaktionselemente (wie das gerade erwähnte OutputText) schreiben bei der nächsten Anfrage 

nicht wieder in die referenzierte Variable. Bei reinen Ausgabeelementen, bei denen der Benutzer die Werte nur 

angezeigt bekommt aber nicht verändern kann, wird das Laufzeitsystem den Wert der Variable nur lesen aber 

niemals schreiben. 

124

Service Interface 

ClassifiedsService 

+getClassifiedById() 

+persistClassified() 

+getClassifiedList() 

+getTagById() 

+getTagByName() 

+persistTag() 

+getTagList() 

+addFavorite() 

+getFavorites() 

Domain 

Favorites 

-owner : User 

Tag 


-tags 

0..* 

-classifieds 

0..* 

Classified 

-owner : User 

-title : String 

-description : String 

-price : BigDecimal 

-creationDate : Date 

 

ClassifiedCondition 

-NEW 

-USED 


BaseEntity 

-condition 

-pictureData 

-classified 

Abbildung 6.9: Domänenmodell – Beispiel 

PictureData 

-data : byte"[]" [0..*] 

PhoneContact 

-contacts 

-phoneNumber : String 

1..* 

Contact 

-firstName : String 

-lastName : String 

AddressContact 

-street : String 

-city : String 

Die Domain enthält die Entitäten der Anwendung und ihre Verknüpfungen. Im Zentrum 

steht die Kleinanzeige (Classified), welche die Informationen der Kleinanzeige 

sammelt. Der Titel, die Beschreibung und der Preis sind beispielsweise als Attribute 

abgelegt, andere Informationen sind als eigene Entitäten über Beziehungen mit der 

Kleinanzeige verbunden. Über eine Kompositionsbeziehung sind z. B. Bilddaten (PictureData) 

und eine Liste von Kontaktinformationen (Contact) angebunden. Letztere werden 

in die Unterklassen Adresskontakt (AddressContact) und Telefonkontakt (Phone- 

Contact) verfeinert. Mit der Entität Tag werden die Tags abgebildet, jede Kleinanzeige 

kann einer beliebigen Anzahl Tags zugeordnet sein. Mit den Favoriten (Favorites) wird 

eine Liste verwaltet, in der Benutzer ausgewählte Kleinanzeigen aufnehmen können, 

um diese zu beobachten und schneller darauf zuzugreifen. Die Oberklasse BaseEntity 

enthält übergreifende Funktionalität, um Klassen zu persistieren. Ein objektrelationaler 

Integrationsdienst (Object-Relational-Mapping, ORM) kann Instanzen dieser Klassen 

automatisch in einer relationalen Datenbank speichern. 

Die Service-Schnittstelle kapselt den Zugriff auf die Domäne in Form von vordefinierten 

Methoden. Dies hat verschiedene Vorteile: 

Abstraktion vom Domänenmodell: Die Schnittstelle ermöglicht den abstrakten Zugriff 

auf das Domänenmodell in Form von Methoden, die Anwendungsfällen entsprechen. 

Die Domäne kann, ohne die darauf zugreifenden Schichten zu beeinflussen, 

umorganisiert und erweitert werden, solange der Schnittstellenvertrag 

erhalten bleibt. 

Zentrale Stelle für die Berechtigungsprüfung: Nur beim Eintritt in die Schnittstellenmethoden 

muss die Autorisation des Benutzers überprüft werden. 

Definierte Transaktionsgrenzen: Die Veränderungen am Domänenmodell (und damit 

an der Datenbank) werden in einer Transaktion gekapselt. Die Transaktion 

wird beim Eintritt in die Schnittstellenmethode gestartet, umfasst alle Verände- 

125


rungen der Domänenobjekte, und wird beim Verlassen der Methode abgeschlossen. 

Falls im Laufe der Methode ein Fehler auftritt, wird ein Rollback stattfinden, 

der alle veränderten Entitäten wieder zurücksetzt. Methoden, die nur Informationen 

aus der Domäne holen (get. . . ), werden in einer read only transaction ausgeführt. 

Die Schnittstellenmethoden müssen von unserer Benutzerschnittstelle angesprochen 

werden. Die Methode persistClassified() erzeugt z. B. eine Kleinanzeige mit Bild und 

Kontaktinformationen und müsste von der Benutzerschnittstelle am Ende der Aufgabe 

Kleinanzeige Erstellen aufgerufen werden. Das Dialogfragment könnte beispielsweise 

folgendes Interaktionselement enthalten: 

ContactBean 

-lastName 

-firstName 

-street 

-city 

-phoneNumber 

-contactsAccess 

+createAddressContact() 

+createPhoneContact() 

6.4.3 Domänenzugriffsobjekte 






+getTagById() 


+persistTag() 

+getTagList() 



Abbildung 6.10: Domänenzugriffsobjekte – Beispiel 

Unser Ansatz fordert, dass jede Aufgabe, die auf die Domäne zugreift, ein Domänenzugriffsobjekt 

erhält, in dem dieser Zugriff gekapselt ist. Ähnlich wie Dialogfragmente 

werden diese der Aufgabendefinition hinzugefügt, gelten allerdings für die gesamte 

Lebensdauer einer Aufgabe und sind nicht einem Aufgabenzustand zugeordnet. Alle 

Dialogfragmente einer Aufgabe können nur auf dieses Domänenzugriffsobjekt zugreifen, 

um mit der Domäne zu kommunizieren. Abbildung 6.10 zeigt das Domänenzugriffsobjekt 

ContactBean, welches für die Aufgabe Kontaktinformationen angeben und ihre 

Unteraufgaben erstellt wurde. Das Interaktionselement aus der Aufgabe Vorname angeben 

könnte beispielsweise folgendermaßen auf das Domänenzugriffsobjekt zugreifen: 

. Am Ende der Aufgabe Adresse 

angeben könnte dann, nachdem andere Interaktionselemente die restlichen erforderlichen 

Werte im Domänenzugriffsobjekt gefüllt haben, eine Aktion ausgelöst werden, 

also z. B.: . 

Diese erst würde den Adresskontakt speichern. 

Wegen der Ähnlichkeit zwischen einem Telefon- und einem Adresskontakt, kann das 

gleiche Domänenzugriffsobjekt auch alternativ zur Erzeugung eines Telefonkontaktes 

verwendet werden, die aufzurufende Aktion wäre dann createPhoneContact(). 

Unterbrechbarkeit im Bezug auf Domänenzugriffsobjekte 

Mit der Einführung von Domänenzugriffsobjekten müssen wir die Unterbrechbarkeit 

von Aufgaben genauer betrachten. Wir haben die Unterbrechungsstrategien im Aufgabenmodell 

bereits abgebildet und in den Aufgabenautomaten einen Zustand für unterbrochene 

Aufgaben vorgesehen. Das Laufzeitsystem kann Unterbrechungen – wie 

in Abschnitt 5.6 definiert – feststellen und den Zustand der Aufgabenautomaten basierend 

auf den Unterbrechungsstrategien selbstständig persistieren und wieder herstellen. 

Wenn jedoch ein Domänenzugriffsobjekt zu einer Aufgabe existiert, dann enthält 

dieses Informationen, die zum Zustand der Aufgabe zu zählen sind, z. B. bereits eingegebene 

Vor- und Nachnamen eines Adresskontaktes. Wenn die Aufgabe unterbrochen 

wird, müssen diese Informationen ebenfalls persistiert werden, damit diese beim Fortsetzen 

wieder verfügbar sind. 

127


StateHolder 

+saveState() : Object 

+restoreState( state ) 

+isTransient() : boolean 

ContactBean 















+getTagById() 


+persistTag() 

+getTagList() 



Abbildung 6.11: Domänenzugriffsobjekte – Unterbrechbarkeit 

Domänenzugriffsobjekte sind jedoch vom Modellierer zu erstellen, das Laufzeitsystem 

kann nicht automatisch erkennen, welche Werte zum Zustand gehören und damit 

zu persistieren sind. Zu diesem Zweck existiert eine generische Schnittstelle StateHolder, 

die alle Domänenzugriffsobjekte implementieren müssen 36 . Sie enthält drei Methoden 

zur Sicherung und Wiederherstellung des Zustandes: 

isTransient(): Wird vom Laufzeitsystem aufgerufen, wenn die Aufgabe des Domänenzugriffsobjekts 

unterbrochen wurde. Über einen booleschen Rückgabewert 

kann das Domänenzugriffsobjekt entscheiden, ob es flüchtige(true) oder zu persistierende 

(false) Informationen enthält. 

saveState(): Wird vom Laufzeitsystem aufgerufen, wenn isTransient() den Wert false 

zurückgeliefert hat. Alle Informationen, die zu persistieren sind, müssen in ein 

Objekt verpackt und als Rückgabewert an das Laufzeitsystem übergeben werden. 

Dieses persistiert das Objekt gemeinsam mit dem Aufgabenzustand. 

restoreState(): Wird vom Laufzeitsystem aufgerufen, wenn eine unterbrochene 

Aufgabe fortgesetzt wird. Dazu wird neue Instanz des Domänenzugriffsobjekts 

erzeugt und diese Methode im Anschluss daran aufgerufen. Als Parameter wird 

das Objekt übermittelt, welches vorher persistiert wurde, das Domänenzugriffsobjekt 

ist selbstständig für die Wiederherstellung seines Zustandes aus dem Zustandsobjekt 

verantwortlich. 

Abbildung 6.11 zeigt unser Domänenzugriffsobjekt für die Aufgabe Kontaktinformationen 

angeben, welches die Schnittstelle StateHolder implementiert. IsTransient() liefert 

false zurück, saveState() und restoreState() persistieren alle vom Benutzer bereits 

eingegebenen Attribute. 

36 Viele Sprachen liefern eine Serializable-Schnittstelle, welche eine automatische Persistierung eines Objektzustandes 

ermöglicht. Wir werden diese nicht verwenden, weil die persistierten Informationen zu stark von der 

Implementierung der Klasse abhängen, die Deserialisierung würde scheitern, wenn sich die Struktur der Klasse 

geändert hat. Wir gehen davon aus, dass Aufgabenzustände sehr lange persistiert sein können und überlassen 

damit dem Entwickler der Domänenzugriffsobjekte die Verantwortung, alte Zustandsobjekte korrekt einzulesen. 

128

Gültigkeitsbereich der Domänenzugriffsobjekte 


Domänenzugriffsobjekte werden automatisch erzeugt, wenn der Aufgabenautomat einer 

Aufgabe initialisiert wird und entfernt, wenn der Aufgabenautomat beendet wird. 

Damit können die Aufgabe und die Unteraufgaben auf das Domänenzugriffsobjekt zugreifen, 

alle anderen Aufgaben (auch die Oberaufgaben) haben keinen Zugriff. 

Um eine möglichst gute Wiederverwendbarkeit der Aufgaben zu erreichen, wollen 

wir aber auch den Zugriff der Unteraufgaben beschränken. Das folgende Beispiel illustriert 

das Problem: Unser Domänenzugriffsobjekt ContactBean kann beim Anlegen eines 

Adresskontaktes mittels createAddressContact() diesen nicht direkt über die Service- 

Schnittstelle persistieren, weil Classified laut Domänenmodell in Abbildung 6.9 Contacts 

als Komposition enthält, letztere also nicht für sich alleine existieren können. Wir müssen 

die Kontaktinformationen an ein Domänenzugriffsobjekt übergeben, welches zur 

Wurzelaufgabe Kleinanzeige erstellen gehört und für das Anlegen einer neuen Kleinanzeige 

zuständig ist. Beim Beenden der Wurzelaufgabe wird diese aufgerufen und 

erzeugt eine neue Kleinanzeige mitsamt der Kontaktinformationen mittels persistClassified() 

der Service-Schnittstelle. 

Problematisch ist die Übergabe der Informationen an ein in der Aufgabenhierarchie 

höher befindliches Domänenzugriffsobjekt. Prinzipiell ist dieses verwendbar, wenn wir 

allerdings die Aufgabe an einer anderen Stelle wiederverwenden wollen, dann ist die 

Kette der Oberaufgaben zur Wurzel unterschiedlich und das benötigte Domänenzugriffsobjekt 

ist eventuell nicht verfügbar. In den meisten Fällen wird allerdings kein 

Vollzugriff auf ein höheres Domänenzugriffsobjekt benötigt, sondern nur eine Möglichkeit, 

die eigenen Informationen dem anderen Domänenzugriffsobjekt mitzuteilen. 

Zu diesem Zweck sollte eine Schnittstelle zur Übergabe der Informationen definiert 

werden. Eine Wiederverwendung der Aufgabe ist dann möglich, wenn ein Domänenzugriffsobjekt 

der neuen Oberaufgaben diese Schnittstelle ebenfalls implementiert. 

Abbildung 6.12 zeigt eine Umsetzung dieses Vorgehens. Das Domänenzugriffsobjekt 

UploadBean gehört zur Aufgabe Kleinanzeige erstellen und sammelt die Informationen, 

um eine Kleinanzeige am Ende der Aufgabe mittels uploadClassified() zu erstellen. 

Unter anderem verwaltet es auch eine Liste der Kontaktinformationen contacts, 

auf das das Domänenzugriffsobjekt ContactBean der Unteraufgabe Kontaktinformationen 

angeben zugreifen möchte. Der Zugriff beschränkt sich allerdings in diesem Fall 

auf das Hinzufügen einer neuen Kontaktinformation, welches in der Schnittstelle ContactsAccess 

als Methode addContact() beschrieben ist. UploadBean implementiert diese 

Schnittstelle und fügt beim Aufruf der Methode eine Kontaktinformation der Liste hinzu. 

ContactBean enthält ein neues Attribut namens contactsAccess, welches vom Laufzeitsystem 

bei der Instanzierung mit der passenden Referenz gefüllt wird, in diesem 

Fall auf UploadBean. Beim Erstellen einer neuen Kontaktinformation kann Contact- 

Bean aus createAddressContact() die Methode contactsAccess.addContact() aufrufen, 

ohne die implementierende Klasse zu kennen 37 . 

37 Das Verfahren ist als Dependency Injection bekannt. Zwei Klassen besitzen, bis auf die implementierte Schnittstelle, 

keine Abhängigkeiten untereinander und können flexibel ausgetauscht werden. Erst zur Laufzeit wird 

über ein Mapping, in unserem Fall dem Aufgabenmodell, eine Referenz des einen Objektes in das andere injiziert. 

129


StateHolder 




ContactBean 






-contactsAccess : ContactsAccess 






ContactsAccess 

+addContact( contact ) 

UploadBean 

-title : String 

-description : String 

-price : BigDecimal 

-condition : ClassifiedCondition 

-pictureData : PictureData 

-selectedTags : Tag [0..*] 

-contacts : Contact [0..*] 

+createNewTag() : void 

+uploadClassified() : void 

+addContact( contact : Contact ) : void 

+restoreState( state : Object ) : void 







+getTagById() 


+persistTag() 

-classifiedsService +getTagList() 



Abbildung 6.12: Domänenzugriffsobjekte – Gültigkeitsbereich 

Zum besseren Verständnis der Interaktionen zur Laufzeit werden wir das Sequenzdiagramm 

des obigen Beispiels betrachten (siehe Abbildung 6.13). 

130 

1. Der Benutzer startet die Aufgabe Kleinanzeige erstellen. 

2. Das Laufzeitsystem erzeugt eine Instanz des zu der Aufgabe gehörenden Domänenzugriffsobjekts 

UploadBean. 

3. Dieses Domänenzugriffsobjekt benötigt eine Referenz auf die Service-Schnittstelle 

der Domäne. Das Laufzeitsystem instanziiert dieses und . . . 

4. . . . setzt die Referenz in dem Domänenzugriffsobjekt. 

5. Der Benutzer bekommt eine Webseite zurückgeliefert, in der eine der Unteraufgaben 

zur Erstellung einer Kleinanzeige ausgewählt werden kann. 

6. Der Benutzer wählt die Unteraufgabe Kontaktinformationen angeben. 

7. Das Laufzeitsystem erzeugt das zugehörige Domänenzugriffsobjekt ContactBean 

und . . . 

8. . . . setzt die Referenz auf das ContactsAccess implementierende UploadBean. 

9. Der Benutzer bekommt eine Webseite zurückgeliefert, in der die Art der einzugebenden 

Kontaktinformationen ausgewählt werden muss. An dieser Stelle haben 

wir im Sequenzdiagramm einige Dialogschritte ausgelassen, die nicht direkt die 

Interaktion mit den Domänenzugriffsobjekten betrifft. Der Benutzer wählt die

User 

1: task "create classified" 

5: return web page 

6: task "enter contact information" 


10: #{contactBean.firstname} 


14: #{contactBean.createAddressContact} 


20: #{uploadBean.uploadClassified} 


Runtime System 

7: create domain access 

2: create domain access 

8: setContactsAccess("uploadBean") 

12: update task states 


3: create classifieds service 

4: setClassifiedsService("classifiedsService") 

11: setFirstName() 

15: createAddressContact() 

18: remove domain access 

.contactBean : ContactBean 

21: uploadClassified() 


24: remove domain access 

16: addContact() 


uploadBean : UploadBean 

22: persistClassified(-) 

classifiedsService : ClassifiedsService 

Abbildung 6.13: Domänenzugriffsobjekte – Gültigkeitsbereich als Sequenzdiagramm 

Eingabe eines Adresskontaktes und bekommt eine Webseite zur Eingabe des Vorund 

Nachnamens zurückgeliefert. 

10. Das Interaktionselement für die Eingabe des Vornamens ist mit der Variablen firstname 

des Domänenzugriffsobjekts ContactBean verbunden. Das Laufzeitsystem 

wertet die Verbindung aus und . . . 

11. . . . setzt die Variable im passenden Domänenzugriffsobjekt. 

12. Nachdem der Wert gesetzt wurde, werden die neuen Zustände der Aufgabenautomaten 

bestimmt und . . . 

131


13. . . . eine neue Webseite zurückgeliefert. An dieser Stelle haben wir wieder einige 

Schritte ausgelassen, in denen der Benutzer die restlichen Variablen zur Erzeugung 

eines Adresskontakts eingibt. 

14. Beim Abschluss der Aufgabe Adresse angeben wird mittels einer Schaltfläche die 

Aktion createAddressContact() ausgelöst, welche vom Laufzeitsystem . . . 

15. . . . an das Domänenzugriffsobjekt ContactBean weitergeleitet wird. 

16. Im Verlauf der Abarbeitung wird die Methode addContact() der vorher gesetzten 

Referenz auf UploadBean aufgerufen. Die eingegebene Kontaktinformation befindet 

sich jetzt in der Liste der Kontaktinformationen im Domänenzugriffsobjekt 

UploadBean. 

17. Das Laufzeitsystem berechnet darauf die neuen Aufgabenzustände. Die Aufgabe 

Kontaktinformationen angeben ist beendet, sodass . . . 

18. . . . das zugehörige Domänenzugriffsobjekt ContactBean entfernt werden kann. 

19. Der Benutzer bekommt eine Webseite zurückgeliefert, in der er vier weitere Kontaktinformationen 

angeben kann, oder die übrigen Unteraufgaben zur Erzeugung 

einer Kleinanzeige aufrufen kann. Wir überspringen diese Dialogschritte 

bis zum Schluss, wo . . . 

20. . . . die eingegebenen Informationen als Kleinanzeige persistiert werden sollen. Zu 

diesem Zweck existiert auf der letzten Seite eine Schaltfläche, die mit der Aktion 

uploadClassified verbunden ist. 

21. Das Laufzeitsystem ruft die Methode uploadClassified() des Domänenzugriffsobjekts 

UploadBean auf, welche . . . 

22. . . . die Methode persistClassified() der Service-Schnittstelle aufruft, um die Kleinanzeige 

als Domänenobjekt anzulegen und zu persistieren. 

23. Die Wurzelaufgabe Kleinanzeige erstellen ist damit abgeschlossen und . . . 

24. . . . das zugehörige Domänenzugriffsobjekt kann entfernt werden. Die zustandslose 

Service-Schnittstelle muss nicht entfernt werden und kann beim nächsten Domänenzugriffsobjekt 

wiederverwendet werden. 

25. Der Benutzer bekommt eine Erfolgsbestätigung, ob die Kleinanzeige erfolgreich 

angelegt wurde. 

132

6.4.4 Unterbrechbarkeit und Nebenläufigkeit 


Das vorgestellte Aufgabenmodell ist dank Unterbrechbarkeit in der Lage, lang ablaufende 

Prozesse abzubilden. Hierbei stellt sich die Frage, inwiefern Nebenläufigkeit diese 

Abarbeitung behindern kann. In [Fowler, 2003] werden im Kapitel über Nebenläufigkeit 

System- und Geschäftstransaktionen unterschieden: 

Die Systemtransaktionen der Datenschicht (siehe Abschnitt 2.3.3) sind meist nur von 

kurzer Dauer, an die die ACID-Eigenschaften [Härder und Reuter, 1983] geknüpft werden. 

Geschäftstransaktionen hingegen bestehen aus mehreren Schritten, die der Benutzer 

durchführt (z. B. einloggen, Bankkonto auswählen und Geld überweisen). Dies lässt sich 

nur schwer mit einer einzelnen langen Systemtransaktion bewerkstelligen, die gängigen 

Transaktionssysteme arbeiten mit lang andauernden Transaktionen ineffizient, vor 

allem bei hoher nebenläufiger Last. Stattdessen wird eine Geschäftstransaktion selbst 

verwaltet und als eine Art Klammer um kurze Systemtransaktionen definiert. 

Die Bearbeitung einer Aufgabe kann als Transaktion betrachtet werden, sie lässt sich 

abbrechen (äquivalent zum abort) oder beenden (äquivalent zum commit), und sie bietet 

dank der Unterbrechungsstrategien auch eine Persistenz. Die Aufgabenhierarchie ist 

eine Transaktionshierarchie. Innerhalb von Domänenzugriffsobjekten werden die Service-Schnittstelle 

und damit auch Systemtransaktionen verwendet, z. B. um eine komplett 

eingegebene Kleinanzeige als Domänenobjekt abzulegen. Die Bearbeitung einer 

Aufgabe entspricht also der oben beschriebenen Geschäftstransaktion. 

In der folgenden Betrachtung wollen wir untersuchen, inwiefern Geschäftstransaktionen 

in Form eines hierarchischen Aufgabenmodells den ACID-Eigenschaften genügen: 

Atomarität (atomicity) Eine Aufgabe kann als atomar betrachtet werden, wenn sie erst 

am Ende der Aufgabenbearbeitung eine schreibende Systemtransaktion auslöst. 

Bis zu diesem Zeitpunkt werden die Informationen nur innerhalb der Aufgabe als 

Aufgabenzustand verwaltet. Problematisch ist das Abbrechen einer Aufgabe mit 

Unteraufgaben. Dann können bereits beendete Unteraufgaben Systemtransaktionen 

abgeschlossen haben, die jetzt nicht mehr ohne Weiteres rückstellbar sind. 

Dauerhaftigkeit (durability) Genau wie bei der Atomarität ist die Dauerhaftigkeit gewährleistet, 

wenn am Ende der Aufgabenbearbeitung eine schreibende Systemtransaktion 

ausgelöst wird. Vorher werden die Informationen nur innerhalb der 

Aufgabe als Aufgabenzustand verwaltet, welche im Falle einer Unterbrechung 

automatisch persistiert werden. 

Isolation (isolation) Isolation innerhalb einer Geschäftstransaktion ist nicht automatisch 

zu gewährleisten, weil die Aufgabe bei mehreren zeitlich versetzten Systemtransaktionen 

38 in die klassischen Isolationsprobleme läuft: lost updates, dirty 

read, etc . . . 

38 Mehrere lesende Systemtransaktionen sind laut Vorgehen bei Atomarität und Dauerhaftigkeit erlaubt, nur die 

schreibende Systemtransaktion muss am Ende erfolgen. 

133


Konsistenz (consistency) Die Konsistenz des Aufgabenzustands ist automatisch schwierig 

zu gewährleisten, weil außer den Konsistenzproblemen der Isolation die Aufgabenhierarchie 

ein zusätzliches Problem mitbringt: Unteraufgaben können auf 

den Aufgabenzustand von Oberaufgaben zugreifen und diesen verändern. Wenn 

eine Unteraufgabe abgebrochen wird, müsste diese den Aufgabenzustand der 

Oberaufgabe wiederherstellen, damit dieser konsistent ist. Wir beziehen uns hier 

aber auf die Aufgabendefinition, wonach eine Aufgabe eine Komposition ihrer 

Unteraufgaben ist und demnach ebenfalls abgebrochen werden muss. Die Kaskade 

setzt sich bis zur Wurzel des Aufgabenbaums fort, alle Aufgaben, die eventuell 

inkonsistent waren, sind demnach abgebrochen. Eine zukünftige Variante könnte 

es den Aufgaben erlauben, diese Kaskaden aufzuhalten, dann müssten aber auch 

die beschriebenen Konsistenzprobleme gelöst werden. 

Eine automatisierte Behandlung der oben erwähnten Probleme würde uns zwangsläufig 

wieder zu der Umsetzung einer Geschäftstransaktion als Systemtransaktion führen, 

mit allen verbundenen Problemen. Die oben genannten Probleme sollten deshalb beim 

Modellieren der Aufgabenhierarchie bekannt sein und entsprechend behandelt werden. 

In [Fowler, 2003] werden in Kapitel 16 verschiedene Lösungsmöglichkeiten vorgestellt, 

die unter dem Begriff offline 39 concurrency zusammengefasst werden. Im Wesentlichen 

handelt es sich dabei um Verfahren, die den konkurrierenden schreibenden 

Zugriff gewährleisten. Dem optimistischen Verfahren wird der Vorzug gegeben, 

es wird ein explizites Versionsattribut in allen Datensätzen verwendet, um zwischenzeitlich 

veränderte Datensätze zu erkennen. Im Falle einer Kollision kann mithilfe des 

Benutzers der Konflikt entweder geklärt werden (die Datensätze werden gemischt), 

oder die Geschäftstransaktion wird abgebrochen. Kombiniert mit einer grobkörnigen 

Versionierung, bei der nicht jeder Datensatz auf Kollision geprüft wird, sondern nur die 

Hauptobjekte einer Geschäftstransaktion 40 , entsteht daraus ein performantes System. 

Probleme durch Inkonsistenzen beim lesenden Zugriff können allerdings weiterhin auftreten 

und müssen spezifisch beachtet werden. 

6.4.5 Erweiterung des Aufgabenmetamodells 

Definition 

Um Domänenzugriffsobjekte in unserem Aufgabenmetamodell zu definieren, müssen 

wir den AufgabenDialog erweitern (siehe Abbildung 6.14). Aufgaben können eine beliebige 

Anzahl Domänenzugriffsobjekte verwenden, welche einen Namen und einen 

Verweis auf eine Klasse besitzen. Die Klasse verweist auf eine Klasse, die der Modellierer 

angelegt haben muss und die das Laufzeitsystem instanziieren kann. Der Name wird 

von den Dialogfragmenten verwendet, um sich auf die Klasse zu beziehen und auf die 

Werte und Methoden des Domänenzugriffsobjekts zuzugreifen. 

39 Im Sinne von: außerhalb des Transaktionssystems. 

40 Im Gegensatz zur Datenschicht kennen die Geschäftstransaktionen der Anwendungsschicht die Domänen- 

struktur 

134

Aufgabe 

-dialog 

0..1 



0..6 

AufgabenDialog 

0..* 

DomaenenZugriff 


-klasse : String 

-aufgabenZustaende 


-zustand 

-domaenenZugriffsObjekte 

-abhaengigkeiten 

 


ausgefuehrt 

initialisiert 

gestartet 

uebersprungen 

unterbrochen 

abgebrochen 

0..* 

Abhaengigkeit 

-attribut : String 

-verweis : String 

Abbildung 6.14: Erweiterung des Aufgabenmetamodells um Domänenzugriffsobjekte 

Um die Abhängigkeiten zur Laufzeit eindeutig aufzulösen, müssen wir die für ein Domänenzugriffsobjekt 

zu verwendenden Abhängigkeiten einzeln definieren, dies erfolgt 

über die Angabe eines Attributs, welches im Domänenzugriffsobjekt vom Laufzeitsystem 

gefüllt wird und über einen Verweis auf den Namen eines verfügbaren Domänenzugriffsobjekts. 

Der Verweis muss vom Laufzeitsystem aufgelöst werden können, d. h., 

es können nur Namen von Domänenzugriffsobjekten verwendet werden, die in der 

Aufgabenhierarchie auf dem Pfad der Oberaufgaben bis zur Wurzelaufgabe definiert 

wurden und deshalb bei der Aufgabenausführung verfügbar sind. Diese Bedingung 

muss ein geeigneter Aufgabeneditor abprüfen, im Aufgabenmetamodell lässt sich diese 

Beschränkung nicht modellieren. Das Laufzeitsystem sollte ebenfalls Aufgabenmodelle 

abweisen, die diese Bedingung verletzen. 

Wie im Metamodell erkennbar, kann für jede Aufgabe mehr als ein Domänenzugriffsobjekt 

definiert werden. Auch kann jedes Domänenzugriffsobjekt beliebig viele Abhängigkeiten 

in Form von Referenzen auf andere Domänenzugriffsobjekte besitzen. 

Damit können wir den Domänenzugriff in verschiedene Klassen aufteilen und einzelne 

Klassen eventuell für andere Aufgaben als Domänenzugriff wiederverwenden. 

Beispiel 

Abbildung 6.15 zeigt unser Beispiel, erweitert und fokussiert auf die Definition des Domänenzugriffs. 

Die Aufgabe Kleinanzeige erstellen definiert ein Domänenzugriffsobjekt 

uploadBean und einen Verweis auf eine Klasse com.application.UploadBean. Das 

Dialogfragment dieser Aufgabe kann über den symbolischen Namen die Methoden der 

Klasse aufrufen, z. B. action=#{uploadBean.persistClassified}. 

135


136 

Name 

angeben 

Vorname 

angeben 

Adresse 

angeben 



Strasse 

angeben 

Nachname 

angeben 

Kleinanzeige 

erstellen 




name = »uploadBean« 

klasse = »com.application.UploadBean« 


angeben 


name = »contactsBean« 

klasse = »com.application.ContactsBean« 

attribut = »contactsAccess« 

verweis = »uploadBean« 

Stadt 

angeben 

Telefonnummer 

angeben 

Rufname 

angeben 

existierende 



Rufnummer 

angeben 

Abbildung 6.15: Beispiel Interaktionsmodell – Domänenzugriff (Auszug)

6.5 Erweiterung der Aufgaben um dialogspezifische Attribute 

Die Aufgabe Kontaktinformationen angeben definiert ein Domänenzugriffsobjekt 

mit dem Namen contactsBean und den Verweis auf die Klasse com.example.access.ContactsBean. 

Für die Abhängigkeit zum Domänenzugriffsobjekt uploadBean wird das Attribut 

contactsAccess ausgewählt. Das um den Domänenzugriff erweiterte Aufgabenmodell 

kann jetzt, wie im Sequenzdiagramm in Abbildung 6.13 abgebildet, ausgeführt 

werden. 


In diesem Abschnitt haben wir erst die allgemeine Anbindung einer komponentenbasierten 

Präsentation an ein Domänenmodell vorgestellt und sind dann auf die Probleme 

und Anforderungen eines aufgabenbasierten Dialogs eingegangen. Um den direkten 

Zugriff auf das Domänenmodell zu verhindern, haben wir die Domänenzugriffsobjekte 

vorgestellt, welche die Ein- und Ausgaben der Dialogfragmente einer Aufgabe verwalten. 

Mit den Domänenzugriffsobjekten können wir die Unterbrechbarkeit der Aufgaben 

gewährleisten und den Zugriff auf das Domänenmodell kapseln. Innerhalb der 

Aufgabenhierarchie lassen sich Domänenzugriffsobjekte verknüpfen, um einen Informationsaustausch 

zu erlauben. 

Die Aufgabenhierarchie ist weiterhin die grundlegende Struktur für die Abhängigkeiten 

der Aufgaben untereinander, der Domänenzugriff folgt diesen Abhängigkeiten. 

Aufgaben können an anderer Stelle wiederverwendet werden, solange die neue Oberaufgabe 

die notwendigen Schnittstellen des Domänenzugriffsobjektes bereitstellt. 


Zusätzlich zu den beiden bereits vorgestellten Erweiterungen des Metamodells – Dialogfragmente 

und Domänenzugriffsobjekte – wollen wir in diesem Abschnitt Erweiterungen 

präsentieren, die zur Laufzeit die Ausführung der Aufgabenhierarchie als Dialog 

optimieren. Ziel ist die Generierung einer Benutzerschnittstelle, die möglichst einfach 

benutzbar ist und möglichst wenig redundante Aktionen erfordert. Bei der Aufgabenausführung 

kann z. B. Redundanz entstehen, wenn der Benutzer in einer Sequenz 

von Aufgaben nach dem Beenden einer Aufgabe die Folgeaufgabe in einem zweiten 

Schritt erst starten muss. Im Zentrum der nächsten Abschnitte steht deshalb die Frage, 

wie ein vom Benutzer ausgelöstes Ereignis Aufgabenereignisse für verschiedene Aufgaben 

erzeugen kann. 

6.5.1 Automatisches starten und beenden der Aufgaben 

Um aus einem Benutzerereignis (z. B. einem Knopfdruck) Ereignisse für mehrere Aufgaben 

(start, ende, überspringen, etc.) zu erzeugen, bieten sich zwei verschiedene Vorgehensweisen 

an: 

Zuordnungstabelle: Jedem Benutzereignis werden ein oder mehrere Aufgabenereignisse 

zugeordnet. Alle Zuordnungen werden außerhalb des Aufgabenmodells 

137


in einer Zuordnungstabelle abgelegt. Das Laufzeitsystem findet dort die zu einem 

Benutzereignis passenden Aufgabenereignisse und löst sie auf den Automaten 

aus. 

Ereignisabhängigkeiten: Jedes Benutzereignis löst ein Aufgabenereignis auf dem 

eigenen Aufgabenautomaten aus 41 . Die Folgeaufgaben können über diesen Zustandswechsel 

informiert werden und eigene Aufgabenereignisse auslösen. Ein 

Zustandswechsel der Folgeaufgaben wird ebenfalls rekursiv propagiert, wodurch 

eine Ereigniskaskade ausgelöst werden kann. 

Wir werden uns auf die zweite Vorgehensweise konzentrieren, weil diese es erlaubt, Ereignisabhängigkeiten 

direkt im Aufgabenmodell zu definieren. Wie wir zeigen werden, 

können die Ereignisabhängigkeiten definiert werden, ohne direkt auf das auslösende 

Ereignis Bezug zu nehmen. Dadurch bleiben die Aufgaben unabhängig voneinander 

und können an anderer Stelle wiederverwendet werden. 

Um dies zu erreichen, werden wir der Aufgabendefinition zwei weitere Attribute 

hinzufügen: autostart und autostop. 

Autostart 

Mithilfe des Autostart-Attributs kann die Aufgabe vom Laufzeitsystem automatisch gestartet 

werden, wenn die Bedingungen der Start-Transition dies erlauben. In der Umsetzung 

bedeutet dies, dass das Laufzeitsystem in definierten Situationen den Automaten 

ein Start-Ereignis sendet, wenn das Autostart-Attribut gesetzt ist. In folgenden Situationen 

wird das Ereignis gesendet: 

Eine Aufgabe kann automatisch gestartet werden, wenn ihre Oberaufgabe gestartet 

wurde. Wenn beispielsweise eine Aufgabe vom Benutzer gestartet wurde, 

die eine Reihe von sequenziellen Unteraufgaben besitzt, so kann die erste Unteraufgabe 

automatisch vom Laufzeitsystem gestartet werden. 

Eine Aufgabe kann automatisch gestartet werden, wenn eine Geschwisteraufgabe 

beendet wurde. Wenn im oben genannten Fall der Benutzer die erste Unteraufgabe 

der Sequenz beendet, kann das Laufzeitsystem die zweite Unteraufgabe 

automatisch starten. 

Ein Autostart ist nicht in jeder Situation sinnvoll, dies hängt vor allem von der verwendeten 

Hierarchiebeziehung ab. Bei einer Selektion ist ein Autostart der Unteraufgaben 

z. B. nicht sinnvoll, weil das Laufzeitsystem dann immer nur die erste Unteraufgabe 

starten würde, wenn die Oberaufgabe gestartet wurde; die Selektion wäre sinnlos. Ein 

Autostart einer Aufgabe ist nur dann sinnvoll, wenn diese Aufgabe vom Laufzeitsystem 

eindeutig als Folgeaufgabe zu einer anderen Aufgabe auswertbar ist, z. B. im Falle 

einer Sequenz. Die folgende Tabelle 6.1 fasst die Kombination der Hierarchiebeziehungen 

und der Ordnungen zusammen, in denen das Laufzeitsystem das Autostart-Attribut 

überhaupt auswertet. 

41 Der Aufgabenautomat kann über die folgende Beziehungskette gefunden werden: Benutzerereignis → Oberflächenelement 

→ Dialogfragment → Aufgabe → Aufgabenautomat 

138

Autostop 


Tabelle 6.1: Unterstützung von Autostart 

Sequenz Selektion Parallel Überlappend Verschachtelt Arbiträr 

strikte Ordnung 

beliebige Ordnung 

Im Gegensatz zum Autostart kann das automatische Beenden einer Aufgabe (Autostop) 

vom Laufzeitsystem nur in einer Situation angewendet werden: Wenn alle Unteraufgaben 

beendet wurden, kann die Oberaufgabe vom Laufzeitsystem automatisch beendet 

werden, wenn das Autostop-Attribut gesetzt ist. Das automatische Beenden kann unabhängig 

von den verwendeten Hierarchiebeziehungen eingesetzt werden, die Hierarchiebeziehungen 

legen nur fest, wann die Unteraufgaben als beendet gelten, z. B. 

kann bei einer Selektion bereits bei einer ausgeführten Unteraufgabe die Oberaufgabe 

ebenfalls beendet werden. 

Beispiel 

Das folgende Beispiel verdeutlicht das Verhalten von Autostart und Autostop. Nehmen 

wir an, der Benutzer führt gerade die Aufgabe Straße angeben durch, die Aufgabenzustandshierarchie 

könnte folgendermaßen aussehen: 



Name angeben (Ausgeführt) 

Straße angeben (Gestartet) 

Stadt angeben (Initialisiert) 



Wenn die Aufgabe Stadt angeben das Autostart-Attribut gesetzt hat, dann würde bei 

einem beenden der Aufgabe Straße angeben aufgrund der Sequenz diese automatisch 

gestartet. Die Aufgabenzustandshierarchie sieht dann folgendermaßen aus: 




Straße angeben (Ausgeführt) 

Stadt angeben (Gestartet) 



Wenn die Aufgaben Adresse angeben und Kontaktinformationen angeben das Autostop-Attribut 

gesetzt haben, dann würden diese beim Beenden der Aufgabe Stadt 

angeben ebenfalls automatisch beendet: 

139


Kontaktinformationen angeben (Ausgeführt) 

Adresse angeben (Ausgeführt) 


Straße angeben (Ausgeführt) 

Stadt angeben (Ausgeführt) 



Die Aufgabe Adresse angeben wurde beendet, weil die Sequenz der Unteraufgaben 

beendet ist. Die Aufgabe Kontaktinformationen angeben wurde beendet, weil die 

Selektion aufgrund der soeben beendeten Aufgabe abgeschlossen ist. Wie wir sehen, 

kann durch ein Benutzerereignis eine Kaskade von automatisch erzeugten Ereignissen 

ausgelöst werden. 

Zusammenfassung 

Autostart und Autostop sind sinnvolle Erweiterungen der Aufgabendefinition, um benutzerfreundliche 

Oberflächen zu erzeugen. Der Benutzer muss nicht mehr jedes Aufgabenereignis 

selbst erzeugen, sondern kann eine Kaskade von automatisch generierten 

Ereignissen auslösen. 

6.5.2 Aufgabenzustandsabhängige Erweiterungen 

Zustandsautomaten bieten die Möglichkeit, beim Eintritt und beim Verlassen eines Zustands 

vordefinierte Aktionen auszuführen. Auch für unsere Aufgabenautomaten ist 

das eine sinnvolle Erweiterung, z. B. um automatisch beim Beenden einer Aufgabe eine 

Methode im Domänenmodell anzusprechen. Zu diesem Zweck erweitern wir das Interaktionsmetamodell 

um zwei Aufgabenzustandsabhängige Attribute: startAktion und 

stopAktion. Die Startaktion wird beim Eintritt in den entsprechenden Zustand ausgelöst, 

die stopAktion beim Verlassen des Zustandes. Beide Attribute nehmen Aufrufe in 

Form der in Abschnitt 6.4.1 beschriebenen Anbindung von Aktionen auf. 

6.5.3 Generische Aufgabendarstellung 

In der frühen Modellierungsphase kann es sinnvoll sein, das Interaktionsmodell erst 

ohne Dialogfragmente zu erstellen, um schnell einen ersten Prototyp der Web-Anwendung 

ausführen zu können. Damit der Benutzer trotzdem eine Oberfläche angezeigt 

bekommt, wird das Laufzeitsystem eine generische Aufgabendarstellung bereitstellen, 

die Interaktionselemente definiert, um alle Aufgabenereignisse zu erzeugen. Die generischen 

Aufgabendarstellungen werden dann entsprechend der Komposition von Dialogfragmenten 

ineinander verschachtelt. 

Für die Darstellung der Hierarchie werden wir keine Baumstruktur verwenden, denn 

diese würde den zur Verfügung stehenden rechteckigen Bereich im Web-Browser nur 

unzureichend ausnutzen. Wir verwenden stattdessen einen platzoptimierten Tree-Map- 

Algorithmus (siehe [Shneiderman, 1992]), der die Elemente der Hierarchie ineinander 

140


Abbildung 6.16: Beliebige Sequenz (mit Dialogfragmenten) 

verschachtelt. Der Wurzelknoten ist ein rechteckiger Bereich, in dem die Unteraufgaben 

horizontal angeordnet werden. Deren Unteraufgaben werden dann in den jeweiligen 

Knoten vertikal angeordnet, die Rekursion setzt sich bis zu den Blättern fort. 

Für jede dargestellte Aufgabe werden für die möglichen Benutzerereignisse Schaltflächen 

angezeigt (siehe Tabelle 6.2): 

Tabelle 6.2: Generische Ereignisse für Aufgabenautomaten 

ereignis symbol 

start 

ende 

überspringen 

zurücksetzen 

Durch das Setzen des Aufgabenattributs generisch kann das Laufzeitsystem angewiesen 

werden, statt des Dialogfragments die generische Aufgabendarstellung zu verwenden. 

Wenn alle Aufgaben generisch dargestellt werden, kann das Interaktionsmodell 

als Prototyp ausgeführt werden. 


Das folgende Beispiel soll die generische Aufgabendarstellung verdeutlichen. Der Benutzer 

möchte eine Kleinanzeige erstellen und hat bereits die Aufgaben Informationen 

angeben und Tags zuweisen ausgeführt. Aus der beliebigen Sequenz verbleiben 

noch die Aufgaben Kontaktinformationen angeben und Bild auswählen, aus denen der 

Benutzer die nächste Aufgabe wählen muss. Abbildung 6.16 zeigt die Darstellung mit 

Dialogfragmenten. 

141


Abbildung 6.17: Beliebige Sequenz (generische Darstellung) 

Wenn wir in allen Aufgaben das Generisch-Attribut setzen, dann wird das Laufzeitsystem 

die eigene Aufgabendarstellung verwenden. Das Ergebnis der Seitengenerierung 

ist in Abbildung 6.17 dargestellt. 

Das Bildschirmfoto wurde von der kompletten, englischen Version unseres Beispiels 

angefertigt. Interessant ist für uns die Create Classified-Aufgabe. Die Aufgaben Enter 

Information und Select Tags sind bereits beendet (completed) und können keine weiteren 

Benutzerereignisse mehr entgegennehmen. Die Aufgabe Enter Contacts kann gestartet 

werden, die Aufgabe Select Picture kann gestartet oder übersprungen werden, 

die entsprechenden Schaltflächen sind bei den Aufgaben sichtbar. Die Aufgabe Create 

Classified kann abgebrochen werden, die Zurücksetzen-Schaltfläche wurde unten in 

der Aufgabendarstellung eingefügt. Mithilfe der Schaltflächen kann der Benutzer alle 

erlaubten Benutzerereignisse auslösen und das Interaktionsmodell prototypisch testen. 


In diesem Kapitel haben wir gezeigt, wie ein aufgabenbasiertes Interaktionsmodell um 

Dialog- und Präsentationsinformationen erweitert werden kann. Zu diesem Zweck haben 

wir Dialogfragmente und Domänenzugriffsobjekte eingeführt, sowie einige dialogspezifische 

Attribute den Aufgabendefinitionen hinzugefügt. Tabelle 6.3 und 6.4 

auf Seite 144 fassen die vorgestellten Erweiterungen zusammen. Abbildung 6.18 zeigt 

die endgültige Version unseres Interaktionsmetamodells als UML-Klassendiagramm. Im 

nächsten Kapitel werden wir zeigen, wie ein Laufzeitsystem die Interaktionsmodelle 

ausführen kann. 

142


-zustand 


Platzhalteraufgabe 

 

Ordnung 

 

AufgabenTyp 

ausgefuehrt 

initialisiert 

gestartet 

uebersprungen 

unterbrochen 

abgebrochen 


-startAktion : String 

-stopAktion : String 

-ordnung 

0..* 

beliebig 

strikt 

-typ 

abstrakt 

interaktion 

benutzer 

system 

-aufgabenZustaende 

0..6 

-referenz 

1 

Aufgabe 

 

AufgabenBeziehung 

AufgabenDialog 

-dialog 

0..1 

-gruppe : String 

-autostart : Boolean 

-autostop : Boolean 

-generisch : Boolean 

-id : String 


-beschreibung : String 

-kardinalitaet : int [2] 

-zugriffsRollen : Set 

-beziehung 

-unteraufgaben 

0..* 

sequenz 

parallel 

selektion 

verschachtelt 

ueberlappend 

arbitraer 

-elternaufgabe 

0..1 

Abhaengigkeit 

0..* -domaenenZugriffsObjekte 

DomaenenZugriff 

 

UnterbrechungsStrategie 

-attribut : String 

-verweis : String 

-abhaengigkeiten 


-klasse : String 

-strategie 

0..* 

fluechtig 

unterbrechbar 

persistent 


Abbildung 6.18: Interaktionsmetamodell – mit dialogspezifischen Erweiterungen 

143



autostart Die Aufgabe kann vom Laufzeitsystem 

als Reaktion auf ein Ereignis einer anderen 

Aufgabe automatisch gestartet wer- 

den. 

autostop Die Aufgabe kann vom Laufzeitsystem 

als Reaktion auf ein Ereignis einer anderen 

Aufgabe automatisch gestoppt wer- 

den. 

generisch Das Laufzeitsystem ignoriert die Dialogfragmente 

dieser Aufgabe und verwendet 

eine generische Aufgabendarstel- 

lung. 

domaenenZugriffsObjekte Eine Liste der zu verwendenden Domänenzugriffsobjekte 

inklusive ihrer Abhängigkeiten. 

Tabelle 6.3: Aufgabendialogdefinition 

ja nein 

ja nein 

ja nein 

ja leer 


zustand Der Zustand, für den diese Definition gilt. nein - 

startAktion Die Aktion, die ausgeführt werden soll, wenn der 

Aufgabenautomat in diesen Zustand wechselt. 

ja - 

stopAktion Die Aktion, die ausgeführt werden soll, wenn der 

Aufgabenautomat diesen Zustand verlässt. 

ja - 

dialogfragment Das Dialogfragment, dass das Laufzeitsystem zur 

Erzeugung der Benutzerschnittstelle verwendet. 

ja - 

144 

Tabelle 6.4: Aufgabenzustandsdefinition

Kapitel 7 

Architektur für das Laufzeitsystem 

Inhalt 

7.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

7.2 Ablaufübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

7.3 Architekturübersicht Laufzeitumgebung . . . . . . . . . . . . . . . . . . 147 



Ziel dieser Arbeit ist nicht nur die Definition von Interaktionsmodellen, sondern auch 

die Erstellung einer Architektur des Laufzeitsystems, mit der die Interaktionsmodelle 

ausgeführt und dargestellt werden können. Von einer allgemeinen Architektursicht aus 

der Vogelperspektive werden wir im Laufe des Kapitels einen detaillierten Blick auf die 

Kernkomponenten werfen. Dazu werden wir einen objektorientierten Grobentwurf der 

Architektur vorstellen, indem wir die Kernkomponenten bis auf Klassenebene zerlegen 

und die Beziehungen zwischen den Klassen definieren. 

Die Laufzeitumgebung ist der Teil dieser Arbeit, welcher in einer Implementierung 

umgesetzt wird. Weil die meisten Programmiersprachen eine englische Syntax und englische 

Sprachkonventionen besitzen, sollte auch der Entwurf auf Englisch geschehen; 

Anweisungen im Sinne von HashSet werteMenge = new LinkedhashSet(kapazitaet) 

sind kein Quelltext, sondern ein Albtraum. Aus diesem Grund werden wir für die Architektur 

in den Diagrammen alle Begriffe auf Englisch verfassen. Im Fließtext werden 

wir diese durch kursive Schrift hervorheben, z. B. Dialog Controller, wenn wir den Baustein 

zur Dialogkontrolle besprechen. 

7.2 Ablaufübersicht 

Bevor wir in den nächsten Abschnitten die Architektur des Laufzeitsystems vorstellen, 

werden wir den im letzten Kapitel beschriebenen Ablauf eines Dialogschrittes zusammenfassen. 

Abbildung 7.1 zeigt die Verarbeitung einer Anfrage durch das Laufzeitsystem. 

145

7 Architektur für das Laufzeitsystem 

User 

Browser 

1 

6 

Task 

Controller 

2 3 

Dialog 

Controller 

Dialog 

Fragments 

Web Application Server 

Task 

Model 

Abbildung 7.1: Ablaufübersicht 

4 

5 

View 

Assembly 

UI 

Theme 

Aus der Vogelperspektive betrachtet zerlegt sich die Anfrageverarbeitung in sechs 

Schritte: 

1. Alle Anfragen des Browsers werden vom Dialog Controller entgegengenommen, 

welcher sich als Front Controller verhält, und die Anfrage in ein Ereignis für die 

Aufgabenautomaten transformiert. 

2. Der Dialog Controller ruft den Task Controller auf, welcher das Ereignis verarbeitet 

und die Zustandswechsel der Aufgabenautomaten des Task Models ausführt. 

3. Der Task Controller liefert die Zustände der Automaten der Aufgabenhierarchie 

zurück. 

4. Der Dialog Controller generiert aus den Zuständen und den Dialogfragmenten 

einen neuen Komponentenbaum, welcher an die View Assembly weitergeleitet 

wird. 

5. Die View Assembly wandelt die konkrete Benutzerschnittstelle unter Berücksichtigung 

von Gestaltungsrichtlinien (UI Theme) in eine finale HTML-Benutzerschnittstelle 

um. 

6. Der Dialog Controller liefert die Seite an den Browser aus. 

Die Architektur des Task- und Dialog Controllers werden wir im Detail vorstellen. Für 

die View Assembly können wir existierende Ansätze integrieren, die automatisch aus 

einer konkreten Benutzerschnittstelle eine finale erzeugen, z. B. aus McClanahan u. a. 

[2004]. 

146

Finite State Machine 

Process Context 

Manager 

Domain Base 

Base Entity 

Task Controller 

Task Model 

Context Factory 

User Management 


Service 

7.3 Architekturübersicht Laufzeitumgebung 

Dialog Controller 

Dialog Context 

Manager 

User Management Dialog 


Dialog 

Abbildung 7.2: Architekturübersicht Laufzeitumgebung 


Web Application 

Abbildung 7.2 zeigt, in Form eines Kompositionsstrukturdiagramms der UML, die Aufteilung 

der Gesamtarchitektur in einzelne Bausteine. Diese besitzen, gemäß dem Modularitätsprinzip 

für Softwarearchitekturen, eine hohe interne Kohäsion und eine geringe 

Kopplung untereinander. Auf die Interna der Bausteine werden wir später eingehen, in 

dieser Übersicht sind nur die Kopplungen der Bausteine dargestellt. Dazu bietet jeder 

Baustein, der von einem anderen verwendet werden soll, eine öffentliche Schnittstelle 

an, die Verbindungslinie zwischen einem Baustein und einer Schnittstelle beschreibt 

eine „verwendet“-Beziehung. 

Die Bausteine fassen abgrenzbare Funktionalitäten zusammen. Folgende werden wir 

im Detail vorstellen: 

Finite State Machine: Dient der Modellierung und Ausführung eines beliebigen 

endlichen Automaten. Bestandteile sind z. B. Zustände, Transitionen, Bedingungen 

und Aktivitäten. Eine Instanz eines endlichen Automaten wird Process genannt, 

der Process Context Manager bietet es anderen Bausteinen an, Ereignisse 

an den Automaten zu schicken und den aktuellen Zustand zu erfragen. 

Task Controller: Verwendet die Finite State Machine, um den endlichen Automaten 

aus Abbildung 6.4 umzusetzen. Die temporalen Operatoren des Interaktionsmodells 

werden in Form von Bedingungen an die Transitionen gebunden. Dieser 

Baustein verwaltet intern die Menge der aktuell ausgeführten Aufgaben. Über die 

Schnittstelle Task Model Context Factory können weitere Bausteine den Aufgaben 

Ereignisse senden und auf die aktuellen Zustände der Aufgaben zugreifen. 

Domain Base: In diesem Baustein werden generische Elemente für das Domänenmodell 

zusammengefasst, z. B. um ein Objekt zu persistieren, oder um konkurrierenden 

Zugriff mittels optimistischer Verfahren zu erkennen. In Form der Base 

147


Entities 

BaseEntity 

Data Access 

GenericDao 

T > BaseEntity 

Abbildung 7.3: Architektur – Domain Base 

Entity können diese sowohl von den anderen Architekturbausteinen, als auch von 

den zur Laufzeit ausgeführten Interaktionsmodellen verwendet werden. 

User Management: Modelliert eine einfache Benutzerverwaltung, damit das Laufzeitsystem 

über eine definierte Schnittstelle auf Autorisierungs- und Authentisierungsinformationen 

zugreifen kann. Im Baustein ist dazu ein eigenes Domänenmodell 

vorhanden, um diese Daten zu persistieren, es können aber auch externe 

Benutzerverwaltungen integriert werden. Der User Management Service definiert 

die öffentliche Schnittstelle, z. B. um Benutzer anzulegen und Rollen zuzuweisen. 

Dialog Controller: Dieser Baustein liest ein Interaktionsmodell ein und verwaltet 

den Lebenszyklus des Dialogs. Ereignisse aus der Benutzeroberfläche werden an 

die zugehörigen Aufgabenautomaten verteilt und aus dem neuen Zustand der 

Automaten wird mit den Dialogfragmenten eine Seite generiert. Der Baustein 

greift dazu nicht nur auf den Task Controller zurück, sondern verwendet ebenfalls 

den User Management Service für die Zugriffskontrolle und die Base Entity, um 

unterbrochene Dialoge zu persistieren. 

User Management Dialog: Dieser Baustein besteht aus einem Interaktionsmodell, 

welches eine Oberfläche für die Benutzerverwaltung definiert. Es unterscheidet 

sich nicht von durch Modellierer erzeugte Interaktionsmodelle, es ist allerdings 

immer vorhanden und muss nicht installiert werden. 

Web Application: Fasst die Bausteine unter einer gemeinsamen Oberfläche zusammen. 

Jedes installierte Interaktionsmodell wird auf der Hauptseite in einer 

Auswahlliste dargestellt, der Benutzer kann aus der Liste einen Dialog anfangen. 

Auch das Fortsetzen unterbrochener Dialoge und das Installieren neuer Interaktionsmodelle 

ist Bestandteil dieses Bausteins. 

In den folgenden Abschnitten werden wir die Bausteine im Detail vorstellen. 

7.3.1 Domain Base 

Die Domain Base (siehe Abbildung 7.3) definiert generische Oberklassen für zwei Bereiche: 

den Domänenobjekten und der Datenzugriffsschicht. 

148

Domain Service Interface 

BaseEntity 

Group -groups User -roles Role 

0..* 

0..* 

-roles 0..* 


UserManagementService 

SecurityService 

Abbildung 7.4: Architektur – User Management 

Die abstrakte Klasse BaseEntity, von der alle Domänenobjekte (Entities) abgeleitet 

sind, definiert allgemeine Attribute, die jedes Domänenobjekt besitzen muss, z. B. eine 

id als automatisch generierter Surrogatschlüssel und ein Versionsattribut für den optimistischen 

konkurrierenden Zugriff. 

Die Schnittstelle GenericDao definiert allgemeine Methoden, um auf die Persistenzfunktionen 

42 einer BaseEntity zuzugreifen. Die BaseEntity sollte diese Methoden nicht 

selbst integrieren, damit die davon abgeleiteten Objekte keine Abhängigkeit zur Persistenzschicht 

besitzen. Zu diesem Zweck wird eine Data-Access-Schicht definiert, in der 

für jede von BaseEntity abgeleitete Klasse ein zugehöriges Data Access Object definiert 

wird. 

Für die weitere Architekturübersicht werden wir uns auf das BaseEntity beziehen, 

wenn wir zu persistierende Objekte modellieren wollen. 

7.3.2 User Management 

Das User Management (siehe Abbildung 7.4) setzt eine Benutzerverwaltung als Basisdienst 

um. Für die rollenbasierte Zugriffskontrolle (siehe Abschnitt 5.7) benötigen wir 

die drei Klassen User, Group und Role, welche wir von der Oberklasse BaseEntity aus 

dem Domain Base Baustein ableiten. 

Die Klasse User modelliert die Benutzer der Web-Anwendung, z. B. Namen, Email- 

Adresse und Passwort. Die Klasse Group beschreibt die Gruppen, zu denen Benutzer 

zusammengefasst werden können. Jeder Benutzer kann beliebig vielen Gruppen zugeordnet 

werden. Die Klasse Role beschreibt die Rollen, die für die Zugriffskontrolle 

verwendet werden. Sowohl Benutzern als auch Gruppen können beliebig viele Rollen 

zugeordnet werden. 

Der Schnittstelle UserManagementService fasst die Methoden zum Verwalten der Benutzerdaten 

zusammen, z. B. zum Anlegen neuer Benutzer, Zuordnung von Rollen und 

zum Löschen von Gruppen. Die Schnittstelle SecurityService dient nur zum Abfragen 

von Authentisierungsdaten und liefert alle Rollen – sowohl explizite, als auch implizite 

über die Gruppenzugehörigkeit – eines Benutzers zurück. 

42 Persistenzfunktionen werden häufig als CRUD-Funktionalitäten bezeichnet, nach den vier zentralen Operationen 

Create, Retrieve, Update und Delete. 

149


7.3.3 Finite State Machine 

Die Finite State Machine (siehe Abbildung 7.5) definiert die Klassen zur Beschreibung 

eines allgemeinen endlichen Automaten. Dieser Baustein ist in zwei Bereiche aufgeteilt, 

auf der linken Seite die Elemente, die den endlichen Automaten definieren (model-time 

elements) und auf der rechten Seite die Elemente, die zur Laufzeit angelegt werden, 

um eine Instanz des endlichen Automaten zu verwalten (run-time elements). 

Im linken Bereich definiert Process einen endlichen Automaten, indem er die Menge 

der Zustände (State) verwaltet. Über die Assoziation startState wird der Anfangszustand 

des Process identifiziert. Die Klasse Activity beschreibt die Aktionen, die beim 

Eintritt (enterActivity) oder beim Verlassen (exitActivity) eines States ausgeführt werden. 

Der Zustandsübergang wird mittels einer Transition ausgelöst. Eine Transition führt 

von einem Ursprungszustand (origin) in einen Zielzustand (destination). Die ausgehenden 

Transitionen eines Zustandes werden über die Assoziation outbound verwaltet, die 

eingehenden über inbound. Ein Zustandsübergang kann über eine oder mehrere Bedingungen 

(Condition) geschützt werden. Als generische Bedingungen sind nur AndCondition, 

OrCondition und NotCondition definiert, mit deren Hilfe sich komplexe boolesche 

Ausdrücke aus einzelnen Bedingungen zusammensetzen lassen. Die Implementierung 

der Schnittstelle Condition (genau wie Activity) ist anwendungsabhängig und muss an 

anderer Stelle geschehen. 

Im rechten Bereich sind die Laufzeitelemente des endlichen Automaten dargestellt. 

Ein ProcessContextManager erstellt auf Anfrage eine Instanz eines Prozesses: den ProcessContext. 

Dieser besitzt am Anfang den ProcessStatus „NOT_STARTED“. Sobald der 

Automat in den Startzustand wechselt, befindet er sich im Status „RUNNING“ und der 

ProcessContext referenziert den aktuellen Zustand mit der Assoziation processState. 

Dem ProcessContext können mittels einer Instanz der Klasse ProcessEvent neue Ereignisse 

übermittelt werden, worauf dieser versucht, einen Zustandsübergang unter 

Berücksichtigung der Bedingungen durchzuführen. Falls ein Zustandsübergang ausgeführt 

wurde, verweist processState auf den neuen Zustand. Falls der Automat sich in einem 

Endzustand befindet, wechselt der Status auf „FINISHED“. Die ereignisauslösende 

Klasse muss dabei nicht die konkrete Umsetzung des ProcessContext kennen, letztere 

implementiert die Schnittstelle ProcessListener, welche nur eine Methode zum Verarbeiten 

eines Ereignisses bereitstellt. Von außen betrachtet existiert nur ein ProcessListener 

der ProcessEvents entgegennimmt. 

Der ProcessContext kann, zusätzlich zu dem aktuellen Zustand des Automaten, auch 

noch weitere Kontextdaten speichern. Dazu muss eine Anwendung die Schnittstelle 

StateHolder implementieren und im ProcessContext ablegen. Damit kann der gesamte 

Automat unterbrochen, persistiert und zu einem späteren Zeitpunkt fortgesetzt werden. 

Dieser Baustein für die Ausführung endlicher Automaten werden wir im Folgenden 

verwenden, um unsere Aufgabenautomaten abzubilden. Er kann aber auch an anderer 

Stelle benutzt werden, z. B. um im Domänenmodell einen Zustandsautomaten zu 

verwenden. 

150

un-time elements 

model-time elements 

ProcessContextManager 

-manager 

ProcessContext 

Process -process 

-status 

ProcessStatus 

-NOT_STARTED 

-RUNNING 

-FINISHED 

-startState 0..* -states 

-outbound 

State 

0..* 

-inbound 

-processState 

0..* -origin 

-destination 

Transition 


0..* -conditions 

-enterActivity -exitActivity 

-processData 

Condition Activity 

StateHolder ProcessListener ProcessEvent 

BaseCondition 

AndCondition OrCondition NotCondition 

Abbildung 7.5: Architektur – Finite State Machine 

151


7.3.4 Task Controller 

Der Task Controller ist in zwei Bereiche aufgeteilt. Zum einen der Modellierungsbereich, 

um das komplette Interaktionsmodell als Klassenstruktur abzubilden. Zum anderen der 

Laufzeitbereich, um eine Instanz des Interaktionsmodells auszuführen. Aus Gründen 

der Darstellbarkeit haben wir das Diagramm in diese zwei Bereiche aufgeteilt und stellen 

sie getrennt vor. 

Abbildung 7.6 beschreibt die Struktur, um ein Interaktionsmodell abzubilden. Dazu 

übertragen wir das Interaktionsmetamodell aus dem vorigen Kapitel (siehe Abbildung 

6.18) in unsere Architektur, damit wir zur Laufzeit Interaktionsmodelle einlesen und 

verarbeiten können. Eine Anpassung ist notwendig, weil das Interaktionsmetamodell 

speziell für die Erstellung von Interaktionsmodellen in Diagrammeditoren und für die 

textuelle Notation der Interaktionsmodelle geeignet ist, während wir zur Laufzeit das 

Interaktionsmodell in einer für die Ausführung angepassten Form benötigen. Die notwendigen 

Transformationen werden automatisch beim Einlesen eines Interaktionsmodells 

durchgeführt. 

Zentrale Elemente sind die Schnittstellen TaskModel, welche das zugrundeliegende 

Aufgabenmodell, Task, welche einzelne Aufgaben des Interaktionsmodells und TaskDialog, 

welche die dialogspezifischen Informationen einer Aufgabe beschreiben. Zu jeder 

Schnittstelle existiert eine Implementierung, die den Präfix Base trägt; Schnittstelle und 

Implementierung werden im Folgenden als eine Einheit beschrieben. Das TaskModel 

verweist auf den Wurzelknoten des Aufgabenbaums mittels der Assoziation rootTask. 

Weiterhin pflegt es noch eine Hashtabelle mit dem Namen taskMap, um eine Aufgabe 

effizient nach ihrem Namen finden zu können. Der Baum wird vom Wurzelknoten mittels 

der Assoziationen parent und subTasks aufgespannt, jede Oberaufgabe verweist 

auf eine oder mehrere Unteraufgaben und jede Unteraufgabe verweist auf ihre Oberaufgabe. 

Mit der Assoziation dialog verweist die Aufgabe auf ihre dialogspezifischen 

Informationen, welche wiederum auf mehrere zustandsabhängige Dialoginformationen 

verweisen kann (taskStateDialogs). Der Typ einer Aufgabe wird mit dem Verweis 

auf TaskType beschrieben. Die Beziehung einer Aufgabe zu ihren Unteraufgaben wird 

mittels einer Relation beschrieben. Die sechs verfügbaren Hierarchiebeziehungen sind 

als Unterklassen von BaseRelation modelliert. Während BaseRelation die allgemeine 

Hierarchiebedingung von Seite 75 umsetzt, erweitern die Unterklassen die speziellen 

Hierarchiebedingungen der Ausprägungen. 

Der zweite Bereich des Task Controllers (siehe Abbildung 7.7) beschreibt die Laufzeitelemente 

für die Ausführung des Interaktionsmodells, zusammengefasst in dem Unterbereich 

run-time elements. In dem Unterbereich model-time elements werden die 

Schnittstellen aus der vorigen Abbildung aufgegriffen, die an dieser Stelle Verwendung 

finden. In dem Unterbereich process integration wird, unter Verwendung des Bausteins 

Finite State Machine der Aufgabenautomat modelliert. 

Im Zentrum der Aufgabenausführung stehen die Schnittstellen TaskModelContext, 

TaskContext und TaskDialogContext, sowie deren jeweiligen Implementierungen. 

TaskModelContext verwaltet z. B. eine Instanz der Schnittstelle TaskAccessControl, die 

eine Integration des Bausteins User Management umsetzt und die Berechtigungsprüfung 

vornimmt. 

152


TaskState 

TaskType 

TaskModel 

BaseTaskModel 

-taskType 

-ABSTRACT 

-USER 

-SYSTEM 

-INTERACTION 

-SKIPPED 

-INITIATED 

-RUNNING 

-COMPLETED 

-SUSPENDED 

-TERMINATED 

-rootTask -taskMap 

0..* 

Relation 

TaskRelation 

Task 

BaseTask 

-relation 


-parent 

-subTasks 

0..* 

-relation 

BaseRelation 

-ARBITRARY 

-NESTED 

-OVERLAP 

-PARALLEL 

-SELECTION 

-SEQUENCE 

-dialog 

TaskDialog 

BaseTaskDialog 

OverlapRelation 

SequenceRelation 

0..* -taskStateDialogs 

StateDialogData 

NestedRelation 

ParallelRelation 

ArbitraryRelation 

SelectionRelation 

Abbildung 7.6: Architektur – Task Controller – Modellierung 

153

Abbildung 7.7: Architektur – Task Controller – Laufzeit 


154 

SkipControlCondition 

ResumeControlCondition 

StopControlCondition SuspendControlCondition 

TaskProcessFactory 

StartControlCondition 

ResetControlCondition 

Activity 

Condition 

TaskActivity 

TaskControlCondition 

proccess integration 

-taskDialogContext 

TaskDialogContext 

BaseTaskDialogContext 

-taskContext 

-parentContext 

-rootContext 

-cachedOperations 

0..* 

-START 

-STOP 

-RESET 

-SUSPEND 

-RESUME 

-ABORT 

-SKIP 

Task 

TaskContext 

BaseTaskContext 

TaskOperation 

-task 

-modelContext 

-taskAccessControl 


-taskModel 

TaskModel 


TaskModelContext BaseTaskModelContext 

TaskAccessControl 

TaskModelContextFactory 

BaseTaskModelContextFactory 


run-time elements


TaskContext und TaskDialogContext werden dynamisch angelegt, wenn eine Aufgabe 

in der Aufgabenhierarchie ausgeführt wird, und wieder entfernt, wenn die Aufgabenausführung 

beendet wurde. Den Algorithmus haben wir auf Seite 113 im Detail 

vorgestellt. Der TaskContext enthält den Aufgabenautomaten und weitere Laufzeitinformationen, 

z. B. Anzahl der bisher ausgeführten Iterationen. 

Der Aufgabenautomat wird – unter Verwendung des Bausteins Finite State Machine 

– von der TaskProcessFactory erzeugt. Für den Ein- und Austritt aus den Zuständen 

werden mittels einer TaskActivity die im Interaktionsmodell definierten Aktionen 

mit dem endlichen Automaten verknüpft. Die einzelnen Aufgabenautomaten werden 

mittels Transitionsbedingungen untereinander verknüpft. So erlaubt beispielsweise die 

StartControlCondition nur dann die Start-Transition des Aufgabenautomaten, wenn die 

Oberaufgabe bereits gestartet ist, die Hierarchiebeziehung der Oberaufgabe den Start 

erlaubt und die Berechtigungsprüfung für den Benutzer positiv ausfällt. An jede Transition 

im Aufgabenautomaten werden die entsprechenden ControlCondition-Bedingungen 

geknüpft, nur die Abbrechen-Transition ist immer auslösbar. 

Nach jedem verarbeiteten Ereignis werden die möglichen Folgeereignisse in allen 

Aufgaben bestimmt, z. B. kann eine Aufgabe nur gestartet werden, wenn die Hierarchiebeziehung 

dies zulässt. Der TaskContext verwaltet dazu mit der Assoziation cachedOperations 

eine Liste der erlaubten Folgeereignisse. Bei der Generierung der Benutzerschnittstelle 

kann diese Liste abgefragt werden, um nur Oberflächenelemente für 

Ereignisse zu erzeugen, die auch verarbeitet werden können. 

Die TaskModelContextFactory ist die Schnittstelle nach außen, um die Ausführung 

eines der installierten Interaktionsmodelle anzustoßen. Sie legt auf Anfrage einen initialen 

TaskModelContext an. 

7.3.5 Dialog Controller 

Der Dialog Controller (siehe Abbildung 7.8) ist das verbindende Element zwischen der 

Benutzerschnittstelle und den Aufgabenautomaten des Task Controllers. Dieser Baustein 

nimmt Anfragen vom Browser des Benutzers entgegen und transformiert diese in 

Ereignisse für die Aufgabenautomaten. Im Anschluss verwendet es die neuen Zustände 

der Automaten, um daraus gemäß dem Algorithmus auf Seite 118 eine neue Webseite 

aus den Dialogfragmenten zu generieren. 

Während die Schnittstelle Dialog nur die bestehenden TaskModel – und damit die 

installierten Interaktionsmodelle – kapselt, verrichtet der DialogContext die oben beschriebene 

Dialogfunktionalität. Initial wird dieser erzeugt von einem DialogContext- 

Manager und der TaskModelContextFactory. 

Wenn ein DialogContext aufgrund von System- oder Benutzerereignissen unterbrochen 

wird, dann wird dieser in einen PersistedDialog umgewandelt. Dieser ist von BaseEntity 

abgeleitet und kann persistiert werden. Die Assoziation zu User aus dem Baustein 

User Management erlaubt es dem Laufzeitsystem, dem Benutzer beim nächsten 

Aufruf der Web-Anwendung die persistierten Dialoge zur Fortsetzung anzubieten. 

155


156 

Abbildung 7.8: Architektur – Dialog Controller 

BaseEntity PersistedDialog -user User 

TaskModelContext 

-taskModelContext 

BaseDialogContext 

0..* -map 

DialogContext 

TaskModelContextFactory 

-taskModelContextFactory 

-dialog 

-manager 

TaskModel 

-taskModel 

BaseDialog 

0..* 

Dialog 

DialogContextManager 

BaseDialogContextManager 

-dialogs


Weil der DialogContext den Ablauf unseres Dialogs zentral steuert, werden wir die 

dort ausgeführten Schritte im Detail betrachten (vergleiche Dialog Controller in Abbildung 

7.1): 

1. Komponentenbaum aufbauen: Damit der DialogContext die Eingaben verarbeiten 

kann, muss zuerst der Komponentenbaum wiederhergestellt werden, der bei 

der letzten Anfrage die Webseite des Benutzers generiert hat. Dieser Komponentenbaum 

kann z. B. zwischengespeichert worden sein, oder aber aus den Dialogfragmenten 

basierend auf den Aufgabenzuständen neu aufgebaut werden. 

2. Komponentensteuerungen aufrufen: Die Eingaben des Benutzers werden den 

Komponenten zugeordnet, damit die Komponentensteuerungen (siehe Abbildung 

2.11) diese verarbeiten können. Sie nehmen die Eingaben für die jeweilige 

Komponente entgegen und greifen z. B. mit den Domänenzugriffsobjekten auf 

das Domänenmodell zu. 

3. Aufgabenereignis weiterleiten: Eine der Komponenten der Oberfläche hat die Anfrage 

an die Web-Anwendung ausgelöst. Der Dialog Controller transformiert das 

allgemeine Ereignis („Knopf gedrückt“) in ein Ereignis für einen Aufgabenautomaten 

und ruft den Task Controller auf. 

4. Neuen Komponentenbaum aufbauen: Nachdem die Aufgabenautomaten ihre Zustände 

gewechselt haben, generiert der Dialog Controller aus den Zuständen und 

den Dialogfragmenten einen neuen Komponentenbaum. 

5. Webseite generieren: Die Generierung der Webseite wird dem komponentenbasierten 

Framework überlassen. Der Komponentenbaum wird in der View Assembly 

übergeben, welche mit einer Darstellungsspezifikation (UI Theme) z. B. eine 

HTML-Webseite ausgibt. 

7.3.6 User Management Dialog 

Der Baustein User Management Dialog definiert eine Administrationsschnittstelle der 

Benutzerverwaltung in Form eines Interaktionsmodells. Aus Platzgründen ist dieses hier 

nicht aufgeführt, zusammengefasst bietet es die Möglichkeit, in einer dialoggeführten 

Oberfläche die Benutzer, Gruppen und Rollen jeweils zu erstellen, zu verändern und zu 

löschen. 

7.3.7 Web Application 

Der Baustein Web Application fasst die bis jetzt besprochenen Bausteine in einer Oberfläche 

zusammen. Folgende Aspekte sollten dabei umgesetzt werden: 

Beim ersten Aufruf der Web-Anwendung sollte eine Liste der verfügbaren Interaktionsmodelle 

dargestellt werden, damit der Benutzer eines auswählen und ausführen 

kann. 

157


Abbildung 7.9: Umsetzung der Einstiegsseite 

Falls für einen Benutzer persistierte Dialoge vorhanden sind, sollte diese zur Fortsetzung 

angeboten werden. 

Unabhängig vom ausgeführten Dialog sollten jederzeit generisch Interaktionselemente 

dargestellt werden, damit sich ein Benutzer bei der Web-Anwendung anmelden 

kann. So kann ein Benutzer beispielsweise den Dialog anonym beginnen 

und sich erst dann anmelden, wenn Aufgaben zugangsbeschränkt sind. 

Abbildung 7.9 zeigt die beispielhafte Umsetzung der aufgezählten Aspekte. Im Kopfbereich 

der Oberfläche wird der angemeldete Benutzer (Jane Doe) und die dem Benutzer 

zugeordneten Rollen (user) angezeigt. Im Hauptbereich werden die installierten Interaktionsmodelle 

zur Auswahl (Available Dialogs), sowie die unterbrochenen Dialoge zur 

Fortsetzung (Suspended Dialogs) angeboten. 


Wir haben in diesem Kapitel eine Architektur vorgestellt, mit der Interaktionsmodelle 

eingelesen und ausgeführt werden können. 

158


Wir haben gezeigt, wie die Gesamtarchitektur in Bausteine zerteilt werden kann, die 

in sich gekapselte Funktionalität über definierte Schnittstellen nach außen anbieten 

können. Die Architektur ist in allen Bausteinen durchgängig in zwei Bereiche gekapselt: 

den Elementen der Modellierung (model-time) und den Elementen der Laufzeit (run-time). 

Während die Modellierungselemente unser Interaktionsmodell abbilden, welches 

innerhalb des Laufzeitsystems statischer Natur ist, beschreiben die Elemente der Laufzeit 

Kontextdaten, welche das Laufzeitsystem für jeden Benutzer verwaltet. 

Wir haben gezeigt, dass in einem Laufzeitsystem mehrere Interaktionsmodelle installiert 

sein können und wie die Kontextdaten eines Benutzers bei einer Unterbrechung 

persistiert werden. 

159


160

Kapitel 8 

Bewertung der Ergebnisse 

Inhalt 

8.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 


8.3 Abschließender Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

8.4 Modifizierungen am Aufgabenmodell . . . . . . . . . . . . . . . . . . . 162 


Nachdem wir in den vorigen Kapiteln sowohl das Interaktionsmodell, als auch das dazu 

passende Laufzeitsystem vorgestellt haben, werden wir an dieser Stelle die Ergebnisse 

zusammenfassen und kritisch mit den existierenden Ansätzen vergleichen. Während die 

Vorteile der vorgestellten Erweiterungen und Integrationen in den letzten Kapiteln bereits 

motiviert wurden, werden wir hier einen Blick auf die Vorteile des Gesamtansatzes 

werfen und die noch offenen Thesen konstatieren. 


Der in dieser Arbeit vorgestellte Ansatz zur Modellierung von Web-Anwendungen besitzt 

folgende Eigenschaften: 

Parallel zum Domänenmodell entwickeln wir ein Interaktionsmodell für die Spezifikation 

der Benutzerschnittstelle. 

Das Interaktionsmodell vereint die Eigenschaften eines Aufgaben-, Dialog- und 

Präsentationsmodells. 

Dialogfragmente beschreiben die Interaktionselemente einer Aufgabe. Dialogfragmente 

sind unabhängig voneinander und sind nur ihrer Aufgabe zugeordnet. 

Die Benutzeroberfläche wird erst zur Laufzeit aus dem Zustand des Aufgabenmodells 

und den zugehörigen Dialogfragmenten erzeugt. 

161

8 Bewertung der Ergebnisse 

Nicht-Blattaufgaben gruppieren nicht nur die Unteraufgaben, sondern können 

auch Dialogfragmente in die Benutzerschnittstelle einbringen, die gemeinsame 

Interaktionselemente aller Unteraufgaben zusammenfassen. 

Zeitliche und räumliche Beziehungen sind explizit im Interaktionsmodell beschrieben, 

entweder in den temporalen Relationen des Aufgabenmodells oder als Gruppierungen 

in den Dialogfragmenten. 

Unser Ansatz erlaubt die einfache Veränderung des zugrundeliegenden Aufgabenmodells. 

Die Dialog- und Präsentationseigenschaften des Interaktionsmodells 

folgen den Veränderungen. 

8.3 Abschließender Vergleich 

Unsere Arbeit unterscheidet sich von allen klassischen Ansätzen durch die Verwendung 

von aufgabenbasierten Dialogfragmenten. In den meisten Ansätzen, einschließlich der 

Arbeiten aus dem HCI-Bereich (siehe [Paternò u. a., 1997], [Clerckx u. a., 2004] und [Luyten 

u. a., 2003]), werden die Aufgabenhierarchien während der Modellierung in ein 

initiales Dialog- oder Navigationsmodell transformiert. Diese Modelle werden weiter 

angepasst, eine Änderung der Aufgabenhierarchie und ein erneutes transformieren ist 

nicht möglich, bzw. zieht den Verlust des Dialogmodells nach sich. Wir verschieben die 

Generierung des Dialogs und der Präsentation auf die Laufzeit, die Anwendung kann 

die Benutzerschnittstelle den Anforderungen des Benutzers gemäß anpassen. 

Einige Limitationen und Entwurfsentscheidungen, die dem Ansatz inhärent sind, sollten 

dem Modellierer bewusst sein. Der Einsatz des vorgestellten Interaktionsmodells 

beschränkt sich auf Web-Anwendungen, es werden keine multi-modale Anwendungen 

unterstützt. Wir haben Redundanz vermieden, indem wir gemeinsame Interaktionselemente 

aus den Blattaufgaben in die Dialogfragmente der Oberaufgabe verlagert haben. 

Die Vermeidung von Redundanz erhöht aber die Komplexität des Ansatzes; dem 

Modellierer ist beim Erstellen des Interaktionsmodells nicht mehr ohne Weiteres ersichtlich, 

wie eine generierte Seite aussehen könnte. Eine Änderung eines Dialogfragmentes 

kann Auswirkungen auf viele generierte Seiten haben. Wir versuchen dem entgegenzuwirken, 

indem wir das Laufzeitverhalten der Hierarchiebeziehungen konkret definieren 

und dem Modellierer damit helfen, ein mentales Modell der Komposition aufzubauen. 

Auch die Unterstützung durch Modellierungswerkzeuge ist hilfreich, z. B. um während 

der Erstellung des Interaktionsmodells eine Ausführung zu simulieren. 

8.4 Modifizierungen am Aufgabenmodell 


In diesem Abschnitt wollen wir betrachten, wie robust unser Interaktionsmodell auf 

Veränderungen durch Entwicklungsiterationen reagieren kann. Im Gegensatz zu klassischen 

Anwendungen, die auf dem Rechner des Benutzers installiert werden müssen, 

162


werden Web-Anwendungen beim Anbieter einmalig installiert und können leicht für 

alle Benutzer gleichzeitig aktualisiert werden. Aufgrund dieser Eigenschaft ist es wünschenswert, 

wenn der Entwicklungsprozess die sogenannte Continuous Integration 43 

unterstützt, bei der Erweiterungen der Anwendung nicht erst nach einem langen Zeitraum, 

sondern oft und in kurzem Abstand veröffentlicht werden. Das kann soweit führen, 

dass von den Entwicklern täglich eine neue Version entsteht, die, entsprechend 

getestet und veröffentlicht, von dem Endbenutzer verwendet werden kann. 


Modifikation – Original Aufgabenmodell 

Unser Interaktionsmodell unterstützt diese Vorgehensweise, 

indem die Dialogfragmente und Domänenzugriffsobjekte 

möglichst wenig Abhängigkeiten untereinander 

besitzen, die Aufgaben und ihre Hierarchiebeziehungen 

können somit flexibel in einer Entwicklungsiteration 

verändert werden, um z. B. neue Aufgaben hinzuzufügen 

oder bestehende zu löschen. Wir betrachten anhand 

von einigen Veränderungsoperationen, wie sich diese auf 

das Gesamtsystem auswirken und welche Seiteneffekte 

zu beachten sind. Wir betrachten das nebenstehende Auf- 

gabenmodell (Abbildung 8.1) als Ursprungsmodell, welches in einer Entwicklungsiteration 

verändert werden soll. Es ist ein möglichst generisches Beispiel, die Bedeutung der 

Aufgaben ist nicht relevant und die Beziehungen sind willkürlich gewählt. 

8.4.2 Eine Aufgabe hinzufügen 


Modifikation – Eine Aufgabe 

hinzufügen 

Die bei einer Entwicklungsiteration am häufigsten vorkommende 

Veränderung am Aufgabenmodell ist das Hinzufügen 

einer Aufgabe. In der nebenstehenden Abbildung 

8.2 wurde das Ursprungsmodell um eine Aufgabe 

erweitert, welche im letzten Teilbaum eingefügt wurde. 

Die neue Aufgabe sollte auch mit entsprechenden Dialogfragmenten 

verknüpft sein, um bei der Aufgabenausführung 

visualisiert zu werden. 

Wenn eine Blattaufgabe im Ursprungsmodell um neue 

Unteraufgaben ergänzt werden soll, so müssen die Dialogfragmente der bestehenden 

Aufgabe eventuell angepasst werden, weil diese möglicherweise keine Einfügeposition 

für Dialogfragmente von Unteraufgaben vorsieht. In so einem Fall würde das Laufzeitsystem 

die Dialogfragmente der Unteraufgaben hinten an das Dialogfragment der 

Oberaufgabe anhängen (siehe Algorithmus auf Seite 118), was eventuell vom Modellierer 

nicht erwünscht ist. Im Beispiel links ist dies aber kein Problem, denn die Aufgabe 

wird in eine bestehende Hierarchie eingefügt, die Oberaufgabe musste also bereits die 

Unteraufgaben integrieren können. 

43 Teil der agilen Softwareentwicklung, für weitere Informationen zur kontinuierlichen Integration siehe [Duvall 

u. a., 2007]. 

163


8.4.3 Eine Aufgabe entfernen 

Bei einer Entwicklungsiteration kann die Notwendigkeit entstehen, eine Aufgabe aus 

dem Aufgabenmodell zu entfernen, z. B. um selten verwendete Aufgaben in einer Selektion 

gänzlich zu entfernen oder um die Bedienbarkeit zu verbessern, indem optionale 

Aufgaben in einer Sequenz entfernt werden. Beim Entfernen einer Aufgabe ist darauf 

zu achten, dass sie nicht Informationen an eine Oberaufgabe weiterleitet, die ohne 

die Informationen eventuell nicht mehr ausführbar ist. Eine vorhandene Abhängigkeit 

des Domänenzugriffsobjektes auf ein Domänenzugriffsobjekt der Oberaufgaben 

ist ein Hinweis auf eine Datenübergabe, Aufgaben ohne diese Abhängigkeit können 

gefahrlos gelöscht werden. Z. B. füllt unsere Aufgabe Kontaktinformation angeben die 

Kontakte in das Domänenzugriffsobjekt der Aufgabe Kleinanzeigen erstellen. Würden 

wir Kontaktinformation angeben entfernen, könnten keine Kleinanzeigen mehr erstellt 

werden, weil das Domänenmodell mindestens eine Kontaktinformation vorschreibt. 



entfernen 

8.4.4 Reihenfolge der Unteraufgaben verändern 


Modifikation – Unteraufgaben 

vertauschen 

Wie in der nebenstehenden Abbildung 8.3 ersichtlich, 

führt das Entfernen einer Nicht-Blattaufgabe zu einer 

Entfernung aller Unteraufgaben, weil diese ohne die 

Oberaufgabe nicht mehr erreichbar wären. Der oben genannte 

Hinweis bezüglich der Abhängigkeiten zu noch 

existierenden Oberaufgaben muss jetzt auch für alle Aufgaben 

des entfernten Aufgabenbaums überprüft werden. 

Die Reihenfolge der Unteraufgaben im Aufgabenmodell 

ist entscheidend für die Erstellung der Benutzeroberfläche 

zur Laufzeit. So hat die Reihenfolge bei der Sequenz 

eine zeitliche Bedeutung, die Aufgaben werden der Reihenfolge 

im Aufgabenmodell nach abgearbeitet. Bei der 

parallelen Hierarchiebeziehung hat sie eine räumliche 

Bedeutung, die Aufgaben werden der Reihenfolge im 

Aufgabenmodell nach in der Benutzerschnittstelle dargestellt. 

Es kann deshalb sinnvoll sein, die Reihenfolge der Un- 

teraufgaben zu ändern. In der nebenstehenden Abbildung 8.4 wurden die zweite und 

die dritte Unteraufgabe der Wurzelaufgabe vertauscht, dadurch ändert sich die Abarbeitung 

der Sequenz. Das Verändern der Reihenfolge ist eine unkritische Operation, 

weil die Unteraufgaben immer unabhängig voneinander sind. 

164

8.4.5 Eine Aufgabe verschieben 


Im Verlauf einer Entwicklungsiteration kann die Anforderung entstehen, eine Aufgabe 

an eine neue Position zu verschieben. Dies ist als Verallgemeinerung der oben erwähnten 

Vertauschoperation zu sehen, weil die Aufgabe nicht nur innerhalb der Menge der 

Unteraufgaben verschoben wird, sondern an eine beliebige Stelle im Aufgabenmodell. 



verschieben 

Die Verschiebung einer Aufgabe im Aufgabenmodell 

setzt sich zusammen aus dem Entfernen der Aufgabe an 

der Ursprungsposition und dem Einfügen an der Zielposition. 

Die entsprechenden Hinweise der Entfernungs- und 

Einfügeoperationen sind zu beachten. Wie in der nebenstehenden 

Abbildung 8.5 deutlich wird, werden auch alle 

Unteraufgaben der Aufgabe verschoben. 

Weitere Varianten dieser Veränderungsoperation sind 

das Kopieren einer Aufgabe an eine neue Position (ohne 

die Aufgabe an der Ursprungsposition zu entfernen) und 

das Verknüpfen einer Aufgabe, bei der an der neuen Position 

ein Verweis auf die Ursprungsaufgabe erstellt wird 

(Bestandteil des Aufgabenmodells, siehe Abschnitt 5.8). 

Im Gegensatz zum Kopieren existiert bei der Verknüpfung nur eine Version der Aufgabendefinition, 

die an beiden Positionen verwendet wird; Änderungen an der Aufgabendefinition 

wirken sich überall aus. Beim Kopieren wird eine neue, unabhängige 

Kopie der Aufgabendefinition erstellt. Eine einmal getroffene Wahl der Variante ist 

endgültig, denn aus einer kopierten Aufgabe lässt sich z. B. nachträglich keine Verknüpfung 

mehr erstellen, weil die Ursprungsaufgabe nicht mehr bekannt ist. 


Änderungen am Interaktionsmodell sind iterativ möglich. Wie wir anhand der Operationen 

hinzufügen, entfernen, vertauschen und verschieben gezeigt haben, sind nur 

wenige zusätzliche Arbeiten durchzuführen. Ein grafischer Modelleditor sollte mindestens 

diese Operationen anbieten, zusätzlich könnten die angeführten Bedingungen automatisch 

überprüft und in Form von Warnungen ausgegeben werden. 

Ein Problem haben wir bei der Betrachtung der Entwicklungsiteration bis jetzt nicht 

erörtert: persistierte Dialoge. Wenn zwischen dem Persistieren und dem Fortsetzen eines 

Dialogs das Interaktionsmodell verändert wird, dann kann das Laufzeitsystem den 

alten Dialogzustand nicht wieder herstellen, weil das aktuelle Interaktionsmodell nicht 

mehr dem Interaktionsmodell entspricht, dessen Zustand persistiert wurde. Denkbare 

Lösungen sind z. B. das Löschen aller persistenten Dialoge, die auf veralteten Interaktionsmodellen 

basieren oder das Speichern des Interaktionsmodells zusammen mit dem 

Zustand. 

165


166

Kapitel 9 

Ausblick 

Inhalt 

9.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

9.2 Werkzeugunterstützung . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 

9.3 Aufgabenspezifische Dialogelemente . . . . . . . . . . . . . . . . . . . 168 

9.4 Transformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 

9.5 Laufzeitumgebung für andere Bereiche . . . . . . . . . . . . . . . . . . 169 

9.6 Usability Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

9.7 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 

9.8 Schlusswort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 


Der vorgestellte Ansatz ist in sich abgeschlossen und bietet die Möglichkeit, vollständige 

Web-Anwendungen modellbasiert zu entwickeln. Trotzdem gibt es in verschiedenen 

Bereichen sinnvolle Weiterentwicklungen, die wir in diesem Kapitel vorstellen wollen. 

Die Abschnitte in diesem Kapitel sind nach Realisierbarkeit geordnet, vom konsequenten 

nächsten Schritt bis zur abstrakten Vision. 

9.2 Werkzeugunterstützung 

In der Arbeit haben wir am Beispiel einer textuellen und grafischen Notation das Interaktionsmodell 

für Web-Anwendungen vorgestellt. Für den Modellierer wäre ein entsprechendes 

Werkzeug wünschenswert, um diese Diagramme zu entwickeln. Die zu 

lösende Herausforderung ist hierbei einerseits die Abbildung des vorgestellten Entwurfsprozesses, 

anderseits die Integration mit anderen Modellierungswerkzeugen, z. B. 

der UML zur Domänenmodellierung. 

Erste Schritte in diese Richtung wurden von Suer [2006] durchgeführt. In der Arbeit 

wurde ein Dialogeditor entwickelt, der mehrere Sichten auf das zugrundeliegende Modell 

besitzt, unter anderem auch eine Sicht auf die Aufgabenstruktur. Dem Werkzeug 

fehlt allerdings die Integration des Präsentationsmodells. 

Auch die Integration einer Simulationskomponente wäre eine sinnvolle Ergänzung 

des Modellierungswerkzeugs. Der Simulator instanziiert die Aufgabenautomaten des 

167

9 Ausblick 

erstellten Interaktionsmodells und der Modellierer kann Ereignisse auf diesen auslösen. 

Anhand der Reaktion des Simulators kann der Modellierer die Verzweigungen des 

Dialogs überprüfen. 

9.3 Aufgabenspezifische Dialogelemente 

Im Gegensatz zu den klassischen Ansätzen ist bei unserem die Aufgabenstruktur zur 

Laufzeit verfügbar. Dies erlaubt uns, spezielle Interaktionselemente zu definieren, die 

auf die Struktur und des Zustands der Aufgabenhierarchie zugreifen. Diese Interaktionselemente 

könnten generisch vordefiniert werden und vom Modellierer in den Dialogfragmenten 

eingesetzt werden. 

Für die Erstellung von Benutzerschnittstellen existieren Sammlungen von Entwurfsmustern, 

die häufig verwendete Interaktionsmuster zusammenfassen ([van Welie, 2008] 

[Sinnig u. a., 2005]). Einige dieser Muster können mittels Zugriff auf die Aufgabenhierarchie 

als generisches Interaktionselement definiert werden, zum Beispiel: 

Breadcrumbs: Stellt den Weg des Benutzers zur aktuellen Seite als Liste der besuchten 

Seiten dar. Eine generische Umsetzung kann von der aktuellen Aufgabe in 

der Aufgabenhierarchie die Namen der Aufgaben bis zur Wurzelaufgabe ausgeben, 

z. B., wenn der Benutzer in unserem Beispiel an der Aufgabe Stadt angeben 

angelangt ist, könnte automatisch der Weg ausgegeben werden: Kleinanzeige erstellen 

- Kontaktinformation angeben - Adresse angeben - Stadt angeben. 

Main Navigation: Stellt dem Benutzer die Hauptnavigation in Form eines Menüs 

dar, welches auf jeder Seite immer an der gleichen Stelle erscheint. Wir könnten 

ein Interaktionselement einführen, welches die Unteraufgaben als Menü darstellt. 

Wenn dieses Menü im Dialogfragment der Wurzelaufgabe verwendet wird, wird 

das Hauptmenü auf jeder Seite angezeigt. 

Wizard: Zeigt den aktuellen Schritt innerhalb einer Serie von nacheinander abzuarbeitenden 

Schritten. Wir könnten die Schritte als sequenzielle Unteraufgaben 

modellieren und ein Interaktionselement erstellen, welches die Namen der Unteraufgaben 

ausgibt und die aktuell bearbeitete Unteraufgabe hervorhebt. 

9.4 Transformationen 

Im Bereich der HCI existieren Ansätze, für die bereits fortgeschrittene Werkzeuge entwickelt 

wurden. Auch wenn diese Ansätze sich häufig nur auf die Aufgabenmodellierung 

konzentrieren, können wir doch von den Werkzeugen profitieren. Interessant ist 

deshalb eine Konvertierung eines fremden Aufgabenmodells in unser Interaktionsmodell. 

Basierend auf dieser Ursprungsversion kann ein Modellierer dann die dialog- und 

präsentationsspezifischen Informationen hinzufügen. Auch ein Export des Aufgabenmodells 

aus dem Interaktionsmodell in ein fremdes Aufgabenmodell wäre sinnvoll. 

168

9.5 Laufzeitumgebung für andere Bereiche 

Erste Ergebnisse für einen Import und Export liefern die Arbeiten von Albrecht-Zölch 

[2006] und Czubak [2008]. Beide beschäftigen sich mit der Transformation unseres Interaktionsmodells 

in ein CTT-Aufgabenmodell. Besondere Herausforderung ist die Umsetzung 

der temporalen Relationen, die bei uns in der Oberaufgabe für die Unteraufgaben 

und bei den CTT-Aufgabenmodellen zwischen zwei Unteraufgaben definiert sind. 

9.5 Laufzeitumgebung für andere Bereiche 

Unser Laufzeitsystem wurde für die Generierung von Webseiten ausgelegt. Das Interaktionsmodell 

beschreibt allerdings eine generische zwei-dimensionale Benutzeroberfläche 

(konkrete Präsentation). Mit einer Anpassung des Laufzeitsystems könnten wir 

auch Desktop-Anwendungen generieren, und uns damit vom Einsatzbereich der Web- 

Anwendungen entfernen. 

Weiteres Potenzial steckt in der Generierung aktiver Webseiten, bei der ein Teil der 

Präsentationslogik auf den Client ausgelagert wird (Web 2.0). Weil sich zwischen zwei 

Dialogschritten nur die Bereiche in der Benutzeroberfläche ändern, deren zugehörige 

Aufgabenautomaten den Zustand geändert haben, müssen auch nur diese Dialogfragmente 

übertragen werden. Die Komposition der Dialogfragmente geschieht auf dem 

Client und sorgt für einen schnelleren Seitenaufbau und geringerer Auslastung des Servers. 

9.6 Usability Analyse 

Die Aufzeichnung der Aufgaben-Ereignisse bietet die Möglichkeit, die Dialogschritte 

eines Benutzers auf der Web-Anwendung auszuwerten. Die Aufzeichnung kann beispielweise 

mit einem Prototypen und einzelnen Testpersonen in der Modellierungsphase 

oder mit einer großen Benutzeranzahl im Echtbetrieb erfolgen. Die aufgezeichneten 

Ereignisse können dann nach Usability-Gesichtspunkten analysiert werden, z. B. um herauszufinden, 

ob Benutzer häufig in eine Sackgasse navigieren, oder ob häufig verwendete 

Aufgaben zu tief in der Aufgabenhierarchie verborgen sind. In [Propp u. a., 2008] 

wird dieser Themenkomplex für allgemeine Aufgabenmodelle behandelt, interessant 

wäre eine Übertragung auf unser Interaktionsmodell. 

9.7 Integration 

Die Anforderungen an eine Web-Anwendung – deren Ermittlung am Anfang der Modellierung 

steht – werden häufig in unstrukturierten Dokumenten beschrieben. Die Anforderungen 

können aber auch aus einer übergeordneten Instanz stammen, in die sich 

die Web-Anwendung integrieren muss. Ein Beispiel hierfür sind die strukturierte Definition 

von Geschäftsprozessen, in dem die Web-Anwendung einen Teil des Prozesses 

ausfüllt. In [Sousa u. a., 2008] wird beschrieben, wie Aufgabenmodelle im Allgemeinen 

in Geschäftsprozesse integriert werden können; interessant wäre die Integration eines 

oder mehrerer Interaktionsmodelle in einen globalen Geschäftsprozess. 

169

9 Ausblick 

9.8 Schlusswort 

An dieser Stelle enden der Ausblick und die Arbeit. In den folgenden Anhängen werden 

die verfügbaren Interaktionselemente und das Beispiel in tabellarischer Form zusammengefasst. 

170

Teil III 

Anhänge 

171

Anhang A 

Übersicht aller Interaktionselemente 

Die folgende Tabelle beschreibt alle verfügbaren Interaktionselemente der Java Server- 

Faces Plattform [McClanahan u. a., 2004], die in unseren Dialogfragmenten als Komponentenhierarchie 

die konkrete Benutzerschnittstelle bilden. Die Tabelle beschreibt die 

abstrakten und konkreten Komponenten (gemäß den Abstraktionsstufen aus Abschnitt 

3.6.2) gemeinsam. Die erste Spalte beschreibt abstrakte Interaktionselemente, die unabhängig 

vom Kontext der Benutzerschnittstelle sind. Aus diesen Elementen lassen sich 

z. B. sowohl Sprachsteuerungssysteme als auch Web-Schnittstellen erzeugen. Konkrete 

Interaktionselemente, die auf die Verwendung von Web-Anwendungen zugeschnitten 

sind, werden in der zweiten Spalte beschrieben. Diese sind eine Verfeinerung der abstrakten 

Interaktionselemente und tragen den abstrakten Namensteil als Präfix, also 

z. B. die Secret Verfeinerung des abstrakten Elements Input ergibt das konkrete Interaktionselement 

InputSecret. 

Die Interaktionselemente können über verschiedene Parameter angepasst werden. 

Da die Definition der Parameter an dieser Stelle zu weit führen würde, sei auf McClanahan 

u. a. [2004] verwiesen. 

Abstrakt Konkret Beschreibung 

Tabelle A.1: Interaktionselemente 

Input Ein abstraktes Interaktionselement zur Eingabe von Daten. 

Text Ein einzeiliges Eingabefeld zur Eingabe einer Zeichenkette. 

Finale HTML Darstellung: 

Secret Ein einzeiliges Eingabefeld zur Eingabe einer verdeckten 

Zeichenkette, z. B. zur Eingabe von Passwörtern. Finale 

HTML Darstellung: 

TextArea Ein mehrzeiliges Texteingabefeld. Finale HTML Darstellung: 

 

Date Ein Eingabefeld zur Eingabe eines Datums. 

Output Ein abstraktes Interaktionselement zur Ausgabe von Daten. 

Text Ausgabe eines Textes. 


173

A Übersicht aller Interaktionselemente 



Link Ausgabe eines Hypertext-Links. Dieses ist nur für externe 

Links geeignet, für interne Links werden Command-Interaktionselemente 

verwendet. Finale HTML Darstellung: 

Label Der Text wird als Beschriftung für ein anderes Interaktionselement 

verwendet. Finale HTML Darstellung: 

Graphic Ein abstraktes Interaktionselement zur Ausgabe einer Abbildung. 

Image Die Abbildung wird als grafisches Bild angezeigt. Finale 


Command Ein abstraktes Interaktionselement, welches ein neues Ereignis 

an die Web-Anwendung auslösen kann und zur Navigation 

eingesetzt wird. 

Button Das ereignisauslösende Element wird als Schaltfläche dargestellt. 


Link Das ereignisauslösende Element wird als Hypertext-Link 

dargestellt. Finale HTML Darstellung: 

Data Ein abstraktes Interaktionselement, um strukturierte Daten, 

z. B. aus einer Liste, auszugeben. 

Table Die strukturierten Daten werden als Tabelle ausgegeben. Je 

Eintrag in der Liste wird eine Tabellenzeile erzeugt. Finale 


Panel Ein abstraktes Interaktionselement, um Unterelemente zu 

gruppieren. 

Grid Die Unterelemente werden in einem Gitter mit fester Spaltenanzahl 

ausgegeben. Finale HTML Darstellung: 

Group Die Unterelemente werden horizontal angeordnet ausgegeben. 

SelectOne Ein abstraktes Interaktionselement, um ein Element aus einer 

Liste von Wahlmöglichkeiten zu selektieren. 

Listbox Die Liste wird als Dropdown-Menü dargestellt. Finale HTML 

Darstellung: 

Menu Die Liste wird als Sammlung von Links dargestellt. 

Radio Die Liste wird als Sammlung von Auswahlfeldern mit gegenseitigem 

Ausschluss angezeigt. Finale HTML Darstellung: 

 

SelectMany Ein abstraktes Interaktionselement, um mehrere Elemente 

aus einer Liste von Wahlmöglichkeiten zu selektieren. 

174 




Listbox Die Liste wird in einer mehrzeiligen Auswahl angezeigt, 

der Benutzer kann mehrere Elemente daraus markieren 

und auswählen. Finale HTML Darstellung: 

Checkbox Die Liste wird als Sammlung von Ankreuzfeldern dargestellt. 


175

A Übersicht aller Interaktionselemente 

176

Anhang B 

Beispiel- und Schemadefinition 

B.1 Vollständiges Beispiel in Diagramm-Notation 

In der Arbeit haben wir ein Beispiel kontinuierlich aufgebaut. An dieser Stelle wollen 

wir das Beispiel vollständig darstellen und die restliche Aufgabenhierarchie erklären. 

Abbildung B.1 auf Seite 178 zeigt die grafische Notation, Abbildung B.2 zeigt das gleiche 

Diagramm für einen schnellen Überblick auf die Aufgabentypen reduziert. 

Die Wurzelaufgabe Kleinanzeigen verwalten ist der Einstiegspunkt in die Anwendung 

und zeigt dem Benutzer eine Liste aller verfügbaren Kleinanzeigen an. Mit der 

Aufgabe Kleinanzeige erstellen kann der Benutzer eine neue Kleinanzeige erstellen, 

diese Aufgabe und ihre Unteraufgaben haben wir in der Arbeit bereits beschrieben. 

Die verbleibenden Unteraufgaben der Wurzelaufgabe decken die restliche Funktionalität 

der Web-Anwendung ab: Kleinanzeige suchen beschreibt einen Suchdialog für den 

Benutzer, der über eine Reihe von Selektionen dem Benutzer die Möglichkeit gibt, die 

Liste aller Kleinanzeigen auf eine Treffermenge zu reduzieren. Details anzeigen erlaubt 

dem Benutzer, eine Kleinanzeige zu selektieren und die entsprechenden Details anzuzeigen. 

Der Benutzer kann mit der Aufgabe Tags verändern die Schlüsselworte von 

beliebigen Kleinanzeigen verändern, oder mit der Aufgabe zu Favoriten hinzufügen 

die Kleinanzeige benutzerspezifisch markieren. Markierte Kleinanzeigen werden in der 

Liste aller Kleinanzeigen farblich hervorgehoben. Schließlich kann der Benutzer mit der 

Aufgabe Hilfe die Bedienungsanleitung der Web-Anwendung aufrufen. 

177

B Beispiel- und Schemadefinition 

178 

Nach Benutzer 

suchen 

Volltextsuche Über Auswahl 

suchen 

Nach Zustand 

suchen 

Nach Favoriten 

suchen 

Kleinanzeige 

suchen 


Über Kontakt 

suchen 

Nach Tags 

suchen 

Über Bereich 

suchen 

Nach Zeitbereich 

suchen 

Abbildung B.1: Vollständiges Beispiel – detailliert 

Suchfilter 

entfernen 

In Preisbereich 

suchen 

Titel 

angeben 

Informatione 

angeben 

Zu 

an

ationen 

n 

Zustand 

angeben 

Preis 

angeben 

Name 

angeben 

Vorname 

angeben 

Bild 

auswählen 


Beschreibung 

angeben 

Kleinanzeigen 

verwalten 

Strasse 

angeben 

Nachname 

angeben 


Kleinanzeige 

erstellen 




Adresse 

angeben 

Tags 

zuweisen 


Stadt 

angeben 

Telefonnummer 

angeben 

Rufname 

angeben 

B.1 Vollständiges Beispiel in Diagramm-Notation 


angeben 


existierende 


ZugriffsRollen = »admin« 

Rufnummer 

angeben 

Details 

anzeigen 


Tags 

verändern 

Details 

anzeigen 


zu Favoriten 

hinzufügen 


179

Abbildung B.2: Vollständiges Beispiel – kompakt 


180

B.2 Vollständiges Beispiel in XML-Notation 


Das grafisch notierte Beispiel aus dem letzten Absatz lässt sich auch im XML-Format 

persistieren; der Modellaustausch zwischen Modellierungswerkzeug und Laufzeitsystem 

wird damit vereinfacht. Listing B.1 beschreibt unser Beispiel. 

Listing B.1: Komplettes Beispiel im XML-Format 

1 

2 

5 

6 

9 

10 

11 

12 

14 

15 

16 

17 

18 

19 

21 

22 

23 

24 

25 

26 

27 

28 

29 

31 

32 

33 

34 

35 

36 

38 

39 

40 

41 

42 

44 

45 

46 

181


47 

48 

49 

51 

52 

53 

54 

55 

56 

58 

59 

60 

61 

62 

63 

65 

66 

67 

68 

69 

70 

71 

73 

74 

75 

76 

77 

79 

80 

81 

82 

83 

84 

86 

87 

88 

89 

90 

91 

92 

94 

95 

96 

97 

98 

99 

182


101 

102 

104 

105 

106 

107 

108 

110 

111 

112 

113 

114 

115 

117 

118 

119 

121 

122 

123 

124 

125 

127 

128 

129 

130 

131 

132 

134 

135 

137 

138 

139 

140 

142 

143 

144 

145 

146 

147 

149 

150 

152 

153 

154 

183

155 


156 

158 

159 

160 

161 

162 

164 

165 

166 

168 

169 

171 

173 

174 

175 

177 

178 

180 

181 

182 

184 

185 

187 

188 

189 

190 

192 

193 

195 

196 

197 

198 

199 

201 

202 

204 

205 

206 

207 

184


209 

210 

212 

213 

214 

215 

216 

218 

219 

221 

223 

224 

225 

227 

228 

230 

231 

232 

234 

235 

237 

238 

239 

240 

242 

243 

245 

246 

247 

248 

249 

251 

252 

254 

255 

256 

257 

258 

260 

261 

185


263 

264 

265 

266 

267 

269 

270 

272 

273 

274 

275 

277 

278 

279 

280 

281 

282 

283 

285 

286 

287 

288 

289 

290 

292 

293 

294 

295 

296 

297 

298 

299 

301 

302 

303 

304 

305 

306 

309 

310 

312 

313 

314 

315 

316 

186

317 

318 

B.3 Schemabeschreibung 


Um die im XML-Format persistierten Modelle validieren zu können, ist ein Metamodell 

in Form einer XML-Schemabeschreibung (XSD) sinnvoll. Listing B.2 fasst unser Metamodell 

in dieser Notation zusammen. 

Listing B.2: XSD Schemabeschreibung des Aufgabenmetamodells 

1 

2 

7 

8 

11 

14 

15 

18 

19 

20 

21 

22 

26 

30 

31 

35 

39


42 use="required" /> 

43 

44 

45 

46 

47 

48 

49 

50 

54 

58 

62 

63 

67 

71 

75 

79 

83 

87 

88 

89 

90 

91 

92 

93 

94

96 minOccurs="0" 

97 maxOccurs="unbounded" /> 

98 

102 

103 

107 

111 

115 

119 

120 

121 

122 

123 

124 

125 

126 

130 

131 

135 

136 

137 

138 

139 

140 

144 

148 

149 


189


150 

151 

152 

153 

157 

161 

165 

169 

170 

171 

172 

175 

176 

177 

178 

179 

180 

181 

182 

183 

184 

185 

186 

187 

188 

189 

190 

191 

192 

193 

194 

195 

196 

197 

198 

199 

200 

201 

202 

203 

190

204 

205 

206 

207 

208 

209 

210 

211 

212 

213 

214 

215 

216 

217 

218 

219 

220 

221 

222 

223 

224 

225 

226 

227 

228 

229 

230 

231 

232 

233 

234 

235 

236 

237 

238 

239 

240 

241 

242 

243 

244 

245 

246 

247 

248 

249 

250 

251 

252 

253 

254 

255 

256 

257 


191


258 

259 

260 

261 

262 

263 

264 

265 

266 

267 

268 

269 

192

Literaturverzeichnis 

[Albrecht-Zölch 2006] Albrecht-Zölch, Janet: Optimierung von Benutzerschnittstellen 

unter Verwendung eines Aufgabenmodells am Beispiel eines Selbstmanagementsystems, 

Fernuniversität Hagen, Diplomarbeit, 2006 

[Alexander u. a. 1977] Alexander, Christopher ; Ishikawa, Sara ; Silverstein, Murray: A 

Pattern Language: Towns, Buildings, Construction (Center for Environmental Structure 

Series). Oxford University Press, August 1977. – ISBN 0195019199 

[Allen 1983] Allen, James F.: Maintaining Knowledge about Temporal Intervals. In: 

Communications of the ACM 26 (1983), November, Nr. 11, S. 832–843 

[Alur u. a. 2001] Alur, Deepak ; Malks, Dan ; Crupi, John: Core J2EE Patterns: Best 

Practices and Design Strategies. Upper Saddle River, NJ, USA : Prentice Hall PTR, 2001. 

– ISBN 0130648841 

[Annett und Duncan 1967] Annett, J. ; Duncan, K.: Task analysis and training in design. 

In: Occupational Psychology (1967), Nr. 41, S. 211–221 

[Betermieux und Bomsdorf 2007] Betermieux, Stefan ; Bomsdorf, Birgit: Finalizing 

Dialog Models at Runtime. In: Baresi, Luciano (Hrsg.) ; Fraternali, Piero (Hrsg.) ; Houben, 

Geert-Jan (Hrsg.): Proceedings of the 7th International Conference on Web Engineering 

Bd. 4607, Springer, August 2007, S. 137–151. – ISSN 0302-9743 

[Betermieux und Bomsdorf 2008] Betermieux, Stefan ; Bomsdorf, Birgit: Task-Driven 

Composition of Web User Interfaces. In: Proceedings of CADUI 2008, Springer Verlag, 

2008 

[Betermieux u. a. 2005] Betermieux, Stefan ; Bomsdorf, Birgit ; Langer, Patrick: Towards 

a Generic Model for Specifying Different Views on the Dialog of Web Applications. 

In: Proceedings of HCI International, Lawrence Erlbaum Associates, 2005 

[Bomsdorf 2007] Bomsdorf, Birgit: The WebTaskModel Approach to Web Process Modelling. 

In: Proceedings of the 6th International Workshop on Task Models and Diagrams 

for User Interface Design, 2007, S. 240–253 

193


[Booch 2005] Booch, Grady: On Creating a Handbook of Software Architecture. 2005. 

– URL http://www.booch.com/architecture/index.jsp. – Keynote Speach, 

Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA) 2005 

[Brambilla u. a. 2006] Brambilla, Marco ; Ceri, Stefano ; Fraternali, Piero ; Manolescu, 

Ioana: Process Modeling in Web Applications. In: ACM Transactions on Software 

Engineering and Methodology, 2006 

[Brown u. a. 2001] Brown, Kyle ; Niswonger, Jaime ; Hester, Greg: Enterprise Java 

Development with IBM Websphere. Boston, MA, USA : Addison-Wesley Longman 

Publishing Co., Inc., 2001. – ISBN 0201616173 

[Cachero und Koch 2002] Cachero, Cristina ; Koch, Nora: Conceptual navigation analysis: 

a device and platform independent navigation specification. In: Proceedings of 

2nd International Workshop on Web-Oriented Software Technology, 2002 

[Card u. a. 1983] Card, Stuart K. ; Newell, Allen ; Moran, Thomas P.: The Psychology of 

Human-Computer Interaction. Mahwah, NJ, USA : Lawrence Erlbaum Associates, Inc., 

1983. – ISBN 0898592437 

[Ceri u. a. 2001] Ceri, Stefano ; Fraternali, Piero ; Matera, Maristella ; Maurino, Andrea: 

Designing multi-role, collaborative Web sites with WebML: a conference management 

system case study. In: IWWOST 2001 Workshop, URL citeseer.ist.psu. 

edu/ceri01designing.html, 2001 

[Clerckx u. a. 2004] Clerckx, Tim ; Luyten, Kris ; Coninx, Karin: The mapping problem 

back and forth: customizing dynamic models while preserving consistency. In: TA- 

MODIA ’04: Proceedings of the 3rd annual conference on Task models and diagrams. 

New York, NY, USA : ACM Press, 2004, S. 33–42. – ISBN 1-59593-000-0 

[Comer 2006] Comer, Douglas E.: Internetworking With TCP/IP. Bd. 1. 5. Prentice Hall, 

2006. – ISBN 0-13-187671-6 

[Conallen 2000] Conallen, Jim: Building Web applications with UML. Boston, MA, 

USA : Addison-Wesley Longman Publishing Co., Inc., 2000. – ISBN 0-201-61577-0 

[Czubak 2008] Czubak, Janine: Modellgetriebene Webseitenentwicklung - Vergleich 

zweier Aufgabenmodelle und Entwicklung eines Werkzeugs zur Modellumwandlung, 

Fernuniversität Hagen, Diplomarbeit, 2008 

[Dashorst und Hillenius 2008] Dashorst, Martijn ; Hillenius, Eelco: Wicket in Action. 

Manning Publications, 2008 

[de Troyer und Leune 1998] de Troyer, Olga ; Leune, C. J.: WSDM: A user centered 

design method for web sites. In: Computer Networks and ISDN Systems, 1998, S. 85–94 

[Dittmar 2000] Dittmar, Anke: More precise Descriptions of Temporal Relations within 

Task Models. In: Palanque, Philippe (Hrsg.) ; Paternò, Fabio (Hrsg.): Interactive 

Systems: Design, Specification, and Verification, Springer-Verlag, 2000, S. 151–168 

194


[Dittmar 2002] Dittmar, Anke: Ein formales Metamodell für den aufgabenbasierten 

Entwurf interaktiver Systeme, Universität Rostock, Dissertation, April 2002 

[Dix u. a. 1993] Dix, Alan ; Finlay, Janet ; Abowd, Gregory ; Beale, Russell: Human- 

Computer Interaction. Prentice Hall, 1993 

[Duvall u. a. 2007] Duvall, Paul ; Matyas, Stephen M. ; Glover, Andrew: Continuous 

Integration: Improving Software Quality and Reducing Risk (The Addison-Wesley Signature 

Series). Addison-Wesley Professional, 2007. – ISBN 0321336380 

[Fowler 2003] Fowler, Martin: Patterns of Enterprise Application Architecture. 11. 

Addison-Wesley, 2003 

[Gamma u. a. 1995] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: 

Design patterns: elements of reusable object-oriented software. Boston, MA, USA : 

Addison-Wesley Longman Publishing Co., Inc., 1995. – ISBN 0201633612 

[Güell u. a. 2000] Güell, Natacha ; Schwabe, Daniel ; Vilain, Patricia: Modeling Interactions 

and Navigation in Web Applications. In: In Proc. of the WWW and Conceptual 

Modeling Workshop, Springer, 2000, S. 115–127 

[Heineman und Councill 2001] Heineman, George T. (Hrsg.) ; Councill, William T. 

(Hrsg.): Component-based software engineering: putting the pieces together. Boston, 

MA, USA : Addison-Wesley Longman Publishing Co., Inc., 2001. – ISBN 

0201704854 

[Helbig 1996] Helbig, Hermann: Künstliche Intelligenz und automatische Wissensverarbeitung. 

Berlin : Verlag Technik, 1996 

[Hill und Mallais 2004] Hill, Charles ; Mallais, Sacha: Practical WebObjects. Apress, 

August 2004. – ISBN 1590592964 

[Hix und Hartson 1993] Hix, Deborah ; Hartson, Rex H.: Developing User Interfaces: 

Ensuring Usability Through Product & Process (Wiley Professional Computing). Wiley, 

June 1993. – ISBN 0471578134 

[Härder und Reuter 1983] Härder, Theo ; Reuter, Andreas: Principles of Transaction- 

Oriented Database Recovery. In: Computing Surveys 15 (1983), Dezember, Nr. 4, 

S. 287–317 

[IEEE 2000] IEEE: ANSI/IEEE Standard 1471-2000: IEEE Recommended Practice for Architectural 

Description of Software-Intensive Systems. IEEE Computer Society, 2000. – 

ISBN 0-7381-2518-0 

[INCITS 2004] INCITS: ANSI/INCITS Standard 359-2004: Role Based Access Control. American 

National Standards Institute, 2004 

195


[ISO 8807 1989] ISO: ISO Standard 8807 – LOTOS – A formal description technique based 

on the temporal ordering of observational behaviour. International Organization 

for Standardization, 1989 

[Johnson u. a. 1988] Johnson, Peter ; Johnson, Hilary ; Waddington, Ray ; Shouls, Alan: 

Task-related knowledge structures: analysis, modelling and application. In: Proceedings 

of the Fourth Conference of the British Computer Society on People and computers 

IV. New York, NY, USA : Cambridge University Press, 1988, S. 35–62. – ISBN 

0-521-36553-8 

[Jonassen u. a. 1999] Jonassen, David H. ; Tessmer, Martin ; Hannum, Wallace H.: Task 

Analysis Methods for Instructional Design. Lawrence Erlbaum Associates, 1999 

[Keller u. a. 1992] Keller, G. ; Nüttgens, M. ; Scheer, August-Wilhelm: Semantische 

Prozeßmodellierung auf der Grundlage “Ereignisgesteuerter Prozeßketten (EPK)” / 

Institut für Wirtschaftsinformatik Universität Saarbrücken. 1992 (Heft 89). – Arbeitsbericht 

[Kirchhof u. a. 2004] Kirchhof, Anja ; Gurzki, Thorsten ; Hinderer, Henning ; Vlachakis, 

Joannis: “Was ist ein Portal?” Definition und Einsatz von Unternehmensportalen / 

Fraunhofer Institut Arbeitswirtschaft und Organisation. Nobelstr. 12, 70569 Stuttgart, 

2004. – Forschungsbericht 

[Kraus und Koch 2003] Kraus, Andreas ; Koch, Nora: A Metamodel for UWE / University 

of Munich. 2003. – Forschungsbericht 

[Liberty und Hurwitz 2005] Liberty, Jesse ; Hurwitz, Dan: Programming ASP.NET. 3. 

O’Reilly Media, Oktober 2005. – ISBN 059600916X 

[Limbourg u. a. 2001] Limbourg, Quentin ; Pribeanu, Costin ; Vanderdonckt, Jean: 

Towards Uniformed Task Models in a Model-Based Approach. In: Proceedings of DSV- 

IS 2001, Springer Verlag, 2001 

[Luyten u. a. 2003] Luyten, Kris ; Clerckx, Tim ; Coninx, Karin ; Vanderdonckt, Jean: 

Derivation of a Dialog Model from a Task Model by Activity Chain Extraction. In: 

DSV-IS, 2003, S. 203–217 

[McClanahan u. a. 2004] McClanahan, Craig ; Burns, Ed ; Kitain, Roger: JavaServer 

Faces Specification, v1.1, rev. 01 / Sun Microsystems. 4150 Network Circle, Santa Clara, 

CA 95054 U.S.A., 2004. – Forschungsbericht. – URL http://www.jcp.org/en/jsr/ 

detail?id=252 

[Mitchell 2001] Mitchell, Margaret: Use of Directed Instructions Acyclic Graph Analysis 

in Generating for Multiple Users. In: Proceedings of the Australian Symposium on 

Information Visualization, Dezember 2001 

[Mori u. a. 2002] Mori, Giulio ; Paternò, Fabio ; Santoro, Carmen: CTTE: Support for 

Developing and Analyzing Task Models for Interactive System Design. In: IEEE Transactions 

on Software Engineering 28 (2002), Nr. 8, S. 797–813. – ISSN 0098-5589 

196


[Mori u. a. 2003] Mori, Giulio ; Paternò, Fabio ; Santoro, Carmen: Tool Support for 

Designing Nomadic Applications. In: Proceedings of IUI 2003, Januar 2003 

[OMG 2005] OMG: Unified Modeling Language: Superstructure (final adopted spec, 

version 2.0) / Object Management Group. URL www.omg.org, 2005 (formal/2005-07- 

04). – Forschungsbericht 

[OMG 2006] OMG: Meta Object Facility (MOF) Core Specification / Object Management 

Group. URL www.omg.org, 2006 (formal/2006-01-01). – Forschungsbericht 

[OMG 2008] OMG: Business Process Modeling Notation (version 1.1) / Object Management 

Group. URL www.omg.org, 2008 (formal/2008-01-17). – Forschungsbericht 

[Paternò 1999] Paternò, Fabio: Model-Based Design and Evaluation of Interactive 

Applications. London, UK : Springer-Verlag, 1999. – ISBN 1852331550 

[Paternò 2003] Paternò, Fabio: ConcurTaskTrees: An Engineered Approach to Modelbased 

Design of Interactive Systems. In: Diaper, Dan (Hrsg.) ; Stanton, Neville (Hrsg.): 

The Handbook of Task Analysis for HCI. Lawrence Erlbaum Associates, 2003, Kap. 24. 

– ISBN 0805844325 

[Paternò u. a. 1997] Paternò, Fabio ; Mancini, Cristiano ; Meniconi, Silvia: Concur- 

TaskTrees: A Diagrammatic Notation for Specifying Task Models. In: INTERACT ’97: 

Proceedings of the IFIP TC13 Interantional Conference on Human-Computer Interaction. 

London, UK, UK : Chapman & Hall, Ltd., 1997, S. 362–369. – ISBN 0-412-80950-8 

[Paternò und Santoro 2002] Paternò, Fabio ; Santoro, Carmen: One Model, Many 

Interfaces. In: Kolski, Christophe (Hrsg.) ; Vanderdonckt, Jean (Hrsg.): Proceedings of 

the Fourth International Conference on Computer-Aided Design of User Interfaces, 

Kluwer, 2002, S. 143–154. – ISBN 1-4020-0643-8 

[Paternò u. a. 2008] Paternò, Fabio ; Santoro, Carmen ; Mantyjarvi, Jani ; Mori, Giulio ; 

Sansone, Sandro: Authoring pervasive multimodal user interfaces. In: Int. J. Web Eng. 

Technol. 4 (2008), Nr. 2, S. 235–261. – ISSN 1476-1289 

[Pfaff 1985] Pfaff, Günther E. (Hrsg.): User Interface Management Systems. Springer, 

1985 

[Posch u. a. 2004] Posch, Torsten ; Birken, Klaus ; Gerdom, Michael: Basiswissen Softwarearchitektur. 

Heidelberg : dpunkt-Verlag, 2004 

[Propp u. a. 2008] Propp, Stefan ; Buchholz, Gregor ; Forbrig, Peter: Integrating Usability 

Methods into Model-based Software Development. In: Proceedings of CADUI 

2008, Springer Verlag, 2008 

[Reenskaug 1979] Reenskaug, Trygve: THING-MODEL-VIEW-EDITOR: an Example from 

a Planning System / Xerox PARC Technical Note. Mai 1979. – Forschungsbericht 

197


[Scapin und Pierret-Goldbreich 1989] Scapin, D. ; Pierret-Goldbreich, C.: Towards a 

method for task description : MAD. In: Berlinguet, L. (Hrsg.) ; Berthelette, D. (Hrsg.): 

Proceedings of Work with Display Units (WWU ’89), North-Holland: Elsevier Science, 

1989, S. 27–34 

[Shepherd 1989] Shepherd, A.: Analysis and training in information technology tasks. 

In: Diaper, Dan (Hrsg.): Task Analysis for Human-Computer Interaction. Upper Saddle 

River, NJ, USA : Prentice Hall PTR, 1989, S. 15–55. – ISBN 0470216069 

[Ship 2004] Ship, Howard M. L.: Tapestry in Action. Manning Publications, 2004. – 

ISBN 1932394117 

[Shneiderman 1992] Shneiderman, Ben: Tree visualization with tree-maps: 2-d spacefilling 

approach. In: ACM Trans. Graph. 11 (1992), Nr. 1, S. 92–99. – ISSN 0730-0301 

[Sinnig u. a. 2005] Sinnig, Daniel ; Javahery, Homa ; Forbrig, Peter ; Seffah, Ahmed: 

Patterns and Components for Enhancing Reusability. In: Proceedings of HCI International 

2005, July 2005 

[Sousa u. a. 2008] Sousa, Kênia ; Mendonça, Hildeberto ; Vanderdonckt, Jean: User 

Interface Development Lifecycle for Business-Driven Enterprise Applications. In: Proceedings 

of CADUI 2008, Springer Verlag, 2008 

[Stahl u. a. 2007] Stahl, Thomas ; Völter, Markus ; Efftinge, Sven: Modellgetriebene 

Softwareentwicklung. Techniken, Engineering, Management. Dpunkt Verlag, 2007. – 

ISBN 3898644480 

[Suer 2006] Suer, Klaus: Konzeption und Realisierung eines Editors für alternative 

Dialognotationen, Fernuniversität Hagen, Diplomarbeit, 2006 

[van der Veer u. a. 1996] van der Veer, Gerrit C. ; Lenting, Bert F. ; Bergevoet, Bas A.: 

GTA: Groupware Task Analysis - Modeling Complexity. In: Acta Psychologica (1996), 

Nr. 91, S. 297–322 

[van Welie 2001] van Welie, Martijn: Task-based User Interface Design, Vrije Universiteit 

Amsterdam, Dissertation, 2001 

[van Welie 2008] van Welie, Martijn: A Pattern Library for Interaction Design. 2008. 

– URL http://www.welie.com/patterns. – [Online; aufgerufen am 26. August 

2008] 

[Vanderdonckt und Limbourg 2004] Vanderdonckt, Jean ; Limbourg, Quentin: 

UsiXML: A User Interface Description Language Supporting Multiple Levels of Independence. 

In: Matera, M. (Hrsg.) ; Comai, S. (Hrsg.): Engineering Advanced Web 

Applications. Rinton Press, 2004, S. 325–338 

[Vogel u. a. 2005] Vogel, O. ; Arnold, I. ; Chughtai, A. ; Ihler, E. ; Mehlig, U. ; Neumann, 

T. ; Voelter, M. ; ; Zdun., U.: Software Architektur - Grundlagen, Konzepte, Praxis. 

Elsevier/Spektrum Verlag, Oktober 2005 

198


[Winter 2005] Winter, Mario: Methodische objektorientierte Softwareentwicklung. 

1. dPunkt.verlag, 2005 

199

Generierung aufgabenbasierter dialogorientierter ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?