Das Modell ist die Quelle der Wahrheit.

Ein Modell ist in der MDSD eine formale, präzise Beschreibung eines Systems oder einer Domäne, formal genug, um daraus automatisiert Code, Tests oder Dokumentation zu erzeugen. Die Eindeutigkeit wird durch Metamodelle sichergestellt: Sie legen fest, welche Konzepte existieren, welche Beziehungen zwischen ihnen erlaubt sind und welche Regeln gelten, vergleichbar einer Grammatik für natürliche Sprachen.

Die Notation ist davon unabhängig wählbar: grafisch, textuell oder tabellarisch, je nachdem, was für die Domäne und das Team am besten passt. Zwei Sprachfamilien dominieren:

• Allgemeine Modellierungssprachen wie UML oder SysML sind branchenübergreifend standardisiert und decken ein breites Spektrum ab. Für einen konkreten Einsatzzweck wird ihr generischer Rahmen per Profilierung auf die jeweilige Domäne zugeschnitten.
• Domänenspezifische Sprachen (DSLs) werden gezielt für eine konkrete Domäne entworfen. Sie bilden genau deren Begriffe und Regeln ab, nicht mehr und nicht weniger. Eine gut geschnittene DSL schließt ganze Fehlerklassen von vornherein aus.

Ob UML/SysML oder DSL ist eine pragmatische Entscheidung nach Domäne, Team und Ziel; beide Ansätze lassen sich in derselben Toolchain kombinieren.

Zwei Beispiele machen das Spektrum greifbar:

Textuelle DSL (Versicherung): Eine fachliche Sprache, in der Tarif- und Beitragsregeln direkt in Versicherungsbegriffen formuliert werden. Fachexperten lesen und prüfen die Regeln im Klartext; daraus wird reproduzierbar die Berechnungslogik generiert: versionierbar, diff-bar und nah an der fachlichen Realität.

Grafisches Modell (Steuerung): Das Verhalten einer Ampelsteuerung als Zustandsautomat, mit Zuständen, zeitgesteuerten Übergängen und Sicherheitsbedingungen. Das Verhalten ist auf einen Blick verständlich, simulierbar und direkt in Code überführbar.

Der Entwurf eigener textueller und grafischer Sprachen ist zentrales Thema des Bereichs Custom Tools.

Der Zustandsautomat (bzw. das Statechart) ist das verbreitetste Modell für verhaltenszentrierte MDSD und das natürliche Modell für reaktive Systeme: Software, die auf externe Ereignisse reagiert, Zustände verwaltet und unter definierten Bedingungen Aktionen auslöst.

Interaktiver Demo: Fahrradlicht als Statechart

Das Fahrradlicht ist ein klassisches Einsteiger-Statechart: ein reales Gerät, das auf einen einzigen Input (den Tastendruck) reagiert und dabei zwischen mehreren Betriebsmodi wechselt (Aus, Dauerlicht, Blinken). Einfach genug, um sofort verständlich zu sein; komplex genug, um das Wesentliche reaktiver Systeme greifbar zu machen. Zustandsübergänge, Events und Guards sind direkt erlebbar, ohne Installation, ohne eine Zeile Code:

Genau das ist, was itemis CREATE leistet: Statecharts modellieren, interaktiv simulieren und daraus Code in C, C++, C#, Java, Python und weiteren Zielsprachen generieren. Deterministisch, auditierbar, plattformunabhängig. Im Serieneinsatz bei BSH Hausgeräte, MAN und Dräger, von Hausgeräte-Steuerungen bis zu sicherheitsrelevanter Funktionalität nach ISO 26262.

Kurz: Ja, und die Kombination ist stärker als jeder Ansatz allein.

Generative KI ist mächtig, aber statistisch. Dasselbe Prompt erzeugt unterschiedliche Ausgaben, ohne Garantie auf Konformität, Nachvollziehbarkeit oder Korrektheit. Genau die Eigenschaften, die KI strukturell fehlen (Determinismus, Auditierbarkeit, reproduzierbare Generierung) sind in eingebetteter und regulierter Entwicklung nicht verhandelbar. Hier liefert MDSD, was KI nicht kann.

Gleichzeitig ist KI ein wirkungsvoller Beschleuniger für MDSD. Konkret im Workflow: Anforderungstexte werden durch KI in erste Modellentwürfe überführt, bestehende Modelle werden erklärt oder auf Konsistenz geprüft, Refactorings werden vorgeschlagen. Der Modellraum (mit seiner definierten Semantik, seinen Regeln und Constraints) liefert KI dabei einen präzisen Kontext, den freie Textgenerierung nicht bieten kann. KI-Vorschläge bleiben auf valide Modellkonstrukte beschränkt; ganze Fehlerklassen sind im Modellraum strukturell ausgeschlossen, bevor ein Mensch reviewt.

Der entscheidende Schritt bleibt beim Menschen: Kein KI-Vorschlag wird ohne fachliche Freigabe zur Generierungsgrundlage. KI beschleunigt die Modellbildung; das Modell bleibt die deterministische Quelle der Wahrheit; die Code-Generierung bleibt reproduzierbar. Die drei Ebenen ergänzen sich, keine ersetzt die andere.

1. MDSD Readiness Assessment & Zieldefinition

Wir reviewen Entwicklungsprozesse, Domänenstruktur, Zielhardware und Werkzeuglandschaft und definieren ein gemeinsames Zielbild mit messbaren KPIs. Dabei klären wir, welche Systembereiche den größten Nutzen durch Modellierung und Generierung bieten und welche Qualitäts- und Nachweisanforderungen die Generierungsstrategie bestimmen.

2. Methodisches Tailoring & Sprachdesign

Auswahl oder Entwurf der geeigneten Modellierungssprache (UML-Profil oder DSL), Definition der Kernabstraktionen und Generator-Strategie für die relevanten Zielplattformen. Dazu gehören Simulationsumgebung für frühe Verhaltensvalidierung sowie die Integration modellbasierter Tests in bestehende Build- und CI-Prozesse.

3. Begleitung im Pilotprojekt

Wir begleiten Sie bei einem passenden Pilotprojekt direkt im Alltag: fachlich bei der Modellierung, bei der Kalibrierung der Code-Generatoren sowie beim Aufbau einer durchgängigen Absicherungskette: von der Simulation über automatisierte Tests bis zur formalen Verifikation. Ziel ist ein produktiv eingesetzter Generator-Stack, den Ihr Team eigenständig betreiben kann.

4. Skalierung & Roll-out

Ausweitung auf weitere Projekte, Produktlinien, Zielplattformen und Abteilungen. Generator-Konfigurationen, Simulationsumgebungen und Testframeworks werden systematisch übertragen und angepasst.

5. Langfristige Begleitung & Maintenance

Weiterentwicklung von Generatoren und Modellierungssprachen, Anpassung an neue Zielplattformen, Compiler oder Normanforderungen sowie Pflege von Simulations- und Testinfrastruktur über Versionszyklen hinweg. Auf Wunsch übernehmen wir auch die Modernisierung gewachsener Generator-Stacks und Legacy-DSLs.