Archiv der Kategorie: Metamodelle

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

UML2: Generalisierungen (Teil 4)

Nach dem vorangegangenen Artikel über die Struktur des Metamodells geht es in diesem Text um konkreten Inhalt, nämlich die Generalisierung. Zunächst ein Zitat aus der UML Superstructure Specification:
„A generalization is a taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus, the specific classifier inherits the features of the more general classifier.“
Das obige Zitat beinhaltet eine Referenz auf „features“, damit sind „StructuralFeatures“ und „BehavioralFeatures“ gemeint, also (vereinfacht ausgedrückt) Properties und Operationen.

Wie wird die Generalisierung im Metamodell modelliert? Das obige Zitat drückt bereits aus, dass die Generalisierung eine Beziehung zwischen „Classifiers“ ist. Daher liegt die Vermutung nahe, dass die Generalisierung wie in folgendem Diagramm modelliert ist:
too simple generalization
Während die Beziehung im obigen Diagramm ausreicht, um die Generalisierung zu realisieren, ist das Metamodell von UML doch etwas komplexer. Das hat den Hintergrund, dass im Metamodell schon abstrakte Klassen für Beziehungen aller Art beinhaltet (und die Generalisierung ist eine Beziehung zwischen Classifiers), und das Konzept von Beziehungen auch für die Generalization benutzt wird. Trotzdem ist das obige Diagramm korrekt, denn die Informationen über die „Parents“, also die generellen Classifiers, werden über eine „derived“-Beziehung (erkennbar an dem Slash „/“ für abgeleitete Properties) so abgebildet. Das bedeutet, dass die Generalisierung über die Klasse „Generalization“ modelliert wird, aber die Informationen gleichzeitig über die „general“-Property verfügbar sind.
Im folgenden Bild ist der Ausschnitt aus dem UML Metamodell, der Generalisierungen definiert, abgebildet:
Generalization for Classifiers

An dieser Stelle noch ein Verweis auf den Teil 1 des Metamodells, wo schon die Modellierung der Superklassen angedeutet wurde. Dort hat eine Klasse die Property „superClass“, die von der Generalisierung abgeleitet ist.

UML2: Struktur des Metamodells (Teil 3)

Im vorigen Artikel (UML2 Teil 2) wird ein Teil des UML-Metamodells, ausgehend von „Class“, beschrieben. Diese Vererbungshierarchie ist eigentlich recht intuitiv, wenn die verschiedenen abstrakten Klassen des Metamodells bekannt sind. Hier eine unvollständige Übersicht über verschiedene Klassen:
– Element
– NamedElement
– Namespace
– PackageableElement
– Package
– TypedElement
– Type
– RedefinableElement
– Classifier
– Class
– DataType
– PrimitiveType
– Enumeration
Das intuitive Herangehen an die Struktur des Metamodells besteht nun darin, eine Klasse herauszunehmen und mit den übrigen Klassen folgende Frage zu beantworten: „Ist die [herausgenommene Klasse] eine [übrige Klasse]“?
So zum Beispiel für den „PrimitiveType“ (in UML gibt es die primitiven Typen „Boolean“, „Integer“, „UnlimitedNatural“ und „String“): Ein „PrimitiveType“ ist allein dem Namen nach ein „Type“. Ob er jetzt direkt mit Type verbunden ist, oder indirekt, kann man jetzt noch nicht beantworten. Ein „PrimitiveType“ ist auch ein „DataType“ (da z.B. „Integer“ ein „DataType“ ist). Exkurs über „DataType“: Ein „DataType“ ähnelt einer „Class“, besitzt aber keine inherente Identität (alle Instanzen mit demselben Wert sind gleich).
Ist ein „PrimitiveType“ ein „Classifier“? Ein Classifier beschreibt eine Menge von Objekten, ein PrimitiveType repräsentiert ebenfalls eine Menge von Objekten, also ist ein PrimitiveType auch ein Classifier. Ist Classifier eine direkte Generalisierung von PrimitiveType? Das kann durch Untersuchung der bisher identifizierten SuperKlassen von PrimitiveType herausgefunden werden, also durch Beanwortung der Frage „Repräsentiert DataType eine Menge von Objekten“? Ja, ein DataType ist ebenfalls ein Classifier, also ist ein Classifier keine direkte Generalisierung von PrimitiveType, sondern von DataType.
Eine „Class“ beschreibt ebenfalls eine Menge von Objekten, also ist auch sie ein „Classifier“. Welche Generalisierungen von „Classifier“ gibt es? Ein „Classifier“ kann als „Type“ von Operationen oder Properties benutzt werden, daher ist ein „Type“ eine Generalisierung von „Classifier“. Ein „Namespace“ beinhaltet „NamedElements“, ein „Classifier“ kann „Properties“ beinhalten, also ist „Namespace“ eine Generalisierung von „Classifier“.
Ein „Classifier“ kann in einem Package liegen, also muss „Classifier“ ein „PackageableElement“ sein. Da ein „Type“ ebenfalls in einem Package liegen kann, und genereller als ein „Classifier“ ist, ist „PackageableElement“ eine direkte Generalisierung von „Type“.
Die positive Beantworung der Frage „Ist ein ‚Classifier‘ ein ‚PackageableElement‘?“ liefert einen Kandidaten für eine Generalisierung, durch Überprüfung der bereits identifizierten weiteren Kandidaten werden alle Metaklassen in eine relative Beziehung zueinander gesetzt. Den bildlichen „Nagel in der Wand“, an dem das Konstrukt aufgehängt wird, liefert dann das BasisElement von UML, die Metaklasse „Element“.
Abschließend eine Übersicht über die Generalisierungsbeziehungen im UML-Metamodell:

Struktur des UML Metamodells

UML2: Das Metamodell (Teil 2)

Als Fortsetzung der begonnenen Erklärung des Metamodells von UML, setzt dieser Text an der wohlbekannten Stelle der „Klasse“ die Serie fort.
Welche Merkmale besitzt eine Klasse? Sie hat einen Namen und liegt in einem Package. Zunächst der Name, ohne Kenntnisse des Metamodells liegt der Gedanke nahe, dass eine Klasse ein String-Attribut namens „name“ besitzt (wie im folgenden Bild dargestellt).

class with a name-property
Im UML-Metamodell besitzt die Klasse aber kein Attribut „name“, sondern erbt dieses von „NamedElement“.

inheritance of the name-property

Dieses Diagramm zeigt verschiedene Dinge: Erstens wird deutlich, dass das UML-Metamodell mit Mehrfachvererbung arbeitet (selbst das Meta-Metamodell benutzt Mehrfachvererbung). Zweitens ist eine Klasse gleichzeitig ein „Type“, Properties und andere TypedElements können also als Typ eine Klasse (genauer: die Instanz von „Class“ des Metamodells) haben. Drittens ist eine Klasse auch ein Namespace, sie kann also andere Elemente (zum Beispiel PackageableElements oder NamedElements) enthalten. Damit kann man innere Klassen, Properties, Operationen und vieles mehr in eine Klasse legen.

UML2: Das Metamodell (Teil 1)

UML besitzt, wie bereits in „Metamodelle anschaulich“ Teil 1 und Teil 2 beschrieben, ein Metamodell. Dieses Metamodell ist auf den Webseiten von OMG frei verfügbar. Wen interessiert das UML-Metamodell? Der Anwender von UML-Werkzeugen kommt nicht mit dem Metamodell in Kontakt, denn das Tool mit seinem eingebauten Metamodell gibt dem Benutzer gar keine andere Möglichkeit, als ein korrektes UML-Modell zu erstellen. Trotzdem ist meiner Meinung nach eine Kenntnis des UML-Metamodells für jeden Anwender von Vorteil, da die UML-Tools zum einen teilweise ein reduziertes UML-Modell verwenden, zum anderen aber auch bei einem guten UML-Werkzeug Kenntnisse der Semantik nötig sind. Zum Beispiel bei der Frage, welche Bedeutung die Beziehungsenden einer Assoziation besitzen, und wem sie „gehören“.

Es gibt noch weitere Gründe, das Metamodell anzuschauen. Bei Zeichnungen am Whiteboard liegt es nämlich beim Zeichner, ein valides UML-Modell zu erstellen. Während Klassendiagramme noch von den meisten Entwicklern beherrscht werden (abgesehen von Constraints und tenären Beziehungen), ist es relativ selten, ein korrektes dynamisches Diagramm an einer Wand zu erblicken. Die Ausrede, dass ein korrektes UML-Diagramm am Whiteboard gar nicht vonnöten ist, zählt auch nicht wirklich. Denn nur, wer die unterschiedlichen Möglichkeiten in den Interaktionen von Objekten kennt, kann auch ein sinnvolles Diagramm zeichnen. Und selbst, wenn man diese Möglichkeiten auch ohne UML-Erfahrung kennen kann, so ist die Benutzung von UML doch besser als die Erfindung einer eigenen, gleichwertigen Sprache.

