Learn about Webel's comprehensive SysMLv2 Workshop Seminar course!
Webel now has a SysMLv2 Online Self-Study course with self-test Quizzes!
Learn about the Webel Q&A     online self-testing system for SysML v2/v1

A ControlFlow is an ActivityEdge traversed by control tokens or object tokens of control type, which are use to control the execution of ExecutableNodes

Icon class
icon_class
fas fa-quote-left
icon_class_computed
fas fa-quote-left
Related content
uml101 - Activity Diagram - notation - REFERENCE CARD
Source
Unified Modeling Language 2.5.1
Copyright information
About Object Management Group copyright in text extracts quoted from OMG specifications for educational purposes
Snippet kind
INFO
UML keywords
ControlFlow
ActivityEdge
token
control token
object token
Full quote
A ControlFlow is an ActivityEdge traversed by control tokens or object tokens of control type, which are use to control the execution of ExecutableNodes
Next snippet
Related snippets
Related snippets (backlinks)
object_nodes ControlFlows may not have ObjectNodes at either end, except for ObjectNodes with control type.
A control Pin (with isControl=true) must have a control type (isControlType=true), so that they may be used with ControlFlows.
Control Pins are ignored in the constraints that Actions place on Pins (including matching to parameters for InvocationActions ...).
Tokens arriving at a control InputPin have the same semantics as control tokens arriving at the Action, except that control tokens can be buffered in control Pins.
Tokens are placed on control OutputPins according to the same semantics as tokens placed on ControlFlows coming out of an Actions.
An ExecutableNode is a kind of ActivityNode that may be executed as a step in the overall desired behavior of the containing Activity.
Generally, the ControlNodes and ObjectNodes in an Activity are largely there to control the sequencing and to manage the flow of data between the ExecutableNodes of the Activity.
All concrete kinds of ExecutableNodes are Actions ...
An ExecutableNode is an ActivityNode that carries out a substantive behavioral step of the Activity that contains it.
An ExecutableNode may also consume and produce data, but it must do so through related ObjectNodes (Actions use Pins for this purpose ...
An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites ...
Before an ExecutableNode begins executing, it accepts all tokens offered on incoming ControlFlows. If multiple tokens are being offered on a ControlFlow, they are all consumed.
The effect of object tokens accepted from ControlFlows is not specified (see isControlType for ObjectNodes ...), but the semantics above applies if the effect is to execute the ExecutableNode.
While the ExecutableNode is executing, it is considered to hold a single control [token] indicating it is execution [executing].
In some cases, multiple concurrent executions of an ExecutableNode may be ongoing at one time (see the semantics of isLocallyReentrant=true for Actions ... ). In this case, the ExecutableNode holds one control token for each concurrent execution.
When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork ...
A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...).
ControlFlows are used to explicitly sequence execution of ActivityNodes, as the target ActivityNode cannot receive a control token and start execution until the source ActivityNode completes execution and produces the token.
An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes.
Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens
There are three kinds of ActivityNodes:
ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...).
ObjectNodes hold object tokens accepted from incoming ObjectFlows and may subsequently offer them to outgoing ObjectFlows (with a modeler-specified exception for ControlFlows, see isControlType for ObjectNodes ...).
ExecutableNodes actually carry out the desired behavior of an Activity. If an ExecutableNode has incoming ControlFlows, then there must be tokens offered on all these flows that it accepts before beginning execution.
Visit also
Visit also (backlinks)