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
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
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
A MergeNode is a control node that brings together multiple flows without synchronization. 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
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
InitialNodes are an exception to the rule that ControlNodes cannot “hold” tokens, but only manage their flow. 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
An InitialNode shall not have any incoming ActivityEdges, which means the InitialNodes owned by an Activity will always be enabled when the Activity begins execution and a single control token is placed on each such InitialNode when Activity execution sta Source Unified Modeling Language 2.5.1
Generally, the ControlNodes and ObjectNodes in an Activity are largely there to control the sequencing and to manage the flow of data between the ExecutableNodes of the Activity. Source Unified Modeling Language 2.5.1
uml101 - Activity Diagram - notation - REFERENCE CARD 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 Activity Diagram
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
15.3.3.6 Decision Nodes - A DecisionNode is a ControlNode that chooses between outgoing flows. Source Unified Modeling Language 2.5.1
decisionInputFlow : ObjectFlow [0..1] ... An additional ActivityEdge incoming to the DecisionNode that provides a decision input value for the guards ValueSpecifications on ActivityEdges outgoing from the DecisionNode. Source Unified Modeling Language 2.5.1
decisionInput : Behavior [0..1] ... A Behavior that is executed to provide an input to guard ValueSpecifications on ActivityEdges outgoing from the DecisionNode. 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
If an Activity has more than one InitialNode, then invoking the Activity starts multiple concurrent control flows, one for each InitialNode. (Additional concurrent flows may begin at input ActivityParameterNodes and enabled ExecutableNodes ... Source Unified Modeling Language 2.5.1
An InitialNode is a ControlNode that acts as a starting point for executing an Activity. Source Unified Modeling Language 2.5.1
