Table of Contents
First let us look in more detail at the second part of the last exercise:
Write an application that takes a customer email address and a book ISBN from the command line.
It should check that the customer exists in the database and that a book with the given ISBN exists in the database and exit with an error message otherwise.
If there is no open order for that customer then a new open order is created and the book that matches the book ISBN should be added to the open order with a quantity of 1 and a NULL charge (charge is only set when the order is closed).
If there is an open order for that customer but the order does not contain any copies of this book, then the book that matches the book ISBN should be added to the open order with a quantity of 1 and a NULL charge.
If there was an open order for that customer which already contains any copies of this book, then the quantity for this book should be incremented by 1.
Print to System.out a listing of the customer's details and the customer's open order.
This exercise is essentially a description of one possible operation in an application. One can imagine that if we wrote out all the possible operations in a similar way, we would have a pretty good description of the entire system. The concept of a Use Case was invented to capture this idea. Furthermore, describing your system in use cases often helps to design the actual code and test cases that one needs to develop as well as providing a focus for the construction of the system.
A use case is a description of one operation on a system. it is not a very well defined concept (and certainly not a rigorous one). Use cases describe the requirements of a system in terms of the interactions that should occur between the system and various people and other systems that can interact with it.
Use cases have become a diagram type in the Unified Modelling Language (UML) and a central feature in the Rational Unified Process (RUP), a software design and development methodology. Nonetheless, Use Cases are best represented as textual documents: th diagram form is really only suitable as a quick reminder of what the Use Case represents. Here we recast the exercise above in the form of a use case:
Name Add book to order
Initiator User
Goal Given a customer email address and a book ISBN, add the book
the customer's order
Main Success Scenario
1. User requests that a book be added to a customer's order
2. System identifies customer from email address
3. System identifies book from ISBN
4. System obtains current open order for customer
5. System adds new orderDetail for book to order
Extension
2. No matching customer found
1. Fail
3. No matching book found
1. Fail
4. No open order for customer found
1. Add new order for customer
2. Resume 5
5. OrderDetail for book exists
1. add one to quantity for orderDetail
2. Stop
Since Use Cases are not well defined, you will see differing opinions about the rules for using them. We adhere to those suggested in [CheDan01]
Each use case must have a unique name
Each use case must have an initiator: this is an actor who starts the execution of a use case.
Each use case must have a goal: a short description of the purpose of the use case.
Each use case must have a single numbered sequence of steps that describe the main success scenario. The critical idea about the main success scenario is that it describes the most common situation in which absolutely nothing exceptional happens. To design the steps for the main success scenario, one has to think like the most unrealistic optimist: assume not only that nothing will go wrong, but that it is so certain that nothing will go wrong that you do not need to test even for the simplest things that one expects to have to test for. The extensions (see below) are where we deal with this unrealistic optimism by specifying the tests required and the actions to be taken when the most common situation does not occur.
The following rules apply to the steps:
Each step must be of the form "Actor does something" or "Include use case"
The first step indicates the stimulus that caused the use case to be initiated. The combination of Actor and Stimulus must be unique across all use cases.
Steps cannot use parallelism, recursion, iteration, gotos or conditional statments.
A step can invoke another use case (though not recursively) by naming it in an "Include" statement. In such a case, when the step is executed, the included use case is executed and, when it has terminated, execution continues with the next step in the first use case.
A use case may have a list of extensions. Each extension is essentially a mini-use case that describes an alternative or addition to the main success scenario. They are described after the main success scenario. An extension is made up of:
The step number (also know as extension point) in the main success scenario at which the extension applies.
A condition that must be tested before that step is executed. If the condition is true, the extension is executed, if not, the original step is executed.
A numbered sequence of steps that constitute the extension. Each step can be of the same form and type as in the main success scenario but the last step of an extension can also be one of the following forms:
"Fail": the use case is terminated with the goal unsatisfied.
"Stop": the use case is terminated with the goal satisfied.
"Resume N": the extension ends and the use case continues at step N in the main success scenario.
One of the usual main success scenario forms: the use case continues by executing the step at which this extension started (i.e. the extension does not replace the step it started from: it is inserted before it.)
Thus a use case describes the operation in sufficient detail and sufficiently simply that it is usually relatively straightforward to write the code to handle the use case.
Also, each use case becomes a basis for designing our tests for the system: one needs to test the main success scenario and to test each of the extensions.