Entity class extraction

Noun extracting approach

  • Step 1: Describe the functions of the system in a short and complete paragraph.
  • Step 2: Extract all nouns which appear in the step 1. Each noun is counted only one time.
  • Step 3: Classify the nouns in the step 2.
    • A noun could become an entity class.
    • A noun could become an attribute of an entity class.
    • Reject a noun if it is too general, too abstract, or out of the scope of the system.
  • Step 4: Consider the quantitative relationship among entity classes.
    • If it is 1-1 then: keep it or regroup two classes into one.
    • If it is 1-n then keep them.
    • If it is n-n, then it should be divided into at least 2 relationships of type 1-n.
  • Step 5: Determine the object relationship among entity classes: generalization, aggregation, composition, association, dependence…

Applying

Step 1: describe the system within a paragraph

The system supports to manage the information about a hotel, the room of the hotel, and the clients booked in the hotel. The system enables the hotel manager to manage the information about the hotel, the room of the hotel; to view some kind of statistical report such as: room statistic, hotel statistic, client statistic, service statistic, and revenue statistic. The system enables the system administrator to manage an account for an user of the system when required. The system enables the hotel seller to book rooms and cancel a booking for a remote client via the telephone. The system enables the hotel receptionist to book rooms, cancel a booking, check-in, check-out and process the payment for an onsite client at the reception desk. Once a payment is processed, a bill is created with the information about the client, the booked rooms, and the service that the client used during the rest time in the hotel.

Step 2+3: extract nouns and classify them

  • System: an abstract noun –> reject.
  • Information: a common noun –> reject.
  • Room: need to be managed –> a class: Room
  • Hotel: need to be managed –> a class: Hotel
  • Client: need to be managed –> a class: Client
  • Manager: this is a kind of member in the system (also called account, user) –> a class: User
  • Telephone: out of the scope of the system –> reject
  • Seller: a kind of User
  • Desk: out of the scope of the system –> reject
  • Receptionist: a kind of User
  • Bill: need to be managed –> a class: Bill
  • Service: need to be managed –> a class: Service
  • Statistic: room statistic –> RoomStat; client statistic –> ClientStat; service statistic –> ServiceStat; hotel statistic –> HotelStat; income or revenue statistic –> IncomeStat.

So we obtain the initial classes: Room, Hotel, Client, User, Bill, Service and statistical classes: RoomStat, HotelStat, ClientStat, ServiceStat, IncomeStat.

Step 4+5: quantity and object relationships among classes

Quan hệ giữa các lớp thực thể được xác định như sau:

  • A Hotel may have many Rooms, a Room belongs only to a Hotel. So, Hotel – Room is 1-n.
  • A Client may book many Rooms, a Room may be booked by many Clients at different times: so Client – Room is n-n. So we could propose a class between them: Booking.
  • A Client may have many Booking (in different times). A Room may also be booked in many Booking (in different times). Moreover, in a Booking, the client may book many rooms (for group clients). So, Booking – Room is still n-n. WE need a more class between them: BookedRoom. A Boooking and Room determine an unique BookedRoom. This association relationship determines also some information: check-in date, check-out date, booked price.
  • A Booking may be paid in several times. Each time, there has to be a bill. So, Booking – Bill is 1-n.
  • A receptionist may create many Bills for many Bookings. So, User – Bill is also 1-n.
  • A Service may be used by many Clients, in many BookedRooms. However, a Service is paid only once in a BookedRoom. A BookedRoom may use many Services: The relationship BookedRoom – Service is n-n. So we create a class UsedService between BookedRoom and Service.
  • In the case of statistical classes, they reuse some attributes of the corresponding entity class. So we could consider that they inherit from the corresponding entity class: HotelStat inherits from Hotel; RoomStat inherits from Room; ServiceStat inherits from Service; ClientStat inherits from Client.
  • As IncomeStat doesn’t reuse any attribute of other classes, it depends only on the Bill.