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

Kapselprotokolle identifizieren

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