Bisherige Softwareentwicklung krankt daran, daß man seine Aufgabe umständlich in einer klassischen Programmiersprache formulieren muß. Java, C, Basic, Perl, PHP, Phyton und der ganze übrige Zoo der Algolnachfahren zwingt den Entwickler, seine Lösungen in Sprachen zu formulieren, die seiner konkreten Aufgabe meist sehr fremd sind. Aktuelle Programmiersprachen wurden entwickelt, um Algorithmen gut darstellen zu können, oder um abstrakte Konzepte wie die Objektorientierung umzusetzen, aber nicht, um damit die Regeln und Vorgänge einer Auftragserfassung auszzudrücken. Programmieren ist deswegen eine echte Fleißarbeit. Man erzeugt tausende von Quellcodezeilen, die hoffentlich die Aufgabe erfüllen. Aber am Ende ist der Sinn irgendwie hineinkodiert, und zwar in einer Art und Weise, die man alles andere als leicht versteht. Spätestens, wenn die Mitarbeiter wechseln, ist der Überblick verloren. Programmieren ist keine Ingenieurskunst, es ist ein Handwerk, und bestenfalls eine Kunst. Für die, welche damit Arbeiten, ist es aber fast immer eine Form des Katastrophenmanagements. Und bei all dem wird man das Gefühl nicht los, das man etwas falsch macht. Und tatsächlich – viele Softwareprojekte scheitern, oder sie sind hart an der Grenze dazu. Das ist die bekannte Kriese der Softwareindustrie.

Die Lösung muß grundsätzlich anders sein, und längst ist hier ein Wandel im Gange. Der neue Weg heißt Domain Language, aber letztlich ist es ein alter Hut, der wie viele gute Ideen lange Zeit nicht aufgegriffen wurde, vielleicht weil die Zeit einfach nicht reif war. Es geht um die einfache Tatsache, eine Aufgabe in einer dafür geeigneten Sprache auszudrücken. Andere Bereiche machen es doch schon lange vor – in der Chemie, in der Mathematematik, in der Musik, in der Literatur oder im Maschinenbau werden Pläne, Notationen, Modelle und Sprachen benutzt, die in ihrem Bereich gut geeignet sind, die Ideen und Konzepte einer Sache zu formulieren.

In der Programmierung wird das schon länger praktiziert, aber eben nicht von der großen Mehrheit. „Die eigentliche Kunst des Programmierens ist es, sich für eine Aufgabe eine eigene Sprache zu schaffen und ein Programm, um diese Sprache auf eine bestehende Programmiersprache abzubilden“, so ein altes Buch über Lisp-Programmierung. Wenn man das einmal geschafft hat, kann man jede ähnliche Aufgabe, die sich mit der selben oder einer leicht abgeänderten Sprachen formulieren läßt, sehr schnell und in hoher Qualität lösen, ganz so, wie es der Übergang von der Handwerklichen Fertigung zur Industriellen Massenproduktion vormacht. Deswegen dominieren im Moment auch Worte wie „Softwarefabrik“, „Montage“ oder „Transformation“ die Fachzeitschriften.

Aber dieser Weg, der momentan oft mit UML und darauf aufbauenden MDA-Tools umgesetzt wird, führt nicht selten an der eigentlichen Zielsprache vorbei. Da solche Sprachen der zugrundelegenden Abstraktion natürlich entsprechen, sind sie der UML überlegen, die für allgemeine Probleme entwickelt wurde. In UML muß die eigentliche Logik oft nachkodiert werden, weil nur ein grobes Gerüst erstellt wird. In einer DML dagegen wird das Problem in einer Sprache ausgedrückt, die aus dem Problemfeld kommt. Ein Experte, zum Beispiel ein Finanzmitarbeiter, wird sich in einer solchen Sprache zurechtfinden. Ein recht allgemeines Beispiel dafür mag Excel sein, auch wenn es nicht unbedingt ein glanzvolles ist. Weitaus fortgeschrittenere Möglichkeiten hat man mit Tools wie Mathematica oder [ecomod|http://www.wi-inf.uni-essen.de/FGFrank/ecomod/index.php?workflow=approach&&lang=en].

verständlichen Sprache ausgedrückt.


Praktisch heißt das: Fang damit an, deine Aufgabe und die Lösung zu beschreiben, und zwar so, daß Du diese Beschreibung nimmst und z.B. mit einem Java-Programm in Java-Quelltext übersetzt. Dann hat man eine Ideale Situation – die Dokumentation ist gleichzeitig das Programm. Die hierzu notwendigen Techniken werden interessanterweise schon seit Jahrzehnten im Rahmen des Informatikstudiums (Compilerbau) gelehrt.

Natürlich hat es einen Grund, warum die meisten Programmierer immer anders gearbeitet haben – der „neue“ Weg hat seine eigenen Schwierigkeiten. Man muß sich nämlich erst einmal viele Gedanken zu dieser Sprache machen, die man da erfinden muß. Statt einem schreibt man plötzlich vier Programme – die neue Sprache muß definiert werden, dann muß man sein Problem darin aufschreiben, dann muß man den Transformator in die klassische Programmiersprache schreiben, und das am Ende dabei erzeugte Programm muß zumindest in einigen Teilen trotzdem um klassischen Programmcode ergänzt werden. Aber die Arbeit ist eine andere. Der Code, den man schreibt, wird viel dichter, viel interessanter, weil man sonst zeitfressenden wiederholenden Arbeiten nur noch einmal machen muß. Wenn man einen Fehler macht, wird er viel leichter entdeckt, weil er oft an vielen Stellen gleichzeitig auftritt. Viele Änderungen gehen viel schneller – manche zwar langsamer, aber man hat dafür plötzlich das Gefühl, die Sache wirklich verstanden zu haben. Und – die Doku hat man als Abfallprodukt immer einwandfrei und topaktuell.

Also los!


[http://www.codegeneration.net]

[Language-Driven Development|http://www.codegeneration.net/tiki-read_article.php?articleId=68]