Domänenspezifische Sprachen

Transkript

1 Domänenspezifische Sprachen Eine Einführung und Vertiefung am Beispiel des Eclipse Xtext Framework Mirko Heinold MatrikelNr: März 2012 Institut für Informatik Christian-Albrechts-Universität zu Kiel Arbeitsgruppe Kommunikationssysteme

2

3 Zusammenfassung Diese Seminararbeit beschäftigt sich mit den Thema Domain-Specific Languages (DSLs) und dem Erstellen solcher in Xtext. Hierzu wird der Begriff DSL erläutert, es werden Arten von DSLs vorgestellt und Vor- und Nachteile werden aufgezählt. Dies findet anhand von Beispielen statt. Anschließend wird das Eclipse-basierende Framework Xtext, welches das automatisierte Erstellen von DSLs erlaubt, vorgestellt. Es wird hierfür eine Beispiel-DSL eingeführt und mit Xtext implementiert, so dass am Ende ein Editor und eine Übersetzung in eine Zielsprache vorhanden sind. iii

4

5 Inhaltsverzeichnis 1 Einleitung Aufbau dieser Arbeit Domänenspezifische Sprachen Beispiele Arten von DSLs Interne DSLs Externe DSLs Vor- und Nachteile Xtext Die Xtext Grammar Language Der mittels Xtext-Grammatik generierte Editor Zielcodegenerierung mit Xtend Zusammenfassung und Bewertung 15 v

6

7 Abkürzungsverzeichnis DSL Domain-Specific Language SQL Structured Query Language YACC Yet Another Compiler Compiler BNF Backus Naur Form EBNF Extended Backus Naur Form HTML HyperText Markup Language GPL General Purpose Language API Application Programming Interface AST Abstract Syntax Tree JVM Java Virtual Machine EMF Eclipse Modeling Framework UML Unified Modeling Language vii

8

9 Abbildungsverzeichnis 2.1 Umschreibung von Gleitkommadarstellungen in C Anwendungsbeispiel Beispiel-DSL und eine daraus generierbare Anwendung Darstellung des generierten Editors Auszug generierter Interfaces ix

10

11 Listings 2.1 EBNF als Beispiel-DSL Rake als Beispiel einer internen DSL Verwendung unserer Beispiel-DSL Beispiel einer Xtext Grammatik Auszug aus Xtend-Code zum Generieren des HTML-Code (Teil 1) Auszug aus Xtend-Code zum Generieren des HTML-Code (Teil 2) Mit Xtend generierter HTML-Code xi

12

13 1 Einleitung Eines der wesentlichen Probleme der Informatik besteht darin, abstrakte Probleme und Sachverhalte dem Computer mitzuteilen. Das richtige Umschreiben von Problemen auf einer Abstraktionsebene, die sowohl für Computer als auch Menschen verständlich ist, ist eine zentrale Herausforderung. Unterschiedlichste Programmiersprachen wurden hierzu entwickelt, verwendet und auf Maschinen zur Ausführung gebracht. Abstraktionen von Maschinensprachen wie Assembler bis hin zu Hochsprachen wie Java wurden dafür mit unterschiedlichen Erfolg verwendet und entwickelt. Dennoch bleibt die Umschreibung von vielen Problemen in diesen Sprachen eine zeitaufwendige und komplexe Angelegenheit. Ein Ansatz damit umzugehen ist die Entwicklung von unterschiedlichen, meist kleinen Sprachen, die für das konkrete Problem eine ideale Abstraktion bieten. Dieses hat beispielsweise in der Unix-Welt Tradition [1]. Diese Domain-Specific Languages (DSLs) sind Spezialsprachen für die von ihnen abgedeckte Domäne. Um Anwendungsfälle, Ausprägungen, Vor- und Nachteile sowie die Entwicklung von DSLs wird es im Folgenden gehen. Um auf die Entwicklung von DSLs näher einzugehen, findet einen Auseinandersetzung mit dem Xtext Framework statt. Dieses bietet Tools für eine möglichst einfache Entwicklung von DSLs. 1.1 Aufbau dieser Arbeit Um in das Thema DSLs und deren Entwicklung näher einzuführen, findet zunächst eine Erläuterung des Begriffes DSL statt. Dies geschieht anhand von Beispielen. Danach geht es um unterschiedliche Arten von DSLs und die Vor- und Nachteile der Verwendung von DSLs. Im Hauptteil der Arbeit geht es dann um Xtext. Xtext und seine Funktionsweise wird hier anhand einer Beispiel-DSL erläutert. Hierzu wird nacheinander auf das Beschreiben von Grammatiken mit Xtext, den mit Hilfe einer Grammatik generierbare Editor und die Generierung eines Zielcodes für die Beispiel-DSL eingegangen. Zur Codegenerierung wird Xtend verwendet. Am Ende der Arbeit steht ein Fazit, das Möglichkeiten aber auch Nachteile der DSL- Entwicklung, insbesondere mit Xtext, aufzeigt 1

