Entwicklungssysteme Domänenspezifische Sprachen

Unter »Domain Specific Languages« (DSLs) sind Programmiersprachen zu verstehen, die nicht universell sondern für eine spezifischen Bereichen, also ein Arbeits- oder Einsatzgebiet, zugeschnitten sind. Umgangssprachlich könnte man sie als Fachsprachen bezeichnen. Sie sollen, ähnlich wie »normale« Programmiersprachen eine festgelegte Bedeutung haben und automatisch verarbeitbar sein.

Sie können aber auch »nur« der Informationsgewinnung dienen. So sind in der Unix-Welt Programme wie »awk« dazu gedacht, aus Texten und Tabellen Informationen zu filtern. Zur Beschreibung dieser Filter kommen dann ebenfalls eigene Sprachen, in diesem Sinne also DSLs, zum Einsatz.

Um eine DSL (Domain Specific Languages) automatisch verarbeitbar zu machen, sind entsprechende Werkzeuge wie Compiler, Entwicklungsumgebungen oder Debugger nötig. Diese zu bauen ist aufwändig und stellt für die Entwickler oftmals eine große Hürde da. Daher wurden Generatoren wie beispielsweise »lex« und »yacc« entwickelt, die einen großen Teil der Werkzeugerstellung automatisch ausführen. Dazu ist allerdings eine eigene Beschreibungssprache nötig, eben eine DSL. Solche Beschreibungssprachen werden auch als Meta-Sprachen bezeichnet, da sie dazu dienen, eine andere Sprache zu beschreiben.

Eigentlich lässt sich mit einer solchen Syntaxbeschreibung (zum Beispiel EBNF (Extendet Backus Naur Form), eine DSL zur Beschreibung von kontextfreien Grammatiken (Bild 1)) nur das »Aussehen« einer Sprache beschreiben, jedoch nicht deren Bedeutung erklären. Hierzu werden so genannte Modell-Beschreibungssprachen, wie UML (Bild 2), eingesetzt. Eine Kombination aus Syntax- und Modell-Beschreibungssprache findet sich in Werkzeugen wie »Xtext«, das als Open-Source-Software zur Verfügung steht [3].

Der Entwurf einer DSL

Beim Entwurf einer eigenen DSL sollte immer das zu Grunde liegende Modell, das die Funktionalität der Sprache beschreibt, im Fokus stehen. Der naive Ansatz, mit der Grammatik zu beginnen, führt schnell zu einem erheblichen Mehraufwand, da das Modell zu Beginn meist noch nicht vollständig verstanden wurde [1].

Das folgende praktische Beispiel soll die Entwicklung einer DSL aufzeigen. In der SPS-Welt (Speicherprogrammierbare Steuerungen in der Automatisierungstechnik) gibt es die Variante »Funktionsbaustein-Sprache«, die sogar grafisch orientiert ist.

Ein Funktionsbaustein (Bild 3) ist ein Rechteck, das linksseitig die Eingänge und nach rechts die Ausgänge hat. Werden die Eingänge mit Werten belegt, kann der Funktionsbaustein ausgeführt werden und gibt an den Ausgängen das Ergebnis aus. Funktionsbausteine können so kombiniert werden, dass Eingänge mit Ausgängen verbunden sind und somit ein Datenfluss durch ein Netz von Bausteinen führt. Aus einem System so verbundener Funktionsbausteine lassen sich dann neue Funktionsbausteine definieren. Man kann sich leicht vorstellen, dass auf diesem Wege auch größere Steuerungsprogramme geschrieben werden können. Es muss jedoch eine Basismenge von vordefinierten Funktionsbausteinen vorhanden sein, die grundlegende Funktionen des Steuerprogramms beschreiben.

Da solch ein Baustein ein Gedächtnis, also die Fähigkeit verschiedene Zustände anzunehmen, besitzen soll, wird er als Automat definiert (hier als ein Moore-Automat). Aus einer solchen Automatenbeschreibung lassen sich dann ein Programm erzeugen, Testsequenzen ableiten oder auch Eigenschaften wie die Verklemmungsfreiheit (d. h. das Programm bleibt nirgends stecken) nachgewiesen werden.

Die Verwendung einer DSL ist also in solch einem Fall nicht auf das Erzeugen von Maschinencode beschränkt. Für die Beschreibung des  Automaten benötigt man die Menge der Ein- und Ausgangs-variablen, der Zustände und deren Übergänge. Dass dies nicht nur graue Theorie ist, zeigt die Modellierung von Funktionsbausteinen für Safety-Steuerungen, wie wir sie bei der PLCopen Safety Group finden [4].