Master Thesis Von Swing zu Ergonomie - static.sws.bfh.chstatic.sws.bfh.ch/download/MAS-07-02-18-doc.pdf · Unterm¨uli 6 CH-6300 Zug ... 2.2. MVC - Model View ... saubere, dynamische,

Master ThesisVon Swing zu Ergonomie

Nummer der Abschlussarbeit MAS-07-02.18

Klasse / Datum MAS-IT-2007-02 / 13.11.2009

Student und Autor Emilio WalterJurastrasse 41CH-3063 Ittigen+41 79 469 58 [email protected]

Betreuer Jan van HoeckFlexor AGUntermuli 6CH-6300 Zug+41 76 488 49 57

Expertin Dr. Beatrice AmrheinBerner FachhochschuleWankdorffeldstrasse 102CH-3014 Bern+41 31 84 83 [email protected]

Abstract

Erstellung eines Buches, welches die Lucke zwischen Programmierung und Ergonomieschliesst. Wie der Programmierer sein Wissen einsetzen soll, um aus den vielen, einzelnerlernten Techniken zu ansprechenden und den Ergonomieanspruchen gerecht werdendenMasken zu gelangen.

Schlusselworter: Ergonomie, Swing, Anleitung, Buch

Von Swing zu Ergonomie

Emilio Walter

19.02.2010

Inhaltsverzeichnis

Vorwort i

1. Einleitung 1

1.1. Fur wen ist das Buch? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Buchstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Symbole im Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I. Software Ergonomie Standards 5

Software-Ergonomie 7

1. Angemessen 9

1.1. Liftsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.2. Systemvariable Path einstellen . . . . . . . . . . . . . . . . . . . . . . . . 10

2. Selbstbeschreibend 13

2.1. Adresse erfassen fur Saison Abo . . . . . . . . . . . . . . . . . . . . . . . . 14

3. Steuerbar 17

3.1. Computer gesteuerte Werkzeugmaschinen . . . . . . . . . . . . . . . . . . 17

4. Erwartungskonform 19

4.1. Bankomat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5. Fehlertolerant 21

5.1. Ein Buchungssystem mit Fragen zu den Eingaben . . . . . . . . . . . . . . 21

6. Individualisierbar 23

6.1. Code Editor Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7. Lernforderlich 25

7.1. Automatisch reduzierte Menus . . . . . . . . . . . . . . . . . . . . . . . . 25

3

Inhaltsverzeichnis

II. Ergonomie mit Swing 27

1. Fenster und Dialoge gestalten 291.1. Weniger ist mehr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.2. In drei Schritten vom Usecase-Diagramm zur Anzahl Masken . . . . . . . 291.3. Beispiel Schwimmbad Kasse . . . . . . . . . . . . . . . . . . . . . . . . . . 311.4. Wer und Wann? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311.5. Funktionalitat pro Maske? . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.6. Was kommt mehrmals vor? . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2. MVC - Model View Controller 412.1. Die Datenbank gehort nicht auf den Bildschirm . . . . . . . . . . . . . . . 412.2. MVC - Model View Controller als Losung . . . . . . . . . . . . . . . . . . 412.3. Farben mischen mit MVC: ErgoSwing02 . . . . . . . . . . . . . . . . . . . 432.4. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3. Registernavigation 473.1. So viele Optionen und so wenig Zeit . . . . . . . . . . . . . . . . . . . . . 473.2. Fehlerhafte Eingaben anzeigen . . . . . . . . . . . . . . . . . . . . . . . . 473.3. Benutzer geradeaus fuhren . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4. Registernavigation: ErgoSwing03 . . . . . . . . . . . . . . . . . . . . . . . 503.5. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4. Fortschrittsanzeige 534.1. Wo bin ich? Was soll ich hier? Und was wollte ich gerade tun? . . . . . . 534.2. Fortschrittsanzeige: Ergoswing04 . . . . . . . . . . . . . . . . . . . . . . . 554.3. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5. Menus und Icons anordnen 575.1. Wo war der Befehl doch gleich? . . . . . . . . . . . . . . . . . . . . . . . . 575.2. Losung: Aufmerksamkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3. Menu und Icons: ErgoSwing05 . . . . . . . . . . . . . . . . . . . . . . . . 605.4. Menus und Toolbaricons synchron aktivieren . . . . . . . . . . . . . . . . 605.5. Action konfigurieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.6. Snippet: BeendenAction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.7. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

6. Eingabefelder beschriften 636.1. Wahl der Beschriftung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2. Nahe schafft Zusammenhang . . . . . . . . . . . . . . . . . . . . . . . . . 636.3. Beschriftungen Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.4. Snippet: Mehrzeiliger Text in Labels . . . . . . . . . . . . . . . . . . . . . 65

7. Action mit SwingWorker 677.1. Wenn es mal wieder langer dauert . . . . . . . . . . . . . . . . . . . . . . 67

4

Inhaltsverzeichnis

7.2. Ein neuer Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.3. Losung: SwingWorker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.4. Tipps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.5. Action mit SwingWorker: ErgoSwing07 . . . . . . . . . . . . . . . . . . . . 69

7.6. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8. Look and Feel 718.1. Begriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.2. Wozu eigentlich? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.3. Mal eben schnell die Farbe aller Fenster wechseln . . . . . . . . . . . . . . 72

8.4. Einzelne Eigenschaften abfragen und einstellen . . . . . . . . . . . . . . . 72

8.5. Look and Feel: ErgoSwing08 . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8.6. Snippet: Look and Feel setzen . . . . . . . . . . . . . . . . . . . . . . . . . 73

8.7. Snippet: Look and Feel schon beim Starten festlegen . . . . . . . . . . . . 75

8.8. Snippet: Liste der Schlussel beschaffen . . . . . . . . . . . . . . . . . . . . 77

8.9. Snippet: Beispiele fur”Wert setzen“ . . . . . . . . . . . . . . . . . . . . . 77

8.10. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9. Flexible Fenstergrossen 799.1. Wenn das Grosste der Bildschirm ist . . . . . . . . . . . . . . . . . . . . . 79

9.2. Flexible Fenstergrossen: ErgoSwing09 . . . . . . . . . . . . . . . . . . . . 81

10.Fehlermeldungen 8310.1. Eingabe nicht korrekt! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

10.2. Der Situation angepasste Icons verwenden . . . . . . . . . . . . . . . . . . 83

10.3. Eingaben prufen mit InputVerifier . . . . . . . . . . . . . . . . . . . . . . 85

10.4. Eingabeformat festlegen mit JFormattedTextField . . . . . . . . . . . . . 85

10.5. Snippet: DateFormatter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.6. Snippet: NumberFormatter . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.7. Snippet: MaskFormatter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

10.8. InputVerifier: ErgoSwing10 . . . . . . . . . . . . . . . . . . . . . . . . . . 87

10.9. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

11.Hilfe 8911.1. Kontextsensitive - Hilfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

11.2. Aufrufen von Hilfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

11.3. Tooltipps als Ersatz fur Handbucher? . . . . . . . . . . . . . . . . . . . . 90

11.4. In drei Schritten Hilfe erstellen . . . . . . . . . . . . . . . . . . . . . . . . 90

11.5. HelpService - ein einfaches Hilfe-System: ErgoSwing11 . . . . . . . . . . . 91

11.6. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

12.Eingabefelder optimieren 9712.1. Wenn Profis und Anfanger dieselbe Maske verwenden . . . . . . . . . . . 97

12.2. Alternative Navigation und Eingabemoglichkeiten . . . . . . . . . . . . . . 97

5

Inhaltsverzeichnis

12.3. Optimierte Eingabefelder: ErgoSwing12 . . . . . . . . . . . . . . . . . . . 99

12.4. Snippet: Datum-Spinner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

12.5. Der Swing JSpinner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

12.6. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

III. Design Patterns und Ergonomie 105

Was sind Design Patterns? 107

1. Abstract Factory 1091.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

1.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

1.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

1.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

2. Adapter 1132.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113


2.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114


3. Bridge 1153.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115


3.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116


4. Builder 1174.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117


4.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117


5. Chain of Responsibility 1195.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119


5.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.4. Verwandtes Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

6. Command 1216.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121


6.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122


6

Inhaltsverzeichnis

7. Composite 1257.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1257.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1267.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

8. Decorator 1298.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1298.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1318.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

9. Facade 1339.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1339.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

10.Factory Method 13710.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13710.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13710.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13810.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

11.Flyweight 13911.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13911.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13911.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14011.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

12.Interpreter 14312.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14312.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14312.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14312.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

13.Iterator 14713.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14713.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14713.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14813.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

14.Mediator 14914.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14914.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

7

Inhaltsverzeichnis

14.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150


15.Memento 15315.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153


15.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154


16.Observer 15516.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155


16.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156


17.Prototype 15917.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159


17.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159


18.Proxy 16118.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161


18.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162


19.Singleton 16519.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165


19.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166


20.State 16720.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167


20.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168


21.Strategy 16921.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169


21.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170


8

Inhaltsverzeichnis

22.Template Method 17322.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17322.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17322.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17422.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

23.Visitor 17523.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17523.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17623.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17623.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

A. Glossar 179

B. Literaturverzeichnis 183

C. Abbildungsverzeichnis 185

Index 189

9

Vorwort

Haben Sie das schon einmal erlebt? Nach hunderten von Entwicklungsstunden ste-hen Sie vor versammelten Programmierern und Stakeholdern. Ihr Rucken ist zur Lein-wand gedreht und Sie schauen zufrieden in zwanzig Gesichter. Sie zeigen stolz und alsUberraschung, den ersten lauffahigen Prototypen Ihrer neuen Software.

Nach den ersten paar Fenstern, unterbricht Sie Ihr Kunde mit den Worten:”Ah, ich sage

es mal ganz Schwarz/Weiss, das ist nicht das was wir wollen“.

Die Blicke der Anwesenden sind auf Sie gerichtet. Der kurze Moment, in dem geradeniemand etwas sagt und alle gespannt auf eine vernunftige Antwort Ihrerseits warten,scheint endlos lang. . .

Was ist passiert? Wir hatten die neue Software nach den Regeln der Kunst entwickelt.Requirements zusammengetragen und in einer Datenbank verwaltet, Use-Cases gezeich-net und spezifiziert, Workshops organisiert, um mit den Fachspezialisten die Anforde-rungen nochmals und nochmals durchzugehen. Die neuste Technik eingesetzt, um einesaubere, dynamische, wieder verwendbare, stabile und wartungsfreundliche Architekturzu bauen.

Nur leider ist uns dabei ein bisschen die Zeit aus dem Ruder gelaufen und zum Schlussmussten wir fur die Prasentation noch schnell eine View zusammenbauen. Schliesslichwollten wir nicht nur Tabellen und Diagramme zeigen.

Wir hatten besser darauf verzichtet.

Nun, Benutzer sehen aus einleuchtenden Grunden nur die Oberflache einer Software, abernicht was darunter steckt. Man kann es ihnen zwar erklaren und sie nicken freundlichdabei. Aber was sie wirklich interessiert, ist wie man nun genau diese und jene Arbeitdamit erledigen kann.

Eigentlich wusste ich das schon, aber ein bisschenWiederholung schadet ja nicht.

Ich wunsche Ihnen viel Spass beim Lesen!

Emilio Walter

i

1. Einleitung

1

1. Einleitung

1.1. Fur wen ist das Buch?

Zielpublikum

Das Buch richtet sich sowohl an etablierte, als auch an zukunftige Software Entwickler.Es ist fur Selbststudium und als Begleitliteratur zu Vorlesungen gedacht. Das Ziel ist, diein unterschiedlichen Vorlesungen wie

”Analyse und Design“,

”Software Ergonomie“ oder

”Programmierung in Java“ erarbeiteten Informationen, zu verbinden.

Benotigtes Wissen

Fur den ersten Teil des Buches, die Erklarungen zu den Software Ergonomie Standards,bedarf es keiner speziellen Vorkenntnisse.

Der zweite und dritte Teil des Buches, setzen Kenntnisse der Java Programmierung undder Analyse und Design Sprache UML voraus.

Die meisten Tipps treffen auch auf anderer Programmiersprachen zu. Jemand, der sichfur Ergonomie interessiert, kann sicher vom Buch profitieren.

Liebe Leserinnen

Ich entschuldige mich an dieser Stelle ganz offiziell dafur, dass ich uberall, wo es sowohlweibliche als auch mannliche Formen gibt, die mannliche gewahlt habe. Es ist sicher aufder einen Seite Bequemlichkeit. Auf der anderen Seite fand ich aber den Text leserlicher,wenn nicht jedes Mal beide Geschlechter erwahnt werden.

2

1.2. Buchstruktur

1.2. Buchstruktur

Das Buch besteht aus folgenden Teilen:

• Vorwort und Einleitung

• Teil I Software Ergonomie Standards

• Teil II Ergonomie mit Swing

• Teil III Design Patterns und Ergonomie

• Anhang mit Glossar, Literaturverzeichnis und Abbildungsverzeichnis

• Index

3

1. Einleitung

1.3. Symbole im Buch

Symbole am Rand signalisieren gute und weniger gute Beispiele oder Source Code, wel-cher auf der mitgelieferten CD zu finden ist.

Blick uber den Tellerrand

Wie wird diese Anforderung in der Praxis umgesetzt? Auch in ganz anderen Fachge-bieten? Analogien sollen helfen, den Zusammenhang und die Anforderung besser zuverstehen.

Erfolgversprechend

Beispiele, welche auf gelungeneWeise Ergonomie-Anforderungen umsetzen.

Ungunstig

Beispiele, welche Ergonomie-Anforderungen nicht optimal umsetzen.

Source Code vorhanden

Dieses Symbol finden Sie bei Programmierbeispielen welche sich auf der mitgeliefertenCD befinden.

4

Teil I.

Software Ergonomie Standards

5

Software-Ergonomie

Das Ziel der Software-Ergonomie ist die Erstellung von leicht verstandlicher und schnellbenutzbarer Software. Dabei wird der am Bildschirm arbeitende Mensch in den Vorder-grund geruckt und seine Anforderungen, Ziele, Vorkenntnisse und der kulturelle Hinter-grund betrachtet.

Denn: Software soll dem Menschen dienen und nicht umgekehrt.

In diesem Teil des Buches werden die sieben wichtigsten Grundsatze der Software Er-gonomie erklart. Diese sieben tauchen immer wieder in der Fachliteratur [Rie06] auf.So auch in den ISO Standards 9241. Die Grundsatze werden mit Bildern und Textverstandlich gemacht.

Gewisse Beispiele mogen auf den ersten Blick trivial erscheinen. Nun, genau mit denkleinen einfachen Dingen fangt es an.

Ein kleines Spiel: Versuchen Sie doch in Gedanken das Schaltpanel aus der Internatio-nalen Raumstation ISS aus Abbildung 1.0.1 auf eine Maske zu bringen und dabei gleichdie Ergonomie zu verbessern.

Alle die welche Russisch konnen, sich mit der Raumfahrt und im Besonderen mit der ISSauskennen und eine Ahnung haben, wozu das Panel verwendet wird, sind jetzt machtigim Vorteil. Fur alle anderen ist die Aufgabe etwas schwierig.

Was nun? Die Losung liegt darin, die Benutzer mit einzubeziehen. Und wenn sie kein Usa-bility Experte sind, dann ziehen Sie welche bei. Diese konnen mittels Usability-Laborsund strukturierten Interviews ein Maximum an Informationen von Benutzern holen, ohneunbedingt eine Menge uber ihr spezifisches Aufgabengebiet zu wissen.

Das Buch Usability Engineering [RF07] fuhrt auf verstandliche Weise in diese Disziplindes Software Engineering und zeigt in kompakter Form auf wie es gemacht wird.

7

Software-Ergonomie

Abbildung 1.0.1.: Panel in der internationalen Raumstation ISS, Quelle: NASA

8

1. Angemessen

Ein Programm ist dann angemessen gestaltet, wenn es den Benutzer bei der taglichenArbeit unterstutzt. Insbesondere soll das Programm so gebaut sein, dass es auf die zuerledigenden Arbeiten und das Umfeld zugeschnitten ist.

Wichtige Punkte:

• Genau so viele Informationen anzeigen und zur Eingabe verlangen, wie fur dieErledigung der Aufgabe benotigt werden. Nicht mehr und nicht weniger.

• Datenformat der Eingabefelder muss der Aufgabenstellung angepasst sein. Sindnur Zahlen sinnvoll? Oder auch Buchstaben? Wie viele Zeichen?

• Wo moglich und sinnvoll, Standardwerte vorgeben und damit den Benutzer vonwiederholenden Eingaben befreien.

• Keine Selbstdarstellung der Technologie. Nach zwei Tagen interessiert es nieman-den mehr, dass das Programm mit der coolen, neusten Technik XY gebaut wurde.

• Je komplizierter die Aufgabe ist, umso wichtiger ist ein einfach zu bedienendesProgramm.

1.1. Liftsteuerung

Liftsteuerungen sind gute Beispiel fur der Aufgabe angemessenes Design. Lifte lassen sichin der Regel weltweit mit denselben einfachen Tasten bedienen. Und dies nicht etwa aus-schliesslich durch Techniker, sondern durch jede erwachsene Person.

Von welcher Software kann man das gleiche behaupten? Welche Software erlaubt daseinfache Steuern von Menschen transportierenden, teuren Maschinen? Maschinen, welcheden hochsten Sicherheitsanforderungen genugen mussen? Und dies auf eine so simple undintuitive Art, dass eine einmalige Instruktion fur praktisch alle ahnlichen Maschinenweltweit reicht?

Wir sehen sie jeden Tag und denken uns nichts dabei. Dabei tragen Liftsteuerungenfolgenden Punkten Rechnung:

• Minimimalistische Steuerung, nur gerade so viele Tasten, wie notig sind

9

1. Angemessen

Abbildung 1.1.1.: Liftsteuerung

• Anordnung der Tasten entspricht Anordnung der Stockwerke und erleichtert so dieOrientierung

• Alarmruf, Moglichkeit Hilfe anzufordern, wenn mal was nicht stimmt

• Feedback uber aktuelle Position und Richtung der Kabine

1.2. Systemvariable Path einstellen

Die Abbildung 1.1.2 zeigt ein Fenster, mit dem sich die Systemvariable”Path“ einstellen

lasst. Es ist eigentlich der Aufgabe angemessen gestaltet. Mit nur zwei Labels, zweiEingabefelder und zwei Buttons ist es sehr ubersichtlich.

Nur leider wurde beim Eingabefeld fur den Wert der Variable doch etwas zu einfachgedacht. Die Path-Variable meiner Installation hat 450 Zeichen und das ist noch nichteinmal besonders viel. Da das Eingabefeld nur eine Zeile hat und sich das Fenster nichtvergrossern lasst, bleibt der Blick auf nur ca. 40 Zeichen offen.

Zugegeben, das Fenster wird nicht von so vielen Anwendern verwendet und darf dahernicht zu teuer sein. Trotzdem: hier hatte es gereicht das Fenster ein bisschen grosser odernoch besser vergrosserbar zu gestalten und fur die Eingabe des Wertes der Variable einmehrzeiliges Eingabefeld zu verwenden.

10

1.2. Systemvariable Path einstellen

Abbildung 1.1.2.: Path Variable einstellen

11

2. Selbstbeschreibend

Ein Programm ist dann selbstbeschreibend, wenn der Benutzer jederzeit weiss in welchemArbeitsschritt er sich befindet, warum und wozu die Maske gerade angezeigt wird undwie es weiter geht.

Selbstbeschreibend hat ubrigens nichts damit zu tun, ob es einer Schulung und Handbucherbedarf. Dies ist viel mehr von der Komplexitat der zu verrichtenden Arbeit abhangig.

Ein guter Hartest fur Selbstbeschreibung ist folgendes Szenario: Fuhren Sie irgendeineTatigkeit am Bildschirm aus, welche uber mehrere Masken hinweg einen Ablauf hat undhoren Sie mitten drin abrupt auf. Nun gehen Sie Mittagessen oder Sport treiben ohnean die Arbeit zu denken. Wenn Sie nach, sagen wir, einer Stunde zuruck sind, setzen Siesich wieder vor den Bildschirm und fahren weiter. Wie lange geht es, bis Sie wissen, wiees weiter geht? Ist es muhelos? Oder sind Sie nicht einmal mehr sicher ob Sie uberhauptim richtigen Programm sind? Wurden alle Masken bis hier hin komplett ausgefullt? Siehtman das dem Programm an? Und wenn vor dem Mittagessen doch was vergessen wurde,wie stellen Sie es fest?

Wichtige Punkte:

• Masken und Dialoge sollen beschreibende Titel tragen. Beispiele sind:”Kunde er-

fassen“,”Konto eroffnen“ oder

”Monatsreport erstellen“. Nicht geeignet sind Titel

welche ausschliesslich aus einer Nummer bestehen, im Stil von:”Maske 329560 -

09“.

• Steuerelemente und Eingabefelder der Aufgabe entsprechend beschriften.

• Jederzeit die aktuelle Position im Verhaltnis zum gesamten Ablauf anzeigen. Diesist besonders wichtig, wenn die zu erledigende Aufgabe uber mehr als 3 Maskenfuhrt.

• Verlangte oder fehlende Eingaben anzeigen.

• Hilfe anbieten. Der Benutzer sollte vom Programm aus in moglichst einfachenSchritten in Handbucher und Online Hilfe gelangen, welche die aktuelle Maskeund die Optionen beschreiben.

• Sicherheits-Ruckfragen in begrundeten Fallen. Zum Beispiel ist es sinnvoll, wenndas Programm den Benutzer fragt, ob er vor dem Verlassen des Programms nochseine umfangreichen Anderungen speichern mochte. Auch sind Ruckfragen vorSchritten, welche wichtige oder teure Verarbeitungen auslosen auch hilfreich.

13

2. Selbstbeschreibend

• Anzeige von Tipps und Hinweisen in unaufdringlicher Form. Zum Beispiel Tool-tipps auf Schaltflachen und Icons, Tipps in der Statuszeile, sobald der Fokus imentsprechenden Feld ist. Einen netten, wenn auch nicht uberall einsetzbaren, An-satz sind Sprechblasen, die etwas verzogert auftauchen und von selbst wieder ver-schwinden. Diese behindern die Arbeit von Profis nicht und konnen fur Anfangerhilfreich sein.

2.1. Adresse erfassen fur Saison Abo

Ein gutes Beispiel ist die Maske zur Erfassung eines neuen Kunden im Schwimmbad.Die Maske konnte durchaus auch von der Schnupper-Lehrtochter oder -Lehrling ohnegrossere Probleme bedient werden.

Die Maske wird angezeigt, wenn ein Kunde ein Saison Abonnement kaufen mochte unddieser in der Datenbank noch nicht erfasst ist.

Typisch fur ergonomische Masken, konzentriert sich diese auf genau eine Aufgabe: das Er-fassen der Adresse eines Kunden. Fur Informatiker: genau ein Usecase.

Merkmale der Maske:

• Sprechender Titel

• Eingabefelder sind mit ortsublichen Bezeichnungen versehen

• Obligatorische und optionale Eingaben sind je in einem eigenen Rahmen

• Darstellung ist analog zu Adressetiketten und erlaubt so sich rasch zu orientieren

• Grosse der Eingabefelder ist der erwarteten Lange der Eingaben angepasst

• Wird der Dialog nach dem Eingeben von Daten uber Abbrechen verlassen, erfolgteine Ruckfrage ob man den Dialog effektiv verlassen mochte und der Warnung,dass die Daten noch nicht gespeichert wurden.

• Eingabefelder mit fehlenden Eingaben werden beim Drucken der Speichern Tas-te farbig hinterlegt und der Benutzer mit einer einfachen Fehlermeldung auf dasFehlen aufmerksam gemacht.

14

2.1. Adresse erfassen fur Saison Abo

Abbildung 1.2.1.: Adresse erfassen fur Saison Abo

15

3. Steuerbar

Ein Programm ist steuerbar, wenn der Benutzer den Ablauf starten, die Richtung undGeschwindigkeit vorgeben kann und schlussendlich das Ziel erreicht.

Wichtige Punkte:

• Moglichkeit bieten die Arbeit zu unterbrechen und dann fortzusetzen

• Umfangreiche Aufgaben auf mehrere Masken verteilen und die Moglichkeit bietenvor und zuruck zu navigieren

• Wenn moglich Varianten der Steuerung fur Anfanger und solche fur Profis anbieten

• Undo und Redo Funktionalitat

• Moglichkeit jeder Zeit abzubrechen

3.1. Computer gesteuerte Werkzeugmaschinen

Computer gesteuerte Werkzeugmaschinen stellen Werkstucke mit hoher Prazision undGeschwindigkeit her. Die Maschinen sind mit diversen Sensoren ausgestattet, die die Po-sition des Werkstucks und der bearbeitenden Maschinenteile feststellen.

Eine spezialisierte Software berechnet auf Grund der Daten des Endproduktes die notigenBewegungen und Positionen der bearbeitenden Teile wie Bohrer, Frase oder Schneide-werkzeug.

17

3. Steuerbar

Abbildung 1.3.1.: Computer gesteuerte Werkzeugmaschine

18

4. Erwartungskonform

Ein Programm verhalt sich erwartungskonform, wenn es das tut, was man von ihm erwar-tet. Diese etwas saloppe Erklarung, bringt es auf den Punkt. Erwartungskonformitat hatwas mit Erwartungen zu tun und ist entsprechend vom Benutzer abhangig.

