Home

User Interface- orientierte Softwarearchitektur Bauentwurfslehre für

image

Contents

1. Die Statusmarken f r die Situationen k nnen in einer weiteren Tabelle zur Verf gung gestellt und verwaltet werden Tabelle 2 situation id bool value logical expression needs recalculation In Tabelle 1 werden f r jeden logischen Schritt abh ngig von ausl sendem Signal und Situation die Transitionen gehalten Einer der f r die Anwendung definierten logischen Schritte ist der aktuelle Schritt in dem sich die Anwendung userbezogen befindet Die Liste der Transitionen kann die Ver nderung von Standard marken verschiedener logischer Schritte beinhalten Werte an den Datenhaushalt der Anwendung bergeben Ausf hrung von Funktionen anfordern und zuletzt direkt oder indirekt einen anderen logischen Schritt zum aktuellen logischen Schritt ma chen Mit parentstep idref und idolstep idref kann die Behandlung des Signals an Eltern und Vorbilder weitergereicht werden wenn 190 Prozesssteuerung Berechnen der Statusmarken keine der Regeln im aktuellen Schritt greift Die Anwendung der geerbten Regeln kann auch explizit in der Transitionsliste ange fordert werden In Tabelle2 werden f r jede definierte Situation der aktuelle Wahrheitswert true oder false und die Ermittlungsvorschrift verwaltet Mit needs _recalculation kann intern angezeigt werden dass der Wahrheitswert neu ermittelt werden muss Das ist dann notwendig wenn sich ein Datenwert oder
2. Anwender 4 wartet auf Reaktionen System ereignis Anwendung inititiert eine Aktion im UI Signal Trigger Oberfl che interpretiert Eingaben 6 Transitionan sind abgesthlossen Oberfl che macht Transitionen Notifikationen und fordert Ausf hrung von Funktionen an Funktionale Anwendung f hrt angeforderte Funktionen durch 8 Oberfl che schlie t Transitionen ab 9 Ein Zyklus des in der Grafik skizzierten Dialogs zwischen An wender Oberfl che und Anwendung hat folgende Schritte 1 Oberfl che gibt Inhalt und Kontextinformationen aus und stellt Eingabem glichkeiten zur Verf gung Das U ser Interface zeigt dazu z B eine Dialogseite an und oder spielt eine Sprachausgabe ab 2 Oberfl che wartet was nun passiert Die Anwendung wartet i d R nicht mit der Oberfl che sondern erwartet ihrerseits Systemereignisse und oder Signale von der Oberfl che Funktionsweise einer Softwareoberfl che 47 3 Anwender interpretiert die Ausgaben Der Anwender sieht bzw h rt was die Oberfl che ausgibt und macht sich einen Reim drauf 4 Anwender manipuliert Bedienungselemente ob dies aus Sicht der Oberfl che echte Eingaben sind ist zu diesem Zeitpunkt noch nicht entschieden 5 Anwender wartet was nun passiert Oberfl che interpretiert die Eingaben im Kontext der Anwendung Die Oberfl che befragt
3. Projektabschnitte berblick Kapitel bersicht Kapitel 1 Einf hrung in dem Sie erfahren weshalb und f r wen das Buch geschrieben wurde Die Einf hrung erl utert den Bedarf f r und den Zweck der User Interface orientierten Architektur Es wird die Zielgruppe der inhaltliche Rahmen und die Struktur des Buchs beschrieben Bild 12 Leitfaden der User Interface orientierten Architektur Einf hrung 16 Einf hrung Was genau ist ein User Interface UI Werkzeuge auf dem Markt Verwendung der Software verstehen und UI planen Ebenso finden Sie hier grundlegende Beispiele welche kl ren was die UI Orientierung erreichen soll Nach dem Durchlesen des Einf hrungskapitels werden Sie einen berblick ber das Potential und die Bedeutung der User Inter face orientierten Architektur f r Ihre Projekte haben Kapitel 2 Oberfl che in dem wir uns die Benutzeroberfl che vornehmen und herausfinden aus welchen verschiedenen Teilen sie besteht Das Kapitel beinhaltet einen geschichtlichen ber blick ber den Werdegang der User Interface Entwicklung und eine Klassifizierung verschiedener Oberfl chentypen Im Kapitel Oberfl che wird eine bersicht der Bestandteile einer Oberfl che zusammengestellt und diese Bestandteile zu einander in Beziehung gesetzt Das Ergebnis dieser Begehung ist die Aufteilung der Oberfl che in mehrere logische Bereic
4. Pr Funktionszugriff 3 anbinden Anwendungsentwickler setzen das UI um Hierzu geh rt z B die Anbindung der UI Logik an die interne Anwendungslogik und an den Datenhaushalt der Anwendung Rollen und Aufgabenteilung bei der UI Entwicklung 219 Ul Test Pr fen Tester 7 Screenshots N 7 Be vergleichen j i Sy 7 formale N i beinhaltet EN Tests Im i i S a lt r i Verhalten Se Sr l pr fen Ie ER j X N Widerspruchs N N N freiheit s Pr fen Abl ufe pr fen D Tester pr fen die bereinstimmung von Ul Implementierung und Ul Spezifikation Hierzu geh rt z B das Nachvollziehen einzelner Interaktionen aber auch das Vergleichen von Bild schirmen mit Entw rfen Die Ul Entwicklung umfasst die Definition bzw Beschaffung folgender Informationen die in ein Gesamtmodell einflie en Dialogseitenstruktur und Inhalte der Dialoge Logische Schritte Logische Dialogelemente Listen Schaltfl chen etc Ablaufhierarchie Men baum Schritt berg nge Ablauflogik Ereignisse Bedingungen Reaktionen Schnittstelle zur Anwendungslogik Situationen Funktio nen Zust nde von angeschlossenen Ger ten Wertebereiche Datenmuster Listen Text und Grafikressourcen Anzeigetexte Grafiken Anforderungsbeschreibung Prosabeschreibung Variantendefinition und Variantenbezug Konfiguration Modellkonfiguration Anzeige und Bedienelemente Vari antenbeschaltung Stileleme
5. gt wartet auf Ausgaben UI Reaktionen UI Aktionen Die Verwendungsf lle aus Sicht der Oberfl che sind e Aus und Eingabeelemente f r den aktuellen logischen Anwendungsschritt bereitstellen e Eingaben des Anwenders interpretieren e Signale der Anwendung interpretieren e Datenkontext der Anwendung abholen und auswerten Funktionsweise einer Softwareoberfl che 49 e Den Zustandsvektor der Oberfl che ermitteln Bedingun gen f r Aktionen bzw Situationen berechnen e Oberfl chen Transitionen berg nge in der Oberfl che ausl sen e Ausf hrung von Anwendungsfunktionen ausl sen Bild 23 2 Use Cases Sicht der Software Oberfl che Kontext ausgeben Transitionen vollziehen Oberfl che Inhalte ym beinhalte ausgeben dient dem Anwender Benutzeraktionen interpretieren benutzt Funktionalit t 7 Funktionen ausl sen Anwendungssignale interpretieren Situationen Daten ermitteln auswerten Die Verwendungsf lle aus Sicht der funktionalen Anwendung sind e Requests der Oberfl che ber Ausf hrung Funktionalit ten quittieren und umsetzen e Requests der Oberfl che ber Bereitstellung des Daten kontexts quittieren und umsetzen e Signale an die Oberfl che senden Die Anwendung sendet namenlose Signale die unterschiedliche Priorit t haben k nnen um der Oberfl che zu signalisieren dass diese agieren soll Er Bild 24
6. 66 107 108 139 147 Interpretieren 43 47 166 234 Sachwortverzeichnis Iteration 102 108 109 111 112 113 114 116 117 J Jian 32 60 75 78 169 K Kommunikation 5 48 65 133 138 181 229 232 Kontextperspektive 66 108 148 179 Kontrollelemente 22 31 33 42 50 51 52 53 54 55 56 63 71 114 119 129 140 191 201 L Logik 22 51 54 55 56 167 218 logischer Schritt 96 LUCIA18 138 139 140 141 142 143 145 146 148 149 150 158 162 193 M Maschine2 9 2 5 9 27 42 45 46 47 105 132 169 231 Modellieren 61 73 96 106 122 175 176 180 185 229 MVC 55 165 166 167 168 169 N Notation 21 63 64 66 67 68 72 86 87 124 125 128 129 130 136 158 Notifikationen 55 60 72 0 Oberfl che 1 3 7 8 9 10 11 12 13 14 16 17 18 27 28 31 32 33 34 37 42 43 44 45 46 47 48 49 50 51 54 56 57 60 71 72 81 83 84 85 86 87 88 92 95 96 97 98 101 102 105 106 107 117 119 122 124 129 131 132 133 135 137 138 139 140 142 143 144 145 146 156 162 165 167 168 170 171 173 175 176 180 181 186 187 195 197 202 203 204 205 206 207 209 210 211 212 215 216 223 226 227 228 229 P Pr sentationslogik 36 54 59 128 129 133 146 186 Praxis 6 7 14 85 225 227 Programmierer 5 87 105
7. Der Startschritt bernimmt das Hochfahren der Oberfl che und kontrolliert den anf nglichen bergang zu anderen Ablaufschritten Mit using default Screen wird festgelegt dass der logische Schritt Hallo_Welt als Darstellungs und Eingabemedium einen Bildschirm gleichen Namens nutzt Schritte k nnen hierarchisch angeordnet werden und bieten vielf ltige Konstrukte zur Ablaufspezifikation mit Unterst tzung der orthogonalen Verwendung von hierarchischer und prototypi scher Vererbung die unser einfaches Beispiel jedoch nicht de monstriert Screen named Hallo_Welt beschreibt nun die Inhalte der Bildschirmmaske die der Anwen der sieht und die Interaktionsm glichkeiten auf dieser Bild schirmmaske Mit using Layout Hallo_Anordnung wird dem Bildschirm ein Anordnungsschema zugeordnet auf das die Dialogelemente Bezug nehmen k nnen Innerhalb von contains werden die Inhalte des Screens also Ein und Ausgabeelemente mit ihren Eigenschaften be schrieben Text und Button sind logische Dialogelemente Sie sind auf dieser Ebene noch unabh ngig von ihrer tats chlichen Darstel lung Aussehen auf der Oberfl che legen aber fest was und wie zwischen Anwender und Anwendung kommuniziert wird Weitere typische logische Dialogelemente auf die in diesem Beispiel nicht n her eingegangen wird sind Selector z B List box Combobox Men Checkbox Radiobutton Slider Edit fields in ve
8. Testen gehen auf verschiedene Projektphasen und spezielle Entwicklungsthe men ein Die Kapitel Projektmanagement und Lebenszyklusmanage ment beleuchten das Planen Organisieren und Koordinieren von T tigkeiten in Ul orientierten Projekten Inhalte der User Interface Architektur 15 Lifi N t UI Modelle wieder verwenden irecyciemanagemen Migration Reengineering Ul Orientierung in die Projektmanagement Projektorganisation integrieren C t gt Testf lle generieren 10 Dokuma MAON Projektdokumente und Benutzer dokumentation generieren CX Prozesse gt Steuerungsregeln bertragen 8 Funktionen Funktion und Verwendung abstimmen 3 Entwicklungsumgebung Architektur Komponentenplanung Ul Sprache Datenstruktur Grammatik Beispiele ziii Iterationen Fertigstellungsgrade Detaillieren Modellieren in Tiefe Reife erreichen Skizzi Anwendungsbreite abstecken izzioren Ul Modell aufsetzen und strukturieren Typen von Ul Werkzeugen Beispiele Werkzeuge Anforderungen Bewertungskriterien Oberfl che Funktionsweise Struktur Elemente Einf hrung Ausgangslage Zielsetzung Roadmap Der Leitfaden f hrt kein neues Vorgehensmodell ein sondern zeigt auf wie man innerhalb etablierter Vorgehensmodelle einen deutlicheren Fokus auf das User Interface legt Das Buch be schreibt Methoden der UI Entwicklung Aspekte wie Usability und Grafikdesign werden nur am Rande behandelt Management
9. definiert wird ein name oder eine zeichenkette namen wird vorzug gegeben d h definitionen werden als name aufgefasst wenn sie die kriterien f r eine id erf llen Eine Namensdefinition kann implizit da an dieser Stelle erwartet oder explizit durch das Schl sselwort named eingeleitet werden In bestimmten F llen z B bei einer Anforderung ist eine explizite Namenseinleitung erforderlich weil sonst der Anforderungstext mit seiner optional vergebbaren Benamung verwechselt werden k nnte name_definition_ Namensdefinition NAMED x NAME_DEFINITION i name_reference_ Namensverwendung x NAME_REFERENCE L nnn interaktionen werden von ereignissen ausgel st definieren reaktionen auf die ereignisse k nnen bedingungen vor die reaktionen stellen interactions_ Interaktionen interaction_ interaction_ onEnterInteraction_ onSignalInteraction_ onLeavelnteraction_ onCommandInteraction_ p model_interaction_ legt modellglobale interaktionen fest 154 Sprache Bedingungen interaktionen die beim start des hci ausgef hrt werden onEnter interaktionen die ereignisgesteuert ausgef hrt werden onSignal screen _interaction_ legt globale screen interaktionen fest interaktionen die beim start des screens ausgef hrt werden onEnter interaktionen die ereignisgesteuert ausgef hrt werden onSignal e
10. e Zweck der Oberfl che e Dialogfluss e Dialoginhalte e Verhalten e Verwendung von Funktionen und Daten Bei Verfeinerung dieser Gliederung ber mehrere Ebenen geht die umgangssprachliche Beschreibung in eine strukturierte UI Beschreibung ber Tabellarische Ul Beschreibung e Tabellarische Beschreibung der Dialogseiten e Maskenentw rfe mit Pr sentationsprogramm Die tabellenorientierte UI Spezifikation zum Beispiel mittels Excel und PowerPoint oder mit OpenOffice wird in der Praxis oft angetroffen Sie ist in der Regel weiterhin umgangssprachlich definiert aber f r einige Spezifikationsartefakte detailliert deren 86 Skizzieren Kontrollelemente der Dialogseite im Vordergrund Statische Struktur im Vordergrund UT Konstruktion im Vordergrund Struktur Diese Spezifikationsform wird oft beim Entwurf von einzelnen Dialogseiten angetroffen Das Layout der Dialogseite wird zum Beispiel in PowerPoint erstellt Die Liste der Elemente auf der Dialogseite wird mit Excel erstellt Mit dieser Spezifikationsform werden gro e Teile der Dialogper spektive abgedeckt Auch Abl ufe und Kontextbez ge k nnen in tabellarischer Form spezifiziert werden In der Praxis kommen tabellarische Spezifikationen die ber das Beschreiben einzelner Seiten hinausgehen gegen ber z B Ablaufdiagrammen ver gleichsweise selten vor Strukturierte Ul Beschreibung e Detaillierte hierarchische Struktur e Datenhaltung innerhalb ein
11. Die vielen verschiedenen Fallabh ngigkeiten in den Abl ufen einer Software bleiben beim Aufstellen der Ablaufstruktur zu n chst au en vor Die Ablaufstruktur ist sozusagen ein statisches Ger st f r die Ablaufdynamik die aber erst bei der sp teren Detaillierung folgt Die Ablaufstruktur einer Softwareoberfl che beinhaltet folgende Informationen e Ablaufgliederung Hierarchie der logischen Schritte e Eigenschaften der in der Ablaufgliederung aufgenomme nen Schritten zum Beispiel Sequence Steps und Service Steps e Enter und Exit Behandlung Aktionen beim Betreten und Verlassen logischer Schritte Die Ablaufgliederung einer Anwendungsoberfl che wird durch die Hierarchie der logischen Schritte dargestellt Als N herungswert k nnen Sie sich einen logischen Schritt zu n chst als einen Dialogbildschirm einer grafischen Oberfl che vorstellen siehe auch Kapitel Oberfl che Logische Schritte sind eine Detaillierung von Use Cases Bei der Beschreibung von User Interfaces bieten logische Schritte gegen ber Use Cases folgende Vorteile e Logische Schritte k nnen hierarchisch gegliedert sein e Logische Schritte dr cken eine Ausf hrungsreihenfolge aus e Man kann Haupt und Nebenpfade im Ablauf der Anwen dung unterscheiden e Man kann verschiedene Typen von Schritten unterschei den Man kann jede Anwendung in kanonische Sequenzen aus logischen Schritten gliedern Das hei t Man bringt alles was
12. Oberfl che und funktionale Anwendung bzw das Modellieren der Softwareoberfl che und die Funktionsmodellierung haben verschiedene Ber hrungspunkte e An der Oberfl che werden Funktionen und Daten des Softwaresystems verwendet e Beim Beschreiben einer Oberfl che setzen die Spezifizie rer die Existenz der verwendeten Daten und Funktionen voraus und treffen Annahmen ber Datenstrukturen und Funktionsweisen der Anwendung Bild 76 Oberfl che Funktionen und Daten sind Teile eines Ganzen 176 Funktionsmodellierung Entwickler treffen Annahmen Bild 77 Gegenseitige Abh ngigkeiten von Bedienung und Funktionen e Beim Modellieren der Oberfl che schlie t man also von der Bedienung auf Funktionen und Daten bzw auf Objek te e Beim objektorientierten Modellieren ist es umgekehrt Man schlie t von den Funktionen und Datenstrukturen auf ihre Verwendung Daher erg nzen sich beide Ans tze UI Entwickler treffen Annahmen ber Daten und Funktionen der Anwendung Objektentwickler treffen Annahmen ber Verwendung der Objektinstanzen an der Oberfl che Es liegt nahe die Annahmen aus der User Interface Modellierung mit Klassenmodellen Use Case Diagrammen Aktivit ts und Sequenzdiagrammen abzusichern Die Modelle der Oberfl che und die Modelle der Funktionen und der Daten erg nzen und berpr fen sich gegenseitig 8 1 Abh ngigkeiten zwischen Bedienung und Funktion Bedienung und Funktion einer Software b
13. Paul Chlebek User Interface orientierte Softwarearchitektur Aus dem Bereich IT erfolgreich gestalten Visual Basic NET mit Methode von Heinrich Rottmann Warum ausgerechnet NET von Heinrich Rottmann Requirements Analysis realisieren von Karl Scharbert Management der Software Entwicklung von Carl Steinweg Das neue PL I von Eberhard Sturm Projektmanagement der SW Entwicklung von Werner Mellis Profikurs ABAP von Patrick Theobald SAP R 3 Kommunikation mit RFC und Visual Basic von Patrick Theobald Six Sigma in der SW Entwicklung von Thomas Michael Fehlmann Profikurs Eclipse 3 von Gottfried Wolmeringer und Thorsten Klein Erfolgreiche Datenbankanwendung mit SAL3 von J rg Fritze und J rgen Marsch Web basierte Systemintegration von Harry Marsh Sneed und Stephan Henry Sneed Terminalserver mit Citrix Metaframe XP von Thomas Joos Exchange Server 2000 von Thomas Joos Profikurs PHP Nuke von Jens Ferner Unternehmensweites Datenmanagement von Rolf Dippold Andreas Meier Walter Schnider und Klaus Schwinn Netzarchitektur Kompass f r die Realisierung von Thomas Spitz Markus Bl mle und Holger Wiedel SIP Die Technik von Andreas Kanbach IT Sicherheit Make or Buy von Marco Kleiner Lucas M ller und Mario K hler Mehr IT Sicherheit durch Pen Tests von Enno Rey Michael Thumann und Dominick Baier IT Risiko Management mit System von Hans Peter K nigs IT Sicherheit mit
14. bezug unterschiedliche Reaktionen ausl sen Jeder Satz von 0 Bedingungen der zu einem anderen Satz von 0 Reaktionen f hrt z hlt als eine eigene Interaktion Wie leicht zu erkennen ist ist die Beschreibung des Verhaltens einer Softwareoberfl che viel aufw ndiger als die Festlegung und Anordnung der Kontrollelemente auf dem Bildschirm Nach Raskin sollte eine Softwareoberfl che mit dem Anwender sogar auf Basis der kleinsten bedeutungsvollen Eingabeeinheit also einzelne Zeichen und Mausbewegungen interagieren Raskin 2001 S 156 Bei Voice User Interfaces sind die Kontrollelemente nur durch Ereignisse und Interaktionen Sprechen H ren wahrnehmbar Bei Graphical User Interfaces GUD beschr nken sich die meis ten Werkzeuge auf die Unterst tzung des Festlegens von Dialog seiten also Kontrollelemente und deren Anordnung Sie ber lassen die Definition des Verhaltens der Oberfl che der Pro grammierung in einer Programmiersprache Das f hrt zu Br chen in der Oberfl chendefinition die Oberfl che ist teils im GUI Werkzeug beschrieben und teils programmiert und zu Technologieabh ngigkeit man hat sich auf die gew hlte Pro grammiersprache festgenagelt Einige GUI Werkzeuge versuchen das Verhalten der Anwen dungsoberfl che mit State Charts oder mit Entscheidungstabellen abzubilden Wie wir noch sehen werden gen gt das nicht f r eine effektive Verhaltensbeschreibung einer Softwareoberfl che weil der Objekt
15. ist explizit using screen id angegeben und der screen mit dieser id nicht definiert dann wird das als spezifikationsfehler gewertet USING SCREEN name_reference_ DEFAULT using _layout_clause_ screens k nnen m ssen aber nicht ein layout verwenden das layout ist eine schablone f r die positionierung der inhalte auf dem screen USING LAYOUT name_reference_ DEFAULT based_on clause_ steps k nnen m ssen aber nicht auf anderen steps aufbauen so ein step erbt die eigenschaften des mit based on referenzierten step BASED _ON name_reference_ Logische container _ ER 9 Kontrolleleniente CONTAINER name definition OPENBLOCK CLOSEBLOCK D element_ display element_ button_element_ item_list_ checkbox _element_ name_definition_ element_commons_ interactions_ D element_commons_ PLACED AT name_reference_ using widget_clause_ D display element_ DISPLAY D button_element_ BUTTON D item list_ ITEMLIST D Lucia Grammatik 153 checkbox_element_ CHECKBOX p using widget_clause_ elemente und containet k nnen m ssen aber nicht ein widget verwenden das widget ist eine schablone f r das rendering des elements auf dem screen bei detaillierung der spezifikation sollten elementen nach und nach widgets zugeordnet werden USING WIDGET name_reference_ DEFAULT a Definitionen und Verweise
16. rien in Szene gesetzt werden Eine UI Beschreibung enth lt Informationen ber Wertebereiche f r Eingaben und Details ber bedingte Reaktionen auf Einga ben Aus diesen Informationen k nnen automatisiert synthetische Testf lle ber zuf llige Abfolgen von Eingaben generiert werden und gegen die erwarteten Reaktionen gepr ft werden Auf diese Weise kann die UI Beschreibung beim Testen der Anwendung verwertet werden Die in diesem Kapitel vorgestellten Methoden sind in der Umset zungsphase und in der Testphase Construction Transition von Nutzen Kapitel 12 Projektmanagement in dem UI Modelle in die bei einem Projekt blichen Abnahme Dokumente z B Grob konzept Fachkonzept Implementierungsspezifikation einge ordnet werden Genauso wie UML Modelle und Konzeptdokumente m ssen UI Modelle klar und nachvollziehbar in das Projektvorgehen einge gliedert sein Da UI Modelle aufgrund ihrer inhaltlichen Breite berschneidungen mit beinahe allen Entwicklerrollen haben ist ein besonders intensives und integrierendes Management der Ul Beschreibung selbst und ihrer Wechselwirkungen mit anderen Entwicklungsbereichen unabdingbar Das Kapitel zeigt auf wie das Erstellen des Artefakts User Inter face im Projekt installiert wird und wie dabei die Akzeptanz und Mitwirkung durch die einzelnen Entwicklerrollen erreicht wird Die UI Modellierung ist ein Querschnittsthema und muss daher aktiv und integrierend in allen Projek
17. 122 123 138 164 215 Projektleiter2 5 21 81 211 216 220 221 Prototyp 18 87 172 214 Prozesslogik 56 148 186 187 188 189 191 193 R Ressourcenperspektive 107 108 S Situationen49 113 129 133 134 140 145 148 157 186 187 188 189 190 191 192 219 224 Spezifikation 7 9 17 18 19 20 61 62 63 72 74 75 76 79 85 86 87 88 105 106 107 108 109 116 130 134 135 136 137 142 143 146 149 165 173 177 178 195 198 199 202 206 214 219 220 Sachwortverzeichnis 235 Spezifizierer 5 24 86 87 105 122 123 138 164 175 215 218 State Charts 9 51 70 72 124 125 128 129 130 131 132 133 134 Strukturperspektive 66 87 107 108 139 147 178 T Transaktion 24 31 33 60 Transition 20 79 110 113 125 126 U UI Modelle 18 20 84 86 101 164 167 173 175 202 209 210 221 228 229 230 UI Perspektiven 28 60 66 107 113 119 124 129 130 137 149 UML 2 9 19 20 21 22 23 24 29 60 74 75 88 89 90 91 125 167 168 169 175 178 179 180 181 183 192 232 Usability 2 44 123 216 Use Case 3 9 10 21 23 24 88 129 176 213 User Interface 10 1 2 3 5 6 7 8 11 13 14 15 16 17 18 19 20 24 25 26 27 34 42 46 51 54 56 57 63 64 65 70 81 83 84 87 105 109 113 116 119 125 130 134 137 138 149 1
18. 226 Bild 91 Use Cases Map der UI Entwicklung Bedienkonzegpt e 227 Bild 92 Use Cases Map der UI Entwicklung Erscheinungsbild 227 Bild 93 Use Cases Map der Ul Entwicklung Inhalte 228 Bild 94 Use Cases Map der UI Entwicklung Methoden 228 Bild 95 Use Cases Map der UlI Entwicklung Umsetzen nenen 229 Bild 96 Use Cases Map der UI Entwicklung Testen 229 Bild 97 Tool Chain f r die UI Entwicklung eenneennsnn 231 Bild 98 Gewachsene Anwendungen werden immer weniger berschaubar 233 Bild 99 Neue Software kann man unterschiedlich empfinden 234 Bild 100 Etablierte Softwarel sungen sind oft organisch gewachsen 235 Bild 101 Ul orientierte Architektur unterst tzt Knowledge Management 240 Bild 102 M glichkeiten der Verwendung von UI Modellen en 240 Kapitel 1 Einf hrung in dem Sie erfahren warum Sie dieses Buch lesen sollten und was Sie in seinen Kapiteln finden Kapitelziele e Verstehen der Problemstellungen und der L sungsans tze der User Interface orientierten Architektur e berblick ber Themen Zielgruppe und Aufbau dieses Buchs 1 1 Mensch und Software Anwendungsprogramme sind Dinge die Computer f r Menschen nutzbar machen Durch sie kann der Computer dem Anwender bei seinen Aufgaben helfen z B Buchhaltung machen Term
19. Regelwerk f r Entwicklungs und Laufzeitumgebung Software Architektur Informations Architektur 164 Architektur Bild 71 Fehlende Integration der UI Modelle in der Architektur Verhandlungsritual um bislang wenig bekannte Features und um neue Anwenderforderungen sind Hinweise auf technische Mach barkeit und auf die Architekturkonformit t stets im Repertoire der Entwicklerargumente Sie haben den Zweck das technische Regelwerk stabil und konsistent zu halten o k o User Interface Anforderungen sind eine prim re Quelle von ar chitekturrelevanten nderungen an Daten Funktionen und Ab l ufen der Software Eine UI Beschreibung enth lt notwendiger weise Informationen die die Funktionsmodelle und damit die Architektur und die Codierung unterschiedlich stark beeinflus sen Zudem ndert sich die UI Beschreibung im Lauf ihrer Detail lierung Es liegt daher im Interesse der kodierenden Techniker die UI Beschreibung m glichst nderungsrobust in die Architektur zu integrieren Es ist zum Beispiel zweckm ig die UI Modelle genauso wie andere Quellartefakte im Versionskontrollsystem VCS der Ent wicklung zu verwalten Es ist ebenfalls im Interesse der UI Entwickler Anwendervertre ter UI Spezialisten Spezifizierer dass die UI Beschreibung im VCS der Entwickler beheimatet wird Sie wird dadurch symbo lisch und praktisch als entwicklungseigenes Artefakt und als Bestandteil der Architektur
20. Spezifizierer und Analytiker Weitere Zielgruppen des Buchs sind e Projektleiter e Anforderungssteller z B Anwendervertreter und Fachexperten e Qualit tssicherer und pr fer e Designer F r die die Software herstellen und f r die die Software beauftragen Bild 6 Leute die am Entstehen einer Software beteiligt sind sg Einf hrung Bild 7 Gemeinsames Entwickeln macht Pl ne und Modelle notwendig Methodensammlung f r die Projekipraxis Es ist genau genommen ein Buch das eine Br cke zwischen diesen Gruppen und Rollen baut Diese Br cke sorgt f r Ver st ndigung und friedliches Zusammenleben dieser seit je her zu Missverst ndnissen im Umgang miteinander neigenden V lker User Interface orientierte Softwarearchitektur zeigt die Kommu nikationsl cken zwischen den am Bau einer Softwareanwen dung beteiligten Rollen auf Zum Beispiel werden typische Ver st ndigungsprobleme zwischen Softwarehersteller und Auftrag geber sowie L sungsm glichkeiten daf r aufgezeigt Das Buch zeigt wie die beteiligten Personen in ihren jeweiligen Rollen mit weniger Missverst ndnissen und Informationsverlusten gemeinsam an der Planung und Realisierung einer Software zu sammenarbeiten k nnen Es stellt allgemeinverst ndliche und effiziente M glichkeiten zur eindeutigen Beschreibung der Funk tionen der Anwendung aus Anwendersicht zur Verf gung und zeigt wie auf dieser Basis die Effizienz der Soft
21. Vererben und wieder verwenden In einer Benutzeroberfl che sind Verhaltensweisen bzw Bild schirmaufbau oft an mehreren Stellen hnlich Zum Beispiel soll vielleicht in mehreren Bildschirmen das gleiche oder hnliche Men erscheinen eine hnliche Statusleiste eingeblendet werden oder beim Dr cken einer Funktionstaste die gleiche eventuell zentral konfigurierbare Aktion ausgef hrt werden Auch kann es n tig sein auf eintretende Ereignisse in Abh ngig keit von der Stelle an der sich der Anwender in der Software oberfl che befindet hnlich aber differenziert zu reagieren Bei anderen Ereignissen zum Beispiel bei Ausfall von ange schlossenen Ger ten eines Infotainmentsystems im Auto bei unterschiedlich wichtigen Verkehrsmeldungen oder bei einge henden Anrufen ist es eventuell notwendig an jeder Stelle der Oberfl che gleich zu reagieren aber die Priorit t der gerade durchgef hrten Operation zu ber cksichtigen Beim Anzeigen einer wichtigen Staumeldung im Navigationssys tem soll zum Beispiel wenn das vom Fahrer so eingestellt wur de das Einblenden eingehender Anrufe unterdr ckt werden Ein anderes Beispiel w re das Verz gern des Einblendens einge hender Nachrichten w hrend der Anwender in seinem PDA Personal Digital Assistent eine TAN Transaktionsaktivierungs nummer f r eine berweisung eintippt Die Beispiele zeigen dass es notwendig ist die an einer Stelle der UI Beschreibung definierten Ei
22. ber zu diskutieren wie der Tisch verwendet wird wenn er fertig ist Der Kunde und der Entwickler des Tisches werden dar ber sprechen wo der Tisch stehen wird was auf ihm stehen wird und wer daran sit zen wird Dabei werden Sie auch ber das Holz und das Metall sprechen aus dem der Tisch beschaffen sein k nnte und even tuell ihre Vorstellung durch Beispiele echter Tische untermalen Verhindern Sie als Analytiker Beschreibungen und Diskussionen ber das Verwenden von Oberfl cheneigenschaften und ber technische Umsetzungsw nsche nicht sondern verkn pfen Sie Verwendungsinformationen mit funktionalen Anforderungen Im Beispiel des Tisches w re z B die Anzahl der Beine die Form die Oberfl chenbeschichtung die H hen und Neigungsverstell barkeit aus der Art der Nutzung des M bels ableitbar Lassen Sie sich beim Analysieren und Dokumentieren der Anfor derungen von diesem Leitspruch begleiten Wenn du ein Schiff bauen willst musst du die Leute nicht zum Baumf llen antrei ben sondern ihre Sehnsucht nach dem Meer wecken Antoine de Saint Exupery Durch paralleles Entwerfen von Verwendungsaspekten und der technischen Umsetzung erhalten Sie zwei Teilmodelle e Modell der Anwendungsoberfl che Pr sentationslogik Dialogseiten Oberfl chenabl ufe und e Modell des Anwendungsinnenlebens Datenmodell Funktionsvorrat interne Abl ufe die sich gegenseitig erg nzen und best tigen Nutz
23. che und Versionsinformationen generieren Die aus einem UI Modell ableitbaren Dokumente lassen sich in drei Kategorien gliedern e Entwicklungsdokumente e Benutzerdokumente und e 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 wer den weil Designentscheidungen auf Basis von ausf hrbaren UI Prototypen erfolgen Diese Nachdokumentationsarbeit kann eingespart werden wenn die ausf hrbaren Prototypen und die UI Dokumente mit geeig neten Transformationen aus demselben UI Modell erzeugt wer den Entwicklungsbegleitende UI Dokumente k nnen zum Beispiel sein e Aufstellungen die Entwicklern beim Codieren helfen Liste der Dialogseiten Liste von Kontrollelementen pro Dialogseite Liste von Kontrollelementen pro Kategorie mit Vor kommen Aufz hlung Benutzerdokumente generieren 197 Liste der Aufrufe von Anwendungsfunktionen pro Dia logseite Liste der Aufrufe von Anwendungsfunktionen pro Funktionsgruppe mit Vorkommen Aufz hlung e Abnahme und freigaberelevante Projektdokumente Dialogseitenbeschreibungen bersichten ber die Ablaufstruktur der Oberfl che Spezifikationsdokumente die automatisch aus dem UI Modell generiert wurden 10 2 _ Benutzerdokumente generieren
24. f r einzelne Oberfl chenbe UI in die Modellierung der Funktionalit t einbinden Funktionalit t anhand der UI Beschreibung ableiten und pr fen UI Spezifikation als Steuerungsdaten f r Prozesse bernehmen Workflow aus UI Beschreibung ableiten Benutzer und Entwicklungs Dokumentation generieren 20 Einf hrung Automatlisiert gegen UT Beschreibung testen Verwerten der UI Beschreibung beim Testen der Anwendung Projekt mit der UI Beschreibung steuern Einbinden der UI Entwicklung in das Projektmanagement standteile deren Zweck sowie die zugrunde liegenden Anforde rungen in der UI Beschreibung zu dokumentieren Aus diesem Informationsgef ge k nnen vielf ltige Dokumente und Auswer tungen generiert werden Von gro em Nutzen f r Dokumentationsentwickler ist die M g lichkeit das Ger st der Dokumentation jederzeit aus der aktuel len UI Beschreibung generieren zu k nnen So k nnen alle e reits vorhandenen Informationen fr hzeitig verwertet werden Zusammen mit der M glichkeit die UI Spezifikation als Oberfl chenprototyp ausf hren zu k nnen kann die Benutzerdokumen tation parallel zum Entwurf und zur Realisierung der Anwendung erstellt werden Damit l sst sich sowohl die Qualit t des Ge samtprodukts steigern als auch die Lieferzeit verk rzen Kapitel 11 Testen in dem die Informationen in der UI Beschreibung als Quelle f r automatisiert generierte Testszena
25. gen auf Grund von Change Requests nderungsanforde rungen Nachvollziehen des Ersetzens von Spezifikationsteilen durch andere replaced by Bezug Nachvollziehen des Wegfalls von Spezifikationsteilen deprecated removed reviewed Kennzeichnung Nachvollziehen des Hinzuf gens von Spezifikationstei len added to Bezug Unterst tzen des gemeinsamen Arbeitens an der Entwick lung einer Benutzeroberfl che Aufteilbarkeit nach UI Teilen z B Modul Screens Va riantenzuschnitt Bewertungsschema 63 Aufteilbarkeit nach Informationssegmenten z B Kon text Screens Ablaufstruktur Interaktionen Aufteilbarkeit nach Fertigstellungsphase und Rolle z B Rahmenspezifikateur Detailspezifikateur Realisierer Tester e Werkzeugunabh ngige Zugreifbarkeit auf die spezifi zierten Informationen als menschen und als maschinen lesbare Datenstruktur in Textform Definiertes Informationsmodell Bereitstellung als Klartextdatei die zum Informations modell konform ist z B als HMIML Konkreto Skript oder im projekt spezifischen XML Format Kapselung von werkzeugabh ngigen fachlichen In formationen der Spezifikation und von technischen Implementierungsrestriktionen e Unterst tzung von verschiedenen Sichten auf die spezifi zierten Inhalte auf Basis der werkzeugunabh ngigen Zu greifbarkeit Auswertungen Umformungen Simulation Generieren von Steuerungsdaten Generieren von Prog
26. heraus Anruf beenden Adressbuch mit statischen Eintr gen Umschalten zwischen den Bereichsmen s Navigation Radio Telefon Klima und Einstellungen lucia revision 1 02 N Erstellt mit LUCIA Notation 1 02 step hauptmenu I aus dem hauptmen kann man in die einzelnen funktionsbereiche wechseln step phonemenu I The communication menu enables the user to use telecommunication services and other car services depending on the car configuration in order to exchange information step group phone I das telefonmodul stellt die telefonfunktionalit t zur verf gung I die funktionalit t ist hierarchisch gegliedert beim ablauf ist aber immer nur ein step aktiv step group sim card checken step sim card einlegen bitte step sim card ok step pin eingeben step puk eingeben step ende gel nde step group anrufen step aus adressbuch anrufen based on adressbuch step rufnummer w hlen und anrufen step group telefonieren step eingehender anruf step eingehender anruf annehmen step auflegen step eingehender anruf ablehnen based on auflegen step gespr ch l uft step adressbuch screen sim card checken Lucia Grammatik 159 I der bildschirm der w hrend des steps sim card checken eingeblendet wird on enter apply sim card checken funktion I Es soll erst der Hinweis ausgegeben un
27. r die Steuerung von berg ngen an der Oberfl che modelliert Das Regelwerk kann aber auch f r den anwendungsinternen Kon trollfluss bereitgestellt und verwendet werden Der richtige Zuschnitt des Netzwerks aus Regeln ist eine Aufga be die in der Verantwortung des Workflow Modellierers liegen sollte Die Aufstellung des Regelwerks sollte sehr umsichtig er folgen und das Ownership bei nur einer Person liegen damit das Regelwerk konsistent effizient und robust bleibt Die algorithmische Komplexit t einer Prozesslogik ist genauso hoch wie beim Programmieren Allerdings ist die Form transpa renter und die Beschreibung robuster als programmierter Code Der Vorteil ist dass die Regeln die Constraints und die Con cerns separiert vorliegen Wie im obigen Beispiel gezeigt k nnen im Prinzip beliebige Situationen als Statusmarken abgebildet werden Die Statusmar ken k nnen sehr komplexe Situationen z B verkaufsvor gang abgeschlossen oder einfache Zust nde z B nachname eingegeben abbilden Prozesslogik steuert den Bearbeitungs fluss Separation of concerns 188 Prozesssteuerung Interne Zust nde von logischen Schritten Situationen k nnen als Entscheidungs Variablen f r User Interface und f r Gesch ftslogik dienen Neben den vom abzubildenden Prozess abh ngigen individuel len Statusmarken bieten sich einige Standard Statusmarken an die f r jeden logischen Schritt gelten an Die
28. schen Rahmenbedingungen des Projekts wissen wie man ein Werkzeug zur User Interface Entwicklung ausw hlt Zu diesem Wissen geh ren e Kenntnis der typischen Ph nomene beim Festlegen De taillieren und Umsetzen der Eigenschaften einer Oberfl che Woraus und womit wird ein User Interface gebaut Bild 26 Wissen worauf es beim UI Werkzeug ankommt 58 Werkzeuge Herausforderung des UI Entwickelns berblick behalten n m 1 2 m gliche Beziehungen zwischen n UI Elementen Typische Stolpersteine e Kenntnis der Anforderungen an Features einer Ul Entwicklungsumgebung e berblick dar ber wie man die Features einer Ul Entwicklungsumgebung einsch tzt und wie man bewer ten kann wie gut sie die Anforderungen erf llen e berblick ber die Werkzeuge die zur Auswahl stehen 3 1 Typische Ph nomene des Ul Entwickelns In typischen kommerziellen Softwareentwicklungsprojekten wer den in allen Projektphasen Dialogseiten entworfen und verwor fen angepasst und ge ndert Die Projektbeteiligten diskutieren laufend den Dialogfluss Sie detaillieren die Reihenfolge der Bildschirmseiten und passen das Verhalten einzelner Kontroll elemente an Beim Entwickeln von User Interfaces gilt es den berblick zu behalten Man muss eine Menge Anforderungen technische Rahmenbedingungen und Ergebnisse vieler Workshops und Kantinendiskussionen in ein stimmiges Gesamtbild bringen und das Bild laufend aktuell
29. strengungen von Software Entwicklern auf die funktionale Seite und die Optimierung von Rechenzentrum Elementen wie einfa ches Operating und Datenspeicher Minimierung gerichtet Der Benutzer hatte mit der resultierenden Anwendung im Regelfall keine direkte Ber hrung gehabt und nur deren Resultate oder Wirkungen wahrgenommen Die Entwicklung der Anwendung dauerte ihre Zeit aber man lebte damit Nach der ersten Dialogisierung war eine interessante Feststellung zu machen In dem Ma e in dem die Softwareentwicklung kom plexer wurde eine h here Fertigungstiefe erhielt und Fehler oder konzeptionelle Missinterpretationen sofort sichtbar wurden stiegen die Anforderungen an die Umsetzungszeit Je intensiver also die Benutzer Einfluss auf die Gestaltung neh men konnten umso schneller wollten sie Ergebnisse sehen ob wohl der Entwicklungsaufwand zunahm Diese Entwicklung ist bis heute nicht abgeschlossen trotz oder wegen agilem Manifest SOA und vielen anderen Technologie Parametern Die Ausf hrungen des Autors zur User Interface orientierten Architektur helfen uns diesen Optimierungsweg weiter erfolg reich zu beschreiten G nter Penzenauer REB Consulting Group Geleitwort des Praxismentors Vorwort Die ersten von Menschen gebauten Werkzeuge damals in der Steinzeit waren nicht sonderlich kompliziert Ausgefeilte Bau pl ne waren bei den gl cklichen Ingenieuren dieser Zeit nicht gro in Mode Man nahm einen Stein und
30. ufe Wie grenzt man die Ab laufschritte voneinander ab Wie identifiziert und kennzeichnet man kanonische Sequenzen Ablaufalternativen und parallele Abl ufe Wie identifiziert und kennzeichnet man im Ablauf Haupt und Nebenpfade Wie integriert man die Fehler und die Ausnahmenbe handlung in die Ablaufdefinition e Wieder verwenden und vererben Wie kann man Dialogelemente Dialogseiten und Ab laufmechanismen als wieder verwendbare Bausteine verwenden Wie formuliert man Gemeinsamkeiten und Unterschiede zwischen dem Muster und seiner spezia lisierten Wiederverwendung same but different problem Wie vererbt man Festlegungen quer durch das UI Modell z B Hintergrundfarbe Systemmeldungen e Transitionen definieren Formulieren von situationsabh ngigen impliziten z B Weiter Button und expliziten berg ngen zwischen Dialogseiten Workflow F hrung und Kontrollelemen ten Fokus F hrung Abbilden von Entscheidungstabellen und Verzwei gungsknoten auf Bedienungselemente Zum Beispiel Mit welchen Elementen setzt man eine mehrstufige Auswahl um e Kontextabh ngige Pr sentationslogik Anzeige und Navigationsform f r Massendaten z B umfangreiche Listen Kataloge und Verzeichnisse Auswerten von komplexen zusammengesetzten Sys temsituationen am UI e Lokalisieren Anpassen von Texten Grafiken Sprachausgaben For matierung an lokale Begebenheiten z B L ndereinstel lungen Spracheinste
31. unktionen A Use Cases Sicht der funktionalen Daten bereitstellen funktionale Anwendung Anwendung Requests umsetzen Signale an Ul senden Systemgtriggerte Funktionen ausf hren dient der Oberfl che 50 Oberfl che Kontrollelement Bedienelement Verhalten Interaktion 2 5 Informationsgehalt des Ul Der Inhalt bzw Informationsgehalt einer Softwareoberfl che bzw einer Oberfl chenbeschreibung besteht vereinfacht ge sagt aus Antworten auf Fragen die gestellt werden m ssen wenn man als Entwickler eine Oberfl che spezifizieren bzw konstruieren soll Anhand der Leitfragen zur UI Beschreibung siehe oben wird schnell ersichtlich dass die sichtbaren Kontroll und Darstel lungselemente nur einen Teil der Oberfl che ausmachen Der weitaus gr ere Teil der Fragen hat mit dem Verhalten der Oberfl che den Abl ufen aus Anwendersicht und dem Zusam menspiel der Bedienungselemente zu tun Es ist an der Zeit die beiden schon benutzten Begriffe Kon trollelement bzw Bedienelement und Verhalten zu definieren Kontrollelement bzw Bedienelement ist ein Ding das Einga ben des Anwenders entgegennimmt und oder Ausgaben der Software pr sentiert Es gibt eine Reihe spezialisierter Bedienelemente z B Druck kn pfe Eingabefelder Ausgabefelder Regler Auswahlfelder Fortschrittanzeiger und so weiter Weiter in diesem Kapitel fin den Sie eine detaillierte
32. 160 Sprache Wertebereiche verwenden z steht f r eine Dezimalziffer die nicht angezeigt werden soll wenn sie den Wert Null hat Damit lassen sich z B f hrende Nullen unterdr cken b steht f r blank und erzeugt ein Leerzeichen Damit lassen sich z B bei einer Bankleitzahl zur besseren Lesbarkeit Leerzei chen einf gen Der Dezimalpunkt das Komma und andere Interpunktionssym bole werden wie das Leerzeichen an der Stelle eingef gt an der sie in der Formatangabe festgelegt wurden Verwenden von festgelegten Wertebereich Mustern editfield using pattern betrag editfield using pattern blz selectfield using pattern betrag Hinweis zum Referenzieren von Modellbestandteilen Das Ver weisen auf benannte Einheiten des UI Modells erfolgt in Lucia durch name Verschiedene Modellteile Steps Layouts Patterns k nnen den gleichen lokalen Namen haben Um die Verweise auf solche Namen eindeutig zu machen kann dem Namen der Entit tstyp bzw die Namenshierarchie vorangestellt werden Zum Beispiel use pattern blz ist gleichwertig mit use blz Ande res Beispiel go to step auswahl ist gleichwertig mit go to step menues hauptmenue auswahl sofern das der im Modell n chstgelege ne logische Schritt ist Ein und dasselbe Wertebereich Muster kann von verschiedenen Kontrollelementen verwendet werden Die Art der zur Verf gung stehenden Eingabem glichkeiten h ngt von dem logischen Kon trollelement und vo
33. 179 182 191 210 211 219 220 221 226 228 229 Anforderungsperspektive 66 107 108 137 139 147 Anwender 1 2 4 8 9 11 18 24 27 29 32 36 37 38 39 42 44 45 46 47 48 50 51 52 54 60 64 66 72 92 97 102 106 112 131 132 136 137 139 144 159 162 168 178 197 205 206 207 214 223 225 227 228 Architekt 57 215 220 Architektur 2 10 1 5 6 7 11 13 14 15 18 25 26 32 33 46 55 90 109 113 121 123 163 164 166 167 168 170 172 173 193 214 229 230 Ausgabe 42 47 52 53 91 95 136 166 170 202 231 B Benutzeroberfl che 9 8 10 16 27 31 59 60 62 106 121 128 131 132 133 135 140 141 143 177 209 217 Browser 32 224 D Datenmodell 66 135 138 210 Dialog 4 29 39 45 46 48 74 93 95 96 107 114 130 136 137 147 156 Dialogperspektive66 86 87 107 108 139 147 178 E Eingabe 31 47 48 52 91 158 178 179 201 226 Entwickler 2 5 11 13 18 19 21 24 26 31 33 34 37 50 55 57 60 70 81 83 87 88 101 106 138 164 172 176 182 210 311 212 214 220 231 228 Erwartungen 21 37 214 F funktionale Anwendung 42 175 Funktionalit t 9 10 19 24 32 35 42 43 46 78 80 81 101 133 167 173 212 226 Generieren n 63 199 Guards c 47 134 Informationsarchitektur 112 229 Interaktionsperspektive
34. Ablaufstruktur formen 93 man mit der Anwendung machen kann in eine nach T tigkeiten und Arbeitsschritten gegliederte Grundreihenfolge Die Anwendungsoberfl che wird in einen Baum aus logischen Elementare und Zust nden gegliedert Diese Zustandsknoten spiegeln logische zusammengesetzte Schritte Arbeitsschritte T tigkeiten Phasen der Anwendungs Schritte oberfl che wider Die Bl tter des Baums repr sentieren elementare nicht weiter unterteilte logische Arbeitsschritte Die hierarchisch ber den elementaren Arbeitsschritten liegenden Knoten repr sentieren zusammengeselzte Schritte z B T tigkeiten und Phasen Breite Bild 39 Prozessgliederung Prozess Dialogfluss und w Dialogseiten Phase beschreibung N T tigkeit Job Dialogfluss sas an Grenze Dialogseite UN Teilschritt Arbeitsschritt Tiefe Das obige Bild zeigt die Hierarchie aus Arbeitsschritten T tigkei ten und Phasen und die Verankerung der Ablaufsteuerung auf der Ebene eines Dialog Arbeitsschritts also einer Dialogseite Das Verankern auf Arbeitsschrittebene bedeutet dass man beim Spezifizieren nach Ablaufschritten sucht die eine in sich so weit abgeschlossene Einheit bilden dass sie auf einer Dialogseite abgehandelt wird Die Dialogseite ist f r den Arbeitsschritt ein Kommunikationsme dium mit dem die zum Arbeitsschritt geh renden Daten dem Anwender angezeigt werden Eingabedaten erfasst und die Be fehle zum Fortse
35. B enabled disabled Interaktionsperspektive Interaktion Bezug zum logischen Schritt 148 Sprache Keine Steuerungsvariablen Bezug zum Dialogelement Bezug zu Situationen Prozesslogik Ausl sen von Funktionen Manipulieren der Eigenschaften von Schritten und Dia logelementen Kontextperspektive e Situation Guard e Datenverwendung Application Value e Funktionsverwendung Application Function e Widget Realisierung e Layoutvorschrift e LTaufzeitkontext Current Step Stack Interaktionshistorie Fokus Vektor Stephistorie Modellperspektive e Metainformationen ber das Modell Modellierungsstand f r das gesamte Modell und her unter gebrochen auf einzelne Modellelemente Inkludierungen Version Autor Lucia bietet bewusst keine Variablen an Die UI Session ist selbst ein AnwendungsObjekt Um Werte abzurufen oder zu speichern gibt es zwei M glichkeiten Application Values und unsicht bare Kontrollelemente z B versteckte Textfelder Das nachfolgende Blockdiagramm zeigt eine bersicht der Sprachelemente von Lucia Lucia Grammatik 149 Bild 70 head Sprachstruktur von Lucia ELQSS references requirements l application objects l functions l l l 3 I situations I l l l 6 7 Lucia Grammatik Die nachfolgende Parsergrammatik in ANTIR definiert die Syntax der Lucia Sprache Ausschnitt Die Sprache erm glicht eine eindeutige Beschreibung von User Interfaces
36. Das sp tere Entdecken solcher L cken kann uner wartete zus tzliche Aufw nde und Terminengp sse durch Wie derholen von bereits erledigt geglaubten Entwurfsschritten zur Folge haben Kapitel 5 Detaillieren das den Weg von einem groben User Interface Ger st zu einer umselzungsreifen Spezifikation der Anwendungsoberfl che auf zeigt Kapitelziele e Wissen wie man eine Oberfl chenbeschreibung in Iterati onen detailliert e Wissen wie man eine gleichm ige Detailtiefe erreicht und beh lt e Wissen wie man Stand und Qualit t der Oberfl chenbe schreibung messbar macht Besitzt man als Konstrukteur einer neuen Maschine einmal eine genaue Vorstellung davon wie etwas im Detail funktionieren wird dann kann man es in einem Zug formen Selten bis nie stimmt aber die erste Skizze mit dem fertig entwickelten Produkt berein Beim Entwickeln muss man sich oft an die L sung her antasten und erreicht die L sung schrittweise es handelt sich eben um eine Ent Wicklung im w rtlichen Sinn Benutzeroberfl chen werden nicht in einem Aufwasch sondern schrittweise entwickelt F r User Interfaces ist das schrittweise Entwickeln der richtigen L sung von vielleicht noch gr erer Bedeutung als f r andere Konstruktionen Man muss f hlen wie die Oberfl che in der Hand liegt und sitzt um Verbesse rungspotentiale und richtige L sungen zu erkennen Die Hauptkritik an bestehenden GUI Toolkits ist Sie
37. Die Guards einer Ul Spezifikation beziehen sich auf den Funkti ons und Datenkontext der Anwendung Auf enschnittstelle nehmen aber auch oft Bezug auf den eigenen Zustand des UI Damit hat das User Interface auch eine Selbstschnittstelle zu einem durch sich selbst aufgebauten Kontext Zum Beispiel k nnte es notwendig sein zu wissen welche Dia logseite zuletzt aktiv war und welches Eingabeelement gerade den Fokus hatte Oder es wird die Information ben tigt ob ein Bildschirm bereits betreten wurde betretbar ist abgeschlossen wurde Die n tigen Informationen k nnen nur teilweise aus der funkti onalen Anwendung bezogen werden teilweise sind sie sitzungs spezifisch und beziehen sich auf den Zustand einzelner Bedie nungselemente und logischer Schritte Zur Abbildung dieser komplexen Transitionsbedingungen schla ge ich die Erweiterung des Guard Konzepts von State Charts zur Selbstschnittstelle des User Interfaces mit wieder verwendbaren Situationen vor Der konkrete L sungsvorschlag beinhaltet die Einf hrung der folgenden semantischen Erweiterungen e Formulieren von Bedingungsausdr cken als zentrale Res sourcen z B als Pseudo Zust nde e Formulieren von Interaktionen als Tupel aus Ausl ser Si tuationsbedingung und Reaktionen wobei sowohl die ganze Interaktion bedingt sein kann als auch jede darin vorkommende Reaktion e M glichkeit den Event weiterzupropagieren oder zu kon sumieren bei Reaktion wird das
38. Framework in John M Caroll Hrsg HCI Models Theories and Frameworks Toward a Multidisciplinary Science 103 133 Morgan Kaufmann Publishers Elsevier Science San Francisco 2003 Stefano Ceri Piero Fratenali Aldo Bongio Marco Brambilla Sara Comai Maristella Matera Designing Data Intensive Web Applications Morgan Kaufmann Publishers Elsevier Science San Francisco 2003 http www webml org 232 Literaturverzeichnis JJeckle 2004 Herczeg 2005 Khazaeli 2005 Scharbert 2005 Mario Jeckle Chris Rupp J rgen Hahn Barbara Zengler Stefan Queins UML 2 glasklar Carl Hanser Verlag M nchen Wien 2004 http www uml glasklar com Michael Herczeg Softwareergonomie Grundlagen der Mensch Computer Kommunikation 2 vollst ndig ber arbeitete Auflage Oldenbourg Verlag M nchen Wien 2005 Cyrus Dominik Khazaeli Systemisches Design Intelligente Oberfl chen f r Information und Interaktion Rowohlt Verlag Reinbek 2005 Karl Scharbert Requirement Analysis realisieren Praktischer Leitfaden f r die Anforderungsanalyse bei IT Projekten Kundenanforderungen erfragen verstehen und spezifizieren Vieweg Verlag Wiesbaden 2005 Sachwortverzeichnis A Ablaufstruktur 62 63 68 92 94 95 100 101 102 115 124 130 136 197 Anforderungen 8 12 13 14 16 20 26 56 57 58 61 62 64 81 83 88 101 106 112 121 124 128 130 137 138 140 142 143 147 164 168 170 171 177
39. Kapiteln wurden verschiedene Metho den und Werkzeuge zum Beschreiben von User Interfaces vor gestellt In den Kapiteln Skizzieren und Detaillieren haben Sie Vorge hensleitf den kennen gelernt die Sie beim Beschreiben von Softwareoberfl chen unterst tzen k nnen Auf dieser Grundlage k nnen Sie mit formalen Modellierungs elementen z B Step Screen Interaction das User Interface einer Softwareanwendung skizzieren Die aufgezeigten Metho den und die User Interface Perspektiven erm glichen Ihnen ebenfalls das Detaillieren der Skizzen zu einer weitgehend voll st ndigen Beschreibung des User Interface Damit stehen Ihnen hilfreiche Ausdruckmittel zur UI Beschreibung und ein Leitfaden f r deren Anwendung zur Ver f gung Die vorgestellten M glichkeiten k nnen Sie zum Model lieren von Bildschirmabfolgen der Kontrollelemente und des Verhaltens einer Anwendung nutzen Aus praktischen Gr nden habe ich bislang nur ausgew hlte Teile einer Oberfl chenbeschreibung ausf hrlich beleuchtet und auf ein vollst ndiges Modell f r User Interfaces verzichtet Das Kapitel Sprache schlie t die noch offenen L cken und stellt das Konzept eines Sprachmodells f r User Interfaces vor mit dem sich eine Softwareoberfl che vollst ndig und pr zise beschreiben bzw konstruieren l sst Der Einsatzzweck dieses Modells ist das Spezifizieren von grafischen und sprachkom mandogesteuerten Benutzeroberfl chen f r kommerziell
40. Klassifikation der mir bekannten Kon trollelemente Verhalten ist die Art und Weise wie die Anwendung agiert und reagiert Das Verhalten einer Softwareoberfl che ist durch die Summe ihrer Aktionen und Reaktionen festgelegt Als Oberbegriff f r Aktionen und Reaktionen mit den dazugeh rigen Verkn pfungen verwende ich den Begriff Interaktion Interaktionen verkn pfen die f r den Anwender wahrnehmba ren Teile der Oberfl che also in der Regel Kontrollelemente mit den Funktionen der Anwendung und die Kontrollelemente un tereinander Interaktionen werden durch Freignisse ausgel st Ereignisse k nnen durch Aktionen des Anwenders oder durch Initiative der Anwendung z B in Folge eines Systemereignisses ausgel st werden Die Auswertung der Bedingungen wie die Oberfl che fallabh ngig auf Ereignisse reagiert geh rt ebenfalls zu den In teraktionen Das Verhalten der Oberfl che setzt sich also aus Freignissen Reaktionsbedingungen und Reaktionen zusammen Eine Interak tion ist ein strukturiertes Gebilde aus e Ereignis mit Objektbezug d h der Bereich der Oberfl che auf den sich das Ereignis bezieht z B ein einzelnes Kontrollelement Informationsgehalt des UI 51 e 0 Bedingungen die zutreffen m ssen um eine oder mehrere bestimmte Reaktionen auf das Ereignis auszul sen e 0 Reaktionen die beim Zutreffen der Bedingungen fol gen Nat rlich kann ein und das selbe Freignis bei gleichem Objekt
41. Model lierungsthemen und die M glichkeiten wie diese Themen siehe auch Abschnitt Typische Ph nomene des Ul Entwickelns in diesem Kapitel durch Features unterst tzt werden k nnen Zu dieser Analyse geh ren e Beschreibung des Einsatzzwecks und der Zielgruppe Was wird mit den Werkzeugen entwickelt Welches Vorgehensmodell sieht das Werkzeug vor Welche Rollen verwenden das Werkzeug Welche Ergebnisse liefert das Werkzeug Welche Kenntnisse und Vorbedingungen werden vor ausgesetzt e Beschreibung der Features des Werkzeugs Welche Instrumente werden vom Werkzeug f r wel chen Zweck bereitgestellt Welche Anwendungsf lle werden unterst tzt F r wel che Anwendungsf lle ist das Werkzeug nicht vorgese hen e Ein Beispiel f r das Modellieren mit dem Werkzeug in Form von kommentierten Screenshots Die beim Modellieren von Uls f r eingebettete Systeme einge setzten Methoden k nnen ohne weiteres auf herk mmliche B roanwendungen bertragen werden 74 Werkzeuge 3soft tresos Guide 3Soft tresos Guide Guide ist ein Werkzeug zur Entwicklung eingebetteter Software oberfl chen Das User Interface wird grafisch in einer IDE In tergrated Development Environment mittels spezialisierter Edito ren z B View Editor f r Bildschirme State Editor f r die Ablauf struktur modelliert Das Werkzeug erm glicht die Simulation des UI als Prototyp und das Generieren von Teilen des Codes f
42. Programmierer und MDA Entwickler aus Anwendervertreter Spezifizierer und Programmierer haben ver schiedene Aspekte der Software im Fokus Die Lucia Sprache verbindet und berbr ckt die unterschiedlichen Sichten der am Projekt beteiligten Personen Sie erm glicht die koordinierte Zusammenarbeit der Interessengruppen so dass sich die unter schiedlichen Sichten zu einem Gesamtbild erg nzen UI Beschreibungssprache Lucia 139 Nutzung und Technik k nnen so im Zusammenhang diskutiert und L sungen auf einer gemeinsamen Formulierungsplattform erreicht werden Die Modellierungssprache legt Zielkonflikte offen und dient zugleich als Katalysator f r die Formulierung von L sungen die sowohl der Anwender als auch der Techniksicht gen gen Ziel des Modellierens in Lucia ist ein vollst ndiges und in sich stimmiges UI Modell das den Bedarf aller beteiligten Interessen gruppen abdeckt und missverst ndnisfrei die Anwendungsober fl che festlegt Das Ergebnis ist ein Modell mit eindeutiger Bedeutung der Inhal te und Relationen und kann als Datenstruktur z B in XML f r die parserunterst tzte Weiterverarbeitung bereitgestellt werden Eigenschaften der Lucia Sprache Die zur Formulierung von unseren User Interface Beispielen verwendete Oberfl chenspezifikationssprache hat den Arbeits namen Lucia Language for User Centered Information Archi tecture Die Namenswahl unterstreicht die Absicht mit dieser Sprache die
43. Systeme sowie neue experimen telle UI Formen werden nur am Rande erw hnt weil sie in der Praxis kommerzieller Projekte vergleichsweise selten vorkom men Softwareoberfl chen gibt es heute berall Sie werden aber mit wenig methodischer Unterst tzung gebaut gewisserma en nach dem Freihandprinzip und nach der Art einer Hundeh tte zu sammengezimmert Vorwort XI Wie aber entwirft und konstruiert man das was an der Oberfl Verwenden ist der che einer Software geschieht oder geschehen soll eindeutig und Schl ssel zum hinreichend genau Mit welcher Kombination aus Methoden und Beschreiben Werkzeugen l sst sich das Geflecht aus Verwenden Dialog Wirkung Erscheinen und Funktionieren planen und beschrei ben Dar ber gibt dieses Buch ber User Interface orientierte Archi tektur Auskunft und Anleitung Das Buch zeigt Mittel und Wege auf um Benutzeroberfl chen strukturierter und professioneller zu entwickeln Mit dem Know how aus dem Buch ist der Leser in der Lage Anwendungen so zu entwickeln dass jederzeit Klarheit und Sicherheit ber die Funktionsweise und die Funktionalit t der entwickelten Anwendung gegeben ist Dadurch k nnen Kom munikationsaufw nde gesenkt die Budgets und Zeitvorgaben des Entwicklungsprojekts abgesichert und die Anzahl der nde rungsauftr ge minimiert werden Paul Chlebek Affing im Juni 2006 Inhaltsverzeichnis Kapitel 1 Einfu hrung c s0ns 002006escesesennnsness
44. Zustands nachricht abfrage nderung gt Ausf hren von Methoden ter gt Nachricht ber Ereignisse 166 Architektur Document View Die obige Grafik illustriert das Prinzip des MVC Entwurfsmusters Der View e Pr sentiert Modellinhalte e Fordert vom Modell Aktualisierungen an e Sendet Eingabeereignisse zum Controller e Erm glicht das Selektieren eines Views Das Modell e Kapselt anwendungsinterne Zust nde e Beantwortet Zustandsanfragen e Stellt die Funktionalit t der Anwendung bereit e Benachrichtigt den View ber nderungen Der Controller e Definiert das Verhalten der Anwendung e Ordnet Anwenderaktionen zu Modellaktualisierungen zu e W hlt den View zur Beantwortung der Eingabeereignisse aus Ziele des Einsatzes von MVC sind e Trennung von Anzeige Pr sentations und Gesch ftslogik sowie Datenzugriff e Mandantenf hige Anwendung e Wiederverwendbare Actions Das MVC Entwurfsmuster wurde mit der Verbreitung von Small Talk bekannt Es unterscheidet zwischen e View Pr sentation Ausgabe Layout e Controller Programmsteuerung Interpretieren von Benut zeraktionen und e Modell Objektmodell Anwendungsfunktionalit t Daten haushalt Document View ist eine von Microsoft in MFC Microsoft Foun dation Classes umgesetzte Variante von MVC Eine weitere Variante des MVC Entwurfsmusters ist das MVC2 Modell Es ist eine f r Webanwendungen optimierte zustandslose Variante des objektorient
45. angenommen Sobald die Grenze von einem zugelieferten Anforderungsdoku ment zu einem Bestandteil der Systemmodelle mental berschrit ten ist stehen psychologisch wie technisch viele nutzbringende Unterst tzungsm glichkeiten f r die Zusammenarbeit der UI Spezialisten und der Programmierer bei der Verwertung der UI relevanten Informationen offen Bei vollzogener Integration der UI Modelle in der Architektur laufen UI Entwicklung und UI Codierung Hand in Hand Das MVC Entwurfsmuster 165 Bild 72 UI 9 Spezifikation und L ED UI Codierung 2 laufen Hand in Hand Wenn die UI Spezifikation ein Bestandteil der Softwarearchitek tur ist kann man folgende Vorteile nutzen e Die UI Beschreibung wird im gesamten Entwicklungsteam als relevantes Teilmodell des Systems wahrgenommen e Gemeinsame Versionskontrolle und nderungsmanage ment f r alle Modelle e Das Entwicklungsteam kann laufend teilweise automati siert ber nderungen an der UI Beschreibung informiert werden e Laufende Abstimmung der Modelle aufeinander beg nstigt das gemeinsame Verst ndnis der Anwendungsfunktionen und ihrer Nutzung an der Oberfl che e Aus der UI Beschreibung k nnen jederzeit teilweise au tomatisiert Informationen und Steuerungsdaten f r die Programmierung extrahiert werden 7 2 Das MVC Entwurfsmuster Modell View Controller Architektur Bild 73 MVC Entwurfsmuster a a a nderungs Zustands
46. auch dann wenn diese erste Version die Endanwender niemals sehen werden eine UI Dokumentation oder eine andere Form der Sollverhal tenbeschreibung mitgeliefert wird Sie erleichtert den Anwen dervertretern den Einstieg hilft Missverst ndnisse zu vermeiden und gibt Aufschluss dar ber was man von der Software erwar ten kann und was nicht Eine manuell erstellte Dokumentation beschreibt das UI Verhalten der Anwendung nachtr glich Ein User Interface Modell vorausgesetzt dass es im Projekt ernst genommen wur de beschreibt vorab wie die Oberfl che der Softwareanwen dung funktionieren soll Selbstverst ndlich haben beide Beschreibungsformen unter schiedliche 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 A priori und a posteriori Dokumentation 196 Dokumentation Bild 81 Aus einem UI Modell kann man Dokumente ableiten Die in einem User Interface Modell enthaltenen Informationen k nnen also f r das Erstellen verschiedener Dokumente heran gezogen werden Aus einem hinreichend formalisierten UI Modell kann man zum Beispiel die strukturierenden und die anleitenden Teile automati siert in ein Ger st f r die zu erstellende Benutzerdokumentation umwandeln In hnlicher Weise lassen sich Berichte ber den Entwicklungsstand der Oberfl
47. be rechtigten Anwendern frei konfiguriert werden k nnen Die beauftragte KreditSoft stellt bald fest dass das Abschreiben vom Altsystem in die neue Technologie nicht so einfach ist wie zun chst angenommen wurde Insbesondere erkl rt KreditSoft dem Auftraggeber sieht die Oberfl che in der neuen Technolo gie ganz anders aus weil neue und komfortable M glichkeiten der Bedienerf hrung zur Verf gung stehen Das Abschreiben der Bedienungsweise vom Altsystem und stellenweise veraltete durch moderne Bedienelemente zu ersetzen w rde nichts brin gen Man m sse vielmehr die gesamte Oberfl che durchg ngig neu planen Bei Entwurf der neuen Oberfl che werden die funktionalen An forderungen zugrunde gelegt Als Referenz f r die Anforderun gen an die Dialogmasken werden Ausdrucke von Masken aus dem Altsystem verwendet Die Oberfl che des Altsystems ist ber Jahre erg nzt und opti miert worden Eine Dokumentation aller Bedienungsm glichkei UI Beschreibung wieder verwenden 227 ten gibt es nicht Die Anwendungsexperten k nnen im Tagesge sch ft nicht entbehrt werden Daher bleiben viele Eigenschaften des Altsystems dies stellt sich sp ter heraus unber cksichtigt und werden erst nachtr glich oder gar nicht in der neuen Software umgesetzt Die Begeisterung der Anwender f r das neue System h lt sich in Grenzen Das Budget des Projekts wird erheblich berzogen Die Zeitvorgaben ebenso 13 2 Ul Beschr
48. che enthaltenen Informationen wiedergeben e Welche Informationen m ssen in einer Sprache f r Ober fl chenspezifikationen formuliert werden k nnen Die durch das User Interface Informationsmodell aufgestellte Datenstruktur erf llt mehrere Funktionen e Datensenke f r die Aufnahme der Informationen aus der Spezifikation e Notationsneutrale Struktur f r Objekte Attribute und As soziationen einer spezifizierten Benutzeroberfl che 136 Sprache e Datenquelle f r die Umformung der spezifizierten Infor mationen in verschiedene Verwendungen z B in Code und Laufzeitstrukturen Damit bildet das Informationsmodell die Projektionsachse zwi schen einer UI Spezifikationssprache und den Laufzeitdatenstruk turen zum Pr fen Auswerten und Simulieren der Anwendungs oberfl che mit Interpretationsprogrammen Br M2C Laufzeitoptimierte 7 x Datenstrukturen Notationsspezifische Notationsneutrales Formulierungen Informationsmodell Bild 66 Das Informationsmodell kapselt Notation und Laufzeitformat Auswertungsoptimierte Datenstrukturen Die obige Abbildung zeigt wie das Informationsmodell die Spra che der Spezifikation von den Datenstrukturen auf denen die rechnergest tzte Verarbeitung der Spezifikation erfolgt kapselt Der praktische Nutzen dieser Kapselung ist dass die Sprache zur Spezifikationsformulierung Hochsprache ver ndert werden kann ohne dass diese Ver nderungen auf
49. das Bedienpult Gemeint ist Das Verstehen einer Maschine erfolgt anhand des sen wie die Maschine vom Anwender beim Benutzen erlebt wird Das gilt sowohl f r reale Maschinen wie einen Korkenzie her oder einen Toaster als auch und insbesondere f r virtuelle Softwaremaschinen und ihre Benutzeroberfl chen wie zum Bei spiel ein Textverarbeitungsprogramm eine Suchmaschine im Internet oder das Navigationssystem in einem Fahrzeug Anwendungssoftware ist ein Ger t das nur durch das Verwen den der Softwareoberfl che f r den Anwender materiell existiert Also kann man Software hinreichend nur anhand der Interakti on des User Interface mit dem Anwender nicht aber ber den inneren Aufbau der Softwarekomponenten allgemein definieren beschreiben vermitteln und verstehen Einstellungen J x j u Datenschutz Allgemein a t Chronik L schen Datenschutz D Gespeicherte Formulardaten L schen e Web Festures F Gespeicherte Passw rter L schen Re paee Download Manager Chronik L schen Downloads Der Download Manager gibt Ihnen enen berblick ber k rzlich heruntergeladene Dateien Dateien aus dem Download Manager entfernen 1 v Erweitert Cookies L schen lt l Cache L schen Alle Daten die w hrend der Benutzung angefallen sind schen Alles l schen E In der Konsequenz heift das aber Datenmodelle und Flussdia gramme Klassen und Komponentendiagramme k nnen eine Verw
50. der Funktion aber auch an der Verwendung des Werkzeugs weil die Funktion davon abh ngt wie von wem und unter welchen Umst nden das Werkzeug verwendet wird Die Nutzung steht im Vordergrund der Modellierung von Bauwerken und Maschinen Bei Software steht heute noch der innere Aufbau im Vordergrund Form follows Junction Function follows Use Case 10 Einf hrung Bild 9 Form and Function follows Use Case RD Form follows Man k nnte auch berspitzt formulieren Form follows Mal Malfunction function denn oft geh rt es zu den Aufgaben einer Oberfl che das Risiko von Fehlbedienung und Fehlfunktion zu senken Damit hat eine Oberfl che neben dem Bereitstellen von benutz baren Funktionen auch eine anleitende und eine dokumentie rende Aufgabe Der Kernsatz Form and Function follows Use Case er ffnet den Zugang zur folgenden Sicht auf die Zusammenh nge zwi schen dem Anwenden einer Software der Funktionalit t der technischen Umsetzung und der Benutzeroberfl che Es gibt verschiedene Blickwinkel des Planens Verwendungswei se Funktionsumfang technische Umsetzung und Form Use Case wozu und wie wird das Softwarewerkzeug benutzt Bild 10 Verwendung Funktion Technik Form Verwendung Funktion Inhalt was kann die Software Umsetzung womit woraus und wie Todinik wird die Software gebaut Oberfl che womit wird was wie an der Software bedient Q Eo u
51. diesem Kapitel eine Praxisan leitung zur Erg nzung der g ngigen Entwurfsmethoden mit UI Modellen Nutzen UI und Business Logik sind von Anfang an aufeinander abgestimmt ben tigte Funktionen und Datenstruk turen werden fr hzeitig erkannt Die laufende Vollst ndigkeit und Korrektheit der Funktions und Datenentw rfe wird besser abgesichert Kapitel 9 Prozesssteuerung in dem die in einer Ul Spezifikation enthaltenen Informationen zu Ablaufgraphen und zu elektronischen Workflows destilliert werden Eine UI Beschreibung enth lt Informationen ber Dialogabfolgen und Details ber die Reihenfolge der T tigkeiten beim Ausf hren von Aufgaben mit der Software Diese Informationen k nnen herausgefiltert und zur Steuerung von Arbeitsschritten auf Workflow und Prozessebene herange zogen werden F r Entwickler von prozessorientierten bzw workflowgesteuer ten Anwendungen zum Beispiel Sachbearbeitungs und Verwal tungssoftware zeigt das Kapitel M glichkeiten auf Anwen dungsworkflows regelbasiert anhand der aus der UI Beschreibung gewonnenen Ablaufschritten und Regeln mit Steu erungsdaten zu versorgen Kapitel 10 Dokumentation in dem die in einer Ul Beschreibung gesammelten Informationen als Ger st f r Hand b cher und Hilfesysteme dienen Eine UI Beschreibung enth lt vielf ltige Informationen ber Wer tebereiche Abl ufe Dialoginhalte und Fallabh ngigkeiten Zum sauberen Arbeiten geh rt es auch
52. eine Navigationshintert r k nnen Plausibilit ts pr fungen der UI Implementierung das Betreten einer Dialogsei te bzw eines Eingabefelds verhindern z B weil die fachlichen Voraussetzungen fehlen und den Test von Eingabewerten verei teln Unterst tzt die UI Implementierung keine Hintert r f r die Navi gation mittels eines Testautomaten dann sind die Tests des Test skripts nur in Verbindung mit echten fachlichen Testszenarien anwendbar In diesem Fall k nnen die generierten Testanwei sungen als Datenquelle f r manuell zu erstellende Testf lle von Nutzen sein 11 4 Nutzen Anhand einer formalen oder einer halbformalen UI Spezifikation k nnen automatisierte Massentests der Oberfl che generiert wer den Diese Tests ersetzen keine fachlichen Testszenarien erspa ren aber den Anwendern bzw den Testern den in der Regel langwierigen und eint nigen Test des Standardverhaltens einzel ner Dialogelemente implementieren UI in Laufzeit generierien umgebung et User Interface TEE Test protokoll ei z analysieren Testskript ni generieren Pr Generische Testf lle Navigations regeln Aus dem UI Modell werden generische Testf lle z B Eingaben innerhalb und au erhalb des definierten Wertebereichs eines Eingabefelds ermittelt und ein Testskript erzeugt mit dem das UI in der Laufzeitumgebung getestet wird Nutzen 207 Die Testergebnisse k nnen zur Identifizierung und Behebung von Fl chtigkeits
53. eingef hrte Begriff Prozesslogik bezeichnet die Re geln die den Bearbeitungsfluss einer Softwareanwendung steu ern Zur Prozesslogik geh ren insbesondere Abfolgen von Dialogsei ten sowie das Auswerten und Setzen des Bearbeitungsstatus auf den die Gesch fts und Pr sentationslogik der Anwen dung Bezug nehmen kann um Entscheidungen ber Aktionen der Software zu treffen Die Entscheidungen k nnen zum Bei spiel das Aufrufen einer bestimmten Systemfunktion oder das Ausblenden und Einblenden von Kontrollelementen betreffen Der Begriff Bearbeitungsstatus steht f r eine Ansammlung von benannten Statusmarken die das Vorliegen verschiedener Situationen in der Softwareanwendung repr sentieren und die jeweils den Wahrheitswert wahr oder falsch haben k nnen Die Werte der Statusmarken werden durch die Auswertung eines logischen Ausdrucks einer boolean expression gesetzt Der Wert einer Statusmarke kann aus dem Datenhaushalt der An wendung unter Verwendung der Werte anderer Statusmarken ermittelt werden Das hei t Durch Wiederverwendung der Sta tusmarken k nnen komplexe Situationen aus einfacheren Situa tionen zusammengesetzt werden Bei nderungen in der Prozesslogik brauchen in der Regel nur die Statusmarken ge ndert zu werden die die Basissituationen repr sentieren Die zusammengesetzten Statusmarken die auf einfachere Situationen aufbauen bleiben in der Regel stabil Durch den Aufbau einer Hierarchie
54. ersten beiden Anforderungen also auf das Modellelement HCI Model und damit auf die gesamte Oberfl chenspezifikation Die unbe nannte Anforderung Im Hallo Welt Beispiel enth lt bezieht sich auf Step named Hallo_Welt Eine Anforderung muss keinen Namen haben allerdings kann dann von anderen Stellen der Spezifikation oder auch bei Aus wertungen nicht Bezug auf so eine unbenannte Anforderung genommen werden Daher empfiehlt es sich echte Anforde rungen immer mit einem Namen zu versehen Eine Anforderungsbeschreibung kann bei Bedarf weiter struktu riert werden d h z B in Ausgangssituation Zielsetzung Vor und Nachbedingungen Wann und wie diese M glichkeit ange wandt wird zeige ich in einem sp teren Beispiel siehe Anf_2 Start Step named Hallo_Welt using default Screen definiert den ersten Ablaufschritt im Workflow der Benutzerober fl che Die Wortfolge Start Step zeichnet den Schritt als den ersten Schritt im logischen Ablauf der Oberfl che aus Da unser Beispiel nur einen logischen Ablaufschritt hat w rde das Auslassen von Start keine Auswirkungen haben Wenn Start Step nicht angegeben wird gilt die Konvention dass der Ablauf mit dem in Definitionsreihenfolge ersten Schritt des Mo dells beginnt H chstens ein Step des Modells darf mit dem Pr dikat Start versehen werden Typischerweise ist dieser Ablaufschritt ein 144 Sprache Login oder ein Hauptmen
55. hackte einfach auf einen anderen ein bis dieser eine gef llige Form hatte Sp ter als Baumeister und Ingenieure der Antike der Renais sance und des Industriezeitalters gro e komplizierte Geb ude und Maschinen zu errichten begannen wurde das Zusammen wirken mehrerer Entwickler z B Baumeister und seine Gesel len und die Abstimmung mit dem Auftraggeber z B K nig F rst Fabrikant unabdingbar Damit wurde auch das gemein same Verstehen des geplanten Werkes wichtig und so kamen Baupl ne und Modelle ins Spiel Beim Bauen von Werkzeugen und Maschinen ist das Verstehen der sp teren Verwendung ausschlaggebend daf r ob das Pro dukt praxistauglich wird Das Wahrnehmen des Anwendungs zwecks und der Anwendungsweise ist Vorbedingung f r korrek te Entscheidungen der Konstrukteure Alles andere muss sich in die Weise wie ein Produkt verwendet wird einf gen Die Funktionsweise die Form die Konstruk tionsmiltel Dieses Buch handelt von der Zusammenarbeit und vom gegen seitigen Verstehen von Menschen die gemeinsam komplizierte elektronische Maschinen beauftragen und bauen Diese Maschi nen die man nicht in die Hand nehmen und anfassen kann nennt man Software Software ist nicht aus Holz und nicht aus Stein Die Gesetze der newtonschen Mechanik gelten f r sie nicht man kann sie also nicht ber ihre mechanischen Eigenschaften wahrnehmen Soft warefunktionen quietschen nicht beim Starten Men und Sym bolleisten
56. hren been det und damit der Lauf der Anwendungsoberfl che terminiert 4 5 Dialoginhalte abgrenzen Ziel des Abgrenzens von Dialoginhalten ist es f r die einzelnen logischen Schritte der Anwendung zu wissen welche Informati onen auf die dazugeh rige Dialogseite geh ren Zum Abgrenzen geh rt es zu ermitteln welche Informationen auf einer Dialogseite zusammengefasst werden sollen und wel Nutzen der UI Skizzen 101 che Informationen unter Umst nden auf zwei Dialogseiten aufge teilt werden m ssen Das Ergebnis dieser Abgrenzung ist ein stabiles Bild davon wel che Dialoginhalte hinter einzelnen logischen Schritten stehen Durch das Abgrenzen der Inhalte der Dialogseiten wird die Ab laufstruktur abgesichert und der Datenumfang der logischen Schritte aneinander angeglichen 4 6 Nutzen der Ul Skizzen Der Nutzen der UI Modelle in der Startphase ist dass Kunden und Entwickler einen vollst ndigen berblick ber Umfang und Struktur der Anwendungsoberfl che gewinnen Der berblick erfolgt in der Breite die Tiefe folgt sp ter und wird zun chst vermieden Das erste UI Modell wird von Bedienungsprototypen Designs und Schaubildern einzelner Dialogseiten der Anwen dung begleitet Die ersten UI Modelle erm glichen den Projektbeteiligten die Beurteilung des Umfangs der Anwendung der Vollst ndigkeit der Kernanforderungen und der Arbeitsweise der Oberfl che Maskenfluss Aufteilung Dialogf hrung Auf der Basis d
57. koennte eine beliebige andere Layoutvorschrift die der Spezifikationsleser oder ein Interpreter versteht stehen Zum Umfang von Konkreto gehoeren lediglich die Platzhalter lt htm1l gt lt body gt lt table gt lt tr gt lt td gt placeholder named titelzeile lt td gt lt tr gt lt tr gt lt td gt placeholder named koerper lt td gt lt tr gt lt tr gt lt td gt placeholder named fusszeile lt td gt lt tr gt lt table gt lt body gt lt htm1 gt zi Widget named spezielles_text_widget I Hier ist die Schnittstelle zu Darstellungselementen Man kann hier umgangssprachlich oder formalisiert z B in SVG oder in HTML spezifizieren wie das Widget zur Darstellung des logischen Bedienungselement aussehen soll fsi lt hl gt value lt h1 gt Functionality anwendungsfunktion_1 I thats the interface to the business logic some code to call the functionality in its runtime environment can also be used to call a stub zi Sehen wir uns das Beispiel n her an Es zeigt wie die Verqui ckung von Abl ufen Inhalten Layout Darstellung Interaktionen und Anforderungen systematisch aufgegliedert und zu einem abgestimmten Ganzen zusammengef gt wird Nachfolgend werden anhand der im Hallo Welt Beispiel ver wendeten Ausdruckformen die von der Lucia Sprache gelieferten L sungen zur Formulierung von komplexen Zusammenh ngen und Abh ngigkeiten zwischen den unterschiedlichen Bausteinen der
58. lare z B eine Hotelbuchung ausgef llt werden sollen Der Workflow der Anwendung besteht aus mehreren an einander gereihten Formularen e Systeminitiierter Dialog Ebenfalls eine Form des ange leiteten Dialogs Der Computer informiert den Anwender ber ein Ereignis und bietet in der Regel Reaktionsm g lichkeiten an z B in Form eines Auswahlmen s e Offener Dialog nicht angeleiteter Dialog Der Mensch erkl rt was er m chte der Computer grenzt die Antwort m glichkeiten ein Die meisten Anwendungen vor allem Gesch ftsanwendungen sind Form Filling Dialog Anwendungen In der Regel enthalten alltags bliche Anwendungen auch systeminitiierte Dialoge Der offene Dialog zwischen Software und Anwender ist bis auf ein zelne gesprochene Steuerbefehle in spezialisierten Anwendun intuitiv auf Erfahrungen und Metaphern zur ck 40 Oberfl che gen z B Maschinensteuerung Radionavigationssysteme noch nicht weit verbreitet Dialogmodalit ten Dialogmodalit t bezeichnet die Mittel die die Oberfl che ber wiegend dem Anwender zur Dialogf hrung bereitstellt Befehlszeilen Command Line Interpreter CLI e Der Anwender gibt Befehle und Befehlsparameter in einer Kommandozeile an e Der Befehl wird mit einer Freigabetaste Enter abge schlossen und an den Kommandbointerpreter bergeben e Nach dem Ausf hren des Kommandos ist der CLI einga bebereit f r den n chsten Befehl e Beispiel Unix Command Shell Tex
59. multimedialen Assistenten f r die eigentliche Funktiona lit t einer Software gewachsen In dialogintensiven Anwendungen machen Pr sentation und Interaktion zwischen Anwender und Anwendungsoberfl che oft mehr als 2 3 der Software aus Myers 1992 Die eigentliche Transaktion kommt hingegen erst am Schluss der Verhandlung zwischen Anwender und User Interface zur Ausf hrung Der Anteil der Gesch ftslogik am Gesamtumfang einer dialogin tensiven Anwendung ist kleiner als bislang aus der Sicht von Objekt und Ablaufmodellen angenommen wird Zusammenfassung 25 Es lohnt sich also Modelle Methoden und Werkzeuge zur for malen Beschreibung von Oberfl chen zu entwickeln marginal 4 Ul Interaktion dominierend Fr her Heute Interaktive dominierend User on User Interface Stapelverarbeitung Funktionale Logik Operationen von Transaktionen 30 Funktionen und Prozeduren Funktionen sind Services f r das UI User Interface entwickeln User Interface View und Keine 5 bezogene Controller standardisierten Eingabe Ausgabe Code Methoden Operationen Modell ebene Gesch ftslogik Systemlogik Code Funktionale Operationen Funktionalit t entwickeln Bild 13 User User Interface orientierte Architektur ist eine Bauentwurfslehre rterfaces machen f r durchdachte interaktive Softwareober
60. sein soll die der Auftraggeber stufenweise zu einem Gesamtsystem ausbauen m chte Inhalte der User Interface Architektur 13 AlphaSoft steckt daher gemeinsam mit dem Auftraggeber Alpha Rent die Grenzen des von AlphaRent gew nschten Gesamtsys tems ab und nimmt die grunds tzlichen Anforderungen an die Gesamtfunktionalit t auf So wird sichergestellt dass die Ent wickler der Kundenverwaltung den zuk nftigen Gesamtkontext kennen und ber cksichtigen k nnen Sodann werden die An wendungsszenarien der Kundenverwaltung verfeinert Bei der Detaillierung der Anforderungen werden zuerst die grobe Abfolge der Dialogmasken und die Maskeninhalte aufge nommen In mehreren Iterationen werden dann die Dialogele mente und die Anordnung der Informationen auf den Masken beschrieben Ebenso wird bei der weiteren Detaillierung be schrieben wie die Anwendung beim Bedienen der einzelnen Dialogelemente reagiert Die Masken Abl ufe und Interaktionen werden kontinuierlich mit AlphaRent abgestimmt bis die An wendungsoberfl che steht Begleitend werden Klassendiagram me Aktivit tsdiagramme und Sequenzdiagramme modelliert Erst dann wird implementiert Das Vorgehen ist an der fachlichen Verwendung der Software orientiert e 1 Systemgrenzen abstecken e 2 Dialogabfolge im Kontext der Verwendung ermitteln e 3 Schl sselfelder der Masken bestimmen e 4 Iterative Detaillierung des UI e 5a Fertigstellen und Test der UI Bedienung e 5b F
61. setzen voraus dass der Anwendervertreter Spezifizierer Pro grammierer bereits ein fertiges detailliertes weitgehend fehlerfreies und stabiles Bild der Oberfl che im Kopf mit bringt Bild 46 User Interfaces werden schrittweise entwickelt 106 Detaillieren Bestehende Werkzeuge setzen ein weitgehend feststehendes Konzept voraus Es werden Werkzeuge mit Planungscharakter ben tigt UI Perspektiven Die g ngigen UI Werkzeuge bieten f r die iterative und evoluti on re Entwicklung von Oberfl chen wenig Unterst tzung Die Werkzeuge unterst tzen den Entwickler in erster Linie dabei seine bereits weitgehend feststehende L sung in die zur Verf gung stehenden Formalismen zu bertragen Viele GUI Entwicklungswerkzeuge fordern vom Anwender von Anfang an die Festlegung von Details die m glicherweise erst sp ter gekl rt werden k nnen Die erstellten GUI Modelle erwei sen sich als z h wenn der Entwickler auf Grund neuer Erkennt nisse globale Ver nderungen vornehmen m chte Im Extremfall wird das UI Modell weggeworfen und von vorne begonnen Die Entwicklung einer Benutzeroberfl che ist ein iterativer und kommunikativer Prozess Die UI Entwicklung hat meist einen evolution ren Charakter Das liegt daran dass der Umfang an fangs oft noch nicht berschaubar ist und dass dem Auftraggeber viele gew nschte Eigenschaften und Bedienungsmerkmale erst auffallen wenn er eine Vorabversion des User Interfa
62. stellt es reicht der name der funktionalit t es geht darum zu wissen dass was an einer stelle des hci getan wird nicht wie es getan wird f r das hci relevante antworten der funktionalit t nicht daten sondern status und fehlercodes z b sim nicht erkannt die mit der funktionalit t assozierten daten k nnen nat rlich auch statuscodes enthalten die wahl was wo erwartet wird ist eine designentscheidung I Anne requirements anforderungen sind benannt oder unbenannt auf die benannten anforderungen kann man verweisen die unbenannten anforderungen haben kommentar charakter anforderungen k nnen auf andere modellstellen und aufeinander verweisen andere modellstellen k nnen auf anforderungen verweisen anforderungen legitimieren funktionale modellelemente jedes funktionale modellelment sollte auf mindestens eine anforderung verweisen requirements_ En Anforderungen Querverweise p requirement_ REQUIREMENT x INSIDE REQUIREMENT D taggedcode_ x TAGGEDCODE p 156 Sprache Einige Semantikregeln Einschub Reihenfolge des Abarbeitens einer UI Beschreibung Zusammenarbeit zwischen Steps und Screens 1 Betreten der H lle des Steps 1b Abarbeiten der on enter Ereignisse des Steps 2 Wenn der Step einen Screen benutzt dann Screen auf bauen 3 Abarbeiten der on enter Ereignisse des Screens Dia logs 4 Hauptschlei
63. ufe Anwendungsnavigation und Pr senta tionsinhalte k nnen in UML nicht direkt modelliert werden sie he auch Kapitel Sprache Model Driven Architecture MDA 169 Gerade aber eine Modellierungsm glichkeit der Pr sentations schicht d h der Mensch Maschine Schnittstelle also des View und des Controllers aus dem MVC Entwurfsmuster ist aus Sicht einer dialogintensiven Gesch ftsanwendung besonders w n schenswert und f hrt zur Steigerung der Produktivit t 7 3 Model Driven Architecture MDA Heute 2006 ist es seit mehr als 25 Jahren blich Anwendungen mit problem und objektorientierten Sprachen Cobol Pascal C C Java zu programmieren Die i d R objektorientierten Pro grammiersprachen sind mit Bibliotheken ausgestattet die unter anderem Datenzugriff und grafische Oberfl chen IO unterst t zen Moderne Entwicklungswerkzeuge verwenden zum Teil schon Modelle zum Beispiel UML Klassendiagramme um daraus die Datenhaltungs und die Datenzugriffsschicht als Code zu gene rieren blich sind auch damit einhergehende UI Designwerkzeuge zur visuellen Entwicklung von grafischen Dialogseiten Gew hnlich w hlt man Oberfl chenelemente aus einem vordefinierten erwei terbaren Vorrat aus platziert sie mit drag und drop auf der Dia logseite und legt in ihren Properties fest wie sie aussehen wel che Daten sie anzeigen und welche Funktionen sie ausl sen sollen Aus diesen Masken Modellen wi
64. von Statusmarken zur Repr sentation der verschiedensten Situationen ber die die Software an der Oberfl che Bescheid wissen muss bleiben die Regeln die die Prozesslogik verwendet flexibel und derungsrobust Prozesslogik und Situationen 187 Beispiel Situationen festlegen Die folgenden Statusmarken definieren zwei zusammengesetzte und zwei einfachere Situationen Die Situationen s buchung_ok und s bestellung ok nehmen Bezug auf andere weniger abstrakte Situationen F r die Situationen s kundendaten ok und s artikel_vorraetig neh men wir in unserem Beispiel an dass sie durch Pr fung von mehreren Datenfeldern im Datenhaushalt der Anwendung ermit telt werden Um das Beispiel einfach zu halten nehmen wir des Weiteren an dass diese Situationen keine weiteren untergeord neten Situationen einschlie en s buchung_ok s bestellung ok amp s bestaetigung erfolgt s bestellung_ok s kundendaten_ ok amp s artikel_vorraetig amp s freigabe erfolgt s kundendaten_ok weitere Detaillierung s artikel_vorraetig weitere Detaillierung Wenn sich nun etwas an den Pr fbedingungen f r Kundendaten ndert dann muss nur diese eine Regel s kundendaten ok ange passt werden Alle anderen Regeln bei denen die erfolgreich stattgefundene Pr fung der Kundendaten Teil der Regel ist sind automatisch aktuell und brauchen nicht ge ndert zu werden Mit der Prozesslogik wird also ein Netzwerk aus Regeln f
65. werden dass Situationen zirkul r voneinander abh ngen und so zu Dead Locks bei der Berechnung der Sta tusmarken f hren Prozessbeschreibungen im UI abbilden 191 9 3 Prozessbeschreibungen im Ul abbilden Wie man eine vorliegende Prozessbeschreibung in eine Prozess logik f r ein User Interface umformt zeigt der folgende Leitfa den e Definieren aller Prozesszust nde als logische Schritte e Anordnung der Schritte in einer Sequenz von der Wiege bis zur Bahre e Aufbau einer Hierarchie aus logischen Schritten durch Ver feinerung und Generalisierung der Schritte e Definition von Interaktionen Transitionen auf Schrittebe ne e Definition der Situationen auf die bei der Steuerung des Prozesses Bezug genommen wird e Aufbau der Situationenhierarchie und Formulieren der Er mittlungsvorschrift f r die einzelnen Statusmarken e Auswahl der Schritte die ein UI haben e Definition von steuerungsrelevanten Kontrollelementen e Detaillieren der Interaktionen auf Ebene der Kontrollele mente Beispiel Situationen verwenden Gegeben sei ein Prozess zur Buchung eines Hotels Er beinhaltet 1 die Suche nach einem Hotel 2 die Buchungsdatenerfassung und 3 die Buchungsdurchf hrung Die Abl ufe die funktionalen Anforderungen und die Randbe dingungen seien in der Prozessdefinition z B in einem Aris Prozessmodell nebst Begleitdokumentation beschrieben 1 Logische Schritte hotel_suchen buchung_ vorbereiten buchu
66. werden k nnen Bild 102 Anforderungs M glichkeiten der 9 dokumentation Verwendung von UI Modellen H 8 7 Auswertungen User Interface 5e Model Kirn Dokumentations ra ger ste UML Klassen ger ste K Oberfl chen prototyp Generische Testf lle Bis User Interface Modelle fl chendeckend eingesetzt werden wird sicher noch eine umfangreiche Weiterentwicklung der heu tigen Vorgehensweisen stattfinden S S A D Die notwendige Entwicklung betrifft sowohl unterst tzende Werkzeuge und Methoden als auch das Selbstverst ndnis der Anwendungsentwickler und die Nutzenwahrnehmung der Ent scheider Die hier vorgestellte User Interface Architektur hat einige L cken und l sst Fragen offen In der vorliegenden Fassung leistet sie keine ersch pfende Antwort auf alle Fragen der UI Entwicklung liefert jedoch einen praxistauglichen berblick ber die UI Orientierung im Softwareentwicklungsprozess Auf der Grundlage der in diesem Buch aufgezeigten Ideen und L sungsans tze k nnen Sie viele neue Wege in der t glichen Arbeit an Ihren Softwareprojekten beschreiten und bessere Er gebnisse erzielen Die weitere Entwicklung bleibt spannend Ich bin berzeugt davon dass die User Interface orientierte Architektur darin eine wesentliche Rolle spielt Vielen Dank dass Sie dieses Buch gelesen haben Literaturverzeichnis Kidder 1982 Rose 1985 Harel 1987 Ebeling 198
67. 2 UI Spezifikation und UI Codierung laufen Hand in Hand 175 Bild 73 MVGEntwurfsm ster 2 228 32 Klara a E 176 Bild 74 MVC und Zuordnung von Entwicklungs Themen eeen 178 Bild 75 Komponenten Modell f r eine Ul orientierte Architektur 182 Bild 76 Oberfl che Funktionen und Daten sind Teile eines Ganzen 185 Bild 77 Gegenseitige Abh ngigkeiten von Bedienung und Funktionen 187 Bild 78 Klassenger st f r die Kundenverwaltung esenesnnesnesneennnnen 191 Bild 79 Vorgehenskarte f r synchrone UI und UML Modellierung 192 Bild 80 Abl ufe und Regeln sind implizit im Programmcode eingebaut 195 Bild 81 Aus einem UI Modell kann man Dokumente ableiten 206 Bild 82 Verwerten des UI Modells zum Erstellen von Dokumenten 209 Bild 83 Mit UI Modellen sind einfache UI Tests automatisierbar 211 Bild 84 Klassifikation von automatisierten Tests 212 Bild 85 Vorgehenskarte f r das automatisierte Testen des UI 214 Bild 86 Artefaktekette beim UI TESt rroen a 217 Bild 87 Beim UI f hlen sich viele kompetent srccnccnrmesracisiii 219 Bild 88 User Interface Entwicklung ist ein interdisziplin res Thema 220 Bild 89 Funktions und Daten Entwickler grenzen das User Interface gerne aus 222 Bild 90 UI bezogene Rollen und Aufgaben im Entwicklungsprozess
68. 63 167 170 172 176 183 191 195 196 198 201 209 210 211 212 213 214 220 223 224 229 230 231 v Verhalten 44 50 51 54 64 66 75 78 85 106 122 124 129 137 218 228 229 w Werkzeug 9 57 66 69 73 106 121 170 180 189 193 Widget 52 74 78 79 80 136 137 141 142 145 146 147 148 x XML2 29 33 63 75 77 88 139 172 173 Zeichen 51 143 Zielgruppe 1 5 15 73
69. 8 Myers 1992 Feldmann 1998 Raskin 2001 Lauer 2002 Shneiderm 2002 Wessel 2002 Blackwell 2003 Ceri 2003 Tracy Kidder Die Seele einer neuen Maschine Birkh user Verlag Basel Boston Stuttgart 1982 Frank Rose Ins Herz des Verstandes Auf der Suche nach der k nstlichen Intelligenz Lev Roitman Verlag M nchen 1985 David Harel Statecharts A Visual Formalism for Complex Systems Science of Computer Programming 8 Elsevier 1987 http www wisdom weizmann ac il dharel SCANNED PAPERS Statecharts pdf Adolf Ebeling Gehirn Sprache und Computer Unerreichte Natur k nstliche Intelligenz Heinz Heise Verlag Hannover 1988 Brad A Myers Hrsg Languages for developing user interfaces Jones and Barlett Publishers Boston 1992 Clarence G Feldmann The Practical Guide to Business Process Reengineering Using IDEFO Dorset House Publishing New York 1998 Jef Raskin Das intelligente Interface Adison Wesley Verlag ein Imprint der Pearson Education Deutschland M nchen 2001 Michael Lauer Python und GUI Toolkits mitp Verlag Bonn 2002 Ben Shneiderman User Interface Design Deutsche Ausgabe 3 Auflage mitp Verlag Bonn 2002 Ivo Wessel GUI Design Richtlinien zur Gestaltung ergonomischer Windows Applikationen 2 aktualisierte und berarbeitete Auflage Carl Hanser Verlag M nchen Wien 2002 Alan Blackwell Thomas Green Notational Systems The Cognitive Dimensions of Notations
70. Au entemperatur Situationen Deklarationen von Texten und Grafiken Schnittstellen zur grafischen Darstellung logischer Kontrollelemente Anforderungsobjekte Beschreibungen von Anforderungen und Querverweise zwischen Anforderungen Die Syntax von Lucia legt fest wie diese drei Grundobjekte wei ter unterteilt werden und nach welchen Regeln sie einander enthalten bzw aufeinander verweisen k nnen Die Semantik von Lucia legt fest was die Kombinationen von Objekten bedeuten und wie sie als Oberfl chenspezifikation zu interpretieren sind UI Beschreibungssprache Lucia 141 Zur Abgrenzung Lucia ist keine Programmiersprache vgl Ebe ling 1988 S 169 174 sondern eine auf User Interfaces zuge schnittene Spezifikationssprache d h sie legt z B keine Imple mentierungsdetails fest und toleriert auch unvollst ndige Kon strukte Lucia Beispiel Hallo Welt Fangen wir mit einem Hallo Welt Beispiel an Wir wollen eine Hallo Welt einfache Benutzeroberfl che beschreiben die auf dem Bild schirm Hallo Welt ausgibt und dann mit einem Knopf Ende beendet wird Anhand von diesem trivialen Beispiel erkl ren wir die wichtigsten Sprachkonzepte und Elemente Sp ter k nnen wir unser Beispiel Schritt f r Schritt um statische und dynamische Auswahllisten Interaktion Situationsabh ngig keit Funktionsanforderung und Datenabfragen erweitern HCI Model named Hallo Welt Beispiel 1 I das ist der modellkopf er ide
71. Ausbildung der Personen mit Schl sselrolle im Spezifikationsprozess e der Notation der UI Beschreibungssprache e von der Einbindung der Entwickler in den Modellie rungsprozess e und vom Komfort der Modellierungswerkzeuge Ul Prototypen mit HTML e HTML Forms e Layout mit HTML Tabellen und Layern Die Spezifikation mit HTML Forms st tzt sich auf die in HTML bzw DHTML verf gbaren M glichkeiten zum Definieren und zum Anordnen von Kontrollelementen auf Masken Diese Spezifikationsform erlaubt das detaillierte Festlegen der Dialogabfolge und der Dialoginhalte sowie Interaktionen Sie liefert aber f r sich genommen keine vollst ndige UI Spezifikation sondern erg nzt andere Spezifikationsformen mit techniknahen Maskenentw rfen in HTML z B eine strukturierte UI Beschreibung Programmierte Ul Prototypen e Ausf hrbare Oberfl che e Codiert in einer Programmiersprache e Verwendet in der Regel ein GUI Toolkit Die Oberfl che der Anwendung wird durch ablauff hige pro grammierte Beispiele definiert Die Eigenschaften der Oberfl che sind nicht explizit beschrieben sondern liegen implizit in den erfahrbaren Eigenschaften des programmierten UI Prototypen Der Prototyp liefert die f r den Anwendervertreter intuitivste Form des Erlebens des Oberfl chenentwurfs Allerdings Den Oberfl chenentwurf verfeinern und detaillieren k nnen der An wendervertreter und der Spezifizierer nur zusammen mit einem Programmierer UI De
72. Bauplaner e Architekt Bauleiter e Programmierer Umsetzer e Projektleiter Koordinator Eskalationsstelle legt fachliche Anwender Rahmenbedingungen vertreter fest pr ft best ti User Interface kommuniziert Spezifikation interpretiert 7 detailliert Programmierer Projektleiter analysiert modelliert legt technische Rahmenbedingungen fest En in an Das Entwicklerteam Programmierer Spezifizierer Architekt folgt bei der Entwicklung der Oberfl che den von den Anwen dervertretern festgelegten Rahmenbedingungen Der Fortschritt Bild 90 UI bezogene Rollen und Aufgaben im Entwicklungsprozess 216 Projektmanagement Bild 91 Use Cases Map der UI Entwicklung Bedienkonzept Ihrer Arbeit kann am Erf llungsgrad der Anwenderforderungen gemessen werden Der Architekt legt die technischen Rahmenbedingungen der Entwicklung fest Der Projektleiter legt die organisatorischen Rahmenbedingungen der Entwicklung fest und kommuniziert die Arbeitsergebnisse an die Projektgremien Weitere an der UI Entwicklung beteiligte Spezialisten k nnen sein e Designer Grafiker e Handbuchautor e Tester Qualit tsmanager e Usability Experte Bedienkonzeptentwickler e Technik und Business Consultants e Prozessspezialisten e Integratoren von Standardkomponenten Eine detaillierte Landkarte der am Bau einer Oberfl che beteilig ten Rollen ihrer Beziehungen und Au
73. Benutzeroberflaeche de e Beispiele von User Interface Modellen in der User Inter face Beschreibungssprache Lucia e Eine detaillierte Grammatik von Lucia e Eine Demonstration des Ausleitens von Prototypen aus UI Spezifikationen durch ein Web Service e Eine detaillierte bersicht ber aktuelle Werkzeuge zur UI Entwicklung 1 7 Lesen von UML Diagrammen Weil zur Erkl rung von Zusammenh ngen im Buch viele UML Diagramme verwendet werden folgt eine kurze Einf hrung in UML Klassendiagramme und UML Use Case Diagramme Diese Kurzeinf hrung ist f r die Leser bestimmt die mit der UML Notation nicht vertraut sind F r die UML Kundigen sind in UI Beschreibung wieder verwenden Evolution res Cross Plattform Management Geplante Online Begleitmaterialien zum Buch 22 Einf hrung den Einf hrungs Diagrammen einige Paradigmen der UI orientierten Architektur enthalten UMI Klassendiagramm e Klasse Definiert einen Begriff eines Fachvokabulars durch sei ne eindeutige Klassifizierung z B Benennung einer Klasse Kontrollelement Kontrollelement e Spezialisierung bzw Generalisierung Bringt Klassen in die Beziehung ist ein z B ein Pushbutton ist ein Kontrollelement Kontrollelement Pushbutton Toggle button Dropdownliste Radiobutton Eine detaillierte Anmerkung Ein User Interface enth lt neben Schaltfl Aufz hlung der chen und Auswah
74. Das Erstellen von Benutzerdokumenten erfolgt meist in eigenen Teilprojekten Die Benutzerdokumentation wird dabei auf Basis einer bereits nahe am Endstand funktionsf higen Software er stellt In der Projektpraxis kommt die Dokumentation oft sp ter als die Software in den Test und in den Piloteinsatz Wertvolle Informationen ber eventuelle Br che in der Bedie nungssystematik oder ber die Durchf hrbarkeit der vorgesehe nen Anwendungsf lle kommen damit oft zu sp t um in der Software noch vor dem Ersteinsatztermin korrigiert zu werden W nschenswert w re daher eine Unterst tzung des parallelen Erstellens von Software und Dokumentation Hierzu kann eine automatisierte Auswertung des UI Modells auf Bedienungshin weise hilfreich sein Die so erzeugten Dokumentationsger ste k nnen den Grundstock einer fr hzeitigen Benutzerdokumenta tion bilden Denkbar ist auch dass die aus dem UI Modell stammenden An teile der Benutzerdokumentation als Redaktionsbeitr ge einge bunden und automatisch aktualisiert werden Dokumente f r den Anwender der Software sind in der Regel e Ger st f r das Benutzerhandbuch e Ger st f r interaktive Hilfefunktionen der Anwendung Die Dokumentation insbesondere ihre interaktiven Anteile ist nicht nur rechtlich gesehen Bestandteil der Software Eine Soft wareoberfl che hat neben der Aufgabe Funktionalit ten zu er schlie en auch die Aufgabe den Anwender anzuleiten und sollte dabei unterst t
75. Form e b Das Verwenden ist vorrangig e Die Funktionen ergeben sich aus Verwendungsf llen e Die technische Umsetzung der Funktionen ergibt sich aus der verf gbaren Technologie e Die Oberfl che ergibt sich aus den Verwendungsf llen wird aber von der technischen Umsetzung beschr nkt blich sind heute Modelle der inneren Struktur der Software Modelle der Au enwirkung der Software kommen meist nur in Form von UI Prototypen vor Beispiel f r Ul orientiertes Entwickeln 11 Verwunderlich ist User Interfaces stehen im Mittelpunkt des Interesses der Auftraggeber und der Anwender doch von den Entwicklern werden sie nicht selten wie Schmuck am Nachthemd behandelt Brauchen wir nicht dringend User Interface Modelle und Dialogbaupl ne im Zentrum der Aufmerksamkeit der Soft wareauftraggeber und der Softwarehersteller Wo doch der Erfolg der Anwendung allein von ihrer Verwendbarkeit abh ngt Die Erfahrungen aus Projekten in denen die Oberfl chenentwick lung zu kritischen Verz gerungen gef hrt hat sprechen eindeu tig daf r Dialogbaupl ne sollten zudem mehr als Freihandzeichnungen sein Klar festgelegte Modelle die in Bezug auf die Oberfl che der Software so exakt und eindeutig wie technische Zeichnun gen oder CAD Modelle von Maschinen oder Geb uden sind 1 5 Beispiel f r Ul orientiertes Entwickeln Haben Sie beruflich mit dem Erstellen von Softwareanwendun gen zu tun Das folgende B
76. IO Makros in Assembler auf BS2000 Systemen Sp ter folgten diesem Ansatz fortgeschrittene Formen von Mas kengeneratoren in dBase FoxPro in verschiedenen RDBMS Relational Database Management System wie Oracle oder DB 2 und in anderen integrierten Werkzeugen zur Entwicklung von datenorientierten Gesch ftsanwendungen Grafische Benutzeroberfl chen Softwareoberfl chen ver nderten sich stark mit dem Markteintritt der Computermaus und mit dem Erfolg grafischer Betriebssyste me bzw Betriebssystemaufs tze wie e Mac OS e X Windows e GEM Graphical Environment Manager e GEOS Graphic Environment Operating System e MS Windows Microsofts Antwort auf GEM oder e KDE K Desktop Environment Durch GUIs Graphical User Interfaces wurden Anwendungen zunehmend reaktiv Die wesentliche Neuerung der grafischen Oberfl chen zu bisherigen Dialogbildschirmen ist die ereignis orientierte Arbeitsweise In transaktionsorientierten Dialoganwendungen haben Oberfl chen an bestimmten Stellen im Programmablauf bestimmte Ein gaben des Benutzers gefordert Mit der Einf hrung der Ereignis orientierung wurde diese strikte F hrung des Benutzers gelo ckert Der Benutzer kann die angebotenen Bedienungselemente in beliebiger Reihenfolge verwenden Die Anwendungsoberfl che reagiert auf diese Verwendungsereignisse In gleicher Weise kann die Anwendungsoberfl che auf anwendungsinterne Ereig nisse reagieren Eine kompakte Beschreibung d
77. Leitfaden Die Kapitel der User Interface orientierten Architektur sind nach den Durchf hrungsphasen eines Entwicklungsprojekts gegliedert Jede Projektphase hat einen anderen Schwerpunkt so auch die Kapitel des Buchs das Sie in der Hand halten Die Kapitel bauen nicht zwingend aufeinander auf Ich empfehle Ihnen aber es der Reihe nach zu lesen So erschlie en sich das Gesamtbild und die Zusammenh nge leichter Sp ter k nnen Sie die einzelnen Kapi tel vor allem die Definitionen der Ul Beschreibungssprache als Nachschlagewerk verwenden Die Buchkapitel beleuchten die Phasen eines Softwareprojektes und zeigen auf wie die User Interface orientierte Architektur in jeder Phase konkret hilft Durch die Verkn pfung der Informati onen und durch Wissensmanagement in einer durchg ngigen Informationsstruktur entsteht aber auch ein phasen bergreifen der Nutzen Innerhalb der einzelnen Kapitel werden die vorgestellten The men anhand von Beispielen und Vergleichen aus kommerziellen Softwareprojekten verdeutlicht Am Ende jedes Kapitels finden Sie im Abschnitt Nutzen eine Zusammenfassung der vorgestell ten Inhalte und konkrete Handlungsempfehlungen f r die Praxis Die Kapitel Einf hrung Oberfl che und Werkzeuge geben einen berblick ber das Entwickeln von User Interfaces Die Kapitel Skizzieren Detaillieren Sprache Architektur Funktionsmodellierung Prozesssteuerung und
78. Oberfl che m glichst geradlinig und exakt zu be schreiben Lucia ist eine deskriptive auf Beschreibung interaktiver Oberfl chen ausgerichtete Sprache mit einer Syntax die zum Zweck der Lesbarkeit an umgangssprachliches Englisch angelehnt ist Die Lucia Sprache stellt eine Sammlung von oberfl chentypi schen Objekten bereit welche durch Eigenschaftsattribute be schrieben und miteinander in Beziehung gesetzt werden Die Sprache deckt die Themenbereiche Anforderungsperspekti ve Strukturperspektive Dialogperspektive und Interaktionsper spektive sowie Schnittstellen zu funktionalen Diensten und zur Darstellungsschicht Bild 68 Spezialisten interessieren sich f r unterschiedliche Softwareteile 140 Sprache Bild 69 berblick ber Objekitypen in Lucia UI Modell in LUCIA 0 N Oberfl chen objekte Kontext objekte Bildschirm dialoge Schritte E Sprach dialoge Kontroll elemente Interaktionen Lucia gliedert die Oberfl chenbeschreibung in drei Grundtypen von Objekten Oberfl chenobjekte Logische Bestandteile der Oberfl che z b Ablaufschritte Bildschirme Elementgruppen und einzelne Ein und Ausgabe Elemente mit den daran gekn pften Interaktio nen Kontextobjekte Logische Platzhalter f r die Umwelt der Benutzeroberfl che z B Schnittstellen zum Datenhaushalt und zu den funktionalen Transaktionen der Anwendung z B
79. Oberfl che skizziert HCI Model named Hallo_Welt_Beispiel sagt aus dass unser Spezifikationsmodell den Namen Hal lo_Welt_Beispiel hat Namensdefinitionen werden mit dem Wort named eingeleitet Statt der Anf hrungszeichen die wir oft in Flie texten der Spezifikation ben tigen werden eckige Klam mern als Begrenzer f r Namen und Inhalte verwendet In einer Spezifikation kommen viele Namen und Querverweise vor Deshalb wird zur besseren Unterscheidung eine Namensfest legung mit named name notiert und eine Namensreferenz UI Beschreibungssprache Lucia 143 mit name Die in einer Lucia Spezifikation verwendeten Namen d rfen beliebige Zeichen au er eckigen Klammern Punkt Komma und Anf hrungszeichen also auch Leerzeichen und Umlaute enthalten 1 Wir wollen legt eine Anforderung fest leitet eine Anforderungsbeschreibung ein Eine Anforderung kann muss aber nicht einen sie identifizierenden Namen haben named Anf_2 Das Beispiel soll legt eine Anforde rung mit dem Namen Anf_2 fest Die Beschreibung der Anfor derung folgt in einem ebenfalls mit und begrenzten Block Innerhalb der Anforderungsbeschreibung darf mit name auf andere Anforderungen und auch auf beliebige andere benannte Elemente der Spezifikation quer verwiesen werden Eine Anforderung geh rt zu dem n chsten ber ihr befindlichen Modellelement im Hallo Welt Beispiel beziehen sich die
80. Signal im Normalfall nicht weiter propagiert e OnEnter und Onleave funktionieren wie normale Event Propagation in einem Step e M glichkeit einen Step Exit mit refuse exit abzubrechen e Standortabh ngiges Interpretieren von Sprungzielen f r Step berg nge Datenmodell f r UI Spezifikationen 135 6 4 Datenmodell f r Ul Spezifikationen Der Bedarf und Nutzen eines gemeinsamen Datenmodells f r die bei der UlI Entwicklung entstehenden Informationen ist dass man auf dieser Ebene Informationen austauschen kann Mit dem untenstehend aufgestellten Informationsmodell schlage ich eine Informationsstruktur vor welche dazu geeignet ist den Informationsgehalt einer Oberfl chenspezifikation aufzunehmen Die nachfolgende Abbildung zeigt die grundlegenden Informati onseinheiten einer Benutzeroberfl che und deren Beziehungsge flecht z Bild 65 lt lt root gt gt Specified Jed T Kernentit ten eines eclares e Veena existence of Informationsmodells consist of f r User Interfaces Requirement Description e g Configuration Variants Situations Representation Data References Function References requires Interaction requires Mit der Aufstellung der Kernentit ten kl rt das Informationsmo dell f r Oberfl chenspezifikationen zwei zentrale Fragen e Welches Informationsgeflecht kann die in einer Oberfl
81. System von Klaus Rainer M ller Der IT Security Manager von Heinrich Kersten und Gerhard Klett User Interface orientierte Softwarearchitektur von Paul Chlebek Paul Chlebek User Interface orientierte Softwarearchitektur Bauentwurfslehre f r interaktive Softwareoberfl chen Kompass f r die Entwicklung dialogintensiver Anwendungen Leitfaden f r erlebbare User Interfaces Mit 85 Abbildungen vieweg Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie detaillierte bibliografische Daten sind im Internet ber lt http dnb d nb de gt abrufbar Das in diesem Werk enthaltene Programm Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden Der Autor bernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung bernehmen die auf irgendeine Art aus der Benutzung dieses Programm Materials oder Teilen davon entsteht Die Wiedergabe von Gebrauchsnamen Handelsnamen Warenbezeichnungen usw in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme dass solche Namen im Sinne von Warenzeichen und Markenschutz Gesetzgebung als frei zu betrachten w ren und daher von jedermann benutzt werden d rfen H chste inhaltliche und technische Qualit t unserer Produkte ist unser Ziel Bei der Produktion und Auslieferung unserer B cher woll
82. UI Spezifikationen neeenenennnenenenenn 135 6 5 UI Beschreibungssprache Lucia eeeseensnsennnennennennnnnnennennn nenn 138 6 6 Umfang der Lucia Sprache eneesenesenensenneneneneneneesenesneneoe 146 6 7 tucia Grammatik ua a nn ern ee nee 149 6 8 N lzen Ar O A E E ansehen TNE a 162 Kapitel 7 Architektur rien ee 163 2 Integration in die Entwicklungsumgebung eenenenen 163 7 2 Das MVC Entwurfsmuster eeneennenssennensenseneenenneno 165 7 3 Model Driven Architecture MDA ucesesnnssnnnnnnnnessnnnnnnnnnnnneneennnnn 169 7 4 Ul orientierte Laufzeitkomponenten eseenesennensesnnnnnnennn 170 75 Ausleiten von Prototypen ena 172 Inhaltsverzeichnis XV 7 6 Weitere TransfoOrmationEns asrih tiren oeii a ea SE E EENAA 172 7 7 NUTZEN Ge ee TR ee 172 Kapitel 8 Funktionsmodellierung srsrss0000sssnnesessnnnenne 175 8 1 Abh ngigkeiten zwischen Bedienung und Funktion 176 8 2 Kollaboratives Modellieren ususssssnesseesenesnnennnsnnesne sn esn essen 177 8 3 Oberfl cheneigenschaften mit UML Modellen absichern 179 8 4 Funktions und Datenmodelle ableiten 180 8 5 LELIA a ESEA E E E EAE A A E AEA S 181 Kapitel 9 Prozesssteuerung oosossssseoecososssesesoeosscssesseosocsssssese 185 9 1 Prozesslogik und Situationen anei noitana EEAO 186 9 2 Ablaufsteuerungsdaten extrahieren enneneeeenn
83. a cher Hinsicht zu Die Projektbeteiligten haben unterschiedliche Wissensst nde und bringen unterschiedliche mentale Modelle der Anwendung mit In der Initialisierungsphase des Projekts setzt eine Flut von In formationen in Form von Anforderungen Vorg ngeranwendun gen Konzeptpapieren Restriktionen sowie Erfahrungen der einzelnen Entwickler ein und will zu einem ersten geschlossenen Bild geformt werden 9 Die Projektbeteiligten bringen unterschiedliche mentale Modelle der zu entwickelnden Anwendung mit Oft gehen die Spezialis ten in den ersten Beschreibungen und Prototypen an manchen Stellen sehr ins Detail w hrend ber andere Bereiche der An wendung nur Schlagworte genannt werden Die Herausforderung der ersten Projektphase liegt darin einen Grundriss der Software zu formen der die Breite der Anwen dung vollst ndig wiedergibt zugleich aber die Tiefe der Details begrenzt und nur so weit ber cksichtigt wie es f r ein geschlos senes Bild notwendig ist Bild 34 Projektbeteiligte bringen mentale Modelle der Anwendung mit Anwendungsbreite vor Funktionstiefe beschreiben 84 Skizzieren berdetaillieren vermeiden Logische Schritte identifizieren Schwierig ist dabei das berdetaillieren der besonders interes santen oder wohlbekannten Bereiche der Anwendung zu ver meiden Die Versuchung im Rohbau der Software an einzelnen Stellen schon mal Parkett zu verlegen und einige Quadratmeter woh
84. agieren auf Signale aus der Funktionsschicht Application Values und Functional Requests l sen das Problem der Verbindung der Oberfl che mit dem funktionalen Teil der Anwendung Wenn die Oberfl che Daten der Anwendung abru fen und Funktionen der Anwendung ausl sen kann sowie auf einfache Signale der Anwendung reagiert ist eine ausreichende Schnittstelle zur Kommunikation zwischen Oberfl che und Funk tionalit t gegeben Die Oberfl che kann damit im Kontext der Funktionen und Daten der funktionalen Schicht agieren Kontextabh ngige Pr sentationslogik Eine Benutzeroberfl che hat zur Laufzeit oft den Bedarf sit zungsspezifische Informationen wie z B dass ein Knopf schon einmal gedr ckt wurde oder dass ein Passwort schon zweimal falsch eingegeben wurde auszuwerten Ohne Kontextbezug kann die Anwendungsoberfl che keine Abl ufe abbilden Breite Schnittstelle zwischen UI und der funktionalen Anwendung Von Bedingungen zu Situationen 134 Sprache Wiederverwendbare Situationen State Charts bieten so genannte Guards Bedingungsbewacher an um das Durchf hren von Transitionen an Bedingungen zu kn pfen Falls mehrere Bedingungen ausgewertet werden m s sen k nnen die Guards schnell un bersichtlich werden Zudem kann man nicht auf zentral definierte Guards zur ckgreifen was bei nderungen von globalen Bedingungen das berpr fen und Anpassen aller Guards der betroffenen Transitionen nach sich zieht
85. aktion Trigger k nnen Transitionen bzw Aktivit ten ausl sen Es gibt folgende Trigger e Signal Trigger e Call Trigger e Time Trigger e Change Trigger Mehrere Zust nde d h ihre Transitionen und Aktivit ten in ab getrennten Tafelteilen k nnen gleichzeitig ausgef hrt werden Orthogonale Zust nde beziehen sich in der Regel auf unter schiedliche Objekte Die State Charts Notation 127 Bild 62 Orthogonale Zust nde oz UZ1 UZ2 Mit der flachen und der tiefen Historie k nnen Unterzust nde gemerkt werden Dadurch kann z B festgelegt werden dass beim erneuten Betreten eines bergeordneten Zustands der zu vor aktive Unterzustand eingestellt wird F Bild 63 Flache und E tiefe Historie za za2 A z3 234 y 22 Die untenstehende Grafik zeigt ein Beispiel f r eine State Chart Bild 64 State Chart f r einen Schalter Ein Aus aus ein a Stromversorgung a Stecker raus Pen rein Netz u Ger Seker rein Akku raus ber Sicherung Neue Sicherun spannung ralszienen eingesetzt Sicherung Sicherung durchgebrannt Sicherung fehlt gt Er Das Diagramm verdeutlicht die Zustands berg nge beim Ein bzw Ausschalten eines elektrischen Ger ts z B eines Laptops 128 Sprache Kanonische Sequenzen Sequenz und Service Schritte Das Ger t hat eine berspa
86. alogelementen auf die unser Beispiel jedoch nicht eingeht Das Beispiel zeigt nur eine kleine Auswahl der Sprachkonstrukte der Oberfl chenspezifikationssprache Lucia Es sollte Ihnen jedoch in Form eines vertikalen Durchstichs ei nen Eindruck von den unterschiedlichen Themen Sichten Per spektiven Bestandteilen die in einer Spezifikation beschrieben und in Bezug zueinander gesetzt werden m ssen verschafft haben 6 6 Umfang der Lucia Sprache bersicht der Ausdrucksm glichkeiten f r UI Sachverhalte der Lucia Sprache Die Schl sselworte der Sprache repr sentieren wichtigste Elemente der Oberfl che bzw ihrer Beschreibung Umfang der Lucia Sprache 147 Anforderungsperspektive Anforderung REQUIREMENT Anforderungen identifizieren Anforderung beschreiben Bezug zu anderen Modellelementen herstellen Querverweise Strukturperspektive Ablaufschritt STEP Aneinanderreihung Schachtelung Stepeigenschaften z B Modalit t Schritte fallabh ngig durchf hren Schritte parallel durchf hren Hierarchische Vererbung Vererbung aus Musterschritten Dialogperspektive Dialog SCREEN DIALOG Bezug zum logischen Schritt Bezug zu einer Layoutvorschrift Widgetgruppe Platzierung Darstellungsbezug Rendering Widget Platzierung Darstellungsbezug Rendering Kontrollelement Datenbezug Eingabeschablonen Sichtbarkeit Modus z
87. alogseiten und den Kontext Ablaufnetz UI Logik die den Ablauf der Anwendung oberhalb der Kontroll elemente und einzelner Dialogseiten steuert e Hierarchie der logischen Schritte der Anwendung e Klassifizierung der logischen Schritte in Sequenzschritte und Services Popups Notifikationen e Interaktionen beim Betreten und Verlassen der logischen Schritte e Sequentielle und nichtsequentielle berg nge zwischen logischen Schritten e Ablaufkontrolle und Navigationsinstrumente Dialogseiten UI Logik die innerhalb einer Dialogeinheit stattfindet 56 Oberfl che e Dialogschnittstelle f r einen logischen Schritt e Anordnung der Kontrollelemente auf dem Bildschirm e Interaktionen f r die Kontrollelemente Kontext UI Logik die den Zusammenhang zwischen dem Zustand der Oberfl che und dem Zustand der funktionalen Anwendung her stellt e Verwendung von Daten e Verwendung von Funktionen e Prozesslogik e Statusermittlung durch Situationsindikatoren e Verwendung von Widgets e Verwendung von Layouts e Verwendung von Datenmustern e Bezugnahme auf Anforderungen 2 8 Nutzen Die Erforschung der Bestandteile und Zusammenh nge hat ein differenziertes Bild der Oberfl che geliefert Eine Softwareober fl che ist demzufolge keine lose Ansammlung von beliebigen Bedienungselementen sondern ein strukturiertes Gebilde mit einer klaren Gliederung Diese Gliederung erm glicht e Vollst ndigkeitsbewertung vo
88. alte der Iterationen erm glichen das Errei chen und Behalten des gleichen Detaillierungsgrads in der ge samten Anwendungsbeschreibung Beim Skizzieren der Funktionen und der Oberfl che wird in der Breite modelliert das heift flach aber mit dem Ziel einer voll st ndigen bersicht Beim Detaillieren der UI Beschreibung erfolgt stufenweise der bergang von der Breitenmodellierung zur Modellierung in der Tiefe Das hei t Aus dem groben Modell werden die Detailei genschaften weitergeformt Die in diesem Kapitel vorgestellten Hilfsmittel sind in der Entwurfsphase und bei der Vorbereitung der Implementierung Elaboration Construction von Nutzen User Interface spezifizieren Vom Modellieren in der Breite zum Modellieren in der Tiefe 18 Einf hrung Eindeutige UI Modelle erstellen UT Beschreibung wie Quellcode verwenden UI in der Architektur verankern Kapitel 6 Sprache in dem enth llt wird wie und womit man ein User Interface eindeutig beschreiben kann In diesem Kapitel stelle ich eine detaillierte Informationsstruktur und eine Sprache f r den Bau von Benutzeroberfl chen auf Diese Struktur erm glicht die geordnete und zusammenh ngen de Verwaltung aller Informationen die in die Implementierung der Oberfl che einflie en Zum F llen dieser Datenstruktur wird die UI Beschreibungssprache Lucia bereitgestellt Die Formulie rungsm glichkeiten dieser Sprache werden vorgestellt und an han
89. altung 90 Skizzieren Weg zum Ergebnis der Anwendung im Vordergrund Bild 36 IDEFO Activity Box Bild 37 Aktivit ten verkelten spr nglich unter anderem von der NASA zur Beschreibung von Prozessen verwendet Feldmann 1998 UML Aktivit tsdiagramme haben eine den IDEFO Diagrammen hnliche Semantik In der Ul orientierten Architektur verwende ich eine von mir auf Aktivit tsdiagramme adaptierte Form von IDEFO Diagrammen Das Diagramm in der obigen Abbildung ist ein UML Aktivit tsdiagramm dessen Aufbau und Semantik an einem IDEFO Diagramm orientiert ist Ein IDEFO Diagramm ist eine Prozessvorschrift bei der nicht der Ablauf sondern der Zusammenhang zwischen den Vorausset zungen und Ergebnissen von T tigkeiten und den f r die T tig keiten ben tigten Mitteln und Regeln im Vordergrund steht Die im Buch ber Ul orientierte Softwarearchitektur verwendeten IDEFO hnlichen Diagramme bedienen sich der Semantik von Aktivit tsdiagrammen mit einigen an IDEFO angelehnten Speziali sierungen der berg nge zwischen Aktionszust nden Die nachfolgende bersicht zeigt wie IDEFO Diagramme in der Ul orientierten Softwarearchitektur auf UML Aktivit tsdiagramme abgebildet werden Regeln Eingandsdaten Aktivit t Verb Phrase Ergebnis gang z B Artikel w hlen Rolle Werkzeug Die Activity Box steht f r eine Aktivit t des Anwenders Die Ak tivit t wird durch eine Verb Phrase also durch ein Sachwort und e
90. and exit Step Situation Login Parameter Eingegeben not Login Id empty and not Login Password empty Screen Login in Progress on Signal if login done end step Text progress message value Login Objekt message text Progressbar value Login Objekt progress percentage screen login error Display error message value Login Objekt message text Button ok on command exit Step Situation Eingeloggt ApplicationValue LoginConfirmed ok Application Interface Login Objekt method doLogin id password use Login Eingabe Login Id Login Eingabe Login Password string id string password string message text string progress percentage picture message picture Aus dem Application Interface und aus der globalen Situation Eingeloggt l sst sich 1 1 eine Klassenbeschreibung formen 8 3 Oberfl cheneigenschaften mit UML Modellen absichern Die Anforderungen an die Bedienung k nnen mit Klassenmodel len Aktivit ts und Sequenzdiagrammen auf Machbarkeit und Plausibilit t berpr ft werden Die in einem UML Klassenmodell beschriebenen Strukturen und Beziehungen beinhalten implizite Regeln f r den Zugriff auf Lokaler Kontext Kontextperspektive 180 Funktionsmodellierung Bild 78 Klassenger st f r die Kundenverwaltung Objektinstanzen z B wie man die Bestellungen eines bestimm ten Kunden im Zeitraum X findet Die Objektstruktur legt damit der Anwendungsoberfl c
91. as Bewerten von Notationen in Blackwell 2003 angelehnt Das Schema wurde von mir an die Bewertung von UI Entwicklungswerkzeugen angepasst erweitert und mit einem Punktesystem versehen Bewertungskriterien f r eine Ul Entwicklungsumgebung sind e Vollst ndigkeit Abdeckungsgrad der UI Dom ne e Fachlichkeit N he der Repr sentation zur Ul Dom ne e Sichtbarkeit Kapselungsgrad von Informationen e Geringe Vorabverpflichtung Grad der Provisionalit t Vorl ufigkeit der Definitionen e Klarheit Umfang Erkennbarkeit und Lesbarkeit der Konstrukte e Geringe Z higkeit Widerstand gegen nderung der UI Beschreibung Vollst ndigkeit Fachlichkeit Sichtbarkeit Geringe Vorab verpflichtung Klarheit Geringe Z higkeit F r jedes der nachstehend beschriebenen Bewertungskriterien k nnen 1 bis 10 Punkte vergeben werden Die Gesamtzahl der Punkte ist eine Ma zahl f r die G te einer UIEU Bild 27 Bewertungskriterien f r eine UI Entwicklungsumge bung 66 Werkzeuge Vollst ndigkeit Abdeckungsgrad des Ein Informations bzw Datenmodell f r das Entwickeln von User UI Datenmodells N he zur Fachsprache der Anwender Interfaces stellt den Rahmen f r das Wissensmanagement von Informationen und Beziehungen die zum Bau eines UI dienen Die Notation zur UI Modellierung erm glicht es dieses Daten modell mit Inhalten zu bef llen Je h her der Abdeckungsgrad des UI Datenmodells desto
92. ases des UI Modellierens 121 e Ein Informationsmodell ist eine Datenstruktur in der die in der Sprache formulierten Informationen f r eine weitere Verarbeitung z B durch Auswertungsmechanis men und Transformatoren abgelegt werden k nnen Die Idee einer Spezifikationssprache und einer Datenstruktur f r das Ordnen der UI bezogenen Informationen adressiert vor allem die Probleme derer die User Interfaces spezifizieren Spezifizie rer und derer die diese Spezifikationen interpretieren m ssen Programmierer Kommuni kation Interface SA Modell Ein Sprachmodell f r User Interfaces erm glicht die Weiterent wicklung der UI Modellierung von einem Beschreibungs und Kommunikationshilfsmittel f r UI Anforderungen zu einer UI Entwicklungswerkbank im Sinne der modellgetriebenen Archi tektur MDA 6 1 Use Cases des Ul Modellierens Um das Informationsgeflecht eines UI zu spezifizieren werden Modellierungselemente ben tigt die Ausdrucksm glichkeiten zum Beschreiben der UI Bestandteile und ihrer gegenseitigen Beziehungen bereitstellen Anwendungsf lle oder Use Cases der Ul Entwicklung sind T tigkeiten die bei Entwurf Design Realisierung und Inbetrieb nahme einer Benutzeroberfl che anfallen Die Aufteilung der Anwendungsf lle beim Entwickeln eines UI entspricht der thematischen Aufteilung einer UI Beschreibung in UI Perspektiven Weitere Informationen zur MDA finden Sie z B auf den Se
93. asst wird Damit wird auch die psychologische L cke zwischen Oberfl che und Funktionalit t geschlossen Die Oberfl che ist kein Aufsatz auf die Funktionalit t sondern die Schnittstelle zu ihrer Nutzung Benutzerschnittstelle und Funktionalit t k nnen optimal nur in einem gemeinsamen von der Architektur getragenen Kontext entwickelt werden Kapitel 8 Funktionsmodellierung in dem UI Modelle und UML zusammen angewandt werden sich erg nzen und gemeinsam wirken Kapitelziele e Kooperative Modellierung von Benutzeroberfl chen und von funktionalen Anwendungsschichten e Mapping von Oberfl cheneigenschaften auf Eigenschaften der funktionalen Anwendung z B auf Modellebene Wel che Funktionen werden in der Oberfl che vorausgesetzt und welche werden von der Anwendung bereitgestellt e bernahme der UI Beschreibung als Ger st f r funktionale Modelle z B Klassenliste oder Data Dictionary Der Begriff Funktionsmodellierung bezeichnet im Folgenden das Modellieren von internen Abl ufen und Strukturen der funk tionalen Anwendung Damit ist auch die Modellierung von Daten bzw Objekten gemeint Die funktionale Anwendung ist der Teil der Software der unter der Oberfl che liegt In betriebswirt schaftlichen Anwendungen wird diese Schicht der Software oft als Gesch ftslogik oder Fachfunktionalit t bezeichnet In tech nisch orientierten Anwendungen wird die funktionale Anwen dung meist als Systemlogik bezeichnet
94. azu zun chst als CGI Common Gateway Interface Bei CGI wurde sozusagen die Ereignisverarbeitungsschleife eines Fat Clients als Serverprogramm nachempfunden Danach folgten viele weitere M glichkeiten f r interaktive Web Anwendungen z B Applets Servlets oder Java Server Pages JSP Der gro e Unterschied zwischen einer auf HTML und Web Browser basierten und einer vom Fat Client gewohnten Anwen dungsoberfl che ist dass nach dem HTTP Konzept die Grenze zwischen Transaktionen und Pr sentation hart weil physisch ist Die im Fat Client blichen Intensivkopplungen zwischen ein zelnen Controls und den feink rnigen Transaktionen sind bei einem Thin Client teuer weil f r jeden Kopplungszyklus eine Servertransaktion mit Daten bertragung notwendig ist Thin Web Clients haben hnlichkeiten mit dialog transaktionalen Oberfl chen in der man den Zentralrechner hinter der Bild schirmmaske sp ren kann F r Anwender die sich an die belie big interaktive Fat Client Welt gew hnt hatten in der man das Gef hl haben konnte dass man die Anwendung mit allen Daten zur alleinigen Nutzung auf seinem Rechner hat kann sich das wie ein R ckschritt anf hlen Nat rlich schr nken Thin Clients die unbegrenzten Kopplungs m glichkeiten zwischen Teiltransaktionen und Controls der Fat Clients ein Und nat rlich m chten die Anwender nicht einge schr nkt werden Das Web hat die Grenze zwischen der Pr sentationsschicht und der Transaktions
95. bar willk rlich ber die Technik Entwickler m gen das nicht In der Vorstellung der Entwickler UI Modelle zeigen Zielkonflikte auf Wechselnde UI Anforderungen verunsichern die Entwickler 212 Projektmanagement Vermeiden des Ausgrenzens Bild 89 Funktions und Daten Entwickler grenzen das User Interface gerne aus Framework wird ohne Standard UI entwickelt beschneidet es ihren Gestaltungsspielraum und gef hrdet die Ergebnisse ihrer Arbeit Oberfl chen so argumentieren Entwickler oft kann man ei gentlich erst entwickeln wenn die Funktionsanalyse abgeschlos sen ist sonst m ssen sie st ndig ge ndert werden Zu dieser Argumentation geh rt auch die weit verbreitete Vorstellung dass Oberfl chen nur ein Aufsatz auf die wesentlich komplexere Funktionalit t sind Um den S ndenbock wie den Ausgrenzungseffekt zu vermei den m ssen im Projekt klare Schnittstellen und Synchronisati onspunkte zwischen dem sich schnell ndernden UI Modell und den weniger agilen Artefakten wie Datenmodellen Klassen und Programmcode festgelegt werden Ebenso muss die Mitwirkung der verschiedenen Rollen am Ver vollst ndigen des User Interface Modells und am Verwerten der Informationen aus dem UI Modell klar geregelt sein und konti nuierlich durchgesetzt werden Wird die Oberfl che nicht fest im Projekt verankert und ins Vor gehen integriert dann wird sie unter Umst nden ausgegrenzt und die Realisierung der Soft
96. beliebig ohne In formationsverlust ver ndert und Notationselemente k n nen schnell umgeformt werden z B aus einem Pushbut ton eine Checkbox machen Gesamtbewertung Die Gesamtbewertung kann durch die Summe der in den einzel nen Bewertungskriterien vergebenen Punkte ausgedr ckt wer den Die maximale Punktzahl betr gt 60 Punkte Ein mit 60 Punkten bewertetes Werkzeug w re nach diesem Bewertungsschema optimal zur UI Entwicklung geeignet Das folgende Beispiel zeigt eine Gesamtbewertung im Vergleich zwischen C mit MFC und Flash MX Die Einzelbewertungen sind subjektive Sch tzwerte Punkte Bewertungskriterien C mit MFC Flash MX Vollst ndigkeit 10 6 Fachlichkeit 2 4 Sichtbarkeit 2 6 Freiheit von 4 6 Vorabverpflichtung Klarheit 4 Geringe Z higkeit 4 on 26 32 Die im Beispiel mit 26 und 32 Punkten bewerteten Werkzeuge liegen bez glich ihrer Eignungseinsch tzung im Mittelfeld Auf eine detaillierte Bewertung von einzelnen Werkzeugen wird im Rahmen des Buchs bewusst verzichtet da solche Bewertun gen stark vom Kontext des durchzuf hrenden Projektes und der Aufgabenstellung der zu erstellenden Software abh ngen Eine allgemeing ltige Bewertung eines Werkzeugs ohne das Projekt umfeld im Detail zu ber cksichtigen erscheint mir wenig plausi bel und kann sogar irref hrend sein Ich empfehle Ihnen daher die f r Ihr Projekt in Frage kommenden Werkzeuge fallbezogen und subje
97. ber das gesamte Mo dell d h auch aus allen UI Perspektiven gleichm ig auf einen bestimmten Stand zu bringen Man erh lt so einen stabilen Ausgangsstand f r den n chsten Iterationsschritt und kann kontinuierlich den Fertigstellungsgrad den Arbeitsfortschritt und die Qualit t des UI Modells messen Durch den Abschluss einer UI Entwicklungsiteration wird der Meilenstein erreicht an dem das UI Modell den f r diese Iterati on aufgestellten Kriterien gen gen soll Wichtige Kriterien f r einen Iterationsabschluss sind e Definierte Umf nge sind erreicht e Definierte Ausgangskriterien wurden erf llt e Definierte Eingangsbedingungen f r die n chste Iteration liegen vor und k nnen erf llt werden 114 Detaillieren e Vorliegen von geforderten Modellteilen e Vorliegen von Verkn pfungen zwischen Modellelementen e Gleichm ige Modellierungstiefe Typische T tigkeiten am Ende einer Iteration sind e Angeben aller geforderten Attribute pro Kontrollelement e Angeben aller geforderten Attribute f r jeden logischen Schritt e Eintragen des Fertigstellungsgrads in die Modellelemente e Absichern der Ergebnisse durch Begutachtung und Best tigung seitens der Vertreter des Auftraggebers einschlief s lich Anwendervertreter Wie viele UI Iterationen in einem konkreten Projekt stattfinden und wie sie im Detail voneinander abgegrenzt werden h ngt von der Projektgr e vom Vorgehensmodell des Herstellers vom Vorgehe
98. berblick ber den heutigen Stand der User Interface Entwicklung ber den Begriff der UI Orientierung sowie ber die typischen Fragestellungen und L sungsans tze f r die Herausforderungen bei der Entwick lung dialogintensiver Anwendungen gegeben Mit dem Wissen aus dem Einf hrungskapitel verf gen Sie ber einen Leitfaden zu den einzelnen Themen der UI Architektur und k nnen den Nutzen der UI Orientierung f r Ihre Software projekte berschlagen Aber wie funktioniert eigentlich eine Softwareoberfl che und wie h ngt das alles was auf dem Bildschirm zu sehen ist und das was die Anwendung macht zusammen Ist in Anbetracht der Vielfalt verschiedener Oberfl chentypen und anwendungsspezifi scher Eigenarten eine strukturierte und exakte Form der Be schreibung von Softwareoberfl chen m glich Um die Antworten auf diese Fragen geht es im n chsten Kapitel Kapitel 2 Oberfl che in dem die Struktur und die Bestandteile einer Benutzerober fl che unter die Lupe genommen werden und eine allgemeine Gliederung f r User Interfaces aufgestellt wird Kapitelziele e Wissen was eine Soflwareoberfl che ist e Wissen woraus eine Softwareoberfl che besteht e Gliederung der Bestandteile einer Oberfl che Umgangssprachlich werden die vom Anwender wahrnehmbaren Teile der Softwareanwendung mit vielen synonymen Bezeich nungen bedacht blich sind Bezeichnungen wie Benutzer schnittstelle Bedieneroberfl che Anwendungso
99. berfl che Soft wareoberfl che Dialogmasken oder Dialogschnittstelle In Spezi alistenkreisen werden weiter differenzierte Fachbezeichnungen verwendet Pr sentationsschicht UI User Interface GUI Graphical User Interface Human Computer Interface HCD oder Mensch Maschine Schnittstelle MMS In diesem Kapitel machen wir das was Ingenieure am liebsten tun Wir nehmen uns einen Schraubenzieher schrauben den Deckel ab und gucken gr ndlich und tief in die Zahnr der eines User Interfaces hinein Eine Softwareoberfl che ist kein Monolith und auch keine Ver packung um die Softwarefunktionen sondern eine Maschine mit verschiedenen Teilen die gemeinsam eine komplexe Vermitt lungsaufgabe erf llen Eine Softwareoberfl che ist eine komplexe Maschine die zwischen Anwender und Softwarefunktionen vermittelt Bild 14 Eine Softwareoberfl che besteht aus verschiedenen Teilen 28 Oberfl che UI Perspektiven blich ist bei heutigen Oberfl chen auch dass sie den Anwen der anleiten Dazu geh ren entsprechender Aufbau der Dialoge selbst aber auch kontextsensitive Hilfefunktionen und On Screen Hilfe Benutzerdokumentation kann aus diesem Blick winkel als Teil der Softwareoberfl che gesehen werden Dieses Kapitel zeigt welche verschiedenen Bestandteile eine Oberfl che hat und wie diese gegliedert werden k nnen Die Bestandaufnahme liefert einen berblick ber Zusammenh nge und Unterschiede zwischen den ver
100. bezug und die Reaktionsbedingungen sehr kom plex werden k nnen Ausger stet mit der Definition von Kontrollelement Verhalten und Interaktion k nnen wir zur weiteren Untersuchung der Be standteile der Softwareoberfl che schreiten In einem User Interface lassen sich leicht zwei voneinander ver schiedene Sorten von Bestandteilen identifizieren e Fin und Ausgabeelemente Das sind die vom Anwender wahrnehmbaren Informationstr ger e User Interface Logik Das sind die logischen Konstrukte die das Zusammenspiel der Ein und Ausgabeelemente organisieren 52 Oberfl che 2 6 Kontrollelemente Unter Kontrollelementen werden im Folgenden sowohl Eingabe als auch Ausgabeelemente verstanden Kontrollelemente versetzen den Anwender in die Lage die Er gebnisse der Anwendungsoperationen wahrzunehmen und sei nerseits Aktionen in der Anwendungsoberfl che anzusto en und die hierf r notwendigen Informationen Eingabedaten ein zugeben Widgets sind eine Weiterentwicklung von Kontrollelementen Ein Widget entspricht der Zusammenfassung von Layout und Verhaltensinformationen in einem Objekt Das Aussehen eines Widgets wie eines Kontrollements h ngt oft von seinem Zustand ab Der Zustand wird zur Laufzeit durch Auswertung von Funktionsergebnissen und Statusinformationen abgefragt Zum Beispiel wird eine Schaltfl che oft grau darge stellt wenn die durch die Schaltfl che aktivierbare Funktionalit t zu diesem Zeitpunkt nic
101. biegen sich nicht unter der Last ihres Inhalts durch und Dialogseiten k nnen einem nicht auf den Fu fallen Wenn Software solche mechanischen Eigenschaften h tte k nn ten diese durchaus Aha Erlebnisse bei Anwendern und Entwick lern ausl sen Das Zugangstor zum Wahrnehmen Ausl sen und zum Definie ren der Softwarefunktionen ist jedoch allein die Art und Weise in der man Software verwendet ihre Benutzerschnittstelle in Computerenglisch User Interface abgek rzt UI Menschen bauen immer komplexere und gr fsere Werkzeuge Ausschlaggebend Verstehen wie das zu bauende Werk verwendet wird Software ist eine Maschine die man nur ber ihre Benutzeroberfl che anfassen kann Verwenden ist der Schl ssel zum Verstehen Vorwort Das Buch ber User Interface orientierte Architektur Bauentwurfslehre Fokus auf kommerzielle Anwendungen Da das User Interface eine Schl sselrolle spielt ist demnach eine User Interface orientierte Softwarearchitektur n tig um die Softwareoberfl che im Entwicklungsvorgehen und in der Konstruktionsweise der Software st rker zu fokussieren als es die heutigen Architekturen tun User Interface orientierte Softwarearchitektur zeigt wie man Softwareanwendungen f r Menschen baut indem man das Ver wenden der Software in den Mittelpunkt der Abstimmung zwi schen Auftraggeber und Entwicklern stellt Die Verwendung findet ber die Oberfl che statt f r den Anwe
102. ce sieht In allen Stadien der Modellierung k nnen grundlegende nde rungen an Navigation Ablauf Dialogseitenaufbau und Verhalten notwendig werden Das GUI Werkzeug und die Modellierungsmethode m ssen die ser Notwendigkeit durch nderungstolerante Modelle gerecht werden Andererseits ist es auch unabdingbar dass der Modellie rungsstand t glich m glichst stabil in sich konsistent und ver l sslich ist und nicht alles im st ndigen Fluss ist Ansonsten wird das UI Modell zu einer unberechenbaren amorphen Masse 5 1 Perspektiven des Ul Entwickelns Das Modellieren einer Softwareoberfl che ist ein iterativer evolu tion rer Vorgang bei dem die Oberfl che aus unterschiedlichen Sichten heraus analysiert und definiert wird Eine Softwareoberfl che wird beim Schreiben wie beim Lesen der Oberfl chenspezifikation aus verschiedenen Perspektiven betrachtet Diese Perspektiven sind Sichten auf e die Reihenfolge und Hierarchie der logischen Schritte e die Inhalte eines einzelnen Bildschirms e die berg nge zwischen Bildschirmen und Dialogelemen ten e die Schnittstellen zu Funktionen und zu Daten der An wendung e und auf Zusammenh nge zwischen spezifizierten Oberfl cheneigenschaften und den zugrunde liegenden Anforde rungen Perspektiven des UI Entwickelns 107 UI Perspektiven entsprechen verschiedenen Brillen die man beim Schreiben und Lesen einer User Interface Spezifikation aufsetzt um die Oberfl
103. che Das folgende Diagramm zeigt einen berblick ber die Kennzei chen f r logische Schritte Logischer Schritt Weitere Kennzeichen Parallel ausf hren Schablone Optional Auswahl Die Eigenschaft Ausf hrungsmodus kennzeichnet wie sich der Schritt im Kontrollfluss der Anwendung verh lt Die beiden Auspr gungen des Ausf hrungsmodus sind Sequence Step und Service Step Die Defaultauspr gung von Ausf hrungsmodus ist Sequence Step Falls Ausf hrungsmodus Service Step angegeben wurde wird der Schritt als Dienst ausgef hrt und sein Standardnachfolger ist der aufrufende Schritt Das hei t Der laufende Arbeitsschritt wird unterbrochen um einen Dienst auszuf hren z B eine wichtige Meldung in einem Popup Dialog zu lesen und best ti Logische Schritte modellieren 97 gen Anschlie end wird der unterbrochene Arbeitsschritt in der Regel fortgesetzt Wurde Ausf hrungsmodus Sequence Step oder kein Ausf h rungsmodus angegeben dann wird der Schritt als Sequenzbau stein ausgef hrt Sein Standardnachfolger ist dann der n chste Schritt der gleichen Gliederungsstufe Damit bilden alle Ge schwister Knoten sibling nodes im Gliederungsbaum eine Se quenz in Definitionsreihenfolge Das hei t Nacheinander auf der gleichen Gliederungsstufe definierte Schritte werden als eine logische Abfolge betrachtet Der Unterschied zwischen Service Step und Seq
104. che in ihren Zusammenh ngen und Ein zelheiten zu verstehen bzw verst ndlich zu machen Verschiedene Sichten auf das User Interface T Struktur gt Die gerade ben tigte Perspektive wechselt oft Sie wird vom erreichten Fertigstellungsgrad der Spezifikation und vom inhaltli chen Interesse des Schreibers bzw Lesers bestimmt Die ver schiedenen Perspektiven werden in der Regel durch unterschied liche Rollen der Projektbeteiligten wahrgenommen Anforderungen Die Strukturperspektive definiert die inhaltliche Breite der Softwareoberfl che Mit dieser Sicht beginnt blicherweise die Arbeit an einer Spezifikation indem eine inhaltliche Gliederung des User Interface aufgenommen wird Die Anforderungsperspektive legt den Zielbezug der Soft wareoberfl che fest Sie stellt den Bezug zu Use Cases zur Fea tureplanung zu funktionalen und nichtfunktionalen Anforderun gen und zur Abgrenzung des Anwendungsumfangs her Mit die ser Sicht werden zuerst die Struktur und dann die weiteren Perspektiven qualifiziert bewertet und validiert best tigt Die Dialogperspektive definiert die inhaltliche Tiefe der Soft wareoberfl che Es ist die Sicht auf eine abgegrenzte Dialogein heit z B eine Dialogseite oder ein Sprachmen Diese Sicht sollte man nach hinreichender Abgrenzung der Struktur ausfor mulieren Die Ressourcenperspektive deklariert die von anderen Sichten verwendeten Kontextbausteine der Softwareobe
105. chlechte Softwareanwendungen und damit gute und schlechte Benutzeroberfl chen Ende der 60er Jahre hat die so genannte Softwarekrise die Entwicklung von ingenieurm igen Metho den und Vorgehensmodellen f r den Softwarebau eingeleitet Die Softwareindustrie begann analog zur Bau und Automobil industrie Software systematisch zu planen und zu entwickeln Die so begonnene kontinuierliche Auseinandersetzung mit den Schw chen der Methoden und Werkzeuge der Softwareentwick lung hat zu einer Vielzahl n tzlicher Hilfsmittel gef hrt z B e SADT Structured Analysis and Design Technique e IDEF Integrated Computer Aided Manufacturing Defini tion Languages e ERM Entity Relationship Model e OOD Object Oriented Design e UML Unified Modelling Language oder e XML Extensible Markup Language Die Verbreitung und die fortschreitende Standardisierung dieser Hilfsmittel und Methoden helfen Kommunikationsbr che in Prozessen der Softwareentwicklung zu vermeiden und zu schlie en Benutzeroberfl chen sind bis heute nur nachrangig XForms XUL UIML in diese Methodenentwicklung eingeschlossen Von Stapelverarbeitung zu Dialogtransaktionen In der Batchwelt der fr hen EDV kamen bis in die sp ten 50er Jahre Anwendungsoberfl chen mit interaktiven Dialogseiten gar nicht vor Prozedurale Anwendungen erledigten die Verarbeitung von gestapelten Fingabedaten ohne Anwenderinteraktion und lieferten die Ergebnisse meist in Form v
106. chsel Gro ro Ereignis p Dialogseiten ro Situation Navigations wechsel skript analysieren erzeugen Skriptgenerator Parser ptg Navigation beim UI Test 205 Das Testskript kann z B pro Eingabefeld automatisiert Werte innerhalb und au erhalb des g ltigen Wertebereichs eingeben und die erwartete Reaktion berpr fen z B eine Fehlermeldung nach einem falschen Eingabewert e Das Eingabewerteskript testet Wertebereiche und beson dere Eingabewerte e Das Kontrollelementeskript testet Signale an Kontrollele mente e Das Navigationsskript testet die berg nge zwischen den Dialogseiten 11 3 Navigation beim Ul Test Dem Testskript muss bekannt sein wie man im UI zur betreffen den Dialogseite und zu dem zu testenden Eingabefeld navigiert Deshalb muss das Testskript mindestens ein Eingabeger t das zum Bedienen der Oberfl che verwendet wird kennen und es muss dieses Ger t simulieren k nnen Das Testskript sendet Eingabezeichen zum Beispiel Tastendr cke und Zeigeger tbewegungen an das Eingabeger t um zu den zu testenden Dialogseiten und Fingabefeldern zu gelangen Das Simulieren der Navigation ist gegen ber dem eigentlichen Test von Eingaben und Reaktionen der komplexere Teil des Testskripts Es empfiehlt sich hierf r einen allgemeinen Testse quenzer zu erstellen oder den Sequenzer eines Testtools z B MQC Mercury Quality Center zu verwenden und abstrahierte Navi
107. d 31 Guide State Editor Me ba memts vemi Lepap Yee Mipi Dos Ome Mape Bas xao aa 7na o a ALL Eal Daaa ero ALTE 2 7 un DIE mman n aa l mmence IM as rennen sn aan SCI Bam a c Aa uu o0 m mm 58 BOSSE OR Van aa LRI Je ouseeee lt ee I Die Trennung zwischen Oberfl che und Applikation erfolgt durch den Datenpool und ber Events Dies erlaubt eine User Interface Spezifikation unabh ngig von den funktionalen Appli kationen e Der Datenpool enth lt alle f r das HMI relevanten Werte e Er kann zu Simulationszwecken mit Testwerten beschrie ben werden Werkzeuge f r eingebettete Systeme 77 IAV Teledrive HMI Studio Teledrive HMI Human Machine Interface Studio ist ein Werk zeug zur Entwicklung von Oberfl chen f r Infotainmentsysteme Das UI wird in einer IDE anhand von einem Strukturbaum mit tels verschiedener Property Editoren entwickelt Das Werkzeug unterst tzt die Verhaltensmodellierung von Wid gets das Simulieren des UI mit einem externen Simulator sowie die Verwendung einer XML basierten Modellierungssprache als Modelltr ger Einsatzziele und Zielgruppe e Werkzeugkette f r den gesamten Entwicklungsprozess e Durchg ngige Entwicklung in einem Vorgehensmodell und mit einer Werkzeugkette e Einheitliches Datenaustauschformat f r alle Beteiligten dadurch keine Medienbr che mehr e Fr hzeitige Verf gbarkeit von Simulationen f r entwick lungsbe
108. d dann die Funktion aufgerufen werden Der Hinweis soll solange auf dem Bildschirm stehen solange die Funktion durchgef hrt wird In Abh ngigkeit vom Ergebnis der Funktion soll der Anwender zum Einlegen der sim Card aufgefordert zum Eingeben der Pin aufgefordert oder zum Telefonmenu weitergeleitet werden on signal I nach dem checken der simcard ergebnisabh ngig verfahren when abfragen ob sim card checken funktion response simcard needs pin nextstep sim card checken pin eingeben I on leave apply abfragen ob sim card checken funktion response simcard ready to use heisst pin wurde bereits eingegeben display simcard wird gecheckt display gleich gehts weiter display noch mehr functionality sim card checken funktion application value beispiel response beispiel2 Beispiel Wertebereiche und Auswahllisten Festlegen von Wertebereich Mustern z B f r ein Eingabefeld zur Wertebereiche Betragsangabe festlegen pattern named betrag values 0 10 1000 1500 2000 2010 2500 3500 format z zz9 99 pattern named blz values 0 9999999 format 999b999b99 Die Angabe values legt den g ltigen Wertebereich f r einen Ein gabewert z B eine Zahl oder einen Schl ssel fest Die Formatangabe format legt z B die Anzeigeaufbereitung von Zahlen fest Der Format Ausdruck ist an die Notation der Cobol Picture Klausel angelehnt 9 steht f r eine Dezimalziffer
109. d ihre Inhalte strukturell in der Anwendung zusammen Gliederung der T tigkeiten Zuordnung von Dialogmasken zu Ablaufschritten T tigkeitsauswahl Wiederholung und Unterbrechungen Datenorganisation 36 Oberfl che Anzeige und Bedienung Anforderungen Darstellung Bedienungssystematik Anzeige Bedien und Navi gationsregeln e Wie wird eine konsistente Darstellung der Anwendungs inhalte erreicht e Wie wird der Anwender durch den Prozess und die Ar beitsschritte gef hrt Navigationselemente Layouts Widgets Verhalten Interaktionen Pr sentationslogik Schnittstelle zur Gesch ftslogik e Nach welchen Regeln erfolgt die Steuerung der Anwen dungsabl ufe e Wie wird die Dynamik der Abl ufe zwischen den Arbeits schritten und innerhalb der Arbeitsschritte kontrolliert Ereignisse Auswerten von Situationen Reaktionen Dialogfortschritt Umwelt Kontext Skalierung Pr sentations und Funktionskontext e Wie werden die verschiedenen Sichten rollen und bear beitungsstandbedingt auf den gleichen Anwendungsinhalt abgebildet e Wie reagiert die Oberfl che auf sich ndernde Umweltbe dingungen e Wie werden in Abh ngigkeit vom Bearbeitungsstand die auszuf hrenden Funktionen und Funktionsparameter be stimmt Ermitteln von Situationen Verwenden von Anwendungsfunktionen Verwenden von Anwendungsdaten Varianz Restriktionen Umgebung Var
110. d von Beispielen erl utert Die Spezifikationssprache erm g licht eindeutige UI Spezifikationen und damit eine gemeinsame Abstimmungsplattform f r die am Bau des User Interface betei listen Rollen Das Bespiel Hallo Welt zeigt wie die speziell f r Oberfl chen beschreibungen bereitgestellte Informationsstruktur mit der Be schreibungssprache Lucia ausgef llt wird Im Projektalltag k nnen Sie die Sprachbeschreibung und die Beispielmodelle als Referenzmaterial verwenden Sie finden in der Sprachbeschreibung Formulierungsbeispiele f r typische User Interface Bedienungssituationen und L sungsvorschl ge f r bliche UI Spezifikationsprobleme Kapitel 7 Architektur in dem die UI Beschreibung zu einem Entwicklungsartefakt gek rt und gezeigt wird was Entwickler daraus machen k nnen Eine UI Spezifikation die in Form und Inhalt eindeutig ist l sst sich auch maschinell auswerten und zum ausf hrbaren Code umwandeln Damit l sst sich eine Spezifikation hnlich wie Quellcode in einer h heren Programmiersprache verwenden Die in der formalen Spezifikation enthaltenen Informationen k nnen maschinell ausgewertet werden und daraus automatisiert zum Beispiel der Programmcode f r Dialogseiten der Anwen dung erzeugt werden Dieses Kapitel zeigt auf wie man die modellgetriebene Architek tur MDA auf UI Beschreibungen anwenden kann und welche Produktivit tszuw chse damit m glich werden Durch Transfor mationsalgo
111. dazu ggf den Da tenhaushalt der Anwendung 7 Oberfl che reagiert anwendergetriggert bzw agiert anwendungsgetriggert z B durch Transitionen Zustands berg nge in der Oberfl che Neuberechnung von Guards Bedingungen die an das Durchf hren von Transitionen gekn pft sein k nnen unter Verwendung des Datenhaushalts der Anwen dung Oberfl chen Dienste z B R ckmeldung an Anwen der oder durch Anfordern des Ausf hrens von Anwendungsfunktiona lit ten 8 Anwendung f hrt aus Sicht der Oberfl che synchron oder asynchron intern in der Regel asynchron die an geforderten Funktionalit ten aus bzw liefert die abge fragten Daten 9 Oberfl che schlie t die Reaktionen ab und l utet die Bereitstellung der aktuellen Ausgaben Kontextinforma tionen und Bedienelemente ein 10 Weiter mit Schritt 1 Anhand dieser Dialogschritte kann z B die Vollst ndigkeit der Checkliste f r das Beschreibung eines Dialogs in der Benutzeranleitung bewertet Pr fen von werden Beschreibungen Wesentlich f r das Verstehen des Mensch Maschine Dialogs ist Unterschied es zwischen dem kommunikationsorientierten Schema Aktion zwischen Aktion Reaktion und dem funktionsbezogenen Schema Eingabe Interpretation Ausgabe zu unterscheiden Reaktion und Auf der Ebene von Eingabe Ausgabe hat das Interpretieren von Eingabe Verarbeitung Benutzeraktionen bereits vorher stattgefunden In der Anwen Ausgabe dung wird daraufhin eine defi
112. dem durch das aktuelle Anzeige und Bedienkonzept definierte Look und Feel e Zielcode Generator mit Beispielapplikation auf der Ziel plattform Nutzen 221 dit Bild 97 Tool Chain f r die UL Entwicklung Modell notation verwalten UI Modell Daten Transformatoren transformieren Dokumente Test Ziel skripte code Simulations daten Screens Testsequenzer Simulator testen simulieren compilieren Testprotokolle UI Ausf hrbarer Prototyp Code Die neuen Funktionen sollten in die bestehende Methoden und Werkzeuglandschaft integrierbar sein 12 5 Nutzen Ul Modelle erh hen die Transparenz im Projekt und machen die Grenzen zwischen den Aufgaben weicher Bei der Einf hrung der UI Modellierung muss der Projektleiter daher besonderen Wert auf die Festlegung und Einhaltung von Zust ndigkeiten und Mitwirkungspflichten legen Empfohlene Projektmanagement Aktivit ten e Arbeiten im Kontext der UI Anforderungen e Sicherstellen der Integration der UI Entw rfe in die Aktivi t ten aller Entwickler e Klare Aufgabenteilung zwischen UI Entwicklern und Funk tionsentwicklern e Klare Aufgabenteilung zwischen verschieden spezialisier ten UI Entwicklern Durch ein aktives auf Offenlegung und Aufl sung von Konflik ten ausgelegtes Projektmanagement wird sichergestellt dass die 222 Projektmanagement UI Modellierung als Kommunikations und Abstimmungsplatt form d
113. der Oberfl che benutzt dient dem Oberfl che Anwender e Abh ngigkeit Verwendung Bringt Anwendungsf lle in eine Abh ngigkeitsbezie hung z B Inhalte ausgeben beinhaltet Kontext ausge ben oder Priorit ten ber cksichtigen erweitert Signale interpretieren o Kontext beinhaltet ausgeben Inhalte er ausgeben 24 Einf hrung e Spezialisierung Generalisierung Bringt Anwendungsf lle oder Aktoren in die Beziehung ist ein z B Pushbutton dr cken ist Kontrollele ment bedienen oder Spezifizierer ist ein Entwickler Kontrollement bedienen Entwickler IE Spezifizierer Programmie rer Architekt Pushbutton dr cken e Systemgrenzen Kennzeichnen mehrere Anwendungsf lle als zu einem System zugeh rig z B Die Anwendungsf lle Daten bereitstellen und Requests auf Funktionen mappen werden im Kontexthandler bereitgestellt Kontexthandler Daten N bennaite O bereitstellen Daten und S Funktionszugriff Requests l anbinden beinhaltet auf Funktionen a beintaitg Requests 57 N Die obige Aufstellung zeigt nur einen Auszug aus den vielf lti gen M glichkeiten die Klassen und Use Case Diagramme bie ten Eine weitgehend vollst ndige Beschreibung der UML finden Sie z B in Jeckle 2004 1 8 Zusammenfassung Bauentwurfslebre Oberfl chen sind von den urspr nglich kargen Kommandokon f r Oberfl chen solen zu
114. der f r diese Iteration definierten Detaillierungsebene vollst ndig ist Blockierende Gegens tze sollen erkannt und durch Designentscheidungen ausger umt werden Strukturperspektive 7 Anforderungsperspektive Ressourcen perspektive perspektive Interaktionsperspektive 4 Iterationsmodell 109 Das User Interface Modell wird nach dem Ansatz der UI orientierten Architektur gleichm ig aus der jeweiligen Per spektive und aus der Wechselwirkung der Perspektiven unter einander heraus aufgebaut Im iterativen Modellierungsprozess wird die anfangs grobe User Interface Spezifikation Iteration f r Iteration ber ihre gesamte Breite vertieft 5 2 Iterationsmodell Um die Phasen der UI Definition besser zu berblicken bietet sich eine Einteilung des UI Modellierungsprozesses in Fertigstel lungsstufen an Das Vorgehensmodell RUP Rational Unified Process unterteilt den Software Entwicklungsprozess in vier Phasen in denen die verschiedenen Entwicklungsaufgaben unterschiedlich stark aus gepr gt sind Die untenstehende Grafik verdeutlicht den Vorge hensansatz des Rational Unified Process Workflows Business Modeling Requirements Analysis amp Design Implementation Test Deployment Configuration amp Change Mgmt Project Management Environment Iterations Die im RUP vorgenommene Aufteilung bietet aus meiner Sicht eine brauchbare Ausgangsbasis f r das stufenwei
115. derun gen und benutzt Dialoge und den Kontext 138 Sprache UCIA Datenmodell Lucia Sprache e Die Dialoge realisieren die Kommunikation der Logischen Schritte Sie folgen den Anforderungen und benutzen den Kontext e Die Kontextelemente werden von Logischen Schritten und Dialogen herangezogen Sie folgen den Anforderungen e Die Anforderungen bilden die Grundlage f r Logische Schritte Dialoge und Kontextelemente 6 5 Ul Beschreibungssprache Lucia Die in der User Interface orientierten Softwarearchitektur vorge schlagenen Modellierungshilfsmittel f r Anwendungsoberfl chen bestehen aus einer Informationsstruktur und aus einer Grammatik Die Informations bzw Datenstruktur ist so beschaffen dass sie die ber eine Oberfl che gesammelten Informationen als Bezie hungsgeflecht aufnehmen kann Die Grammatik legt eine Spra che fest mit der die Datenstruktur auf effiziente Weise bef llt werden kann Im Folgenden bezeichne ich diese Datenstruktur als User Cente red Information Architecture bzw als UI Datenmodell und die Sprache als Language for User Centered Information Architectu re Die Akronyme hierf r sind UCIA und Lucia Der Nutzen der bisher vorgestellten M glichkeiten zur UI Modellierung liegt in der Bereitstellung einer Entwurfsmethodik f r Anwendervertreter und Spezifizierer Ein Ausbau der Ent wurfsmethodik zu einer Modellierungssprache weitet die Gruppe der Nutznie er eines UI Informationsmodells auf
116. die Definition ver schiedener Skins z B f r Tag Nacht Design e Unterst tzung zur Internationalisierung Eigenschaften wie Texte Bilder Fonts Koordinaten k nnen abh ngig von der Sprache definiert werden Automatische Textl ngenberechnung Export Import Funktion f r das bersetzungsb ro e Referenzsuche Wo wird dieses Element in der Spezifika tion verwendet e Erstellung von Templates um bereits konfigurierte Wid gets wieder zu verwenden e Papierkorb Konzept e Export der Spezifikation in spezielle XML Formate als PDF Dokumentation e Batch Screenshot aller Views Als Bitmap Als Vektorgrafik SVG e Codegenerierung f r eingebettete Systeme f r verschiedene Betriebssysteme embedded Grafik bibliotheken und Programmiersprachen z B VxWorks WinCE QNX Linux C C Java OSGI Modellieren mit Guide Ein View wird im View Editor spezifiziert Links oben ist die Baumstruktur der Widgets des aktuell gezeigten Views zu sehen Rechts in der Mitte wurde gerade die aktuelle Variante Skin Digital Day ausgew hlt Die im View Editor spezifizierten Views werden im Zustandsedi tor zur Definition des Men ablaufs verwendet Auf verschiede nen Diagrammen wird das Verhalten des Systems mit UML Zustandsdiagrammen beschrieben Illustrierte Zustandsdiagramme und automatische berpr fungen erleichtern dabei die Arbeit 76 Werkzeuge Bild 30 Guide View Editor Bil
117. die auf dem Informa tionsmodell Maschinennahe Sprache aufsetzenden Auswer tungswerkzeuge durchschlagen Die Auswertungswerkzeuge bezeichnet durch M2C und M2R werden durch die Komplexit tsreduktion bei Umwandlung von menschennahen Hochspracheformulierungen zu maschinenna hen Low Level Strukturen bezeichnet durch N2M und M2N einfacher Die in der Spezifikation enthaltene Information ist prim r in Logische Schritte bzw Ablaufschritte unterteilt Logische Schritte legen eine hierarchische Ablaufstruktur fest wobei jeder logische Schritt in weitere logische Schritte unterteilt sein kann So werden die T tigkeiten des Anwenders in eine Reihenfolge gebracht und in kleinere Teilaufgaben gegliedert Logical Steps sind die Struktur Perspektive der Spezifikation Jeder logische Schritt kann muss aber nicht als Kommunikati onsmedium zum Anwender einen Dialog verwenden Ein Dialog besteht aus Widget Gruppen und aus einzelnen Widgets die Bedienungselemente z B Grafische Ein und Ausgabe Controls Hardbuttons Voicebuttons repr sentieren Datenmodell f r UI Spezifikationen 137 Dialogs Widget Groups und Widgets sind die Dialog Perspektive der Spezifikation Die Oberfl che interagiert mit dem Anwender im Kontext der Funktionen und Daten der zugrunde liegenden Anwendung Das Verhalten und die Anzeigen der Oberfl che h ngen von den verf gbaren Funktionen und von Daten der Anwendung und von den Aktivit t
118. dienung die Gesch ftsabl ufe des Unternehmens und die fachlichen Arbeitsschritte in der Bedienung einer Software abgebildet werden Entscheidender Unterschied beim Entwickeln der Softwareober fl che mit UI Modellen ist Die Pr sentationsschicht wird nicht codiert oder mit einem Designwerkzeug gezeichnet sondern aus den im Konzept modellierten Anforderungen generiert Das er m glicht e Plattformunabh ngigkeit e Flexibilit t Robustheit e Qualit tserh hung Kostensenkung e Produktivit tserh hung Anforderungen modellieren und Code aus Konzept generieren ist nachhaltiger als plattformspezifisches Design und Codierung Die bew hrte Oberfl che kann so den Lebenszyklus einer tech nischen Umsetzungsplattform berdauern und evolution r mit neuen technischen M glichkeiten weiterentwickelt werden 13 3 Zusammenfassung und Ausblick UI Modelle haben einen vielf ltigen Nutzen der auch ber Re leases und Lebenszyklen einer Software hinweg wirkt Der Ein satz von UI Modellen zahlt sich in allen Projektphasen von der Anforderungsanalyse bis zur Realisierung und Test der Software aus Durch die Verwendung von UI Modellen lassen sich Entwick lungskosten senken und Entwicklungsprozesse beschleunigen Zusammenfassung und Ausblick 229 Konzeptionsergebnisse k nnen direkt in ablauff hige An wendungsoberfl chen umgewandelt werden Die Dokumentation der Anforderungen ist strukturiert und nachvollziehbar Entwickl
119. e Bild 19 Software kann man nicht mechanisch wahrnehmen Die Interaktion eines Papierbuches mit seinem Nutzer ist mecha nisch und kulturell klar geregelt Ausnahmen best tigen die Re gel Wenn beim Bl ttern in einem Buch pl tzlich die eben um gebl tterte Seite Flammen f ngt oder Buchstaben sich in Nichts aufl sen wenn das Buch zu Staub zerf llt oder andere okkulte Aktivit ten entwickelt wissen wir dass dies nach physikalischen Gesetzen nicht normal ist Bei dem Versuch das Verhalten von Software zu verstehen greift der Nutzer auf seine Erfahrungen mit der realen Umwelt zur ck Er erwartet intuitiv dass die Software gewisserma en den Gesetzen der Mechanik folgt was aber oft nicht der Fall ist Wenn eine Software nicht die intuitiv erwarteten Aktivit ten un ternimmt z B wenn Dialogseiten pl tzlich nicht an gewohnter Stelle erreichbar sind oder wenn Dialogelemente pl tzlich er scheinen oder verschwinden sprechen wir von Features oder von Fehlern und legen ggf im Einzelfall das Sollverhalten fest Kognitive Wissenschaften und die Usability Forscher besch fti gen sich unter anderem damit wie die Informationen an der Oberfl che dargestellt werden und wie Eingabeelemente aufge baut sein m ssen damit sie f r den Anwender intuitiv und opti mal verwendbar sind W hrend die mechanischen Metaphern z B Einrasten einer Schaltfl che beim Draufklicken von allen Menschen hnlich wahrgenommen werden h nge
120. e 38 Oberfl che Beispiel Um mit dem Erfassen eines neuen Kundendatensatzes zu begin nen wird der Punkt Neuer Kunde aus dem Hauptmen ge w hlt Reaktionserwartung e Anwendersicht Was tut die Anwendung wenn ich etwas mit ihr mache e Oberfl chensicht Alle Aktionen des Anwenders sollen durch eine wahrnehmbare Reaktion quittiert werden e Entwicklersicht Welche Reaktionen zeigt die Anwendung auf Eingaben oder auf Eingabeversuche des Anwenders Beispiel Wenn ein Punkt aus dem Hauptmen gew hlt wird wird die zu diesem Punkt passende Dialogseite eingeblendet Konvergenzerwartung e Anwendersicht Wenn ich das Gleiche wieder mache macht die Anwendung dann auch wieder das Gleiche o der etwas anderes e Oberfl chensicht Die Reaktionen der Oberfl che sollen f r den Anwender einem einfachen und leicht nachvoll ziehbaren Muster folgen e Entwicklersicht Folgen auf die gleichen Eingaben oder Eingabesequenzen die gleichen Reaktionen der Anwen dung Wann reagiert die Anwendung anders Beispiel Wenn zum zweiten Mal hintereinander Speichern gew hlt wird k nnte in der Statusleiste die Meldung Seit dem letzten Spei chern ist nichts ge ndert worden Speichern nicht n tig er scheinen Die Oberfl che k nnte auch die Aufforderung zum Speichern ohne R ckmeldung ignorieren oder jedes Mal Spei chern Erfahrungs und Funktionserwartung e Anwendersicht Tun die Bedienungs
121. e Nachvollziehbarkeit e Durchg ngigkeit Sie k nnen mit der User Interface orientierten Softwarearchitek tur keine Arbeit sparen daf r aber Zeit Wenn Sie etwas bauen z B einen Schreibtisch k nnen Sie nicht sagen wir mal die Tischplatte ungehobelt lassen wenn Sie diese am Ende schleifen und polieren wollen Planungssicherheit Sicherung der Projektziele Doppelarbeit vermeiden Einf hrung Bild 8 Dialogbaupl ne helfen Missverst ndnisse zu vermeiden Das Buch ist eine Anleitung zum Erstellen von Dialogbaupl nen Das hei t Alle zu einem Entwicklungsprozess geh renden Ar beitsg nge m ssen durchgef hrt werden Das Buch hilft Ihnen allerdings dabei die Entwicklungsarbeit im gemeinsamen Kon text und mit der gr tm glichen Transparenz f r alle Projektbe teiligten zu erledigen Sie schlafen ziemlich ruhig wenn das sichergestellt ist 1 4 Benutzeroberfl che in den Mittelpunkt r cken Missverst ndnisse bei Auftragsvergabe und Systementwurf verur sachen oft erhebliche Folgekosten Die Vermeidung von Missver st ndnissen l sst sich durch eindeutige Oberfl chenbeschreibun gen so genannte Dialogbaupl ne erreichen Eindeutige Dia logbaupl ne braucht man um Softwareoberfl chen gem Kundenbestellung zu programmieren Dialogbaupl ne beschreiben das User Interface eindeutig und helfen Missverst ndnisse zu vermeiden Die Oberfl che ist das was Kunden und Anwender von der So
122. e andere sind DSLs Domain Specific Languages fachgebiet spezifische Sprachen Hier beschreibt man mit einem Fachvo kabular fachliche Sachverhalte zum Beispiel Periodensystem der Elemente technisches Zeichnen Elektrobaupl ne und bildet diese Information mit Generatoren in Code der Anwendung ab z B Funktionen zur Ausgabe der Periodentabelle der Kernscha lengrafiken sowie Fusion und Spaltung von Elementen Hierbei entstehen fachspezifische Modelle von Fachdaten und Fachalgorithmen oberhalb der Ebene der Programmiersprache Die Model Driven Architecture ist noch auf dem Weg von einer Initiative zu einem zuverl ssigen Standard Heute zeigt die Arbeit mit MDA Parallelen zum fr hen Stadium des Dieselmotors wenngleich dies wahrscheinlich nicht mit einer eigenen Gedenk tafel pr miert wird Im MAN Diesel Werk in Augsburg h ngt an einer Ziegelmauer eine in Messing gefasste Gedenktafel welche besagt dass an dieser Stelle Herr Ingenieur Diesel seinen ersten Motor in Betrieb nahm welcher 30 Sekunden lief bevor er ex plodierte Heute aber ist der Dieselmotor technisch ausgereift und funktioniert zuverl ssig in unterschiedlichsten Fahrzeugen F r die MDA in Verbindung mit ihrem Treibstoff den dom nen spezifischen Sprachen ist dieser Reifeprozess aus meiner Sicht noch im Gange 7 4 Ul orientierte Laufzeitkomponenten In einer User Interface orientierten Architektur kann die Oberfl che Komponenten verwenden die Dienste zu
123. e des Vermittlers zwischen An wender und Anwendung e Die Anwendung im Sinne der durch die Oberfl che er reichbaren Funktionalit ten und Informationen Der Dialog zwischen Anwender und Anwendung findet indirekt ber die Vermittlung durch die Oberfl che statt Der Anwender ist die Umwelt der Anwendung Dieser Akteur l sst sich zu Mensch oder Maschine erweitern Mit dieser Er weiterung k nnte man den L sungsraum der Schnittstellenkom munikation im Allgemeinen zum Beispiel den Dialog zwischen zwei Anwendungsoberfl chen untersuchen Bild 20 Dialog zwischen Anwender und Oberfl che 46 Oberfl che Entsprechende L sungen verfolgt die SOA Service orientierte Architektur indem in diesem Architekturansatz die Funktionali t t der Anwendung als Prozessbausteine in Form von Diensten bereitgestellt wird Die User Interface orientierte Architektur be schr nkt sich auf die Untersuchung des Dialogs des Anwenders mit der Oberfl che und der Oberfl che mit der Funktionalit t der Anwendung Um ein Ablaufschema f r diesen Mensch Maschine Dialog aufzu stellen kann man die Dialogsituation wie oben skizziert aus dem Blickwinkel der Softwareoberfl che analysieren Bild 21 Mensch 11 Kontext Maschine Dialog ausgeben 2 Oberfl che 7 wartet aus der Sicht des UI e _ Inhalte ONeImgaBebErEE gt 7 gt UI eingabebereit Anwender Bedienelemente 3 interpretiert ausgeben Anwender manipuliert
124. e dia logintensive vor allem horizontale aber auch vertikale Soft wareanwendungen Siehe Abschnitt Horizontale und vertikale Oberfl chen im Kapitel Oberfl che Sprachmodell zur UI Beschreibung 120 Sprache Bild 54 Einsatz einer UI Sprache f r praxis bliche Oberfl chen Bild 55 Syntax Semantik Informations Modell User Interface Modellierungssprache direkt manipulativ Grafische vertikal Oberfl chen 20 3 formularorientiert horizontal Textorientierte Oberfl chen befehlszeilen gesteuert Kommando gesteuerte Oberfl chen sprachkommando gesteuert Das Gesamtmodell verbindet die verschiedenen Ausdrucksmittel Screenbeschreibung logische Schritte Anforderungsbeschrei bung zu einer integrierten UI Beschreibungssprache Es stellt eindeutige Ausdrucksformen zum Festlegen von Ul Eigenschaften und eine Datenstruktur zur Verwaltung dieser Informationen bereit A s H uunun hi Wortschatz amp A cke Und Kombinationsregeln a der Datenstrukturen Datenstrukturen Speichermedium Informations modell e Die Syntax einer Sprache legt den zur Verf gung stehen den Wortschatz und die Grammatikregeln f r Wortkombi nationen und f r das Aufbauen von S tzen in der Sprache fest e Die Semantik einer Sprache ist die Bedeutung von syn taktisch korrekten Worten Wortkombinationen S tzen und Satzfolgen Use C
125. e in den Verruf geraten st ndig alles zu ver ndern und die Realisierung der Anwendung aufzuhalten 12 1 Arbeiten im Kontext der Ul Anforderungen Die Anforderungen an das User Interface liefern Informationen die alle Teile der Software betreffen Diese Informationen m s sen an alle Projektbeteiligten verteilt werden Umgekehrt werden f r das Entwickeln der Oberfl che Informationen ber alle Teile der Software herangezogen und verwendet Anforderungen Prozesse User Interface Die Anforderungen an das User Interface sind Kerninformationen f r das Wissensmanagement des Projekts Sie k nnen verwen det werden um nutzbringend das gemeinsame Vorgehen im Projekt zu koordinieren Informationen ber Prozesse werden verwendet um die Ablauf struktur des UI zu formen Informationen ber Funktionen wer den dazu herangezogen diese Funktionalit t per UI dem An wender zur Verf gung zu stellen Informationen ber Daten Integration sicherstellen 211 werden zur Steuerung von Funktionen und Abl ufen benutzt Die Informationen ber das Design bestimmen das Look und Feel der Software Die Informationen ber die Zielplattform ge ben Einschr nkungen und Rahmenbedingungen f r die vom UI angebotenen Darstellungs und Bedienungsformen 12 2 _ Ul orientiertes Vorgehen Die Entwicklung der Oberfl che sollte im Entwicklungsprozess als ein eigener zur Funktionsentwicklung paralleler Entwick lungsbereich angesiedelt und e
126. e und Abh ngigkeiten des Er 72 Werkzeuge scheinungsbildes der Kontrollelemente vom Ablaufkontext der Anwendung modelliert werden k nnen Sowohl Verhalten als auch Kontextbezug werden beim Einsatz von GUI Toolkits bzw GUI Bibliotheken typischerweise in der Programmiersprache kodiert f r die die Bibliothek erstellt wur de 3 8 Grafische Ablaufmodellierungswerkzeuge Ein Konsens ber den Modellierungsbedarf im Bereich der An wendungsoberfl chen kristallisierte sich nur langsam heraus Die von David Harel Mitte der 80ger Jahre vorgeschlagene State Charts Notation Harel 1987 trug den Verschiebungen von pro zeduralen zu reaktiven Systemen Rechnung und lieferte erstmals eine standardisierte Beschreibungsform f r Teile von Oberfl chen Die State Charts k nnen die Ablauf und die Strukturaspekte einer Oberfl che beschreiben bieten aber keine Hilfe zum Be schreiben wie Dialoge und Anwender Notifikationen dargestellt werden State Charts bieten auch keine explizite Schnittstellen sicht zum funktionalen Teil der Anwendung Dennoch spielen Statecharts nach wie vor eine zentrale Rolle f r die Ablaufmodellierung von User Interfaces State Charts werden von verschiedenen Experten als Instrument zur UI Entwicklung diskutiert und empfohlen Im Kapitel Sprache im Abschnitt State Charts Notation finden Sie eine Einf hrung in die State Charts Notation sowie eine Ana lyse der Verwendbarkeit von State Charts zur Spezif
127. ebe reichen An Wertegruppen und einzelne Werte k nnen Reaktionen zum Beispiel Fehlermeldungen insbesondere auf Ausschlusswerte und Werte au erhalb des Wertebereichs Value Checker Erg n zer automatisches Erg nzen der Eingaben anhand von Anfangs buchstabenfolge gekn pft werden Formatschablonen erm glichen die Pr sentationsaufbereitung von numerischen und alphanumerischen Werten blicherweise werden Pattern Eigenschaften in einem Kontext objekt zusammengefasst und k nnen mittels using name beliebig oft verwendet werden Bei Bedarf k nnen Pattern Eigenschaften auch direkt in der Definition eines Kontrollelements festgelegt werden Zum Beispiel selectionfield named monatsauswahl using widget auswahlkreis pattern values Januar Februar M rz Dezember 162 Sprache Die Sprache ist die Wohnung des Seins 6 8 Nutzen Der Nutzen einer eindeutigen UI Beschreibungssprache ist Die unterschiedlichen Vorstellungswelten der Interessengruppen k nnen ohne Zusatzaufwand zu einem Gesamtbild vereinigt werden Das Gesamtbild ist eindeutig und kann maschinell aus gewertet und transformiert werden Die formale UI Beschreibung liefert etwas was aus PowerPoint Folien und aus formfreien Beschreibungen nicht herausgelesen werden kann Hinreichend genaue eindeutige Informationen ber geforderte Eigenschaften der Oberfl che Der Nutzen der Lucia Sprache l sst sich anhand von Tourist
128. edeutet dass die mit basedOn geerbten Eigenschaften vom erbenden State berschrieben und oder um weitere Eigenschaften erg nzt werden k nnen F r die Kombination von hierarchischer und orthogonaler Verer bung gilt e Event Bekanntmachung in den Steps und in den Widgets Suche nach Event Handler erfolgt erst orthogonal und danach hierarchisch auf der Elternachse e Beim Erben der Containments erfolgt die Verschmelzung nur aus orthogonal geerbten Inhalten Hierarchisch wird kein Containment vererbt Funktions und Datenkontext verwenden Eine Benutzeroberfl che vermittelt zwischen Anwender Mensch und der funktionalen Anwendung Maschine Die Oberfl che muss daher mit der Anwendung kommunizieren um das Aus f hren von Funktionen anzusto en und um Informationen aus dem Datenhaushalt der Anwendung zu holen Die Oberfl che gibt an den Anwender Informationen aus die sie aus den Daten der Anwendung holt Sie stellt auch Bedienele mente zur Verf gung die auf Anwenderaktionen reagieren Die se Reaktionen k nnen Aufrufe von Anwendungsfunktionen be inhalten Zum Beispiel e Auf dem Bildschirm wird von der Oberfl che eine alpha betische Liste von Orten ausgegeben Die Liste ist ein Aus wahlfeld aus dem ein Ort ausgew hlt werden kann e Neben der Liste gibt es auf dem Bildschirm ein Eingabe feld Werden in diesem Eingabefeld Buchstaben eingege ben dann wird die Liste auf die Eintr ge eingeschr nkt in dene
129. edingen sich gegensei tig Oft kann das Was und das Wie einer Software nur im Zu sammenhang verstanden werden daher ist es auch ratsam UI Modell und Funktionsmodelle in gegenseitiger Abstimmung zu entwerfen Funktionalit ten Informationsmengen Fachliche Attribute Funktionale Anforderungen Worksteps Dialoge Bausteine Templates Schl ssel Auswahllisten Oberfl che Anforderungen Kollaboratives Modellieren 177 Oberfl chenanforderungen haben mittelbaren Einfluss auf funk tionale Anforderungen Umgekehrt wirken sich Funktionen auch auf die Art der Bedienung aus Die fachlichen und technischen Restriktionen wirken sich sowohl auf die Bedienung als auch auf die Funktionen aus Inhaltliche Anforderungen stehen in Wechselwirkung mit Nut zungsanforderungen d h sie bedingen sich zum Teil gegensei tig Das in der herk mmlichen Vorgehensweise postulierte vonein ander getrennte Betrachten dieser beiden Bereiche ist nicht prak tikabel Mit der Ul Orientierung wird dem Vorliegen dieser Wechselwir kungen Rechnung getragen und entsprechende Behandlungs m glichkeiten f r die sich daraus ergebenden Aufgaben aufge zeigt 8 2 Kollaboratives Modellieren Eine durchg ngige Spezifikation erstreckt sich von der Pr senta tionsschicht bis zur Systemschicht der Anwendung Durchg ngig bedeutet dass alle Aspekte der Software in einem gemeinsamen konzeptionellen Rahmen gehalten fe
130. ehen welche Transitionen die Hauptpfade sind und welche Transitionen Ausnahme bzw Nebenpfade wie dergeben L sungsm glichkeit Unterscheiden zwischen Sequenz schritten und Serviceschritten Unterscheiden zwischen Transitionen auf dem Haupt pfad und Neben und Ausnahmepfaden Konzepte f r eine UI Beschreibungssprache 129 In Bezug auf Pr sentationslogik und Lokalisierung e Es k nnen nur Abl ufe und Interaktionen beschrieben werden Es fehlt aber die Unterst tzung des Definierens und des Bezugnehmens auf andere UI Teile z B Kon trollelemente Dialogseiten Funktions und Datenkon text L sungsm glichkeit UI Perspektiven die den Use Ca se Modulen des UI Modellierens folgen Querverweise zwischen Bestandteilen der Strukturbe schreibung und Bestandteilen der Verhaltensbeschrei bung sowie den Anforderungen In Bezug auf Vererben und wieder verwenden e Eine State Chart wird durch die vielen Transitionen und Interaktionen einer modernen grafischen Oberfl che schnell komplex und un bersichtlich e Es fehlt ein universell verwendbarer Wiederverwen dungsmechanismus f r Eigenschaften von States und f r Transitionen L sungsm glichkeit Auslagerung von Situationen auf die bei Transitionen Bezug genommen wird in eine eigene Modellierungssicht Bezugnahme auf bereits definierte Schritte mit einem based on Konstrukt 6 3 Konzepte f r eine Ul Beschreibungssprache Es w
131. eibung wieder verwenden Wie h tte dieses in der Praxis leider nicht un bliche Szenario vermieden werden k nnen Wie kann man beim Reengineering das Weglassen entscheidender bew hrter Oberfl cheneigen schaften vermeiden Wie schlie lich kann man sicherstellen dass bei zuk nftigen Technologiewechseln die Oberfl che nicht neu entdeckt werden muss sondern eine verbindliche Basis f r die Umsetzung in neuer Technologie ist und bleibt User Interface Orientierung beim Reengineering hilft Bew hrtes zu bewahren Das steigert die Akzeptanz der Innovation Herczeg unterstreicht die Wichtigkeit der Kontinuit t beim Ent wickeln und Weiterentwickeln von User Interfaces Traditionelle Werkzeuge und Hilfsmittel wurden meist mit hohem Aufwand ber lange Zeitr ume f r eine gute Bedienbarkeit entwickelt und dabei ber viele Entwicklungsschritte an menschliche Physiologie Fertigkeiten Kenntnisse und Pr ferenzen optimal angepasst Es haben sich auf diese Weise vielf ltige oft undokumentierte Ge staltungsprinzipien Entwicklungs und Testmethoden sowie nati onale und internationale Standards entwickeln k nnen Bei computerbasierten Systemen fehlen diese langj hrigen evolutio n ren Entwicklungsprozesse und viele daraus abgeleiteten Erfah rungen auf Grund der vergleichsweise kurzen Historie interakti ver Computersysteme weitgehend Herczeg 2005 Bei Softwareoberfl chen fehlen traditionelle an der Bedienung und der Bed
132. eine andere Status marke ndert die in die Berechnung der aktuellen Statusmarke einflie t Alle Statusmarken deren Ermittlungsvorschrift den betroffenen Wert beinhaltet werden dann ung ltig gesetzt Das wird f r alle Statusmarken wiederholt die wiederum in ihrer Ermittlungsvorschrift eine der auf ung ltig gesetzten Statusmar ken beinhaltet Dieser rekursive Algorithmus erreicht dass Statusmarken von Situationen nicht bei jedem Abruf sondern nur bei Bedarf neu ermittelt werden Trotz des Aufwands f r das rekursive Durchsu chen der Tabelle nach abh ngigen Werten kann diese Methode die Geschwindigkeit der Anwendung steigern Alternativ kann man nat rlich auch mit der Holzhammermethode bei nderung eines Wertes der in eine beliebige Situationser mittlungsvorschrift einflie st alle Situationen auf ung ltig setzen und so die Neuberechnung aller Statusmarken erzwingen Bei der Berechnung der Statusmarken ist die Reihenfolge der Durchf hrung von Bedeutung Die richtige Reihenfolge kann schwierig zu ermitteln sein wenn nicht klar ist welche Situatio nen von welchen abh ngen Ein rekursiver Algorithmus hilft hierbei weiter kann aber aufw ndig sein und kann zirkul re Abh ngigkeiten nicht verhindern Es empfiehlt sich daher eine Hierarchie von Situationen aufzu bauen und den Situationsbaum von den Bl ttern des Baums aufw rts zu berechnen Durch hierarchischen Aufbau der Situationen kann auch unkom pliziert vermieden
133. eispiel wird Ihnen zeigen was User Interface orientierte Architektur bringt und was Entwickler Pla ner und Auftraggeber mit ihr erreichen k nnen Szenario 1 stellt ein implementierungsorientiertes Vorgehen vor Szenario 2 stellt ein User Interface orientiertes Vorgehen vor Szenario 1 BetaSoft amp BetaRent Die Firma BetaSoft erh lt von der Autovermietung BetaRent den Auftrag eine Kundenverwaltung zu erstellen Nachdem der Auftragsinhalt vom Hersteller analysiert wurde wird gemeinsam mit dem Kunden die Realisierungsplatiform abgestimmt Dabei wird schnell ersichtlich dass die Kundenver waltung auf der gew nschten Realisierungsplattform nicht so wie vom Kunden gew nscht umgesetzt werden kann Sodann werden die Anwendungsszenarien unter den gegebenen techni schen Rahmenbedingungen konkretisiert Bild 11 Entwickler modellieren vorwiegend das Innenleben der Software Beispiel f r implementierungs orienliertes Vorgehen 12 Einf hrung Beispiel f r UT orientiertes Vorgehen Bei der Detaillierung der Anforderungen werden zuerst die gew nschten Prozesse und dann die einzelnen Funktionen auf genommen In mehreren Iterationen werden dann die Anwen dungsf lle und die Ablaufvarianten beschrieben Ebenso wird beschrieben wie die Anwendung in einzelnen Ausnahmef llen reagiert Das Klassenmodell die Ablaufdiagramme und die Fall unterscheidungen werden kontinuierlich mit BetaRent abge stimmt bis das Konz
134. eld in ihre Kreditsoftware investiert Die auf die Belange der Bank angepasste Oberfl che hat sich bew hrt Die Anwendung arbeitet zuverl ssig Leider l uft die Software auf einem veralteten Betriebssystem f r das es kaum noch Support gibt Neue technische Anforderungen wie die Abwicklung von Kreditanfragen via Internet und die Ver kn pfung mit einer Groupware zwingen die Bank schlie lich zu einem Reengineering der Software auf einer aktuellen und zu kunftssicheren technischen Plattform Die Bank beauftragt die interne IT zusammen mit der externen Firma KreditSoft mit der Planung und Umsetzung des Folgesys tems Der Auftrag beschreibt die technischen Anforderungen die die Anwendung erf llen soll und auch welche neuen Anwen dungsfunktionen realisiert werden sollen Der brige Funktions umfang soll in der neuen Technologie fachlich genauso wie in der alten Anwendung umgesetzt werden Die bew hrte Bedie nungsphilosophie soll im Wesentlichen beibehalten werden Im Gro en und Ganzen geht der Auftraggeber davon aus dass die Funktionalit t und die Bedienung der neuen Anwendung einfach vom Altsystem abgeschrieben wird Nat rlich soll die Oberfl che entsprechend dem Stand der Tech nik modernisiert werden So soll zum Beispiel die bisherige Eingabe von dreistelligen Kennzeichenk rzeln durch Auswahl felder ersetzt werden Auch sollen Listenansichten und parame terabh ngige Workflows f r verschiedene Kreditarten von
135. elemente das wonach sie f r den Anwender aussehen e Oberfl chensicht Die Bedienungsmetaphern sollen sich an der Alltagswelt orientieren e Entwicklersicht Kann der Anwender dem Erscheinungs bild der Bedienungselemente und aus Erfahrungen mit User Interface Arten 39 Anwendungen die hnlichem Zweck dienen auf die Re aktion dieser Anwendung schlie en Beispiel Anwender greifen Wenn eine Schaltfl che mit Start beschriftet ist erwartet der unerfahrene Anwender eventuell dass das gerade zuvor ange klickte Desktopsymbol gestartet wird Der erfahrene Anwender wei dass beim Klicken auf diese Schaltfl che ein Men erscheint in dem z B auch der Punkt Computer ausschalten enthalten ist welchen er zun chst hinter dem Wort Start nicht vermuten wird M glicherweise w re Men oder Mach mal eine erwar tungskonformere Beschriftung der bewussten Start Schaltfl che 2 3 User Interface Arten Man kann Softwareoberfl chen zum Beispiel nach Dialogform Dialogmitteln Modalit t oder nach Bedienungsparadigma hori zontal vertikal klassifizieren Untenstehend finden Sie die aus meiner Sicht wichtigsten Klassi fizierungsmerkmale Dialogformen e Directed Dialog angeleiteter Dialog Computerinitiierte Dialoge z B grafische oder gesprochene Auswahlmen s e Form Filling Dialog Eine Form des angeleiteten Dialogs bei der vor allem die vom Computer angebotenen Formu
136. em Entwickler berantwortet Manchmal begegnet man noch extremeren Beispielen Die Funktionalit t wird ohne Oberfl che als Framework entwickelt und die Oberfl che in einem Einf hrungsprojekt beim Kunden dr bergelegt Die Bedienung der Software wird damit einhergehend nicht als Mittelpunkt des Projekts sondern eher als Aufsatz auf die techni sche Umsetzung der Funktionalit t wahrgenommen In der Pra xis hat das allerdings zur Folge das erst beim Entwickeln der Oberfl che die L cken und Br che in einem vermeintlich ein satzf higen Framework zum Vorschein kommen Form follows Use Case Der Henkel einer Tasse ist ihre Benutzerschnittstelle Ein auf der Innenseite der Tasse angebrachter Henkel funktioniert zwar me chanisch genauso stellt jedoch den Anwender beim Verwenden des Henkels insbesondere in Kombination mit Heifsgetr nken vor gro e Herausforderungen Sie kennen sicher aus eigener Erfahrung die eine oder andere Softwareanwendung bei der Ihnen der Gedanke an eine Tasse mit Henkel innen einfallen mag Der bekannte Satz Form follows Function kann aus meiner Sicht zu dem folgereichen Missverst ndnis f hren dass eine funktionale Spezifikation ein Werkzeug hinreichend beschreiben kann Zum Beispiel soll ein Fotoapparat photographieren aber diese Funktion wird unter Wasser anders ausfallen als auf einem Kindergeburtstag Es gilt daher auch Function follows Use Case Die Form orientiert sich an
137. en 183 Mit Hilfe der so verkn pften Modelle k nnen Analytiker konkre te Eigenschaften der Anwendung verst ndlich vorstellen und mit den Projektbeteiligten diskutieren So kann das Entwicklungsteam Widerspr che zwischen Verwen dungsabsicht und Konstruktionsentwurf aufsp ren und noch vor der Implementierung korrigieren Die parallele Verwendung der User Interface orientierten Model le und der UML Modelle f hrt zu besten Ergebnissen Die M he des kontinuierlichen Abgleichens zwischen den Teil modellen wird durch k rzere Entwicklungszeit weniger Nach besserungen und h here Qualit t des Softwareprodukts entlohnt Kapitel 9 Prozesssteuerung in dem Informationen aus UI Modellen zu elektronischen Workflows destilliert werden Kapitelziele e Visualisieren der Anwendungsabl ufe durch Prozess und Workflowgraphen e Modellieren von vorgegebenen Prozessen in der Anwen dungsoberfl che e Verwerten der ablaufrelevanten Informationen als Steue rungsregeln f r Ablaufmaschinen z B externe Workflow Systeme anwesndungsinterne Ablaufsteuerung In der UI Beschreibung sind s mtliche Ablaufm glichkeiten der Anwendung festgelegt Sie sind darin nicht explizit etwa als Transitionsgraph ausformuliert sondern in Form von Transitio nen zwischen Dialogseiten enthalten Prozesse und die Ab laufsteuerung von Anwendungen h ngen immer enger zusam men Unternehmen die gro e Verwaltungsanwendungen betreiben erheb
138. en englisch und der Eurow hrung bildhaft erkl ren Man versteht das bereiste Land nicht ganz hat vielleicht einen eingeschr nk ten Wortschatz aber man hat eine ganz gute Vorstellung davon was ein Euro ist und f hlt sich daher einigerma en sicher bei Kaufentscheidungen Die unterschiedlichen Vorstellungen und Erfahrungswelten der Anwendervertreter im Land der Entwickler und umgekehrt fin den im standardisierten Wortschatz eine gemeinsame Basis und erm glichen eine schnellere Vertiefung in die Belange des Ande ren beim Erreichen eines gemeinsamen Ziels Das Ziel ist eine funktionierende Anwendung die an der Ober fl che f r die Anwender in ihrem Sinne verwendet werden kann und in der Technik so umsetzbar ist wie es von den Ingenieuren vertreten werden kann Ich f ge als Motivation f r das Verwenden einer Sprache zu UI Modellierung hinzu Was man in einer Sprache f r andere ver st ndlich und eindeutig ausdr cken kann gewinnt Gestalt und beginnt zu sein Kapitel 7 Architektur in dem die Oberfl chenbeschreibung als formales Entwick lungsartefakt in die Softwarearchitektur aufgenommen wird Kapitelziele e Verwalten der UI Beschreibung zusammen mit dem Quell code der Anwendung e Inhalte der UI Beschreibung automatisiert in die Pro grammierung berleiten e Kommunizieren zwischen Projektbeteiligten ber generier te User Interface Prototypen Was das Projektmanagement f r die Verwaltung und Organisat
139. en Anwender schwieriger zu erfassen als die Kontrollelemente Diese Schwierigkeit ist leicht nachvoll ziehbar weil die User Interface Logik f r den Anwender nur indirekt durch das Verhalten der Kontrollelemente wahrnehmbar ist Typischerweise unterscheiden die Anwender nur zwischen der Bildschirmmaske und dem Programm hinter der Maske ohne weiter zwischen Pr sentationslogik Schnittstellenlogik oder Gesch ftslogik zu differenzieren Wenn es aber darum geht eine Softwareoberfl che zu konstruie ren ist eben dieser unsichtbare Teil der Oberfl che das Pro gramm hinter der Maske das zwischen den Kontrollelementen und den Anwendungsfunktionen vermittelt interessant F r diese Innenansicht der Softwareoberfl che kann man das strukturierte Geflecht der User Interface Logik in die Bestandteile User Interface Logik 55 e Ablaufneiz e Dialogseiten bzw allgemeine Dialogeinheiten und e Kontext gliedern Dieser Gliederungsvorschlag fu t auf der eigenen Erfahrung dass unabh ngig von der Architektur einer Software die Entwick ler stets zwischen e Kontrollfluss Controller e Dialogen Views mit Controllern und e Daten Model unterscheiden vergleiche hierzu auch MVC Entwurfsmuster Bild 25 Ablaufnetz Ben Dialogseiten und Kontext verwendet verwendet verwendet Das Ablaufnetz steuert den Ablauf der Softwareoberfl che und verwendet dabei die Di
140. en des Anwenders in der Oberfl che ab Die Kontextelemente auf die die Oberfl che Bezug nimmt sind die Kontext Perspektive der Spezifikation Die Anforderungen an die Anwendung und ihre Bedienung sind Grundlage der Struktur der Dialoge und der Kontextbez ge Die Verkn pfung der Oberfl cheneigenschaften mit den zugrunde liegenden Anforderungen erzeugt ein Geflecht das die gegensei tige Abh ngigkeit abbildet Die Anforderungen und ihre Verkn pfungen untereinander so wie die Verkn pfungen mit den Oberfl chenbestandteilen sind die Anforderungsperspektive der Spezifikation Bild 67 Inhalte und Verflechtungen der UI Perspektiven HCI Information Model Perspectives A Structure Perspective IN Dialog Perspective IN Dialog Logical Step lt lt use gt gt 7 Widget Group Widget Interaction Interaction I lt lt use gt gt l lt lt use gt gt lt lt use gt gt lt lt use gt gt y L y Context Perspective A Requirement Perspective N n Requirement Kontext rn Situer Description item Representation Data lt lt use gt gt References Function References Wie die obige Abbildung zeigt sind die Perspektiven einer User Interface Spezifikation miteinander verflochten und voneinander abh ngig e Die Struktur der Logischen Schritte folgt den Anfor
141. en oft die Forderung dass die Anwendung den Prozessen des Unternehmens folgen muss und nicht umgekehrt Meist wird diese Forderung mit einer Prozessbeschreibung z B in einem Aris Modell oder in IDEF unterlegt Hersteller von Prozessmodellierungs und BPM Business Pro cess Management Werkzeugen werben zuweilen mit dem Slo gan Eine Anwendungssoftware ist eine ausf hrbare Prozessbe schreibung Auch wenn die Formulierung bertrieben erscheint In Anwendungen die etwa Verwaltungs Verkaufs und Sachbe arbeitungsvorg nge abbilden geh rt die F hrung des Anwen ders durch die einzelnen Schritte dieser Vorg nge also eine Workflowsteuerung auf jeden Fall dazu Anwendungen sollen Gesch ftsprozesse unterst tzen Bild 80 Abl ufe und Regeln sind implizit im Programmcode eingebaut 186 Prozesssteuerung Prozesslogik Bearbeitungsstatus Eine Situation kann sich aus anderen Situationen zusammensetzen Die Anwendung befolgt also eine Prozessbeschreibung In den meisten F llen ist diese Prozessbeschreibung implizit Das heift dass die Abl ufe und Regeln im Programmcode der Anwendung abgebildet sind Die Regeln sind aber nicht explizit formuliert sondern auf die Ebene der Programmiersprache herunter gebro chen Dementsprechend ist meist Programmierarbeit angesagt wenn eine vorhandene Anwendung an nderungen der Abl ufe des Unternehmens angepasst werden soll 9 1 Prozesslogik und Situationen Der hier
142. en von User Interfaces z B der freie Dialog oder Augmented Reality sind in der Anwendungssoftware des t gli chen Gebrauchs eher selten Zielgruppe Eigenschaften die ber die Funktion eines guten Bedienpults hinausgehen zum Beispiel die oft beschworene Mensch Maschine Kommunikation wie zum Beispiel die zwischen Dr David Bowman und dem Computer HAL Ebeling 1988 S 96f werden von einer Anwendungsoberfl che gar nicht gew nscht Oder wollen Sie mit dem Navigationssystem in Ihrem Auto aus diskutieren ob es aus seiner Sicht Sinn macht von A nach B ber C zu fahren Zumal eine intelligente Anwendung auch l gen darf um den Turing Test zu bestehen Rose 1985 S 62 1 2 Zielgruppe Wo Software entsteht gibt es stets jene die sie beauftragen und sie anschlie end nutzen Die Auftraggeber Und nat rlich gibt es auch jene die die Software herstellen Die Entwickler Das Buch das Sie aufgeschlagen haben ist diesen beiden Zielgrup pen zu gleichen Teilen gewidmet User Interface orientierte Softwarearchitektur ist f r Leute die Software herstellen Programmierer Architekten Designer und Analytiker Und sie ist f r Leute die die Herstellung von Soft ware beauftragen und steuern Projektleiter Anwendervertreter Anforderungssteller und Qualit tssicherer Zur prim ren Zielgruppe der User Interface orientierten Architek tur geh ren e Softwareentwickler e Softwarearchitekten e Requirement Engineers z B
143. en wir die Umwelt schonen Dieses Buch ist auf s urefreiem und chlorfrei gebleichtem Papier gedruckt Die Einschwei folie besteht aus Poly thylen und damit aus organischen Grundstoffen die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen 1 Auflage August 2006 Alle Rechte vorbehalten Friedr Vieweg amp Sohn Verlag GWV Fachverlage GmbH Wiesbaden 2006 Lektorat G nter Schulz Andrea Bro ler Der Vieweg Verlag ist ein Unternehmen von Springer Science Business Media www vieweg de Das Werk einschlie lich aller seiner Teile ist urheberrechtlich gesch tzt Jede Verwertung au erhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzul ssig und strafbar Das gilt insbesondere f r Vervielf ltigungen bersetzungen Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen Konzeption und Layout des Umschlags Ulrike Weigel www CorporateDesignGroup de Umschlagbild Nina Faber de sign Wiesbaden Druck und buchbinderische Verarbeitung MercedesDruck Berlin Printed in Germany ISBN 10 3 8348 0162 3 ISBN 13 978 3 8348 0162 3 User Interface Architektur e Anleitung zur User Interface orientierten Softwarearchitek tur e Bauentwurfslehre f r durchdachte interaktive Software oberfl chen e Kompass f r die benutzerzentrierte Entwicklung dialogin tensiver Anwendungen e Leitfaden f r erlebbare und eindeutige User Interface Spezifi
144. endervertreter und der Spezifizierer hingegen betrachten das Produkt von au en und treffen Annahmen ber seinen inne ren Aufbau e Anwendervertreter interessieren sich f r die Oberfl cheninhalte und f r das Verhalten der Oberfl che e Das Augenmerk der Spezifizierer liegt auf den Interakti onen und den Regeln die das Verhalten der Oberfl che bestimmen e Im Fokus der Aufmerksamkeit der Programmierer liegt das Zusammenspiel der Interaktionen mit den Systemfunk tionen und mit dem Datenhaushalt der Anwendung Eine vollst ndige Sprache zur UlI Beschreibung muss daher den unterschiedlichen Sichtweisen dieser Zielgruppen bei der Model lierung einer Oberfl che gen gen Use Cases des UI Modellierens 123 e Anwendervertreter geben die dem Benutzer zugewandten UI Eigenschaften vor e Spezifizierer modellieren die UI Eigenschaften und UI internen Zusammenh nge e Programmierer modellieren die dem System zugewandten UI Aspekte Man kann zwischen Use Cases unterscheiden die sich auf UI Au ensicht und solchen die sich auf UI Innensicht beziehen Die UI Au ensicht umfasst UI Use Cases die sich auf Design Usability Ergonomie und Erleben des Anwenders richten Die UI Innensicht umfasst Use Cases die sich auf Informations strukturen Beziehungen Abh ngigkeiten Verflechtungen und Erleben des Entwicklers richten Bild 58 UI ER Au sensicht und UI ABA Innensicht I Anwender y Aussens
145. endungsbeschreibung sinnvoll erg nzen sie k nnen aber nicht von der Verwendungsbeschreibung losgel st erstellt oder verstanden werden Daraus folgt dass funktionale Spezifikationen und Modelle nach rangig zur Spezifikation des User Interface einer Softwareanwen dung sind Mensch und Software Beispiel f r User Interface Orientierung Platt gesagt Man kann zum Beispiel einen Fernseher nicht an hand seines Bauplans erkl ren sondern nur dar ber dass man das Fernsehen als T tigkeit beschreibt Im ausgeschalteten Zu stand sieht ein Computermonitor einem Fernsehger t ja nicht un hnlich Die Aufgabe den Fernseher anhand des Fernsehens zu be schreiben ist ein Beispiel f r das Wahrnehmen und Verstehen anhand der Verwendungsszenarien Wir wissen dass wir uns verschiedene Programme ansehen k nnen je nachdem welche Tasten wir auf der Fernbedienung dr cken Wir wissen auch wann was im Fernseher kommt sofern wir eine Fernsehzeitung lesen Wir k nnen einen Kanal ausw hlen und gucken Wenn das Antennenkabel eingesteckt ist aha Man kann die T tigkeit des Fernsehens nicht vermitteln indem man den Schaltplan des Fernsehger ts erkl rt oder beschreibt wie ein Fernsehstudio nebst Sender funktioniert Vielmehr muss man die Interaktionen an der Bedienerschnittstelle des ge dachten Anwendungssystems Fernsehen aufzeigen Um das Fernsehen zu definieren muss man also beschreiben wie man fernsieht Aus der Beschreibu
146. ener Sprache oder anderen Rezeptoren und Manifesto ren ausgestattet sein Es gibt Schritte die ohne Benutzerinteraktion auskommen Ma chine Steps und solche die mit einem Dialogbildschirm und oder mit einem Sprachdialog ausgestattet sind Diese Schrit te hei en Dialog Steps Sequence Step Dialog Modell Service Step Exitbehandl Dialog Modell Die obige Abbildung zeigt einen Sequence Step Kasten mit Spitze nach rechts und einen Service Step Kasten mit Spitze nach oben Die Rauten am linken und rechten Rand der Step Ausf hrungs modus Sequence Step und Service Step Modalit t Machine Step und Dialog Step Bild 41 Grafische Darstellung f r logische Schritte 96 Skizzieren Bild 42 Wichtigste Kennzeichen f r logische Schritte Logische Schritte als Service ausf hren Symbole repr sentieren die Enter und die Exitbehandlung der Steps Beide Steps sind Dialog Steps Das wird durch das Dialog symbol am unteren Rand des Step Symbols angezeigt Man kann diese Symbole beim Modellieren von Ablaufstrukturen verwenden Sie helfen dabei sich einen schnellen berblick ber den logischen Aufbau der Anwendung zu verschaffen und auf einen Blick Dialogschritte Sequenzen und Services zu identi fizieren Ein logischer Schritt hat verschiedene Kennzeichen die mitein ander kombiniert werden k nnen Die Kennzeichen bestimmen die Eigenschaften des Schritts in der modellierten Oberfl
147. enes 123 Bild 54 Einsatz einer UI Sprache f r praxis bliche Oberfl chen 126 Bild 55 Syntax Semantik Informations Modell een 126 Bild 56 Von einer Beschreibungshilfe zum MDA Werkzeug ene 127 Bild 57 Anwendungsfall Gruppen beim UI Modellieren e 128 Bild 58 Ul Au ensicht und UI Innensicht enenennnenennneennnnnenennn nn 130 Bild 59 Zust nde in einer State Ch tt oe 132 Bild 60 State Chart Zust nde mit Aktivit ten und Transitionen ee 133 Bild 61 Ausl ser Bedingung und Reaktion in einer Transition ee 133 Bild 62 Orthogonale Zust nde enenenneesenenensensenennennneennnenen 133 Bild 63 Flache und tiefe Historie nunenenneenenssenennnnesnnanen 134 Bild 64 State Chart f r einen Schalter nennsnnnennennenn 134 Bild 65 Kernentit ten eines Informationsmodells f r User Interfaces 143 Bild 66 Das Informationsmodell kapselt Notation und Laufzeitformat 144 Bild 67 Inhalte und Verflechtungen der UI Perspektiven nennenenen 145 Bild 68 Spezialisten interessieren sich f r unterschiedliche Softwareteile 147 Bild 69 berblick ber Objekttypen in Lucia sn a 148 Bild 70r Sprachstrukt r von TCi erara na 157 Abbildungsverzeichnis XIX Bild 71 Fehlende Integration der UI Modelle in der Architektur 174 Bild 7
148. ept steht Erst dann wird implementiert Das Vorgehen ist an der technischen Funktion der Software ori entiert e 1 Zielsetzung und Randbedingungen ermitteln e 2 Use Cases im technischen Kontext ermitteln e 3 Hauptabl ufe bestimmen e 4 Iterative Detaillierung der Use Cases und der Abl ufe Ausnahmebehandlung e 5a Fertigstellen und Abnahme des Fachkonzepts e 5b Entw rfe f r Bildschirmmasken fertig stellen e 6 Implementierung und Test der Software e 7 Nachbesserungen und Change Requests Das Projekt verl uft angespannt Der Kunde ist ber den Entwicklungsstand unsicher und f hlt sich au er Stand anhand der Konzeptpapiere zu pr fen ob die Lieferung der Beauftragung entspricht Beim Test wird festge stellt dass nicht eindeutig feststeht ob die gelieferte Anwen dungsoberfl che die im Konzept formulierten Anforderungen erf llt Es werden verschiedene nderungsanforderungen und Auftr ge formuliert die die Anforderungen an die Bedienung und die Oberfl che pr zisieren Das Projekt berschreitet den Zeitrahmen und das Budget erheblich Szenario 2 AlphaSoft amp AlphaRent Die Firma AlphaSoft erh lt von der Autovermietung AlphaRent den Auftrag eine Kundenverwaltung zu erstellen In Interviews werden zun chst der Einsatzzweck und die Ein satzszenarien Use Cases abgesteckt Dabei wird schnell er sichtlich dass die Kundenverwaltung Baustein einer gr eren L sung mit Bestellsystem und Fuhrparkverwaltung
149. er Repository Struktur Diese Spezifikationsform gibt die Dokumentationsform eine detaillierte Gliederung und formal strukturierende Regelungen f r die Spezifikationsinhalte vor Die Gliederung der Spezifikati on wird feink rnig herunter gebrochen und als Struktur in einem Repository bereitgestellt Die Struktur leitet den Spezifizierer beim Beschreiben der einzel nen UI Eigenschaften an Diese Form der UI Spezifikation wird typischerweise mit Werkzeugen wie Rochade oder Doors erstellt Bei zunehmender Regelung der Strukturinhalte geht die struktu rierte Beschreibung in ein formales UI Modell ber Formale Ul Modelle e Formale Spezifikationssprache e Verschiedene Sichten auf die Oberfl che Eine formale Spezifikationssprache liefert eine Notation zur for malisierten pr zisen Beschreibung einer Softwareoberfl che Das UI wird in einem in sich konsistenten und geschlossenen Modell beschrieben Mit Hilfe von Zusatzwerkzeugen kann die Einhaltung der Regeln der formalen Sprache und die Integrit t des Modells gepr ft werden In der Regel muss der Spezifizierer die Philosophie des Modellie rungswerkzeugs eine mehr oder weniger aufw ndige Modellie rungsnotation und verschiedene werkzeugspezifische Kniffe erlernen F r gew hnlich ist die Lernkurve beim Einsatz formaler Modellierungsmethoden steil Methodenwahl 87 Die Akzeptanz des formalen Modellierens eines User Interface h ngt ab von e den Erfahrungen bzw der
150. er eine genaue Verfahrensanleitung Weitere Anregungen zum Aufstellen eines projektspezifischen Modellierungsleitfadens liefert der Vergleich des Iterationsmo dells der User Interface orientierten Architektur mit den f nf Stufen des Produktionsprozesses f r Interaktive Web Software und f r Hypertext Websites von Jesse James Garret Nach Garret siehe auch http www jjg net elements pdf elements pdf hat das Web eine duale Verwendung als Software Interface und als Hypertext System Die von Khazaeli Khazaeli 2005 in Anlehnung an Garett be schriebenen f nf Produktionsstufen sind e Strategie Ziele der Anwendung bzw der Site Anforderungen der Benutzer e Scope Umfang Inhaltliche Anforderungen Funktionale Spezifikationen e Skeleton Ger st Interaktionsdesign im Sinne von Dialogfluss und von Navigationselementen Informationsarchitektur im Sinne der Strukturierung Gliederung und Vernetzung der Informationsknoten e Structure Struktur Informationsdesign Pr sentation von Informationen in m glichst verst ndlicher Form Navigationsdesign Elemente zum Navigieren durch die Informationsarchitektur Interface Design Bedienungselemente zur Unterst t zung der Interaktion zwischen Anwender und Anwen dungsfunktionalit t e Surface sinngem Oberfl chenbeschichtung Visuelles Design Grafische und visuelle Repr sentation der Bedienungselemente Navigationselemente und Texte
151. er ereignisge steuerten Programmierung finden Sie z B in Lauer 2002 S 22ff Historische Entwicklung der Softwareoberfl chen 31 Bei grafischen Oberfl chen verflochten sich Transaktionen mit den f r den Benutzer sichtbaren Steuerungs und R ckkopp lungselementen Auf Entwicklungsseite wurden die Werkzeug k sten der bisherigen Maskengeneratoren um grafische Kontroll elemente GCI Graphical Control Items und um Ereignisbe handlung erweitert Es wurden grafische SDKs Software Development Kits und GCLs Graphical Control Libraries ent wickelt Die Entwickler begannen Transaktionen und Transaktions teile an einzelne Kontrollelemente zu koppeln Die Transak tionen wurden feink rniger um die neuen Kontrollelemente mit Statusinformationen und Wertebereichen beliefern zu k nnen Zum Beispiel ben tigte man jetzt statt der Eingabe einer Artikel gruppe in einem Schl sselfeld eine Combobox mit Auswahl der Artikelgruppe und somit die neue Transaktion hole die Namen aller Artikelgruppen Es wurden immer vielseitigere Kontrollelemente entwickelt und ihre Interaktionen immer dichter an den Datenhaushalt der An wendungen gekoppelt Dabei umgingen die Entwickler gerne die hinderliche Transaktionsschicht Die so entstandenen An wendungen deren Hauptmerkmal eine hochinteraktive Benut zeroberfl che mit sehr feink rnigen Interaktionen ist werden als Fat Clients bezeichnet Trotz der hohen Komplexit t der in einer gra
152. erfl che beginnt Inhalte der User Interface Architektur 17 e Wie man Funktionen und deren Verwendung an der O berfl che skizziert e Wie man einen berblick ber die gesamte Breite der Anwendung gewinnt e Wie man bei den ersten Iterationen die berdetaillierte Beschreibung der Dialoge vermeidet Zum Skizzieren von Funktion und Oberfl che kann eine aus der UI Gliederung entwickelte Informationsstruktur und Beschrei bungsformalismen eingesetzt werden Am Beispiel der Kundenverwaltung werden wichtige Praxis schritte vorgestellt und ge bt e Bestimmen der Systemgrenzen und e Entwicklung des UI in Iterationen Die im Kapitel vorgestellten Vorgehensweisen sind vor allem in den fr hen Phasen eines Softwareprojekts Inception Elaborati on n tzlich Die einfache Beschreibungsstruktur f r User Inter faces hilft beim Aufsetzen einer robusten Systembeschreibung Kapitel 5 Detaillieren das den Weg von einem groben An wendungsger st bis zu einer vollst ndigen Spezifikation der Inhalte und des Verhaltens der Anwendung aufzeigt e Wie man in der Breite und in der Tiefe modelliert und man eine gleichm ige Tiefe beh lt e Wie man bewertet wie weit der UI Entwurf fortgeschritten ist e Wie man die Implementierungsreife der UI Beschreibung erreicht und erkennt Der Leitfaden f r die stufenweise Detaillierung der UI Beschreibung unterst tzt Sie beim iterativen Vorgehen Klare Kriterien f r die Inh
153. erung f r eine UI Beschreibung formen t N p l F y Anzeige amp N Er l N Bedienung 1 oe BR S Die obige Abbildung zeigt dass sich die Beschreibung eines User Interface in sechs verschiedene Themen gliedern l sst und dass die verschiedenen Themen einer Ul Beschreibung mitein ander zusammenh ngen Oberfl che gliedern 35 27 a Bild 16 2 gt Dialogelemente FR Informationsgeflecht d x s N einer UI ee RE F k er Fa Dre 4 eschreibung K Dialogschritte s iteraktonen T a I Forna Mi 7 H i I i penti BE po amp EUR 3 6 l F 5 Eo o n iO rrernnennnnnfannennenntt Fi s vi x e PP N Restriktionen _ 7 r P y a Die obige Abbildung zeigt das Informationsgeflecht das in der Themengliederung enthalten ist und in einer UI Beschreibung wiedergegeben wird Inhalte Dialogelemente Gegenstand der Anwendung Funktionalit t Ablaufsequenzen e Was beinhalten die Abl ufe und Inhalte der Anwendung aus fachlicher Sicht Standard Dialogabfolgen zuerst Normalf lle Inhalte von Dialogmasken zuerst Hauptelemente e Wodurch sind diese Abl ufe und Inhalte gekennzeichnet Varianz und Vermischung von Dialogabl ufen Maskenaufbau typische Anwender Interaktionen Struktur Dialogschritte Ablaufgliederung Anwendungsaufbau Ablaufzusammenh nge e Wie h ngen die Aktivit ten un
154. erungs und Visuali sierungswerkzeuge erzeugt werden Zum Beispiel k nnen die Prozesssteuerungstabellen in ein Fluss diagramm in yEd oder in ein UML Activity Diagramm f r MD Magic Draw UML transformiert werden Hilfreich ist dabei wenn das Zielwerkzeug ber automatische Layoutalgorithmen verf gt Nutzen 193 Anderenfalls ist die Transformation in einen Graph aufwendiger weil dann die Positionen der Knoten des Graphs und unter Um st nden auch der Kanten durch den Transformationsalgorithmus berechnet und in die Zieldatei mit ausgegeben werden m ssen Prinzipiell kann aus den Prozesssteuerungsdaten ein Prozessmo dell f r ein beliebiges Werkzeug erzeugt werden Auch die De taillierungstiefe des erzeugten Prozessmodells kann variiert wer den 9 5 Nutzen Die Prozessbeschreibung kann aus einem Prozessmodell in ein UI Modell bernommen werden Umgekehrt ist auch eine Ex traktion und Umformung der Ablaufinformationen aus dem UI Modell m glich Aus den im UI Modell vorhandenen Ablaufinformationen k nnen etwa Ablaufstrukturgraphen Workflowbeschreibungen und Steu erungsdaten f r Workflowmanagementsysteme extrahiert wer den Die Formulierung der Prozesslogik ist in der UI Sprache Lucia in Form von Interaktionen auf der Ebene von logischen Schritten enthalten N heres hierzu finden Sie im Kapitel Sprache Die Ermittlung und Bereitstellung von Statusmarken kann in der Ul orientierten Architektur als Teil de
155. esnsnns seen sseneenne denn enreene 1 1 1 Mensch und S ftwarernnnauaie ee Linn 1 1 2 ZIEISTUPPE RE RR Rn nme T 5 1 3 Nutzen der Ul orientierten Architektur ssesessessensneesnnesnnesnn nenn 6 1 4 Benutzeroberfl che in den Mittelpunkt r cken 8 1 5 Beispiel f r Ul orientiertes Entwickeln ennensennennn 11 1 6 Inhalte der User Interface Architektur eneneeeneeneenneeneennnnnnen 13 1 7 Lesen von UML Diagrammen uuurssssenerssnnnnerssnnnnessnnnnenssnnnnansennnnensnnnnn 21 1 8 Zusammenfassung aut rare is A E EE 24 Kapitel 2 Oberfl che ec scssssekssscstssesssisatssseness seosnnnnsecsssseknnsentene 27 2 1 Historische Entwicklung der Softwareoberfl chen neeee 29 2 2 Oberfl che gliedert sosire ninaa egei a A AET 33 2 3 U ser Interfaee ten 2 Ne i n e OREA 39 2 4 Funktionsweise einer Softwareoberfl che eneeneenneenneennen 42 2 5 Informationsgehalt des Ul u ussesenssessnesneennnennnennnennnenene nennen 50 2 6 Kontrollelementer ae lagen aebree nie 52 2 7 User Interface Logik ciens re Bun LI 54 2 8 Nutzen 13 rin RBB IIIRIN erinnern 56 Kapitel 3 Werkzeuge zsisissscsseessesnsensssessscssenss tessernessssensesnseersinenneen 57 3 1 Typische Ph nomene des UI Entwickelns enen 58 3 2 Anforderungen an Ul Werkzeuge eensessesseessnesseesnnesnnesnnesnnesn nennen 61 3 3 Bewertungsschemar sau an E ablehnen Mkdesshisl
156. et wann in welcher Test umgebung Wo werden die Testergebnisse dokumentiert Was wird mit den Testergebnissen gemacht Eine UI Beschreibung liefert keine expliziten Testszenarien Aber sie liefert den Aktionsraum daf r Wertebereiche Plausibili sierungen Verzweigungsm glichkeiten Reaktionen auf Einga ben Diese Information kann verwendet werden um Testszena rien automatisiert zu generieren die den oben genannten Akti onsraum pr fen ut Testen ist Probefahren nach Plan Bild 83 Mit UI Modellen sind einfache UI Tests automatisierbar 202 Testen Anhand der UI Modelle k nnen einfache Tests der Oberfl che automatisiert werden Aus der UI Spezifikation kann man Testf l le in der Art der im funktionalen Bereich blichen Unit Tests generieren 11 1 Arten von Ul Tests Man kann zwischen Tests der UI Erscheinung Text Layout Grafiken und Tests der UI Logik unterscheiden Das k nnten zum Beispiel die folgenden Tests sein e Einhaltung von Wertebereichen e Korrekte Reaktion auf diskrete im UI erwartete Eingabe werte e Korrekte Reaktion auf das Dr cken von Schaltern e Ausf hren von erwarteten Dialogseiten berg ngen Bild 84 _ ap Automatisierter Klassifikation von UI Test automatisierten Tests Test von Interaktionen Test von Werteingaben verwendet Wertebereiche Diskrete Werte Controls Screens F r das automatisierte Testen v
157. fe on Signal Ereignisse und andere Ereignisse verarbeiten in der Reihenfolge Control Dialog Step entlang der Vererbungshierarchie der Steps u Abarbeiten der on leave Freignisse des Screens 6 Abarbeiten der on leave Ereignisse des Steps Regeln In einer Step Schachtelung werden die geschachtelten Steps in Definitionsreihenfolge betreten Es werden zuerst die on Enter Interaktionen ausgef hrt Dann wird der Screen oder der VoiceDialog ausgef hrt falls der Step mit einem solchen assoziiert ist Zum Verst ndnis von on Signal Die Anwendung setzt immer dann ein Signal an die Ober fl che ab wenn es f r die Oberfl che etwas zu tun gibt Das Signal wird dann vom aktiven Punkt der Oberfl che gew rdigt also es werden Situationen gepr ft und gege benenfalls Reaktionen eingeleitet Das passiert in der Reihenfolge Element Elementgruppe Screen Step H lle Hierarchie der semiaktiven Steps Auf Anforderung kann jede Signal verarbeitende Stelle das Signal aufessen dann wird es nicht weiter nach oben propagiert Lucia Grammatik 157 Zum Verst ndnis von on Situation Das Situation Ereignis wird immer dann abgesetzt wenn sich eine Situation ndert Optimalerweise wird in der UI Ablaufmaschine nicht nach Situationen gepollt also nicht st ndig berpr ft ob sich vielleicht eine Situation ver ndert hat sondern der Kon texthandler setzt das Si
158. fehlern an der Oberfl che zum Beispiel falsch eingestellte Wertebereiche von Eingabefeldern vergessene Aus gaben verwendet werden Kommen Ihnen solche Peanuts die einen lange vorbereiteten Test wie ein Kartenhaus umwerfen k nnen bekannt vor Kleine eigentlich leicht zu behebende Oberfl chenfehler f hren oft genug dazu dass ein bereits angelaufener Fachtest abgebrochen werden muss Mit automatisierten Tests im Vorfeld des Testens von fachlichen Anwendungsszenarien durch Anwender kann die Qualit t der Oberfl che f r den Test erheblich gesteigert werden Automati sierte Oberfl chentests helfen beim Testen die wertvolle Arbeits zeit der Test und Fachspezialisten gezielt einzusetzen und Kos ten einzusparen Kapitel 12 Projektmanagement in dem UI Modelle in das organisatorische Regelwerk des Pro jekts integriert werden Kapitelziele e Klare Zust ndigkeit und Mitwirkungspflichten f r UI Modelle e Nachvollziehbare Checkpoints Schnittstellen und Synchro nisationspunkte zwischen den Projektrollen e Wissen wie man bei der Integration Ul orientierter Metho den in die Projektorganisation vorgeht e Risiken z B Kompetenz berschneidungen und Abschie ben von anderen Entwicklungsaufgaben auf die UI Modellierung erkennen und diese einschr nken Fast jeder f hlt sich kompetent bei der Benutzeroberfl che einer Software mitzureden und mitzugestalten aber fast niemand m chte das gesamte User Interface ve
159. fgaben kann folgenderma en aussehen Bedienkonzeptentwicklung Navigation u Bedienkonzept u PN 4 Styleguide Layoutregeln gt beinha N Anzeige und Bedienkonzept nteraktionsmuster gt entwickeln C Usability Funktionale Erscheinungsbild Adaptivitat adaptivit t Adaptivit t Personalisierung N m Benutzer N Benutzer einstellungen gewohnheiten S D Bedienkonzeptentwickler entwickeln Grundregeln f r die Hand habung der Software Bedienungsmetaphern Hierzu geh ren z B die Usability das UI Styleguide und Regeln f r die Anpass Rollen und Aufgabenteilung bei der UI Entwicklung 217 barkeit der Benutzeroberfl che zur Konfigurationszeit und zur Laufzeit Erscheinungsbildentwicklung Grafikdesign Die Ein und Ausgabe kann gleichzeitig ber GUI und Sprachkanal erfolgen Grafiker unter zt Ban er unterst tzt Sprach dialog enwickler Erscheinungsbild entwickler Kontrollemente gestalten Kontrollemente Erscheinungsbild parametrisieren entwickeln 7 Beispiellayouts Kontrollemente entwickeln einsetzen Layoutalgorithmen e Erscheinungsbildentwickler entwickeln wie die Software aus sieht und oder sich anh rt Hierzu geh rt z B das Grafikdesign oder allgemein gesagt das Look and Feel der Software Struktur und Verhaltensentwicklung Logik N Die Ein und A
160. fischen Oberfl che auftretenden Wechselwirkungen von Arbeitsabl ufen Darstel lung Eingaben und Transaktionen blieb die Methodik der UI Entwicklung zun chst ein Randthema Auch bei Fat Client GUIs wird die Entwicklung der Oberfl chen oft weiter als Abfallprodukt der Entwicklung von Funktionalit ten angesehen Von Fat Clients zu Thin Clients Die Anwendungsentwickler haben sich erfolgreich mit grafischen Oberfl chen und mit der Ereignisorientierung arrangiert Das Paradigma vom Aufsetzen der Oberfl che als Masken ber Funktionen und anwendungsinterne Abl ufe wurde beibehalten Durch die 1991 begonnene weltweite Verbreitung und kommer zielle Nutzung des WWW World Wide Web und damit der HTML Hyper Text Markup Language hat sich die Funktions und Bauweise von Softwareoberfl chen zun chst langsam und weitgehend unbemerkt abermals dramatisch ver ndert Anfangs diente die HTML zur standardisierten Darstellung wis senschaftlicher Texte Die Kommunikation zwischen UI Web Browser und Anwendungs Backend Web Server erfolgte zu Enge Kopplung zwischen Transaktionen und Kontrollelementen 32 Oberfl che Das Web zeigt die Grenze zwischen Oberfl che und Funktionalit t auf Das Web bricht Grenzen zwischen Anwendungen auf n chst nur auf Ebene der Web Seiten ber HTTP Hyper Text Transfer Protocol Die M glichkeit Anwendungen anzusteuern und damit dynamische Inhalte darzustellen kam sp ter d
161. fl chen und ein Leitfa den Gro teil einer den f r erlebbare und eindeutige User Interface Spezifikationen ware aus Das Buch beh lt Funktionalit t und Look and Feel der Software gleicherma en im Blick Der Fokus liegt auf dem Verstehen Planen und Umsetzen der f r das Verwenden der Software ge forderten Eigenschaften Der Unterschied zwischen User Interface Architektur und den ULArchitektur vielen auf dem Markt verf gbaren GUI Design Werkzeugen ist versus GUI Design die Fokussierung auf die Informationsarchitektur und auf das methodische Vorgehen GUI B cher stellen Regeln f r die Gestaltung von Oberfl chen auf Die User Interface Architektur geht hingegen auf den Infor mationsgehalt ein der zum Bau einer Oberfl che notwendig ist und darauf wie man diese Informationen formuliert d h mit welcher Notation in welchem Prozess und mit welchen Werk zeugen 26 Einf hrung UI Architektur von Die Unterschiede der User Interface orientierten Architektur zur der herk mmlichen herk mmlichen Softwareentwicklung sind Softwarearchitektur e Die Entwickler entwickeln das User Interface als eigenes differenzieren Artefakt Heute wird das UI nicht als eigenes Artefakt ver standen e Nach dem Ansatz der Ul Orientierung werden die funkti onalen Anforderungen aus den Ul Anforderungen heraus entwickelt Heute werden Ul Anforderungen nachrangig zu den funktionalen Anforderungen erhoben Das Einf hrungskapitel hat Ihnen einen
162. ftware sehen f r sie ist das die eigentliche Software Sie teilen den Entwicklern ihre Anforderungen an die Software ber ihre Vorstellung von dem Geschehen an der Bedienerschnittstelle mit Deshalb ist ein f r Kunde und Softwarehersteller gleicherma en verst ndlicher eindeutiger genauer und einvernehmlicher Bau plan der Oberfl che ausschlaggebend f r den Erfolg eines Soft wareprojektes Pl ne und technische Zeichnungen sind schon beim Bau von H usern Schiffen Automobilen und anderen Maschinen unab dingbar W hrend der Planungsphase werden Draufsichten Sei tenansichten perspektivische Ansichten und verschiedene Quer schnitte des Bauvorhabens erstellt Ohne sie w re die Beauftra gung Genehmigung und Durchf hrung des Bauvorhabens undenkbar Benutzeroberfl che in den Mittelpunkt r cken Gerade da wo es um die Nutzung des Bauvorhabens z B die Inneneinrichtung der B ro und Wohnr ume das Cockpit des Fahrzeugs oder das Bedienpult der Maschine geht sind zur Ab stimmung der Funktions und Verwendungsweise Modelle und Simulationen blich W hrend im H user Maschinen und Fahrzeugbau die Sicht des Nutzers meist im Mittelpunkt steht konzentriert sich z B die UML beim Softwarebau auf Querschnittsmodelle ber Funktio nen Datenhaushalt und innere Abl ufe Nicht selten wird die Oberfl che nur mit Hausmitteln wie Powerpoint Excel State Charts und Designprototypen umrissen und die Ausgestaltung der Details d
163. fusit t f hrt zu schlechter Formulier und Lesbarkeit der Notation und erh ht damit den Kommunikationsaufwand der am UI Entwurf und Design beteiligten Rollen Die Bewertung der Diffusit t erfolgt anhand der L nge und der Verwechselbarkeit der Notationskonstrukte Sind viele Notati onsworte f r eine Festlegung notwendig K nnen hnliche Kon strukte leicht miteinander verwechselt werden e 1 Punkt hnliche Notationselemente haben unterschiedli che Bedeutungen e 10 Elemente sind klar voneinander unterscheidbar Z higkeit Eine viskose UI Entwicklungsumgebung bedarf vieler Anwen deraktionen um ein Ziel zu erreichen Zum Beispiel kann das ndern aller Step Namen einer Ablauf struktur von Gro in Kleinschreibung das Anfassen eines jeden Steps bedeuten Editierumgebungen die passende Abstraktionen zum Beispiel Suchen und Ersetzen in allen Step Namen bereitstellen k nnen Viskosit t senken Die Viskosit tsbewertung erfolgt anhand des Aufwands zum ndern von Modellkonstrukten M gliche Leitfragen f r diese Bewertung sind Muss man das Modell an mehreren Stellen n dern um ein Element hinzuzuf gen oder zu entfernen Kann ein Teil eines Modells durch ein anderes Teil ersetzt werden Gehen beim Verschieben von Modellteilen Beziehungsinformationen verloren e 1 Punkt Bei nderungen der UI Beschreibung gehen Enti t ten und Relationen verloren Bewertungsschema 69 e 10 Punkte Die UI Beschreibung kann
164. g der UI Perspektiven in State Charts schlage ich die Einf hrung von je einer typisierten State Chart pro Perspekti ve sowie spezielle Relationen zur Bezugnahme auf die Elemente dieser spezialisierten State Charts Ein UI Modell besteht diesem Vorschlag nach aus e einer Anforderungen Chart e einer Ablaufstruktur Chart e einer Dialog Chart pro Screen Dialog e einer Interaktion Chart pro Screen Dialog e einer Interaktion Chart f r die Ablaufstruktur sowie aus Querverweisen zwischen den Elementen dieser ne beneinander liegenden Charts Der konkrete L sungsvorschlag ist hier das Aufteilen einer UI Spezifikation in die Teile e 1x Struktur Baum mit Ablaufschritten e n x Screen ein GUI f r einen Bildschirm oder ein Voice UI f r einen Sprachdialog und e 1x Kontext Ressourcen Informationen ber Umwelt dinge auf die Bezug genommen wird Die Interaktionen und Anforderungen k nnen in diese Bestand teile eingestreut sein oder orthogonal dazu in eigenen Teilen e Verzeichnis der Interaktionen und e Verzeichnis der Anforderungen liegen Die Anforderungsperspektive wird in der UI Spezifikation durch Anforderungsobjekte abgebildet Die Struktur Dialog und Interaktionsperspektiven werden durch Oberfl chenobjekte abgebildet Konzepte f r eine UI Beschreibungssprache 131 Die Kontextperspektive wird durch Kontext und Ressourcenob jekte abgebildet
165. gangssprachlich bis codierungsnah sowie von formlos bis algorithmisch e Umgangssprachliche UI Beschreibung e Tabellarische UI Beschreibung e Strukturierte UI Beschreibung e Formale UI Modelle e UI Prototypen mit HTML e Programmierte UI Prototypen Die Auswahl der Spezifikationsmethode kann zusammen mit der Wahl des UI Entwicklungswerkzeugs oder unabh ngig davon Methodenwahl 85 erfolgen Je formaler die gew hlte UI Beschreibungsmethode ist desto mehr tritt allerdings die Frage der Unterst tzung durch Werkzeuge in den Vordergrund Umgangssprachliche Ul Beschreibung e Umgangssprache e H ndische Maskenentw rfe e Benutzermodelle Es gibt nat rlich gute und schlechte beschreibende Spezifikatio nen Die nat rliche Sprache ist die f r Menschen verst ndlichste aber auch missverst ndlichste Form der Beschreibung einer An wendungsoberfl che Oft haben umgangssprachliche Spezifikationen die Form von Erleben des Erlebnisaufs tzen Der Verfasser beschreibt dabei seine Erwar Benutzers im tung an das Erleben der Anwendung beim Erledigen von Aufga Vordergrund ben Zu umgangssprachlichen Spezifikationen geh ren erg nzend so genannte Benutzermodelle bei denen ein Benutzer anhand von typischen Aufgaben und Verhaltensmustern beschrieben wird und so Anforderungen an Eigenschaften der Benutzerschnittstelle abgeleitet werden Andere umgangssprachliche Spezifikationen folgen einer vorge gebenen Gliederung zum Beispiel
166. gationsanweisungen an diesen zu senden Solche Navigationsanweisungen die der Testsequenzer verste hen sollte k nnen zum Beispiel NextField PreviousField oder NextDialog sein Der Aufwand f r das Erstellen eines Testsequenzers ist hoch jedoch die einzige M glichkeit das Testskript automatisch ablaufen zu lassen Eine weniger effektive Alternative ist das halbautomatische Tes ten der Oberfl che Dabei navigiert sich das Testskript nicht selbst durch die Oberfl che sondern gibt dem Anwender Navi gationsanweisungen Das Testskript weist die testende Person an zu einer bestimmten Dialogseite und zu einem bestimmten Feld zu navigieren und f hrt die Tests des Felds erst nach Best tigung seitens des Anwenders aus Das Navigieren zu einer bestimmten Dialogseite und zu einem bestimmten Kontrollelement auf dieser Seite kann durch eine Hintert r in der Oberfl chenimplementierung unterst tzt werden Beim UI Test muss das Eingabeger t bekannt sein 206 Testen Bild 86 Artefaktekette beim UI Test Modell Zum Beispiel kann die implementierte Oberfl che Testanweisun gen der Art GoTo lt Screenld gt lt Controlld gt unterst tzen Falls die Oberfl chenimplementierung eine solche Navigations hintert r bereitstellt kann das Testskript f r den Oberfl chentest ohne die Simulation der Navigation mit Eingabeger ten und ohne Navigationsanweisungen an den Anwender ausgef hrt werden Ohne
167. gen an Werkzeuge zur UI Entwicklung sind unabdingbar um zu bewerten was Spezifikations Imple mentierungs und Testwerkzeuge k nnen m ssen damit man mit ihnen User Interfaces entwickeln kann Halt werden Sie sagen Mit vorhandenen Werkzeugen kann man ja Anwendungsoberfl chen entwickeln Was ist denn daran nicht in Ordnung Eine berechtigte Frage auf die ich im Verlauf dieses Kapitels im Detail eingehe Die gew nschten Eigenschaften von Werkzeugen zum Erstellen von Benutzeroberfl chen k nnen in Anlehnung an Shneiderman Shneiderm 2002 S 209 wie folgt in einer groben bersicht zusammengestellt werden e Unabh ngigkeit des UI Trennung der UI Entwicklung von den inneren Eigen schaften M glichkeit verschiedener Strategien f r User Interfaces M glichkeit des Multiplattform Supports Etablieren der Rolle des UI Entwicklers Durchsetzen von Standards e Methodik und Notation Entwickeln von Design Prozeduren Wege ber das Design zu sprechen Schaffen von Projektmanagement f r das UI e Schnelle Entwicklung von Prototypen Fr hes Ausprobieren von Ideen Testen berarbeiten testen berarbeiten Beteiligung von Anwendern Managern und Kunden e Softwaresupport Steigern der Produktivit t Warum brauchen wir Anforderungen an Werkzeuge zur UI Entwicklung 62 Werkzeuge berpr fen der Grenzen und der Konsistenz Team orientierte Herangehensweise f rde
168. genschaften an verschiedenen Stellen und in verschiedenen Kombinationen wieder verwenden zu k nnen Diese Anforderung gilt sowohl f r zentrale Definitio nen als auch f r die im Kontext einer bestimmten UI Stelle fest gelegten UI Eigenschaften State Charts erm glichen lediglich eine hierarchische Vererbung von Transitionen Das wird durch Schachtelung von States inein ander ausgedr ckt Ein selektives Erben aus States die au erhalb der Schachtelung liegen wird in State Charts nicht unterst tzt Auch das Erweitern oder berschreiben von Eigenschaften aus beerbten States unterst tzen State Charts nicht Um das nichthierarchische Erben von Vorbildern zu erm gli chen m ssen State Charts erweitert werden Neben der hierar chischen Vererbung von Eigenschaften wird damit eine zweite Achse die orthogonale Vererbung mittels der basedOn Beziehung eingef hrt Generalisierte und spezialisierte UI Eigenschaften Hierarchische Vererbung und orthogonale Vererbung 132 Sprache Umweltschnittstelle mit Application Values und Function Requests Orthogonale Vererbung l st das Problem der Wiederverwendung von unterschiedlich kombinierten Grundeigenschaften Diese verschmelzende Vererbung l st das Problem dass die geerbten Eigenschaften ggf erg nzt oder berschrieben werden m ssen Hierzu wird in State Charts die Beziehungseigenschaft e basedOn lt state id gt eingef hrt Diese Beziehung b
169. gleitende Tests e Reduktion von Kommunikationsproblemen zwischen Au tomobilhersteller und Zulieferer bersicht der Features IAV Teledrive HMI Die Infotainment Markup Language IML definiert eine Be schreibungssprache f r die einheitliche Erstellung von XML Dateien f r das HMI eines Infotainmentsystems Sie enth lt die Strukturbeschreibungen f r den Aufbau und die Erstellung eines konkreten HMI und bildet au erdem die Grundlage f r die G l tigkeitspr fung der XML Dateien Die Features von IML sind e ein einheitliches Austauschformat f r die in einer Spezifi kation enthaltenen Informationen e die Spezifikation ist mit XML Werkzeugen in andere Ziel formate transformierbar e die Spezifikation ist maschinenlesbar e die Spezifikation ist mit einer g ltigen Formatbeschreibung unterlegt Darstellung auf Basis der Angaben des Herstellers mit freundlicher Genehmigung der IAV GmbH Berlin und eigener Tests Studio 78 Werkzeuge Layout und Verhaltensdefinition von Widgets werden in einem Definitionsteil festgelegt und in einem Implementationsteil mit konkreten Werten versehen Der Definitionsteil enth lt Definitio nen der ben tigten Elemente Zust nde und Eigenschaften eines Widgets Diese definierten Elemente Zust nde und Eigenschaf ten werden in dem Implementationsteil angewendet um das Widget Verhalten und Aussehen zu konkretisieren Dazu bietet die Struktur eines Widgets unterschiedliche M glichkei
170. gs und UI Entwurfs an Ich bezeichne diese Iteration Oberfl che der Ul Entwicklung in Anlehnung an RUP als UI Inception Konzeptualisierung der Softwareoberfl che Das Ergebnis der UI Inception ist ein Modell das als Grundlage f r alle weiteren Detaillierungen der UI Beschreibung dient Ich empfehle Ihnen daher die T tigkeiten der Konzeptualisierung gr ndlich durchzu f hren um sicherzustellen dass Sie beim sp teren Detaillieren des UI Entwurfs auf einen stabilen UI Umfang auf eine robuste Ablaufstruktur und auf zuverl ssige Dialoginhalte zur ckgreifen k nnen Die Merkmale einer soliden UI Inception k nnen nach folgenden Kriterien bewertet werden e Stabiler UI Umfang Klare Systemgrenzen siehe Abschnitt Systemgrenzen abstecken Abdeckung der Anwendungsf lle aller Anwenderrollen e Robuste Ablaufstruktur Gleichm ige Gliederungstiefe Keine berfl ssigen Gliederungsebenen Ablaufschritte geben in sich abgeschlossene Anwender t tigkeiten wieder e Zuverl ssige Dialoginhalte Dialogschritte haben ein definiertes Ergebnis Es ist definiert was pro Dialogseite eingegeben werden muss und was der Anwender sehen will Kerninhalte Nutzen der UI Skizzen 103 Mit einer soliden UI Skizze in Form eines Inception Modells vermeiden Sie dass bereits erstellte Teile des UI Entwurfs sp ter verworfen werden m ssen Sie verhindern damit auch wei e Flecken auf der Landkarte der Anwendung
171. halten Dabei treten gew hnlich Fragestellungen der Art Wie funktio niert alles zusammen Wie spezifiziere ich das oder Wie soll ich das programmieren auf Bei einer Anwendung der nichttrivialen Gr e so ab 50 Dialog seiten h ufen sich die Fragen nach Formulierbarkeit und Be herrschbarkeit der User Interface Definition ob als Code oder als Spezifikation Die Komplexit t einer User Interface Definition w chst schnell weil die Anzahl der m glichen Beziehungen und damit die Anzahl der gegebenenfalls zu beschreibenden Beziehungsregeln zwischen n UI Elementen mit dem Faktor n n 1 2 quadratisch w chst Die Formel gibt Anzahl der m g lichen direkten Kommunikationswege zwischen n Partnern bzw interaktiven Elementen an Die auftretenden Fragen betreffen in erster Linie e das Formulieren der Ablauflogik e das Wiederverwenden von Festlegungen e das Bezugnehmen auf Steuerungsdaten und e das Formulieren der Varianz l nder einstellungs und si tuationsspezifische Anpassung des Verhaltens und des Er scheinungsbilds der Oberfl che Im Folgenden bezeichne ich diese Fragestellungen als Stan dardprobleme oder typische Ph nomene der UI Entwicklung Typische Ph nomene des UI Entwickelns 59 Man kann die typischerweise beim Entwickeln einer gr eren Softwareoberfl che auftretenden Standardprobleme wie folgt klassifizieren e Formulieren der Ablaufbeschreibung Wie gliedert man die Abl
172. he Diese Aufteilung erm glicht eine grobe Gliederung f r eine O berfl chenbeschreibung die man zum Beispiel als Checkliste oder als Strukturierungshilfe nutzen kann Leitfragen zu einzel nen Aspekten einer Oberfl che versetzen Sie in die Lage ver schiedene Teile der Oberfl che voneinander zu unterscheiden und ihr Zusammenwirken zu verstehen Kapitel 3 Werkzeuge in dem einige auf dem Markt erh ltli che Werkzeuge zur Ul Modellierung und ihre Philosophien vor gestellt werden Wir verwenden die im vorhergehenden Kapitel aufgestellte Glie derung der Bestandteile einer Oberfl che um unterschiedliche UI Werkzeuge miteinander zu vergleichen Hinter den Werkzeu gen stehen auch verschiedene Philosophien wie die Werkzeug hersteller die Oberfl che in Bauabschnitte gliedern Der ber blick stellt verschiedene UI Werkzeuge vor zeigt Unterschiede und Gemeinsamkeiten in der Herangehensweise an die Oberfl chenmodellierung sowie Potentiale und Einschr nkungen der hinter den Werkzeugen stehenden Konzepte Das Kapitel enth lt auch eine Aufstellung der Anforderungen an UI Werkzeuge sowie ein Bewertungsschema f r die Bewertung von solchen Werkzeugen Diese Hilfsmittel sind zum Beispiel bei der Auswahl von UI Werkzeugen f r den Projekteinsatz n tzlich Kapitel 4 Skizzieren das sich der Antwort auf die Frage widmet wie man den Umfang und die Struktur der Anwendung absteckt e Wie man mit dem Entwurf der Anwendungsob
173. he Restrik tionen auf Eine Restriktion w re zum Beispiel inwiefern die Datenorganisation eine Kundensuche vor der Suche nach den Bestellungen dieser Kunden voraussetzt Suche ber Liste der Kunden Id s oder ob es reicht das Produkt und den Zeitraum als Suchkriterien anzugeben um alle Kunden die dieses Produkt bestellt haben zu finden Wenn die Datenstruktur nicht entsprechend optimiert ist kann sich die Identifikation von Kunden anhand von bestellten Pro dukten als ineffizient erweisen und die Oberfl che sollte anders aufgebaut oder die Datenorganisation modifiziert werden Die Entscheidung was ge ndert wird muss von den Verantwort lichen f r UI und Datenorganisation gemeinsam und unter Ab w gung des Aufwands und der Arbeitsweise des Anwenders getroffen werden 8 4 Funktions und Datenmodelle ableiten Beim Modellieren des Kontextes der Oberfl che wird die Erwar tungshaltung an das Vorliegen von Daten und Funktionen be schrieben Aus diesen Informationen kann ein Ger st f r das UML Klassenmodell erzeugt und anschlie end in einem UML Werkzeug weiter detailliert werden Beispiel Ableiten des Ger sts f r ein Klassenmodell aus dem UI Modell der Kundenverwaltung Si Kontaktliste Die Beziehung zwischen Ul Informationen und anwendungsin ternen Informationen kann mit Hilfe von Mapping Tabellen ab gebildet werden Beispiele f r Mapping Tabellen e Datenverwendung gt Datenstrukture
174. hmen Zudem sind die Anwender vom Ergebnis entt uscht das nicht dem Kon zept und damit nicht den Erwartungen entspricht Szenario 3 Ein IT Consultingteam wird mit der Erstellung einer Projekt vorstudie f r eine Software beauftragt die Kreditengangements unterst tzen soll Der Auftrag beinhaltet die Prozess und die Anforderungsanalyse sowie die Erstellung eines auf die Ergebnis se abgestimmten User Interface Prototypen Die Navigation und die Bildschirmmasken des Prototypen werden maschinell aus den Ablaufbeschreibungen und den Anforderungsdaten gene riert Kritische Projektentscheidung Der Kunde beauftragt die Umsetzung der Anwendung auf Basis des User Interface Prototypen in einer neuen Archi tektur Dazu merkt er an dass er einen geringen Aufwand erwartet da die Anwendung durch den ausgereiften Pro totypen so gut wie fast fertig sei Der mit der Umsetzung beauftragte Softwarehersteller verwirft den generativen Ansatz und erstellt eine zielplatt formspezifische Spezifikation der Ablaufsteuerung und der Bildschirmmasken Das Argument f r diese Entscheidung ist dass die im Pro totyp erlebbare Bedienung auf der Zielplattform nicht eins zu eins umsetzbar sei Folgen W hrend die Datenbasis des UI Prototypen vom Kunden weiter verfeinert wird findet die Realisierungsplanung auf Basis der Ergebnisdokumente der Studie statt Die Kon zeption und die Realisierungsplanung driften auseinander Die Entwickler sehen
175. ht die Messung des Entwicklungsfortschritts Durch klar festgelegte Iterationsumf nge wird der Fertigstel lungsgrad des User Interface einsch tzbar und der verbleibende Aufwand bleibt in allen Entwicklungsphasen planbar Wenn klar definiert ist was in einer Iteration modelliert werden soll und was nicht steht allen Beteiligten ein nachvollziehbarer Leitfaden f r ein geordnetes gemeinsames Vorgehen zur Verf gung So kann jeder Projektbeteiligte einsch tzen wo die UI Entwicklung steht und was der n chste Schritt ist einschlie lich der Klarheit dar ber wann die UI Spezifikation wirklich fertig ist Im Kapitel Detaillieren habe ich Ihnen eine Vorgehensweise f r das iterative Detaillieren einer Oberfl chenbeschreibung vorge stellt Das folgende Diagramm fasst die vorgestellten T tigkeiten und den Arbeitsfluss beim Detaillieren eines UI Modells zusam men UI elaborieren UI Elaboration Modell UI Construction Modell UI konstruieren UI transferieren UI Transition Modell Korrektur bedarf Fertigstellungsgrad messen Nutzen der UI Detailmodelle 117 Ziel des oben abgebildeten Leitfadens ist das Erreichen des Zu stands Implementierungsreifes Modell Die Aussage dass ein implementierungsreifes Modell vorliegt ist dann tragf hig wenn zwischen Spezifizierern und Programmierern Konsens dar ber besteht dass die UI Beschreibung exakt genug ist um ber die verb
176. ht zur Verf gung steht Unabh ngig von ihrem Erscheinungsbild das sehr unterschied lich sein kann findet man in den heute blichen Softwarean wendungen folgende Klassen von logischen Kontrollelemen ten Schaltfl chen e Pushbutton e Toggle Button Auswabhlfelder e Drop Down Liste e Men leiste e Kontextmen Einzelmen e List Box e Slider Schieberegler e Spincontrol Drehregler e Radio Auswahlfeld Gruppe e Optionsschaltfl che Ankreuzfeld Checkbox Text und Zahlen Ein und Ausgabe e Formatiertes Texteingabefeld Eingabeschablone e Combobox e Mehrzeilige Texteingabe Kontrollelemente Notifikationsfelder e Gauge Fortschrittsanzeiger e Statusanzeiger Strukturierungselemente e Groupbox Dialogabschnitt e Positionierungsraster e Statusleisten Akustische Ein und Ausgabe e Sounds e Sprachmen s e Spracheingabeempf nger Gestaltungselemente e Geometrische Formen z B Linien e Pixelgrafiken e Vektorgrafiken e Piktogramme Bewegte Bilder e Videosequenzen e Animationen Eine detaillierte Beschreibung der Funktion und des Einsatz zwecks der einzelnen Kontrollelemente von GUIs finden Sie z B in Wessel 2002 oder in Shneiderm 2002 Logische und physische Kontrollelemente Logische Bedienelemente sind aufz hlbar das hei t es gibt eine Logische begrenzte Anzahl davon Die obige Aufz hlung zeigt die in heu Bedienelemente tigen Oberfl chen blichen logischen Kontrollelemen
177. i on eines Softwareprojekts auf der Auftragsebene leistet wird auf der Ebene der Entwicklungsorganisation und technik von den Architekten geleistet Die Softwarearchitektur stellt den organisatorischen Rahmen und das technische Regelwerk f r das Entwicklungsteam auf Die Softwarearchitektur teilt eine Software in Komponenten auf Sie bestimmt den Zuschnitt die Aufgabenteilung und die Zusammenwirkung der Softwarekomponenten in der Laufzeit umgebung Zur Softwarearchitektur geh rt auch die Organisation und Verwaltung der Quellartefakte in der Entwicklungsumge bung Die Informationsarchitektur bezeichnet die Kombination aus Strukturierung von Wissen Organisation von Daten und Benut zerinteraktionen zum Zugriff auf diese Informationen Zu den Aufgaben eines Informationsarchitekten geh rt der Aufbau von Informationsmodellen sowie von Repr sentationsformen f r das Auffinden und Verwenden z B gruppieren navigieren ver kn pfen indizieren von den im Informationsmodell gespeicher ten Informationen 7 1 Integration in die Entwicklungsumgebung Die Architektur ist eine gro e Klammer um die Bestandteile der Anwendung die Entwicklungswerkzeuge und die Entwicklungs technik Was innerhalb der Architektur ber cksichtigt und gere gelt ist gilt als architekturkonform und damit als technisch legal Alles andere wird als Wildwuchs von der technischen Leitung des Entwicklungsteams mehr oder minder rigoros abgelehnt Im Technisches
178. ianten Mandanten Zulieferer Oberfl che gliedern 37 e Wie werden mandanten und versionsabh ngige Varianten und Abweichungen der Anwendungsabl ufe und deren Inhalte verwaltet L nder und Sprachabh ngige Ressourcen Rollenspezifische Unterschiede in UI Elementen Mandantenspezifische Ressourcen in UI Elementen Ul Erwartungsanalyse Beim Bedienen einer interaktiven Softwareanwendung beobach tet der Anwender das an der Oberfl che wahrnehmbare System verhalten und trifft auf dieser Basis Annahmen ber das Funktio nieren der Anwendung Der Anwender trifft diese Annahmen auf Grund seiner Erfahrun gen mit dem Bedienen von Maschinen und anderen Software anwendungen Um den Entwurf einer Oberfl che weiter zu pr zisieren kann der Entwickler bzw der Analytiker zus tzliche Fragen ber Er wartungen des Benutzers an das Bedienen der Software stellen Diese Fragen kann man wie folgt gruppieren I 23 gt Reaktionserwartung Aktionserwartung gt Konvergenzerwartung gt Erfahrungserwartung gt Funktionserwartung Aktionserwartung e Anwendersicht Was muss ich als Anwender machen damit die Anwendung etwas macht e Oberfl chensicht Oberfl che wartet auf Ereignisse die sie interpretieren kann e Entwicklersicht ber welche Eingabeelemente empf ngt die Anwendung bzw ihre Oberfl che Anweisungen des Benutzers Bild 17 Erwartungen des Anwenders und der Oberfl ch
179. icht un LER v Ergonomie Y Benutzer modelle User Interface nformations A A Abh ngig strukturen keiten stt e u Q A a ra td Innensicht A a b f Entwickler Die beiden UI Sichten haben unterschiedliche Ausdrucksformen Die UT Architektur Die UI Au ensicht wird mit kognitiven Modellen durch Grafik geht auf die UI design und Usability Analysen behandelt Innensicht ein In der Ul orientierten Architektur geht es vorrangig um das Zu sammenspiel der verschiedenen Perspektiven auf die UI 124 Sprache Innensicht Die Sprache zum Beschreiben von User Interfaces stellt also Ausdrucksmittel zum Beschreiben der Innensicht der Sicht des UI Konstrukteurs auf ein User Interface aus dem Blickwinkel verschiedener UI Perspektiven UI Perspektiven l sen das Problem wie man beim Spezifizieren die Abh ngigkeiten zwischen e Anforderungen e Ablaufstruktur e der wahrnehmbarer Erscheinung von Dialogseiten e dem Verhalten e dem Kontext e und den Restriktionen einer Softwareoberfl che in gegenseitiger Verkn pfung be schreibt Mit den UI Perspektiven steht ein Modell f r das Ord nen und das Verkn pfen dieser Informationen zur Verf gung Somit bieten sich UI Perspektiven auch als eine Gliederung f r eine Ul Beschreibungssprache an Oberfl che Beim Entwickeln einer Softwareoberfl che sind zeitlich parallel schrittwei
180. icht referenziert werden F r eine Auswahlliste sofort festlegen ob sie ber eine Drop Down Liste oder ber eine Men tafel realisiert wird Provisionalit t erlaubt unvollst ndiges Spezifizieren Standard Annahmen zu unspezifizierten Inhalten und sp tere Konkretisie rung wenn n tig Die Bewertung der Provisionalit t erfolgt anhand der Striktheit der Notation Das kann anhand folgender Leitfragen bewertet werden K nnen Teile von Notationskonstrukten zun chst weg gelassen werden Kann das UI von einer groben Skizze an stu fenweise zu den Details hin spezifiziert werden e 1 Punkt Der UI Editor l sst keine Auslassungen von Ei genschaften und keine vorl ufigen Definitionen zu Struktur Toleranz von Spezifikations Auslassungen 68 Werkzeuge e 10 Punkte Notation erlaubt unvollst ndige und vorl ufige Konstrukte die nach und nach exakter ausformuliert wer den k nnen Klarheit M glichst knappe Neigt eine Notation zu verschiedenen Beschreibungskonstrukten leicht voneinander zu unterscheidende Formen Die Spezifikation soll schnell und einfach zu ndern sein f r die gleiche Sache nimmt sie auf dem Bildschirm unverh lt nism ig viel Platz f r einfache Informationen in Anspruch oder benutzt sie lange umst ndliche und leicht zu verwechselnde Konstrukte dann hat sie eine hohe Diffusit t Es hei t nichts anderes als dass die eigentliche Information in der Beschreibung verstreut ist Hohe Dif
181. iel einer Kundenverwaltung e 95 Bild 30 IDEFO Activity Box sienai Ee oe AEE a LEE ea EEE S Ei 96 Bild 37 Aktivit ten verketten n as ndenenseneena aaa 97 Bild 38 Dekomposition und Border Lines ensessesessnennensnennennennennnnn 97 Bild 39 Prozessgliederung Dialogfluss und Dialogseiten een 99 Bild 40 Struktur der logischen Schritte in der Kundenverwaltung 101 Bild 41 Grafische Darstellung f r logische Schritte enenenennenn 102 Bild 42 Wichtigste Kennzeichen f r logische Schritte enenenenn 103 Bild 43 Aktiver Schritt und hierarchisch semi aktive Schritte 105 Bild 44 Aktiver Schritt und orthogonal semi aktive Schritte 106 Bild 45 Vorgehenskarte f r das Skizzieren der Oberfl che nee 109 Bild 46 User Interfaces werden schrittweise entwickelt 111 Bild 47 Verschiedene Sichten auf die Oberfl che nenenesen 113 Bild 48 UI evolution r aus wechselnden Perspektiven entwickeln 115 Bild 49 Rational Uniled Process nannte naeh eo 116 Bild 50 UI Inception Elaboration Construction Transition eeneneen 116 Bild 51 Iterationsmodell f r die UI Entwicklung eeneneneennennen 117 Bild 52 Leitfaden f r das Detaillieren der UI Beschreibung e 123 Bild 53 Ablauf einer Ul Iteration 0 un enseensasssnennnnsnann
182. ienbarkeit orientierte Bauweisen weitgehend und m ssen erst m hsam gefunden werden Einmal gefunden sollten sie durch bernahme der Oberfl che in die n chste technologi sche Umsetzungsplattform bewahrt bleiben Das UI Modell ist nur insofern Bestandteil der Software als dass es in der Software technisch umgesetzt wird Ansonsten ist es eine von der Software unabh ngige virtuelle Verfahrens und Verwendungsvorschrift Kontinuit t bei UI Entwicklung hilft Bew hrtes zu bewahren 228 Lebenszyklusmanagement Generativer Ansatz schafft neue M glichkeiten F r den Anwender ist die Softwareoberfl che identisch mit dem Softwareprodukt Er verl sst sich auf das Produkt und beurteilt es anhand der bew hrten Eigenschaften der Oberfl che Die technologische Neuumsetzung wird aber von Entwicklern durchgef hrt die meist nicht mit der Altanwendung produktiv gearbeitet haben und wahrscheinlich auch nicht mit dem Folge system arbeiten werden Daher wird die Bedeutung der Kontinu it t in Verhalten und Bedienung der Anwendung von Entwick lern nur selten wahrgenommen F r die Entwickler stehen natur gem die neue Technologie und deren M glichkeiten im Vordergrund UI Modelle liefern eine entscheidende Hilfestellung um beide Sichten zu vereinen und beantworten die oben formulierten Fragen Ein UI Modell ist ein technologie und plattformunab h ngiges Schema in dem eindeutig beschrieben ist wie die spe zielle Be
183. ient und nicht als Abladehalde f r unbequeme Fragestel lungen der Entwicklung benutzt wird So wird wiederum vermieden dass das UI Modell von den Ent wicklern auf ein Abstellgleis gestellt wird Ein so aufeinander abgestimmtes und koordiniertes Vorgehen kann helfen Entwicklungslaufzeiten erheblich zu verk rzen und ein stabiles erwartungskonformes Projektergebnis sichern Kapitel 13 Lebenszyklusmanagement in dem plattformunabh ngige User Interface Modelle die Wie derverwendung und kontinuierliche Weiterentwicklung von be w hrten Oberfl chen erm glichen Kapitelziele e Oberfl chen nicht immer wieder wegwerfen und neu ent wickeln sondern kontinuierlich fortentwickeln e Bei Technologiewechsel und bei Reengineering Qualit t der Oberfl che auf Basis bew hrter Eigenschaften weiter entwickeln e Neuentwicklungskosten senken Investitionswert erhalten Im Laufe der Zeit k nnen aus hilfreichen Anwendungen vor allem im Verwaltungsbereich durch gewachsene Erweiterungen und durch so genannte Papierschnittstellen Instrumente der Sys tembefriedigung werden Bei so wild gewachsenen Anwendun gen k nnen die Anwender nicht mehr den Nutzen f r ihre t gli che Arbeit und f r das Unternehmen erkennen Lebenszyklusmanagement kann helfen solche Fehlentwicklun gen zu vermeiden Das Risiko von Softwarebausteinen die an Fachprozessen vorbei arbeiten und das Risiko von technologi schen Sackgassen sollen dabei minimie
184. ierte Werkzeuge Dazu z hlen Werkzeuge bei denen die grafische Gestaltung und Animation also die Form des User Interface im Vordergrund steht Beispiele Flash SVG Scalable Vector Graphics XHTML Darstellungsorientierte Werkzeuge werden von Grafikdesignern bevorzugt und meist dazu eingesetzt die grafische Gestaltung von Dialogseiten festzulegen Beim Arbeiten mit darstellungsorientierten Werkzeugen wird zun chst die grafische Erscheinung von Bedienelementen und das Layout der Dialogseite festgelegt bevor eventuelle Interakti onen hinzugef gt werden 3 7 GUl Toolkits und GUl Bibliotheken Es gibt eine Reihe von GUI Toolkits mit denen Screendesign m glich ist Viele Entwicklungswerkzeuge etwa Net Visual Stu dio oder Delphi beinhalten eigene Screen Editoren mit denen Bildschirmmasken aus dem Vorrat von Kontrollelementen zu sammengeklickt werden k nnen GUI Bibliotheken APIs sind Funktionssammlungen die dem Programmierer das Codieren von grafischen Benutzeroberfl chen erlauben PC typische GUI Toolkits bzw GUI Bibliotheken sind XWin dows Windows SDK Motif SDK GTK und MacOS Eine detail lierte Beschreibung der typischen Bestandteile eines GUI Toolkits finden Sie z B in Lauer 2002 S 56 76 Es gibt kaum GUI Tookkits die ber das Screendesign hinausge hen und beispielsweise die Modellierung des Verhaltens der Oberfl che erm glichen Ebenso selten sind GUI Toolkits mit denen eigene Kontrollelement
185. ierten MVC Entwurfsmusters In Ceri 2003 wird im Detail beschrieben wie die Modell View Controller Architektur auf Webanwendungen adaptiert wird und Das MVC Entwurfsmuster 167 wie das Entwurfsmuster mit einer Modellierungssprache f r da tenintensive Web Applikationen verkn pft werden kann MVC in der Ul orientierten Architektur Im Zusammenhang mit der User Interface Architektur ist das Verkn pfen des MVC Entwurfsmusters mit User Interface Modellen von Interesse f r die automatisierte Code Erzeugung Wenn m glich soll aus einem UI Modell der Code f r View und Controller sowie die Mapping Schicht zwischen Controller und Model funktionale Schicht mit Datenhaushalt und Business Logik generiert werden k nnen Das MVC Entwurfmuster unterteilt die Anwendung in drei Auf gabenbereiche e Modell die eigentliche Funktionalit t und Datenhaushalt e View die Pr sentation der Daten an der Oberfl che und e Controller die Vermittlungsschicht zwischen View und Modell Die g ngigen Methoden und Vorgehensweisen der Systemmodel lierung z B UML detaillieren den Modell Anteil der Anwen dung UI Modelle detaillieren den View und den Controller Anteil der Anwendung als Verbund Modell Funktionen Daten Interne Abl ufe Controller View seh Schritte Kontext Interaktionen Elemente Bei nicht Ul orientierten Arch
186. ieses Inception Modells k nnen erste Klassenmodelle und vertikale Durchstiche im Kontext der Anwendungsbreite und der System grenzen erstellt werden Die Kenntnis des Kontextes senkt das Risiko dass Anforderun gen an die Funktionalit t hinsichtlich ihrer Nutzung falsch einge sch tzt werden und wesentliche Anforderungsteile bersehen werden Ebenso wird durch den Kontext vermieden in Funktio nen Anforderungen hineinzuinterpretieren die sich aus der Ver wendung an der Oberfl che nicht ergeben UI berblicksmodelle schaffen ein geschlossenes Bild der An wendung und tragen so entscheidend dazu bei dass von Anfang an ein gemeinsames Verst ndnis der Anforderungen und des Aufbaus der Software geformt wird Im Kapitel Skizzieren habe ich Ihnen eine Vorgehensweise f r das Skizzieren einer Anwendungsoberfl che vorgestellt Das folgende Diagramm fasst die vorgestellten T tigkeiten und den Arbeitsfluss beim Skizzieren einer Anwendungsoberfl che zu sammen 102 Skizzieren Beschreibungs Gew hlte Form gt z gt I Formen form w hlen der UI Beschreibung Systemgrenzen Kernanwendungsf lle gt UI Umfang Logische Schritte gliedern ul Inception Modell Ablaufstruktur Dialoginhalte abgrenzen Korrekturen Kerninhalte der Dialoge Bild 45 V rgehenskarte f r Das obige Vorgehensschema leitet Sie in der ersten Phase des das Skizzieren der Anwendun
187. ikation von Oberfl chen State Charts Editoren werden oft in Werkzeugen zur formalen UI Modellierung integriert DSL Editoren zur Modellierung von UI Abl ufen haben meist das Metamodell der State Charts als Basis Auch in integrierten Werkzeugen f r eingebettete Systeme sind State Charts ein typischer Bestandteil der UIEU 3 9 Werkzeuge f r eingebettete Systeme Im Folgenden werden zwei Werkzeuge vorgestellt die die ge samte Oberfl che im Blickwinkel der Modellierung behalten Sie unterscheiden sich in Komplexit t Philosophie und Bedienung grundlegend von den blichen Maskeneditoren Beide Werkzeuge bringen einen jeweils eigenen Modellierungs ansatz mit mit dem ein Gesamtmodell eines UI erstellt zur Mo Werkzeuge f r eingebettete Systeme 73 dellierungszeit simuliert und Code f r die Zielplattform erzeugt werden kann Bild 29 Durchg ngige UI Werkzeuge haben eigene Philosophien eg Gg Das origin re Einsatzgebiet dieser Werkzeuge liegt in der Ent wicklung von Software f r eingebettete Systeme in Fahrzeugen Moderne Infotainmentsysteme der Automobilindustrie zeichnen sich durch die Integration verschiedener Ger te Radio CD CD Wechsler MP3 DVD TV Navigation Verkehrsinformationen Telefon etc in einem User Interface aus Dabei spielen ein durchg ngiges Bedienkonzept und Erscheinungsbild Benutzer oberfl che eine entscheidende Rolle Die Kurzanalyse der Werkzeuge zeigt die Bandbreite der
188. il das Prozessregelwerk nun beinahe beliebige Ver nderungen an der Ablaufsteuerung ohne nde rungen am Programmcode erm glicht Denkbar ist dass der Kunde das Prozesslogik Regelwerk selbst als Bestandteil der Anwendung pflegen und so Aufw nde f r zuk nftige Anpassung sparen m chte Ablaufsteuerungsdaten extrahieren 189 Allerdings rate ich davon ab das durchaus komplexe Regelwerk in der Fachabteilung zu pflegen oder die Regeln mal eben kurz im Produktivsystem zu ndern Zirkul re Regeln k nnen zum Stillstand der Anwendung und zu anderen sehr unerw nschten Resultaten f hren Das Werkzeug der Prozesslogik ist ein m chtiges Instrument zur Steuerung der Bearbeitungsfl sse im UI und in der funktionalen Schicht Es ist aber auch m chtig komplex und sollte daher in der Entwicklungsumgebung wie Quellcode behandelt werden Das Formulieren von Prozesslogik liegt innerhalb eines UI Modells nahe am Programmieren weil sich aus der Prozesslogik im Prinzip eine Sequenz von Anweisungen der Form if expres sion then reactions ergibt Die Bereitstellung der Prozesslogik f r die Verwendung in der Entwicklungsumgebung kann in einem beliebigen Format erfol gen Die in der Ul Beschreibung aufgestellten Workflow Steuerungsregeln lassen sich z B in eine Transitionstabelle der folgenden Form umformen Tabelle 1 step id signal type situation idref transition list parentstep idref idolstep idref
189. in T tigkeitswort z B Artikel w hlen ausgedr ckt e Von links werden in die Aktivit t die Eingangsinformatio nen eingespeist e Von oben und unten wird die Aktivit t mit Regeln durch f hrenden Personen Rolle und Mechanismen Werkzeu ge Systeme versorgt e Nach rechts gehen aus der Aktivit t Ergebnisse hervor Aktivit t Steuerinformationen Al Rostoff 1 Aktivit t 2 Aktivit t 3 Produkt Systemgrenzen abstecken 91 Die Datenfl sse verketten Aktivit ten zu Prozessen Das Ergebnis einer Aktivit t kann als Eingangsinformation oder als Regel f r andere Aktivit ten dienen Man kann die Eingangsgr e der ersten Aktivit t als Rohstoff den die Software verarbeitet und die Ausgangsgr e der letzten Aktivit t als Produkt das die An wendung der Software liefert sehen Nach den Regeln von IDEFO sollte ein Diagramm aus mindestens drei h chstens aber aus sechs Aktivit ten bestehen F r die ein zelnen Aktivit ten des Diagramms wird auf der n chsten Detail lierungsstufe jeweils ein eigenes Diagramm erstellt Input Al gt Output 4 Border Lines kennzeichnen Eingangs Ausgangs und Regelgr en welche die Grenzen des Diagramms und beim Diagramm der obersten Abstraktionsstufe die Systemgrenzen berschreiten Gehen Sie wie folgt vor um IDEF0 hnliche Aktivit tsdiagramme f r Ihre Anwendung zu erstellen e Die IDEFO Activity Box
190. ine organisieren Kundenkontakte verwalten Grafiken und Texte erstellen Was wir als Anwender von einer Anwendungssoftware wahr nehmen k nnen ist ausschlie lich ihre Benutzerschnittstelle Die so genannte Softwareoberfl che oder das User Interface Wenn wir ber eine Software sprechen sprechen wir dar ber was wir wahrnehmen sehen h ren etc und tun k nnen Kn pfe dr cken Men punkte w hlen Daten eingeben etc also eben ber die Oberfl che der Software F r Anwender ist Software nur das was sie wahrnehmen und steuern k nnen Software soll die vielf ltigen Funktionen des Computers f r Men schen erschlie en und leichter verwendbar machen Durch ihre Oberfl che wird Software anfassbar und begreifbar Hingegen ist f r die Nutzer eines Computerprogramms oder eines anderen vielseitigen Werkzeugs dessen innerer Aufbau meist nur am Rande wichtig Sie interessieren sich haupts chlich daf r ob das F r Anwender ist die Oberfl che die Software Bild 1 Software macht Computer f r Menschen verwendbar Einf hrung Funktionale Beschreibungen erg nzen Beschreibungen der Verwendung Bild 2 Software anhand der Verwendens der Oberfl che verstehen Beschreibung des User Interface hat Vorrang vor funktionalen Spezifikationen Ding gut in der Hand liegt und seinen Zweck gut erf llt Bei Software interessiert den Anwender die Oberfl che bei Fahrzeu gen das Fahrerlebnis bei Maschinen
191. inen Bearbeitungsfluss von den Ein gangsinformationen zu den Zielergebnissen der Software Kunden Kunden suchen Kundenliste Selektierte Kundenkarte ansehen Kundenkarte gt pflegen ge ndert Kundenkarte i l schen gel scht Kundenkarte a Kundenkarte Kundenkarte Kontaktdaten Finden der Eingangsdaten der Ergebnisse und der Hauptschritte der Anwendung Kunden kartei Bestellungen abwickeln verwenden S Kontaktliste Kundenkarte anlegen AA angelegt Die abgerundeten Vierecke zeigen die oberste Ebene der An wenderaktivit ten Die von links in die Aktivit ten m ndenden Pfeile repr sentieren Eingangsinformationen Die rechts aus den Aktivit ten herausgehenden Pfeile repr sentieren Ergebnisse Die durch einen Pfeil transportierten Informationen kann man direkt an den Pfeil schreiben oder in einen rechteckigen Kasten einfassen Ein Pfeil der in der obigen Abbildung zwei Aktivit ten miteinan der verbindet bedeutet dass das Ergebnis einer Aktivit t in einer anderen Aktivit t als Eingangsgr e verwendet wird Die senkrechten Balken zeigen die Grenzen der Anwendung an IDEFO mit UML Aktivit tsdiagrammen Die IDEFO Diagramme sind eine Weiterentwicklung von SADT Structured Analysis and Design Technique und wurden ur Kundenkarte Mailings organisieren Bild 35 Sysiemgrenzen am Beispiel einer Kundenverw
192. it In den Verwendungsszenarien des UI sind L cken die nicht umgangen werden k nnen Die den L cken nachgelagerten UI Eigenschaften k nnen damit nicht ausprobiert werden e Priorit t 3 Arbeitsbehinderung mit Umgehungsm glich keit In den Verwendungsszenarien des UI sind L cken welche aber z B durch trickreiches Anwenden anderer UI Features umgangen werden k nnen Somit kann das betreffende UI Feature bzw Verwendungsszenario auf Umwegen erprobt werden Zu dieser Kategorie z hlen Grad der Fertigstellung Klassifizieren von UI Issues 116 Detaillieren Bild 52 Leitfaden f r das Detaillieren der UI Beschreibung UI Inception Modell auch irref hrende Anleitungen und sachlich falsche Be schriftungen von Eingabefeldern e Priorit t 4 Sch nheitsfehler UI Fehler die das Verwen dungsszenario nicht beintr chtigen z B Rechtschreibfeh ler Grafikfehler Aussprachefehler und Fehler im Layout von Dialogseiten e Priorit t 5 Verbesserungsw nsche Gew nschte UIl Eigenschaften die ber die f r das Projekt festgelegten Verwendungsszenarien hinausgehen Anhand des obigen Bewertungsschemas kann f r das konkrete Projekt ein nachvollziehbares Regelwerk zur qualitativen Absi cherung der User Interface Entwicklung aufgebaut werden 5 4 Nutzen der Ul Detailmodelle Die iterative Detaillierung der UI Beschreibung liefert ein ge schlossenes Bild der Anwendung und erm glic
193. it weder eine aktive noch eine passive Rolle Betreten und Verlassen logischer Schritte Die Aktionen beim Betreten eines Schritts werden als Enter Behandlung bezeichnet Analog dazu hei en die Aktionen beim Verlassen des Schritts Exit Behandlung Bei Ausf hren eines zusammengesetzten Schritts siehe oben werden also die Startaktionen Enter Behandlung durchgef hrt und dann der erste untergeordnete Schritt aktiviert Diese Proze dur wird wiederholt bis ein elementarer also nicht zusammen gesetzter Schritt erreicht ist In einem elementaren Schritt folgt auf die Enter Behandlung das Durchf hren von Aufgaben z B das Ausf hren einer Dialogseite und zum Schluss die Exit Behandlung Nach dem Ende der Exit Behandlung wird die Kon trolle an den hierarchisch bergeordneten Schritt zur ckgegeben Man kann sich die Kontrolle dieser Aktivit tshierarchie wie einen Stapel aus begonnenen Schritten vorstellen Auf dem unteren Ende des Stapels liegt der hierarchisch h chste allen anderen bergeordnete Schritt UI der Anwendung ausf hren auf dem oberen Ende des Stapels befindet sich der aktive Schritt Alle unter dem aktiven Schritt auf dem Stapel liegenden Schritte sind passiv oder semi aktiv d h sie warten auf ihre Reaktivierung nach dem Ende der weiter oben auf dem Stapel liegenden Schrit te Mit dem vollst ndigen Abbauen des Aktivit tsstapels wird der hierarchisch h chste Step UI der Anwendung ausf
194. itekturen sind Controller die auf w ndigsten Teile der Anwendung und besonders nderungsan f llig Selbst kleinere nderungen an der Oberfl che z B das Verschieben eines Eingabefeldes von einem Bildschirm in einen anderen kann zu aufw ndigen nderungen in der Controller schicht f hren siehe auch Lauer 2002 S 29f Die Benutzerschnittstelle ist der Teil der Anwendung der Funk tionen und Daten verwendet Um die Verwendung zu steuern Bild 74 MVC und Zuordnung von Entwicklungs Themen 168 Architektur Kontexthandler UT Anteil in Dialogintensiven Anwendungen werden an der Oberfl che Informationen ber den Kontext zum Beispiel Welche Funktionen stehen zur Verf gung Wo im Be arbeitungsfluss befindet sich der Anwender Welche Daten liegen bereits vor welche fehlen noch ben tigt Dieser Blickwinkel erm glicht ein differenzierteres Bild der Auf gaben eines Controllers Die Aufteilung der Controllerfunktionen in Schrittesteuerung Kontextermittlung und Interaktionshandling erm glicht robustere Controller und f hrt zu einem erg nzten Komponentenbild Beispielsweise kann die Kontextermittlung als ein zentraler Dienst angeboten werden statt sie ber die Controller zu vertei len Oft werden in verschiedenen Controllern hnliche Kontext informationen ermittelt z B ob die Mussfelder des Kundenda tensatzes bereits erfasst und noch g ltig sind Da die Information nur einmal pro Anwendersitzung aus
195. iten der OMG http www omg org Zielgruppe Bild 56 Von einer Beschreibungshilfe zum MDA Werkzeug Ziele f r MDA gerechte UI Modelle Eindeutigkeit Durchg ngigkeit Vollst ndigkeit 122 Sprache Bild 57 z B Dialogseiten Anwendungsfall Dialogabschnitte h logische Gruppen beim UI Kontrollemente Modellieren emente lieren UI Struktur beinhaltet Verhalten modellieren modellieren altet f z B Logische a bein z B Ereignisse Schritte Standard I Reaktionen sequenzen U ei Bedingungen Vererbung modellieren beinhaltet Kontext Anforderungen modellieren modellieren gt z B Ergebnisse En nao onen Features Varianten Restriktionen A Erl uterungen modellieren Listenmuster d Formatschablonen z B Prozessanforderungen Situationen Werkzeugeinsatz Infrastruktur Die Grafik verdeutlicht welche Klassen von Anwendungsf llen beim Modellieren einer Softwareoberfl che vorkommen Zum Gro teil sind diese T tigkeiten nat rlich analog zu sonsti gen Entwicklungst tigkeiten wie z B Abl ufe modellieren Beim Detaillieren der T tigkeiten tauchen aber User Interface spezifische Use Cases auf z B Navigationskonzept festlegen oder Dialogseite XY entwerfen Rollenbezug Verschiedene Personen die am Projekt beteiligten Rollen inte ressieren sich f r unterschiedliche Teile des UI Modells Der Techniker entwickelt ein Produkt von innen nach au en der Anw
196. kationen Sp ter f r Leon jetzt f r Markus Paul Chlebek ber den Autor Paul Chlebek ist Experte f r UML Unified Modelling Language und XML Extensible Markup Language Der Schwerpunkt sei ner derzeitigen Projekt und Forschungsarbeit liegt im Entwi ckeln von Methoden und dom nenspezifischen Sprachen f r die Konstruktion von Softwareoberfl chen Durch Verbindung der Spezialgebiete HCI Mensch Maschine Schnittstellen DSL dom nenspezifische Sprachen und MDA modellgetriebene Architektur hat er die die User Interface orientierte Softwarearchitektur aufgestellt Er bringt ein breites Spektrum an Erfahrungen aus der Projekt praxis im In und Ausland in den Rollen Leitender Entwickler Internationalisierungsingenieur Projektleiter Technischer Ent wicklungsleiter Softwarearchitekt und Testmanager mit Paul Chlebek arbeitet freiberuflich als Berater und Methoden entwickler f r BMW und andere international t tige Unterneh men Er ist Mitglied in der Gesellschaft f r Informatik in der International Association of Software Architects und im Berufs verband der deutschen Usability Professionals sowie Gr nder des Open HCI Knowledge Projekts www BenutzerOberflae che de Autorenhomepage https www openbe com hp Paul_Chlebek http www projectpeople net chlebek http www benutzeroberflaeche de Geleitwort Dialoganforderungen werden komplexer Als die Welt noch keine Dialog Software kannte waren die An
197. ktiv anhand des obigen Schemas einzusch tzen Bild 28 Beispiel f r eine Bewertung von UI Werkzeugen 70 Werkzeuge 3 4 Werkzeugarten Zum Beschreiben des User Interface wenden die Entwickler in der Projektpraxis die unterschiedlichsten Hilfsmittel an Die von mir beobachteten UI Entwurfsmethoden reichen von Flipcharts mit denen Workshopr ume tapeziert wurden ber Paintshop Powerpoint Excel und HTML Editoren bis hin zu GUI Toolkits wie FormFlow QT oder VisualBasic Designer oder State Charts und Spezialeditoren f r die Ul Modellierung Zu unterscheiden sind e Office Werkzeuge z B Powerpoint und Excel e Darstellungsorientierte Werkzeuge z B Flash Director SVG oder X HTML e GUI Toolkits Betriebsystemnahe und Kontrollelement orientierte Designwerkzeuge und Bibliotheken e Grafische Ablaufmodellierungswerkzeuge oft auf Basis von State Charts e Werkzeuge f r eingebettete Systeme z B Guide oder HMI Studio e Dom nenspezifische Modellierungssprachen 3 5 Office Werkzeuge Office Programme z B Word Excel Powerpoint werden vor allem von Anwendervertretern als Werkzeuge f r den Entwurf von User Interfaces bevorzugt Das liegt in den meisten F llen daran dass sie sofort verf gbar sind und dass man sich nicht erst einarbeiten muss sondern sofort beginnen kann eine Maske zu entwerfen oder einen Ablauf zu skizzieren Man muss mit Office Programmen keine bestimmte Methodik befolgen In der Pra
198. ld 16 Informationsgeflecht einer UI Beschreibung eeeee 37 Bild 17 Erwartungen des Anwenders und der Oberfl che ne 40 Bild 18 Empfangen Interpretieren Verarbeiten Manifestieren neeee 45 Bild 19 Software kann man nicht mechanisch wahrnehmen 47 Bild 20 Dialog zwischen Anwender und Oberfl che eenennnnen 48 Bild 21 Mensch Maschine Dialog aus der Sicht des UL 49 Bild 22 Use Cases Anwendersicht ssessessnnsensennnennnnnenennennenennenn nennen non 51 Bild 23 Use Cases Sicht der Obertl che 2 au euer 52 Bild 24 Use Cases Sicht der funktionalen Anwendung nenenenene 53 Bild 25 Ablaufnetz Dialogseiten und Kontext eneenesseennesnesnesneen nenne 59 Bild 26 Wissen worauf es beim UI Werkzeug ankommt eeenen 61 Bild 27 Bewertungskriterien f r eine Ul Entwicklungsumgebung 70 Bild 28 Beispiel f r eine Bewertung von UIl Werkzeugen eennennenneen 74 Bild 29 Durchg ngige UI Werkzeuge haben eigene Philosophien 77 Bild 30 Guide View Editot 0uenene aa 81 Bild 31 Guide State Bditor a auslesen een rasieren 81 Bild 32 IAV Teledrive Spezifikation u 84 Bild 33 IAV Teledrive Simulation un denken 85 Bild 34 Projektbeteiligte bringen mentale Modelle der Anwendung mit 89 XVII Abbildungsverzeichnis Bild 35 Systemgrenzen am Beisp
199. leibenden Details auf Implementierungsebene plau sible Annahmen zu treffen Reif f r die Implementierung Exakt genug um plausible Annahmen zu treffen Bild 53 Ablauf einer UI Iteration Ergebnisse der vorigen am Struktur Iteration detaillieren Anforderungen detaillieren Dialoge detaillieren k Interaktionen detaillieren Kontext gt Iterations detaillieren ergebnis Der ausschlaggebende Nutzen eines Vorgehensmodells zur itera tiv evolution ren Detaillierung der Ul Beschreibung ist die Orien tierungshilfe die es bietet Das Iterationsmodell stellt eine siche re Bemessungsgrundlage f r die Planung Durchf hrung und Koordination der T tigkeiten bei der Entwicklung einer Oberfl che F r jede Modellierungsiteration wird klar festgelegt welche Erwartungshaltung an das Modellierungsergebnis gestellt werden kann Die iterative Detaillierung der UI Beschreibung bietet einen Ent wicklungsweg der integrierend und deeskalierend wirkt indem er die Konzentration auf Sachthemen der User Interface Entwicklung unterst tzt Kapitel 6 Sprache in dem eine Sprache zur eindeutigen Beschreibung von Soft wareoberfl chen vorgestellt wird Kapitelziele e Wissen wie und womit man die gesamte Oberfl che ein deutig beschreiben kann e Beispiele f r typische UI Modellierungssituationen e L sungen f r typische UI Modellierungsprobleme In den vorangegangenen
200. lement_interaction_ legt elementspezifische interaktionen fest I common _interaction_ onCommandInteraction_ common interaction _ 1 onEnterInteraction_ onSignallnteraction_ onLeavelnteraction_ beim betreten des modells eines steps eines containers eines elements ein step wird immer vor dem dazugeh rigen screen betreten die step on enters werden unmittelbar nach erlangen der kontrolle durch den step ausgef hrt die screen on enters werden nach ausgabe bzw anstossen der ausgabe der screeninhalte ausgef hrt die element on enters werden nach dem abschluss des screen aufbaus bei bergabe der kontrolle an einzelne elemente ausgef hrt onEnterInteraction_ ON _ENTER requirements_ condition _ action_ D beim verlassen siehe onEnter onLeavelnteraction_ ON LEAVE requirements_ condition _ action_ bei Auftreten eines Signals onSignallnteraction_ ON _SIGNAL requirements_ condition _ action_ D onCommandInteraction_ ON _COMMAND requirements_ condition _ action_ D condition_ UNCONDITIONALLY WHEN expression_ requirements_ D 155 Lucia Grammatik expression_ name _reference_ EQUALS name_reference_ action_ y PASS z APPLY name_reference x LEAVE _ v NEXTSTEP name_reference_ requirements _ a business logic context funktionalit ten die die anwendung zur verf gung
201. lemente Look and Feel Iterationsmodell 113 UI Iterationen der User Interface orientierten Architektur und Web Produktionsstufen weisen Parallelen auf e Die Produktionsstufen Strategie und Scope sind mit der UI Inception vergleichbar e Skeleton ist in Teilen mit UI Elaboration vergleichbar e Structure ist in Teilen mit UI Construction vergleichbar e Surface kann als Teil von UI Transition angesehen werden UI Iterationen der User Interface Architektur gehen vor allem in der Iteration UI Transition inhaltlich ber die Web Produktionsstufen hinaus z B bei der Kontexteinbettung Situa tionen Restriktionen Daten und Funktionsbezug Varianz Weitere technisch orientierte Detaillierungsaufgaben bei der UI Construction und bei der UI Transition sind e Parametrisieren der Kontexte f r Darstellung von Wid gets und f r Funktionsaufrufe e Klassifizieren der Dialog berg nge in Haupt und Ne benpfade e Mapping Angaben f r die Kopplung des UI mit der Ap plikationsschicht Daten und Funktionsdeklarationen e Wiederverwendungsstrategien Zusammenfassen von hnlichen Eigenschaften in Musterschritten Extrahieren von Situationen Iterationsabschluss Auf Grundlage der obigen Iterationseinteilung kann die UI Entwicklung in mehreren klar festgelegten Waschg ngen durchgef hrt werden Jeder Waschgang hat das Ziel die der Iteration zugeordneten UI Eigenschaften
202. lfeldern nat rlich noch andere Kon Kontrollelemente in trollelemente z B Text Eingabe Felder Text Ausgabe einem UI finden Sie Felder Grafiken Tabellen usw im Kapitel Oberfl che e Containment Komposition Aggregation Bringt zwei Klassen in die Beziehung ist ein Bestand teil von bzw besteht aus oder enth lt zum Beispiel Eine Softwareoberfl che besteht aus Kontroll elementen und aus UI Logik Softwareoberfl che Kontrollelemente User Interface Logik e Multiplizit t Gibt an wie viele Exemplare der durch eine Contain mentbeziehung oder durch eine einfache Assoziation verbundenen Klassen gemeint sind z B Ein Dialogab schnitt enth lt 7 Kontrollelemente Lesen von UML Diagrammen 23 Dialogabschnitt Kontrollelement e Abh ngigkeit Verwendung Bringt zwei Klassen in eine Abh ngigkeitsbeziehung z B Ablaufnetz verwendet Dialogseiten oder Interak tion ben tigt benutzt verwendet Kontext Interaktionen ben tigen Kontext meistens UML Use Case Diagramm e Akteure Handelnde Definiert eine agierende Anwenderrolle Aktoren k n nen sowohl Menschen als auch Systeme sein e Verwendungsf lle Anwendungsf lle Sind T tigkeiten die der Akteur mit Hilfe des verwen deten Systems hier also mit einer Softwareanwen dung durchf hren kann Q AN Software Anwen
203. lg lt berichten Zu Bestellsystem wechseln Zur Serienbrief erstellung wechseln Durch die Darstellung der Anwendungsoberfl che als eine Hie rarchie von logischen Schritten kann man ihre Dialogentit ten z B GUI Screens oder Sprachmen s identifizieren und gliedern Logische Schritte modellieren 95 4 4 Logische Schritte modellieren Das Konzept des logischen Schritts spielt f r die Erkl rung der Abl ufe in einer Softwareoberfl che eine wichtige Rolle Logische Schritte sind Stationen im Ablauf der Arbeit des An wenders mit der Oberfl che Sie sind Bausteine der Ablauf struktur der Anwendung Unterschiedliche Schritte Nicht alle logischen Schritte sind gleich Sie k nnen sich in der Art der Aufeinanderfolge in Repr sentation an der Oberfl che und in anderen Eigenschaften unterscheiden Es gibt Schritte die hintereinander ausgef hrt werden und so den Bearbeitungsfluss der Anwendung bilden Sie hei en Se quence Steps Andere Schritte werden wie ein Dienst verwen det Nach ihrem Durchf hren wird der Bearbeitungsfluss an schlie end an der Stelle fortgesetzt von der aus der Dienst abge rufen wurde Diese Schritte hei en Service Steps Mit Hilfe von Service Steps lassen sich Unterbrechungen im Bearbeitungsfluss z B modale Meldungen und Popup Dialoge modellieren Logische Schritte k nnen unterschiedliche Modalit ten haben also mit grafischer Ein und Ausgabe Ein und Ausgabe mittels gesproch
204. llungen Skinning Anpassen der Men s Dialogseiten und Abl ufe an Konfigurationen z B keine Funktionen anzeigen die 60 Werkzeuge UI Perspektiven helfen beim Handling typischer Ph nomene des UI Entwickelns in dieser Konfiguration oder von dieser Benutzerrolle nicht ausgef hrt werden k nnen Standard Entwicklungswerkzeuge z B Java in Eclipse oder eine User Interface Beschreibung in Form eines strukturierten Anfor derungsdokuments unterst tzen das Handling des oben aufge z hlten Standardrepertoire der Spezifikationsprobleme schwach Typischerweise muss sich jeder Entwickler selbst ein Schema oder eine Konfigurationsdatei erfinden um die UI Definition zu strukturieren oder zu parametrisieren Die L sung wird dabei so gut wie die ad hoc und neben der eigentlichen Entwicklungs aufgabe gefundenen Strukturen und Beziehungen sind Weitere typische jedoch seltener auftretende Standardproble me der UI Entwicklung sind e Transaktionsverarbeitung Erst wenn alle Eingabedaten vorliegen kann die Transak tion ausgef hrt werden Die Eingabedaten m ssen gege benenfalls ber eine lange Sequenz von Dialogseiten hin weg berpr ft werden Es m ssen Berichtigungsanwei sungen f r die Eingaben ausgegeben werden Ggf soll der Anwender im UI zu den zu berichtigenden Stellen auto matisch hinnavigiert werden e Einzelaktionsverarbeitung Einzelne Aktionen in der Benutzeroberfl che sollen sofort verarbeitet
205. m Austausch von Informationen mit dem funktionalen Anteil der Anwendung zur Verf gung stellen Diese Komponenten k nnten hei en e Funktionsmapper bildet Requests zum Ausf hren von Funktionen auf parametrisierte Methoden der Anwendung ab e Valuemapper bildet Requests zum lesenden oder schrei benden Zugriff auf Daten auf das Objektmodell der An wendung ab UI orientierte Laufzeitkomponenten 171 e Listenmapper bildet den Zugriff auf Listen und Listen eintr ge auf Listenobjekte ab e Situationsmapper bildet Requests zum Abfragen von Zust nden auf Wahrheitswerte und logische Ausdr cke ab Bild 75 lt lt component gt gt Komponenten Pr sentationsschicht Woden i A odell f r eine UI Pr sentationsobjekte fi orientierte og Architektur lt lt component gt gt Dialoghandler Ul Laufzeitobjekte x P x is wertet zus Wird erzeligt von verwendet LE eg D a Ui Laufzeitmodell Formale arser Daten UI Spezifikation lt verwenget lt lt component gt gt Kontexthandler lt lt component gt gt 2 lt lt component gt gt Funktionsmapper Listenmapper lt lt component gt gt lt lt component gt gt Valuemapper Situationsmapper lt lt component gt gt z Funktionale Anwendung Gesch ftsobjekte Systemobjekte Die Ul orientierten Laufzeitkomponenten k nnen in einem so genannten Kontextbandler zusam
206. m Sammeln UT Elaboration und dem Ordnen von Bestandteilen aus denen sich das User Sammeln und Interface zusammensetzt Ablaufstruktur Kontrollelemente Ver ordnen haltenselemente Ziel ist dass das Gef ge aus Dialogen mitsamt ihrer Anzeige und Bedienelemente sowie die Arbeitsab ufe m glichst vollst ndig bekannt sind In der UI Construction liegt der Schwerpunkt auf dem Formen UI Construction und Verkn pfen der User Interface Bestandteile Dazu geh rt das Formen und Formulieren von berg ngen zwischen Dialogeinheiten und das verkn pfen Benennen der Bedingungen f r diese berg nge Ziel ist dass das UI f r den Anwender anfassbar und erlebbar wird und an hand einer Simulation best tigt werden kann In der UI Transition liegt der Schwerpunkt auf dem Verkn p UT Transition In fen des User Interface mit der Funktionalit t und mit dem Da Kontext einbetten tenkontext Dazu geh rt das Ausdetaillieren von Verhaltensbe dingungen Nebenpfaden Ausnahmenbehandlung Besonderhei 112 Detaillieren ten der Bedienung und Implementierungsdetails Ziel ist das Erreichen der Umsetzungsreife in der Zielplattform In einem Modellierungsleitfaden kann jeder UI Iteration zuge ordnet werden welche UI Eigenschaften darin im Fokus stehen und welche Eigenschaften als bereits vorliegend und weitgehend stabil vorausgesetzt werden Mit der Detaillierung des Leitfadens bis zur Ebene einzelner UI Eigenschaften erhalten die Modellie r
207. mengefasst werden Der Kontexthandler bew ltigt die Aufgabe die Oberfl che mit Infor mationen ber den Zustand der anwendungsinternen Gesch fts und Systemobjekten zu beliefern In umgekehrter Richtung l st der Kontexthandler die Anforde rungen von Funktionen seitens der Oberfl che in das Ausf hren und das Parametrisieren einzelnen Methoden auf 172 Architektur 7 5 Ausleiten von Prototypen Aus den in der UI Beschreibung enthaltenen Informationen kann man Bildschirme und einfache Kontrollanweisungen herauspar sen und daraus UI Prototypen erzeugen Ein zum Beispiel in HTML und JavaScript erzeugter Prototyp eignet sich gut als Kommunikationsplattform f r die an der Kon struktion eines User Interface beteiligten Personen Mit CSS Cascading Style Sheets kann das Erscheinungsbild des Prototypen jederzeit bequem und meist ohne erneute Generie rung des Prototypen ver ndert werden Der Kunde oder Begut achter des UI Entwurfs braucht keine besondere Laufzeitumge bung um den Prototypen auszuf hren also kann man den Pro totypen z B einfach per Mail an den Gespr chspartner verschicken 7 6 Weitere Transformationen Man kann aus einer Ul Beschreibung noch weitere f r Entwick ler n tzliche Dokumente und Aufstellungen ausleiten e Data Dictionary e Funktionslisten e Elementlisten e Wertebereiche Prinzipiell kann eine eindeutige UI Beschreibung in einen belie bigen Datenstrom oder in einen beliebigen Code u
208. mgewandelt werden Sofern die Semantik die Bedeutung der Bestandteile einer UI Beschreibung eindeutig ist k nnen daraus beliebige andere Artefakte generiert werden ber Dinge die in das Zielmodell hineingeneriert werden z B Seitenlayout Rendering einzelner Bedienungselemente Spezifi kationsauslassungen aber im Quellmodell nicht vorhanden sind m ssen Annahmen getroffen werden Die Annahmen k nnen innerhalb der Transformationsprozedur also im Code oder in einer Parameterdatei z B eine XML Konfiguration f r den Transformator abgelegt werden 7 7 Nutzen Der wesentliche Vorteil der Einbindung einer formalen UI Beschreibung in die Architektur der Software liegt darin dass Nutzen 173 Informationen ber nderungen an der UI Spezifikation unmit telbar f r die Programmierung zur Verf gung stehen Diese Informationsbereitstellung kann bei einer formalen UI Spezifikation zu einem beliebigen Grad automatisiert werden Es k nnen die in der Ul Beschreibung enthaltenen Regeln als XML Daten bereitgestellt oder von einem Parser zur Codeerzeugung verwendet werden Aus der UI Beschreibung k nnen bereits in fr hen Projektphasen Oberfl chenprototypen erzeugt und zur Abstimmung und Absicherung der geplanten Funktionen ver wendet werden Der nichttechnische jedoch nicht minder bedeutsame Vorteil der Beheimatung der UI Modelle in der Softwarearchitektur ist dass damit die ganze Anwendung von der Architektur umf
209. n Varianz ausformulieren Ausnahmen behandeln Erreichen der Implementierungsreife Iterationsmodell 111 Inhaltlich abgrenzen Sammeln amp ordnen Formen amp verkn pfen In Kontext einbetten _ gt gt lt gt Inception Elaboration Construction Transition Systemgrenzen Interaktionen Anforderungen A Haupt u z log Schritte Uberg nge Notifikationen Restriktionen Bild 51 Die Grafik verdeutlicht welche Themen in den einzelnen Iterati ferationsmodell f r onen des UI Entwickelns gekl rt werden sollten Diese Kl rung fe Ul Entwicklung bedeutet nicht dass die einzelnen Themen am Ende der Iteration abschlie end und endg ltig spezifiziert sind sondern dass je weils ein Fundament steht auf dem abgesichert die weitere De taillierung in der n chsten Iteration erfolgen kann Anzeige amp Bedienung In jeder Iteration werden alle Perspektiven betrachtet jedoch mit unterschiedlichen Schwerpunkten und in verschiedener Detailtie fe In der UI Inception liegt der Schwerpunkt auf der inhaltlichen Uf Mmception Abgrenzung des User Interface Ziel ist die Breite der Software Inhaltlich oberfl che zuverl ssig abzustecken Mit der in der UI Inception abgrenzen aufgestellten UI Landkarte kann man sicherstellen dass man im sp teren Entwicklungsverlauf nicht durch das Entdecken neuer L nder berrascht wird In der UI Elaboration liegt der Schwerpunkt auf de
210. n e Datenverwendung gt Datenselektion Statements Nutzen 181 e Anzeigeausschnitt lt gt Datenvorrat e Funktionsverwendung gt Methoden e Funktionskontext lt gt Methodenparameter 8 5 Nutzen UI Modellierung vertr gt sich gut mit den allgemein verwendeten Methoden UML RUP V Modell und erg nzt diese um UI orientierte Methoden und Vorgehensweisen UI Modellierung f rdert die Kommunikation im Projekt und unterst tzt die Erstel lung der funktionalen Modelle z B durch die Verwendungssicht der geforderten Daten und Funktionen Durch Verbindung von UML Modellen mit UI Modellen erh lt man ein in sich geschlossenes abgesichertes und rundes Ge samtbild der Anwendung Ich empfehle Ihnen Oberfl che und Anwendungsinternas paral lel zu entwerfen und kontinuierlich miteinander abzugleichen Sie erreichen so ein konsistentes und fehlerarmes Ganzes Die Abbildung zeigt eine Vorgehenskarte f r das Verbinden der UI Modellierung mit der Funktionsmodellierung UI Perspektiven modellieren Ablaufstruktur Dialoge Interaktionen Kontext B Data UML Modellger ste UI Inception Modell Anforderungen an Verwendung Anforderungen an Funktionen m UML modellieren Anforderungen an Daten Klassen Use Cases Kontroll und Datenfl sse Anforderungen an Abl ufe Verzichten Sie auf die Forderung der klassischen Anforderungs a
211. n Ablaufstruktur step_ STEP name _definition_ requirements_ using screen _clause_ requirements _ based on clause_ requirements_ step_content_ requirements_ D step_content_ Lucia Grammatik 151 CONTAINS OPENBLOCK requirements_ step_ CLOSEBLOCK p screen _ SCREEN name definition_ requirements_ using_layout_clause_ requirements_ interactions_ screen_content_ requirements_ interactions_ Dialogsicht D layout_ LAYOUT name_definition_ requirements _ taggedcode D widget_ WIDGET name _definition_ requirements _ taggedcode p context_ FUNCTIONALITY name definition_ requirements_ taggedcode _ Kontextsicht p a bildschirme der benutzeroberfl che sind der io kanal zwischen benutzer und hci enthalten ein und ausgabee lemente screen content_ CONTAINS OPENBLOCK requirements_ container_ element_ CLOSEBLOCK p using_screen clause _ io kanal bildschirm steps k nnen m ssen aber nicht einen screen verwenden ber diesen screen erfolgt die io falls screen nicht angegeben dann wird angenommen dass der zum step zugeh rige screen den selben namen hat using default und keine angabe sind aquivalent ist dieser default screen nicht defniert dann wird angenommen dass der step keinen bildschirm verwendet 152 Sprache
212. n Schritte auf verschiedenen Bildschirmmasken durch w hlt Funk tionsbereiche aus bzw steuert den Anwendungsablauf innerhalb des von der Software vorgegebenen Angebots la Enterprise Mana gemen t Umernehmen vertragspariner Proste Prozente Projektwerteiler Kontenstellen Kat verteler einrichten einrichten ainnehsen inneren ainnean einrichten anrichten Banker een Mandant Nony Mitarbeiter Stommsatz des Niederlassungs Mitarbelters einrichten Dielogseite Wife zur Disiogsete Fragen amp Antworten 1a Start r Kinstieg FT d Stammdaten I Unternehmen einrichten Untem Navigator Unternehmen Mandant J Niederlassung Vertragspartner einricht D in Produkte einrichten 3 Funk Dienste barse 7 7 g orucker aj Zi E iE Vertragsverwaltung 4 cm Untern Navigator Start a Stammdaten Bitte w hlen Sie den gew nschten Datensatz und dann Bearbeiten um einen bestehenden Datensatz Urternehmen einrichten zu bearbeiten Demo 99 EI Dem Mandant 99 Ausgew hlten Fintrag bearbeiten pa Demo mi 01 2 o E Achn Zentrale Neues Unternehmen anlegen amp Bonm kam Neuen Mandanten anlegen E Wenger Jens D Neue Niederlassung anlegen 2 oe Acim 2 Wronisch Vaser Ubben werner Ne Mitarbeiter anlegen Miler Jens er lei 2 Poner Marnsa A Senger apela pl iwe ra s9 Ausgew hlten Eintrag l schen amp Testname Niederlassung Ferug d Arbetsplatz Andere Form
213. n UI Beschreibungen e Vergleich von UI Beschreibungen e Strukturiertes Aufnehmen und Dokumentieren von User Interface Anforderungen e Aufstellen von funktionalen Anforderungen an Werkzeuge zur UI Modellierung e Bewerten von Verfahren zur UI Modellierung Die n chsten Kapitel sch pfen den Nutzen dieser User Interface Gliederung aus Kapitel 3 Werkzeuge in dem Anforderungen an UI Werkzeuge sowie unterschiedli che Werkzeugtypen und konkrete Werkzeuge vorgestellt werden Kapitelziele e Wissen welche typischen Ph nomene beim Entwickeln ei nes User Interface auftreten e Wissen nach welchen Kriterien Werkzeuge zur UI Entwicklung bewertet und ausgew hlt werden k nnen e berblick ber Werkzeuge zur UI Entwicklung Wie bei jedem Konstruktionsprojekt so auch bei Software und damit auch bei ihrer Oberfl che taucht bereits zu Beginn des Projekts neben der Frage Was wird gebaut bald die Frage Woraus und womit wird gebaut auf In einem Softwareprojekt k nnen konkrete Fragen der Entwick ler an den Architekten zum Beispiel so lauten e Mit welchem Werkzeug soll die Softwareoberfl che ent wickelt werden e Wie gut ist das zur Auswahl stehende Werkzeug zum Bauen der Oberfl che geeignet e Nach welchen Kriterien wurde die Werkzeugauswahl ge troffen Um diese Fragen fundiert zu diskutieren sollten Architekt und Entwickler neben der Kenntnis der technischen und organisatori
214. n andere Oberfl cheneigenschaften z B Farben Piktogramme vom kul turellen und sozialen Hintergrund der Anwendergruppe ab Zum Beispiel haben ein 11 j hriges M dchen aus Tokyo und ein 60 j hriger griechischer Weinbauer ganz unterschiedliche Wahr nehmungen von einer und derselben Anwendungsoberfl che falls der Weinbauer berredet werden kann sich eine anzuse hen Eine konsequente Anlehnung der Bedienung und des Verhaltens von Oberfl chenelementen an mechanische Gesetze k nnte sich positiv auf die intuitive Anwendbarkeit von Softwareprogrammen auswirken Hier k nnen UI Entwickler und selbst Usability Forscher noch von Weinbauern lernen Funktionsweise einer Softwareoberfl che 45 Verlauf des Anwender Anwendung Dialogs Das folgende Funktionsmodell erkl rt die Vorg nge die in der Software stattfinden wenn ein Anwender und eine Anwen dungsoberfl che in einen Dialog treten das hei t also wenn der Anwender Bedienungselemente der Anwendungsoberfl che bet tigt um eine von ihm gew nschte Funktion der Anwendung auszuf hren Anwender Agieren Mensch Interpretieren Softwareumwelt Interpretieren one I Oberfl che gt Vermittler Verarbeiten Ausgabe Maschine Funktionen Informationen Software An dem oben skizzierten Dialog beteiligt sind die Akteure e Der Anwender e Die Oberfl che im Sinn
215. n der physischen Darstellung des Widgets das verwendet wird ab Zum Beispiel bedeutet selectfield using pattern betrag using widget dropdownlist dass der Wertebereich von betrag als Auswahlfeld in einer auf klappbaren Auswahlliste Combo Box bzw Drop Down List bereitgestellt wird Dabei wird jeder zul ssige Wert aus dem Wertebereich von betrag als Eintrag in der Auswahlliste bereitge stellt Lucia Grammatik 161 Bei Zahlen ist die Schrittweite der Auswahl davon abh ngig wie viele Nachkommastellen die Formatangabe festlegt Bei einer Bereitstellung als Auswahlliste enth lt die durch pattern named betrag values 0 10 1000 1500 2000 2010 2500 3500 format z zz9 99 festgelegte Auswahlliste also die folgenden Werte 0 00 0 01 9 98 9 99 10 00 1 000 00 1 500 00 2 000 00 2009 99 2 010 00 2 500 00 3 500 00 Weitere Wertebereichs Muster k nnen sein Dynamische Listen Kombinationen aus festen Werten mit dynamischen Anteilen sowie direkte Reaktionen auf die Auswahl einzelner Werte Zum Beispiel pattern named feiertage values l Januar Neujjahr 25 Dezember Weihnachten values from function feiertagsliste on select set kontrollanzeige value to value Ein Pattern definiert Wertebereiche f r Eingaben und Ausgaben e durch regul re Ausdr cke e Aufz hlung von Einzelwerten e Dynamische Wertebereiche e Ausschluss von Einzelwerten und dynamischen Wert
216. n die eingegebene Buchstabenfolge vorkommt e Dazu wird die Liste unter bergabe der eingegebenen Buchstabenfolge als Suchschl ssel von der Anwendung neu geholt Konzepte f r eine UI Beschreibungssprache 133 e Nach Auswahl eines Orts wird entsprechend voreingestell ten Kategorien die Liste der Sehensw rdigkeiten zu die sem Ort angezeigt Dazu wird Bereitstellung der Liste der Sehensw rdigkeiten abermals per Funktionsaufruf in der Anwendung angefordert e Anschlie end werden die von der Funktion an der UI Schnittstelle bereitgestellten Daten abgerufen und auf dem Bildschirm ausgegeben Das Beispiel zeigt dass die Oberfl che eine breite Schnittstelle zum Funktions und Datenkontext der funktionalen Anwendung hat State Charts beschreiben Zustands berg nge innerhalb eines geschlossenen Systems Sie unterst tzen jedoch keine Wechsel wirkung zwischen zwei Systemen von denen z B eines das andere verwendet F r das Spezifizieren von Benutzeroberfl chen m ssen State Charts um eine Kontext und Ressourcen Sicht zur Deklaration der von der Oberfl che verwendeten Funktionen und Daten erweitert werden Hierzu k nnen in State Charts die auf den UI Kontext bezogenen Konstrukte e applicationValue e functionalRequest und e onSignal eingef hrt werden Sie erm glichen das Abfragen und Deklarie ren von Daten aus dem Datenhaushalt der Anwendung das Ausl sen und Deklarieren von Anwendungsfunktionen und das Re
217. n und ihre Darstellung als Kurve auf der Zeitachse Man kann auf diese Weise Entwicklung und Tendenz der Qualit t einsch tzen 11 2 _ Testszenarien generieren Aus den Informationen in einem UI Modell k nnen keine fachli chen Testszenarien generiert werden Fachliche Testf lle sind in der Beschreibung des UI in der Regel nicht enthalten und k n nen aus ihr nicht ausgeleitet werden Die UI Spezifikation unterscheidet sich von einer Testfallspezifi kation Die Testfallspezifikation beschreibt konkrete Durchl ufe und die dabei erwarteten Ergebnisse die UI Spezifikation be schreibt hingegen den M glichkeitenraum f r abstrakte Durch l ufe und den Erwartungsraum der Eingaben F r das automatische Testen der Oberfl che k nnen einfachere Tests auf der Ebene einzelner Eingabewerte und Reaktionen auf das Bet tigen einzelner Schaltfl chen aus der UI Spezifikation herausanalysiert werden Das folgende Diagramm zeigt eine Vorgehenskarte f r solche automatisierten UI Tests Eingabeger te simulationsregeln Reaktionen Reaktion auf Eingabewerte pro Eingbewert analysieren pro Eingabefeld Eingabewerte testskript a a Wertebereich erzeugen Wertebereiche pro Eingabefeld analysieren Reaktion pro gt User Interface U Modell UI Element Testskript Reaktionen auf pro Situation Kontrollelemente p Kontrollelemente testskript analysieren erzeugen Dialogwe
218. nalyse dass nur das Was nicht aber das Wie der Anwen dung erhoben werden soll Die sicher berechtigte Sorge nicht in technischen Umsetzungs disputen zu versinken wird von Scharbert hervorgehoben Da der Analytiker zur L sungsneutralit t verpflichtet ist befasst er Dictionary UML Modelle Bild 79 Vorgehenskarte f r synchrone UI und UML Modellierung N chster UI gt Fertigstellungsgrad E Bloss nicht auf die L sung eingehen 182 Funktionsmodellierung Beliebte Standardfrage Na sieht man schon was Auf Merkmale der L sung eingehen Informationen ber Verwendung mit funktionalen Anforderungen verkn pfen sich nicht mit technischen Repr sentationen zumindest gibt er es nicht laut zu Scharbert 2005 S 129 Andererseits Welcher Entwickler hat noch keinen Teamleiter erlebt welcher pl tzlich hinter einem stehend mehrmals t glich die wohlbekannte Frage Sieht man schon was stellt Jeder am Projekt Beteiligte will das Produkt anfassen und erleben k nnen wieso also dem Analytiker das Ganzk rperpr servativ der L sungsneutralit t um jeden Preis berziehen Aus meiner Sicht ist es sachdienlich das Was vom Wie zu tren nen aber nicht zeitlich sondern nur r umlich das hei t Die Analyse klar nach Was und Wie gliedern Zum Beispiel Wenn Sie einen Tisch bauen sollen wird es Ihrem Kunden und Ihnen schwer fallen nicht dar
219. nd einzelne logische Schritte die Ablaufstruktur einzelne Dialoge und Kontext Als Ma zahlen f r solche qualitativen Einsch tzungen bieten sich prozentuale Aussagen an z B Die Qualit t von Kundendaten erfassen betr gt 80 Es empfiehlt sich vorab festzulegen welche Prozentangaben plausibel sind und was sie bedeuten Zum Beispiel ist die Anga be zu 95 fertig in der Regel nicht weiter verwertbar weil die restlichen f nf Prozent oft einen berraschend langen Zeitraum in Anspruch nehmen Das sollte man nicht verwechseln Durch die Prozentangabe wird nicht die hineingesteckte Arbeit sondern der Arbeitsstand des UI Modells ausgedr ckt Eine m gliche Prozentskala zur Bewertung des Fertigstel lungsgrades k nnte lauten e 1 30 Begonnen e 31 60 Sammlung und Aufbau e 61 80 Gesamtbild liegt in Breite und Tiefe vor Keine Priorit t 1 Probleme e 81 90 Alle UI Merkmale k nnen evtl mit kleinen Umwegen ausprobiert werden Keine Priorit t 2 Probleme e 91 100 Optimierung Alle Anforderungen der Priorit t 1 2 und 3 sind umgesetzt Die beim Bestimmen des Fertigstellungsgrads herangezogene Priorit t von UI Anforderungen und UI Problemen kann hnlich einer Fehlerklassifikation in folgende Klassen unterteilt werden e Priorit t 1 Show Stopper Das UI erm glicht keine ge schlossenen Verwendungsszenarien e Priorit t 2 Arbeitsbehinderung ohne Umgehungsm g lichke
220. nden Unternehmen vital verkn pft ist werden ber Jahre manchmal ber Jahrzehnte mit gro em Auf wand gewartet und ausgebaut Unternehmen die viel Geld Wissen und Arbeit in eine bew hrte L sung investiert haben setzen sich ungern dem Abenteuer aus eine so ma geschneiderte und gereifte Software durch ein neues System zu ersetzen Sie z gern nicht selten auch dann wenn aus technischen organisatorischen und zuletzt auch aus wirtschaftli chen Gr nden der Ersatz veralteter Systeme durch modernere L sungen nahe liegt Das Ersetzen einer Software durch eine neue wird von Techni kern und Anwendern unterschiedlich empfunden Reengineering und Migration 225 Der Kern dieser Modernisierungsabneigung liegt zuweilen in der nicht unbegr ndeten Angst dass sich mit dem neuen System die gewohnten Arbeitsg nge anders oder vielleicht schlechter als bisher erledigen lassen Die Anwender bef rchten oft zu recht dass sie ihre heute routi nierten T tigkeiten mit dem n chsten System m hsam neu erler nen m ssen Wenn auch das neue System so manches neue und n tzliche kann M glich und in der Praxis schon vorgekommen ist dass manch anderes auf dessen Funktion die Anwender bei der t glichen Arbeit angewiesen sind nicht mehr m glich sein wird 13 1 Reengineering und Migration Kein Reengineering oder Migrationsprojekt und keine Entwick lung eines neuen Release beginnen mit dem Ziel die oben be schriebene Situation he
221. nder ist die Ober fl che die Software Beschreibt man die Oberfl che im Detail also das wie sich die Software im Dialog mit dem Anwender verh lt dann ist auch die Funktion beschrieben und Auftragge ber und Entwickler werden sich einig was gebaut wird Das Buch zeigt auf welche Begriffe Redewendungen und Be schreibungsstrukturen ben tigt werden um die Verwendung einer Softwareanwendung nicht nur Use Cases sondern die komplette Oberfl che einer B roanwendung mit jedem Pieps den sie von sich gibt eindeutig und missverst ndnisfrei zu be schreiben Der Fokus des Buchs liegt auf Oberfl chen f r kommerzielle wirtschaftlich orientierte Software Diese Anwendungen etwa Verwaltungssoftware Beratungs Verkaufs und Buchungs systeme unterst tzen Arbeitsabl ufe der Unternehmen durch elektronische Workflows dialoggest tztes Ausf llen von Formu laren sowie durch verschiedene Such und Auswertungsfunktio nen Heute werden solche Anwendungen in der Regel mit grafischen Benutzeroberfl chen als Windows oder als Browserapplikation implementiert Diese Art von Softwareoberfl chen kommt nach meiner Einsch tzung in 90 aller gesch ftorientierten Anwen dungen vor Die Ul orientierte Architektur geht zum Teil auch auf Fragestel lungen von sprachgesteuerten Dialogen und von eingebetteten Systemen z B Radionavigationssysteme Andere User Interface Arten wie freie Dialoge Virtual Reality Augmented Reality Spiele KI
222. neen nenne 188 9 3 Prozessbeschreibungen im UI abbilden eeenenn 191 9 4 Ablaufstrukturen visualisieren seesesnsensnesennnenn nennen nenne 192 9 5 Nutzen eu es E sr E E E S 193 Kapitel 10 Dokumentation sssrssssssnssssnnsnessnnsnsnsssnnnnessnnnnnnnne 195 10 1 Entwicklungsdokumente generieren eesssensesseeeneesneesneesneesnee nenn 196 10 2 Benutzerdokumente generieren uuenssnsnessnessnesnnesnnesneesnneeneesnesnes nenn 197 10 3 UI nderungen nachvollziehen 198 10 4 Nutzen ats nn 198 Kapitel 11 Testen z esesisesisenssseiensessseesessnehss seltene hkenesnpensese 201 11 1 Arten von Ul TEsts u nn ill nuslifannatnalschen 202 11 2 Pestszenarien Genereren orere e e a E e AA 204 11 3 Navigation beim UI Test sessessesseessnesnnesnesnesnnennnnnnnsnnesnennn en 205 11 4 NUOD r RE RER TEE TEENS a E EHE 206 Kapitel 12 Projektmanagement ursssssssonsnnnsnonsnnnnnnnnnnnnnnnnnnnnn 209 12 1 Arbeiten im Kontext der Ul Anforderungen enennennennen 210 12 2 Ul tientiertes Vorgehen 2 3 2 ER enenorepehien 211 12 3 Integration sicherstellen n i 4 amp 2s2s Keen 211 12 4 Rollen und Aufgabenteilung bei der UI Entwicklung 215 12 5 NUEN I unten ihnen a ee 221 XVI Inhaltsverzeichnis Kapitel 13 Lebenszyklusmanagement rrrrrsssossssnssessonnnsnenennee 223 13 1 Reengineering und Migration eeeneneesnnennennsnn nennen nen
223. nen 225 13 2 UI Beschreibung wieder verwenden nenseneensennee nn 227 13 3 Zusammenfassung und Ausblick eensenneneeneennennenn nenne 228 Iiier tuiverzeich san ERIESERERIERINAI 231 Abbildungsverzeichnis Bild 1 Software macht Computer f r Menschen verwendbar 1 Bild 2 Software anhand der Verwendens der Oberfl che verstehen 0 2 Bild 3 Oberfl chen sind Bedienpulte f r Funktionen der Software eee 4 Bild 4 Typisches User Interface einer kommerziellen Dialoganwendung 4 Bild 5 Navigieren in kommerziellen Anwendungen cenenennensnen nenn 5 Bild 6 Leute die am Entstehen einer Software beteiligt sind ene 6 Bild 7 Gemeinsames Entwickeln macht Pl ne und Modelle notwendig 6 Bild 8 Dialogbaupl ne helfen Missverst ndnisse zu vermeiden 9 Bild 9 Form and Function follows Use Case eenennsesseesnnenenesnne nennen 10 Bild 10 Verwendung Funktion Technik Form enenenneenennen 11 Bild 11 Entwickler modellieren vorwiegend das Innenleben der Software 11 Bild 12 Leitfaden der User Interface orientierten Architektur 16 Bild 13 User Interfaces machen den Gro teil einer Software aus 27 Bild 14 Eine Softwareoberfl che besteht aus verschiedenen Teilen 29 Bild 15 Themengliederung f r das Beschreiben einer Oberfl che 37 Bi
224. nen in Erfahrung bringen Unabh ngig davon ob die Oberfl che f r eine Kundenverwal tung f r ein Navigationssystem f r ein Verwaltungsprogramm oder f r eine Vertriebsunterst tzungssoftware ist kann man die 34 Oberfl che Leitfragen der UI Beschreibung Grobgliederung f r eine UI Beschreibung Bild 15 Themengliederung f r das Beschreiben einer Oberfl che Aufgabenstellung nach den Merkmalen der Softwareoberfl che analysieren und thematisch gliedern Die im Folgenden in Form von Leitfragen beschriebenen Klas sifizierungsmerkmale k nnen als Anleitung f r eine Ul orientierte Anforderungsanalyse verwendet werden Gliedern der Ul Beschreibung mit Leitfragen Um eine Anwendungsoberfl che entwerfen zu k nnen stellt der Entwickler bzw der Analytiker eine Menge Fragen Die Fragen k nnen das generelle Aussehen Verhalten und Funktion der Anwendung einzelne Dialogseiten Buttons oder Eingabefelder oder den Dialog zwischen Anwender und Oberfl che in speziel len Situationen betreffen Sowohl die Fragen als auch die Ant worten k nnen schnell ein komplexes und schwer zu berbli ckendes Informationsgemenge bilden Die Gliederung der Fragen in merkmalbezogene Themen kann helfen die Antworten in eine strukturierte Form zu bringen und so den berblick ber eine UI Beschreibung zu behalten Die beim Entwickeln eines User Interface aufkommenden Fra genkomplexe lassen sich wie folgt zu einer Grobglied
225. nen zwischen den Anwendungsfunktionen funktiona le Maschine und der Anwendungsumwelt im betrachteten Fall der Anwender Die f r den Anwender Mensch bestimmten Informationen m ssen f r diesen wahrnehmbar und interpretierbar sein Die f r die funktionale Anwendung Maschine bestimmten Informationen m ssen f r diese verarbeitbar und eindeutig sein Es handelt sich bei einer Anwendungsoberfl che also um eine Art bersetzer und Vermittler dessen Aufgabe es ist die Fin gaben des Menschen an den Rezeptoren Steuerungseinrichtun gen Kontrollelementen der Software an die Anwendung wei terzureichen In der umgekehrten Richtung wandelt die Oberfl che die Daten der Anwendung in mensch wahrnehmbare Informationen d h in Ausgaben i d R in Form von visuellen und akustischen u e rungen um Funktionsweise einer Softwareoberfl che 43 In beiden Richtungen findet dabei immer das Verhandeln der Oberfl che gegen ber der Funktionalit t statt Interaktives System Interpretations Eingabe und Ausgabe empf nger Verarbeitungs mechanismen algorithmen Rezeptoren Manifestoren Prozessoren Eine Anwendungsoberfl che ist in diesem Kontext ein interakti ves System aus e Eingabeempf ngern Rezeptoren e Interpretations und Verarbeitungsregeln Prozessoren e Ausgabemechanismen Manifestoren In kommerziellen Projekten bei Rechenzentren und Banken wird Oberfl che auch al
226. nes Automobilherstellers geplant und umgesetzt Die Konzeption erfolgt nach Anwendungsf llen und beinhaltet auch UI Entw rfe Kritische Projektentscheidung Die Umsetzung wird nach technischen Komponenten ge gliedert beauftragt Das Argument f r diese Entscheidung ist das Senken der Komplexit t einzelner L sungsanteile durch die Orientie rung an den beteiligten technischen Systemen Folgen Die Integration der L sung auf Use Case Ebene liegt im Niemandsland zwischen den plattformgetriebenen L sungsteilen Die konzipierten Benutzeroberfl chen werden in den L sungsteilen zum Teil neu entworfen Das bergehen der Konzepte erfolgt oft unter Hinweis auf Scope und auf die technischen M glichkeiten der jeweiligen technischen Plattform Die vom Softwarehersteller programmierten Oberfl chen sind nicht vorab bekannt Sie stehen erst bei Lieferung der Software fest Tests sind daher nur schwer planbar Beim Test wird festgestellt dass die gelieferten Funktiona lit ten nur l ckenhaft zu den konzipierten Anwendungs f llen und zu den abzubildenden Prozessen passen Use Cases gehen ber die Grenzen von beauftragten Komponenten 214 Projektmanagement Dynamisches Regelwerk wird starr codiert Da nur einzelne Funktionen aber nicht durchg ngige Pro zesse zur Verf gung stehen verz gern sich Test und Pilo tierung der L sung In der Folge berschreitet das Projekt erheblich den Zeit und Budgetra
227. ng der T tigkeit und wie dabei Werkzeuge verwendet werden leiten sich die Existenz Funktion und Konstruktion dieser Werkzeuge ab Am Ende die ses Ableitungsprozesses hat man den Schaltplan des Fernsehge r ts und die Fernbedienung gleich dazu Das Wissen dar ber wie man fernsieht bestimmt wie ein guter Fernseher und ein guter Fernsehsessel gemacht werden Die Klarheit dar ber wie die Software an der Oberfl che verwendet wird schafft Klarheit dar ber was technisch programmiert wer den muss Es funktioniert nicht umgekehrt auch nicht bei Soft ware Heute sind Softwareoberfl chen des t glichen Gebrauchs Be dienpulte f r die in der Software enthaltenen Anwendungsfunk tionen B Rechner U lex Bearbeiten Ansicht C Hax De C Okt CBn Deg C Rad C Grad IT iw IH Sta F E MC R 4 5 DERRERS Pi Zum Beispiel ein Fernseher Am Anfang steht der Use Case Wissen ber das Verwenden bestimmt die m gliche Qualit t der technischen Umsetzung Bild 3 Oberfl chen sind Bedienpulte f r Funktionen der Software Einf hrung Bild 4 Typisches User Interface einer kommerziellen Dialoganwendung Bild 5 Navigieren in kommerziellen Anwendungen In den meisten Anwendungen des B roalltags wird der Anwen der durch einen Dialogfluss aus auszuf llenden Formularen ge f hrt Er f hrt dabei die von der Anwendung vorgesehene
228. ng_bestaetigen 2 Ablaufsequenz ort_und zeitraum festlegen hotel_aus_trefferliste _waehlen kundendaten_erfassen zahlungsoptionen_ festlegen buchung_ueberpruefen und akzeptieren bestaetigung drucken 192 Prozesssteuerung 3 Hierarchie der logischen Schritte hotel_suchen ort_und zeitraum festlegen hotel_aus_trefferliste_waehlen buchung_vorbereiten kundendaten erfassen zahlungsoptionen_ festlegen buchung_bestaetigen buchung_ueberpruefen und akzeptieren bestaetigung_ drucken 4 Transitionen auf Schrittebene und Verwendung von Situatio nen step hotel suchen step ort _und zeitraum festlegen on step exit request search hotels step hotel aus_trefferliste _waehlen on stepexit request set hotel id step buchung vorbereiten on step enter if situation hotel_gewaehlt false on step exit situation kundendaten erfasst true step kundendaten erfassen step zahlungsoptionen festlegen buchung_bestaetigen step buchung ueberpruefen und akzeptieren step bestaetigung drucken 5 Definition von Situationen und Anwendungsdaten situation hotel _gewaehlt datavalue hotel id empty situation kundendaten_erfasst false situation buchungsbereit hotel_gewaehlt amp kundendaten erfasst situation gebucht datavalue buchungs_ id empty datavalue hotel _id datavalue buchungs_ id 9 4 Ablaufstrukturen visualisieren Aus den extrahierten Prozessteuerungsdaten k nnen Prozessgra phen und Ablaufmodelle f r g ngige Modelli
229. nierte Funktion ausgel st die ein definiertes Ergebnis liefert Auf der Ebene von Aktion Reaktion findet hingegen ein gegen seitiges Interpretieren statt Der Anwender trifft Annahmen ber die von der Oberfl che bereitgestellten Informationen Bedie 48 Oberfl che Bild 22 Use Cases Anwendersicht nungselemente und dahinter stehende Funktionen Die Oberfl che trifft Annahmen ber das Wahrnehmen und Agieren des Anwenders und ber die verf gbaren Funktionen und Daten der funktionalen Anwendung Dialog bzw Kommunikation mit dem Anwender im Sinne von Expression und Signalisation ist Teil des Verhaltens einer Soft wareoberfl che Auf Seite des Anwenders und auf Seite der Oberfl che besteht die eigentliche Kommunikation aus Kodie rungen und Entkodierungen in einem gemeinsamen Begriffs raum statt Ebeling 1988 S 97 99 Dieser Begriffsraum wird durch die Ein und Ausgabeelemente der Softwareoberfl che bereitgestellt Use Cases beim Bedienen des Ul Die Verwendungsf lle Use Cases beim Bedienen einer Soft wareoberfl che aus Sicht des Anwenders sind e Die Oberfl che Ausgaben der Anwendung im Kontext der Pr sentation interpretieren e Eingabe und Steuerungselemente bet tigen e R ckmeldung ber laufende Verarbeitung der Eingaben erhalten interpretiert Kontext u Q Merpretiert Anwender i Ausgaben beinhalte Er bet tigt N Bedienelemente benutzt m Oberfl che 295 NS gibt Werte D
230. nlaufs ist genau ein Blatt im Baum der logischen Schritte aktiv In dem gerade aktiven logischen Schritt wartet die Oberfl che auf Ereignisse und reagiert auf diese aus dem Blickwinkel dieses aktiven Schritts Obwohl zu jedem Zeitpunkt nur ein Schritt aktiv ist gibt es Schritte die zugleich mit dem aktiven Schritt semi aktiv bleiben Diese semi aktiven Schritte kommen dadurch zustande dass Schritte hierarchisch gegliedert sind und weil logische Schritte als Dienst im Auftrag von anderen Schritten ausgef hrt werden k n nen Die in der Ablaufhierarchie bergeordneten Schritte ich nenne sie Lead Steps bleiben semi aktiv auf Reaktivierung wartend weil der untergeordnete Schritt z B ein Service Step im Auftrag des bergeordneten Schritts durchgef hrt wird Der Lead Step wird nach dem Ende des untergeordneten Schritts reaktiviert Logische Schritte modellieren 99 Kunden verwalten Kunden A suchen r N Semi Kunden aktive suchen in DB Schritte Zu viele keine Treffer Aktiver anzeigen Schritt Im obigen Beispiel sind dem aktiven Schritt Zu viele keine Treffer anzeigen die Schritte Kunden suchen in DB Kunden suchen und Kunden verwalten hierarchisch bergeordnet und daher semi aktiv Man kann sich die gesamte Anwendungsoberfl che als einen einzelnen logischen Schritt UI ausf hren vorstellen Dieser oberste Schritt gliede
231. nlich einzurichten ist gro Umso entt uschter ist man in der Regel dass das Parkett wieder aufgerissen werden muss wenn die Heizungsbauer kommen Im Vordergrund der ersten User Interface Skizzen stehen die logischen Schritte der Softwareanwendung sowie die Abgren zung des Verwendungszwecks und der Inhalte dieser Schritte Logische Schritte unterteilen das UI der Anwendung in Sequen zen aus in sich abgeschlossenen T tigkeiten bzw Aufgabenstel lungen die der Anwender im Dialog mit der Oberfl che durch f hrt Dabei ist es wichtiger was die einzelnen logischen Schritte be wirken also was am Ende eines Bildschirms oder einer Bild schirmfolge erreicht sein soll als alle Felder der einzelnen Mas ken ausfindig zu machen Oft genug stellt sich heraus dass aus einer Bildschirmmaske zwei werden oder dass mehrere logische Schritte auf einer Bildschirmmaske vereinigt werden In Bezug auf die Oberfl che will man in der ersten Phase eines Softwareentwicklungsprojekts feststellen wie viele und welche Bildschirmmasken die Anwendung in etwa hat wie sich die Masken inhaltlich und bez glich des Einsatzzwecks voneinander unterscheiden und wie sie zueinander in Beziehung stehen 4 1 Methodenwahl F r das Skizzieren und Detaillieren einer Oberfl che k nnen verschiedene Beschreibungsformen verwendet werden Die nachfolgend aufgef hrten typischen Beschreibungsformen f r Oberfl chen sind unterschiedlich abstrakt und variieren von um
232. nn 63 3 4 Werkzeus rten 2 2 22 RM in 70 3 5 Office Werke geer aaisa a an aa a ee ls 70 3 6 Darstellungsorientierte Werkzeuge nenne 71 XIV Inhaltsverzeichnis 3 7 GUI Toolkits und GUI Bibliotheken enenneneenseneenennennnn 71 3 8 Grafische Ablaufmodellierungswerkzeuge eennenneneneennen 72 3 9 Werkzeuge f r eingebettete Systeme enenseneenneneneenenenennne nennen 72 3 10 INUEZETN EE A A E EEN OE 81 Kapitel 4 I VAA R A T A RE O RTI IEAA 83 4 1 MethodenwaM ssie anae a un e aon aia e a leisen 84 4 2 Systemgrenzen abstecken roosa etaar aE a ains 89 4 3 Ablaufstr kt r Torme en 2 a a E e A E EEE EEA 92 4 4 Logische Schritte modellieren sseseeeeeeeeeseiseisrisrrsrrsrrsresrrsrisresesers 95 4 5 Dialoginhalte abgrenzen Edi gan 100 4 6 Nutzen der USKOT oen E EEE EATA 101 Kapitel 5 Detaillieren esssseesecescssesensossnssesensensnsenensssenesee nassen 105 5 1 Perspektiven des Ul Entwickelns eeessensesennennennnnnnnnn 106 5 2 Iterationsmodell 02 she ee ei 109 5 3 Pertiestellungssrad Messen a ae deren als 114 5 4 Nutzen der UI Detailmodelle enseneseneneneeneennenn 116 Kapitel 6 Sprache nah ae ul 119 6 1 Use Cases des UI Modellierens 24neeseeneeneeneennennee nee 121 6 2 Die State Charts Notation naar uns lannn in age 124 6 3 Konzepte f r eine Ul Beschreibungssprache eenee 129 6 4 Datenmodell f r
233. nnungssicherung und kann per Netz strom oder per Batterie betrieben werden Schw chen von State Charts und L sungsans tze Im Abschnitt Typische Ph nomene des Spezifizierens wurde vorgestellt welche Standardanforderungen an die Spezifikati onsmethode beim Beschreiben einer Benutzeroberfl che auftre ten Diese Standardanforderungen betreffen folgende Ph nomene e Ablaufbeschreibung e Vererben und wieder verwenden e Transitionslogik e Kontextabh ngige Pr sentationslogik e Lokalisieren Eine Methode zum Spezifizieren von Benutzeroberfl chen sollte daher die aus diesen Ph nomenen resultierenden Anforderungen ber cksichtigen und Handhabungsm glichkeiten daf r bieten Nach meiner Erfahrung mit dem Spezifizieren von Oberfl chen f r verschiedenste kommerzielle Anwendungen lassen sich UI Spezifikationen nur zum Teil bzw nicht effizient mit State Charts handhaben Wesentliche Schw chen der State Charts Notation beim Einsatz f r das Beschreiben von User Interfaces k nnen sein In Bezug auf Ablaufbeschreibung und Transitionslogik e Es gibt keine Standard Lese und Ausf hrungsreihen folge einer State Chart Die Reihenfolge der Zust nde ei ner State Chart wird durch die Transitionen bestimmt L sungsm glichkeit Einf hren von Standardsequen zen die der Definitions und Lesereihenfolge folgen Erweitern der Zust nde zu Ausf hrungsschritten e Beim Lesen einer State Chart kann man nicht auf Anhieb s
234. nsmodell des Auftraggebers und von der Abstim mung der Vorgehensmodelle aufeinander ab Ausschlaggebend ist dass man im Vorfeld wei woran der Erfolg der Iteration gemessen wird Nur dann ist ein sachlicher Soll Ist Vergleich praktikabel 5 3 Fertigstellungsgrad messen Referenzielle Integrit t Alle in der UI Beschreibung referenzierten Dinge z B logische Schritte zu denen in einer Interaktion verzweigt wird m ssen definiert sein Quantitative Messungen Die quantitativen Messungen k nnen durch Z hlen von logi schen Schritten und Kontrollelementen vorgenommen werden Die statistische Analyse z B wie viele Kontrollelemente hat ein Dialog durchschnittlich und welche Ausrei er gibt es in der UI Beschreibung nach oben und nach unten liefert Anhaltspunkte f r Aussagen ber die Gleichm igkeit und damit ber den Fer tigstellungsgrad bzw ber den Umfang des UI Modells Weitere Ans tze f r das quantitative Messen des Fertigstellungs grades finden Sie im Kapitel Testen Qualitative Einsch tzungen Die qualitativen Einsch tzungen erfolgen durch Bewertung von Stichproben Dabei werden gleicherma en die Ergebnisse der quantitativen Messungen als auch subjektive Einsch tzungen der Projektbeteiligten herangezogen Fertigstellungsgrad messen 115 Eine Form der qualitativen Einsch tzung ist die Bewertung wie stabil also so beschrieben dass keine grundlegenden Ver nde rungen mehr erwartet werden si
235. nte Skins Der UI Entwicklungsprozess kann in folgende T tigkeiten unter teilt werden Grundkonzepte erstellen Anforderungen verwalten und laufend mit Fahrzeugfunk tionen abstimmen Bild 96 Use Cases Map der UI Entwicklung Testen 220 Projektmanagement e Anforderungen modellieren e Modellierte Anforderungen analysieren mittels erstellter Visualisierungen e Optional UI der Anwendung simulieren Prototyping aus f hrbare Spezifikation e Optional Zielcode f r eine UI Umsetzung generieren Vergleichen Sie dazu auch die Aufteilung des UI Entwicklungsprozesses in Iterationen siehe Abschnitt Detaillie rungsstufen im Kapitel Detaillieren In jeder UI Entwicklungsiteration k nnen alle oben aufgez hlten T tigkeiten vorkommen Folgende Rollen sind am User Interface Entwicklungsprozess beteiligt e Entscheider Auftraggeber Projektleiter Architekt e Entwickler Anforderungsingenieur Spezifizierer Prototypenbauer Werkzueugbauer Anwendungs und Systementwickler Qualit tsingenieur Qualit tsmanager Fachspezialist Anwendervertreter Tool Chain Zur Unterst tzung des UI Entwicklungsprozesses sollte die Ver f gbarkeit folgender Werkzeuge bzw Funktionseinheiten sicher gestellt werden e Modellverwaltungswerkzeug e Modelleditor ggf mehrere spezialisierte Editoren e Modellauswerter Modellvisualisierer e UI Simulator mit Styleguide Anbindung d h in
236. ntifiziert das modell als hci spezifikation Wir wollen eine Benutzeroberflaeche beschreiben die Hallo Welt ausgibt und dann mit einem Knopf Ende beendet wird requirement Anf_2 Das Beispiel soll kurz einfach und leicht lesbar sein model revision 1 00 I die modellrevision gibt an um welchen stand der spezifikation es sich handelt lucia revision 1 00 I die notationsrevision gibt an mit welchem stand der spezifikationssprache das modell erstellt wurde Start Step named Hallo Welt using default Screen Im Hallo Welt Beispiel enthaelt unsere Oberflaeche nur einen einzigen logischen Schritt welcher als IO Medium den Bildschirm gleichen Namens nutzt Der logische Schritt selbst ist in unserem Beispiel nicht als Kontrollinstrument aktiv Weitere Einsatzmoeglichkeiten der logischen Schritte werden in anderen Beispielen diskutiert siehe Anf 2 requirement Der Bildschirm dient als Ein und Ausgabemedium fuer den logischen Schritt gleichen Namens in den er ablaufmaessig eingebettet ist Screen named Hallo Welt using Layout Hallo_Anordnung contains Text Hallo Welt placed at titelzeile using Widget spezielles text _widget Button Ende placed at fusszeile vs 142 Sprache using default Widget on command unconditionally leave current Step Layout named Hallo Anordnung I Html ist nur ein Beispiel fuer die Formulierung eines Layouts Hier
237. ntuitiven Spezifi kationsformen zusammenklickbare Masken Listen von Masken elementen bis hin zu detaillierten formalen Beschreibungen z B maschinenlesbare XML Spezifikation skalierbar sein Folgende Faktoren beg nstigen die Akzeptanz einer Entwick lungsmethode f r User Interfaces e Einfach erlernbare Syntax und Semantik der Modelle e Einfache grafische bzw tabellarische Grundnotation e Modellierbarkeit in allgemein gebr uchlichen B roanwen dungen im besten Fall etwa Powerpoint oder Excel mit einem Plugin der Editierhilfe und Modellvalidierung bie tet e Fachleute modellieren in Breite Use Case Entwickler in Tiefe Detailablauf e Absch pfbarkeit Destillierbarkeit d h Herausziehen des Informationsgehalts des UI Modells aus Common Tools z B Office Programme in ein formales Modell UML XML e Vertiefende Modellierungswerkzeuge mit einer Detailnota tion auf UML oder XML Basis e M glichkeit des Round Trip Modelling hin und her Wechsel zwischen Grundform und Detailform des Modells ohne Verlust von Informationen informationen Systemgrenzen abstecken 89 e Umsetzung von WYSIWYG What You See Is What You Get Ans tzen in der Methode 4 2 Systemgrenzen abstecken F r einen ersten berblick ber die geplante Softwareanwen dung ist ein Diagramm hilfreich das die Grenzen des Systems absteckt Das Diagramm zeigt die Anwendersicht auf die Hauptschritte der Anwendung und formt e
238. odell und die Werkzeuge die Programmierspra chen und die Laufzeitplattform weitgehend vorgegeben sind Es geht also darum wie man mit gegebenen Mitteln und in einem gegebenen Projektumfeld das Projektziel sicherer erreicht Best Practice eben Ich verspreche Ihnen nicht dass Sie nach dem Lesen der User Interface orientierten Architektur mehr Qualit t in k rzerer Zeit erreichen oder die Projektkosten senken Mehr und bessere Tur nierkrokodile in k rzerer Zeit mit weniger Geld Das funktioniert nur in der New Economy und die hat ja nur f r wenige funktio niert Ich verspreche Ihnen stattdessen dass Sie besser schlafen k n nen weil Sie genauer wissen was Sie eigentlich bauen oder gebaut kriegen Sie schlafen umso besser weil Sie auch sicher sein k nnen dass Ihr Projektpartner Ihr Auftraggeber Ihr Soft warehersteller das gleiche Verst ndnis davon hat wie die Soft ware die Sie gemeinsam erarbeiten aussieht und funktioniert Die Sicherung der Projektziele wird erreicht indem Risiken sys tematisch eliminiert werden Das kann mit folgenden Maf snah men erreicht werden e Abgestimmte Schnittstellen e Erlebbarer User Interface Entwurf e Durchg ngige und eindeutige Spezifikation von der Soft wareoberfl che bis zu den Systemfunktionen In Bezug auf die Oberfl che kann die Sicherung der Projektziele durch folgende Eigenschaften der Oberfl chenspezifikation er reicht werden e Formulierbarkeit e Erlebbarkeit
239. odellie rung z B mit Maskenentw rfen und Lucia Ergebnis Oberfl che und Pr sentationslogik Modelle des Systeminneren Schwerpunkt Funktionelle Abl ufe Inhalte und techni sche Umsetzung Vorgehen Objekt und komponentenorientierte Modellie rung Modellierung der systeminternen Abl ufe in der Re gel mit UML Ergebnis Gesch ftslogik Kontexthandling technische Komponenten Gemeinsam liefern die Modelle die f r eine h ndische oder eine modellgetriebene Implementierung notwendigen Informationen Beispiel Login Prozedur Eine durchg ngige Spezifikation f r eine Login Prozedur Ober fl chenbeschreibung Ablauf Funktionen und Daten Start Step Anwendungsrahmen on Enter perform Step LoginProzedur Zuerst einloggen on Signal nach dem Einlogversuch pr fen ob eingeloggt when not situations eingeloggt exitStep Service Step LoginProzedur Step Login Eingabe Anwender identifiziert sich Service Step Login In Progress Fortschrittanzeige Service Step Login Error Fehlermeldung im Misserfolgfal Screen Login Eingabe I Eingabe und Bedienelemente Textinput Login Id Textinput Login Password Button ok on Command invokeFunction doLogin goto Step login in progress Oberfl cheneigenschaften mit UML Modellen absichern 179 on Situation Login Parameter Eingegeben inputmode enabled else disabled Button abbrechen on Comm
240. on Listen oder neuen Datenkartenstapeln Tastatur und Bildschirm wurden 1960 zum ersten Mal an einen Computer angeschlossen und l sten unter den Gro rechnerherstellern Panik aus Rose 1985 5 48 Mit dem Aufkommen der ersten dialogisierten transaktionalen Anwendungen in den fr hen 60ern nderte sich an der Bedie nung der Softwareprogramme zun chst wenig da hinter den Dialogseiten meist die bisherigen Batchaufrufe maskiert wurden In den Masken wurden die Parameter f r den Stapellauf einge tragen und mit der Maskenfreigabe an die Prozedur bergeben Oberfl chen ergaben sich damit von selbst aus den Prozedu Die Softwarekrise war der Motor f r systematisches Entwickeln von Software In prozeduralen Anwendungen gibt es keinen Dialog mit dem Anwender Bei dialog transaktionalen Oberfl chen wird der Anwender am Fluss der Transaktionen entlang gef hrt 30 Oberfl che Grafische User Interfaces arbeiten ereignisgesteuert ren Als Abfallprodukt des Funktionsdesigns stellte die Anwen dungsoberfl che keine eigenen Anspr che an die Entwicklung von Methoden zu ihrer systematischen Entwicklung Mit der Zunahme von Dialogtransaktionen wurden Maskenbe schreibungsformalismen entwickelt und in die Programmierspra chen und Entwicklungswerkzeuge integriert z B SDD Structu red Dialog Design in IBMs RPG Report Program Generator Input und Display Befehle in COBOL Common Business Orien ted Language oder
241. on Wertebereichen und diskreten Werten ben tigt man einen Satz von Eingaben die an die Ober fl che geschickt werden und einen Satz von daraufhin erwarte ten Ausgaben der Oberfl che Die von der Oberfl che erwartete Reaktion k nnte durchaus sein dass keine Ausgabe erfolgt die Oberfl che also z B einen Eingabewert der im definierten Wertebereich liegt ohne sich zu beschweren annimmt Ein elementarer Testzyklus ist ein Kreislauf von Ausl ser bis Ergebnis Das hei t Der Testzyklus beschreibt ausgehend von einem bestimmten Punkt im UI die Ausl ser die zu einem an deren Punkt im UI f hren und die dabei vom UI erzeugten Aus gaben Arten von UI Tests 203 e System umwelt oder anwenderinitiierte Aktionsausl ser Interpretieren im Kontext gt Input e Input Funktionen ausf hren gt Output e Output Aufbereitung im Kontext Darstellung gt Ergebnis Quantitative Analysen Quantitative Analysen des UI Modells stellen statistische Informa tionen ber die Oberfl che zur Verf gung Das kann zum Beispiel die Anzahl von Kontrollelementen pro Dialogseite oder die Anzahl von Interaktionen pro Kontrollele ment sein Quantitative Analysen erfolgen durch Z hlen und in Verh ltnis setzen von Bestandteilen zum Beispiel e Anzahl der verschiedenen Modellbestandteile z B logi sche Schritte im Verh ltnis zur Modellgr e e Anzahl der Kontrollelemente pro Dialogbildschirm eines logischen Sch
242. persistierten Daten ermittelt werden muss bietet sich hierf r eine Kontextvariable an die in einem zentralen Kontexthandler zur Verf gung gestellt werden kann Bauen verschiedene Kontextinformationen aufeinander auf dann k nnen sie bereits vorliegende Kontextvariablen heranziehen und erm glichen eine wesentlich nderungsrobustere Controller logik Gleiches gilt f r die bermittlung von eingegebenen Daten an die Anwendung Die Pr fung der Vollst ndigkeit und Plausi bilit t der Eingaben sowie die Weitergabe an die Persistenz schicht k nnen ebenfalls im zentralen Dienst eines Kontexthand lers untergebracht werden Damit k nnen Eingabefelder beliebig auf eine andere Dialogseite verschoben werden ohne dass die Dialoglogik angepasst werden muss Die Anwendung der UI orientierten Architektur auf das MVC Entwurfsmuster erm glicht Produktivit tssteigerung durch e Direkte Ableitung der Pr sentationsschicht aus den Anfor derungen gt View e Erzeugung der Validierungs und Mappingmechanismen gt Controller e Erzeugung des Ger sts f r ein Klassenmodell Daten und Funktionen gt Modell Dialogintensive Gesch ftsanwendungen z B Verwaltungssoft ware Kreditsachbearbeitungssoftware bestehen in der Regel zu mehr als 3 4 aus Dialogmasken und Mapping Bei solchen An wendungen entfallen weniger als 1 4 des Gesamtumfangs auf die Gesch ftslogik Die UML bietet hierf r keine Hilfestellung an denn Oberfl chenabl
243. r die jeweilige Zielplatt form aus den Modelldaten Einsatzziele und Zielgruppe Modellbasierte Spezifikation und Simulation grafischer Oberfl chen On the fly Simulation w hrend der Spezifikationsphase Erstellen eines lebenden Lastenhefts in der fr hen Phase des Entwicklungsprozesses Integrierte Entwicklung von GUI und Sprachdialog in ei nem Werkzeug Verzahnung von Modalit ten multimoda ler Dialog bersicht der Features WYSIWYG What You See Is What You Get View Editor zur Erstellung der einzelnen Bildschirme Views Editor f r UML Zustandsdiagramme zur Beschreibung des Men ablaufs Anbindung von Spracherkennern und Text To Speech Systemen Integrierter Simulator zum prototypischen Ausprobieren der spezifizierten Oberfl che Aufzeichnen und Playback von Bedienabl ufen in der Si mulation Einbindung echter Hardware in der Simulation Projektspezifische Erweiterung durch Plugins Anbindung von projektabh ngigen Java Widgets Multi User f hig f r paralleles Arbeiten an verschiedenen Teilen der Spezifikation Automatische Konsistenz berpr fungen des Modells Darstellung auf Basis der Angaben des Herstellers mit freundlicher Genehmigung der 3Soft GmbH Erlangen und eigener Tests Werkzeuge f r eingebettete Systeme 75 e Speicherung in maschinenlesbarem XML e Spezifikation mehrerer Zustandsmaschinen f r mehrere Displays oder Splitscreens e Der Variantenmechanismus erlaubt
244. rammcode mit wahlfreien Analyse und Bearbeitungswerkzeugen 3 3 Bewertungsschema Im Mindestumfang besteht eine UI Entwicklungsumgebung aus einem User Interface Editor der die Modellierung von UI Eigenschaften mit einer bestimmten Modellierungsnotation erm glicht Die Notation kann z B aus grafischen Symbolen f r Kontrollelemente aus Property Tabellen Code Skripten oder aus grafischen Modellen bestehen Shneiderman formuliert die Ziele einer Notation so Schneiderm 2002 S 325fl e Grundlegende Ziele Pr zision Kompaktheit Leichtigkeit beim Schreiben und Lesen Vollst ndigkeit Unabh ngig vom Werkzeug auf Spezifikationsdaten zugreifen Spezifikationsdaten auswerten und umformen 64 Werkzeuge Geschwindigkeit beim Lernen Einfachheit Fehler zu vermeiden Leichtigkeit sich an das Notierte zu erinnern e Ziele auf h herer Abstraktionsstufe Enge Korrespondenz zwischen Realit t und Notation Bequemlichkeit beim Durchf hren von Manipulatio nen die f r Notationsanwender von Bedeutung sind Kompatibilit t mit anderen Notationen Anpassbarkeit an Anf nger und Experten Ausdruckskraft die die Kreativit t f rdert Visuelle Ansprechbarkeit Anziehungskraft e Einschr nkende Ziele F higkeit des Menschen in der Notation zu schreiben und zu lesen Zusammenpassen der Aufzeichnungs und der Anzei gemedien Bequemlichkeit beim sich Ausdr cken in der No
245. rantworten Bild 87 Beim UI f hlen sich viele kompetent Sorgf ltig aufgebaute UI Modelle besitzen eine gro e Aussage kraft Mit ihrer Hilfe werden verschiedene Bereiche der Entwick lung im Projekt transparent und vergleichbar gemacht Zugleich wird der Stand des Entwurfs von allen Projektbeteilig ten messbar weil man keine Spezialkenntnisse mehr ben tigt um anhand der Oberfl che zu sehen wie weit der Entwurf ge diehen ist Diese Wirkung von UI Modellen stellt die Organisati on des Projekts vor besondere Herausforderungen Zum einen muss vermieden werden dass das User Interface zum S ndenbock wird Ein UI Modell kann andere Entwicklungst tig 210 Projektmanagement Bild 88 User Interface Entwicklung ist ein interdisziplin res Thema keiten nicht ersetzen Daher kann man ein fehlerhaftes Daten modell oder fehlende Funktionen nicht mit Unvollst ndigkeiten in der UI Beschreibung begr nden Dies zu kommunizieren und sicherzustellen liegt in der Verantwortung des Projektleiters Andererseits muss vermieden werden dass das UI Modell ausge grenzt wird Ein UI Modell liefert Informationen ber Zusam menh nge und beg nstigt die Evolution der Anwenderforderun gen Auf diese Weise werden L cken und Fehler in der Konzep tion der Anwendung sichtbar was die Entwickler zur fortlaufenden Korrektur der Funktions und Datenmodelle zwingt Als Abwehrreaktion auf diese fortw hrende St rung k nnen UI Modell
246. rbeizuf hren Obwohl das neue System immer besser sch ner schneller und leichter zu bedienen sein soll stellt sich allzu oft heraus dass sich die Anwender mit der Modernisierung ihrer t glich eingesetzten Software meist bestraft und nur selten geholfen f hlen Vorhandene Softwarel sung BEE it t Abl ufe Eee Schnittstellen Gewachsene Erweiterungen und Anderungen Der meiner Ansicht nach ausschlaggebende Grund f r die Skep sis gegen ber Nachfolgesystemen ist Die neue Software benutzt sich ganz anders Stellen Sie sich Ihr Auto nach Kundendienst vor Da wo fr her das Gaspedal war ist jetzt die Bremse anstelle der Hupe ist der Blinker und da wo der Blinker war ist etwas was sehr sch n aussieht aber dessen Funktion kein Kollege kennt Muss das sein H tten Sie gerne dass man Ihnen in Ihr Auto beim n chs ten Servicetermin erst ein f nftes Rad einbaut und dass Sie dann noch den F hrerschein neu machen m ssen Das ist berspitzt formuliert aber es k nnte in etwa die Gef hls vorstellung der Anwender ber neue Softwarel sungen und Release Wechsel treffen Bild 100 Etablierte Softwarel sungen sind oft organisch gewachsen 226 Lebenszyklusmanagement Beispiel Funktional orientiertes Reengineering Das folgende Beispiel zeigt Hinweise auf m gliche Ursachen des reservierten Anwenderempfindens bei Systemwechseln auf Die MoneyExperts Bank AG hat viel G
247. rd ebenfalls 1 1 Code generiert Zur heutigen Landschaft der Anwendungsentwicklung geh ren auch die Paradigmen der MDA welche uns nahelegt weite Teile der Anwendung in Form von oben erw hnten und weiteren Modellen zu beschreiben und daraus den herk mmlichen Pro grammcode und oder Steuerungsdaten zu generieren Als Kriterien f r das Anwenden der MDA werden dabei e Kapselung von Implementierungsdetails also Komplexi t tsreduktion und Wiederverwendbarkeit e Redundanzvermeidung also Integrit ts und Qualit tser h hung sowie die e Generativit t also Robustheitssteigerung und Senkung von nderungskosten Das klingt gut H here Produktivit t in h herer Qualit t zu klei neren Kosten Fast wie New Economy Nur die Frage danach was wir modellieren sollen und was wo raus sollen wir was generieren beantwortet uns die MDA Evangelisten mit Schulterzucken na eben beliebig ois model lieren ois generieren Umsetzung von MDA Paradigmen in der Praxis 170 Architektur Pr sentationsobjekte UI Objekte Gesch ftsobjekte Systemobjekte Kommen wir aber aus dem Kontext der heutigen Landschaft der Softwareentwicklung zur ck zu den Anforderungen an MDA freundliche Werkzeuge zur UI Entwicklung Eine Form der MDA ist dass man Codeschnipsel die sich auf der Implementierungsebene wiederholen ins Modell schiebt und damit die Implementierung parametrisiert Hierbei entstehen Konfigurationsdateien Ein
248. re praktisch die schon bestens bekannten UI Perspektiven mit der State Charts Notation modellieren zu k nnen Statecharts bieten jedoch keine Unterst tzung zum Aufteilen der UI Beschreibung in Perspektiven und beim gegenseitigen Ver kn pfen von Darstellung Verhalten und Kontext Unter diesem Vorzeichen folgt die Analyse welche Erweiterun gen an State Charts vorgenommen werden sollten damit UI Perspektiven abgebildet werden k nnen Die Analyse liefert die Konzeptgrundlage f r eine UI Beschreibungssprache die e die Gliederung der Beschreibung in UI Perspektiven er m glicht e eine Handhabe f r typische Ph nomene des Ul Spezifizierens bietet Perspektiven und Querverweise Zentral definierte Ressourcen Ziel UI Perspektiven abbilden und typische Ph nomene die beim Spezifizieren auftreten z B Varianz handhaben 130 Sprache Verbund aus spezialisierten State Charts e und an die Ausdrucksm glichkeiten von Statecharts ange lehnt ist Hierzu erweitere ich die Semantik der State Charts da wo sie die oben aufgezeigten Schw chen aufweisen Ul Perspektiven abbilden Statecharts bieten keine Notation f r das Aufteilen einer User Interface Spezifikation in verschiedene Sichten Anforderungen Ablaufstruktur Dialoge Interaktionen Kontext blicherweise werden diese Sichten in einer State Chart nicht getrennt Das f hrt schnell zu komplexen und un bersichtlichen Diagrammen Zur Abbildun
249. rface stehen Sie wurden seit ihrer Erfindung nicht wei ter f r die Oberfl chenentwicklung spezialisiert und entwickelt sondern sind seit ber 20 Jahren in ihrer Ursprungsform stabil geblieben Diese Stagnation steht ganz im Gegensatz zur Daten und Funk tionsmodellierung wo der Wettbewerb der Modellierungsme thoden die Konvergenz und die Erweiterung der Formen an treibt Die State Chart Notation bietet eine Basis f r die Beschreibung von Abl ufen und Interaktionen in einem User Interface Das Informationsgeflecht einer UI Beschreibung geht jedoch ber die Ausdrucksm glichkeiten von State Charts hinaus vgl Abschnitt Leitfragen der UI Beschreibung im Kapitel Oberfl che Es folgt eine kurze Analyse der Ausdrucksmittel der State Chart Notation Ein Schwerpunkt dieser Analyse ist wie gut sich die aus den Kapiteln Oberfl che Skizzieren und Detaillieren bekannten Perspektiven einer UI Beschreibung durch State Charts abbilden lassen Elemente der State Charts Notation Die zentralen Elemente der State Chart Notation sind der State Zustand und die Transition bergang State Charts haben folgende Notationselemente e Zustandstafel H lle einer State Chart e Zust nde e Start und Endzust nde e Pseudozust nde z B Kreuzung und Vereinigung e Transitionen berg nge mit Ausl sern Bedingungen und Reaktionen e Zustandsaktivit ten Der Zustandsname wird in einem Rechteck mit abger
250. rfl che Diese Sicht wird implizit und explizit jederzeit dann verwendet wenn in einer anderen Sicht eine Bezugnahme definiert wird und hier zu ein entsprechendes Bezugsziel festgelegt werden soll In die ser Perspektive werden Schnittstellen festgelegt Die Interaktionsperspektive ist eine Vertiefung der Dialog und Strukturperspektive Sie beschreibt an welchen Strukturstel Bild 47 Verschiedene Sichten auf die Oberfl che 108 Detaillieren Bild 48 UI evolution r aus wechselnden Perspektiven entwickeln len und in welchen Dialogstellen auf das Auftreten welcher Er eignisse welche Reaktionen folgen Diese Sicht sollte man nach Festigung der Struktur und nach Abgrenzung der Dialoginhalte ausformulieren Im iterativen Ansatz erfolgt der Aufbau der UI Spezifikation stu fenweise durch abwechselnde Betrachtung von Anforderungen Struktur Dialogseiten Ressourcen und Interaktionen in definier ten Detaillierungsstufen In der Spezifikation einer Softwareoberfl che wirken die ver schiedenen Modellierungsperspektiven e Anforderungsperspektive e Strukturperspektive e Dialogperspektive e Interaktionsperspektive e und Kontext bzw Ressourcenperspektive zusammen und bilden gemeinsam den Spezifikationsstand der jeweiligen Iteration Beim Spezifizieren werden die verschiede nen Perspektiven miteinander verwoben Ziel des iterativen Vorgehens ist dass die Spezifikation mit dem Vollziehen jeder Iteration auf
251. rift verwendet werden Button Ende placed at fusszeile using default Widget on command unconditionally leave current Step legt fest dass der mit Ende beschriftete unbenannte Command Button an der Layoutposition fusszeile angezeigt werden soll Zum Rendering des Buttons soll dabei ein generisches Widget z B der von Windows bereitgestellte Pushbutton verwendet werden Wenn der Button geklickt wird soll der Screen und der Step Hallo_Welt und damit die Anwendung verlassen werden Beim Dr cken des Buttons sollen keine Bedingungen gepr ft und keine R ckfragen etwa Sind Sie sicher gestellt werden Die vielf ltigen M glichkeiten der Situationspr fung und der Reaktion auf Eingaben und Kommandos werden anhand von anderen Beispielen verdeutlicht Layout named Hallo_Anordnung leitet die Definition eines Layouts ein Das Layout beschreibt eine Schnittstelle zur Darstellungsebene der Oberfl che Im Layout k nnen die statischen Anteile von Screens beschrieben und der Screen in Bereiche unterteilt werden Die Beschreibung des Layouts kann in einem beliebigen Format erfolgen und ist von Lucia nicht definiert Zur Lucia Sprache geh ren lediglich die Platzhalter auf die sich Dialogelemente zur Positionierung mit placed at platzhaltername beziehen k nnen Ein Positionierungsplatzhalter wird mit placeholder named platzhaltername festgelegt 146 Sprache Zur Festlegung von Layouts bie
252. rithmen kann der Spezifikationsstand zum Beispiel als lauff higer Prototyp der Oberfl che bereitgestellt und so schon vor der Implementierung gepr ft werden Integriert man solche Transformationsalgorithmen in die Architektur der An wendung dann kann die Umsetzung der Oberfl chenbeschrei bung in die ablauff hige Oberfl che drastisch verk rzt werden Das er ffnet f r Entwickler und Anwendervertreter neue M g lichkeiten die anhand von Praxisbeispielen erl utert werden Inhalte der User Interface Architektur 19 Kapitel 8 Funktionsmodellierung in dem UI Modelle und UML Modelle z B Use Cases Klassen Abl ufe zusammen an gewandt werden sich erg nzen und gemeinsam wirken Das UI beeinflusst die Funktionen und die internen Abl ufe der Software Umgekehrt beschr nken Funktionen des technischen Softwaresystems die M glichkeiten des User Interface Die UI Modellierung verzahnt sich daher eng mit der Modellierung der internen Strukturen und Abl ufe in der brigen Software Das Kapitel zeigt wie Informationen aus UI Modellen in UML Modelle einflie en und dort weiterverwendet werden k nnen Ebenso wird aufgezeigt wie UI Modellierung im Kontext bereits vorhandener Funktions und Ablaufmodelle erfolgreich und ein ander erg nzend durchgef hrt werden kann Die Verbindung von g ngigen Modellierungs und Konzeptions methoden mit der UI Modellierung f hrt zu einem ausgewoge nen Ganzen Entwickler finden in
253. ritts e Anzahl der Modellbestandteile pro Modellierungsiteration Wieviele Modellbestandteile sind auf welchem Fertigstel lungsstand gekennzeichnet e Mengenger st bersicht der Modellbestandteile nach Per spektiven Aussage ber die Gleichm igkeit des Modells Qualitative Analysen Anhand von Erwartungswerten an Quantit ten und anhand der tats chlichen Quantit tsverh ltnisse k nnen Qualit tsverbesse rungspotentiale in der Oberfl che identifiziert werden Qualit t wird anhand des Eindrucks beurteilt die einzelne Pro duktteile und das Gesamtprodukt auf den Tester machen Quali tative Analysen k nnen helfen die Qualit tsbeurteilung nach vollziehbarer zu machen Zum Beispiel k nnte die Regel gelten dass auf einer Dialogseite zwischen 15 und 35 Kontrollelemente erwartet werden Die qua litative Analyse w rde auf Dialogseiten hinweisen die nicht in diesem Bereich liegen und daher m glicherweise unvollst ndig lt 15 oder zu komplex gt 35 sind 204 Testen Bild 85 Vorgehenskarte f r das automatisierte Testen des UI Weitere Beispiele f r qualitative Analysen sind e Konsistenzchecks ist das Modell in sich geschlossen e Redundanzchecks sind gleiche Sachverhalte nur einmal definiert oder werden Definitionen wiederholt e Layoutchecks ist das Layout der Dialogseiten konsistent Ebenfalls aussagekr ftig ist das Aufzeichnen der zeitlichen Ver nderungen von qualitativen Merkmale
254. rive Spezifikation 80 Werkzeuge Teledrive Simulation rm SETUP FORT I is jan Hierarchical Widget Editor Ein Widget kann aus BaseWidgets und oder wiederum aus ande ren Widgets zusammengestellt werden Hierf r werden die Ele mente des Basic Widget Pools als Vorlage benutzt Neu definier te Widgets werden automatisch in einen User Defined Widget Pool f r eine sp tere Wiederverwendung eingef gt Widget Preview Nach der Zuordnung von Graphikdateien zu Men s oder Wid gets kann der Benutzer ber eine statische Vorschau das Er scheinungsbild von Men s visuell pr fen Die Zuordnung kann w hrend der Bearbeitungszeit gew hlt werden Die Vorschauda ten werden zusammen mit den Projektdaten persistent gehalten Behavior Editor Dieser Editor dient zur Erstellung und Bearbeitung des Verhal tens von Widgets Er unterst tzt den Entwurf des Verhaltens unter anderem durch Zustandsmaschinen Dar ber hinaus ist es m glich externe Funktionalit t zu integrieren Generieren von Dokumenten Aus dem HMIStudio k nnen projektspezifische Dokumentatio nen erzeugt werden Unterst tzt werden die Formate DOC Winword und HTML Resourcen Management Attributwerte wie z B Texte Positionen Farben und Bitmaps k nnen durch den Benutzer zu Ressourcen erkl rt werden Nutzen 81 Weitere Werkzeuge f r das gesamte Ul Neben den vorgestellten Werkb nken zur durchg ngigen En
255. rn Pflege vereinfachen Auch wenn diese Aufstellung mehr die Ziele der Verwendung von UI Werkzeugen als deren tats chliche Features adressiert liefert sie eine Ausgangsbasis f r das Formulieren konkreter An forderungen Anhand der Use Cases bei Spezifikation Realisierung und Test von Benutzeroberfl chen siehe auch Abschnitt Use Cases des UI Modellierens im Kapitel Sprache werden aus Sicht der UI orientierten Architektur folgende Anforderungen gestellt Vokabular zur UI s Spezifikation UT Bestandteile R kennzeichnen Spezifikationsst nde a vergleichen nderungen u verwalten und nachvollziehen Gemeinsam an e einer UI Beschreibung arbeiten Vokabular zur Spezifikation von Ablaufstruktur Bedie nungselementen Layout Interaktionen sowie Kontext und Anforderungsbez gen der Benutzerschnittstelle UI Definition Stufenweise detaillieren M glichkeit die UI Spezifikation stufenweise von einer groben Skizze zu einer Umsetzungsvorschrift zu detaillie ren M glichkeit Bestandteile der Spezifikation bez glich Fertigstellungsphase Fertigstellungsgrad in der jeweiligen Phase Review Status im jeweiligen Fertigstellungsgrad auf beliebiger Gliederungsebene zu kennzeichnen Unterst tzen von Vergleichen zwischen Spezifikations st nden z B Delta Analyse Kennzeichnen und Wieder herstellen eines Spezifikationsstandes Unterst tzen der nderungsverwaltung z B nderun
256. rschiedenen Spezialisierungen und Kompositionen aus diesen Grundtypen Allen logischen Dialogelementen ist gemeinsam dass sie Infor mationen zur und von der Darstellungsebene hin und her trans portieren Der Informationsgehalt ist dabei abh ngig vom logi schen Typ des Dialogelements z B dient eine Auswahlliste zur Auswahl aus den angebotenen M glichkeiten ein Button hinge gen zum Aktivieren einer bestimmten M glichkeit jedoch un abh ngig vom Look And Feel auf der Darstellungsebene z B ob die Auswahl ber RadioButtons oder ber eine DropDown Listbox getroffen wurde ist f r die logische Ebene unwesent lich UI Beschreibungssprache Lucia 145 Logische Dialogelemente sind mit einer Reihe von Eigenschaften ausgestattet mit denen ihnen Ein und Ausgabeinhalte Situatio nen und Interaktionen auf denen sie operieren zugewiesen werden Die Schnittstelle des logischen Dialogelements zur Dar stellungsebene wird ebenfalls durch Eigenschaften ausgedr ckt In unserem Hallo Welt Beispiel benutzen wir zur Veranschauli chung der Screenbeschreibung zwei logische Dialogelemente Text und Button mit wenigen Eigenschaften Text Hallo Welt placed at titelzeile using Widget spezielles_text_widget legt fest dass der Text Hallo Welt an der Layoutposition titel zeile ausgegeben werden soll Zur Darstellung des Texts soll dabei die im Widget spezielles_text_widget festgelegte Rende ringvorsch
257. rt sich in eine Hierarchie von untergeord neten Schritten Im Beispiel hei t das Wenn der hierarchisch oberste logische Schritt Kunden verwalten zu Ende geht wird damit auch die Anwendungsoberfl che beendet Kunden Ao verwalten Mit der Kundenliste arbeiten Semi aktive Schritte Kundenkarte ansehen ndern lt lt service gt gt Kundenkartei synchronisieren Aktiver Schritt Das zweite Beispiel zeigt einen Service Step Kundenkartei syn chronisieren der aus einem nicht hierarchisch bergeordneten Schritt heraus aktiviert wird Auch hier gilt Der aufrufende Schritt bleibt semi aktiv und wird nach dem Ende des Service Steps reaktiviert Aus Sicht der Laufzeit kann man die logischen Schritte einer Anwendungsoberfl che also zusammenfassend in drei Gruppen unterteilen Bild 43 Aktiver Schritt und hierarchisch semi aktive Schritte Bild 44 Aktiver Schritt und orthogonal semi aktive Schritte 100 Skizzieren e Aktiver Schritt e Passive oder semi aktive Schritte e Unbeteiligte Schritte Der aktive Schritt ist der Schritt der gerade ausgef hrt wird Die passiven oder semi aktiven Schritte sind alle Schritte die vor dem aktiven Schritt begonnen aber nicht beendet wurden Alle anderen in der Ablaufstruktur definierten Schritte sind un beteiligt spielen also zu diesem Zeitpunkt der Laufze
258. rt werden Lebenszyklusmanagement hat das Ziel den Einsatz einer unter nehmensweiten Softwarel sung ber lange Zeitr ume hinweg so zu planen und zu organisieren dass Paradigmenwechsel und Life Cycle Management Bild 98 Gewachsene Anwendungen werden immer weniger berschaubar 224 Lebenszyklusmanagement Abenteuer Systemwechsel Bild 99 Neue Software kann man unterschiedlich empfinden technologische nderungen rechtzeitig erkannt und ber cksich tigt werden User Interface orientiertes Lifecycle und Cross Lifecycle Management kann besonders bei folgenden Situationen zum Senken dieser Risiken zum Vermeiden von Verwendbarkeitsver lusten und zum Erhalt des Werts einer Softwarel sung beitragen e nderungsanforderungen Change Requests e Release Planung stufenweise Realisieren von Features e Technisch bedingte Migration der Softwarel sung in eine andere Laufzeitumgebung e Ersetzen einer bestehenden L sung durch eine Standard l sung i d R mit Customizing kundenindividuelle Konfi guration Anpassung und Erweiterung der Standardl sung e Ersetzen einer bestehenden L sung durch Reengineering auf einer anderen technischen Plattform e Austausch des Front Ends Kapselung des Altsystems i d R Hostanwendung als Serviceschicht f r ein neues User Interface z B ein Thin Client im Web Browser Gro e Softwarel sungen mit denen oft das wirtschaftliche Funk tionieren der sie einsetze
259. rte Arbeitsschritt Bestandteil des Standardablaufs oder eine Ausnahme bzw ein Dienst ist Die Eigenschaft Modalit t kennzeichnet den bevorzugten Kommunikationskanal des Steps d h ob und auf welchem Weg Grafischer Dialog Sprachkommandos etc der Step haupts ch lich mit dem Anwender verkehrt Logische Schritte als Sequenz ausf hren Services mit innen liegenden Sequenzen 98 Skizzieren Die Modalit t hat klassifizierenden Charakter und wird vor allem zu Validierungs und Abfragezwecken auf Ebene der UI Beschreibung verwendet Eine einschr nkende Auswirkung auf die zu einem Step geh renden Dialogelemente und auf deren Ausf hrung hat die Modalit t nicht In einem Dialog k nnen zum Beispiel Kontrollelemente f r Sprachkommandos und Mausbe dienung kombiniert sein Falls keine Modalit t angegeben wurde hat der Step die neutrale Modalit t LogicalStep was bedeutet dass keine Modalit t bevor zugt wird Weitere Modalit ten sind DialogStep GuiStep Voi ceStep und MachineStep Die im Diagramm angedeuteten weiteren Kennzeichen zeigen z B das Erben von Eigenschaften von anderen Steps oder die Verwendung eines Steps als Schablone an Ebenso kann es not wendig sein parallel auszuf hrende Schritte zu kennzeichnen oder anzuzeigen dass aus einer Gruppe von Schritten nur einer ausgef hrt werden soll oder dass ein Schritt optional ist Aktive passive und unbeteiligte Schritte Zu jedem Zeitpunkt des Oberfl che
260. s Frontend und der funktionale Teil der An wendung als Backend bezeichnet Entsprechend dem Zweck der ber die Oberfl che zug nglichen Funktionalit t manifestiert die Anwendungsoberfl che in geord neter Weise das Empfangen das Interpretieren und das Ver arbeiten von Aktionen des Anwenders und von Signalen des funktionalen Systems unterhalb der Oberfl che In den Grundz gen ist dieses Schema der vermittlerischen Funk tionsweise einer Softwareoberfl che analog zu den koordinie renden Aufgaben eines Betriebssystemkerns Kidder 1982 S 140ffl Experimentelle User Interfaces und die KI Forschung K nstliche Intelligenz liefern f r die Softwareoberfl chen des t glichen Gebrauchs Ans tze f r plastische Erkl rungsmodelle Rose 1985 S 60fl So kann man zum Beispiel die Zusammenarbeit zwischen einer Oberfl che und der funktionalen Anwendung mit dem Zusammenspiel zwischen Sinnesorganen Gehirn und K rper funktionen vergleichen Interaktion und Mechanik Interaktive Werkzeuge k nnen in materielle und immaterielle Systeme gegliedert werden Ein Buch ist materiell und unterliegt dadurch physisch mechanischen Gesetzen Software ist imma teriell Sie unterliegt keinen mechanischen Gesetzm igkeiten Dies ist eine ihrer St rken und zugleich ein Risiko Bild 18 Empfangen Interpretieren Verarbeiten Manifestieren Oberfl che Frontend Anwendung Backend Software Funktioniert nicht mechanisch 44 Oberfl ch
261. s Interpretieren und Ausf hren der Anwenderanweisung hnlichkeit mit der Arbeitsweise ei nes Command Line Interpreters Oft werden VUIs mit anderen IO Modalit ten wie Zei cheneingabe ber Tastatur z B DTMF Signale an Telefo nen oder mit GUIs z B in Fahrerassistenzsystemen kombiniert Haptische User Interfaces HUI HUIs reagieren auf Bewegungen des Benutzers z B durch Datenhandschuh oder durch Kamerabeobachtung Sie k nnen auch mit haptischen R ckkopplungen kombi niert sein Beispiele f r haptische User Interfaces sind Virtual Reality oder Augmented Reality Ein repr sentatives Beispiel f r ein UI mit haptischer R ckkopplung sind Flugsimulatoren bei denen z B Be schleunigung und Bremsen f r den Anwender k rperlich sp rbar sind Horizontale und vertikale Oberfl chen Man kann in einer Anwendungsoberfl che zwischen einer bori zontalen ablauforientierten und einer vertikalen bear beitungsgegenstandorientierten Bedienungsform unterschei den Oft werden in einer Softwareanwendung beide Bedienungsfor men nebeneinander und miteinander vermischt angewandt Je nachdem welche Bedienungsform berwiegt kann man die gesamte Anwendungsoberfl che als vertikal oder horizontal be zeichnen Sprachsteuerung Steuerung durch K rperbewegung 42 Oberfl che Vertikales User Interface Horizontales User Interface Vertikale User Interfaces sind solche in denen Objekte direkt manipulier
262. s Kontexthandlings verstan den werden und sollte in einer eigenen Softwarekomponente umgesetzt werden N heres hierzu finden Sie im Kapitel Archi tektur Querverweise Kapitel 10 Dokumentation in dem die Informationen aus dem User Interface Modell zum Ger st f r Handb cher und f r das Hilfesystem werden Kapitelziele e Handbuch und Hilfe zeitgleich mit der Software liefern e Automatisierte bernahme der anleitenden und beschrei benden Teile des UI Modells in das Ger st der Benutzerdo kumentation e Automatisches Erzeugen von Screenshots aus der Bild schirmbeschreibung in der UI Spezifikation e Informationen ber nderungen am UI automatisiert an Verfasser der Dokumentation liefern z B auf neu hinzu gekommene oder enifallene 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 Soft wareoberfl 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 Funktionali t ten zu weiteren Irritationen der Anwender Es ist daher von Nutzen wenn bereits mit der ersten UI Version die vom Entwicklungsteam bereitgestellt wird
263. s sind zum Bei spiel not_startable startable started done_ok done_needs_corrections done_but_failed done_but_failed_finally unnn unnun Damit l sst sich f r jeden logischen Schritt der Anwendung der aktuelle Status festlegen und feststellen Auf der Basis dieser elementaren Statusmarken k nnen dann die f r die Anwendung spezifischen Situationen durch logische Ausdr cke beschrieben werden Weitere Beispiele fahrzeug_faehrt data geschwindigkeit lt gt 0 vorgang abgeschlossen situations geprueft and situation genehmigt and situation gebucht 9 2 Ablaufsteuerungsdaten extrahieren Die in der Prozesslogik definierten Statusmarken sind in fast allen F llen genauso auch f r die Gesch ftslogik relevant Es bietet sich daher an das f r das UI definierte Regelwerk zur Workflowsteuerung auch f r die Gesch ftslogik bereitzustellen Der Nutzen ist hoch Ein gemeinsames Regelwerk f r UI und f r interne Kontrollfluss Entscheidungen senkt den Aufwand f r Erstellung und Pflege der Anwendung Die redundanzfrei defi nierten Regeln verhindern Inkonsistenzen zwischen UI und Ge sch ftslogik und sorgen f r eine flexible und nderungsrobuste Anwendung Hierzu m ssen die Prozessregeln und die Situations Statusmarken aus der UI Beschreibung herausgeparst und als Steuerungsdaten oder als generierter Code in der Entwicklungs umgebung der Anwendung bereitgestellt werden Dieser Auf wand zahlt sich aus we
264. schicht wieder sp rbar gemacht Dadurch ist auch sichtbar geworden wieviel von der Anwendung potentiell Pr sentationsschicht ist Damit ist auch sp rbar geworden wel che komplexen IO und Interpretationsvorg nge in einer Ober fl che enthalten sind Das Web durchbricht aber auch die Grenzen zwischen Einzel anwendungen und erm glicht die Fokussierung auf Prozesse und Workflows Anwendungen werden ber das Web global miteinander vernetzt Von Thin Clients zur SOA und weiter zur User Interface orientierten Softwarearchitektur Die Welten der zentralen und funktionsorientierten Transaktio nen und der lokalen und anwenderorientierten Interaktionen mit ihren jeweiligen Vorteilen und Wechselwirkungen sind durch Web Oberfl chen in ein produktives Spannungsfeld getreten Oberfl che gliedern 33 Die Entwickler von Web Anwendungen arbeiten zum Beispiel mit Net und Active X DHTML und JSP oder mit ZOPE und Py thon zwar in verschiedenen Lagern doch zieht man dabei durchaus am gleichen Strang N mlich wieder den Komfort der Fat Client Verh ltnisse einzuf hren Die Bem hungen der Softwarehersteller zielen darauf ab das aus der Fat Client Welt gewohnte Interaktionslevel in die Web Client Welt zu bertragen Dies ist an sich kein systematisches Problem sofern das Netz gen gend Bandbreite zur Verf gung stellt Wenn jedoch zum Beispiel durch Net die Grenze zwischen Transaktion und Pr sentation wieder weich wird k nn
265. schiedenen Teilen einer Softwareoberfl che Das Ergebnis dieser informationellen Analyse eines User Inter face ist ein Gliederungsger st f r das Beschreiben der Benut zerschnittstellen von Softwareanwendungen Zu dieser Grundgliederung geh ren Abl ufe und Inhalte sowie Wechselwirkungen und Beziehungen zwischen den Oberfl chenbestandteilen Anwendungsfunktionen und Anforderungen Auf diese Strukturierungsgrundlage die ich UI Perspektiven nenne wird die User Interface Architektur in allen Kapiteln zu r ckgreifen und aufbauen Sie k nnen lernen mit diesen Per spektiven in unterschiedlichen Phasen des Softwareprojekts um zugehen und so verschiedene Aspekte der Oberfl che zu sehen und zu entwerfen Eine UI Gliederung nach UI Perspektiven kann zum Beispiel zum e Vergleichen des Informationsgehalts von verschieden um gesetzten Oberfl chen oder zum e Bewerten der Vollst ndigkeit einer zur Pr fung vorgeleg ten Oberfl chenbeschreibung herangezogen werden Sie k nnen die UI Perspektiven auch verwenden um e oberfl chenrelevante Informationen in einen Gesamtzu sammenhang einzuordnen und die e UI Beschreibung schrittweise von der ersten Skizze bis zu einer umsetzungsreifen Detailspezifikation der Software oberfl che zu erg nzen Historische Entwicklung der Softwareoberfl chen 29 2 1 Historische Entwicklung der Softwareoberfl chen Seit den Anf ngen der Softwareentwicklung gibt es gute und s
266. se und iterative Entwickeln einer Softwareoberfl che Innerhalb der Phasen k n nen die Iterationen beliebig zugeschnitten und so in das projekt spezifische Vorgehensmodell z B Kombination mit dem V Modell eingegliedert werden Quelle http www 128 ibm com developerworks rational library content RationalEdge jan0 1 WhatIstheRationalUnifiedProcessJan01 pdf Bild 49 Rational Unified Process 110 Detaillieren Detaillierungsstufen In Anlehnung an die in RUP aufgestellten Entwicklungsphasen und deren T tigkeitsschwerpunkte kann man das Modellieren eines User Interface in die Hauptiterationen UI Inception UI Elaboration UI Construction und UI Transition einteilen Bild 50 UI Inception Elaboration Construction Transition Den Detaillierungsstufen bzw Hauptiterationen des Ul Entwickelns kann man wie folgt Schwerpunktt tigkeiten und Fertigstellungsgrade zuordnen UI Inception ist im UI Inception Kapitel Skizzieren inhaltlich abgrenzen beschrieben Umfang skizzieren Gliederung skizzieren Bedienungskonzept skizzieren Kernanforderungen sammeln Kerninhalte sammeln e UI Elaboration sammeln und ordnen gliedern und strukturieren Detaillieren der Struktur Detaillieren der Dialogsicht e UI Construction formen und verkn pfen Detaillieren des Verhaltens Detaillieren des Bedienungskonzepts e UI Transition in Kontext einbetten Restriktionen ausformuliere
267. se zwei Fragestellungen zu kl ren entwickeln e Wie erreicht man in der UI Beschreibung schrittweise den Informationsgehalt f r eine vollst ndige Implementierung der Oberfl che e Wie kl rt man in der UI Beschreibung schrittweise die fachspezifische Bedeutung der einzelnen UI Bestandteile 6 2 Die State Charts Notation Eine gute Ausgangsbasis f r das Aufstellen einer formalen Be schreibungssprache f r Softwareoberfl chen liefern auch die State Charts Die im Kapitel Werkzeuge vorgestellten UI Modellierungsplattformen Guide und Teledrive enthalten jeweils einen State Chart Editor State Charts Zustandstafeln sind eine Erweiterung von Zu standsautomaten In beiden Konzepten geht es um die Beschrei bung von Maschinenzust nden State Charts erweitern das Kon zept der urspr nglichen Mealy und Moore Zustandsautomaten um hierarchische Vererbung und um die so genannte Orthogo nalit t Gleichzeitige Existenz von mehreren Zustandsabfolgen State Charts werden oft als eine Standardnotation zur UI Beschreibung angef hrt Ceri 2003 Shneiderm 2002 Der ur spr nglich von David Harel als Erweiterung von Zustandsauto Die State Charts Notation 125 maten erschaffene Formalismus der State Charts Harel 1987 ist Teil der UML und wird dort Zustandsdiagramm genannt Bemerkenswert ist dass die State Charts nicht in Konkurrenz mit anderen Formalismen zum Beschreiben von Abl ufen in einem User Inte
268. sich wechselnden Anwenderforde rungen ausgesetzt und kommen mit der Codierung dem sich st ndig ndernden Prototypen nicht hinterher In der Zielarchitektur wird die Ablauflogik starr codiert Die gew nschte Flexibilit t der Pr sentations und Ablauf regeln kann vom Hersteller in der Zielarchitektur nicht umgesetzt werden In Folge wird das Projekt wegen Un vereinbarkeit von Architektur und Konzeption eingefroren und sp ter mit einem anderen Hersteller neu konzipiert und realisiert Rollen und Aufgabenteilung bei der UI Entwicklung 215 Die obigen Szenarien sind an wirkliche Projektsituationen ange lehnt In der Folge haben diese Projekte den vorgesehenen Zeit und Budgetrahmen erheblich berschritten Nach meinem Da f rhalten h tte die st rkere Ausrichtung an User Interface Entw rfen diese Projekte erfolgreicher machen k nnen Die schon erw hnte Integration des UI Entwurfs in das Entwick lungsvorgehen spielt dabei eine gro e Rolle Besonders wichtig ist eine klare Aufteilung von Rollen und Aufgaben zwischen den Entwicklern des UI und der funktionalen Anwendung vgl Kapi tel Funktionsmodellierung sowie zwischen den einzelnen an der UI Entwicklung beteiligten Personen 12 4 Rollen und Aufgabenteilung bei der Ul Entwicklung Das folgende Diagramm zeigt die typischerweise an der Entwick lung einer Oberfl che beteiligten Hauptrollen Das sind e Anwendervertreter Konsumenten e Spezifizierer
269. sign Werkzeuge bieten in der Regel umfangreiche Unter st tzung f r das Screen Design Oft stellen sie Bibliotheken von Dialogbausteinen und Kontrollelementen die bereits f r die Zielplattform zugeschnitten sind zur Verf gung Die unterst tz ten Ul Sichten sind Dialogperspektive und Strukturperspektive UI Darstellung im Vordergrund UI Implementierung im Vordergrund 88 Skizzieren Akzeptanzkriterien einer Methode zur UI Entwicklung Die Codierung des Oberfl chenentwurfs in einer Programmier sprache bietet den maximalen Grad an Flexibilit t unterst tzt jedoch kein Anforderungsmanagement keine modellgetriebene Vorgehensweise keine Technologiekapselung keine Wieder verwendung und keine Aufteilung der UI Beschreibung in UI Perspektiven Kriterien der Methodenwahl Der Werdegang einer Oberfl che beginnt mit ersten Anforderun gen Der Weg des Entwurfs f hrt von ersten Skizzen ber aus f hrbare Prototypen bis zu einer implementierungsreifen Detail spezifikation Bei der Wahl von Methoden und Werkzeugen sollten Sie darauf achten dass diese einander erg nzen und eine stufenweise Ver feinerung der UI Definition unterst tzen Bei der Methodenwahl f r die Entwicklung von User Interfaces steht dieses Ziel im Vordergrund Eine Modellierungsumgebung zu haben mit der die UlI Beschreibung von groben Skizzen schrittweise zu einer exakten Spezifikation verfeinert werden kann Die Modellierungsumgebung sollte von i
270. sion der Software liefern Gleiches kann f r Designdoku mente erreicht werden Die Software k nnte damit bereits in fr hen Testphasen gegen die Benutzerdokumentation bzw gegen Designdokumente getes tet werden Ebenso kann durch automatisches Generieren der Dokumente von vorne herein sichergestellt werden dass die Dokumentation der Spezifikation entspricht Das Generieren von Dokumenten h ngt eng mit dem Test eines User Interface zusammen denn anhand von Dokumenten wer den die Voraussetzungen f r den UI Test geschaffen werden Kapitel 11 Testen in dem User Interface Modelle f r den automatisierten Test der UI Implementierung herangezogen werden Kapitelziele e Verwerten von Eingabe und Reaktionsbeschreibungen als Steuerungsregeln f r Testszenarien z B automatisch ge nerierte Unit Tests e Quantitative Aussagen ber das UI Modell anhand der Verteilung der Modellelemente in einer UI Beschreibung e Qualitative Aussagen ber das UI und das Modell anhand der Erwartungswerte an die Quantitative Verteilung z B ist f r jedes Eingabefeld ein Wertebereich fesigelegt Gibt es Kontrollelemente ohne Interaktionen Zu testen bedeutet ein Produkt darauf zu berpr fen ob es den Erwartungen entspricht Dazu ben tigt man e Das Testobjekt das zu testende Produkt e Die Erwartungen dokumentiertes Sollverhalten e Die Testszenarien Sequenzen von Aktion Reaktion Erwartungen e Ein Testvorgehen z B Wer test
271. stgelegt werden und zuein ander in Beziehung stehen Der Vorteil der Durchg ngigkeit ist dass das Modell der Benut zeroberfl che und die Modelle des inneren Aufbaus des Systems aufeinander abgestimmt sind und jeweils anhand des anderen Modells auf Vollst ndigkeit und Korrektheit berpr ft werden k nnen In einem solchen Modellverbund ist es weitgehend sichergestellt dass keine Bedienungselemente Ablaufschritte Funktionen und Daten vergessen wurden Ein weiterer Vorteil der Durchg ngig keit liegt darin dass so genannte tote Enden also Daten und Funktionen die nicht verwendet werden oder aber Bedienungs elemente die nicht mit Funktionen unterlegt sind so vermieden werden k nnen Das kollaborative Modellieren kann man vereinfacht auf die folgende Formel bringen Anwendungsabl ufe und funktionelle Abl ufe m ssen wie Schraube und Mutter zueinander passen UI Modell und Modelle des Systeminneren werden voneinan der getrennt erstellt m ssen aber fortw hrend aufeinander abge stimmt werden Eine Aufgabenteilung kann beim kooperativen Modellieren wie folgt aussehen User Interface und Funktion bedingen sich gegenseitig Durchg ngigkeit UI Modell und Modelle des Sysieminneren m ssen aufeinander abgestimmt sein 178 Funktionsmodellierung Strukturperspektive Dialogperspektive UI Modell Schwerpunkt Anwendungsabl ufe und Pr sentationsinhal te Vorgehen Workflow und anwenderorientierte M
272. t wicklung von Oberfl chen f r eingebettete Systeme gibt es eine Reihe von experimentellen Projekten und Werkzeugen welche ebenfalls L sungsans tze f r eine durchg ngige UI Entwicklung anbieten Darunter gibt es auch kommerzielle L sungen Als Beispiele seien die DSL Domain Specific Language Tools von Microsoft http msdn microsoft com vstudio DSL oder MetaEdit von MetaCase http www metacase com genannt 3 10 Nutzen Die Analyse von verschiedenen Werkzeugarten und Beispielen f r Werkzeuge zur durchg ngigen UI Entwicklung hat uns einen Einblick in die Komplexit t der Ul Modellierung sowie einen berblick ber verschiedene Ans tze zur Beherrschung dieser Komplexit t gegeben Das in diesem Kapitel eingef hrte Bewertungsschema f r UI Werkzeuge kann Ihnen bei der Beurteilung und bei der Auswahl des passenden Werkzeugs f r Ihr Projekt behilflich sein Mit den vorgestellten Anforderungsprofilen an Funktionalit t von UI Entwicklungswerkzeugen und mit den Bewertungskriterien f r Handhabung der Werkzeuge k nnen Projektleiter Architek ten und Entwickler die am Markt angebotenen Werkzeuge ver gleichen und den Erf llungsgrad der projektspezifischen Anfor derungen einsch tzen Die Bereitstellung von UI Entwicklungswerkzeugen ist ein wach sender Markt und es ist zu erwarten dass vorhandene Modellie rungsans tze weiterentwickelt und neue Werkzeuge angeboten werden Mit den in diesem Kapitel eingef hrten Bewert
273. t werden ber diese Manipulation l st der Anwender komplexe Funktionen wie z B Grafik und Textverarbeitung oder 3D Modellierung CAD aus Diese Anwendungen haben eine vertikale Ul Ausdehnung die dadurch gekennzeichnet ist dass die bearbeiteten Objekte selbst als relativ wenige Kon trollelemente f r vielf ltige Umformungen dienen Horizontale User Interfaces treten hingegen vor allem in wirt schaftlich orientierten Anwendungen auf wo der Fokus auf Workflows und auf intensiver Ein und Ausgabe von Daten liegt Diese Anwendungen haben eine horizontale UlI Ausdehnung die durch die Aneinanderreihung von vielen elektronischen Formularen gekennzeichnet ist Vertikale User Interfaces haben im Vergleich zu horizontalen User Interfaces weniger Dialogseiten und Kontrollelemente Ihre Kontrollelemente sind aber komplexer weil sie mit der grafi schen Repr sentation der Anwendungsdaten z B einem CAD Modell oder dem bearbeiteten Text verzahnt sind 2 4 Funktionsweise einer Softwareoberfl che Eine Softwareoberfl che umfasst diejenigen Teile der Software die in Form von Ausgaben Eingabeelementen oder Dialogf h rung zwischen dem Anwender und der Funktionalit t der An wendung vermitteln Die Softwareoberfl che ist ein Vermittler zwischen den Dialogpartnern Anwender und Softwarefunktionalit t Die Oberfl che ist der dem Anwender Mensch zugewandte Teil der Software Maschine und zust ndig f r den Austausch von Informatio
274. tabliert werden Es ist die Aufgabe des Projektleiters die f r das UI Verantwor tung tragenden Personen zu st rken und die Mitwirkung anderer Rollen am UI Entwurf einzufordern In einem Projekthandbuch sollte klar festgelegt sein wer was zum UI beitragen muss und woran die Qualit t dieser Beitr ge gemessen wird UI Modellierung ist ein Querschnittsthema Sie vernetzt und ver bindet Verantwortungsbereiche und kann deshalb Zielkonflikte offen legen z B zwischen Datenmodellierern und den Bef rwor tern einer detaillierten Historie aller Eingaben im UI Der Projektleiter muss deshalb Kommunikationsprozesse f rdern und eine Instanz f r die laufende Beilegung der aufgedeckten Widerspr che und Zielkonflikte stellen Checkliste f r UI orientiertes Vorgehen e UI Entwurf als eigenst ndiges Artefakt im Entwicklungs prozess aufstellen e Informationsschnittstelle zwischen UI Entwurf und funkti onalen Entw rfen festlegen e Regelm igen Abgleich zwischen UI Entwurf und Funkti onsmodellen etablieren e Rollenkompetenz definieren und einhalten e Zielkonflikte identifizieren und aufl sen e Checklisten f r Erreichen von Fertigstellungsgraden des UI Entwurfs verwenden 12 3 Integration sicherstellen Neue oder ver nderte Anforderungen an das User Interface k n nen eine bereits begonnene technische L sung in Frage stellen Die Anwendervertreter und ihr User Interface entscheiden aus Sicht der Entwickler schein
275. tation Aussprache UIEU Diese Ziele gelten auch f r das Verwenden der Notation in einer User Interface Entwicklungsumgebung UIEU Die Form der Notation ist im nachfolgenden Bewertungsschema f r UI Entwicklungsumgebungen sekund r Das Bewertungssys tem klassifiziert die T tigkeiten eines Entwicklers bzw Spezifizie rers beim Verwenden einer UI Entwicklungsumgebung und stellt Bewertungskriterien f r die Qualit t mit der die UIEU diese T tigkeiten unterst tzt Das macht der Anwender mit einer UI Entwicklungsumgebung Inkrementieren Hinzuf gen von User Interface Bestandteilen z B Steps Dialog Lists List Items Transkribieren Ausdetaillieren und Ausformulieren von User Interface Screen Content Verhalten und Kontext verkn pfen mit Anforderungen Modifizieren ndern von User Interface Bestandteilen zur Anpassung an ver nderte Anforderungen Exploratives Design Skizzieren iteratives entdecken des Vervollst ndigen von User Interface Bestandteilen Exploratives Lesen E forschen der Struktur der Klassi fikation der spezifizierten User Interface Bestandteile Bewertungsschema 65 e Suchen Nachforschen nach bekannten Fragestellungen z B welche User Interface Bestandteile haben Interaktio nen Kommunizieren Pr sentation und Kommunikation der UI Entw rfe im Entwicklungsteam und vor dem Kunden Die T tigkeiten und die Kriterien sind an die Arbeit von Black well und Green ber d
276. te Ich be zeichne sie als logische Elemente weil sie zwar eine bestimmte Grundform haben aber ihre grafische Ausgestaltung und mecha nische Umsetzung nicht festgelegt sind 54 Oberfl che Physische Bedienelemente Zum Beispiel ist f r das logische Funktionieren einer Checkbox nicht von Bedeutung ob sie durch einen umzulegenden Hebel oder durch ein Ankreuzfeld repr sentiert wird Physische Bedienelemente sind Rendering behaftete Inkarnatio nen von logischen Kontrollelementen Sie k nnen wenn man von ihrem Aussehen absieht auf logische Bedienelemente zu r ckgef hrt werden Weitere Fragestellungen zu logischen Bedienelementen k nnen sein e Wo liegt die Grenze zwischen logischen Controls und rea len Controls e Welche Informationen werden an der Schnittstelle zwi schen logischen Controls und realen Controls ausge tauscht e Welche Events m ssen die realen Controls an logische Controls weitergeben bzw senden e Welche Events sind f r welchen logischen Control defi niert e Welche Events werden an der logischen Schicht eines Kontrollelements am Beispiel eines komplexen Kontroll elements wie GridControl oder DataTable ben tigt e Wie h ngt ein logisches Bedienelement vom Anzeige und Bedienungskonzept Mouse based GUI Touch Screen Sprachbefehle Mischmodale Eingaben ab 2 7 User Interface Logik Das hier als User Interface Logik bezeichnete Geflecht hinter den Kontrollelementen ist f r d
277. te das negative Folgen haben Eine nicht mehr beherrschbare weil nicht exakt formulierbare Vermengung von Pr sentations Pro zess Anwendungs und Gesch ftslogik k nnte ein systemati sches Problem sein Die Service orientierte Architektur SOA mit Web Services strebt die Bereitstellung von Funktionalit ten und Prozessbausteinen als Dienste an Web Services erm glichen das Bereitstellen von verteilten Funktionalit ten die ber XML Schnittstellen angespro chen und damit leicht in Web User Interfaces eingebunden wer den k nnen Auf der Systemseite werden die M glichkeiten der Aufbereitung und Darstellung von Informationen auf der Anwenderseite die M glichkeiten mit diesen Informationen zu interagieren kom plexer Khazaeli 2005 Die Antwort auf die Frage was sich eigentlich an der Anwen dungsoberfl che abspielt und wie sich das mit der Transaktions logik verzahnt hat im Kontext der immer komplexer werdenden Anwendungen und der neuen technischen M glichkeiten des Web eine neue Dringlichkeit erhalten Mit geeigneten User Interface Modellen die ber das Aufsetzen von Masken auf Funktionen hinausgehen kann das Risiko einer neuen komplexit tsbedingten Krise in der Softwareentwicklung begrenzt werden 2 2 Oberfl che gliedern Wer den Auftrag hat eine Softwareoberfl che zu erstellen muss Verschiedenes ber die f r ein ordentliches UI ben tigten Dia logabl ufe Ablaufschritte Kontrollelemente und Interaktio
278. ten e Es k nnen Widget eigene Eigenschaften mit Daten gef llt werden e Alle grafischen Elemente werden im grafischen Bereich des bergeordneten Widget platziert e Alle grafischen Elemente erhalten zustandsbezogen ihr Aussehen e Man kann beliebig viele Widgets als Elemente ineinander schachteln e F r jedes Widget k nnen Funktionen definiert werden e Jedes Widget enth lt einen eigenen Datencontainer mit lokalen statischen und dynamischen Variablen e Zustands berg nge werden nach Eingang eines Events in Form einer Nachricht in einer Zustandstabelle behandelt e Jedes Widget besitzt die F higkeit Nachrichten zu versen den Die Funktionalit t kann durch PlugINs erweitert werden Da das Tool in NET umgesetzt wurde werden dabei NET Sprachen wie z B Visual Basic Java C unterst tzt Es existieren Schnittstellen zu g ngigen Dokumentationsformaten Testmanagement und Konfigurationsmanagementsystemen Ein Codegenerator kann integriert werden Modellieren mit Teledrive Menu Structure Editor Der Aufbau der Men struktur erfolgt mittels Kontextmen oder per Drag amp Drop von Vorlagenelementen in die vorhandene Struktur Die Konsistenz der HMI Struktur wird durch die automatische Anwendung festgelegter Strukturregeln gew hrleistet Das bedeu tet z B dass in Men netzen ausschlie lich Men s und weitere Men netze eingef gt werden d rfen und dass Men s ihrerseits nur Widgets enthalten k nnen Die Attrib
279. tet sich insbesondere HTML und SVG an Zwischen Auszeichnungselementen k nnen die Platz halter eingestreut werden an welchen die Dialogelemente einge setzt werden k nnen Dialogelemente die keinen Bezug auf Layoutplatzhalter nehmen landen im Bereich placeholder named content wenn das Layout einen solchen Platzhalter festlegt Benutzt der Screen kein Layout dann werden die Elemente in Definitionsreihenfolge platziert Hat das vom Screen benutzte layout keinen content Platzhalter dann werden die Dialogele mente nach den Layoutelementen auf dem Bildschirm ausgege ben Zur Festlegung der grafischen Eigenschaften von Widgets bietet sich wie schon f r Layouts XHTML und SVG an Zwischen den Auszeichnungselementen die das Widget rendern k nnen die Platzhalter eingestreut werden an welchen die Eigenschaften von Dialogelementen eingesetzt werden k nnen Widget named spezielles_text_widget leitet die Definition eines Widgets ein Das Widget beschreibt wie das Layout eine Schnittstelle zur Darstellungsebene der Oberfl che Im Widget kann das Aussehen und die interne Pr sentationslogik z B wie sich das Widget beim Fokussieren ver ndert des Darstellungselements beschrieben werden Die Beschreibung des Widgets kann in einem beliebigen Format erfolgen und ist von Lucia nicht definiert Zur Lucia Sprache geh ren lediglich die Platzhalter f r den Inhalt value und weitere Eigenschaftswerte von logischen Di
280. tmasken Text User Interface TUI e Die Benutzerschnittstelle ist zeichen bzw textbasiert b licherweise 25 Zeilen 80 Zeichen e Aus Eingabefeldern beschreibenden Texten und grafi schen Zeichen werden auf TUIs Ein und Ausgabe Masken zusammengesetzt e Die Eingabe von Daten und Befehlen erfolgt ber diese Masken durch Tastatureingaben blicherweise werden textbasierte Oberfl chen auch ber Tastenkombinationen und Men s bedient e Prominente Vertreter Word Star Norton Commander Lo tus 123 Grafische Grapbical User Interface GUI Kontrollelemente e Die Benutzerschnittstelle ist grafikbasiert Verschiedene Bedienungselemente wie Fenster Schalt kn pfe Regler und Eingabefelder werden mit der Maus Tastatur und eventuelle weitere Eingabeger te z B Gra fiktablett bedient Die meisten kommerziellen Anwendungen werden heute mit einem GUI ausgestattet Typische Vertreter sind Windowsanwendungen f r den t glichen B roeinsatz OpenOffice oder MS Office Apple Macintosh Anwendungen oder GIMP GNU Image Mani User Interface Arten 41 pulation Program Bildbearbeitungssoftware z B unter KDE oder GNOME Voice User Interface VUI Der Anwender steuert die Anwendung mit gesprochenen Befehlen Die Ausgaben des UI bestehen entweder aus vorab aufge zeichnetem Ton oder aus ber eine synthetische Stimme ausgegebenem Text Die Eingaben erfordern eine Spracherkennung Nach der Spracherkennung da
281. tphasen verankert sein um Lesen von UML Diagrammen 21 von den Beteiligten als nutzbringend f r die eigene Arbeit er kannt und somit mitgetragen zu werden Sie finden in diesem Kapitel Tipps und Vorgehensvorschl ge f r die erfolgreiche Einf hrung nutzbringende Anwendung und nachhaltige Integration der UI Architektur in Softwareprojekten Das Kapitel ist auch f r Entwickler und Architekten nicht nur f r Projektleiter interessant Es zeigt an Fallbeispielen m gliche Risi ken z B falsche Erwartungen an die UI Architektur Kompe tenzverschiebungs ngste Abwehrhaltungen und M glichkeiten zur Vermeidung dieser Risiken Kapitel 13 Lebenszyklusmanagement in dem der Genera tionenwechsel der Technik die Hauptrolle spielt Eine platt formunabh ngige Oberfl chenbeschreibung berbr ckt den Technologiewechsel Oberfl chen m ssen nicht f r jede neue Technologieplattform von Grund auf neu entwickelt werden sondern k nnen ber Technologiewechsel hinweg wieder verwendet und weiter entwickelt werden Die in diesem Kapitel vorgestellten Ans tze sind bei der Planung von Releases Entwicklungsstufen und von Reengineering Projekten hilfreich Ebenso liefert dieses Kapitel eine Zusammenfassung der in der UI Architektur angesprochenen Themengebiete und einen Aus blick auf die weiteren M glichkeiten und Chancen der konse quenten Anwendung der UI Architektur im Projektalltag Begleitmaterial Online auf www
282. tuation Changed Signal im aktuel len Kontext ab Auf diese Weise passiert im User Interface kein st ndiges berpr fen von Situations nderungen die im aktuellen Ablaufpunkt des UI gar nicht relevant sind Zum Verst ndnis der Value Zuweisung Wenn ein Kontrollelement seinen Anzeigewert aus einem Application Value bezieht wird impliziert dass die Anzei ge des Controls jedes Mal aktualisiert wird wenn sich der Application Value ndert Zum Verst ndnis des Zusammenhangs zwischen Signal Applica tion Value und Situation Wenn das UI ein Signal erh lt muss es das Signal in der Regel vor einer Reaktion qualifizieren d h eine Situation oder einen Anwendungswert auswerten Die direkte Kopplung von Kontrollelementen an Situatio nen und Anwendungswerte impliziert ein zweckgebunde nes Signal an das Kontrollelement wenn sich die Situation oder der Datenwert ndert Beispiel Telefonbedienung Ein Modell f r das User Interface des Telefonmoduls in einem Fahrzeug Infotainmentsystem Das nachstehende Beispiel zeigt wie Gruppen aus logischen Schritten gebildet werden und wie einzelne logische Schritte mit Bildschirmen unterlegt werden hci model phone Telefonmodul im Fahrzeug Infotainmentsystem Die grobe Beschreibung des Use Cases ist 158 Sprache Telefon mit Sim Karte in Betrieb nehmen PIN und PUK Eingabe Rufnummer eingeben und anrufen Eingehenden Anruf annehmen aus beliebigem Men
283. tzen des Workflows empfangen werden Ein Arbeitsschritt sollte ein definierbares Ergebnis haben so dass man z B den Workflow nach einer Unterbrechung des Arbeitens mit der Anwendung auf dem gleichen Arbeitsschritt wieder auf setzen kann Ein Teilschritt ist ein Teil eines Arbeitsschritts das aber im Work flow kein in sich eigenst ndiges Ergebnis hat Auf einer Dialog seite die einen Arbeitsschritt abbildet kann der Teilschritt durch 94 Skizzieren Erfassen und Strukturieren der logischen Schritte Bild 40 Struktur der logischen Schritte in der Kundenverwaltung einen Dialogabschnitt abgebildet werden Ein Dialogabschnitt wird auf der Dialogseite z B durch eine Group Box eine Ab schnitttrennlinie oder durch einen Karteireiter bei einem Wi zard Dialog repr sentiert Beispiel Ablaufstruktur der Kundenverwaltung Die folgende Gliederung zeigt die Struktur der logischen Schritte f r das Beispiel der Kundenverwaltung Kunden verwalten suchen Suchkriterien angeben Kunden suchen in DB Kundenkarte lt ansehen ndern Mit der Kundenliste arbeiten gew hlte lt Kundenkarten l schen Kundenkarten verwenden lt Neue lt Kundenkarte anlegen lt lt service gt gt Kundenkartei synchronisieren Zu viele keine Treffer anzeigen Speichern von nderungen abfragen Best tigung abfragen Datens tze lt in DB l schen Erfo
284. uence Step ist also dass blicherweise nach Ausf hrung eines Service Steps zum aufrufenden Schritt zur ckgekehrt wird nach Ausf hrung eines Sequence Steps dagegen mit dem Nachfolger Schritt in Lesereihenfolge fortgefahren wird Ein Service Step kann im brigen auf der n chsten Gliederungs ebene wiederum in Sequence Steps unterteilt werden Das ist zum Beispiel dann sinnvoll wenn gr ere Abl ufe z B die Erstanmeldung bei einem Web Portal als Service realisiert wer den und der Anwender anschlie end da weitermachen kann wo er gerade war bevor die Erstanmeldung in seinen Workflow eingeschoben wurde Dadurch dass man einem Schritt einen Ausf hrungsmodus zu weist bestimmt man den Unterschied zwischen workfloworien tierten und dienstorientierten Teilen der Oberfl che Die workfloworientierten Teile stellen die Standardabl ufe der Ober fl che dar Die dienstorientierten Teile stellen die bei Bedarf abrufbaren Funktionen welche Standardabl ufe unterbrechen und nach Ausf hrung zur ckkehren dar Die Auswirkung auf die Abl ufe in der Anwendungsoberfl che wird beim Vergleich mit herk mmlichen Programmiersprachen deutlich Durch die Einf hrung des Flussmodus wird der Unter schied zwischen absolutem Sprung im Ablauf und einem Unter ablaufaufruf nicht mehr vom Aufrufer sondern von Aufgerufe nen bestimmt Der Vorteil dieser Neuerung liegt darin dass der aufrufende Step nicht unterscheiden muss ob der angeforde
285. ular e 10 Punkte Anwenderorientiertes Vokabular Bewertungsschema 67 Sichtbarkeit Eine UI Entwicklungsumgebung die Informationen kapselt und M glichst einfache vielfach verpackt reduziert die Sichtbarkeit von Ul Eigenschaften Bei Pflege von UI Details z B bei Anzeigetexten ist eine hohe Sichtbarkeit erforderlich Eine geringe Sichtbarkeit ist vor allem dann gegeben wenn die Eigenschaften z B in einem geschachtelten Propertybaum ste cken in dem man durch Aufklappen nach der Stelle suchen muss in der eine bestimmte Eigenschaft definiert ist Man kann dieses Manko teilweise durch eine Suchfunktion des Editors beheben hat aber nach wie vor Sichtbarkeitsprobleme wenn man hnliche Properties an mehreren Stellen des Baumes miteinander vergleichen m chte Die Sichtbarkeitsbewertung erfolgt anhand der im Editor verf g baren Gesamt und Detailsichten auf das Modell sowie anhand der Schachtelungstiefe von Informationen Die Leitfrage zur Be wertung kann z B sein Wie viele Wrapper werden um die tat s chliche UI Eigenschaft gelegt e 1 Punkt Informationen werden tief klassifiziert geschach telt e 10 Punkte Informationen werden mit wenig Schachtelun gen spezifiziert Vorabverpflichtung Vorabverpflichtung passiert wenn man fr hzeitig gezwungen wird Dinge festzulegen die eigentlich erst sp ter entschieden werden sollen oder k nnen Beispiele Id s f r Elemente festlegen m ssen die vielleicht gar n
286. und unterst tzt die Abbildung der Ul Perspektiven in einer User Interface Spezifika tion a modellger st beschreibt den aufbau des hci modells definiert die reihenfolge der modellteile modellkopf steps screens layouts widgets lucia Modellstruktur modelhead_ step_ screen_ layout_ 150 Sprache widget_ context_ a modellkopf identifiziert die datei als hci model legt den namen des modells fest liefert versionsinformationen zum modell und zur modellnotation legt gegebenenfalls modelglobale interaktionen fest legt gegebenenfalls modelglobale anforderungen fest Verwaltungs modelhead_ Informationen mode PaE model_revision_ lucia_revision_ interaction_ mode name_ legt den namen des modells fest legt eventuelle bezugnahmen auf modelle in anderen systemen alias namen MODEL name_definition_ requirements_ model revision_ legt fest mit welchem versionsstand das model bezeichnet ist die angabe der modellversion ist optional MODEL REVISION name definition_ requirements_ lucia_revision_ nennt die sprachversion in der das modell verfasst wurde die angabe der konkreto sprachversion ist erforderlich pflichtangabe LUCIA REVISION name_definition_ requirements_ a ablaufschritte der benutzeroberfl che beschreiben die ablaufstruktur der oberfl che k nnen ineinander geschachtelt werde
287. undeten Ecken angeschrieben Zust nde k nnen ineinander geschachtelt werden Der Start und der Endzustand werden durch besondere Symbole dargestellt 126 Sprache Bild 59 Zust nde Oberzustand in einer State Chart Zustandsname Unterzustand Q Start Ende Zust nde k nnen festgelegte Eintritts und Austrittaktivit ten Arbeitsaktivit ten sowie weitere durch dedizierte Ausl ser fest gelegte Aktivit ten haben Bild 60 State Chart Taai Zust nde mit zei Aktivit ten und Z1 22 OnClick Bedingung Aktion entry z1 beginnen do z1 Arbeitsaktivit t exit z1 beenden Transitionen Die berg nge k nnen zwischen zwei Zust nden erfolgen oder zustandsintern sein Fin bergang kann einen Ausl ser eine Bedingung und eine Aktion haben Der Ausl ser ist ein Ereignis mit dem das Abarbeiten des bergangs beginnt Die Bedingung legt z B in Form eines logischen Ausdrucks fest welche weite ren Begebenheiten gelten m ssen damit der bergang auch tats chlich ausgef hrt wird Die Reaktion definiert Aktivit ten z B das Ausf hren von Funktionen die im Vorfeld des ber gangs zum Zielzustand ausgef hrt werden Der bergang erfolgt ohne zeitliche Verz gerung d h ein ber gang nimmt per Definition keine Zeit in Anspruch Bild 61 Ausl ser Bedingung und Reaktion in einer Z5 Ausl ser Bedingung Reaktion Transition Ausl ser Bedingung Re
288. ungs schemen k nnen Sie die Vollst ndigkeit und die Anwendbarkeit von vorhandenen und neu aufkommenden User Interface Entwicklungswerkzeugen bewerten ber den Vergleich von Werkzeugen hinaus ist das Bewertungs schema f r die Entwicklung von User Interface per Hand und f r den Bau von projektspezifischen UI Werkzeugen hilfreich Die Anforderungen und Bewertungskriterien geben Ihnen einen berblick dar ber welche Faktoren in die Entwicklung einer Oberfl che einflie en Wenn Sie also ein konventionelles GUI Toolkit verwenden oder das UI mit projektspezifischen Methoden entwickeln k nnen Sie zum Beispiel anhand der oben aufgezeigten UI Ausdehnung pr fen ob und welche UI Bereiche ihre Methoden und Werk zeuge abdecken 82 Werkzeuge Mit diesen Hilfsmitteln sind Sie in der Lage Ihre UI Entwicklungsmethodik auf Vollst ndigkeit und Robustheit zu pr fen und bei Bedarf zu vervollst ndigen Kapitel 4 Skizzieren das sich der Antwort auf die Frage widmet wie man von An forderungen zu einer Oberfl chenbeschreibung kommt Kapitelziele e Wissen wie man aus Anforderungen User Interface Skizzen formt e Wissen wie man den Umfang und die Organisation der Oberfl che bestimmt e Wissen wie man den Gesamtumfang der Anwendung er fasst und wie man dabei die berdetaillierung vermeidet Das Sprichwort sagt Aller Anfang ist schwer Bei der Entwick lung einer Softwareanwendung trifft das Sprichwort in mehrf
289. ungszyklen k nnen iterativ und ohne Verlust von konzeptionellen Informationen erfolgen Die Definition der Softwareoberfl che ist plattformunab h ngig und berdauert Technologiewechsel Wechselnde Anwenderforderungen werden toleriert Das Softwareprodukt ist flexibler Der Zeitraum zwischen der nderung des Gesch ftspro zesses und der Abbildung in den unterst tzenden IT Systemen wird verkleinert Die UI orientierte Softwarearchitektur liefert Ein praxisbezogenes Rahmenwerk f r das Planen das Spezifizieren das Umsetzen und das Testen von Software oberfl chen Eine auf das UI zentrierte Informationsarchitektur f r das Entwickeln dialogintensiver Anwendungssoftware Eine Methodik f r das eindeutige Beschreiben von Dia loginhalten und Verhalten von Softwareoberfl chen Eine Grundlage f r das fr hzeitige Kommunizieren Ab stimmen und f r das systematische Testen von Anwen dungsoberfl chen UI Modelle helfen nicht nur beim Entwickeln der Oberfl che sondern stellen auch Informationen f r das Modellieren von Funktionen Daten und technischen Abl ufen zur Verf gung User Interface orientiertes Vorgehen unterst tzt Kommunikation und Wissensmanagement im gesamten Projekt UI Modell Bild 101 UI orientierte Architektur unterst tzt Knowledge Management 230 Lebenszyklusmanagement Ein User Interface Modell enth lt miteinander verkn pfte Infor mationen die auf vielf ltige Weise verwendet
290. unktionsmodelle fertig stellen e 6 Implementierung und Test der Funktionen e 7 Komfortverbesserungen und Erweiterungen Das Projekt verl uft erfolgreich und in konstruktiver Atmosph re Der Kunde hat jederzeit Kenntnis des Entwicklungsstands und kann die Lieferungen gegen die vereinbarte Oberfl che pr fen Beim Test werden die Abweichungen von der gemeinsam festge legten Bedienung festgestellt und behoben Das Projekt wird in Time und in Budget fertig gestellt 1 6 Inhalte der User Interface Architektur Die User Interface orientierte Architektur ist eine spannende Geschichte ber die Zusammenarbeit von Menschen bei der Entwicklung von Softwareanwendungen Sie berichtet ber die unterschiedlichen Sichten der beteiligten Personen und zeigt wie man Kommunikationsbr che im Entwicklungsprojekt berwin det um gemeinsam zu gewinnen 14 Einf hrung Das Buch ist nach Projekiphasen gegliedert Das Projektgesch ft ist voller Untiefen und Fu angeln Enge Zeitpl ne fachliche und technische Restriktionen wechselnde Anforderungen und verdeckte Ziele der Beteiligten sind nur einige Beispiele f r die Gefahren denen ein Projekt laufend ausgesetzt ist Mit dem Buch haben Sie einen Kompass f r die benutzerzentrierte Entwicklung dialogintensiver Anwendungen in der Hand Es wird Sie in allen Projektphasen unterst tzen und helfen die Risiken mit klaren Strukturen und rollen bergreifen dem Wissensmanagement zu berbr cken
291. usgabe kann Re Sprach gleichzeitig ber GUI und dialog Sprachkanal erfolgen Dialog enwickler Bi Spezifizierer UI spezifizieren Texte erstellen Texte nationalisieren Dialoge spezifizieren Bedienungselemente beschreiben Anordnung Situationen beschreiben N beschreiben Verhalten Ablauflogik beschreiben beschreiben Funktions und Datenzugriff beschreiben Bild 92 Use Cases Map der UI Entwicklung Erscheinungsbild Bild 93 Use Cases Map der UI Entwicklung Inhalte 218 Projektmanagement Spezifizierer beschreiben die Inhalte und das Verhalten der Soft ware Hierzu geh ren z B die Reaktionen auf einzelne Eingaben aber auch die Reihenfolge der Dialogseiten Methodenentwicklung Modellmanagement Bild 94 Use Cases Map der UI 2 an Meinoden Feet N Entwicklung taken e ea Methoden bereitstellen Varianten L Strukturierung Kontext Situationen Interaktionen Inhalte Logische Elemente Methodenentwickler pflegen die Systematik der UI Beschreibung Hierzu geh ren z B Erfassungsschablonen f r Dialogseitenbe schreibungen Technische Umsetzung Implementieren Bild 95 Use Cases Map AAA Anwendungs vertikaler Entwicklung aiik _ Durchstich I Umsetzen Prototypen UI umsetzen Kontrollemente anbinden Widgetlibrary pflegen
292. ute eines Men struktur Elementes wie z B Name Kommentar oder Transitionen k nnen bearbeitet werden Dies Werkzeuge f r eingebettete Systeme 79 geschieht in Eigenschafts Editoren Property Editor welche die Eigenschaften in einer tabellarischen Form zur Bearbeitung pr sentieren Menu Transition Logic Editor Generell k nnen bedingte sowie unbedingte Spr nge zwischen Men struktur Elementen definiert werden Das Hinzuf gen und Bearbeiten der Spr nge geschieht in tabellarischer Form F r eine solche Transition k nnen die Sprungtypen Menu Net Netzsprung oder Back definiert werden F r die Ziel auswahl einer Transition werden ausschlie lich alle g ltigen Ziele des definierten Sprungtyps angeboten Basic Widget Pool Dieser Pool stellt eine Sammlung von wiederverwendbaren Vor lagenelementen f r die Definition der HMI Struktur dar Die Poolelemente werden dem Benutzer nach Kategorien gruppiert in einem Palettenfenster angeboten Property Editor Die Bearbeitung von Eigenschaften eines Widgets wird in diesem Editor vorgenommen F r die unterschiedlichen Eigenschaftsty pen wie z B Zahlen Farben Zeichenketten werden angepasste Eingabem glichkeiten zur Verf gung gestellt O Mwamkie chem Lina hc Daw n earm mpri D Weakiel Tail IR Liadhai Semma bu AND daw a mine Monu DD Mon Pr CONFCRT lm N Iran E ropa Drei AM Bild 32 IAV Teled
293. voll st ndiger l sst sich mit der Notation ein UI einschlie lich der Verwaltung der Beschreibung selbst z B Varianten Spezifikati onsst nde nderungen beschreiben Die Vollst ndigkeitsbewertung erfolgt auf einer Skala von 1 bis 10 Punkte Die Punkte werden anhand des Abdeckungsgrads der UI Perspektiven und ihrer Unterobjekte durch die bewertete UI Entwicklungsumgebung vergeben e 2 Punkte Werkzeug deckt die Dialogperspektive ab e 4 Werkzeug deckt zus tzlich die Kontextperspektive ab e 6 Werkzeug deckt zus tzlich die Strukturperspektive ab e 8 Werkzeug deckt zus tzlich die Interaktionsperspektive ab e 10 Vollst ndige Abdeckung der UI Perspektiven ein schlie lich der Anforderungsperspektive der Ul Objekte und der Beziehungen zwischen ihnen e F r die fragmentarische Abdeckung einer Perspektive kann z B jeweils ein Punkt weniger vergeben werden Fachlichkeit Ist die Notation nahe an der Sprache die zu Fachgespr chen zwischen Anwendern Spezifizierern und Entwicklern verwendet wird dann l sst sich das UI in ihr leicht formulieren und das Formulierte leicht lesen Fachlichkeit bedeutet dass UI Elemente und ihr Verhalten durch ein Vokabular beschrieben werden das nahe an dem aus Sicht der UI Bedienung durch den Anwender verwendeten Vokabular liegt Die Fachlichkeitsbewertung erfolgt anhand der Bezeichnungen f r die Hauptobjekte der Modellierungsnotation e 1 Punkt Konstruktionsorientiertes Vokab
294. ware wird verschiedenen Risiken ausgesetzt Beispiel Oberfl che wird gerne ausgegrenzt Beispiele f r negative Folgen des Ausgrenzens der Oberfl che aus dem Entwicklungsvorgehen Szenario 1 Ein Softwarehersteller entwickelt ein Banking Framework Als Entwicklungsziel wird die Bereitstellung einer Mittelschicht f r die Abwicklung von Fachfunktionen gesetzt Kritische Projektentscheidung e Eine Standardoberfl che ist f r das Framework nicht vor gesehen e Das Argument f r diese Entscheidung ist dass f r jeden Kunden individuell ein seinen Bed rfnissen entsprechen Integration sicherstellen 213 des User Interface auf die Frameworkfunktionen aufge setzt werden soll Folgen Das Produkt ist vor dem Umsetzen einer ersten Referenz l sung nicht vorf hrf hig Der erste Kunde muss eine Katze im Sack kaufen Der n chste Kunde muss von der Individuall sung des Referenzkunden auf den Umfang des Standardframeworks abstrahieren k nnen und wollen Das Produkt kann nur auf Ebene einzelner Funktionen aber nicht auf Use Case Ebene getestet werden Die Vollst ndigkeit und Anwendbarkeit des Frameworks kann erst beim ersten Kunden reifen Da f r Interessenten die L sung nicht erlebbar ist wird das Produkt nicht erworben In der Folge wird das Projekt eingestellt Szenario 2 In einem Gro projekt wird die Softwareunterst tzung f r eine integrierte Konstruktions und Beschaffungsumgebung ei
295. wareentwicklung in allen Projektphasen entscheidend verbessert wird 1 3 Nutzen der Ul orientierten Architektur Die User Interface orientierte Softwarearchitektur ist auf die Pra xis der Softwareentwicklung gerichtet Das Buch aus Erfahrun gen entstanden die im Projektalltag gemacht wurden Kommerzielle Softwareprojekte haben stets enge Zeitvorgaben begrenzte Budgets und m ssen im vorgegebenen Umfeld mit Menschen gemacht werden die unterschiedliche ebenfalls be grenzte F higkeiten mitbringen Man kann es sich nicht aussu chen Auf Auftraggeberseite gibt der Marktdruck Time To Mar ket das Tempo vor auf Herstellerseite ist das eigene technische Know how bestimmend f r die Wahl der Werkzeuge und Me thoden Auf beiden Seiten spielen die Kosten und die Verf gbar keit von Ressourcen eine entscheidende Rolle Eine keimfreie Atmosph re in der man Lehrbuchwissen unter Laborbedingungen anwenden k nnte findet man im Projektge Nutzen der Ul orientierten Architektur sch ft nicht Das Buch konzentriert sich daher auf allt gliche Projektsituationen auf Beispiele aus der Praxis und auf konkrete Herausforderungen der Entwicklung von komplexen und dialog intensiven Anwendungen unter Zeit und Erfolgsdruck Theorien und Betrachtungen ber den Besenstiel z B Vorgehensmodelle und Metamodelle formaler Sprachen bleiben weitgehend au en vor Im Projekt z hlt die Praxistauglichkeit in einem Umfeld bei dem das Vorgehensm
296. werden und an der Oberfl che soll eine Reak tion sichtbar sein Das direkt manipulierte oder ber eine Eigenschaftenliste Properties oder ber Kontrollelemente indirekt manipulierte Objekt soll sofort Ver nderungen anzeigen e Benutzerkollaboration Mehrere Anwender bearbeiten z B einen gemeinsamen Text oder an einem gemeinsamen Verwaltungsvorgang Verschiedene Notifikationen sollen sicherstellen dass die Anwender wissen was jeweils der Andere tut Einige Dia loge k nnen nur lesend abgerufen werden solange sie von einem anderen Anwender bearbeitet werden Lo cking UI Perspektiven liefern den Schl ssel zum systematischen Hand ling der typischen Spezifikationsprobleme Prinzipiell ist die An wendung der UI Perspektiven als Strukturierungsmethode in jeder technischen Umgebung z B eingebettet in Java oder als UML Profil m glich Anforderungen an UI Werkzeuge 61 Entscheidend f r die Qualit t eines UI Werkzeugs ist der Grad der direkten Unterst tzung des Modellierens eines UI aus ver schiedenen Perspektiven Daher werden die Informationsstruktu ren f r eine UL Spezifikation im sp teren Verlauf des Buchs nicht in eine objektorientierte Programmiersprache eingebettet Es wird stattdessen eine spezielle Spezifikationssprache vorge stellt und eine Methode vorgeschlagen die auf das Modellieren eines UI aus verschiedenen Perspektiven ausgelegt ist 3 2 Anforderungen an Ul Werkzeuge Klar definierte Anforderun
297. wird im UML Aktivit tsdiagramm durch einen Aktionszustand abgebildet e Eingangsdaten Ergebnisse Regeln und Mechanismen Rollen Werkzeuge Systeme aus IDEFO werden im UML Aktivit tsdiagramm durch berg nge sowie durch Einga be und Ausgabe Pins abgebildet e berg nge und Eingabe Pins die von links in Aktionszu st nde m nden repr sentieren Eingangsdaten e berg nge und Ausgabe Pins die rechts aus Aktionszu st nden herauskommen repr sentieren Ergebnisse e berg nge die von oben in Aktionszust nde m nden re pr sentieren Regeln und Restriktionen e berg nge die von unten in Aktionszust nde m nden repr sentieren Mechanismen e Die von den berg ngen transportierten Informationen werden wahlweise direkt an den bergangskanten anno tiert oder durch Objektflusszust nde repr sentiert e Synchronisationsleisten repr sentieren IDEFO Border Lines Bild 38 Dekomposition und Border Lines IDEFO in UML 92 Skizzieren Die Ablaufstruktur beschreibt keine Ablaufdynamik Kanonische Sequenzen bilden 4 3 Ablaufstruktur formen Mit Ablaufstruktur ist eine Aufteilung der Anwendung in Pha sen T tigkeiten und einzelne Arbeitsschritte gemeint Diese Auf teilung erfolgt aus Anwendersicht Sie liefert einen berblick dar ber wie das was der Anwender mit der Anwendung tun kann von Anfang bis Ende aneinandergereiht und vom Gro ben ins Feine untergliedert werden kann
298. xis hat es sich eingeb rgert dass Powerpoint zum Entwurf von Masken und Abl ufen verwendet wird Excel wird oft dazu benutzt Listen von Kontrollelementen oder Dialog schritten zu erstellen In der Regel werden von Analytikern pro jektspezifische Vorlagen Templates f r den Entwurf von Mas keninhalten und f r die Beschreibung von Kontrollelementen aufbereitet und den Anwendervertretern vorgegeben Je nach Detaillierungsgrad kann eine Spezifikationsvorlage die gew nschte Struktur der UI Beschreibung grob umrei en oder bis in die Einzelheiten z B Wertebereiche von einzelnen Einga befeldern vorschreiben Eine berpr fung der formalen Korrektheit der auf Basis einer Word Vorlage erstellten UI Beschreibung findet nicht statt Eben GUI Toolkits und GUI Bibliotheken 71 so wenig wird der Spezifizierer programmseitig beim Schreiben der Ul Spezifikation unterst tzt z B auf formale Fehler hinge wiesen oder zum Einhalten der vorgegebenen Struktur aufgefor dert Zur besseren Durchsetzung von vorgegebenen Spezifikations schablonen werden Anforderungsmanagementsysteme wie Doors oder Rochade eingesetzt Der Spezifikationsart nach k nnen diese Programme zu den Office Werkzeugen gez hlt werden weil die Spezifikation aus Textbausteinen erstellt wird Zus tzlich wird ber die Textbausteine eine Struktur gelegt deren Verwal tung und Einhaltung mit Hilfe des Anforderungsmanagement Programms erfolgt 3 6 Darstellungsorient
299. xt und Hypertext f r Benutzerhandbuch und f r die Bildschirmhilfe erzeugt werden Bild 82 Verwerten Allgemeine Beschreibun des UI Modells zum 3 Erstellen von Zweckbeschreibung 7 __ Hilfetexte f r Dialogseiten Anforderungen Dokumenten Hilfetexte f r Bedienungselemente 7 merena Texte 7 ur bei log Schritten Auflistungen User Interface bei Kontrollelementen Modell ne er Gliederungen Strukturinformationen 7 Verh ltnisse von Ablaufhierarchie a Mengenger ste gastandteilen Bildschirmaufbau Statusinformationen gt Anderungsprotokolle Fertigstellungsgrad bersichten Die obige Abbildung zeigt eine Analyse der Informationen in einem Ul Modell aus dem Blickwinkel des Verwertens dieser Informationen zum Erstellen von Dokumentationsteilen Nutzen 199 Das fr hzeitige automatisierte Erzeugen des Dokumentationsge r sts Generierung von Bildschirmfotos sowie Aktualisierungs hinweisen erm glicht eine starke Optimierung der Arbeiten an der Benutzerdokumentation Bei konsequenter automatisierter Verwertung der im UI Modell enthaltenen strukturierten Informationen ber Zweck und Be dienung der einzelnen Bestandteile bis hin zu einzelnen Kon trollelementen kann die Erstellung der Benutzerdokumentation und der Entwicklungsdokumente stark beschleunigt werden Im Idealfall kann der Softwarehersteller aufeinander abgestimmte und aktuelle Benutzerdokumentation zusammen mit der ersten Testver
300. zen Fehlbedienungen zu vermeiden Daraus l sst sich folgern dass eine Softwareoberfl che erst zu sammen mit den interaktiven Hilfefunktionen und mit dem Be nutzerhandbuch vollst ndig ist Das Generieren von Ger sten f r diese Oberfl chenanteile ist ein Schritt mit dem man dieser Voll st ndigkeit n her kommen kann Ger st f r Benutzerhandbuch und On screen Hilfe generieren Software soll den Anwender anleiten und helfen Fehlbedienung zu vermeiden 198 Dokumentation 10 3 _ Ul nderungen nachvollziehen nderungsdokumentationen sind zum Beispiel f r aufeinander folgende Test und Pilotierungsiterationen hilfreich Sie ersparen und vereinfachen die m hsame Suche nach den Stellen der Soft ware die neu gepr ft werden m ssen Durch den automatisierten Vergleich von zeitlich versetzten St nden eines UI Modells kann der Aufwand zum Erstellen die ser vielfach von Anwendern Testern und Managern geforderten Dokumente gesenkt werden Zudem kann das automatisierte Vergleichen von UI St nden die Vollst ndigkeit einer nde rungsdokumentation sicherstellen Dokumente die nderungen zwischen verschiedenen User Inter face St nden aufzeigen k nnen sein e nderungsprotokolle der am UI seit einem bestimmten Datum vorgenommenen nderungen e Delta Dokumentation der Unterschiede zwischen zwei UI St nden 10 4 Nutzen Aus einer in formaler oder in halbformaler Form vorliegenden UI Spezifikation kann Te

Download Pdf Manuals

image

Related Search

Related Contents

MANUAL DO UTILIZADOR CALDeIRA De PeLLeTs  User Guide for the Psion Workabout Pro  THIS DOCUMENT IS IMPORTANT AND REQUIRES YOUR  view full paper - International Journal of Scientific and Research  B5708_0720G2 CYBORG A.ai  Elektronischer Tresor 20EA  American Standard 2425.XXXW-LHO User's Manual    `T。 S H ー BA 東芝ネオポールシ ャ ンデリ ア取扱説明書 保管用  

Copyright © All rights reserved.
Failed to retrieve file