Profile versus MOF Metamodel for a Clinical Pathway Language
A health authority is standardizing clinical pathway models. The first attempt was a UML profile of 300 stereotypes applied to UML activity and class models; two years on it fails in three ways. A pathway may have exactly one entry criterion, but a stereotype cannot narrow or remove the multiplicity of the inherited UML property it extends, so the rule lives only in a PDF. Pathway variants need multiple inheritance among three concepts, and stereotype generalization over different UML metaclasses produces applications that tools validate inconsistently. And the pathway repository must store pathway models with no underlying UML model at all, because they are imported from a statistical pipeline. The repository team requires MOF 2.5.1 conformance and reflective access to the metamodel at runtime; a second team wants a lighter exchange format. All interchange is XMI against a metamodel that must be versioned independently of UML.
1. Decide between extending the UML profile and defining a MOF metamodel. Explain the M0/M1/M2/M3 levels for each option and justify the decision against the three symptoms.
Read the worked answer
Levels first. UML is itself a metamodel (M2) defined in MOF (M3). A profile is a package at M2 that extends UML: each stereotype is an M2 Class with an Extension to one or more UML metaclasses, and a stereotype application is an M1 element attached to an M1 UML element. A MOF metamodel for pathways is also M2, but it is not a UML extension: its instances (individual pathways) are M1, and there is no UML model underneath.
Decision criteria:
- Profile if the DSL is a UML variant, models must remain UML models (existing UML tools, UML validation and UML XMI keep working), and the added semantics fit into stereotypes plus tagged values plus constraints.
- MOF metamodel if you need your own metaclasses with their own associations, multiplicities and multiple inheritance; if models must exist with no UML base; if the abstract syntax differs structurally from UML rather than merely annotating it.
The authority's three symptoms all point to MOF: a multiplicity cannot be narrowed by a stereotype; stereotype generalization across different metaclasses is ambiguous when an element is both an Activity and a Class (which extension applies?); and a repository importing non-UML pathways cannot use stereotype applications at all.
Migration need not be all-or-nothing: keep the profile for UML-facing teams and define the MOF metamodel as the normative abstract syntax with a documented mapping. But the normative one must be MOF, because only it can enforce "exactly one entry criterion" as a structural multiplicity.
2. The repository requires MOF 2.5.1 conformance and reflective access; the second team wants a light exchange format. Explain EMOF versus CMOF and recommend what to publish as normative.
Read the worked answer
EMOF and CMOF are the two MOF 2.5.1 compliance points, and the choice is driven by the constructs the metamodel uses, not by tool fashion.
EMOF (Essential MOF) covers the static structure: Packages, Classes, Properties with simple multiplicities and types, simple binary Associations, DataTypes, Enumerations, PrimitiveTypes. It is the smaller, easier-to-exchange subset and serializes without reflective gymnastics.
CMOF (Complete MOF) adds the full UML-class metamodelling machinery: subsetting and redefinition of properties, derived unions, association classes and n-ary associations, and full reflective access, including introspecting the metamodel at runtime.
CMOF is required if the pathway metamodel uses property redefinition (for example VariantPathway redefining entryCriterion to 1..1 or narrowing a type), derived unions across pathway kinds, or if the repository must build and query the metamodel reflectively - which the repository team explicitly demands.
Compatibility runs one way: a CMOF-capable repository can consume an EMOF metamodel, but an EMOF-only tool cannot represent redefinition or subsetting and will silently flatten them into plain properties, which is indistinguishable from a modelling error downstream.
Recommendation: publish the normative metamodel as CMOF. Optionally publish an EMOF projection for the light-exchange team, together with an explicit loss list (which redefinitions and derived unions are flattened) and a rule that the projection is never the source of truth. The moment someone needs a derived union, a projection and the normative metamodel diverge - plan for that divergence instead of discovering it in production.
3. For the rule "exactly one entry criterion per pathway", show what a profile can and cannot do, and contrast it with the MOF metamodel solution.
Read the worked answer
Profiles cannot change the base metamodel. A stereotype's properties are added to the stereotype, not to the base metaclass; multiplicities and navigation of the extended UML metaclass's own properties are fixed by UML and cannot be narrowed, removed, or made mandatory. So "exactly one entry criterion" cannot be structural in a profile.
What a profile can do:
- Attach a constraint: an OCL Constraint owned by the stereotype requiring
self.entryCriterion->size() = 1, evaluated when the stereotype is applied. It is checked, not enforced by the metamodel; a model that violates it can exist until validation runs, and a tool that skips validation accepts it. - Introduce a stereotype property with multiplicity 1 instead of the base property. This works only if modellers are forbidden to use the base property, which is fragile across tools and easily bypassed.
In the MOF metamodel the rule is structural: define Pathway::entryCriterion with multiplicity 1..1 (and the opposite end 1..*), so an instance lacking an entry criterion cannot be created or loaded at all. That is the distinction the exam is testing: profile = constraints layered on UML; MOF = new abstract syntax with its own cardinalities and associations.
Recommendation: state the rule once in OCL, reference it from the stereotype for UML-facing work, and make it structural in the MOF metamodel. Keep both texts in the same repository so that a change to one is a change to the other; otherwise the profile's constraint and the metamodel's multiplicity will drift and the two populations of models will disagree about what a valid pathway is.