Designing a Campus Lost and Found System Using OOD Principles

Designing a Campus Lost and Found System using Object-Oriented Design (OOD) principles aims to organize and simplify the management of lost and found items on a campus. The goal is to provide an easy-to-use platform for students, staff, and visitors to report and locate lost belongings. Below is a breakdown of how such a system can be designed using OOD principles.

1. System Overview

The Campus Lost and Found System (CLF) will allow users to report lost and found items, search for lost items, and claim them if found. The system will also provide functionalities for item categorization, verification, and notification. The key functionalities include:

• Reporting a Lost or Found Item: Users can report items they have lost or found with details such as description, location, and time.

• Searching for Items: Users can search through the database of found items by various filters such as item type, description, and location.

• Claiming Items: Users can claim an item they believe is theirs by providing identification details.

• Notifications: Notify users when their lost items are found.

• Administrator Role: Admins can validate and approve claimed items and manage the database.

2. Key Objects and Classes

a. Item Class

This class represents an item in the lost and found system. It encapsulates the details about each item.

python
CopyEdit
class Item:
    def __init__(self, id, item_type, description, location, found_date, status='lost'):
        self.id = id
        self.item_type = item_type
        self.description = description
        self.location = location
        self.found_date = found_date
        self.status = status  # 'lost' or 'found'
        self.owner = None
        self.claimed = False

Attributes:

• id: Unique identifier for each item.

• item_type: Type of item (e.g., wallet, phone, bag).

• description: Detailed description of the item.

• location: Where the item was lost or found.

• found_date: Date when the item was lost or found.

• status: Whether the item is lost or found.

• owner: The owner of the item if claimed.

• claimed: A flag indicating whether the item has been claimed.

b. User Class

The user class defines the system’s users, including students, staff, and administrators.

python
CopyEdit
class User:
    def __init__(self, user_id, name, email, role='student'):
        self.user_id = user_id
        self.name = name
        self.email = email
        self.role = role  # 'student', 'staff', 'admin'

Attributes:

• user_id: Unique identifier for each user.

• name: Name of the user.

• email: Email address for notifications.

• role: The user’s role (student, staff, admin).

c. LostAndFoundSystem Class

This is the main class that manages the overall functionality of the system, including adding and searching for items.

python
CopyEdit
class LostAndFoundSystem:
    def __init__(self):
        self.items = []  # List to hold all items
        self.users = []  # List to hold all users
        self.notifications = []  # List to store notifications

    def add_item(self, item):
        self.items.append(item)

    def search_items(self, search_params):
        results = []
        for item in self.items:
            if all(getattr(item, key) == value for key, value in search_params.items()):
                results.append(item)
        return results

    def report_item(self, item, user):
        if item.status == 'lost':
            item.status = 'found'
            item.owner = user
        self.add_item(item)

    def claim_item(self, item, user):
        if not item.claimed:
            item.claimed = True
            item.owner = user
            self.send_notification(user, f"Item {item.description} claimed successfully.")
        else:
            self.send_notification(user, f"Item {item.description} has already been claimed.")
    
    def send_notification(self, user, message):
        notification = {"user": user.email, "message": message}
        self.notifications.append(notification)

Attributes and Methods:

• items: Stores all the items in the system.

• users: List of users interacting with the system.

• notifications: Holds all the notification messages.

• add_item(): Adds a new item to the system.

• search_items(): Searches for items based on parameters like item type, location, etc.

• report_item(): Allows a user to report an item as found.

• claim_item(): Allows a user to claim an item.

• send_notification(): Sends notifications to users via email.

3. Use Cases

1. Reporting a Lost Item
   When a user reports a lost item, the system will create an item and store the information such as item type, description, location, and date.

2. Reporting a Found Item
   When a user finds an item, they can report it as “found”. The system will update the item’s status and store its details in the found items list.

3. Searching for Lost Items
   A user can search for lost items based on attributes such as item type or location. The system will display all the matching results.

4. Claiming a Found Item
   Users can claim an item they think belongs to them. The system will check if the item is unclaimed and allow the user to mark it as claimed, notifying both the user and the admin.

5. Admin Role
   Admins can review claimed items, verify user identities, and mark items as returned or unclaimed.

4. Design Principles in Use

• Encapsulation: Each class hides its internal details (attributes and methods) and only exposes necessary functionality.

• Abstraction: Complex interactions (e.g., searching for items, claiming items) are abstracted into high-level methods, simplifying the user interface.

• Inheritance: The User class can be extended to define more specific roles like Student, Staff, and Admin.

• Polymorphism: Methods like send_notification() can handle notifications for both lost and found items, abstracting the differences in message content.

5. Extensions and Improvements

• Geolocation Tracking: Add location-based features, allowing users to track the area where the item was lost or found.

• Item Verification: Implement a verification system where items with valuable information, such as serial numbers, can be matched against existing records.

• Rating System: Allow users to rate their interactions (e.g., how easy it was to claim an item or how satisfied they were with the system).

6. System Deployment

The Campus Lost and Found System can be deployed as a web application or mobile app. Here are the basic components of the system architecture:

• Frontend: The user interface where users can report, search, and claim items.

• Backend: A server that processes user requests, interacts with the database, and handles notifications.

• Database: A relational database to store user information and item data.

Conclusion

This Campus Lost and Found System efficiently applies OOD principles to create an organized, user-friendly, and scalable solution. Using these principles ensures that the system is flexible, maintainable, and capable of growing as the needs of the campus evolve.