Changes between Version 5 and Version 6 of P4


Ignore:
Timestamp:
01/10/26 20:33:49 (10 days ago)
Author:
193284
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • P4

    v5 v6  
    1 = P4 – Prototype Implementation (REST API)
     1= Prototype application
    22
    3 == Description
    4 This phase focuses on the implementation of a functional backend prototype for the Wedding Planner system.
    5 The prototype demonstrates the practical use of the database designed in previous phases through RESTful endpoints.
     3== Short presentation of the implemented use-cases
    64
    7 The implementation validates the relational schema and business logic by exposing selected functionalities
    8 via a Flask-based REST API connected to an SQLite database.
     5 * [[PrototypeImplementation|Presentation]]
    96
    10 == Technologies and Tools
    11 The prototype is implemented using the following technologies:
     7== Instructions for running the prototype
    128
    13 * Python 3.11
    14 * Flask web framework
    15 * SQLite relational database
    16 * SQL schema and seed scripts
    17 * Flask development server (local execution)
    18 
    19 == Prototype Architecture
    20 The backend prototype consists of:
    21 
    22 * An SQLite database created using SQL DDL scripts
    23 * Pre-populated sample data using seed scripts
    24 * A Flask application exposing REST endpoints
    25 * JSON responses for all API calls
    26 
    27 The application is executed locally and accessed through a web browser using HTTP requests.
    28 
    29 == Implemented REST Endpoints
    30 The following REST endpoints are implemented and operational:
    31 
    32 '''/weddings''' 
    33 Returns a list of weddings stored in the database.
    34 
    35 '''/weddings/<wedding_id>/events''' 
    36 Returns all events associated with the selected wedding.
    37 
    38 '''/weddings/<wedding_id>/guests''' 
    39 Returns all guests related to a specific wedding.
    40 
    41 '''/weddings/<wedding_id>/attendance''' 
    42 Displays attendance information for a wedding event, including guest names, roles,
    43 attendance status, and table assignments.
    44 
    45 '''/weddings/<wedding_id>/rsvp''' 
    46 Returns RSVP responses for guests for a selected event.
    47 
    48 '''/availability/venue''' 
    49 Checks venue availability for a given venue, date, and time interval and detects possible scheduling conflicts.
    50 
    51 == Demonstrated Functionalities
    52 The prototype demonstrates the following key functionalities:
    53 
    54 * Retrieval of wedding data from the database
    55 * Display of attendance overview per event
    56 * Role-based guest participation (guest, best man)
    57 * Handling of optional attributes (e.g. table number)
    58 * Venue availability checking with time overlap detection
    59 
    60 == Venue Availability Logic
    61 Venue availability is determined by checking existing bookings for a selected venue on a specific date.
    62 
    63 Two scenarios are demonstrated:
    64 
    65 '''Conflict case''' 
    66 If an existing confirmed booking overlaps with the requested time interval, the venue is not available.
    67 The response returns "available": false and provides details about the conflicting booking.
    68 
    69 '''Free case''' 
    70 If no overlapping bookings exist, the venue is available.
    71 The response returns "available": true with an empty conflicts list.
    72 
    73 This logic prevents double-booking of venues at the application level.
    74 
    75 == Prototype Evidence
    76 The following screenshots are attached to this page as evidence of the working prototype:
    77 
    78 * Flask development server running locally
    79 * Overview of available REST endpoints
    80 * Wedding list endpoint response
    81 * Attendance overview endpoint response
    82 * Venue availability conflict example
    83 * Venue availability free example
    84 
    85 These screenshots confirm the correct execution of the backend prototype and successful interaction with the database.
    86 
    87 == Implemented Use Cases
    88 The prototype demonstrates the following usage scenarios:
    89 
    90 * View weddings managed by a user
    91 * View events for a wedding
    92 * View guest list
    93 * Track attendance and seating
    94 * Manage RSVP responses
    95 * Check venue availability
    96 * Detect booking conflicts
    97 
    98 == Conclusion
    99 Phase P4 successfully demonstrates a working backend prototype for the Wedding Planner system.
    100 The implementation validates the database design from previous phases and confirms the correct behavior
    101 of core system functionalities through RESTful API endpoints.
    102 
    103 The prototype provides a solid foundation for further development and future frontend integration.
     9 * [[BuildInstructions|Documentation]]