Seemann Software-Entwurf mit UML 2

Objektorientierte Modellierung mit Beispielen in Java
2. Auflage 2006
ISBN: 978-3-540-30950-5
Verlag: Springer-Verlag
Format: PDF
Kopierschutz: Adobe DRM (»Systemvoraussetzungen)

E-Book, Deutsch, 359 Seiten

Die Unifed Modeling Language (UML) ist der etablierte Standard für objektorientierte Modellierungssprachen. Die neue erheblich erweiterte Version 2.0 unterstützt komponentenbasierten Entwurf und die Spezifikation eingebetteter Systeme.

Dieses Buch macht die UML 2 beherrschbar. Es bietet nach einer Einführung in die objektorientierte Modellierung, die die wichtigsten UML Diagramme herausstellt, eine kompakte, anschauliche Darstellung des Sprachumfangs mit vielen Beispielen. Schwerpunkt des Buches ist die schrittweise Verfeinerung des Modells bis hin zur Implementierung als Java-Programm. Dabei wird ein flexibles, praxiserprobtes Vorgehensmodell vorgestellt, welches die Verantwortung der Klassen betont und in dem jede Anforderung durch den gesamten Entwicklungsprozess verfolgt werden kann. Für jede der Entwurfsphasen wird ein durchgängiges Anwendungsbeispiel behandelt.

Die beigefügte CD-ROM enthält die UML-Spezifikationen als pdf, die UML-Referenz als html-Dateien sowie alle Quelltexte der Java-Programme.

Autoren/Hrsg.

Seemann, Jochen

Inhaltsverzeichnis

