Domänenspezifische Sprachen zur Rettung

Wie DSLs die Welt erobern

Sven Efftinge

© iStockphoto.com / arosof

Jeder kennt den beliebten Ausspruch des Investors Marc Andreessen: „Software is Eating the World“. Dieser Satz beschreibt, wie Software heutzutage alles durchdringt und dabei disruptiv auf traditionelle Geschäftsmodelle einwirkt. Branchen, die weit entwickelt und etabliert schienen, werden oft in nur wenigen Monaten von Start-ups umgekrempelt – und das alles mithilfe von Software.

Man denke nur daran, welchen Einfluss Netflix auf das TV-Geschäft hatte oder an den Effekt von Uber auf die Taxibranche. Klassische Reisebüros haben es schwer im Wettbewerb mit Plattformen wie Airbnb. Sogar die Automobilindustrie wurde von einem Start-up erschüttert: Tesla, das mittlerweile wohl jedem ein Begriff ist. Auch hier gelang das vor allem durch Software. Und wo wir gerade von der Automobilwelt sprechen, wussten Sie, dass das durchschnittliche moderne Auto etwa 100 Millionen Zeilen Code benötigt?

Das sind nur einige der bekanntesten Beispiele dafür, dass Software „die Welt auffrisst.“ Software ist wirklich überall und wird in Zukunft nur noch bei sehr wenigen Produkten keine Rolle spielen.

Wer schreibt den ganzen Code?

„Software ist überall“ bedeutet aber auch, dass Softwaresysteme größer und komplexer werden, einfach weil sie immer mehr Aufgaben übernehmen. Zur gleichen Zeit muss alles miteinander verbunden werden, wodurch neue Dimensionen der Komplexität entstehen. Wer schreibt – und noch wichtiger –, wer pflegt all diesen Code?

Die einfache Antwort lautet natürlich: Programmierer. Wer heute programmieren kann, wird mit höchster Wahrscheinlichkeit auch einen guten Job bekommen, weil jedes Unternehmen Software entwickeln muss. Diese Software wird allerdings für spezifische Zwecke entworfen. Programmierer müssen also nicht nur wissen, wie man Code schreibt, sondern auch ein Verständnis für das Gebiet besitzen, für das die Software gedacht ist. Dazu kommt, dass das Anwendungsgebiet üblicherweise alles andere als trivial ist. Der ideale Angestellte wäre also gut im programmieren und hätte zugleich ein tiefes Verständnis der Problemdomäne. Viel Glück bei der Suche nach solchen Mitarbeitern!

In der Praxis müssen wir Teams aus Leuten mit unterschiedlichen Stärken zusammenstellen, dabei aber auch behutsam vorgehen, weil sich der Kommunikationsaufwand mit der Anzahl der Mitarbeiter im Team vergrößert. Dabei handelt es sich sogar um ein exponentielles Wachstum, oder noch genauer ausgedrückt: um eine kombinatorische Explosion. Auch in der Softwareentwicklung gilt die alte Weisheit: „Neun Frauen bringen das Baby nicht in einem Monat zur Welt“.

Anders ausgedrückt sollten wir alles dafür tun, die Zahl der Beteiligten an einem Projekt zu minimieren und ihre Produktivität zu maximieren. Es ist bestimmt eine tolle Idee, nur extrem motivierte und talentierte Branchenspezialisten zu engagieren, die gleichzeitig auch sehr gute Entwickler sind. Wenn aber nicht genug solcher talentierten Individuen zur Verfügung stehen, lässt sich das Problem auch anders lösen.

Tools zur Rettung

Profis sollten mit professionellen Werkzeugen arbeiten. Für Entwickler sind das Debugger, Compiler, Codeeditoren, Profiler und viele mehr. Solche Tools werden häufig in einer integrierten Entwicklungsumgebung (IDE) kombiniert, eine generische Plattform für Programmierer, mit der sie Software in einer generischen Sprache wie Java implementieren können.

Für Programmierer ist das alles also schön und gut, aber wie lassen sich nun die Experten für den Fachbereich in diesen Vorgang integrieren? Domänenexperten können üblicherweise keinen Code schreiben. Sollen sie nun aber wirklich Prosatexte über die Anforderungen und Konzepte des Geschäftsfelds schreiben, die von den Entwicklern dann in Code gegossen werden? Sollten wir nicht lieber versuchen, ihnen zu ermöglichen, sich aktiver am Softwareentwicklungsprozess zu beteiligen? Vielleicht könnten wir ihnen ja relevanten Code in einer Form vorlegen, den sie zumindest lesen und verstehen können, sodass sie über die reale Software sprechen können, statt über eine veraltete Liste von Anforderungen.

DSLs schließen die Lücke

Bei einer domänenspezifischen Sprache (DSL) handelt es sich um eine Programmiersprache, die auf einen bestimmten Anwendungsbereich und eine spezifische Zielgruppe zugeschnitten ist. DSLs sind formal, sodass alles, was in einer DSL geschrieben wird, eine bestimmte Bedeutung hat und von Maschinen verstanden wird. Die Notation einer DSL ist allerdings auf die Fachleute der jeweiligen Branche zugeschnitten und wird nicht durch die generische Komplexität einer typischen Programmiersprache verschlüsselt. Stattdessen bietet eine DSL leistungsstarke Konzepte an, mit denen die Probleme der Branche beschrieben und gelöst werden können.

Lesen Sie auch: DDD versus DSL: Was Domain-driven Design mit domänenspezifischen Sprachen zu tun hat

Stellen Sie sich etwa eine Abrechnungssoftware vor, in der alle gesetzlichen Vorgaben und Richtlinien berücksichtigt werden müssen. Um eine bestimmte Gehaltsabrechnung durchzuführen, sind jede Menge mathematischer Regeln notwendig. Und nun denken Sie daran, dass diese Regeln sich zwischen den verschiedenen Branchen unterscheiden und jährlich verändern können. Die Software muss allerdings immer noch dazu in der Lage sein, jede Gehaltsabrechnung aus der Vergangenheit erneut zu berechnen, mit den jeweils zum entsprechenden Zeitpunkt geltenden Bestimmungen.

Ich habe einmal einen Workshop in einem Unternehmen durchgeführt, das ein solches Produkt hatte. In diesem Fall haben die Experten für die Gehaltsabrechnung alle notwendigen Formeln in Excel notiert und den Entwicklern daneben in Textform erklärt, wie diese Formeln in die Software eingegeben werden müssen. Das Ergebnis war eine Flut aus Excel-Dateien voller Fehler, weil die Informationen nur semi-formal eingegeben wurden und nicht testbar waren. Die Entwickler haben diese Excel-Sheets dann in Code übersetzt (C# in diesem Fall). Fehler sind erst in der fertigen Software aufgefallen und behoben worden, sodass sowohl das Softwaresystem als auch die Excel-Sheets kaum mehr wartbar waren.

Ich wurde nun gerufen, weil das Unternehmen von DSLs gehört hatte und wissen wollte, ob sie damit die Kommunikation innerhalb ihres Teams verbessern und die ständige Anpassung der Regeln zur Gehaltsabrechnung erleichtern konnten. In einem zweitägigen Workshop haben wir eine DSL entworfen, mit der die Fachleute Excel-Formeln in eine Textdatei schreiben konnten (wir haben die Excel-Syntax beibehalten, weil sie bereits bekannt war). Diese Formeln wurden zudem getestet und direkt ins Produkt integriert. Die Fachexperten haben also tatsächlichen Code geschrieben, wodurch sie eine einfache Lösung mit nur einer Quelle für ihre sich ständig verändernde Fachlogik hatten. Die Formeln als Text zu verwalten, hat außerdem die Versionierung und die Zusammenarbeit mit dem Softwareteam vereinfacht. Die DSL hat einige wichtige Konzepte unterstützt, die für diese Branche nötig waren. Beispielsweise wurde das Konzept der deklarativen Gültigkeitsbereiche eingeführt, die es ermöglichten, bestimmte Formeln mit einem Start- und Enddatum zu verstehen. Diese Informationen fanden sich zuvor verstreut durch den Code in Form von langen if-then-else-Ketten, die schwer zu verstehen waren, wenn man nach einiger Zeit erneut eine Regel hinzufügen wollte.

Neben der Begrenzung auf eine Quelle, die die Redundanz stark verringert hat, konnten nun außerdem alle Beteiligten gemeinsam auf den Quellcode des Systems schauen und darüber diskutieren – ohne Missverständnisse. Zum Design der DSL haben wir Eclipse Xtext verwendet, sodass ein vollständiger Editor mit einem Contentassistenten, Fehlerchecks und vielem mehr zur Verfügung stand.

Lesen Sie auch: DSLs mit Xtext für IntelliJ IDEA

Eine solche DSL kann über Xtext in kurzer Zeit implementiert werden. Zusätzlich ist die DSL auf diesem Weg leicht zu erweitern und zu pflegen. Das Framework unterstützt den gesamten Umfang dessen, was eine DSL-Implementierung braucht und bietet sogar eine erweiterte Unterstützung für die Bearbeitung auf verschiedenen Plattformen an. Die Sprache kann auf eine RCP-Anwendung heruntergebrochen werden und ist so ohne die Komplexität einer typischen Eclipse-IDE nutzbar. Alternativ kann auch eine Updateseite für Entwickler geschrieben werden, über die DSL-Editoren installiert und aktualisiert werden können. Mit der neuen Webeditorintegration von Xtext können die DSL-Files sogar in jeder Art von Webanwendung bearbeitet werden. Man könnte sich ein Admintool für das Gehaltsabrechnungssystem vorstellen, über das Formulare im laufenden System bearbeitet oder hinzugefügt werden können.

Fazit

Was sollten Sie aus diesem Artikel mitnehmen? Klug angewendet können DSLs die Produktivität von Teams enorm steigern und Software leichter pflegbar machen. Der schwerste Teil dabei ist es, herauszufinden, wo der richtige Ansatzpunkt für diese Art von weitreichender Abstraktion ist, sodass sich die Investition lohnt. Ich stelle mir DSLs gerne als Erweiterungen dessen vor, was sich mit allgemeiner Programmierung machen lässt: Die Entwickler von Frameworks erstellen normalerweise Bausteine für Anwendungsentwickler. Aus denselben Gründen entwerfen Sprachenentwickler DSLs für nicht programmierende, aber logisch denkende Teammitglieder.

Verwandte Themen:

Geschrieben von
Sven Efftinge
Sven Efftinge
Sven Efftinge ist Projektleiter von Eclipse Xtext und Xtend. Er ist CEO und Language Architect bei TypeFox. In seiner Freizeit verbringt er gerne viel Zeit mit seinen Kindern oder mit einem Kite auf der Ostsee.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: