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— entfernt 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 wurden 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 Originalanforderungen (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 minimalen Teil Code fertigzustellen und schnellstm??glichst ausf??hren zu k??nnen, 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 Wiederholungen 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 Vorschritt 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 per Vertrag f??r einen Kunden erstellen, ist der Endpunkt wohl definiert. Jedoch, wenn Sie ein neues Produkt f??r den Markt entwickeln, kann es eine Strategie sein, die 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. Anrufe zu verarbeiten,

  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 nat??rlich diesen Ansatz. Eine OOA&D in einer rekursiven 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.

3.2.2. Ein Entwicklungsprozess f??r dieses ??bungshandbuch

In diesem ??bungshandbuch wollen wir einen reduzierten iterativen Prozess mit rekursiver Entwicklung, lose gekoppelt mit RUP verwenden. Die Fallstudie bringt uns durch die erste Iteration, obwohl wir am Ende des ??bungshandbuch-Abschnittes sehen werden, 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 ihre Anwendung zu sehen. Der vollst??ndige Umfang der UML-Diagramme und wie sie unterst??tzt werden ist im Referenzhandbuch beschrieben (siehe Abschnitt 16.8, „Diagram“).

3.2.2.1. Erfassen der Anforderungen

Unser "Erfassen der Anforderungen" wird das UML-Konzept von Anwendungsf??llen verwenden. 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 erlaubt es uns, eine Top-Level- Sicht von Objekten zu erzeugen, welche die L??sung darstellt— manchmal als Konzept-Diagramm bekannt.

Wir werden 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 „Erfassen der Anforderungen“ 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 Prozessteils m??ssen wir unsere Systemarchitektur entwickeln, um zu definieren, wie alle Komponenten zusammenpassen und miteinander zusammenarbeiten.

Obgleich es nicht zwingend Teil unseres Prozesses ist, werden wir uns ansehen, wie das UML Kollaborationsdiagramm als Alternative oder Erg??nzung zum Sequenzdiagramm verwendet werden kann. ??hnlich dem vorhergehenden, werden wir uns das UML Aktivit??tsdiagramm als Alternative oder Erg??nzung zum Zustandsdiagramm ansehen.

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