What You'll Learn in This Hour:
The care and feeding of use cases
Specifying descriptions, preconditions, and postconditions
Specifying steps
Diagramming the use cases
The use cases from the package diagram in Hour 18, “Gathering System Requirements,” give a good picture of what the system will have to do. The team will have to analyze and understand each one. They've moved gradually from understanding the domain to understanding the system. The use cases have provided the bridge.
If you're getting the idea that the system development project is use case driven, you have a good understanding of the whole process.
Notice that at no point in the JAD session did the development team discuss how the system would accomplish all the activities specified in the panoply of use cases. The idea was just to enumerate all the possible use cases. As the use cases are fleshed out in this hour, notice how the components of the WIN system start to materialize. At this point in the development effort, the system begins to take center stage.
Now, put yourself in the shoes of the development team, and we'll deal with part of this collection of use cases.
To analyze the use cases, you have to run another JAD session. The discussion in this JAD session is intended to derive an analysis for each use case.
A word of caution: The use case JAD session is usually the most difficult one, as it calls for the participants—potential users of the finished system—to become analysts. In their own niche, each one is a domain expert, and you have to tap into their expertise. Typically, they're not used to either verbalizing or analyzing what they know. They probably haven't been part of a system design effort before, and they may be uncomfortable trying to specify what a system should do to help them carry out their work.
In order to alleviate the strain, it's best to organize the JAD session so that the team deals with one group at a time—for instance, just the servers. That way, the others won't sit idly by as the servers analyze their use cases. The overall domain experts, the restaurateurs, can show up to lend a hand with all the groups. A cross-section of the users would be appropriate when dealing with the Customer package.
The use cases are numerous. Just to keep this hour manageable, we'll focus on the first eight use cases for the Server package. After you see how these analyses are done, you'll be able to deal with the remaining Server use cases, as well as the use cases for the other packages, on your own. (See the exercises in the Workshop at the end of this hour.)
Remember (from Hour 7, “Working with Use Case Diagrams”): Each use case is a collection of scenarios, and each scenario is a sequence of steps. For each scenario in each use case, you'll want to show
A brief description of the scenario
Assumptions for the scenario
The actor who initiates the use case
Preconditions for the use case
System-related steps in the scenario
Postconditions when the scenario is complete
The actor who benefits from the use case
(In your analysis, you can also include any exception conditions or alternative flows. I've kept the scenarios simple for this example, however.)
No specific way of laying out a use case analysis is correct. The items listed typically provide a complete picture of a use case.
In your design document (the document you give your client and the programmers), each of these use case analyses will have a separate page. You'll probably want to include a diagram of the use case, complete with actors, on this page.
The system-related steps in the scenario are extremely important. They'll show how the system is supposed to work. When the JAD session participants tell you these steps, they're describing, in effect, what the system will ultimately look like. After this JAD session, you should have a good idea about the components of the system.
The assumptions are important, too. In the list of assumptions, you can list design considerations, as you'll see.
This is what I meant by the system development project being use case driven. The use cases will ultimately create the path to the system.
The Server class seems to figure in the greatest amount of activity. This isn't surprising because the Server interacts with virtually every other class.
The Server use cases are
Take an order
Transmit the order to the kitchen
Change an order
Track order status
Notify chef about party status
Total up a check
Print a check
Summon an assistant
Summon a busser
Take a drink order
Transmit a drink order to lounge
Receive acknowledgment
Receive notification from lounge
Receive notification from kitchen
Let's begin with “Take an order.” The team relies on experienced servers for a description, assumptions, preconditions, steps, and postconditions. The package and subpackage already indicate the initiating actor (Server) and the benefiting actor (Customer).
A good one-sentence description might be, “The server enters the customer's order into the handheld device and transmits it to the kitchen.” The assumptions are that a customer wants a meal, the customer has read the menu, and the customer has made a selection. Another assumption is that the server's handheld has a user interface dedicated to order entry.
The preconditions are that the customer has been seated and has read the menu. The postcondition is that the order is entered into WIN.
The steps in the use case are
On the handheld computer, the server activates the user interface for order entry.
The order-entry user interface appears.
The server enters the customer's menu selection into WIN.
The system transmits the order to the kitchen PC.
Although the assumption is that an order entry interface exists, you haven't yet specified how that interface will look or how the physical act of entering the order will proceed. You don't know yet what the kitchen PC's user interface will look like, nor have you said anything about the technical details of transmitting an order.
The point is that as you state your design assumptions, you're starting to get a handle on what the system is supposed to do, and you'll start to crystallize your thoughts on how to do it. The steps in the use cases force you to come up with assumptions about the components of the system. Remember that the use cases are intended to show how the system looks to a user.
Ready for another? This one will be included in (that is, used by) at least two use cases—the previous one and “Change an order.”
The description is, “Take an order entered into the handheld, put it on the wireless network, and send it to the kitchen PC.” The assumptions are that you'll have a means of communicating the order (via a wireless network), and again, that you have an order-entry interface. Do you have to repeat this assumption? You do. Each use case will eventually appear on a separate page in the design document, which will serve as a reference about the system. For clarity, the assumptions should appear on each use case, even if you have to repeat them from use case to use case.
The precondition is an order entered into a handheld. The postcondition is that the order has arrived in the kitchen. The benefiting actor is the customer.
The steps are
A button-click in the order-user interface indicates “Send to kitchen.”
WIN transmits the order over the wireless LAN.
The order arrives in the kitchen.
The order-entry user interface on the handheld indicates that the order arrived in the kitchen.
Obviously, you have to change your use case diagram for the customer subpackage. It has to show the «include» dependency between this use case and “Take an order” and between this use case and “Change an order.” Figure 19.1 shows the updated use case diagrams for the Server package.
While we're on the subject, let's move to “Change an order.” The description is, “Modify an order already entered into WIN.” The assumption is that an order has already been placed and sent to the kitchen and that, subsequently, the customer wants to change that order. You also assume that WIN has a database of orders showing the server who entered each order and the table the order came from, that the server can access the database from the handheld, that WIN can make transmissions from the handheld to the kitchen PC and back, and that the handheld has a user interface screen for changing an order.
The precondition is the previously placed order. The postcondition is that the modified order has arrived in the kitchen. The benefiting actor is the customer.
The steps in this use case are
On the handheld computer, the server activates the user interface screen for changing an order.
The user interface brings up a list of existing orders in the kitchen placed by this server.
The server selects the order to be changed.
The server enters the modification to the order.
The system transmits the order to the kitchen PC.
(Step 5 includes the previous use case “Transmit the order to the kitchen.”)
As you might recall, earliest discussions about the restaurant of the future included finding out when a customer's order will come out of the kitchen. This use case does just that. Implementing it in the system will go a long way toward facilitating the server's job.
The description is, “Track the status (time to completion) of an order already entered into WIN.” The assumption is that an order has already been placed, has been sent to the kitchen, and that the customer wants to know how much longer it will take for the food to arrive. You repeat two of the previous design assumptions: a database of orders and the capability to transmit messages back and forth between the handheld and the kitchen PC. You also assume a user-interface screen on the handheld for tracking orders and a user-interface screen on the kitchen PC for the same purpose.
The precondition is the previously placed order. The postcondition is that the order status has arrived at the server's handheld. The benefiting actor is the customer.
The steps are
On the handheld computer, the server activates the user-interface screen for tracking an order entry.
The user interface brings up a list of existing orders in the kitchen that this server has placed.
The server selects the order to be tracked.
The system transmits a tracking message to the kitchen PC.
The kitchen PC receives the message.
The chef brings up the tracking order interface on the kitchen PC.
The chef enters a time estimate for the order's completion.
The system transmits the time estimate back to the server's handheld.
Starting with this use case, I'll use subheadings within these subsections to indicate the aspects of the use case analysis, and I'll use bullets to set off phrases within those subheadings—with two exceptions: I'll still number the steps, and I won't use bullets for the description.
Via the network, the server tells the chef that a customer is almost finished with the appetizer.
The server is in the customer's serving area.
The server can gauge the customer's progress.
The system has a user-interface screen for customer status.
The system transmits messages from handheld to kitchen PC and vice versa.
On the handheld computer, the server activates the interface screen for customer status.
The user interface brings up a list of the tables in the server's serving area.
The server selects the table of interest.
The server sends an “almost finished with appetizer” message about this table to the kitchen PC.
The kitchen PC receives the message.
The server receives an acknowledgment from the kitchen PC.
This last step uses the “Receive acknowledgment” use case, which is in the Server package. Figure 19.2 shows a diagram for the “Notify chef about party status” use case. (In somewhat traditional style, Figure 19.2 shows the benefiting actor. Many modelers now don't bother to show this actor in a use case diagram.)
Here's an important use case. Without it, a restaurant wouldn't make any money!
There is a database of orders accessible to the server's handheld.
Each item in the order is attached to its price.
Although this one may seem trivial, it's an important part of the transaction.
This one is important because assistants help keep everything flowing smoothly.
The system allows wireless communication between two mobile employees.
The system has a user interface screen for sending a message to an assistant.
The server activates the interface for sending a message to an assistant.
The server receives an acknowledgment from the assistant.
As in the “Notify chef about party status” use case, the last step uses the “Receive acknowledgment” use case.
Assistant
Analyzing this use case as well as the use cases in the Assistant package, might lead you to believe that splitting the Assistant class into two classes, AssistantServer and AssistantChef, is a good idea. (It just makes things cleaner.) Could they be children of an abstract Assistant class? They could, but you probably wouldn't gain much from setting up this abstract class.
Creating these two new classes necessitates revisiting the domain analysis. You have to rework the class diagrams, particularly the diagram for Employee, as Figure 19.3 shows.
You would also have to update your package diagrams to include an Assistant Server package and an Assistant Chef package.
This is an example of how the segments of GRAPPLE feed each other. The knowledge gained during use case analysis has helped you evolve the domain analysis.
One important aspect of the use case analysis is that you begin to reveal the components of the system. Before you leave this hour, take note of the components that have emerged through your analysis of the use cases in the Server package. You'll find them in the “Assumptions” section of each use case analysis. (Additional components will become apparent when you do the exercises.)
On the software side, it's obvious that a number of user interface screens are necessary. WIN will need handheld-based user interfaces for order entry, order change, order status tracking, customer status, and sending messages to an assistant. For good measure, something like an interface “home page” will be necessary to keep all these other interface screens organized. WIN will also need a user interface on the kitchen PC to enable the chef to see and track each order. In general, any of these user interfaces should display that home page, accept user input, and display messages. If the restaurant wants to really delight its customers, all the user interfaces should be capable of tracking an order and tracking a customer's status. That way, anyone who has access to WIN will be able to answer a customer's questions and be sensitive to that customer's status.
It also seems that you'll need a database to contain all the orders. Each record will contain the table number, the order, the time the order went in, the server, whether the order is active, and more.
Of course, you'll also need an order processor that works behind the interfaces to create orders, send them where they're supposed to go, and register them in the database.
Figure 19.4 shows a class diagram that models the interfaces, the database, and the order processor. It also shows some of their operations. This will come in handy in the next hour when you examine the interactions among these components.
On the hardware side, you'll need a wireless network, handheld computers for the mobile employees (servers, assistant servers, and bussers), and a desktop PC in the kitchen and another in the lounge. You'll need a networked printer in each serving area. You'll probably need a palmtop and a printer for the coat-check clerk, too.
The order processor and the database of orders have to reside on a computer. One possibility is to have a central machine that holds the order processor and the database and makes them accessible to all other machines on the network. The wireless network, then, would allow wireless communication among the handheld computers and desktop PCs and this central computer.
A rather involved design document is starting to take shape. In the next hour, you'll delve even further into the use cases.
It's not enough to list all the use cases. A development team has to understand each one in great detail in order to begin to understand the system. In this hour, accordingly, you went through the intricacies of use case analysis.
A use case analysis involves specifying a description of the use case, deriving the preconditions and postconditions, and specifying the steps. One important aspect of the use case analysis is that the components of the system begin to emerge.
The workshop for this hour tests your knowledge on fleshing out use cases. To see the fleshed-out answers, turn to Appendix A, “Quiz Answers.”
1: | Draw the use case diagram for “Summon an assistant.” |
2: | Analyze the remaining use cases in the Server package, and draw use case diagrams. |
3: | Analyze the use cases in the Chef package, and draw use case diagrams. |
4: | Do the same for the Bartender, Assistant, and Busser packages. |
5: | Examine Figure 19.4. What additional interface classes should the model include? What would their operations be? |