Design a Real-Time Wildlife Sightings Reporting App Using OOD Principles

Overview

The design of a Real-Time Wildlife Sightings Reporting App follows the Object-Oriented Design (OOD) principles, ensuring modularity, reusability, and maintainability. The app enables users to report wildlife sightings in real time, providing an interactive map, wildlife data, and notifications about local wildlife events. The app is useful for wildlife enthusiasts, researchers, conservationists, and the general public.

Key Features

1. Real-Time Sightings Reporting

2. Interactive Wildlife Map

3. User Profiles

4. Search and Filter Sightings

5. Wildlife Database Integration

6. Notification System

7. Moderation and Reporting Tools

8. Location-based Services

OOD Concepts Applied

1. Class Design

The system can be broken down into several classes that represent different objects in the application. Here are some key classes:

• WildlifeSighting

  • Represents a single wildlife sighting event.

  • Attributes: sightingID, userID, wildlifeType, location, timestamp, image, description, status.

  • Methods: createSighting(), updateSighting(), getSightingDetails().

• User

  • Represents the user interacting with the app.

  • Attributes: userID, username, email, password, profilePicture, reportCount.

  • Methods: createProfile(), viewSightings(), reportSighting(), updateProfile().

• WildlifeDatabase

  • Stores and manages the wildlife species information.

  • Attributes: speciesID, speciesName, scientificName, description, habitat, conservationStatus.

  • Methods: getWildlifeInfo(), searchWildlife(), updateWildlifeInfo().

• Map

  • Displays sightings on a map based on location.

  • Attributes: mapID, mapData.

  • Methods: renderMap(), filterSightings(), showSightingDetails().

• Notification

  • Sends real-time notifications to users based on sightings and events.

  • Attributes: notificationID, userID, message, timestamp.

  • Methods: sendNotification(), getNotificationDetails().

• Admin

  • Manages the app’s back-end functions such as moderating reports, validating sightings, and ensuring data integrity.

  • Attributes: adminID, username, email, permissions.

  • Methods: moderateSighting(), approveSighting(), banUser().

2. Inheritance

Inheritance can be used to build specialized versions of certain objects or entities in the app. For example:

• AnimalSighting (inherits from WildlifeSighting)

  • Represents specific sightings of animals, with additional attributes like animalBehavior, speciesGroup.

• PlantSighting (inherits from WildlifeSighting)

  • Represents plant sightings with unique attributes such as growthStage, flowerColor.

• AdminUser (inherits from User)

  • Represents an administrator with additional permissions.

3. Encapsulation

The design encapsulates the internal details of each class, ensuring that only the necessary attributes and methods are exposed to other objects. This enhances security and flexibility:

• The WildlifeSighting class hides the implementation of sighting validation and stores user reports in an abstract manner.

• The User class encapsulates sensitive information like the password and user history, offering methods like updateProfile() or viewSightings() for interaction.

4. Polymorphism

Polymorphism allows the system to handle different types of sighting reports through a unified interface, making it more extensible:

• The method createSighting() can behave differently depending on whether the sighting is of an animal or a plant. This can be done by overriding the method in specialized classes like AnimalSighting or PlantSighting.

• The sendNotification() method can send notifications in multiple formats (e.g., push, email, SMS) depending on user preferences.

5. Composition

Certain objects can be composed of other objects to represent complex entities. For example:

• The Map class can compose the WildlifeSighting class to display multiple sightings on the map at once.

• The User class can have a collection of WildlifeSighting objects that represent all the sightings reported by a specific user.

Sequence Diagram (Core Workflow)

1. User Reports a Sighting

   • A user opens the app and reports a wildlife sighting.

   • The app prompts the user for details such as the type of wildlife, location, time, and image.

   • The user’s input is used to create a WildlifeSighting object, which is saved to the system.

2. Map Updates with New Sightings

   • The app fetches sightings from the database and updates the map with new sightings.

   • The Map object calls the renderMap() method to display the sightings on the map interface.

3. User Receives Notifications

   • Once a new sighting is reported nearby, a Notification object is triggered.

   • The app sends real-time notifications to users who have opted in for such updates.

4. Moderation by Admin

   • Admins receive flagged reports of incorrect or inappropriate sightings.

   • The admin can either approve or reject sightings based on the review.

Use Case: Reporting a Sighting

Actors:

• User

• App (System)

Steps:

1. User opens the app.

2. User clicks the “Report a Sighting” button.

3. User enters the details of the sighting, such as type of wildlife, location (either manually or using GPS), date and time, description, and image.

4. User submits the report.

5. The app creates a new WildlifeSighting object.

6. The WildlifeSighting is stored in the database and associated with the user.

7. The map is updated, and nearby users are notified of the new sighting.

User Interaction with the System

• Login/Registration: Users can log in using social media, email, or through a guest account.

• Profile Creation/Editing: Users can edit their profile, including their wildlife interests, sighting preferences, and notification settings.

• Sighting Viewing: Users can view and filter past sightings based on location, time, and type of wildlife.

Admin Interaction with the System

• Moderate Sightings: Admins can verify sightings reported by users, ensuring accuracy and preventing spam or inappropriate content.

• User Management: Admins can manage users, including banning, updating privileges, or reviewing reported sightings.

Design Patterns

• Observer Pattern: Used for notifications. The app acts as a subject, and users are observers. When a new sighting is added, all subscribed users receive a notification.

• Singleton Pattern: The WildlifeDatabase class could be a Singleton to ensure there is only one instance of the database manager throughout the app.

• Factory Pattern: Used to create WildlifeSighting objects based on the type of wildlife being reported (e.g., animal, plant).

Conclusion

By using object-oriented design principles, the Real-Time Wildlife Sightings Reporting App ensures maintainability and scalability. The app is built with clear responsibilities for each class, easy-to-extend functionality, and efficient user interaction. Each component is designed with the future in mind, allowing for easy updates, integration of new features, and expansion of the wildlife database.