Domänenspezifische Sprache

Eine domänenspezifische Sprache (englisch domain-specific language, DSL) ist eine formale Sprache, die speziell für ein bestimmtes Problemfeld (die 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 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 universell einsetzbare Programmiersprache, wie C und Java, 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

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 aufgrund fehlender oder ungeeigneter Tools für die DSL viele Entwicklungsaufgaben (Review, Debugging, Laufzeitmessung, ...) in der Sprache des erzeugten Codes vornehmen muss
• Risiko eines Lock-in mit interner Bindung an die eigene Toolentwicklung oder externer Bindung an den Anbieter von Tools für eine Nischensprache
• Risiko, dass die Option, 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 Tools (Editoren, Compiler, Debugger, statische Codechecker, Testumgebungen, Testabdeckungsbestimmung, Metriktools), 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/eingebettete DSLs (internal DSL)

Eine Untermenge domänenspezifischer Sprachen stellen die internen DSLs (engl. 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
• ein domänen-spezifisches UML2-Profil (Stereotypen, Stereotypeigenschaften und Constraints)
• ein domänen-spezifisches XML Schema (Elemente, Restriktionen)

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.

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 muss das Alphabet (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

• AMMI – FAW GmbH
• DEViL – Universität Paderborn
• DSL Tools für Visual Studio
• Eclipse Xtext (Teil von openArchitectureWare)
• Eclipse GMF
• EMFText
• OOMEGA TMK (Textual Modelling Kit)
• Intentional Software
• MetaEdit+ – MetaCase
• Meta Programming System – JetBrains
• MontiCore
• YML

Siehe auch

• Modellgetriebene Softwareentwicklung
• Codegenerator
• Interpreter
• Model Driven Architecture
• Domain-Driven Design

Literatur

• Thomas Stahl, Markus Völter, Sven Efftinge: Modellgetriebene Softwareentwicklung. Techniken, Engineering, Management. 2. Auflage. Dpunkt Verlag, Mai 2007, ISBN 978-3898644488.
• Georg Pietrek, Jens Trompeter (Hrsg.): Modellgetriebene Softwareentwicklung. MDA und MDSD in der Praxis. Entwickler-Press, ISBN 978-3-939084-11-2.

Weblinks

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