software factories, ws 2019/20 - htw dresdenmuellerd/swfac_ws201920/07_xtext.pdftitle: software...

Software Factories

WS 2019/20

Prof. Dr. Dirk Müller

7 Xtext

WS 2019/20Dirk Müller: Software Factories

2/56

Ü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


3/56

Xtext-Projekt erzeugen (1/2)

Dateinamen-Suffix,bitte merken!


4/56

Xtext-Projekt erzeugen (2/2)

IntelliJ-IDEA-Plug-in kann mitgeneriert werden, benötigt dannzusätzlich Gradle-Buildsystem

Integration ins Web möglich,benötigt dann Maven oder Gradle

Build-System abhängig voninstallierten Plug-ins und

Zielplattform wählbar


5/56

Xtext-Projektstruktur

Hauptprojekt zurBeschreibung der Domäne

Modeling Workflow Engine 2Workflow-Datei zur Generierung des DSL-Editors

in eigener DSL geschrieben

Xtext-Grammatik, die die konkreteund abstrakte Syntax der DSL spezifiziert

2 Verzeichnisse für zu generierendeDateien, z. Z. noch leer

4 (abhängige) Projekte fürdie Oberfläche, den Editor und

zugehörige Tests


6/56

DSL-Editor mittels MWE2-Datei generieren


7/56

DSL-Editor generiert


8/56

Java-Projekt in 2. Eclipse-Instanz anlegen


9/56

Datei für DSL-Instanz anlegen


10/56

DSL-Editor läuft

grammar de.htwdd.sf.domain1.Hellodslwith org.eclipse.xtext.common.Terminals

generate hellodsl "http://www.htwdd.de/sf/domain1/Hellodsl"

Model:greetings+=Greeting*;

Greeting:'Hello' name=ID '!';

Hellodsl.xtext

Name der Grammatik

Import von Standard-Terminalenwie ID, STRING, INT

Name und URI des zuerzeugenden Metamodells

beliebig viele Grüße(auch keine) verkettet

Muster eines einzelnenGrußes spezifiziert

<Ctrl> + <Space>: Content Assist


11/56

Ecore-Diagramm zum Metamodell

Generierung über Kontextmenü „Initialize Ecore Diagram“ optional, aber wichtig für Verständnis


12/56

Einordnung

● Open-Source-Framework zur Entwicklung von Programmiersprachen und DSLs

● aktuelle Version 2.19 vom 3.9.2019● 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”


13/56

Geschichte● 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– 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)

● 19.9.2018 Version 2.15– Projekt von Kommandozeile, Gradle-Integr., Test-Unterstützung

● 4.3.2019 Version 2.17 Java 11, Abhängigkeitsmanagement besser

● Editor-Highlights: Syntaxhervorhebung, Autovervollständigung incl. Quickfixes; Scoping, Rename-Refactoring


14/56

ANTLR

● objektorientierter Parsergenerator● ANother Tool for Language Recognition● Terence Parr, Uni San Francisco, seit 1989● aktuelle Version: 4.7.2 vom 18.12.2018● 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, Python, Go, Swift● konsistente Notation für Spezifizierung von Lexer, Parser

und TreeParser● Hauptziel: Bau von Compilern


15/56

EBNF vs. Ecore

EBNF● + nur konkrete Syntax● + lineare Ordnung von

Elementen● - keine Wiederverwendung● - nur Enthaltensein-

Relation

Ecore● + Wiederverwendung

durch Vererbung● + auch andere Referenzen● + vordefinierte Datentypen

und nutzerdefinierteEnumerations

● ~ „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]


16/56

Lö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 GrammatikQuelle: [2]


17/56

Textual Concrete Syntax (TCS)

Que

lle:

http

://w

ww

.ecl

ipse

.org

/gm

t/tc

s/ab

out.p

hp

M1

M2

M3

abstrakteSyntax

konkreteSyntax

angereicherteGrammatik

http://www.eclipse.org/gmt/tcs/about.php


18/56

Xtext-Workflow (1/2)

Quelle: [2]

Sprache Check,ähnlich zur OCL


19/56

Xtext-Workflow (2/2)

Quelle: [5]

M2

M1


20/56

Xtext-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

Quelle: [2]

A : ( type = B);

A

B

type 0..1


21/56

Sprachdeklaration

● 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

grammar de.htwdd.sf.domainmodel.Domainmodelwith org.eclipse.xtext.common.Terminals

Quellen: [1][4]


22/56

Ableitung/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

● Import eines EPackage mit Alias-Vergabe und -Einsatz

Quelle: [1]

generate domainmodel "http://www.htwdd.de/sf/domainmodel/Domainmodel"

