Konzeption und prototypische Realisierung einer Abfrage- und Transformationssprache für DeepML

Transkript

1 Konzeption und prototypische Realisierung einer Abfrage- und Transformationssprache für DeepML Diplomarbeit im Fach Informatik vorgelegt von Elena Klevtsova geb. in angefertigt am Department Informatik Lehrstuhl für Informatik 2 Programmiersysteme Friedrich-Alexander-Universität Erlangen-Nürnberg (Prof. Dr. M. Philippsen) Betreuer: Dipl.-Inf. Samir Al-Hilank, Dipl.-Inf. Ralf Ellner Beginn der Arbeit: Abgabe der Arbeit:

2

3 Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als solche gekennzeichnet. Der Universität Erlangen-Nürnberg, vertreten durch die Informatik 2 (Programmiersysteme), wird für Zwecke der Forschung und Lehre ein einfaches, kostenloses, zeitlich und örtlich unbeschränktes Nutzungsrecht an den Arbeitsergebnissen der Diplomarbeit einschließlich etwaiger Schutzrechte und Urheberrechte eingeräumt. Erlangen, den Elena Klevtsova

4

5 Diplomarbeit Thema Konzeption und prototypische Realisierung einer Abfrage- und Transformationssprache für DeepML Hintergrund Das Forschungsprojekt IWK-MMA-SWEP beschäftigt sich seit 2008 mit der Modellierung und Ausführung von Softwareentwicklungsprozessen, sowie der Modellierung und Vereinheitlichung von Standards und Reifegradmodellen für die Softwareentwicklung. In beiden Domänen stößt das bekannte Konzept der objektorientierten Instanziierung, mit nur zwei logischen Ebenen (Klassen- und Instanzebene), an seine Grenzen. Die Softwareentwicklungsprozess- und Reifegradmodellierung verlangt nach mehreren logischen Ebenen, z.b. Sprach-, Modell- und Instanzebene, wie sie mit dem Konzept der tiefen Instanziierung modelliert werden können. Im Rahmen des Projekts wurde daher die abstrakte Syntax einer Modellierungssprache ( DeepML ) entworfen, die diese tiefe Instanziierung unterstützt. Ergänzend wurde die konkrete Syntax von DeepML definiert und in einem graphischen, diagrammbasierten Editor umgesetzt. Die Modellierungswerkzeuge für DeepML sind auf der Basis der Eclipse-Plattform (EMF, Graphiti) realisiert. Aufgabenstellung Durch die Realisierung des graphischen Editors ist es möglich, DeepML-Modelle komfortabel zu erstellen. Für die Ver- und Weiterbearbeitung von DeepML-Modellen werden zusätzlich Mechanismen benötigt, um diese zu restringieren, zu analysieren und in andere Modellformate zu transformieren. Für diese Zwecke werden im Modellierungsumfeld speziell angepasste Sprachen verwendet. Im Kontext der weit verbreiteten Modellierungs-Standards MOF (Meta Object Facility) und UML (Unified Modeling Language) sind dies z.b. die OCL (Object Constraint Language) zur Beschreibung von Zusicherungen und die QVT (Query View Transformation) zur Beschreibung von Anfragen, Sichten und Transformationen. OCL, QVT und ähnliche Sprachen basieren jedoch häufig selbst auf der MOF, die das Konzept der tiefen Instanziierung nicht umsetzt. Daher bietet sie keine Unterstützung für die Analyse und Bearbeitung von Modellen, die sich über mehrere logische Instanziierungsebenen erstrecken. Ziel dieser Arbeit ist es, im ersten Schritt eine Sprache zu konzipieren, die auf die speziellen Bedürfnisse von tiefen Metamodellen, wie der DeepML, Rücksicht nimmt. Diese Sprache soll es ermöglichen, auf DeepML-Modellelemente zuzugreifen und DeepML- Modelle über Transformationen in andere DeepML-Modelle zu überführen. Anschließend soll die Sprache prototypisch in einem Werkzeug umgesetzt und in die vorhandene Werkzeuglandschaft für DeepML integriert werden.

6 Meilensteine Einarbeiten in die abstrakte und konkrete Syntax von DeepML Einarbeitung in den State of the Art bei Anfrage- und Transformationssprachen (OCL, QVT etc.) Konzeption der Sprache Prototypische Realisierung der Sprache Integration der Sprache in die DeepML-Werkzeuglandschaft Schreiben der Ausarbeitung Literatur Eclipse Foundation: Eclipse Project, Oktober Atkinson, C., Gutheil, M., Kennel, B.: A Flexible Infrastructure for Multilevel Language. IEEE Trans. Softw. Eng. 35 (2009) Atkinson, C., Kennel, B., Goß, B.: The Level-Agnostic Modeling Language Engineering. Volume 6563 of LNCS. (2011) Betreuung Dipl.-Inf. Ralf Ellner Dipl.-Inf. Samir Al-Hilank Bearbeiter Elena Klevtsova

7 Abstract The well-known concept of the object-oriented instantiation with two logical levels reaches its limits in domains which require several logical levels. Deep instantiation, on the other hand, offers more expressiveness and contains the shallow instantiation as a special case. In order to support this deep instantiation, the abstract syntax of a modeling language DeepML has been designed within the framework of the research project IWK-MMA-SWEP. Additionally, a concrete syntax has been designed and implemented in a graphical editor. The next step shall be to implement a query and transformation language for DeepML used to process DeepML models, to perform model-to-model transformation or to be able to formulate and analyse constraints. This new language has to take into account and support the deep instantiation. First, this thesis briefly presents the concept of the deep instantiation and its implementation in DeepML. Then, two possible approaches to the implementation of the query and transformation language are discussed. The first one is the extension of the OCL- and QVT-standard languages with the concept of the deep instantiation; the second one is the usage of the epsilon framework, which supports a general framework for the access to and the processing of the models over a single language family. Of these two approaches we choose the epsilon framework and justify this decision. In order to use the existing epsilon languages for the DeepML models a special driver (DeepML Connectivity Layer) is implemented. We examine the general principle of the implementation of such a driver and discuss the solutions which are especially needed because of the deep instantiation. Following, we evaluate the implementation. Here we pay attention to both the feasibility and the scalability of the solution. In addition to that, the epsilon framework has been reviewed. Finally, we give an outlook for possible future research on this subject and summarize the results of this thesis. i

8 Abstract ii

9 Zusammenfassung Das bekannte Konzept der objektorientierten Instanziierung mit nur zwei logischen Ebenen stößt an seine Grenzen bei Domänen, die nach mehreren logischen Ebenen verlangen. Die tiefe Instanziierung bietet dagegen mehr Ausdruckskraft und beinhaltet dabei die flache Instanziierung als Sonderfall. Um diese tiefe Instanziierung zu unterstützen, wurde im Rahmen des Forschungsprojekts IWK-MMA-SWEP die abstrakte Syntax einer Modellierungssprache DeepML entworfen. Ergänzend wurde die konkrete Syntax definiert und in einem graphischen Editor umgesetzt. Als nächster Schritt soll nun eine Abfrage- und Transformationssprache für DeepML realisiert werden, um z.b. die DeepML-Modelle zu verarbeiten, Modell-zu-Modell-Transformationen durchzuführen oder Zusicherungen formulieren und auswerten zu können. Dabei soll diese Sprache die tiefe Instanziierung berücksichtigen und unterstützen. Als Erstes wird in dieser Arbeit kurz vorgestellt, was tiefe Instanziierung ist und wie sie in DeepML realisiert wurde. Danach werden zwei möglich Ansätze für die Realisierung der Abfrage- und Transformationssprache diskutiert, nämlich die Erweiterung von OCL- und QVT-Standardsprachen um das Konzept der tiefen Instanziierung oder der Benutzung des Epsilon Frameworks, welches ein allgemeines Rahmenwerk für den Zugriff auf und die Verarbeitung von Modellen über eine Sprachfamilie unterstützt. Das Epsilon Framework wird für die Implementierung ausgewählt und seine Auswahl begründet. Um die existierenden Epsilon-Sprachen für DeepML-Modelle verwenden zu können, wird ein spezieller Treiber (DeepML Connectivity Layer) realisiert. Dabei wird auf das allgemeine Prinzip der Implementierung solch eines Treibers eingegangen und die Problemlösungen, die speziell wegen der tiefen Instanziierung notwendig sind, diskutiert. Anschließend wird die Evaluierung der Implementierung vorgenommen. Dabei wird sowohl auf die Machbarkeit als auch auf die Skalierbarkeit der Lösung geachtet. Außerdem wird das Epsilon Framework bewertet. Schließlich werden mögliche zukünftige Arbeiten vorgestellt und die Ergebnisse der Arbeit zusammengefasst. iii

10 Zusammenfassung iv

11 Inhaltsverzeichnis 1 Einleitung Problemstellung Zielsetzung Aufbau der Arbeit Einführung in DeepML Motivation Tiefe Instanziierung (Deep Instantiation) Ontologische vs linguistische Instanziierung Exkurs: Ein kurzer Walkthrough durch DeepML DeepML Clabject und Instanziierung DeepML Attribute DeepML Referenzen Generalisierung Slot-Konzept Realisierung von DeepML Ansätze für die Definition von Abfrage- und Transformationssprachen Motivation OCL und QVT Epsilon Framework OCL und QVT vs Epsilon Framework Konzeption und Realisierung des DeepML Connectivity Layer Epsilon Connectivity Layer und die Schnittstelle IModel Verwalten von Modellen Erzeugung und Entfernung von Modellelementen Erhalten von Instanzen v

12 Inhaltsverzeichnis 4.5 Anfragen an Modelle nach Modellelementen Abfrage und Modifizierung der Attribute von Modellelementen Integration von tiefen Attributen Dialogfenster für die Eingabe von Modelleigenschaften Evaluierung der Implementierung Motivation Das eingesetzte Modell Textuelle Erstellung von DeepML-Modellen Modell-zu-Modell-Transformation Modell-zu-Text-Transformation Validierung von DeepML-Modellen mittels Zusicherungen Organisation und Ausführung von Modell-Tasks Bewertung des Epsilon Frameworks Zukünftige Arbeiten Fazit vi

13 Bildverzeichnis Abbildung 1: Tiefe Instanziierung... 4 Abbildung 2: Duale Klassifizierung... 5 Abbildung 3: Realisierung des Clabjects... 6 Abbildung 4: Realisierung der Instanziierung... 7 Abbildung 5: Realisierung der Attribute... 7 Abbildung 6: Realisierung der Referenzen... 8 Abbildung 7: Realisierung der Generalisierung... 9 Abbildung 8: Realisierung des Slot-Konzepts Abbildung 9: Paketdiagramm: Implementierung des DeepML Connectivity Layer Abbildung 10: DeepML Connectivity Layer als Treiber Abbildung 11: Architektur der EMC (Epsilon Model Connectivity Layer) Abbildung 12: Erzeugung eines Modellelements Abbildung 13: Beispiel für eine komplexe Generalisierungs- und Klassifikationshierarchie Abbildung 14: Abfrage von Attributen des Modellelements Abbildung 15: Integration von tiefen Attributen Abbildung 16: Beispiel für die Konfigurierung des EVL-Programms Abbildung 17: Konfigurationsdialog für das DeepML-Modell Abbildung 18: Architektur des PIHS-MM im Hinblick auf Layer und Domain Stacks Abbildung 19: Verlauf der textuellen Erstellung von DeepML-Modellen Abbildung 20: Eingabemodell: Mapping (Kernel) Abbildung 21: Verlauf der Modell-zu-Modell-Transformation Abbildung 22: Verlauf der Modell-zu-Text-Transformation Abbildung 23: Verlauf der Validierung Abbildung 24: Abstrakte Syntax für die Modellierung von Methoden Abbildung 25: Erweiterung des DeepML-Modells für die Realisierung der Methoden vii

14 Bildverzeichnis viii

15 Tabellenverzeichnis Tabelle 1: Vergleich von OCL und QVT mit Epsilon Framework Tabelle 2: Einstellungen für die Ausführung des EOL-Programms Tabelle 3: Einstellungen für die Ausführung der Modell-zu-Modell-Transformation Tabelle 4: Ergebnis der Modell-zu-Text-Transformation für linguistische Typen Tabelle 5: Ergebnis der Modell-zu-Text-Transformation für ontologische Typen Tabelle 6: Einstellungen für die Ausführung der Modell-zu-Text-Transformation Tabelle 7: Einstellungen für die Ausführung der Validierung ix

16 Tabellenverzeichnis x

17 Codefragmente Codefragment 1: Definition des Pre-Blocks des ETL-Programms Codefragment 2: Transformationsregel für die Klasse-zu-Clabject-Transformation Codefragment 3: Transformationsregel für die Generalisierung Codefragment 4: Generierung einer HTML-Tabelle im EGL-Programm Codefragment 5: Der generierte HTML-Code Codefragment 6: Definition der Zusicherungen Codefragment 7: Struktur des Workflow-Projekts Codefragment 8: Laden des Modells Codefragment 9: Definition von Konstanten für Parameternamen Codefragment 10: Epsilon.eol-Task zur Ausführung des EOL-Programms Codefragment 11: Entladen des Modells Codefragment 12: Benutzung zusätzlicher Attribute des epsilon.evl-tasks Codefragment 13: Benutzung zusätzlicher Attribute des epsilon.egl-tasks xi

18 Codefragmente xii

