Control Nodes
Control Nodes
SysML uses a variety of elements to represent the logical flow of control of the system behavior. These elements include Fork Nodes, Join Nodes, Decision Nodes, Merge Nodes, Initial Nodes, Activity Final Nodes, and Flow Final Nodes. The first four can also be used to represent object flow in the activity. Each control node will be explained below.
A Fork Node (aka “fork”) is used to split a single control flows in two 2 or more control flows. The split control flows are all identical, each possessing a control token and provide their control token to each of their receiving elements simultaneously. A Fork is modeled as a solid black bar.
A Join Node (aka “join”) takes two or more control flows as inputs and creates one outgoing control flow. All control tokens must be present on the input of the Join Node in order for the output control token to be generated. A Join Node is also modeled as a solid black bar, but some tools model it as a hollow black bar to differentiate it from the Fork Node.
A Decision Node (aka “decision”) takes a single control token as an input and creates a single control token as an output, but which outgoing control flow from the Decision is taken depends upon the Guard condition of each control flow. Guard conditions are Boolean expressions. A Decision Node may optionally have an incoming object flow stereotyped as «decisioninputFlow» whose object token can be used as an input to the guard expressions assigned to the decision node’s outgoing control flows. A Decision Node is modeled as a diamond.
A Merge Node (aka “merge”) is similar to a Join Node in that it takes multiple control flows as inputs and creates a single output control flow, but it differs from the Join Node in that only one input must be present before the output is created. A Merge Node is also modeled as a diamond, but some tools model it as a hollow diamond (or a diamond within a diamond) to differentiate it from a Decision Node.
An Initial Node demarcates where an activity’s execution begins by generating the first control token which is placed on its outgoing control flow. The Initial Node may not have an incoming control flow. The Initial Node is modeled as a solid, filled circle.
The Activity Final Node is the opposite of the Initial Node in that it consumes the final control token of the activity execution, causing the activity execution to end. The Activity Final Node is modeled as a “bulls-eye.”
The Flow Final Node is similar to the Activity Final Node, in that it consumes a control token and ends the control flow on a certain branch of the activity diagram, but it does not end the activity execution. In other words, there may be other control tokens “in play” elsewhere in the activity execution. The Flow Final Node is modeled as a circle with an inscribed “X.”
Control Nodes can be considered as actions, and as such, may be allocated to blocks or instances, may own constraints, and may even satisfy a requirement.
