Student_Answers_Chapter_05.doc

Suggested answer for Exercise 5.1The restaurant object is clearly not a boundary object, but it might appear to share some characteristics of both control and entity objects. As it is responsible for maintaining data, it might be argued that the entity stereotype was appropriate. This stereotype is normally used for data in the system that represents a single external entity, however. The restaurant object does not represent an entity in this sense, however, but instead makes other entities available in the system. The entity stereotype is probably not appropriate for the restaurant object, therefore. There is a control aspect to the restaurant object, as it is controlling access to the entity data held by the system. This is more a question of being a gatekeeper to some system resources than controlling a number of interactions, as the booking system object does, and it is probably clearer not to represent both by the same stereotype. It therefore appears that none of the analysis class stereotypes straightforwardly applies to the restaurant object, and it has been left in Figure 5.4 as a plain object. Suggested answer for Exercise 5.2The date attribute in the booking system class represents the date for which booking information is currently being displayed by the system. The date attribute in the current bookings should be the same as this, therefore, otherwise the system will be displaying bookings for the wrong date. This can be specified by a constraint on the current association as shown below. Suggested answer for Exercise 5.3On the face of it, this proposal might seem to be attractive on the grounds of removing redundancy, following the guideline that data should not be stored in more than one place. However, removing the date attribute from the booking system object would create problems in the situation where there are no bookings yet recorded for a date the system is asked to display. In this case, the system would have no record of what date was currently being displayed. If a walk-in booking was then created, for example, it would be difficult to work out the date required for the new booking object. This suggests that storing the date in both classes is not in fact redundant, as the two occurrences of the attribute have different semantics, one referring to the date being displayed by the system, and the other to the date of an individual booking. In cases like this, care needs to be taken before optimizing one of the attributes away. Suggested answer for Exercise 5.4Producing a realization for this scenario involves deciding which object is responsible for detecting that the date is invalid. A reasonable guideline to adopt here is to validate user-entered data as soon as possible. This would mean that the booking system object should be responsible for detecting errors, and so a realization might be as follows. The restaurant and booking objects have been left on this diagram to emphasize that they do not receive any messages in the course of this interaction. It is not necessary at this level of detail to attempt to specify how the system reports the error to the user and requests reentry of the date. We can simply assume that when the user reenters the date a new system message will be generated, and either the interaction above or the one in Figure 5.5 will take place again. Suggested answer for Exercise 5.5The complete sequence diagram is shown below. Suggested answer for Exercise 5.6The sequence diagram for Record walk-in is shown below. Apart from changing the actor, class and operation names throughout to refer to walk-ins, the most significant change is that a customer object does not need to be located. Details referring to customers have therefore been removed from the diagram. Suggested answer for Exercise 5.7A realization for the case where the customer is already known to the system is shown in the diagram below. As in Figure 5.5, the restaurant object retrieves data from customer objects to compare with the name and phone number of the requested customer. Assuming that a match is found, a customer object is returned to the caller. In the case where no matching customer is found, a new instance is created and a reference to it is returned to the caller, as shown below. Suggested answer for Exercise 5.8A possible sequence diagram for table transfer is shown below. The required table is first selected, as shown in Figures 5.9 and 5.11. Then the table object corresponding to the number of the new table is retrieved from the restaurant object, as in Figure 5.8. Finally, the table allocated to the selected booking is updated, and the display refreshed. An alternative design might pass the table number to the selected booking, which would then have to retrieve the required table object from the restaurant itself. This design is slightly more decentralized than the one above, but on the other hand introduces a circular dependency between the booking and restaurant classes. The design shown above is therefore probably preferable. Suggested answer for Exercise 5.9The diagrams below show the classes from Figure 5.13 with type information added to attributes and operations. The additions are strictly based on what is stated in the various realizations given in Chapter 5, and do not attempt to define final signatures for the operations. This will be considered later when implementing each