Requirements for the Prototype Reservation System

A good way to capture requirements is to describe use cases. Use cases are simple interactions between one or more types of users and the system. They explain the work that the user will want to do when working with the running system.

The use cases for the reservation system include one or more users who may be anonymous or identified. Anonymous users may view open rentals, but to make, view, or cancel a reservation, the user must identify himself. For simplicity, the identity is not authenticated. In addition to the one or more anonymous or identified users, the use cases specify an administrator who populates the datastore with initial data.

One of the virtues of this example is that the rentals may be contested. Two users can simultaneously attempt to reserve the same lighthouse for the same week. Since the rental Swing application supports only one user's interaction at a time, to see the interaction of conflicting reservations, you will need to use a datastore that supports multiuser access. The b-tree file datastore used by the reference implementation does not support multiuser access, but most other JDO implementations will use datastores that do support multiuser access. If you are using the JDO reference implementation, you will be able to exercise all of the uses cases presented, except use case 10, in which the system detects conflicting reservations. You cannot test this use case with the reference implementation because the b-tree file datastore does not support two clients in different JVMs accessing the same data files at the same time.

In the next sections, the use cases for the prototype of the reservation system are described. Notice that they are simple, as they should be. Because use cases must communicate to everyone how the software behaves, they should be as simple as possible. Although the various prototypes of the reservation system presented in this book vary in their architecture, each implementation satisfies the same set of use cases.

Use Case 1: The Administrator Clears the Datastore

In this use case, the administrator removes any rental information as the preliminary step to initializing the datastore with testing data. The interaction involves two steps.

1. The administrator requests that the datastore be cleared of all rental information.

2. The system clears the datastore of all rental information.

Use Case 2: The Administrator Initializes the Datastore

In this use case, the administrator initializes a clean datastore with the testing data. A number of rentals are created for a number of weeks. The middle portion of the rental period is the high season when rates are higher than during the off-season. The interaction involves two steps.

1. The administrator requests that the datastore be initialized with the standard testing data.

2. The system populates the datastore with the standard testing data.

Use Case 3: An Anonymous User Identifies Himself

In this use case, an anonymous user declares his identity, or an identified user changes his identity. Thereafter, he is an identified user with a name. The interaction involves two steps.

1. The user presents his name.

2. The system accepts the name and assumes thereafter that the user with this name is using the system.

Use Case 4: An Identified User Discards His Identity

In this use case, an identified user reverts to an anonymous user. The interaction occurs in two steps.

1. The user revokes his identity.

2. The system discards the current user identity and assumes that an anonymous user is using the system.

Use Case 5: A User Views Available Rentals

In this use case, the user, who may be anonymous or identified, views the available rentals. The interaction occurs in two steps.

1. The user asks to see the available reservations.

2. The system displays the available reservations.

Use Case 6: An Identified User Makes a Reservation

In this use case, an identified user makes a reservation. This use case assumes that the user is viewing the reservations as a result of completing the interaction in use case 5. The system will not permit an anonymous user to make a reservation. The interaction is completed in three steps.

1. The identified user selects one or more available rentals to reserve.

2. The user confirms the reservations.

3. If the reservations are accepted, the system displays all of the user's reservations. Otherwise, see use case 10.

Use Case 7: An Identified User Views His Reservations

In this use case, an identified user views his own reservations. This interaction is completed in one or two steps.

1. The identified user asks to see his own reservations, or alternatively, this step is skipped if the user has just completed use case 6.

2. The system displays the user's reservations.

Use Case 8: An Identified User Cancels Some Reservations

In this use case, the identified user begins the interaction after viewing his own reservations. The system will not permit a user to cancel reservations that belong to a different user.

1. The identified user selects one or more of his reservations to cancel.

2. The user confirms the cancellations.

3. The system accepts the cancellations and displays all of the user's remaining reservations.

Use Case 9: An Identified User Alters His Reservations

In this use case, the identified user views both his own reservations and the available reservations. He may also see reservations that belong to others. The user can cancel his own reservations and make new reservations in one transaction. In this fashion, there is no danger when changing a reservation that he ends up with the old reservation cancelled but the new reservation rejected.

1. The identified user asks to see both available rentals and his own reservations.

2. The system displays the same.

3. The user selects zero or more reservations to cancel and rentals to reserve.

4. The user confirms the changes.

5. If the system accepts the changes, it displays all of the user's reservations. Otherwise, see use case 10.

Use Case 10: The System Detects Conflicting Reservations

In some cases, the changes confirmed by a user cannot be accepted because they conflict with changes made by another user. This happens when two different users seek to reserve the same rental at approximately the same time. Only one will be successful. The other is informed of the failure.

1. The system informs the user that the reservation cannot be accepted because it conflicts with a reservation made by another user.

2. The system refreshes the information that caused the problem.

3. The user has the option to refresh all information.

Use Case 11: User Views Additional Information on a Rental Unit

In this use case, the user requests additional information about a rental unit. This request can be made from any of the views of available rentals or reservations. The interaction takes place in three steps.

1. The user requests more information on a rental unit.

2. The system displays it.

3. At a later point, the user returns to the original view.