Design a Public Transport Lost Item Reporting App with OOD Principles

Public Transport Lost Item Reporting App Design with Object-Oriented Design (OOD) Principles

Designing a Public Transport Lost Item Reporting App using Object-Oriented Design (OOD) principles involves defining key classes, relationships, and responsibilities in the system. Here is a breakdown of the components, interactions, and structure of the app.

Key Requirements:

1. Lost Item Report Submission: Users should be able to report lost items via the app.

2. Item Search and Status Updates: Users should be able to track the status of lost items (e.g., found, in transit, unclaimed).

3. Notifications: Users should receive notifications when their lost item is found.

4. Item Retrieval: Users can view where and how to collect their found items.

5. Admin Dashboard: Administrators should have access to a dashboard for managing lost items, verifying reports, and tracking the recovery process.

1. Identifying the Core Classes:

User

• Represents an individual who uses the app to report or claim a lost item.

• Attributes:

  • user_id: Unique identifier for the user.

  • name: User’s name.

  • email: User’s email address.

  • phone_number: User’s phone number.

  • lost_items: A list of lost items reported by the user.

• Methods:

  • report_lost_item(): Allows a user to report a lost item.

  • track_lost_item(): Lets users track the status of their reported lost item.

  • receive_notification(): Receives notifications about lost item status.

LostItem

• Represents an item reported as lost.

• Attributes:

  • item_id: Unique identifier for the lost item.

  • item_name: Name or description of the item (e.g., phone, wallet).

  • date_reported: Date when the item was reported lost.

  • status: Current status of the item (e.g., Reported, Found, Unclaimed).

  • location: The last known location where the item was lost.

  • user: The user who reported the item.

• Methods:

  • update_status(): Updates the status of the lost item (e.g., from Reported to Found).

  • set_location(): Sets or updates the location where the item was lost.

Admin

• Represents an administrator who oversees the management of lost items.

• Attributes:

  • admin_id: Unique identifier for the admin.

  • name: Admin’s name.

  • email: Admin’s email address.

• Methods:

  • approve_item_found(): Confirms that a lost item has been found.

  • notify_user(): Sends notifications to users about the status of their lost item.

  • manage_reports(): Views, approves, and updates lost item reports.

Notification

• Responsible for sending alerts and updates to users.

• Attributes:

  • notification_id: Unique identifier for the notification.

  • user: The user receiving the notification.

  • message: The content of the notification.

  • status: The notification status (e.g., Sent, Read).

• Methods:

  • send_notification(): Sends a notification to a user.

  • mark_as_read(): Marks the notification as read.

TransportService

• Represents the public transport system (e.g., bus or train services).

• Attributes:

  • service_id: Unique identifier for the transport service.

  • route: The specific route the transport takes.

  • lost_item_records: List of all lost item reports related to that transport service.

• Methods:

  • record_lost_item(): Logs a lost item in the service’s records.

  • search_lost_items(): Allows admins to search lost items based on criteria (e.g., route, location).

2. Class Relationships:

• A User can report multiple LostItems.

• Each LostItem is reported by one User, and can be found or unclaimed.

• Admin has access to all LostItems and can manage notifications and reports.

• Notification is linked to a User and provides status updates.

• A TransportService manages LostItems related to specific routes.

3. Key Use Cases:

Use Case 1: Reporting a Lost Item

• Actors: User

• Pre-condition: The user has lost an item on a public transport system.

• Flow:

  1. The user opens the app and logs in.

  2. The user selects the option to report a lost item.

  3. The user fills in details about the item (e.g., name, description, route, etc.).

  4. The app creates a new LostItem object and associates it with the user.

  5. The user submits the report, and the item’s status is set to Reported.

  6. The app sends a confirmation notification to the user.

Use Case 2: Tracking a Lost Item

• Actors: User

• Pre-condition: The user has reported an item as lost.

• Flow:

  1. The user logs into the app and navigates to their lost items.

  2. The user selects the item they wish to track.

  3. The app displays the current status of the item (e.g., Found, In Transit, Unclaimed).

  4. If the status changes (e.g., item found), the user is notified.

Use Case 3: Admin Managing Lost Items

• Actors: Admin

• Pre-condition: A lost item has been reported.

• Flow:

  1. The admin logs into the dashboard.

  2. The admin views a list of reported lost items.

  3. The admin verifies the item status and updates it as Found if the item has been recovered.

  4. The admin can send a notification to the user about the item’s found status.

4. Design Considerations:

• Extensibility: New features, such as integrating with different transport services or adding advanced tracking (e.g., GPS), can be easily added by extending existing classes.

• Security: Sensitive user information (e.g., phone numbers) should be stored securely. Access control should be implemented to ensure only admins can approve found items or manage sensitive data.

• Scalability: The system should be able to handle a growing number of users, lost items, and transport services.

• Notifications: The system should include a robust notification mechanism (e.g., push notifications, email).

5. Sample Interaction Diagram:

1. User Reports a Lost Item:

   • User → LostItem (create report)

   • LostItem → TransportService (record report)

   • Notification → User (confirm report)

2. Admin Approves Item as Found:

   • Admin → LostItem (update status)

   • Admin → Notification (send notification)

   • Notification → User (notify item found)

3. User Tracks Lost Item:

   • User → LostItem (view status)

   • LostItem → TransportService (retrieve item status)

   • Notification → User (send status update)

Conclusion:

The Public Transport Lost Item Reporting App designed with Object-Oriented Design (OOD) principles emphasizes modularity, reusability, and clear responsibilities for each class. This ensures the system is efficient, scalable, and easy to maintain. The main focus is on seamless user interaction, proper tracking of lost items, and effective communication between users and transport services.