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
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 ...). 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
Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens Source Unified Modeling Language 2.5.1
An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes. 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
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. 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
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
ObjectNode::upperBound : ValueSpecification [0..1] The maximum number of tokens that may be held by this ObjectNode. Tokens cannot flow into the ObjectNode if the upperBound is reached. If no upperBound is specified, then there is no limit on how many ... Source Unified Modeling Language 2.5.1
Rate ... When the stereotype is applied to a parameter, the parameter shall be streaming, and the stereotype gives the number of objects or values that flow in or out of the parameter per time interval while the behavior or operation is executing. Source OMG Systems Modeling Language (SysML) 1.6
When the «rate» stereotype is applied to an activity edge, it specifies the expected value of the number of objects and values that traverse the edge per time interval, that is, the expected value rate at which they leave the source node and arrive at ... Source OMG Systems Modeling Language (SysML) 1.6
incoming_control_one_input_parameter If the DecisionNode has a decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has one in Parameter ... Source Unified Modeling Language 2.5.1
two_input_parameters If the DecisionNode has a decisionInputFlow and a second incoming ObjectFlow, then any decisionInput has two in Parameters ... Source Unified Modeling Language 2.5.1
The values on such object tokens may be used to affect the control of ExecutableNodes that are the targets of such ControlFlows, though the specific meaning of such values is not defined in this specification Source Semantics of a Foundational Subset for Executable UML Models 1.4
If isControlType=true for an ObjectNode, ControlFlows may be incoming to and outgoing from the ObjectNode, objects tokens can come into or go out of the ObjectNode along ControlFlows, and these tokens can flow along ControlFlows reached downstream ... Source Semantics of a Foundational Subset for Executable UML Models 1.4
Unlike a regular CentralBufferNode, a DataStoreNode contains objects uniquely. Source Unified Modeling Language 2.5.1
When a DataStoreNode accepts an object token, if that token contains an object with the same identity as an object contained in a token already held by the node, then the duplicate object token shall not be placed on the DataStoreNode. Source Unified Modeling Language 2.5.1
... a copy is made of the removed object token, with the same value, and this is immediately placed back onto the DataStoreNode. Thus, the values held by a DataStoreNode appear to persist for the duration of each execution of its containing activity, even Source Unified Modeling Language 2.5.1
When an offer for an object token held by a DataStoreNode is accepted by a downstream object node, the offered token is removed from the DataStoreNode, per the usual CentralBufferNode semantics. However, a copy is made of the removed object token ... Source Unified Modeling Language 2.5.1
15.4.3.4 Data Store Nodes - A DataStoreNode is a CentralBufferNode that holds its object tokens persistently while its activity is executing. Source Unified Modeling Language 2.5.1
Held object tokens are offered to outgoing flows according to the general ordering rules for ObjectNodes. When an offer for a token is accepted by a downstream object node, that token is removed from the CentralBufferNode and moved to the accepting ... Source Unified Modeling Language 2.5.1
15.4.3.3 Central Buffer Nodes - A CentralBufferNode acts as a buffer between incoming ObjectFlows and outgoing ObjectFlows. It accepts all object tokens offered to it on all incoming flows, which are then held by the node. Source Unified Modeling Language 2.5.1
If the upperBound evaluates to *, then there is no limit on the number of tokens the ObjectNode may hold. Source Unified Modeling Language 2.5.1
If the removal of one or more tokens brings the number of tokens held below the evaluated upperBound, then the ObjectNode may accept any pending offers up to the limit of the upperBound. Source Unified Modeling Language 2.5.1
If the number of tokens already held by the ObjectNode is greater than or equal to the evaluated upperBound, then the ObjectNode shall not accept any further tokens until some of the ones it is holding are removed. Source Unified Modeling Language 2.5.1
An ObjectNode may not contain more tokens than specified by its upperBound, if any. If an ObjectNode has an upperBound, then this ValueSpecification shall evaluate to an UnlimitedNatural value. The upperBound is evaluated each time a token is offered ... Source Unified Modeling Language 2.5.1
ObjectNodes may also specify an inState set of States. If such a set is specified, then any object token held by the ObjectNode shall have a value with a type that has or inherits a StateMachine as its classifierBehavior that has all of the states .. Source Unified Modeling Language 2.5.1
Null tokens (object tokens without a value) satisfy the type of all object nodes. Source Unified Modeling Language 2.5.1
ObjectNodes are TypedElements ... If an ObjectNode has a type specified, then any object tokens held by the ObjectNode shall have values that conform to the type of the ObjectNode. If no type is specified, then the values may be of any type. Source Unified Modeling Language 2.5.1
An ObjectNode may contain multiple object tokens with the same value. Such tokens are not normally combined (but see the special semantics for DataStoreNodes ...). Source Unified Modeling Language 2.5.1
Except in the case of an output ActivityParameterNode, tokens held by an ObjectNode may leave the node on outgoing ActivityEdges. Source Unified Modeling Language 2.5.1
Except in the case of an input ActivityParameterNode ... the tokens held by an ObjectNode arrive from incoming ActivityEdges. Source Unified Modeling Language 2.5.1
15.4.3.1 Object Nodes - An ObjectNode holds object tokens during the course of the execution of an Activity. Source Unified Modeling Language 2.5.1
