Richtlinie: Designmodell
Diese Richtlinie beschreibt, wie Sie das Designmodell vom Analysemodell ableiten.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Designelemente aus Analyseklassen ableiten Seitenanfang

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.

Zuordnung zum Analysemodell Seitenanfang

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: 

Abbildung zur Trace-Abhängigkeit

Anmerkung: Rückverfolgbarkeitsverbindungen werden von Designmodellelementen zu den Analysemodellelementen gezeichnet, so dass das Designmodell vom Analysemodell abhängig ist und nicht umgekehrt.

Zuordnung zum Implementierungsmodell

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.

Merkmale eines tauglichen Designmodells

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.