Aufgabe: Subsystemdesign
Diese Aufgabe beschreibt, wie die Subsystemelemente und ihr Verhalten sowie Subsystemabhängigkeiten dokumentiert werden.
Disziplinen: Analyse und Design
Zweck
  • In den Schnittstellen des Subsystems angegebenes Verhalten mit Kollaborationen der enthaltenen Designelemente und externen Subsysteme/Schnittstellen definieren
  • Interne Struktur des Subsystems dokumentieren
  • Realisierungen zwischen den Subsystemschnittstellen und enthaltenen Klassen definieren
  • Abhängigkeiten von anderen Subsystemen bestimmen
Beziehungen
RollenPrimärer Ausführender: Zusätzliche Ausführende:
EingabenVerbindlich: Optional:
Ausgaben
Prozessverwendung
Hauptbeschreibung

 UML-1.x-Darstellung

Dieselben Hinweise für Subsystemabhängigkeiten gelten, wenn UML 1.5 verwendet wird:


Im Begleittext beschriebene Abbildung

Beispiel für Subsystemschichten mit direkten Abhängigkeiten

Im Begleittext beschriebene Abbildung

Beispiel für Subsystemschichten mit Schnittstellenabhängigkeiten

Lesen Sie auch den Artikel Unterschiede zwischen UML 1.x und UML 2.0.

Schritte
Subsystemverhalten auf Subsystemelemente verteilen
Zweck Internes Verhalten des Subsystems angeben.
Neue Designklassen oder Designsubsysteme identifizieren, die erforderlich sind, um die Anforderungen an das Verhalten des Subsystems zu erfüllen.  

Das externe Verhalten eines Subsystems wird primär von den verwendeten Schnittstellen definiert. Wenn ein Subsystem eine Schnittstelle realisiert, verpflichtet es sich damit, jede einzelne Operation, die in der Schnittstelle definiert ist, zu unterstützen. Die Operation wiederum kann von einer Operation in einem Designelement (z. B. Designklasse oder Designsubsystem) im Subsystem realisiert werden. Diese Operation setzt möglicherweise eine Kollaboration mit anderen Designelementen voraus.

Die Kollaborationen von Modellelementen innerhalb des Subsystems müssen mit Ablaufdiagrammen dokumentiert werden, die zeigen, wie das Subsystemverhalten realisiert wird. Jede Operation in einer Schnittstelle, die vom Subsystem realisiert wird, muss mindestens ein dokumentiertes Ablaufdiagramm haben. Dieses Diagramm, dessen Eigner das Subsystem ist, wird verwendet, um das interne Verhalten des Subsystems zu entwerfen.

Wenn das Verhalten des Subsystems in hohem Maße zustandsabhängig ist und eine oder mehrere Steuerungs-Threads darstellt, sind Zustandsmaschinen in der Regel hilfreicher, um das Verhalten des Subsystems zu beschreiben. Zustandsmaschinen werden in diesem Kontext häufig zusammen mit aktiven Klassen verwendet, um eine Dekomposition der Steuerungs-Threads des Subsystems (oder der Subsysteme in diesem Fall) darzustellen, und werden in Zustandsdiagrammen beschrieben (siehe Richtlinie: Zustandsdiagramm). In Echtzeitsystemen wird das Verhalten von  Kapseln auch mit Zustandsmaschinen beschrieben. Das Subsystem kann unabhängige Ausführungs-Threads enthalten, die von aktiven Klassen dargestellt werden.

In Echtzeitsystemen werden  Kapseln verwendet, um diese Threads zu kapseln.

Beispiel:

Die Kollaboration von Subsystemen, die ein gefordertes Verhalten des Systems erbringen, kann mit Ablaufdiagrammen beschrieben werden:

Im Begleittext beschriebene Abbildung

Dieses Diagramm zeigt, wie die Schnittstellen der Subsysteme für ein Szenario verwendet werden. Für das Subsystem "Netzverwaltung" sehen Sie die spezifischen Schnittstellen (ICoordinator in diesem Fall) und die Operationen, die das Subsystem unterstützen muss. Sie sehen auch, dass das Subsystem "Netzverwaltung" von den Schnittstellen IBHandler und IAHandler abhängig ist.

Wenn Sie sich das Subsystem anschauen, sehen Sie, wie die Schnittstelle ICoordinator realisiert wird:

