Metamodellierung mit MOF und Ecore

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung im Rahmen des Seminars Ausgewählte Themen des Software Engineering Metamodellierung mit MOF und Ecore und deren Anwendung im Rahmen des MDA-Ansatzes Benedikt Uckat Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Christian Arndt Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Motivation für die Metamodellierung als integraler Bestandteil des Model-Driven Software Development Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture Das theoretische und begriffliche Fundament der Metamodellierung Die Grundlagen der Model Driven Architecture Meta Object Facility und Ecore als technische Umsetzung MOF als standardisiertes Meta-Metamodell Integration der Meta Object Facility in die MDA Metadatenaustausch über plattformspezifische Repositories MOF als Metadata Management Architecture Ausgewählte Aspekte der MOF 2.0 Spezifikation der OMG Die entwicklungsnahe Realisierung der MOF durch Ecore Das EMF-Framework Die Kernkonzepte des Ecore-Metamodells Integration von Ecore in EMF anhand eines Beispiels Fazit - kritische Beurteilung der MOF und Ecore im Rahmen des MDA-Ansatzes24 5 Literaturverzeichnis II

3 Kapitel 1: Motivation für die Metamodellierung als integraler Bestandteil des Model- Driven Software Development 1 Motivation für die Metamodellierung als integraler Bestandteil des Model-Driven Software Development Eine seit Anbeginn der Softwareentwicklung im Großen vorherrschende Problematik spiegelt sich in dem in der Literatur viel zitierten Terminus Software Krise wider. [vgl. u. a. Ba00, S. 26; Pe06, S. 9; Gr06, S. V] Der Einsatz von Software zur Unterstützung menschlichen Handelns hat sich rapide auf sämtliche Bereiche des gesellschaftlichen Lebens ausgeweitet. Software ist heute allgegenwärtig. Insbesondere im betriebswirtschaftlichen Kontext haben sich Softwaresysteme zu einem kritischen Erfolgsfaktor entwickelt. Sie sollen nicht nur den Wertschöpfungsprozess einzelner Unternehmen detailgetreu abbilden, sondern zunehmend auch zwischenbetriebliche Integration ermöglichen. Softwareprodukte müssen demnach zum einen immer leistungsfähiger und allumfassender werden, andererseits aber auch höheren Qualitäts- und Zuverlässigkeitsanforderungen genügen. Hinzu kommen Forderungen nach Kosteneffizienz und immer kürzeren Entwicklungszyklen, welche die Komplexität der Softwareentwicklung erhöhen. Diese divergierenden Erwartungshaltungen tragen dazu bei, dass weniger als die Hälfte aller Projekte gelingt. [vgl. SG03] Einen Ansatz zur Reduktion der Komplexität und zur ingenieursgemäßen Durchführung von Softwareprojekten bietet die modellgetriebene Softwareentwicklung (Model-Driven Software Development (MDSD)). Hier wird der formale und abstrakte Charakter von Modellen genutzt, um zunächst den jeweiligen Gegenstandsbereich, für welchen Softwaresysteme entwickelt werden sollen, möglichst exakt auf unterschiedlichen Detaillierungsebenen darzustellen. Darüber hinaus dienen diese Modelle der Generierung eines Großteils der Implementierung. [St05, S. 16] Notwendig für diese Art des Modelleinsatzes sind formal spezifizierte Modellierungssprachen, die es ermöglichen, die Problemdomäne adäquat abzubilden. Deren Konstruktion ist Aufgabe der Metamodellierung. Im Folgenden sollen zunächst die grundlegende Terminologie der Metamodellierung und deren Konzepte dargelegt werden. Im Anschluss wird die Model Driven Architecture (MDA) als ein zentrales Framework der modellgetriebenen Softwareentwicklung vorgestellt. Hierbei wird der Fokus auf die Anwendung der Konzepte der Metamodellierung innerhalb des Frameworks gelegt. Außerdem wird eine Einordnung der Meta Object Facility (MOF) in die Architektur vorgenommen. Diese Einordnung der MOF in 3

4 Kapitel 2: Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture die MDA, verbunden mit der Theorie der Metamodellierung, bildet die Grundlage für die detaillierte Darstellung der Funktionalitäten und der Spezifikation der MOF, welche den Schwerpunkt dieser Ausarbeitung bildet. Darauf folgt eine Beschreibung des Eclipse Modeling Frameworks und dessen Metamodells namens Ecore im Hinblick auf deren Beziehungen zur MOF und zum MDA-Ansatz. 2 Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture 2.1 Das theoretische und begriffliche Fundament der Metamodellierung Die Metamodellierung, von STRAHRINGER vereinfacht als modellorientierte Beschreibung von Softwareentwicklungsmethoden bezeichnet, stellt das zentrale Instrument der modellgetriebenen Softwareentwicklung dar. [St96, S. 1] Sie spezifiziert die Modellierungssprachen zur Konstruktion derjenigen Modelle, die in den einzelnen Phasen des Softwarelebenszyklus angewandt werden, wiederum in Form von Modellen. Die Terminologie dieses Themengebiets wird aber insbesondere in implementierungsnahen Schriften eher unreflektiert benutzt. So definieren die Architekten des Eclipse Modeling Frameworks (EMF) ein Metamodell simpel als Modell eines Modells mit dem Zusatz, dass eine weiterführende Durchdringung der abstrakten Konzeption nur von akademischem Interesse sei. [Bu04, S. 15] Die Konzepte der Metamodellierung sind aber grundlegend für die weiteren Ausführungen dieser Arbeit und sollen daher hier betrachtet werden. Zu jeder Phase der Entwicklung nimmt der Modellierer unterschiedliche Perspektiven auf das Softwaresystem ein und beschreibt den relevanten Ausschnitt mit dafür spezifizierten Modellierungssprachen. So wird ein Modell nach SCHÜTTE verstanden als Ergebnis einer Konstruktion eines Subjekts (des Modellierers), das für eine bestimmte Adressatengruppe (Modellnutzer) eine Repräsentation eines Originals zu einer Zeit als relevant mit Hilfe einer Sprache deklariert. [Be04, S. 65; Sc98, S. 59] Insbesondere der Aspekt der Sprache ist hier im Hinblick auf das Verständnis von Metamodellen von besonderem Interesse. Der Gegenstandsbereich wird mit Hilfe einer Modellierungssprache auf ein Modell abgebildet. Wird diese Modellierungssprache selbst Gegenstand der Untersuchung, so wird diese in Anlehnung an die Sprachstufentheorie als Objekt- 4

