Implementierung einer komponentenorientierten Architektur für Software-Modelle basierend auf dem Eclipse Modeling Framework (EMF)

Transkript

1 Master-Arbeit Implementierung einer komponentenorientierten Architektur für Software-Modelle basierend auf dem Eclipse Modeling Framework (EMF) im Master-Studiengang Informatik des Fachbereichs Mathematik und Informatik der Philipps-Universität Marburg Tim Schäfer geb in Marburg Betreuer: Prof. Dr. Gabriele Taentzer, Dipl.-Inf. Stefan Jurack, Dipl.-Inf. Daniel Strüber

2

3 Zusammenfassung Das Eclipse Modeling Framework (EMF) ist ein auf Eclipse basierendes, weit verbreitetes Modellierungswerkzeug mit dem sich aus Software-Modellen Code erzeugen lässt. Diese Ecore genannten Modelle und deren Instanzen werden mit zunehmender Komplexität der zu modellierenden Domäne immer größer und somit unhandlicher. Daher besitzt EMF einen Mechanismus, um Modelle auf mehrere Dateien oder allgemeiner Ressourcen, aufzuteilen. Diese Verteilung ist über URI 1 s realisiert und somit rein physischer Natur. Im logischen Sinne handelt es sich stets um ein Modell, dessen Teilmodelle bei Bedarf nachgeladen werden. Verteiltes Arbeiten an derart separierten Modell-Ressourcen, z.b. in Entwicklerteams, ist zwar durch gängige Versionierungssysteme inklusive Konfliktmanagement möglich. Eine weitere Problematik ergibt sich jedoch aus der Tatsache, dass alle Elemente eines referenzierten Modells benutzt werden können, auch wenn dies vom Besitzer des referenzierten Modells evtl. nicht erwünscht ist. Es könnte sich um private Daten handeln, die nicht nach außen preisgegeben werden sollen. Wünschenswert wäre hier ein Ansatz, der das Geheimnisprinzip ( information hiding ) auf Modellebene anwendet. Diese Arbeit beschreibt die Implementierung einer auf expliziten Schnittstellen- Modellen basierenden komponentenorientierten Infrastruktur für Software-Modelle. Dabei wird die vorhandene Funktionalität des Eclipse Modeling Framework bestmöglich wiederverwendet, indem dieses erweitert wird. 1 Uniform Resource Identifier

4

5 Inhaltsverzeichnis 1. Einleitung Motivation Lösungsansatz Gliederung Grundlagen Modelle und modellgetriebene Softwareentwicklung Eclipse Plattform und Plug-in Architektur Struktur eines Eclipse-Plugins Extension-Points Eclipse Modeling Framework Ecore EMF Edit Framework EObject API und Dynamisches EMF Validierung Ressourcen und URIs Setting Delegates Komponentenorientierte Modelle Modelle als Graphen Ein komponentenorientiertes Konzept für typisierte Graphen Aspektorientierte Programmierung (AOP) mit AspectJ Anforderungsbeschreibung Import- und Export-Schnittstellen Schnittstellen auf Typebene Schnittstellen auf Instanzebene Komponenten-Infrastruktur Baumeditor Entwurf Import- und Export-Schnittstellen Erweiterung des Ecore Metamodells Modell-Constraints Delegation von Datenabfragen

6 Erweiterte Standard-Constraints für Schnittstellen-Instanzen Komponenten Infrastruktur Netzwerkmodell Modell-Constraints Komponenten-Registry Implementierung Import- und Export-Schnittstellen EExport und EImport Delegation Anpassungen am Codegenerierungs-Prozess Umsetzung der Anforderungen Baumeditor Überblick Item-Provider von EExport und EImport Umsetzung der Anforderungen Komponenten-Registry URI Schema Umsetzung der Anforderungen Tests Erweiterungen Diagramm-Editor für die Netzwerkschicht CDO-Integration Zukünftige Erweiterungen Demonstration und Tutorial Beispiel: Fluggesellschaft und Reisebüro Beispiel: -Client Verwandte Arbeiten Zusammenfassung und Ausblick 87 A. Anhang 89 A.1. Installation & Benutzung A.2. Testfälle für die realisierten Werkzeuge Abbildungsverzeichnis 97 Literaturverzeichnis 99

7 Kapitel 1. Einleitung In der modellgetriebenen Softwareentwicklung spielen, wie der Name schon andeutet, Modelle eine zentrale Rolle. Während sie in der klassischen Softwareentwicklung hauptsächlich als Abstraktionshilfe, also zur Veranschaulichung der auf klassische Weise erstellten Programmstruktur, dienen, werden sie in der modellgetriebenen Entwicklung direkt in den Entwicklungsprozess mit einbezogen. Spezielle Code- Generatoren verwenden Modelle als Eingabe um daraus automatisiert Programmcode zu erzeugen. Für die weitverbreitete Entwicklungsumgebung Eclipse steht mit dem Eclipse Modeling Framework (EMF), unter dem Dach des Eclipse Modeling Projects, eine Infrastruktur zur Verfügung, die Konzepte der modellgetriebenen Entwicklung realisiert. Mit EMF lassen sich aus einem strukturierten Datenmodell neben dem Modell-Code auch lauffähige Editoren generieren, die das Erstellen und Editieren von Modellinstanzen erlauben Motivation Ein Software-System bildet selten eine in sich geschlossene Einheit, sondern wird häufig in eine Menge von zusammengehörigen Teilen, den Komponenten, zerlegt. An diesen können dann verschiedene Entwickler-Teams parallel, nicht selten auch verteilt, arbeiten. In Anbetracht der wachsenden Beliebtheit modellgetriebener Entwicklungsprozesse stellt sich die Frage, inwiefern sich komponentenorientierte Strategien auf Modellebene übertragen lassen. Auf EMF basierende Modelle können beliebige Elemente anderer Modelle referenzieren. Dadurch kann ein sehr großes Modell auf mehrere Ressourcen (Dateien) verteilt werden. Dieses Vorgehen ist jedoch mit Nachteilen verbunden: Zwar werden von einem Modell referenzierte Modelle bei erstmaligem Zugriff in den Editor geladen und somit über Änderungen informiert. Einem Modell ist aber nicht bekannt, welche externen Modelle auf es selbst verweisen. Änderungen können somit zu Inkonsistenzen in den referenzierenden Modellen führen. Auch ist die Verteilung rein physischer und nicht logischer Natur, da die Teilmodelle von den Modellierungswerkzeugen letzten Endes intern zu einem großen zusammenhängenden Modell zusammengesetzt werden. Ein weiterer Nachteil ist, dass das Geheimnisprinzip ( information hiding ) nicht

8 2 1 Einleitung unterstützt wird: Zu einem Modell kann nicht festgelegt werden, welche Daten nach außen preisgegeben werden dürfen und welche nicht. Ein auf EMF basierender komponentenorientierter Modellierungsansatz, der eine Lösung für die genannten Probleme anbietet, wurde in [JT09, Jur12] auf graphentheoretischer Basis vorgestellt. Dort wurden komponentenorientierte Modelle mit expliziten Import- und Export-Schnittstellen eingeführt. Eine solche Komponente besteht aus einem als Body bezeichneten Domänenmodell sowie einer Menge von (beliebig vielen) Import- und Export-Schnittstellen. Export-Schnittstellen legen fest, welche Modellelemente des Bodys nach außen hin sichtbar sein sollen, Import- Schnittstellen agieren als Brücke zwischen Bodys mit importierten Elementen und Export-Schnittstellen anderer Komponenten. Ziel dieser Arbeit ist eine prototypische Implementierung dieses Konzepts. Sie soll in erster Linie die Machbarkeit der theoretischen Überlegungen zeigen Lösungsansatz Wir werden besagte graphentheoretische Formalisierung komponentenorientierter Modelle mit expliziten Schnittstellen im Kontext von EMF in die Praxis umsetzen. Als Modellierungssprache werden wir uns dem von EMF bereitgestellten Ecore Format bedienen. Body-, Export- und Import-Schnittstellen werden durch verbundene Ecorebasierte Modelle verkörpert werden. Dabei werden wir feststellen, dass das Ecore Metamodell nicht über die nötigen Strukturen verfügt, um Schnittstellen-spezifische Informationen zu speichern. Aus diesem Grund werden wir es erweitern. In einem zweiten Schritt werden wir erste Werkzeuge bereitstellen um den Umgang mit der Infrastruktur zu ermöglichen und zu erleichtern. Dabei können wir uns auf die vorhandene Werkzeugunterstützung von EMF stützen Gliederung Nach dieser Einleitung folgt zunächst eine Übersicht über die für das Verständnis wichtigen technischen und theoretischen Grundlagen. Anschließend soll eine Anforderungsbeschreibung Merkmale bestimmen, die die im Rahmen dieser Arbeit erstellten Artefakte aufweisen sollen. Der Kern der Arbeit untergliedert sich in Entwurf und Implementierung der zu erstellenden Software. Während sich der Entwurf hauptsächlich um konzeptionelle Designentscheidungen dreht, zeigt der Implementierungs-Teil einige Lösungswege detailliert auf. Erweiterungsmöglichkeiten, darunter einige bereits verwirklichte Erweiterungen, werden in einem separaten Kapitel behandelt. Anschließend soll die Benutzung der implementierten Werkzeuge in einem Tutorial-Kapitel demonstriert werden. Nach einer Auseinandersetzung mit verwandten Arbeiten sollen eine Zusammenfassung und ein Ausblick die Arbeit abrunden.

9 Kapitel 2. Grundlagen Es folgt eine Einführung in die für das Verständnis dieser Arbeit wichtigen theoretischen und technischen Grundlagen. Zunächst betrachten wir Modelle und ihre Rolle in der modellgetriebenen Softwareentwicklung. Anschließend geben wir einen Überblick über das Eclipse Modeling Framework. Da EMF in Form eines Eclipse Plug-ins vorliegt, werden wir uns zuvor mit der Eclipse Plattform und dessen Plug-in Konzept beschäftigen. Anschließend werden wir die Definition komponentenorientierter Modelle zusammenfassen, deren praktische Umsetzung Gegenstand dieser Arbeit ist. Den Abschluss dieses Kapitels bildet das Paradigma der aspektorientierten Programmierung, von dem wir in geringem Umfang Gebrauch machen werden Modelle und modellgetriebene Softwareentwicklung Modelle sind ein in der Softwareentwicklung häufig eingesetztes Mittel, um komplexe Sachverhalte durch Abstraktion vereinfacht darzustellen. Ein Modell beschreibt die Beziehungen zwischen den Entitäten einer konkreten Problem-Domäne und die Struktur, in der sie ihre Daten bereitstellen. Eine der bekanntesten Modellierungssprachen ist die von der Object Management Group (OMG) spezifizierte Unified Modeling Language (UML), die 14 Diagrammarten umfasst. In der objektorientierten Programmierung haben sich insbesondere Klassendiagramme bewährt, die die wesentlichen Bestandteile des objektorientierten Entwurfs Klassen, Felder und Methoden in grafischer Notation festhalten. In einem Klassendiagramm werden Klassen als Rechtecke dargestellt und sind für gewöhnlich in der oberen Hälfte mit dem Klassenname beschriftet. Weitere Eigenschaften, zum Beispiel ob die Klasse abstrakt oder eine Schnittstelle ist, sind je nach Modellierungs-Werkzeug zusätzlich in doppelten spitzen Klammern ( interface ) über dem Namen aufgeführt. Bei abstrakten Klassen wird dies auch ersatzweise durch einen kursiv geschriebenen Namen ausgedrückt. Bei Feldern unterscheidet man in der Modellierung zwischen Attributen (für atomare Datentypen wie Integer und String) und Referenzen (für komplexe Datentypen, in der Regel Klassen). Attribute werden

10 4 2 Grundlagen zusammen mit Methoden innerhalb einer Klasse aufgezählt. Ihr Typ wird hinter einem Doppelpunkt angegeben (Beispiel: vorname : String). Bei Methoden werden noch ihre Parameter in runden Klammern aufgeführt, ihre textuelle Repräsentation ähnelt also der Methoden-Signatur. Referenzen zu anderen Klassen werden durch Verbindungslinien visualisiert. Man unterscheidet hier zwischen der Assoziation und der Aggregation/Komposition. Letztere stellt eine Besitzer-Beziehung dar und grenzt sich von der Assoziation grafisch durch eine Raute an der besitzenden Klasse ab. Allen Referenzen gemeinsam ist, dass sie gerichtet oder ungerichtet (also in beide Richtungen verlaufend) sein können und dass sie eine Kardinalität bzw. Multiplizität (ggf. auf beiden Seiten) besitzen. Diese besteht aus zwei numerischen Werten: einer unteren und einer oberen Schranke. Sie stehen für die minimale bzw. maximale Anzahl an Teilnehmern der Assoziation. Multiplizitäten werden in der Form a..b notiert, wobei a die untere und b die obere Schranke angibt. Vererbungsbeziehungen bezeichnet man als Generalisierung. Grafisch handelt es sich um eine Verbindungslinie mit einem Dreieck auf der Seite der Oberklasse. So wie Programmiersprachen die formale Syntax für in ihr geschriebene Programme vorgeben, gibt es auch für Modelle eine formale Grundlage: Metamodelle. Meta ist griechisch für über, demzufolge ist ein Metamodell also ein Modell über Modelle. Es beschreibt, wie ein zu ihm konformes Modell auszusehen hat. Eine allgemeine Grundlage für Metamodelle schafft der Meta-Object Facility (MOF) Standard. Von der OMG spezifiziert, beschreibt MOF eine Architektur, die aus 4 Ebenen aufgebaut ist. Auf der höchsten Ebene, M3, befindet sich das MOF Meta-Metamodell, das beschreibt, wie eine MOF-konforme Modellierungssprache auszusehen hat. Darunter findet man auf M2 die Meta-Ebene, welche die Sprachelemente eines Modells beschreibt, in der Regel also Modellelemente wie Klassen, Attribute, Referenzen und deren Beziehung untereinander. Ein bekannter Vertreter ist das Metamodell der UML. Auf M1 befinden sich konkrete Modelle einer (auf M2 definierten) Modellierungssprache, im Fall von Sprachen wie der UML häufig als Klassendiagramm visualisiert. Die letzte Ebene M0 bezieht sich schließlich auf Instanzen von (M1-) Modellen, also Objekte aus der realen Welt. Modelle eignen sich nicht nur zur Dokumentation oder als Abstraktionshilfe bei der Softwareentwicklung. Im Rahmen der modellgetriebenen Softwareentwicklung werden Modelle unmittelbar in den Entwicklungsprozess mit einbezogen. Modellgetriebene Softwareentwicklung (Model-Driven Software Development, MDSD) ist ein Oberbegriff für Techniken, die automatisiert aus formalen Modellen lauffähige Software erzeugen. [SVEH07] Geeignete Werkzeuge generieren aus einem Modell automatisiert lauffähigen Programmcode. Der Code entsteht also nicht allein durch die Interpretation des Modells durch den Entwickler, sondern vielmehr durch einen Generator (wenn auch nur bis zu einem gewissen Grad). Ändert sich das Modell, können die Änderungen, je nach

11 2.2 Eclipse Plattform und Plug-in Architektur 5 Qualität der Werkzeuge, in den bereits generierten Code (automatisch) übertragen werden, was die Kohärenz steigert Eclipse Plattform und Plug-in Architektur Die integrierte Entwicklungsumgebung (engl. integrated development environment = IDE) Eclipse ist mehr als nur ein Programmierwerkzeug. War ihr Einsatzzweck zu Beginn hauptsächlich das Schreiben von Java Software, wird sie durch ihre enorme Erweiterbarkeit mittlerweile für verschiedenste Zwecke eingesetzt. Seit Version 3 besteht Eclipse selbst nur aus einem kleinen Kern, dem Eclipse Core. Sämtliche Funktionalität ist in Plug-ins ausgelagert, die beim Start der Plattform durch den Kern geladen werden. Dazu zählt beispielsweise das Equinox-Framework, eine OSGi 1 -Implementierung, die das Grundgerüst von Eclipse darstellt. Wie bei einem Betriebssystem gleicht daher eine Eclipse Installation kaum einer anderen, es lassen sich beliebige Pakete zu einem Gesamtsystem zusammenschnüren, mit dem prinzipiell jede Aufgabe aus dem Alltag eines Softwareentwicklers (und darüber hinaus) bewältigt werden kann. Um ein Eclipse Plug-in zu testen, muss man es nicht installieren. Man kann eine weitere Eclipse Instanz, auch Runtime Workbench genannt, aus Eclipse heraus starten, in der alle im Workspace 2 befindlichen Plug-ins nutzbar sind. Bei der Menge an verfügbaren Eclipse Plug-ins ist es wenig verwunderlich, dass deren Entwicklung in zahlreiche Projekte und Unter-Projekte untergliedert ist. Hier wäre zum Beispiel das Java Development Tools (JDT) Projekt zu erwähnen, in dem sämtliche Java-spezifische Funktionalität, z.b. der Quelltext-Editor mit Syntax- Highlighting oder der Debugger, zusammengefasst ist. Ein insbesondere für diese Masterarbeit wichtiges Top-Level Projekt ist das Eclipse Modeling Project, zu dem neben EMF unter anderem auch das Graphical Modeling Framework (GMF) zählt. Das bereits erwähnte Equinox-Framework bildet die Basis für die dynamische Erweiterbarkeit der Eclipse Plattform. Eine komplette Übersicht würde den Rahmen dieser Arbeit sprengen, interessierte Leser seien auf [Ecl06] verwiesen. Wir werden uns im Folgenden kurz mit der Struktur eines Eclipse Plug-ins sowie dem sogenannten Extension-Point Mechanismus befassen Struktur eines Eclipse-Plugins Ein Eclipse Plug-in wird in Java geschrieben. Die API der Eclipse Plattform bietet dazu eine Reihe von Schnittstellen und (zum Teil abstrakten) Basis-Implementierungen an, z.b. für grafische Komponenten wie Editoren und Sichten. Desweiteren beinhaltet 1 Open Services Gateway initiative 2 Der Workspace ist ein Verzeichnis auf der Festplatte des Eclipse Nutzers, in dem dieser seine Projekte abspeichert. Man kann nach belieben zwischen mehreren Workspaces wechseln.

12 6 2 Grundlagen ein Plug-in neben dem für Java-Archive üblichen Manifest (META-INF/MANIFEST.MF) eine XML-Datei namens plugin.xml, in der die benutzten bzw. angebotenen Extension Points (siehe Kapitel 2.2.2) aufgeführt sind. In der Regel enthalten Plug-ins zusätzliche Ressourcen, etwa Icons/Bilder etc. Beim Starten von Eclipse werden alle verfügbaren Plug-ins in einer Registry festgehalten und können von dort abgefragt werden Extension-Points Die Eclipse Plattform (bzw. das Equinox-Framework) verfügt mit dem Konzept der Extension-Points und den Extensions über einen sehr mächtigen Mechanismus, Erweiterungen bereitzustellen. Durch Definition eines Extension-Points öffnet sich ein Plug-in für eine Erweiterung durch andere Plug-ins. Dabei gibt die Definition die Struktur der Information vor, die eine konkrete Erweiterung angeben muss. Andere Plug-ins können nun eine passende Erweiterung bereitstellen, indem sie eine Contribution zu diesem Extension-Point vornehmen. Dies wird in der Extension- Registry festgehalten. Ein Beispiel dafür ist der Extension-Point org.eclipse.ui.newwizards der genutzt werden kann, um eigene Wizards zum Anlegen einer Ressource im Workspace (File New... ) bereitzustellen. In diesem Fall müsste unter anderem der (vollqualifizierte) Name einer Klasse angegeben werden, die das Interface org.eclipse.ui.inewwizard implementiert. Beim Öffnen des New -Dialogs in Eclipse fragt das den Extension-Point definierende Plug-in (hier: org.eclipse.ui) die Extension-Registry nach Plug-ins ab, die einen solchen Wizard bereitstellen um die Liste an verfügbaren Wizards zusammenzustellen Eclipse Modeling Framework Als Kernbestandteil des Eclipse Modeling Projects erfreut sich EMF in der Modeling- Community großer Beliebtheit. EMF bietet Werkzeug-Unterstützung sowohl für die Modellierung als auch die Codegenerierung. Grundlage für den modellgetriebenen Prozess bildet ein Domänenmodell, in dem die Elemente der betrachteten Anwendungsdomäne und deren Beziehungen untereinander beschrieben werden. Das Domänenmodell kann aus diversen Quellen (XML-Schema, annotierte Java-Klassen u.v.m) importiert oder mit EMFs hauseigenem Format Ecore, mit dem wir uns in Abschnitt näher beschäftigen werden, von Grund auf definiert werden. Für die Codegenerierung ist es nötig, aus dem Domänenmodell ein Generatormodell abzuleiten, das aufgrund seiner Dateinamenserweiterung auch kurz Genmodel genannt wird. In diesem können zusätzliche, allein für die Codegenerierung relevante, Einstellungen vorgenommen werden, etwa in welches Verzeichnis der Code geschrieben werden soll. Die Codegenerierung wird per Kontextmenü aus dem Genmodel-Editor

13 2.3 Eclipse Modeling Framework 7 angestoßen. Technisch realisiert ist sie mit sogenannten Java Emitter Templates (JET), Schablonen, die in einer an Java Server Pages angelehnten Template-Sprache verfasst sind. Da im Domänenmodell nur die Beziehung zwischen Entitäten, nicht aber deren Verhalten, modelliert werden kann, ist es wünschenswert, den generierten Code um selbstgeschriebenen zu erweitern. Damit diese Änderungen bei einer erneuten Codegenerierung nicht verloren gehen, wird jedes generierte Element initial mit der im Javadoc-Bereich markiert. Ändert man diese NOT, wird das entsprechende Element bei der nächsten Neugenerierung nicht angefasst. Durch Modifizierung der Standard-Templates kann darüber hinaus der Codegenerierungs-Prozess an die individuellen Bedürfnisse des Benutzers angepasst werden. Neben dem Modell-Code, der die modellierten Entitäten mitsamt ihrer Eigenschaften auf Java-Klassen abbildet, lassen sich JUnit 3 -Testfälle sowie ein baumbasierter Editor zur Erstellung und Bearbeitung von Modellinstanzen vollautomatisch generieren. Metamodelle und deren Instanzen können im XML-basierten Dateiformat XMI oder mithilfe der Erweiterung Teneo auch in einer Datenbank persistiert werden. Mit den baumbasierten Editoren werden wir uns in den nachfolgenden Abschnitten auseinandersetzen Ecore Für die Modellierung bietet EMF ein eigenes Format namens Ecore an, welches auf dem EMOF -Standard basiert. EMOF steht für Essential Meta-Object Facility und ist eine auf das Wesentliche reduzierte Teilmenge von MOF. Das Ecore Metamodell ENamedElement name : EString EModelElement EObject ETypedElement lowerbound : EInt upperbound : EInt 0..1 etype EClassifier 0..* eclassifiers EPackage nsuri : EString EStructuralFeature 0..* estructuralfeatures EClass abstract : EBoolean interface : EBoolean EDataType EAttribute EReference containment : EBoolean 0..* esupertypes Abbildung 2.1.: Ausschnitt des Ecore Metamodells (Ecore.ecore) 3 JUnit ist ein Java-Framework zum Schreiben von Unit Tests, die ohne Nutzerinteraktion durchlaufen werden können.

14 8 2 Grundlagen (Abb. 2.1) orientiert sich an den sprachlichen Bestandteilen der Programmiersprache Java. Dazu gehören bekanntlich Pakete, die wiederrum Klassen und Unter-Pakete beinhalten können. Klassen enthalten (Objekt-) Felder und Methoden. Pakete werden in Ecore durch EPackages repräsentiert, die durch eine eindeutige Namespace-URI (nicht etwa durch ihren Namen) identifiziert werden. Das Ecore-Äquivalent einer Java-Klasse ist die EClass. Ob eine Klasse abstrakt ist, oder ob es sich gar um ein Interface handelt, wird durch entsprechende Indikatoren (abstract bzw. interface) angegeben. Vererbungsbeziehungen werden durch eine Liste von Oberklassen (esupertypes) ausgedrückt. Bei Objektfeldern unterscheidet Ecore zwischen Attributen (EAttribute) und Referenzen (EReference). Der Typ eines Attributs wird über einen EDataType angegeben. Elementare Datentypen wie Integer, Float und String liegen in Ecore als Instanz eines EDataType vor (EInt, EFloat, EString). Der Typ einer Referenz ist hingegen eine Klasse. In Kontrast zu vielen anderen Modellierungssprachen sind Referenzen in EMF stets unidirektional. Bidirektionale Referenzen müssen als zwei entgegengesetzte unidirektionale Referenzen modelliert und mithilfe der Eigenschaft eopposite als Gegenstück zueinander deklariert werdem. Standardmäßig handelt es sich bei einer Referenz um eine Assoziation (im Sinne der Objektorientierung), möchte man eine Aggregation/Komposition, setzt man die Containment-Eigenschaft. Diese Unter- Airline name : EString offeredflights 0..* start Flight 1 flightno : EInt destination usedairports 1 0..* Airport name : EString location : EString runwaycount : EInt ScheduledFlight weeklydeparture : EString weeklyarrival : EString CharterFlight departure : EDate arrival : EDate (a) Diagramm-Editor (b) Baumeditor Abbildung 2.2.: Beispiel für ein Ecore-Modell scheidung ist insbesondere für die Serialisierung wichtig: Ein Objekt muss (über eine Containment-Referenz) in einem anderen Objekt enthalten ( contained ) sein, um serialisiert werden zu können. Im Baumeditor äußert sich dies darin, dass ein Objekt (mit Ausnahme der Wurzel) nur als Kind eines anderen Objektes im Baum angelegt werden kann. Abb. 2.2 zeigt ein Ecore-Modell, dargestellt durch den Ecoretools Diagramm- Editor (a) und den baumbasierten Editor (b). Eine Fluggesellschaft (Airline) besitzt

