Design a Smart Public Park Facilities Availability App Using OOD Principles

Smart Public Park Facilities Availability App Design Using OOD Principles

Overview

The goal of this app is to enhance the user experience for visitors to public parks by providing real-time information on the availability of various park facilities. Using Object-Oriented Design (OOD) principles, we can structure the system in a modular and scalable way, focusing on the core functionality such as facility reservations, notifications, and park facility management.

Key Features of the App

• Facility Availability: View real-time availability of park facilities like sports fields, picnic areas, playgrounds, restrooms, etc.

• Facility Reservation: Reserve available facilities for a set period to avoid overcrowding or double booking.

• Notifications: Users will be notified when their reserved facility is about to be available or if there’s a change in availability.

• Rating & Feedback: Users can rate and provide feedback on park facilities, enhancing the user experience and guiding future improvements.

• Maps & Directions: Interactive maps showing the locations of park facilities, paths, and accessibility features.

Key Concepts Using OOD Principles

1. Identifying Classes

The first step in object-oriented design is to identify the classes that will represent the various entities in the app.

• User: Represents the park visitor using the app.

  • Attributes: userID, name, email, phoneNumber, reservationHistory[]

  • Methods: viewAvailableFacilities(), makeReservation(), provideFeedback(), cancelReservation()

• Facility: Represents each park facility such as a sports field, restroom, playground, etc.

  • Attributes: facilityID, name, type, location, availabilityStatus, capacity

  • Methods: updateAvailability(), getAvailability(), reserve(), getFacilityDetails()

• Reservation: Represents a reservation made by a user for a specific park facility.

  • Attributes: reservationID, userID, facilityID, startTime, endTime, status

  • Methods: modifyReservation(), cancelReservation(), checkAvailability()

• Notification: Manages notifications for users regarding their reservations or availability changes.

  • Attributes: notificationID, userID, message, timestamp, type

  • Methods: sendNotification(), displayNotification(), clearNotification()

• ParkMap: Provides the interactive map functionality of the park and its facilities.

  • Attributes: mapID, location, zoomLevel, facilityMarkers[]

  • Methods: zoomIn(), zoomOut(), displayMap(), showFacilityDetails()

• Feedback: Allows users to submit feedback or ratings for park facilities.

  • Attributes: feedbackID, userID, facilityID, rating, comments

  • Methods: submitFeedback(), viewFeedback(), getAverageRating()

2. Defining Relationships

The relationships between the different classes are fundamental for the structure and flow of the app.

• User & Reservation: A user can make multiple reservations, but each reservation belongs to one user.

• Facility & Reservation: A facility can have multiple reservations (over time), but each reservation is linked to a specific facility.

• User & Notification: A user can receive multiple notifications based on reservation status or facility availability.

• Facility & Feedback: Each facility can have multiple pieces of feedback, but feedback belongs to one facility.

• ParkMap & Facility: The ParkMap shows various facilities on the map and helps users locate them.

3. Defining System Behavior Using OOD Principles

Encapsulation

Encapsulation ensures that the details of the classes are hidden from other classes, and access is provided only through defined methods.

• User class encapsulates sensitive information like userID, email, etc., and provides methods like makeReservation() or provideFeedback() for interaction.

• Facility class encapsulates the facility’s state (whether it is available, reserved, etc.) and provides methods to modify this state.

Inheritance

Inheritance allows for code reuse. For example, you could have specialized types of facilities such as “SportsFacility” or “PicnicArea” inheriting from the general Facility class.

python
CopyEdit
class SportsFacility(Facility):
    def __init__(self, facilityID, location, capacity):
        super().__init__(facilityID, "SportsField", location, "Available", capacity)

class PicnicArea(Facility):
    def __init__(self, facilityID, location, capacity):
        super().__init__(facilityID, "Picnic Area", location, "Available", capacity)

Polymorphism

Polymorphism allows the system to treat different facility types in a unified way. For example, getAvailability() would behave differently based on the type of facility, yet the user doesn’t need to know which specific class is being used.

python
CopyEdit
def checkAvailability(facility: Facility):
    if isinstance(facility, SportsFacility):
        return facility.checkSportsAvailability()
    elif isinstance(facility, PicnicArea):
        return facility.checkPicnicAvailability()
    else:
        return facility.getAvailability()

Abstraction

Abstraction is used to simplify complex processes. For instance, users only interact with high-level methods like makeReservation() or viewAvailableFacilities(), while the system internally handles the details of reservation time slots, checking for availability, and managing user data.

4. Sequence Diagram for Facility Reservation

Here’s how the process might flow when a user reserves a facility:

1. User requests to view available facilities.

2. The system queries the Facility class to get the availability status.

3. User selects a facility and makes a reservation.

4. The system checks availability, and if available, creates a Reservation.

5. A Notification is generated and sent to the User about successful reservation.

6. The Facility‘s availability is updated.

7. The user receives a notification reminder before the reservation starts.

5. Database Design

To support the app, we can design a simple relational database with the following tables:

• Users: stores user details.

• Facilities: stores information about the facilities.

• Reservations: links users to their reserved facilities.

• Notifications: stores all notifications for users.

• Feedback: stores feedback from users about the facilities.

The relationships in the database:

• One-to-many between User and Reservation.

• One-to-many between Facility and Reservation.

• One-to-many between Facility and Feedback.

• One-to-many between User and Notification.

6. Use Case Scenarios

Here are some common use case scenarios for this app:

• User checks facility availability: The user opens the app, selects a park, and views available facilities. They can filter by type or availability time.

• User reserves a facility: The user selects a facility and time slot, and if available, reserves it. A confirmation is sent to the user, and the facility’s availability is updated.

• User cancels a reservation: The user can cancel an existing reservation, and the system will free up the facility for others to reserve.

• User receives notifications: The user gets reminders when their reservation is about to start or when the facility’s status changes.

• User leaves feedback: After using the facility, the user can rate it and leave comments.

Conclusion

By using OOD principles such as encapsulation, inheritance, polymorphism, and abstraction, the Smart Public Park Facilities Availability App is designed to be scalable, maintainable, and user-friendly. The app not only provides real-time updates about facility availability but also offers enhanced interactivity with features like reservations, notifications, and feedback. This approach ensures the app can easily accommodate future growth, such as adding new types of facilities or enhancing map functionality.