Vergleich ausgewählter Vertreter von Language Workbenches zur Entwicklung domänenspezifischer Sprachen

Größe: px
Ab Seite anzeigen:

Download "Vergleich ausgewählter Vertreter von Language Workbenches zur Entwicklung domänenspezifischer Sprachen"

Transkript

1 FernUniversität in Hagen Fakultät für Mathematik und Informatik Lehrgebiet Programmiersysteme Prof. Dr. Friedrich Steimann Abschlussarbeit im Studiengang Master of Computer Science Vergleich ausgewählter Vertreter von Language Workbenches zur Entwicklung domänenspezifischer Sprachen Carsten Blume Matrikelnummer: Betreuer: Marcus Frenkel Abgabedatum:

2

3 Yet there's immense potential here these are tools that could change the face of programming as we know it. Martin Fowler

4

5 Abstract Abstract Diese Arbeit gibt einen Einblick in das Feld der Language Workbenches; bei diesen handelt es sich um Werkzeuge, welche zur professionellen Entwicklung von domänenspezifischen Sprachen gedacht sind. Um eine Einführung in dieses Thema zu bieten, werden zunächst die Grundlagen einer domänenspezifischen Sprache erläutert. Dann folgt eine Darstellung der Kernelemente, die eine Language Workbench ausmachen: das semantische Modell einer Sprache abzubilden; eine Editoren-Umgebung für die Sprachen zu bieten und das Verhalten des semantischen Modells im Rahmen einer Code- Generierung zu realisieren. Innerhalb des Kerns der Arbeit werden dann drei ausgewählte Language Workbenches im Detail dargestellt und miteinander verglichen. Bei diesen handelt es sich die Folgenden: Meta Programming System eine eigenständige Anwendung mit textbasierten, projektionalen Editoren und einer Model-to-Model- Transformation als Generator; Xtext ein Eclipse-Plug-In mit Texteditoren und einem Template-basierten Generator; Generic Modeling Environment eine eigenständige Anwendung zur Definition domänenspezifischer Modellierungssprachen, die grafische Editoren einsetzt, sowie einen Template-basierten Generator. In dieser Arbeit wird dargestellt, dass alle drei Anwendungen sinnvolle Vertreter von Language Workbenches sind. Sie unterscheiden sich jedoch in ihrer Herangehensweise, und demnach auch in ihrem potentiellen Einsatzgebiet. Erklärung Ich versichere, dass ich diese Masterarbeit ohne fremde Hilfe selbstständig verfasst und nur die angegebenen Quellen und Hilfsmittel benutzt habe. Wörtlich oder dem Sinn nach aus anderen Werken entnommene Stellen sind unter Angabe der Quellen kenntlich gemacht. Carsten Blume Hannover, 22. Dezember 2011 i

6 Inhaltsverzeichnis Inhaltsverzeichnis ABSTRACT... I INHALTSVERZEICHNIS... II ABBILDUNGSVERZEICHNIS... IV PROGRAMMCODEVERZEICHNIS... V ABKÜRZUNGSVERZEICHNIS... VI 1 ÜBERBLICK DOMAIN SPECIFIC LANGUAGES WAS SIND DOMAIN SPECIFIC LANGUAGES BESTANDTEILE EINER DOMAIN SPECIFIC LANGUAGE WOZU DIENEN DOMAIN SPECIFIC LANGUAGES BEISPIELE WEIT VERBREITETER DOMAIN SPECIFIC LANGUAGES LANGUAGE WORKBENCHES BEISPIELE VERSCHIEDENER LANGUAGE WORKBENCHES AUSGEWÄHLTE LANGUAGE WORKBENCHES BEISPIELHAFTE DSL ZUM VERGLEICH DER LANGUAGE WORKBENCHES META PROGRAMMING SYSTEM CHARAKTERISIERUNG ALLGEMEINE TECHNISCHE REALISIERUNG Grundelemente Sprachdefinition Generatordefinition GRUNDLEGENDE TECHNISCHE KONZEPTE Bootstrapping der Sprachen zur Sprachdefinition Die Base Language und ihre Erweiterungen IMPLEMENTIERUNG DER JAVA-GUI-DSL Überblick über die Implementierung ZUSAMMENFASSUNG Stärken von MPS Schwächen von MPS XTEXT CHARAKTERISIERUNG ALLGEMEINE TECHNISCHE REALISIERUNG Die Grammar Language Der Language Generator Validierung Anpassung der Entwicklungsumgebung GRUNDLEGENDE TECHNISCHE KONZEPTE Bootstrapping der Grammar Language Die Modeling Workflow Engine Xtend Integration in das Eclipse Modeling Framework IMPLEMENTIERUNG DER JAVA-GUI-DSL Überblick über die Implementierung ZUSAMMENFASSUNG Stärken von Xtext Schwächen von Xtext ii

7 Inhaltsverzeichnis 6 GENERIC MODELING ENVIRONMENT CHARAKTERISIERUNG ALLGEMEINE TECHNISCHE REALISIERUNG Das Modeling Paradigm Typvererbung Model Interpretation GRUNDLEGENDE TECHNISCHE KONZEPTE Bootstrapping des MetaGME Modeling Paradigm Bibliotheken und Metamodell-Komposition IMPLEMENTIERUNG DER JAVA-GUI-DSML Überblick über die Implementierung ZUSAMMENFASSUNG Stärken von GME Schwächen von GME ABSCHLIEßENDER VERGLEICH DER LANGUAGE WORKBENCHES TECHNISCHE GRUNDLAGEN SPRACHDEFINITION EDITOREN GENERATOREN EINSATZBEREICHE FAZIT ANHANG INHALT DER BEIGEFÜGTEN CD LITERATURVERZEICHNIS iii

8 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: Zusammenhang zwischen Metamodell, konkreter Syntax, Semantik, Constraints, Modell und Domäne (3)... 3 Abbildung 2: Zusammenhang zwischen dem Modell und den verarbeitenden Werkzeugen (3)... 7 Abbildung 3: Aufbau eines Language-Module in MPS Abbildung 4: Beispiel eines MPS-Concept anhand des Frame-Concept der Java-GUI-DSL Abbildung 5: Beispiel eines MPS-Editors anhand des Editors des Frame-Concept der Java-GUI-DSL Abbildung 6: Beispiel eines MPS-Constraints anhand des Constraints des NavigationButton-Concept der Java-GUI-DSL Abbildung 7: Beispiel einer MPS-Subtyping Rule anhand der Definition des Buttons der Java-GUI-DSL Abbildung 8: Auszug aus der Mapping Configuration des Generators der Java-GUI-DSL Abbildung 9: Auszug aus dem Root Template des Frames der Java-GUI-DSL Abbildung 10: Beispiel einer Programmierung innerhalb der Java-GUI-DSL in MPS Abbildung 11: Der Constrained Datatype ID der Java-GUI-DSL Abbildung 12: Die wichtigsten Ecore Konzepte (22) Abbildung 13: Paradigm Model in GME am Beispiel des Models der Java-GUI-DSML. 57 Abbildung 14: Modellierungselemente der Metamodell-Komposition in GME Abbildung 15: Beispiel einer Modellierung des ApplicationDiagram innerhalb der Java- GUI-DSML in GME Abbildung 16: Beispiel einer Modellierung eines JavaFrame innerhalb der Java-GUI- DSML in GME iv

9 Programmcodeverzeichnis Programmcodeverzeichnis Programmcode 1: Beispiel einer Sprachsyntax in Xtext anhand der Java-GUI-DSL Programmcode 2: Beispiel der Sprache Xtend als Auszug aus dem Generator der Java- GUI-DSL Programmcode 3: Beispiel einer Programmierung innerhalb der Java-GUI-DSL in Xtext Programmcode 4: Beispiel für die Implementierung der invokeex-methode der BON2Component anhand der Umsetzung für die Java-GUI-DSML in GME v

10 Abkürzungsverzeichnis Abkürzungsverzeichnis API - Application Programming Interface / Programmierschnittstelle AST - Abstract Syntax Tree / Abstrakter Syntaxbaum BON2 - Builder Object Network 2.0 COM - Component Object Model DLL - Dynamic Link Library DSL - Domain Specific Language / Domänenspezifische Sprache DSML - Domain Specific Modeling Language / Domänenspezifische Modellierungssprache EMF - Eclipse Modeling Framework FCO - First Class Object GME - Generic Modeling Environment GPL - General Purpose Language / Universelle Programmiersprache ISIS - Institute for Software Integrated Systems LOP - Language Oriented Programming MPS - Meta Programming System MWE2 - Modeling Workflow Engine 2 POJO - Plain Old Java Object UI - User Interface / Benutzerschnittstelle UML - Unified Modeling Language URL - Uniform Resource Locator vi

11 Überblick 1 1 Überblick Diese Arbeit befasst sich mit der verhältnismäßig jungen Anwendungsfamilie der Language Workbenches, welche sich im Laufe der letzten Jahre entwickelt hat. Diese Anwendungen verfolgen das Ziel, eine Umgebung zur Entwicklung von domänenspezifischen Sprachen (DSLs) unter Zuhilfenahme selbiger zu bieten. Um einen Einblick in die Familie der Language Workbenches zu ermöglichen, werden im Rahmen dieser Arbeit drei Vertreter dieser Anwendungen vorgestellt und näher betrachtet. Da dieses Anwendungsfeld noch in der Entstehung ist, und es eine Vielzahl von Anwendungen verschiedenster Art auf diesem Feld gibt, hat diese Arbeit lediglich den Anspruch einen ersten Einblick in das Themengebiet zu geben. Daher werden repräsentativ diese drei Workbenches, und nicht die Gesamtheit der vorhandenen Vertreter, dargestellt. Der Aufbau der Arbeit gestaltet sich dabei in der Form, dass zunächst eine kurze Einführung in das Thema domänenspezifische Sprachen im Allgemeinen gegeben wird, um die Grundlage des Themas darzulegen. Dann folgt ein Überblick über die Definition und die Aufgaben von Language Workbenches, sowie ein kurzer Überblick darüber, welche Anwendungen in diesem Feld existieren. Den Kern der Arbeit bilden die drei Kapitel, welche die behandelten Language Workbenches vorstellen; diese sind hierbei alle in der gleichen Struktur aufgebaut. Nach der einleitenden Darstellung, woher das Werkzeug stammt und wie es sich entwickelt hat folgt eine erste Charakterisierung der Anwendung; innerhalb dieser wird darauf eingegangen, welche Kernelemente und Grundparadigmen die jeweilige Anwendung ausmachen. Daraufhin erfolgt eine Darstellung der technischen Umsetzung, welche sich in zwei Hauptbereiche aufteilt. Zunächst werden die allgemeinen Anwendungsbestandteile beschrieben, die das Definieren einer DSL ermöglichen. Dann wird auf die Grundlagen eingegangen, welche weiteren Möglichkeiten zur Sprachdefinition existieren und welche Frameworks ggf. als technische Basis zum Einsatz kommen. In einem weiteren Kapitel folgt die Beschreibung, wie eine beispielhafte domänenspezifische Sprache in den Workbenches umgesetzt wird. Abschließend wird bei jedem Werkzeug auf seine spezifischen Stärken und Schwächen eingegangen. Bei den Vertretern die zur Betrachtung in dieser Arbeit ausgewählt wurden, handelt es sich um drei Anwendungen, die verschiedenen Herangehensweisen folgen. Zunächst wird ein Einblick in das Meta Programming System gegeben, welches als Vertreter für eigenständige Anwendungen die auf projektionalen Editoren basieren ausgewählt wurde. Dann erfolgt die Vorstellung von Xtext; dem Vertreter, der die Workbenches repräsentiert, welche als Erweiterung einer bestehenden Entwicklungsumgebung realisiert sind (Xtext basiert hierbei auf einer textuell getriebenen Vorgehensweise). Als dritte Language Workbench wird das Generic Modeling Environment begutachtet, bei welchem es sich wiederum um eine eigenständige Anwendung handelt. Diese Anwendung hat jedoch den Fokus auf der Entwicklung von grafikbasierten, domänenspezifischen Modellierungssprachen. Zum Abschluss der Arbeit erfolgt ein zusammenfassender Vergleich der betrachteten Workbenches. Hierbei wird darauf eingegangen, wie sich die ausgewählten Vertreter hinsichtlich ihrer Vorgehensweise bei der Abbildung der verschiedenen Aspekte einer Language Workbench unterscheiden. Im Rahmen eines Fazits werden dann die gewonnenen Erkenntnisse noch einmal kurz dargestellt. 1

12 2 Domain Specific Languages 2 Domain Specific Languages Im Gegensatz zu General Purpose Languages (GPLs) welche den Anspruch haben als Programmiersprache nicht an ein explizites fachliches Gebiet gebunden zu sein bilden domänenspezifische Sprachen (DSLs) immer nur eine konkrete fachliche Domäne ab. Diese Arbeit vergleicht verschiedene Anwendungen, welche den Zweck haben eine Entwicklungsumgebung für solche Sprachen bereitzustellen. Daher wird im folgenden Kapitel ein kurzer Überblick darüber gegeben, was domänenspezifische Sprachen sind und aus welchen Gründen sie zum Einsatz kommen. 2.1 Was sind Domain Specific Languages Es existiert keine hundertprozentig scharfe Definition dafür, was eine domänenspezifische Sprache ist. Bei vielen Sprachen und Sprachelementen existieren daher verschiedene Meinungen, ob diese zu selbigen zählen oder nicht. Der Begriff DSL ist im Laufe der Jahre gewachsen und hat sich weiterentwickelt, aber eine wirklich fixe akademische Definition wurde hierbei nie getroffen. (1) Eine mögliche immer noch nicht zur Gänze scharfe Definition einer DSL wird von Martin Fowler in seinem Werk Domain-Specific Languages gegeben. Er stützt sich dabei auf die folgenden vier Schlüsselelemente, welche eine solche charakterisieren (1): Computer programming language Eine DSL ist zwar dafür gedacht, die Verständlichkeit einer Sprache für den Endanwender zu erhöhen, aber sie sollte letztlich dennoch von einem Computer ausführbar sein. Language nature Eine DSL sollte den Charakter einer Sprache haben und flüssig formulierbar sein. Ihre Ausdruckstärke sollte nicht nur auf Basis der einzelnen Ausdrücke gegeben sein, sondern auch durch die Art wie die Ausdrücke kombinierbar sind. Limited expressiveness Eine DSL sollte eine begrenzte Ausdrucksstärke haben. Im Gegensatz zu einer GPL, sollte nicht alles innerhalb einer DSL ausgedrückt werden können, sondern nur die für die Domäne relevanten Informationen. Hierdurch sollte eine leichtere Erlernbarkeit gegeben sein. Domain focus Eine DSL sollte den Fokus auf eine bestimmte Domäne richten, und nur für diese einsetzbar sein. Die Sprachen, welche in diese Kategorisierung fallen und somit zu den domänenspezifischen Sprachen zählen lassen sich in die folgenden zwei Arten einteilen (1; 2): External DSL Eine DSL, die komplett eigenständig funktioniert und außerhalb anderer Sprachen zum Einsatz kommt. Eine externe DSL hat eine eigene Syntax und Grammatik; sie verfügt meist über eine eigene Verarbeitung, in Form eines eigenen Parsers. Internal DSL Eine DSL, die innerhalb einer GPL zum Einsatz kommt. Der in der DSL geschriebene Code entspricht hinsichtlich der Syntax dem der GPL in die sie eingelassen ist. Die interne DSL bildet hierbei, über ein entsprechendes Funktionsspektrum, einen fachlichen Bereich ab und versucht diesen über eine entsprechende Kapselung von Funktionalität einfach zugänglich zu machen. 2

13 Domain Specific Languages 2 Über diese beiden Standarddefinitionen hinaus, hat sich in den letzten Jahren noch eine weitere Form von DSLs herausgebildet. Für diese existiert noch keine einheitliche Bezeichnung. Teils wird sie als Nontextual DSL bezeichnet, teilweise auch direkt als Language Workbench. Hierbei handelt es sich um Sprachen, die innerhalb einer speziell hierfür konzipierten Anwendung entwickelt werden, und somit automatisch über entsprechende Editoren, etc. verfügen (siehe 3). Diese Anwendungen sind das zentrale Thema dieser Arbeit. (1; 2) 2.2 Bestandteile einer Domain Specific Language Nachdem nun im vorangegangenen Kapitel kurz erläutert wurde was domänenspezifische Sprachen sind, soll im Folgenden ein kurzer Überblick gegeben werden, woraus eine solche besteht. Hierzu ist der allgemeine Aufbau einer DSL in Abbildung 1 dargestellt, und soll anhand dieses Schemas erläutert werden. Abbildung 1: Zusammenhang zwischen Metamodell, konkreter Syntax, Semantik, Constraints, Modell und Domäne (3) Eine DSL besteht zunächst aus drei essentiellen Elementen: dem Metamodell, der konkreten Syntax und der Semantik. Das Metamodell welches auch als abstrakte Syntax bezeichnet wird definiert, welche logische Struktur der Sprache zugrunde liegt. Innerhalb dieses Modells wird die Domäne der Sprache festgelegt und abgebildet. Hierzu definiert es, welche Entitäten es innerhalb der Domäne gibt, und in welcher Beziehung diese zueinander stehen. Das Metamodell enthält hierbei auch die Constraints, die das Verhalten und die Regeln der Domäne erzwingen; diese sind in der Lage auch die Dinge abzubilden, die in einer reinen Modellierung nicht definierbar sind (z.b. die Eindeutigkeit von Attributnamen). Auf der über das Metamodell definierten abstrakten Syntax basiert die konkrete Syntax der Sprache. Während das Metamodell bestimmt, was innerhalb einer Sprache ausgedrückt werden kann, legt diese fest in welcher Form es ausgedrückt wird. Die Form ist hierbei relativ frei wählbar; sie kann z.b. die Grammatik einer textuellen DSL sein, aber auch die grafische Notation einer Modellierungssprache. Der dritte Bestandteil ist die Semantik, also die Definition der Bedeutung dessen, was in der konkreten Syntax ausdrückt werden kann. Ohne eine Bedeutung im Kontext der Domäne hätten die Elemente der konkreten Syntax keinerlei Ausdrucksstärke, da es keine Festlegung gäbe, was ein Ausdruck der Syntax repräsentiert. Die Semantik wird 3

14 2 Domain Specific Languages meist nicht explizit ausprogrammiert, sondern liegt in Form eines Dokumentes vor, welches die DSL beschreibt; oder sie ist implizit gegeben, dadurch das die Code- Generatoren einer Sprache bestimmte Konstrukte in realen Code umsetzen, und ihnen somit Bedeutung geben. (3) 2.3 Wozu dienen Domain Specific Languages DSLs bieten viele Vorteile, welche für ihren Einsatz sprechen. Aber es existieren selbstverständlich auch Probleme, welche durch die übermäßige oder falsche Verwendung dieser Sprachen entstehen können. Da dieses Kapitel nur einen kurzen Überblick darüber geben soll, aus welcher Motivation heraus DSLs eingesetzt werden, wird an dieser Stelle nur ein kurzer Überblick über einige der Vorteile gegeben. Eine DSL kann z.b. zur Verbesserung der Produktivität der Entwicklung einer Anwendung beitragen, da eine höhere Abstraktionsebene der Implementierung erreicht wird. Dies kann den Vorteil haben, dass innerhalb der Implementierung weniger Fehler entstehen, oder diese durch die einfachere Lesbarkeit schneller entdeckt werden. Hierdurch reduziert sich der Aufwand, welcher mit den entsprechenden Bugfixes verbunden ist. Der erreichte höhere Abstraktionsgrad führt auch zu einer besseren Wiederverwendbarkeit der in der Sprache getroffenen Spezifikationen. Die in einer DSL beschriebene fachliche Grundlade des Systems ist im Allgemeinen weniger Änderungen unterworfen, als die tatsächliche Implementierung der Anwendung. Auch ist es möglich, sich durch eine domänenspezifische Sprache von einem vorherrschenden Programmierparadigma zu lösen. Das heißt, es kann durch die Kapselung des eigentlichen Codes in einer DSL z.b. der Transfer von der Perspektive wie und in welcher Folge etwas geschehen soll, zu der Perspektive was geschehen soll, erreicht werden. (1; 2) Ein weiteres Ziel von DSLs ist eine bessere Integration der fachlichen Domänenexperten in die Implementierung der Anwendung. Dies kann im einfachsten Fall daher rühren, dass über die gemeinsame Definition des Modells der Sprache eine bessere Kommunikation zwischen Domänenexperten und Programmierern erreicht wird. Diese gewinnen hierdurch eine gemeinsame Sprache für und Sichtweise auf das System. Aber es kann auch dazu führen, dass z.b. eine bessere Qualitätskontrolle der für die Domäne definierten Verhaltensweisen und Regeln durch die entsprechenden Domänenexperten selbst erreicht wird; da diese in der Lage sind, die in der speziellen Sprache durch die Entwickler definierten Elemente zu lesen, und zu verstehen. Im besten Fall sind die Domänenexperten selbst in der Lage innerhalb der DSL zu programmieren, und so direkt das fachliche Verhalten der Anwendung zu definieren. (1) 2.4 Beispiele weit verbreiteter Domain Specific Languages Um den Begriff der domänenspezifischen Sprache etwas greifbarer zu machen, soll an dieser Stelle ein kurzer Überblick über weit verbreitete Vertreter gegeben werden. Diese Sprachen sind teils schon lange und fest innerhalb ihres Einsatzgebietes etabliert, und werden oftmals von vielen Programmierern nicht als DSLs wahrgenommen. Dies zeigt, dass DSLs letztlich keine neue Erscheinung sind, sondern nur ihre Rolle im Laufe der Zeit stärker ins Bewusstsein der Informationstechnologie gerückt ist. 4

15 Domain Specific Languages 2 Hier einige Beispiele etablierter und verbreiteter domänenspezifischer Sprachen (1; 2): CSS - Cascading Style Sheets Eine DSL zur Definition der Darstellung von Elementen innerhalb eines Dokuments. Make - Eine DSL zur Definition eines Build-Ablaufs, incl. eines Netzes von Abhängigkeiten zwischen den verschiedenen Build-Schritten. SQL - Structured Query Language Eine DSL zur Definition von Datenbankabfragen und zur Manipulation von Daten in relationalen Datenbanken. HTML - Hypertext Markup Language Eine DSL zur Definition der Inhalte und Strukturen einer Webseite. 5

