Software Engineering PS (WS2000/2001)

© Copyright 2000, Schwaiger Roland

Home

Vorbesprechung

Organisation

Thema

Gruppen

Aufgaben

Präsentation

Abschluss

Material

Construction Phase

Aufgabe 8

1. Arbeiten Sie die Kommentare und Anmerkungen der letzten Besprechung mit dem project leader in ihr Gruppendokument ein.
2. Machen Sie sich mit den Unterlagen im Sekretariat und der UML PPT Show von Grady Booch vertraut.
3. Wählen Sie eine Iteration, aus Aufgabe 6. Für diese Iteration erstellen Sie ein konzeptionelles Class Diagram, zeigen sie die wichtigsten Operationen und Attribute für die Klassen und deren Assoziationen.
4. Erstellen Sie Interaction Diagrams, also Sequence und Collaboration Diagrams, für ausgesuchte Fälle.
5. Erstellen Sie ein State Diagram, für eine Klasse Ihrer Wahl.

Zusatzinformation

In der Construction Phase wird das System in einer Serie von Iterationen (Mini Projekten) gebaut. Es wird in jedem Mini Projekt Analysis, Design, Coding, Testing und Integration für jeden, der Iteration zugeordneten Use Case, durchgeführt. Abgeschlossen wird eine Iteration mit einer Benutzerpräsentation und einem Systemtest, um zu verifizieren, dass die Use Cases korrekt implementiert wurden.

Dieser Prozess sollte dazu dienen, Risiken zu minimieren. Die Iterationen in der Construction Phase sind iterativ(bzgl. der Codebasis, jede Iteration bedingt, dass Code der vorherigen Iterationen umgeschrieben wird um flexibler zu werden, siehe auch Refactoring) und inkrementell(bzgl. Funktion, jede Iteration baut auf die Use Cases der vorherigen Iteration auf).

Alle UML Techniken werden in dieser Phase benutzt. Begonnen wird bei einem Use Case. Für diesen der Umfang bestimmt und ein konzeptionelles Class Diagram. Diese "groben" Class Diagrams können benutzt werden, um mit einem domain expert zu kommunizieren. Um den Schritt zum Design zu schaffen, kann man den Use Case durchwandern, um zu sehen, wie die erkannten Klassen, die geforderte Funktionalität durch Zusammenarbeit erfüllen. Also geht es darum Interaktionen zwischen den Klassen zu erkennen, die in weiterer Folge zu Verantwortlichkeiten und Operationen der Klassen führen (siehe auch CRC cards). Die erhaltenen einfachen Designs, können als Grundlage für Diskussionen mit Kollegen über den gewählten Ansatz dienen. Fühlt man sich sicher im Ansatz, kann bereits die Implementierung beginnen.

Sollte man feststellen, dass Schwächen im Design vorhanden sind, wird es nötig sein, das Design nochmals zu überarbeiten. Dies ist ein normaler Vorgang und stellt keinen Fehler in der Designphase dar.

Wurde die Software fertiggestellt, kann die UML benutzt werden, um das Ergebnis zu dokumentieren. Ziel wird es aber nicht sein, für jedes Detail ausführliche Diagramme zu verfassen. Im Endeffekt sollte die Dokumentation dazu dienen, das grobe Bild der erstellen Software zu vermitteln(detailierte Dokumentation sollte direkt vom Code produziert werden, z.B. JavaDoc) und "knifflige" Details herauszuarbeiten. Quasi ein Zwischenschritt, bevor sich ein Entwickler auf den Code st¨rzt.

Package Diagrams können benutzt werden, um eine logische Sicht (logische Strassenkarte) des Systems zu präsentieren. Darin können speziell Abhängigkeiten der einzelnen Teile explizit gemacht werden. Desweiteren kann ein Deployment Diagram herangezogen werden, um die physikalische Struktur auf hohem Level zu zeigen.

In jedem Package, sollten Class Diagrams aus Sicht der Spezifikation vorhanden sein. Es wird nicht nötig sein, alle Operationen anzuzeigen, aber all jene Operationen und Attribute, die für das Verständnis diese Package vonnöten sind. Falls eine Klasse ein kompliziertes zeitliches Verhalten zeigt, dient ein State Diagram zu Beschreibung. Um Interaktionen zwischen Klassen darzustellen werden Interaction Diagrams verwendet, wiederum, nicht für alle Interaktionen, ondern nur für jene, die hinreichend komplex und für das Verständnis essentiell sind.

Falls in manchen Fällen komplexe Algorithmen benutzt werden, können Activity Diagrams zur Veranschaulichung herangezogen werden.