import "http://www.eclipse.org/emf/2002/Ecore" as ecoreterminal INT returns ecore::EInt: ('0'..'9')+;


23/56

Regelarten

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]


24/56

1. 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“

● 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

terminal ID :'^'?('a'..'z'|'A'..'Z'|'_')('a'..'z'|'A'..'Z'|'_'|'0'..'9')*;

Quelle: [4]


25/56

Terminalregeln

● vereinfachte formale Definition einer Terminalregel:

● 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

TerminalRule: 'terminal' name=ID ('returns' type=TypeRef)? ':' alternatives=TerminalAlternatives ';';

terminal INT returns ecore::EInt: ('0'..'9')+;

Quelle: [4]


26/56

EBNF-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]


27/56

2. 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]


28/56

Assignments

● 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]


29/56

Querverweise

● Alleinstellungsmerkmal von Xtext● Spezifizierung von Cross-reference-Informationen für den

Linker bereits in der Grammatik

● Text zwischen Klammern bezeichnet keine Regel, sondern eine EClass, d. h. einen Typ.

Transition:event=[Event] '=>' state=[State];

Event:name=ID code=ID;

Quelle: [4]


30/56

Aktionen

● 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 | MyOtherRule; MyOtherRule returns TypeB: "B" name = ID;

MyRule returns TypeA: "A" name=ID | "B" {TypeB} name=ID;

Bedingung: TypeB⊆TypeA

Verfeinerung des Typs durch Aktion

Quelle: [4]


31/56

Regelaufrufe 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]


32/56

Linksrekursion in Xtext?

● Fehlermeldung; so nicht möglich

● Grund: Aktuelle Xtext-Version 2.17 nutzt intern ANTLR 3.2 !

● evtl. später Nutzung von ANTLR 4

● momentan manuelles Umschreiben der Regeln nötig


33/56

Linksfaktorisierung

neue Regel

Delegierung an neue Regel

explizite Priorität durch Klammerung


34/56

Redundanter AST durch Linksfaktorisierung

Expression: {Operation} left=TerminalExpression (op='+' right=TerminalExpression)?; TerminalExpression returns Expression: '(' Expression ')' | {IntLiteral} value=INT;

Operation { left=Operation { left=IntLiteral { value=42 } }}

syntactic sugar

Ausdruck (42) liefert den AST.

Quelle: [4]


35/56

Abhilfe: Regelaufrufe ohne Assignments + Assigned Actions

Expression: TerminalExpression ({Operation.left=current} op='+' right=Expression)?; TerminalExpression returns Expression: '(' Expression ')' | {IntLiteral} value=INT;

tree rewrite action

● Erzeugen einer Instanz von Operation und Zuweisen des aktuellen Rückgabewertes (Variable current) an das angegebene Feature (left)

● in Java:

● (42) korrekt als ein IntLiteral● (40 + 2) korrekt mit zweien erkannt

Operation temp = new Operation();temp.setLeft(current);current = temp;

Quelle: [4]


36/56

Syntactic Predicates: Dangling-Else-Problem

● Frage: Zu welchem „if“gehört das „else“?

● Antwort: Zum zweiten (inneren),denn Einrückungen sind meist Luftfü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

if (isTrue()) if (isTrueAsWell()) doStuff(); else dontDoStuff();

Condition: 'if' '(' condition=BooleanExpression ')' then=Expression (=>'else' else=Expression)?

Quelle: [4]


37/56

Versteckte Terminalsymbole

● Ausblenden semantisch unwichtiger Zeichen● Standardeinstellung aus Terminals.xtext

● Beispiel: auch Setzen per Regel möglich, dann Vererbung an alle transitiv aufgerufenen Regeln

grammar org.eclipse.xtext.common.Terminalshidden(WS, ML_COMMENT, SL_COMMENT)terminal ML_COMMENT : '/*' -> '*/';terminal SL_COMMENT : '//' !('\n'|'\r')* ('\r'? '\n')?;terminal WS : (' '|'\t'|'\r'|'\n')+;

Quelle: [4]

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

Block-Kommentar

Zeilen-Kommentar

Whitespaces


38/56

3. Datentyp-Regeln

● eine Art Terminalregeln, die aber vom Parser behandelt werden, erzeugen EDataType-Instanzen– kontextsensitiv => sicherer, kein „shadow“– Verwendung versteckter Token möglich

● Beispiel: Parsen von Dezimalzahlen

● Beispiel: qualifizierte Namen

● Verlockung: genereller Einsatz statt Terminalregeln– Parsen wird zu langsam

Quellen: [4][7]

terminal DECIMAL: INT '.' INT;

Decimal: INT '.' INT;

