Chapter 7    Example Use Cases

Let’s see the whole procedure in action. I am going to describe an example vision for a restaurant.[1] The vision statement goes something along the lines of: ‘As a restaurant owner I wish to reduce the wait staff to a minimum. They are expensive, they eat the food, they break the crockery and they steal things when my back is turned. To this end I wish to replace the waiters with an automated menu system, which allows customers to:

·         Offer the customer a greeting.

·         Display the menu for today (it will change regularly, but remains constant every day).

·         Select items from the menu for the kitchen to prepare.

·         Inform the kitchen of each table’s order.

·         Inform the customer when their meal is ready and where to pick it up.

·         Allow the customer to add to their order at any time.

·         Allow the customer to pay for their order (and leave a tip if they so wish).

·         Give the customer a receipt and offer them a farewell message.’

1.1    Business Use Case

A business use case for the Automated Menu System project may look like this:

Name

Serve Customer Business Use Case

Description

The referenced document contains a great storyboard sketch of the BUC. It describes a person entering a restaurant, being assigned a table, having their coat checked, being shown to their table, ordering lunch, being delivered food, paying the bill and retrieving their coat.

Objectives of the business use case.

To provide a satisfactory meal for a customer in return for payment.

Performance Goals

At peak time (lunch hour) to have customers in and out of the restaurant within 1 minute for every $ they spend. For example, a customer whose bill comes to $30 will be in the restaurant for ½ an hour.

Primary Actor

Customer – the person being served by the restaurant.

Secondary Actors

None.

Business Workers

Normally I would define the actors and workers in a project repository and not duplicate their definitions in the use case. For this example I have pulled their definition into the use case text.

Head Waiter – Arranges for the customer to be assigned to a table.

Cloakroom Attendant – Manages the customer’s non-essential belongings while they are seated.

Table Waiter – Takes the customer's order and delivers their food.

Cashier – Takes the customer's payment.

Cook – Prepares the food.

Preconditions

The restaurant is open to customers.

Successful Postcondition

The restaurant has received the customer's payment.

Alternative Postconditions

The customer leaves without paying.

Workflow

The following workflows describe the different paths through the use case. The Basic Workflow describes the expected or normal flow of events.

Basic Workflow

1.      The use case starts when, the customer enters the restaurant.

2.      The headwaiter greets the customer.

3.      The customer requests a table.

4.      The head waiter arranges for seating for the customer.

5.      Seating is arranged and the head waiter asks if the customer would like to check their coat.

6.      The customer hands their belongings to the cloakroom attendant.

7.      The cloakroom attendant takes the customers belongings and hands the customer a token.

8.      The head waiter shows the customer to their table.

9.      The head waiter hands the customer a menu.

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

11.  The table waiter asks the customer for their order. (They are probably going to list recommendations and specials that are not on the menu first, but let's keep it simple.)

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

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

14.   The cook takes the order and prepares the meal.

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

16.  The table waiter delivers the meal to the customer's table.

17.  The customer finishes with their meal and asks the waiter for the bill. (Again, keeping it simple by leaving out the waiter asking if the customer would like anything else.)

18.  The table waiter gives the customer the bill.

19.  The customer makes a payment to the cashier.

20.  The cashier gives the customer a receipt.

21.  The customer gives the cloakroom attendant back their token.

22.  The cloakroom attendant returns the customer belongings.

23.  The table waiter cleans the table in preparation for the next customer.

24.  The table is prepared and the table waiter informs the head waiter that the table is free. (This and the previous step are performed in parallel to steps 19, 20, 21 and 22, demonstrating why the text method of detailing use cases is awkward.)

25.  The use case ends.

Alternative Workflows

A.1   The customer has nothing to checkin.

26.  At step 5 the customer has nothing to checkin to the cloakroom and the use case continues from step 8.

27.  At step 21 the customer has nothing to retrieve from the cloakroom and the use case continues from step 23.

28.  At step 31 the customer has nothing to retrieve from the cloakroom and the use case continues from step 34.

A.2   The customer finds a fly in their soup

29.  At step 17 the customer is not satisfied with their meal.

30.  The waiter fetches the head waiter to the table.

31.  The head waiter agrees to not give the customer a bill.

32.  The customer gives the cloakroom attendant back their token.

33.  The cloakroom attendant returns the customer belongings.

34.  The table is cleaned in preparation for the next customer.

35.  The table is prepared and the table waiter informs the head waiter that the table is free.

36.  The use case ends.

Some points of note:

·         Steps 21, 22 and 23 are duplicated in the extension flow. In order to avoid duplication we can pull out these steps into a use case fragment and ‘include’ the fragment in this use case.

·         Steps 5, 17, 21 and 31 all contain branches to alternate workflows, yet no mention is made of this fact in the basic workflow. Keep the basic path ‘happy’ by only describing the expected steps of the use case. Alternate workflows will capture to unexpected steps.

Business Rules

Dress Code

37.  To use the restaurant customers must be attired according to the restaurant’s dress code. [Impacts step 2]

Seating Rules

38.  Customers will be seated on a first come first served basis, unless every restaurant table is occupied, in which case the largest party that may be seated at a free table will be seated first. [Impacts step 4]

The BUC Activity Diagram

The complete diagram encompasses more than a full page, so I will only display the more interesting activities.

I believe that the diagrams in Figure 19: and Figure 22: capture all of the above rules and a few additional features too. These are explained in the following notes.

                                                                        Figure 1:    Serve Customer BUC Activity Diagram

Note 1 – This is the initial state ‘Restaurant Is Open’ (to customers) and the triggering event exiting this state. The reason why the arrow is bent is because if had drawn it straight some of the text becomes unreadable.

Note 2 – Have you noticed that there is one common activity diagram element that I missed from the list in Section 1.7.2? Swimlanes! I despise swimlanes for several reasons including;

·         They waste whitespace on my diagram,

·         They restrict the flexibility of the layout of my diagram,

·         And, I cannot find a modeling tool that has successfully implemented swimlanes in such a manner, that when I edit my activity diagram the swimlanes do not cause the layout of the diagram to become totally destroyed.

[Rant over.]

There are many ways that you may indicate the workers of each action in your activity diagram, without the use of swimlanes. These include adding stereotypes to the actions. (I.e. adding a waiter stereotype would indicate that this is a ‘waiter’ type of action.) In Figure 19: I have used color to indicate which worker performs what action.

Note 3 – Notice that every action includes an output flow to an object. You might argue that a ‘Greeting’ is not an artifact, but when we start modeling the application we may discover that this was a useful object to capture.

Note 4 – The seating chart is changed by the head waiter and as a result the table object has its status changed from ‘Open’ to ‘Reserved’.

Note 5 – This is an example of an alternate workflow. Notice that the flow begins with a decision and ends with a merge. The decision asks the question, does the customer wish to make use of the cloakroom?

Note 6 – An example of an activity. In this instance the activity is being used to indicate that there are a lot of missing actions here, and not that they are captured by a use case fragment.

Note 7 – This is an example of an extended flow. We know that it is an extension to the use case, because it does not return to the basic flow.

Note 8 – This is an example of a fork. Notice how more eloquent this notation is than trying to describe this activity with text.

Note 9 – Retrieve Coat and Clean Table are use case fragments that are ‘included’ in the flow of this use case.

Note 10 – A non-successful postcondition.

Note 11 – This is the successful postcondition.

Notice how the basic flow runs vertically down the page. Alternate and extended flows are drawn off to the left and right of the basic flow. (Another reason not to use swimlanes.)

The BUC Object Diagram

The following objects, and their definitions, have been identified as being impacted by the Serve Customer BUC.

·         Bill – A request for the customer to pay the cashier the amount indicated.

·         Cloakroom Request – An inquiry as to whether the customer wishes to make use of the restaurant’s cloakroom to stow their belongings.

·         Customer Belongings – That are exchanged for a cloakroom token.

·         Kitchen – Where food is prepared.

·         Meal – Food served to a single customer at a single seating.

·         Menu – What the customer uses to order food.

·         Order – A combination of items from the menu for a single table.

·         Payment – Money handed to the cashier.

·         Restaurant – Where food is served to customers.

·         Seating Chart – Displays which tables are reserved and which are free, as well as their size and location in the restaurant.

·         Table – Reserved for customers in order that they may be served food.

·         Token – A unique identifier for customer items in the cloakroom.

Putting this in a diagrammatic form we see these objects described in Figure 20:

                                                                          Figure 2:    Serve Customer BUC Class Diagram

This is the complete BUC. There is more activity in the business modeling process, including determining which steps in the BUC are to be automated. This process is not necessarily the responsibility of the BA. The appointed systems analysts, lead architects and the business SMEs need to also be involved. Therefore, I consider those actions as falling on the interface between the Business Modeling and the Requirements disciplines.

In the next chapter I will describe a process for moving from the above BUC to AUCs. For now I will just present an example of a potential AUC for the Automate Restaurant project.

1.2    Example Application Use Case

For iteration 1 of the Elaboration phase (that’s the 2nd of 4 phases in RUP terminology, Inception, Elaboration, Construction and Transition), it has been decided that the ordering food business activities concerning ordering from the menu will be completely automated by the Menu Ordering System[2]. Here is the goal of the AUC, followed by the AUC itself:

Goals

To allow a customer to order any item from the menu and when it arrives at a pickup area, inform the customer where they may retrieve their meal from.

Name

Order Food Application Use Case

Description

The following description forms an overview of the detail in the steps of the basic flow of the AUC.

The customer arrives at the table. The system greets the customer and prompts the customer to display the menu. When prompted the system displays the first page of the menu. The customer may browse every page of the menu using the interface controls. (The menu items and menu  size could change daily.) The customer will select the items for their meal. Once they have finished selecting the customer orders their meal. The order will be processed by the kitchen and once prepared the customer is informed how to retrieve their meal from the service area. Once the meal is retrieved the system will stop prompting the customer to retrieve it.

Usage

Usage describes the expected average use of the system and the peak use. It is sometimes useful to know when the peak usage occurs so that the system does not schedule any unnecessary maintenance activity or batch jobs at that time.

Assume a maximum usage of 15 minutes out of every 30 minutes per table with 105 tables in the restaurant, from 12noon-1pm. Normal usage is assumed to be 10 minutes every hour per table.

Primary Actor

The actors are defined in a repository somewhere. We do not repeat their definitions in the use case.

Customer.

Supporting Actors

The supporting (or secondary actors) are all the other roles or systems that are interfacing with the menu ordering system during this AUC.

Kitchen Staff, Stock Taking System, Administrator, Meal Sensor.

Preconditions

The precursor use case to this AUC, is itself, or any other use case that displays the welcome screen.

The welcome screen is displayed.

Successful Postcondition

How does the application know that the customer has picked up their meal? I am assuming that there is some sort of sensor that can detect when there is a meal in the serving area. This sensor is outside of our application, but it will inform our system when it changes state, (either ‘Meal’ or ‘No Meal’).

Customer has picked up their meal from the serving area.

Alternate Postcondition

This postcondition could happen for any number of reasons (the customer leaves the restaurant, the customer has a heart-attack, the customer is locked in the washroom, etc) none of which are relevant to this AUC.

The customer does not pick up their meal within 10 minutes of it being delivered to the pickup area.

Basic Flow

Note that the steps in the use case are written as dryly as possible, using as few different words as possible, while being grammatically correct and containing every detail that is required to implement the use case. As with everything else, if you can use 2 words in the steps of the use case that have the same meaning, pick one and use it consistently. (We want the use case story to be as boring as possible.)

1.      The use case starts when, the customer initiates communication with the system.

2.      The system greets the customer and displays the instructions screen.

3.      The customer selects the menu screen.

4.      The system displays the menu index and requests that the customer select a category (menu items will be categorized by ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’, etc).

5.      The customer selects a category of menu items.

6.      The system displays the first page of the selected items.

7.      The customer changes page and the system displays the selected page (the system keeps rotating the pages as they are changed within the selected category).

8.      The customer selects items to order and deselects ordered items from the displayed page.

Although relatively simple to model with an activity diagram, the following 2 steps were extremely difficult to ‘model’ with text.

9.      The customer changes page and the use case continues from step 7, until the customer selects a different category or places an order.

10.  The customer selects a different category and the use case continues from step 5, until the customer places an order.

11.  The customer orders their selection,

12.  The system displays the total price and requests the customer for confirmation of the order.

13.  The customer confirms the order.

14.  The system displays the order items to the kitchen staff.

15.  The system displays the ordering menu to the customer, where they may edit, or cancel their order.

16.  The kitchen staff inform the system of the location of the customer food.

17.  The system informs the customer where their food is located and the system informs the Stock Taking System of the contents of the meal.

18.  The food is picked up from the serving area and the system displays the welcome screen to the customer.

1.2.1.1    Alternate Flows

A.3   The Customer Changes their Mind

19.  At step 15, the customer edits their order and the use case continues from step 5.

A.4   The food is not picked up

20.  At step 17, after 10 minutes the food is not picked up and the system sends a request to the administrator to reset the table menu.

Performance Requirements

For each step in the AUC that is performed by the system, make sure that it has an associated timing.[3] Any steps that do not have an associated time-out requirement cannot be fully tested.

21.  By default, all responses to the customer will occur within 2 seconds.

22.  All responses to selected items will occur within .5 seconds.

23.  When the customer places an order the kitchen staff will be informed within 30 seconds.

24.  When the location of the food is entered into the system, the customer is informed within 30 seconds.

25.  Once the food has been picked up, the system displays the welcome screen within 10 seconds.

26.  All messages to the administrator will be displayed within 5 seconds of the event occurring.

27.  The Stock Taking System must be informed of the customer ordered items before 6am the following day.

Supplementary Requirements

We captured some supplementary requirements during the detailing of the use case steps. I am going to move (not copy) them here and reference the step that they were moved from.

Supplementary (including performance) requirements will be moved their own repository if they are duplicated between use cases. Only supplementary requirements that are specific to a single use case remain with the use case. Ideally we want them to remain with the use case, but unfortunately, the duplication rule takes precedence.

28.   Menu items will be categorized by ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’, etc

Obviously this requirement needs clarification from the business; ‘etc’ is not a word that belongs in a requirements document.

29.  The system keeps rotating the pages as they are changed within the selected category.

Or to put it another way, when ‘Next’ is selected while the last page is displayed, the first page will be displayed, and when ‘Previous’ is selected while the first page is displayed, the last page will be displayed. For all other pages, selecting ‘Previous’ will display the previous page and selecting ‘Next’ will display the next page.

[Do not assume that everyone reading this requirement will have the same understanding of the word ‘rotating’. There is bound to be someone out there that interprets ‘rotate’ as meaning ‘turn the page over’. If in doubt, spell it out.[4]]

Interface Requirements

System to actor interface requirements are captured with use case storyboards. Since these are specific to the system, they belong with the application.

System to system (Stock Taking System, for example) interface requirements impact both systems and form a contract between the 2 applications. In this case neither application is allowed to change that interface without getting permission from the other system. (I have never worked in an environment where the system interfaces have been properly controlled.)

Diagrams

Let’s go ahead and capture the above use case with an AUC activity diagram, but first here is the use case diagram.

                                                                               Figure 3:    Order Food Use Case Diagram

                                                                             Figure 4:    Serve Customer Activity Diagram

The first thing I noticed when trying to model the above AUC, was that it is way too complicated. There are too many steps to fit on a single page.[5]

Note that an AUC activity diagram does not require swimlanes; because there is only 1 worker – the system.

Notice that the event flow exiting the ‘Waiting For Customer Input’ action, carries both the unrelated events ‘Customer Changes Order’ and ‘Welcome Screen displayed’.

1.3    Summary

The activity diagram is a great tool for modeling use cases, but even in UML 2 there are too many ambiguities to use it straight from the box. This document addressed where a UML notation’s meaning was unclear by restricting the use of the notation when there are more than 1 ways to describe an activity and by clearly defining the meaning of each notation when used for use case modeling.