5 Kapitel 2: Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture sprache, das durch die Anwendung der Objektsprache entstandene Modell als Objektmodell bezeichnet. [St73, S. 217; St96, S. 18] Die Modellierungssprache, in der diese Untersuchung erfolgt, wird Metasprache genannt. Durch die Metasprache erfolgt die Untersuchung wiederum durch Konstruktion eines Modells, dem sprachbasierten Metamodell in Bezug auf das Objektmodell. Der Zusatz sprachbasiert gibt den Aspekt der Untersuchung des Objektmodells an, der durch das Metamodell erklärt wird. Er wird durch das Metaisierungsprinzip beschrieben. Bei der sprachbasierten Metaisierung dienen demnach Metamodelle der Darstellung von Modellierungssprachen, in denen Objektmodelle formuliert werden. [St98] Alternativ wird von prozessbasierter Metaisierung gesprochen, wenn das Metamodell den Prozess der Konstruktion des Objektmodells erklärt. Die prozessorientierte Metamodellierung ist für diese Arbeit aber nicht relevant und soll nur am Rande erwähnt sein. [vgl. hierzu Ho98, S. 14ff] Die Beziehung zwischen Meta- und Objektmodell bzw. Meta- und Objektsprache wird durch die Einführung von Metaebenen ausgedrückt. (vgl. Abb. 1) Ein Metamodell kann nie unabhängig, sondern nur in Bezug auf sein Objektmodell formuliert werden. Semantisch befindet es sich auf einer Metaebene, also auf einem Abstraktionsniveau, oberhalb des Objektmodells, welches es beschreibt. Dieses Schema kann rekursiv über beliebig viele Metaebenen fortgesetzt werden. So beschreibt das sprachbasierte Metamodell eines Metamodells die Modellierungssprache, die zur Formulierung des Metamodells genutzt wird. Dieses trägt, bezüglich des Modells auf unterster Abstraktionsebene, den Namen Meta-Metamodell. Wichtig ist, dass das Metaisierungsprinzip auf jeder Metaebene beibehalten wird. Der Bezug zwischen den Ebenen wird in der Softwaretechnik auch über den Begriff der Instanziierung hergestellt. Ein Modell instanziiert demnach ein Metamodell und das Metamodell ist seinerseits wieder Instanz eines Meta-Metamodells. Um zu verdeutlichen, welche Ebene Gegenstand der Diskussion ist, hat sich die Notation Mn, n {0,..., } als nützlich erwiesen. So bezeichnet M0 bspw. die Ebene des Objektsystems (z. B. ein Softwaresystem zur Laufzeit), M1 die Modellebene, M2 die Metamodellebene und M3 die Meta-Metamodellebene. 1 Diese als Modellhierarchie bezeichnete Strukturierung durch Metaebenen determiniert nicht, welche Modellierungssprache auf welcher Ebene Anwendung findet. Eine Modellierungssprache kann wiederholt auf unterschiedlichen Ebenen auftreten. Ihre Rolle als Objekt- oder Metasprache wird hierbei durch die Bezugssprache bzw. -ebene bestimmt. [St96, S ] 1 Der Zählweise ist in der Literatur unterschiedlich. Sie beginnt teilweise bei -1. [vgl. Ho98; De06] 5

6 Kapitel 2: Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture Die rekursive Deklaration von Objektmodellen durch Metamodelle auf der nächst höheren Metaebene findet durch den Mechanismus der Selbstdefinition ihre Beendigung. Ein Modell wird hierbei durch sich selbst erklärt, es ist sowohl Objekt- als auch Metamodell innerhalb einer Metaebene. Dieser Mechanismus lässt erkennen, dass die Strukturierung von Modellbeziehungen durch Metaebenen keineswegs strikt ist, sondern nur der Veranschaulichung und Übersichtlichkeit dient. [Fr03, S.108] Abbildung 1: Modellhierarchie der Metamodellierung (in Anlehnung an [St98; De06, S. 50]) 2.2 Die Grundlagen der Model Driven Architecture Die Model Driven Architecture (MDA) ist die zentrale Spezifikations-Architektur der modellgetriebenen Softwareentwicklung. Sie wurde von der Object Management Group (OMG), einem internationalen Industriekonsortium für Standardisierungen, spezifiziert. [OMG] Eine umfassende Beschreibung des MDA-Frameworks ist nicht Thema dieser Ausarbeitung. Vielmehr sollen die Kerninhalte dargelegt werden, um eine Einordnung der Metamodellierung, der Meta Object Facility (MOF) und Ecore in den Gesamtkontext der MDA zu ermöglichen. Die MDA setzt den Grundgedanken des MDSD um, nämlich Modelle zu Artefakten der Softwareentwicklung werden zu lassen, die formal so durch offene Standards spezifiziert sind, dass eine automatische Implementierung des Softwaresystems durch Modell- 6

