Activity Diagrams
The principle diagram for workflow modeling is the Activity Diagram. While the basic notation looks similar to the traditional flow chart, it does contain many significant differences as well as numerous enhancements that make the Activity Diagram preferable in practice. The remainder of this article will present some of the most salient notational devices and their practical application in workflow modeling and business process analysis. It is important to realize that not all of the symbology of UML is necessary for building effective workflow models. Of course, there are a number of other UML diagrams that are also important for business analysis, including the use case diagram for user requirements modeling, the class diagram for data modeling, and the state diagram for complex business rule modeling. The discussion of these diagrams is beyond the scope of this article, but will be addressed in subsequent articles.
A basic Activity Diagram for workflow modeling consists of the following elements:
- A set of sequentially performed activities representing the tasks to be accomplished
- A set of decisions that guide the flow of control based on conditions that are encountered during the workflow
- A set of partitions that allocate the activities among the responsible parties that participate in the workflow
- A set of terminal activities that indicate the start and end of the workflow
- A set of regions that indicate repetition and concurrency
An Example
To illustrate the process of constructing an Activity Diagram and to demonstrate the use of the different notational elements, let’s consider an example workflow. We are going to model the process of fulfilling an order for a beverage at an upscale coffee shop. The process can be described with the following narrative:
- This process starts when the customer places an order
- The cashier enters the beverage order into the point-of-sale system (POS)
- The cashier asks for the customer’s name and notes it on the order
- The customer pays for the order
- The cashier communicates the order details to the barista (person making the beverage)
- The barista prepares the beverage order
- Upon completion of the order, the barista places the beverage on the pick-up counter and calls the customer’s name
- The process ends when the customer picks up the beverage
Sequential Activities
An activity representing a task to be carried out by one workflow participant is graphically shown as a rounded corner rectangle. It is connected to the next activity in the workflow sequence by a solid line with an open arrow. In Figure 1, the activity “place order” is performed first and once completed, the second activity “enter order into POS” happens. The start of a workflow is indicated with a start activity (filled circle) while the end is indicated with a terminal activity (filled circle with another circle around it). The activities themselves therefore are not numbered.
Figure 1. Sequence of two activities. The “dog-ear” boxes represent notes. While color
is useful in distinguishing semantics, it is not a part of UML syntax.
There is no indication yet as to who carries out the activities. Figure 2 shows the entire workflow with the activities placed into partitions that indicate which person is responsible for those activities. Note that the placement of the activity nodes has no meaning, although it is a convention to keep the flow going from left to right and from top to bottom.
Figure 2. Workflow with partitions showing who does what work. The workflow
starts with a special start (or initial) activity and end with a final activity.
Decisions and Branches
Many times during a workflow, some condition may occur that causes the flow to branch, and different activities are carried out in response to the outcome of the condition. In the UML Activity Diagram, a decision is shown graphically with a diamond shaped icon from which at least two control flows emanate. Each control flow is tagged with the condition that would cause the flow to proceed in that direction. This is different from the classic flow chart approach where the decision icon contains a question that is either affirmed or negated (“yes” or “no” labels on the branches are the most common way to show this in a flow chart.) The approach in UML makes it possible to have more than two outgoing control flows from a decision. The labels on the outgoing control flows are called guard conditions in the UML vernacular and are placed into a pair of square brackets (‘[ … ]’). The naming of the guard condition can be formal or informal – UML does not have any prescriptive format for the writing of the guard conditions. For business analysis, it is best to keep the guard conditions simple and expressed as simple narratives.
To illustrate this concept, let’s extend our workflow example. Perhaps it is possible that the barista might run out of the ingredients necessary to prepare the beverage. In that case, there is a possibility that the workflow cannot be completed in the way it is shown in Figure 2. Figure 3 is a revision of the workflow taking that exceptional flow into account. In this case, the decision has two potential outcomes: the ingredients are available or they are not. Both control flows emanating from the decision must be labeled.
Figure 3. Workflow with a branch. In this case, the branch, when taken, terminates
the workflow.
Suppose that instead of simply terminating the workflow, the barista restocks the ingredients or finds a substitute ingredient. In that situation, the workflow would not terminate and the branch would not be an exception, but rather an alternate flow that eventually rejoins the main flow. To indicate a rejoining of one flow with another, UML uses a merge icon, which is – unfortunately – visually the same as the branch. However, a branch (decision) has one incoming control flow and at least two outgoing control flows, whereas a merge has at least two incoming control flows and no more than one outgoing control flow. Figure 4 illustrates this concept.
Figure 4. Workflow containing an alternate flow that eventually rejoins the main
flow using a merge.
Unordered and Concurrent Activities
Suppose that during analysis you have discovered that some baristas call the customer name first and then place the beverage on the counter, while others do it in the reverse order. Further analysis revealed that the order is actually of no consequence. So, how does one show unordered activities in a workflow, i.e. a set of activities where the order does not matter; it only matters that the activities are done? This is shown in UML with a fork/join region – a set of vertical (or horizontal) bars containing activity flows that can be done in any order or even at the same time as long as all of the flows are completed before the next activity after the join starts. Figure 5 illustrates the use of the fork and join mechanisms.
Figure 5. Workflow containing a fork/join region indicating that the activities
within the region can be done in any order or even at the same time
(concurrently).
Conclusion
The UML Activity Diagram is a worthwhile addition to the arsenal of business analysis and modeling tools and should be mastered by every BA. This article explored some of the most important aspects of the diagram that apply to workflow analysis and documentation. Of course, the UML Activity Diagram contains many more symbols that go beyond the scope of this article and often the need of the BA.
Although UML is rich with syntax and semantics and offers many symbols to indicate complex concepts, it is important to remember that often a simple note is easier for others to understand. After all, the point of diagrams is to facilitate communication and allow others to understand what the BA has discovered. When reviewing the diagrams with stakeholders, be sure to walk them through the diagram and translate the diagram into English. Don’t simply put up the diagram on a PowerPoint slide and ask: “Any questions?” or “Let us know if we missed something.”
Finally, keep the diagrams simple and use text narratives to support the diagram – don’t rely solely on the visual symbology.
Copyright © 2007: Martin J. Schedlbauer, Ph.D.
Martin Schedlbauer is an accomplished software architect, business analyst and trainer. He has been developing and analyzing software systems since 1989. In addition, he frequently presents seminars and workshops on software architecture, business analysis, and requirements management to corporate clients throughout the world. Prior to returning to consulting, Dr. Schedlbauer served as CTO for Global Services at BEA Systems, Inc. and as CTO and CEO for Technology Resource Group, Inc., a consulting and training firm. He holds B.S., M.Sc. and Ph.D. degrees in Computer Science from the University of Massachusetts and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it. .
References
Business Analysis Body of Knowledge, Version 1.6, International Institute of Business Analysis (IIBA), 2006.
Booch, G., Rumbaugh, J., & Jacobson, I. The Unified Modeling Language User Guide 2nd Edition, Upper Saddle River, NJ: Addison-Wesley, 2005.
Comments