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?

## UML is itself a MOF metamodel UML's constructs — Class, Association, Attribute, Operation, and the rules governing how they combine — are themselves defined using MOF's M3 constructs (Class, Property, Operation, DataType). Concretely, UML's `Class` metaclass has properties such as `ownedAttribute` and `isAbstract`, and these are declared the same way any MOF-based metamodel declares its constructs, using MOF's own Class and Property building blocks. This is why any MOF-compliant tool can reflectively introspect, validate, or transform a UML model without UML-specific hardcoded parsing: the tool just walks the metaclass structure generically. ## Two ways to specialize a modeling language - **A Profile** is UML's built-in, lightweight extension mechanism. A Stereotype extends an existing UML metaclass — for example, a stereotype named `Entity` extends Class — and tagged values act like typed properties attached via that stereotype, applied at the M1 level to a specific model element. Applying a profile does not create any new M2 construct; the UML metamodel itself is untouched, so a profile-extended model remains valid plain UML and can still be opened, serialized, and edited by any standard UML/XMI-based tool, even one that doesn't understand the specific profile's meaning. - **Defining a brand-new MOF metamodel** is a different move entirely: it declares wholly new M2 constructs — BPMN's `Task`, `Gateway`, and `SequenceFlow`, for instance — unrelated (or only loosely related) to UML's constructs, which requires bespoke tooling: editors, validators, and serialization support, unless built on a framework like EMF that gives generic tree editors and XMI serialization for any Ecore-defined M2 language for free. ## Why each mechanism exists Profiles exist to let practitioners specialize UML for a domain cheaply, reusing the enormous existing base of UML tools, training, and notations, rather than paying the cost of a bespoke DSL for every specialization need. New metamodels exist because some domains' semantics genuinely don't map cleanly onto UML's object-oriented worldview — BPMN's flow-of-control process semantics is a good example — and forcing them into UML stereotypes would be an abuse of the lightweight mechanism, producing a profile that isn't really a profile. ## The trade-offs The trade-offs run in opposite directions. - **The profile route** is cheap and stays tool-compatible, but semantically weak: the UML metamodel doesn't enforce a domain's real constraints — a stereotype like `Entity` doesn't stop someone from applying it to something structurally incoherent, since the underlying Class metaclass still accepts anything a Class accepts — so a lot of domain rules end up as documentation or external OCL (Object Constraint Language) constraints layered on top, rather than being structurally enforced. - **The new-metamodel route** gives strong, precise, structurally enforced semantics, but comes with expensive tooling and low reuse of the existing UML ecosystem, and it needs its own governance — versioning, backward compatibility — exactly as MOF/UML itself does at the OMG. ## Failure modes - **On the profile side**, the most common failure mode is misusing a profile to encode something that has no coherent mapping onto the extended metaclass, so tools silently allow structurally valid but semantically nonsensical models, because profiles don't prevent misapplication beyond what's explicitly declared in the profile's extension relationships. - **The opposite failure** is building a brand-new metamodel for something a profile could have handled — sinking months into a bespoke editor, validator, and serializer for a DSL that a two-stereotype UML profile with OCL constraints would have solved in a week. ## Real-world examples Real-world examples illustrate both sides. | Language | Mechanism it chose | |---|---| | MARTE (Modeling and Analysis of Real-Time and Embedded systems) and SoaML (Service-oriented Architecture Modeling Language) | OMG-standardized UML profiles that add stereotypes for real-time scheduling and service-oriented concepts respectively, reusing standard UML tooling | | BPMN 2.0 | by contrast, defined as its own independent MOF-based metamodel rather than a UML profile, precisely because process semantics like tasks, gateways, and sequence flows don't map cleanly onto UML's structural and behavioral diagram types |