Aufgabe

References: 3 Amigos

Architektur

Im nächsten Schritt benötigen wir einen Ansatz, um das System in Teile zu zerlegen, die eine Grösse haben, um sie zu realisieren bzw. damit zu arbeiten. Wir beginnen damit Module zu definieren, deren Gesamtheit das System darstellt. Ansich ist eine Architektur spezifisch für ein Problem, aber wir werden sehen, dass sg. pattern entwickelt wurden, um uns bei der prinzipiellen Struktur der Architektur zu unterstützen (siehe auch Gang of 4). Diese patterns zeigen eine prinzipielle Strukur des Systems, ohne auf die Details der Komponenten einzugehen.

Beim bisherigen Ausarbeiten der Use Cases haben Sie sich sicher dabei ertappt, gewisse signifikante Teile des Systems identifiziert zu haben, z.B. ist der Gedanke naheliegend, dass das System in mehrere Module aufgeteilt werden kann, die sich mit der Datenbank, dem Business Layer und dem GUI beschäftigen. Oder wir haben die Anforderung, dass unser System auf mehrere Prozessoren (Maschinen) verteilt werden muss. Unser Ziel ist es nun, diese Informationen in einer entsprechenden Art und Weise zu dokumentieren.

Der erste Schritt, den man machen könnte, wäre die prinzipielle Annahme, einer Grundstruktur unseres Systems aufgrund bereits definierter patterns. Wir wuerden uns den passensten auswählen und nach und nach Details, aufgrund der Use Cases zu dem pattern hinzufügen (z.B. Details zu den Modulen bzw. Interfaces zwischen den Modulen). Im Laufe der Zeit stellt sich heraus, ob der gewählte pattern ein passender war, oder nicht. Diesen Ansatz könnte man als Top Down Ansatz bezeichnen. Ein weiteres mögliches Vorgehen wäre der Bottom Up Ansatz. Aufgrund der erkannten Use Cases wird eine Kategorisierung, der Funktionen durchgeführt, und diese zu Modulen zusammengefasst. In weiteren Schritten werden Beziehungen zwischen den Modulen (Interfaces) und Verfeinerungen der Module aufgrund von weiteren Use Cases, durchgeführt.

Nehmen sie sich Teile, bzw. Use Cases vor, die "zentrale" Funktionalität darstellen. Diese Teile werden in UML als Subsysteme dargestellt (siehe Kopien Sekretariat). Bescheiben Sie diese Subsysteme (deren Funktionalität), das wird ihnen helfen festzustellen, ob die Subsysteme wohldefiniert sind und im Sinne des Modulgedanken gekapselt sind. Desweiteren hilf die Beschreibung, Interfaces (Schnittstellen) zwischen den Systemen zu finden und zu definieren, also welches Subsystem mit welchem Subsystem zusammenarbeitet. Zuguterletzt, nachdem die Subsysteme und deren Beziehungen definiert wurden, wird man versuchen Teile oder das ganze System aus Subsystemen mit Architektur patterns zu vergleichen.

Wie man im obigen Beispiel sieht, werden Subsysteme als Karteiordner dargestellt und die Beziehungen, d.h. dort wo Interfaces bestehen, werden mithilfe strichlierter Pfeile visualisiert.

Nehmen wir an, sie haben die Subsysteme identifiziert, diese beschrieben und Beziehungen zwischen diesen Teilen spezifiziert und die prinzipiellen Architektur pattern identifiziert. Wie können sie sicher sein, dass die Architektur zu ihrem Problem passt? Wir können die folgenden Modultests verwenden und auf die Subsysteme anwenden:

Die nächste Prüfung besteht darin, die Use Cases heranzuziehen und diese Schritt für Schritt durch die Architektur abzuarbeiten. Für jeden Schritt wird bestimmt, welches Subsystem diesen Schritt bearbeitet. Falls ein Subsystem ein anderes Subsystem benötigt, um Teile des Use Cases abzuarbeiten, stellt sich die Frage, ob zwischen diesen Subsystemen eine Beziehung besteht. Dieser Test sollte dazu verwendet werden, die Beschreibung der Subsysteme zu verfeinern, Beziehungen zwischen den Subsystemen einzufügen, Beschreibung zu den Beziehungen zu hinterlegen und möglicherweise neue Subsysteme einzufügen.

Beim "durchwandern" der Use Cases werden Operationen lokalisiert, die von einem Subsystem in einem anderen Subsystem gerufen werden. Bis jetzt wurden zwar die Pfeile zwischen den Subsystemen gezeichnet, aber die Operationen wurden noch nicht aufgezeichnet. Diese Operationen werden im Main Compartment des Subsystems der Reihe nach angeführt (siehe Kopie Sekretariat).

Weitere Ausführungen, basierend auf 3 Amigos: Use Cases alleine sind nicht ausreichend um ein funktionierendes System zu erstellen. Es wir mehr benötigt, nämlich die Architektur. Diese wird über mehrere Iterationen in der Inception und Elaboration Phase entwickelt. Besonders die Elaborationsphase dient dazu eine "architectural baseline" zu entwickeln, um in der Construction Phase die Entwicklung mit einem soliden Fundament zu beginnen. Die Architektur eines Systems kann von unterschiedliche Sichten (views) präsentiert werden. (Referenz: Booch und Kruchten). Die Architektur unterstützt bei den Entscheidungen zu

Wie kann nun so eine Beschreibung zu einer Architektur aussehen? Wie oben erwähnt, wird die Architektur als eine Sammlung von Sichten dargestellt: eine Sicht auf das Use Case Modell, eine Sicht auf das Analysis Modell, eine Sicht auf das Design Modell, ... (Referenz: Kruchten, Sekretariat). Nachdem die Sicht eines Modells ein Extrakt ist, wird die Sicht, z.B. eines Use Case Modells wie ein Use Case Modell aussehen. Es hat Actors und Use Cases, aber nur jene, die für die Architektur relevant sind. Warum wird Architektur benötigt? Um Unser Ziel wird es sein, die konkretisierten Use Cases, also unser Use Case Modell, als Grundlage für die Architektur zu verwenden. Also wollen wir eine Architektur entwickeln, die die Use Cases implementiert, nicht nur jetzt, sondern auch in weiterer Folge. Die Use Cases können auch als treibende Kraft (use case driven) hinter der Entwicklung der Architektur gesehen werden. In den Anfangsiterationen wählen wir jene Use Cases, von denen wir annehmen, dass sie am besten geeignet sind, eine Architektur abzuleiten. Natürlich werden jene Use Cases mitberücksichtigt, die vom Kunden im nächsten Release benötigt werden. Nat¨rlich wir die Architektur noch von anderen Faktoren beeinflusst: Die Architektur wird in Iterationen der Elaboration Phase entwickelt. Ein einfacher Ansatz wäre, das Design der Architektur auf einer sehr abstrakten Ebene zu beginnen, z.B. ein geschichtetes Modell (layered). Sukzessive nimmt man in weiterer Folge bestimmte Aspekte in das Design der Architektur auf. In einem ersten Schritt ber¨cksichtigt man die applikationsunabhängigen Teile, z.B. Systemsoftware, middleware, Altsysteme, Standards, nicht funktionale Anforderungen. In einem nächsten Schritt wir der applikationsspezifische Teil der Architektur betrachtet. Einige der Architektur patterns sind:

Projekt Plan für die Construction Phase

(Referenz: Fowler, Extreme Programming) Prinzipiell geht es darum eine Serie von Iterationen zu planen zur Konstruktion und Definition von Funktionalität, die am Ende der Iteration geliefert wird. Man könnte z.B. ganze Use Cases pro Iteration benutzen und diese vollständig implementieren bzw. grosse Use Cases benutzen und einige Szenarios pro Iteration erledigen. Prinzipiell läuft die Planung identisch ab.

In einem ersten Schritt werden die Use Cases kategorisiert. Zuerst bekommt der Kunde die Chance die Use Cases nach deren Wichtigkeit, bzgl. der Problemstellung, zu ordnen. Diese Bewertung kann sich seit der initialen Besprechung verändert haben, nachdem am Ende der Elaboration Phase ung. 80% der Use Cases bekannt sein sollten. Dann sortiert der Entwickler die Use Cases nach dem Entwicklungsrisiko. Also hohes Risiko für etwas, das schwer zu implementieren ist, das grossen Einfluss auf das Design des Systems hat, oder das nicht richtig verstanden wird (das sollte nicht passieren, wofür sind sonst die ganzen Besprechungen). Im nächsten Schritt sollte der Entwickler für jeden Use Case die Entwicklungszeit schätzen (in Mannwochen) und dabei nicht vergessen, dass Analyse, Desing, Coding, Unit Testing, Integration und Dokumentation erforderlich sind. Die Schätzmethode ist beliebig.

Der nächste Schritt betrifft die Definition der Iterationslänge. Anzustreben ist eine fixe Iterationslänge für das ganze Projekt, um einen regulären Rhythmus für die Lieferungen zu erreichen. Eine Iterationslänge sollte reichen um einige Use Cases zu behandeln.

Jetzt werden Use Cases zu den Iterationen zugeordnet. Naturgemäss sollten Use Cases mit hoher Priorität und/oder hohem Risiko zuerst behandelt werden.

Aus der Zuordnung der Use Cases zu den Iterationen, der Iterationsdauer und Iterationsanzahl ergibt sich der Projekt Plan.