Department of Computer Science

Willowbank - Use Cases

To: Systems Design and Development

See (e.g.) 'Using UML' and 'The UML User Guide' for more detail. The User Guide defines a use case as "a description of a set of sequences of actions ... that a system performs to yield an observable result of value to an actor". Informally, we can think of a use case as a task which the system has to perform, and the actor as the beneficiary of that task.

Some General Comments on Your Submissions

Naturally we didn't expect perfection; you hadn't seen many examples of use cases, and they are a pretty informal technique anyway. There aren't lots of rules or guidelines to help you disinguish between a 'good' use case and a not-so-good one. Anyway, we only asked for high-level use cases.

Quite a few groups didn't hand anything in.

There were some good attempts, however, but a lot of these confined to the fairly obvious ones.

Names of use cases should start with an 'active verb', as a use case is about what the system does.

Actors

There were some strange choices of these. Actors are external to the system, so it wasn't really appropriate to have the database(s) as actors. I know that the database in the Scanner case study was modelled as an actor, but that database really is external: it already exists completely independently of our system, which has to deal with it. In Willowbank, though, the database is part of the system we are designing; we have control over it - it is definitely not given, fixed and external.

Also, I don't think it is appropriate to identify hardware devices as actors; at this stage, if at all possible it is better to model in terms of human users than (say) keyboards and (in the client-server system) terminals. In some systems this won't be possible: there will be a lump of hardware with no obvious associated human, but I don't think Willowbank falls into this category.

A more difficult decision concerns whether the humans should be those operating the system, or those on whose behalf the system is operated; i.e. is the actor in 'Make Reservation' the Willowbank employee or the club member? Both of these could be said to 'benefit' from the use case. I think both of these positions are tenable; my conclusion is that because, in practice, the use case should be checked with the actor to validate the requirements, it is more sensible to have the Willowbank operatives as the actors, rather than members, non-members, guests, etc.

So the use cases that I have done so far involve only two actors, corresponding to the two levels of access to the proposed system. We could call these 'User' (deals with membership and reservations) and 'SuperUser' (also has access to management functions), but I shall use the terms 'Receptionist' and 'Administrator' .

In passing, notice that the Administrator in this sense is a specialization (or subtype) of a Receptionist and inherits its behaviour! Everywhere a Receptionist is allowed, an Administrator can be substituted. So inheritance even appears here; again see either of the books cited above for further information.

Reusing Use Cases

Once you start producing use cases for a system of any size, you find chunks of functionality which occur in more than one use case. The User Guide defines an 'include' mechanism, which allows one use case to include the text of another at a specified point (in 'Using UML', this is called 'uses' imstead, but 'include' is the official, and an obviously better, term). This is illustrated in the examples below.

Event Flows

The User Guide recommends separating out normal and exceptional event flows in use cases.

Some Sample Use Cases

Hopefully these will help; they are no doubt imperfect, and I'm sure some of yours' were as good, if not better. These are presented in full detail (i.e. not high-level use cases). I've tried to be specific about what data gets input, but not how the input takes place; we are dealing here with requirements, so issues that are really to do with the user interface design should not be included.

The following use cases are detailed here:

• Make Reservation
• Cancel Reservation
• Record Payment
• Login
• Amend Calendar
• Validate Member - included in Make Reservation, and other (as yet unwritten) use cases
• Find Reservation - included in Cancel Reservation, Record Payment, etc.

-------------------------------------------------------------

Actor: Receptionist

Main Flow of Events: This use case starts when the Receptionist requests to make a reservation. The system prompts for a date, time, duration and sport, which the Receptionist enters. The system displays a list of courts available for that sport over that time period. The Receptionist chooses a court. include (validate member). If the member number is valid, the system asks the Receptionist for confirmation, and (if confirmed) reserves the chosen court for that member for that date, time and duration.

Exceptional Flow of Events: If no courts are available that meet the member's requirements, the system indicates this and allows the Receptionist to edit any of date, time and duration.

Exceptional Flow of Events: The Receptionist can cancel the entry at any time prior to confirmation.

-------------------------------------------------------------

Actor: Receptionist

Main Flow of Events: The Receptionist enters the member number. The system checks that it has a record of a member with this number. If so, it displays the member's name for confirmation; if not, it displays a suitable message, and allows the Receptionist to edit the member number.

-------------------------------------------------------------

Use Case: Cancel Reservation (assumes refunds at Receptionist's discretion)

Actor: Receptionist

Main Flow of Events: This use case starts when the Receptionist requests to cancel a reservation. include (find reservation). The Receptionist chooses the reservation corresponding to the member number; the system asks the Receptionist for confirmation, and (if confirmed) asks whether a refund is to be given, recording the Receptionist's answer. The system then cancels the reservation.

Exceptional Flow of Events: The Receptionist can cancel the entry at any time prior to confirmation (e.g. If the member number does not occur in the list of reservations).

-------------------------------------------------------------

Actor: Receptionist

Main Flow of Events: This use case starts when the Receptionist requests to record a payment for a session. include (find reservation). The Receptionist chooses the reservation corresponding to the member number; enters the payment details, the system asks the Receptionist for confirmation, and (if confirmed) records the payment details.

Exceptional Flow of Events: The Receptionist can cancel the entry at any time prior to confirmation (e.g. If the member number does not occur in the list of reservations).

-------------------------------------------------------------

Actor : Receptionist

Main Flow of Events: The system prompts for the reservation date, time and sport, which the Receptionist enters. The system displays a list of courts reserved for that sport at that time, together with the member number of the member who made the reservation.

-------------------------------------------------------------

Actor: Receptionist

Main Flow of Events: This use case starts when the Receptionist requests to start a work session. There must be no user currently logged on at this terminal. The Receptionist enters their user identification and password, the system verifies these and (if valid) starts a session.

Exceptional Flow of Events: If the verification fails, the Receptionist is allowed to edit both user identification and password and resubmit them.

-------------------------------------------------------------

Actor: Administrator

Main Flow of Events: This use case starts when the Administrator requests to record the fact that the club is going to be closed on a day when it would normally be open. The Administrator enters the date concerned, the system asks for confirmation and (if confirmed) records the closure.

Exceptional Flow of Events: The Receptionist can cancel the entry at any time prior to confirmation.

-------------------------------------------------------------

Other Use Cases

This list is not meant to be exhaustive, just to suggest the sort of things you should be considering.

 References

Using UML: Software Engineering with Objects and Components Pooley & Stevens; Addison-Wesley Object Technology Series 1999

The Unified Modeling Language User Guide Booch, Rumbaugh & Jacobson; Addison-Wesley Object Technology Series 1998