Welche Erwartungen der Benutzer hat, ist von folgenden Punkten abhangig:

• Andere verwendete Software

• Erfahrung in der Bedienung der Software

• Fachkenntnisse in der Erledigung der Aufgabenstellung

• Kultureller Hintergrund

Eine mogliche Technik um Erwartungskonformitat zu erreichen, sind mentale Model-le der zu erledigenden Aufgabe. Ziel davon sind Szenarien in Gedanken oder auf Pa-pier durchzuspielen, bis eine Art Drehbuch entsteht und diese dann auf die Maskenzu ubertragen. Je besser dies gelingt, umso einfacher kann sich der Benutzer mit derSoftware identifizieren.

Wichtige Punkte:

• Menus sollten mit Vorteil vollstandig dargestellt werden. Werden sie doch auch als

”Eselsleiter“ gebraucht um selten verwendete Funktionen zu suchen.

• Menus sollten eine Hierarchische Struktur haben. Dabei bildet jedes Hauptmenueinen bestimmten Zusammenhang ab.

• Beschriftung und effektives Verhalten sollen ubereinstimmen.

• Die Beschriftung der Eingabefelder und Masken muss dem Wortschatz der Be-nutzer entsprechen und der Aufgabenstellung dienen. Auch sind moglichst kurze,pragnante Begriffe zu verwenden.

• Widerspruche in Optionen oder Eingabefeldern sind unbedingt zu vermeiden.

• Moglichst homogene Umgebung pro Arbeitsplatz. Oft ist dem Benutzer mit einemweit verbreiteten und bewahrten Bedienungskonzept mehr gedient als mit komplettveralteten oder noch nie da gewesenen Oberflachen.

• Durchgangige Belegung der Funktionstasten. Dieselben Funktionstasten solltenauch auf unterschiedlichen Masken dieselben Funktionen haben.

19

4. Erwartungskonform

Abbildung 1.4.1.: Bankomat

4.1. Bankomat

Der Bankomat ist der Inbegriff fur Erwartungskonformitat. Denn, wenn die Kunden unddie Banken etwas nicht wollen, dann sind es Unsicherheiten, Streitereien und Geldverlustinfolge von Uberraschungen am Automaten.

Die Steuerelemente, deren Beschriftung und alle Dialoge sind penibel widerspruchsfrei.Das Resultat kann auch ein unerfahrener Computerbenutzer erahnen.

Die Benutzerfuhrung ist so ausgelegt, dass der Benutzer jeder Zeit weiss was die Einga-bemoglichkeiten bedeuten und was passieren wird, wenn er sie wahlt. Um dies zu errei-chen, werden die moglichen Handlungen auf ein Minimum eingeschrankt, der Benutzerin engen Bahnen gefuhrt und die Masken ubersichtlich gestaltet.

20

5. Fehlertolerant

Ein Programm gilt dann als fehlertolerant, wenn das beabsichtigte Arbeitsergebnis auchnach fehlerhaften Eingaben, durch Ruckmeldung an den Benutzer und Korrektur seiner-seits, erreicht werden kann.

Fehlerhafte Eingaben durfen ein Programm nicht gleich zum Absturz bringen. Auchdurfen fehlerhafte Eingaben nicht zu Dateninkonsistenzen fuhren.

Wichtige Punkte:

• Benutzereingaben sollten vom Programm moglichst sofort auf offensichtliche Fehlergepruft werden.

• Fehlerdialoge sollen kurz und prazise formulieren was beanstandet wird. PauschaleAussagen wie

”Diese Maske hat noch Fehler“ bringen nichts.

• Der Benutzer soll die Moglichkeit haben, Eingaben nach Fehlern zu korrigierenund weiterzufahren.

•”Leichte Vergehen“ sollten den Arbeitsfluss nicht bremsen. So konnten zum Beispielnoch nicht ausgefullte, obligatorische Felder farblich hervorgehoben werden, stattden Benutzer mit einem Fehlerdialog fur jedes einzelne Eingabefeld zu nerven.

• Gleichzeitig mit Fehlermeldungen Hilfe anbieten. Dies kann uber Hilfe - Tastenauf dem Fehlerdialog passieren oder uber Hinweise, welche am Rand eingeblendetwerden.

5.1. Ein Buchungssystem mit Fragen zu den Eingaben

Das Buchungssystem fur das Hallenstadion Betal bemangelt eine ungultige Eingabe beider erwarteten Anzahl Besucher fur ein neues Event. Gemass Geschaftsrichtlinien solldas Hallenstation in Betal eigentlich nur fur Events mit mindestens 5’000 erwartetenBesucher reserviert werden konnen.

Statt nun den Benutzer mit einer einfach Fehlermeldung”Eingabe ungultig“ darauf hin-

zuweisen, zeigt sich das Buchungssystem fehlertolerant und bietet gleich zwei Optionenan.

21

5. Fehlertolerant

Abbildung 1.5.1.: Ruckfrage aus Buchungssystem Hallenstadion Betal

22

6. Individualisierbar

Ein Dialog gilt dann als individualisierbar, wenn der Benutzer ihn an seine Vorliebenund an die Anforderungen der Arbeitsaufgabe anpassen kann.

Mogliche Optionen:

• Definierbare Symbolleisten

• Wahl des Umfangs an bereitgestellter Funktionalitat

• Einstellen von Benutzer spezifischen Vorgabewerte fur Eingabefelder und Aus-wahlmoglichkeiten

• Anpassen der Darstellung an schwierige Arbeitsbedingungen. Wahl von Farben,Kontrast und Schriftgrosse

• Wahl der Sprache der Beschriftungen

• Wahl der Eingabegerate

• Wahl der Tastaturbelegung

• Moglichkeit Makros zu definieren um wiederkehrende Arbeitsschritte zu automa-tisieren

• Wahl zwischen Listendarstellung und Karteikartendarstellung

Wichtige Punkte:

• Grundeinstellung muss schon ergonomisch sein. Die Moglichkeit sie zu andern istkein Freibrief fur schlechtes Design.

• Umfang an moglichen Einstellungen muss mit dem ursprunglichen Ziel der Anwen-dung abgestimmt werden. Nicht alles was machbar ist, ist auch sinnvoll.

23

6. Individualisierbar

Abbildung 1.6.1.: Code Editor Optionen

6.1. Code Editor Optionen

Code Editoren erlauben das Eingeben von Source Code in einer spezifischen Program-miersprache. Nicht selten werden bei der taglichen Arbeit unterschiedliche Editoren ver-wendet. Da ist es sehr hilfreich, wenn die Editoren an die eigenen Gewohnheiten ange-passt werden konnen.

Mogliche Individualisierbarkeit fur Code Editoren:

• Schriftart und Grosse der Source Code Anzeige

• Farben fur Schlusselworter

• Hervorhebung von Struktur - Zeichen wie geschweifte Klammern oder Kommentar-zeichen

24

7. Lernforderlich

Ein lernforderlicher Dialog unterstutzt den Benutzer bei der Erlernung der Anwendungdurch Hinweise und Anleitungen.

Im Idealfall gibt es zur Erledigung einer Aufgabe mehrere Moglichkeiten und Strategien,die angewendet werden konnen. Die Idee der Lernforderlichkeit ist nun, dass der Benutzeram Anfang eine einfache, aber vielleicht nicht so effiziente Strategie verwendet und dannmit Ubung sich steigert und ausgefeiltere Strategien entwickelt.

Wichtige Punkte:

• Hilfesystem, Hilfe auf Abruf, wenn moglich Kontext bezogen

• Tastaturkurzel, welche zur Verfugung stehen um Eingabefelder direkt anzuwahlen,deren Gebrauch jedoch optional ist

• Auf Wunsch einblendbare Details zu Ruckfrage Dialoge

• Einschaltbare Assistenten welche durch die Prozesse fuhren und auch ungeubtenBenutzern erlauben rasch zu Resultaten zu kommen.

• Undo / Redo Funktionalitat zur Unterstutzung von praktischen Versuchen.

7.1. Automatisch reduzierte Menus

Das automatische Ausblenden von nicht oder selten benutzen Menupunkten ist ein zwei-schneidiges Schwert. Auf der einen Seite sind schlanke Menus naturlich elegant. Auf deranderen Seite besteht die Gefahr, dass Benutzer immer nur die gleichen Befehle verwen-den und gar nicht auf die Idee kommen neue Sachen auszuprobieren.

In Bezug auf Lernforderlichkeit ist die Reduzierung der Menus auf die zuletzt verwen-deten Eintrage eher storend.

Wenn ein Programm schon protokolliert, welche Menu-Eintrage verwendet werden undwelche nicht, sollte man das fur den Tipp des Tages verwenden. Dieser Tipp, gleich nachdem Starten der Applikation angezeigt, konnte dann Werbung fur selten verwendeteFunktionen machen.

25

7. Lernforderlich

Abbildung 1.7.1.: Menu mit versteckten Auswahlmoglichkeiten

Abbildung 1.7.2.: Menu zeigt alle Auswahlmoglichkeiten

26

Teil II.

Ergonomie mit Swing

27

1. Fenster und Dialoge gestalten

1.1. Weniger ist mehr

Die Aussage in der Uberschrift bezieht sich auf die Anzahl Funktionalitaten pro Maske.Schliesslich geht es um die Grenze, bei der es keinen Sinn mehr macht, noch mehr aufdie Maske zu packen. Die Anwendungsfalle sollen als Basis fur den Umfang pro Maskegenommen werden.

Eigentlich klar wenn man daruber nachdenkt. Und trotzdem wird es immer wieder, auchvon namhaften Herstellern, falsch gemacht: die Anzahl benotigter Masken ist von denAnwendungsfallen abhangig und nicht von der Anzahl Eingabefelder.

Denn wenn”Adresse erfassen“ ein Anwendungsfall ist und dafur hundert Attribute ab-

gefullt werden mussen, dann ist das so. Die hundert Attribute konnen sicher noch grup-piert werden und somit auf unterschiedliche Tabs oder Panels verteilt werden, abergrundsatzlich wurde eine Maske reichen.

Im Gegenzug ist”Anmelden“ ein Anwendungsfall fur sich und gehort ganz alleine auf

eine eigene Maske. Auch wenn es nur zwei Eingabefelder sind: Benutzername und Pass-wort.

”Anmelden“ und

”Adresse erfassen“ haben also nichts auf derselben Maske zu suchen.

Gestalten Sie Ihr Programm so, dass sie zum Beispiel uber ein Menu die Hauptanwen-dungsfalle auswahlen lassen und sich dann jeweils sich eine spezialisierte Maske darumkummert. Damit reduzieren Sie automatisch die Komplexitat fur den Benutzer. Auchhat der Benutzer jederzeit einen Anhaltspunkt, was er eigentlich gerade am Machen ist.Auch wenn er zwischendurch von der Arbeit abgelenkt wird mit Telefonate, Mittagessenoder Besprechungen.

1.2. In drei Schritten vom Usecase-Diagramm zur AnzahlMasken

Die Mindestanzahl benotigter Masken lasst sich in drei Schritten bestimmen:

1. Wer macht was und wann?

2. Welche Anwendungsfalle gehoren zusammen?

29


3. Welche Anwendungsfalle haben mehrere Beziehungen?

In Details:

1. Anwendungsfalle identifizieren, welche von unterschiedlichen Personen zu unter-schiedlichen Zeitpunkte erledigt werden konnen.

Als Gegenprobe die Gruppen von Anwendungsfallen bestimmen, welche mit Vorteilvon derselben Person gleich hintereinander verwendet werden.

Aus den Funktionen, welche zu unterschiedlichen Zeitpunkten oder von unter-schiedlichen Personen verwendet werden konnen, entsteht je ein Maske.

2. Fur jede nun gefundenen Maske den Umfang an Teilfunktionalitaten uberprufenund falls sie zu hoch ist, in weitere Masken aufteilen. Teilfunktionen sind auf demUsecase-Diagramm durch ihre

”include“ oder

”extend“ Beziehung zu erkennen.

Als Faustregel kann die”drei“ genommen werden. Drei Dinge lassen sich ohne

Anstrengung merken.

Sind es mehr Teilfunktionen, kann es von Vorteil sein eine Abfolge von Masken zuerstellen in der sich der Benutzer vor- und zuruck bewegen kann.

3. Uberprufen welche Funktionalitat nun wiederholt auf unterschiedlichen Maskenanzutreffen ist.

Diese sollte nun in eine wiederverwendbare Komponente gekapselt werden. Alsozum Beispiel eine eigene Maske oder dann mindestens ein eigenes Panel.

Damit wird die Wartung einfacher, duplizierter Code wird vermieden und dieselbeFunktionalitat sieht in unterschiedlichen Zusammenhangen gleich aus.

Tipp

Lassen Sie sich nicht beirren von Aussagen wie:”Joh, die ist aber klein die Maske, warum

nehmen wir nicht noch Dieses und Jenes drauf?“ oder”Da sind aber ganz schon viele

Klassen in diesem Projekt, muss das sein?“

Die Antwort ist: Ja es muss sein. Die Benutzer werden es mit sicherer Bedienung, Ge-schwindigkeit und Motivation verdanken.

Denn auch wenn es mit den heutigen Mitteln kein Problem ist Software zu bauen, welcheauf einer einzigen Maske unglaublich viele Funktionen und Steuerelemente enthalt, lassenSie es sein. Es ist nicht ergonomisch.

Und wenn Sie das nachste Mal Software sehen, mit der Kernreaktoren uberwacht werdenoder an der Borse gehandelt wird. Schauen Sie genau hin. Das sind mehrere Masken,

30

1.3. Beispiel Schwimmbad Kasse

ja sogar selbststandige, frei positionierbare Fenster. Denn es sind extrem viele Infor-mationen, die diese Spezialisten sich gleichzeitig auf mehreren Bildschirmen anzeigenlassen.

Diese Spezialisten, sei es nun Kernkrafttechniker oder Borsenmakler, konzentrieren sichjeweils genau auf eine Maske und halten die anderen im Blickfeld, damit ihnen nichts ent-geht und sie schnell von einer Maske zur anderen wechseln konnen.

Und das geht einfach nicht mit einer einzigen Maske mit einem langen Scroll oder vielenTabs.

1.3. Beispiel Schwimmbad Kasse

Wie das gehen konnte sehen wir am Beispiel einer Software fur die Kasse eines Schwimm-bads. Die Kasse des Schwimmbads ist mit Touchscreen, Maus und Tastatur ausgestattet.Zudem gibt es einen kleinen Drucker welcher Einzeleintritte, Saisonabonnemente, Quit-tungen fur die Kunden und Belege fur die Buchhaltung druckt.

Die Mitarbeiterinnen und Mitarbeiter des Schwimmbads sollen mit der Software folgendeArbeiten erledigen:

• Ausgeben von Einzeleintritten

• Ausgeben von Saisonabonnemente, dabei muss auf diesen die Adresse der Kundenaufgedruckt werden

• Bereits im System erfasste Adressen wiederverwenden um Zeit zu sparen

• Bereits erfasste Adressen andern

Daraus ergibt sich das Usecase-Diagramm aus Abbildung 2.1.1.

1.4. Wer und Wann?

Bei diesem Usecase-Diagramm (Abbildung 2.1.1) konnen drei Hauptanwendungen derSoftware identifiziert werden (Abbildung 2.1.2): Einzeleintritte und Saisonabonnementeverkaufen und Adressen andern.

Diese drei Anwendungsfalle konnen als in sich geschlossene Einheiten angeschaut werdenund es ist vorstellbar dass jeder von diesen Anwendungsfallen von einer anderen Personoder zu einem unterschiedlichen Zeitpunkt erledigt wird. Also brauchen wir sicher schonmal drei Masken:

1. Einzeleintritte verkaufen

2. Saisonabonnement verkaufen

31


Kasse

Einzeleintri tt verkaufen

Saisonabonnement verkaufen

Adresse suchen

Adresse erfassen

Adresse korrigeren

Für Neukunden Saisonabonnement

«extend»

«include»

«include»

Abbildung 2.1.1.: Anwendungsfalle Schwimmbad

32

1.4. Wer und Wann?

Maske 2

Maske 3

Maske 1

Kasse

Einzeleintri tt verkaufen


Adresse korrigeren

Abbildung 2.1.2.: Zuteilung der Masken nach”wer machts wann?“

33


Abbildung 2.1.3.: Startbildschirm Schwimmbad Kasse

3. Adresse andern

Nun brauchen wir noch Steuerelemente um diese Masken aufzurufen. Da es sich beider Kasse um ein Modell mit Touchscreen handelt, bietet es sich an grosse Buttons zuverwenden, statt einem Menu.

Also machen wir eine kleine Maske zum Auswahlen der Hauptfunktionen. (Abbildung2.1.3)

1.5. Funktionalitat pro Maske?

