The ‘Initial node’ shows where the activity diagram starts, and kicks off the
diagram. Conversely, the end of the activity diagram is indicated by the ‘Activity
final node‘. These are all the same as in activity diagrams in UML 1.x, but there is
also a new type of ‘Final node’ which is the ‘Flow final node’. A’Flow final node‘
allows a particular flow to be terminated without actually closing the diagram.
For example, imagine a situation where there are two parallel control flows in
a diagram and one needs to be halted whereas the other continues. In this case,
a final flow node would be used as it terminates a single flow but allows the rest
of the diagram to continue.
The ‘Join node’ and ‘Fork node’ allow the flow in a diagram to be split into several
parallel paths and then rejoined at a later point in the diagram. Forks and joins use
the concept of ‘token passing’ that was used in Petri-net systems modelling, which
basically means that whenever a flow is split into parallel flows by a fork, imagine
that each flow has been given a token. These flows can only be joined together
again when all tokens are present on the join flow. It is also possible to specify a
Boolean condition on the join to create more complex rules for rejoining the flows.
The ‘Decision’ and ‘Merge’ nodes also complement one another nicely.
A ‘Decision’ node allows a flow to branch off down a particular route according
to a condition, whereas a ‘Merge’ node allows several flows to be merged back
into a single flow.
The ‘Signal’ symbol is used to show signals passed in and out of the activity
diagram – the same as in a state machine diagram, whereas the ‘Time signal’ allows
the visualisation of explicit timing events.
Partitions can be shown in one of two ways – the traditional swim lane way
by drawing a box or two parallel lines enclosing the relevant region, or by simply
writing the partition name in brackets above the activity name in the activity invocation
symbol. Interruptible regions are shown by a dashed line with an arrow coming out
of it to show where the flow goes in the event of an interruption.
Figure 5.63 shows how a design process behaves.
Note how this diagram uses partitions as swim lanes to show responsibility in the
process. Also, note the cunning use of a package to indicate where one of the objects
has been baselined.
The second example of modelling workflows is one that is taken from the
definition of the RUP, which can be found in almost every UML textbook in existence
today. For a more in-depth discussion of this concept of workflows, see References
2 and 16. For now, however, it is enough to know that the activity diagram is
recommended by the RUP to be the diagram that is used to model workflows.
Figure 5.64. Activity Diagram showing workflow from the RUP
Figure 5.64 shows an activity diagram that describes the behavior of, or how to
execute, a particular workflow. One point worth considering here is the use of the fork
and join nodes. There are two activity invocations that are happening in parallel flows,
but this does not necessarily indicate that the actual activities are being executed in
parallel. What the diagram actually shows is that the flow is split into two flows and
that both activities must complete before the flows can be joined. It could be the case
that both activities do execute in parallel or it could be that one is executed before the
other, or any other permutation. The main point to remember here is that both flows
must complete before they can be joined.
Activity diagrams are actually defined as a special type of state machine diagram,
but it is sometimes difficult to see why two types of diagrams are required when,
it may be argued, they are very similar indeed. The most fundamental conceptual
difference between activity diagrams and state machine diagrams is that activity diagrams
concentrate on activity flow and may thus show behaviour from more than one
type of object, whereas a state machine only shows the behaviour from a single type
of object. As a consequence, state machine diagrams may show wait, or idle, states,
whereas an activity diagram may not. The states in a state machine are normal states,
which means that they may be complex and contain more than one internal transition,
represented by a number of actions or activities, whereas activity invocations may
only contain one. Activity diagrams may also use advanced syntax such as ‘swim
lanes’ and ‘object flow’, which will be discussed briefly in Chapter 6. Swim lanes
allow particular states to be grouped together and associated with a particular class or
object, which is useful for assigning responsibility. Object flows allow the creation
and destruction of objects or classes to be associated with states, which may be used
to show data flow.