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

1.3 Erfolgsfaktoren und Risiken von DSLs 11
leichtert die Wartung von Software, weil bei geänderten Anforderungen häufig nur eines
von beiden angepasst werden muss und sich so die Auswirkungen besser lokal begrenzen
lassen. Somit begünstigt der Einsatz von DSLs die Wiederverwendung von Software oder
Modellen in anderen Anwendungsbereichen [MHS03].
Die modellgetriebene Entwicklung verwendet DSL-Modelle als zentrale Artefakte bei
der Softwareentwicklung. Die kompakten Modelle sind durch die Nähe zur Domäne nahezu
selbst-dokumentierend. Dadurch können anders als bei der Programmierung, in der das
Programm durch einen Compiler in eine ausführbare Form übersetzt wird, leichter auch
weiterführende Ziele verfolgt werden: automatisierte Testcodeerzeugung, Dokumentation
und statische sowie dynamische Analysen. Zusätzlich besteht für DSLs im Gegensatz zu
GPLs nicht der Zwang, dass sie ausführbar sein müssen [MHS03], was ein anderes Herangehen
an Problemstellungen erlaubt und auch den Einsatz von DSLs in frühen Phasen der
Softwareentwicklung ermöglicht.
Die Risiken bei der Verwendung von DSLs liegen vor allem in den Kosten für den
Entwurf, die Implementierung, Weiterentwicklung und Wartung einer DSL und den Kosten
für die Schulung der Entwickler [DKV00]. Dieses Risiko ergibt sich für fast jede neue
Technologie, weil Compiler für eine Vielzahl an Plattformen in hoher Qualität kostengünstig
verfügbar sind. DSLs hingegen müssen relativ oft spezifisch für ein Projekt entwickelt
oder zumindestens angepasst werden [DK98]. Dieser Punkt wird in dieser Arbeit
insofern adressiert, als mit dem Grammatikformat eine möglichst einfache und kompakte
Sprachdefinition erreicht werden kann. Ergänzend dazu kapselt das DSLTool-Framework
viel Wissen, das nötig ist, um modellbasierte Codegeneratoren zu entwickeln, und verringert
somit den Entwicklungsaufwand. Die Schulung der DSL-Nutzer ist notwenig, kann
aber dadurch vereinfacht werden, dass die DSLs aus Elementen aufgebaut werden, die zum
Standardrepertoire in der Informatik gehören, was den Lernaufwand reduziert.
Es ist außerdem schwierig, den richtigen Aufgabenbereich für die DSL zu definieren,
um dabei einen Mehrwert für die Entwickler zu erreichen, ohne eine neue allgemeingültige
Programmiersprache zu entwickeln [DKV00]. Der Entwurf einer DSL unterscheidet sich
hier kaum vom Entwurf einer Programmiersprache. Geeignete Abstraktionen zu finden ist
ein iterativer Prozess, in dem die Sprache immer wieder den Erfordernissen der Entwickler
angepasst werden muss. GPLs haben hier den Vorteil, dass oftmals die Nutzeranzahl
deutlich höher ist und sich somit der hohe Aufwand leichter amortisieren kann. Bei DSLs
hingegen ist es hilfreich, wenn die DSL-Entwickler zunächst mit einer kleinen Anzahl von
Produktentwicklern zusammenarbeiten und so schnelle Rückmeldungen zur Verbesserung
der Sprache nutzen können.
Ein oft genanntes Gegenargument für den Einsatz von DSLs ist, dass der aus einer DSL
erzeugte Code nicht so effizient wie eine handcodierte Anwendung ist [DKV00]. Dieses
Argument gilt insbesondere, wenn die Abstraktion der DSL ungünstig gewählt ist, und
erinnert an Argumente, die bei der Einführung von Hochsprachen und Compilern gültig
waren. Eine Kompensation dieses Effektes ist durch Optimierungen bei der Codeerzeugung
möglich.
Paul Hudak fasst die Abwägung der Vor- und Nachteile von DSLs in der Abbildung 1.2
zusammen, wobei ausschließlich die Kosten miteinander verglichen werden. Die beschriebenen
Vorteile von DSLs in Bezug auf die allgemeinen Verbesserungen des Prozesses, die
verbesserte Wartbarkeit und die Möglichkeiten der modellbasierten Entwicklung sind ebenfalls
zu beachten. Paul Hudak gibt keine Maßzahl für den Schnittpunkt der beiden Kurven
und die Höhe der notwendigen Anfangsinvestition an [Hud98]. Das publizierte Zahlenmaterial
hierzu ist wenig aussagekräftig, weil es für DSLs im Wesentlichen die bereits zitierten
Vergleiche der generierten Quellcodemenge mit der ursprünglichen Menge an DSL-Code