Skip to content

Model-Driven Engineering

Make metamodel-conformant models primary engineering artifacts and use explicit transformations to derive, synchronize, analyze, and generate implementation artifacts across abstraction and platform boundaries.

Version
v2 · 2026-09-06 · History
Domain-specific #
2290
Origin domain
computer science
Subdomain
software engineering
Aliases
MDE, Model-driven development, Model-driven software engineering

Core Idea

Model-Driven Engineering (MDE) is an engineering approach in which explicit models are primary lifecycle artifacts rather than disposable documentation, and defined transformations connect those models to other models, code, configuration, tests, analyses, deployment descriptions, or documentation. A model is expressed in a language whose abstract syntax and well-formedness rules are governed by a metamodel or equivalently precise language definition. The approach is present when engineering decisions are made, checked, and propagated through those model relations—not whenever a developer happens to draw a diagram.

Scope of Application

Model-Driven Engineering is literal where structured models and explicit transformations govern the production, consistency, analysis, and evolution of software or system artifacts.

  • Domain-specific software. Languages encode domain concepts and generators produce framework or platform artifacts.
  • Platform migration. Platform-independent intent is transformed into multiple platform-specific realizations under controlled mappings.
  • Embedded systems. Behavioral, timing, interface, and deployment models feed simulation, code generation, and verification.
  • Systems engineering. Cross-discipline models coordinate requirements, architecture, behavior, interfaces, and analysis artifacts.
  • Data engineering. Schemas and mappings generate storage, integration, validation, and interface artifacts.
  • Product lines. Feature and variability models configure related generated products.
  • Modernization. Existing artifacts are parsed into models, transformed, and regenerated with explicit information-loss boundaries.
  • Continuous integration. Model validation and generation become repeatable build steps with versioned transformations.

Clarity

Name the model kinds, languages, metamodel versions, semantic domains, abstraction levels, source of truth, transformations, directionality, trace format, generated/manual ownership, validation rules, and regeneration policy. Distinguish model-to-model from model-to-text transformation and endogenous from language-changing transformation. State whether mappings preserve semantics, refine nondeterminism, or merely translate syntax. Version models, metamodels, and transformation code together or document migration. Do not claim platform independence without listing the assumptions still embedded in the supposedly independent model.

Manages Complexity

Software platforms expose accidental detail that obscures domain intent and multiplies repeated implementation work. MDE manages this by capturing stable concerns in a higher-level language, separating viewpoints and platforms, and automating recurrent mappings. The same domain decision can then flow into code, tests, configuration, and documentation with traceable consistency. Complexity moves rather than disappears: metamodels become compatibility contracts, transformations become substantial programs, debugging crosses abstraction levels, and generated code can be unreadable or semantically leaky.

Abstract Reasoning

  1. Identify domain decisions currently scattered across implementation artifacts. 2. Define a modeling language and metamodel that express those decisions without premature platform detail. 3. Separate viewpoints and abstraction levels while declaring their consistency relations. 4. Design transformations with explicit source, target, preconditions, and semantic obligations. 5. Validate model conformance and domain constraints before generation. 6. Generate or synchronize downstream artifacts while preserving element-level trace links.

Knowledge Transfer

The strict parent is Transformation. MDE depends on rule-governed mappings from models to models or other engineering artifacts while preserving declared meaning, constraints, and trace relations. Transformation supplies the portable input–mapping–output–invariant skeleton. The domain residual is metamodel conformance, primary model status, abstraction/viewpoint structure, generation, synchronization, and lifecycle governance. Representation is necessary but insufficient because ordinary modeling may never drive another artifact.

Relationships to Other Abstractions

Local relationship map for Model-Driven EngineeringParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Model-DrivenEngineeringDOMAINPrime abstraction: Transformation — is a kind ofTransformationPRIME

Current abstraction Model-Driven Engineering Domain-specific

Parents (1) — more general patterns this builds on

  • Model-Driven Engineering is a kind of Transformation Prime

    Transformation is the strict parent by composition/presupposition because MDE's defining work is explicit model-to-model and model-to-artifact mapping under declared semantic and traceability obligations.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Model-Driven Engineering sits in a sparse region of the domain-specific corpus (89th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Design Representation & Process Control (5 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08