Chlebek User Interface-orientierte Softwarearchitektur

Bauentwurfslehre für interaktive Softwareoberflächen - Kompass für die Entwicklung dialogintensiver Anwendungen - Leitfaden für erlebbare User Interfaces
1. Auflage 2007
ISBN: 978-3-8348-9016-0
Verlag: Vieweg+Teubner Verlag
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 222 Seiten

Reihe: Computer Science and Engineering (German Language)

Softwareoberflächen sind wie Häuserfassaden: Der Nutzer erwartet hinter einer schönen Außengestaltung ein wohl konstruiertes Inneres, in dem er sich wohl fühlt und in jeder Hinsicht gut zurechtfindet. 'User Interface-orientierte Softwarearchitektur' zeigt, wie Anwendungsentwickler ihren Beruf als Softwarearchitekten verstehen können. Wie der Bau von Software von Anfang an auf eine durchdachte Funktionalität und Sichtbarkeit für den Anwender ausgerichtet werden kann.
Lernen Sie exakte Baupläne für User Interfaces - methodisch sauber - zu erstellen und umzusetzen. Bauen Sie für Ihre Kunden Softwareprototypen. Generieren Sie die Softwareoberflächen automatisch aus der Anforderungsbeschreibung, damit Sie die künftige Funktionalität in Kombination mit dem Look&Feel bereits in der Planungsphase aufzeigen und abstimmen können. Ein Kompass, der Ihnen von der Spezifikation bis zur Umsetzungs- und Testphase dienlich ist.

Paul Chlebek ist Spezialist für HCI, MDA, UML, XML und domänenspezifische Sprachen. Er ist freiberuflich als Berater und Methodenentwickler für BMW, FiNet und andere Unternehmen tätig.

Autoren/Hrsg.

Chlebek, Paul

Inhaltsverzeichnis