19 1 Einleitung 1.1 Problemstellung In immer mehr verschiedenen Domänen stößt man bei der Modellierung an Grenzen der objektorientierten Instanziierung, die nur zwei logische Ebenen besitzt. Auch die Softwareentwicklungsprozess- und Reifegradmodellierung, womit sich das Forschungsprojekt IWK-MMA-SWEP beschäftigt, verlangen nach mehr als zwei logischen Ebenen. Ein vielversprechendes, aber in der Praxis wenig erforschtes Konzept für die Modellierung über mehrere logische Ebenen ist das Konzept der tiefen Instanziierung. Im Rahmen des Forschungsprojekts wurde daher die Sprache DeepML entwickelt, die diese tiefe Instanziierung unterstützt. Ergänzend zur abstrakten Syntax wurde im Rahmen einer Studienarbeit [1] die konkrete Syntax definiert und in einem graphischen Editor umgesetzt. Als nächstes werden Sprachen benötigt, um DeepML-Modelle zu verarbeiten, z.b. um Modell-zu- Modell- und Modell-zu-Text-Transformationen durchzuführen, Zusicherungen zu formulieren und auszuwerten. Für diese Zwecke momentan bestehende Sprachen, wie sie z.b. für die UML in Form von OCL und QVT definiert sind, unterstützen nicht die tiefe Instanziierung. Daher sollten entweder die existierenden Sprachen entsprechend angepasst werden oder neue, geeignete Sprachen definiert werden. 1.2 Zielsetzung Diese Arbeit verfolgt folgende Ziele: Auswahl eines geeigneten Ansatzes für die Definition der Abfrage- und Transformationssprache für DeepML Konzeption der Sprache Prototypische Realisierung der Sprache Bewertung des Ergebnisses und Ausblick 1.3 Aufbau der Arbeit In Kapitel 2 wird zunächst erklärt, worum es sich bei der tiefen Instanziierung handelt und auf Unterschiede zwischen ontologischer und linguistischer Instanziierung eingegangen. Schließlich wird kurz vorgestellt, wie die tiefe Instanziierung in DeepML realisiert wurde. 1

20 1 Einleitung Kapitel 3 stellt zuerst zwei mögliche Ansätze für die Realisierung der Abfrage- und Transformationssprache vor. Darauf basierend wird die Auswahl für das Epsilon Framework getroffen und begründet. In Kapitel 4 wird die Implementierung des DeepML Connectivity Layer dargestellt, die für die Realisierung der Abfrage- und Transformationssprache notwendig ist. Dabei werden sowohl die allgemeine Funktionsweise des Epsilon Frameworks als auch die speziell bei DeepML-Modellen auftretenden Probleme diskutiert. Kapitel 5 beschreibt die Evaluierung der Implementierung. Dabei wird zuerst das dafür eingesetztes Modell vorgestellt, danach wird auf jeden Punkt der Evaluierung detailliert mit Codebeispielen eingegangen. Anschließend wird das Epsilon Framework bewertet. Kapitel 6 gibt einen Ausblick auf mögliche zukünftige Arbeiten. Kapitel 7 fasst schließlich die Ergebnisse der Arbeit im Fazit zusammen. 2

21 2 Einführung in DeepML 2 Einführung in DeepML 2.1 Motivation In diesem Kapitel wird zunächst anhand eines Beispiels erklärt, was tiefe Instanziierung ist und auf Unterschiede zwischen ontologischer und linguistischer Instanziierung eingegangen. Danach wird kurz vorgestellt, wie die tiefe Instanziierung in DeepML realisiert wurde. 2.2 Tiefe Instanziierung (Deep Instantiation) Bei herkömmlicher ( flacher ) Instanziierung sind immer nur zwei Ebenen beteiligt. Der Typ in der oberen Ebene bestimmt (charakterisiert) seine Instanzen auf der darunterliegenden Ebene. Wenn man aber mithilfe mehrerer Ebenen modelliert, ergibt sich oft die Notwendigkeit, die Elemente einer unteren Ebene über die Elemente einer mittleren Ebene (bzw. mehrerer mittlerer Ebenen) von den oberen Ebenen aus zu spezifizieren. Dies ist nicht ohne weiteres möglich. Verschiedene existierende Ansätze, dies mit Hilfsmethoden zu erreichen, haben mehrere Nachteile und Beschränkungen (Z.B. Power Types [2], Prototyipcal Concept Pattern und Nested Metalevels with Context Sensitive Queries [3]). Die tiefe Instanziierung, die von Atkinson und Kühne vorgeschlagen wurde [3] (Weiterentwicklung in [2], [4]), ermöglicht diese tiefe Charakterisierung auf ganz intuitive Weise. Sie ist eine logische Erweiterung der traditionellen Instanziierung und beinhaltet somit diese als einfachsten Fall. Damit die tiefe Instanziierung zum Tragen kommt, müssen mehr als zwei logische Ebenen vorhanden sein. Dabei haben die Elemente auf den mittleren Ebenen einen dualen Charakter. Einerseits sind sie Instanzen von Elementen der oberen Ebene, andererseits bestimmen sie die Elemente der unteren Ebenen und sind damit die Typen. Deswegen werden sie auch Clabjects genannt [3], was ein zusammengesetztes Kunstwort aus den englischen Begriffen Class und Object darstellt. Um die tiefe Instanziierung zu realisieren, wird ein zusätzlicher Mechanismus benötigt. Alle Elemente des Modells (Clabjects, Attribute, Referenzen) erhalten eine zusätzliche Eigenschaft, die sogenannte Potenz. Dies ist eine ganzzahlige nicht negative Zahl, die anzeigt, wie oft das Element instanziiert werden kann. Z.B. hat das Clabject Profession in dem Beispiel in Abbildung 1 die Potenz gleich zwei. Bei der konkreten Syntax, die für DeepML entworfen wurde, steht die Potenz des Clabjects nach dem Namen in Klammern 3

22 2 Einführung in DeepML (die Zahl vor dem At-Zeichen, danach folgt die Ebenennummer). Die Potenz gleich zwei bedeutet, dass das Clabject Profession genau zweimal instanziiert werden kann. Bei der Instanziierung wird die Potenz um eins reduziert, somit hat das Clabject ITProfessional, das eine Instanz des Clabjects Profession darstellt, die Potenz eins. Hat ein Clabject die Potenz eins, so kann es genau einmal instanziiert werden. Somit entspricht dies der gewöhnlichen flachen Instanziierung. Bei der nächsten Instanziierung wird die Potenz wieder um eins reduziert und wenn ein Clabject die Potenz null hat, so kann es nicht mehr instanziiert werden. Im Beispiel ist das der Fall für das Clabject BillGates. Nicht nur die Elemente der untersten Ebene können Clabjects mit der Potenz gleich null haben. Profession salary: float (2) salaried: boolean (1) «instance of» L0 ITProfessional salary: float (1) salaried = true L1 «instance of» BillGates (0@L2) salary = L2 Abbildung 1: Tiefe Instanziierung Aber nicht nur das Clabject selbst, sondern auch seine Attribute haben eine Potenz. Diese hat die gleiche Bedeutung wie beim Clabject: sie zeigt, wie oft das Attribut instanziiert werden kann. Die Potenz des Attributs steht in Klammern nach der Typangabe. So hat das Clabject Profession zwei Attribute: salary, das Potenz zwei hat und somit zweimal instanziiert werden kann und Salaried, das die Potenz gleich eins hat. Bei der Instanziierung werden alle Potenzen um eins reduziert, somit hat das Attribut salaried im Clabject ITProfessional die Potenz gleich null. Dies bedeutet nicht nur, dass es nicht mehr instanziiert werden kann, sondern auch, dass das Attribut einen Wert erhalten muss. So bekommt das Attribut salaried den Wert true zugewiesen. Das Attribut salaried kann nicht mehr instanziiert werden, deswegen erscheint es auch nicht mehr in dem Clabject BillGates in der Ebene L2. Das Attribut salary dagegen hat im Clabject ITProfessional die Potenz gleich eins, die bei der Instanziierung um eins redu- 4

