• Shuffle
    Toggle On
    Toggle Off
  • Alphabetize
    Toggle On
    Toggle Off
  • Front First
    Toggle On
    Toggle Off
  • Both Sides
    Toggle On
    Toggle Off
  • Read
    Toggle On
    Toggle Off
Reading...
Front

Card Range To Study

through

image

Play button

image

Play button

image

Progress

1/3

Click to flip

Use LEFT and RIGHT arrow keys to navigate between flashcards;

Use UP and DOWN arrow keys to flip the card;

H to show hint;

A reads text to speech;

3 Cards in this Set

  • Front
  • Back

In the above conceptual models we have conflated the concepts of guest, reservation-maker and bill-payer. Is this realistic? Would the people playing these roles necessarily be the same person?

There are a number of problems with this simplification. In reality, a hotel should allow for the roles to be distinct. It should be possible to have guests recorded who neither pay a bill nor make a reservation. For example, partners and children may be staying in the hotel along with a person who reserves and/or pays the bill. In fact, the hotel would almost certainly want a complete picture of who is staying in the hotel for a range of reasons.


A separate issue is whether it should be possible for one person to reserve on behalf of another, or pay on behalf of another. On the one hand, allowing this gives more flexibility but on the other hand, having the credit card details of an actual occupier might make the sanction of charging for things such as damage stronger. There is also a modelling issue here because some people reserving rooms will also be guests and some not, and not all guests will make reservations – for example, partners as above. You might like to try drawing a simple class diagram to see the problems this poses for inheritance.


For the reasons identified in the previous question, we want to separate out the role of a guest from that of a person making reservations or paying bills. Are objects of the class RoomType shared across hotels? Does this present any problems?

The model permits the sharing of RoomType objects across hotels. This can be seen by the multiplicity at the Hotel end of the relevant association. However, this is problematic: if we try to find all the rooms a hotel has by navigating via the RoomType objects, we may include rooms from other hotels! In any case, there is an argument for making the RoomType objects associated with a Hotel unique to that hotel, as prices for a given type of room are likely to vary depending on location and local market conditions. This is what we decide to do.

Does the model cover reservations for multiple rooms?

No. This can be seen from the multiplicities of 1 on the ReservationRoomType and ReservationRoom associations.