OCUP 2 Intermediate common mistakes
OCUP 2 Intermediate · Understand the traps and how to avoid them.
Treating a Port as just a named attribute and omitting its required type and multiplicity, so a composite structure with several ports is drawn without interface-typed ports.
Candidates carry over class-attribute habits; they forget that a Port is a typed property of the classifier whose type is usually an Interface (or a Class), and that multiplicity on a port expresses how many instances can be attached. The exam tests ports together with provided/required interfaces.
What to do instead
For every port, state the type explicitly (often an interface), give multiplicity where attachment multiplicity matters, and pair it with provided (ball) and required (socket) interfaces. Practice redrawing a component with two ports, one requiring an interface the other provides, and verify the direction of each ball/socket.
Confusing Connector kinds: using an assembly connector where a delegation connector is required, or drawing a plain association between parts inside a structured classifier.
Assembly and delegation connectors look similar and both appear in composite structure diagrams. Candidates miss the rule that delegation connects an internal part to the enclosing classifier's port, while assembly connects required to provided interfaces between parts at the same level.
What to do instead
Memorize the orientation rule: delegation goes outward from part to the boundary port of the containing classifier; assembly joins a socket on one part to a ball on another part. When reading a stimulus question, first ask 'does this cross the classifier boundary?' If yes, it is delegation.
Mixing up aggregation and composition, or drawing composition with the diamond on the wrong end, when modeling whole-part structures in a large model.
Both are shared whole-part associations and the notation differs only by filled versus hollow diamond at the whole end. Candidates also forget that composition implies exclusive ownership and lifetime dependency, which affects multiplicity and navigability answers.
What to do instead
Anchor the rule: diamond always touches the whole. Filled diamond = composition (part cannot be shared, lifetime tied to whole); hollow = shared aggregation. For each whole-part question, decide ownership and lifetime first, then place the diamond, then set multiplicity at the part end.
Designing modules with circular package dependencies and then answering that the model is valid, or omitting the «import»/«access» distinction when justifying reuse.
Candidates focus on class-level correctness and overlook package-level dependency direction. They also conflate «import» (public, re-exported) with «access» (private, not re-exported), which is exactly what interoperability questions probe.
What to do instead
Draw a package dependency graph before answering and check for cycles. State the direction of every «import»/«access» arrow (client depends on supplier). Remember «import» makes names visible to importers of the importing package; «access» does not. Remove cycles by introducing an interface package or by inverting a dependency.
Failing to separate interface from implementation when generating interoperating modules: putting operations on a component instead of on its provided interface, or exposing internal classes across module boundaries.
The exam rewards designs where modules couple only through interfaces. Candidates who model behavior directly on components or export concrete classes create tight coupling and cannot answer substitutability and black-box reuse questions correctly.
What to do instead
Model each provided capability as an Interface owned by the supplier; have the component realize it via a port. Export only interfaces and value types from a module package; keep implementation classes in a non-exported subpackage. Verify substitutability by asking whether a second realization of the same interface could replace the first without changing clients.
Ignoring visibility and namespace rules when refining an existing model, e.g., leaving newly added helper operations public or placing reused elements in the wrong package, so the improved model changes the public contract unintentionally.
Improvement tasks tempt candidates to add elements quickly. They forget that adding a public operation or moving a class changes the API and can break existing clients, which is the point of the question.
What to do instead
Before editing, list the model's public surface (public/protected members, exported packages). Make additions private or package-visible unless the requirement demands exposure, and preserve existing qualified names. After the change, diff the public surface and confirm only intended changes appear.
Refactoring by generalization without verifying substitutability: pulling common attributes into a superclass while leaving operations that subclasses cannot honor, or replacing an association with inheritance where the is-a test fails.
Candidates optimize for duplication removal rather than semantic correctness. They also forget Liskov-style substitutability and the constraint that a subclass must not strengthen preconditions or weaken postconditions of inherited operations.
What to do instead
Apply the is-a test explicitly and check every inherited operation against each subclass's contract. Prefer delegation or an interface when only behavior is shared. Where generalization is used, mark it abstract if no instance is meaningful, and record pre/postconditions to confirm none are tightened.
Choosing the wrong diagram kind for a question, e.g., using a Communication diagram to show time-ordered messages, a State Machine to show object collaboration, or omitting the interaction overview when control flow among interactions is asked for.
Candidates learn diagrams in isolation and do not build a selection heuristic. The exam asks model users to pick the view that answers a stakeholder's question, so a technically correct diagram of the wrong kind loses the mark.
What to do instead
Build a decision table: structure (Class, Component, Composite Structure, Deployment, Package, Object) versus behavior (Activity, State Machine, Use Case) versus interaction (Sequence for time order, Communication for links, Timing for state over time, Interaction Overview for control flow among interactions). For each practice question, name the stakeholder question first, then select the diagram.
Describing a diagram's purpose with generic phrases ('shows the system') instead of naming the specific elements, relationships, and the question the view answers for its audience.
Candidates memorize diagram names but not their communicative intent, so explanation answers lack the element vocabulary and audience framing the rubric expects.
What to do instead
For each diagram kind, prepare a one-sentence template: ' shows connected by so that can answer .' Practice applying it to a concrete model fragment, naming at least three element types and two relationship types per answer.
Misapplying multiplicity and role names on associations in complex models, e.g., writing 1..* where 0..* is correct, or omitting role names so the two ends of a self-association are ambiguous.
Multiplicity depends on business rules that candidates skim, and self-associations require distinct role names to be readable. The exam uses large models where ambiguous ends make the answer wrong.
What to do instead
For every association end, state the rule aloud ('can a department exist with no employees?') to choose 0..* versus 1..*. Give both ends of any self-association distinct role names and verify navigability. Re-read the completed association as a sentence to confirm it matches the requirement.