23 2 Einführung in DeepML ziert wird. Im Clabject BillGates hat das Attribut salary somit die Potenz null und muss einen Wert erhalten. Auf diese Weise ist es möglich, über mehrere Ebene hinweg zu spezifizieren, dass ein Clabject in der bestimmten Ebene ein Attribut haben muss (hier von L0 über L1 für L0). An dieser Stelle ist noch zu erwähnen, dass die Potenz des Attributes kleiner oder gleich der Potenz des Clabjects sein kann, aber nicht größer [2]. 2.3 Ontologische vs linguistische Instanziierung Die Instanziierung, die, wie im oben vorgestellten Beispiel, zwischen den Elementen des Domänenmodells stattfindet, wird in [4] als ontologische Instanziierung bezeichnet. Im Gegensatz dazu nennt man die Instanziierung, die zwischen dem Element des Domänenmodells und dem Element der Sprache entsteht, die linguistische Instanziierung. Abbildung 2 veranschaulicht diese duale Klassifizierung. LO Profession «linguistic instance of» «ontological instance of» L1 ITProfessional «linguistic instance of» Clabject «ontological instance of» L2 BillGates «linguistic instance of» Language Definition Abbildung 2: Duale Klassifizierung Das Modellelement BillGates ist eine ontologische Instanz vom Modellelement IT- Professional und gleichzeitig eine linguistische Instanz vom Sprachelement Clabject. Genauso ist das Modellelement ITProfessional eine ontologische Instanz vom Modellelement Profession und gleichzeitig eine linguistische Instanz vom Sprachelement Clabject. Somit verlaufen die Pfeile der ontologischen Instanziierung vertikal und die der linguistischen Instanziierung horizontal. Solche Architektur wird auch orthogonale Klassifizierungsarchitektur (engl. orthogonal classification architecture) genannt [4]. Wichtig ist, dass alle Modellelemente die Instanzen des einzigen Sprachelements Clabject sind. Es wird also nicht zwischen Typen und ihren Instanzen unterschieden, wie es 5

24 2 Einführung in DeepML z.b. bei UML der Fall ist. Stattdessen verbindet das Element Clabject die beiden Konzepte. Dies bringt auch den Vorteil, dass die Anzahl der logischen Ebenen nicht durch die Anzahl der unterschiedlichen Sprachelemente (z.b. Object, Class und Metaclass) beschränkt ist. 2.4 Exkurs: Ein kurzer Walkthrough durch DeepML DeepML ist eine im Rahmen des Forschungsprojekts IWK-MMA-SWEP entworfene Modellierungssprache, die die tiefe Instanziierung unterstützt. Die abstrakte Syntax der Sprache DeepML wurde in Form eines UML-Modells spezifiziert. Dieses Modell wird in den folgenden Kapiteln in vereinfachter Form herangezogen, um die wichtigsten Eigenschaften der Sprache DeepML zu beschreiben. Die Realisierung von DeepML erfolgte dabei unter Verwendung des EMF [5], was ausführlicher im Rahmen einer Studienarbeit beschrieben ist [1], die sich mit der Definition einer konkreten Syntax für DeepML auseinandersetzt. Ziel dieses Abschnitts ist es daher, die grundlegenden Konzepte darzustellen, die für das Verständnis der Ausführungen notwendig sind DeepML Clabject und Instanziierung Abbildung 3 zeigt die Realisierung des Clabjects in DeepML. Das Clabject wird als eine Klasse modelliert, die unter anderem über ein Attribut für die Speicherung der Potenz verfügt. Die Ebene wird dagegen berechnet. Das Clabject kann beliebig viele Features haben. Diese sind Attribute, Methoden und Referenzen. Jedes Feature kann nur zu einem Clabject gehören. Features, wie auch Clabjects, haben ein Attribut für die Potenz. Die Ebene des Features dagegen ist immer gleich der Ebene des Clabjects, zu dem das Feature gehört. Attribute und Referenzen können abgeleitet sein, was mit dem Attribut isderived ihrer Oberklasse DMLStructuralFeature ausgedrückt werden kann. DMLClabject +/level : Integer +potency : Integer dmlclabject 0..1 * +dmlclabject +/ownedfeatures {readonly, union, unique, subsets ownedelements} +potency : Integer DMLFeature * +/ownedstructuralfeatures {readonly, union, unique, subsets ownedfeatures, subsets structuralfeatures } DMLStructuralFeature +isderived:boolean DMLAttribute DMLReference DMLMethod Abbildung 3: Realisierung des Clabjects 6

25 2 Einführung in DeepML In Abbildung 4 ist die Realisierung der Instanziierung zu sehen. Um auszudrücken, dass ein Clabject eine Instanz des anderen Clabjects ist, wird eine DMLClabjectInstantiation erzeugt und zu dem Clabject, das die Instanz darstellt, hinzugefügt (ownedclabjectinstantiations). Ein Clabject kann mehrere solche Instanziierungen haben, somit wird die Mehrfachklassifikation unterstützt. Die Instanziierung wiederum zeigt auf das Clabject, das einen Classifier darstellt (clabjectclassifier). Man kann auch vom Classifier aus zu seinen Instanzen kommen (invclabjectclassifier). DMLClabjectInstantiation * +invclabjectclassifier {unique} clabjectclassifier DMLClabject * +ownedclabjectinstantiations {unique} clabjectinstance Abbildung 4: Realisierung der Instanziierung DeepML Attribute Abbildung 5 betrachtet die Attribute des Clabjects näher. Wie oben gezeigt, kann ein Clabject beliebig viele Features haben. In diesem Fall sind es Attribute. Jedes Attribut hat einen Datentyp. Das kann entweder eine Enumeration oder eine primitiver Datentyp sein (z.b. Integer, String, usw). Für die Speicherung von Werten von Attributen wird ein Slot- Konzept gebraucht, das in Kapitel vorgestellt wird. DMLClabject dmlclabject * +ownedattributes {subsets owedstructuralfeatures, unique} DMLAttribute * +atribute {unique} datatype {subsets type} DMLDataType DMLEnumeration DMLPrimitive DataType Abbildung 5: Realisierung der Attribute 7

