OCSMP Model Builder Fundamental common mistakes
OCSMP Model Builder Fundamental · Understand the traps and how to avoid them.
Treating SysML as UML with renamed boxes: drawing a class diagram, calling it a block definition diagram, and never using value properties, parts, or ports.
Candidates with UML background assume the mapping is cosmetic and skip the semantic differences (blocks owning parts, directed composition, value types), so they lose marks on questions about what distinguishes a BDD from a class diagram.
What to do instead
For each BDD element, state its SysML meaning aloud: block, part property (composition, owned by the whole), reference property (shared, not owned), value property typed by a value type, and port. Rebuild two small UML class diagrams as BDDs and list every structural change you made.
Confusing parts with references, or drawing composition as a plain association with no diamond, when asked to show whole-part structure.
The distinction is invisible in casual diagrams and many candidates never internalize that the filled diamond on the whole end means ownership and lifetime dependency, while a reference property links without ownership.
What to do instead
Practice reading multiplicities and diamonds from the whole's perspective: diamond sits at the whole, multiplicity at the part end. For a car/engine/wheel/owner example, decide ownership explicitly, then check that deleting the whole would delete parts but not references.
Using a sequence diagram to show control flow with decisions and loops, or using an activity diagram to show lifeline message ordering.
Both diagrams look like 'flow' pictures, and candidates pick whichever they drew most recently rather than matching diagram intent to the question's wording (message exchange over time versus token flow and control logic).
What to do instead
Memorize a one-line purpose per behavior diagram: activity = flow of tokens/control with decisions, forks, merges; sequence = time-ordered message exchange between lifelines; state machine = state transitions triggered by events; use case = actor-visible goals. Then classify ten sample scenarios by keyword before drawing anything.
Drawing an activity diagram with no initial node, no final node, or with a decision whose outgoing guards do not cover all cases (or overlap).
Candidates focus on the happy path and treat control nodes as decoration; guard completeness is a subtle correctness rule that is easy to overlook when sketching quickly.
What to do instead
Adopt a checklist for every activity diagram: exactly one initial node (unless multiple entry points are justified), explicit final flow node, every decision branch guarded, guards mutually exclusive and jointly exhaustive, and merges paired with the decisions they close.
Writing requirements as design statements ('the system shall use a CAN bus') or as unverifiable wishes ('the system shall be user friendly'), then modeling them as requirements.
Candidates draft from an implementation mindset or from marketing language and do not apply the test of whether a requirement constrains the solution space or can be verified by a stated method.
What to do instead
Apply two tests to every requirement: does it state what, not how (unless it is a genuine design constraint, which should be labeled as such), and can it be verified with a named method (test, analysis, inspection, demonstration)? Rewrite three vague statements into measurable ones with thresholds and units.
Ignoring requirement relationships: no containment hierarchy, no derive, no satisfy, no verify, so traceability questions cannot be answered.
Candidates treat requirements as a flat list in a table and do not realize that containment, derivation, satisfaction, and verification are distinct relationships with distinct directions and distinct diagram homes.
What to do instead
Build a small matrix: containment (requirement owns sub-requirements), derive (derived requirement depends on source), satisfy (block satisfies requirement), verify (test case verifies requirement). Draw each on its correct diagram (requirement diagram for containment/derive/copy, BDD or internal block diagram for satisfy) and check arrow direction every time.
Treating a parametric diagram as a block diagram: putting blocks and associations in it instead of constraint properties, parameters, and value bindings.
The parametric diagram shares visual vocabulary with the internal block diagram, and candidates who have not practiced constraint blocks default to drawing structure rather than equations.
What to do instead
Practice the pattern: define a constraint block containing a constraint expression (for example a = bc) plus parameters; instantiate it as a constraint property inside a block; bind each parameter to a value property with a binding connector. Do three examples (mass = densityvolume, force = massacceleration, power = voltagecurrent) until the pattern is automatic.
Using «allocate» for everything, including requirement satisfaction and logical-to-physical mapping where a different relationship is correct, or allocating to nothing (no target).
Allocation is introduced as a general 'maps to' concept, so candidates over-apply it and never learn that satisfy, derive, and refine have their own semantics and their own stereotypes.
What to do instead
Learn the allocation decision tree: requirement to design element = satisfy; requirement to requirement = derive; behavior to structure = allocation (activity partition or «allocate» dependency); abstract to concrete = allocation. Every allocation must have a named source and target, and be shown on an allocation matrix or allocation diagram.
Inventing stereotypes freely, or applying a stereotype without defining it, without a profile, and without consistent application across the model.
Stereotypes look like labels, so candidates use them as informal annotations; they do not realize a stereotype must be defined in a profile, extends a specific metaclass, and carries properties that must be filled in.
What to do instead
Before using a stereotype, confirm it is defined in a profile applied to the model, that its base metaclass matches the element it is applied to, and that all its tagged values are populated. Keep a model glossary listing every stereotype, its metaclass, and its allowed values, and audit the model against it.
Building models with no organizing structure: no packages, no model-level purpose or viewpoint, everything in one flat namespace, so questions about model organization and views cannot be answered from the model.
Candidates focus on diagram syntax and treat organization as administrative overhead, missing that the exam tests whether a model can answer 'which view serves which stakeholder' and whether names are unambiguous across namespaces.
What to do instead
Structure every practice model with packages by concern (requirements, structure, behavior, parametrics, verification), give each diagram a name and a stated purpose/viewpoint, and use fully qualified names when referring to elements across packages. Be able to explain why a view is a projection of the model, not a separate model.