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