Richtlinie: Kapsel
Diese Richtlinie beschreibt das Konzept der Kapsel für Echtzeitsysteme.
Beziehungen
Hauptbeschreibung

Themen

Ports

Da sich Ports an der Grenze einer Kapsel befinden, sind sie sowohl vom Inneren als auch vom Äußeren der Kapsel sichtbar. Vom Äußeren der Kapsel aus betrachtet stellen alle Ports dieselbe undurchdringbare Objektschnittstelle dar und lassen sich nur anhand ihrer Identität und der Rolle, die sie in ihrem Protokoll spielen, unterscheiden. Vom Inneren der Kapsel aus betrachtet lassen sich Ports jedoch in zwei Arten unterscheiden: Relay-Ports und End-Ports. Sie unterscheiden sich in ihren internen Verbindungen. Relay-Ports sind mit Unterkapseln verbunden, während End-Ports mit der Zustandsmaschine der Kapsel verbunden sind. Gewöhnlich werden Relay-Ports verwendet, um die "Schnittstellen" interner Unterkapseln selektiv zu exportieren, während End-Ports Grenzobjekte für die Zustandsmaschine einer Kapsel sind. Relay- und End-Ports können auf der Grenze der Kapsel dargestellt werden und sind, wie gesagt, von außen nicht voneinander zu unterscheiden.

Relay-Ports

Relay-Ports sind Ports, die Signale einfach durchreichen. Sie sind eine "Öffnung" in der Kapselungsschale einer Kapsel, die von den Unterkapseln verwendet werden kann, um mit der Außenwelt zu kommunizieren, ohne sich dieser wirklich offen zu legen (und umgekehrt). Ein Relay-Port ist über einen Konnektor mit einer Unterkapsel und normalerweise auch von außen her mit einer anderen Partnerkapsel ("Peer") verbunden. Sie empfangen Signale von beiden Seiten und leiten diese einfach unter Einhaltung der Richtung des Signalflusses an die jeweils andere Seite weiter. Dies geschieht ohne Verzögerung und Informationsverlust, sofern auf der anderen Seite ein Konnektor vorhanden ist. Sollte kein Konnektor vorhanden sein, geht das Signal verloren.

Relay-Ports lassen die direkte Delegierung (ohne zusätzlichen Aufwand) der für eine Kapsel bestimmten Signale an eine Unterkapsel zu, ohne dass die Zustandsmaschine der Kapsel intervenieren muss. Relay-Ports können nur auf der Grenze einer Kapsel dargestellt werden und sind deshalb öffentlich sichtbar.

End-Ports

Um hilfreich zu sein, muss eine Kette von Konnektoren letztendlich in einem End-Port enden, der mit der Zustandsmaschine kommuniziert. End-Ports sind Grenzobjekte für die Zustandsmaschinen einer Kapsel (obwohl, wie wir noch sehen werden, einige auch als Grenzobjekte für die Kapsel dienen). End-Ports sind die eigentlichen Quellen und Senken für alle Signale, die von Kapseln gesendet werden. Diese Signale werden von den Zustandsmaschinen von Kapseln generiert. Zum Senden eines Signals ruft eine Zustandsmaschine eine Sende- oder Aufrufoperation an einem ihrer End-Ports auf. Das Signal wird dann über den verbundenen Konnektor weitergeleitet, durchläuft möglicherweise einen oder mehrere Relay-Ports und verkettete Konnektoren, bis es letztendlich auf einen anderen End-Port tritt, der sich normalerweise in einer anderen Kapsel befindet. Da signalbasierte Kommunikation asynchron sein kann, hat ein End-Port eine Warteschlange für Nachrichten, die zwar von der Zustandsmaschine empfangen, aber noch nicht verarbeitet wurden (d. h. sie dient als Mailbox). Der Empfang des Signals und die Zuteilung der empfangenden Zustandsmaschine wird von der Zustandsmaschine entsprechend der UML-Standardsemantik vorgenommen.

Wie Relay-Ports können End-Ports auf der Grenze einer Kapsel erscheinen und öffentlich sichtbar sein. Diese Ports werden als öffentliche End-Ports bezeichnet. Solche Ports sind Grenzobjekte der Zustandsmaschine und der übergeordneten Kapsel. End-Ports können jedoch auch vollständig innerhalb der Kapsel, als Teil der internen Implementierungsstruktur erscheinen. Diese Ports werden von der Zustandsmaschine verwendet, um mit den Unterkapseln oder mit externen Schichten für die Implementierungsunterstützung zu kommunizieren. Diese internen End-Ports werden als geschützte End-Ports bezeichnet, das sie die Sichtbarkeitsstufe "protected" haben.

