SOFTWARETECHNIK - beim Fachbereich Informatik

SOFTWARETECHNIK
Wintersemester 2005/06
Version 1 : Stand: 27.05.04
Version 2 : Stand: 27.11.04
Version 3: Stand: 10.11.05
Urs Andelfinger, Frank Bühler,
Michael Guist, Stephan Karczewski,
Gerhard Raffius, Inge Schestag,
Wolfgang Weber, Gerhard Winkler
*
1 *
*
1 *
1

2
Vorwort
Sehr geehrter Leser, sehr geehrte Leserin,
Stand 01.03.04
mit dieser Veröffentlichung lesen Sie ein Hochschulskript, das für die Studierenden
am Fachbereich Informatik erstellt wurde.
Dementsprechend handelt es sich weder um ein Lehrbuch noch um ein Fachbuch
zur Softwaretechnik. Hinweise auf Lehr- und Fachbücher finden Sie im
Literaturverzeichnis. Die Autoren dieses Skriptes empfehlen Ihnen dringend neben
dem Besuch der Vorlesung auch in diesen Quellen nachzulesen und damit zu
arbeiten.
Die aktuellen Studien- und Prüfungsordnungen sehen vor, dass die Studierenden
im Studiengang Informatik die Lehrveranstaltung Softwaretechnik im 2. und 3.
Studiensemester besuchen. Neben der Vorlesung mit insgesamt 4 Semesterwochenstunden
ist zusätzlich ein Praktikum mit insgesamt 3 Semesterwochenstunden
verpflichtend vorgesehen. Beide Teile sind nach Meinung des Fachbereichs
dringend nötig, um die Lehr- und Lerninhalte kennen zu lernen, zu verstehen,
anwenden zu können und somit zu beherrschen.
Vorlesung und Praktikum sind als integrierte Lehrveranstaltung konzipiert, d.h.
auch, dass es aus Sicht der Lehrenden keinen Sinn macht, nur einen der beiden
Teile zu absolvieren. Wenn dies aus besonderen Gründen (z.B. Nichtbestehen der
Prüfung) einmal nötig werden sollte, wird diese Situation zwar akzeptiert, sie ist
aber weder empfehlenswert noch etwas, was Sie anstreben sollten.
Abgeschlossen werden soll die Lehrveranstaltung mit den Prüfungsleistungen
Softwaretechnik I und Softwaretechnik II nach dem 2. und 3. Semester.
Dieses Skript ist aber "nur" zur Unterstützung der Lehrveranstaltung Softwaretechnik
entwickelt worden, zur Vorbereitung der Prüfungen also keinesfalls

ausreichend. Die Autoren weisen ausdrücklich darauf hin, dass dieses Skript
konzipiert und entwickelt wurde, um Ihnen den Besuch der Lehrveranstaltung und
die Bearbeitung der Inhalte zu erleichtern und nicht zu ersetzen.
Neben den Abbildungen von in der Vorlesung verwendeten Schaubildern und
Folien enthält das Skript in knapper Form die wichtigsten Aussagen und
Lehrinhalte. Beispiele, Fragen und Musterlösungen runden den Inhalt ab und sollen
Ihnen Anregungen für eigenes Arbeiten und Nachdenken liefern.
3

4
Inhaltsverzeichnis
1 Einführung.........................................................................................11
1.1 Was ist ein gutes Softwaresystem?................................................................11
1.2 Was ist Softwaretechnik?...............................................................................12
1.3 Geschichtliche Entwicklung...........................................................................13
1.4 Softwarequalität.............................................................................................14
1.5 Software-Qualitätseigenschaften...................................................................15
1.6 Phasen der Softwareentwicklung...................................................................19
1.7 Überblick über den Aufbau des SWT-Skriptes..............................................23
2 Objektorientierung............................................................................25
2.1 Einführung......................................................................................................25
2.2 Prinzipien der Objektorientierung..................................................................26
2.2.1 Abstraktion..............................................................................................26
2.2.2 Kapselung................................................................................................26
2.2.3 Wiederverwendung..................................................................................27
2.2.4 Beziehungen............................................................................................28
2.2.5 Polymorphismus......................................................................................28
2.3 Überblick Objektorientierte Programmiersprachen.......................................29
2.3.1 C++..........................................................................................................29
2.3.2 JAVA.......................................................................................................30
2.3.3 C#.............................................................................................................30
2.4 Werkzeuge für die objektorientierte Entwicklung.........................................31
2.5 Weiterführende Literatur................................................................................32
3 UML Unified Modeling Language...................................................33
3.1 Was ist die UML?...........................................................................................33
3.2 Entstehung der UML......................................................................................33
3.3 Diagramme der UML 2.0...............................................................................34
3.3.1 Klassendiagramm Class Diagram..........................................................37
3.3.1.1 Zweck...............................................................................................37
3.3.1.2 Notation............................................................................................37
3.3.1.3 Anwendungsbereich.........................................................................49
3.3.1.4 Zusammenhang................................................................................50
3.3.1.5 Hinweise für die Praxis....................................................................50
3.3.1.6 Beispiel.............................................................................................52
3.3.2 Objektdiagramm - Object Diagram.........................................................54
3.3.2.1 Zweck...............................................................................................54
3.3.2.2 Notation............................................................................................55

3.3.2.3 Beispiel.............................................................................................55
3.3.3 Komponentendiagramm - Component Diagram....................................55
3.3.3.1 Zweck...............................................................................................56
3.3.3.2 Notation............................................................................................56
3.3.3.3 Anwendungsbereich.........................................................................57
3.3.3.4 Zusammenhang ...............................................................................57
3.3.3.5 Hinweise für die Praxis....................................................................57
3.3.3.6 Beispiel.............................................................................................58
3.3.4 Paketdiagramm - Package Diagram........................................................58
3.3.4.1 Zweck...............................................................................................58
3.3.4.2 Notation............................................................................................59
3.3.4.3 Anwendungsbereich.........................................................................59
3.3.4.4 Zusammenhang ...............................................................................60
3.3.4.5 Beispiel ............................................................................................60
3.3.5 Anwendungsfalldiagramm - Use Case Diagram.....................................61
3.3.5.1 Zweck...............................................................................................61
3.3.5.2 Notation ...........................................................................................61
3.3.5.3 Anwendungsbereich.........................................................................63
3.3.5.4 Zusammenhang ...............................................................................64
3.3.5.5 Hinweise für die Praxis....................................................................65
3.3.5.6 Beispiel ............................................................................................66
3.3.6 Sequenzdiagramm - Sequence Diagram.................................................68
3.3.6.1 Zweck...............................................................................................68
3.3.6.2 Notation............................................................................................68
3.3.6.3 Anwendungsbereich.........................................................................71
3.3.6.4 Zusammenhang ...............................................................................72
3.3.6.5 Hinweis für die Praxis......................................................................72
3.3.6.6 Beispiel ............................................................................................73
3.3.7 Kommunikationsdiagramm - Communication Diagram........................77
3.3.7.1 Zweck................................................................................................77
3.3.7.2 Notation............................................................................................77
3.3.7.3 Anwendungsbereich.........................................................................77
3.3.7.4 Zusammenhang ...............................................................................77
3.3.7.5 Hinweise für die Praxis....................................................................78
3.3.7.6 Beispiel ............................................................................................78
3.3.8 Zeitverlaufsdiagramm - Timing-Diagram...............................................79
3.3.8.1 Zweck...............................................................................................79
3.3.8.2 Notation............................................................................................79
3.3.8.3 Anwendungsbereich.........................................................................80
5

6
3.3.8.4 Zusammenhang................................................................................80
3.3.8.5 Hinweis für die Praxis......................................................................80
3.3.8.6 Beispiel.............................................................................................80
3.3.9 Interaktionsübersicht Diagramm - Interaction Overview Diagram........81
3.3.9.1 Zweck...............................................................................................81
3.3.9.2 Anwendungsbereich.........................................................................82
3.3.9.3 Zusammenhang................................................................................82
3.3.9.4 Hinweis für die Praxis......................................................................82
3.3.9.5 Beispiel.............................................................................................82
3.3.10 Zustandsautomat-State Machine Diagram............................................83
3.3.10.1 Zweck.............................................................................................83
3.3.10.2 Notation..........................................................................................84
3.3.10.3 Anwendungsbereich.......................................................................89
3.3.10.4 Zusammenhang..............................................................................89
3.3.10.5 Hinweis für die Praxis....................................................................89
3.3.10.6 Beispiel...........................................................................................90
3.3.11 Aktivitätsdiagramm - Activity Diagram...............................................91
3.3.11.1 Zweck.............................................................................................91
3.3.11.2 Notation..........................................................................................92
3.3.11.3 Anwendungsbereich.......................................................................96
3.3.11.4 Zusammenhang..............................................................................96
3.3.11.5 Hinweise für die Praxis..................................................................97
3.3.11.6 Beispiel...........................................................................................98
3.3.12 Verteilungsdiagramm - Deployment-Diagram...................................100
3.3.12.1 Zweck...........................................................................................100
3.3.12.2 Notation........................................................................................101
3.3.12.3 Beispiel.........................................................................................101
3.3.13 Kompositionsstrukturdiagramm - Composite Structure Diagram......102
3.3.13.1 Zweck...........................................................................................102
3.3.13.2 Notation........................................................................................102
3.3.13.3 Anwendungsbereich.....................................................................103
3.3.13.4 Neu in UML 2..............................................................................103
3.4 Object Constraint Language.........................................................................103
3.5 Model Driven Architecture...........................................................................104
3.5.1 Was ist MDA?.......................................................................................104
3.5.2 Motivation..............................................................................................104
3.5.3 Wie funktioniert MDA?.........................................................................105
3.6 UML Profile..................................................................................................106
4 Vorgehens- und Prozessmodelle.....................................................107

4.1 Überblick (Motivation, Begriffe).................................................................107
4.2 Das objektorientierte Projekt........................................................................108
4.3 Wasserfallmodell, Evolutionäres Modell, Iteratives Modell.......................109
4.4 Prototyping ...................................................................................................115
4.5 Das V-Modell................................................................................................117
4.5.1 Struktur des Standardisierungskonzeptes..............................................118
4.5.2 Eigenschaften des V-Modells................................................................120
4.5.3 Produktzustände und Übergänge...........................................................120
4.5.4 Erzeugnisstruktur...................................................................................120
4.5.5 Struktur und Inhalt des V-Modells.......................................................121
4.5.6 Aktivitäten und Produkte.......................................................................121
4.5.7 Aktivitätenzerlegung..............................................................................122
4.5.8 Produktfluss und Abwicklung...............................................................123
4.5.9 Die Submodelle.....................................................................................123
4.5.10 Zusammenspiel der Submodelle.........................................................124
4.5.11 Submodell "Softwareerstellung" (SWE).............................................124
4.5.12 Systemanforderungsanalyse und -entwurf (SWE 1)...........................125
4.5.13 Systemanforderungsanalyse und -entwurf (SWE 1)...........................125
4.5.14 DV-Anforderungsanalyse und -entwurf (SWE 2)..............................125
4.5.15 DV-Anforderungsanalyse und -entwurf (SWE 2)..............................126
4.5.16 SW-Anforderungsanalyse (SWE 3)....................................................126
4.5.17 Grobentwurf (SWE 4).........................................................................126
4.5.18 Feinentwurf (SWE 5)..........................................................................127
4.5.19 Implementierung (SWE 6)..................................................................127
4.5.20 SW-Integration (SWE 7).....................................................................127
4.5.21 DV-Integration (SWE 8).....................................................................127
4.5.22 Produkte im Submodell SWE.............................................................128
4.5.23 Submodell"Qualitätssicherung" .........................................................128
4.5.24 Aktivitäten im Submodell QS.............................................................128
4.5.25 Aktivitäten im Submodell KM............................................................129
4.5.26 Submodell "Projektmanagement" (PM).............................................129
4.5.27 Aktivitäten im Submodell PM.............................................................130
4.5.28 Rollen im V-Modell............................................................................130
4.5.29 Tailoring...............................................................................................130
4.5.30 Zusammenfassung...............................................................................131
4.6 RUP ..............................................................................................................132
4.6.1 RUP-Phase "Inception".........................................................................133
4.6.2 RUP-Phase "Elaboration"......................................................................134
4.6.3 RUP-Phase "Construction"....................................................................135
7

8
4.6.4 RUP-Phase "Transition"........................................................................136
4.7 eXtreme Programming (XP).........................................................................137
4.7.1 Warum XP?............................................................................................137
4.7.2 Die zwölf Praktiken...............................................................................137
4.7.3 Der XP Prozess......................................................................................140
4.7.4 Die Umsetzung......................................................................................143
4.7.5 Weiterführende Literatur.......................................................................144
4.7.5.0.1 Literatur...................................................................................144
4.8 Prozessorientiertes Software-Qualitätsmanagement....................................144
4.8.1 Überblick ..............................................................................................145
4.8.2 Das ISO 15504 / ISO 12207 (SPICE) Prozessmodell..........................148
4.8.2.1 Die Kunden Lieferanten Kategorie (CUS)....................................149
4.8.2.2 Die Engineering Kategorie.............................................................151
4.8.2.3 Die unterstützenden Prozesse ........................................................153
4.8.2.4 Die Management Prozess Kategorie..............................................158
4.8.2.5 Die Organisations Prozeß Kategorie..............................................160
4.8.2.6 Prozeß Tailoring.............................................................................162
4.8.3 Das ISO 15504 / ISO 12207 Reifegradmodell.....................................162
4.8.3.1 Stufe 0 - Unvollständiger Prozess (Incomplete)............................164
4.8.3.2 Stufe 1 - Durchgeführter Prozess (Performed) .............................165
4.8.3.3 Stufe 2 - Gelenkter Prozess (Managed). .......................................165
4.8.3.4 Stufe 3 - Etablierter Prozess (Established). ...................................166
4.8.3.5 Stufe 4 - Quantitativ steuerbarer und vorhersagbarer Prozess
(Predictable) ...............................................................................................168
4.8.3.6 Stufe 5 - Optimierender Prozess (Optimizing). ............................169
4.8.4 Anwendungsbeispiel der ISO 15504/12207: Reifegradstufen im
Projektmanagement........................................................................................171
4.8.5 Risikomanagement gemäß ISO 15504 / ISO 12207 ............................173
4.8.6 Assessments gemäß ISO 15504 / ISO 12207 ......................................176
4.8.7 Das CMMI-Modell................................................................................179
4.8.8 Literatur .................................................................................................182
5 Requirements Engineering..............................................................183
5.1 Textuelle Beschreibung von Anwendungsfällen..........................................183
6 Der Qualitätsbegriff und die Qualitätskriterien für Software.....195
6.1 Die Qualitätseigenschaften beim fertigen Produkt:......................................195
6.1.1 Wichtige Kriterien aus Benutzersicht....................................................196
6.1.2 Wichtige Kriterien aus Entwicklersicht ..............................................197
6.2 Qualitätsmanagement...................................................................................197
6.2.1 Methoden und Werkzeuge des Qualitätsmanagements........................199

6.2.2 Die Bedeutung von Qualitätsstandards.................................................199
6.2.3 Die Problematik von Standards in der Softwareentwicklung...............200
6.2.4 Die Dokumentation von Software.........................................................200
6.3 Die statische Kontrolle der Qualität und anderer Softwareeigenschaften . .201
6.3.1 Softwaremaße-Softwaremessung..........................................................201
6.3.1.1 Die Function-Point Methode..........................................................202
6.3.1.2 Halstead-Maße................................................................................205
6.3.1.3 Das Mc Cabe-Maß.........................................................................209
6.3.1.4 Fan-in---Fan-out.............................................................................211
6.3.2 Reviews..................................................................................................213
6.3.2.1 Die Entwurfsinspektion.................................................................214
6.3.2.2 Die Codeinspektion.......................................................................215
6.3.3 Formale Verifikation.............................................................................217
6.3.3.1 Baumförmige Darstellung der Verifikationsregeln.......................221
6.3.3.2 Beweis der Endlichkeit von Algorithmen......................................227
7 Testen................................................................................................229
7.1 Testverfahren - Wie wird getestet? ..............................................................229
7.2 Wie findet man Testdaten.............................................................................231
7.3 Wer testet?....................................................................................................232
7.4 Testen von objektorientierter Software........................................................232
7.5 Teststrategie..................................................................................................233
7.6 Testwerkzeuge ............................................................................................234
7.7 xUnit, JUnit...................................................................................................234
8 Konfigurationsmanagement...........................................................238
8.1 Warum Konfigurationsmanagement (KM)?................................................238
8.2 Was ist (Software-)Konfigurationsmanagement (SKM)?...........................238
8.3 Einsatz von Software-Konfigurationsmanagement in Projekten................239
8.4 Weiterführende Literatur..............................................................................242
9 Petri-Netze........................................................................................243
9.1 Zustände und Ereignisse...............................................................................243
9.2 Dynamik in Petri-Netzen..............................................................................244
9.3 Regeln in Petri-Netzen..................................................................................244
9.4 Komplexe Situationen in Petri-Netzen.........................................................246
9.5 Kontakt- und Konfliktsituation....................................................................246
9.6 Gabel und Zusammenführung......................................................................247
9.7 Beispiele von Petri-Netzen...........................................................................248
9.8 Varianten von Petri-Netzen..........................................................................252
9.8.1 Bedingungs-/Ereignis-Netze..................................................................253
9.8.2 Stellen-/Transitions-Netze.....................................................................253
9

10
10 Entscheidungstabellen...................................................................254
10.1 Grundlagen..................................................................................................254
10.2 ET-Typen ...................................................................................................255
10.3 Anwendung von Entscheidungstabellen....................................................255
10.4 Entscheidungsbaum....................................................................................258
10.5 Weiterführende Literatur............................................................................260

1 Einführung
Ziel der Softwaretechnik ist es gute d. h. qualitativ hochwertige Softwaresysteme
erstellen zu können.
1.1 Was ist ein gutes Softwaresystem?
Letztendlich ist nach [StP 00] ein gutes System eines, das den Bedürfnissen des
Anwenders gerecht wird.
Das System muss deshalb...
• nützlich und nutzbar sein. Es muss dem Anwender das Leben möglichst stark
erleichtern.
• zuverlässig sein. Es soll möglichst wenig Fehler enthalten.
• flexibel sein. Das System muss leicht an geänderte Anforderungen des
Benutzers anpassbar sein. Die Fehler müssen leicht zu beheben sein.
• kostengünstig sein, nicht nur in der Anschaffung, sondern auch im Unterhalt.
• verfügbar sein. Das System muss auf jetzigen und zukünftigen Zielplattformen
(Hardware, Betriebssystemen etc.) lauffähig bzw. leicht adaptierbar sein. Zur
Verfügbarkeit gehört natürlich auch, dass das Softwareprodukt überhaupt
existiert und zwar zu dem Zeitpunkt, zu dem es zum Einsatz kommen soll.
Frage: Kennen Sie Projekte mit großen Softwareanteil, die gescheitert sind?
Warum sind diese Projekte gescheitert?
11

12
1.2 Was ist Softwaretechnik?
In dieser Vorlesung sollen Sie lernen, wie man gute Softwaresysteme erstellt, d. h.
es sollen Methoden und Techniken vermittelt werden, um Software in einem
gegebenen Zeitrahmen mit den oben angegebenen Eigenschaften zu realisieren.
Das Fach Softwaretechnik bietet Methoden für die konstruktiven Phasen der Software
Entwicklung (Analyse, Entwurf, Implementierung), die verwendet werden,
um die Arbeitsergebnisse dieser Phasen zu strukturieren. Softwaretechnik stellt
aber auch Modelle zur Definition von Qualität zur Verfügung (Qualitätseigenschaften,
Qualitätsmodelle) und entsprechende Methoden zur Überprüfung der
Phasenergebnisse (Test, Verifikation, Qualitätssicherung). Zur zeitlichen Strukturierung
von Softwareprojekten sind Projektmodelle (Phasenmodelle) definiert, die
eine zeitliche Gliederung eines Projektes in verschiedene Entwicklungsphasen
ermöglichen.
Softwaretechnik beschäftigt sich folglich mit Methoden für das "Pragrammieren im
Großen". Unter Programmieren im versteht man die Abwicklung großer
Softwareprojekte. Ein großes Softwareprojekt ist gekennzeichnet durch den Einsatz
eines Entwicklerteams. Ein Team von mehreren Entwicklern entwickelt
gemeinsam ein Softwareprodukt. Es werden in der Regel mehrere Versionen der
Software erzeugt. Die Software wird weiterentwickelt und erweitert; veraltete
Softwareversionen werden durch verbesserte ersetzt. Ein großes Softwareprojekt
hat eine lange Entwicklungszeit. Große Systeme werden über mehrere Monate oder
Jahre entwickelt. Das erfordert eine zeitliche Projektplanung und
Terminüberwachung.
Software hat eine lange Lebensdauer, während der das Produkt Software an neue
Anforderungen angepasst werden muss.
Diese Probleme bei der Software Entwicklung im Großen erfordern andere Vorgehensweisen
als das Programmieren einer kleinen Anwendung (z. B. in einem Programmierpraktikum).
Die Methode VHIT (Vom Hirn Ins Terminal) ist zur Entwicklung komplexer Systeme
nicht geeignet. Dazu benötigt ein Entwicklerteam Prinzipien und Methoden
des Software Engineering.

1.3 Geschichtliche Entwicklung
In der "Steinzeit" der Software Entwicklung, in den 50er und 60er Jahren des 20.
Jahrhunderts wurden Computer und die dafür notwendige Software fast ausschließlich
im naturwissenschaftlichen Bereich eingesetzt. Die eingesetzten Programme
dienten hauptsächlich der effizienten Lösung von mathematischen Problemen.
Die Hardware war sehr teuer, die Software war sehr preisgünstig oder
wurde von den Anwendern selbst geschrieben.
Durch sinkende Hardwarepreise wurden Computer für eine größere Zielgruppe
erschwinglich. Dadurch veränderten sich aber auch die Anforderungen an die
Software. Es wurde Software für die verschiedensten Bereiche gebraucht. Der
Umfang der Software wurde immer größer. Ihre Komplexität war mit den bis zu
diesem Zeitpunkt bekannten Vorgehensweisen für das "Programmieren im Kleinen
" nicht mehr zu beherrschen. Ausgelieferte Programme waren fehlerhaft und
unzuverlässig. Software Projekte wurden nicht termingerecht fertig gestellt. Die zur
Entwicklung eingeplanten Budgets wurden überschritten. Dieser Zustand der
Software Industrie wurde mit dem Begriff der Softwarekrise charakterisiert.
Wissenschaft und Forschung entwickelten als Reaktion darauf strukturierte Programmiersprachen
und Entwicklungsmethoden zur Lösung der Probleme, die zur
Softwarekrise führten. Der Begriff Software Engineering wurde zuerst auf einer
Software-Engineering-Konferenz der NATO, die 1968 in Garmisch veranstaltet
wurde, geprägt. Diese Konferenz gilt allgemein als Geburtsstunde der Softwaretechnik.
Nachfolgend sind die Entwicklungsschritte der Softwaretechnik in Stichworten
aufgeführt: (angelehnt an [Sch 90])
1. Erster Ansatz zur Entwicklung übersichtlicher Programme (1968)
Dijkstra schlägt die "strukturierte Programmierung" vor (Vermeidung von
GOTO-Anweisungen).
2. Entwicklung von Software-Engineering-Prinzipien (1968 - 1974)
Es werden die theoretischen Grundlagen (Prinzipien) erarbeitet, die der strukturierten
Entwicklung von Programmen zugrundeliegen: strukturierte Programmierung,
schrittweise Verfeinerung, Geheimnis-Prinzip, Programmodularisierung,
Software-Lifecycle, Entity-Relationship-Modell, Software-Ergonomie
3. Entwicklung von phasenspezifischen Software-Engineering-Methoden (1972
- 1975)
Umsetzen der Software-Engineering-Prinzipien in Entwurfsmethoden: HIPO,
Jackson, Constantine-Methode, erste Version von Smalltalk
4. Entwicklung von phasenspezifischen Werkzeuge (1975 - 1985):
Der Einsatz von SE-Methoden mit maschineller Unterstützung (z.B.
Programminversion, Batchwerkzeuge)
13

14
5. Entwicklung von phasenübergreifenden (integrierten) Software-Engineering-
Methoden (ab 1980)
Es sollen die Ergebnisse einer Phase des Software-Lifecycles automatisch an die
nächste Phase weitergegeben werden: Methodenverbund
6. Entwicklung von phasenübergreifenden (integrierten) Werkzeuge (ab 1980)
Einsatz einer Datenbank als automatischer Schnittstelle zwischen den einzelnen
Phasen des Software-Lifecycles. Interaktiver Programmaufruf durch CAS-
Werkzeuge (Computer Aided Softwaredesign)
7. Definition verschiedener, konkurrierender objektorientierter Methoden (ab
1990)
Es entstanden parallel verschiedene Objektorientierte Analyse- und Entwurfsmethoden
(Booch, Jacobson, Rumbaugh, Shlaer/Mellor, Coad/Yourdon u. a.).
Die Methoden wurden in CASE Tools (Computer Aided Software Engineering)
realisiert.
8. Integration der OO-Methoden zur UML – Unified Modeling Language (ab
1995)
Jacobson, Booch und Rumbaugh schließen sich zusammen und entwickeln die
UML. In der UML sollen die Schwächen der frühen OO-Methoden beseitigt
werden und ein weltweit gültiger, einheitlicher Standard geschaffen werden. Die
UML 1.0 wurde 1997 verabschiedet.
9. UML 2.0
Nachdem die UML 1.0 bis zur Version UML 1.5 erweitert wurde, erschien 2004
die UML 2.0. In dieser Version wurde die Sprachelemente der UML an aktuelle
Technologien angepasst; es wurden Redundanzen und Inkonsistenzen in der
Sprachdefinition beseitigt.
1.4 Softwarequalität
Das Produkt Software soll nach seiner Fertigstellung den Anforderungen der
Benutzer entsprechen. (Es muss nicht eine "möglichst hohe" Qualität haben, sondern
die vom Benutzer verlangte Qualität!) Dazu ist es notwendig die Qualitätsanforderungen
der Benutzer zu definieren, für die Entwicklung Methoden und Hand-

lungsanweisungen zum Erreichen der geforderten Qualität zu definieren und am
fertigen Produkt die entwickelte Qualität zu überprüfen.
Zur Definition von Softwarequalität entstand eine Vielzahl von Begriffen, die
sogenannten Qualitätseigenschaften, die verschiedene Dimensionen der Qualität
beschreiben. Außer den im Folgenden beschriebenen Eigenschaften existiert eine
Vielzahl weiterer Qualitätseigenschaften, die nicht einheitlich definiert sind.
Nachfolgend werden, als in die Problematik einführendes Beispiel,
Qualitätseigenschaften mit Hilfe eines Modells nach Raasch [Ra 92] erläutert.
1.5 Software-Qualitätseigenschaften
Raasch benutzt die in Abbildung 1.5.1 beschriebene Hierarchie von Qualitätseigenschaften,
die Qualität aus Benutzersicht und Qualität aus Entwicklersicht
unterscheidet. Er geht davon aus, dass für diese beiden Gruppen unterschiedliche
Qualitätseigenschaften wichtig sind. Der Benutzer verwendet Software, folglich
sind für ihn Eigenschaften wie Funktionserfüllung, Zuverlässigkeit usw. von
Bedeutung. Für den Entwickler sind Eigenschaften wie Wartbarkeit,
Erweiterbarkeit usw. von Bedeutung. Qualitätseigenschaften können in einer Hierarchie
verfeinert werden.
Qualitätsmerkmale aus
Benutzer sicht
Qualitätsmerkmale aus
Entwicklersicht
Funktionserfüllung
Effizienz
Zuverlässigkeit
Benutzbarkeit
Sicherheit
Erweiterbarkeit
Wartbarkeit
Übertragbarkeit
Wiederverwendbarkeit
Abbildung 1.5.1 Software - Qualitätseigenschaften
HW-Effizienz
SW-Effizienz(Performance)
Robustheit
Fehlertoleranz
Änderbarkeit
Verständlichkeit
Testbarkeit
15

16
Funktionserfüllung:
ist ein Maß für die Übereinstimmung zwischen geplantem und tatsächlich
realisiertem Funktionsumfang.
Je mehr ein System kann, desto vielseitiger ist es einsetzbar. Man kann mit Software
jede beliebige Funktion verwirklichen, aber man sollte keine Systeme planen,
die alle beliebigen Funktionen enthalten.
Effizienz:
ist das Ausmaß der Inanspruchnahme von Betriebsmitteln (HW) durch das Software-Produkt
bei gegebenem Funktionsumfang.
Die Hardware soll bei gegebenem Funktionsumfang eines Produktes möglichst
sparsam benutzt werden (hohe Ablaufgeschwindigkeit, geringer Speicherbedarf).
Effizienz war lange Zeit aufgrund hoher Hardwarekosten das beherrschende
Qualitätsmerkmal, verliert aber bei ständig sinkenden Hardwarepreisen immer
mehr an Bedeutung. Heute spielt Effizienz z. B. bei Realzeitsystemen eine große
Rolle.
Zuverlässigkeit: (siehe [So 01])
Man kann Zuverlässigkeit von Software durch eine Funktion R(t) beschreiben. Sei
fw(t) die Wahrscheinlichkeit, dass im Zeitraum von 0 – t ein Fehler auftritt, so gilt:
R(t) = 1 – fw(t) (Zuverlässigkeitsfunktion)
Geht R(t) auch für große t gegen 1, dann nennt man ein Softwareprodukt zuverlässig.
Falls R(t) bereits für kleine t nahe bei 0 liegt, ist das Produkt unzuverlässig.
Robustheit:
Robustheit ist der Grad, in dem ein Produkt eine vernünftige Reaktion bei nicht
vorgesehener Verwendung erbringt und seine Funktionsfähigkeit bewahrt. Man
setzt voraus, dass Hardware- und Eingabefehler vorkommen können und verlangt,
dass dadurch keine Katastrophe geschehen soll.
Benutzbarkeit:
Benutzbarkeit (auch Benutzungskomfort oder Benutzerfreundlichkeit) umfasst alle
Software-Eigenschaften, die dem Anwender ein einfaches, angenehmes, effizientes
und fehlerarmes Arbeiten mit dem Software-Produkt gestatten. Dabei sind auch
viele ergonomische Kriterien zu berücksichtigen wie: Lernaufwand, Installationsaufwand,
einfache und einheitliche Benutzeroberfläche, Robustheit usw. (
Benutzerschnittstelle, Software Ergonomie.
Fehlertoleranz:

Das System muss im Falle eines erkannten Fehlers den Benutzer situationsgerecht
informieren. Das System muss immer bedienbar bleiben, d. h. alle auftretenden
Fehlerbedingungen müssen abgefangen werden.
Sicherheit:
unter dem Begriff sind alle System-Eigenschaften zusammengefasst:
• die verhindern, dass ein technisches System in einen gefährlichen Zustand gerät,
• die verhindern, dass Software-Systeme unbefugt benutzt werden,
• die verhindern, dass Daten oder Programme unbeabsichtigt oder mutwillig zerstört
oder verfälscht werden,
• und die dafür sorgen, dass eine ordnungsgemäße und revisionsfähige Verarbeitung
im Sinne geltender Normen und Gesetze sichergestellt wird.
Erweiterbarkeit:
Wie einfach ist es auch noch nach Fertigstellung den Leistungsumfang des Software-Produktes
durch Einbau zusätzlicher Funktionen zu verändern und dabei
einer speziellen Anwendungssituation anzupassen.
Änderbarkeit:
Grad, in dem ein Produkt die Veränderung (Anpassung) seiner Eigenschaften
durch den Benutzer zulässt. Die Änderung erfolgt über definierte Schnittstellen,
nicht durch Veränderung des Quellcodes.
Wartbarkeit:
Die Wartbarkeit eines Systems wird nach der Zeitdauer beurteilt, die im
produktiven Einsatz nach Auftreten und Meldung eines Fehlers erforderlich ist,
um diesen zu lokalisieren und zu beheben. Diese Qualitätseigenschaft wird
beeinflusst von der Änderbarkeit, Verständlichkeit und Testbarkeit.
Verständlichkeit:
Bezieht sich auf die Lesbarkeit des Codes, den Aufbau des Systems, seine Architektur,
die Modularisierung der Komponenten. Je übersichtlicher ein System gegliedert
(verfeinert) ist um so größer ist seine Verständlichkeit
Testbarkeit
Je übersichtlicher und verständlicher ein System gegliedert ist, umso einfacher ist
es zu testen. Korrektur von Fehlern in der Wartung beseitigen Fehler, sie können
aber neue Fehler in das System einschleusen. Testbarkeit bezeichnet den Aufwand,
der zum Testen einer Anwendung nötig ist.
Übertragbarkeit:
17

18
ein System ist portabel, wenn es leicht in neue oder andere Hardware- und
Software-Umgebung überführt werden kann.
Wiederverwendbarkeit:
ist die Verwendung von bereits entwickelten Software-Komponenten in anderen
Umgebungen, für die sie ursprünglich nicht geplant waren. Wiederverwendbarkeit
ist nicht nachträglich zu erreichen. Ein System muss so konzipiert werden, dass die
entwickelten Komponenten wiederverwendbar sind.
Abhängigkeiten zwischen Qualitätseigenschaften
Die Qualitätseigenschaften sind nicht unabhängig voneinander. Werden Maßnahmen
zur Verbesserung einer Qualitätseigenschaft getroffen, so wirken sich
diese möglicherweise auf andere Eigenschaften aus. Wird die Effizienz eines Systems
verbessert, so kann dies ein unzuverlässigeres System bewirken; die Robustheit
kann sinken, das System kann schwerer änderbar sein (weil z. B. die
Effizienzsteigerung durch Assemblerprogramme erreicht wurde). Hardwarenahe
Programmiersprachen wirken sich natürlich auch auf die Wartbarkeit und
Übertragbarkeit aus.
Maße für Qualität
Wie oben beschrieben, muss schon bei der Spezifikation die Qualität der zu erstellenden
Software definiert werden, so dass nach der Fertigstellung nachgeprüft
werden kann, ob die Software den Qualitätsanforderungen genügt. Zum Beispiel
kann die Qualitätseigenschaft Funktionserfüllung geprüft werden, indem getestet
wird, ob die Software so funktioniert wie vereinbart, d.h. ob die Software das tut,
was in der vom Auftraggeber abgezeichneten Spezifikation steht. Die Effizienz
kann durch Angabe von maximalen Antwortzeiten spezifiziert werden, die Zuverlässigkeit
durch einen Wert für R(t). Andere Maße, wie die z. B. Erweiterbarkeit
oder Wartbarkeit sind schwieriger zu definieren, wir werden im Kapitel 7
Softwaremetriken näher auf mögliche Maße eingehen.

1.6 Phasen der Softwareentwicklung
Um qualitativ hochwertige Software zu produzieren muss das Produkt modular
aufgebaut werden. Zusätzlich ist es nötig auch den Produktionsprozess nach
Prinzipien zu strukturieren, die auch in anderen Ingenieursdisziplinen üblich sind.
Man spricht in diesem Zusammenhang von ingenieurmäßigem Vorgehen bei der
Softwareentwicklung. Ein Softwareprojekt muss, wie jeder andere industrielle
Fertigungsprozess auch, in mehrere Phasen eingeteilt werden. Frick beschreibt in
[Frick95] die Merkmale eines industriellen Fertigungsprozesses:
1. Der Prozess läuft in Phasen ab.
2. Jede Phase liefert Ergebnisse, die die Grundlage für die Folgephase darstellen.
3. Es findet eine Überprüfung der Phasenergebnisse statt, bevor die Folgephase
anläuft (wobei es notwendig werden kann, die gleiche Phase noch einmal
durchzuführen).
4. In jeder Phase entsteht eine abstrakte Darstellung des Produktes, je fortgeschrittener
die Phase, desto konkreter wird die Darstellung.
Diese allgemeinen Anforderungen an einen Fertigungsprozess gelten auch für die
Softwareerstellung. Durch den Einsatz von Phasenmodellen wird ein Softwareprojekt
zeitlich strukturiert. Es wird festgelegt:
• welche Arbeiten in den einzelnen Phasen zu erledigen sind,
• welche Arbeitsergebnisse in den Phasen erzeugt werden müssen,
• welche Personen die Ergebnisse zu erarbeiten haben,
• wie die Ergebnisse dokumentiert werden sollen,
• welche Termine eingehalten werden müssen,
• einzuhaltende Standards und Richtlinien.
Phasenmodelle regeln auch die Zusammenarbeit zwischen den am Softwareerstellungsprozess
beteiligten Rollen und Personen.[Kimm79].
Es existieren verschiedene Phasenmodelle für die Softwareentwicklung.
Das "Ur-Modell" ist das so genannte Wasserfallmodell, das ein rein sequentielles
Durchlaufen der Phasen vorsah. Die Arbeiten einer Phase mussten abgeschlossen
sein, bevor die Folgephase beginnen konnte. Dieses Vorgehen erwies sich in der
19

20
Praxis als undurchführbar. Es wurde so erweitert, dass Rücksprünge in zeitlich
früher liegende Phasen möglich wurden. Am Ende jeder Phase werden die Ergebnisse
überprüft und an die Folgephase weitergegeben. Wird dort während der Erarbeitung
der eigenen Phasenergebnisse, ein Fehler in den Vorgaben festgestellt, so
werden die Vorgaben an die vorhergehende Phase zurückgeführt.
In den letzten Jahren hat sich eine Vielzahl von weiteren Prozessmodellen herausgebildet,
die dieses Modell variieren, z. B. durch ein mehrmaliges Durchlaufen
der Phasen des Wasserfallmodells in mehreren Zyklen, wobei am Ende jedes Zyklus
eine weitere Ausbaustufe des Systems entsteht. Prototyping-Ansätze wurden
in das Wasserfallmodell integriert.
Ob wir nun in mehreren Zyklen entwickeln, d. h. erst ein Basissystem und in den
Folgezyklen dieses Basissystem immer wieder durch weitere Teilsysteme ergänzen
oder ob wir das Gesamtsystem als ganzes entwickeln, wir durchlaufen während des
Softwareentwicklungsprozesses immer verschiedene aufeinander aufbauende
Phasen:
Implementierung und Test
Diese zentrale Phase des Softwareentwickungsprozesses kennen wir schon aus der
Lehrveranstaltung Programmieren. (Zumindest kleine Programme wurden von Ihnen
bereits implementiert und getestet.)
Bei großen Systemen können wir das System nicht als Ganzes implementieren und
testen, sondern wir implementieren und testen zuerst die einzelnen Komponenten
(Komponententest). Anschließend werden diese ausgetesteten Komponenten
schrittweise zusammenmontiert und ausgetestet (Integrationstest).
Vor Beginn der eigentlichen Codierung ist die Implementierungsstrategie festzulegen.
Es wird entschieden, in welcher Reihenfolge die Komponenten implementiert
und zusammengebaut werden (Top-Down- oder Bottom-Up-Vorgehensweise).
Die einzusetzenden Bibliotheken sind festzulegen. Detaillierte Testpläne
für die einzelnen Komponenten, für die Teilsysteme und das Gesamtsystem sind,
falls nicht schon in vorhergehenden Phasen geschehen, zu erstellen.
Abnahme
Auch diese Phase kennen wir vom Programmierpraktikum.
In dieser Phase wird geprüft, ob die Leistungen des Systems mit den in der Spezifikation
vereinbarten Leistungen übereinstimmen (im Programmierpraktikum: mit

den in der Aufgabenstellung geforderten Leistungen). Ist ein externer Auftraggeber
vorhanden, überprüft dieser oft die Systemfunktionen mit einem eigenen Prüfkatalog.
Im Programmierpraktikum bekamen Sie dann Ihre Abnahme und der Sinn der Implementierung
war erfüllt. Sie sind wieder einen Schritt in Ihrem Studium
vorangekommen.
Bei der kommerziellen Softwareentwicklung soll die Software nach der Implementierung
natürlich auch zum Einsatz kommen. Es kommt eine weitere Phase,
der eigentliche Einsatz, d. h. der Betrieb des Systems.
Betrieb
Bezogen auf die Lebensdauer eines Softwareproduktes ist die Betriebsphase eines
Produktes die längste aller Phasen. Das erstellte Produkt wird in dieser Phase
benutzt. Hier fallen mit ca. 80% der weitaus größte Teil der Kosten aller Phasen der
Softwareentwicklung an, d. h. der Aufwand für die Erstellung übersichtlich
entworfene und gut ausgetesteter Programme mit guter Dokumentation rentiert sich
an dieser Stelle auf jeden Fall.
Während des Betriebs eines Softwareproduktes werden zusätzliche Fehler und Unzulänglichkeiten
am Produkt entdeckt. Diese werden dem Hersteller zur Korrektur
gemeldet und verursachen Rücksprünge in zeitlich frühere Phasen.
Während der Betriebszeit eines Softwareproduktes ändert sich der Einsatzzweck
eines Produktes; die betrieblichen Abläufe, die von der Software unterstützt
werden, ändern sich und die Software muss entsprechend angepasst oder verändert
werden. Diese Aktivitäten werden häufig auch den Wartungsaktivitäten zugeordnet,
bezeichnen aber eigentlich Arbeiten zur Weiterentwicklung der Software.
Weitere Phasen bei der Softwareentwicklung
Im Praktikum Programmieren wurde immer eine Aufgabe gestellt, d. h. die Definition
war vorgegeben. Sie als Studierender mussten sich jetzt noch, falls nicht auch
in der Aufgabenstellung vorgegeben, einige Gedanken über den Aufbau des
Systems machen, und los ging es mit der Implementierung. Statt z. B. die
Klassenstruktur inkl. der Beziehungen zwischen den Klassen graphisch darzustellen,
konnten Sie, wegen der Übersichtlichkeit Ihrer kleinen Softwaresysteme,
die Klassenstruktur meistens direkt als Header-File in C++ hinschreiben.
Bei der Entwicklung von großen Systemen wird vor der eigentlichen Implementierung
des Systems erst einmal eine Analyse durchgeführt, um zu wissen, ob
und in welchem Umfang ein System erstellt werden sollte und ob eine Erstellung
unter Kostengesichtspunkten ratsam und mit den Möglichkeiten der Firma
21

22
überhaupt möglich ist. Gemeinsam mit dem späteren Benutzer des Systems muss
dann in einer Definitionsphase der Funktionsumfang genau spezifiziert und
anschließend von der IT-Abteilung die IT-Lösung entworfen werden:
Analyse
In der Analysephase muss der Systemanalytiker zuerst das Anwendungsgebiet
verstehen. Er muss begreifen was der Kunde will. Die Schwachstellen werden
analysiert, Verbesserungsvorschläge werden geprüft und die zusätzlichen Wünsche
an das System aufgenommen. Daraus wird abgeleitet was die Software aus
fachlicher Sicht leisten soll. Die fachlichen Anforderungen an die Software werden
dokumentiert und mit dem Benutzer abgestimmt. Es wird analysiert ob die
Aufgabe durchführbar (lösbar) und finanzierbar ist und ob das notwendige Personal
vorhanden ist. Es wird eine erste Kostenkalkulation vorgenommen.
Fehler in der Analysephase sind sehr teuer, wirken sie sich doch auf alle folgenden
Phasen aus. Die Dokumentation der Analyseergebnisse bilden die Kommunikationsgrundlage
zwischen IT-Abteilung und Fachabteilung und müssen deshalb implementierungsunabhängig
sein.
Definition
In dieser Phase werden die informellen Anforderungen der Analyse in eine vollständige,
konsistente Spezifikation umgesetzt. Die Produktdefinition beschreibt
wie das Produkt aus Benutzersicht funktionieren soll. Sie soll normalerweise implementierungsunabhängig
formuliert sein. Die geforderten Qualitätseigenschaften
werden in der Definitionsphase festgelegt. Der Abnahmetest wird mit dem
Benutzer festgelegt.
Entwurf
Im Entwurf wird die IT-Lösung für das in den vorhergehenden Phasen spezifizierte
Softwareprodukt entworfen. Es wird entschieden welche Hardware und welches
Betriebssystem nötig sind. Die Programmiersprache wird gewählt.
Benutzerschnittstelle, Datenbank und notwendige Systemschnittstellen zu Fremdsystemen
werden festgelegt. Hier wird die Komponentenarchitektur definiert, d. h.
das System wird in Komponenten (Klassen, Funktionen) zerlegt, die in
Komponentenarchitekturdiagrammen (Klassendiagramm, Sequenzdiagramm)
dargestellt werden. Das gewählte Softwareentwicklungsparadigma bestimmt die
Methoden, die dafür eingesetzt werden. Komponententestpläne werden entworfen.
In dem Entwurf wird festgelegt wie das System aufzubauen ist, damit es die in der
Definition festgelegte Leistung erbringen kann.

Ergebnisse der Phasen, Reviews
Als Ergebnis jeder Phase entstehen Dokumente, die als Grundlage für das Weiterarbeiten
in der Folgephase dienen. Diese Ergebnisse (und evtl. auch innerhalb der
Phasen an so genannten Meilensteinen anfallende Zwischenergebnisse) werden in
so genannten Reviews geprüft und mit den Erstellern diskutiert. Dieser Schritt ist
sehr wichtig, da Fehler in frühen Phasen der Softwareentwicklung in späteren Phasen
nur mit sehr hohen Kosten behoben werden können. (Z. B. Fehler oder missverständliche
Formulierungen in der Spezifikation werden erst zum Zeitpunkt der
Abnahme festgestellt => alle Phasen müssen nochmals durchlaufen werden, man
muss sich in den Aufbau des Programms hineindenken und Änderungen im Code
sind vorzunehmen. Ein nicht zu unterschätzender Faktor ist der Test
(Komponenten- und Integrationstest des gesamten Systems) und das Anpassen der
Dokumentation.
Eine ausführliche Betrachtung von Phasenmodellen ist in einem gesonderten Kapitel
weiter hinten im Skript durchgeführt.
1.7 Überblick über den Aufbau des SWT-Skriptes
In Kapitel 2 werden die Grundbegriffe der Objektorientierung wiederholt. Die
Prinzipien der Objektorientierung und die objektorientierten Programmiersprachen
werden zusammengefasst.
Kapitel 3 gibt einen Überblick über die Modellierungssprache UML - Unified –
Modeling Language. Alle Diagrammtypen der UML werden erläutert. Die
wichtigsten Notationselemente werden beschrieben. Die Diagrammtypen der UML
werden an einem durchgängigen Beispiel demonstriert.
Kapitel 4 fasst die aktuellen Vorgehens- und Prozessmodelle zusammen. Das
historische Wasserfallmodell beschreibt die Phasen eines Softwareprojektes und
die Zusammenhänge zwischen den Phasen. Das V-Model ist aus dem
Wasserfallmodell hervorgegangen und beschreibt als Standardmodell von
Bundesbehörden das Vorgehen einer großen Organisation. RUP und extreme
Programming stellen aktuelle Entwicklungen im Bereich der Vorgehensmodelle
dar.
Die prototypische Entwicklung wird erläutert.
Im Abschnitt CMM/ISO 9000, SPICE liegt der Fokus auf der Bewertung der
Qualität von Entwicklungsprozessen.
23

24
Der 2. Teil des Skriptes wird zum WS 04/05 erscheinen und folgenden Inhalt
umfassen:
• Requirements Engineering
• Software Architektur und Patterns
• Qualitätsmanagement
• Testmanagement
• Konfigurationsmanagement
• vollständige Darstellung der UML
• Petrinetze und Entscheidungstabellen.

2 Objektorientierung
2.1 Einführung
Objektorientierte Programmierung (kurz OOP) ist seit den 90er Jahren das zentrale
Programmiersprachenparadigma für viele Arten von Softwaresystemen. Ziel der
Einführung der Objektorientierung war die Erstellung von robusteren,
fehlerärmeren und besser wartbaren Programmen.
Das fundamentale Konstrukt der Objektorientierung ist das Objekt, das sowohl
Daten (die Attributen als Eigenschaften des Objekts) als auch das Verhalten (die
Logik des Objekts) vereinigt. Damit wird es möglich, Software aus einer
Sammlung von konkreten Objekten zu erstellen. Jedes Objekt ist hierbei eindeutig
über einen sog. Handle (Referenz) identifizierbar. Je nach Programmierumgebung
kann ein Handle beispielsweise als eine Adresse zu einem Speicherbereich
realisiert sein. Objekte können durch Kenntnis des Handle mit anderen Objekten
kommunizieren. Man spricht in diesem Zusammenhang von einem
Nachrichtenaustausch zwischen Objekten. Aufgrund einer eingehenden Nachricht
führt das Objekt eine bestimmte Operation aus. Eine Operation wird durch Aufruf
einer Methode des Objekts realisiert. Eine Methode repräsentiert somit das
Verhalten eines Objektes. Oft wird sprachlich nicht zwischen einer Methode und
einer Operation unterschieden und beide Begriffe synonym verwendet.
Als Beispiel werden nachfolgend Polygon-Objekte betrachtet (siehe Abbildung 2-
1).
Attribute
- Kante
- Kantenfarbe
- Füllmuster
Operationen
- zeichnen
- löschen
- verschieben
Abb. 2-1: Beispiel "Polygon-Objekte"
25

26
Ein konkretes Polygon-Objekt ist beispielsweise das Viereck. Dieses wird durch 4
Kanten beschrieben, die Kantenfarbe und das Füllmuster. Polygon-Objekte können
in diesem Beispiel auf drei Nachrichten reagieren: zeichen, löschen und
verschieben.
Im nächsten Abschnitt werden die Grundideen der objektorientierten
Programmierung erläutert.
2.2 Prinzipien der Objektorientierung
2.2.1 Abstraktion
Eine der wichtigsten Ideen der objektorientierten Programmierung ist die Trennung
zwischen Konzept und Umsetzung. Hierzu wurden die Begriffe Klasse und Objekt
eingeführt.
Ein Objekt ist eine tatsächlich existierende Repräsentation einer "Sache" aus dem
zu entwickelnden Anwendungssystem. Beispiele für Objekte sind das
Personenobjekt "Schmidt", das Autoobjekt "VW-Käfer" oder das Druckerobjekt
"Laserdrucker1". Objekte müssen instantiiert werden, damit die Eigenschaften und
das Verhalten der Objekte in einem Programm genutzt werden können. Anstelle
von Objekten spricht man auch gerne von den "Instanzen einer Klasse". In diesem
Skript werden diese Begriffe synonym verwendet.
Eine Klasse ist die Beschreibung eines oder mehrerer ähnlicher Objekte, d.h.
Objekte des gleichen Typs. Objekte einer Klasse müssen sich nicht in allen Details
gleichen, aber in vielen Eigenschaften übereinstimmen. Beispiel einer Klasse ist
"Auto", das die Beschreibung aller Automarken von verschiedensten Hersteller
repräsentieren kann. Die Attribute und Methoden der Klasse "Auto" müssen so
gewählt sein, dass hiermit die unterschiedlichsten Ausprägungen gemäß den
Projekt-Anforderungen umfassend beschrieben werden können.
Die Unterscheidung zwischen Klasse und Objekt kann als Abstraktion angesehen
werden. Hiermit wird es möglich, Details einer Problemstellung zu ignorieren und
somit die Komplexität des Problems zu reduzieren. Es findet somit eine Abbildung
der realen Welt in eine abstrakte logische Ebene (bestehend aus Klassen und
Objekten) statt.
2.2.2 Kapselung
Eine Klasse fasst eine Menge von Daten und darauf operierender Funktionen (die
sog. Methoden) zusammen. Die Daten werden durch einen Satz von Variablen
repräsentiert. Diese werden als Attribute oder Instanzvariablen bezeichnet. Für die
Klasse Auto könnten diese z. B. die Attribute Baujahr, Jahr der Erstzulassung,

Hubraum, Kennzeichen usw. sein. Für jedes Objekt wird ein eigenständiger Satz an
Attributen angelegt.
Die Funktionen werden in der Objektorientierung als Operationen bzw. als
Methoden bezeichnet. Diese repräsentieren das Verhalten der Objekte. Die
Methoden enthalten ausführbaren Programmcode und stellen die Schnittstelle zur
Kommunikation mit anderen Objekten (einer anderen Klasse) dar. Das Verhalten
eines Objektes ist festgelegt durch die aktuellen Attributwerte (der sog.
Objektzustand) und dem Programmcode der jeweiligen Methoden.
Da in der Objektorientierung Attribute und Methoden in einem Objekt
zusammengefasst sind, bezeichnet man dies als Kapselung. Ein objektorientiertes
System besteht somit aus einer Mengen von gekapselten Objekten (s. Abb. 2-2).
m1()
x1()
2.2.3 Wiederverwendung
Abb. 2-1Objekte eines objektorientierten Systems
Durch Anwendung der Prinzipien der Abstraktion und Kapselung kann die
Wiederverwendung von Programmteilen gefördert werden. Dies kann somit zur
Erhöhung der Fehlerfreiheit und Effizienz beim Programmieren führen. Ein
Beispiel sind die sog. Collections als Objekte, die eine Sammlung von Objekten
anderen Typs verarbeiten können. Diese Collections ermöglichen sehr effizient
typische Aufgaben wie beispielsweise das Durchsuchen, Sortieren oder Kopieren
a1()
27

28
von Elementen. Hierzu stellen die Collection-Klassen unterschiedliche Methoden
als Schnittstelle (Collection-API) zur Verfügung.
Allerdings gibt es auch Grenzen ….
2.2.4 Beziehungen
Meistens existieren Objekte nicht isoliert sondern stehen in Beziehungen zu
anderen Objekten. Hierbei werden unterschiedliche Beziehungsarten unterschieden.
So kann zwischen Objekten beispielsweise eine "Teil-von"-Beziehung bestehen.
Dies beschreibt eine Zusammensetzung eines Objektes aus anderen Objekten. So
könnte beispielsweise ein Lampen-Objekt aus den Objekten für Birne, Fassung,
Kabel und Widerstand bestehen.
Eine andere zentrale Beziehung der Objektorientierung ist die Spezialisierung (istein-Beziehung).
Diese wird in objektorientierten Programmiersprachen durch
Vererbung ausgedrückt. Beispielsweise könnte ein Transportmittel als Schiff, Zug,
Flugzeug und Strassenfahrzeug spezialisiert werden. Die Aussage ist, dass ein
Schiff ein (spezielles) Transportmittel ist, aber auch ein Zug, ein Flugzeug oder ein
Strassenfahrzeug. Diese Beziehung kann auch umgekehrt betrachtet werden. In
diesem Falle spricht man von Generalisierung (Verallgemeinerung). Vererbungen
können auch mehrstufig sein. So könnte beispielsweise ein Strassenfahrzeug
weitere unterteilt werden in Auto, Zweirad und Lastkraftwagen. Auf diese Weise
entstehen sog. Vererbunghierarchien, die in einer Baumstruktur (Ableitungsbaum)
dargestellt werden. Die Modellierung von Vererbungshierarchien kann auch dazu
eingesetzt, gegliederte Begriffstrukturen (sog. Taxonomien) für einen
Anwendungsbereich zu definieren.
Im Kapitel 3 werden im Rahmen der Betrachtung der UML (Unified Modelling
Language) die unterschiedlichen Beziehungstypen erläutert.
2.2.5 Polymorphismus
Ein anderes wichtiges Konzept von objektorientierten Programmiersprachen ist die
des Polymorphismus (Vielgestaltigkeit). Hierunter versteht man die Fähigkeit von
Objektvariablen, Objekte unterschiedlicher Klassen und daraus abgeleiteten
Klassen aufzunehmen. Aufgrund der definierten Vererbunghierarchien wird
sichergestellt, dass nur Eigenschaften berücksichtigt werden, die auf allen Ebenen
der Hierarchie definiert sind.
Mit Polymorphismus wird es möglich, gleiche Methoden von unterschiedlichen
Objekten der Hierrachie aufzurufen. Hierbei wird das Konzept des "Late Binding"
vom "Early Bindung" unterschieden. Letzteres bedeutet, dass zur Compile-Zeit der
Methodenaufruf bestimmt ist. "Late Binding" bedeutet, dass erst zur Laufzeit die
Festlegung getroffen wird welche Methode aufgerufen wird. Der Vorteil dieses
Konzeptes liegt darin, dass der Programmieraufwand für typbasierte

Fallunterscheidungen verringert werden können. Allerdings sollte hiermit
vorsichtig umgegangen werden, da sich hiermit unter Umständen die
Verständlichkeit und Wartbarkeit eines Programms deutlich verschlechtern kann.
2.3 Überblick Objektorientierte Programmiersprachen
Objektorientierte Programmierkonzepte können sehr weit rückverfolgt werden. Die
erste objektorientierte Programmiersprache war Simula 67, die bereits 1967 alle
wesentlichen Elemente einer objektorientierten Sprache enthielt. In den 70er und
80er Jahren des letzten Jahrhunderts dominierten prozedurale
Programmiersprachen wie beispielsweise Fortran, Pascal, C und COBOL. In der
Folge wurden viele etablierte Programmiersprachen um objektorientierte
Sprachmittel erweitert oder neue Programmiersprachen definiert. In den 90er
Jahren erlangten C++ (zunächst als Erweiterung der Sprache C), Smalltalk und
Java eine hohe Aufmerksamkeit. In jüngster Zeit gewinnt C# durch die
Marketingoffensive von Microsoft an Bedeutung. Während Java und C++ sich
mittlerweile bei der Anwendungsentwicklung bewährt haben, muss C# sich als
echte Alternative erst noch beweisen. In den nächsten Abschnitten werden die
wesentlichen Eigenschaften von C++, JAVA und C# kurz beschrieben.
2.3.1 C++
Anfang der 80er Jahre entstand als objektorientierte Erweiterung von C die
Programmiersprache C++. Ein zentrales Ziel von Bjarne Stroustrup, dem Erfinder
der Sprache, war die Nutzung objektorientierter Konzepte unter Beibehaltung der
prozeduralen Bestandteile von C. Somit zählt C++ zu den sogenannten
Hybridsprachen, da verschiedene Programmiersprachenparadigmen unterstützt
werden. C++ erfuhr schnell eine weite Verbreitung und wurde in vielen Projekten
auch aufgrund vorhandener Entwicklungswerkzeuge gerne genutzt. Schon früh
wurden umfangreiche Klassenbibliotheken entwickelt, die Lösungen für bestimmte
Fragestellungen anboten. Beispielsweise entwickelte Microsoft die MFC
(Microsoft Foundation Class) zur Unterstützung der Entwicklung von Windows-
Programmen. Auch eine Standard-C++-Bibliotek, die STL (Standard Template
Library), zur Bearbeitung von Objektsammlungen steht Anwendungsentwickler
zur Verfügung. Des Weiteren existiert eine Reihe von Spezialklassenbibliotheken
wie z. B. IlogViews zur Entwicklung von anspruchsvollen grafischen Oberflächen.
C++ wird auch heute noch immer dann eingesetzt, wenn die Performance der
Applikation eine Rolle spielt. Einer der Gründe dafür ist, dass man mit C++ sehr
effizient die Nutzung des Speicherplatzes und die Programmabarbeitung
beeinflussen kann. Im Rahmen der Programmiervorlesungen im Bachelor-
29

30
Studiengang wird an der FH Darmstadt C++ als objektorientierte Basis-
Programmiersprache gelehrt.
2.3.2 JAVA
Java wurde 1995 (als Nachfolger der Sprache Oak von James Gosling) von der
Firma Sun Microsystems entwickelt. Ursprünglich wurde die Programmiersprache
für die Gerätesteuerung ("Comsumer devices") entwickelt, fand aber schnell
weitere Anwendungsgebiete. Java ist eine plattformunabhängige, objektorientierte
Programmiersprache, die es unter anderem ermöglicht, interaktive Web-Seiten zu
entwickeln. Mit Java programmierte Applikationen (Applets), die per HTML in
Web-Seiten integriert werden, werden beim Öffnen der Seite übers Internet
automatisch gestartet und ausgeführt.
Java ist in weiten Teilen nicht nur mit C++ vergleichbar, sondern sogar identisch.
Allerdings wurden bei der Entwicklung von Java einige Sprachbestandteile von
C++ anders umgesetzt oder konsequent eliminiert. So existieren beispielsweise
keine fehlerträchtigen Pointeroperationen wie in C++. Des Weiteren sorgt ein
"Garbage Collector" für eine effiziente Speicherverwaltung und gibt nicht mehr
benötigten Speicher automatisch wieder frei.
Inzwischen werden auch "Mission critical" Systeme mit Java entwickelt. Hierbei
kann auf eine große Java-Bibliothek zurückgegriffen werden. Die Sprache Java
basiert auf einer umfangreichen Klassenbibliothek, die von Hause aus eine Menge
an Basisfunktionalitäten zur Verfügung stellt. In diesem Bereich ist Java der
Programmiersprache C++ klar überlegen. Ein gravierender Nachteil von Java ist
die im Vergleich zu C++ geringere Performance. Da Java zunächst in einen
plattformunabhängigen Byte-Code übersetzt wird, muss dieser anschliessend von
einem virtuellen Java-Prozessor (der Java Virtual Machine) ausgeführt werden.
Durch diesen Interprationsvorgang geht wertvolle CPU-Zeit verloren. Durch
Einführung der J2EE (Java 2 Enterprise Edition) und der Verfügbarkeit von sog.
Applikations-Servern können mit Java auch mehrschichtige Architekturen
entwickelt werden. Schliesslich unterstützt Java damit auch die
komponentenorientierte Softwareentwicklung und stelle somit eine state-of-the-art
Programmiersprache dar.
2.3.3 C#
C# ist eine relativ neue objektorientierte Programmiersprache, die von der Firma
Microsoft im Jahre 2001? veröffentlicht wurde. C# ist mit dem Anspruch
entwickelt worden, einige Nachteile von C++ und Java zu beseitigen. Dennoch ist
die Ähnlichkeit sehr hoch und die Frage stellt sich, ob C# sich am Markt
durchsetzen wird und Java bzw. C++ längerfristig verdrängen kann.

C#-Programme werden in der .NET-Laufzeitumgebung ausgeführt. Das .NET-
Framework stellt hierzu viele Funktionen zur Verfügung. Dies bedeutet, dass viele
Vorgänge im Gegensatz zu C++ nicht der Steuerung des Programmierers
unterliegen. Quellen werden in Assemblierungen kompiliert, die sowohl den
kompilierten Code (ausgedrückt in der .NET-Zwischensprache IL) als auch
Metadaten zur Beschreibung des kompilierten Codes enthalten. Der IL-Code
(Intermediate Language) wird dann in der CLR (Common Language Runtime)
ausgeführt. Nachfolgend werden einige weitere Unterschiede zu C++ bzw. Java
genannt.
Im Gegensatz zu C++ werden bei C# keine Header-Dateien verwendet. Um eine
schnellere Analyse des C#-Codes zu erzielen, werden keine Makros unterstützt.
Auch auf Vorwärtsdeklarationen wurde verzichtet, da die Reihenfolge der Klassen
in den Quelldateien nicht von Bedeutung ist. Das Löschen von Objekten erfolgt in
C#-Programmen über die Speicherbereinigung und wird ausgeführt, wenn das
Objekt nicht länger benötigt wird. Destruktoren (= Finalisierungsroutinen) können
zur Durchführung von Bereinigungsaufgaben eingesetzt werden, dies jedoch nicht
im gleichen Umfang wie bei C++-Destruktoren.
Wegen der architekturellen und strukturellen Ähnlichkeiten von .NET und der
Java-2-Technik bieten beide Sprachen einen vergleichbaren Umfang. Teilweise
sind sich die Sprachen derart ähnlich, dass man schon ein zweites Mal auf den
Programmcode schauen muss, um die Sprachen unterscheiden zu können. Ein
wesentlicher Nachteil von C# ist, dass die entwickelten Programme nur auf den
Microsoft-Plattformen ablauffähig sind.
2.4 Werkzeuge für die objektorientierte Entwicklung
Um objektorientierte Softwaresysteme zu entwickeln, ist der Einsatz einer Reihe
von leistungsfähigen Entwicklungswerkzeugen notwendig. Dies reicht
beispielsweise von mächtigen Programmeditoren mit LSE-Fähigkeit (Language
Sensitive Editing) sowie Assistenten und Wizards, komfortablen Debuggern und
Analyse-Werkzeugen aber auch modernen Modellierungswerkzeugen. In den
letzten Jahren sind viele leistungsfähige IDEs (Integrated Development
Environments) entstanden, die viele Funktionen "unter einem Dach" dem
Entwickler anbieten und oft auch durch Add-Ins (oder Plug-Ins) erweiterbar sind.
Interessante Werkzeuge sind beispielsweise Visual Studio .NET von Microsoft und
Eclipse der Apache Software Foundation (http://www.apache.org/).
Schon sehr früh sind Modellierungswerkzeuge entstanden, die die Objektorientierte
Analyse (OOA) und das Objektorientierte Design (OOD) unterstützen. Aufgrund
des Bemühens, große Informationssysteme ingenieurmäßig (d.h. systematisch) und
rechnergestützt zu entwickeln, entstanden leistungsfähige CASE-Werkzeuge
31

32
(Computer Aided Software Engineering). Ein CASE-System ist eine integrierte
Software-Entwicklungsumgebung, die idealerweise den gesamten
Softwarelebenszyklus unterstützt. Anfangs nutzten diese CASE-Werkzeuge
unterschiedlichste Notationssprachen. Seit der weiten Verbreitung der UML
(Unified Modelling Language) unterstützen alle CASE-Tools zumindest diese
grafische Modellierungssprache. Durch die Integration von Methoden und
Verfahren sowie deren Automatisierung soll ein rechnergestütztes System zur
Unterstützung sämtlicher Phasen und Aktivitäten des Systemlebenszyklusses zur
Verfügung gestellt werden.
Alle marktrelevanten Tools unterstützen den Implementierungs-Prozess durch die
Generierung von Programmfrakmenten in unterschiedlichen Zielsprachen aus den
entwickelten UML-Modellen. Des weiteren sind moderne CASE-Werkzeuge in der
Lage, den weiter entwickelten Code zu analysieren und das UML-Modell durch
Reverse Engineering entsprechend anzupassen. Wird dieser Kreislauf im Rahmen
eines Projektes mehrfach und systematisch genutzt, spricht man von Round-Trip
Engineering.
Im Rahmen des Softwaretechnik-Praktikums wird das CASE-Werkzeug Innovator
der Firma MID eingesetzt. Weitere bekannte objektorientierte
Modellierungswerkzeuge sind beispielsweise Rational Rose (IBM Rational),
TogetherJ (Togethersoft), ObjectiF (MicroTool GmbH), Rhapsody (I-Logix) und
ArgoUML (OpenSource).
2.5 Weiterführende Literatur
[Graham95] Graham, Ian: Migrating To Object Technology, Addison-Wesley
Publishing Company, 1995.
[Meyer97] Meyer, Bertrand: Object-Oriented Software Construction, 2 nd
edition, Prentice Hall PTR, 1997.

3 UML Unified Modeling Language
3.1 Was ist die UML?
Die Unified Modeling Language ist eine Modellierungssprache, also eine Sprache
zur Beschreibung von Software-Systemen. Sie bietet eine einheitliche Notation, die
für alle Anwendungsgebiete nutzbar ist. Sie enthält Diagramme und natürlichsprachliche
Beschreibungsformen. Die UML kann zur statischen und dynamischen
Modellierung von Analyse, Design und Systemarchitektur eingesetzt werden. Sie
unterstützt objektorientierte Vorgehensweisen, ist aber auch zur Modellierung
nicht-objektorientierter Systeme geeignet.
Die UML 2.0 enthält gegenüber den Vorgängerversionen zahlreiche Neuerungen.
Diese Neuerungen wurden notwendig um die aktuellen Entwicklungen im Bereich
der Programmiersprachen (Java, C#) abzudecken und um technologische
Entwicklungen (Komponententechnologie, Application Server), die sich nach der
Definition der Versionen 1.x entwickelt haben, zu berücksichtigen. Der in den
letzten Jahren expandierende Mark der Embedded Systems (eingebettete Systeme)
lenkte den Fokus stärker auf die Elemente der UML, die die Modellierung von
Real-Time-Systemen unterstützen.
3.2 Entstehung der UML
Im Zeitraum Ende der achtziger bis Anfang der neunziger Jahre entstanden mehrere
Notationen zur Modellierung von OO-Systemen. Die Grundlage der Notationen
waren objektorientierte Programmiersprachen, wie Smalltalk und C++. Einige der
wichtigsten Notationen waren:
• Booch (Grady Booch)
• OMT (James Rumbaugh)
• OOSE (Ivar Jacobson)
• Shlaer/Mellor
• Coad/Yourdon
• u. a.
Seit 1994/1995 arbeiteten die "drei Amigos" Grady Booch, James Rumbaugh und
Ivar Jacobson in ihrer gemeinsamen Firma Rational Rose an einer Methode, die die
Vorteile der einzelnen Notationen vereinen und die ihre Nachteile eliminieren
sollte. Es entstand, in Zusammenarbeit mit vielen Firmen aus der Software-Industrie,
die Unified Method 0.8, die bis 1997 zur Unified Modeling Language 1.1
weiterentwickelt wurde. Die Notation der UML 1.1 war so umfangreich, dass der
33

34
Anspruch eine Methode zu definieren auf die Definition einer Modellierungssprache
reduziert wurde.
Die UML 1.1 wurde 1997 bei der Object Management Group (OMG) eingereicht
und wurde ein weltweiter Standard im Bereich der Objekt-Orientierten Entwicklung.
Die erste Version der UML wurde bis zur UML 1.5 weiterentwickelt.
Um die UML an neue Technologien wie Componentware, serverbasierte Technologien,
u. a. anzupassen, wurde die Struktur der UML 1.x gründlich überarbeitet.
Zur Zeit (SS 2004) liegt die UML 2.0 als Entwurf vor. Sie wird im 2. Halbjahr
2004 verabschiedet werden.
3.3 Diagramme der UML 2.0
Die UML 2.0 definiert die nachfolgenden Diagramme. In der UML 2.0 ist es
möglich Diagramme zu schachteln; man kann also eine Hierarchie von Diagrammen
erstellen, bei der Details eines Diagramms in einem weiteren Diagramm
"verfeinert" werden. Diagramme können über definierte Schnittstellen miteinander
verknüpft werden; ein Diagramm kann Verhalten, das in einem anderen Diagramm
modelliert ist über eine definierte Schnittstelle aufrufen. Es ist möglich
Diagrammvererbungen zu nutzen und Vererbungsbeziehungen zwischen Diagrammen
aufzubauen. Diagramme, die Verhalten modellieren, können mit Einund
Ausgabeparametern versehen werden. Programmierkonstrukte wie Schleifen
und Verzweigungen können dargestellt werden.
• Strukturdiagramme
• Klassendiagramm -Class Diagram
• Objektdiagramm - Object Diagram
• Komponentendiagramm - Component Diagram
• Paketdiagramm - Package Diagram
• Kompositionsstrukturdiagramm - Composite Structure Diagram
• Verteilungsdiagramm - Deployment Diagram
• Verhaltensdiagramme
• Aktivitätsdiagramm - Activity Diagram
• Anwendungsfalldiagramm - Use Case Diagram
• Zustandsdiagramm -State Machine Diagram
• Interaktionsdiagramme
• Interaktionsübersichsdiagramm - Interaction Overview Diagram
• Sequenzdiagramm - Sequence Diagram
• Kommunikationsdiagramm - Communication Diagram
• Zeitverlaufsdiagramm - Timing Diagram

Strukturdiagramme
werden in der UML verwendet um die statische Struktur (zeitunabhängige
Aspekte) von Systemen zu beschreiben. Sie können zur Beschreibung der interne
Struktur einzelner Klassen bis zur Definition der Architektur komplexer Systeme
verwendet werden. Die UML enthält die oben genannten Strukturdiagramme zur
Beschreibung struktureller Aspekte von Klassen, Objekten, Komponenten und Paketen.
Das Kompositionsstrukturdiagramm zeigt die interne Struktur eines
Elementes (Klasse, Komponenten, Use Case) und seine Interaktionspunkte zu
anderen Systemteilen. Das Verteilungsdiagramm zeigt die dynamische Zuordunung
von Softwareelementen zu Hardwareelementen eines Systems.
Verhaltensdiagramme
Verhaltensdiagramme beschreiben Aspekte eines Systems, die sich mit dem dynamischen
Verhalten von Systemelementen beschäftigen. Verhaltensdiagramme
modellieren bestimmte dynamische Aspekte eines Systems, unter
Vernachlässigung anderer Zusammenhänge.
Interaktionsdiagramme
sind eine Untermenge der Verhaltensdiagramme. Sie beschreiben die Kommunikation
zwischen Kommunikationspartnern.
35

36
Begriffe der UML
Da die UML Spezifikation in englischer Sprache verfasst ist, werden in Veröffentlichungen
häufig deutsche und englische Begriffe verwendet. Zur Erleichterung der
Übersetzung existiert eine UML Übersetzungstabelle, die alle wesentlichen
englischen Begriffe in die deutsche Sprache übersetzt. Sie ist zu finden unter
http://www.oose.de. Auf diesem Server befindet sich auch ein Glossar, das alle
Begriffe der UML erklärt. Auch in den Spezifikationsdokumenten der UML [Omg
03Super] und [Omg 03Infra] sind die verwendeten Begriffe in einem Glossar
definiert.
Einige zentrale, diagrammübergreifende Begriffe der UML werden hier kurz
erläutert.
Artifact - Artefakt
In der UML Spezifikation werden Ergebnisse oder Produkte eines Entwicklungsprozesses
als artifact bezeichnet. Ein artifact ist also z. B. eine Klasse, ein Diagramm,
eine Beschreibung eines Elementes.
Note - Notiz, Anmerkung
Jedes UML Element kann mit einer Notiz versehen werden. Die Notiz wird über
eine gestrichelte Linie mit dem Element verbunden, das beschrieben wird.
Abbildung 3.3.1Beispiel Notiz in UML Diagrammen
Szenario
Ein Szenario ist eine Szene eines Modells, also ein Ausschnitt, für den nur bestimmte
Aspekte des Gesamtsystems dargestellt werden.
Constraint - Einschränkung
Eine Einschränkung ist eine Bedingung, die bei der Implementierung eines Systems
erfüllt sein muss. Constraints werden in geschweiften Klammern geschrieben
und mit einer gestrichelten Linie mit dem Element verbunden, auf das sie sich beziehen.

Abbildung 3.3.2Beispiel Constraint
In Abbildung 3.3.2 wird die Einschränkung formuliert, dass das Immatrikulationsdatum
eines Studenten immer größer sein muss, als das Geburtsdatum.
Die UML benutzt die Object Constraint Language (OCL) zur formalen Spezifikation
von Einschränkungen (vgl. Kapitel 3.4).
Classifier
Ein Classifier bezeichnet in der UML ein Grundelement der UML, z. B. eine
Klasse, Assoziation, Datentyp. Die Grundelemente der UML werden zu dem
Element Classifier abstrahiert. Ein Classifier steht in der UML-Spezifikation
immer für ein definiertes Element der UML. Es gibt aber kein grafisches Symbol
für den Classifier.
Stereotype - Stereotyp
Stereotypen werden verwendet um Elemente zu Kategorien von Elementen zusammenzufassen.
Man kann Klassen z. B. nach ihrer Verwendung in Oberflächenklassen
(Stereotyp boundary), Entitätsklassen (Stereotyp entity) und fachliche
Klassen (Stereotyp control) einteilen. Die UML kann durch Definition neuer
Stereotypen erweitert werden. In Abbildung 3.3.1 ist der Stereotyp entity für die
Klasse angegeben.
3.3.1 Klassendiagramm Class Diagram
3.3.1.1 Zweck
Klassendiagramme stellen die statische Struktur eines Systems dar. Sie zeigen die
Klassen, die Eigenschaften der Klassen (Attribute), das Verhalten (Operationen)
der Klassen und die Beziehungen zwischen den Klassen.
Sie sind der zentrale Diagrammtyp der UML und werden in allen Phasen der Softwareentwicklung
eingesetzt.
3.3.1.2 Notation
37

38
Symbol Bedeutung
Klasse
Ein Klasse kann als Rechteck dargestellt werden, das
den Klassennamen enthält. Üblicherweise bestehen
Klassen aus drei Bereichen; der obere Bereich enthält
den Stereotyp, das Paket zu dem die Klasse gehört und
den Namen. Im mittleren Bereich werden die Attribute
angegeben und im unteren Bereich stehen die Operationen
der Klasse. Laut UML-Spezifikation kann die
Darstellung einer Klasse zusätzliche Bereiche enthalten.
Abstrakte Klasse
Der Name einer abstrakten Klasse wird kursiv geschrieben.
Alternativ kann die Eigenschaft {abstract}
angegeben werden.
Parametrisierte Klasse
auch Template oder Schablone genannt. Die parametrisierte
Klasse hat in der rechten, oberen Ecke ein das
Klassensymbol überlappendes Rechteck, das die Schablonen-Parameter
der Klasse enthält. Die Funktion, die
den Parameter verwendet wird angegeben. Die Klasse,
die den Parameter bindet, wird über eine gestrichelte
Linie mit Pfeil an dem Template verbunden. Diese
trägt die Bezeichnung .
Assoziation
Eine Linie zwischen den Klassen stellt eine Assoziation
dar. Eine Assoziation ist eine Beziehung zwischen
Klassen. Die Objekte der Klassen kommunizieren über
die Assoziationen miteinander. Die Assoziation kann
einen Namen haben. Ein Pfeil an dem Assoziationsnamen
gibt die Leserichtung des Namens an. An den
Assoziationsenden können die Rollen der beteiligten
Klassen und die Multiplizität angegeben werden. Die
zweigliedrige Assoziation kann, wie die mehrgliedrige
Assoziation, durch eine Raute markiert werden.

Symbol Bedeutung
Gerichtete Assoziation
Mit einem Pfeil an der Assoziation kann die Navigationsrichtung
angegeben werden. Der Pfeil drückt die
Zugriffsrichtung der Objekte aus. Objekt A greift auf B
zu, B greift nie auf A zu.
Vererbung
auch Generalisierung/Spezialisierung genannt. Vererbungsbeziehungen
werden mit einem Pfeil dargestellt.
Die Pfeilspitze zeigt auf die Oberklasse. Die Oberklasse
vererbt ihre Eigenschaften an die Unterklassen.
Aggregation
Eine Aggregation drückt eine Teile-Ganzes-Beziehung
aus. Das Ganze-Objekt besteht aus Teil-Objekten. Die
Raute befindet sich an dem Ende des Ganzen. Die
Aggregation ist eine spezielle Art der Assoziation. Da
das Ganze die Teile enthält, sollten am Assoziationsende
der Teile ein Navigationspfeil stehen.
Komposition
Die Komposition ist auch eine Beziehung, die Teile zu
einem Ganzen in Beziehung setzt. Die Teile und das
Ganze sind bei dieser Beziehung existenzabhängig; die
Teile können nicht ohne das Ganze existieren. Wird
das Ganze gelöscht, so beenden auch die Teile ihre
Existenz.
Assoziationsklasse
Ist eine Klasse von dem Vorhandensein einer Assoziation
zwischen zwei Klassen abhängig, so kann dies
durch eine Assoziationsklasse ausgedrückt werden. Die
Assoziationsklasse beschreibt Eigenschaften, die keiner
der an der Assoziation beteiligten Klassen sinnvoll
zuordenbar sind. Die Assoziationsklasse wird über eine
gestrichelte Linie mit der Assoziation, von der sie
abhängt, verbunden. Hat die Assoziation einen Namen,
dann muss die Assoziationsklasse den selben Namen
erhalten. Die Assoziationsklasse ist ein Analysekonzept.
39

40
Symbol Bedeutung
Tabelle 1Notation Klassendiagramm
Klassen
Mehrgliedrige Assoziation
Eine mehrgliedrige Assoziation drückt eine Beziehung
zwischen mehr als 2 gleichwertigen Klassen aus. Die
Beziehung wird mit einer Raute markiert.
Objekte und Klassen sind die zentralen Elemente objektorientierter Modelle. Die
gemeinsamen Eigenschaften konkreter Objekte werden zu Klassen abstrahiert. Die
Klasse definiert die Struktur ihrer Objekte. Die UML 2.0 versteht unter einer
Klasse ein Element, das eine Menge Objekte beschreibt, die die selbe Spezifikation
der Merkmale, Einschränkungen und Semantik teilen [Omg 03b]. Eine Klasse hat
Attribute und Operationen. Attribute und Operationen können in UML spezifiziert
werden.
Die Syntax für die Deklaration von Attributen lautet: [Sichtbarkeit] [/]
Name [:Typ] [=Wert]
Die Syntax für die Deklaration von Operationen lautet: [Sichtbarkeit]
Name [(Parameterliste)] [: Returntyp]
Die Parameterliste ist definiert als:
[Übergaberichtung] Name [: Typ] [ =Wert]
Die Syntaxelemente haben nachfolgende Bedeutung:
• Sichtbarkeit
gibt an, wie die Sichtbarkeit eines Elementes relativ zu seiner Umgebung ist. Die
Sichtbarkeit gibt also an, welche Elemente auf ein Attribut, bzw. auf eine
Operation zugreifen können. Der Zugriff auf ein Attribut definiert den lesenden
und schreibenden Zugriff auf das Attribut; die Sichtbarkeit von Operationen gibt
an, welche Elemente die Operation aufrufen können. Folgende Sichtbarkeitsmodi
sind definiert.
• public: Jedes andere Element hat Zugriff.
• privat: Der Zugriff ist auf die Objekte der Klasse selbst beschränkt.

• protected: Zugriff besteht nur für die definierende Klasse und die Vererbungslinien,
die von ihr ausgehen.
• package: Das Element ist sichtbar für alle Klassen, die sich im selben Paket
befinden.
• Der Slash [/] kennzeichnet ein abgeleitetes Element. Ein abgeleitetes Element
kann aus einem anderen Modellelement berechnet werden.
• Name
gibt den Namen des Attributs oder der Operation an.
• Typ, Returntyp
gibt den Datentyp eines Attributs, eines Parameters oder Returns an. Die UML
definiert einige Typen, wie Integer, String, u. a. Macht aber keine Einschränkungen
zur Verwendung selbstdefinierter Typen. Es können alle Typen
verwendet werden, die zur Lösung eines Problems benötigt werden.
• Wert
Attribute und Parameter können mit einem Wert belegt werden.
• Übergaberichtung
definiert die Richtung in die ein Parameter übergeben wird.
• IN- Parameter wird an die Operation übergeben. Die Operation liest den Parameter
nur.
• OUT - der Parameter wird von der Operation geschrieben, ohne dass sie seinen
Inhalt vorher verarbeitet.
• INOUT - die Operation liest einen Parameter, verarbeitet ihn und schreibt ihn
erneut.
Beispiel
Abbildung 3.3.1.2.1Klasse Konto mit UML-Deklarationen
Abbildung 3.3.1.2.1 zeigt ein Beispiel einer Klasse "Konto" die in UML deklariert
ist. Das Attribut "KontoNr" ist vom Typ Integer, für "Guthaben" wurde ein eigener
Typ mit dem Namen Real definiert. Der Typ Real steht für eine reelle Zahl (z. B.
Float in C++). Die Operation einzahlen nimmt den Parameter "Betrag" vom Typ
Real an und gibt einen Boolean-Wert zurück. Die Sichtbarkeit der Elemente wurde
ausgeblendet.
41

42
Implementierung in C++
Abbildung 3.3.1.2.2Klasse Konto mit C++-Deklarationen
Abbildung 3.3.1.2.2 zeigt die Klasse Konto mit Deklarationen in C++. Bei Einsatz
eines CASE-Tools kann aus der UML-Deklaration die Deklaration in einer
Zielsprache generiert werden.
Class Konto
{
};
private:
int KontoNr;
float Guthaben;
public:
virtual bool einzahlen(float Betrag);
Parametrisierte Klassen
werden auch Templates oder Schablonen genannt. Wenn mehrere Klassen sich nur
durch die Daten, auf denen sie arbeiten unterscheiden, können sie durch parametrisierte
Klassen realisiert werden. Die parametrisierten Klassen werden mit Parametern
versehen, die Typen enthalten können. Somit ist es möglich typunabhängige
Algorithmen zu definieren und parametrisierten Klasse zur Verarbeitung verschiedener
Datentypen zu verwenden.
Assoziation
Im Klassendiagramm drückt eine Assoziation eine Beziehung zwischen Klassen
aus. Die Assoziation kann einen Namen haben. Die Rollen der beteiligten Klassen

können angegeben werden, die Multiplizität muss spätestens im Designmodell
angegeben werden.
Beispiel
Abbildung 3.3.1.2.3Assoziation in UML-Darstellung
Das Beispiel in Abbildung 3.3.1.2.3 zeigt die Assoziation "studiert" zwischen den
Klassen "Student" und "Fachbereich". Die Multiplizität ist mit * zu 1 angegeben;
ein Student studiert immer an einem Fachbereich, ein Fachbereich hat viele Studenten.
Für Assoziationen wird üblicherweise entweder ein Assoziationsname angegeben,
oder die Rollennamen der beteiligten Klassen werden angegeben. Von der Multiplizität
hängt es ab, wie die Assoziation implementiert wird. In diesem Beispiel
muss ein Student auf einen Fachbereich zugreifen, weil der Fachbereich mit der
Multiplizität 1 an der Beziehung beteiligt ist. Der Student ist mit der Multiplizität *
beteiligt; der Fachbereich muss deshalb auf viele Objekte der Klasse Student zugreifen.
Implementierung der Assoziation in C++
Abbildung 3.3.1.2.4Realisierung der Assoziation in C++
Abbildung 3.3.1.2.4 zeigt die Realisierung der Assoziation studiert in C++. Für die
Attribute werden die Stereotypen angezeigt; Attribute vom Stereotyp
beschreiben fachliche Eigenschaften der Klassen, der Stereotyp kennzeichnet Attribute, die eine Assoziation implementieren.
43

44
Der Student muss, wie oben beschrieben, auf den einen Fachbereich zugreifen zu
dem er gehört. Dafür wurde bei dem Student der Pointer "Fachbereich
*fachbereich" deklariert, über den er auf den Fachbereich zugreift. Der Fachbereich
muss auf viele Studenten zugreifen. Für diesen Zugriff wurde die Menge
"set students" deklariert. Ein Set ist eine Struktur der Standard
Template Library und verwaltet eine Menge von Elementen.
Vererbung
Die Vererbung ist ein Grundkonzept objektorientierter Programmiersprachen und
dient der Wiederverwendung von Quellcode. Sie wird verwendet um Eigenschaften
einer Oberklasse an Unterklassen zu vererben. Alle Eigenschaften (Attribute und
Operationen) der Oberklasse, die für die Unterklasse sichtbar sind, werden an diese
vererbt. Sie sind in der Unterklasse benutzbar, als wären sie in der Klasse selbst
definiert. Die Unterklassen dürfen weitere, speziellere Eigenschaften haben. Aus
der Sichtweise der Oberklasse sind die Unterklassen immer speziellere Klassen;
aus der Sichtweise der Unterklassen ist die Oberklasse die allgemeinere, generellere
Klasse. Deshalb wird die Vererbung auch Generalisierung oder Spezialisierung
genannt.
Abbildung 3.3.1.2.5Vererbung in UML
In Abbildung 3.3.1.2.5 vererbt die "Person" ihre Eigenschaften an "Student" und
den "FH-Angestellten". Die "Person" ist die generelle Klasse, "Student" und "FH-
Angestellter" sind spezielle Personentypen. Die "Person" hat die Attribute
"Adresse" und "Name". Die Attribute der "Person" haben die Sichtbarkeit protec-

ted, damit sie an "Student" und "FH-Angestellter" vererbt werden. Attribute mit der
Sichtbarkeit private sind nur in der Klasse selbst sichtbar und werden nicht an
Unterklassen vererbt. Die Operation "aendereAdresse" ist public und wird ebenfalls
an die Unterklassen vererbt. Der "Student" hat in diesem Beispiel die Attribute
"Adresse", "Name" und "MatNr" und die Operationen "aendereAdresse",
"immatrikulieren" und "exmatrikulieren". Die Einschränkung (constraint) "{incomplete}"
gibt an, dass die Vererbung nicht vollständig ist; es gibt in einer
Fachhochschule noch weitere Personentypen, die in der Vererbung nicht dargestellt
sind. Die UML 2.0 definiert folgende constraints für Vererbungen:
• complete
• incomplete
• disjoint
• overlapping
Implementierung der Vererbung in C++
Aus dem UML-Diagramm in Abbildung 3.3.1.2.5 ergibt sich das in Abbildung
3.3.1.2.6 dargestellte Diagramm in C++-Sicht.
Abbildung 3.3.1.2.6Vererbung in C++
Class Person
{
protected:
cAdresse Adresse;
45

46
};
string Name;
public:
virtual bool aendereAdresse(neuAdresse);
class Student: public Analyse::Person
{
};
private:
int MatNr;
Fachbereich *fachbereich;
public:
virtual bool immatrikulieren(einStudent);
virtual int exmatrikulieren(einStudent);
class FH_Angestellter: public Person
{
};
private:
int PersonalNr;
public:
virtual bool aendereGehalt(neuGehalt);
Aggregation
Die Aggregation wird verwendet um zwischen Klassen eine Teile-Ganzes-Beziehung
aufzubauen. Abbildung 3.3.1.2.7 zeigt ein Beispiel einer Aggregation. Die
Lehrveranstaltung setzt sich aus der Vorlesung und aus einem optionalen
Praktikum zusammen. Die Multiplizität "0..1" mit der das Praktikum an der
Aggregation beteiligt ist, drückt aus, dass es auch Lehrveranstaltungen ohne
Praktikum gibt.

Abbildung 3.3.1.2.7Aggregation
Da die Aggregation eine Spezialform der Assoziation ist, ist die Assoziation in
durch zwei Assoziationen ersetzbar. Das Diagramm in Abbildung 3.3.1.2.7 ist
äquivalent zu dem Diagramm in Abbildung 3.3.1.2.8. Die Aggregation wird hier
durch die Rollenbezeichnung "besteht_aus" ausgedrückt.
Abbildung 3.3.1.2.8Aggregation als Assoziation
Implementierung der Aggregation in C++
Da die Aggregation eine Spezialform der Assoziation ist, wird sie wie eine Assoziation
implementiert.
47

48
Komposition
Abbildung 3.3.1.2.9Komposition
Das Beispiel in Abbildung 3.3.1.2.9 zeigt eine Komposition. Die Komposition ist
eine strengere Form der Aggregation und drückt aus, dass das Ganze und die Teile
existenzabhängig sind. Die Teile und das Ganze bilden eine untrennbare Einheit;
sie können deshalb nur als Einheit existieren. Die Teile dürfen immer nur zu einem
Ganzen gehören; das Ganze kann keine Multiplizität größer 1 haben.
In diesem Beispiel besteht eine Rechnung aus dem Rechnungskopf und den Positionen.
Eine Rechnungsposition kann nur zu einer Rechnung gehören. Es kann
keine Rechnungsposition geben, wenn es keine Rechnung gibt. Wird die Rechnung
gelöscht, muss sie alle Rechnungspositionen und den Rechnungskopf löschen.
Assoziationsklasse
Die UML 2.0 definiert eine Assoziationsklasse als eine Assoziation, die
Klasseneigenschaften hat, oder als Klasse, die Assoziationseigenschaften hat. Die
Assoziationsklasse bezieht sich immer auf das Vorhandensein einer Beziehung
zwischen Klassen und auf die Eigenschaften, die diese Beziehung zusätzlich hat.
Der Name der Beziehung und der Name der Assoziationsklasse repräsentieren
dasselbe Modellelement. Hat die Assoziation zu der die Assoziationsklasse assoziiert
ist, einen Namen, dann muss die Assoziationsklasse den selben Namen tragen.
Es genügt jedoch einem Element einen Namen zu geben.

Abbildung 3.3.1.2.10Assoziationsklasse
In dem Beispiel in Abbildung 3.3.1.2.10 besteht eine Assoziation zwischen
"Student" und "Lehrveranstaltung". Eine Lehrveranstaltung findet statt, wenn
mindestens 3 Studenten teilnehmen; ein Student kann keine, oder mehrere
Lehrveranstaltungen besuchen. Der "Leistungsnachweis" ist keiner dieser beiden
Klassen zuordenbar, da er sich immer auf die Verbindung (Link) eines konkreten
Exemplars von "Student" mit einem konkreten Exemplar von "Lehrveranstaltung"
bezieht. Da die Assoziationsklasse immer die Multiplizität 1 hat, wird die Multiplizität
nicht angegeben.
3.3.1.3 Anwendungsbereich
Klassendiagramme sind der zentrale Diagrammtyp der UML. Sie beschreiben die
Klassen eines Systems, ihre Eigenschaften, Operationen und die Beziehungen
zwischen den Klassen. Klassendiagramme werden in allen Phasen der Softwareentwicklung
eingesetzt. Die modellierten Inhalte und das verwendete Vokabular
müssen sich an dem Know-how der beteiligten Personengruppen orientieren. Ein
Klassendiagramm modelliert einen Teilausschnitt der realen Welt. Es werden nur
die Klassen und Eigenschaften berücksichtigt, die zur Beschreibung des Problembereichs
benötigt werden. Bei der Modellierung von Klassendiagrammen wird
zwischen dem Analysemodell und dem Designmodell unterschieden.
Diese verschiedenen Sichten auf ein Klassenmodell können durch den Einsatz von
Entwicklungswerkzeugen, wie z. B. Case-Tools verwaltet und konsistent gehalten
werden.
Klassendiagramm Analyse
Klassendiagramme in der Sichtweise der Analyse stellen dar, was das System aus
Anwendersicht leisten soll. Sie bilden die Klassen, Attribute, Operationen und ihre
Beziehungen ab, die das spätere Softwaresystems aus der Sicht des fachlichen Bereiches,
den es abdecken soll, enthalten muss.
49

50
Das Analysemodell beschreibt was die zukünftige Software aus fachlicher Sicht
leisten soll.
Für die Informatikabteilung, die das geplante Produkt entwickeln soll, stellt das
Analysemodell die Basis der zukünftigen Entwicklungsarbeit dar. Da Fehler in der
Analyse sehr teuer sind, muss das Analysemodell sehr sorgfältig modelliert
werden.
In der Analyse sollten sprechende Namen verwendet werden, die auch die beteiligte
Fachabteilung versteht. Die Deklaration von Attributen und Operationen wird
in UML, nicht in der späteren Programmiersprache vorgenommen. Bei Einsatz
eines CASE-Tools können daraus die Deklarationen in der gewählten Programmiersprache
generiert werden.
Klassendiagramm Design
Im Designmodell wird das Analysemodell auf die Implementierungstechnologie
abgebildet. Klassendiagramme in der Sichtweise Design stellen dar, wie das System
technisch aufgebaut sein muss, damit es die in der Analyse geforderten Eigenschaften
realisieren kann. Die in der Systemanalyse erkannten und dokumentierten
Strukturen werden um die Informationen, die nötig sind um das fachliche Modell
zu implementieren, erweitert.
Im Design wird die Implementierungssprache festgelegt. Es wird definiert wie
Assoziationen zu implementieren sind; die Art und Weise wie die Instanzen der
Klassen verwaltet werden, wird festgelegt. Die Persistenzschicht wird modelliert,
d. h. es wird definiert, wie die Klassen auf eine Datenbank abgebildet werden; die
Datenbank wird ausgewählt. In der Regel werden bei der Implementierung eines
Modells Klassenbibliotheken verwendet, deren Verwendung im Klassenmodell
dokumentiert werden muss. Die Benutzeroberfläche muss eingeführt werden.
3.3.1.4 Zusammenhang
Klassen werden in fast allen UML-Diagrammen verwendet. Die Klassen des
Klassendiagramms wirken sich deshalb auf alle anderen Diagramme aus und sind
mit den anderen Diagrammen eines Modells konsistent zu halten.
3.3.1.5 Hinweise für die Praxis
Klassen identifizieren

Die UML definiert eine umfangreiche Notation zur Modellierung von Softwaresystemen.
Vor der Modellierung der Struktur von Softwaresystemen müssen jedoch
aus natürlichsprachigen Dokumentationen der Anforderungen an Systeme die
enthaltenen fachlichen Objekte identifiziert werden. Alle Klassen, die den Problembereich
für eine geplant Anwendung beschreiben, sind fachliche Klassen.
Diese Klassen beschreiben die wichtigsten Merkmale der Anwendung.
Wie findet man die in einem Text die enthaltenen Klassen? Es gibt zwei
Techniken, die hier kurz skizziert werden.
Substantivmethode
Rumbaugh empfiehlt in [Rumbaugh, 1991] die Substantiv-Methode zur
Identifikation von Klassen. Aus den Anforderungsdefinitionen an ein geplantes
System werden alle Substantive markiert. Diese Begriffe sind potenzielle
Klassenkandidaten. Danach werden redundante Begriffe eliminiert. Alle Begriffe,
die auf die technische Realisierung der Begriffe hindeuten werden beseitigt. Durch
diese kritische Analyse der Texte erhält man eine Menge Begriffe, die als Klassen
im geplanten System verwendet werden können.
CRC-Methode
CRC bedeutet Class, Responsibility, Collaboration und bezeichnet eine Technik
bei der für jede potenzielle Klasse eine Karteikarte angelegt wird, die drei Abschnitte
enthält:
• class – Klassennamen
• resposibility – Zuständigkeit
• collaboration - Zusammenarbeit
Für jede Klasse wird der Klassenname notiert. Im Abschnitt Zuständigkeit wird
beschrieben für welchen Zweck die Klasse eingeführt wurde, und unter Zusammenarbeit
wird angegeben mit welchen anderen Klassen sie zusammenarbeitet.
Die Substantivmethode und die CRC-Methode können auch kombiniert verwendet
werden, indem man die Substantivmethode zum Auffinden der Klassen verwendet
und die Klasseneigenschaften danach mit CRC-Karten (oder einem Texteditor)
beschreibt.
Attribute identifizieren
Attribute sind die Eigenschaften der Klassen. Attribute sollten nur von der Klasse
zu der sie gehören abhängig sein. Bei der Suche nach Attributen muss die Frage
beantwortet werden: Was muss die Klasse über sich selbst wissen, damit sie arbeiten
kann? Die Adjektive in der Anforderungsdefinition sind Kandidaten für Attribute.
51

52
Operationen identifizieren
Operationen sind die öffentlich aufrufbaren Funktionen einer Klasse. Operationen
sind die Schnittstellen einer Klasse, über die sie die Dienste, die sie implementiert,
allen anderen Klassen des Systems anbietet.
Assoziationen identifizieren
Objekte kommunizieren über Assoziationen miteinander. Bei der Suche nach
Assoziationen muss die Frage gestellt werden: Welche Objekte kommunizieren
miteinander? In einem Projekt sind aber nur die Assoziationen zu modellieren, die
zur Lösung des gestellten Problems benötigt werden. Die Verben in der Anforderungsdefinition
geben Hinweise auf mögliche Assoziationen.
Vererbungsstrukturen identifizieren
Bei der Suche nach Vererbungsstrukturen sucht man gemeinsame Eigenschaften
von Klassen, die in einer Oberklasse zusammengefasst werden können. Die Unterklasse
muss alle geerbten Eigenschaften verwenden. Vererbung liegt dann vor,
wenn eine Klasse eine Speziallfall einer anderen Klasse ist. Zwischen Oberklasse
und Unterklasse besteht immer eine "ist-ein" Beziehung.
Style Guide
• Vererbungshierarchien sollten von oben nach unten angeordnet werden. Unterklassen
sollten unterhalb ihrer Oberklasse stehen.
• Kreuzungen zwischen Beziehung sollten minimiert werden.
• Wird ein Klassendiagramm zu groß für eine Seite (einen Bildschirm), sollte es
über mehrere Seiten in Teildiagramme verteilt werden. Für die Aufteilung der
Klassen in Teildiagramme sollten fachliche Kriterien herangezogen werden.
Neu in UML 2.0
Die Klassendiagramme sind in allen wesentlichen Elementen unverändert gegenüber
der UML 1.x.
3.3.1.6 Beispiel
Identifikation der Klassen

Aus den Spezifikationen des Use Case Diagramms "Mensa" wurden die
Klassenkandidaten abgeleitet. Für den Use Case "KarteLaden" ergaben sich aus
den markierten Begriffen in der Spezifikation folgende Klassenkandidaten:
Automat, Karte, Kunden, Betrag, Display, Geld, Echtheit, Geldscheins, Restbetrag,
Gesamtbetrag, Schein, Taste, Quittieren, Minute, Benutzung, Strom und Wiederkehr.
Folgende Begriffe sind für den Problembereich überflüssig: Geld, Echtheit, Geldscheins,
Minute, Benutzung, Strom und Wiederkehr. Sie werden eliminiert.
Quittieren ist der Instanzname der Klasse Taste und wird eliminiert.
Der Kunde ist ein Akteur, er ist damit kein Klassenkandidat.
Damit bleiben nachfolgende Klassenkandidaten für den Use Case "KarteLaden":
Automat, Karte, Display, Taste.
Der Betrag ist ein Attribut von Karte.
Abbildung 3.3.1.6.1 zeigt das Klassendiagramm zu dem Mensa Beispiel. Die
"MensaKarte" wird von einer abstrakten "FH_Karte" abgeleitet. Das Attribut "ID"
der "FH_Karte" hat die Sichtbarkeit protected und wird an die "MensaKarte"
vererbt. "MensaAutomat" und "Kasse" stehen jeweils über Aggregationen in Beziehung
zu den angegebenen Objekten. "Display" und "LeseSchreibEinheit" sind
Teil von zwei Klassen; dies ist in der UML ausdrücklich erlaubt. Da das Beispiel
ein Analysemodell darstellt, sind nur Analyseeigenschaften dargestellt. Es sind
keine Elemente modelliert, die sich auf die Implementierung beziehen.
Um die Lesbarkeit des Modells zu verbessern, wurde Farbe eingesetzt. Die Aggregationsbeziehungen
sind blau, Assoziationen schwarz und Vererbungen rot dargestellt.
53

54
Abbildung 3.3.1.6.1Klassendiagramm Mensa
3.3.2 Objektdiagramm - Object Diagram
3.3.2.1 Zweck

Objektdiagramme werden eingesetzt um einen Schnappschuss eines Systems zur
Laufzeit zu darzustellen. Es werden die zur Laufzeit existierenden Objekte,
Attribute und Beziehungen angegeben.
3.3.2.2 Notation
Symbol Bedeutung
Objekt
Für jedes Objekt wird der Klassenname und der
Objektname angegeben. Für die dargestellten Attribute
wird der Attributname, Typ und die aktuelle Wertbelegung
angegeben.
Link
Tabelle 2Notation Objektdiagramm
3.3.2.3 Beispiel
Abbildung 3.3.2.3.1Beispiel Objekt Mensakarte
Ein Link ist eine aktuelle Beziehung zwischen Objekten.
Er wird ähnlich der Assoziation im Klassendiagramm, als
Linie zwischen den Objekten dargestellt. Es kann ein
Name oder Rollenbezeichnungen angegeben werden
Das Beispiel in Abbildung 3.3.2.3.1 zeigt das Objekt mit der Identität "123" der
Klasse "MensaKarte". Das Attribut "Betrag" ist vom Typ "float" und hat den
aktuellen Wert "2.60".
3.3.3 Komponentendiagramm - Component Diagram
55

56
3.3.3.1 Zweck
Ein Komponentendiagramm beschreibt die physikalischen Komponenten aus
denen ein System zusammengesetzt ist. Es stellt die Komponenten eines Modells,
ihre Beziehungen und die öffentlichen Schnittstellen dar. Eine Komponente ist eine
modulare, autonome Einheit innerhalb eines Systems, die über definierte Schnittstellen
verfügt. Eine Komponente kann Schnittstellen anbieten, bzw. erfordern. Der
interne Aufbau einer Komponente ist verborgen. Komponentendiagramme geben
Auskunft darüber welche Teile eines Systems zusammenarbeiten. Eine
Komponente ist innerhalb eines Modells austauschbar.
3.3.3.2 Notation
Symbol Beschreibung
Komponente (externe Sicht)
Eine Komponente wird als Rechteck dargestellt.
Sie trägt die Stereotypbezeichnung
und hat einen Namen. In der
rechten, oberen Ecke kann sie das
Komponentensymbol tragen. Das Symbol mit
dem vollen Kreis stellt eine Schnittstelle dar, die
die Komponente bereitstellt; das Symbol mit dem
Halbkreis bezeichnet eine Schnittstelle, die von
der Komponente genutzt wird.
Komponente (interne Sicht)
Komponenten können, ähnlich wie Klassen,
vollständig dargestellt werden. In dem Bereich
unter dem Namen werden die geforderten und
bereitgestellten Schnittstellen aufgeführt; im
nächsten Abschnitt werden die Klassen, die die
Komponente realisieren angegeben. Im unteren
Bereich wird die Datei angegeben, die die
Implementierung der Komponente enthält.

Symbol Beschreibung
Beziehungen
Tabelle 3Notation Komponentendiagramm
3.3.3.3 Anwendungsbereich
können im Komponentendiagramm als
gestrichelte Linien angegeben werden. Der Pfeil
gibt zu Zugriffsrichtung an. Sind die
Schnittstellen der Komponenten angegeben,
ergibt sich aus den Symbolen die
Zugriffsrichtung.
Komponentendiagramme werden eingesetzt um komponentenorientierte Software
zu modellieren. Es ist damit möglich Komponenten und ihre Abhängigkeiten für
Systeme, die in Komponententechnologie wie z. B. Enterprise Java Beans, .Net
oder CORBA realisiert werden zu modellieren.
Komponentendiagramme können auch verwendet werden, um die physischen
Komponenten eines Systems zu modellieren, das nicht in
Komponententechnologie realisiert wird. Die Komponenten geben dann die
Zuordnung der Klassen zu den Quellcodedateien an.
3.3.3.4 Zusammenhang
Da Komponenten häufig mehrere Klassen enthalten, müssen die Klassen den
Komponenten zugeordnet werden. Komponentendiagramme und
Klassendiagramme müssen konsistent gehalten werden.
3.3.3.5 Hinweise für die Praxis
Für ein Komponentendesign gelten die selben Designprinzipien wie für ein Design
auf Klassenebene; die Komponenten sollten eine hohe Kohäsion und eine lose
Kopplung aufweisen.
Neu in UML 2.0
In den UML-Versionen 1.x war eine Komponente eine Implementierungseinheit.
Sie legte fest in welchen Quellcodedateien die Klassen eines Modells
implementiert wurden. Es war zwar möglich Komponentendiagramme zum
57

58
Entwurf komponentenorientierter Software zu verwenden, aber die Notation sah es
nicht explizit vor. Die in UML 2.0 mögliche explizite Angabe von bereitgestellten
und geforderten Schnittstellen war in UML 1.x nur implizit möglich.
3.3.3.6 Beispiel
Abbildung3.3.3.6.1Beispiel, Komponentendiagramm Mensaautomat
Abbildung3.3.3.6.1 zeigt eine einfache Komponentenstruktur des Beispiels
Mensaautomat. Im oberen Bereich wird der Name der Komponente angegeben, der
untere Bereich gibt die Klassen an, die den Komponenten zugeordnet sind. Das
Pluszeichen vor dem Klassennamen gibt die Sichtbarkeit public der Klassen
innerhalb der Komponente an.
Es werden die Komponentensymbole der UML 1.x verwendet; dies ist in der UML
2.0 ausdrücklich erlaubt.
3.3.4 Paketdiagramm - Package Diagram
3.3.4.1 Zweck

Pakete werden verwendet um Mengen von Modellelementen zu Gruppen zusammenzufassen.
Sie dienen der Strukturierung von UML-Modellelementen in
überschaubare Einheiten. Paketdiagramme stellen die Pakete und die Beziehungen
(Abhängigkeiten) zwischen den Paketen eines Modells dar. Die Kriterien, nach
denen Modelle strukturiert werden, sind frei festlegbar.
3.3.4.2 Notation
Tabelle 4Notation Paketdiagramm
3.3.4.3 Anwendungsbereich
Paket
Ein Paket fasst eine Gruppe von beliebigen
Modellelementen zusammen. Pakete können
verschachtelt sein. Sie definieren einen
Namensraum. In diesem Beispiel umfasst
das Paket a die Pakete b und c.
Abhängigkeiten
zwischen Paketen werden als gestrichelte
Pfeile dargestellt. Sie drücken aus, dass Pakete
in einem Client-Server-Verhältnis zueinander
stehen. Häufige Stereotypen für
Abhängigkeiten in Paketdiagrammen sind
und , womit ausgedrückt
wird, dass ein Paket ein anderes
importiert, bzw. darauf zugreift.
Da Pakete Modellelemente zu Gruppen zusammenfassen, können sie für verschiedene
Zwecke eingesetzt werden. Pakete können verwendet werden um Subsysteme
zu modellieren, in die ein großes System zerlegt wird. Pakete können auch
verwendet werden um die Ergebnisse von Entwicklungsphasen festzulegen und die
entsprechenden Diagramme, die einer Phase zugeordnet werden, zusammenzufassen.
Darüber hinaus können Pakete für jede sinnvolle Gruppierung von
Modellelementen in einem Projekt eingesetzt werden. Die Systemarchitektur kann
z. B. mit Paketen abgebildet werden.
Jedes Paket definiert einen Namensraum. Namensräume geben Sichtbarkeitsbereiche
von Modellelementen an; in einem Paket müssen Namen eindeutig sein. Jedes
Modellelement gehört zu einem Paket. Zwei Elemente, die zu unterschiedlichen
Namensräumen gehören dürfen denselben Namen tragen; um sie zu unterscheiden
muss der Namensraum angegeben werden.
59

60
Der Zugriff auf die Elemente eines Paketes kann durch die Sichtbarkeit der
Elemente gesteuert werden. Die Sichtbarkeit kann public, private oder protected
sein.
3.3.4.4 Zusammenhang
Pakete sind eine logische Zusammenfassung von Modellelementen. Folgende
Elemente werden häufig zu Paketen zusammengefasst:
• Klassen werden zu Realisierungseinheiten zusammengefasst. In C++ werden
Pakete als namespace realisiert. In Java werden Pakete als Java-Package umgesetzt.
• Use Cases werden zu Paketen zusammengefasst, um in frühen Entwicklungsphasen
ein Projekt in Teilprojekte zu zerlegen, die von verschiedenen
Entwicklergruppen bearbeitet werden können.
• UML-Diagramme werden zu Paketen zusammengefasst, um die Entwicklungsergebnisse
eines Projekts den Entwicklungsphasen zuzuordnen.
Von Paketen können keine Instanzen gebildet werden. Sie können deshalb in
keinen Interaktionsdiagrammen verwendet werden.
3.3.4.5 Beispiel
Abbildung 3.3.4.5.1Beispiel Paketdiagramm Mensaautomat

Abbildung 3.3.4.5.1 definiert eine Paketstruktur für das Beispiel Mensaautomat auf
der Ebene des Use Case Modells. Jedem Paket ist ein Use Case und alle den Use
Case verfeinernden Diagramme zugeordnet. Dem Paket Geldautomat wären in
diesem Beispiel folgende Diagramme zugeordnet:
• das Sequenzdiagramm "KarteLaden“
• das Aktivitätsdiagramm "KarteLaden“
Durch dieses Paketdiagramm werden drei Subsysteme definiert, die von verschiedenen
Projektteams selbständig bearbeitet werden können.
3.3.5 Anwendungsfalldiagramm - Use Case Diagram
3.3.5.1 Zweck
In Use Case Diagrammen wird das externe Systemverhalten aus Anwendersicht
beschrieben. Use Case Diagramme stellen das geplante System, die Akteure, die
Verwendung des geplanten Systems (Anwendungsfälle) und die Beziehungen zwischen
Akteuren und Anwendungsfällen dar. Use Case Diagramme geben Auskunft
darüber, was ein geplantes System aus Sichtweise der Benutzer leisten soll.
3.3.5.2 Notation
Symbol Bedeutung
System
Das Rechteck stellt das geplante System dar. Das System erhält
einen Namen. Ein Use Case Diagramm kann auch mehrere Systeme
enthalten, die ineinander geschachtelt sein dürfen. Dadurch
kann ein System in Teilsysteme gegliedert werden.
Akteur
Ein Akteur ist ein Element, das nicht zum geplanten System gehört.
Er kann eine Person sein, die auf das System zugreift, oder
ein anderes System, das mit dem geplanten System kommuniziert.
Die UML erlaubt mehrere Symbole zur Darstellung eines Akteurs.
Er kann als Strichmännchen dargestellt werden. Es ist optional
erlaubt ein Klassensymbol zu verwenden, das mit dem Stereotyp
markiert wird. Zusätzlich können eigene Symbole
verwendet werden um nicht menschliche Akteure darzustellen.
61

62
Symbol Bedeutung
Use Case
Eine Ellipse stellt einen Anwendungsfall des Systems dar. Ein
Anwendungsfall ist ein in sich abgeschlossener Vorgang, der für
einen oder mehrere Akteure ein beobachtbares Ergebnis liefert. Er
beschreibt aus Sicht der Akteure welche Leistungen das System
für den Anwender zur Verfügung stellt. Ein Use Case stellt somit
einen Teil der Gesamtfunktionalität des Systems dar. In UML 2.0
kann auch ein Rechteck, das mit einer Ellipse markiert wird, als
Use-Case-Symbol verwendet werden. Der Name kann innerhalb
oder außerhalb des Symbols stehen.
Extension points
Das Verhalten eines Use Case kann durch einen weiteren Use Case
erweitert werden. Dies wird durch die extend-Beziehung und den
extension point angegeben. Die Beziehung wird gestrichelt
dargestellt; der Pfeil zeigt auf den erweiterten Use Case und trägt
den Stereotyp . Der extension point gibt den Ort im
erweiterten Use Case an, an dem der erweiternde Use Case eingefügt
wird. b erweitert das Verhalten von a. b wird an dem extension
point "Name" in a eingefügt.
include-Assoziation
Die include Beziehung definiert einen Use Case, der die Funktionalität,
die ein anderer Use Case zur Verfügung stellt, importiert.
Der Use Case a importiert die Funktionalität des Use Case b.
Vererbungsbeziehung
In Use Case Diagrammen ist die Verebungsbeziehung erlaubt. Sie
kann verwendet werden um Verhalten zwischen Use Cases zu
vererben. Sie kann aber auch verwendet werden, um Vererbungsbeziehungen
zwischen Akteuren aufzubauen.
Assoziation
Eine Linie stellt eine Assoziation zwischen einem Akteur und
einem Use Case dar. Sie beschreibt den Zugriff des Akteurs auf die
Funktionalität, die das System in diesem Use Case zur Verfügung
stellt, bzw. eine Antwort des Systems an einen Akteur.
Tabelle 5Notation Use Case Diagramm
Use Case Diagramme stellen das für den Anwender sichtbare Verhalten eines Systems
dar. Sie bestehen aus den in Tabelle 4 aufgeführten Notationselementen. Ein

System stellt ein vollständiges Hard- bzw. Softwaresystem dar. Das System enthält
die Use Cases. Akteure sind extern und stehen außerhalb des Systems. Ein Use
Case beschreibt eine Menge von Funktionen, die das System für die Benutzer
implementiert. Der Benutzer ist der Auslöser eines Use Cases; er greift über die
Assoziationen auf die Use Cases zu. Use Cases können eine Spezifikation enthalten,
die in Form eines weiteren Diagramms oder als Freitext realisiert werden kann.
Beispiel include und extend Beziehung
Abbildung 3.3.5.2.1Beispiel include, extend Beziehung
Abbildung 3.3.5.2.1 zeigt ein Beispiel zu einer include und extend Beziehung. Ein
"Bearbeiter" erfasst einen Auftrag; er greift auf den Use Case "Auftrag erfassen"
zu. Der Use Case "Auftrag erfassen" includiert (importiert) den Use Case "Kunden
prüfen", d. h. bei jedem Erfassen eines Auftrags wird der Kunde geprüft. Includierte
Use Cases werden beim Ausführen des includierenden Use Case immer ausgeführt.
Der Use Case "Auftrag erfassen" hat den extension point "Kunde einfügen". Dieser
verweist über die extend-Beziehung und die in der angehängten Notiz enthaltene
Information auf den Use Case "Kunden erfassen". Das bedeutet, dass der Use Case
"Kunden erfassen" nur dann ausgeführt wird, wenn die Bedingung "Kunde=neu"
erfüllt ist. Durch die Angabe des extension points bei der Bedingung wird deutlich
gemacht an welcher Stelle des erweiterten Use Case ("Auftrag erfassen") der
erweiternde Use Case ("Kunden erfassen") im Ablauf des erweiterten Use Case
eingefügt wird. Die extend Beziehung drückt also eine optionale Erweiterung eines
Use Case aus, die nur unter bestimmten Bedingungen ausgeführt wird.
3.3.5.3 Anwendungsbereich
Use Case Modelle werden zur Festlegung der Anforderungen an ein Softwaresystem
(Anforderungsanalyse, Requirements engineering) eingesetzt. Use Case
63

64
Modelle sind leicht verständlich und ein gutes Kommunikationsmittel zwischen
Systemanalytiker, Anwender und Entwickler. Sie legen die Grenzen des Systems
fest, die Akteure, die darauf zugreifen und die Funktionalität des Systems. Die
Funktionalität wird aus Sicht der zukünftigen Benutzer des geplanten Systems
analysiert und definiert. Implementierungsdetails, wie z. B. die zu verwendende
Programmiersprache, Systemarchitektur (Client-Server, ....), usw. sind in diesen
Phasen noch nicht wichtig und deshalb zu vernachlässigen.
In der Systemanalyse wird, z. B. in Meetings zwischen Systemanalytikern und
Anwendern des künftigen Systems definiert was das System aus der Sicht der
Anwender leisten soll. Die einzelnen Fälle, die das System abdecken soll, werden
als Use Case in die Diagramme eingezeichnet und beschrieben.
Ein Use Case Diagramm stellt also eine grobe Skizze des Systems dar, das den
Zweck des geplanten Systems angibt, seine Grenzen und Schnittstellen, die auf es
einwirken. Alle modellierten Elemente sind in einer Spezifikation zu beschreiben.
Die Spezifikation sollte das Verhalten im Normalfall, mögliche alternativen Abläufe
und das Verhalten im Fehlerfall enthalten.
3.3.5.4 Zusammenhang
Die Use Cases stellen jeweils eine Menge von Systemfunktionen dar. Diese
Funktionen sind in einem Projekt genauer zu beschreiben. Diese Spezifikation der
Use Cases kann in Form eines anderen UML-Diagramms erfolgen, oder als strukturierter
Text hinterlegt werden.
Folgende Diagrammtypen sind zur Spezifikation von Use Cases geeignet:
• Aktivitätsdiagramme
• Sequenzdiagramme
• Interaktionsübersichtsdiagramme
• Kommunikationsdiagramme
Stehen die Geschäftsprozesse im Vordergrund, so können Aktivitätsdiagramme
verwendet werden. Damit können die Abläufe der Use Cases präzise beschrieben
werden. Einzelne Szenen können in Sequenzdiagrammen oder in Kommunikationsdiagrammen
modelliert werden, wenn die Interaktion von Objekten eine
wichtige Rolle spielt. Interaktionsübersichtsdiagramme können verschiedene Interaktionsdiagramme
einem Use Case zuordnen.
Die Use Case Spezifikationen enthalten wichtige Informationen für das zu entwickelnde
System. Aus den Spezifikationen können erste Klassenkandidaten für das
statische Modell abgeleitet werden.

3.3.5.5 Hinweise für die Praxis
Identifikation der Akteure
In der Anforderungsanalyse ist es nötig die Akteure zu identifizieren und zu
benennen. Dabei müssen die Fragen beantwortet werden:
• Für wen wird das System entwickelt?
• Wer soll das System benutzen?
• Mit welchen anderen Systemen soll das geplante System interagieren?
Identifikation der Systemgrenzen
Die Use Cases sind Teil des Systems und enthalten die Funktionalität des zukünftigen
Systems. Akteure sind Elemente, die nicht zu dem System gehören und auf
das System zugreifen. Das System grenzt die Elemente, die zum System gehören
von Elementen, die nicht zu dem System gehören ab. Alle Elemente innerhalb des
Systems gehören zu dem System und sind zu entwickeln. Elemente außerhalb des
Systems greifen auf das System zu.
Identifikation der Use Cases
Use Cases beschreiben den Zweck, für den ein System entwickelt wird auf einer
hohen Abstraktionsebene. Sie beschreiben die Leistung, die ein System für den
Benutzer erbringt.
Folgende Fragen sind zur Identifikation von Use Cases hilfreich:
• Für welchen Zweck soll das System eingesetzt werden?
• Wofür will der spätere Benutzer es einsetzen?
• Durch welches externe Ereignis wird ein Use Case angestoßen?
• Welches Ergebnis liefert ein Use Case dem späteren Nutzer?
Spezifikation der Use Cases
Zur Spezifikation von Use Cases ist es vorteilhaft strukturierten Text zu
verwenden. Die Textstruktur könnte folgende Abschnitte enthalten:
• Name des Use Case
• Auslösendes Ereignis
• Verhalten im Normalfall
• Verhalten im Fehlerfall
• Ergebnis
Identifikation der Beziehungen zwischen Akteuren und Use Cases
Zur Identifikation der Beziehungen hilft die Beantwortung folgender Fragen:
• Auf welche Use Cases greift ein Akteur zu?
65

66
• Welche Antworten erhält er vom System?
• Über welche externen Ereignisse muss ein Use Case informiert werden?
Style Guide
• Akteure und Use Cases sollten niemals in einem Diagramm isoliert sein (ohne
Bezug zu anderen Modellelementen).
• Ein Use Case Diagramm sollte nicht mehr als ca. 10 Use Cases enthalten. Bei zu
vielen Use Cases wird das Diagramm unübersichtlich. Zu viele Use Cases in
einem Diagramm sind ein Hinweis darauf, dass die Granularität der Use Cases
nicht korrekt gewählt wurde. Sollte das System zu groß sein, ist es sinnvoll es in
Teilsysteme zu zerlegen und in mehrere Use Case Diagramme zu verteilen.
• Kreuzungen zwischen Assoziationen sind zu vermeiden.
• Akteure sind außerhalb des Systems einzuzeichnen.
Neu in UML 2.0
Die Notationselemente für Use Case Diagramme sind in der UML 2.0 unverändert.
Vorbedingung und der extension point müssen jetzt als Notiz an der extend-
Beziehung angegeben werden.
3.3.5.6 Beispiel
Das Use Case Modell "Mensa" besteht aus den Use Cases "EssenZahlen",
"KarteLaden" und "Umsatzstatistik"; das System wird für diese Zwecke verwendet.
Die Akteure "Kunde", "MensaLeitung" und "KassenFrau" greifen auf das System
zu. Der Zugriff von Servicetechnikern auf das System wird in dem Beispiel nicht
modelliert. Nachfolgend sind die beiden Use Cases "EssenZahlen" und
"KarteLaden" spezifiziert. Der Use Case "Umsatzstatistik" wird nicht detailliert
spezifiziert und modelliert. Die unterstrichenen Begriffe in den Spezifikationen
stellen die ersten Klassenkandidaten dar, die beim Lesen der Spezifikation
gefunden wurden. Verfahren, die zur Identifikation von Klassenkandidaten
geeignet sind, werden im Kapitel Klassendiagramm beschrieben.

Abbildung 3.3.5.6.1Beispiel, Use Case Diagramm Mensa
Spezifikation
Name des Use Case: KarteLaden
Auslösendes Ereignis: Kunde schiebt eine Karte in den Automat
Verhalten im Normalfall: Der Automat liest und prüft die Karte. Ist die Karte
gültig, so zeigt er dem Kunden den Betrag, der noch auf der Karte gespeichert ist
auf dem Display an. Ist die Karte ungültig, wird sie wieder ausgeschoben. Ist die
Karte gültig, kann der Kunde Geld in den Automaten einschieben. Das Geld wird
auf Echtheit überprüft. Ist das Geld echt, wird der Betrag des eingelegten Geld-
scheins zu dem Restbetrag, der noch auf der Karte gespeichert war, addiert und der
Gesamtbetrag angezeigt. Wird das Geld vom Automaten nicht als echt akzeptiert,
so schiebt er den Schein wieder aus. Der Kunde kann keine oder mehrere
Geldscheine einschieben. Drückt der Kunde die Taste Quittieren, wird der aktuelle
Betrag auf der Karte gespeichert und die Karte wird vom Automat ausgeschoben.
Hat der Kunde kein Geld eingeschoben, erhält er die Karte unverändert zurück.
Verhalten im Fehlerfall: Lässt ein Kunde seine Karte länger als eine Minute in
dem Automat, ohne ihn zu bedienen, dann schiebt der Automat die Karte wieder
aus.
67

68
Fällt während der Benutzung der Strom aus, dann schiebt der Automat nach
Wiederkehr des Stroms Karte und Geld wieder aus. Der Geldbetrag auf der Karte
bleibt unverändert.
Ergebnis: Der Kunde erhält seine Karte zurück.
Name des Use Case: EssenZahlen
Auslösendes Ereignis: Kunde steht mit beladenem Tablett an der Kasse
Verhalten im Normalfall: Die KassenFrau tippt das Essen in die Kasse. Der zu
zahlende Gesamtbetrag wird auf dem Display angezeigt. Der Kunde schiebt seine
Karte ein. Der Betrag, den das Essen kostet, wird abgebucht. Ist auf der Karte nicht
mehr genug Geld gespeichert, wird eine entsprechende Fehlermeldung auf dem
Display ausgegeben. Die Karte wird ausgeschoben.
Verhalten im Fehlerfall: Ist die Karte für die Leseeinheit des Automaten nicht
lesbar, so gibt er eine Fehlermeldung auf dem Display aus. Die Karte wird heraus
geschoben. Fällt der Strom aus, während eine Karte im Automat ist, wird die Karte
noch Wiederkehr des Stroms heraus geschoben. Der Bezahlvorgang muss wiederholt
werden.
Ergebnis: Der Kunde hat das Essen bezahlt und erhält die Karte zurück.
3.3.6 Sequenzdiagramm - Sequence Diagram
3.3.6.1 Zweck
Sequenzdiagramme beschreiben die Kommunikation zwischen Objekten in einer
bestimmten Szene. Es wird beschrieben welche Objekte an der Szene beteiligt sind,
welche Informationen (Nachrichten) ausgetauscht werden und in welcher
zeitlichen Reihenfolge der Informationsaustausch stattfindet. Sequenzdiagramme
enthalten eine implizite Zeitachse. Die Zeit schreitet in einem Diagramm von oben
nach unten fort. Die Reihenfolge der Pfeile in einem Sequenzdiagramm gibt die
zeitliche Reihenfolge der Nachrichten an.
3.3.6.2 Notation

Symbol Bedeutung
Klasse, Objekt
In dem Rechteck oberhalb der gestrichelten Linie wird der
Objektname und der Klassenname angegeben. Der Name wird
unterstrichen. Die senkrechte, gestrichelte Linie stellt die
Lebenslinie (lifeline) eines Objekts dar. Im diesem zeitlichen
Bereich existiert das Objekt. Das schmale Rechteck auf der
gestrichelten Linie stellt eine Aktivierung dar. Eine Aktivierung
ist der Bereich, in dem eine Methode des Objektes aktiv ist
(ausgeführt wird). Auf einer Lebenslinie können mehrere
Aktivierungen enthalten sein.
Nachricht, Botschaft
Objekte kommunizieren über Nachrichten. Nachrichten werden
als Pfeile zwischen den Aktivierungen eingezeichnet. Der Name
der Nachricht steht an dem Pfeil. Eine Nachricht liegt immer
zwischen einem sendenden und einem empfangenden Objekt.
Synchrone Nachricht (Aufruf)
Der Pfeil mit der ausgefüllten Spitze bezeichnet einen synchronen
Aufruf. Der Aufruf erfolgt von der Quelle zum Ziel, d. h. die
Zielklasse muss eine entsprechende Methode implementieren.
Die Quelle wartet mit der weiteren Verarbeitung bis die
Zielklasse ihre Verarbeitung beendet hat und setzt die
Verarbeitung dann fort. Ein Aufruf muss einen Namen haben; in
runden Klammern können Aufrufparameter angegeben werden.
Der gestrichelte Pfeil ist der Return. Die Bezeichnung des Return
mit einem Namen ist optional.
Asynchrone Nachricht
Mit einer offenen Pfeilspitze werden asynchrone Nachrichten
gekennzeichnet. Der Aufruf erfolgt von der Quelle zum Ziel. Die
Quelle wartet mit der Verarbeitung nicht auf die Zielklasse,
sondern setzt ihre Arbeit nach dem Senden der Nachricht fort.
Asynchrone Aufrufe werden verwendet, um parallele Threads zu
modellieren.
Objekt erzeugen, zerstören
Das Erzeugen eines Objektes wird durch eine Nachricht, die im
Kopf des Objekts endet dargestellt.
Das Zerstören (Löschen) eines Objektes wird durch ein x auf der
Lebenslinie markiert.
69

70
Symbol Bedeutung
Tabelle 6 Notation Sequenzdiagramm
Rekursion
Sendet ein Objekt eine Nachricht an sich selbst, so ruft es eine
Methode auf, die es selbst implementiert.
Ein Sequenzdiagramm enthält Objekte, Lebenslinien, Aktivierungen, Nachrichten
und kombinierte Fragmente (combined fragment). Mit kombinierten Fragmenten
können in Sequenzdiagrammen die Kontrollstrukturen höherer
Programmiersprachen ausgedrückt werden. Jedes kombinierte Fragment wird als
rechteckiger Block dargestellt. In der linken, oberen Ecke trägt er eine
Bezeichnung, die den Typ der Kontrollstruktur angibt (interaction operator). Die
wichtigsten kombinierte Fragmente der UML 2.0 sind weiter unten erläutert.
Abbildung 3.3.6.2.1Prinzip Sequenzdiagramm
Abbildung 3.3.6.2.1 stellt das Prinzip des Sequenzdiagramms in UML 2.0 dar. In
der linken, oberen Ecke steht der Diagrammtyp (sd) und der Name des
Diagramms (NameSQ). Im Diagramm sind die beiden Objekte objA und objB
enthalten. Sie existieren während der gesamten Szene; das ist daran ersichtlich,
dass die Lebenslinien bis zum unteren Bildrand durchgezogen sind und kein x
enthalten, das das Zerstören eines Objektes ausdrückt.
Sequenzdiagramme können in der UML 2.0 verschachtelt sein. Aus einem
Sequenzdiagramm kann auf Sequenzen in einem anderen Diagramm verwiesen

werden. Der mit ref bezeichnete Block stellt einen Verweis auf ein Diagramm mit
dem Namen "SQ-Diagramm 2" dar, das eine Verfeinerung des Blockes enthält.
Der mit alt markierte Block beschreibt eine Alternative (Verzweigung). Ist die
Bedingung [b=wahr] erfüllt, wird der Bereich oberhalb der gestrichelten Linie in
dem alt-Block ausgeführt. Im else-Fall wird der Bereich unterhalb der gestrichelten
Linie ausgeführt.
Abbildung 3.3.6.2.2Schleife in Sequenzdiagramm
Abbildung 3.3.6.2.2 zeigt eine Schleife in einem Sequenzdiagramm. Die
modellierte Szene ist eine Variation des Beispiels Mensaautomat. Es sind drei
Objekte an der Szene beteiligt. Das Objekt Kunde ist vom Stereotyp . Er
ist ein Akteur (aus dem Use Case Diagramm) und greift auf den MensaAutomat zu,
indem er ihm die Botschaft "geldEin" sendet; diese Botschaft übergibt den
Parameter "Betrag". Danach sendet der "MensaAutomat" die Botschaft "anzeige
(Betrag)" an das "Display". Das "Display" führt die Methode aus und gibt die
Kontrolle über den Return wieder an den "MensaAutomat" zurück. Der
"MensaAutomat" gibt die Kontrolle wieder an den "Kunden" zurück. Diese
Sequenz von Botschaften wird solange ausgeführt bis die Abbruchbedingung
[Summe reicht] erfüllt ist. Das Prüfen des Geldes auf Echtheit ist in diesem
Beispiel nicht modelliert worden.
3.3.6.3 Anwendungsbereich
Sequenzdiagramme werden zur Darstellung der Kommunikation von Objekten
eingesetzt. Sie können in der Analyse und im Design eingesetzt werden.
Sequenzdiagramme werden häufig verwendet, um Szenarios eines Systems zu
modellieren. Ein Szenario (Szene) ist die Beschreibung einer Sicht auf einen Teil
71

72
eines Systems. Sequenzdiagramme können auch zur Modellierung von komplexen
Operationen eines Systems verwendet werden und detaillierte Designinformationen
enthalten.
Ein System wird in der Regel nicht vollständig durch Sequenzdiagramme
spezifiziert. Es werden nur die Szenen modelliert, die häufig vorkommen oder
besonders wichtig sind.
3.3.6.4 Zusammenhang
Jedes Sequenzdiagramm kann sich auf einen Use Case beziehen. Da Use Case
Diagramme aber nicht in jedem Projekt verwendet werden, können
Sequenzdiagramme auch unabhängig von Use Case Diagrammen eingesetzt
werden.
Die Klassen der Sequenzdiagramme müssen in den Klassendiagrammen enthalten
sein. Ereignisse und Nachrichten erfordern entsprechende Methoden bei den
Zielklassen.
Alternativ zu den Sequenzdiagrammen können auch Interaktionsübersichtdiagramme,
Kommunikationsdiagramme, Zeitverlaufsdiagramme oder
Aktivitätsdiagramme verwendet werden.
3.3.6.5 Hinweis für die Praxis
Sequenzdiagramme werden zur Modellierung von Interaktionen gewählt, wenn die
Darstellung der Reihenfolge des Nachrichtenaustauschs wichtig ist.
Bevor Sequenzdiagramme modelliert werden können, müssen die an der Szene
beteiligten Klassen identifiziert werden. Hinweise zur Identifikation von Klassen
befinden sich im Kapitel 3.3.1 Klassendiagramm.
Die in Sequenzdiagrammen modellierten Objekte und Nachrichten müssen
konsistent zu den Klassendiagrammen gehalten werden.
Da Sequenzdiagramme dynamische Aspekte eines Systems darstellen, müssen
normalerweise Instanznamen und Klassennamen angegeben werden. Häufig
vernachlässigt man jedoch den Instanznamen und gibt nur den Klassennamen an.
Ein solches anonymes Objekt steht stellvertretend für alle Objekte der Klasse und
impliziert, dass alle Objekte der Klasse sich in der Szene gleich verhalten.
Style Guide
• Objekte sollten so angeordnet werden, dass in einem Diagramm möglichst
wenig Kreuzungen entstehen.

• Nachrichten sollten von links nach rechts zeigen, Returns von rechts nach links.
• Nachrichtennamen sollten an der Spitze der Pfeile stehen.
• Beteiligte Akteure sollten am linken Rand der Diagramme stehen.
• Namen der Akteure sollten konsistent zu den Use Case Diagrammen sein.
• Klassennamen sollten konsistent zu dem Klassendiagramm sein.
Neu in UML 2.0
Folgende Elemente sind in der UML 2.0 neu oder geändert gegenüber UML 1.x:
• Verschachtelung von Diagrammen mittels Referenzen.
• Darstellung der Kontrollstrukturen höherer Programmiersprachen (Verzweigung,
Schleifen ..) mittels kombinierter Fragmente.
• Es wurden zwei neue Nachrichtentypen eingeführt; "lost" und "found", die in
diesem Skript nicht behandelt werden.
3.3.6.6 Beispiel
Sequenzdiagramm der Szene Karte laden
Abbildung 3.3.6.6.1Beispiel Sequenzdiagramm Karte laden
Dieses Sequenzdiagramm modelliert die Szene "Karte laden". Es bezieht sich auf
den Use Case "KarteLaden" des Use Case Diagramms "Mensa".
73

74
Für einige Objekte ist ein Objektnamen angegeben, bei anderen Objekten wurde er
vernachlässigt. Objekte der Klassen "LeseSchreibEinheit" und "Display" tragen
einen Objektnamen, weil sie Teil des Mensaautomaten und der Kasse sind. Zur
Unterscheidung erhielten sie einen Objektnamen. Die Objekte der Klassen "Knopf"
und "GeldEinzug" sind im Modell nur einmal vorhanden, der Objektnamen wurde
deshalb nicht angegeben.
Die Lebenslinien des Display-Objekts und des Karten-Objekts sind nicht bis zum
unteren Rand des Diagramms durchgezogen; dadurch werden Kreuzungen
vermieden, das Diagramm wird übersichtlicher.
Die Nachrichtennamen stehen immer in der Nähe der Pfeilspitzen. Wenn es
möglich war, wurden sie über den Pfeilen angegeben. Dadurch ist die Zuordnung
der Namen eindeutig und das Diagramm ist leicht lesbar.
Auf die Verwendung von kombinierten Fragmenten wurde verzichtet. Das
Diagramm enthält eine Alternative, die durch Notizen an den beiden Nachrichten,
die alternativ gesendet werden, markiert ist.
Der Akteur "Kunde" greift auf das Objekt "mAutomat" der "LeseSchreibEinheit"
zu, indem er die Nachricht "KarteEin(meineKarte)" sendet. Er übergibt über diese
Nachricht den Parameter "meineKarte" an die "LeseSchreibEinheit". Die
"LeseSchreibEinheit" liest die "MensaKarte" und lädt sie in ihren Speicher. Die
"MensaKarte" ist ein passives Objekt (Datenträger). Auf die Verwendung eines
Konstruktoraufrufs wurde verzichtet. Die "MensaKarte" gibt über den Return den
"Betrag" an die "LeseSchreibEinheit" zurück. Diese sendet die Nachricht "zeige"
an das Display und übergibt den "Betrag". Der Kunde kann jetzt zwischen den
markierten Zweigen der Alternative wählen; er kann Geld einlegen oder den Knopf
drücken und die Karte zurückfordern. Es wird jeweils der Zweig des Diagramms
ausgeführt, der den beiden Alternativen folgt.
Über die Nachricht "GeldEin()" wird der Geldeinzug aktiviert. Er zieht den
eingelegten Schein ein und ruft seine eigene Methode "pruefeSchein()" auf. Der
Return gibt TRUE oder FALSE zurück. Ist die Bedingung "[Schein nicht echt]"
erfüllt, ruft der "Geldeinzug" seine eigene Methode "GeldRaus()" auf und gibt den
Schein zurück. Trifft die Bedingung "[Schein echt]" zu, sendet er dem Display die
Nachricht "zeige(Betrag)"; der Betrag wird auf dem Display angezeigt und danach
auf die "MensaKarte" gespeichert. Da mehrere Scheine hintereinander
eingeschoben werden können, kann die entsprechende Sequenz von Nachrichten
mehrfach ausgeführt werden. Dies wurde durch die beiden waagrechten Linien und
dem mit "repeat" bezeichneten Pfeil ausgedrückt. Das kombiniert Fragment loop
wurde wegen der Einfachheit des Diagramms nicht eingesetzt.
Nachdem genügend Scheine eingeschoben wurden, drückt der Kunde auf den
Knopf. Der Knopf teilt dieses Ereignis über die Nachricht "knopfGedrueckt" der
"LeseSchreibEinheit" mit. Diese aktiviert ihre eigene Methode "KarteRaus" und
gibt die Karte wieder aus.

Sequenzdiagramm der Szene Essen zahlen
Abbildung 3.3.6.6.2Beispiel, Sequenzdiagramm Karte laden
76
Dieses Sequenzdiagramm modelliert die Szene "Essen zahlen". Es bezieht sich auf
den Use Case "EssenZahlen" des Use Case Diagramms "Mensa".
Aufgabe: Interpretieren Sie dieses Diagramm.

3.3.7 Kommunikationsdiagramm - Communication Diagram
3.3.7.1 Zweck
In Kommunikationsdiagrammen wird die Interaktion zwischen Objekten
dargestellt. Sie geben die Beziehungen zwischen den Objekten an und die
Nachrichten, die übertragen werden. Dabei steht der Überblick der
Kommunikationsstruktur im Vordergrund.
Die Darstellung der zeitlichen Reihenfolge, in der die Nachrichten gesendet
werden, kann durch eine Nummerierung vorgenommen werden.
3.3.7.2 Notation
Symbol Beschreibung
Objekt
Das Rechteck stellt eine Objekt dar. Es kann einen
Objektnamen und einen Klassenenamen tragen.
Beziehung, Nachricht
Tabelle 7Notation Kommunikationsdiagramm
3.3.7.3 Anwendungsbereich
Die Kommunikationsbeziehungen zwischen Objekten
werden als Linie dargestellt. An die Beziehungen werden
die Nachrichten, die darüber übertragen werden
geschrieben. Die Nummerierung vor den
Nachrichtennamen gibt die zeitliche Reihenfolge der
Nachrichten an. Der Pfeil gibt die Richtung der
Nachrichten an.
Kommunikationsdiagramme stellen den Informationsaustausch zwischen Objekten
dar. Sie können die gesamte Struktur einer Anwendung abbilden oder sich auf
Teile einer Anwendung beziehen. Kommunikationsdiagramme werden für die
selben Zwecke eingesetzt wie Sequenzdiagramme.
3.3.7.4 Zusammenhang
77

78
Da die Kommunikationsdiagramme alternativ zu Sequenz Diagrammen verwendet
werden, sind die selben Zusammenhänge zu berücksichtigen, die unter
Sequenzdiagrammen beschrieben sind.
3.3.7.5 Hinweise für die Praxis
Kommunikationsdiagramme werden dann als Alternative zu Sequenz Diagrammen
verwendet, wenn an einer Szene viele Objekte beteiligt sind, die wenige
Nachrichten austauschen. Sind wenige Objekte an einer Szene beteiligt, die viele
Nachrichten austauschen, sind Sequenz Diagramme wegen der übersichtlicheren
Darstellung der zeitlichen Zusammenhänge vorzuziehen.
Neu in UML 2.0
Der Name der Kommunikationsdiagramme in der UML 2.0 ist neu, die Notation
ist unverändert geblieben. In der UML 1.x wurden diese Diagramme mit dem
Namen Kollaborationsdiagramme, Collaboration diagram bezeichnet.
3.3.7.6 Beispiel
Dieses Kommunikationsdiagramm zeigt die Kommunikation der Objekte, die an
der Szene "EssenZahlen" beteiligt sind. Es macht deutlich, über welche
Kommunikationswege die Objekte Informationen austauschen. Die zeitliche
Reihenfolge ist jedoch in dem entsprechenden Sequenzdiagramm besser zu sehen.
Dass die Nachrichten "essenEin" und KarteEin" parallel erfolgen können, ist in
Kommunikationsdiagrammen nicht darstellbar. Diese Information ist am
übersichtlichsten in dem Aktivitätsdiagramm modellierbar.
Die Nummerierung wurde so gewählt, daß die erste Stelle der Nummer den
"Zweig" angibt und die zweite Stelle die Reihenfolge in einem Zweig. Es wird also
zuerst die Nachricht mit der Nummer 1 und danach 1.1 gesendet. Im unteren Zweig
wird in folgender Reihenfolge kommuniziert: 2, 2.1, 2.2, danach wird entweder
2.3a oder 2.3b gesendet.

Abbildung 3.3.7.6.1Beispiel, Kommunikationsdiagramm Essen zahlen
3.3.8 Zeitverlaufsdiagramm - Timing-Diagram
3.3.8.1 Zweck
Timing-Diagramme stellen das zeitliche Verhalten von Systemelementen
(Classifier z. B. Klassen, Objekte, Komponenten) in einem bestimmten Zeitraum
dar. Es wird damit ausgedrückt, wann ein Objekt seinen Zustand ändert und wie
lange es für eine Aktion benötigt. Werden mehrere Classifier in einem Diagramm
dargestellt, können die Interaktionen zwischen den Classifiern ebenfalls modelliert
werden. Timing Diagramme stammen aus der Elektrotechnik und werden zur
Visualisierung von Signalverläufen eingesetzt.
3.3.8.2 Notation
Die Notation des Zeitverlaufdiagramms ist in dem Beispiel erläutert.
79

80
3.3.8.3 Anwendungsbereich
Timing Diagramme sollten verwendet werden, wenn das zeitliche Verhalten
modularer Systeme spezifiziert wird. Sie eignen sich zur Visualisierung der
Abhängigkeiten zwischen den Modulen.
3.3.8.4 Zusammenhang
Zeitverlaufdiagramme müssen konsistent in einem Modell integriert werden. Die
verwendeten Klassen müssen in dem Klassenmodell existieren. Die Zustände
müssen in den Zustandsdiagrammen der entsprechenden Klassen vorhanden sein.
Die Nachrichten müssen mit den restlichen Interaktionsdiagrammen und den
Klassendiagrammen übereinstimmen.
3.3.8.5 Hinweis für die Praxis
Neu in UML 2.
Timing Diagramme sind neu in der UML 2.0.
3.3.8.6 Beispiel
Das Beispiel modelliert das Laden einer Karte. Die Diagrammelemente sind mit
hellgrauer Schrift bezeichnet. Der obere Bereich enthält die Lebenslinie des
Mensaautomaten, der untere Bereich die Lebenslinie eines Studierenden, der den
Automat benutzt. Auf der y-Achse sind die Zustände der Objekte angegeben, die x-
Achse enthält die Zeitskala. Die Treppenkurve zeigt die Zustandsübergänge und die
Dauer, für die ein Objekt in einem Zustand bleibt. Zwischen den Lebenslinien sind
die Nachrichten, über die die beteiligten Objekte miteinander interagieren
angegeben. Die Zeitbedingung "T

3.3.9 Interaktionsübersicht Diagramm - Interaction Overview Diagram
3.3.9.1 Zweck
Interaktionen können in der UML in verschiedenen Diagrammtypen dargestellt
werden, wie z. B. Sequenzdiagramm, Aktivitätsdiagramm,
Kommunikationsdiagramm, Zeitverlaufsdiagramm. Jedes dieser Diagramme stellt
eine bestimmte Sicht auf ein System oder einen bestimmten Ausschnitt eines
Systems dar. In Interaktionsübersichts Diagrammen können Teildiagramme in
Bezug zueinander gesetzt werden. Das Interaktionsübersicht Diagramm enthält
81

82
Rahmen, die eine Interaktion, bzw. eine Referenz auf ein Interaktionsdiagramm
darstellen. Die Rahmen werden über die aus den Aktivitätsdiagrammen bekannten
Kontrollstrukturen miteinander verknüpft. Interaktionsübersicht Diagramme sind
spezielle Aktivitätsdiagramme, bei den die Aktivitäten durch die Interaktionsrahmen
ersetzt sind.
3.3.9.2 Anwendungsbereich
Interaktionsübersicht Diagramme können zur Modellierung von System mit vielen
Interaktionen verwendet werden. Interaktionsübersicht Diagramme geben eine
Übersicht über das Zusammenspiel von mehreren Interaktionsdiagrammen.
3.3.9.3 Zusammenhang
Da Interaktionsrahmen Referenzen auf andere Interaktionsdiagramme
repräsentieren, müssen die referenzierten Diagramme konsistent gehalten werden.
3.3.9.4 Hinweis für die Praxis
Neu in UML 2.
Interaktionsübersicht Diagramme sind neu in der UML 2.0.
3.3.9.5 Beispiel
Das Beispiel stellt ein Interaktionsübersicht Diagramm dar. Der mit sd bezeichnete
Rahmen enthält ein Sequenzdiagramm. Die beiden mit ref bezeichneten Rahmen
enthalten eine Interaktionsreferenz, werden also in weiteren Diagrammen
verfeinert.

3.3.10 Zustandsautomat-State Machine Diagram
3.3.10.1 Zweck
Zustandsautomaten sind Diagramme zur Spezifikation des Verhaltens von
Classifiern (Elemente). Cassifier können sein: Klassen, Komponenten, Systeme,
Zustandsautomaten beschreiben das Verhalten der Elemente während ihres
Lebenszyklus durch Darstellung der möglichen Zustände und Zustandsübergänge.
Sie zeigen Aktivitäten, die Elemente in den Zuständen ausführen und Ereignisse
und Bedingungen, die Zustandsübergänge verursachen.
Die UML 2.0 unterscheidet state machines, die Verhalten von Systemen oder Systemteilen
beschreiben, und state machines, die Protokolle, die von einem Systemelement
realisiert werden, modellieren. Zustandsautomaten werden häufig zur
Darstellung des Lebenszyklus von Objekten benutzt, können sich aber auch auf
andere Elemente beziehen.
83

84
3.3.10.2 Notation
Da die Notationselemente für Zustandsautomaten sehr komplex sein können,
werden sie hier in zwei Bereichen behandelt: die grundlegenden Konzepte der Zustandsautomaten
werden im Abschnitt Notation - Konzept beschrieben, die weiterführenden
Konzepte werden unter Notation - erweitert dargestellt.
Notation - Konzept
Symbol Beschreibung
Anfangs-, Endzustand (initial state, final state)
geben den Beginn und Ende des Lebenszyklus
eines modellierten Elementes an. Wird ein Objekt
erzeugt, befindet es sich im Anfangszustand, wird
es gelöscht, befindet es sich im Endzustand.
Zustand (state)
Elemente können im Laufe ihrer Existenz eine endliche
Anzahl Zustände einnehmen. Der Zustand
wird als Rechteck mit abgerundeten Ecken dargestellt.
Zustände können einen Namen erhalten. Ein
Zustand kann durch eine waagrechte Linie unterteilt
werden. Unterhalb der Linie können Aktivitäten
und interne Transitionen angegeben werden.
Diese werden in dem Zustand ausgeführt. Die
UML definiert folgende internen Aktivitäten:
entry, exit und do. Die entry-Aktivität wird beim
Eintritt in den Zustand ausgeführt, die exit-
Aktivität vor Verlassen des Zustands. Do-
Aktivitäten werden zwischen entry und exit-
Aktivität ausgeführt und können länger andauern.
Interne Transitionen werden intern ausgeführt,
führen jedoch nicht zu einem Zustandsübergang.
Es kann ein Auslöser (Trigger) angegeben werden,
eine Bedingung (guard), die erfüllte sein muß und
eine Aktivität, die ausgeführt wird.

Symbol Beschreibung
Zustandsübergang (Transition)
Eine Transition ist ein Zustandsübergang von
einem Quellzustand zu einem Zielzustand. Die Beschriftung
gibt den Auslöser (Trigger) an, die Bedingung,
die erfüllt sein muß (guard) und die Aktivität,
die beim Übergang ausgeführt wird. Die
Beschreibungselemente sind optional. Sie können
beliebig kombiniert werden.
Zustand (State)
Der Zustand (state) eines Objekts wird durch die Attributwerte bzw. Daten und die
jeweiligen Verbindungen zu anderen Objekten bestimmt [Balzert, 1999].
Die UML 2.0 unterscheidet drei Zustandstypen:
• einfacher Zustand - simple state
• zusammengesetzter Zustand - composite state
• Unterzustandsautomatenzustand - submachine state
Einfacher Zustand (simple state)
Ein einfacher Zustand hat keine Unterzustände (Regionen oder submachine state
machine). Ein einfacher Zustand kann entry, exit und do-Aktivitäten enthalten und
interne Transitionen. Nach Erreichen eines Zustands wird sofort die entry-Aktivität
ausgeführt. Vor Verlassen des Zustands wird die exit-Aktivität ausgeführt. Die do-
Aktivität wird nach Beendigung der exit-Aktivität ausgeführt.
Zustandsübergang (Transition)
Eine Transition wird durch einen Auslöser (Trigger) verursacht. Der Trigger kann
intern sein oder extern; er kann von dem Objekt kommen, auf das die state
machine sich bezieht, oder von einem anderen Objekt. Für einen Zustandsübergang
kann eine Bedingung (guard) angegeben werden, die erfüllt sein muß, damit die
Transition ausgeführt wird. Bei einer Transition kann ein Objekt eine Aktivität
ausführen, die zu dem Aufruf einer Methode führt.
Einfacher Zustandsautomat
Zustandsautomaten beschreiben den Lebenszyklus von Objekten, können sich aber
auch auf komplexere Elemente beziehen, wie z. B. Komponenten, Subsysteme
oder Use Cases. Sie stellen die Zustände dar, die Objekte, Komponenten usw. im
85

86
Laufe ihrer Existenz annehmen können und sie geben die Zustandsübergänge an,
die möglich sind. Ein Zustandsautomat gibt auch an, in welchem Zustand ein
Objekt auf welche Ereignisse reagiert.
Diese Abbildung stellt einen einfachen Zustandsautomat einer Tür dar. Die Tür
kann die beiden Zustände offen und geschlossen annehmen. Sie reagiert auf die Ereignisse
schliessen und öffnen. In dem Zustand offen kann jedoch nur das Ereignis
schliessen angewandt werden, in dem Zustand geschlossen kann nur das Ereignis
öffnen angewandt werden.
Dieses Beispiel modelliert eine Loginmaske eines Rechners. Sie hat die Zustände
"UserNameEingabe" und "PasswortEingabe". In dem Zustand
"UserNameEingabe" führt sie die Aktivität "ZeichenLesen" aus. Ist die Bedingung
"[Cursor in Feld Passwort]" erfüllt, so wechselt sie zu dem Zustand

"PasswortEingabe". Sobald die Maske den Zustand betritt führt sie die entry-
Aktivität "Echo aus" aus, sie schaltet das Echo aus und zeigt das Passwort nicht auf
dem Bildschirm an. Danach liest sie mit der Aktivität "ZeichenLesen" das Passwort
ein und schaltet bei Verlassen des Zustands mit der exit-Aktivität "Echo an" das
Bildschirmecho wieder ein.
Pseudozustände
Symbol Beschreibung
Region (Region)
Regionen können in zusammengesetzten Zuständen
und in state machine Diagrammen verwendet
werden. Sie stellen parallele Abläufe oder parallele
Zustände dar. Regionen können einen Namen
haben. Die Regionen in einem Zustand werden
durch eine gestrichelte Linie voneinander
abgegrenzt. Regionen können Zustände und
Transitionen enthalten.
sind Knoten in einem Zustandsdiagramm, die es erlauben komplexe Zusammenhänge
zwischen Zuständen darzustellen (z. B. Verzweigungen, Parallelität usw.).
Pseudozuständen werden keine Aktivitäten zugeordnet. Die Erläuterung der Pseudozustände
erfolgt in der nächsten Version des Skriptes.
Entscheidung
Kreuzung
Terminator
Eintrittspunkt
Austrittspunkt
87

88
Symbol Beschreibung
Gabelung
Vereinigung
Flache Historie
Tiefe Historie
Zusammengesetzter Zustand (composite state)
Ein zusammengesetzter Zustand ist ein Zustand, in dem Unterzustände möglich
sind. Das Beispiel stellt die Zustände einer abschließbaren Tür dar. Die Tür kann
die Zustände zugeschlossen und aufgeschlossen haben. Nur in dem Zustand aufge-

schlossen kann sie die Unterzustände offen und geschlossen haben. Ist das untergeordnete
Zustandsdiagramm zu groß um im Zustand dargestellt zu werden, kann es
auch in einem Verfeinerungsdiagramm modelliert werden.
Unterzustandsautomatenzustand (submachine state)
Der Unterzustandsautomatenzustand ist ein gutes Beispiel für unverständliche
Wortungetüme, die die deutsche Sprache hervorbringen kann. Der Submachine
State bezeichnet einen Zustand, der Unterzustände enthält, die in einem
untergeordneten Zustandsdiagramm verfeinert sind. Im Zustandssymbol wird der
Zustandsnamen angegeben und mit Doppelpunkt getrennt der Zustandsautomat,
der ihn verfeinert.
3.3.10.3 Anwendungsbereich
Zustandsdiagramme werden häufig im Bereich Embedded Systems eingesetzt, sind
aber auch in anderen Bereichen verwendbar. Sie werden nur für Klassen mit nicht
trivialemem (interessantem) Lebenszyklus modelliert. Ein trivialer Lebenszyklus
ist dann vorhanden, wenn ein Zustandsdiagramm nicht zum besseren Verständnis
des Verhaltens des Objektes beiträgt. Nicht triviale Lebenszykeln von Objekten
liegen dann vor, wenn die Objekte "viele" Zustände haben und in den einzelnen
Zuständen nur auf eine bestimmte Art und Weise auf eingehende Nachrichten reagieren
können.
3.3.10.4 Zusammenhang
Ein Zustandsdiagramm kann sich auf eine Klasse des Klassendiagramms beziehen.
Es kann aber auch die Zustände von komplexeren Modellelementen (Subsystemen)
darstellen. Die Nachrichten auf die eine Klasse mit einem Zustandsübergang reagiert,
werden von anderen Klassen oder Akteuren gesendet.
3.3.10.5 Hinweis für die Praxis
Zustandsautomaten sollten nur bei komplexen Objekten verwendet werden. Ein
Objekt ist dann komplex, wenn es viele Methoden oder viele Attribute hat. Bei
einfach strukturierten Objekten bringt der Einsatz von Zustandsautomaten keine
89

90
zusätzlichen Erkenntnisse. Jeder Zustand und Pseudozustand, außer dem Anfangsund
Endzustand, sollte mindestens einen ein- und eine ausfließende Transition
haben.
Style Guide
Zustandsdiagramme sollten so gestaltet werden, dass sie von links oben nach rechts
unten lesbar sind. Zustand sollte aus- und einfliessende Pfeile haben, jeder Zustand
muß erreichbar sein und wieder verlassen werden können.
Neu in UML 2.
Der Name State Machine Diagram ist in der UML 2.0 neu. In früheren Versionen
der UML wurden dieser Diagrammtyp Zustandsübergangsdiagramme, State Diagram
oder State Transition Diagram genannt. Diese Bezeichnungen werden heute
immer noch verwendet.
3.3.10.6 Beispiel
Der Mensaautomat hat die Zustände bereit, KarteCheck, GeldFordernd,
GeldEinzug und LadeKarte. Nach dem Aktivieren befindet er sich in dem Zustand
bereit. Diesen Zustand verläßt er, wenn das externe Ereignis KarteEin auf ihn
einwirkt. Er führt die Transition zu dem Zustand KarteCheck durch. In diesem
Zustand liest er über die Aktivität lies die Mensakarte. Ist die Karte in Ordnung
(Bedingung Karte = OK), führt er die Aktivität zeige aus und zeigt den Betrag an.
Er wechselt den Zustand zu GeldFordernd. Trifft die Bedingung Karte = !OK zu,
führt er die Aktivität KarteRaus aus und geht zurück in den Zustand bereit. Das
externe Ereignis druecken() (des Rückgabeknopfes) veranlaßt den Automat zur
Zustandsänderung von GeldFordernd zu bereit; er gibt die Karte zurück. In dem
Zustand GeldFordernd reagiert der Mensaautomat außerdem noch auf das Ereignis
GeldEin; es führt zu der Transition zu GeldEinzug. Dort wird zuerst die entry-
Aktivität pruefeSchein ausgeführt, danach zeigt die Aktivität zeige den aktuellen
Geldbetrag an. Das Ereignis GeldEin führt zu einer rekursiven Transition; der
Kunde kann mehrere Geldscheine einschieben. Das Ereignis druecken führt zu der
Transition zu LadeKarte, die Aktivität schreibe schreibt den aktuellen Geldbetrag
auf die Karte. Die Karte wird herausgeschoben und der Automat wechselt in den
Zustand bereit.

3.3.11 Aktivitätsdiagramm - Activity Diagram
3.3.11.1 Zweck
Aktivitätsdiagramme sind Diagramme zur Flussmodellierung. Sie stellen die Aktivitäten
eines Systems dar, die Aktionen, aus den die Aktivitäten sich zusammensetzen
und den Fluss durch die Aktivitäten.
Mit Aktivitätsdiagrammen können komplexe Abläufe in einem System modelliert
werden (Geschäftsprozesse, Workflows).
Da Aktivitäten aus Aktionen und deren zeitlicher Verknüpfung bestehen, können
sie auch zur Modellierung der internen Logik komplexer Operationen verwendet
werden und somit Algorithmen visualisieren.
91

92
Aktivitätsdiagramme können in Verantwortungsbereiche gegliedert werden. Damit
können die Aktionen bestimmten Modellelementen, wie Klassen oder
Komponenten zugeordnet werden.
3.3.11.2 Notation
Symbol Beschreibung
Aktivität (Activity)
Eine Aktivität besteht aus Knoten (Aktivitäten,
Aktionen, Kontroll- und Objektknoten) und
Kanten (Pfeilen), die den Kontrollfluss durch
die Aktivität darstellen. Die Aktivität wird als
abgerundetes Rechteck dargestellt. In der linken,
oberen Ecke steht der Name der Aktivität,
gefolgt vom Eingangsparameter und Typ. Die
Rechtecke an beiden Seiten geben die Eingangs-
bzw. Ausgangsparameter an. Die Symbole
in der Aktivität stellen die Aktionen dar
und die Pfeile den Kontrollfluss.
Aktion (Action)
Eine Aktion ist in UML das Basiselement zur
Spezifikation von Verhalten. Eine Aktion kann
als nicht weiter zerlegbare Funktion angesehen
werden. Sie transformiert eine Eingabe zu einer
Ausgabe. Aktionen sind in Aktivitäten enthalten.
Die UML 2.0 unterscheidet verschiedene
Typen von Aktionen.
Signal (Send signal action, Accept event action)
Mit diesen Symbolen kann das Senden und
Empfangen von Signalen dargestellt werden.
Zeitereignis (Accept time event action)
Über diese Symbol wird ausgedrückt, dass eine
Aktion zeitgesteuert angestoßen wird.
Kontrollknoten
werden benutzt um Kontrollstrukturen in einem
Flussgraph anzugeben.

Symbol Beschreibung
Entscheidung und Zusammenführung
Bei der Entscheidung wird nach Eintreffen des
Tokens a entweder nach b oder nach c
verzweigt. Die Bedingung, die erfüllt sein muss,
kann als Ausdruck in eckigen Klammern an den
Pfeilen angegeben werden.
Bei der Zusammenführung wird nach Eintreffen
der Token a oder b nach c verzweigt.
Splitting, Synchronisation
Bei einem Splitting-Knoten wird in mehrere
parallele Threads verzweigt (wenn a da ist, feuern
b und c). Ein Synchronisationsknoten synchronisiert
mehrere Threads (wenn a und b da
sind, feuert c).
Start-, Endknoten, Ablaufende
Ein Startknoten (Initial Node) stellt den Beginn
eines Ablaufes dar. Ein Endknoten (Activity
Final Node) beendet eine Aktivität vollständig.
Ein Ablaufende (Flow Final Node) terminiert
einen Zweig einer Aktivität, die Aktivität selbst
läuft weiter.
Pfeil/Kante
Ein Pfeil beschreibt den Fluss zwischen den
verbundenen Elementen. In einer eckigen
Klammer kann eine Bedingung angegeben
werden, die erfüllt sein muss, damit die Kante
überquert wird.
Objektknoten
können in Aktivitätsdiagrammen Objekte oder
Daten repräsentieren. Sie können als unabhängige
Knoten in einem Diagramm benutzt
werden, bzw. als Parameter für Aktionen (Input,
Output Pin). Beide Darstellungen sind
äquivalent. Im Bild oben ist a als Objekt eingezeichnet;
im unteren Bild ist a Ausgangsparameter
der linken Aktion und Eingangsparameter
der rechten.
93

94
Symbol Beschreibung
Kanten
Tabelle 8Notation Aktivitätsdiagramm
Prinzip der Aktivitätsdiagramme
verbinden die Aktionen in einem Diagramm
und stellen den Fluss dar. Kanten, die Kontrollfluss
modellieren, verbinden Aktionen direkt;
Objektflusskanten verbinden die Pins der beteiligten
Aktionen.
Aktivitätsdiagramme zeigen den Ablauf von Aktivitäten. Sie definieren die Aktionen,
aus den sich Aktivitäten zusammensetzen und die zeitliche Reihenfolge ihrer
Ausführung. Verzweigungen des Kontrollflusses und gleichzeitig ablaufende,
parallele Zweige sind möglich. Um die ausgeführten Aktionen verfolgen zu
können, werden die Zweige eines Aktivitätsdiagramms mit Tokens belegt. Ein Token
ist eine Marke, die den Kontrollfluss markiert. In jedem Thread existiert ein
Token. Tokens besitzen kein Symbol in der UML. Sie sind virtuelle Elemente, die
den Kontrollfluss markieren.
Abbildung 3.3.11.2.1Beispiel Token in Aktivitätsdiagrammen
In Abbildung 3.3.11.2.1 ist das Prinzip des Token-Modells dargestellt. Nachdem
der Ablauf gestartet wurde, wird das erste Token, links im Bild, erzeugt. Danach
wird die Aktion a1 ausgeführt und das Token auf den Ausgang von a1 gelegt.
Durch die Verzweigung in die beiden Threads p1 und p2 wird am Anfang beider
Threads je ein Token gesetzt. Die Aktionen p1 und p2 werden ausgeführt; die
Tokens werden auf die Ausgänge von p1 und p2 gelegt. Wenn beide Tokens da
sind, wird das Eingangstoken für a2 gestartet. A2 wird ausgeführt, das Token auf
den Ausgang von a2 gelegt, die Aktivität wird beendet und das Token vernichtet.
Aktionstypen
Die UML 2.0 definiert verschiedene Typen von Aktionen, die für bestimmte Zwecke
verwendet werden können, z. B. Aktionen zum
• Erzeugen, Löschen von Objekten

• Lesen und Schreiben von Attributwerten
• Aufrufen von Operationen
• Empfangen und Senden von Signalen
• u. a.
Verantwortungsbereiche (Partitions)
Aktivitäten können komplexe Abläufe darstellen, die durch unterschiedliche
Modellelemente ausgeführt werden, bzw. für die unterschiedliche Elemente
verantwortlich sind. Zur Zuordnung der Aktionen einer Aktivität zu den verantwortlichen
Elementen können Aktivitätsdiagramme in Partitionen (Activity Partition)
unterteilt werden. Da ein entsprechend aufgeteiltes Diagramm wie eine in
Schwimmbahnen eingeteiltes Schwimmbecken aussieht, werden die Activity
Partitions auch swimlanes genannt.
Abbildung 3.3.11.2.2Verantwortungsbereiche in Aktivitätsdiagrammen
In Abbildung 3.3.6.2.2 ist das Aktivitätsdiagramm in die Bereiche Partition 1 und
Partition 2 unterteilt. Die Aktionen a1 und a3 gehören zu der Partition 1; die
Aktion 2 gehört zu der Partition 2. Partitionen können senkrecht und waagrecht
angelegt werden.
Verfeinern von Aktivitäten
95

96
Abbildung 3.3.11.2.3Verfeinern von Aktivitäten
Aktivitäten können in weiteren Aktivitätsdiagrammen verfeinert werden. Das zu
verfeinernde Element wird mit einem Gabelsymbol gekennzeichnet und kann in
einem Unterdiagramm verfeinert werden. So können Hierarchien von Aktivitätsdiagrammen
modelliert werden. Alle Aktivitäten sind auf der untersten
Hierarchieebene auf Aktionen abzubilden.
3.3.11.3 Anwendungsbereich
Aktivitätsdiagramme werden zur Modellierung von Abläufen und deren Steuerung
benutzt. In Aktivitätsdiagrammen werden die einzelnen Verfahrensschritte von
Aktivitäten und die Reihenfolge in der sie ausgeführt werden dargestellt. Sie
können von der Modellierung von Geschäftsprozessen bis zur Visualisierung von
Kontrollflüssen benutzt werden. Eine Aktivität setzt sich aus den Aktionen zusammen,
die im Aktivitätsdiagramm enthalten sind.
Aktivitätsdiagramme können in einem Projekt überall verwendet werden, wo
Verhalten beschrieben werden muss, bzw. wo Datenflüsse oder Kontrollflüsse
modelliert werden sollen.
3.3.11.4 Zusammenhang
Da Aktivitätsdiagramme sehr vielfältig einsetzbar sind, können vielfältige Beziehungen
zwischen Aktivitätsdiagrammen und anderen Diagrammen der UML bestehen.

Aktivitätsdiagramme können die Abläufe von Anwendungsfällen aus Use Case
Modellen beschreiben. Sie können verwendet werden, um z. B. den Ablauf eines
Geschäftsprozesses, der einem Use Case zugeordnet ist, zu modellieren. Es ist
aber auch möglich, dass mehrere Aktivitätsdiagramme den Ablauf eines Use Cases
modellieren; in einem Aktivitätsdiagramm könnte das Normalverhalten eines Use
Case modelliert werden in einem weiteren könnte eine Alternative zum Normalverhalten
beschrieben werden.
Da die Darstellung der Kontrollstrukturen höherer Programmiersprachen in der
Notation der Aktivitätsdiagramme enthalten ist, können sie auch zur Spezifikation
von Algorithmen verwendet werden.
Aktivitätsdiagramme müssen mit den anderen Diagrammen in einem Projekt
konsistent gehalten werden. Aktionen können Operationen bei den Klassen eines
Modells erfordern.
3.3.11.5 Hinweise für die Praxis
Style Guide
• Diagramme sollten übersichtlich angeordnet werden. Kannten zwischen den
Knoten sollten möglichst kreuzungsfrei sein.
• Besonders wenn Aktivitätsdiagramme mit Verantwortungsbereichen gezeichnet
werden, entstehen große Diagramme. Zur Integration der Diagramme in einer
Projektdokumentation sollte das Ausgabeformat (DIN A 4) berücksichtigt
werden. Es kann sinnvoll sein große Diagramme über mehrere Seiten zu
zerlegen und diese über Konnektoren miteinander zu verbinden.
• Bei Entscheidungsknoten sollten die Bedingungen in der Nähe des Konnektors
angegeben werden.
• Entscheidungsknoten sollten einen Bezug zur Aktion haben, der sie nachfolgen.
• Start- und Endknoten sollten angegeben werden, um unmissverständlich Beginn
und Ende einer Aktivität zu dokumentieren.
• Die Pfeilspitzen sollten so angeordnet werden, dass Diagramme von oben nach
unten und von links nach rechts lesbar sind.
Neu in UML 2.0
Die Aktivitätsdiagramme in UML 2.0 erfuhren die größten Veränderungen gegenüber
der UML 1.x.
In der UML 1.x waren die Aktivitätsdiagramme eine spezielle Form der Zustandsdiagramme.
In der UML 2.0 sind die Aktivitätsdiagramme eigenständig.
Einige Begriffe der UML 1.x wurden weiterverwendet, bekamen aber eine vollständig
neue Bedeutung. Ein Aktivitätsdiagramm in UML 2.0 beschreibt eine Ak-
97

98
tivität, die Teilschritte werden Aktionen genannt. In der UML 1.x wurden die Teilschritte
eines Aktivitätsdiagramms Aktivitäten genannt; die Aktivitäten der UML
1.x heißen jetzt Aktionen, das Aktivitätsdiagramm von UML 1.x heißt jetzt Aktivität.
Aktivitätsmodelle haben jetzt eine starke Ähnlichkeit zu Petrinetzen.
Ein Aktivitätsdiagramm darf mehrere Anfangszustände haben.
Signale, Zeitereignis und das Ablaufende wurden als neue Notationselemente eingeführt.
Zur Darstellung von Objektflüssen können die "fließenden" Objekte als
Objektknoten angegeben werden.
Aktivitätsdiagramme dürfen Ein- und Ausgabeparameter enthalten.
3.3.11.6 Beispiel
Bei der Modellierung des Beispiels wurden folgende Annahmen getroffen:
Die Diagramme modellieren jeweils einen Geschäftsprozess zu einem Use Case.
Zur Darstellung der externen Ereignisse, die auf die Aktivitäten einwirken, sind die
Akteure, die diese auslösen in den Diagrammen enthalten. Sie sind mit einer
gerichteten Kante mit der Aktion, auf die sie zugreifen, verbunden.
Die Diagramme zeigen den Kontrollfluss, keinen Daten- oder Objektfluss.
Aktivitätsdiagramm EssenZahlen

Abbildung 3.3.11.6.1Beispiel Aktivitätsdiagramm Essen zahlen
Hier wurden Verantwortungsbereiche angegeben. Das Diagramm hat zwei Startpunkte,
da die Aktionen "Essen eintippen" und "Karte einschieben" parallel erfolgen
können. Die beiden Zweige werden auf dm folgenden Synchronisationsknoten
miteinander synchronisiert.
Aktivitätsdiagramm KarteLaden
Das Diagramm in Abbildung 3.3.6.6.2 wurde ohne Verantwortungbereiche
modelliert.
99

Abbildung 3.3.11.6.2Beispiel Aktivitätsdiagramm Karte laden
3.3.12 Verteilungsdiagramm - Deployment-Diagram
100
3.3.12.1 Zweck

Das Verteilungsdiagramm stellt die physikalische Struktur eines Systems dar. Es
gibt die Zuordnung von Softwarekomponenten zu den ausführenden Hardwareeinheiten
(Knoten) zur Laufzeit an und beschreibt die Kommunikation
zwischen den Knoten über Kommunikationspfade.
3.3.12.2 Notation
Symbol Beschreibung
3.3.12.3 Beispiel
Knoten (Node)
Ein Knoten ist eine Ressource auf der Artefakte bereitgestellt
und ausgeführt werden. Es kann z. B. ein Server sein.
Knoten können geschachtelt sein. Es werden die
Knotentypen Gerät (device) und Ausführungsumgebung
(execution environment) unterschieden.
Artefakt (Artifact)
Ein Artefakt ist das Ergebnis oder Produkt einer Entwicklertätigkeit.
Ein Artefakt kann z. B. sein: ein Modellelement,
eine Softwarekomponente, eine Quellcodedatei, eine
Binärdatei, eine DB-Tabelle, usw.
Kommunikationspfad (communication path)
Ein Kommunikationspfad ist eine Assoziationsbeziehung
zwischen Knoten. Über Kommunikationspfade können
Knoten Nachrichten austauschen. Kommunikationspfade
werden als Linien zwischen Knoten dargestellt und können
bezeichnet werden. Kommunikationspfade können
ungerichtet oder gerichtet sein. Gerichtete Beziehungen
werden mit einem Pfeil angegeben.
Das Beispiel zeigt die Hardwarestruktur des Beispiels Mensaautomat. Es besteht
aus den Geräten Mensaautomat, Kasse und dem Mensaserver. Den Geräten sind
die Softwarekomponenten zugeordnet, die darauf installiert sind.
101

102
3.3.13 Kompositionsstrukturdiagramm - Composite Structure Diagram
3.3.13.1 Zweck
Das Kompositionsstrukturdiagramm beschreibt die interne Struktur eines
Classifiers und seine Interaktionsbeziehungen zu anderen Systemteilen. Es zeigt
wie die Teile eines Classifiers den Classifier selbst bilden. Da es mit dem
Kompositionsstrukturdiagramm möglich ist die Teile (Architekturelemente) eines
Systems und ihre Beziehungen darzustellen, wird es auch Architekturdiagramm
genannt. Das Kompositionsstrukturdiagramm eignet sich ebenfalls zur
Modellierung von Entwurfsmustern.
3.3.13.2 Notation
Symbol Beschreibung
Teil (Part)
Ein Part ist eine Laufzeitinstanz einer Klasse oder
Schnittstelle. Parts werden verwendet um
Kompositionsstrukturen oder Entwurfsmuster
darzustellen. Parts können Eigenschaften von
Klassen sein, d. h. sie können in der Klasse
enthalten sein.

Symbol Beschreibung
3.3.13.3 Anwendungsbereich
Kollaboration (Collaboration)
Eine Kollaboration beschreibt die Struktur von
zusammenarbeitenden Elementen, die gemeinsam
das Gesamtverhalten der Kollaboration
beschreiben. Die Kollaboration wird mit einem
Namen bezeichnet. Die enthaltenen Elemente
können in der Kollaboration angegeben werden,
oder in einem weiteren
Kompositionsstrukturdiagramm modelliert
werden. Die Linie, die Part1 und Part2 verbindet
ist ein Konnektor. Konnektoren werden
verwendet um Kommunikationsbeziehungen
zwischen Instanzen darzustellen.
Kompositionsstrukturdiagramme können in frühen Projektphasen zur
Modellierung von Systemteilen und deren Zusammenhängen eingesetzt werden.
Sie können noch relativ abstrakte Modellelemente enthalten, ohne bis zur
Detaillierungsebene von Klassendiagrammen ausmodelliert zu werden.
Die verwendeten Strukturelemente können schrittweise verfeinert werden.
3.3.13.4 Neu in UML 2.
Kompositionsstrukturdiagramme sind neu in der UML 2.0.
3.4 Object Constraint Language
UML-Diagramme, wie z. B. Klassendiagramme drücken meistens nicht alle
Aspekte eines Softwaresystems aus. Zusätzliche Bedingungen werden in
natürlicher Sprache formuliert. Sie sind häufig nicht eindeutig und enthalten
Widersprüche. Um diese Fehlerquellen zu beseitigen, wurde die Object Constraint
Language definiert. Die OCL ist eine formale Sprache zur Beschreibung von
103

104
Constraints (Bedingungen, Einschränkungen) in UML-Modellen. Ein Constraint ist
eine Bedingung oder Einschränkung, die für Modellelemente definiert wird.
Die Constraints können z. B. zur Beschreibung folgender Eigenschaften verwendet
werden:
• Definition von Zusicherungen über Zusammenhänge zwischen
Modellelementen, bzw. Einschränkungen,
• Definition von Vor- und Nachbedingungen,
• Voraussetzungen für die Ausführung von Operationen,
• Zusicherungen von Ergebnissen, die Operationen liefern,
• Invarianten,
• Navigation in Uml-Modellen (query-language).
Ein Beispiel zu einem Constraint findet sich in dem Kapitel 3.3 Diagramme der
UML auf Seite 39.
3.5 Model Driven Architecture
3.5.1 Was ist MDA?
Die Model Driven Architecture ist ein offener, herstellerunabhängiger Standard zur
Modellierung von Werkzeug-unabhängigen Anwendungen. Er verfolgt das Ziel
Modelle unabhängig von der aktuellen Implementierungstechnologie zu
beschreiben und sie somit als Basis der Weiterentwicklung von Systemen zu
nutzen, unabhängig von der sich schnell weiterentwickelnden
Implementierungstechnologie. MDA trennt die Geschäftslogik von der
Implementierungstechnologie und definiert dafür zwei Modelle:
• PIM- Platform-Independent Model
• PSM-Platform-Specific Model.
3.5.2 Motivation
Software lebt; sie lebt in manchen Geschäftsbereichen sehr lange. In dem
Bankbereich sind Anwendungen im Einsatz, die in so antiken

Programmiersprachen wie Cobol oder PLI geschrieben wurden. Die
Implementierungstechnologie ist vielfältig und entwickelt sich sehr schnell weiter.
Daraus ergibt sich eine Diskrepanz zwischen der Lebenszeit der fachlichen
Modellen, die der Software zugrundeliegen und der aktuellen
Implementierungstechnologie. Modelle können nicht oder nur schwer an neue
Implementierungstechnologie angepaßt werden, obwohl die fachlichen Modelle
weiterhin gültig sind. Diese Probleme motivierten die OMG zur Definition der
MDA. Das Ziel der MDA ist die Verbesserung der Wiederverwendbarkeit von
Modellen. Dies soll durch die Trennung von dem fachlichen Modell und der
Implementierungsplattform erreicht werden. Firmen soll die Investition in
langlebige Modelle, statt in Code ermöglicht werden.
3.5.3 Wie funktioniert MDA?
Das Prinzip der MDA ist die Plattformunabhängigkeit von Software-Modellen.
Das Plattformunabhängige Modell wird in der MDA PIM, Platform Independent
Model genannt. Alle fachlichen und funktionalen Aspekte der Software werden im
PIM beschrieben. Die Beschreibung erfolgt mit Standards, wie UML, OCL und
XMI.
Das PIM wird über ein Standardmapping auf ein oder mehrere PSM, Platform
Specific Model abgebildet. Hier wird das Softwaremodell auf ein Zielsystem, wie
Corba, EJB transformiert. Dieser Schritt erfolgt automatisch über das MDA-Tool.
Generiert werden alle für die Zielplattform benötigten Elemente, wie z. B.:
• Platform Interfaces,
• fachlicher Code,
• deployment descriptor,
105

106
• DB-Schema.
Das PSM beschreibt die Anwendung mit den Mitteln der Implementierungstechnologie.
Aus dem PSM wird der Plattformspezifische Code
generiert.
3.6 UML Profile
UML-Profile sind ein Erweiterungsmechanismus der UML. Sie werden verwendet,
um die Regeln des UML-Metamodells zu erweitern oder einzuschränken. Dafür
stehen in der UML folgende Konstrukte zur Verfügung:
• Stereotypen,
• Tagged values (Eigenschaftswerte),
• in OCL formulierte constraints.
Eine konkrete Anpassung der UML an eigene, bestimmte Zwecke (mit Hilfe der o.
g. Konstrukte) wird Profile genannt. Über Profile können also Modelle
vorkonfiguriert werden; die Regeln der UML können an eigene Zwecke angepaßt
werden.
Die OMG liefert viele vordefinierte Profile, wie z. B.:
• UML Profile for Corba
• UML Profile for Enterprise Application Integration (EAI)
• UML Testing Profile

4 Vorgehens- und Prozessmodelle
4.1 Überblick (Motivation, Begriffe)
Oft steht der Projektleiter am Anfang eines Softwareentwicklungsprojektes vor der
zentralen Frage, welches Vorgehen das Beste für sein Projekt ist. In der Vorlesung
Softwaretechnik wird vorrangig die objektorientierte Vorgehensweise dargestellt.
Dies hat Auswirkungen auf das Projektmanagement. Einige wichtige Aspekte
werden im Abschnitt 4.2 erläutert. In den nachfolgenden Abschnitten werden
verschiedene Vorgehens- und Prozessmodelle vorgestellt, die in heutigen
Entwicklungsprojekten eine wesentliche Rolle spielen.
Im Abschnitt 4.3 werden das Wasserfallmodell sowie die evolutionären und
inkrementellen Ansätze dargestellt und deren Vor- und Nachteile genannt. Viele
Projekte basieren nach wie vor auf einem Wasserfallmodell trotz der Einsicht, dass
bei Wasserfallmodelle Risiken oft zu einem (zu) späten Zeitpunkt erkannt und
Anforderungen schlecht in einer späten Phase berücksichtigt werden können. Um
Risiken möglichst früh bewerten und evtl. ausschließen zu können, ist die
Entwicklung eines Prototyps ein mögliches Mittel. Im Abschnitt 4.4 werden die
verschiedenen Klassifizierungsmerkmale von Prototypen herausgearbeitet und der
generelle Aufbau von Prototypen dargestellt.
Sogenannte schwergewichtige Prozessmodelle versuchen, ein möglichst
vollständiges Rahmenwerk der Softwareentwicklung für die verschiedenen
Projekttypen bereitzustellen. Im Kapitel 4.5 wird das V-Modell vorgestellt, das
sowohl bei Behörden als auch in der Industrie eingesetzt wird. Ein anderes
schwergewichtiges Modell ist der RUP (Rational Unified Process). Der RUP (s.
Abschnitt 4.6) beschreibt ein Vorgehensmodell auf Basis von sog. "Best Practices",
die erwiesenermaßen bei erfolgreichen Projekten zum Einsatz kommen. Diese
umfassen im Einzelnen die iterative Entwicklung von Software, das Management
von Anforderungen, die Nutzung komponentenbasierter Architekturen, die visuelle
Modellierung der Software, die Verifikation der Software-Qualität und der
Etablierung eines Änderungsmanagements.
Im Abschnitt 4.7 wird ein agiles (leichtgewichtiges) Vorgehensmodell beschrieben,
das die Programmentwicklung bzw. das Codieren in den Kern der Betrachtungen
rückt. Dieses Modell wird XP (eXtreme Programming) genannt und kann in
kleinere Projekten eingesetzt werden.
Ziel eines jeden Projektes sollte die Entwicklung eines qualitativ hochwertigen
Softwareproduktes sein. Der letzte Abschnitt in diesem Kapitel ist daher dem
Thema "prozessorientiertes Software-Qualitätsmanagement" gewidmet. Eine
zentrale Erkenntnis ist hierbei, dass die Produktqualität von der Prozessqualität
bestimmt wird. Seit den 80er Jahren werden an verschiedenen Stellen an der
Entwicklung von Standardmodellen für gute Software-Entwicklungsprozesse
107

108
gearbeitet. Die wichtigsten Standards (ISO 9000-Standards, insbesondere ISO
9000-3 für die Software –Entwicklung, ISO 12207, ISO 15504 (SPICE- Standard)
und CMM/CMMI) werden im Abschnitt 4.8 ausführlich beschrieben.
4.2 Das objektorientierte Projekt
Die Leitung eines Projektes ist grundsätzlich eine schwierige Aufgabe. Dies
resultiert letztlich auf der Kollision zwischen Wünschen, festgelegten Terminen
und vorhandenem Budget. Die objektorientierte Softwareentwicklung kann
zusätzliche Risiken hervorbringen und erfordert daher zusätzliche Anstrengungen
im Bezug auf das Projektmanagement. Im Folgenden werden wesentliche Aspekte
kurz benannt.
Der Einstieg in die Objektorientierung ist eine große Umstellung in allen Belangen
eines Projektes (z. B. in Bezug auf erforderliches Know-How, Projektorganisation
und Steuerung). Oft fehlt es an erfahrenen Projektmitarbeitern, die bereits
Probleme in früheren Projekten gelöst haben und so durch Ihr Know-How
Fehlentwicklungen entgegensteuern können. Der Einsatz von objektorientierter
Technologie ist alleine keine Gewähr dafür, dass eine Software den Ansprüchen
des Kunden genügt. Es gibt durchaus Szenarien, in denen der Einsatz von
Objekttechnologie eindeutig Nachteile mit sich bringt (z. B. Performance-Verlust
bei Batch-Verarbeitung auf dem Mainframe oder bei Anwendungen im Bereich
"Parallel Computing").
Objektorientierte Entwicklung erfordert den Einsatz von modernen
Programmiersprachen und Entwicklungswerkzeugen. Die Menge an neuen
Verfahren/Methoden und Regeln verursachen in der Regel neue Risiken, die
intensiver verfolgt werden müssen und ein ausgereiftes Risikomanagement
erfordern. Zum Teil müssen auch vorhandene Werkzeuge und Verfahren, die seit
vielen Jahren erfolgreich in einem Unternehmen eingesetzt werden, an die neuen
Entwicklungsprozesse angepasst werden.
Iterative und inkrementelle Entwicklung bei objektorientierten Projekten erfordert
ein kompetentes Projektmanagement (z. B. Aufwandsschätzung, Ressourcen-
Planung, Meilensteinplanung, "politische Aspekte"). Projektleiter stehen daher oft
zwischen den Stühlen. Der Lenkungsausschuss fordert einsatzbereite Software mit
eingeschränktem Budget in vorgegebener Zeit und die Projektmitglieder benötigen
ein gutes Umfeld sowie eine ausgereifte Entwicklungsplattform, um die gesteckten
Ziele zu erreichen. Objektorientierte Projekte sind oft teurer als vergleichsweise
prozedural entwickelte Anwendungen. Dies liegt insbesondere an dem
notwendigen Einsatz von vergleichsweise teuren Werkzeugen und Berater,
benötigter Schulung für die Entwickler und Komplexität des neuen
Programmiermodells (z. B. Abstraktion, Wiederverwendbarkeit, Kapselung,
Vererbung). In der Objektorientierung gibt es viele Ansätze ein Problem zu lösen

und viele Ansätze eine Problemlösung zu formulieren. Dagegen gibt es je nach
Anwendungsszenario noch nicht genügend publizierte Standardlösungen. Daher
muß zusätzliche Zeit aufgewendet werden, um evtl. Eigenentwicklungen
vorzunehmen oder eigene Tools für die Werkzeugintegration zu entwickeln.
Der Erfolg von objektorientierten Projekten hängt im besonderen Maße auch von
der Projektkultur ab (z. B. Offenheit, Kommunikationsformen, Führungsstil).
Projektleiter, die kein offenes Ohr für Entwickler haben, verlieren schnell den
Bezug zur Realität und den aktuellen Problemen. Vorgehensmodelle, die in den
nachfolgenden Abschnitten beschrieben werden, geben Orientierungshilfe für alle
Projektmitarbeiter aber auch viele Freiheitsgrade. Wie in traditionellen Projekten
auch sind viele Einzelentscheidungen zu treffen. Patentrezepte gibt es nicht! Trotz
der genannten Probleme stellt die objektorientierte Softwareentwicklung eine
wichtige Säule bei heutigen Projekten dar und wird in den nächsten Jahren weiter
an Bedeutung gewinnen.
4.3 Wasserfallmodell, Evolutionäres Modell, Iteratives Modell
Wasserfallmodell
Im Wasserfallmodell wird Software von der ersten Idee zur Erstellung eines
Softwaresystems bis zur Einführung und Wartung des Systems in sukzessiven
Stufen entwickelt. In der Urform waren keine Rücksprünge möglich, man hat
jedoch schnell bemerkt, dass diese strenge Vorgehensweise nicht durchgehalten
werden kann. Bei der Entwicklung kann in einer Phase festgestellt werden, dass
einige Vorgaben der vorhergehenden Phase gar nicht oder nicht im vertretbaren
Zeit- und Kostenrahmen durchführbar sind. In diesem Fall müssen Rücksprünge in
zeitlich früher liegende Phasen möglich sein. Als Beispiel sei hier ein
Phasenmodell von Frick [Frick95] verwendet. Die Rechtecke stellen die Phase dar,
die Pfeile den Informations- und Kontrollfluss zwischen den Phasen. Die Phasen
werden sequentiell durchlaufen. Am Ende jeder Phase werden die Ergebnisse
überprüft und an die Folgephase weitergegeben. Wird dort während der
Erarbeitung der eigenen Phasenergebnisse, ein Fehler in den Vorgaben festgestellt,
so werden die Vorgaben an die vorhergehende Phase zurückgeführt. Die nach oben
gerichteten Pfeile der linken Seite beschreiben Rücksprünge während der
Entwicklung, die Pfeile der rechten Seite kennzeichnen Rücksprünge, die während
der Wartung (Fehlerkorrektur) notwendig werden können.
Auf die Inhalte der einzelnen Phasen wurde schon in Kapitel 1 eingegangen. Auf
eine nochmalige Beschreibung wird hier verzichtet.
109

110
Nachteile des Wasserfallmodells:
1 Bei großen Systemen ist die Entwicklungszeit zu lang. d. h. nach Fertigstellung
des Systems ist es schon veraltet.
2 Es ist nicht sinnvoll alle Entwicklungsschritte streng sequentiell durchzuführen.
(Z. B. kann es sinnvoll sein, ein Teil der Bedieneroberfläche schon bei der
Definition des Systems zu Demonstrationszwecken oder spezielle technische
Lösungen schon beim Entwurf des Systems zu realisieren.)
3 Risikofaktoren werden u. U. zu wenig berücksichtigt, da immer der einmal
festgelegte Entwicklungsablauf durchgeführt wird
Analyse
Änderungen
während der
Entwicklung
Definition
Entwurf
Abbildung 4.3.1 Wasserfallmodell
Implementierung
und Test
Abnahme
Änderungen /
Fehlerkorrektur
während der
Wartung
Betrieb und
Evaluation
Trotzdem ist das Wasserfallmodell insbesondere für kleinere Projekte evtl. unter
Einbeziehung von Prototyping-Ansätzen und einer nicht so strengen Sichtweise,
was den streng sequentiellen Ablauf angeht, auch heute noch durchaus anwendbar.

Für große Systeme ist insbesondere der Nachteil der langen Entwicklungszeit so
gravierend, dass besser eines der im Folgenden beschriebenen Prozessmodelle mit
mehreren zyklischen Durchläufen ausgewählt werden sollte.
Evolutionäres und inkrementelles Modell
Ziel heutiger Softwareentwicklungen ist es, dem Auftraggeber möglichst jedes
halbe Jahr ein lauffähiges Teilprodukt zur Verfügung zu stellen. Beim
evolutionären und inkrementellen Modell erstellt man das gesamte System deshalb
nicht wie beim Wasserfallmodell in einem Durchlauf, sondern in mehreren
Durchläufen, wobei am Ende jedes Durchlaufs ein einsatzfähiger Teil des System
fertig gestellt, in Betrieb genommen und evaluiert wird. Unter Einbeziehung der
Ergebnisse der Evaluation wird dann der nächste Durchlauf gestartet.
Das evolutionäre Modell
Die Kernanforderungen oder Mussanforderungen des Auftraggebers definieren den
Produktkern. Im ersten Durchlauf wird der gesamte Software-Entwickungszyklus
für diesen Produktkern durchgeführt. Das entwickelte Kernsystem wird
anschließend an den Auftraggeber ausgeliefert. Der Aufraggeber sammelt
Erfahrungen mit dieser Nullversion. Diese Erfahrungen fließen dann in die
verbesserte und erweiterte nächste Version ein, d. h. sowohl Pflegeaktivitäten
bezüglich des schon fertiggestellten Teil des Systems als auch die für die nächste
Version gewünschten Erweiterungen erfolgen im nächsten Zyklus.
Vorteile des evolutionären Modells:
• Benutzer stehen in kurzen Zeitabständen jeweils immer größere
einsatzfähige Teile des Gesamtsystems zur Verfügung.
111

1
112
Änderungen
Analyse des
Teilsystems
Definition des
Teilsystems
Entwurf des
Teilsystems
Abbildung 4.3.2 Evolutionäres Modell
Implementierung
und Test des
Teilsystems
Abnahme des
Teilsystems
Betrieb und
Evaluation des
Teilsystems
zum nächsten
Zyklus
1 Die mit einer Version gewonnenen Erfahrungen fließen sofort in die nächste
Version ein (sowohl Verbesserungen / Anpassungen an den Stand der Technik /
Veränderungen des Ablaufs bezüglich des schon bestehenden Teils als auch für
die Konzeption der ergänzenden Teile).
2 Geeignet, wenn der Auftraggeber seine Anforderungen noch nicht genau
überblickt.
Nachteile des evolutionären Modells:

­ Gefahr, dass der schon realisierte Teil des Systems völlig umgeschrieben
werden muss, weil die in spätern Entwicklungszyklen gefundenen
Anforderungen nicht mehr einfach Systemerweiterungen sondern
Systemveränderungen verursachen.
Inkrementelles Modell
Der oben beschriebene Nachteil wird durch das inkrementelle Modell vermieden.
In diesem Modell wird die Analyse und Definition für das Gesamtsystem erstellt.
In der Phase Definition wird dabei auch die Planung der Zyklen durchgeführt. In
den folgenden Phasen werden dann wie beim evolutionären Modell jeweils immer
umfangreicher werdende Teilsysteme erstellt, allerdings müssen nur die Phasen
Entwurf bis Betrieb und Evaluation durchlaufen werden, da die Analyse und die
Definition des Gesamtsystems ja schon vor dem ersten Durchlauf durchgeführt
wurden.
Vorteile des Inkrementellen Modells:
5. Die Vorteile des evolutionären Modells, dass dem Benutzer in kurzen
Zeitabständen jeweils immer größere einsatzfähige Teile des Gesamtsystems
zur Verfügung stehen und dass die mit einer Version gewonnenen Erfahrungen
sofort in die nächste Version einfließen können, sind hier auch gegeben. Der
Nachteil, dass beim Erstellen der Teilsysteme die Anforderungen an das
Gesamtsystem nicht berücksichtigt werden konnten, da sie noch nicht
aufgenommen waren, entfällt.
Nachteil des Inkrementellen Modells:
• Da die ersten beiden Phasen für das Gesamtsystem durchgeführt werden,
dauert es länger bis die erste Version fertig gestellt werden kann.
113

114
Analyse des
Gesamtsystems
Änderungen
Definition des
Gesamtsystems
inkl. Zyklenplanung
Anpassungen auf
Grund von Erfahrungen
mit dem Teilsystem
Entwurf des
Teilsystems
Implementierung
und Test des
Teilsystems
Abnahme des
Teilsystems
zum nächsten
Zyklus
Betrieb und
Evaluation des
Teilsystems
Abbildung 4.3.3 Inkrementelles Modell
Um den oben aufgeführten Nachteil abzuschwächen, könnte man auch eine
Mischform von evolutionären und inkrementellen Modell anwenden: Wir führen
keine bis ins Detail gehende Analyse und Definition des Gesamtsystems durch,
sondern eine so tief gehende Analyse und Definition, so dass mit großer
Wahrscheinlichkeit ausgeschlossen werden kann, dass es bei der Realisierung von
späteren Erweiterungen des Gesamtsystems dazu kommt, dass diese Erweiterungen
nicht oder nur mit großen Aufwand ins bereits bestehende System integriert
werden können (Grobkonzeption). Für das im ersten Durchlauf zu realisierende
Teilsystem werden natürlich die Phasen Analyse und Definition vollständig
durchgeführt.

4.4 Prototyping
Wir haben festgestellt, dass es bei allen vorgestellten Vorgehensmodellen
vorkommen kann, dass in irgendwelchen Phasen zu vorangehenden Phasen
zurückgegangen werden muss, um dort gefällte Entscheidungen zu revidieren.
Dieses Zurückgehen ist sehr zeit- und kostenaufwendig. Außerdem bedeutet ein
Ändern in einem bestehenden System meistens ein Strukturverfall im System.
Besonders aufwendig wird ein Zurückgehen in Vorphasen, wenn zum Zeitpunkt
der Abnahme festgestellt wird, dass das System nicht das tut, was es eigentlich tun
soll. In diesem Fall muss oft von der Phase Abnahme bis zur Analyse
zurückgegangen werden. Grund eines solche "bösen Erwachens" sind oft Fehler
oder Mehrdeutigkeiten in der Spezifikation, die vom zukünftigen Benutzer des
Systems nicht erkannt wurden.
Durch eine ausführliche durchgeführte Istanalyse, Schwachstellenanalyse etc.
durch den späteren Realisierer des Systems kann oft der Umfang solcher Fehler
verringert werden und Mehrdeutigkeiten richtig interpretiert werden.
Eine weitere Methode ist das Erstellen von so genannten Explorativen Prototypen,
mit Hilfe derer dem zukünftigen Benutzern des Systems die Bedienung und
Funktionsweise des Systems exemplarisch vorgeführt werden kann.
Ein zweiter Zeitpunkt, an dem ein die Wahrscheinlichkeit für ein Zurückgehen in
frühere Phasen durch Anwendung des Prototyp-Konzeps verringert werden kann,
ist die Phase der Implementierung. Wenn sich in dieser Phase herausstellt, dass
einige der in der Phase Definition oder Entwurf vorgesehene Konzepte gar nicht
oder nur mit großen Aufwand realisierbar sind, muss, falls überhaupt möglich, eine
nachträgliche Korrektur der Konzepte durchgeführt werden.
Dies ist oft nur mit recht großen Aufwand oder sogar (wie z. B. bei Toll Collect)
im versprochenen Zeit- und Kostenrahmen gar nicht möglich. Durch einen so
genannten Technischen Prototyp kann man viele Fragen der technischen
Realisierbarkeit im Vorfeld ausprobieren
Klassifikation von Prototypen
Es gibt drei Kriterien, nach denen Prototypen klassifiziert werden können:
• Was wird durch den Prototyp getestet?
• Wie ist der Prototyp aufgebaut?
• Inwieweit findet der Prototyp Anwendung bei der Implementierung des
endgültigen Systems?
115

116
Was wird durch den Prototyp getestet?
• Explorativer Prototyp
dient als Kommunikationsgrundlage zwischen Endbenutzer und den
Systementwicklern. Spätere Arbeitsweise wird durchgespielt Schwächen und
Fehler der Spezifikation werden erkannt und vor der Weiterarbeit beseitigt.
• Technischer Prototyp ( Experimenteller Prototyp. Labormodell)
dient den Entwicklern intern als Bewertungsgegenstand, der Fragen der
technischen Umsetzung und Realisierbarkeit klären soll. Beispiel für
Zielsetzungen:
• Überprüfung der Machbarkeit
• Abschätzung des Aufwandes und damit des Zeitbedarfs und der Kosten
der Realisierung
• Vergleich von Alternativen
• Performance-Tests
• Fragen der Konfiguration (Anschluss von Druckern, Vernetzung, …)
• Einsatz von Tools
Wie ist der Prototyp aufgebaut?
• Horizontaler Prototyp
ist dadurch gekennzeichnet, dass nur eine Ebene des Systems implementiert ist.
IM Normalfall ist die Schittstelle zum Benutzer (oder ein Teil davon)
implementiert. Mit Hilfe solch eines Prototyps kann das Arbeiten mit dem
System gezeigt werden. Da die tieferen Ebenen fehlen, liefert das System
normalerweise falsche Werte.
• Vertikaler Prototyp
horizontaler Prototyp
Schnittstelle
Verarbeitunglogik
Dateizugriffe

ist dadurch gekennzeichnet, dass er exemplarisch ausgewählte Teilfunktionen
des zukünftigen Systems vollkommen realisiert.
• Gesamtsystem mit Lücken
ist dadurch gekennzeichnet, dass alle Teile des systems realisiert sind außer
Plausibilitätsprüfungen, Abfangen von Ausnahme- und Fehlersituationen,
komplexe Berechnungsroutinen etc.
Inwieweit findet der Prototyp Anwendung bei der Implementierung des
endgültigen Systems
• Throw-away-Prototype (Quick-and-dirty-Prototype, Rapid-Specification-
Prototype)
findet keine Verwendung bei nachfolgender Implementierung dient einzig und
allein zur Entwicklung korrekter, robuster Spezifikationen
• Add-on-Prototype (Rapid-Cyclic-Prototype)
wird Bei der Implementierung des Zielsystem mitverwendet Beim Rapid-Cyclic-
Prototyping wird ausgehend von einem ersten Add-on-Prototype zum
Zielsystem weiterentwickelt.
4.5 Das V-Modell
vertikaler Prototyp
Das V-Modell ist hervorgegangen aus dem Wasserfallmodell, das man um die
Aktivitäten Verifikation und Validation erweitert hat.
Verifikation in der Bedeutung: Prüfen, ob das Produkt seiner Spezifikation
entspricht. Umgangssprachlich: "Wird ein korrektes Produkt entwickelt?"
117

118
Validation in der Bedeutung: Prüfen, ob das Produkt für seinen Einsatzzweck
geeignet ist. Umgangssprachlich: "Wird das richtige Produkt entwickelt?"
Das V-Modell ist Bestandteil des Standardisierungskonzepts der Bundesbehörden.
Dieses Konzept hat folgende Eigenschaften:
• verbindlich für IT-Vorhaben in Bundesbehörden (wird jedoch auch in der
Wirtschaft eingesetzt)
• deckt die Softwareentwicklung, das Projektmanagement, die Qualitätssicherung
und das Konfigurationsmanagement ab
• beschreibt die Vorgehensweise (V-Modell), die anzuwendenden Methoden und
die einzusetzendenWerkzeuge
Das V-Modell ist in vier Submodelle gegliedert:
• Softwareerstellung (SWE)
• Qualitätssicherung (QS)
• Konfigurationsmanagement(KM)
• Projektmanagement (PM)
4.5.1 Struktur des Standardisierungskonzeptes
Die Notwendigkeit der Standardisierung in der IT-Systementwicklung ist heute
unbestritten.
Als Vorteile der Standardisierung werden hauptsächlich gesehen:
• Bessere Planbarkeit von ITProjekten
• Eindämmung der Entwicklungskosten über den Lebenszyklus
• Verbesserung der Qualität
• Verbesserung der Kommunikation zwischen Auftraggeber und Auftragnehmer.
Der Standard besteht aus folgenden drei Ebenen:
1. Vorgehensweise "Was ist zu tun?"
Diese Ebene legt fest, welche Tätigkeiten im Verlauf der Systementwicklung
durchzuführen sind, welche Ergebnisse dabei zu produzieren sind und welche
Inhalte diese Ergebnisse haben müssen.
2. Methoden "Wie ist etwas zu tun?"

Hier erfolgt eine Bestimmung, mit welchen Methoden die auf der ersten Ebene
festgelegten Tätigkeiten durchzuführen und welche Darstellungsmittel in den
Ergebnissen zu verwenden sind.
3. Werkzeuganforderungen "Womit ist etwas zu tun?" Auf dieser Ebene ist fixiert,
welche funktionalen Eigenschaften die Werkzeuge (Tools) aufweisen müssen,
die bei der Systementwicklung eingesetzt werden sollen.
Auf allen Ebenen werden die Regelungen nach den Tätigkeitsbereichen, den
sogenannten Submodellen gegliedert:
119

120
4.5.2 Eigenschaften des V-Modells
Das V-Modell
• beschreibt Aktivitäten und Produkte
• regelt die Gesamtheit der Aktivitäten und Produkte sowie die
Produktzustände und die Abhängigkeiten zwischen Aktivitäten und
Produkten
Wichtig: das V-Modell beschreibt den Softwareentwicklungsprozeß nur aus
funktionaler Sicht, d.h. es werden keine Aussagen über die konkrete organisatorische
Umsetzung getroffen.
Die Aufteilung von Aufgaben auf Bearbeiter bzw. Organisationseinheiten wird vor
Projektdurchführung festgelegt.
4.5.3 Produktzustände und Übergänge
4.5.4 Erzeugnisstruktur
Das Gesamtsystem (inklusive HW und SW) wird in unterschiedliche Bestandteile
aufgelöst:
• Subsysteme
• Segmente (mit DV-Anteil/ohne DV-Anteil)
• Konfigurationseinheiten (SW, HW und ohne DV-Anteil)
• KomponentenModule/Datenbanken

4.5.5 Struktur und Inhalt des V-Modells
Das V-Modell besteht aus folgenden Elementen:
• Aktivitäten
• Produkte
• Beschreibungsmuster
• Submodelle
4.5.6 Aktivitäten und Produkte
Aktivitäten: Tätigkeiten, die hinsichtlich ihres Ergebnisses und ihrer
Durchführung genau beschrieben werden können. Sie sind durch Teilaktivitäten
verfeinerbar, die Zwischenergebnisse erzeugen. Aktivitäten der obersten Ebene
werden Hauptaktivitäten genannt.
Produkte: Bearbeitungsgegenstand oder Ergebnis einer Aktivität, kann wiederum
auch in Teilprodukte zerlegt werden. Produkte können die Zustände geplant, in
Bearbeitung, vorgelegt und akzeptiert annehmen.
Notation:
121

122
4.5.7 Aktivitätenzerlegung
Die Aktivitätenzerlegung wird bei der Verfeinerung von Aktivitäten angewendet..
Sie beschreibt den Zusammenhang von Teilaktivitäten und -produkten in
graphischer Form (hier die Aktivität SWE 6/Implementierung):

4.5.8 Produktfluss und Abwicklung
Produktflüsse beschreiben die Eingangs- und Ausgangsprodukte für eine
bestimmte Aktivität
4.5.9 Die Submodelle
Die Aktivitäten der Softwareentwicklung werden auf vier Submodelle verteilt:
• Softwareerstellung (SWE)
• Qualitätssicherung (QS)
• Konfigurationsmanagement (KM)
• Projektmanagement (PM)
123

124
4.5.10 Zusammenspiel der Submodelle
4.5.11 Submodell "Softwareerstellung" (SWE)
Der linke Arm des V enthält die Planungs- und Konstruktionsphasen, der rechte
Arm die Integrations- und Kontrollphasen der Systementwicklung. Auf gleicher

Höhe befindet sich links die Phase, die die Test- und Planungs-Unterlagen für die
Phase rechts liefern muss. Dieses "V" in der Darstellung des Softwareentwicklungsprozesses
hat dem gesamten Vorgehensmodell den Namen gegeben. Es
legt fest, dass die Testfälle für die Verifikation eines Software-Moduls bereits mit
dem Feinentwurf und während der Implementierung zu erstellen sind. Die Testfälle
und sonstigen Pläne für die Integration einzelner Softwaremodule müssen bei
Grobentwurf und SW-Anforderungsanalyse geschaffen werden. Der Plan für die
DV-Integration ist in der DV-Anforderungsanalyse festzulegen. Die Planungsunterlagen
für die endgültige Systemintegration und ihr Test sind bereits
während der Systemanforderungsanalyse zu schaffen.
4.5.12 Systemanforderungsanalyse und -entwurf (SWE 1)
Betrifft das Gesamtsystem und besteht aus folgenden Aktivitäten:
Ist-Analyse: Datenbestände, DV-Ausrüstung, Zeit/Mengengerüst, Schwachstellen
Bedrohungs- und Risikoanalyse: zu schützende Objekte, Eintrittwahrscheinlichkeiten
Systemanforderungen definieren: Anforderungen an Funktionalitäten, Daten,
Qualitätsmerkmale aus Anwendersicht
System fachlich strukturieren: Funktions- und Datenstruktur aus Anwendersicht
4.5.13 Systemanforderungsanalyse und -entwurf (SWE 1)
System technisch entwerfen: Aufteilung in Subsysteme, Segmente oder
Softwarekonfigurationseinheiten
Machbarkeitsanalyse: Verwendung von Fertigprodukten, Wirtschaftlichkeit,
Tolerierbarkeit von Restrisiko
Systemanforderungen zuordnen: Zuordnung der Anforderungen zu den
Systembestandteilen
Systemintegration planen: Planen des Zusammenführens der Systembestandteile,
Planen der Inbetriebnahme
Wichtige Produkte in SWE 1 sind die Systemanforderungen, die
Systemarchitektur und der Systemintegrationsplan
4.5.14 DV-Anforderungsanalyse und -entwurf (SWE 2)
Besteht aus folgenden Aktivitäten:
125

126
• DV-Ist-Analyse
• DV-Anforderungen analysieren
• Machbarkeitsanalyse
• DV-Segment entwerfen
• DV-Anforderungen zuordnen
• DV-Integration planen
4.5.15 DV-Anforderungsanalyse und -entwurf (SWE 2)
Die Aktivitäten korrespondieren mit den Aktivitäten aus SWE 1, jedoch betreffen
sie hier nur einzelne DV-Segmente.
Wichtige Produkte sind die DV-Anforderungen, die DV-Architektur, der
Schnittstellenentwurf und der DV-Integrationsplan
4.5.16 SW-Anforderungsanalyse (SWE 3)
Behandelt einzelne SWKE und besteht aus folgenden Aktivitäten:
• Ist-Analyse
• Allgemeine Anforderungen definieren
• Anforderungen an externe Schnittstellen definieren
• Anforderungen an Funktionen und Daten definieren
• Qualitätsanforderungen definieren
• Anforderungen an Entwicklungsumgebung und Zielrechner definieren
• Als Produkt werden die SW-Anforderungen erstellt.
4.5.17 Grobentwurf (SWE 4)
Zerlegt die SWKE in einzelne Prozesse und definiert die Kommunikation und
Synchronisation zwischen den Prozessen.Weiter werden die SWKE dann in
Module aufgeteilt. Aktivitäten sind:
• SW-Architektur entwerfen
• Prozesse entwerfen

• SWKE-interne Schnittstellen entwerfen
• SWKE-Integration definieren
Als Ergebnis wird die SW-Architektur, der Schnittstellenentwurf und der SWKE-
Integrationsplan erstellt.
4.5.18 Feinentwurf (SWE 5)
Entwurf der Realisierung der Module und Datenbanken:
• Komponente/Modul/Datenbank beschreiben
• Betriebsmittel- und Zeitbedarf analysieren
Hieraus resultieren der Datenkatalog und der SW-Entwurf.
4.5.19 Implementierung (SWE 6)
Umsetzung der Module und Datenbanken:
• Module codieren
• Datenbanken realisieren
• Informelle Prüfung
• Debugging
Produkte sind Module und Datenbanken.
4.5.20 SW-Integration (SWE 7)
Zusammenführung der Module und Datenbanken zu SWKE: Zu SWKE-
Teilstruktur integrieren
• Komponente informell prüfen
• Zur SWKE integrieren
• SWKE informell prüfen
Ergebnis der SW-Integration sind die SWKE.
4.5.21 DV-Integration (SWE 8)
Zusammenführung von SWKE und HWKE zu DV-Segmenten:
127

128
• Zum DV-Segment integrieren
• Tuning
• Beitrag zur Einführungsunterstützung leisten
• DV-Segment informell prüfen
Die DV-Integration liefert vollintegrierte und teilintegrierte DV-Segmente
4.5.22 Produkte im Submodell SWE
Produkte, die bei der SWE erstellt werden:
Systemprodukte: Systemanforderungen, Systemarchitektur
DV-Produkte: DV-Anforderungen, DV-Architektur
SW-Produkte: SW-Anforderungen, SW-Architektur, SW-Entwurf,
Implementierungsdokumente
Integrationsdokumente: Integrationsplan
Handbuchinformation: Anwenderhandbuch, Diagnosehandbuch,
Betriebshandbuch
Begleitende Dokumente: Datenkatalog, Schnittstellenentwurf
4.5.23 Submodell"Qualitätssicherung"
4.5.24 Aktivitäten im Submodell QS

Folgende Aktivitäten werden im Submodell QS durchgeführt: QS-Initialisierung:
legt den organisatorischen Rahmen im QS-Plan und in Prüfplänen fest
Prozeßprüfung von Aktivitäten: Prüft die Einhaltung bestimmter
Vorgehensweisen
Produktprüfung vorbereiten: Erstellen von Prüfspezifikationen und -prozeduren,
Erfolg und Mißerfolg einer Prüfung muß eindeutig und nachvollziehbar sein
4.5.25 Aktivitäten im Submodell KM
KM-Initialisierung: legt organisatorischen Rahmen für die Konfigurationsverwaltung
sowie alle Einsatzmittel fest Konfigurationsverwaltung:
Verwaltung von Produkten, Konfigurationen und Rechten, Festlegung einer
zentralen Datenadministration Änderungsmanagement: Erfassung von
Fehlermeldungen, Problemmeldungen, Verbesserungsvorschlägen etc.
Datensicherung
KM-Berichtswesen: Zur Vorbereitung von Durchführungsentscheidungen und zur
Information des Projektmanagements
4.5.26 Submodell "Projektmanagement" (PM)
129

130
4.5.27 Aktivitäten im Submodell PM
Projekt initialisieren: regelt den organisatorischen Rahmen für das gesamte
Projekt im Projektplan und Projekthandbuch. Legt Modalitäten für die
projektinterne Zusammenarbeit und die Schnittstelle zum Auftraggeber fest.
Anpassung des Vorgehensmodells (Tailoring).
Projekt begleiten: Unterteil in die Phasen Initialisieren, Begleiten und
Abschließen der einzelnen Aktivitäten im Projekt.
Projekt abschließen: Aufbereitung der Ergebnisse, Soll-Ist-Vergleich
4.5.28 Rollen im V-Modell
Das V-Modell legt Rollen fest, die durch Erfahrungen, Kenntnisse und
F¨ahigkeiten definiert sind. Diese Rollen werden dann im Projektablauf den
Mitarbeitern zugewiesen:
SWE-Rollen: Systemanalytiker, Systemdesigner, DV-Analytiker, DV-Designer,
SW-Analytiker, SW-Designer, Programmierer, Supportberater,
Applikationsberater, HW-Berater, Technischer Autor
PM-Rollen: Projektmanager, Projektleiter, Projektassistent
QS-Rollen: QS-Manager, QS-Verantwortlicher, Qualitätsprüfer, QS-Assistent
KM-Rollen: KM-Leiter, Konfigurationsadministrator, Datenschutz- und
Datensicherheitsbeauftragter
Den einzelnen Rollen werden detailliert Aufgaben zugeordnet (ausführend,
beratend, mitwirkend). Die Zuordnung von Rollen zu Mitarbeitern kann frei
erfolgen mit zwei Ausnahmen:
• Personen mit QS-Rollen dürfen nicht an der Erstellung der von ihnen
zuprüfenden Produkte beteiligt sein (dies ist abhängig von der Kritikalität
unterschiedlich streng zu handhaben)
• Zu trennen ist auch die Rolle des Projektmanagers von QS- und SWE-Rollen
Es ist somit eine Mindestanzahl von zwei bis drei Personen an einem Projekt
beteiligt.
4.5.29 Tailoring

Das V-Modell soll sowohl für kleine als auch sehr große Projekte geeignet sein.
Demzufolge definiert es alle Aspekte, die in diesen Projekten auftreten können.
Das Tailoring sieht vor, aus dem V-Modell durch Streichungen ein an das Projekt
angepasstes Modell zu erstellen. Es sind jedoch auch schon Beispielmodelle
(inklusive Dokumente) erhältlich.
4.5.30 Zusammenfassung
• Das V-Modell ist ein übergreifendes Modell zur Abwicklung von
Softwareentwicklungsvorhaben
• Es muß vor dem Einsatz angepaßt werden
• Wegen der hohen Zahl und Komplexität von zu erstellenden Produkten ist eine
Werkzeugunterstützung fast zwingend
• Es verlangt erhöhte Kooperation zwischen Auftraggeber und Auftragnehmer;
kann dabei aber Kommunikationsprobleme verringern
131

132
4.6 RUP
Der Rational Unified Process (RUP) ist ein Vorgehensmodell (Software
Engineering Process), das von der Firma Rational Software entwickelt wurde.
Dieses stellt ein umfangreiches Rahmenwerk zur Entwicklung von qualitativ
hochwertiger Software bereit. Der Anwendungsbereich des RUP ist sehr weit
gefasst und soll unterschiedlichste Projekttypen in Bezug auf Projektgröße,
Anwendungsgebiet und Plattform unterstützen.
Der RUP beschreibt ein Vorgehensmodell auf Basis von sog. "Best Practices", die
erwiesenermaßen bei erfolgreichen Projekten zum Einsatz kommen. Diese
umfassen im Einzelnen die iterative Entwicklung von Software, das Management
von Anforderungen, die Nutzung komponentenbasierter Architekturen, die visuelle
Modellierung der Software, die Verifikation der Software-Qualität und der
Etablierung eines Änderungsmanagements.
Um die gesteckten Ziele zu erreichen, definiert der RUP diverse Workflows (bzw.
Disziplinen), Rollen und Artefakte. Ein Workflow (Disziplin) beschreibt eine
Sequenz von Aktivitäten, die die Verbindung zwischen Rollen, Aktivitäten und
Artefakte herstellt. Die Artefakte können Dokumente, Codestücke, Modelle oder
Berichte sein und stellen das Ziel einer Aktivität dar. Die einzelnen Aktivitäten
werden dabei von den Inhabern der zugeordneten Rolle ausgeführt und unterteilen
sich in einzelne Schritte.
Zusammengefasst ergeben die Aktivitäten folgende neun Disziplinen:
Geschäftsprozessmodellierung (Business Modelling), Anforderungsanalyse
(Requirements), Analyse und Design, Implementierung, Test, Softwareverteilung
(Deployment), Konfigurations- und Änderungs-Management, Projektmanagement
sowie IT-Infrastruktur (Environment). Diese werden in die sog. Core Process
Workflows und Core Supporting Workflows unterteilt (siehe Abbildung 4-2).
Dieser Teil des RUP bildet den statische Teil.
Darüber hinaus wird der dynamische Teil des RUP durch Phasen, Iterationen,
Zyklen und Meilensteinen dargestellt. Die vier Phasen des RUP lauten Inception,
Elaboration, Construction und Transition. Jede Phase wird beim RUP in mehreren
Iterationen abgehandelt. In jedem Zyklus wird eine neue Produktversion erstellt,
die bestimmte Anwenderanforderungen erfüllt. Meilensteine stellen bestimmte
Zeitpunkte dar, an denen wichtige Entscheidungen abhängig vom erreichten
Entwicklungsstand getroffen werden können. Die Disziplinen durchziehen jeweils
mehrere Phasen, allerdings mit unterschiedlicher Intensität der assoziierten
Aktivitäten. Dies wird durch die dargestellte Fläche pro Disziplin verdeutlicht.

Abb. 4-2: Der Rational Unified Process (RUP)
4.6.1 RUP-Phase "Inception"
Die Inception-Phase beschäftigt sich mit dem Aufsetzen eines Projekts und bildet
den Einstiegspunkt zur Erstellung oder Änderung eines Systems. Ziel dieser Phase
ist es, den Projektumfang festzulegen und einen sogenannten "Business Case " als
Grundlage für das durchzuführende Projekt zu erstellen. Dies beinhaltet auch eine
Risiko- sowie Zeit- und Kostenschätzung im Rahmen des Projektmanagements
und beschreibt die Erfolgskriterien, die an das Produkt gestellt werden. Des
Weiteren wird ein sog. "Vision"-Dokument erstellt, das die wesentlichen
Rahmenbedingungen des Projektes sowie die Anforderungen und Hauptfunktionen
des zu erstellenden Systems beschreibt.
Ein weiterer Schwerpunkt dieser Phase bildet die Durchführung der
Geschäftsprozessmodellierung. Hierfür sind neben den sog. Stakeholdern die
Rollen Business-Process Analyst, Business Designer und Business Model
Reviewer vorgesehen.
Um ein gemeinsames Verständnis der Anwendungsdomäne zu erreichen, wird
zunächst vom Business-Process Analyst ein gemeinsamer Wortschatz in Form
eines Glossars erarbeitet. Danach werden von diesem Analyst die an den
Geschäftsprozessen beteiligten Personen sowie die Anwendungsfällen (Use Cases)
identifiziert. Eine Detaillierung dieser UseCases erfolgt vom Business Designer.
Die weitere Strukturierung des Anwendungsfall-Modells fällt der Rolle des
Analysten zu. Dieses Anwendungsfall-Modell wird nun vom Business Model
Reviewer überprüft.
133

134
Neben der Geschäftsprozessmodellierung werden in der Inception-Phase die
Hauptanforderungen als wichtige Grundlage für das zu erstellende System
erarbeitet. Am Ende dieser Phase stehen so ein konzeptioneller Prototyp sowie ein
erstes, noch unvollständiges Domainmodell für die weiteren Phasen bereit. Somit
ist ein wichtiger Meilenstein (der "Lifecycle Objectives Milestone") erreicht.
Sofern die Projektziele zu diesem Zeitpunkt gefährdet sind oder als nicht erreichbar
eingeschätzt werden, kann ein Projekt hier beendet oder in veränderter Form neu
aufgesetzt werden.
4.6.2 RUP-Phase "Elaboration"
Die Aufgabe der Elaboration-Phase ist die weitere Ausarbeitung des Projekts.
Dabei werden die funktionellen und nicht funktionellen Anforderungen aus der
vorherigen Phase im Rahmen des Software Development Plans (SDP) erarbeitet
und einen Projekt- sowie einen Iterationsplan erstellt. In diesen Plänen werden die
während des Projekts zu verwendenden Ressourcen und Werkzeuge festgelegt.
Der Software Development Plan liefert eine Hilfe für die Durchführung folgender
RUP-Komponenten: Projektorganisation, Requirements Management Plan,
Configuration Management Plan, Problem Resolution Plan, Quality Assurance
Plan, Test Plan, Test Cases, Evaluation Plan und Product Acceptance Plan.
Des weiteren wird in der Elaboration-Phase eine detaillierte Analyse der Problembereichen
durchgeführt und die Basisarchitektur des zu erstellenden Systems
festgelegt ("mile wide and inch deep view of the system"). Zusätzlich erfolgt die
Identifikation und Beschreibung der Hauptrisiken. Ziel ist es, die identifizierten
Hauptrisiken durch entsprechende Maßnahmen möglichst früh zu eliminieren.
Zur Erstellung der Anforderungsanalyse und des Designs sind folgende sieben
Rollen definiert: der System Analyst, der Use Case Specifier, der User Interface
Designer, der Architect, der Designer, der Datenbank Designer und der Capsule
Designer, welcher für das objektorientierte Design zuständig ist. Wichtige
Artefakte dieser Phase sind der Anforderungsplan, ein detailliertes Use Case
Modell, ein User Interface Prototyp (falls notwendig), ein Softwarearchitekturplan,
ein Datenmodell, Klassendiagramme, ein Designmodell sowie weitere notwendige
Dokumente. Welche Artefakte in dieser Phase erstellt werden müssen, hängt
selbstverständlich von dem Projekttyp ab. Hierzu bietet auch der RUP die
Möglichkeit, sich an die Projektgegebenheiten anzupassen ("RUP Configuration").
Zur Erstellung dieser Artefakte stehen diverse Werkzeuge zur Verfügung. Hierbei
wird angestrebt, dass möglichst automatisch Artefakte der nächsten Stufe
erzeugt werden können. Beispielsweise ist es möglich, aus einem
Klassendiagramm die Klassen (Coderahmen) in der jeweiligen
Programmiersprache zu erzeugen. Weitere Möglichkeiten stellen die Generierung
der benötigten Tabellen aus einem Datenmodell dar. Am Ende dieser Phase stehen

eine überarbeitete Risikoabschätzung sowie die Basisarchitektur des
umzusetzenden Systems. Damit sind die wichtigsten Rahmenbedingungen
geschaffen, um das geforderte System in der nächsten Phase weiter zu entwickeln.
Diese Phase des RUP stellt die kritischste Phase dar und die "harte Engineering-
Phase" ist hiermit für das Projekt beendet ("Lifecycle Architecture Milestone").
Konzeptuell gesehen, sollte ein Grad an Sicherheit in Bezug auf Architektur,
Anforderungen etc. erreicht sein, damit die nachfolgende Phase als Fix-Preis-
Projekt durchgeführt werden könnte. Auch hier gilt, dass ein Projekt beendet
werden kann, wenn die Ziele dieser Phase nicht erreicht wurden.
4.6.3 RUP-Phase "Construction"
In der Construction-Phase findet der größte der Teil der Implementierung des
Systems statt. Die einzelnen Klassen bzw. Software-Komponenten werden
ausprogrammiert und notwendige Schnittstellen realisiert. Zusätzlich werden
Testfälle erstellt und deren Durchführung geplant. Hiermit soll eine
Qualitätssicherung bereits vor der Implementierung gewährleistet werden. Die
Ergebnisse jeder einzelnen Iteration dieser Phase stellen Produkt-Releases dar, die
dem Kunden zur Verifikation übergeben werden können. Die Disziplin
Implementierung umfasst neben der Implementierungsplanung und der Erstellung
der einzelnen Softwarekomponenten auch die Planung und Durchführung der
Integration der jeweils betroffenen Software-Komponenten. Auch werden die
Datenbanken mit den notwendigen Tabellen erstellt. Zur Durchführung der
diversen Aktivitäten sind beim RUP vier Rollen vorgesehen. Diese sind der
Architect, der System Integrator, der Code Reviewer sowie der Implementierer.
Der RUP legt einen klaren Schwerpunkt auf das Testen der Software vor deren
Auslieferung. Hierbei durchlaufen die einzelnen Tests die Phasen Planung, Design,
Implementierung, Ausführung und Evaluierung. Eine entwickelte Komponente
wird sowohl isoliert von anderen Komponenten getestet (Komponententest) als
auch im Verbund mit anderen Komponenten (Verbund-/Integrationstest). Die Tests
helfen, unerwünschte Seiteneffekte herauszufinden, die bei der Kommunikation
einzelner Komponenten auftreten können. Erst bei erfolgreicher Absolvierung
dieser Tests gilt eine Komponente als fertig gestellt. Die Durchführung der
Testphasen wird durch die vier Rollen, Test Designer, Designer, Implementer und
Tester abgedeckt.
Diese Phase des RUP kann als Produktionsprozess bezeichnet werden, da der
Fokus auf das Management der vorhandenen Ressourcen und die Steuerung der
Aktivitäten liegt, um so die Kosten, den Zeitplan und die geforderte Qualität
einzuhalten.
135

136
Die Construction-Phase liefert als Ergebnis ausführbare und qualitätsgesicherte
Produkt-Versionen. Die Auslieferungsplanung legt fest, wann der Kunde welche
Komponenten bzw. Produktversionen erhält bzw. wann diese in Produktion gehen
sollen ("Wirk- oder Produktionsumgebung"). Schließlich wird in dieser Phase
auch die System- und Benutzerdokumentation erstellt. Nach Abschluss dieser
Phase ist der Meilenstein "Initial Operational Capability" erreicht. Oft entspricht
das erstellte Produkt dem Status eines Beta-Release. Sofern ein stabiler
Produktzustand erreicht ist, kann in die nächste Phase gegangen werden.
4.6.4 RUP-Phase "Transition"
In der Transition-Phase wird das erstellte System oder Teile davon (Subsystem)
vollständig dem Kunden übergeben. Neben der Übergabe sieht der RUP auch eine
Unterstützung bei der Inbetriebnahme und dem Umgang mit der Software vor.
Hierbei auftretende Probleme werden umgehend gelöst.
In der Disziplin Deployment wird zunächst ein Deployment Plan erstellt, der die
Integration des Systems in die IT-Landschaft des Kunden beschreibt. Weitere
Dokumente zum Umgang mit dem System werden erstellt. Zur Durchführung des
Deployments sind folgende fünf Rollen definiert: der Implementer, der Technical
Writer, der Deployment Manager, der Graphic Artist und der Course Developer.
Die Inbetriebnahme des entwickelten Systems bedeutet, dass dieses in die IT-
Landschaft des Kunden integriert werden muss. Hierzu müssen unter Umständen
noch Implementierungsarbeiten und Tests durchgeführt werden, die in einer
früheren Phase nicht durchgeführt wurden bzw. konnten. Das Software-Produkt
durchläuft somit verschiedene Stati: von dem Beta-Release, über General
Availability Release bis hin zu Bug-Fixes und Enhancement Releases. Für die
verschiedenen Produktstände empfiehlt sich die Ausarbeitung, Durchführung und
Auswertung der Akzeptanztests, um die Abnahme des jeweiligen Produkts zu
erreichen.
Am Ende der Transition Phase ist der Meilenstein "Product Release" erreicht. Der
Abschluss der Aktivitäten der Transition-Phase stellt damit das Projektende dar.
Nach der Übergabe des Produkts an den Kunden sollte von Seiten des
Softwareunternehmens bzw. Softwareerstellers eine Nachbetrachtung hinsichtlich
der eingehaltenen Planungen und der notwendigen Anpassungen erfolgen. Hiermit
sollen Probleme oder Mängel in zukünftigen Projekten vermieden werden. Einige
Beratungsfirmen pflegen daher umfangreiche Wissens- bzw. Projektdatenbanken,
um die gemachten Erfahrungen und Erkenntnisse möglichst schnell in neue
Projekte einfließen lassen zu können.

4.7 eXtreme Programming (XP)
4.7.1 Warum XP?
Im Jahr 1998 führten erste Veröffentlichungen von Kent Beck unter dem Titel
eXtreme Programming (XP, Extremes Programmieren) zu bis heute anhaltenden
Diskussionen. Die von ihm vorgeschlagenen Forderungen für ein Methode zur erfolgreichen
Software-Entwicklung, die "das Programmieren zur Schlüsselaktivität
während der gesamten Dauer eines Softwareprojektes [erklärt]" (Erich Gamma im
Vorwort zu [Beck 03]), wurden und werden in ihrer "extremen" Art von manchem
als provokativ empfundenen. Beck vergleicht den Software-Entwicklungsprozess
mit dem Steuern eines Autos zum Erreichen eines vorgegebenen Ziels: die Lenkung
des Autos erfordert eine kontinuierliche Justierung zur Zielrichtung in kleinsten
Einheiten. Dieses Bild überträgt Beck auf die Forderung, den Software-Entwicklungsprozess
in kleinste, iterative Schritte zu gliedern, die die Erreichung des
Projekt-Ziels durch die permanente Anwendung geeigneter Regulierungspraktiken
garantiert. Beck nennt vier Variablen, mit deren Hilfe man jedes Projekt kontrollieren
kann: Kosten, Zeit, Qualität und Umfang – alle vier Variablen stehen in komplexen
Abhängigkeiten zueinander. Der Umfang ist jedoch die wichtigste und am
einfachsten zu steuernde der vier Kontrollvariablen, wenn die Softwareentwicklung
in kleinsten Entwicklungseinheiten durchgeführt wird und dadurch die unmittelbare,
d.h. zeitnahe Kontrolle der drei anderen Variablen ermöglicht. Die
bislang angewandten Vorgehensmodelle enthielten diese Forderung nach kleinsten
Iteartionsschritten mit allen zugehörigen Konsequenzen nicht in der von Beck
geforderten, "extremen" Art. Beck betont die Wichtigkeit der Gesamtheit aller
anzuwendenden Praktiken (vgl. 4.6.2). Werden einzelne Praktiken aus dem
Gesamtkontext des XP gelöst, ist die eigentliche Idee des XP nicht mehr tatsächlich
verwirklicht. "Calling the tail a leg doesn't make it one." [Jeff 04].
Unter der Gesamtheit aller IT-Projekte können solche als besonders geeignet für
die Anwendung des XP als Methode zur Entwicklung von Software bezeichnet
werden, die risikobehaftet sind und mit einem hohen Grad an dynamischen Anforderungen
von kleinen bis mittelgroßen Teams realisiert werden.
XP wurde seit 1998 bis zur heute diskutierten Form von Kent Beck, Ward Cunningham,
Martin Fowler und Ron Jeffries definiert und durch umfangreiche Erprobung
in Projekten ständig weiterentwickelt.
4.7.2 Die zwölf Praktiken
Der Planungsprozess (Planning Process) (bzw. das Planungsspiel) hat zum Ziel,
durch die Definition der Anforderungen (Requirements) eine gezielte Planung für
137

138
jede einzelne Iteration zu ermöglichen. Verfügbare Entwicklungsressourcen und
Kundenwünsche werden dabei in Einklang gebracht. Die Aufgabe des Kunden besteht
hierbei darin, seine User Stories zu definieren. Diese werden auf Karteikarten
notiert und sind vergleichbar mit einer Beschreibung von Anwendungsfällen auf
einer zunächst relativ generischen Ebene. Für jede Iteration werden die User
Stories ggf. korrigiert und neu priorisiert, um die Hinführung des Gesamtprojekts
zum Erfolg in kleinsten, validierbaren Schritten zu garantieren. Zum geeigneten
Zeitpunkt werden die User Stories im Dialog der Entwickler mit dem Kunden verfeinert
und ggf. neu verhandelt.
Kleine Releases (Small Releases) sind das Ziel erfolgreich durchgeführter Iterationen
auf der Basis des im Planungsprozess erzielten Release-Planes (Release
Plan). Jedes dieser kleinen Releases erlaubt eine frühzeitige Produktionsübernahme
der entsprechenden User Story und garantiert die permanente Erweiterung im Hinblick
auf das Gesamtprojektziel in jeweils sehr kurzen Release-Zyklen. Ein Release-Zyklus
umfasst 1-3 Monate. In dieser Phase werden mehrere Iterationen einer
Dauer von 1-3 Wochen durchlaufen, die sich wiederum in Arbeitspakete einer
Dauer von 1-3 Tagen gliedern.
Die System-Metapher (System Metaphor) dient dazu, die Architektur bzw. einen
Teil der Architektur zu beschreiben. Durch ein von allen Mitgliedern des XP
Teams gemeinsam genutztes System von Bezeichern, Begriffen und Beschreibungen
wird die Entwicklung und die Kommunikation unterstützt und gefördert.
Einfacher Entwurf (Simple Design) bedeutet, dass zur Erreichung der aktuellen
Anforderungen die minmalistischste Lösung bzgl. des Aufwandes herangezogen
wird, "the simplest thing that could possibly work" [Beck 99]. Dies bedeutet u.a.
auch, dass keine der zukünftigen Anforderungen bereits "mit implementiert" wird.
Zur Erlangung eines guten Designs sollte insbesondere die Praxis des Refaktorisierung
(s.u.) zum Einsatz kommen.
Das Testen (Testing) begleitet jeden Iterationsschritt. Funktionale Akzeptanztests
auf der Basis von Testfällen, die der Kunde – in Anlehnung an die jeweilige Story
– definiert, werden von den Testern implementiert (Acceptance Tests). Sie sind
jederzeit automatisch ausführbar und werden ergänzt von Kompontententests (Unit
Tests), die von den Entwicklern zum Test ihrer Klassen vor der Implementierung
der Klassen geschrieben werden (vgl. auch den Abschnitt JUnit in Kapitel 8). Diese
beiden Teststrategien bilden den Kern der XP-Teststrategien und werden ergänzt
durch Paralleltests und Belastungstests.
Refaktorisierung (Refactoring) verbessert während des gesamten Entwicklungsprozesses
das Design des Systems durch permanente Vereinfachung des Codes bei

gleichbleibender Semantik und wachsender Verständlichkeit. Ergänzende Dokumentationen
werden mehr und mehr überflüssig gemäß dem Ziel, Code zu generieren,
der durch klare Strukturen und geeignete Namensgebung letztlich selbsterklärend
ist. Nach jeder Refaktorisierung muss durch Tests die unveränderte Semantik
geprüft werden.
Paarweise Programmierung (Pair Programming) führt nachweislich zu gleichen
bzw. geringeren Kosten als bei Einzelprogrammierung – bei weniger fehlerhaftem
Code und höherer Verständlichkeit des Codes. XP Entwickler arbeiten stets zu
zweit an einem Rechner, wobei einer der Entwickler programmiert, während der
andere logische und syntaktische Fehler beachtet sowie die Kompatibilität des
Codes zum Entwurf und die Vollständigkeit der Testfälle prüft. Entwickler-Paare
können sich für jedes Arbeitspaket neu bilden; hierdurch wird ein breites Know-
How jedes Entwicklers bzgl. des Gesamtsystems gewährleistet und die "Unentbehrlichkeit"
einzelner Entwickler ausgeschlossen.
Kollektives Eigentum von Code (Collective Ownership) bedeutet, dass jeder
Entwickler jeder Zeit Änderungen an jedem Code vornehmen kann. Auch hier gewährleistet
der unmittelbar anschliessende Test die unveränderte Semantik der zu
testenden Einheit. Das kollektive Eigentum von Code impliziert die gemeinsame
Verantwortlichkeit.
Fortlaufende Integration von Code (Continuous Integration) ermöglicht
schnellen Projektfortschritt dadurch, dass durch täglich mehrmalige Integration
neuer Komponenten in das bestehende System größere Integrationsprobleme vermieden
werden und alle beteiligten Entwickler umittelbar Gewissheit bzgl. der Integrationsfähigkeit
ihrer neu entwickelten Komponente haben. Das integrierte System
stellt ein in kurzen Zyklen permanent erweitertes, stets lauffähiges System
dar.
Die 40-Stunden-Woche (40-hour Week) minimiert die Fehleranfälligkeit von
Komponenten, die durch übermüdete, erschöpfte Entwickler implementiert werden.
Die Erfahrung zeigt: "Tired programmers make more mistakes."
Der Kunde vor Ort (On-site Customer) ist unerlässlich, da aufgrund der geringen
Granularität von Anforderungen aus dem Planungsprozess permanent Rücksprachemöglichkeit
mit einem Kundenvertreter im Projektteam zur Klärung von offenen
Punkten gewährleistet sein muß. Der Kunde vor Ort ist auch verantwortlich
für die Definition der Testfälle zu den Akzeptanz-Tests.
Programmierstandards (Coding Standard) sind ebenso unerlässlich, da insbesondere
die Praktiken Paarweise Programmierung, Kollektives Eigentum von
139

140
Code und Refaktorisierung mit dem Ziel, selbsterklärenden Code zu implementieren,
ohne Programmierstandards nicht durchführbar sind.
Abbildung 4.6-1 zeigt die Abhängigkeiten der zwölf Praktiken untereinander. Eine
Verbindungslinie zwischen zwei Praktiken weist darauf hin, dass diese beiden
Praktiken sich gegenseitig verstärken.
Kunde vor Ort
Metapher
Refactoring
Programmieren
in Paaren
Gemeinsame Verantwortlichkeit
Programmier-
standards
40-Stunden-Woche
Einfaches Design
Testen
Planungsspiel
Kurze Releasezyklen
Fortlaufende Integration
Die Abhängigkeiten der zwölf Praktiken untereinander
Abb. 4.6-1: Die Abhängigkeiten der zwölf Praktiken untereinander
[Beck 03]
4.7.3 Der XP Prozess
Quelle: Beck, K.; Extreme Programming. Das Manifest; Addison Wesley 2003

In diesem Abschnitt werden in Abb. 4.6.-2 zur Visualisierung eines XP-Projektes
diejenigen der zwölf o.g. Praktiken in ihren zyklischen Abläufen dargestellt, die
unmittelbar einer Projektphase bzw. dem Ergebnis einer Projektphase als
Voraussetzung für die folgende Projektphase entsprechen.
User Stories
Architectural
Spike
System
Metaphor
Uncertain
Estimates
Requirements
Release
Planning
Spike
Test Scenarios
New User Story
Project Velocity
Release
Plan
Confident
Estimates
Arbeitspakete
von 1-3 Tagen
Release-Zyklus
1-3 Monate
Iteration
Next Iteration
Iterationen
von 1-3 Wochen
Abb. 4.6-2: Zyklen im XP-Projekt, in Anlehnung an [Wells 00]
Acceptance
Tests
Small
Releases
Release-Zyklus (1-3 Monate)
Auswahl einer priorisierten User Story als Basis für die Implementierung des
nächsten kleinen Release.
In die Release Planung fliesst die Systemmethapher mit ein, um Entwicklung und
Kommunikation sowohl der Entwickler untereinander als auch mit dem Kunden
und dem Management zu unterstützen und zu fördern.
Iteration (1-3 Wochen)
141

142
In einzelnen Iterationen werden Komponenten implementiert und durch anschliessende
Akzeptanz-Tests die Korrektheit und Vollständigkeit der Komponenten
bzgl. der User Story und der zugehörigen Testfälle geprüft.

Arbeitspaket (1-3 Tage)
Im Rahmen eines Arbeitspaketes erstellen bzw. verbessern Entwickler-
Paare Komponenten (Refactoring), führen Tests durch und garantieren
durch kontinuierliche Integration die Verfügbarkeit eines permanent sich
weiterentwickelnden, lauffähigen Systems.
Jede Iteration kann durch Korrekturen an den User Stories in Zusammenarbeit
mit dem Kundenvertreter im Projektteam zu einer neuen, geänderten User
Story führen. Dies erfordert eine erneute Releaseplanung, um mit dem überarbeiteten
Releaseplan die nächste Iteration auf dem Weg zur Freigabe des aktuell
projektierten kleinen Releases zu ermöglichen. Der Prozess der Releaseplanung
ist dann abgeschlossen, wenn alle unsicheren Schätzungen (Uncertain Estimates)
durch sichere Schätzungen (Confident Estimates) ersetzt worden sind.
Der Release-Zyklus ist abgeschlossen, wenn das aktuell projektierte kleine Release
in die Produktion übernommen wurde.
4.7.4 Die Umsetzung
Die Durchführung eines XP-Projektes erfordert eine enge, permanente Zusammenarbeit
zwischen den Entwicklern, dem Management und dem Kunden, der insbesondere
durch seinen Kundenvertreter im Projektteam fortwährend in das Projektgeschehen
involviert ist. Der Kunde muss also die Bereitschaft besitzen, sich auf
alle XP-Praktiken einzulassen. Die räumliche Umgebung soll die hohen Anforderung
an die Kommunikation aller Beteiligten untereinander durch eine offene Arbeitsumgebung
unterstützen; die Ausstattung der Arbeitsplätze berücksichtigt die
Praxis der Paar-Programmierung. Ein Entwicklerteam sollte eine Größe von 10-15
Entwicklern haben.
Die Aufgabe des Managements besteht im Beobachten und Aufzeigen von Problemen,
deren Lösungsmöglichkeiten vom Kunden und den Entwicklern gemeinsam
erarbeitet wird. Durch die kurzen Iterationszyklen und die kontinuierliche Integration
sollten Änderungskosten höchstens logarithmisch mit der Zeit steigen.
Beck empfiehlt die schrittweise Einführung der einzelnen XP-Praktiken entsprechend
ihrer aktuellen Dringlichkeit und unter Berücksichtigung ihrer Abhängigkeiten
untereinander (vgl. Abb. 4.6.-1). Den vollständigen Wirkungsgrad erreicht
man jedoch immer erst bei vollständigem Einsatz aller Praktiken. "Einzelne Elemente
von XP können bedeutende Vorteile bringen. Ich glaube lediglich daran,
dass man sehr viel mehr gewinnen kann, wann man alle Einzelteile zusammenfügt."
[Beck 03]
143

144
4.7.5 Weiterführende Literatur
Als weiterführende Literatur werden neben den referenzierten Büchern und URLs
die folgenden "Standardwerke" und URLs empfohlen: eine Vertiefung zum Thema
Extremes Programmieren planen findet man in [BeckFowl 00] bzw. in der
deutschsprachige Version [BeckFowl 01], zum Schwerpunkt des Testens im
Rahmen des Extremen Programmierens in [Beck 02] (vgl. hierzu auch die
Literaturangaben aus Kapitel 8, Abschnitt JUnit), sowie zum Thema Refactoring in
Fowler's gleichnamigem Buch in der Originalfassung [Fowl 99] und der deutschen
Übersetzung [Fowl 00]. Wichtige URLs zum Thema Extreme Programming sind
Ward Cunningham's Wiki Wiki Web [Cunn], Ron Jeffries‘ Seite Xprogramming
[Jeff], sowie Don Wells‘ A gentle introduction zum Thema Extreme
Programming [Wells 03], die durch eine Verfeinerung einer Grafik in der Art von
Abb. 4.6-2 die unterschiedlichen Prozessebenen im Rahmen eines XP-Projektes
sehr schön visualisiert.
4.7.5.0.1 Literatur
[Beck 99] Beck, K.; Extreme Programming Explained: Embrace Change;
Reading/MA: AddisonWesley 1999
[BeckFowl 00] Beck, K., Fowler, M.; Planning Extreme Programming; Addison
Wesley 2000
[BeckFowl 01] Beck, K., Fowler, M.; Extreme Programming planen; Addison
Wesley 2001 (deutsche Übersetzung von [Beck 00])
[Beck 02] Beck, K.; Test-Driven Development; Addison Wesley 2002
[Beck 03] Beck, K.; Extreme Programming. Das Manifest; Addison Wesley
2003 (deutsche Übersetzung von [Beck 99])
[Fowl 99] Fowler M.; Refactoring; Addison Wesley 1999
[Fowl 00] Fowler M.; Refactoring. Wie Sie das Design vorhandener
Software verbessern; Addison Wesley 2000 (deutsche
Übersetzung von [Fowl 99]
URLs
[Cunn] http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
[Jeff] www.xprogramming.com/
[Jeff 04] http://c2.com/cgi/wiki?AreYouDoingXp
[Wells 00] www.extremeprogramming.org/map/project.html
[Wells 03] www.extremeprogramming.org
4.8 Prozessorientiertes Software-Qualitätsmanagement

4.8.1 Überblick
Qualität bei der Softwareentwicklung hat zwei Aspekte: Produkt- und
Prozessqualität. In diesem Abschnitt geht es um die Prozessqualität, d.h. um die
Qualität der Entwicklungsprozesse von Software. Warum ist die Qualität des
Entwicklungsprozesses von Software wichtig? Reicht nicht die Qualität des
Produktes aus, die z.B. mit guten Anforderungsdefinitionen und sorgfältigen Tests
gewährleistet wird? Die Antwort darauf ist ganz einfach:
Aus eigener Erfahrung werden Sie bereits Entwicklungsprojekte kennengelernt
haben, in denen die nachvollziehbare Umsetzung von Anforderungen systematisch
betrieben wurden. Daneben haben Sie sicherlich auch andere Entwicklungsprojekte
erlebt, in denen einfach drauf los entwickelt wurde. Entsprechend unterschiedlich
fällt in der Regel die Produktqualität aus.
Zusammengefasst heißt dies also: Die Produktqualität bei der Software-
Entwicklung hängt von der Qualität der Entwicklungsprozesse ab. Oder noch mehr
zugespitzt: Die Produktqualität von Software wird von der Prozessqualität
bestimmt. Dies ist die Ausgangshypothese der hier vorzustellenden
prozessorientierten Qualitätsmanagementansätze. (Dies heißt übrigens nicht, dass
produktbezogene Qualitätssicherung wie z.B. Testen jetzt überflüssig wäre!) Die
gute Botschaft daran ist, dass die Produktqualität durch die Einführung guter
Entwicklungsprozesse gesteuert werden kann. Doch was sind nun gute
Entwiclungsprozesse?
Bereits seit Anfang der 80er Jahre haben verschiedene Organisationen damit
begonnen, auf der Basis einer Vielzahl echter Projekterfahrungen wichtige
Elemente für erfolgreiche Software-Entwicklungsprozesse zu identifizieren.
Beispiele hierfür sind:
• Arbeiten mit Projektplänen
• Systematische Erfassung und Umsetzung der Kundenanforderungen
• Arbeiten mit Konfigurationsmanagementsystemen
Die in den 80er Jahren an verschiedenen Stellen begonnenen Arbeiten zur
systematischen Beschreibung, was ‚gute Software-Entwicklungsprozesse sind, hat
inzwischen zu einigen wichtigen Standardmodellen geführt:
• ISO 9000-Standards, insbes. ISO 9000-3 für die Software-Entwicklung
• ISO 12207
• ISO 15504, der sogenannte SPICE-Standard
(SPICE: Software Process Improvement and Capability dEtermination)
• CMM / CMMI des Software Engineering Institutes der Carnegie Mellon
University (CMMI: Capability Maturity Model Integration)
Die zunehmende Relevanz und Aktualität prozessorientierten Qualitätsmanagements
für die Software-Industrie wird beispielsweise daran deutlich,
145

146
dass sich die führenden deutschen Automobilhersteller (Daimler-Chrysler,
Volkswagen, Audi, BMW und Porsche) 2003 zu einer Hersteller-Arbeitsgruppe
zusammengeschlossen haben mit dem Ziel, auf Basis des SPICE-Standards einen
an die Automobil-Industrie angepassten Prozesstandard zu definieren, der sowohl
von ihnen selbst wie von allen Zulieferfirmen für ihre Autos bei der Software-
Entwicklung einzuhalten ist. Die Initiative hat unter der Bezeichnung ‚Hersteller-
Initiative Software die bisherigen Ergebnisse im Internet unter der Adresse
http://www.automotive-his.de/ bereitgestellt.
Charakteristisch für SPICE und CMMI ist, dass zwei Dimensionen bei der
Betrachtung der Entwicklungsprozesse unterschieden werden: die Prozessdimension
und die Fähigkeitsdimension:
• Die Prozessdimension enthält einen Katalog wichtiger Prozesse, die im
Bereich der Software-Entwicklung eine Rolle spielen. Insgesamt werden von
SPICE 5 Prozessgruppen mit insgesamt 40 Einzelprozessen definiert.
• In der Fähigkeitsdimension wird für jeden Prozess bewertet, wie gut er
umgesetzt wird. Die Güte der Umsetzung wird auch als Reife oder
Capability-Level bezeichnet. Insgesamt werden von SPICE 6 Capability-
Levels definiert mit insgesamt 9 Fähigkeitsbereichen, den sogenannten
Process Attributes.
Damit entsteht eine Matrix, bei der für jeden Einzelprozess eine individuelle
Bewertung der erreichten Fähigkeitsstufe möglich ist. Dieser
Gesamtzusammenhang ist in der folgenden Abbildung graphisch dargestellt:
Quelle: Qualität und Informatik, www.itq.ch
Wichtig ist in diesem Zusammenhang, dass es durchaus möglich ist, dass eine
Software-Entwicklungsorganisation bei einem Einzelprozess einen hohen
Reifegrad haben kann und bei einem anderen Einzelprozess einen ganz niedrigen
Reifegrad. Damit werden sehr differenzierte Fähigkeitsprofile für Software-
Entwicklungsorganisationen möglich, wie im folgenden Beispiel dargestellt.

Beispielsweise ist es denkbar, dass eine Firma sowohl Prozesse zur
Anforderungsanalyse definiert hat und spezielle Prozesse zum Software Entwurf
einsetzt. Während beispielsweise der Software Entwurf bereits sehr gut etabliert ist,
kann sie im Bereich Anforderungsanalyse noch ganz am Anfang stehen. Insgesamt
lässt sich dadurch ein sehr individuelles Fähigkeitsprofil für die einzelne Firma
erstellen und gezielte Verbesserungsmaßnahmen für einzelne Prozessbereiche
ableiten, wie in der nachfolgenden Abbildung anschaulich dargestellt wird:
Quelle: Qualität und Informatik, www.itq.ch
Am dargestellten Beispiel wird auch der Nutzen eines prozessorientierten
Qualitätsmanagements für die Software-Entwicklung auf Basis von SPICE oder
CMMI deutlich:
Mithilfe der in SPICE formulierten Prozessgebiete und den darauf bezogenen
Reifegradstufen ist es möglich, das Reifegradmodell einer ganzen Software-
Entwicklungs-Organisation systematisch, differenziert und nachvollziehbar zu
bewerten. Auf der Basis des Assessment-Ergebnisses kann die SW-
Entwicklungsorganisation gezielte Verbesserungsprogramme in den Feldern
anstoßen, wo sie den größten Nachholbedarf hat. Außerdem kann sie sich, wenn
sie gewisse Levels erreicht hat, als Zulieferer für andere große Firmen oder z.B. für
die öffentliche Hand qualifizieren.
Normen wie SPICE oder CMMI liefern damit zusammenfassend:
• ein inhaltliches Referenzmodell, welche Prozesse inhaltlich zu einem guten
Software-Entwiclungsprozess gehören
• bewährte und objektive Bewertungsmaßstäbe, um festzustellen, wie gut
einzelne Prozesse durchgeführt werden
• Hinweise für Ansatzpunkte, um gezielte Verbesserungen in den Software
Entwicklungsprozessen zu erreichen.
In den folgenden Abschnitten werden diese Aspekte im einzelnen vorgestellt. Da
CMMI und SPICE inhaltlich zueinander konsistent sind und der gleichen
Grundstruktur folgen, wird im folgenden das SPICE-Modell detaillierter betrachtet.
Zunächst erfolgt eine detaillierte Darstellung des Prozessmodells von SPCIE (ISO
147

148
15504 / 12207). Danach werden das durch SPICE definierte Reifegradmodell und
aufgrund seiner besonderen Bedeutung das Risikomanagement gemäß SPICE
vorgestellt, bevor aufgezeigt wird, wie beide Aspekte zusammen (Prozess- und
Reifegrad-Dimension) für sogenannte Assessments eingesetzt werden können.
Zum Abschluß erfolgt ein kurze Einführung von CMM / CMMI und ein Vergleich
der beiden Ansätze CMMI und SPICE.
4.8.2 Das ISO 15504 / ISO 12207 (SPICE) Prozessmodell
Die ISO 15504 beschreibt ein detailliertes Prozeßmodell für die Softwareentwicklung.
Die Prozeßbeschreibung enthält für jeden Prozeß den Zweck des
Prozesses, die Ergebnisse, die mit dem Prozeß erreicht werden, die
Grundtätigkeiten, die auszuführen sind, um die Ziele zu erreichen, und eine
Beschreibung der Eingangsinformationen und Arbeitsergebnisse (Workproducts)
jedes Prozesses. Es werden insgesamt 40 Einzelprozesse in 5 Kategorien
beschrieben.
Die Prozesse werden in 3 Gruppen eingeteilt:
• Primäre Lebenszyklus Prozesse (Primary life cycle processes) mit den
Kategorien
• Kunden - Lieferanten Prozesse
• Engineering Prozesse
• Unterstützende Lebenszyklus Prozesse (Supporting life cycle processes) mit
der Kategorie
• Support
• und organisatorische Lebenszyklus Prozesse (Organization life cycle
processes) mit den Kategorien
• Managment
• Organisation
K u n d e n - L i e f e r a n t e n
E n g i n e e r i n g
M a n a g e m e n t
O r g a n i s a t i o n
S u p p o r t

Prozesse des Primären Lebenszyklus
P r i m a r y l i f e c y c l e p r o c e s s e s
C u s t o m e r - S u p p l i e r
C U S . 1 A c q u i s i t i o n
E n g i n e e r i n g
A c q u i s i t i o n P r e p a r a t i o n
S u p p l i e r S e l e c t i o n
S u p p l i e r M o n i t o r i n g
C u s t o m e r A c c e p t a n c e
C U S . 3
R e q u i r e m e n t s E l i c i t a t i o n
E N G . 1 D e v e l o p m e n t
S y s t e m r e q u i r e m e n t s
a n a l y s i s a n d d e s i g n
S o f t w a r e r e q u i r e m e n t s
a n a l y s i s
S o f t w a r e d e s i g n
S o f t w a r e c o n s t r u c t i o n
C U S . 2 S u p p l y
C U S . 4 O p e r a t i o n
O p e r a t i o n a l U s e
C u s t o m e r S u p p o r t
S o f t w a r e i n t e g r a t i o n
S o f t w a r e t e s t i n g
S y s t e m i n t e g r a t i o n a n d t e s t i n g
E N G . 2 S y s t e m a n d s o f t w a r e m a i n t e n a n c e
4.8.2.1 Die Kunden Lieferanten Kategorie (CUS)
CUS.1 Acquisition Process
Der Zweck des Aquisitionsprozesses ist es Produkte oder Dienstleistungen zu
kaufen, die den Bedarf des Kunden erfüllen. Er beginnt mit der Identifikation der
Anforderungen und endet mit der Akzeptanz des Produktes oder der Leistung die
der Kunde benötigt. Der Prozeß besitzt 4 weitere Unterprozesse
CUS.1.1 Acquisition Preparation Process
149

150
Der Zweck des Akquisitions Vorbereitungs Prozesses ist es den Bedarf und die
Ziele der Akquisition zu ermitteln, die Anforderungen aufzuschreiben, eine
Einkaufsstrategie zu entwickeln und Akzeptanzkriterien zu definieren
CUS.1.2 Supplier Selection Process
Ziel des Lieferantenauswahlprozesses ist es eine Organisation zu finden, die für die
Implementierung des gewünschten Produkts verantwortlich ist. Aufgabe ist es eine
Ausschreibung zu erzeugen, den Lieferanten auf Grund seines Angebots und seiner
Fähigkeiten auszuwählen und einen Vertrag zwischen Kunden und Lieferanten zu
etablieren
CUS.1.3 Supplier Monitoring Process
Der Zweck des Monitoring Prozesses ist es die Aktivitäten des Lieferanten und den
technischen Fortschritt während der Entwicklung durch gemeinsame Aktivitäten
und die Kontrolle von regelmäßigen Informationen zu überwachen.
CUS.1.4 Customer Acceptance Process
Der Zweck des Akzeptanz Prozesses ist es zu überprüfen, ob das gelieferte Produkt
oder die gelieferte Leistung allen definierten Kriterien und den gestellten
Anforderungen entspricht
CUS.2 Supply Process
Der Zweck des Lieferprozesses ist es dem Kunden Software zur Verfügung zu
stellen, die den vereinbarten Anforderungen genügt. Dazu gehört ein Angebot auf
die Anfrage des Kunden, der Abschluß eines Vertrags zwischen Kunde und
Lieferant über Entwicklung, Lieferung und Installation von Software, die
Entwicklung einer Software, die den Anforderungen genügt, und die Lieferung
und Installation der Software
CUS.3 Requirements Elicitation Process
Die Aufgabe des Requirements Elicitation Prozesses (Sammlung von
Anforderungen) ist es über den Lebenszyklus eines Produkts oder einer
Dienstleistung die sich entwickelnden Anforderungen der Kunden zu ermitteln und
damit eine Basis für neue Software oder neue Produkte zu schaffen. Dazu wird eine
regelmäßige Kommunikation mit dem Kunden etabliert, es werden die
Anforderungen der Kunden definiert und ein Mechanismus zur regelmäßigen
Beobachtung der Kundenbedürfnisse geschaffen. Fortschritte durch sich ändernde
Technologien und Kundenbedürfnisse werden beobachtet und der Einfluß
berücksichtigt.
CUS.4 Operation Process

Der Zweck des Operations Prozesses ist es die Software in ihrer vorgesehenen
Umgebung zu betreiben und den Kunden durch Support zu unterstützen. Der
Prozess besitzt zwei Unterprozesse:
CUS.4.1 Operational Use Process
Der Zweck des Operational Use Prozesses ist es der korrekte und effiziente Betrieb
der Software.. Dazu gehören die Identifikation und Überwachung von Risiken bei
der Einführung der Software, der eigentliche Betrieb der Software in ihrer
vorgesehenen Umgebung und die Überprüfung, dass die Software Kapazitäten den
Bedürfnissen des Kunden genügen.
CUS.4.2 Customer Support Process
Die Aufgabe des Customer Suppport Prozesses ist es einen Service auf einem
akzeptierten Level einzurichten und zu unterhalten. Dazu gehören die Erfassung
und Beobachtung der Servicebedürfnisse des Kunden, die regelmäßige Evaluierung
der Kundenzufriedenheit mit Service und Produkt, die Durchführung des Supports
durch Unterstützung des Kunden bei operationalen Problemen
4.8.2.2 Die Engineering Kategorie
ENG.1 Development process
Der Zweck des Enwicklungsprozesses ist es eine Menge von Anforderungen in ein
funktionierendes Softwareprodukt oder ein softwarebasiertes System zu
transformieren. Der Entwicklungsprozess besitzt insgesamt sieben Teilprozesse.
Die Teilprozesse müssen dabei nicht sequentiell durchgeführt werden. Die ersten
Grundtätigkeiten des Testprozesses und der Integrationsprozesse werden z.B.
gleichzeitig mit dem Requirements Analyse Prozess durchgeführt. In einem
Iterativen Vorgehensmodell oder in einem Spiralmodell werden die Prozesse zum
Teil mehrfach durchlaufen.
Der am häufigsten anzutreffende Entwicklungsprozeß
151

152
ENG.1.1 System requirements analysis and design process
Die Aufgabe des System Requirements Analysis und Design Prozesses ist es die
funktionalen und nicht funktionalen Anforderungen (Requirements) an das System
zu erstellen, eine System Architektur zu beschreiben und eine Zuordnung von
Anforderungen zu den Hauptelementen des Systems und zu den Releases des
Systems zu treffen.
ENG.1.2 Software requirements analysis process
Die Aufgabe des Software Requirements Analysis Prozesses ist es die
Anforderungen an die Softwarekomponenten zu erstellen. Dabei werden die
Anforderungen Softwarekomponenten zugeordnet und die Interfaces zwischen den
Komponenten beschrieben. Die Anforderungen werden analysiert, auf Korrektheit
und Testbarkeit überprüft. Der Einfluß der Softwareanforderungen auf die
Laufzeitumgebung wird verstanden. Eine Software Release Strategie wird
entwickelt und ein Mechanismus zur Verfolgung der Anforderungen über den
Entwicklungsprozeß wird etabliert.
ENG.1.3 Software design process
Die Aufgabe des Design Prozesses ist es ein Design für die Software zu
entwickeln, das die Anforderungen erfüllt. Dabei ist ein architektonisches Design
zu entwickeln, das die Haupt Software Komponenten beschreibt, es sind die
internen und externen Schnittstellen jeder Softwarekomponente zu beschreiben und
es ist ein detailliertes Design ist zu entwickeln, das Softwareeinheiten beschreibt,
die implementiert und getestet werden können.
Es ist die Konsistenz zwischen Anforderungen und Design nachzuweisen.
ENG.1.4 Software construction process
Die Aufgabe des Software Konstruktions Prozesses ist es ausführbare
Softwareeinheiten zu produzieren, die dem Design und den Anforderungen
entsprechen. Dazu sind Verifikationskriterien für die Software zu definieren, die
Softwareeinheiten müssen erzeugt werden und es muss der Test gegen die
Verifikationskriterien durchgeführt werden.
ENG.1.5 Software integration process
Die Aufgabe des Integrationsprozesses ist es die Softwareeinheiten zu größeren
integrierten Einheiten zusammenzufügen. Dazu ist eine Integrationsstrategie zu
entwicklen, die beschreibt in welcher Reihenfolge und zu welchen integrierten
Einheiten die Software zusammengefügt wird, es sind Verificationskriterien für die
integrierten Einheiten zu entwicklen, die integrierten Einheiten sind zu produzieren
und gegen die Verifikationskriterien zu testen. Die Testergebnisse werden
protokolliert. Es ist eine Regressionstest Strategie zu entwickeln, die angibt welche

Tests bei Fehler oder Änderungen an den Softwareeinheiten durchzuführen sind.
Die Regressionstests sind bei Bedarf durchzuführen.
ENG.1.6 Software testing process
Der Software Test Prozeß testet die integrierte Software gegen die Akzeptanz-
Kriterien der Software Anforderungen. Dazu werden Akzeptanz Kriterien
entwickelt (zeitlich normalerweise parallel zum Software Requirements Analysis
Prozess), die Tests werden gegen die Akzeptanz-Kriterien durchgeführt und die
Ergebnisse protokolliert.
ENG.1.7 System integration and testing process
Der Zweck des System Integrationsprozesses ist es die Software mit anderen
Komponenten (z.B. Hardware) zu integrieren um ein Gesamtsystem zu bekommen.
Es sind eine Integrationsstrategie für das System und Akzeptanzkriterien zu
entwickeln. Die Integration und die Tests sind durchzuführen durch Bildung von
Systemaggregaten, bis das Gesamtsystem entstanden ist. Der Nachweis aller
Anforderungen (funktionale, nicht-funtionale, operationale, Wartung) am
Gesamtsystem ist durchzuführen und zu protokollieren. Eine
Regressionsteststrategie für Änderungen an Systemkomponenten ist zu entwickeln
und bei Bedarf durchzuführen.
ENG.2 System and software maintenance process
Die Aufgabe des System und Software Wartungsprozesses ist es die Änderungen,
Weiterentwicklungen und den Ausfall von Komponenten auf Anforderung des
Kunden zu managen. Die Ursache der Anforderungen können erkannte Probleme
oder der Wunsch nach Verbesserung oder Anpassung sein. Das Ziel ist es das
System oder die Software zu modifizieren oder zu entfernen bei gleichzeitigem
Erhalt der Integrität der Kundenprozesse. Dazu ist eine Wartungsstrategie zu
schaffen, die die Änderung, die Modifikation oder die Entfernung von
Systemkomponenten berücksichtigt. Es sind die Rückwirkungen auf das
bestehende System zu ermitteln. Es sind die Spezifikationen, Designs und
Teststrategien zu erneuern. Die modifizierten Komponenten sind zu entwickeln
und zu testen. Updates sind beim Kunden einzuspielen.
Auf Anforderung sind Software und System in kontrollierter Form mit minimaler
Störung des Kunden zu entfernen.
4.8.2.3 Die unterstützenden Prozesse
153

154
S u p p o r t i n g l i f e c y c l e p r o c e s s e s
S U P . 1 D o c u m e n t a t i o n P r o c e s s
S U P . 2 C o n f i g u r a t i o n M a n a g e m e n t P r o c e s s
S U P . 3 Q u a l i t y A s s u r a n c e P r o c e s s
S U P . 4 V e r i f i c a t i o n P r o c e s s
S U P . 5 V a l i d a t i o n P r o c e s s
S U P . 6 J o i n t R e v i e w P r o c e s s
S U P . 7 A u d i t P r o c e s s
S U P . 8 P r o b l e m R e s o l u t i o n P r o c e s s
Die unterstützenden Prozesse, sind Hilfsprozesse die im Rahmen der Durchführung
anderer Prozesse an unterschiedlichen Stellen Unterstützung leisten.
SUP.1 Documentation Process
Die Aufgabe des Dokumentationsprozesses ist es Dokumente zu entwickeln und zu
warten die Inhalte besitzen, die von anderen Prozessen oder Aktivitäten erzeugt
werden. Dazu gehört die Entwicklung einer Strategie zur eindeutigen Identifikation
von Dokumenten, die Benennung von Standards zur Erzeugung von Dokumenten,
die eindeutige Identifikation von Dokumenten, die Definition des Inhalts und
Zwecks von Dokumenten, die Sicherstellung, dass die Dokumente den
angegebenen Standards entsprechen und die Sicherstellung der Wartung von
Dokumenten.
Der Dokumentationsprozeß ist ein Prozeß der die Prozessattribute auf
Fähigkeitslevel 2 (ISO15504) unterstützt.
SUP.2 Configuration Management Process
Der Zweck des Konfigurationsmanagement Prozesses ist die Einführung und
Erhaltung der Integrität von allen Arbeitsergebnissen eines Projekts. Dazu ist eine
Konfigurationsmanagementstrategie zu entwickeln, alle Arbeitsergebnisse eines

Prozesses oder Projekts sind zu identifizieren, und zu versionieren, Modifikationen
und Releases sind zu kontrollieren, der Status und die Änderungsanforderungen
werden protokolliert, die Vollständigkeit und Konsistenz wird sichergestellt und
die Speicherung und Auslieferung von Arbeitsergebnissen wird kontrolliert.
SUP.3 Quality Assurance Process
Zweck des Qualitätssicherung Prozesses ist es sicherzustellen, dass die
Arbeitsergebnisse und Tätigkeiten eines Prozesses oder Projekts den
Anforderungen genügen und den Plänen entsprechen. Dazu wird eine Strategie zur
Leitung der Qualitätssicherungsaktivitäten und Aufgaben entwickelt, durchgeführt
und gewartet. Es wird sichergestellt, dass die Qualitätssicherungs-Aktivitäten und
Aufgaben nachvollziehbar sind. Es wird verifiziert, dass die Software-Produkte,
Prozesse und Aktivitäten den anwendbaren Standards, Prozeduren und
Anforderungen genügen.
Der Qualitätssicherungsprozess muss unabhängig sein und es sollte keine direkte
Abhängigkeit zu Personen existieren, die die Software entwickeln oder die
Entwicklung steuern.
Der Qualitätssicherungsprozeß benutzt zur Durchführung weitere Support Prozesse
wir Verification, Validation, Joint Reviews, Audits und den Problem Lösungs
Prozeß.
Die Durchführung des Qualitätssicherungsprozesses ist notwendig für alle
primären Prozesse um den Reifegrad 2 zu erhalten.
SUP.4 Verification Process
Der Zweck des Verifikationsprozesses ist es, zu gewährleisten, dass alle
Arbeitsergebnisse oder Dienstleistungen eines Prozesses oder Projektes den
Anforderungen genügen. Dazu wird eine Strategie entwickelt, es werden
Verifikationskriterien für alle Produkte definiert und die Produkte gegen diese
Kriterien geprüft. Die Ursachen der identifizierten Defekte werden gesucht und
beseitigt. Die Ergebnisse werden protokolliert und dem Kunden zugänglich
gemacht.
Dieser Prozeß ist eng verbunden mit dem Integrations- und dem Testprozeß, aber
auch alle anderen Prozesse die Arbeitsergebnisse erzeugen werden durch diesen
Prozeß unterstützt. Auch Requirementsdokumente, Designs und Projektpläne sind
Arbeitsergebnisse, für die Qualitätskriterien gelten.
SUP.5 Validation Process
Der Zweck des Validationsprozesses ist es sicherzustellen, dass ein Produkt oder
die Arbeitsergebnisse die Anforderungen für die gewünschte Anwendung erfüllt.
Im Gegensatz zum Verifikationsprozeß, der die Konformität mit den gestellten
Anforderungen (Requirements) nachweisen soll, wird hier überprüft, ob das daraus
entstandene Produkt auch die gewünschte Anwendungsaufgabe erfüllt. Dazu ist
155

156
eine Validationsstrategie zu entwicklen, die Aktivitäten sind durchzuführen und zu
protokollieren. Die gefundenen Probleme werden gelöst.
Dieser Prozeß ist eng gekoppelt mit der Ausführung des System Integrations- und
Test Prozesses.
SUP.6 Joint Review Process
Der Zweck des Joint Review Prozesses ist es ein gemeinsames Verständinis mit
dem Kunden über den Fortschritt der Entwicklungsprojekts zu gewinnen. Joint
Reviews gibt es sowohl auf dem Management als auch auf dem technischen Level
und sie werden über die gesamte Projektlaufzeit in regelmäßigen Abständen und an
vordefinierten besonderen Meilensteinen durchgeführt. Dabei werden der Status
und die Ergebnisse von Prozessen durch gemeinsame Reviews von Kunden,
Entwicklern, Zulieferern und anderen interessierten Teilen begutachtet. Aus den
Reviews werden Maßnahmen abgeleitet und diese werden bis zu ihrer Erfüllung
verfolgt.
Dieser Prozeß ist eine unterstützender Prozeß für das Projektmanagement Attribut
von Prozessen auf Level 2 der Fähigkeitenskala
SUP.7 Audit Process
Der Auditprozeß gewährleistet die unabhängige Beurteilung von Produkten,
Prozessen, Anfoderungen, Plänen und Verträgen. Die Audits werden an
vordefinierten Meilensteinen durch eine geeignete, unabhängige Partei
durchgeführt, die Probleme werden protokolliert und kommuniziert. Die Probleme
werden durch die für die Beseitigung verantwortliche Partei gelöst.
Mögliche Audits für den Softwareentwicklungsprozeß sind
• Der Vertrag genügt den Anforderungen der Organisation
4 Die Systemspezfikation genügt den Requirements
5 Das Design genügt der Spezifikation
6 Das Softwareprodukt entspricht dem Design
7 Die Testabdeckung entspricht den Qualitätssicherungsanforderungen
8 Die Qualität des Softwareprodukts entspricht den Standards der Organisation
9 Die Dokumentation stimmt mit den Kundenanforderungen überein
Mögliche Audits für die Managementaktivitäten
1 Angebot im Vergleich zu Anforderungen
2 Erreichte Fortschritte im Vergleich zu Projekt- und Zeitplan
3 Risiko Kontrolle
4 Einhaltung von angemessenen Standards
Besonders wichtig ist die Unabhängigkeit und fachliche Qualifikation der
Auditoren, die auch eine weitgehende finanzielle Unabhängigkeit voraussetzt. Eine
Beauftragung des Auditors durch den Lieferanten (ISO9000) kann dies kaum
gewährleisten.

SUP.8 Problem Resolution Process
Die Aufgabe des Problem Lösungs Prozesses ist es, sicherzustellen, dass alle
entdeckten Probleme analysiert und gelöst werden.
• Grundaufgaben dieses Prozesses sind die Einrichtung eines Problem Report
Systems,
• die Priorisierung von Problemen,
• die Definitionen von Aktionen zur Behebung von Problemen,
• die Verfolgung der Aktionen,
• die Verteilung der Lösungen nach Review und Freigabe und
• die Analyse von Problem Trends.
157

158
Die Organisations-Prozesse
O r g a n i z a t i o n a l l i f e c y c l e p r o c e s s e s
M a n a g e m e n t
M A N . 1 M a n a g e m e n t P r o c e s s
M A N . 2 P r o j e c t M a n a g e m e n t P r o c e s s
M A N . 3 Q u a l i t y M a n a g e m e n t
M A N . 4 R i s k M a n a g e m e n t
O r g a n i z a t i o n
O R G . 1 O r g a n i z a t i o n a l a l i g n m e n t p r o c e s s
O R G . 2 I m p r o v e m e n t p r o c e s s
P r o c e s s e s t a b l i s h m e n t p r o c e s s
P r o c e s s a s s e s s m e n t p r o c e s s
P r o c e s s i m p r o v e m e n t p r o c e s s
O R G . 3 H u m a n R e s o u r c e M a n a g e m e n t p r o c e s s
O R G . 4 I n f r a s t r u c t u r e p r o c e s s
O R G . 5 M e a s u r e m e n t P r o c e s s
O R G . 6 R e u s e P r o c e s s
4.8.2.4 Die Management Prozess Kategorie
In der Managment Prozess Kategorie befinden sich Prozesse mit generischen
Tätigkeiten, die von jedem anderen Prozess im Software Lebenszyklus benutzt
werden können.

MAN.1 Management Process
Die Aufgabe des Management Prozesses ist es den Start und die Durchführung
jeglichen Prozesses oder Funktion zu initieren, zu überwachen und zu steuern, so
dass sie ihre Ziele effektiv erreichen.
• Dabei werden die Aktivitäten und Aufgaben, die Durchzuführen sind, um
den Zweck des Prozesses zu erreichen, identifiziert,
• es wird die Machbarkeit der Ziele mit den vorhandenen Ressourcen und
Randbedingungen evaluiert,
• die Ressourcen und Infrastrukturen werden zur Verfügung gestellt,
• Aktivitäten und Aufgaben werden gestartet,
• die Performance der Aktivitäten wird überwacht,
• die Arbeitsprodukte werden überprüft und die Ergebnisse analysiert und
evaluiert,
• Aktionen zur Änderung der Performance bei Abweichungen werden
durchgeführt
• und die erfolgreiche Durchführung des Prozesses wird nachgewiesen.
MAN.2 Project Management Process
Der Projektmanagement Prozeß ist die spezielle Ausprägung von MAN.1 für
Projekte.
Die Aufgabe des Projekt Management Prozesses ist es alle Aufgaben, Aktivitäten
und Ressourcen, die notwendig sind um ein Produkt oder eine Dienstleitung zu
erhalten, zu identifizieren, einzurichten, zu koordinieren und zu überwachen.
Dazu wird der Rahmen der Arbeit des Projektes definiert
Die Machbarkeit des Ziels des Projekts mit vorhandenen Ressourcen und
Randbedingungen evaluiert,
Die Aufgaben und Ressourcen, die notwendig sind um die vollständige Arbeit zu
erledigen werden in ihrer Größe geschätzt
Die Schnittstellen zwischen dem Projekt und anderen Projekten oder
organisatorischen Einheiten werden identifiziert und überwacht
Pläne für die Ausführung des Projekts werden entwickelt und umgesetzt
Der Fortschritt des Projekts wird beobachtet und berichtet
Aktionen zur Korrektur von Abweichungen und zur Vermeidung der
Wiederholung von Problemen werden durchgeführt, wenn die Projektziele nicht
erreicht werden
Der Projektmanagement Prozeß ist ein generischer Prozeß, der in anderen Prozeß
wieder auftaucht. Die Grundaufgaben des jeweiligen Prozesses sind die zu
planenden Aktivitäten im Projektmanagement. Eine Überprüfung dieses Prozesses
bedeutet daher die Kontrolle ob jeder primäre Prozesse mindestens auf
159

160
Fähigkeitenlevel 2 sich befindet, dann befindet sich der Managementprozeß auf
Level 1, d.h. er ist durchgeführt.
Projektmanagement setzt daher die genaue Kenntnis der zu managenden
Grundprozesse voraus, ihrer Grundtätigkeiten und ihrer Arbeitsprodukte. Der
universelle Projektmanager, der nur Erfahrungen in Projektmanagement besitzt ist
daher nicht möglich.
MAN.3 Quality Management
Die Aufgabe des Qualitätsmanagements ist es die Qualität der Produkte oder
Dienstleistungen eines Projekts zu überwachen, so dass sie den Kunden zufrieden
stellen. Dieser Prozeß geht über die Qualitätssicherung von SUP.3 hinaus. Er setzt
die Messung der Qualität sowohl von Produkten als auch von Prozessen mit Hilfe
von Metriken voraus, mit deren Hilfe eine Steuerung der Qualität möglich ist.
MAN.4 Risk Management
Die Aufgabe des Risikomanagement Prozesses ist es Projektrisiken kontinuierlich
über den gesamten Lebenszyklus zu identifizieren und zu vermeiden. Dazu gehört
die Identifikation, Analyse und Priorisierung von Risiken, die Planung und
Durchführung von Maßnahmen zur Risikovermeidung, die Verfolgung von
Risiken und die Durchführung von Korrektiven Aktionen wenn die
Risikovermeidung nicht funtioniert.
4.8.2.5 Die Organisations Prozeß Kategorie
Die Organisationsprozesse sind Prozesse die einer Organisation helfen die
Geschäftsziele als ganzes zu erreichen. Die Organisationsprozesse sind notwendig
zur Erreichung der Reifegradstufen 3-5, d.h. sie unterstützen die Wiederholbarkeit
von Projekten (ORG.2.1, ORG.3, ORG.4) die Steuerbarkeit von Prozessen durch
Messungen (ORG.1, ORG.5) und die Optimierung von Organisation und
Prozessen (ORG.2.3, ORG.1)
ORG.1 Organizational alignment process
Der Zweck des Organizational Alignment Prozesses ist es, daß alle Mitarbeiter
einer Organisation eine gemeinsame Vision, Kultur und Verständnis der
Geschäftsziele haben.
ORG.2 Improvement process
Das Ziel des Improvement Prozesses ist es einen Software Lifecycle Prozeß zu
etablieren, zu überwachen, zu steuern und zu verbessern.
• Dazu gehört die Einrichtung einer Standardmenge von Prozessen,

• die detaillierten Aufgaben und Arbeitsergebnisse der Prozesse sind
beschrieben,
• zusammen mit erwarteten Performance Charakteristiken,
• es existiert eine Strategie zur Anpassung der Prozesse an die Projektgröße
(Tailoring)
• es existiert eine Beschreibung zur Benutzung der Prozesse
ORG.2.1 Process establishment process
Die Aufgabe des Process Establishment Prozesses ist die Einrichtung eines Satzes
von Standardprozessen für den Software Lebenszyklus
ORG.2.2 Process assessment process
Der Prozess Assessment Prozeß untersucht die Standard Softwareentwicklungsprozesse
mit Hilfe von Assessments und deckt Schwachstellen auf.
Die relativen Stärken und Schwächen der Standardprozesse geben Informationen
für einen kontinuierlichen Verbesserungsprozeß
ORG.2.3 Process improvement process
Der kontinuierliche verbesserungsprozeß hat die Aufgabe durch kontrollierte
Änderung der Standards die Effektivität und Effizienz der Prozesse, die in einem
Unternehmen genutzt werden, ständig zu erhöhen.
ORG.3 Human Resource Management process
Der Zweck des Human Resource Management Prozesses ist es der Organisation
und den Projekten zu genügend ausgebildete Mitarbeiter zur Verfügung zu stellen,
die Fähigkeiten und Wissen besitzen um ihre Rolle effektiv zu erfüllen und als
Gruppe zusammenarbeiten zu können.
Dazu gehört die Identifikation der benötigten Fähigkeiten und des benötigten
Trainings und die Durchführung des Trainings.
ORG.4 Infrastructure process
Die Aufgabe des Infrastrukturprozesses ist es eine stabile und verlässliche
Infrastruktur aus Hardware, Software, Tools, Standards, Methoden, Techniken und
Gebäuden für Entwicklung, Betrieb und Wartung zur Verfügung zu stellen.
ORG.5 Measurement Process
Das Ziel des Mess-Prozesses ist es Daten, die Produkte und die Prozesse einer
Organisation betreffend, zu sammeln und zu analysieren um das Management der
Prozesse effektiv zu unterstützen und die Qualität der Produkte zu demonstrieren.
161

162
ORG.6 Reuse Process
Die Aufgabe des Reuse Prozesses ist es die Wiederverwendung von existierenden
und neuen Softwareprodukten zu fördern und zu unterstützen. Dazu gehört die
Entwicklung einer Wiederverwendungsstrategie und die Einrichtung und Wartung
einer Infrastruktur für Wiederverwendung
4.8.2.6 Prozeß Tailoring
Eine der wichtigsten Aufgaben zu Anfang eines jedes Projektes ist das
Prozeßtailoring des Prozeßmodells. Die Komplexität von Softwareprojekten ist
sehr unterschiedlich und kann vom kleinen Hilfsprogramm, das in einer Stunde
entwickelt ist bis zum Großprojekt mit 100 Mannjahren Entwicklungsaufwand
reichen. Die Aktivitäten müssen daher dem jeweiligen Projekt angepasst werden.
Diesen Prozeß nennt man Prozeß-Tailoring (Tailor=Schneider).
Grundsätzlich gilt die Regel: Je höher die Komplexität einer Aufgabe desto höher
muß die Prozeßqualiät sein. Das Tailoring erfordert normalerweise sehr viel
Erfahrung im entsprechenden Bereich. Viele Projekte scheitern, weil den
Projektleitern eben diese Erfahrung fehlt und sie deshalb wichtige Tätigkeiten
weglassen oder die Qualität von Arbeitsergebnissen nicht sicherstellen. Trotzdem
ist zu beachten, dass auch der umgekehrte Fall vorkommen kann, dass ein Projekt
scheitert, weil die Prozesse zu umfangreich sind. Dies Fall tritt aber nur sehr selten
auf. Ausserdem gilt, dass gute Softwareentwicklungsprozesse eine Voraussetzung
für den Erfolg sind, aber keine Garantie. Die Umkehrung gilt aber fast immer:
Wenn die Entwicklungsprozesse in einem großen Projekt nicht ausreichend sind,
wird das Projekt ein Mißerfolg!
4.8.3 Das ISO 15504 / ISO 12207 Reifegradmodell
Wie oben bereits kurz dargestellt, ist das ISO 15504-Schema zweidimensional
strukturiert, nämlich in die Prozess- und in die Reifegrad-Dimension: In der
Process Dimension werden die für einen guten Software-Entwicklungsprozess
geforderten Einzelprozesse beschrieben (vgl. vorigen Abschnitt). In der Capability
Dimension werden verschiedene Reifegradstufen bei der Ausführung dieser Einzelprozesse
unterschieden, wie in der folgenden Abbildung dargestellt wird:

Zur Einstufung eines Einzelprozesses in eine bestimmte Reifegradstufe werden
sogenannte Prozessattribute (process attributes) herangezogen. Prozessattribute
sind objektiv beobacht- und messbare Qualitätseigenschaften bei der Durchführung
von Software-Entwicklungsprozessen. Prozessattribute stellen für jeden
betrachteten Einzelprozess einen Bewertungsmaßstab dar für die darin erreichte
Reife. Insgesamt werden von SPICE 6 Reifegradstufen (Capability Levels) mit
zusammen 9 Gruppen von Prozessattributen (Process Attributes) unterschieden:
Reifegradstufen und Prozess-Attribute gemäß ISO 15504-2
Process
Capability Levels
Attribute ID
and Process Attributes
Level 0 : Incomplete process
Level 1 : Performed process
PA 1.1 Process performance
Level 2 : Managed process
PA 2.1 Performance management
PA 2.2 Work product management
Level 3 : Established process
PA 3.1 Process definition
PA 3.2 Process resource
Level 4 : Predictable process
PA 4.1 Measurement
PA 4.2 Process control
Level 5 : Optimizing process
PA 5.1 Process change
PA 5.2 Continuous improvement
Die einzelnen Reifegradstufen sind wiederum so abgestuft, dass der Fortschritt von
einer zur nächsten Stufe jeweils eine signifikante Verbesserung in der
Durchführung des betrachteten Einzelprozesses darstellt. Die Stufenabfolge
insgesamt stellt daher einen schrittweisen Verbesserungsprozess gemäß ISO/IEC
TR 15504-2 dar.:
163

164
Quelle: Qualität und Informatik, www.itq.ch
Capability Levels als Roadmap für einen Verbesserungsprozess
Im folgenden werden die einzelnen Reifegradstufen mit den Prozessattributen
vorgestellt. Danach wird am Beispiel des Prozessbereichs Projektmanagement
illustriert, wie die Anforderungen an die Beherrschung des Projektmanagements
von Capability-Level zu Capability-Level zunehmen. In analoger Weise werden
für alle von SPICE geforderten Einzelprozesse stufenweise zunehmende
Anforderungen an die Beherrschung der Einzelprozesse von Capability-Level zu
Capability-Level definiert.
4.8.3.1 Stufe 0 - Unvollständiger Prozess (Incomplete)
Kurzbeschreibung:
Es gibt nur wenige oder gar keine klar beschriebenen Ziele und Arbeitsergebnisse
des Prozesses. Es ist deshalb nicht feststellbar, ob der Prozess überhaupt greifbare
Ergebnisse bringt und es ist davon auszugehen, dass der Prozess nicht verstanden
ist.
Prozessattribute:
Für die Stufe 0 gibt es keine speziellen Prozessattribute.
Bei Prozessen der Stufe 0 ist unklar, wie das Ergebnis überhaupt zustande kam

4.8.3.2 Stufe 1 - Durchgeführter Prozess (Performed)
Kurzbeschreibung:
Der Gesamtprozess ist weitgehend verstanden. Die Zielsetzung und die Ergebnisse
des Einzelprozesses wird in der Regel erreicht. Die Zielerreichung wird in der
Regel jedoch nicht systematisch geplant und kontrolliert. Einzelpersonen innerhalb
der Organisation erkennen, dass gewisse Aktionen durchgeführt werden müssen.
Es ist allgemein akzeptiert, dass diese Aktion dann durchgeführt wird, wenn es
notwendig ist. Die Einzelheiten des Prozesses zwischen Prozessbeginn und
Prozessende sind nicht bekannt.
Prozesse der Stufe 1 sind in ihren inneren Details eine ‚Black-Box
Prozessattribute:
Auf Stufe 1 werden folgende Prozessattribute gefordert:
PA 1.1 - Process performance attribute:
Das Prozessattribut PA 1.1 stellt fest, in welchem Ausmaß der Prozess mit klar
definierten Inputs klar definierte Ergebnisse erzeugt. Im einzelnen sind von einem
Einzelprozess zur Erreichung der Stufe 1 - Bereich PA 1.1 - folgende generischen
Qualitätsmerkmale zu erfüllen:
• MP 1.1.1: Identify input and output work products
• MP 1.1.2: Ensure that the scope of work is identified
• MP 1.1.3 Ensure that base practices are implemented.
4.8.3.3 Stufe 2 - Gelenkter Prozess (Managed).
Kurzbeschreibung:
Auf der Stufe 2 werden zwei Prozessattribute unterschieden: Work product
management und Performance management. Der Einzelprozess liefert definierte
Arbeitsergebnisse gemäß klarer Vorgehensweisen und ist in seiner Durchführung
geplant sowie kontrolliert. Die Arbeitsergebnisse erfüllen spezifizierte (Qualitäts)-
Standards und Anforderungen. Der hauptsächliche Unterschied zur Stufe 1 ist
neben der grundsätzlichen Transparenz des Gesamtprozesses, daß die Erstellung
der Arbeitsergebnisse systematisch hinsichtlich Zeit, Qualität und Aufwand gelenkt
165

166
(managed), d.h. geplant und systematisch kontrolliert wird. ‚Außerdem sind
Zuständigkeiten und Verantwortungen zugewiesen.
Prozess der Stufe 2 folgen einer grob strukturierten systematischen
Vorgehensweise
Prozessattribute:
Auf Stufe 2 werden zwei Gruppen von Prozessattributen gefordert, eine
prozessbezogene (PA 2.1) und eine produktbezogene (PA2.2):
PA 2.1 - Performance management attribute:
Das Prozessattribut PA 2.1 stellt fest, in welchem Ausmaß der Prozess gelenkt
wird, um Ergebnisse mit klar definierten Qualitätseigenschaften zu erzeugen. Im
einzelnen sind von einem EinzelProzess zur Erreichung der Stufe 2 - Bereich PA
2.1 - folgende generischen Qualitätsmerkmale zu erfüllen:
3 MP 2.1.1: Identify the objectives for the performance of the process
4 MP 2.1.2: Plan the performance of the process according to the identified
objectives
5 MP 2.1.3: Plan and assign the responsibility and authority for developing the
work products
6 MP 2.1.4: Manage the execution of the activities by continued tracking and
replanning.
PA 2.2 - Work product management attribute:
Das Prozessattribut PA 2.2 stellt fest, in welchem Ausmaß der Prozess gelenkt
wird, um sicherzustellen, dass die erzeugten Produkte die gestellten Anforderungen
hinsichtlich Dokumentation, Kontrolle und Qualitätssicherung vollständig erfüllen.
Lokale (projektbezogene) Standards sind dafür definiert. Außerdem werden die
Arbeitsergebnisse systematisch verwaltet und verifiziert. Im einzelnen sind von
einem Einzelprozess zur Erreichung der Stufe 2 - Bereich PA 2.2 - folgende
generischen Qualitätsmerkmale zu erfüllen:
MP 2.2.1: Identify the requirements for the work products (both functional and
non-functional aspects).
MP 2.2.2: Manage the documentation and configuration management
MP 2.2.3: Identify and define any work product dependencies
MP 2.2.4: Manage the quality of work products
4.8.3.4 Stufe 3 - Etablierter Prozess (Established).

Kurzbeschreibung:
Auf der Stufe 3 werden zwei Prozessattribute unterschieden: Process definition
und Process resources. Der Einzelprozess wird durchgeführt und gelenkt durch
einen definierten Prozess auf der Basis guter Software Engineering Prinzipien.
Individuelle Anpassungen des Prozesses nutzen genehmigte Varianten des
Standardprozesses, um die definierten Prozessergebnisse zu erzeugen. Die
Ressourcen zur Durchführung der definierten Prozesse sind ebenfalls vorhanden.
Der hauptsächliche Unterschied zur Stufe 2 ist, dass auf Stufe 3 ein allgemein
definierter Prozess organisationsweit verfügbar und im Einsatz ist, um die
definierten Arbeitsergebnisse zu erreichen.
Prozesse der Stufe 3 folgen einer organisationsweit standardisierten detaillierten
Vorgehensweise
Prozessattribute:
Auf Stufe 3 werden zwei Gruppen von Prozessattributen gefordert, eine
prozessbezogene (PA 3.1) und eine organisationsbezogene (PA3.2):
PA 3.1: Process definition attribute
Das Prozessattribut PA 3.1 stellt fest, in welchem Ausmaß der Prozess auf
Standardprozesse zurückgreifen kann, um die geforderten Ergebnisse zu erzeugen.
Im einzelnen sind von einem Eizelprozess zur Erreichung der Stufe 3 - Bereich PA
3.1 - folgende generischen Qualitätsmerkmale zu erfüllen:
• MP 3.1.1: Identify the standard process that supports the execution of the
managed process
• MP 3.1.2: Implement and / or tailor the standard process
• MP 3.1.3: Gather process performance data
• MP 3.1.4: Establish and refine the understanding of the process behaviour by
using process performance data
• MP 3.1.5: Refine the standard process
PA 3.2: Process resource attribute
Das Prozessattribut PA 3.2 stellt fest, in welchem Ausmaß der Prozess in der
Organisation auf angemessene Ressourcen, vor allem auf qualifizierte Mitarbeiter
wie auf eine geeignete Basisinfrastruktur zurückgreifen kann. Letztlich geht es also
darum, inwieweit der in PA 3.1 beschriebene Standardprozess auf
167

168
Organisationebene umgesetzt und mit ausreichenden Ressourcen versorgt ist. Im
einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 3 - Bereich PA
3.2 - folgende generischen Qualitätsmerkmale zu erfüllen:
• MP 3.2.1: Identify and document the roles, responsibilities and
competencies rquired to support the implementation of the defined process
• MP 3.2.2: Identify and document the process infrastructure requirements
• MP 3.2.3: Provide, allocate and use the resources to support the performance
of the defined process
• MP 3.2.4: Provide, allocate and use an adequate process infrastructure.
4.8.3.5 Stufe 4 - Quantitativ steuerbarer und vorhersagbarer Prozess
(Predictable)
Kurzbeschreibung:
Auf der Stufe 4 werden zwei Prozessattribute unterschieden: Process measurement
und Process control. Der definierte Prozess wird durchgängig in der Praxis
angewandt innerhalb definierter Schwankungsbreiten, um die definierten
Prozessziele zu erreichen. Detaillierte Messwerte der Prozessdurchführung werden
erhoben und ausgewertet. Dies führt zu einem quantitativen Verständnis der
Prozessfähigkeiten und zu einer verbesserten Vorhersagbarkeit und Steuerung der
Prozesse. Die Prozessleistung wird quantitativ gesteuert. Die Qualität der Produkte
ist quantitativ erfasst. Der hauptsächliche Unterschied zur Stufe 3 ist, dass der
definierte Prozess jetzt konsistent innerhalb definierter Grenzen durchgeführt wird,
um die definierten Arbeitsergebnisse zu erreichen.
Prozess der Stufe 4 werden quantitiativ überwacht und gesteuert
Prozessattribute:
Auf Stufe 4 werden zwei Gruppen von Prozessattributen gefordert, eine
messungsbezogene (PA 4.1) und eine prozessbezogene (PA4.2):
PA 4.1: Measurement attribute
Das Prozessattribut PA 4.1 stellt fest, in welchem Ausmaß quantitative
Zielvorgaben sowie Maße für den Prozess und die Produkte verwendet werden, um
die Leistung und die Zielerreichung im Kontext der Geschäftsziele zu messen. Im

einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 4 - Bereich PA
4.1 - folgende generischen Qualitätsmerkmale zu erfüllen:
• MP 4.1.1: Identify product and process goals and measures
• MP 4.1.2: Collect the specified product and process measures through
performing the defined process
• MP 4.1.3: Analyze trends in the performance of the process across the
organisation.
• MP 4.1.4: Measure the process capability and maintain it within defined
limits across the organisation.
PA 4.2: Process control attribute
Das Prozessattribut PA 4.2 stellt fest, in welchem Ausmaß der Prozess quantitativ
kontrolliert und gesteuert wird, um die vorgegebenen Prozess- und Produktziele zu
erreichen. Im einzelnen sind von einem Einzelprozess zur Erreichung der Stufe 4 -
Bereich PA 4.2 - folgende generischen Qualitätsmerkmale zu erfüllen:
• MP 4.2.1: Identify suitable measurement techniques
• MP 4.2.2: Collect measures and identfy process control parameters in order
to perform analysis
• MP 4.2.3: Control the process performance using the analysis measures to
identify actions to maintain control and/or implement improvement.
4.8.3.6 Stufe 5 - Optimierender Prozess (Optimizing).
Kurzbeschreibung:
Auf der Stufe 5 werden zwei Prozessattribute unterschieden: Process change und
Process innovation. Die Leistung des Einzelprozesses ist optimiert, um laufende
Geschäftsanforderungen zu erfüllen. Der Prozess ist soweit ausgereift, dass er mit
konstanter Performance wiederholbar ist. Quantitative Prozesseffektivitäts- und
-effizienzziele für die Leistung sind vorhanden und bauen auf den Geschäftszielen
der Organisation auf. Die kontinuierliche Prozesskontrolle gegen diese Ziele wird
ermöglicht durch quantitative Überwachung. Die Verbesserung wird erreicht durch
die Analyse der Ergebnisse. Die Verbesserung und Optimierung beinhaltet die
Pilotierung innovativer Ideen und Technologien und die Veränderung ineffektiver
Prozesse, um definierte Ziele (besser) zu erreichen. Der hauptsächliche Unterschied
zur Stufe 4 ist, dass der definierte Standardprozess jetzt dynamisch
weiterentwickelt wird, um aktuelle und zukünftige Geschäftsanforderungen
optimal zu erfüllen.
169

170
Prozess der Stufe 5 arbeiten an einer ständigen Verbesserung
Prozessattribute:
Auf Stufe 5 werden zwei Gruppen von Prozessattributen gefordert, eine
innovationsbezogene (PA 5.1) und eine verbesserungsbezogene (PA5.2):
PA 5.1: Process change attribute
Das Prozessattribut PA 5.1 stellt fest, in welchem Ausmaß der Prozess selbst auf
der Basis quantitativer Prozessinformationen kontrolliert Prozessänderungen
definiert, umsetzt und durch Ergebniskontrolle im Sinne der relevanten
Geschäftsziele lenkt. Im einzelnen sind von einem Einzelprozess zur Erreichung
der Stufe 5 - Bereich PA 5.1 - folgende generischen Qualitätsmerkmale zu erfüllen:
• MP 5.1.1: Identify changes to the standard process definition on the basis of a
quantitative understanding of the process
• MP 5.1.2: Assess the impact of all proposed changes
• MP 5.1.3: Define an implementation strategy for the approved change, ensuring
that any disruption to the process performance is understood and acted upon.
• MP 5.1.4: Implement the approved changes
• MP 5.1.5: Evaluate the effectiveness of process change on the basis of actual
performance.
PA 5.2: Continuous improvement attribute
Das Prozessattribut PA 5.2 stellt fest, in welchem Ausmaß der Prozess
kontinuierliche Verbesserungsprozesse für die Erfüllung der übergeordneten
geschäftspolitischen Zielvorgaben unterstützt. Im einzelnen sind von einem
Einzelprozess zur Erreichung der Stufe 5 - Bereich PA 5.2 - folgende generischen
Qualitätsmerkmale zu erfüllen:
• MP 5.2.1.: Define the process improvement goals for the process
• MP 5.2.2: Analyse the source of real and potential problems in the current
process, identifying improvement opportunities in a systematic and
proactive manner to continuously improve the process.
• MP 5.2.3: Implement changes to selected areas of the tailored process
according to the implementation strategy.

• MP 5.2.4: Validate the effectiveness of process change on the basis of actual
performance and add feedback to the standard process definition.
Die folgende Abbildung fasst in kompakter Weise nochmals die von Level zu
Level zunehmenden Anforderungen an die Prozessbeherrschung zusammen:
Quelle: Qualität und Informatik, www.itq.ch
4.8.4 Anwendungsbeispiel der ISO 15504/12207: Reifegradstufen im
Projektmanagement
In diesem Abschnitt wird am Beispiel des inhaltlichen Prozessbereichs
‚Projektmanagement dargestellt, wie die Beherrschung und Professionalität beim
Projektmanagement von Capability-Level zu Capability-Level zunimmt.
Ausgangspunkt dazu sind die von der ISO 15504 für das Projektmanagement
definierten Base-Practices, d.h. Kernfähigkeiten, die vom Projektmanagement
inhaltlich abzudecken sind:
MAN.2.BP1 : Define the scope of work.
MAN.2.BP2 : Determine development strategy
MAN.2.BP3 : Select software life cycle model.
MAN.2.BP4 : Size and estimate tasks and resources.
MAN.2.BP5 : Develop work breakdown structure.
171

172
MAN.2.BP6 : Identify infrastructure requirements.
MAN.2.BP7 : Establish project schedule.
MAN.2.BP8 : Allocate responsibilities.
MAN.2.BP9 : Identify interfaces.
MAN.2.BP10 : Establish and implement project plans.
MAN.2.BP11 : Track progress against plans.
MAN.2.BP12 : Act to correct deviations.
Je nach Reifegradstufe sind diese Base-Practices in unterschiedlichem Umfang und
Perfektion zu erfüllen. Im einzelnen sind die Base-Practice auf den verschiedenen
Reifegradstufen sinngemäß in der im folgenden dargestellten abgestuften Weise zu
beherrschen:
Stufe 0: Ein Projektmanagement ist nicht vorhanden, es gibt nicht einmal einen
klaren Entwicklungsprozess.
Stufe 1: Der Entwicklungsprozess wird als Black-Box betrachtet. Klarheit über die
vorhandenen Input-Produkte und über die zu erstellenden Output-Ergebnisse ist
vorhanden. Da der Prozess aber ansonsten nicht transparent ist, sind weitere
spezifische Anforderungen an das Projektmanagement nicht vorhanden.
Stufe 2: Elementare Projektplanungstechniken für jedes Einzelprojekt sowie
Einzelprojektverfolgung und -steuerung werden eingesetzt.
6. Zusätzlich zu Stufe 1: Zielsetzungen für die Leistung des Prozesses hinsichtlich
Zeit und Aufwänden ist vorhanden. Es sind Aufwandskennzahlen sowie
Schätzmethoden im Einsatz. Für die Planung werden Werkzeuge eingesetzt
sowie Methoden wie z.B. kritische-Pfad-Methoden. Außerdem sind klare
Zuordnungen von Aufgaben zu Ressourcen vorgenommen einschließlich
Ergebnisverantwortung. Der Ergebnisfortschritt wird regelmäßig kontrolliert
und berichtet.
Stufe 3: Das Projektmanagement ist auf Organisationsebene definiert und wird als
integriertes Projektmanagement gelebt.
1. Zusätzlich zu Stufe 2: Organisationsweite Standard für die Durchführung von
Projekten sind vorhanden. Prozess- und Projektmessdaten werden regelmäßig
erhoben und zentral gesammelt. Die erhobenen Daten werden zentral ausgewertet,
auf Trends hin analysiert und für ein vertieftes Verständnis der
laufenden Prozesse verwendet. Die verschiedenen für das Projekt relevanten
Einzelpläne werden zu einem gemeinsamen Projektplan integriert (z.B.:
Meilensteinplan, Budgetplan, Ressourcenplan, Qualitätsmanagementplan,
Abnahmeplan usw.).
Stufe 4: Ein quantitatives Projektmanagement ist organisationsweit etabliert.
1. Zusätzlich zu Stufe 3: Die Daten von Stufe 3 werden systematisch zur
Steuerung der Projekte auf Organisationsebene verwendet. Es werden
systematisch projektübergreifende Soll-Ist-Vergleiche hinsichtlich Zeit,

Aufwand und Ergebnisse durchgeführt. Dabei werden auch vordefinierte
Zielgrößen (Benchmark) eingesetzt. Die Projektsteuerung erfolgt zunehmend
unter Berücksichtigung der übergeordneten geschäftspolitischen Zielsetzungen.
Das Projektreporting erfolgt daher analog auch anhand aggregierter
management-gerechter Indikatoren, insbesondere Zeit, Kosten, Produktivität,
Risikoindikatoren. Verfahren der statistischen Qualitätssicherungen können
eingesetzt werden.
Stufe 5: Laufende Optimierung und Innovation der Projektdurchführung und der
Projektmanagementprozesse auf Basis quantitativer Grundlagen.
1. Zusätzlich zu Stufe 4: Neben die Steuerung der Projektdurchführung tritt die
ständige Optimierung und Verbesserung des Projektmanagementprozesses
selbst. Abweichungen von Zielvorgaben oder neue Benchmarks werden zum
Anlass genommen, den derzeit gelebten Prozess auf Verbesserungsmöglichkeiten
hin zu analysieren, die Verbessserungsansätze einzuführen und
deren Auswirkungen systematisch zu beobachten.
4.8.5 Risikomanagement gemäß ISO 15504 / ISO 12207
Die Bedeutung von Risikomanagement
Risiken sind ein unvermeidlicher Bestandteil jeder Software oder
Systementwicklung. Der richtige Umgang mit den Risiken entscheidet in vielen
Fällen über den Projekterfolg. Das Risikomanagment ist der Management Prozess,
der kontinuierlich versucht zu erkennen, was in einem Entwicklungsprojekt falsch
gehen könnte, die Schwere und die Eintrittswahr-scheinlichkeit der Ereignisse
abschätzt und daraus versucht Managementmassnahmen abzuleiten. Das Ziel des
Risiko Managements ist es also Projekt Risiken frühzeitig zu erkennen und
mögliche Probleme abzuschwächen oder zu vermeiden. Risiko Management
bestimmt dabei in starkem Maße das Life-Cycle Modell des jeweiligen SW
Projekts.
Die Grundaufgaben
Zu den Grundaufgaben des Risikomanagements gehören die
• Identifikation von Risiken
• Die Analyse und Priorisierung von Risiken
• Die Definition von Strategien um die Risiken zu managen
• Die Definition von Metriken um die Risiken zu überwachen
• Die Durchführung der Risiko Management Strategien
• Die Beobachtung der Ergebnisse der Risiko Management Strategien mit
Hilfe der definierten Metriken
­ Die Durchführung von korrektiven Massnahmen, wenn die Risikovermeidung
nicht erfolgreich ist.
Identifikation von Risiken
173

Die Identifikation von Risiken erfolgt in einem ersten Schritt am Anfang des
Projekts und wird in regelmäßigen Abständen wiederholt, da während eines
Projektes neue Risiken entstehen können. Die Identifikation erfolgt am besten im
Team durch moderierte Brainstormingsitzungen und durch systematische Suche
nach Risiken mit Hilfe von Checklisten. Dabei ist zu beachten, daß Risiken ganz
unterschiedliche Ursachen haben können. Eine Klassifikation [CMU/SEI-93-TR-6]
unterscheidet zwischen Risiken des Product Engineerings, Risiken durch Prozeßund
Arbeitsumgebung und Risiken durch externe Randbedingungen.
Analyse und Priorisierung von Risiken
In der Analyse von Risiken wird die Schwere des Schadens die das Eintreffen eines
Risikos haben kann und die Eintrittswahrscheinlichkeit eines Riskos bewertet
Schwere (S) der Konsequenzen bei Eintritt des Risikos
(0) vernachlässigbar
(-) gering
(--) kritisch
(---) katastrophal
Eintrittswahrscheinlichkeit (E)
(0) unwahrscheinlich
(-) gering
(--) gelegentlich
(---) wahrscheinlich
Aus Eintrittswahrscheinlichkeit und möglichem Schaden ergibt sich der
Handlungsbedarf
Handlungsbedarf
Schwer
e
174
Eintrittswahrscheinlichkeit
wahscheinlich gelegentlich gering unwahrscheinlich
Katastrophal hoch Hoch mittel kein
Kritisch hoch Mittel gering kein
Gering mittel Gering gering kein
Vernachlässigb
ar
kein Kein kein kein
Strategien zum Management von Risiken
Je nach Handlungsbedarf sind unterschiedliche Strategien zur Vermeidung der
Folgen bei Eintritt von Risiken zu suchen

hoher Handlungsbedarf:
Lösungen müssen präventiv gesucht werden. Bei Produktrisiken sind
Prototypen zu planen und zu entwickeln und Alternativlösungen zu
erproben.
mittlerer Handlungsbedarf:
QS-Maßnahmen sind einzuplanen. Alternativlösungen suchen
Geringer Handlungsbedarf:
Das Risiko ist zu beobachten.
Für jedes Risiko mit Handlungsbedarf sind Aktivitäten und Ressourcen und
Termine zu planen, die im Rahmen des Projektmanagements behandelt werden.
Metriken zur Überwachung von Risiken
Metriken zur Überwachung von Risiken sollten zumindest die Wahrscheinlichkeit
für das Auftreten eines Risikos und die Größe des Schadens berücksichtigen. Dabei
ist zu beachten, dass der Schaden bei fortschreitendem Projekt immer größer
werden kann.
Durchführung der Risikomanagment Strategien
Die Durchführung des Risikomassnahmen erfolgt im Rahmen des
Projektmanagements. Je nach Massnahme werden hierdurch andere
Lifecyclemodelle bevorzugt. Projekte mit hohen technischen oder anderen
Produktrisiken führen zu Prototypenenwicklungen im Rahmen von
Spiralmodellen, Projekte mit hohen Prozessrisiken (umfangreiche Projekte)
benötigen Iterative Modelle mit Prozessen hoher Qualität. Kleine Projekte mit
geringen Risiken stellen dagegen kaum Anforderungen an das zugrundeliegende
Lifecyclemodell. Der Bereich komplexer Projekte mit hohen technischen Risiken
ist als sehr kritisch zu betrachten. Eine umfangreiche Prototypphase in der die
wichtigsten Risiken geklärt werden, gefolgt von einem iterativen Vorgehensmodell
zur Bewältigung der Komplexität ist ein mögliches Vorgehensmodell.
175

176
K o m p l e x i t ä t / P r o z e ß r i s i k e n
P r o z e ß b e h e r r s c h u n g
R i s i k o
S i c h e r e P r o j e k t e V o r e n t w i c k l u n g
P r o d u k t R i s i k e n / t e c h n i s c h e R i s i k e n
4.8.6 Assessments gemäß ISO 15504 / ISO 12207
Die Zielsetzung der ISO 15504 (sowie von CMMI) ist, zur Verbesserung von
Software-Entwicklungsprozessen beizutragen, um damit schließlich eine
Verbesserung der Software-Produktqualität sowie eine Produktivitätsverbesserung
bei den Entwicklungsprozessen zu erreichen. Die Bewertung des Reifegrades von
Software-Entwicklungsprozessen findet in sogenannten Assessments statt. Dabei
werden die zu untersuchenden Einzelprozesse gemäß des dargestellten
Reifegradmodells bewertet::

Quelle: Qualität und Informatik, www.itq.ch
Die Reife eines Prozesses bestimmt sich dabei nach dem Erfüllungsgrad der
Prozessattribute. Pro Prozess wird für die Prozessattribute nach Auswertung
vorgegebener Checkfragen ein Erfüllungsgrad in einer vierstufigen Skala vergeben:
Quelle: Qualität und Informatik, www.itq.ch
Ein Capability-Level gilt als erreicht, wenn alle Prozessattribute darunterliegender
Level voll erfüllt sind (Fully) und jene des betreffenden Levels größtenteils oder
voll erfüllt sind (Largely oder Fully):
Quelle: Qualität und Informatik, www.itq.ch
177

178
In der folgenden Tabelle wird zusammenfassend dargestellt, welche Bedingungen
ein Einzelprozess erfüllen muß, wenn er auf einem bestimmten Level bewertet
werden soll:
Quelle: Qualität und Informatik, www.itq.ch
Mithilfe dieser Bewertungsrichtlinien können dann für verschiedene Prozesse
differenzierte Bewertungsprofile erstellt werden:
Quelle: Qualität und Informatik, www.itq.ch
Das Ergebnis eines solchen Assessments wird schließlich in aufbereiteter Form als
Assessment-Bericht für die Software-Entwicklungsorganisation zur Verfügung

gestellt. Darin sind dann neben der Einstufung der Einzelprozesse auch weitere
detaillierte Assessment-Ergebnisse enthalten, z.B. die Darstellung von Bereichen,
in denen punktuell bereits Prozess-Attribute von höheren Reifegradstufen erreicht
worden sind:
Quelle: Qualität und Informatik, www.itq.ch
4.8.7 Das CMMI-Modell
Das CMMI-Modell hat seinen Ursprung in den USA, wo das Verteidigungsministerium
(DoD) in den 80er Jahren einen Kriterienkatalog für gute
Software-Lieferanten bei der Vergabe von Software-Entwicklungsaufträgen
entwickeln ließ. Ziel war, bei der Auftragsvergabe für Softwareprojekte
einigermaßen sicher zu sein, dass der Auftragnehmer die Software wie versprochen
in der vorgesehenen Zeit, im Budget und mit der zugesagten Qualität liefern kann.
Dazu entwickelte 1987 das Software Engineering Institute der Carnegie Mellon
University unter Leitung von Watts Humphrey die Idee, in der Industrie bewährte
Praktiken ("best practices") in einem Referenzmodell für Software-
Entwicklungsprozesse zu vereinen, das als Fragebogen eingesetzt werden sollte.
Aus dieser Arbeit entstand 1991 das Capability Maturity Modell (CMM).
Zur Unterscheidung von später entwickelten weiteren CMM-Modellen nannte man
dieses Modell auch "Software CMM". Unternehmen konnten diese Praktiken
adaptieren, um somit besser und erfolgreicher Software zu entwickeln und dabei
schrittweise verschiedene Reifegradstufen erreichen. Ein Unternehmen konnte
mittels eines Assessments untersucht und beurteilt werden, auf welcher Reifegradstufe
es sich befindet.
Nachdem das CMM in der Anfangszeit nur von Organisationen verwendet wurde,
die vom DoD als Auftraggeber dazu gezwungen wurden, stellte sich bald heraus,
dass auch der Auftragnehmer einen deutlichen Nutzen von einer solchen
179

180
Vorgehensweise hat. Eine Reihe von Unternehmen begann daher, das CMM
freiwillig zur eigenen Prozessverbesserung zu nutzen. Es verbreitete sich von USA
aus schließlich schnell in die ganze Welt. Die Anwendergemeinde umfaßt heute
Tausende von (aufgrund der Durchführung offizieller Assessments) registrierten
Unternehmen sowie eine unbekannte Anzahl von selbständigen Anwendern. Die
Version 1.0 erschien im August 1991 und die verbesserte, heute noch gültige
Version 1.1 im Februar 1993. Im Lauf der Jahre sind neben dem ursprünglichen
Software CMM eine Reihe weiterer Reifegradmodelle für andere
Anwendungsgebiete entstanden (wie z.B. People CMM, Software Acquisition
CMM).
Das CMMI (Capability Maturity Model Integration) ist nun der Nachfolger des
CMM. Es wurde ebenfalls am Software Engineering Institute (SEI) der Carnegie-
Mellon University in Pittsburgh im Auftrag des DoD entwickelt. In diesem neuen
CMMI sind viele Erfahrungen und Verbesserungsvorschläge zum CMM
eingeflossen. Die Anforderungen sind einheitlicher strukturiert und der
Anwendungsbereich ist über die Softwareentwicklung hinaus erweitert worden.
Außerdem wurde durch die Einführung der kontinuierlichen, d.h.
einzelprozessbezogenen Reifegradbewertung, die Konsistenz zur ISO 15504
weitgehend erreicht. Das Nebeneinander verschiedener CMM-Modelle (Software-
CMM, People-CMM etc.) wurde ebenfalls bereinigt. Alle Informationen zum
CMM und zum CMMI sind öffentlich über das Internet erhältlich auf der
Homepage des SEI unter der Adresse http://www.sei.cmu.edu. Das CMMI-Modell
V1.1 ist veröffentlicht als CMU/SEI-2002-TR-001.
Ein Ziel bei der Entwicklung des CMMI war, konform zu SPICE (ISO 15504) zu
sein. Im großen und ganzen scheint dies auch gelungen, wobei zu ergänzen ist,
dass die ISO 15504 bis heute (März 2004) noch nicht endgültig verabschiedet ist.
Genauso wie die ISO 15504 hilft CMMI Softwareunternehmen bei der
Verbesserung der eigenen Prozesse und zeigt auf, was für eine erfolgreiche
Softwareentwicklung erforderlich ist. Durch die sechs Reifegradstufen wird ein mit
ISO 15504 kompatibler Verbesserungspfad beschrieben. Die Vorgehensweisen von
CMMI beruhen dabei ebenfalls auf praxisbewährten Best Practices und nicht auf
einem theoretischen Modell.
Eine detaillierte Darstellung der inhaltlichen Unterschiede würde über den Rahmen
dieses Skriptes hinausgehen, ist jedoch auch angesichts der überschaubaren
Differenzen nicht erforderlich. Wichtiger sind die Unterschiede beim
organisatorischen Status und bei der Durchführung von Assessments:
Status bei CMMI:
CMMI bietet professionellen Support durch das Software Engineering Institute
(SEI) an der Carnegie Mellon University in Pittsburgh. Hierzu gehören z.B.
Schulungskurse, Lead Assessoren Kurse, die Registrierung von Lead Assessoren
sowie von offiziell durchgeführten Assessments in einer Datenbank mit jährlichen
statistischen Auswertungen. Eine Vielzahl von Informationen kann kostenlos von

der SEI Website (www.sei.cmu.edu) abgerufen werden, z.B. auch die
verschiedenen CMMI Modelle. Das SEIR (Software Engineering Information
Respository, http://seir.sei.cmu.edu/) bietet zudem eine große Menge von
wertvollen Praxisinformationen und Beispielen zu den verschiedenen Software
Engineering Themengebieten. Der Stellenwert des CMMI auch für die europäische
Softwareindustrie dürfte durch die Gründung des SEI Europe in Frankfurt/Main
(europäische Außenstelle des SEI) im Jahre 2003 noch zunehmen.
CMMI gilt deshalb als ein sehr vielversprechendes Referenzmodell und es ist zu
erwarten, dass sich die Benutzergemeinde bezogen auf das Vorgängermodell CMM
vervielfachen wird. Entscheidende Faktoren hierfür sind:
• die Erweiterung auf (System) Engineering Prozesse
• die Flexibilität zweier Repräsentationsformen bei voller inhaltlicher
Kompatibilität
• die Qualität, Ausführlichkeit und Verständlichkeit der Modelle
• der professionelle Support
Status bei ISO 15504:
Hinter ISO 15504 steht keine betreuende Organisation wie bei CMM.
Entsprechend gering sind die Informationen, die oftmals veraltet sind und von der
SPICE User Group (http://www.seg.iit.nrc.ca/spice/) oder
Forschungsorganisationen (z.B.http://www.sqi.gu.edu.au/spice/) geboten werden.
Neuere Informationen, etwa zur Weiterentwicklung des TR in Hinblick auf die
Norm, sind äußerst spärlich. Von einem professionellen "Support" kann daher
keine Rede sein. Die 98er Version des TR wurde noch kostenlos zum Download
angeboten (mittlerweile eingestellt), die gültige 99er Version (inhaltlich praktisch
identisch) kann für mehrere hundert Euro von der ISO bezogen werden
(www.iso.ch). Die ISO 15504 hat derzeit (März 2004) immer noch den Status
Technical Report, also die letzte Vorstufe vor dem International Standard, mit
dessen Erscheinen in den nächsten Jahren zu rechnen ist. Die ISO 15504 wird
dabei noch einmal überarbeitet werden.
Die ISO 15504 hat derzeit international im Vergleich zu den CMM-Modellen
geringere Bedeutung und wird in der Praxis hauptsächlich in Australien, Europa
und dort insbesondere in Deutschland angewendet. In Deutschland wird die ISO
15504 durch die Entscheidung einiger Automobilhersteller (Herstellerinitiative
Software, HIS, bestehend aus Audi, BMW, DaimlerChrysler, Porsche, VW), die
ISO 15504 für die Bewertung von Lieferanten einzusetzen, jedoch voraussichtlich
an Bedeutung gewinnen. Durch die Konformität von CMMI zur ISO 15504 ist
jedoch der Erfolg dieser Inititative noch abzuwarten.
Fazit:
Angesichts der geringen inhaltlichen Differenzen zwischen ISO 15504 und CMMI
und angesichts der stärkeren institutionellen Unterstützung bei CMMI ist zu
erwarten, dass CMMI mittelfristig die führende Rolle bei den prozessorientierten
Qualitätsmanagement-Ansätzen einnehmen kann.
181

182
4.8.8 Literatur
• Ralf Kneuper: CMMI - Verbesserung von Softwareprozessen mit Capability
Maturity Model Integration. Dpunkt.Verlag Heidelberg, 2003.
• Watts S. Humphrey: Characterizing the Software Process: A Maturity
Framework, Software Engineering Institute, CMU/SEI-87-TR-11
• Watts S. Humphrey: Managing the Software Process, Addison Wesley,
Reading, MA, 1989
• The Capability Maturity Model - Guidelines for Improving the Software
Process, Carnegie Mellon, University, Software Engineering Institute,
Addison Wesley, Reading, MA, 1994
• ISO/IEC TR 15504-5:1999(E), Information technology - Software Process
Assessment, First Edition 1999-05-01
• Capability Maturity Model ® Integration (CMMI SM), Version 1.1, Carnegie
Mellon, Software Engineering Institute, March 2002, CMU/SEI-2002-TR-001

5 Requirements Engineering
5.1 Textuelle Beschreibung von Anwendungsfällen
Die Anforderungsanalyse besteht einerseits aus den nicht funktionalen Anforderungen wie
Definition der Qualität des zukünftigen Systems, Festlegung des Termins, zu dem das Produkt
fertig sein soll, Vorgaben für die einzusetzende Hardware und Software etc.
Außer diesen nicht funktionalen Anforderungen gibt es die funktionalen Anforderungen, d. h. die
Spezifikation der Funktionen des Systems. Der generelle Ablauf des Systems kann durch
Workflows dargestellt werden. Die einzelnen Anwendungsfälle können mit Hilfe der Use-Caseoder
Anwendungsfall-Modellierung spezifiziert werden.
Wir kennen Use-Cases (Anwendungsfälle) schon aus dem 1. Teil der Vorlesung. Hier ein Beispiel,
wie man Use-Cases beschreiben kann:
Beispiel 1: Geldautomat (ATM)
Customer
1. Überschrift: Geld abheben
2. Einfache verbale Beschreibung:
Nachdem der Kunde die Karte eingeschoben und die PIN und den Betrag eingegeben hat, wird der
Betrag vom Konto abgebucht und die Karte und das Geld ausgegeben. Falls die PIN das 1. oder 2.
Mal falsch eingegeben wurde, wird der Kunde benachrichtigt und die PIN wird erneut eingegeben.
Falls die PIN ein 3. Mal falsch eingegeben wurde, protokolliert das System den Versuch, zieht die
Karte ein und bricht die Kommunikation ab. Falls die Karte nicht gültig ist, wird dies dem Kunden
mitgeteilt und die Karte wieder ausgegeben.
Bessere und eindeutigere Schreibweise:
ATM
Withdraw
Cash
Fig. 1: Graphische Darstellung des Use-
Case Diagramms
Geldautomat
183

184
Die obige Beschreibung des Anwendungsfalls ist nicht sehr übersichtlich und auch nicht ganz
eindeutig. Aus der obigen Beschreibung kann man nicht erkennen, ob zuerst die PIN geprüft wird
und evtl. die Ausnahmesituation eintritt oder ob PIN und Betrag eingegeben werden und danach
die Prüfung erfolgt. Cockburn hat in seinem Buch "Writing Effective Use-Cases" [Co01] erläutert,
wie Anwendungsfälle besser beschrieben werden können: Wir schreiben die einzelnen Aktionen
(Action-Steps) in der richtigen Reihenfolge und nummerieren jede Aktion. Jede Aktion wird durch
einen einfachen Satz Subjekt, Verb, Objekt und evtl. präpositionale Ergänzungen beschrieben. Als
Subjekt steht immer die Instanz, die die Aktion durchführt. Wir geben ein Use-Case-Goal an.
Dieses Use-Case-Goal macht eine Aussage darüber, was das Ziel des Anwendungsfalls ist. Das
Use-Case-Goal entspricht normalerweise dem Namen des Anwendungsfalls bzw. sagt aus, dass der
Name das Ziel des Anwendungsfalls beschreiben sollte. Es ist immer aus der Sicht des Akteurs zu
sehen, d. h. man schreibt Geld abheben, nicht Geld auszahlen.
Beispiel 1: Geldautomat
Use-Case-Goal: Geld abheben
Basic Course:
1. Kunde schiebt Karte ein.
2. Das System überprüft, dass die Karte gültig ist.
3. Kunde gibt PIN ein.
4. Das System überprüft, dass die PIN die richtige
PIN zur Karte ist.
5. Kunde gibt gewünschten Betrag ein.
6. System bucht Betrag vom Konto ab.
7. System gibt Karte aus.
8. System gibt Geld aus.
In der UML gibt es noch den Begriff Use-Case-Business-Result. Dieses Use-Case-Business-
Result gibt an, welches Ergebnis nach dem erfolgreichen Durchlauf durch den Anwendungsfall
entsteht.
Use-Case-Business-Result:
Das Geld wurde vom Automat ausgegeben und vom Konto
abgebucht.
Die Karte wurde vom Automat zurückgegeben.
Das System ist wieder bereit für den nächsten Kunden.
Alle Fehler– und Transaktionsdaten wie z. B. Zeit und Datum
der Transaktion wurden protokolliert.
Was haben wir nun noch vergessen?
Was passiert, wenn z. B. die PIN falsch eingegeben wird, die Karte nicht lesbar ist etc.?

Basic Course
?
Business
Result
Jeder Ausnahmefall wird nicht im Basic Course, sondern in einem speziellen Alternative
Course beschrieben. Vorteil dieser Vorgehensweise ist, dass man sich als erstes Gedanken
macht über den Normalfall. Im zweiten Schritt werden die Ausnahmen durchdacht. Um die
Beschreibung übersichtlich zu halten, werden die Ausnahmefälle nicht in den Basic Course
integriert (z. B. mit: "Wenn das und das tue dieses und jenes" - und das evtl. über mehrere
Stufen), sondern in einem gesonderten Alternative Course beschrieben, der auf den Basic
Course Bezug nimmt.
Alternative
Course
Alternative Courses:
4a. Das System erkennt, dass die PIN das 1. oder 2.
Mal falsch eingegeben wurde:
4a1. Das System protokolliert den Versuch.
4a2. Das System benachrichtigt den Kunden.
4a3. Rückkehr nach 3.
4b. Das System erkennt, dass die PIN das 3. Mal
falsch eingegeben wurde:
4b1. Das System protokolliert den Versuch.
4b2. Das System zieht endgültig die Karte ein.
4b3. Das System benachrichtigt den Kunden.
4b4. Use-Case wird abgebrochen.
Aufgabe: Was passiert, wenn die Karte ungültig ist?
Beschreiben Sie den Alternative Course.
185

186
Wie wird der Use-Case ausgelöst?
Ein Use-Case wird durch einen Trigger ausgelöst. Der Trigger kann die erste Aktion im Use-Case
sein (z. B.: Der Kunde schiebt die Karte ein), es kann aber auch ein Ereignis von außerhalb des
eigentlichen Use-Cases sein (z. B.: Kunde ruft an und will Auftrag vergeben. Die erste Aktion ist
dann: Sachbearbeiter ruft Auftragserfassungsprogramm auf) oder ein Timer
Derjenige der durch die direkte Kommunikation mit dem System den Use-Case anstößt, d. h.
derjenige, der die erste Aktion des Use-Case durchführt wird Primary Actor genannt
Wer ist bei der Beschreibung des Use-Case zu befragen?
Alle Stakeholders, d. h. alle, die an dem Use-Case interessiert sind. Das sind oft nicht nur die
Akteure, sondern auch andere Personen oder Interessengruppen wie z. B. der Besitzer des
zukünftigen Systems, der Abteilungsleiter, die interne Revisionsabteilung etc. Die Akteure sind
zwar diejenigen, die später das System bedienen werden, sind aber oft für die Definition des Use-
Case nicht so wichtig wie andere Stakeholders.
Typen von Alternative Courses [MOW03]
- Use-Case-Exception
- Verzweigt und kehrt nie mehr zurück
- Erfüllt nicht die Use-Case-Business-Results
In [Co01]: Use-Case-Business-Results =
Success-Guarantees. die Minimal-Guarantees
sind immer, d. h. auch bei Abbruch erfüllt – hier:
Minimal-Guarantees:
Alle Fehler– und Transaktionsdaten wurden protokolliert.
Siehe Beispiel 1 (Geldautomat) zweiter Alternative Course:
4b. Das System erkennt, dass die PIN das 3. Mal
falsch eingegeben wurde:
4b1. Das System protokolliert den Versuch.
4b2. Das System zieht endgültig die Karte ein.
4b3. Das System benachrichtigt den Kunden.
Fig. 3:
Use-Case-Exception

4b4. Use-Case wird abgebrochen.
- Alternative History
- Verzweigt und kehrt nie mehr zurück
- Erfüllt die Use-Case-Business-Results
(= Success-Guarantees)
Beispiel 2 Personalverwaltung:
Use-Case-Goal: Mitarbeiter einstellen
Basic Course:
1. Der Sachbearbeiter der Personalabteilung gibt den Namen,
die Adresse und Telefonnummer des einzustellenden
Mitarbeiters ein.
2. Der Sachbearbeiter der Personalabteilung gibt die
Abteilung des neuen Mitarbeiters ein.
3. Das System weist dem Mitarbeiter eine eindeutige
Personalnummer zu.
4. Das System zeigt die verschiedenen Entlohnungstarife an.
5. Der Sachbearbeiter der Personalabteilung selektiert einen
Tarif.
6. Der Sachbearbeiter der Personalabteilung gibt die
wöchentliche Arbeitszeit ein.
Use-Case-Business-Results / Success-Guarantees:
Der neue Mitarbeiter ist eingestellt.
Der Personalstammsatz ist angelegt.
+ Minimal-Guarantees
Minimal-Guarantees:
Alle Fehler– und Transaktionsdaten wurden protokolliert.
Alternative History:
5a. Der Sachbearbeiter entscheidet, dass die Position
eine außertarifliche Bezahlung erfordert:
Fig. 2:
Alternative
History
187

188
5a1. Der Sachbearbeiter der Personalabteilung legt das
außertarifliche Monatsgehalt fest.
5a2. Der Sachbearbeiter der Personalabteilung vermerkt
sonstige Nebenabreden.
5a3. Use-Case endet erfolgreich.
- Alternative Part
- Verzweigt und kehrt zurück zu Basic Course
- Erfüllt die Business-Results
3 Arten von Alternative Parts:
- - Conditional Insertion
Beispiel 3: Studentenverwaltung
Basic Course
Use-Case-Goal: Studierenden immatrikulieren
1. Sachbearbeiter gibt Name und Adresse des
Studierenden ein.
2. Das System vergibt eine Matrikelnummer.
3. Sachbearbeiter trägt den Fachbereich ein.
4. System druckt die Immatrikulationsbestätigungen.
Alternative Course (hier: Conditional Insertion):
(a) (b) (c)
A A
4a. Studierender hat noch keine Wohnung und ihm wurde ein
Wohnheimplatz zugesagt:
4a1. Das System zeigt freie Wohnheimplätze an.
4a2. Dem Studierenden wird ein Wohnheimplatz
zugewiesen.
4a3. Rückkehr nach 4.
Bemerkung:
Extension Point (hier: Action-Step 4) ist der Punkt, an dem der Base Use-Case
verlassen wird. Der Action-Step des Extension Points wird nicht durchgeführt,
Conditional
Insertion
B
Interaction
Cycle
Fig. 3: Alternative Part
B
A
Alternative interaction
fragment
B

- - Interaction Circle
stattdessen werden die Action-Steps des Alternative Courses durchgeführt
[MOW03].
Return Point ist der Punkt, an dem wieder in den Base Course zurückgesprungen
wird (hier wie bei jeder Conditional Insertion = Extension Point). Der Action-Step
am Return Point wird nach dem Rücksprung als nächstes durchgeführt[MOW03].
Siehe Beispiel 1 (Geldautomat) erster Alternative Course:
4a. Das System erkennt, dass die PIN das 1. oder 2.
Mal falsch eingegeben wurde:
4a1. Das System protokolliert den Versuch.
4a2. Das System benachrichtigt den Kunden.
4a3. Rückkehr nach 3.
- - Alternative Interaction Fragment
Beispiel 4: Auftragsverwaltung
Use-Case-Goal: Auftrag erfassen
Basic Course:
1. Der Auftragssachbearbeiter gibt den Namen des Kunden ein.
2. Das System zeigt alle Kunden mit diesem Namen an.
3. Der Auftragssachbearbeiter wählt den richtigen
Kunden aus.
4. Das System zeigt alle Kundendaten an.
5. ...
Alternative Course (hier: Alternative Interaction Fragment):
1a. Der Auftragssachbearbeiter wünscht mit
Kundennummer zuzugreifen:
1a1. Eingabe der Kundennummer.
Rückkehr nach 4.
Abbildung zwischen textueller Beschreibung und graphischer Darstellung
Es existieren 2 Welten:
- UML
189

190
- textuelle Beschreibung
Textuelle Beschreibung mit
Basic Course +
Alternative Courses
kann sich in einen Use-Case abspielen.
Aber auch möglich:
In Base-Use-Case + Extension-Use-Case.
Dies ist z. B. dann ratsam, falls der Alternative Course in mehreren verschiedenen Base-Use-Cases
vorkommt.
Abbildung zwischen textueller und graphischer Welt:
Extension
Point
Rejoin
Point
base
use case
Basic Course
Fig. 4 Alternative Course als eigener Use
Case
Darstellung von Beispiel 1 als ausgelagerte mit extend angebundene Use-Cases:
«extend»
Alternative
Course
[condition]
extension
use case

Akteur2
Geld abheben
Geldautomat
{ 4, Abbruch;
Condition:
PIN wurde das 3. Mal falsch eingegeben}
PIN-Eingabe
Wiederholen
{4,3;
Condition:
PIN wurde das 1. oder 2.
Mal falsch eingegeben}
Karte einziehen
Fig. 5 Als eigene Use-Cases ausgelagerte alternative Courses
Die Ziffern vor der Bedingung sind der Extension Point und der Return Point und definieren
eindeutig den Typ des Alternative Courses. Statt Ziffern könnten im Text und in der Grafik auch
Marken angegeben werden (z. B. PIN-Prüfung statt 4 – siehe unten).
In der UML2 gibt es auch ein spezielles Konstrukt um Extension-Points darzustellen. Die
Bedingung kann nur in Form eines Kommentars angegeben werden.
Ein Konstrukt zur Darstellung von Return Points, so dass auch unterschieden werden kann, um
welchen Typ von Extension es sich handelt, ist in UML2 nicht vorgesehen (könnte aber im
Kommentar auch angegeben werden). Der Nachteil der Verwendung von Benannten Extension-
Points ist, dass zum Zeitpunkt, zu dem man den Base-Use- Case erweitert, im Base-Use-Case eine
Veränderung vorgenommen werden muss (Einführung einer Marke)
191

192
Akteur2
extention points:
PIN-Prüfung
Geld abheben
Geldautomat
{Condition: PIN wurde
das 3. Mal falsch eingegeben.
extention point: PIN-Prüfung}
PIN-Eingabe
Wiederholen
{Condition: PIN wurde das 1.
oder 2. Mal falsch eingegeben.
extention point: PIN-Prüfung}
Karte einziehen
Fig. 6 Als eigene Use-Cases ausgelagerte alternative Courses dargestellt in UML-
Notation
Die UML-Notation lässt auch zu, dass man nicht nur die Marke, sondern zusätzlich die Aktion
selbst hinschreibt, also: statt "Intentionen point: PIN-Prüfung" -> "Intentionen point PIN-Prüfung:
Das System überprüft, dass die PIN die richtige PIN zur Karte ist." oder "Intentionen point 4: Das
System überprüft, dass die PIN die richtige PIN zur Karte ist."
Auslagern von nicht optionalen Teilen von Use-Cases
Wird ein Use-Case zu lang, können auch Teile gesondert beschrieben werden. In [Co01] werden
gesondert zu beschreibende Teile unterstrichen und als gesonderter Use-Case beschrieben, der eine
Include-Beziehung zum Base Use-Case hat. Durch diese Vorgehensweise können sehr große Use-
Case Diagramme entstehen. Wir schlagen deshalb vor, gesondert zu beschreibende Teile auch im
gleichen Use-Case zu beschreiben (durch Anhangen des in Klammern geschriebenen Wortes
"verfeinert" am Ende der Aktion). Weiter unten kann dann die verfeinerte Aktion als unconditional
insertion beschrieben werden. Extension und Return Points müssen nicht angegeben werden, da ja
schon im Base Use-Case die Stelle angegeben ist, von wo aus mit der unconditional insertion
fortgefahren wird, und nach der Abarbeitung der unconditional insertion wird natürlich genau nach
der Aussprungstelle fortgefahren.
Eine Auslagerung in einen gesonderten Use-Case sollte dann erfolgen, wenn dieser
Anwendungsfall auch noch von anderen Use-Cases benötigt wird. Durch die Auslagerung als
gesonderter Use-Case werden somit Redundanzen vermieden.

Use-Cases auf verschiedenen Ebenen
In [Co01] werden mehrere Ebenen von Use-Cases definiert.
Fig. 6 Levels von Use-Cases
Die Use-Cases der oberen Ebenen können dabei durch Use-Cases der unteren Ebenen definiert
werden. Es gibt Ziele (Goals), die auf ganz hohen Ebenen anzusiedeln sind. Das oberste Ziel wäre:
Führe eine Firma, so dass Gewinn erzielt wird. Ein weiter tiefer angesiedeltes Ziel wäre: Aufträge
abwickeln von der Angebotsschreibung bis zur Fakturierung und Verbuchung in der Buchführung.
Diese oberen Ziele sind nach [Co01] die Summary-Goals und befinden sich auf dem White-Level,
der wiederum in Kite- und Cloud-Level geteilt ist.
Die von uns weiter oben ausführlich beschriebenen Use-Cases beschreiben alle die
Kommunikation mit dem System. Dieser Level wird in [Co01] Blue bzw. Sea-Level genannt. Die
zugehörigen Ziele heißen User-Goals. Die Use-Cases auf diesem Level werden dadurch
charakterisiert, dass sie eine von der Auslösung durch den Trigger bis zum Erreichen des Business
Results oder bis zum Abbruch eine Sitzung am Rechner (z. B Auftrag erfassen) bzw. einen
ununterbrochenen Arbeitsfluss im Rechner darstellen (z. B. alle Pakete sortieren).
193

194
Unter dieser Schicht befindet sich noch der Indigo- bzw. Underwater-Level und der Black- bzw.
Clam-Level. Hier sind Subfunctions angesiedelt, für die aber normalerweise keine Beschreibung
mehr existiert.
Weiter Möglichkeiten der Beschreibung von Use-Cases
Wie können wir Use-Cases beschreiben?
- ganz normaler Text
- strukturierter Text (pro Satz eine Aktion)
- Workflow- oder Aktivitätsdiagramme. Diese Diagramme sind besonders geeignet zur
Darstellung der Abläufe im Kite- oder Cloud-Level (Siehe Kapitel Workflows).
- Zustandsdiagramme. Da ein Zustandsdiagramm im Grunde genommen das gleiche ist wie
ein Aktivitätsdiagramm sind Use-Cases natürlich auch mit Zustandsdiagrammen
beschreibbar. Als Beispiel sei hier auf das Zustandsdiagramm des Use-Cases Authentifizierung
in [JRHZQ04], Kap. 11.3.1 verwiesen.
- Sequenzdiagramme. Diese Art von Beschreibung stellt schon die Kommunikation zwischen
Klassen dar – sie ist deshalb nicht als Diskussionsgrundlage zwischen dem normalen
Benutzer ohne jegliches IT-Wissen und dem Systementwickler geeignet, sondern führt
schon hin zum Design des Systems.
- Kommunikationsdiagramme. Hier gilt das gleiche wie für Sequenzdiagramme.
Literatur
[Co01] Cockburn, Alistair; Writing effective use cases; Addison Wesley, 2001
[MOW03] Metz, Pierre; O’Brian, John; Weber, Wolfgang; Specifying Use Case Interaction:
Types of Alternative Courses.
In: Journal of Object Technology, März 2003
[MOW03] Metz, Pierre; O’Brian, John; Weber, Wolfgang; Specifying Use Case Interaction:
Clarifying Extension Points and Points of Return.
In: Journal of Object Technology, März 2004
[JRHZQ04] Jeckle; Rupp; Hahn; Zengler; Queins; UML2 glasklar; Hanser-Verlag; 2004

6 Der Qualitätsbegriff und die Qualitätskriterien für Software
Es gibt 5 verschiedene Ansätze für die Qualität von Software:
• Transzendent: Qualität ist eine ganzheitliche Eigenschaft. Sie lässt
sich nur durch Erfahrung bewerten. (Für die Praxis untauglich:
"Programmierer ist Künstler").
• Produktbezogen: Qualität ist eine genau spezifizierte Größe, die das
Produkt beschreibt. (Kundeninteresse wird bei diesem Ansatz leicht
vernachlässigt). Sicht: Entwickler.
• Benutzerbezogen: Qualität wird durch den Produktbenutzer
festgelegt. Produkte, die das Benutzerbedürfnis am besten befriedigen,
sind qualitativ hochwertig. (Das Verkaufsergebnis als Indikator ist
problematisch). Sicht: Vertrieb/Verkauf.
• Prozessbezogen: Qualität entsteht durch den richtigen
Erstellungsprozess. Dieser muss spezifiziert und kontrolliert werden.
Dadurch wird Ausschuss und Nachbesserung vermieden und die
wandelnden Kundenbedürfnisse berücksichtigt. Sicht: Fertigung.
• Kosten/Nutzen bezogen: Qualität ist eine Funktion von Kosten und
Nutzen. Ein Qualitätsprodukt ist ein Erzeugnis, das zu einem
akzeptablen Preis einen bestimmten Nutzen bringt. Sicht: Finanzen
Allgemeine Definitionen:
Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes
oder einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener
Erfordernisse bezieht. (Deutsche Industrie-Norm DIN 55350, Teil 11)
Qualität ist die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung,
festgelegte und vorausgesetzte Erfordernisse zu erfüllen. (ISO 8402)
6.1 Die Qualitätseigenschaften beim fertigen Produkt:
Richtigkeit:
Das Softwaresystem arbeitet gemäß der widerspruchsfreien
Spezifikation.
Zuverlässigkeit:
195

196
Sei fw(t) die Wahrscheinlichkeit, dass im Zeitraum 0 bis t im System ein Fehler
auftritt, so ist R(t) = 1 - fw(t) die Zuverlässigkeitsfunktion des Systems. Geht R(t)
auch für große t gegen 1, so nennt man das System zuverlässig.
Effizienz:
Das System nutzt die Ressourcen bestmöglich aus. Hardware wird bei voller
Erfüllung des Aufgabenkatalogs sparsam verwendet. Ablaufzeit ist möglichst
optimal.
Robustheit:
Die Auswirkung eines Bedienungsfehlers ist umgekehrt proportional der
Häufigkeit seines Auftretens.
Funktionsumfang - Funktionserfüllung:
Funktionsumfang ist dann in Ordnung, falls der Funktionsumfang des Systems
gleich dem geplanten Funktionsumfang ist.
Benutzerkomfort:
Ist dann erfüllt, wenn dem Benutzer ein angenehmes , effizientes und fehlerarmes
Benutzen möglich ist und der Lernaufwand zur Bedienung des Systems gering ist.
Änderbarkeit:
Anpassungen und Fehlerbehebung sind schnell und ohne Folgefehler
durchführbar.
Portabilität:
Das System kann leicht in neue Hardwareumgebungen übertragen
werden.
Wiederverwendbarkeit:
Systemteile sind wiederverwendbar, wenn sie aufgrund ihrer Spezifikation in
unterschiedlichen Softwaresystemen als Bausteine verwendet werden können.
Generell: Die Wiederverwendung ist mit weniger Aufwand verbunden als die
Neuentwicklung.
Je nach Interessenlage ergeben sich Unterschiede in der Bewertung der Wichtigkeit
von Qualitätseigenschaften beim fertigen Produkt:
6.1.1 Wichtige Kriterien aus Benutzersicht

Richtigkeit
Zuverlässigkeit
Effizienz
Robustheit
Funktionsumfang - Funktionserfüllung
Benutzerkomfort
6.1.2 Wichtige Kriterien aus Entwicklersicht
Änderbarkeit
Portabilität
Wiederverwendbarkeit
Auf die Softwarequalität haben unterschiedliche Faktoren Einfluss:
Bild 1: Einflussfaktoren auf die Qualität
6.2 Qualitätsmanagement
197

198
Will man Softwarequalität erreichen, so muss der gesamte Softwareentwicklungsprozess
diese Kriterien im Auge haben. Es muss darauf geachtet werden, dass der
gesamte Entwicklungsprozess in systematischer Art und Weise die
Qualitätskriterien unterstützt. Eine Art "Qualitätsagentur" am Ende des
Entwicklungsprozesses, die das Produkt mit "Qualität" versieht ist ein unmögliches
Unterfangen.
Zur systematischen Erarbeitung von Softwarequalität gehört:
1. Eine Entwicklungsmethodik die folgendes erreicht:
Adäquate Modellierung des Problembereichs
Beherrschung der Problemkomplexität
2. Einsatz von bewährten Systemarchitekturen
Bewährte Analysemuster aufdecken und benutzen
Bewährte Entwurfsmuster einsetzen, finden und dokumentieren
Vorhandene bewährte Klassen- und Funktionsbibliotheken verwenden, ggf.
erweitern
Vorgegebene "Frameworks", d.h. vorgefertigte Anwendungsbereiche,
sinnvoll einsetzen
3. Den Benutzer ernsthaft bei der Festlegung der Anforderungen beteiligen
4. Konsequente Projektführung im Hinblick auf die Qualität der Software
Um zu überwachen, ob ein Qualitätsziel beim Endprodukt erreicht worden ist,
muss man Metriken für dieses Qualitätsmerkmal haben. Wir werden im Laufe der
Vorlesung einige solcher Maße besprechen, aber insgesamt ist die Lage durch
weitgehendes Fehlen der geeigneten allgemein einsetzbaren Metriken
gekennzeichnet.
Deshalb ist es im Softwareentwicklungsprozess meist erfolgreicher bereits im
konstruktiven Prozess die Qualität des Endproduktes weitgehend zu sichern, als
sich auf die Überprüfung nach Fertigstellung zu verlassen.
Diese konstruktive Qualitätssicherung ist gekennzeichnet durch:
Maßnahmen, die bereits in den Phasen:
Analyse
Definition
Entwurf
Implementierung
systematisch und permanent stattfinden.
Hierzu können gehören:
• Prototyping zur Einbeziehung des Benutzers
• Einsatz bewährter Analyse- und Entwurfsmuster

• Verwenden vorgefertigter Anwendungsframeworks
generell:
• Wiederverwendung zuverlässiger vorhandener Softwarelösungen für Teile
des Systems (Klassenbibliotheken usw.)
• Einsatz von Werkzeugen zur formalen Spezifikation (Z oder VDM oder
Petrinetze)
• Bewährte Abwandlungen des "Wasserfallmodells" anwenden:
• V-Modell
• Prototyping
• Spiralmodell ( hier ist insbesondere die Risikoanalyse wichtig mit der
Überprüfung, vor jeweils einer neuen Entwicklungsrunde, ob
Wiederverwendung günstiger ist)
• Evolutionäre Entwicklung ("Versioning")
6.2.1 Methoden und Werkzeuge des Qualitätsmanagements
Das Softwarequalitätsmanagement hat drei Hauptaufgaben:
• Qualitätssicherung ( durch Einrichten eines Systems von Verfahren und
Regeln ("Standards") zur Entwicklung qualitativ hochwertiger Software)
• Qualitätsplanung ( durch Anpassen der Verfahren und Regeln ("Standards")
an das jeweilige Projekt )
• Qualitätskontrolle ( durch Entwickeln von Vorgehensweisen, die sicherstellen,
dass die wichtigen Verfahren und Regeln (Standards) im
Softwareentwicklungsprozess auch wirklich eingehalten werden )
6.2.2 Die Bedeutung von Qualitätsstandards
Das Qualitätsmanagement muss unabhängig vom Entwicklungsteam eine
Überprüfung des Softwareentwicklungsprozesses durchführen. Ein internationaler
Standard für die Entwicklung von Qualitätsmanagementsystemen ist ISO 9000,
und speziell für den Bereich der Softwareentwicklung: ISO 9000-3.
Es ist sinnvoll daraus eigene Standards für den Qualitätssicherungsprozess zu
entwickeln, nämlich:
Produktstandards (z.B. Standards für die Dokumente im Entwicklungsprozess,
wie die Anforderungsdefinition, die Gestalt der Kommentare, die
systematische und sinnvolle Variablenbenennung, Festlegung bestimmter
Programmierstandards, um die Benutzung von negativen Eigenheiten von
Programmiersprachen zu vermeiden)
199

200
Prozessstandards (z.B. die Festlegung, wie bestimmte Phasen abzulaufen
haben und wie die Dokumente abzufassen sind, die in diesen Phasen
geschaffen werden)
Die beiden Arten von Standards hängen eng zusammen, da die Prozessstandards in
vielen Fällen die Voraussetzung dafür sind, dass bestimmte Produktstandards
erreicht werden.
Gründe für das Beachten von Softwarestandards:
• Sie bilden die Zusammenstellung geeigneter Entwicklungspraktiken
• Sie stellen die Basis für die Qualitätskontrolle dar
• Sie stellen sicher, dass das Auswechseln von Software-Entwicklern möglich
wird
6.2.3 Die Problematik von Standards in der Softwareentwicklung
Wenn sehr viele Regeln zur Softwareentwicklung in dicken Handbüchern
vorhanden sind, wird das kaum eine große Begeisterung bei den Entwicklern
hervorrufen. Deshalb sollten nicht zu viele Festlegungen getroffen werden, sondern
nur wirklich sinnvolle "Standards" gefordert werden.
Insbesondere sollte beachtet werden, dass die Zahl der Formulare, die während der
Softwareentwicklung auszufüllen sind nicht zu groß wird.
Eine sinnvolle Vorgehensweise des Qualitätsmanagers beinhaltet:
1. Für alle bürokratischen Standards, sollte er Werkzeuge zur Verfügung stellen
2. Die Standards sollten zwar gut ausgewählt und beständig sein, aber nicht für
ewig aufgestellt werden. Der bessere Standard muss den guten ersetzen
3. Die Entwickler müssen bei der Erarbeitung von Standards beteiligt sein und
jede Festlegung sollte stichhaltig im "Qualitäts-Handbuch" begründet sein.
6.2.4 Die Dokumentation von Software
Um Verifikation und Validation von Software durchführen zu können, ist eine
angemessene Dokumentation und eine präzise Festlegung der zu prüfenden Fälle
unabdingbar. Das bereits früher behandelte V-Modell sieht hierin eine wichtige
Aufgabe des Softwareentwicklungsteams (SWE), die vom Qualitätsmanager (QS)
streng zu überwachen ist. Einige Qualitätskriterien nehmen direkt auf die
Dokumentation bezug und werten Sie als (wichtigen) Indikator für die Qualität
eines Softwareprodukts.

Kurz gesagt: Dokumentation muss korrekt, so knapp wie möglich und so
umfassend wie nötig sein. Sinnvoll sind hier allgemein akzeptierte Standards in
einem Software-Entwicklungsteam.
6.3 Die statische Kontrolle der Qualität und anderer Softwareeigenschaften
Software zeigt ihre Eigenschaften beim dynamischen Ablauf aber teilweise auch
durch theoretische Kontrolle, dh. durch statische Analyse des Programmcodes oder
der Entwurfsunterlagen.
Als Methoden unterscheidet man hierbei::
• Messung
• Reviews
• Formale Verifikation
6.3.1 Softwaremaße-Softwaremessung
Im Gegensatz zur Messung in der Physik besitzt man in der Softwaretechnik keine
allgemein festgelegten Grundmaße. Das gilt speziell für die Qualitätskriterien bei
Software, mit Hilfe derer man die Messergebnisse ausdrücken und vergleichen
könnte. Um trotzdem Aussagen über die Qualität von Softwareprodukten machen
zu können, werden Hypothesen aufgestellt, die eine Reihe messbarer Größen
quantitativ (in Gestalt einer Formel) als Maß für ein bestimmtes Qualitätskriterium
des Softwareprodukts zusammenfassen. Es ist jedoch damit fast immer nur ein
Teilaspekt dieses Kriteriums erfasst und insbesondere eine subjektive Wertung der
Bedeutung einzelner messbarer Größen für die Qualität des Produktes damit
verbunden.
Metriken als Ausdruck für bestimmte Qualitätseigenschaften eines
Softwareprodukts sollten also immer mit der gehörigen Vorsicht verwendet und
bestenfalls als Maß für einen Teilaspekt der Qualität des Softwareprodukts
gewertet werden. Meist weisen die Ergebnisse von Softwaremessungen nur bei
einem Vergleich auf Qualitätsabweichungen unterschiedlicher Software hin.
Um überhaupt Aussagen über Software machen zu können, braucht man Maße für
Software-Eigenschaften. Einige davon betreffen unmittelbar die Qualität von
Software. Andere tauchen in Formeln für die Qualität eines Softwareprodukts auf
und dienen damit mittelbar der Qualitätsbestimmung. So wird ein Großteil der
Maße für Qualitätsaussagen über die gemessene Software verwendet. Es gibt aber
auch solche, die dazu benutzt werden, den Aufwand bei der Erstellung von
201

202
Software zu schätzen oder einfach nur Größenvergleiche unter verschiedenen
Softwareprodukten anzustellen.
6.3.1.1 Die Function-Point Methode
Diese Messmethode ist besonders herauszustellen, weil sie ein Maß liefert, das
bereits zum Zeitpunkt der Erstellung der Anforderungsdefinition festgelegt werden
kann und somit auch dazu dienen kann, den Aufwand für die Softwareerstellung
zu einem sehr frühen Zeitpunkt festzustellen.
In ihr werden Function-Points FP unter Beachtung bestimmter Einflussfaktoren
mittels einer durch praktische Experimente verifizierten Formel berechnet:
FP = UFP * TCF
Die Größe UFP ( "ungewichtete Function-Points") ergibt sich dabei
folgendermaßen:
UFP = f1*I + f2*O + f3*L + f4*F + f5*A
I Anzahl unterschiedlicher Eingabedatentypen
O Anzahl unterschiedlicher Ausgabedatentypen
L Anzahl unterschiedlicher interner logischer Datenbestände
F Anzahl unterschiedlicher externer Datenbestände
("Interfaces")
A Anzahl unterschiedlicher Abfragen
fi sind Bewertungsfaktoren, die sich nach den Kriterien einfach, mittel, komplex
nach folgendem Schema ergeben (Erfahrungswerte!):
Merkmal einfach mittel komple
(e) (m) x (k)
I 3 4 6
O 4 5 7
L 7 10 15
F 5 7 10
A 3 4 6
Die Bewertungsfaktoren fi liegen in dem angegebenen Bereich. Für den
durchschnittlichen UFP-Wert (bei mittlerer Schwierigkeit der Daten) gilt:
UFPm = 4*Im + 5*Om + 10*Lm+ 7*Fm + 4*Am

wobei Im, Om, ... usw. die Anzahl solcher Datentypen mittlerer Schwierigkeit
dieser Art ist.
Analog ergeben sich UFPe und UFPk
Der genaue UFP-Wert ergibt sich zu: UFP = UFPe + UFPm + UFPk
Die Einschätzung e, m oder k geschieht nach folgenden Richtlinien:
Eingaben:
Anzahl unterschiedlicher Datenelemente (e):(1-5) (m): 6-10 (k): >10
Prüfung der Daten: (e) : formal (m): formal + logisch (k):
formal+logisch+Dateizugriff
Bedienerführung bei Eingabe (e): gering (m): teilweise, in der Handhabung (k):
intensiv extern
Ausgaben:
Ebenfalls wieder Bewertung nach Anzahl unterschiedlicher Datenelemente
Anzahl unterschiedlicher Zeilen in Listen
Anzahl Wiederholgruppen
... usw. Hier sind Erfahrungswerte einzusetzen. Wenn nicht vorhanden, dann
mittlere Bewertungsfaktoren verwenden.
Der "Technical-Influence-Factor" TCF ergibt sich folgendermaßen:
TCF = 0.65 + 0.01*DI
, wobei DI bedeutet: "Degree of Influence" also "Einflussgrad".
Der Einflussgrad kann zwischen 1 und 5 liegen und zwar werden folgende 14
Faktoren der Systemcharakteristik berücksichtigt.
203

204
Deren Summe ergibt den Wert DI:
Faktor Charakteristik DI
C1 Datenkommunikation
C2 Verteilte Verarbeitung
C3 Performance
C4 Intensive Systemnutzung
C5 Transaktionsrate
C6 On-Line Dateneingabe
C7 Benutzeroberfläche
C8 Online Änderungen
C9 Komplexe Verarbeitung
C10 Wiederverwendung
C11 Einfache Installation
C12 Operationale Einfachheit
C13 Externe Einbindung
C14 Änderungsfreundlichkeit
DI-Summe:
Je nach Stärke des Einflusses der jeweiligen Charakteristik wird der Wert DI
zwischen 0= keinen Einfluss und 5 = starken Einfluss festgelegt. Maximal kann
sich also ein DI-Wert von 70 (in der Summe) ergeben.
TCF liegt also zwischen 0.65 und 1.35.
Maximal kann also der Wert von FP durch TCF um 35 % nach oben und unten
verändert werden.
Beispiel 1 : Ein System mit drei internen logischen Datenbeständen L. Einem
externen Datenbestand (Interface) F. Sechs Eingabedatentypen I, acht
Ausgabedatentypen O und dreizehn unterschiedliche Abfragen.
Komponenten einfach mittel komplex Total
L(logische interne Datenbestände)
1 x 7 = 7 2 x 15 = 30 37
F (Interfaces) 1 x 10 = 10 10
I (Eingabedatentypen) 2 x3 = 6 3 x 4 =12 1 x 6 = 6 24
1 vgl.:Horst Zuse: A Framework of Software Measurement, S.495f, Walter de Gruyter, 1998

O(Ausgabedatentypen) 5x 4=20 3x5 = 15 35
A(Abfragen) 6 x 3 = 18 6x4 = 24 1 x 6 = 6 48
Summe 156
Die Einflussfaktoren (TCF):
Faktor Charakteristik DI
C1 Datenkommunikation 4
C2 Verteilte Verarbeitung 3
C3 Performance 5
C4 Intensive Systemnutzung 4
C5 Transaktionsrate 5
C6 On-Line Dateneingabe 5
C7 Benutzeroberfläche 1
C8 Online Änderungen 4
C9 Komplexe Verarbeitung 2
C10 Wiederverwendung 2
C11 Einfache Installation 1
C12 Operationale Einfachheit 4
C13 Externe Einbindung 0
C14 Änderungsfreundlichkeit 3
DI-Summe: 43
Insgesamt ergibt sich in diesem Fall: FP = 156 * (0.65 + 0.01*43) = 168.48
Wir können also feststellen, dass die Technische Komplexität TCF in diesem Fall
den Function-Point-Wert, zunächst ausgedrückt durch den UFP-Wert = 156, auf
den endgültigen Wert von
FP = 168.48 angehoben hat.
6.3.1.2 Halstead-Maße
Mit den Halstead-Maßen wurde der Versuch unternommen, aufbauend auf einem
neuen Maß für die Größe von Softwareprodukten, eine Theorie der Softwareentwicklung
aufzustellen, die insbesondere die Wertung der verwendeten
Programmiersprache mit einschließt. Außerdem kann mittels der Halstead-Maße
eine Aussage über die Schwierigkeit der Softwareentwicklung gemacht werden.
Anzahl der unterschiedlichen Operatoren: n1
205

206
Anzahl der unterschiedlichen Operanden: n2
Anzahl des Auftretens von Operatoren: N1
Anzahl des Auftretens von Operanden: N2
Primitives Beispiel zur Veranschaulichung der Maße (Programmiersprache C++, C
):
void tausche(double &x, double &y)
{
double z;
z=x;
x=y;
y=z;
}
Operatoren Anz. Auftreten Operanden Anz. Auftreten
void 1 x 3
( ) 1 y 3
double 3 z 3
& 2
= 3
; 4
{ } 1
, 1
n1 = 8 N1 = 16 n2 = 3 N2 = 9
Abgeleitete Maße:
Größe des Vokabulars: n = n1 + n2
Länge der Implementierung: N = N1 + N2 (1)
Im Beispiel:
n = 11 (Größe des Vokabulars)

N = 25 (Länge der Implementierung)
Die Programmgröße, auch Volumen genannt, ist folgendermaßen definiert:
Programmgröße (Volumen): V = N*log(n) (2)
Der Name erklärt sich aus folgender Überlegung:
Die n unterschiedlichen Worte können in log(n) Bits kodiert werden. Das
Informationsvolumen des gesamten Programms mit insgesamt N Operatoren und
Operanden kann also mit V Bits dargestellt werden.
Die Größe V ist also recht gut als Maß für den Umfang eines Softwareprodukts
geeignet und kann als Ersatz und zur Präzisierung des recht willkürlichen Maßes
"Lines of Code" (LOC) verwendet werden.
Für unser Beispiel ergibt sich
V = 25 * log(11) = 25 * 3.5 = 87.5
Hinweis: In Sprachen mit reichhaltigem Operatorenangebot, die dem Problem
angepasst sind, wird V klein sein, andernfalls ist V groß. Die minimale Größe für
die Programmgröße V wird mit V* bezeichnet.
Sie tritt auf, falls die Funktionen, die ein Programm bietet, voll als Befehle in der
verwendeten Programmiersprache vorhanden sind.
In diesem Fall braucht i.a. kein Operand und kein Operator wiederholt zu werden.
V* = (n1 * + n2 * ) * log(n1 * + n2 *) (3)
In der Idealsprache braucht nur noch die gewünschte Funktion aufgerufen und der
erhaltene Wert zugewiesen zu werden. Also existieren in der "Idealsprache" für
eine Problemlösung nur noch 2 verschiedene Operatoren
Es ergibt sich im Idealfall also:
V* = (2 + n2 * ) * log(2 + n2 *) (4)
Im Beispiel ergäbe sich:
gegenüber
V* = (2 + 3) * log(5) = 5 * log( 5 ) = 5 * 2.32 = 11.6
V = 25 * log(11) = 25 * 3.5 = 87.5
207

208
Definition:
Der Level L ist definiert als:
L = V* / V (5)
Der Level hängt von der Programmiersprache ab. Im Idealfall ist der Level L = 1,
real ist
L < 1.
Im Beispiel gilt:
L = 11.6 / 87.5 = 0.133
Ein Maß für die Schwierigkeit der Implementierung D (difficulty) ist definiert als:
D = 1/L (6)
Im Beispiel ergibt sich:
D = 7.52
Der Aufwand E (effort) ist definiert als:
E = V / L = V * D (7)
Im Beispiel ergibt sich der Wert:
E = 87.5 * 7.52 = 658.0
Einsetzen von (5) in (7) ergibt das sehr aussagekräftige Resultat:
E = V2 / V* (8)
Da der Wert V * für die hypothetische, ideal geeignete Programmiersprache sich nur
sehrgeringfügig mit dem wachsenden Programmumfang verändert, besagt die
Formel (8) in etwa:
Der Aufwand zur Codierung eines Programms steigt quadratisch mit dem
Programmvolumen.

Ein Softwaremaß, das als Maß für die "Komplexität" von Softwaremoduln intensiv
verwendet wird, ist das von Mc Cabe. Bei genauerer Analyse stellt sich heraus,
dass man dieses Maß als Maß für den Aufwand eines sinnvollen Tests also als Maß
für die Testkomplexität verwenden kann, denn (grob gesprochen) gibt das Mc
Cabe-Maß die Mindestzahl der Testläufe an, die benötigt werden, um einen
sorgfältige Prüfung eines Moduls durchzuführen. In einem Modul ohne
Programmschleifen, gibt das Mc Cabe Maß die Anzahl der Pfade durch das
Programm an. Sind Schleifen vorhanden, so müssten streng gesprochen unendlich
viele Testläufe durchgeführt werden und das Mc Cabe Maß gibt nur an, wieviel
Läufe mindestens notwendig sind für einen Test, bei dem jede Schleifenbedingung
mindestens einmal wahr und einmal falsch ist.
6.3.1.3 Das Mc Cabe-Maß
Die zyklomatische Zahl z, die Zahl der unabhängigen Pfade 1 durch den Programm-
Graphen G, ist das McCabe-Maß des Programms. Für z gilt:
z(G) = e - n + 2
wobei gilt:
e = Anzahl der Kanten des Graphen G
n = Anzahl der Knoten von G
Beispiel:
1 Ein Pfad durch den Programmgraphen ist unabhängig, wenn er mindestens eine Kante enthält, die in keinem
anderen Pfad enthalten ist
209

210
Hier gilt: z(G) = 10 - 8 + 2 = 4
d.h. es existieren 4 unabhängige Pfade durch den Programmgraphen G.
Die Pfade:
1) < 2,4,6,8,10 > 2) < 1,5 >
3) < 2,3,7,8,10 > 4) < 2,4,6,8,9,8,10 >
Es gilt z.B.:
Der Pfad ist nicht unabhängig, weil er nur Kanten enthält, die
bereits im Pfad 3) bzw. 4) enthalten sind.
Folglich gilt sogar allgemein, dass alle Pfade, die die Schleife mehrfach
enthalten, abhängig sind von den Pfaden 3) und 4):
Der Pfad < 2,4,6,8,(9,8),(9,8),(9,8),10 > beispielsweise ist kein unabhängiger
Pfad, es gilt:
= Pfad 1) + 3*( Pfad 4)-Pfad 1))
Die McCabe-Zahl gibt Auskunft über die Komplexität der Kontrollstruktur.
Falls z(G) sehr groß ist, z.B. >>10, wird der pfad-vollständige Test sehr
aufwendig.
Es gibt für einfache Programm-Graphen ein vereinfachtes Verfahren, um die
McCabe-Zahl zu berechnen. Es gilt nämlich:

z (G) = π + 1,
wobei π die Anzahl der Verzweigungen über BOOLEschen Bedingungen ist. Im
Beispiel ist π gleich 3 also ergibt sich aus obiger Formel ebenso der Wert z(G)
= 4.
Eine weithin akzeptierte Regel in Bezug auf das Maß von McCabe lautet:
Große Programme sollten in Module zerlegt werden, wobei für jeden einzelnen
Modul gelten muss, dass z(G) < 10 ist.
6.3.1.4 Fan-in---Fan-out
Darstellung des Flusses: (Quelle, Fluss, Ziel)
Lokaler Datenfluss (A, x, B)
Eingabeparameter x ist Werteparameter
A ruft die Funktion B auf und erhält ein Ergebnis (B, B, A)
Globaler Datenfluss: (A, DS, B)
B
A
B
A verändert eine globale Datenstruktur und B benutzt diese
A
A B
x
B
211

212
DS
Beurteilung der Software-Architektur durch Informationsfluss-Analyse:
"fan-in" Zahl der Datenflüsse, die zu einem Modul m führen: FIm
"fan-out" Zahl der Datenflüsse, die von einem Modul wegführen: FOm
n
IF4 = ∑ ( FIi * FOi ) 2 n ist Anzahl der Module
i=1
IF4i = (FIi * FOi ) 2
IF4 (S) ist eine Maßzahl für die Architektur des Systems S
IF4m (S) ist eine Maßzahl für den Modul m im System S
Beispiel:
Globale Flüsse:
( B, MF, C )
( B, MF, D )
A
x x y,z
B C D
Masterfil
e
y

Modul fan-in fan-out FI * FO IF4i
A 3 2 6 36
B 0 3 0 0
C 2 2 4 16
D 2 0 0 0
IF4 drückt die Kopplung der Module mit ihrer Umwelt aus:
IF4(D) = IF4(B) < IF4(C)

214
ausschließende Verfahren. So ist zum Beispiel eine der wirksamsten Review-
Techniken die Inspektion der Testfälle eines Softwaresystems.
Programminspektionen haben als Hauptziel die Entdeckung von Fehlern in der
Software und beschäftigen sich weniger mit anderen Arten der Qualitätssicherung.
6.3.2.1 Die Entwurfsinspektion
Die Gruppe für eine Entwurfsinspektion besteht aus 3 bis 5 Teilnehmern (bei
kleineren Projekten evtl. nur 2 Teilnehmern)
1. Entwerfer
2. Moderator
3. Erfahrener Programmierer (Protokollführer für entdeckte Fehler)
4. evtl. 2-3 weitere Teilnehmer (Codierer, Wartungspersonal, Mitarbeiter aus
anderen Projekten)
Ablauf :
4 Nicht unterbrechbare Sitzung von 1-2 Stunden.
4 Teilnehmer erhalten die Entwurfsunterlagen möglichst einige Tage vor der
Sitzung durch den Moderator zugestellt. (Sind von den Teilnehmern
durchzustudieren!)
4 Anhand der Anforderungsdefinition werden die Fälle mittels des Entwurfs
durchgespielt.
4 Die anhand des Entwurfs zu erwartenden Ergebnisse werden daraufhin
überprüft, ob sie mit den gemäß Anforderungsdefinition zu erwartenden
übereinstimmen.
4 Es wird ein Protokoll über entdeckte Fehler geführt.
4 Über kritische Stellen des Entwurfs wird mit dem Entwerfer diskutiert.
4 Auch "Schwachstellen" werden protokolliert.
4 Es wird aber noch keine Fehlerkorrektur vorgenommen. Fehler werden erst
(später durch den Entwerfer) bereinigt

6.3.2.2 Die Codeinspektion
Die Mannschaft für eine Codeinspektion besteht aus ca. 4 Teilnehmern:
1. Programmierer des vorliegenden Produkts
2. Moderator
3. Testspezialist
4. Entwerfer
Ablauf :
4 Einige Stunden vor der Sitzung verteilt der Moderator die Programmliste und
die Entwurfs- Spezifikation an die Teilnehmer (Durchstudieren und verstehen
des Codes durch die Teilnehmer ist Voraussetzung für die Sitzung.)
4 Dauer der Sitzung 1 - 2 Stunden ununterbrochen.
Wichtigste Aktivitäten
1. Der Programmierer erklärt die Programmlogik Schritt für Schritt gemäß der
Anweisungen. Eventuell auftretende Fragen werden verfolgt. Der Moderator
protokolliert die Fehler. Kritische Fälle werden eventuell durchgespielt und die
Ergebnisse mit denen gemäß der Entwurfsspezifikation verglichen.
2. Die vorliegende Programmliste wird anhand einer Checkliste häufiger
Fehler analysiert (evtl. schon vorher von jedem Teilnehmer)
Der Moderator achtet darauf, dass sich auf das Entdecken von Fehlern beschränkt
wird und protokolliert diese. Die Korrektur wird später durch den Programmierer
vorgenommen.
215

216
Check-Liste für die Codeinspektion
" | " Bedeutet:Fehler können vom Compiler normalerweise nicht gefunden werden,
d.h. diese Punkte sind besonders wichtig für Nachprüfungen
Variablenbenutzung
1.Werden Variable angesprochen, die nicht initialisiert wurden?
| 2.Werden die Indexgrenzen für Felder (Arrays) eingehalten?
3.Sind die Indizes vom richtigen Typ?
| 4.Werden Pointer richtig verwendet?
5.Stimmen formale Parameter und die Argumente für die Unterprogramme im
Typ überein?
6.Ist die Anzahl der Argumente gleich der Argumente der formalen Parameter bei
Unterprogrammen?
Variablenvereinbarung
1.Sind alle Variablen vereinbart?
| 2.Werden Felder richtig initialisiert?
| 3.Gibt es Variable mit ähnlichen Namen?
| 4.Sind die globalen Variablen an der richtigen Stelle vereinbart?
Berechnungen
1.Werden Berechnungen mit nicht arithmetischen Variablen durchgeführt?
2.Gibt es Berechnungen, an denen Daten unterschiedlichen Typs beteiligt sind?
| 3.Kann es Über- oder Unterlauf in Zwischenergebnissen geben?
| 4.Kann irgendwo eine Division durch Null auftreten?
| 5.Wo können unvertretbare Ungenauigkeiten durch die Dualdarstellung auftreten?
| 6.Wurde die Priorität der Operationen beachtet?
| 7.Sind die ganzzahligen Divisionen korrekt?
Vergleiche
1.Werden Werte verschiedenen Typs miteinander verglichen?
| 2.Sind die Vergleichsoperationen korrekt verwendet?
| 3.Sind die Booleschen Ausdrücke korrekt?
| 4.Treten überkomplizierte Boolesche Ausdrücke auf?

Programmablauf
| 1.Werden bei Fallunterscheidungen alle Fälle berücksichtigt?
| 2.Wird jede Schleife richtig beendet? (Endlosschleife möglich?)
| 3.Hört das Programm nach endlich vielen Schritten auf?
| 4.Werden Schleifen aufgrund der Eingangsbedingung nicht ausgeführt?
| 5.Ist die Schrittzahl in zählenden Schleifen um eins zu hoch oder zu niedrig?
Schnittstellen
1.Werden Eingabeparameter im Unterprogramm verändert?
2. Werden Konstante auf der Position von Variablenparametern als Argument
übergeben?
| 3.Ist die Benutzung globaler Variablen über alle Module konsistent?
4.Sind Parameter und Argumente in bezug auf Typ und Argument konsistent?
Ein- und Ausgabe
1.Werden die Dateien richtig geöffnet und geschlossen?
2.Sind die Dateien richtig vereinbart?
3.Werden Zeilenende und Dateiende korrekt abgefragt?
Weitere Prüfungen
1.Gibt es nicht angesprochene Variablen im Programm?
2.Erhält man bei der Übersetzung Warnungsmeldungen?
3.Werden die Eingabedaten auf Gültigkeit geprüft?
| 4.Fehlen bestimmte Funktionen oder Prozeduren?
6.3.3 Formale Verifikation
Jedes geschaffene Softwaresystem hat die Aufgabe, aus bestimmten
Anfangsbeziehungen unter den Daten ("precondition") bestimmte Endbeziehungen
("postcondition") herbeizuführen. In der Systemspezifikation werden diese
Transformationen, die das System leisten soll, festgelegt.
Die formale Verifikation eines Systems verläuft nun so, dass durch ganz formales
Anwenden von Regeln über die Wirkungsweise der verwendeten
Algorithmenelemente der Beweis geführt wird, dass das System die gewünschten
Transformationen leistet. Gelingt dieser Beweis, so hat man damit einen strengen
Beweis, dass das System exakt die Spezifikation erfüllt, also korrekt ist.
217

Die Regeln über die Wirkung der Algorithmenbausteine sind sehr elementarer Art,
so dass man sicher sein kann, dass sie in allen gängigen Programmiersprachen so
festgelegt sind [s. Hoare69]. Die Evidenz dieser Axiome ist teilweise
offensichtlich oder kann leicht eingesehen werden.
Umgekehrt kann man auch so formulieren, dass die Axiome im Hinblick auf die
verwendete Implementierungssprache und den eingesetzten Computer festlegen,
dass die angegebene Wirkungsweise mindestens garantiert sein muss.
Die Verifikationsregeln sind formuliert wie ein Vertrag: Wenn eine bestimmte
Voraussetzung erfüllt ist, dann führt das Algorithmenelement eine bestimmte
Beziehung (die "precondition") in eine bestimmte andere Beziehung (die
"postcondition") über.
Die Verifikationsregeln
Die nachstehend beschriebene Verifikationsmethode entspricht dem Durchlaufen
der Beweisregeln von der Folgerung zur Voraussetzung. Als Ausgangspunkt beim
Beweis dient jeweils die zu beweisende Systemeigenschaft (die
Systemspezifikation).
Zum Bewahren der Übersicht auch bei größeren Systemen, werden die Regeln als
Teilbaum formuliert und ein Beweisbaum wird konstruiert (s.u.).
Für die Spezifikation der Wirkung wird folgende Schreibweise gewählt:
P { A } Q
P = precondition
Q = postcondition
A = Aktion (Algrithmenelement, Komponente oder System)
218
1. Regel für die Wertzuweisung: v := W
Es gilt: P {v:=W} Q (Folgerung)
falls erfüllt ist: P --> [Q v W] (Voraussetzung)
d.h., aus der precondition P folgt die postcondition Q, wenn man darin das freie
Vorkommen von v durch W ersetzt.
oder eine andere (etwas allgemeinere Formulierung) der Wirkung, hierbei ist V 0
der Wert der Variablen V vor der Wertzuweisung:

Aus P(V 0 ) & V = f(V 0 ,Y)--> Q(V)
folgt P(V) { V := f (V,Y) } Q(V)
Die zweite Fassung, verbal ausgedrückt:
Wenn aus der Gültigkeit von P für den Wert von V vor der Wertzuweisung und
dem durch die Zuweisung erreichten neuen Wert von V die Beziehung Q folgt,
dann hat die Zuweisung die gewünschte Wirkung.
Beispiele:
a) Sei P: X > 24 W
und Q: X > V dann gilt: X > 24W {V := 24*W} X > V,
weil erfüllt ist:X > 24 W --> [Q V 24W]
b) Es gilt: x ganz & x > 0 {x := x -1} x >= 0, denn
aus x > 0 & x ganz , folgt x-1 >= 0 = [Q x x-1], wenn Q : x >= 0 .
2. Regel für die Sequenz:
Aus P {A1 } Q1
Q1 {A2} Q2
Q2 {A3} Q3
.
.
.
Qn-1{An} Q (Voraussetzung)
folgt: P {A1; A2; . . .; An} Q (Folgerung)
Beispiel:
Ein Programmstück S1 berechnet die Summe s der Elemente a1, a2, ..., an;
Ein Programmstuck S2 berechnet aus s den Wert M=s/n.
Aus TRUE {S1} s=a1+a2+.....+an
s= a1+a2+...+an {S2} M = s/n
folgt: TRUE {S1; S2} M= (a1+a2+...+an)/n
219

220
d.h. das zusammengesetzte Programm berechnet den Mittelwert.
3. Regel für die Alternative:
Aus P & B {A1} Q
und P & NOT B {A2} Q (Voraussetzung)
folgt: P {if B then A1 else A2} Q (Folgerung)
Beispiel:
Aus x reelle Zahl & x >= 0 {y := x} y >= 0
und x reelle Zahl & x < 0 {y := -x} y >= 0
folgt x reelle Zahl {if x >= 0 then y:=x else y := -x } y >= 0
4. Regel für die while-Schleife:
Aus P --> INV
und INV & B { A } INV
und INV & NOT B --> Q
folgt: P { while B do A } Q
(Falls die Schleife nach endlich vielen Schritten abbricht ("Partielle Korrektheit"))
Beispiel: (Hier gleichzeitig Entwicklung des (partiell) korrekten Programms
Summe der N Elemente eines Feldes a0, . . . , aN-1.
Es soll ein Programm A entwickelt werden, für das gilt:
N>=0 { A } s = ∑ aj
0

Als Invariante INV wählen wir: s = ∑ aj & 0

222
Die Verifikationsregeln lassen sich baumförmig darstellen, wenn wir die
Verifikationsvoraussetzungen als Knoten darstellen, die durch Kanten mit der
Verifikationsfolgerung verbunden sind.
a) Wertzuweisung
oder in der zweiten Fassung:
b) Sequenz
c) Alternative
d) While-Schleife
P --> [Q v W]
P {v:=W} Q
P(V 0 ) & V = f(V 0 ,Y)--> Q(V)
P(V) { V := f (V,Y) } Q(V)
P{A1 }Q1 Q1 {A2}Q2 Q2{ A3 } Q3 . . . Qn-1 {An}Q
P { A1 ; A2; . . . ; An } Q
P & B {A1} Q P & NOT B {A2} Q
P {if B then A1 else A2} Q

P --> INV INV & B { A } INV INV & NOT B --> Q
e) Repeat-Schleife
P { while B do A } Q
P {A} INV INV & NOT B { A } INV INV & B --> Q
P {repeat A until B } Q
Die Verifikation eines Programmes verläuft so, dass ein "Verifikationsbaum"
aufgebaut wird. Dieser enthält als Wurzel die Programmspezifikation. Mittels der
Verifikationsregeln werden weitere Knoten entwickelt. Dies geschieht solange bis
in den Blättern des Baums die Verifikationsbedingungen stehen. Falls alle
Verifikationsbedingungen erfüllt sind ist der Beweis der Korrektheit für dieses
Programm erfolgreich abgeschlossen, die (partielle) Korrektheit des Programms
streng bewiesen.
Beispiel:
Es ist zu beweisen: Für X0, Y0 ganzzahlig, gilt:
X > 0 & X = X0 & Y = Y0
{ Z := 0;
U := X;
repeat
223

224
Z = X0 * Y0
Z := Z + Y;
U := U - 1;
until U = 0 }
Als erster und wichtigster Schritt wird eine Invariante für die repeat-Schleife
gesucht. Die geeignete Invariante (wie wir noch streng beweisen werden) ist:
U * Y + Z = X0 * Y0
Wir nennen diese Invariante INV. Dass INV durch das Innere der Schleife nicht
verändert wird, ist plausibel, da das Produkt U * Y jeweils bei einem Durchlauf
um Y vermindert und Z um Y erhöht wird.
Es werden folgende Abkürzungen im Verifikationsbaum benutzt:
ENTRY ist X > 0 & X = X0 & Y = Y0
EXIT ist Z = X0 * Y0
INV0 ist X*Y + Z = X0 * Y0
INV1 ist U * Y + Z = X0 * Y0
INV2 ist INV1 & U >= 0
Bed1 ist (U - 1) * Y + Z = X0 * Y0
S0 ist Z := 0; U := X;
S1 ist Z := Z + Y; U := U-1;
S2 ist repeat S1 until U = 0

9 10 15 16 17 18
4 5
2
11 12 13 14
1
6 7 8
1. ENTRY { S0; S2 } EXIT
2. ENTRY {S0 } INV1 & U> 0
3. INV1 & U > 0 {S2 } EXIT
4. ENTRY {Z := 0 } INV0 & X >0
5. INV0 & X > 0 {U := X } INV1 & U> 0
6. INV1 & U > 0 { S1 } INV2
7. INV2 & U 0 { S1 } INV2 (siehe 6.)
8. INV2 & U = 0 --> Z = X0 * Y0
9. ENTRY & Z = 0 --> X * Y + Z = X0 * Y0
10. INV1 & X > 0 & U = X --> U * Y + Z = X0 * Y0 & U > 0
11. INV1 & U > 0 { Z := Z + Y } Bed1 & U > 0
12. Bed1 & U > 0 { U := U - 1 } INV2
13. siehe 11.
14. siehe 12.
15. U > 0 & U * Y + Zalt = X0 * Y0 & Z = Zalt + Y
--> (U - 1) * Y + Z = X0 * Y0 & U > 0
16. Ualt > 0 & ( Ualt - 1 ) * Y + Z = X0 * Y0 & U = Ualt - 1
--> U >= 0 & U * Y + Z = X0 * Y0
17. siehe 15.
3
225

226
18 siehe 16.
Wir haben durch den Beweisbaum folgendes Ergebnis erhalten: Der obige
Algorithmus liefert das richtige Ergebnis, falls er bis zum Ende kommt, mit
anderen Worten, wenn die Schleife nicht unendlich lange läuft. Man bezeichnet
dies als den Beweis der partiellen Korrektheit.
Um die totale Korrektheit eines Algorithmus festzustellen, müssen wir zusätzlich
noch beweisen, dass das gewünschte Ergebnis nach endlich vielen Schritten auch
wirklich erreicht wird, d.h., dass der Algorithmus wirklich endet.

6.3.3.2 Beweis der Endlichkeit von Algorithmen
Die Endlichkeit eines Algorithmus ist genau dann gewährleistet, wenn alle
zyklischen Programmteile ( also die Schleifen ) in endlich vielen Schritten
vollständig durchlaufen sind. Hierzu müssen wir eine weitere Schleifeninvariante
einführen bzw. finden.
Falls wir einen Ausdruck e finden, für den vor und nach einem Schleifendurchlauf
gelten muss: e >= 0, und dessen Wert bei jedem Durchlauf um mindestens 1
vermindert wird, dann ist die Endlichkeit der Schleife gesichert, denn es muss dann
nach endlich vielen Durchläufen die Schleife verlassen werden, weil sonst für e
gelten würde: e < 0, was nicht möglich ist.
In unserem obigen Beispiel ist U ein solcher (ganzzahliger ) Ausdruck, denn da
X > 0 gilt, ist U >= 0 eine Schleifeninvariante, aber U wird bei jedem
Schleifendurchlauf um 1 vermindert.
Damit ist die totale Korrektheit unseres kleinen Algorithmus bewiesen.
Übungen:
1. Beweisen Sie: N 0
2. Beweisen Sie:
A = A0 & B = B0 { T : = A; A : = B; B : = T } A = B0 & B = A0
3. Zeigen Sie, dass das folgende Programm, eine etwas abgeänderte und
optimierte Form des behandelten Algorithmus, in Z ebenfalls das Produkt X0 *
Y0 liefert, also:
X>0 & X=X0 & Y=Y0
{ Z:= 0;
U:= X;
while NOT U=0 do
if (U mod 2 = 0) then
{ U:= U/2; Y=Y*2;}
else
{ Z:= Z+Y; U:= U-1; }
end; }
227

228
Z=X0*Y0

7 Testen
Keine Software ist fehlerfrei. Beispiele, die diese Tatsache belegen, wie z. B. der
Ausfall von Telefonnetzen oder Bahnhof-Leitsystemen, Absturz von Ariane-
Raketen, sind aus der Tagespresse bekannt. Diese Beispiele zeigen, daß Fehler in
der Software sehr teuer werden können. Aber nicht nur die Folgen von Software-
Ausfällen sind teuer, auch die Kosten der Phase Test sind in großen oder
sicherheitskritischen Projekten oft höher als die Entwicklungskosten. Die Phase
Test in einem Software-Entwicklungsprozeß ist somit eine wichtige und
kostspielige Phase. Bei den Aktivitäten in der Test-Phase werden Fehler in der zu
prüfenden Software gesucht und (hoffentlich) entdeckt. Dadurch werden die
Folgekosten von entdeckten Softwarefehlern erheblich reduziert. Je später im
Entwicklungsprozeß ein Fehler entdeckt wird, um so höher sind die Kosten für
seine Beseitigung. Ein erfolgreicher Test führt zur Entdeckung von Fehlern. Es ist
durch Testen aber nicht möglich die Fehlerfreiheit von Software zu beweisen.
7.1 Testverfahren - Wie wird getestet?
Ein Softwaresystem kann aus unterschiedlichen Sichten betrachtet werden, z. B.
externe - interne, statische - dynamische Sicht. In jeder Sichtweise sind bestimmte
Eigenschaften eines Systems sichtbar. Zur Überprüfung der Eigenschaften einer
Software können verschiedene Testverfahren eingesetzt werden. Testverfahren
helfen mit einem Minimum an Tests ein Maximum an Fehlern zu finden.
Balzert klassifiziert in [Bal99, S. 509f] Testverfahren wie folgt:
Dynamische Testverfahren
• White Box Test, Strukturtest
• Black Box Test, Funktionstest
Statische Testverfahren
• Walkthrough
• Inspektionen
Bei den dynamischen Verfahren wird die Software ausgeführt und mit konkreten
Eingabewerten versehen. Bei den statischen Verfahren wird die Software nicht
ausgeführt. Der Quellcode wird analysiert, mit dem Ziel Fehler zu finden.
Vigenschow unterscheidet [Vig, S. 20ff] demonstratives Testen und destruktives
Testen. In den ersten Bereich fällt z. B. der Entwicklertest, der zeigt, daß ein
229

230
Programm funktioniert. Destruktives Testen bezeichnet das systematische Testen
von Software mit der Absicht Fehler zu finden.
Black Box Test - Funktionstest
Bei dem Black Box Test wird das Testobjekt (Klasse, Komponente, System) gegen
seine Spezifikation getestet. Die interne Struktur des Testobjektes ist entweder
unbekannt oder unwichtig. Die Testwerte werden aus der funktionalen
Spezifikation abgeleitet. Mit einem Black Box Test kann herausgefunden werden,
ob das Testobjekt den Anforderungen des Auftraggebers entspricht, bzw. in
welcher Komponente ein Fehler auftritt. Zur genauen Lokalisierung eines
entdeckten Fehlers sind weitere Tests oder Werkzeuge nötig.
White Box Test - Strukturtest
Beim White Box Test wird das Testobjekt gegen seine Kontrollstruktur
(Implementierung) getestet. Die Kontrollstruktur kann mit Hilfe eines
Kontrollflussgraphen dargestellt werden . Ein Kontrollflussgraph ist ein gerichteter
Graph, der die Anweisungen und Verzweigungen im Quellcode des Testobjekts
darstellt (siehe Kapitel 8.1.3 Das McCabe Maß). Der Kontrollflussgraph einer
Komponente besteht aus Knoten (Anweisungen) und gerichteten Kanten
(Strukturinformationen), die die Knoten verbinden. Die gerichteten Kanten nennt
man Zweige. Den Weg durch eine Komponente von dem Anfangsknoten zu einem
Endknoten nennt man Pfad.
Durch die Berücksichtigung der Kontrollstruktur können auftretende Fehler
wesentlich präziser, als bei einem Black Box Test, lokalisiert werden.
Bei dem White Box Test werden die Testfälle so gewählt, daß die Anweisungen
und Zweige eines Programms möglichst vollständig ausgeführt werden. Software
kann wegen ihrer Komplexität nicht vollständig getestet werden. Es kann mit
vertretbarem Aufwand nicht nachgewiesen werden, daß ein Programm fehlerfrei
ist. Die nachfolgend aufgeführten Überdeckungsgrade dienen als Maße für den
Umfang der durchgeführten Tests. Überdeckungsgrade werden meistens in Prozent
angegeben. 80% Zweigüberdeckung bedeutet, daß 80 % aller Zweige bei Tests
ausgeführt wurden.
Die Anweisungsüberdeckung fordert die einmalige Ausführung aller
Anweisungen eines Testobjekts. Die Zweigüberdeckung fordert die Ausführung
aller Zweige eines Programms. Bei der Bedingungsüberdeckung werden die
Bedingungen, die zu einer Verzweigung führen, getestet. Bei komplexen boolschen
Bedingungen müssen alle Kombinationen von Bedingungen, die in den FALSE
oder TRUE Zweig führen getestet werden; für die Zweigüberdeckung genügt die
Ausführung einer Bedingung. Die Pfadüberdeckung fordert die Ausführung aller

Pfade durch ein Testobjekt. Für nicht-triviale Programme ist dieser Test nicht
vollständig durchführbar, da die Anzahl der Pfade unendlich sein kann. Die
kritischen Strukturen beim Pfadtest sind die Schleifen. Bei jedem
Schleifendurchlauf ergibt sich ein neuer Pfad und damit eine neue
Fehlermöglichkeit. Bei praktisch durchführbaren Pfadüberdeckungstests muß die
Wiederholbarkeit von Schleifen eingeschränkt werden. (siehe Lig S. 64ff)
Instrumentierung
Um die im letzten Abschnitt beschriebenen Überdeckungsgrade messen zu können,
werden in den Zweigen eines Testobjekts Zähler eingeführt. Daran kann
festgestellt werden, welche Zweige bei einem Test ausgeführt wurden. Die Analyse
des Quellcodes eines Testobjekts und das Einfügen der Zähler durch Testwerkzeug
wird Instrumentierung genannt.
Grey Box Test
Der Grey Box Test ist eine Kombination aus Black Box und White Box Tests. Bei
der Integration eines Gesamtsystems aus Teilkomponenten werden die
Schnittstellen der Teilkomponenten getestet. Beim Grey Box Test ist die
Komponentenstruktur bekannt; die Testfälle werden aus der Spezifikation
abgeleitet.
7.2 Wie findet man Testdaten
Äquivalenzklassenanalyse
Es ist unmöglich ein Programm mit allen möglichen Eingabewerten zu testen. Zur
Reduzierung des Testaufwands dient die Äquivalenzklassenanalyse. Die möglichen
Eingaben in ein Testobjekt werden in Äquivalenzklassen eingeteilt. Alle Werte
einer Äquivalenzklasse verursachen das gleiche Systemverhalten. Für jede
Äquivalenzklasse wird, stellvertretend für alle Eingaben dieses Bereichs, ein Test
durchgeführt. Die Testdaten werden aus Eingabewerten der Funktionen unter
Berücksichtigung der Gültigkeitsbereiche gewählt.
Grenzwertanalyse
Bei dem Einsatz der Äquivalenzklassenanalyse sind die Übergänge zwischen den
Äquivalenzklassen besonders kritisch; dort treten häufig Fehler auf. Es können
Fehler entstehen durch die Verwendung falscher Vergleichsoperatoren (< statt

232
wählt als Testdaten Eingabewerte an der Grenze von Äquivalenzklassen und
überprüft, ob die entsprechenden Extremwerte in den Algorithmen richtig
behandelt wurden.
7.3 Wer testet?
Alle Tests, deren Testgegenstand eine kleine Softwareeinheit ist, wie z. B. eine
Klasse, Methode oder ein Objekt werden während der Entwicklung vom
Entwickler getestet. Diese Tests dienen jedoch primär dem Nachweis, daß die
entwickelten Softwareeinheiten die geplante Funktion erfüllen. Sie fallen in den
Bereich des demonstrativen Testens. Die Entwickler von Software sind aus
psychologischen Gründen nicht geeignet für das destruktive Testen. Sie können
ihrem eigenen Werk - der Softwareeinheit - nicht mit der notwendigen destruktiven
Einstellung entgegentreten. Das destruktive Testen - die aktive Suche nach Fehlern
in der Software - sollte deshalb immer von einem Tester oder einem Testteam
durchgeführt werden. Nur Personen, die nicht mit der Entwicklung der Software
beschäftigt waren, haben die nötige objektive Distanz zu dem Produkt, um Fehler
zu finden.
7.4 Testen von objektorientierter Software
Die meisten Testverfahren stammen aus der vor-OO-Zeit, sind jedoch auch auf
OO-Software anwendbar. In der vor-OO-Zeit bestand ein Programm aus Modulen,
die Module enthielten Funktionen oder Prozeduren. OO-Software ist prinzipiell
genauso aufgebaut, enthält aber zusätzlich die Konzepte der Klasse, Vererbung und
Polymorphie. Klassen können in einer Vererbungshierarchie angeordnet sein und
Methoden und Attribute von übergeordneten Klassen erben. Methoden können in
abgeleiteten Klassen überschrieben werden. Dynamisch gebundene Methoden
können in Abhängigkeit des Objekts bei dem sie aufgerufen werden zu
unterschiedlichem Verhalten führen.
Objektorientierte Software besteht aus vielen miteinander interagierender Einheiten
(Klassen, Packages). Die Komplexität der einzelnen Einheiten ist relativ gering
(und einfach zu testen). Die Abhängigkeiten zwischen den Einheiten ist aber groß.
Öffentliche Methoden einer Klasse können von Methoden anderer Klassen
aufrufen werden. Wird eine Klasse von einer anderen Klasse abgeleitet, ist die

abgeleitete Klasse von der Oberklasse abhängig. Methoden können den Zustand
von Objekten ändern und so über die Zustandsattribute gekoppelt sein.
Dadurch entstehen viele Abhängigkeiten, die das Testen von objektorientierter
Software sehr aufwändig machen (vgl. [SnWi S. 22-25] und [Vig S. 93ff]).
7.5 Teststrategie
Ein Softwaresystem wird aus seinen Komponenten zusammengesetzt. Es wird
entsprechend seiner Struktur schichtweise zusammengebaut und getestet. Die
Integration erfolgt entweder top-down oder bottom-up. Die jeweils fehlende
Schicht wird durch Testtreiber simuliert.
Bild aus [FiRi]
Funktionstest, Klassentest
Bei diesen Tests ist bei Einsatz einer OO-Sprache eine Methode, Klasse oder
Objekt der Testgegenstand. Die Tests werden von den Softwareentwicklern selbst
durchgeführt. Es werden meistens White Box Test eingesetzt. Beim Klassentest
werden alle öffentlichen Methoden einer Klasse getestet. Eine Klasse kann
Methoden von anderen Klasse erben und über Assoziationen mit anderen Klassen
in Beziehung stehen. Diese Beziehungen einer Klasse zu den Klassen ihrer
Umgebung müssen beim Testen berücksichtigt werden. Die Klassenstruktur muss
entlang der Vererbungsstruktur getestet werden (siehe [Vig S. 93ff]) und sie muss
233

234
entlang der Assoziationen getestet werden. Wenn die Umgebungsklassen nicht zur
Verfügung stehen müssen sie durch Stellvertreterobjekte simuliert werden.
Modultest, Integrationstest
Softwaresysteme bestehen aus mehreren Modulen, die einen bestimmten Zweck
erfüllen und als Einheit gekapselt sind. Im Modultest werden die Funktionen der
Module (Teilsysteme) getestet. Im Integrationstest wird das Zusammenspiel der
Module getestet. Hier werden White, Grey und Black Box Tests eingesetzt.
Systemtest, Anwendertest
Im Systemtest wird das fertige Gesamtsystem getestet. Es wird getestet ob das
System die geplante Funktion erfüllt; es wird die Bedienbarkeit und die Installation
getestet. Das Verhalten des Systems unter Last wird überprüft. Der Anwender
überprüft am Ende des Entwickungszyklus die Akzeptanz des Systems, die
Robustheit und Stabilität während des Betriebs. Es werden hier hauptsächlich
Black Box Testverfahren eingesetzt.
7.6 Testwerkzeuge
Es sind verschiedene Tools auf dem Markt, die Testplanung und Testmanagement,
die Durchführung dynamischer und statischer Tests unterstützen und eine
Automatisierung von Testabläufen ermöglichen. Werkzeuge zur Automatisierung
von GUI-Tests verwenden Skriptsprachen um die GUI-Elemente aufzurufen und
mit Werten zu versorgen. Tools für Last- und Performancetests werden benötigt,
um ein System unter Last zu setzen und mögliche Engpässe zu erkennen und zu
beseitigen.
Eine ausführliche Klassifizierung von Testwerkzeugen findet sich in [SnWi,
Kapitel 11]. Eine kleine Auswahl stellt nachfolgende Liste dar:
• WinRunner/Mercury
• Rational Robot/IBM
• SilkTest/Segue
• QA-C++/QA-Systems
• Telelogic Tau/Telelogic
7.7 xUnit, JUnit

xUnit steht für eine Familie von Open Source Frameworks, die Entwickler bei der
Durchführung und Automatisierung von Tests unterstützen. Die Frameworks
stehen für verschiedene Programmiersprachen zur Verfügung. Die Java Variante
JUnit unterstützt die Erstellung der Tests in Java. Die Frameworks sind im Umfeld
von XP entstanden und als Open-Source-Projekte realisiert worden (siehe
http://c2.com/cgi/wiki?TestingFramework). Bei einer testgetriebenen,
inkrementellen Entwicklung, wie XP sie vorschlägt, ist zur wirtschaftlichen
Durchführung der Tests eine Testautomatisierung unerläßlich. Bei Einsatz der
xUnit-Frameworks erstellen Entwickler die Tests in der selben Sprache in der auch
die zu testende Anwendung entwickelt wird. Die Durchführung der Tests und die
Überprüfung der Ergebnisse erfolgt automatisch. Jeder Testfall ist von allen
anderen Testfällen unabhängig, damit bei einem auftretenden Fehler nicht der
vollständige Testlauf abgebrochen wird. Jeder Testfall kann erfolgreich
durchlaufen werden, oder einen Fehler verursachen. Zur Überprüfung der
Testergebnisse werden Zusicherungen (assertions) verwendet. Die Testergebnisse
werden aufgezeichnet.
XP unterscheidet zwei Testebenen (vgl. Kapitel 4.7 eXtreme Programming):
• Acceptance Tests werden von dem Kunden definiert und von den Entwicklern
implementiert.
• Unit Tests erstellen die Programmierer bevor sie die Units (Klassen, Packages,
Komponenten, Module) implementieren. Diese Vorgehensweise wird
testgetriebene Entwicklung (test-driven development) genannt. Die Integration
der Units zu einem Gesamtsystem erfolgt erst, wenn alle Unit Tests erfolgreich
laufen.
235

236
Struktur von xUnit, JUnit
Klassendiagramm von xUnit (aus [JUcook])
Das Klassendiagramm in Bild NR beschreibt die Struktur von JUnit. Bei der
Realisierung von xUnit wurden mehrere Entwurfsmuster eingesetzt. Die grau
hinterlegten Pfeile bezeichnen die Entwurfsmuster, bzw. die Elemente der Muster.
xUnit besteht aus 4 Klassen (siehe Bild NR). Über das Composite-Pattern ergibt
sich daraus eine Baumstruktur aus Testfällen und Testsuiten. Das abstrakte
Interface Test wird vererbt an die Klassen TestCase und TestSuite. Wird
ein Testfall geschrieben, so wird dieser von TestCase abgeleitet. Die Methode
setUp() wird vor jedem Test aufgerufen. Sie führt alle Initialisierungen (z. B.
der Instanzvariablen) durch. Die Methode tearDown() sorgt nach jedem Testfall
für einen definierten Endzustand. Die Methode runTest() ruft den Testfall auf, run
(TestResult) übergibt das Ergebnis des Tests an die Klasse TestResult, in
der die Ergebnisse gespeichert werden. Werden mehrere Testfälle benötigt, dann
wird die Klasse TestSuite verwendet. Diese Klasse fügt über die Methode
addTest(Test) einen Testfall in eine Menge von Tests, die TestSuite, ein. Die
Klasse TestSuite hat eine Aggregationsbeziehung zu Test. Dadurch kann eine
TestSuite mehrere Exemplare von TestCase und TestSuite enthalten.
Die Struktur von JUnit ist ausführlich beschrieben in dem Dokument JUnit A
Cook's Tour (http://junit.sourceforge.net/doc/cookstour/cookstour.htm).

Vorgehensweise
Bei Einsatz von JUnit für einen Testfall geht man wie folgt vor:
1. Erzeugen einer Unterklasse von TestCase
2. Überschreiben der Methode runTest()
3. Test starten.
Ein ausführliches Beispiel zur Verwendung von JUnit findet sich in dem
Dokument JUnit Cookbook
(http://junit.sourceforge.net/doc/cookstour/cookstour.htm).
Literatur
[Bal99] Helmut Balzert, Lehrbuch - Grundlagen der Informatik, Spektrum
Akademischer Verlag, 1999.
[FiRi] Daniel Fischer, Marc-Oliver Richter, Schwarze Kunst, Black-Box-
Methoden zum GUI-Testen, in iX 11/2001, S. 52-55, Heise.
[JUcook] Kent Beck, Erich Gamma, JUnit Cookbook,
http://junit.sourceforge.net/doc/cookstour/cookstour.htm
[Lig] Peter Liggesmeyer, Modultest und Modulverifikation, BI
Wissenschaftsverlag, 1990.
[Link] Johannes Link, Softwaretest mit JUnit, dpunkt.verlag, 2005.
[SnWi] Harry M. Sneed, Mario Winter, Testen objektorientierter Software,
Hanser, 2002.
[Vig] Uwe Vigenschow, Objektorientiertes Testen und Testautomatisierung in
der Praxis, dpunkt.verlag, 2005.
237

238
8 Konfigurationsmanagement
8.1 Warum Konfigurationsmanagement (KM)?
Heutige Software-Entwicklungsprojekte zeichnen sich durch eine hohe
Komplexität aus (vgl. [Brö00]). In SW-Entwicklungsprojekten entsteht eine
Vielzahl von Software-Elementen (Artefakte), die im Laufe des Projektes iterativ
in den verschiedenen Phasen geändert bzw. weiterentwickelt werden. Zentrale
Artefakte sind z. B. Anforderungsdokumente, Architekturbeschreibungen, Grafiken
sowie der Quellcode der verschiedenen Module/SW-Komponenten. Diese SW-
Elemente (auch KM-Items genannt) können in unterschiedlichen Dateisystemen
auf verteilten Plattformen/Rechnern sowie in unterschiedlichsten Formaten
vorliegen.
In der Regel bedingen heutige Entwicklungen die Einhaltung einer bestimmten
Produktionskette (vom Entwicklungssystem bis zum Produktivbetrieb).
Erfolgreiche Projekte basieren auf einem guten Management dieser Artefakte durch
eine transparente Ablagestrategie sowie einzuhaltender Konventionen (z. B.
Namenbildungsregeln für die Artefakte). Idealerweise kann zu jedem Zeitpunkt,
d.h. während des gesamten Lebenszyklus des Anwendungssystems, Teile von dem
Anwendungssystem oder auch das gesamte Anwendungssystem aus den
Entwicklungsdaten ohne manuelle Eingaben reproduziert werden. Die hierfür
notwendigen Informationen zu den Entwicklungsdaten werden zentral gespeichert.
Das Konfigurationsmanagement stellt ein wichtiges Mittel dar, um Änderungen
effektiv durchzuführen und diese auch später noch nachvollziehen zu können.
Beim Aufbau der SW-Entwicklungsumgebung (SEU) muss berücksichtigt werden,
dass die Änderung der verschiedenen Software-Elementen geordnet und
nachvollziehbar erfolgt.
8.2 Was ist (Software-)Konfigurationsmanagement (SKM)?
Ein Produkt durchläuft im gesamten Lebenszyklus (= Produktlebenszyklus)
verschiedene Zustände, die sich in unterschiedlichen Produktstrukturen
widerspiegeln können. Unter dem Begriff Konfigurationsmanagement fasst man
vielfältige Aufgaben zusammen (wie z. B. Produktplanung sowie Produkt- und
Konfigurationsverwaltung), die die verschiedenen Produktzustände effektiv
verwalten.
Der KM-Begriff stammt ursprünglich aus dem Maschinenbau und wurde auch auf
die Software-Entwicklung adaptiert. In der Softwareentwicklung bezeichnet der

Begriff des Software Konfigurations-Managements (SKM) die Disziplin zur
Verfolgung und Steuerung der Evolution von Software. KM wurde durch die
Internationale Standards Organisation für die SW-Entwicklung standardisiert (->
Richtlinienwerk DIN EN ISO 9001, [Brö00]).
Konfigurations-Management wurde ca. 1950 für die US-Luft- und
Raumfahrtindustrie eingesetzt (z. B. im Apollo-Programm zur Verfolgung
Tausender von Änderungen). In den 70er Jahren des letzten Jahrhunderts wurden
Werkzeuge wie z. B. SCCS (Source Code Version Control Management Software)
und MAKE etabliert. Heutzutage ist anerkannt, dass SKM-Werkzeuge eine hohe
Bedeutung für Softwareprojekte besitzen. Moderne Werkzeuge (wie z. B. CVS
[CVS04] und ANT [Ant04]) sind anspruchsvoll und bedingen eine Lernphase
bevor diese effizient genutzt werden können.
8.3 Einsatz von Software-Konfigurationsmanagement in Projekten
Software ist durch Anpassungen, Erweiterungen oder Korrekturen einem ständigen
Änderungsprozess unterworfen. Das Hauptaugenmerk beim SKM liegt bei der
Unterstützung der Nachvollziehbarkeit von Änderungen sowie der Produktion
zumeist zahlreicher Software-Freigaben (Releases).
Wird die Entwicklung durch Teams durchgeführt und bearbeiten mehrere
Entwickler das gleiche Softwareobjekt, muss festgelegt sein, welches Prinzip
angewandt werden soll. Ein Prinzip könnte sein, dass die jeweils letzte Änderung
vorherige Änderungen einfach überschreibt („last save wins“). Alternativ kann
auch das gleichzeitige Ändern untersagt werden, um evtl. ungewolltes
Überschreiben grundsätzlich zu verhindern.
In der Regel bestehen Abhängigkeiten zwischen den einzelnen
Softwarekomponenten. Bei der Modifikation einer Komponente ist es daher oft
nötig auch die davon abhängigen Komponenten anzupassen. Ändert sich
beispielsweise die Schnittstelle einer Komponente, müssen Anwendungsteile, die
diese Schnittstelle verwenden, ebenfalls angepasst werden.
Ist die Menge der von einer Komponente abhängigen Teile nicht bekannt, muss
diese bei jeder Änderung erst mühsam (evtl. manuell) ermittelt werden. Wird dabei
eine Komponente, die eigentlich angepasst werden müsste, nicht beachtet und
keine unmittelbare Fehlermeldung im Kompositionsprozess angezeigt, können so
neben dem Zeitverlust auch Fehler entstehen, die mit erhöhtem Kostenaufwand
wieder korrigiert werden können.
239

240
Um diesen Probleme entgegenzuwirken, enthält ein SKW-Werkzeug mächtige
Änderungs- und Build-Management-Funktionen. Um die Reproduzierbarkeit der
einzelnen Produkteigenschaften zu gewährleisten, bildet das Konfigurationsmanagement
die diversen Produkt-Zustände in sog. Konfigurationsmappen ab.
Hierbei sind verschiedene Anforderungen an die eingesetzten Techniken und
Verfahren zu stellen. Jeder Entwickler hat zur erfolgreichen Durchführung des
SKM zusätzlich zu seiner Arbeit am Produkt für das SKM einen Mehraufwand zu
leisten. Der hieraus erwachsende Nutzen sollte jederzeit ersichtlich sein. Um dieses
Bewusstsein und die Fähigkeit zur Bedienung der Werkzeuge zu fördern, sind
Schulungsmaßnahmen durchzuführen.
Nachfolgend werden wichtige Funktionen eines idealtypischen
Konfigurationsmanagement Systems genannt:
- Verwaltung aller Projektergebnisse (unabhängig vom verwendeten Dateiformat)
- Verwaltung und automatisierte Pflege der Abhängigkeitsbeziehungen (Verweise)
zwischen den SW-Elementen
- Konsistenzsicherung zwischen den verschiedenen abhängigen SW-Elementen
- Unterstützung von Änderungen an textuellen und graphischen
Entwicklungsmodellen (wie z. B. Analyse- und Entwurfsmodellen)
Die einzelnen Aufgaben des SKM kann man nach ihrer Wichtigkeit ordnen. Die
Basis bildet die Kontrolle der Versionen einzelner SW-Elemente. Darauf
aufbauend liegen Konfigurationen sowie Einstellungen für die
Kompositionsprozesse im Rahmen des Build-Management. Hat eine Freigabe der
Software stattgefunden, gewinnen Verfolgung und Koordination von
Änderungsprozessen an Bedeutung. In dieser Phase des SW-Lebenszyklus muss
ein effizientes Änderungsmanagement etabliert sein. Letztendlich fügt sich das
SKM in den Gesamtprozess der Softwareentwicklung (z. B. bei V-Modell oder
RUP) ein. In dem jeweiligen Vorgehensmodell sind daher entsprechende KM-
Abschnitte enthalten. Ziel und Aufgabe des SKM ist es, all diese Bereiche
möglichst automatisiert und verteilt auf unterschiedlichen Plattformen (LAN,
WAN, …) abwickeln zu können.

Verteilung (LAN, WAN; …)
Vorgehensmodell
Änderungsmanagement
Konfigurationsmanagement
Versionsmanagement
Abbildung: Aufgaben von SKM
Der in einem Projekt eingesetzte Entwicklungsprozess sollte von Anfang an SKM
berücksichtigen. Schon sehr früh entstehen in einem Projekt wichtige Dokumente
(wie z. B. der Projektplan und die Risikoliste), deren Änderungen nachvollziehbar
sein sollten.
Ist ein Projekt abgeschlossen, können die einzelnen SW-Elemente auch in anderen
Projekten wieder verwendet werden. Dies sollte durch den Einsatz eines SKM-
Werkzeugs gefördert werden. Dies kann in der Weise geschehen, dass
Projektergebnisse in einem zentralen Repository (Projektbibliothek) gespeichert
werden oder Informationen über Intranets oder Entwicklerportale veröffentlicht
werden.
Nach dem ersten Rollout der Software ist ein besonderes Änderungsmanagement
zu etablieren. Dieses hat u. a. die Aufgabe, die aufgetretenen Problem- und
Fehlermeldungen zu erfassen und zu verwalten. In der nachfolgenden Abbildung
sind abschließend die möglichen Zustände einer Änderung und die zugehörigen
Formulare (kursive Schrift) dargestellt (vgl. [Balz96]).
Änderungsantrag/Problemmeldung
bean
-
tragt
Änderung
bewerten
Änderungsvorschlag
Änderungen
Abbildung: Änderungsmanagement
beabsichtig
t
Änderungs
vorschlag
ablehnen
entschließen u.
einleiten
Änderungsauftrag
beauftra
gt
Änderung
abschliessen
Änderungsmitteilung
erledig
t
241

242
Änderung
bewerten
abgelehnt
8.4 Weiterführende Literatur
[Ant04] Apache ANT, http://ant.apache.org/, zuletzt besucht 11/2004.
[Balz96] H. Balzert, Lehrbuch der Software-Technik: Software-Entwicklung,
Spektrum Akademischer Verlag, 1996.
[Brö00] P. Brössler, J. Siedersleben (Hrsg.), Softwaretechnik: Praxiswissen für
Software-Ingenieure, Hanser, 2000.
[CVS04] CVS, http://www.cvshome.org/, zuletzt besucht 11/2004.

9 Petri-Netze
Während bei vielen Methoden nicht vorgesehen ist, gleichzeitig stattfindende
Vorgänge mit ihren Abhängigkeiten zu beschreiben, ermöglichen Petri-Netze
sowohl die Darstellung der elementaren logischen Strukturen als auch deren
möglichen parallelen Ablauf.
9.1 Zustände und Ereignisse
Kernelemente von Petri-Netzen sind
• Zustände (statische Knoten) und
• Ereignisse (dynamische Knoten).
Zustände können durch Ereignisse in neue Zustände übergehen. Die Zustände
können die Bedingungen anzeigen, unter denen die Ereignisse stattfinden. Der
ständige Wechsel von Ereignissen und neuen Zuständen zwingt den Benutzer
dieser Methode, sich darüber klar zu werden, welche Zustände zu welchen
Ereignissen führen, und welche Ereignisse notwendig sind (oder welche
Bedingungen erfüllt werden müssen), um die gewünschten Zustände zu erreichen.
Ein Petri-Netz ist demzufolge ein gerichteter Graph, der aus Kanten und Knoten
besteht und folgende Eigenschaften aufweist:
• Es gibt zwei Arten von Knoten:
• den Bedingungs- bzw. Zustandsknoten (´Stelle´)
• den Ereignisknoten (´Transition´).
• Die Knoten treten nicht isoliert auf.
• Die Pfeile laufen von Stelle zu Transition oder von Transition zu Stelle.
• Die Anzahl der zu einem Knoten hinführenden Pfeile kann verschieden sein
von der Anzahl der wegführenden Pfeile.
Mit Hilfe solcher Petri-Netze können z.B. folgende Frage beantwortet werden:
• Welche Vor- und Nachbedingungen weisen die Aktionen auf?
• Nach welchen Vorschriften werden die Abläufe im System gesteuert?
• In welcher Reihenfolge laufen Aktionen ab?
• Welche Funktionsbereiche kommunizieren über welche
Informationseinheiten miteinander?
243

244
Zur Erstellung von Petri-Netzen sind im Wesentlichen drei Symbole notwendig:
Zustandsknoten
Ereignisknoten oder
Verbindungspfeile
9.2 Dynamik in Petri-Netzen
Um die ablaufenden Prozesse verfolgen zu können, kann eine Stelle mit einer
Markierung (schwarzer Mittelpunkt ) versehen werden, die anzeigt, dass die
Bedingung erfüllt oder der Zustand eingetreten ist.
Ein Vorteil von Petri-Netzen ist es, mit Hilfe dieser Marken nebenläufige oder
parallele Prozesse (concurrency) darstellen zu können. Von ganz besonderer
Bedeutung ist dabei, zu erkennen, an welcher Stelle des Petri-Netzes
Konfliktsituationen auftreten können und ob Blockierungen des dynamischen
Flusses zu erwarten sind.
Das von anderen Methoden her bekannte Prinzip der schrittweisen Verfeinerung ist
auch bei Petri-Netzen anwendbar, so daß ebenfalls eine top-down-Vorgehensweise
möglich ist. Übersichtlich gestaltet wird dies durch entsprechende
Nummerierungen.
9.3 Regeln in Petri-Netzen
In der folgenden Übersicht werden die einzelnen Regeln beschrieben, nach denen
Petri-Netze aufgebaut sein können:
Regeln

Z1
Z2
Z4
Z5
Z1
Z2
Z3
Z1 E1 Z2 E2
E1
E1
E2
E1
Z 4
Z 5
Z3
Z1
Z2
Z3
Z4
Z5
E 1
E3
E4
E5
Z 1
Z 2
Z 3
Abb. Regeln für den dynamischen Ablauf in Petri-Netzen
Es dürfen nur Knoten unterschiedlicher Art
direkt miteinander verbunden werden: Ein
Zustand (eine Stelle) führt immer direkt zu
mindestens einem Ereignis (einer Transition)
und das wiederum direkt zu mindestens einem
Zustand (einer Stelle).
Ein Ereignis (eine Transition, hier E1) kann
mehrere direkte Vorgängerstellen (Zustände),
die "Eingangsstellen", und mehrere direkte
Nachfolgerstellen (Zustände), die "Ausgangsstellen",
besitzen.
Ebenso kann eine Stelle (ein Zustand, hier Z3)
mehrere Eingangs- oder Ausgangs-ereignisse
(Transitionen) aufweisen.
Ein Ereignis wird nur dann stattfinden (eine
Transition wird aktiv), wenn alle Eingangsbedingungen
erfüllt sind, d.h. alle Eingangsstellen
eine Marke tragen.
Findet das Ereignis einer aktivierten Transition
statt, so schaltet oder "feuert" die Transition.
Dieser Übergang von den Eingangsstellen
zu den Ausgangsstellen wird so dargestellt,
dass die Markierung bei allen
Eingangsstellen entfernt und bei allen Ausgangsstellen
hinzugefügt wird.
Diese Grundregeln sind bei der Darstellung und Simulation von Situationen stets
einzuhalten. Trotz dieser einfachen Regeln sind aufgrund der vielfältigen
Anordnung sehr komplexe Situationen darstellbar.
245

246
9.4 Komplexe Situationen in Petri-Netzen
Wesentliche komplexe Situationen in Petri-Netzen sind die Nebenläufigkeit, bei
der parallele Vorgänge simuliert werden und Blockierung (deadlock), bei der durch
die Anordnung von Stellen und Transitionen gewollte oder ungewollte Situationen
auftreten, die nicht auflösbar sind. Die folgende Abbildung zeigt die beiden
Situationen.
Z 1
Z 2
Z3
Z1
E 1
Z 3
Z 4
Abb. Komplexe Situationen
9.5 Kontakt- und Konfliktsituation
Z 5
E2
E1
E 2
E 3
Z2
Z 6
Z 7
Nebenläufigkeit (concurrency)
Sind mehrere Ereignisse aktiviert,
können alle Ereignisse (die keine
gemeinsamen Eingangsstellen haben,
hier E2 und E3) willkürlich feuern.
Damit sind parallel ablaufende Vorgänge
darstellbar.
Blockierung (deadlock)
Wenn kein Ereignis aktiviert werden
kann, weil z.B. zwei Eingangsstellen
niemals gleichzeitig markiert werden
können, ist dieser Zweig des Petri-
Netzes blockiert. Es liegt entweder ein
Entwurfs- oder Darstellungsfehler vor,
oder aber die dargestellte Situation stellt
eine reale Blockade dar.

Kontakt- und Konfliksituationen treten dann auf, wenn durch die Markenbelegung
ein Schalten nicht möglich ist (Kontakt) bzw. durch die Konstellation des Netzes
unterschiedliche Schaltungen bei gleichem Ausgangszustand möglich sind. Die
folgende Abbildung zeigt die beiden Situationen.
Z 1 Z 3
Z 2
E 1
E 1
E 2
Z 4
andere Darstellungsweise:
Abb. Kontakt- und Konfliktsituationen
9.6 Gabel und Zusammenführung
1
2
Kontakt
Z4 ist makiert 2
E1 kann nicht schalten, obwohl Z1 und
Z2 markiert sind.
Konflikt
Schalten von E1 (bzw. E2), führt
dazu, dass E2 (bzw. E1) nicht mehr
schalten kann
Die folgenden Situationen zeigen die typische Konstellation bei Graphen, wenn in
einen Knoten zwei Kanten einlaufen und eine wieder heraus oder – umgekehrt –
eine Kante hineinläuft und zwei wieder hinaus. Die Abbildung zeigt die daraus
entstehenden vier Situationen.
247

248
Verzweigung
(branch)
Beim Markenspiel kann nur ein
Zweig durchlaufen werden
Aufspaltung
(split)
Die Wirkung wird
gleichberechtigt verteilt, d.h. ein
Pfeil löst mehrere nebenläufige
Aktionen aus (beide
auslaufenden Pfeile
transportieren beim Schalten
eine Marke)
Abb. Gabel und Zusammenführung
9.7 Beispiele von Petri-Netzen
Stelle
Transition
Begegnung (Wettbew.)
(meet)
Nur über einen Zweig kann die
Marke belegt werden (logisches
XOR)
Sammlung
(wait)
Es kann erst geschaltet werden,
wenn alle einlaufenden Pfeile
eingetroffen sind (aufeinander
gewartet haben; logisches UND)
Das Hauptmann von Köpenik-Problem eignet sich, um die Blockierung eines Petri-
Netzes aufzuzeigen. Die Abbildung zeigt das passende Petri-Netz.

Abb. Das Hauptmann von Köpenik-Problem (Blockierung)
Liegt in Z1 eine Marke, in Z2 und Z3 aber nicht, dann liegt das Problem des
Hauptmannes von Köpenick vor. Die Arbeitserlaubnis (E1) kann nicht gegeben
werden, da keine Aufenthaltsgenehmigung (Z3) vorliegt. Daher wird Z2 (Arbeit
bei einer Firma) nicht erfüllbar sein. Ohne die Arbeit bei einer Firma, gibt es
allerdings keine Aufenthaltsgenehmigung (Z3). Es liegt die bekannte Blockierung
vor (weder Arbeit noch Aufenthaltsgenehmigung können erlaubt werden).
Im folgenden Beispiel wird ein einfaches Betriebssystem in seinem Ablauf
simuliert. Dieses System kann nur jeweils einen Auftrag abarbeiten, bevor der
nächste Auftrag gestartet werden kann. Voraussetzung für dieses restriktive
Vorgehen ist, dass es nicht erlaubt ist, dass mehrere Marken in einem
Zustandsknoten liegen können.
249

250
Abb. Ein einfaches Betriebssystem-Modell
Für ein weiteres Anwendungsbeispiel wird ein sehr einfacher und von vielen
Einflußfaktoren (vor allem der Zeit) ‘bereinigter’ Ausschnitt eines Flug- und
Flugzeugumlaufplans unterstellt, in dem lediglich die Zuordnung von Flugzeugen
zu Flugstrecken (Flug-Nr.) und Umsteigemöglichkeiten für Passagiere
(‘Zubringerfunktion’) zu beachten sind. Mit dem ersten Fall ist eine notwendige
technische, mit dem zweiten Fall eine ökonomisch erwünschte Bedingungsklasse
für den Flugverkehr eingeführt. Beide sollen im Folgenden jedoch zunächst
unterschiedslos als ‘unabdingbare’ Bedingungen behandelt werden.
Der ‘Flugplanaussschnitt’ sieht folgende Aktionsmuster vor:
Flug-Nr. Strecke Flugzeug
151 Köln (CGN=5) – Frankfurt (FRA=1)
A
Zubringer
für Flug-Nr.
131 München (MUC=3) - Frankfurt B 211,411
141 Düsseldorf (DUS=4) - Frankfurt C
211 Frankfurt - Hamburg (HAM=2) C
511 Frankfurt - Köln B
411 Frankfurt - Düsseldorf A

Setzt man nun als Ereignis die Flug-Nr., die für den Controller zugleich
Informationen über die Strecke und die Abwicklungszeit beinhaltet, und als
Zustände alle die Bedingungen, die für die Realisierung der Flug-Nr. unabdingbar
sind (sein sollen), hier also ‘Flugzeug Z für Flug-Nr. X vorhanden’ (z.B. ‘A 151’),
‘Flugzeug Z für Flug-Nr. X flugbereit’ (z.B. ‘A 151 ok’) und ‘Umsteigepassagiere
von Flug-Nr. X für den Weiterflug bereit’ (z.B. ‘PAX 131’), so können dem
Flugplan hinsichtlich Flug-Nr. 252 die folgenden Zustands-Ereignis-Abbildungen
entnommen werden:
Jedes Element dieser Auflistung wird in der Sprache der Petri-Netz-Theorie als
Abbildung eines Prozesses bezeichnet (z.B. „Der Zustand ‘Flugzeug A 151
befindet sich am Boden’ wird durch Ereignis 151 beendet“). Die Gesamtheit der in
dieser Form systematisch aufgelisteten Prozesse eines Flugplans heißt das
zugehörige ‘unverbundene Netz’.
Die Verbindung der Elemente des unverbundenen Netzes zu einem
zusammenhängenden Prozeßnetz ist gleichbedeutend mit der Definition der co-
Relation. Hier verlangt die Ermittlung der co-Relation eine systematische
Überprüfung und Fixierung der im Flugplan zum Ausdruck gebrachten (geplanten,
aber durchaus nicht unproblematischen, weil z.B. durch Nebel und ähnliches
störanfälligen) Zusammenhänge zwischen den einzelnen Prozessen.
251

252
Dieses Netz entspricht einer möglichen Übersetzung des Flugplanes in ein Petri-
Netz und zwar hier in ein zustandsunverzweigtes Netz, also ein
Synchronisationsnetz.
9.8 Varianten von Petri-Netzen
Für Petri-Netze sind verschiedene Varianten entwickelt worden, die für jeweils
unterschiedliche Problemklassen entwickelt wurden. Die folgenden Varianten sind
[Balzert] entnommen:

9.8.1 Bedingungs-/Ereignis-Netze
Bedingungs-/Ereignis-Netze zeichnen sich dadurch aus, dass die Objekte bzw.
Marken vom Typ boolean sind. Transitionen werden als Ereignisse interpretiert.
Stellen bilden dann Bedingungen. Jede Stelle kann genau eine oder keine Marke
enthalten. Eine Transition t kann schalten, wenn jede Eingabestelle von t eine
Marke enthält und wenn jede Ausgabestelle von t leer ist.
9.8.2 Stellen-/Transitions-Netze
Stellen können bei dieser Variante mehrere Marken enthalten. Transitionen müssen
so viele Marken beim Schalten wegnehmen oder hinzufügen, wie die Gewichte an
den Pfeilen angeben. Soll eine Stelle eine Kapazität größer 1 erhalten, dann wird
dies durch „K = ...“ an der Stelle notiert. Die Kapazität definiert die maximale
Anzahl von Marken, die auf einer Stelle liegen dürfen. Mit dieser Variante ist eine
höhere Komplexität der Beziehungen darstellbar. Jedoch erfordern die Stellen-/
Transitions-Netze eine klare Übersicht über das System und sind in ihrer
Anwendung sehr komplex.
253

254
10 Entscheidungstabellen
10.1 Grundlagen
Entscheidungstabellen (ET) dienen dazu, Entscheidungsprozesse in übersichtlicher,
tabellarischer Form darzustellen und helfen somit komplexe Verarbeitungsregeln
zu spezifizieren. Eine Entscheidungstabelle fasst eine Menge aussagenlogischer
Regeln zusammen. Entscheidungstabellen wurden 1957 in einer Projektgruppe der
General Electric Company entwickelt und sind in DIN 66241 genormt [Balz96].
Eine Entscheidungstabelle besteht im Wesentlichen aus vier Quadranten für
2. Bedingungen
3. Aktionen
4. Bedingungsanzeiger und
5. Aktionsanzeiger
Bei einer ET werden die Bedingungsanzeiger mit den jeweiligen Aktionsanzeiger
verknüpft. Jede Spalte stellt hierbei eine Regel dar, die durch eine Regelnummer
eindeutig bezeichnet wird. Die Regelnnummern werden über den
Bedingungsanzeigerquadranten notiert. Nachfolgend ist die Basis-Struktur einer
Entscheidungstabelle dargestellt.
B 1
-
-
B i
A 1
-
-
-
-
A j
B e d i n g u n g e n
A k t i o n e n
E n t s c h e i d u n g s r e g e l n
R 1 . . . . . . . . . . . . . . R n
B e d i n g u n g s a n z e i g e r
b z w .
- a u s p r ä g u n g e n
A k t i o n s a n z e i g e r
b z w .
- a u s p r ä g u n g e n
Abbildung: Struktur einer Entscheidungstabelle [Sch86], [Sch90]
Um eine Entscheidungstabelle aufzubauen, muss zunächst für einen Anwendungs-
Kontext analysiert werden, welche Bedingungen und welche mögliche Aktionen
auftreten können. Diese werden zunächst in die Entscheidungstabelle in den beiden
linken Quadranten eingetragen.

Anschließend werden alle Bedingungskombinationen ermittelt. Ist eine Bedingung
erfüllt, wird "J" (für Ja) in dem Bedingungsanzeigerteil eingetragen. Andernfalls
erfolgt die Eintragung "N" (für Nein). Ist der Erfüllungsgrad einer Bedingung
irrelevant, so wird in der Tabelle "-" (Irrelevanzanzeiger) eingetragen.
10.2 ET-Typen
Bei ET werden unterschiedliche Darstellungsformen für den Bedingungsteil
unterschieden. Werden im Bedingungsanzeigerteil nur die Werte "J", "N" und "-"
sowie "X" im Aktionsanzeigerteil verwendet, wird eine ET als "begrenzt"
bezeichnet. Oft kann eine kompaktere Darstellung erzielt werden, wenn jedoch
textliche Beschreibungen verwendet werden. In diesem Fall spricht man von
"erweiterten" ET.
Eine ET ist vollständig, wenn alle möglichen Bedingungskombinationen auch als
Regeln vorkommen. Es wird hierbei zwischen "formal vollständig" und "inhaltlich
vollständig" unterschieden. Bei einer formal vollständigen Tabelle werden im
Bedingungsanzeigerteil alle möglichen Kombinationen dargestellt. Bei einer
inhaltlich vollständigen Tabelle werden alle praktisch möglichen Kombinationen
aufgeführt, d.h. es fehlen die unlogischen bzw. offensichtlich unmöglichen
Kombinationen.
Da bei n Bedingungen 2 n Bedingungskombinationen auftreten können, versucht
man nur die wichtigsten Regeln darzustellen und die irrelevanten Fälle durch eine
Else-Regel abzudecken. Durch Einsatz der Else-Regel kann somit aus einer
unvollständigen ET eine vollständige ET erzeugt werden.
10.3 Anwendung von Entscheidungstabellen
Im Folgenden soll an einem Beispiel die Erstellung einer ET beschrieben werden.
Diese dient zur Darstellung des Problemlösungswissens einer Universitätsbibliothek,
die die Ausleihe von Büchern durch ein Software-System
unterstützt. Gemäß der fachlichen Problemstellung müssen verschiedene Fälle
betrachtet werden, wann ein Buch ausgeliehen werden kann. Einige Regeln lauten:
/1/ Wenn ein Benutzer bekannt ist und kein Sperrvermerk für diesen Benutzer
existiert, kann dieser das Buch ausleihen-vorausgesetzt es ist vorhanden.
/2/ Auch wenn ein Benutzer gesperrt ist, dieser jedoch bekannt ist, kann ein Buch
mittels Einzahlungsbeleg ausgeliehen werden.
/3/ Wenn ein Buch nicht vorhanden ist, kann nicht ausgeliehen werden. Allerdings
ist eine Vormerkung möglich, auch wenn der Benutzer gesperrt ist.
255

Bedingungen
B1Benutzer
bekannt
B2Benutzer
gesperrt
B3Buch
vorhanden
B4Einzahlungsbeleg
Aktionen
A1Buch
ausleihen
A2 nicht ausleihen, gesperrt
A3vormerken
A4Systemfehler
A5Einzahlung
eingeben
A6keine
Aktion
256
/4/ Wenn ein Benutzer im System nicht bekannt ist, dieser aber als gesperrt
vermerkt ist, liegt ein Systemfehler vor.
Aus der Problembeschreibung folgt die ET, die in der folgenden Abbildung
dargestellt ist.
R1 R2 R3 R4 R5 R6 R7
J
J J J J N N
N J J N J J J
J J J N N
- J N -
x x
Entscheidungsregeln
Bedingungsanzeiger
x
J
-
N
Aktionsanzeiger
x
x x
-
J
x x
Abbildung: Begrenzte Entscheidungstabelle zur Darstellung des
Problemlösungswissens einer Universitätsbibliothek [Sch86]
Die dargestellte ET ist ein Beispiel für eine begrenzte, unvollständige ET. Sie ist
"begrenzt", da nur Ja-/Nein- sowie "-" Angaben im Bedingungsanzeiger gemacht
werden. Die ET ist "unvollständig", da nicht alle 16 Ja-/Nein-Kombinationen der 4
Bedingungen B1 bis B4 ausgeführt sind, sondern die Tabelle durch die Else-Regel
verkürzt ist.
Vereinfachte Entscheidungstabelle
ET mit mehr als 4 Bedingungen können nur recht schwierig dargestellt werden.
Aus diesem Grunde empfiehlt es sich, diese zu konsolidieren. So können Spalten,
die den gleichen Aktionsteil haben, zusammengefasst werden. Es entsteht dadurch
eine vereinfachte Entscheidungstabelle. In der obigen ET kann z.B. eine
Zusammenfassung von Spalte 4 und 5 bzw. 6 und 7 erfolgen.

Zusätzlich kann durch Darstellung des Else-Zweiges eine vollständige ET erzeugt
werden. Das Ergebnis dieser Konsolidierung ist in der nachfolgenden Abbildung
dargestellt.
B1
B2
B3
B4
A1
A2
A3
A4
A5
A6
Benutzer bekannt
Benutzer gesperrt
Buch vorhanden
Einzahlungsbeleg
Buch ausleihen
nicht ausleihen, gesperrt
vormerken
Systemfehler
Einzahlung eingeben
keine Aktion
R1 R2 R3 R4´ R5´
J J J J N
N - J - J
J J J N
- J N - -
x x
x
x
-
x
ELSE
Abbildung: Ausleihverkehr einer Universitätsbibliothek als vereinfachte
Entscheidungstabelle dargestellt [Sch86]
Sofern noch weitere Regeln aufgrund einer fachlichen Analyse als notwendig
erscheinen, kann die ET entsprechend angepasst werden. Als Beispiel könnte
gefordert sein, dass ein Benutzer maximal 4 Bücher ausleihen und ein Buch
maximal zweimal verlängert werden darf. Diese Regeln werden am günstigsten
durch textuelle Angaben realisiert. In der nachfolgenden Abbildung ist eine
erweiterte ET als Beispiel angegeben.
x
x
257

258
B 1
B 2
B 3
B 4
B 5
B 6
B e d i n g u n g e n
B e n u t z e r b e k a n n t
A n z a h l a u s g e l i e h e n e B ü c h e r
B e n u t z e r g e s p e r r t
B u c h v o r h a n d e n
A n z a h l V e r l ä n g e r u n g e n
E i n z a h l u n g s b e l e g
B 7 A n z a h l M a h n u n g e n
A 1
A 2
A 3
A 4
A k t i o n e n
B u c h a u s l e i h e n
B u c h v e r l ä n g e r n
M a h n g e b ü h r
. . . . . . . . . . .
R 1 R 2 R 3 R 4 R 5 R 6 R 7
J J J J J
X
E n t s c h e i d u n g s r e g e l n
B e d i n g u n g s a n z e i g e r
A k t i o n s a n z e i g e r
J J J
< 5 < 5 < 5 < 5 - - - -
N J N J N J N J
J J - - - - - -
- -
- J - J - -
- - - -
X
≤ 2 ≤ 2
X X
- - - -
- -
R 8
1 - 3 1 - 3 4 , 5 4 , 5
1 D M 2 D M 2 D M 3 D M
Abbildung: Ausleihverkehr einer Universitätsbibliothek als gemischte
Entscheidungstabelle dargestellt [Sch86]
10.4 Entscheidungsbaum
Neben der Quadrantendarstellung mit vertikaler Anordnung der Regeln wird in der
Praxis auch gerne eine horizontale Darstellung der Entscheidungstabelle
vorgenommen. In der folgenden Abbildung ist ein Beispiel hierfür angegeben
[Balz96].
Kreditgrenze
überschritten?
Zahlungs-
Verhalten
einwandfrei?
Überschreitungsbetrag
< 500 Euro?
Scheck
einlösen
Scheck
nicht
einlösen
Neue
Konditionen
vorlegen
J J J X
N X X
N J X
N X
N J J X
N X
N J X
N X
unlogisch
Abbildung: Entscheidungstabelle in horizontaler Darstellungsform [Balz96]

Aus einer Entscheidungstabelle in horizontaler Darstellungsform lässt sich leicht
die Darstellung eines Entscheidungsbaums ableiten. Hierbei werden die
Alternativen explizit ausgeführt. Für obiges Beispiel wird nachfolgend die
äquivalente Baumdarstellung angegeben.
Scheckeinlösung
Kreditgrenze
nicht überschritten
Kreditgrenze
nicht überschritten
Zahlungsverhalten
einwandfrei
Zahlungsverhalten
nicht einwandfrei
Zahlungsverhalten
einwandfrei
Zahlungsverhalten
nicht einwandfrei
Überschreitungsbetrag
< 500 Euro
Überschreitungsbetrag
>= 500 Euro
Überschreitungsbetrag
< 500 Euro
Überschreitungsbetrag
>= 500 Euro
Überschreitungsbetrag
< 500 Euro
Überschreitungsbetrag
>= 500 Euro
Überschreitungsbetrag
< 500 Euro
Überschreitungsbetrag
>= 500 Euro
Abbildung: Entscheidungstabelle als Entscheidungsbaum [Balz96]
Scheck einlösen
Scheck einlösen
und neue
Konditionen
verlegen
Scheck nicht
einlösen
Scheck nicht
einlösen
Scheck einlösen
Unlogisch
Scheck einlösen
Unlogisch
Für das im vorherigen Abschnitt erwähnte Beispiel ist abschließend die alternative
Darstellung als Entscheidungsbaum angegeben.
259

260
B e n u t z e r
b e k a n n t
S o n s t
w e n i g e r a l s
5 B ü c h e r
a u s g e l i e h e n
B e n u t z e r
n i c h t
g e s p e r r t
B e n u t z e r
g e s p e r r t
B e n u t z e r
n i c h t
g e s p e r r t
B e n u t z e r
g e s p e r r t
B u c h v o r h a n d e n
A n z a h l V e r l ä n g e r u n g e n
≤ 2
B u c h v o r h a n d e n
A n z a h l V e r l ä n g e r u n g e n
≤ 2
A n z a h l M a h n u n g e n
1 - 3
A n z a h l M a h n u n g e n
4 - 5
A n z a h l M a h n u n g e n
1 - 3
A n z a h l M a h n u n g e n
4 - 5
Abbildung: Entscheidungsbaum "Buch ausleihen"
E i n z a h l u n g s -
b e l e g
v o r h a n d e n
E i n z a h l u n g s -
b e l e g
v o r h a n d e n
B u c h a u s l e i h e n
B u c h v e r l ä n g e r n
B u c h a u s l e i h e n
B u c h v e r l ä n g e r n
1 D M
2 D M
2 D M
3 D M
K e i n e A k t i o n
Wie den Darstellungen der Entscheidungsbäume entnommen werden kann, ist
diese alternative Darstellungsform insoweit semantisch nicht mit der vertikalen
Darstellungsform identisch, da beim Entscheidungsbaum eine Abarbeitungsfolge
von links nach rechts festgelegt ist.
10.5 Weiterführende Literatur
[Balz96] H. Balzert, Lehrbuch der Software-Technik: Software-Entwicklung,
Spektrum Akademischer Verlag, 1996.
[Sch86] H.-J. Schneider, Lexikon der Informatik und Datenverarbeitung,
Oldenburg, 1986.
[Sch89] F. Schöntaler, Rapid Prototyping zur Unterstützung des Konzeptuellen
Entwurfs von Informationssystemen, Dissertation, Universität
Karlsruhe, Fakultät Wirtschaftswissenschaften, 1989.
[Sch90] A. Schulz, Software Entwurf, P. Oldenburg Verlag, München Wien, 1990.