Software Engineering PS (WS2000/2001)

© Copyright 2000, Schwaiger Roland

Home

Vorbesprechung

Organisation

Thema

Gruppen

Aufgaben

Präsentation

Abschluss

Material

Architecture, Project Plan

Aufgabe 6

1. Arbeiten Sie die Änderungen lt. Besprechung mit dem project leader in ihr Gruppendokument ein.
2. Erstellen Sie in der Gruppe, also keine Individuallösungen, eine Software Architektur für ihr System und dokumentieren Sie diese mithilfe der UML.
3. Erstellen Sie in der Gruppe, also keine Individuallösungen, einen Projekt Plan für die Construction Phase.

Architektur

• Der Organisation des Software Systems.
• Den strukturellen Elementen und ihren Interfaces, die das System darstellen, mit ihren Verhalten und deren Zusammenarbeit.
• Die Zusammensetzung der strukturellen Elementen und der Verhalten in schrittweise grössere Subsysteme.
• Den "architectural style", der die Organisation lenkt: die Elemente und ihre Interfaces, ihre Zusammenarbeit und ihre Zusammensetzung.

• Das System zu verstehen.
• Die Entwicklung zu koordinieren.
• Reuse zu unterstützen.
• Das System zu entwickeln.

Man kann z.B. damit beginnen, getrieben, durch die USE Cases, die ausgearbeitet wurden, Module zu definieren, deren Gesamtheit das System darstellt. Ansich ist eine Architektur spezifisch für ein Problem, aber man kann sehen, dass sg. pattern entwickelt wurden, um uns bei der prinzipiellen Struktur der Architektur zu unterstützen (siehe auch Gang of 4, Gamma et.al.). 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.

Natürlich wird die Architektur noch von anderen Faktoren beeinflusst:

• Die Software auf die wir aufbauen wollen, z.B. Betriebssystem, RDBMS, et c.
• Welche Middleware wir verwenden wollen, z.B. ORB Typ, ...
• Altsysteme, die benutzt werden.
• Welche Standards unerstützt werden.
• Nicht funktionale Anforderungen.
• Verteilungsmechanismen und Prinzipien des Systems.

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 hilft 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.

Einige der Architektur patterns sind:

• Der Broker pattern ist ein generischer pattern zum Verwalten von Objekt Distributionen. Es erlaubt Objekte anderer Objekte (remote) über einen Broker zu rufen. Der Broker pattern benutzt sehr oft den Proxy pattern, der ein lokales Proxy Objekt mit selben Interface wie das remote Objekt zur Verfügung stellt.
• Der Client/Server, Three-Tier und Peer-to-Peer pattern beschreibt die Verteilung (Deployment) der Komponenten auf die unterschiedlichen Knoten (siehe Grafik witer unten).
• Der Layer pattern definiert, wie das Design Modell in Schichten aufgeteilt werden kann.
• Pipe and Filter pattern definiert, wie Daten von einem Teil übernommen werden, verarbeitet werden und weitergereicht werden. Das nächste Teil übernimmt die Daten, verarbeitet diese und reicht sie wiederum weiter, etc. (Beispiel für eine Pipe und Filter Architektur: PPKT II SS2000, Visualization of netJEN problem domains and results
• Object-Oriented Pattern definiert, wie Subsysteme um Daten und den entsprechenden Funktionen herum definiert werden.

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 (f¨r weitere Modulkriterien siehe 7) verwenden und auf die Subsysteme anwenden:

• Hat das Subsystem eine einzige Funktionalität?
• Hat das Subsystem eine starke interne Bindung?
• Haben die Subsysteme eine schwache äussere Bindung?
• Gibt es minimale Kommunikation zwischen den Subsystemen?

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).

Projekt Plan für die Construction Phase

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 pro Iteration 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 für die Construction Phase.