Other meanings of Model-Driven Engineering
Software engineering methodology
Model-Driven Engineering is a software engineering methodology using models as primary artifacts. Models represent structure, behavior, requirements, or deployment knowledge at levels of abstraction chosen for a development task; tools then analyze, transform, validate, or generate other models and implementation artifacts. The approach includes, but is broader than, the Object Management Group's Model-Driven Architecture, which distinguishes computation-independent, platform-independent, and platform-specific models.1
Model-Driven Engineering treats models as central development artifacts rather than as disposable sketches. A model is a deliberately simplified representation of a system, while a metamodel defines the concepts, relationships, and constraints that make a modeling language precise. The distinction supports automated checking and repeatable processing instead of relying solely on informal diagrams.
The methodology commonly combines a domain-specific language, model editors, constraints, transformation engines, and generators. The Unified Modeling Language remains a widely used general-purpose notation, but MDE also supports specialized languages for areas such as telecommunications, automotive control, business processes, and hardware design. Its intellectual roots include computer-aided software engineering, object-oriented analysis, formal methods, and language engineering.2
The typical MDE workflow moves from domain knowledge to models, then from models to validated designs, generated artifacts, or further models. Model-to-model transformations revise or reconcile representations; model-to-text transformations produce source code, configuration, tests, documentation, or deployment descriptions. Manual code can coexist with generated code when clear ownership and regeneration rules are established.
Model-Driven Architecture emphasizes separating platform-independent models from platform-specific models and promotes standards such as the Meta-Object Facility and Object Constraint Language.13 Other variants prioritize executable models, domain-specific modeling, or model-based systems engineering. No single process is mandatory: teams may apply MDE to a complete product line or only to a difficult subsystem.
MDE can improve consistency by deriving multiple artifacts from a shared representation, and it can make domain rules visible to specialists who are not experts in implementation languages. Automated validation may detect structural or semantic errors earlier, while generators can reduce repetitive work and preserve organizational conventions. These advantages are strongest when the domain is stable enough to justify investment in languages, tooling, and transformations.4
The costs are substantial. Teams must maintain metamodels, transformation logic, generators, version compatibility, traceability, and debugging techniques for artifacts that may not be written directly by developers. Poor abstractions can conceal important implementation behavior, and generated code can be difficult to customize or diagnose. Research therefore treats usability, scalability, integration with agile work, and long-term tool evolution as central engineering problems rather than secondary concerns.5
Model repositories can serve as collaboration and analysis infrastructure, not merely as sources for code generation. Versioning models, comparing their semantic changes, maintaining transformation traces, and checking conformance between models are distinct technical tasks that become important in large projects.
The Eclipse Modeling Framework helped popularize a practical ecosystem in which metamodels can define Java APIs, editors, serializers, and reflective representations.6 MDE also reaches beyond conventional application software: models may describe safety cases, cyber-physical behavior, variability in software product lines, or deployment topologies. An edge case arises when generated artifacts must meet certification or regulatory demands; generation then requires qualification evidence, reproducible builds, and traceability, not merely syntactic correctness. These concerns explain why model governance and tool-chain assurance can matter as much as the modeling notation.
Terminology varies across research communities: model-driven development, model-driven software engineering, and model-driven engineering are often overlapping labels, while Model-Driven Architecture is a specific OMG approach within the broader field.
Help improve the encyclopedia. Reports go straight to the site manager.