26 2 Einführung in DeepML DeepML Referenzen Abbildung 6 zeigt die Realisierung der Referenzen. Eine Referenz zeigt auf das Clabject, das den Typ der Referenz darstellt. Mithilfe von Referenzen können Beziehungen zwischen Clabjects modelliert werden. Wie jedes andere Feature hat eine Referenz eine Potenz (potency). Unter- und Obergrenze (lowerbound und upperbound) dienen zur Einschränkung der erlaubten Kardinalität der Menge der Referenzen. Für die Realisierung der Eigenschaft derived union bei Assoziationen (Definition der Instanzmengen als Vereinigung der Untermengen) werden isunion, subsettedreferences und subsettingreferences gebraucht. Wie für Attribute steht das Slot-Konzept (Kapitel 2.4.5) auch für Referenzen zur Verfügung. DMLClabject DMLFeature +/level : Integer +potency : Integer +potency : Integer +lowerbound : Integer +upperbound : Integer +clabject clabject {susets type} 0..1 DMLStructuralFeature +isderived:boolean +reference {unique} * * +isunion : Boolean +ownedreferences {unique, subsets ownedstructuralfeatures} DMLReference * * +subsettedreferences {unique} +subsettingreferences {unique} Abbildung 6: Realisierung der Referenzen Generalisierung Für die Realisierung der Generalisierung (Abbildung 7) wird die Klasse DMLGeneralization gebraucht. Sie speichert den Verweis auf das generalisierte (generaclabject) und spezialisierte Clabject (specializedclabject). Die Generalisierungen werden von der abgeleiteten Klasse verwaltet (ownedgeneralizations). Ein Clabject kann mehrere dieser Generalisierungen haben, somit wird die Mehrfachvererbung unterstützt. Um von dem generalisierten Clabject aus auf seine spezialisierten Clabjects zu gelangen, werden diese in invgeneralclabject gespeichert. 8

27 2 Einführung in DeepML DMLGeneralization * 0..1 DMLClabject +invgeneralclabject {unique} +generalclabject * +ownedgeneralizations {subsets ownedelements, unique} specializedclabject {subsets fromelements} Abbildung 7: Realisierung der Generalisierung Slot-Konzept Wenn die Potenz von Features null ist, so müssen die Werte (für DMLAttribute) oder Referenzen auf den Clabjects (für DMLReference) im Modell abgespeichert werden. Diese sind zudem abhängig von den im Feature spezifizierten Unter- und Obergrenzen für die Kardinalität. Um dies zu ermöglichen, wurde in DeepML ein Slot-Konzept realisiert, das in Abbildung 8 dargestellt ist. Mithilfe von DMLSlotContent können Werte oder Referenzen auf andere Clabjects gespeichert werden. DeepML unterstützt dabei die folgenden Arten von Slot-Contents: DMLClabject: für die Speicherung der Referenzen auf Clabjects DMLPrimitiveTypeSlotContent: für die Speicherung von Werten der primitiven Datentypen DMLEnumeratonsLiterale: für die Speicherung von Werten der Enumeration Ein Element des Modells, das Slots besitzen kann, wird durch die Klasse DMLElement- WithSolts repräsentiert. Ein DMLClabject ist eine Unterklasse von ihr, und kann somit beliebig viele Slots (DMLSlot) haben. Dabei wird jeder dieser Slots mit maximal einem konkreten DMLFeature verbunden. Der dazugehörige Wert wird in eine Klasse gespeichert, die von der abstrakten Klasse DMLSlotContent erbt. Der Slot kann beliebig viele dieser Slot-Contents für die Abspeicherung von Werten und Referenzen besitzen, um die Kardinalität größer als eins zu unterstützen. 9

28 2 Einführung in DeepML /slotfeature {readonly, union} DMLFeature +potency : Integer +lowerbound : Integer +upperbound : Integer * +slot {unique} DMLSlot * +slot {unique} * +/slotcontent {readonly, union, unique} DMLSlotContent * +/ownedslots {readonly, union, unique, subsets ownedelements} elementwithslots DMLElement WithSlots DMLClabject DMLPrimitive TypeSlotContent + value: String DMLEnumeration Literal + value: Integer Realisierung von DeepML Abbildung 8: Realisierung des Slot-Konzepts DeepML ist als ein EMF-Modell realisiert. Für das Management von DeepML-Modellen wird von EMF der Java-Code generiert. Außer gewöhnlichen Gettern und Settern wurden noch viele weitere Methoden für Elemente des Modells definiert und implementiert, die die Logik der DeepML-Sprache realisieren oder einfach die Arbeit mit dem Modell komfortabler machen. Eine kleine Auswahl an solche Methoden für das DMLClabject ist unten zu sehen: DMLAttribute addattribute(string name, int potency, DMLDataType datatype) erzeugt ein neues Attribut mit den angegebenen Namen, Potenzen und Datentypen und fügt es zu der Liste der Attribute des Clabjects hinzu EList<DMLAttribute> getattrinhbyclasshierarchy() liefert alle Attribute des Clabjects, die es nach der Klassifizierungshierarchie hat EList<DMLAttribute> getattrinhbygenhierarchy() liefert alle Attribute des Clabjects, die es nach der Generalisierungshierarchie hat EList<DMLClabject> getallontclassifiers() liefert alle Classifier des Clabjects entsprechend der Klassifizierungshierarchie über alle Ebenen hinweg EList<DMLClabject> getontinstances() liefert alle Instanzen eines Clabjects 10

29 2 Einführung in DeepML Object getvalue(dmlstructuralfeature structfeature) liefert den Wert des eingegebenen Features, das zum diesem Clabject gehört boolean isonttypeof(dmlclabject clabject) liefert true, wenn das Clabject ein ontologischer Typ des angegebenen Clabjects ist Mit jeder DeepML-Modellinstanz kann dann auf linguistischer Ebene gearbeitet werden, z.b. können an jedem Clabject des erstellten Modells die oben vorgestellten Methoden aufgerufen werden. 11

