Tokens consumed by an Action are immediately removed from its InputPins when the action begins an execution (except in some cases for StructuredActivityNodes, where tokens may remain on InputPins during the Action execution ...) Source Unified Modeling Language 2.5.1
All tokens offered on the incoming edges of a MergeNode are offered to the outgoing edge. There is no synchronization of flows or joining of tokens. Source Unified Modeling Language 2.5.1
ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...). Source Unified Modeling Language 2.5.1
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. Source Unified Modeling Language 2.5.1
A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...). Source Unified Modeling Language 2.5.1
InitialNodes are an exception to the rule that ControlNodes cannot “hold” tokens, but only manage their flow. Source Unified Modeling Language 2.5.1
The outgoing ActivityEdges of an InitialNode must all be ControlFlows. The control token placed on an InitialNode is offered concurrently on all outgoing ControlFlows. Source Unified Modeling Language 2.5.1
An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta Source Unified Modeling Language 2.5.1
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 ... Source Unified Modeling Language 2.5.1
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. Source Unified Modeling Language 2.5.1
While the ExecutableNode is executing, it is considered to hold a single control [token] indicating it is execution [executing]. Source Unified Modeling Language 2.5.1
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. Source Unified Modeling Language 2.5.1
Tokens are placed on control OutputPins according to the same semantics as tokens placed on ControlFlows coming out of an Actions. Source Unified Modeling Language 2.5.1
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. Source Unified Modeling Language 2.5.1
Control Pins are ignored in the constraints that Actions place on Pins (including matching to parameters for InvocationActions ...). Source Unified Modeling Language 2.5.1
A control Pin (with isControl=true) must have a control type (isControlType=true), so that they may be used with ControlFlows. Source Unified Modeling Language 2.5.1
object_nodes ControlFlows may not have ObjectNodes at either end, except for ObjectNodes with control type. Source Unified Modeling Language 2.5.1
A ControlFlow is an ActivityEdge traversed by control tokens or object tokens of control type, which are use to control the execution of ExecutableNodes Source Unified Modeling Language 2.5.1
