OCSMP Model User common mistakes
OCSMP Model User · Understand the traps and how to avoid them.
On an activity diagram, the candidate uses a single fork node to split one flow into mutually exclusive alternatives, or uses a decision node to show two branches that are supposed to run in parallel, and leaves decision outgoing edges without guards.
The candidate reads the diagram as a generic flowchart where a split is just 'a split', and has not internalised that fork/join tokens are copied (AND semantics) while decision/merge tokens are selected (OR semantics).
What to do instead
Before drawing, state the intent in words: 'both paths run' or 'exactly one path runs'. Use fork/join for AND and decision/merge for OR; put a guard on every outgoing decision edge, make guards mutually exclusive and collectively exhaustive, and add an [else] guard as the catch-all. Verify by asking what tokens arrive at each downstream action.
The candidate models behaviour that depends on remembering which state the system is in as a loop-and-decision activity, or conversely models a pure input-to-output transformation as a state machine, so events, guards and state history have nowhere to live (or the flow of data and outputs is lost).
Activities and state machines both contain nodes connected by arrows and look interchangeable at a glance; the candidate picks whichever diagram they drew most recently rather than the one whose semantics match the requirement.
What to do instead
Apply the selection rule explicitly: if the requirement talks about a sequence of transformations producing outputs from inputs, use an activity (actions, object flow, pins); if it talks about the system being in distinguishable conditions over time and reacting to events, use a state machine (states, triggers, guards, effects). If both are needed, model the state machine as the owner and reference activities via entry/do/exit behaviours, rather than duplicating logic.
On a sequence diagram the candidate draws synchronous calls as plain open-headed arrows with no reply, never distinguishes asynchronous from synchronous messages, and expresses conditional or repeated interaction in a text note instead of a combined fragment.
The candidate treats sequence diagrams as informal sketches and does not connect the arrowhead style to the execution semantics (blocking wait for a reply versus fire-and-forget), nor to the interaction operators that express branching and iteration.
What to do instead
Use the filled solid arrowhead for synchronous messages and always complete the pair with a dashed reply arrow; use the open arrowhead only where the sender truly does not wait. Wrap conditional behaviour in alt or opt fragments with explicit guards on each operand, and repetition in a loop fragment with a guard. Check each lifeline is typed by the part or block that actually owns the behaviour at that point in the interaction.
On a block definition diagram the candidate attaches the 'many' multiplicity to the whole end of the composition, believing that is how they say 'the system has many subsystems', and leaves the part end at 1.
The candidate reasons from the sentence 'the whole contains many parts' and places the number next to the containment symbol instead of reading each end as 'how many of the opposite end one instance here sees'.
What to do instead
Read every association end as: how many objects at the opposite end are associated with one object at this end. Put the number of parts per whole on the part-side end (System [1] --- 1..* Subsystem reads 'one System has one or more Subsystems'). Say the sentence aloud in both directions before committing the multiplicities.
The candidate uses shared (hollow diamond) aggregation for genuine whole-part relationships, then states in the rationale that destroying the whole destroys the parts, or leaves the diamond off entirely and calls it composition.
The candidate thinks 'aggregation' is just a synonym for 'has-a' and does not treat the filled diamond as a lifetime/ownership commitment with consequences for the model.
What to do instead
Decide ownership first: if the part cannot outlive the whole and is created and destroyed with it, use composite aggregation (filled diamond at the whole end) and model the part as a property of the whole. Use shared aggregation only where lifetimes are genuinely independent, and state that reasoning in the element's documentation so the choice is auditable.
On an internal block diagram the candidate draws connectors directly between parts with no ports, or types a port with a block rather than an interface block, so the model says nothing about what is exchanged and cannot be checked against the interface requirement.
The candidate focuses on 'these two parts are connected' as a wiring fact and treats ports as optional decoration, and has not practised distinguishing a port's type (what it provides or requires) from the part it belongs to.
What to do instead
For each connector, state what flows across it and through which feature. Add a port on each part, type the port with an interface block (or use a flow port / proxy port as appropriate), and connect port to port. Use full ports only where the part's internal behaviour is genuinely exposed; otherwise use proxy ports. Where the exchange is physical matter, energy or information with a type and direction, model it as an item flow on the connector.
The candidate draws a «satisfy» dependency from a test case or verification activity to a requirement, and a «verify» dependency from a design block to a requirement, effectively swapping the two.
Both relationships point at requirements and both feel like 'this thing deals with that requirement', so the candidate recalls the stereotype name without its subject: design versus evidence.
What to do instead
Anchor the definitions: «satisfy» goes from a design element (block, activity, part) to the requirement it meets; «verify» goes from a verification element (test case, test procedure, verification activity) to the requirement it provides evidence for. Also add «refine» only where the relationship is about elaboration of meaning, not proof. Read each dependency back as a sentence: 'this design satisfies that requirement' or 'this test verifies that requirement'.
The candidate models requirements as plain classes or as text in a note, omits the id and text properties, and then draws «deriveReqt» from the parent requirement to the derived one or copies requirements with «copy» when they meant derivation.
Requirements look like documentation rather than model elements, and the derive relationship reads naturally in the wrong direction because people say 'this requirement derives that one'.
What to do instead
Create requirements with the «requirement» stereotype, always populate id and text, and place them in the owning requirement package by composition so containment is visible. Draw «deriveReqt» from the derived (more specific) requirement to the source (parent) requirement. Use «copy» only for reuse of the same requirement text in another context, not for specialisation.
The candidate draws «allocate» from the physical implementation element back to the logical or functional element, or allocates a requirement directly to a block with «allocate» instead of using the requirements relationships.
Allocation feels symmetric ('these two things map to each other'), and the candidate conflates 'this block is responsible for this requirement' with 'this behaviour is implemented here'.
What to do instead
Orient allocations from the more abstract source to the more concrete target (behaviour or logical element to the implementing structure), and read it as 'source is allocated to target'. Keep requirements out of allocation: use «satisfy» for design-to-requirement and «verify» for test-to-requirement. If the allocation is really about which part performs a function, model it as an allocated activity or a «perform» relationship in addition to, not instead of, the allocation.
The candidate encodes units in property names or documentation (mass_kg, a Real typed property commented 'kilograms'), or types quantities with the block of the thing being measured, so quantity values cannot be compared or converted.
Tool palettes make primitive types the fastest thing to select, and the candidate has not internalised the value type / unit / dimension triple as the mechanism for making quantities meaningful.
What to do instead
Define a «valueType» (or use the library one) with a quantity kind and a unit, then type the property with that value type and give the value a unit where a literal is used. Consistency check: every numeric property in the model with a physical meaning should have a value type carrying a dimension, and no unit abbreviation should appear in an element name.