OCSMP Model Builder Intermediate flashcards

31 cards. Read the term and the definition here. The deck at the top of this page is optional.

Requirement text property

The «requirement» element's text property holds the requirement statement itself; it is displayed in the requirement's compartment and is distinct from the id property, which carries the identifier.

Satisfy dependency

A «satisfy» dependency runs from a block or other named element to a requirement, asserting that the supplier fulfills the client requirement. It is the standard SysML mechanism for design-to-requirement traceability.

DeriveReqt versus copy

«deriveReqt» links a derived requirement to its source and permits restating or narrowing the text; «copy» makes a read-only reuse whose text may not be edited. Both are dependencies between requirements.

Verify and testCase

A «testCase» is a behavior stereotyped as such, and «verify» dependencies run from the test case to the requirements it verifies. Verification is modeled as behavior plus dependency, not as a requirement attribute.

Refine versus trace

«refine» is a directed dependency from any element to a requirement it makes more precise; «trace» is a weaker informal link. Neither implies satisfaction, and neither substitutes for «satisfy» or «verify».

Requirement containment semantics

Nesting a requirement inside another expresses composition only. It does not imply derivation, so an explicit «deriveReqt» dependency is still required when the nested requirement is derived from its parent.

Requirement diagram frame contents

A requirement diagram may show «satisfy», «deriveReqt», «verify», «refine», «trace», «copy», and containment relationships. Allocation of requirements to design elements uses «allocate», not «satisfy».

Block versus part property

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

Composition versus reference

A filled aggregation diamond marks composition, where the whole owns its parts. A plain diamond or no diamond marks a reference property. SysML does not use shared aggregation, so the diamond is filled or absent.

Proxy port typing rule

A proxy port must be typed by an «interfaceBlock» and exposes the owning block's features. It delegates to the block's internal parts, unlike a full port, which is typed by a block and owns its own structure.

Flow property direction

Flow properties are typed by a «flowSpecification» or block and carry a direction of in, out, or inout. They are used on ports and connectors to type item flows moving between parts.

Value type and units

A «valueType» block types value properties and carries units and dimensions. Units come from a library such as SI, and binding a value property to a parameter in incompatible units is a modeling error.

Item flow on connector

An item flow on a connector must be typed by an «itemFlow» whose type conforms to the types at both ends, typically the ports or parts the connector joins. It shows what moves, not merely that a connection exists.

Property redefinition rules

When a subtype redefines a property, the new type must conform to the old type and the multiplicity may not widen. Covariant narrowing of the type is permitted; changing units or direction inconsistently is not.

Internal block diagram frame

An internal block diagram is framed by the block it describes. Every part shown must be a property of that owning block, and connectors must join parts or ports of that block.

Full port

A full port is typed by a block and owns its own internal structure, including its own parts and connectors. It contrasts with a proxy port, which delegates to the features of its owning block.

Object flow versus control flow

An object flow carries tokens typed by its flow type between actions; a control flow carries only control tokens and no object tokens. Both connect actions inside an activity.

Decision versus merge node

Both use the diamond notation. A decision has one input and multiple guarded outputs, with guards evaluated on outgoing edges; a merge has multiple inputs and a single output and performs no guard evaluation.

Fork versus join node

Both use the bar notation. A fork has one input and multiple concurrent outputs; a join has multiple inputs and one output and waits for all incoming tokens unless its join specification says otherwise.

Activity parameter and pins

Activity parameters are typed by pins on the activity's actions. An input pin's type must conform to the object flow it receives, and an output pin's type must conform to the flow it produces.

Transition trigger guard effect

A state machine transition may have a trigger event, a boolean guard, and an effect behavior; all three are optional. When no trigger is given, a completion event is implied for the transition.

Composite state behaviors

A composite state contains a region with an initial pseudostate and may define entry, exit, and do behaviors. A final state terminates its region; a terminate pseudostate ends the whole state machine.

Lifeline message signature

A message on a sequence diagram must correspond to an operation or reception of the receiving lifeline's type. A synchronous message implies a reply message when the operation has a return type.

Allocate dependency

An «allocate» dependency maps behavior to structure, such as an activity to a block or an action to a part. It is shown in an allocation compartment or table and does not change underlying model semantics.

Constraint block

A «constraintBlock» owns constraint parameters and a constraint expression. Its parameters are typed by value types, and instances appear as constraint properties on parametric diagrams where they are bound to value properties.

Binding connector type compatibility

A binding connector joining a constraint parameter to a value property requires compatible types and units. Incompatible units, such as meters bound to seconds, make the model ill-typed even when the diagram renders.

Parametric diagram allowed contents

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 check

Every binding between a value property and a constraint parameter must agree in dimension and unit. SI library «unit» and «dimension» elements supply the reference types used to detect mismatches during model review.

Requirement audit checklist

Each requirement needs a unique id and non-empty text; each «satisfy» needs a block or behavior supplier; each «verify» needs a «testCase» supplier; each proxy port needs an interface block type.

SysML conformance indicators

Conformance means using standard stereotypes and notation: «block» rather than «class», «itemFlow» rather than a plain association, and «allocate» rather than 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 the most common audit findings in model reviews.