QualifiedName: ID ('.' ID)*;

terminal QUALIFIED_NAME: ID ('.' ID)*;

scheitert z. B. beim Parsen von123.toString()


39/56

4. 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

Quelle: [4]

enum TimeUnit:MINUTE = 'min' |HOUR = 'hour' |DAY = 'day' |WEEK = 'week';


40/56

Abbildung von Xtext auf Ecore zur Konstruktion des Metamodells

Quelle: [6]


41/56

Beispiel: TaskDSL

grammar persons.tasks.TaskDSLwith org.eclipse.xtext.common.Terminalsgenerate 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]


42/56

TaskDSL: Syntaxgraph der Grammatik

Quelle: [5]

Terminal Nichtterminal


43/56

TaskDSL: generiertes Metamodell

Quelle: [5]


44/56

TaskDSL: Editor läuft

Quelle: [5]


45/56

Erstellung aus bestehendem Ecore-Modell (1/5)


46/56


sollte dem umschließendenContainer im EMF-Modell

entsprechen


47/56



48/56

Erstellung aus beste-

hendem Ecore-Modell

(4/5)

// automatically generated by Xtextgrammar de.htwdd.sf.library.xtext.LibraryDSLwith org.eclipse.xtext.common.Terminalsimport "platform:/resource/de.htwdd.sf.library/model/library.ecore" import "http://www.eclipse.org/emf/2002/Ecore" as ecoreLibrary returns Library:

{Library}'Library'name=EString'{'

('writers' '{' writers+=Writer ( "," writers+=Writer)* '}' )?('books' '{' books+=Book ( "," books+=Book)* '}' )?

'}';EString returns ecore::EString:

STRING | ID;Writer returns Writer:

{Writer}'Writer'name=EString'{'

('books' '(' books+=[Book|EString] ( "," books+=[Book|EString])* ')' )?'}';

Book returns Book:{Book}'Book''{'

('title' title=EString)?('pages' pages=EInt)?('category' category=BookCategory)?('author' author=[Writer|EString])?

'}';EInt returns ecore::EInt:

'-'? INT;enum BookCategory returns BookCategory:

Mystery = 'Mystery' | ScienceFiction = 'ScienceFiction' | Biography = 'Biography';

1.GenerateLibraryDSL.mwe2als MWE2 Workflow ausführen

2. neue Eclipse-Instanz starten3. neues Java-Projekt dort anlegen4. neue Datei my.librarydsl anlegen5. Inhalte mittels DSL eintragen


49/56


● komfortabler Editor mit DSL für bestehendes Metamodell schnell generiert

● konkrete Syntax nun anpassbar● „Metamodell zuerst!“ auch mit Xtext möglich


50/56

Beurteilung 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]


51/56

Alternative: baumbasierter Ansatz

● Idee: modularisiere Transformation in 2 Schritte mit einem AST (Baum) als Zwischenprodukt1. 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]


52/56

Workflow mit ANTLR und eMoflon

Text2Tree Tree2Model

Quelle: [2][3]

Text Baum Modell

Lexer und Parser Transformation

einfaches Baum-Metamodell Ziel-Metamodell

EBNF

Story DrivenModeling (SDG)

Triple GraphGrammars (TGG)


53/56

● 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

Vorteile textueller DSLs gegenüber grafischer

Quelle: [2]


54/56

Moderne 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

● externe DSLs– eigene Syntax und Semantik– eigene Werkzeugkette (Parser, Editor, Compiler/Interpreter)– nicht nutzerfreundlich: viele zuerst XML-basierte Sprachen nun

externe DSLs

DateFactory.newDate().year(2009).month(2).day(7);

Quelle: [2]


55/56

Zusammenfassung

● 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


56/56

Literatur

[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.2016http://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

http://www2.htw-dresden.de/~fritzsch/SF/Software_Factories_Skript.pdf

http://www.es.tu-darmstadt.de/fileadmin/user_upload/_imported/fileadmin/download/lehre/mbse/LectureSlides/05-DomainSpecificLanguages.pdf

http://dx.doi.org/10.1007/978-3-319-08789-4_10

https://eclipse.org/Xtext/documentation/301_grammarlanguage.html

http://www.cs.kun.nl/J.Hooman/DSL/Xtext_DSL_GettingStarted_Mars.pdf

http://fr.slideshare.net/OlivierLeGoar/syntaxe-des-dsl-en-idm-avec-xtext

http://zarnekow.blogspot.de/2012/11/xtext-corner-6-data-types-terminals-why.html

software factories, ws 2019/20 - htw dresdenmuellerd/swfac_ws201920/07_xtext.pdftitle: software...

Documents