1;User Interface-Architektur;6
2;Über den Autor;7
3;Geleitwort;8
4;Vorwort;9
5;Inhaltsverzeichnis;13
6;Abbildungsverzeichnis;17
7;Kapitel 1: Einführung;20
7.1;1.1 Mensch und Software;20
7.2;1.3 Nutzen der UI-orientierten Architektur;25
7.3;1.4 Benutzeroberfläche in den Mittelpunkt rücken;27
7.4;1.5 Beispiel für UI-orientiertes Entwickeln;30
7.5;1.6 Inhalte der User Interface-Architektur;32
7.6;1.7 Lesen von UML-Diagrammen;40
7.7;1.8 Zusammenfassung;43
8;Kapitel 2: Oberfläche;46
8.1;2.1 Historische Entwicklung der Softwareoberflächen;48
8.2;2.2 Oberfläche gliedern;52
8.3;2.3 User Interface-Arten;58
8.4;2.4 Funktionsweise einer Softwareoberfläche;61
8.5;2.5 Informationsgehalt des UI;69
8.6;2.6 Kontrollelemente;71
8.7;2.7 User Interface-Logik;73
8.8;2.8 Nutzen;75
9;Kapitel 3: Werkzeuge;76
9.1;3.1 Typische Phänomene des UI-Entwickelns;77
9.2;3.2 Anforderungen an UI-Werkzeuge;80
9.3;3.3 Bewertungsschema;82
9.4;3.4 Werkzeugarten;89
9.5;3.5 Office-Werkzeuge;89
9.6;3.6 Darstellungsorientierte Werkzeuge;90
9.7;3.7 GUI-Toolkits und GUI-Bibliotheken;90
9.8;3.8 Grafische Ablaufmodellierungswerkzeuge;91
9.9;3.9 Werkzeuge für eingebettete Systeme;91
9.10;3.10 Nutzen;100
10;Kapitel 4: Skizzieren;102
10.1;4.1 Methodenwahl;103
10.2;4.2 Systemgrenzen abstecken;108
10.3;4.3 Ablaufstruktur formen;111
10.4;4.4 Logische Schritte modellieren;114
10.5;4.5 Dialoginhalte abgrenzen;119
10.6;4.6 Nutzen der UI-Skizzen;120
11;Kapitel 5: Detaillieren;124
11.1;5.1 Perspektiven des UI-Entwickelns;125
11.2;5.2 Iterationsmodell;128
11.3;5.3 Fertigstellungsgrad messen;133
11.4;5.4 Nutzen der UI-Detailmodelle;135
12;Kapitel 6: Sprache;138
12.1;6.1 Use Cases des UI-Modellierens;140
12.2;6.2 Die State Charts Notation;143
12.3;6.3 Konzepte für eine UI-Beschreibungssprache;148
12.4;6.4 Datenmodell für UI-Spezifikationen;154
12.5;6.5 UI-Beschreibungssprache Lucia;157
12.6;6.6 Umfang der Lucia-Sprache;165
12.7;6.7 Lucia-Grammatik;168
12.8;6.8 Nutzen;181
13;Kapitel 7: Architektur;182
13.1;7.1 Integration in die Entwicklungsumgebung;182
13.2;7.2 Das MVC-Entwurfsmuster;184
13.3;7.3 Model Driven Architecture (MDA);188
13.4;7.4 UI-orientierte Laufzeitkomponenten;189
13.5;7.5 Ausleiten von Prototypen;191
13.6;7.6 Weitere Transformationen;191
13.7;7.7 Nutzen;191
14;Kapitel 8: Funktionsmodellierung;194
14.1;8.1 Abhängigkeiten zwischen Bedienung und Funktion;195
14.2;8.2 Kollaboratives Modellieren;196
14.3;8.3 Oberflächeneigenschaften mit UML-Modellen absichern;198
14.4;8.4 Funktions- und Datenmodelle ableiten;199
14.5;8.5 Nutzen;200
15;Kapitel 9: Prozesssteuerung;204
15.1;9.1 Prozesslogik und Situationen;205
15.2;9.2 Ablaufsteuerungsdaten extrahieren;207
15.3;9.3 Prozessbeschreibungen im UI abbilden;210
15.4;9.4 Ablaufstrukturen visualisieren;211
15.5;9.5 Nutzen;212
16;Kapitel 10: Dokumentation;214
16.1;10.1 Entwicklungsdokumente generieren;215
16.2;10.2 Benutzerdokumente generieren;216
16.3;10.3 UI-Änderungen nachvollziehen;217
16.4;10.4 Nutzen;217
17;Kapitel 11: Testen;220
17.1;11.1 Arten von UI-Tests;221
17.2;11.2 Testszenarien generieren;223
17.3;11.3 Navigation beim UI-Test;224
17.4;11.4 Nutzen;225
18;Kapitel 12: Projektmanagement;228
18.1;12.1 Arbeiten im Kontext der UI-Anforderungen;229
18.2;12.2 UI-orientiertes Vorgehen;230
18.3;12.3 Integration sicherstellen;230
18.4;12.4 Rollen und Aufgabenteilung bei der UIEntwicklung;234
18.5;12.5 Nutzen;240
19;Kapitel 13: Lebenszyklusmanagement;242
19.1;13.1 Reengineering und Migration;244
19.2;13.2 UI-Beschreibung wieder verwenden;246
19.3;13.3 Zusammenfassung und Ausblick;247
20;Literaturverzeichnis;250
21;Sachwortverzeichnis;252

Leseproben

Kapitel 10: Dokumentation (S. 195-197)

… in dem die Informationen aus dem User Interface-Modell zum Gerüst für Handbücher und für das Hilfesystem werden.

Kapitelziele
• Handbuch und Hilfe zeitgleich mit der Software liefern.
• Automatisierte Übernahme der anleitenden und beschreibenden Teile des UI-Modells in das Gerüst der Benutzerdokumentation.
• Automatisches Erzeugen von Screenshots aus der Bildschirmbeschreibung in der UI-Spezifikation.
• Informationen über Änderungen am UI automatisiert an Verfasser der Dokumentation liefern (z.B. auf neu hinzugekommene oder entfallene Teile des UI hinweisen).

