The stereotype does not override UML token offering semantics, just indicates what happens to the token when it is accepted. When the stereotype is not applied, the semantics is as in UML, specifically, tokens arriving at object nodes do not replace ... Source OMG Systems Modeling Language (SysML) 1.6
For object nodes that are the target of continuous flows, «overwrite» and «nobuffer» have the same effect. Source OMG Systems Modeling Language (SysML) 1.6
The number of tokens replaced is equal to the weight of the incoming edge, which defaults to 1. Source OMG Systems Modeling Language (SysML) 1.6
Tokens arriving at a full object node with the Overwrite stereotype applied take up their positions in the ordering as normal, if any. The arriving tokens do not take the positions of the removed tokens. Source OMG Systems Modeling Language (SysML) 1.6
For upper bounds greater than one, the token removed is the one that has been in the object node the longest. For FIFO ordering, this is the token that is next to be selected, for LIFO it is the token that would be last to be selected. Source OMG Systems Modeling Language (SysML) 1.6
This is typically used on an input pin with an upper bound of 1 to ensure that stale data is overridden at an input pin. Source OMG Systems Modeling Language (SysML) 1.6
This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired. Source Unified Modeling Language 2.5.1
If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics. Source Unified Modeling Language 2.5.1
However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes ... and ExecutableNodes ...). Source Unified Modeling Language 2.5.1
As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. Source Unified Modeling Language 2.5.1
The ActivityEdges going out of ForkNodes continue to hold the tokens they accept until all pending offers have been accepted by their targets. Source Unified Modeling Language 2.5.1
joinSpec ... This evaluation shall not be interrupted by any new tokens offered during the evaluation, nor shall concurrent evaluations be started when new tokens are offered during an evaluation. The ValueSpecification shall evaluate to a Boolean value. Source Unified Modeling Language 2.5.1
Join nodes may have a joinSpec, which is a ValueSpecification that determines the condition under which the join will emit a token. If a JoinNode has a joinSpec, then this ValueSpecification is evaluated whenever a new token is offered to the JoinNode ... Source Unified Modeling Language 2.5.1
A DecisionNode accepts tokens on its primary incoming edge and offers them to all its outgoing edges. However, each token offered on the primary incoming edge shall traverse at most one outgoing edge. Tokens are not duplicated. Source Unified Modeling Language 2.5.1
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
An ActivityFinalNode is a FinalNode that stops all flows in an Activity (or StructuredActivityNode, see sub clause 16.11). A token reaching an ActivityFinalNode owned by an Activity terminates the execution of that Activity. Source Unified Modeling Language 2.5.1
A FlowFinalNode is a FinalNode that terminates a flow. All tokens accepted by a FlowFinalNode are destroyed. This has no effect on other flows in the Activity. 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
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
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
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
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 ... 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
15.3.3.6 Decision Nodes - A DecisionNode is a ControlNode that chooses between outgoing flows. Source Unified Modeling Language 2.5.1
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
A DecisionNode is a ControlNode that chooses between outgoing ActivityEdges for the routing of tokens. 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
