System description in UML

Steps to build the general use case diagram:

  • Step 1: Propose actors. For each user, we can propose as an actor of the system. If several users have some common features, we could propose an abstract actor for all, and then each corresponding actor inherit from the abstract actor. WE need also to consider all indirect users who could kick off some function of the system.
  • Step 2: Propose use cases. For each function of an actor, propose it as an use case.
  • Step 3: Refine the use cases. If there are at least two similar use cases, they should be regrouped into one. If the regroup makes the miss understand about the number of related actors, we could use an abstract use case as the common parent of them.

Steps to build the detailed use case diagram for each function:

  • Step 1: Extract the use case part of the function from the general use case.
  • Step 2: Propose sub use cases: an (or several) interface which has interaction with actor could be a sub use case.
  • Step 3: Determine the relationship between each sub use case to the main use case: generalization, include, or extend.
  • Step 4: Regroup some sub similar use cases into a more general use case if it is necessary.

Build the general use case diagram

Step 1: actors

  • Direct actors: manager, administrator (admin), seller, receptionist. They are the same type as employee of the hotel (Employee – abstract actor).
  • Indirect actor: client. It could kick off some functions: booking, checkin, checkout, payment.

Step 2 and 3: use case

  • The receptionist could use the following functions:
    • Book room for on site clients -> book on site,
    • Cancel a booking for on site clients -> cancel on site,
    • Check in for clients -> checkin,
    • Check out and process the payment for clients -> checkout.
  • Seller could use the following functions:
    • Book room for remote clients via the telephone -> book via phone,
    • Cancel a booking for remote clients via the telephone -> cancel via phone.
  • Manager could use the following functions:
    • Manage hotel information -> manage hotel
    • Manage room information -> manage room
    • View statistical reports -> view report
  • System administrator could use following functions:
    • Manage user account by their demand -> manage account.
  • Book a room is the same if it is on site (with the receptionist) or remote (with the seller). So we could propose an abstract use case: book room
  • The same for cancel a booking, we propose an abstract use case: cancel booking.

The obtained general use case diagram is:

The use case are described as follow:

  • Manage hotel: this use case enables the manager to manage the information about the hotel.
  • Manage room: this use case enables the manager to manage the information about the rooms.
  • View report: this use case enables the manager to view statistical report about hotel, room, client, service or revenue of the hotel.
  • Manage account: this use case enables the administrator to manage the user account by the demand of related user.
  • Book a room: this use case enables the seller or receptionist to book a room for a client.
  • Book on site: this use case enables the receptionist to book a room for an on site client.
  • Book via phone: this use case enables the seller to book a room for a remote client via the telephone.
  • Cancel a booking: this use case enables the seller or receptionist to cancel a booking for a client.
  • Cancel on site: this use case enables the receptionist to cancel a booking for an on site client
  • Cancel via phone: this use case enables the seller to cancel a booking for a remote client via the telephone.
  • Checkin: this use case enables the receptionist to check in for a client at the reception desk.
  • Checkout: this use case enables the receptionist to check out and to process the payment of a client

Use case edit room (manage room)

Let’s review the description of this function: A manager logs in into the system -> The manager’s UI is appeared, it has the following options: manage the hotel information, manage the room information, and view the statistical reports -> The manager selects to manage room information -> The room information management UI is appeared with three options: add room, edit room, delete room -> The manager clicks on the edit function -> The search room UI is appeared with an input text to enter the keyword, and a search button -> The manager enters a keyword about the name of the room to edit and then, clicks on the search button -> A list of all rooms whose name contains the entered keyword is appeared, each row corresponds to a room with: id, name, type, price, description -> The manager clicks on the room to edit -> The edit room UI is appeared with the editable input texts which already contain the corresponding attribute values (except the id which is not editable) -> The manager modifies some attribute values and then, clicks on the save button -> The system announces a success alert and then, returns to the manager home UI.

So we need the interfaces with the related interactions: Login. Manage the room has three sub functions: add room, edit room, and delete room. Edit room has one more action: search room to edit. So we have the use case as follow:

Use case description:

  • Add room: this use case enables the manager to add a new room into the system
  • Edit room: this use case enables the manager to edit a room in the system
  • Delete room: this use case enables the manager to delete a room from the system.
  • Search room: this use case enables the manager to search a room (by id or by name) to edit or delete.

Use case book a room

Let’s review this function description: A client gets a call to the hotel to book a room -> A receptionist forwards the call to a seller -> The seller asks the client what period of time that the client want to stay in the hotel and selects the booking function in the seller home UI -> The available room search UI is appeared with two date inputs: the checkin and checkout date, a search button -> The seller enters the checkin/checkout date as the client’s desire and then, clicks on the search button -> A list of all available rooms in that period is listed in a table form, each row corresponds to a room with: id, name, type, price, description -> The seller informs to the client all the type of available room and asks the client to choose a room (or some rooms) -> The client informs their choice -> the seller click on a room which satisfies the client requirement -> The system changes to the client information UI with an input text and a search button -> The seller requires the client to provide his/her information about: id card number, name, address, phone number and then, enters the client name into the text and clicks on the search button -> A list of all clients whose name contains the entered keyword is appeared in a table form, each row corresponds to a client with: id card number, name, address, phone number, notes -> The seller clicks on the row which has the same information to the current client (If there is no row satisfies, it have to click on the add new client button to add new client) -> The system displays the confirmation UI with: client information, selected room information, the checkin/checkout date -> The seller confirms these information to the client and the client confirms that is OK -> The seller clicks on the confirm button -> The system announces a success alert and then, returns to the seller home UI -> The seller informs the success booking to the client and ends the call.

So, in order to book a room, the seller/receptionist have to: log in to the system, search the available rooms, search the client to check whether it exists in the system (add new client if it does not exist), and confirm the booking (this could be separated as a sub use case or integrated in the booking use case). So we have the use case as follow:

Use case description:

  • Search free room: this use case enables the seller/receptionist to search the available room to book for the client.
  • Search client: this use case enables the seller/receptionist to search information of client to book a room. The search could be based on the client name or phone number.
  • Add client: this use case enables the seller/receptionist to add a new client during book a room for the client.

Use case view the report of room by the revenue

 Let’s review the description of this function: A manager logs in into the system -> The manager’s UI is appeared, it has the following options: manage the hotel information, manage the room information, and view the statistical reports -> The manager selects to view the statistical reports -> The UI to config the report is appeared with two selection list. First, the object of the report, including: hotel, room, client, service, revenue. Second, the criteria of the report, including: by revenue, by time (if the object is the revenue), by filled rate (if the object is hotel or room) -> The manager selects the object is room, the criteria is by revenue -> The report UI is appeared with two input dates: the start and the end of the duration to count the report -> The manager enters these dates and clicks on the view button -> The report results are listed in a table form, ordered by the total revenue, each row corresponds to a room with: id, name, type, total of filled days, total of revenue -> The seller clicks on a row to view more detail -> The UI appeared with the selected room information and a list of booking related to the selected room, each row corresponds to a booking with (ordered by the time of checkin): client name, checkin, checkout, price, total income -> The seller clicks on the return button to return to the manager home UI.

So, in this use case, the manager have to log in, config the report(integrated into the view report), choose the statistic period (could be integrated into the view the main report), view the main report. And the manager may choose to view the detailed report of a room (optional). The obtained use case is follow:

Use case description:

  • View report: this use case enables the manager to view all kinds of report
  • View room report: this use case enables the manager to view the main report about room by their revenue.
  • view detail a room: this use case enables the manager to view the booking related to a room during the period of statistic.