Jäger des verlorenen Ports

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Das Thema "Ports" verwirrt mich schon eine Weile (siehe auch "Conjugation considered harmful"). Jeder scheint eine andere Vorstellung zu haben, was ihr Wesenskern ist und wofür sie verwendet werden. Anhand eines rein mechanischen Systems möchte ich in diesem Post ein paar meiner Antworten zur Diskussion stellen.

Wieviele Ports sehen sie in diesem Bild eines Kapselhebers? Hier ist nach SysML (Proxy) Ports gefragt.

Zur Erinnerung - die SysML definiert Ports folgendermaßen:

Ports sind Punkte an denen externe Entitäten sich mit einem Block verbinden und mit ihm interagieren können. [SysML 1.5]

Denken sie kurz nach und zählen nach. Sind es drei, vier, fünf, neun, dreizehn oder noch mehr? Hängt es vielleicht von der genauen Fragestellung ab? Ich habe ja nicht gesagt, ob nur die externen Ports gemeint sind oder auch die innerhalb des Systems Kapselheber zwischen seinen Bausteinen? Sind nur die Ports für den bestimmungsgemäßen Gebrauch gemeint oder auch die, die bei Zweckentfremdung des Kapselhebers Anwendung finden (ich überlasse es Ihrer Fantasie, was man da so alles anstellen könnte).

Ok, dann konkretisiere ich: Es geht nur um die externen Ports die im Anwendungsfall "Flasche öffnen" benötigt werden.

Was halten sie von diesem Modell:

Ich komme also auf genau drei Ports. Klingt logisch, oder? Hm, nun vergleichen wir es mal mit einem originalen SysML-Diagramm. Da ein ganz konkretes Objekt gezeigt ist, handelt es sich um ein Objektdiagramm:

Ups! Es gibt im Objektdiagramm überhaupt keine Ports. Als ich das entdeckt hatte, glaubte ich zuerst an ein Versehen der UML-Autoren.

Bei genauerem Nachdenken allerdings wird klar: Zwei Objekte können unter Umständen interagieren. Wenn sie das tun, bilden sie ein Interaktionspaar.  In UML-Sprech sagt man dann, es gebe einen Link zwischen ihnen ¹. Letztlich dienen alle Strukturdiagramme dazu, die möglichen Links und die möglichen Interaktionen zu beschreiben. In bdds sind es Rollen und Assoziationen und in ibds Parts, Konnektoren, Ports und ihre Typen. Ganz konkret kann man mit Objektdiagrammen werden, da sie direkt Linkspezifikationen enthalten.

Erkenntnis: Ports sind Spezifkationselemente die in der Realität keine Entsprechung haben ². Real sind nur die Links.

Wenn nun in einem Objektdiagramm die Ports nicht dargestellt werden können, wie kann man dann aussagen, dass ein Link genau durch einen bestimmten Port spezifiert wird? Die Antwort auf diese Frage wirft ein ganz neues Licht auf den Zusammenhang zwischen Assoziationen und Ports.

Versuchen wir es erst einmal ohne Ports. Der Classifier eines Links ist eine Assoziation. Wir brauchen also Assoziationen:

Da es zwei verschiedene Links zwischen Flasche und Kapselheber gibt, benötigen wir auch zwei Assoziationen. Ich habe versucht sprechende Namen für die Rollen zu finden. Die Hand ist der Manipulator und der Kapselheber ist ein Deckeldrücker und gleichzeitig ein Zackenheber. Wir könnten natürlich den Aufbau des Kapselhebers darstellen - er enthält unter anderem eine Querstrebe und eine Zackenkante (oder wie auch immer das Teil offiziell heißt) - aber wenn das nicht nötig ist, reicht es die Rollen zu benennen.

Damit können wir das Objektdiagramm ergänzen:

So weit so gut. Diese Links sind jetzt allerdings unterspezifiziert. Da Hand und Kapselheber assoziiert sind, kann die Hand alle Interaktionen die der Kapselheber kennt auslösen. Zum Beispiel könnte sie Wärmeenergie oder elektrische Ladungsträger übertragen. Wenn er Nachrichten in Form von Operationsaufrufen oder Signalen verarbeiten könnte, kann die Hand das ebenfalls auslösen. Es ist unwahrscheinlich, dass das korrekt ist. Selbst bei einem einfachen System wie einem Kapselheber wollen wir genau festlegen, welche Interaktion über einen bestimmten Link erfolgt.

In diesem Fall ist es die Übertragung von Impuls (falls Sie Kraft erwartet hatten, Kraft ist das Potential Impuls zu übertragen). Dies kann mit einer Flow-Property p:momentum definiert werden. Des weiteren erfordern die Links eine Passung der Geometrien der verbundenen Teile. Die Geometrie selbst brauchen wir nicht, aber die Definition dass zwei Seiten zusammen passen. Dies geht mit Assoziationen zwischen Interface-Blöcken:

Es ist kein Zufall, dass die Namen der Interface-Blöcke und der Rollen an den Assoziationen identisch sind. Es geht hier ja um rollenspezifische Interfaces.

Das ibd sieht dann so aus:

Wie kann das jetzt im Objektdiagramm verwendet werden? Wie oben gezeigt, braucht man für die Links eine Assoziation zwischen echten Blöcken. Diese kann auch vererbt werden, also etwa so:

Da die Ports dann direkt von dem sie besitzenden Block realisiert werden, werden sie mit dem kleinen angehängten Rechteck als Verhaltensports gekennzeichnet. Damit sind wir am Ziel, das Objektdiagramm mit Ports sieht genauso aus, wie das Objektdiagramm oben.

Etwas anders sieht es aus, wenn wir die Struktur des Kapselhebers aufschlüsseln:

Das Objektdiagramm muss nun Links zu den Teilen des Kapselhebers haben. Direkte Links sind nicht möglich, was ja auch der Realität entspricht. Man kann nie mit einem System interagieren, immer nur mit seinen Bestandteilen (natürlich darf man in der Modellierung eine Vermischung zulassen (oder besser nicht?)).

Fazit: Ports dienen der Beschreibung von rollenspezifischen Schnittstellen. Sie entsprechen keinen realen Objekten. Die Jäger des verlorenen Ports folgen einem Irrlicht.

PS: Mir ist klar, dass es Modellierer gibt, für die Ports mehr sind, als ein Beschreibungselement für Links und die meinen Ausführungen nicht folgen werden. Ich habe lange über Ports nachgedacht und bin weiterhin dran - insofern ist das nur eine Momentaufnahme. Ich freue mich auf eine Diskussion.

---

1.  Genau genommen können Links auch einfach nicht interagierende Paare definieren. Wenn sie allerdings nicht interagieren frage ich mich, was dann ein Paar eigentlich ausmacht. Ich würde es so interpretieren, dass es schon eine Interaktion gibt, diese aber nicht modelliert wurde.↩

2. Dass Ports nur virtuell sind, gilt natürlich nur für Proxy-Ports. Und in der UML muss das sowieso noch differenzierter betrachtet werden.↩