OCSMP Model User key terms

A behavior modeled as a network of actions joined by control and object flows; it shows how inputs are transformed into outputs, including branching, concurrency, and defined start and stop points.

A single step inside an activity that consumes tokens on its input pins and produces tokens on its output pins when it completes; it is the basic unit of work in a behavior.

A directed edge in an activity that carries data or items from one action's output pin to another action's input pin, so the receiving action waits until that item arrives.

A control node with one incoming flow and several guarded outgoing flows; for each arriving token exactly one outgoing path is selected, making it the activity equivalent of an if-statement.

A control node that combines alternative incoming flows into a single outgoing flow without making any choice; it is typically paired with a decision node to rejoin separated branches.

A control node with one incoming flow and multiple outgoing flows that duplicates each arriving token onto every outgoing flow, launching concurrent branches within an activity.

A control node with multiple incoming flows and one outgoing flow that waits until tokens are available on all incoming flows, then passes a single token onward to synchronize concurrent branches.

A control node that ends the whole activity when any token reaches it, terminating all other tokens and flows still executing within that activity.

A behavior describing the lifetime of an object as states, transitions, events, guards, and effects; it defines how and when the object changes state in response to occurrences.

A condition during the life of an object in which it satisfies some condition, performs some behavior, or waits for an event; states can be simple or contain nested substates.

A directed relationship between states, or from a pseudo-state, that fires when its trigger occurs and its guard is true, optionally executing an effect on the object.

A Boolean expression attached to a transition or to an outgoing flow that must evaluate to true before that path can be taken; it prevents firing when false.

An occurrence that may trigger a transition, such as a received signal, an operation call, a change in a condition, or the passing of a time duration.

A state that contains one or more regions of nested substates, allowing hierarchical behavior; entering it normally enters its initial substate unless a history pseudo-state is used.

A behavior specifying a sequence of actions that actors and a system perform together to produce an observable result of value to the actor; it scopes system capabilities from a user viewpoint.

The fundamental structural unit in SysML; a classifier that may own properties, operations, ports, and constraints and can be instantiated to represent a system, component, or item.

A property typed by a block that represents a component owned by the containing block, so its lifetime is bound to the whole and it appears in the owner's internal structure.

A property typed by a block that refers to an object the containing block does not own, used to model shared, external, or remotely located elements.

A property typed by a value type whose value is simple data such as a number with units, a string, or a Boolean; it captures quantifiable characteristics of a block.

An interaction point on a block through which it exchanges signals, items, or services with other blocks; ports state what the block provides and requires at its boundary.

A port that forwards interactions to internal parts of its owning block instead of handling them itself, so the block's external interface is realized by its internal structure.

A link between two parts or ports that lets them communicate; assembly connectors join required and provided interfaces between peers, while delegation connectors join an outer port to inner parts.

A connector that ties an outer port of a block to a port of one of its internal parts, passing requests or items inward or outward so the outer interface is met internally.

A whole-part relationship with strong ownership in which the part cannot outlive the whole; it is drawn with a filled diamond and usually realized through a part property.

A taxonomic relationship in which a more specific classifier inherits features from a more general classifier and may add new features or override inherited ones.

A classifier whose instances are values without identity, such as a number with a unit and dimension; it types value properties and keeps measurement units consistent across the model.

A diagram showing the inside of a single block: its parts, ports, connectors, and item flows, revealing how the block's own components are wired together.

A stereotype applied to a class-like element that captures an identifier and a text statement of need, and that can be related to design elements through satisfy, verify, derive, and trace relationships.

A diagram that presents requirements, their containment hierarchy, and their relationships to other requirements and to model elements that satisfy, verify, or refine them.

A dependency from a design element to a requirement asserting that the element fulfills the requirement; it records a design claim and does not by itself prove that the requirement is met.

A relationship from a test case or other verification element to a requirement, stating that the element checks whether the requirement is met.

A relationship between two requirements showing that the derived one follows from the source, typically breaking a higher-level need into a more specific, lower-level statement.

A general dependency used for lightweight traceability between requirements and other model elements when no more specific relationship such as satisfy, verify, or derive applies.

The technique planned to check a requirement: inspection, analysis, demonstration, or test; it is recorded on requirements or test cases to guide verification planning.

A specification of the conditions, inputs, and expected results used to check a requirement, modeled as a behavior stereotyped as a test case and linked by a verify relationship.

A cross-cutting relationship that maps elements of one kind onto elements of another, for example assigning activities to the blocks that perform them or requirements to the parts that own them.

A model element that extends the modeling language to define a new kind of element or property, adding tags and constraints, and that is applied to existing model elements.

A package of stereotypes, tagged values, and constraints that adapts the modeling language to a particular domain, method, or project without changing the underlying metamodel.

A package of reusable model elements, such as units, value types, or analysis blocks, that other models import by reference rather than copying into their own namespace.

A model element that describes one specific instance of a classifier, giving concrete values for its properties; it is used to show example configurations, test data, or snapshots.