Example of domain model development - a hotel

Textual description of the domain

The hotel has 200 rooms and two restaurants. At the reception desk, people can check-in for a room. At the end of their stay, they have to check-out and pay for the use of the room and any additional charges. In the restaurants, people can sit down at a table or at the bar, and eat and drink. Before leaving the restaurant, they have to pay for their consumption, either in cash or by charging it to their room, if they are registered clients at the hotel.

Dictionary of terms

• Nouns: hotel, restaurant, room, reception desck, people, stay, additional charges, table, bar, consumption, cash, registered client
• Verbs: has, check-in, check-out, pay, sit down, eat, drink, leave, charging-to-room

UML Class Diagram showing entities and their relationships (preliminary sketch)

Identify interactions

The interactions check-in and check-out are interactions between People and the Hotel along the relationship occupies shown in the above diagram. The interaction sit-down is already indicated as a relationship in the diagram above; eat and drink go along the same relationship. The interactions pay and charging-to-room are performed between People and the Restaurant (no direct relationship shown in the diagram above, however, there is the indirect relationship sit-down followed by the contained-in relationship (Table contained in Restaurant).

State diagrams

Here are some sketches of state diagrams: (a) and (b) are two versions of the states and transitions of a room. (c) shows the interactions check-in and check-out and the corresponding state changes of the person (which is an instance of class People).

Executable model using LTSA

Suggestion: Use the LTSA tool to display the state models for CLIENT, REAURANT and ROOM individually, and the global state machine model obtained by composition. Then execute the model interactively. The LTSA specification of this system can be found here.

// state machine of the client: it has only one state, all client actions are possible any time.
CLIENT = (checkIn -> CLIENT | checkOut -> CLIENT |
eat -> CLIENT | payCash -> CLIENT | chargeRoom -> CLIENT).

// state machine of a restaurant. The alphabet of this LTS is {eat, payCash, chargeRoom}
RESTAURANT = (eat -> DONE),
DONE = (payCash -> RESTAURANT | chargeRoom -> RESTAURANT).

// state machine of a room. The alphabet of this LTS is {checkIn, checkOut, chargeRoom}
ROOM = (checkIn -> OCCUPIED),
OCCUPIED = (checkOut -> ROOM | chargeRoom -> OCCUPIED).

// The system consists of one client, one restaurant and one room
||SYSTEM = (CLIENT || RESTAURANT || ROOM).
// List of interactions in this system:
// (a) Rendezvous involving the CLIENT and the RESTAURANT: eat, payCash
// (b) Rendezvous involving the CLIENT and the ROOM: checkIn, checkOut
// (c) Rendezvous involving all three objects: chargeRoom

The above is Version (1) of the hotel system. Below is the global state transition diagram obtained by LTSA:

The following diagram is obtained with Version (2) - see specification. There are two additional interactions which makes the diagram much more complicated:

• enter must be performed before a Client can eat in the restaurant.
• clean is an operation which is done by the Hotel after check-out and before the room becomes free again.

The following diagram is obtained with Version (3) - see specification. In this version, the checkIn and checkOut operations are rendezvous with all three system components, and the RESTAURANT assures that checkIn and checkOut can only be performed when the client did not enter the restaurant. Note: A better understandable diagram is shown on the right. Questions: What are the numbers of the global states in which the Room is in the OCCUPIED state ?