CINEMACONDO
Miguel Sanabria
Alejandro Nuñez
PROBLEM AND SOLUTION
Nowadays, the ticket selling is more efficient by the
web, because it is more comfortable and quickly, you
don’t have to go to the cinema for buy a ticket.
The solution of this problem is the creation of an
application which facilitates the process of get a ticket
to the film you want to see and the cinema
mangament.
BUSINESS MODEL
The project is an API of Cinema Management System designed to streamline the
customer experience at a movie theater. The project allows users to manage
various aspects of their cinema visit, including buying tickets, managing
memberships and for the administrator it allows to manage the films, showtimes
and all the aspects of the cinema.
TOOLS
Python Java PostgreSQL Docker
Backend 1 Backend 2 Database Deployment
USER STORIES
As a user, I want to browse available movies and showtimes so that I can choose
the best option for my schedule and preferences.
As a user, I want to select and reserve my seat when purchasing a ticket so that
I can ensure I have the seating arrangement I prefer.
As a user, I want to have a payment gateway so that I can choose a payment
method.
As a user, I want to sign up for a membership so that I can receive exclusive
discounts and early access to tickets.
As a member, I want to manage my membership and view my rewards so that I
can keep track of my benefits and stay updated on perks.
As a user, I want to log in securely and manage my account so that I can update
my personal details and view my purchase history easily.
As a user, I want to see a list of movies that are going to be released soon, along
with their release dates and length, so that I can plan future visits to the cinema.
As a user, I want to see my cart and add tickets to my cart so that I can pay the
order.
As an admin, I want to access a dashboard where I can see a list of all
purchases (tickets and food orders) along with user details, so that I can assist
customers with any issues.
As an admin, I want to add new films, create showtimes and update showtimes
so that I can manage the cinema featured films.
FUNCTIONAL REQUIREMENTS I
User Authentication: The system must allow users (customers
and administrators) to log in using a username and password.
Movie Management: Administrators should be able to add,
update, and delete movie listings, including details such as title,
duration, genre, and screening times.
Showtime Scheduling: The system must allow admins to
define movie schedules, assign theaters, and manage
availability.
FUNCTIONAL REQUIREMENTS II
Ticket Booking: Customers should be able to search for
movies, select showtimes, choose seats, and book tickets.
Payment Processing: The system must handle secure online
transactions and provide booking confirmation.
User Role Management: Different access levels must be
defined for administrators and customers.
Report Generation: The system should generate reports on
ticket sales, revenue, and attendance trends.
NONFUNCTIONAL REQUIREMENTS
Performance: The system should respond to user actions
within 2 seconds under normal load.
Scalability: The system must support up to 1,000 concurrent
users without degradation in performance.
Usability: The API should be well-documented, allowing
developers to integrate it easily with front-end applications.
Availability: The system must have an uptime of at least
99.9%.
Maintainability: The software should allow for easy updates,
bug fixes, and feature expansions with minimal downtime.
ER DATABASE DIAGRAM
ACTIVITY DIAGRAMS
SEQUENCE DIAGRAMS
BEFORE DESIGN
PATTERNS
BEFORE DESIGN
PATTERNS
SOLID
Single Responsibility Principle (SRP): Each class in the system
is designed to have a single responsibility. For example, the
Movie class handles business logic related to movies, while the
Ticket class manages ticket reservations. This separation
improves maintainability and reduces code coupling.
Open/Closed Principle (OCP): The system is designed to be
open for extension but closed for modification. For instance,
new payment methods can be added by implementing an
interface without modifying existing payment processing logic.
SOLID II
Liskov Substitution Principle (LSP): Subtypes can replace their
parent types without affecting the correctness of the program.
For example, different types of users (regular customers,
member customers, and admins) extend a base User class while
maintaining consistent behavior across the system.
Interface Segregation Principle (ISP): Interfaces are designed
to be specific to the needs of their clients. Instead of having a
single large interface, the API defines multiple smaller ones,
such as PaymentGateway, ensuring that classes only implement
the methods they actually use.
SOLID III
Dependency Inversion Principle (DIP): High-level modules do
not depend on low-level modules but instead rely on
abstractions. Dependency injection is used in Spring Boot and
FastAPI to manage dependencies, making the system more
flexible and easier to test.
DEMO LIVE