Ziel der domänenspezifischen Modellierung (DSM) ist es, das Abstraktionsniveau in der Softwareprogrammierung weiter anzuheben und eine vollständige Codegenerierung zu ermöglichen. Dabei können Entwickler selbst entscheiden, wie sie ihre Entwicklungstätigkeiten automatisieren wollen. Beim DSM werden die Anwendungen in Modellierungssprachen entworfen. Diese stellen eine Hilfe dar, um zu einem guten Design zu kommen, indem die Designer dazu angehalten werden, die spezifische Architektur und Designregeln zu befolgen, die ihre Domäne von einer anderen unterscheiden. Wenn die abstrakten Designs in Code überführt werden, stellt DMS sicher, dass der Code genauso erzeugt wird, wie ein Experte es normalerweise von Hand tun würde – mit dem Unterschied, dass es 5 bis 10 Mal schneller geht.

Die Schöpfer der UML haben diese Sprache nicht für die Codegenerierung entworfen. Die vergangenen 10 Jahre haben darüber hinaus gezeigt, wie wenig UML für diese Zwecke geeignet ist. Im allgemeinen kommt man mit ihr über das Erzeugen eines Code-Gerippes nicht hinaus. Die Entwickler müssen den Rest der Anwendung – Interaktionen, dynamisches Verhalten, Benutzerinteraktionen usw. – manuell spezifizieren. All diese Aspekte sind, ebenso wie die Architektur mit ihren Regeln, domänenspezifisch. Will man sie effektiv und vollständig in einem grafischen Design erfassen, benötigt man eine domänenspezifische Modellierungssprache.

Domänenspezifisches Vorgehen bedeutet, dass die Konzepte, die man normalerweise benutzt, um ein Produkt in einer bestimmten Domäne zu beschreiben, zu Konzepten der Modellierungssprache werden. Nehmen wir ein einfaches Beispiel aus eine Domäne, die wir alle kennen: das Mobiltelefon. Eine Modellierungssprache, die Konzepte wie „Menü“, „Liste“, „Query“, „SMS senden“ und die in dieser Domäne geltenden Regeln verwendet, ist beim Design von Applikationen für Mobiltelefone wesentlich effizienter als eine Modellierungssprache, die auf Konzepten wie „Objekt“, „Attribut“, „Rückgabewert“ und allgemein gültigen Programmierregeln basiert.

Mit einer solchen maßgeschneiderten Sprache lässt sich eine Applikation mit geringerem Modellierungsaufwand vollständig und exakt spezifizieren. Da in den Modellen alle benötigten Informationen erfasst werden, lässt möglichst vollständiger, qualitativ hochwertiger Code realisieren.

Sieht man sich die Resultate eines Code-Generierungsprozesses an, so wissen die meisten, was sie von Standard-Generatoren zu erwarten haben: Sie erzeugen statische, deklarative Definitionen aus allgemeinen Designs, z. B. Schnittstellen oder Datenbank-Schemata, wie sie seit Jahrzehnten Realität waren. Anders sieht die Situation aus, wenn es darum geht, verhaltensbezogenen, funktionalen Code zu generieren.

In diesem Kontext sind zahlreiche Faktoren zu berücksichtigen: z. B. die Zielsprache, das Programmiermodell und die Speicherbehandlung. Darüber hinaus ändern sich viele Faktoren im Laufe der Zeit, was dazu führt, dass sich auch die Art und Weise der Codegenerierung ändert. Hersteller von Codegeneratoren wissen häufig nicht genug über die spezifischen Anforderungen einer Organisation, um optimalen Code zu generieren; daher ist es nicht verwunderlich, dass viele generierten Code als nicht zufrieden stellend ansehen.

Bei DSM definiert ein Experte im eigenen Unternehmen eine DSM-Sprache und einen Codegenerator, der – wo nötig – um Framework-Code ergänzt wird. Er kapselt sein Wissen, um die Dinge für die anderen zu vereinfachen. Für die Softwareentwicklung bedeutet DSM auch Spezialisierung, da ein Werkzeug gebaut wird, mit dem die Entwickler ihr domänenspezifischen Aufgaben besser erledigen können. Die für den Bau eines solchen Werkzeugs am besten qualifizierte Person ist ein sehr erfahrener Entwickler, von denen es meistens nur ein paar in jeder Firma gibt.

In der letzten Zeit sind einige neue Technologien, wie z. B. domänenspezifische Modellierungswerkzeuge, auf den Markt gekommen, mit deren Hilfe ein solcher Experte innerhalb von ein paar Wochen Werkzeugunterstützung für die firmeneigenen Modellierungssprachen und Codegeneratoren zur Verfügung stellen kann. So lässt sich ein eigenes, maßgeschneidertes Modellierungswerkzeug wesentlich schneller herstellen.

Normalerweise weiß der Experte selbst am besten, was die in der Problemdomäne seines Unternehmens gültigen Konzepte und Regeln sind und wie ein Programm am besten zu implementieren ist. Mit DSM kann er sein Wissen in dem Werkzeug kapseln und den anderen Entwicklern als Gesamtpaket zur Verfügung stellen. Auf diese Art leitet die Modellierungssprache die Entwickler dabei an, ein korrektes Design zu erstellen, da durch das Verankern von Einschränkungen (Constraints) in der Sprache unzulässige bzw. unerwünschte Konstrukte nicht möglich sind.

Weil keine Domäne wie die andere ist, unterscheiden sich auch die Sprachkonzepte und Abstraktionslevel der DSM-Sprachen voneinander. Sprachkonzepte kann der Experte am besten in der Terminologie finden, die in folgenden Bereichen verwendet wird: die Anwendungsdomäne der Firma, die Systemarchitektur, bestehende Systembeschreibungen und Komponenten-Services.

Der in einer Organisation verwendete domänenspezifische Jargon umfasst natürliche Konzepte, die die Domäne auf eine Art und Weise beschreiben, wie sie von den Menschen bereits verstanden wird. Die Menschen denken über Lösungen nicht in einer Programmiersprache nach – daher sollte man es sinnvoller weise vermeiden, eine neue Terminologie einzuführen oder die Mitarbeiter dazu zu zwingen, zwischen zwei verschiedenen Begriffswelten Abbildungen vornehmen zu müssen.

Beim Erzeugen einer DSM-Sprache wird häufig zunächst eine bestimmte Sicht auf die Domäne eingenommen. Diese kann beispielsweise auf der Struktur eines physischen Produkts, dem Look&Feel eines Systems, der Variabilität, Konzepten eines Domänenexperten oder dem zu generierenden Output basieren. Im ersten Moment wird die Definition einer neuen Sprache häufig als eine schwierige Aufgabe empfunden. Wenn ein Entwickler jedoch erst einmal erkannt hat, dass er nur das Wissen über seine Domäne anwenden muss, über das er ohnehin bereits verfügen, erscheint diese Aufgabe gleich wesentlich leichter.

Beim Erstellen eines DSM-Generators wird definiert, wie Modellkonzepte auf Code oder andere Ausgaben abgebildet werden. Aus Sicht der Codegenerierung ist DSM vor allem deshalb attraktiv, weil der Codegenerator vergleichsweise einfach gehalten werden kann. Anders als in vielen Fällen, wo der Generator sicherstellen muss, dass die Eingaben, die er erhält, korrekt sind, erledigen das in DSM bereits die Regeln der Modellierungssprache.

Ziel ist es, den Generator so einfach wie möglich zu halten. Je einfacher der Generator zu Beginn ist, desto einfacher sind spätere Änderungen. Typischerweise erzeugt jedes Symbol aus dem Modell bestimmten festen Code, der die vom Modellierer als Argumente in das Sym-bol eingetragenen Werte beinhaltet.

Geht man einen Schritt weiter, so kann ein Generator auch die Beziehungen zu anderen Modellelementen oder anderen -informationen, wie z. B. Submodellen, zu Modellen, die in anderen Sprachen erstellt wurden, oder zu vorhandenem Bibliothekscode berücksichtigen. Wenn der Generator vollständigen Code erzeugt – ausführbar und von Produktqualität –, sodass nach der Generierung nichts mehr umgeschrieben oder ergänzt werden muss, dann ist dies ein guter Generator. Sicher gibt es Fälle, wo es erforderlich ist, ein kleines Stück Code manuell zu optimieren. Aber das sollte die Ausnahme von der Regel bleiben.

Codegenerierung ist nicht die einzige Stelle, an der Automatisierung stattfindet. Die Stärke von Modellen setzt sich fort, da man Dinge wie Konfigurationsdaten, Testfälle, Simulationsmaterial, Dokumentation, automatisierte Build-Prozesse usw. alle aus derselben Quelle generieren kann. Eine einzige Quelle für mehrere Ziele zu haben, kann sehr nützlich sein: Änderungen müssen nur an einer Stelle vorgenommen werden.

Die domänenspezifische Modellierung lehnt sich eng an die Ziele der modellgetriebenen Entwicklung an, bei der die Entwickler in Modellierungssprachen programmieren. Die Konsequenzen im Überblick:

• Nicht der Code, sondern die Modell werden versioniert: Da Code jederzeit generiert werden kann, gibt es keine Notwendigkeit für eine Versionierung des Quellcodes. Objektdateien werden nicht versioniert, auch nicht während der C-Kompilierung.

• Der generierte Code wird niemals angefasst: Da der generierte Code aus Sicht des Modellierers vollständig ist, muss dieser den Code nicht anfassen. Wenn eine Änderung am generierten Code erforderlich ist, die nicht durch eine Änderung des Modells realisiert werden kann, ist es besser, den Generator, die Modellierungssprache oder Framework-Komponenten zu modifizieren; so können auch andere von dieser Verbesserung profitieren.

• Der generierte Code hat Produktqualität: DSM gibt die vollständige Kontrolle über den zu generierenden Code.

• Testen findet bereits im Entwurfsstadium statt: Dies liegt daran, dass die Sprache die Anwendungsdomäne kennt und es im Idealfall nicht möglich ist, ein Design zu erstellen, das unzulässig ist oder zu schlechter Performance führt. Die für die manuelle Programmierung typischen Fehler entfallen.

• Modelle auf einem höheren Abstraktionslevel vereinfachen die Kommunikation mit dem Kunden erheblich. Darüber hinaus sind sie leichter zu lesen, zu verstehen, im Kopf zu behalten und zu verifizieren als Modelle, die die Domäne mittels programmiersprachlicher Konzepte visualisieren.

Es lässt sich also zusammenfassen, dass DSM die Entwicklung dadurch beschleunigt, dass an Stelle von Codemodellen Produktmodelle verwendet werden. Berichte über Erfahrungen mit DSM aus der Industrie zeigen enorme Verbesserungen hinsichtlich der Produktivität, niedrigere Entwicklungskosten und eine bessere Qualität. Nokia gibt beispielsweise Zahlen an, denen zufolge es mit DSM Mobiltelefone inzwischen bis zu zehn Mal schneller entwickelt; bei der Firma Lucent konnte die Produktivität, abhängig vom Produkt, um das drei- bis zehnfache gesteigert werden.

MetaCase, Tel. +358(0)9 280270

*Juha-Pekka Tolvanen ist Field Application Engineer, Martijn Iseger ist Sales- und Marketing-Manager bei MetaCase, Finnland.