Lecture_Notes/imperfect_notes/pragy/LLD 5.md

LLD 5

• some have still not submitted the BookMyShow diagram
• So postpone it to next class
• For now, BookMyShow

Hotel Management System

• support booking different room types
  • suite
  • king size
  • delux
  • Entities:
    • booking
    • room
  • Relations:
    • booking-room
    • room-subclass
• search and book rooms for a guest
  • Entities:
    • search interface
    • guest
  • who else can use search? We can not only book rooms online. People also visit the frontdesk and book rooms
  • Relationships
    • guest uses search interface
    • Receptionist
• Who booked a particular room, say 1004
  • Relation:
    • room booking has multiple guests
    • one guest can only bok one room
• cancel a booking
  • behavior. no new entity / relation here
• track housekeeping tasks
  • Entities:
    • housekeeing task
    • housekeeper
  • Relation:
    • housekeeper can perform * tasks
• customer can ask for room service
  • room service is different from house keeping
  • don't have to pay for housekeeping
  • have to pay for roomservice
  • order food/drinks in roomservice
  • Entities:
    • room service
• payment should be supported through various modes
  • card
  • cash

---

How should we start?

• from building
• from brand

class HotelBranch:
    name: str
    
    def get_number_of_centers():
    def add_location():
    
class HotelCenter: # actual physical building
    location: Address
    name: str
    
    def get_rooms():

HotelBrand 1 <>----- * HotelBranch

class Room:
    room_number: str
    room_type: str  # or subclass
    price: float
    is_booked: bool
    
    def check_in():
    def check_out():

HotelCenter 1 <>----- * Room

---

How will you get into your room? Do you need something? Each room can have multiple keys, right?

class RoomKey:
    id: str
    barcode: str
    issued_at_date: Date
    is_active: bool

Room 1 <>----- * Key

---

Humans

• guest
• receptionist
• housekeeper
• manager

class Person:
    name: str
    phone_number: str
    email_id: str

class Guest(Person):
    def create_booking():

class Receptionist(Person):
    def create_booking():
    
class Housekeeper(Person): # or servant. Or differnt subclasses of servant - cleaner / food server / masseur
    def add_service_charge(): # for services they offer
    # no def create_booking()

Person <--- ext --- Guest Person <--- ext --- Receptionist Person <--- ext --- Housekeeper

---

How do you track / manage these people? Account

class Account:
    name: str
    email: str
    password: str

Person 1 <>------ 1 Account

---

How do you track of your sales? Booking

What is it that you book? Brand/Hotel/Room? Room

class Booking:
    booking_number: str
    start_time: DateTime
    end_time: DateTime
    status: successfull / failed
    
    def modify():
    def cancel():

Can there be multiple bookings for a particular room?

• Yes, for different times. All bookings can exist simultaneously

Room 1 ---- * Booking

• Composition or Association?
• If room goes bad - leaking / haunted / something not working
• Would you cancel my booking? No - reassign to a room of the same type
• Association Room ---> Booking

Booking * ------> 1 Guest

Does not need to be composition, because room can be booked for a friend. Could be though depending on the case

---

What does a housekeeper do?

• various housekeeping tasks

class HouseKeepingTask:  # or record
    description: str
    start_time: DateTime
    duration: Time 

HouseKeeper 1 -----> * HouseKeepingTask

Not a composition

HouseKeepingTask * <------ Room Same room could have multiple tasks that were/need to be done

What if room is destroyed? Should destroy previous tasks?

• no
• but what about foriegn keys?
• keep a note in room saying invalid or something
• depends on requirements
• We will discuss DB schema design later in LLD

---

RoomService (not the same as housekeeping)

class FoodService:
    
class MassageService:

HouseKeeper 1 ------- * Service

---

Now, each service will need some payment. Invoice

class InvoiceItem:
    amount: float
    time: DateTime

InvoiceItem 1 ------- 1 Service Each instance of service associated with each instance of invoiceitem Or we could make Service objects static Then, Invoice * ------ 1 Service

InvoiceItem * ------ RoomBooking Same room can request multiple services

---

All invoiceitems associated with an invoice

class Invoice:
    

Do you always charge money all the time? No. at the end RoomBooking 1 -------> 1 Invoice

InvoiceItem * ------<> 1 Invoice

---

Searching

<<interface>> Search:
    search_by_room_type()
    search_by_floor()

have catalogues of rooms and mapping that we need Who can use this? Receptionist

Why is search an interface? Because search can be done on various things - users, rooms, tasks .. So, the common functionality of search is an interface. Then there are several modules that implement that interface

---

going forward, we will look at DB schema design for things like this

---