14

15 2 Domänenspezifische Sprachen Zur Lösung von Problemen in der Informatik kann man grundsätzlich zwischen generischen oder spezifischen Lösungen unterscheiden [2]. Eine spezifische Lösung bieten domänenspezifische Sprachen, englisch Domain-Specific Languages. Dies sind Programmiersprachen, die auf praktische Probleme einer bestimmten Domäne zugeschnitten sind [3]. DSLs haben eine beschränkte Ausdrucksfähigkeit [4], welches der Fokussierung auf eine Domäne und den damit verbundenen Schwerpunkten und Anforderungen geschuldet ist. DSLs sind also Spezialsprachen, die mit der Intention gebaut wurden, ein konkretes Problem möglichst effizient zu lösen. Der Einsatz von DSLs hat zudem das Ziel, einen einfachen Zugang zum Kontrollieren und Beschreiben komplexer Systeme zu ermöglichen [5]. 2.1 Beispiele DSLs sind in der Informatik allgegenwärtig. Oft ist einem beim Verwenden einer DSL gar nicht klar, dass man es mit einer solchen zu tun hat. Prominente Beispiele für DSLs sind TEX, SQL, Make, YACC, LEX, BNF und HTML [2]. Als Beispiel für eine nähere Betrachtung bietet sich die Extended Backus Naur Form (EBNF) an. Hierbei handelt es sich um eine Erweiterung der BNF zum formalen Beschreiben der Grammatik von Programmiersprachen [6]. In Listing 2.1 ist eine EBNF angegeben, welche Darstellung von Gleitkommazahlen in der Programmiersprache Go 1 beschreibt. Listing 2.1: EBNF als Beispiel-DSL a 1 float_lit = decimals "." [ decimals ] [ exponent ] 2 decimals exponent 3 "." decimals [ exponent ]. 4 5 decimals = decimal_digit { decimal_digit }. 6 7 exponent = ( "e" "E" ) [ "+" "-" ] decimals. 8 9 decimal_digit = "0"..."9". a Beispiel von Wie für DSLs typisch, sind EBNFs genau für einen speziellen Anwendungsfall, nämlich 1 3

16 2 Domänenspezifische Sprachen die Beschreibung von Grammatiken, entwickelt worden. In diesem Kontext sind EBNFs dann aber sehr effizient. Es lässt sich, nachdem einmal die Syntax verstanden ist, mit der dargestellten Grammatik sehr leicht entscheiden, welche Zeichenfolgen gültige Gleitkommadarstellungen in Go sind. Zum Vergleich ist in Abbildung 2.1 angegeben, wie eine Umschreibung der Darstellung von Gleitkommazahlen in textueller Form aussehen kann. Eine Gleitpunktkonstante besteht aus einen ganzzahligen Teil, einen Dezimalpunkt, einem Dezimalbruch, dem Zeichen e oder E, einem ganzzahligen Exponenten mit optionalen Vorzeichen und einem optionalen Typ-Suffix, nämlich einem der Buchstaben f, F, l oder L. Ganzzahligen Teil und Dezimalbruch sind Ziffernfolgen. Entweder der ganzzahlige Teil oder der Dezimalbruch kann fehlen (aber nicht beide); entweder der Dezimalpunkt oder der Exponent beginnend mit e kann fehlen (aber nicht beide). Abbildung 2.1: Umschreibung von Gleitkommadarstellungen in C [7] Diese Umschreibung ist so im Anhang der deutschen Ausgabe des Kernighan and Ritchie zu finden. Eine EBNF Darstellung ist übersichtlicher, deutlich besser zu lesen und zu verstehen. Es wird elegant abstrahiert und auch eine spätere Implementierung der Grammatik ist aufgrund der klaren Regeln einfacher. Keine DSLs sind so genannte General Purpose Languages (GPLs), also allgemeine Programmiersprachen. Diese grenzen sich von DSLs dadurch ab, dass sie nicht nur für ein bestimmtes konkretes Problem einer Domäne geeignet sind. Zudem ermöglicht der zur Verfügung stehende Funktionsumfang Verwendung in mehreren Bereichen [8]. Prominente Beispiele für GPLs sind etwa C++, Java und C# [9]. 2.2 Arten von DSLs Unterschiedliche DSLs werden typischerweise in zwei Arten von Sprachen eingeteilt. Es lassen sich das Erweitern und Wiederverwenden einer Sprache oder das Entwickeln einer eigenständigen Sprache realisieren. Es findet auf dieser Basis eine Unterteilung in interne und externe DSLs statt [10] Interne DSLs Interne DSLs, auch embedded DSLs genannt, beschreiben das Verwenden einer Hostsprache als Basis der eigenen Sprache [10]. Interne DSLs haben keine eigene Syntax, sondern verwenden die der Hostsprache. Als Hostsprache bieten sich unterschiedlichste Sprachen wie Java oder C# an. In Listing 2.2 ist ein Programm in der DSL Rake 2 an

17 2.3 Vor- und Nachteile gegeben, welche als Hostsprache Ruby verwendet. Rake bietet die Funktionalität eines Make für Ruby-Programme bietet aber einen größeren Funktionsumfang als Make. Listing 2.2: Rake als Beispiel einer internen DSL a 1 file main.o => ["main.c", "greet.h"] do 2 sh "cc -c -o main.o main.c" 3 end 4 5 file greet.o => [ greet.c ] do 6 sh "cc -c -o greet.o greet.c" 7 end 8 9 file "hello" => ["main.o", "greet.o"] do 10 sh "cc -o hello main.o greet.o" 11 end a Beispiel von Bei dem angegeben Programm handelt es sich um ein gültiges Ruby-Programm, welches durch die spezielle Struktur und das Verwenden spezieller APIs zu einen Rake- Programm wird. Bei internen DSLs handelt es sich also um eine Teilmenge der Hostsprache, die, meist angereichert um spezielle APIs, verwendet wird. Die Vorteile für das Verwenden von internen DSLs liegen auf der Hand: Ein Compiler und Parser sind schon vorhanden, Tools wie beispielsweise Editoren für die Sprache sind ebenfalls schon vorhanden. Wenn der Programmierer die Hostsprache beherrscht gibt es wenig Berührungsängste und Einarbeitungszeit bei der Verwendung der DSL Externe DSLs Externe DSLs haben ihre komplett eigene Syntax, was allerdings auch zur Folge hat, dass für sie ein eigener Parser geschrieben werden muss [10]. Ein Beispiel für eine externe DSL wurde bereits in Listing 2.1 betrachtet. Vorteile bei der Verwendung von externen DSLs sind, dass man bei der Syntax keine Einschränkungen hat und dass beim Schreiben eines Compilers für die externe DSL domänenspezifische Anforderungen mitvalidiert werden können. 2.3 Vor- und Nachteile Die Verwendung und das Entwickeln von DSLs hat sowohl Vor- als auch Nachteile. Hat man erst einmal eine gute DSL entwickelt, profitiert man von Vorteilen wie geringeren Entwicklungskosten für neue Anwendungen, guten Code, Lesbarkeit oder einer geringen Anzahl an Code-Zeilen [8]. Ein weiterer Vorteil von von DSLs ist, dass diese die Domäne, für die sie entwickelt wurden besser abbilden. Wurde bei der Entwicklung ein gutes Maß an Abstraktion gefunden, kann die DSL auch von Experten der entsprechenden Domäne verstanden, validiert und oft sogar programmiert werden [2]. 5

