3.2. UML basierter Prozess für OOA&D

Sie müssen verstehen, dass UML eine Notation für die OOA&D ist. Sie schreibt keinen bestimmten Prozess vor. Welcher Prozess auch immer angewendet wird, ein System wird in mehreren Phasen konstruiert.

  1. Erfassen der Anforderungen. In dieser Phase identifizieren wir die Anforderungen an das System. Dabei verwenden wir die Sprache des Problembereiches. Mit anderen Worten, wir beschreiben das Problem mit den Begrifflichkeiten des „Kunden“.

  2. Analyse. Wir nehmen die Anforderungen und beginnen diese in die Sprache der vermeintlichen Lösung umzuformen, in den Lösungsbereich. Zu diesem Zeitpunkt halten wir die Dinge auf einer hohen Abstraktionsebene, obwohl wir bereits in den Begrifflichkeiten der Lösung denken - abseits von den konkreten Details einer spezifischen Lösung. Dieser Vorgang ist als Abstraktion bekannt.

  3. Design. Wir nehmen die Spezifikation aus der Analysephase und konstruieren die Lösung ganz detailliert. Wir bewegen uns von der Abstraktion des Problemes, hin zu seiner Realisierung in konkreter Form.

  4. Build-Phase. Wir nehmen das aktuelle Design und setzen es in eine reale Programmiersprache um. Das schliesst nicht nur die Programmierung ein, sondern auch das Testen, ob das Programm den Anforderungen (Verifikation) entspricht, testen, ob das Programm das aktuelle Kundenproblem löst ( Validierung) und das Schreiben der gesamten Anwenderdokumentation.

3.2.1. Prozesstypen

In diesem Abschnitt sehen wir uns die beiden Hauptprozesstypen an, die im Software-Engineering verwendet werden. Es gibt noch weitere, diese werden aber weniger häufig eingesetzt.

In den letzten Jahren gab es auch eine Bewegung, den für die Entwicklung von Software notwendigen Aufwand zu reduzieren. Dies führte in der Entwicklung zu einer Anzahl von kleineren Prozessvarianten (oft als agile computing oder extreme programming bekannt), die auf sehr kleine Ingenieurteams zugeschnitten waren.

3.2.1.1. Der Wasserfall-Prozess

In diesem Prozess wird jeder Prozessschritt - Erfassen der Anforderungen, Analyse, Design und Build (Code und Test) abgeschlossen, bevor der nächste beginnt. Dies ist in Abbildung 3.1, „ Der Wasserfall-Prozess illustriert.

Abbildung 3.1. Der Wasserfall-Prozess

Der Wasserfall-Prozess

Dies ist ein sehr zufriedenstellender Prozess, in dem Anforderungen gut entworfen und keine Änderungen erwartet werden - zum Beispiel die Automatisierung eines bewährten, manuellen Systems.

Der Schwachpunkt dieses Ansatzes zeigt sich bei weniger gut definierten Problemen. Offene Punkte in den Anforderungen bleiben bis zur Phase Analyse und Design, oder auch bis zur Codephase ungeklärt. Dies erfordert dann ein Zurückgehen, um diese Arbeit nachzuholen.

Der schlechteste Aspekt davon ist, dass ausführbarer Code erst zum Ende des Projektes verfügbar wird. Sehr häufig ist es so, dass erst zu diesem Zeitpunkt Probleme mit den ursprünglichen Anforderungen (zum Beispiel mit der Anwenderschnittstelle) in Erscheinung treten.

Dies ist besonders schlimm, weil jeder folgende Schritt mehr Aufwand als der vorhergehende erfordert, so dass die Kosten spät entdeckter Probleme extrem teuer sind. Dies wird durch die Pyramide in Abbildung 3.2, „ Zu erwartender Aufwand je Schritt des Wasserfallmodelles dargestellt.

Abbildung 3.2. Zu erwartender Aufwand je Schritt des Wasserfallmodelles

Zu erwartender Aufwand je Schritt des Wasserfallmodelles

Der Wasserfallprozess ist wahrscheinlich der dominante Designprozess. Durch seine Beschränkungen wird er jedoch mehr und mehr durch iterative Prozesse ersetzt. Insbesondere bei Projekten, bei denen die Anforderungen schlecht definiert sind.

3.2.1.2. Iterative Entwicklungsprozesse

In den letzten Jahren wurde ein neuer Ansatz verwendet, dessen Ziel es war, einen kleinen Teil des Codes fertigzustellen und schnellstmöglichst auszuführen, um Probleme im Entwicklungszyklus sehr schnell aufzudecken.

