Designing a Campus Facility Booking System with Object-Oriented Design

A campus facility booking system allows students, faculty, and staff to book various campus facilities (such as lecture halls, meeting rooms, gymnasiums, or sports fields) for events or activities. The system needs to provide a seamless way to view availability, make bookings, and manage existing reservations. Using object-oriented design (OOD) principles helps in organizing the system in a modular, maintainable, and scalable way. Let’s break down how to design such a system using OOD concepts.

1. System Overview

The campus facility booking system should provide functionalities to:

• Browse available facilities.

• Make, modify, and cancel bookings.

• Manage bookings (administrative level).

• View booking history and upcoming bookings.

• Notify users of booking confirmations and changes.

2. Key Classes and Objects

In Object-Oriented Design, we define entities as classes that model real-world objects. Each class will have attributes and methods associated with it.

User Class

Users in this system could be students, faculty, or administrative staff. A generic user class could be the superclass, with specific subclasses for different types of users.

• Attributes:

  • user_id: Unique identifier.

  • name: Name of the user.

  • email: Contact email.

  • user_type: Type of user (e.g., student, faculty, staff).

• Methods:

  • register(): Method to register a new user.

  • login(): Method to log into the system.

  • view_bookings(): Allows the user to view their current bookings.

Facility Class

A facility is any bookable resource like a room, gym, or conference hall.

• Attributes:

  • facility_id: Unique identifier.

  • name: Name of the facility (e.g., “Main Lecture Hall”).

  • capacity: Maximum number of people the facility can accommodate.

  • location: The physical location of the facility on campus.

  • type: Type of facility (e.g., sports hall, lecture room).

• Methods:

  • check_availability(date_time): Checks if the facility is available at a given time.

  • reserve(): Reserves the facility for the user.

  • cancel_reservation(): Cancels a previously made reservation.

Booking Class

A booking represents a reservation made by a user for a facility.

• Attributes:

  • booking_id: Unique identifier for the booking.

  • user_id: The ID of the user who made the booking.

  • facility_id: The ID of the facility being booked.

  • start_time: The start time of the booking.

  • end_time: The end time of the booking.

  • status: The status of the booking (e.g., confirmed, pending, canceled).

• Methods:

  • create_booking(): Create a new booking for a facility.

  • modify_booking(): Modify an existing booking.

  • cancel_booking(): Cancel the booking.

  • view_booking_details(): View details of the booking.

Admin Class

The admin class manages the overall system, including user management, facility management, and booking oversight.

• Attributes:

  • admin_id: Unique identifier for the administrator.

  • name: Name of the admin.

  • email: Admin’s email.

• Methods:

  • add_facility(): Adds a new facility to the system.

  • remove_facility(): Removes a facility from the system.

  • view_all_bookings(): Views all bookings across the system.

  • manage_user_account(): Manages user accounts (approve, deactivate, etc.).

Calendar Class

The calendar class helps manage the availability of the facilities over time.

• Attributes:

  • facility_id: The facility for which this calendar is being maintained.

  • date: The date of the booking.

  • available_timeslots: A list of available time slots for a given date.

• Methods:

  • get_available_times(date): Retrieves available times for a given date.

  • update_availability(): Updates the availability of a facility based on a new booking or cancellation.

3. Relationships Between Classes

• User-Booking Relationship: One user can have multiple bookings, but each booking is linked to only one user.

• Booking-Facility Relationship: One booking corresponds to a single facility.

• Admin-User/Facility Relationship: The admin manages both user accounts and facilities.

• Booking-Calendar Relationship: Each booking updates the calendar for a specific facility.

4. Key Design Considerations

• Encapsulation: Each class should manage its own state. For example, the Facility class should only expose methods like reserve() and cancel_reservation() to interact with bookings, not its internal state directly.

• Inheritance: The User class could be generalized for all user types (students, faculty, staff), and specific behaviors could be added to subclasses (e.g., faculty can reserve specific kinds of rooms).

• Polymorphism: A User can have different behaviors based on their role (e.g., booking a facility). A subclass can override a method to provide role-specific behavior.

• Composition: A Booking object can include references to both a User and a Facility object.

5. UML Diagram (Unified Modeling Language)

For a clearer overview, a class diagram would depict the classes, their attributes, methods, and the relationships between them. This visual representation would show the inheritance between User and its subclasses, the aggregation of Booking and Facility, and the admin’s management capabilities.

6. Database Design

A relational database can be used to store the information of users, facilities, bookings, and availability. For example:

• Users Table: stores information on students, faculty, and staff.

• Facilities Table: stores information about all available facilities.

• Bookings Table: stores the booking details, including references to the user and facility tables.

• Calendar Table: stores availability information for each facility on each date.

7. Workflow of the System

Booking Process:

1. Login: The user logs into the system.

2. Browse Facilities: The user browses available facilities.

3. Select Date and Time: The user selects a facility and a time slot.

4. Check Availability: The system checks if the facility is available.

5. Make Reservation: The system confirms the reservation and updates the calendar and booking tables.

6. Confirmation Notification: The user receives a confirmation email or notification.

Admin Process:

1. Manage Users: Admin can view or deactivate user accounts.

2. Manage Facilities: Admin can add, remove, or edit facilities.

3. Manage Bookings: Admin can view all bookings and resolve any issues.

8. Future Considerations

• Mobile App Integration: The system could be expanded to include mobile applications for easier facility access.

• Real-time Notifications: Push notifications for booking updates, reminders, and cancellations.

• Advanced Search: Search functionality to filter facilities by type, capacity, or location.

Conclusion

By following object-oriented design principles, this campus facility booking system can be structured to be flexible, scalable, and easy to maintain. The classes interact with each other to simulate real-world processes and provide an efficient booking experience for users and administrators.