Student_Answers_Chapter_04.doc

Suggested answer for Exercise 4.1In this situation, the manager is not drawing the distinction between the users of a system and the roles they can play when using the system, represented by actors. The existence of an actor in a use case model does not imply that there is a particular individual restricted to that role. Any of the restaurants staff who are able to record reservations will be able to do so by adopting for the purpose the Receptionist role, or acting as a Receptionist. In practice, this might mean no more than logging on to the system using a particular user id.Suggested answer for Exercise 4.2The redrawn use case diagram is shown below. When the Staff actor is removed, the association with the Display Bookings use case must be shown explicitly for both the Receptionist and Head Waiter actors. The actors have been shown twice to simplify the drawing of the associations; this has no effect on the meaning of the diagram. This diagram is not quite equivalent to Figure 4.7. Both diagrams specify the same capabilities for the Receptionist and Head Waiter actors, but in addition Figure 4.7 defines an actor Staff who only has the ability to display bookings. No such actor is defined in the diagram above, though a Staff actor could easily be added if required. Because this is a simple diagram, there is not much difference in complexity between the two versions. In more complicated diagrams, however, the use of actor generalization can significantly reduce the number of associations that have to be shown, thus simplifying the diagram. The use of superactors also makes it easier to see when use cases can be performed by a variety of actors. Suggested answer for Exercise 4.3The following scenario describes a possible approach to this situation. Record booking - double booked table: exceptional course of events 1. The receptionist performs the Display Bookings use case for the date requested by the customer. 2. There is a suitable table available: the receptionist enters the customers name and phone number, the time of the reservation, the number of covers and the table number. 3. The data entered overlaps with another booking made for the same table; the system issues a message informing the receptionist of this. 4. The receptionist acknowledges the message, and the use case terminates with no reservation being made. I have classified this as an exceptional course of events because it arises from a mistake made by the user that results in a divergence from the basic course of events.Suggested answer for Exercise 4.4The answer to this question depends in part on how the record arrival operation is made available to users. If, for example, a pop-up menu presents the operations available on the selected booking, the record arrival option could be disabled in the case where arrival has already been recorded for the selected booking. If this approach was adopted, no alternative or exceptional course of events would be required, as the system would automatically prevent the situation arising. Alternatively, the system could detect this situation and warn the user appropriately, as described below. Record arrival - arrival already recorded: exceptional course of events 1. The head waiter performs the Display Bookings use case for the date requested by the customer. 2. The head waiter confirms arrival for a selected booking. 3. The booking is already recorded as arrived, so the system displays a warning message without altering the booking. 4. The head waiter confirms that no action is to be taken. Suggested answer for Exercise 4.5The most obvious exceptional case is if the user enters a date that is in some way invalid. Display bookings - invalid date: exceptional course of events 1. The user enters a date. 2. The date was invalid in some way, perhaps wrongly formatted or something like 31 February, 2004. The system reports the error to the user and prompts for the date to be reentered. The case where there are no bookings to be displayed for the date selected is not really an alternative course of events, as it is implicitly included in the basic course: if there are no bookings, the system simply has nothing to display for that date.Suggested answer for Exercise 4.6Various alternative and exceptional courses of events for these use cases are listed and briefly described below. Cancel bookings - invalid date: exceptional course of events 1. The receptionist performs the Display Bookings use case for the date given by the customer. 2. The receptionist selects and cancels the relevant reservation. 3. The date of the booking is prior to the current date: the system displays a suitable error message and the booking is not cancelled. Cancel bookings - booking arrived: exceptional course of events 1. The receptionist performs the Display Bookings use case for the date given by the customer. 2. The receptionist selects and cancels the relevant reservation. 3. The booking is already recorded as having arrived: the system displays a suitable error message and the booking is not cancelled. Table transfer - table too small: exceptional course of events 1. The head waiter performs the Display Bookings use case for the current date. 2. The head waiter selects the required booking. 3. The head waiter changes the table allocation of the booking. 4. The number of covers recorded for the booking is larger than the maximum specified size of the new table, so the system issues a warning message asking the head waiter if the transfer should go ahead. 5. If the answer is no, the booking is not modified. 6. If the answer is yes, the system records the alteration and updates the display. Table transfer - invalid date: exceptional course of events 1. The head waiter performs the Display Bookings use case for the current date. 2. The head waiter selects the