Software Design

How is the software designed? Is the architecture appropriate? Do the project follow any software design principle taught in the class?

The software follows a multi-tier architecture with three clearly separated layers. The mobile frontend (mobile-app) handles user interactions such as vehicle search, manual check-in, parking history, and notifications. The backend, built using Node.js and Express, processes business logic and exposes a REST API. A PostgreSQL database persists application data through versioned migration files (001_init.sql, 002_license_plate_detection.sql, 003_security_flags.sql), ensuring consistent schema evolution. In addition, a separate Python-based AI service is responsible for license plate detection using EasyOCR and OpenCV. This service communicates with the backend via a single HTTP endpoint (POST /api/detection/record). This design ensures loose coupling, allowing the detection pipeline to be modified or replaced without impacting the Node.js application layer. The backend follows the Model-View-Controller (MVC) design pattern. Route files such as parkingRoutes.js, detectionRoutes.js, vehicleRoutes.js, and notificationRoutes.js handle incoming HTTP requests and delegate them to controllers. Controllers (detectionController.js, parkingController.js, notificationController.js) implement all business logic, while models (parking.js, vehicle.js, detection.js, notification.js, user.js) encapsulate database interactions. Controllers do not directly access the database, and models do not contain business logic, demonstrating a clear application of the separation of concerns principle. The project also implements the Observer design pattern as defined in class. In parking_observer.py, the ParkingSpot class acts as the Subject, maintaining a list of observers and notifying them whenever its state changes through methods such as mark_occupied() and mark_available(). Multiple observers respond independently, including DatabaseObserver (which persists changes), UserNotificationObserver (which sends notifications), and GarageDashboardObserver (which updates real-time occupancy displays). This structure reflects the classic Observer pattern, where a one-to-many dependency allows all observers to react to state changes without the subject needing to know their internal behavior. This demonstrates loose coupling and improves extensibility. Importantly, the system does not implement the Strategy pattern. The check-in logic is currently handled through a conditional (if/else) structure within recordPlateDetection in detectionController.js, rather than being abstracted into interchangeable strategy classes. This distinction ensures that the design description accurately reflects the implemented code.