30 3 Ansätze für die Definition von Abfrage- und Transformationssprachen 3 Ansätze für die Definition von Abfrageund Transformationssprachen 3.1 Motivation Für MOF-basierte Sprachen (z.b. EMF) stehen Standards zur Verfügung z.b. OCL und QVT. Allerdings unterstützt MOF nicht die in DeepML realisierte tiefe Instanziierung. Für die Unterstützung der mehrstufigen Klassifikationshierarchien müssten diese Sprachen erweitert werden. Eine andere Möglichkeit wäre, eine Sprache auf der Basis von Epsilon Framework zu realisieren, welches ein allgemeines Rahmenwerk für den Zugriff auf und die Verarbeitung von Modellen über eine Sprachfamilie unterstützt. In diesem Kapitel werden diese beiden Varianten für die Realisierung einer Abfrage- und Transformationssprache für DeepML einander gegenübergestellt: Anpassung von OCL und QVT Verwendung des Epsilon Frameworks 3.2 OCL und QVT Die Object Constraint Language (OCL) [5] ist eine formale Sprache für die Definition von Zusicherungen (Constraints) und Anfragen an UML-Modelle. Sie ist seit der UML-Version 1.1 Bestandteil der UML. OCL ist eine rein deklarative Sprache, d.h. ihre Ausdrücke haben bei der Auswertung keine Nebeneffekte auf das zugehörige Modell. Query View Transformation (QVT) [6] ist auch eine Spezifikation der OMG, die eine Sprache für Modell-zu-Modell-Transformationen beschreibt. Das QVT-Metamodell baut auf den Metamodellen von Essential MOF (EMOF) und Essential OCL auf. Letzteres wird um imperative Funktionen erweitert. Sowohl für OCL als auch für QVT gibt es Eclipse-Implementierungen. Eclipse OCL [7] ist eine Implementierung der OCL 2.3-Spezifikation für die Verwendung mit Ecore und UML-Metamodellen. Sie ist erweiterbar und wird als eine Komponente in 12

31 3 Ansätze für die Definition von Abfrage- und Transformationssprachen einer Vielzahl von anderen Eclipse-Projekten wie z.b. GMF, QVTo und anderen verwendet. Es gibt momentan zwei Varianten von Eclipse-OCL-Implementierungen: ein ausgereiftes Metamodell (The mature Eclipse OCL metamodel), das nur begrenzte Funktionalität bietet und ein experimentell erweitertes Metamodell (The pivot Eclipse OCL metamodel), das schon jetzt eine Standard Library bietet. Jedoch ist die Abbildung der zugehörigen konkreten Syntax zur abstrakten Syntax noch nicht modellgetrieben und deswegen umständlich zu erweitern. Volle Erweiterbarkeit wurde erstmals für das Juno-Release [9] später dann für das Kepler- Release [10] geplant. QVT Operational (QVTo) [8] ist eine partielle Implementierung der OMG-Standard- Spezifikation (MOF) 2.0 Query/View/Transformation (QVT). Für die Zukunft ist eine vollständige Umsetzung des operationellen Teils des Standards geplant. 3.3 Epsilon Framework Epsilon [9] steht für Erweiterbare Plattform mit integrierten Sprachen für Modell- Management (engl. Extensible Platform of Integrated Languages for model management). Dies ist eine Plattform für den Aufbau einheitlicher und kompatibler domänenspezifischer Sprachen, die unter anderem folgende Manipulationen mit den Modellen ermöglichen: Modell-zu-Modell-Transformationen, Textgenerierung aus Modellen, Modellvergleich, Zusammenführung von Modellen und Validierung. Außerdem bietet Epsilon die Möglichkeit, weitere Sprachen für eigene Ziele zu definieren. Der Kern von Epsilon ist EOL, eine auf OCL basierte Sprache, die die nötige Infrastruktur zur Programmierung bietet und eine Reihe von in anderen Sprachen wiederverwendbaren Grundfunktionen für das Modell-Management zur Verfügung stellt (z.b. Schleifen, Zuweisungen, Operationen auf Mengen, usw.). Darauf basierend werden alle anderen Sprachen von Epsilon definiert, wodurch sie alle einen gemeinsamen Kern haben. Somit können die wiederverwendbaren Funktionen mit EOL definiert und im Kontext der anderen Sprachen verwendet werden. [6] Momenten stellt Epsilon folgende Sprachen zur Verfügung [14]: Epsilon Object Language (EOL) Bietet Grundfunktionen zum Modell-Management; kann auch als selbstständige Mehrzwecksprache benutzt werden oder, um die wiederverwendbaren Funktionen auszuklammern 13

32 3 Ansätze für die Definition von Abfrage- und Transformationssprachen Epsilon Validation Language (EVL) Ermöglicht die Definition von Zusicherungen (hat eine ganze Reihe von Verbesserungen gegenüber der ursprünglichen OCL) Epsilon Generation Language (EGL) Ermöglicht Modell-zu-Text-Transformationen. Z.B. können Berichte als Text, HTML oder Quellcode erstellt werden Epsilon Transformation Language (ETL) Bietet Funktionalität für Modell-zu-Modell-Transformationen, inklusive Transformationen zwischen Modellen verschiedener Typen Epsilon Comparison Language (ECL) Ermöglicht den Vergleich verschiedener Modelle Epsilon Merging Language (EML) Ermöglicht die Zusammenführung unterschiedlichster Modelle Epsilon Wizard Language (EWL) Bietet Funktionen zur Durchführung von Refactoring von Modellen Für jede Sprache bietet Epsilon Eclipse-basierte Entwicklungs-Tools und einen Interpreter, der in dieser Sprache geschriebene Programme ausführen kann. Diese Sprachen sind unabhängig von den Technologien, auf denen die Modelle basieren. Momentan unterstützt Epsilon EMF-basierte Modelle, aber mithilfe von EMC (Epsilon Model Connectivity Layer) können die Treiber für andere Modelltechnologien realisiert werden. Ist ein Treiber für eine solche Sprache realisiert, so können alle oben genannten Sprachen verwendet werden. Auch ist der gleichzeitige Zugriff auf Modelle, auf die mit verschiedenen Treibern zugegriffen wird, möglich, was z.b. bei Modell-zu-Modell- Transformationen notwendig ist, um UML-Modelle in DeepML-Modelle zu transformieren. 3.4 OCL und QVT vs Epsilon Framework In diesem Kapitel werden beide Ansätze - Verwendung von OCL und QVT sowie die Verwendung von Epsilon Framework - gegenübergestellt und ein Ansatz für weitere Realisierung ausgewählt. OCL und QVT sind beide für Modelle definiert, die auf der MOF-Architektur basieren. Diese besitzt eine feste Anzahl von logischen Ebenen, wobei für die Definition von Benutzermodellen nur eine Ebene (nämlich M1) zu Verfügung steht. Für die Instanzen der Elemente des Benutzermodells ist entsprechend die Ebene M0 vorgesehen. Somit unterstützt die MOF-Architektur nur die flache Instanziierung, was bestimmte Schwierigkeiten und wahr- 14

