Software Engineering

Vorlesung im Wintersemester 2006/2007

Prof. Dr. Snelting
Lehrstuhl Softwaresysteme
Copyright c _ 19982002 Universit at Passau
Lehrstuhl f ur Software-Systeme
Gregor Snelting, Andreas Zeller, Jens Krinke
Copyright c _ 2001, 2002 Universit at des Saarlandes
Lehrstuhl f ur Softwaretechnik
Andreas Zeller
Inhaltsverzeichnis
1 Was ist Software Engineering? 5
2 Einige bekannte Software-Katastrophen 6
2.1 Ein schlimmes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Drei argerliche Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Drei lustige Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Der Software-Lebenszyklus 9
3.1 Code-and-Fix-Zyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Prozemodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Wasserfallmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Evolution ares Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5 Spiralmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.6 Transformationsmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 Extreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Software-Qualit atsmerkmale 27
4.1 Korrektheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Zuverl assigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Robustheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.4 Efzienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5 Benutzerfreundlichkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.6 Wartbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.7 Wiederverwendbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8 Portierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.9 Kompatibilit at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.10 Produktivit at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.11 Vertrauensw urdigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.12 Qualit atsmerkmale f ur bestimmte Anwendungen . . . . . . . . . . . . . . . 39
5 Grundprinzipien des Software Engineering 41
5.1 Strenge und Formalit at . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Separation der Interessen (

Teile und Herrsche) . . . . . . . . . . . . . . . 43

i
5.3 Spezialfall: Modularit at . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.4 Abstraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.5 Spezialfall: Allgemeinheit . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.6 Evolutionsf ahigkeit (

Antizipation des Wandels) . . . . . . . . . . . . . . 47

5.7 Spezialfall: Inkrementalit at . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.8 Grundprinzipien und Qualit atsmerkmale . . . . . . . . . . . . . . . . . . . 49
6 Pr ufung der Durchf uhrbarkeit 50
6.1 Die Durchf uhrbarkeitsstudie . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Das Lastenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.3 Projektkalkulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.4 Projektplanung und Organisation . . . . . . . . . . . . . . . . . . . . . . . 59
6.5 Checkliste: Durchf uhrbarkeitsstudie . . . . . . . . . . . . . . . . . . . . 63
6.6 Checkliste: Allgemeine Anforderungen an Dokumente . . . . . . . . . . 64
7 Software-Denition: Pichtenheft 73
7.1 Die Produkt-Denition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.2 Das Pichtenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.3 Basiskonzepte zur Produkt-Modellierung . . . . . . . . . . . . . . . . . . . 79
7.4 Funktionale Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5 Datenorientierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.6 Zustandsorientierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . 88
7.7 Regelbasierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.8 Objektorientierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . 98
7.9 Szenariobasierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . 99
7.10 Checkliste: Pichtenheft . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8 Gestaltung von Benutzer-Handb uchern 102
8.1 Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.2 Benutzer-Kategorien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.3 Handbuchtypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.4 Aufbau eines Benutzer-Handbuchs . . . . . . . . . . . . . . . . . . . . . . 105
8.5 Hilfesysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.6 Checkliste: Benutzer-Handbuch . . . . . . . . . . . . . . . . . . . . . . . 110
9 Entwurf von Benutzungsschnittstellen 111
9.1 Konsistenz und Kompetenz . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.2 Kompetenzf ordernde Dialoge . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.3 Flexibilit at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.4 Efzienz und Angemessenheit . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.5 Benutzerfreundliche Web-Seiten . . . . . . . . . . . . . . . . . . . . . . . 130
9.6 Benutzerfreundlichkeit pr ufen . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.7 Checkliste: Benutzungsober ache . . . . . . . . . . . . . . . . . . . . . 133
ii
10 Konzepte des Software-Entwurfs 134
10.1 Grundprinzipien der Zerlegung . . . . . . . . . . . . . . . . . . . . . . . . 135
10.2 Chaos (1950) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.3 Parametrisierte Funktionen (1960) . . . . . . . . . . . . . . . . . . . . . . 139
10.4 Bibliotheken (1960) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.5 Module (1970) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.6 Abstraktes Datenobjekt (1970) . . . . . . . . . . . . . . . . . . . . . . . . 145
10.7 Abstrakte Datentypen (1980) . . . . . . . . . . . . . . . . . . . . . . . . . 154
10.8 Generische Datenobjekte und Datentypen (1985) . . . . . . . . . . . . . . . 159
10.9 Objekte und Klassen (1990) . . . . . . . . . . . . . . . . . . . . . . . . . . 162
10.10 Subjekte und Aspekte (2000) . . . . . . . . . . . . . . . . . . . . . . . . . 178
11 Objektorientierter Entwurf 179
11.1 Objektorientierte Modellierung . . . . . . . . . . . . . . . . . . . . . . . . 179
11.2 Objekt-Modell: Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . 180
11.3 Objekt-Modell: Assoziationen . . . . . . . . . . . . . . . . . . . . . . . . . 189
11.4 Formale Zusicherungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
11.5 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
11.6 Kommunikationsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . 206
11.7 Zustandsdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
11.8 Fallstudie: Tabellenkalkulation . . . . . . . . . . . . . . . . . . . . . . . . 208
11.9 Finden von Klassen und Methoden . . . . . . . . . . . . . . . . . . . . . . 211
11.10 Fallstudie: Geldautomat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
11.11 Vom Modell zum Programm . . . . . . . . . . . . . . . . . . . . . . . . . 224
11.12 Checkliste: Grobentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
12 Entwurfsmuster 226
12.1 Muster in der Architektur: Window Place . . . . . . . . . . . . . . . . . . . 227
12.2 Die Elemente eines Musters . . . . . . . . . . . . . . . . . . . . . . . . . . 228
12.3 Fallstudie: Die Textverarbeitung Lexi . . . . . . . . . . . . . . . . . . . . . 229
12.4 Struktur darstellen das Composite-Muster . . . . . . . . . . . . . . . . . . 231
12.5 Algorithmen einkapseln das Strategy-Muster . . . . . . . . . . . . . . . . 235
12.6 Mehrfache Variation das Bridge-Muster . . . . . . . . . . . . . . . . . . . 238
12.7 Benutzer-Aktionen das Command-Muster . . . . . . . . . . . . . . . . . 243
12.8 One-To-Many Beziehungen das Observer-Muster . . . . . . . . . . . . . 249
12.9 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
13 Software-Architektur 255
13.1 Interaktive Systeme: Model-View-Controller . . . . . . . . . . . . . . . . . 256
13.2 Schichten und Abstraktionen: Layers . . . . . . . . . . . . . . . . . . . . . 267
13.3 Datenstrom verarbeiten: Pipes and Filters . . . . . . . . . . . . . . . . . . . 271
13.4 Vermitteln von Ressourcen: Broker . . . . . . . . . . . . . . . . . . . . . . 277
13.5 Anti-Muster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
iii
14 Model-Driven Architecture 288
14.1 MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
14.2 Transformationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
14.3 Standards und Metamodelle . . . . . . . . . . . . . . . . . . . . . . . . . . 292
14.4 Ans atze zur Modelltransformation . . . . . . . . . . . . . . . . . . . . . . 294
14.5 Beispiel: Rosas Breakfast Service
1
. . . . . . . . . . . . . . . . . . . . . . 297
14.6 MDA: Vorteile und Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . 304
15 Refactoring 305
15.1 Refactoring im

Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
15.2 Beispiel: Der Videoverleih . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
15.3 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
15.4 Methoden aufspalten (

Extract Method) . . . . . . . . . . . . . . . . . . . 309

15.5 Bewegen von Methoden (

Move Method) . . . . . . . . . . . . . . . . . . 311

15.6 Abfrage-Methoden einf uhren (

Replace Temp with Query) . . . . . . . . . 314

15.7 Weiteres Verschieben von Methoden . . . . . . . . . . . . . . . . . . . . . 318
15.8 Fallunterscheidungen durch Polymorphie ersetzen . . . . . . . . . . . . . . 320
15.9 Ein Refactoring-Katalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
15.10 Refactoring bestehenden Codes . . . . . . . . . . . . . . . . . . . . . . . . 328
16 Spezikation 329
16.1 Informale Spezikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
16.2 Exemplarische Spezikation mit Testf allen . . . . . . . . . . . . . . . . . . 332
16.3 Spezikation mit Vor- und Nachbedingungen . . . . . . . . . . . . . . . . . 340
16.4 Spezikation von Klassen und Objekten . . . . . . . . . . . . . . . . . . . 344
16.5 Modellorientierte Spezikation . . . . . . . . . . . . . . . . . . . . . . . . 354
16.6 Algebraische Spezikation . . . . . . . . . . . . . . . . . . . . . . . . . . 370
16.7 Spezikation mit Pr adikaten und Regeln . . . . . . . . . . . . . . . . . . . 384
16.8 Checkliste: Feinentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
17 Qualit atssicherung 391
17.1 Grundbegriffe der Qualit atssicherung . . . . . . . . . . . . . . . . . . . . . 392
17.2 Programminspektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
17.3 Pair Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
17.4 Testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
17.5 Testverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
17.6 Cleanroom Software Development . . . . . . . . . . . . . . . . . . . . . . 426
17.7 Komplexit atsmae (Software-Metriken) . . . . . . . . . . . . . . . . . . . 427
17.8 Verbesserung der Prozequalit at . . . . . . . . . . . . . . . . . . . . . . . . 430
17.9 Checkliste: Implementierung und Validierung . . . . . . . . . . . . . . . 440
18 Arbeiten im Team 442
1
Jos Warmer und Anneke Kleppe, MDA explained, Addison-Wesley, 2005, Kap.4-6
iv
18.1 Kongurationsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . 443
18.2 Management von Softwareentwicklung . . . . . . . . . . . . . . . . . . . . 448
A Programmverstehen 471
A.1

Ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
A.2 Dynamische Verfahren des Programmverstehens . . . . . . . . . . . . . . . 473
A.3 Statische Verfahren des Programmverstehens . . . . . . . . . . . . . . . . . 492
A.4 Wann mu ein System saniert werden? . . . . . . . . . . . . . . . . . . . . 496
B Software-Werkzeuge 497
B.1 Programmkonstruktion mit MAKE . . . . . . . . . . . . . . . . . . . . . . 497
B.2 Regressionstests mit DEJAGNU . . . . . . . . . . . . . . . . . . . . . . . . 500
B.3 Fehlersuche mit DDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
B.4 Revisionskontrolle mit RCS . . . . . . . . . . . . . . . . . . . . . . . . . . 504
B.5 Software-Konguration mit Autoconf . . . . . . . . . . . . . . . . . . . . . 507
B.6 Benutzerober achen erstellen mit Tcl/Tk . . . . . . . . . . . . . . . . . . . 510
B.7 Scanner generieren mit LEX . . . . . . . . . . . . . . . . . . . . . . . . . 512
B.8 Parser generieren mit YACC . . . . . . . . . . . . . . . . . . . . . . . . . . 514
B.9 Benutzer freundlich gr uen mit HELLO . . . . . . . . . . . . . . . . . . . 516
v
Zur Vorlesung
Die Vorlesung

Software Engineering
zeigt Ihnen, wie Sie systematisch groe Software-Systeme im Team erstellen
gibt eine

Ubersicht uber das Gebiet des Software Engineering
ist Voraussetzung f ur das Software-Engineering-Praktikum
Klausur
Bachelor-, Lehramts- und Nachqualizierungs-Studenten m ussen durch eine Klausur am Ende
des Semesters einen Schein erwerben.
Termin
im Februar 2007
Anmeldung ist erforderlich.
Zugelassene Hilfsmittel: SE-Skript.
1
Software-Engineering-Praktikum
Ein Markenzeichen der Passauer Informatik!
Im Software-Engineering-Praktikum (SEP)
entwickeln Sie in 6er-Teams ein Software-Produkt
spielen Sie alle Phasen der Software-Entwicklung durch (Anforderungen, Entwurf, Imple-
mentierung, Test)
setzen Sie moderne Werkzeuge ein (Eclipse, Together, JUnit, SVN, ...)
Ziel
Entwicklung eines Systems im Team objektorientiert durch alle Phasen
Aufgaben
Internet-Tauschb orse, Navigationssystem, Handy-Programmierung...
Umfang
ca. 100 Klassen, ca. 10000 LOC Java-Code
Voraussetzungen
ndet im 5. Semester statt
Details + Anmeldung in einer Auftaktveranstaltung am Ende des 4. Semesters
2
Literatur
Grundlegend
Balzert: Lehrbuch der Software-Technik, Band 1 Software-Entwicklung. 2. Auage, Elsevier-
Verlag, 2001
Sommerville: Software Engineering. 7. Auage, Addison-Wesley, 2004.
Ghezzi, Jazayeri, Mandrioli: Fundamentals of Software Engineering. 2, Auage, Pearson
Education (Addison Wesley), 2002.
Gamma, Helm et.al: Design Patterns. Addison-Wesley, 1995.
Erg anzend
Balzert: Lehrbuch der Software-Technik, Band 2 Software-Management. Spektrum Aka-
demischer Verlag, 1997.
Beck: Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.
Fowler: Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999.
Industrielle Praxis
Humphrey: Managing Technical People. Addison-Wesley, 1997.
E. Yourdon: Decline & Fall of the American Programmer, Yourdon Press, 1992
Klassiker
G. M. Weinberg: The Psychology of Computer Programming, Van Nostrand, 1971
F. P. Brooks: The Mythical Man Month, Addison-Wesley, 1979.
3
Eine Auswahl der B ucher steht im Semesterapparat und in der Lehrbuchsammlung bereit.
4
Kapitel 1
Was ist Software Engineering?
Software Engineering ist
Multi-Personen-Konstruktion von Multi-Versionen-Software
(Parnas)
Software Engineering bietet
Management Theorie
Organisation Methoden
Werkzeuge Techniken
zur Konstruktion groer Programmsysteme.
Industrielle Softwareprojekte im Umfang von 500 Personenjahren sind keine Seltenheit!
Ziel: Einhalten von Qualit atsstandards
Vorbild: klassische Ingenieurdisziplinen wie Maschinenbau
Problem: Software ist unstetig:
Fehlt an einer Br ucke eine Schraube, so st urzt sie noch nicht ein
Stimmt in einem Programm 1 Bit nicht, kann das schon die Katastrophe bedeuten
Der Stand der Technik ist nicht der, dass Software ingenieurm aig entwickelt wird! (ob-
wohl es Programme gibt, die trotzdem funktionieren. . . )
5
Kapitel 2
Einige bekannte Software-Katastrophen
2.1 Ein schlimmes Beispiel
R ontgenger at verstrahlt 6 Menschen 3 Tote (1987)
Therac-25: medizinisches Bestrahlungsger at (R ontgen- und Elektronenstrahlen)
Nachfolger von Therac-6 und Therac-20
Therac-6 und Therac-20 benutzten Hardware-Sicherungen gegen zu hohe Strahlungsdosis
Therac-25 realisierte Sicherungen in Software
Wenn
1. der Operator die urspr unglichen Strahlungsart und Dosis eingab,
2. der Operator dann aber innerhalb von 8 Sekunden die Strahlungsart oder Dosis anderte,
wurde der Magnet nicht zur uckgesetzt falsche Strahlungsdosis
Fehlermeldungen traten sporadisch auf, waren aber unverst andlich
Da die Herstellerrma die Fehler zun achst nicht reproduzieren konnte, nahm sie sie lange nicht
ernst
Auerdem: Die Vorg anger Therac-6 und Therac-20 waren bew ahrt
6
2.2 Drei argerliche Beispiele
Intel Pentium: 1/824633702441.0 um 0.00005 zu gro (1994)
Intel ben otigte 1 Jahr, um den Fehler durch Zufallstesten (= Testen mit zuf alligen Werten) zu
nden

The value in the [algorithm] lookup table was numerically generated and downloaded into a
Programmable Lookup Array. A defect in the script resulted in a few entries in the lookup table
being omitted. When a division that required those entries was executed, an incorrect value was
retrieved.
1
Ariane 5 explodiert auf Jungfernug (1996)

Shortly after lift-off, the [untested] faulty software module attempted to compute a value based
on the horizontal velocity of the launcher. Because this value for Ariane 5 was signicantly larger
than the value expected for Ariane 4, an operand error occurred on both the backup and active
Inertial Reference System. The validity of this conversion was not checked because it was never
expected to happen.
The specication for error handling of the system indicated that the failure context should be
stored in EEPROM memory before shutting down the processor. After the operand error, the
Inertial Reference System set the failure context as specied, which was read by the onboard
computer. Based on these values, the onboard computer issued a command to the nozzle of the
solid boosters and the main engine. The command called for a full nozzle deection. . .
Geldregen am Geldautomat (1990)

A Norwegian Bank was embarrased yesterday after a cashpoint computer applied its own form
of fuzzy logic and handed out thousands of pounds no one had asked for. A long queue formed
at the the Oslo cashpoint after news spread that customers were receiving 10 times what they
requested.
2
1
Telles, Hsie: The Science of Debugging
2
ACM SIGSOFT Software Engineering Notes 15(3), 1990, S. 7
7
2.3 Drei lustige Beispiele
Wahlbeteiligung von 104% in Neu-Ulm (1994)

Bei der Wahl des Oberb urgermeisters in Neu-Ulm 1994 wurde zun achst eine Wahlbeteiligung
von 104% ermittelt. Sp ater mute man feststellen, da sich in die Auswertungssoftware ein my-
steri oser Faktor 2 eingeschlichen hatte.
3
Roboter begeht Selbstmord mit L osungsmittel (1988)

A Budd Company assembly robot has apparently commited suicide. The robot was programmed
to apply a complex bead of uid adhesive, but the robot ignored the glue, picked up a stful of
highly-active solvent, and shot itself in its electronics-packed chest.
4
F-16 zieht Fahrwerk auf Landebahn ein (1986)

One of the rst things the Air Force test pilots tried on an early F-16 was to tell the computer
to raise the landing gear while still standing on the runway. Guess what happened? Scratch one
F-16.
5
3
Partsch, Requirements Engineering Systematisch, S. 1
4
ACM SIGSOFT Software Engineering Notes 13(3), 1988, S. 3
5
ACM SIGSOFT Software Engineering Notes 11(5), 1986, S. 10
8
Kapitel 3
Der Software-Lebenszyklus
3.1 Code-and-Fix-Zyklus
geeignet f ur 1-Person-Projekte und Praktikumsaufgaben in den ersten Semestern (PdP/PI)
Ablauf:
1. Code schreiben und testen
2. Code

verbessern (Fehlerbeseitigung, Erweiterung, Efzienz. . . )

3. GOTO 1
Wenn das Problem klar speziziert ist und eine Person die Implementierung allein bew altigen
kann, ist wenig dagegen zu sagen.
Jedoch:
Wartbarkeit und Zuverl assigkeit nehmen kontinuierlich ab (

Entropie)
Wenn der Programmierer k undigt, ist alles vorbei
Heutige Projekte umfassen -zig Personenjahre
Wenn Entwickler und Anwender nicht identisch sind, gibt es oft Meinungsverschiedenhei-
ten uber den erwarteten/realisierten Funktionsumfang
Sogenannte Software-Krise (1968)
9
3.2 Prozemodelle
Die Software-Krise f uhrte zur Entwicklung strukturierter Prozemodelle.
Ein Prozemodell bietet eine Anleitung f ur den Entwickler, welche Aktivit aten als n achstes kom-
men.
Vorteil: Der Entwicklungsproze wird (aus betriebswirtschaftlicher Sicht) plan- und kontrollier-
bar.
Projektplanung
Kostenkontrolle
Abnahme von Zwischen- und Endprodukten
. . .
3.3 Wasserfallmodell
Machbarkeits-
Studie
Anforderungs-
Analyse
Entwurf
Codierung
+ Modultest
Integration
+ Systemtest
Installation
+ Wartung
10
Eigenschaften des Wasserfallmodells
Der Entwicklungsproze wird in Phasen zerlegt
Eine Phase mu abgeschlossen sein, bevor die n achste beginnt
Jede Phase produziert ein Dokument (auch ein Programm)
Die Phasen k onnen in Unterphasen unterteilt werden
3.3.1 Durchf uhrbarkeitsstudie
(Detaillierte Beschreibung in Kapitel 6)
Die Durchf uhrbarkeitsstudie soll Kosten und Ertrag der geplanten Entwicklung absch atzen
Dazu (grobe) Analyse des Problems mit L osungsvorschl agen, Alternativl osungen
F ur jeden L osungsvorschlag werden ben otigte Ressourcen, Entwicklungszeit und Kosten gesch atzt
Die Ergebnisse werden in einem Dokument festgehalten
Dieses Dokument ist h aug Grundlage eines Angebotes an einen potentiellen Kunden
Problem: oft hoher Zeitdruck und begrenzte Ressourcen
ungenaue Sch atzungen
Ist die Aufgabe exakt umrissen und das Umfeld bekannt, kann die Durchf uhrbarkeitsstudie auch
fehlen.
Ergebnis der Phase: Durchf uhrbarkeitsstudie
11
3.3.2 Anforderungsanalyse
(Detaillierte Beschreibung in Kapitel 7)
In der Anforderungsanalyse wird exakt festgelegt, was die Software leisten soll (aber nicht, wie
diese Leistungsmerkmale erreicht werden).
Alle relevanten Funktions- und Qualit atsmerkmale m ussen speziziert werden!
Diese Angaben werden im Pichtenheft (auch Lastenheft genannt) dokumentiert; das Pichten-
heft ist Bestandteil des Vertrages.
Eine Anforderungsdenition mu
verst andlich sein, und zwar f ur Auftraggeber und Auftragnehmer
pr azise sein, damit es hinterher nicht zu Streit um die Auslegung kommt
vollst andig und konsistent sein, da L ucken und Widerspr uche zu teuren R uckfragen f uhren
oder zu Katastrophen.
Am pr azisesten sind formale Spezikationen, die sich auch formal auf Vollst andigkeit und Wi-
derspruchsfreiheit uberpr ufen lassen. (Kapitel 16)
Nachteil allerdings: Kunde versteht formale Spezikationen nicht.
Deshalb h aug Verwendung von semiformalen Methoden, z.B. Entity-Relationship Diagramme,
Datenudiagramme
oder sogar Prosa (mit standardisiertem Vokabular/Glossar)
H aug ist die Benutzeranleitung (in vorl auger Form) bereits Bestandteil des Pichtenheftes.
(Kapitel 8)
Ergebnis der Phase: Pichtenheft
12
3.3.3 Entwurf
(Detaillierte Beschreibung in Kapitel 10 und 11)
Im Entwurf wird die Systemarchitektur festgelegt:
Welche Module (Objekte, Klassen) gibt es?
Welche Beziehungen bestehen zwischen ihnen?
H auges Vorgehen: Top-Down Entwurf
Zerlegung des Systems in Komponenten, Zerlegung der Komponenten in Unterkomponenten
usw.
Oft ist die Verwendung spezieller Architektur- oder Systembeschreibungssprachen sinnvoll.
Ergebnis der Phase: Entwurfsbeschreibung, die die Systemarchitektur festh alt.
3.3.4 Codierung und Modultest
(Detaillierte Beschreibung in Kapitel 17)
Eigentliche Implementierungs- und Testphase
Codierung und Testen war fr uher die einzige Phase.
Firmen verwenden oft Programmierrichtlinien, z.B. Programmlayout, Namenskonventionen, Kom-
mentierkonventionen
Das ist aber fragw urdig, denn veraltete Konventionen k onnen die Qualit at reduzieren:
Folgendes Beispiel wurde uns glaubw urdig berichtet: In einer Abteilung einer be-
kannten Automobilrma werden Variablennamen zentral vergeben und durchnume-
riert, nach dem Schema

F ur Modul x darfst du die Variablen VW1344 bis VW1576

verwenden
Heute werden Programmierrichtlinien nicht nur von (benutzenden) Firmen, sondern gleich von
den Sprachautoren ver offentlicht.
Vorteil: Richtlinien werden von Anfang an eingesetzt.
Beispiel: Suns Code Conventions for the Java Programming Language
Ergebnisse der Phase:
Implementierungsbericht, der Details der Implementierung beschreibt (etwa Abweichun-
gen vom Entwurf, Abweichungen vom Zeitplan, Begr undungen dazu)
Testbericht, der die durchgef uhrten Tests und ihre Ergebnisse beschreibt
getesteter Programmtext der einzelnen Module
13
3.3.5 Integration und Systemtest
Die Module werden zu einem Programm zusammengebunden
Das Zusammenspiel der einzelnen Komponenten wird getestet
Kann mit der vorangegangenen Phase verschmolzen sein
Schlielich wird das gesamte System getestet:
zun achst nur innerhalb der Entwicklungsorganisation (Alpha-Test)
sp ater bei ausgew ahlten Kunden (Beta-Test)
Ergebnisse der Phase:
Laufendes System
Benutzeranleitung in endg ultiger Form
14
3.3.6 Installation und Wartung
Die Installation einer neuen Software ndet h aug in zwei Phasen statt:
Zun achst Auslieferung nur an ausgew ahlte, vertrauensw urdige Kunden. Ziel: R uckmel-
dungen, Erfahrungen und Fehlermeldungen der Benutzer gewinnen (Beta-Test)
Dann Auslieferung an alle Kunden
Wartungskosten machen 60% der gesamten Softwarekosten aus!
Davon wiederum
20% Fehlerbeseitigung
20% Adaption (z.B. Anpassung an neues Betriebssystem)
50% Perfektion (z.B. Umstellung von alphanumerischer auf graphische Schnittstelle)
Andere Quelle (Swanson 1980, Studie an 400 Softwareprojekten):
42%

Anderungen der Anforderungsdenition
17%

Anderung der Dateiformate
12% Notfalldebugging
9% normales Debugging
6%

Anderungen der Hardware
5% Verbesserungen der Dokumentation
4% Verbesserungen der Efzienz
Wartung ist um so teurer, je mehr die fr uhen Phasen davon betroffen sind. Am teuersten sind
nachtr agliche

Anderungen der Anforderungen man spricht von einer Verzehnfachung der Ko-
sten pro Phase.
Ergebnis der Phase: keins, da kein

Ubergang in n achste Phase
15
3.3.7 Wasserfallmodell mit R uckkopplung
In der Praxis kann man nie strenge Trennung der Phasen erreichen; dies ist nur der Idealfall
Deshalb: M oglichkeit, in fr uhere Phasen zur uckzukehren (etwa wenn Fehler oder Inkonsistenzen
entdeckt wurden)
Machbarkeits-
Studie
Anforderungs-
Analyse
Entwurf
Codierung
+ Modultest
Integration
+ Systemtest
Installation
+ Wartung
16
3.4 Evolution ares Modell
Probleme mit dem Wasserfallmodell:
Am Projektanfang sind nur ungenaue Sch atzungen der Kosten und Ressourcen m oglich.
Ein Pichtenheft, egal wie sorgf altig erstellt, kann nie den Umgang mit dem fertigen Sy-
stem ersetzen. Dies ist f ur viele Kunden ein Problem.
Es gibt Kunden, mit denen man keine pr azisen Pichtenhefte erstellen kann, weil sie nicht
wissen was sie wollen.
1
Oft werden die endg ultigen Anforderungen erst nach einer gewissen Experimentierphase
deutlich.
Antizipation des Wandels (von Anforderungen) wird uberhaupt nicht unterst utzt; stattdes-
sen werden die Anforderungen fr uhzeitig eingefroren.
Am Ende jeder Phase mu ein Dokument abgeliefert werden.
Dies kann zu einer Papierut und uberbordender B urokratie f uhren, ohne da die Qualit at pro-
tiert.
Alternative Evolution ares Vorgehen:
Ein Produkt wird als Folge von Approximationen realisiert.
Jede Approximation entsteht durch

Anderungen/Erweiterungen aus der vorangegangenen Versi-
on.
Einige oder sogar alle Phasen des Lebenszyklus k onnen evolution ar realisiert werden.
1
Beispiel: In Berlin sollte ein Programm zur Wohnungsvermittlung erstellt werden. Es sollte die Wohnungen
nach sozialen Kriterien vergeben, aber auch verf ugbare Wohnungen sofort vermitteln.
17
3.4.1 Prototyping
Software-Prototypen sind Approximationen an das endg ultige System mit
reduziertem Funktionsumfang
reduzierter Benutzerschnittstelle
reduzierter Leistung
Spezialf alle des Prototyping
Rapid Prototyping: Verwendung von Generatoren, ausf uhrbaren Spezikationssprachen oder
Skriptsprachen
Vorteil: sehr schnelle Realisierung, fr uhzeitige Validierung der funktionalen Spezi-
kation
Nachteil: u.U. inefzient, schlechte Benutzerschnittstelle, bei Skriptsprachen: schlech-
te Systemarchitektur
Horizontaler Prototyp: Nur eine Systemschicht, z.B. hohle Benutzerschnittstelle ohne echte
Funktionalit at
Vorteil: fr uhzeitiges Einbinden der zuk unftigen Benutzer; Validierung der Spezika-
tion
Nachteil: nur f ur Demos benutzbar
Vertikaler Prototyp: Abgemagerter Funktionsumfang wird durch alle Ebenen implementiert
Vorteil: fr uhzeitige Validierung technischer Systemeigenschaften; fr uhzeitige Auslie-
ferung eines Kernsystems
Nachteil: teuer
Problem: Den

Ubergang vom Prototypen zum Endprodukt bew altigen
Kunde sieht Prototyp und wundert sich, da er weggeworfen werden soll
Prototypen k onnen nur begrenzt zu einem vollwertigen Programm ausgebaut werden
Heutiger Trend:
Benutzerschnittstellen werden mit Skriptsprachen (z.B. Tcl/Tk, Python oder Visual Basic)
prototypisch realisiert; die Benutzerschnittstelle wird so auch Bestandteil des Endprodukts
Die einzelnen Funktionalit aten werden zun achst ebenfalls mit Skriptsprachen prototypisch
realisiert und im Endprodukt durch vollwertige, herk ommlich realisierte Funktionen aus-
getauscht.
18
3.4.2 Ratschl age f ur die evolution are Softwareentwicklung
2
Das System entwickelt sich um fr uhzeitig entwickelte Schl usselkomponenten, um die an-
dere Systemteile herumgebaut werden (Beispiel: Programmierumgebung entwickelt sich
um Editor herum)
Stets mu ein vorf uhrbarer Prototyp vorhanden sein, und sei er noch so vorl aug
Man sollte eine gute Entwicklungsinfrastruktur aufbauen. Gerade zur Prototypentwicklung
ist der Einsatz von Werkzeugen, High-Level-Sprachen und Generatoren notwendig
Die Systemarchitektur sollte in besonderer Weise f ur zuk unftige Optionen offen sein
Da es meistens ahnliche Projekte anderswo gibt, ist es wichtig, gut informiert zu sein.
3.4.3 Allgemeines evolution ares Modell
Machbarkeits-
Studie
Anforderungs-
Analyse
Entwurf
Codierung
+ Modultest
Integration
+ Systemtest
Installation
+ Wartung
Evaluierung
durch Anwender
2
Aus: J. Nievergelt et. al.: Smart Game Board and Chess Explorer: A Case Study in Software and Knowledge
Engineering, CACM 33, 2 (Februar 1990).
19
3.5 Spiralmodell
Das Spiralmodell ist ein Metamodell, das evolution are Aspekte und Risikobewertung umfat.
Jeder Umlauf der Spirale entspricht dem n achsten Prototyp;
Winkel Zeit, Radius Kosten
Jeder Umlauf zerf allt in 4 Hauptphasen (Quadranten):
1. Anforderungsdenition
2. Bewertung von Alternativen und Risiken
3. Entwurf, Implementierung, Test
4. Auswertung und Planung des n achsten Umlaufs
20
3.6 Transformationsmodell
Im Transformationsmodell wird das fertige Programm (halb-) automatisch aus einer formalen
Spezikation erzeugt
Korrektheitserhaltende Transformationen + Maschinenunterst utzung
1. Ausgangspunkt ist nichtdeterministische funktionale Spezikation
2. Zus atzliche Entwurfsentscheidungen beseitigen Nichtdeterminismus
3. Transformation in tailrekursive Form
4. Transformation in prozedurales Programm
Vorteil: Korrektheit garantiert
Nachteil: anspruchsvoll, nur f ur kleine Beispiele brauchbar
21
3.7 Extreme Programming
Extreme Programming (

XP) ist ein Proze zum schnellen Programmerstellen in unsicherem

Umfeld.
Antwort auf uberm aige Prozemodellierung der 90er.
Eigenschaften:
Arbeiten in kleinen Gruppen (max. 10 Personen)
Kurzfristige Planung (bis zum n achsten Termin)
Konzentration auf das, was gemacht werden mu
Flexibilit at ist Trumpf!
Das XP-Vorgehensmodell
Programmieren
in Paaren
Test
entwerfen
Kontinuierliche
Integration
Mitarbeiter
neu einteilen
Gnadenloses
Umstrukturieren
Test nicht bestanden
Test bestanden
neue Tests
neue Features
Hilferuf
zu komplexer
Code
neue
Paarbildung
vereinfachter
Code
Abnahmetest
alle Tests
bestanden
Neue Aufgabe
Paarbildung
Abnahmetest
erfolglos
Abnahme
Abnahmetest
erfolgreich
Stories
komplexes
Problem
einfache
Lsung
22
3.7.1 Eigenschaften des XP-Vorgehensmodells
Stories (Szenarien) treiben den Entwicklungsproze:
Eine Story beschreibt einen konkreten Vorfall, der f ur den Betrieb des Produktes
notwendig ist.
Beispiel eine