Beim Verkauf von Einzeleintritten fallen keine weiteren Funktionen an. Beim Verkauf vonSaisonabonnementen hingegen muss die Adresse des Kunden drauf. Und diese wiederumist entweder in der Datenbank schon vorhanden (Funktionalitat

”Adresse suchen“ oder

sie wird der Funktion”Adresse erfassen“ neu erfasst. Die Abbildung 2.1.4 veranschaulicht

die Zusammenhange.

Gleichzeitig mit dem Verkaufen eines Saisonabonnements soll es moglich sein, eine bereitserfasste Adresse zu andern. Haufig denken Kunden erst beim nachsten Kauf daran demSchwimmbad die neue Adresse zu melden.

Als dritte und letzte Hauptfunktion soll die Software der Kasse ermoglichen, eine bereitserfasste Adresse auch ohne Verkauf von Saisonabonnement zu andern. Diese Funktionbeinhaltet das Adressen suchen aber nicht das Neuerfassen. Dieser Umstand wird in derAbbildung 2.1.5 veranschaulicht.

Aus diesen Hauptfunktionen und deren enthaltenen Unterfunktionalitaten entstehen nundie drei Masken:

1. Einzeleintritt verkaufen (Abbildung 2.1.6)

34

1.5. Funktionalitat pro Maske?

Maske Saisonabonnement verkaufen

Kasse


Adresse suchen

Adresse erfassenFür Neukunden Saisonabonnement

«include»

«extend»

Abbildung 2.1.4.: Benotigte Funktionalitat fur”Saisonabonnement verkaufen“

Maske Adressse ändern

Kasse

Adresse suchenAdresse korrigeren«include»

Abbildung 2.1.5.: Benotigte Funktionalitat fur”Adresse andern“

35


Abbildung 2.1.6.: Einzeleintritt verkaufen

2. Saisonabonnement verkaufen (Abbildung 2.1.7)

3. Adresse andern (Abbildung 2.1.8)

1.6. Was kommt mehrmals vor?

Funktionalitat, die auf verschiedenen Masken vorkommt, kann je nach Umfang auf einwiederverwendetes Panel gebracht werden oder wird zur eigenen Maske, welche vonverschiedenen Orten aus aufgerufen werden kann.

Ganz offensichtlich ist es moglich von zwei verschiedenen Masken aus Adressen zu suchenund Adressen zu andern. Zudem erlaubt die Saisonabonnemente verkaufen - Maske nochneue Adressen zu erfassen.

Daraus ergibt sich, dass die Funktion”Adresse suchen“ in unterschiedlichen Zusam-

menhangen zur Verfugung stehen muss. Dazu konnte man eine eigene Maske machen oderwie sich hier der Entwickler entschieden hat, die

”Adresse suchen“ Funktion in einer eige-

nen Klasse bauen, welche entsprechend konfiguriert werden kann.

Dadurch erhalt die Funktion ein durchwegs gleiches Aussehen und eine gleiche Bedie-nung, obwohl sie auf unterschiedlichen Masken anzutreffen ist. Kein Wunder, ist es dochimmer dieselbe Klasse.

36


Abbildung 2.1.7.: Saisonabonnement verkaufen

37


Abbildung 2.1.8.: Adresse direkt korrigieren

Die Abbildung 2.1.9 zeigt das Korrigieren einer Adresse gleich beim Verkauf eines Sai-sonabonnements und die Abbildung 2.1.10 zeigt das Neuerfassen einer Adresse.

38


Abbildung 2.1.9.: Adresse korrigieren wahrend Verkauf Saisonabonnement

39


Abbildung 2.1.10.: Neuerfassung wahrend Verkauf Saisonabonnement

40

2. MVC - Model View Controller

2.1. Die Datenbank gehort nicht auf den Bildschirm

Damit Masken als ergonomisch gelten, mussen sich diese an den Benutzern und derenzu erledigenden Aufgaben orientieren.

Dabei mussen das Design der Business Logik und der darunter liegenden Datenbankzurucktreten. Mit anderen Worten: Eingabefelder auf der Maske und Felder in der Da-tenbank konnen, aber mussen nicht ubereinstimmen. Sind doch die Anforderungen aneine robuste und prazise Businesslogik und an eine leistungsfahige Datenbank andere,als die Anforderungen an eine ergonomische Maske.

Ein kleines Beispiel: Eine Datenbank mit Adressen konnte ein Feld”Anrede“ enthalten.

Fur die Datenbank reicht ein einzelnes Feld vom Typ String vollig aus. Es wurde einfachpro Adresse darin enthalten, was als Anrede einzusetzen ist.

Auf der Maske hingegen ware ein solches Eingabefeld, in das der Benutzer fur je-de Adresse eine Anrede eingeben muss, nicht ergonomisch. Vermutlich ware ein Aus-wahlliste mit vorgegebenen Werten wie

”Frau“,

”Herr“, Familie oder leer komforta-

bler.

Die Losung liegt in einer Aufteilung der Aufgaben in:

• Datenschicht (Model)

• Darstellung und Eingaben (View)

• Businesslogik (Controller)

Auf diese Weise gibt es auch keine unliebsamen Diskussionen zwischen GUI-Entwicklernund Datenbank-Spezialisten, ob nun die Anrede normalisiert werden sollte oder nicht.

2.2. MVC - Model View Controller als Losung

Beim MVC - Konzept handelt es sich um ein Architektur-Pattern. Dessen Ursprungwird auf den norwegischen Forscher der Informatik Trygve Reenskaug zuruckgefuhrt.Er formulierte 1979 den Begriff Model View Controller im Zusammenhang mit seinenArbeiten in Palo Alto fur Xerox Parc.

41


Model

View Controller

Benutzer Eingaben

Beobachtung

Notifikation

Werte verändernWerte abfragen

Abbildung 2.2.1.: MVC Diagramm

In der Zwischenzeit hat sich der Begriff MVC zu einem allgemeinen Standard in derSoftwareentwicklung gemausert.

Das Ziel des MVC-Konzepts ist Entwicklung von Software bei welcher Anderungen undWartung einfacher vonstatten gehen und deren Komponenten wiederverwendet werdenkonnen.

Um dies zu erreichen werden bei den Programmen drei Teile identifiziert: Die Daten-schicht (Model), die Darstellung und die Eingabe der Daten als gemeinsame Schicht(View) und die Businesslogik (Controller). (Abbildung 2.2.1)

Diese Aufteilung kann dabei auf vollig unterschiedlichen Abstraktionsebenen geschehen:von einer Webanwendung in der der Client als View bezeichnet wird bis zu den Docu-ments hinter einem JTextComponent hinunter als Model.

Model

• Kapselt Daten und Zustand des Programms

• Erlaubt die Abfrage von Werten

• Verstandigt interessierte Views uber Anderungen an den Daten. (siehe auch Ob-server Pattern S. 155)

View

• Erstellt eine Darstellung der Daten

42

2.3. Farben mischen mit MVC: ErgoSwing02

• Wird vom Model verstandigt wenn die Daten geandert haben

• Fuhrt nach einer solchen Verstandigung eine Auffrischung der Darstellung durch

• Stellt Steuerelemente zur Manipulation der Daten zur Verfugung

• Verstandigt Controller uber Benutzer-Eingaben

• Kann vom Controller aufgefordert werden Darstellung zu wechseln

Controller

• Definiert die Funktionalitat des Programms

• Wandelt Benutzer-Eingaben in Updates der Daten um

• Verstandigt gegebenenfalls View daruber eine bestimmte Darstellung zu zeigen,als Antwort auf Benutzer-Eingaben

• In einem Programm existieren in der Regel mehrere Controller, welche sich dieFunktionalitaten teilen

2.3. Farben mischen mit MVC: ErgoSwing02

In den mitgelieferten Sourcen finden sie im Paket ergoSwing02 das kleine als MVC gebau-te Programm (Abbildung 2.2.3) zum Auswahlen von RGB - Farbwerten. Die Bestandteilevon Rot, Grun und Blau lassen sich je im Bereich von 0 - 255 einstellen. Die sich darausergebende Farbe wird rechts davon als Flache dargestellt.

ergoSwing02.ErgoSwing02

• Erstellt eine Instanz des Models

• Erstellt eine Instanz der View und ubergibt dabei die Referenz auf das Model

• Erstellt eine Instanz des Controllers und ubergibt dabei Referenzen auf Model undView

• Startet das Beispiel durch Anzeigen der View

43


View

- model: Model

+ update(Observable, Object) : void+ addRotListener(ChangeListener) : void+ addGruenListener(ChangeListener) : void+ addBlauListener(ChangeListener) : void

«Constructor»+ View(Model)

«interface»Observer

+ update(Observable, Object) : void

JFrame

Model

- rot: int- gruen: int- blau: int

+ getRot() : int+ getGruen() : int+ getBlau() : int+ getColor() : Color+ setRot(int) : void+ setGruen(int) : void+ setBlau(int) : void

Observable

+ addObserver(Observer) : void

Controller

- model: Model- view: View- rotListener: ChangeListener- gruenListener: ChangeListener- blauListener: ChangeListener

«Constructor»+ Controller(Model, View)

Registriert sich alsObserver

Registriertsich auf dieRegler

MutiertWerte

Abbildung 2.2.2.: Farben mischen mit MVC - UML Diagramm

44

2.4. Pattern

ergoSwing02.Model

• Fuhrt die Werte fur Rot, Grun und Blau

• Erlaubt das Registrieren von Observer (Observer Pattern S. 155)

• Verstandigt registrierte Observer uber Anderungen

• Erlaubt die Abfrage der einzelnen RGB-Werte und einer daraus berechneten Farbe

ergoSwing02.View

• Fuhrt eine Anzeige fur die gemischte Farbe

• Fuhrt drei Anzeigen fur die einzelnen RGB-Werte

• Hat drei Schieberegler fur Benutzereingaben

• Registriert sich beim Model als Observer

• Fuhrt nach Verstandigung vom Model ein Update aller drei Wertanzeigen und derangezeigten Farbe durch

• Erlaubt das Registrieren von Listener auf die einzelnen Regler

• Verstandigt die registrierten Listener uber Anderungen der Werte der Regler

ergoSwing02.Controller

• Kapselt die Businesslogik

• Fuhrt die Minimum- und Maximumwerte fur die RGB-Werte

• Registriert sich bei der View als Listener auf die einzelnen Regler

• Wandelt eine Anderung eines Reglerwertes in eine Mutation des Models um

• Uberpruft vor dem Mutieren des Models die Einhaltung der Minimum- und Maxi-mumwerte

2.4. Pattern

• Observer Pattern (S. 155)

45


Abbildung 2.2.3.: Farben mischen mit MVC - Screenshot

46

3. Registernavigation

3.1. So viele Optionen und so wenig Zeit

Wie man mit komplexen Auswahlmoglichkeiten umgeht.

Masken mit Registerkarten (Tabs) sind eine beliebte Moglichkeit jede Menge Informa-tionen auf kleinem Raum unterzubringen.

Auch wenn diese Darstellungsart bequem ist, darf die Benutzerfuhrung dabei nicht ver-gessen gehen.

Wenn eine Maske wie in Abbildung 2.3.1 auf mehreren Tabs sehr viele Steuerelementeund sogar Buttons fur weiterfuhrende Dialoge halt, dann wird es kritisch. Vor allemungeubte Benutzer verlieren schnell die Ubersicht und die Geduld. Und auch fur versierteBenutzer ist es schwierig sich zu merken auf welchem Tab, welche Einstellung zu findenist.

Spatestens wenn auf den Tabs Daten erfasst werden sollen, stellen sich folgende Fra-gen:

• Zu welchem Zeitpunkt werden die Eingaben auf den Tabs uberpruft? Beim Tab-Wechsel oder beim OK-Button im unteren Teil des Fensters?

• Wie informiere ich den Benutzer uber fehlerhafte oder fehlende Eingaben?

• Wie sieht es aus mit Abbrechen oder Ruckgangig machen von Eingaben?

• Wie helfe ich dem Benutzer sein Arbeit geradlinig zu erledigen. So, dass schonbesuchte Tabs nicht mehrmals besucht werden, nur um sich zu vergewissern, dassalle Felder ausgefullt wurden?

3.2. Fehlerhafte Eingaben anzeigen

Sollen die Daten von den Tabs ubernommen werden, dann werden sie haufig auchuberpruft. Was nun, wenn sich das beanstandete Eingabefeld nicht gerade auf dem zur-zeit angezeigten Tab befindet? Oder was ist wenn es mehrere Eingabefelder sind aufunterschiedlichen Tabs?

47


Abbildung 2.3.1.: 192 Optionen auf 11 Tabs

48

3.3. Benutzer geradeaus fuhren

Vorschlage

• Eingaben gar nicht uberprufen (sofern es zu einem spateren Zeitpunkt nachgeholtwerden kann)

• Schlimm, aber leider auch schon gesehen: Eine einzige Fehlermeldung im Stil:”Es

hat noch Fehler“ und zwischen den Zeilen:”Suchen Sie selbst wo“

• Besser, aber immer noch nicht toll: Jedes beanstandete Feld einzeln eine Fehler-meldung ausgeben und den Benutzer zum Feld fuhren.

Losung

Die Losung ist eigentlich einfach: Eingabefelder, welche beanstandet werden, farbig her-vorheben und Tabs auf welchen sich diese befinden mit einem Warn-Icon versehen. Dannreicht es aus, alle Eingaben beim Drucken des OK-Buttons zu uberprufen und bei Fehlerneine kurze Fehlermeldung auszugeben.

Ganz elegante Losungen prufen die Eingaben gleich im Hintergrund und noch wahrenddem Tippen werden Eingabefelder und Tabs markiert.

3.3. Benutzer geradeaus fuhren

Mussen auf den verschiedenen Tabs Eingaben gemacht werden, kann es schnell passieren,dass man die Ubersicht verliert. Bei der Maske in Abbildung 2.3.1 geht es zwar

”nur“ um

Optionen und nicht um die Steuererklarung, aber ein gewissenhafter Benutzer mochtevielleicht doch sicher sein, dass er alle Optionen angeschaut hat.

Spatestens nach dem funften Tab oder wenn die Reihenfolge der Linien sich automatischan das gewahlte Tab angepasst hat, wird es kritisch. War ich nun schon auf diesem Taboder nicht? Und welche habe ich schon angeschaut?

Losung

Die Losung liegt darin, den Arbeitsfortschritt festzuhalten und auf dem Reiter des Tab,zum Beispiel mit einem Gutzeichen, zu visualisieren.

Falls die Aufgabenstellung, wie zum Beispiel”Optionen einstellen“ keine automatische

Verfolgung des Arbeitsstandes erlaubt, sollte der Benutzer jeden Tab selber als erledigtmarkieren konnen.

49


Abbildung 2.3.2.: JTabbedPane im Einsatz

3.4. Registernavigation: ErgoSwing03

Mit dem mitgelieferten Programm kann man sich ein Bild machen wie die Anzeige vonfehlerhaften Eingaben und das auf erledigt setzen von Tabs erfolgen konnte. (Abbildung2.3.2

Ziel dieses etwas sinnlosen Programms ist es zehn Mal einen Wert von 1 bis 100 zu erfas-sen. Der Benutzer hat die Moglichkeit einzelne Tabs fur sich als erledigt zu markieren.Und zwar unabhangig davon, ob er wirklich was eingegeben hat.

Mit dem OK-Button werden die Eingaben auf den Tabs uberpruft und eine entsprechen-de Ruckmeldung ausgegeben. Sind nun Tabs vorhanden welche keine oder eine ungultigeEingabe haben, werden diese mit einem Icon markiert.

Das Programm wechselt zudem selbstandig auf das erste Tab mit einem Fehler.


• Programm mit zehn Registerkarten fur die Erfassung von Werten

• Verwendet fur die Erstellung der einzelnen Tabs Objekte der Klasse EingabePanel

• Registriert sich bei den Registerkarten als Observer

• Zeigt den Status der Registerkarten als Icon auf den Reiter

• Lasst alle Registerkarten auf einmal die Plausibilitat der Eingaben uberprufen

50

3.4. Registernavigation: ErgoSwing03

ErgoSw ing03

+ update(Object, Observable) : void+ main(String[]) : void

JFrame «interface»Observer

+ update(Object, Observable) : void

«interface»TabPanel

+ addObserver(Observer) : void+ deleteObserver(Observer) : void+ getMainPanel() : JPanel+ setStatus(PanelStati) : void+ getStatus() : PanelStati+ isPlausible() : boolean

Observable

«enumeration»PanelStati

«enum» DEFAULT ERROR OK WARNING

JPanel

EingabePanel

+ addObserver(Observer) : void+ deleteObserver(Observer) : void+ getMainPanel() : JPanel+ setStatus(PanelStati) : void+ getStatus() : PanelStati+ isPlausible() : boolean

1 1

hat pro Tab

Abbildung 2.3.3.: UML Diagramm zu ErgoSwing03

51


ergoSwing03.TabPanel

• Deklariert das Interface fur eine Tab-Klasse

• Fuhren eines JPanels fur die Darstellung

• Setzen und Abfragen von Stati gemass Enumeration PanelStati

• Plausibilisierung der eingegebenen Werte auslosen

• Moglichkeit Observer zu registrieren und wieder zu entfernen

ergoSwing03.PanelStati

• Enumeration der moglichen Stati eines Panels

• DEFAULT

• ERROR

• OK

• WARNING

ergoSwing03.EingabePanel

• Implementiert ein Register-Panel gemass Interface TabPanel

• Erstellt gleich selbst eine minimalistische Benutzeroberflache mit einem Eingabe-feld und einer Checkbox

• Verstandigt registrierte Observer uber Anderungen am Status

• Erlaubt dem Benutzer das Panel als”erledigt“ zu markieren, damit dieser die

Ubersicht uber die schon besuchten Panels behalt

3.5. Pattern

• Decorator Pattern (S. 129)

• State Pattern (S. 167)

52

4. Fortschrittsanzeige

Fortschrittsanzeigen dienen dazu den Benutzer daruber zu orientieren wie lange es imGanzen dauert und wie viel davon schon erledigt ist. Eine der bekanntesten Fortschritts-anzeigen ist die Anzeige der ubermittelten Daten bei einem Download. (Abbildung 2.4.1)

4.1. Wo bin ich? Was soll ich hier? Und was wollte ich geradetun?

Fortschrittsanzeigen konnen aber auch eine wichtige Orientierung fur den Benutzer sein.Gerade wenn ein Arbeitsablauf mehrere sich folgende Fenster beinhaltet, ist es fur dieMotivation des Benutzers wichtig zu sehen wie viele Schritte es im Ganzen sind und beiwelchem er sich gerade befindet.

Zwar kann man den JProgressBar von Swing auch fur diese Aufgabe verwenden, aller-dings ist die Darstellung fur die meisten Anwendungsfalle zu wenig prominent. Schonerware eine Fortschrittsanzeige mit Nummerierung der Arbeitsschritte und einer kurzenBeschreibung derselben wie in Abbildung 2.4.2.

Abbildung 2.4.1.: Fortschrittsanzeige bei Download

53


Abbildung 2.4.2.: Fortschrittsanzeige mit funf Schritten

54

4.2. Fortschrittsanzeige: Ergoswing04

ProgressDisplay

- MIN_SCHRITTE: int- MAX_SCHRITTE: int- listeBeschriftungen: List<String>

+ setSelectedIndex(int) : void

«Constructor»+ ProgressDisplay(int)+ ProgressDisplay(List<String>)

JTabbedPane

Abbildung 2.4.3.: UML-Diagramm ProgressDisplay

4.2. Fortschrittsanzeige: Ergoswing04

Das mitgelieferte Beispiel im Paket ergoSwing04 zeigt wie man mit wenig Aufwand durchErweiterung einer JTabbedPane eine wieder verwendbare Fortschrittsanzeige realisierenkann.

ergoSwing04.ProgressDisplay

Die Klasse ProgressDisplay implementiert eine wieder verwendbare Fortschrittsanzeigefur Arbeitsablaufe von zwei bis zehn Schritten. (Abbildung 2.4.3)

Das Steuerelement lasst sich mit einer Liste von Strings, den Bezeichnungen fur dieverschiedenen Schritte, instanzieren. Die Anzahl ubermittelte Schritte ergibt auch gleichdie Anzahl Schritte in der Anzeige.

Das ProgressDisplay bietet als erweiterte Funktionalitat nur gerade die uberschriebeneMethode setSelectedIndex(int) welche den zurzeit aktivierten Arbeitsschritt entspre-chend darstellt. Ansonsten wird es so konfiguriert, dass es sich wie ein reines Anzeige-Steuerelement verhalt.

55



Das Programm ErgoSwing04 verwendet das ProgressDisplay um funf Arbeitsschritte zusimulieren. (Abbildung 2.4.2)

Ein”Weiter“ und ein

”Zuruck“ Button fuhren den Benutzer von Arbeitsschritt zu Ar-

beitsschritt.

Statt echter JPanels, mit Eingabefeldern, Beschriftungen und weiteren Steuerelementen,werden zur Veranschaulichung nur gerade kleine Texte angezeigt.

4.3. Pattern

• Adapter Pattern (S. 113)

56

5. Menus und Icons anordnen

5.1. Wo war der Befehl doch gleich?

Was hat Gewohnheit mit Ergonomie zu tun und nach welchen Regeln sollen die Menu-Eintrage und Icons auf der Toolbar verteilt werden?

Die Redewendung”Der Mensch ist ein Gewohnheitstier“ kommt nicht von ungefahr.

Gewohnheiten helfen uns in gefahrlichen Situationen rasch und ohne zu Uberlegen rich-tig zu handeln. Sie erlauben uns aber auch harmlose Arbeitsablaufe automatisch zuerledigen.

Es geht sogar noch weiter. Erwarten wir Handlungen, wie zum Beispiel ein Dokumentauszudrucken, wie im Schlaf erledigen zu konnen, dann fuhlen wir die Abweichung vonder Gewohnheit sogar als innere Spannung.

Das nachste Mal wenn sich ein Arbeitskollege oder eine Kollegin sich uber ein Programmaufregt achten Sie darauf, was genau die Ursache ist. Hat es etwas mit Gewohnheit zutun?

Weitere interessante Informationen liefern die Kapitel Erwartungskonform (S. 19) undIndividualisierbar (S. 23) im ersten Teil des Buches.

5.2. Losung: Aufmerksamkeit

Achten Sie beim Gestalten von Menus und Toolbars darauf, welche Software von denBenutzern gleichzeitig verwendet wird und wie die Menus und Icons dort angeordnetsind.

In Programmen findet man immer wieder Funktionen wie Offnen, Speichern, Druckenoder Hilfe. Dann gibt es aber auch Funktionen, die sind spezifisch auf den Verwen-dungszweck der Software zugeschnitten. Nicht selten, sind es Menupunkte, die in keineranderen Software zu finden sind. So werden Sie wohl eine Funktion

”Rote Augen Effekt

entfernen“ vergebens in Bankensoftware suchen.

Die Losung ist nun die Funktionen, welche immer wieder vorkommen ganz links undganz rechts in den Menubalken und Toolbars zu platzieren und dann die spezifischenFunktionen dazwischen. Eine mogliche Losung konnte wie in Abbildung 2.5.1 und 2.5.2aussehen.

57


Abbildung 2.5.1.: Menus und Icons wie gewohnt

Abbildung 2.5.2.: Gewohntes Datei - Menu

58

5.2. Losung: Aufmerksamkeit

Abbildung 2.5.3.: Ungewohnliche Anordnung der Menus und Icons

Abbildung 2.5.4.: Ungewohnliche Position fur Programm Beenden

59


5.3. Menu und Icons: ErgoSwing05

In den mitgelieferten Sourcen finden sie das kleine Programm mit dem die Screenshotszu diesem Kapitel gemacht wurden.

Es ermoglicht Ihnen gewohnte und ungewohnte Anordnung von Menupunkten und Iconsdirekt miteinander zu vergleichen. Mittels Umschalttasten lasst sich zwischen den An-sichten hin und her schalten.

Die Abbildungen 2.5.3 und 2.5.4 zeigen eine Auswahl auf Stellung”ungewohnt“.

5.4. Menus und Toolbaricons synchron aktivieren

Um alle Toolbars und Menupunkt synchron zu aktivieren und desaktivieren, muss mitActions gearbeitet werden, statt zum Beispiel Event-Listener direkt auf den Komponen-ten. Mit den Actions wird nun uber setEnabled(boolean) die Funktion ein- und ausge-schaltet.

Durch die Verwendung von Actions erhalten ausserdem alle Buttons und Menus, welchefur dieselbe Funktionalitat stehen, die Beschriftung, Icons, Tastenkurzel und den Textfur den Tooltip uber ein einziges Objekt.

5.5. Action konfigurieren

Die Konfiguration von Actions erfolgt uber Wertepaare, welche mit den Methoden

putValue(String, Object)

gesetzt und mit

getValue(String)

abgefragt werden.

Die verschiedenen Eigenschaften tragen Namen, welche im Action-Interface deklariertsind:

Action.NAME Name der Aktion, wird fur die Beschriftung der Buttons und der Menu-Eintrage verwendet.

Action.SHORT DESCRIPTION Kurze Beschreibung der Funktion. In der Regel nurein oder zwei Worte. Dieser Text wir als Tooltip verwendet.

60

5.6. Snippet: BeendenAction

Action.LONG DESCRIPTION Ausfuhrlichere Beschreibung der Funktion. Dieser Textkann fur die kontext-sensitive Hilfe verwendet werden.

Action.SMALL ICON Zur Angabe eines Icons, welches die Funktion symbolisiert.

Action.LARGE ICON KEY Falls fur Toolbar und Buttons ein anderes Icon verwendetwerden soll als fur den Menu-Eintrag. Wird dieses Wertepaar nicht gesetzt, ver-wendet Swing fur Toolbars und Buttons das mit SMALL ICON angegebene Icon.

Action.ACCELERATOR KEY Tastenkurzel um die Funktion mittels Tastatur statt derMaus aufzurufen. Im Gegensatz zum Mnemonic wird hier normalerweise ein Kom-bination aus CTRL und einem Buchstaben oder einer Zahl verwendet, welcheaber nicht Bestandteil des Namens sein mussen. Typischerweise werden diese Tas-tenkurzel nicht lokalisiert sondern behalten ihre Kombination uber die Sprachgren-zen hinweg.

Action.MNEMONIC KEY Durch Unterstreichen hervorgehobener Buchstabe des Action-Namen. Dieser kann zur schnellen Auswahl mittels Tastatur verwendet werden.Dabei wird eine vom Betriebssystem abhangige Command-Taste in Kombinationmit dem Buchstaben gedruckt. (Microsoft Windows = ALT + Buchstabe)

5.6. Snippet: BeendenAction

/**

* Beispiel einer Action - Konfiguration

* Aufruf mittels ALT + F4 oder uber ALT + B

*/

public class BeendenAction extends AbstractAction {

// Konstruktor

BeendenAction() {

putValue(Action.NAME, "Beenden");

putValue(Action.ACCELERATOR_KEY, KeyStroke

.getKeyStroke(KeyEvent.VK_F4,

InputEvent.ALT_DOWN_MASK));

putValue(Action.MNEMONIC_KEY, KeyEvent.VK_B);

putValue(Action.SHORT_DESCRIPTION, "Programm beenden");

}

@Override

public void actionPerformed(ActionEvent e) {

System.exit(0);

}

}

61


5.7. Pattern

• Template Method Pattern (S. 173)

62

6. Eingabefelder beschriften

6.1. Wahl der Beschriftung

Wie beschriftet man Eingabefelder am besten? Auf was kommt es an?

Achten Sie beim Beschriften und Anordnen von Eingabefeldern, Menus und sonstigenSteuerelementen auf folgende Punkte:

• Bezeichnungen kurz und pragnant halten, Fullworter vermeiden

• Auf die Wahl der Bezeichnung achten, widerspruchsfrei, branchenspezifisch

• Bei Masken welche in unterschiedlichen Sprachversionen (lokalisiert) verwendetwerden, darauf achten, dass die unterschiedlichen Sprachen auch unterschiedlichlange Worter fur ein und dasselbe haben. Also genugend Platz einrechnen odernoch besser dynamische Layouts verwenden.

• Logisch zusammengehorende Steuerelemente auch als erkennbare Gruppen gestal-ten. Zum Beispiel Trennlinien in Menus und Toolbars oder beschriftete Rahmenrund um Gruppen von Eingabefeldern.

6.2. Nahe schafft Zusammenhang

Nahe schafft Zusammenhang. Diese Aussage trifft nicht nur fur Paparazzi zu, wenn sieFotos von nebeneinander stehenden Personen machen und gleich eine Story reindichten,sondern eben auch fur Eingabefelder.

Dabei spielt die Anordnung der Eingabefelder und deren Beschriftung eine wichtigereRolle als man auf den ersten Blick vermuten wurde. Denn unbewusst werden grossereAbstande als eine Art Trennung empfunden und im Gegenzug fehlende Abstande als eineAufforderung die beiden Elemente als eine Einheit anzuschauen.

Auf der anderen Seite konnen nicht alle Beschriftungen direkt an den Eingabefeldern

”kleben“ weil sonst ein sehr unruhiges Gesamtbild entsteht. Sind doch die Beschriftun-gen meist unterschiedlich lang. Damit ein ausgewogenes und ubersichtliches Gesamtbildentsteht, in dem sich der Benutzer problemlos orientieren kann, braucht es Kompromisseund uberlegtes Platzieren.

Dabei sollte auf folgende Punkte geachtet werden:

63

6. Eingabefelder beschriften

Abbildung 2.6.1.: Beispiel fur Beschriftungen

• Bilden Sie unsichtbare Fluchtlinien durch ausrichten mindestens einer Kante derBeschriftung und des Eingabefeldes

• Achten Sie auf Abstande. Ein etwas grosserer Abstand zwischen logischen Blockenvon Steuerelementen und schon hat man eine Gruppierung. Und dies ohne Rahmen.

• Nicht zu viele Gruppen machen. Die Benutzer erinnern sich eher daran was auf wel-cher Maske erledigt werden kann, wenn es nicht zu viele Dinge sind. Und Gruppenhelfen eben mit sich das

”was und wo“ zu merken.

6.3. Beschriftungen Beispiel

Die Abbildung 2.6.1 zeigt eine mogliche Losung Beschriftung von Eingabefeldern.

1. Der Rahmen gruppiert hier nicht nur die Eingabefelder, sondern auf ein subtileArt auch die Buttons am unteren Rand.

2. Die Beschriftungen sind hier an der rechten Seite des Textes ausgerichtet undbilden eine Fluchtlinie, die Ruhe ins Design bringt. Zudem befinden sich so dieTexte nahe an den entsprechenden Eingabefeldern.

64

6.4. Snippet: Mehrzeiliger Text in Labels

3. Der grossere Abstand zwischen”Anrede“ und den Eingabefeldern fuhrt zu einer

feinen Gruppierung der Text-Eingabefelder fur die Adresse. Das gleiche bewirktder grossere Abstand zur Auswahlliste

”Land“.

4. Als Alternative zu Beschriftungen zwischen Eingabefeldern kann, sofern nur zweiEingabefelder auf der gleichen Zeile sind, das rechte Feld auch aussen angeschriebenwerden. Dies hat den Vorteil, dass die Eingabefelder naher beieinander sind undder Lesefluss nicht behindert wird.

5. Die absichtlich als eigene Gruppe gefuhrten Buttons fuhren dazu, dass die Aufgabeeine Adresse zu erfassen als zwei Schritte empfunden wird. Zuerst Daten eingebenund dann sich entscheiden zu Speichern oder Abzubrechen.

6.4. Snippet: Mehrzeiliger Text in Labels

Labels eignen sich nicht von Haus aus um mehrzeiligen Text darzustellen. Auch dieLosung eine Zeilenumbruchanweisung wie

JLabel myLabel =

new JLable( "ErsteZeile\nZweite Zeile" );

zu verwenden fuhrt nicht zum Erfolg, weil Swing hier das Zeilenumbruchzeichen nichtbeachtet.

Die Losung liegt in der Verwendung von HTML als Labeltext. Die Anweisung

JLabel myLabel =

new JLabel( "<html>Erste Zeile<p/>Zweite Zeile</html>" );

fuhrt in diesem Fall zum gewunschten Resultat.

65

7. Action mit SwingWorker

7.1. Wenn es mal wieder langer dauert

Aufgaben die etwas langer dauern, wie zum Beispiel Datenbank- oder Datei-Zugriffesollten nie auf dem Event Dispatching Thread, dem Thread der fur das ganze Hand-ling der Benutzereingaben und graphischen Ausgaben verantwortlich ist, erledigt wer-den.

Programmiert man nun eine”normale“ Action, zum Beispiel fur einen Button, passiert

aber genau das. Jeglicher Code zwischen ButtonPressed und ButtonReleased wird aufdem Event Dispatching Thread ausgefuhrt. Was dazu fuhrt, dass in dieser Zeit keine Be-nutzereingaben angenommen werden und kein Update der Darstellung erfolgt.

Dauert die Aufgabe nur einen Bruchteil einer Sekunde, merkt das niemand und alle sindglucklich. In der Regel ist das bei Aufgaben wie Fenster schliessen, eine kleine Berechnungdurchfuhren oder Fenster wechseln der Fall. Alles kein Problem.

Dauert die Aufgabe jedoch mehrere Sekunden, oder sogar Minuten, sieht es ganz andersaus: die Folge sind Programme welche wirken, als waren sie gerade abgesturzt. Buttons,die nicht zuruckfedern, Fenster von denen nur noch der Rahmen da ist.

Wenn die Aufgabe erledigt ist, geht es plotzlich wieder. Namlich dann, wenn der EventDispatching Thread wieder frei ist und sich seiner eigentlichen Aufgabe widmen kann.Das ist nicht gerade Vertrauen erweckend.

7.2. Ein neuer Thread

Die Losung scheint zuerst naheliegend. Statt den Event Dispatching Thread zu blockie-ren, startet man einen neuen Thread und lasst diesen die Aufgabe erledigen.

Die Sache hat leider einen kleinen Haken: Swing ist nicht thread-sicher. Um nicht Per-formance einzubussen, sind die meisten Befehle in Swing nicht synchronisiert. Das heisstSwing vertragt es nicht wenn ein anderer als der Event Dispatching Thread Swing Kom-ponenten verandert.

67


Problem

Ein kleines unscheinbares Beispiel ist das Loschen des Inhalts eines Eingabefelds. Ist derEvent Dispatching Thread der einzige welcher Swing Komponenten verandert, wird derInhalt geloscht und das Feld danach neu dargestellt, Eines nach dem Anderen.

Loscht nun aber ein anderer Thread den Inhalt ohne Rucksicht auf den Event Dis-patching Thread kann dieser beim Rendern der Buchstaben auf Unerwartetes stossen:plotzlich ist da kein Text mehr, wo vorher noch einer war. Das Resultat ist eine Excep-tion.

Was nun? Auf der einen Seite sollte man den Event Dispatching Thread sofort wiederfreigeben. Auf der anderen Seite darf aber vom zweiten Thread, welcher die lange Auf-gabe erledigt, nichts an der graphischen Oberflache gemacht werden, weil sonst Swingdurcheinander geraten konnte. Und wie soll man so vom zweiten Thread aus eine Fort-schrittsanzeige realisieren, die Daten einer Transaktion darstellen oder mal kurz denBenutzer etwas fragen?

7.3. Losung: SwingWorker

Seit Java Version 6 gibt es dafur eine elegante Losung: die neue SwingWorker Klasse imPaket javax.swing. Sie wurde dafur gebaut langer dauernde Aufgaben im Hintergrund zuerledigen und, wahrend und nachdem diese erledigt wurde, Ausgaben auf der graphischenOberflache zu tatigen.

Die raffinierte Losung beruht darauf, dass Updates der graphischen Oberflache zwar imSwingWorker definiert werden, aber uber Call-Back Methoden vom Event DispatchingThread ausgefuhrt werden. So bleibt der Event Dispatching Thread der einzige, welcherSwing Komponenten verandert.

Um einen SwingWorker zu implementieren mussen die abstrakte Methode doInBack-ground() ausprogrammiert und bei Bedarf die Methoden done() und process() uberschriebenwerden.

SwingWorker bietet folgende Moglichkeiten:

• Die Methode done() kann uberschrieben werden. Diese wird automatisch am Endeder Aufgabe vom Event Dispatching Thread aus aufgerufen.

• Die Methode doInBackground() muss implementiert werden. Sie definiert was imHintergrund erledigt werden soll. Hier durfen selbstverstandlich keine Zugriffe aufSwing Komponenten stattfinden.

68

7.4. Tipps

• SwingWorker implementiert das Interface Future aus dem Paket java.util.concurrentwelches die Kommunikation mit Hintergrundthreads definiert und Methoden ver-langt um vom Hintergrundthread das Resultat der Arbeit zu holen, den Abbruchder Arbeit zu verlangen oder abzufragen ob die Arbeit schon erledigt ist.

• Der SwingWorker - Thread kann Zwischenresultate mittels publish() publizierenindem er den Event Dispatching Thread auffordert bei Gelegenheit die Methodeprocess() aufzurufen.(Call-Back) Da der Zeitpunkt des Call-Back nicht bestimmtwerden kann, sammelt der Event Dispatching Thread die publizierten Resultateund gibt sie als Liste an die process() Methode.

• Im Swing Worker konnen neue, zusatzliche Bound-Properties definiert werden,welche bei Anderung der Werte Property-Events auslosen, welche wiederum vomEvent Dispatching Thread behandelt werden. Die Bound-Properties Progress undState sind bereits vorhanden.

• Die SwingWorker Klasse ist zudem generisch gebaut und kann beliebige Typen alsResultat oder Zwischenresultat zuruckgeben.

7.4. Tipps

• SwingWorker Instanzen konnen nicht zweimal verwendet werden, beim zweitenMal .execute() wird die Methode doInBackground nicht mehr aufgerufen.

• Damit das Abbrechen funktioniert muss der Code in doInBackground() periodischuber die Methode isCancelled() uberprufen ob er uberhaupt noch was machen soll.

• Achten Sie auf gemeinsame Ressourcen ausserhalb Swing. Nur weil mit dem Swing-Worker die Arbeit mit Swing vereinfacht wurde, heisst das noch nicht, dass derRest der Daten im Programm vor konkurrierenden Zugriffen geschutzt ist.

• Nach dem Starten des Hintergrund-Thread ist der Event Dispatching Thread gleichwieder frei. Das ist gut so. Bedeutet aber auch, dass der Benutzer beliebige Buttonsdrucken kann. Darum: nicht vergessen die Actions auszuschalten, die wahrend derHintergrundverarbeitung nicht gestartet werden durfen.

7.5. Action mit SwingWorker: ErgoSwing07

Das mitgelieferte Beispiel zeigt eine Implementierung des SwingWorker im Einsatz. DasProgramm berechnet im Hintergrund Primzahlen, liefert als Zwischenresultat jede biszu dem Zeitpunkt gefundene Primzahl. (Abbildung 2.7.1

69


Abbildung 2.7.1.: Primzahlen berechnen mit SwingWorker

Die Berechnung lauft im Hintergrund bis der Benutzer abbricht oder die grosste als Inte-ger darstellbare Zahl uberpruft wurde. Als Resultat wird die bis dahin grosste gefundenePrimzahl zuruckgegeben.

7.6. Pattern

• Observer Pattern (S. 155)

• Template Method Pattern (S. 173)

• State Pattern (S. 167)

70

8. Look and Feel

8.1. Begriff

Mit dem Begriff Look and Feel (Aussehen und Handhabung) bezeichnet man das De-sign der graphischen Benutzeroberflache und deren Bedienung. Dazu zahlen Eigenschaf-ten wie Farbe, Layout, Schriftgrossen, Rander und das Aussehen der Steuerelemen-te.

8.2. Wozu eigentlich?

In den meisten Fallen, wo der Look and Feel verandert werden soll, sind es nur margi-nale Anderungen. Meist geht es darum die Benutzeroberflache zu vereinheitlichen, denschon vorhandenen Applikation anzugleichen oder einfach nur das Corporate Designeinzuhalten.

Naturlich kann man nun jedes Steuerelement einzeln einstellen. Zum Beispiel durchVorgabe einer bestimmten Schriftart oder einer Farbe oder eines bestimmten Rahmens.Spatestens wenn es mehr als eine Maske ist und die Steuerelemente sich ansammeln, mussnach Losungen gesucht werden, damit die Darstellung einheitlich bleibt.

Dazu bieten sich folgende Losungen an:

• Das Verwenden von fertig konfigurierten Steuerelement-Bibliotheken

• Das Erstellen einer eigenen Sammlung von angepassten Steuerelementen

• Das gezielte Andern eines existierenden Look and Feel

Dem Verwenden von fertigen Bibliotheken stehen die Anforderungen der Kunden ge-genuber. Sind diese mit dem Aussehen der Steuerelementen zufrieden, ist dies vermutlichdie einfachste Losung.

Eigene Bibliotheken von Steuerelementen sind zwar flexibel aber auch sehr aufwendig.Nicht selten entstehen dabei weit uber hundert Klassen. Das Einhalten eines einheitlichenAussehens ist dabei meist von der Disziplin der Entwickler abhangig. Schnell passiertes, dass Schrift-Einstellungen in einer Klasse

”hart-codiert“ werden. Und dann wird die

Umstellung der Sammlung auf einen neuen Font richtig aufwendig.

71

8. Look and Feel

Die Losung liegt in der Verwendung der Mittel von Swing. Mittels der UIManager Klasselassen sich Eigenschaften wie

• Rahmen

• Farbe

• Grosse

• Schrift

• Icon

• Abstande

• Beschriftung

einstellen.

8.3. Mal eben schnell die Farbe aller Fenster wechseln

Swing wurde so gebaut, dass das Aussehen, der sogenannte Look and Feel, geandertwerden kann. Dies wird durch die Trennung der Steuerelemente in die Komponente(JComponent) und deren Darstellung (ComponentUI) erreicht.

Falls Sie nicht gerade einen neuen Look and Feel entwickeln, werden Sie mit den Darstel-lung Klassen (Z.B. ListUI) nur ganz selten zu tun haben. Das Delegieren der Darstellung(paint()) an die entsprechende UI-Klasse erfolgt in den Mutterklassen wie JCompo-nent.

8.4. Einzelne Eigenschaften abfragen und einstellen

Die einzelnen Eigenschaften werden uber Schlussel-Wert Paare eingestellt. Beim Schlusselhandelt es sich um einen String welcher ublicherweise die Komponente kennzeichnet ge-folgt von einem Punkt und dann welche Eigenschaft gemeint ist.

Ein bestimmter Look and Feel kann nun die gewunschten Eigenschaften abfragen oderauch nicht. Dies bedeutet, dass es vom Look and Feel abhangig ist, welche Einstellungenuberhaupt Auswirkungen haben.

Die UIManager Klasse bietet eine Vielzahl von Methoden an um die Einstellungen abzu-fragen. Damit nicht jedes Mal zuerst uberpruft werden muss, ob sich hinter dem Schlusseleffektiv eine Farbe oder ein Rahmen befindet, geben diese Methoden gleich den richti-gen Typ zuruck oder Null falls es den Schlussel nicht gibt oder sich eben nicht um dengewunschten Typ handelt.

72

8.5. Look and Feel: ErgoSwing08

Abbildung 2.8.1.: Mit Look and Feel experimentieren

8.5. Look and Feel: ErgoSwing08

Mit dem mitgelieferten Programm ErgoSwing08 (Abbildung 2.8.1) lasst sich ein wenigmit Look and Feel experimentieren. Das Programm erlaubt zwischen den installiertenLook and Feels hin und her zu schalten und verschiedene Farbeinstellungen vorzuneh-men.

Dazu wird zuerst einer der uber 250 Schlussel ausgewahlt (Abbildung 2.8.2) und dannuber den Button

”Farbe setzen“ der ColorChooser von Java aufgerufen. (Abbildung

2.8.3)

Um den Wechsel des Look and Feel an schon geoffneten Fenstern zu demonstrieren,konnen uber die Taste

”Beispiele anzeigen“ beliebig oft drei weitere Fenster geoffnet

werden. Diese wechseln ihr Aussehen gleichzeitig mit den Anderungen in ErgoSwing08.(Abbildung 2.8.4)

8.6. Snippet: Look and Feel setzen

Um unnotige Zeitverzogerungen beim Starten der Applikation zu vermeiden sollte derLook and Feel als erstes eingestellt werden, noch bevor Masken aufgebaut werden. Damit

73

8. Look and Feel

Abbildung 2.8.2.: Schlussel fur Farbeinstellung auswahlen

wird vermieden, dass der Default Look and Feel initialisiert wird.

Fur das Handling des Look and Feel ist die UIManager Klasse aus dem Paket javax.swingverantwortlich. Die Umstellung erfolgt durch Ubergabe des Look and Feel Klassenna-men:

// Setzen des "Metal" Look and Feel

UIManager.setLookAndFeel("com.sun.java.swing.plaf.motif.MotifLookAndFeel");

Das Setzen des Look and Feels kann Exceptions werfen, welche abgefangen werdenmussen:

• UnsupportedLookAndFeelException

• ClassNotFoundException

• InstantiationException

• IllegalAccessException

Der UIManager kann die Klassennamen des System - Look and Feel und des Default JavaLook and Feel liefern, was das Setzen des Look and Feel etwas vereinfacht:

74

8.7. Snippet: Look and Feel schon beim Starten festlegen

Abbildung 2.8.3.: JColorChooser in Aktion

// Setzen des System - Look and Feel

UIManager.setLookAndFeel(

UIManager.getSystemLookAndFeelClassName());

// Setzen des Java - Look and Feel

UIManager.setLookAndFeel(

UIManager.getCrossPlatformLookAndFeelClassName());

8.7. Snippet: Look and Feel schon beim Starten festlegen

Der gewunschte Look and Feel kann auch schon beim Starten der Virtual Machine,mittels des Attributs swing.defaultlaf festgelegt werden:

java -Dswing.defaultlaf=com.sun.java.swing.plaf.windows.WindowsLookAndFeel

75

8. Look and Feel

Abbildung 2.8.4.: Look and Feel wechseln bei laufender Applikation

76

8.8. Snippet: Liste der Schlussel beschaffen

8.8. Snippet: Liste der Schlussel beschaffen

Mit dem folgenden Code lassen sich die Schlussel des aktuell eingestellten Look and Feelausgeben:

LookAndFeel laf = UIManager.getLookAndFeel();

UIDefaults uiD = laf.getDefaults();

Set<Object> keySet = uiD.keySet();

for (Object key : keySet) {

System.out.println(key);

}

8.9. Snippet: Beispiele fur”Wert setzen“

//Schrift fur Labels einstellen

UIManager.put("Label.font", new Font("Dialog",Font.BOLD, 12));

//Schriftfarbe fur die Angabe des Tastenkurzels bei Menupunkten

UIManager.put("MenuItem.acceleratorForeground", Color.RED);

//Rahmen um die Pfeil-Buttons bei einem Spinner-Feld

UIManager.put("Spinner.arrowButtonBorder",

BorderFactory.createEmptyBorder());

//Minimum Hohe fur Slider

UIManager.put("Slider.minimumVerticalSize", 15);

8.10. Pattern

• Abstract Factory Pattern (S. 109)

• Facade Pattern (S. 133)

• Singleton Pattern (S. 165)

77

9. Flexible Fenstergrossen

9.1. Wenn das Grosste der Bildschirm ist

Wie erlaubt man dem Benutzer Fenster-Grossen anzupassen und behalt dabei ein er-gonomisches Design? Der Trick liegt darin das Fenster in dynamische und fixe Teileaufzuteilen. Beim Verandern der Grosse des Fensters sollen sich die dynamischen Teileanpassen und die fixen Teile ihre Grosse beibehalten.

Das in Abbildung 2.9.1 gezeigte Beispiel verwendet drei Panels:

1. Die Beschreibung zum Fenster als fixen Teil

2. Die Tabelle als dynamischen Teil

3. Die Buttons wiederum als fixen Teil

Die Abbildungen 2.9.2 und 2.9.3 zeigen wie sich die fixen und dynamischen Teile zuein-ander verhalten.

Abbildung 2.9.1.: Schweizer Kantone

79

9. Flexible Fenstergrossen

Abbildung 2.9.2.: Schmale Anzeige der Kantone

Abbildung 2.9.3.: Breite Anzeige der Kantone

80

9.2. Flexible Fenstergrossen: ErgoSwing09

9.2. Flexible Fenstergrossen: ErgoSwing09

Das mitgelieferte Programm zeigt auf, wie schon mit einfachen Mitteln wie BorderLay-out, FlowLayout und einer ScrollPane ein dynamisches Fenster wie in den Abbildungen2.9.1 bis 2.9.3 realisiert werden kann.

81

10. Fehlermeldungen

10.1. Eingabe nicht korrekt!

Eine der Aufgabe von Eingabemasken ist die Uberprufung der Eingaben und entspre-chende Verstandigung uber Fehler oder das Stellen von Ruckfragen.

Da sich solche Dialoge direkt an den vor dem Bildschirm sitzenden Benutzer wenden,ist ein bisschen Fingerspitzengefuhl gefragt. Schliesslich soll das Programm den Benut-zer bei der Arbeit unterstutzen und nicht mittels unsinniger Meldungen davon abhal-ten.

Fragen mussen mit den moglichen Antworten zusammenpassen und widerspruchsfreisein. Vorsicht, Benutzer tendieren nach einer Weile dazu zu fruh die Entertaste zudrucken und damit die Default-Auswahl zu nehmen. Wahlen Sie also geschickt aus,welcher Button, z.B. Ja oder Nein, als Default gilt.

Die Ruckmeldungen sollen zudem den Benutzer nicht im Arbeitsfluss storen, aber auchnicht zu spat erfolgen. Siehe auch Kapitel

”Fehlertolerant“ auf Seite 21

10.2. Der Situation angepasste Icons verwenden

Achten Sie bei der Erstellung von Ruckmeldungen und Fragen auf das gewahlte Icon.Dieses kleine, gestalterische Element hat mehr Auswirkungen, als man auf den erstenBlick vermuten wurde.

So wird das Icon vom Auge erfasst und vom Gehirn ausgewertet, lange bevor der Textdazu gelesen und verstanden wurde. Es hat Signalwirkung und kann beeinflussen obText aufmerksam, nur fluchtig oder gar nicht gelesen wird.

Soll nun die Aufmerksamkeit des Benutzers geholt werden, kann dies mit einem entspre-chenden Icon geschehen. Die Voraussetzung ist, dass dieses Icon auch wirklich nur danngezeigt wird, wenn die Aufmerksamkeit des Benutzers verlangt ist.

Information Icon

Das Information Icon sollte eine unaufdringliche, neutrale Farbe wie Blau haben. Es dientdazu dem Benutzer eine Bestatigung oder Hinweise zu geben. (Abbildung: 2.10.1)

83

10. Fehlermeldungen

Abbildung 2.10.1.: Information Icon fur einfache Ruckmeldung

Abbildung 2.10.2.: Frage Icon fur unkritische Frage

Frage Icon

Auch dieses Icon sollte mit einer neutralen Farbe wie Blau gestaltet werden. Damitwerden Dialoge ausgestattet, welche mehrere Auswahlmoglichkeiten anbieten und dem

”normalen“ Verlauf der Arbeit entsprechen. (Abbildung: 2.10.2)

Warnung Icon

Das Warnung Icon dient dazu die Aufmerksamkeit des Benutzers zu holen und solltefur kritische Ruckfragen eingesetzt werden. Wird es zu oft oder fur unkritische Fragenverwendet, verliert es an Wirkung. (Abbildung: 2.10.3)

Kritischer Fehler Icon

Das kritischer Fehler Icon sollte mit einer Signalfarbe wie Rot gestaltet werden. Eszeigt eine schwerwiegende Situation an. Verwenden Sie dieses Icon nicht um fehler-hafte Benutzereingaben zu bemangeln, sondern gehen Sie mit diesem Icon sparsamum. Eigentlich sollte es in einem Programm gar nie auftreten, es sei denn, es ist aufeinen schweren Fehler aufgelaufen und die Arbeit muss beendet werden. (Abbildung:2.10.4)

84

10.3. Eingaben prufen mit InputVerifier

Abbildung 2.10.3.: Warnung Icon fur kritische Frage

Abbildung 2.10.4.: Kritischer Fehler Icon fur Programmabsturz

10.3. Eingaben prufen mit InputVerifier

Sollen Eingaben gleich vor dem Verlassen des betreffenden Eingabefelds uberpruft wer-den, bietet sich die Klasse InputVerifier aus dem Paket javax.swing an. Objekte diesesTyps konnen einem beliebigen Objekt des Typs JComponent mittels der Methode se-tInputVerifier() zugewiesen werden.

Falls ein solcher InputVerifier zugewiesen wurde, wird dieser vor jedem Verlassen derbetroffenen JComponent von Swing mittels der Methode shouldYieldFocus() angestos-sen. Der InputVerifier kriegt so die Moglichkeit die Daten vor dem Verlassen des Felds zuprufen, entsprechend zu reagieren und den Fokustransfer zu verhindern.

Beim InputVerfifier handelt es sich um eine kleine abstrakte Klasse, welche durch eineeigene Implementierung angepasst werden muss. Das Beispiel ErgoSwing10 zeigt einemogliche Anwendung.

10.4. Eingabeformat festlegen mit JFormattedTextField

Mit dem JFormattedTextField lassen sich bequem Eingabefelder realisieren, die Da-ten ausschliesslich in einem bestimmten Format annehmen. Die erlaubten Zeichen unddie Darstellung der Daten konnen mittels eines ubergebenen Formatter festgelegt wer-den.

85

10. Fehlermeldungen

10.5. Snippet: DateFormatter

// Datum Eingaben mit Default - Format

DateFormatter df = new DateFormatter(DateFormat

.getDateInstance());

JFormattedTextField textField = new JFormattedTextField(

df);

// Datum Eingaben im Format TT.MM.JJ

DateFormatter df = new DateFormatter(DateFormat

.getDateInstance(DateFormat.SHORT, Locale.GERMAN));


df);

10.6. Snippet: NumberFormatter

// Eingeben im lokalen Wahrungsformat

NumberFormatter nf = new NumberFormatter(NumberFormat

.getCurrencyInstance());


nf);

10.7. Snippet: MaskFormatter

// 4-stellig hexadezimale Zahl

MaskFormatter mf;

JFormattedTextField textField;

try {

mf = new MaskFormatter("****");

mf.setValidCharacters("0123456789abcdefABCDEF");

textField = new JFormattedTextField(mf);

} catch (ParseException e) {

e.printStackTrace();

}

86

10.8. InputVerifier: ErgoSwing10

10.8. InputVerifier: ErgoSwing10

Das mitgelieferte Programm ErgoSwing10 (Abbildung 2.10.5) erlaubt die Berechnungvon Tilgungsraten fur einen Kredit bei gleich bleibendem Zinssatz. Die Eingabefelderwerden mit einer Implementierung des InputVerifier auf gultige Eingaben uberpruft.

Das einfache Programm soll eine Moglichkeit aufzeigen, den Benutzer auf Fehleinga-ben aufmerksam zu machen, ohne den Arbeitsfluss zu beeintrachtigen. Eingaben wer-den gleich uberpruft und falls sie ungultig sind das Eingabefeld hervorgehoben. DerBenutzer kann aber selber bestimmen, wann er den Wert in Ordnung bringen will.

ErgoSwing10

• Berechnet monatliche Tilgung fur einen Kredit bei gewahlter Laufzeit und festemZinssatz

• Erlaubter Bereich der Eingaben wird als Tooltip bei den Eingabefeldern angezeigt

• Eingaben werden beim Verlassen des Eingabefelds oder beim Drucken der Einga-betaste ubernommen

• Ungultige Eingaben werden mit einem roten Hintergrund markiert

• Resultat wird nur angezeigt, wenn alle Eingaben in Ordnung sind

RangeInputVerifier

• Erweiterung des abstrakten InputVerifier mit mehr Funktionalitat

• Konfiguration von Minimum und Maximum Wert

• Angabe NumberFormat fur Parsen

10.9. Pattern


• Strategy Pattern (S. 169)

87

10. Fehlermeldungen

Abbildung 2.10.5.: Kreditrechner

88

11. Hilfe

11.1. Kontextsensitive - Hilfe

Wie implementiere ich kontextsensitive Hilfe und was ist das uberhaupt?

Mit kontextsensitiver Hilfe bezeichnet man Informationen, die passend zur aktuellenAufgabenstellung angezeigt werden. Mit anderen Worten, abhangig davon, wo sich derBenutzer in einem Programm befindet, wird bei Bedarf die entsprechende Seite desHandbuchs automatisch aufgeschlagen.

Kontextsensitive Hilfe hilft Anfangsschwierigkeiten zu uberwinden und ist gleichzeitigauch von Profis geschatzt. Diese brauchen zwar seltener Hilfe, sind aber trotzdem froh,wenn sie sie dann schnell erhalten. Und dies ohne den Umweg uber Inhaltsverzeichnis,Index oder Volltextsuche zu machen.

11.2. Aufrufen von Hilfe

In den meisten Applikationen gibt es folgende Moglichkeiten Hilfe aufzurufen:

• uber Menu

• uber ein Toolbar-Icon

• uber einen oder mehrere Hilfe-Buttons

• durch Drucken der F1 Taste

Die F1 Taste eignet sich am besten um kontextsensitive Hilfe zu implementieren. Denndiese kann ohne Wechsel des Fokus bedient werden. Dadurch kann das Programm aufGrund der aktuellen Position des Fokus,

”erraten“ welche Hilfeseite dem Benutzer wohl

am meisten dienen wurde.

Beim Aufruf uber Menu, Button oder Icon wird eher Hilfestellung zum aktuellen Fensteroder zur aktuellen Aufgabenstellung geboten.

Eine weitere Variante sind sogenannte Assistenten. Diese konnen sogar ihre Hilfe an-bieten, ohne dazu aufgefordert zu werden. Denn es ist moglich, trotz dem Wechsel desFokus von Eingabefeldern, zu Menus und dann wieder zu Buttons, kontextsensitive Hilfeanzubieten. Dies bedeutet jedoch, dass das Programm mehr oder weniger die Ganze Zeit

89

11. Hilfe

uberwachen und analysieren muss, was der Benutzer macht. Da solche Hilfe aufwendigzu implementieren ist, trifft man sie eher selten an.

11.3. Tooltipps als Ersatz fur Handbucher?

Gleich vorne weg: Tooltipps sind kein Ersatz fur Hilfeseiten oder Handbucher. Tooltippskonnen zwar uber kleine Hurden hinweg helfen. Sie sind aber eher als Eselsleitern odereben nur Tipps anzuschauen.

Zudem haben sie auch Nachteile. Da Tooltipps dann angezeigt werden, wenn mit derMaus uber das entsprechende Steuerelement navigiert wird, kann der Tooltip auch storen.Unter Umstanden verdeckt er dann die Sicht auf das Eingabefeld, statt zu helfen. Ausdemselben Grund und weil der Tooltip nach ein paar Sekunden von selbst wieder ver-schwinden soll, kann auch nicht jede Menge Text reingepackt werden.

Handbucher oder Hilfeseiten konnen jedoch beliebig aufwendig gestaltet werden und derBenutzer kann sie auf dem Bildschirm auf die Seite schieben und solange offen lassenwie es notig ist.

11.4. In drei Schritten Hilfe erstellen

1. Handbucher und Hilfeseiten erstellen

2. Mapping der Steuerelemente auf die Hilfeseiten

3. Implementierung des Mappings und der Aufrufe

Der grosste Aufwand liegt beim Erstellen der Handbucher und Hilfeseiten. Noch schlim-mer wird es, wenn fur die Hilfe spezielle Tools verwendet werden mussen und dadurch einMedienbruch zwischen Handbuch und der Hilfe im Programm entsteht.

Im Idealfall brauchen fur die im Programm angezeigte Hilfe keine weiteren aufwendi-gen Dateien erstellt zu werden. Das Programm offnet dann beim Hilfeaufruf einfach dieDatei des Handbuchs oder fuhrt den Benutzer auf die entsprechende Seite im Inter-net.

Beim Mapping der Steuerelemente auf die Hilfeseiten, wird entschieden, welche Stelleaus den Handbuchern oder welche Seite aus dem Internet pro Steuerelement angezeigtwerden soll.

Wenn es richtig gemacht wird ist die Implementierung der am wenigsten aufwendigeSchritt. Das Beispiel ErgoSwing11 im gelieferten Source Code zeigt wie so etwas, ohneaufwendiges Framework, realisiert werden kann.

90

11.5. HelpService - ein einfaches Hilfe-System: ErgoSwing11


Das etwas minimalistische Beispiel zeigt wie mit weniger als 200 Zeilen Code ein Hilfe-system gebaut werden kann.

HelpService

HelpService ist die zentrale und gleichzeitig einzige Klasse des ganzen Hilfesystems. Sieverwaltet intern die eigene Instanz (Singleton) und wird uber statische Methoden ver-wendet. (Abbildung 2.11.1

Eine Map fuhrt die registrierten Komponenten und das beim Aufruf anzuzeigende Fileals Pfad-Angabe.

Sobald das erste Programm den HelpService verwendet, zum Beispiel um eine Hilfe-Seitezu registrieren, erstellt der HelpService eine Instanz und meldet sich beim Keyboard-FocusManager an. Ab diesem Zeitpunkt wird der HelpService uber jeden Tastendruckinnerhalb der Java Virtual Machine verstandigt. (Abbildung 2.11.2

Wird nun die Funktionstaste F1 gedruckt, versucht der HelpService entsprechend Hilfeanzuzeigen. Ausgehend von der Komponente, welche zurzeit den Fokus hat, wird imAufbau in Richtung Fenster nach der ersten Komponente gesucht, welche registriertwurde. Diese Hilfe wird dann angezeigt.

ErgoSwing11

Zur Demonstration des HelpService wurde das Programm aus dem Kapitel”Eingabe“

um einen Hilfe-Button und kontextsensitive Hilfe erweitert. Fur das Registrieren derKomponenten und Angeben des Mappings wurden nur gerade ein paar Zeilen Codeeingefugt.

Damit es uberhaupt etwas zum Anzeigen gibt, befinden sich ein paar Dummy Hilfe-Seitenals Pdf-Files im Ordner res/help/.

Obwohl es auf diesem Fenster sieben verschiedene Steuerelemente hat, aber nur vierHilfe-Seiten, zeigt jedes von denen beim Drucken von F1 Hilfe an. Wie ist das moglich?

Die Losung liegt darin, dass der HelpService selbststandig im Aufbau des Fensters nacheiner ubergeordneten Komponente sucht, welche Hilfe anzeigt. Wenn also die obersteKomponente, Hilfe anbietet (das Fenster), konnen alle Steuerelemente darunter dieseHilfe auf Knopfdruck auch anzeigen. (Abbildung 2.11.3

91

11. Hilfe

HelpService

- helpService: HelpService- helpMapping: Map

+ dispatchKeyEvent(KeyEvent) : boolean+ register(Component, String) : void+ unRegister(Component) : void+ showHelp(Component) : void

«Constructor»- HelpService()

«interface»KeyEventDispatcher

+ dispatchKeyEvent(KeyEvent) : boolean

ErgoSwing11

KeyboardFocusManager

verwendet

registriert sich alsKeyEventDispatcher

Handelt alleKeyEvents derProgramme in derJVM

Verständigt überKeyEvents

Abbildung 2.11.1.: UML Diagramm HelpService

92


dispatchKeyEvent()

Wurde F1 gedrückt?

showHelp(source)

Source desKeyEvent einComponent?

showHelp(null)

[nein]

[ja]

Abbildung 2.11.2.: UML Diagramm HelpService - KeyEvents

93

11. Hilfe

showHelp(Component)

Ist Componentübermittelt?

Component welchezur Zeit den Focus

hat beschaffen

In der MapComponent

nachschlagen

Eintrag gefunden?

Hilfe anzeigen

Hat Component einenParent?

Parent wird zuraktuellen

Component

Keine Hilfegefunden. Hinweis

ausgeben

[nein]

[ja]

[ja]

[nein]

[ja]

[nein]

Abbildung 2.11.3.: UML Diagramm - Hilfe suchen

94

11.6. Pattern

Registrieren eines einzelnen Steuerelments

HelpService.register(zahlFeld, "res/help/HilfeZahl.pdf");

Registrieren von Hilfe auf Fenster-Ebene

HelpService.register(this, "res/help/HilfeFenster.pdf");

Kontextsensitives Aufrufen von Hilfe

Fur das Handling der Aufrufe via F1 - Taste ist in ErgoSwing11 kein Code notig. Die Ar-beit wird vom HelpService in der Rolle als KeyEventDispatcher erledigt.

Gezieltes Aufrufen von Hilfe

Steht zum Beispiel ein Hilfe-Button zur Verfugung, dann wird damit der HelpServiceangestossen. Als Argument wird entweder eine ganz bestimmte Komponente oder einfachder Hilfe-Button selbst ubergeben.

Das folgende Beispiel zeigt, wie im Programm ErgoSwing11 der Hilfe-Button die Hilfezum Fenster anzeigt:

helpButton.addActionListener(new ActionListener(){

@Override

public void actionPerformed(ActionEvent e) {

//Zeigt die Hilfe zum Fenster an

HelpService.showHelp(ErgoSwing11.this);

}

});

11.6. Pattern

• Chain of Responsibility Pattern (S. 119)

• Facade Pattern (S. 133)

• Singleton Pattern (S. 165)


95

12. Eingabefelder optimieren

12.1. Wenn Profis und Anfanger dieselbe Maske verwenden

Software soll auf den Benutzer zugeschnitten sein. Dies ist gar nicht so einfach zu bewerk-stelligen. Schliesslich gibt es nicht nur unterschiedliche Benutzer, sondern jeder einzelneBenutzer andert sich und lernt mit der Zeit dazu.

Ist eine Software brandneu, sind alle Benutzer erstmal Anfanger. Dann sollten die Mas-ken so einfach wie moglich gebaut sein und jede erdenkliche Hilfe anbieten. Kommtaber Erfahrung dazu, andern sich die Anspruche. Dann sollten die Masken eine schnelleBedienung erlauben und sich auf das Wesentliche konzentrieren.

Die Schwierigkeit ist nun, dass die Software Anfanger unterstutzen und gleichzeitig ver-sierten Benutzern erlauben soll moglichst effizient zu arbeiten.

12.2. Alternative Navigation und Eingabemoglichkeiten

Der Trick liegt nun darin unterschiedliche Navigations- und Eingabemoglichkeiten an-zubieten, ohne dass sich diese in die Quere kommen.

Tabulator

Die Navigation mittels Tabulator ist eine beliebte Variante um sich von Steuerele-ment zu Steuerelement fortzubewegen. Jede Maske sollte das Navigieren zwischen denSteuerelementen mittels Tabulatortaste erlauben und eine sinnvolle Reihenfolge vorge-ben.

Die Aufgabe der Entwickler ist es nun diese Reihenfolge zu uberprufen und im Zweifelsfallmit dem Kunden zu besprechen. Java nimmt bei dieser Aufgabe schon viel Arbeit ab. DieNavigation erfolgt

”automatisch“ von oben links nach unten rechts.

97


Tastenkurzel fur Eingabefelder

Wenn von vielen Eingabefeldern der Cursor in ein ganz bestimmtes soll, dann konnen dieBenutzer entweder mit der Maus rein klicken oder mit dem Tabulator hin fahren. Profiswunschen sich fur diesen Fall noch eine dritte Moglichkeit: das Tastenkurzel.

Dazu werden Eingabefelder mit einer Tastenkombination hinterlegt die dazu fuhrt, dassder Cursor in das entsprechende Feld springt. Im Idealfall kommt der Buchstabe derKombination in der Beschriftung des Feldes vor. Dann kann das Tastenkurzel in der Be-schriftung durch Unterstreichen des Buchstabens sichtbar gemacht werden. Buchstabenkonnen aber auch zugewiesen werden, wenn sie nicht im Text vorkommen. Der Benutzermuss dann einfach wissen, welcher es ist.

Sinnvolle Default - Werte

Die Arbeit der Benutzer wird dadurch erleichtert, indem Eingabefelder mit Default-Werten schon vorbelegt sind. Dabei ist aber Vorsicht geboten. Muss der Wert in mehrals der Halfte der Falle doch geandert werden, ist der Vorteil weg.

Automatisches Vervollstandigen

Eine elegante Art die Arbeit der Benutzer zu vereinfachen, ist das automatische Ver-vollstandigen von Eingaben. Ein typisches Beispiel sind die Auswahllisten, die sich schonbeim Eingeben der ersten Buchstaben gleich zu den entsprechenden Eintragen bewegen.Mit ein bisschen Gluck braucht es so nur ein oder zwei Buchstaben und schon ist derrichtige Eintrag ausgewahlt.

Auch sehr praktisch sind Vorschlage, wie der gerade eingegebene Text vervollstandigtwerden konnte. Diese tauchen als Liste gleich unter der aktuellen Cursorposition aufund konnen mit den Pfeiltasten selektiert werden. Gerade das Editieren von SourceCode ware ohne diese praktische Hilfe sehr muhsam.

Ein anderes Beispiel sind Datum-Eingabefelder, welche das Jahr selber erganzen, wennes nicht eingegeben wird.

Durch Assistenten gefuhrte Eingaben

Ein fur Anfanger besonders komfortable Eingabemoglichkeit sind Assistenten. Diesefuhren den Benutzer durch das Ausfullen der Eingabefelder mittels Erklarungen undRuckfragen.

Manche Assistenten gehen dabei soweit nur ein paar Fragen auf abstrakter Ebene zu stel-len und dann eine vollstandige Arbeit abzuliefern. Fur Gelegenheitsbenutzer welche allepaar Monate mal eine Prasentation brauchen, ist das sicher eine valable Moglichkeit.

98

12.3. Optimierte Eingabefelder: ErgoSwing12

Abbildung 2.12.1.: Auswahl der zu druckenden Seiten

Profis brauchen solche Assistenten meist nur um ein Grundgerust anzulegen und dannvon Hand noch selber zu verfeinern und anzupassen. Fur lernwillige Anfanger haben dieseAssistenten leider meist zu wenige Erklarungen, was im Hintergrund passiert.

Besonders gut ausgestattete Programme fuhren Assistenten mit einem Tutorial-Modus.Diese fuhren durch die Eingaben und erklaren gleichzeitig die Funktionen und Aus-wahlmoglichkeiten.

Eingabemoglichkeit mit Parser

Erstellen von Makros und Formeln sind typische Anwendungsfalle fur geparste Eingabe-felder. Dies sind Eingabefelder, in die der Benutzer einen Ausdruck eingeben kann undder Ausdruck vom Programm ausgewertet und interpretiert wird.

Werden solche Eingabefelder noch mit der Moglichkeit verknupft uber andere Steuer-elemente sich den Ausdruck zusammen zu klicken, wird daraus eine der effizientestenMoglichkeit die Arbeit zu beschleunigen.

Die Abbildung 2.12.1 zeigt ein schones Beispiel aus dem Drucken-Dialog einer Textver-arbeitung. Mittels diesem Feld konnen zum Beispiel die zweite und dritte Seite und allerestlichen Seiten ab Seite 17 ausgedruckt werden, indem

”2-3; 17-“ eingegeben wird.

12.3. Optimierte Eingabefelder: ErgoSwing12

Mit dem mitgelieferten Programm lassen sich Tastenkurzel ausprobieren. (Abbildung2.12.2) Alle Eingabefelder konnen mittels

”Alt“ und der entsprechenden Taste ange-

sprungen werden.

Das Datumfeld ist zudem als Spinner gebaut. Es bietet verschiedene Moglichkeiten dasangezeigte Datum zu verandern:

• Eingabe eines Datums

99


Abbildung 2.12.2.: Beispiel Programm mit Tastenkurzel

• Mittels der”nach oben“ und

”nach unten“ Pfeiltasten

• Durch Klicken auf die Spinner-Buttons

Je nachdem welche Zahl des Datums markiert ist, werden mit den Spinner-Buttons odermit den Pfeiltasten entweder der Tag, der Monat oder das Jahr geandert.

12.4. Snippet: Datum-Spinner

Das Snippet zeigt wie mit kleinem Aufwand so ein Datum-Spinner erstellt wird. Das Bei-spiel kann mit wenigen Zeilen Code noch erweitert werden. So konnen beim Erstellen desModels fur den Spinner noch folgende Werte angegeben werden:

• Initialdatum (Default: Aktuelles Datum)

• Kleinster Wert (Default: Keine Untergrenze)

• Grosster Wert (Default: Keine Obergrenze)

// Model erstellen, damit Spinner mit Daten arbeitet

SpinnerDateModel dm = new SpinnerDateModel();

100

12.5. Der Swing JSpinner

// JSpinner erstellen und Model ubergeben

JSpinner datumFeld = new JSpinner(dm);

// Editor mit gewunschtem Eingabeformat erstellen

JSpinner.DateEditor ed = new JSpinner.DateEditor(

datumFeld, "dd.MM.yyyy");

// Editor dem Feld zuweisen

datumFeld.setEditor(ed);

12.5. Der Swing JSpinner

Mit Hilfe der Spinner-Komponente lassen sich bequem Daten, Zahlen oder Elemente auseiner Liste auswahlen. Die Abbildung 2.12.3 zeigt die JSpinner Komponente und ihreRelationen.

SpinnerDateModel

Das SpinnerDateModel wird verwendet um Kalender-Daten hinter dem Spinner abzu-legen. Das Model nimmt untere und obere Grenze und die Schrittweite der Buttonsentgegen.

SpinnerListModel

Das SpinnerListModel wird dazu verwendet eine Liste von Objekten als Basis zu nehmenund mit den Spinner-Buttons durch zu navigieren.

SpinnerNumberModel

Das SpinnerNumberModel wird wie das SpinnerDateModel dazu verwendet eine”auto-

matisch“ erstellte Liste von Zahlen (int oder double) durch zu navigieren. Dabei kannhier auch die obere und untere Grenze und die Schrittweite der Buttons angegebenwerden.

JSpinner.DateEditor

Beim Editor fur das SpinnerDateModel kann das Format des Eingabefelds festgelegtwerden.

101


JSpinner.ListEditor

Der ListEditor komplettiert eingebenen Text automatisch zu einem vorhandenen Ein-trag.

JSpinner.NumberEditor

Beim Editor fur das SpinnerNumberModel kann das Zahlenformat des Eingabefelds fest-gelegt werden.

SpinnerModel

Das Interface SpinnerModel stellt sicher, dass alle SpinnerModels wenigstens folgendeFunktionen anbieten:

• Registrieren von ChangeListener

• Abfragen des aktuellen Elements

• Setzen des aktuellen Elements

• Abfragen des nachsten Elements

• Abfragen des vorherigen Elements

12.6. Pattern



102

12.6. Pattern

JComponent

JPanel JSpinner

«interface»SpinnerModel

+ addChangeListener(ChangeListener) : void+ getNextValue() : Object+ getPreviousValue() : Object+ getValue() : Object+ removeChangeListener(ChangeListener) : void+ setValue(Object) : void

«JSpinner»DefaultEditor

JFormattedTextField AbstractSpinnerModel

«JSpinner»DateEditor

«JSpinner»ListEditor

«JSpinner»NumberEditor

SpinnerDateModel

SpinnerListModel

SpinnerNumberModel

«verwendet alsModel»

«hat als Editor»

«Uses»

«Uses»

«Uses»

«Uses»

Abbildung 2.12.3.: UML Klassendiagramm JSpinner

103

Teil III.

Design Patterns und Ergonomie

105

Was sind Design Patterns?

Design Patterns sind Losungen zu wiederkehrenden Problemen. Sie dienen dazu, dasRad nicht bei jedem neuen Programm neu zu erfinden.

Damit die Kommunikation zwischen den Entwicklern einfacher vonstatten geht, hat manden Patterns Namen gegeben. Erich Gamma, Richard Helm, Ralph Johnson und JohnVlissides haben diesen Job ubernommen. Sie veroffentlichten 1994 das Buch

”Design

Patterns - Elements of Reusable Object-Oriented Software“ [GHJV95] und erstelltendamit das Standardwerk zum Thema. Die vier Herren laufen auch unter dem BegriffGang of Four, oder kurz GoF.

Haufig werden mehrere Patterns zusammen verwendet. Softwarearchitekten beschreibenihre Losungen oft nur bis auf die Pattern - Ebene und uberlassen dann die eigentlicheImplementierung den Softwareentwicklern.

Weitere Eigenschaften von Pattern:

• Pattern passen oft auf ganz naturliche Weise zusammen

• ein Pattern kann zum nachsten Pattern fuhren

• in manchen Situation lassen sich Pattern gegenseitig austauschen

• Pattern sind eine Beschreibung der Losung auf hohem abstraktem Niveau

• Patterns enthalten keine konkrete Implementierung, sondern sind praktisch in allenObjekt orientierten Programmiersprachen umsetzbar

• Patterns zeigen auf, wie Probleme effizient gelost werden konnen

Die nachsten Kapitel beschreiben kurz und bundig die 23 Pattern aus dem Buch”Design

Patterns“ [GHJV95] der Gang of Four.

107

1. Abstract Factory

Das Factory Pattern stellt ein Interface zur Verfugung um Objekte herzustellen. Obwohlnaturlich der gelieferte Typ bekannt ist, bleibt die effektive Klasse, von der das Objektkommt, im Verborgenen. Als weitere Steigerung davon, liefert das Abstract FactoryPattern nicht direkt ein brauchbares Objekt, sondern eine Factory.

Eine haufige Anwendung der Abstract Factory ist das Vorbereiten der Programme furunterschiedliche Look and Feels. Dabei wird uber Parameter der Abstract Factory dergewunschte Look and Feel mitgeteilt und diese liefert im Gegenzug die konkrete Facto-ry. Die gelieferte konkrete Factory stellt die entsprechend aussehenden Steuerelementeher.

Auch bekannt als

Kit

1.1. Nutzen

• Ermoglicht eine ganze Bibliothek von Klassen, wie zum Beispiel Steuerelementefur den Aufbau von Masken, zur Verfugung zu stellen, ohne deren konkrete Imple-mentierung Preis zu geben

• Erlaubt die Abtrennung der konkreten Klassen von ihrer Mutterklasse

• Erlaubt das Verwenden von Objekten, deren Herstellung, Zusammensetzung undAussehen nicht oder noch nicht bekannt ist

1.2. Bezug zu Ergonomie

Mit Hilfe des Abstract Factory Pattern lasst sich das Bedurfnis nach Individualisierbar-keit hervorragend losen. Der Benutzer kann das Aussehen der Programme bei Laufzeitandern und der Programmierer braucht wahrend der Entwicklung nicht gross daraufRucksicht zu nehmen.

109

1. Abstract Factory

Client

AbstractFactory

+ createProduct() : Product

ConcreteFactory

+ createProduct() : Product

ConcreteProduct

Product

produces

«instantiate»

Abbildung 3.1.1.: Abstract Factory Pattern

1.3. Struktur

AbstractFactory Deklariert das Interface der verschiedenen Factories

ConcreteFactory Implementiert eine Factory

AbstractProduct Deklariert das Interface des herzustellenden Produkts

Product Das durch die Factory konkret hergestellte Produkt

Client Verwendet Factory und Produkte uber deren Interfaces

1.4. Verwandte Patterns

Factory Method (S. 137) Das Factory Method Pattern kommt bei der Implementierungder abstrakten Factories zum Einsatz.

Singleton (S. 165) Konkrete Factories werden haufig als Singletons gebaut.

110


Prototype (S. 159) Neben dem Factory Method Pattern, kann auch das Prototype Pat-tern beim Implementieren der abstrakten Factories zum Einsatz kommen.

Facade (S. 133) Das Facade Pattern wird verwendet um mehrere Factories hinter einemeinheitlichen Interface zu verstecken.

111

2. Adapter

Das Adapter Pattern dient dazu ein existierendes Interface einer Klasse mit dem Inter-face eines anderen Typs zu erweitern. In Java gibt es zwei Moglichkeiten dies zu errei-chen: Zum Einen uber Vererbung, was aber auf eine Klassen - Hierarchie einschranktoder zum Anderen durch Implementierung der fur das neue Interface benotigten Metho-den.

Mit Hilfe des Adapter Patterns konnen Klassen direkt miteinander kommunizieren, dievollig verschiedene Interfaces haben.

Auch bekannt als

Wrapper

2.1. Nutzen

• Erlaubt die Zusammenarbeit von unabhangigen Klassen

• Erlaubt gleich zu mehreren Interfaces kompatibel zu sein

• Erhoht die Wiederverwendbarkeit von Klassen


Das Adapter Pattern tritt gehauft im Bereich der GUI - Programmierung auf und betrifftvor allem die Anforderung der Steuerbarkeit.

113

2. Adapter

Client Target

+ request()

Adapter

+ request()

Adaptee

+ specificRequest()

Abbildung 3.2.1.: Adapter Pattern

2.3. Struktur

Target Definiert das vom Client erwartete Interface

Adapter Passt das Interface des Adaptee an das Interface des Targets an

Adaptee Hat irgendein Interface, welches angepasst werden soll

Client Arbeitet mit Objekten, welche dem Target - Interface entsprechen


Proxy (S. 161) Im Gegensatz zum Adapter Pattern wird beim Proxy Pattern ein Ersatz- Objekt mit identischem Interface zur Verfugung gestellt.

Decorator (S. 129) Das Ziel des Decorator Pattern ist die Erweiterung des existierendenInterfaces um neue Funktionen.

Bridge (S. 115) Das Bridge Pattern hat zwar ein ahnliches Konzept, aber das Ziel dieImplementierung vom Interface zu trennen. Wahrend ein Adapter existierende Ob-jekte anpasst.

114

3. Bridge

Das Bridge Pattern dient dazu die Implementierung vom Interface zu trennen. Das Zielist es, Interface und Implementierung getrennt weiter entwickeln zu konnen.

Erreicht wird dies, indem Interface und Implementierung in unterschiedlichen Hierarchi-en gefuhrt werden.

Auch bekannt als

Handler/Body

3.1. Nutzen

• Erlaubt die Trennung von Interface und Implementierung

• Erlaubt die Verwendung derselben Implementierung in unterschiedlichen Klassen

• Verhindert eine permanente Bindung an eine Implementierung

• Sowohl die Implementierung als auch das Interface konnen unabhangig voneinandererweitert werden


Das Bridge Pattern kommt zum Beispiel im Bereich der Erwartungskonformitat undder Individualisierbarkeit zum Einsatz. Lassen sich doch damit Anderungen und Erwei-terungen einfuhren, ohne die bestehenden, schon verteilten Klassen, gleich andern zumussen.

115

3. Bridge

Abstraction

+ operat ion()

RefinedAbstraction

Implementor

+ operationImpl()

ConcreteImplementor

+ operationImpl()

Abbildung 3.3.1.: Bridge Pattern

3.3. Struktur

Abstraction Definert das Interface und halt die Referenz auf ein Objekt des Typs Imple-mentor bereit, welches die gewunschte Funktionalitat, also die Implementierung,zur Verfugung stellt

RefinedAbstraction Demonstriert die von der Implementation unabhangige Weiterent-wicklung des Interfaces

Implementor Definiert das Interface, welches von den konkreten Implementierungen vonAbstraction eingehalten werden muss. Dieses muss nicht unbedingt mit dem In-terface von Abstraction ubereinstimmen. Das Implementor Interface ist meist aufdie eher einfacheren Funktionalitaten beschrankt, wahrend Abstraction die hohereAbstraktionsstufe beschreibt

ConcreteImplementor Eine der Klassen, welche die konkrete Implementierung enthalt


Abstract Factory (S. 109) Das Abstract Factory Pattern kann so umgesetzt werden,dass es im Prinzip ein Bridge Pattern kreiert und konfiguriert.

Adapter (S. 113) Im Unterschied zum Bridge Pattern, wird das Adapter Pattern dazuverwendet, existierende Systeme aneinander anzupassen.

116

4. Builder

Das Builder Pattern hat das Ziel die Konstruktion von komplexen Objekten von derenDarstellung zu trennen. Dabei soll es auch moglich sein uber Parameter unterschiedlicheVersionen des Objekts herzustellen.

4.1. Nutzen

• Ermoglicht die Abkapselung der Konstruktionsdetails von Objekten

• Erlaubt Objekte uber Angabe des Typs und Inhalt zu konstruieren

• Trennt den Konstruktionsprozess von den Teilen, welche das Objekt beschreiben

• Erlaubt die feinere Steuerung des Konstruktionsprozesses


Das Builder Pattern kann dazu verwendet werden die Anforderungen an Individualisier-barkeit und Erwartungskonformitat zu erfullen. Damit lassen sich zum Beispiel Maskenerstellen, welche ihr Aussehen der Aufgabenstellung anpassen.

4.3. Struktur

Builder Definiert das Interface, welches fur die Konstruktion zu verwenden ist

ConcreteBuilder Konstruiert und stellt das Produkt zusammen

Director Lasst ein Produkt uber das Builder Interface herstellen

Product Definiert das Interface des Produkts

117

4. Builder

Director

+ build()

Builder

+ buildPart()+ getResult() : Product

ConcreteBuilder

+ buildPart()+ getResult() : Product

Productbuilds

«instantiate»

Abbildung 3.4.1.: Builder Pattern


Abstract Factory (S. 109) Das Abstract Factory Pattern kann auch dazu verwendet wer-den komplexe Objekte herzustellen. Beim Builder Pattern liegt der Fokus jedochauf der prazisen Steuerung des Konstruktionsprozesses selbst.

Composite (S. 125) Meist wird das Builder Pattern dazu verwendet Composite Kon-strukte herzustellen.

118

5. Chain of Responsibility

Mit dem Chain of Responsibility Pattern lasst sich die Verantwortung fur eine Funk-tionalitat der Reihe nach auf mehrere Klassen verteilen. Wobei die Klassen miteinanderkooperieren ohne davon zu wissen und ohne enge Kopplung. Der Methodenaufruf wirddabei von Klasse zu Klasse weitergereicht, bis sich eine Klasse abschliessend darumkummert.

5.1. Nutzen

• Erlaubt die Verteilung der Verantwortung auf mehrere Objekte

• Erlaubt eine lose Kopplung

• Erhoht die Flexibilitat beim Behandeln von Anfragen


Ein Beispiel fur das Chain of Responsibility Pattern ist ein Hilfe - System welches dieBeantwortung des Aufrufs mehreren Klassen uberlasst. Je nachdem auf welchem Steue-relement der Fokus gerade ist und ob fur das Steuerelement gezielt Hilfe zur Verfugungsteht. Wenn das Steuerelement keine konkrete Hilfestellung anbietet, soll die allgemeineHilfe zur Maske angezeigt werden.

5.3. Struktur

Handler Definiert das Interface fur die Anfrage und implementiert gegebenenfalls dieverkettete Liste der weiteren Handler, welche sich um die Anfrage kummern konnen

ConcreteHandler Behandelt die Anfrage oder gibt sie weiter

Client Tatigt den ersten Aufruf der Kette

119

5. Chain of Responsibility

Client Handler

+ handleRequest()

ConcreteHandler

+ handleRequest()

Weitergabe an Nachfolger

Abbildung 3.5.1.: Chain of Responsibility Pattern

5.4. Verwandtes Pattern

Composite (S. 125) Das Chain of Responsibility Pattern wird oft in Form eines Compo-site Pattern realisiert. Dabei wird die Mutterklasse als nachfolgende Klasse, welchesich um den Aufruf kummern kann, benutzt.

120

6. Command

Das Command Pattern dient dazu Aufrufe von Methoden als Objekte zu kapseln. DieKapselung soll dabei alle fur die Wiederholung benotigten Informationen enthalten.Durch die Kapselung lassen sich so Aufrufe in Listen verwalten, in Queues stellen oderLoggen.

Die gekapselten Aufrufe konnen nun vor dem Ausfuhren verandert oder ausgewechseltwerden. Damit kann das Verhalten des Programms bei Laufzeit geandert werden. Eintypisches Beispiel dafur ist die

”Ruckgangig machen“ Funktion. Was zu tun ist, ist ja

abhangig davon, was vorher gemacht wurde. Die Funktion andert also ihre Auswirkungenwahrend der Laufzeit.

Auch bekannt als

Action, Transaction

6.1. Nutzen

• Erlaubt das Ablegen von Aufrufen in Listen

• Erlaubt Aufrufe zu einem spateren Zeitpunkt auszufuhren

• Entkoppelt den Aufruf von seinem Ausloser


Mit Hilfe des Command Patterns lassen sich Funktionen wie”Ruckgangig machen“ und

”Wiederholen“ hervorragend implementieren. Damit spielt das Pattern bei den Anforde-rungen zur Steuerbarkeit und Erwartungskonformitat eine wichtige Rolle.

121

6. Command

Client

Receiver

+ action()

ConcreteCommand

+ execute()

Command

+ execute()

Invoker

create

«instantiate»

Abbildung 3.6.1.: Command Pattern

6.3. Struktur

Command Deklariert das Interface fur die Kapselung der Aufrufe

ConcreteCommand Implementiert die Kapselung durch Fuhren der Referenz auf denReceiver und Aufrufen der eigentlichen Methoden auf dem Reciever

Client Stellt das konkrete Command Objekt her und konfiguriert es mit der Referenzauf den Reciever

Invoker Last den Command, den eigentlichen Aufruf, ausfuhren durch Aufruf der imInterface Command abgemachten Methode

Receiver Implementiert die ursprungliche, direkte Ausfuhrung des Aufrufs


Composite (S. 125) Das Composite Pattern kann dazu verwendet werden, Comman-ds in eine Hierarchie zu bringen und damit Abstraktionsstufen zu kreieren. Umzum Beispiel komplexe Funktionen zu erstellen, welche mehrere andere einfachereAufrufe ausfuhren.

122


Memento (S. 153) Das Memento Pattern wird normalerweise mit dem Command Pat-tern zusammen verwendet. Wahrend mit dem Memento Pattern Zustande abgelegtwerden konnen, kann das Command Pattern dazu verwendet werden von einemZustand in den nachsten und wieder zuruck zu wechseln.

Prototype (S. 159) Das Prototype Pattern kommt zum Zug wenn es darum geht gekap-selte Aufrufe vor dem Ablegen in eine Liste zu kopieren.

123

7. Composite

Das Ziel des Composite Pattern ist das Konstruieren von komplexen Objekten in Formeiner baumartigen Hierarchie von einfachen Objekten. Diese neuen Objekte sollen so ein-gesetzt werden konnen, dass es keine Rolle spielt ob es zusammengesetzte sind oder nicht.Sowohl das zusammengesetzte, als auch die einzelnen Elemente implementieren dazu das-selbe Interface. Die zusammengesetzten Elemente implementieren noch das zusatzlicheInterface Composite, das neue Operationen auf der Zusammenstellung ermoglicht. DerClient operiert dabei nicht mit den einzelnen konkreten Typen, sondern uber das ge-meinsame Interface.

Auch bekannt als

Wrapper

7.1. Nutzen

• Ermoglicht die Darstellung von Teil - Ganzes Beziehungen in einem Baum

• Ermoglicht das Gruppieren von Komponenten zu grosseren Komponenten, welchewiederum zum Konstruieren von noch grosseren Komponenten gebraucht werdenkonnen


Gerade die Anforderung nach Erwartungskonformitat bedeutet, dass bei ahnlichen Auf-gabenstellungen die gleichen Komponenten zur Losung verwendet werden sollen, dieschon verwendet wurden. Da bietet es sich an das Composite Pattern einzusetzen, umzum Beispiel Elemente einer Maske zu gestalten.

Das Ganze kann soweit getrieben werden, dass eine ganze Sammlung, ein Framework,von Komponenten entsteht. Die Komponenten konnen dann mit ein paar Handgriffe zueiner kompletten Maske zusammengestellt werden.

125

7. Composite

Client Component

+ operat ion()+ add(Component)+ remove(Component)+ getChild(int)

Composite


Leaf


*

Abbildung 3.7.1.: Composite Pattern

7.3. Struktur

Component Deklariert das gemeinsame Interface aller Elemente der Zusammenstellung

Leaf Definiert das Verhalten der Elemente in der Zusammenstellung, welche selber keineweiteren Kinder haben

Composite Definiert das Verhalten der Elemente, welche selber weitere Kinder haben.Fuhrt eine Liste der direkten Kinder. Implementiert die Kind - bezogenen Metho-den

Client Benutzt die Zusammenstellung uber das gemeinsame Interface der Zusammen-stellung


Chain of Responsibility (S. 119) Die Verbindung von Mutter- zu Kindklassen wird gernefur das Erstellen des Chain of Responsibility Pattern verwendet.

Decorator (S. 129) Decorator und Composite Pattern werden auch im Zusammenspielverwendet. In dem Fall haben sie eine gemeinsame Mutterklasse.

126


Flyweight (S. 139) Das Flyweight Pattern kommt zum Einsatz, wenn die Zusammen-stellung eine grosse Menge von sehr kleinen Objekten enthalten soll. Zum Beispieldie Buchstaben eines Textes.

Iterator (S. 147) Das Iterator Pattern wird dazu verwendet die einzelnen Elemente derZusammenstellung zu durchschreiten.

Visitor (S. 175) Das Visitor Pattern wird dazu verwendet, einzelne Operationen nichtin jedem Element der Zusammenstellung zu implementieren sondern in einer se-paraten Klassen zu kapseln.

127

8. Decorator

Das Decorator Pattern dient dazu Klassen um neue Funktionalitat zu erweitern, ohnegleich die Klasse selbst im Sinne der Klassenhierarchie erweitern zu mussen.

Auch bekannt als

Wrapper

8.1. Nutzen

• Ist eine Alternative zur Vererbung beim Erweitern von Klassen

• Erlaubt neue Funktionalitat zu einem Objekt zu erganzen, ohne die bereits vor-handen Verwendung des Objekts zu storen

• Erlaubt Funktionen dynamisch zu erganzen und zu entfernen

• Erlaubt eine hohere Flexibilitat als die Vererbung

• Die Erweiterung erfolgt fur den Code der erweiterten Klasse transparent


Das Decorator Pattern wir im Bezug zu Ergonomie dazu gebraucht um Funktionen jenach Kontext anders darzustellen, hinzu zu fugen oder zu entfernen. In dem Sinn dientes dazu die Anforderungen nach Steuerbarkeit, Erwartungskonformitat und Individuali-sierbarkeit zu erfullen.

129

8. Decorator

Component

+ operat ion()

ConcreteComponent

+ operat ion()

Decorator

+ operat ion()

ConcreteDecoratorA

- addedState

+ operat ion()

ConcreteDecoratorB

+ operat ion()+ addedBehavior()

Abbildung 3.8.1.: Decorator Pattern

130

8.3. Struktur

8.3. Struktur

Component Definiert das Interface des Objekts, welches dynamisch um Funktionalitaterweitert werden soll

ConcreteComponent Definiert ein konkretes Objekt, welches um die Funktionalitat er-weitert werden soll, ohne dabei die Klassendefinition zu andern

Decorator Halt die Referenz zum erweiterten Objekt und definiert dasselbe Interfacewie das zu erweiternde Objekt

ConcreteDecoratorA Beispiel einer Erweiterung des Objekts um einen Status

ConcreteDecoratorB Beispiel einer Erweiterung des Objekts um einen neue Funktiona-litat


Adapter (S. 113) Wahrend das Adapter Pattern eine Klasse an ein anderes Interfaceangleicht, wird das Decorator Pattern dazu verwendet einer Klasse eine neue Funk-tionalitat zu geben.

Composite (S. 125) Das Decorator Pattern konnte als vereinfachtes Composite Pat-tern mit nur einem erweiterten Element angeschaut werden. Im Gegensatz zumComposite erweitert jedoch das Decorator Pattern die Funktionalitat und ist nichtgedacht um Objekte zu einer Sammlung zusammen zu stellen.

Strategy (S. 169) Strategy Pattern und Decorator Pattern sind zwei Alternativen umein Objekt anzupassen. Grob gesehen andert das Strategy Pattern das Innere unddas Decorator Pattern das Aussere der Klasse.

131

9. Facade

Das Ziel des Facade Pattern ist es ein einheitliches Interface fur eine Sammlung von Sub-systemen zur Verfugung zu stellen um deren Verwendung zu vereinfachen.

Haufig wird bei der Implementierung auch gleich versucht das Interface einfacher undschlanker zu gestalten, als die Summe der Interfaces der Subsysteme. Das Facade wirktdann als ubergeordnete, abstrakte Schicht.

9.1. Nutzen

• Erlaubt die Komplexitat eines Systems zu reduzieren

• Entkoppelt Subsysteme, reduziert deren Abhangigkeit untereinander und erhohtso die Wiederverwendbarkeit

• Erlaubt einen einzelnen Eintrittspunkt fur die Subsysteme zu haben

• Vereinfacht das Umsetzen von Security Anforderungen

• Versteckt Implementationsdetails vor den Clients dadurch, dass diese nicht dieeigentlichen Interfaces der Subsysteme zu sehen kriegen, sondern nur das Interfaceder ubergeordneten Schicht


Der Programmierer profitiert vom Facade Pattern, indem er sich auf die Anforderungender Ergonomie konzentrieren kann und sich ihm die verwendeten Subsysteme einfacherdarstellen. Das Facade Pattern kann uberall dort eingesetzt werden, wo es gilt kom-plexe Businesslogik uber Masken zuganglich zu machen. Damit dient das Pattern derSteuerbarkeit und Erwartungskonformitat.

133

9. Facade

Subsystem Klassen

Client Facade

SubsystemA

SubsystemB

SubsystemC

SubsystemD

SubsystemE

Abbildung 3.9.1.: Facade Pattern

134

9.3. Struktur

9.3. Struktur

Client Verwendet das Facade Objekt um die Funktionalitat der Subsysteme zu erreichen

Facade Kennt die verschiedenen Subsysteme und weiss welches Subsystem sich um wel-che Anfrage kummert. Gibt die Anfragen an das entsprechende Subsystem weiter

Subsystem Implementiert die Funktionalitat eines Subsystems. Beantwortet die Anfra-gen des Facade Objekt. Kennt das Facade Objekt nicht. Fuhrt keine Referenz aufdas Facade Objekt


Abstract Factory (S. 109) Das Abstract Factory Pattern kann als Alternative zum Faca-de Pattern verwendet werden. Besonders dann wenn die Subsysteme nicht wirklichunterschiedliche Funktionalitat bieten, sondern eher Varianten davon sind. Zudemwird das Abstract Factory Pattern gegebenenfalls auch innerhalb des Facade Ob-jekts verwendet um Instanzen der Subsysteme herzustellen.

Singleton (S. 165) Normalerweise wird nur ein einziges Facade Objekt benotigt, darumwird dieses oft als Singleton gestaltet.

Mediator (S. 149) Das Facade Pattern hat Ahnlichkeit zum Mediator Pattern, erweitertjedoch nicht die Funktionalitat der Subsysteme.

135

10. Factory Method

Das Factory Method Pattern stellt ein Interface zur Verfugung um Objekte herzustellen.Durch die Implementierung des Interfaces in den Kindklassen, kann die Mutterklassedas Herstellen von Objekten an die Kindklassen delegieren. Weiterhin konnen an dieFactory Methode Parameter ubergeben werden, welche die zu instanzierende Klasse oderVariante beeinflussen.

Das Factory Method Pattern ist das wohl in der Objekt orientierten Programmierungam meisten anzutreffende Pattern. In Swing Programmen wird haufig jedes einzelneSteuerelement uber eine Factory Methode hergestellt. Frameworks verwenden haufigabstrakte Klassen um die zu erstellenden Objekte zu definieren und Referenzen daraufzu halten, geben die Wahl der konkreten Klasse jedoch weiter.

Auch bekannt als

Virtual Constructor

10.1. Nutzen

• Erlaubt die Wahl der zu instanzierenden Klasse an die Kindklasse zu delegieren

• Fordert die Programmierung gegen Interfaces, statt konkreten Klassen

• Erlaubt konkrete Klassen vor der Businesslogik zu verstecken

• Ermoglicht die Parameter gesteuerte Instanzierung


Das Factory Method Pattern kommt in Swing sehr oft vor. Alles was mit Gestaltungvon Graphischen Oberflachen zu tun hat, implementiert fur die Herstellung der Ob-jekte ein Factory Method Pattern. So gesehen spielt das Pattern in der Steuerbarkeit,Erwartungskonformitat und Individualisierbarkeit eine Rolle.

137

10. Factory Method

Product

ConcreteProduct

Creator

# factoryMethod() : Product

ConcreteCreator

# factoryMethod() : Productcreates

«instantiate»

Abbildung 3.10.1.: Factory Method Pattern

10.3. Struktur

Product Definiert das Interface der herzustellenden Objekte

ConcreteProduct Konkrete Implementierung eines herzustellenden Objekts

Creator Deklariert die Factory Methode, welche ein Objekt vom Typ Product zuruckgebenwird. Die Methode kann dabei ausprogrammiert sein und effektiv ein Objektzuruckgeben oder sie ist abstrakt deklariert und es wird erst in der konkretenKlasse festgelegt, was fur ein Objekt hergestellt wird

ConcreteCreator Konkrete Implementierung, kann oder muss sogar, je nach dem ob dieFactory Methode abstrakt deklariert wurde, die Factory Methode uberschreibenund ein konkretes Produkt zuruckgeben


Abstract Factory (S. 109) Das Abstract Factory Pattern wird haufig mittels FactoryMethoden implementiert. Es ist von der Abstraktion her eine Stufe abstrakter alsdas Factory Method Pattern.

Template Method (S. 173) Das Template Method Pattern verwendet bei der Imple-mentierung Aufrufe von Factory Methoden.

138

11. Flyweight

Erlaubt das Verwenden von sehr vielen Elementen als Objekte. Dabei wird aus Performance-und Speicherplatzgrunden nicht wirklich fur jedes ein eigenes Objekt erzeugt. Stattdes-sen wird eine Instanz von aussen konfiguriert, um sie wie ein neues Objekt wirken zulassen.

Ein typisches Beispiel dafur sind die Zellen einer Tabelle. Je nach Tabellengrosse kannes tausende davon haben. Da macht es keinen Sinn fur jede einzelne Zelle effektiv einObjekt herzustellen.

Mit dem Flyweight Pattern ist es nun moglich jede Zelle der Tabelle wie ein eigenesObjekt anzusprechen und zu behandeln, obwohl es sich immer um dieselbe Instanz han-delt.

11.1. Nutzen

• Erlaubt die Anzahl instanzierter Objekte zu reduzieren

• Erlaubt den verwendeten Speicherplatz zu reduzieren und damit die Performancezu verbessern


Der Nutzen fur die Ergonomie kommt vor allem dann zu Tage, wenn”vergessen“ wird,

dieses Pattern anzuwenden. Als Folge gehen Applikationen schlecht mit grossen An-sammlungen von Objekten um. Das fangt an beim grafischen Aufbau von Masken undzieht sich bis uber die Businesslogik. Denn eine Maske, die sich nur sehr schleppenddarstellt oder Berechnungen die ewig dauern, wird nicht als ergonomisch empfunden.Ganz gleich, ob ansonsten alle Ergonomie Standards eingehalten werden. Mindestensdie Forderung nach Steuerbarkeit ist es nicht.

139

11. Flyweight

Client

FlyweightFactory

+ getFlyweight(Key)

Flyweight

+ operation(ExtrinsicState)

ConcreteFlyweight

- intrins icState


UnsharedConcreteFlyweight

- allState


Abbildung 3.11.1.: Flyweight Pattern

11.3. Struktur

Flyweight Deklariert das Interface der Objekte. Besonders die Methode, mit der dieObjekte konfiguriert werden

ConcreteFlyweight Konkrete Implementierung des Flyweight Interfaces. Dies ist dieKlasse von der es sehr viele Instanzen gibt, wenn das Pattern nicht angewendetwird. In der Regel fuhrt sie nur sehr wenig eigene Eigenschaften, da diese ja furalle fiktiven Instanzen dieselben sind

UnsharedConcreteFlyweight Das Flyweight Pattern arbeitet auch mit Instanzen, wel-che nicht mehrfach mit unterschiedlichen Attributen zur Verfugung gestellt wer-den, sondern

”gewohnliche“ Objekte reprasentieren. So zum Beispiele die Objekte

der Klassen Spalte und Zeile einer Tabelle. Das Flyweight Pattern erlaubt diese

”normalen“ Objekte genau gleich zu behandeln wie das Objekt Zelle

FlyweightFactory Die FlyweightFactory liefert dem Client die Objekte aus.

Client Der Client behalt die Referenzen auf die einzelnen Objekte uber einen Schlussel.Dies kann zum Beispiel die Spalte und Zeile einer Tabelle sein. Der Client sprichtdie Objekte uber die FlyweightFactory an

140



Composite (S. 125) Das Composite Pattern kommt beim Erstellen des Flyweight Pat-tern zum Einsatz um hierarchische Strukturen der Elemente abzubilden.

State (S. 167) Das State Pattern bedient sich oft des Flyweight Pattern bei der Erstel-lung der Objekte. Besonders dann, wenn eine grosse Anzahl Objekte entsteht unddiese sich nur in ihrem Zustand voneinander unterscheiden.

Strategy (S. 169) Wie beim State Pattern, wird beim Strategy Pattern oft auf dasFlyweight Pattern zuruckgegriffen um die Anzahl Objekte zu reduzieren.

141

12. Interpreter

Das Interpreter Pattern wird dazu benutzt Programme zu bauen, welche Informationennach Grammatikregeln verarbeiten, sogenannte Parser.

12.1. Nutzen

• Ist das Grundgerust fur jegliche Parser

• Erlaubt einen Ausdruck in einzelne Befehle zu zerlegen

• Erlaubt das Abarbeiten von baumartigen Strukturen


Mit Hilfe des Interpreter Pattern kann dem Benutzer die Moglichkeit geboten werden inTextform Befehle zu erfassen. Oft wird dies als Alternative zu Point and Click Verfahrenverwendet. Damit wird erfahrenen Benutzern eine Moglichkeit zur Verfugung gestellt,umfangreiche Aufgaben mit weniger Aufwand zu erfassen.

12.3. Struktur

AbstractExpression Definiert das gemeinsame Interface der Knoten und Blatter desbinaren Baums, welcher beim Parsen des Ausdrucks entsteht

TerminalExpression Die TerminalExpression ist die kleinste Einheit der Grammatik undkann nicht mehr weiter aufgeteilt werden

NonterminalExpression Die NonTerminalExpression Klasse bildet die Regeln der Gram-matik ab

Context Der Context bildet die Informationen ab, welche fur das gesamten InterpreterPattern gultig sind

Client Verwendet das Interpreter Pattern Konstrukt um einen Ausdruck, welcher der ab-gemachten Grammatik entspricht, auszuwerten. Dabei entsteht ein binarer Baumvon NonTerminalExpression Knoten und TerminalExpression Blatter

143

12. Interpreter

Client

Context

AbstractExpression

+ interpret(Context)

TerminalExpression

+ interpret (Context)

NonTerminalExpression

+ interpret(Context)

*

Abbildung 3.12.1.: Interpreter Pattern

144



Composite (S. 125) Der beim Parsen entstehende binare Baum ist ein typischer Vertre-ter des Composite Pattern.

Flyweight (S. 139) Das Flyweight Pattern kann dazu verwendet werden die Terminal-Expression Instanzen abzubilden.

Iterator (S. 147) Das Iterator Pattern kann dazu verwendet werden den binaren Baumzu durchschreiten.

Visitor (S. 175) Mit dem Visitor Pattern wird die Logik der Knoten im Knoten selbstgehalten.

145

13. Iterator

Das Iterator Pattern wird dazu verwendet Sammlungen von Objekte oder zusammenge-setzte Objekte zu durchschreiten, ohne uber ihre interne Struktur Bescheid zu wissen.Es ist ein bekanntes und viel eingesetztes Pattern.

Gerade die Kapselung des Durchschreitens selbst, erlaubt unterschiedliche Implemen-tierungen des Iterator Patterns zu verwenden. So konnen diese beim Durchschreitenzusatzliche Aufgaben wahrnehmen oder die Sicht auf die durchschrittenen Daten ein-schranken.

Auch bekannt als

Cursor

13.1. Nutzen

• Stellt ein standardisiertes Interface zur Verfugung um Sammlungen zu durchschrei-ten

• Alle Java Klassen der Standard Bibliotheken, welche Sammlungen abbilden, bietenbereits Implementierungen dieses Pattern an

• Erlaubt die Art des Durchschreitens, unabhangig von den durchschrittenen Klas-sen, zu andern

• Kann ebenfalls als Filter fur die Sicht auf die Elemente der Sammlung verwendetwerden


Probleme bei der Benutzerfuhrung im Bereich des Durchschreitens von Listen oder Ar-beitsablaufen lasst sich haufig auf eine ungenugende Implementierung dieses Patternzuruckfuhren.

147

13. Iterator

Aggregate

+ createIterator()Client

Iterator

+ firs t()+ next()+ isDone()+ current Item()

ConcreteAggregate

+ createIterator()

ConcreteIterator

+ first()+ nex t()+ isDone()+ current Item()

creates

«instantiate»

Abbildung 3.13.1.: Iterator Pattern

13.3. Struktur

Iterator Definiert das Interface fur das Durchschreiten

ConcreteIterator Konkrete Implementierung des Interfaces. Diese ist auf die zu durch-schreitenden Klassen zugeschnitten

Aggregate Definiert das Interface um das Iterator Objekt zu beschaffen

ConcreteAggregate Implementiert das Interface, welches ein Iterator Objekt zur Verfugungstellt. Erlaubt damit das Durchschreiten einer Sammlung oder der eigenen, innerenObjekte


Composite (S. 125)Das Iterator Pattern tritt haufig in Composite Pattern Strukturenauf, um diese zu durchschreiten.

Factory Method (S. 137) Das Factory Method Pattern kommt beim Erstellen der Ite-rator Instanz zum Zug.

Memento (S. 153) Implementierungen des Iterator Pattern benutzen das Memento Pat-tern um beim Durchschreiten erreichte Zustande intern abzulegen.

148

14. Mediator

Das Mediator Pattern erlaubt eine losere Kopplung von Objekten durch Kapselung vonDetails und Zugriffen.

Bei grosseren Programmen ist die Businesslogik haufig auf viele Klassen verteilt unddie Wartung und Erweiterung der Programme wird immer schwieriger. Das MediatorPattern entflechtet nun diese Klassen, indem sie nicht mehr uber alle Details der Imple-mentierung voneinander wissen mussen.

14.1. Nutzen

• Erlaubt Systeme, welche aus verschiedenen Objekten bestehen, als ein Einzelneserscheinen zu lassen

• Zentralisiert die Steuerungslogik der beteiligten Objekte

• Kann komplexe Zusammenhange mittels einer ubergeordneten Steuerung verein-fachen

• Halt die Anzahl notiger Vererbungen kleiner

• Vereinfacht Klassen wieder verwendbar zu gestalten


Das Mediator Pattern spielt bei der Erfullung der Anforderungen an die Steuerbarkeitund Erwartungskonformitat eine wichtige Rolle. Gerade bei Programmen, welche mitjeder neuen Version neue Funktionalitaten gespendet kriegen, ist die Umsetzung diesesPattern wichtig.

Lassen sich Programme, nach einem neuen Release nicht mehr fehlerfrei bedienen underwecken sie den Eindruck des Auseinanderfallens, dann ist nicht selten die innere Kom-plexitat, das Zusammenspiel der Klassen einer der Grunde.

149

14. Mediator

Mediator

ConcreteMediator

Colleague

ConcreteColleague

Abbildung 3.14.1.: Mediator Pattern

14.3. Struktur

Mediator Definiert das Interface, uber welches die Colleague Klassen angesprochen wer-den

ConcreteMediator Implementiert und steuert die Zusammenarbeit und Kommunikationvon und zu den Colleague Objekte. Kennt die am System beteiligten ColleagueObjekte

Colleague Definiert das gemeinsame Interface der am System beteiligten Klassen

ConcreteColleague Eines der Objekte des Systems und konkrete Implementierung desColleague Interfaces. Dieses Objekt kommuniziert mit dem Mediator Objekt, stattdirekt mit den anderen Objekten des Systems


Facade (S. 133) Das Facade Pattern hat grosse Ahnlichkeit zum Mediator Pattern,dient es doch auch dazu ein komplexes System vereinfacht darzustellen. Beim Fa-cade Pattern findet die Kommunikation jedoch nur in eine Richtung statt. DieSubsysteme arbeiten ohne Kenntnis des Facade Objekts. Im Mediator findet dieKommunikation dagegen in beiden Richtungen statt und die Subsysteme arbeitenuber das Mediator Objekt zusammen.

Command (S. 121) Das Command Pattern wird haufig fur die Kommunikation zwischenColleague Objekten und Mediator und umgekehrt verwendet.

150


Observer (S. 155) Das Observer Pattern wird oft als Mittel fur die Verlinkung vonColleagues mit Meditator und zur Strukturierung der Kommunikation verwendet.

151

15. Memento

Das Memento Pattern dient dazu den inneren Zustand eines einzelnen Objekts zu kapselnund zu speichern, ohne die innere Struktur zu kennen. Dies kann dazu verwendet werdenum Checkpoints herzustellen. Zustande, zu denen, aus welchem Grund auch immer,wieder zuruck gekehrt werden kann. Ein prominenter Vertreter davon ist die Undo/RedoFunktionalitat, welche in vielen Programmen zu finden ist.

Auch bekannt als

Token

15.1. Nutzen

• Ermoglicht die Implementierung von Undo- und Redo-Funktionalitat

• Erlaubt das Anfertigen von Momentaufnahmen von Objekten, um sie spater aus-zuwerten

• Erlaubt Details zur Implementierung hinter einem vereinfachten Interface zu ver-stecken


Mit dem Memento Pattern lassen sich Undo und Redo - Funktionen sauber implemen-tieren. Damit tragt das Memento Pattern einen wichtigen Beitrag zur Steuerbarkeitbei. Gerade Dialog Folgen mit

”nachster“ und

”zuruck“ Tasten profitieren ebenfalls von

diesem Pattern.

153

15. Memento

Originator

- state

+ setMemento(Memento)+ createMemento()

Memento

- state

+ getState()+ setState()

Caretaker

create

Abbildung 3.15.1.: Memento Pattern

15.3. Struktur

Memento Das Memento Objekt speichert die Momentaufnahme des Originators. Da-bei werden so viele interne Werte des Originator Objekts gespeichert, als notigsind. Halt ein schlankes Interface nach Aussen bereit und versteckt somit die Im-plementierungsdetails des Originator. Das Originator Objekt muss hingegen allevorhandenen Details des Memento Objekts kennen und ansteuern konnen um sei-nen Zustand zu sichern oder einen vorherigen Zustand wieder herzustellen

Originator Erstellt Momentaufnahmen des eigenen internen Zustandes als Memento Ob-jekte. Kann uber die Zufuhrung eines eigenen Memento Objekts in einen fruherenZustand versetzt werden

Caretaker Das Caretaker Objekt verwaltet die verschiedenen Memento Objekte ohneuber ihren internen Aufbau Bescheid zu wissen


Command (S. 121) Das Memento Pattern wird zusammen mit dem Command Patternverwendet um Undo - Funktionalitat anzubieten.

Iterator (S. 147) Mit dem Memento Pattern kann,, wie beim Iterator Pattern, eineMoglichkeit des Durchschreitens angeboten werden, in dem von Zustand zu Zu-stand navigiert wird.

154

16. Observer

Das Observer Pattern dient dazu unterschiedliche Objekte auf demselben Stand zu hal-ten. Dabei werden die uberwachenden Objekte aktiv uber ein abgemachtes Interfaceuber Anderungen verstandigt.

Damit das uberwachte Objekt weiss, welche anderen Objekte uber Anderungen verstandigtwerden sollen, melden sich die uberwachenden Objekte bei diesem an.

Die haufigste Anwendung des Observer Patterns ist die Trennung der Datenschicht vonder Businesslogik und diese wiederum von der Darstellung der Daten. Mit Hilfe desObserver Pattern konnen die Darstellung und die Businesslogik uber einen elegantenWeg uber Anderungen in den Daten verstandigt werden.

Auch bekannt als

Dependents, Publish-Subscribe

16.1. Nutzen

• Verschiedenste Objekte konnen andere Objekte (ublicherweise Daten) uberwachenund werden verstandigt, wenn diese ihre Eigenschaften andern

• Das Aussehen und Verhalten von GUI - Elementen kann damit vom Zustand einesDatenobjekts abhangig gemacht werden

• Mit dem Observer Pattern lassen sich Nachrichten als Broadcast an alle angemel-deten Objekte verteilen

• Erlaubt das konsistent halten von unterschiedlichen Objekten

• Erlaubt eine losere Kopplung von Klassen, indem diese nur uber das ObserverPattern miteinander verbunden werden

155

16. Observer

Subject

+ addObserver(Observer)+ removeObserver(Observer)+ noti fy()

Observer

+ update()

ConcreteObserver

- observerState

+ update()

ConcreteSubject

- subjec tState

+ getState()+ setState()

*

Abbildung 3.16.1.: Observer Pattern


Mit Hilfe des Observer Pattern lassen sich Masken bauen, welche sich wie von selbstaktualisieren. So kann zum Beispiel eine Maske ein Kurvendiagramm von Werten dar-stellen. Wenn nun die Werte auf einer separaten Maske editiert werden, passt sich dieKurve

”automatisch“ den neuen Werten an.

Mit dem Observer Pattern ist es leicht Daten, welche auf unterschiedlichen Maskengleichzeitig angezeigt werden, synchron zu halten.

Da Observer Pattern betrifft damit die Anforderungen an die Steuerbarkeit und dieErwartungskonformitat.

16.3. Struktur

Subject Fuhrt eine Liste der angemeldeten Observer. Stellt ein Interface zur Verfugungum sich als Observer an- und wieder abzumelden

ConcreteSubject Verstandigt die angemeldeten Observer uber Anderungen der internenDaten oder des Zustands

Observer Definiert das Interface fur uberwachende Objekte. Stellt eine Methode zurVerfugung, welche von den uberwachten Objekten zur Verstandigung aufgerufenwird

156


ConcreteObserver Implementiert das Observer Interface und wird uber Anderungendurch die uberwachten Objekten verstandigt. Fuhrt typischer Weise eine Liste deruberwachten Objekte und deren zuletzt gemeldeten Zustande


Mediator (S. 149) Das Observer Pattern ubernimmt durch die Kapselung der Nach-richten und der Ubermittlung uber ein schlankes und einfaches Interface die Rolleeines Mediators.

157

17. Prototype

Das Prototype Pattern dient dazu, den Zeitaufwand fur das Herstellen eines neuen Ob-jekts zu verringern, in dem ein bestehendes Objekt durch Klonen auf Basis eines bereitsvorhandenen Objekts angelegt wird.

Das Pattern ist vor allem dann nutzlich, wenn mehrere kompliziert zu erstellende Objekteangelegt werden sollen und diese sich erstmal nur in wenigen Details unterscheiden. Eintypisches Beispiel ist ein Objekt

”Text“ in einer Textverarbeitung. Beim Erstellen eines

neuen Objekts, wird erstmal ein leeres Textdokument hergestellt. Und dies kann nunuber das Prototyp Pattern fur das zweite und die folgenden Textdokumente sehr schnellund Ressourcen sparend durch Klonen geschehen.

17.1. Nutzen

• Erlaubt Ressourcen schonend mehrere Objekte derselben Klasse anzulegen

• Erlaubt dynamisch auf das Herstellen von Objekten Einfluss zu nehmen

• Erlaubt das Herstellen von Objekten in mehrere, unabhangige Schritte zu unter-teilen. Wobei beim ersten Schritt eine Art Vorlage mit einer Grundkonfigurationerstellt wird


Der Nutzen des Prototype Pattern liegt in der Erfullung der Steuerbarkeit. Besondersdann, wenn Objekte umfangreiche Konfigurationsmoglichkeiten bieten. Dank dem Proto-type Pattern lassen sich

”lebendig“ wirkende Programme bauen, welche nach dem Befehl

”Neues Objekt erstellen“ sofort wieder zur Verfugung stehen.

17.3. Struktur

Prototype Beschreibt das Interface fur Objekte, welche sich selbst klonen konnen

ConcretePrototype Konkrete Implementierung einer Klasse, welche in der Lage ist, sichselbst zu klonen

159

17. Prototype

Client

+ operat ion()

Prototype

+ clone()

ConcretePrototype

+ clone()

Abbildung 3.17.1.: Prototype Pattern

Client Stellt neue Objekte durch Klonen bereits bestehender Objekte her


AbstractFactory (S. 109) Das Abstract Factory Pattern wird gerne mit dem Prototy-pe Pattern zusammen verwendet. Die Kombination erlaubt der Abstract FactoryRessourcen sparend durch Klonen neue Objekte heraus zu geben.

Composite (S. 125) Das Prototype Pattern bedient sich oft des Composite Pattern umzusammengesetzte Objekte herzustellen.

Decorator (S. 129) Das Decorator Pattern profitiert ebenfalls von Objekten, welche inder Lage sind sich selbst zu klonen.

160

18. Proxy

Das Proxy Pattern erlaubt Platzhalter an Stelle von originalen Objekten zu verwenden.Damit kann das aufwendige Erstellen eines komplexen Objekts vermieden werden. Auchkonnen zu Testzwecken, durch die Verwendung des Proxy Patterns, Objekte angelegtwerden, welche ansonsten nicht zur Verfugung stehen wurden. Das Proxy Pattern kommtvor allem dann zum Zug, wenn das Verwenden der originalen Objekte zu viele Nachteilebringt oder aus praktischen Grunden aufgeschoben werden muss.

Ublicherweise stellt das Proxy Objekt dieselben Methoden zur Verfugung wie das ori-ginale Objekt. Erst wenn es notig ist, wird dann vom Proxy ein originales Objekt an-gelegt und die Aufrufe an das Original weitergegeben. Dadurch kann bei der Herstel-lung der Objekte unterschieden werden zwischen

”ist Bestandteil“ und

”wird verwen-

det“.

Auch bekannt als

Surrogate

18.1. Nutzen

• Erlaubt das zeitaufwendige oder speicherintensive Herstellen von Objekten aufzu-schieben

• Ermoglicht sparsame Platzhalter zu verwenden. Zum Beispiel konnte in einemLayout Programm das Proxy fur Bilder nur den Rahmen darstellen und somit dasBerechnen des Textes darum herum erlauben, ohne das Bild effektiv zu laden

• Erlaubt die Zugriffe auf das originale Objekt von Autorisierungen abhangig zumachen, ohne den Code der ursprunglichen Klasse zu verandern

161

18. Proxy

Client Subject

+ request()

RealSubject

+ request()

Proxy

+ request()

Abbildung 3.18.1.: Proxy Pattern


Das Proxy Pattern wird bei Ergonomie Uberlegungen dazu verwendet, Masken leben-diger erscheinen zu lassen und Prozesse durch Weglassen von Details zu beschleuni-gen.

Das Proxy Pattern macht sich besonders beim Fehlen bemerkbar. Geht das Starteneiner Applikation qualend lange, kann es mit grosser Wahrscheinlichkeit durch Einsatzdes Proxy Pattern beschleunigt werden. Denn die Features mussen ja eigentlich erst zurVerfugung stehen, wenn sie der Benutzer brauchen will und nicht schon beim Startendes Programms.

18.3. Struktur

Client Verwendet das Proxy Objekt ohne sich dessen bewusst zu sein

Subject Deklariert das vom Client erwartete Interface

Proxy Stellt die Funktionalitat des originalen Objekts zur Verfugung ohne es effektivzu implementieren. Erstellt ein originales Objekt, sobald es notig ist. Kann auchdazu verwendet werden die Zugriffe auf das originale Objekt zu regeln

RealSubject Die originale Klasse, welche die Funktionalitat effektiv implementiert undvon der nicht sofort Objekte hergestellt werden sollen

162



Adapter (S. 113) Das Adapter Pattern stellt ein unterschiedliches Interface zu einemexistierenden Objekt zur Verfugung um es anzupassen. Im Vergleich dazu stelltdas Proxy Pattern dasselbe Interface zur Verfugung.

Decorator (S. 129) Obwohl Decorator Pattern ahnlich wie Proxy Pattern implemen-tiert werden, haben sie einen anderen Zweck. Wahrend das Decorator Patterndazu verwendet wird Funktionalitat zu erganzen, wird mit dem Proxy Pattern diebestehende Funktionalitat kontrolliert zur Verfugung gestellt.

163

19. Singleton

Mit dem Singleton Pattern kann ein und dasselbe Objekt in der ganzen Applikation zurVerfugung gestellt werden. Zudem kann mit dem Singleton Pattern sichergestellt werden,dass auch wirklich nur ein einziges solches Objekt existiert.

Das Singleton Pattern kommt immer dann zum Einsatz, wenn Objekte von der BusinessLogik her nur einmal existieren durfen oder es sich um Ressourcen handelt, welche es nureinmal gibt. Auch kann das Singleton Pattern dazu verwendet werden, um Zugriffe zukanalisieren. Zum Beispiel um den Zugriff auf eine Datenbank uber ein einziges Objektzu regeln.

19.1. Nutzen

• Stellt sicher, dass es von einer bestimmten Klasse nur ein einziges Objekt erstelltwird

• Erlaubt Funktionen und Attribute eines Objekts in der ganzen Applikation zurVerfugung zu stellen

• Stellt Objekten einen Weg zur Verfugung, um selbstandig zur Referenz auf einbereits existierendes Singleton Objekt zu gelangen


Das Singleton Pattern hilft bei der Erfullung der Anforderungen an die Erwartungskon-formitat.

Indem zum Beispiel die Logik zur Autorisierung als Singleton erstellt wird, stehen dyna-mische Anderungen der Autorisierung, gleich allen Objekten zur Verfugung. Auch wenndiese vor dem Zeitpunkt der Erteilung der Rechte hergestellt worden sind und somitbereits eine Referenz auf die Autorisierungslogik haben. Ohne das Singleton Pattern,ware nach der Anderung ein Neustart der Applikation notig, um die geanderten Rechtefur alle Objekte wirksam werden zu lassen.

165

19. Singleton

Singleton

- instance

- Singleton()+ getInstance()

Abbildung 3.19.1.: Singleton Pattern

19.3. Struktur

Singleton Definiert eine Klasse, von der nur ein einziges Objekt hergestellt werden soll.Ist fur die Herstellung des Objekts und halten der Referenz darauf selber verant-wortlich. Dazu wird der Konstruktor privat deklariert und somit versteckt. Dafurgibt es eine statische Methode um die Referenz auf das einzige Objekt zu holen


AbstractFactory (S. 109) Das Abstract Factory Pattern bedient sich oft des Single-ton Patterns um sicher zu stellen, dass von einer Factory nur eine Instanz exis-tiert. Auch kann eine Abstract Factory dazu verwendet werden immer wiederdasselbe Objekt herauszugeben und somit die Rolle eines Singleton Patterns zuubernehmen.

Prototype (S. 159) Das Prototype Pattern ist genau das Gegensteil des Singleton Pat-terns. Beim Prototype Pattern werden neue Objekte auf Grund eines bestehendenObjekts angelegt. Wahrend beim Singleton Pattern ein bestehendes Objekt alseinziges weiter gegeben wird.

166

20. State

Das State Pattern dient dazu Zustanden eine Form zu geben. Die Zustande werdenzu Objekte. Die Zustande sind typischerweise Hilfsklassen und werden in irgendeinemZusammenhang verwendet. Dadurch, dass die Zustande in Klassen modelliert werden,statt nur einen primitiven Typ zu verwenden, bieten sich viele elegante Moglichkeiten,diese zu verwenden.

Hat nun eine Klasse verschiedene Zustande, kann diese die vom Zustand abhangigeLogik auf die Zustands - Klassen verteilen. Dadurch wird der Code ubersichtlicher undwartbarer. Dazu wird beim Aufruf einer Methode, diese einfach an den aktuellen Zustandzur Ausfuhrung weitergeleitet.

Auch bekannt als

Objects for States

20.1. Nutzen

• Erlaubt verschiedene Zustande in einem Programm zu behandeln und trotzdemdie Hauptlogik sauber und ubersichtlich zu halten

• Erlaubt Zustande eine Logik und mehrere Attribute zu geben, im Gegensatz zurReprasentation als primitiven Typ


Das State Pattern wird bei Ergonomie Schwachstellen selten als primarer Grund er-kannt. Eine fehlende oder fehlerhafte Umsetzung kann sich aber in Inkonsistenzen beider Bedienung auswirken und betrifft somit die Steuerbarkeit und Erwartungskonfor-mitat.

Ein Indiz fur fehlendes State Pattern ist, wenn sich ein Programm bei einem fur denBenutzer offensichtlichen Zustand, einmal so und einmal anders verhalt, je nachdem aufwelchem Weg der Zustand erreicht wurde.

167

20. State

Context

+ request()

State

+ handle()

ConcreteState

+ handle()

Abbildung 3.20.1.: State Pattern

20.3. Struktur

Context Bildet den Zusammenhang der Zustande. Gibt Aufrufe von Methoden, derenResultat vom Zustand abhangig ist, an den aktuellen Zustand weiter. Fuhrt eineListe aller Zustande und den dazu gehorenden Objekte

State Definiert das Interface der Zustande. Alle Zustande, die zum selben Zusammen-hang gehoren, mussen auch dasselbe Interface implementieren, damit sie auswech-selbar sind

ConcreteState Eine konkrete Implementierung eines Zustands. Implementiert die Me-thoden des Interfaces mit einer Logik, die zum Zustand gehort. Bedingt durch dieenge Bindung mit dem Zusammenhang, werden Zustande oft als innere Klassenmodelliert


Flyweight (S. 139) Gibt es eine grosse Anzahl Zustande im Zusammenhang, kann dasFlyweight Pattern dazu verwendet werden, die Anzahl Objekte zu reduzieren.

168

21. Strategy

Das Strategy Pattern dient dazu, einen Algorithmus zu kapseln und so auswechsel-bar zu machen. Dadurch kann das Programm, welches die Algorithmen verwendet,einfacher und sauberer gehalten werden. Auf Grund der Auswechselbarkeit, kann zu-dem das Programm bei Laufzeit einen der Aufgabenstellung angepassten Algorithmusauswahlen.

Auch bekannt als

Policy

21.1. Nutzen

• Erlaubt Algorithmen zu kapseln und den Code einfacher und wartbarer zu halten

• Erlaubt die Art, wie eine bestimmte Aufgabe ausgefuhrt wird, bei Laufzeit zubestimmen und auszuwechseln

• Auf Grund der Kapselung konnen die Algorithmen voneinander unabhangig geandertwerde

• Bietet eine Alternative zur Vererbung


Programme bieten oft verschiedene Arten an, um eine bestimmte Aufgabe zu erle-digen. Zum Beispiel, wie ein Dokument am Bildschirm dargestellt werden soll: AlsDruckvorschau, normal oder als Endlostext. Mit Hilfe des Strategy Pattern konnennun die verschiedenen Optionen auf eine schlanke und elegante Art implementiert wer-den.

Das Strategy Pattern kann aber auch vom Programm fur den Benutzer transparent ver-wendet werden. So kann zum Beispiel ein

”Suchen“ Auftrag auf eine andere Art und

Weise erledigt werden, je nachdem was der Benutzer eingegeben hat. Das Programmuberrascht dann den Benutzer mit scheinbar intelligentem Verhalten.

169

21. Strategy

Context

+ contextInterface()

Strategy

+ algorithmInterface()

ConcretStrategyA


ConcretStrategyB


ConcretStrategyC


Abbildung 3.21.1.: Strategy Pattern

Das Pattern spielt damit der Steuerbarkeit in die Hand.

21.3. Struktur

Context Der Zusammenhang, in dem die verschiedenen Strategien verwendet werden.Fuhrt eine Liste der moglichen Strategien um eine Aufgabe zu losen und wahltdann die konkrete Strategie auf Grund von Benutzerangaben oder Beurteilung derDaten aus

Strategy Beschreibt das Interface der Aufgabenstellung, welche von den verschiedenenStrategien erledigt werden soll. Alle moglichen Strategien zur selben Aufgabenstel-lung, mussen dasselbe Interface implementieren

ConcreteStrategy Konkrete Implementierung einer Strategie, um die im Interface defi-nierte Aufgabe zu losen


State (S. 167) Obwohl dem State Pattern ahnlich, hat das Strategy Pattern einen ande-ren Zweck. Im Gegensatz zum State Pattern, werden die verschiedenen Strategien

170


nicht alle hergestellt und hin und her gewechselt, sondern es wird eine Strategieausgewahlt und diese erledigt die Arbeit.

Decorator (S. 129) Das Decorator Pattern, ist wie das Strategy Pattern, dafur ver-antwortlich ein Programm den Umstanden anzupassen. Das Decorator Patternkummert sich dabei um das Aussehen und das Strategy Pattern um das Verhaltenund die Logik.

Composite (S. 125) Die verschiedenen Strategien werden mittels Composite Pattern zueinem Modul zusammengefasst, welches eine bestimmte Aufgabe auf verschiedeneArten und Weisen erledigen kann.

171

22. Template Method

Das Template Method Pattern erlaubt in einer Klasse, auf abstrakter Ebene, Funktionenzu definieren und die Implementierung den Erweiterungen der Klasse zu uberlassen. Dieserlaubt die Klassen besser innerhalb ihrer Verantwortung zu kapseln und die Logik aufmehrere spezialisierte Klassen zu verteilen.

22.1. Nutzen

• Erlaubt die Trennung der Implementierung von generellen Funktionen von denspezialisierten Formen. Mittels der Vererbung stehen die in der Mutterklasse im-plementierten generellen Funktionen in allen Kindklassen zur Verfugung. Wahrenddie abstrakten Methoden von spezialisierten Kindklassen implementiert werden

• Ergibt durch die Verbringung der generellen Logik in der Mutterklasse, schlankere,ubersichtlichere und wartungsfreundlichere Kindklassen

• Erlaubt Algorithmen stufenweise zu verfeinern


Das Template Pattern ist das Grund Pattern der Objekt orientierten Programmierungund ein wichtiger Bestandteil der Vererbung.

Unzulanglichkeiten, bzw. nicht Einsetzen des Template Pattern fuhren zu Programmenwelche einen veralteten Eindruck machen. Der Grund dafur ist, dass in veralteten Pro-grammen und Programmiersprachen Funktionen immer wieder ausprogrammiert wer-den, statt sie zu vererben.

Solche Programme konnen oft nicht mehr den heutigen Anspruchen an die Benut-zerfuhrung genugen. Haufig verlangen sie vom Benutzer, dass er jede Menge Codes undBedienungen auswendig kennt und schleusen ihn auf starrem Weg von einer Maske zuranderen.

173

22. Template Method

AbstractClass

+ templateMethod()+ primitiveOperation1()+ primitiveOperation2()

ConcreteClass

+ primitiveOperation1()+ primitiveOperation2()

Abbildung 3.22.1.: Template Method Pattern

22.3. Struktur

AbstractClass Definiert auf abstrakter Ebene Methoden, welche von den Kindlassen zuimplementieren sind. Gibt so die Funktionalitat und Struktur vor, ohne bereitsImplementierungsdetails festzulegen

ConcreteClass Implementiert die in der Mutterklasse definierten abstrakten Methoden


Strategy (S. 169) Wie mit dem Strategy Pattern, kann uber das Template MethodePattern die Implementierung von Algorithmen auf unterschiedliche Klassen ver-teilt werden. Das Strategy Pattern erledigt dies uber Delegieren an eine andereKlasse und kann dies auch bei Laufzeit noch andern. Das Template Method Pat-tern beruht, im Gegensatz dazu, auf der Vererbung und kann somit die Strategiezur Laufzeit nicht mehr andern.

174

23. Visitor

Das Visitor Pattern dient dazu Operationen auf allen Objekten, welche sich in einer,meist hierarchischen, Struktur befinden anzuwenden. Das Ziel ist es, Daten und die dar-auf angewendete Operationen, voneinander zu trennen. Die Operationen in einer einzigenKlasse zu kapseln und dies obwohl die Daten von unterschiedlichen Typen abstammen,also grundsatzlich einen unterschiedlichen Aufbau und unterschiedliche Interfaces ha-ben.

Der Nachteil des Visitor Pattern ist die enge Kopplung der Visitor Klassen mit denverschiedenen Klassen der Struktur, welche besucht werden sollen. Die Visitor Klassemuss dabei fur jeden in der Struktur auftretenden Typ eine Methode bereitstellen. Diesewird dann beim Besuchen des Objekts vom besuchten Objekt als Gegenaufruf aufgerufen.Also mussen alle in der Sammlung vorhandenen Objekte auch wissen was ihre im Visitoraufzurufende Methode ist und ihre Eigenschaften und Methoden zuganglich machen,damit das Visitor Objekt seine Aufgabe erledigen kann.

Die Anwendung des Visitor Pattern macht nur dann Sinn, wenn folgende Eigenschaftengegeben sind:

• Die zu erledigende Aufgabe ist einfach

• Die Aufgabe soll auf allen Elementen einer Hierarchie von unterschiedlichen Typenausgefuhrt werden

• Die Auswahl an Typen, welche in der Hierarchie auftauchen kann, andert nie odernur sehr selten

• Es sind unterschiedliche Operationen auf die Struktur anzuwenden

23.1. Nutzen

• Erlaubt Operationen in einer Klasse zusammenzufassen, welche auf unterschiedli-che Klassen angewendet werden konnen

• Erlaubt eine Objekt Struktur zu durchlaufen, um zu Beispiel Informationen ein-zusammeln

175

23. Visitor

• Zusatzlich Operationen konnen, sobald das Pattern fur eine Operation implemen-tiert ist, einfach erganzt werden. Im Gegensatz dazu, kann das Pattern nur mitviel Aufwand auf weitere, zu besuchende Klassen erweitert werden


Das Visitor Pattern spielt in Bezug auf die Erfullung von Anforderungen an die SoftwareErgonomie eine untergeordnete Rolle. Auf Grund der Einschrankungen eignet es sichnicht um auf hohere, abstraktere Ebenen portiert zu werden. Das Risiko, dass durch diebenotigte Offenlegung der Eigenheiten der Klassen und der mangelnden Kapselung, einnur noch schwer wartbarer Monolith entsteht, ist einfach zu hoch.

Sollen auf Masken Operationen bereit gestellt werden, welche der Benutzer auf Struktu-ren (z.B. Dateibaum) anwenden kann, so wird dies eher mit einer Zusammenstellung vonPattern implementiert werden, als mit einem reinen Visitor Pattern.

23.3. Struktur

Visitor Definiert eine Methode, welche beim Durchlaufen der Datenstruktur aufgerufenwird. Typischerweise gibt es zu jeder Klasse der Datenstruktur eine Methode, dieaufgerufen wird, wenn ein Element dieses Typs besucht wird. Im Gegenzug wertetder Visitor das besuchte Element uber dessen Interface aus.

ConcreteVisitor Konkrete Implementierung des Visitor Interfaces. Ublicherweise exis-tiert pro gestellte Aufgabe eine konkrete Klasse. Der ConcreteVisitor sammelt dieResultate der einzelnen Methoden und fugt diese zu einem Resultat zusammen,welches dem Resultat der Durchschreitung der ganzen Struktur entspricht.

Element Definiert das Minimum - Interface welches einen Visitor als Argument entgegennimmt, die accept Methode.

ConcreteElement Implementiert die accept Methode und ist somit in der Lage einenVisitor entgegen zu nehmen. Ruft im Gegenzug, die fur sie vorgesehene Methodeim Visitor auf, abhangig vom eigenen Typ.

ObjectStructure Die Struktur von unterschiedlichen Objekttypen, auf die eine Opera-tion mittels Visitor angewendet werden soll.

176

23.3. Struktur

Client Visitor

+ visitConcreteElement(ConcreteElement)

ConcreteVisitor

+ visitConcreteElement(ConcreteElement)

ObjectStructure Element

+ accept(Visitor)

ConcreteElement

+ accept(Visitor)+ operat ion()

*

Abbildung 3.23.1.: Visitor Pattern

177

23. Visitor


Composite (S. 125) Die im Visitor Pattern zu durchschreitenden Strukturen sind oft inForm eines Composite Pattern aufgebaut.

Interpreter (S. 143) Interpreter Pattern konnen auch mit Hilfe von Visitor Pattern ge-baut werden.

178

A. Glossar

Assistent Programm das mittels mehrerer Dialoge durch die Dateneingabe fuhrt

Button Auch Taste oder Schaltflache. Bezeichnet ein Steuerelement in grafischen Benut-zeroberflachen, das einer Taste nachempfunden ist und zum Auslosen von Funk-tionen verwendet wird.

Controller Bezeichnet die Steuerungsschicht des MVC-Architekturmuster (siehe S. 41)

Dateninkonsistenz Wiederspruchlichkeiten in den Daten, meist Verwendung von nichtoder nicht mehr gultigen Fremdschlusseln in Datenbanken.

Dialog Auch Dialogfenster, werden in verschiedenen Situationen vom Programm einge-blendet um gezielt zu Informieren oder Benutzereingaben zu verlangen.

Ergonomie/Software-Ergonomie Bezeichnet die Arbeit hin zu leicht verstandlicher,gebrauchstauglicher und benutzerfreundlicher Software. Im Mittelpunkt stehenMensch und Arbeitsablaufe.

Fokus Fokus bezeichnet das aktuelle Fenster, bzw. das aktuelle Steuerelement welchesTastatureingaben des Benutzers empfangt

GUI Abkurzung fur Graphical User Interface, bezeichnet grafische Benutzeroberflachen

Internationale Raumstation ISS Die Internationale Raumstation (engl. InternationalSpace Station, kurz ISS) ist eine bemannte Raumstation, die derzeit in internatio-naler Kooperation betrieben und weiter ausgebaut wird.

Intuitiv Bezeichnet Zusammenhange die ohne langes Uberlegen erkannt werden

Kapselung, kapseln Wichtiges Konzept der objektorientierten Programmierung. Ver-folgt das Ziel der Programmierung gegen Schnittstellen. Klassen sollen von derFunktionalitat anderer Klassen wissen, aber nicht wie diese sie implementieren.

Kontext Im Zusammenhang mit einem Arbeitsablauf oder einer Tatigkeit

Lokalisierung Anpassung von Beschriftungen an eine bestimmte Sprache

Maske Anderer, etwas veralteter Begriff fur Bildschirm-Formular. Ruhrt davon her, dassdie Daten je nach Aufgabe

”maskiert“ werden. Also ein fur die Aufgabe nicht

relevanter Teil verdeckt wird und ein anderer Teil der Daten gezeigt wird.

179

A. Glossar

Mentales Modell Reprasentation eines Gegenstandes oder eines Prozesses im Bewusst-sein.

Model Bezeichnet die Datenschicht des MVC-Architekturmuster (siehe S. 41)

MVC Abkurzung fur Model View Controller (Erklarungen siehe S. 41)

Norm Auf nationaler oder internationaler Ebene durch Gremien erstellte Abmachun-gen zu technischen Fragen. Zuerst Empfehlungen, konnen jedoch durch Gesetzeverbindlich gemacht werden

Pattern Bewahrte Losungsansatze fur wiederkehrende Problemstellungen in der Soft-wareentwicklung.

Rahmen Zur Gruppierung und Abtrennung benutztes gestalterisches Element bei gra-phischen Ein-/Ausgabemasken. Oft werden sie mit einem Titel versehen, welcherden Inhalt beschreibt

Registerkarte Auch Tab, ist eine Element der grafischen Benutzeroberflachen welchesdazu dient Informationen analog den Registerkarten in Aktenschranken zu unter-teilen.

Redo-Funktion Bezeichnung fur die Funktion nach einem Ruckgangigmachen (Undo)dieselben Arbeitsschritte ohne Neueingabe nochmals ausfuhren zu lassen.

Schaltflache s. Button

Standard Ubereinkunfte und Verordnungen welche sich in der Praxis eine breite Akzep-tanz verschafft haben.

Steuerelement Oberbegriff fur alle Ein- und Ausgabe Elemente, welche fur die Gestal-tung von grafischen Benutzeroberflachen verwendet werden. Beispiele sind Einga-befelder, Beschriftungen, Buttons, Checkboxen, usw.

Swing Programmierschnittstelle und Grafikbibliothek zum Programmieren von grafi-schen Benutzeroberflachen in Java

Symbolleiste Auch Werkzeugleiste oder Toolbar, horizontale oder vertikale Leiste mitSchaltflachen fur haufig verwendete Funktionen. Ublicherweise an Stelle von Be-schriftungen mit Icons versehen

Tab s. Registerkarte

Toolbar s. Symbolleiste

Tooltipp Ein kleiner Hinweis der erscheint wenn mit dem Mauszeiger eine gewisse Zeitlang ruhig uber einem entsprechenden Steuerelement verblieben wird

UML Abkurzung fur Unified Modeling Language, standardisierte Sprache fur die Mo-dellierung von Objektorientierter Software [Oes09]

180

Undo-Funktion Bezeichnung fur die Funktion eine oder mehrere Eingaben zuruckzunehmen

Usability Oberbegriff fur Brauchbarkeit, Nutzbarkeit und Bedienbarkeit

View Bezeichnet die Prasentationsschicht des MVC-Architekturmuster (siehe S. 41)

181

B. Literaturverzeichnis

[GHJV95] Gamma, Erich ; Helm, Richard ; Johnson, Ralph ; Vlissides, John: De-sign Patterns - Elements of Reusable Object-Oriented Software. 1. Addison-Wesley, 1995. – ISBN 0–201–63361–2

[Oes09] Oestereich, Bernd: Analyse und Design mit UML 2.3. 9. OldenbourgWissenschaftsverlag, 2009. – ISBN 3–486–58855–9

[RF07] Richter, Michael ; Fluckiger, Markus: Usability Engineering kompakt. 1.Elsevier GmbH, 2007. – ISBN 978–3–8274–1837–1

[Rie06] Riebeck, Marcel: Software-Evaluation - Eine Studie zur Erkennung vonNutzungsproblemen mit Hilfe von Logfile-Dateien. 1. VDM Verlag Dr. Muller,2006. – ISBN 3–85660–700–X

183

C. Abbildungsverzeichnis

1.0.1. Panel in der internationalen Raumstation ISS, Quelle: NASA . . . . . . . . 8

1.1.1. Liftsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.1.2. Path Variable einstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2.1. Adresse erfassen fur Saison Abo . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3.1. Computer gesteuerte Werkzeugmaschine . . . . . . . . . . . . . . . . . . . . 18

1.4.1. Bankomat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.5.1. Ruckfrage aus Buchungssystem Hallenstadion Betal . . . . . . . . . . . . . 22

1.6.1. Code Editor Optionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.7.1. Menu mit versteckten Auswahlmoglichkeiten . . . . . . . . . . . . . . . . . 26

1.7.2. Menu zeigt alle Auswahlmoglichkeiten . . . . . . . . . . . . . . . . . . . . . 26

2.1.1. Anwendungsfalle Schwimmbad . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.1.2. Zuteilung der Masken nach”wer machts wann?“ . . . . . . . . . . . . . . . 33

2.1.3. Startbildschirm Schwimmbad Kasse . . . . . . . . . . . . . . . . . . . . . . 34

2.1.4. Benotigte Funktionalitat fur”Saisonabonnement verkaufen“ . . . . . . . . . 35

2.1.5. Benotigte Funktionalitat fur”Adresse andern“ . . . . . . . . . . . . . . . . 35

2.1.6. Einzeleintritt verkaufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.1.7. Saisonabonnement verkaufen . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.1.8. Adresse direkt korrigieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.1.9. Adresse korrigieren wahrend Verkauf Saisonabonnement . . . . . . . . . . . 39

2.1.10. Neuerfassung wahrend Verkauf Saisonabonnement . . . . . . . . . . . . . . 40

2.2.1. MVC Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.2.2. Farben mischen mit MVC - UML Diagramm . . . . . . . . . . . . . . . . . 44

2.2.3. Farben mischen mit MVC - Screenshot . . . . . . . . . . . . . . . . . . . . . 46

2.3.1. 192 Optionen auf 11 Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.3.2. JTabbedPane im Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2.3.3. UML Diagramm zu ErgoSwing03 . . . . . . . . . . . . . . . . . . . . . . . . 51

2.4.1. Fortschrittsanzeige bei Download . . . . . . . . . . . . . . . . . . . . . . . . 53

185

Abbildungsverzeichnis

2.4.2. Fortschrittsanzeige mit funf Schritten . . . . . . . . . . . . . . . . . . . . . 54

2.4.3. UML-Diagramm ProgressDisplay . . . . . . . . . . . . . . . . . . . . . . . . 55

2.5.1. Menus und Icons wie gewohnt . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.5.2. Gewohntes Datei - Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

2.5.3. Ungewohnliche Anordnung der Menus und Icons . . . . . . . . . . . . . . . 59

2.5.4. Ungewohnliche Position fur Programm Beenden . . . . . . . . . . . . . . . . 59

2.6.1. Beispiel fur Beschriftungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.7.1. Primzahlen berechnen mit SwingWorker . . . . . . . . . . . . . . . . . . . . 70

2.8.1. Mit Look and Feel experimentieren . . . . . . . . . . . . . . . . . . . . . . . 73

2.8.2. Schlussel fur Farbeinstellung auswahlen . . . . . . . . . . . . . . . . . . . . 74

2.8.3. JColorChooser in Aktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

2.8.4. Look and Feel wechseln bei laufender Applikation . . . . . . . . . . . . . . . 76

2.9.1. Schweizer Kantone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

2.9.2. Schmale Anzeige der Kantone . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.9.3. Breite Anzeige der Kantone . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.10.1. Information Icon fur einfache Ruckmeldung . . . . . . . . . . . . . . . . . . 84

2.10.2. Frage Icon fur unkritische Frage . . . . . . . . . . . . . . . . . . . . . . . . . 84

2.10.3. Warnung Icon fur kritische Frage . . . . . . . . . . . . . . . . . . . . . . . . 85

2.10.4. Kritischer Fehler Icon fur Programmabsturz . . . . . . . . . . . . . . . . . . 85

2.10.5. Kreditrechner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

2.11.1. UML Diagramm HelpService . . . . . . . . . . . . . . . . . . . . . . . . . . 92

2.11.2. UML Diagramm HelpService - KeyEvents . . . . . . . . . . . . . . . . . . . 93

2.11.3. UML Diagramm - Hilfe suchen . . . . . . . . . . . . . . . . . . . . . . . . . 94

2.12.1. Auswahl der zu druckenden Seiten . . . . . . . . . . . . . . . . . . . . . . . 99

2.12.2. Beispiel Programm mit Tastenkurzel . . . . . . . . . . . . . . . . . . . . . . 100

2.12.3. UML Klassendiagramm JSpinner . . . . . . . . . . . . . . . . . . . . . . . . 103

3.1.1. Abstract Factory Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

3.2.1. Adapter Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

3.3.1. Bridge Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

3.4.1. Builder Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

3.5.1. Chain of Responsibility Pattern . . . . . . . . . . . . . . . . . . . . . . . . . 120

3.6.1. Command Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

186

Abbildungsverzeichnis

3.7.1. Composite Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

3.8.1. Decorator Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

3.9.1. Facade Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

3.10.1. Factory Method Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

3.11.1. Flyweight Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

3.12.1. Interpreter Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

3.13.1. Iterator Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

3.14.1. Mediator Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

3.15.1. Memento Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

3.16.1. Observer Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

3.17.1. Prototype Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

3.18.1. Proxy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

3.19.1. Singleton Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

3.20.1. State Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

3.21.1. Strategy Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

3.22.1. Template Method Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

3.23.1. Visitor Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

187

Index

Abbildungsverzeichnis, 184

Abstract Factory

Design Pattern, 109

UML Diagramm, 110

Action

konfigurieren, 60

Snippet, 61

Action mit SwingWorker, 67

Source Code, 69

Adapter

Design Pattern, 113

UML Diagramm, 114

Adresse erfassen fur Saison Abo, 14

Alternative Navigation, 97

Angemessen, 9

Arbeit unterbrechen und fortsetzen, 17

Assistent

im Glossar, 179

Assistenten, 98

Automatisch reduzierte Menus, 25

Automatisches Vervollstandigen, 98

Bankomat, 20

Benotigtes Wissen, 2

Benutzer geradeaus fuhren, 49

Blick uber Tellerrand

Bankomat, 20

Liftsteuerung, 9

Werkzeugmaschine, 17

Body, 115

Bridge

Design Pattern, 115

UML Diagramm, 116

Buchstruktur, 3

Buchungssystem mit Fragen, 21

Builder

Design Pattern, 117

UML Diagramm, 118

Button

im Glossar, 179

Chain of Responsibility

Design Pattern, 119

UML Diagramm, 120

Code Editor Optionen, 24

Command

Design Pattern, 121

UML Diagramm, 122

ComponentUI, 72

Composite

Design Pattern, 125

UML Diagramm, 126

Controller

im Glossar, 179

Cursor, 147

DateFormatter

Snippet, 86

Datenbank auf Bildschirm, 41

Datenbankzugriffe, 67

Dateninkonsistenz

im Glossar, 179

Decorator

Design Pattern, 129

UML Diagramm, 130

Default Werte, 98

Dependents, 155

Design Pattern, 107

Dialog

im Glossar, 179

189

Index

EingabefelderAbstande, 64beschriften, 63Fluchtlinien, 64Gruppen, 64Nahe zu Beschriftung, 63optimieren, 97Source Code, 99Wahl der Beschriftung, 63

Erfahrung, 19Erfolgversprechend

Adresse erfassen fur Saison Abo, 14Buchungssystem mit Fragen, 21Code Editor Optionen, 24

ErgonomieAngemessen, 9Erwartungskonform, 19Fehlertolerant, 21im Glossar, 179Individualisierbar, 23Lernforderlich, 25Selbstbeschreibend, 13Software-Ergonomie, 7Steuerbar, 17

ErgoSwing02, 43Screenshot, 46UML Diagramm, 44



ErgoSwing05, 60Screenshot, 58, 59

ErgoSwing07, 69Screenshot, 70

ErgoSwing08, 73Screenshot, 73–76

ErgoSwing09, 81Screenshot, 79, 80

ErgoSwing10, 87Screenshot, 88

ErgoSwing11, 91

UML Diagramm, 92–94ErgoSwing12, 99

Screenshot, 100Erwartungskonform, 19Event Dispatching Thread, 67, 68

F1 Taste, 89Facade

Design Pattern, 133UML Diagramm, 134

Fachkenntnisse, 19Factory Method


Farben mischen mit MVC, 43Fehler anzeigen

Icons, 83Register, 47Vorschlage, 49

Fehlermeldungen, 83Source Code, 87

Fehlertolerant, 21Fenster und Dialoge gestalten, 29Filezugriffe, 67Flexible Fenstergrossen, 79

Source Code, 81Fluchtlinien, 64Flyweight


Fokusim Glossar, 179

Fortschrittsanzeige, 53ProgressDisplay, 55Source Code, 55

Frage Icon, 84

Glossar, 179GUI

im Glossar, 179

Handler, 115HelpService, 91, 92

Snippet, 95Hilfe, 89

190

Index

Aufrufen, 89Handbucher, 90Hilfeseiten, 90Implementierung, 90Mapping, 90Source Code, 91Tooltipp, 90

HTML als Text, 65

Individualisierbar, 23Information Icon, 83InputVerifier, 85

RangeInputVerifier, 87Internationale Raumstation ISS

im Glossar, 179Interpreter


Intuitivim Glossar, 179

ISO 9241, 7ISS, 7Iterator


JComponent, 72, 85JFormattedTextField, 85

Snippet, 86JLabel, 65

Mehrzeiliger Text, 65JSpinner, 101

DateEditor, 101ListEditor, 102NumberEditor, 102Snippet, 100SpinnerDateModel, 101SpinnerListModel, 101SpinnerModel, 102SpinnerNumberModel, 101UML Diagramm, 103

JTabbedPane, 55

Kapselungim Glossar, 179

KeyboardFocusManager, 91, 92

KeyEventDispatcher, 92

Kit, 109

Klonen, 159

Kontext

im Glossar, 179

Kontextsensitive - Hilfe, 89

Source Code, 91

Kopplung

Chain of Responsibility Pattern, 119

Facade Pattern, 133

Mediator Pattern, 149

Kritischer Fehler Icon, 84

Kultureller Hintergrund, 19

LaF (Look and Feel), 71

Lernforderlich, 25

Liftsteuerung, 9

Literaturverzeichnis, 183

Lokalisierung

im Glossar, 179

Look and Feel, 71

Begriff, 71

Eigenschaften abfragen, 72

Eigenschaften setzen, 72

Motivation, 71

Schlussel-Wert Paare, 72

Snippet, 73, 75, 77

Source Code, 73

Maske

im Glossar, 179

Masken

Anzahl bestimmen, 29

Funktionen, 34

Mehrfach vorh. Funktionen, 36

Weniger ist mehr, 29

Wer und Wann?, 31

MaskFormatter

Snippet, 86

Mediator

Design Pattern, 149

UML Diagramm, 150

Memento

191

Index


Menus und Icons anordnen, 57Source Code, 60

Mentales Modellim Glossar, 180

Minimalistische Steuerung, 9Model, 180MVC

Controller, 43im Glossar, 180Model, 42Model View Controller, 41Source Code, 43UML Diagramm, 42View, 42

Nahe schafft Zusammenhang, 63Norm

im Glossar, 180NumberFormatter

Snippet, 86

Objects for States, 167Observable, 44, 51Observer, 44, 51


Parent, 94Parser, 99

Interpreter Pattern, 143Path einstellen, 10Pattern

im Glossar, 180Policy, 169Prototype


ProxyDesign Pattern, 161UML Diagramm, 162

Publish-Subscribe, 155

Rahmen

im Glossar, 180Raumstation, 7Redo, 17, 25

Command Pattern, 121im Glossar, 180Memento Pattern, 153

Registerkarteim Glossar, 180

Registernavigation, 47Source Code, 50

Schaltflacheim Glossar, 180

Schwimmbad Kasse, 31Selbstbeschreibend, 13Singleton


Software-Ergonomie, 7im Glossar, 179

Source CodeAction mit SwingWorker, 69Farben mischen mit MVC, 43Flexible Fenstergrossen, 81Fortschrittsanzeige, 55Hilfe, 91InputVerifier, 87Look and Feel, 73Menus und Icons, 60Optimierte Eingabefelder, 99Registernavigation, 50

Standardim Glossar, 180

StateDesign Pattern, 167UML Diagramm, 168

Steuerbar, 17Steuerelement

im Glossar, 180Strategy


Surrogate, 161Swing

192

Index

im Glossar, 180SwingWorker, 67, 68Symbole im Buch, 4Symbolleiste

im Glossar, 180Synchrone Menus und Toolbars, 60Systemvariable Path einstellen, 10

Tabim Glossar, 180

Tabulator, 97Tastenkurzel, 98Template Method


TestenProxy Pattern, 161

Thread, 67Konkurrierende Zugriffe, 68Thread-Sicherheit, 68

Token, 153Toolbar

im Glossar, 180ToolTipp, 90Tooltipp

im Glossar, 180Transaction, 121

UIManager, 72UML

im Glossar, 180Undo, 17, 25

Command Pattern, 121im Glossar, 181Memento Pattern, 153

UngunstigAutomatisch reduzierte Menus, 25Systemvariable Path einstellen, 10

UsabilityEngineering, 7im Glossar, 181Labor, 7

Viele Optionen, 47View

im Glossar, 181Virtual Constructor, 137Visitor


Vorwort, i

Warnung Icon, 84Wrapper, 113, 125, 129

Zeitaufwendige Zugriffe, 67Zielpublikum, 2

193

Documents

Master Thesis Von Swing zu Ergonomie - static.sws.bfh.chstatic.sws.bfh.ch/download/MAS-07-02-18-doc.pdf · Unterm¨uli 6 CH-6300 Zug ... 2.2. MVC - Model View ... saubere, dynamische,