Upload
vuongliem
View
216
Download
0
Embed Size (px)
Citation preview
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
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.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
2.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
2.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3. Bridge 1153.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4. Builder 1174.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5. Chain of Responsibility 1195.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.4. Verwandtes Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6. Command 1216.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
14.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
15.Memento 15315.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
15.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
15.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
15.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
16.Observer 15516.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
16.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
16.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
16.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
17.Prototype 15917.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
17.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
17.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
17.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
18.Proxy 16118.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
18.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
19.Singleton 16519.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
19.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
19.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
19.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
20.State 16720.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
20.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
20.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
20.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
21.Strategy 16921.1. Nutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
21.2. Bezug zu Ergonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
21.3. Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
21.4. Verwandte Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. 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
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
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
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
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
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
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
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
1. Fenster und Dialoge gestalten
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
1. Fenster und Dialoge gestalten
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
Saisonabonnement verkaufen
Adresse korrigeren
Abbildung 2.1.2.: Zuteilung der Masken nach”wer machts wann?“
33
1. Fenster und Dialoge gestalten
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
Saisonabonnement verkaufen
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
1. Fenster und Dialoge gestalten
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
1. Fenster und Dialoge gestalten
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
1.6. Was kommt mehrmals vor?
Abbildung 2.1.9.: Adresse korrigieren wahrend Verkauf Saisonabonnement
39
1. Fenster und Dialoge gestalten
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
2. MVC - Model View Controller
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
2. MVC - Model View Controller
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
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
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
3. Registernavigation
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.
ergoSwing03.ErgoSwing03
• 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
3. Registernavigation
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
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
4. Fortschrittsanzeige
ergoSwing04.ErgoSwing04
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
5. Menus und Icons anordnen
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. Menus und Icons anordnen
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
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
7. Action mit SwingWorker
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
7. Action mit SwingWorker
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.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));
JFormattedTextField textField = new JFormattedTextField(
df);
10.6. Snippet: NumberFormatter
// Eingeben im lokalen Wahrungsformat
NumberFormatter nf = new NumberFormatter(NumberFormat
.getCurrencyInstance());
JFormattedTextField textField = new JFormattedTextField(
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
• Decorator Pattern (S. 129)
• Strategy Pattern (S. 169)
87
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
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
11.5. HelpService - ein einfaches Hilfe-System: ErgoSwing11
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)
• Strategy Pattern (S. 169)
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
12. Eingabefelder optimieren
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
12. Eingabefelder optimieren
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
12. Eingabefelder optimieren
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
• Decorator Pattern (S. 129)
• Strategy Pattern (S. 169)
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
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
1.4. Verwandte Patterns
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
2.2. Bezug zu Ergonomie
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
2.4. Verwandte Patterns
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
3.2. Bezug zu Ergonomie
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
3.4. Verwandte Patterns
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
4.2. Bezug zu Ergonomie
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
4.4. Verwandte Patterns
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
5.2. Bezug zu Ergonomie
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
6.2. Bezug zu Ergonomie
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
6.4. Verwandte Patterns
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
6.4. Verwandte Patterns
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
7.2. Bezug zu Ergonomie
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
+ operat ion()+ add(Component)+ remove(Component)+ getChild(int)
Leaf
+ operat ion()+ add(Component)+ remove(Component)+ getChild(int)
*
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
7.4. Verwandte Patterns
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
7.4. Verwandte Patterns
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
8.2. Bezug zu Ergonomie
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
8.4. Verwandte Patterns
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
9.2. Bezug zu Ergonomie
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
9.4. Verwandte Patterns
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
10.2. Bezug zu Ergonomie
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
10.4. Verwandte Patterns
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
11.2. Bezug zu Ergonomie
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
+ operation(ExtrinsicState)
UnsharedConcreteFlyweight
- allState
+ operation(ExtrinsicState)
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
11.4. Verwandte Patterns
11.4. Verwandte Patterns
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
12.2. Bezug zu Ergonomie
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
12.4. Verwandte Patterns
12.4. Verwandte Patterns
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
13.2. Bezug zu Ergonomie
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
13.4. Verwandte Patterns
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
14.2. Bezug zu Ergonomie
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
14.4. Verwandte Patterns
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
14.4. Verwandte Patterns
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
15.2. Bezug zu Ergonomie
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
15.4. Verwandte Patterns
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
16.2. Bezug zu Ergonomie
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
16.4. Verwandte Patterns
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
16.4. Verwandte Patterns
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
17.2. Bezug zu Ergonomie
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
17.4. Verwandte Patterns
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
18.2. Bezug zu Ergonomie
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
18.4. Verwandte Patterns
18.4. Verwandte Patterns
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
19.2. Bezug zu Ergonomie
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
19.4. Verwandte Patterns
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
20.2. Bezug zu Ergonomie
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
20.4. Verwandte Patterns
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
21.2. Bezug zu Ergonomie
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
+ algorithmInterface()
ConcretStrategyB
+ algorithmInterface()
ConcretStrategyC
+ algorithmInterface()
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
21.4. Verwandte Patterns
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
21.4. Verwandte Patterns
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
22.2. Bezug zu Ergonomie
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
22.4. Verwandte Patterns
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
23.2. Bezug zu Ergonomie
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
23.4. Verwandte Patterns
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
ErgoSwing03, 50Screenshot, 50UML Diagramm, 51
ErgoSwing04, 55Screenshot, 54UML Diagramm, 55
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
Design Pattern, 137UML Diagramm, 138
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
Design Pattern, 139UML Diagramm, 140
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
Design Pattern, 143UML Diagramm, 144
Intuitivim Glossar, 179
ISO 9241, 7ISS, 7Iterator
Design Pattern, 147UML Diagramm, 148
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
Design Pattern, 153UML Diagramm, 154
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
Design Pattern, 155UML Diagramm, 156
Parent, 94Parser, 99
Interpreter Pattern, 143Path einstellen, 10Pattern
im Glossar, 180Policy, 169Prototype
Design Pattern, 159UML Diagramm, 160
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
Design Pattern, 165UML Diagramm, 166
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
Design Pattern, 169UML Diagramm, 170
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
Design Pattern, 173UML Diagramm, 174
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
Design Pattern, 175UML Diagramm, 177
Vorwort, i
Warnung Icon, 84Wrapper, 113, 125, 129
Zeitaufwendige Zugriffe, 67Zielpublikum, 2
193