Xcore

Unter dem Motto

”Modellieren f¨ur Programmierer und Programmieren f¨ur Modellie-rer“ zielt Xcore [3] darauf ab, die L¨ucke zwischen Programmierung und Modellierung zu schließen, indem es die Vorteile beider Ans¨atze vereint. Xcore wurde parallel zum ModGraph-Ansatz entwickelt. Es ist eine dom¨anenspezifische Sprache (DSL), die eine

erweiterte konkrete Syntax f¨ur Ecore anbietet. Diese erm¨oglicht neben der Modellierung der Struktur auch die Beschreibung von Verhalten durch Integration der Ausdrucksspra-che Xbase [28]. So entsteht eine vollwertige ProgrammierspraAusdrucksspra-che mit Java-naher Syntax.

Xcore-Modelle

Der Aufbau eines Xcore-Modells ¨ahnelt dem eines Ecore-Modells sehr (siehe Abschnitt 3.1), da es sich um einen Nachbau der entsprechenden Klassen handelt. Zudem enth¨alt jedes Xcore-Modell ein zugeh¨origes Ecore-Modell sowie ein Generator-Modell. Beide wer-den aus dem Xcore-Modell abgeleitet.

Xcore ist in Xtext [29, 4], einem freien Rahmenwerk zur Entwicklung von externen, textuellen DSLs spezifiziert. Bei der Erstellung der Sprache wird entweder ausgehend von der konkreten Syntax (der Xtext-Grammatik) der Sprache ihre abstrakte Syntax (ein Ecore-Modell) abgeleitet oder - m¨ochte man ein bestehendes Ecore Modell nutzen-eine konkrete Syntax f¨ur dieses definiert. Zudem wird weitere Sprachinfrastruktur be-reitgestellt (Editor, Parser, Compiler, ...). Ein Ausschnitt aus der Xtext-Grammatik zur Xcore-Definition ist in Auflistung 4.1 abgebildet, die vollst¨andige Grammatik befindet sich in Anhang A.6.1.

Der in Auflistung 4.1 dargestellte Abschnitt zeigt die Definition einer Klasse (XClass Definition) und deren Eigenschaften. Die Notation ¨ahnelt der erweiterten Backus Naur Form (EBNF), die unter anderem in [67] besprochen wird. Jeder Klasse k¨onnen beliebig viele Annotationen zugeordnet sein, sie darf zum Interface deklariert werden und hat einen Namen. Zudem wird Generizit¨at und Vererbung unterst¨utzt. Sie kann als Beh¨alter f¨ur eine Java-Klasse oder einen -Datentyp dienen. Jede Klasse beinhaltet beliebig viele Elemente (XMember Definition), die entweder Operationen, Referenzen oder Attribute sind.

Eine konkrete Spezifikation einer Klasse in Xcore ist am Beispiel Refactoring in Auf-listung 4.2 gezeigt. Diese Auflistung ist lediglich eine andere Sicht auf das bereits in Kapitel 3.4, Abbildung 3.4, als Klassendiagramm dargestellte Refactoring-Modell. Die KlasseRefactoring(Schl¨usselwortclass) definiert, analog zu der im vorangegangenen Ka-pitel 3.4, Referenzen (Schl¨usselwortrefers) auf Klassen des Ecore Metamodells sowie auf eine interne Hilfsklasse.

Auflistung 4.1: Ausschnitt aus der Xcore Grammatik

1 . . .

2 c l a s s R e f a c t o r i n g {

3 r e f e r s H e l p e r h e l p e r

4 r e f e r s ENamedElement [ ] referenceToENamedElement

5 r e f e r s E C l a s s [ ] r e f e r e n c e T o E C l a s s

Auflistung 4.2: Ausschnitt aus dem erRefactoring Xcore-Modell

Operationen (Schl¨usselwort op) definieren Methoden zum Refactoring von Ecore-Klassendiagrammen.

An dieser Stelle sind die Analogien zu Ecore klar ersichtlich: Vergleicht man diese Auf-listung mit Abbildung 3.4, so wird klar, dass es sich um den Aufbau derselben Strukturen handelt. Dar¨uber hinaus wird bei der praktischen Nutzung von Xcore deutlich, dass je-des Element auf das entsprechende Ecore-Element abgebildet wird. So wird jede durch class gekennzeichnete Klasse als EClass aufgefasst. Im ¨Ubrigen ist es m¨oglich, bereits existierende Ecore-Modelle problemlos in Xcore-Modelle zu ¨uberf¨uhren.

Auf dieser Ebene ist Xcore noch nichts anderes als die textuelle Einkleidung von Ecore. Allerdings unterst¨utzt Xcore die Spezifikation von Verhalten durch Einbindung der prozeduralen Ausdruckssprache Xbase. Xbase ist Teil von Xtext und wurde speziell zur Wiederverwendung in beliebigen Xtext-basierten Sprachen, wie Xcore, erstellt. Die Xtext-Grammatik zur Spezifikation von Xbase befindet sich in Anhang A.6.2. Xbase ist eine statisch typisierte Programmiersprache und ist eng verzahnt mit dem Java-Typ-System. Sie bietet eine prozedurale, Java-nahe, ausdrucksorientierte Syntax. Auflistung 4.3 zeigt exemplarisch die Implementierung der im Refactoring-Beispiel genutzten Me-thode addEParameter, die einer Operation im Ecore-Modell einen Parameter hinzuf¨ugt.

Xbase-Ausdr¨ucke stellen Kontrollstrukturen, die aus den g¨angigen Programmierspra-chen bekannt sind, und programmiersprachliche Ausdr¨ucke bereit. In Auflistung 4.3, Zeile 3, wird eine Schleife zum Finden der Operation durchlaufen. In Zeile 4 wird eine Bedingung ¨uberpr¨uft, die ausschließt, dass der Parameter bereits vorhanden ist.

Jeder Ausdruck hat einen R¨uckgabewert. Er kann beliebig mit anderen Ausdr¨ucken, Operatoren, Methodenaufrufen, usw. kombiniert werden, um komplexere Ausdr¨ucke zu

9 newParameter . name = newParameterNameValue

10 op1 . g e t E P a r a m e t e r s . add ( newParameter )

11 newParameter . EType = paramType

12 r e f e r e n c e T o E P a r a m e t e r . add ( newParameter )

13 }

Auflistung 4.3: Einfache Xbase Implementierung der Methode addEParameter

erhalten. Diese erm¨oglichen das Implementieren jeder Xcore definierten Operation sowie die Spezifikation von abgeleiteten Eigenschaften und die Redefinition von Datentypen.

Datentypen k¨onnen zudem inferiert werden. So reicht es, bei der Deklaration einer Va-riablen lediglich das Schl¨usselwort var bzw. val (bei finalen Variablen) voranzustellen, siehe Zeilen 7 und 8 in Auflistung 4.3. Der Typ der Variablen wird durch Dependency Injection mit Google Guice¹ ermittelt.

Des Weiteren wird Dependency Injection genutzt, um Typen von R¨uckgabewerten und von Lambda-Ausdr¨ucken festzustellen. Lambda-Ausdr¨ucke definieren anonyme Funktio-nen auf den aktuell g¨ultigen Elementen. Sie k¨onnen zum Beispiel durch einen einzeiligen Ausdruck ein Element einer gegebenen Liste anhand seiner Eigenschaften identifizie-ren. (In Java w¨are hier eine (meist mehrzeilige) Schleife zu programmieren.) Die filter-Funktion innerhalb der for-Schleife (Zeile 3), sowie die findFirst-Funktion innerhalb der if-Bedingung (Zeile 4), die jeweils Namensgleichheit pr¨ufen, sind zwei Beispiele f¨ur einen Lambda-Ausdruck.

Auch besteht in Xbase die M¨oglichkeit, Operatoren zu ¨uberladen. Ihre Auswertung geschieht durch Funktionsaufrufe mit operator-spezifischer Signatur. Im Gegensatz zu Java k¨onnen demnach beliebige Operatoren auf beliebigen Typen definiert werden. Bei-spielsweise kann Objektgleichheit mit== festgestellt werden (Zeilen 3 und 4, Vergleich von String-Objekten innerhalb der Lambda-Ausdr¨ucke).

Xbase bietet zudem eine kleine Standard-Bibliothek mit erweiterten Methoden an.

Diese k¨onnen aufgerufen werden, als w¨urden sie zu einem bestimmten Typ geh¨oren, sind jedoch extern definiert. Dabei wird das Objekt, auf dem die Methode aufgerufen wird, zum ersten ¨Ubergabeparameter der externen Methode. Eine weitere Eigenschaft von Xbase ist die Modellinferenz. Methoden- und Konstruktoraufrufe werden mit dem Java-Typ-Modell verbunden, das alle Java Sprachkonstrukte unterst¨utzt. Xbase nutzt dies bei der Aufl¨osung von Typen und Methoden sowie zur Festlegung von G¨ultigkeitsbereichen von Variablen. Diese Typinferenz erlaubt die Generierung von validen Java-Quelltext-Fragmenten f¨ur Xcore-Ausdr¨ucke. Damit ist es m¨oglich, dass Sprachen - die Xbase er-weitern - ausf¨uhrbaren Java-Quelltext erzeugen und diesen benutzen. Zum Beispiel wird in Auflistung 4.3, Zeile 8 die zuvor generierte Fabrikmethode zur Erzeugung eines Para-meters in Ecore aufgerufen, in Zeile 9 wird durch Nennung des Attributs name implizit dessen Akzessor-Methode aufgerufen.

Ausf¨uhren eines Modells

Parallel zur Spezifikation des Xcore-Modells wird dieses validiert und ausf¨uhrbarer Java-Quelltext generiert, der auf der Grundlage der Modellinferenz aufbaut. Eine Interpretati-on mit dem Xcore-Interpreter ist ebenfalls m¨oglich. Dieser nutzt die Tatsache, dass jedes Xcore-Modell ein Ecore-Modell (und ein Generator-Modell) beinhaltet. Beide Modelle werden aus dem Xcore-Modell abgeleitet. Das Ecore-Modell kann, wie in 3.2.2 beschrie-ben, interpretiert werden. Der Xbase-Interpreter erm¨oglicht zus¨atzlich die Interpretation von Verhalten.

1N¨aheres zu Google Guice findet sich unter:https://github.com/google/guice

Nutzt man also Xcore mit dem integrierten Xbase, so erh¨alt man ein ausf¨uhrbares Modell, das eine Modell-zu-Modell-Transformation spezifiziert, indem es die Ausf¨uhrung von Methoden auf Instanzen des Modells erm¨oglicht. Es bietet damit eine tats¨achliche Abstraktion zu Java an, denn der Modellierer muss sich nicht mehr mit Quelltext besch¨aftigen.

F¨ur weitere Informationen zu Xcore sei auf die Xcore-Homepage [3] verwiesen. Die Installation der aktuellen Xcore-Version erfolgt in Eclipse.