In the previous chapter we saw the difference between a business use case and an application use case. In this chapter we discuss a process for deriving impacted AUCs from a BUC. 5.1    Overview

The BUC includes business process steps making up its workflow. Each of these steps has the option to be automated. The business analyst (BA), systems analyst (often the same person), systems architect and business process owners (BPO) determine between them which steps are to be automated. The systems analyst and architect roles are mainly to determine the time and cost to automate the business process. The BA and BPO will determine the return on investment (ROI) in order to determine if there value in automating a business process.

Once automated steps have been identified (and prioritized) the systems analyst copies each step into a candidate use case (CUC) template. (yes, we are copying, but only temporarily.) The systems analyst works with the CUCs in order to derive functionality that goes into an AUC. Once the AUC has been scoped the CUCs whose functionality was captured by the AUC can be discarded. The CUCs retain traceability to the BUC steps. Prior to being discarded, that traceability is transferred to the AUC.

Impacted objects are added to the AUC. These will initially come from the business objects that were identified during the creation of the BUC. The AUC will supply some attributes and states for these objects.

5.2    The Rationale behind the Process

We create CUCs for the automated BUC steps so that they may be manipulated and traceability to the BUC is not lost. Automation of 1 BUC step may be identical or be a partial implementation of another BUC step. The corresponding CUCs will be consolidated into a single AUC and that AUC retains the traceability to both steps. Traceability for the CUCs is graphical. AUC traceability is textual.

5.3    Process Details

The following BUC steps are those that were identified as being automated from the restaurant example.

·         The head waiter hands the customer a menu.

·         The table waiter is informed they have a new customer.

·         The table waiter asks the customer for their order.

·         The customer gives their meal order to the table waiter.

·         The table waiter takes the customer order to the kitchen.

·         The meal is ready and the table waiter is informed.

·         The customer asks the waiter for the bill.

·         The table waiter gives the customer the bill.

·         The customer makes a payment to the cashier.

·         The cashier gives the customer a receipt.

·         The customer is not satisfied with their meal.

·         The waiter fetches the head waiter to the table.

The following business rules apply to these steps:

·         The table waiter will request the customer order within 5 minutes of being informed that they have a new customer.

·         The meal will be delivered to the customer within 10 minutes of the customer placing their order.

·         The table waiter will give the customer their bill within 4 minutes of it being requested.

·         The cashier will process the customer’s payment within 2 minutes of the customer initiating payment.

·         Menu items are categorized by ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’.

Notice that we no longer need the numbering, nor do we care if the step was in the basic workflow or an alternate flow.

The steps have also been modified slightly in order to remove any manual parts.

The steps are prioritized and assigned to an iteration. The following diagram shows just those steps that are slated for iteration 1. I use a dashed line to indicate that these steps are going to be automated.

Figure 1:    BUC Steps For Automation

Note that the ‘Waiting For Food’ and ‘Customer Eating Food’ steps are not automated. For each automated step we create an equivalent candidate application use case (CUC) and place these on activity diagram. (I realize that it is getting crowded, but if we were using a modeling tool we might be able to create a new diagram and re-use the activities and use cases on that diagram.) We connect the use cases to their equivalent action step.

        Figure 2:    CUCs Tracing From BUC Steps

Now that we have our traceability in place we may work on the CUCs to turn them into AUCs. If a CUC is deleted we must revisit this diagram to fix the traceability. Similarly, if a CUC is created a traceability link should be added to this diagram. The following diagram shows the CUCs and their primary actor.

          Figure 3:    CUC Diagram With Primary Actors

Now we create a high level description of the application’s functionality within each CUC.

Handing Menu To Customer – The system is displaying the initial menu screen with instructions for the customer. The customer requests the system display the menu. The system displays the menu index to the customer, which contains an overview of each menu category. The customer may select a category and have the system display the items in that category. If there are too many items for a single page the system will indicate this and allow the customer to page through the items in that category. The customer may select any number of items from a category by inputting the number of each item into the system. The system will display the items selected by the customer to the customer, along with a running total of the cost of the customer’s selection.

Asking Customer For Their Order – Anytime that a customer is making a selection of items from the menu system, the customer will be able to select the order option. The customer’s order is displayed to the customer, along an itemized pricing of each item and a total cost. The customer is prompted to verify that everything is correct and that they wish to pay the total cost of the order. The customer may go back to the menu categories and make changes to the selected items, or the customer may confirm the order. Once the order is confirmed a message is displayed to the kitchen containing the ordered items and the table that they are for.

Waiter Is Delivering Food – Once an order has been placed in the pickup area the kitchen will inform the system of where the customer can obtain their food. The system will inform the customer where their food is located. Once the complete meal has been retrieved from the pickup area the system is informed and the system displays the initial menu screen to the customer.

Getting Head Waiter – Anytime that the customer has access to the system they may request assistance from a member of the restaurant’s staff. Upon receiving this request, the system will display a message to the system administrator indicating which table is requesting assistance.

Given these initial use case descriptions it is possible to update the CUC diagram with secondary actors.

 Figure 4:    CUC Diagram With Secondary Actors

Notice that as a result of writing down the high-level description of the ‘Waiter Is Delivering Food’ use case we discovered that the primary actor wasn’t the customer at all, but the kitchen.

Next we consolidate these CUC cases into AUCs and rename them appropriately. ‘Handing Menu To Customer’ and ‘Asking Customer For Their Order’ are closely related, so let’s combine these into a single use case. (We could move the common functionality concerning selecting items from the menu into an ‘included’ use case fragment. I discourage using ‘includes’ and ‘extends’ relationships, unless they either remove duplication from the use case model, or they add clarity to the model. The objective is to keep the model as simple as necessary, by keeping the number of elements in the model to a minimum.)

The following diagram shows the CUCs converted to appropriate AUC names and the consolidated CUCs.

 Figure 5:    Initial AUC Diagram

We need to revisit the BUC activity diagram and clean up the traceability.

                   Figure 6:    Updated Traceability Diagram

The ‘Handing Menu To Customer’ and ‘Ordering from Menu’ steps both trace to the ‘Order From Menu’ AUC.

Once we have detailed the steps, the ‘Order From Menu’ AUC might look like the following: