W h a t we do when identifying use cases is to divide up the system~
functionality into chunks, into the main system activities. W h a t dictates the split is what the user sees as the separate jobs or processes
- the tasks he will do using the system. We are not attempting in the use case model to achieve a division of the system into logical software units; we are just attempting to capture the user~ view of the system.
Identifying use cases f r o m the actors. There are several ways of approaching use case identification. One is to identify the actors, the users of the system, and for each one, to establish how t h e y use the system, w h a t t h e y use it to achieve. If we look at the i n t e r v i e w in Chapter 2 we can see that Annie and Simon start off by talking about issuing bikes, one of the main jobs that make up Annie's w o r k i n g day. Issuing bikes therefore will be one of the use cases.
Issuing bikes involves finding a suitable bike, calculating the hire charge, collecting the money, issuing a receipt and recording details of the customer and the hire transaction.
The interview moves on to discuss dealing with the return of a bike. Annie sees this as a separate job from issuing the bike, it is separated in time and involves a different set of p r o c e d u r e s - checking the date and the condition of the bike and returning the deposit.
Annie tells us in the i n t e r v i e w that a list of bikes is already held on the computer, b u t t h e y do not seem to be able to use it to help t h e m in their work. The bike list needs to be stored so that it can be used to answer queries about w h a t bikes Wheels have, w h e t h e r t h e y are available or on hire, w h a t their deposit and hire charges are and so on. M a i n t a i n i n g this bike list is another use case.
Handling queries is seen by Annie as a separate job from issuing bikes. She often gets people coming into the shop or p h o n i n g just to check on the range of bikes available and get an idea of costs.
This sometimes leads to a hire, but more often it does not. We can therefore identify 'Handle enquiries' as a separate use case.
It also emerges from the interview that no record is kept of customer details or of what bikes they have hired on previous occasions. This sort of information would be useful for marketing purposes and to simplify dealing with requests for the same bike (see the Problem Definition (Figure 2.6), the Problems and Requirements List (Figure 2.7) and the Interview Summary (Figure 2.8)). 'Maintain customer list' can therefore be identified as a use case.
Identifying use cases from scenarios. Another approach to identifying use cases is to start with the scenarios. We have already mentioned scenarios in Chapter 2 - a scenario describes a series of interactions between the user and the system in order to achieve a specified goal. A
USE CASES THE USE CASE
43
scenario describes a specific sequence of events, for example what happened when Annie successfully issued a bike to a customer (see Figure 3.3). Depending on the stage they have reached, system developers can use scenarios to describe what did actually happen (or might typically have happened) on one occasion or how they want things to happen in the new system. A careful study of scenarios depicting both typical and exceptional uses of the system is a very good way to understand what the system does and how it is used. It~ a bottom up approach to understanding a system. You start by looking at the details of how the system is used and from this work out what the overall aims and objectives are and from this what the use cases are.
Each use case represents a group of scenarios. Scenarios belonging to the same use case have a common g o a l - each scenario in the group describes a different sequence of events involved in achieving (or failing to achieve) the use case goal. Figures 3.3 and 3-4 describe scenarios belonging to the 'Issue bike' use case; in both cases Annie is trying to issue a bike to a customer.
9 Stephanie arrives at the shop at 9.ooam one Saturday and chooses a mountain bike 9 Annie sees that its number is 468
9 Annie enters this number into the system
9 The system confirms that this is a woman~ mountain bike and displays the daily rate (s and the deposit (s
9 Stephanie says she wants to hire the bike for a week
9 Annie enters this and the system displays the total cost s + s = s 9 Stephanie agrees this
9 Annie enters Stephanie~ name, address and telephone n u m b e r into the system 9 Stephanie pays the s
9 Annie records this on the system and the system prints out a receipt
9 Stephanie agrees to bring the bike back by 9.ooam on the following Saturday.
Figure 3.3 Successful scenario for the use case "Issue bike"
9 Michael arrives at the shop at 12.oo on Friday 9 He selects a man~ racer
9 Annie see the number is 658
9 She enters this number into the system
9 The system confirms that it is a man~ racer and displays the daily rate (s and the deposit (s
9 Michael says this is too much and leaves the shop w i t h o u t hiring the bike.
Figure 3.4 Scenario for "Issue bike" where the use case goal is not achieved
44 A STUDENT GUIDE TO OBJECT-ORIENTED DEVELOPMENT
Coming to grips w i t h the required functionality by s t u d y i n g typical user interactions w i t h the system is a t e c h n i q u e that has been used informally by software developers since long before the arrival of object-orientation. Use cases are not essentially object- oriented; t h e y are a useful tool w h a t e v e r method of developing software is being used. Use case modelling formalizes and documents a long-standing practice. Jacobson (1992) was responsible for raising the profile of the use case to the extent that it is now almost universally a d o p t e d by the object-oriented community, is formally included in the UML notation and is part of almost all object-oriented methods of developing software.
It would be an inefficient use of time for a developer to write scenarios for every possible sequence of events in a use case. A software tester writes test cases to test an intelligent selection of cases; he tests to agreed coverage criteria. In much the same way a developer should write a representative set of scenarios. The scenarios should document:
9 A typical sequence of events leading to the achievement of the use case g o a l - e.g. a customer hires one bike
9 Obvious variations on the n o r m - e.g. a customer hires several bikes for a fixed period; a customer hires several bikes for different periods; a customer hires a specialist bike etc.
9 Sequences of events where the use case goal is not achieved - e.g.
the customer cannot find a bike he likes; the customer t h i n k s the cost is too great, etc.
The developer needs to be sure he u n d e r s t a n d s and documents how the system should r e s p o n d in every eventuality. He will probably write detailed scenarios to d o c u m e n t large or complicated use cases, but small, simple use cases can be a d e q u a t e l y described by use case descriptions (see below).
To summarize, the p u r p o s e of the use case model is to describe, from the user~ perspective, w h a t the system does. A use case describes a cohesive piece of the system~ functionality as the user perceives it. The user may see it as a task that he uses the system to achieve, one of the jobs that make up his daily workload, or it may produce a list or a report that he gets from the computer. A use case is a complete e n d - t o - e n d use of the computer, a complete p a t h t h r o u g h the system. A use case must deliver some benefit to the actor associated w i t h i t - it must have a goal. Each use case will have several scenarios associated w i t h it. Some will be successful, i.e. achieve the use case goal, some will not. The software developer needs to be aware of all possible scenarios because the system must be able to cope w i t h t h e m all and respond appropriately. However,
USE CASES