Im Begleittext beschriebene Abbildung

Die Klasse Koordinator agiert als "Proxy" für die Schnittstelle ICoordinator, bearbeitet die Schnittstellenoperationen und koordiniert das Schnittstellenverhalten.

Dieses "interne" Ablaufdiagramm zeigt exakt, welche Klassen die Schnittstelle unterstützen, was intern passieren muss, damit die Funktionalität des Subsystems bereitgestellt werden kann, und welche Klassen Nachrichten aus dem Subsystem senden. Das Diagramm veranschaulicht das interne Design und ist wichtig für Subsysteme mit komplexen internen Designs. Es erleichtert außerdem das Verständnis des Subsystemverhaltens und kann somit hoffentlich in anderen Kontexten wiederverwendet werden.

Wenn Sie solche "Schnittstellenrealisierungsdiagramme" erstellen, müssen Sie möglicherweise neue Klassen und Subsysteme erstellen, die das erforderliche Verhalten erbringen. Der Prozess gleicht dem Prozess, der in der Anwendungsfallanalyse definiert ist, aber anstelle von Anwendungsfällen wird hier mit Schnittstellenoperationen gearbeitet. Geben Sie für jede Schnittstellenoperation die Klassen (bzw. für komplexes Verhalten ein Subsystem) im aktuellen Subsystem an, die für die Durchführung der Operation erforderlich sind. Erstellen Sie neue Klassen/Subsysteme, wenn die vorhandenen Klassen/Subsysteme das erforderliche Verhalten nicht aufweisen (versuchen Sie es jedoch zuerst mit Wiederverwendung).

Wenn neue Designelemente erstellt werden, müssen Subsysteminhalt und -schnittstellen neu überdacht werden. Vermeiden Sie die Verwendung derselben Klasse in zwei unterschiedlichen Subsystemen. Die Existenz einer solchen Klasse weist darauf hin, dass die Subsystemgrenzen nicht klar gezogen sind. Greifen Sie in regelmäßigen Abständen auf die Aufgabe Designelemente identifizieren zurück, um die Zuständigkeiten der Subsysteme zu überprüfen.

Manchmal ist es hilfreich, zwei separate interne Modell des Subsystems zu erstellen - eine Spezifikation für den Subsystemclient und eine Realisierung für die Implementierer. Die Spezifikation kann "ideale" Klassen und Kollaborationen enthalten, um das Verhalten des Subsystems zu beschreiben. Die Realisierung hingegen lehnt sich enger an die Implementierung an und kann zur Implementierung weiterentwickelt werden. Weitere Informationen zur Spezifikation und Realisierung von Designsubsystemen finden Sie in Richtlinie für Arbeitsergebnis: Designsubsystem, Subsystemspezifikation und -realisierung.

Subsystemelemente dokumentieren
Zweck Interne Struktur des Subsystems dokumentieren  

Um die interne Struktur des Subsystems zu dokumentieren, erstellen Sie ein oder mehrere Klassendiagramme, die die im Subsystem enthaltenen Elemente und ihre Assoziationen zueinander zeigen. Ein Klassendiagramm sollte zwar ausreichen, aber zur Verringerung der Komplexität und zur besseren Verständlichkeit können auch mehrere verwendet werden.

Schauen Sie sich das folgende Beispielklassendiagramm an:

Im Begleittext beschriebene Abbildung

Beispielklassendiagramm für Auftragserfassungssystem

Modelliert als Komponente kann der interne Inhalt eines Subsystems alternativ im Komponentenrechteck in einem Komponentendiagramm dargestellt werden. Diese Darstellung erlaubt Ihnen außerdem, die Interaktionspunkte des Subsystems zu anderen Teilen des Systems (über seine Schnittstellen) einzufügen.

Das folgende Komponentendiagramm zeigt das Subsystem Auftrag, seinen internen Inhalt sowie die bereitgestellten und erforderlichen Schnittstellen.

Im Begleittext beschriebenes Diagramm

Beispielkomponentendiagramm für Subsystem Auftrag