Parkhaus-Story:
Der Fahrer bleibt an der geschlossenen Schranke stehen und fordert einen Park-
schein an.
Hat er diesen entnommen, offnet sich die Schranke
Der Fahrer passiert die Schranke, die dann wieder schliet.
Weitere Situationen (volles Parkhaus, Stromausfall. . . ) werden ebenfalls durch eige-
ne Stories beschrieben.
Zu jeder Story wird ein Testfall entworfen (der die Funktionalit at der Story abdeckt)
Die Entwicklung ist beendet, wenn alle Testf alle erf ullt sind
Pair Programming (Programmieren in Paaren) sorgt f ur st andiges Gegenlesen durch den
Partner (vergl. Abschnitt 17.3)
H auger, st andiger Rollenwechsel (Programme schreiben/lesen)
Teams werden stets neu zusammengestellt
Auch der Kunde kann so beteiligt sein
St andiges automatisches Testen sorgt daf ur, da Funktionalit at erhalten bleibt (vergl. Ab-
schnitt 16.2)
F ur jede neue Funktionalit at gibt es einen Testfall
Testf alle werden vor dem Programm geschrieben
Jeder kann jederzeit die Software umstrukturieren (refactoring(vergl. Kapitel 15)
Software mu entsprechend wandlungsf ahig sein
Testf alle m ussen weiterhin erf ullt werden
Code-Qualit at mu auf hohem Niveau bleiben
23
3.7.2 XP kennt keinen Entwurf
Das Extreme Programming kennt keine eigenen Entwurfsphasen:
Die Funktionalit at des Systems wird in Stories zusammengefat
Jede Story wird 1:1 in einen Testfall umgesetzt
Man nehme den einfachsten Entwurf, der die Testf alle besteht und implementiere ihn
Die Implementierung ist abgeschlossen, wenn alle Testf alle bestanden sind
Treten bei der Abnahme weitere Fragen auf, gibt es neue Stories und neue zu erf ullende
Testf alle
Der Kunde ist bei der gesamten Entwicklung dabei!
3.7.3 Einsatzbedingungen
Extreme Programming ist geeignet. . .
wenn die Anforderungen vage sind
wenn die Anforderungen sich schnell andern
wenn das Projekt klein bis mittelgro ist (< 1012 Programmierer)
Extreme Programming ist ungeeignet. . .
wenn es auf beweisbare Programmeigenschaften ankommt
wenn sp ate

Anderungen zu teuer werden
wenn h auges Testen zu teuer ist
wenn das Team zu gro oder nicht an einem Ort ist
24
3.7.4 Vor- und Nachteile
Positiv
Testf alle vor dem Codieren schreiben
Programmieren in Paaren
Umstritten
Kein Entwurf
Keine externe Dokumentation
Negativ
Erschwerte Wiederverwendung
Nur f ur kleine, hochqualizierte Teams geeignet
Erst wenig Erfahrung vorhanden
25
Eine alternative Sicht des Software-Lebenszyklus
26
Kapitel 4
Software-Qualit atsmerkmale
Wir unterscheiden
externe Qualit atsfaktoren: sichtbar f ur die Benutzer der Software
interne Qualit atsfaktoren: sichtbar f ur die Entwickler der Software
Qualit atsmerkmale m ussen validierbar sein.
27
4.1 Korrektheit
Korrekte Software erf ullt ihre Aufgabe entsprechend der Spezikation
Spezikation: funktionale Beschreibung der Anforderungen
was soll die Software tun, und was ist Voraussetzung daf ur
(aber nicht: wie tut sie es)
Korrektheit ist der wichtigste Qualit atsfaktor!
aber Korrektheit wird stets relativ zur Spezikation betrachtet:
ohne Spezikation keine korrekte Software
Die Spezikation mu deshalb hinreichend genau sein Miverst andnisse bei der Spezikation
sind die h augste und teuerste Fehlerquelle!
Verfahren zum

Uberpr ufen der Korrektheit:
Programmverikation (mathematisch)
Programmtest (empirisch)
Besser: (Teil)Korrektheitsgarantie per Konstruktion/Werkzeug:
konstruktive Verikation (Programmerstellung durch semiautomatische Transformation
der Spezikation in ausf uhrbares Programm)
statische Analysen (z.B. Typcheck: well typed programs cant go wrong)
Es gibt (fast) keine korrekten Softwaresysteme!
28
4.2 Zuverl assigkeit
Zuverl assige Software erf ullt ihre Aufgabe meistens
Im engeren Sinne ist Zuverl assigkeit die Wahrscheinlichkeit eines (gewichteten) Fehlers in einer
bestimmten Zeitspanne

Ubliches Ma: MTBF (Mean Time Between Failures)

Korrekte Systeme sind automatisch zuverl assig
Software
korrekte
Software
zuverlssige
In der Praxis gibt es viele nichtkorrekte Softwaresysteme, die dennoch recht zuverl assig sind
Beispiel f ur inkorrekte, aber noch zuverl assige Software:
Ein Texteditor, der manchmal Schmierzeichen auf den Bildschirm malt
Beispiel f ur unzuverl assige Software:
Ein Texteditor, der manchmal die Datei kaputtmacht
In der Praxis ist meistens schon die Spezikation unvollst andig oder inkonsistent, so da aus
praktischer Sicht Zuverl assigkeit wichtiger ist als Korrektheit
Unzuverl assige Produkte sterben schnell!
29
4.3 Robustheit
Robuste Software funktioniert auch unter unvorhergesehenen Umst anden
Beispiele f ur unvorhergesehene Umst ande:
Falsche Benutzereingabe
Plattenfehler
Stromausfall
Es mag sein, da derartige Situationen in der Spezikation nicht vorgesehen waren, das Pro-
gramm also korrekt ist, auch wenn es etwa auf falsche Eingabe mit Absturz reagiert.
Ein Editor, der auf einen nicht vorgesehenen Knopfdruck hin die Datei l oscht, wird aber wenig
Freunde nden.
Die Spezikation sollte auch f ur unvorhergesehene Situationen ein deniertes Systemverhal-
ten vorsehen.
Dadurch wird Robustheit Teil der Korrektheit.
Fail-Safe Technik: Ansteuern eines sicheren Systemzustandes im Fehlerfall
Beispiel: Entdeckt eine Eisenbahn-Signalsteuerungsanlage eine nicht vorgesehene Situation, soll-
ten alle Signale auf Rot gestellt werden.
Gerade Anf anger und Nichtfachleute brauchen robuste Software!
30
4.4 Efzienz
Efziente Software nutzt Hardware-Ressourcen okonomisch
Korrektheit geht vor Efzienz!
Aber mangelnde Efzienz kann Software unbenutzbar machen.
Bekannte Anforderung: Sub-Second Response Time f ur interaktive Systeme
Wichtigste Kriterien: Zeitbedarf, Platzbedarf
Wie bewertet man Efzienz?
Theoretische Komplexit atsanalyse
Simulationsmodelle
Messungen
Wie erzielt man Efzienz?
Verwende gute Algorithmen (z.B. O(n ln n) Sortierverfahren statt O(n
2
) Verfahren)
Optimierung, Tuning von Problemstellen, z.B. inneren Schleifen (

erst messen, dann opti-

mieren)
Schnellere Hardware kaufen
Die theoretische Komplexit at limitiert die maximale Problemgr oe!
Durch die rasanten Fortschritte der Hardwaretechnologie hat die Efzienz im Vergleich zu
anderen Qualit atskriterien an Bedeutung verloren
31
4.5 Benutzerfreundlichkeit
Benutzerfreundliche Software kann von Menschen leicht erlernt und benutzt werden
Die Benutzerschnittstelle bestimmt die Benutzerfreundlichkeit.
Hierbei mu nach Anwenderklassen (Anf anger, Fortgeschrittene Experte) differenziert werden.
Beispiel: Men us f ur Anf anger, Control-Keys f ur Fortgeschrittene, Makros f ur Experten.
Wichtigstes Kriterium f ur Benutzerschnittstellen ist Konsistenz:

Ahnliche Funktionen sollten auch auf ahnliche Weise ausgel ost werden!
Standardisierung kann Benutzerfreundlichkeit sehr erh ohen.
Beispiel: jeder kann sich schnell an ein anderes Auto gew ohnen, denn die Anordnung der Bedie-
nungselemente ist im wesentlichen dieselbe.
Aber steigen Sie mal von Word auf L
A
T
E
X um!
Groe Fortschritte durch Graphische Benutzerober achen (KDE, MacOS, Windows 95). Diese
bieten auch Style-Guides als Entwurfshilfen.
Psychologische Aspekte der Benutzerfreundlichkeit werden in der
Software-Ergonomie erforscht. Beispiel

magic number seven: ein Men u sollte nicht mehr als 7

Men upunkte enthalten.
Interaktion mit anderen Qualit atskriterien:
inkorrekte Software ist uberhaupt unfreundlich
langsame Systeme sind unfreundlich, auch wenn die Antworten mit bunten Bildern darge-
stellt werden
Schlechte Software mit guter Schnittstelle verkauft sich besser
als gute Software mit schlechter Schnittstelle!
32
4.6 Wartbarkeit
Software-Wartung =

Anderungen an der Software aufgrund von Fehlern oder ge anderten
Anforderungen
Eigentlich ein Euphemismus, denn Software kann nicht verschleien, im Gegensatz etwa zu
einem Keilriemen
besserer Begriff: Software-Evolution
Wartungskosten machen 60% der gesamten Softwarekosten aus!
Davon wiederum
20% Fehlerbeseitigung
20% Adaption (z.B. Anpassung an neues Betriebssystem)
50% Perfektion (z.B. Umstellung von alphanumerischer auf graphische Schnittstelle)
Wartbarkeit wird unterst utzt durch
Gute Systemstruktur (Modularisierung)
Gute Dokumentation
Kontrollierte

Anderungsprozeduren (Versions- und Variantenkontrolle)
Je mehr unkontrollierter Informationsu, desto schlechter die Wartbarkeit und desto h oher die
Wahrscheinlichkeit, da Reparaturen neue Fehler einf uhren
Software ist gar nicht so soft: Nichts ist einfacher, als ein Programm zu andern, aber in schlecht
strukturierter Software kann der Austausch eines Teils das gesamte Systemgeb aude zum Einsturz
bringen!
Jede Wartung reduziert die Wartbarkeit, solange bis die Software nicht mehr anderbar ist
(Gesetz der zunehmenden Entropie)
33
4.7 Wiederverwendbarkeit
Wiederverwendbare Software kann leicht f ur neue Anwendungen verwendet werden
klassische Beispiele f ur wiederverwendbare Software: Programmbibliotheken
Ein-/Ausgabe
Netzwerk, Kommunikation
Graphische Ober achen
Auch Teile einer Spezikation, Teile eines Entwurfs, Entwicklungsmethoden, Entwicklungspro-
zesse oder Wissen eines Entwicklers k onnen wiederverwendbar sein.
Traumziel:

Zusammenstecken von Software aus vorgefertigten Komponenten ( ahnlich wie es

Kataloge von Transistoren und Chips gibt, sollte es Kataloge von Softwarekomponenten geben)
Abstraktion ist der K onigsweg zu Wiederverwendbarkeit:
Ersetze anwendungsspezische Teile durch formale Parameter
Instantiiere diese Parameter je nach Bedarf der Anwendung
Beispiel: Polymorphe Funktionen k onnen mit Daten verschiedenen Typs

gef uttert werden;

Typsicherheit bleibt erhalten
Beispiel: Objektorientierte Programmierung
Objekte fassen Daten (Attribute) und Operationen darauf zusammen
Klassen beschreiben Mengen von Objekten und deren gemeinsame Eigenschaften (Schnitt-
stelle)
Unterklassen spezialisieren Klassen durch Hinzuf ugen neuer Operationen (Vererbung)
34
4.8 Portierbarkeit
Portierbare Software kann in verschiedenen Umgebungen laufen
Umgebung = Hardware oder Software (Betriebssystem, Fenstersystem)
Sogar innerhalb einer Prozessorfamilie nichttrivial
Portierbarkeit erreicht man durch Standardisierung:
Verwendung standardisierter Sprachen
Verwendung standardisierter Betriebssysteme
Verwendung standardisierter Fenstersysteme
Verwendung standardisierter Schnittstellen
Problem: portierbare Software kann Vorz uge einer speziellen Umgebung nicht nutzen (z.B. Ma-
schinenbefehle, die es nur auf bestimmten Prozessoren einer Familie gibt)
L osung:
erstelle portierbare Minimalversion
verwende Varianten f ur spezielle Kongurationen
Fr uher typisch: Software lief auf einer Maschine
Heute typisch: Software l auft auf (fast) allen PCs, auf (fast) allen UNIX-Rechnern, auf (fast)
allen Java-Maschinen
Portierbarkeit wird immer wichtiger, aber durch zunehmende Standardisierung immer
unproblematischer. Das Hauptproblem ist die Variantenkontrolle.
35
4.9 Kompatibilit at
Kompatible Software kann leicht mit anderer Software kooperieren (Interoperabilit at)
Klassisches Analogiebeispiel: Stereoanlage. Jeder CD-Spieler kann an jeden Verst arker ange-
schlossen werden
Beispiele:
Tabellen, die mit einem Grakprogramm erzeugt wurden, k onnen in eine Textverarbeitung
ubernommen werden
Neuartige Programmierumgebungen k onnen mit vorhandenen Werkzeugen kombiniert wer-
den
Der GNOME-Desktop kann mit verschiedenen Window-Managern arbeiten
Wichtig: Gemeinsame, wohldenierte Schnittstellen, z.B. einheitliche Dateiformate, normierte
Protokolle (XML, CORBA)
Abtr aglich: monolithische Systemstrukturen; Systeme, die (behaupten) alles (zu) bieten; Kon-
trolle durch Dritten
Zutr aglich: Offene Systeme mit offentlichen Schnittstellen, die aus vielen selbst andigen Einzel-
programmen bestehen

Integrierte Produkte halten oft nicht, was sie versprechen

Offenen Systemen geh ort die Zukunft!
36
4.10 Produktivit at
Produktivit at mit die Efzienz des Software-Entwicklungsprozesses
H aug verwendete, aber sehr fragw urdige Einheit:
Programmzeilen
Monat
Bestraft das Finden guter Abstraktionen!
Besseres Produktivit atsma, aber schwerer zu quantizieren:
Realisierte Funktionen
Monat
Produktivit at ist individuell stark schwankend; h angt sehr von Ausbildung, Aufgabe, Program-
miersprache, Programmierumgebung etc. ab
Typisch: 1000 Zeilen/Monat bei prozeduralen Sprachen
Die Produktivit at eines Teams ist kleiner als die Summe der Einzelproduktivit aten: je gr oer das
Team, desto gr oer der Organisations-Overhead pro Kopf (bis zu 40%!)
Teamgroesse
Produktivitaet
5 7 10
Produktivit at kann durch Methoden und Werkzeuge drastisch erh oht werden etwa durch geeig-
nete Programmiersprachen:
Python vs. C: Faktor 10
Prolog vs. Assembler: Faktor 50
37
4.11 Vertrauensw urdigkeit
Vertrauensw urdige Software hat auch im Fehlerfall
keine katastrophalen Auswirkungen
Manche Software ist von allein vertrauensw urdig, z.B. Editor, Compiler, Binder, Schachpro-
gramm, . . .
Inkorrekte Software kann vertrauensw urdig sein
Unzuverl assige Software kann vertrauensw urdig sein
Korrekte Software mu nicht vertrauensw urdig sein (z.B. wenn in der Spezikation ein m ogli-
cher katastrophaler Seiteneffekt ubersehen wurde)
Nicht robuste Software ist kaum vertrauensw urdig!
Vergleiche: Therac-25 Strahlenkanone
Es gibt Verfahren zur Absch atzung der Vertrauensw urdigkeit
1
Historische Analogie: Dampfmaschine
Im 19. Jahrhundert t oteten die damals noch unausgereiften Hochdruckdampfmaschi-
nen bei Explosionen mehrere hundert Menschen. Die Situation entsprach ziemlich
genau der heutigen Situation mit sicherheitskritischer Software; die Analyse der da-
maligen Geschehnisse kann auch einen Anhaltspunkt f ur heute liefern.
2
Vertrauensw urdigkeit ist extrem schwer zu garantieren, und die Gesellschaft mu deshalb
entscheiden, welche Restrisiken sie einzugehen bereit ist
1
siehe Parnas et al.: Evaluation of Safety-Critical Software, CACM 33,6 [Juni 1990], S. 636648
2
N.G. Leveson: High-Pressure Steam Engines and Computer Software, Proc. International Conference on Soft-
ware Engineering, Melbourne, May 1992.
38
4.12 Qualit atsmerkmale f ur bestimmte Anwendungen
4.12.1 Datenbanksysteme
Datenintegrit at: Wie wirken sich Hardware/Softwarefehler auf den Datenbestand aus? Kann
ein Plattenfehler die Datenbank korrumpieren?
Sicherheit: Wie wird unautorisierter Zugriff/Manipulation von Daten verhindert?
Verf ugbarkeit: Wie schnell kann die Datenverf ugbarkeit nach Systemausfall wieder hergestellt
werden?
Transaktionsdurchsatz: Wieviel Transaktionen pro Sekunde k onnen bearbeitet werden?
4.12.2 Realzeitsysteme
Realzeitsysteme steuern physikalische Prozesse
Realzeitsysteme m ussen innerhalb strikter Zeitgrenzen auf externe Ereignisse reagieren
Efzienz wird Teil der Korrektheit!
Robustheit, Zuverl assigkeit und Vertrauensw urdigkeit absolut essentiell (vgl. fail-safe)
Verbotene Systemzust ande werden oft separat speziziert
4.12.3 Verteilte Systeme
Systeme aus mehreren unabh angigen, aber gekoppelten Rechnern
Transparenz: mu der Benutzer auf Verteiltheit R ucksicht nehmen, oder kann er so tun, als
stehe ihm ein groes System zur Verf ugung?
Beispiele: UNIX-Dateisystem, X-Windows
Parallelit atsgrad: Wie werden die multiplen Hardwareressourcen ausgenutzt?
Fehlertoleranz: Was passiert beim Ausfall eines Knotens oder einer Verbindung?
Verteilte Systeme k onnen durch Redundanz die Zuverl assigkeit erh ohen (z.B. Mehrfachspeiche-
rung / Verteilung von Daten)
39
4.12.4 Eingebettete Systeme
Software ist Teil eines technischen Gesamtsystems (z.B. Waschmaschine, Kernreaktor)
Eingebettete Systeme interagieren nicht mit Menschen, sondern mit Sensoren und Kontrollein-
heiten
Es gibt keine Benutzerschnittstelle!
Sicherheit ist wichtiges Kriterium in eingebetteten Systemen. Hierbei wird zwischen Safety und
Security unterschieden:
Safety: Kann das System in einen verbotenen Zustand gelangen? Welche Auswirkungen hat die
Annahme eines verbotenen Zustands? Welche Reaktion erfolgt durch das System?
Security: Wie wird unautorisierter Zugriff auf bzw. Manipulation des Systems verhindert?
Realzeitsysteme sind oft eingebettete Systeme
40
Kapitel 5
Grundprinzipien des Software Engineering
Prinzipien: Allgemeine und abstrakte Aussagen uber w unschbare Eigenschaften von Software
und ihren Entwicklungsprozessen
Methoden: Generelle Richtlinien zur Prozeorganisation
Techniken: Spezielle Verfahren zur L osung von Teilproblemen im Entwicklungsproze
Methodologien: Methoden + Techniken
Werkzeuge: Implementierungen bestimmter Techniken oder Methoden
Prinzipien, Methodologien und Werkzeuge sollen das Erreichen von Qualit at unterst utzen
Vier Grundprinzipien:
1. Strenge und Formalit at
2. Separation der Interessen Modularit at
3. Abstraktion Allgemeinheit
4. Evolutionsf ahigkeit Inkrementalit at
41
5.1 Strenge und Formalit at
Software-Entwicklung ist eine kreative T atigkeit
Viele Software-Entwickler, insbesondere Studenten und Wissenschaftler, lassen ihrer Kreativit at
bei der Software-Entwicklung freien Lauf
geniale Software schlechter Qualit at bei unkalkulierbaren Terminen und Kosten
Dies mag im Wissenschaftsbereich ok sein, f ur eine am Markt orientierte Organisation aber nicht
Strenge und formale Verfahren sind ein notwendiges Komplement
Strenge: Vorgehen nach strengen Regeln
Formalit at ist mehr als Strenge: Bei formalem Vorgehen mu in jedem Schritt ein mathemati-
sches Gesetz angewendet werden
Beispiel: Lehrb ucher der Mathematik sind streng, aber nicht formal!
Strenge Verfahren in der Softwareentwicklung:
UML-Diagramme
Schrittweise Verfeinerung
Formale Verfahren in der Softwareentwicklung:
Algebraische Spezikation
Programmverikation
Formalit at und Strenge engen nicht die Kreativit at ein,
sondern erh ohen Korrektheit und Zuverl assigkeit
42
5.2 Separation der Interessen (

Teile und Herrsche)

Wer alles auf einmal machen will, erreicht nichts
Software-Entwicklung ist reduktionistisch: die verschiedenen Aspekte wie Funktionalit at, Qua-
lit atsmerkmale, Hard- und Softwareumgebung, Teamorganisation, Kostenkontrolle . . . werden
(soweit m oglich) isoliert betrachtet.
Dies ist die einzige M oglichkeit, die Komplexit at der Entwicklung in den Griff zu bekommen!
Trennung verschiedener Entwicklungsphasen
Erst wird entworfen
Dann implementiert
Dann getestet
Trennung verschiedener Qualit atsaspekte
Korrektheit
Efzienz
Benutzerschnittstelle
Trennung verschiedener Sichten
Statischer Aufbau
Dynamisches Verhalten
Trennung verschiedener Teile
Zerlegung eines Systems in Elemente
Festlegung der Schnittstelle zwischen Elementen

Trennung bedeutet hier oft auch

personelle Trennung:
Jede/r sollte das machen, was er/sie am besten kann
In der Software-Entwicklung ist es selten,
da eine ganzheitliche Sicht der Dinge mehr bringt
43
5.3 Spezialfall: Modularit at
Modul = Software-Komponente mit wohldenierter Schnittstelle
Schnittstelle: Variablen und Operationen (samt Argument- und Ergebnistypen), die von auen
verwendet werden k onnen
Interne Realisierungsdetails (lokale Datenstrukturen und Algorithmen) sind nach auen unbe-
kannt!
Beispiel: Der Benutzer (Klient) eines Warteschlangen-Moduls braucht nicht zu wissen, ob die
Warteschlange als Feld oder verkettete Liste implementiert ist; er mu aber wissen, wie die
Operationen zum Anf ugen / Entfernen heien bzw. was diese f ur Argumente haben.
Vorbild: Klassische Ingenieurtechnik
Beispiel: Baugruppen (Platinen) in einem Fernseher.
Andere Baugruppen bedienen sich der Dienste einer Baugruppe nur uber eine Schnitt-
stelle, welche aus einigen Kabeln besteht; f ur jeden Anschlu sind die elektrischen
Eigenschaften genau speziziert. Die interne Schaltung einer Baugruppe ist nach au-
en uninteressant; Verbesserungen in einer Baugruppe betreffen andere Baugruppen
nicht, und im Fehlerfall kann eine Baugruppe einfach ausgetauscht werden.
Module sollten syntaktischen Einheiten der Sprache entsprechen
Schnittstellen sollen uber Mittel der Programmiersprache realisiert werden:
keine (implizite) Kommunikation uber globale Variablen,
keine (impliziten) Konventionen zum Funktionsaufruf
Grundprinzipien der Modularisierung:
Hohe Koh asion: Module sollten logisch zusammengeh orende Funktionen enthalten
Wenige Schnittstellen: Module sollten mit m oglichst wenig anderen Modulen kommunizieren
Schwache Kopplung: Module sollten so wenig Information wie m oglich austauschen
Geheimnisprinzip: Niemand darf modulinterne Daten abfragen oder manipulieren. Auf die
Dienste eines Moduls darf nur durch Aufruf von Schnittstellenfunktionen zugegriffen werden.
44
5.4 Abstraktion
Abstraktion: Ignorieren von irrelevanten Details;
Herausarbeiten des (f ur einen Zweck) Wesentlichen
Oft hat man Abstraktionshierarchien, wobei jede Schicht die ad aquate Beschreibung f ur einen
bestimmten Zweck ist:
Elektronen / Quantenmechanik
Transistoren / Festk orperphysik
Gatter / Boolesche Algebra
Maschinensprache / Rechnerorganisation
h ohere Sprache / Compilertheorie
Module und Komponenten / Software Engineering
Jede h ohere Schicht ignoriert Details der darunterliegenden Schicht
Klassischer Abstraktionsmechanismus in der Informatik: h ohere Programmiersprachen. Diese
verstecken die Details der Hardware.
Auch die Konstruktion eines Algorithmus ist eine Abstraktion: man abstrahiert von konkreten
Eingabedaten und sucht ein allgemeines Verfahren.
Software-Entwurf : Denition geeigneter Funktionsbausteine
Von der konkreten Realisierung der Bausteine wird abstrahiert
Abstraktion ist der K onigsweg zur Wiederverwendbarkeit:
Ersetze anwendungsspezische Teile durch formale Parameter
Instantiiere diese Parameter je nach Bedarf der Anwendung
Das Finden geeigneter Abstraktionen ist der Kern der Informatik
45
5.5 Spezialfall: Allgemeinheit

Every time you are asked to solve a problem, try to discover a more general problem
that may be hidden behind the problem at hand.
It may happen that the generalized problem is not more complexit may even be
simplerthan the original problem. Being more general, it is likely that the solution
to the more general problem has more potential for being reused.
It may even happen that the solution is provided by some off-the-shelf package. Also,
it may happen that by generalizing a problem you end up designing a module that
is invoked at more than one point of the application, rather than having several
specialized solutions. (Ghezzi)
Beispiele:
Allgemein verwendbares Sortierprogramm
Tabellenkalkulation
Datenbanksystem
Grak-Bibliothek
Textprozessoren (z.B. AWK)
statt
Quicksort f ur Arrays fester Gr oe
Selbstgebastelter Taschenrechner
Handimplementierte Rot/Schwarz-B aume
Direktes Ansprechen der Grakkarte
Selbstrealisierter Knuth-Morris-Pratt-Algorithmus zur Textsuche
Allgemein verwendbare Software verkauft sich besser!
46
5.6 Evolutionsf ahigkeit (

Antizipation des Wandels)

In Software ist nichts best andiger als der Wandel
Bereits bei der Erstellung mu der zuk unftigen Software-Evolution Rechnung getragen werden
Eigenschaften, die sich absehbar andern, sollten von vornherein in spezischen Komponenten
isoliert werden
Dadurch ist nur ein kleiner Teil der Software von der

Anderung betroffen.
Beispiele f ur Evolutionsf ahigkeit:
Feldgr oen
Schlechte L osung:

Uberall im Programm steht
if (i < 100) ...a[i]... . . .
Gute L osung: Verwende symbolische Konstante
Datumsfunktionen
Schlechte L osung: im Programm stehen Umrechungen wie
if (year > 30 && year < 99) year += 1900 . . .
Gute L osung: Verwende explizite Datumsfunktionen
Fehlermeldungen
Schlechte L osung: Englische Strings sind im Programmtext verstreut
Gute L osung: Die Meldungen werden aus einer Datei eingelesen
Wiederverwendbarkeit wird deutlich verbessert!
Auf diese Weise kann man leicht Programmfamilien realisieren, die sich nur in wenigen Kom-
ponenten unterscheiden (Varianten, Kongurationen)
Problem: Kongurationsmanagement
Gibt es eine Software in mehreren Varianten, sollte eine konsistente Version automatisch kon-
struiert werden zur

Ubersetzungszeit oder zur Laufzeit.
Wandel in der Auffassung von Software Engineering:
Fr uher: Konstruktion hochwertiger Software aus einer gegebenen Spezikation

from scratch.
Heute: Anpassen existierender Komponenten; Evolution bestehender Systeme
47
5.7 Spezialfall: Inkrementalit at
Inkrementalit at = Vorgehen in kleinen Schritten
Inkrementalit at im Software Engineering: ein Produkt wird als Sequenz von Approximationen
realisiert (

evolution ares Vorgehen)

Jede Approximation entsteht durch kleine

Anderungen/Erweiterungen aus der vorangegangenen
Version
Vorteile:
Teilsysteme mit eingeschr ankter Funktionalit at k onnen fr uhzeitig ausgeliefert werden
Fr uhzeitiges Feedback durch Benutzer
Vollst andige Spezikation ist am Anfang nicht n otig
Spezialfall: Rapid Prototyping
Das System wird zun achst in einer ausf uhrbaren Spezikationssprache (VDM, ASF, RAP) rea-
lisiert
Dies ist zwar sehr langsam, erm oglicht aber fr uhzeitige Diskussionen mit den Anwendern; das
Risiko von Fehlspezikationen oder Miverst andnissen wird stark reduziert
Sp ater kann eine efziente Version mit endg ultiger Benutzerschnittstelle implementiert werden
Variante: Realisiere zun achst eine hohle Benutzerschnittstelle und benutze diese zu Pr asentatio-
nen / Diskussionen mit dem Kunden. Sp ater wird dann die echte Funktionalit at erg anzt
Hohle Schnittstellen zu bauen ist g angige Praxis!
48
5.8 Grundprinzipien und Qualit atsmerkmale
+: positive, : negative Auswirkung des Grundprinzips auf Qualit atsmerkmal
S
t
r
e
n
g
e
,
F
o
r
m
a
l
i
t
a
t
S
e
p
a
r
a
t
i
o
n
d
e
r
I
n
t
e
r
e
s
s
e
n
M
o
d
u
l
a
r
i
t
a
t
A
b
s
t
r
a
k
t
i
o
n
A
l
l
g
e
m
e
i
n
h
e
i
t
E
v
o
l
u
t
i
o
n
s
f
a
h
i
g
k
e
i
t
I
n
k
r
e
m
e
n
t
a
l
i
t
a
t
Korrektheit ++ + + + +
Zuverl assigkeit ++ + + + + +
Robustheit ++ ++
1
++ +
Efzienz
2

Benutzerfreundlichkeit + + + + ++
3
Wartbarkeit + ++ ++ + ++ +
Wiederverwendbarkeit ++ ++ ++ ++ ++ +
Portierbarkeit ++ ++ +
Kompatibilit at + + + +
Produktivit at
4
+ + ++ ++ ++ ++
5
Vertrauensw urdigkeit ++ ++ ++
6

7
1
Wenig Kopplung
2
Schnittstellen sind meist inefzienter als direkter Zugriff
3
H auger und fr uher Feedback durch Anwender
4
Strenge und Formalit at erfordern kurzfristig h oheren Aufwand (bringen aber mittelfristig Gewinn, s. Wartbar-
keit)
5
Fr uhzeitige Eink unfte durch fr uhe Auslieferung unvollst andiger Versionen
6
Sicherheitskritische Software wird auf ein bestimmtes Umfeld hin veriziert
7
Viele Revisionen instabile Software!
49
Kapitel 6
Pr ufung der Durchf uhrbarkeit
Bevor mit der eigentlichen Software-Entwicklung begonnen werden kann, mu in der Durchf uhr-
barkeitsstudie gepr uft werden, ob
die fachliche Durchf uhrbarkeit,
die okonomische Durchf uhrbarkeit und
die personelle Durchf uhrbarkeit
gegeben sind.
Ziel ist, zu pr ufen, ob ein Produkt entwickelt werden soll.
50
6.1 Die Durchf uhrbarkeitsstudie
Zur Pr ufung der Durchf uhrbarkeit geh ort:
Ausw ahlen des Produkts
Trendstudien
Marktanalysen
Forschungsergebnisse
Kundenanfragen
Vorentwicklungen
Voruntersuchung des Produkts
Ist-Analyse (etwa gegenw artiges Produkt)
Festlegen der Hauptanforderungen:
Hauptfunktionen, -daten, -leistungen
Aspekte der Benutzerschnittstelle
Wichtigste Qualit atsmerkmale
Durchf uhrbarkeitsuntersuchung
Fachliche Durchf uhrbarkeit (Softwaretechnische Realisierbarkeit,
Verf ugbarkeit geeigneter Hardware)
Alternative L osungsvorschl age (etwa Anpassung
von Standardsoftware vs. Neuerstellung)
Personelle Durchf uhrbarkeit (Aufwandsabsch atzung,
Lage am Arbeitsmarkt)
Pr ufen der Risiken
Pr ufung der okonomischen Durchf uhrbarkeit
Aufwands- und Terminabsch atzung
Wirtschaftlichkeitsrechnung
Die Durchf uhrbarkeitsstudie besteht aus
1. Lastenheft,
2. Projektkalkulation und
3. Projektplan.
51
6.2 Das Lastenheft
Das Lastenheft (auch grobes Pichtenheft) f uhrt alle fachlichen Anforderungen auf, die die fer-
tige Software aus Sicht des Auftraggebers erf ullen mu.
Es ist das erste Dokument, das die Anforderungen an ein neues Produkt grob beschreibt.
Typischer Aufbau des Lastenhefts
1
1 Zielbestimmung
Welche Ziele sollen durch den Einsatz der Software erreicht werden?
2 Produkteinsatz
F ur welche Anwendungsbereiche und Zielgruppen ist die Software vorgesehen?
3 Produktfunktionen
Was sind die Hauptfunktionen des Produktes aus Sicht des Auftraggebers?
Die Hauptfunktionen (Kernfunktionen, keine Details!) werden typischerweise einzeln ge-
kennzeichnet (etwa /LF10/, /LF20/, . . . ), um sich in sp ateren Dokumenten auf sie beziehen
zu k onnen.
4 Produktdaten
Was sind die (permanent gespeicherten) Hauptdaten des Produkts?
Hier ebenfalls Kennzeichnung (mit /LD10/, /LD20/, . . . )
5 Produktleistungen
Werden f ur bestimmte Funktionen besondere Anspr uche in Bezug auf Zeit, Datenumfang
oder Genauigkeit gestellt? Welche?
Hier ebenfalls Kennzeichnung (mit /LL10/, /LL20/, . . . )
6 Qualit atsanforderungen
Aufz ahlung der wichtigsten Qualit atsanforderungen wie Zuverl assigkeit, Robustheit, Be-
nutzerfreundlichkeit, Efzienz . . .
7 Erg anzungen
Gibt es auergew ohnliche Anforderungen, die nicht durch obige Punkte abgedeckt sind?
Welche?
Typischer Umfang: nur wenige Seiten
1
aus Balzert, Lehrbuch der Software-Technik
52
6.3 Projektkalkulation
Software ist teuer. Noch teurer aber werden (zumindest f ur den Hersteller) falsche Preisvorstel-
lungen.
Zur Kalkulation der anfallenden Kosten gibt es viele Modelle:
Analogiemethode
Vergleich der zu sch atzenden Entwicklung mit bereits abgeschlossenen Entwicklungen
anhand von

Ahnlichkeitskriterien.
Nachteil: Expertenwissen oft nicht nachvollziehbar
Relationsmethode
Analogiemethode mit Faktorenliste (etwa Faktor Programmiersprache: PASCAL = 100,
COBOL = 120, ASSEMBLER = 140)
Bei Wechsel innerhalb eines Faktors kann so der Aufwand neu bestimmt werden
Multiplikatormethode
Aufwandssch atzung f ur einzelne Teilsysteme der Software. Bestimmte Teilsysteme sind
(erfahrungsgem a) teurer als andere (etwa: Datenverwaltung 1,0; Algorithmen 2,0)
Gesamtaufwand ergibt sich als Summe des Aufwands f ur die Teilsysteme.
Gewichtungsmethode
Bestimmung zahlreicher Faktoren objektiv wie

verwendete Programmiersprache oder

subjektiv wie

Erfahrung des Personals und Verkn upfung aller Faktoren gem a mathe-
matischer Formel
Bekannteste Vertreter: Constructive Cost Model (COCOMO), Function-Point-Methode
(derzeit einzige empfehlenswerte)
Iterative Anwendung: Einufaktoren m ussen regelm aig angepat werden
Prozentsatzmethode
Aus abgeschlossenen Entwicklungen wird ermittelt, wie sich der Aufwand auf die einzel-
nen Phasen verteilt hat (etwa: Spezikation 20%). Bei neuen Projekten kann dann aus
der tats achlichen Dauer der abgeschlossenen Phasen der Aufwand f ur die Restphasen
gesch atzt werden.
Wird gew ohnlich mit einer der obigen Methoden kombiniert
Parkinsons Gesetz

Die Arbeit ist beendet, wenn alle Vorr ate aufgebraucht sind.
53
6.3.1 Function-Point-Methode
Bei der Function-Point-Methode wird der Aufwand f ur ein neues Projekt aus den Produktanfor-
derungen berechnet. Dies erfolgt in sieben Schritten, bei denen ein spezielles Berechnungsfor-
mular ausgef ullt wird:
54
1. Schritt: Jede Produktanforderung wird eine der folgenden f unf Kategorien zugeordnet:
Eingabedaten
Abfragen
Ausgaben
Datenbest ande
Referenzdaten
2. Schritt: Kategorisierung der Anforderungen in Klassen
einfach
mittel
komplex
Dazu werden Tabellen, Beispiele, Richtlinien verwendet.
3. Schritt: Mit diesen Daten wird der erste Teil des Bewertungsbogens ausgef ullt und die Sum-
me berechnet. Diese Summe bildet die unbewerteten Gesamtpunkte.
4. Schritt: Weitere sieben Einussfaktoren werden gesch atzt und im Formular eingetragen. F ur
die Sch atzungen werden in der Regel rmeninterne Richtlinien verwendet. Aus diesen
Einussfaktoren wird die Summe gebildet.
5. Schritt: Im f unften Schritt wird aus den Einussfaktoren ein Faktor berechnet und mit den
unbewerteten Gesamtpunkten multipliziert. Das Ergebnis sind die Function Points.
6. Schritt: Anschliessend werden in einer Aufwandskurve, die eine Abbildung von Function
Points auf Mitarbeiter-Monate (MM) darstellt, die ben otigten MM f ur das Projekt abge-
lesen. Diese Kurve ist rmenspezisch und ergibt sich aus fr uheren Projekten, indem die
f ur die Projekte berechneten Function Points und die tats achlich ben otigten Mitarbeiter-
Monate eingetragen werden.
7. Schritt: Nach Beendigung des Projekts wird die Aufwandskurve mit den Werten des Projekts
f ur Function Points und ben otigte Mitarbeiter-Monate aktualisiert.
55

Uberblick uber die Vorgehensweise:

Aufwandskurve und Einufaktoren m ussen stets individuell angepat werden!
56
Vor- und Nachteile
Vorteile:
Bewertet werden Produktanforderungen, nicht LOC
In verschiedenen Phasen der Software-Entwicklung anwendbar, dadurch als iterative Me-
thode verwendbar:
1. Sch atzung auf Grundlage des Lastenhefts
2. Sch atzung auf Grundlage des Pichtenhefts
3. Sch atzung auf Grundlage des Entwurfs
gute Anpassbarkeit an unternehmensspezische Verh altnisse oder an neue Techniken und
Anwendungsbereiche durch

Anderungen von Kategorien, Einussfaktoren und Einussbe-
wertungen
leicht erlernbar und wenig zeitaufwendig
gute Sch atzgenauigkeit
Nachteile:
es kann nur der Gesamtaufwand gesch atzt werden
stark funktionsbezogen
Einuss von Qualit atsanforderungen fehlt
Einussfaktoren vermischen Projekt- und Produkteigenschaften
um Richtlinien f ur Einussfaktoren und die Aufwandkurve zu bilden, ist eine Datenbasis
aus bereits abgeschlossenen Projekten n otig
57
6.3.2 Faustregeln zur Kostensch atzung
Ein Ingenieurmonat (zu 10.000 DM) liefert etwa 350 Quellcodezeilen (ohne Kommentare) von
der Denition bis zur Implementierung.
Bei weitgehender Wiederverwendung existierender Software betr agt der Neuaufwand nur 25%
der Zeit und der Ressourcen von Neuentwicklungen
Sinnvolle Sch atzungen sind nur bei einer ausreichenden Datenbasis/Erfahrung zu erwarten
58
6.4 Projektplanung und Organisation
Zun achst m ussen die Arbeitspakete identiziert werden
Diese ergeben sich aus dem Lebenszyklus und dem Lastenheft
Der Umfang kann (grob) mit Hilfe eines Modells gesch atzt werden
Beispielprojekt: einfacher Compiler
2
Aufteilung des Projektes in Arbeitspakete:
2
aus Ghezzi, Software Engineering
59
6.4.1 PERT-Charts
Anordnung der Arbeitspakete in einem gerichteten Graphen
Die Aktivit aten, die ohne Zeitverlust aneinander anschlieen m ussen, bilden den kritischen Pfad
Am Ende erh alt man den fr uhestm oglichen Endtermin
60
6.4.2 Gantt-Diagramme
zur Zeitplanung von Arbeitspaketen
F ur komplizierte Verechtungen und Abh angigkeiten weniger geeignet als PERT-Charts, daf ur
aber sehr ubersichtlich.
61
Ein Beispiel aus der Lehrstuhlpraxis das JOP-Projekt




























T
3
-
T
4
:

T
u
t
o
r
i
a
l















































E
3
-
E
1
0
:

E
l
e
k
t
r
o
n
i
s
c
h
e

T
u
t
o
r
e
n




















T
1
:

E
n
t
w
u
r
f
T
u
t
o
r
i
a
l
(
1

P
M
)
T
2
:

G
r
u
n
d
g
e
r

s
t
T
u
t
o
r
i
a
l
(
2

P
M
)
T
3
:

I
n
h
a
l
t
T
u
t
o
r
i
a
l
(
3

P
M
)
T
4
:

B
e
i
s
p
i
e
l
e
T
u
t
o
r
i
a
l
(
2

P
M
)
T
6
:

J
a
v
a
-
A
u
f
g
a
b
e
n
T
u
t
o
r
i
a
l
(
2

P
M
)
P
3
:

J
a
v
a
-
A
u
f
g
a
b
e
n
P
r
a
k
t
o
m
a
t
(
2

P
M
)
E
1
:

E
n
t
w
u
r
f
E
l
.

T
u
t
o
r
e
n
(
1

P
M
)
E
6
:

"
F
o
r
m
a
t
i
e
r
u
n
g
"
(
1

P
M
)
E
8
:

"
D
o
k
u
m
e
n
t
a
t
i
o
n
"
(
1

P
M
)
E
7
:

"
K
o
m
p
l
e
x
i
t

t
"
(
2

P
M
)
E
5
:

"
B
e
z
e
i
c
h
n
e
r
"
(
1

P
M
)
E
2
:

E
i
n
r
i
c
h
t
e
n
J
a
v
a
-
P
a
r
s
e
r
(
1

P
M
)
P
1
:

J
a
v
a
-
A
n
p
a
s
s
u
n
g
P
r
a
k
t
o
m
a
t
(
1

P
M
)
P
2
:

I
n
t
e
g
r
a
t
i
o
n
E
l
.

T
u
t
o
r
e
n

+

P
r
a
k
t
o
m
a
t
(
2

P
M
)
T
5
:

I
n
t
e
g
r
a
t
i
o
n
E
l
.

T
u
t
o
r
e
n

+

B
e
i
s
p
i
e
l
e
(
2

P
M
)
P
r
o
j
e
k
t
b
e
g
i
n
n
+
1

M
o
n
a
t
+
3

M
o
n
a
t
e
+
1
0

M
o
n
a
t
e
+
1
2

M
o
n
a
t
e
+
1
4

M
o
n
a
t
e
W

r
z
b
u
r
g
P
a
s
s
a
u
K
1
:

P
r
o
j
e
k
t
-
K
o
o
r
d
i
n
a
t
i
o
n
(
2

P
M
)
T
7
:

I
n
t
e
g
r
a
t
i
o
n
T
u
t
o
r
i
a
l

+

P
r
a
k
t
o
m
a
t
(
1

P
M
)
E
9
:

"
T
e
s
t
"
(
2

P
M
)
K
2
:

K
o
o
r
d
i
n
a
t
i
o
n
(
2

P
M
)
E
3
:

"
M
u
s
t
e
r
l

s
u
n
g
"
(
2

P
M
)
E
4
:

"
S
c
h
n
i
t
t
s
t
e
l
l
e
"
(
2

P
M
)
62
6.5 Checkliste: Durchf uhrbarkeitsstudie
F ur Praktika ist die Durchf uhrbarkeit ex cathedra gegeben, so da eine eigene Studie in der Regel
entf allt.
Dennoch sollten die folgenden Punkte, wenn schon nicht als Teil der Durchf uhrbarkeitsstudie, in
den nachfolgenden Dokumenten behandelt werden.
Ist ein Zeitplan enthalten?
Der Zeitplan mu die

Uberg ange zwischen den einzelnen Phasen mit Datum enthalten.
Sind Autoren und Phasenverantwortlichen aufgef uhrt?
F ur jede Phase ist ein Gruppenmitglied zu benennen, das f ur die Termineinhaltung und die
geforderten Dokumente verantwortlich zeichnet.
Sind Risiken hinreichend abgesch atzt?
Was passiert, wenn einzelne Gruppenmitglieder ausfallen oder unzureichende Arbeit lie-
fern?
63
6.6 Checkliste: Allgemeine Anforderungen
an Dokumente
Dokumente im Rahmen des Praktikums werden anhand der folgenden Anforderungen beurteilt.
6.6.1 Allgemeines
Fehlerfrei schreiben
Rechtschreibfehler werden durch handels ubliche Korrekturprogramme erkannt, grammatikali-
sche Fehler durch lautes Vorlesen.
Wer sich nicht sicher ist, soll einen Korrektor nden.
Verbliebene Fehler sind Zeichen f ur mangelnde Sorgfalt und zeigen so Geringsch atzung f ur den
Leser.
Auch Praktikums-Betreuer haben Anspruch auf Wertsch atzung.
Gliederung
Die Gliederung sollte ausgewogen sein; d.h. die L ange der einzelnen Abschnitte und die Anzahl
der Unterpunkte sollten nicht grob voneinander abweichen.
Die Gliederungstiefe soll 3 nicht uberschreiten. Unsch on:
1.1 Motivation
1.1.2 Aufgabenstellung
1.1.2.1 Einf uhrung
1.1.2.1.1 Denitionen
1.1.2.1.1.1 Allgemeines
Die Abschnitt uberschriften m ussen zum Inhalt passen und umgekehrt.
Typographie

Uberschriften, Schl usselbegriffe sollen satztechnisch hervorgehoben werden.

Typographie ist bewut und sparsam anzuwenden. Eine
Vielzahl von Schriftarten und -Gr oen
macht die Seite unruhig und erschwert das Lesen.
64
6.6.2 Die W orter
Weg mit den Adjektiven!
Adjektive nur einsetzen, wenn sie zur Pr azision beitragen.
Klassische Gegenbeispiele:
weie Schimmel
schwere Verw ustungen (wer h atte je leichte Verw ustungen gesehen?)
In unserem Kontext:
Eine wohl organisierte Struktur ist ein integrierter Bestandteil eines guten Entwurfs.
Gegenfrage: Was w aren eine unorganisierte Struktur, ein nicht integrierter Bestandteil?
Besser:
Ein guter Entwurf ist gut strukturiert.
Soso. Wer h atte das gedacht?
65
Her mit den Verben!
Verben tragen die Bedeutung im Satz.
Niemals ein Substantiv verwenden, wo ein Verb denselben Dienst versieht.
Im Rundfunkvortrag:
3
Wir warnen Sie auch davor, unangebracht substantivische an Stelle verbaler Kon-
struktionen zu gebrauchen:

nach Instandsetzung der Bauten,

aus Gr unden der

Zug anglichmachung eines Geb audes,

beim Unterbleiben einer Inangriffnahme des

Projektes.
In unserem Kontext:
Die Implementierung der Funktion wurde in Form eines abstrakten Datentyps vor-
genommen.
also:
Die Funktion wurde als abstrakter Datentyp implementiert.
Arm an Saft und Kraft ist auch das Passiv Lieblingsinstrument der B urokratie, bei jedem
Verst andlichkeitstest im Hintertreffen.
Aktive Variante:
Wir implementierten die Funktion als abstrakten Datentyp.
3
Fritz Geratewohl, Technik und

Asthetik des Rundfunkvortrags, 1931
66
Das deutsche Wort
Richten Sie sich nach dem Sprachschatz des Lesers!
Wo es pr azise deutsche Fachbegriffe gibt, sind sie den englischen vorzuziehen.
Statt:
Nach jeder Cursor-Bewegung wird das Access-File geupdated.
also:
Nach jeder Cursor-Bewegung wird die Zugriffsdatei aktualisiert.
oder, je nach Zielpublikum:
Nach jeder Bewegung der Schreibmarke wird die Zugriffsdatei auf den neuesten
Stand gebracht.
Aktive Alternative:
Nach dem Bewegen des Cursors aktualisiert das Programm die Zugriffsdatei.
Wie im gesamten Software Engineering haben der Autor und sein Ego vor den Bed urfnissen des
Anwenders zur uckzustehen.
67
6.6.3 Die S atze
Kurze S atze!
Der h augste, der klassische Rat an jeden, der verstanden werden will:
Schreibe kurze S atze!
Was ist ein langen S atzen falsch? Ein Beispiel:
4
Studieninhalte werden als Konsumgut aufgefat. Ein Merkmal von Konsum scheint
mir zu sein, da man sich zwar uber das, was man konsumiert, ein St uck weit zu
denieren trachtet und dies sicherlich auch tut, aber nur auf einer aueren, manipu-
lativen Ebene.
Was will uns der Autor damit sagen? E. A. Rauter meint:
5
Um kurze S atze schreiben zu k onnen, mu man erst gearbeitet haben. In langen
S atzen bleibt die Unwissenheit des Autors l anger verborgen ihm selbst und dem
Leser. Der lange Satz ist meist eine Zuucht f ur den, der sich eine Sache nicht erar-
beitet hat. Kurze S atze kann man nicht schreiben, wenn man nicht genau Bescheid
wei.

Uberspitzt (Ludwig Wittgenstein):

Alles, was man wei, nicht blo rauschen und brausen geh ort hat, l at sich in drei
Worten sagen.
In diesem Sinne eine verbesserte Version:
Studenten fassen den Studieninhalt als Konsumgut auf und denken nicht dar uber
nach, wie sie selbst zum Studieninhalt stehen.
Anhaltspunkt f ur Verst andlichkeit:
6
Bis zu 13 W orter pro Satz: sehr leicht verst andlich
1418: leicht verst andlich
1925: verst andlich
2530: schwer verst andlich
31 und mehr: sehr schwer verst andlich
4
Christian Schl uter,

Das Sein als Schein, Frankfurter Rundschau 1998-15-10, S. 6, zur Frage, ob Studenten f ur
Scheine oder f ur die Wissenschaft studieren
5
E. A. Rauter, Vom Umgang mit W ortern, M unchen 1980
6
Ludwig-Reimers-Schema, zitiert nach: Wolf Schneider, Deutsch f ur Pros
68
Hauptfeind: Der Schachtelsatz
Schachtels atze vermeiden. In der Karikatur:
Denken Sie, wie sch on der Krieger, der die Botschaft, die den Sieg, den die Athener
bei Marathon, obwohl sie in der Minderheit waren, nach Athen, das in groer Sorge,
ob es die Perser nicht zerst oren w urden, schwebte, erfochten hatten, verk undete,
brachte, starb!
Im wirklichen Leben:
Als Vorbedingung der Funktion gilt, da alle ubergebenen Argumente, wobei zu
ber ucksichtigen ist, da das letzte Argument, der Pr ufmodus, optional ist mit einer
Vorgabe von false, im angegebenen Wertebereich liegen m ussen.
Besser geht das in drei kurzen S atzen:
Als Vorbedingung m ussen alle Argumente im angegebenen Wertebereich liegen. Der
Pr ufmodus kann weggelassen werden. Ist dies der Fall, so gilt der Pr ufmodus als
abgeschaltet.
Noch besser: Satzkn auel durch Tabellen und Aufz ahlungen gliedern. Dies ist ein zentrales Prinzip
f ur technische Dokumentationen.
Hier:
Vorbedingungen:
1. Alle Argumente m ussen im angegebenen Wertebereich liegen.
2. Der Pr ufmodus kann weggelassen werden. Ist dies der Fall, so gilt der Pr ufmo-
dus als abgeschaltet.
Mark Twain meint:
Ich w urde jeden Menschen, ob hoch oder niedrig, ersuchen, seine Geschichte klar
und einfach zu entwickeln. Sonst soll er sich auf sein Redekn auel setzen und gef alligst
Ruhe halten. Verst oe gegen dieses Gesetz w urde ich mit dem Tode ahnen.
7
7
Mark Twain, Die schreckliche deutsche Sprache, S. 51, Manuscriptum 1998
69
Redundanz vermeiden
In journalistischen Texten und im gesprochenen Wort (wie in Vorlesungen) gilt: Je komplizierter
das Thema, um so mehr Redundanz.
Erst sage ich den Leuten, was ich ihnen sagen werde. Dann sage ich es ihnen. Dann
sage ich ihnen, was ich ihnen gerade gesagt habe.
Erfolgsrezept eines amerikanischen Predigers
In technischen Texten aber schadet Redundanz der Pr azision!
Grundsatz: Werden Dinge aus verschiedenen Blickwinkeln betrachtet, sorgt die Vielfalt f ur gr oe-
re Pr azision.
Ansonsten aber: Alles weglassen, was vorausgesetzt werden kann oder sich aus dem Gesagten
ergibt.
Statt:
Die Klasse A ist eine Unterklasse von B, d.h. sie erbt alle Attribute.
heit es:
A ist eine Unterklasse von B.
Nicht aus allgemein zug anglichen Werken abschreiben!
Der Entwurf erf ullt alle Grundprinzipien des Software Engineering, n amlich: 1)
Strenge und Formalit at, 2) Separation der Interessen . . . .
Stattdessen zitieren:
Der Entwurf erf ullt alle Grundprinzipien des Software Engineering (Ghezzi, 1991).
Allgemeinpl atze sind nur im ersten Satz der ersten Seite zul assig:
Schachspielen ist schwer. Unser Schachprogramm macht es Ihnen leicht. . .
70
F ullw orter vermeiden
Streichen von F ullw ortern hilft, S atze zu verk urzen:
auch doch eben
geradezu reichlich eigentlich
ausgerechnet vielleicht interessant
weitgehend ein St uck weit im allgemeinen
insbesondere irgendwie in diesem Zusammenhang
sowohl als auch sozusagen relativ
praktisch quasi sicherlich
unzweifelhaft voll und ganz mehr oder weniger . . .
Ein Beispiel:
8
Ich mu meine Bezugssysteme thematisieren und da diese dann auch und gerade
gesellschaftliche (und eben auch soziologische) sein k onnen, m ussen und werden, ist
praktisch unabwendbar.
Umpf! Sollte dies etwa heien:
Wir m ussen mal dar uber reden.
Vergleiche hierzu:
9
Die Kunst, geisteswissenschaftlich unwiderlegbar zu werden, besteht darin, so lange
zu abstrahieren, bis der endlich gefundene Begriff alle konkreten Angriffs achen
verloren hat damit freilich auch jede Farbe, alle Kraft, jeden praktischen Sinn.
Unser Ziel: Pr azision! K urze! Und wenn nach dem Streichen von F ullw ortern irgendwie weitge-
hend Banalit aten ubrig bleiben den Satz als Ganzes streichen, auch und gerade wenn es relativ
weh tut.
8
Schl uter, a.a.O.
9
Rudolf Walter Leonhart, Das Deutsch des deutschen Fernsehens, Die Zeit, 1980-12-05
71
6.6.4 Wie wendet man diese Regeln an?
Wolf Schneider, Leiter der Journalistenschule von Gruner + Jahr, h alt es so:
10
Laut lesen.
Dabei oder danach:
die meisten F ullw orter und m oglichst viele Adjektive streichen
bei fahrl assigen Wiederholungen andere W orter einsetzen
rote Schlangenlinien an Stellen des Mivergn ugens machen
Den logischen Ablauf pr ufen.
Den dramaturgischen Aufbau pr ufen.
Alle Stellen uberarbeiten, die eine Schlangenlinie bekommen haben.
Die Passagen uberarbeiten, die den Gegenlesern mifallen haben.
Noch mal laut lesen.
10
Wolf Schneider, Deutsch f ur Pros, Stern-Buch, 1984
72
Kapitel 7
Software-Denition: Pichtenheft
7.1 Die Produkt-Denition
Die Anforderungen an eine neue Software sind von ihrer Natur her vage, verschwommen, unzu-
sammenh angend, unvollst andig und widerspr uchlich.
Ziel der Software-Spezikation ist es, aus diesen Anforderungen eine m oglichst vollst andige
konsistente und eindeutige Produkt-Denition zu erstellen, die Grundlage f ur das zu erstellende
Produkt ist.
Zur Produkt-Denition geh oren vier Teile:
Das Pichtenheft oder Anforderungsdokument.
Legt (verbal) die Anforderungen an die fertige Software fest.
Das Produkt-Modell.
Speziziert den Aufbau und wichtige Eigenschaften des Produkts. Dies geht mit
semi-formalen Denitionsverfahren, die imZusammenspiel mit demBenutzer erstellt
werden, oder mit
formalen Spezikationsverfahren, die als pr azise Grundlage f ur die Implementierung
dienen.
Die Beschreibung der Benutzungsober ache.
Wird typischerweise aus den Erfahrungen mit Prototypen gewonnen.
Das Benutzerhandbuch.
Wird gew ohnlich weit vor der eigentlichen Implementierung erstellt.
73
7.2 Das Pichtenheft
Das Pichtenheft legt (verbal) die Anforderungen an die fertige Software fest.
7.2.1 Typischer Aufbau
(nach Balzert, Lehrbuch der Software-Technik)
1 Zielbestimmung
Mukriterien
Welche Leistungen sind f ur das Produkt unabdingbar?
Wunschkriterien
Welche Leistungen sind erstrebenswert?
Abgrenzungskriterien
Welche Ziele sollen bewut nicht erreicht werden?
2 Produkt-Einsatz
Anwendungsbereiche
Zu welchem Zweck wird das Produkt eingesetzt?
Zielgruppen
Von wem soll das Produkt eingesetzt werden? Welches Qualikationsniveau des Be-
nutzers wird vorausgesetzt?
Betriebsbedingungen
Wie ist die physikalische Umgebung? Die Betriebszeit? Aufsicht?
3 Produkt-Umgebung
Software
Welche Software-Systeme sollen auf der Zielmaschine zur Verf ugung stehen?
Hardware
Welche Hardware-Komponenten werden ben otigt?
Orgware
Welche organisatorischen Bedingungen m ussen erf ullt sein?
4 Produkt-Funktionen
Funktion 1
. . .
Funktion 2 usw.
Was leistet das Produkt aus Benutzersicht?
Wichtig: Nicht das Wie, sondern das Was wird hier deniert.
74
Jede Einzelanforderung mu gesondert gekennzeichnet sein (etwa als /F10/, /F20/,
usw.)
5 Produkt-Daten
Daten 1
. . .
Daten 2 usw.
Was speichert das Produkt (langfristig) aus Benutzersicht?
Auch hier sollten die zu speichernden Daten gesondert gekennzeichnet sein (etwa als
/D10/, /D20/, usw.)
Hier werden h aug auch bereits Aussagen uber das Datenformat getroffen.
6 Produkt-Leistungen
Welche zeit- und umfangsbezogenen Anforderungen gibt es?
Kennzeichnung als /L10/, /L20/, usw.
7 Benutzungsober ache
Was sind die grundlegenden Anforderungen an die Benutzerober ache?
Umfat Bildschirmlayout, Drucklayout, Tastaturbelegung, Dialogstruktur, usw.
8 Qualit ats-Zielbestimmung
Verweis auf g angige Normen und Standards
9 Globale Testszenarien und Testf alle
Testfall 1
. . .
Testfall 2 usw.
Was sind typische Szenarien, die das Produkt erf ullen mu?
Ein Szenario sollte eine Schritt f ur Schritt-Anleitung f ur den Tester sein:
/T10/ W ahlen Sie das Objekt 1 aus /F10/.
/T20/ L oschen Sie es /F25/ . . .
Die Testf alle (gekennzeichnet durch /T10/, /T20/, usw.) sollen die Anforderungen
vollst andig abdecken.
Testszenarien sind typischerweise Grundlage f ur den Abnahmetest.
10 Entwicklungs-Umgebung
Software
75
Hardware
Orgware
Welche Umgebung wird f ur die Entwicklung ben otigt?
11 Erg anzungen
Hierunter fallen
Spezielle, nicht abgedeckte Anforderungen
Installationsbedingungen
Zu ber ucksichtigende Normen, Lizenzen, Patente
Glossar
Denition aller wichtigen Begriffe zur Sicherstellung einer einheitlichen Terminologie
Glossar soll nicht Allgemeinpl atze denieren (etwa

CPU,

Java), sondern Begriffe aus

