skip to content

MDA and Metamodels

9 roadmaps5 questions

OMG's Model Driven Architecture and its metamodeling stack from M0 to M3, with UML as the modeling language and conformance relating each level to the one above. It is the formal backbone behind the idea that a model can be a specification.

part ofSoftware design & architectureoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What is OMG's Model Driven Architecture (MDA), and what is the difference between a Platform-Independent Model (PIM) and a Platform-Specific Model (PSM)?

level: juniorimportance: must knowfreq 55%

answer

  1. PIM before PSM before code
  2. protected regions save hand edits
  3. platform churn insurance
  4. AndroMDA/oAW era tools
  5. narrow modern descendants (OpenAPI codegen)

basics

~20 s

MDA is a way of building software by first drawing a model of what the system does, ignoring the technology, then turning that model into one tied to a specific technology (like Java or a database), and finally generating code from it.

solid answer

~30 s

MDA is an OMG standard that separates business/functional design from technology implementation. A Platform-Independent Model (PIM) captures system behavior and structure without referencing any specific technology (no Java, REST, or SQL mentioned). A Platform-Specific Model (PSM) is derived from the PIM by adding platform detail, e.g., a PIM class becomes a PSM class with JPA annotations and Spring stereotypes. Tooling then generates code, or partial code, from the PSM. The goal is to isolate business logic from platform churn so the PIM survives when the target platform changes.

go deeper

for a junior

Can state that MDA separates what the system does from what tech it runs on, and can roughly say PIM comes before PSM before code.

for a middle

Can describe the PIM to transformation to PSM to code pipeline in order, and name at least one purpose such as porting to a new platform.

for a senior

Can discuss the protected-region and regeneration problem concretely, and can argue about when the PIM investment pays off versus when it doesn't for a given project.

for a principal

Can weigh MDA's historical adoption track record against a project's specific situation and recommend for or against it, including naming narrower modern alternatives.

## The pipeline in three artifacts **Model Driven Architecture (MDA)** is an OMG standard, first published in 2001, whose central idea is to separate what a system does from how it is implemented on any particular technology stack. The mechanism strings three artifacts into a pipeline. 1. **The PIM.** First, architects build a Platform-Independent Model (PIM): a formal model, typically expressed in UML constrained to a business/domain vocabulary, that describes entities, behavior, and relationships without ever naming a specific technology. 2. **The transformation.** Second, a transformation step (manual, template-driven, or using a transformation language such as QVT — Query/View/Transformation) maps PIM elements onto platform concepts to produce a Platform-Specific Model (PSM): the same `Order/Customer` domain, now expressed with JPA entities, Spring repositories, or WSDL operations, depending on the chosen target. 3. **The generated code.** Third, code generators turn the PSM into source artifacts, and a developer fills in the platform-specific logic no model can practically capture. ## Why it exists MDA exists to solve a recurring pain in long-lived enterprise systems: business logic and domain knowledge are expensive to design and validate, but the technology platforms they run on churn far faster. By keeping the PIM free of platform detail, you retarget the same model to a new platform by writing a new PIM-to-PSM mapping instead of re-deriving business logic from scratch. It also promises **traceability**: because the PSM and code are derived, not hand-designed, changes to business rules flow from a single source of truth rather than being duplicated and drifting across multiple hand-maintained codebases. ## The trade-offs The trade-offs are real on both sides. - **In favor:** for organizations that genuinely ship the same domain model to multiple platforms, the PIM investment pays for itself, and the discipline of writing a truly platform-neutral model forces cleaner domain design. - **Against:** building and maintaining a correct PIM, plus the transformation rules, plus the generators, is itself a large upfront investment that many projects never earn back, especially when there is really only one target platform. - **'Platform independent' is also aspirational** rather than absolute — a PIM that assumes strict relational integrity or synchronous request/response semantics is already leaking assumptions from a class of platforms, even if it names none specifically. ## Failure modes - **Hand edits and regeneration.** The most common failure mode shows up after code generation: developers need logic the model can't express — custom validation, performance tuning, edge cases — so they hand-edit the generated PSM or source files. When the PIM later changes and the team regenerates, those hand edits are silently overwritten unless the toolchain supports protected regions, partial classes, or a merge step. Teams that skip this discipline either lose work on every regeneration or, more commonly, stop regenerating altogether — at which point the 'generated' code quietly becomes hand-maintained, the PIM goes stale, and the promised single source of truth is gone in practice. - **Scope creep in the PIM.** A second failure mode is scope creep in the PIM: without discipline, architects start encoding platform assumptions into the 'platform-independent' model to make the generator produce the code they want, defeating the separation MDA was meant to provide. ## Where it actually landed In practice, full-stack MDA saw real but narrow adoption: 2000s-era tools like AndroMDA (UML-to-Java/Hibernate/Spring) and openArchitectureWare, and heavier CASE suites from IBM Rational and Compuware, targeted exactly this pipeline, and it found genuine traction in regulated, model-heavy domains such as telecom (via TeleManagement Forum specifications) and some avionics/automotive model-based development. Mainstream web and enterprise development largely rejected the full pipeline as too heavyweight for its payoff, and today MDA's core idea survives mostly in narrower, purpose-built descendants — OpenAPI/Swagger-driven codegen, GraphQL schema-first codegen, and Kubernetes Custom Resource Definitions — which keep 'model as source of truth, generate the rest' without OMG's full formal metamodeling apparatus.

  • Who or what performs the PIM-to-PSM transformation, and can it be fully automated?
    It is done via transformation languages such as QVT (Query/View/Transformation) or template-based generators applying architect-defined mapping rules. For simple, well-understood platforms it can be largely automated; for anything involving business-specific optimization or unusual platform idioms it usually needs manual tuning, which is why the PSM often ends up partly hand-maintained in practice.
  • What happens when a developer hand-edits generated code and then the PIM changes?
    Regenerating from the updated model overwrites the hand edits unless the toolchain supports protected regions, partial classes, or a merge step. Teams that skip this discipline either lose their manual fixes on every regen or stop regenerating altogether, at which point the model silently goes stale.
  • Why did full MDA not become the mainstream way to build software?
    Most projects only ever target one platform and change primarily through new features, so the 'insurance' against platform churn rarely paid out, while the tooling and modeling-discipline cost was certain and immediate. Tooling was also expensive and inconsistent across 2000s vendors, pushing many teams toward simpler template-based generation or abandoning the pipeline entirely.

An architectural blueprint (PIM) versus site-specific construction drawings adapted to local building codes and materials (PSM) versus the finished building (the running code).

saying these in an interview costs you the question

  • Treats PIM and PSM as just two names for the same UML diagram with no real distinction
  • Claims code generation from a PSM is always fully automatic with zero manual coding needed
  • Cannot explain what happens to hand-edited generated code when the model changes and is regenerated
  • Believes platform independent means the PIM has literally zero implicit assumptions about any platform
  • Cannot name any real trade-off or reason a team might skip the full MDA pipeline

context

resolving links…

open as a page

OMG's Meta Object Facility (MOF) defines a four-layer metamodeling stack, M0 through M3. What does each layer represent, and how does UML fit into this stack?

level: middleimportance: must knowfreq 45%

basics

~20 s

MOF is a stack of four levels, like Russian nesting dolls: M0 is the real data at runtime, M1 is a model of it (like a UML diagram), M2 is the language used to draw that diagram (UML's rules), and M3 is the top rule-set (MOF) that even defines UML's own rules and defines itself.

open as a page

Where do PIM and PSM sit in the M0–M3 MOF stack, and what does a QVT-based PIM-to-PSM transformation actually operate on?

level: seniorimportance: must knowfreq 35%

basics

~20 s

PIM and PSM are both just models sitting at the same level in the stack, built using rules like UML's. A transformation tool reads the PIM according to those rules and writes out a PSM according to a possibly different set of platform rules, using a defined mapping between the two.

open as a page

UML is itself defined as a MOF metamodel. What does that mean concretely, and how does extending UML via a Profile differ from defining a brand-new MOF metamodel?

level: middleimportance: should knowfreq 28%

basics

~20 s

UML's own rules, like what a Class or Association is, are written using MOF's building blocks. If you just need to tag extra info onto UML diagrams, you use a lightweight Profile, like stickers on a form. If you need a whole new kind of diagram with its own rules, you define a brand-new metamodel instead.

open as a page

MDA promised that a platform-independent model plus automated transformations would insulate business logic from platform churn and reduce cross-platform maintenance cost. Given that promise, why did full-pipeline MDA see only narrow industry adoption, and under what conditions would you actually reach for it today?

level: principalimportance: should knowfreq 28%

basics

~20 s

Building and maintaining the models, transformation rules, and generators cost more than most teams ever got back, because most software only ever targets one platform and changes more through new features than through swapping technology — so the insurance MDA sold rarely paid out. It's worth it mainly for large, long-lived systems that genuinely target multiple platforms or where regulators demand traceable models.

open as a page