Darstellungsoptionen |
UML-Darstellung: Modell mit dem Stereotyp <<Analysemodell>> (Analysis model).
Das Analysemodell kann die folgenden Eigenschaften haben:
-
Einführung: Eine Textbeschreibung, die als Kurzeinleitung in das Modell dient.
-
Analysepakete: Die Pakete im Modell, die eine Hierarchie darstellen.
-
Klassen: Die Klassen im Modell, deren Eigner die Pakete sind.
-
Beziehungen: Die Beziehungen im Modell, deren Eigner die Pakete sind.
-
Anwendungsfallrealisierungen: Die Anwendungsfallrealisierungen im Modell, deren Eigner die Pakete
sind.
-
Diagramme: Die Diagramme im Modell, deren Eigner die Pakete sind.
Normalerweise entwickeln sich die "Analyseklassen" direkt zu Elementen im Designmodell. Einige werden zu Designklassen
und andere zu Designsubsystemen. Mit der Analyse wird das Ziel verfolgt, eine vorläufige Zuordnung des erforderlichen
Verhaltens zu Modellierungselementen im System zu ermitteln. Beim Design wird diese vorläufige (und in gewisser Weise
idealisierte) Zuordnung in eine Gruppe von Modellelementen umgesetzt, die implementiert werden können. Beim Übergang
von der Analyse zum Design findet demzufolge eine Präzisierung (Detail und Genauigkeit) statt. Deshalb sind die
"Analyseklassen" häufig relativ flexibel, veränderlich und entwickeln sich erheblich, bevor sie sich in
Designaktivitäten manifestieren.
Beachten Sie die folgenden Punkte, wenn Sie entscheiden, ob ein separates Analysemodell erforderlich ist:
-
Ein separates Analysemodell kann hilfreich sein, wenn das System für mehrere Zielumgebungen mit separaten
Designarchitekturen entworfen werden muss. Das Analysemodell ist eine Abstraktion bzw. eine Generalisierung des
Designmodells. Im Analysemodell fehlt ein Großteil der Designdetails, um einen Überblick über die Funktionalität
des Systems zu liefern.
-
Das Design ist komplex, so dass ein vereinfachtes, abstraktes "Design" erforderlich ist, um das Design neuen
Teammitgliedern vorzustellen. Eine klar strukturierte Architektur kann demselben Zweck dienen.
-
Die zusätzliche Arbeit, die erbracht werden muss, um sicherzustellen, dass die Analyse- & Designmodelle
konsistent bleiben, muss gegen die Vorteile abgewogen werden, die eine Sicht des Systems bietet, die ausschließlich
die wichtigsten Details der Funktionsweise des Systems darstellt. Analysemodell und Designmodell im Einklang zu
halten, kann erhebliche Kosten verursachen. Sie können sich auch für den weniger ambitionierten Ansatz entscheiden,
im Analysemodell nur die wichtigsten Domänenklassen und im Design die Schlüsselabstraktionen zu verwalten. Mit
zunehmender Komplexität des Analysemodells steigen auch die Kosten für dessen Verwaltung.
-
Wenn das Analysemodell nicht mehr verwaltet wird, nimmt sein Nutzen rapide ab und ist ab einem gewissen Punkt nicht
mehr hilfreich, weil es das aktuelle Design des Systems nicht mehr genau widerspiegelt. Wenn das Analysemodell
seinem Zweck gedient hat, kann es durchaus Sinn machen, die Verwaltung einzustellen. Diese Entscheidung sollte
jedoch mit Sorgfalt getroffen werden.
In einigen Unternehmen, in denen ein System Jahrzehnte im Einsatz bleibt oder in denen es viele Varianten des Systems
gibt, hat sich ein separates Analysemodell vielfach als hilfreich erwiesen.
|