UML2: Properties (Teil 6)

Der vorgehende Teil hat noch die Frage offengelassen, wo der Typ der Assoziation (also der AggregationKind) definiert wird. Die zunächst überraschende Antwort auf diese Frage: An der Property. Überraschend deshalb, weil die Vermutung naheliegt, dass der AggregationKind an der Assoziation liegt. An dieser Stelle kann jeder Leser sich überlegen, wie er oder sie die Assoziation modellieren würde. Bei mir sehen die Gedanken folgendermaßen aus:

Eine Assoziation verbindet Classifiers. Für gerichtete Assoziationen, sowie für Aggregationen und Kompositionen sind die Enden der Assoziation nicht gleichberechtigt, daher hätte ich die „memberEnd“-Assoziation zwischen „Association“ und „Property“ (siehe das Bild im vorigen Teil) als zwei separate Assoziationen modelliert (mit den Namen „source“ und „target“). Den Typ der Assoziation, also den AggregationKind, hätte ich dann direkt an die Association gehängt, durch die nicht-gleichberechtigten Enden ist dann eindeutig, welches Ende der „Teil“ und welches das „Ganze“ ist.

Warum ist im UML-Metamodell der AggregationKind für „Property“ definiert? In meinen Gedanken bin ich von der (falschen) Annahme ausgegangen, dass eine Assoziation nur zwei Enden haben kann. UML als Universalsprache erlaubt aber beliebig viele Enden für Assoziationen. Und damit funktioniert mein Ansatz mit verschiedenen Rollen für die Assoziationsenden nicht mehr. Mir stellt sich aber jetzt die Frage, ob sich der ganze Aufwand für die Unterstützung von Assoziationen mit mehr als zwei Enden lohnt. Das Metamodell erlaubt es nämlich, jedes Ende einer Assoziation als „Ganzes“ einer Teil-Ganzes-Beziehung zu modellieren, ein Widerspruch, den man durch Constraints im Metamodell verbieten muss. Da ich persönlich noch nie eine Assoziation mit mehr als zwei Enden modelliert habe, erscheint mir der Nachteil, ein Teil der Struktur der Metamodells in Constraints verlagern zu müssen, größer als der Vorteil, beliebig viele Enden zu unterstützen. Aber wie so oft ist das eine Abwägungssache.

Abschließend das detaillierte Metamodell von „Property“, diesmal mit dem AggregationKind.

Properties

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.