Entwicklung Anwendungsbezogener Sprachen

Entwicklung Anwendungsbezogener Sprachen Eine Beschreibung der Phasen und Probleme bei der Erstellung von Domain Specific Languages Seminararbeit im Fachgebiet Softwaretechnik und Informationssysteme vorgelegt von: Achim Schumacher Seminar: Software Language Engineering Matrikelnummer: 6300019 Betreuer: Prof. Dr. Uwe Kastens 18. Februar 2010

II Inhaltsverzeichnis 1. Grundlagen...1 1.1. Eigenschaften...1 1.2. Klassifikation...3 2. Entwicklung in Phasen...5 2.1. Das Phasenmodell...5 2.2. Entscheidungsphase...6 2.3. Analysephase...7 2.4. Designphase...8 2.5. Implementierungsphase...12 2.6. Einsatzphase...13 2.7. Benötigte Expertise zur Entwicklung...14 3. Fazit...15 Anhang A: Literatur...16

1. Grundlagen 1 1. Grundlagen 1.1. Eigenschaften Es gibt Computersprachen, die auf bestimmte Anwendungen zugeschnitten sind und sich damit von allgemein anwendbaren Programmiersprachen, die für viele verschiedene Zwecke eingesetzt werden, abgrenzen. Diese anwendungsbezogenen Sprachen ( domain-specific language, DSL) unterscheiden sich in einigen Eigenschaften von allgemein einsetzbaren Programmiersprachen ( general purpose language, GPL). Einige dieser Eigenschaften sollen im Folgenden erläutert werden. Ein Beispiel für DSL ist die Sprache HTML. Die Sprache enthält Anweisungen für einen Webbrowser und wird in den Anwendungsbereichen (den Domänen ) Layout und Hypertext eingesetzt. Sie ist vor allem durch die Popularität des World Wide Web bekannt geworden. Mit HTML lässt sich eine Internetseite gestalten und durch das Einfügen von sogenannten Links auf andere Seiten verweisen. HTML-Quellcode <h1>lorem ipsum</h1> <p>dolor <i>sit</i> amet, <a href= index.html > consectetur</a></p> Bildschirmausgabe Lorem ipsum dolor sit amet, consectetur Abbildung 1.1.1: Layout und Links in HTML Wie im Beispiel auf Abbildung 1.1.1 sichtbar, kann mit sehr kompakten, auf die Anwendungsgebiete spezialisierten Anweisungen, das Layout festgelegt werden. Will man das gleiche Ziel mit einer GPL erreichen, ist die Programmierung aufwändiger, da es keine GPL gibt, die vergleichbare Möglichkeiten zur Seitengestaltung bietet. Eine entsprechende Funktionalität muss dann vom Programmierer selbst umgesetzt werden.

1. Grundlagen 2 DSL Anwendungsgebiet LaTeX SQL VHDL Make Excel-Makro UML Typografie Datenbankanfragen Hardwaredesign Softwareaktualisierung Tabellenkalkulation Grafische Modellierung Kontextfreie Grammatiken Spezifikation von Syntax Tabelle 1: Bekannte DSL Es gibt noch viele weitere bekannte DSL (Tabelle 1). So wird in der Typografie häufig die Sprache LaTeX zur Beschreibung des Seitenlayouts verwendet. Für die Kommunikation mit Datenbanksystemen steht SQL zur Verfügung. VHDL wird zur Beschreibung von Schaltungen im Hardwaredesign genutzt. Die Eingabesprache von Make dient der Automatisierung des Übersetzungsprozesses von Programmen. Die Tabellenkalkulation Microsoft Excel liefert eine Makro-Sprache mit, die die Automatisierung von Aktionen der Tabellenkalkulation erlaubt. Zur Modellierung von Software ist die Sprache UML weit verbreitet, da sie eine grafische Syntax bietet und universell einsetzbar ist. Kontextfreie Grammatiken ermöglichen die Spezifikation von Syntax, also die Beschreibung der Syntax von Programmiersprachen. Dies sind nur einige Beispiele, die sich in ihrer Domäne durchsetzen konnten. Da die Sprachen auf ihren Anwendungsbereich zugeschnitten sind, sollten sie keine Konstrukte besitzen, die in der Domäne nicht benötigt werden. DSL sind damit schneller erlernbar und effizienter nutzbar. In anwendungsbezogenen Sprachen wird Wissen aus der Domäne gekapselt. Domänendetails können durch aussagekräftige und kompakte Sprachkonstrukte ersetzt werden. Für einen HTML-Entwickler ist es nicht wichtig, wie Kursivschrift im Anzeigeprogramm umgesetzt wird. Ebenso ist die Implementierung der Datenbank unerheblich, wenn ein Entwickler mit Hilfe der Sprache SQL seine Anfragen formulieren kann. In den Befehlen der Sprachen ist das Wissen enthalten, wie die Aktion in der Domäne ausgeführt wird. Ist außerdem das Anwendungsgebiet einer Sprache enger, kann die verwendete Sprache ausdrucksstärker sein. Aus einer sehr kompakten Notation lässt sich dann viel erzeugen. Eine kontextfreie Grammatik hat eine

1. Grundlagen 3 sehr spezialisierte Aufgabe und kann mit ihrer Notation nur Syntax spezifizieren. Aus einer KFG ist aber beispielsweise direkt ein Parser für die beschrieben Sprache oder ein Syntax-Baum generierbar. Durch die beschriebenen Eigenschaften ist die Nutzung einer DSL einfacher als die Verwendung von GPL. Damit vergrößert sich die Zielgruppe für die Sprache und es ist leichter möglich, auch Benutzer ohne Programmiererfahrungen anzusprechen. 1.2. Klassifikation Anwendungsbezogene Sprachen lassen sich anhand des Grades ihrer Ausführbarkeit klassifizieren. Die Sprachen befinden sich auf einem Spektrum von ausführbar bis beschreibend (Abbildung 1.2.1). Zwischen den Extremen liegen Sprachen, die beide Eigenschaften mehr oder weniger stark ausgeprägt besitzen. Ausführbar Beschreibend Excel Makro HTML / LaTeX Backus- Naur-Form Datenstrukturen Abbildung 1.2.1: Ausführbarkeitsspektrum von DSL Die Sprachen am einen Ende des Spektrums besitzen eine wohldefinierte Ausführungssemantik, haben aber nur wenig oder gar keinen beschreibenden Charakter. Als Beispiel für diese Klasse von Sprachen kann die Makro- Sprache von Microsoft Excel herangezogen werden. Sie erlaubt die programmierte Ausführung von Operationen der Tabellenkalkulation, während sie keine Zustände oder Strukturen wiedergibt. Ebenfalls in erster Linie ausführbar, aber auch etwas beschreibend ist die Klasse der Eingabesprachen für Übersetzer, die in eine andere Sprache übersetzt und dann ausgeführt werden können. Die Sprache LaTeX kann in andere Sprachen wie PostScript oder das Portable Document Format übersetzt werden. Aber auch andere ausführbare Sprachen können beschreibenden Charakter besitzen. HTML besitzt ausführbare Befehle für den Browser, beschreibt aber gleichzeitig auch das Layout der Seite. Ist eine Sprache primär beschreibend, also definiert sie statische Strukturen, kann sie denn noch in gewissem Maße ausführbar sein. Kontextfreie Grammatiken oder die Backus-Naur-Form beschreiben die Syntax von Sprachen, sind in dieser Hinsicht also nicht ausführbar. Dennoch können

1. Grundlagen 4 Syntaxbeschreibungen in KFG oder BNF wie weiter oben erläutert zur Anwendungsgenerierung genutzt werden, wenn für die beschriebene Sprache automatisch Parser erstellt werden. Das andere Ende des Spektrums bildet die Klasse von Sprachen, die ausschließlich beschreibend und entsprechend nicht ausführbar sind. Sie repräsentieren domänenspezifische Datenstrukturen. Wie für die ausführbaren Klassen von DSL ist die Analyse einer solchen Sprache ebenso möglich wie die Überprüfung von Konsistenz oder die Visualisierung.

