Mastering Software Complexity

Was sind domänenspezifische Sprachen und wann ist ihr Einsatz sinnvoll?

Projektleiter stehen immer wieder vor der Frage, ob es für ihr Projekt nützlich ist,  domänenspezifische Sprachen (DSL) zu entwickeln. Eine solche DSL deckt in der Regel nur einen Aspekt oder Teilbereich im Gesamtprojekt ab, so dass es oftmals auch zum Einsatz mehrerer DSLs im Rahmen eines Projektes kommt.

Selbstverständlich kann es auch sinnvoll sein, eine schon bestehende DSL in einem Projekt zu verwenden. Dies ist meist einfacher zu realisieren, da es für bestimmte Domänen schon sehr verbreitete DSLs gibt, die quasi einen Standard darstellen.

Ich will in diesem Artikel jedoch Anhaltspunkte dafür liefern, wann es sinnvoll ist, eine eigene DSL zu entwickeln.

Was sind domänenspezifische Sprachen?

Domänenspezifische Sprachen begegnen uns in verschiedenen Formen. Wir unterscheiden technische DSLs wie etwa SQL, MatLab/Simulink und AUTOSAR auf der einen Seite und konzeptuelle DSLs wie Stundenpläne in der Schule oder auch Versicherungsverträge auf der anderen.

Beispiele für domänenspezifische Sprachen:

SQL

SQL ist eine textuelle DSL zur Entwicklung von Datenbanken.   

Beispiel: Select * from emp where sal>=1000 And  sal<2000

MatLab / Simulink

Matlab ist ein Werkzeug mit einer textuellen DSL mit der z.B. numerische Probleme gelöst werden können. Darauf aufsetzend stellt Simulink eine grafische DSL zur Modellierung von technischen und physikalischen Systemen zur Verfügung.

Beispiel:  Steuerung eines Lego Roboters

Domänenspezifische Sprachen und Tools Simulink

By Medelen8 – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=27948580

AUTOSAR

AUTOSAR enthält u.A. eine DSL zur Modellierung von komponentenbasierten Automotive Softwaresystemen.

Beispiel: Scheibenwischer Steuerungssystem

domänenspezifische Sprachen AUTOSAR Example

Stundenplan

Ein Stundenplan ist gutes Beispiel für eine sehr einfache, aber sehr nützliche DSL die jeder kennt.

domänenspezifische Sprachen - konzeptuelle DSLs

Charakteristiken

Die Beispiele zeigen uns, dass es sowohl textuelle als auch grafische Notationen für DSLs gibt, die sich häufig gegenseitig ergänzen. In beiden Fällen gibt es eine begrenzte Anzahl zur Verfügung stehender Elemente, die nach vorgegebenen Regeln miteinander kombiniert werden können.

Mögliche Nutzen einer DSL

Anhand der genannten Beispiele lässt sich sofort eine Reihe von Vorteilen erkennen, die der Einsatz einer DSL bietet:

Ein nicht ganz so naheliegender Nutzen ist das vertiefte Verständnis einer Domäne durch die Konstruktion einer DSL. Dieser Erkenntnisgewinn ist allerdings kaum hoch genug einzuschätzen.

Automation und Abstraktion

Abstraktion ist die Art und Weise, wie wir über ein Problem nachdenken, wie wir komplexe Vorstellungen kommunizieren und wie wir Probleme logisch zerlegen. Abstraktion entfernt also alle überflüssigen Details.

Automation ist der gegenläufige Prozess, bei dem wir etwas so detailliert beschreiben, dass es automatisch ausgeführt werden kann. Besonders interessant werden domänenspezifische Sprachen dann, wenn sich diese beiden Aspekte vereinigen lassen.

Automation und Abstraktion mit Zustandsautomaten:

domänenspezifische Sprachen automation und Abstraktion

… und die Modellierung von Datenflussdiagrammen:

Domänenspezifische Sprachen Datenflussdiagramm

 

In beiden Beispielen lässt sich aus den Diagrammen Programmcode generieren. Dieser wird übersetzt und gegen eine Laufzeitbibliothek gebunden und kann dann auf dem entsprechenden Zielsystem ausgeführt werden.

Wann ist der Einsatz einer DSL sinnvoll?

Zusammenfassend finde ich den Einsatz einer DSL grundsätzlich dann sinnvoll, wenn einer oder mehrere der folgenden Punkte gewünscht sind

Ich möchte an dieser Stelle betonen, dass eine DSL keine „eierlegende Wollmilchsau“ sein muss. Sie ist bereits von Nutzen, wenn einer oder mehrere der genannten Aspekte zutreffen und das häufig auch nur in einem eng abgesteckten Bereich eines Projektes. Insofern ist das Beispiel AUTOSAR nicht unbedingt typisch, da AUTOSAR meist von zentraler Bedeutung in einem Projekt ist, um das herum sich die anderen Teile gruppieren.

Zur letztendlichen Beantwortung der Frage, wann die Entwicklung einer DSL sich lohnt, sind neben dem Nutzen für das konkrete Projekt noch weitere Faktoren entscheidend:

Erstellung einer eigenen DSL in einem iterativen Prozess

Da der Aufwand für die Implementierung einer grafischen DSL den für eine textuelle DSL um mindestens eine Größenordnung übertrifft, empfehlen wir unbedingt, mit einer textuellen DSL zu beginnen. Sehr bewährt hat sich hier z.B. das Eclipse Xtext Framework, mit dem sich eine textuelle DSL ausgehend von einer Grammatik beschreiben lässt. Das Framework generiert daraus ein Metamodell und einen reichhaltigen Editor. Falls es gewünscht wird, kann später immer noch ein grafischer Editor als Alternative implementiert werden.

Von entscheidender Bedeutung ist die Entwicklung der DSL in einem iterativen Prozess: Man beginnt mit einem sehr einfachen Prototyp, um erste Erfahrungen zu sammeln. Parallel dazu kann man gegebenenfalls auch schon einen ebenso einfachen Generator, z.B. für Dokumentationszwecke im Markdown-Format, entwickeln. Auf diese Weise lernt man sehr schnell, was wirklich gebraucht wird und man kann mit verhältnismäßig wenig Aufwand schon die „niedrig hängenden Früchte“ ernten. Vor jedem weiteren Iterationsschritt kann man dann erneut beurteilen, ob der zu erwartende Nutzen den immer besser abschätzbaren Aufwand rechtfertigt.

Wer einmal angefangen hat, eigene maßgeschneiderte DSLs zu entwickeln, wird bald feststellen, dass der Einstieg verhältnismäßig einfach ist und sehr schnell rentabel wird. Zudem wächst auch das Know-How für die Erstellung von DSLs sehr schnell – und zwar in zweierlei Hinsicht: in Bezug auf die Beherrschung der Technologie zur Erstellung einer DSL wie auch auf ein Gespür für das geeignete Design einer Sprache.

Von Anfang an ins Auge fassen sollte man auch die Integration der neu entstehenden DSL-Werkzeuge mit anderen Werkzeugen, z.B. die Validierung oder die Generierung von Artefakten im Rahmen des Bauprozesses einer Continuous Integration.

Auch wenn der Einstieg in die Entwicklung einer eigenen DSL einfacher erscheint, als Sie vielleicht anfänglich dachten – für einen gelungenen Start empfiehlt es sich immer, professionelle Unterstützung an Bord zu holen. Erfahrene Experten werden Sie dabei unterstützen, damit auch die wichtigen ersten Schritte direkt in die richtige Richtung führen!

Über den Autor

Henrik Rentz-Reichert ist Geschäftsführer von PROTOS. Unter Einsatz domänenspezifischer Sprachen konzipiert und realisiert er für unsere Kunden Werkzeugketten für Embedded Systeme und Enterprise IT. Zudem ist er gemeinsam mit Thomas Schütz Projektleiter des Eclipse Projektes eTrice.

Fragen, Anregungen oder Kritik zu dem Artikel? Schreiben Sie Henrik Rentz-Reichert persönlich. Ihre Nachricht wird nicht veröffentlicht!




Einwilligung



Es gilt die PROTOS Datenschutzvereinbarung

Bitte stimmen Sie der Kontaktaufnahme zu, bevor Sie das Formular absenden können.

Kunde

Pari GmbH

Schlagworte: Produktion in der Medizintechnik, Traceability, Modellbasierte Automatisierung und Produktionssteuerung, Fertigungsoptimierung, SAP-Anbindung

Technologien: ROOM, Trice, eTrice, UML2, Rhapsody, Linux, Interbus-S, Sercos-III, Modbus, EtherCAT, Codegenerierung für C++ und Java, Eclipse EMF und RCP

Partner

Embedded for You

Embedded for You ist ein Verein von deutschen Anbietern für Software- und Hardwarelösungen im Bereich der Embedded Systeme. Mit unseren Partnern erstellen wir kundenspezifische Gesamtlösungen für alle Arten von Embedded Systemen.

Partner

Eclipseina

Die Eclipseina GmbH ist ein Beratungs- und Dienstleistungsunternehmen, das sich auf embedded Softwareentwicklung spezialisiert hat. Dabei bedient sie alle Disziplinen, die für eine erfolgreiche Softwareentwicklung sowohl in technischer als auch in organisatorischer Hinsicht notwendig sind.

Partner

oose.

oose bietet Ihnen exzellente Seminare, Workshops, Beratung und Projektunterstützung für Software & Systems Engineering, neue Arbeitswelten und Innovation.

Kunde

Visteon

Schlagworte: Entwicklung von domänenspezifischen Sprachen für Infotainmentsysteme, DSL-Entwicklung auf der Basis von Xtext, Middleware in C++ für verschiedene Architekturen, Tooling für Entwickler, GUI-Entwicklung für Eclipse-basierte Tools, Integration der eTrice Statemachine Editoren und Code Generatoren

Technologien:  Xtext, Xtend, Eclipse, C++, Java, eTrice, Statemachines

Kunde

Siemens

Schlagworte: Maschinensteuerungen, Barcode, Netzwerkapplikationen, Traceability in der Produktion, Datenbank Integration

Technologien: C++, XML

Kunde

SCHAEFFLER

Schlagworte: Entwicklung einer modellgetriebenen Toolchain für Mechatronik und Elektro-Mobilität auf Basis von Eclipse eTrice, Aufbau des technischen Entwicklungsprozesses mit hohem Automatisierungsgrad

Technologien: ROOM, Eclipse eTrice, Codegenerierung und Transformationen für verschiedene Sprachen und Formate (Eclipse Xtend, EMF), Entwicklung domänenspezifischer Sprachen (Eclipse Xtext), Continuous Integration (Hudson), C, Python, A2L, CAN

Kunde

HARMAN

Harman Automotive ist weltweit führender Hersteller von In-Car Premium Audio- und Infotainmentsystemen.

Schlagworte: Automatiserte Auswertung von Tracedaten aus Tests, Systemstabilität, Performance

Technologien: QNX, Perl, C++

Kunde

ept

Schlagworte: Automatisierungstechnik, Modellbasierte Steuerungslösungen für Serienanlagen, Harte Echtzeitsysteme, numerische Optimierung

Technologien: ROOM, Trice, Codegenerierung für C++ und C, CAN

Kunde

Infineon

Schlagworte: Modellbasierte Konfiguration für Microcontroller Varianten

Technologien: Eclipse-EMF, Xtext, JET, Codegenerierung für C, Java

Kunde

BMW Group

Schlagworte: Software Architektur für Bordnetze, Spezifikationen für elektronische Fahrzeugfunktionen, Modellbasiertes Rapid Prototyping für Steuergeräte, Modellbasierte Entwicklung, Automatisierte Steuergerätetests, Model und Hardware in the Loop

Technologien: ROOM, Trice, Codegenerierung, Java, C++, C, CAN, MOST, Flexray, Eclipse-EMF