1;Vorwort;6
2;Vorwort zur zweiten Auflage;8
3;Inhaltsverzeichnis;9
4;TEIL I UML als Entwurfssprache;15
4.1;1 Modellierung von Software-Systemen;16
4.1.1;1.1 Entstehung der UML;17
4.1.2;1.2 Zum Aufbau des Buches;19
4.1.3;1.3 Modelle, Sichten und Diagramme;21
4.1.4;1.4 Das statische Modell;25
4.1.5;1.5 Das dynamische Modell;26
4.2;2 Das Use-Case-Diagramm;29
4.2.1;2.1 Anwendungsfälle;30
4.2.2;2.2 Das Anwendungsfalldiagramm;32
4.2.3;2.3 Verfeinerung von Anwendungsfällen;33
4.2.4;2.4 Beziehungen in Use-Case-Diagrammen;34
4.2.5;2.5 Zusammenfassung;38
4.3;3 Das Aktivitätsdiagramm;40
4.3.1;3.1 Abläufe und Vorgänge;41
4.3.2;3.2 Aufteilung des Kontrollflusses;43
4.3.3;3.3 Zuteilung der Verantwortung;45
4.3.4;3.4 Objektfluss;45
4.3.5;3.5 Aktivitäten und Aktionen;48
4.3.6;3.6 Algorithmen;48
4.3.7;3.7 Zusammenfassung;51
4.4;4 Das Klassendiagramm;55
4.4.1;4.1 Klassen;56
4.4.2;4.2 Attribute und Operationen;57
4.4.3;4.3 Verantwortlichkeiten;60
4.4.4;4.4 Objekte;61
4.4.5;4.5 Verknüpfungen;63
4.4.6;4.6 Assoziationen;63
4.4.7;4.7 Generalisierung;77
4.4.8;4.8 Klassen und Schnittstellen;81
4.4.9;4.9 Geschachtelte Klassen;83
4.4.10;4.10 Schablonen;83
4.4.11;4.11 Erläuternder Text;84
4.4.12;4.12 Stereotypen;88
4.4.13;4.13 Zusammenfassung;89
4.5;5 Das Sequenzdiagramm;91
4.5.1;5.1 Nachrichtenaustausch;92
4.5.2;5.2 Aktivitätszonen;93
4.5.3;5.3 Asynchrone Nachrichten;95
4.5.4;5.4 Erzeugung und Zerstörung von Objekten;96
4.5.5;5.5 Regelung des Interaktionsablaufs;97
4.5.6;5.6 Zeitachse;103
4.5.7;5.7 Zusammenfassung;104
4.6;6 Weitere Interaktionsdiagramme;106
4.6.1;6.1 Das Kommunikationsdiagramm;107
4.6.2;6.2 Das Timing-Diagramm;113
4.6.3;6.3 Das Interaktionsübersichtsdiagramm;114
4.7;7 Das Zustandsdiagramm;116
4.7.1;7.1 Zustandsautomaten;117
4.7.2;7.2 Zustände und Ereignisse;118
4.7.3;7.3 Verzweigungen;120
4.7.4;7.4 Atomare und andauernde Aktivitäten;122
4.7.5;7.5 Hierarchische Zustandsdiagramme;124
4.7.6;7.6 Protokollzustandsautomaten;128
4.7.7;7.7 Zusammenfassung;129
4.8;8 Die Komponentendiagramme;131
4.8.1;8.1 Das Komponentendiagramm;132
4.8.2;8.2 Das Installationsdiagramm;136
4.8.3;8.3 Das Kompositionsdiagramm;137
4.8.4;8.4 Das Kooperationsdiagramm;141
4.9;9 Das Paketdiagramm;147
4.9.1;9.1 Pakete und Abhängigkeiten;148
4.9.2;9.2 Zusammenwirken von Paketen;150
4.9.3;9.3 Modelle;154
5;TEIL II Anwendung der UML;155
5.1;10 Ein Vorgehensmodell für den Software-Entwurf;156
5.1.1;10.1 Anforderungsermittlung;157
5.1.2;10.2 Analyse;161
5.1.3;10.3 Entwurf;167
5.1.4;10.4 Implementierung;172
5.1.5;10.5 Bemerkungen;174
5.1.6;10.6 Komponentenbasierte Implementierung;176
5.1.7;10.7 Modularisierung;177
5.1.8;10.8 Das Vorgehensmodell – kurz gefasst;180
5.1.9;10.9 Einsatzgebiete der Diagramme;181
5.2;11 UML und Java;184
5.2.1;11.1 Klassende.nitionen;186
5.2.2;11.2 Beziehungen zwischen Klassen;189
5.2.3;11.3 Methodenrümpfe;199
5.2.4;11.4 Pakete;205
5.2.5;11.5 Java Klassenbibliotheken;206
5.3;12 Entwurfsmuster;211
5.3.1;12.1 Einführung und Begriffsklärung;212
5.3.2;12.2 Das Kompositum-Muster;213
5.3.3;12.3 Das Beobachter-Muster;218
5.3.4;12.4 Das Adapter-Muster;223
5.3.5;12.5 Das Kommando-Prozessor-Muster;227
5.3.6;12.6 Das Status-Muster;229
5.3.7;12.7 Der Asynchrone Methodenaufruf;235
5.3.8;12.8 Software-Entwurf mit Entwurfsmustern;237
5.4;13 Fallstudie: Eine Tabellenkalkulation;240
5.4.1;13.1 Einführung;241
5.4.2;13.2 Anforderungsermittlung;243
5.4.3;13.3 Analyse und Entwurf;250
5.4.4;13.4 Implementierung in Java;279
6;TEIL III Formale Grundlagen der UML;281
6.1;14 Erweiterungsmechanismen;282
6.1.1;14.1 Präzisierung;283
6.1.2;14.2 Zusätzliche Information;283
6.1.3;14.3 Vereinbarung von Stereotypen;284
6.1.4;14.4 Profile;286
6.1.5;14.5 Die OCL;286
6.2;15 Das UML-Metamodell;292
6.2.1;15.1 Modell und Metamodell;293
6.2.2;15.2 Die 4-Schichten Architektur von UML;294
6.2.3;15.3 Zusammenfassung;296
7;TEIL IV Anhang;297
7.1;A Die UML Referenz;298
7.1.1;A.1 Gemeinsame Elemente aller Diagramme;299
7.1.2;A.2 Use-Case-Diagramm;300
7.1.3;A.3 Aktiviätsdiagramm;303
7.1.4;A.4 Klassendiagramm;310
7.1.5;A.5 Sequenzdiagramm;320
7.1.6;A.6 Weitere Interaktionsdiagramme;326
7.1.7;A.7 Zustandsdiagramm;333
7.1.8;A.8 Komponentendiagramme;340
7.1.9;A.9 Paketdiagramm;349
7.1.10;A.10 Die OCL-Syntax;352
7.1.11;A.11 Vorde.nierte Stereotypen;353
7.1.12;A.12 Vorde.nierte Bedingungen;354
7.2;B Inhalt der CD-ROM (nicht im eBook enthalten);355
8;Literatur;357
9;Index;359