2. Entwicklung in Phasen 5 2. Entwicklung in Phasen Bei der Entwicklung einer DSL sind konkrete Vorschläge in verschiedenen Entwicklungsstadien der Sprache hilfreich. 2.1. Das Phasenmodell Stellvertretend für die Entwicklungsstadien wird die Entwicklung einer DSL im Phasenmodell nach Mernik [1] in mehrere Phasen unterteilt, nämlich Entscheidung, Analyse, Design, Implementierung und Einsatz (Abbildung 2.1.1). Es sei jedoch darauf hingewiesen, dass die Entwicklung in der Praxis meist kein sequenzieller Prozess ist. Eine vorausgehende Analyse kann beispielsweise den Entscheidungsprozess bestimmen, oder das Design wird möglicherweise von Implementierungsentscheidungen beeinflusst. Analyse Design Entscheidung Implementierung Einsatz Muster Muster Muster Muster Muster Abbildung 2.1.1: Entwicklungsphasen mit zugehörigen Mustern Für jede dieser Entwicklungsphasen wurden Klassen von Mustern gefunden, die typische Fälle beschreiben. Beispielsweise beschreiben die Muster der Entscheidungsphase Situationen, in denen sich ein Entwickler wiederfinden kann und in denen der Einsatz einer DSL meist sinnvoll ist. Die Muster aller Phasen können unabhängig voneinander eingesetzt werden, also beeinflusst die Auswahl in der Entscheidungsphase nicht das Analyse- oder Designmuster. Innerhalb einer Klasse müssen die Muster nicht unabhängig sein und können sich überlappen. Die einzelnen Phasen und ihre Muster werden im Folgenden näher beschrieben.

2. Entwicklung in Phasen 6 2.2. Entscheidungsphase Meist ist nicht von Beginn an klar, ob sich die Entwicklung einer neuen DSL wirklich lohnt. Grundlegende Bestrebungen bei der Entscheidung sind die verbesserte Wirtschaftlichkeit der Software und die Öffnung der Softwareentwicklung für Benutzer mit weniger Domänen- und Programmierexpertise. Die Muster in dieser Phase (Tabelle 2) können als konkretere Untermuster dieser Bestrebungen gesehen werden, in denen der Einsatz einer DSL sinnvoll ist. Notation Muster Beschreibung Notation für Domäne hinzufügen - textliche zusätzlich zu visueller Notation - benutzerfreundliche Notation für API Aufgabenautomatisierung Vermeidung wiederholender Aufgaben Handhabung von Datenstrukturen Anpassung von Benutzungsschnittstellen Vereinfachung von Beschreibungen und Durchlaufen von Daten - Interaktion programmierbar machen - Vereinfachung der GUI-Erstellung Tabelle 2: Anwendungsgebiete für DSL Ein mögliches Anwendungsgebiet ist der Bedarf an weiteren Notationen für eine Domäne. Steht beispielsweise nur eine Sprache mit visueller Notation zur Beschreibung der Domäne zur Verfügung, kann diese durch eine weitere Sprache mit textlicher Notation ergänzt werden oder umgekehrt. Eine DSL kann aber auch die Benutzung einer API (Application Programming Interface, engl. Programmierschnittstelle) vereinfachen, indem sie eine benutzerfreundliche Notation zur Verfügung stellt. Die Sprache Java- Swul [2] ermöglicht die Erstellung von SWING-Objekten in Java, indem sie auf der SWING-API aufbaut. Beim Umgang mit GPL müssen Programmierer oftmals Aufgaben nach den gleichen Mustern abarbeiten. Insbesondere wenn die verwendete GPL keine Hilfsmittel wie Modularisierung bietet, kann die automatisierte Generierung des Programmcodes hilfreich sein. Nutzt man eine DSL als Eingabesprache für einen Anwendungsgenerator, lässt sich damit der benötigte Code leichter erzeugen. Auch die Handhabung von Datenstrukturen kann auf ähnliche Weise durch DSL vereinfacht werden (Abbildung 2.2.1). Stehen die Daten im Mittelpunkt des Codes, werden korrekt initialisierte Datenstrukturen oft vor-

