Aufgabe: Designelemente identifizieren |
|
 |
Diese Aufgabe beschreibt, wie Subsysteme Subsysteme, Klassen, Schnittstellen, Ereignisse und Signale identifiziert werden. |
Disziplinen: Analyse und Design |
|
Zweck
-
Interaktionen von
Analyseklassen analysieren, um Designmodellelemente zu identifizieren
|
Beziehungen
Rollen | Primärer Ausführender:
| Zusätzliche Ausführende:
|
Eingaben | Verbindlich:
| Optional:
|
Ausgaben |
|
Prozessverwendung |
|
Hauptbeschreibung
Das Ergebnis der Aufgabe: Anwendungsfallanalyse sind Analyseklassen, die
konzeptionelle Elemente, die Verhalten erbringen können, darstellen. Im Design werden Analyseklassen in
unterschiedlichen Arten von Designelementen weiterentwickelt:
-
Klassen zum Darstellen differenzierter Zuständigkeiten
-
Subsysteme für die Darstellung allgemein definierter Zuständigkeiten, die sich unter Umständen aus einer weiteren
Gruppe von Subsystemen zusammensetzen, aber letztendlich eine Gruppe von Klassen sind
-
Aktive Klassen, die die Threads im System darstellen
-
Schnittstellen, die abstrakte Deklarationen von Zuständigkeiten einer Klasse oder eines Subsystems darstellen
Außerdem wird im Design Folgendes identifiziert:
-
Ereignisse, die Spezifikationen interessanter Vorkommen in Zeit und Raum sind und gewöhnlich (sofern sie
erwähnenswert sind) eine Antwort vom System voraussetzen
-
Signale für die Darstellung asynchroner Mechanismen, die für die Übertragung bestimmter Typen von Ereignissen
innerhalb des Systems verwendet werden
Auf der Basis dieser feineren Unterscheidungen können Sie die unterschiedlichen Aspekte des Designs untersuchen:
-
Mit Ereignissen und den Signalen, die diese Ereignisse übertragen, können die asynchronen Auslöser für Verhalten
beschrieben werden, auf die das System antworten muss.
-
Mit Klassen und Subsystemen können Sie zusammengehörige Zuständigkeiten zu Einheiten zusammenfassen, die relativ
unabhängig voneinander entwickelt werden können. Klassen bilden eine atomare Gruppe zusammengehöriger
Zuständigkeiten, wohingegen Subsysteme zusammengesetzte Bausteine sind, die sich aus Klassen und anderen
Subsystemen zusammensetzen. Subsysteme werden verwendet, um die Arbeitsergebnisse eines Entwicklungsteams als
einzelne, integrale Funktionalitätseinheit darzustellen, und sind somit sowohl Steuerungs- und
Konfigurationsmanagementeinheiten als auch logische Designelemente.
-
Aktive Klassen werden verwendet, um Steuerungs-Threads im System darzustellen und Parallelität zu modellieren.
Aktive Klassen werden häufig zusammen mit anderen Klassen verwendet, die gewöhnlich, aber nicht zwingenderweise
passiv sind. Eine solche Komposition kann wie eine Kollaboration verwendet werden, um komplexes Verhalten zu
modellieren.
In Echtzeitsystemen werden Kapseln anstelle aktiver Klassen verwendet. Kapseln bieten eine stärkere Semantik
für die Vereinfachung des Designs und erhöhen die Zuverlässigkeit paralleler Anwendungen. Kapseln haben gewisse
Aspekte mit Klassen und Subsystemen gemein und sind eigentlich gekapselte Kollaborationen von Klassen, die
zusammen einen Steuerungs-Threads im System darstellen. Sie unterscheiden sich insofern von Subsystemen, als
eine Kapsel in der Zuständigkeit eines einzelnen Designers liegt, während für ein Subsystem (normalerweise) ein
Team von Entwicklern verantwortlich ist. Ein Subsystem kann jedoch Kapseln enthalten.
-
Mit Schnittstellen können Sie die "Nähte" des Systems untersuchen und beschreiben. Schnittstellen definieren in
exakter Weise, wie die einzelnen Bestandteile des Systems zusammenwirken.
-
In Echtzeitsystemen werden Protokolle verwendet, um die Nachrichten präzise zu definieren, die an einem Port einer
Kapsel gesendet und empfangen werden können.
Durch die Trennung der Problemstellungen und die gesonderte Behandlung jedes von diesen diesen Konzepten dargestellten
Aspekts wird der Designprozess vereinfacht und die zugehörige Lösung klar veranschaulicht.
Wenn die Rückverfolgbarkeit zwischen Systemmodellen gewährleistet sein muss, muss dies in dieser Aufgabe dokumentiert
werden. Weitere Informationen zum Dokumentieren der Rückverfolgbarkeit zwischen dem Designmodell und anderen
Systemmodellen finden Sie in Richtlinie:
Designmodell.
UML-1.x-Darstellung
In UML 1.5 ist ein Subsystem eine spezielle Art von Paket, das nur Schnittstellen als öffentliche Elemente enthält. Die
Schnittstellen sind eine Kapselungsschicht und erlauben, das interne Design des Subsystems vor anderen Modellelementen
zu verbergen. Das Konzept Subsystem wird verwendet, um eine Unterscheidung von "herkömmlichen" Paketen möglich zu
machen, die semantikfreie Container von Modellelementen sind. Das Subsystem stellt eine bestimmte Verwendung von
Paketen mit klassenähnlichen (Verhaltens-) Eigenschaften dar.
In RUP werden Kapseln in der UML-1.5-Notation dargestellt. Ein Großteil dieses Konzepts kann in UML 2.0 mit dem Konzept: Strukturierte Klasse dargestellt werden.
Lesen Sie auch den Artikel Unterschiede zwischen UML 1.x und UML 2.0.
|
Schritte
Ereignisse und Signale identifizieren
Zweck
|
Externe und interne Ereignisse und Signale identifizieren, auf die das System antworten muss
|
Ereignisse sind externe und interne Vorkommen, die eine Aktion im System bewirken. Ereignisse und ihre Merkmale
können die Ermittlung von Schlüsseldesignelementen, z. B. aktiver Klassen, lenken.
Eine erste Liste mit externen Ereignissen kann aus dem Anwendungsfallmodell aus den Interaktionen der Akteure mit
Anwendungsfällen abgeleitet werden. Interne Ereignisse können aus dem Text in den Abläufen der Anwendungsfälle
abgeleitet und während der Weiterentwicklung des Designs ermittelt werden.
Wichtige Merkmale von Ereignissen:
-
intern vs. extern - Ist das Ereignis extern oder intern?
-
Priorität - Muss das Ereignis das Aussetzen anderer Verarbeitung erwirken, um behandelt zu werden?
-
Häufigkeit - Wie oft tritt das Ereignis ein?
-
Verteilung der Häufigkeit - Tritt das Ereignis in regelmäßigen Abständen ein oder gibt es Spitzen?
-
Antwortanforderungen - Wie schnell muss das System auf das Ereignis antworten (hierfür ist möglicherweise eine
Unterscheidung zwischen herkömmlichen und ungünstigstem Fall erforderlich)?
-
Art - Handelt es sich um ein Aufrufereignis, Zeitereignis, Signalereignis oder Änderungsereignis (die
Definitionen finden Sie in Konzept:
Ereignisse und Signale)?
Gegebenenfalls müssen die Merkmale von Ereignissen beschrieben werden, um die Identifizierung der Designelemente zu
steuern, die diese Ereignisse verarbeiten. Die Beschreibung von Ereignismerkmalen ist in der Regel eine extrem
wichtige Aufgaben in reaktiven (ereignisgesteuerten) Systemen, kann aber auch in anderen Systemen hilfreich sein,
beispielsweise solchen, die mit Parallelität und/oder asynchroner Nachrichtenübermittlung arbeiten.
Asynchrone Kommunikationsereignisse können als Signale modelliert werden, um die Daten zu veranschaulichen, die sie
übertragen, oder um Beziehungen zwischen Signalen, z. B. eine Generalisierung, auszudrücken. In einigen Systemen,
insbesondere aktiven Systemen, ist es wichtig, die Signale, die von externen Einheiten empfangen werden, speziellen
Mechanismen, z. B. Interrupts oder speziellen Abfragenachrichten, zuzuordnen.
|
Klassen, aktive Klassen und Subsysteme identifizieren
Zweck
|
Analyseklassen zu entsprechenden Designmodellelementen konkretisieren
|
Klassen identifizieren. Wenn die Analyseklasse einfach ist und bereits eine logische Abstraktion darstellt, kann
sie 1:1 einer Designklasse zugeordnet werden. Entitätsklassen werden normalerweis relativ unverändert in das
Design übernommen. Da Entitätsklassen in der Regel auch persistent ist, müssen Sie bestimmen, ob die Designklasse
persistent sein soll und dies entsprechend in der Klassenbeschreibung dokumentieren.
Wenn Sie Klassen identifizieren, gruppieren Sie sie zu Organisations- und Konfigurationsmanagementzwecken in Designpaketen. Weitere Informationen zu Packentscheidungen finden Sie
in Richtlinie für Arbeitsergebnis: Designpaket.
Aktive Klassen identifizieren. Schauen Sie sich die Parallelitätsanforderungen des Systems im Kontext der
identifizierten Analyseobjekte an. Muss das System auf extern generierte Ereignisse antworten, und wenn ja, welche
Analyseklassen sind 'aktiv', wenn die Ereignisse eintreten? Externe Ereignisse im Anwendungsfallmodell werden durch
Stimuli dargestellt, die von den Akteuren stammen, die mit einem Anwendungsfall interagieren. Schauen Sie sich die
entsprechenden Anwendungsfallrealisierungen an, um festzustellen, welche Objekte interagieren, wenn ein Ereignis
eintritt. Beginnen Sie damit, die Objekte zu autonomen Gruppen kollaborierender Objekte zu gruppieren. Diese
Gruppierungen stellen einen ersten Schnitt unter eine Gruppe dar, die eine zusammengesetzte aktive Klasse bilden
könnte.
Wenn die Ereignisse wichtige Attribute haben, die beschrieben werden müssen, können Sie diese als Klassen mit dem
Stereotyp <<Signal>> modellieren. In Echtzeitsystemen müssen diese identifizierten Gruppen von Objekten in
Kapseln zusammengefasst eingebunden werden, die eine starke Kapselungssemantik haben.
Die Instanzen aktiver Klassen stellen unabhängige 'logische' Ausführungs-Threads dar. Diese 'logischen'
Ausführungs-Threads dürfen nicht mit mit den Ausführungs-Threads im Betriebssystem verwechselt werden (obwohl sie
irgendwann dem Ausführungs-Thread des Betriebssystems zugeordnet werden). Sie stellen vielmehr unabhängige
konzeptionelle Ausführungs-Threads im Lösungsbereich dar. Durch die Ermittlung dieser Ausführungs-Threads zu genau
diesem Zeitpunkt im Design kann die Lösung in unabhängige Einheiten eingeteilt werden, die auf den natürlichen
"Parallelitätssträngen' im System basiert. Die Arbeit auf diese Weise einzuteilen, vereinfacht die konzeptionelle
Behandlung von Parallelitätsproblemen, da unabhängige Ausführungs-Threads abgesehen davon, dass sie die zugrunde
liegenden passiven Klassen gemeinsam nutzen, separat behandelt werden können.
Eine aktive Klasse sollte im Allgemeinen immer dann berücksichtigt werden, wenn Parallelität und Parallelitätskonflikte
in der Problemdomäne auftreten. Eine aktive Klasse muss verwendet werden, um ein externes paralleles Objekt oder eine
parallele Aktivität im Computer darzustellen. Auf diese Weise können Sie parallele Aktivitäten überwachen und steuern.
Aktive Klassen können auch als interne Darstellungen externer physischer Einheiten, die mit einem Computer
verbunden ist, verwendet werden, da diese physischen Entitäten an sich parallel sind. Diese "Einheitentreiberklassen"
dienen nicht nur zur Überwachung und Steuerung der entsprechenden physischen Einheiten, sondern isolieren auch den Rest
des Systems von den Besonderheiten der Einzeiten. Das bedeutet, dass der Rest des Systems nicht betroffen ist, falls
sich die Technologie hinter den Einheiten weiterentwickelt.
Aktive Klassen werden außerdem verwendet, um logische parallele Aktivitäten darzustellen. Eine logische Aktivität
stellt ein konzeptionelles paralleles "Objekt" dar, z. B. eine Geldtransaktion oder ein Telefonanruf. Obwohl diese
nicht direkt als physische Entitäten manifestiert sind (auch wenn sie in der echten Welt stattfinden), gibt es oft
Gründe, sie als solche zu behandeln. Beispielsweise kann es sein, dass eine bestimmte Geldtransaktion vorübergehend
zurückgehalten werden muss, um einen Parallelitätskonflikt zu verhindern, oder aufgrund von Fehlern im System sogar
abgebrochen werden muss. Da diese konzeptionellen Objekte als Einheit bearbeitet werden müssen, bietet es sich an, sie
als Objekte mit eigenen Schnittstellen darzustellen, die die entsprechenden funktionalen Fähigkeiten bereitstellen.
Ein besonderes Beispiel dieses Typs von konzeptionellem Objekt ist ein aktiver Objektcontroller. Dieser
Controller hat die Aufgabe, ein oder mehrere andere aktive Objekte kontinuierlich zu verwalten. Dies beinhaltet
normalerweise, jedes Objekt in den gewünschten Betriebszustand zu versetzen, es trotz verschiedener Störungen wie
Teilfehlern in diesem Zustand zu halten und seine Ausführung mit der Ausführung anderer Objekte zu synchronisieren.
Diese aktiven Objektcontroller entwickeln sich häufig aus Steuerungsobjekten, die während der Anwendungsfallanalyse ermittelt werden.
Aufgrund ihrer Fähigkeit, Parallelitätskonflikte einfach und elegant lösen zu können, sind aktive Klassen auch als
Wächter gemeinsam genutzter Ressourcen geeignet. In diesem Fall werden eine oder mehrere Ressourcen, die von
mehreren parallelen Aktivitäten benötigt werden, in einer aktiven Klasse gekapselt. Aufgrund ihrer integrierten
Ausschlusssemantik schützen solche Wächter die Ressourcen automatisch vor Parallelitätskonflikten.
In Echtzeitsystemen müssen Kapseln anstelle aktiver Klasse verwendet werden. Wenn Sie entsprechend der zuvor
beschriebenen Heuristik den Bedarf an einer aktiven Klasse feststellen, müssen Sie stattdessen eine Kapsel
verwenden.
Subsysteme identifizieren. Wenn die Analyseklasse komplex ist, z. B. Verhalten enthält, das nicht in der
Zuständigkeit einer einzelnen Klasse allein liegen kann, muss die Analyseklasse einem Designsubsystem zugeordnet
werden. Das Designsubsystem wird verwendet, um diese Kollaborationen so zu kapseln, dass den Clients des Subsystems das
interne Design des Subsystems völlig verborgen bleibt, selbst wenn sie die vom Subsystem bereitgestellten Services
nutzen.
Ein Subsystem wird als UML-Komponente modelliert, die nur Schnittstellen als öffentliche Elemente besitzt. Die
Schnittstellen sind eine Kapselungsschicht und erlauben, das interne Design des Subsystems vor anderen Modellelementen
zu verbergen. Das Konzept Subsystem wird verwendet, um eine Unterscheidung von "herkömmlichen" Paketen möglich zu
machen, die semantikfreie Container von Modellelementen sind.
Der Beschluss, aus einer Gruppe kollaborierender Analyseklassen ein Subsystem zu erstellen, basiert im Wesentlichen
darauf, ob die Kollaboration unabhängig von einem separaten Designteam entwickelt werden kann oder wird. Wenn die
Kollaborationen zusammen mit ihren kollaborierenden Klassen vollständig in einem Paket enthalten sein können, kann ein
Subsystem eine stärkere Form der Kapselung unterstützen als ein einfaches Paket. Inhalt und Kollaborationen in einem
Subsystem sind vollständig hinter einer oder mehreren Schnittstellen isoliert, so dass der Client des Subsystems nur
von der Schnittstelle abhängig ist. Der Designer des Subsystems ist damit vollständig von externen Abhängigkeiten
isoliert. Der Designer (bzw. das Designerteam) muss festlegen, wie die Schnittstelle realisiert wird, aber er hat
völlige Freiheit, das interne Subsystemdesign zu ändern, ohne damit externe Abhängigkeiten zu beeinträchtigen. In
großen Systemen mit weitgehend unabhängigen Teams ist dieser Grad von Entkopplung, kombiniert mit der
Architekturumsetzung durch formale Schnittstellen ein schlagkräftiges Argument für die bevorzugte Wahl von Subsystemen
gegenüber einfachen Paketen. Weitere Informationen zu den Faktoren, die sich darauf auswirken, ob Subsysteme als
Designelemente ausgewählt werden, finden Sie in Richtlinie für
Arbeitsergebnis: Designsubsystem.
|
Subsystemschnittstellen identifizieren
Zweck
|
Designelemente identifizieren, die die "Nähte" des Systems formalisieren
|
Schnittstellen definieren eine Gruppe von Operationen, die von einem bestimmten Klassifikationsmerkmal realisiert
werden. Im Designmodell werden Schnittstellen hauptsächlich verwendet, um die Schnittstellen für Subsysteme zu
definieren. Das soll nicht bedeuten, dass sie nicht auch für Klassen verwendet werden können, aber für eine einzelne
Klasse ist es gewöhnlich ausreichend, öffentliche Operationen in der Klasse zu definieren, die damit ihre
"Schnittstelle" selbst definiert. Schnittstellen sind für Subsysteme wichtig, weil sie eine Trennung von Deklaration
des Verhaltens (Schnittstelle) und Realisierung des Verhaltens (spezifische Klassen im Subsystem, die die Schnittstelle
realisieren) ermöglichen. Diese Entkopplung erhöht die Unabhängigkeit von Entwicklungsteams, die an unterschiedlichen
Teilen des Systems arbeiten, während die präzisen Definitionen der 'Verträge' zwischen diesen unterschiedlichen Teilen
weiterhin eingehalten werden.
Für jedes Subsystem eine Reihe geeigneter Schnittstellen identifizieren. Identifizieren Sie anhand der im
vorherigen Schritt identifizierten gruppierten Kollaborationen die Zuständigkeit, die bei der Einleitung der
Kollaboration "aktiviert" wird. Diese Zuständigkeit wird anschließend präzisiert, indem die vom 'Client'
bereitzustellenden Informationen und die Informationen bestimmt werden, die zurückgegeben werden, wenn die
Kollaboration abgeschlossen ist. Die Gruppen von Informationen werden zu den Ein- und Ausgabeparametern des Prototyps
und zum Rückgabewerte für eine Operation, die das Subsystem realisiert. Definieren Sie einen Namen für diese Operation.
Halten Sie sich bei der Benennung an die Namenskonventionen, die in den projektspezifischen Richtlinien definiert sind. Wiederholen Sie dies,
bis alle Operationen, die vom Subsystem realisiert werden, definiert sind.
Gruppieren Sie anschließend die Operationen entsprechend ihrer Zuständigkeiten. Kleinere Gruppen sind größeren Gruppen
vorzuziehen, das es wahrscheinlicher ist, dass eine kohäsive Gruppe gemeinsamer Zuständigkeiten vorhanden ist, wenn
weniger Operationen in der Gruppe enthalten sind. Achten Sie auch auf Wiederverwendung. Suchen Sie nach Ähnlichkeiten,
die es einfacher machen, zusammengehöre wiederverwendbare Funktionalität zu identifizieren. Verbringen Sie jedoch nicht
zu viel Zeit damit, die ideale Gruppierung von Zuständigkeiten zu finden. Denken Sie daran, dass es sich hierbei nur um
eine erste Gruppierung handelt, die iterativ während der Ausarbeitungsphase verfeinert wird.
Ähnlichkeiten zwischen Schnittstellen suchen. Suchen Sie innerhalb der Gruppe geeigneter Schnittstellen nach
ähnlichen Namen, ähnlichen Zuständigkeiten und ähnlichen Operationen. Wenn mehrere Schnittstellen dieselben Operationen
enthalten, müssen Sie ein Refactoring für die Schnittstellen ausführen und gemeinsame Operationen in eine neue
Schnittstelle extrahieren. Schauen Sie sich auch die vorhandenen Schnittstellen an und stellen Sie fest, ob diese
wiederverwendet werden können. Das Ziel ist, die Festigkeit der Schnittstellen zu bewahren und gleichzeitig redundante
Operationen in den Schnittstellen zu entfernen. Dies trägt zum einfacheren Verständnis und zur einfacheren
Weiterentwicklung der Schnittstellen bei.
Schnittstellenabhängigkeiten definieren. Die Parameter und der Rückgabewert jeder Schnittstellenoperation haben
jeweils einen bestimmten Typ. Sie müssen eine bestimmte Schnittstelle realisieren oder Instanzen eines einfachen
Datentyps sein. In den Fällen, in denen die Parameter Objekte sind, die eine bestimmte Schnittstelle realisieren,
müssen Sie Abhängigkeitsbeziehungen zwischen dieser Schnittstelle und den Schnittstellen, von denen sie abhängig ist,
definieren. Die Definition von Abhängigkeiten zwischen Schnittstellen liefert dem Softwarearchitekten hilfreiche
Kopplungsinformationen, da Schnittstellenabhängigkeiten die primären Abhängigkeiten zwischen Elementen im Designmodell
definieren.
Schnittstellen zu Subsystemen zuordnen. Nachdem Sie die Schnittstellen identifiziert haben, erstellen Sie
Realisierungsassoziationen zwischen dem Subsystem und den Schnittstellen, die das Subsystem realisiert. Eine
Realisierung vom Subsystem zu einer Schnittstelle zeigt an, dass es mindestens ein Element im Subsystem gibt, das die
Operationen der Schnittstelle realisiert. Später, beim Design des Subsystems werden diese Realisierungen der
Subsystemschnittstelle präzisiert, und der Subsystemdesigner legt fest, welche speziellen Elemente im Subsystem die
Operationen der Schnittstelle realisieren. Diese präzisierten Realisierungen sind nur für den Subsystemdesigner
sichtbar. Aus der Perspektive des Subsystemclients ist nur die Realisierung der Subsystemschnittstelle sichtbar.
Von den Schnittstellen spezifiziertes Verhalten definieren. Schnittstellen definieren häufig eine implizite
Zustandsmaschine für die Elemente, die die Schnittstelle realisieren. Wenn die Operationen in der Schnittstelle in
einer bestimmten Reihenfolge aufgerufen werden müssen (z. B. wenn die Datenbankverbindung geöffnet sein muss, damit sie
verwendet werden kann), muss eine Zustandsmaschine definiert werden, die die öffentlich sichtbaren (oder abgeleiteten)
Zustände veranschaulicht, die jedes Designelement, das die Schnittstelle realisiert, unterstützen muss. Diese
Zustandsmaschine hilft dem Benutzer der Schnittstelle, die Schnittstelle besser zu verstehen, und hilft dem Designer
der Elemente, die die Schnittstelle realisieren, das korrekte Verhalten für das Element bereitzustellen.
Schnittstellen packen. Eigner der Schnittstellen ist der Softwarearchitekt. Änderungen an Schnittstellen sind
architektonisch immer relevant. Zur Verwaltung der Schnittstellen müssen diese in einem oder mehreren Paketen gepackt
werden, deren Eigner der Softwarearchitekt ist. Wenn jede Schnittstelle von einem eigenen Subsystem realisiert wird,
können die Schnittstellen mit dem Subsystem in ein Paket gestellt werden. Wenn die Schnittstellen von mehreren
Subsystemen realisiert werden, müssen Sie in jeweils eigene Pakete gestellt werden, deren Eigner der Softwarearchitekt
ist. Damit können die Schnittstellen unabhängig von den Subsystemen verwaltet und gesteuert werden.
Zweck
|
Designelemente identifizieren, die die "Nähte" im System formalisieren (nur RT-Design).
|
In ereignisgesteuerten Systemen gleichen Protokolle Schnittschnellen: Sie identifizieren den 'Vertrag' zwischen
Kapseln, indem sie eine abgestimmte Gruppe von Signalen definieren, die für die Kommunikation zwischen unabhängigen
Steuerungs-Threads verwendet werden. Während Schnittstellen primär dazu verwendet werden, die synchrone Übertragung
unter Verwendung eines Funktionsaufrufmodells zu definieren, werden Protokolle hauptsächlich verwendet, um die
asynchrone Übertragung unter Verwendung von signalbasierter Nachrichtenübertragung zu definieren. Protokolle
ermöglichen eine Trennung von Deklaration des Verhaltens (Signalgruppe) und Realisierung des Verhaltens (Elemente im
Subsystem, die die Schnittstelle realisieren). Diese Entkopplung erhöht die Unabhängigkeit von Entwicklungsteams, die
an unterschiedlichen Teilen des Systems arbeiten, während die präzisen Definitionen der 'Verträge' zwischen diesen
unterschiedlichen Teilen weiterhin eingehalten werden.
Für jede Kapsel eine Gruppe von Eingangs- und Ausgangssignalen identifizieren. Identifizieren Sie anhand der in
den vorherigen Schritten identifizierten gruppierten Kollaborationen die Zuständigkeit, die bei der Einleitung der
Kollaboration "aktiviert" wird. Diese Zuständigkeit wird anschließend präzisiert, indem die vom 'Client'
bereitzustellenden Informationen und die Informationen bestimmt werden, die zurückgegeben werden, wenn die
Kollaboration abgeschlossen ist. Diese Gruppen von Informationen werden zu Eingabeparametern für ein Signal, das die
Kapsel über einen ihrer Ports realisiert. Definieren Sie einen Namen für dieses Signal. Halten Sie sich bei der
Benennung an die Namenskonventionen, die in den projektspezifischen Richtlinien definiert sind. Wiederholen Sie dies,
bis alle Signale, die von der Kapsel realisiert werden, definiert sind.
Gruppieren Sie anschließend die Signale entsprechend ihrer Zuständigkeiten. Kleinere Gruppen sind größeren Gruppen
vorzuziehen, das es wahrscheinlicher ist, dass eine kohäsive Gruppe gemeinsamer Zuständigkeiten vorhanden ist, wenn
weniger Signale in der Gruppe enthalten sind. Achten Sie auch auf Wiederverwendung. Suchen Sie nach Ähnlichkeiten, die
es einfacher machen, zusammengehöre wiederverwendbare Funktionalität zu identifizieren. Verbringen Sie jedoch nicht zu
viel Zeit damit, die ideale Gruppierung von Zuständigkeiten zu finden. Denken Sie daran, dass es sich hierbei nur um
eine erste Gruppierung handelt, die iterativ während der Ausarbeitungsphase verfeinert wird. Geben Sie dem Protokoll
einen aussagefähigen Namen, d. h. einen Namen, der die Rolle des Protokolls in den Kapselkollaborationen zum Ausdruck
bringt.
Ähnlichkeiten zwischen Protokollen suchen. Suchen Sie innerhalb der Gruppe geeigneter Protokolle nach ähnlichen
Namen, ähnlichen Zuständigkeiten und ähnlichen Signalen. Wenn mehrere Protokolle dieselben Signale enthalten, müssen
Sie ein Refactoring für die Protokolle ausführen und gemeinsame Signale in ein neues Protokoll extrahieren. Schauen Sie
sich auch die vorhandenen Protokolle an und stellen Sie fest, ob diese wiederverwendet werden können. Das Ziel ist, die
Festigkeit der Protokolle zu bewahren und gleichzeitig redundante Signale in den Protokollen zu entfernen. Dies trägt
zum einfacheren Verständnis und zur einfacheren Weiterentwicklung der Protokolle bei.
Protokolle zu Kapseln zuordnen. Nachdem Sie die Protokolle identifiziert haben, erstellen Sie Ports in
den Kapseln, die die Protokolle realisieren. Die Ports der Kapsel definieren ihre 'Schnittstellen', das Verhalten, das
von der Kapsel angefordert werden kann. Später, beim Design der Kapsel wird das von den Ports spezifizierte Verhalten
von der Zustandsmaschine für die Kapsel beschrieben.
Von den Protokollen spezifiziertes Verhalten definieren. Protokolle definieren häufig eine implizite
Zustandsmaschine für die Elemente, die die Schnittstelle realisieren. Wenn die Eingabesignale in der Schnittstelle in
einer bestimmten Reihenfolge empfangen werden müssen (z. B. wenn ein Signal vom Typ 'System bereit' empfangen werden
muss, damit ein bestimmtes Fehlersignal empfangen werden kann), muss eine Zustandsmaschine definiert werden, die die
öffentlich sichtbaren (oder abgeleiteten) Zustände veranschaulicht, die jedes Designelement, das das Protokoll
realisiert, unterstützen muss. Diese Zustandsmaschine hilft dem Benutzer der Kapseln, die das Protokoll realisieren,
das Kapselverhalten besser zu verstehen, und dem Designer der Kapseln, das korrekte Verhalten für das Element
bereitzustellen.
Protokolle packen. Eigner der Protokolle ist der Softwarearchitekt. Änderungen an Protokollen sind
architektonisch immer relevant. Zur Verwaltung der Protokolle müssen diese in einem oder mehreren Paketen gepackt
werden, deren Eigner der Softwarearchitekt ist. Damit können die Protokolle unabhängig von den Kapseln, die die
Protokolle realisieren, verwaltet und gesteuert werden.
|
|
Weitere Informationen
Prüflisten |
|
Konzepte |
|
Richtlinien |
|
Toolmentoren |
|
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|