Eine Benutzerdokumentation beschreibt, wie die Oberfläche der Softwareanwendung funktioniert. Ein User Interface, das nicht beschrieben ist, gleicht einem Abenteuerspiel. Der Anwender muss raten und rätseln, ob das beobachtete Verhalten der Softwareoberfläche so gewollt oder ein Fehler ist. Funktionalitäten, die nicht offensichtlich sind, bleiben dem Anwender verborgen, bis sie zufällig oder durch systematische Detektivarbeit entdeckt werden. Versehentlich ausgelöst, führen unbekannte Funktionalitäten zu weiteren Irritationen der Anwender.

Es ist daher von Nutzen, wenn bereits mit der ersten UI-Version, die vom Entwicklungsteam bereitgestellt wird (auch dann, wenn diese erste Version die Endanwender niemals sehen werden) eine UI-Dokumentation (oder eine andere Form der Sollverhaltenbeschreibung) mitgeliefert wird. Sie erleichtert den Anwendervertretern den Einstieg, hilft Missverständnisse zu vermeiden und gibt Aufschluss darüber, was man von der Software erwarten kann und was nicht.

Eine manuell erstellte Dokumentation beschreibt das UIVerhalten der Anwendung nachträglich. Ein User Interface- Modell, vorausgesetzt, dass es im Projekt ernst genommen wurde, beschreibt vorab, wie die Oberfläche der Softwareanwendung funktionieren soll. Selbstverständlich haben beide Beschreibungsformen unterschiedliche Schwerpunkte und unterschiedlichen Aufbau. Jedoch enthält die Vorabbeschreibung der Oberfläche im UI-Modell Informationen über Aufbau und Bedienung der Anwendung, die auch in der Benutzerdokumentation von Belang sind. Die in einem User Interface-Modell enthaltenen Informationen können also für das Erstellen verschiedener Dokumente herangezogen werden.

Aus einem hinreichend formalisierten UI-Modell kann man zum Beispiel die strukturierenden und die anleitenden Teile automatisiert in ein Gerüst für die zu erstellende Benutzerdokumentation umwandeln. In ähnlicher Weise lassen sich Berichte über den Entwicklungsstand der Oberfläche und Versionsinformationen generieren. Die aus einem UI-Modell ableitbaren Dokumente lassen sich in drei Kategorien gliedern:
• Entwicklungsdokumente,
• Benutzerdokumente und
• Dokumente zur Änderungsverfolgung.

10.1 Entwicklungsdokumente generieren

UI-bezogene Entwicklungsdokumente sind meist Bestandteil von Designstudien oder Feinkonzepten. Manuell erstellte UI-Design- Dokumente müssen stets auf den neuesten Stand gebracht werden, weil Designentscheidungen auf Basis von ausführbaren UIPrototypen erfolgen. Diese Nachdokumentationsarbeit kann eingespart werden, wenn die ausführbaren Prototypen und die UI-Dokumente mit geeigneten Transformationen aus demselben UI-Modell erzeugt werden. Entwicklungsbegleitende UI-Dokumente können zum Beispiel sein:

• Aufstellungen, die Entwicklern beim Codieren helfen:
– Liste der Dialogseiten
– Liste von Kontrollelementen pro Dialogseite
– Liste von Kontrollelementen pro Kategorie mit Vorkommen- Aufzählung – Liste der Aufrufe von Anwendungsfunktionen pro Dialogseite – Liste der Aufrufe von Anwendungsfunktionen pro Funktionsgruppe mit Vorkommen-Aufzählung

• Abnahme- und freigaberelevante Projektdokumente:
– Dialogseitenbeschreibungen,
– Übersichten über die Ablaufstruktur der Oberfläche,
– Spezifikationsdokumente, die automatisch aus dem UIModell generiert wurden.