Snippets (text quotes and extracts from authoritative sources)

A Snippet is a short quote or extract (typically a phrase, a sentence, or at most a few sentences) from an authoritative source document such as a specification, technical manual, or design manual. Throughout this site, content is often related to supporting Snippets and each Snippet page links back to the content pages that reference it! The Snippet and Note concepts are very closely related and they support each other.

The Snippet concept is also at the heart of the Parsing Analysis recipe for UML® and SysML®

Kind Snippet quote/extract Source UML keywords SysML keywords Keywords
INFO The system is unstable: the two particles annihilate each other to predominantly produce two or three gamma-rays, depending on the relative spin states. Wikipedia
INFO Thus electrons are stable and the most common charged lepton in the universe, whereas muons and taus can only be produced in high energy collisions (such as those involving cosmic rays and those carried out in particle accelerators). Wikipedia
INFO The heavier muons and taus will rapidly change into electrons and neutrinos through a process of particle decay: the transformation from a higher mass state to a lower mass state. Wikipedia
INFO Electrons have the least mass of all the charged leptons. Wikipedia
INFO and the third are the tauonic leptons, comprising the tau ( τ− ) and the tau neutrino ( ν τ) Wikipedia
INFO the second are the muonic leptons, comprising the muon ( μ− ) and the muon neutrino ( ν μ); Wikipedia
INFO The first-generation leptons, also called electronic leptons, comprise the electron ( e− ) and the electron neutrino ( ν e); Wikipedia
INFO There are six types of leptons, known as flavours, grouped in three generations. Wikipedia
INFO The best known of all leptons is the electron. Wikipedia
INFO Positronium (Ps) is a system consisting of an electron and its anti-particle, a positron, bound together into an exotic atom, specifically an onium. Wikipedia
INFO Charged leptons can combine with other particles to form various composite particles such as atoms and positronium, while neutrinos rarely interact with anything, and are consequently rarely observed. Wikipedia
INFO Two main classes of leptons exist, charged leptons (also known as the electron-like leptons), and neutral leptons (better known as neutrinos). Wikipedia
INFO In particle physics, a lepton is an elementary particle of half-integer spin (spin ​1⁄2) that does not undergo strong interactions. Wikipedia
INFO «effbd» Specifies that the activity conforms to the constraints necessary for EFFBD. OMG Systems Modeling Language (SysML) 1.6 Activity «effbd» non-normative
INFO «nonStreaming» Used for activities that accept inputs only when they start, and provide outputs only when they finish. The activity has no streaming parameters. OMG Systems Modeling Language (SysML) 1.6 Activity «nonStreaming» non-normative
INFO «streaming» Used for activities that can accept inputs or provide outputs after they start and before they finish. The activity has at least one streaming parameter. OMG Systems Modeling Language (SysML) 1.6 Activity «streaming» non-normative
INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper, InputPin, Action::/input, token Overwrite, «overwrite»
INFO For object nodes that are the target of continuous flows, «overwrite» and «nobuffer» have the same effect. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper, InputPin, Action::/input, token Overwrite, «overwrite», Continuous, «continuous», NoBuffer, «noBuffer»
INFO The number of tokens replaced is equal to the weight of the incoming edge, which defaults to 1. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper, InputPin, Action::/input, token Overwrite, «overwrite»
INFO A null token removes all the tokens already there. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper, InputPin, Action::/input, token, null token, null Overwrite, «overwrite»
INFO 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. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper, InputPin, Action::/input, token Overwrite, «overwrite»
INFO 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. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper, InputPin, Action::/input, token, ObjectNodeOrderingKind::FIFO, ObjectNodeOrderingKind::LIFO, ObjectNodeOrderingKind Overwrite, «overwrite»
INFO 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. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper, InputPin, Action::/input, token Overwrite, «overwrite»
INFO When the «overwrite» stereotype is applied to object nodes, a token arriving at a full object node removes one that is already there before being added (a full object node has as many tokens as allowed by its upper bound). OMG Systems Modeling Language (SysML) 1.6 ObjectNode, MultiplicityElement::/upper Overwrite, «overwrite»
INFO NoBuffer::1_not_overwrite The «nobuffer» and «overwrite» stereotypes cannot be applied to the same element at the same time OMG Systems Modeling Language (SysML) 1.6 ObjectNode, ActivityNode::outgoing, InputPin, Action::/input «noBuffer», NoBuffer, Overwrite, «overwrite»
INFO 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 ... OMG Systems Modeling Language (SysML) 1.6 ObjectNode, ActivityNode::outgoing, InputPin, Action::/input «noBuffer», NoBuffer
INFO For object nodes that are the target of continuous flows, «nobuffer» and «overwrite» have the same effect. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, ActivityNode::outgoing, InputPin, Action::/input «noBuffer», NoBuffer, Continuous, «continuous», «overwrite», Overwrite
INFO This is typically used with fast or continuously flowing data values, to prevent buffer overrun, or to model transient values, such as electrical signals. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, ActivityNode::outgoing, InputPin, Action::/input «noBuffer», NoBuffer
INFO 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. OMG Systems Modeling Language (SysML) 1.6 ObjectNode, ActivityNode::outgoing, InputPin, Action::/input «noBuffer», NoBuffer
INFO Discrete rate is a special case of rate of flow ... where the increment of time between items is a non-zero. Examples include the production of assemblies in a factory and signals set at periodic time intervals. OMG Systems Modeling Language (SysML) 1.6 Discrete, «discrete», Rate, Rate::rate
CONSTRAINT, INFO When the «probability» stereotype is applied to output parameter sets, it gives the probability the parameter set will be given values at runtime. These shall be between zero and one inclusive, and add up to one for output parameter sets of the same ... OMG Systems Modeling Language (SysML) 1.6 Parameter::parameterSet, ParameterSet «probability», Probability, Probability::probability
CONSTRAINT, INFO When the «probability» stereotype is applied to edges coming out of decision nodes and object nodes, it provides an expression for the probability that the edge will be traversed. These shall be between zero and one inclusive, and add up to one ... OMG Systems Modeling Language (SysML) 1.6 DecisionNode, ObjectNode, ActivityEdge «probability», Probability, Probability::probability
CONSTRAINT 1_lower_is_0 A parameter with the «optional» stereotypes applied shall have multiplicity.lower equal to zero, otherwise multiplicity.lower shall be greater than zero OMG Systems Modeling Language (SysML) 1.6 Parameter, MultiplicityElement::/lower, multiplicity «optional», Optional, required
INFO When the «optional» stereotype is applied to parameters, the lower multiplicity shall be equal to zero. This means the parameter is not required to have a value for the activity or any behavior to begin or end execution ... OMG Systems Modeling Language (SysML) 1.6 Parameter, MultiplicityElement::/lower, multiplicity «optional», Optional, Optional, required
INFO Once the test fails and the loop is completed, the tokens on the bodyOutput OutputPins from the last iteration are moved to the result OutputPins and offered on any edges outgoing from those OutputPins. Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::loopVariable, OutputPin, LoopNode::bodyOutput
INFO After the completion of each execution of the bodyPart of the LoopNode, any remaining tokens on the loopVariable OutputPins are destroyed and tokens on the bodyOutput OutputPins are copied to the corresponding loopVariable OutputPins so that they are ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::loopVariable, OutputPin, LoopNode::bodyOutput
INFO 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::loopVariable, ActivityNode::outgoing, ActivityEdge, OutputPin, LoopNode::loopVariableInput, InputPin
INFO If a LoopNode has loopVariable OutputPins, then it must also have matching sets of loopVariableInput InputPins, bodyOutput OutputPins (owned by Actions within the bodyPart), and result OutputPins. Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::loopVariable, OutputPin, LoopNode::loopVariableInput, LoopNode::bodyOutput, LoopNode::result, InputPin
INFO 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 ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::test, LoopNode::loopVariable, ActivityNode::outgoing, ActivityEdge, OutputPin
INFO After each execution of the bodyPart, the test section is executed again, for the next iteration of the loop. Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::test, LoopNode::bodyPart, LoopNode:decider
INFO The test section has an Action owning the decider OutputPin with type Boolean identified by the LoopNode. When the test section has completed execution, if the value on the decider OutputPin is true, then the bodyPart is executed. Otherwise ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::test, LoopNode::bodyPart, LoopNode:decider
INFO Execution of the test section may precede or follow execution of the bodyPart, depending on whether isTestFirst is true or false, respectively. ... If the bodyPart is executed first (isTestFirst=false), it is always executed at least once ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::test, LoopNode::bodyPart, LoopNode::isTestedFirst
INFO The setupPart of a LoopNode is executed first. When the setupPart has completed execution, the iterative execution of the loop begins. Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::setupPart
INFO Any ExecutableNode in the LoopNode must be included in the setupPart, test or bodyPart for the LoopNode. Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::setupPart, LoopNode::test, LoopNode::bodyPart, ExecutableNode
INFO A LoopNode is a StructuredActivityNode that represents an iterative loop. A LoopNode consists of a setupPart, a test and a bodyPart, which identify subsets of the ExecutableNodes contained in the LoopNode. Unified Modeling Language 2.5.1 Activity, Activity Diagram, LoopNode, LoopNode::setupPart, LoopNode::test, LoopNode::bodyPart, ExecutableNode
INFO 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. Unified Modeling Language 2.5.1 ActivityEdge, ActivityNode::outgoing, ActivityNode, token
INFO 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. Unified Modeling Language 2.5.1 ActivityEdge, ActivityNode::outgoing, ActivityNode, token
INFO 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 ...). Unified Modeling Language 2.5.1 ForkNode, ActivityEdge, ActivityNode::outgoing, ActivityNode, token, ExecutableNode
INFO As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. Unified Modeling Language 2.5.1 ActivityEdge, ActivityNode::outgoing, ActivityNode, token
INFO The ActivityEdges going out of ForkNodes continue to hold the tokens they accept until all pending offers have been accepted by their targets. Unified Modeling Language 2.5.1 ForkNode, ActivityEdge, ActivityNode::outgoing, token
CONSTRAINT If a JoinNode does not have a joinSpec, then this is equivalent to a joinSpec Expression with the Boolean operator “and.” That is, the implicit default joinSpec condition is that there is at least one token offered on each incoming ActivityEdge. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean
CONSTRAINT Alternatively, the joinSpec may consist of an Expression with the name of a single Boolean operator and no operands specified. In this case, the value of the joinSpec shall be given by applying the given operator to Boolean values indicating ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean, Expression
CONSTRAINT If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote ... the value associated with an object token offered from an ObjectFlow (if any). Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean, ValueSpecification
CONSTRAINT If the joinSpec ValueSpecification is given by a textual expression, then the names of the incoming edges may be used to denote a Boolean value indicating the presence (true) or absence (false) of an offer from a ControlFlow ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, Boolean, ValueSpecification
CONSTRAINT 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, ValueSpecification, token, Boolean
CONSTRAINT 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 ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::incoming, ActivityEdge, JoinNode::joinSpec, ValueSpecification, token
INFO a predefined guard “else” (represented as an Expression with “else” as its operator and no operands) may be used for at most one outgoing edge. This guard evaluates to true only if the token is not accepted by any other outgoing edge from the DecisionNode Unified Modeling Language 2.5.1 DecisionNode, Activity Diagram, [else]
CONSTRAINT 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. Unified Modeling Language 2.5.1 DecisionNode, ControlNode, ActivityEdge, ActivityNode::incoming, primary incoming edge, ControlFlow, ObjectFlow, token, ActivityNode::outgoing
INFO 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 Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, InputPin, Action::/input, Parameter::isStreaming
INFO For structured Actions (StructuredActivityNodes ... ), data can remain on InputPins during Action execution, otherwise they are immediately removed from the InputPins by the ActionExecution. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, InputPin, Action::/input, StructuredActivityNode, ActionExecution
INFO The Action execution consumes input data on all InputPins on the Action up to the upper multiplicity for each InputPin. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, InputPin, Action::/input, MultiplicityElement::/upper
INFO However, if the Action is an invocation of a Behavior with streaming Parameters ... then the Action execution may also post data to OutputPins corresponding to streaming output Parameters before completion of the execution ... Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, completion, termination, Action::/output, OutputPin, InvocationAction, Parameter::isStreaming, ParameterDirectionKind::out
INFO When completed, an Action execution provides any output data on the OutputPins of the Action, and it terminates. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, completion, termination, Action::/output, OutputPin
INFO An Action continues executing until it has completed. The detailed semantics of the execution of an Action and the definition of its completion depend on the particular kind of Action being executed. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, completion
INFO 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, execution, Action::/input, InputPin, Behavior
INFO When an Action in an Activity completes execution, object tokens for output data placed on its OutputPins may be offered on any outgoing ObjectFlows from those Pins ... In addition, control tokens shall be offered on any outgoing ControlFlows ... Unified Modeling Language 2.5.1 Action, Activity, OutputPin, ObjectFlow, ObjectNode, ControlFlow, ExecutableNode, execution, completion, run-to-completion
INFO A ValuePin provides a value by evaluating a ValueSpecification ... When the Action is enabled by other means, the ValueSpecifiation of the ValuePin is evaluated, and the result is provided as an input to the Action when it begins execution. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, ValuePin, ValueSpecification, ValuePin::value
INFO When the Action is enabled by other means, values are computed as specified for the ValuePins and ActionInputPins owned by an Action, and the results are provided as inputs to the Action when it begins execution. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, ValuePin, ActionInputPin, execution
INFO ValuePins and ActionInputPins are InputPins, but are not used in the determination of whether an Action is enabled for execution. If an Action has no other way to start execution, simply having ValuePins or ActionInputPins for its inputs will not enable.. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, ValuePin, ActionInputPin, execution
INFO An Action may not put more values into an output in a single execution than the [upper] multiplicity of that OutputPin. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, OutputPin, Action::/output, execution, MultiplicityElement::/upper
INFO For each execution, an Action cannot terminate itself unless it can put at least as many values into its outputs as required by the multiplicity lower bounds on those OutputPins. Values that may remain on the OutputPins from previous executions are not... Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, OutputPin, Action::/output, execution, MultiplicityElement::/lower
INFO An OutputPin is a Pin that holds output values produced by an Action. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, OutputPin, Action::/output
INFO 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 ...) Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input, MultiplicityElement::/lower, execution, StructuredActivityNode, token, control token, object token
INFO The upper multiplicity determines the maximum number of values that can be consumed from an InputPin by a single execution of its Action. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input, MultiplicityElement::/upper, execution
INFO An Action cannot start execution if one of its InputPins has fewer values than the lower multiplicity of that InputPin. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input, MultiplicityElement::/lower, execution
INFO An InputPin is a Pin that holds input values to be consumed by its Action. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, Action::/input
INFO Action::/output : OutputPin [0..*] ... The ordered set of OutputPins representing outputs from the Action. Unified Modeling Language 2.5.1 Action, Action::/output, OutputPin
INFO 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, OutputPin, Action::/input, Action::/output, multiplicity, Type
INFO Pins are used to specify the inputs and outputs for Actions. Unified Modeling Language 2.5.1 Activity, Activity Diagram, Action, Pin, InputPin, OutputPin, Action::/input, Action::/output
INFO 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, FinalNode, termination, token, ActivityFinalNode
INFO 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, FinalNode, FlowFinalNode, termination, token
INFO 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: Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, FinalNode, ActivityFinalNode, FlowFinalNode, ActivityNode::outgoing, ActivityNode::incoming
INFO An OpaqueAction is an Action whose specification may be given in a textual concrete syntax other than UML. An OpaqueAction may also be used as a temporary placeholder before some other kind of Action is chosen. Unified Modeling Language 2.5.1 Activity Diagram, Activity, OpaqueAction, Action
CONSTRAINT 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode, ActivityNode::outgoing, ActivityNode::incoming, token, control token, object token
CONSTRAINT 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode, ActivityNode::outgoing, ActivityNode::incoming, ControlFlow, ObjectFlow
CONSTRAINT A MergeNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode, ActivityNode::outgoing, ActivityNode::incoming
INFO A MergeNode is a control node that brings together multiple flows without synchronization. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, MergeNode
CONSTRAINT 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::outgoing, ActivityNode::incoming, ActivityEdge
INFO A JoinNode is a ControlNode that synchronizes multiple flows. A JoinNode shall have exactly one outgoing ActivityEdge but may have multiple incoming ActivityEdges. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, JoinNode, ActivityNode::outgoing, ActivityNode::incoming, ActivityEdge
INFO 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, ForkNode, ActivityNode::outgoing, ActivityEdge
CAVEAT 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, ForkNode, ActivityNode::incoming, ActivityNode::outgoing, ControlFlow, ObjectFlow
INFO 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. Unified Modeling Language 2.5.1 Activity, Activity Diagram, ControlNode, ForkNode, ActivityNode::incoming, ActivityNode::outgoing
SEMANTIC ExecutableNodes actually carry out the desired behavior of an Activity. If an ExecutableNode has incoming ControlFlows, then there must be tokens offered on all these flows that it accepts before beginning execution. Unified Modeling Language 2.5.1 Activity, ActivityNode, ExecutableNode, Action, ActivityNode::incoming, ControlFlow
SEMANTIC 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 ...). Unified Modeling Language 2.5.1 Activity, ActivityNode, ObjectNode::isControlType, ObjectNode, ActivityNode::incoming, ActivityNode::outgoing, object token
SEMANTIC ControlNodes act as “traffic switches” managing the flow of tokens across ActivityEdges. Tokens cannot “rest” at ControlNodes (with exceptions for InitialNodes and ForkNodes ...). Unified Modeling Language 2.5.1 Activity, ActivityNode, ControlNode, token, control token, object token, ActivityEdge, InitialNode, ForkNode
SEMANTIC There are three kinds of ActivityNodes: Unified Modeling Language 2.5.1 Activity, ActivityNode, ControlNode, ObjectNode, ExecutableNode
SEMANTIC Unlike ControlFlows, ObjectFlows also provide additional support for multicast/receive, token selection from ObjectNodes and transformation of tokens Unified Modeling Language 2.5.1 Activity, ActivityEdge, ObjectFlow, object token, token, ObjectFlow::selection, ObjectFlow::transformation, ObjectNode, multicast
SEMANTIC An ObjectFlow is an ActivityEdge that can have object tokens passing along it. ObjectFlows model the flow of values between ObjectNodes. Unified Modeling Language 2.5.1 Activity, ActivityEdge, ObjectFlow, object token, token
SEMANTIC 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. Unified Modeling Language 2.5.1 Activity, ActivityEdge, ControlFlow, ActivityNode, ActivityEdge::target, ActivityEdge::source, execution, control token
SEMANTIC A ControlFlow is an ActivityEdge that only passes control tokens (and some object tokens as specified by modelers, see isControlType for ObjectNodes ...). Unified Modeling Language 2.5.1 Activity, ActivityEdge, ControlFlow, ObjectNode::isControlType, control token, object token, ObjectNode