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.
Conjugation Considered Harmful!
Blog offline
Die SysML basiert ja auf der UML. Wie ich schon in einem anderen Post dargestellt habe, ist das auch eine gute Basis. Manche Konzepte der UML ergeben allerdings in der Welt der Systeme keinen Sinn und führen dann zu Stilblüten wie typisierten Gleichheitskonnektoren (engl. BindingConnector. Wieviele benutzerdefinierte Typen von Gleichheit gibt es?).
Eines dieser Konzepte ist die Möglichkeit Ports zu konjugieren. Sie erinnern sich, Ports sind Interaktionspunkte von Blöcken, über die sie im internen Blockdiagramm mit anderen Teilen des Systems verbunden werden können. Im Diagramm unten ist der Fuel Dispenser über Ports mit dem Tank verbunden.
Ports haben Typen und darüber kann festgestellt werden, ob zwei Ports sinnvoll miteinander verbunden werden können. Recht einfach kann man sich die Prüfung auf Kompatibilität machen, wenn beide Ports den gleichen Typ haben. Wobei Ports des gleichen Typs natürlich nicht direkt zusammen passen. Vielmehr müssen sie sich ergänzen: Was der eine einfordert, wie zum Beispiel die Operation isFull():Boolean, muss der andere anbieten. Will man auf beiden Seiten den gleichen Typ verwenden, muss der Typ auf der anderen Seite quasi umgekrempelt werden: Alle eingeforderten Merkmale müssen angeboten werden und umgekehrt. Genau das erledigt die Konjugation, dargestellt im Diagramm durch eine vorangestellte Tilde (~FuelpumpInterface).
So weit so gut. Das Problem beginnt, wenn man nun das Modell weiter entwickeln will. Irgendein Block muss ja die eingeforderten Merkmale am Ende wirklich anbieten. Dieser Block ist dann sinnvollerweise eine Spezialisierung des InterfaceBlocks. Dieser spezifiziert was angeboten werden muss und der implementierende Block beschreibt, wie dies geschieht.
Für den konjugierten Port gibt es diesen Typ nur virtuell. Und einen nicht vorhanden Block kann man nicht spezialisieren. Das muss kein Problem sein, schließlich kann man die Kompatibilität zwischen dem konjugierten Port und dem implementierenden Block auch durch den Vergleich jedes einzelnen Merkmals beweisen. Aber wünschenswert wäre es schon, eine formale Verbindung zwischen Block und zugehörigem InterfaceBlock zu haben.
Um einen Ausweg zu finden, sollte man sich nochmal anschauen, wie die Porttypen ursprünglich gedacht waren. Leider ist die UML-Spezifikation dabei nicht sehr hilfreich. In einer mir vorliegenden Mail hat Bran Selic, der Autor dieses Teils der Spezifikation, dargelegt, dass der Typ des Ports ein "system-definiertes" Objekt beschreibt, dessen Ausgestaltung nicht dem Modellierer zugänglich ist. Insofern ist es auch kein Problem, sich ein konjugiertes Objekt vorzustellen. Das ist dann halt ebenfalls ein "system-definiertes" Objekt.
Diese Vorgehensweise funktioniert aber in der SysML nicht. Hier reden wir davon dass die Ports abstrakte Stellvertreter für den eigentlichen, vom Modellierer erstellten konkreten Block sind (Proxy Ports).
Der natürliche Zusammenhang zwischen abstraktem Stellvertreter und konkretem Block ist die Spezialisierung. Also brauchen wir auf beiden Seiten eines Konnektors echte Typen. Diese Typen brauchen allerdings nur beschreiben, was der jeweilige spezialisierte Block anbieten muss. Was er selbst einfordert, muss er ja nicht implementieren, also braucht es auch nicht ein Merkmal des spezialisierten InterfaceBlocks sein. Wie kann man aber dann ausdrücken, dass ein InterfaceBlock bestimmte Merkmale einfordert? Nun, das Problem ist schon gelöst. In der SysML 1.2 nahm man dafür die Benutzungsbeziehung (Usage). Zwar wurde sie dort für UML-Interfaces verwendet (die in der SysML 1.3 in Ungnade gefallen sind), aber es spricht nichts dagegen, sie auch zwischen InterfaceBlöcken zu verwenden. Dann erhalten wir nebenstehendes Diagramm: Zwei InterfaceBlöcke die zwei Seiten einer Schnittstelle beschreiben. Daher habe ich ihnen den gleichen Namen gegeben und nur dem einen eine Tilde voran, dem anderen eine nachgestellt.
Auf diese Weise ist das Problem elegant gelöst. Es funktioniert mit bestehenden Mitteln und sieht übersichtlich aus.
Wie komme ich nun zu meinem provokanten Titel? Wenn man es nicht so löst, wie oben dargestellt, bleibt einem offenbar nur ein Monster von einem Konstrukt: Der Typ des konjugierten Ports muss entvirtualisiert werden, also zu einem echten Typ werden. Das ist entweder Arbeit für den Modellierer oder für das eingesetzte Tool. Der originale Typ und der konjugierte Typ sind bis auf wenige Eigenschaften (provided<-->required) gleich und müssen vom Tool synchron gehalten werden. Eine vierseitige OCL-Zusicherung muss sicherstellen, dass das auch formal definiert ist (siehe SysML-Issue SYSML16-132. Es wird mit Abstand die längste Zusicherung der Spezifikation sein). Wenn man einen solchen Aufwand treiben muss, um Gleichheit zu definieren – vielleicht ist es dann doch einfach in Wirklichkeit das selbe Element? Nur um die Konjugation zu behalten, wird die Sprache aufgebläht und die Bedeutung ihrer Elemente verwässert.
Meines Erachtens zeigt dieser ganze Aufwand, dass Konjugation ein für die SysML unpassendes Konzept ist. Was meinen Sie?
Anmerkungen: