Themen
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 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.
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.
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.
Port-Notation - Kommunikationsdiagramm (interne Sicht)
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.
Die Spezifikation der Zustandsmaschine einer Kapsel und die Spezifikation gültiger Protokollsequenzen wird mit
UML-Standardzustandsmaschinen vorgenommen.
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.
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.
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.
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.
|