Seemann / Wolff von Gudenberg Software-Entwurf mit UML 2

Objektorientierte Modellierung mit Beispielen in Java
2. Auflage 2006
ISBN: 978-3-540-30950-5
Verlag: Springer Berlin Heidelberg
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Deutsch, 361 Seiten

Reihe: Xpert.press

Das Buch macht die UML 2 beherrschbar. Es führt in die objektorientierte Modellierung mit den wichtigsten UML 2-Diagrammen ein und liefert eine kompakte Darstellung des Sprachumfangs. Schwerpunkt ist die schrittweise Verfeinerung des Modells bis hin zur Implementierung als Java-Programm. Jede Entwurfsphase wird mit einem Anwendungsbeispiel veranschaulicht.

Autoren/Hrsg.

Seemann, Jochen

Wolff von Gudenberg, Jürgen

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

Kapitel 8 Die Komponentendiagramme (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.

8.1.1 Logische Komponenten

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.