Changes between Version 2 and Version 3 of P4


Ignore:
Timestamp:
01/03/26 22:09:33 (2 weeks ago)
Author:
193284
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • P4

    v2 v3  
    1 Phase P4 – First Application Prototype
     1= P4 – Prototype Implementation (REST API)
    22
    3 Description
    4 This phase presents a working prototype application that demonstrates
    5 how selected application scenarios from Phase P3 can be implemented
    6 using a real database and backend logic.
     3== Description
     4This phase focuses on the implementation of a functional backend prototype for the Wedding Planner system.
     5The prototype demonstrates the practical use of the database designed in previous phases through RESTful endpoints.
    76
    8 Technology
    9 - Programming language: Python
    10 - Framework: Flask
    11 - Database: SQLite
    12 - Execution environment: Local development (Windows)
     7The implementation validates the relational schema and business logic by exposing selected functionalities
     8via a Flask-based REST API connected to an SQLite database.
    139
    14 Implemented Scenarios
    15 The prototype implements a representative subset of the application
    16 scenarios defined in Phase P3:
     10== Technologies and Tools
    1711
    18 1. Listing weddings for a user
    19 2. Viewing events for a selected wedding
    20 3. Viewing guests for a wedding
    21 4. Attendance overview for an event
    22 5. RSVP overview for an event
    23 6. Venue availability check with conflict detection
     12The prototype is implemented using the following technologies:
    2413
    25 Venue Availability Logic
    26 The application implements business logic to detect overlapping
    27 venue bookings for a selected date and time interval.
     14Python 3.11
    2815
    29 If a conflict exists, the system returns:
    30 - available: false
    31 - list of conflicting bookings
     16Flask web framework
    3217
    33 If no conflict exists, the system returns:
    34 - available: true
     18SQLite relational database
    3519
    36 Screenshots
    37 Below are screenshots demonstrating:
    38 - Wedding listing
    39 - Attendance overview
    40 - RSVP overview
    41 - Venue availability with conflict
    42 - Venue availability without conflict
     20SQL schema and seed scripts
    4321
    44 This prototype demonstrates the feasibility of implementing
    45 the database usage scenarios and validates the database design.
     22Flask development server (local execution)
     23
     24== Prototype Architecture
     25
     26The backend prototype consists of:
     27
     28An SQLite database created using SQL DDL scripts
     29
     30Pre-populated sample data using seed scripts
     31
     32A Flask application exposing REST endpoints
     33
     34JSON responses for all API calls
     35
     36The application is executed locally and accessed through a web browser using HTTP requests.
     37
     38== Implemented REST Endpoints
     39
     40The following REST endpoints are implemented and operational:
     41
     42'''/weddings'''
     43Returns a list of weddings stored in the database.
     44
     45'''/weddings/<wedding_id>/events'''
     46Returns all events associated with the selected wedding.
     47
     48'''/weddings/<wedding_id>/guests'''
     49Returns all guests related to a specific wedding.
     50
     51'''/weddings/<wedding_id>/attendance'''
     52Displays attendance information for a wedding event, including guest names, roles, attendance status, and table assignments.
     53
     54'''/weddings/<wedding_id>/rsvp'''
     55Returns RSVP responses for guests for a selected event.
     56
     57'''/availability/venue'''
     58Checks venue availability for a given venue, date, and time interval and detects possible scheduling conflicts.
     59
     60== Demonstrated Functionalities
     61
     62The prototype demonstrates the following key functionalities:
     63
     64Retrieval of wedding data from the database
     65
     66Display of attendance overview per event
     67
     68Role-based guest participation (guest, best man)
     69
     70Handling of optional attributes (e.g. table number)
     71
     72Venue availability checking with time overlap detection
     73
     74== Venue Availability Logic
     75
     76Venue availability is determined by checking existing bookings for a selected venue on a specific date.
     77
     78Two scenarios are demonstrated:
     79
     80Conflict case
     81If an existing confirmed booking overlaps with the requested time interval, the venue is not available.
     82The response returns "available": false and provides details about the conflicting booking.
     83
     84Free case
     85If no overlapping bookings exist, the venue is available.
     86The response returns "available": true with an empty conflicts list.
     87
     88This logic prevents double-booking of venues at the application level.
     89
     90== Prototype Evidence
     91
     92The following screenshots are attached to this page as evidence of the working prototype:
     93
     94Flask development server running locally
     95
     96Overview of available REST endpoints
     97
     98Wedding list endpoint response
     99
     100Attendance overview endpoint response
     101
     102Venue availability conflict example
     103
     104Venue availability free example
     105
     106These screenshots confirm the correct execution of the backend prototype and successful interaction with the database.
     107
     108== Conclusion
     109
     110Phase P4 successfully demonstrates a working backend prototype for the Wedding Planner system.
     111The implementation validates the database design from previous phases and confirms the correct behavior
     112of core system functionalities through RESTful API endpoints.
     113
     114The prototype provides a solid foundation for further development and potential frontend integration.