Analyseklassen stellen Rollen dar, die von Instanzen von
Designelementen eingenommen werden. Diese Rollen können von einem oder mehreren Designelementen ausgesfüllt werden.
Außerdem kann ein Designelement mehrere Rollen ausfüllen. Im Folgenden werden die Möglichkeiten beschrieben, wie die
Analyseklassen ausgefüllt werden können:
-
Eine Analyseklasse kann eine Designklasse im Designmodell werden.
-
Eine Analyseklasse kann ein Teil einer Designklasse im Designmodell werden.
-
Eine Analyseklasse kann eine zusammengesetzte Designklasse im Designmodell werden (d. h. die Teile in diesem
Aggregat werden möglicherweise nicht explizit als Analyseklassen modelliert).
-
Eine Analyseklasse kann eine Gruppe von Designklassen werden, die die Eigenschaften derselben Klasse im
Designmodell erben.
-
Eine Analyseklasse kann eine Gruppe funktional zusammengehöriger Designklassen im Designmodell werden.
-
Eine Analyseklasse kann ein Designsubsystem im Designmodell werden.
-
Eine Analyseklasse kann ein Teil eines Designsubsystems werden, z. B. bestehend aus einer oder mehreren
Schnittstellen und ihren Implementierungen.
-
Eine Analyseklasse kann eine Beziehung im Designmodell werden.
-
Eine Beziehung zwischen Analyseklassen kann eine Designklasse im Designmodell werden.
-
Analyseklassen behandeln primär funktionale Anforderungen und modellieren Objekte aus der "Problemdomäne".
Designklassen behandeln nicht funktionale Anforderungen und modellieren Objekte aus der "Lösungsdomäne".
-
Analyseklassen können verwendet werden, um "die Objekte darzustellen, die das System unterstützen soll", ohne eine
Entscheidung darüber zu treffen, wie viele von ihnen mit Hardware und wie viele mit Software unterstützt werden
sollen. Deshalb kann ein Teil einer Analyseklasse durch Hardware realisiert, aber im Designmodell gar nicht
modelliert werden.
Die genannten Möglichkeiten können in beliebiger Weise miteinander kombiniert werden.
Wenn ein separates Analysemodell verwaltet wird, müssen Sie die Rückverfolgbarkeit vom identifizierten Designelement
zur entsprechenden Analyseklasse verwalten. Weitere Informationen hierzu finden Sie in Zuordnung zum Analysemodell.
Dieser Abschnitt gilt nur, wenn Sie ein separates Analysemodell verwalten.
Während des Designs werden die Designelemente identifiziert, die eine engere Ausrichtung an der Architektur und den
ausgewählten Technologien unterstützen. Jede Analyseklasse im Analysemodell muss mindestens einer Designklasse im
Designmodell zugeordnet werden.
Zur Modellierung dieser Rückverfolgbarkeit muss, wie in der folgenden Abbildung gezeigt, eine Abhängigkeit mit dem
Stereotyp <<Trace>> vom Designelement zu den zugehörigen Analyseklassen gezeichnet werden:
Anmerkung: Rückverfolgbarkeitsverbindungen werden von Designmodellelementen zu den Analysemodellelementen
gezeichnet, so dass das Designmodell vom Analysemodell abhängig ist und nicht umgekehrt.
Sie müssen vor Beginn des Designs entscheiden, wie Klassen im Designmodell mit den Implementierungsklassen in
Verbindung gebracht werden. Beschreiben Sie dies in den für das Projekt spezifischen Designrichtlinien.
Das Designmodell kann sich mehr oder weniger eng an das Implementierungsmodell anlehnen. Dies richtet sich danach, wie
Sie die Klassen, Pakete und Subsysteme den Implementierungsklassen, -dateien, -paketen und -subsystemen im
Implementierungsmodell zuordnen. Während der Implementierung müssen Sie häufig kleinere taktische Probleme mit der
Implementierungsumgebung bewältigen, die sich jedoch nicht auf das Designmodell auswirken sollten. Beispielsweise
können während der Implementierung Klassen und Subsysteme für die Unterstützung paralleler Entwicklung oder für die
Anpassung der Importabhängigkeiten hinzugefügt werden. Weitere Informationen finden Sie in Implementierungsmodell strukturieren und Zuordnung von Design zu Code.
Die Zuordnung vom Designmodell zum Implementierungsmodell muss konsistent sein. Projektspezifische Richtlinien definieren diese Zuordnung. Wenden Sie
im Designmodell konsistent dieselbe Abstraktionsebene an.
Ein taugliches
Designmodell hat die folgenden Merkmale:
-
Es erfüllt die Systemanforderungen.
-
Es ist Änderungen in der Implementierungsumgebung gegenüber tolerant.
-
Es ist in Bezug auf weitere mögliche Objektmodelle und auf die Systemimplementierung einfach zu verwalten.
-
Es zeigt deutlich die Vorgehensweise bei der Implementierung auf.
-
Es enthält keine Informationen, die besser im Programmcode dokumentiert werden sollten.
-
Es lässt sich einfach an Änderungen von Anforderungen anpassen.
Informationen zu spezifischen Merkmalen finden Sie unter Designmodell.
|