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. Source Unified Modeling Language 2.5.1
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 ... Source Unified Modeling Language 2.5.1
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). Source Unified Modeling Language 2.5.1
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 ... 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
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
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
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. 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
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
If the primary incoming edge of a DecisionNode is a ControlFlow, then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges shall be ObjectFlows. Source Unified Modeling Language 2.5.1
If it has two incoming edges, then one shall be identified as the decisionInputFlow, the other being called the primary incoming edge. If the DecisionNode has only one incoming edge, then it is the primary incoming edge. 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
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
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
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
decision_input_flow_incoming The decisionInputFlow of a DecisionNode must be an incoming ActivityEdge of the DecisionNode. Source Unified Modeling Language 2.5.1
DecisionNode::edges The ActivityEdges incoming to and outgoing from a DecisionNode, other than the decisionInputFlow (if any), must be either all ObjectFlows or all ControlFlows. Source Unified Modeling Language 2.5.1
zero_input_parameters If the DecisionNode has no decisionInputFlow and an incoming ControlFlow, then any decisionInput Behavior has no in parameters. Source Unified Modeling Language 2.5.1