Diese Prozesse verwenden eine Reihe von „Mini-Wasserfällen “, definieren einige Anforderungen (die wichtigsten zuerst, bringen diese durch den Analyse- und Design-, sowie den Buildprozess, um eine frühe Version des Produktes mit eingeschränkter Funktionalität zu erhalten. Die Rückmeldungen können dann dazu verwendet werden, die Anforderungen zu überarbeiten, punktuelle Probleme zu identifizieren usw. bevor noch mehr Arbeit investiert wird.

Dieser Prozess wird dann für alle weiteren Anforderungen wiederholt, um ein Produkt mit wachsender Funktionalität zu konstruieren. Erneutes Feedback kann wieder in die Anforderungen einfliessen.

Dieser Prozess wird wiederholt, bis alle Anforderungen implementiert wurden und das Produkt fertig ist. Es ist diese Iteration, die diesem Prozess seinen Namen gab. Abbildung 3.3, „ Zu erwartender Aufwand je Schritt des iterativen Prozesses zeigt, wie dieser Prozess mit der Pyramidenstruktur des Wasserfallprozesses verglichen werden kann.

Abbildung 3.3. Zu erwartender Aufwand je Schritt des iterativen Prozesses

Zu erwartender Aufwand je Schritt des iterativen Prozesses

Das Wachsen der Popularität iterativer Prozesse ist mit dem Wachsen der OOA&D eng verknüpft. Es ist die saubere Kapselung von Objekten, die es erlaubt, einen Teil des Systems mit klar definierten Leerroutinen für den verbleibenden Code zu bauen.

3.2.1.2.1. Der Rational Unified Process

Der wahrscheinlich bekannteste, iterative Prozess ist der Rational Unified Process (RUP) von Rational Software ( www.rational.com).

Dieser Prozess berücksichtigt, dass unsere Pyramidensicht der Wasserfallebenen nicht realistisch ist. In der Praxis neigen frühe Iterationen dazu, zu gross zu werden (sie müssen zu Beginn eine beträchtliche Menge definieren), während spätere Iterationen sehr viel Aufwand in der Design- und Buildphase benötigen.

RUP erkannte, dass Iterationen entsprechend Ihrer Lage im Gesamtprojekt in Phasen aufgeteilt werden können. Jede Phase kann eine oder mehrere Iterationen umfassen.

  • In der Anfangsphase neigen Iterationen dazu, mit Blick auf die Gesamtanforderung/ Analyse zu gross zu werden, während jede Build-Aktivität bezüglich der Emulation des Desgins durch das CASE-Tool eingeschränkt sein kann.

  • In der Ausarbeitungsphase werden die Iterationen dazu benutzt, die Spezifikation der Anforderungen zu vervollständigen. Ihr Schwerpunkt liegt auf Analyse und Design und dem wahrscheinlich ersten real erzeugten Code.

  • In der Konstruktionsphase sind die Anforderungen und Analyse mehr oder weniger vollständig, der Aufwand liegt häufig im Design und in der Buildphase.

  • In der abschliessenden Deploymentphase finden Iterationen weitestgehend in den Buildaktivitäten und teilweise beim Test der Software statt.

[Anmerkung]Anmerkung

Es sollte klar sein, dass Testen ein integraler Bestandteil aller Phasen ist. Gerade in den frühen Phasen sollten die Anforderungen und das Design getestet werden. Und dies wird durch ein gutes CASE-Tool unterstützt.

Wir wollen in diesem Handbuch einen iterativen Prozess verwenden, der lose auf dem RUP basiert.

3.2.1.2.2. Iterationsgröße

Eine gute Regel ist es, dass eine Iteration in typischen kommerziellen Projekten zwischen sechs und zehn Wochen umfassen sollte. Bei längeren Zeiträumen haben Sie sich wahrscheinlich mehr Anforderungen vorgenommen, als Sie in einem Schritt verarbeiten können. Sie verlieren auch den Fokus auf den nächsten vollständigen Iterationsschritt. Bei kürzeren Zeiten haben Sie wahrscheinlich nicht genügend Anforderungen um einen spürbaren Fortschritt zu erzielen. In diesem Fall wird der mit einer Iteration verbundene zusätzliche Overhead zum Problem.

Die Gesamtanzahl von Iterationen hängt von der Grösse des Projektes ab. Nehmen Sie die voraussichtliche Gesamtdauer (geschätzte Ausarbeitungzeit für das gesamte Subjekt) und unterteilen diese in 8 Wochen grosse Abschnitte. Die Erfahrung sagt, dass Iterationen im Verhältnis 1:2:3:3 bezüglich der RUP-Phasen „Anfangsphase“, „ Ausarbeitungsphase“, „Konstruktionsphase“ und „Deploymentphase“ aufgeteilt werden sollten. Ein Projekt, dass grosse Unsicherheiten in seiner Spezifikation aufweist (einige Forschungsprojekte zum Beispiel) wird viel grössere frühe Phasen aufweisen.

Wenn Sie ein Produkt auf Basis eines Vertrages für einen Kunden erstellen, ist der Endpunkt wohl definiert. Wenn Sie jedoch ein neues Produkt für den Markt entwickeln, kann die Strategie verwendet werden, das Datum der Produktveröffentlichung zu nehmen und den Zeitpunkt für das Ende des Engieering zu bestimmen (einige Zeit vorher). Dieser Zeitraum wird dann in Iterationen unterteilt. In dieser Zeit wird so viel von dem Produkt entwickelt wie möglich. Der iterative Prozess ist sehr effektiv, wenn der Zeitpunkt der Markteinführung wichtiger ist, als die exakte Funktionalität.

3.2.1.3. Rekursive Entwicklungsprozesse

Sehr wenige Softwaresysteme sind als monolitische Werkzeuge geplant. Sie werden in Subsysteme, Module usw. unterteilt.

Die Softwareprozesse sind die gleichen. Mit frühen Abschnitten in denen der Prozess eine Top-Level-Struktur definiert und die wiederholte Anwendung des Prozesses auf Teile der Struktur, um jedes grössere Detail zu definieren.

Zum Beispiel könnte das grundlegende Design eines Telefonsystemes Objekte identifizieren um

  1. Telefonleitungen zu belegen,

  2. Anrufe zu verarbeiten,

  3. das System zu verwalten und,

  4. den Kunden abzurechnen.

Der Softwareprozess kann dann auf jedes dieser vier Komponenten erneut angewendet werden, um deren Design zu identifizieren.

OOA&D mit seinen klaren Objektgrenzen unterstützt diesen Ansatz natürlich. Eine OOA&D mit rekursiver Entwicklung wird manchmal als OOA&D/RD abgekürzt.

Die rekursive Entwicklung kann parallel zu Wasserfall- oder iterativen Prozessen angewendet werden. Sie ist keine Alternative zu diesen Prozessen.

3.2.2. Der Entwicklungsprozess für dieses Übungshandbuch

In dieser Übungsanleitung wollen wir einen reduzierten, iterativen Prozess mit rekursiver Entwicklung verwenden, der mit dem RUP lose gekoppelt ist. Die Fallstudie bringt uns durch die erste Iteration, am Ende des Abschnittes Übungsanleitung werden wir sehen, wie das Projekt vollständig entwickelt wird.

Innerhalb der ersten Iteration werden wir jede Aktivität wie das Erfassen der Anforderungen, die Analyse, das Design und den Build angehen. Nicht alle Teile des Prozesses basieren auf UML oder ArgoUML. Wir werden sehen, welches andere Material hierfür benötigt wird.

Innerhalb dieses Prozesses werden wir die Möglichkeit haben, die verschiedenen UML-Diagramme in ihrer Anwendung zu sehen. Der vollständige Umfang der UML-Diagramme und wie sie angewendet werden ist im Referenzhandbuch beschrieben (siehe Abschnitt 16.8, „ Diagramm).

3.2.2.1. Erfassen der Anforderungen

Um unsere Anforderungen zu erfassen, verwenden wir das UML-Konzept der Anwendungsfälle. Beginnend mit einem Visions-Dokument werden wir sehen, wie Anwendungsfälle entwickelt werden können, um alle Aspekte des Systemverhaltens im Problembereich zu beschreiben.

3.2.2.2. Analyse

Während der Analyse werden wir in das UML-Konzept der Klassen einführen. Dieses Konzept erlaubt es uns, eine Top-Level-Sicht von Objekten zu erzeugen, die die Lösung darstellen - manchmal auch als Konzept-Diagramm bekannt.

Wir werden in das UML Sequenzdiagramm und das Zustandsdiagramm einführen, um die Anforderungen für das Gesamtverhalten des Systems zu erfassen.

Abschliessend nehmen wir die Anwendungsfälle aus dem Abschnitt Anforderungsaufnahme und wandeln diese in die Sprache des Lösungsbereiches um. Dies wird die UML-Ideen von Stereotypen und Realisierung illustrieren.

3.2.2.3. Design

Wir verwenden das UML-Paketdiagramm, um die Komponenten des Projektes zu organisieren. Wir besuchen dann erneut das Klassendiagramm, das Sequenzdiagramm und das Zustandsdiagramm, um zu zeigen, wie diese rekursiv verwendet werden können, um die vollständige Lösung zu designen.

Während dieses Teils des Prozesses müssen wir unsere Systemarchitektur entwickeln, um zu definieren, wie alle Komponenten zusammenpassen und miteinander zusammenarbeiten.

Obwohl es kein zwingend erforderlicher Teil unseres Prozesses ist, werden wir uns ansehen, wie das UML- Kollaborationsdiagramm als Alternative oder Ergänzung zum Sequenzdiagramm verwendet werden kann. Desweiteren werden wir uns das UML- Aktivitätsdiagramm als Alternative oder Ergänzung zum Zustandsdiagramm ansehen.

Zum Schluß wollen wir das UML-Deploymentdiagramm verwenden, um zu spezifizieren, wie das System aktuell realisiert werden soll.

3.2.2.4. Build

UML ist nicht wirklich mit dem Schreiben von Code verknüpft. Jedoch wollen wir an dieser Stelle zeigen, wie ArgoUML für die Codegenerierung eingesetzt werden kann.

Wir wollen uns auch ansehen, wie das UML-Anwendungsfalldiagramm und die Anwendungsfall-Spezifikation unschätzbare Werkzeuge für ein Testprogramm sind.