2. Entwicklung in Phasen 7 ausgesetzt. Deren Komplexität kann es schwierig machen, den entsprechenden Code zu schreiben und zu warten. Das Durchlaufen komplizierter Datenstrukturen kann durch eine passende DSL ebenfalls besser und zuverlässiger ausgedrückt werden. int{nummer} String{name vorname} private int nummer; private String name, vorname; public int getnummer() { return this.nummer; } Weitere Anwendungsgebiete für DSL sind zum Beispiel die Erschaffung von Benutzerschnittstellen oder die Ermöglichung von Interaktivität mit einer Anwendung, wie beispielsweise die Makro-Sprache von Excel, die komplizierte und sich wiederholende Eingaben erleichtern soll. 2.3. Analysephase Abbildung 2.2.1: Codegenerierung für Datenstrukturen Um eine DSL an die Domäne anpassen zu können, muss die Domäne identifiziert und Wissen gesammelt werden. Da dies ein sehr komplexer Sachverhalt ist, der über den Rahmen dieser Ausarbeitung hinausgeht, soll er an dieser Stelle nur sehr kurz angesprochen werden. public void setnummer(int nummer) { this.nummer=nummer; } public String getname() { return this.name; } public void setname(string name) { this.name=name; } public String getvorname()... Zentral für die Analysephase ist die Erstellung einer Ontologie für den Anwendungsbereich. Die Ontologie der Domäne (Beispiel in Tabelle 3) ist eine Sammlung von Begriffen, die in der Sprache umgesetzt werden sollen. Begriffe aus Domänen Layout und Hypertext Absatz, Aufzählung, Bild, Fettschrift, Hyperlink, Kursivschrift, Tabelle, Überschrift, Zeilenumbruch,... Tabelle 3: Beispiel einer Ontologie: Begriffssammlung für HTML (Auszug) Zur Erfassung der Domäne gibt es verschiedene Quellen mit explizitem oder implizitem Wissen: Technische Dokumente, Wissen von Domänenexperten, bereits existierender GPL-Code und Benutzerumfragen.

2. Entwicklung in Phasen 8 2.4. Designphase Ist festgelegt, welche Elemente der Domäne in der DSL umgesetzt werden sollen, kann die Notation der Sprache festgelegt werden. Dabei ist vor Allem von Bedeutung, welche Beziehung die neue Sprache zu bereits existierenden hat. Also muss die Entscheidung getroffen werden, ob sie auf einer bestehenden Sprache aufbaut oder neu entworfen werden soll (Tabelle 4). Muster Sprachausnutzung Spracherfindung Beschreibung (Teilweises) Nutzen einer existierenden GPL/DSL Huckepack : Teilweise Nutzung Spezialisierung: Begrenzung der existierenden Sprache Erweiterung der existierenden Sprache Kompletter Neuentwurf ohne Gemeinsamkeiten mit existierenden Sprachen Tabelle 4: Beziehung einer neuen DSL zu existierenden Sprachen Lässt man die neue Sprache auf einer existierenden Sprache basieren, kann das die Implementierung einfacher machen, und möglicherweise kennen die Benutzer die existierende Sprache bereits. Drei Untermuster werden bei dieser Möglichkeit unterschieden: Im ersten Fall werden die domänenspezifischen Funktionen Huckepack auf Teile der existierenden Sprache übernommen. Das bedeutet, dass Teile der bestehenden Sprache weiter genutzt werden, aber um fremde Elemente erweitert werden. Der zweite Ansatz ist die Beschränkung der bestehende Sprache, um sie auf einen Bereich ihrer Funktionalität zu beschränken. Ein Beispiel hierfür ist die Sprache OWL (Web Ontology Language), die die eingeschränkte Untersprache OWL Lite besitzt [3]. Der dritte Weg zur Sprachausnutzung ist die Erweiterung einer Sprache. Die existierende Sprache wird dabei im kompletten Umfang übernommen und um an die Domäne angepasste Funktionalität ergänzt. Gleichzeitig sollte wohlüberlegt sein, ob Konstrukte und Semantiken wirklich wiederverwendet werden. Nimmt man Teile einer Sprache weg und fügt neue hinzu, kann das aufwändiger sein, als eine Sprache ohne Bezug auf andere Sprachen neu zu erstellen.

2. Entwicklung in Phasen 9 Um die Verschiedenartigkeit der möglichen Notationen zu zeigen, werden im Folgenden mehrere bekannte DSL mit ihrer speziellen Syntax vorgestellt. 2.4.1. Notation von HTML Bei HTML handelt es sich um eine Auszeichnungssprache, die sogenannte Tags zur Beschreibung der Daten benutzt (Beispiel in Abbildung 2.4.1). Diese Tags sind in den Text eingebettet und strukturieren ihn. Um einen Textteil zu klassifizieren, wird er zwischen einen Starttag (zum Beispiel <h1>) und einen entsprechenden Endtag (</h1>) geschrieben. Außerdem sind auch Tags ohne Inhalt möglich, beispielsweise für einen Zeilenumbruch (<br/>). <h1>lorem ipsum</h1> <p>dolor <b> <i>sit</i> amet </b>, <a href= index.html > consectetur </a> </p> Abbildung 2.4.1: HTML-Quelltext Außerdem lässt HTML die Schachtelung von Tags zu. Im Beispiel befindet sich der Text sit amet innerhalb des durch <b> beschrieben Bereichs und wird in Fettschrift ausgegeben, während sit desweiteren durch <i> klassifiziert ist und somit zusätzlich kursiv ausgegeben wird. Zudem können Starttags auch Attribute enthalten. Das Beispiel enthält den Link-Tag <a>, der im Attribut href die Zieladresse des Links beinhaltet. Durch Kombination der Tags wird in HTML die Beschreibung einer Seite sowie die Verlinkung zwischen den Seiten möglich, womit die Domäne Layout und Hypertext abgedeckt ist. 2.4.2. Notation kontextfreier Grammatiken Eine einfache Sprache zur Definition von konkreter Syntax ist die kontextfreie Grammatik (Beispiel in Abbildung 2.4.2) [4]. Jede kontextfreie Grammatik besteht aus vier Teilen:

2. Entwicklung in Phasen 10 T, die Menge der Terminalsymbole, aus denen die Sätze der Sprache bestehen N, die Menge der Nichtterminalsymbole, aus denen die Sprachkonstrukte abgeleitet werden P, die Menge der Produktionen, die Regeln der Grammatik S, ein Startsymbol aus der Menge N, aus dem die Sätze der Grammatik abgeleitet werden. Die Notation der Produktionen besitzt keine überflüssigen Sprachkonstrukte; jede Zeile stellt eine weitere Produktion da. Jede dieser Produktionen belegt genau eine Zeile, weshalb kein abschließendes Zeichen am Zeilenende benötigt wird. Meist werden nur die Produktionen und das Startsymbol der KFG angegeben, da sich die Mengen T und N daraus ergeben: Die Terminalsymbole (im Beispiel blau eingefärbt) sind die Symbole, die sich ausschließlich auf der rechten Seite der Produktionen befinden, während Nichtterminalsymbole auch auf der linken Seite erscheinen. Mit einer äußerst kompakten Schreibweise lässt sich somit die ganze Grammatik definieren. 2.4.3. Notation von UML Die Sprache UML wird vor allem zur Modellierung von Softwaresystemen einsetzt. Sie besitzt eine grafische Notation, die die Darstellung der einzelnen Systemkomponenten als Diagramme erlaubt. In einem Klassendiagramm werden die Eigenschaften von und die Beziehung zwischen Klassen dargestellt. Es gibt unterschiedliche Arten von Beziehungen: Mengen T und N, Startsymbol S T = {'a', 'b', 'x', 'y'} N = {A, B} S = A Menge P der Produktionen A ::= 'x' A 'y' A ::= B B ::= 'a' B ::= 'b' Abbildung 2.4.2: Beispiel einer KFG Erzeugbare Sätze a, b, xay, xby, xxayy, xxbyy... Assoziation (Beispiel in Abbildung 2.4.3): Beschreibung einer Relation zwischen Klassen. Im Beispiel wird zusätzlich zur Verbindung angegeben, wie viele Objekte in welcher Rolle in Assoziation zu den Objekten der anderen Klasse stehen: Ein Vortrag ist Bestandteil genau eines

