Business Analysis

Workflow Modeling with UML Diagrams

The construction of workflow models (a.k.a. business process models) is an essential technique that the Business Analyst (BA) needs to master. The Business Analysis Body of Knowledge^® (BABOK^®) defines a workflow model as, “A visual representation of the flow of work in a business area. Workflow models are used to document how work processes are carried out, and to find opportunities for process improvement” (BABOK^®, v1.6, Section 5.13.7.1). The BABOK^® does not prescribe a specific notation for workflow models, although the use of a standard notation is suggested. For the past decade, the Unified Modeling Language (UML) has emerged as a de facto industry standard for the visual representation of analysis and design artifacts; therefore, it is essential for the practicing BA to understand how workflow models can be represented in UML (Booch, Rumbaugh, and Jacobson, 2005).

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:

1. This process starts when the customer places an order
2. The cashier enters the beverage order into the point-of-sale system (POS)
3. The cashier asks for the customer's name and notes it on the order
4. The customer pays for the order
5. The cashier communicates the order details to the barista (person making the beverage)
6. The barista prepares the beverage order
7. Upon completion of the order, the barista places the beverage on the pick-up counter and calls the customer's name
8. 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 while the end is indicated with a terminal activity. The activities themselves, therefore, are not numbered.

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.

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.

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.

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.

Conclusion

The UML Activity Diagram is a worthwhile addition to the arsenal of business analysis and modeling tools and should be mastered by every business analyst. 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.

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.

About the Author:

Dr. Martin Schedlbauer, consultant and instructor for the Corporate Education Group, is an accomplished business analysis subject matter expert, and has been leading and authoring seminars and workshops in business analysis, software engineering, and project management for over twenty years. Beyond that, he is involved in architecting large-scale distributed software systems for many of his clients.