Activity Diagram

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.

 

Example:


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.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: