OCSMP Model Builder Fundamental cheat sheet

A model is a set of packages, elements, and relationships; a view is a projection selected by a viewpoint, never a separate copy of the model.

Namespace containment: Package owns elements; owning a package gives a qualified name Package::Element. Two elements may share a name only if their owners differ.

Element kinds: Class, Actor, Use Case, Component, Activity, State Machine, Constraint (parametric), Block (SysML), ValueType, InterfaceBlock, and Requirement.

Diagram is a view of model elements; deleting a diagram does not delete elements. Deleting an element removes it from every diagram that shows it.

Dependency vs association: dependency is a directed supplier/client arrow with no instances; association is structural with multiplicities and navigability.

Model libraries and reusable packages should be imported (Package Import, public/private) rather than copied, so changes propagate to all users.

A root model element (model) owns top-level packages; naming conventions and package structure are organizational decisions, not UML semantics.

Stereotypes, tags, and profiles extend the metamodel; applying a stereotype adds properties to an element without changing its base metaclass.

A model is an abstraction that answers specific questions; its value depends on the questions it is built to answer, not on completeness.

Model purposes: communication, specification, verification/validation, simulation, and documentation; each purpose selects which views and fidelity are needed.

Requirement traceability is a primary benefit: model elements link to requirements, so impact analysis of a change is a query, not a manual search.

Simulation (behavior and parametric) lets engineers evaluate design alternatives before hardware exists, reducing rework cost.

A single source of truth avoids inconsistency between separate documents; diagrams and reports are generated from the model.

Model-based systems engineering (MBSE) formalizes the model as the primary artifact; documents become derived products.

Quality attributes of a model: correctness, consistency, completeness relative to purpose, and comprehensibility to its intended readers.

Cost is real: model maintenance, tooling, and training; benefits accrue when the model is reused across lifecycle phases and projects.

A requirement is a capability or condition that a system must satisfy; SysML Requirement is a Class stereotype with id and text properties.

Requirement relationships: containment (composite), deriveReqt (derived from a source), satisfy (design element meets requirement), verify (test case verifies).

«satisfy» goes from a design element (block, activity, etc.) to a requirement; «verify» goes from a test case to a requirement.

Traceability directions: deriveReqt points from derived requirement to its source; refinement points from refined element to the refined element.

Requirement text should be verifiable: state a measurable condition, not an adjective; each requirement has a unique id.

Allocation of requirements to structure is not «satisfy»; satisfaction is a claim that the design meets it, allocation assigns responsibility.

Requirements can be organized in packages and requirement diagrams; hierarchy is shown by containment, not by «deriveReqt» alone.

Change management: a requirement change propagates through deriveReqt and satisfy links, so impact analysis follows those relationships.

Block is the SysML structural unit; it may have properties (parts), operations, ports, and constraints. Part properties are typed by blocks and owned by the whole.

Composition (filled diamond) means the whole owns the part; the part's lifetime is bounded by the whole. Aggregation (open diamond) is a weaker, non-owning whole.

Multiplicity [n..m] on an association end states how many instances of the target may be linked to one instance of the source.

Ports are interaction points typed by interfaces (interface blocks or flow specifications); proxy ports expose features, full ports are behavior-bearing.

Internal block diagram (IBD) shows parts, ports, connectors, and item flows inside one block; it is a white-box view.

Generalization (hollow triangle) means subtype inherits features and is substitutable for the supertype; association is not generalization.

Value types define units and dimensions for value properties; quantities should be typed, not bare numbers, to enable unit checking.

Structure vs behavior: a block describes what exists; activities and state machines describe what happens. A part property is not a class.

Activity diagrams model flow of control and data: actions, control flows, object flows, decision/merge, fork/join, initial and final nodes.

A token on a control flow enables an action; fork produces concurrent tokens, join synchronizes them (all incoming tokens required).

Decision node has one input and multiple guarded outputs; merge node has multiple inputs and one output; they are not the same node.

State machine: states, transitions with trigger/guard/effect, entry/exit/do activities; composite and orthogonal regions model hierarchy and concurrency.

A transition fires when its trigger occurs and its guard is true; guard false means no firing, and the event may be lost or deferred.

Use case diagram: actors, use cases, associations, «include» (mandatory reuse) and «extend» (conditional extension at an extension point).

Sequence diagram: lifelines, messages (sync, async, reply), combined fragments (alt, opt, loop); order is vertical time.

Interactions and activities are behavior owned by a context block via ownedBehavior; a behavior can be allocated to a structural element.

A constraint block (constraint property) encapsulates an equation and its parameters; the equation is a constraint expression in a specific language.

A parametric diagram shows constraint properties, value properties bound to parameters, and binding connectors that equate values.

Parameters are typed by value types; binding a value property to a parameter means the values are equal at evaluation time.

Units and dimensions on value types allow dimensional consistency checking; a binding between different dimensions is an error.

Constraint blocks are reusable: the same equation can be applied many times as different constraint properties with different bindings.

Parametric models evaluate design, not behavior over time; they answer 'what value results from these inputs' given the equations.

A binding connector is not an item flow or association; it is a value equality between a parameter and a property.

Analysis context: a block owns constraint properties and value properties, and an IBD/parametric diagram shows the bindings among them.

Allocation is a cross-cutting relationship mapping elements of one model domain to another (e.g., behavior to structure, logical to physical).

«allocate» is a dependency-like relationship from the allocated (source) element to the allocated-to (target) element.

Allocation can be shown on an allocation compartment, an allocation table, or an activity diagram with allocated swimlanes/partitions.

Allocate behavior to structure: an activity or action is allocated to a block or part that performs it.

Allocate structure to structure: a logical block is allocated to a physical block, supporting layered architecture views.

Allocation is not satisfaction: satisfy claims a requirement is met; allocate assigns responsibility across domains.

Allocation direction matters for traceability queries; reverse navigation from target to source answers 'what is allocated here'.

Allocations can be derived and refined; they should be maintained as the model evolves, since they are the bridge between views.

A stereotype extends a metaclass; applying it to an element adds stereotype-specific properties (tagged values) and may add constraints.

A profile is a package of stereotypes and their extensions; the profile must be applied to the model before its stereotypes are usable.

Stereotype notation: «StereotypeName» above or inside the element name; tagged values appear in a compartment or property sheet.

SysML itself is a UML profile: «block», «requirement», «interfaceBlock», «valueType», «constraint» are stereotypes on UML metaclasses.

A stereotype can specialize another stereotype; the child inherits its properties and extensions.

Stereotypes are not subclasses: a «block» is a UML Class with the Block stereotype applied, not a new metaclass.

Custom stereotypes should capture modeler intent (e.g., «safetyCritical») and support queries and reports, not replace structure.

Multiple stereotypes may apply to one element; conflicting tagged values must be resolved by the modeler.