Was ist ein Metamodell?

von

Der Begriff des Metamodells

In einem früheren Blog-Artikel habe ich bereits einmal erklärt, was ein Datenmodell ist. Datenmodelle bilden die Grundlage fast jeder Software und definieren die Datenstrukturen, mit denen die Software umgeht.

Wenn man modelliert – zum Beispiel mit UML – entstehen auch Daten, nämlich die Modelle. Auch diese Modelldaten brauchen eine Definition über ihren Aufbau durch ein entsprechendes Datenmodell. Solch ein Datenmodell ist also ein Datenmodell eines Modells. Man kann auch sagen „Das Modell des Modells.“ Daher wird ein solches Datenmodell, welches die Datenstruktur der Modellierungssprache wie z.B. UML selbst definiert auch gerne als Metamodell bezeichnet.

Die Bezeichnung Meta stammt aus dem Griechischen und bedeutet „höher, jenseits oder über“ und wird oft verwendet, um eine höhere Ebene zu bezeichnen. Genau in diesem Sinne ist es auch bei den Metamodellen. Das Metamodell ist das Über-Modell des Modells selbst. Es definiert also die Datenstrukturen bzw. das Datenmodell welches genutzt wird um zum Beispiel Daten von UML-Modellen abzubilden oder zu speichern.

Metamodelle lassen sich mit Klassendiagrammen definieren

Da Metamodelle auch nur ganz normale Datenmodelle sind, können diese wie alle Datenmodelle mit Hilfe von Klassen spezifiziert und mit Hilfe der UML-Klassendiagramme dargestellt werden. Um Metamodelle zu erstellen, braucht man also UML-Klassendiagramme. Nun kann man diese Klassendiagramm-Notation ja auch wieder über ein Datenmodell spezifizieren. Dort ist dann zum Beispiel definiert, dass es ein Element „Klasse“ gibt und diese einen Namen haben kann.

Auch das kann mit einem Datenmodell abgebildet werden, also wiederrum mit einem Klassendiagramm. Ein solches Modell welches das Datenmodell für ein Metamodell selbst ist nennt man daher ein Meta-Metamodell – also eine Ebene höher.

Diese könnte unendlich so weiter gehen, es zeigt sich jedoch dass hier die Metaebenen enden, da man mit dem gleichen Datenmodell welches das Meta-Meta-Modell beschreibt auch sich selbst definieren kann. Daher haben wir hier eine Rekursion in der Spezifikation und die Metaebenen enden hier.

Abbildung 1: Die Metamodell-Hierarchie

In Abbildung 1 ist die Hierarchie der Modelle dargestellt. Die Ebene des Metamodells sowie des Meta-Metamodells besteht aus Klassen. Vom Meta- bzw. Datenmodell werden dann Instanzen gebildet in Form von Objekten. Diese können dann zum Beispiel nach JSON oder XML serialisiert werden.

Beispiel

Ich möchte nun konkret an einem Beispiel erklären, wie solche Modelle aussehen.

In Abbildung 2 ist ein einfaches Datenmodell gegeben, welches zum Beispiel einer Adressverwaltungssoftware zugrunde liegen könnte. Es besteht aus 3 Klassen, die Attribute enthalten. Außerdem sind weitere Attribute über die Kompositionsbeziehung modelliert. Das kursiv gedruckte Wort „Object“ rechts oben in den Klassen bedeutet außerdem, dass die Klassen von der Klasse Object per Vererbung abgeleitet sind.

Abbildung 2: Ein einfaches Datenmodell, dargestellt mit UML

Um nun ein Metamodell für dieses Diagramm selbst zu definieren, brauchen wir folgende Möglichkeiten:

  • Es muss ein Datentyp für die „Klasse“ geben
  • Dieser Datentyp muss einen Namen haben können
  • Es muss die Möglichkeit geben Attribute zu definieren – mit Name, Typ und Sichtbarkeit (z.B. public)
  • Außerdem muss es die Möglichkeit geben zu definieren, ob ein Attribut einfach vorkommt (Kardinalität 1) oder als Sammlung (Kardinalität *)

Der Meta Object Facility Standard der OMG

Die Object Management Group (OMG) definiert mit der Meta Object Facility (MOF) (MetaObject Facility | Object Management Group) einen Standard für eine Meta-Meta-Modellierungssprache. Also einer Möglichkeit genau solche Modelle wie in Abbildung 2 zu erstellen. Da es sich dabei auch um ein UML-Klassendiagramm handelt, decken sich viele Dinge in MOF auch mit der Spezifikation der UML-Klassendiagramme.

Wie in vielen der OMG-Standards werden auch hier wiederum Klassendiagramme verwendet, um den Standard selbst zu definieren. Wir haben es also auch hier mit einem Meta-Metamodell zu tun.

Die Klassendiagramme innerhalb von OMG-Standards nutzen oftmals das Konzept der Vererbung und auch das der Mehrfachvererbung recht exzessiv aus, um die Datenmodelle zu definieren. Dies erschwert mitunter die praktische Umsetzung der Standards, weil viele der modernen objektorientierten Programmiersprachen – darunter auch Java und C# aus guten Gründen keine Mehrfachvererbung zulassen. Stattdessen muss man hier mit Interfaces arbeiten, um das Gleiche zu erreichen.

Essential MOF

Der MOF-Standard definiert eine sogenannte Complete MOF (CMOF) und eine Essential MOF (EMOF). EMOF ist etwas reduziert, genügt aber so gut wie immer, um Metamodelle zu definieren. Daher möchte ich hier nun EMOF genauer zeigen.

Abbildung 3: Ein Klassenmodell aus dem EMOF-Standard der OMG

In Abbildung 3 ist ein Klassenmodell aus dem EMOF-Standard zu sehen. Man erkennt Mehrfachvererbungen zwischen der Klasse StructuralFeature und ihren Elternklassen. Außerdem sieht man einige abstrakte Klassen (erkennbar am kursiv gedruckten Klassenname). Solche Modelle sind typisch für OMG-Standards.

Doch wie kann man jetzt mit Hilfe von EMOF Datenmodelle modellieren?

Die Klasse Class repräsentiert eine Klasse eines Datenmodells. Die Klasse Property repräsentiert ein Attribut einer Klasse – ganz gleich, ob es sich um ein Attribut handelt, das als Textzeile in einem Klassenelement modelliert ist, oder ein Attribute, das mit Hilfe einer Kompositionsbeziehung modelliert wird.

Eine Vererbung kann mit Hilfe der superClass-Assoziation der Klasse Class ausgedrückt werden. Damit bietet EMOF alle Datemodellelemente an, die notwendig sind, um das Datenmodell der Addressverwaltung aus Abbildung aus Abbildung 2 datentechnisch abzubilden.

Eine EMOF-Umsetzung mit C#

Um EMOF praktisch nutzbar zu machen, habe ich ein EMOF-Datenmodell mit Hilfe von C# realisiert. Der Quellcode dafür ist hier zu finden (dev-Zweig): https://github.com/oalt/MDD4All.EMOF.DataModels/tree/dev

Abbildung 4: Die Klassen und Schnittstellen der EMOF-C#-Umsetzung

Das Klassendiagramm der EMOF-C#-Umsetzung ist in Abbildung 4 gegeben. Dieses Diagramm zeigt noch einige Elemente mehr als das OMG-Diagramm aus Abbildung 3, jedoch wird man auch hier entsprechende Übereinstimmungen finden.

Ein EMOF-Generator für C#-Datenmodelle

Mit Hilfe dieses EMOF-Datenmodells konnte ich nun ein kleines Werkzeug realisieren, welches aus beliebigen Datenmodellen, welche als C#-Code oder -Bibliothek vorliegen entsprechende EMOF-Objekte generiert. Realisiert wird dies per Reflection (https://learn.microsoft.com/en-us/dotnet/fundamentals/reflection/overview), um die Inhalte der C#-Datenmodellklassen abzufragen. Am Ende werden die Objekte nach JSON serialisiert und können dann ggfs. weiterverarbeitet werden.

Für das Datenmodell aus Abbildung 2 entsteht auf diese Weise folgender EMOF-JSON-Code:

Zusammenfassung

Metamodelle sind nichts anderes als die Datenmodelle von Modellen selbst. Um diese zu definieren, nutzt man die Elemente der Klassendiagramme. Auch diese bedürfen wiederum eines Datenmodells. Dies sind dann die Meta-Metamodelle.

Mit EMOF definiert die OMG einen Standard, um diese Klassenmodelle selbst zu definieren, damit man damit wiederum Metamodelle bzw. andere Datenmodelle erstellen kann.

In EMOF-Instanzen lassen sich beliebige Datenmodelle speichern und übertragen. Mit Hilfe von Reflection kann man aus C#-Datenmodellen EMOF erzeugen und aus diesem dann zum Beispiel wieder UML-Modelle. Die oben gezeigten Abbildungen von Klassen sind genau aus solchen EMOF-Modellen erzeugt worden – nach einer automatischen Modellgenerierung aus EMOF-Daten in Enterprise Architect. Sobald ich meine Ex- und Importer für EMOF etwas benutzerfreundlicher gestaltet habe – woran ich gerade arbeite – werde ich das in einem weiteren Beitrag berichten, damit auch andere Leute davon profitieren können.

Schreibe einen Kommentar