2. Entwicklung in Phasen 11 Seminars, während ein Seminar der Rahmen für mindestens einen Vortrag ist. Seminar name: String rahmen Generalisierung (Beispiel in Abbildung 2.4.4): eine speziellere Klasse übernimmt implizit Eigenschaften einer generelleren Klasse. Die Linie zwischen den Klassen erhält ein unausgefülltes Dreieck auf der Seite der generelleren Klasse. Im Beispiel erbt ein Seminarvortrag die Eigenschaften eines Vortrags. bestandteil 1..1 1..* Vortrag Abbildung 2.4.3: Beispiel eines Klassendiagramms mit Assoziation in UML Vortrag Komposition und Aggregation: Beziehung zwischen einem Ganzen und seinen Teilen. Die Komposition wird verwendet, wenn die Teile nicht ohne das Ganze existieren können. Hier wird auf der Seite des Ganzen ein Raute auf der Linie eingefügt. Im Falle einer Komposition ist die Raute gefüllt, bei einer Aggregation nicht. Seminarvortrag Abbildung 2.4.4: Beispiel eines Klassendiagramms mit Generalisierung in UML Die Beziehung zwischen Klassen unterscheidet sich grafisch durch Variation des Symbols, das auf der Linie zwischen den Klassen eingefügt wird. Je nach Diagramm- und Beziehungstyp ist auch die Veränderung der Linie möglich, beispielsweise die Nutzung einer gestrichelten Linie. Seminarvortrag Vorbereitung Vortragender Präsentation Zuhörer Abbildung 2.4.5: Beispiel eines Anwendungsfalldiagramms in UML Mit anderen Diagrammtypen lassen sich weitere Eigenschaften von Systemen zeigen. Die Anwendungsfälle (engl. use casew) bestimmen, wie welcher Anwender mit dem System verfahren soll. Zum Beispiel (Abbildung 2.4.5) können an einem Seminarvortrag Personen in der Rolle Vortragender und Zuhörer teilnehmen. Während nur der Vortragende die Vorbereitung

