Tm354 - Unit 8.1, 8.2

Front 1

Work through the steps of the four use cases for the first iteration of the system as identified in Block 1 Unit 4, considering whether there are any classes needed to support each step that we have not yet decided to include.

Back 1

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 because, as you 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, for example, reservations. The lifetime of a bill may even exceed the lifetime of an individual hotel. This is because 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.

Front 2

Identify the associations needed to support the use cases of our first iteration.

Back 2

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. Although we identify each relationship only once below, 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.

Front 3

Draw the initial class diagram for the domain model.

Back 3

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.

Front 4

• Go through each step of each of the use cases for this iteration, checking that the relevant associations are present in the class diagram.
• Add multiplicities to the initial class diagram in the previous question.

Back 4

• The relevant associations are indeed present.
• This conceptual model diagram shows the multiplicities for each of the associations.

Front 5

By working through the use cases for the current iteration step by step, add the attributes needed at this stage to the conceptual model in Figure 4, together with their corresponding data types.

Be aware 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 temporarily, until we have sufficient information to decide what actual data type to use. This is an example of an attribute that could be represented as an enumerated type. We don’t need the generality of a class to represent it.

Back 5