Step 1 (facts finding/brain storming)

• There are four different room types
• The system has information on each room's availability
• The price of the room is set by their type.

Note: In the real case, in addition to those obvious from the problem statement, you might also consider other things, which are not explicitly mentioned such as:

• each room's booking status
• special price for certain period (such as weekday/weekend)
• special tourist package plan, etc.

However, here we just focus on things which are obvious from the problem statement.

Step 2 (viewpoint/concept)

There seem to be two different types of information:

• information for each room,
• information for each room type.

For instance

• Room information (unique to each room)
  • room number
  • availability
  • room type
• Room Type information
  • price

The important thing here is to realise that the "price" is not unique to each room but to each room type. (If you put the price under each room, you will have many duplications.)

Step 3 (modelling)

The initial relationship between the uni villege and the room(s) would be:

The "room no" box is a specifier and the diamond mark indicates the aggregation. So, that means there are many rooms belong to the uni village, and each room can be identified with the unique specifier.

Furthermore, each room will obtain its price based on its type form the room type class:

You might say, this class diagram does not say much about what sort of types are available. If you wish to show the types of rooms, then you could use "Object Diagram" or "Instance Diagram".

Typical mistake

If you decide to include the price information in the room class, you might have a class diagram like:

It appears good because it represents the relationship between the uni village and rooms along with types of rooms. However, with this design you would need to store redundant information such as the room price, which should be obtained as the attribute of the room type.