OCSMP Model Builder Intermediate cheat sheet

A requirement's text is held in the «requirement» element's text property; the id property carries the identifier, and both are shown in the compartment labeled by the requirement's name.

«satisfy» is a dependency from a block (or other named element) to a requirement; «deriveReqt» is a dependency between requirements where the client is derived from the supplier; «verify» links a test case to the requirement it verifies.

«refine» is a directed dependency from any element to a requirement it makes more precise; «trace» is a weaker, non-semantic dependency used for informal linkage; neither implies satisfaction.

«copy» on a requirement creates a read-only reuse of the supplier's text; editing the copy is not permitted, whereas a derived requirement may restate or narrow the source text.

Requirement containment (a requirement nested inside another) expresses composition only; it does not by itself imply derivation, so a nested requirement must still be linked with «deriveReqt» if derivation is intended.

A «testCase» is a behavior (often an activity) with «verify» dependencies to requirements; verification is thus modeled as a behavior plus a dependency, not as an attribute of the requirement.

Requirement diagram frames may show «satisfy», «deriveReqt», «verify», «refine», «trace», «copy», and containment; allocation of requirements to other model elements uses «allocate» rather than «satisfy».

Rationale, problem, and other user-defined requirement properties are added as value properties or stereotypes; SysML itself defines only id and text as standard requirement properties.

A block is a UML class stereotyped «block»; it is a type, while a part property (a property typed by a block and owned by a composite association) is a role played in the whole; multiplicity on the part property gives the number of instances.

Reference properties are shown with a plain (non-filled) aggregation diamond and are non-compositional; shared aggregation is not used in SysML - either the diamond is filled (composition) or absent (reference).

Ports are typed by «interfaceBlock» or «proxyPort»; a full port is typed by a block and owns its own internal structure, a proxy port delegates to the internal parts of the owning block.

Proxy ports expose features (operations, receptions, flow properties) of the owning block and must be typed by an interface block; a port's provided/required interfaces are indicated by lollipop and socket notation.

A «flowPort» is deprecated in SysML 1.3+; use proxy ports or full ports with «directedFeature»/«nestedConnectorEnd» instead. Flow properties are typed by «flowSpecification» or «block» and carry direction in, out, or inout.

Value types are blocks stereotyped «valueType» with units and dimensions; a value property's type should be a value type or a primitive, and units come from a «unit» or «dimension» library such as SI.

A connector between parts is an association usage; item flows on connectors must be typed by an «itemFlow» whose type conforms to the types of both ends' ports or parts.

Generalization between blocks is specialization; a block may have multiple generalizations, and redefinition of properties in a subtype must respect the type and multiplicity of the redefined property (covariant narrowing of type is allowed, multiplicity may not widen).

An activity owns actions connected by object flows and control flows; an object flow carries tokens typed by the flow's type, while a control flow carries only control tokens and may not carry object tokens.

«activity» parameters are typed by pins on the activity's actions; an input pin must have a type conforming to the object flow it receives, and an output pin's type must conform to the flow it produces.

Decision and merge nodes are the same notation (diamond) but differ in semantics: a decision has one input and multiple guarded outputs, a merge has multiple inputs and one output; guards are evaluated on outgoing edges of a decision.

Fork and join nodes are the same notation (bar) but differ in semantics: a fork has one input and multiple outputs (concurrent), a join has multiple inputs and one output and waits for all incoming tokens unless the join is specified otherwise.

A «stateMachine» has regions, states, and transitions; a transition's trigger is an event (signal, call, time, or change), its guard is a boolean constraint, and its effect is a behavior - all three are optional but a completion event is implied when no trigger is given.

Composite states contain regions with an initial pseudostate and may have entry, exit, and do behaviors; a final state terminates the region, and a terminate pseudostate terminates the entire state machine.

An «interaction» (sequence diagram) has lifelines typed by blocks or parts; a message's signature must be an operation or reception of the receiving lifeline's type, and a synchronous message implies a reply message when the operation has a return type.

«alloc» (allocate) dependencies map behavior to structure - for example, an activity to a block or an action to a part - and are shown on an allocation compartment or an allocation table; allocation does not change the underlying model semantics.

A «constraintBlock» owns constraint parameters and a constraint expression; a «constraintProperty» (a property typed by a constraint block) binds its parameters to value properties of blocks via «bindingConnector» or «nestedConnectorEnd» on a parametric diagram.

Constraint parameters are typed by value types; a binding connector between a constraint parameter and a value property requires the types and units to be compatible, otherwise the model is ill-typed even if the diagram looks correct.

A parametric diagram is an internal block diagram whose parts are constraint properties; it may show value properties, constraint properties, and binding connectors, but not behavioral elements such as actions or states.

Unit consistency is a modeling constraint: a value property with a unit of meters may not be bound to a constraint parameter typed in seconds; unit and dimension libraries (SI) supply the «unit» and «dimension» elements used to check this.

Model quality checks include: every requirement has a unique id and non-empty text; every «satisfy» has a supplier that is a block or behavior; every «verify» has a supplier that is a «testCase»; every proxy port is typed by an interface block; every flow property has a direction.

Conformance to SysML means using the standard stereotypes and notation rather than ad hoc ones; for example, using «block» instead of «class», «itemFlow» instead of a plain association, and «allocate» instead of an untyped dependency for allocation.

Traceability completeness: each requirement should be reachable from at least one design element via «satisfy», «deriveReqt», or «allocate»; orphan requirements and orphan test cases are common audit findings.

Inter-diagram consistency: a part shown on an internal block diagram must be a property of the block that owns the diagram's frame; a lifeline on a sequence diagram must correspond to a part or block that participates in the modeled interaction.