1. Identify the scope of the activity diagram
Begin by identifying what it is you are modeling. Is it a single use case? A portion of a use case? A business process that includes several use cases? A single method of a class? Once you identify the scope of your diagram, you should add a label at the top, using a note, indicating an appropriate title for the diagram and a unique identifier for it. You may also want to include the date and even the names of the authors of the diagram.
Every activity diagram has a starting point and an ending point, so you might as well add them right away. In UML Distilled (see Resources), Fowler and Scott make ending points optional. Sometimes an activity is simply a dead end but, if this is the case, then there is no harm in indicating the only transition is to an ending point. This way, when someone else reads your diagram, he or she knows you have considered how to exit these activities.
If you are modeling a use case, introduce an activity for each major step initiated by an actor (this activity would include the initial step, plus any steps describing the response of the system to the initial step). If you are modeling a high-level business process, introduce an activity for each major process, often a use case or a package of use cases. Finally, if you are modeling a method, then it is common to have an activity for this step in the code.
4. Add transitions from the activities
My style is always to exit an activity, even if it is simply to an ending point. Whenever there is more than one transition out of an activity, you must label each transition appropriately.
Sometimes the logic of what you are modeling calls for a decision to be made. Perhaps something needs to be inspected or compared to something else. Important to note is that the use of decision points is optional. For example, in Figure 1 I could just as easily have modeled the accepted and rejected transitions straight out of the "Enroll in University" activity.
6. Identify opportunities for parallel activities
Two activities can occur in parallel when no direct relationship exists between them and they must both finish before a third activity can. In Figure 1 you see it is possible to attend the overview or enroll in seminars in either order, but both activities must occur before you can end the overall process.
Figure 1. A UML activity diagram for enrolling in school for the first time

-
Building
Object Applications That Work: Your Step-By-Step Handbook for Developing Robust
Systems with Object Technology
by Scott W. Ambler. New York: Cambridge
University Press, 1998.
-
The Object Primer 2nd
Edition
by Scott W. Ambler. New York: Cambridge University Press, 2000.
-
UML Distilled: Applying the Standard Object Modeling Language
by
Martin Fowler, Ivar Jacobson, and Kendall Scott. Reading, MA: Addison-Wesley
Longman, Inc, 1997.
-
The Unified Modeling Language Reference Manual
by James Rumbaugh,
Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
Scott W. Ambler is President of Ronin International, a consulting firm specializing in object-oriented software process mentoring, architectural modeling, and Enterprise JavaBeans (EJB) development. He has authored or co-authored several books about object-oriented development, including the recently released The Object Primer 2nd Edition, which covers, in detail, the subjects summarized in this article. He can be reached at scott.ambler@ronin-intl.com and at his Web site at www.ambysoft.com.
Comments (Undergoing maintenance)





