Der Mythos Assoziation

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.

Die Assoziation ist ein merkwürdiges Modellelement. Und es gibt viele Mythen über sie. Denken Sie beispielsweise an die unzähligen Diskussionen über die Bedeutung und den Unterschied der Aggregation und Komposition. Aber wussten Sie, dass die Konzepte der Aggregation und Komposition gar nicht so viel mit der Assoziation zu tun haben?

Ich beabsichtige nicht, die Details der Assoziation in diesem Blogpost zu erläutern. Mein primäres Interesse ist es, sie loszuwerden. Na gut, es gibt durchaus Szenarien, in denen die Assoziation notwendig und nützlich ist. Aber sie ist nicht so wichtig, wie sie in Büchern und Publikationen über SysML (und UML) dargestellt wird.

Fangen wir vorne an und nun muss ich doch ein wenig das Konzept der Assoziation erläutern. Sie ist recht komplex. Betrachten Sie das folgende einfache Diagramm:

Zwei Blöcke und eine Assoziation zwischen A und B. Die meisten interpretieren dieses Diagramm so, dass Block A eine Eigenschaft namens „b“ mit Typ B hat. Das ist mehr oder weniger korrekt. Im Repository des Modells finden Sie zu diesem Diagramm 2 Blöcke, 1 Assoziation und 2 Eigenschaften. Unabhängig davon, ob die Assoziation einen Pfeil hat oder nicht, es sind immer zwei Eigenschaften im Modell. Mit Eigenschaft bezeichne ich übrigens das englische Property. Im Kontext der UML auch häufig Attribut genannt.

Wussten Sie, dass die Assoziation auch Eigenschaften besitzen darf? Ob die Assoziation oder der Block eine Eigenschaft besitzt, wird an der Assoziation durch den kleinen schwarzen Kreis am Ende der Assoziation angezeigt. Die meisten Modellierungswerkzeuge zeigen diesen Kreis nicht. Der schwarze Kreis zeigt an, dass die Eigenschaft dem gegenüberliegenden Block gehört. Wenn ein Assoziationsende keinen schwarzen Kreis hat, gehört die Eigenschaft der Assoziation. Interessanterweise wird der schwarze Kreis in der Modellierung mit UML sehr selten in der Praxis verwendet, obwohl der Modellierer in den meisten Fällen mit der Assoziationen Eigenschaften spezifizieren möchte, die einem Block bzw. Klasse und nicht der Assoziation gehören. Da diese Notation so selten verwendet wird und SysML den Anspruch hat, einfach zu sein, ist der schwarze Kreis in der SysML auch nicht erlaubt. Wer die Eigenschaft besitzt, wird in der SysML mit dem Navigationspfeil ausgedrückt. Aktuell gibt es ein Issue gegen die SysML, die Scharze-Kreis-Notation wieder zuzulassen.

Der folgende Screenshot von einem Modellierungswerkzeug zeigt die Modellelemente im Repository passend zum obigen Diagramm:

In dem Screenshot können Sie sehen, dass die Eigenschaft b dem Block A gehört. Die unbenannte Eigenschaft am anderen Assoziationsende ohne dem schwarzen Kreis gehört der Assoziation.

Ein paar mehr Merkwürdigkeiten zur Assoziation: zu Beginn dieses Beitrags habe ich erwähnt, dass die Assoziation nichts mit der Aggregation und der Komposition zu tun hat. Die Notation der Komposition zeigt das folgende Diagramm:

Die Eigenschaft b gehört weiterhin dem Block A. Die schwarze Raue an der linken Seite der Assoziation spezifiziert die Beziehung als Komposition. b ist ein Teil von A. Im vorherigen Diagramm ohne die schwarze Raute referenziert der Block A die Eigenschaft b, er besitzt sie aber nicht. Die Komposition ist eine Eigenschaft an der Eigenschaft b und ist nicht an der Assoziation definiert. Eine Eigenschaft in UML (und SysML) hat eine Eigenschaft namens aggregationKind, die die Werte none, share (=Aggregation) und composite (=Komposition) annehmen kann. In vielen Modellierungswerkzeugen wird die Aggregation und die Komposition als eigene Beziehung angeboten. Das sind aber nur Abkürzungen für Assoziationen, deren Eigenschaften an den Assoziationsenden entsprechende Werte für aggregationKind haben.