16 3 Language Workbenches 3 Language Workbenches Die Bezeichnung Language Workbench wurde 2005 von Martin Fowler in einem seiner Artikel geprägt. Sie beschreibt eine Umgebung, in welcher domänenspezifische Sprachen und ihre Toolunterstützung entwickelt werden können; und diese Entwicklung ggf. wiederum mit solchen Sprachen erfolgt. (4) Die im Folgenden dargestellten Informationen über die Grundlagen von Language Workbenches entstammen sofern nicht anders angegeben dem Werk Domain- Specific Languages von Martin Fowler (1). Seit dem Erscheinen dieses Artikels haben sich die möglichen Vertreter dieser Anwendungsgattung deutlich vermehrt. Da es sich nach wie vor um ein stark in der Entwicklung befindliches Feld handelt, ist es daher schwer, eine konkrete Definition des Leistungsumfangs einer Language Workbench vorzunehmen. Es gibt jedoch einige Grundlagen, welche sich im Allgemeinen in allen Workbenches finden lassen. So wird dem Entwickler einer DSL für gewöhnlich die Möglichkeit gegeben, die folgenden drei Aspekte seiner Sprache zu definieren: Semantic model schema Dieses Schema beschreibt die Datenstruktur und die statischen Anteile der Semantik einer DSL; dies geschieht meist über die Verwendung eines Metamodells. DSL editing environment Language Workbenches bieten eine Editoren- Umgebung an, innerhalb derer eine komfortables Programmieren in einer selbstdefinierten DSL möglich ist. Semantic model behavior Dies gibt eine Definition, wie das semantische Modell einer DSL um das Verhalten des späteren Programms angereichert wird. Zum Beispiel durch Methoden, die im Rahmen der Code-Generierung in die Datenstruktur eingebracht werden. Für die Abbildung des semantischen Schemas innerhalb von Language Workbenches kommt meist ein Metamodell der zu definierenden Sprache zum Einsatz. Sprich, die semantischen Datenstrukturen der Sprache werden in einem Modell abgebildet, das definiert, welche Elemente auftreten können, und in welcher Beziehung sie zueinander stehen. Für die genaue Definition des Metamodells und der Elemente, die in seinem Kontext stehen, sei hier auf Kapitel 2.2 verwiesen. Da es sich bei dem Metamodell einer DSL letztlich auch um ein Modell handelt, muss dieses wiederum auch einem Metamodell folgen. Dieses legt fest, welche Elemente und Beziehungen bei der Definition einer Sprache zulässig sind. Innerhalb vieler Language Workbenches ist dieses Metamodell wiederum das semantische Modell einer Sprache zur Sprachdefinition. Diese sog. Schema Definition Language ist also eine innerhalb der Workbench verwendete Sprache zur Definition neuer Sprachen. Hierbei ist es oftmals sogar so, dass die Schema Definition Language in sich selbst weiterentwickelt wird; sie nutzt also die eigenen Mittel zur Sprachdefinition, um den Rahmen vorzugeben, in dem Sprachen definiert werden können. Ist dies der Fall, so handelt es sich um eine sog. Bootstrapped Workbench. Da somit in einer Language Workbench die Datenstruktur einer DSL oftmals als semantisches Modell vorliegt, verzichten viele Vertreter dieser Anwendungsgruppe auch auf Editoren, die Freitext erfassen. Statt dieser die die Eingabe eines beliebigen Textes zulassen, welcher dann in Konstrukte der Sprache übersetzt werden muss kommen projektionale Editoren zum Einsatz. Diese stellen eine Projektion des semantischen Modells dar, und können somit in verschiedenster Form auftreten. Es kann z.b. eine 6

17 Language Workbenches 3 Projektion auf eine grafische Notation erfolgen; aber auch eine tabellarische Darstellung, oder eine Repräsentation als Text ist möglich. Hierbei stellt der Editor immer nur eine Sichtweise auf das zugrundeliegende Modell dar und überträgt Änderungen innerhalb der bearbeiteten Elemente wiederum zurück in selbiges. Der Vorteil hierbei ist, dass solche projektionalen Editoren die möglichen Eingaben des Benutzers bereits direkt auf Konsistenz mit dem zugrundeliegenden Modell prüfen, so dass eine syntaktische Fehleingabe nur schwer möglich ist. Auch ist es möglich verschiedene Editoren gleichzeitig einzusetzen, welche verschiedene Arten der Projektion vornehmen. Dies kann von Vorteil sein, wenn sich bestimmte Details eines Modells z.b. besser grafisch bearbeiten lassen, während andere Bestandteile besser in einer textuellen Darstellung greifbar werden. Hierbei entfällt bei der Projektion der Aufwand, die verschiedenen Repräsentationen ineinander zu übersetzen, da sie alle nur eine Sicht auf das zugrundeliegende (konsistente) Modell darstellen. Abbildung 2: Zusammenhang zwischen dem Modell und den verarbeitenden Werkzeugen (3) Da das Ziel einer DSL nicht nur ist, die gewählte Domäne darstellen zu können, sondern auch ausführbar zu sein, muss eine Language Workbench den Entwickler auch hierbei unterstützen. Hierzu gibt es zwei mögliche Ansätze: einen Interpreter oder einen Code- Generator. Ein Interpreter interpretiert die DSL direkt und führt, auf Basis der in der Sprache formulierten Konstrukte, direkt Aktionen aus; der Code-Generator übersetzt eine DSL zunächst anhand vorgegebener Regeln in eine allgemeine Programmiersprache (GPL), und stellt so die Ausführbarkeit her. Beide arbeiten hierbei auf den Vorgaben, die durch das Metamodell der DSL gemacht werden. In manchen Workbenches wird die Generierung jedoch nicht direkt für dieses Modell der Sprache definiert, sondern es existiert ein weiteres (vordefiniertes) Metamodell, welches diese Generator-Funktion bereits bietet. In diesem Falle erfolgt eine Model-to-Model-Transformation, über die das Modell der DSL in ein Modell der Sprache übersetzt wird, welche diesen Generator anbietet. 7

18 3 Language Workbenches Die Interaktion dieser Komponenten mit dem Metamodell und den Modellen einer domänenspezifischen Sprache ist zur Veranschaulichung schematisch in Abbildung 2 dargestellt. Die verschiedenen Varianten werden innerhalb der Abbildung, ausgehend vom abstrakten Modellverarbeiter, gezeigt. Dieser bildet das Sammelelement aller Weiterverarbeitungsarten für eine Sprache. 3.1 Beispiele verschiedener Language Workbenches Wie bereits erwähnt, hat sich im Laufe der Jahre eine Vielzahl von Anwendungen im Feld der Language Workbenches herausgebildet. Viele von ihnen verfolgen hierbei ganz verschiedene technische Ansätze. Das markanteste und offensichtlichste Merkmal in welchem sich die Vertreter unterscheiden ist, ob sie als eigenständige Anwendung implementiert wurden oder als Erweiterung eines bestehenden Werkzeugs (meist einer Entwicklungsumgebung). Über diese Eigenschaft hinaus, lassen sich die verschiedenen Workbenches auch hinsichtlich ihrer Funktionsweise weiter differenzieren. Dies kann anhand der folgenden Kriterien geschehen (2): Art der Definition des semantischen Modells Das semantische Modell einer DSL kann entweder über eine Modellierung oder über eine Grammatik definiert werden. Art der Editoren Die Editoren können entweder auf Freitext basieren und über einen entsprechenden Parser verarbeitet werden oder es handelt sich um projektionale Editoren, die eine Sicht auf das Modell abbilden. Art der Transformation Bei der Transformation der Sprache (z.b. zur Code- Generierung) kann entweder ein Ansatz über eine Template-basierte Generierung erfolgen oder eine Model-to-Model-Transformation (siehe hierzu auch die Beschreibung im vorhergehenden Kapitel). Im Folgenden sollen nun einige Language Workbenches kurz vorgestellt werden, um einen Überblick über das Feld der Anwendungen zu bieten; diese werden dabei, anhand der eben genannten Merkmale, eingeordnet. Die folgende Liste ist nicht als vollständige Erhebung aller Workbenches zu verstehen, sondern soll nur einige Vertreter darstellen. Die Auswahl der Anwendungen orientiert sich an der Teilnehmerliste der Language Workbench Competition 2011 (5) (siehe Kapitel 3.2 für die in dieser Arbeit betrachteten Werkzeuge): MetaEdit+ Bei MetaEdit+ handelt es sich um eine eigenständige, kommerziell vertriebene Anwendung. Es ist eine Umgebung zur Definition von domänenspezifischen Modellierungssprachen (DSMLs), welche auf einem Metamodell basieren. Dieses Metamodell wird über entsprechende Anwendungsfunktionen definiert. Innerhalb der Anwendung kommen projektionale Editoren zum Einsatz. Die Transformationen können sowohl auf Templates basieren, als auch über einen Model-to-Model-Ansatz abgebildet werden. (6) OOMEGA OOMEGA ist eine auf Eclipse basierende Anwendung. Sie ist frei für Open Source Projekte verfügbar, aber für kommerzielle Projekte kostenpflichtig. Es ist eine Umgebung zur Definition von DSLs, deren Metamodell textuell spezifiziert wird. Die Transformationen des Modells erfolgen hierbei Template-basiert oder über Model-to-Model-Transformationen. (7) Whole Platform Die Whole Platform ist eine auf Eclipse basierende Open Source Anwendung. Sie verwendet projektionale Editoren zur Definition des Metamodells sowie zur späteren Nutzung der DSLs. Die Transformation erfolgt über Templates, die auf Basis von Abfragen der Modelleigenschaften kombiniert werden. (8) 8

19 Language Workbenches 3 Rascal Rascal ist eine Open Source Anwendung. Sie kann sowohl auf der Kommandozeile, als auch als Eclipse-Plug-In eingesetzt werden. Das Metamodell wird hierbei textuell definiert, und die Transformation erfolgt auf Basis von Templates. (9) Spoofax Spoofax ist eine auf Eclipse basierende Open Source Anwendung. Sie verwendet eine textuelle DSL zur Definition des Metamodells der späteren DSL, daher kommen auch textuelle Editoren zum Einsatz. Die Transformation erfolgt auf Basis von Templates, mittels einer speziellen DSL kann auch eine Modell- Transformation erfolgen. (10) Intentional Bei Intentional handelt es sich um eine eigenständige, kommerzielle Anwendung. Sie betreibt einen massiven Einsatz projektionaler Editoren und setzt auch die Transformation als Template-Projektion auf den abstrakten Syntaxbaum (AST) der Zielsprache um. (11) Essential Bei Essential handelt es sich um eine eigenständige Anwendung, welche aktuell unter einer Evaluationslizenz weitergegeben wird. Sie basiert auf der textuellen Definition des Metamodells und dient der Erstellung von DSLs. Sowohl die Transformation über Templates, als auch die Model-to-Model-Transformation, basieren auf textuellen DSLs. (12) Obeo Designer Der Obeo Designer ist eine auf Eclipse basierende, kommerzielle Anwendung zur Definition von DSMLs. Die Definition des Metamodells erfolgt hierbei auch auf Basis einer Modellierung; während sowohl die Transformation auf Template-Basis als auch die über Modelle über speziell dafür ausgelegte textuelle Sprachen erfolgt. (13) EMFText EMFText ist eine auf Eclipse (konkret dem Eclipse Modeling Framework) basierende Open Source Anwendung zur Spezifikation von DSLs. Das Metamodell wird hierbei über eine textuelle DSL definiert; die Transformationen können mit beliebigen mit dem Eclipse Modeling Framework kompatiblen Werkzeugen durchgeführt werden. (14) 3.2 Ausgewählte Language Workbenches Bei der Auswahl der Language Workbenches, die in dieser Arbeit näher betrachtet werden, sind verschiedene Kriterien berücksichtigt worden. Zum einen sollten die drei betrachteten Anwendungen eine möglichst große Vielfalt innerhalb der in Kapitel 3.1 dargestellten Kriterien darstellen; zum anderen sollte es sich nach Möglichkeit um verbreitete und bekannte Vertreter handeln. Hierbei ist im Zweifel Open Source Anwendungen der Vorzug vor kommerziellen Vertretern gegeben worden. Neben diesen Hauptkriterien sind natürlich auch Details, wie die Qualität der Dokumentation und die Verfügbarkeit der Software, berücksichtigt worden. Die Verfügbarkeit ist bei möglichen kommerziellen Vertretern nur eingeschränkt gegeben. Auf Basis dieser Evaluation wurden die Workbenches Meta Programming System, Xtext und Generic Modeling Environment für diese Arbeit ausgewählt. Die detaillierten Informationen über diese Anwendungen können den jeweiligen Hauptkapiteln, die sich mit diesen beschäftigen, entnommen werden. 9

20 3 Language Workbenches An dieser Stelle soll nur ein kurzer Überblick über diese ausgewählten Werkzeuge und ihre Charakterisierung gegeben werden: Meta Programming System (MPS) Das Meta Programming System ist eine eigenständige Open Source Anwendung zur Definition von DSLs. Sie arbeitet rein auf dem abstrakten Syntaxbaum einer Sprache und ermöglicht jeglichen Zugriff darauf über projektionale Editoren; diese werden hierbei in Textform dargestellt. Die Definition des semantischen Modells erfolgt durch die Verwendung mehrerer DSLs, die in dieser Anwendung selbst entwickelt werden. Die Transformation zur Code-Generierung erfolgt über eine Model-to-Model-Transformation wobei das Zielmodell eine entsprechende Funktion zur Generierung von Artefakten im Dateisystem beinhalten muss. Xtext Xtext ist eine auf dem Eclipse Modeling Framework basierende (in Eclipse integrierte) Open Source Anwendung zur Definition von DSLs. Sie arbeitet über eine textuelle Sprache zur Definition der Grammatik der DSL. Diese wird im Rahmen der Generierung der Sprache in das semantische Modell umgewandelt. Die Editoren innerhalb von Xtext sind alle textbasiert; sie arbeiten über entsprechende Lexer und Parser, um das semantische Modell zu bedienen. Die Generierung erfolgt hierbei auf Template-Basis und orientiert sich am generierten semantischen Modell. Auf dieses wird bei der Generierung über automatisch bereitgestellte Klassen zugegriffen. Xtext setzt bei seiner Realisierung hierbei an zahlreichen Punkten auf bestehenden Funktionen von Eclipse auf. Generic Modeling Environment (GME) Das Generic Modeling Environment ist eine eigenständige Open Source Anwendung, welche als Vertreter für die Definition von domänenspezifischen Modellierungssprachen ausgewählt wurde. Die Definition des Metamodells erfolgt hierbei selbst innerhalb einer DSML, welche innerhalb von GME entwickelt wird. Da das semantische Modell und die späteren Sprachen modelliert werden, kommen projektionale (grafische) Editoren zum Einsatz. Der Code-Generator arbeitet hierbei auf Template-Basis; er wird als eigenständige Anwendung entwickelt, welche (über eine entsprechende Schnittstelle) Zugriff auf das Modell der DSML erhält. 3.3 Beispielhafte DSL zum Vergleich der Language Workbenches Um die Entwicklung einer DSL in den ausgewählten Language Workbenches darzustellen, sollen für alle Anwendungen dieselben Anforderungen an die zu implementierende Sprache zum Einsatz kommen. Bei dieser Sprache handelt es sich um ein einfach gehaltenes Beispiel, da hier nicht die Komplexität der DSL im Vordergrund stehen soll, sondern die anwendungsspezifische Vorgehensweise bei der Implementierung. Im Folgenden werden die Anforderungen an die zu entwickelnde DSL dargestellt. Es soll eine DSL erstellt werden, welche in der Lage ist, über einen Code-Generator eine Java-Anwendung zu generieren. Diese Java-Anwendung soll aus mehreren JFrames bestehen, von denen einige beim Start der Anwendung angezeigt werden, während andere zunächst verborgen bleiben. Jeder Frame soll dabei eine beliebige Menge der folgenden Objekte enthalten können: JLabel Es soll ein JLabel erzeugt werden können; wobei definiert werden muss, welchen Text das Label enthalten soll. JTextField Es soll ein JTextField erzeugt werden können. Diesem soll optional ein initialer Text mitgegeben werden können. JTextArea Es soll eine JTextArea erzeugt werden können. Dieser soll optional ein initialer Text mitgegeben werden können. 10

21 Language Workbenches 3 JButton mit Funktion Es soll ein JButton definiert werden können. Für diesen soll optional eine Beschriftung festgelegt werden können. Darüber hinaus soll es möglich sein, eine Listener-Klasse generieren zu lassen, welche für diesen Button registriert wird. JButton zur Navigation Es soll ein JButton definiert werden können. Für diesen soll optional eine Beschriftung festgelegt werden können. Für diesen Button soll definiert werden können, welcher der in der Anwendung vorhandenen Frames das Ziel der Navigation sein soll. In der generierten Anwendung soll dann ein Druck auf diesen Button dazu führen, dass sich der Frame, der diesen Button enthält, schließt, und stattdessen der als Ziel definierte Frame dargestellt wird. Im Folgenden wird die DSL, die diese Anforderungen umsetzt, als Java-GUI-DSL bezeichnet. 11

22 4 Meta Programming System 4 Meta Programming System Beim Meta Programming System (MPS) handelt es sich um eine komplette, eigenständige Entwicklungsumgebung für Sprachen. MPS wird von der Firma JetBrains als professionelles Open Source Projekt entwickelt, und unter der Apache License weitergegeben. JetBrains selbst ist eine Firma, die sich der Entwicklung von Werkzeugen für Software- Entwickler verschrieben hat. Eins der wohl bekanntesten Produkte aus diesem Haus ist die Java-Entwicklungsumgebung IntelliJ IDEA. (15; 16) Die Entwicklung vom MPS begann im Jahr 2003 als Forschungsprojekt; sie wurde dann weitergeführt, so dass die erste Beta-Version im Jahr 2008 der Öffentlichkeit präsentiert wurde. Zum Zeitpunkt der Erstellung dieser Arbeit lag die Anwendung MPS in der Version 2.0 (erschienen am 22. August 2011) vor. (16; 17) MPS versteht sich selbst als Werkzeug zur Umsetzung des Language Oriented Programming (LOP) und als Entwicklungsumgebung für domänenspezifische Sprachen. LOP verfolgt hierbei den Ansatz, dass keine Konzentration darauf erfolgt, wie ein Problem in die Möglichkeiten der gegebenen Programmiersprachen übertragen werden soll, sondern darauf, wie die Programmiersprache dynamisch an die Bedürfnisse der Problemstellung angepasst wird. Eben dieses Konzept wird durch MPS dahingehend unterstützt, dass Sprachen nicht nur in DSLs geschrieben, sondern auch durch andere erweitert werden können. (18) 4.1 Charakterisierung Die Anwendung MPS ist eine vollständig alleinstehende Entwicklungsumgebung. Daher ist alles innerhalb dieser Umgebung auf die Entwicklung von Sprachen, und die Entwicklung in Sprachen, ausgerichtet. Somit kommt im Falle von MPS dieselbe Entwicklungsumgebung, sowohl für die Verwendung der Sprachen durch den Endnutzer, als auch für die Entwicklung der DSLs durch den Programmierer, zum Einsatz. Im Gegensatz zu anderen Werkzeugen (wie z.b. dem in dieser Arbeit betrachteten Xtext) verzichtet MPS konsequent auf den Einsatz von Freitext. Dies hängt damit zusammen, dass stets direkt auf dem abstrakten Syntaxbaum (AST) der Sprache gearbeitet wird. Da keine Texteditoren zum Einsatz kommen, sind sowohl das Parsen der Eingabedaten, als auch das Definieren einer Grammatik, nicht erforderlich. Stattdessen werden die Struktur und die Elemente die im AST der zu definierenden DSL enthalten sind direkt festgelegt; so wird das semantische Modell der Sprache vorgegeben (vergleiche 4.2.2). Da das direkte Editieren des AST jedoch ein hinderliches Konstrukt bei der Nutzung einer Sprache wäre, wird für jedes Element nicht nur seine Struktur, sondern auch der zur Bearbeitung der Struktur erforderliche Editor definiert. Dieser fungiert als Projektion auf den AST der Anwendung, so dass über ihn ein Element sowohl angezeigt, als auch bearbeitet werden kann (siehe auch ); das Eingabemedium hierfür ist zwar Text, aber kein Freitext. Der innerhalb eines Editors erfasste Text wird direkt in einen Knoten (oder die Eigenschaft eines Knotens) im Baum der Anwendung übersetzt; so wird letztlich kein wirklicher Text verwendet. Da ohnehin eine Einschränkung durch die Strukturdefinition der Sprache hinsichtlich dessen, welche Elemente an welchen Stellen innerhalb des AST auftauchen können gegeben ist, bietet der Editor auch für selbst definierte Sprachen eine umfangreiche Unterstützung bei der automatischen Vervollständigung. Auf diese Vervollständigung wird bei der Programmierung meist zurückgegriffen sofern nicht ein tatsächlicher Text (z.b. zur Definition des Inhalts eines Strings) eingegeben wird. 12

23 Meta Programming System 4 Der Ansatz der ständigen Projektion auf den AST und die damit einhergehende Nutzung von Editoren, die speziell für die Konstrukte der Sprache definiert sind führt automatisch dazu, dass der Endnutzer einer DSL auch innerhalb von MPS arbeiten muss. Die definierten Sprachen wären nicht ohne weiteres in eine andere Entwicklungsumgebung portierbar, da diese die speziellen Projektionen auf den AST unterstützen müsste. Die Definition eigener Editoren im Zusammenspiel mit dem Verzicht auf Freitext haben dabei für den Endnutzer sowohl Vor- als auch Nachteile. Der Vorteil liegt ganz klar darin, dass es nahezu nicht möglich ist, eine syntaktische Fehleingabe innerhalb des Editors zu machen; da dieser eine solche Eingabe gar nicht akzeptieren oder sofort als fehlerhaft kennzeichnen würde. Allerdings erfordert es ein gewisses Maß an Umstellung bei der Bedienung der Editoren, da diese optisch wie Texteditoren erscheinen, aber sich nicht wie solche verhalten. Die Zielgruppe von domänenspezifischen Sprachen umfasst jedoch auch die Domänenspezialisten, die ggf. keine Vorkenntnisse in der Programmierung haben; daher ist vermutlich ohnehin eine Einarbeitung in das Werkzeug erforderlich. In diesem Falle kann es sich positiv auswirken, dass MPS ein reines Sprachentwicklungstool ist; dadurch ist es nicht mit in diesem Kontext überflüssigen Funktionen überladen, wie es eine allgemeine Entwicklungsumgebung wäre. Für die Entwicklung von Sprachen in MPS werden selbst DSLs eingesetzt. Für jeden Aspekt der Sprachdefinition existiert somit eine eigene in MPS entwickelte Sprache (siehe 4.2.2). Es werden also bereits bei der Entwicklung einer DSL mehrere von MPS mitgelieferte DSLs eingesetzt; z.b. die Structure Language zur Definition von Sprachstrukturen. Dieses Konstrukt geht soweit, dass selbst diese Sprachen zur Sprachdefinition in sich selbst implementiert ( bootstrapped ) werden (vergleiche 4.3.1). Da ohnehin alle Elemente eines Programms, das in einer in MPS definierten DSL geschrieben wurde, in Form eines AST vorliegen, erfolgt die Generierung als Model-to- Model-Transformation. Hierbei wird innerhalb des Generators definiert, in welche Elemente der Zielsprache der Quell-AST übersetzt werden soll. Sofern die Zielsprache den sogenannten TextGen-Aspekt unterstützt, können hierbei auch Textartefakte in das Dateisystem geschrieben werden (siehe auch 4.2.3). Eine mögliche Zielsprache, die von MPS mitgeliefert wird, ist hierbei die Base Language; diese ermöglicht die Generierung von Java-Code (vergleiche 4.3.2). Mehrere Generatoren können auch in eine Abhängigkeitsbeziehung zueinander gebracht werden, so dass die Generierung kaskadierend durch mehrere Model-to-Model-Transformationen erfolgt. 4.2 Allgemeine technische Realisierung Im folgenden Kapitel wird die allgemeine Realisierung von MPS betrachtet, hierzu werden zunächst die Grundbegriffe und -elemente erläutert. In den Unterkapiteln werden dann die Mittel zur Definition von Sprachen aufgeteilt nach Struktur, Editoren, Verhalten und Typsystem betrachtet. Abschließend erfolgt die Darstellung der Möglichkeiten, die bei der Implementierung eines Generators zur Verfügung stehen. Die im folgenden Kapitel dargestellten Informationen über die Grundlagen von MPS entstammen sofern nicht anders angegeben dem MPS User s Guide von JetBrains (19) Grundelemente Da MPS nicht auf Text als Medium für die Programmierung setzt sondern immer mit direkten Projektionen auf dem AST arbeitet unterscheidet es sich strukturell stark von anderen Anwendungen. Daher sollen hier zunächst die grundlegenden Elemente dargestellt werden. 13

24 4 Meta Programming System Das Basiselement jeder Definition ist der sogenannte Node. Jeder Node repräsentiert einen Knoten im AST der Anwendung. Er verfügt somit über seine eigenen Properties hinaus über verschiedene Eigenschaften, die in Relation zu den ihn umgebenden Nodes stehen. Er hat eine Menge von Child-Nodes, die unter ihm liegen; eine Menge von Nodes, auf die er selbst eine Referenz hält; und einen Parent-Node, unter dem er sich befindet. Die einzige Ausnahme hiervon bilden die Root-Nodes, die das Wurzel-Element des AST bilden, und somit über keinen Parent-Node verfügen. Da Nodes von verschiedenster Art sein können (sie repräsentieren alle Elemente im AST), referenziert jeder Node die Definition auf der er basiert; dies ist das sogenannte Concept. Ein Concept gibt die konkreten Eigenschaften vor, die ein aus ihm resultierender Node annehmen kann (z.b. Art und Menge der Child-Nodes). Um die Menge an Nodes zu verwalten werden Models eingesetzt. Diese enthalten für gewöhnlich einen Root-Node und dessen Child-Nodes; sie dienen somit als Organisationselement für die Programme in MPS. Da keinerlei Text und somit auch keine Textdateien als Ordnungskriterium einsetzt wird, wird diese Funktionalität von Models übernommen. Ein Model ist also als Konstrukt am ehesten einer Kompilierungseinheit einer gewöhnlichen Programmiersprache gleichzusetzen. Jenseits der Nodes enthält es auch noch Meta-Informationen darüber, welche anderen Models es verwendet und in welcher Sprache es geschrieben ist. Mehrere Models werden wiederum in Modules zusammengefasst. Jedes Module stellt dabei den in ihm enthaltenen Models diverse Informationen über die Umgebung zur Verfügung. Dies umfasst die referenzierten anderen Modules, sowie die Sprachen auf denen es basiert. Somit gibt es für die in ihm enthaltenen Models vor, auf welchen Sprachen diese basieren können. Innerhalb von MPS gibt es vier verschiedene Arten von Modules: Solutions Eine Solution ist die einfachste Form des Modules; es ist lediglich ein Container-Element für eine Sammlung von Models. Solutions werden zur Programmierung in einer in MPS definierten Sprache eingesetzt, und fassen alle Models die zu einem Programm gehören zusammen. Languages Ein Language-Module besteht aus einer Komposition verschiedener Models, die eine wiederverwendbare Sprache beschreiben (siehe 4.2.2). Ein Language-Module kann dabei auf einem anderen basieren, und so eine bereits definierte Sprache erweitern. Generators Generator-Modules definieren, wie eine Sprache in etwas anderes übersetzt / transformiert werden kann; z.b. in Code einer anderen Sprache (siehe 4.2.3). Auch diese können, wie Languages, aufeinander basieren. Hierbei muss jedoch der Reihenfolge der Generator-Ausführung besondere Aufmerksamkeit geschenkt werden. DevKits DevKit-Modules dienen der einfachen Handhabung verschiedener (miteinander verwobener) Sprachen, die zu einer Einheit zusammengefasst werden sollen. Hierzu kann definiert werden, welche Sprachen zu einem Verbund gehören. Spätere, auf diesem basierende Solutions, müssen dann nur noch das DevKit referenzieren und nicht mehr die komplette Liste aller beteiligten Sprachen. Auch DevKits können aufeinander basieren und sich so hierarchisch erweitern. Da diese nur eine Vereinfachung in der Handhabung darstellen, wird im Folgenden nicht weiter auf sie eingegangen. 14

25 Meta Programming System Sprachdefinition In diesem Kapitel werden die fünf Grundpfeiler der Sprachdefinition in MPS dargestellt. Diese Aspekte einer Sprache werden in den innerhalb des Language-Module vorliegenden Models definiert. Wie in Abbildung 3 zu sehen, trägt dabei das Language- Module den Namen der DSL; unterhalb dieses Modules befinden sich die einzelnen Models zur Definition der Sprachbestandteile. Abbildung 3: Aufbau eines Language-Module in MPS Bei diesen handelt es sich um das Model structure, zur Definition der möglichen Nodes innerhalb des AST der Sprache, sowie deren Beziehungen zueinander; das Model editor, welches definiert wie die Editoren zu den einzelnen Sprachelementen gestaltet sein sollen; das Model constraints, zur Festlegung welchen Beschränkungen und Regeln die Elemente der Sprache unterliegen (z.b. hinsichtlich ihrer Position im AST); das Model behavior, mit der Definition des Verhaltens des AST und seiner Methoden; und das Model typesystem, welches das der Sprache zugrundeliegende Typsystem beschreibt. Diese einzelnen Sprachaspekte werden in den folgenden Unterkapiteln näher erläutert Structure Die Struktur einer Sprache in MPS ergibt sich aus der Summe ihrer Concepts, da jedes Concept einen möglichen Node innerhalb des AST der Sprache so wie seine Beziehungen zu anderen Nodes definiert. In Abbildung 4 ist exemplarisch die Darstellung eines Concepts innerhalb seines entsprechenden Editors zu sehen. Als Beispiel wurde hier eines aus der Implementierung der Java-GUI-DSL gewählt (vergleiche ). Neben den Concepts können auch Concept Interfaces definiert werden, in denen allgemeine / übergreifende Eigenschaften für mehrere Concepts definiert werden. Die Vererbung ist hierbei analog der in Java verwendeten; jedes Concept kann ein anderes erweitern und beliebig viele Concept Interfaces implementieren, welche wiederum beliebig viele andere Interfaces erweitern können. Jedes Concept wird dabei durch die folgenden Eigenschaften beschrieben, die das Verhalten des späteren Nodes vorgeben: Instance can be root Definiert als booleschen Ausdruck, ob das definierte Concept innerhalb des AST (bzw. des Models in dem es enthalten ist) als Root-Node fungieren kann. Properties Hierbei handelt es sich um die Attribute des Concepts; diese sind einfache Elemente denen ein Typ zugewiesen werden kann, z.b. String oder Integer. Auch selbstdefinierte Typen können hier als Typ der Property herangezogen werden. Children Die Children definieren, welche anderen Concepts als Nodes unterhalb eines Nodes dieses Concepts auftreten dürfen. Hierzu wird nicht nur das Concept, welches als Child auftreten kann, definiert, sondern auch die Kardinalität in welcher diese auftreten können. Die möglichen Kardinalitäten hierbei sind: 0..1 ein oder kein Mal; 0..n beliebig oft; 1 exakt ein Mal; und 1..n ein Mal bis beliebig oft. 15

26 4 Meta Programming System References Neben den Children, welche in einer hierarchischen Beziehung zum Concept stehen, kann es auch Referenzen auf andere Concepts enthalten. Diese enthalten ebenfalls eine Kardinalität, in welcher die Referenz vorliegt; hier sind jedoch nur die Kardinalitäten 1 und 0..1 möglich. Eine Referenz kann also optional sein, oder eine Pflichtangabe. Concept Properties Diese Properties geben allgemeine Charakteristika des Concepts an, wie etwa ob das Concept abstract oder final deklariert ist. Abbildung 4: Beispiel eines MPS-Concept anhand des Frame-Concept der Java-GUI-DSL Neben diesen Node-spezifischen Attributen existieren noch Concept-weite Properties; diese verhalten sich ähnlich wie als static deklarierte Felder innerhalb von Java. Der Wert einer Concept-weiten Property ist also in allen Nodes dieses Concepts immer gleich, egal an welchem Node des Concepts die Definition des Werts erfolgt ist Editor Da MPS zur Gänze auf Texteditoren verzichtet es aber für den Endnutzer nicht intuitiv und praktikabel ist direkt den AST zu editieren ist die Definition von Editoren ein essentieller Bestandteil der Entwicklung einer Sprache in MPS. Für jedes in der Sprachdefinition enthaltene Concept kann ein Editor definiert werden. Dieser fungiert gleichzeitig als Sicht zur Anzeige des Nodes und als eigentlicher Editor zur Veränderung des selbigen. Es ist jedoch auch möglich ein Concept ohne Editor zu definieren. Für dieses wird dann der in der Vererbung am nächsten liegende Editor verwendet. Auf ihn verzichtet werden kann z.b. bei der Deklaration eines abstrakten Concepts. Entweder es wird auf den Editor, des als abstrakt deklarierten Concepts verzichtet, oder auf den eines (oder mehrerer) Subtypen. Ein Editor besteht immer aus einer Menge an Zellen, die verschiedenste Werte annehmen können. Die Definition eines Editors erfolgt also durch die Summe der Zellen, die er enthält. Die Darstellung dieser Verfahrensweise kann auch in Abbildung 5 nachvollzogen werden., Hier ist der Editor eines Concepts der Java-GUI-DSL (vergleiche ) zu 16

27 Meta Programming System 4 sehen. Die einzelnen Elemente befinden sich innerhalb von Zellen, welche vorgeben, in welcher Folge diese auftreten können. Die Zellen selbst können dabei auf verschiedenen Cell-Models basieren und somit ein verschiedenes Verhalten an den Tag legen. Wenn wiederkehrende Bestandteile in verschiedenen Editoren verwendet werden, können diese auch als sogenannte Editor Components zu abstrakten Editor-Elementen zusammengeführt werden. Diese können dann aus mehreren Editoren heraus referenziert werden. Die folgenden Cell-Models sind die gebräuchlichsten innerhalb der Deklaration eines Editors: Constant cell Eine Zelle, die eine unveränderliche Textkonstante enthält. Diese dient meist zur Definition von Schlüsselwörtern, die eine Deklaration einleiten. Collection cell Eine Zelle, die eine Gruppe anderer Zellen enthält. Die Collection kann vertikal, horizontal oder mit Einrückung dargestellt werden. Property cell Eine Zelle zur Definition einer Property des Concepts. Child cell Eine Zelle, die eine Referenz auf einen Child-Node aufnimmt. Referent cell - Eine Zelle, die eine Referenz auf einen anderen Node aufnimmt. Child list cell Eine Zelle, die eine Liste von Child-Nodes aufnehmen kann, um so Kardinalitäten die größer als 1 sind abzubilden. Analog der Collection cell kann auch hier die Art der Darstellung definiert werden. Indent cell Eine Zelle zur Darstellung einer Einrückung. Abbildung 5: Beispiel eines MPS-Editors anhand des Editors des Frame-Concept der Java-GUI-DSL Neben der Festlegung was ein Editor enthalten soll, kann auch definiert werden wie die Darstellung erfolgen soll. Hierzu kommen sogenannte Styles zum Einsatz. Diese werden zu Stylesheets zusammengefasst, und entweder innerhalb eines Editors oder eigenständig, und somit wiederverwendbar deklariert. Innerhalb selbiger kann z.b. die Schriftart, -größe und -farbe definiert werden; aber auch z.b. die Einrückung und der Abstand zu den umgebenden Elementen. Als letztes Element der Editorgestaltung ist es möglich die von MPS standardmäßig auf Basis des Concepts und seiner Constraints ermittelte automatische Vervollständigung an die eigenen Bedürfnisse anzupassen. Hierzu können spezielle Editor Actions definiert werden, welche das Standardverhalten überschreiben und ergänzen Constraints In manchen Fällen ist die bloße Definition einer Struktur hinsichtlich der Regeln die ihr Verhalten definieren nicht mächtig genug. In diesem Fall ist es möglich Concepts mit definierten Constraints in ihrer Verhaltensweise einzuschränken. Constraints werden innerhalb des gleichnamigen Models der Language definiert; jedes von ihnen bezieht 17

28 4 Meta Programming System sich hierbei auf exakt ein Concept. In Abbildung 6 ist exemplarisch ein Constraint der Java-GUI-DSL zu sehen (vergleiche ). Innerhalb dessen wird eine Vorgabe dafür gemacht, wie sich das Concept in der automatischen Vervollständigung des Editors darstellen soll. Abbildung 6: Beispiel eines MPS-Constraints anhand des Constraints des NavigationButton-Concept der Java-GUI-DSL Die folgenden Einschränkungen können durch Constraints definiert werden: Can be child / parent / ancestor / root Über diese Werte kann in Form von booleschen Ausdrücken definiert werden, ob dieses Concept im AST an entsprechender Stelle innerhalb der Hierarchie auftreten darf. Property Constraints Hier kann für jede Property des Concepts eine Einschränkung / Definition des Verhaltens erfolgen. Während rein innerhalb des Concepts beschriebene Properties sich wie öffentliche Felder verhalten, kann über die Constraints eine explizite Getter- und Setter-Methode sowie eine Methode zur Prüfung der Validität des Feldinhalts definiert werden. Referent Constraints Über diese kann, für die Referenz eines Concepts auf ein anderes, ein konkretes Verhalten definiert werden. Hierbei kann angegeben werden, über welche Setter-Methode ein Setzen des Werts erfolgt, sowie mit welcher Methode eine Prüfung auf Validität der Referenz erfolgen soll. Darüber hinaus kann auch der Scope eingeschränkt werden, aus welchem die Ziel-Nodes der Referenz stammen dürfen. Zuletzt kann die textuelle Repräsentation des Zielelements in der automatischen Vervollständigung des Editors definiert werden. Default Scope Ähnlich wie bei den Referent Constraints definiert werden kann, wie der Scope für das Ziel eines Links definiert ist und wie dieses dargestellt werden soll; so kann über den Default Scope definiert werden, wie sich das Concept verhalten soll, wenn es selbst das Ziel eines Links ist. 18

29 Meta Programming System Behavior Während das Concept selbst nur definiert aus welchen Bestanteilen ein Node dieses Concepts besteht, kann über eine Behavior auch das Verhalten desselben beschrieben werden. Eine Behavior-Definition bezieht sich hierzu immer auf exakt ein Concept. Für dieses kann nun ein Konstruktor für die Instanzen des Concepts definiert werden, über welchen ein Node z.b. vordefinierte Werte für seine Properties erhalten kann. Darüber hinaus ist es sowohl möglich Methoden für die Instanzen zu definieren, als auch statische Concept-weite Methoden, die unabhängig von einzelnen Nodes agieren Typesystem Innerhalb einer Sprache in MPS ist es möglich ein eigenes komplexes Typsystem zu erstellen. Dieses gestattet entsprechende Typvergleiche innerhalb der Nodes der Sprache durchzuführen und so z.b. eine Typgleichheit auf Basis verwendeter Interfaces herzustellen. Zur Etablierung eines Typsystems kommen, unterhalb des typesystem Models, die folgenden Arten von Regeln zum Einsatz: Inference Rule Die Inference Rule ist das Grundelement des Typsystems. In dieser Regel wird für einen übergebenen Node ermittelt welchen Typ er hat, so dass weitere Funktionen basierend darauf ermöglicht werden. Inference Rules können entweder für ein bestimmtes Concept definiert werden, oder über ein Pattern. Bei Verwendung eines Patterns fallen alle Nodes aller Concepts die den Selektionskriterien des Patterns genügen unter diese Inference Rule. Subtyping Rule Über Subtyping Rules wird die Typhierarchie der Sprache definiert. Eine Subtyping Rule eines Concepts definiert hierbei, welche Typen seine Super-Typen sind. Über den Aufruf dieser Funktion kann für einen Node ermittelt werden, ob dieser in der Liste der Super-Typen eines anderen Nodes enthalten ist. Das Subtyping unterscheidet hier zwischen starken und schwachen Sub-Typen. Schwache Sub-Typen können einander z.b. bei Wertzuweisungen ersetzen. Starke Sub-Typen hingegen erben auch die etwaigen Methoden des Super-Typen. Ein starkes Subtyping schließt hierbei immer automatisch ein schwaches Subtyping ein. Ein Beispiel einer Subtyping Rule kann in Abbildung 7 eingesehen werden. Diese Regel entstammt der Java-GUI-DSL (vergleiche ) und definiert über die Rückgabe eines neuen Nodes vom Typ Element das dieser ein Super-Typ des betroffenen Concepts ist. Comparison Rule Die Gleichheit zweier Typen kann über eine Comparision Rule definiert werden. Hierbei wird festgelegt, ob sich die Typen gegenseitig ersetzen können; dies ist auch möglich, wenn sie ggf. nicht in einer Vererbungsbeziehung stehen. Ein möglicher Fall für eine solche Gleichheit wäre z.b. das Implementieren desselben Interfaces. Replacement Rule Da die Vererbungsbeziehungen zwischen Typen über Subtyping Rules definiert werden welche immer nur unidirektional aufgerufen werden können ist es nicht immer problemfrei möglich, sowohl Kovarianz als auch Kontravarianz, einer Beziehung festzustellen. In solchen Fällen kann über eine Replacement Rule die eigentliche Prüfung durch eine selbstdefinierte ersetzt werden, um so eine effiziente Ermittlung zu gewährleisten. 19

30 4 Meta Programming System Overloaded Operations Rule Über diese Regel ist es möglich die Standard- Operatoren z.b Plus (+) und Minus (-) zu überladen, und so für die eigenen Typen zugänglich zu machen. Hierzu muss in einer Overloaded Operations Rule definiert werden, welche Typen für eine Standard-Operation zulässig sind und ob diese auch durch Sub-Typen ersetzt werden können. Zusätzlich ist es erforderlich festzulegen, welche Operation zur eigentlichen Berechnung der Standard- Operation herangezogen werden soll Generatordefinition Abbildung 7: Beispiel einer MPS-Subtyping Rule anhand der Definition des Buttons der Java-GUI-DSL Die Generatoren von MPS basieren auf Model-to-Model-Transformationen. Der AST eines Programms wird hierbei in den der Zielsprache übertragen. Dies kann über multiple Schritte und Zwischenmodelle erfolgen, bis schließlich das Output-Model (als eigentliches Ziel der Transformationen) erreicht wird. Um während des Generierens auch Artefakte in Textform zu erzeugen, muss die Sprache, auf der das Output-Model basiert, den TextGen-Aspekt unterstützen. Dieser Aspekt einer Sprache definiert, wie die Elemente des Modells in Textartefakte übersetzt werden. Bei der Generierung dieser Artefakte wird jedoch nur eine destruktive Vorgehensweise unterstützt, d.h. Änderungen an zuvor generierten Artefakten werden bei einer erneuten Generierung verworfen und durch neu erzeugte Artefakte ersetzt. Prinzipiell kann jede in MPS definierte Sprache als Ziel einer Generator-Transformation eingesetzt werden. Und, sofern sie den TextGen-Aspekt unterstützt, auf dieser Basis Text generiert werden. Die Base Language von MPS selbst verfügt über diesen Aspekt; sie wird aufgrund dessen häufig als Zielsprache eingesetzt. Da die Base Language ohnehin stark an Java angelehnt ist, wird hierbei naheliegender Weise als Ausgabe Java-Code generiert. Für jede Sprache in MPS kann ein Generator erstellt werden, wobei die Erstellung mehrerer Generatoren für eine Sprache zwar technisch möglich ist, aber derzeit nicht vollumfänglich unterstützt wird. Daher werden die meisten Sprachen entweder einen oder gar keinen Generator beinhalten. Dieser wird unterhalb der Language angeordnet, beinhaltet aber im Vergleich zu den anderen Aspekten, wie etwa structure mehr als nur ein einfaches Model. Er besteht aus einer Komposition verschiedener Models, die die Elemente des Generators wie etwa die Templates beinhalten. Darüber hinaus verwaltet das Generator-Model Informationen darüber, welche Sprachen und DevKits es verwendet und welche anderen Generatoren es einbindet. Über das Referenzieren anderer Generatoren kann somit ein Geflecht aufeinander basierender Generatordefinitionen geschaffen werden. Innerhalb der Regeln kann, sowohl für die Regeln eines einzelnen, als auch generatorübergreifend, definiert werden, in welcher Priorität diese abgearbeitet werden. 20

31 Meta Programming System 4 Abbildung 8: Auszug aus der Mapping Configuration des Generators der Java-GUI-DSL Die Hauptelemente innerhalb eines Generators bilden die Mapping Configurations und die Templates. Die Templates sind in der Output-Language verfasste Models; für ihre Definition kommen dieselben Editoren zum Einsatz, wie bei der eigentlichen Entwicklung innerhalb der entsprechenden Sprache. Die Mapping Configurations definieren hierbei, welche Nodes aus dem Quell-AST, auf welche Templates gemappt werden. Ein exemplarischer Auszug aus der Mapping Configuration des Generators der Java- GUI-DSL (vergleiche ) ist in Abbildung 8 zu sehen. Innerhalb einer solchen können insgesamt die folgenden Regeln zum Einsatz kommen: Conditional root rule Definiert, ob für diese Mapping Configuration einmalig ein Root-Node im Output-Model generiert werden soll. Root mapping rule Definiert für einen Input-Node eines bestimmten Concepts, welches Template zu seiner Bearbeitung aufgerufen werden soll. Das Ergebnis erzeugt einen Root-Node im Output-Model. Weaving rule Erlaubt es am Ende der Generierung das entstandene Output- Model durch weitere Child-Nodes anzureichern. Pattern rule Definiert eine Transformation, oder ein Zieltemplate für Input- Nodes, die einem bestimmten Suchkriterium (das als Pattern definiert wird) genügen. Abandon root rule Definiert, welche Input-Nodes bei der Generierung ignoriert werden sollen, und somit nicht in eine Repräsentation im Output-Model übersetzt werden. Die folgenden Template-Arten stehen einem Generator als Ziel für die Regeln der Mapping Configuration zur Verfügung: Inline Template Es wird kein eigenes Model für die Definition des Templates verwendet, sondern der Code des Templates wird direkt in der Mapping Configuration definiert. 21

