OCSMP Model Builder Intermediate common mistakes
OCSMP Model Builder Intermediate · Understand the traps and how to avoid them.
Treating «requirement» as a free-text container: typing the constraint into the requirement's name or documentation, leaving no «satisfy» relationships and no decomposition into subrequirements, so the requirement cannot be verified or traced.
Candidates carry over habits from word-processor requirement lists and assume the diagram is illustrative. They do not internalize that a requirement's text is a property whose value must be a single, testable constraint, and that satisfy/verify/derive/refine relationships are what give the model its value.
What to do instead
For every requirement, write the text as one atomic, verifiable statement (with a stated measure or acceptance criterion), give it an id, and force yourself to attach at least one «satisfy» to a structural element and one «verify» to a test case or analysis. If a requirement contains 'and', split it into a container requirement with «containment» of subrequirements. Practice reading a paragraph of prose and converting it into 3-5 atomic requirements with explicit trace links.
Confusing «deriveReqt» with «refine» and «trace», and drawing «satisfy» from a requirement to a block (reversing the arrow direction) or between two requirements.
The four dependency stereotypes look interchangeable on a diagram, and candidates memorize names without the semantics: derivation creates a new requirement from a source requirement, refinement adds detail without creating a new requirement, satisfy always goes from a requirement to the element that fulfills it, and trace is the untyped catch-all. Arrow direction is easy to flip because the notation is a dashed arrow and candidates read it left-to-right on the canvas.
What to do instead
Memorize the rule 'the arrow points at the requirement' for «satisfy» and «verify», and 'the arrow points at the derived/refined requirement' for «deriveReqt» and «refine». Build a one-page decision table: does the target requirement stand on its own (derive) or merely add detail (refine)? Is the link to a design element (satisfy) or to a test case (verify)? Use «trace» only when none of the specific stereotypes apply, and be ready to justify that choice.
Using an association where the model requires composition or aggregation, or drawing a plain association with a navigability arrow and calling it a part property, so whole-part semantics and multiplicity on the whole end are wrong.
Candidates see two blocks connected by a line and assume any line is acceptable. They do not check ownership: a part property is owned by the whole, appears in the whole's compartment as 'name: Type [multiplicity]', and is destroyed with the whole. Reference properties (shared aggregation or plain association) do not carry that lifecycle meaning.
What to do instead
For every whole-part line, ask 'is this part owned and does it die with the whole?' If yes, use a solid diamond (composite) and confirm the part appears in the whole's parts compartment. Verify multiplicity at both ends and confirm the role name is on the part end. If the relationship is a peer reference, use a plain association and do not draw a diamond. Re-read the parts compartment of each block after drawing to confirm the model, not just the picture, is correct.
Overusing generalization for what is actually shared usage: creating a subclass to hold a value or a part that should be a property of the whole, producing deep inheritance trees and blocks that cannot be instantiated sensibly.
Generalization is the most familiar OO construct, so candidates reach for it whenever two elements look similar. They miss that SysML distinguishes specialization (classification) from composition (usage), and that a value or part belongs to the instance, not the type hierarchy, unless it is genuinely type-specific.
What to do instead
Before drawing a generalization, test the 'is-a' sentence and the substitutability rule: every instance of the subtype must be usable wherever the supertype is. If the shared item is a value, part, or port that varies per instance, model it as a property of the owning block instead. Check that no subclass merely adds a default value; that is a property with a default, not a subtype. Review each generalization for whether the subtype adds structure or behavior of its own.
Mixing up ports, proxy ports, and full ports, or attaching an interface block to a port without the «interfaceBlock» stereotype and conjugated flow properties, so the port's type and direction are wrong.
Port notation is visually similar (small square on the boundary) and the conjugation concept is subtle: a conjugated interface block reverses the direction of its flow properties, which is what makes producer and consumer ports compatible. Candidates often type a port with a plain block and then wonder why item flow direction does not check out.
What to do instead
Adopt a rule: proxy ports are typed by «interfaceBlock» classifiers; full ports are typed by blocks and own their own internal structure. When connecting two ports, make the receiving port's type the conjugate of the sending port's type (or explicitly conjugate the interface block) so flow directions oppose. Verify each item flow's conveyed classifier matches a flow property on the port type, and check direction arrows in both the internal block diagram and the port's type definition.
Drawing an activity diagram as a flowchart without the semantics: multiple unguarded outgoing control flows from a decision node, missing or duplicated initial/final nodes, and actions with no input/output pins, so the model cannot be executed or checked.
Flowchart habits dominate, and candidates treat decision nodes as decorative diamonds. They also forget that in SysML an action's inputs and outputs are object flows with pins, and that a control flow and an object flow are different things. Without guards, the model is ambiguous about which path is taken.
What to do instead
For every decision node, ensure each outgoing edge has a mutually exclusive guard and that the guards are exhaustive (add an else guard). Use a merge node to reconverge alternative paths, exactly one initial node per activity, and a flow final or activity final as appropriate. Give each action input and output pins typed by the object flowing, and connect object flows pin-to-pin rather than action-to-action. Trace one token through the diagram manually to confirm it can reach a final node.
Using a state machine where the behavior is really an activity, or omitting entry/exit/do behaviors and transition triggers/guards/effects so the state machine has states but no executable semantics.
Candidates pick the behavior diagram they are most comfortable with rather than the one matching the question's intent. State machines describe event-driven lifecycle of a single object; activities describe transformation of inputs to outputs. Without triggers and guards, transitions are unlabeled arrows with no meaning.
What to do instead
Decide first: is the subject a single object whose lifecycle is driven by events (state machine) or a process transforming inputs (activity)? For state machines, give every transition a trigger event, add guards where alternatives exist, and specify entry/exit/do behavior in the state's compartment. Confirm that composite states have initial and final pseudostates and that every state is reachable from the initial state and can reach a final state.
Modeling a constraint as a block with a text description instead of a «constraint» with a constrained property whose expression is a real equation, and leaving constraint parameters unbound so the parametric diagram cannot be evaluated.
Candidates are comfortable with blocks and uncomfortable with the constraint expression language. They also miss that a parametric diagram shows binding connectors between constraint parameters and value properties, and that without bindings the equation has no inputs.
What to do instead
Define each constraint as a «constraint» classifier with parameters typed by value types, and put the equation in the constraint's expression (for example, a constraint property with the expression written as an equality between parameters). In the parametric diagram, draw binding connectors from each constraint parameter to the corresponding value property of the owning block. Verify dimensional consistency: units on each parameter must be compatible with the equation's operations.
Failing cross-diagram consistency: a value property renamed on a block definition diagram still appears under its old name in an internal block diagram, or a part's type is changed but the parametric bindings and satisfy relationships still point at the old element.
Candidates work diagram-by-diagram and treat each as a separate drawing. In SysML a diagram is a view of one underlying model, so an element appears in many diagrams and a change in one place must be reflected everywhere. The exam tests whether you understand that the model, not the picture, is the source of truth.
What to do instead
Before answering any question about a diagram, ask 'where else does this element appear?' Build the habit of checking the parts compartment, the parametric bindings, and the satisfy/verify links whenever a type or name changes. When reviewing a model for quality, walk each requirement down to a satisfying block, then to the block's value properties, then to the constraint parameters bound to them, and confirm the chain is unbroken.
Ignoring multiplicity and units: leaving multiplicity at the default 1 when the requirement implies a collection, or omitting units on value properties and on constraint parameters so numeric constraints are ambiguous.
Multiplicity and units are small annotations that are easy to skip, and the default of 1 is invisible. Candidates focus on the boxes and lines and treat annotation as optional, but the exam treats them as part of the precise meaning of the model.
What to do instead
For every part and value property, read the requirement text for words like 'each', 'set of', 'list', or 'up to' and set multiplicity accordingly, including the upper bound. Attach a unit to every value property that represents a physical quantity and to every constraint parameter, and check that the units used in an equation are consistent (for example, converting before dividing). When a question offers two answers that differ only in multiplicity or units, that difference is the point of the question.