OCSMP Model Builder Advanced common mistakes
OCSMP Model Builder Advanced · Understand the traps and how to avoid them.
When asked to build a profile, the candidate stereotypes the metaclass itself (e.g., puts «stereotype» on Class) or applies the stereotype to the wrong metaclass, instead of defining a Stereotype whose base metaclass is set via extension (Class with Extension end pointing at the Stereotype).
Candidates conflate 'stereotype' with 'subclass' and forget that a SysML/UML profile is a Package containing Stereotypes, each with an Extension to a base metaclass and optional meta-properties; they memorize the «stereotype» keyword but not the extension semantics.
What to do instead
Practice the exact pattern: create a Package «profile», create a Stereotype element, add an Extension from the Stereotype to the chosen base metaclass (e.g., Class, Property, Association), and verify the stereotype is applicable only to that metaclass. Draw the profile in a profile diagram showing «metaclass» and «stereotype» with the extension arrow, and state explicitly which metaclass each stereotype extends.
Treats a model library as just another model package and imports it by copy/paste or by referencing a local path, so the library elements are duplicated or unresolvable in other tools.
Candidates do not distinguish model libraries (reusable, read-only, versioned, referenced by URI/import) from ordinary packages, and do not know the PackageImport vs ElementImport distinction or the difference between copy semantics and reference semantics.
What to do instead
State that a model library is a separate package (often a separate model file) imported via «import» with public/private visibility, referenced by URI, and never edited in place. When asked to integrate, show PackageImport of the library package and confirm that changes propagate by reference; use ElementImport only for individual elements and explain the visibility consequence.
Describes a viewpoint as a diagram type or a stakeholder list rather than as a mechanism: a «viewpoint» that conforms to a stakeholder concern and a «view» that conforms to a viewpoint, with the modeling method and purpose stated.
Candidates mix up the SysML viewpoint/view/stakeholder/concern concepts with UML's older 'view' notion or with tool-specific diagram categories, and cannot articulate that a viewpoint specifies how to construct a view for a concern.
What to do instead
Memorize the quartet: Stakeholder (who), Concern (what), Viewpoint (how the view is built and what it must show, conforming to a concern), View (the actual model/diagram conforming to the viewpoint). In answers, name the concern, the viewpoint's modeling conventions (which diagrams, which elements, which properties), and the view that conforms to it.
When asked to integrate SysML with UML, claims that SysML is a UML profile and that every SysML element is a UML element with a stereotype, ignoring that SysML reuses a UML subset and adds its own metaclasses (e.g., Requirement, Block as a specialization of Class) and that some UML elements are excluded.
Candidates learn the shorthand 'SysML is a UML profile' and over-generalize; they do not know which UML constructs SysML reuses, which it omits (e.g., some UML diagram kinds, certain relationship semantics), and how the two metamodels align.
What to do instead
Build a comparison table: reused UML metaclasses (Class, Property, Port, Connector, Activity, StateMachine, Interaction), SysML specializations (Block, ValueType, Requirement, ItemFlow, ProxyPort/FullPort), and omitted UML features. For integration questions, state the mapping rule (e.g., a Block maps to a UML Class; a SysML Requirement has no direct UML counterpart and needs a stereotype or a separate requirements package) and cite the alignment approach rather than claiming identity.
Integrating SysML with MARTE by simply drawing MARTE stereotypes on SysML blocks without addressing the different concerns (MARTE's quantitative timing/resource modeling vs SysML's structural/behavioral system modeling) or the profile-application and namespace conflicts.
Candidates treat all profiles as interchangeable decorations and do not consider that applying two profiles can create conflicting stereotypes on the same element, or that MARTE's value specification language (VSL) and time model need explicit mapping to SysML value types and time.
What to do instead
Describe a deliberate mapping: keep performance/timing concerns in a MARTE-annotated analysis view, map MARTE «Resource»/«ProcessingResource» to Blocks or Parts, map MARTE timing values to SysML ValueTypes with units, and state how conflicting stereotypes are resolved (separate views or explicit precedence). Mention that both are profiles over UML and that the integration point is the shared UML metaclass.
Integrating with UPDM/DoDAF/MODAF by asserting that UPDM is a SysML extension that replaces SysML diagrams, rather than a profile that adds architecture-framework viewpoints built on SysML, and failing to map framework viewpoints to SysML diagram kinds.
Candidates memorize the acronyms but not the layering: UPDM is a UML/SysML profile providing DoDAF/MODAF viewpoints; the underlying modeling language remains SysML/UML. They also confuse framework 'views' with SysML viewpoints.
What to do instead
State the layering explicitly: framework (DoDAF/MODAF) → UPDM profile → SysML/UML. Give at least one mapping example (e.g., an operational node/activity view realized with SysML activity/block diagrams plus UPDM stereotypes) and note that the framework's viewpoints constrain which SysML constructs and diagrams are used.
Integrating with Modelica by claiming that SysML parametric diagrams execute the same equations as a Modelica model, or by hand-waving the exchange without specifying the mapping of value types, units, and equation causality.
Candidates know SysML has parametric diagrams with constraint blocks and assume this is equivalent to Modelica's acausal equation-based modeling; they do not appreciate that SysML constraints are declarative bindings while Modelica requires a solvable equation system with defined causality and connectors.
What to do instead
Explain the division of labor: SysML captures structure/requirements and parametric constraints (ConstraintBlocks with parameters bound via binding connectors); Modelica performs the numerical simulation. Specify the exchange: map SysML ValueTypes and units to Modelica types/units, map constraint parameters to Modelica variables/connectors, and state that causality and solvability are Modelica's responsibility. Mention tool-level exchange (e.g., FMI/co-simulation or model transformation) rather than claiming semantic identity.
Describing requirements-tool integration as 'export the requirements to a spreadsheet and import them' without addressing identity, traceability direction, change propagation, or the fact that SysML Requirements are model elements with id/text and satisfy/derive/verify relationships.
Candidates default to file exchange because it is familiar, and do not know that integration requires stable identifiers, a defined traceability relationship mapping (e.g., RM tool 'satisfies' link ↔ SysML «satisfy» dependency), and a synchronization policy (authoritative source, one-way vs bidirectional).
What to do instead
Specify: unique and stable requirement IDs on both sides, a mapping table from RM-tool link types to SysML relationships («derive», «satisfy», «verify», «trace»), the authoritative source of truth for each attribute, the synchronization direction and frequency, and conflict handling. Note that SysML Requirement text is often a copy that must be kept consistent, so define which side owns the text.
Integrating with configuration management tools by treating the CM system as a file backup and not defining model-element-level versioning, baselines, branching/merging of model fragments, or the mapping between CM change requests and SysML model changes.
Candidates think of CM in terms of files, but models are graphs of elements with cross-file references; they do not consider that a baseline must capture a consistent model state, that merges can break references, and that change requests should trace to model elements.
What to do instead
Describe the integration contract: which granularity is versioned (project/file/element), how baselines are taken (tagged consistent model state), how branches and merges preserve cross-references (tool-specific merge or lock-based policy), and how CM change requests link to SysML elements (e.g., «trace» to a ChangeRequest or a requirement). State the export format and the identifiers used to keep links stable across tools.
Assessing model quality only by 'the diagrams look complete' or by counting elements, instead of applying explicit quality criteria (syntactic correctness, semantic consistency, completeness against requirements, traceability coverage, well-formedness rules, and readability/conventions).
Candidates lack a checklist and default to visual inspection; they also do not distinguish model validation (tool rule checks, OCL/constraints) from review (human inspection against a quality model) and from verification against requirements.
What to do instead
Use a named quality framework: correctness (well-formedness, metamodel conformance, no orphan/dangling references), consistency (naming conventions, no contradictory values, unique IDs), completeness (every requirement traced to design and verification), and clarity (viewpoint conformance). Pair it with concrete mechanisms: automated validation rules, traceability coverage reports, and peer review against a checklist. State the metric and the acceptance threshold for each criterion.