18 2 Domänenspezifische Sprachen Ein weiterer Vorteil ist, dass DSLs häufig selbst dokumentierend sind [2]. Da sie für eine Domäne entwickelt wurden, ist das Umschreiben, was der vorliegende Code genau macht, häufig schon Teil der Sprache. Auch Wiederverwendung zu verschiedenen Zwecken, gute Wartbarkeit und Portabilität, sowie Testen unter Berücksichtigung der Eigenschaften der betrachten Domäne gehören zu den Vorteilen von DSLs [2]. Vor allem das bereits angesprochene validieren auf Domänenebene, aber auch Optimieren von erzeugtem Code unter Berücksichtigung der Domäne sind starke Argumente für die Verwendung von DSLs. Größter Nachteil der Verwendung von DSLs sind die Kosten, die für Entwicklung, Implementierung und Wartung der Sprache entstehen [2]. Zur Entwicklung ist genaues Wissen über die Domäne, für die die Sprache entwickelt werden soll, nötig. Hierfür werden sowohl Fachleute für den DSL-Entwurf, sowie für die betrachtete Domäne benötigt. Hinzu kommen Fortbildungen des Personals, damit es die DSL verwenden kann und die Schwierigkeit beim DSL-Entwurf die richtige Balance zwischen GPL- und DSL- Konstrukten zu finden [2]. Die Schwierigkeit der richtigen Abstraktion für die zu entwickelnde DSL zeigt sich häufig schon dadurch, wie schwierig es ist, die betrachtete Domäne sinnvoll und eindeutig abzugrenzen. Ein weiterer Nachteil ist zudem, dass durch den Einsatz von DSLs die Anzahl der insgesamt verwendeten Sprachen steigt [8]. Dies bedeutet, dass für ein Softwareprojekt viele unterschiedliche Sprachen und Syntaxen erlernt und beherrscht, sowie im richtigen Kontext eingesetzt werden müssen. Der Erfolg einer DSL und vor allem die Akzeptanz steht und fällt häufig mit der Tool-Unterstützung. Tools, die über den einfachen Parser und Compiler hinausgehen, sind deshalb von großer Wichtigkeit [11]. Grade aber komplexe, stabile und zuverlässig arbeitende Tools können die Entwicklungskosten für eine DSL deutlich in die Höhe treiben. Als letzter hier aufgeführter Nachteil ist zudem noch anzumerken, dass mit DSLs erstellte Programme häufig nicht dieselbe Effizienz, bezogen auf Laufzeit und Speicherverbrauch, wie individuell ausprogrammierte Varianten zeigen [2]. Ein guter Compiler kann diesen Nachteil verkleinern, kostet aber, vor allen wenn er viele Optimierungen enthält, Zeit und Geld. Um einige dieser Nachteile, vor allem die Kosten des DSL-Entwurfs, gering zu halten lohnt sich das verwenden spezieller Tools, die den DSL-Entwurf möglichst preiswert und effizient gestalten. Eines dieser Tools ist Xtext, welches im Folgenden betrachtet werdet soll. 6

19 3 Xtext Xtext 1 ist ein Framework zur Entwicklung von Programmiersprachen und DSLs [12]. Es unterstützt die Entwicklung textueller DSLs [13] durch das Bereitstellen verschiedener DSLs und APIs, um die unterschiedlichen Aspekte einer Programmiersprache zu beschreiben [12]. Xtext ist Eclipse 2 -basierend und erlaubt es, einen Eclipse basierten Editor, ähnlich den bekannten Java-Editor, zum Schreiben der entwickelten Sprache, zu erstellen [12]. Trotz der Eclipse-versiertheit sind die von Xtext erstellten Komponenten zur Übersetzung der DSL, wie der Abstract Syntax Tree (AST) oder Parser, Eclipse-unabhängig. Sie können in jeder Java Umgebung verwendet werden [12]. Mit Xtext soll die für den Erfolg von DSLs so wichtige Unterstützung der entwickelten Sprache mit Tools erleichtert werden [11]. Zentral hierfür ist der erwähnte Editor. Um einen besseren Einblick in Xtext zu erhalten und die Funktionsweisen und Fähigkeiten besser verstehen zu können, wird nun eine Beispiel-DSL mit Hilfe von Xtext entwickelt. Diese ist in Listing 3.1 abgebildet. Listing 3.1: Verwendung unserer Beispiel-DSL 1 Poll "Evaluation" 2 3 Question "Geben Sie Ihren Namen ein" name 4 5 Question "Wie fanden Sie das Seminar?" bewertung 6 () "1 (Sehr Gut)" sehrgut 7 () "2 (Gut)" gut 8 () "3 (Befriedigend)" befriedigend 9 () "4 (Ausreichend)" ausreichend 10 () "5 (Mangelhaft)" mangelhaft Question "Was kann verbessert werden?" verbesserungen 13 [] "Schrift" schrift 14 [] "Beamer" beamer 15 [] "Schokolade fuer alle" schokolade Abbildung 3.1: Anwendungsbeispiel Abbildung 3.2: Beispiel-DSL und eine daraus generierbare Anwendung Es handelt sich bei dieser DSL um eine Sprache zum Beschreiben von Befragungen oder Abstimmungen, in diesem Beispiel bezogen auf ein Seminar. Hierzu bietet die DSL die Verwendung von Antworten als Text-, Multiple-Choice- oder Single-Choice-Antwort