33 3 Ansätze für die Definition von Abfrage- und Transformationssprachen scheinlich Einschränkungen bei der Implementierungen für DeepML-Modelle mit sich bringen kann, da diese ja auf der tiefen Instanziierung und einer unbegrenzte Ebenenanzahl basieren. Epsilon-Sprachen sind dagegen unabhängig von der Technologie, auf der die Modelle basieren. Mithilfe einer Zwischenschicht in Form eines Connectivity Layer kann Epsilon mit beliebigen Modellen funktionieren, für die ein entsprechende Treiber realisiert ist. Mit dieser Technologie ist die Integration eigener Typsysteme möglich. Somit kann die tiefe Instanziierung integriert werden. Als nächstes wurde bei der Untersuchung von OCL- und QVTo-Projekten für Eclipse festgestellt, dass ihre Erweiterungen, so wie sie für DeepML nötig sind, schwierig zu realisieren erscheinen. Das Epsilon Framework ist dagegen für Erweiterungen angelegt und da alle Epsilon-Sprachen untereinander kompatibel sind, können schon existierende Sprachen hier leicht benutzt werden. Als letzter Punkt ist festzustellen, dass man bei der Verwendung des Epsilon Frameworks und der Realisierung des Connectivity Layer automatisch gleichzeitig alle Sprachen erhält, die Epsilon definiert (und die, die vielleicht erst später definiert werden), wogegen bei der Erweiterung von OCL und QVT am Ende nur diese beiden Sprachen zu Verfügung stehen. Wie man leicht aus Tabelle 1, in der alle Vor- und Nachteile nochmal gegenübergestellt sind, ersehen kann, erscheint das Epsilon Framework als bessere Wahl für die Zwecke dieser Arbeit. OCL und QVT MOF-basierte Modelle Kennt nur flache Instanziierung Erweiterung kompliziert (dies wurde erkannt und daran wird derzeit gearbeitet) Zwei Implementierungen (OCL und QVT) Epsilon Framework + Unabhängig von den Technologien auf denen die Modelle basieren + Integration eigener Typsysteme möglich + Angelegt für Erweiterungen + Eine Implementierung für EMC (Connectivity Layer): alle Epsilon-Sprachen automatisch nutzbar Tabelle 1: Vergleich von OCL und QVT mit Epsilon Framework 15

34 4 Konzeption und Realisierung des DeepML Connectivity Layer 4 Konzeption und Realisierung des DeepML Connectivity Layer Als Lösungsansatz für die Definition von Abfrage- und Transformationssprachen wurde die Verwendung von Epsilon Framework gewählt. Für die Realisierung dieser Sprachen muss der DeepML Connectivity Layer implementiert werden. Dafür wurden zwei Plug-in- Projekte angelegt (siehe Abbildung 9). Das erste Projekt mit dem Namen de.developgroup.deepml.emc beinhaltet die Implementierung für DeepML Connectivity Layer selbst. Seine Klassen werden in den nächsten Unterkapiteln beschrieben. Das zweite Projekt mit dem Namen de.developgroup.deepml.gui realisiert die Integration des DeepML Connectivity Layer in das Eclipse GUI. Es ermöglicht eine bequeme Parameterangabe der Modelleigenschaften, die für die Ausführung von Epsilon- Programmen erforderlich sind, in einem Dialogfenster. Seine Beschreibung findet im Kapitel 4.8 statt. package de.developgroup.deepml.emc package de.developgroup.deepml.emc.gui DeepMLModel package deepmlwrapper DeepMLModel ConfigurationDialog DeepMLProperty Getter EpsilonDMLClabject DeepMLProperty Setter Linguistic MMToolkit Ontological MMToolkit Abbildung 9: Paketdiagramm: Implementierung des DeepML Connectivity Layer 16

35 4 Konzeption und Realisierung des DeepML Connectivity Layer 4.1 Epsilon Connectivity Layer und die Schnittstelle IModel Um von verschiedensten Repräsentationen sämtlicher Modelle und unterschiedlichsten APIs der Modellierungstechnologien zu abstrahieren, wird von Epsilon ein IModel Interface definiert, das von dem spezifischen Connectivity Layer realisiert werden muss. Dieses Interface bietet unter anderem die Methoden zur Abfrage und Änderungen von Modellelementen auf hohem Abstraktionsniveau. So agiert die EMC als Treiber zwischen dem Modell und den Epsilon-Sprachen. Abbildung 10 veranschaulicht das Prinzip anhand des Beispiels des DeepML-Modells. DeepML Connectivity Layer implementiert IModel Interface, somit können die Epsilon-Sprachen die DeepML-Modelle manipulieren. EOL Engine... EVL Engine EOL-Programs EVL-Programs IModel DeepML Connectivity Layer DeepML Model Abbildung 10: DeepML Connectivity Layer als Treiber Für die einzelnen Sprachen von Epsilon (z.b. EOL oder EVL vergleiche Kapitel 3.3) stellt das Epsilon Framework Komponenten genannt Engines zur Verfügung, die die entsprechenden Programme parsen und die Befehle auf Modelloperationen über die EMC umsetzen. Dabei kann es sich um Anfragen oder Änderungswünsche handeln, die im Folgenden im Kontext der Schnittstelle IModel genauer diskutiert werden. Abbildung 11 zeigt einen Ausschnitt aus der Architektur der EMC. ModelRepository verwaltet die verschieden Modelle. Mit jedem Modell sind ein PropertyGetter und ein PropertySetter assoziiert, die zu Abfrage und Setzen von Attributen der Elemente dienen. Darüber hinaus bietet Epsilon das Transaktionskonzept, das in der laufenden Version nicht umgesetzt wurde, weswegen hier nicht näher darauf eingegangen wird. 17

36 4 Konzeption und Realisierung des DeepML Connectivity Layer -name:string -aliases:string[*] IModel +load():void +load(properties:properties,string:string):void +store():void +store(location:string):void +dispose():void +allcontents():object[*] +owns(element:object):boolean +creteinstance(type:string):object +creteinstance(string type, Collection<Object> parameters):object +deleteelement(element:object):void +getallofkind(type:string):object[*] +getalloftype(type:string):object[*] +getenumerationvalue(enum:string, label,string):void +getelementbyid(id:string):object +getelementid(object:object):string +gettypeof(element:object):string +getpropertygetter():ipropertygetter +getpropertysetter():ipropertysetter +hastype(type:string):boolean +ismodelelement(element:object):boolean +isofkind(element:object, type:string):boolean +isoftype(element:object, type:string):boolean * +models +propertysetter +propertygetter -object:object -property:string ModelRepository +getowningmodel(modeelement:object):imodel +getmodelbyname(name:string):void +dispose():void IPropertySetter +invoke(value:object):void IPropertyGetter +invoke(object:object,property:string):object Abbildung 11: Architektur der EMC (Epsilon Model Connectivity Layer) 4.2 Verwalten von Modellen Man kann in einem Epsilon-Programm gleichzeitig mit mehreren Modellen arbeiten, die sich unterschiedlicher Technologien bedienen (z.b. UML- und DeepML-Modelle in einer Modell-zu-Modell-Transformation). Diese Modelle werden von ModelRepository verwaltet. IModel selbst hat die Attribute zur Speicherung des Namens des Modells und einiger ihre Alias. Die load() und load(string Properties properties, String basepath) Methoden dienen zum Laden des Modells in den Arbeitsspeicher aus der Datei. Die zweite Variante hat zusätzlich Properties als Parameter, die verschiedene Eigenschaften über das Modell übergeben lässt, z.b. ob das Modell beim Entladen gespeichert werden soll. Beim Entladen des Modells wird die Methode dispose() aufgerufen. Wenn das Modell dabei gespeichert werden soll, muss eine der beiden Methoden store() oder store(location: String) aufgerufen werden. Bei der zweiten Methode kann ein Speicherort angegeben werden, wenn er vom Ladeort abweicht. 4.3 Erzeugung und Entfernung von Modellelementen Ein Modellelement wird mithilfe einer der beiden Methoden createinstance erzeugt. Im ersten Fall wird nur der gewünschte Typ als ein String übergeben, im zweiten zu- 18

