Repository navigation
High Level Design
In accordance with Agile methodology, we avoid Big Design Up Front (BDUF). Our formal High-Level Design (HLD) and UML modeling for this sprint are strictly focused on our core, central feature: Epic 3 (Create and Manage Recreational Events).
UML Rationale: We chose to use standard UML Sequence and Deployment diagrams because they provide a rigorous, universally understood blueprint for our engineers. While our Context Diagram uses business-facing graphics, these UML diagrams specifically utilize strict notation to explicitly map out our Django Model-View-Template (MVT) architecture, API database queries, and AWS hosting environments prior to coding. This minimizes architectural rework during development.
This diagram outlines the physical tech stack and data flow for the NYC Active platform.
Maintainability Note: To adhere to the Single Source of Truth (SSOT) principle, the PlantUML source code for this diagram is maintained as Docs-as-Code in our main repository:
docs/deployment.puml.
Tech Stack Overview:
- Frontend/Backend Framework: Python / Django
- Hosting/Infrastructure: AWS (Amazon Web Services)
- Database: SQLite (Local Development) / PostgreSQL or MySQL (Production)
- Project Management & SCM: GitHub / ZenHub
This sequence diagram illustrates the chronological data flow and authorization checks between the Client, Django Server, and Database when an Event Organizer creates a new meetup.
Maintainability Note: To adhere to the Single Source of Truth (SSOT) principle, the PlantUML source code for this diagram is maintained as Docs-as-Code in our main repository:
docs/epic3-sequence.puml.
This sequence diagram illustrates the strict authorization logic used when an existing event is modified or canceled. It demonstrates how the Django backend verifies the user's identity against the event's owner_id before executing any database mutations.
(Insert your newly generated Manage Sequence Diagram image here)
Maintainability Note: The PlantUML source code for this diagram is maintained as Docs-as-Code in our main repository:
docs/epic3-manage-sequence.puml.
This epic enables authenticated organizers to generate public meetups tied to specific NYC park locations. It encompasses the entire lifecycle of an event including setting details, setting capacity limits, updating times, and canceling.
The event creation interface will include a Django template form with a park location dropdown (populated from Epic 2's dataset), date/time selectors, and an optional capacity limit.
Backend Django views will validate the submitted payload, verify the user's authentication status, and execute database writes using Django's ORM. A shared Event model will contain the organizer ID, park ID, activity type, schedule, and capacity limits.
An authenticated organizer submits the creation form. The Django view will first verify the user's session token. It will then validate that the park_id exists in the NYC Parks directory and that the scheduled time is in the future.
If validation passes, the server writes the Event record to the database using the Django ORM, automatically assigning the requesting user as the owner_id. If required fields are missing, the server rejects the request with a 400 Bad Request and no partial data is saved.
Only the owner_id or an authorized admin can mutate the event record. When an edit or cancel request hits the server, a Django decorator/middleware function checks the user's ID against the event's owner ID. Unauthorized attempts return a 403 Forbidden.
Canceling an event triggers a soft-delete or status change (e.g., status: cancelled), freezing the database from accepting any new RSVPs from Epic 4.
Epic 3 depends on Epic 1 for authenticated accounts and Epic 2 for verified park locations. Implementation will be validated against stories #22–#28, ensuring capacity limits cannot be reduced below active RSVPs and unauthorized edits are strictly blocked.