20 3 Xtext an. Ein mögliches Anwendungsszenario für die Beispiel-DSL ist in Abbildung 3.1 dargestellt. Die DSL lässt sich, wie dargestellt, zum Beschreiben von Homepages für Abstimmungen verwenden, die sich auf Basis der DSL automatisch generieren lassen. 3.1 Die Xtext Grammar Language Beginnen wir nun mit der Beschreibung einer Grammatik für die Beispiel-DSL. Dies ist stets der erste Schritt, nachdem der Aufbau, das Aussehen und der Funktionsumfang einer DSL festgelegt wurde. Die Grammatik zu unserer Beispiel-DSL wird in Listing 3.2 dargestellt. Listing 3.2: Beispiel einer Xtext-Grammatik a 1 grammar org.xtext.example.mydsl.simplepolldsl with org.eclipse.xtext. common.terminals 2 3 generate simplepolldsl " 4 5 Poll: 6 "Poll" description=string 7 (questions+=question)* 8 ; 9 10 Question: 11 TextQuestion SingleChoiceQuestion MultipleChoiceQuestion 12 ; TextQuestion: 15 "Question" title=string name=id; SingleChoiceQuestion: 18 "Question" title=string name=id 19 (options+=singlechoiceoption)+; MultipleChoiceQuestion: 22 "Question" title=string name=id 23 (options+=multiplechoiceoption)+; SingleChoiceOption: 26 "()" title=string name=id 27 ; MultipleChoiceOption: 30 "[]" title=string name=id 31 ; a Beispiel aus einen Vortrag von Peter Friese xtext-google/ Wie leicht zu erkennen ist, ähnelt die dargestellte Grammatik stark der EBNF und regulären Ausdrücken. Die angegebene Grammatik beschreibt Schritt für Schritt die Struktur der bereits in Listing 3.1 verwendeten Sprache für Umfragen. Hierzu werden in den Zeilen 1 bis 3 der Name der Sprache und der Grammatik näher beschrieben. In den Zeilen 5 bis 8 ist dann die erste Grammatikregel zu finden, die angibt, 8

21 3.2 Der mittels Xtext-Grammatik generierte Editor dass eine Umfrage mit dem Schlüsselwort poll anfängt, gefolgt von einem String zur Beschreibung und einer Anzahl beliebig vieler Fragen. Die Anzahl der erlaubten Fragen wird mit * auf 0 bis n festgelegt, das += gibt an, dass diese Fragen im späteren, abstrakten Modell von Sprachen der Grammatik in der Liste questions zu finden sein werden. In den Zeilen 10 bis 12 wird dann angegeben, dass es sich bei einer Question entweder um eine TextQuestion, um eine SingleChoiceQuestion oder um eine MultipleChoiceQuestion handelt. Das oder wird in der Xtext Grammatik Beschreibung mit dargestellt. Die Zeilen 14 bis 23 beschreiben dann die einzelnen Arten von Fragen. Jede Frage beginnt mit dem Schlüsselwort Question, gefolgt von einem Titel, der den Text der Frage enthält, und einer ID, um die Frage identifizieren zu können. Multiple- und Single-Choice Fragen erhalten zudem noch mindestens eine dazugehörige Option. Dass es sich um mindestens eine Option handelt, wird durch + angegeben. In den Zeilen 25 bis 31 erfolgt dann die Umschreibung dieser Optionen. Eine Übersicht der wichtigsten Grammatikregeln wird im Folgenden dargestellt. Zunächst einmal werden die Operatoren aufgeführt, die die Anzahl erlaubten Anwendungen einer Grammatikregel festlegen. kein Operator genau 1 mal? 0 oder 1 mal + mindestens 1 mal * beliebig oft Zusätzlich zu den Konstrukten die die Anzahl von möglichen Regel aufrufen festlegen sind noch die folgenden Konstrukte wichtig. Oder [] Referenz auf eine Regel der Grammatik {} Erzwingt Erstellung eines bestimmten Typs Xtext verfügt also über umfangreiche Möglichkeiten eine Grammatik für eine Sprache zu definieren. Hierzu verwendet man die Xtext Grammar Language, die sowohl die Syntax einer Sprache, als auch die Abbildung von in der Grammar Language geschrieben Code auf ein Modell beschreibt [12]. 3.2 Der mittels Xtext-Grammatik generierte Editor Mit Hilfe der in Abschnitt 3.1 beschriebenen und im Listing 3.2 dargestellten Grammatik lässt sich mit Xtext automatisch ein Editor generieren. Hierzu genügt es, die Grammatik in die beim Erstellen eines Xtext Projektes dafür erzeugte Datei einzugeben und den Prozess zum Erstellen des Editor zu starten. Ein auf diese Weise erstellter Editor ist in Abbildung 3.3 dargestellt. 9

22 3 Xtext Abbildung 3.3: Darstellung des generierten Editors Ein zentrales Feature des Editor ist das Hervorheben der Syntax. Außerdem ist das typische Eclipse Layout zu sehen, zudem lässt sich rechts eine Outline erkennen die beim Navigieren im Code der DSL hilft. Des Weiteren bietet der Editor noch weitere Funktionalitäten wie automatische Code- Vervollständigung, Syntaxüberprüfung, Kreuz-Referenzen und andere, auf die hier nicht näher eingegangen wird [12]. Zusätzlich zu den automatisch erzeugten Funktionen des Editors ist dieser sehr flexibel [12] und anpassbar. Es lassen sich beispielsweise auch Überprüfungen von Eigenschaften der Semantik der Sprache im Editor implementieren. 3.3 Zielcodegenerierung mit Xtend Nachdem der generierte Editor für die Beispiel-DSL betrachtet wurde, wird nun wieder auf die Kernaufgabe von DSLs eingegangen. DSLs sollen meist übersetzt oder interpretiert werden. So sollen aus der Beschreibung der DSL für den Computer verwertbare Informationen gewonnen werden. In Xtext ist zur Übersetzung die Sprache Xtend 3 integriert. Vor der Auseinandersetzung mit Xtend und seiner Syntax wird der Ausgangspunkt unserer Übersetzung genauer betrachtet. Beim Prozess des automatischen Erstellen des Editors wurden außerdem weitere Artefakte wie der Parser, der Serialisierer und zusätzlicher Infrastrukturcode generiert [12]. Diese Komponenten sind integriert und ba

23 3.3 Zielcodegenerierung mit Xtend sieren auf dem Eclipse Modeling Framework (EMF) 4 [12]. Für die Übersetzung der DSL in eine Zielsprache ist hier zunächst nur wichtig, dass EMF ein strukturiertes Modell unserer Daten, auf Basis der Grammatik, als Ausgangspunkt für eine weitere Übersetzung liefert. Einige der generierten Java-Klassen, bzw. in diesen Fall Interfaces, sind in Abbildung 3.4 als UML-Klassendiagramm dargestellt. Soll also eine in der Beispiel-DSL georg.xtext.example.mydsl.simplepolldsl <<Interface>> Poll +getdescription(): String +setdescription(string): void +getquestions(): EList<Question> 1 0..* <<Interface>> Question +gettitle(): String +settitle(string): void +getname(): String +setname(string): void <<Interface>> MultipleChoiceQuestion +getoptions(): EList<MultipleChoiceOption> 1 <<Interface>> TextQuestion <<Interface>> SingleChoiceOption +getoptions(): EList<SingleChoiceOption> 1 1..* <<Interface>> MultipleChoiceOption +gettitle(): String +settitle(string): void +getname(): String +setname(string): void 1..* <<Interface>> SingleChoiceOption +gettitle(): String +settitle(string): void +getname(): String +setname(string): void Abbildung 3.4: Auszug generierter Interfaces schriebene Umfrage in eine HTML Repräsentation übersetzt werden, kann Xtext dazu verwendet werden, eine Darstellung dieser Umfrage in der abgebildeten Objektrepräsentation zu erzeugen. Hier kann nun Xtend eingesetzt werden, und auf Basis der Bereits strukturierten Daten, jeder Objektinstanz den zugehörigen HTML-Code zuordnen. Xtend ist eine statisch getypte Programmiersprache, die auf der Java Virtual Machine (JVM) ausführbar ist [14]. Xtend Programme compilieren zu lesbarem Java-Code, was das Debuggen und Verständnis verbessert [15]. Außerdem gibt es beispielsweise Closures und Typinferenz [14] sowie syntaktischen Zucker für bessere Lesbarkeit. Hinzu kommt Toolunterstützung für Xtend durch Eclipse [14]. Betrachten wir nun den konkreten Xtend Code für das Umwandeln unser Beispiel- DSL für Umfragen in HTML-Code. In Listing 3.3 ist ein Auszug daraus zu sehen: Die Funktion die die Umwandlung eines gegebenen Poll-Objekts anstößt. Der relevante Code hierfür befindet sich zwischen und. Der restliche Text findet sich nachher

