Sie müssen entscheiden, welche Arbeitsergebnisse verwendet werden sollen und wie. Außerdem müssen Sie jedes
Arbeitsergebnis so anpassen, dass es den Anforderungen des Projekts entspricht.
Die folgende Tabelle enthält eine Liste der empfohlenen und optionalen (die nur in bestimmten Fällen verwendet werden
können) Arbeitsergebnisse aus der Disziplin Analyse & Design. Weitere Hinweise zur Anpassung finden Sie im
Abschnitt "Anpassen" auf der Seite mit der Beschreibung des jeweiligen Arbeitsergebnisses.
Arbeitsergebnis
|
Zweck
|
Anpassen (optional, empfohlen)
|
Analysemodell (Analyseklasse)
|
Ein Analysemodell ist hilfreich, um die Anforderungen besser zu verstehen, bevor Designentscheidungen
getroffen werden. In komplexen Systemen kann das Analysemodell als konzeptionelle Übersicht über das
System gepflegt.
|
Optional
In vielen Projekten wird anstelle des Analysemodells ein erstes Designmodell verwendet.
In Projekten, die ein Analysemodell erstellen, ist es in der Regel ein temporäres Artefakt, aus dem
sich das Designmodell entwickelt.
|
Navigationsübersicht, Benutzerschnittstellenprototyp
|
Projekte mit einer großen und komplexen Benutzerschnittstelle sollten sich für ein
Benutzerschnittstellendesign entscheiden.
|
Optional
In kleineren Entwicklungsprojekten kann ein eher formloses Benutzerschnittstellendesign ausreichend
sein.
|
Designmodell
|
Für die meisten Systeme, selbst kleinere sollte vor der Implementierung ein Design erstellt werden, um
kostenintensive Nacharbeiten aufgrund von Designfehlern zu vermeiden. Mit visuellen Modellen lässt sich
das Design einfach kommunizieren. Tools für Entwicklung (Forward-Engineering) und Rückentwicklung
(Reverse-Engineering) können die Konsistenz mit dem Implementierungsmodell sicherstellen und Aufwand
sparen.
|
Empfohlen für die meisten Projekte.
In kleineren Projekten ist die Verwendung automatisierter Tools kein kritischer Faktor, können aber
langfristig die Produktivität verbessern.
|
Designklasse; Designpaket
|
Klassen und Pakete sind ein grundlegender Baustein jedes objektorientierten Designs. Objektorientiertes
Design ist der Standarddesignansatz, der in den meisten Projekten verwendet wird.
|
Empfohlen für die meisten Projekte.
Ein wichtigste Anpassungsaspekt ist die Entscheidung, welche Stereotypen verwendet werden (diese
Entscheidung kann in den Designrichtlinien erfasst werden).
|
Anwendungsfallrealisierung
|
Die Brücke von Anwendungsfällen zum Design.
|
Empfohlen für die meisten Projekte.
|
Schnittstelle
|
Schnittstellen werden normalerweise verwendet, um Verhalten unabhängig von größeren Komponenten zu
definieren, die das Verhalten realisieren.
|
Empfohlen für die meisten Projekte.
Komponentenbasiertes Design wird langsam zu einem Standarddesignansatz.
|
Designsubsystem
|
Designsubsysteme werden verwendet, um Verhalten in einer Komponente zu kapseln, die Schnittstellen
bereitstellt. In ihnen werden die Interaktionen von Klassen und/oder anderen Subsystemen gekapselt.
|
Empfohlen für die meisten Projekte.
Subsysteme sind häufig hilfreich, um eine höhere Abstraktionsstufe zu erreichen. Sie machen Systeme
verständlicher.
|
Ereignis
|
Kann für Systeme hilfreich sein, die auf viele externe Ereignisse reagieren.
|
Empfohlen für Echtzeitsysteme.
|
Protokoll
|
Erforderlich für Echtzeitsysteme.
|
Empfohlen für Echtzeitsysteme.
|
Signal
|
Kann hilfreich für Systeme sein, die Parallelität voraussetzen und ereignisgesteuert sind.
Erforderlich für Echtzeitsysteme.
|
Kann hilfreich für Systeme sein, die Parallelität voraussetzen und ereignisgesteuert sind.
Empfohlen für Echtzeitsysteme.
|
Kapsel
|
Ist eigentlich für Echtzeitsysteme bestimmt, kann aber hilfreich für die Modellierung und das Design
jedes Systems sein, das ein hohes Maß an Parallelität erfordert.
|
Empfohlen für Echtzeitsysteme.
|
Datenmodell
|
Wird verwendet, um die logische und möglicherweise physische Struktur der persistenten Informationen zu
beschreiben.
|
Empfohlen für Projekte, die eine Datenbank verwenden.
|
Deployment-Modell
|
Zeigt die Konfiguration der Verarbeitungsknoten zur Laufzeit, die Kommunikationsverbindungen zwischen
diesen Knoten sowie die Komponenteninstanzen und Objekte auf diesen Knoten.
|
Optional.
Viele Systeme haben mehrere Verarbeitungsknoten und müssen deshalb das Deployment-Modell
berücksichtigen. Es kann jedoch als Abschnitt des Softwarearchitekturdokuments erfasst werden und
muss nicht als separates Artefakt geführt werden.
|
Architekturmachbarkeitsstudie
|
Wird verwendet, um festzustellen, ob eine Lösung vorhanden ist, die die architektonisch relevanten
Anforderungen erfüllt.
|
Empfohlen für die meisten Projekte.
Viele Projekte verwenden eine Architekturmachbarkeitsstudie, um die Realisierbarkeit der
Anforderungen zu prüfen. Eine Architekturmachbarkeitsstudie kann unter anderem folgende Formen
annehmen:
-
Liste bekannter Technologien, die für die Lösung geeignet zu sein scheinen
-
Skizze eines konzeptionellen Modells einer Lösung
-
Simulation einer Lösung
-
Ausführbarer Prototyp
|
Referenzarchitektur
|
Referenzarchitekturen beschleunigen die Entwicklung und Mindern Risiken durch Wiederverwendung
bewährter Lösungen.
|
Empfohlen für die meisten Projekte.
Wenn eine geeignete Referenzarchitektur vorhanden ist, kann sie die Entwicklung drastisch
beschleunigen und Risiken minimieren.
|
Softwarearchitekturdokument (SAD)
|
Das Softwarearchitekturdokument wird als umfassende Übersicht über die Architektur des Systems
verwendet. Diese Übersicht ist hilfreich, um das System zu verstehen und die wichtigsten Entscheidungen
in Bezug auf die Architektur zu erfassen.
|
Empfohlen für die meisten Projekte.
Eine Übersicht über die Softwarearchitektur auf hoher Ebene ist hilfreich, selbst für die kleinsten
Systeme. Komplexe Systeme erfordern in der Regel einen höheren Detaillierungsgrad und mehr Sichten
als kleinere Systeme.
|
Benutzerschnittstellenprototyp
|
Wird verwendet, um Funktionalität und Benutzerfreundlichkeit vor dem Beginn der eigentlichen
Entwicklung offen zu legen und zu testen. Es ist ein wirksames Mittel zur Validierung des Designs,
bevor zu viel Zeit verschwendet wird.
|
Empfohlen für die meisten Projekte.
|
Welche Berichte verwendet werden, richtet sich nach den Berichtstools, die dem Projekt zur Verfügung stehen. Wenn Tools
für Berichterstellung verfügbar sind, wird empfohlen, Berichte für modellorientierte Arbeitsergebnisse wie
Designklassen und Anwendungsfallrealisierungen zu generieren. Vorhandene Berichte in Ihrer RUP-Konfiguration werden auf
den Beschreibungsseiten für Arbeitsergebnisse bereitgestellt und unter dem jeweiligen Arbeitsergebnis im
Baumstrukturbrowser gruppiert.
Legen Sie die Prüfebene für jedes zu verwendende Arbeitsergebnis fest. Legen Sie insbesondere fest, wie und in welchem
Ausmaß die Ergebnisse von Analyse & Design geprüft und abgenommen werden.
Die Durchführung von Prüfungen während Analyse & Design hat die folgenden Vorteile:
-
Es werden Probleme erkannt, die bei Tests unmöglich oder nur sehr schwer feststellbar sind. Dies betrifft
beispielsweise Probleme mit dem Stil und mit dem Layout.
-
Sie ist ein Mittel, um einen einheitlichen Modellierungsstil durchzusetzen, und gibt den Mitarbeitern die
Möglichkeit, voneinander zu lernen.
-
Es werden Mängel erkannt, die ansonsten erst sehr viel später im Projekt während der Tests festgestellt werden.
Die Durchführung von Prüfungen während Analyse & Design hat die folgenden Nachteile:
-
Sie nimmt Zeit und Ressourcen in Anspruch.
-
Wenn sie nicht sorgfältig verwaltet wird, kann sich leicht zu falschen Zwecken eingesetzt werden
Die Faktoren, für Prüfungen während Analyse & Design geändert werden können, sind Prüftechniken, Ressourcen und
Umfang. Sie können beispielsweise Folgendes für Ihr Projekt entscheiden:
-
Lokale Änderungen an einem Subsystem werden nur von einem Partner geprüft, der die Ergebnisse auf Papier übergibt.
-
Einige Teile des Designs werden gar nicht geprüft. Die Überprüfung wird auf einige Klassen jedes Mitarbeiters des
Projekts beschränkt, und es wird darauf vertraut, dass damit sichergestellt ist, dass der Stil der übrigen von
ähnlicher Qualität ist.
-
Das Softwarearchitekturdokument wird vom Kunden in einer separaten Besprechung geprüft.
-
Es werden formale Überprüfungsbesprechungen bezüglich Änderungen in wichtigen Schnittstellen abgehalten, d. h.
Schnittstellen, die sich auf die Arbeit mehrerer Projektmitarbeiter auswirken.
Weitere Informationen finden Sie in der Anleitung:
Prüfebenen.
Die Gestaltung des Designs richtet sich danach, ob Sie aus dem Designmodell Code generieren oder nicht. Wenn Sie Code
generieren, muss das Design sehr detailliert sein. Wenn Sie aus dem Design keinen Code generieren, ist es nicht
erforderlich, sehr detailliert zu sein. Ganz im Gegenteil, wenn Sie zu detailliert sind, müssen die Details im Design
manuell mit dem Code synchronisiert werden.
|