UML 2 activity diagrams are typically used for
business process modeling, for modeling the logic captured by a single
use caseor 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 don't
require an activity diagram. In many ways UML activity diagrams are the object-oriented equivalent of
flow charts and
data flow diagrams (DFDs) from structured development.
Let's start by describing the basic notation (there's more) that I've used in Figures 1
and 2:
- Initial node. The filled in circle is the starting point of the diagram. An initial node isn't
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/edge. The arrows on the diagram. Although there is a subtle difference between flows and
edges I have never seen a practical purpose for the difference although I have no doubt one exists. I'll
use the term flow.
- 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. All flows going into the
join must reach it before processing may continue. 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 one or more
incoming flows must reach this point until processing continues, based on any guards on the outgoing
flow.
- 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 I'm 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 don't 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:
- It depicts the notation that you're likely to use 90% of the time (I'll discuss the more esoteric
notation later).
- It is incorrect. You can enter the join but never get out of it. When you look at the logic, you see
that you'll either
Create a Student Record and then enter the join, or you could enter the join directly from
Display List of Potential Matches when the applicant is on the list. One but not both of these
things will happen, but both are required for you to exit the join. I really should have used a merge (a
diamond) instead of a join bar. Should I update the diagram? No, because agile models are
just barely good enough to get the job done (this one is, IMHO) and because agile modelers follow
the practice
update only when it hurts, and there isn't enough motivation to update this diagram (chances are
very good that once you implemented the logic contained within it that you'd simply erase it anyway).
- 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.
- It uses a fork to indicate parallel processing, in this case we've decided that we can perform some of
the checks on the applicant in parallel, something that wasn't easy to indicate using flow charts.
- 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-to-right across the board. Better yet, it would
be nice to have more whiteboard space.
- 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. It's 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 haven't seen before, the five-sided
Possible Security Risk signal. This symbol indicates that an event has occurred, that we've 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 I've 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 it's 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 1st. In fact, I've 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 isn't 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 isn't obvious from
the incoming flows. For example, if the schedules needed to be distributed before April 21st
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 Labelactivity 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.
This artifact description is excerpted from Chapter 9 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
The notation used in these diagrams, particularly the hand drawn ones, may not conform perfectly to the
current version of the UML for one or more of reasons:
- The notation may have evolved from when I originally developed the diagrams. The UML evolves over time,
and I may not have kept the diagrams up to date.
- I may have gotten it wrong in the first place. Although these diagrams were thoroughly reviewed for the
book, and have been reviewed by thousands of people online since then, an error may have gotten past of
us. We're only human.
- I may have chosen to apply the notation in "non-standard" ways. An agile modeler is more interested in
created models which communicate effectively than in conforming to notation rules set by a committee.
- It likely doesn't matter anyway, because the
modeling tool(s) that you're using likely won't fully support the current version of the UML
notation perfectly anyway. Bottom line is that you're going to be constrained by your tools anyway.
If you're really concerned about the nuances of "official" UML notation then read the current version of the
UML specification.