Modellgetriebene Entwicklung als praktischer Leitfaden für deutsche Engineering-Teams

Lange Zeit lief die Spezifikationsarbeit in Engineering-Teams über Word-Dokumente, Excel-Tabellen und ein paar Skripte, die diese Dokumente in etwas verwandelten, das eine Toolchain verarbeiten konnte. Das funktioniert gut, solange der Umfang klein bleibt. Es bricht zusammen, sobald sich Anforderungen vervielfachen, Varianten sich anhäufen und dieselbe Spezifikation mehrere Generatoren bedienen muss, die jeweils ein leicht anderes Eingabeformat erwarten.

Modellgetriebene Entwicklung ist eine Antwort auf dieses Problem. Statt Spezifikationen als Freitext zu schreiben und zu hoffen, dass jeder sie gleich interpretiert, definiert man ein Modell: eine strukturierte Darstellung der Fachdomäne, die eine Maschine lesen, prüfen und weiterverarbeiten kann. Die Spezifikation wird zu Daten mit klaren Regeln, nicht zu Prosa, deren Bedeutung von der Auslegung des Lesers abhängt.

Warum das notwendig wird und keine Option bleibt

Deutsche Engineering-Teams stoßen häufig aus verschiedenen Richtungen auf dieselbe Wand. Spezifikationsdokumente wachsen über den Punkt hinaus, an dem Word-Versionsverläufe oder Excel-Reiter noch etwas konsistent halten können. Varianten vervielfachen sich: Dieselbe Basisspezifikation muss unterschiedliche Fahrzeugplattformen, Märkte oder Hardwarekonfigurationen unterstützen, und welche Variante welche Änderung übernommen hat, lässt sich danach nur noch manuell und fehleranfällig nachvollziehen. Rückverfolgbarkeit soll eine klare Linie von der Anforderung über den Testfall bis zum Ergebnis ziehen, doch diese Linie reißt in dem Moment, in dem jemand eine Tabelle aktualisiert und vergisst, das Dokument drei Systeme weiter unten anzupassen. Und die Konsistenz der Generatoren leidet, weil jeder Generator einzeln gegen seine eigene Interpretation der Quelldaten gebaut wurde, sodass eine kleine Änderung an der Spezifikation einen Generator unbemerkt beschädigen kann, während die anderen unberührt bleiben.

Das ist kein Versagen der Werkzeuge im eigentlichen Sinn. Es ist das, was passiert, wenn dokumentenbasierte Spezifikation über die Größe hinauswächst, für die sie je gedacht war.

Warum JetBrains MPS und DSL-Werkzeuge helfen

Eine domänenspezifische Sprache, aufgebaut auf einer Plattform wie JetBrains MPS, ermöglicht es einem Team, Spezifikationen zu schreiben, die gleichzeitig menschenlesbar und maschinell verarbeitbar sind. Ingenieure arbeiten in einem strukturierten Editor statt in Freitext, sodass das Werkzeug Inkonsistenzen erkennt, bevor sie einen Generator erreichen. Dasselbe zugrunde liegende Modell kann mehrere Ausgaben erzeugen, etwa einen generierten Testfall, ein exportiertes Anforderungsdokument oder eine XML- oder ReqIF-Datei für ein nachgelagertes System, ohne dass diese Ausgaben voneinander abweichen, weil sie alle aus derselben Quelle stammen.

Das ersetzt nicht das technische Urteilsvermögen der Ingenieure. Es nimmt ihnen die wiederkehrende Übersetzungsarbeit ab, durch die die meisten Fehler entstehen, sodass mehr Zeit für die Teile der Spezifikation bleibt, die tatsächliches Nachdenken erfordern.

Wo dieser Ansatz in der Praxis greift

Modellgetriebene Workflows bewähren sich vor allem in einigen klar umrissenen Bereichen. Bei der formalen Testspezifikation erzwingt ein DSL-Editor eine Struktur, die Freitext nicht leisten kann. Bei der Unterstützung der ECU-Testdurchführung müssen Spezifikationen sauber in HiL- oder SiL-Testausführung übersetzt werden, ohne manuelle Nacharbeit. Beim Variantenmanagement kann ein Modell ausdrücken, was sich zwischen Varianten tatsächlich unterscheidet, statt ganze Dokumente zu duplizieren. Bei der Generatorkonfiguration liefert ein einzelnes Spezifikationsmodell konsistente Ausgaben über mehrere Toolchains gleichzeitig. Und in Dokumentations- und Exportworkflows erzeugt dasselbe Modell Word-, Excel-, XML- oder ReqIF-Ausgaben, ohne dass drei getrennte Pflegeaufwände parallel laufen müssen.

Wie man anfängt, ohne alles neu zu bauen

Der häufigste Fehler ist, modellgetriebene Entwicklung als vollständige Ablösung der gesamten Toolchain zu behandeln, nach dem Prinzip alles oder nichts. Das muss sie nicht sein. Ein realistischerer Einstieg besteht darin, einen einzelnen, klar abgegrenzten und schmerzhaften Teil des Spezifikationsprozesses auszuwählen, oft die Testfallgenerierung oder eine Variantenfamilie, die sich häufig ändert, und genau diesen Teil zu modellieren. Erst wenn dieser Teil funktioniert und die Ingenieure mit dem Editor und der Struktur vertraut sind, entscheidet man, ob sich das Modell auf weitere Teile der Toolchain ausweiten lässt.

Das entspricht genau der Art, wie deutsche Engineering-Teams ohnehin mit Risiko in anderen Bereichen umgehen: zunächst in kleinem, begrenztem Umfang validieren, bevor man sich weiter verpflichtet. Für das erste DSL-Modell gilt dasselbe Prinzip.

Wo TAMA Systems India ansetzt

Wir haben die TAMA Test Specification Platform auf Basis von JetBrains MPS aufgebaut, weil wir bei der Entwicklung unserer eigenen Automotive-Testwerkzeuge genau auf diese Probleme gestoßen sind. Der DSL-Editor erzeugt strukturierte, maschinenlesbare Testspezifikationen, die direkt in ECU-TEST, EXAM, Java, Python und C/C++ Testcode generiert werden, und dasselbe Quellmodell exportiert nach ReqIF, XML, HTML und Excel.

Unsere Engineering-Teams bringen praktische Erfahrung in ISO-26262- und ASPICE-orientierten Umgebungen aus dem Automotive- und Embedded-Software-Bereich mit, ergänzt durch JetBrains MPS und DSL-Engineering-Kompetenz, die gezielt um Spezifikations- und Testwerkzeuge herum aufgebaut wurde. Wir behaupten keine Zertifizierung, die wir nicht besitzen. Was wir bieten, ist praktische Vertrautheit mit der Art von Spezifikationsarbeit, die diese Umgebungen verlangen.

Ein praktischer nächster Schritt

Wenn sich Ihr Spezifikationsprozess zunehmend so anfühlt, als werde er nur durch das Erfahrungswissen einzelner Mitarbeiter und ein paar Skripte zusammengehalten, ist das meist ein Zeichen dafür, dass sich ein modellgetriebener Ansatz zu prüfen lohnt, nicht zwingend ein Zeichen, dass die gesamte Toolchain ersetzt werden muss. Nehmen Sie Kontakt auf, wenn Sie besprechen möchten, wo ein DSL-Modell in Ihre aktuelle Umgebung passen könnte.