2. Entwicklung in Phasen 12 eines Seminarvortrags durchführt, sind an der Präsentation sowohl Vortragende als auch Zuhörer beteiligt. 2.5. Implementierungsphase Wenn die Notation der Sprache festgelegt ist, kann der passende Implementierungsansatz (Tabelle 5) gewählt werden. Muster Interpretierer (Interpreter) Übersetzer (Compiler) Präprozessor Einbettung Beschreibung Zyklus: Holen, Dekodieren, Ausführen Flexibel und langsam Übersetzung in existierende Sprache Komplette statische Analyse des DSL-Codes Übersetzung in existierende Sprache Analyse des generierten Codes bei dessen Ausführung Einfügen in bestehende Sprache Definition neuer abstrakter Datentypen,... Einfachste Form: Anwendungsbibliothek Tabelle 5: Implementierungsmuster für DSL Wird ein Interpretierer (engl. Interpreter) eingesetzt, werden die Konstrukte der DSL erkannt und interpretiert, indem ein Holen-Dekodieren- Ausführen-Zyklus ausgeführt wird. Dieser Ansatz ist sinnvoll, wenn die Sprache einen dynamischen Charakter hat oder wenn die Ausführungsgeschwindigkeit nicht relevant ist. Ein Beispiel für interpretierbare Sprachen ist HTML. Die bekanntesten Interpretierer für HTML sind Webbrowser. Sie stellen Internetseiten oftmals dar, bevor sie komplett heruntergeladen sind. Die Ausführungsgeschwindigkeit beim Interpretieren von HTML ist nicht in erster Linie wichtig, da andere Vorgänge wie die Bildschirmdarstellung normalerweise im Vordergrund stehen. Nutzt eine Sprache vor der Ausführung einen Übersetzer (engl. Compiler), erfolgt zunächst die Übersetzung der DSL-Konstrukte in eine Basissprache und in Aufrufe von Programmbibliotheken. Auf dem DSL-Programm oder der Spezifikation kann eine komplette statische Analyse durchgeführt werden. Die Sprache LaTeX kann komplett analysiert und übersetzt werden. Die Anwendung pdflatex überprüft ein LaTeX-Dokument zuerst auf Vollständigkeit und Fehlerfreiheit und übersetzt das Dokument dann in die Seitenbeschreibungssprache PDF (Abbildung 2.5.1). Zudem ist es möglich, aus

2. Entwicklung in Phasen 13 LaTeX Übersetzung durch pdflatex PDF kontextfreien Grammatiken Parser für die spezifizierten Sprachen zu erstellen. Entsprechende Anwendungsgeneratoren verwenden eine KFG als Eingabesprache und übersetzen diese in eine ausführbare Programmiersprache. Beim Einsatz eines Präprozessors werden die DSL-Konstrukte ebenfalls in eine existierende Basissprache übersetzt. Die syntaktische Korrektheit kann allerdings nicht garantiert werden, da die Analyse nur beim späteren Verarbeiten der Basissprache durchgeführt wird. Beim Ansatz der Einbettung implementiert man die DSL, indem eine bestehende Sprache durch Definition spezifischer Datentypen und Operatoren erweitert wird. Ein anwendungsbezogenes Problem kann dann mit diesen neuen Konstrukten beschrieben werden. Die einfachste Form der Einbettung sind Anwendungsbibliotheken. Noch weitere Implementierungsansätze sind möglich, etwa die Erweiterung eines GPL-Übersetzers, was in der Praxis jedoch schwierig ist, wenn der Übersetzer nicht mit Rücksicht auf Erweiterbarkeit gestaltet wurde. Ebenso können die vorgestellten Implementierungsverfahren kombiniert werden, um die entworfene DSL passend umzusetzen. 2.6. Einsatzphase Die Entwicklung einer DSL ist jedoch nicht mit der Erstellung des Programmcodes abgeschlossen. Damit die entwickelte Sprache von den Benutzern angenommen wird, ist die Erstellung von Trainingsmaterial erforderlich. Das Trainingsmaterial wird den Benutzern vermittelt und auf Rückmeldungen der Anwender muss Rücksicht genommen werden. Die Entwicklung darf nach auch im Einsatz nicht stagnieren, denn die Sprache muss gegebenenfalls an Änderungswünsche angepasst werden. Wenn sich die Domäne ändert, ist außerdem eine Anpassung oder der Neuentwurf einer DSL notwendig. Abbildung 2.5.1: Übersetzung von LaTeX in PDF

2. Entwicklung in Phasen 14 2.7. Benötigte Expertise zur Entwicklung Um eine DSL entwickeln zu können, wird sowohl Domänen- als auch Sprachentwicklungswissen benötigt. Einerseits ist die Erfassung des Wissensgebiet eine wichtige und umfangreiche Aufgabe, denn wenn die Domäne nicht richtig verstanden wurde, kann keine gute DSL entworfen werden. Auf der anderen Seite muss auch die Implementierung einer Sprache umgesetzt werden, wofür Vorwissen aus der Sprachentwicklung unerlässlich ist. Da sich selten beide Fähigkeiten in einer Person finden, sind Erfahrung und gegenseitige Hilfe wichtig. Wie in den vergangenen Kapiteln gezeigt wurde, erfordert die Entwicklung einer DSL die Verbindung von Sprachentwicklung und Erfassung von Anwendungsgebieten. Die vorgestellten Vorgehensmuster können in den verschiedenen Entwicklungsstadien eine Hilfe sein.

3. Fazit 15 3. Fazit Das Papier von Mernik, Heering und Sloane gibt einen guten Überblick über die verschiedenen Entwicklungsstadien einer DSL. Das Phasenmodell liefert einen Rahmen, in dem die Muster als konkrete Vorschläge zur Vorgehensweise in den einzelnen Phasen verankert sind. Auch wenn die Entwicklung nicht linear wie im Modell ablaufen muss, können die einzelnen Muster unabhängig von anderen Phasen genutzt werden. Somit zeigen die Autoren eine Möglichkeit zur strukturierten Entwicklung von DSL auf. Die zweite Primärquelle, ein Papier von Kelly und Pohjonen [5], erhebt den Anspruch, durch Gegenbeispiele zu zeigen, wie DSL-Entwicklung nicht aussehen darf. Erreicht werden soll dies durch Verdeutlichung von praktischen Problemen während der Entwicklung. Dem Papier liegt jedoch eine sehr eingeschränkte Datenbasis zugrunde: es wurden 76 Fälle bei nur einer Firma mit nur einem Werkzeug untersucht. Die Autoren sind selbst Mitarbeiter dieser Firma und haben die Erkenntnisse ihrer Untersuchungen noch während der Forschung als Ratschläge an Kunden weitergegeben, was diese Kunden laut den Autoren wahrscheinlich dazu veranlasst hat, die Probleme zu vermeiden und das Ergebnis zu verändern. Das Papier enthält viele vage Aussagen und meist unbelegte Thesen, die sich die Autoren nach eigenen Angaben selbst überlegt haben. Damit erreicht das Papier kaum wissenschaftliches Niveau und taugt allenfalls zur Sensibilisierung gegenüber Problemen während der Entwicklung. Die Entwicklung anwendungsbezogener Sprachen ist insbesondere durch die Kombination von Domänen- und Sprachentwicklungsexpertise ein spannendes Forschungsgebiet, das durch das Papier von Mernik eine Struktur erhalten hat. Diese Arbeit hat die theoretischen Ausarbeitungen der Autoren durch Beispiele ergänzt, um den möglichen Ablauf der DSL-Entwicklung anhand bekannter Sprachen zu verdeutlichen und den Einstieg zu erleichtern.

Anhang A: Literatur 16 Anhang A: Literatur [1] M. Mernik, J. Heering und A. M. Sloane. When and how to develop domain-specific languages. In ACM Computing Surveys, Band 37, Nummer 4, Seiten 316 344, 2005. [2] M. Bravenboer und E. Visser. Concrete Syntax for Objects: Domain- Specific Language Embedding and Assimilation without Restrictions. In Proceedings of the 19th ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications, Seiten 365 383, 2004. [3] I. Herman. Web Ontology Language (OWL). Verfügbar unter http://www.w3.org/2004/owl/ (Zuletzt abgerufen am 15.02.2010) [4] U. Kastens. Vorlesung Grundlagen der Programmiersprachen. Verfügbar unter http://ag-kastens.upb.de/lehre/material/gps/index.html (16.02.2010) [5] S. Kelly und R. Pohjonen. Worst Practices for Domain-Specific Modeling. In Software, IEEE, Band 26, Nummer 4, Seiten 22 29, 2009.