Während seiner Laufzeit beobachtet dieser Host, welche PlugIns (Exten-der) ihre Erweiterungen für diesen Erweiterungspunkt angemeldet haben und integriert ihre Einträge in die Oberäche der Anwendung. So kann ein Host-PlugIn erweitert werden, ohne dass es verändert werden muss. Im OBSE-Tool werden auf diese Weise zum Beispiel Transformationen in die gemeinsame Oberäche integriert.
Einen besonderen Stellenwert in der Infrastruktur des OBSE-Prozesses nimmt die Sprache CPL ein. So wie sie dort die Rolle eines Drehkreuzes ausübt, das verschiedene Artefakte miteinander verknüpft, übernimmt das CPL-Meta-Modell (cpl.ecore) und das zugehörige obsetool.cpl.metamodell-PlugIn die entsprechende Rolle in dem OBSE-Tool. Dieses obsetool.cpl.metamodell-PlugIn steht im Mittelpunkt der PlugIn-Architektur des Tools, die mittels des UML-Komponentendiagramms in der Abbildung 6.3 dargestellt ist. Das metamo-del-PlugIn stellt als Extender über die Erweiterung org.eclipse.emf.ecore.ge-nerated_package16 einen Zugri auf das Meta-Modell anderen PlugIns zur Verfügung. Wie der Name dieser Erweiterung andeutet, handelt es sich da-bei um eine automatisch generierte Implementierung, die alle Zugrie auf die Elemente eines Ecore-Modells übernimmt. Die Erstellung der nötigen Java-Klassen und Schnittstellen übernimmt das EMF -Framework. Auf die-se Weidie-se wird zum Beispiel die Klasdie-se ThingType des CPL-Meta-Modells auf das gleichnamige Interface und seine Implementierung abgebildet. Das wird für jedes Element des Meta-Modells durchgeführt. Zusätzlich erstellt EMF eine zentrale Klasse CPLFactoryImpl, mit der einzelne Meta-Modell-Elemente erstellt werden können.
Alle PlugIns, die auf dem CPL-Meta-Modell aufbauen, benutzen das obsetool.cpl.metamodel-PlugIn. Dadurch wird sichergestellt, dass unabhän-gig davon, ob ein CPL-Modell in einem graphischen, tabellarischen Editor oder während einer Transformation entstanden ist, es von diesen gemein-sam benutzt werden kann. So baut jede Komponente des OBSE-Tools17 mindestens eine use-Beziehung zum PlugIn das CPL-Meta-Modells auf.
Die CPL-Editoren (linke obere Ecke der Abbildung) teilen ein gemein-sames PlugIn obsetool.cpl.edit, das die grundlegende Funktionalität zum Editieren von CPL-Modellen anbietet. Spezische Repräsentation tabel-larisch oder graphisch wird mit Hilfe der PlugIns obsetool.cpl.editor und obsetool.cpl.diagram realisiert. Diese PlugIns integrieren sich in die gemein-same Oberäche (realisiert durch das PlugIn obsetool.application)
entspre-16Erweiterungen und Erweiterungspunkte werden in diesem Diagramm der Übersicht-lichkeit wegen nicht dargestellt.
17vgl. auch die Abbildung 6.2
Abbildung 6.3: PlugIn-Architektur des OBSE-Tools
chend dem vorherigen ActionSets-Beispiel.
Bei den PlugIns für die Imoprt- und Export-Brücke liefert das ob-setool.bridge.actions-PlugIn die Menü-Einträge für die Oberäche des OB-SE-Tools. Die PlugIns obsetool.bridge.import und obsetool.bridge.export stel-len Wizards entsprechend den Aktivitätsdiagrammen in dem Kapitel 4.3.2 zur Verfügung. Die Ausführung von Integrationsaufgaben für CPL-Modelle ist in das PlugIn obsetool.bridge.integration ausgelagert, das auf dem CPL-Meta-Modell aufbaut. Da die Import-Brücke Integrationsschritte beinhal-tet, greift sie auf das obsetool.bridge.integration-PlugIn zu. Ansonsten, um die Ontologie-Fragmente oder andere CPL-Modelle zu integrieren, sieht das obsetool.bridge.actions eine direkte Nutzung des obsetool.brdge.integration-PlugIns vor.
Die Datenbankanbindung erfolgt weitgehend automatisch mit Hilfe des Teneo-Frameworks. Als eine Objekt-Relationale-Brücke ermöglicht Teneo, Klassen aus dem obsetool.cpl.metamodel-PlugIn auf entsprechende relatio-nale Datenbanktabellen abzubilden. Da verschiedene relatiorelatio-nale Datenban-ken zum Teil unterschiedlichen Funktionsumfang mitbringen, baut das ob-setool.db.teneo-PlugIn auf Treibern für die zu verwendende Datenbank auf.
Für diesen Erweiterungspunkt können verschiedene Treiber registriert wer-den, so dass jede relationale Datenbank, die einen jdbc-Treiber mitbringt18, zum Ablegen von CPL-Modellen verwendet werden kann. Getestet wurde das OBSE-Tool mit der kompakten HSQLDB-Datenbank, wofür bereits ein entsprechendes PlugIn in der Architektur existiert.
Eine zu dem obsetool.cpl.metamodel-PlugIn vergleichbare Rolle in der Architektur übernimmt das org.eclipse.uml2-Plugin, das das UML-Meta-Modell zur Verfügung stellt. Es wird von dem baumartigen (org.eclipse.uml2.-uml.editor) und einem Editor für die UML-Klassendiagramme (org.eclipse.-uml2.diagram.clazz) verwendet. Dieses PlugIn und die darauf aufbauenden Editoren-PlugIns sind in der Abbildung 6.3 farblich abgesetzt, um zu ver-deutlichen, dass es sich nicht um eigene Implementierung handelt, sondern dass sie von der Eclipse-Plattform in das OBSE-Tool integriert wurden.
Auch die Namensgebung betont diesen Unterschied. Auf Grund ihres Ur-sprungs bringen sie eine andere Menü-Stuktur mit, als sie in dem OBSE-Tool gewünscht ist. Das PlugIn obsetool.uml.actions wird deswegen zwi-schen den UML-Editoren und der OBSE-Applikation zwizwi-schengeschaltet und übernimmt die Konvertierung.
18Das trit zur Zeit auf alle gebräuchlichen, relationalen Datenbanken zu.
Die Transformatoren sind aus jeweils zwei PlugIns für jede Trans-formationsrichtung zusammengesetzt. Analog zu den anderen Komponen-ten liefern entsprechnde actions-PlugIns Erweiterungen wie Menü-Einträge für die Integration in die Oberäche des OBSE-Tools. Die PlugIns obse-tool.atl.uml2cpl und obsetool.atlcpl2uml stellen die eigentliche Funktionali-tät der Transformationen bereit. Sie beinhalten zwei Artefakte, die neben dem Java-Code eine entscheidende Rolle für die Umsetzung einer Transfor-mation spielen. In den Dateien cpl2uml.atl und uml2cpl.atl benden sich Transformationsregeln in der für Menschen lesbaren Form. Die Dateien cpl2uml.asm und uml2cpl.asm sind ihre maschineninterpretierbaren Gegen-stücke, die während einer Transformation von der Virtuellen Maschine des ATL-Frameworks ausgeführt werden19.
Das obsetool.application-PlugIn ist im Unterschied zu allen anderen PlugIns in der Abbildung 6.3 als eine eigenständige RCP-Anwendung de-klariert und ist ausführbar. Auÿerdem werden hier Aufgaben-übergreifende Elemente des OBSE-Tools implementiert. Zum Beispiel bietet obsetool.appli-cation eine Möglichkeit, OBSE-Projekte oder Projekte zum Verwalten der Domänen-Ontologie zu erstellen und zu bearbeiten. Die wichtigste Funktion dieses PlugIns liegt aber darin, als Host Anknüpfpunkte für die Dienste der darunterliegenden PlugIns anzubieten und sie einem Benutzer unter einer gemeinsamen Oberäche zur Verfügung zu stellen.
Was das Diagramm in der Abbildung 6.3 nicht zeigt, ist die Menge an PlugIns, die von der Eclipse-Plattform zusätzlich aktiviert werden, um die Ausführung der vorgestellten PlugIn-Struktur zu ermöglichen. Abhän-gig von der Konguration des OBSE-Tools handelt es sich dabei um bis zu 190 zusätzliche PlugIns. Eine derart komplexe Anwendung im Rahmen dieser Arbeit herzustellen, war nur unter Verwendung von ausgereiften und weitgehend auf der Modell-getriebenen Vorgehensweise aufbauenden Eclip-se-Werkzeugen möglich. Ein Einblick in die Implementierung des OBSE-Tools und Verwendung dieser Werkzeuge wird in dem kommenden Kapitel anhand von ausgewählten Beispielen gegeben.