Diese Art von Port wird vollständig von seiner internen Konnektivität und seiner Sichtbarkeit außerhalb der Kapsel bestimmt. Die verschiedenen Begriffe (Relay-Port, öffentlicher End-Port, privater End-Port) sind lediglich Kurzbeschreibungen. Ein öffentlicher Port, der intern nicht verbunden ist, kann je nachdem, wie er später verbunden wird, entweder ein Relay-Port oder ein End-Port werden. Er kann auch unverbunden bleiben und eine Senke für eingehende Signale sein.

Port-Sichtbarkeit

Von außen her gesehen ist ein Port ein Port. Es ist nicht möglich und auch nicht wünschenswert zu bestimmen, ob ein Port ein Relay-Port oder ein End-Port ist. Wenn Sie sich jedoch die Dekomposition einer Kapsel anschauen, sehen Sie das Innere der Kapsel und, wie im Folgenden zu sehen, wird dort zwischen End-Port und Relay-Port unterschieden.

Im Begleittext beschriebenes Diagramm

Port-Notation - Kommunikationsdiagramm (interne Sicht)

Port-basierte Auslöser

In der Praxis passiert es häufig, dass zwei oder mehr Ports derselben Kapsel dasselbe Protokoll verwenden, aber semantisch verschieden sind. Es ist auch möglich, dass dasselbe Signal in mehreren Protokollrollen auftreten kann, die von unterschiedlichen Ports einer Kapsel unterstützt werden. In beiden Fällen kann es erforderlich sein, den spezifischen End-Port, der das aktuelle Signal empfangen hat, zu ermitteln. Auf diese Weise sind Anwendungen in der Lage, dasselbe Signal je nach Signalquelle und -zustand unterschiedlich zu bearbeiten. Dieser Typ von Auslöser wird als Port-basierter Auslöser bezeichnet. Port-basierte Auslöser werden in UML mit Wächterbedingungen modelliert, die einen bestimmten Quellen-Port überwachen.

Zustandsmaschinen

Die Spezifikation der Zustandsmaschine einer Kapsel und die Spezifikation gültiger Protokollsequenzen wird mit UML-Standardzustandsmaschinen vorgenommen.

Zeitservice

Erwartungsgemäß ist in den meisten Echtzeitsystemen Zeit der vorrangige Faktor. Im Allgemeinen müssen zwei Arten zeitbasierter Situationen modelliert werden: die Fähigkeit, Aufgaben zu einer bestimmten Uhrzeit auszulösen, und die Fähigkeit, Aufgaben auszulösen, nachdem ausgehend von einem bestimmten Zeitpunkt ein gewisser Zeitraum abgelaufen ist.

Die meisten Echtzeitsysteme erfordern eine explizite und direkt zugängliche (steuerbare) Taktungseinrichtung, einen so genannten Zeitservice. Dieser Service, der über einen Standard-Port (Servicezugriffspunkt) zugänglich ist, konvertiert Zeit in Ereignisse, die dann auf dieselbe Weise bearbeitet werden können wie andere signalbasierte Ereignisse. Mit einem solchen Service kann eine Zustandsmaschine beispielsweise anfordern, dass sie mit einem "Timeout"-Ereignis benachrichtigt wird, wenn eine bestimmte Uhrzeit erreicht ist oder wenn ein bestimmter Zeitraum abgelaufen ist.

Kapseltaxonomie

Kapseln können als Konzept auf viele verschiedene Arten eingesetzt werden. Hierfür können eine Kapselhierarchie und eine Kapseltaxonomie beschrieben werden, um die allgemeinen Einsatzgebiete für Kapseln abzudecken.

Rollenmodellrealisierung Typisiertes Rollenmodell Typisierte Rollenrealisierung Rollenrealisierung Kapsel Rollenmodell Rollentyp Im Begleittext beschriebenes Diagramm

Kapseltaxonomie, die eine Generalisierungshierarchie zeigt

