Konzept: Zuordnung von Design zu Code
Diese Richtlinie beschreibt verschiedene Optionen für den Übergang vom Design zur Implementierung und erläutert die Vor- und Nachteile dieser Ansätze.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Einführung

Das Design muss genug vom System definieren, dass es unzweideutig implementiert werden kann. Was genug bedeutet, richtet sich nach dem jeweiligen Projekt und dem jeweiligen Unternehmen.

In einigen Fällen gleicht das Design einer Skizze, die nur so weit ausgearbeitet ist, dass gewährleistet ist, dass Implementierer seine Arbeit fortsetzen kann (Ansatz "skizzieren und codieren"). Der Grad der Spezifikation variiert mit dem Know-how des Implementierers, der Komplexität des Designs und dem Risiko, dass das Design missgestaltet ist.

In anderen Fällen ist das Design so weit ausgearbeitet, dass es automatisch in Code umgesetzt werden kann. Hierfür werden in der Regel Erweiterungen zur Standard-UML verwendet, um sprach- und/oder umgebungsspezifische Semantik darzustellen.

Das Design kann auch hierarchisch sein. Beispiele:

  • Ein Designmodell auf hoher Ebene, das eine Übersicht des Gesamtsystems skizziert.
  • Ein Subsystemspezifikationsmodell, das die erforderlichen Schnittstellen und das Verhalten wichtiger Subsysteme im System präzise definiert.
  • Ein detailliertes Designmodell für die Interna des Subsystems.

Der Entwicklungsfall muss definieren, wie das Designmodell im spezifischen Prozess des Projekts realisiert wird und wie/ob das Modell mit anderen Modellen und der Implementierung in Relation steht. Details müssen in den projektspezifischen Richtlinien erfasst werden.

Die folgenden Abschnitte beschreiben verschiedene Optionen, wie Design und Implementierung einander zugeordnet werden können, und die Vor- und Nachteile dieser Ansätze.

Skizzieren und codieren

Ein gebräuchlicher Ansatz für das Design ist, das Design relativ abstrakt zu skizzieren und anschließend direkt zur Codierung überzugehen. Die Pflege des Designmodells wird manuell durchgeführt.

Bei diesem Ansatz ist eine Designklasse eine Abstraktion mehrerer Klassen auf Codeebene. Es wird empfohlen, jede Designklasse einer "führenden" Klasse zuzuordnen, die wiederum mehrere Unterstützungsklassen haben kann, um ihr Verhalten zu erbringen. Mit diesen Unterstützungsklassen können Sie ein komplexes Attribut implementieren oder eine Datenstruktur erstellen, die Sie für die Implementierung einer Operation benötigen. Im Design werden die Unterstützungsklassen nicht modelliert, sondern nur die Schlüsselattribute, Beziehungen und Operationen, die in der führenden Klasse definiert sind. Der Zweck eines solchen Modells ist die Abstraktion von Details, die vom Implementierer vervollständigt werden können.

Dieser Ansatz wird auf andere Designmodellelemente erweitert. Sie können Designschnittstellen verwenden, die abstrakter sind als Schnittstellen auf Codeebene usw.

Round-Trip-Engineering

In Round-Trip-Engineering-Umgebungen wird das Designmodell in einem solchen Detaillierungsgrad ausgearbeitet, dass es zu einer visuellen Darstellung des Codes wird. Der Code und die visuelle Darstellung werden synchronisiert (mit Toolunterstützung).

Im Folgenden werden einige Optionen für die Darstellung eines Designmodells in einem Round-Trip-Engineering-Kontext vorgestellt.

Designmodell auf hoher Ebene und detailliertes DesignmodellSeitenanfang

Bei diesem Ansatz werden zwei Ebenen von Designmodell verwaltet. Jedes Designelement auf hoher Ebene ist eine Abstraktion eines oder mehrerer detaillierter Elemente im Round-Trip-Modell. Beispielsweise kann eine Designklasse wie beim zuvor beschriebenen Ansatz "Skizzieren und codieren" einer "führenden" Klasse und mehreren Unterstützungsklassen zugeordnet werden. Die Rückverfolgbarkeit von den Designmodellelementen der hohen Ebene zu den Elementen des Round-Trip-Modells kann helfen, die Konsistenz der beiden Modelle zu gewährleisten.

Obwohl auf diese Weise weniger wichtige Details abstrahiert werden können, muss dieser Vorteil gegen den Aufwand abgewogen werden, der erforderlich ist, um die Konsistenz der beiden Modelle zu wahren.

Einzelnes DesignmodellSeitenanfang

Bei diesem Ansatz wird nur ein Designmodell verwendet. Erste Skizzen von Designelementen werden so weit ausgearbeitet, dass sie mit dem Code synchronisiert werden können. Diagramme wie die, die zum Beschreiben von Anwendungsfallrealisierungen verwendet werden, verweisen zunächst auf skizzierte Designklassen, aber letztendlich dann auf sprachspezifische Klassen. Beschreibungen des Designs auf hoher Ebene werden bei Bedarf verwaltet, z. B.:

  • Diagramme der logischen Struktur des Systems
  • Subsystem-/Komponentenspezifikationen
  • Designmuster/-mechanismen

Ein solches Modell ist einfacher mit der Implementierung konsistent zu halten.

Spezifikations- und Realisierungsmodelle

Ein verwandter Ansatz ist, das Design mit Hilfe von Spezifikationen der wichtigeren Subsysteme zu definieren, die so detailliert sind, dass Clientimplementierungen auf deren Basis kompiliert werden können.

Das detaillierte Design der Subsystemrealisierung kann gesondert von diesem Spezifikationsmodell modelliert und verwaltet werden.

Richtlinien für Subsystemspezifikationen und -realisierungen und deren Verwendung finden Sie in Richtlinie für Arbeitsergebnis: Designsubsystem.