6.9 Alternatives to the main success scenario
If a use case incorporates a scenario that is significantly different from the main success scenario, you may decide to create a new subsidiary use case. There may even be a need to create more than one subsidiary, depending on what happens in different circumstances. For example, when making a reservation in a typical hotel the receptionist would first determine whether the guest was already known to the hotel (among other advantages, this would speed up the reservation process since re-entering of all the guest's details would be avoided). Of course, in the case of a new guest and therefore not known to the hotel, all the guest's details would have to be entered.
Figure 6 shows a development of the hotel system use case diagram that identifies two new sub-use cases: identify guest and create new guest. The identify guest sub-use case is part of the make reservation use case and is connected to the original make reservation use case because it will have to be carried out every time a reservation is made (unconditional behaviour). However, the second new sub-use case, create new guest, which is connected to identify guest will not be carried out every time a reservation is made. Therefore, create new guest is connected to identify guest with an open-headed, dashed arrow labelled with the stereotype «extend». This is conditional behaviour as it is only performed when the guest is not already known to the hotel.
The UML allows a number of ways to record the event that triggers the subsidiary use case. In Figure 6, we have used the general purpose notation for a note to indicate that create new guest is performed when a guest is not already known to the hotel.
The textual description of new use case should record a description of the corresponding scenario. It should contain the following two key points:
the condition that triggers the subsidiary use case, that is, the business event;
the place(s) in the main success scenario where the condition is tested – these are called extension point(s).
Table 3 shows how the original description of the make reservation use case given in Table 2, has been changed to take into account the extension to deal with instances where the hotel has no unoccupied room available for the requested period, and the introduction of a new actor called Reserver. Each step in the main success scenario acts as a potential extension point, from which the relationship to a new use case can be defined. In Table 3, step 3 is the extension point that leads to the additional steps described in steps 3.1 and 3.2. As the second extension point at step 5 shows, some work can be avoided if the potential guest for the reservation has stayed somewhere in the hotel chain before. Where such choices arise, your main success scenario should reflect the more dominant or typical flow. Table 3 reflects an emphasis upon new guests for the hotel chain.
|Identifier and name||UC_1 Make reservation.|
|Initiator||Reserver (may be a Guest or a Receptionist).|
|Goal||Reserve a room at a hotel for a guest.|
|Post-condition||The guest will have been allocated to a room for the requested period and the room will be occupied for that period.|
|Assumptions||The expected initiator is a guest using an Internet browser to perform the use case. The guest is not already known to the hotel's software system (see main success scenario, step 5).|
|Main success scenario|
|1||The reserver requests a reservation on behalf of a potential guest.|
|2||The reserver selects the desired hotel, dates and type of room.|
|3||The receptionist provides the availability and price for the request. (An offer is made.)|
|4||The reserver agrees to proceed with the offer.|
|5||The reserver provides identification and contact details for the hotel's records.|
|6||The reserver provides payment details.|
|7||The receptionist creates a reservation and gives it an identifier.|
|8||The receptionist reveals the identifier to the reserver.|
|9||The receptionist creates a confirmation of the reservation and sends it to the guest identified by the reserver.|
|3||A room matching the request is not available.|
|3.1||The receptionist offers alternative dates and types of room.|
|3.2||The guest selects from the alternatives.|
|5||The guest is already on record.|
|5.1||Resume at step 6.|