32 4 Meta Programming System Root Template Ein vollständiges Template zur Erzeugung eines Root-Nodes im Output-Model. Template Declaration Ein Template in der Output-Language, dass nicht den kompletten Umfang eines Root-Nodes abbildet, sondern nur ein Template Fragment enthält. Dieses Fragment kann mit Aufrufparametern versehen werden und dient z.b. als Ziel für Weaving und Pattern Rules. Template Switches Diese Templates definieren für eine bestimmte Code-Stelle alternative Implementierungen. Diese Switches werden innerhalb der anderen Templates eingebunden und entscheiden zur Laufzeit anhand des Typs des übergebenen Nodes welche der Code-Alternativen zum Einsatz kommt. Abbildung 9: Auszug aus dem Root Template des Frames der Java-GUI-DSL Da die in der Output-Language geschriebenen Templates zunächst nur statischen Code enthalten, muss eine Integration der im Quell-Modell enthaltenen Daten in diese ermöglicht werden. Hierzu kommen innerhalb der Templates Makros zum Einsatz. Diese werden als Annotationen zum bestehenden Template-Code, in der sog. Inspector-View (einem Kontext-Editorfenster zusätzlich zum Template-Editor), definiert. Es wird zwischen drei Hauptarten von Makros unterschieden: Property Macro Fügt den Wert einer Property des aktuell betrachteten Nodes in das Template ein. Reference Macro Erlaubt den Zugriff auf einen referenzierten Node innerhalb des Output-Models. Node Macro Ein Makro, welches immer auf Basis eines kompletten Nodes des Templates agiert und verschiedenste Funktionen zur Verfügung stellt. Über dieses Makro kann (neben vielem anderen) der Template-Node mit einem If-Statement nur konditional eingebunden werden; oder es wird über einen Loop ein Template- Node für jeden Child-Node des Quell-Nodes wiederholt. In Abbildung 9 ist ein Auszug aus einem der Root Templates der Java-GUI-DSL dargestellt. Hier kann zum einen die Implementierung der Ziel-Strukturen in Java-Code gesehen werden; zum anderen kann innerhalb dieser Übersicht zumindest nachvollzogen werden, an welchen Stellen Makros zum Einsatz kommen. Sehr offensichtlich wird hier 22

33 Meta Programming System 4 ein Node Macro (Loop) eingesetzt, während der Hinweis auf die Property und Reference Macros etwas dezenter ist. Das Vorhandensein dieser wird durch die Einfassung der entsprechenden Variablen in die Konstrukte $[] und ->$[] dargestellt. Zusammenfassend erfolgt die Model-to-Model-Transformation durch den Generator, also letztlich dadurch, dass die Nodes des Quell-Modells auf verschiedene Templates gemappt werden. Diese Templates erzeugen dann Nodes innerhalb des Ziel-Modells. Die dynamische Übernahme der Werte die durch die Quell-Nodes repräsentiert werden erfolgt hierbei durch den Einsatz der im Template definierten Makros. 4.3 Grundlegende technische Konzepte In diesem Kapitel sollen die weiteren Konzepte zur Sprachdefinition von MPS behandelt werden. Diese gehen über die im vorhergehenden Kapitel geschilderten Möglichkeiten insofern hinaus, dass diese statt die direkt zur Entwicklung von DSLs benötigten Funktionen zu betrachten den Fokus eher auf die zugrundeliegenden Techniken richten. Im Falle von MPS spielt das Bootstrapping eine zentrale Rolle, da die Entwicklungsumgebung von MPS lediglich den Rahmen zur Entwicklung von Sprachen bietet, während die eigentliche Entwicklung innerhalb von dafür definierten DSLs erfolgt. Die Anwendung setzt also massiv domänenspezifische Sprachen ein, um die Entwicklung selbiger zu ermöglichen. Darüber hinaus bietet sie viele weitere Sprachen an, die in den verschiedenen Situationen der Sprachentwicklung und -generierung zum Einsatz kommen. Somit ist die Mächtigkeit der Entwicklungsmöglichkeiten von Sprachen hier direkt abhängig von der Menge und den Möglichkeiten, die die mitgebrachten Sprachen bieten. Die eigentliche Entwicklungsumgebung stellt hierbei an sich nur das Grundgerüst zum Einsatz selbiger bereit. Die im folgenden Kapitel dargestellten Informationen über die Grundlagen von MPS entstammen sofern nicht anders angegeben dem MPS User s Guide von JetBrains (19) Bootstrapping der Sprachen zur Sprachdefinition Die unterhalb des Language-Module zu findenden Aspekte (vergleiche 4.2.2), sind selbst nur Models der von MPS definierten Sprachen. Das Erstellen der Elemente (z.b. eines Concepts) erfolgt demnach innerhalb des Editors der Sprache zur Erstellung der Struktur einer DSL. Die Sprachen die innerhalb der verschiedenen Aspekte zum Einsatz kommen sind hauptsächlich die folgenenden: Structure Language (jetbrains.mps.lang.structure) Die Sprache, die zur Definition der Concepts einer zu erstellenden DSL zum Einsatz kommt. Diese Sprache gibt die Struktur des AST der erstellten Sprache vor (vergleiche ). Editor Language (jetbrains.mps.lang.editor) Die Sprache, die zur Definition der Editoren einer zu erstellenden DSL zum Einsatz kommt. In dieser Sprache wird die Projektion der Editoren zur Anzeige und Bearbeitung des AST der erstellten Sprache festgelegt (vergleiche ). Constraints Language (jetbrains.mps.lang.constraints) Die Sprache zur Einschränkung der Struktur einer zu erstellenden DSL. Diese Sprache kann die Struktur und Ausprägung der Elemente einer Sprache weiter einschränken, falls die Mächtigkeit der Structure Language hierzu nicht ausreicht (vergleiche ). Behavior Language (jetbrains.mps.lang.behavior) Die Sprache, die zur Definition der Verhaltensweise einer zu erstellenden DSL zum Einsatz kommt. Über diese Sprache kann das Verhalten (die zur Verfügung stehenden Methoden) eines Concepts definiert werden (vergleiche ). 23

34 4 Meta Programming System Typesystem Language (jetbrains.mps.lang.typesystem) Die Sprache, die zur Definition des Typsystems einer zu erstellenden DSL zum Einsatz kommt. Über diese Sprache können die Typen der Concepts einer DSL und ihre hierarchische Beziehung zueinander definiert werden (vergleiche ). Generator Language (jetbrains.mps.lang.generator) Die Sprache, die zur Definition des Generators einer zu erstellenden DSL zum Einsatz kommt. Über diese Sprache wird definiert, welche Elemente des Quell-Models in welche Zielelemente umgewandelt werden (vergleiche 4.2.3). Die Entwicklung dieser Sprachen erfolgt hierbei im Bootstrapping-Verfahren, sprich die Sprachen werden in sich selbst (und ineinander) weiterentwickelt. Das heißt konkret, dass die mögliche Struktur der Structure Language in sich selbst entwickelt wird, während zur Entwicklung des Editors in welcher die neue Struktur der Structure Language definiert werden kann die Editor Language eingesetzt wird. Dieses Verhalten, sowie die daraus resultierenden Querbeziehungen, setzen sich auf diese Weise für alle Sprachen fort Die Base Language und ihre Erweiterungen Neben den Sprachen zur Sprachdefinition existieren in MPS noch zahlreiche weitere Sprachen. Diese kommen in Details der Aspekte oder als Ziel bei der Generierung zum Einsatz. Die wohl umfangreichste unter ihnen ist die Base Language (jetbrains.mps.baselanguage); sie ist eine nahezu vollständige Implementierung von Java innerhalb von MPS, so dass in den entsprechenden Editoren Java (als Projektion auf den AST der Base Language) programmiert werden kann. Da diese Sprache über einen TextGen-Aspekt verfügt (vergleiche 4.2.3), kann aus ihr heraus Java-Code generiert werden. Dies macht sie zur am häufigsten verwendeten Zielsprache, bei der Generator- Implementierung. Die Base Language kann, wie alle Sprachen, durch andere erweitert werden. Da sie ein zentraler Bestandteil von MPS ist, existieren zu ihr bereits diverse Erweiterungen, von denen einige hier kurz erwähnt werden sollen: Collections Language (jetbrains.mps.baselanguage.collections) Eine Sprache zur Definition von Collections. Die Grundlage dieser Sprache bildet die Sequence; auf Basis dieser werden die Konstrukte List, Set und Map bereitgestellt. Neben den eigentlichen Datentypen bringt die Sprache auch erweiterte Konstrukte mit, wie etwa die Möglichkeit auf die Collections Queries abzusetzen, um so nur bestimmte Elemente zu selektieren. Dates Language (jetbrains.mps.baselanguage.dates) Diese Sprache bringt ein erweitertes Typ- und Funktionsspektrum für die Arbeit mit Zeit und Datum mit. Es ist auf einfache Weise möglich, Zeit und Datum sowie Zeitspannen zu definieren und ineinander umzuwandeln. Closures Language (jetbrains.mps.baselanguage.closures) Eine Sprache zur Erweiterung der Base Language um das Konstrukt der Closures. Dies eröffnet die Möglichkeit funktionale Programmieraspekte einzubringen. Regular Expressions Language (jetbrains.mps.baselanguage.regexp) Eine Sprache zur Definition regulärer Ausdrücke. Diese erweitert die Base Language um die Java-seitigen Fähigkeiten Pattern zu definieren und Regular Expressions auszuführen. 24

35 Meta Programming System Implementierung der Java-GUI-DSL Zur Implementierung einer eigenen DSL in MPS wird zunächst der Dialog zur Erstellung eines neuen Projekts gestartet. Hier wird der Name des Projekts und ein Namespace definiert; dieser muss syntaktisch den Regeln eines Java-Packagenamens entsprechen. Sobald diese Schritte absolviert sind, öffnet sich die Standardansicht von MPS; in dieser sind bereits die noch leere Grundstruktur der Sprache, sowie ggf. die Solution, angelegt. Zur Entwicklung der Sprache wird zunächst damit begonnen innerhalb des Structure- Models die Struktur des AST, der späteren Sprache, in Form von Concepts zu erfassen. An diesem Punkt ist es bereits möglich die DSL zu generieren und somit in der Solution nutzbar zu machen. Während der Generierung laufen gleichzeitig verschiedenste Modellprüfungen; diese kontrollieren, ob in der definierten Sprache Fehler vorliegen. Die neue Sprache ist allerdings zu diesem Zeitpunkt noch nicht nutzbar, da zwar die Struktur vorgegeben ist, jedoch noch keine Editoren für die Erfassung der Elemente definiert wurden. Daher ist der nächste Schritt in der Spracherstellung für alle vom Endnutzer erfassbaren Elemente (abstrakte Concepts, o.ä. können hierbei ggf. vernachlässigt werden) einen Editor zu erstellen. Sind diese erfolgreich erfasst, kann nach einer erneuten Generierung die DSL auch innerhalb der Solution erstmals vollwertig verwendet werden. Abschließend werden noch das Typsystem für die enthaltenen Concepts, sowie ggf. ergänzende Constraints und Behaviors zur Verfeinerung der Sprache festgelegt. Während der Entwicklung kann die DSL (sofern diese keine Fehler enthält) natürlich jederzeit erneut generiert werden, um so die Änderungen direkt in der Solution testen zu können. Die Entwicklung aller Sprachelemente der verschiedenen Aspekte erfolgt hierbei selbst in den Editoren der MPS-eigenen Sprachen zur Sprachdefinition. Es werden also zur Entwicklung bereits die Bootstrapping-Sprachen von MPS eingesetzt (vergleiche 4.3.1). Die hier geschilderte Vorgehensweise ist natürlich nur als exemplarisches Beispiel zu verstehen. Es ist auch möglich alle Aspekte der Sprache simultan (anstatt nacheinander) zu entwickeln, und die Sprache somit (beginnend mit ihren grundlegenden Eigenschaften) sukzessive aufzubauen. Sobald alle grundlegenden Elemente und Strukturen erfasst wurden, kann mit der Definition des Generators begonnen werden. Hierzu wird innerhalb des Language-Projekts ein neuer Generator angelegt. Als Standard-Einstellung referenziert dieser die Base Language (vergleiche 4.3.2); diese kann also sofort als Zielsprache verwendet werden, so dass eine Generierung von Java-Code erfolgt. Innerhalb des Generators werden nun zunächst die benötigten Templates angelegt; jeweils eins pro zu generierender Java- Klasse (ggf. erweitert um Template Switches zur Auslagerung von Definitionen; vergleiche 4.2.3). Hier wird nun zunächst der zu generierende Java-Code programmiert. Dies erfolgt indem ein Java-Programm geschrieben wird, welches alle für die Generierung benötigten Konstrukte (in der entsprechenden Abfolge) enthält. Wurde die Definition des Java-Codes vorgenommen, so wird dieser anschließend mit Hilfe der in den Templates zur Verfügung stehenden Makros um die entsprechenden Informationen zu den Elementen der DSL angereichert. Dies geschieht z.b. indem mit Property-Makros auf Eigenschaften der zu generierenden Nodes referenziert wird, oder indem über Loop- Makros Programmelemente für alle Child-Nodes eines Elements wiederholt werden. Hierbei ist es jeweils möglich (bzw. erforderlich) die zu bearbeitenden Nodes innerhalb des Makros noch weiter einzuschränken; z.b. anhand des für die DSL definierten Typsystems. Des Weiteren ist es erforderlich für Variablendeklarationen ein Mapping vorzunehmen. Über dieses kann der für eine Deklaration generierte Variablenname dem Node (für den er generiert wurde) zugeordnet werden; im Laufe der weiteren Verarbeitung kann dieser dann, über das verwendete Mapping, wieder abgerufen werden. Wur- 25

36 4 Meta Programming System den auf diese Weise die Templates definiert, muss anschließend eine Zuordnung der Templates und Mapping Regeln in der Mapping Configuration erfolgen. Diese definiert welche Nodes der Quellsprache mit welchem Template in die Zielsprache übersetzt werden sollen. Ist die Implementierung des Generators abgeschlossen (oder zu einem fehlerfreien Zwischenstand gebracht), kann dieser einzeln oder über ein erneutes Generieren der gesamten Language neu erzeugt werden. Sobald dies erfolgt ist, kann die der DSL zugeordnete Solution ebenfalls generiert werden; hierdurch werden die entsprechenden Java-Artefakte auf Basis der Inhalte der Solution erstellt Überblick über die Implementierung Im Folgenden wird die konkrete Implementierung der Java-GUI-DSL mit den Mitteln von MPS dargestellt. Hierzu werden zunächst alle Aspekte der Sprachdefinition einzeln erläutert, und abschließend die Definition des Generators dargestellt. Der Aspekt der Behavior wird an dieser Stelle nicht erläutert, da dieses Konstrukt für die Implementierung des Beispiels nicht relevant war; daher wurden in diesem Aspekt keine Definitionen vorgenommen. Abbildung 10: Beispiel einer Programmierung innerhalb der Java-GUI-DSL in MPS In den jeweiligen Unterkapiteln erfolgt an dieser Stelle nur die Erläuterung der einzelnen, zur Erstellung der Sprache vorgenommenen Definitionen. Exemplarische Beispiele für die Repräsentation der einzelnen Elemente innerhalb ihrer Editoren sind in den Abbildungen des Kapitels 4.2 zu sehen. In Abbildung 10 wird das Ergebnis der Implementierung der Java-GUI-DSL gezeigt. Diese stellt eine Beispielimplementierung eines Frames innerhalb des dafür definierten Editors dar; hier ist auch die angebotene automatische Vervollständigung für das Einfügen eines weiteren Elements zu sehen Definitionen des Structure-Aspekts Im Folgenden werden die Concepts beschrieben, die das Grundgerüst der Sprache bilden und somit die Struktur des späteren AST vorgeben. Für gewöhnlich implementieren diejenigen von ihnen, welche einen Namen erhalten sollen, das INamedConcept- Interface. Dieses Interface lässt jedoch einen beliebigen String als Namen zu. Dieser kann auch Leerzeichen u.a. enthalten. Die Namen der Concepts werden aber zum Teil für die Definition der Namen von Java-Elementen herangezogen, daher wurde auf die Verwendung dieses Interfaces verzichtet. Stattdessen wird innerhalb der Structure der 26

37 Meta Programming System 4 Constrained String Datatype ID definiert, welcher über eine Regular Expression nur die Zeichen A-Z und Zahlen als Inhalt der ID zulässt (zu sehen in Abbildung 11). Die Concepts referenzieren dann für die Deklaration ihres Namens auf diesen Datatype. Abbildung 11: Der Constrained Datatype ID der Java-GUI-DSL Die folgenden Concepts wurden zur Abbildung der Java-GUI-DSL in MPS definiert: Frame Der Frame ist das oberste Sprachkonstrukt der DSL. Er repräsentiert einen Java-Frame in der später generierten Anwendung. Er ist das einzige Concept, welches die Option instance can be root auf true gesetzt hat; somit ist der Frame immer der Root-Node aller definierten Models. Er verfügt über die Eigenschaften name vom Typ ID und visible vom Typ boolean. Die Eigenschaft visible gibt hierbei vor, ob der Frame nach dem Start der generierten Anwendung direkt angezeigt werden soll. Darüber hinaus wird deklariert, dass der Frame-Node eine beliebige Anzahl (Kardinalität 0..n) von Child-Nodes des Concepts Element unter sich haben kann. Element Das Concept Element ist als abstract definiert und kann daher nie direkt instanziiert werden. Das Element dient in dieser Definition nur als Platzhalter für Daten der Concepts Label, TextField, TextArea und Button. Durch die Definition des abstrakten Elements welches vom Frame referenziert wird ist es möglich, eine beliebige Abfolge der oben genannten Typen zu bilden; da sie alle einen Platz in der Liste der Elemente des Frames einnehmen können. Das Element selbst definiert nur die Eigenschaft name vom Typ ID, welche es an alle Concepts, die das Element erweitern, vererbt. Label Das Concept Label erweitert das Concept Element und ergänzt es um eine Eigenschaft text vom Typ string. In dieser Eigenschaft kann der Text, der im aus dem Concept resultieren Java-Label stehen soll, hinterlegt werden. ButtonCaption Das Concept ButtonCaption beinhaltet lediglich eine Eigenschaft caption vom Typ string ; es dient dem optionalen Referenzieren einer Caption durch das Concept Button. Da Eigenschaften selbst nicht optional sein können (es wäre lediglich möglich einen leeren String anzugeben), ist die Eigenschaft caption in dieses Concept ausgelagert; so kann es von den anderen optional (Kardinalität 0..1) als Child-Node eingebunden werden. Button Analog zum Element ist der Button nur ein abstrakter Typ, der nie direkt instanziiert wird. Der Button dient hierbei als Platzhalter für die Concepts FunctionalButton und NavigationButton. Das Concept Button definiert, dass alle Concepts die es erweitern eine Eigenschaft buttoncaption vom Typ ButtonCaption erhalten. FunctionalButton Das Concept FunctionalButton definiert einen Button in der späteren Anwendung (Java-Button), welcher mit einer Funktion versehen werden kann. Er erweitert das Concept Button, wodurch er sowohl die Eigenschaft caption, als auch die Eigenschaft name (vom Concept Element ) erbt. Das Concept selbst definiert nur noch die Eigenschaft listener vom Typ boolean. Über diese kann gesteuert werden, ob für die Funktion des Buttons beim Generieren eine Listener-Klasse erzeugt (und am Button registriert) werden soll. 27

38 4 Meta Programming System NavigationButton Das Concept NavigationButton definiert einen Button in der späteren Anwendung, der zur Navigation zwischen zwei Frames verwendet wird. Hinsichtlich der gerbten Eigenschaften verhält sich dieses Concept wie der FunctionalButton. Es verfügt zusätzlich über eine Referenz auf den Ziel-Frame der Navigation. Diese Referenz namens target muss exakt einmal (Kardinalität 1) gesetzt werden. TextContent Das Concept TextContent verhält sich zu den Concepts TextField und TextArea, wie das Concept ButtonCaption zum Button. Es ermöglicht die optionale Deklaration eines Texts, der als Vorbelegung verwendet werden soll. Hierzu definiert das Concept die Eigenschaft text vom Typ string. TextField Das Concept TextField repräsentiert ein Java-Textfeld innerhalb des Frames der später generierten Anwendung. Es erweitert das Concept Element und erbt so die Definition der Eigenschaft name. Darüber hinaus deklariert es ein optionales Child vom Typ TextContent. TextArea Das Concept TextArea unterscheidet sich vom Concept TextField nur durch den Java-Typ (Java-TextArea), der für den Node in der späteren Anwendung generiert wird; ansonsten sind diese Typen identisch Definitionen des Editor-Aspekts Da das Bearbeiten der Concepts als Nodes des AST zu unintuitiv ist, wird für alle nicht abstrakten Concepts ein projektionaler Editor definiert. Die Editoren bauen dabei aufeinander auf, so dass ein Node, der ein anderes Concept als Child einbindet, innerhalb seines Editors auf den des anderen Concepts referenziert. Hierbei verwenden alle Editoren konstante Strings zur Einleitung der Definitionen. Dies ist rein technisch nicht erforderlich, da es auch möglich wäre nur eine Folge der möglichen Eigenschaften als Inhalt festzulegen (für die Projektion sind die fixen Zeichenketten unerheblich). Die Konstanten ermöglichen es aber dem Endnutzer auf einen Blick zu identifizieren, welche Elemente eine Node enthält; sie dienen also maßgeblich der Usability. Die folgenden Editoren wurden zur Abbildung der Java-GUI-DSL in MPS definiert: ButtonCaption_Editor Der Editor einer ButtonCaption definiert, dass diese mit dem Wort caption als Konstante eingeleitet wird. Darauf folgt der String, welcher im Attribut caption abgelegt wird. NavigationButton_Editor Der Editor des NavigationButton definiert, dass ein solcher über das Wort navigation eingeleitet wird. Darauf folgt (als optionales Element) der Editor der ButtonCaption. Abschließend folgt, eingeleitet vom Wort target, eine Referenz auf den Frame der das Navigations-Ziel sein soll; dieser wird hierbei über den Namen referenziert. FunctionalButton_Editor Der Editor des FunctionalButton definiert, dass ein solcher über das Wort button eingeleitet wird. Darauf folgt (als optionales Element) der Editor der ButtonCaption. Abschließend folgt, eingeleitet vom Wort createlistener, eine boolesche Angabe, ob für diesen Button eine Listener-Klasse generiert werden soll. Label_Editor Der Editor eines Labels definiert, dass dieses mit dem Wort label als Konstante eingeleitet wird und darauf die Strings folgen, welche in den Attributen name und text abgelegt werden. TextContent_Editor Der TextContent Editor definiert, dass dieser mit dem Wort initialcontent als Konstante eingeleitet wird und darauf der String folgt, welcher im Attribut text abgelegt wird. 28

