UML 2.

x activity diagrams (Object Management Group 2003) are typically used for
business process modeling, for modeling the logic captured by a single use case or
usage scenario, or for modeling the detailed logic of a business rule. Although UML
activity diagrams could potentially model the internal logic of a complex operation it
would be far better to simply rewrite the operation so that it is simple enough that you
dont require an activity diagram. In many ways UML activity diagrams are the objectoriented equivalent of flow charts from structured development.
Lets start by describing the basic notations:

Initial node. The filled in circle is the starting point of the diagram. An initial node
isnt required although it does make it significantly easier to read the diagram.

Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.

Activity. The rounded rectangles represent activities that occur. An activity may be
physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.

Flow(Transitions): The arrows on the diagram. Shows the flow from one state to
another.

Fork. A black bar with one flow going into it and several leaving it. This denotes the
beginning of parallel activity.

Join. A black bar with several flows entering it and one leaving it. This denotes the end
of parallel processing.

Condition. Text such as [Incorrect Form] on a flow, defining a guard which must
evaluate to true in order to traverse the node.

Decision. A diamond with one flow entering and several leaving. The flows leaving
include conditions although some modelers will not indicate the conditions if it is
obvious.

Merge. A diamond with several flows entering and one leaving. The implication is that
all incoming flows must reach this point until processing continues, unless otherwise
noted as in Figure 2 (discussed below).

Partition. Figure 2 is organized into three partitions, also called swimlanes,

indicating who/what is performing the activities (either the Applicant, Registrar, or
System).

Sub-activity indicator. The rake in the bottom corner of an activity, such as in

the Apply to University activity, indicates that the activity is described by a more
finely detailed activity diagram. In Figure 2 the Enroll In Seminar activity includes
this symbol.

Flow final. The circle with the X through it. This indicates that the process stops at this
point.

Note. Figure 2 includes a standard UML note to indicate that the merges does not require
all three flows to arrive before processing can continue. An alternative way to model this
would have been with an OR constraint between the no match and applicant not on
match list flows. I prefer notes because stakeholders find them easier to understand.

Use case. In Figure 1 I indicated that the Enroll in Seminar use case is invoked as one of
the activities. This is a visual cheat that I use to indicate that an included use case is
being invoked. To tell you the truth Im not sure if this is official allowed by the UML
but clearly it should be. Another way to depict this is shown in Figure 2 via the use of a
normal activity although I dont think this is as obvious as using a use case.

The activity diagram of Figure 1 depicts one way to model the logic of the Enroll in University
use case, a very common use of activity diagrams because they enable you to depict both the
basic course of action as well as the alternate courses. Activity diagrams can also be drawn that
cross several use cases, or that address just a small portion of a use case. You can also use
activity diagrams without use cases being involved at all, for example a pair of eXtreme
Programming (XP) developers (Beck 2000) could draw activity diagrams with their customer (the
XP term for stakeholder) to analyze a user story or a larger business process that a user story
supports.

Figure 1. UML activity diagram for the Enroll in University use case.

Figure 1 is notable for several things:

1. It depicts the notation that youre likely to use 90% of the time (Ill discuss the more
esoteric notation later).
2. The use of diamonds for decisions and merges is visually wordy but unfortunately all too
common. In Figure 2 I address this issue by placing conditions on flows leaving
activities instead of introducing additional diamonds to represent decision points.
3. It uses a fork to indicate parallel processing, in this case weve decided that we can
perform some of the checks on the applicant in parallel, something that wasnt easy to
indicate using flow charts.
4. It shows how activity diagrams can get large very quickly. Even though it models the
logic of a single use case I was forced to have it wind around the whiteboard because I
ran out of space. Ideally the diagram should be wider, with the logic going from left-toright across the board. Better yet, it would be nice to have more whiteboard space.

5. It includes a common mistake. At the very end I applied a decision just before the
Process Payment and Print Receipt processes to indicate that they can be done in
parallel. I should have used a fork, not a decision, for that. I should also use a balancing
join, instead of a merge, although either one would be allowed. The join or merge is
required because both processes need to finish before the overall process ends, without
doing this a race condition effectively exists where the first process to finish would end
things.
Figure 2 depicts the Enroll in University use case but takes a different approach than. As noted
above it avoids the use of decision points. It also uses the concept of partitions, also called swim
lanes, to indicate who/what is performing the activity. In this diagram I simply labeled the
partitions with the text Applicant, Registrar, and System although it is also common to put actor
symbols (stick figures) to make it very clear that an actor is performing some activities. Partitions
are useful because they provide more information, but they also elongate the diagram I ran out
of room and was forced to finish the diagram on another whiteboard (not shown), using a
connector (the circle with the letter A in it), to help show how the physical separate portions fit
together. A common use of connectors is to avoid a line going from one side of a diagram to
another. Instead you show a flow entering a connector and a second flow leaving a similarly
labeled connector, e.g. both connectors have the letter B in them, going into the target activity.
Figure 2 also depicts how to apply a flow final, the circle with the X through it, as well as a note
to indicate a constraint on a merge, as noted above.

Figure 2. UML activity diagram with partitions based on actors.

The style of partitions in Figure 2 is often referred to as swim lanes because the partitions look
like the lanes in a swimming pool. Figure 3 takes a different approach, I guess you could call the
partitions swim areas. As you can see swim areas take up less room than swim lanes. Its also
interesting to note that the partitioning strategies between the two diagrams are different Figure
2 is partition by actor whereas Figure 3 is partitioned by courses of action within a use case. As
always, my advice is to use the strategy best suited for your situation.

Figure 3. UML activity diagram with partitions based on alternate courses.

Figure 3 uses a notation that we havent seen before, the five-sided Possible Security Risk signal.
This symbol indicates that an event has occurred, that weve determined that there is a possible
security risk, and therefore the Perform Security Check use case may need to be triggered.
Figure 4 depicts a UML activity diagram for the Distribute Schedules use case, this time Ive used
a drawing tool so you can see a clean example of the notation. The activity starts when the
Schedule Printed signal is received, this signal would be sent from one or more other activity
diagrams, and its April 1st (or later). The hour-glass symbol represents time, and because all of
the flows going into a join must occur before processing can continue the way that you would
read this is that the schedules must be printed and it has to be at least April 1 st. In fact, Ive
chosen to indicate this with a join specification, basically a constraint associated to a join in the
format {joinSpec = }. In this case the join specification is completely redundant so there isnt
any value in indicating it other than the fact that I wanted to show you an example. The only time
that I indicate join specifications is when there is a constraint that isnt obvious from the
incoming flows. For example, if the schedules needed to be distributed before April 21 st then I
would likely indicate this with a join specification.

Figure 4. Distributing schedules.

The square on the side of the Determine Mailing List activity in Figure 4 is called a pin, and the
one on the side of the Print Mailing Label activity is a parameter. The circle on the flow indicates
a transformation, in this case the people on the mailing list are sorted by zip code (the post office
charges less for bulk mailings that are sorted in this manner) and then each individual is listed so
that a mailing label can then be printed for each individual.
The Labeled Schedule box is an example of an object being passed between activities. I rarely
show objects in this manner as I feel this notation is a little bit goofy. You can usually read
between the lines and determine what is flowing between activities, for example it is clear that
labels are being passed from the Print Mailing Label activity to the Attach Labels to Schedules
activity.