Suggested answer for Exercise 5.1
The 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.2
The 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.3
On 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.4
Producing 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.5
The complete sequence diagram is shown below.
Suggested answer for Exercise 5.6
The 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.7
A 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.8
A 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.9
The 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 class.
Where detailed parameters have not yet been defined, types such as BookingId and BookingDetails have been used as placeholders.
The OCL collection type Set(T) has been used to indicate that the Restaurant.getBookings operation returns in general more than
one bookings object.