39 Meta Programming System 4 TextField_Editor Der Editor des TextField definiert, dass ein solches über das Wort field eingeleitet wird. Darauf folgt der Name des TextFields als String, und abschließend (als optionales Element) der Editor des TextContent. TextArea_Editor Der Editor einer TextArea ist analog zu dem eines TextField, nur dass dieser über das Wort area eingeleitet wird. Frame_Editor Der Editor des Frames ist der komplexeste der Editoren die zum Einsatz kommen. Die Definition eines Frames wird eingeleitet durch das Wort frame, gefolgt vom Namen des Frames. In der nächsten Zeile erfolgt die Definition der Eigenschaft visible als boolescher Ausdruck, eingeleitet durch das Wort isvisibleonstartup. Abschließend folgt jeweils in einer neuen Zeile eine beliebige Anzahl von Elementen, bzw. von Concepts die das Element erweitern Definitionen des Constraints-Aspekts Innerhalb des Aspekts der Constraints wurde für die Java-GUI-DSL nur ein Constraint für das Concept NavigationButton definiert. Dieser ist erforderlich, um die Darstellung des NavigationButton innerhalb der automatischen Vervollständigung des Editors zu optimieren. Da die Referenz auf einen anderen Frame vom Editor als dominantes Merkmal dieses Concepts angenommen wird, verhält sich dieses in der Vervollständigung anders als die anderen. Für den NavigationButton wird hier eine Option je Frame der Anwendung angeboten. Durch das Auswählen des Frames wird dann automatisch ein neuer NavigationButton mit diesem als Navigationsziel angelegt. Das Standardverhalten der Darstellung führt hierbei jedoch dazu, dass nur der Typ des Ziels angezeigt wird. Stehen also mehrere Frames zur Auswahl, so wird nur mehrfach das Wort Frame in der Liste der möglichen Elemente angezeigt; daher nimmt der Constraint eine Anpassung der Darstellung dieser Referenz vor. Er definiert, dass die Repräsentation eines NavigationButton dadurch gebildet wird, dass der String Navigation to Frame mit dem Namen des Frames kombiniert wird. Das Ergebnis dieses Constraints kann auch in Abbildung 10 gesehen werden Definitionen des Typesystem-Aspekts Das Typesystem definiert, welche Typen die einzelnen Concepts innehaben, und in welcher hierarchischen Beziehung die Typen zueinander stehen. Die Definition der Typen erfolgt hierbei in den Inference Rules, deren Name mit typeof_ beginnt. Für die Implementierung der Java-GUI-DSL gibt es für jedes Concept eine solche Regel; in dieser wird definiert, dass ein Node den Typ seines Concepts hat. Neben den Inference Rules gibt es in der Beispielimplementierung noch die folgenden Subtyping Rules, die die Hierarchie der Typen definieren: Button_subtypeof_Element Das Concept Element ist der Super-Typ des Concepts Button. FunctionalButton_subtypeof_Button Das Concept Button ist der Super-Typ des Concepts FunctionalButton. Label_subtypeof_Element Das Concept Element ist der Super-Typ des Concepts Label. NavigationButton_subtypeof_Button Das Concept Button ist der Super-Typ des Concepts NavigationButton. TextArea_subtypeof_Element Das Concept Element ist der Super-Typ des Concepts TextArea. TextField_subtypeof_Element Das Concept Element ist der Super-Typ des Concepts TextField. 29

40 4 Meta Programming System Definitionen des Generators Der Generator basiert auf der Base Language von MPS; diese wird standardmäßig bei der Anlage vorgegeben. Da es sich bei der Base Language um eine Adaption von Java handelt die Java-Code als Ausgabe erzeugt ist diese Sprache die perfekte Grundlage für den Generator der Java-GUI-DSL. Dessen Definition besteht aus einer Mapping Configuration namens main, sowie drei Root Templates. Die Templates basieren auf dem Model einer Klasse der Base Language. Sie erzeugen somit im Rahmen der Generierung Java-Klassen. Die Mapping Configuration definiert hierbei zunächst die mapping labels ; diese dienen der Verknüpfung von Felddeklarationen, mit den entsprechenden Nodes für die diese vorgenommen wurden. Die Labels werden z.b. innerhalb der Deklaration von Variablen für einen Node verwendet. Da für die Variablennamen sichergestellt werden soll, dass diese einzigartig innerhalb der Klasse sind, werden diese um ein eindeutiges (zufälliges) Suffix erweitert. Damit der generierte Name zu einem späteren Zeitpunkt wieder abrufbar ist, wird dieser über das Mapping Label mit dem Node verknüpft. Für die Beispielimplementierung werden, zum eben genannten Zweck, verschiedene dieser Mapping Labels deklariert. Diese sind durch den vergebenen Typ FieldDeclaration erkennbar. Darüber hinaus werden in der Mapping Configuration noch zwei weitere Arten dieser Labels verwendet: die LocalVariableDeclaration, zum Wiederauffinden einer lokalen Variablendeklaration und die ConstructorDeclaration, zum binden einer Konstruktor-Deklaration einer Klasse an einen Node. Darauf folgt die Definition der eigentlichen Mapping Regeln. Hier wird zunächst eine Conditional Root Rule definiert; da diese always als Kondition hat, kommt diese immer einmalig im Rahmen der Generierung zum Einsatz und erzeugt eine Instanz des Templates MainStarter. Dann folgt die Deklaration zweier Root Mapping Rules, die konkrete Nodes des Quell-AST in Ziel-Templates und die daraus resultierenden Ziel-Nodes umsetzen. Zunächst wird festgelegt, dass jeder Node des Concepts Frame somit der jeweilige Root-Node eines Models über das Template FrameImpl umgesetzt werden soll. Dann folgt noch die Konvention, dass für jeden Node des Concepts FuncionalButton für den Fall, dass die Eigenschaft listener des Nodes auf true steht eine Generierung über das Template ListenerImpl erfolgen soll. Das Root Template FrameImpl ist das zentrale Template des Generators; es erzeugt, für jeden definierten Frame, eine Java-Klasse zu seiner Abbildung. Hierzu ist der gesamte Code, der in der zu generierenden Java-Klasse auftreten kann, im Template definiert. Die einzelnen Code-Bestandteile werden hierbei in entsprechende Makros eingefasst; diese bestimmen anhand der im Frame-AST vorkommenden Nodes ob die entsprechenden Code-Passagen mehrfach (oder auch gar nicht) in das erstellte Generat aufgenommen werden. Da die Base Language in der das Template verfasst ist auf Java basiert und somit mit den Konzepten von Java vertraut ist, müssen die erforderlichen Imports hierbei nicht definiert werden; diese werden vom Generator automatisch berechnet, und in die Ausgabe-Klasse eingebunden. Das Template beginnt mit der Deklaration der Klasse als Erweiterung von JFrame. Hierbei wird mittels eines Makros der Name des Frames als Klassenname gesetzt. Danach erfolgt die Deklaration der privaten Klassenvariablen; hierzu wird jeweils ein Loop über alle Elemente unterhalb des Frames durchgeführt, welcher auf die entsprechenden Typen der Elemente gefiltert ist. Auf diese Weise werden z.b. für die Deklaration der Variablen der FunctionalButtons nur Elemente von exakt diesem Typen zugelassen. Hierbei wird auch das Mapping Label definiert, welches an dieser Stelle zum Tragen kommt; es verknüpft den hier generierten Variablennamen mit dem bearbeiteten Node. Die Gene- 30

41 Meta Programming System 4 rierung der Namen erfolgt hierbei über die Hilfsfunktion unique name from, der als Eingabeparameter eine Konstante für den Feldtyp (z.b. button_ ), sowie der Name des Nodes, übergeben werden. Auf Basis dieses übergebenen Strings stellt diese sicher, dass ein eindeutiger Variablenname generiert wird. Es folgt die Definition des Konstruktors der Klasse; dieser ruft zunächst den des JFrame auf und übergibt diesem (über ein entsprechendes Makro) den Namen des Frame-Nodes. Nun erfolgt die Initialisierung des Grid-Layout, wobei die Anzahl der Spalten automatisch auf die Anzahl der im Frame enthaltenen Elemente gesetzt wird. Anschließend werden alle Variablen initialisiert. Hierzu werden zunächst alle Nodes vom Typ NavigationButton abgearbeitet; für jeden dieser Nodes wird ein neuer JButton definiert, welchem über ein Makro die definierte ButtonCaption (sofern vorhanden) übergeben wird; falls diese nicht definiert wurde, wird der Name des Buttons verwendet. Für jeden dieser Buttons wird automatisch eine neue Listener-Klasse erzeugt, welche (über entsprechende Makros) die Navigation auf den Ziel-Frame abbildet. Hier kommt das für diesen Fall definierte Mapping zum Zuge, welches den Namen des generierten Listeners mit dem Node verknüpft; der Listener wird abschließend für den erzeugten Button registriert. Es folgt die Belegung der FunctionalButtons; für diese wird zunächst, analog den NavigationButtons, ein neuer JButton angelegt. Dann wird für alle Nodes deren Eigenschaft listener auf true steht die Registrierung der Instanz der Listener-Klasse, welche durch das Template ListenerImpl generiert wurde, durchgeführt. Die nun folgenden Definitionen für Label, TextField und TextArea sind verhältnismäßig einfach. Für das Label wird ein neues JLabel erzeugt, welches als Text den am Label- Node hinterlegten Text enthält. Für Text-Area und TextField werden ebenso die Entsprechenden Java-Objekte erzeugt und, sofern ein TextContent für den Node definiert wurde, dieser als initialer Text in das erstellte Objekt eingetragen. Nach der Definition des Konstruktors werden noch für alle Variablen Getter-Funktionen generiert, damit ein Zugriff auf die entsprechenden Felder aus einem der generierten Listener heraus ermöglicht wird. Abschließend wird die Klasse um eine statische Methode getvisibleonstartup erweitert, die den Wert der für die entsprechende Eigenschaft des Frame-Nodes gesetzt wurde zurückgibt; diese Methode wird von der durch das MainStarter Template generierten Klasse verwendet. Das Root Template ListenerImpl kommt nur für die Nodes des FunctionalButton Concepts zum Einsatz, für die automatisch ein Listener generiert werden soll. Es bildet das Rohgerüst einer Listener-Klasse ab, welche dann nach der Generierung manuell erweitert werden kann. Damit diese Zugriff auf ihren Kontext erhält, wird ihr automatisch die Instanz der entsprechenden Frame-Klasse als private Variable zur Verfügung gestellt. Hierbei ist jedoch zu beachten, dass der Generator keinen Erhalt von manuellen Definitionen gewährleistet, sondern die Klassen bei jeder Generierung überschreibt. Als letztes bleibt das Root Template MainStarter, dieses wird einmalig pro Generatorlauf ausgeführt. Es basiert nicht auf den Elementen des Quell-AST und beinhaltet lediglich eine fest definierte Klasse. Diese dient als zentraler Startpunkt der Anwendung; sie ermittelt mittels Introspektion, welche der generierten Frames beim Start angezeigt werden müssen. 31

42 4 Meta Programming System 4.5 Zusammenfassung MPS setzt als alleinstehende Entwicklungsumgebung auf den Ansatz, in einer eigenen Anwendung, das optimale Umfeld für die Implementierung von Sprachen zu bieten. Hierbei setzt es auf die reine Verarbeitung des AST über projektionale Editoren. Dadurch verzichtet es auf die Definition von Grammatik und befreit sich so von vielen Konstrukten, die erforderlich sind, wenn Freitext als Eingabemedium verwendet wird. Allerdings steigt durch diese grundlegend von normaler Programmierung abweichende Herangehensweise der Einarbeitungsaufwand für traditionelle Programmierer erheblich an. Ist diese Lernkurve jedoch erst bewältigt, bietet diese Anwendung viele Funktionen zur effizienten Entwicklung von DSLs. Auch der Aspekt, dass MPS nicht nur die Erweiterung und Kombination von Sprachen unterstützt, sondern auch selbst maßgeblich einsetzt, trägt zur Fähigkeit auch komplexeste Sprachen abbilden zu können bei. Auch für den Domänenspezialisten, der der mögliche Endnutzer einer definierten DSL ist, kommt MPS als Entwicklungsumgebung zum Einsatz. Das kann zwar ebenso zu erhöhtem Einarbeitungsaufwand führen, dies kann aber durch die benutzerfreundliche Gestaltung der Editoren durch den Entwickler der Sprache kompensiert werden. Die Verwendung einer Entwicklungsumgebung für Sprachen, zur Nutzung einer DSL durch den Endnutzer, konfrontiert diesen zwar mit zahlreichen Funktionen, die für seine eigentliche Arbeit unerheblich sind; jedoch ist das Maß dieser Funktionen geringer, als es in einer vollständigen Umgebung für allgemeine Entwicklung der Fall wäre Stärken von MPS Die Stärke von MPS ist der komplette Verzicht auf Freitext und die damit verbundenen Aufwände hinsichtlich der Verarbeitung der Sprache. Da stets nur auf Basis des AST gearbeitet wird und somit alles innerhalb der Entwicklung als Modell vorliegt entfallen die Schritte des Lexen und Parsen gänzlich. Aufgrund dieser Tatsache ist es bei der Entwicklung einer DSL auch nicht erforderlich, eine Grammatik für die Sprache zu definieren; da, bereits zum Zeitpunkt der Eingabe der Daten durch den Endnutzer, entsprechende Nodes innerhalb des AST erstellt werden. Von Vorteil ist hierbei, dass die Editoren durch den Entwickler der Sprache selbst, sehr detailliert definiert werden können; so kann trotz der Tatsache, dass der Endnutzer auf einer Projektion des AST arbeitet eine gute Usability erreicht werden. Die Tatsache, dass innerhalb der Editoren unweigerlich meist über die automatische Vervollständigung gearbeitet wird, trägt hierbei dazu bei, dass Fehleingaben sehr unwahrscheinlich werden. Auch der Generator profitiert davon, dass die Eingabe-Elemente für den Generatorlauf stets schon als definierte Nodes (inklusive ihrer Eigenschaften) vorliegen; die Generierung kann somit als Model-to-Model-Transformation erfolgen. Durch die Nachimplementierung von Java (in der Base Language) ist hierbei ein sehr mächtiges Zielmodel gegeben. Dieses bringt bereits den entsprechenden TextGen-Aspekt zur Generierung tatsächlicher Java-Klassen mit. Die verschiedenen Formen von Templates sowie die Makros, welche in ihnen zu Einsatz kommen ermöglichen einen hohen Grad an Flexibilität und Effizienz bei der Generatorimplementierung. Als letztes bleibt noch positiv hervorzuheben, dass durch den Ansatz einer alleinstehenden Anwendung einzig mit dem Ziel der Entwicklung von Sprachen natürlich selbige auch optimal unterstützt werden kann. Es müssen hier keine Kompromisse durch den Einsatz einer allgemeingültigen Entwicklungsumgebung eingegangen werden. 32

43 Meta Programming System Schwächen von MPS Die Schwäche von MPS liegt ebenso wie seine Vorteile in dem Paradigma keinerlei Freitext zu verwenden, sondern stets auf Projektionen des AST zu arbeiten. Dies ermöglicht zwar eine sehr effektive Implementierung von DSLs, führt jedoch beim Anwender zu einer sehr hohen Lernkurve. Da die meisten Entwickler von Sprachen vermutlich einen Hintergrund als Programmierer haben und somit die Arbeit mit Freitext gewohnt sind ist diese neue Herangehensweise mit einer erheblichen Umstellung verbunden. Hinzu kommt, dass die vielen verschiedenen Möglichkeiten innerhalb der Anwendung zwar eine effiziente Entwicklung einer DSL ermöglichen, dies aber erfordert, sich zunächst in alle zur Verfügung stehenden Möglichkeiten intensiv einzuarbeiten. Auch besteht gerade bei der betrachteten Zielgruppe der Entwickler gegebenenfalls bereits eine Präferenz hinsichtlich einer zu verwendenden Entwicklungsumgebung; diese kann jedoch, da MPS eine alleinstehende Anwendung ist, nicht erfüllt werden. Dieser Nachteil wird jedoch dadurch aufgewogen, dass die Zielgruppe der Endnutzer ggf. auch nicht technikaffine Domänenspezialisten beinhaltet. Diese besitzen keine solche Präferenz und können durch eine speziell auf die Sprachentwicklung ausgelegte Entwicklungsumgebung besser unterstützt werden. Als letzte Schwäche soll an dieser Stelle noch auf die Möglichkeiten der Generierung eingegangen werden. Da die Generierung als Model-to-Model-Transformation erfolgt, ist es erforderlich, dass die Sprache (in die generiert werden soll) auch als Model vorliegt. Hervorragend gegeben ist dies bereits für Java in Form der Base Language. Für andere Sprachen ist diese Unterstützung noch nicht oder nicht in dem Umfang vorhanden. Sofern also eine Zielsprache verwendet werden soll, welche nicht als Model in MPS abgebildet ist, muss diese entweder zunächst in MPS implementiert werden; oder die eigene Sprache muss über einen TextGen-Aspekt direkt zur Generierung von Artefakten im Dateisystem befähigt werden. 33

44 5 Xtext 5 Xtext Bei Xtext handelt es sich um einen Bestandteil des Eclipse Modeling Project, welches somit unter die Eclipse Public License fällt. Die Anwendung ist ein professionell entwickeltes Open Source Projekt, welches maßgeblich von der Firma itemis als Hauptentwickler und Projektleiter vorangetrieben wird. Die Firma itemis ist eins der zwölf strategischen Mitglieder der Eclipse Foundation und beschäftigt sich vornehmlich mit modellgetriebenen Methoden, Verfahren und Werkzeugen zur Automation der Softwareentwicklung. (20; 21; 22; 23) Die erste Version von Xtext wurde 2006 als Bestandteil der openarchitectureware veröffentlicht; Anfang 2008 erfolgte der Übergang in das Eclipse Modelling Project. Zum Zeitpunkt der Erstellung dieser Arbeit lag die Anwendung Xtext in der Version 2.0 (erschienen am 27. Juni 2011) vor. Xtext betrachtet sich selbst als language development framework, welches von der Implementierung von DSLs bis hin zu GPLs alles ermöglicht. Ein weiterer Anwendungsbereich ist die Nachimplementierung von Sprachen, welche bereits existieren, aber für die es keine ausgereifte Toolunterstützung gibt. Durch diese Vorgehensweise können der Sprache die Vorteile einer kompletten Editorunterstützung in Eclipse zur Verfügung gestellt werden. (22) Die generierten Compiler-Komponenten (der in Xtext definierten Sprachen) können, neben der Verwendung in Eclipse, auch in jeder anderen Java-Umgebung genutzt werden. Über die mitgelieferten DSLs und Schnittstellen (APIs) hinaus ist Xtext in hohem Maße individualisierbar / konfigurierbar; da es als technische Grundlagen das Eclipse Modeling Framework (EMF), sowie Google Guice einsetzt. Somit können alle Anwendungen, welche eine Integration in das EMF anbieten, als Erweiterung eingesetzt werden. Über Guice ist es unterdessen möglich einzelne von Xtext bereitgestellte Module durch eigene auszutauschen. Diese werden über die Dependency Injection von Guice integriert. (22) 5.1 Charakterisierung Im Gegensatz zu den anderen in dieser Arbeit vorgestellten Anwendungen, handelt es sich bei Xtext nicht um eine eigenständige Language Workbench, sondern um ein Eclipse-Plug-In. Aufgrund dieser Tatsache basieren viele seiner Funktionen auf bereits in Eclipse etablierten Frameworks, bzw. auf Funktionen von Eclipse selbst. Das letztliche Ergebnis einer DSL-Entwicklung wird wiederum auch als Eclipse-Plug-In bereitgestellt; auf diese Weise wird nicht nur ein Compiler / Code-Generator, sondern eine komplette Entwicklungsumgebung, zur Verfügung gestellt. Diese kann darüber hinaus noch an konkrete Anforderungen der speziellen DSL angepasst werden (vergleiche 5.2.4). Der Vorteil hierbei ist, dass mit einer Umgebung in Eclipse ein verbreitetes Werkzeug eingesetzt wird, das ggf. schon vielen Endnutzern der Sprache bekannt ist. Ein möglicher Nachteil könnte jedoch sein, dass dies ein Werkzeug ist, welches sich von der Komplexität her eher an eine Zielgruppe von Programmierern richtet. Eines der Ziele einer domänenspezifischen Sprache ist es jedoch, den Spezialisten einer Domäne zu ermöglichen Spezifikationen in der Sprache der Domäne zu erfassen; diese sind jedoch nicht zwingend technikaffin. Ein weiteres Alleinstellungsmerkmal von Xtext innerhalb der in dieser Arbeit betrachteten Workbenches ist der Ansatz einen Texteditor als Eingabemedium zu verwenden. Somit gibt der Endnutzer seinen in der DSL formulierten Code als Freitext ein. Er wird 34

