UML Diagrams Zicomi Systems publishes some UML example diagrams online from the world famous UML dictionary. more...
Version 2.5 Released Zicomi Systems is delighted to announce that version 2.5 of Zicomi Mentor is released. With support for UML 2.0 and all thirteen UML diagrams more...
Zicomi Systems' Director speaks about the UML at Objects by Design - an informative interview more...
Partner Programme Zicom Systems is delighted to announce a new world wide partner programme, become a partner today. more...
OMG Member Zicom Systems is made a member of the OMG!
A join node is a type of control node that synchronizes a number of incoming flows into a single outgoing flow. Each (and every) incoming control flow must present a control token to the join node before the node can offer a single token to the outgoing flow. If some of the incoming flows are object flows, which carry object (data) tokens, these tokens are all offered to the outgoing flow. A join specification (for complete activities) may be used, which further governs the way that the join will evaluate the arrival of tokens.
When flows have been divided into a number of concurrent flows by upstream fork nodes they typically need to be re-united (joined) to allow other nodes to receive their necessary inputs; this is achieved by the use of one or more join nodes. A join node has two or more incoming flows, which are synchronized into a single outgoing flow. In normal usage of the join (in intermediate activities) control tokens are required to be present on all incoming flows for the join to offer a single token to the outgoing flow. This is equivalent to a logical 'and' in Boolean logic. If any of the incoming flows have data (object) tokens then the data (or objects) in the tokens are all offered to the outgoing flow. In advanced usage of the join node (in complete activities) a join specification can be used which describes the conditions under which the join will occur. This specification if present overrides the default 'and' condition.
All flows regardless of whether they are incoming or outgoing must be either all control flows or all object flows.
A join node is a type of control node and therefore can only manage a single type of flow. So all incoming and outgoing flows must all be of a single type: either control flows carrying control tokens, or object flows carrying data or object tokens, but not a mixture of both types of flows.
A merge node is related to a join node as they both have one or more incoming flows and a single outgoing flow. They have different semantics as a merge is used to unite a number of possible incoming flows only one of which presents a token to the merge, the join reunites concurrent flows where each incoming flow presents a token to the join.
A join pseudostate is related to a join node as they have the same appearance. They have different semantics and are used in different diagrams. A join pseudostate reunites transitions in a state diagram whereas a join node reunites flows in an activity or interaction overview diagram. They are both used to model concurrency.