The model is the source of truth.

In MDSD, a model is a formal, precise description of a system or domain: formal enough to automatically generate code, tests or documentation from it. Unambiguity is ensured by metamodels: they define which concepts exist, which relationships between them are permitted and which rules apply, comparable to a grammar for natural languages.

The notation is independently selectable: graphical, textual or tabular, depending on what suits the domain and team best. Two language families dominate:

• General modelling languages such as UML or SysML are standardised across industries and cover a broad spectrum. For a specific use case, their generic framework is tailored to the respective domain through profiling.
• Domain-specific languages (DSLs) are designed specifically for a concrete domain. They represent exactly its terms and rules. Nothing more and nothing less. A well-scoped DSL rules out entire error classes from the outset.

Whether UML/SysML or DSL is a decision based on domain, team and goal. Both approaches can be combined in the same toolchain.

Two examples make the spectrum tangible:

Textual DSL (Insurance): A domain language in which tariff and premium rules are formulated directly in insurance terms. Domain experts read and review the rules in plain text; the calculation logic is reproducibly generated from them: versionable, diff-able and close to domain reality.

Graphical model (Control system): The behaviour of a traffic light control system as a state machine, with states, time-controlled transitions and safety conditions. The behaviour is understandable at a glance, simulatable and directly transferable into code.

The design of custom textual and graphical languages is the central topic of the Custom Tools area.

The state machine (or statechart) is the most widespread model for behaviour-centric MDSD and the natural model for reactive systems: software that reacts to external events, manages states and triggers actions under defined conditions.

Interactive demo: bicycle light as a statechart

The bicycle light is a classic introductory statechart: a real device that reacts to a single input (a button press) and cycles through several operating modes (off, steady light, flashing). Simple enough to be immediately understandable; complex enough to make the essence of reactive systems tangible. States, transitions, events and guards, all directly explorable, without installation, without a single line of code:

That is precisely what itemis CREATE delivers: model statecharts, simulate interactively and generate code in C, C++, C#, Java, Python and further target languages: deterministic, auditable, platform-independent. In series use at BSH Hausgeräte, MAN and Dräger, from household appliance controls to safety-relevant functionality under ISO 26262.

Briefly: yes, and the combination is stronger than either approach alone.

Generative AI is powerful but statistical. The same prompt generates different outputs, without a guarantee of conformity, traceability or correctness. Precisely the properties that AI structurally lacks (determinism, auditability, reproducible generation) are non-negotiable in embedded and regulated development. Here MDSD delivers what AI cannot.

At the same time, AI is an effective accelerator for MDSD. Concretely in the workflow: requirements texts are transferred by AI into initial model drafts, existing models are explained or checked for consistency, refactorings are suggested. The model space, with its defined semantics, rules and constraints, provides AI with a precise context that free text generation cannot offer. AI suggestions remain limited to valid model constructs; entire error classes are structurally excluded in the model space before a human reviews them.

The decisive step remains with the human: no AI suggestion becomes the basis for generation without domain approval. AI accelerates model building; the model remains the deterministic source of truth; code generation remains reproducible. The three levels complement each other; none replaces the other.

1. MDSD Readiness Assessment & Target Definition

We review development processes, domain structure, target hardware and toolchain landscape and define a shared target picture with measurable KPIs. We clarify which system areas offer the greatest benefit from modelling and generation, and which quality and evidence requirements determine the generation strategy.

2. Methodological Tailoring & Language Design

Selection or design of the appropriate modelling language (UML profile or DSL), definition of core abstractions and generator strategy for the relevant target platforms. This includes the simulation environment for early behavioural validation and the integration of model-based tests into existing build and CI processes.

3. Support in the Pilot Project

We accompany you through a suitable pilot project directly in day-to-day work: technically in modelling, in calibrating code generators and in building a consistent evidence chain: from simulation through automated tests to formal verification. The goal is a productively deployed generator stack that your team can operate independently.

4. Scaling & Roll-out

Extension to further projects, product lines, target platforms and departments. Generator configurations, simulation environments and test frameworks are systematically transferred and adapted.

5. Long-term Support & Maintenance

Further development of generators and modelling languages, adaptation to new target platforms, compilers or standard requirements, and maintenance of simulation and test infrastructure across version cycles. On request, we also take over the modernisation of existing generator stacks and legacy DSLs.