dem Anforderungsbereich.
Unabdingbare Voraussetzung f ur sprachliche Pr azision
76
7.2.2 Gliederung
Beispiel zu Produkt-Funktionen:
Graphischer Editor informal speziziert
Unstrukturierter Text
Stark durchgegliederter Text mit Begr undung
Beschreibung fundamentaler Datenstrukturen:
77
Beschreibung von entsprechenden Operationen:
Pichtenhefte f ur groe Projekte k onnen mehrere hundert bis tausend Seiten umfassen!
78
7.3 Basiskonzepte zur Produkt-Modellierung
F ur das Pichtenheft m ussen geeignete Basiskonzepte zur Modellierung des Gesamt-Systems
verwendet werden.
Je nach Sicht auf das Gesamt-System unterscheiden wir:
Funktionale Modellierung
Beschreibt die funktionale Hierarchie und den Informationsu.
Konzepte: Funktionsbaum, Datenudiagramm
Datenorientierte Modellierung
Beschreibt die Datenstrukturen und deren Beziehungen.
Konzepte: Syntax-Diagramm, Entity-Relationship-Diagramm,
Data Dictionary
Algorithmische Modellierung
Beschreibt das Verhalten in Form von Kontrollstrukturen.
Konzepte: Pseudocode, Struktogramm, Jackson-Diagramm
Erst in der Implementierungsphase!
Regelbasierte Modellierung
Beschreibt das Verhalten in Form von Wenn-Dann-Regeln.
Konzepte: Regeln, Entscheidungstabelle
Zustandsorientierte Modellierung
Beschreibt die Zust ande und die

Uberg ange.
Konzepte: Endlicher Automat, Petri-Netz
Objektorientierte Modellierung
Beschreibt die auftretenden Klassen und Objekte und deren Beziehungen.
Konzepte: Klassendiagramm
Szenariobasierte Modellierung
Beschreibt die Interaktion zwischen Komponenten (= Objekten).
Konzepte: Interaktionsdiagramm
79
7.4 Funktionale Modellierung
7.4.1 Funktionsbaum
Bew ahrtes Konzept zur systematischen Gliederung von Funktionen
Gibt erste Hinweise f ur die Dialoggestaltung
Beispiel: Kundenverwaltung
Der Funktionsbaum ber ucksichtigt nur die funktionale Sicht; Daten werden ignoriert.
Als Top-Down-Methode unterst utzt der Funktionsbaum nicht das Finden geeigneter Abstraktio-
nen, was zu mehrfacher Implementierung f uhren kann.
Im Beispiel k onnten etwa die Verwaltung von Kundenstamm und Firmenstamm vereinheitlicht
werden.
80
7.4.2 Datenudiagramm
Beschreibt, welche Informationen von wo nach wo durch das System ieen
Notation (nach deMarco, 1979): Structured Analysis
Geschlossene Rechtecke sind Schnittstellen zur Umwelt (Informationsquellen und/oder -senken)
Pfeile sind Daten usse zwischen Schnittstellen, Funktionseinheiten und Datenspeichern
Kreise sind Funktionseinheiten, die ankommende Daten usse in ausgehende Daten usse ver-
wandeln
Offene Rechtecke sind Datenspeicher, auf die lesend und schreibend zugegriffen werden kann
Beispiel: Beschreibung eines Bibliothekssystems
1
1
aus Ghezzi et al., Fundamentals of Software Engineering
81
Verfeinerung dieses Beispiels:
Daten usse von Grobdiagrammen m ussen in verfeinerten Diagrammen erhalten bleiben!
82
Beispiel: Kundenverwaltung
2
2
aus Balzert, Lehrbuch der Software-Technik
83
Beispiel: Entwurf eines Reportgenerators
3
Hier alternative Notation:
Pfeile: Datenstr ome
Runde K astchen: Funktionseinheiten
Eckige K astchen: Datenspeicher
Kreise: Ein-/Ausgabe
3
aus Sommerville, Software Engineering
84
7.5 Datenorientierte Modellierung
7.5.1 Entity-Relationship-Diagramm
Beschreibt die permanent gespeicherten Daten und ihre Beziehungen.
Rechteck: Entit atsmenge
Menge anhand ihrer Eigenschaften unterscheidbarer Objekte
Kreis: Attribut
eine gemeinsame Eigenschaft aller Objekte einer Entit atsmenge
Raute: Assoziation
Menge gleichartiger Beziehungen zwischen Entit aten
Doppelraute: Vererbung
eine Entit atsmenge

erbt alle Attribute der bezogenen Entit atsmenge

Beispiel: Zusammengesetzte Symbole
4
4
aus Sommerville, Software Engineering
85
7.5.2 Syntax-Diagramme
Die lexikalischen Einheiten einer Sprache (z.B. der gespeicherten Daten) werden durch regul are
Ausdr ucke beschrieben
Beispiel: Bezeichner und numerische Konstanten in Pascal
5
5
aus K. Jensen, N. Wirth, Pascal Manual and Report
86
7.5.3 Regul are Ausdr ucke
Regul are Ausdr ucke k onnen auch textuell notiert werden.
Es bedeuten:
Folge X Y erst X, dann Y
Alternative (X [ Y ): entweder X oder Y
Wiederholung X

: 0 oder mehr Auftreten von X

Wiederholung X
+
= X X

: 1 oder mehr Auftreten von X

Option X
?
= (X [ ): 0 oder 1 Auftreten von X
Beispiel: Aufbau von Bezeichnern in textueller Form
identier = letter(letter [ digit)

unsigned-integer = digit
+
unsigned-number = unsigned-integer(.digit
+
)
?
(E(+ [ -)
?
unsigned-integer)
?
unsigned-constant = constant-identier [ unsigned-number [
NIL [ character
+

constant =
_
(+ [ -)
?
(constant-identier [ unsigned-number)
_
[
character
+

Aus solchen Beschreibungen lassen sich automatisch endliche Automaten konstruieren, die Be-
standteile einer Eingabe erkennen und verarbeiten (siehe auch Abschnitt 7.6.1).
87
7.6 Zustandsorientierte Modellierung
7.6.1 Endliche Automaten
Ein endlicher Automat beschreibt ein System als eine (endliche) Menge von Zust anden.
Die

Uberg ange zwischen den einzelnen Zust anden sind an bestimmte Bedingungen gekn upft.
Ist die Bedingung f ur den

Ubergang erf ullt, geht das System in einen neuen Zustand uber.
Beispiel: Stellen einer Digitaluhr
6
6
aus Balzert, Lehrbuch der Software-Technik
88
Beispiel: Mikrowellenofen
7
Zust ande bzw.

Uberg ange entsprechen realen Schaltern/Sensoren/Lampen
Zust ande und

Uberg ange m ussen separat erl autert werden:
7
aus Sommerville, Software Engineering
89
Beispiel: Grobstruktur einer Prozekontrolle in einer chemischen Fabrik
8
Dieses Beispiel illustriert, wie Automaten verfeinert werden k onnen, indem ein Zustand durch
einen ganzen Teilautomaten ersetzt wird.
Nat urlich m ussen die urspr unglichen

Uberg ange aus/in einen verfeinerten Zustand sich im neuen
Teilautomaten wiedernden! Diese Bedingung ist im folgenden Beispiel verletzt.
8
aus Ghezzi, Fundamentals of Software Engineering
90
7.6.2 Statecharts
Erlauben die Beschreibung nebenl auger Zust ande
91
7.6.3 Petri-Netze
Beschreiben parallele und asynchrone Systeme
Petri-Netze
sind gerichtete Graphen, deren Knoten entweder Stellen oder Transitionen sind
Stellen
dienen als Aufnahmebeh alter f ur Marken
Transitionen
sind die

Ubergabewege f ur Marken
Marken
beschreiben durch ihre Anzahl und Position den Zustand eines Petri-Netzes
Der Bewegungsablauf von Marken im Netz wird durch die Schaltregel festgelegt:
Eine Transition t kann schalten, wenn jede Eingabestelle von t wenigstens eine Marke
enth alt
Schaltet eine Transition, wird aus jeder Eingabestelle eine Marke entfernt und jeder Aus-
gabestelle eine Marke hinzugef ugt
92
Bedingungs/Ereignis-Netz
Einfachste Form von Petri-Netzen: Jede Stelle kann genau eine oder keine Marke enthalten
Weitere Schaltregel:
Eine Transition t kann schalten, wenn jede Eingabestelle von t eine Marke enth alt und jede
Ausgabestelle von t leer ist
Beispiel: Best ucken von Leiterplatten durch zwei Roboter
9
9
aus Balzert, Lehrbuch der Software-Technik
93
94
Welche der beiden Transitionen feuert (und welcher Roboter die Leiterplatte ergreift), ist nicht
deterministisch!
Weitere Petri-Netze:
Stellen/Transitions-Netze
Jeder Kante ist eine maximale Kapazit at zugeordnet; jede Transition mu entsprechend
der Kapazit at Marken hinzuf ugen und entfernen
Pr adikat/Transitions-Netze
Marken sind unterschiedlich gef arbt; Pr adikate an den Transitionen geben an, unter wel-
chen Bedingunen die Transitionen schalten d urfen
Hierarchische Petri-Netze
zur Strukturierung groer Systeme
Zeitbehaftete Petri-Netze
mit

Verharren der Marken auf Transitionen

95
7.7 Regelbasierte Modellierung
7.7.1 Entscheidungstabellen
Entscheidungstabellen sind eine Matrix zur Festlegung von unter bestimmten Bedingungen aus-
zuf uhrenden Aktionen
Name der ET Regelnummern
wenn Bedingungen Bedingungsanzeiger
dann Aktionen Aktionsanzeiger
Obere H alfte der Matrix: Bedingungsteil. Die Zeilen sind mit Bedingungen markiert
Untere H alfte der Matrix: Aktionsteil. Die Zeilen sind mit auszuf uhrenden Aktionen markiert
Jede Spalte entspricht einer Bedingungskombination
Entweder nur ja/nein Eintr age oder differenzierte Eintr age
Vollst andigkeit (jede Bedingungskombination mu abgedeckt sein) kann automatisch gepr uft
werden
Widerspruchsfreiheit (es d urfen keine sich widersprechenden Aktionen ausgel ost werden)
Kann nicht automatisch gepr uft werden, denn ein Rechner wei nichts uber die Semantik
der Aktionen
Aus einer Entscheidungstabelle kann automatisch ein Programm(ger ust) erzeugt werden.
96
Beispiel: Bibliothekssystem
10
10
aus Kimm et al. Einf uhrung in Software Engineering
97
7.8 Objektorientierte Modellierung
Beschreibt ein System mit Hilfe von Objekten, die anhand ihrer Eigenschaften in Klassen zu-
sammengefat werden.
Neben Eigenschaften kennen Objekte auch Methoden: Funktionen, die sich implizit auf das je-
weilige Objekt beziehen.
Die Klassenhierarchie dr uckt uber Vererbung gemeinsame Eigenschaften und Methoden aus:
Detaillierte Beschreibung in Kapitel 11 (Objektorientierter Entwurf)!
98
7.9 Szenariobasierte Modellierung
Dient der schematischen Veranschaulichung zeitbasierter Vorg ange
Wird in der objektorientierten Modellierung benutzt, um die Kommunikation zwischen Objekten
darzustellen
Hilfreich zur Darstellung von Szenarien und nebenl auger Prozesse
Beispiel: Ein Benutzer positioniert einen Roboter mit Kommandos
11
11
aus Balzert, Lehrbuch der Software-Technik
99
7.10 Checkliste: Pichtenheft
Das Pichtenheft im Rahmen des Software-Entwicklungs-Praktikums wird anhand der folgen-
den Anforderungen beurteilt.
Wenn keine eigene Durchf uhrbarkeitsstudie gefordert war, m ussen dessen Inhalte (Zeitplan und
Phasenverantwortliche; vergl. Abschnitt 6.5) hier aufgef uhrt werden.
Ist das Pichtenheft pr azise, vollst andig und konsistent?
Hier helfen eine gute Gliederung und ein Glossar.
Sind alle Anforderungen gem a Skript aufgef uhrt?
Siehe hierzu:
Abschnitt 6.2, f ur den typischen Aufbau eines Lastenhefts,
Abschnitt 7.2.1 f ur den typischen Aufbau eines Pichtenhefts.
Wenn von den Beispiel-Gliederungen abgewichen wird, ist dies zu begr unden.
Sind die Hauptfunktionen, Daten, Leistungen gekennzeichnet?
Balzert schl agt vor, die Leistungen mit /L10/, /L20/, . . . zu kennzeichnen (vergl. Abschnitt 7.2.1).
Dies ist wichtig, um sich in sp ateren Dokumenten darauf beziehen zu k onnen.
Sind die Anforderungen begr undet?
Nach Absprache mit dem Auftraggeber sollten alle Anforderungen begr undet sein. Dies
erleichtert das Verst andnis erheblich.
Werden geeignete Modellierungsverfahren eingesetzt?
Alle zentralen Aspekte des Systems m ussen pr azise modelliert sein.
Abschnitt 7.3 enth alt eine Liste der m oglichen Modellierungen.
Ist die Verwendung externer Ressourcen dokumentiert?
Hierzu geh oren Formate von Eingabedateien, Protokolle, Interaktion mit externen Pro-
grammen und ahnliches.
Ist die Systemevolution ber ucksichtigt?
Hierunter f allt, was sich in Zukunft andern k onnte.
Decken die Testf alle die Anforderungen ab?
Jede Anforderung mu (durch einen Testfall) validierbar sein.
Gibt es ein Glossar?
Das Glossar soll alle wesentlichen Begriffe der Aufgabenstellung pr azisieren.
100
Begriffe im Glossar sind als solche zu verwenden d.h. keine Synonyme, auch nicht zu
stilistischen Zwecken.
Beispiel:
Die Ausleuchtung bestimmt, wie die Weiche dargestellt wird. Ist die Darstellung

Alarm, so wird die Weiche rot blinkend gezeichnet. Die Abbildung richtet sich
nach der Aufl osung des Bildschirms.
Was ist der Unterschied zwischen

Ausleuchtung,

Darstellen,

Abbilden,

Zeichnen?
Mit zwei Glossar-Eintr agen

Ausleuchtung und

Darstellung wird der Text sofort klarer:

Die Ausleuchtung bestimmt, wie die Weiche dargestellt wird. Ist die Ausleuch-
tung

Alarm, so wird die Weiche rot blinkend dargestellt. Die Darstellung rich-
tet sich nach der Aufl osung des Bildschirms.
Das Glossar sollte nach Stichworten alphabetisch sortiert sein.
Gibt es einen Index?
Bei umfangreichen Dokumenten ist ein Index (am Ende des Dokuments) hilfreich.
101
Kapitel 8
Gestaltung von Benutzer-Handb uchern
Das Benutzer-Handbuch ist in der Regel der erste Kontakt eines Benutzers mit einem neuen
Software-System.
Das Handbuch ist sozusagen die Visitenkarte des Systems; entsprechend sorgf altig sollte es ge-
staltet sein.
8.1 Aufgabe
Das Benutzer-Handbuch soll die Handhabung und das Verhalten des Produkts m oglichst vollst andig
und fehlerfrei beschreiben.
Es mu m oglich sein, das Produkt nur anhand des Handbuchs zu bedienen.
8.2 Benutzer-Kategorien
Anordnung und Aufbau eines Handbuchs werden im wesentlichen durch die Adressaten be-
stimmt. Man unterscheidet drei Kategorien:
Anf anger haben keine oder wenig Erfahrungen mit Computersystemen im allgemeinen
und dem Produkt im speziellen.
Experten haben viel Erfahrungen mit Computersystemen im allgemeinen, aber wenig Er-
fahrungen mit dem speziellen Produkt.
Fortgeschrittene liegen irgendwo zwischen Anf angern und Experten; sie haben vielleicht
schon ahnliche Produkte benutzt.
102
8.3 Handbuchtypen
F ur jede Benutzer-Kategorie gibt es eigene Handbuch-Typen:
Trainings-Handbuch (Tutorial)
Referenz-Handbuch
Referenzkarte
Benutzer-Leitfaden (user guide)
8.3.1 Trainings-Handbuch (Tutorial)
F ur Anf anger am besten geeignet.
Ein Trainings-Handbuch
ist als Kurs oder Trainingsprogramm organisiert
ist nach Aufgaben gegliedert:
Das Handbuch beschreibt die Wege zur Erreichung von Arbeitszielen.
Beispiel: So buchen Sie eine Anmeldung
Die n otigen Arbeitsabl aufe bestimmen die Gliederung.
mu von Anfang bis Ende vollst andig durchgearbeitet werden
erfordert direkte Arbeit mit demProdukt, d.h. der Leser f uhrt die Anweisungen des Trainings-
Handbuchs aus
vermittelt rasch Erfolgserlebnisse
ist f ur fortgeschrittene Benutzer und Experten zu elementar
8.3.2 Referenz-Handbuch
F ur Experten bestimmt.
Ein Referenz-Handbuch
erm oglicht schnellen Zugriff auf spezische Information
ist nach Produktaufbau gegliedert:
Alle Funktionen und Bestandteile werden in der Reihenfolge beschrieben, die sich
aus der Struktur des Produktes ergibt.
Beispiel: Die Funktion

Anmeldungen bearbeiten
103
Es wird beschrieben, was das Produkt kann. . .
. . . und nicht, wie man Arbeitsziele mit dem Produkt erreicht
bietet vollst andige Informationen zu allen Produktfunktionen
unterstellt, da der Benutzer mehr wei, als er tun will
8.3.3 Referenzkarte
Ebenfalls f ur Experten bestimmt.
Eine Referenzkarte
fat die wesentlichen Informationen der wichtigsten oder h augsten Funktionen zusam-
men.
ist m oglichst kompakt (nicht mehr als eine A4-Seite)
Abwandlung: die Referenztasse.
8.3.4 Benutzer-Leitfaden (user guide)
F ur fortgeschrittene Benutzer gedacht.
Ein Leitfaden
ist eine Mischform aus Trainings- und Referenzhandbuch
mu simultan die Bed urfnisse beider Benutzergruppen, Anf anger und Experten, erf ullen.
besteht typischerweise aus zwei Teilen:
Die aufgabenorientierte Arbeitsanleitung dient zum Einarbeiten.
nicht vollst andig
erlaubt das Arbeiten mit Grundfunktionen.
Der Referenzteil dient zum sp ateren Nachschlagen.
erlaubt es, sich die weiteren Funktionen zu erschlieen.
erlaubt es, bereits bekannte Informationen zu uberschlagen
darf aber nicht davon ausgehen, da der Leser Systemdetails bereits kennt
bei einfachen Systemen das einzige Handbuch
Bei umfangreichen Systemen gibt es oft alle vier Handbuch-Typen!
104
8.4 Aufbau eines Benutzer-Handbuchs
F ur Benutzer-Handb ucher l at sich kein generelles Gliederungsschema wie etwa Pichtenhefte
(Abschnitt 7.2.1)vorgeben. Neben dem sachlichen Inhalt geh oren aber bestimmte Teile in jedes
Handbuch:
Vorwort
Enth alt Adressatenkreis, Anwendungsbereich,

Anderungen gegen uber Vorversionen.
Ziel: der Leser mu nach den ersten Seiten wissen, ob Produkt und Handbuch f ur ihn und
seine Anwendung bestimmt sind.
Manche Leser uberbl attern das Vorwort; deshalb geh oren unverzichtbare Informationen in
die Einleitung.
Inhaltsverzeichnis
Einf uhrung
Dient in der Regel als Gebrauchsanleitung, die uber den Aufbau und den Umgang mit dem
Handbuch informiert.
Beschreibt oft auch
die Konguration, die f ur das Produkt erforderlich ist (evtl. in eigenem Kapitel).
Zielgruppe
Vorkenntnisse zum Verstehen des Handbuchs
Insgesamt soll die Einf uhrung kurz sein.
Installation
Beschreibt, was der Benutzer tun mu, um das Produkt in Betrieb zu nehmen.
Wird nur selten gelesen, kann deshalb in den Anhang (dann mu aber in der Einf uhrung
darauf verwiesen werden).
Benutzungsober ache
Verdeutlicht den prinzipiellen Aufbau der Benutzungsober ache.
Insbesondere
Tasten- und Mausbelegung
grunds atzlicher Bildschirmaufbau (z.B. Fenstertypen)
Dialogstrategie (z.B. erst Objekt, dann Funktion ausw ahlen)
105
Produktstruktur
Gibt einen

Uberblick uber die einzelnen Bestandteile des Produkts.
Trainingsteil
(im Benutzer-Leitfaden oder Trainings-Handbuch)
Beschreibt typische Arbeitsabl aufe mit Beispielen und

Ubungen, mit besonderem Wert auf
Routinearbeiten.
Anordnung:
h augste Arbeitsabl aufe und Routinearbeiten
seltene Arbeitsabl aufe
Initialisieren und L oschen von Systemen
Beispiele m ussen aus dem geplanten Anwendungsbereich stammen
Abstraktionen (also var-1, var-2 statt zins und kapital) sind zu vermeiden

Ubungen sind so zu gestalten, da der Benutzer mit dem Produkt arbeitet und dabei
Erfolgserlebnisse hat.
Referenzteil
(im Benutzer-Leitfaden oder Referenz-Handbuch)
Enth alt eine vollst andige Beschreibung der einzelnen Objekte und Funktionen.
Die Anordnung orientiert sich meistens an der Men ustruktur.
Kommandos werden alphabetisch angeordnet.
Behandlung von Problemen
Enth alt eine Liste von Fehlermeldungen mit detaillierten Erkl arungen und Vorschl agen
Literaturverzeichnis
Abk urzungsverzeichnis
Glossar
Stichwortverzeichnis / Index / Register
Wichtigstes Hilfsmittel f ur einen schnellen Zugriff
Enth alt Benutzerziele (z.B. Anmeldung vornehmen) und Funktionsnamen (z.B. Buchung
erfassen)
Erstellt der Handbuch-Autor ein gutes Handbuch, dann sparen hunderte oder tausende
Benutzer eine Menge Zeit und Nerven!
106
8.5 Hilfesysteme
Ein Hilfesystem unterst utzt den Benutzer w ahrend der Benutzung durch explizite Erkl arungen
und Ausk unfte.
Schnelle und vom Kontext abh angige Erg anzung zum Benutzer-Handbuch
Hilfesysteme erl autern typischerweise folgende Punkte:
Aktuell w ahlbare Objekte, Funktionen, und Kommandos (und deren Optionen)
Bedeutung von Funktionstasten und Mauskn opfen
Hinweise zu Eingaben
Erl auterungen zu Funktionsergebnissen
Spezische Fehlererkl arungen (einschlielich Hilfen zur Korrektur)
Vorteile gegen uber dem Handbuch:
+ Texte in Hilfesystemen sind schneller und leichter zu aktualisieren.
+ Die Information in Hilfesystemen kann nicht verlorengehen.
Nachteile gegen uber dem Handbuch:
Der Text auf dem Bildschirm wird langsamer gelesen als in einem Handbuch (k urzer fas-
sen!)
Notizen und Markierungen wie auf Papier sind nicht m oglich.
Es gibt auch Mischformen aus Hilfesystemen und Handb uchern:
Es gibt Programme, die ausschlielich per Hilfesystem dokumentiert sind; lediglich die
Installationsanleitung kommt in gedruckter Form.
Bei manchen Programmen (z.B. Netscape) ist die gesamte Dokumentation als WWW-
Hypertext organisiert, auf den uber das Netz zugegriffen wird.
107
8.5.1 Dynamische Hilfesysteme
Ein statisches Hilfesystem liefert stets dieselbe Information, unabh angig vom Kontext.
Beispiel: in einem Fenster wird an jeder Stelle die gleiche Erkl arung gegeben.
Dies gilt auch bei Fehlermeldungen.
Beispiel: Der UNIX-Editor ed gibt bei Fehlern aller Art die Meldung
?
aus.
Ein dynamisches Hilfesystem ber ucksichtigt den Kontext zum Zeitpunkt der Hilfeanforderung.
Beispiel: In jedem Eingabefeld eines Fensters wird eine spezische Hilfe gegeben.
Dies gilt auch bei Fehlermeldungen.
Beispiel: Der eingegebene Wert 0.005 ist zu klein
Dynamische Hilfesysteme sind stets vorzuziehen.
8.5.2 Individuelle Hilfesysteme
Ein uniformes Hilfesystem gibt jedem Benutzer dieselbe Hilfe unabh angig von seinem Kenntnis-
stand.
Ein individuelles Hilfesystem unterscheidet nach verschiedenen Benutzergruppen (Anf anger, Ex-
perte).
Die Einstufung kann auch automatisch erfolgen.
Beispiel: Nachdem Sachbearbeiter M uller nur noch selten das Hilfesystem aufruft,
wird er als vom Hilfesystem als Experte eingestuft und erh alt nur noch eine Kurz-
form der Erkl arungstexte.
Individuelle Hilfesysteme sind stets vorzuziehen.
8.5.3 Passive und Aktive Hilfesysteme
Nur 40% der Funktionalit at komplexer Systeme werden auch benutzt.
Manche Funktionen werden nur selten benutzt, da der Benutzer
die Funktionen nicht im Detail kennt
sich unsicher uber ihre Details und Wirkungen ist
108
Das ist der Einsatzbereich von passiven Hilfesystemen.
Ein passives Hilfesystem erwartet, da der Benutzer von sich aus eine Hilfeleistung anfordert,
z.B.
durch Dr ucken einer Taste (F1 oder Help)
durch Eingabe eines Kommandonamens (man ls)
durch Anfragen in nat urlicher Sprache (

Warum kann hier kein Text eingef ugt werden?)

durch Anwahl eines Bedienelements (balloon help)
Problem: Oft sind Konzepte realisiert, die der Benutzer nicht vermutet.
Ein aktives Hilfesystem beobachtet das Benutzungsverhalten und wird von sich aus aktiv, um
dem Benutzer eine Hilfe zu geben.
Beispiel: Um sich von einem Wort zum anderen zu bewegen, wurden einzeln Pfeil-
tasten benutzt. Der Word-Assistent erkennt diesen Vorgang und weist den Benutzer
darauf hin, da mit Ctrl+Pfeiltasten W orter ubersprungen werden k onnen.
In der Regel werden heute passive und uniforme Hilfssysteme eingesetzt, die statische und dy-
namische Hilfeleistungen mischen.
109
8.6 Checkliste: Benutzer-Handbuch
Kann man leicht durch das Handbuch navigieren?
Sind im Benutzer-Leitfaden und Trainings-Handbuch Kapitel und Abschnitte nach Be-
nutzerzielen organisiert und benannt?
Ist das Inhaltsverzeichnis gut gegliedert?
Enth alt das Stichwortverzeichnis Benutzerziele und Funktionsnamen?
Unterst utzt das Handbuch leichtes Erlernen?
Richtet sich die Sprache an den Endanwender?
Wird die Information in kleinen Einheiten dargeboten?
Wird die Information in einer logischen Sequenz dargeboten?
Gibt es Beispiele? Zeichnungen? Graken?
Werden visuelle Kennzeichen (Typographie) konsistent verwendet?
Wird eine

Vermenschlichung des Computers vermieden?

Ist das Handbuch gut lesbar?
Lesbarkeit wird insbesondere erreicht
durch groz ugigen Gebrauch von Leerraum
durch Vermeiden von unn otigem Jargon
Sind die Pichtteile enthalten?
Vergleiche Abschnitt 8.4.
Gibt es geeignete Szenarien?
Benutzer-Leitfaden und Trainings-Handbuch m ussen typische Szenarien im Umgang mit
dem System enthalten, und beschreiben, wie sich das System verh alt.
Diese Szenarien bilden die Grundlage f ur sp atere Tests (und sollten deshalb einzeln ge-
kennzeichnet sein).
Ist eine Hilfefunktion vorhanden?
Das System sollte zumindest eine statische, passive, uniforme Hilfe anbieten.
110
Kapitel 9
Entwurf von Benutzungsschnittstellen
Bei der Einf uhrung eines neuen Software-Systems in die Praxis kommt es oft zu Problemen, da
die Benutzungsschnittstellen nur unzureichend an die Probleme angepat sind.
Das verf ugbare Wissen zur Software-Ergonomie wurde in einer Norm zusammengefasst: DIN
EN ISO 9241
Diese Norm bietet Hilfestellungen bei der Konzeption, Gestaltung und Bewertung von Bild-
schirmarbeitspl atzen und deniert Mindestforderungen f ur die ergonomische Gestaltung von
Software.
Hauptanforderungen:
Kompetenzf orderlichkeit
Das Software-System soll
konsistent und
handlungsunterst utzend
gestaltet sein und so das Wissen des Benutzers uber das Software-System steigern.
Handlungsexibilit at
Das System mu alternative L osungswege und Aufgabenstellungen unterst utzen.
Aufgabenangemessenheit
Das System mu erlauben, die Aufgabe gut und efzient zu erledigen.
Jede dieser Anforderungen hat konkrete Auswirkungen auf die Gestaltung der Benutzungs-
schnittstelle.
111
9.1 Konsistenz und Kompetenz
Die Interaktion zwischen dem Benutzer und der Software soll so gestaltet sein, da der Benutzer
kompetent mit den Software-Systemen umgehen kann und dadurch seine Handlungskompetenz
gef ordert wird.
Handlungskompetenz bedeutet, da der Benutzer Wissen uber die Software-Systeme und ihre or-
ganisatorische Einbettung erworben hat und da er dieses Wissen auf die von ihm zu erf ullenden
Aufgaben beziehen kann.
Grunds atze:
1. Benutzeroperationen sollen konsistent gestaltet sein
2. Benutzeroperationen sollen die Aufgabenstellung unterst utzen
Konkrete Manahmen zum Steigern von Konsistenz und Kompetenz:
Objekt-Aktivierung und -Bearbeitung einheitlich, ubersichtlich und durchschaubar dar-
stellen. Wenig syntaktische Fehler zulassen.
Nur im Kontext anwendbare Funktionen darstellen; sinnlose Funktionen blockieren (z.B.
grau darstellen)
Letzte Parametereinstellung beim Aufruf einer Men uoption anzeigen (z.B. Formatieren
einer Diskette)
Sicherheitsabfragen bei Operationen mit schwerwiegenden Folgen. Folgen verdeutlichen.
Undo/Redo-Funktion anbieten, d.h. alle durchgef uhrten Operationen sollten storniert wer-
den k onnen.
Auf Wunsch mu die Stornierung aufgehoben werden (Redo).
Mindestens einstug. Wunsch mehrstug.
Inkrementelle Aufgabenbearbeitung erm oglichen, d.h. kleine, unabh angige, nichtsequenti-
elle Teilschritte mit jeweiliger Ergebnisr uckmeldung.
Keine Operation darf in einer

Sackgasse enden.
R uckmeldungen auf alle Benutzeroperationen. Anzeigen, ob Eingabe erwartet wird oder
gerade eine Verarbeitung stattndet.

Uberdurchschnittliche Verarbeitungszeiten anzeigen
(Art, Objekt, Umfang oder Dauer).
Systembedingte Verz ogerungen, Unterbrechungen oder St orungen explizit anzeigen.
112
Regelwerke f ur die Dialoggestaltung
Das wichtigste Hilfsmittel, einheitliche Programmbedienung zu erhalten, sind Regelwerke (style
guides) f ur die Ober achengestaltung.
Beispiel: Dialoggestaltung mit der GNOME-Bibliothek, einem Linux-Standard:
1
All dialogs should have at least one button that is labeled Close, Cancel, OK, or
Apply.
Modal dialogs should be avoided wherever possible.
The default highlighted button for a dialog should be the safest for the user.
All dialogs should default to a size large enough to display all of the information in the
dialog without making a resize necessary.
All dialogs should set the titlebar with an appropriate string.
A dialog which consists of a single entry box shall have its OK button be the default
(which is to say that ENTER shall accept the entry), and the ESCAPE key shall be bound to
the Cancel button.
In a dialog the OK or Apply button should not be highlighted until the user has made
a change to the congurable data in the dialog.
If a dialog contains more than one button for the destruction of that dialog, (for example,
an OK and a Cancel), the afrmative button should always fall to the left of the
negative.
Style Guides k onnen bis zu hundert Seiten umfassen!
Verbreitete Stile und Regelwerke der Dialoggestaltung sind
Windows (Windows Interface Application Design Guide)
Motif (OSF/Motif Style Guide)
MacOS (Macintosh Interface Guidelines)
Manche Betriebssysteme (z.B. X Window System/UNIX), Programme (z.B. StarOfce), und
Bibliotheken (z.B. Swing, Qt) unterst utzen mehrere Stile entweder wahlweise oder gleichzeitig.
Generell n ahern sich Aussehen und Verhalten der Ober achen (look and feel) zunehmend einan-
der an.
1
http://www.gnome.org/
113
Beispiele f ur inkonsistente Benutzeroperationen
2
Den Sinn einheitlicher Regeln f ur Benutzungsschnittstellen erkennt man am besten, wenn man
Verst oe betrachtet.
Auf einem Macintosh-M ulleimer kann man beliebige Objekte l oschen, indem man sie auf den
M ulleimer zieht.
Zieht man jedoch eine Diskette auf den M ulleimer, wird sie nicht gel oscht, sondern ausgeworfen.
Ein

magischer M ulleimer, der neue Benutzer verwirrt.

Frage f ur Macintosh-Experten: Wie l osche ich eine Diskette?
Will man in Windows 95 eine Datei suchen, erh alt man diesen Dialog:
Originellerweise wird die Suche mit Starten aktiviert der Durchsuchen-Knopf erlaubt nur die
Auswahl eines Startverzeichnisses.
2
Alle Beispiele aus: Interface Hall of Shame (http://www.iarchitect.com/mshame.htm), dem Museum f ur falsche
Fehlermeldungen (http://www.moffem.de/) sowie Dialoge boxen (http://www.dasding.de/dialoge/dialog2.htm)
114
9.2 Kompetenzf ordernde Dialoge
Hauptpunkte der Kompetenzf orderlichkeit sind:
Selbstbeschreibungsf ahigkeit
Jeder Dialogschritt mu verst andlich sein.
Erwartungskonformit at
Dialoge sollen den Erwartungen der Benutzer entsprechen
Fehlerrobustheit
Dialoge sollen robust mit Fehleingaben umgehen.
9.2.1 Selbsterkl arende Dialoge
Selbsterkl arende Dialoge steigern die Handlungskompetenz, indem sie das Wissen uber das
Software-System f ordern.
Ein Dialog ist selbsterkl arend, wenn
dem Benutzer auf Verlangen Einsatzzweck sowie Leistungsumfang des Dialogsystems
erl autert werden k onnen und wenn
jeder einzelne Dialogschritt
unmittelbar verst andlich ist oder
der Benutzer auf Verlangen dem jeweiligen Dialogschritt entsprechende Erl auterun-
gen erhalten kann.
Konkrete Manahmen f ur selbsterkl arende Dialoge:
Der Benutzer mu sich zweckm aige Vorstellungen von den Systemzusammenh angen ma-
chen k onnen
Erl auterungen sind an allgemein ubliche Kenntnisse der zu erwartenden Benutzer angepat
(deutsche Sprache, beruiche Fachausdr ucke)
Wahl zwischen kurzen und ausf uhrlichen Erl auterungen (Art, Umfang)
Kontextabh angige Erl auterungen
115
Beispiele f ur schlechte Erl auterungen
Was ist ein

palettized display?
Ein PC-Experte mag diese Meldung vielleicht verstehen. Diese Warnung entstammt aber Dr.
Zeusss ABC, ein Alphabet-Lern-Programm f ur 3- bis 5j ahrige Kinder.
Noch bemerkenswerter: Die Warnung ist v ollig uber ussig, denn auch ohne

palettized display
funktioniert das Programm einwandfrei.
Diese h ochst aussagekr aftige Fehlermeldung ist Microsoft Visual Basic 5.0 zu entnehmen:
Nach dem Klicken auf Help erhalten wir:
Visual Basic encountered an error that was generated by the system or an external
component and no other useful information was returned.
The specied error number is returned by the system or external component (usually
from an Application Interface call) and is displayed in hexadecimal and decimal
format.
Das bedeutet:
Irgendetwas ist passiert. Wir wissen nicht, was hier passiert ist oder warum es pas-
siert ist. Wir wissen nur, da die dargestellte hexadezimale Zahl eine hexadezimale
Zahl ist, aber die Zahl selbst hat keine Bedeutung.
Was nicht in der Erl auterung steht: Die L osung des Problems. Neu booten.
116
Zum Schlu eine unfreundliche Fehlermeldung der Secure Shell:
$ ssh somehost.foo.com
You dont exist, go away!
$
Diese Fehlermeldung erscheint etwa, wenn der NIS-Server gerade nicht erreichbar ist. Nicht, da
man den Benutzer dar uber aufkl aren w urde. . .
117
9.2.2 Erwartungskonforme Dialoge
Die Handlungskompetenz wird durch erwartungskonforme Dialoge unterst utzt.
Ein Dialog ist erwartungskonform, wenn er den Erwartungen der Benutzer entspricht,
die sie aus Erfahrungen mit bisherigen Arbeitsabl aufen oder aus der Benutzerschulung
mitbringen sowie
den Erwartungen, die sie sich w ahrend der Benutzung des Dialogsystems und im Umgang
mit dem Benutzerhandbuch bilden.
Konkrete Manahmen f ur erwartungskonforme Dialoge:
Das Dialogverhalten ist einheitlich (z.B. konsistente Anordnung der Bedienungselemente).
Bei ahnlichen Arbeitsaufgaben ist der Dialog einheitlich gestaltet (z.B. Standard-Dialoge
zum

Offnen oder Drucken von Dateien)
Zustands anderungen des Systems, die f ur die Dialogf uhrung relevant sind, werden dem
Benutzer mitgeteilt.
Eingaben in Kurzform werden im Klartext best atigt.
Systemantwortzeiten sind den Erwartungen des Benutzers angepat, sonst erfolgt eine
Meldung.
Der Benutzer wird uber den Stand der Bearbeitung informiert.
118
Beispiele f ur unerwartetes Dialogverhalten
Gew ohnlich schreiben Standards vor, wie Bedienungselemente anzuordnen sind etwa Best ati-
gen vor Abbrechen, oder Ja vor Nein, oder Hilfe ganz rechts. Microsoft Excel macht alles anders:
Wo ist der Unterschied zwischen Yes und OK?
Wenn man Freeloader, einen WWW-Browser deinstalliert, erscheint dieses Fenster:
Der Benutzer mag denken, er k onne ausw ahlen, was denn nun tats achlich deinstalliert werden
soll. Weit gefehlt! Dies ist eine Statusmeldung, die anzeigt, was bereits deinstalliert wurde.
Originellerweise andern die Kn opfe ihren Zustand, wenn man auf sie klickt aber diese

Ande-
rung hat keine Auswirkungen.
119
9.2.3 Fehlerrobuste Dialoge
Ein Dialog ist fehlerrobust, wenn trotz erkennbar fehlerhafter Eingaben das beabsichtigte Ar-
beitsergebnis mit minimalem oder ohne Korrekturaufwand erreicht wird.
Dem Benutzer m ussen Fehler verst andlich gemacht werden, damit er sie beheben kann.
Konkrete Manahmen f ur fehlerrobuste Dialoge:
Benutzereingaben d urfen nicht zu Systemabst urzen oder undenierten Systemzust anden
f uhren.
Aus der GCC-Dokumentation:
If the compiler gets a fatal signal, for any input whatever, that is a compiler bug. Reliable
compilers never crash.
Automatisch korrigierbare Fehler k onnen korrigiert werden. Der Benutzer mu hier uber
informiert werden.
Die automatische Korrektur ist abschaltbar.
Korrekturalternativen f ur Fehler werden dem Benutzerangezeigt.
Fehlermeldungen weisen auf den Ort des Fehlers hin. z.B. durch Markierung der Fehler-
stelle.
Fehlermeldungen sind
verst andlich,
sachlich und
konstruktiv
zu formulieren und sind einheitlich zu strukturieren (z.B. Fehlerart, Fehlerursache, Fehler-
behebung).
120
Beispiele f ur schlechte Fehlermeldungen
Dies ist eine Fehlermeldung von Eudora, einem E-Mail-Programm:

503 h oiche Leute sagen erstmal Hallo.

Ein Programmierer, der mit demSMTP-Protokoll vertraut ist, mag hiermit etwas anfangen k onnen.
Der gew ohnliche Benutzer aber wird sich fragen:

H ah? Was habe ich falsch gemacht?

Was w urden wohl 503 unh oiche Leute sagen?
Auch hier war der Programmierer zu faul, einen sinnvolle Meldung abzuliefern, geschweige
denn, Hinweise, wie man den Fehler beheben kann:
Erschwerend kam hinzu, da die arme Sekret arin, mit dieser Meldung konfrontiert, ein ums
andere Mal

mismatch eintippte (

type = tippen), ohne da irgendetwas passierte.

121
Diese Meldung erscheint in IBMs Aptiva Communication Center, wenn der Benutzer einen
leeren Datensatz ausgew ahlt hat und auf den Change-Knopf klickt:
Nun gut, dies ist ein Fehler. Vielleicht auch ein dummer Fehler, aber wenn Rechner dumme Feh-
ler erm oglichen, machen Benutzer sie auch. Was Benutzer jedoch nicht erwarten, sind unh oiche
Rechner. Diese Fehlermeldung k onnte genausogut lauten:

Andern?! Wie dumm sind Sie eigentlich?

Was zum Teufel soll ich hier andern?!
Eine sehr viel einfachere L osung:
Niemals eine Funktion anbieten, die in einer Fehlermeldung endet
Stattdessen Funktionen ausblenden, die nicht angewandt werden k onnen.
Zum Abschlu eine freundliche und aussagekr aftige Macintosh-Meldung:
122
9.3 Flexibilit at
Eine Anwendung ist dann exibel, wenn
der Benutzer mit einer ge anderten Aufgabenstellung seine Arbeit noch efzient mit dem-
selben System erledigen kann,
eine Aufgabe auf alternativen Wegen ausgef uhrt werden kann, die dem Benutzer entspre-
chend seinem wechselnden Kenntnisstand und seiner aktuellen Leistungsf ahigkeit w ahlen
kann,
unterschiedliche Benutzer mit unterschiedlichem Erfahrungshintergrund ihre Aufgaben
auf alternativen Wegen erledigen k onnen.
Konkrete Manahmen zum Steigern der Flexibilit at:
Makrobildung erm oglichen, d.h. Operationen bei wiederkehrenden Abl aufen k onnen zu
einer einzigen Operation zusammengefat werden.
Mengenbildung erm oglichen, d.h. Objekte, auf die die gleichen Operationen angewendet
werden sollen, k onnen zu gr oeren Einheiten zusammengefat werden (z.B. im Zeichen-
programm mehrere Objekte gruppieren und dann verschieben)
Soweit wie m oglich nicht-modale Dialoge verwenden.
Ein modaler Dialog schr ankt im Rahmen einer Ausnahmesituation die Handlungsexibi-
lit at ein (z.B. zur Fehlerbehebung, wenn erst nach der Fehlerbehebung weitergearbeitet
werden kann).
Parallele Bearbeitung mehrerer Anwendungen mit gegenseitigem Informationsaustausch
vorsehen.
Generell: Alternative Benutzeroperationen anbieten!
123
Der Netscape Navigator erlaubt das Einstellen von Benutzeroptionen, so etwa der Schriftgr oen.
Ungl ucklicherweise ist der Einstellungs-Dialog modal alle anderen Fenster sind inaktiv, w ahrend
der Dialog ge offnet ist. Wenn der Benutzer h aug zwischen verschiedenen Schriftgr oen wech-
seln will, mu er jedesmal den Dialog offnen und wieder schlieen.
Dieser Dialog mu nicht modal sein. Viel bequemer w are es, nach Belieben zwischen den einzel-
nen Fenstern hin- und herzuschalten. Offensichtlich sind die Einstellungen nur deshalb modal,
weil sich die Programmierer Arbeit ersparen wollten.
Modale Dialoge vermeiden, wo immer es geht!
124
Beispiele f ur groe Flexibilit at
DDD ist ein graphischer Debugger, mit dem der Ablauf eines Programms Schritt f ur Schritt
untersucht werden kann.
So kann der Benutzer in DDD einen Haltepunkt (Breakpoint) setzen:
1. eine Zeile ausw ahlen und auf Break klicken (Anf anger)
2. einen Funktionsnamen ausw ahlen und auf Break klicken (Anf anger)
3. auf eine Zeile mit der rechten Maustaste klicken und Set Breakpoint aus einem Kontext-
Men u ausw ahlen (Fortgeschrittener)
4. einen Funktionsnamen mit der rechten Maustaste ausw ahlen und Set Breakpoint at aus
einem Kontext-Men u ausw ahlen (Fortgeschrittener)
5. auf eine Zeile doppelklicken (Experte)
6. ein break-Kommando uber die Tastatur eingeben (Experte) oder
7. das Kommando zu b abk urzen. (Guru)
125
9.4 Efzienz und Angemessenheit
Der Benutzer soll seine Arbeitsaufgabe mit Hilfe der Anwendungen in einer Weise bearbeiten,
die der Aufgabe angemessen ist:
Kann der Benutzer die Zielsetzung seiner Aufgabe uberhaupt mit dem System erreichen,
oder mu er zus atzlich andere Systeme oder Medien einsetzen (z.B. Speicherung von Zwi-
schenergebnissen auf Papier)
Mit welchem Planungs- und Zeitaufwand (einschlielich des Aufwandes zur Korrektur
von Fehlern) sowie mit welcher Qualit at des Arbeitsergebnisses kann dieses Ziel erreicht
werden?
Ein System ist immer dann nicht aufgabenangemessen, wenn
bestimmte erforderliche Funktionalit aten nicht vorhanden sind (fehlende Funktionalit at)
oder

der Benutzer zur Ausf uhrung eines in seinem Verst andnis zusammenh angenden und ein-
heitlichen Arbeitsschrittes eine gr oere Anzahl von Interaktionsschritten ben otigt (gerin-
ge Efzienz der Mensch-Rechner-Interaktion).
Konkrete Manahmen zum Steigern der Efzienz:
Minimierung der Interaktionsschritte, die zur Ausf uhrung einer Aufgabe oder einer ein-
zelnen Operation ben otigt werden.
Hilfreiche Techniken:
Mnemonische Auswahl von Men uoptionen uber die Tastatur
Auswahl uber Tastaturk urzel (z.B. Strg+X statt BearbeitenAusschneiden)
Symbolbalken (Toolbar) mit h aug benutzten Funktionen
Auff uhrung der zuletzt benutzten Objekte / Einstellungen
Kommandosprache (ggf. mit Kontrollstrukturen)
Planungsaufwand reduzieren, z.B. durch syntaktisch einfache Aufgaben oder Reduktion
vieler Einzelschritte
Makro- und Mengenbildung (s. Abschnitt 9.3)
Syntaktische Fehler verhindern oder abfangen.

Uber ussige Systemmeldungen, die der
Benutzer quittieren mu, vermeiden.
Am besten ist die volle Funktionalit at eines Men usystems und einer Kommandosprache!
126
Beispiele f ur mangelnde Efzienz
Jedesmal, wenn man in Lotus Notes eine e-mail absenden will, verlangt Notes eine Best atigung.
Das kann auf Dauer recht anstrengend werden:
Wenn der Benutzer schon einmal auf Absenden gedr uckt hat, warum nicht einfach anerkennen,
da er wohl Absenden meint?
Noch schlimmer treibt es da AK-Mail:
Warum eigentlich JA? Warum nicht gleich JAAA, VERFLUCHT!?
Microsofts Web Wizard ist ein Programm zum Verwalten von Dateien auf WWW-Servern.
W ahrend des Ablaufs erstellt Web Wizard eine Liste der Dateien auf dem Server und fragt ab,
f ur jede Datei einzeln, ob sie gel oscht werden soll:
127
Wenn man etwa die Datei zeller.gif l oschen wollte, m ute man zun achst 400mal auf No klicken
f ur jede der Dateien, die im Alphabet davor stehen.
Sehr viel efzienter w are es hier, das Programm w urde einfach die komplette Liste der Dateien
anzeigen und L oschen von Gruppen anbieten.
Wenn man in Visual Basic einen Text selektiert und dann Search aufruft, wird der selektierte Text
zur Vorgabe. So sollte es sein.
In anderen Programmen wie etwa Notepad mu der Benutzer stattdessen aufwendig den Text
uber die Zwischenablage kopieren und einf ugen:
128
Beispiele f ur gute Efzienz
In den Textverarbeitungsprogrammen LyXund KLyXgibt es einen Formeleditor, mit demAnf anger
Formeln uber ein Men u zusammensetzen k onnen:
Der fortgeschrittene Benutzer kann aber auch direkt uber die Tastatur T
E
X-Kommandos eingeben
etwa
\sum_{n = 1}{\infty}\frac{xn}{n} =
\ln\left(\frac{1}{1 - x}\right)
f ur

n=1
x
n
n
= ln
_
1
1x
_
.
Bereits mit der ersten Eingabe von \ schaltet KLyX in den T
E
X-Eingabemodus.
Flexible Programme sind meist auch efzient!
129
9.5 Benutzerfreundliche Web-Seiten
Die Top 10, um die Benutzungsfreundlichkeit zu erh ohen von Jakob Nielsens Alertbox
3
:
1. Name und Logo auf alle Seiten
2. Suchfunktion (bei > 100 Seiten)
3. Aussagekr aftige Titelzeilen
4. Vertikales Scannen erm oglichen
5. Information per Hypertext strukturieren (statt Scrollen)
6. Kleine Photos benutzen
7.

Ubertragungsgeschwindigkeit maximieren
8. Links mit Titeln versehen
9. Seiten f ur Behinderte zug anglich machen
10. Konventionen von anderen Seiten ubernehmen
. . . und umgekehrt die Top 10, um die Benutzungsfreundlichkeit zu verringern:
1. Frames
2. Neueste Plug-Ins
3. Scrollender Text
4. Lange URLs
5. Waisenseiten (= Error 404)
6. Scrollende Navigations-Seiten
7. Keine Unterst utzung f ur Navigation
8. Eigene Farben f ur Links
9. Obsoleter Inhalt
10. Lange Ladezeiten
3
http://www.useit.com/alertbox/
130
9.6 Benutzerfreundlichkeit pr ufen
Umdie Benutzerfreundlichkeit zu pr ufen, gibt es nur ein Mittel: Das Systemmit echten Benutzern
testen!
Typische Vorgehensweise: Benutzer sollen mit dem System eine bestimmte Aufgabe erledigen
und halten anschlieend fest, was sie gest ort hat.
Beispiel: In Linux-Maschine einloggen (Studie, 2001)
4
Probleme bei der Benutzung dieses Dialogs:
Was ist ein

Login? Der Benutzername? Oder das Pawort? (Konsistenz und Kompetenz)

Username und Pawort werden nicht gemeinsam abgefragt (Konsistenz und Kompentenz)
Was soll der Benutzer nach der Eingabe des Namens tun? (Erwartungskonforme Dialoge)
Bei falschem Benutzernamen/Pawort erscheint kein Dialog (Erwartungskonforme Dialo-
ge)
Ist Klein-/Groschreibung relevant? Was passiert, wenn die Caps-Lock-Taste gedr uckt ist?
(selbsterkl arende Dialoge)
Was ist

marge-hci? (selbsterkl arende Dialoge)

4
Suzanna Smith et al., GNOME Usability Study Report, http://developer.gnome.org/projects/gup/ut1 report/
131
Vorschlag f ur (leicht) verbesserten Dialog:
Typically, when project managers observe their design undergoing a usability test, their initial
reaction is:
Where did you nd such stupid users?
5
5
http://www.useit.com/alertbox/20010204.html
132
9.7 Checkliste: Benutzungsober ache
Ist die Ober ache konsistent gestaltet?
Dies wird in der Regel durch das Verwenden von Standard-Dialogen erreicht. Wo immer
m oglich, sollte man sich an Standards orientieren Dialoggestaltung, Men ustruktur, Ta-
staturbelegung usw.
Sind die Dialoge selbsterkl arend?
Vergleiche Abschnitt 9.2.1.
Sind die Dialoge erwartungskonform?
Auch dies wird durch Standard-Dialoge erreicht.
Sind die Dialoge fehlerrobust?
Fehleingaben d urfen in keinem Fall zu Abst urzen oder undeniertem Verhalten f uhren.
Meldungen m ussen positiv sein. Keine Anklagen! Keine Beleidigungen! Keine Witze! Kei-
ne merkw urdigen Ger ausche auf dem Lautsprecher!
Stets sollte das System vermitteln, da es zu dumm ist, den Benutzer zu verstehen, und
nicht, da der Benutzer zu dumm ist, das System zu bedienen.
Ist die Anwendung exibel?
Nach Absprache mit dem Auftraggeber sollte die Anwendung m oglichst so gestaltet wer-
den, da Aufgaben auf alternativen Wegen ausgef uhrt werden k onnen.
Modale Dialoge sollten, wo immer m oglich, vermieden werden.
Vergleiche Abschnitt 9.3.
Unterst utzt die Ober ache efzientes Arbeiten?
Das entscheidet der Auftraggeber. Vergleiche Abschnitt 9.4.
133
Kapitel 10
Konzepte des Software-Entwurfs
In der Entwurfsphase wird die Systemarchitektur festgelegt:
Zerlegen des Systems in Programmelemente.
Festlegen der Schnittstellen der Elemente
Festlegen der Beziehungen zwischen Elementen.
In diesem Kapitel betrachten wir zun achst die Grundprinzipien des Zerlegens. Anschlieend
f uhren wir die Konzepte anhand einer historischen Betrachtung ein.
134
10.1 Grundprinzipien der Zerlegung
10.1.1 Hauptprinzip: Lokalisierung
Ein System wird in Elemente zerlegt, um Entwicklung und Wartung zu lokalisieren.
Lokalisieren bedeutet, da T atigkeiten (

Anderungen, Erweiterungen) an einer Stelle im System

m oglichst wenig weitere T atigkeiten an

entfernteren Stellen bewirken.

Beispiel 1: Die Mehrwertsteuer wird erh oht
Im einen Fall mu an zweihundert Stellen die

magische Zahl 0.16 in 0.18 abgewandelt

werden.
Im zweiten Fall reicht es, an einer Stelle die Konstantendenition MWST von 0.16 auf 0.18
zu andern.
Wir sagen: die Konstante lokalisiert den Wert der Mehrwertsteuer.
Beispiel 2: Wir f uhren 4-stellige statt 2-stellige Jahreszahlen ein
Im einen Fall m ussen 5 Millionen Codezeilen auf Jahreszahlen untersucht werden.
Im zweiten Fall gen ugt es, die Denition des abstrakten Typs Datum zu erweitern.
Wir sagen: der Typ lokalisiert die Datumsdenition.
Einu von Lokalisierung auf Grundprinzipien
Lokalisierung der Software-Entwicklung Separation der Interessen
Lokalisierung der Software-Wartung Evolutionsf ahigkeit
Synonym von Lokalisierung: Einkapselung
135
10.1.2 Was kann sich in einem System andern?
Typische Anl asse f ur

Anderungen:
Wechsel der Algorithmen
um die Efzienz zu erh ohen oder mit allgemeineren F allen umzugehen (z.B. Quicksort /
Mergesort)
Wechsel der Datenstrukturen
um die Efzienz zu erh ohen oder passende Algorithmen zu realisieren (z.B. verkettete
Liste / Suchbaum / Hashtabelle)
Wechsel der abstrakten Maschine
kann

Anderungen in der Software bedingen (z.B. neues Betriebssystem / neuer

Ubersetzer
/ neues Datenbanksystem)
Wechsel der Peripherie
mu in der Software nachvollzogen werden (z.B. neue Druckerschnittstelle, farbige Dis-
plays)
Wechsel des sozialen Umfelds
mu gleichfalls nachvollzogen werden (z.B. Erh ohung der Mehrwertsteuer, Umstellung
DMEuro)
Der Entwurf mu zuk unftige

Anderungen so weit wie m oglich ber ucksichtigen.
Unvorhergesehene

Anderungen kommen um so billiger,
je besser ein Entwurf ist!
136
10.1.3 Zerlegungskriterien
Ziel jeder Zerlegung ist, die Kopplung der Programmelemente uber Informationsu so gering
wie m oglich zu halten.
Grund: Je schw acher die Kopplung, um so weniger k onnen

Anderungen in einem Element

Ande-
rungen in anderen Elementen bedingen.
Bei der Zerlegung eines Systems in Elemente sollen die folgenden Grundprinzipien ber ucksich-
tigt werden:
Getrennte

Ubersetzbarkeit
Elemente sollten syntaktischen Einheiten der Sprache entsprechen
Explizite Schnittstellen
Schnittstellen m ussen aus dem Programm ersichtlich sein
Vollst andige Schnittstellen
Schnittstellen m ussen den gesamten Funktionsumfang abdecken
Geheimnisprinzip
Schnittstellen d urfen keine f ur Klienten irrelevanten Interna offenlegen
Hohe Koh asion
Elemente sollten logisch zusammengeh orende Funktionen enthalten
Schwache Kopplung
Elemente sollten sowenig Information wie m oglich austauschen.
Wenige Schnittstellen
Elemente sollten mit m oglichst wenig anderen Elementen Informationen austauschen.

Uberschaubarkeit
Elemente sollten nicht zu gro sein
Gesamtziel: Lokalisierung Separation der Interessen und Evolutionsf ahigkeit
137
10.2 Chaos (1950)
Am Anfang der Programmierung gab es kaum explizite Programmelemente: selbst die Trennung
von Daten und Programmcode war anfangs unbekannt.
Das Programm konnte beliebig den kompletten Speicher manipulieren (und tat es auch).
Die Kommunikation selbst ist unstrukturiert:
Elemente manipulieren direkt Daten oder sogar Programmcode (Assembler!) von anderen Ele-
menten.
Dieser schwerwiegende Versto gegen das Geheimnisprinzip wird mit sofortigem Entzug des
Diploms geahndet!
(Leider) immer noch verbreitet: Daten werden uber globale Variablen ausgetauscht (z.B. COMMON-
Bl ocke in FORTRAN).
Dieser Versto gegen das Geheimnisprinzip ist nur in ganz wenigen Ausnahmesituationen
sinnvoll!
138
10.3 Parametrisierte Funktionen (1960)
Funktionen verf ugen uber lokale Variablen, auf die von auen nicht zugegriffen werden kann.
Kommunikation erfolgt uber Argumente bei Funktionsaufrufen.
Heute immer noch sicheres Standardverfahren!
Aber: Der Zustand des Systems wird nach wie vor in allgemein zug anglichen globalen Variablen
abgelegt.
Ein System kann auf mehrere Weisen in Funktionen zergliedert werden:
Top-Down-Entwurf
Eine Funktion wird solange in Sequenzen, Schleifen oder Abfragen zerlegt, bis man bei elemen-
taren Operationen angelangt ist. (vergl. Abschnitt 7.4.1)
Klassischer

Teile und Herrsche-Ansatz gut f ur erste

Ubersicht
Aber:
N utzliche Generalisierungen werden unterdr uckt
Wiederverwendung wird erschwert
Geheimnisprinzip wird nicht unterst utzt
Kontrollu wird fr uhzeitig xiert
Hohe Kopplung zwischen Programmteilen, da sie auf gemeinsamen Daten arbeiten
Bottom-Up-Entwurf
In einer Aufgabenstellung sucht man zun achst nach Elementen, die sich andern k onnten.
Diese Frage ist grundlegend beim Architekturentwurf, denn es gilt das Prinzip: Was sich andern
k onnte, mu in einem Element gekapselt werden, um

Anderungen lokal zu halten!
Sorgt f ur h ohere Wiederverwendbarkeit und bessere

Anderbarkeit
139
10.4 Bibliotheken (1960)
Eine Bibliothek fat eine Menge von Elementen (insbesondere Funktionen und Variablen) zur
Verwendung in unterschiedlichen Kontexten zusammen (Bottom-Up-Entwurf).
Bibliotheken sollen logisch zusammengeh orende Elemente enthalten (hohe Koh asion)
Grund: zusammengeh orende Elemente werden gemeinsam entwickelt und ge andert.
Wir unterscheiden folgende Koh asionstypen:
Koinzidentielle Koh asion
Keine Beziehung zwischen Teilen der Bibliothek
Logische Koh asion

Ahnliche Funktionen, z.B. alle Eingabefunktionen, alle Ausgabefunktionen, alle Fehlerbe-

handlungsfunktionen . . .
Zeitliche Koh asion
Alle Teile, die zur selben Zeit ausgef uhrt werden etwa Initialisierungsroutinen, Start-Up
. . .
Prozedurale Koh asion
Eine Bibliothek realisiert einen bestimmten Algorithmus
Kommunikative Koh asion
Elemente einer Bibliothek arbeiten auf denselben Daten
Sequentielle Koh asion
Ausgabe einer Bibliothekskomponente ist Eingabe der n achsten
Funktionale Koh asion
Jedes Element der Bibliothek ist zur Realisierung einer bestimmten Funktion notwendig
In einer Bibliothek k onnen auch Daten offentlich zug anglich sein (etwa globale Schalter). Dieser
Versto gegen das Geheimnisprinzip ist sehr fehleranf allig!
Ggf. verbietet eine Konvention den Zugriff auf Interna der Bibliothek (z.B. Auf Elemente, die
mit beginnen, darf nicht zugegriffen werden). Konventionen k onnen aber umgangen werden!
Alternativer Name f ur Bibliotheken: Paket
140
Beispiel: Adressenliste in C
Wir realisieren eine Liste von Paaren (Name, Adresse) zusammen mit einer Suchfunktion.
struct Element
char name[20]; /
*
Name
*
/
char adresse[20]; /
*
Adresse
*
/
struct Element
*
next; /
*
Nachstes Element
*
/
;
/
*
Element in LISTE suchen, bei der NAME ubereinstimmt
*
/
extern Element
*
suche element(Element
*
liste,
char name[]);
Benutzung:
Element
*
e = suche element(liste, "Hugo");
if (e != NULL)
kopiere(formular.adresse, e->adresse);
.
.
.
Probleme dieser offenen Zeiger:
Darf der Benutzer den Adressen-Wert ver andern?
Darf der Benutzer den Schl ussel-Wert ver andern? (Die Liste k onnte sortiert sein!)
Darf der Benutzer auf next zugreifen?
Darf sich der Benutzer den Zeiger merken? Wie lange?
Was passiert, wenn die Liste ver andert wird? Ist der zur uckgegebene Zeiger nach wie vor
g ultig?
All diese Fragen werden per Konvention (Dokumentation) geregelt. Verst oe (insbesondere un-
absichtliche!) werden jedoch nicht erfat.
Besser: Das Schl usselwort const kennzeichnet eine konstante Datenstruktur:
extern const Element
*
suche element(Element
*
liste,
char name[]);
Nach wie vor sind aber (Lese-)Zugriffe auf next m oglich; auch ist undeniert, wie lange der
Zeiger g ultig ist.
141
10.5 Module (1970)
Mit Modulen wurde erstmals exakt speziziert, welche Elemente eines Programms auf welche
Elemente zugreifen d urfen.
Ein Modul ist ein wohldeniertes Element eines Softwaresystems, das aus einer Schnittstelle und
einem Rumpf besteht.
In der Schnittstelle (auch: Denition, Deklaration) wird speziziert, welche Dienstleistun-
gen das Modul exportiert, d.h. seiner Umgebung zur Verf ugung stellt.
Der Rumpf (auch: Implementierung, Realisierung) enth alt die Implementierungen der in
der Schnittstelle spezizierten Dienstleistungen.
Der Modulzustand kann nur durch Aufruf der Schnittstellenfunktionen abgefragt und ver andert
werden.
Die interne Repr asentation des Modulzustands (d.h. die Modulvariablen) ist Geheimnis des Mo-
duls:
Alle Variablen werden einem bestimmten Modul zugeordnet
Die Variablen k onnen nur von den Modulfunktionen direkt angesprochen werden
F ur Benutzer sind die Modulvariablen nicht zug anglich.
142
10.5.1 Zugang zu Moduldiensten
ImLaufe der Zeit haben Programmiersprachen verschiedene Mechanismen herausgearbeitet, den
Zugang zu Moduldiensten zu regeln.
Explizite Export/Importschnittstelle (Modula-2)
Das Modul gibt explizit an, welche Dienste zur Verf ugung gestellt werden:
EXPORT push, pop, top, empty stack;
Nicht aufgef uhrte Dienste sind geheim!
Analog dazu: Importschnittstelle gibt explizit an, welche Dienste genutzt werden
FROM stack IMPORT empty stack, push, pop, top;
Denitions- und Implementierungsteil (Modula-2, C, C++)
Das Modul ist in zwei Teile getrennt:
Der Denitionsteil enth alt die Beschreibung der Dienste, die offentlich zug anglich sind.
Der Implementierungsteil enth alt die Beschreibung der Dienste, die nicht offentlich zug ang-
lich sind und die komplette Implementierung des Moduls.
In C und C++: Header-Dateien, Implementierungsdateien
143
Schl usselw orter (C++, Java)
Ein

Ubersetzer kann ein Programm um so efzienter ubersetzen, je mehr Informationen uber den
Programmaufbau zur Verf ugung stehen einschlielich der Modulgeheimnisse.
Deshalb hat es sich als praktisch herausgestellt, dem

Ubersetzer die Geheimnisse des Moduls
offentlich zu machen, dem Benutzer aber nach wie vor den Zugriff zu verbieten.
Welche Dienste vom Benutzer genutzt werden k onnen, wird durch Schl usselw orter festgelegt:
private bedeutet, da nur Modulfunktionen auf den Dienst zugreifen k onnen;
public bedeutet, da alle Funktionen auf den Dienst zugreifen k onnen.
Ist nichts angegeben, ist der Dienst in der Regel private.
Dar uber hinaus noch Mischformen (umstritten):
protected Zugriff nur von Unterklassen,
package Zugriff nur innerhalb des Subsystems,
friend (C++) Zugriff durch explizit aufgef uhrte Programmelemente.
Nachteil: Benutzer kann Details der Implementierung erkunden und sich darauf verlassen.
144
10.6 Abstraktes Datenobjekt (1970)
Ein abstraktes Datenobjekt (ADO) kapselt einen Zustand (Daten) durch Zugriffsfunktionen ein.
Geheimnisprinzip
Absolute Trennung zwischen Schnittstelle und Realisierung
Schnittstelle
Angabe von Zugriffsfunktionen, ihren Argument- und Ergebnistypen (Modulkopf, Signa-
tur)
Zugriffsfunktionen
Die Denition erfolgt durch die Zugriffsfunktionen; Realisierung und interner Zustand
sind nach auen unbekannt
Ein abstraktes Datenobjekt existiert genau einmal im ganzen Programm.
(Klassische) Module realisieren meist abstrakte Datenobjekte.
10.6.1 Beispiel: Abstraktes Datenobjekt

Stack in MODULA-2
Modulkopf in MODULA-2 mit Signaturen:
DEFINITION MODULE stack;
PROCEDURE empty stack();
PROCEDURE push(x: integer);
PROCEDURE pop();
PROCEDURE top(): integer;
PROCEDURE isempty(): boolean;
END stack;
Verwendung in Anwender-Modul:
FROM stack IMPORT empty stack, push, pop, top;
.
.
.
empty stack();
push(42);
push(37);
WHILE NOT isempty() DO
WriteInt(top());
pop();
END;
145
Realisierung in MODULA-2 (mittels Feld fester Gr oe):
IMPLEMENTATION MODULE stack;
CONST size = 2500;
VAR s: ARRAY[1..size] OF integer;
c: [0..size];
PROCEDURE empty stack();
BEGIN
c := 0
END empty stack;
PROCEDURE isempty(): boolean;
BEGIN
RETURN c = 0
END isempty;
PROCEDURE push(x: integer);
BEGIN
c := c + 1;
s[c] := x
END push;
PROCEDURE pop();
BEGIN
c := c - 1
END pop;
PROCEDURE top(): integer;
BEGIN
RETURN s[c]
END top;
END stack;
(Fehlerbehandlung (Unter-/

Uberlauf) fehlt noch)

146
10.6.2 Beispiel: Abstraktes Datenobjekt

Stack in Java
In Java sind abstrakte Datenobjekte eher ungew ohnlich; Vorgabe ist der abstrakte Datentyp
(Abschnitt 10.7)bzw. die Klasse (Abschnitt 10.9).
Abstrakte Datenobjekte werden als Klassen realisiert, bei denen alle Methoden und Variablen
mittels static als Klassenmethoden und Klassenvariablen deklariert sind.
public class Stack
// Klassenvariablen und -Konstanten
// (nicht-offentlich)
private static final int size = 500;
private static int s[] = new int[size];
private static int c = -1;
//

Offentliche Funktionen
public static void empty() c = -1;
public static void push(int x) s[++c] = x;
public static void pop() --c;
public static int top() return s[c];
public static boolean isempty() return c == -1;

Auf size, s, und c kann von auerhalb der Klasse nicht zugegriffen werden!
Verwendung:
public class demo
public static void main(String[] args)
Stack.empty();
Stack.push(45);
int x = Stack.top();
Stack.pop();
System.out.println("x = " + x);

147
10.6.3 Beispiel: Abstraktes Datenobjekt

Stack in C
In C kann mit dem Schl usselwort static die Sichtbarkeit eines Objekts auf die jeweilige

Uber-
setzungseinheit (= Datei) eingeschr ankt werden.
In einer Header-Datei sind auerdem genau die Dienste deklariert, auf die von auen zugegriffen
werden darf.

Offentliche Schnittstelle stack.h:

extern void stack empty(void);
extern void stack push(int x);
extern void stack pop(void);
extern int stack top(void);
extern int stack isempty();
Realisierung stack.c:
#define SIZE 500
static int s[SIZE]; /
*
static: Nur innerhalb
*
/
static int c = -1; /
*
dieser Datei sichtbar
*
/
void stack empty() c = -1;
void stack push(int x) s[++c] = x;
void stack pop() --c;
int stack top() return s[c];
int stack isempty() return c == -1;
Verwendung:
#include <stdio.h> /
*
#include: Deklarationen
*
/
#include "stack.h" /
*
hier zuganglich machen
*
/
int main()

int x;
stack empty();
stack push(45);
x = stack top();
stack pop();
printf("x = %dn", x);

Ubung: Warum beginnt hier jeder Funktionsname mit stack ?

148
10.6.4 Schnittstellenentwurf
Die Schnittstelle (Signatur) mu alle f ur Benutzer wichtigen Operationen und Ressourcen ent-
halten.
Sie darf jedoch keine Information bereitstellen, die f ur das funktionale Verhalten des Moduls
ohne Belang sind.
Faustregel: Eine Schnittstelle soll genau die Dienste und Informationen bereitstellen, die ben otigt
werden, keinesfalls jedoch mehr.
Beispiel: Chemische Prozesteuerung in Java
Es m ussen st andig Mewerte wie Druck, Temperatur usw. ausgewertet werden
Daraus werden Steuersignale errechnet, die an diverse Aktoren gesendet werden
149
Variante 1 (

Ingenieur)
public class Control
// Direkter Zugang zu Sensor-Datenblock
public static int state[];
// Indizes der einzelnen Felder
public static final int PRESSURE = 0;
public static final int TEMP LOBYTE = 1;
public static final int TEMP HIBYTE = 2;
public static final int VALVES = 3;
// Bits in state[VALVES]
public static final int INPUT VALVE = 0x1;
public static final int OUTPUT VALVE = 0x2;
public static final int EMERGENCY VALVE = 0x4;
;
Zugriffsbeispiel:
int temperature =
Control.state[Control.TEMP LOBYTE] +
Control.state[Control.TEMP HIBYTE]
*
256;
if (temperature > 100)
Alarm.alarm("Feueralarm", 137);
Control.state[VALVES] |= EMERGENCY VALVE;
Control.state[VALVES] &= INPUT VALVE;
else
boolean input open = (state[VALVES] & INPUT VALVE) > 0);
Control.state[PRESSURE] = compute pressure(temperature);
.
.
.

Sehr schlecht, denn

Direkter Zugriff auf Sensor-Datenblock
Hauptprogramm kennt interne Kodierung der Mewerte

Anderung der Hardware bedingt ( uberall)

Anderung des Programms
150
Variante 2 (

Fortgeschrittener Ingenieur)
class Control
// Direkter Zugang zu Sensor-Datenblock
public static int state[];
// Indizes der einzelnen Felder
public static final int PRESSURE = 0;
.
.
.
// Bits in state[VALVES]
public static final int INPUT VALVE = 0x1;
public static final int OUTPUT VALVE = 0x2;
public static final int EMERGENCY VALVE = 0x4;
// Zugriffsfunktionen
public static int get temperature()
return state[TEMP LOBYTE] + state[TEMP HIBYTE]
*
256;

public static void set valves(int valves)

state[VALVES] = valves;

.
.
.
;
Schon besser, da jetzt Zustand uber Zugriffsfunktionen zug anglich.
Aber:
Nach wie vor direkter Zugang zum Zustand (state) m oglich
Nach wie vor werden Zustands-Interna nach auen sichtbar (hier: die Codierung der Ven-
tile)
151
Variante 3 (

Software-Ingenieur)
public class Control
// Zugriffsfunktionen
public static int get temperature() ...
public static boolean input valve open()
return valve open(INPUT VALVE);

public static void set input valve(boolean valve open)

set valve(INPUT VALVE, valve open);

// Interne Funktionen
private static void set valve(int valve, boolean valve open)
if (valve open)
state[VALVES] |= valve;
else
state[VALVES] &= valve;

private static boolean valve open(int valve)

return (state[VALVES] & valve) > 0;

.
.
.
// Interner Zustand
private static int state[];
// Interne Konstanten
private static final int PRESSURE = 0;
private static final int TEMP LOBYTE = 1;
.
.
.

Viel besser, denn

Physikalische Eigenschaften der Mef uhler wurden zum Geheimnis des Moduls
Sensoren k onnen ausgetauscht werden, ohne da das Kontrollprogrammsich darumk ummern
mu.
152
Schnittstellen und Efzienz
H aug wird behauptet, da Schnittstellen zu Lasten der Efzienz gingen.
Das ist in modernen Programmiersprachen jedoch nur bedingt richtig.
Da der Java-Compiler Zugang zu den Modul-Interna hat (in unserem Beispiel etwa state), kann
er im ubersetzten Code Funktionsaufrufe durch den Funktionsrumpf ersetzen; der (relativ teure)
Funktionsaufruf entf allt.
Ein Aufruf
boolean input open = input valve open();
etwa wird w ahrend des

Ubersetzungsprozesses zu
boolean input open = valve open(INPUT VALUE);
und dies wiederum zu
boolean input open = ((state[VALVES] & valve) > 0);
das genauso efzient ist wie der direkte Zugriff in Variante 1.
153
10.7 Abstrakte Datentypen (1980)
Ein abstrakter Datentyp (ADT) realisiert eine Menge von abstrakten Datenobjekten.
Bei allen Zugriffsfunktionen mu nun explizit angegeben werden, welches Objekt gemeint ist.
Hinzu kommen typischerweise spezielle Funktionen zum Erzeugen und Zerst oren von Objekten;
n utzlich sind auerdem Zuweisungs- und Vergleichsfunktionen.
10.7.1 Beispiel: Abstrakter Datentyp

Stack in Java
In Java werden ADTs als Klassen realisiert.
public class Stack
// Instanzvariablen und Klassenkonstanten
static final int size = 500;
int s[] = new int[size];
int c = -1;
//

Offentliche Funktionen
public void empty() c = -1;
public void push(int x) s[++c] = x;
public void pop() --c;
public int top() return s[c];
public boolean isempty() return c == -1;

Verwendung:
public class demo
public static void main(String[] args)
Stack s = new Stack();
s.empty();
s.push(45);
int x = s.top();
s.pop();
System.out.println("x = " + x);

Vorteil: beliebig viele Stacks pro Programm!

154
10.7.2 Beispiel: Abstrakter Datentyp

Stack in C
In C benutzt man opake Zeiger zum Realisieren von ADTs.

Offentliche Schnittstelle stack.h:

typedef struct stackrep
*
stack;
extern stack new stack();
extern void stack empty(stack);
extern void stack push(stack, int x);
extern void stack pop(stack);
extern int stack top(stack);
extern int stack isempty(stack);
extern void delete stack(stack);
Verwendung:
#include <stdio.h>
#include "stack.h"
int main()

stack st = new stack();

stack push(st, 45);
.
.
.

In stack.h ist stack als Zeiger auf ein stackrep (= stack representation) deniert, der ge-
naue Aufbau von stackrep fehlt jedoch. Deshalb kann von auen nicht auf Interna des ADT
zugegriffen werden.
stackrep wird in einer privaten Header-Datei deniert, die Zugang zu den Interna erm oglicht:
Private Deklarationen stackP.h:
#define STACK SIZE 500
struct stackrep
int s[STACK SIZE];
int c;
;
Die Implementierung greift auf stackP.h zur uck:
#include "stack.h"
#include "stackP.h"
155
stack new stack()
stack st = malloc(sizeof(struct stackrep));
stack empty(st);
return st;

void stack empty(stack st)

st->c = -1;

void stack push(stack st, int x)

st->s[++st->c] = x;

.
.
.
Auch hier k onnen Realisierungs-Details nach Belieben ver andert werden, solange die Schnitt-
stelle gleich bleibt.
156
10.7.3 Beispiel: Abstrakter Datentyp

Stack in MODULA-2
Auch in Modula-2 benutzt man opake Zeiger zum Realisieren von ADTs.
DEFINITION MODULE stack;
TYPE stacktype; (
*
opaker Typ
*
)
PROCEDURE new(): stacktype;
PROCEDURE push(s: stacktype; x: integer): stacktype;
PROCEDURE pop(s: stacktype): stacktype;
PROCEDURE top(s: stacktype): integer;
PROCEDURE delete(s: stacktype);
PROCEDURE isempty(s: stacktype): boolean;
END stack;
Verwendung:
FROM stack IMPORT stacktype, new, delete, push, pop, top;
VAR s1, s2: stacktype;
.
.
.
s1 := new();
s2 := new();
s1 := push(s1, 42);
s2 := push(s2, 17);
s1 := push(s1, 103);
s1 := pop(s1);
WHILE NOT isempty(s2) DO
WriteInt(top(s2));
s2 := pop(s2)
END;
delete(s1);
delete(s2);
157
Realisierung in MODULA-2 (mittels Feld fester Gr oe):
IMPLEMENTATION MODULE stack;
CONST size = 100;
TYPE stacktype = POINTER TO RECORD
s: ARRAY[1..size] OF integer;
c: [0..size]
END;
PROCEDURE new(): stacktype;
VAR st: stacktype;
BEGIN
NEW(st);
st.c := 0;
RETURN st
END new;
PROCEDURE push(s: stacktype; x: integer): stacktype;
.
.
.
PROCEDURE pop(s: stacktype): stacktype;
.
.
.
PROCEDURE top(s: stacktype): integer;
.
.
.
PROCEDURE delete(s: stacktype);
.
.
.
PROCEDURE isempty(s: stacktype): boolean;
.
.
.
END stack;
158
10.8 Generische Datenobjekte und Datentypen (1985)
Ein generischer Datentyp realisiert einen parametrisierten abstrakten Datentyp. Bestandteile des
Typs sind variabel z.B. der Objekttyp bei Containern.
Geht explizit nur in manchen Sprachen:
Ada generische Pakete
C++ Templates
Java generische Klassen
Funktionale Sprachen Polymorphismus
10.8.1 Beispiel: Generisches Datenobjekt

Stack in Ada
Modulkopf:
GENERIC
size: NATURAL; (
*
Parameter des generischen ADO
*
)
TYPE item IS PRIVATE;
PACKAGE stack IS
TYPE stacktype IS PRIVATE;
PROCEDURE emptystack() RETURN stacktype;
PROCEDURE push(s: IN stacktype; x: IN item)
RETURN stacktype;
PROCEDURE pop(s: IN stacktype) RETURN stacktype;
PROCEDURE top(s: IN stacktype) RETURN item;
END stack;
Verwendung im Anwender-Modul:
PACKAGE integer stack IS
NEW stack(size => 100, item => INTEGER);
PACKAGE string stack IS
NEW stack(size => 500, item => STRING);
VAR
s1: integer stack;
s2: string stack;
.
.
.
s1 := emptystack();
s2 := emptystack();
s1 := push(s1, 42);
s2 := push(s2, hugo);
159
Vorteil: Allgemeinheit, viel bessere Wiederverwendbarkeit
160
10.8.2 Beispiel: Generischer Datentyp

Stack in Java
Java Generics wurden 1997 in Pizza, einem Java-Dialekt, vorgestellt und sp ater in Java 1.5 uber-
nommen.
public class Stack<E>
// Instanzvariablen und Klassenkonstanten
static final int SIZE = 500;
E s[] = new E[SIZE];
int c = -1;
//

Offentliche Funktionen
public void empty() c = -1;
public void push(E x) s[++c] = x;
public void pop() --c;
public E top() return s[c];
public boolean isEmpty() return c == -1;
public boolean isFull() return c == SIZE;

Verwendung:
Stack<Integer> values = new Stack<Integer>();
values.push(42);
Stack<String> pizza = new Stack<String>();
pizza.push("Salami");
pizza.push("Kase");
pizza.push("Knoblauch");
pizza.push("Knoblauch");
pizza.push("Knoblauch");
Vorteil: Allgemeinheit, viel bessere Wiederverwendbarkeit
Analog f ur generische abstrakte Objekte.
161
10.9 Objekte und Klassen (1990)
Eine Klasse ist ein (anderes Wort f ur) abstrakter Datentyp.
Ein Objekt ist ein Exemplar eines abstrakten Datentyps.
10.9.1 Klassen
Wie ein Modul besteht auch eine Klasse aus einer Schnittstelle und einer Implementierung.
Die Schnittstelle speziziert die Methoden (Funktionen, Operationen) der Objekte der
Klasse, uber die auf den internen Zustand zugegriffen werden kann.
Die Implementierung deniert die Methodenr umpfe und die Zustandsvariablen (Instanz-
variablen, Eigenschaften, Attribute) der Objekte.
Beispiel: Klasse Account zur Verkapselung eines Kontos (UML-Darstellung)
Syntax Attribute (alle Teile bis auf attribut sind optional):
attribut[Multiplizit at] : Paket : : Typ = InitialwertZusicherungen
Syntax Methoden (alle Teile bis auf methode sind optional):
methode(Argumentliste): R uckgabetypZusicherungen
Der Pr ax gibt die Sichtbarkeit an (+: public, : private)
162
10.9.2 Objekte
Ein Objekt ist eine bestimmtes Exemplar (engl. instance) einer Klasse.
Es kann beliebig viele Objekte einer Klasse geben.
Objekte k onnen zur Laufzeit erzeugt werden.
Jedes Objekt einer Klasse hat einen eigenen Zustand (eigene Objekt- oder Instanzvariablen (engl.
instance variables) oder auch Attribute oder Fields genannt), aber dieselben Methoden.
Beispiel: Objekt konto 333 der Klasse Account
konto_333: Account
balance = 10000
minimum_balance = 0
owner = "Welthungerhilfe"
Objektname
und Klasse
Attribute
Die Methoden werden nicht explizit aufgef uhrt.
Beziehung zwischen Objekt und Klasse:
Account konto_333
<<instance of>>
163
10.9.3 Vererbung
Die zentrale Erweiterung im Objektorientierten Software-Entwurf ist: Eine Klasse (

Unterklas-
se) kann als Spezialisierung einer anderen Klasse (

Oberklasse) deniert werden.

Eine Unterklasse erbt (= verf ugt uber) alle Attribute und Methoden der Oberklasse, kann diese
jedoch umdenieren oder eigene dazuf ugen.
Die so entstehende Hierarchie zwischen Klassen heit Vererbungshierarchie.
Beispiel: Neue Klassen Checking Account (Girokonto) und Loan Account (Darlehenskonto)
als Spezialisierung der Oberklasse Account
Account
-balance: double
-minimum_balance: double
-owner: string
+open()
+deposit()
+withdraw()
+may_withdraw()
Checking_Account
-overdraft_limit: double
+set_overdraft_limit()
+may_withdraw()
+print_account_statement()
Loan_Account
-interest_rate: double
-amortization_amount: double
+set_interest_rate()
+may_withdraw()
Die Unterklasse Checking Account erbt alle Attribute und Methoden der Oberklasse Account.
Hinzu kommen ein neues Attribut overdraft limit (

Uberziehungsgrenze) und eine neue Me-

thode print account statement.
Die Methode may withdraw wird umdeniert n amlich so, da auf die

Uberziehungsgrenze
gepr uft wird.
Realisierung von Varianten ist eine der wichtigsten Anwendungen von Vererbung!
164
10.9.4 Vorteile des Objektorientierten Entwurfs
Hervorragende Modularisierung (Geheimnisprinzip, Koh asion, Kopplung)
Hervorragende Wiederverwendbarkeit
Gute Anlehnung an reale (z.B. graphische) Objekte
Daten und Funktionen werden zusammen beschrieben (und nicht durch zwei verschiedene
Formalismen)
165
10.9.5 Beispiel einer einfachen Objektdenition
Wir greifen das Beispiel

Kontof uhrung auf und realisieren es in Java.

Klassendenition
public class Account
// Attribute
protected double balance;
protected double minimum_balance;
protected String owner;
// Konstruktor (Initialisierung)
public Account()
balance = 0.00;
minimum_balance = -10.00;

// Nicht-offentliche Methoden
void add(double sum)
balance = balance + sum;

//

Offentliche Methoden
public void open(String who) owner = who;
public void deposit(double sum) add(sum);
public void withdraw(double sum) add(-sum);
public boolean may_withdraw(double sum)
return balance - sum >= minimum_balance;

Account-Verwender k onnen ausschlielich auf die als

offentlich (public) gekennzeichneten

Attribute und Methoden zugreifen.
Auf andere (nicht- offentliche, private) Attribute und Methoden (hier: balance, minimum balance,
owner) k onnen nur die Account-Methoden zugreifen!
Attribute werden gew ohnlich nicht- offentlich realisiert und allenfalls durch Methoden zug ang-
lich gemacht.
166
Verwendung
.
.
.
Account a1 = new Account();
Account a2 = new Account();
Account a3 = new Account();
a1.open("Fritz Brause");
a2.open("Richard Wagner");
a3.open("Andreas Zeller");
a1.deposit(500.00);
a2.deposit(42.00);
a3.deposit(5.00);
a1.withdraw(100.00);
a2.withdraw(50.00);
boolean test = a3.may_withdraw(50000.00);
.
.
.
In der Praxis wird der Konstruktor so realisiert, da Argumente zur Initialisierung gleich mit
ubergeben werden:
public class Account
.
.
.
// Konstruktor (Initialisierung)
public Account(String who, double min_balance)
balance = 0.00;
minimum_balance = min_balance;
open(who);

.
.
.
Verwendungsbeispiel:
Account a1 = new Account("Fritz Brause", 0.00);
Account a2 = new Account("Richard Wagner", -1000.00);
Account a3 = new Account("Andreas Zeller", -5000.00);
167
10.9.6 Einfache Vererbung
Die verschiedenen Konten-Varianten werden als Spezialisierung der gemeinsamen Oberklasse
Account dargestellt.
Klassendenition
public class Checking_Account extends Account
double overdraft_limit;
public void set_overdraft_limit(double limit)
overdraft_limit = limit;

public boolean may_withdraw(double sum)

return (balance + sum >=
minimum_balance - overdraft_limit);

public void print_account_statement()

...

public class Loan_Account extends Account

double interest_rate;
double amortization_amount;
public void set_interest_rate(double amount)
...

public boolean may_withdraw(double sum)

return false;

168
Klassen-Kompatibilit at
Objekte einer Unterklasse k onnen auch als Objekte der Oberklasse verwendet werden, da sie
alle Attribute und Methoden der Oberklasse haben; entsprechende Zuweisungen sind erlaubt.
Das umgekehrte gilt jedoch nicht!
.
.
.
Checking_Account a4 = new Checking_Account();
Loan_Account a5 = new Loan_Account();
a4.open("Walther Leisler Kiep");
a4.set_overdraft_limit(20000.00);
a5.open("CDU");
a5.set_interest_rate(20.00);
Account a1 = a4; // Ok
Account a2 = a5; // Ok
a1.deposit(500.00); // Ok
a1.withdraw(42.00); // Ok
if (a2.may_withdraw(5.00)) ... // Ok
1
a1.set_overdraft_limit(10000.00); // Verboten
=> Error: Method set_overdraft_limit(double)
not found in class Account
a2.set_interest_rate(10.00); // Verboten
=> Error: Method set_interest_rate(double)
not found in class Account
a4 = a1; // Verboten
=> Error: Incompatible type for =.
Explicit cast needed to convert Account
to Checking_Account.
a4 = a5; // Verboten
=> Error: Incompatible type for =.
Cant convert Loan_Account to Checking_Account.
.
.
.
1
Welche Methode wird hier aufgerufen? Siehe Abschnitt 10.9.7!
169
10.9.7 Dynamische Bindung
Jedes Objekt einer Unterklasse kann auch als Objekt der Oberklasse fungieren.
Unterklassen k onnen Oberklassenmethoden umdenieren. Deswegen kann man nur zur Laufzeit
bestimmen, welche Methode tats achlich aufgerufen wird.
Beispiel: Einrichten eines neuen Kontos
.
.
.
Account a;
if (kontentyp.einlesen())
a = new Loan_Account();
else
a = new Checking_Account();

if (a.may_withdraw(5.00)) ...
.
.
.
Welche may withdraw-Methode wird hier aufgerufen?
Wenn a auf ein Loan Account-Objekt verweist: die von Loan Account
Wenn a auf ein Checking Account-Objekt verweist: die von Checking Account
Diese dynamische Bindung (von Methoden-Aufrufen an Methoden-Denitionen) ndet zur Lauf-
zeit (dynamisch) statt im Gegensatz zur (herk ommlichen) statischen Bindung, die bereits beim

Ubersetzen stattndet.
170
Beispiel: Denition einer Grak
public abstract
2
class Shape
public abstract double area();

public class Circle extends Shape

protected
3
double radius;
protected static final
4
double PI =
3.14159265358979323846;
public Circle(double r)
radius = r;

public double area()

return PI
*
radius
*
radius;

public class Rectangle extends Shape

protected double width, height;
public Rectangle(double width, double height)
this.width = width; // this: Objekt, auf das
this.height = height; // sich die Methode bezieht

public double area()

return width
*
height;

171
Benutzung:
// Feld von Shapes
Shape shapes[] = new Shape[3];
shapes[0] = new Circle(2.0);
shapes[1] = new Rectangle(1.0, 3.0);
shapes[2] = new Rectangle(4.0, 2.0);
// Flachen aufsummieren
double total_area = 0.0;
for (int i = 0; i < shapes.length; i = i + 1)
total_area = total_area + shapes[i].area();
Auch hier wird f ur jedes Element dynamisch bestimmt, welche area()-Methode aufgerufen
wird.
2
Shape ist ein Beispiel f ur eine abstrakte Oberklasse, die nur das Auenverhalten, nicht jedoch den vollst andi-
gen inneren Aufbau beschreibt: f ur wenigstens eine Methode fehlt die Implementierung (hier area()). Solche
abstrakten Methoden werden in den konkreten (nicht-abstrakten) Unterklassen deniert. Abstrakte Klassen k onnen
nicht instantiiert werden es gibt nur konkrete Objekte.
3
protected-Elemente sind f ur Unterklassen zug anglich
4
static-Elemente werden von allen Objekten geteilt; final steht f ur Elemente und Methoden, die von Un-
terklassen nicht redeniert werden k onnen PI ist also eine Konstante.
172
Dynamische Bindung vs. Fallunterscheidung
Bei herk ommlichem Entwurf ohne dynamische Bindung mu eine Fallunterscheidung herhalten,
um unterschiedliche Objekte gleichzeitig zu verwalten.
Beispiel mit varianten Records in MODULA-2:
PROCEDURE area(s: Shape): REAL
BEGIN
CASE s.typeid OF
Circle:
RETURN PI
*
s.circle.radius
*
s.circle.radius;
Rectangle:
RETURN s.rectangle.width
*
s.rectangle.height;
.
.
.
END
Nachteil: Bei jeder Einf uhrung eines neuen Shape-Typs m ussen s amtliche Fallunterscheidungen
uberpr uft und ggf. erweitert werden immenser Aufwand!
Mit dynamischer Bindung hingegen ist noch nicht einmal eine Neu ubersetzung der bisherigen
Klassen n otig.
Dynamische Bindung vs. Statische Bindung
Dynamische Bindung ist durch das Aufsuchen der geeigneten Methode geringf ugig teurer als die
(herk ommliche) statische Bindung, die bereits beim

Ubersetzen stattndet.
Oft kann der

Ubersetzer aber erkennen, da nur eine Methode in Frage kommt, und deshalb
statisch binden.
Beispiel:
Shape s = new Rectangle(1.0, 2.0);
double area = s.area();
Hier kann nur die area()-Methode von Rectangle in Frage kommen; der area()-Aufruf
kann statisch gebunden werden.
In der Praxis: Optimierung durch Sprungtabellen, nicht redenierbare Methoden (nicht-virtual
in C++) oder nicht erweiterbare Klassen (final in Java).
173
10.9.8 Mehrfache Vererbung
Mehrfache Klassenvererbung
Bei der Erstellung von Vererbungshierarchien kann es zu mehrfacher Vererbung kommen:
PCHndler Bcker
Kaufmann Rennfahrer
Geschftsmann Sportler
Mensch
Sportstudent Informatikstudent
Student
Ein B acker und ein Informatikstudent haben alle Eigenschaften eines Menschen (sowie weitere);
ein Sportstudent hat alle Eigenschaften von Sportlern und Studenten (sowie ggf. weitere).
Ein Problem bei mehrfacher Vererbung ist der Konikt bei mehrfacher Vererbung von Imple-
mentierungen: Wenn Sportler und Student unterschiedliche aufstehen()-Methoden im-
plementieren welche Implementierung wird dann in Sportstudent geerbt?
Weitere Probleme bei mehrfacher Vererbung sind:
Efzienz der dynamischen Bindung (Durchsuchen der Klassenhierarchie),
mehrfaches Erben von Oberklassen (ein gemeinsames Exemplar der Oberklasse oder
mehrere getrennte?)
174
Schnittstellenvererbung
In Java werden die Probleme der mehrfachen Klassenvererbung mit Hilfe von Interfaces (Schnitt-
stellen) umgangen:
Interfaces sind abstrakte Oberklassen, die keine Attribute enthalten d urfen.
Eine Klasse kann von mehreren Interfaces erben und mu alle abstrakten Methoden der
Interfaces implementieren (d.h. die Schnittstellen realisieren).
Interfaces k onnen ebenfalls von anderen (ggf. mehreren) Interfaces erben.
In unserem Beispiel k onnte dies so aussehen:
public interface Mensch ...
public interface Sportler extends Mensch
public void aufstehen();
public void sport_treiben();

public interface Student extends Mensch

public void aufstehen();
public void lernen();

public class Sportstudent implements Sportler, Student

public void aufstehen() ...
public void sport_treiben() ...
public void lernen() ...

Sportstudent k onnte hier auch als Interface realisiert werden, um weitere mehrfache Verer-
bung zu erm oglichen (z.B. einen PCs verkaufenden, Sportinformatik studierenden B acker).
Eine gesonderte Klasse Konkreter Sportstudent m ute dann das Interface Sportstudent
realisieren:
public interface Sportstudent extends Sportler, Student
// Keine neuen Methoden

public class Konkreter_Sportstudent

implements Sportstudent
public void aufstehen() ...
public void sport_treiben() ...
public void lernen() ...

175
Beispiel: Chemische Prozesteuerung mit Interfaces
Eine weiter verbesserte chemische Prozesteuerung aus Abschnitt 10.6.4:
public interface Control
// Zugriffsfunktionen
public int get temperature();
public boolean get input valve();
public void
set input valve(boolean new state);
;
public class RaffinerieControl implements Control
// Zugang zu Sensor-Datenblock
private int state[];
// Indizes der einzelnen Felder
private static final int PRESSURE = 0;
private static final int TEMP LOBYTE = 1;
private static final int TEMP HIBYTE = 2;
private static final int VALVES = 3;
// Bits in state[VALVES]
private static final int INPUT VALVE = 0x1;
private static final int OUTPUT VALVE = 0x2;
private static final int EMERGENCY VALVE = 0x4;
public int get temperature()
return state[TEMP LOBYTE] +
state[TEMP HIBYTE]
*
256;

.
.
.
;
Neue Steuerungshardware wird durch eine neue Klasse realisiert, die das Control-Interface
implementiert. Das Control-Interface (und der Rest des Programms) bleiben unver andert.
176
10.9.9 Vorteile des Vererbungsmechanismus
Trennung der gemeinsamen Eigenschaften von Objektmengen von individuellen Eigen-
schaften von Objekten
Hierarchische Klassikation von Objekten
Konstruktion allgemeiner Klassen, die spezialisiert werden k onnen
Wiederverwendung durch Ableitung neuer Klassen aus alten
Parametrisierte Klassen erlauben universell anwendbare Bausteine
Beispiel: Die Standard Template Library in C++
Schrittweise Evolution von Modulen durch Redenition/Hinzuf ugen von Funktionen in
einer Unterklasse
Varianten k onnen als Unterklassen einer Klasse beschrieben werden; die Unterklassen ent-
halten nur die variantenspezischen Funktionen
177
10.10 Subjekte und Aspekte (2000)
M ogliches Problem bei objektorientierter Modellierung: Crosscutting Concerns.
Bei der Separation der Interessen eines Systems kann es geschehen, dass sich Eigenschaften
miteinander uberschneiden und sich nicht sauber separieren lassen.

Ublicherweise wird die als wichtiger erscheinende Eigenschaft vorgezogen und gekapselt.
Die sekund are Eigenschaft, der Crosscutting Concern, bleibt ungekapselt
Standardbeispiel: Logging
Es gibt einige Ans atze zur Behandlung von Crosscutting Concerns:
Aspect-oriented Programming Crosscutting Concerns werden in sog. Aspekten gekapselt. Die
Punkte des Programms, an denen der Aspekt ausgef uhrt werden soll, k onnen durch Regeln
beschrieben werden. Ein sog. Aspect Weaver f ugt beim Kompilieren den Aspekt-Code an
diesen Punkten ein.
Feature-oriented Programming S amtliche Eigenschaften eines Programms werden in sog. Fea-
tures gekapselt. Aus ihnen kann dann das Programm synthetisiert werden. Dazu m ussen
allerdings auch die Funktionen f ur die Synthese entwickelt werden. Daher ist dieser Ansatz
vor allem auf Produktfamilien bezogen.
Subject-oriented Programming ist ein Ansatz zur Komposition von objektorientierten Pro-
grammen aus Subjekten. Ein Subjekt besteht aus einer Sammlung von Klassen oder Klas-
senfragmenten mit einer bestimmten Aufgabe.
Die Subjekt-Komposition kombiniert die Klassen der einzelnen Subjekte; das Resultat ist
wiederum ein Subjekt.
Schwierigkeit dabei: Regeln zur Komposition von Subjekten m ussen erstellt werden.
178
Kapitel 11
Objektorientierter Entwurf
In diesem Kapitel werden wir untersuchen, wie die Komponenten eines Systems in Hinblick auf
Gemeinsamkeiten und sp atere

Anderungen ausgesucht werden.
Hierzu dient uns der objektorientierte Entwurf.
11.1 Objektorientierte Modellierung
Die Objektorientierte Modellierung mit UML umfat u.a. folgende Aspekte des Entwurfs:
Objekt-Modell:
Welche Objekte ben otigen wir?
Welche Merkmale besitzen diese Objekte? (Attribute, Methoden)
Wie lassen sich diese Objekte klassizieren? (Klassenhierarchie)
Welche Assoziationen bestehen zwischen den Klassen?
Sequenzdiagramm:
Wie wirken die Objekte global zusammen?
Zustandsdiagramm:
In welchen Zust anden benden sich die Objekte?
179
11.2 Objekt-Modell: Klassendiagramm
Darstellung der Klassen als Rechtecke, unterteilt in
Klassenname,
Attribute m oglichst mit Typ (meistens ein Klassenname)
Methoden m oglichst mit Signatur
Darstellung der Vererbungshierarchie ein Dreieck (Symbol: ) verbindet Oberklasse und Un-
terklassen.
Beispiel f ur Vererbung: Konten
1
(Vergleiche Abschnitt 10.9.3)
Account
-balance: double
-minimum_balance: double
-owner: string
+open()
+deposit()
+withdraw()
+may_withdraw()
Checking_Account
-overdraft_limit: double
+set_overdraft_limit()
+may_withdraw()
+print_account_statement()
Loan_Account
-interest_rate: double
-amortization_amount: double
+set_interest_rate()
+may_withdraw()
Ererbte Methoden (wie hier: open(), deposit()) werden in der Unterklasse nicht mehr ge-
sondert aufgef uhrt.
Wird eine Methode wie may withdraw() in Unter- und Oberklasse aufgef uhrt, so uberschreibt
die Denition in der Unterklasse die Denition in der Oberklasse.
1
Die Beispiele dieses Kapitels sind entnommen aus: G. Goos, Vorlesungen uber Informatik. Band 2: Objektori-
entiertes Programmieren und Algorithmen, Springer 1996, sowie Bernd Oestereich, Objektorientierte Softwareent-
wicklung, Oldenbourg 1998.
180
Modier f ur Methoden und Attribute
+ f ur public
- f ur private
f ur protected
statische Methoden und Attribute werden unterstrichen
181
11.2.1 Abstrakte Klassen und Methoden
Klassen, von denen keine konkreten Objekte erzeugt werden k onnen, heien abstrakte Klassen.
Sie verf ugen meist uber eine oder mehrere abstrakte Methoden, die erst in Unterklassen realisiert
werden.
Eine konkrete Klasse ist eine Klasse, von der konkreten Objekte erzeugt werden k onnen.
Beispiel f ur abstrakte Klassen: Digitale Abspielger ate
Ein

Digitales Abspielger at ist ein abstrakter Oberbegriff f ur konkrete Realisierungen etwa

einen CD-Spieler oder einen MP3-Spieler.
Digitales Abspielgert
-Ausgabeleistung: int
-Rauschpegel: int
+Wiedergabe starten / anhalten()
+Vorlauf / Rcklauf()
+nchster / voriger Titel()
+alle Titel anspielen()
CD-Spieler
+Wiedergabe starten / anhalten()
+Vorlauf / Rcklauf()
+nchster / voriger Titel()
MP3-Spieler
+Wiedergabe starten / anhalten()
+Vorlauf / Rcklauf()
+nchster / voriger Titel()
Kursiver Klassen-/Methodenname: abstrakte Klasse/Methode
Die Methode alle Titel anspielen() wird bereits in der abstrakten Oberklasse realisiert
sie ruft nachster Titel() und die Wiedergabe-Methoden auf, die in den konkreten Unter-
klassen realisiert werden.
Die Oberklasse einer abstrakten Klasse ist immer eine abstrakte Klasse.
182
11.2.2 Initialwerte und Zusicherungen
Die Attribute eines Objekts k onnen mit Initialwerten versehen werden. Diese gelten als Vorgabe,
wenn bei der Konstruktion des Objekts nichts anderes angegeben wird.
Mit Zusicherungen werden Bedingungen an die Attribute speziziert. Hiermit lassen sich Inva-
rianten ausdr ucken Objekt-Eigenschaften, die stets erf ullt sein m ussen.
Beispiel f ur Zusicherungen: Figuren-Bibliothek
(Vergl. Abschnitt 10.9.7)
Die Zusicherungen garantieren, da Kreise immer einen positiven Radius haben und Rechtecke
positive Kantenl angen.
Shape
-position: Point = (10, 10)
+area(): double
+draw()
+set_position(position:Point)
+get_position(): Point
Circle
-radius: double = 1 {radius > 0}
+area(): double
+draw()
+set_radius(radius:double)
+get_radius(): double
Rectangle
-a: double = 10 {a > 0}
-b: double = 10 {b > 0}
+area(): double
+draw()
+set_a(length:double)
+set_b(length:double)
+get_a(): double
+get_b(): double
Initialwert
Zusicherung
183
11.2.3 Das Problem der Spezialisierung
Eine Unterklasse ist eine Spezialisierung einer Oberklasse, wenn sie
weitere Zusicherungen uber die Attribute der Oberklasse enth alt
weitere Vorbedingungen uber die Methoden der Oberklasse enth alt
Klassenhierarchien sollten Spezialisierung vermeiden.
Beispiel f ur Spezialisierung: Reelle und komplexe Zahlen
Jede reelle Zahl ist auch eine komplexe Zahl (mit Imagin arteil 0). Sollten deshalb reelle Zahlen
Unterklassen der komplexen Zahlen werden?
Complex
-real: double = 0.0
-imag: double = 0.0
+set_real(real:double)
+set_imag(imag:double)
?
Real
{imag == 0}
Problem: set imag, von Complex geerbt, w urde die Zusicherung von Real verletzen.
2
Analog: Ein Quadrat

ist ein Rechteck. Ist Square eine Unterklasse von Rectangle, verletzt
set a die Zusicherung von Square.
Rectangle
-a: double = 10 {a > 0}
-b: double = 10 {b > 0}
+area(): double
+draw()
+set_a(length:double)
+set_b(length:double)
Square
{a = b}
?
2
Man k onnte Real mit einer eigenen Implementierung von set imag versehen. Deren Vorbedingung
imag == 0 w urde aber ebenfalls zu einer Spezialisierung f uhren.
184
11.2.4 Ziel: Konformanz
Konformanz bedeutet, da ein Objekt einer Unterklasse in jeder Beziehung als Objekt der Ober-
klasse einsetzbar ist.
Klassenhierarchien sollten so konstruiert werden, da Konformanz stets sichergestellt ist.
In folgendem Beispiel ist die Konformanz verletzt. Von einer existierenden Klasse TextFile
hat ein Programmierer eine Klasse f ur bin are Dateien abgeleitet, um deren Methoden zu erben
(sogenanntes Erben von Implementierungen).
TextFile
-s: stream = void {nur ASCII-Zeichen}
+put(c:char)
+get(): char
BinaryFile
+put(b:byte)
+get(): byte
ruft TextFile.put(b) auf
?
Die Methoden des BinaryFile verletzen jedoch die Zusicherung des TextFile.
Selbst wenn die Methoden von TextFile funktionieren sollten wird irgendwo im Programm
ein TextFile erwartet, das die Zusicherung erf ullt, stattdessen jedoch ein BinaryFile uber-
geben, kann dies zu beliebigen Problemen f uhren.
Das Gegenst uck zur Konformanz ist die Spezialisierung. Bei ihr kann ein Objekt der Unterklasse
nicht in jeder Beziehung als Objekt der Oberklasse eingesetzt werden. Spezialisierung tritt vor
allem beim Ererben von Implementierungen auf. Soll Spezialisierung vermieden werden, sollte
das Erben von Implementierungen ausbleiben. Die Alternative ist das Benutzen von anderen
Klassen (ohne Vererbung), wobei Teile der Schnittstelle nachgebildet werden (sog. Delegation).
In unserem Beispiel k onnte BinaryFile ein TextFile benutzen, um Bin ardaten (in ASCII-
Zeichen kodiert) abzulegen.
185
Auch ohne explizite Zusicherungen kann die Konformanz verletzt sein.
Rectangle l at sich als Unterklasse von Square einrichten, wobei man die Kantenl ange a erbt:
Square
-a: double = 10 {a > 0}
+area(): double
+draw()
+set_a(length:double)
Rectangle
-b: double = 10 {b > 0}
+area(): double
+draw()
+set_b(length:double)
?
Auch hier ist die Konformanz verletzt: Wird irgendwo ein Quadrat bearbeitet, jedoch ein Recht-
eck ubergeben, wird nur die Kantenl ange a ber ucksichtigt.
Im Fall reelle/komplexe Zahlen k onnte eine solche Anordnung jedoch Sinn machen: Jede kom-
plexe Zahl kann als reelle verwendet werden (wobei die Funktionalit at auf den Realteil be-
schr ankt ist).
Real
-real: double = 0.0
+set_real(real:double)
Complex
-imag: double = 0.0
+set_imag(imag:double)
Frage ist, ob eine solche implizite Umwandlung von komplexen in reelle Zahlen nicht mehr
Risiken als Nutzen bringt.
186
Um tats achlich Quadrate und Rechtecke zu modellieren, bieten sich zwei Wege an. Man kann
Quadrate und Rechtecke als separate Klassen modellieren, die durch eine neue gemeinsame
Oberklasse verbunden sind:
Quadrangle
+area(): double
+draw()
+get_a(): double
+get_b(): double
Square
-a: double = 10 {a > 0}
+get_a(): double
+get_b(): double
+set_a(a:double)
Rectangle
-a: double = 10 {a > 0}
-b: double = 10 {b > 0}
+get_a(): double
+get_b(): double
+set_a(length:double)
+set_b(length:double)
gibt a zurck
Alternativ kann man sich auf den Standpunkt stellen, da jedes Rechteck ein Quadrat sein kann
n amlich dann, wenn die beiden Seiten gleich lang sind.
Man k onnte also auf eine eigene Klasse f ur Quadrate verzichten und stattdessen Rechtecke um
eine besondere Methode is square erweitern:
Rectangle
-a: double = 10 {a > 0}
-b: double = 10 {b > 0}
+area(): double
+draw()
+set_a(length:double)
+set_b(length:double)
+is_square(): boolean
return a == b
Nach dem gleichen Muster k onnen auch Text-/Bin ar-Dateien und reelle/komplexe Zahlen mo-
delliert werden.
187
11.2.5 Schnittstellen
Schnittstellen (vergl. Abschnitt 10.9.8)sind mit dem Schl usselwort interface gekennzeichnet.
Die implementierungs-Beziehung ist gestrichelt dargestellt und besitzt einen geschlossenen, nicht
ausgef ullten Pfeil.
Beispiel: Eine Person realisiert sowohl eine Patienten- als auch eine Arbeitnehmerschnittstelle
Kurzschreibweise mit

Lolli
Person
-gesundheit
-qualifikation
+get_gesundheit()
+get_qualifikation()
Patient
Arbeitnehmer
188
11.3 Objekt-Modell: Assoziationen
11.3.1 Allgemeine Assoziationen
Verbindungen zwischen nicht-verwandten Klassen stellen Assoziationen (Relationen) zwi-
schen Klassen dar
Diese beschreiben den inhaltlichen Zusammenhang zwischen Objekten (vgl. Datenbanktheo-
rie!)
Durch Multiplizit aten wird die Anzahl der assoziierten Objekte eingeschr ankt.
Beispiel f ur Assoziationen mit Multiplizit atsangaben:
Ein Rechnerh andler hat mehrere Kunden, ein Zusteller hat mehrere Kunden, aber ein Rech-
nerh andler hat nur einen Zusteller
Kunde
-name: string
-adresse: string
Zusteller
-name: string
-adresse: string
Rechnerhndler
-name: string
-adresse: string
ist kunde von 0..*
1
ist kunde von 0..*
1
ist zusteller von
0..*
1
189
Beispiel: Professoren haben mehrere Studenten, Studenten haben mehrere Professoren
Professor
-name: string
Student
-name: string
hrt bei 0..*
0..*
Beispiel f ur Objektbeziehungen:
p1: Professor
name = "Gregor"
p2: Professor
name = "Andreas"
s1: Student
name = "Georg"
s4: Student
name = "Grete"
s3: Student
name = "Gustav"
s2: Student
name = "Gerda"
hrt bei
hrt bei
hrt bei
hrt bei
Darstellung von Exemplaren (Objekten) mit unterstrichenem Objektnamen f ur die Attribute
sind konkrete Werte angegeben
190
11.3.2 Aggregation
Eine h aug auftretende und deshalb mit besonders markierte Assoziation ist die hat-Beziehung,
die die Hierarchie zwischen einem Ganzen und seiner Teile ausdr uckt.
Beispiel: Ein Pkw hat 34 R ader
Pkw
hat
1
3..4
Rad
Beispiel: Ein Unternehmen hat 1..* Abteilungen mit jeweils 1..* Mitarbeitern
Unternehmen
besteht aus
1
1..*
Abteilung
umfat
1
1..*
Mitarbeiter
Ein Aggregat kann (meistens zu Anfang) auch ohne Teile sein: die Multiplizit at 0 ist zul assig.
Gew ohnlich ist es jedoch Sinn eines Aggregats, Teile zu sammeln.
Bei einem Aggregat handelt das Ganze stellvertretend f ur seine Teile, d.h. es ubernimmt Opera-
tionen, die dann an die Einzelteile weiterpropagiert werden.
Beispiel: Methode berechneUmsatz() in der Klasse Unternehmen, die den Umsatz der Ab-
teilungen aufsummiert.
191
11.3.3 Komposition
Ein Sonderfall der Aggregation ist die Komposition, markiert mit .
Eine Komposition liegt dann vor, wenn das Einzelteil vom Aggregat existenzabh angig ist also
nicht ohne das Aggregat existieren kann.
Beispiel: Rechnungsposition
Eine Rechnungsposition geh ort immer zu einer Rechnung.
Rechnung
hat
1
1..*
Rechnungsposition
Beispiel: Buch
Ein Buch besteht aus Inhaltsverzeichnis, mehreren Kapiteln, Index; ein Kapitel besteht aus meh-
reren Abschnitten usw.
Buch
hat
0..*
1
hat
1
1
hat
0..*
1
Kapitel Abschnitt
hat
1
Inhaltsverzeichnis
Index
Absatz
hat
1
1
0..*
0..*
0..*
0..*
192
Beispiel: Kreiseck
Ein

Kreiseck besteht aus einem ubereinander gelegten Quadrat und einem Kreis:
Modellierung als Klasse SquareCircle, die sowohl einen Kreis als auch ein Quadrat enth alt:
Shape
-position: Point = (10, 10)
+area(): double
+draw()
+set_position(position:Point)
+get_position(): Point
Circle
-radius: double = 1 {radius > 0}
+area(): double
+draw()
+set_radius(radius:double)
+get_radius(): double
Rectangle
-a: double = 10 {a > 0}
-b: double = 10 {b > 0}
+area(): double
+draw()
+set_a(length:double)
+set_b(length:double)
+get_a(): double
+get_b(): double
SquareCircle
{2 * k.radius = r.a = r.b}
+set_a(length:double)
+resize(factor:double)
Erg anzungen
Ein Einzelteil kann immer nur von einem Aggregat existenzabh angig sein.
Eine Klasse kann auch als Komposition aller ihrer Attribute aufgefat werden.
In vielen Programmiersprachen werden Aggregationen durch Referenzen (Zeiger auf Objekte)
realisiert, Kompositionen jedoch durch die Werte selbst.
193
11.3.4 Rollen
An jedem Ende einer Assoziation k onnen Rollennamen vergeben werden. Ein Rollenname be-
schreibt, wie das Objekt durch das in der Assoziation gegen uberliegende Objekt gesehen wird.
Beispiel (vergl. Abschnitt 11.2.5): Eine Person wird vom Arbeitgeber als Arbeitnehmer, vom
Hausarzt als Patient gesehen.
Person
+get_gesundheit()
+get_qualifikation()
Firma
Arzt
+arn: Arbeitnehmer
+Patient
Arbeitgeber
Hausarzt
<<interface>>
Arbeitnehmer
+get_qualifikation()
Zus atzlich zum Rollennamen kann der Name einer Schnittstelle angegeben werden, die von der
jeweiligen Klasse implementiert wird (hier: die Schnittstelle Arbeitnehmer zum Rollennamen
arn).
In diesem Fall wird der Umfang der Assoziation eingeschr ankt es sind nur noch die Attribu-
te/Methoden der Schnittstelle sichtbar.
In obigem Beispiel kann etwa die Firma nicht auf die Patientendaten zugreifen.
194
11.3.5 Mehrgliedrige Assoziationen
Neben Zweierbeziehungen gibt es noch mehrgliedrige Assoziationen Assoziationen, an denen
drei oder mehr Klassen beteiligt sind.
Tern are Assoziationen
Beispiel f ur eine tern are (dreigliedrige) Assoziation: Studenten h oren Vorlesungen bei Professo-
ren
Professor
+name: string
Student
+name: string
hlt
1
hrt
+1
Vorlesung
+titel: string
1..*
Mehrgliedrige Assoziationen lassen sich gew ohnlich in normale Assoziationen umformen:
Professor
+name: string
Student
+name: string
hlt
1
1..*
hrt
1..*
Vorlesung
+titel: string
1..*
1..*
195
Mehrgliedrige Assoziationen
Beispiel f ur eine viergliedrige Assoziation: Fahrg aste reservieren Pl atze f ur Abschnitte von Z ugen.
Zug
+datum:
+zugnr:
Abschnitt
+von_bahnhof:
+bis_bahnhof:
Fahrgast
+name:
+geschlecht:
Platz
+wagen_nr:
+platz_nr:
1
1..*
1
1..*
Reservierung
Auch hier gibt es eine Umformung in normale Assoziationen:
Zug
+datum:
+zugnr:
Abschnitt
+von_bahnhof:
+bis_bahnhof:
Fahrgast
+name:
+geschlecht:
Platz
+wagen_nr:
+platz_nr:
1
0..* 0..*
1..*
0..*
0..*
1
1..*
Reservierung
196
11.4 Formale Zusicherungen
Neben Attributen k onnen beliebige UML-Elemente mit Zusicherungen versehen werden. Dies
geschieht entweder frei formuliert oder mit Hilfe der UML-eigenen Object Constraint Language,
kurz OCL.
11.4.1 Beispiel: Projektleitung
Der Leiter eines Projekts rekrutiert sich aus den Reihen der Projektmitglieder.
Informale Zusicherung:
hat
Leiter
1
besteht aus
Projektmitglied
1..*
{subset}
Projekt
Mitarbeiter
Die Zusicherung ist als subset frei formuliert mit der Bedeutung projektleiter projektmitglieder.
Formale Zusicherung:
hat
Leiter
1
besteht aus
Projektmitglied
1..*
Projekt
Mitarbeiter
Projekt
self.projektmitglieder->
includes(self.projektleiter)
Der OCL-Ausdruck
self .projektmitglieder includes(self .projektleiter)
bedeutet, da die Mengenoperation includes, die auf die Menge der Projektmitglieder angewandt
wird, und der der Projektleiter als Argument ubergeben wird, den Wert true liefern mu.
197
11.4.2 Beispiel: Reservierungen
Die Anzahl der reservierten Pl atze (vergl. Abschnitt 11.3.5) mu mit der Anzahl der Fahrg aste
ubereinstimmen
Zug
+datum:
+zugnr:
Abschnitt
+von_bahnhof:
+bis_bahnhof:
Fahrgast
+name:
+geschlecht:
Platz
+wagen_nr:
+platz_nr:
1
0..* 0..*
1..*
0..*
0..*
1
1..*
Reservierung
Reservierung
self.platz->size ==
self.fahrgast->size
Die Operation size gibt die Anzahl der Elemente zur uck.
11.4.3 Weitere OCL-Beispiele
Das Gehalt des Mitarbeiters mu kleiner sein als das Gehalt des Chefs:
mitarbeiter.gehalt < chef.gehalt
Die Person mu vollj ahrig sein:
person.alter >= 18
Eine Person mu mindestens eine Anschrift haben
not person.anschriften->isEmpty oder
person.anschriften->size >= 1
Alle Fahrer eines Mietwagens m ussen alter als 21 sein
self.fahrer->forAll(f | f.alter >= 21)
Solche Zusicherungen k onnen ggf. in Zusicherungen der Programmiersprache ubersetzt werden,
die dann zur Laufzeit Verletzungen aufdecken.
198
11.5 Sequenzdiagramme
Ein Sequenzdiagramm gibt den Informationsu zwischen einzelnen Objekten wieder mit Beto-
nung des zeitlichen Ablaufs.
Objekte werden mit senkrechten Lebenslinien dargestellt; die Zeit verl auft von oben nach unten.
Der Steuerungsfokus (breiter Balken) gibt an, welches Objekt gerade aktiv ist. Ruft eine Methode
eines aktiven Objekts (indirekt) eine weitere Methode des Objekts auf, wird dies durch multiple
Balken dargestellt.
Pfeile (

Nachrichten) kennzeichnen Informationsu z.B. Methodenaufrufe (durchgehende

Pfeile) und R uckkehr (gestrichelte Pfeile). Pfeilspitzen von Methodenaufrufen treffen mit dem
Anfang des erzeugten Steuerungsfocus zusammen, R uckkehr-Pfeile beginnen am Ende des be-
endeten Steuerungsfocus.
199
11.5.1 Beispiel: Vergr oern eines Kreisecks
(Vergl. Abschnitt 11.3.3)
Folgender Ablauf ist zum Vergr ossern eines Kreisecks modelliert:
: Kreiseck r: Rechteck
k: Kreis
Benutzer
resize(factor)
get_a()
a
set_a(a)
set_radius(a / 2)
set_a(a)
set_b(a)
Neues a:
a = a * factor
200
Aus diesem Sequenzdiagramm l asst sich anschliessend folgender Code entwickeln:
class SquareCircle
private Rectangle r;
private Circle c;
public void resize(double factor)
double a = r.get_a();
a = a
*
factor;
set_a(a);

public void set_a(double length)

c.set_radius(length / 2);
r.set_a(length);
r.set_b(length);

...

class Rectangle
private double a;
private double b;
public double get_a()
return a;

public void set_a(double length)

a = length;

public void set_b(double length)

b = length;

...

201
class Circle
private double radius;
public double get_a()
return a;

public void set_radius(double radius)

radius = length;

...

202
11.5.2 Beispiel: Erzeugen und L oschen von Objekten
Situation: ein Benutzer m ochte in einem Hotel ein Zimmer f ur eine bestimmte Anzahl von Tagen
reservieren. Sp ater sagt er die erhaltene Reservierung ab.
hotel: Hotel
reservation:
Reservation
Benutzer
reservation(days)
[is_room] <<create>>
cancel(reservation)
Falls ein Raum fr
jeden Tag frei ist:
Reserviere den Raum
is_room := available(day)
reservation
<<destroy>>
X
loop
[for each day: days]
Zun achst pr uft das Hotel, ob es ein Zimmer gibt, das an s amtlichen Tagen frei ist. Dazu wird
uber die Tage iteriert.
die Struktur loop [...] beschreibt eine Iteration, in der Klammer steht die Abbruchbedin-
gung
Falls ein Zimmer zur Verf ugung steht, wird ein Objekt des Typs Reservation erzeugt und
zur uckgegeben.
das Erzeugen von Objekten wird mit dem Schl usselwort create gekennzeichnet
203
Ausdr ucke in [] stellen Bedingungen dar
Sp ater widerruft der Benutzer die Reservierung. Das Hotel l oscht die Reservierung.
das L oschen von Objekten wird mit dem Schl usselwort destroy gekennzeichnet
die Lebenslinie endet an diesem Punkt mit einem Kreuz
204
11.5.3 Beispiel: Darstellung von Nebenl augkeit
Zur Darstellung von Nebenl augkeit k onnen asynchrone Nachrichten verwendet werden. Diese
werden durch Pfeile mit halben K opfen dargestellt.
tutor: Tutor group: Course
administration:
Administration
room := free_room(day)
time := meeting_time()
reserve(room, day, time)
Im Beispiel m ochte ein Tutor einen Raum f ur ihre Gruppe an einem bestimmten Tag reservieren.
Dazu ben otigt sie einen Raum und eine genaue Uhrzeit. Diese Information kann sie in beliebiger
Reihenfolge erhalten, daher die Nebenl augkeit. Anschliessend wird der Raum reserviert.
205
11.6 Kommunikationsdiagramme
Kommunikationsdiagramme beschreiben ebenfalls den Informationsu zwischen einzelnen Ob-
jekten.
Im Gegensatz zu Sequenzdiagrammen betonen sie aber die Beziehungsstruktur der Objekte.
11.6.1 Beispiel: Vergr oern eines Kreisecks
Das bekannte Szenario aus Abschnitt 11.5.1 diesmal als Kommunikationsdiagramm:
r: Rechteck k: Kreis
: Kreiseck
1.1: a := get_a()
1.2.1: set_radius(a / 2)
1: resize(factor)
1.2: set_a(a)
Neues a:
a = a * factor
1.2.2: set_a(a)
1.2.3: set_b(a)
Im Kommunikationsdiagramm werden die Nachrichten durchnumeriert. Die Gliederung gibt da-
bei an, welche Objekte noch aktiv sind.
1 Nachricht ans Kreiseck: Vergr oern um factor
1.1 Kreiseck holt aktuelle Gr oe von Rechteck r
1.2 Kreiseck multipliziert seine Gr oe mit factor
1.2.1 Kreiseck setzt neue Gr oe des Kreises
1.2.2 Kreiseck setzt neue Kantenl ange des Rechtecks
1.2.3 Dito f ur zweite Kantenl ange
206
11.7 Zustandsdiagramme
Ein Zustandsdiagramm zeigt eine Folge von Zust anden, die ein Objekt im Laufe seines Lebens
einnehmen kann und aufgrund welcher Ereignisse Zustands anderungen stattnden.
Ein Zustandsdiagramm zeigt einen endlichen Automaten(vergl. Abschnitt 7.6.1).
Zustands uberg ange werden in der Form
Ereignisname[Bedingung]/Aktion
notiert. Hierbei ist
Ereignisname der Name eines Ereignisses (typischerweise ein Methodenaufruf);
Bedingung die Bedingung, unter der der Zustands ubergang stattndet (optional)
Aktion eine Aktion, die beim

Ubergang ausgef uhrt wird (optional)
Auch Zust ande k onnen mit Aktionen versehen werden: Das Ereignis entry kennzeichnet das
Erreichen eines Zustands; exit steht f ur das Verlassen eines Zustands.
11.7.1 Beispiel: Flugreservierung
Wird ein Flug eingerichtet, ist noch nichts reserviert. Die Aktion ruecksetzen() sorgt daf ur,
da die Anzahl der freien und reservierten Pl atze zur uckgesetzt wird.
reservieren()
teilweise
reserviert
stornieren()
[reserviertePlaetze == 1]
stornieren()
[reserviertePlaetze > 1]
reservieren()
[freiePlaetze > 1]
ausgebucht
reservieren()
[freiePlaetze == 1]
flug
einrichten()
stornieren()
geschlossen
schliessen()
schliessen()
flug
streichen()
Ohne
Reservierung
entry /ruecksetzen()
207
11.8 Fallstudie: Tabellenkalkulation
Eine Tabelle besteht aus mn Zellen
Zellen sind entweder leer oder haben einen Inhalt
Inhalte sind Zahlen, Texte oder Formeln
Zu einem Inhalt gibt es mehrere Formeln (die die Inhalte ansprechen)
Zu einer Formel gibt es mehrere Inhalte (die als Operanden in der Formel auftreten)
11.8.1 Objektmodell
gibWert() gibt den Wert der Zelle (des Inhalts) zur uck
belege() belegt eine Zelle (einen Inhalt) mit einem neuen Wert
benachrichtige() ruft nach einer

Anderung eines Inhalts aktualisiere() f ur alle For-
meln auf, in der der Inhalt als Operand auftritt. Diese berechnen und belegen daraufhin ihr Er-
gebnis neu.
Tabelle
hat 1
0..*
Zelle
+gibWert(): Inhalt
+belege(s:string)
Inhalt
+gibWert(): Inhalt
+belege(s:string)
-benachrichtige()
Inhalt
0..1
Zelle
1
Zahl
-wert: double
+belege(s:string)
Text
-wert: string
+belege(s:string)
Formel
+gibWert(): Inhalt
+belege(s:string)
+aktualisiere()
Operand
0..*
Ergebnis 1
1
Formel
0..*
208
11.8.2 Beispiel f ur Objektbeziehungen
Die Tabelle sei wie folgt belegt:
A1 = 1 B1 = A1 + A2
A2 = 10 B2 = B1 + A3
A3 = 100
Dann sind die Inhalte wie folgt verkn upft:
a1: Zahl
wert = 1
a2: Zahl
wert = 10
b1: Formel
b1 = a1 + a2
operand operand
b2: Formel
b2 = b1 + a3
a3: Zahl
wert = 100
operand operand
b1: Zahl
wert = 11
ergebnis
b2: Zahl
wert = 111
ergebnis
209
11.8.3 Zustandsdiagramm
Die Methode belege der Klasse Inhalt pr uft, ob sich der Wert ge andert hat. Wenn ja, be-
nachrichtigt sie mit benachrichtige() alle Formelobjekte, in denen der Inhalt als Operand
vorkommt.
konstanter Wert
vernderter Wert
belege()
[neuer Wert =
alter Wert]
benachrichtige()
11.8.4 Sequenzdiagramm
Beispiel: Die Tabelle sei belegt wie in Abschnitt 11.8.2 beschrieben; nun andern wir den Wert
der Zelle A1 von 1 auf 5.
a1: Zahl
wert = 1
a2: Zahl
wert = 10
b1: Formel
b1 = a1 + a2
b2: Formel
b2 = b1 + a3
a3: Zahl
wert = 100
Benutzer
belege("5")
b1: Zahl
wert = 11
b2: Zahl
wert = 111
aktualisiere()
gibWert()
5
gibWert()
10
belege("15")
aktualisiere()
gibWert()
100
gibWert()
10
belege("115")

Ubung: Erstellen Sie das aquivalente Kommunikationsdiagramm!

210
11.9 Finden von Klassen und Methoden

Wie nde ich die Objekte? ist die schwierigste Frage der Analyse.
Es gibt keine eindeutige Antwort: Man kann ein Problem auf verschiedene Weisen objektorien-
tiert modellieren.
11.9.1 Entwurf nach Zust andigkeit
Ein verbreitetes Grundprinzip ist der Entwurf nach Zust andigkeit: Jedes Objekt ist f ur bestimmte
Aufgaben zust andig und
besitzt entweder die F ahigkeiten, die Aufgabe zu l osen,
oder es kooperiert dazu mit anderen Objekten.
Ziel ist damit das Aufnden von Objekten anhand ihrer Aufgaben in der Kooperation.
Wir gehen zun achst von einer informalen Beschreibung aus und betrachten zentrale Begriffe der
Aufgabenstellung:
Hauptworte in der Beschreibung werden zu Klassen und konkreten Objekten
Verben in der Beschreibung werden zu Diensten
entweder zu Diensten, die ein Objekt anbietet,
oder zu Aufrufen von Diensten kooperierender Objekte.
Diese Dienste kennzeichnen die Zust andigkeit und Kooperationen der einzelnen Klassen.
Die so gefundenen Klassen werden dann anhand ihrer Zust andigkeiten auf sogenannte KZK-
Karten (Klasse Zust andigkeit Kooperation) notiert:
Klassenname Zusammenarbeit mit
zust andig f ur
Die KZK-Karte gibt die Rolle wieder, die Objekte im Gesamtsystem ubernehmen sollen.
211
11.9.2 Beispiel: Rechnerversand
Student Fritz bestellt mit einem Brief bei der Firma Rechnerwelt einen Rechner. Die-
ser wird ihm nach mehreren Tagen als Paket durch die Firma Gelbe Post zugestellt.
Eine erste N aherung k onnte so aussehen:
Student Zusammenarbeit mit
zust andig f ur
bestellen Rechnerh andler
Paket annehmen Zusteller
Rechnerh andler Zusammenarbeit mit
zust andig f ur
Bestellung annehmen Student
Paket absenden Zusteller
Zusteller Zusammenarbeit mit
zust andig f ur
Paket annehmen Rechnerh andler
Paket abgeben Student
Diese erste N aherung ist jedoch noch nicht vollst andig:
Fritz tritt in seiner Rolle als Kunde auf; es kommt nicht darauf an, da er auch Student ist
(es sei denn, er bek ame Studentenrabatt). Besser w are also der Klassenname Kunde statt
Student.
Brief und Paket fehlen es handelt sich um reine Datenobjekte, die weder Zust andigkeit
noch Kooperationspartner haben.
Wir haben offengelassen, wie der Bestellbrief zum Rechnerh andler gelangt; ggf. ist hierf ur
ebenfalls ein Zusteller zust andig.
Datenu, Zustands uberg ange und Klassenhierarchien sind nicht ber ucksichtigt.
212
11.9.3

Uberarbeitung des Entwurfs (Restrukturierung)
Nachdem ein erster Grobentwurf fertiggestellt ist, sollte versucht werden, ihn anhand der folgen-
den Gesichtspunkte zu verbessern:
Herausfaktorisieren gleicher Merkmale. K onnen gemeinsame Merkmale (Attribute, Metho-
den) verschiedener Klassen miteinander in Zusammenhang gebracht werden?
Diese gemeinsamen Merkmale k onnen
in eine dritte Klasse verlagert werden, die von den bestehenden Klassen aggregiert
wird. Die bestehenden Klassen m ussen die ausgelagerten Dienste aber weiterhin an-
bieten
in eine gemeinsame Oberklasse verlagert werden. Dies ist bei gemeinsamen ist-ein-
Beziehungen sinnvoll.
Verallgemeinerung von Verhaltensweisen. K onnen Methoden mit einheitlicher Schnittstelle be-
reits auf einer abstrakten Ebene angegeben werden?
Abstrakte Klassen k onnen etwa allgemeine Methoden bereitstellen, deren Details (abge-
leitete Kernmethoden) in den konkreten Unterklassen realisiert werden.
Ersetzen einer umfangreichen Klasse durch ein Teilsystem. K onnen Klassen mit vielen Merk-
malen weiter unterteilt werden?
Evtl. Einf uhrung eines Teilsystems aus mehreren Objekten und zugeh origen Klassen
Minimierung von Objektbeziehungen. Kann man durch Umgruppierung der Klassen oder neue
Schnittstellen die Zahl der

Benutzt-Beziehungen verringern?
Auch hier unterh alt nur noch ein neu einzuf uhrendes Teilsystem Auenbeziehungen.
Wiederverwendung, Bibliotheken. Kann man bestehende Klassen wiederverwenden?
Ggf. k onnen geeignete Anpassungsklassen (Adapter) eingef uhrt werden
Generizit at. K onnen generische Klassen und Methoden eingesetzt werden?
Oder auch: k onnen Klassen und Methoden des Entwurfs generisch gestaltet werden?
Entwurfsmuster. Kann man Standard-Architekturbausteine (Kapitel 12)einsetzen?
213
11.9.4 Beispiel: Rechnerversand
Objektmodell
Anschrift: herausfaktorisiert als gemeinsame Attribute von Kunden und H andlern
Die neue Klasse Paket besteht aus Absender- und Empf angeradresse.
Bestellung: ebenfalls neu; besteht u.a. aus einer Bestelleradresse
Anschrift
-name: string
-adresse: string
Paket
Bestellung
Kunde
+annehmen(p:Paket)
+versandt(b:Bestellung)
Rechnerhndler
+annehmen(b:Bestellung)
Zusteller
-name: string
+annehmen(p:Paket)
Empfnger
Absender
Besteller
1
0..*
1
0..*
Sequenzdiagramm
k: Kunde
r: Rechnerhndler z: Zusteller
annehmen()
annehmen()
annehmen()
versandt()
empfangen()
214
11.10 Fallstudie: Geldautomat
11.10.1 Problembeschreibung
Ein Geldautomat (Scheckkartenautomat, SKA) ist eine Maschine, mit der Bankkunden Geld
von ihrem Girokonto abheben und sich uber ihren Kontostand informieren k onnen. Er besteht
aus einem Anzeigefeld, einem Scheckkartenleser, einem Geldausgabefach, einem Ziffern- und
einem Funktionsfeld.
Im Grundzustand wird eine Begr uungsnachricht

Bitte Scheckkarte einf uhren angezeigt. Die

Tasten werden erst aktiv, wenn eine Karte eingef uhrt ist.
Der Kartenleser versucht eine eingef uhrte Karte zu lesen. Ein unleserliche Karte wird ausgewor-
fen, dar uber wird der Kunde informiert.
Ist die Karte leserlich, wird der Kunde aufgefordert, seine 4-stellige Geheimzahl einzugeben.
F ur jede eingegebene Ziffer wird das Symbol

# angezeigt. Wurde die Geheimzahl korrekt ein-

gegeben, wird der Kunde aufgefordert, zwischen

Auszahlung und

Kontostand zu w ahlen.
Andernfalls hat der Kunde noch zwei Versuche frei, die Geheimzahl korrekt einzugeben. Schl agt
auch der dritte Versuch fehl, so wird die Karte einbehalten und nur am Bankschalter zur uckge-
geben.
Mit der entsprechenden Funktionstaste kann der Kunde den Bearbeitungsvorgang ausw ahlen.
215
Soll der Kontostand angezeigt werden, erscheint zun achst die Nachricht

Vorgang wird bearbeitet

. . . , danach f ur 20 Sekunden der aktuelle Kontostand. Anschlieend erscheint die Meldung

Bitte Karte entnehmen; die Karte wird ausgeworfen und das System geht in den Grundzustand.
F ur eine Auszahlung wird der Kunde aufgefordert, den Betrag einzugeben. Der Betrag wird mit
Zifferntasten eingegeben, jede Ziffer wird angezeigt. Die Eingabe wird mit der Taste

Betrag
best atigt. Danach erscheint eine Nachricht

Der Vorgang wird bearbeitet . . . .

Pro Tag d urfen mit der Karte maximal DM 2000,- abgehoben werden. Auerdem darf der Kon-
tostand nicht negativ werden. Bei Verletzung dieser Bedingungen werden entsprechende Nach-
richten ausgegeben und gegebenenfalls die Aufforderung zur Eingabe eines Betrages erneut an-
gezeigt.
Ist der Geldbetrag akzeptabel, so wird zun achst die Meldung

Bitte Karte entnehemen ausgege-

ben, nach Entnahme der Karte erscheint die Meldung

Bitte Geld entnehmen. Danach wird im

Ausgabefach das Geld bereitgestellt. Anschlieend geht der Automat in seinen Grundzustand.
Zwischen zwei Eingabeaufforderungen kann der Bearbeitungsvorgang durch Dr ucken der Ab-
bruchtaste bendet werden. Es erscheint die Nachricht

Bearbeitung abgebrochen, bitte Karte ent-

nehmen; die Karte wird ausgeworfen und anschlieend geht das System in den Grundzustand.
216
11.10.2 Klassenhierarchie, erster Versuch
Entsprechend Abschnitt 11.9 sind alle Hauptworte Kandidaten f ur Klassen. Diese werden daher
zun achst gesammelt. Objekte, die offensichtlich nicht zum System geh oren, werden weggelas-
sen, desgleichen zeitliche Angaben (diese werden Teil des Zustandsdiagramms).
Wir erhalten einen ersten Entwurf der Klassenhierarchie:
SKA ist das Hauptprogramm. Die Ger ate sind in einer Taxonomie abstrakter Klassen angeordnet;
nur die Bl atter dieser Taxonomie haben Methodenimplementierungen.
217
11.10.3 Klassenhierarchie, zweiter Versuch
Im ersten Versuch fehlen jedoch noch s amtliche Ein-/Ausgaben, ferner fehlen die Bearbeitungs-
vorg ange, Datum und Geld.
Dies f uhrt zum erweiterten Diagramm, in dem die Klassenhierarchie Dialog sowie die Klassen
Konto, Geld und Datum neu hinzukommen.
218
11.10.4 Bestimmung der Methoden
Zur Gewinnung der Methoden legen wir f ur jede Klasse eine KZK-Karte an, auf der die T atig-
keiten und Kooperationspartner der Klasse vermerkt werden.
Die T atigkeiten extrahieren wir aus den Verben in der informalen Aufgabenbeschreibung.
219
220
11.10.5 Einf uhrung von Teilsystemen
Wir strukturieren das System weiter durch das Einf uhren von Teilsystemen.
Grundlage sind die Kooperationen zwischen den Klassenbeschreibungen, wie sie auf den KZK-
Karten vermerkt sind. Zun achst extrahieren wir Methoden, und stellen dabei fest, wer diese Me-
thoden verwendet (in OMT

Vertragspartner genannt).
Im Beispiel ergeben sich u.a. folgende Methoden:
1 Bearbeitungsvorgang: Bearbeitungsvorgang ausf uhren
2 Konto: Kontoinformation abfragen
3 Konto: Betrag abbuchen
4 Meldung: Text ausgeben
5 Formular: Text ausgeben, Eingabe liefern
6 Kartenleser: Karte einlesen, auswerfen, behalten
7 Tastenfeld: gedr uckte Taste ubermitteln
8 Anzeigenfeld: Text anzeigen
9 Ausgabefach: Geld bereitstellen
Das Benutzt-Diagramm gibt an, welche Klasse welche Methoden verwendet. Dazu werden Ver-
erbungsb aume zu Teilsystemen zusammengefat.
221
Fat man noch Konto und Bearbeitungsvorgang zum Subsystem Finanzmanager zusammen,
sowie Ger at und Dialog zu Dialogmanager, so erh alt man eine klassische Architektur, deren
Grundlage die Trennung von Benutzerschnittstelle und Kernfunktionalit at ist:
Abschlieende Grobstruktur:
Eine solche Architektur k onnte auch bei modularem Entwurf entstehen!
222
11.10.6 Zustandsdiagrammm
Das Zustandsdiagramm gibt f ur jede Klasse die m oglichen Aufrufsequenzen der Methoden an.
Dabei werden auch Aktionen des Kunden ber ucksichtigt.
Es m ussen alle denkbaren F alle ber ucksichtigt werden, insbesondere auch falsche Benutzerein-
gabe (Robustheit!)

Ubung: Geben Sie ein m oglichst vollst andiges Objektmodell des Scheckkartenautomaten an. Das
Modell soll die Assoziations- und Aggregationsbeziehungen sowie die Signaturen der ben otigten
Methoden enthalten.
223
11.11 Vom Modell zum Programm
Wie verwandelt man den Entwurf in einen Quelltext?
1. Klassen und Vererbung k onnen direkt aus dem Klassendiagramm entnommen werden. Die
Methoden(k opfe) ebenso. Zu jeder Methode mu eine vollst andige Signatur angegeben
werden.
2. Assoziationen zwischen Klassen werden durch Attribute realisiert.
Eine n : 1 oder 1 : 1 Assoziation von P nach Q wird in P durch ein Attribut q vom
Typ Q realisiert.
Eine 1 : n- bzw. n : m-Assoziation von P nach Q wird durch eine Menge qs vom
Typ set(Q) realisiert. (Implementierung als Feld, Liste. . . )
Falls Assoziationen eigene Methoden haben, mu man sie als eigene (Hilfs-) Klassen im-
plementieren.
3. F ur jede Klasse sollte eine Invariante formuliert und dokumentiert werden; f ur jede Me-
thode eine Vor- und Nachbedingung.
4. Die Methodenr umpfe werden implementiert. Dabei wird vorgegangen wie in der traditio-
nellen Programmierung.
5.

Uberpr ufung des Zustandsdiagramms: sind genau die im dynamischen Modell angegebe-
nen Aufrufsequenzen zul assig? Unzul assige Aufrufe m ussen durch Ausnahme/Fehlerbehandlung
abgefangen werden! Dazu kann es sinnvoll sein, die Vorbedingung dynamisch zu uber-
pr ufen.
6. Zum Testen werden die ublichen Verfahren angewendet (siehe Kapitel 17).
Moderne Programmierumgebungen erzeugen aus einem Entwurf automatisch Codeschablonen:
1. Man entwirft ein System mit allen Klassen und Attributen.
2. Die Programmierumgebung erzeugt entsprechende Codeschablonen.
3. Nun m ussen

nur noch die Methoden ausprogrammiert werden.

224
11.12 Checkliste: Grobentwurf
Der Grobentwurf im Rahmen des Software-Entwicklungs-Praktikums wird anhand der folgen-
den Anforderungen beurteilt.
Entsprechen die Klassen zentralen Konzepten der Aufgabenstellung?
Wichtige Hauptworte der Aufgabenstellung sollten als Klassen im Entwurf auftauchen.
Siehe Abschnitt 11.9.
Sind die Grundprinzipien der Zerlegung erf ullt?
Vergleiche hierzu Abschnitt 10.1.3 sowie Kapitel 5.
Sind Hierarchien und Objektbeziehungen gut dokumentiert?
Dies soll in Form eines Objekt-Modells geschehen; siehe Abschnitt 11.1.
Das Objekt-Modell sollte so pr azise wie m oglich sein (Multiplizit aten, Aggregation/Komposition,
Zusicherungen).
Im Entwurf sollten alle offensichtlichen M oglichkeiten f ur Restrukturierungen und

Uber-
arbeitungen bereits ausgesch opft sein. Vergleiche Abschnitt 11.9.3.
Sind Informationsu und Zustands uberg ange hinreichend ber ucksichtigt?
Je nach Komplexit at der Aufgabenstellung kann es notwendig sein,
ausgew ahlte Aspekte des Informationsusses (Sequenzdiagramm, Kommunikations-
diagramm) und
Zustands uberg ange (Zustandsdiagramm)
gesondert zu spezizieren.
225
Kapitel 12
Entwurfsmuster
In diesemKapitel werden wir uns mit typischen Eins atzen von objektorientiertemEntwurf besch afti-
gen den sogenannten Entwurfsmustern (design patterns).
1
Der Begriff Entwurfsmuster wurde durch den Architekten Christopher Alexander gepr agt
2
:
Each pattern describes a problem which occurs over and over again in our environ-
ment, and then describes the core of the solution to that problem, in such a way that
you can use this solution a million times over, without ever doing it the same way
twice.
Ein Muster ist eine Schablone, die in vielen verschiedenen Situationen eingesetzt werden kann.
1
nach Gamma et al.: Design Patterns: Elements of reusable Software Components. Addison Wesley, 1995
2
Alexander et al.: A Pattern LanguageTowns Buildings Construction, Oxford Press, New York, 1977
226
12.1 Muster in der Architektur: Window Place
3
Everybody loves window seats, bay windows, and big windows with low sills
4
and comfortable
chairs drawn up to them . . . A room which does not have a place like this seldom allows you to
feel comfortable or perfectly at ease. . .
If the room contains no window which is a place, a person in the room will be torn between
two forces:
He wants to sit down and be comfortable.
He is drawn toward the light.
Obviously, if the comfortable placesthose places in the room where you most want to sitare
away from the windows, there is no way of overcoming this conict. . .
Therefore: In every room where you spend any length of time during the day, make at least one
window into a window place
In unserem Fall sind Entwurfsmuster
Beschreibungen von kommunizierenden Objekten und Klassen, die angepat wurden, um ein
allgemeines Entwurfsproblem in einem bestimmten Kontext zu l osen.
3
Alexander et al., a.a.O.
4
sill = Fensterbank
227
12.2 Die Elemente eines Musters
Muster sind meistens in Kataloge zusammengefatHandb ucher, die Muster f ur zuk unftige
Wiederverwendung enthalten.
Jedes Muster wird mit wenigstens vier wesentlichen Teilen beschrieben:
Der Name des Musters wird benutzt, um das Entwurfsproblem, seine L osung und seine Folgen
in einem oder zwei Worten zu beschreiben.
Der Name des Musters
erm oglicht es, auf einem h oheren Abstraktionsniveau zu entwerfen,
erlaubt es uns, es unter diesem Namen in der Dokumentation zu verwenden,
erm oglicht es uns, uns mit unseren Kollegen dar uber zu unterhalten.
Das Problem beschreibt, wann ein Muster eingesetzt werden soll.
Dieser Teil
beschreibt das Problem und dessen Kontext
kann bestimmte Entwurfsprobleme beschreiben
kann bestimmte Einsatzbedingungen enthalten
Die L osung beschreibt die Teile, aus denen der Entwurf besteht, ihre Beziehungen, Zust andig-
keiten und ihre Zusammenarbeit kurz, die Struktur und die Teilnehmer.
Dies ist
nicht die Beschreibung eines bestimmten konkreten Entwurfs oder einer bestimmten
Implementierung,
aber eine abstrakte Beschreibung eines Entwurfsproblems und wie ein allgemeines
Zusammenspiel von Elementen das Problem l ost.
Die Folgen sind die Ergebnisse sowie Vor- und Nachteile der Anwendung des Musters.
Dies sind gew ohnlich
Abw agungen bez uglich Ressourcenbedarf (Speicherplatz, Laufzeit)
aber auch die Ein usse auf Flexibilit at, Erweiterbarkeit und Portierbarkeit. (Schlie-
lich wollen wir die Muster wiederverwenden!)
Ein Muster-Katalog kann allgemeiner Natur sein; es gibt aber auch spezische Kataloge (z.B.
anwendungsspezische Kataloge f ur Compilerbau, Datenbanken, Betriebssysteme, usw.)
228
12.3 Fallstudie: Die Textverarbeitung Lexi
Als Fallstudie betrachten wie den Entwurf einer What you see is what you get (WYSIWYG)
Textverarbeitung namens Lexi.
Lexi kann Texte und Bilder frei mischen in einer Vielzahl von m oglichen Anordnungen.
Wir betrachten, wie Entwurfsmuster die wesentlichen L osungen zu Entwurfsproblemen in Lexi
und ahnlichen Anwendungen beitragen.
Im Wesentlichen betrachten wir f unf Probleme in Lexis Entwurf:
Dokument-Struktur.
Wie wird das Dokument intern gespeichert?
Formatierung.
Wie ordnet Lexi Text und Graphiken in Zeilen und Polygone an?
Unterst utzung mehrerer Bedienober achen.
Lexi sollte so weit wie m oglich unabh angig von bestimmten Fenstersystemen sein.
Benutzer-Aktionen.
Es sollte ein einheitliches Verfahren geben, um auf Lexis Funktionalit at zuzugreifen und
um Aktionen zur uckzunehmen.
Darstellung der Dokumentstruktur.
Bestimmte Strukturen eines Lexi-Dokuments, beispielsweise

Uberschriften oder Graphi-
ken sollen durch mehrere Views darstellbar sein.
Jedes dieser Entwurfsprobleme (und seine L osung) wird durch ein oder mehrere Entwurfsmuster
veranschaulicht.
229
230
12.4 Struktur darstellen das Composite-Muster
Ein Dokument ist eine Anordnung grundlegender graphischer Elemente wie Zeichen, Linien,
Polygone und anderer Figuren.
Diese sind in Strukturen zusammengefatZeilen, Spalten, Abbildungen, und andere Unter-
strukturen.
Solche hierarchisch strukturierte Information wird gew ohnlich durch rekursive Komposition dar-
gestellt aus einfachen Elementen (composite) werden immer komplexere Elemente zusammen-
gesetzt.
Jedes wichtige Element wird durch ein individuelles Objekt dargestellt.
231
Wir denieren eine abstrakte Oberklasse Glyphe (engl. glyph) f ur alle Objekte, die in einem
Dokument auftreten k onnen.
Jede Glyphe
wei, wie sie sich zeichnen kann (mittels der Draw()-Methode). Diese abstrakte Methode
ist in konkreten Unterklassen von Glyph deniert.
wei, wieviel Platz sie einnimmt (wie in der Intersects()-Methode).
kennt ihre Kinder (children) und ihre Mutter (parent) (wie in der Insert()-Methode).
Die Glyph-Klassenhierarchie ist eine Auspr agung des Composite-Musters.
232
Das Composite-Muster
Problem
Benutze das Composite-Muster wenn
Du Teil-ganzes-Hierarchien von Objekten darstellen m ochtest
die Anwendung Unterschiede zwischen zusammengesetzten und einfachen Objekten igno-
rieren soll
Struktur
233
Teilnehmer
Component (Komponente: Glyph)
deniert die Schnittstelle f ur alle Objekte (zusammengesetzt und einfach)
implementiert Vorgabe-Verhalten f ur die gemeinsame Schnittstelle (sofern anwend-
bar)
deniert die Schnittstelle zum Zugriff und Verwalten von Unterkomponenten (Kin-
dern)
Leaf (Blatt: Rechteck, Zeile, Text)
stellt elementare Objekte dar; ein Blatt hat keine Kinder
deniert gemeinsames Verhalten elementarer Objekte
Composite (Zusammengesetztes Element: Picture, Column)
deniert gemeinsames Verhalten zusammengesetzter Objekte (mit Kindern)
speichert Unterkomponenten (Kinder)
implementiert die Methoden zum Kindzugriff in der Schnittstelle von Component
Client (Benutzer)
verwaltet Objekte mittels der Component-Schnittstelle.
Folgen
Das Composite-Muster
deniert Klassenhierarchien aus elementaren Objekten und zusammengesetzten Objekten
vereinfacht den Benutzer: der Benutzer kann zusammengesetzte wie elementare Objekte
einheitlich behandeln; er mu nicht (und sollte nicht) wissen, ob er mit einem elementaren
oder zusammengesetzten Objekt umgeht
vereinfacht das Hinzuf ugen neuer Element-Arten
kann den Entwurf zu sehr verallgemeinern: soll ein bestimmtes zusammengesetztes Ele-
ment nur eine feste Anzahl von Kindern haben, oder nur bestimmte Kinder, so kann dies
erst zur Laufzeit (statt zur

Ubersetzungszeit) uberpr uft werden.
Dies ist ein Nachteil!
Andere bekannte Einsatzgebiete: Ausdr ucke, Kommandofolgen.
234
12.5 Algorithmen einkapseln das Strategy-Muster
Lexi mu Text in Zeilen umbrechen und Zeilen zu Spalten zusammenfassen je nachdem, wie
der Benutzer es m ochte. Dies ist die Aufgabe eines Formatieralgorithmus.
Lexi soll mehrere Formatieralgorithmen unterst utzen, etwa
einen schnellen ungenauen (

quick-and-dirty) f ur die WYSIWYG-Anzeige und

einen langsamen, genauen f ur den Textsatz beim Drucken
Gem a der Separation der Interessen soll der Formatieralgorithmus unabh angig von der Doku-
mentstruktur sein.
Wir denieren also eine separate Klassenhierarchie f ur Objekte, die bestimmte Formatieralgo-
rithmen einkapseln. Wurzel der Hierarchie ist eine abstrakte Klasse Compositor mit einer allge-
meinen Schnittstelle; jede Unterklasse realisiert einen bestimmten Formatieralgorithmus.
Jeder Kompositor wandert durch die Dokumentstruktur und f ugt ggf. neue (zusammengesetzte)
Glyphen ein:
Dies ist eine Auspr agung des Strategy-Musters.
235
Das Strategy-Muster
Problem
Benutze das Strategy-Muster, wenn
zahlreiche zusammenh angende Klassen sich nur im Verhalten unterscheiden
verschiedene Varianten eines Algorithums ben otigt werden
ein Algorithmus Daten benutzt, die der Benutzer nicht kennen soll
Struktur
Teilnehmer
Strategy (Compositor)
deniert eine gemeinsame Schnittstelle aller unterst utzten Algorithmen
ConcreteStrategy (SimpleCompositor, TeXCompositor, ArrayCompositor)
implementiert den Algorithmus gem a der Strategy-Schnittstelle
Context (Composition)
wird mit einem ConcreteStrategy-Objekt konguriert
referenziert ein Strategy-Objekt
kann eine Schnittstelle denieren, uber die Daten f ur Strategy verf ugbar gemacht
werden.
236
Folgen
Das Strategy-Muster
macht Bedingungs-Anweisungen im Benutzer-Code unn otig (if simple-composition then
. . . else if tex-composition then . . . else . . . )
hilft, die gemeinsame Funktionalit at der Algorithmen herauszufaktorisieren
erm oglicht es dem Benutzer, zwischen Strategien zu w ahlen. . .
. . . aber belastet den Benutzer auch mit der Strategie-Wahl!
kann in einem Kommunikations-Overhead enden: Information mu bereitgestellt werden,
auch wenn die ausgew ahlte Strategie sie gar nicht benutzt
Weitere Einsatzgebiete: Code-Optimierung, Speicher-Allozierung, Routing-Algorithmen
237
12.6 Mehrfache Variation das Bridge-Muster
Lexi l auft auf einem Fenstersystem und hat (mindestens) drei verschiedene Fenster-Typen:
Ein ApplicationWindow zeigt das Dokument an
Ein IconWindow ist zeitweise unsichtbar (

ikoniziert)
Ein DialogWindow ist ein tempor ares Fenster, das auf einem Besitzer-Fenster liegt.
Diese Fenstertypen k onnen in einer Window-Klassenhierarchie angeordnet werden:
238
Diese Fenstertypen sind nicht die einzige m ogliche Variation.
Lexi k onnte auf mehreren verschiedenen Fenstersystemen laufen etwa Windows, Macintosh,
und das X Window System.
Es gibt drei Alternativen, um diese zus atzliche Variation zu modellieren:
Neue Unterklassen. F uhre neue Unterklassen ein, die die Variation einkapseln, wie PMIcon-
Window, MacIconWindow, XIconWindow.
ApplicationWindow
MacApplWindow
PMApplWindow
XApplWindow
Window
IconWindow
MacIconWindow
PMIconWindow
XIconWindow
DialogWindow
MacDialogWindow
PMDialogWindow
XDialogWindow
Gemeinsamer Code f ur alle Fenstersysteme ist nicht in gemeinsamer Oberklasse
Mit n Fenstertypen und m Fenstersystemen erhalten wir n m neue Klassen
Mehrfach-Vererbung. Erzeuge zwei Hierarchien f ur den Fenstertyp (Window) und das Fen-
stersystem (WindowImp) und benutze mehrfache Vererbung, um neue zusammengesetzte
Klassen zu erzeugen: Jede Klasse erbt einen Fenstertyp und eine Implementierung.
Window
IconWindow DialogWindow MacWindowImp PMWindowImp XWindowImp ApplicationWindow
WindowImp
MacApplWindow MacIconWindow MacDialogWindow etc.
Wir bekommen nach wie vor n m neue Klassen.
239
Dynamische Kopplung. Wir koppeln Fenstertyp und Fenstersystem dynamisch mittels eines
implementation-Verweises; jedes Window-Objekt verweist auf eine bestimmte WindowImp-
Implementierung.
Dies ist eine Auspr agung des Bridge-Musters.
240
Das Bridge-Muster
Problem
Benutze das Bridge-Muster, wenn
Du eine Abstraktion von ihrer Implementierung entkoppeln willst (etwa wenn die Imple-
mentierung zur Laufzeit ausgew ahlt wird)
sowohl die Abstraction als auch die Implementierung erweiterbar sein sollen.
Struktur
Teilnehmer
Abstraction (Window)
deniert die Schnittstelle der Abstraktion
unterh alt einen Verweis zu einem Objekt vom Typ Implementor
RenedAbstraction (IconWindow)
erweitert die Schnittstelle von Abstraction
Implementor (WindowImp)
deniert die Schnittstelle f ur Implementierungs-Klassen (gew ohnlich primitive Ope-
rationen; die h oheren Operationen sind in Abstraction realisiert)
ConcreteImplementor (XWindowImp, PMWindowImp)
realisiert die Implementor-Schnittstelle und deniert ihre konkrete Implementierung
241
Folgen
Das Bridge-Muster
entkoppelt Schnittstelle und Implementierung:
Eine Abstraktion ist nicht fest an eine Schnittstelle gebunden
Die Implementierung kann zur Laufzeit konguriert (und sogar ge andert) werden
Wir unterst utzen eine bessere Gesamt-Struktur des Systems
verbessert die Erweiterbarkeit
versteckt Implementierungs-Details vor dem Benutzer
Weitere Einsatzgebiete: Darstellung von Bildern (z.B. JPEG/GIF/TIFF), String-Handles
242
12.7 Benutzer-Aktionen das Command-Muster
Lexis Funktionalit at ist auf zahlreichen Wegen verf ugbar: Man kann die WYSIWIG-Darstellung
manipulieren (Text eingeben und andern, Cursor bewegen, Text ausw ahlen) und man kann wei-
tere Aktionen uber Men us, Schalt achen und Abk urzungs-Tastendr ucke ausw ahlen.
Wir m ochten eine bestimmte Aktion nicht mit einer bestimmten Benutzerschnittstelle koppeln,
weil
es mehrere Benutzungsschnittstellen f ur eine Aktion geben kann (man kann die Seite mit
einer Schalt ache, einem Men ueintrag oder einem Tastendruck wechseln)
wir wom oglich in Zukunft die Schnittstelle andern wollen.
Umdie Sache weiter zu verkomplizieren, m ochten wir auch Aktionen r uckg angig machen k onnen
(undo) und r uckg angig gemachte Aktionen wiederholen k onnen (redo).
Wir m ochten mehrere Aktionen r uckg angig machen k onnen, und wir m ochten Makros (Kom-
mandofolgen) aufnehmen und abspielen k onnen.
Wir denieren deshalb eine Command-Klassenhierarchie, die Benutzer-Aktionen einkapselt.
243
Spezische Glyphen k onnen mit Kommandos verkn upft werden; bei Aktivierung der Glyphen
werden die Kommandos ausgef uhrt.
Dies ist eine Auspr agung des Command-Musters.
244
Das Command-Muster
Problem
Benutze das Command-Muster wenn Du
Objekte parametrisieren willst mit der auszuf uhrenden Aktion
Kommandos zu unterschiedlichen Zeiten ausl osen, einreihen und ausf uhren m ochtest
die R ucknahme von Kommandos unterst utzen m ochtest (siehe unten)

Anderungen protokollieren m ochtest, so da Kommandos nach einem System-Absturz
wiederholt werden k onnen.
Struktur
245
Teilnehmer
Command (Kommando)
deniert eine Schnittstelle, um eine Aktion auszuf uhren
ConcreteCommand (PasteCommand, OpenCommand)
deniert eine Verkn upfung zwischen einem Empf anger-Objekt und einer Aktion
implementiert Execute(), indem es die passenden Methoden auf Receiver aufruft
Client (Benutzer; Application)
erzeugt ein ConcreteCommand-Objekt und setzt seinen Empf anger
Invoker (Aufrufer; MenuItem)
fordert das Kommando auf, seine Aktion auszuf uhren
Receiver (Empf anger; Document, Application)
wei, wie die Methoden ausgef uhrt werden k onnen, die mit einer Aktion verbunden
sind. Jede Klasse kann Empf anger sein.
Folgen
Das Command-Muster
entkoppelt das Objekt, das die Aktion ausl ost, von dem Objekt, das wei, wie die Aktion
ausgef uhrt werden kann
realisiert Kommando als rst-class-Objekte, die wie jedes andere Objekt gehandhabt und
erweitert werden k onnen
erm oglicht es, Kommandos aus anderen Kommandos zusammenzusetzen (siehe unten)
macht es leicht, neue Kommandos hinzuzuf ugen, da existierende Klassen nicht ge andert
werden m ussen.
246
12.7.1 Kommandos r uckg angig machen
Mittels einer Kommando-Historie kann man leicht r ucknehmbare Kommandos gestalten. Eine
Kommando-Historie sieht so aus:
present
past commands
Um das letzte Kommando r uckg angig zu machen, rufen wir Unexecute() auf dem letzten
Kommando auf. Das heit, da jedes Kommando genug Zustandsinformationen halten mu, um
sich selbst r uckg angig zu machen.
present
Unexecute()
Nach dem R ucknehmen bewegen wir die

Gegenwarts-Linie ein Kommando nach links. Nimmt

der Benutzer ein weiteres Kommando zur uck, wird das vorletzte Kommando zur uckgenommen
und wir enden in diesem Zustand:
present
past future
Um ein Kommando zu wiederholen, rufen wir einfach Execute() des gegenw artigen Kom-
mandos auf . . .
present
Execute()
. . . und setzen die

Gegenwarts-Linie um ein Kommando nach vorne, so da das n achste Wie-

derholen die Execute()-Methode des n achsten Kommandos aufruft.
247
present
past future
Auf diese Weise kann der Benutzer vorw arts und r uckw arts in der Zeit gehen je nachdem, wie
weit er gehen mu, um Fehler zu korrigieren.
12.7.2 Makros
Zum Abschlu zeigen wir noch, wie man Makros (Kommandofolgen) realisiert. Wir setzen das
Composite-Muster ein, um eine Klasse MacroCommand zu realisieren, die mehrere Kommandos
enth alt und nacheinander ausf uhrt:
Wenn wir nun noch dem MacroCommand eine Unexecute()-Methode hinzuf ugen, kann man
ein Makro wie jedes andere Kommando zur ucknehmen.
248
12.8 One-To-Many Beziehungen das Observer-Muster
Lexi soll den Zustand eines Dokuments auf verschiene Weise darstellen. Denkbar w are beispiels-
weise eine Baumstruktur der

Uberschriften oder eine

Ubersichtsview aller benutzten Bilder.
Dabei soll ein Lexi-Dokument keine genau Kenntnis uber die es darstellenden Views haben und
das dynamische Hinzuf ugen und Entfernen neuer Views unterst utzen.
Eine View registriert sich bei einem Dokument
Das Dokument kennt nur das Interface, wei also nicht, welche Art von View es darstellt.
Das Dokument teilt den Views Zustands anderungen uber die update-Methode mit.
Dies ist eine Auspr agung des Observer-Musters.
249
Das Observer-Muster
Problem
Benutze das Observer-Muster wenn
ein Aspekt einer Abstraktion abh angig ist von einem anderen Aspekt. Die Aufteilung
dieser Aspekte in verschiedene Objekte erh oht die Variationsm oglichkeit und Wiederver-
wendbarkeit.
eine Zustands anderung eines Objektes die

Anderung anderer Objekte nach sich zieht, wo-
bei nicht a priori bekannt ist, vieviele Objekte ge andert werden m ussen.
Ein uberwachtes Objekt die

Anderung seines Zustandes seinen Observern mitteilen soll,
ohne diese im Detail zu kennen.
Struktur
250
Teilnehmer
Subject
kennt seine Observer, deren Anzahl beliebig ist, und die dieses uberwachen
bietet Schnittstellen um Observer zu registrieren bzw. wieder zu entfernen
Observer
bietet eine Schnittstellenmethode update an, die dem Observer mitteilt, dass sich der
Zustand eines observierten Subjects ge andert hat.
Concrete Subject
speichert die f ur einen Observer relevanten Zustandsdaten
benachrichtigt seine Observer uber Zustands anderungen
Concrete Observer
referenziert ein concrete Subject
speichert Zustand des observierten Subjects, der konsistent gehalten werden muss.
bietet, gem a dem Observer Interface, eine update Methode an, welche von beobach-
teten Subjects aufgerufen wird.
251
Kollaborationsdiagramm
252
Folgen
Das Observer-Muster
bietet eine schwache Kopplung zwischen Subjects und Observern.
unterst utzt Informationsbroadcast ohne dabei die Informationsempf anger spezizieren zu
m ussen.
f uhrt zu h augen update-calls. Da die Observer nicht n aher speziziert sind, werden sie
bei jeder - auch evtl. f ur sie nicht relevanten - Zustands anderung benachrichtigt.
Eine weitere Anwendung des Observer-Musters sind Listener in Java-Swing
253
12.9 Zusammenfassung
In Lexi haben wir f unf Entwurfs-Muster kennengelernt:
Composite zur Darstellung der internen Dokument-Struktur
Strategy zur Unterst utzung verschiedener Formatierungs-Algorithmen
Bridge zur Unterst utzung mehrerer Fenstersysteme
Command zur R ucknahme und Makrobildung von Kommandos
Observer zur Darstellung eines Dokuments in verschiedenen Views
Keins dieser Entwurfsmuster ist beschr ankt auf die Dokumentenverarbeitung; auch reichen diese
vier Muster nicht aus, um alle anfallenden Probleme in Lexis Entwurf zu l osen.
Es gibt zahlreiche weitere Anwendungen und Muster, die hier nicht behandelt wurden; das Buch
von Gamma et al. (1995) enh alt viele Details.
Zusammenfassend bieten Entwurfsmuster:
Ein gemeinsames Entwurfs-Vokabular.
Entwurfsmuster bieten ein gemeinsames Vokabular f ur Software-Entwerfer zum Kommu-
nizieren, Dokumentieren und um Entwurfs-Alternativen auszutauschen. Irgendwann sagt
man einfach

La uns diese Klassen als Strategie einsetzen.

Dokumentation und Lernhilfe.
Die meisten groen objekt-orientierten Systeme benutzen Entwurfsmuster. Das Lernen
von Entwurfsmuster hilft, diese Systeme zu verstehen, und macht den Leser so zu einem
besseren Entwerfer.
Eine Erg anzung zu bestehenden Methoden.
W ahrend eine Entwurfsmethode eine Menge von graphischen Notationen deniert, umver-
schiedene Aspekte eines Entwurfs zu modellieren, fassen Entwurfsmuster die Erfahrung
von Experten zusammen.
The best designs will use many design patterns that dovetail and intertwine to produce a
greater whole.

Die besten Entw urfe werden zahlreiche Entwurfsmuster benutzen, die sich gegenseitig
erg anzen und durchdringen, um ein gr oeres Ganzes zu schaffen.
254
Kapitel 13
Software-Architektur
Nachdem wir in Kapitel 12 Muster auf der Ebene von Klassen und Objekten kennengelernt ha-
ben, besch aftigen wir uns nun mit typischen Mustern auf einer h oheren Ebene: Muster, die die
gesamte Architektur eines Systems beschreiben.
1
Wir betrachten die folgenden klassischen Architekturmuster:
Model-View-Controller
Layers
Pipes and Filters
Broker
. . . sowie einige Anti-Muster, die nicht auftreten sollten.
1
nach Buschmann et al.: Pattern-oriented software architecture. John Wiley & Sons, 1996.
255
13.1 Interaktive Systeme: Model-View-Controller
Das Model-View-Controller-Muster ist eins der bekanntesten und verbreitetsten Muster f ur die
Architektur interaktiver Systeme.
13.1.1 Beispiel: Wahlabend
Wir betrachten ein Informationssystem f ur Wahlen, das verschiedene Sichten auf Hochrechnun-
gen und Wahlergebnisse bietet.

Uber eine Spreadsheet-Schnittstelle k onnen Benutzer aktuelle
Ergebnisse eintragen.
CDU:
SPD:
FDP:
GRUENE:
PDS:
Andere:
41%
38%
8%
6%
5%
2%
CDU
SPD
FDP
GRUENE
PDS
Andere
41
38
8
6
5
2
13.1.2 Problem
Benutzerschnittstellen sind besonders h aug von

Anderungen betroffen.
Wie kann ich dieselbe Information auf verschiedene Weise darstellen?
Wie kann ich sicherstellen, da

Anderungen an den Daten sofort in allen Darstellungen
sichtbar werden?
Wie kann ich die Benutzerschnittstelle andern (wom oglich zur Laufzeit)?
Wie kann ich verschiedene Benutzerschnittstellen unterst utzen, ohne den Kern der An-
wendung zu ver andern?
256
13.1.3 L osung
Das Model-View-Controller-Muster trennt eine Anwendung in drei Teile:
Das Modell (Model) ist f ur die Verarbeitung zust andig,
Die Sicht (View) k ummert sich um die Ausgabe
Die Kontrolle (Controller) k ummert sich um die Eingabe.
Schema
View
Model
event
modify
modify
update
get
data
Controller
Ablauf
Die Kontrolle verarbeitet Eingaben und andert je nach Eingabe Modell oder Sicht.
Wurde das Modell ge andert, benachrichtigt dieses die Sicht (update).
Die Sicht ruft die aktuellen Daten des Modells ab und aktualisiert sich.
257
Klassendiagramm
Jede Sicht implementiert ein Interface Observer, damit sich beliebige Sichten beim Modell regi-
strieren lassen k onnen.
Jede Kontrolle ist genau einer Sicht zugeordnet.
Model
+coreData
+attach(Observer)
+detach(Observer)
+notify()
+getData()
+service()
View
+initialize(Model)
+makeController()
+activate()
+display()
+update()
Controller
+initialize(Model,View)
+handleEvent()
Observer
+update()
observers
0..*
1
1 0..n
Observer
registrieren
Observer
benachrichtigen
Darstellung
aktualisieren
1
In einigen Programmiersprachen oder Architekturen kann es notwendig sein, dass das Modell
bei einer

Anderung auch die Kontrolle benachrichtigt.
L osung: Kontrollen implementieren ebenfalls Interface Observer und registrieren sich beim Mo-
dell.
258
Multiple Darstellungen
Bei jedem Modell k onnen sich mehrere Sichten registrieren. H aug wird auch von Beobachtern
(Observer) des Modells gesprochen.
m: Model
spd = 45
cdu = 41 ...
pie: View bar: View c: Controller sheet: View
Bei jeder

Anderung des Modell-Zustands werden die registrierten Beobachter benachrichtigt;
sie bringen sich dann auf den neuesten Stand.
259
Teilnehmer
Das Modell (model) verkapselt Kerndaten und Funktionalit at. Das Modell ist unabh angig von
einer bestimmten Darstellung der Ausgabe oder einem bestimmten Verhalten der Eingabe.
Model Zusammenarbeit mit
zust andig f ur
Kernfunktionalit at der Anwendung
Abh angige Sichten und Kontrollen
registrieren
Registrierte Komponenten bei
Daten anderung benachrichtigen
View, Controller
Die Sicht (view) zeigt dem Benutzer Informationen an. Es kann mehrere Sichten pro Modell
geben.
View Zusammenarbeit mit
zust andig f ur
Dem Anwender Information anzeigen
Ggf. zugeordnete Kontrolle erzeugen
Liest Daten vom Modell
Controller, Model
Die Kontrolle (controller) verarbeitet Eingaben und ruft passendeDienste der zugeordeten Sicht
oder des Modells auf. Jede Kontrolle ist einer Sicht zugeordnet; es kann mehrere Kontrol-
len pro Modell geben.
Controller Zusammenarbeit mit
zust andig f ur
Benutzereingaben annehmen
Eingaben auf Dienstanforderungen
abbilden (Anzeigedienste der Sicht
oder Dienste des Modells)
View, Model
260
Dynamisches Verhalten
Beispiel:
1. Ein Controller erh alt eine Eingabe (handleEvent) und andert das Modell (service).
2. Das Modell benachrichtigt (update) die registrierten Beobachter.
3. Jeder Beobachter erfragt daraufhin vom Modell den aktuellen Zustand (getData)
4. und bringt sich selbst auf den neuesten Stand (display).
c :Controller
m: Model v: View
handleEvent()
service()
display()
getData()
update()
notify()
261
Beispiel in Java
Das Model verwaltet eine von aussen abfragbare und ver anderbare Zahl. Mehrere Beobachter
k onnen sich registrieren. Wird die Zahl ver andert, benachrichtigt das Modell s amtliche regi-
strierte Beobachter.
class Model
private int value;
private List<Observer> observer;
public void attach(Observer o) ...
public void detach(Observer o) ...
private void notify()
for (Observer o : observer)
o.update();

public int getValue() ...

public void setValue(int i)
value = i;
notify();

262
Observer ist ein Interface, das multiple Beobachter erm oglicht.
interface Observer
void update();

Die ButtonView erm oglicht mittels zweier Buttons, den Wert des Modells zu inkrementieren
oder zu dekrementieren. Sie implementiert das Observer-Interface.
Wenn die Methode update() aufgerufen wird, ruft die ButtonView den aktuellen Wert des Mo-
dells ab und zeichnet sich neu.
F ur die Buttons wird je ein Event-Listener generiert. Diese Event-Listener bilden den Controller.
class ButtonView implements Observer
private Model m;
private JButton up;
private JButton down;
public ButtonView(Model m)
...
createListeners();
...

public void update()

display();

private void createListeners()

UpListener lu = new UpListener(m, this);
DownListener ld = new DownListener(m, this);
up.addActionListener(lu);
down.addActionListener(ld);
...

private void display()

int value = m.getValue();
...

263
Der Controller f ur die ButtonView besteht aus dem UpListener und dem DownListener. Sie wer-
ten ein erhaltenes Event (zB. Mausklick) aus und dekrementieren bzw. inkrementieren den Wert
des Modells.
class UpListener implements ActionListener
private Model m;
private View v;
public UpListener(Model m, View v) ...
public void actionPerformed(ActionEvent e)
...
m.setValue(oldValue +1);

class DownListener implements ActionListener

private Model m;
private View v;
public DownListener(Model m, View v) ...
public void actionPerformed(ActionEvent e)
...
m.setValue(oldValue -1);

Dem Programm k onnten noch weitere Views hinzugef ugt werden, etwa eine View mit einem
Slider zum Einstellen des Wertes.
264
Klassendiagramm
Das Klassendiagramm weicht vom vorhergehenden etwas ab: mehrere voneinander unabh angige
Klassen bilden den Controller.
Model
-value
+attach(Observer)
+detach(Observer)
+notify()
+getValue()
+setValue()
ButtonView
+ButtonView(Model)
+update()
-createListeners()
-display()
UpListener
+UpListener(Model,View)
+actionPerformed(ActionEvent)
Observer
+update()
observers
0..*
1
1 1
DownListener
+DownListener(Model,View)
+actionPerformed(ActionEvent)
1 1
1
1
265
13.1.4 Folgen des Model-View-Controller-Musters
Das Model-View-Controller-Muster hat folgende Vor- und Nachteile:
Vorteile
Mehrere Sichten desselben Modells
Synchrone Sichten

Ansteckbare Sichten und Kontrollen
Nachteile
Erh ohte Komplexit at
Starke Kopplung zwischen Modell und Sicht
Starke Kopplung zwischen Modell und Kontrollen (kann mit Command-Muster umgangen
werden)
MVC-Muster wird ggf. bereits von der GUI-Bibliothek realisiert
Bekannte Einsatzgebiete: Smalltalk, Microsoft Foundation Classes
266
13.2 Schichten und Abstraktionen: Layers
Das Layers-Muster trennt eine Architektur in verschiedene Schichten, von denen jede eine Un-
teraufgabe auf einer bestimmten Abstraktionsebene realisiert.
13.2.1 Beispiel: ISO/OSI-Referenzmodell
Netzwerk-Protokolle sind wahrscheinlich die bekanntesten Beispiele f ur geschichtete Architek-
turen. p Das ISO/OSI-Referenzmodell teilt Netzwerk-Protokolle in 7 Schichten auf, von denen
jede Schicht f ur eine bestimmte Aufgabe zust andig ist:
Application
Presentation
Session
Transport
Network
Data Link
Physical
Layer 7
Layer 6
Layer 5
Layer 4
Layer 3
Layer 2
Layer 1
Provides miscellaneous protocols
for common activities
Structures information
and attaches semantics
Provides dialog control and
synchronization facilities
Breaks messages into packets
and guarantees delivery
Selects a route
from sender to receiver
Detects and corrects errors
in bit sequences
Transmits bits: velocity,
bit-code, connection, etc.
267
13.2.2 Problem
Aufgabe: Ein System bauen, das
Aktivit aten auf niederer Ebene wie Hardware-Ansteuerung, Sensoren, Bitverarbeitung so-
wie
Aktivit aten auf hoher Ebene wie Planung, Strategien und Anwenderfunktionalit at
vereinigt, wobei die Aktivit aten auf hoher Ebene durch Aktivit aten der niederen Ebenen realisiert
werden.
Dabei sollen folgende Ziele ber ucksichtigt werden:

Anderungen am Quellcode sollten m oglichst wenige Ebenen betreffen
Schnittstellen sollten stabil (und m oglicherweisestandardisiert) sein
Teile (= Ebenen) sollten austauschbar sein
Jede Ebene soll separat realisierbar sein
13.2.3 L osung
Das Layers-Muster gliedert ein System in zahlreiche Schichten.
Struktur
Jede Schicht sch utzt die unteren Schichten vor direktem Zugriff durch h ohere Schichten.
Client Layer N
Layer N-1
Layer 1
uses
268
Teilnehmer
Schicht j Zusammenarbeit mit
zust andig f ur
Stellt Dienste bereit f ur Schicht j + 1.
Delegiert Aufgaben an Schicht j1.
Schicht j1
Dynamisches Verhalten
Es gibt verschiedene weitverbreitete Szenarien:
Top-Down Anforderung Eine Anforderung des Benutzers wird von der obersten Schicht ent-
gegengenommen; diese resultiert in Anforderungen der unteren Schichten bis hinunter auf
die unterste Ebene. Ggf. werden die Ergebnisse der unteren Schichten wieder nach oben
weitergeleitet, bis das letzte Ergebnis an den Benutzer zur uckgegeben wird.
Meist bewirkt eine Anforderung auf einer h oheren Schicht zahlreiche Anforderungen auf
einer niederen Schicht.
Bottom-Up Anforderung Hier empf angt die unterste Schicht ein Signal, das an die oberen
Schichten weitergeleitet wird; schlielich benachrichtigt die oberste Schicht den Benut-
zer.
Auch hier k onnen mehrere Signale auf der untersten Schicht zu einer einzigen Nachricht
auf oberen Schichten zusammengefat werden.
Protokollstack In diesem Szenario kommunizieren zwei n-Schichten-Stacks miteinander. Eine
Anforderung wandert durch den ersten Stack hinunter, wird ubertragen und schlielich als
Signal vom zweiten Stack empfangen. Jede Schicht verwaltet dabei ihr eigenes Protokoll.
Beispiel TCP/IP-Stack:
269
HTTP
TCP
IP
Ethernet
HTTP
TCP
IP
Ethernet
HTTP-Protokoll
TCP-Protokoll
IP-Protokoll
Ethernet-Protokoll
Physikalische Verbindung
Anforderung
Benachrichtigung

Ubung: Erstellen Sie geeignete Sequenzdiagramme!

13.2.4 Folgen des Layers-Musters
Das Layers-Muster hat folgende Vor- und Nachteile:
Vorteile
Wiederverwendung und Austauschbarkeit von Schichten
Unterst utzung von Standards
Einkapselung von Abh angigkeiten
Nachteile
Geringere Efzienz
Mehrfache Arbeit (z.B. Fehlerkorrektur)
Schwierigkeit, die richtige Anzahl Schichten zu bestimmen
Bekannte Einsatzgebiete:
Application Programmer Interfaces (APIs)
Datenbanken
Betriebssysteme
Kommunikation. . .
270
13.3 Datenstrom verarbeiten: Pipes and Filters
Das Pipes and Filters-Muster bietet eine Struktur f ur Systeme, die einen Datenstrom verarbeiten.
Jede Verarbeitungsstufe wird durch eine Filter-Komponente realisiert; Pipes (Kan ale) leiten die
Daten von Filter zu Filter.
13.3.1 Beispiel: Compiler
Ein Compiler soll ein Programm in Maschinencode ubersetzen. Dies geschieht in mehreren Ver-
arbeitungsstufen:
Zun achst wird der Programmtext durch einen Pr aprozessor geleitet.
Die lexikalische Analyse wandelt den Programmtext in einen Strom von Tokens, . . .
. . . der in der syntaktischen Analyse in einen Syntaxbaum umgewandelt wird.
Die semantische Analyse bindet Namen an ihre Deklarationen und reichert den Syntax-
baum um diese Bindungen an.
Schlielich wird Zwischencode erzeugt und optimiert, . . .
der im Backend schlielich in den passenden Maschinencode umgewandelt wird.
Prprozessor
Lexikalische Analyse (Scanner)
Syntaktische Analyse (Parser)
Semantische Analyse
Erzeugung von Zwischencode
Optimierung
Intel Backend PowerPC Backend Bytecode Backend Interpreter
ASCII Programmtext
Bearbeiteter Programmtext
Tokenstrom
Syntaxbaum
Angereicherter Syntaxbaum
Zwischencode
Optimierter Zwischencode
Ausfhrbares Programm
271
13.3.2 Problem
Aufgabe: Ein System bauen, das einen Strom von Eingabedaten verarbeiten oder umwandeln
soll. Das System soll oder kann nicht als monolithischer Block gebaut werden.
Das System soll erweitert werden k onnen, indem einzelne Teile ausgetauscht oder neu
kombiniert werden wom oglich sogar durch den Anwender.
Kleine Verarbeitungsstufen k onnen leichter wiederverwendet werden.
Verarbeitungsstufen, die nicht aufeinander folgen, teilen keine Information (und sind somit
entkoppelt).
Es gibt verschiedene Eingabequellen (z.B. verschiedene Sensoren)
Explizites Speichern von Zwischenergebnissen ist fehlertr achtig (insbesondere, wenn es
Anwendern uberlassen wird).
Parallele Verarbeitung soll zuk unftig m oglich sein.
Nicht jedes System kann als Folge von Verarbeitungsstufen geplant werden ein interaktives,
ereignisgesteuertes System etwa pat nicht in dieses Muster.
13.3.3 L osung
Das Pipes and Filters-Muster teilt die Aufgaben des Systems in mehrere Verarbeitungsstufen, die
durch den Datenu durch das System verbunden sind: Die Ausgabe einer Stufe ist die Eingabe
der n achsten Stufe.
Jede Verarbeitungsstufe wird durch einen Filter realisiert. Ein Filter kann Daten inkrementell
verarbeiten und liefern er kann also mit der Ausgabe beginnen, noch bevor er die Eingabe
komplett eingelesen hat. Dies ist eine wichtige Voraussetzung f ur paralleles Arbeiten.
Die Eingabe des Systems ist eine Datenquelle, die Ausgabe des Systems eine Datensenke. Da-
tenquelle, Filter und Datensenke sind durch Pipes verbunden. Die Folge von Verarbeitungsstufen
heit Pipeline.
272
Teilnehmer
Filter Ein Filter kann auf dreierlei Weise mit den Daten umgehen:
Er kann die Daten anreichern, indem er weitere Informationen berechnet und hin-
zuf ugt,
Er kann die Daten verfeinern, indem er Information konzentriert oder extrahiert
Er kann die Daten ver andern, indem er sie in eine andere Darstellung uberf uhrt.
Nat urlich sind auch Kombinationen dieser Grundprinzipien moglich.
Filter Zusammenarbeit mit
zust andig f ur
Holt Eingabedaten.
Wendet eine Funktion auf seine
Eingabedaten an.
Liefert Ausgabedaten.
Pipe
Ein Filter kann auf verschiedene Weise aktiv werden:
Die folgende Pipeline holt Daten aus dem Filter
Die vorhergehende Pipeline schickt Daten in den Filter
Meistens ist der Filter jedoch selbst aktiv er holt Daten aus der vorhergehenden
Pipeline und schickt Daten in die folgende Pipeline.
273
Pipe Eine Pipe verbindet Filter miteinander; sie verbindet auch die Datenquelle mit dem ersten
Filter und den letzten Filter mit der Datensenke.
Verbindet eine Pipe zwei aktive Komponenten, sichert sie die Synchronisation der Filter.
Pipe Zusammenarbeit mit
zust andig f ur

Ubermittelt Daten.
Puffert Daten.
Synchronisiert aktive Nachbarn.
Datenquelle, Filter, Datensenke
Eine Pipe kann auch durch Aufruf implizit realisiert werden etwa, indem der erste Filter
Dienste des zweiten Filter aufruft. Dies erschwert aber die freie Kombination von Filtern.
Datenquelle, Datensenke Diese Komponenten sind die Endst ucke der Pipeline und somit die
Verbindung zur Auenwelt.
Datenquelle/-senke Zusammenarbeit mit
zust andig f ur

Ubermittelt Daten an/aus Pipeline.
Pipe
Eine Datenquelle kann entweder aktiv sein (dann reicht sie von sich aus Daten in die Pipe-
line) oder passiv (dann wartet sie, bis der n achste Filter Daten anfordert).
Analog kann die Datensenke aktiv Daten anfordern oder passiv auf Daten warten.
274
Dynamisches Verhalten
Zwei aktive Filter sind durch eine Pipe verbunden; beide Filter arbeiten parallel.
Die Pipe puffert Ein- und Ausgabedaten; Zur Vereinfachung nehmen wir an, da die Pipe genau
ein Datenelement puffern kann.
1. Zun achst versucht Filter f2, aus der Pipe zu lesen (read); er mu warten.
2. Filter f1 liest (read) und verarbeitet (f1) Daten und schreibt (write) sie in die Pipe.
3. Filter f2 kann die Daten nun lesen, verarbeiten (f2) und sie in die Datensenke (write)
schreiben.
4. Filter f1 hat gleichzeitig ein weiteres Datenelement verarbeitet (f1); beim Schreiben
(write) mu er jedoch warten,. . .
5. . . . bis Filter f2 das Element gelesen hat (read).
read()
read()
write()
read()
read()
f1: Filter
p: Pipe
f2: Filter s: Datensenke
q: Datenquelle
f1()
write()
f2()
f1()
write()
275
13.3.4 Folgen des Pipes and Filters-Musters
Das Pipes and Filters-Muster hat folgende Vor- und Nachteile:
Vorteile
Kein Speichern von Zwischenergebnissen (z.B. in Dateien) notwendig
Flexibilit at durch Austauschen von Filtern
Rekombination von Filtern (z.B. in UNIX)
Filter k onnen als Prototypen erstellt werden
Parallel-Verarbeitung m oglich
Nachteile
Gemeinsamer Zustand (z.B. Symboltabelle in Compilern) ist teuer und unexibel.
Efzienzsteigerung durch Parallelisierung oft nicht m oglich (z.B. da Filter aufeinander
warten oder nur ein Prozessor arbeitet)
Overhead durch Datentransformation (z.B. UNIX: Alle Daten m ussen in/aus Text konver-
tiert werden)
Fehlerbehandlung ist schwer zu realisieren
Bekannte Einsatzgebiete: UNIX (Pionier)
276
13.4 Vermitteln von Ressourcen: Broker
13.4.1 Beispiel: Rechenzeit verteilen
Moderne Arbeitsplatzrechner verbringen einen Groteil ihrer Rechenzeit damit, auf Eingaben
des Benutzers zu warten.
Sie m ochten ein System bauen, in dem diese Rechenzeit anderen Anwendern zur Verf ugung
gestellt werden kann etwa, um gemeinsam rechenintensive Probleme zu l osen.
Clients Servers
Broker
Ihr System soll
zwischen Anbietern (Servern) und Anwendern (Clients) von Rechenzeit vermitteln
transparent arbeiten: Anwender m ussen nicht wissen, wo ihre Berechnungen ausgef uhrt
werden
dynamisch arbeiten: Zur Laufzeit k onnen jederzeit Anbieter und Anwender hinzukommen
oder wegfallen.
13.4.2 Problem
Ein komplexes Software-System soll als Menge von entkoppelten, zusammenarbeitenden Kom-
ponenten realisiert werden (und nicht als eine monolithische Anwendung).
Die Komponenten sollen verteilt sein; dies soll jedoch m oglichst transparent gestaltet werden.
277
Zur Laufzeit k onnen neue Komponenten hinzukommen oder wegfallen.
13.4.3 L osung
Ein Broker (Vermittler) vermittelt zwischen Dienste-Anbietern (Server) und Dienste-Anwendern
(clients). Dienste-Anbieter melden sich beim Broker an und machen ihre Dienste f ur Anwender
verf ugbar. Anwender senden Dienste-Anforderungen an den Broker, der sie an einen geeigneten
Anbieter weiterleitet.
Zu den Aufgaben des Brokers geh ort es,
den passenden Anbieter zu nden
Anfragen des Anwenders an den passenden Anbieter weiterzuleiten
die Antwort des Anbieters an den Anwender zur uckzusenden
Struktur
Broker
+main_event_loop()
+update_repository()
+register_service()
+acknowledgment()
+find_server()
+find_client()
+forward_request()
+forward_response()
Client-side Proxy
+pack_data()
+unpack_data()
+send_request()
+return()
Server-side Proxy
+pack_data()
+unpack_data()
+call_service()
+send_response()
Client
+call_server()
+start_task()
+use_Broker_API()
Server
+Initialize()
+enter_main_loop()
+run_service()
+use_Br