Und schließlich gibt es noch UML-Zertifizierungen von OMG. Meiner Meinung nach sollte bei dieser Zertifizierung besser ein Beispielprojekt in UML modelliert werden. Da aber wahrscheinlich die Korrektur eines frei erstellen Modells zu aufwändig ist, besteht diese Zertifizierung aus Fragen zum Metamodell (eine Zertifizierung, wo ein Modell für ein Beispielprojekt erstellt werden muß, ist der „Sun certified Enterprise Architect“). Für die Prüfung sind tiefe Kenntnisse eines Teils des Metamodells erforderlich, und dafür muss die UML-Spezifikation durchgearbeitet werden.

Die UML-Infrastructure beginnt mit der Definition eines „Elements“. Das „Element“ ist der Baustein, auf dem alle anderen Klassen des Metamodells aufbauen. Leider ist es aber auch ein sehr unintuitiver Beginn einer Definition. Eine „Klasse“ ist den meisten Leuten viel geläufiger als ein abstraktes „Element“. Warum also nicht das Metamodell mit einer Klasse beginnen?

Eine Klasse ist ein „Classifier“. (Andere Classifier sind z.B. „DataType“, „PrimitiveType“ und „Enumeration“).

Metamodel of a class and classifier

Eine Klasse kann mehrere Superklassen haben. (Die „Generalization“-Beziehung wird später definiert).

a class has a superClass

Der Slash „/“ an dem Assoziationsende bedeutet „derived definition“. Die Information über die SuperKlassen kann also aus anderen Modellelementen (hier kommt wieder die Generalisierung ins Spiel) abgeleitet werden.

Damit endet der erste Teil, die Einführung wurde etwas ausschweifender als gedacht, in den nächsten Teilen kommt deutlich mehr vom UML-Metamodell.

UML in Farbe: UML colors

Bei der Programmierung von Anwendungen wird (in den meisten Sprachen) mit Klassen gearbeitet. Eine Person wird durch eine Klasse (oder zumindest durch eine Instanz dieser Klasse) repräsentiert. Eine Action, die eine Buchung durchführt, ist bei der Programmierung ebenfalls eine Klasse. Hinter Person und Buchung stehen aber völlig verschiedene Konzepte, eine Person ist mit Information verknüpft und etwas dauerhaftes (im Sinne von: „sollte in einer DB gespeichert werden“). Eine Buchung (damit ist jetzt kein Objekt gemeint, welches Buchungsinformationen darstellt, sondern etwas im Sinne einer Gui-Action oder einer Stateless SessionBean) ist etwas hochdynamisches, sie besitzt keine Identität und ist die in eine Klasse gepackte Business-Logik.
Es werden üblicherweise völlig unterschiedliche Konzepte in Klassen gepackt.

Nun stellt sich die Frage: Ist eine „Klasse“ genug, um diese verschiedenen Konzepte abzubilden?

Peter Coad hat in seinem Ansatz „UML colors“ diese Konzepttypen in vier Archetypen unterteilt:

  • PPTs (Party, Place or Thing): Objekte, die eine echte Identität besitzen
  • Description: Eine Beschreibung, die für eine Klasse von Objekten (also die Gesamtmenge der Instanzen) gilt
  • Role: Eine Rolle, mit der ein Objekt (ein PPT) an einer Interaktion teilnimmt
  • Moment-Interval: Etwas temporäres, kurzlebiges, zum Beispiel temporäre Objekte oder Interaktionsobjekte

Die vier Archetypen ordnen sich in typischer Weise an.  Da eine vollständige Beschreibung von Peter Coads Ansatz nicht Ziel dieses Eintrags ist, verweise ich an dieser Stelle auf diesen Bericht.
Meiner Meinung nach zeigt Peter Coads Konzept sehr gut, dass UML als universelle Modellierungssprache nicht auf spezielle Konstrukte Rücksicht nehmen kann. Peter Coad setzt mit der Markierung der Archetypen durch Stereotypen auf ein von UML bereitgestelltes Mittel, um die Sprache zu erweitern.

Eine andere Möglichkeit zur Unterstützung dieser Konstrukte ist eine Erweiterung des UML-Metamodells. Über einen Package-Merge können die vier Archetypen als Subklassen von „Class“ definiert werden, und dann als Instanzen in Modellen genutzt werden.

uml colors

Die Frage am Anfang war: Ist eine “Klasse” genug, um diese verschiedenen Konzepte abzubilden? Dieser Blog-Eintrag hat die Frage nicht beantwortet. Eine Anwendung kann aus „Klassen-Bausteinen“gebaut werden,  sie kann aber auch aus den vier „Archetyp-Bausteinen“ zusammengesetzt werden.

