Software Factories SS 2018 - Prof. Dr. Dirk Müller - HTW Dresden
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Software Factories 7 Xtext SS 2018 Prof. Dr. Dirk Müller
Übersicht
● Einführungsbeispiel
● Einordnung und Geschichte
● Schließen der Lücke zwischen EBNF und Metamodell
● Xtext-Grammatiksprache
– Linksrekursion in Xtext?
● TaskDSL-Beispiel
● Erstellung aus bestehendem Ecore-Modell
● Beurteilung von Xtext und Alternativen
● Zusammenfassung
Dirk Müller: Software Factories
SS 2018 2/56
Xtext-Projekt erzeugen (1/2)
Dateinamen-Suffix,
bitte merken!
Dirk Müller: Software Factories
SS 2018 3/56
Xtext-Projekt erzeugen (2/2)
IntelliJ-IDEA-Plug-in kann mit
generiert werden, benötigt dann
zusätzlich Gradle-Buildsystem
Integration ins Web möglich,
benötigt dann Maven oder Gradle
Build-System abhängig von
installierten Plug-ins und
Zielplattform wählbar
Dirk Müller: Software Factories
SS 2018 4/56
Xtext-Projektstruktur
Hauptprojekt zur
Beschreibung der Domäne
Modeling Workflow Engine 2
Workflow-Datei zur Generierung des DSL-Editors
in eigener DSL geschrieben
Xtext-Grammatik, die die konkrete
und abstrakte Syntax der DSL spezifiziert
2 Verzeichnisse für zu generierende
Dateien, z. Z. noch leer
4 (abhängige) Projekte für
die Oberfläche, den Editor und
zugehörige Tests
Dirk Müller: Software Factories
SS 2018 5/56
DSL-Editor mittels MWE2-Datei generieren
Dirk Müller: Software Factories
SS 2018 6/56
DSL-Editor generiert
Dirk Müller: Software Factories
SS 2018 7/56
Java-Projekt in 2. Eclipse-Instanz anlegen
Dirk Müller: Software Factories
SS 2018 8/56
Datei für DSL-Instanz anlegen
Dirk Müller: Software Factories
SS 2018 9/56
DSL-Editor läuft
+ : Content Assist
grammar de.htwdd.sf.domain1.Hellodsl Name der Grammatik
with org.eclipse.xtext.common.Terminals
Import von Standard-Terminalen
generate hellodsl "http://www.htwdd.de/sf/domain1/Hellodsl"
wie ID, STRING, INT
Model:
greetings+=Greeting*; Name und URI des zu
beliebig viele Grüße
erzeugenden Metamodells
Greeting:
(auch keine) verkettet
'Hello' name=ID '!'; Muster eines einzelnen
Hellodsl.xtext Grußes spezifiziert
Dirk Müller: Software Factories
SS 2018 10/56Ecore-Diagramm zum Metamodell
Generierung über Kontextmenü „Initialize ecore_diagram
diagram file“ optional, aber wichtig für Verständnis
Dirk Müller: Software Factories
SS 2018 11/56Einordnung
● Open-Source-Framework zur Entwicklung von
Programmiersprachen und DSLs
● aktuelle Version 2.11.0 vom 1.2.2017
● gehört zum Eclipse Modeling Project, genauer zum
Textual Modeling Framework (TMF)
● Parsergenerator (nutzt ANTLR) mit vielen Zusatzfeatures
– generiert auch EMF-Metamodell
(Klassenmodell für den abstrakten Syntaxbaum)
– generiert Texteditor für Eclipse
– stellt Infrastruktur zur Entwicklung einer modernen IDE passend
zur eigenen Programmiersprache bzw. DSL zur Verfügung
– Parser, Linker, Typechecker, Compiler, Editor als Produkte
● Auszeichnung: Eclipse Community Awards 2010: “Most
Innovative New Feature or Eclipse Project”
Dirk Müller: Software Factories
SS 2018 12/56Geschichte
● 2006 als Teil von openArchitectureWare (oAW) erstmals
veröffentlicht
● seit 2008 Teil des Eclipse Modeling Project
● 2012 Version 2.3
– Xbase zur Integration einer DSL in das Java-Typsystem
– Xtend als Java-ähnliche Programmier- und Templatesprache
● 1.12.2015 Version 2.9
– nicht mehr nur für Eclipse, sondern auch für IntelliJ IDEA
– Entwicklung von DSL-Editoren für Web-Anwendungen
– Build-System-Unterstützung (Maven, Gradle)
● 1.2.2017 Version 2.11
– Refactoring (Modularisierung) durchgeführt
– Generierung eines Sprachservers (für verschiedene IDEs nutzbar)
● Editor-Highlights: Syntaxhervorhebung, Autovervoll-
ständigung incl. Quickfixes; Scoping, Rename-Refactoring
Dirk Müller: Software Factories
SS 2018 13/56ANTLR
● objektorientierter Parsergenerator
● ANother Tool for Language Recognition
● Terence Parr, Uni San Francisco, seit 1989
● aktuelle Version: 4.7 vom 30.03.2017
● Erzeugung von Parsern, Lexern und TreeParsern für
LL(k)-Grammatiken mit beliebigem k, Top-down-Ansatz
– seit Version 4 Linksrekursion außer indirekte korrekt behandelt
● in Java geschrieben
● Zielsprachen: Java, C#, JavaScript, Python2, Python3
● konsistente Notation für Spezifizierung von Lexer, Parser
und TreeParser
● Hauptziel: Bau von Compilern
Dirk Müller: Software Factories
SS 2018 14/56EBNF vs. Ecore
EBNF Ecore
● + nur konkrete Syntax ● + Wiederverwendung
● + lineare Ordnung von durch Vererbung
Elementen ● + auch andere Referenzen
● - keine Wiederverwendung ● + vordefinierte Datentypen
● - nur Enthaltensein- und nutzerdefinierte
Relation Enumerations
~ „nur“ abstrakte Syntax
●
● => Eine sinnvolle EBNF kann nicht aus einem Metamodell
generiert werden und auch umgekehrt nicht!
● Herausforderung: Wie kann die Lücke zwischen diesen
beiden Welten geschlossen werden?
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 15/56Lösungsansätze
● generische Syntax
– wie XML
– Metamodell ausreichend, „keine“ konkrete Syntax nötig
– z. B. UML Human-Usable Textual Notation (HUTN), JSON, YAML
● Metamodell zuerst!
– Metamodell spezifizieren
– textuelle Syntax dazugeben, Grammatik wird generiert
– z. B. Textual Concrete Syntax (TCS)
● Grammatik zuerst!
– Syntax (konkrete + abstrakte) durch Grammatik spezifizieren
– Metamodell wird dann daraus abgeleitet
– z. B. Xtext
– inzwischen unterstützt Xtext auch den Import von Metamodellen
● Separierung von Metamodell und Grammatik
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 16/56Textual Concrete Syntax (TCS)
M3
Quelle: http://www.eclipse.org/gmt/tcs/about.php
abstrakte konkrete
Syntax Syntax
M2
M1
angereicherte
Grammatik
Dirk Müller: Software Factories
SS 2018 17/56Xtext-Workflow (1/2)
Sprache Check,
ähnlich zur OCL
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 18/56Xtext-Workflow (2/2)
M2
M1
Quelle: [5] Dirk Müller: Software Factories
SS 2018 19/56Xtext-Grammatiksprache
● ähnlich zur erweiterten Backus-Naur-Form (EBNF)
● Konvention: Regelnamen beginnen mit Großbuchstaben
● Erweiterungen
– objektorientierte Konzepte
– Daten, die zur Ableitung des Metamodells nötig sind
– Editor
● Beispiel A
A : ( type = B);
type 0..1
B
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 20/56Sprachdeklaration
grammar de.htwdd.sf.domainmodel.Domainmodel
with org.eclipse.xtext.common.Terminals
● Name der Sprache mit einem gültigen Java-Qualifier
angeben
● Dateinamensuffix xtext
– Domainmodel.xtext im Paket de.htwdd.sf.domainmodel
● Bezugnahme auf andere Sprachdeklarationen möglich,
hier Import der Standard-Terminale (später mehr)
– „grammar mixins“
– bei Namensgleichheit von Regeln: deklarierte Regel mit höherer
Priorität als importierte, überschreibt diese also
Quellen: [1][4]
Dirk Müller: Software Factories
SS 2018 21/56Ableitung/Import eines Ecore-Metamodells
● Xtext-Parser erzeugen im Speicher Objekt-Graphen, die
Instanzen von Ecore-Metamodellen sind.
● Ein Ecore-Metamodell besteht aus einem EPackage, darin
sind Instanzen der Modellierungselemente EClass, EEnum
und EDataType enthalten.
● Anlegen einer Instanz von EPackage
generate domainmodel
"http://www.htwdd.de/sf/domainmodel/Domainmodel"
● Import eines EPackage mit Alias-Vergabe und -Einsatz
import "http://www.eclipse.org/emf/2002/Ecore" as ecore
terminal INT returns ecore::EInt: ('0'..'9')+;
Quelle: [1]
Dirk Müller: Software Factories
SS 2018 22/56Regelarten
1. Terminalregeln (auch: Token- oder Lexer-Regeln)
- liefern Token für den Parser
2. Parser-Regeln (auch Produktions- oder EObject-Regeln)
- legen Instanzen von EClass an
3. Datentyp-Regeln
- legen Instanzen von EDataType an
4. Enum-Regeln
- legen Instanzen von EEnum an
Quelle: [4] Dirk Müller: Software Factories
SS 2018 23/561. Terminalregeln
● Konvention: Regelnamen vollständig in Großbuchstaben
– z. B. COMMENT
● spezifizieren den Lexer (Überführung einer Sequenz von
Zeichen in eine Sequenz von Token)
● vordefinierte Regeln u.a. für ID, INT, STRING
● Vererbung aus org.eclipse.xtext.common.Terminals,
sogenanntes „grammar mixin“
terminal ID :
'^'?('a'..'z'|'A'..'Z'|'_')('a'..'z'|'A'..'Z'|'_'|'0'..'9')*;
● z. B.: ID
– muss min. 1 Zeichen lang sein, nach oben Länge offen
– darf nicht mit einer Ziffer beginnen
– Zirkumflex '^' als Präfix bei Konflikt mit Schlüsselwörtern
Quelle: [4] Dirk Müller: Software Factories
SS 2018 24/56Terminalregeln
● vereinfachte formale Definition einer Terminalregel:
TerminalRule:
'terminal' name=ID ('returns' type=TypeRef)? ':'
alternatives=TerminalAlternatives ';';
● Reihenfolge der Angabe der Terminalregeln ist
entscheidend, „shadow“ => nicht rein deklarativ
– besondere Vorsicht bei Wiederverwendung
● geben jeweils atomaren Wert zurück, Standard ist Instanz
von ecore::EString
– ggf. eigene Implementierung einer Konvertierung von String nötig
● z. B.: Ganzzahl besteht aus beliebig vielen,
aber min. 1 Ziffer und gibt den Wert zurück
terminal INT returns ecore::EInt: ('0'..'9')+;
Quelle: [4] Dirk Müller: Software Factories
SS 2018 25/56EBNF-Ausdrücke
● Kardinalitäten mit ? * + ('bla')*
dahinter spezifiziert
● Schlüsselworte terminal, datatype
● Zeichenbereiche mit .. zwischen 'a'..'z'
Anfang und Ende des Bereichs
● Jokerzeichen . 'f'.'o'
● Until-Token -> '/*'->'*/'
● Negationstoken ! '#' (!'#')* '#';
● Regelaufruf INT '.' INT
● Alternative | (' '|'\t'|'\r'|'\n')+
● Dateiendezeichen EOF
Quelle: [4] Dirk Müller: Software Factories
SS 2018 26/562. Parser-Regeln
● dienen dem Aufbau des Syntaxbaums mit Nichtterminalen
und Terminalen als Knoten
● liefern Plan für Aufbau von EObject-Instanzen, die das
semantische Modell (Metamodell) bilden
● nutzbare Konstrukte: Gruppe, Alternative, Schlüsselworte,
Regelaufruf
● zusätzliche Mittel zum Aufbau des AST
Quelle: [4] Dirk Müller: Software Factories
SS 2018 27/56Assignments
● Informationen zu einem Feature des aktuell produzierten
Objekts hinzufügen
● Typ des aktuellen Objekts durch den Rückgabetyp der
Regel (implizit: Typname = Regelname) bestimmt
● Typ des Features wird von der rechten Seite der
Zuweisung bestimmt
● Assignment-Operatoren
– Zuweisung eines Elements =
– Hinzufügen am Ende einer Liste +=
– Boolescher Assignment-Operator ?=
beim Konsumieren auf true gesetzt, unabhängig vom Wert
● ungeordnete Gruppen: beliebige Reihenfolge &
Modifier: static?='static'? & final?='final'? & visibility=Visibility;
Quelle: [4] Dirk Müller: Software Factories
SS 2018 28/56Querverweise
● Alleinstellungsmerkmal von Xtext
● Spezifizierung von Cross-reference-Informationen für den
Linker bereits in der Grammatik
Transition:
event=[Event] '=>' state=[State];
Event:
name=ID code=ID;
● Text zwischen Klammern bezeichnet keine Regel, sondern
eine EClass, d. h. einen Typ
Quelle: [4] Dirk Müller: Software Factories
SS 2018 29/56Aktionen
● Typ und Inhalt des von einer Parser-Regel zurückzu-
gebenden Objekts wird bei einem Assignment bestimmt
● mittels Aktionen kann das zurückzugebende Objekt explizit
bestimmt werden => Grammatik kürzer und besser lesbar
MyRule returns TypeA:
"A" name=ID | MyRule returns TypeA:
MyOtherRule; "A" name=ID |
"B" {TypeB} name=ID;
MyOtherRule returns TypeB:
"B" name = ID;
Verfeinerung des Typs
durch Aktion
Bedingung: TypeB⊆TypeA
Quelle: [4] Dirk Müller: Software Factories
SS 2018 30/56Regelaufrufe ohne Assignments
Delegieren an andere Regeln, die dann den Rückgabetyp
bestimmen Action:
LunchAction | MeetingAction |
PaperAction | PaymentAction;
LunchAction:
'Lunch' location=ID;
MeetingAction:
'Meeting' topic=STRING;
PaperAction:
'Report' report=ID;
PaymentAction:
'Pay' amount=INT 'euro';
Quelle: [4] Dirk Müller: Software Factories
SS 2018 31/56Linksrekursion in Xtext?
● Fehlermeldung,
so nicht möglich
● Grund: aktuelle
Xtext-Version
2.11.0 nutzt
intern ANTLR
3.2.0
● evtl. später
Nutzung von
ANTLR 4
● momentan
manuelles
Umschreiben
der Regeln nötig
Dirk Müller: Software Factories
SS 2018 32/56Linksfaktorisierung
Delegierung an neue Regel
neue Regel
explizite Priorität durch Klammerung
Dirk Müller: Software Factories
SS 2018 33/56Redundanter AST durch Linksfaktorisierung
Expression:
{Operation} left=TerminalExpression (op='+' right=TerminalExpression)?;
TerminalExpression returns Expression:
'(' Expression ')' |
{IntLiteral} value=INT;
Operation { syntactic sugar
left=Operation {
Ausdruck (42) liefert den AST left=IntLiteral {
value=42
}
}
}
Quelle: [4] Dirk Müller: Software Factories
SS 2018 34/56Abhilfe: Regelaufrufe ohne Assignments +
Assigned Actions
Expression:
TerminalExpression ({Operation.left=current}
op='+' right=Expression)?;
tree rewrite action
TerminalExpression returns Expression:
'(' Expression ')' |
{IntLiteral} value=INT;
● Erzeugen einer Instanz von Operation und Zuweisen des
aktuellen Rückgabewertes (Variable current) an das
angegebene Feature (left)
● in Java: Operation temp = new Operation();
temp.setLeft(current);
current = temp;
● (42) korrekt als ein IntLiteral
Quelle: [4]
● (40 + 2) korrekt mit zweien erkannt
Dirk Müller: Software Factories
SS 2018 35/56Syntactic Predicates: Dangling-Else-Problem
● Frage: Zu welchem „if“ if (isTrue())
if (isTrueAsWell())
gehört das „else“? doStuff();
else
● Antwort: Zum zweiten (inneren), dontDoStuff();
denn Einrückungen sind meist Luft
für den Compiler (außer in Python) und so steht es in der
Sprachspezifikation.
● Implementierung durch ein Syntactic Predicate, eine Art
Direktive für den Parser, nicht über andere Optionen bei
einem Match nachzudenken
Condition:
'if' '(' condition=BooleanExpression ')'
then=Expression
(=>'else' else=Expression)?
Quelle: [4] Dirk Müller: Software Factories
SS 2018 36/56Versteckte Terminalsymbole
● Ausblenden semantisch unwichtiger Zeichen
● Standardeinstellung aus Terminals.xtext Block-Kommentar
grammar org.eclipse.xtext.common.Terminals
hidden(WS, ML_COMMENT, SL_COMMENT) Zeilen-Kommentar
terminal ML_COMMENT : '/*' -> '*/';
terminal SL_COMMENT : '//' !('\n'|'\r')* ('\r'? '\n')?;
terminal WS : (' '|'\t'|'\r'|'\n')+;
Whitespaces
● Beispiel: auch Setzen per Regel möglich, dann Vererbung
an alle transitiv aufgerufenen Regeln
Person hidden(WS, ML_COMMENT, SL_COMMENT):
name=Fullname age=INT ';';
Fullname:
(firstname=ID)? lastname=ID; John /* comment */ Smith // line comment
/* comment */
42 ; // line comment
Quelle: [4] Dirk Müller: Software Factories
SS 2018 37/563. Datentyp-Regeln
● eine Art Terminalregeln, die aber vom Parser behandelt
werden, erzeugen EDataType-Instanzen
– kontextsensitiv => sicherer, kein „shadow“
– Verwendung versteckter Token möglich scheitert z. B. beim Parsen von
123.toString()
● Beispiel: Parsen von Dezimalzahlen
terminal DECIMAL: Decimal:
INT '.' INT; INT '.' INT;
● Beispiel: qualifizierte Namen
terminal QUALIFIED_NAME: QualifiedName:
ID ('.' ID)*; ID ('.' ID)*;
● Verlockung: genereller Einsatz statt Terminalregeln
– Parsen wird zu langsam
Quellen: [4][7] Dirk Müller: Software Factories
SS 2018 38/564. Enum-Regeln
● Abkürzung für eine Datentyp-Regel
– einfach
– typsicher
– leicht zu verifizieren
● erzeugt eine EEnum-Instanz
● Beispiel: erschöpfende Aufzählung im Modell
zugelassener Zeiteinheiten
enum TimeUnit:
MINUTE = 'min' |
HOUR = 'hour' |
DAY = 'day' |
WEEK = 'week';
Quelle: [4] Dirk Müller: Software Factories
SS 2018 39/56Abbildung von Xtext auf Ecore zur
Konstruktion des Metamodells
Quelle: [6]
Dirk Müller: Software Factories
SS 2018 40/56Beispiel: TaskDSL
grammar persons.tasks.TaskDSL
with org.eclipse.xtext.common.Terminals
generate taskDSL "http://www.tasks.persons/TaskDSL"
Planning: personlist += PersonTasks*;
PersonTasks: 'Person' name=ID tasks += Task+;
Task: 'Task' action = Action
'priority:' prio = INT
('duration:' dl = INT unit = TimeUnit)?;
Action: LunchAction | MeetingAction | PaperAction | PaymentAction;
LunchAction: 'Lunch' location = ID;
MeetingAction: 'Meeting' topic = STRING;
PaperAction: 'Report' report = ID;
PaymentAction: 'Pay' amount = INT 'euro';
enum TimeUnit:
MINUTE = 'min' |
HOUR = 'hour' |
DAY = 'day' |
WEEK = 'week';
Quelle: [5] Dirk Müller: Software Factories
SS 2018 41/56TaskDSL: Syntaxgraph der Grammatik
Terminal Nichtterminal
Quelle: [5]
Dirk Müller: Software Factories
SS 2018 42/56TaskDSL: generiertes Metamodell
Quelle: [5] Dirk Müller: Software Factories
SS 2018 43/56TaskDSL: Editor läuft
Quelle: [5] Dirk Müller: Software Factories
SS 2018 44/56Erstellung aus bestehendem Ecore-Modell
(1/5)
Dirk Müller: Software Factories
SS 2018 45/56Erstellung aus bestehendem Ecore-Modell
(2/5)
sollte dem umschließenden
Container im EMF-Modell
entsprechen
Dirk Müller: Software Factories
SS 2018 46/56Erstellung aus bestehendem Ecore-Modell
(3/5)
Dirk Müller: Software Factories
SS 2018 47/56// automatically generated by Xtext
grammar de.htwdd.sf.library.xtext.LibraryDSL
with org.eclipse.xtext.common.Terminals Erstellung
aus beste-
import "platform:/resource/de.htwdd.sf.library/model/library.ecore"
import "http://www.eclipse.org/emf/2002/Ecore" as ecore
Library returns Library:
{Library}
'Library'
hendem
name=EString
'{' Ecore-Modell
('writers' '{' writers+=Writer ( "," writers+=Writer)* '}' )?
'}';
('books' '{' books+=Book ( "," books+=Book)* '}' )? (4/5)
EString returns ecore::EString:
STRING | ID;
Writer returns Writer:
{Writer}
'Writer'
name=EString
'{'
('books' '(' books+=[Book|EString] ( "," books+=[Book|EString])* ')' )?
'}';
Book returns Book:
{Book} 1.GenerateLibraryDSL.mwe2
'Book' als MWE2 Workflow ausführen
'{'
('title' title=EString)?
2. neue Eclipse-Instanz starten
('pages' pages=EInt)? 3. neues Java-Projekt dort anlegen
('category' category=BookCategory)? 4. neue Datei my.librarydsl anlegen
('author' author=[Writer|EString])?
'}'; 5. Inhalte mittels DSL eintragen
EInt returns ecore::EInt:
'-'? INT;
enum BookCategory returns BookCategory:
Mystery = 'Mystery' | ScienceFiction = 'ScienceFiction' | Biography =
'Biography';
Dirk Müller: Software Factories
SS 2018 48/56Erstellung aus bestehendem Ecore-Modell
(5/5)
● komfortabler Editor mit DSL für bestehendes Metamodell
schnell generiert
● konkrete Syntax nun anpassbar
● „Metamodell zuerst!“ auch mit Xtext möglich
Dirk Müller: Software Factories
SS 2018 49/56Beurteilung von Xtext
● + kompakt: minimaler Aufwand für kleine/einfache DSLs
– leicht erlernbar, da auf EBNF basierend
● + gute Integration in EMF und Eclipse
● + Editor mit Komfortfeatures mitgeliefert
● - keine gute Trennung der Zuständigkeiten
– Texterkennung, Transformation und Editor-Generierung verwoben
● - Bidirektionalität schwer erreichbar
● - keine Wiederverwendung von Modulen möglich
– Parser ANTLR und Grammatik-Basis EBNF nicht austauschbar
● - schlecht wartbar, da alles in einem spezifiziert + generiert
● - unvollständig: nicht alle Prg.-Sprachen beschreibbar
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 50/56Alternative: baumbasierter Ansatz
● Idee: modularisiere Transformation in 2 Schritte
mit einem AST (Baum) als Zwischenprodukt
1. Text-zu-Baum-Transformation mit einem Parser (aus EBNF-
Spezifikation generiert)
2. Baum-zu-Modell-Transformation mit einer
Modelltransformationssprache beschrieben
● Schritt 1 ohne Zusatzaufwand, direkt aus EBNF
● Schritt 2 muss Typen- und Kontextdaten mit einbeziehen
– prinzipiell beliebige Metamodelle als Ziel möglich
– komplexere Metamodelle erfordern hier komplexere Verarbeitung
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 51/56Workflow mit ANTLR und eMoflon
einfaches Baum-Metamodell Ziel-Metamodell
Story Driven
Modeling (SDG)
Triple Graph
Grammars (TGG)
EBNF
Text Baum Modell
Text2Tree Tree2Model
Lexer und Parser Transformation
Quelle: [2][3]
Dirk Müller: Software Factories
SS 2018 52/56Vorteile textueller DSLs gegenüber grafischer
● gut skalierbar
● automatische Formatierung (Zeilenumbrüche, Einrückung,
Syntaxhervorhebung) funktioniert gut
● kompakte und ausdrucksstarke Syntax
– für erfahrene Nutzer hohe Produktivität (vgl. Tastatur vs. Maus)
– Autovervollständigung und Online-Syntaxprüfung als
Komfortfeatures in IDE erleichtern das Schreiben von Code in der
DSL
– Editor leichter zu erstellen als für grafische DSLs
● Konfigurationsmanagement erleichtert
– Versionierungswerkzeuge für Textdaten ausgereifter als für
Modelldaten => verteiltes, paralleles Entwickeln erleichtert
– diff, merge, search, replace, etc.
– aber: Modellversionierung für Eclipse als EMFStore seit 2014
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 53/56Moderne Entwicklungstechniken für DSLs
● DSLs sind sehr verbreitet: CSS, reguläre Ausdrücke, Ant,
SQL, HQL, Rails.
● interne DSLs
– in existierende Wirtssprachen eingebettet
– explizite interne DSLs, z. B. Rake in Ruby als Make-Alternative,
Lisp-basierte DSLs, UML2-Profile, XML-Schemas
– implizite interne DSLs durch Fluent Interfaces in Java und C#
simuliert DateFactory.newDate().year(2009).month(2).day(7);
● externe DSLs
– eigene Syntax und Semantik
– eigene Werkzeugkette (Parser, Editor, Compiler/Interpreter)
– nicht nutzerfreundlich: viele zuerst XML-basierte Sprachen nun
externe DSLs
Quelle: [2]
Dirk Müller: Software Factories
SS 2018 54/56Zusammenfassung
● Xtext als komfortabler Parsergenerator, der aus der
Grammatikdefinition ein Ecore-basiertes Metamodell und
einen Eclipse-Editor generiert
● EBNF-basierte Grammatiksprache mit Terminal- u. Parser-
Regeln, spezifiziert Lexer, Parser + Linker (Querverveise)
● Xtext nutzt intern den Parsergenerator ANTLR 3, der als
klassischer Top-Down-Parser keine linksrekursiven Regeln
zulässt: manuelle Linksfaktorisierung solcher Regeln nötig
● Textuelle DSLs scheinen (noch?) für den Profieinsatz
besser geeignet zu sein als grafische.
– gut skalierbar, automatische Formatierung, hohe Produktivität
● Modularisierung in Lexer, Parser und dann Modelltrans-
formation als mächtigere und flexiblere Alternative
Dirk Müller: Software Factories
SS 2018 55/56Literatur
[1] Hartmut Fritzsche, „Software Factories – Skript zur Lehrveranstaltung“,
11.01.2016, Download am 6.4.2016,
http://www2.htw-dresden.de/~fritzsch/SF/Software_Factories_Skript.pdf
[2] Andy Schürr, Gergely Varró: „Textual Modeling Languages“, Folien vom
24.05.2012, Download am 18.04.2016,
http://www.es.tu-darmstadt.de/fileadmin/user_upload/_imported/fileadmin/download/lehre/mbse/LectureSlides/05-DomainSpecificLanguages.pdf
[3] Erhan Leblebici, Anthony Anjorin, Andy Schürr: “Developing eMoflon with
eMoflon,” in: ICMT 2014, S. 138-145, http://dx.doi.org/10.1007/978-3-319-08789-4_10
[4] Xtext-Dokumentation: „The Grammar Language“, Download am 21.04.2016,
https://eclipse.org/Xtext/documentation/301_grammarlanguage.html
[5] Arjan Mooij, Jozef Hooman: „Creating a Domain Specific Language (DSL)
with Xtext“, 15.12.2015, Download am 21.04.2016,
http://www.cs.kun.nl/J.Hooman/DSL/Xtext_DSL_GettingStarted_Mars.pdf
[6] Olivier Le Goaër: „Syntaxe concrète des DSL en IDM [avec Xtext]“,
Download am 22.04.2016
http://fr.slideshare.net/OlivierLeGoar/syntaxe-des-dsl-en-idm-avec-xtext
[7] Sebastian Zarnekow: „Xtext Corner #6 - Data Types, Terminals, Why Should
I Care?“, 2.11.2012, Download am 23.04.2016,
http://zarnekow.blogspot.de/2012/11/xtext-corner-6-data-types-terminals-why.html
Dirk Müller: Software Factories
SS 2018 56/56Sie können auch lesen
