Domänenspezifische Sprache

Eine domänenspezifische Sprache (englisch domain-specific language, kurz DSL) oder anwendungsspezifische Sprache ist eine formale Sprache, die zur Interaktion zwischen Menschen und digital arbeitenden Computern („Computersprache“) für ein bestimmtes Problemfeld (die sogenannte Domäne) entworfen und implementiert wird. Beim Entwurf einer DSL wird man bemüht sein, einen hohen Grad an Problemspezifität zu erreichen: Die Sprache soll alle Probleme der Domäne darstellen können und sie soll nichts darstellen können, was außerhalb der Domäne liegt. Dadurch ist sie durch Domänenspezialisten ohne besonderes Zusatzwissen bedienbar.

Das Gegenteil einer domänenspezifischen Sprache ist eine Allzweck-Programmiersprache, wie beispielsweise Python oder C, oder eine universell einsetzbare Modellierungssprache, wie UML.

Vorteile

Zu den Vorteilen einer DSL gegenüber der Nutzung einer allgemeinen Programmier- oder Spezifikationssprache zählen

• weniger Redundanz,
• deklarative Beschreibung eines Sachverhaltes,
• bessere Lesbarkeit,
• weniger technischer Code,
• domänenspezifische, statische Validierung (nur externe DSLs),
• leichte Erlernbarkeit aufgrund des beschränkten Umfangs –
• und verborgene Wirkungen sind eher nicht zu erwarten.

Auch Endbenutzer können DSLs verwenden, da diese leichter erlernt werden können als universell einsetzbare Programmiersprachen. Man spricht hier von End User Development.

Nachteile

• Bei Nischensprachen bzw. proprietären DSLs: Fehlen von Sprachstandards, Zertifizierungsmöglichkeiten, freien Implementierungen, freien oder kommerziellen Bibliotheken, Literatur, Diskussionsforen etc.,
• Aufwand für das Erlernen einer neuen Sprache bei einem verhältnismäßig eingeschränkten Anwendungsbereich der Sprache; fehlende Möglichkeit oder Bereitschaft von Anwendern, sich privat in der Sprache weiterzubilden,
• Risiko, dass der Anwender wegen fehlender oder ungeeigneter Dienstprogramme ("tools") für die DSL viele Entwicklungsaufgaben (Review, Fehlersuche, Laufzeitmessung, …) in der Sprache des erzeugten Codes vornehmen muss,
• Risiko eines Lock-in mit interner Bindung an die eigene Programmentwicklung oder externer Bindung an den Anbieter von Programmen für eine Nischensprache,
• Risiko, dass die Möglichkeit, eine neue Sprache zu entwickeln oder zu verwenden, zum unzureichenden Bemühen um andere sinnvolle Alternativen führt, wie beispielsweise der Schaffung vergleichbar geeigneter Abstraktionen in den bisher verwendeten Sprachen,
• Aufwand für die Bestimmung der Anforderungen an die neue Sprache, der Definition von Syntax und Semantik sowie der Implementierung und Pflege der Dienstprogramme (Editoren, Compiler, Debugger, statische Codechecker, Testumgebungen, Testabdeckungsbestimmung, Metrik-Tools), die zur Anwendung der Sprache benötigt werden,
• Schwierigkeit, die langfristig benötigten Eigenschaften der Sprache zu identifizieren: Benötigt die Sprache ein Modulkonzept, die Möglichkeit zur Definition von Unterroutinen oder Datentypen, die Darstellung von Vererbung oder Schnittstellen oder generischer Programmierung, oder die Integrierbarkeit mit Code in anderen Programmiersprachen?
• Risiko einer schleichenden Entwicklung der Sprache zu einer allgemeinen Programmiersprache, weil die Ansprüche an die Sprache steigen und die Sprache um neue Konzepte erweitert werden muss,
• Schwierigkeit der Findung des geeigneten Abstraktionsniveaus,
• hoher Anspruch an die Kompetenz der Entwickler der Sprache.

Arten von DSLs

Man unterscheidet zwischen internen (eingebetteten) DSLs und externen DSLs.

Interne bzw. eingebettete DSLs (internal DSL)

Eine Untermenge domänenspezifischer Sprachen stellen die internen DSLs (englisch internal DSL oder auch embedded domain specific language) dar, die wesentliche Komponenten der Sprachimplementierung ihrer Wirtssprache nutzen. Dadurch sinkt der Implementierungsaufwand. Eine interne DSL ist immer eine echte Untermenge einer generelleren Sprache.

Prominente Vertreter von internen DSLs sind:

