Tip: When to use UML activity diagrams

First published by IBM at http://www-106.ibm.com/developerworks/webservices/library/ws-tip-whenuml

The activity diagram in Figure 1 depicts the business logic for how someone new to the university would enroll for the first time.

Figure 1. A UML activity diagram for enrolling in school for the first time

• The filled circle represents the starting point of the activity diagram, effectively a placeholder, and the filled circle with a border represents the ending point.
  
  
• The rounded rectangles represent processes or activities that are performed. In this diagram, the activities map reasonably closely to use cases, although you will notice the "Enroll in Seminar(s)" activity would be the invocation of the "Enroll in Seminar" use case several times. Activities can also be much more fine-grained, particularly if I had chosen to document the logic of a method instead of a high-level business process.
  
  
• The diamonds represent decision points, although, in this example, the decision point had only two possible outcomes; it could just as easily have had many more.
  
  
• The arrows represent transitions between activities, modeling the flow order between the various activities.
  
  
• The text on the arrows represent conditions that must be fulfilled to proceed along the transition and are always described using the format "[condition]". I suspect in future versions of the UML, we will see conditions documented using the UML constraint notation such as "{condition}".
  
  
• The thick bars represent the start and end of potentially parallel processes; after you are successfully enrolled in the university, you must attend the mandatory overview presentation, and also enroll in at least one seminar and pay some portion of your tuition.

Figure 2. A use-case diagram for a university

Exiting an activity is possible in several ways, as you see with the "Fill out Enrollment Forms" activity. If your forms are filled out correctly, then you can proceed to enrolling in the university. If your forms aren't correct, however, then you'll have to obtain help, perhaps from a registrar, to fill them out correctly.

This activity diagram is interesting because it cuts across the logic of several of the use cases identified in Figure 2. It's a good thing that use-case models don't communicate the order of processes well. For example, although the use-case diagram presented in Figure 2 gives you a good idea as to the type of functionality this system performs, it offers no definitive answer as to the order in which these use cases might occur. The activity diagram of Figure 1 does, however. In short, different models have different strengths and weaknesses.

Resources

• 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.
  
  
• Structured Systems Analysis: Tools and Techniques by Chris Gane and Trish Sarson. Englewood Cliffs, New Jersey: Prentice Hall, Inc. (1978).
  
  
• The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
  
  

Email Article Print Article Download PDF Digg del.icio.us Newvine furl StumbleUpon BlinkList Newsvine Magnolia Facebook Tailrank Slashdot Technorati Google Bookmarks Yahoo Favorites Windows Live Ask