Es ist noch nicht merkwürdig genug, dass die Komposition bzw. Aggregation an der Assoziation angezeigt wird, sie werden auch noch an der gegenüberliegenden Seite von der betroffenen Eigenschaft dargestellt.

Zurück zu meiner Intention, dass ich die Assoziation loswerden möchte. Das primäre Ziel eine Assoziation zu modellieren ist in den meisten Fällen, eine Eigenschaft eines Blocks zu definieren. Aber wenn Sie eine Assoziation modellieren, definieren Sie, wie oben gesehen, zwei Eigenschaften. Typischerweise sind Sie aber nur an einer Eigenschaft interessiert. Und diese können Sie auch ohne die Assoziation anlegen. Zumindest in der UML. In der SysML gibt es da ein kleines Problem, wie Sie weiter unten sehen werden.

Unabhängig von SysML denkt ein Systems Engineer in Blockdiagrammen. Sie oder er skizziert das zu entwickelnde System in Diagrammen mit Blöcken, Schnittstellen und Verbindungen zwischen den Blöcken. In SysML ist das das interne Blockdiagramm mit Systemteilen, Ports und Konnektoren. Das Blockdefinitionsdiagramm mit seinen Blöcken und Assoziation scheint überflüssig zu sein. Zumindest für Systems Engineers, die als Hintergrund nicht Software Engineering haben. Ein Softwareentwickler wiederum ist es gewohnt, eher in Blockdefinitionsdiagrammen als in internen Blockdiagrammen zu denken.

In jedem Fall müssen Sie die Blöcke definieren. Aber Sie benötigen eigentlich meistens nicht die Assoziation. Stattdessen definieren Sie die Systemteile (Eigenschaften) ohne Assozaition. Ihr Modell hat dieselbe beabsichtigte Semantik, aber viel weniger Modellelemente, die sie verwalten müssen.

Sie können direkt im internen Blockdiagramm modellieren und definieren – sofern nicht bereits geschehen – die Blöcke in einem einfachen Blockdefinitionsdiagramm oder Tabellensicht. Das folgende Diagramm zeigt ein einfaches internes Blockdiagramm

Die Blöcke B und C, und A mit den Systemteilen sind im Blockdefinitionsdiagramm ohne Assoziationen definiert:

Im Repository befinden sich nur die Blöcke, die Eigenschaften, Konnektoren und ein Port, aber keine Assoziationen:

Sie brauchen die Assoziation hier nicht. Sie ist unnötiger Ballast. Sie sollten den Aufwand nur spendieren, wenn Sie sie auch wirklich benötigen, beispielsweise wenn Sie die grafische Sicht im Blockdefinitionsdiagramm brauchen.

Das Problem in der SysML ist, dass die SysML die Assoziation einfordert. Jede Eigenschaft, die als Typ einen Block hat, muss über eine Assoziation definiert werden. Ich kenne kein Modellierungswerkzeug, dass diese Regel erzwingt. So kann man sich bewusst darüber hinwegsetzen. Es gibt auch ein offizielles Issue für die SysML, die fordert, dass diese Einschränkung zukünftig aufgehoben wird.

Wie bereits vorher erwähnt, ist die Assoziation in manchen Kontexten wichtig. Beispielsweise im Anwendungsfalldiagramm. Die Beziehung zwischen Akteur und Anwendungsfall ist eine Assoziation. Oder im Fachwissenmodell um Blöcke der Domäne zu spezifizieren.

Generell sollten Sie bei der Modellierung immer darauf achten, dass Sie nur Dinge modellieren, die auch einen Wert im Entwicklungsprozess haben. Die Modellierung darf kein Selbstzweck sein. Es ist leicht, Dinge zu modellieren, aber es kostet Aufwand sie zu verwalten und bedarf explizite Pfade, um die modellierten Informationen auch zu nutzen.

Dieser Beitrag wurde zuerst in der englischen Version im MBSE Blog veröffentlicht: The Myth of the Association.