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.
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.
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 Designmodell
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 Designmodell
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.
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.
|