Activity Diagrams

For many people looking at the latest version of the UML, the
most unfamiliar diagram is the new activity diagram. This is particularly
unfamiliar since it is a diagram that was not present in works
of either Booch, Jacobson, or Rumbaugh. In fact it is based upon
the event diagram of Odell, although the notation is very different
to that in Odell's books.

The activity diagram focuses on activities, chunks of process
that may or may not correspond to methods or member functions,
and the sequencing of these activities. In this sense it is like
a flow chart. It differs, however, from a flow chart in that it
explicitly supports parallel activities and their synchronization.
In the diagram we see the receive order activity triggers both
the authorize payment and the check line item activities. Indeed
the check line item is triggered for each line item on the order.
Thus if an order has three line items the receive order activity
would trigger four activities in parallel, leading (at least conceptually)
to four separate threads. These threads, together with other threads
started by the receive supplies activity, are synchronized before
the order is dispatched.

Note that this diagram does not have an end point. This is typical
of activity diagrams that define a business process which synchronizes
several external incoming events. You can think of the diagram
of defining the reaction to that process, which continues until
everything that needs to be done is done. You can also draw activity
diagrams with a single start and end point; such procedural diagrams
are more like the conventional procedure invocations. Such procedural
diagrams can also use parallel behavior.

The biggest disadvantage of activity diagrams is that they do
not make explicit which objects execute which activities, and
the way that the messaging works between them. You can label each
activity with the responsible object, but that does not make the
interactions between the objects clear (that's when you need to
use an interaction diagram). Often
it is useful to draw an activity diagram early on in the modeling
of a process, to help you understand the overall process. Then
you can use interaction diagrams to help you allocate activities
to classes.

When to Use Them

Activity diagrams are useful when you want to describe a behavior
which is parallel, or when you want to show how behaviors in several
use-cases interact.

Where to Find Out More

The best source for information here is [Odell foundations].
He gives a thorough description of event diagrams, which are the
original source for activity diagrams. Unfortunately the notation
is different, but the underlying concepts are very much the same.