15 2.3 Eclipse Modeling Framework 9 einen Namen, modelliert durch ein Attribut vom Datentyp String (EString). Über Containment-Referenzen im Diagramm erkennbar an der Raute auf Container-Seite werden angebotene Flüge (Flight) und benutzte Flughäfen (Airport) verwaltet. Flügen ist über entsprechende Referenzen ihr Start- und Zielflughafen zugeordnet. ScheduledFlight und CharterFlight sind Unterklassen der abstrakten Flight- Klasse. So wie in Java jedes Objekt automatisch (entweder direkt oder indirekt) von java.lang.object erbt, ist EObject die gemeinsame Oberklasse aller Instanzen einer mit EMF modellierten EClass. Interessanterweise liegt das soeben beschriebene Ecore Metamodell seinerseits als Ecore-Modell vor, sozusagen als Instanz von sich selbst, wie in Abb. 2.1 zu sehen. Dies mag auf den ersten Blick verwirrend erscheinen, eröffnet jedoch die Möglichkeit, Modellelemente des Ecore Metamodells in eigenen Modellen wiederzuverwenden, was wir später auch tun werden EMF Edit Framework Wie in Abschnitt angedeutet, beschränkt sich EMF nicht auf das Generieren von Modell-Code. Auch ein baumbasierter Editor nach dem Model-View-Controller Entwurfsmuster (MVC-Pattern) gehört zum Repertoire. EMF setzt hier auf den TreeViewer-Widgets des JFace-Frameworks auf. JFace ist Bestandteil der Eclipse Plattform und stellt eine Abstraktionsschicht für den einfachen Zugriff auf die Komponenten des Standard Widget Toolkit (SWT) bereit. Das SWT ist eine Bibliothek für grafische Oberflächen und somit eine Alternative zu Swing und dem AWT (Abstract Window Toolkit). Alle grafischen Komponenten in Eclipse sind mit SWT implementiert. Ein von EMF generierter Editor erlaubt das Editieren von Instanzen des entsprechenden Metamodells. Dabei muss bei der Instanz-Erstellung eine der modellierten Entitäten als Wurzelobjekt ausgewählt werden. Dieses Wurzelelement fungiert als Basis-Container für alle Objekte, die in dieser Instanz angelegt und gespeichert werden. Dementsprechend ist beim Entwurf des Modells darauf zu achten, dass jede modellierte EClass, von der im Editor eine Instanz erstellt werden können soll, transitiv über eine Containment-Referenz vom Wurzelelement aus erreichbar ist. In unserem Fluggesellschafts-Beispiel übernimmt die Klasse Airline diese Rolle. Im Generatormodell kann die Dateinamenserweiterung für Instanzen des Modells gewählt werden, standardmäßig entspricht sie dem Namen des Pakets (EPackage). Das Einfügen eines neuen Objekts in den Baum geschieht per Rechtsklick auf das Vater-Objekt, also das Objekt, dessen Metaklasse eine Containment-Referenz vom Typ des zu erzeugenden Objektes besitzt, und Auswahl von New Child im Kontextmenü. Im erscheinenden Untermenü ist für jedes mögliche Objekt ein Eintrag vorhanden. Das Editieren von Attributen und Nicht-Containment-Referenzen eines Objekts erfolgt über die Properties-View von Eclipse. Bei Attributen ist der Wert je nach Typ entweder als Text (z.b. EInt, EString) einzugeben oder aus einer

16 10 2 Grundlagen Abbildung 2.3.: Beispielinstanz des Modells aus Abb. 2.2, dargestellt durch den generierten Editor Dropdown-Liste (z.b. EBoolean) auszuwählen. Bei Referenzen hängt es von deren Multiplizität ab: Ist diese 0:1 oder 1:1 wählt man das referenzierte Objekt aus einer Dropdown-Liste, bei 0:N- oder 1:N-Referenzen öffnet sich ein Dialog, in dem mehrere Objekte nacheinander selektiert werden können. Damit der Editor (bzw. der TreeViewer) weiß, wie die Objekte im Baum darzustellen sind, benötigt er einen sogenannten ContentProvider sowie einen LabelProvider. Ersterer gibt zu einem gegebenen Objekt dessen Vater und seine Kinder zurück etc., letzterer liefert die textuelle Repräsentation (oder auch Label) sowie ein grafisches Symbol, das neben dem Text angezeigt wird. Die Properties-View benötigt Informationen darüber, welche Daten in den diversen Komponenten zur Auswahl stehen sollen. Diese Datenbindung vereint EMF in eigenen ItemProvider Klassen, die zu jeder Modellklasse generiert werden. Wie in Abb. 2.3 zu sehen, setzt sich die textuelle Repräsentation eines EObjects standardmäßig aus dem Namen dessen Metaklasse sowie, falls vorhanden, dem Wert eines EAttributes zusammen. Als Kind-Objekte werden standardmäßig alle mit dem entsprechenden Objekt in einer Containment- Beziehung stehenden Objekte betrachtet, bei unserer Fluggesellschaft sind dies die von ihr angebotenen Flüge sowie die ihr bekannten Flughäfen. Anpassungen am Verhalten des Editors können zum Teil vor der Codegenerierung durch gewisse Einstellungen im Generatormodell spezifiziert werden, tiefergreifende Anpassungen werden aber meist durch Änderung der generierten Item-Provider-Klassen umgesetzt. In unserem Beispiel bietet es sich an, das Text-Label eines Fluges aus Start- und Ziel-Ort zusammenzusetzen und die Flugnummer in eckigen Klammern dahinter zu stellen. Flughäfen könnten zusätzlich zu ihrem Namen ihren Standort in runden Klammern angeben (siehe Abb. 2.4).

17 2.3 Eclipse Modeling Framework 11 Abbildung 2.4.: Anzeige der Beispielinstanz durch den Editor nach Anpassung der Item-Provider-Klassen für Flight und Airport Änderungen an Modellinstanzen nehmen EMF-generierte Editoren nicht direkt, sondern über einzelne Befehle bzw. Commands vor. Elementare oder komplexe Operationen werden in einem Command parametrisiert, der alle benötigten Informationen zur Durchführung der Änderung vorhält. Kommandos werden auf einem Command-Stack ausgeführt und können rückgängig gemacht werden. Dabei wird der oberste Command vom Stack heruntergenommen und die Methode undo() aufgerufen. Rückgängig-gemachte Operationen lassen sich wiederholen (redo), was mit einem weiteren Stack realisiert ist, auf den rückgängig-gemachte Commands abgelegt werden. Modell-Code, Item-Provider-Klassen, der Editor und der Test-Code können separat voneinander generiert werden. Dabei werden jeweils eigene Projekte, mit entsprechenden Abhängigkeiten untereinander, erzeugt. Der Modell-Code wird in der Regel in das Projekt, in dem sich das Generatormodell befindet, geschrieben. Die Namen der Projekte ergeben sich aus dem Namen des Projekts mit dem Modell-Code sowie einem Suffix (*.edit, *.editor, *.tests). In unserem Beispiel erhalten wir die Projekte airline, airline.edit, airline.editor und airline.tests EObject API und Dynamisches EMF Jede Instanz einer mit EMF modellierten Klasse (EClass) ist ein EObject und verfügt somit über die von der EObject-API bereitgestellten Methoden. Besonders interesssant sind hier die reflektiven Methoden, die man mit der Reflection aus Java vergleichen kann. Damit ist es möglich, eine Modellinstanz zu verändern, ohne ihr Metamodell zu kennen. Der Aufruf der Methode eclass() auf einem EObject liefert die Metaklasse des Objekts. eget() und eset() erlauben das Abfragen und Setzen von Attributen und Referenzen. Somit muss man nicht den Getter/Setter der definierenden Klasse kennen, stattdessen übergibt man das EStructuralFeature

18 12 2 Grundlagen als Parameter. Man spricht hier von Dynamischem EMF. Damit ist es sogar möglich, Instanzen eines Modells, zu dem kein generierter Code vorliegt, zu erstellen. Anstatt der Implementierungs-Klassen, die in diesem Fall fehlen, werden DynamicEObjects instanziiert. Ihre Daten speichern sie in einem Objekt-Array, dass bei reflektivem Zugriff mit der Feature-ID des EStructuralFeature indiziert wird. Nachteile ergeben sich aus fehlender Typsicherheit und schlechterer Performanz. Editieren kann man dynamische Instanzen mit dem Reflective Ecore Model Editor, der einen generischen Item-Provider (siehe 2.3.2) verwendet um das Standard-Verhalten generierter Item- Provider zu emulieren. Weitere nützliche Methoden von EObject sind unter anderem econtents(), die alle in diesem Objekt über eine Containment-Referenz direkt enthaltenen Kind-Objekte liefert (mit eallcontents() erhält man auch die indirekten), sowie econtainer(), die in umgekehrter Richtung das Vater-Objekt zurückgibt. Ist ein EObject in einer Ressource enthalten, erhält man sie mittels eresource() Validierung Für ein Modell können Regeln (engl. Constraints) festgelegt werden, die eine Instanz einhalten muss um als korrekt angesehen zu werden. Das Überprüfen dieser Regeln wird als Validierung bezeichnet und kann aus dem Kontextmenü des Editors auf jedem Objekt der Instanz aufgerufen werden. Die Validierung wird automatisch auch rekursiv auf allen Kind-Elementen aufgerufen. Eine Standard-Regel für jedes EObject ist beispielsweise, dass Multiplizitäten eingehalten werden müssen. Referenziert ein Objekt weniger/mehr Elemente, als es laut Definition der Referenz darf (lowerbound / upperbound), schlägt die Validierung für dieses Objekt fehl. Die Standard-Invarianten sind jedoch nicht immer ausreichend, zum Beispiel könnte ein Modellierer verlangen, dass ein bestimmtes String-Attribut einem gewissen Format folgen soll, oder dass ein numerisches Attribut nicht negativ sein darf. Constraints können in EMF entweder in speziellen Validator-Klassen in Java implementiert oder mit der Object Constraint Language (OCL) spezifiziert werden. OCL-Ausdrücke können als Annotationen in das Modell eingebettet werden Ressourcen und URIs Modelle und ihre Instanzen werden in EMF in Ressourcen gespeichert. EMF stellt dazu die Klassen Resource und ResourceSet zur Verfügung, letztere als Container für mehrere, möglicherweise miteinander verbundene, Ressourcen. Mithilfe eines ResourceSets können neue Ressourcen erstellt und bereits vorhandene geladen werden. EMF-generierte Editoren arbeiten stets auf einem ResourceSet und erlauben das Laden von weiteren Ressourcen mittels Kontextmenü-Eintrag Load Resource....

19 2.3 Eclipse Modeling Framework 13 Listing 2.1: XMI-Markup der Beispielinstanz lufthansa.airline <? xml version =" 1.0 " encoding ="UTF -8"?> < airline:airline xmi:version =" 2.0 " xmlns:xmi =" http: // www. omg. org / XMI " xmlns:xsi =" http: // /2001/ XMLSchema - instance " xmlns:airline =" http: // airline " name =" Lufthansa "> < usedairports name =" Frankfurt " location =" Frankfurt am Main " runwaycount ="4"/> < usedairports name =" John F. Kennedy International " location =" New York " runwaycount ="4"/> < usedairports name =" Paris - Charles -de - Gaulle " location =" Paris "/> < offeredflights xsi:type =" airline:scheduledflight " flightno ="42" start destination weeklydeparture ="Mo, 12 :00 " weeklyarrival ="Mo, 20 :00 "/> < offeredflights xsi:type =" airline:charterflight " flightno ="23" start destination departure =" T07:00: " arrival =" T14:00: "/> </ airline: Airline > Standardmäßig werden EMF-Ressourcen im XMI-Format persistiert. XMI steht für XML Metadata Interchange und ist ein von der OMG standardisiertes allgemeines Austauschformat für Metadaten die einem auf MOF basierenden Metamodell unterliegen. Wie der Name vermuten lässt, sieht eine XMI-Instanz wie ein XML-Dokument aus (siehe Listing 2.1). Objekte werden als XML-Elemente serialisiert, ihre Daten als XML-Attribute oder Kind-Elemente. Hier offenbart sich die Relevanz des Containment-Konzepts: Ist ein Objekt in einem anderen enthalten, taucht es im XML-Markup als Kind des Containers auf. Andernfalls erfolgt die Referenzierung anhand eines der XML-Abfragesprache XPath ähnelnden Ausdrucks oder, falls sich das referenzierte Objekt in einer anderen Ressource befindet, einer URI. URIs sind universelle Identifikatoren für Ressourcen und es existieren verschiedene URI-Schemata, wie zum Beispiel HTTP oder FTP. Im Kontext von EMF und Eclipse kommen meist Platform-Resource-URIs zum Einsatz, mit denen Ressourcen im Workspace angesprochen werden können (Beispiel: platform:/resource/projektname/pfad/datei.xml). Der Verweis auf das referenzierte Objekt im Dokument wird der URI in Form des optionalen URI-Fragments, eingeleitet durch eine Raute (#), angehängt. Über eine URI referenzierte Objekte werden von EMF als sogenannte Proxys vorgehalten und lazy, also erst bei Bedarf, aufgelöst. Dieses Verhalten kann für jede EReference über die Eigenschaft resolveproxies gesteuert werden. Ist ihr Wert true (Standard-Wert), wird das Objekt bei erstmaligem Zugriff aufgelöst. Andernfalls bleibt es ein Proxy, bis der Nutzer die Auflösung manuell durchführt.

20 14 2 Grundlagen Setting Delegates Bei der Codegenerierung wird aus jedem EStructuralFeature einer EClass ein Objektfeld in der generierten Klasse erzeugt. Das Abfragen und Setzen eines Merkmals entspricht dann dem Lesen von bzw. dem Schreiben in dieses Feld. Mitunter benötigt man aber Features, dessen Werte aus anderen Daten abzuleiten sind. In einem solchen Fall werden üblicherweise die Eigenschaften derived und volatile des Features im Metamodell gesetzt, was dazu führt, dass kein Feld generiert wird und die Getter/Setter von Hand zu implementieren sind. Eine flexiblere Alternative ist hingegen die Benutzung von sogenannten Setting Delegates, die in Version 2.6 von EMF eingeführt wurden. Diese können einem Feature programmatisch zugewiesen werden oder alternativ per Extension-Point registriert und durch Annotationen auf dem Feature aktiviert werden. Zur Laufzeit wird die Abfrage und das Setzen dann an das Setting Delegate weitergeleitet, also delegiert. Eine Implementierung eines Setting Delegates findet sich beispielsweise im OCL-Ecore Plugin (org.eclipse.ocl.ecore), bei dem die Berechnung des Feature-Werts in einem OCL-Ausdruck (als Annotation auf dem Feature) angegeben werden kann, der dann von der OCL-Engine ausgewertet wird. Ein Vorteil von Setting Delegates liegt darin, dass sie auch mit dynamischem EMF genutzt werden können. Schließlich liegen bei dynamischen Instanzen keine Implementierungs-Klassen vor, bei denen Getter/Setter manuell implementiert werden könnten. Neben Setting Delegates unterstützt EMF Invocation Delegates und Validation Delegates um Methodenaufrufe bzw. die Validierung der Modellinstanz zu delegieren Komponentenorientierte Modelle Die theoretische Grundlage dieser Arbeit bilden komponentenorientierte Modelle mit expliziten Schnittstellen, deren grundlegende Struktur in [JT09] auf graphentheoretischer Basis eingeführt wurde. In [JT10] und [JT11] wurden die Details dieser Struktur formuliert. Wir werden in diesem Abschnitt zunächst zeigen, wie Modelle durch Graphen repräsentiert werden können und anschließend einen Überblick über die Definition komponentenorientierter Modelle aufzeigen Modelle als Graphen Graphen sind ein geeignetes Mittel, um die abstrakte Syntax von Datenstrukturen und Algorithmen zu modellieren. Auch EMF-Modelle und die Beziehungen der beteiligten Klassen untereinander sowie die Objektstruktur einer Modellinstanz lassen sich durch Graphen darstellen. In diesem Abschnitt werden einige Begriffe aus dem Bereich der Graphentheorie eingeführt und der Bezug zu Modellen hergestellt.

21 2.4 Komponentenorientierte Modelle 15 Graphen Ein Graph ist eine abstrakte Struktur, die aus einer Menge von Knoten und einer Menge von Verbindungen zwischen diesen Knoten, Kanten genannt, besteht. Grafisch werden Knoten in aller Regel als Kreise oder Punkte und Kanten als Verbindungslinien zwischen diesen dargestellt. Man unterscheidet häufig zwischen gerichteten und ungerichteten Graphen, wobei sich Richtung auf den Verlauf der Kanten bezieht. Grafisch wird eine ungerichtete Kante durch eine normale Linie, eine gerichtete Kante hingegen durch einen Pfeil in Verlaufsrichtung dargestellt. Im Folgenden werden wir nur gerichtete Graphen betrachten. Ein Graph ist ein Tupel G = (G N, G E, s G, t G ) mit Knotenmenge G N, Kantenmenge G E und Abbildungen s G, t G : G E G N, die einer Kante Quell- und Zielknoten zuordnen. Graphmorphismen Ein Graphmorphismus ist eine Abbildung zwischen zwei Graphen, beziehungsweise ein Paar von Abbildungen, die jeweils die Knoten- bzw. Kantenmenge des einen Graphs auf die Knoten- bzw. Kantenmenge des anderen Graphs abbilden. Die Abbildung muss dabei strukturverträglich sein. Das bedeutet, dass für jede durch den Morphismus abgebildete Kante auch deren Quell- und Zielknoten genau auf die Quell- und Zielknoten der Bild-Kante abgebildet werden müssen. Formal besteht ein Graphmorphismus f : G H aus Abbildungen f N : G N H N und f E : G E H E. Für eine Kante e G E müssen folgende Eigenschaften gelten: B E A D G A F B E C D G C F (a) partieller Morphismus (b) totaler Morphismus Abbildung 2.5.: Graph-Morphismen f N (s G (e)) = s H (f E (e)) f N (t G (e)) = t H (f E (e)) Man spricht ferner von einem partiellen Graphmorphismus, wenn durch ihn nicht jeder Knoten oder jede Kante des Ursprungs-Graphen auf den Ziel-Graphen abgebildet wird, also wenn mindestens eine der beiden Abbildungen nicht total ist. Das ist bei Abb. 2.5a der Fall, da Knoten D und die Kante zwischen D und C nicht abgebildet werden. Abb. 2.5b zeigt einen totalen Graph-Morphismus.

22 16 2 Grundlagen IC-Graphen Objekte einer Modellinstanz sind über Klassen des Metamodells getypt. Das Konzept der Typisierung lässt sich mithilfe von Typgraphen in Form von IC-Graphen bzw. Graphen mit Vererbung (engl. Inheritance) und Containment ausdrücken. Diese repräsentieren das Metamodell, das heißt die Knoten entsprechen den Klassen des Metamodells und die Kanten entsprechen den Referenzen zwischen den Klassen. Die Vererbungshierarchie wird über eine Relation auf der Knotenmenge ausgedrückt, bei der ein Knoten mit genau den Knoten in Beziehung steht, von denen er direkt erbt. Unter dem Vererbungs-Clan eines Knoten verstehen wir die Menge aller Knoten, die in der reflexiv-transitiven Hülle der Vererbungs-Relation mit ihm in Beziehung stehen. Dies entspricht der Menge aller Unterklassen inklusive der Klasse selbst. Da eine Klasse weder direkt noch indirekt von sich selbst erben darf, wird zusätzlich gefordert, dass die reflexiv-transitive Hülle der Vererbungs-Relation antisymmetrisch ist. Die Information darüber, welche Klassen abstrakt sind, wird über eine Teilmenge der Knoten kodiert. Wie wir in Abschnitt gesehen haben, spielen Containment- Referenzen in EMF eine wichtige Rolle. Daher verfügt ein Typgraph zusätzlich über die Information, bei welchen Kanten es sich um Containment-Kanten handelt. Formal ist ein IC-Graph definiert als G = (T, I, A, C) mit einem Graph T = (T N, T E, s T, t T ) einer Vererbungs-Relation I T N T N einer Menge von abstrakten Knoten A T N, sowie einer Menge von Containment Kanten C T E. Kardinalitäten von Referenzen sowie Attribute und Methoden sind in dieser Formalisierung nicht berücksichtigt. IC-Morphismen Die Einführung von IC-Graphen erfordert für unsere Zwecke noch eine Ausweitung der Definition von Morphismen auf IC-Graph-Morphismen. Ein Morphismus zwischen zwei IC-Graphen, auch IC-Morphismus genannt, ist über einen Morphismus auf der IC-Graph- Komponente T definiert. Daraus ergeben sich die Abbildungen für die Menge der abstrakten Knoten (A) sowie der Containment Kanten (C). Letztere müssen ebenfalls auf Containment-Kanten abgebildet werden. Die strukturerhaltende Bedingung wird abgeschwächt: Abbildung 2.6.: Typgraph- Morphismus

23 2.4 Komponentenorientierte Modelle 17 Quell- und Zielknoten einer abgebildeten Kante müssen nicht auf Quell- und Zielknoten der Bildkante abgebildet werden, sondern dürfen auf einen Knoten aus dem Vererbungs-Clan von Quell- bzw. Zielknoten der Bildkante abgebildet werden. Vererbungs-Clans werden auf Vererbungs-Clans abgebildet. Abb. 2.6 zeigt einen Morphismus zwischen zwei durch Klassendiagramme visualisierten Typgraphen. Die Abbildung der Kante zwischen B und C (unten) auf die zwischen A und C (oben) ist valide, da B zum Vererbungs-Clan von A gehört. Der Ursprungs-Graph weist eine gegenüber dem Ziel-Graphen einfachere Struktur auf: Knoten A wurde weggelassen, seine Kante zu Knoten C bleibt jedoch erhalten, geht aber nunmehr von B aus. Typisierte IC-Graphen Nachdem nun Typgraphen als Repräsentanten für Metamodelle definiert wurden, stellt sich die Frage, wie sich Modellinstanzen als Graphen darstellen lassen. Offensichtlich gibt es auf Instanzebene keine Vererbung und auch keine abstrakten Elemente, da konkrete Objekte niemals abstrakt im Sinne der Objektorientierung sind. Die Unterscheidung zwischen Containment-Kanten und Nicht-Containment- Kanten ist hingegen auch für Instanzen relevant. Daher verwenden wir IC-Graphen mit leerer Menge an abstrakten Knoten und leerer Vererbungs-Relation (I = A = ). Die Typisierung drücken wir über einen totalen IC-Morphismus zu einem Typgraphen aus. Für den Instanzgraphen muss gelten, dass jeder Knoten höchstens eine eingehende Containment-Kante besitzt. Desweiteren muss der Containment-Graph zyklenfrei sein. Als Containment-Kanten kommen nur solche in Frage, die durch mylibrary : Library Library Goethe : Writer Faust : Book writers books Fontane : Writer Effi Briest : Book Writer author Book Schiller : Writer Wilhelm Tell : Book Maria Stuart : Book Abbildung 2.7.: Instanzgraph (links) getypt über Typgraph (rechts) den IC-Morphismus auf eine Containment-Kante des Typgraphs abgebildet werden. Nicht notwendig, für EMF im Rahmen der Serialisierung jedoch wünschenswert

24 18 2 Grundlagen ist es darüberhinaus, dass jeder Knoten - außer dem Wurzelknoten - eine (d.h. genau eine) eingehende Containment-Kante besitzt. Abb. 2.7 zeigt links einen Instanzgraphen in Form eines UML Objektdiagramms und rechts den dazugehörigen Typgraphen als Klassendiagramm. Der typisierende IC-Morphismus ist aus Gründen der Übersichtlichkeit nicht explizit eingezeichnet. Der Typ eines Instanz-Knotens ist hinter einem Doppelpunkt notiert, Containment-Kanten sind am ausgefüllten Kreis auf der Seite des Besitzers zu erkennen. Sie sind über die entsprechenden Containment-Kanten im Typgraph getypt. Typisierte IC-Graphmorphismen Analog zu Typgraph-Morphismen benötigen wir noch Morphismen zwischen Instanzgraphen. Ein solcher ist über den Morphismus zwischen den Typgraphen der beiden Instanzgraphen typisiert. Für ihn muss gelten, dass der Typ eines Knoten bzw. einer Kante des Ursprungs-Graphen durch den Typgraph-Morphismus auf den Typ des Bild-Knotens bzw. der Bild-Kante abgebildet werden muss. In Abb. 2.8 werden Flüge (Instanzen von Flight) auf Charter-Flüge (Instanzen von CharterFlight) abgebildet. Das ist zulässig, da auch in den Typgraphen Flight auf CharterFlight abgebildet wird. Airline Airline flights Flight knownairports start flights Airport Flight CharterFlight destination myline : Airline myline : Airline NY : Airport NY_Paris : Flight NY_Paris : CharterFlight Paris : Airport Paris_Frankfurt : Flight Paris_Frankfurt : CharterFlight Frankfurt : Airport Abbildung 2.8.: Typisierter IC-Graphmorphismus

25 2.4 Komponentenorientierte Modelle Ein komponentenorientiertes Konzept für typisierte Graphen Nachdem wir gesehen haben, wie gewöhnliche EMF-Modelle und deren Instanzen mit IC-Graphen und typisierten Graphen dargestellt werden können, befassen wir uns nun mit dem theoretischen Fundament, das als Grundlage für diese Arbeit dient: komponentenorientierte Modelle mit expliziten Schnittstellen. In [JT11] werden sie als zusammengesetzte Graphen mit expliziten Export- und Import-Schnittstellen formalisiert, die auf verteilten Graphen basieren. Dabei wird zwischen zwei Ebenen unterschieden. Die Netzwerk-Schicht beschreibt die allgemeine Verteilungs-Struktur, die Objekt-Schicht beschreibt die lokalen Bestandteile, d.h. die einzelnen Graphen, die miteinander vernetzt sind. Verbindungen zwischen den Graphen sind mithilfe von IC-Morphismen definiert. Ab sofort betrachten wir nur noch totale IC-Morphismen. Netzwerkgraphen Ein Netzwerkgraph ist ein Graph, dessen Knoten-Menge aus Body-Knoten, Export- Knoten und Import-Knoten besteht. Export- und Import-Knoten repräsentieren die (expliziten) Schnittstellen-Modelle: Export-Schnittstellen spezifizieren, welche Teile des Body-Modells öffentlich - also für andere Modelle - nutzbar sein sollen. Import-Schnittstellen legen zum einen fest, welche Teile des Bodys importiert sind und zum anderen, aus welcher Export-Schnittstelle diese Teile importiert werden sollen. Für den Netzwerkgraphen müssen folgende Eigenschaften gelten: Von einem Body-Knoten gehen keinerlei Kanten aus. Von jedem Export-Knoten geht exakt eine Kante aus, deren Ziel ein Body- Knoten ist. Import-Knoten haben genau zwei ausgehende Kanten, wobei die eine zu einem Body-Knoten und die andere zu einem Export-Knoten verläuft. Aus diesen Eigenschaften folgt, dass beliebig viele Kanten auf ein und denselben Body-Knoten und ebenfalls beliebig viele Kanten auf einen Export-Knoten zeigen können. Offensichtlich darf keine Kante auf einen Import-Knoten verweisen. Einen Body mit seinen (auf ihn zeigenden) Imports und Exports fassen wir zu einer Komponente zusammen. Importe stellen mit ihrer Export-Kante die Verbindung zwischen Komponenten her. Eine formale Definition für den Begriff der Komponente ist in dieser Formalisierung nicht enthalten. Komponenten ergeben sich vielmehr indirekt aus der Netzwerkstruktur. Zusammengesetzte IC-Graphen Ein zusammengesetzter IC-Graph besteht aus einem Netzwerkgraphen, einer Menge von IC-Graphen und einer Menge von IC-Graph-Morphismen. Die IC-Graphen wer-

26 20 2 Grundlagen den als Objektgraphen oder lokale Graphen bezeichnet. Sie sind jeweils einem Knoten des Netzwerkgraphen zugeordnet, den sie verfeinern. Die Anzahl der IC-Graphen entspricht also der Anzahl an Netzwerkknoten. Die IC-Morphismen verfeinern analog dazu die Kanten des Netzwerkgraphen. Verläuft also eine Netzwerk-Kante zwischen zwei Knoten a und b, so wird diese durch den IC-Morphismus zwischen dem Objektgraphen von a und dem von b verfeinert. Desweiteren müssen die Objektgraphen B E I B r r Abbildung 2.9.: Zusammengesetzter IC-Graph jedes Body-Knotens einen Wurzelknoten besitzen, also einen Knoten, der mit jedem anderen nicht-abstrakten Knoten des Graphen (direkt oder indirekt) in einer Containment-Beziehung steht. Für Export- und Import-Graphen wird dies nicht gefordert. Abb. 2.9 zeigt einen zusammengesetzten IC-Graphen: Oben befindet sich der Netzwerkgraph, bestehend aus 2 Komponenten, dessen Knoten ihren Typ über den entsprechenden Anfangsbuchstaben angeben (B = Body, E = Export, I = Import). Unter diesen sind in Rechtecken die verfeinernden IC-Graphen abgebildet. Die IC-Morphismen korrespondieren mit den Netzwerkkanten. Die Wurzelknoten der Bodys sind mit einem r (root) gekennzeichnet. Zusammengesetzte IC-Graphen mit Typisierung Morphismen zwischen zusammengesetzten IC-Graphen nennen wir konsequenterweise zusammengesetzte IC-Graph-Morphismen. Sie bestehen aus einem totalen Morphismus zwischen den Netzwerkgraphen sowie einer Menge von IC-Morphismen zwischen den Objektgraphen. Dabei wird der Objektgraph eines Netzwerkknoten n auf den Objektgraphen des Bildes von n abgebildet. Mit zusammengesetzten IC-Graph- Morphismen können wir zusammengesetzte IC-Graphen typisieren (siehe Abschnitt 2.4.1). Im Netzwerkgraph sind Body-Knoten über Body-Knoten, Export-Knoten über Export-Knoten und Import-Knoten über Import-Knoten getypt. Die Objektgraphen sind über dementsprechende Typgraphen typisiert. Abb zeigt zusammengesetzte IC-Graphen auf Typebene (oben) und Instanzebene (unten). Es sind keine Netzwerkgraphen, sondern nur die verfeinernden Objektgraphen abgebildet. Auf Typebene sind zwei Komponenten zu sehen: links

27 2.5 Aspektorientierte Programmierung (AOP) mit AspectJ 21 Abbildung 2.10.: Zusammengesetzter IC-Graph mit Typisierung (aus [JT10]) ein Verwaltungs-System für Abteilungen (Departments) bestehend aus einem Body (DepBody) und drei Export-Schnittstellen, rechts ein Projekt-Management-System. PrjImport2 verbindet die beiden Systeme mittels DepExport2, wohingegen PrjImport1 sich bemerkenswerterweise auf einen Export derselben Komponente bezieht, was auf Typebene erlaubt ist. Auf Instanzebene (untere Hälfte) wäre eine solche Beziehung innerhalb derselben Komponente nicht erlaubt. Hier handelt es sich jedoch um zwei verschiedene Komponenten-Instanzen: Ein Projekt aus PrjBody.2 wird in PrjBody.1 importiert Aspektorientierte Programmierung (AOP) mit AspectJ Konzepte der Objektorientierung postulieren die hierarchische Modularisierung der Programmlogik. Funktionale Anforderungen können oft gut in Klassen und zugehörige Methoden gekapselt werden, einige nichtfunktionale Anforderungen hingegen müssen an vielen unterschiedlichen Stellen umgesetzt werden. Maßnahmen wie Protokollierung (Logging) oder Sicherheitsüberprüfungen sind dann in immer gleicher Form auf den Code verstreut. Man spricht hier von bereichsübergreifenden Belangen oder Cross-Cutting Concerns. Objektorientierte Programmierung erreicht schnell ihre Grenzen, wenn es darum geht, eine Modularisierung hinsichtlich dieser Belange

28 22 2 Grundlagen vorzunehmen. Hier setzt das Paradigma der aspektorientierten Programmierung an, das eine Isolierung dieser querschnittlichen Belange von der Kernfunktionalität (Separation of Concerns) anstrebt. Mit AspectJ existiert eine aspektorientierte Erweiterung für die Programmiersprache Java. Ursprünglich bei Xerox PARC entwickelt, ist es heute ein der Eclipse Foundation zugehöriges Open-Source Projekt. Werkzeugunterstützung für Eclipse erhält man mittels der AspectJ Development Tools (AJDT). AspectJ führt den Aspekt als Sprachkonstrukt ein, der sich ähnlich wie eine Java- Klasse verhält: Er kann ebenfalls Felder und Methoden enthalten, darüber hinaus jedoch zusätzlich sogenannte Pointcuts, Advices und Inter-Type Declarations 4. Bevor wir diese Begriffe definieren, müssen wir uns zunächst mit dem Join Point Modell auseinandersetzen. Ein Join Point ist eine Stelle im Kontrollfluss eines Programms, also beispielsweise ein Methodenaufruf, ein Feldzugriff oder das Behandeln einer Ausnahme. Er ist im Allgemeinen nicht mit einer Zeile im Quellcode gleichzusetzen, da er auch dynamische Komponenten ( Von wem bzw. in welchem Kontext wurde die Methode aufgerufen? ) enthalten kann. Ein Pointcut ist ein Ausdruck, der eine Menge von Join Points auswählt. Sie können mit logischen Operatoren (&&,,!) verknüpft werden. Der Pointcut call(void Point.setX(int)) call(void Point.setY(int)) greift bei jedem Aufruf der Setter-Methode für eines der Felder x oder y auf einem Objekt vom Typ Point. Hier ist call(ausdruck) einer der atomaren, in AspectJ eingebauten (built-in) Pointcuts. Eigene Pointcuts können aus den elementaren zusammengesetzt und ähnlich einer Methode mit einem Namen und Parametern versehen werden. Die Parameter dienen dazu, den Kontext des Join Points festzuhalten. Definiert man folgenden Pointcut pointcut setterx(int newx): call(void Point.setX(int)) && args(newx); steht der Wert, mit dem der Setter aufgerufen wurde, in der Variable newx zur Verfügung. Als Advice wird der Code bezeichnet, der beim Erreichen eines assoziierten Pointcuts ausgeführt werden soll. Er kann vor Erreichen des Join Points (before), danach (after) oder auch anstelle des eigentlichen Codes (around) ausgeführt werden. Ein Advice kann also nicht nur zusätzliches Verhalten hinzufügen, sondern auch das in Klassen, Methoden etc. definierte Verhalten ersetzen. Ein Advice für das obige Beispiel (setterx) könnte so aussehen: before(int newx): setterx(newx) { System.out.println("x-coordinate changed to: " + newx); } 4 Inter-Type Declarations werden wir in dieser Einführung außen vor lassen, da sie für unsere Zwecke nicht von Relevanz sind. Mit Inter-Type Declarations ist es möglich, vorhandenen Klassen neue Attribute und Methoden hinzuzufügen, ohne die Klassen selbst zu ändern.

29 2.5 Aspektorientierte Programmierung (AOP) mit AspectJ 23 Wie bei Methoden steht der auszuführende Code im Rumpf, innerhalb geschweifter Klammern. Hier zeigt sich auch die Notwendigkeit, sowohl Pointcut als auch Advice ggf. mit Parametern zu versehen, um Zugriff auf die Umgebung des Join Points zu bekommen. Da wir AspectJ nur in geringem Umfang nutzen werden, steigen wir an dieser Stelle nicht weiter in die Details dieser sehr mächtigen Sprache ein. Eine vollständige Beschreibung des Sprachumfangs findet sich in [Asp]. Damit die Aspekte Wirkung zeigen, müssen sie in den Programmcode eingewoben werden. Geschehen kann dieses Aspect Weaving entweder beim Kompiliervorgang oder zur Laufzeit beim Laden der Klassen durch den Classloader. Zum Funktionsumfang des AJDT zählen unter anderem der AspectJ Compiler ajc, der zuerst den gewöhnlichen Java-Compiler aufruft und anschließend etwaige Aspekte einwebt, sowie die Bibliothek aspectjweaver.jar. Letztere weist die JVM an, einen von AspectJ bereitgestellten Classloader zu verwenden, der die Aspekte einwebt, nachdem die betroffenen Klassen in den Speicher geladen wurden 5. Dieses Load-Time Weaving genannte Verfahren erweist sich als ausgesprochen nützlich, da es dem Programmierer erlaubt, Programmcode, den er selbst nicht ändern kann (wie z.b. Bibliotheken) oder auf den er zur Compile-Zeit keinen Zugriff hat, mit Aspekten zu versehen. Wir werden dies später ausnutzen. 5 Implementiert ist dies als sogenannter Javaagent, ein Mechanismus, der in Java 5 eingeführt wurde und beim Start der JVM über eine Option spezifiziert werden kann. Für weitere Informationen siehe package-summary.html

30

31 Kapitel 3. Anforderungsbeschreibung Im Rahmen dieser Arbeit sollen komponentenorientierte Modelle auf Basis von EMF implementiert werden, um einen komponentenbasierten Modellierungs- und Codegenerierungs-Prozess in prototypischem Stadium zu ermöglichen. In diesem Kapitel sollen Anforderungen an Entwurf und Implementierung der komponentenorientierten Architektur sowie der zu erstellenden Werkzeuge festgehalten werden. Die nachfolgend dargestellten Anforderungen lassen sich in funktionale und nichtfunktionale Anforderungen unterteilen. Funktionale Anforderungen sind hierbei genauer anhand der unterschiedenen Anwendungsfälle darzulegen. Bei nichtfunktionale Anforderungen wird gegebenenfalls zwischen konzeptionellen und ergonomischen Anforderungen unterschieden Import- und Export-Schnittstellen In Abschnitt wurden komponentenorientierte Modelle mit expliziten Schnittstellen auf formaler Basis vorgestellt. Komponenten - bestehend aus einem Body und einer Menge von Schnittstellen - sollen auf Typ- und Instanzebene erstellt werden können. Bodys sind gewöhnliche Graphen mit Vererbung und Containment und können in der technischen Realisierung auf Basis von EMF als Ecore-Modelle bzw. Instanzen davon umgesetzt werden. Schnittstellen sind hingegen über IC-Morphismen ihrem Body (und Imports zusätzlich ihrem Export) zugeordnet. Diese Zuordnungen können nicht ohne weiteres in Ecore-Modellen untergebracht werden. Es bedarf also einer Infrastruktur für Import- und Export-Schnittstellen, in der diese Zuordnungen gespeichert werden können. Auch die Netzwerkschicht soll explizit spezifizierbar sein. Im Folgenden sind Anforderungen an die Schnittstellen-Architektur aufgeführt, die sich zum Teil direkt aus der Definition der komponentenorientierten Modelle ergeben.

32 26 3 Anforderungsbeschreibung Konzeptionelle Anforderungen Anforderung 1.1: Existierende Ecore-Modelle als Body-Modelle Beschreibung Bereits vorhandene Ecore-Modelle und Instanzen davon sollen ohne Änderung als Body einer Komponente fungieren können. Erklärung Die Zuordnungen zwischen Schnittstellen und ihrem Body sowie zwischen Importen und ihren Exports sollen lediglich in den Schnittstellen-Modellen bzw. ihren Instanzen gespeichert werden. Jedes gültige Ecore Modell bzw. jede gültige Instanz davon soll, ohne dass eine Migration, Konvertierung oder ähnliches nötig ist, als Body für eine Komponente verwendbar sein Schnittstellen auf Typebene Die logische Verteilung der Komponenten-Bestandteile soll sich auch in der physischen Organisation widerspiegeln. Body-, Import- und Export-Modelle sollen jeweils in eigenen Ressourcen persistiert werden. Schnittstellen-Modelle sollen einem Body- Modell und Import-Modelle zusätzlich einem Export-Modell zugeordnet werden. Dieses Prinzip soll auch auf die Objekt-Ebene übertragen werden: Jede einzelne in einer Schnittstelle definierte Klasse/Referenz soll eindeutig einer Klasse/Referenz des Body/Export-Modells zugeordnet sein. Nichtfunktionale Anforderungen Anforderung 1.2: Containment-Struktur Beschreibung Schnittstellen sollen automatisch eine Containment-Struktur aufweisen, die eine beliebige Struktur für ihre Instanzen erlaubt. Erklärung Objekte einer EMF-Instanz können (abgesehen vom obersten Wurzelobjekt) nur serialisiert werden, wenn sie in einem anderen enthalten (contained) sind. Dies steht im Konflikt zu der Anforderung der Formalisierung, dass Schnittstellen-Modelle keinen obersten Wurzelcontainer benötigen. Die technische Umsetzung soll diesen Konflikt lösen. Anforderung 1.3: Simplere Modellstruktur Beschreibung Schnittstellen-Modelle sollen eine einfachere Struktur als ihre Body-Modelle haben dürfen.

33 3.1 Import- und Export-Schnittstellen 27 Erklärung Schnittstellen müssen nicht die gesamte Komplexität ihres Bodys erfassen. Es soll nicht nur möglich sein, bestimmte Klassen oder Referenzen eines Bodys in einer Schnittstelle wegzulassen. Vererbungs-Hierarchien dürfen abgeflacht werden, das heißt eine Klasse kann ohne ihre Oberklasse(n) in einer Schnittstelle auftauchen, darf aber dennoch (geerbte) Eigenschaften der Oberklasse(n) übernehmen. Mögliche Vereinfachungen ergeben sich aus den strukturerhaltenden Eigenschaften von IC-Morphismen (siehe 2.4.1). Nicht erlaubte Vereinfachungen sind durch geeignete Modell-Constraints (vgl ) zu unterbinden. Anforderung 1.4: Code-Generierung von Schnittstellen-Modellen Beschreibung Aus Schnittstellen-Modellen soll sich, wie bei Ecore-Modellen, Code generieren lassen. Erklärung Abhängig von der konkreten Umsetzung der Schnittstellen-Modelle kann möglicherweise auf die vorhandene Funktionalität von EMF zurückgegriffen werden. Funktionale Anforderungen Anwendungsfall 1.5: Erstellen von Schnittstellen-Modellen auf Basis existierender Komponenten-Teile Zusammenfassung Der Nutzer soll beim Erstellen eines neuen Schnittstellen- Modells die Möglichkeit bekommen, ein bereits vorhandenes Body-Modell auszuwählen. Wird ein Import-Modell angelegt, soll zusätzlich ein vorhandenes Export- Modell auswählbar sein. Vorbedingung Ein Body- bzw. Export-Modell existieren bereits. Ablauf Der Nutzer ruft den Wizard zur Erstellung eines Export- oder Import- Modells auf. Mithilfe eines Auswahldialogs kann er ein bestehendes Body-Modell (Export-Modell) selektieren. Nachbedingung Die neu angelegte Schnittstelle ist mit dem ausgewählten Body- Modell und/oder dem Export-Modell verbunden. Anwendungsfall 1.6: Erstellen von Schnittstellen-Modellen mit Vorauswahl von Modellelementen des Body-Modells Zusammenfassung Der Nutzer soll beim Erstellen eines neuen Schnittstellen- Modells die Möglichkeit bekommen, Modellelemente des Bodys auszuwählen, die in die neue Schnittstelle initial zu übertragen sind.

34 28 3 Anforderungsbeschreibung Vorbedingung Ein vorhandenes Body-Modell wurde bereits ausgewählt (siehe Anwendungsfall 1.5). Ablauf Dem Nutzer werden alle Modellelemente des gewählten Body-Modells angezeigt, aus denen er eine Teilmenge selektieren kann. Nachbedingung Das neue erzeugte Schnittstellen-Modell enthält die gewählten Modellelemente mit entsprechender Zuordnung. Anwendungsfall 1.7: Generatormodell für Schnittstellen-Modell anlegen Zusammenfassung Aus Schnittstellen-Modellen soll ein Generatormodell erstellt werden können, mit dem sich Code generieren lässt. Vorbedingung Ein valides Schnittstellen-Modell wurde bereits erstellt und ist mit Body sowie ggf. Export verbunden. Ablauf Weitgehend wie bei gewöhnlichen EMF-Modellen. Nachbedingung Das Generatormodell kann auf übliche Weise zur Codegenerierung verwendet werden Schnittstellen auf Instanzebene Aus den Schnittstellen-Modellen sollen sich wieder Instanzen bilden lassen. Diese sollen wie auf Typebene einem Body (Importe dazu einem Export) zugeordnet sein. Auch hier gilt dies ebenfalls auf Objekt-Ebene, also für alle Objekte der Instanz. Nichtfunktionale Anforderungen Anforderung 1.8: Delegation von Datenabfragen Beschreibung Instanzen eines Schnittstellen-Modells sollen keine eigenen Daten 1 besitzen, sondern lediglich die Rolle von Delegationsobjekten annehmen. Exportierte Objekte sollen Datenabfragen zu ihrem Body delegieren. Importierte Objekte beziehen ihre Daten aus ihrem Export und leiten Abfragen auf ihrem Body auf sich selbst um. Erklärung Diese Delegations-Kette soll dazu führen, dass Objekte einer Body- Instanz, die durch einen Import als importiert gekennzeichnet sind, ihre Daten letztendlich aus der Body-Instanz beziehen, mit der sie über die entsprechenden Schnittstellen verbunden sind. Dabei ist zu berücksichtigen, dass Exports ihren 1 Mit Daten sind die Werte von Attributen gemeint

35 3.1 Import- und Export-Schnittstellen 29 Body (bzw. Imports ihren Export), zu dem sie delegieren müssen, kennen, importierte Bodys jedoch weder ihren Import kennen, noch wissen, dass sie importiert sind. Anforderung 1.9: Toleranz bezüglich nicht-erreichbarer Ressourcen Beschreibung Eine temporäre Nicht-Verfügbarkeit einer Komponente soll nicht als Ausnahme, sondern als typischer Fall angesehen werden. Da eine Delegation in diesem Fall nicht möglich ist, soll auf zwischengespeicherte Attribut-Werte zurückgegriffen werden. Erklärung In EMF werden aus anderen Ressourcen referenzierte Objekte entweder garnicht oder bei Bedarf aufgelöst (siehe 2.3.5). Schnittstellen-Instanzen sollen die aus anderen Komponenten referenzierten Objekte wenn möglich auflösen, aber nicht-auflösbare Proxys stillschweigend ignorieren. Anforderung 1.10: Erweiterte Standard-Constraints Beschreibung EMF-Instanzen müssen neben den nutzerdefinierten domänenspezifischen auch alle Standard-Constraints (siehe 2.3.4) erfüllen. Für Schnittstellen- Instanzen ergeben sich noch weitere Standard-Regeln. Diese sind dem Standard- Regelwerk von EMF hinzuzufügen. Erklärung In wurden strukturerhaltende Bedingungen für IC-Morphismen angegeben, aus denen sich Constraints für Schnittstellen-Modelle, aber auch für ihre Instanzen, ableiten lassen. Diese sind in Form von Standard-Constraints zu implementieren, die für jede beliebige Schnittstellen-Instanz gelten müssen. Anforderung 1.11: Kompatibilität zu dynamischem EMF Beschreibung Aus Schnittstellen-Modellen sollen sich dynamische Instanzen anlegen lassen. Erklärung Mit dynamischem EMF (2.3.3) lassen sich unter Verwendung der reflektiven Ecore-API Instanzen von Modellen anlegen, zu denen kein generierter Code vorliegt. Dies soll auch bei Schnittstellen-Modellen möglich sein. Die Delegation (Anforderung 1.8) soll daher nach Möglichkeit nicht durch den generierten Code (etwa mithilfe angepasster Code-Templates) sondern einer dynamischeren Lösung umgesetzt werden.

36 30 3 Anforderungsbeschreibung 3.2. Komponenten-Infrastruktur Konzeptionelle Anforderungen Die Netzwerkstruktur einer Komponente ist auf Typ- und Instanzebene implizit durch die Beziehungen der Bodys und Schnittstellen gegeben. Für eine effektive Verwaltung von Komponenten ist ein EMF-basiertes Datenmodell mit einer entsprechenden expliziten Datenstruktur zu erstellen. Über diesen Netzwerkgraphen sollen die Bestandteile einer Komponente, also die verfeinernden Graphen der Netzwerkknoten, auffindbar sein. Die Datenstruktur soll als Grundlage für einen baumbasierten Editor (3.3) dienen. Mit den Editoren sollen sich Komponenten und ihre Bestandteile erstellen und bearbeiten lassen. Komponenten sollen zudem in einer zentralen Registry verwaltet werden. Anforderung 2.1: Registrieren von Komponenten in einer Registry Beschreibung Es soll eine Komponenten-Registry realisiert werden, in die Komponenten aufgenommen und abgefragt werden können. Erklärung EMF stellt eine Package-Registry zur Verfügung, in der EPackages registriert werden können. Für Komponenten soll dies auf ähnliche Weise möglich sein. Ergonomische Anforderungen Anforderung 2.2: Komponenten-Registry-View Beschreibung Für die Komponenten-Registry soll eine Eclipse-View implementiert werden, in der alle registrierten Komponenten sichtbar sind. Erklärung Views zeigen ähnlich wie Editoren diverse Informationen in einem Fenster an, sind jedoch weniger auf das Ändern von Daten ausgelegt. Funktionale Anforderungen Anwendungsfall 2.3: Komponente registrieren Zusammenfassung Dem Nutzer soll es möglich sein, eine Komponente beispielsweise aus dem Editor heraus per Kontextmenü der Registry hinzuzufügen.

37 3.3 Baumeditor 31 Vorbedingung Der Nutzer hat eine Komponente selektiert. Die Operation wird durch ein Kontextmenü aufgerufen. Ablauf Die Komponente wird validiert. Bei erfolgreicher Validierung wird sie in die Registry aufgenommen und dem Nutzer wird eine Erfolgsmeldung angezeigt. Andernfalls wird die Registrierung nicht durchgeführt und dem Nutzer eine entsprechende Fehlermeldung präsentiert. Nachbedingung Die Komponente ist in die Registry aufgenommen falls sie valide ist (ansonsten nicht). Anwendungsfall 2.4: Komponente aus Registry entfernen Zusammenfassung Die Registrierung einer Komponente soll sich aufheben lassen. Vorbedingung Der Nutzer hat eine registrierte Komponente in der Komponenten- Registry-View selektiert. Die Operation wird durch ein Bedienelement aufgerufen. Ablauf Dem Nutzer wird eine Sicherheitsabfrage angezeigt, die er mit Ja oder Nein beantworten muss. Bei positiver Antwort wird die Komponente aus der Registry entfernt, andernfalls passiert nichts. Nachbedingung Die Komponente ist nicht mehr in der Registry vorhanden und wird auch nicht von der View angezeigt Baumeditor Die einzelnen Bestandteile einer Komponente sollen sowohl auf Typ- als auch auf Instanzebene jeweils gemeinsam in einem EMF-generierten Editor bearbeitet werden. Da über den Netzwerkgraphen alle Bestandteile einer Komponente verfügbar sind, bietet sich der Baumeditor des Netzwerkmodells an. Ergonomische Anforderungen Anforderung 3.1: Benutzerführung für das Bearbeiten von Schnittstellen- Modellen Beschreibung Die Zuordnung der Schnittstellen-Modellelemente zu ihren Body- (ggf. Export-) Elementen soll durch geeignete Filter erleichtert werden. Erklärung Die Properties-View eines EMF-Editors erlaubt bei Referenzen die Auswahl aller möglichen Objekte vom Typ der Referenz. Im komponentenorien-

38 32 3 Anforderungsbeschreibung tierten Kontext können diese beschränkt werden um die Auswahl zu erleichtern. Anforderung 3.2: Optische Hervorhebung korrespondierender Elemente Beschreibung Der Editor soll die Zusammengehörigkeit der Elemente im Baum visualisieren. Erklärung Wird beispielsweise ein Import-Objekt ausgewählt, sollen dessen Bodyund Export-Objekt optisch hervorgehoben werden (etwa farblich oder dergleichen). Funktionale Anforderungen Anwendungsfall 3.3: Erstellen von Netzwerkgraphen auf Basis vorhandener Komponenten-Teile Zusammenfassung Der Nutzer soll beim Erstellen eines Netzwerkgraphen die Möglichkeit bekommen, vorhandene Bodys, Imports und Exports auszuwählen, aus denen dann gemäß ihrer Beziehungen Komponenten gebildet werden. Vorbedingung Es liegen bereits Komponenten-Teile (mit implizitier Komponenten- Struktur) vor. Ablauf Der Nutzer ruft den Wizard zur Erstellung eines Netzwerkgraphen auf. Über einen Auswahldialog kann er vorhandene Komponenten-Teile auswählen. Diese werden analysiert um daraus eine explizite Komponenten-Struktur zu extrahieren. Nachbedingung Der neue Netzwerkgraph besteht aus den gewählten Komponenten-Teilen und spiegelt deren Verteilungs-Struktur wider. Jedes gewählte Komponenten-Teil ist einem Netzwerkknoten als verfeinernder Graph zugeordnet. Anwendungsfall 3.4: Exportieren und Importieren per Drag&Drop Zusammenfassung Der Editor soll dem Nutzer eine Drag&Drop-Funktion zum Exportieren und Importieren von Objekten anbieten. Vorbedingung Der Typ des zu exportierenden bzw. importierenden Objekts ist Teil des Schnittstellen-Modells. Ablauf Der Nutzer zieht ein zu exportierendes Objekt vom Body auf die Export- Schnittstelle oder ein zu importierendes Objekt von der Export- in die Import- Schnittstelle. Nachbedingung Ein typkonformer Export bzw. Import wurde erzeugt und ist dem Body- bzw. Export-Objekt zugeordnet.

39 Kapitel 4. Entwurf In diesem Kapitel wird ein grundlegender Entwurf für komponentenorientierte Modelle vorgestellt. Im ersten Teil werden wir ein Konzept zur Definition von Export- und Import-Schnittstellen auf Typebene darlegen. Dabei wird ein EMF Metamodell entstehen, mit dem es möglich ist, Export- und Import-Modelle im Sinne von zu spezifizieren. Anschließend entwerfen wir einen Delegationsmechanismus für Datenabfragen auf Schnittstellen-Instanzen. Im zweiten Teil stellen wir ein Konzept zur Organisation von Komponenten auf Netzwerkebene vor Import- und Export-Schnittstellen Aus Export- und Import-Schnittstellen soll sich wieder mithilfe von EMF Code generieren lassen. Gemäß Anforderung 1.1 sollen Ecore-Modelle als Body-Modelle agieren. Es liegt daher nahe, auch Schnittstellen-Modelle als Ecore-Modelle umzusetzen. Die meisten Werkzeuge, allen voran der EMF-Generator, können dann weitestgehend auch für Schnittstellen-Modelle wiederverwendet werden. Allerdings müssen Morphismen zwischen Exports und Imports sowie zwischen Schnittstellen und ihrem Body (siehe 2.4.2) enthalten sein. Konkret sollen Klassen einer Schnittstelle auf Klassen ihres Bodys verweisen, Klassen einer Import-Schnittstelle zusätzlich auf Klassen ihres Exports. Dieses Prinzip übertragen wir auch auf Attribute, Referenzen und Pakete. Zwar werden Attribute und Pakete in der Formalisierung nicht explizit berücksichtigt, unser Konzept tut dem jedoch keinen Abbruch. Wir können Attribute ähnlich wie Referenzen behandeln. Eine Möglichkeit, diese Zuordnungen in Ecore-Modellen unterzubringen wäre, Annotationen (EAnnotation) auf den Modellelementen zu platzieren. Annotationen sind ein generisches Konzept mit dem Ecore-Modelle um beliebige Metadaten angereichert werden können. Das automatische Hinzufügen und das Verarbeiten dieser Annotationen müsste in den entsprechenden Werkzeugen, also den Editoren, mit denen Schnittstellen-Modelle bearbeitet werden, implementiert werden. Ein Schnittstellen-Modell mit dynamischem EMF (siehe 2.3.3) aufzubauen, wäre so jedoch nicht ohne weiteres möglich. Wir gehen daher einen anderen Weg und erweitern das Ecore Metamodell durch Vererbung. Die dabei entstehenden Meta-

40 34 4 Entwurf Ecore M3... body body EExport EExport Model Ecore exported Ecore Model exported body EImport body EImport Model M2 M1 Legend: extends elements of refers to is typed over body EExport Instance EMF Instance exported body EImport Instance M0 Abbildung 4.1.: Schnittstellen in der MOF Meta-Architektur (nach [Jur12]) modelle befinden sich dann zusammen mit Ecore auf der MOF-Ebene M2 (Abb. 4.1). Da die Body- und Schnittstellen-Modelle jeweils in eigenen Ressourcen vorliegen, werden dokumentübergreifende Referenzen (engl. crossreferences) zum Einsatz kommen, ein Konzept, das wir in kennengelernt haben. Im Gegensatz zum Annotationen-basierten Ansatz können diese Referenzen direkt im Code, also von den Modellelementen selbst, verwaltet werden, womit sich unser Ansatz auch als kompatibel zu dynamischem EMF erweist Erweiterung des Ecore Metamodells Das Metamodell für Export-Schnittstellen nennen wir EExport, das für Import- Schnittstellen EImport. In beiden erstellen wir jeweils Unterklassen von EPackage, eclassifiers EPackage (from ecore) 0..* 1 bodypackage EClassifier (from ecore) 1 EClass (from ecore) bodyclass estructuralfeatures EReference (from ecore) EStructuralFeature (from ecore) EAttribute (from ecore) ExportedPackage ExportedClass ExportedReference ExportedAttribute 0..* 1 bodyreference 1 bodyattribute Abbildung 4.2.: Erste Version des EExport Metamodells EClass, EAttribute und EReference. Jede beginnt mit dem Präfix Exported bzw. Imported. Durch das Laden von Ecore.ecore, die Datei, welche das Ecore Metamodell enthält (siehe 2.3.5), bekommen wir Zugriff auf die Metaklassen und können

41 4.1 Import- und Export-Schnittstellen 35 sie der Liste der Oberklassen (esupertypes) hinzufügen. Die Morphismen zu den Body-Elementen setzen wir durch geeignete Referenzen um. Die Multiplizität setzen wir dabei auf 1 (nicht etwa 0..1), da es sich um totale Morphismen handelt. Abb. 4.2 bodypackage 1 EPackage (from ecore) bodypackage 1 bodyclass 1 EClass (from ecore) 1 bodyclass ExportedPackage 1 ImportedPackage (from eexport) exportedpackage ExportedClass (from eexport) 1 exportedclass ImportedClass bodyreference 1 EReference (from ecore) bodyreference 1 bodyattribute 1 EAttribute (from ecore) 1 bodyattribute ExportedReference (from eexport) 1 exportedreference ImportedReference ExportedAttribute 1 ImportedAttribute (from eexport) exportedattribute Abbildung 4.3.: Erste Version des EImport Metamodells zeigt die erste Version von EExport. Klassen des Ecore-Metamodells sind in blau dargestellt und mit Shortcut-Symbolen versehen. ExportedPackage, ExportedClass, ExportedReference sowie ExportedAttribute erben hier direkt von den Ecore Meta-Klassen. EImport ist in Abb. 4.3 zu sehen. Betrachten wir die beiden Metamodelle, fällt auf, dass die Referenzen zu den Body-Elementen redundant vorhanden sind. Die Klassen in EImport unterscheiden sich von denen aus EExport, abgesehen von ihrem Namen, nur durch ihre zusätzliche Referenz zu den Export-Elementen. Man könnte sie also auch von diesen erben lassen. Streng genommen liegt jedoch keine ist-ein -Beziehung vor: Ein Import ist kein Export. Wir lagern ihre Gemeinsamkeiten daher in gemeinsame Oberklassen aus, die wir mit dem Präfix Composite versehen. Abb. 4.4 zeigt die optimierten Versionen von EExport und EImport in einem gemeinsamen Diagramm. Basierend auf diesen Metamodellen können komponentenorientierte Modelle im Sinne von erstellt werden. Instanzen von EExport bzw. EImport sind dann Ecore-Modelle mit komponentenorientierter Erweiterung. In Anforderung 1.2 wird gefordert, dass für Schnittstellen-Modelle keine Wurzelklasse benötigt werden soll. Abhilfe schaffen wir mit einer automatisch erzeugten Container-Klasse mit Containment- Referenzen zu allen Schnittstellen-Klassen. Dies ist später im Rahmen der Implementierung umzusetzen.

42 36 4 Entwurf EPackage (from ecore) CompositePackage (from eexport) 1 bodypackage EClass (from ecore) CompositeClass (from eexport) 1 bodyclass ExportedPackage 1 ImportedPackage (from eexport) exportedpackage ExportedClass (from eexport) 1 exportedclass ImportedClass EReference (from ecore) CompositeReference (from eexport) 1 bodyreference EAttribute (from ecore) 1 bodyattribute CompositeAttribute (from eexport) ExportedReference (from eexport) 1 exportedreference ImportedReference ExportedAttribute 1 ImportedAttribute (from eexport) exportedattribute Abbildung 4.4.: Finale Versionen von EExport und EImport Modell-Constraints Um für Schnittstellen-Modelle eine einfachere Struktur zu erlauben, sind Constraints (siehe 2.3.4) zu formulieren. Eine Invariante für Ecore-Modelle ist beispielsweise, dass die untere Schranke der Multiplizität einer Referenz kleiner oder gleich der oberen Schranke sein muss (lowerbound <= upperbound) 1. Alle Constraints für Ecore-Modelle gelten aufgrund der Vererbungsbeziehungen automatisch auch für Schnittstellen-Modelle. Diese sind also noch in Hinblick auf die Komponenten- Struktur zu ergänzen. Wir unterscheiden zwischen strukturerhaltenden und technischen Constraints. Strukturerhaltende Constraints sind durch die strukturerhaltenden IC-Morphismen der Formalisierung vorgegeben. Einige für die Umsetzung mit EMF relevante Aspekte werden jedoch nicht durch die Theorie abgedeckt. Diese Lücken versuchen die technischen Constraints zu schließen. Technische Constraints Schnittstellen-Pakete (ExportedPackage bzw. ImportedPackage) enthalten nur Schnittstellen-Klassen (ExportedClass bzw. ImportedClass) und keine gewöhnlichen (EClass). Schnittstellen-Klassen enthalten nur Schnittstellen-Attribute und -Referenzen und keine gewöhnlichen. 1 Eine Ausnahme bildet eine nach oben unbeschränkte Referenz, die durch einen upperbound von -1 ausgezeichnet ist.

43 4.1 Import- und Export-Schnittstellen 37 Schnittstellen-Attribute haben den gleichen Datentyp wie ihr Body-/Export- Attribut. Schnittstellen-Referenzen haben die gleiche Multiplizität wie ihre Body-/Export- Referenz. Schnittstellen-Klassen haben nur Schnittstellen-Klassen als Oberklassen. Die Body-/Export-Klasse einer Schnittstellen-Klasse befindet sich im Body- /Export-Paket des Schnittstellen-Pakets. Strukturerhaltende Constraints In der folgenden Aufzählung sind die strukturerhaltenden Bedingungen für IC- Morphismen aus mit größerer Nähe zum vorgestellten Entwurf formuliert. 1. Erbt eine Schnittstellen-Klasse A von einer Schnittstellen-Klasse B, so ist die Body-/Export-Klasse von A eine Unterklasse von Bs Body-/Export-Klasse. 2. Ist die Containment-Eigenschaft einer Schnittstellen-Referenz gesetzt, so ist auch die Body-/Export-Referenz eine Containment-Referenz. Ist sie nicht gesetzt, ist die Containment-Eigenschaft der Body-/Export-Referenz beliebig. 3. Die Body-/Export-Referenz einer Schnittstellen-Referenz ist in der Body- /Export-Klasse der Schnittstellen-Klasse oder einer Oberklasse davon enthalten. Gleiches gilt für Schnittstellen-Attribute. 4. Sei A der Typ einer Schnittstellen-Referenz und B der Typ ihrer Body-/Export- Referenz. Dann ist die Body-/Export-Klasse von A eine Unterklasse von B oder B selbst. (1) entspricht der Bedingung, dass Vererbungs-Clans auf Vererbungs-Clans abgebildet werden, (2) der Bedingung, dass Containment-Kanten auf Containment-Kanten abgebildet werden. (3) und (4) ergeben zusammen die Forderung nach einer Vererbungs- Clan-kompatiblen Kanten-Abbildung. Die Anwendung von (3) auf Attribute ergibt sich daraus, dass wir diese ähnlich zu Referenzen behandeln, obwohl sie von der Theorie nicht abgedeckt sind Delegation von Datenabfragen Konkrete Objekte einer Export- oder Import-Schnittstelle sollen Datenabfragen gemäß Anforderung 1.8 delegieren. Auf Typebene ist jeder Schnittstellen-Klasse eine Body-Klasse sowie Import-Klassen zusätzlich eine Export-Klasse zugeordnet. Diese Zuordnung ist auch auf die Instanzebene zu übertragen: Instanzen einer

44 38 4 Entwurf Schnittstellen-Klasse ordnen wir eine Instanz der Body- bzw. Export-Klasse zu. Speichern können wir sie direkt in den Schnittstellen-Objekten, allerdings benötigen sie dafür jeweils eine typgerechte Referenz. Diese kann der Schnittstellen-Klasse bei der Modellierung automatisch hinzugefügt werden, sobald die Body- bzw. Export- Klasse durch den Nutzer gesetzt wird. Ihr Typ ist die Body-/Export-Klasse. Sie sollten für den Nutzer bei der Modellierung nicht sichtbar (und dadurch auch nicht manuell veränderbar) sein. Zudem müssen wir sie bei der Validierung ignorieren, denn ein technischer Constraint besagt, dass eine Schnittstellen-Klasse keine gewöhnliche Referenzen enthalten darf. Wir nennen die beiden Referenzen schlicht body bzw. exported und bezeichnen dementsprechend die von konkreten Schnittstellen-Instanzen referenzierten Objekte als body-objekt bzw. exported-objekt. Zu beachten ist, dass die Referenzen innerhalb einer Vererbungshierarchie nur einmal auftreten dürfen - mehrere Referenzen mit gleichem Namen sind in einer Klasse nicht erlaubt. Erbt eine Schnittstellen-Klasse von einer anderen, muss sie die von der Oberklasse geerbte body- bzw. exported- Referenz mitbenutzen. Abb. 4.5 veranschaulicht dies anhand zweier Export-Klassen (rechts) mit Vererbungsbeziehung. Die body-referenz ist hier für beide Klassen vom Typ A, da BExp keine eigene gleichnamige Referenz definieren darf. Instanzen von B können aber problemlos von dieser Referenz gehalten werden, da B ein Subtyp von A ist. Da Vererbungs-Clans strukturerhaltend abgebildet werden, ist dies auch im Allgemeinen stets der Fall. A bodyclass AExp body: A B bodyclass BExp body: B Abbildung 4.5.: Zwei in Vererbungsbeziehung stehende Export-Klassen (rechts) mit ihren zwei Body-Klassen (links) aber nur einer body-referenz Skizzieren wir nun den Delegationsmechanismus beispielhaft anhand eines Exports: Wird der Attributwert eines exportierten Objekts abgefragt, muss die Abfrage an das body-objekt weitergeleitet werden. Wir könnten die Code-Templates (siehe 2.3) für Export-Klassen so anpassen, dass die für Export-Attribute generierten Getter- Methoden den Body-Attributwert des body-objekts zurückgeben. Der auf dem Body aufzurufende Getter kann anhand des bodyattribute des Export-Attributs ermittelt werden. Dieser Ansatz würde jedoch mit dynamischen Instanzen, bei denen kein generierter Code vorliegt, nicht funktionieren. Deshalb greifen wir zu den aus bekannten Setting Delegates. Einmal implementiert, kann auf jedem Export-Attribut ein geeignetes Setting Delegate, das die Delegation durchführt, installiert werden. Somit wären modifizierte Getter-Methoden nicht nötig.

45 4.1 Import- und Export-Schnittstellen 39 Für Instanzen einer Import-Schnittstelle ist das Vorgehen analog. Anstatt zum body-objekt wird hier zum exported-objekt delegiert. Schwieriger erweist sich die Delegation vom importierten Body-Objekt zum Import-Objekt. Der Body-Instanz ist nicht bekannt, dass einige ihrer Objekte importiert sind. Die betroffenen Objekte referenzieren nicht das Import-Objekt, durch das sie importiert werden, sondern werden von diesem referenziert. Delegation und Referenzierung verlaufen in entgegengesetzter Richtung, wie in Abb. 4.6 zu sehen. Da wir das Verhalten gewöhnlicher Klassen <deleg> <deleg> <deleg> B E I B body export body Abbildung 4.6.: Verlaufsrichtung der Referenzen vs. Verlaufsrichtung der Delegation (EClass) und ihrer Attribute (EAttribute) nicht verändern können, ist es uns nicht möglich, den importierten Body-Objekten ein Setting-Delegate unterzuschieben. Auch das Einbringen von Delegations-Code in die generierten Getter kommt aufgrund der Anforderung, dass Ecore-Modelle ohne Änderung als Body-Modelle einsetzbar sein sollen (Anforderung 1.1) nicht in Frage. Wir lösen dieses Problem mit Mitteln der aspektorientierten Programmierung (siehe 2.5) Erweiterte Standard-Constraints für Schnittstellen-Instanzen In Abschnitt haben wir Modell-Constraints für Schnittstellen-Modelle festgelegt. Für Instanzen davon ergeben sich noch zwei Standard-Constraints: 1. Für ein Schnittstellen-Objekt ist das body- bzw. exported-objekt vom Typ der bodyclass bzw. exportedclass der Schnittstellen-Klasse. 2. Der Objektgraph einer Schnittstellen-Instanz muss strukturverträglich zu dem der Body-/Export- Instanz sein: Zwei Objekte einer Schnittstellen-Instanz dürfen sich nur dann referenzieren, wenn auch ihre body-/exported- Objekte miteinander in Beziehung stehen. (1) spielt nur dann eine Rolle, wenn die Schnittstellen-Klasse des fraglichen Objekts von einer anderen abgeleitet ist. Der Typ der während der Modellierung automatisch erzeugten body-/exported-referenz entspricht dann unter Umständen nicht der Body- /Export-Klasse, sondern möglicherweise einer Oberklasse davon (siehe und Abb. 4.5). Es wäre somit möglich, ein Objekt allgemeineren Typs zuzuordnen, was jedoch nicht erlaubt ist. Constraint (2) ergibt sich durch die strukturerhaltende Eigenschaft

46 40 4 Entwurf von Morphismen. In Abb. 4.7 referenziert Objekt a der Schnittstellen-Instanz (rechts) Objekt b (roter Pfeil). Das body-/exported-objekt von a referenziert allerdings nicht das body-/exported-objekt von b, was gegen die gewünschte Eigenschaft verstößt. Body oder Export Schnittstelle b a Abbildung 4.7.: Strukturverträglichkeit von Schnittstellen-Instanzen: Die durch den roten Pfeil dargestellte Referenzierung ist nicht erlaubt 4.2. Komponenten Infrastruktur Die Netzwerkstruktur komponentenorientierter Modelle ergibt sich indirekt aus den einzelnen Bestandteilen einer Komponente Bodys und Schnittstellen und deren Beziehungen untereinander. Auch in der Formalisierung taucht das Konzept der Komponente nur implizit auf. Es stellt sich daher die Frage, ob die technische Umsetzung überhaupt einer expliziten Netzwerkstruktur bedarf. Wir haben uns in Abschnitt bereits mit der Problematik befasst, dass Bodys ihre Schnittstellen nicht kennen. Betrachtet man ein Body-Modell oder eine Body-Instanz isoliert, ist nicht zu erkennen, ob das Modell bzw. die Instanz zu einer Komponente gehört und wenn ja, zu welcher. Schnittstellen sind immerhin sofort als solche erkennbar, bei Imports sind referenzierter Body und Export sichtbar, bei Exports zumindest der referenzierte Body. Eine Datenstruktur für Komponenten, die alle Bestandteile kapselt, wäre aus Nutzersicht also durchaus hilfreich. Neben einem Datenmodell für Komponenten werden wir eine Komponenten-Registry entwerfen. Dort können Komponenten registriert und abgefragt werden Netzwerkmodell Abb. 4.8 zeigt das Datenmodell für Netzwerkgraphen. Wurzelbehälter ist die Klasse Composite, die eine beliebige Anzahl an Komponenten (Component) verwaltet. Die Zugehörigkeit einer Schnittstelle (Interface) spiegelt sich explizit in der Containment-Struktur wider: Sie sind direkt in ihrer Komponente enthalten. Die Zuordnung des verfeinernden Objektgraphs ist in der abstrakten Oberklasse Component- Part realisiert. Hier wird das Wurzelobjekt (rooteobject) der Objektgraph-Instanz

47 4.2 Komponenten Infrastruktur 41 sowie dessen Typ (epackage) festgehalten. name und epackageuri sind abgeleitete Attribute (derived). Der Name ergibt sich aus dem Ressource-Name von rooteobject, die Package-URI aus der Namespace-URI von epackage. Während Exports und Imports durch entsprechende Klassen (ExportInterface und ImportInterface) repräsentiert werden, gibt es keine Body-Klasse. Stattdessen ist die Komponente selbst dessen Stellvertreter. Das Einführen einer gesonderten Body-Klasse wäre eine unnötige Indirektion. Da die Containment-Referenz zwischen Komponenten und ihren Schnittstellen bidirektional ist, kann man von einer Schnittstelle mittels body zu ihrer Komponente, also ihrem Body, navigieren. EPackage (from ecore) 1 epackage ComponentPart name : EString epackageuri : EString rooteobject 1 EObject (from ecore) Interface interfaces 1 Component 0..* body 0..* components ExportInterface export ImportInterface Composite 1 Abbildung 4.8.: Composite Metamodell Mit diesem Modell sollen Komponenten auf Typ- und Instanzebene erstellt werden können: Orientiert man sich strikt an den Ebenen der MOF-Architektur, scheint es so, als benötige man ein zweites Netzwerkmodell. In der Praxis sind diese Ebenen jedoch nicht absolut, sondern relativ zu sehen: Jedes Modell ist auch gleichzeitig eine Instanz eine Instanz seines eigenen Metamodells. Doch auch dieses Metamodell ist eine Instanz seines eigenen, man kann dies beliebig fortführen. Das Ecore-Metamodell ist über sich selbst getypt, es ist also sein eigenes Metamodell und das für Ecore-Modelle, doch gleichwohl liegt es in Ecore.ecore als XMI-persistierte Instanz vor. Dementsprechend ist rooteobject eine über epackage getypte Instanz, es kann sich also sowohl um eine Body-/Schnittstellen-Instanz als auch um ein Body-/Schnittstellen-Modell handeln. Im ersten Fall wäre epackage entweder ein Ecore-, EExport- oder EImport-Modell, im zweiten Fall das Ecore-, EExport- oder EImport-Metamodell. Wir können mit diesem Modell also sowohl Komponenten auf Typ- als auch auf Instanzebene erstellen. Es ist nicht einmal nötig, direkt zu unterscheiden: Selbst ein Ecore-Modell könnte als Body-Instanz einer Komponente herhalten.

48 42 4 Entwurf Modell-Constraints Das Netzwerkmodell gleicht aus softwaretechnischer Sicht einer Art Wrapper-Struktur für die unterliegenden verfeinernden Objektgraphen. Die folgenden Constraints sollen sicherstellen, dass die Netzwerkstruktur auch mit der Objektstruktur übereinstimmt. Für jeden ComponentPart ist das rooteobject eines Instanz von epackage. Für eine Schnittstelle (Interface) entspricht der Body des rooteobject dem rooteobject der Body-Komponente. Für eine Import-Schnittstelle entspricht der Export des rooteobject dem rooteobject der Export-Schnittstelle (export: ExportInterface). Das epackage einer Schnittstelle ist entweder das EExport- bzw. EImport- Metamodell oder ein Schnittstellen-Modell, dessen bodypackage (exportedpackage) auf das epackage der Body-Komponente (Export-Schnittstelle) verweist. Anmerkung: Mit Body des rooteobject und Export des rooteobject ist im Falle eines Export-/Import-Pakets auch dessen bodypackage bzw. exportedpackage gemeint Komponenten-Registry In einer Composite-Instanz können beliebig viele Komponenten lokal definiert werden, insbesondere sollen aber Komponenten aus unterschiedlichen Systemen verbunden werden. Dokumentübergreifende Referenzen über Plattform-URIs greifen hier aber zu kurz. In dieser Umsetzung komponentenorientierter Modelle gehen wir bisher nur von einer lokalen Verteilung aus die Ressourcen befinden sich im Workspace des Nutzers. Flexibler wäre es, Komponenten über eine zentrale Registry anzusprechen. Eclipse verwendet beispielsweise eine Plug-in Registry, in der Informationen über alle von der Plattform zurzeit benutzten Plug-ins abgerufen werden können. Plug-ins greifen häufig auf die Extension-Registry zu, um verfügbare Extension-Points und konkrete Extensions (siehe 2.2.2) abzufragen. Für EMF-Modelle gibt es die Package-Registry: Generierte Packages werden per Extension-Point unter ihrer Namespace-URI registriert. Andere Modelle können über diese URI auf Modellelemente des EPackage zugreifen. Die physische URI wird dabei nicht benötigt. Spezielle URIHandler sorgen dafür, dass die (logische) Namespace-URI eines EPackage zur physischen URI aufgelöst wird. Für die Auflösung konsultieren sie die Package-Registry. Mit unseren Komponenten führen wir nun ein ähnliches Konzept ein. Eine Komponenten-Registry könnte die Komponenten von einem Server beziehen, auf den alle beteiligten Entwickler zugreifen. Auch wenn eine echte Verteilungs- Infrastruktur im Sinne einer Client-Server-Architektur nicht Teil dieser Arbeit ist, soll die Registry, im Hinblick auf eine zukünftige, prototypisch entworfen werden.

49 4.2 Komponenten Infrastruktur 43 ComponentRegistry register(component) : EDiagnosticChain unregister(component) getbyname(estring) : Component getbybody(estring) : Component getbybody(eobject) : Component allcomponents 0..* Component (from composite) Abbildung 4.9.: Komponenten-Registry Registriert werden sollen die Komponenten aus dem Editor heraus (siehe Anforderung 2.1 und Anwendungsfall 2.3). Die Registry soll als Singleton global ansprechbar sein. In Abb. 4.9 sind ihre Methoden aufgeführt. Mit register() können Komponenten registriert werden, mit unregister() kann eine Registrierung zurückgenommen werden. Da nur valide Komponenten registrierbar sein sollen, gibt register() die Statusmeldung in Form einer DiagnosticChain zurück. Komponenten werden zum einen unter ihrem Namen, zum anderen anhand der Resource-URI des rooteobject registriert. Dies soll es ermöglichen, zu einem gegebenen EObject herauszufinden, ob es zu einer Komponente gehört und falls ja, zu welcher. getbybody() nimmt ein EObject oder die URI seiner Ressource als String entgegen, navigiert gegebenenfalls zum Body-Objekt und kann anhand der URI des Body-Objekt die zugehörige Komponente, sofern registriert, liefern. Zudem ermöglichen wir das Ansteuern einer Komponente über ein URI-Schema. Es soll die Form component:/<componentname>/ haben, wobei <componentname> der Name der Komponente ist. Schnittstellen einer Komponente können mithilfe eines anzuhängenden URI-Fragments referenziert werden.

50

51 Kapitel 5. Implementierung Aufbauend auf dem vorangegangenen Entwurf (Kapitel 4) kann die Implementierung komponentenorientierter Modelle erfolgen. Zunächst werden Anpassungen an der grundlegenden Infrastruktur für Schnittstellen-Modelle und -Instanzen vorgestellt. Geeignete Editoren und Werkzeuge sollen das Erstellen und Bearbeiten von Komponenten und ihren Bestandteilen erleichtern: Ein baumbasierter Editor soll dem Bearbeiten von Import- und Export-Schnittstellen auf Typ- und Instanzebene dienen. Eine Komponenten-Registry soll das Verwalten von Komponenten mit Hilfe einer Eclipse-View ermöglichen Import- und Export-Schnittstellen In 4.1 wurde die grundlegende Infrastruktur komponentenorientierter Modelle vorgestellt. Dabei sind unter anderem die Metamodelle EExport und EImport enstanden. Damit können Export- und Import-Modelle auf ähnliche Weise wie Ecore-Modelle angelegt werden, die dann die Dateiendung eexport bzw. eimport tragen. In diesem Abschnitt befassen wir uns mit der Umsetzung von Schnittstellen-Modellen, dem Delegationsmechanismus von Schnittstellen-Instanzen und einigen Anpassungen am Codegenerierungs-Prozess EExport und EImport In haben wir das Ecore-Metamodell erweitert. Wir haben dort auch festgelegt, dass Schnittstellen-Klassen automatisch über eine body- bzw. exported-referenz vom Typ der Body-/Export-Klasse verfügen sollen. Diese sollen die Morphismen auf Instanzebene verkörpern und sind insbesondere für die Delegation wichtig. Ferner sollen Schnittstellen-Pakete stets eine Wurzelklasse enthalten, die alle in der Schnittstelle definierten Objekte tragen kann. Beides muss unabhängig davon, wie das Modell erstellt wurde ob durch Werkzeugunterstützung oder programmatisch (dynamisches EMF) vorhanden sein. Wir implementieren dies also direkt im EMF-generierten Modell-Code von EExport und EImport. Dabei werden wir von EMFs Adapter-Konzept Gebrauch machen: Jedem EObject kann eine Menge von

52 46 5 Implementierung Adaptern zugeordnet werden. Ein Adapter ist prinzipiell ein Observer im Sinne des Observer-Patterns, der auf Änderungen an dem beobachteten EObject reagiert. Strukturerhaltende Constraints In haben wir technische und strukturerhaltende Constraints für Schnittstellen- Modelle festgehalten. Da die strukturerhaltenden Constraints ein zentraler Aspekt dieser Realisierung komponentenorientierter Modelle ist, wollen wir uns deren Umsetzung im Detail widmen. Zunächst wurden sie in der Sprache OCL verfasst. Da die vorliegende OCL-Implementierung keine Spezifikation von eigenen Validierungs- Nachrichten erlaubt, wurden die Constraints später in Java-Code überführt. Aufgrund der kompakten Syntax werden wir an dieser Stelle dennoch die OCL-Ausdrücke angeben. Wir kommen hier mit wenigen OCL-Schlüsselwörtern aus. self entspricht dem Java-Schlüsselwort this. Mit dem Punkt-Operator werden Features eines Objekts ausgewählt, c.eallsupertypes gibt also die Menge aller Oberklassen einer EClass c zurück (das Feature esupertypes umfasst nur die direkten Oberklassen). forall(e Ausdruck) ist ein mathematischer Allquantor der mit dem Operator -> auf Listen angewandt werden kann und für alle Elemente e verlangt, dass Ausdruck wahr ist. includes() entspricht der typischen Listen-Abfrage contains(). Im Folgenden sind die 4 Constraints unter Angabe des Kontexts, also der Klasse, auf der sie definiert sind, und des OCL-Ausdrucks aufgeführt. Für eine bessere Übersichtlichkeit wurden Typumwandlungen (Casts) entfernt. Constraint (1) Abbilden von Vererbungs-Clans auf Vererbungs-Clans Kontext CompositeClass OCL self.esupertypes->forall(c self.bodyclass.eallsupertypes->includes(c. bodyclass)) Kontext ImportedClass OCL self.esupertypes->forall(c self.exportedclass.eallsupertypes-> includes(c.exportedclass)) Constraint (2) Abbilden von Containment-Kanten auf Containment-Kanten Kontext CompositeReference OCL self.containment implies bodyreference.containment Kontext ImportedReference

53 5.1 Import- und Export-Schnittstellen 47 OCL self.containment implies exportedreference.containment Constraint (3) Vererbungs-Clan-kompatible Kanten-Abbildung: Assoziations-Anfang Kontext CompositeReference OCL self.econtainingclass.bodyclass.eallstructuralfeatures->includes(self. bodyreference) Kontext ImportedReference OCL self.econtainingclass.exportedclass.eallstructuralfeatures->includes( self.exportedreference) Constraint (4) Vererbungs-Clan-kompatible Kanten-Abbildung: Assoziations-Ende Kontext CompositeReference OCL self.etype.bodyclass = self.bodyreference.etype or self.etype.bodyclass. esupertypes->includes(bodyreference.etype) Kontext ImportedReference OCL self.etype.exportedclass = self.exportedreference.etype or self.etype. exportedclass.esupertypes->includes(exportedreference.etype) Body-/Export-Referenzen Wird die bodyclass einer Schnittstellen-Klasse oder die exportedclass einer Import- Klasse erstmalig gesetzt, ist eine Referenz mit dem Namen body bzw. exported und der gesetzten Body-/Export-Klasse als Typ zu erzeugen und der Schnittstellen- Klasse hinzuzufügen. Bei einer Änderung der bodyclass bzw. exportedclass ist der Typ der Referenz anzupassen. Die Multiplizität setzen wir auf 1 (lowerbound = upperbound = 1) und die Eigenschaft resolveproxies auf false. Letzteres um zu verhindern, dass nicht-verfügbare Ressourcen zu einem Fehler (bzw. einer Ausnahme) führen. Wir implementieren dies direkt in den Setter-Methoden für bodyclass und exportedclass. Allerdings müssen, wie bereits in festgestellt,

54 48 5 Implementierung Vererbungsstrukturen berücksichtigt werden. Dabei genügt es nicht, im Setter zu überprüfen, ob durch eine Oberklasse bereits eine Referenz vorhanden ist. Die Oberklasse könnte nach dem Setzen der Body-/Export-Klasse hinzugefügt werden. Wir heften deshalb an jede Schnittstellen-Klasse einen Adapter an, der die Liste der Oberklassen (esupertypes) observiert und die Anwesenheit der gewünschten Referenz(en) sicherstellt. Automatische Wurzelklasse Jedes Schnittstellen-Modell soll eine Klasse mit Containment-Referenzen zu allen Schnittstellen-Klassen aufweisen. Diese Funktionalität setzen wir in Schnittstellen- Paketen um. Die Klasse selbst, wir nennen sie Container, kann beim Erzeugen des Pakets mit angelegt werden. Die Containment-Referenzen hingegen müssen immer dann erstellt werden, wenn dem Paket neue Klassen hinzugefügt werden und entfernt werden, falls die Klasse gelöscht wird. Wir überwachen dies auch wieder mit einem eigens dafür vorgesehenen Adapter. Als Name für die Referenz kann die pluralisierte Form des Klassennamens genommen werden, die Multiplizität wird auf 0..* gesetzt. Eine Containment-Referenz zu jeder Schnittstellen-Klasse ist unter Umständen nicht nötig: Für Unterklassen genügt eine Containment-Referenz zu ihrer Oberklasse. Der Adapter überwacht also, ähnlich dem für die Body-/Export- Referenzen, auch Änderungen an der Vererbungshierarchie und entfernt bei Bedarf überflüssige Containment-Referenzen. In Abb. 5.1 wird dem Ausgangs-Modell (links) eine neue Klasse Dog hinzugefügt (mitte) was in einer Referenz dogs vom Typ Dog resultiert. Nachdem Animal als Oberklasse von Dog deklariert wurde (rechts), ist die Referenz jedoch unnötig und wird automatisch wieder entfernt. Abbildung 5.1.: Container-Klasse eines Export-Modells mit automatisch erzeugten Containment-Referenzen Schnittstellen-Modell Wizard Zum Umfang des generierten Editor-Codes von EExport und EImport gehören Wizards zum Erstellen von Export- und Import-Modellen. Wie bei Ecore-Modellen wird hier initial ein leeres Paket ohne Klassen erstellt. Da ein Schnittstellen-Modell

55 5.1 Import- und Export-Schnittstellen 49 mit hoher Wahrscheinlichkeit eine ähnliche Struktur wie sein Body-Modell aufweisen wird, ist es nur konsequent, bereits beim Erzeugen des Schnittstellen-Modells die Möglichkeit anzubieten, eine Teilmenge der Modellelemente des Bodys auszuwählen (Anwendungsfall 1.6). Wir erweitern die beiden Wizards um zwei Seiten (WizardPages). Auf der ersten kann das Body-Modell und ggf. das Export-Modell (für ein Import-Modell) aus dem Workspace oder der Package Registry ausgewählt werden, womit wir auch Anwendungsfall 1.5 gleich mit umgesetzt haben. Auf der zweiten Seite sie erscheint nur, sofern auf der vorherigen Seite auch ein Body-Modell gewählt wurde zeigen wir alle Klassen des Body-Modells mit ihren Attributen und Referenzen in einer Baumansicht mit Kontrollkästchen (Checkboxen) an. Ziel ist es hier nicht, alle möglichen Vereinfachungen der Modellstruktur abzudecken. Die Vorauswahl von Modellelementen soll lediglich das Aufsetzen eines neuen Schnittstellen-Modells beschleunigen. Gewisse Vereinfachungen können wir jedoch erlauben: Attribute oder Referenzen können ohne die sie definierende Klasse ausgewählt werden, allerdings muss dann eine Unterklasse ausgewählt sein, in die das Attribut oder die Referenz hineingezogen werden kann. Auch das Assoziationsende (also der Typ) einer Referenz muss nicht Teil der selektierten Klassen sein, wenn dafür eine Unterklasse ausgewählt ist. In Abb. 5.2 ist der Import-Modell Wizard zu sehen. Das gewählte Body-Modell Abbildung 5.2.: Import-Modell Wizard mit Vorauswahl von Modellelementen des Body-Modells enthält eine Klasse Member, dessen name-attribut Teil das Import-Modells sein soll, jedoch nicht die Klasse Member selbst. EmployedMember ist aber ausgewählt und kann als Unterklasse von Member das Attribut aufnehmen. Wurde eine ungültige Auswahl getroffen, wird dies durch eine Fehlermeldung signalisiert und die Buttons Next und Finish sind deaktiviert. Andernfalls kann der Wizard mit seiner Arbeit beginnen. Zu jeder gewählten Klasse legt er im in-

56 50 5 Implementierung itialen Schnittstellen-Modell eine gleichnamige Schnittstellen-Klasse an, die auf die Body-Klasse zeigt (bodyclass). Vererbungsstrukturen werden dabei 1:1 übernommen. Für jedes gewählte Attribut und jede Referenz, deren definierende Klasse nicht Teil der Auswahl ist, wird zunächst eine Menge von Klassen bestimmt, die zum einen Teil der Auswahl und zum anderen eine Unterklasse dieser nicht ausgewählten sind. Das Attribut bzw. die Referenz wird nun nicht etwa jeder Klasse dieser Teilmenge hinzugefügt, sondern pro Vererbungshierarchie nur der obersten Klasse. Bei Referenzen wird der Typ analog bestimmt. Ist er nicht Teil der Auswahl, wird nach einer gewählten Unterklasse gesucht und der erste Treffer genommen. Dem Wizard für Import-Modelle spendieren wir noch eine dritte Seite, auf der die Zuordnung zwischen Import- und Export-Modell vorgenommen werden kann. Sie erscheint nur, wenn Body- und Export-Modell vorausgewählt und auf der vorherigen Seite (vgl. Abb. 5.2) Modellelemente des Body-Modells selektiert wurden. Ungültige Zuweisungen werden dem Nutzer als Warnung signalisiert. Eine völlige Unterbindung unzulässiger Zuweisungen wäre zu restriktiv. Ein Abschließen des Wizards ist also in jedem Fall möglich, das resultierende Modell ist aber gegebenenfalls in einem inkonsistenten Zustand. Abbildung 5.3.: Zuordnung von Import- zu Export-Modellelementen im Import- Modell Wizard Delegation Die Delegation von Datenabfragen wird, wie in bereits erwähnt, durch zwei Maßnahmen umgesetzt. Zwischen Import und Export sowie zwischen Export und Body vermittelt ein Setting Delegate (2.3.6). Importierte Body-Objekte werden durch Techniken der aspektorientierten Programmierung (2.5) dazu gebracht, ihre Daten aus den Import-Objekten zu beziehen.

57 5.1 Import- und Export-Schnittstellen 51 Setting Delegate Ein Setting Delegate muss die gleichnamige (Java-) Schnittstelle implementieren, die im Wesentlichen die Methoden dynamicget() und dynamicset() umfasst. Sie sind in ihrer Bedeutung vergleichbar mit eget() bzw. eset() der EObject API (2.3.3). Dem Setting Delegate wird im Konstruktor das Attribut (als EStructuralFeature) übergeben. Die Delegation setzen wir in dynamicget um, wobei wir das Objekt, dessen Datenabfrage delegiert werden soll, als Parameter bekommen. Es ist entweder ein Import oder ein Export. Zunächst wird das Body-Objekt des Exports oder das Export-Objekt des Imports abgefragt. Es liegt beim ersten Zugriff als Proxy (siehe 2.3.5) vor, das manuell aufgelöst werden muss. Ist das nicht möglich, wird als Attributwert ein im Import/Export zwischengespeicherter Wert zurückgegeben. Andernfalls wird das bodyattribute oder exportedattribute ermittelt und dessen Wert auf dem aufgelösten Zielobjekt abgefragt. Der Wert wird zwischengespeichert, damit er bei zukünftigen Abfragen im Falle eines nicht-erreichbaren Body-/Export-Objekts ersatzweise zurückgegeben werden kann. Abb. 5.4 zeigt in vereinfachter Form den Ablauf der Delegation. Abbildung 5.4.: Ablauf der Delegation Jedem EStructuralFeature kann ein Setting Delegate zugewiesen werden. Unseren Export- und Import-Attributen können wir also bei ihrer Erstellung automatisch eines anheften. Wir müssen EMF aber noch dazu bringen, das Setting Delegate bei der Abfrage auch tatsächlich zu nutzen. Bei dynamischen Instanzen wird immer ein Setting Delegate genutzt: Das generische Objekt-Array mit den Datenwerten aller Attribute und Referenzen ist durch ein internes Setting Delegate gekapselt, das von DynamicEObject immer verwendet wird. Anders verhält es sich im Falle von generiertem Code. Standardmäßig geben EMF-generierte Getter-Methoden den aktuellen Wert des generierten Feldes zurück. Registriert man ein Setting Delegate mithilfe von Annotationen im Ecore-Modell, wird dies vom Generator erkannt und ein aus der Annotation abgeleitetes Setting Delegate wird genutzt. Da wir keine Annotationen nutzen, setzen wir stattdessen im Generator des Schnittstellen-Modells die Eigenschaft Feature Delegation auf Dynamic (diesen Schritt werden wir später noch automatisieren). Dadurch werden in den Schnittstellen-Klassen keine Felder generiert und alle Datenmanipulationen laufen über ein Setting Delegate (ggf. über das interne, wie bei dynamischem EMF).

58 52 5 Implementierung Aspect-Weaving Importierten Body-Objekten könnte zwar ein Setting Delegate injiziert werden, da aber im Allgemeinen davon ausgegangen werden muss, dass der Code ohne dynamische Feature Delegation generiert wurde, hätte das in der Regel keinen Effekt. Änderungen am Body-Modell und somit auch am generierten Code dürfen wir nicht vornehmen. In 2.5 wurde ein kurzer Einblick in die Load-Time-Weaving Technik von AspectJ gegeben. Damit ist es möglich, das Verhalten von bereits kompiliertem Code zu verändern. Wir können einen Pointcut formulieren, der sämtliche Aufrufe von eget() auf einem EObject abfängt. Es stellen sich jedoch zwei Fragen: 1. Wie stellen wir fest, ob es sich bei dem EObject um ein importiertes Body- Objekt handelt? 2. Wie kommen wir an das Import-Objekt, zu dem wir delegieren müssen? Frage Eins können wir mithilfe der Komponenten-Registry (siehe 4.2.3) beantworten, indem wir getbybody() mit dem EObject als Parameter aufrufen. Bekommen wir dabei eine Komponente zurückgeliefert und handelt es sich bei dem gegebenen Objekt weder um einen Export noch einen Import, wissen wir, dass wir es mit einem Body zu tun haben. Kennen wir die Komponente, können wir über alle Import- Schnittstellen iterieren um einen Import zu finden, der auf das Body-Objekt zeigt. Kann ein solches nicht gefunden werden, findet keine Delegation statt. Der im Objekt gespeicherte Attributwert wird auf normale Weise abgerufen. Es liegt in diesem Fall keine Inkonsistenz vor: In der Regel ist nur eine Teilmenge der Objekte der Body-Instanz oder nur eine Teilmenge der Attribute eines Objekts importiert. Sollten hingegen mehrere Import-Objekte auf dasselbe Body-Objekt zeigen, handelt es sich um eine Inkonsistenz. Es gewinnt dann das Import-Objekt, das bei der Iteration als erstes gefunden wird. Nach Identifikation des Imports läuft die Delegation analog zu der im Setting Delegate implementierten ab Anpassungen am Codegenerierungs-Prozess Der EMF-Generator kann aus jedem korrekten Ecore-Modell Code erzeugen. Unsere Export- und Import-Modelle sind ebenfalls Ecore-Modelle: Die Klassen in EExport und EImport erben von den Klassen des Ecore-Metamodells. Wir können den vorhandenen Generator daher wiederverwenden um aus Export- und Import-Modellen Code zu generieren. Lediglich ein eigener Model Importer soll die Erstellung des Genmodels für ein Schnittstellen-Modell erleichtern. Ein solcher hat die Aufgabe, aus einem Modell ein Generatormodell (Genmodel) zu konstruieren. Wie in 2.3 erwähnt, muss das kein Ecore-Modell sein, sondern kann beispielsweise ein XML-Schema (XSD) oder eine Menge von annotierten Java-Klassen sein. Eigene Model Importer können mit dem Extension-Point org.eclipse.emf.importer.modelimporterdescriptors registriert werden. Im Genmodel-Wizard tauchen alle verfügbaren Model Importer

59 5.1 Import- und Export-Schnittstellen 53 auf (Abb. 5.5). Für unsere Schnittstellen-Modelle ist ein eigener Importer nicht zwingend notwendig. Der Ecore Model Importer erkennt Schnittstellen-Modelle als Ecore-Modelle. Zwar akzeptiert er nur Ressourcen mit Dateiendung ecore, während Export-Schnittstellen die Endung eexport und Import-Schnittstellen die Endung eimport haben. Die Dateinamenserweiterung könnten wir aber ändern. Um die Abbildung 5.5.: Model Importer für Schnittstellen-Modelle Nutzbarkeit zu verbessern, entscheiden wir uns dazu, einen eigenen Model Importer zu implementieren, der die beiden Dateiendungen akzeptiert und weitere Schritte automatisiert durchführt. Dazu können wir den vorhandenen Ecore Model Importer durch Vererbung erweitern. Referenziert ein Modell ein fremdes Modell, bietet der Genmodel-Wizard dem Nutzer die Wahl, entweder das fremde Paket selbst generieren zu lassen oder aber ein existierendes Generatormodell im Workspace auszuwählen. Wurde für das referenzierte Modell bereits Code generiert, ist die zweite Option die beste Wahl, da die erste in dupliziertem Code resultiert. Ein Export-Modell referenziert immer ein Body-Modell, ein Import-Modell immer ein Export- und ein Body-Modell. Unseren Model Importer weisen wir an, automatisch die passenden Genmodel-Ressourcen herauszusuchen und auszuwählen, was dem Nutzer etwas Aufwand spart. Wir gehen dabei davon aus, dass sich das Genmodel im selben Verzeichnis wie das Body- oder Export-Modell befindet und denselben Dateinamen (abgesehen von der Endung) trägt. Desweiteren setzen wir die Feature Delegation, wie in Abschnitt bereits angekündigt, automatisch auf Dynamic.

60 54 5 Implementierung Umsetzung der Anforderungen Im Folgenden wollen wir die Anforderungen und Anwendungsfälle aus und in Bezug zur vorgestellten Implementierung von Import- und Export-Schnittstellen setzen und einen vollständigen Überblick über deren Umsetzung geben. Anforderung 1.2: Containment-Struktur Beschreibung Schnittstellen sollen automatisch eine Containment-Struktur aufweisen, die eine beliebige Struktur für ihre Instanzen erlaubt. Umsetzung Die automatisch erstellte Wurzelklasse (Container) setzt die Anforderung um (vgl. Abb. 5.1 und ihre Beschreibung). Die Adapter-Implementierung ContainerReferencesAdapter sorgt für die Konsistenz der Containment-Referenzen. Anforderung 1.3: Simplere Modellstruktur Beschreibung Schnittstellen-Modelle sollen eine einfachere Struktur als ihre Body-Modelle haben dürfen. Umsetzung Die in aufgezählten Modell-Constraints verhindern Verletzungen der strukturerhaltenden Bedingungen. Die Umsetzung wurde in OCL-Syntax angegeben. In den Klassen EexportValidator und EimportValidator liegt die Java-Implementierung der Constraints vor. Anforderung 1.4: Code-Generierung von Schnittstellen-Modellen Beschreibung Aus Schnittstellen-Modellen soll sich, wie bei Ecore-Modellen, Code generieren lassen. Umsetzung Da EExport und EImport das Ecore Metamodell erweitern, kann der EMF-Generator vollständig wiederverwendet werden (siehe 5.1.3). Anwendungsfall 1.5: Erstellen von Schnittstellen-Modellen auf Basis existierender Komponenten-Teile Beschreibung Der Nutzer soll beim Erstellen eines neuen Schnittstellen-Modells die Möglichkeit bekommen, ein bereits vorhandenes Body-Modell auszuwählen. Wird ein Import-Modell angelegt, soll zusätzlich ein vorhandenes Export-Modell auswählbar sein.

61 5.1 Import- und Export-Schnittstellen 55 Umsetzung Dem Export-Modell-Wizard wurde eine WizardPage-Implementierung BodySelectionPage hinzugefügt. Sie enthält eine Textbox für die URI zum Body- Modell und zwei Buttons, mit denen das Modell aus dem Workspace oder der Package-Registry gewählt werden kann. Für den Import-Modell-Wizard wurde eine BodyAndExportSelectionPage erstellt, die Textbox und Buttons in zweifacher Ausführung vorhält. Im Kontextmenü des Eclipse Package Explorers ist zudem auf Ecore-Modellen die Aktion Create Composite Export Model und Create Composite Import Model verfügbar, die den Wizard aufruft und dort das Body-Modell voreinstellt. Anwendungsfall 1.6: Erstellen von Schnittstellen-Modellen mit Vorauswahl von Modellelementen des Body-Modells Beschreibung Der Nutzer soll beim Erstellen eines neuen Schnittstellen-Modells die Möglichkeit bekommen, Modellelemente des Bodys auszuwählen, die in die neue Schnittstelle initial zu übertragen sind. Umsetzung Wie bei Anwendungsfall 1.5 wurden die Wizards um eine Seite InitialElementsSelectionPage erweitert (vgl. Abb. 5.2). Die Wizards initialisieren das Schnittstellen-Modell in ihrer Methode createinitialmodel() anhand der Nutzerauswahl. Anwendungsfall 1.7: Generatormodell für Schnittstellen-Modell anlegen Beschreibung Aus Schnittstellen-Modellen soll ein Generatormodell erstellt werden können, mit dem sich Code generieren lässt. Umsetzung Die Klasse CompositeModelsImporter setzt diesen Anwendungsfall um (vgl. Abb. 5.5). Anforderung 1.8: Delegation von Datenabfragen Beschreibung Instanzen eines Schnittstellen-Modells sollen keine eigenen Daten besitzen, sondern lediglich die Rolle von Delegationsobjekten annehmen. Umsetzung Es wurde ein Setting Delegate AttributeSettingDelegate implementiert, dass die Delegation von Exports zu ihren Bodys und von Imports zu ihren Exports übernimmt. Die Delegation von importierten Bodys zu ihren Imports wird durch Aspect-Weaving und den Aspekt ImportAspect umgesetzt.

62 56 5 Implementierung Anforderung 1.9: Toleranz bezüglich nicht-erreichbarer Ressourcen Beschreibung Eine temporäre Nicht-Verfügbarkeit einer Komponente soll nicht als Ausnahme, sondern als typischer Fall angesehen werden. Da eine Delegation in diesem Fall nicht möglich ist, soll auf zwischengespeicherte Attribut-Werte zurückgegriffen werden. Umsetzung Das Setting Delegate und der Aspekt speichern den Attributwert bei erfolgreicher Delegation im delegierenden Objekt ab und greifen auf ihn zurück, sollte das Ziel-Objekt nicht verfügbar sein (siehe 5.1.2). Anforderung 1.10: Erweiterte Standard-Constraints Beschreibung EMF-Instanzen müssen neben den nutzerdefinierten domänenspezifischen auch alle Standard-Constraints (siehe 2.3.4) erfüllen. Für Schnittstellen- Instanzen ergeben sich noch weitere Standard-Regeln. Diese sind dem Standard- Regelwerk von EMF hinzuzufügen. Umsetzung Die Klasen ExportedEObjectValidator und ImportedEObject- Validator setzen die Anforderung um. Sie werden auf Typebene von Schnittstellen- Paketen in EMFs Validator-Registry registriert. Anforderung 1.11: Kompatibilität zu dynamischem EMF Beschreibung Aus Schnittstellen-Modellen sollen sich dynamische Instanzen anlegen lassen. Umsetzung Durch die Verwendung von Setting Delegates funktioniert die Delegation auch mit dynamischem EMF. Als Unterklassen von EClass können ExportedClass und ImportedClass von EMFs DynamicModelWizard instanziiert werden. Die beiden Klassen CreateDynamicExportInstanceAction und CreateDynamicImportInstanceAction unterstützen diesen Prozess mit einem Kontextmenü-Eintrag auf Schnittstellen-Modellen.

63 5.2 Baumeditor Baumeditor EMF ermöglicht die Generierung eines baumbasierten Editors, mit dem Instanzen des Modells erstellt und bearbeitet werden können, was wir uns in bereits angeschaut haben. Für Body-Modelle gewöhnliche Ecore-Modelle steht der Ecore Editor zur Verfügung und für Import- und Export-Modelle könnten wir die aus EImport und EExport generierten Editoren verwenden. Body- und Schnittstellen- Instanzen ließen sich mit den generierten Editoren oder dem Reflective Ecore Model Editor (für dynamische Instanzen) bearbeiten. Allerdings hätte dies den Nachteil, dass nicht alle Bestandteile einer Komponente im Editor präsent sind. Ändert man mit einem Editor Objekte einer Instanz, werden andere Objekte, die dieses Objekt referenzieren, über die Änderung informiert, sofern sie im ResourceSet des Editors geladen sind. Änderungen an einer Body-Instanz führen daher möglicherweise zu Inkonsistenzen in ihren Export- und Import-Instanzen, wenn die Body-Instanz isoliert editiert wird. In einer Instanz des Netzwerkmodells Composite, dessen Entwurf in vorgestellt wurde, werden alle Komponenten-Bestandteile referenziert und somit bei Zugriff automatisch in das ResourceSet des Editors geladen. Wir wollen daher dessen generierten Editor benutzen, um damit die einzelnen Import- und Export- Schnittstellen auf Typ- und Instanzebene zu bearbeiten. Die Netzwerkstruktur selbst soll über einen grafischen Diagramm-Editor gestaltet werden, der nicht Teil dieser Arbeit ist, sondern im Rahmen von [SJ12] entwickelt und in [Sch12] vorgestellt wurde. Alternativ kann ein Netzwerkmodell aus einer Menge vorhandener Komponenten-Teile Abbildung 5.6.: Netzwerkgraph Wizard mit Auswahl vorhandener Komponenten- Teile abgeleitet werden. Beim Anlegen einer Composite-Instanz können EMF-Ressourcen, die einen Body, Export oder Import enthalten, aus dem Workspace ausgewählt werden, was in Abb. 5.6 zu sehen ist.

64 58 5 Implementierung Überblick Bodys, Exports und Imports werden von Netzwerkknoten einer Composite-Instanz über rooteobject referenziert. Der verfeinernde Objektgraph liegt in einer eigenen Ressource vor, die bei Bedarf in das ResourceSet des Editors geladen wird. Die neue Ressource erscheint dann im TreeViewer als weiteres Wurzelelement. Da rooteobject keine Containment-Referenz ist, ist das Standard-Verhalten, dass das referenzierte Wurzelobjekt nur in einer Dropdown-Liste der Properties-View und nicht als Kindknoten im Baum auftaucht. Dieses Verhalten können wir ändern, indem wir im Generatormodell die Eigenschaft Children auf true setzen. Abb. 5.7 zeigt die optische Präsentation des Editors. Netzwerkknoten sind mit dem Anfangs- Abbildung 5.7.: Komponenten auf Typ- (links) und Instanzebene (rechts) im Composite Editor buchstaben ( B für Body, E für Export und I für Import) in Form eines Icons gekennzeichnet. Die verfeinernden Objektgraphen finden sich als Kind davon. Auf der linken Seite sind das Body-, Import- und Export-Pakete, auf der rechten Seite Instanzen davon. Modellelemente von Schnittstellen gleichen optisch gewöhnlichen Ecore-Modellelementen, sind aber am Zusatz (exp.) bzw. (imp.) zu erkennen. Auf beiden Ebenen werden zu einem selektierten Objekt korrespondierende farblich hervorgehoben (in der Abbildung: die Klassen CharterFlight und Flight sowie Instanzen davon). Betrachtet man unterschiedliche EMF-generierte Editoren, bzw. die generierte Editorklasse, fällt auf, dass die Unterschiede marginal sind. Das Verhalten der Editoren ist hauptsächlich von den generierten Item-Providern abhängig, die losgelöst vom Editor in eigenen Plug-ins vorliegen. Die Darstellung von Schnittstellen-Modellen werden wir durch Anpassung der Item-Provider von EExport und EImport an das Erscheinungsbild von gewöhnlichen Ecore-Modellen angleichen dazu später mehr.

65 5.2 Baumeditor 59 Die optische Präsentation von Body-, Import und Export-Instanzen übernehmen entweder nutzergenerierte Item-Provider oder der ReflectiveItemProvider. Letzterer kann für dynamische Instanzen und auch für Instanzen von Modellen, zu denen zwar generierter Modell-, jedoch kein Edit-Code vorliegt, genutzt werden. Schnittstellen- Instanzen heben sich also nicht von gewöhnlichen Instanzen ab und sind nur an ihrer body- bzw. exported-referenz zu erkennen. Zwei Command s (siehe 2.3.2) sollen das Bearbeiten von Instanzen erleichtern: Per Drag&Drop können Objekte einer Body-Instanz auf einen Export-Knoten (Netzwerkknoten ExportInterface) gezogen werden. Es wird dann ein Export-Objekt, das auf das Body-Objekt zeigt, in der Export-Instanz erstellt. Export-Objekte wiederum können auf einen Import-Knoten gezogen werden, woraufhin ein Import-Objekt, das auf das Export-Objekt zeigt, in der Import-Instanz erstellt wird. Die Zuordnung zum (importierten) Body-Objekt muss jedoch manuell durch Auswahl in der Properties-View erfolgen, da nicht bekannt ist, wo das Body-Objekt angelegt werden soll: Im Gegensatz zu Schnittstellen-Modellen verfügen Body-Modelle im Allgemeinen nicht über eine Wurzelklasse, die alle möglichen Objekte enthalten kann. Der zweite Command trägt Sorge dafür, dass beim Löschen eines Body-Objekts auch alle Exportund Import-Objekte, die auf das Body-Objekt zeigen, gelöscht werden Item-Provider von EExport und EImport Ecore-Modelle sehen durch ihre Item-Provider in jedem Editor, und somit auch im Composite-Editor, gleich aus. Item-Provider werden zu jeder Modellklasse generiert und weisen die gleiche Vererbungshierarchie wie die Modellklassen auf. Der Item- Provider von ImportedClass etwa spezialisiert den von EClass. Die Symbole und die Berechnung der Text-Label können wir daher wiederverwenden um ein ähnliches Erscheinungsbild für Schnittstellen-Modelle zu erhalten. Die automatisch erzeugte Container-Klasse (5.1.1) verstecken wir, um unbeabsichtigte Änderungen durch den Nutzer zu verhindern. Dazu überschreiben wir die Methode getchildren() in CompositePackageItemProvider und filtern besagte Klasse heraus. Ebenfalls ausgeblendet werden die body- und exported-referenzen, die den Schnittstellen- Klassen beim Setzen der Body-/Export-Klasse hinzugefügt werden: Wieder wird getchildren überschrieben, diesmal im Item-Provider von CompositeClass. Desweiteren wurden die Editieroperationen angepasst. Im Kontextmenü-Eintrag New Child sind im Ursprungszustand der Item-Provider gewöhnliche Modellelemente auswählbar: Bei Schnittstellen-Paketen ist neben ExportedClass und (bei Import- Paketen) ImportedClass auch EClass auswählbar. Export-Pakete sollen aber nur Export-Klassen, Import-Pakete nur Import-Klassen enthalten. Auch könnten bei Schnittstellen-Klassen gewöhnliche Attribute und Referenzen erstellt werden, was nicht erlaubt sein soll. Welche Einträge in der Liste auftauchen sollen, kann über Deskriptoren bestimmt werden. In den Methoden collectnewchilddescriptors() sortieren wir die nicht gewünschten Elemente aus.

66 60 5 Implementierung Item-Provider verwalten zu jedem EStructuralFeature der Modellklasse einen sogenannten PropertyDescriptor. Ein solcher versorgt die Properties-View mit den nötigen Daten zur Anzeige und Manipulation der Eigenschaften des im Baum ausgewählten Objekts. Die generierten Item-Provider von EExport fügen jeweils einen solchen Deskriptor für bodypackage, bodyclass, bodyattribute und bodyreference hinzu. Bei den Item-Providern von EImport kommen die für exportedpackage, exportedclass (siehe Abb. 5.8), exportedattribute und exportedreference dazu. Es handelt sich hier um Dropdown-Listen, deren Auswahlmöglichkeiten in der Methode getchoiceofvalues() der Deskriptoren berechnet werden. Standardmäßig tauchen Abbildung 5.8.: Dropdown-Liste für die exportedclass-referenz in der Properties- View einer Import-Klasse in der Liste alle im gesamten ResourceSet verfügbaren Objekte auf, deren Typ zum Typ der Referenz passt. Beispielsweise wären bei einer Export-Klasse alle möglichen Objekte vom Typ EClass als Body-Klasse auswählbar, also insbesondere auch Exportund Import-Klassen. Wir können sie aus der Auswahlliste entfernen, indem wir den Standard-Deskriptor erweitern und getchoiceofvalues() überschreiben. Je nachdem, welche Zuordnungen bereits erfolgt sind, kann noch präziser gefiltert werden: Wurde im Beispiel das Body-Paket des Export-Pakets schon gesetzt, kann die Liste auf die Klassen des Body-Pakets beschränkt werden. Bei (Schnittstellen-) Attributen und Referenzen ist das Vorgehen analog: Wurde die Body-/Export-Klasse schon gesetzt, werden nur deren Attribute und Referenzen (auch geerbte) angeboten Umsetzung der Anforderungen Nachdem das grundlegende Vorgehen bei der Anpassung des Editors gezeigt wurde, soll nun genauer auf die Umsetzung der einzelnen Anforderungen und Anwendungsfälle aus 3.3 eingegangen werden.

67 5.2 Baumeditor 61 Anforderung 3.1: Benutzerführung für das Bearbeiten von Schnittstellen- Modellen Beschreibung Die Zuordnung der Schnittstellen-Modellelemente zu ihren Body- /Export- Elementen soll durch geeignete Filter erleichtert werden. Umsetzung Die Item-Provider für EExport und EImport wurden um geeignete Deskriptoren erweitert. Siehe Abschnitt und Abb Anforderung 3.2: Optische Hervorhebung korrespondierender Elemente Beschreibung Der Editor soll die Zusammengehörigkeit der Elemente im Baum visualisieren. Umsetzung Die Klasse MappingHighlighter setzt diese Anforderung um. Sie implementiert ISelectionChangedListener und reagiert damit auf das Auswählen eines TreeViewer-Elements im Baum des Editors. Korrespondierende Elemente des selektierten werden farblich hervorgehoben (vgl. Abb. 5.7). Die Funktion lässt sich über das Kontextmenü des Editors abschalten. Anwendungsfall 3.3: Erstellen von Netzwerkgraphen auf Basis vorhandener Komponenten-Teile Beschreibung Der Nutzer soll beim Erstellen eines Netzwerkgraphen die Möglichkeit bekommen, vorhandene Bodys, Imports und Exports auszuwählen, aus denen dann gemäß ihrer Beziehungen Komponenten gebildet werden. Umsetzung Der CompositeModelWizard wurde um eine Seite erweitert, in der der Nutzer EMF-Ressourcen aus dem Workspace auswählen kann (Abb. 5.6). Im neu anzulegenden Netzwerkgraph wird für jeden selektierten Body eine Komponente (Component) und für jeden Export bzw. Import ein ExportInterface bzw. ImportInterface angelegt. Anwendungsfall 3.4: Exportieren und Importieren per Drag&Drop Beschreibung Der Editor soll dem Nutzer eine Drag&Drop Funktion zum Exportieren und Importieren von Objekten anbieten. Umsetzung Die Klassen ExportCommand und ImportCommand leisten diese Funktionalität. Sie werden von DragAndDropImportExportCommand, einer Erweiterung von EMFs DragAndDropCommand, genutzt.

68 62 5 Implementierung 5.3. Komponenten-Registry Abbildung 5.9.: Eclipse-View für die Registry In wurde eine Komponenten-Registry konzipiert. In diesem Abschnitt werden wir eine mögliche Implementierung dafür vorstellen. Im Gegensatz zur Package-Registry von EMF, wo EPackages hauptsächlich durch Extension-Points registriert werden, wollen wir Komponenten Workspace-basiert registrieren, da wir sie schon während der Entwicklung in registrierter Form benötigen. Von der entworfenen Schnittstelle wird dies allerdings nicht zwingend gefordert. Wir werden zunächst Basisfunktionalität für die implementierte Komponenten- Registry vorstellen und darauf aufbauend eine persistente Lösung, die auch Neustarts der Plattform überlebt. Die Basisfunktionalität kann für alternative Implementierungen wiederverwendet werden. Abb. 5.9 zeigt eine simple Eclipse-View, die alle registrierten Komponenten anzeigt. Die Darstellung erinnert an die des Editors. Per Doppelklick kann eine Komponente oder eine Schnittstelle im Editor geöffnet werden. Mit dem roten X-förmigen Button kann eine Komponente aus der Registry entfernt werden. Basisfunktionalität Zunächst werden Komponenten nur in zwei String-Maps (Map<String, Component>) vorgehalten. Die erste speichert die Komponente unter ihrem Namen, die zweite unter der Ressource-URI der Body-Instanz, also des verfeinernden Objektgraphen. Die Methode register() validiert dabei zunächst die übergebene Komponente mittels Diagnostician.INSTANCE.validate(). Die Klasse Diagnostician kann jedes beliebige EObject validieren, dazu nutzt sie EMFs Validator-Registry um die korrekte Validator-Klasse für das übergebene Objekt zu bestimmen. Bei erfolgreicher Validierung wird die Komponente dann den beiden Maps hinzugefügt. Bei der ersten Map unter dem Schlüssel component.getname(), bei der zweiten unter component.getrooteobject().eresource().geturi().tostring(). Die beiden getbybody()-methoden sehen nach, ob unter der übergebenen Ressource-URI bzw. unter der URI des übergebenen EObject ein Eintrag in der zweiten Map vorhanden ist. Falls ja, wird die gemappte Komponente zurückgegeben. Andernfalls wird davon ausgegangen, ein Export oder ein Import (oder dessen URI) wurde übergeben und es wird zum Body navigiert. Ist unter dessen Ressource-URI keine Komponente in der Map vorhanden, ist die Komponente auch nicht registriert.

69 5.3 Komponenten-Registry 63 Persistenz Mit der Basisfunktionalität erfüllt die Implementierung alle Anforderungen an die Registry, doch es gehen alle Registrierungen nach einem Neustart der Eclipse Plattform verloren. Jedes Eclipse-Plug-in kann seinen Zustand in der sogenannten Plug-in State Location speichern, einem Verzeichnis im Workspace des Nutzers. Hier lassen wir die persistente Registry-Implementierung eine Properties-Datei (java.util.properties) anlegen. Properties-Dateien sind Textdateien, in denen beliebige Eigenschaften unter einem Namen abgelegt werden können. Bei der Registrierung speichern wir hier unter dem Komponentenname die URI der Komponente, zusammengesetzt aus der Ressource-URI der Composite-Instanz und dem Fragment, das eine bestimmte Komponente der Instanz ansteuert. Die Properties-Datei wird bei der Erzeugung der Singleton-Instanz der Komponenten-Registry gelesen und alle gespeicherten Komponenten werden mithilfe der Basis-Funktionalität registriert URI Schema Registrierte Komponenten sollen über eine spezielle URI ansprechbar sein. Import- Schnittstellen einer Composite-Instanz beispielsweise können dann Export-Schnittstellen einer fremden Komponente, also einer nicht in der eigenen Instanz definierten, über diese URI referenzieren und müssen nicht deren physischen Standort kennen. Umgesetzt ist dies über einen URIHandler, der das Auflösen von URIs mithilfe von zwei Methoden übernimmt: resolve(uri) löst eine relative in eine absolute URI auf, oder aber eine logische URI in eine physische. deresolve(uri) arbeitet umgekehrt und überführt eine beliebige URI in eine möglichst kurze, also in eine relative oder eine logische Form. Unser URIHandler für Komponenten-URIs bekommt also in resolve() eine URI der Form component:/<componentname>/#<fragment> und muss eine physische zurückliefern. Der Teil vor dem Fragment kann hier einfach durch die Ressource-URI der unter <componentname> registrierten Komponente ersetzt werden. In deresolve() wird überprüft, ob die URI auf eine Komponente oder eine Schnittstelle zeigt und ob die entsprechende Komponente in der Registry vorhanden ist. Falls ja, wird wieder der Teil vor dem Fragment ersetzt, diesmal durch eine aus dem Komponentennamen abgeleitete logische Komponenten-URI Umsetzung der Anforderungen Mit der hier vorgestellten Umsetzung der Komponenten-Registry wurden die Anforderungen und Anwendungsfälle aus 3.2 abgedeckt. Dieser Abschnitt soll wieder angeben, durch welche Maßnahmen sie realisiert wurden.

70 64 5 Implementierung Anforderung 2.1: Registrieren von Komponenten in einer Registry Beschreibung Es soll eine Komponenten-Registry realisiert werden, in die Komponenten aufgenommen und abgefragt werden können. Umsetzung Die Basis-Implementierung der Komponenten-Registry ist in der Klasse BaseComponentRegistry umgesetzt. Die Unterklasse PropertiesComponentRegistry erweitert sie um Persistenz. Anforderung 2.2: Komponenten-Registry-View Beschreibung Für die Komponenten-Registry soll eine Eclipse-View implementiert werden, in der alle registrierten Komponenten sichtbar sind. Umsetzung Die Klasse ComponentRegistryView setzt diese Anforderung um (siehe Abb. 5.9). Über den Extension-Point org.eclipse.ui.views wird sie in Eclipse bekannt gemacht. Anwendungsfall 2.3: Komponente registrieren Beschreibung Dem Nutzer soll es möglich sein, eine Komponente beispielsweise aus dem Editor heraus per Kontextmenü der Registry hinzuzufügen. Umsetzung Die Klasse RegisterComponentAction realisiert diesen Anwendungsfall. Über den Extension-Point org.eclipse.ui.popupmenus wird sie als globale Aktion dem Kontextmenü auf Objekten vom Typ Component hinzugefügt. Damit ist sie beispielsweise im Kontextmenü des Baumeditors verfügbar, sofern auf einer Komponente aufgerufen. Anwendungsfall 2.4: Komponente aus Registry entfernen Beschreibung Die Registrierung einer Komponente soll sich aufheben lassen. Umsetzung Die implementierte Eclipse-View stellt eine Schaltfläche zum Entfernen einer Komponente aus der Registry bereit. Sie liegt als lokale Aktion im Menü der View vor.

71 5.4 Tests Tests In diesem Abschnitt soll kurz darauf eingegangen werden, wie die erstellte Software getestet wurde. Nach Möglichkeit sind im Allgemeinen aufgrund ihrer einfachen Wiederholbarkeit automatisierte Unit-Tests manuellen Tests vorzuziehen. Als Gegenstand von Tests kamen hauptsächlich die implementierten Werkzeuge in Frage. Die grundsätzliche Komponenten-Infrastruktur bietet neben dem Delegationsmechanismus nur wenige Module, bei denen Tests sinnvoll sind. Der Delegationsmechanismus wurde durch automatisierte Unit Tests abgedeckt. Das Verhalten der Werkzeuge hingegen ist mit Nutzerinteraktion an der Oberfläche verbunden, die sich schlecht automatisieren lässt, weshalb hier manuelle Tests durchgeführt wurden. Sie sind durch die Anwendungsfälle aus Kapitel 3 spezifiziert und in Anhang A.2 einzeln aufgelistet. Zum Testen der Delegation wurden mithilfe des JUnit-Frameworks Testfälle geschrieben, die Instanzen einer Menge von Beispielmodellen, also Body-, Exportund Import-Modellen, erstellen. Attribute von Body-Instanzen werden auf Beispielwerte gesetzt und es wird überprüft, ob auch die darauf verweisenden Export- und Import-Instanzen die Abfrage korrekt an das Body-Objekt weiterleiten, also dieselben Attributwerte aufweisen. Auch bei importierten Body-Objekten wird die korrekte Funktionsweise der aspektbasierten Delegation getestet. Fehlertoleranz bezüglich nicht erreichbarer Ressourcen wird durch die Tests ebenfalls mit einbezogen, indem die Body-/Export-Referenzen durch die Testfälle auf nicht-auflösbare Proxys zurückgesetzt werden.

72

73 Kapitel 6. Erweiterungen In dieser Arbeit wurden eine prototypische Implementierung komponentenorientierter Modelle sowie erste Werkzeuge zur Unterstützung des Modellierungsprozesses vorgestellt. Der Fokus lag in der Realisierung der komponentenorientierten Infrastruktur und weniger auf dem Ausbau der Werkzeugunterstützung. Auch wenn bereits einiges in dieser Hinsicht verwirklicht wurde, gestalten sich die einzelnen Arbeitsschritte immer noch sehr mühsam. In diesem Kapitel sollen zum einen Erweiterungen, die parallel zur Entstehung dieser Arbeit entwickelt wurden, vorgestellt werden, zum anderen einige Ideen für zukünftige Erweiterungen aufgegriffen werden. Die ersten beiden Abschnitte befassen sich mit Erweiterungen, die im Rahmen von [Sch12] bereits umgesetzt wurden. Im letzten Abschnitt werden Denkanstöße für weitere Arbeiten diskutiert, die aufbauend auf dieser realisiert werden könnten Diagramm-Editor für die Netzwerkschicht Das in vorgestellte Composite Modell bildet die Netzwerkstruktur explizit ab. Der baumbasierte Editor eignet sich zum Editieren der einzelnen Komponenten- Bestandteile (den Objektgraphen), das Aufbauen des Netzwerkgraphen hingegen ist mit gewöhnlichen EMF-Mitteln wenig komfortabel. Die Ressourcen müssen manuell erstellt und mit der Load Resource... -Funktionalität in das Netzwerk eingebunden werden. Auch eine Visualisierung der Netzwerk-Topologie fehlt. Daher wurde mithilfe des Graphical Modeling Frameworks (GMF [KEVH06]) ein grafischer Diagramm- Editor generiert und um nützliche Funktionen erweitert. GMF-Editoren arbeiten direkt auf der EMF-Instanz und legen zusätzlich eine Diagrammdatei an, in der rein visuelle Informationen etwa Position und Größe der geometrischen Objekte festgehalten werden. Standardmäßig setzt sich die Dateiendung der Diagrammdatei aus der Dateiendung des unterliegenden Ecore-Modells (in unserem Fall composite) und dem Suffix diagram zusammen. Abb. 6.1 zeigt den Diagramm-Editor mit einem beispielhaften Netzwerkgraphen. Die visuelle Repräsentation orientiert sich stark an der in vorgestellten Formalisierung. Komponenten-Teile Bodys, Exports und Imports werden als Knoten dargestellt: Bodys als abgerundete Rechtecke, Exports und Imports als Ellipsen. Sym-

74 68 6 Erweiterungen bole und Beschriftungen entsprechen denen des Baumeditors. Auf der rechten Seite des Editor-Fensters befindet sich die Palette. Mit ihr können Knoten und Kanten angelegt werden. Das Paletten-Tool Export Interface (foreign Component) ermöglicht Abbildung 6.1.: Grafischer Diagramm-Editor es, eine Verknüpfung zu einem Export aus der Komponenten-Registry zu erstellen. In der unterliegenden Composite-Instanz wird dann kein neuer Export angelegt, sondern ein vorhandener externer referenziert. Bei Kanten wird explizit zwischen solchen, die zwischen Import- und Export-Knoten sowie zwischen solchen, die zwischen Bodyund Import/Export-Knoten verlaufen, unterschieden. Das liegt daran, dass es sich im unterliegenden Composite-Modell ebenfalls um zwei unterschiedliche Referenzen handelt. Einmal die export-referenz der Klasse ImportInterface und einmal die Containment-Referenz interfaces der Klasse Component. Auf jedem Knoten befinden sich fünf Buttons. Mit Create Meta-Model lässt sich ein neues Metamodell anlegen, über das der durch den Knoten repräsentierte Objektgraph getypt sein soll. Bei einem Body-Knoten öffnet sich hier der Ecore-Modell-Wizard, bei einem Export-Knoten der EExport- und bei einem Import-Knoten der EImport- Modell-Wizard. Mit Select Meta-Model kann ein existierendes Metamodell aus dem Workspace oder EMFs Package-Registry ausgewählt werden. Die nächsten beiden Buttons verhalten sich ähnlich: Create Model legt den Objektgraphen an, der durch den Knoten repräsentiert werden soll. Es wird also eine Instanz des Metamodells (das mit einem der vorherigen beiden Buttons festgelegt wurde) erstellt. Select Model ermöglicht wieder die Auswahl einer bereits vorhandenen Instanz. Der Button Show In Editor öffnet die unterliegende Composite-Instanz mit dem baumbasierten Editor und selektiert dort den Objektgraphen, sofern dem Knoten bereits einer zugewiesen wurde. Da die fünf Buttons einiges an Platz beanspruchen, lassen sie sich im Sinne einer kompakteren Darstellung ausblenden. Die Option befindet sich im Kontextmenü des Diagramm-Editors. Der verfeinernde Objektgraph kann auch, sofern bereits in

75 6.2 CDO-Integration 69 einer Workspace-Ressource persistiert, per Drag&Drop aus dem Eclipse Package Explorer einem Netzwerkknoten zugewiesen werden. Der Editor unterstützt den Nutzer an vielen Stellen. Wird etwa der Create Meta- Model-Button auf einem Export-Knoten gedrückt und ist dieser im Diagramm bereits mit einem Body-Knoten verbunden, wird im EExport-Wizard das Body-Modell auf das Metamodell des Body-Knotens gesetzt. Dasselbe gilt entsprechend für den Create Model-Button. Es wird empfohlen, die Kanten immer vor dem Erstellen/Auswählen des (Meta-) Modells zu ziehen. Allerdings werden auch beim nachträglichen Verbinden von zwei Knoten deren (Meta-) Modelle verbunden. Sind sie allerdings schon derart verbunden, dass die implizite Struktur nicht zu der expliziten Struktur im Diagramm passt, wird das Anlegen der Kante vom Editor verhindert. Die Benutzung des Diagramm-Editors wird auch in Kapitel 7 thematisiert. Für weitere Informationen und Implementierungsdetails sei auf [Sch12] verwiesen CDO-Integration Die vorgestellte Komponenten-Infrastruktur wurde so konzipiert, dass sie sich tolerant gegenüber nicht verfügbaren Komponenten-Bestandteilen verhält. Der Delegationsmechanismus greift auf zwischengespeicherte Attributwerte zurück, wenn die Ressourcen, aus denen die Werte zu beziehen sind, nicht auffindbar sind. Bisher haben wir nur eine Verteilung auf Dateien im Workspace des Nutzers betrachtet (das gilt auch für das nachfolgende Demonstrations-Kapitel). Eine temporäre Nichtverfügbarkeit einer Ressource ist hier sehr unwahrscheinlich, da eine referenzierte Datei entweder im angegebenen Pfad existiert oder nicht. Eine solche Situation kann nur durch das Umbenennen oder Verschieben einer Datei simuliert werden. Interessant wäre eine Umgebung mit echter, also nicht ausschließlich lokaler, Verteilung. Das mittlerweile zu EMF gehörende CDO-Framework (Connected Data Objects [Ecla]) stellt eine Client-Server-Infrastruktur für EMF Modelle unter Verwaltung eines Repositorys zur Verfügung. Es ermöglicht eine Verteilung über unterschiedliche Server hinweg und eignet sich daher, die Fehlertoleranz unter realistischeren Bedingungen zu testen, da Verbindungen zu einem Server durch Ausfälle unterbrochen werden können und ähnliches. Auch das kollaborative Arbeiten an Modellinstanzen wird ermöglicht, indem lokale Objektgraphen live aktualisiert werden, wenn Änderungen der Instanz auf dem Server durch parallele Zugriffe stattfinden. Die in dieser Arbeit vorgestellte Komponenten-Infrastruktur wurde CDO-tauglich gemacht, indem die Werkzeuge an das verteilte Konzept angepasst wurden. Etwa wurde eine Erweiterung des im vorherigen Abschnitts vorgestellten Diagramm-Editors erstellt, die die Composite-Instanzen sowie die einzelnen Komponenten-Bestandteile nicht in Dateien im Workspace, sondern in Ressourcen in einem CDO-Repository speichert. Auch hier sei für weitere Informationen und Implementierungsdetails auf [Sch12] verwiesen.

76 70 6 Erweiterungen 6.3. Zukünftige Erweiterungen Die Wizards für Export- und Import-Modelle bieten dem Nutzer bereits eine gute Möglichkeit, die initiale Schnittstellenstruktur festzulegen. Für tiefergreifende Modellierungsschritte ist der Baumeditor zu benutzen. Die Übersichtlichkeit stößt hier jedoch schnell an ihre Grenzen. Wünschenswert wäre ein grafischer Editor mit mehreren Sichten. Teile der Modelle könnten wie im Ecoretools Diagramm-Editor als Klassendiagramm aufbereitet, zugehörige Modellelemente etwa durch gleiche Einfärbung gekennzeichnet werden. Hier sind viele Szenarien denkbar. Im Bereich der Codegenerierung wurden schon kleine Anpassungen vorgenommen (siehe 5.1.3). Grundsätzlich ist der EMF-Generator auch für komponentenorientierte Modelle wiederverwendbar. In der Regel wird der zu einem Modell generierte Code in einem Eclipse-Projekt vorgehalten. Zwar sind für Schnittstellen-Modelle keine Edit- und Editor-Projekte nötig, dennoch kommt zumindest für den Modell-Code in jedem Fall ein weiteres Projekt pro Schnittstellen-Modell hinzu. Dadurch erhöht sich der Verwaltungsaufwand. Prinzipiell können auch mehrere Modelle in einem Projekt existieren. Erschwert wird dies lediglich durch die Tatsache, dass Plug-inspezifische Dateien, etwa die MANIFEST.MF und die plugin.xml, sobald sie einmal generiert wurden, nicht durch den Generator aktualisiert werden (im Gegensatz zu den generierten Java-Klassen, die gemerged werden, siehe 2.3). Abhilfe könnte eine Zentralisierung der Codegenerierung schaffen. Anstatt den Generierungsprozess für jedes Modell separat anzustoßen, wäre ein gemeinsames Generatormodell denkbar, das den Code für alle Bestandteile einer Komponente in ein gemeinsames Projekt schreibt und auch die Plug-in-Daten zusammenfasst. Kommen neue Schnittstellen-Modelle hinzu, müssten sie jedoch wieder gelöscht und neu generiert werden. Alternativ könnte auch ein Update-Verfahren für diese Dateien realisiert werden: Während ein Merge-Vorgang für diese Art von Daten schwierig ist, stellen reine Additionen kein Problem dar. Das Editieren von Instanzen wird durch die Drag&Drop-Funktionalität des Baumeditors erleichtert. Body-Objekte können durch Ziehen auf eine Export-Schnittstelle exportiert werden. Zwar können auch Export-Objekte durch Ziehen auf eine Import- Schnittstelle importiert werden, ein Platzhalterobjekt ist aber im Body manuell anzulegen und die Body-Referenz des erstellten Import-Objekts muss manuell auf dieses Platzhalterobjekt gesetzt werden. Wie in erläutert, kann dieses Platzhalterobjekt nicht automatisch erzeugt werden, da die Containment-Struktur des Body-Modells nicht notwendigerweise Objekte beliebigen Typs als Kind des Wurzelobjekts erlaubt. Eine Lösung für dieses Problem könnte so aussehen, dass der Nutzer durch einen Dialog aufgefordert wird, ein Container-Objekt in der Body-Instanz zu bestimmen. Alternativ wäre ein designierter Sammelcontainer vorstellbar, in dem alle Platzhalterobjekte abgelegt werden, von wo aus sie vom Nutzer durch gewöhnliches Drag&Drop an die richtige Stelle zu versetzen sind.

77 Kapitel 7. Demonstration und Tutorial In diesem Kapitel soll anhand von konkreten Anwendungsbeispielen der komponentenorientierte Modellierungsprozess mit den implementierten Werkzeugen veranschaulicht werden. Wir werden die einzelnen Arbeitsschritte wie in einem Tutorial durchgehen. Auf die Erstellung der Body-Modelle werden wir allerdings nicht gesondert eingehen, da dies der Erzeugung gewöhnlicher Ecore-Modelle entspricht und keinen Einsatz der in dieser Arbeit vorgestellten Werkzeuge erfordert. Desweiteren werden zur Vereinfachung Codegenerierungs-Schritte ausgelassen. Um dem Tutorial zu folgen, können sie unter Benutzung von dynamischem EMF ebenfalls übersprungen werden. Andernfalls ist zu jedem in diesem Tutorial auftauchenden Modell ein EMF-Projekt anzulegen und das Modell im model-verzeichnis abzulegen. Anschließend kann das Generatormodell bei Schnittstellen-Modellen unter Benutzung des Model-Importers Composite Interface (siehe 5.1.3) abgeleitet werden. Dabei genügt das Generieren von Modell-Code. Edit- und Editor-Code sind nicht notwendig. Zu beachten ist, dass die Dateinamenserweiterung bei dynamischen Instanzen in der Regel xmi lautet und nicht dem Namen des EPackages entspricht, was sich ggf. in den Abbildungen in diesem Kapitel widerspiegelt. Das erste Beispiel handelt von zwei zunächst unabhängigen Systemen dem einer Fluggesellschaft und dem eines Reisebüros deren Domänenmodelle miteinander verknüpft werden sollen. Im zweiten Beispiel befassen wir uns mit einem - Client, bei dem Adressbucheinträge und Nachrichten exportiert und importiert werden Beispiel: Fluggesellschaft und Reisebüro Hinweis: Dieses Beispiel findet sich in abgewandelter Form unter [SJ12]. In diesem Szenario wollen wir das zu Illustrationszwecken bereits in eingeführte Beispielmodell einer Fluggesellschaft mit dem eines Reisebüros verbinden. Wir definieren dazu zwei Komponenten: Das bereits bekannte Modell airline dient als Body-Modell der ersten Komponente, travelagency wird der Body der zweiten Komponente. Beide Modelle sind in Abb. 7.1 gegenübergestellt.

78 72 7 Demonstration und Tutorial Airline name : EString offeredflights 0..* start Flight 1 flightno : EInt destination ScheduledFlight weeklydeparture : EString weeklyarrival : EString usedairports 1 0..* Airport name : EString location : EString runwaycount : EInt CharterFlight departure : EDate arrival : EDate (a) Fluggesellschafts-Modell airline.ecore knownhotels 0..* Hotel name : EString address : EString TravelAgency name : EString 0..1 offeredtravels hotel 0..* Travel outbound start : EDate 1 return duration : EInt 1 0..* airports Airport description : EString from 1 to 1 BookedFlight flightnumber : EInt departure : EDate arrival : EDate (b) Reisebüro-Modell travelagency.ecore Abbildung 7.1.: Body-Modelle der beiden Komponenten Das Reisebüro bietet Flugreisen an, bei denen optional eine Hotelübernachtung mit inbegriffen ist. Hin- und Rückflug sollen in diesem Beispiel bei der Fluggesellschaft gebucht werden, das heißt die Flüge sowie Start- und Zielflughäfen sollen nicht dem System des Reisebüros, sondern dem der Fluggesellschaft entstammen. Wir wollen nun die beiden Modelle mit den in dieser Arbeit vorgestellten Werkzeugen verbinden. Die Fluggesellschaft unterscheidet zwei Arten von Flügen: Linienflüge (Scheduled- Flight) fliegen regelmäßig, Charterflüge (CharterFlight) einmalig und nur bei Buchung durch einen Reiseveranstalter, was sich in der unterschiedlichen Auffassung von Abflug- und Ankunftszeitpunkt äußert. Für das Reisebüro sind also nur Charterflüge von Interesse. Wir werden zunächst eine Export-Schnittstelle der Fluggesellschaft erstellen. Eine Import-Schnittstelle des Reisebüros soll dann beide Komponenten verbinden. Abb. 7.2 skizziert die Grundidee. Die Klasse CharterFlight der Flugge- airline Airline travelagency TravelAgency Flight Airport Hotel Airport ScheduledFlight CharterFlight Travel BookedFlight CharterFlight Airport BookedFlight Airport flightexport flightimport Abbildung 7.2.: Vereinfachte Darstellung der Body-Modelle mit ihren Schnittstellen

79 7.1 Beispiel: Fluggesellschaft und Reisebüro 73 sellschaft soll zusammen mit Airport exportiert werden. Das Reisebüro-Modell kann sie dann importieren. Gepunktete Pfeile stehen für die bodyclass- bzw. exportedclass- Kanten, gestrichelte Pfeile für die bodyreference bzw. exportedreference-kanten. Attribute und die Namen der Referenzen sind zur besseren Übersichtlichkeit nicht eingezeichnet. Modellierung der Fluggesellschafts-Komponente Eine exemplarische Export-Schnittstelle legen wir an, indem wir in Eclipse den EExport-Wizard aufrufen (File New Other Composite EMF Modeling Composite Export Model). Wir geben ihr hier den Dateiname flightexport.eexport. Auf der nächsten Seite wählen wir mittels Browse Workspace... das Body-Modell airline.ecore aus dem Workspace aus. Alternativ kann mit einem Rechtsklick auf die Ecore-Datei im Package Explorer der Kontextmenü-Eintrag Create Composite Export Model gewählt werden. Das Textfeld ist dann bereits mit der URI zur Body- Ressource gefüllt. Auf der folgenden Seite übernehmen wir in die Export-Schnittstelle (a) Auswahl des Body-Modells (b) Auswahl der Modellelemente Abbildung 7.3.: Erstellung des Export-Modells die Klasse CharterFlight mit allen Attributen, auch der Flugnummer (flightno) aus der abstrakten Oberklasse Flight. Flughäfen tauchen auch im Modell des Reisebüros auf, weshalb wir die Klasse Airport ebenfalls in den Export einfließen lassen, wir begnügen uns aber mit dem Namensattribut. Die beiden Referenzen start und destination, mit denen Start- und Zielflughafen eines Fluges festgehalten

80 74 7 Demonstration und Tutorial werden, können wir dann auch inkludieren. Abb. 7.3 zeigt die im Wizard getroffene Auswahl. Abbildung 7.4.: Anlegen der Composite-Instanz mit Initialisierung der ersten Komponente Das Body- und das Export-Modell fassen wir nun zu einer Komponente zusammen, indem wir eine Composite-Instanz anlegen. Der Wizard ist in der selben Kategorie wie der von EExport zu finden und trägt den Namen Network Graph (Composite) Model. Auf der letzten Seite des Wizards werden Body- und Export-Modell selektiert um daraus eine Komponente zu formen (Abb. 7.4). Das Modell des Reisebüros soll nicht Teil dieser Komponente werden, sondern später als Body-Modell einer zweiten Komponente dienen. Die Modellierung der Fluggesellschafts-Komponente, die in diesem Beispiel nur aus einem Body- und einem Export-Modell besteht, ist somit abgeschlossen. Wir registrieren sie noch in der Komponenten-Registry, um sie später einfacher ansprechen zu können. Modellierung der Reisebüro-Komponente Wir gehen ähnlich wie im vorherigen Abschnitt vor und erstellen zunächst mit dem EImport Wizard ein neues Import-Modell basierend auf dem Body-Modell travelagency.ecore. Zusätzlich geben wir auf der zweiten Seite das bereits existierende Export-Modell (flightexport.eexport) an. In die Schnittstelle nehmen wir aus dem Reisebüro-Modell die Klassen BookedFlight und Airport mit allen Attributen und Referenzen auf. Abb. 7.5 zeigt wieder die getroffene Auswahl. Auf der nächsten Seite können die Modellelemente der Import-Schnittstelle denen der Export- Schnittstelle zugeordnet werden. In unserem Beispiel gestaltet sich dies aufgrund der Ähnlichkeit der beiden Modelle recht einfach: Nur die Namen der Klassen, Referenzen und Attribute unterscheiden sich teilweise. Abb. 7.6 zeigt das vorgenommene Mapping.

81 7.1 Beispiel: Fluggesellschaft und Reisebüro 75 (a) Auswahl des Body- und Export-Modells (b) Auswahl der Modellelemente Abbildung 7.5.: Erstellung des Import-Modells Abbildung 7.6.: Zuordnung der Import-Modellelemente von flightimport zu den Export-Modellelementen aus flightexport

82 76 7 Demonstration und Tutorial Abbildung 7.7.: Die Modelle der beiden Komponenten im Composite Editor Damit ist die Modellierung grundsätzlich abgeschlossen. Es könnten nun weitere Schnittstellen-Modelle angelegt werden, wir belassen es jedoch bei der demonstrierten Export- und der Import-Schnittstelle. Änderungen an den Modellen können über den Composite Editor vorgenommen werden. Dazu ist zunächst wieder eine Komponente zu bilden. Wir können dazu entweder die bereits vorhandene Composite-Instanz nutzen oder aber eine neue Instanz anlegen und auf der letzten Seite des Wizards (vgl. Abb. 7.4) die beiden Modelle (travelagency.ecore und flightimport.eimport) markieren. Bei letzterem Vorgehen erkennt der Wizard, dass das vom Import-Modell referenzierte Export- Modell über die Komponenten-Registry auffindbar ist (da wir die Fluggesellschafts- Komponente registriert haben) und stellt die Verbindung her. In Abb. 7.7 ist die Composite-Instanz mit der Reisebüro-Komponente im Baumeditor zu sehen. Da der Import flightimport auf den Export flightexport zeigt, taucht im Baum ein Wurzelknoten für die Ressource mit der Fluggesellschafts-Komponente auf. Für unser Beispiel sind keine Änderungen an den Modellen nötig. Im nächsten Schritt werden wir Beispielinstanzen anlegen und dort Flüge der Fluggesellschaft exportieren und sie vom Reisebüro importieren lassen. Instanzen Nun können aus den Modellen Instanzen gebildet werden. Wurde aus den Modellen Code generiert, ist zunächst eine neue Eclipse-Instanz zu starten (siehe 2.2). Dies muss mit aktiviertem Aspect-Weaving erfolgen (siehe Anhang A.1). Sollen die Instanzen hingegen in der Hauptinstanz von Eclipse angelegt werden, muss das Weaving bereits für diese aktiviert sein. Die Netzwerkstruktur, die wir bei Definition der Typebene nachträglich erstellt haben, legen wir an dieser Stelle vor Erzeugung der einzelnen Instanzen an. Dieses mal werden wir uns der Funktionalität des in 6.1 vorgestellten grafischen Diagramm-Editors für die Netzwerkschicht bedienen. Wie für GMF-Editoren üblich, kann die Diagramm-Datei zu einer bestehenden EMF-Instanz (in unserem Fall einer *.composite-datei) per Kontextmenü (Initialize Composite Diagram File) oder über den von GMF generierten Wizard angelegt werden, der die unterliegende EMF-Instanz mit erstellt. Da wir für die Instanzebene noch keine Composite-Instanz haben, wählen wir letztere Methode. Den Diagramm-Editor werden wir fortan als zentrales Steuerelement benutzen. Zunächst legen wir mithilfe

83 7.1 Beispiel: Fluggesellschaft und Reisebüro 77 der Palette einen Body Knoten an. Per Doppelklick auf Select Meta-Model wird das Body-Modell der Fluggesellschaft (airline) ausgewählt (Abb. 7.8): Entweder aus der Package-Registry (7.8a) oder dem Eclipse Workspace (7.8b), je nachdem, ob zu den Modellen generierter Code vorliegt oder stattdessen dynamisches EMF eingesetzt wird. Als nächstes erstellen wir einen Export-Knoten und weisen ihm auf dieselbe Weise (a) Auswahl von registriertem Package (b) Auswahl von dynamischem Workspace- Package Abbildung 7.8.: Auswahl des Metamodells das Export-Modell (flightexport.eexport) als Metamodell zu. Der Export wird mittels Interface -> Body Edge aus der Palette mit dem Body-Knoten verbunden. Mit Doppelklick auf Create Model auf dem Body-Knoten legen wir dann zunächst eine Fluggesellschafts-Instanz an. Genauso verfahren wir mit dem Export-Knoten. Abb. 7.9 zeigt den Netzwerkgraphen nach diesen Aktionen. Die Body-Instanz wurde hier lufthansa.airline, die Export-Instanz lh_fluege.flightexport genannt. lufthansa.airline Create Meta-Model Select Meta-Model Create Model Select Model Show in Editor lh_fluege.flightexport Create Meta-Model Select Meta-Model Create Model Select Model Show in Editor Abbildung 7.9.: Netzwerkgraph nach Erstellung einer Body- und einer Export-Instanz Ein Doppelklick auf Show in Editor öffnet den Baumeditor und wählt abhängig davon, auf welchem Knoten die Funktion aufgerufen wurde, die noch leere Body- oder

84 78 7 Demonstration und Tutorial Export-Instanz aus. Nachdem wir in der Body-Instanz ein paar Objekte angelegt haben, beispielsweise ein paar Flughäfen, können sie per Drag&Drop exportiert werden. Die zu exportierenden Objekte werden dabei direkt auf dem Export-Knoten (siehe Abb. 7.10) fallen gelassen. Zu beachten ist, dass Linienflüge (ScheduledFlight) Abbildung 7.10.: Exportieren eines Flughafens per Drag&Drop im Gegensatz zu Charterflügen (CharterFlight) nicht exportiert werden können, da die entsprechende Klasse nicht Teil des Export-Modells ist. Der Name eines exportierten Flughafens stimmt mit dem entsprechenden Flughafen der Body-Instanz überein, da die Attributabfrage delegiert wird. Beim Exportieren von Flügen verfahren wir genauso. Abbildung 7.11.: Baumansicht nach Export von Flughäfen und Flügen Alle exportierten Flughäfen und Flüge können nun in eine Reisebüro-Instanz importiert werden. Wie zuvor auf Typebene steht es uns auch an dieser Stelle frei,

85 7.1 Beispiel: Fluggesellschaft und Reisebüro 79 Import- und Body-Knoten entweder im geöffneten Diagramm-Editor und somit in der gleichen Composite-Instanz anzulegen oder sie wie zuvor getrennt voneinander zu halten und den Weg über die Komponenten-Registry zu gehen. Zur Demonstration werden wir wieder die zweite Variante wählen. Im Baumeditor registrieren wir zunächst die Komponente (lufthansa.airline oder lufthansa.xmi) in der Komponenten-Registry. Wie zu Beginn des Abschnitts legen wir dann eine neue Composite-Instanz samt Diagramm-Datei an, erstellen dieses Mal einen Bodyund einen Import-Knoten, weisen ihnen die entsprechenden Metamodelle aus 7.1 (travelagency.ecore und flightimport.eimport) zu und erstellen jeweils eine Instanz. Die Verbindung zu unserer Fluggesellschafts-Komponente stellen wir über expedia.travelagency lh_ep_fluege.flightimport lh_fluege.flightexport Abbildung 7.12.: Netzwerkgraph der Reisebüro-Komponente auf Instanzebene (Schaltflächen ausgeblendet) das Paletten-Tool Export Interface (foreign Component) her. Im sich öffnenden Dialog expandieren wir die Komponente und wählen den Export (lh_fluege.flightexport oder lh_fluege.xmi). Den Import-Knoten verbinden wir (Import -> Export Edge) mit dem daraufhin erscheinenden Export-Knoten. Wir erhalten eine Netzwerkstruktur wie in Abb. 7.12, wobei der Body-Knoten der Fluggesellschaft nicht sichtbar ist. Wir wechseln nun zum Baumeditor und registrieren auch diese Komponente. Dies ist nötig, damit die Delegation durch Aspect-Weaving funktioniert. In der Body- Instanz legen wir zunächst beispielhaft Reise-Objekte (Travel) an. Die Reisedaten etwa die Dauer einer Reise oder ihr Beginn können wir ausfüllen. Hin- und Rückflug sowie Flughäfen sollen aber aus der Fluggesellschafts-Instanz bezogen werden. Um sie zu importieren, ziehen wir zunächst die Export-Objekte aus der Export-Instanz auf die Import-Schnittstelle. Wieder werden typkonforme Objekte angelegt, die ihre Attributsdaten aus dem Export beziehen. Um sie nun in den Body zu importieren, legen wir in der Body-Instanz auf gewöhnliche Weise Objekte im Baum an und lassen dann die Body-Referenz des entsprechenden Import-Objekts auf das erstellte Body- Objekt zeigen. In Abb wurden bereits zwei Flughäfen und ein Flug importiert. Der Import des zweiten Fluges geschieht durch Auswahl des Body-Objekts in der Dropdown-Box. An der auf Null gesetzten Flugnummer ist er zu erkennen. Der andere in der Liste auftauchende Flug ist bereits mit der Nummer 42 versehen, da er diese schon aus dem Import-Objekt abgefragt hat.

86 80 7 Demonstration und Tutorial Abbildung 7.13.: Import eines Fluges durch Setzen der Body-Referenz 7.2. Beispiel: -Client Im vorangegangenen Beispiel haben wir zwei Modelle miteinander verbunden. Dieses Beispiel soll demonstrieren, dass auch innerhalb eines einzelnen Modells Exportund Import-Modelle zur Anwendung kommen können, um Objekte aus verschiedenen Instanzen desselben Metamodells zu exportieren und importieren. Aus Platzgründen und zur Verdeutlichung der Reihenfolge werden die einzelnen Schritte gegenüber dem vorherigen Abschnitt weniger detailliert erläutert. Das Metamodell Address displayname : EString mailaddress : EString sender 1 subject : EString messagebody : EString 0..* addresses 0..* s addressbooks 0..* AddressBook name : EString MailClient name : EString 0..* folders Folder name : EString 0..* subfolders Abbildung 7.14.: Metamodell des -Clients mailclient.ecore ist in Abb als Diagramm dargestellt. Der -Client organisiert s in Verzeichnissen, die wieder Unterverzeichnisse enthalten können. Das Senden von Nachrichten wird von diesem Beispiel nicht abgedeckt: Instanzen des Mail- Clients sollen nur empfangene Nachrichten repräsentieren. Dementsprechend wird nur der Absender einer festgehalten. Absenderadressen werden in Adressbüchern verwaltet, unbekannte Adressen können also beispielsweise in eigens dafür vorgesehenen Adressbüchern gesammelt werden. Abb zeigt eine exemplarische Instanz.

87 7.2 Beispiel: -Client 81 Abbildung 7.15.: Beispielinstanz Die Item-Provider wurden angepasst, sodass beispielsweise s mit einem Briefsymbol und Verzeichnisse mit dem aus Dateisystemen bekannten Ordnersymbol versehen sind. Export und Import von Adressen Eine übliche Funktionalität von -Software ist das Exportieren und Importieren von Adressen, was wir nun in unserem Beispielmodell abbilden wollen. Wir erstellen ein Export-Modell und exportieren aus dem Body-Modell die Klasse Address sowie ihre beiden Attribute. Das Import-Modell verbinden wir dieses mal nicht mit einem anderen Body-Modell, sondern wieder mit dem des Mail-Clients. In Abb sind die (a) Export-Modell (b) Import-Modell Abbildung 7.16.: Modelle zum Export und Import von Mail-Adressen Wizards während dem Erstellen der beiden Modelle zu sehen. Beim Import-Modell werden die gleichen Body-Elemente selektiert, die auch beim Export-Modell gewählt

88 82 7 Demonstration und Tutorial wurden. Genau diesen Elementen werden sie auch zugeordnet. Es entsteht ein Zyklus (Abb. 7.17): Adressen werden exportiert und gleichzeitig importiert. Dies ist auf Typebene erlaubt. Die Idee dahinter ist, dass zwei unterschiedliche Instanzen auf diese Weise Adressen austauschen können. Die eine Instanz exportiert Adressen, die mailclient.ecore addressexport.eexport addressimport.eimport Abbildung 7.17.: Zyklus im Netzwerkgraph auf Typebene andere importiert sie. Ein Adressobjekt könnte sogar innerhalb derselben Instanz gleichzeitig exportiert und an anderer Stelle importiert werden, obgleich dies wenig sinnvoll wäre. Einzig ein Objekt zu exportieren und in sich selbst zu importieren ist nicht erlaubt, da das zu einer Endlosschleife beim Abfragen der Attributwerte führen würde. Auf Instanzebene 1 legen wir nun wieder eine Composite-Instanz mit Diagramm- Datei an. Wir erstellen zwei Body-, einen Export- und einen Import-Knoten, wobei der Export auf den ersten Body, der Import auf den zweiten Body und auf den Export zeigt. Das Metamodell setzen wir bei beiden Body-Knoten auf das Mail-Client Modell, bei Export und Import entsprechend auf die erstellten Schnittstellen-Modelle. Danach legen wir zunächst zu beiden Bodys eine Instanz an, etwa wie die aus Abb Die Netzwerkstruktur sollte dann der in Abb ähneln. Nachdem die thunderbird.mailclient thunderbird_addresses.addressexport pegasus.mailclient tb_peg_addresses.addressimport Abbildung 7.18.: Netzwerkgraph auf Instanzebene Komponenten mithilfe des Baumeditors registriert wurden, können nun Adressen der ersten Body-Instanz (in den Abbildungen: thunderbird.mailclient) exportiert und in der zweiten Body-Instanz (in den Abbildungen: pegasus.mailclient) importiert werden. Abb zeigt den Baumeditor nach dem Exportieren von drei Adressen 1 Die Eclipse Runtime Workbench ist wieder mit aktiviertem Aspect-Weaving zu starten.

89 7.2 Beispiel: -Client 83 Abbildung 7.19.: Export und Import von Adressen aus der Thunderbird-Instanz und dem Importieren von zwei dieser Adressen in der Pegasus-Instanz. Neben den beiden importierten enthält diese noch eine eigene Adresse, die nicht importiert ist. Export und Import von s Nachdem wir uns mit dem Exportieren und Importieren von Adressen beschäftigt haben, kommen wir nun zu einem ähnlichen Szenario: dem Exportieren und Importieren von Nachrichten. Der Fokus soll hier auf dem strukturerhaltenden Exportieren und Importieren liegen. Wir werden daher neben -Nachrichten auch die Verzeichnisse, in denen sie abgelegt sind, berücksichtigen. Wir erstellen wie im vorherigen Szenario ein Export- und anschließend ein Import-Modell. In den Wizards wählen wir die Klassen und Folder und alle Features mit Ausnahme der sender-referenz. Dadurch können wir die Klasse Address weglassen, für die wir bereits über eigene Schnittstellen-Modelle verfügen. Die Erstellung von Instanzen nehmen wir wieder mithilfe des Diagramm-Editors vor. Wir können das Diagramm aus dem vorherigen Szenario wiederverwenden, in dem wir Adressen exportiert und importiert haben (Abb. 7.18). Die Netzwerkstruktur sieht dann wie in Abb aus. Beim Exportieren von s steht es uns frei, auch die Ordner, in denen eine Mail vorliegt, mitzunehmen oder die Mail einfach flach in den Wurzelcontainer zu setzen. Eine Mail aus dem Ordner Inbox können wir einfach per Drag&Drop in die Export-Schnittstelle ziehen. Exportieren wir dann auch den Ordner selbst, kann das Export-Objekt der Mail in das Export-Objekt des Ordners geschoben werden. Die Ordnerstruktur, bzw. aus Sicht von EMF die Containment-

90 84 7 Demonstration und Tutorial thunderbird_mail.mailexport thunderbird.mailclient thunderbird_addresses.addressexport tb_peg_mails.mailimport pegasus.mailclient tb_peg_addresses.addressimport Abbildung 7.20.: Netzwerkgraph auf Instanzebene aus Abb nach Erweiterung Struktur, muss dabei aber erhalten bleiben: Es ist nicht erlaubt, eine aus dem Papierkorb ( Trash ) in den Posteingang ( Inbox ) zu exportieren. In Abb wurde dies unzulässigerweise getan. Validiert man den Export des Inbox-Ordners, meldet Eclipse die Verletzung in einem modalen Dialog. Das Problem kann behoben werden, indem die entsprechende Mail entweder in den Wurzelcontainer verschoben wird, oder durch Export des Trash Ordners und anschließendes Verschieben der Mail in diesen. Beim Importieren der Mails gehen wir analog zum vorherigen Szenario Abbildung 7.21.: Verletzung der Containment-Struktur der Body-Instanz vor. Hier ist wieder darauf zu achten, dass die Komponenten registriert sind und Eclipse mit Aspect-Weaving gestartet wurde. Die beiden Szenarion Export/Import von Adressen sowie Export/Import von E- Mails könnten kombiniert werden um in einer Body-Instanz Adressen und s aus verschiedenen Quellen zu importieren. Wir wollen es an dieser Stelle jedoch nicht weiter vertiefen und schließen die Demonstration damit ab.

91 Kapitel 8. Verwandte Arbeiten In diesem Kapitel sollen einige mit dem Thema dieser Masterarbeit verwandten Arbeiten vorgestellt werden. Zunächst ist ein Vergleich zwischen dem hier vorgestellten Verteilungsansatz und der gewöhnlichen Art und Weise, EMF-Modelle miteinander zu verbinden, zu ziehen. Anschließend sind einige Veröffentlichungen zu nennen, in denen unter anderem die konzeptionellen Grundlagen dieser Arbeit formuliert wurden. Schließlich sind Arbeiten vorzustellen, die ähnliche Ziele wie diese Arbeit verfolgen. EMF bietet von Haus aus die Möglichkeit, Modelle und Instanzen mithilfe von URI-Referenzen über mehrere Ressourcen zu verteilen (siehe 2.3.5). Da aber jedes Modellelement referenziert werden kann, lässt sich das Geheimnisprinzip ( information hiding ) nicht umsetzen. Jedes Element wird implizit exportiert und kann direkt in einem anderen Modell importiert werden. Ein derart importiertes Element entspricht genau dem Originalelement: Die Ressource, die es enthält wird unmittelbar mit der referenzierenden verbunden. Die Verteilung ist also rein physischer und nicht logischer Natur. Im hier vorgestellten Ansatz stimmen Original-, Export- und Import-Objekt nicht überein, sondern besitzen eine eigene Identität, wobei Exports und Imports auf Instanzebene die Rolle von Delegationsobjekten einnehmen. Die Komponenten-Bestandteile bilden in ihrer Gesamtheit also kein einziges, großes Modell, sondern sind logisch getrennt, aber komponiert. Die einzelnen Objektgraphen sind in sich abgeschlossen, das heißt domänenspezifische Referenzierungen finden nur innerhalb eines Objektgraphen statt, während Verbindungen zu anderen Graphen durch die Komponenten-Architektur verwaltet werden. Darüber hinaus lassen sich Sichtbarkeiten bereits auf Typebene einschränken, indem bestimmte Modellelemente nicht oder in anderer Form in die Schnittstelle übernommen werden. Das theoretische Fundament für diese Masterarbeit, die Formalisierung komponentenorientierter Modelle mit expliziten Schnittstellen, wurde in einer Reihe von Konferenzpapieren dargelegt. [JT09] stellt einen grundlegenden Entwurf für komponentenorientierte Modelle vor, der Fokus liegt hier vornehmlich auf der Netzwerkschicht. [JT10] beschreibt eine vollständige Formalisierung komponentenorientierter Modelle, die in [JT11] an einigen Stellen optimiert wurde. Die drei Arbeiten orientieren sich an der graphentheoretischen Formalisierung von EMF-Modellen aus [BET08].

92 86 8 Verwandte Arbeiten Die Dissertation von Stefan Jurack [Jur12] gibt einen umfassenden Überblick über den aktuellen Stand der Forschung im Bereich der komponentenorientierten Modellierung. Im Rahmen von [Sch12] wurden Erweiterungen der vorliegenden Implementierung entwickelt: Ein grafischer Diagramm-Editor für die Netzwerkschicht und die Anpassung der Infrastruktur an eine Client-Server-Umgebung mit echter Verteilung. Die Ergebnisse wurden in Kapitel 6 dieser Arbeit zusammengefasst. [Str11] demonstriert die Entwicklung einer Modelltransformationssprache für komponentenorientierte Modelle. Die dort vorgestellte Implementierung baut auf einer frühen Version der in dieser Masterarbeit vorgestellten Komponenten-Infrastruktur auf und wurde parallel zur Erstellung dieser Arbeit fortlaufend erweitert. [KM10] beschreibt eine Technik zur modularen Komposition von Modellen. Auch hier werden Modellinstanzen über explizite Schnittstellen verbunden, allerdings müssen sie alle demselben Metamodell unterliegen. Die Schnittstellen unterstützen das Geheimnisprinzip durch das Weglassen von Modellelementen, allerdings keine strukturerhaltenden Vereinfachungen etwa bezüglich Vererbungshierarchien wie im hier vorgestellten Ansatz. Im weiteren Sinne mit dieser Arbeit verwandt sind zwei Eclipse-Projekte, die unter anderem das kollaborative Arbeiten an EMF-Modellen ermöglichen. Das CDO- Framework (Connected Data Objects [Ecla]) bietet eine serverbasierte Lösung zum Persistieren von Modellinstanzen in einem Repository und ist auf das verteilte Bearbeiten von sehr umfangreichen Objektgraphen ausgelegt. Das Eclipse-Inkubations- Projekt Papyrus [Eclb] stellt eine Umgebung zur Erstellung von UML und SysML Modellen im Kontext von EMF zur Verfügung. Es verfügt unter anderem über die Möglichkeit, nur Teile eines Modells zu öffnen und die Änderungen dem Gesamtmodell hinzuzufügen, was ein konfliktfreies Arbeiten erleichtert. Existierende Werkzeuge zur Definition von komponentenorientierten Modellen mit expliziten Import- und Export-Schnittstellen lagen zum Zeitpunkt der Erstellung dieser Arbeit nach Wissen des Verfassers nicht vor.

93 Kapitel 9. Zusammenfassung und Ausblick Zusammenfassung In dieser Masterarbeit wurde ein Entwicklungsprozess im Sinne der modellgetriebenen Softwareentwicklung dargelegt. Nach einer Betrachtung der theoretischen und technischen Grundlagen war zunächst eine Anforderungsanalyse durchzuführen. Darauf aufbauend konnte ein Entwurf komponentenorientierter Modelle mit expliziten Schnittstellen erstellt werden. Ein Kernaspekt war die Erweiterung des Ecore Metamodells zur Definition von Export- und Import-Schnittstellen auf Typebene, wobei eine wichtige Anforderung lautete, dass existierende Ecore-Modelle als Body-Modelle einsetzbar sein sollten. Zusätzlich wurde ein Metamodell zur expliziten Spezifikation der Netzwerkstruktur konstruiert. Neben dieser grundlegenden Infrastruktur wurden zum einen ein baumbasierter Editor generiert und angepasst, zum anderen eine Komponenten-Registry entworfen. Bei der Implementierung ermöglichte die Flexibilität von EMF die Wiederverwendung sowohl der Mechanismen zur Codegenerierung als auch existierender Werkzeuge. Abgerundet wurde der Hauptteil der Arbeit durch die Vorstellung von einigen nicht in dieser Masterarbeit verwirklichten Erweiterungen, die im Rahmen von anderen Projekten realisiert wurden oder möglicherweise Gegenstand zukünftiger Arbeiten sein könnten. Ferner wurde der komponentenorientierte Modellierungsprozess in Form eines ausführlichen Tutorials demonstriert.

94 88 9 Zusammenfassung und Ausblick Zielvergleich und Ausblick Ziel dieser Arbeit war nicht das Schaffen einer umfassenden Werkzeugumgebung für einen komponentenorientierten Modellierungsprozess, sondern vielmehr einer prototypischen Umsetzung der Formalisierung komponentenorientierter Modelle mit expliziten Schnittstellen. Sie ist also als Proof of Concept anzusehen. Dementsprechend wurden auch die Anforderungen formuliert, die sich allesamt umsetzen ließen. Um die Infrastruktur produktiv nutzbar zu machen und einen echten Vorteil gegenüber herkömmlicher also nicht-komponentenorientierter Modellierung zu erzielen, sind noch Erweiterungen erforderlich, von denen einige schon angesprochen wurden. Freilich sind auch gänzlich andere Implementierungen, EMF-basiert oder nicht, mit alternativen Designentscheidungen vorstellbar. Als problematisch erwies sich die Anforderung, gewöhnliche Ecore-Modelle als Body-Modelle nutzen zu können, ohne sie ändern zu müssen. Während dies bei der Modellierung auf Typebene für keine Komplikationen sorgte, erschwerte es den Delegationsmechanismus. Die aspektorientierte Lösung zu diesem Problem ist zweckmäßig, aber hinsichtlich Effizienz nicht optimal, da bei jedem Attributszugriff überprüft werden muss, ob eine Delegation nötig ist. Alternative Lösungen wären wünschenswert. Es ist zu überlegen, ob diese Anforderung aufgeweicht werden könnte. Eine Migration existierender Ecore-Modelle wäre verglichen mit der gewonnenen Performanz ein hinzunehmender Schritt, der sich weitgehend automatisieren ließe.

95 A. Anhang A.1. Installation & Benutzung Installation Für die Installation der im Rahmen dieser Arbeit implementierten Komponenten- Infrastruktur und den zugehörigen Werkzeugen wird eine Eclipse-Installation, idealerweise eine Modeling Distribution, benötigt. Die Software liegt in Form von Eclipse Plug-ins vor und kann mithilfe des Installations-Managers installiert werden. Die URL zur Eclipse Update-Site lautete zum Zeitpunkt der Erstellung dieser Arbeit Abbildung A.1.: Installation von CompoEMF über die Eclipse Update-Site

96 90 A Anhang Dort ist das Feature de.uni marburg.fb12.swt.compomodels auszuwählen. Fast alle benötigten Abhängigkeiten befinden sich in der zentralen Update-Site aktueller Eclipse Distributionen. Einzige Ausnahme sind die AspectJ Development Tools (AJDT), von denen wenige Teile benötigt werden. Die Installation des AJDT ist nicht notwendig, die Update-Site muss jedoch der Liste der verfügbaren Sites hinzugefügt werden. Die Update-Site für Version 3.7 lautet Bei der Installation von CompoEMF sollte dann ein Haken bei der Option Contact all update sites during install to find required software gesetzt sein (siehe Abb. A.1). Alle benötigten Abhängigkeiten inklusive der AspectJ-Libraries werden dann automatisch installiert. Bei einer Modeling Distribution sind die meisten Plug-ins bereits vorhanden. Aktuellere Installationshinweise, insbesondere Update-Site URLs, finden sich auf der Projekt Website zu CompoEMF [SJ12]. Aktivierung von Aspect-Weaving Damit die Delegation von importierten Body-Objekten funktioniert, muss Eclipse oder die Runtime Workbench, in der die Instanzen bearbeitet werden mit aktiviertem Aspect-Weaving gestartet werden. Dazu ist ein VM-Argument hinzuzufügen. Dies kann im Falle einer Runtime Workbench in der Launch Configuration, mit der diese gestartet wird, erfolgen oder in der Datei eclipse.ini hinter der Zeile -vmargs eingetragen werden, falls das Aspect-Weaving in der Hauptinstanz von Eclipse aktiviert sein soll. Das VM-Argument unterscheidet sich abhängig von der Version des installierten AspectJ-Plug-ins und muss daher angepasst werden. Es hat die Form -javaagent:pfad/zur/aspectjweaver.jar beginnt also mit dem Schalter -javaagent gefolgt von einem Doppelpunkt und dem Pfad zur Datei aspectjweaver.jar, die sich in der Regel in einem Unterordner des plugins-verzeichnisses der Eclipse-Installation befindet. Abb. A.2 zeigt ein Beispiel für eine solche Launch Configuration.

97 A.1 Installation & Benutzung 91 Abbildung A.2.: Launch Configuration mit VM-Argument zur Aktivierung des Aspect-Weavings