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
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
UML2 Types of Pins - metaclasses This content has been marked as discussing an ADVANCED topic! Gallery Tutorial TRAIL: Webel's ultimate guide to Systems Modeling Language (v1) with MagicDraw/Cameo Section 01:04: UML Behavior: Activities quick start Slide kind UML Profile Diagram
If the Action is an invocation of a Behavior with streaming Parameters ... the Action execution may consume additional data supplied to InputPins corresponding to streaming input Parameters ... Otherwise ... any additional data on InputPins has no effect Source Unified Modeling Language 2.5.1
For structured Actions (StructuredActivityNodes ... ), data can remain on InputPins during Action execution, otherwise they are immediately removed from the InputPins by the ActionExecution. Source Unified Modeling Language 2.5.1
The Action execution consumes input data on all InputPins on the Action up to the upper multiplicity for each InputPin. Source Unified Modeling Language 2.5.1
The time at which an Action executes and what inputs are accepted by each execution are determined by the kind of Action it is, characteristics of its InputPins, and the Behavior in which it is used. 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
The upper multiplicity determines the maximum number of values that can be consumed from an InputPin by a single execution of its Action. Source Unified Modeling Language 2.5.1
An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin. Source Unified Modeling Language 2.5.1
An InputPin is a Pin that holds input values to be consumed by its Action. Source Unified Modeling Language 2.5.1
An Action may accept inputs and produce outputs, as specified by InputPins and OutputPins of the Action, respectively. Each Pin on an Action specifies the type and multiplicity for a specific input or output of that Action. Source Unified Modeling Language 2.5.1
Action::/input : InputPin [0..*] ... The ordered set of InputPins representing the inputs to the Action. Source Unified Modeling Language 2.5.1
A ValueSpecificationAction may not have any InputPins, because Action::/input:InputPin[0..*] is a derived union, and ValueSpecificationAction does not specify any InputPin subsets
