MDSD (Modellgetriebene Softwareentwicklung)
MDSD (Modellgetriebene Softwareentwicklung, engl. Model-Driven Software Development) ist ein Entwicklungsansatz, bei dem formale Modelle die primären Artefakte der Softwareentwicklung sind. Aus den Modellen wird Quellcode automatisiert generiert, statt ihn von Hand zu schreiben — reproduzierbar, konsistent und unabhängig von der Zielplattform.
Wie funktioniert MDSD?
Kern des Ansatzes ist die Umkehrung der üblichen Rollenverteilung: Das Modell ist nicht Dokumentation des Codes, sondern der Code ist eine abgeleitete Größe des Modells. Ein Modell beschreibt die fachlich relevanten Aspekte eines Systems — Struktur, Verhalten, Regeln — formal genug, dass ein Generator daraus automatisiert Quellcode, Konfigurationen, Schnittstellen oder Tests erzeugen kann. Welche Elemente und Beziehungen in einem Modell erlaubt sind, legt ein Metamodell fest; als Notation dienen standardisierte Sprachen wie UML oder eigens entworfene domänenspezifische Sprachen (DSLs).
In der Praxis ergänzen sich zwei Ausprägungen: Die architekturzentrierte MDSD modelliert Struktur, Komponenten, Schnittstellen und Datenmodelle eines Systems. Die verhaltenszentrierte MDSD modelliert das dynamische Verhalten, typischerweise über Zustandsautomaten, Sequenzen oder Regeln.
Welche Vorteile bietet MDSD?
- Reproduzierbarkeit: Aus demselben Modell entsteht mit demselben Generator immer derselbe Code — deterministisch, versionierbar und nachvollziehbar. Das ist die Grundlage für Nachweisführung in regulierten Entwicklungsprozessen, etwa nach ISO 26262 oder DO-178C.
- Konsistenz: Coding-Richtlinien und Architekturvorgaben werden vom Generator automatisch eingehalten, statt in jedem Handgriff neu erkämpft zu werden.
- Frühe Fehlererkennung: Formale Modelle lassen sich validieren, simulieren und testen, bevor die erste Zeile Zielcode existiert — auch ohne verfügbare Zielhardware.
- Plattformunabhängigkeit: Dasselbe Modell kann über austauschbare Generatoren in verschiedene Zielsprachen und Plattformen überführt werden. Wechselt die Zielarchitektur, wird der Generator angepasst, nicht die fachliche Spezifikation.
- Gemeinsame Fachsprache: Domänenexperten, Architekten und Entwickler arbeiten am selben Artefakt statt an separaten, inkonsistenten Interpretationen.
Wo liegen die Grenzen?
MDSD ist eine Investition: Modellierungssprache, Metamodell und Generator müssen entworfen, gepflegt und im Team verankert werden. Dieser Aufwand amortisiert sich dort, wo Strukturen wiederkehren — bei Produktlinien mit vielen Varianten, langen Lebenszyklen oder mehreren Zielplattformen. Für einmalige, kleine Anwendungen ohne Wiederholungsanteil steht der Aufwand in keinem Verhältnis zum Nutzen. Zudem verlagert MDSD Komplexität: Wer den Generator besitzt, braucht Know-how in Sprachdesign und Generatorentwicklung, das nicht in jedem Team vorhanden ist. Und modelliert wird nur, was sich formalisieren lässt — hochgradig individuelle Einzellogik bleibt handgeschriebener Code, der sich über definierte Schnittstellen mit dem generierten Code verbindet.
Abgrenzung: MDSD, MDA und MBSE
Die Begriffe werden oft vermischt. MDA (Model Driven Architecture) ist die standardisierte Ausprägung der Object Management Group (OMG) mit festgelegten Modellebenen (CIM, PIM, PSM) und UML als Notation — eine spezifische Umsetzung der allgemeineren MDSD-Idee. MBSE (Model-Based Systems Engineering) betrachtet das Gesamtsystem über Disziplinen hinweg, inklusive Hardware, Anforderungen und Tests; MDSD ist der softwarespezifische Teil dieser Betrachtung.
MDSD in der Praxis: Embedded und regulierte Entwicklung
Seinen größten Nutzen entfaltet MDSD dort, wo mehrere Anforderungen zusammentreffen: eingebettete Systeme mit wechselnder Zielhardware, hohe Variantenvielfalt, lange Produktlebenszyklen und Nachweispflichten aus Sicherheitsnormen. Deterministisch generierter Code hält Richtlinien wie MISRA C automatisch ein, der Generator selbst kann qualifiziert werden, und die Traceability zwischen Modellelementen und generierten Artefakten entsteht als Nebenprodukt der Generierung — eine Anforderung, die in ISO-26262- und ASPICE-Projekten sonst mühsam manuell hergestellt werden muss.