Design a Campus Public Safety Alert System with Object-Oriented Design

Overview

The Campus Public Safety Alert System (CPSAS) is designed to notify students, faculty, and staff of safety-related events on a campus. These alerts can range from emergencies like fire alarms to security threats such as active shooter situations or natural disasters. The system will handle the creation, distribution, and management of alerts across various channels (email, SMS, app notifications). Object-Oriented Design (OOD) principles will guide the development of this system, ensuring a scalable, modular, and maintainable solution.

Key Classes and Concepts

Here’s how the Campus Public Safety Alert System can be broken down using OOD principles:

1. Alert Class

• Attributes:

  • alert_id (int): Unique identifier for the alert.

  • alert_type (string): Type of alert (e.g., fire, medical emergency, security threat).

  • message (string): The content of the alert.

  • severity (enum): Severity of the alert (Low, Medium, High).

  • time_created (datetime): When the alert was created.

  • location (string): Location where the incident occurred.

• Methods:

  • generate_alert(): Method to create an alert.

  • update_alert(): Update the alert message or status.

  • delete_alert(): Delete the alert from the system.

  • notify_users(): Sends alert notifications to the users.

2. User Class

• Attributes:

  • user_id (int): Unique identifier for the user.

  • name (string): Name of the user.

  • email (string): User’s email address.

  • phone_number (string): User’s phone number.

  • notification_preference (enum): Preferred method of notification (e.g., SMS, Email, App).

  • role (enum): Role of the user (e.g., student, faculty, staff).

• Methods:

  • update_preferences(): Allows the user to change notification preferences.

  • receive_alert(): Receives an alert notification via the preferred method.

  • register_for_alerts(): Registers the user for alert notifications.

3. Notification Class

• Attributes:

  • notification_id (int): Unique identifier for the notification.

  • message (string): The content of the notification.

  • recipient (User): The recipient of the notification.

  • timestamp (datetime): When the notification was sent.

• Methods:

  • send_notification(): Sends a notification to the user via their preferred method.

  • schedule_notification(): Schedules a notification for a specific time.

4. AlertChannel Class (Abstract Base Class)

• Attributes:

  • channel_name (string): Name of the communication channel (e.g., SMS, Email, App).

• Methods:

  • send_alert(alert: Alert, user: User): Sends the alert message to the user via the channel.

• Subclasses:

  • EmailChannel: Sends alerts via email.

  • SMSChannel: Sends alerts via SMS.

  • AppNotificationChannel: Sends alerts via app push notifications.

5. AlertManager Class

• Attributes:

  • alerts (List[Alert]): List of active alerts.

  • users (List[User]): List of users registered for alerts.

• Methods:

  • create_alert(alert_type: string, message: string, severity: string, location: string): Creates a new alert.

  • update_alert(alert_id: int, message: string, severity: string): Updates an existing alert.

  • delete_alert(alert_id: int): Deletes an alert from the system.

  • distribute_alert(alert: Alert): Distributes an alert to all registered users based on their preferences.

6. RoleManager Class

• Attributes:

  • roles (List[Role]): List of roles in the system (e.g., student, faculty, staff).

• Methods:

  • assign_role(user: User, role: Role): Assigns a role to a user.

  • get_role_permissions(role: Role): Retrieves the permissions associated with a specific role.

7. Role Class

• Attributes:

  • role_name (string): Name of the role (e.g., student, faculty).

  • permissions (List[string]): List of permissions for the role (e.g., view_alerts, issue_alerts).

• Methods:

  • add_permission(permission: string): Adds a new permission to the role.

  • remove_permission(permission: string): Removes a permission from the role.

Relationships Between Classes

• The AlertManager is responsible for creating and managing alerts and distributing them to all registered users through their preferred notification channels.

• The User class stores user information and preferences, including which notification channels they prefer (Email, SMS, App) and their roles (student, faculty, staff).

• The Notification class handles the sending of notifications to users. It works with the AlertChannel subclasses to communicate via different platforms.

• The RoleManager manages user roles and permissions. For example, a faculty member can issue alerts, whereas a student can only receive them.

• The Alert class holds the details of each alert, and the AlertChannel subclasses are responsible for sending them out through specific channels.

Example Workflow

1. Alert Creation:

   • The AlertManager receives a new alert creation request (e.g., fire in Building A).

   • It creates an Alert instance, assigns it a unique alert_id, and stores it in the alerts list.

2. User Registration:

   • A user (e.g., John Doe) registers for alerts and sets their preferences to receive SMS notifications.

   • The User instance is created, and the user is added to the system.

3. Alert Distribution:

   • The AlertManager calls distribute_alert() to notify all users of the alert.

   • The system checks each user’s notification preferences and calls the appropriate method on the AlertChannel subclasses to send the alert.

     • If John Doe prefers SMS, the system will use the SMSChannel to send the alert.

4. Alert Notification:

   • John Doe receives an SMS on his phone with the fire alert message.

5. Alert Update:

   • If the situation changes (e.g., fire extinguished), the AlertManager updates the alert, and the system re-notifies users as needed.

Key Considerations

• Scalability: The system should handle thousands of users and alerts. Using object-oriented principles ensures that new alert types and notification channels can be easily added.

• Extensibility: If the university wants to add a new notification channel (e.g., social media), it can easily be done by extending the AlertChannel class.

• Modularity: Each class and method has a single responsibility, which makes the system easier to maintain and test.

Conclusion

The Campus Public Safety Alert System provides a modular, extensible, and scalable design that can be easily adapted to changing needs. The use of Object-Oriented Design ensures that new features and channels can be added over time, and the system remains easy to maintain.