2.2.1 Der Modellbegriff
Befragt man Menschen, was ein Modell sei, werden je nach pers¨onlichem Hintergrund verschiedene Antworten gegeben: maßstabsgetreue Nachbauten realer Gegenst¨ande, Vor-leben von Verhaltensweisen, vereinfachte Darstellungen komplexer Sachverhalte, Kon-struktionspl¨ane, usw.
Eine Systematisierung dieser sehr unterschiedlichen Meinungen bietet Herbert Stacho-wiak. Als Vorreiter der Modelltheorie ordnete er Modellen gemeinsame Eigenschaften zu, die er in seinem Standardwerk
”Allgemeine Modelltheorie“ [71] vorstellt. Dazu betrachtet
er Modelle als Abbilder der Wirklichkeit, die diese auf notwendige Weise verk¨urzen. Die genaue Auspr¨agung des Modells h¨angt dabei vom Modellierer und dessen Arbeitsgebiet ab, jedoch erf¨ullen die Modelle immer drei Merkmale:
1. Abbildung
(Jedes Modell ist eine Abbildung eines nat¨urlichen oder k¨unstlichen Originals.) 2. Verk¨urzung
(Ein Modell vereinfacht das Original. Es werden nicht alle Eigenschaften ¨ ubernom-men, nur diejenigen, die f¨ur den Modellnutzer relevant sind.)
3. Pragmatismus
(Modelle erf¨ullen ihre Ersatzfunktion hinsichtlich der, im betrachteten Fall, re-levanten Eigenschaften des Originals. Dabei kann ein Modell stellvertretend f¨ur verschiedene Originale stehen. Genauso kann es f¨ur ein Original mehrere Modelle geben, wobei jedes Modell einem anderen Zweck dient.)
Unter Ber¨ucksichtigung der Arbeiten von Stachowiak und im Kontext der modellge-triebenen Softwareentwicklung definiert K¨uhne in [47] ein Modell folgendermaßen:
Ein Modell ist eine Abstraktion eines (realen oder sprachbasierten) Systems, mit Hilfe dessen Vorhersagen oder R¨uckschl¨usse gezogen werden k¨onnen. [47]
Stachowiaks allgemeine Merkmale von Modellen bleiben erhalten, jedoch ist zu be-r¨ucksichtigen, dass sein
”Original“ K¨uhnes
”System“ entspricht. Es wird in der modell-getriebenen Softwareentwicklung als virtuelles Produkt und damit als fertige Software, betrachtet. Diese fertige Software kann wiederum als Modell angesehen werden, scharfe Grenzen zwischen Modell und System sind damit inexistent. Dementsprechend kann, innerhalb dieses Kontexts, Jean B´ezivin recht gegeben werden:
Alles ist ein Modell [13].
F¨ur den weiteren Verlauf dieses Dokuments ist B´ezivins Modelldefinition jedoch zu gene-ralisiert. Sofern der Begriff Modell im Folgenden verwendet wird, gilt K¨uhnes Definition des Modellbegriffs.
2.2.2 Klassifikation von Modellen in der
modellgetriebenen Softwareentwicklung
Zur Nutzung eines Modells in der modellgetriebenen Softwareentwicklung ist eine weitere Konkretisierung des Modellbegriffs n¨otig. Abbildung 2.1 zeigt Kriterien zur Klassifika-tion, die im Folgenden besprochen werden.
Das Modell als abstrahiertes System aufzufassen, ist bereits aus der Definition nach K¨uhne im vorangegangenen Abschnitt ersichtlich. Dabei erfasst das Modell entwe-der einen realen Sachverhalt oentwe-der die universellen Eigenschaften eines Systems.
Aspekt
Strukturmodell oder
Verhaltensmodell Abstrahiertes
System
Beschreibung
Modell Zweck
Ausführbarkeit TransͲ
formation
Verschiedene
Transformationsmöglichkeiten DeskriptivesModell oder
PräskriptivesModell EinModellabstrahiert
einSystem
AusführbaresModell oder
nichtausführbaresModell Beschreibungdurcheine
Modellierungssprache
Abbildung 2.1:Klassifikation von Modellen in der modellgetriebenen Softwareentwicklung
Der Aspekt, unter welchem ein System beschrieben wird, ist ebenfalls ausschlaggebend.
Dabei werden Strukturmodelle und Verhaltensmodelle unterschieden.
Strukturmodelle bilden die statischen Eigenschaften eines Softwaresystems ab. Sie definieren die Architektur der Software, indem die Elemente eines Systems und deren statische Beziehungen zueinander modelliert werden. H¨aufige Vertreter sind Klassendiagramme und Paketdiagramme.
Verhaltensmodelle bilden das dynamische Verhalten der Software ab. Dabei un-terscheidet man klassisch zwischen Ablauf- und Zustandsmodellen. Ablaufmodelle geben den zeitlichen Ablauf einer Systemver¨anderung an. Typische Beispiele sind Kommunikations- und Sequenzdiagramme der UML. Zustandsmodelle zeigen den Zustand eines Modells und gegebenenfalls dessen ¨Anderungen. Beispiel hierf¨ur sind Zustandsdiagramme der UML. Im Rahmen des ModGraph-Ansatzes werden zu-dem regelbasierte Modelle genutzt. Diese basieren auf Graphtransformationsregeln und stellen ein spezielles Zustandsmodell dar.
Der Zweck eines Modells beschreibt, ob es deskriptiver oder pr¨askriptiver Natur ist.
Deskriptive Modelle beschreiben ein existierendes System. Ein Beispiel hierf¨ur ist ein - zu Dokumentationszwecken - anhand einer existierenden Software erstelltes Klassendiagramm. Pr¨askriptive Modelle beschreiben ein zu erstellendes System, beispielsweise die zu erstellende Software. Dabei entsteht das Modell vor dem Pro-dukt. [47]
M3:Metametamodell
M2:Metamodell
instanziiert
M1:Modell
M0:Instanzen
instanziiert
instanziiert instanziiert
beschreibt
beschreibt
beschreibt
beschreibt
Abbildung 2.2:Metaebenen der OMG (analog zu [72])
Transformationen bieten eine M¨oglichkeit Modelle und Texte, die Modelle repr¨ asentie-ren, ineinander zu ¨uberf¨uhren. Sie werden in Kapitel 2.5 ausf¨uhrlicher besprochen.
Beschreibung und Ausf¨uhrbarkeit eines Modells sind eng miteinander verkn¨upft. Die Beschreibung eines Modells erfolgt mittels einer Modellierungssprache, deren Syn-tax wohldefiniert ist. Eine wohldefinierte Semantik der Sprache ist w¨unschenswert, jedoch nur zwingend, wenn das Modell ausgef¨uhrt werden soll. In Kapitel 2.3 wer-den die Modellierungssprachen, im Folgenwer-den kurz Sprachen genannt, n¨aher be-trachtet.
2.2.3 Metaebenen von Modellen
Eine weiteres Merkmal eines Modells, das bez¨uglich der Modellierung betrachtet werden muss, ist die Metaebene, auf der sich ein Modell befindet. Hier gilt:
Ein Modell von Modellen ist ein Metamodell. [47]
Das Metamodell definiert demnach die Konzepte, mittels derer die Modelle erstellt werden. Es beschreibt, welche Elemente in den instanziierenden Modellen vorkommen und wie diese miteinander in Beziehung stehen. Zus¨atzlich k¨onnen im Metamodell Be-dingungen definiert werden, die das Modell einzuhalten hat. Zusammenfassend ist der Zweck des Metamodells die zugeh¨origen Modelle konform zu halten. [72]
Durch die Metaebenen kann eine Modellhierarchie aufgebaut werden. Diese hierarchi-schen Beziehungen zwihierarchi-schen Modellen und deren Metamodell sind Instanz-Beziehungen.
Diesbez¨uglich hat die OMG Metaebenen f¨ur Modelle definiert, die in Abbildung 2.2 dar-gestellt sind. Referenzpunkt ist das Modell, aus welchem der Quelltext generiert wird.
Es wird mit M1 bezeichnet. Die Instanzebene M0, die reale Objekte repr¨asentiert, bildet die unterste Ebene. Diese Ebene wird auch Datenebene genannt und kann nicht weiter instanziiert werden. Die Instanzen M0 instanziieren ein Modell M1. M1 selbst ist eine Instanz seines Metamodells M2. Dies bedeutet, dass M2 die Konzepte vorgibt, die in M1 benutzt werden d¨urfen, um M0 zu beschreiben. Diese Konzepte sind Instanzen des Metamodells von M2, hier M3 genannt. Hier zeigt sich ein interessanter Fallstrick bei der Definition des Begriffs Metamodell: M2 nimmt einerseits die Rolle des Metamodells von M1 ein und ist gleichzeitig ein Modell von M3, hat also wiederum ein Metamodell. Der Begriff des Metamodells ist daher keinesfalls absolut zu verstehen. Genauso wenig darf er im Sinne einer Generalisierung verstanden werden. Das Modell instanziiert immer sein jeweiliges Metamodell: M1 ist Instanz von M2, M2 Instanz vom M3. Betrachtet man die Beziehung eines Modells zu dem Metamodell seines Metamodells, spricht man von dem Metametamodell des Modells. M3 ist das Metametamodell von M1.
Durch Hinzuf¨ugen weiterer Meta-Pr¨afixe ließe sich so eine beliebige Modellhierarchie aufbauen. Dabei kann diese theoretisch auf beliebiger (Meta-)Ebene begonnen werden.
In der Praxis ist es meist ¨ublich, nicht ¨uber die Metametaebene hinauszugehen. So ist M3 in sich selbst definiert. In einigen praktischen Anwendungen sind bereits drei Ebenen ausreichend. In diesem Fall wird eine Modellhierarchie aufgebaut, innerhalb derer sich das Metamodell M2 selbst definiert.
Prominente Beispiele der Selbstdefinition sind MOF und das bereits in der Einleitung erw¨ahnte Ecore [73]. Im Falle der Ecore-Definition handelt es sich um eine dreistufige Modellhierarchie: Ecore ist sein eigenes Metamodell, also in sich selbst definiert. Mo-delle sind Instanzen von Ecore, die wiederum instanziiert werden k¨onnen. Dies wird in Abschnitt 3.4 genauer betrachtet. Die OMG-Definition der Metaebenen wird in den folgenden Kapiteln genutzt.