Im Folgenden wird die Basistaxonomie einer Kapsel beschrieben:

  • Kapsel

    Eine Basiskapsel ohne Ports, interne Struktur oder Verhalten ist nicht sehr interessant, weil sie nicht viel tut. Eine solche Kapsel könnte verwendet werden, um eine abstrakte Kapsel zu definieren, von der andere Kapseln abgeleitet werden. Da keine Ports, Struktur und kein Verhalten definiert sind, ist dieser Kapseltyp nur hilfreich, um einen "Platzhalter" zu definieren, der später präzisiert wird.

  • Rollentyp

    Eine Kapsel vom Typ "Rollentyp" ist eine Kapseldefinition, die eine abstrakte Kapsel mit einem oder mehreren Ports definiert. Es wird weder Struktur noch Verhalten definiert. Dieser Typ von Kapsel wird verwendet, wenn die "Schnittstellen" (Ports) einer Gruppe von Kapseln einmal definiert und die spezifischen Realisierungen dieser Schnittstellen von den Untertypen der Kapsel 'Rollentyp' definiert werden müssen.

  • Rollenmodell

    Eine Kapsel vom Typ "Rollenmodell" ist eine Kapseldefinition mit einer internen Struktur (die durch eine Spezifikationskollaboration definiert wird) verschachtelter und potenziell miteinander verbundener Kapseln und möglicherweise einem oder mehreren Ports. Dieser Typ von Kapsel wird verwendet, um eine "Vorlage" für die Struktur eines Systems zu definieren, deren 'Details' an die enthaltenen Kapseln delegiert werden. Wenn eine Kapsel vom Typ "Rollenmodell" Ports hat, definieren diese Ports die 'Schnittstellen' für die Kapsel.

    Das Verhalten des 'Rollenmodells' ist nicht spezifiziert (es ist keine Zustandsmaschine definiert). Es muss von den Untertypen der Kapsel definiert werden.

  • Rollenrealisierung

    Eine Kapsel vom Typ "Rollenrealisierung" definiert Verhalten (über eine Zustandsmaschine) für die Kapsel, aber weder eine interne Struktur noch Schnittstellen. Sie ist im Wesentlichen eine abstrakte Definition von Verhalten für alle abgeleiteten Kapseln, die ihre eigene Struktur und ihre eigenen Schnittstellen definieren müssen. Die Verhaltensdefinition kann als 'Designzusicherung' betrachtet werden, die von allen Kapseln erfüllt werden muss, die von der Kapsel des Typs "Rollenrealisierung" abgeleitet werden.

Es gibt drei hilfreiche Hybridformen dieser Basistypen, die Kombinationen der Basisdefinitionen sind:

  • Typisierte Rollenrealisierung

    Dieser Typ von Kapsel definiert eine Schnittstelle und das Verhalten für eine Rolle von Kapseln, schränkt aber die interne Struktur abgeleiteter Kapseln nicht ein. Sie ist im Wesentlichen eine Kapsel des Typs 'Rollenrealisierung' mit einer Schnittstellendefinition.

  • Typisiertes Rollenmodell

    Dieser Typ von Kapsel definiert eine Schnittstelle und die Struktur einer Gruppe von Kapseln, schränkt aber das Verhalten dieser Kapseln nicht ein. Der Vorteil dieses Typs von Kapsel ist, dass Sie eine Vorlage für die Schnittstelle und die Struktur definieren, die anschließend von den abgeleiteten Kapseln spezialisiert werden kann.

  • Rollenmodellrealisierung

    Dieser Typ von Kapsel definiert eine interne Struktur für die Kapsel und ihr abstraktes Verhalten, aber keine Schnittstelle. Eine solche Kapsel ist hilfreich, wenn mehrere Kapseln einen großen Teil der internen Struktur und des Verhaltens gemein, aber unterschiedliche Schnittstellen haben.

Der letzte Kapseltyp, die 'Typisierte Rollenmodellrealisierung', die Struktur und Schnittstelle sowie abstraktes Verhalten (für die Schnittstelle) und spezifisches Verhalten (für die interne Struktur) definiert, ist komplex und nur schwer zu verstehen, geschweige denn zu implementieren. Dieser Typ wird hier für den Fall erwähnt, dass Einheitentests für die Kapsel im Rahmen der Kapsel selbst definiert werden müssen; deshalb die beiden gesonderten Zustandsmaschinen. Dieses Konstrukt sollte nach Möglichkeit vermieden werden.

UML-2.0-Darstellung

Die aktuelle RUP-Darstellung für Kapseln basiert auf der UML-1.5-Notation. 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.