Kapitel 6. Design

Inhaltsverzeichnis

6.1. Der Designprozess (Noch zu beschreiben)
6.1.1. Klasse, Verantwortlichkeiten und Zusammenh??nge (CRC) Karten
6.1.2. Paketdiagramm (Noch zu beschreiben)
6.1.3. Realisierungs-Klassendiagramme (Noch zu beschreiben)
6.1.4. Sequenz- und Kollaborationsdiagramme (Noch zu beschreiben)
6.1.5. Zustands- und Aktivit??tsdiagramme ( Noch zu beschreiben)
6.1.6. Verteilungsdiagramme (Noch zu beschreiben)
6.1.7. Dokumente (Noch zu beschreiben)
6.2. Paketdiagramme (Noch zu beschreiben)
6.2.1. Das Paketdiagramm (Noch zu beschreiben)
6.2.2. Erweiterte Paketdiagramme (Noch zu beschreiben)
6.3. Paketdiagramme in ArgoUML erstellen
6.3.1. Pakete
6.3.2. Beziehungen zwischen Paketen (Noch zu beschreiben)
6.3.3. Erweiterte Paketeigenschaften (Noch zu beschreiben)
6.4. Mehr ??ber Klassendiagramme (Noch zu beschreiben)
6.4.1. Das Klassendiagramm (Noch zu beschreiben)
6.4.2. Erweiterte Klassendiagramme (Noch zu beschreiben)
6.5. Mehr ??ber Klassendiagramme in ArgoUML (Noch zu beschreiben)
6.5.1. Klassen (Noch zu beschreiben)
6.5.2. Klassenattribute und -operationen (Noch zu beschreiben)
6.5.3. Erweiterte Klasseneigenschaften
6.6. Sequenz- und Kollaborationsdiagramme ( Noch zu beschreiben)
6.6.1. Mehr ??ber das Sequenzdiagramm (Noch zu beschreiben)
6.6.2. Das Kollaborationsdiagramm (Noch zu beschreiben)
6.6.3. Erweiterte Kollaborationsdiagramme (Noch zu beschreiben)
6.7. Kollaborationsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.7.1. Kollaborationsdiagramme (Noch zu beschreiben)
6.7.2. Nachrichten (Noch zu beschreiben)
6.7.3. Erweiterte Kollaborationsdiagramme (Noch zu beschreiben)
6.8. Zustandsdiagramme (Noch zu beschreiben)
6.8.1. Das Zustandsdiagramm (Noch zu beschreiben)
6.8.2. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
6.9. Zustandsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.9.1. Zustandsdiagramme (Noch zu beschreiben)
6.9.2. Zust??nde (Noch zu beschreiben)
6.9.3. Transitionen (Noch zu beschreiben)
6.9.4. Aktionen (Noch zu beschreiben)
6.9.5. Erweiterte Zustandsdiagramme (Noch zu beschreiben)
6.10. Aktivit??tsdiagramme (Noch zu beschreiben)
6.10.1. Das Aktivit??tsdiagramm (Noch zu beschreiben)
6.11. Aktivit??tsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.11.1. Aktivit??tsdiagramme (Noch zu beschreiben)
6.11.2. Aktionszust??nde (Noch zu beschreiben)
6.12. Verteilungsdiagramme (Noch zu beschreiben)
6.12.1. Das Verteilungsdiagramm (Noch zu beschreiben)
6.13. Verteilungsdiagramme in ArgoUML erstellen ( Noch zu beschreiben)
6.13.1. Knoten (Noch zu beschreiben)
6.13.2. Komponenten (Noch zu beschreiben)
6.13.3. Beziehungen zwischen Knoten und Komponenten ( Noch zu beschreiben)
6.14. System-Architektur (Noch zu beschreiben)
6.15. Fallstudie (Noch zu beschreiben)
6.15.1. CRC-Karten (Noch zu beschreiben)
6.15.2. Pakete (Noch zu beschreiben)
6.15.3. Klassendiagramme (Noch zu beschreiben)
6.15.4. Sequenzdiagramme (Noch zu beschreiben)
6.15.5. Kollaborationsdiagramme (Noch zu beschreiben)
6.15.6. Zustandsdiagramme (Noch zu beschreiben)
6.15.7. Aktivit??tsdiagramme (Noch zu beschreiben)
6.15.8. Das Verteilungsdiagramm (Noch zu beschreiben)
6.15.9. Die System-Architektur (Noch zu beschreiben)

Wir haben jetzt das Problem, das wir in der Sprache der vermeintlichen L??sung zu l??sen versuchen. In der Designphase konstruieren wir alle Details dieser L??sung.

