Archiv für den Monat: Juni 2011

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

UML2: Kompositionen und Assoziationen (Teil 5, Praxis)

Im UML-Metamodell werden Beziehungen zwischen Klassen als Assoziationen oder als Kompositionen modelliert. Verglichen mit dem Sprachumfang von UML fehlt im Metamodell die Aggregation. Jeder, der schon in einem Team Klassendiagramme diskutiert hat, hat wohl die Erfahrung gemacht, das der Typ einer Beziehung (der AggregationKind) stellenweise schwer festzulegen ist. Es gilt die folgende Semantik für AggregationKind:

  • „none“: Eine Beziehung zwischen „gleichberechtigten“ Partnern
  • „shared“: Eine Teil-Ganzes Beziehung (Aggregation)
  • „composite“: Eine Teil-Ganzes Beziehung, die enthaltende Klasse ist für Existenz und Speicherung der Teile verantwortlich (Komposition)

Naturgemäß ist eine Aggregation schwer von einer Komposition zu unterteilen, eine Komposition ist eine stärkere Bindung (durch die Existenzabhängigkeit). In der Praxis fangen aber genau hier die Diskussionen an. Die Frage, ob ein Teil einer Komposition nur vom Ganzen erzeugt werden darf, oder auch von außen übergeben werden darf, führt oft zu erbitterten Grabenkämpfen. Die ewige Frage „Komposition oder Aggregation“ löst Craig Larman rigoros und pragmatisch: Für ihn ist eine Aggregation ein Placebo ohne festgelegte Semantik, und soll daher nicht benutzt werden. Eine Lösung, die auch für das UML-Metamodell verwendet wurde (denn das UML-Metamodell besteht ausschließlich aus Assoziationen und Kompositionen). In der UML-Superstructure Specification wird das sehr gut durch folgendes Zitat ausgedrückt:
Precise semantics of shared aggregation varies by application area and modeler.

In UML bestehen Relationships nicht nur aus einer Instanz von „Association“, sondern es existieren Enden, die vom Typ „Property“ sind (siehe das Diagramm unten). Diese Enden können entweder einem Classifier gehören, oder sie gehören als „ownedEnd“ der Association. Das Metamodell erlaubt Beziehungen mit beliebig vielen Enden (genauer: mit 2..* Enden), in der Praxis haben die meisten Beziehungen zwei Enden. Eine Property kann eine „opposite“-Property referenzieren, dies ist über die derived-Beziehung „/opposite“ realisiert.

Im UML-Metamodell gibt es noch eine Spezialisierung von „Relationship“, die „DirectedRelationship“. Diese dient als Basisklasse für gerichtete Beziehungen, z.B. einem PackageImport.

Relationships in the Metamodel