45 Xtext 5 dabei durch automatische Vervollständigung seiner Eingaben, sowie andere Werkzeuge unterstützt (vergleiche 5.2.4); ebenso erfolgt eine Validierung seiner Eingabe anhand verschiedener Kriterien (vergleiche 5.2.3). Aber, durch die Erfassung des Codes in Form von Freitext, muss Xtext die Eingaben des Benutzers zunächst in ein semantisches Modell umwandeln; erst dann können Validierungen und Transformationen wie eine Code-Generierung durchgeführt werden. Diese Umwandlung erfolgt durch einen Lexer und einen Parser. Zunächst zerlegt der Lexer den eingegebenen Freitext (anhand bestimmter Regeln) in seine einzelnen, zusammengehörigen Bestandteile die sogenannten Tokens. Auf Basis dieser wertet dann der Parser (anhand der definierten Parser- Regeln) die Benutzereingaben aus, und übersetzt diese in das semantische Modell (vergleiche 5.2.1); zur Abbildung dieses Modells werden Modellierungskonstrukte des Eclipse Modeling Frameworks eingesetzt. Erst wenn diese Umwandlung des Freitexts in das semantische Modell erfolgreich abgeschlossen ist, können die weiteren Transformationen erfolgen; hierbei kann es sich z.b. um eine Code-Generierung handeln. Die Generatoren werden in der Sprache Xtend verfasst (siehe 5.3.4), welche speziell auf das Programmieren auf Basis von Texttemplates ausgelegt ist. Auf die Informationen des semantischen Modells kann innerhalb dieser Sprache durch Java-Klassen welche das Modell des AST abbilden zugegriffen werden. Diese Klassen werden automatisch über das Eclipse Modeling Framework generiert (siehe 5.3.4). Xtext setzt bei der Definition der in ihm entwickelten Sprachen selbst auf eine domänenspezifische Sprache. Der Entwickler definiert seine neue DSL innerhalb der Grammar Language, welche selbst eine DSL mit der Domäne der Sprachdefinition ist. Diese gibt hierbei vor, welche Konstrukte zur Definition der Sprache eingesetzt werden können. Die Konstrukte, die hierbei möglich sind, stehen dabei in direkter Abhängigkeit zu den Regeln denen Lexer und Parser folgen. 5.2 Allgemeine technische Realisierung Im folgenden Kapitel werden die zentralen Elemente von Xtext dargestellt. Zunächst folgt ein Überblick über die Grammar Language, in welcher neue DSLs definiert werden können. Dann wird der Language Generator erläutert, über den die Generierung der eigentlichen Sprache sowie das bereitstellen des Eclipse-Plug-Ins erfolgt. In den weiteren Unterkapiteln werden dann die Möglichkeiten zur Validierung des auf der DSL basierenden Codes, und die zur Individualisierung der Entwicklungsumgebung, erläutert. Die im folgenden Kapitel dargestellten Informationen über die Grundlagen von Xtext entstammen sofern nicht anders angegeben der Xtext Documentation der Eclipse Foundation (22) Die Grammar Language Die sogenannte Grammar Language ist die Sprache, in der die Syntax der DSLs programmiert wird. Bei dieser handelt es sich bereits selbst um eine domänenspezifische Sprache, die von Xtext mitgeliefert wird; die Domäne selbiger ist dementsprechend die Sprachdefinition. Innerhalb dieser wird die Syntax, welche später durch den Parser in ein semantisches Modell umgewandelt wird, definiert. Zur Definition einer DSL wird zunächst die neue Sprache mit dem Schlüsselwort grammar eingeleitet. Dies kann mit einem with -Statement erweitert werden, welches definiert, dass eine bereits bestehende Sprache durch diese neue erweitert wird. Da die in der Syntax festgelegten Elemente zur Verwendung in den Parsern in Elemente des EMF Ecore Modells umgewandelt werden, muss ein EPackage definiert werden. 35

46 5 Xtext Dieses kann entweder neu generiert werden (wie im Beispiel über das Schlüsselwort generate ), oder kann importiert werden; alternativ können sowohl Import, als auch die Generierung verwendet werden, um die Grammatik verschiedener Sprachen miteinander zu vermengen ( Grammar Mixing ). Im Falle einer Generierung des EPackage wird durch das generate -Statement ein leeres EPackage erzeugt. Dieses wird dann im Rahmen der Verarbeitung mit Klassen (EClass / EObject), Datentypen (EDataType) und Enumerationen (EEnum) gefüllt, die sich aus den verschiedenen Parser-Regeln (siehe unten) der definierten Grammatik ergeben. Eine Klasse wird hierbei durch ihre Attribute (EAttribute) und ihre Referenzen auf andere Elemente (EReference) detailliert. grammar blume.masterarbeit.javaguidsl with org.eclipse.xtext.common.terminals generate javaguidsl Frame: frame name=id isvisibleonstartup visible=( true false ) elemements+=element*; Element: Label TextField TextArea Button; Label: ; label name=id text=string TextField: field name=id ( initialcontent text=string)? ; TextArea: area name=id ( initialcontent text=string)? ; Button: ; FunctionalButton NavigationButton FunctionalButton: button name=id ( caption caption=string)? createlistener listener=( true false ) ; NavigationButton: navigation name=id ( caption caption=string)? target target=[frame] ; Programmcode 1: Beispiel einer Sprachsyntax in Xtext anhand der Java-GUI-DSL Die Grundlage einer DSL-Definition in der Grammar Language bilden die Terminal Rules. Diese definieren, welche Zeichenfolgen im Rahmen des Lexing zu einzelnen Tokens zusammengefasst und weiterverarbeitet werden. Die Notation dieser Regeln erfolgt in einer an die Erweiterte Backus-Naur-Form angelehnten Schreibweise. Hierbei können alle verwendeten Ausdrücke in vier möglichen Kardinalitäten auftreten: Exakt ein Element; ein oder kein Element, angezeigt über den Operator? ; keins bis beliebig viele Elemente (Operator * ); und eins bis beliebig viele Elemente (Operator + ). Jede Regel ist dadurch gekennzeichnet, dass sie einen atomaren Rückgabewert hat, der einem EDataType entspricht (z.b. EInt für einen Integer-Wert). Sollte kein Rückgabewert angegeben sein, so wird von einer Zeichenkette (EString) ausgegangen. Die gängigsten Terminal Rules wie zum Beispiel die Regel ID zur Festlegung von Namen sind bereits 36

47 Xtext 5 in einer DSL (org.eclipse.xtext.common.terminals) zusammengefasst; sie können auf diese Weise in die eigene Sprachdefinition eingebunden werden (vergleiche with - Operator im Programmcode 1). Aber es ist darüber hinaus selbstverständlich möglich sowohl eigene Regeln zu definieren, als auch die übernommenen durch eigene zu überschreiben. Allerdings wird aufgrund der möglichen Nebeneffekte (Terminal Rules können sich gegenseitig verdecken, wenn sie nicht gänzlich disjunkt sind) von der übermäßigen Verwendung abgeraten. Es sollten (falls möglich) lieber Data Type Rules (siehe unten) eingesetzt werden, da diese in die Parsing-Phase fallen und auf Terminal Rules basieren. Zur Definition eigener Terminal Rules stehen die folgenden Ausdrücke zur Verfügung: Keyword Fest definierte Zeichenfolgen, die in der vorgegebenen Form auftreten. Character Range Beliebige Zeichen, die in den definierten Bereich fallen im Rahmen der vorgegebenen Kardinalität. Als Beispiel die Darstellung von Integer- Werten als beliebige Ziffern zwischen Null und Neun: ( )+. Wildcard Der Punkt (.) gilt innerhalb der Terminal Rules als Platzhalterzeichen. Er kann beim Lexing von einem beliebigen Zeichen ersetzt werden. Until Token Über den Operator -> kann definiert werden, dass alles was zwischen zwei definierten Token liegt als eines konsumiert wird. Als Beispiel die Darstellung eines mehrzeiligen Kommentars: /* -> */. Negated Token Alle Token können über ein Ausrufezeichen (!) negiert werden. Rule Calls Regeln können als Zusammensetzung verschiedener anderer Terminal Rules definiert werden. Alternatives Alternatives definieren mehrere Möglichkeiten, die ein Zeichen annehmen kann; z.b. zu lesen als An dieser Stelle steht entweder A oder B : ( A B ). Groups Beliebige Token lassen sich durch Notation hintereinander zu Gruppen zusammenfassen. Terminal Fragments Regeln können explizit als Fragment definiert werden. Diese Fragmente werden nicht vom Lexer verarbeitet, aber können als Teilausdrücke in der Definition von komplexen Terminal Rules eingesetzt werden. End of File Der Token EOF bezeichnet das Ende der einzulesenden Datei. Hiermit ist es z.b. möglich, von einem Token ausgehend, alles bis zum Ende der Datei in einem Token zusammenzufassen. Während die Terminal Rules definieren, welche Abschnitte innerhalb eines Textes während des Lexing zu Token zusammengefasst werden, definieren die Parser Rules wie aus der Sequenz von Tokens der Parser-Baum erstellt wird. Aus diesem ergeben sich die Strukturen, anhand derer die semantischen Modelle und somit auch die EObjects generiert werden. Während die Terminal Rules eher sparsam eingesetzt werden sollten, bilden die Parser Rules das Herzstück der Sprachdefinition; da über diese die Umwandlung der in der Grammar Language getroffenen Definitionen in Laufzeitobjekte erfolgt. Auch die Notation dieser Regeln orientiert sich an der Erweiterten Backus-Naur Form; nicht alle Terminal Rules können jedoch auch als Parser Rules eingesetzt werden. Konkret können nur die folgenden Ausdrücke als solche eingesetzt werden: Group, Alternative, Keyword und Rule Call. 37

48 5 Xtext Über die gemeinsam verwendeten Terminal Rules hinaus können die folgenden Parser Rules eingesetzt werden: Assignments Zuweisungen (wie im Beispiel name=id) weisen die Token, die durch die rechte Seite konsumiert wurden, einem Attribut des Objekts zu. Das Objekt unterhalb dessen die Zuweisung erfolgt ist erhält hierbei das entsprechende Attribut. In diesem Falle erhält das EObject welches aus der Definition des Frame resultiert ein Attribut name, welches einen String mit der definierten ID enthält. Zuweisungen können in verschiedenen Kardinalitäten erfolgen: das Gleichheitszeichen (=) definiert eine einfache Zuweisung; Plus-Gleich (+=) definiert eine Liste von Werten, die aufgenommen werden können; und Fragezeichen- Gleich (?=) definiert einen booleschen Wert, der wahr ergibt, wenn der folgende Token erfolgreich konsumiert wurde. Cross-References Es ist möglich Referenzen auf andere Objekte der Grammatik bereits zum Zeitpunkt ihrer Definition vorzusehen. Diese Referenzen werden direkt auf die für den referenzierten Typen generierte EClass bezogen. Im Beispiel enthält der Typ NavigationButton eine Referenz auf Frame (target=[frame]). Unordered Groups Eine ungeordnete Gruppe wird dadurch definiert, dass verschiedene Ausdrücke mit einem Und-Zeichen (&) verknüpft werden. Jedes Element dieser Gruppe muss nun in einer Menge, entsprechend seiner Kardinalität in dem auf der DSL basierenden Code auftauchen. Die Reihenfolge des Auftretens ist dabei jedoch gleichgültig, daher ist die Gruppe der Ausdrücke unordered. Simple Actions Über Simple Actions ist es möglich, innerhalb eines definierten Typs, weitere selbstdefinierte Typen anzusprechen. Diese müssen hierzu nicht in einem eigenen Typ explizit definiert werden. Diese Vorgehensweise erhöht die Lesbarkeit der Grammatik und zwingt den (ansonsten lazy arbeitenden) Parser das Objekt frühzeitig zu instanziieren. Assigned Actions Assigned Actions können eingesetzt werden, um die Grammatik hinsichtlich der Ergebnisse des Parsers zu optimieren. Da mit ANTLR ein LL-Parser eingesetzt wird welcher keine links-rekursiven Grammatiken unterstützt kann es bei der Definition von Parser Rules zu überflüssigen Knoten im generierten Parser-Baum kommen. Die Verwendung von Assigned Actions dient dazu, dieses Verhalten zu umgehen / zu kompensieren. Unassigned Rule Calls Ein Typ kann anstatt eine Zuweisung eines Wertes vorzunehmen eine Regel auch ohne Zuweisung einbinden. Dies ermöglicht es Abstrakte Typen zu definieren, die selbst niemals zugewiesen werden; sie fungieren lediglich als Platzhalter für andere Typen. Die Definition Abstrakt: TypA TypB;, würde z.b. niemals ein Objekt von Typ Abstrakt erzeugen. Sie erzeugt immer nur Objekte von TypA oder TypB, die den Platz von Abstrakt einnehmen. Data Type Rules Diese Regeln werden verwendet, um neue Datentypen zu definieren. Im Gegensatz zu den anderen Typ-Definitionen, die in EClass / EObject Typen umgewandelt werden, werden Datentypen in EDataTypes umgewandelt. Gegenüber der Definition einer Terminal Rule hat die Data Type Rule den Vorteil, dass die Grammatik definiert an welcher Stelle ein Objekt dieser Regel erwartet wird. So ist ein versehentliches überdecken bestehender Terminal Rules hier nicht zu erwarten. Eine Data Type Rule wird dadurch definiert, dass sie weder andere Parser Rules referenziert, noch Zuweisungen durchführt oder Actions enthält. Enum Rules Hierbei handelt es sich um eine Abwandlung der Data Type Rules, bei der eine Aufzählung definiert wird. 38

49 Xtext Der Language Generator Neben den generisch implementierten Bestandteilen, die für entwickelte DSLs in Xtext zur Verfügung gestellt werden, werden auch Teile spezifisch für die entsprechende Sprache generiert; z.b. der Parser und das entsprechende Ecore-Modell. Zum Beschreiben der zu generierenden Bestandteile, wird hierbei wiederum eine domänenspezifische Sprache eingesetzt, diese trägt den Namen Modeling Workflow Engine 2 (für nähere Informationen siehe 5.3.2). Ein Language Generator besteht aus jeweils einer Language Configuration je entwickelter DSL. Für jede Sprache müssen hierbei die folgenden Definitionen vorgegeben werden: in welcher Datei die Grammatik der Sprache zu finden ist; und welche Dateierweiterung die Dateien haben, für die diese angewandt wird. Darüber hinaus besteht die Language Configuration aus einer Menge von Generatorfragmenten, die von Xtext mitgeliefert werden und aus dieser heraus referenziert werden können. Die einzelnen Fragmente werden, ihrer Reihenfolge in der Configuration entsprechend, ausgeführt. Jedes bekommt dabei das EMF-Modell der Sprache übergeben und kann innerhalb der vorgegebenen Ausgabeverzeichnisse und -dateien Änderungen vornehmen. Es ist auch möglich eigene Generatorfragmente zu entwickeln, oder bestehende zu erweitern; dies ist jedoch in den meisten Fällen nicht erforderlich. Die initiale Language Configuration wird beim Anlegen des Xtext-Projekts in Eclipse automatisch generiert. Im Normalfall ist somit eine bereits lauffähige Version selbiger vorhanden, so dass eine Anpassung nur bei Änderungsbedarf (aufgrund besonderer Erfordernisse der DSL) erfolgen muss Validierung Xtext bietet verschiedene Möglichkeiten zur Unterstützung einer Validierung der erstellten DSL. Diese bezieht sich hierbei nicht darauf, dass der Entwickler bei der Erstellung unterstützt wird; sondern darauf, dass eine Validierung der in der erstellten Sprache geschriebenen Programme gegen die Spezifikation der DSL erfolgt. Im Wesentlichen existieren drei verschiedene Validierungsmöglichkeiten: die automatische Validierung, die benutzerdefinierte Validierung und die manuelle Validierung. In der automatischen Validierung macht sich Xtext die Tatsache zunutze, dass bestimmte Aspekte der DSL (z.b. die Grammatik) bereits konkrete Strukturen vorgeben. Gegen diese können verschiedene Prüfungen erfolgen: Syntaktische Validierung Diese erfolgt über den Lexer und Parser. Die syntaktische Korrektheit der Eingaben wird automatisch gegen die definierte DSL-Syntax geprüft. Crosslink Validierung Es erfolgt eine automatische Prüfung durch den Linker, ob die über die Cross-Reference Regel definierten Querverweise korrekt verwendet wurden und gültige Ziele aufweisen. Konkrete Syntax-Validierung In der Eclipse-Umgebung mit dem entsprechenden Xtext-Editor übernimmt der Parser diese Aufgabe. Für externe Editoren kann aber eine konkrete Syntax-Validierung über den Serializer vorgesehen werden. Hierbei können die Zusicherungen der DSL-Definition geprüft werden wie etwa die korrekte Verwendung von Typen und Subtypen, oder auch die Kardinalitäten der verwendeten Objekte. Für den Fall, dass eine automatische Validierung nicht ausreichend ist da weitere Bedingungen erfüllt werden müssen kann auch eine benutzerdefinierte Prüfung vorgesehen werden. Ein Beispiel für eine solche wäre die Bedingung, dass Typ-Namen immer mit einem Großbuschstaben definiert werden sollen. Sofern die Vergabe des 39

50 5 Xtext Namens über den vordefinierten Typ ID erfolgt, wird eine solche Prüfung nicht automatisch durchgeführt, da dieser keine Zusicherungen in dieser Hinsicht macht. Eine benutzerdefinierte Validierung kann z.b. erfolgen, indem das Generatorfragment (vergleiche 5.2.2) für den Java-Validator verwendet wird. In diesem Fall generiert der Language Generator automatisch die benötigten Java-Klassen, in denen die entsprechenden Validierungen programmiert werden können. Als letzte Form steht die manuelle Validierung zur Verfügung. Diese zielt darauf ab, dass es jederzeit möglich ist, eine Prüfung auch programmatisch anzustoßen. Auf diese Weise kann auch außerhalb der gängigen Editoren die automatisch validieren eine Validierung erzwungen werden. Diese Möglichkeit wird durch das EMF bereitgestellt, über das alle Validatoren des EMF-Modells ausgeführt werden können Anpassung der Entwicklungsumgebung Xtext stellt für die erstellten Sprachen eine komplette Entwicklungsumgebung in Eclipse bereit (incl. spezifischem Texteditor). Daher kann der Endnutzer auch alle Funktionen, die eine Eclipse-Umgebung bietet, für die Entwicklung einsetzen. Um diese Integration noch besser an die Gegebenheiten der speziellen Sprache anzupassen, stehen dem Entwickler der DSL verschiedenste Möglichkeiten zur Modifikation und Erweiterung der Entwicklungsumgebung zur Verfügung: Label Provider An verschiedensten Stellen werden Objekte der DSL in Eclipse als Icon oder mit einem definierten Bezeichner angezeigt. Über Label Provider kann für diese Situationen jeweils sowohl das anzuzeigende Icon als auch der anzuzeigende Bezeichner definiert werden. Content Assist Über den Content Assist kann definiert werden, welche Vorschläge zur automatischen Vervollständigung der Nutzer innerhalb des Texteditors erhält. Hier kann (im Maximalfall) für jede Kombination aus Element-Typ und aktuell bearbeitetem Attribut des Typs, ein unterschiedlicher Vorschlag definiert werden. Quick Fix Für die in der Validierung (siehe 5.2.3) aufgetretenen Fehler können Quick Fixes angeboten werden. Sollte einer der mit einem Quick Fix versehenen Fehler im Rahmen der Validierung auftreten, so wird der definierte Quick Fix kontextsensitiv im Eclipse-Editor zur Durchführung angeboten. Template Proposals Eclipse bietet die Möglichkeit Text-Templates für bestimmte Funktionen zu definieren, um so dem Entwickler die Eingabe bestimmter Konstrukte zu erleichtern. In Java wird z.b. der Aufbau eines Try/Catch-Blocks automatisch ergänzt, sobald der Nutzer das try eingegeben hat. Über Template Proposals können solche Templates auch für die entwickelte DSL angeboten werden. Outline View In der Outline View von Eclipse wird die aktuelle Struktur der betrachteten Datei hierarchisch angezeigt. Diese Outline View kann für die Belange der DSL entsprechend angepasst werden. Es können sowohl die angezeigten Icons und Bezeichner definiert werden (dies überschreibt die sonst verwendeten Definitionen der Label Provider) als auch Filter- und Sortiermechanismen, zur Verbesserung der Übersichtlichkeit der Outline View, angeboten werden. Darüber hinaus ist es möglich, von vorneherein bestimmte Objekte auszublenden, die aus Sicht des Entwicklers der DSL keinen Informationsvorteil für den Endnutzer bieten. 40

51 Xtext 5 Hyperlinking In Eclipse ist es möglich, über die Elemente im Quelltext, welche eine Referenz auf andere Elemente abbilden, zu ihrer Quelle / Deklaration zu navigieren. Für eine DSL ist der hier von Eclipse verwendete Algorithmus zur Ermittlung der Textstelle, innerhalb der Quelle an welche gesprungen werden soll, nicht immer korrekt / zielführend. In solchen Fällen kann ein alternativer Algorithmus zur Ermittlung der Einsprung-Stelle definiert werden. Syntax Coloring Es ist möglich eine Vorgabe dafür zu machen, wie farbliche Hervorhebungen innerhalb des Eclipse-Texteditors erfolgen sollen. Hierbei ist es möglich, einzelne Worte oder gesamte Abschnitte farblich hervorzuheben. Zur Ermittlung der Textbereiche, auf die eine Hervorhebung angewendet werden soll, stehen zwei Möglichkeiten zur Verfügung: die lexikalische und die semantische Hervorhebung. Die lexikalische Hervorhebung wird nach jedem Tastenanschlag geprüft und muss deshalb sehr performant sein. Daher eignet sie sich für alle Bereiche, die sehr schnell ermittelt werden können. Die semantische Hervorhebung läuft asynchron im Hintergrund. Sie kann daher für komplizierte Hervorhebungen eingesetzt werden, die dem Nutzer dann verzögert angezeigt werden. 5.3 Grundlegende technische Konzepte In diesem Kapitel sollen die grundlegenden Konzepte von Xtext behandelt werden. Hierzu werden zunächst die Fähigkeiten von Xtext in Bezug auf sein Bootstrapping der Grammar Language betrachtet; dann wird der Fokus auf die Frameworks gerichtet, welche als Basis zur Realisierung der Funktionen eingesetzt werden. Da Xtext selbst keine alleinstehende Anwendung ist, die alle Funktionalitäten selbst implementiert, handelt es sich bei diesen Frameworks um bereits bestehende Anwendungen. Als Bestandteil des Eclipse Modeling Frameworks und aufgrund seiner allgemeinen Integration in Eclipse profitiert Xtext an vielen Stellen von solchen Basis-Technologien. In diesem Kapitel wurden hierbei drei Komponenten für eine nähere Betrachtung ausgewählt. Die Modeling Workflow Engine 2, welche als Framework zur Generierung der DSL eingesetzt wird; die vor allem für die Code-Generatoren eingesetzte Sprache Xtend; und die allgemeine Integration in das Eclipse Modeling Framework, welche die Basis für die Verwaltung und Transformation der Parser-Ergebnisse bietet. Die im folgenden Kapitel dargestellten Informationen über die Grundlagen von Xtext entstammen sofern nicht anders angegeben der Xtext Documentation der Eclipse Foundation (22) Bootstrapping der Grammar Language Die für eine Sprache in Xtext definierte Grammatik, wird selbst in einer domänenspezifischen Sprache entwickelt. Bei dieser handelt es sich um die Xtext-eigene Grammar Language (siehe auch 5.2.1). Diese hat zur Aufgabe, die Grammatik für die Definition einer Grammatik vorzugeben. Die Konventionen, die innerhalb dieser Sprache gelten, gehen hierbei Hand in Hand mit den Generatoren, welche aus den in der Sprache formulierten Konstrukten das semantische Modell der Sprache erstellen. Die Grammar Language selbst wird hierbei im Bootstrapping-Verfahren in sich selbst entwickelt. Demnach stehen für die Entwicklung dieser auch dieselben Konstrukte zur Verfügung, wie dem Entwickler einer später darauf basierenden DSL. Die Grammar Language nutzt hierzu als Basis die Common-Terminals-DSL welche auch von neu angelegten Sprachen standardmäßig referenziert wird um deren Konstrukte in Bezug auf die Terminal Rules zu adaptieren. Hierbei ist zu beachten, dass diese Sprache natürlich wiederum eine Xtext-DSL ist, welche in der Grammar Language definiert wird. 41

