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!
Fork Node
A fork node is a control node that has a single incoming flow and two or more outgoing flows. Incoming tokens are offered to all outgoing flows (edges). The outgoing flows can be guarded which gives them a mechanism to accept or reject a token. If the token is accepted by an outgoing edge it is duplicated so as to create a copied token for each outgoing flow that has accepted the token. The incoming flow and all outgoing flows must be either all control flows or all object flows. Tokens cannot be detained at the node; the token copying is effectively instantaneous.
Explanation
A fork node allows a number of concurrent flows to be created. It has a single incoming flow and when a token arrives it is offered to all the outgoing flows. There may be conditions (guards) on the outgoing flows which when evaluated will determine if a particular flow will accept the token or not. For every flow that will accept the token a duplicate of the token is created and passes out via the flow. Tokens may not reside at a fork node. Many systems require that a number of actions are carried out or performed at the same time. In our daily lives we often carry out a number of tasks at once. We can be talking on the phone and still continue to do other work at the same time. A fork provides a mechanism to divide a flow into a number of concurrent (parallel) flows that can then be used to represent this concurrent behavior.
Important Points
All flows regardless of whether they are incoming or outgoing must be either all control flows or all object flows.
A fork 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.
An outgoing edge can be guarded.
An outgoing edge can be guarded by a condition that determines whether the flow will accept the token.
A join node is related to a fork node as a paired element. The join node is used to re-unite flows that have been split by a fork further upstream in an activity or interaction overview diagram.
A decision node is related to a fork node as they both have a single incoming flow and one or more outgoing flows. They have different semantics as a decision is used to choose one (and only one) of a number of possible outgoing flows the fork creates concurrent flows such that all outgoing flows are offered a token.
A fork pseudostate is related to a fork node as they have the same appearance. They have different semantics and are used in different diagrams. A fork pseudostate divides transitions in a state diagram whereas a fork node splits flows in an activity or interaction overview diagram. They are both used to model concurrency.