Leseproben

(S. 121-122)

Komponenten beschreiben Teile der Software sowohl mit logisch inhaltlichen Aspekten als auch mit physisch vorhandenen Artefakten. Zu Letzteren gehören die Implementierung betre.ende Dokumente sowie Dateien während der Erstellung, Installation oder Wartung. Komponentendiagramme (Verdrahtungsdiagramme) verdeutlichen die Abhängigkeiten der Komponenten. Kompositionsdiagramme beschreiben die innere Struktur von Komponenten und strukturierten Klassen. Installationsdiagramme (Verteilungsdiagramme) veranschaulichen die Verteilung der Artefakte auf Rechnerknoten.

• Komponenten
• Strukturierte Klassen
• Kooperation
• Software-Architektur
• Verteilte Software

8.1 Das Komponentendiagramm

Der Traum, Software aus fertigen aber anpassbaren Komponenten zusammmenzustecken, ist so alt wie die Softwaretechnik selbst. Ein wichtiges Ziel bei der Modellierung ebenso wie bei der Programmierung ist das Scha.en von wiederverwendbaren Einheiten. Diese Einheiten sollten in sich abgeschlossen sein, um direkt eingesetzt werden zu können, andererseits aber auch anpassbar oder kon.gurierbar, um ein breiteres Einsatzspektrum abzudecken. In einem Komponenten-basierten Modell kommunizieren die Komponenten entlang der Verknüpfungen.



Die einfachste Interpretation einer Komponente ist die eines Objekts, die Kommunikation erfolgt durch Methodenaufrufe. Dies kann in einem Rechnernetzwerk durchaus über Rechnergrenzen hinaus geschehen. Komponenten sollen aber eigentlich .exibler reagieren können als Objekte. Ein Mechanismus der Komponenten verbindet, zusammmensteckt oder verdrahtet, soll anschaulicher als durch eine Assoziation charakterisiert werden. Eine Komponente erfüllt einen Zweck, diesen Zweck kann sie durch Bereitstellen einer Schnittstelle dokumentieren, andererseits agiert die Komponente nicht völlig autark, sie ist auf die Anwesenheit anderer Komponenten angewiesen.

Da sie Schnittstellen bereitstellt und die Existenz weiterer Schnittstellen erfordert, besitzt eine Komponente wie eine Klasse Eigenschaften eines Datentyps. Die Betonung liegt hier auf der ausführungsnahen Sicht der Zusammenarbeit über Schnittstellen, weniger auf den Interna der Methoden. Ein sehr nahe liegendes Beispiel sind die Komponenten einer gra.schen Benutzerober.äche. Aber man kann mit Komponenten auch ein verteiltes System von unter Umständen heterogenen Rechnerarchitekturen modellieren, in dem die Kommunikation durch vorgefertigte Protokolle und Zwischensprachen erfolgt.

Wir wollen unser Monopoly Spiel mit Hilfe von Komponenten modellieren.

Beispiel (Monopoly) 68

Die einfachste Komponente, die auch sehr gut wiederverwendbar ist, ist ein Würfel.

Eine Komponente (als Typ) wird wie eine Klasse gezeichnet. Der Stereotyp component kann textuell oder als Komponentensymbol angegeben werden. Die zur Verfügung gestellte Schnittstelle wird in der Lollipop Notation (siehe Kapitel 4.8) notiert.