52 5 Xtext Ebenso ist der Editor welcher (incl. Syntax-Highlighting, etc.) für die Entwicklung in dieser Sprache zum Einsatz kommt ein Ergebnis der gleichen Eclipse-Plug-In- Generierung, die auch für die neu entwickelten Sprachen zum Einsatz kommt. (24; 25) Die Modeling Workflow Engine 2 Bei der Modeling Workflow Engine 2 (MWE2) handelt es sich um eine abwärtskompatible Erweiterung der ursprünglichen Modeling Workflow Engine. MWE2 ist eine extern (über die entsprechende DSL) konfigurierbare Generator-Engine, welche einen definierten Workflow abarbeitet. Die Workflow-Schritte werden in der Sprache MWE2 definiert, und können EMF-Ressourcen lesen, verändern oder auf Basis der Informationen Ausgabe-Artefakte generieren. In Xtext kommt diese Engine im Rahmen des Language Generators zum Einsatz (siehe 5.2.2). MWE2 basiert darauf, einen zu erledigenden Task als Workflow von Einzelschritten abzubilden. Jeder Schritt kann hierbei von einer anderen Komponente übernommen werden. Diese werden innerhalb von MWE2 durch einfach gehaltene Plain Old Java Objects (POJOs) gebildet. Diese Unterteilung in kleine, einfache Java-Klassen als eigentliche Funktionsträger führt dazu, dass die einzelnen Komponenten schnell und effizient entwickelt werden können. Die Komplexität des Zusammenspiels dieser miteinander wird hierbei komplett in die Definition des Workflows ausgelagert. Auf diese Weise können durch simple Definitionen und verhältnismäßig simple Komponenten komplexe Abläufe gebildet werden. Die einmal implementierten Komponenten können hierbei immer wieder in neuen Workflows eingesetzt werden. Das Mapping der MWE2-Komponenten auf die konkreten POJOs, die ihre Funktionalität implementieren, erfolgt über die gängigen Sichtbarkeitsregeln von Java. Elemente innerhalb desselben Packages können über ihren Simple Name referenziert werden, während andere über ihren Fully Qualified Name angesprochen werden müssen. Für jede referenzierte Komponente wird automatisch im Rahmen des Ablaufs des Workflows eine Instanz der entsprechenden Java-Klasse erzeugt. Die Attributzuweisungen innerhalb der Komponente werden hierbei in Set-/Get-/Add-Aufrufe der Methoden der referenzierten Java-Klasse umgewandelt. Je nachdem welche Basisklassen des MWE2-Frameworks durch die POJOs erweitert werden, stehen den Java-Klassen noch diverse Service- Funktionen des Frameworks zur Verfügung; wie etwa das Speichern von Werten in einer Workflow-globalen Map. Jede MWE2-Workflowdefinition enthält exakt eine Moduldefinition. Über diesen Modulnamen kann der Workflow aus anderen Workflows heraus referenziert werden; so kann seine Funktionalität wiederverwendet werden. Nachdem das Modul definiert wurde, folgt optional eine Reihe von Import-Statements, über welche das neu definierte Model seinerseits auf andere Workflows zugreifen kann, um so deren Funktionen wiederzuverwenden. Als nächstes Element der Workflowdefinition folgen die Properties. Diese sind global definierte Variablen, die innerhalb der Definitionen aller Komponenten des Workflows eingesetzt werden können. Sie können in optionale und erforderliche Properties unterteilt werden. Wird einer Property bei ihrer Definition bereits ein Default-Wert mitgegeben, so handelt es sich um eine optionale Eigenschaft; diese kann neu gesetzt, oder auf ihrem Default-Wert belassen werden. Wird bei der Definition kein solcher Wert angegeben, so bedeutet dies, dass es sich um ein Pflichtfeld handelt. Wenn ein solches in einem Workflow vorhanden ist der von einem anderen Workflow zur Verwendung importiert wird so muss der importierende Workflow zwingend einen Wert für diese Eigenschaft vorgeben. 42

53 Xtext 5 Eine weitere Möglichkeit zur verbesserten Wiederverwendung von Workflows sind die Named Components. Es ist möglich für den Aufruf einer Komponente innerhalb eines Workflows einen expliziten Namen für diese zu vergeben. Unter diesem Namen wird die generierte Instanz gespeichert, und steht so für Zugriffe durch andere Komponenten oder Workflows zur Verfügung. Zur Vereinfachung der Einbindung von Komponenten in Workflows kann die Funktion auto-inject verwendet werden. Wenn eine eingebundene Komponente mit diesem Schlüsselwort gekennzeichnet ist, so werden automatisch alle Attribute welche denselben Namen wie eine im Workflow definierte Property tragen mit dem Wert dieser belegt. Dies erspart redundant auftretende Attributbelegungen und ermöglicht so die komfortable Verwendung mehrerer Komponenten, die umfangreiche und nahezu identische Attribute haben Xtend Xtend ist eine statisch typisierte Programmiersprache, deren Typisierung aber meist durch Typinferenz erfolgt; sie muss daher nur selten explizit deklariert werden. Die Sprache basiert auf Java; sie ist jedoch speziell darauf ausgerichtet einige Konzepte von Java zu verbessern. Zur Ausführung wird Xtend nicht direkt in Bytecode übersetzt, sondern in Java-Code; auf diese Weise sind Xtend-Programme plattformübergreifend einsetzbar. Darüber hinaus hat dies den Vorteil, dass der Programmierer nachvollziehen kann, welche Java-Konstrukte aus seiner Programmierung resultieren. Im Rahmen von Xtext kommt Xtend als Code-Generator für die implementierten DSLs zum Einsatz. def dispatch compile(navigationbutton b) ''' this.«b.name.tofirstlower» = new JButton("«b.name»"); «IF (b.caption!= null)» this.«b.name.tofirstlower».settext("«b.caption»"); «ENDIF» ActionListener «b.name.tofirstlower»listener = new ActionListener() { private «b.target.name.tofirstupper» «b.target.name.tofirstlower»; private «(b.econtainer as Frame).name.toFirstUpper» «(b.econtainer as Frame).name.toFirstLower»; public ActionListener setframe(«(b.econtainer as Frame).name.toFirstUpper» frame) { this.«(b.econtainer as Frame).name.toFirstLower» = frame; return this; } public void actionperformed(actionevent e) { if(this.«b.target.name.tofirstlower» == null) { this.«b.target.name.tofirstlower» = new «b.target.name.tofirstupper»(); } else { this.«b.target.name.tofirstlower».setvisible(true); } this.«(b.econtainer as Frame).name.toFirstLower».setVisible(false); } }.setframe(this); this.«b.name.tofirstlower».addactionlistener(«b.name.tofirstlower»listener); ''' this.add(this.«b.name.tofirstlower»); Programmcode 2: Beispiel der Sprache Xtend als Auszug aus dem Generator der Java-GUI-DSL 43

54 5 Xtext Im Folgenden werden nur die Konstrukte von Xtend dargestellt, welche für den Einsatz als Code-Generator von besonderem Interesse sind: Extension Methods Über Extension Methods können geschlossene Objekte (die nicht erweiterbar sind) um Methoden angereichert werden. Hierzu wird eine Klasse die die erweiterten Methoden bereitstellt definiert und als extension über eine Injection eingebunden. Die Methoden werden auf diese Weise an den Gültigkeitsbereich des erweiterten Objekts angehängt, so dass die Methode wie eine originäre Methode des erweiterten Objekts aufgerufen werden kann. Zum Mapping, welcher Typ durch eine Extension Method erweitert werden soll, wird der Übergabeparameter selbiger herangezogen; dieser ist das Ziel der Extension. Dispatch Functions Für normale Funktionen innerhalb von Xtend erfolgt eine statische Bindung anhand ihrer Übergabeparameter. Über das Schlüsselwort dispatch können jedoch verschiedene Funktionen (desselben Namens) zu einer Gruppe von Dispatch Functions zusammengefasst werden. Innerhalb dieser überladenen Funktionen wird anhand des Typs aller Übergabeparameter zur Laufzeit entschieden, welche von ihnen aufgerufen wird. Create Functions Create Functions adressieren die Probleme, die bei Graphen- Transformationen auftreten. Bei dieser Art von Transformationen muss für gewöhnlich in zwei Schritten vorgegangen werden: zunächst werden alle Objekte als Kopie für den neuen Graph erstellt; dann werden die Verknüpfungen zwischen den Objekten neu angelegt. Diese Vorgehensweise ist erforderlich, da ein iterieren über den Quell-Graph, mit gleichzeitigem Anlegen aller referenzierten Objekte, zu Duplikaten u.a. führt. Dies resultiert daraus, dass verschiedene Pfade zu denselben Objekten führen. In Create Functions wird zu diesem Zweck sowohl eine Funktion zum Anlegen neuer Objekte, als auch eine Funktion für die nachfolgende Initialisierung (Herstellen der Verbindungen) angegeben. Beim Anlegen der Objekte wird nun durch Xtend automatisch eine Factory eingesetzt, die alle bereits neu angelegten Objekte in einem Cache hält. Diese Factory gibt ggf. (statt einem neuen Objekt) ein bereits im Cache befindliches Objekt zurück. Operator Overloading In Xtend ist es möglich, über entsprechende Funktions- Signaturen, jeden Operator für jeden Typ, oder jede Kombination von Typen verfügbar zu machen. Auf diese Weise können beliebige Objekte verschiedener Typen miteinander verglichen, addiert, etc. werden; solange eine entsprechende Methode für diese Operation implementiert wurde. Switch Expression Switches können in Xtend für beliebige Typen durchgeführt werden. Es kann auch auf Objekte und deren Eigenschaften ein Switch erfolgen. Darüber hinaus ist es möglich einzelne Case-Anweisungen zusätzlich mit einer Type Guard zu versehen. Die entsprechenden Ausdrücke werden nur dann ausgewertet, wenn das zu switchende Objekt dem in der Guard angegebenen Typ entspricht. Rich Strings Eine der Hauptaufgaben im Rahmen der Code-Generierung ist das zusammensetzen langer Strings. Um diese Aufgabe möglichst einfach zu gestalten und den Code möglichst lesbar zu erhalten können in Xtend Rich Strings eingesetzt werden. Diese werden innerhalb des Codes durch drei einfache Anführungszeichen geöffnet und beendet ( ). Innerhalb dieses Template-Textes kann direkt auf Attribute der Objekte zugegriffen werden. Ebenso ist es möglich auf andere (selbstdefinierte) Funktionen und bestimmte Standard-Funktionen wie IF oder FOR zuzugreifen. Um einen derartigen Funktionsaufruf (oder auch einen Block von Funktionen) vom Template abzugrenzen, werden die Aufrufe in die Zeichen «und» eingefasst; alles innerhalb dieser Begrenzung wird als Code ausge- 44

55 Xtext 5 führt. Eine besondere Beachtung innerhalb der Rich Strings findet die Behandlung von Leerzeichen. Hierbei werden die Leerzeichen nicht eins zu eins aus dem Template in den generierten Code übernommen, sondern in ihrem Kontext interpretiert. Sollte ein Rich String als Bestandteil eines anderen Strings auftreten, so erhält er automatisch dieselbe Einrückung wie sein Aufrufer. Wenn eine Template- Zeile innerhalb eines Funktionsaufrufs eingerückt wird (z.b. innerhalb des Ausdrucks «FOR» ), so wird diese zusätzliche Einrückungsstufe nicht in die Ausgabe übernommen; da diese Einrückung nicht relativ zu einem String-Bestandteil erfolgt ist. Ebenso werden Zeilen, die nur derartige Funktionsaufrufe enthalten, in der Ausgabe vollständig unterdrückt. Auf diese Weise wird sowohl lesbar eingerückter Code innerhalb der Rich Strings, als auch innerhalb der generierten Ausgabe, erzeugt. In Programmcode 2 ist eine Dispatch Function des Generators der Java-GUI-DSL dargestellt, welche Rich Strings einsetzt. Hier ist auch die Verwendung von Funktionen innerhalb der Strings ersichtlich. Die eigentlichen String- Bestandteile sind in der Darstellung grau unterlegt, so dass auch die spätere Einrückung in der Ausgabe ersichtlich wird. Diese Hervorhebung ist nicht nachträglich zur besseren Darstellung eingebracht worden, sondern ist eine Standard- Funktion des Editors von Xtend. Der Programmierer hat somit schon während der Entwicklung einen guten Überblick über das Ergebnis der späteren Generierung Integration in das Eclipse Modeling Framework Im Rahmen des Parsens jeglicher Textdateien, erstellt Xtext zur Laufzeit im Hintergrund einen abstrakten Syntaxbaum (AST); auf diesem erfolgen alle weiteren Analysen und Transformationen. Abgebildet wird er in einem Modell des Eclipse Modeling Frameworks, wodurch dieses zu einem zentralen Element von Xtext wird. Die Modelle innerhalb des EMF werden in Ecore definiert. Die Vorgehensweise von Xtext ist hierbei, dass für die Grammatik einer DSL zunächst ein eigenes Metamodell generiert wird; dieses definiert, welche Konstrukte innerhalb eines AST der Sprache auftreten können. Dann wird zur Laufzeit der abstrakte Syntaxbaum der verarbeiteten Eingabedatei auf Basis dieses Modells im Speicher gebildet; somit ist dieser eine Instanz des Metamodells der domänenspezifischen Sprache. Von der Hierarchie her betrachtet ist es also so, dass das Metamodell der Sprache auf dem Ecore Modell von EMF basiert; während das Modell des AST einer konkreten Datei wiederum auf dem Metamodell der DSL basiert. Zur Verdeutlichung, welche Konstrukte von Ecore eingesetzt werden um das Metamodell und den späteren AST zu generieren (vergleiche auch 5.2.1), sind in Abbildung 12 die wichtigsten Elemente von Ecore dargestellt. Das Kernelement eines Modells ist das EPackage, welches den Namensraum bestimmt und die weiteren Elemente enthält. In der Grammatik definierte Typen (z.b. Frame ) werden als EClass abgebildet, wobei ihre Assignments in EAttributes umgesetzt werden (z.b. name=id ). Jedes dieser EAttributes hat einen bestimmten EDatatype, der seinen Wertebereich definiert; neben primitiven Java-Typen die im Ecore Modell gekapselt sind (z.b. String in EString) sind auch alle Typen, die über die Data Type Rules definiert wurden, als Datentypen verfügbar. Über die Cross-Reference Regel definierte Abhängigkeiten zwischen Typen (z.b. target=[frame] ) werden als EReference dargestellt, welche auch die definierte Kardinalität berücksichtigt. Eine EReference ist hierbei immer vom referenzierenden Typen auf den referenzierten gerichtet; eine bidirektionale Beziehung muss durch zwei gegenseitige Beziehungen die explizit als eopposite definiert sind hergestellt werden. 45

56 5 Xtext Das EMF ist auch in der Lage auf Basis eines sogenannten Generator-Modells Java- Klassen zu generieren; diese basieren auf dem Modell und sind in die Laufzeit- Bibliotheken von EMF eingebunden. Über diese generierten Java-Klassen ist es sehr komfortabel möglich (z.b. aus einem Code-Generator in Xtend heraus) auf die Eigenschaften der Modellelemente im AST zuzugreifen. In Xtext ist sowohl die Erstellung des Generator-Modells, als auch die Generierung der Java-Klassen, automatisch in DSL eingebunden. Abbildung 12: Die wichtigsten Ecore Konzepte (22) 5.4 Implementierung der Java-GUI-DSL Zur Entwicklung einer eigenen DSL in Xtext wird zunächst der Project Wizard für neue Xtext Projekte verwendet. Dieser sorgt dafür, dass alle benötigten Projektstrukturen angelegt werden. Auf Basis der im Wizard gemachten Eingaben wie dem Namen der DSL und der gewünschten Dateiendung für Dateien, die auf dieser DSL basieren erzeugt dieser auch initiale Versionen aller benötigten Konfigurationsdateien; wie etwa die Language Configuration (siehe 5.2.2) für die neu erstellte Sprache. Für eine gewöhnliche DSL (ohne besondere Anforderungen an die Konfiguration) wie sie hier im Beispiel verwendet wird ist diese initial generierte Konfiguration bereits vollkommen ausreichend; sie bedarf keiner weiteren Anpassung. Der Project Wizard legt insgesamt drei Projekte an: ein Projekt mit dem Namen der DSL, in welchem die eigentliche Definition der Sprache und ihrer Generatoren erfolgt; ein Projekt mit dem Suffix tests, in dem automatisierte Testfälle erfasst werden können; und ein Projekt mit dem Suffix ui, über welches ein Eclipse-Plug-In erzeugt werden kann. Über dieses UI-Projekt wird letztlich das Plug-In für die DSL-spezifische Entwicklungsumgebung generiert. Innerhalb des eigentlichen DSL-Projekts sind neben der Vielzahl an generierten Dateien, die als Konfigurationsdateien oder Erweiterungspunkte zu verstehen sind vor allem zwei Dateien von zentraler Bedeutung. In der Datei <DSL-Name>.xtext im 46

Language Workbench. Aktuelle Themen der Softwaretechnologie. Vortrag von: Arthur Rehm Steven Cardoso. Betreut von: Prof. Dr.

Language Workbench. Aktuelle Themen der Softwaretechnologie. Vortrag von: Arthur Rehm Steven Cardoso. Betreut von: Prof. Dr. Language Workbench Vortrag von:! Aktuelle Themen der Softwaretechnologie Arthur Rehm Steven Cardoso Betreut von: Prof. Dr. Reichenbach [1] !2 Index Kontext Domain Specific Language (DSL) Language Workbench

Mehr

Robot Karol für Delphi

Robot Karol für Delphi Robot Karol für Delphi Reinhard Nitzsche, OSZ Handel I Version 0.1 vom 24. Januar 2003 Zusammenfassung Nach der Einführung in die (variablenfreie) Programmierung mit Robot Karol von Freiberger und Krško

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Definition von domänenspezifischen Sprachen mit Xtext: Einführung. 19. November 2014

Definition von domänenspezifischen Sprachen mit Xtext: Einführung. 19. November 2014 Definition von domänenspezifischen Sprachen mit Xtext: Einführung 19. November 2014 Überblick Was ist zu tun, wenn wir selbst einen Ansatz für modellgetriebenen Entwicklung definieren wollen? Anforderungserfassung

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

Einleitung: Frontend Backend

Einleitung: Frontend Backend Die Internetseite des LSW Deutschland e.v. hat ein neues Gesicht bekommen. Ab dem 01.01.2012 ist sie in Form eines Content Management Systems (CMS) im Netz. Einleitung: Die Grundlage für die Neuprogrammierung

Mehr

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert.

Das System sollte den Benutzer immer auf dem Laufenden halten, indem es angemessenes Feedback in einer angemessenen Zeit liefert. Usability Heuristiken Karima Tefifha Proseminar: "Software Engineering Kernkonzepte: Usability" 28.06.2012 Prof. Dr. Kurt Schneider Leibniz Universität Hannover Die ProSeminar-Ausarbeitung beschäftigt

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

Arbeiten mit UMLed und Delphi

Arbeiten mit UMLed und Delphi Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Kurzfassung der Studienarbeit

Kurzfassung der Studienarbeit Kurzfassung der Studienarbeit Abteilung Informatik Namen der Studenten Roman Widmer Mikkala Pedersen Studienjahr Sommersemester 2004 Titel der Studienarbeit.NET Skript Debugger Examinator Der GUI-Builder

Mehr

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,

Mehr

Die itsystems Publishing-Lösung

Die itsystems Publishing-Lösung Die itsystems Publishing-Lösung www.itsystems.ch 1/6 Inhaltsverzeichnis 1 Publishing-Portal Funktionsübersicht... 3 1.1 Umfang des itsystems Portal... 3 1.2 Portal-Lösungsübersicht... 4 www.itsystems.ch

Mehr

Objektorientierte Programmierung für Anfänger am Beispiel PHP

Objektorientierte Programmierung für Anfänger am Beispiel PHP Objektorientierte Programmierung für Anfänger am Beispiel PHP Johannes Mittendorfer http://jmittendorfer.hostingsociety.com 19. August 2012 Abstract Dieses Dokument soll die Vorteile der objektorientierten

Mehr

Barrierefreie Webseiten erstellen mit TYPO3

Barrierefreie Webseiten erstellen mit TYPO3 Barrierefreie Webseiten erstellen mit TYPO3 Alternativtexte Für jedes Nicht-Text-Element ist ein äquivalenter Text bereitzustellen. Dies gilt insbesondere für Bilder. In der Liste der HTML 4-Attribute

Mehr

Vorgetragen von. Sanaz Mostowfi Anna Polovets Mandy Neumann