Der Einsatz von UML colors führt zu neuen Erkenntnissen, ich habe ihn in einem kleinen Projekt eingesetzt, nachdem zu dritt ein herkömmliches UML-Modell erstellt wurde. Unheimlich war, dass das Modell nach UML colors sich anders „anfühlte“, es war aber lückenlos und wurde dann später auch so als Modell der Anwendung  verwendet. Bei Gelegenheit werde ich einen Erfahrungsbericht zu „UML colors“ veröffentlichen.

Metamodelle anschaulich Teil 2: UML und Schach

UML ist nicht auf bestimmte Themengebiete zugeschnitten, sondern kann vielseitige Modelle darstellen. Statische Diagramme (z.B. Klassendiagramme) beschreiben Strukturen, dynamische Diagramme (z.B. Sequenzdiagramme) können zur Modellierung von Interaktionen verwendet werden.

Dank der Universalität von UML können auch Modelle von Sprachen erstellt werden (ein Gespräch besteht aus mehreren Sätzen, ein Satz besteht aus Wörtern,…). Und somit kann UML natürlich auch den gültigen Aufbau von UML-Modellen beschreiben. Oder, um wieder zum Beispiel des Schachspiels zurückzukehren, die Anleitung eines Schachspiels kann durch die Position von bestimmten Figuren codiert werden. Und zwar, das ist wichtig, von einer Teilmenge des Schachspiels (um den Aufbau von UML-Modellen zu beschreiben genügt auch eine Teilmenge von UML).

Ein Schachspiel kann also auch seine Anleitung beschreiben. Und diese Anleitung kann wiederum durch die Position von Figuren ihre Meta-Anleitung beschreiben.

An Board der Voyager-Raumsonden  hätte also auch ein Schachspiel mit auf bestimmte Art positionierten Figuren genügt.

Metamodelle anschaulich

Zusammen mit den Voyager-Raumsonden hat man auch Nachrichten an Außerirdische gesendet. Diese Nachrichten mussten verständlich für fremde Kulturen sein.

Nehmen wir an, es wäre auch ein Schachspiel an Bord gewesen. Ohne beiliegende Schachregeln könnte eine fremde Kultur das Schachspiel vielleicht als kulturelles Objekt, als Werkzeug oder vielleicht sogar als Spiel verwenden, allerdings bezweifele ich, dass dieses Spiel dann schachähnlich wäre. Das Schachspiel nützt also wenig ohne beiliegende Schachregeln.

Beim Schachspiel beginnt jeder Spieler einen Zug mit einer bestimmten Position der Figuren, und hat am Ende des Zugs die Figuren in eine neue Position gebracht. Die Schachregeln schreiben dann die möglichen Positionen vor. Sie sind das Metamodell des Schachspiels und beschreiben die gültigen Konstellationen der Figuren.

Nun stellt sich die Frage, in welche Form man die Spielregeln (das Metamodell) fasst. An Bord der Voyager wäre ein Buch in deutscher Sprache nicht optimal. Für Menschen wäre eine textuelle Beschreibung der Spielregen hilfreich, allerdings gibt es keine Universalsprache, die von allen Menschen gesprochen wird. Und will man die gültigen Konstellationen der Figuren von einem Computer überprüfen lassen, so müssen die Spielregeln maschinenlesbar sein.

Kurz zusammengefasst tritt folgendes Problem auf: Ein Schachspiel (Modell) benötigt auch eine Beschreibung, eine Anleitung (das Metamodell). Damit das Metamodell verständlich ist (für Menschen und Maschinen) muss es wiederum eine Anleitung für die Anleitung geben (das Metametamodell) und für diese auch wieder eine Anleitung. Also eine unendliche Verkettung von Anleitungen.

„Lies diese unendlich vielen Anleitungen, und dann spielen wir eine Partie Schach“ ist aber in Wirklichkeit keine gute Lösung. Eine nähere Betrachtung der Metamodell-Ketten zeigt aber, dass die Metamodelle zunehmend einfacher werden: Muss die erste Anleitung noch alle Spielregeln (oder alle möglichen Schachspiele) beschreiben, so muss die Meta-Anleitung nur noch die Anleitung definieren.

Ab einer bestimmten Metaebene (üblicherweise drei) ist eine Anleitung für Menschen intuitiv verständlich und Maschinen benötigen nur eine geringe Menge an Wissen, um die Anleitung zu interpretieren.

Ein Schachspiel und 3 einander erklärende Anleitungen an Board der Voyager-Raumsonden hätte die Kultur des Schachspiels universumweit verbreiten können.