OCUP 2 Foundation common mistakes
OCUP 2 Foundation · Understand the traps and how to avoid them.
Treating a state machine as if it were an activity diagram: drawing states as rounded rectangles that contain actions and placing decision diamonds with guard labels between them, then answering questions about 'states' by pointing at those diamonds.
Activity and state machine notation overlap visually (rounded rectangles, diamonds, arrows), and candidates who learned flowcharts first map every diamond to a decision and every box to a step. UML gives these two diagrams distinct semantics: state machine vertices are states with entry/exit/do behaviours and transitions triggered by events with guards and effects; activity nodes are actions, decisions, merges, forks and joins controlled by tokens.
What to do instead
Before answering, classify the node types: a diamond with one incoming and multiple guarded outgoing edges in an activity is a decision; in a state machine, branching is done on transitions out of a state with [guard] labels, and there is no decision pseudostate for that purpose. Memorize the state machine pseudostates (initial, final, entry point, exit point, choice, junction, terminate, shallow history, deep history) separately from activity nodes (initial node, final node, flow final, decision, merge, fork, join, send/receive signal, accept event).
Reading a sequence diagram top-to-bottom as time and assuming messages lower on the page happen later, and assuming lifelines are ordered left to right by importance or creation order.
Sequence diagrams are the most familiar UML diagram to most candidates, so they are read casually. In UML, time runs downward but message ordering is defined by the vertical sequence of occurrences on each lifeline, and horizontal order carries no semantic meaning. Candidates also misread a message arrow that starts partway down an activation bar as a nested call rather than a self-message or a reply.
What to do instead
Practice reading a sequence diagram by tracing each lifeline's vertical axis and numbering the events: send event, receive event, and reply (dashed arrow with open arrowhead). Confirm that a solid arrow with a filled arrowhead is a synchronous call (wait for reply) while a solid arrow with an open arrowhead is asynchronous. Check whether the diagram shows a creation message (arrow to the top of a lifeline with the «create» stereotype or a new lifeline head) before assuming all lifelines exist from the start.
Confusing the notation of the four behavioral diagrams' common elements: answering that a communication diagram shows time ordering, that a timing diagram uses lifelines with activation bars, or that an interaction overview diagram is a plain activity diagram.
All four interaction diagrams (sequence, communication, timing, interaction overview) describe interactions, so candidates who skim the question stem default to 'sequence' or 'communication' without checking which notation is described. The distinguishing features are precise: communication diagrams show links with sequence numbers (and optional nesting like 1a/1b), timing diagrams show state or value changes against a horizontal time axis with lifelines as vertical bands, and interaction overview diagrams use activity-like frames whose nodes are interaction uses or interaction references.
What to do instead
Build a one-line signature for each: sequence = lifelines + vertical time + message arrows; communication = objects + links + numbered messages, no time axis; timing = horizontal time axis + state/value rows; interaction overview = activity-style control flow whose nodes contain interactions. When a stem mentions sequence numbers or links, answer communication; when it mentions a time axis, answer timing.
Treating a use case diagram as a process or data-flow diagram: drawing arrows between actors to show who hands work to whom, or drawing arrows between use cases to show sequence, and using «include» and «extend» interchangeably.
Use case diagrams are the least technical UML diagram, so candidates fall back on narrative intuition. UML restricts associations to actor–use case (and actor generalization), and the two dependency stereotypes have opposite directions: «include» points from the base use case to the included one (always executed), while «extend» points from the extending use case to the base (executed only under its extension condition).
What to do instead
Remember the arrow rule: include = base → included, extend = extension → base. Actors connect to use cases only; interactions between actors are shown in sequence or activity diagrams, not use case diagrams. Also distinguish a system boundary rectangle (which encloses use cases, not actors) and actor generalization (a specialized actor inherits the base actor's associations).
Assuming a class diagram arrow means 'flows to' or 'calls': drawing a plain association where an aggregation or composition is required, or reversing the direction of a navigable association or a generalization arrow.
Class diagrams are the most heavily tested structural diagram, and the difference between association, aggregation, composition, dependency, and generalization is a single decoration at one end of a line. Candidates under time pressure see a line and answer 'association' without checking for the hollow diamond (shared aggregation), filled diamond (composite aggregation), dashed line with open arrow (dependency), or solid line with hollow triangle (generalization).
What to do instead
Drill the end decorations as a lookup table: plain line = association; hollow diamond at the whole = aggregation; filled diamond at the whole = composition; dashed arrow = dependency (supplier at the arrowhead); solid line with hollow triangle pointing to the parent = generalization. Also check multiplicity at each end and remember that a navigable association has an open arrowhead at the target end, while a non-navigable end has none.
Mixing up component, deployment, and package diagram notation, for example drawing a deployment diagram with component icons, or answering that a package diagram shows runtime nodes and artifacts.
Structural diagrams beyond the class diagram are covered briefly in most study material, so candidates retain only a vague picture. The distinctions are concrete: components are rectangles with the component icon or «component» keyword and expose provided/required interfaces (ball and socket); deployment diagrams show nodes (3-D boxes) containing artifacts (rectangles with the artifact icon or «artifact»); package diagrams show folders with «package» and dependencies between them.
What to do instead
Learn the icon vocabulary: 3-D box = node (device or execution environment), rectangle with a folded corner = artifact, rectangle with two small tabs = component, folder tab = package, rectangle with «interface» = interface. Match the question's nouns ('server', 'JAR file', 'namespace') to those icons before selecting a diagram type.
Treating an object diagram as a class diagram with different names, or treating a composite structure diagram as a class diagram with parts, and answering multiplicity or instance questions using class-level rules.
Object diagrams show instances with underlined names (name:Class) and links rather than associations; composite structure diagrams show internal parts, ports, and connectors inside a classifier. Candidates who only studied class diagrams answer from class semantics and miss that an object diagram's links are instance-level and carry no multiplicity of their own.
What to do instead
Check for underlining: underlined classifier names mean instances, so the diagram is an object diagram. For composite structure, look for parts typed by classes inside a classifier's boundary, ports on the boundary, and connectors between parts. Answer questions about a specific runtime configuration using the object diagram, and questions about internal decomposition using the composite structure diagram.
Confusing UML element properties with diagram properties: claiming a class has attributes and operations plus 'methods' as a third compartment, that an association owns its own attributes, or that a stereotype is a kind of attribute.
Everyday programming vocabulary ('method', 'field', 'property') does not map one-to-one onto UML metamodel terms. In UML a class compartment set is name, attributes, operations, and optionally responsibilities or a separate list of receptions; an association is a classifier and can own association ends with properties, but it does not have 'attributes' in the class sense; a stereotype is a profile mechanism that extends a metaclass, not an attribute.
What to do instead
Fix the vocabulary: attribute = typed property of a classifier; operation = specification of a behavior with a signature; method = the implementation of an operation (rarely shown); association end = a property owned by the association; stereotype = extension of a metaclass defined in a profile, applied with «guillemets». When a question uses a non-UML word, translate it to the metamodel term before choosing.
Answering multiplicity, visibility, and abstractness questions from memory of a specific notation style: writing visibility as 'public/private' words, using '*' loosely for 'many', or forgetting that an abstract class or operation name is italicized.
Notation details are small and easy to half-remember, and many candidates have seen tool-specific variants (for example, colored icons instead of +, -, #, ~). UML fixes visibility as + public, - private, # protected, ~ package; multiplicity as a range like 0..1, 1..*, or , with * meaning 0..; and abstract classifiers and operations as italic names or the {abstract} property.
What to do instead
Memorize the four visibility symbols and the multiplicity grammar (lower..upper, * = 0..*, a single number = exactly that many, and a comma-separated list for alternatives). Practice reading a class box with an italic class name and an italic operation as abstract, and check whether a question asks about the classifier's abstractness or an operation's.
Dismissing the 'why model' domain as common sense: choosing answers that say modeling is only for documentation, or that a model must be a complete, executable representation before it is useful.
The rationale domain reads like soft material, so candidates answer from intuition rather than from the stated benefits. The exam expects the standard justification: models manage complexity by abstraction, enable communication among stakeholders, support analysis and early detection of defects, and allow simulation and code generation, and a model is deliberately an abstraction that omits detail rather than a complete copy of the system.
What to do instead
Learn four benefit categories and one example each: abstraction/complexity management, communication across stakeholders, analysis and verification before construction, and reuse/automation (patterns, code generation, simulation). Reject any option that claims a model must be complete or that modeling replaces the need for stakeholder communication. Also be able to name why a domain (embedded, enterprise, real-time) models: to handle scale, concurrency, or regulatory traceability.