Vorgetragen von. Sanaz Mostowfi Anna Polovets Mandy Neumann Vorgetragen von Sanaz Mostowfi Anna Polovets Mandy Neumann Gliederung Was ist DSL? Welche Arten von DSL gibt es? Vor und Nachteile Werkzeuge zur Erstellung von DSLs XText Definition: DSL (Domain Specific

Mehr

10 Erweiterung und Portierung

10 Erweiterung und Portierung 10.1 Überblick In vielen Fällen werden Compiler nicht vollständig neu geschrieben, sondern von einem Rechnersystem auf ein anderes portiert. Das spart viel Arbeit, ist aber immer noch eine sehr anspruchsvolle

Mehr

Übung: Verwendung von Java-Threads

Übung: Verwendung von Java-Threads Übung: Verwendung von Java-Threads Ziel der Übung: Diese Übung dient dazu, den Umgang mit Threads in der Programmiersprache Java kennenzulernen. Ein einfaches Java-Programm, das Threads nutzt, soll zum

Mehr

1 Mathematische Grundlagen

1 Mathematische Grundlagen Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des

Mehr

SEW Übung EMFText. 1 Aufgabe. 2 Domänenbeschreibung. 3 Installation von Eclipse/EMFText. 4 Schritt-für-Schritt Anleitung. 4.

SEW Übung EMFText. 1 Aufgabe. 2 Domänenbeschreibung. 3 Installation von Eclipse/EMFText. 4 Schritt-für-Schritt Anleitung. 4. SEW Übung EMFText 1 Aufgabe Erstellen Sie eine textuelle Domänenspezifische Sprache Domain-specific Language (DSL) mit dem Werkzeug EMFText. Die Sprache soll dazu dienen Formulare (Fragen, Antworttypen

Mehr

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit

IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit IT-Governance und Social, Mobile und Cloud Computing: Ein Management Framework... Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

CSS-Grundlagen. Etwas über Browser. Kapitel. Die Vorbereitung

CSS-Grundlagen. Etwas über Browser. Kapitel. Die Vorbereitung Kapitel 1 Die Vorbereitung Vorgängerversionen. Bald darauf folgte dann schon die Version 4, die mit einer kleinen Bearbeitung bis vor Kurzem 15 Jahre unverändert gültig war. All das, was du die letzten

Mehr

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht

Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur. UML-Klassendiagramme als Werkzeug im Unterricht Dr. Hanno Schauer Mons-Tabor-Gymnasium Montabaur UML-Klassendiagramme als Werkzeug im Unterricht Blitzlicht? In welcher Programmiersprache(n) unterrichten Sie?? In welchem Umfang unterrichten Sie Objektorientierung??

Mehr

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit EMF ist ein eigenständiges Eclipse-Projekt (Eclipse Modeling Framework Project) EMF ist ein Modellierungsframework und Tool

Mehr

WhiteStarUML Tutorial

WhiteStarUML Tutorial WhiteStarUML Tutorial Autor: Simon Balázs, BME IIT, 2015. Übersetzung: Kovács Márton, 2015. Installation Herunterladen und installieren Sie das WhiteStarUML: http://sourceforge.net/projects/whitestaruml/

Mehr

Task: Nmap Skripte ausführen

Task: Nmap Skripte ausführen Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

WEBSEITEN ENTWICKELN MIT ASP.NET

WEBSEITEN ENTWICKELN MIT ASP.NET jamal BAYDAOUI WEBSEITEN ENTWICKELN MIT ASP.NET EINE EINFÜHRUNG MIT UMFANGREICHEM BEISPIELPROJEKT ALLE CODES IN VISUAL BASIC UND C# 3.2 Installation 11 Bild 3.2 Der Webplattform-Installer Bild 3.3 IDE-Startbildschirm

Mehr

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1 Kapitel 4 Die Datenbank Kuchenbestellung Seite 1 4 Die Datenbank Kuchenbestellung In diesem Kapitel werde ich die Theorie aus Kapitel 2 Die Datenbank Buchausleihe an Hand einer weiteren Datenbank Kuchenbestellung

Mehr

Erweiterung eines SMIL Players für die Darstellung von Transparenzen und SVG Inhalten

Erweiterung eines SMIL Players für die Darstellung von Transparenzen und SVG Inhalten Bachlor-Abschlussarbeit Erweiterung eines SMIL Players für die Darstellung von Transparenzen und SVG Inhalten im Studiengang Informatik der Fakultät IV - Wirtschaft und Informatik Sommersemester 2009 Burim

Mehr

Proseminar: Website-Managment-System. NetObjects Fusion. von Christoph Feller

Proseminar: Website-Managment-System. NetObjects Fusion. von Christoph Feller Proseminar: Website-Managment-System NetObjects Fusion von Christoph Feller Netobjects Fusion - Übersicht Übersicht Einleitung Die Komponenten Übersicht über die Komponenten Beschreibung der einzelnen

Mehr

Ihre Interessentendatensätze bei inobroker. 1. Interessentendatensätze

Ihre Interessentendatensätze bei inobroker. 1. Interessentendatensätze Ihre Interessentendatensätze bei inobroker Wenn Sie oder Ihre Kunden die Prozesse von inobroker nutzen, werden Interessentendatensätze erzeugt. Diese können Sie direkt über inobroker bearbeiten oder mit

Mehr

Mit der Maus im Menü links auf den Menüpunkt 'Seiten' gehen und auf 'Erstellen klicken.

Mit der Maus im Menü links auf den Menüpunkt 'Seiten' gehen und auf 'Erstellen klicken. Seite erstellen Mit der Maus im Menü links auf den Menüpunkt 'Seiten' gehen und auf 'Erstellen klicken. Es öffnet sich die Eingabe Seite um eine neue Seite zu erstellen. Seiten Titel festlegen Den neuen

Mehr

Microsoft SharePoint 2013 Designer

Microsoft SharePoint 2013 Designer Microsoft SharePoint 2013 Designer Was ist SharePoint? SharePoint Designer 2013 Vorteile SharePoint Designer Funktionen.Net 4.0 Workflow Infrastruktur Integration von Stages Visuelle Designer Copy & Paste

Mehr

teischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep

teischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep teischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep 1. Erstellen Sie ein neues Rechnungsformular Mit book n keep können Sie nun Ihre eigenen

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

crm-now/ps Webforms Webdesigner Handbuch Erste Ausgabe

crm-now/ps Webforms Webdesigner Handbuch Erste Ausgabe crm-now/ps Webforms Webdesigner Handbuch Erste Ausgabe crm-now/ps Webforms: Webdesigner Handbuch Copyright 2006 crm-now Versionsgeschichte Version 01 2006-08-21 Release Version crm-now c/o im-netz Neue

Mehr

Projektmanagement in der Spieleentwicklung

Projektmanagement in der Spieleentwicklung Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren

Mehr

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können.

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Tutorial: Wie erfasse ich einen Termin? In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Neben den allgemeinen Angaben zu einem

Mehr

Fassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing

Fassade. Objektbasiertes Strukturmuster. C. Restorff & M. Rohlfing Fassade Objektbasiertes Strukturmuster C. Restorff & M. Rohlfing Übersicht Motivation Anwendbarkeit Struktur Teilnehmer Interaktion Konsequenz Implementierung Beispiel Bekannte Verwendung Verwandte Muster

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Klassendiagramme Ein Klassendiagramm dient in der objektorientierten Softwareentwicklung zur Darstellung von Klassen und den Beziehungen,

Mehr

Visuelle DSLs Trends in der Softwaretechnik: Domänenspezifische Sprachen (Seminar WS 2010/11) Thorsten Arendt

Visuelle DSLs Trends in der Softwaretechnik: Domänenspezifische Sprachen (Seminar WS 2010/11) Thorsten Arendt Visuelle DSLs Trends in der Softwaretechnik: Domänenspezifische Sprachen (Seminar WS 2010/11) Thorsten Arendt Problemlösung = Abstrahierung Entwicklung der Programmiersprachen Maschinencode/Binärcode:

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf Softwareentwicklungspraktikum Sommersemester 2007 Feinentwurf Auftraggeber Technische Universität Braunschweig

Mehr

Beschreibung des MAP-Tools

Beschreibung des MAP-Tools 1. Funktionen des MAP-Tool 2. Aufbau des MAP-Tools 3. Arbeiten mit dem MAP-Tool Beschreibung MAP-Tool.doc Erstellt von Thomas Paral 1 Funktionen des MAP-Tool Die Hauptfunktion des MAP-Tools besteht darin,

Mehr

Content Management System mit INTREXX 2002.

Content Management System mit INTREXX 2002. Content Management System mit INTREXX 2002. Welche Vorteile hat ein CM-System mit INTREXX? Sie haben bereits INTREXX im Einsatz? Dann liegt es auf der Hand, dass Sie ein CM-System zur Pflege Ihrer Webseite,

Mehr

schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv

schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv Roboter programmieren mit NXC für Lego Mindstorms NXT 1. Auflage Roboter programmieren mit NXC für Lego Mindstorms NXT schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG mitp/bhv Verlag

Mehr

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger

Software Engineering. Sommersemester 2012, Dr. Andreas Metzger Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle

Mehr

Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz

Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz Anwendungshandbuch Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz Version: 1.0 Herausgabedatum: 31.07.2015 Ausgabedatum: 01.11.2015 Autor: DB Energie http://www.dbenergie.de Seite: 1 1.

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Vorlesung Programmieren

Vorlesung Programmieren Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

http://train-the-trainer.fh-joanneum.at IINFO Storyboard

http://train-the-trainer.fh-joanneum.at IINFO Storyboard IINFO Storyboard Allgemeine Bemerkungen und Richtlinien zur Handhabung. Das Storyboard besteht aus einem Web, d.h. einer vernetzten Struktur von HTML-Seiten welche später von den Programmieren direkt als

Mehr

IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken

IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken Version 2.0 1 Original-Application Note ads-tec GmbH IRF2000 Application Note Lösung von IP-Adresskonflikten bei zwei identischen Netzwerken Stand: 27.10.2014 ads-tec GmbH 2014 IRF2000 2 Inhaltsverzeichnis

Mehr

Handbuch Fischertechnik-Einzelteiltabelle V3.7.3

Handbuch Fischertechnik-Einzelteiltabelle V3.7.3 Handbuch Fischertechnik-Einzelteiltabelle V3.7.3 von Markus Mack Stand: Samstag, 17. April 2004 Inhaltsverzeichnis 1. Systemvorraussetzungen...3 2. Installation und Start...3 3. Anpassen der Tabelle...3

Mehr

Diese Ansicht erhalten Sie nach der erfolgreichen Anmeldung bei Wordpress.

Diese Ansicht erhalten Sie nach der erfolgreichen Anmeldung bei Wordpress. Anmeldung http://www.ihredomain.de/wp-admin Dashboard Diese Ansicht erhalten Sie nach der erfolgreichen Anmeldung bei Wordpress. Das Dashboard gibt Ihnen eine kurze Übersicht, z.b. Anzahl der Beiträge,

Mehr

Klaus Schild, XML Clearinghouse 2003. Namensräume

Klaus Schild, XML Clearinghouse 2003. Namensräume Namensräume Lernziele Namenskonflikte Warum lösen im World Wide Web einfache Präfixe dieses Problem nicht? Wie lösen globale Namensräume das Problem? Wie werden sie in XML-Dokumenten benutzt? Was sind

Mehr

PHP - Projekt Personalverwaltung. Erstellt von James Schüpbach

PHP - Projekt Personalverwaltung. Erstellt von James Schüpbach - Projekt Personalverwaltung Erstellt von Inhaltsverzeichnis 1Planung...3 1.1Datenbankstruktur...3 1.2Klassenkonzept...4 2Realisierung...5 2.1Verwendete Techniken...5 2.2Vorgehensweise...5 2.3Probleme...6

Mehr

HTML5. Wie funktioniert HTML5? Tags: Attribute:

HTML5. Wie funktioniert HTML5? Tags: Attribute: HTML5 HTML bedeutet Hypertext Markup Language und liegt aktuell in der fünften Fassung, also HTML5 vor. HTML5 ist eine Auszeichnungssprache mit der Webseiten geschrieben werden. In HTML5 wird festgelegt,

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Anforderungen an die HIS

Anforderungen an die HIS Anforderungen an die HIS Zusammengefasst aus den auf IBM Software basierenden Identity Management Projekten in NRW Michael Uebel uebel@de.ibm.com Anforderung 1 IBM Software Group / Tivoli Ein Feld zum

Mehr

Die integrierte Zeiterfassung. Das innovative Softwarekonzept

Die integrierte Zeiterfassung. Das innovative Softwarekonzept Die integrierte Zeiterfassung Das innovative Softwarekonzept projekt - ein komplexes Programm mit Zusatzmodulen, die einzeln oder in ihrer individuellen Zusammenstellung, die gesamte Abwicklung in Ihrem

Mehr

RDF und RDF Schema. Einführung in die Problematik Von HTML über XML zu RDF

RDF und RDF Schema. Einführung in die Problematik Von HTML über XML zu RDF RDF und RDF Schema Einführung in die Problematik Von HTML über XML zu RDF Kirsten Albrecht Roland Illig Probleme des HTML-basierten

Mehr

GI-Technologien zur Umsetzung der EU-Wasserrahmenrichtlinie (WRRL): Wissensbasen. Teil 1: Einführung: Wissensbasis und Ontologie.

GI-Technologien zur Umsetzung der EU-Wasserrahmenrichtlinie (WRRL): Wissensbasen. Teil 1: Einführung: Wissensbasis und Ontologie. GI-Technologien zur Umsetzung der EU-Wasserrahmenrichtlinie (WRRL): Wissensbasen Teil 1: Einführung: Wissensbasis und Ontologie Was ist eine Wissensbasis? Unterschied zur Datenbank: Datenbank: strukturiert

Mehr

Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt?

Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt? DGSV-Kongress 2009 Wann ist eine Software in Medizinprodukte- Aufbereitungsabteilungen ein Medizinprodukt? Sybille Andrée Betriebswirtin für und Sozialmanagement (FH-SRH) Prokuristin HSD Händschke Software

Mehr

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 CODESYS a trademark of 3S-Smart Software Solutions GmbH Agenda 1 Warum

Mehr

FAQ The FAQ/knowledge base. Version 2.1.1

FAQ The FAQ/knowledge base. Version 2.1.1 FAQ The FAQ/knowledge base. Version 2.1.1 (c) 2012 OTRS AG, http://otrs.org/ GNU AFFERO GENERAL PUBLIC LICENSE Version 3, November 2007 This work is copyrighted by OTRS AG, Norsk-Data-Str. 1, 61352 Bad

Mehr

Kurzanleitung zur Übermittlung der mündlichen Prüfungsergebnisse mit DSD-Online. Stand: Dezember 2006. Schulmanagement weltweit

Kurzanleitung zur Übermittlung der mündlichen Prüfungsergebnisse mit DSD-Online. Stand: Dezember 2006. Schulmanagement weltweit Kurzanleitung zur Übermittlung der mündlichen Prüfungsergebnisse mit DSD-Online Stand: Dezember 2006 Schulmanagement weltweit Einleitung Ab sofort werden die Ergebnisse der mündlichen Prüfung in DSD-Online

Mehr

Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.

Vermeiden Sie es sich bei einer deutlich erfahreneren Person dranzuhängen, Sie sind persönlich verantwortlich für Ihren Lernerfolg. 1 2 3 4 Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg. Gerade beim Einstig in der Programmierung muss kontinuierlich

Mehr

Kurzanleitung. MEYTON Aufbau einer Internetverbindung. 1 Von 11

Kurzanleitung. MEYTON Aufbau einer Internetverbindung. 1 Von 11 Kurzanleitung MEYTON Aufbau einer Internetverbindung 1 Von 11 Inhaltsverzeichnis Installation eines Internetzugangs...3 Ist mein Router bereits im MEYTON Netzwerk?...3 Start des YAST Programms...4 Auswahl

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

Mehr

Druckvorlagen Als Druckvorlagen sind dafür vorhanden:!liste1.ken (Kennzahlen)!Liste2.KEN (Kontennachweis)

Druckvorlagen Als Druckvorlagen sind dafür vorhanden:!liste1.ken (Kennzahlen)!Liste2.KEN (Kontennachweis) Kennzahlen und Kennzeichen Dieses Dokument zeigt Ihnen in wenigen kurzen Schritten die Logik und Vorgehensweise der Definition der Kennzahlen und Kennzeichen und deren Auswertung in eigens dafür vorhandenen

Mehr

SANDBOXIE konfigurieren

SANDBOXIE konfigurieren SANDBOXIE konfigurieren für Webbrowser und E-Mail-Programme Dies ist eine kurze Anleitung für die grundlegenden folgender Programme: Webbrowser: Internet Explorer, Mozilla Firefox und Opera E-Mail-Programme:

Mehr

Objektorientierte Programmierung. Kapitel 12: Interfaces

Objektorientierte Programmierung. Kapitel 12: Interfaces 12. Interfaces 1/14 Objektorientierte Programmierung Kapitel 12: Interfaces Stefan Brass Martin-Luther-Universität Halle-Wittenberg Wintersemester 2012/13 http://www.informatik.uni-halle.de/ brass/oop12/

Mehr

mysql - Clients MySQL - Abfragen eine serverbasierenden Datenbank

mysql - Clients MySQL - Abfragen eine serverbasierenden Datenbank mysql - Clients MySQL - Abfragen eine serverbasierenden Datenbank In den ersten beiden Abschnitten (rbanken1.pdf und rbanken2.pdf) haben wir uns mit am Ende mysql beschäftigt und kennengelernt, wie man

Mehr

Terminologie zwischen normativer Referenz und deskriptiver Dokumentation. Dr. Birte Lönneker-Rodman, Across Systems GmbH

Terminologie zwischen normativer Referenz und deskriptiver Dokumentation. Dr. Birte Lönneker-Rodman, Across Systems GmbH Terminologie zwischen normativer Referenz und deskriptiver Dokumentation Dr. Birte Lönneker-Rodman, Across Systems GmbH Überblick Normative Referenzterminologie - Beispiele - Unterstützende Funktionen

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Visuelles Programmieren. mit der neuen. Moskito Workbench

Visuelles Programmieren. mit der neuen. Moskito Workbench Visuelles Programmieren mit der neuen Moskito Workbench Was ist die Moskito-Workbench? Grafische Programmieroberfläche Kann auch ohne explizite Kenntnisse der Moskito-Programmiersprache genutzt werden.

Mehr

infach Geld FBV Ihr Weg zum finanzellen Erfolg Florian Mock

infach Geld FBV Ihr Weg zum finanzellen Erfolg Florian Mock infach Ihr Weg zum finanzellen Erfolg Geld Florian Mock FBV Die Grundlagen für finanziellen Erfolg Denn Sie müssten anschließend wieder vom Gehaltskonto Rückzahlungen in Höhe der Entnahmen vornehmen, um

Mehr

Was versteht man unter Softwaredokumentation?

Was versteht man unter Softwaredokumentation? Was versteht man unter? Mit bezeichnet man die Dokumentation von Computer-Software. Sie erklärt für Anwender, Benutzer und Entwickler in unterschiedlichen Rollen, wie die Software funktioniert, was sie

Mehr

MORE Profile. Pass- und Lizenzverwaltungssystem. Stand: 19.02.2014 MORE Projects GmbH

MORE Profile. Pass- und Lizenzverwaltungssystem. Stand: 19.02.2014 MORE Projects GmbH MORE Profile Pass- und Lizenzverwaltungssystem erstellt von: Thorsten Schumann erreichbar unter: thorsten.schumann@more-projects.de Stand: MORE Projects GmbH Einführung Die in More Profile integrierte

Mehr

Mediator 9 - Lernprogramm

Mediator 9 - Lernprogramm Mediator 9 - Lernprogramm Ein Lernprogramm mit Mediator erstellen Mediator 9 bietet viele Möglichkeiten, CBT-Module (Computer Based Training = Computerunterstütztes Lernen) zu erstellen, z. B. Drag & Drop

Mehr

How to do? Projekte - Zeiterfassung

How to do? Projekte - Zeiterfassung How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...

Mehr

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing.

Beschreibung und Bedienungsanleitung. Inhaltsverzeichnis: Abbildungsverzeichnis: Werkzeug für verschlüsselte bpks. Dipl.-Ing. www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Beschreibung und Bedienungsanleitung Werkzeug für verschlüsselte bpks

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

OP-LOG www.op-log.de

OP-LOG www.op-log.de Verwendung von Microsoft SQL Server, Seite 1/18 OP-LOG www.op-log.de Anleitung: Verwendung von Microsoft SQL Server 2005 Stand Mai 2010 1 Ich-lese-keine-Anleitungen 'Verwendung von Microsoft SQL Server

Mehr

Ihr CMS für die eigene Facebook Page - 1

Ihr CMS für die eigene Facebook Page - 1 Ihr CMS für die eigene Facebook Page Installation und Einrichten eines CMS für die Betreuung einer oder mehrer zusätzlichen Seiten auf Ihrer Facebook Page. Anpassen der "index.php" Installieren Sie das

Mehr

Persönliches Adressbuch

Persönliches Adressbuch Persönliches Adressbuch Persönliches Adressbuch Seite 1 Persönliches Adressbuch Seite 2 Inhaltsverzeichnis 1. WICHTIGE INFORMATIONEN ZUR BEDIENUNG VON CUMULUS 4 2. ALLGEMEINE INFORMATIONEN ZUM PERSÖNLICHEN

Mehr

Zeichen bei Zahlen entschlüsseln

Zeichen bei Zahlen entschlüsseln Zeichen bei Zahlen entschlüsseln In diesem Kapitel... Verwendung des Zahlenstrahls Absolut richtige Bestimmung von absoluten Werten Operationen bei Zahlen mit Vorzeichen: Addieren, Subtrahieren, Multiplizieren

Mehr

Grundbegriffe der Informatik

Grundbegriffe der Informatik Grundbegriffe der Informatik Einheit 15: Reguläre Ausdrücke und rechtslineare Grammatiken Thomas Worsch Universität Karlsruhe, Fakultät für Informatik Wintersemester 2008/2009 1/25 Was kann man mit endlichen

Mehr

Ein Blick voraus. des Autors von C++: Bjarne Stroustrup. 04.06.2005 Conrad Kobsch

Ein Blick voraus. des Autors von C++: Bjarne Stroustrup. 04.06.2005 Conrad Kobsch Ein Blick voraus des Autors von C++: Bjarne Stroustrup 04.06.2005 Conrad Kobsch Inhalt Einleitung Rückblick Nur eine Übergangslösung? Was würde C++ effektiver machen? Quelle 2 Einleitung Wo steht C++,

Mehr

Anleitung BFV-Widget-Generator

Anleitung BFV-Widget-Generator Anleitung BFV-Widget-Generator Seite 1 von 6 Seit dem 1. Oktober 2014 hat der Bayerische Fußball-Verband e.v. neue Widgets und einen neuen Baukasten zur Erstellung dieser Widgets veröffentlicht. Im Folgenden

Mehr

Online Newsletter III

Online Newsletter III Online Newsletter III Hallo zusammen! Aus aktuellem Anlass wurde ein neuer Newsletter fällig. Die wichtigste Neuerung betrifft unseren Webshop mit dem Namen ehbshop! Am Montag 17.10.11 wurde die Testphase

Mehr

Du hast hier die Möglichkeit Adressen zu erfassen, Lieferscheine & Rechnungen zu drucken und Deine Artikel zu verwalten.

Du hast hier die Möglichkeit Adressen zu erfassen, Lieferscheine & Rechnungen zu drucken und Deine Artikel zu verwalten. Bedienungsanleitung Professionell aussehende Rechnungen machen einen guten Eindruck vor allem wenn du gerade am Beginn deiner Unternehmung bist. Diese Vorlage ist für den Beginn und für wenige Rechnungen

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf Softwareentwicklungspraktikum Sommersemester 2007 Grobentwurf Auftraggeber Technische Universität Braunschweig

Mehr

YouTube: Video-Untertitel übersetzen

YouTube: Video-Untertitel übersetzen Der Easytrans24.com-Ratgeber YouTube: Video-Untertitel übersetzen Wie Sie mit Hilfe von Easytrans24.com in wenigen Schritten Untertitel für Ihre YouTube- Videos in mehrere Sprachen übersetzen lassen können.

Mehr

4. BEZIEHUNGEN ZWISCHEN TABELLEN

4. BEZIEHUNGEN ZWISCHEN TABELLEN 4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe

Mehr