From Business Process to Use Case

---

Development teams use business process model to visually document the business work flows, and prepare use case model to model what the users want to achieve by using the system. In this tutorial, we will explain in detail how to make use of the model transitor function to prepare a use case model from business process model.

What are BPMN and BPD?

BPMN provides business analysts with a set of graphical notations for modeling business processes. It was initially developed by the Business Process Management Initiative (BPMI) and is now being maintained by the Object Management Group (OMG). One of the motivations of developing BPMN is to provide a common graphical language for people in different roles, from different countries, and/or with different spoken languages to understand the same business process without barrier.

BPD, short for Business Process Diagram, is where business process is modeled, using BPMN. It is a flow-chart like diagram, which depicts the process flow, participants involved and message exchanges between participants. Business analysts draw BPD(s) to model how different participants collaborate together to accomplish a business objective. Having validated the completed business model against the end users, system analyst can then start planning the system.

The following is a simple BPD of a registration process for an organization. It covers most of the typical modeling notations you would see. Let's take a look.

Notation	Description
	Pool - Represents a participant within a process. In BPMN, both pools and lanes are used to represent participants. A lane is contained by a pool for modeling a sub-partition of the parent pool.
	Start event - The beginning of a process. Triggers can be defined to tell readers in what situation the process will be triggered. For example, when an Email is received/when it is Monday morning/when an error has occurred.
	Task - An atomic activity that designated participants (modeled by pool/lane) might perform. Tasks and other flow objects are connected together to form a complete business workflow.
	End event - The end of a process. A result can be defined to tell readers what will happen when the process ends. For example, to issue a signal/to produce an error, etc.

In this tutorial we are not going to focus heavily on BPD nor business process modeling. If you want to learn more about BPMN, BPD or business process modeling, please read the tutorial Introduction to BPMN Part I to IV. The tutorial was written for BP Visual ARCHITECT, but the techniques covered work for Agilian, too.

What is Use Case Diagram?

Use case modeling refers to the technique of capturing high level user requirements using UML use case diagram. Use case model is designed for software or system designer, not for any business people.

There are four main elements in a use case diagram.

Notation	Description
	System - A rectangle that represents the boundary of the system.
	Use case - Use cases are shown in ovals. Each use case represents a user goal, which is an objective the user of the system wants to achieve. Note that use cases can only be used to show what the user wants to do instead of what the developer needs to develop, although they may be the same in some cases. Let me give an example here. For ATM, users of ATM may select to print advice that shows the detail of a transaction. When you draw a use case diagram for ATM, the function 'print advice' should not be a use case. This is because users won't login to ATM just to print advice. Printing advice is only a side product of user's goals such as making a deposit, withdrawal, transfer, etc. If you want to document or model the functions involved in a use case, you may use the flow of events tool, or to elaborate a use case with sequence diagram/activity diagram. Just keep in mind that use case modeling aims at modeling what the user wants to achieve.
	Actor - User of the system. The word 'user' here is not limited to humans. It can be a system that interacts with our system to fulfill certain business objective.
	Communication link/Association - Connects between actor and use case to indicate the access of system by actor. Each communication link implies a sequence of transactions between actor and system.

Transit from BPD and Use Case Daigram

Although BPD and use case diagram do not rely on each other, they are somehow related. Usually, we develop software to automate or optimize certain work flows of business process(es). BPD is what we can use to model the work flows. With BPD, you can understand how participants work together, so you know what functions they need the system to provide in order to help them. The system functions users want can be modeled with a use case diagram. As a result, we can say that BPD helps you construct a use case diagram.

Agilian is a visual modeling tool that supports business and use case modeling with BPD and use case diagram. It also supports creating transition between views of system and maintaining traceability. System analysts may produce a use case diagram by transiting from a BPD. This not only gives you a diagram but also maintains traceability between (objects in) BPD and use case diagram. We need the traceability because of the following reasons:

1. We can make sure the system can fit into real world usage by studying the part of the process flow a use case involves.
2. To answer questions like "Why do we need this (system) function?" by tracing the part of process from which a use case transited.
3. To answer questions like "Has a specific operation been implemented already?" by tracing from BPD to use case diagram.

BPD vs. Use Case Diagram

When you transit a BPD to a use case diagram, you may produce actor from lane/pool, and produce use case from task/sub-process. The following table shows you the characteristics of pool, lane, actor, task, sub-process and use case, in terms of model transition.

From	To	Description
		Pool/Lane to Actor In BPD, a pool represents a participant of business process while a lane is a sub-partition of pool. Anyone who has an activity to perform, relevant to the process, is said to be a participant. In use case diagram, an actor represents a user of system. Keep in mind that any person or role that is not a user of system should not be considered as actor.
		Task/Sub-Process to Use Case In BPD, a task/sub-process (activity) refers to any action participant might perform in order to complete a business process. In use case diagram, a use case presents a goal user wants to achieve by using the system. Keep in mind that an activity need not to be relevant to any system function, and one use case may satisfy multiple activities.

Some people may think that a use case diagram is identical to a BPD but different in notations. This is a wrong notion. Do remember the fact that BPMN is designed for business people while use case diagram is for system analysts or system developers. They serve different purposes and reads a business in two distinct perspectives. That's why in the previous section I have summarized the relationship between BPD and use case diagram by saying "BPD helps you construct a use case diagram". BPD can only gives you hints when constructing a use case diagram. There has no rule stating that every task existing in a BPD is equivalent to a use case. If BPD is equivalent to use case diagram, why do we need a use case diagram? Therefore, do not overkill the transition. In the case study section I will give you more idea about what you should pay attention to when transiting a BPD to a use case diagram. You will know how different they are.