24 3 Xtext Listing 3.3: Auszug aus Xtend-Code zum Generieren des HTML-Code 24 def tohtmlcode(poll p) 25 <html> 26 <head> 27 <title>poll</title> 28 </head> 29 <body> 30 <p> 31 <h2> p.description </h2> <br /> 32 FOR question : p.questions 33 <br /> 34 question.generatecode 35 ENDFOR 36 </p> 37 <p> 38 <input type="submit" value="submit" /> 39 </p> 40 </body> 41 </html> 42 unverändert im generierten HTML-Code wieder. Das Schlüsselwort das für diese Art der Syntax verantwortlich ist, besteht aus drei Hochkommata. Listing 3.4: Auszug aus Xtend-Code zum Generieren des HTML-Code 44 def generatecode(question question) { 45 if (question instanceof SingleChoiceQuestion){ 46 var String s 47 s = question.title + "<br />\n" 48 for(singlechoiceoption op: (question as SingleChoiceQuestion).options){ 49 s = s + "<input type=\"radio\" name=\"" + question.name 50 + "\" value=\"" + op.name + "\" />" + op.title + "<br />\n" 51 } 52 return s 53 }else if(question instanceof MultipleChoiceQuestion){ 54 var String s 55 s = question.title + "<br />\n" 56 for(multiplechoiceoption op: (question as MultipleChoiceQuestion).options){ 57 s = s + "<input type=\"checkbox\" name=\"" + question.name 58 + "\" value=\"" + op.name + "\" />" + op.title + "<br />\n" 59 } 60 return s 61 }else{ 62 return question.title + "<input type=\"text\" name=\"" 63 + question.name + "\" /> <br />" 64 } 65 } Es wird also im Code zunächst ein HTML-Gerüst gebaut, bevor in Zeile 31 die Beschreibung der Umfrage in den Code integriert wird. In den Zeilen 32 bis 35 werden nacheinander alle Fragen aufgerufen und entsprechender Code erzeugt. Die dafür verwendete Funktion generatecode(question question) ist in Listing 3.4 dargestellt. Anschließend ist in den Zeilen 36 bis 41 weiterer HTML-Zielcode zu sehen. 12

25 3.3 Zielcodegenerierung mit Xtend Das Listing 3.4 zeigt die angesprochene Funktion zum Generieren des Zielcodes für die einzelnen Fragen. Die hier verwendete Xtend-Syntax ähnelt stark Java. Die Funktion erwartet eine Question als Argument, bestimmt dann die Art der Frage und erzeugt davon abhängig den HTML-Code, der zurückgegeben wird. Es lässt sich anhand des abgebildeten Codes feststellen, dass die Xtend Syntax die Codegenerierung erleichtert. Der komplette, generierte HTML-Code ist in Listing 3.5 dargestellt. Listing 3.5: Mit Xtend generierter HTML-Code 1 <html> 2 <head> 3 <title>poll</title> 4 </head> 5 <body> 6 <p> 7 <h2>evaluation</h2> <br /> 8 <br /> 9 Geben Sie Ihren Namen ein<input type="text" name="name" /> <br /> 10 <br /> 11 Wie fanden Sie das Seminar?<br /> 12 <input type="radio" name="bewertung" value="sehrgut" />1 (Sehr Gut)<br /> 13 <input type="radio" name="bewertung" value="gut" />2 (Gut)<br /> 14 <input type="radio" name="bewertung" value="befriedigend" />3 (Befriedigend)<br /> 15 <input type="radio" name="bewertung" value="ausreichend" />4 (Ausreichend)<br /> 16 <input type="radio" name="bewertung" value="mangelhaft" />5 (Mangelhaft)<br /> 17 <br /> 18 Was kann verbessert werden?<br /> 19 <input type="checkbox" name="verbesserungen" value="schrift" />Schrift<br /> 20 <input type="checkbox" name="verbesserungen" value="beamer" />Beamer<br /> 21 <input type="checkbox" name="verbesserungen" value="schokolade" />Schokolade fuer alle<br /> 22 </p> 23 <p> 24 <input type="submit" value="submit" /> 25 </p> 26 </body> 27 </html> 13

