Unit 8 Flashcards
Work through the steps of the four use cases for the first iteration of the system as identified in Unit 4, considering whether there are any classes needed to support each step that we have not yet decided to include.
Unit 4 : page 22 - 25
UC1 make reservation
1 The reserver/receptionist makes a reservation request.
2 The reserver/receptionist selects the desired hotel, dates and type of room.
3 The hotel system provides the availability and price for the request; that is, one or more offers are made.
4 The reserver/receptionist accepts the offer.
5 The hotel system requests identification and contact details.
6 The reserver/receptionist provides identification and contact details of the guest for the hotel system’s records, as well as credit card details.
7 The hotel system creates a reservation and gives it a number.
8 The hotel system allocates a room to the reservation.
9 The hotel system reveals the reservation number to the reserver/ receptionist.
UC2 cancel reservation
1 The receptionist/reserver requests the cancellation of a reservation.
2 The receptionist/reserver enters the reservation number or the dates and name and address.
3 The hotel system retrieves the corresponding reservation.
4 The hotel system frees the allocated room.
5 The receptionist/reserver confirms the cancellation.
6 If the cancellation was initiated within 24 hours of the beginning of the reservation, the hotel system charges the credit card whose details are
kept in the reservation.
7 The reservation is cancelled, and the hotel system informs the receptionist/reserver of the cancellation.
UC3 check in guest
1 The guest provides a reservation number or the dates and name and address to the receptionist.
2 The receptionist enters the reservation number or the dates and name and address to find the reservation.
3 The hotel system retrieves the details of the requested reservation.
4 The receptionist confirms the details of the room type and duration of the stay with the guest.
5 The hotel system allocates the room to the guest.
6 The hotel system opens a bill for the guest. (It could be that there is a separate billing package, which must be notified upon check in.)
7 The receptionist issues a key to the guest.
UC4 check out guest
1 The guest requires a bill for a room.
2 The receptionist enters the room number to find the bill.
3 The hotel system provides the details of the bill so far.
4 The receptionist requests details from the guest about any further expenses.
5 The guest provides details.
6 The receptionist calculates the final bill.
7 The receptionist processes payment with the credit card details held for the guest.
8 The hotel system closes the bill and frees the room.
In UC1 make reservation, Step 2 refers to a type of room.
In UC3 check in guest, Step 6 refers to a bill.
We choose to add RoomType as a concept rather than as an attribute, since, as we will see later, it participates in a number of associations. Sometimes decisions like this can simply be based on insight, whereas in other cases they will be taken following further iteration.
Other properties are mentioned, but in each case they can more sensibly be represented as an attribute of an object. For example, reservation number is an integer, a value of a basic data type.
We will regard things like bills and invoices as separate classes, outside the system, because they have lifetimes very different from those of reservations and the like. The lifetime of a bill may even exceed the lifetime of an individual hotel. This situation comes from the fact that bills are considered ‘legal documents’ from the accounting perspective, and thus fall under the regulation-mandated storage rules. As such, they will need to be handled by a separate accounting system.
Our classes are now: Guest, Room, Hotel, HotelChain, Reservation, RoomType.
Identify the associations needed to support the use cases of our first iteration.
UC1 make reservation
UC2 cancel reservation
UC3 check in guest
UC4 check out guest
We need to consider each class against every other class. For Guest, we consider relationships with each of the other five classes; then for Room, we need to consider only four other classes, as the Guest–Room pair has already been considered. Note that in the following, though we identify each relationship only once, this does not imply directionality.
Guest:A Guest can occupy a Room, be a customer of the HotelChain, and have Reservations.
Room:A Room belongs to a Hotel, can be allocated to Reservations, and is of a RoomType.
Hotel:A Hotel belongs to a HotelChain, has Reservations, and has RoomTypes.
HotelChain: See above.
Reservation:A Reservation is for a RoomType.
RoomType: See above.
Draw the initial class diagram for the domain model.
We have also chosen to add a couple of role names, but this was not requested in the question. For the other associations, although we have quite a rich diagram, there are no pairs of classes that have more than one association directly between them, and the associations are mostly fairly obvious. In any case, they are identified in the glossary.
Identify the associations needed to support the use cases of our first iteration.
We need to consider each class against every other class. For Guest, we consider
relationships with each of the other five classes; then for Room, we need to consider
only four other classes, as the Guest–Room pair has already been considered. Note
that in the following, though we identify each relationship only once, this does not imply
directionality.
Guest:A Guest can occupy a Room, be a customer of the HotelChain, and have
Reservations.
Room:A Room belongs to a Hotel, can be allocated to Reservations, and is of a
RoomType.
Hotel:A Hotel belongs to a HotelChain, has Reservations, and has RoomTypes.
HotelChain: See above.
Reservation:A Reservation is for a RoomType.
RoomType: See above.
Go through each step of each of the use cases for this iteration, checking that the relevant associations are present in the class diagram.
Unit 4 : page 22
Unit 8 : page 12
The relevant associations are indeed present.
Add multiplicities to the diagram in Figure 3.
By working through the use cases for the current iteration step by step, add the attributes needed at this stage to the concept diagram in Figure 4, together with their corresponding data types.
Note that in analysis, there are some basic data types, such as Number, String, Character, Date and Boolean; where none of these seems appropriate we use a placeholder, a made-up name such as RoomKind, employed just for the time being, until we have sufficient information to decide what actual data type to use.
The make reservation use case (UC1) suggests several attributes, as shown in Table 8.
The other use cases suggested no attributes to us. The types that we have allocated to each attribute in the revised concept diagram of Figure 5 arejust placeholders at this point in the development.
Consider the make reservation use case described above, and write the signature for a corresponding operation.
context HotelChain::makeReservation(hotel : Hotel, startDate : Date, endDate : Date, roomType : RoomType, reserverPayer : ReserverPayer)
Consider the snapshot in Figure 7, and draw a snapshot after the execution of the system operation makeReservation(hotel1, “8/4/2007”, “10/4/2007”, roomType2, reserverPayer3).
Assume that the allocated room is room1 (with room number 101).
Figure 7 is available on the course website.
Discuss how you would apply GRASP to assign Hotel the responsibility for finding out the availability of a room of a specified type.
GRASP Expert would apply here, in assigning the responsibility to the Hotel class, as Hotel knows about all its rooms, room types and reservations.
Consider the operation that would determine the availability in a hotel of a room of a specific type, for given start and end dates, and write its signature.
context Hotel::available(startDate : Date, endDate : Date, roomType : RoomType) : Boolean
Which parties are involved in satisfying the postcondition of a system operation? How can you identify them?
The parties are:
- the actor that initiates the corresponding use case;
- the system object, which orchestrates the collaboration;
- a set of objects within the system which are required to satisfy the postcondition; these can be identified by looking at the operation specification.
By looking at makeReservation’s postcondition, identify the objects which are involved in the collaboration, and their links.
post:
–if available(startDate, endDate, roomType) executed in the Hotel with hotelName
–returned true then
–a new Reservation object, reservation will have been created (object creation)
–if there is not a ReserverPayer with given details in that Hotel then
–a new ReserverPayer object will be created with attributes set to name, address,
–creditCardDetails and a newly generated id
–the new ReserverPayer object will be linked to hotelChain
–that Hotel will be linked to reservation –the ReserverPayer will be linked to reservation
–reservation will be linked to roomType
–reservation will be linked to a previously free Room
–a string indicating the reservation number will have been returned
–otherwise, a string indicating failure will have been returned
Besides the system object, there is a Hotel object, a ReserverPayer object (either preexisting or newly created), a RoomType object, a Room object and the newly created Reservation object.
By looking at checkInGuest’s postcondition, identify the objects which are involved in the collaboration.
post:
–if name is not that of the ReserverPayer of the Reservation with reservationNo, then
–a new Guest will be created, and its attributes set; this new Guest or,
–otherwise, the ReserverPayer will be linked to the Room with roomNo
Besides the system object, there is a Hotel object, either a pre-existing ReserverPayer object or a newly created Guest,a Room object, and a Reservation object.
