Skip to content

chosen1232/Project

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

56 Commits
 
 
 
 
 
 

Repository files navigation

CS1800 Team Project

Option 2: Reservations


How to Compile and Run

This project contains the database and backend components for the Reservation System (Option 2). To compile:

javac *.java

To run tests (Phase 1 does not have a single entrypoint):

java <TestClassName>

Run individual test files directly, as there is no unified executable main in this phase.


Team Responsibilities

  • Satvik Suresh: Base class architecture and project setup, reservation logic, file managers, base persistence system, fixes for phase 1, updated seating system, most tests, authentication rework, submitted Vocareum workspace.
  • Skander Kefi: Seating classes, seating interfaces.
  • Basliel Melke: Authentication classes, abstractUser repository, abstractUser persistence.
  • Chosen Jegede: Pricing classes, pricing interfaces.
  • William Ju: Test cases

Class/Interface Descriptions

Important

  • Decided not to use Object::toString since the strings I write to files may be very long and difficult to read, which will make debugging annoying. Instead, I can just define an interface Persistable that all the classes implement that just has that one method
  • Persistable (interface) - Defines one method, String toFileString()
  • Bookable (interface) - Defines one method, double calculatePrice()
    • This interface should be implemented by Seat, as well as all pricing decorators. This will allow any decorators to extend on the implementation of Seat::calculatePrice() in order to apply any changes to the price (based
    • on seat location, time of day, etc.)

User

  • User (interface)
    • Defines the abstract accessor and mutator methods expected from AbstractUser
  • AbstractUser (abstract) - Base model for all abstractUser types;
    • Stores abstractUser information like ID (internal), name, username, password
    • Should have accessor and mutator methods for each
    • Implements Persistable (abstract, but defined in subclasses)
  • AdminUser - Elevated abstractUser type with administrative privileges;
  • CustomerUser - Standard abstractUser of the system; interacts with authentication and reservation logic.

Show (showing of a movie)

  • Screening (name is debatable but I hate ShowInterface)
    • Defines the accessor and mutator methods for Show
  • Show - Represents a movie showing with time, seating chart, and availability; persisted through ShowFileManager.
    • Stores show information like ID, SeatingArrangement ID, SeatingChart, timestamp, and movie information
    • Implements Persistable

Seat

  • Seat (interface)
    • Defines the abstract accessor and mutator methods expected from AbstractSeat
  • AbstractSeat - Abstract representation of a seat; base class for all seat types.
    • Stores seat information like ID (within seating chart), SeatPosition (row, col)
    • These objects won't be stored anywhere, only created on-demand to calculate price probably
    • Base price will be stored in the PricingManager to avoid having many seats each storing their own base price (which would make updating a base price very inefficient)
    • Defines a calculate price method, which for this class, will just return it's base price. However, this method will be used by Pricing decorators to dynamically augment the price based on several factors (see Bookable interface)
    • Also note that availability status is not stored by the Seat itself, that's represented by the SeatingChart internal array
    • Implements Persistable (abstract, but defined in subclasses)
    • Implements Bookable (abstract, but defined in subclasses)
  • StandardSeat - Default/basic seat type; inherits from Seat.
  • AccessibleSeat - Accessibilty seat type
  • RecliningSeat - Premium seat type (reclining seat)

Seating Layout

  • SeatLayout (interface)
    • Defines the abstract accessor and mutator methods expected from SeatingArrangement
  • SeatingArrangement - Represents the seating layout;
    • Internally, is an 2d array of Strings, essentially dictates which types of seats go where in the theater,
      • P = Premium, A = Accessible, S = Standard in the layout?
    • Implements Persistable

Seating Chart (per-show availability)

  • LayoutMask (interface) (I'm really cooking with these interfaces names)
    • Defines abstract accessor methods expected from SeatingChart
    • I call it a "mask" since the integer array essentially "masks" the layout with integers representing availability of each seat corresponding to the row and column of the mask.
  • SeatingChart - Stores availability status for each seat in a specific show; used by SeatingFileManager and ShowFileManager.
    • Internally, is an integer 2d array, where different integers represent the status of the seat
      • (e.g. 0 = available, 1 = booked). If the only values are 0 and 1, might use a boolean array or a BitSet (bitsets logic might be harder to read though)
    • Implements Persistable

Pricing

Uses the Decorator Design Pattern to allow us to chain different pricing algorithms onto the base price

  • AbstractPricingDecorator (abstract)
    • Implements Bookable (abstract, defined in subclasses)
    • Stores a Bookable object as a field component
  • DayBasedPricingDecorator - Pricing strategy based on show day; used by PricingManager.
    • Implements the calculatePrice() method by modifying the output component.calculatePrice() method.
  • TimeBasedPricingDecorator - Pricing strategy based on show time; used by PricingManager.
    • Implements the calculatePrice() method by modifying the output component.calculatePrice() method.
  • SeatTypePricingDecorator - Pricing strategy based on seat type; used by PricingManager.
    • Implements the calculatePrice() method by modifying the output component.calculatePrice() method.

Reservations

  • Reservation (interface)
    • Contains abstract accessor and mutator methods for fields defined in Reseration
  • ReservationImpl - Core model representing a reservation instance; connected to ReservationManager.
    • Stores reservation id, showid, list of users, list of seats corresponding to each user, pricePaid
    • Will probably have methods for calculating total price before it's paid,
    • but don't want to store it as a field since it's not really a stored value
    • Simply a sort of wrapper class for booking one or multiple Seats (e.g. as a party).
    • Also implements Persistable

Managers and File Handlers

These are (static?) dependencies for reading and writing data that is used by a multitude of services, and thus may require adjustments for thread safety and atomicity. It's important to note that all major write operations should update the models in memory as well as the database "files" with a thread-safe write. This is to minimize the amount of data loss from unexpected program crashes.

How are we handling dependencies? Constructor injection. For example, the SeatingManager depends on PricingManager to calculate seat prices, so PricingManager will be initialized in the constructor of SeatingManager. Just have to try and prevent circular dependencies and we will be all good. Classes below are stored in order of initialization (classes with more dependencies must be initialized after their dependencies)

  • UserFileManager - Loads, saves, and updates abstractUser data.
    • Stores a list of Users upon loading from file
    • fetch abstractUser - fetch a abstractUser by id or other identifying information (ideally username, not first or last name)
    • check if abstractUser exists
  • PricingManager - Calculates final ticket price using seat type, time-based, and day-based strategies
    • Given information about a seat, contains methods to calculate the final price using the above decorators.
    • Additionally, stores the base prices of seats to make it easier to update by an AdminUser
  • SeatingFileManager - Manages storage and retrieval of seating charts and seat availability. This manager is special because it manages both seating CHARTS as well as specific seating configurations for shows. For example, it will allow an AdminUser to edit seating arrangements for all shows, but ALSO lock out sections for specific shows.
    • Add chart - adds a seating chart with some configuration string
    • Remove chart - removes a seating chart if it exists
    • Update chart - updates a seating chart
    • Set the availability of specific seats for a show
  • AuthManager - Handles authentication, login persistence, and abstractUser credential validation.
    • Request login - evaluates validity of credentials
    • Register abstractUser - add new abstractUser to list of users and persist
    • Delete abstractUser? - delete abstractUser
    • Depends on UserFileManager
  • ShowFileManager - Manages persistence and loading of shows
    • Create show - Create a show on a specific date and time and movie(?)
    • Delete show - Delete a show if it exists
    • Update show - Update a show's information
      • Assign chart - assign a show a specific seating chart
      • Update seating - Will handle updating availability itself
      • Depends on: SeatingFileManager, PricingManager
  • ReservationFileManager - Creates and modifies reservations and loads/saves reservation data.
    • Create reservation - creates a reservation if possible given inputs
    • Delete reservation - deletes a reservation if it exists
    • get reservation by id - get a reservation by the id (index)
    • Depends on: ShowFileManager

Server/Client IO

  • Server - Represents a server that can handle multiple clients at once in a thread-safe manner
    • main method accepts incoming connections and creates a new thread for each connection
    • Run method handles incoming requests based on command name and forwards to the appropriate method
    • Implements NetworkService, which just ensures that resources are closed
  • Client - Represents a client that connects to the server
    • Sends requests to the server and handles responses appropriately
    • Implements NetworkService, which just ensures that resources are closed

Base Components and Utilities

  • BaseFileManager - Abstract file-handling class providing synchronized file I/O.
  • FileDatabase - Initializes file managers and provides central access to persistent data.
  • Constants - Holds shared constant values and string keys.
  • Logger - Utility class for simple logging and debugging output.
  • Response - Represents a Server response with codes and optional message (mirrors HTTP response codes)

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages