OCUP 2 Advanced common mistakes
OCUP 2 Advanced · Understand the traps and how to avoid them.
Treating the UML 2.5.1 'Complete UML palette' as if every diagram kind still accepted the UML 1.x element set (e.g., drawing 'implementation class', 'module', or 'subsystem' icons, or using the old 'presentation'/'flow' relationships as first-class model elements).
Candidates studied from older or vendor-flavored material and assume the palette is additive across versions; the exam targets the current unified metamodel where legacy elements were folded into Class, Component, Artifact, or removed.
What to do instead
Rebuild a one-page cross-reference from the UML 2.5.1 spec's abstract syntax: list every concrete Classifier, Relationship, and BehavioralFeature kind, and for each legacy element record its replacement (implementation class -> Component/Artifact with realizations; subsystem -> Component). Drill on which diagram kinds may legally present each element.
Confusing which properties are owned by the Association versus the AssociationEnd (memberEnd vs. ownedEnd vs. navigableOwnedEnd) when answering questions about navigability, aggregation, and association-class attachment.
The names are similar and candidates memorize the diagram notation (open arrow, diamond) without learning the metamodel ownership rules that determine where multiplicity, aggregation, and qualifiers actually live.
What to do instead
For each association in a practice model, redraw it as an instance of Association with explicit ownedEnd and memberEnd links; state in writing which end owns the qualifier, which end carries aggregation, and why a navigable end is not automatically an owned end. Test yourself by deriving the notation from the metamodel rather than the reverse.
Answering questions about large models by reasoning from diagram appearance instead of from the containment tree - e.g., assuming a Package 'contains' elements merely drawn inside its frame, or that a namespace boundary equals a diagram boundary.
The exam stresses 'largest system models', where diagrams are views over a model that no single diagram shows; candidates who think visually misjudge ownership, visibility, and import consequences.
What to do instead
Practice reading models as containment hierarchies: for a given element, trace owner up to the Model, then state its namespace and visibility. Use import/access and package merge questions to force reasoning about the containment tree and the distinction between a diagram frame and a Namespace.
Mixing up the semantics of the behavior classifiers - treating Activity as a kind of StateMachine, or assuming an Operation's method must be an Activity rather than any Behavior - and misapplying the isAbstract/isLeaf/isStatic flags on BehavioralFeatures.
The palette presents Activity, StateMachine, Interaction, and OpaqueBehavior side by side, and candidates learn notation (rounded rectangles, states) without the metaclass constraints that govern how a Behavior can be attached to a BehavioralFeature.
What to do instead
Build a matrix of Behavior subclasses with their key metaclass constraints (e.g., Activity's nodes/edges, Interaction's lifelines/messages, StateMachine's regions) and the rule that a method is any Behavior whose specification is the Operation. Then answer feature-flag questions by checking the metaclass, not the notation.
Assuming MOF and UML are interchangeable - e.g., claiming a UML Class is a MOF Class, or that a UML metamodel can be exchanged directly as an EMOF instance without a transformation.
Both use class-diagram-like notation, and candidates who have only seen UML diagrams do not realize MOF is a separate metametamodel with its own reflective layer and that UML is defined as an instance of MOF.
What to do instead
Draw the four-layer stack (M3 MOF, M2 UML, M1 user model, M0 runtime) and place concrete examples at each layer. Then contrast EMOF and CMOF: which supports associations, multiplicity, and reflection, and what a tool must do to bridge a UML model and a MOF-based metamodel.
Treating fUML as 'UML with an execution engine' and answering that any UML Activity can be executed directly, ignoring fUML's Foundation subset restrictions (e.g., which Activity constructs are excluded or given precise token semantics).
The name suggests a superset, and candidates conflate UML's normative semantics with fUML's executable subset; they miss that fUML defines a specific subset and precise token-flow rules.
What to do instead
Make a two-column list: UML Activity constructs fUML retains versus excludes, plus fUML's token/offer rules for decision, merge, fork, and join nodes. For each, write the execution trace for a small example so you can predict the output of an fUML activity rather than just its diagram.
Confusing Alf (Action Language for fUML) with fUML itself - e.g., answering that Alf defines the execution semantics, or that Alf text is a UML diagram kind rather than a textual surface syntax that maps to fUML activities.
Alf and fUML are usually introduced together, and candidates do not separate the concrete textual syntax from the executable semantic foundation it compiles to.
What to do instead
State the relationship in one sentence you can defend: Alf is a textual action language whose constructs map onto fUML Activity and Action metaclasses. Then trace a short Alf snippet to its fUML activity structure (initial node, actions, control flow) to prove the mapping.
Ignoring the UML Profiles mechanism when asked how UML is extended for a domain, instead proposing new metaclasses or claiming stereotypes are subclasses of the base metaclass.
Candidates default to 'add a class' thinking and miss that Profiles use Extension, Stereotype, and tagged values, and that a stereotype is not a subclass - it is applied to instances of the base metaclass.
What to do instead
Model a small profile: define a Stereotype with an Extension to a base Class, add tagged values, and show how it is applied to a user model element. Then contrast this with a MOF-based metamodel extension and state when each is appropriate (lightweight vs. structural).
Answering questions about model interchange and constraint expression by asserting that XMI and OCL are part of the UML metamodel proper, or misstating which specification owns them relative to MOF and UML.
The exam's second domain explicitly covers 'other specifications in the UML family', and candidates blur the boundaries between UML, MOF, XMI, OCL, fUML, and Alf, so they attribute features to the wrong document.
What to do instead
Create a one-line ownership card for each family specification (what it defines, what it depends on, and one thing it does not define). Use it to answer boundary questions, such as where a constraint's expression language is defined and how a model is serialized for interchange.
Under time pressure, skipping the metamodel cross-check on multi-select questions and choosing answers that are notationally plausible but violate a metaclass constraint (e.g., a Component owning a Port typed by an Interface versus a Class, or a Connector without a compatible role).
The advanced exam mixes notation-level and metamodel-level distractors; candidates who pattern-match on familiar diagrams pick the visually familiar option without verifying the constraint that makes it legal.
What to do instead
Adopt a fixed two-pass routine: first classify each option by the metaclass and constraint it invokes, then eliminate those that violate a stated rule before considering notation. Practice with timed sets of multi-select items where at least one distractor is notationally valid but metamodel-illegal.