Die verwischten Grenzen zwischen der Analyse und dem Design zeigt sich hier auch durch die gemeinsame Verwendung derselben UML-Werkzeuge. In diesem Kapitel werden wir sehr h??ufig die UML-Technologie verwenden, die wir bereits kennengelernt haben. Der grosse Schritt ist das Umwandeln in konkrete Ausdr??cke. Wir bewegen uns von den abstrakten Konzepten der Analyse hin zu deren konkreten Realisierung.

Erneut bedeutet die rekursive und iterative Natur unseres Prozesses, dass wir in Zukunft viele Male zur??ck in die Designphase kommen.

6.1. Der Designprozess (Noch zu beschreiben)

Der Designprozess erweitert den Modellierungsaufwand jenseits der Gesch??ftsanforderungen in Richtung des L??sungsraumes. W??hrend dieser Arbeit entscheiden Sie, ob Sie Java, C++, J3EE, CORBA, SOAP, W??hlleitungen, Internetverbindungen, Standleitungen, XML, usw. verwenden werden. Viele dieser Entscheidungen werden das PSM-Modell direkt beeinflussen, andere widerum werden sich nur in den erzeugten Dokumenten wiederspiegeln.

...

6.1.1. Klasse, Verantwortlichkeiten und Zusammenh??nge (CRC) Karten

Die St??rken der CRC-Karten w??hrend des Design

  • Verbreitern der objektorientierten Design-Expertise

  • Design Reviews

  • Framework die Implementierung

  • Informelle Notation

  • Auswahl der unterst??tzenden Softwarekomponenten

  • Performance-Anforderungens

In dieser Phase ersetzen die Entwickler einige der fachlichen Experten in der Gruppe. Es sollte aber immer mindestens ein fachlicher Experte in der Gruppe verbleiben.

Der Fokus der Gruppe bewegt sich von der Frage was zu tun ist hin zu der Frage wie es zu tun ist. Der Klassen aus dem L??sungsbereich werden denen der Analysephase hinzugef??gt. Es wird dar??ber nachgedacht, welche Klassen werden ben??tigt, damit das System arbeitet. Ben??tigen Sie eine Listenklasse, die Objekte beinhaltet? Ben??tigen Sie Klassen, die Ausnahmen behandeln? Ben??tigen Sie Wrapperklassen f??r andere Subsysteme? In diesem Abschnitt wird nach neuen Klassen gesucht, nach Klassen, die die Implementierung des Systems unterst??tzen.

W??hrend der Designphase wird der Unterschied zwischen Klasse und Objekt wichtig. Denken Sie ??ber die Objekte in Ihren Szenarien nach. Wer erzeugt die Objekte? Was passiert, wenn sie erzeugt und gel??scht werden? Wie ist die Lebensdauer des Objektes im Gegensatz zur Lebensdauer der Information, die durch das Objekt gehalten wird.

Jetzt ist es an der Zeit sich anzusehen, welche Informationen die Objekte halten, verglichen mit den von anderen Klassen angeforderten oder berechneten Informationen. Benutzen Sie die R??ckseite der Karte, um die gefundenen Attribute f??r diese Klassen aufzuschreiben. Teilen Sie die Verantwortlichkeiten in Sub-Verantwortlichkeiten auf und listen Sie die Sub-Verantwortlichkeiten unter der Hauptverantwortlichkeit einger??ckt auf. Verschieben Sie die daf??r notwendigen Klassen zu den Verantwortlichkeiten die sie nutzen. ^

Hinter der Kollaboratorklasse listen Sie auf Ihrer Karte die Verantwortlichkeit der in dieser Zusammenarbeit verwendeten Klasse auf. Hinter den kollaborierenden Verantwortlichkeiten Ihrer Karte listen Sie die durch die kollaborierenden Objekte zur??ckgelieferten Daten in Klammern auf.

Spielen Sie die Szenarien der Analysephase erneut durch, beachten Sie dabei aber alle Erw??gungen der diskutierten Design-Heuristiken. Nehmen Sie Ihre eigenen Szenarien und versuchen Sie es.

6.1.2. Paketdiagramm (Noch zu beschreiben)

Noch zu beschreiben...

6.1.3. Realisierungs-Klassendiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.1.4. Sequenz- und Kollaborationsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.1.5. Zustands- und Aktivit??tsdiagramme ( Noch zu beschreiben)

Noch zu beschreiben...

6.1.6. Verteilungsdiagramme (Noch zu beschreiben)

Noch zu beschreiben...

6.1.7. Dokumente (Noch zu beschreiben)

System Architektur. Noch zu beschreiben...