26

27 4 Zusammenfassung und Bewertung Zusammenfassend lässt sich sagen, dass das Erstellen von DSLs immer einfacher und komfortabler wird. Xtext bietet einen deutlichen Vorteil bei der DSL-Entwicklung im Vergleich zu klassischen Ansätzen, wie einer Kombination aus LEX und YACC. Tools wie Xtext machen DSL-Entwicklung preiswerter, da sie die Entwicklung deutlich beschleunigen. Hinzu kommt, dass die entwickelte DSL vor allem dank dem Editor und der damit einhergehenden Benutzerfreundlichkeit eine hohe Qualität hat. Es bleibt aber auch festzuhalten, dass DSL-Entwicklung immer noch Zeit und Geld kostet. Gutes Sprachdesign ist kompliziert und selbst wenn die technische Umsetzung einer DSL schnell möglich ist, so verursacht das Design einer gut durchdachten, komplexeren DSL hohe Kosten. Außerdem findet mit der Verwendung von Xtext eine Festlegung auf die Eclipse Plattform statt. Einige der mit Xtext erstelle Komponenten lassen sich ohne Eclipse verwenden es bleibt aber eine Festlegung auf Java-Technologie. Dieses kann von Vorteil sein, wenn man für Eclipse entwickelt oder eine gute Integration in Java-Umgebungen haben möchte, aber auch ein Nachteil, wenn man flexibel und nicht auf Java zur Ausführung festgelegt sein will. 15

28

29 Literaturverzeichnis [1] M. Fowler, Language workbenches: The killer-app for domain specific languages, Accessed online from: html, [2] A. van Deursen, P. Klint, and J. Visser, Domain-specific languages: an annotated bibliography, SIGPLAN Not., vol. 35, pp , June [3] P. Hudak, Domain-specific languages, Handbook of Programming Languages, vol. 3, pp , [4] M. Fowler, Introducing Domain Specific Languages, [5] J. Bentley, Programming pearls: little languages, Commun. ACM, vol. 29, pp , August [6] L. Garshol, BNF and EBNF: What are they and how do they work, acedida pela última vez em, vol. 16, [7] B. Kernighan and D. Ritchie, Programmieren in C. Hanser Verlag, [8] J. Bentley, Little languages, CACM, vol. 29, no. 8, pp , [9] F. Jouault, J. Bézivin, and I. Kurtev, TCS:: a DSL for the specification of textual concrete syntaxes in model engineering, in Proceedings of the 5th international conference on Generative programming and component engineering. ACM, 2006, pp [10] M. Fowler, DomainSpecificLanguage, DomainSpecificLanguage.html, 2008, [Online; Stand 06. März 2012]. [11] M. Eysholdt and H. Behrens, Xtext: implement your language faster than the quick and dirty way, in Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion. ACM, 2010, pp [12] H. Behrens, M. Clay, S. Efftinge, M. Eysholdt, and P. Friese, Xtext User Guide, Dostupné z WWW: 0 1/xtext. html, [13] S. Efftinge and M. Völter, oaw xtext: A framework for textual DSLs, in Workshop on Modeling Symposium at Eclipse Summit, vol. 32, [14] Xtend User Guide, , [Online; Stand 10. März 2012]. [15] S. Efftinge, Xtend 2 - the Successor to Xpand, xtend-2-successor-to-xpand.html, 2010, [Online; Stand 10. März 2012]. 17