7 Kapitel 2: Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture transformationen möglich ist. [Pe06, S.12] Hierzu müssen die Syntax und Semantik dieser Modelle eindeutig auswertbar, d.h. maschinenlesbar sein. Unter Syntax ist hier die Deklaration der Modellelemente und deren Beziehung untereinander zu verstehen. Die Semantik bestimmt, welche Bedeutung der Kombination dieser Modellelemente zukommt. [Gr06, S. 66] Das theoretische Gerüst zur Definition solch eindeutiger Formalmodelle liefert, wie oben beschrieben, die Metamodellierung. Sie findet Anwendung in allen Spezifikationen der MDA und ist somit als deren konzeptuelles Rückgrat zu verstehen. Die Architektur des Standards beschreibt Modelle innerhalb unterschiedlicher Spezifikationsdokumente, ihre Beziehung untereinander und ihren Gebrauch bei der modellorientierten Entwicklung von Software auf unterschiedlichen Ebenen der Abstraktion. [MDAG, S. 2-3] Das von der OMG erklärte zentrale Ziel des Frameworks ist es, Verbesserungen im Bereich der Portabilität und Interoperabilität von Softwareartefakten zu erreichen. Portabilität adressiert das Problem der Schnelllebigkeit von Plattformpopularitäten innerhalb der Softwareindustrie. Unter Plattformen werden im Kontext von MDA Ausführungsumgebungen für einen Satz von Modellen verstanden, die ihre Funktionen über Schnittstellen anbieten. Hierzu zählen Betriebssysteme (Unix, Windows, etc.), Programmiersprachen (Java, C++, C#) und Middleware-Technologien (CORBA, Java EE,.Net). [Gr06, S. 26] Diese Technologien wandeln sich mit rasanter Geschwindigkeit und werden ebenso schnell durch neue Technologien ersetzt, was zur Folge hat, dass die darauf ausgeführte Software ständig auf neue Technologien oder neuere Versionen alter Technologien portiert werden muss. Interoperabilität meint, dass die aktuellen komplexen Softwaresysteme nicht monolithischer Natur, sondern modular strukturiert sind, mit klar definierten Schnittstellen, um sowohl einen systeminternen als auch systemübergreifenden Datenaustausch der Teilsysteme auf heterogenen Plattformen zu ermöglichen. Diese Ziele sollen durch eine Trennung jeglicher fachkonzeptueller Überlegungen von technologieabhängigen Spezifika und implementierungstechnischen Details erreicht werden (separation of concerns) [MDAG, S. 2-2; Ze06, S. 60]. Hierzu wird eine Sichten-Architektur [zu Viewpoints siehe auch MDAG, S. 2-3] definiert, auf deren Ebenen unterschiedliche Modelle formuliert werden. (siehe Abb. 2) Auf der Ebene mit dem gröbsten Detaillierungsgrad wird das Computation Independent Model (CIM) (auch Business- oder Domain-Model genannt) konstruiert. Mit diesem werden Geschäftsprozesse und deren Umfeld fachkonzeptuell abgebildet, von Softwaresystemen und deren Implementierung wird abstrahiert. Jene Teile dieser Abbildung des Systems 7

8 Kapitel 2: Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture der Geschäftprozesse, die durch Softwaresysteme unterstützt werden sollen, werden auf dem darunter liegenden, feineren Detaillierungsniveau durch Platform Independent Models (PIM) dargestellt. [Kl03, S. 19] Hier werden die Aspekte des zu entwickelnden Anwendungssystems einbezogen und plattformunabhängig konzipiert. Aus dem PIM werden unter Berücksichtung plattformabhängiger Details automatisch ein oder mehrere Platform Specific Models (PSM) transformiert. Dieser Mechanismus der Transformation eines PIM zu einem oder mehreren PSM mit Hilfe von Werkzeugen (Transformatoren) stellt das Kernstück des MDA-Ansatzes dar. Der finale Schritt ist das wiederum werkzeugunterstützte Generieren von Code aus einem PSM. Dieses verläuft durch den implementierungsnahen Charakter des PSM sehr gradlinig. In der Literatur wird Code in diesem Kontext auch als weiteres PSM bzw. als Implementation Specific Model (ISM) bezeichnet. [Gr06, S. 67; Ze06, S. 62] Dies macht deutlich, dass die Klassifikation von Modellen in PIM bzw. PSM immer relativ zum jeweiligen Bezugsmodell vorzunehmen ist. Das PIM in Bezug zum generierten Code bzw. ISM ist ein PSM bezogen auf ein PIM, welches z.b. einen Teilaspekt des CIM darstellt. [Kl03, S. 22] Abbildung 2: MDA-Model-Stack und Transformations-Metamodell (nach [Gr06, S. 164; Kl03]) Unter einer Transformation wird die automatische Abbildung eines Quellmodells auf ein Zielmodell verstanden. [Kl03, S. 24] Hierfür sind Transformationsregeln notwendig, die präzise erklären, wie Elemente des Quellmodells auf Elemente des Zielmodells abgebildet werden. Dazu wird das Vokabular der Modellierungssprachen von Quell- und Zielmetamodell auf nächst höherer Abstraktionsebene in Beziehung zueinander gesetzt. Diese Beziehung wird über die Spezifikation der Meta Object Facility (MOF) erklärt, welche das gemeinsame Meta-Metamodell aller Metamodelle spezifiziert, die in der MDA Verwendung finden. Die Metamodelle von Quell- und Zielmodell sind MOF- 8

9 Kapitel 2: Konzeptuelle Grundlagen der Metamodellierung und deren Integration in die Model Driven Architecture konform, demzufolge werden ihre Modellelemente mit gleichen Meta-Metamodellelementen beschrieben und können über diese Gemeinsamkeit ineinander überführt werden. Eine vertiefende Betrachtung der Rolle der MOF in Bezug auf die metamodellorientierten Transformationsansätze 2 der MDA wird im folgenden Kapitel dargestellt. Eine Transformationsregel besteht aus einer Auswahl von Quellmodellelementen und einer Menge von Instruktionen, um diese Elemente in ein Zielmodell zu überführen. Die Menge der Transformationsregeln wird als Mapping bezeichnet. [Gr06, S. 163] Ein Mapping wird u. a. 3 durch Transformationssprachen implementiert. Einen Sprachstandard für solche Transformationssprachen soll die MOF Query/View/Transformation (QVT) Spezifikation bieten, die momentan den Status Final Adopted hat, sich also noch in der Entwicklung befindet. [OMG07] Sie spezifiziert eine komplexe Spracharchitektur aus deklarativen und imperativen Komponenten zur Durchführung MOFkonformer Model-to-Model Transformationen. [QVT07] Transformationen dienen unterschiedlichen Zwecken und können grob und ohne Anspruch auf Vollzähligkeit wie folgt typisiert werden. Eine PIM-to-PIM bzw. PSM-to- PSM Transformation auf gleichem Detaillierungsniveau dient einer plattformunabhängigen bzw. abhängigen Verfeinerung bzw. Erweiterung des Modells (refine). Eine PIM-to-PSM Transformation ist ebenfalls als Verfeinerung in Bezug auf das Modell der spezifischeren Ebene zu betrachten (vertikale Transformation). Eine vertikale Transformation in umgekehrter Richtung, PSM-to-PIM, dient der Abstraktion von irrelevanten Details des PSM, um z.b. die Übersichtlichkeit zu erhöhen. Eine PSM-to-PSM Transformation zwischen Modellen unterschiedlicher Plattformen (horizontale Transformation) ist bekannt als bridging und dient insbesondere dem Erreichen des oben beschriebenen Ziels der Interoperabilität. 2 Weitere Transformationsansätze sind z.b. marking-, pattern- oder template-orientiert [vgl. Pe06, S.131f] 3 Weitere Möglichkeiten bieten bspw. der Einsatz von Skriptsprachen oder universelle Programmiersprachen [Gr06,S. 164ff] 9

10 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung 3 Meta Object Facility und Ecore als technische Umsetzung 3.1 MOF als standardisiertes Meta-Metamodell Integration der Meta Object Facility in die MDA Die Architektur der MDA ist in dem Bewusstsein entstanden, dass in der Industrie unterschiedliche Komponenten von Softwaresystemen in deren Entwicklung mit spezialisierten Sprachkonstrukten formuliert werden (Domain-Specific-Languages (DSL) [St05, S.16]). Eine Einheitssprache ist nicht zweckmäßig. Relationale Datenmodelle enthalten bspw. Konstrukte wie Tabellen, Spalten und Schlüsselattribute, während objektorientierte Entwürfe besser durch UML-Klassendiagramme dargestellt werden können. Wie bereits erwähnt (vgl. Kapitel 2.2), braucht jede Modellierungssprache eine formale Definition von Syntax und Semantik, um eine automatisierte Transformation durch Werkzeuge zu ermöglichen. Diese wird durch Metamodelle realisiert. Die Meta Object Facility Spezifikation der OMG, die am in der Version 2.0 erschien, erweitert dieses Konzept um eine Dimension. Sie definiert das plattformunabhängige Metamodell aller Metamodelle der in der MDA verwendeten Modellierungssprachen. Die Bedeutung dieser Standardisierung der Meta-Metamodellelemente, mit denen Metamodelle deklariert werden, macht folgende Aussage deutlich. Any modeling language used in MDA must be described in terms of the MOF language, to enable the metadata to be understood in a standard manner, which is a precondition for any ability to perform automated transformations. [OR04] Zwei Designziele der MOF sind vorherrschend. Zum einen sollen Sprachkonstrukte bereitgestellt werden, welche die Definition von neuen und die Erweiterung bestehender Metamodelle ermöglichen, um Modellierungssprachen für spezielle Anwendungsdomänen anzupassen. Zum anderen sollen die Verwaltung und der Austausch von Metadaten durch Werkzeuge standardisiert werden. Dieser Aspekt wird im folgenden Kapitel betrachtet. Die Sprachkonstrukte der MOF zur Beschreibung von Metamodellen entstammen dem Sprachkern der Unified Modeling Language (UML 2.0), dem bekanntesten Standard der OMG. Die UML bildet eine Sammlung von Modellierungssprachen, die auf unterschiedlichen Detaillierungsebenen der MDA eingesetzt werden (vgl. ISM, PSM, PIM, CIM in Kapitel 2.2). Eine Struktur in das komplexe Geflecht interdependenter Spezifikationen bringt die Four-Layer-Architecture der OMG, auch MOF-Architecture genannt, die sich an die in Kapitel 2.1 beschriebene Modellhierarchie anlehnt. Die MOF 10

11 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung befindet sich hier auf der M3-Ebene, sie deklariert das Metamodell aller darunter liegenden Metamodelle, das sog. MOF-Model. Die Beziehung zwischen den Metaebenen macht Abbildung 3 deutlich. Zwei von der OMG spezifizierte Metamodelle sind das UML-Metamodell und das Common Warehouse Metamodell (CWM). [CWM01, S. 210] Letzteres dient der Beschreibung von Datenstrukturen und kann als Referenzmodell für Data-Warehouse-Metadaten betrachtet werden. [Ze06, S. 79] Jedes Element des UML-Metamodells ist eine Instanz eines Elements des MOF-Model, ebenso jedes Element des CWM-Metamodells. Der vereinfachte Ausschnitt des MOF-Model definiert Klassen, Attribute, Generalisierungshierarchien, Assoziationen und deren Beziehungen und Abhängigkeiten untereinander. Die Instanzen der MOF-Elemente auf der M2- Ebene definieren die Konstrukte, die zur Modellierung der Modelle auf der M1-Ebene genutzt werden. Für die Modellierung von Datenbank-Schemata werden bspw. Tabellen als Modellelemente gebraucht, welche mindestens eine Spalte enthalten. Sowohl Tabellen als auch Spalten sind über das Attribut name benannt. Die UML unterscheidet die Instanz von -Beziehung zwischen zwei Metaebenen von Instanzbeziehungen zwischen Modellen innerhalb der M1-Ebene (deklariert durch die Klasse InstanceSpecification [INF07, S. 53]), welche in Form von Objektdiagrammen dargestellt werden. [Ba00, S. 159] Diese Objektdiagramme sind Modelle eines Systems zur Laufzeit im Unterschied zu wirklichen Realisierungen der Modelle in Laufzeitumgebungen, welche die M0-Ebene repräsentiert. Sie stellen also eine Momentaufnahme (snapshot) des laufenden Systems dar, nicht aber das laufende System. Daher befinden sich Objektdiagramme auf der M1-Ebene. [INF07, S.19] 11

12 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung Abbildung 3: MOF-Architecture (nach [MOF06, S. 47; INF07, S. 19; CWM01, S.210]) Die Abbildung zeigt außerdem die Bedeutung der MOF für Werkzeuge, die Transformationen unterstützen. Beide Modelle stellen den gleichen Sachverhalt dar, das UML- Modell aus der Perspektive der Objektorientierung, das CWM-Modell aus Sicht der Datenbankkonstruktion. Beide Modelle enthalten keine implementierungstechnischen Details, gehören demnach zu den Platform Independent Models. Mit dem Umweg über die MOF können die Elemente der Metamodelle einander zugeordnet werden. Eine UML-Metaklasse ist eine Instanz der MOF-Klasse, ebenso wie das Metaelement Table des CWM. Eine Transformationsregel muss diese Beziehung abbilden, um eine automatische Überführung des Elements UML::Class in das Element CWM::Table zu ermöglichen. Die Transformationsregel ist dann unabhängig von Modellen, die auf der M1-Ebene konstruiert werden, sie kann demnach wieder verwendet werden. Eine solche Transformation ist ein Beispiel für eine PIM-to-PIM-Bridge. Ein semantisch sehr weit reichender Aspekt der MOF ist der Mechanismus der Selbstbeschreibung. MOF definiert die eigenen Sprachkonstrukte durch ein MOF-konformes Modell, das bereits erwähnte MOF-Model. Das MOF-Model ist demnach nicht nur das Metamodell der Metamodelle der M2-Ebene, sondern auch das Metamodell der MOF selbst. [Fr03, S. 108] Erreicht wird dies durch das Paket Reflection, das in Kapitel erläutert wird. Des Weiteren zeigt die Selbstdefinition der MOF innerhalb einer Metaebene (der M3) erneut, dass die Trennung dieser Ebenen rein künstlich ist, eine Maß- 12

13 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung nahme zur Schaffung von Übersichtlichkeit. Das fundamentale Konzept ist die Instanzbeziehung zwischen Objekt und Klasse bzw. Modellelement und Metamodellelement. Damit lassen sich beliebig viele Ebenen erzeugen. [MOF06, S. 8f] In der Regel werden im Rahmen der Softwareentwicklung keine neuen Sprachen von Grund auf mit Sprachkonstrukten der MOF definiert, vielmehr werden bestehende Sprachen, z.b. aus der UML-Sprachfamilie, für eine bestimmte Domäne erweitert. Solch eine Erweiterung von Modellierungssprachen kann im Rahmen der MDA auf zwei Arten erfolgen, durch eine Veränderung des Metamodells mit Methoden der Metamodellierung (Schwergewichtige Erweiterung) oder durch das Erstellen von Profilen mit Stereotypen (Leichtgewichtige Erweiterung). Bei der schwergewichtigen Erweiterung des Metamodells werden neue Metamodellelemente auf der M2-Ebene durch Sprachelemente der MOF definiert, zum Beispiel durch die Generalisierung. In Abbildung 4 wird die UML-Metaklasse Class durch eine neue Unterklasse Entity verfeinert, die nicht Bestandteil des UML-Standards ist, sie ist dennoch eine Metaklasse auf der M2-Ebene. Das UML-Metamodell wird verändert, es handelt sich somit nicht mehr um das von der OMG standardisierte UML-Metamodell. Bei der leichtgewichtigen Erweiterung durch Profile wird das UML-Metamodell nicht verändert, sondern es stellt selbst einen Mechanismus bereit, um ein domänenspezifisches Konstrukt als so genannten Stereotyp eines Metamodellelements zu deklarieren. Ein Profil ist die Verfeinerung eines UML-Package, in dem die Metaklassen mit den Stereotypen, die sie erweitern, über einen Extension-Pfeil zueinander in Beziehung gesetzt werden. So können Modelle der M1-Ebene mit technologischen Details ausgestattet werden (vgl. PSM), die für die automatische Transformation von Bedeutung sind. 4 Eine mit dem Stereotypen <<EnterpriseJavaBean>> markierte Klasse kann zum Beispiel durch einen Model-to- Code Transformator in Code der Java EE-Komponente überführt werden. Die leichtgewichtige Erweiterung wird von vielen UML-Werkzeugen wie z. B. Magic Draw unterstützt, [NoM] da es im Gegensatz zur schwergewichtigen Erweiterung nicht notwendig ist, das UML-Metamodell für Veränderungen zugängig zu machen. 4 Weitere Erläuterungen zu Profiles können im Rahmen dieser Ausarbeitung aufgrund des begrenzten Umfangs nicht gegeben werden, sie finden sich aber u. a. bei [SUP07, S. 649ff; Bo04, S.245f] 13

14 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung Abbildung 4: Schwer- und leichtgewichtige Erweiterung des UML-Metamodells (nach [INF07, S. 49; SUP07; S. 652; Pe06 S. 75ff]) Metadatenaustausch über plattformspezifische Repositories MOF als Metadata Management Architecture Im Verlauf der Softwareentwicklung werden vielfältige Modelle erstellt, die für die Unternehmung einen großen Wert darstellen, da sie Wissen über Geschäftsprozesse oder Implementierungsdetails in einer für Menschen lesbareren Form darstellen, als dies bei reinem Code der Fall ist. Diese Modellartefakte werden als Metadaten bezeichnet. [Fr03, S.110] Sie müssen persistiert und außerdem zwischen einzelnen Werkzeugen ausgetauscht werden können. Innerhalb der MDA werden in unterschiedlichen Entwicklungsphasen spezialisierte Werkzeuge benutzt, man spricht auch von Werkzeugketten. [Pe06, S. 83] Ein hohes Maß an Interoperabilität ist daher das zentrale Designziel der MDA (vgl. 2.2). Obwohl die MOF plattformunabhängig definiert ist, unterstützt sie dies, indem sie technologieabhängige Mappings spezifiziert. Die Verwaltung der unterschiedlichen Metadaten geschieht durch MOF-Repositories, auf welche über Schnittstellen zugegriffen wird. (vgl. Abb. 5) Die Form der physikalischen Speicherung (in Datenbanken wie Oracle oder DB2, XML-Dateien, etc.) ist dabei nicht vom MOF-Standard festgelegt, sondern eine Designentscheidung bei der Entwicklung des Repository-Werkzeugs. 5 MOF definiert in eigenständigen Spezifikationen, wie die abstrakte und plattformunabhängige Syntax von MOF-konformen Metamodellen auf technologieabhängige Objekte abgebildet wird. Die Java Metadata Inter- 5 Ein Beispiel für ein MOF-Repository, dass sowohl JMI als auch den Import/Export über XMI implementiert, ist das Metadata Repository Project (MDR) von Netbeans [Ne] 14

15 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung face (JMI) Spezifikation [JMI02] definiert so ein Mapping, das Elemente von Metamodellen auf die Programmiersprache Java abbildet. Das Resultat der Anwendung von JMI auf das UML-Metamodell ist bspw. eine Beschreibung, wie UML-Metadaten durch Java-Objekte repräsentiert werden. Das Repository Werkzeug, welches diesen Standard implementiert, stellt Schnittstellen (APIs) bereit, über die Metadaten mit Java im Repository abgelegt, verändert oder gelesen werden können. Den standardisierten Austausch von Metadaten zwischen verschiedenen Werkzeugen mit proprietären Verarbeitungsformaten ermöglicht die XML Metadata Interchange (XMI) Spezifikation [XMI05]. Sie bildet MOF-konforme Metamodellelemente auf das Dateiformat XML ab. Das Ergebnis der Anwendung des Mappings auf das UML-Metamodell ist eine Serialisierung des Modells in Form eines XML-Schemas (XSD) oder einer Document Type Definition (DTD). Außerdem werden Regeln zur Serialisierung von Modellen in XMI- Dateien spezifiziert. Modelle können so in Form von XMI-Dateien zwischen Werkzeugen und Repositories ausgetauscht und beim Import über XML-Parser gegen das XML- Schema/die DTD des Metamodells validiert werden. (zu XML-Schemata bzw. DTD und Validierung siehe auch [W3C; Vo04, S ]) Abbildung 5: Metadatenaustausch zwischen Werkzeugen und Repositories (nach [Fr03, S.116; Pe06, S.85]) Ausgewählte Aspekte der MOF 2.0 Spezifikation der OMG Das MOF-Model ist durch die Notation beschrieben, die in Klassendiagrammen der UML Verwendung findet, auch das UML-Metamodell ist durch diese Notation erklärt. Der Grund dafür ist, dass beide Modelle einen gemeinsamen Kern von Sprachkonstrukten wieder verwenden. Damit wird ein primäres Designziel der MOF erreicht, 15

16 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung nämlich die Definition und Erweiterung von Metamodellen durch einen modularen Aufbau und Wiederverwendungsmechanismen zu vereinfachen. Der modulare Aufbau wird über Pakete realisiert, in denen Modellkonstrukte nach funktionalen und logischen Aspekten gruppiert sind. (vgl. Abb. 6) Dieser Ansatz wird in der MOF-Spezifikation als komponentenbasierte Modellierung bezeichnet. [MOF06, S. 6] Die Modellkonstrukte können über die Mechanismen PackageImport und PackageMerge in andere Pakete importiert und erweitert werden. (vgl. hierzu [INF07, S. 157]). Der angesprochene gemeinsame Kern von UML und MOF ist im Paket InfrastructureLibrary erklärt. [INF07, S. 27] Dieses in der UML-Infrastructure-Spezifikation deklarierte Paket enthält u. a. das Unterpaket Core, welches die Basiselemente sowohl der UML-Superstructure- als auch der MOF-Spezifikation bereitstellt. Das Paket wird also sowohl auf der M3- als auch auf der M2-Ebene wieder verwendet, ein Umstand, der einige Verwirrung bei der Unterscheidung zwischen dem Meta-Metamodell der MOF, also dem MOF-Model, und dem UML-Metamodell stiftet. [St05, S. 374] Eine in der InfrastructureLibrary deklarierte Meta-Metaklasse ist demnach Instanz ihrer selbst, eine Tatsache, die den Mechanismus der Selbstbeschreibung verdeutlicht. [Pe06, S. 80] Das MOF-Model ist unterteilt in zwei Pakete, Essential MOF (EMOF) und Complete MOF (CMOF), die unterschiedliche Konformitätsebenen deklarieren. [MOF06, S. 29] EMOF bildet den essentiellen Kern des MOF-Model und liefert damit eine Möglichkeit, einfache Metamodelle mit einer übersichtlichen Zahl von Modellelementen zu formulieren. [MOF06, S. 31] Dazu vereinigt EMOF die Unterpakete PrimitiveTypes und Basic des Core-Pakets der InfrastructureLibrary, welche eine minimale klassenbasierte Modellierungssprache bereitstellen [INF07, S. 89], mit den Paketen Reflection, Identifiers und Extension der MOF-Spezifikation. Letztere stellen Zusatzfunktionalitäten, sog. Capabilities, für die Modellelemente bereit (s. u.). In Core::Basic ist bspw. definiert, dass Klassen Attribute und Operationen enthalten können und Generalisierungshierarchien zwischen ihnen bestehen (vgl. Abb. 3 und 4). In CMOF ist das MOF-Model vollständig erklärt. Es vereinigt das EMOF-Paket mit dem Paket Core::Constructs der InfrastructureLibrary, in dem komplexere Metamodellkonstrukte als in Core::Basic erklärt werden. In Core::Constructs, welches das Core::Basic Paket erweitert, werden z.b. alle Assoziationsmöglichkeiten sowie die Erweiterungsmechanismen PackageMerge und PackageImport erklärt. Die Zusatzfunktionalitäten der MOF werden ebenso in den Paketen CMOFExtension und CMOFReflection erweitert und in CMOF eingebracht. Durch CMOF wird bspw. das UML-Metamodell definiert. 16

17 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung EMOF wird durch EMOF selbst definiert, allerdings werden dafür die Wiederverwendungsmechanismen aus CMOF bzw. Core::Constructs gebraucht. CMOF ist auch selbstbeschreibend und Grundlage jeglicher Metamodelle der OMG. Dies erklärt, warum jenseits von M3 keine weitere Ebene gebraucht wird. [MOF06, S. 11] Alle Modellelemente des MOF-Model werden durch zusätzliche Funktionen angereichert. Das Paket Reflection erweitert Modellelemente um die Funktionalität, selbstbeschreibend zu sein. [MOF06, S. 13] Hierzu werden für das Modellelement Element, welches Superklasse jedes Modellelements der MOF ist, Operationen definiert, die es ermöglichen die Metaklasse des Elements zur Laufzeit zu bestimmen, um so eine reflektive Beschreibung des Elements zu erhalten. [MOF06, S. 15] Der Mechanismus ähnelt der Funktionalität reflektiver Programmiersprachen wie Java. Über das Paket Identifiers wird jedem Modellelement ein eindeutiger Bezeichner zugewiesen. Diese Identität ist mit der Objektidentität objektorientierter Programmiersprachen vergleichbar und ermöglicht zum Beispiel die Rückverfolgung eines Objekts nach mehreren Transformationen. [MOF06, S. 21] Das Paket Extensions unterstützt die Informationsanreicherung von Elementen durch Annotationen in Form von Tags. Tags sind Tupel aus einem Bezeichner und einem Wert. Die Tagged Values in Modellen der UML sind bspw. durch diesen Mechanismus erklärt. InfrastructureLibrary::Core PrimitiveTypes <<import>> Basic <<import>> Constructs <<merge>> UML::Superstructure <<import>> <<merge>> <<import>> <<merge>> MOF EMOF <<merge>> CMOF Extension <<merge>> <<merge>> <<merge>> Identifiers <<merge>> <<merge>> CMOFExtension CMOFReflection Reflection Abbildung 6: Der modulare Aufbau der MOF (nach [MOF06, S. 45; INF07, S.15]) 17

18 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung 3.2 Die entwicklungsnahe Realisierung der MOF durch Ecore Das EMF-Framework Das Eclipse Modeling Framework (EMF) ist ein als Plug-In konzipiertes Werkzeug der Eclipse Entwicklungsumgebung zur Modellierung und Codegenerierung. [EMFa] Das EMF-Projekt wurde von IBM mit dem Ziel initiiert, die Meta Object Facility zu implementieren, es ist somit Bestandteil des MDA-Ansatzes. [Mo04, S. 4] Die Bezeichnung des Frameworks durch dessen Entwickler als MDA auf Stützrädern 6 illustriert allerdings, dass nicht alle komplexen Aspekte der MOF sofort umgesetzt werden konnten. Man konzentrierte sich stattdessen auf die Zusammenführung der Technologien UML, XML und Java. Nicht die plattformunabhängige Modellierung von verteilten, heterogenen Systemen auf unterschiedlichen Detaillierungsebenen stand beim Design des Frameworks im Vordergrund, sondern das Generieren von Java-Code aus Formalmodellen. EMF verbindet Modellierungskonzepte direkt mit deren Implementierung und erreicht damit, die Möglichkeiten der Modellierung für Java-Entwickler nutzbar zu machen, ohne dass diese die komplexen Spezifikationen der MOF bzw. der MDA gänzlich beherrschen müssen. Die Realisierung dieser im Vergleich zur MOF spezielleren Anforderungen resultierte letztendlich in einem eigenen Metamodell für EMF namens Ecore. Die Trennung der MOF in die Pakete EMOF und CMOF wurde insbesondere von IBM beim Spezifikationsprozess der MOF 2.0 forciert. Dies begründet, dass Ecore heute sehr große Ähnlichkeiten zu EMOF aufweist und daher als deren Implementierung betrachtet werden kann. [Gr06, S. 292] Analog zur MOF bedient sich Ecore auch der Notation der Klassendiagramme zur Deklaration der eigenen Modellelemente. Allerdings sind auch die EMF-Modelle, also die Instanzen des Ecore-Modells, welche Core-Model genannt werden, auf diese Notation beschränkt. Es können demnach mit Ecore nur Klassendiagramme modelliert werden. Ein EMF-Core-Model kann auf verschiedene Weise definiert werden. Es können Java- Interfaces erstellt und diese in ein EMF-Projekt importiert werden. Dabei untersucht der Generator den Code der Interfaces und leitet daraus die Eigenschaften der Modellelemente ab. Ein Interface entspricht dabei meist einer Klasse, die Deklarationen von getter-/setter-methoden werden in Attribute umgesetzt, andere Methoden werden zu 6 Übersetzt aus [ ] EMF as MDA on training wheels. [Bu04, S. 13] 18

19 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung Operationen der Klasse im Modell. Da es sich bei dem EMF-Generator um einen Code-Merging Generator handelt, werden nur markierte Teile des Codes bei der Generierung betrachtet. [Bu04, S. 19] Codefragmente, die Bestandteile des Core-Model deklarieren, müssen mit -Tag in einem Javadoc-Kommentar annotiert werden, daher spricht man auch von Annotated Java Interfaces. Des Weiteren können EMF-Modelle auch als XML-Schemata oder Dateien des UML-Werkzeugs Rational Rose [IBM] definiert und importiert werden. 7 Die am besten geeignete Art ist aber sicherlich die direkte Definition des Modells in EMF mit einem baumbasierten Editor bzw. dem EclipseUML-Editor von Omondo. [OM] Da hier kein expliziter Export- bzw. Importschritt nötig ist, tritt die Problematik der Asynchronität zwischen dem ursprünglichen Modell und dem Core-Model nicht auf. Letztere Art wird im Anschluss an die theoretische Diskussion von Ecore in Kapitel beispielhaft durchgeführt. Das nun vorliegende, zu Ecore konforme Core-Model kann über den EMF-Generator in Java-Code übersetzt werden. Aus jeder Modellklasse wird sowohl ein Interface als auch eine Implementierungsklasse erzeugt. Diese Trennung ist eine Designentscheidung von EMF, die sich für modell-ähnliche APIs bewährt hat und die außerdem notwendig ist, um Mehrfachvererbungen in Java zu ermöglichen. [Bu04, S. 22] Ferner werden für jede Klasse durch Vererbungsmechanismen Methoden und Eigenschaften der Oberklasse EObject zur Verfügung gestellt, die einen reflektiven Zugriff ermöglichen. Die Methode eclass() bietet bspw. den Zugriff auf die Metaklasse einer Klasse. (vgl. Abb. 7) Die Serialisierung von EMF-Modellen geschieht analog zur MOF über den XMI-Standard der OMG. Dafür verfügt EMF intern über einen XMI-Serializer, der generisch Modellelemente verschiedenster Modelle persistieren kann, nicht nur auf Ecore basierende Modelle. Wurde das Core-Model über ein XML-Schema definiert, kann es als XML-Instanzdokument abgespeichert werden, welches konform zu diesem Schema ist. [Bu04, S. 19] Zur Codegenerierung werden neben dem Core-Model noch weitere Informationen gebraucht, welche ebenfalls in einem Modell, dem Generator-Model, gespeichert werden. In diesem können alle wichtigen Parameter zur Codegenerierung adjustiert werden. Zusätzlich inkludiert es die Elemente des Core-Model, indem diese in Wrapper-Klassen 7 Die besondere Stellung des proprietären Werkzeugs Rational Rose von IBM ist dadurch zu begründen, dass die Implementierung des EMF-Frameworks aus der Implementierung von Rational Rose hervorging. [Bu04 S. 17] 19

20 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung abgelegt werden. Beim Editieren eines Modells in EMF mit Hilfe des Generators wird das Generator-Model verändert und automatisch mit dem Core-Model synchronisiert. So entstehen zwei Dateien. Die Datei mit der Endung.ecore ist eine XMI-Serialisierung des Core-Models, während die.genmodel-datei das serialisierte Generator-Model enthält. Diese Trennung hat den Vorteil, dass das Core-Model frei von für die Generierung relevanten Informationen verbleibt und über XMI mit anderen Werkzeugen ausgetauscht werden kann. Ein zentrales Ziel von EMF ist die Verbindung von handgeschriebenem und generiertem Code. Generierte Klassen sollen vom Benutzer erweitert werden. Zudem soll das Core-Model verändert werden und eine erneute Generierung des Codes ohne Verlust der von Hand vorgenommenen Veränderungen erfolgen können. Dies wird auch über Javadoc-Markierungen realisiert. -Tag markiert alle Codefragmente, die generiert wurden und in die Re-Generierung von Code einbezogen werden sollen. Alle anderen, unmarkierten Stellen bleiben unverändert. Das EMF.Edit-Framework erweitert die o. g. Grundfunktionalitäten von EMF um die Möglichkeiten Viewer und Editoren für Instanzen von Core-Modellen als Eclipse Plug- Ins automatisch zu erzeugen. Diese ermöglichen eine Darstellung der Modellobjekte in Form von Baumstrukturen und eine Bearbeitung der Elemente über Eigenschafts-Datenblätter Die Kernkonzepte des Ecore-Metamodells Die Ähnlichkeiten zwischen dem Ecore-Metamodell und dem in der MOF spezifizierten MOF-Model wurden schon in Kapitel erwähnt und begründet. EMF wird als hocheffiziente Java-Implementierung des essentiellen Kerns der MOF-API beschrieben und Ecore als Umsetzung des EMOF-Pakets des MOF-Metamodells. [EMFb] MOF und UML als Wurzeln des Ecore-Metamodells spiegeln sich daher auch in dessen Konzeption wider, es sind allerdings auch Unterschiede festzustellen. Der offensichtlichste Unterschied liegt in der Namensgebung der Elemente. Jeder Modellkomponente in Ecore ist ein E vorangestellt, bspw. EClass für Class. Abbildung 7 zeigt die konstituierenden Elemente des Ecore-Metamodells: Instanzen vom Typ EClass eines Core-Models repräsentieren Implementierungsklassen und Interfaces in Java. Sie enthalten Attribute, Operationen und Referenzen auf andere Klassen. Wie alle Modellelemente werden sie über Namen identifiziert, diese Eigenschaft wird über die abstrakte 20

21 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung Klasse ENamedElement vererbt. Attribute werden über die Klasse EAttribute erklärt. Im Gegensatz zu Referenzen sind Attribute vom Typ Edatatype. EDataType modelliert einzelne Java-Datentypen, also primitive Datentypen, aber auch Klassen und Interfaces. Letztere sollten aber eigene Modellelemente vom Typ EClass bilden. Im Gegensatz dazu definiert die MOF plattformunabhängige Datentypen. [INF07, S. 133] EReferences können als Attribute einer Klasse vom Typ EClass betrachtet werden. Sie entsprechen einem Assoziationsende einer Assoziation der MOF-Spezifikation. [Ge03] Hierin liegt eine wesentliche Diskrepanz zwischen MOF und Ecore. Die Semantik, die durch Assoziationen in MOF ausgedrückt wird, ist wesentlich differenzierter. In der MOF werden bspw. binäre Assoziationen zwischen Klassen erklärt, die fundamentale Abhängigkeiten oder bloße Beobachtungen von Verbindungen zwischen Klassen darstellen können. [vgl. hierzu INF07, S. 112ff] Zwei EReferences in Ecore können nur über die Referenz eopposite eine bidirektionale Assoziation definieren. eopposite referenziert dabei die EReference der jeweils anderen Seite einer solchen Assoziation. [Bu03, S. 102] Eigenschaften, die das Verhalten einer Klasse beschreiben, werden über die Klasse EOperations deklariert. Da ein Core-Model aber keine Informationen über das wirkliche Verhalten einer Klasse enthält, werden nur die Methodenköpfe (Interfaces) dieser Operationen generiert, der Methodenrumpf muss von Hand in den generierten Implementierungsklassen erweitert werden. Wie die MOF ist auch Ecore selbstbeschreibend, es wird demnach ein Core-Model definiert, das die eigenen Konzepte in Form eines Metamodells beschreibt. Dies kann wie folgt verdeutlicht werden: EModelElement, der Basistyp jeder Modellkomponente in Ecore, ist abgeleitet von EObject, dem Äquivalent zu Java.lang.Object. Mit EObject werden über die eigentliche Modellierung hinausgehende reflektive APIs für Modellkomponenten in EMF definiert. [vgl. Bu03, S. 33] Die Metaklasse von EObject ist wiederum die Klasse EClass. Dies ist daher konsistent zu der Aussage, dass Ecore durch sein eigenes Metamodell definiert wird. [Bu03, S. 111] 21

22 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung Abbildung 7: Das Ecore-Metamodell (vereinfacht, nach [Bu04]) Integration von Ecore in EMF anhand eines Beispiels Zur Demonstration der Anwendung von Ecore innerhalb des EMF-Frameworks wird ein Core-Model mit Hilfe des Werkzeugs EclipseUML modelliert. Dieses hat den Vorteil der visuellen Darstellung in Form eines UML-Klassendiagramms, im Vergleich zum baumbasierten Ecore-Editor, welcher Bestandteil des EMF-Frameworks ist. Das erstellte UML-Modell wird simultan in ein Core-Model umgesetzt. Alle im Ecore-Metamodell definierten Modellelemente (EClass, EReference, EAttribute, etc. (vgl. Abb. 7 und 8)) stehen bei der Modellierung zur Verfügung. In dem Beispielprojekt SimpelBank wurde die Klasse Kunde mit den Attributen Vor - und Nachname deklariert. Jeder Kunde kann beliebig viele Konten führen, außerdem muss ein Konto einem Kunden gehören. Ein Konto hat einen Kontonamen und einen Saldo als Attribute, und Operationen zur Verringerung bzw. Erhöhung des Saldos. 22

23 Kapitel 3: Meta Object Facility und Ecore als technische Umsetzung Abbildung 8: Modellerstellung mit dem Eclipse Modeling Framework und EclipseUML Aus dem Core-Model wird dann ein Generator-Model erstellt, in dem die für die Codegenerierung relevanten Informationen abgelegt sind. Mit Aufruf des Generator-Model ist der EMF-Generator gestartet, das Generator-Model kann nun bearbeitet werden. Im Anschluss an eine evtl. Bearbeitung folgt das Generieren des Codes. Mit dem Befehl Generate All werden sowohl Interfaces und Implementierungsklassen für die Modellelemente erzeugt (in den Packages SimpelBank und SimpelBank.impl), als auch Code des EMF.Edit Frameworks zur Bearbeitung von Instanzen des Modells in einem baumbasierten Editor. Dieser ist als Eclipse Plug-In realisiert und direkt über die Eclipse- Runtime-Workbench aufrufbar. Für die Klasse Konto wurden in der Klasse KontoImpl.java bspw. getter- und setter-methoden sowohl für die Attribute Saldo und Kontoname als auch für die Referenz KontoVonKunde erzeugt, da diese als navigierbar deklariert wurde und somit ein Attribut der Klasse vom Typ EClass ist. Außerdem enthält die Klasse das Gerüst für die Methoden decsaldo bzw. incsaldo. Alle Klassen sind mit Javadoc-Kommentaren bestückt, in denen -Tag genutzt wird, um anzuzeigen, dass dieses Codefragment generiert wurde und auch in eine Re-Generierung mit einbezogen werden sollte. Bei einer Veränderung der Methode von Hand sollte dieses Tag entfernt werden. 23

24 Kapitel 4: Fazit - kritische Beurteilung der MOF und Ecore im Rahmen des MDA- Ansatzes Abbildung 9: Bearbeitung der Instanz des SimpelBank Modells im automatisch generierten Editor Innerhalb der Runtime-Workbench muss ein neues einfaches Projekt angelegt werden. Zum Starten des Editor Plug-Ins zum Projekt SimpelBank, wird ein SimpelBank- Model als Instanz des Core-Model erstellt. Hier können nun Instanzen der Klasse Kunde und der Klasse Konto angelegt, und deren Attribute bearbeitet werden. 4 Fazit - kritische Beurteilung der MOF und Ecore im Rahmen des MDA-Ansatzes Die formale Definition von Modellierungssprachen ist notwendige Vorraussetzung für die modellgetriebene Softwareentwicklung, insbesondere für Modelltransformationen und das Generieren von Code. Diese leisten die Konzepte der Metamodellierung, die innerhalb der MDA über die MOF-Spezifikation manifestiert sind. Die Funktionalitäten, welche die MOF in den MDA-Ansatz einbringt und die es rechtfertigen, sie als dessen Kern zu bezeichnen, [St05, S.375] können wie folgt zusammenfassend charakterisiert werden: Die MOF bildet den Fixstern [Pe06, S. 78] der Modellierung, da alle Modellierungssprachen, die innerhalb der MDA Verwendung finden sollen, zur MOF konform sein müssen, um eine werkzeuggestützte Deklaration von Modellen und deren automati- 24

25 Kapitel 4: Fazit - kritische Beurteilung der MOF und Ecore im Rahmen des MDA- Ansatzes sierte Weiterverarbeitung zu ermöglichen. In Verbindung mit der UML-Spezifikation liefert sie eine frei verfügbare, standardisierte Spracharchitektur, die Entwickler befähigt, unterschiedliche Aspekte des zu entwickelnden Softwaresystems auf unterschiedlichen Detaillierungsebenen abzubilden. Gleichzeitig bietet die MOF durch die beschriebenen Erweiterungsmechanismen die Flexibilität, vorhandene Sprachkonstrukte adäquat anzupassen sowie eigene, MOF-konforme Domain-Specific-Languages zu definieren. Die Bedeutung der Standardisierung darf nicht unterschätzt werden. Zum einen wirkt sie positiv auf die Kommunikation in Entwicklungs-Teams. Begriffe wie Metaebene- M2 oder Modell-Instanz werden einheitlich und eindeutig definiert. [Pe06, S. 341] Andererseits ermöglicht die MOF mit Standards wie XMI und JMI die physikalische Verwaltung und Integration MOF-konformer Metadaten entlang von Werkzeug-Ketten. [Fr05, S. 3] Das wichtigste Defizit der bisherigen Spezifikation wird in der Literatur im Fehlen eines Sprachstandards zur Definition von Transformationsregeln gesehen. [Gr06, S. 434; St05, S. 395] Werkzeughersteller greifen auf unterschiedliche Sprachen und Systeme zurück, um Regeln zu definieren und anzuwenden. Diese Lücke soll durch die QVT- Spezifikation geschlossen werden. Sie soll die Heterogenität der Werkzeuge beheben und so die Qualität des generierten Quellcodes vergleichbar machen. [Ze06, S.193] Des Weiteren wird kritisiert, dass die MOF nur die abstrakte Syntax einer Sprache definiert, nicht aber die konkrete, graphische Syntax. [Fr05, S. 6; St05, S. 376] Die Repräsentation einer Sprache ist aber bedeutsam z.b. für die Kommunikation zwischen Modellnutzern oder für graphische Benutzeroberflächen von Werkzeugen, die die Modellierung in der jeweiligen Sprache unterstützen. [Dew07, S. 24] Diese Kritik wird auch gegenüber Ecore geäußert. [Fr05, S.6] Weitere Kritikpunkte an Ecore resultieren hauptsächlich aus der Tatsache, dass Ecore zwar eine starke Ähnlichkeit zur MOF und insbesondere zum EMOF-Paket aufweist, aber dennoch keine exakte Implementierung der Spezifikation ist. Beispielsweise ist das Java-Mapping von EMF nicht konform zu JMI. Außerdem fehlen die Unterstützung von Model-to-Model Transformationen und eine Sprache, mit der Constraints, also Gültigkeitsbedingungen und Einschränkungen, an Modellelemente modelliert werden können. Dies wäre nötig, um auch Code innerhalb von Methoden zu generieren und nicht nur deren Deklaration. [Fr05, S. 5] EMF zeigt damit auf, was heute in der jungen Disziplin des MDSD realisiert und angewandt werden kann. Die Beseitigung der erwähnten Mängel von MOF und EMF bzw. Ecore wird einen noch extensiveren Einsatz von Modellen innerhalb der Softwareentwicklung ermöglichen. 25