NoBuffer::1_not_overwrite The «nobuffer» and «overwrite» stereotypes cannot be applied to the same element at the same time Source OMG Systems Modeling Language (SysML) 1.6
The stereotype does not override UML token offering semantics; it just indicates what happens to the token when it is accepted. When the stereotype is not applied, the semantics are as in UML, specifically, tokens arriving at an object node ... Source OMG Systems Modeling Language (SysML) 1.6
For object nodes that are the target of continuous flows, «nobuffer» and «overwrite» have the same effect. Source OMG Systems Modeling Language (SysML) 1.6
This is typically used with fast or continuously flowing data values, to prevent buffer overrun, or to model transient values, such as electrical signals. Source OMG Systems Modeling Language (SysML) 1.6
When the «nobuffer» stereotype is applied to object nodes, tokens arriving at the node are discarded if they are refused by outgoing edges, or refused by actions for object nodes that are input pins. Source OMG Systems Modeling Language (SysML) 1.6
When the LoopNode begins executing, the tokens on the loopVariableInput InputPins are moved to the corresponding loopVariable OutputPins before the first iteration of the loop. Source Unified Modeling Language 2.5.1
A LoopNode may also define a set of loopVariable OutputPins used to hold intermediate values during each loop iteration. These OutputPins may have outgoing ActivityEdges, in order to make the values they hold available within the test and bodyPart ... Source Unified Modeling Language 2.5.1
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
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
A FinalNode is a ControlNode at which a flow in an Activity stops. A FinalNode shall not have outgoing ActivityEdges. A FinalNode accepts all tokens offered to it on its incoming ActivityEdges. There are two kinds of FinalNode: 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
If the outgoing edge of a MergeNode is a ControlFlow, then all incoming edges must be ControlFlows, and, if the outgoing edge is an ObjectFlow, then all incoming edges must be ObjectFlows. Source Unified Modeling Language 2.5.1
A MergeNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. Source Unified Modeling Language 2.5.1
If any of the incoming edges of a JoinNode are ObjectFlows, the outgoing edge shall be an ObjectFlow. Otherwise the outgoing edge shall be a ControlFlow. Source Unified Modeling Language 2.5.1
A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. Source Unified Modeling Language 2.5.1
Tokens offered to a ForkNode are offered to all outgoing ActivityEdges of the node. If at least one of these offers is accepted, the offered tokens are removed from their original source and the acceptor receives a copy of the tokens. Source Unified Modeling Language 2.5.1
If the incoming edge is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows. Source Unified Modeling Language 2.5.1
A ForkNode is a ControlNode that splits a flow into multiple concurrent flows. A ForkNode shall have exactly one incoming ActivityEdge, though it may have multiple outgoing ActivityEdges. 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
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
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
A DecisionNode shall have at least one and at most two incoming ActivityEdges, and at least one outgoing ActivityEdge. 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
DecisionNode::incoming_outgoing_edges A DecisionNode has one or two incoming ActivityEdges and at least one outgoing ActivityEdge. Source Unified Modeling Language 2.5.1