37 4 Konzeption und Realisierung des DeepML Connectivity Layer sätzlich eine Collection mit Parametern. Das erzeugte Element wird als ein Object zurückgegeben. createinstance(string type): Object createinstance(string type, Collection<Object> parameters): Object Abbildung 12 zeigt wie diese Methode funktioniert. Zuerst wird überprüft, ob es sich beim angegebenen Typ um einen linguistischen oder einen ontologischen Typ handelt. Abhängig davon wird die Erzeugung an LinguisticMMToolkit oder OntologicalMM- Toolkit weiter geleitet, die dann das Element erzeugen und als ein Object zurückliefern. Die Klasse LinguisticMMToolkit kapselt die Methoden, die mit der linguistischen Instanziierung zusammenhängen (z.b. liefert die Methode getlinguistictypes alle linguistischen Typen zurück, die es im Modell gibt). Die Klasse OntologicalMMToolkit dagegen kapselt die Methoden, die sich mit der ontologischen Instanziierung befassen (z.b. liefert die Methode getclabjectforname ein Clabject mit angegebenem Namen zurück). :EolModel ElementType :DeepMLModel :LinguisticMMToolkit :OntologicalMMToolkit createinstance() alt [is linguistic type] createinstance() Object [is ontological type] createinstance() Object Object Abbildung 12: Erzeugung eines Modellelements Zum Entfernen des Modellelements wird die Methode deleteelement(object instance) benutzt. 4.4 Erhalten von Instanzen Es gibt zwei Methoden zum Erhalten der Instanzen des bestimmten Typs (type). getalloftype(string type): Collection<?> getallofkind(string type): Collection<?> 19

38 4 Konzeption und Realisierung des DeepML Connectivity Layer Die erste (getalloftype) liefert die Elemente, die Instanzen genau dieses Typs sind, und die zweite (getallofkind) liefert die Instanzen nicht nur des Typs selbst, sondern auch seinen Unterklassen. Am besten versteht man dies mithilfe eines Beispiels. In Abbildung 13 ist ein Klassendiagramm mit drei logischen Ebenen zu sehen. Die Clabjects auf Ebene L0 haben Namen, die mit Clabject_L0 beginnen, auf Ebene L1 mit Clabject_L1 und auf Ebene L2 entsprechend mit Clabject_L2. Die beiden letzten Ziffern sind laufende Nummern der Clabjects auf einer Ebene. Die Clabjects mit gleichen Nummern auf der unteren Ebene sind Instanzen der entsprechenden Clabjects auf der höheren Ebene. So liefert die Methode getalloftype für Clabject_L0_00 nur ein Clabject_L1_00 als Resultat zurück (In Abbildung 13 links grau dargestellt). Die Methode getallofkind dagegen liefert für das gleiche Clabject_L0_00 vier Clabjects zurück: Clabject_L1_00, Clabject_L1_01, Clabject_L1_02 und Clabject_L1_03 (In Abbildung 13 rechts blau dargestellt). Clabject_L1_03 ist kind of Clabject_L1_00, weil das Clabject_L1_03 eine Instanz von Clabject_L0_03 ist, welches eine (indirekte) Spezialisierung des Clabject_L1_00 ist. An dieser Stelle ist noch hinzuzufügen, dass die Instanziierung nicht transitiv ist, im Gegensatz zur Generalisierung [8]. Somit sind die Clabjects auf Ebene L2 nicht die Instanzen der Clabjects der Ebene L0, obwohl sie die Instanzen von Clabjects der Ebene L1 sind, die wiederum die Instanzen von Clabjects der Ebene L0 sind. getalloftype Clabject_L0_00 getallofkind Clabject_L0_00 L0 Clabject_L0_01 Clabject_L0_02 L0 Clabject_L0_01 Clabject_L0_02 Clabject_L0_03 Clabject_L0_03 Clabject_L1_00 Clabject_L1_00 L1 Clabject_L1_01 Clabject_L1_02 L1 Clabject_L1_01 Clabject_L1_02 Clabject_L1_03 Clabject_L1_03 Clabject_L2_00 Clabject_L2_00 L2 Clabject_L2_01 Clabject_L2_02 L2 Clabject_L2_01 Clabject_L2_02 Clabject_L2_03 Clabject_L2_03 20

39 4 Konzeption und Realisierung des DeepML Connectivity Layer Abbildung 13: Beispiel für eine komplexe Generalisierungs- und Klassifikationshierarchie Bei der Implementierung der beiden Methoden werden ebenso wie bei der Erzeugung der Instanzen zwei Fälle unterschieden: der angegebene Typ ist ein linguistischer Typ oder ein ontologischer Typ. Zur Überprüfung, ob eine Instanz zu einem bestimmten Typ gehört, gibt es zwei Methoden, die die gleiche Semantik für is kind of - und is type of -Beziehungen haben: isofkind(object instance, String type): Boolean isoftype(object instance, String type): Boolean Den Typ des bestimmten Elements kann man mit folgender Methode abfragen: gettypeof(object element): String 4.5 Anfragen an Modelle nach Modellelementen Folgende Methoden erlauben es, verschiedene Anfragen an ein Modell nach dessen Elementen zu stellen: allcontents():object[*] liefert alle Elemente des Modells zurück owns(element:object):boolean liefert true, wenn das Modell das angegebene Element besitzt hastypeof(type:string):boolean liefert true, wenn das Modell den angegebenen Typ besitzt ismodelelement(element:object):boolean liefert true, wenn das angegebene Element ein Element des Modells ist 4.6 Abfrage und Modifizierung der Attribute von Modellelementen Für das Auslesen der Eigenschaften der Modellelemente und ihre Modifizierung werden PropertyGetter und PropertySetter gebraucht. Um diese zu erhalten, definiert das Interface IModel zwei Methoden: getpropertygetter():ipropertygetter getpropertysetter():ipropertysetter Der DeepML Connectivity Layer muss die zwei Klassen DeepMLPropertyGetter und DeepMLPropertySetter bereitstellen, die entsprechend IPropertyGetter und 21