• Rake (das make für Ruby),
• Xunit Frameworks,
• SwiftUI,
• ein domänen-spezifisches UML2-Profil (Stereotype, Stereotypeigenschaften und Constraints),
• ein domänen-spezifisches XML Schema (Elemente, Restriktionen),
• Lisp-basierte DSLs.

Externe DSLs (external DSL)

Eine externe DSL ist eine von Grund auf neu definierte Sprache. Sowohl die konkrete Syntax als auch die Semantik können hier frei definiert werden. Externe DSLs gelten daher als flexibler und ausdrucksstärker. War die Erstellung von externen DSLs in der Vergangenheit noch mit sehr viel Aufwand verbunden, so gibt es heute sehr gute Werkzeuge, die das Entwickeln von externen DSLs erheblich vereinfachen, z. B. eine sogenannte Language Workbench.

Prominente Beispiele für externe DSLs sind:

• SQL,
• reguläre Ausdrücke.

Nutzungsphasen

Eine DSL ist eine formale Sprache und kann daher maschinell unterstützt werden. Während bei internen DSLs die Definition, Nutzung und die Auswertung der DSL durch bestehende Werkzeuge unterstützt werden (Compiler, XML-Parser, XMI-Interpreter), müssen für externe DSL-Ansätze neue Werkzeuge erstellt werden.

Definition der Sprache

Zunächst einmal müssen das Alphabet / der Wortschatz (domänenspezifische Schlüsselwörter) der DSL festgelegt werden und die domänenspezifischen Satzbildungsregeln.

Erstellung von Sätzen

In der nächsten Phase erstellen Domänenexperten Sätze, die zum Alphabet und den Satzbildungsregeln konform gehen und die fachlichen Gegebenheiten in ihrem Problembereich spezifizieren.

Auswertung von Sätzen

Nachdem die Fachexperten ihre Spezifikationen erstellt haben, gilt es, diese maschinell auszuwerten und automatisiert weiterzubearbeiten. Eine DSL kann mittels einer Domänentransformation in eine andere DSL überführt werden, um das fachliche Problem dort weiterzuverarbeiten. Irgendwann wird aber der Bereich der DSL verlassen, und man überführt eine domänenspezifische Spezifikation in eine generische Spezifikation und kann diese dann mit Standardwerkzeugen in eine Problemlösung überführen.

Die domänenspezifische Spezifikation wird auf folgende Arten in eine andere DSL transformiert oder in eine generische Spezifikation übersetzt:

• durch Codegeneratoren,
• durch Interpreter,
• oder mit Hilfe eines Compilers.

Werkzeuge

• Development Environment for Visual Languages (DEViL), ein Generator System für visuelle Sprachen der Universität Paderborn
• DSL Tools für Visual Studio (Microsoft)
• Eclipse Xtext (Teil des Eclipse-Modeling-Framework-Projekts)
• Eclipse GMF
• EMFText
• JetBrains MPS
• MetaEdit+ – MetaCase
• MontiCore
• Langium

Siehe auch

• Modellgetriebene Softwareentwicklung
• Codegenerator
• Interpreter
• Modellgetriebene Architektur
• Domain-driven Design
• Fachsprache

Literatur

• Martin Fowler: Domain-specific languages. Addison-Wesley, ISBN 978-0-321-71294-3. 
• Georg Pietrek, Jens Trompeter (Hrsg.): Modellgetriebene Softwareentwicklung. MDA und MDSD in der Praxis. Entwickler-Press, ISBN 978-3-939084-11-2. 
• Eric Steven Raymond: The Art of Unix Programming. Addison-Wesley Professional Computing Series. Addison-Wesley Professional, Boston 2003, ISBN 0-13-142901-9, Chapter 8. Minilanguages (catb.org [abgerufen am 13. Juli 2015] diskutiert eine Reihe von domänenspezifischen Sprachen, die es unter UNIX zum Teil schon seit Jahrzehnten gibt). 
• Thomas Stahl, Markus Völter, Sven Efftinge, Arno Haase: Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management. 2. Auflage. Dpunkt Verlag, 2007, ISBN 978-3-89864-448-8. 
• Markus Völter: DSL Engineering: Designing, Implementing and Using Domain-Specific Languages. CreateSpace Independent Publishing Platform, 2013, ISBN 978-1-4812-1858-0. 

Weblinks

• Efftinge, Völter, Haase, Kolb: The pragmatic code generator programmer. – The ServerSide
• Martin Fowler on Domain Specific Languages
• Peter Friese, Sven Efftinge, Jan Köhnlein: Build your own textual DSL with Tools from the Eclipse Modeling Project.
• Sven Efftinge, Peter Friese, Jan Köhnlein: Best Practices of Model-Driven Software Development.