Group Project: Coworking Operations Portal

Context

A coworking space needs an internal portal for:

Login (members and staff).
Room reservations for meetings.
Maintenance incidents (report issues and track status).

The core can run in-memory and/or connect to a database via JDBC (optional). If you choose a DB (MySQL or PostgreSQL), you must download the JDBC driver and configure it.

*You may use Maven to include the driver dependency, but the access layer must still use plain JDBC *

Architecture

Use these packages/layers:

controller, view, domain, service, dao, config (and errors for custom exceptions if you like).
DAO: data access (in-memory and/or JDBC).
Service: business rules and validation.
Controller: orchestrates use cases and maps exceptions to response-like codes (HTTP-style).
View: minimal console/menu (no business rules).
Config: parameters and optional JDBC connection settings.

Minimum Scope

1) Authentication (basic login)

Login with email + password.
Roles: MEMBER, STAFF.
Rules:
- Empty credentials → validation error.
- Nonexistent user or wrong password → invalid credentials.
- After login, keep a simple in-memory “session context.”

2) Room reservations

Create reservation, get by ID, cancel, list by date range and/or room (combinable filters).
Rules: required fields; startTime < endTime; no overlaps for the same room; room may be out of service (not reservable).

3) Maintenance incidents

Report incident (title, description, optional room, category).
Change status: OPEN → IN_PROGRESS → RESOLVED/CLOSED.
List incidents filtered by status + category (combined).
Rules: required fields; valid status transitions.

If you enable the database, ensure at least one reservations query and one incidents query use JOINs.

Exceptions (must implement and map)

Create custom exceptions to simulate response codes:

Exception	Code
`BadRequestException`	400
`UnauthorizedException`	401
`NotFoundException`	404
`ConflictException`	409
`ServiceException`	500
`DataAccessException` (checked)	— (force `throws` in DAO)

Language requirements (exceptions):

≥1 try / catch / finally block (the finally must do something visible).
≥1 try-with-resources (read .properties / .csv, or execute a JDBC query).
≥2 methods with throws (throws DataAccessException or another checked type).
≥1 multi-catch (e.g., NumberFormatException | IllegalArgumentException).
≥1 wrapping: catch a technical error (I/O/SQL) and rethrow as ServiceException preserving the cause.

Database (optional, still JDBC)

If you use a DB, use JDBC directly (no ORM).
Drivers (choose one):
- MySQL: mysql-connector-j
- PostgreSQL: postgresql (JDBC driver)
You may use Maven to add the dependency (e.g., in pom.xml), but your code should use plain JDBC.
Provide at least one JOIN-based query for reservations and one for incidents when DB is enabled.

Use Cases (minimum)

Authentication

Log in
- Input: email, password.
- Output: success with active role, or 400/401.

Reservations

Create reservation
- Validate required fields and time range.
- Reject if duplicate ID, room out of service, or overlap.
Get reservation by ID
Cancel reservation
List reservations by room and/or date range.

Incidents

Report incident
Change status (valid transitions only)
List incidents by status + category.

Acceptance Criteria

Login

Given an email/password When input is missing or invalid Then respond with 400.
Given wrong credentials When I attempt to log in Then respond with 401.
Given valid credentials When I log in Then I get an active session with the correct role.

Reservations

Given an available room and valid data When I create a non-overlapping reservation Then it is stored and marked ACTIVE.
Given a time range that overlaps for the same room When I try to create the reservation Then respond with 409 (conflict).
Given a non-existent reservation ID When I fetch or cancel it Then respond with 404.

Incidents

Given valid required fields When I report an incident Then it starts as OPEN.
Given an invalid status transition When I try to change status Then respond with 409.
Given status + category filters When I list incidents Then only matching incidents are returned.

Exceptions & resources

Given reading a .properties or .csv (or running a JDBC query) When I use try-with-resources Then the resource closes properly.
Given DAO methods with throws DataAccessException When an I/O or SQL failure occurs Then the service wraps and rethrows ServiceException (500) with cause.
Given any controller flow When it ends (success or error) Then finally performs a visible action (e.g., “operation finished”).

JOINs (if DB is used)

Given minimal DB data When I list reservations or incidents with details Then queries use JOIN and display combined data (e.g., user, room, category/status).

UML & Documentation (required)

Use case diagram: login, reservations (create/get/cancel/list), incidents (report/change status/list).
Class diagram: entities, services, DAOs, controllers, exceptions (relationships & dependencies).
Data diagram (only if DB is used): minimal tables and relationships (your interpretation).
README:
- How to run (in-memory or with DB).
- If using DB: download the JDBC driver and show connection params (URL, user, password).
- Exception → response code mapping.
- JOIN queries (if applicable) and sample outputs.
- If using Maven, include the pom.xml snippet that adds the driver dependency.

Version Control & Traceability

Use Git + Git Flow (main, develop, feature/*).
Use Azure Boards for work items.

AntonyMRuiz/Coworking.md