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.
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.
Use interaction diagrams when you want to show how objects collaborate to implement an activity diagram. Use a state transition diagram to show how one object changes during its lifetime.
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.