Kapitel 6. Design

Inhaltsverzeichnis

6.1. Der Designprozess (Noch zu beschreiben)
6.1.1. Klasse, Verantwortlichkeits- und Zusammenhänge- (CRC) Karten
6.1.2. Paketdiagramm (Noch zu beschreiben)
6.1.3. Klassendiagramme realisieren (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 Paketfunktionen (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 Klassenfunktionen
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, Verantwortlichkeits- 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. Klassendiagramme realisieren (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...