Archiv für den Monat: März 2011

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.