By Donald Bell
In June 2003, The Rational Edge introduced a new article series by Donald Bell, IBM Global Services, called UML basics. The purpose of this series is to help readers become familiar with the major diagrams that compose much of the UML. Part I offered a general overview of these diagrams; this month, we continue the series with a close look at the activity diagram, including this diagram's complete UML v1.4 notation set.
The purpose of the activity diagram is to model the procedural flow of actions that are part of a larger activity. In projects in which use cases are present, activity diagrams can model a specific use case at a more detailed level. However, activity diagrams can be used independently of use cases for modeling a business-level function, such as buying a concert ticket or registering for a college class. Activity diagrams can also be used to model system-level functions, such as how a ticket reservation data mart populates a corporate sales system's data warehouse.
Because it models procedural flow, the activity diagram focuses on the action sequence of execution and the conditions that trigger or guard those actions. The activity diagram is also focused only on the activity's internal actions and not on the actions that call the activity in their process flow or that trigger the activity according to some event.
Although UML sequence diagrams can protray the same information as activity diagrams, I personally find activity diagrams best for modeling business-level functions. This is because activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram typically shows only one flow of an activity. In addition, business managers and business process personnel seem to prefer activity diagrams over sequence diagrams -- an activity diagram is less "techie" in appearance, and therefore less intimidating to business people. Besides, business managers are used to seeing flow diagrams, so the "look" of an activity diagram is familiar.
The purpose of the activity diagram is to model the procedural flow of actions that are part of a larger activity. In projects in which use cases are present, activity diagrams can model a specific use case at a more detailed level. However, activity diagrams can be used independently of use cases for modeling a business-level function, such as buying a concert ticket or registering for a college class. Activity diagrams can also be used to model system-level functions, such as how a ticket reservation data mart populates a corporate sales system's data warehouse.
Because it models procedural flow, the activity diagram focuses on the action sequence of execution and the conditions that trigger or guard those actions. The activity diagram is also focused only on the activity's internal actions and not on the actions that call the activity in their process flow or that trigger the activity according to some event.
Although UML sequence diagrams can protray the same information as activity diagrams, I personally find activity diagrams best for modeling business-level functions. This is because activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram typically shows only one flow of an activity. In addition, business managers and business process personnel seem to prefer activity diagrams over sequence diagrams -- an activity diagram is less "techie" in appearance, and therefore less intimidating to business people. Besides, business managers are used to seeing flow diagrams, so the "look" of an activity diagram is familiar.
