MontiCore: Agile Entwicklung von domänenspezifischen Sprachen ...

1.1 Motivation 5
der manuell oder automatisiert mit Hilfe von Modelltransformationen abgebildet werden.
Die verschiedenen Abstraktionsebenen erschweren jedoch den Umgang mit sich wandelnden
Anforderungen, weil so oftmals Änderungen nachgepflegt werden müssen. Daher greift
die so genannte modellgetriebene Entwicklung den Wunsch nach einer direkten Codeerzeugung
aus Modellen auf. Die Integration des generierten Quellcodes erfolgt teilweise auf
Codeebene, was jedoch eher eine pragmatische Lösung als ein anzustrebendes Ideal ist. Der
entscheidende Nachteil ist, dass die Entwickler die Struktur der Codegenerierung verstehen
müssen und sich nicht auf das Verständnis der Modelle beschränken können.
Frameworks und APIs kapseln sich wiederholende Aspekte einer Implementierungsarbeit
und stellen so eine Alternative zur modellgetriebenen Entwicklung dar. Gerade bei der
Entwicklung von Geschäftssoftware sind Frameworks weit verbreitet, die auf der JavaEE-
Spezifikation basieren. Das Hauptproblem bei der Verwendung von Frameworks und APIs
ist jedoch, dass deren Freiheitsgrade durch die Modularität der gewählten Programmiersprache
begrenzt sind, so dass wiederkehrende Funktionalität zum Beispiel nur in Form von
Klassen und Methoden bereitgestellt werden kann. Mehr Freiheit erlauben da generative
Ansätze, die auch sich ähnelnden Code aus Modellen erzeugen können, der nicht gekapselt
werden kann. Dabei müssen die notwendigen Informationen jedoch für den Codegenerator
formuliert werden.
Mit zunehmender Abstraktion einer Programmiersprache von technischen Gegebenheiten
muss oftmals zwischen zwei Extremen abgewogen werden: Einerseits erleichtern abstrakte
und daher kompakte Programme die Implementierung eines Softwaresystems, weil
weniger Quellcode geschrieben werden muss. Dieses reduziert allein durch die Übersichtlichkeit
die Anzahl der Entwicklungsfehler und verringert so die Kosten und die time-tomarket.
Andererseits birgt die Abstraktion das Risiko, dass die gewählte Lösung ineffizient
ist oder das genau gewünschte Verhalten nicht erreichbar ist, weil für das gegebene Problem
falsch abstrahiert wurde. Diese Entscheidung kann nicht für jede Domäne generalisiert
werden: Für Geschäftssoftware ist teilweise die time-to-market die entscheidende Komponente,
da bei schnell wechselnden Märkten lange Entwicklungszeiten hemmend für das
Geschäft sind. Bei der Entwicklung automotiver Systeme sind die Stückkosten weiterhin
entscheidend, weil sich die Entwicklungskosten, die zu einer kompakteren, preisgünstigeren
Hardware führen, schnell amortisieren.
Die Anzahl der Anwendungsgebiete der Informatik, die auch Domänen genannt werden,
steigt mit der zunehmenden Verbreitung der Informationstechnik in vielen Bereichen
des alltäglichen Lebens. Die ständig steigende Leistungsfähigkeit und Kompaktheit der
Hardware erlaubt dabei eine Vielzahl an neuen Anwendungen. Die in einigen Domänen bereits
existierenden Notationen, um Systeme zu beschreiben, und Sprachen, die für Domänenexperten
zugänglicher sind als Programmiersprachen, werden als domänenspezifische
Sprachen bezeichnet. DSLs haben im Gegensatz zu allgemeinen abstrakteren Programmiersprachen
weniger das Problem, dass durch die Wahl der Abstraktion eine ineffiziente
Implementierung erzeugt wird, weil die Abstraktion spezifisch für die Domäne gewählt
wurde und keine Allgemeingültigkeit besitzen muss. Normalerweise ist daher auch kein
neues Programmiersprachenparadigma in einer DSL enthalten. Die Idee der domänenspezifischen
Sprache ist in der Informatik keineswegs neu. Bereits Ende der sechziger Jahre
wurde die Idee formuliert und gipfelt in [Lan66] sogar darin, dass eine Vielzahl an neuen
Programmiersprachen postuliert wurde. Erfolgreich eingesetzte Sprachen wie Cobol wurden
spezifisch für einen Anwendungsbereich wie die betriebswirtschaftlichen Anwendungen
konzipiert und auch vor allem dort eingesetzt.
Die Vorteile der Verwendung von DSLs liegen vor allem in der engen Einbindung von
Domänenexperten, die durch ihre Expertise das Softwaresystem selbst besser verstehen,