Da eine Komponente eine strukturierte Klasse ist, kann ein hoher Kapselungsgrad erreicht werden, indem eingehende Kommunikation über Ports geleitet wird, die deklarierten Schnittstellen entsprechen. Dies präzisiert die Spezifikation und die gegenseitige Verbindungen für diese Komponente noch weiter. In dieser Darstellung können Sie Instanzen von Teilen über Konnektoren verknüpfen, so dass sie eine bestimmte Rolle in der Komponentenimplementierung übernehmen. Weitere Informationen hierzu finden Sie in Strukturierte Klasse.

Schauen Sie sich das folgende Beispiel für ein zusammengesetztes Strukturdiagramm für das Subsystem Auftrag mit Schnittstellen und Ports an.

Im Begleittext beschriebenes Diagramm

Beispiel für ein zusammengesetztes Strukturdiagramm für das Subsystem Auftrag



Zusätzlich kann ein Zustandsdiagramm erforderlich sein, um die möglichen Zustände eines Subsystems zu dokumentieren. Informationen hierzu finden Sie in Technik: Zustandsdiagramm.

Die Beschreibung der im Subsystem enthaltenen Klassen selbst erfolgt beim Klassendesign.

Subsystemabhängigkeiten beschreiben
Zweck Schnittstellen dokumentieren, von denen das Subsystem abhängig ist.  

Wenn ein in einem Subsystem enthaltenes Element Verhalten eines Elements in einem anderen Subsystem verwendet, entsteht zwischen den Subsystemen eine Abhängigkeit. Um die Wiederverwendung zu verbessern und Verwaltungsabhängigkeiten zu verringern, können Sie diese Situation mit Hilfe einer Abhängigkeit von einer bestimmten Schnittstelle des Subsystems und nicht vom Subsystemselbst oder von dem im Subsystem enthaltenen Element beschreiben.

Es gibt zweierlei Gründe:

  • Es soll möglich sein, ein Modellelement (einschließlich seiner Subsysteme) durch ein anderes zu ersetzen, sofern beide dasselbe Verhalten aufweisen. Das erforderliche Verhalten wird mit Schnittstellen beschrieben. Deshalb sollten auch alle Verhaltensanforderungen, die ein Modellelement an ein anderes stellt, mit Schnittstellen beschrieben werden.
  • Der Designer soll völlige Freiheit beim Design des internen Verhaltens des Subsystems haben, sofern das Subsystem das richtige externe Verhalten erbringt. Wenn ein Modellelement in einem Subsystem auf ein Modellelement in einem anderen Subsystem verweist, kann der Designer dieses Modellelement nicht mehr entfernen oder das Verhalten dieses Modellelements auf andere Modellelemente verteilen. Deshalb ist das System labiler.

Vergewissern Sie sich beim Erstellen von Abhängigkeiten, dass keine direkten Abhängigkeiten oder Assoziationen zwischen Modellelementen im Subsystem und Modellelementen in anderen Subsystemen bestehen. Stellen Sie außerdem sicher, dass es keine Schleifenabhängigkeiten zwischen Subsystemen und Schnittstellen gibt. Es ist nicht möglich, dass ein Subsystem eine Schnittstelle realisiert und gleichzeitig von dieser Schnittstelle abhängig ist.

Abhängigkeiten zwischen Subsystemen und zwischen Subsystemen und Paketen können wie gezeigt direkt gezeichnet werden. Wenn Abhängigkeiten auf diese Weise gezeichnet werden, gibt die Abhängigkeit an, dass ein Subsystem (z. B. Rechnungsverwaltung) direkt von einem anderen Subsystem (Terminierung von Zahlungen) abhängig ist.


Im Begleittext beschriebenes Diagramm

Beispiel für Subsystemschichten mit direkten Abhängigkeiten

Wenn es möglich ist, dass ein Subsystem durch ein anderes (das dieselben Schnittstellen hat) ersetzt wird, kann die Abhängigkeit zu einer vom Subsystem realisierten Schnittstelle anstatt zum Subsystem selbst gezeichnet werden. Auf diese Weise kann jedes andere Modellelement (Subsystem oder Klasse), das dieselbe Schnittstelle realisiert, verwendet werden. Mit Schnittstellenabhängigkeiten können flexible Frameworks mit austauschbaren Designelementen entworfen werden.


Im Begleittext beschriebenes Diagramm

Beispiel für Subsystemschichten mit Schnittstellenabhängigkeiten

 

Weitere Informationen