Case Study: The True Aqua Distilled Water Company

The True Aqua Distilled Water Company is a young distilled water supplier in the city. They sell distilled water for business and home use. The following is a textual description of their water delivery process.

To order distilled water, customer either calls the ordering hotline or send us Email. Currently, 90% of the orders come from phone calls, while 10% are placed by Email. The customer service assistant who receives the order will check whether the customer is an existing customer or a new one. If the customer has never ordered before, the customer service assistant will create a customer account for him or her before proceeding to water delivery. The delivery of distilled water is carried out once a week on every Wednesday. So on every Wednesday morning, the customer service assistant will forward orders to the Logistics Department for delivery. Once the manager in the Logistics Department has received the orders, he will arrange the delivery by assigning workers for different orders, printing and posting the schedule. The workers receive the calls and deliver water to the customer accordingly.

A business process model has been created based on the description. Now, you are requested to develop a computer system to optimize the whole process. The first thing you need to do is to develop a use case model. With the help of the BPD, try to develop a use case diagram.

1. Download the project file The True Aqua Distilled Water Company.vpp attached with this tutorial.
2. Open the project file in Agilian. (Select File > Open Project... in Agilian to open project file)
3. Open the BPD Distilled Water Ordering Process. Study the process flow carefully.
   
4. The process starts when a customer places an order. Here we can think of a use case - Place Order. The use case will help automate the process by providing an interface for customer to place order without the assistance of customer service assistant, help verify customer identity and create account if customer does not exist. Right click on Place Order and select Related Elements > Create Use Case... from the popup menu.
   
5. This prompts the Transit Model Element window, where you can select the model to place the use case and actor, and rename them. In this case we are pleased with the names of the use case and the actor. Let's keep them unchanged. Click OK.
   
6. This prompts the Visualize Model Element window, where you can select how to show the use case and actor elements, or not to show them. Let's show the use cases and actors in a new use case diagram. Keep the option Create the diagram selected. Enter Distilled Water Order to be the name of the use case diagram.
   
7. Click Create. This forms a new use case diagram.
   
8. Go back to the BPD.
9. Let's consider the task Forward Order. In the business process, the customer service assistant needs to forward the collected orders to the Logistics Department every Wednesday. In the new system, this can either be a part of the Place Order use case, which is likely to be a scheduled work that will be carried out automatically every Wednesday, or be a separate use case triggered by customer service assistant manually. In the real world situation, you should clarify this kind of doubt with the end user because an incorrect use case model will lead to the development of functions that do not match user's expectation. In this example, let's assume that the user wants the Forward Order task be a task done by the customer service assistant. Let's create a use case from it. Right click on Forward Order and select Related Elements > Create Use Case... from the popup menu.
   
10. Again, we are pleased with the name of the use case and actor. Keep everything in the Transit Model Element window unchanged. Click OK.
11. This prompts the Visualize Model Element window. This time, we do not want to show the use case in a new use case diagram. Instead, we want to show them in an existing one. Select Show in existing diagram. After that, select the use case diagram Distilled Water Ordering and click Show at bottom right.
    
12. The use case diagram is updated with a new use case and actor. Let's take a look.
    
13. Go back to the BPD. Let's move on to the sub-process Arrange Delivery. The manager of the Logistics Department can use the system to perform scheduling and notify workers to deliver water. Therefore, this is also a use case of the system. Right click on the sub-process Arrange Delivery and select Related Elements > Create Use Case... from the popup menu.
14. Check the actor Manager in the Transit Model Element window. If we keep the name of actor as Manager, this is ambiguous in the use case model because there may be many departments with many different managers in the company. Therefore, rename the actor to Logistics Department Manager. Click OK.
    
15. In the Visualize Model Element window, keep showing the result in the same use case diagram Distilled Water Order. Click Show. The use case diagram is updated.
    
16. Go back to the BPD. The final task Deliver Water is a job that can only be done by human and has nothing to do with the system's interaction. Therefore, we do not need to create a use case for it.
17. Suppose the regional manager wants the system to support a new function that can generate a report to show the statistics on orders. This function can help him review and refine the marketing strategy. Although this function had not been modeled in the business process model, we can draw it directly in the use case diagram. Open the use case diagram. Draw an actor Regional Manager. Create a use case Generate Statistic Report from it with association in between.
    
18. Let's draw a system boundary around the use cases. Select System in the Diagram Toolbar. Press at the top left of use cases and drag towards bottom right to form a border for the system.
    
19. Release the mouse button. Enter the name of the system: Distilled Water Ordering.
    
20. The transition relationship enables you to trace the business process model from use case model (and vice versa). Let's try. Place the mouse pointer over the Place Order use case.
    
21. Click on the Model Transitor resource at bottom right corner of shape. Select Transit From > Distilled Water Ordering Process.Place Order from the popup menu.
    
    This opens the BPD with the task Place Order selected.
    

Resources

1. The True Aqua Distilled Water Company.vpp
2. The True Aqua Distilled Water Company (completed).vpp

Related Links

1. BPMN Specifications