PJ2.

Movie Ticket Management System

BPM
A. Online Ticket Booking Process

1. Access the Website

The user visits the cinema website.
2. Membership Check
 If the user is not a member → register for an account (account stored in
DB).
 If the user is a member → log into the system.
3. Authentication
 The system authenticates the user.
 If authentication fails → request login again.
 If successful → proceed.
4. Search and Select Showtime
The member searches for a movie and selects a showtime (movie list, video
trailer, or date).
5. Select Ticket Quantity
The member selects the number of tickets.
6. Check Ticket Availability
The system checks the remaining tickets.
 If tickets are available → proceed.
 If not available → booking fails.
7. Confirm Booking
The member confirms the booking request.
8. Booking Validation
The system validates the booking information:
 If invalid → cancel booking and send a cancel notification.
 If valid → request a generate code.
9. Generate Booking Code
The system generates a booking code and sends it to the member.
10. Booking Result
 Successful booking → acknowledgment message is sent to the member.
 Failed booking → booking failure notice is displayed.

b. Direct Ticket Purchase at Cinema

c. Ticket Cancellation Process
∙ Customer requests ticket cancellation.
∙ The system checks cancellation eligibility (based on policies).
∙ If valid: ticket status is updated and refund is processed.

d. Administrative Operations
Manage film list, screening rooms, and showtimes.

1. Film Management Process (Top Section)

Actors: Admin (user), System (backend).
Flow:
1. Access Film Management Mode → Admin enters film management.
2. Display Film List → System shows existing films.
 3. Decision Point:
o Add New → Admin fills in film details → Save changes.

o Edit/Delete:

 Select film →
 If Edit → Fill/Edit film information → Save changes.
 If Delete → Confirm deletion.
4. System Validates & Updates Database → Ensures changes are correct.
5. System Displays Success/Error Message → Feedback to admin.
6. End of the process.
✅ This allows admins to add, edit, or delete movies, with validation and feedback.

2. Room Management Process (Bottom Section)

Actors: Admin (user), System (backend).
Flow:
1. Access Room Management Mode → Admin enters room management.
2. Display Room List → System shows existing rooms.
3. Decision Point:
o Add Room → Fill/Edit room details → Save information.

o Select Room → Admin chooses an existing room.

 Edit → Fill/Edit room information → Save information.

 Delete → Confirm deletion.
 Management Seats → System shows seat map → Modify
seat information.
4. System Validates & Updates Database → Ensures modifications are
valid.
5. System Displays Message → Success or error feedback.
6. End of the process.

Add or edit promotional events.

Actors:
 Admin: manages events (add, edit, delete).
 System: validates, updates, and displays information.

Process Flow
1. Access Event Page
o Admin enters the event management module.

2. Display Event List

o System shows the list of existing events.

3. Decision Point:
o Add New Event → Admin adds a new event → Fill/Edit information
→ Save changes.
o Select Event → Admin chooses an existing event:

 Edit → Fill/Edit information → Save changes.

 Delete → Confirm delete.
 If Yes → Delete event.
 If No → Return to event list.
4. System Validation
o After saving or deleting, the system validates input and updates the
database.
5. Display Message
o System provides feedback (success or error).

6. End of Process
∙ Manage employee accounts and permissions.

Actors:
 Admin: manages employees (add, edit, delete).
 System: validates, updates database, and displays feedback.

Process Flow
1. Access Employee Management Page
o Admin enters the employee management module.

2. Display Employee List

o System shows a list of current employees.

3. Decision Point:
o Add New Employee → Admin adds a new employee → Fill/Edit
employee information → Save changes.
o Select Employee → Admin chooses an existing employee:

 Edit → Fill/Edit information → Save changes.

 Delete → Confirm delete.
 If Yes → Delete employee.
 If No → Return to employee list.
4. System Validation
o After saving or deleting, the system validates input and updates the
employee database.
5. Display Message
o System shows a success or error message to inform the admin.
 6. End of Process

 Generate reports on ticket sales and revenue by movie or time.

Flow Explanation of the Diagram

1. Start
The process begins when the Admin (Statistics Viewer) initiates the
workflow.
2. Access Statistics Page
The admin logs into the system and navigates to the Statistics Page.
This is the entry point for requesting reports.
3. Choose Report Type by Film/Ticket
The admin selects the type of report they want to view. Reports can be
categorized by Film or by Ticket.
4. Request Report
After choosing the report type, the admin submits a Report Request to
the system.
5. Query Database & Generate Report (System)
The System processes the request:
o It queries the database for the required data.

o It generates the report according to the chosen criteria (film/ticket).

6. Display Report
The generated report is then returned and displayed to the admin for
review.
7. End
The process finishes once the report is displayed.
CDM (Common Data Model)

Our system is built upon five core entities:

 Customer: Stores information for registered users.
o CustomerID (Primary Identifier), Name, Phone, Email.
 Movie: Stores detailed information about a film.
o MovieID (Primary Identifier), Title, Genre, Duration, Rating.
 ScreeningRoom: Represents a physical cinema hall.
o RoomID (Primary Identifier), RoomName, Capacity.
 Showtime: Represents a specific screening event, acting as the link
between
a Movie and a ScreeningRoom.
o ShowtimeID (Primary Identifier), StartTime, EndTime.
 Ticket: Represents a single ticket sold for a specific showtime.
o TicketID (Primary Identifier), SeatNumber, Price, BookingTime, Status
Logical Relationships (One-to-Many)
 A Customer can have many Tickets.
  A Showtime can have many Tickets.
 A Movie can have many Showtimes.
 A ScreeningRoom can host many Showtimes

PDM

Entities and Attributes

1. Movie
o MovieID (PK) – Unique identifier for each movie.

o Title – Name of the movie.

o Genre – Type of movie (Action, Comedy, etc.).

o Duration – Length of the movie (in minutes).

o Rating – Movie rating (e.g., PG-13, R).

2. ScreeningRoom
o RoomID (PK) – Unique identifier for each screening room.

o RoomName – Name/label of the room (e.g., Room 1, VIP Hall).

o Capacity – Number of seats available in the room.

3. Showtime
 o ShowtimeID (PK) – Unique identifier for each showtime.

o MovieID (FK2) – Refers to Movie.MovieID, linking the showtime

to a movie.
o RoomID (FK1) – Refers to ScreeningRoom.RoomID, linking the
showtime to a room.
o StartTime – When the show starts.

o EndTime – When the show ends.

4. Customer
o CustomerID (PK) – Unique identifier for each customer.

o Name – Full name of the customer.

o Phone – Customer’s phone number.

o Email – Customer’s email address.

5. Ticket
o TicketID (PK) – Unique identifier for each ticket.

o ShowtimeID (FK2) – Refers to Showtime.ShowtimeID, linking

the ticket to a specific show.
o CustomerID (FK1) – Refers to Customer.CustomerID, linking the
ticket to the person who booked.
o SeatNumber – The seat assigned for the ticket.

o Price – Ticket price.

o BookingTime – The date and time when the ticket was booked.

o Status – Ticket status (e.g., Paid, Canceled).

o BookingMethod – How the ticket was booked (Online, Counter,

Mobile App).

Relationships
1. Movie – Showtime (1:N)
o A movie can have many showtimes.

o Each showtime is linked to only one movie.

2. ScreeningRoom – Showtime (1:N)

o A room can host many showtimes.

o Each showtime happens in one room.

3. Showtime – Ticket (1:N)

 o A showtime can have many tickets booked.

o Each ticket belongs to one showtime.

4. Customer – Ticket (1:N)

o A customer can book many tickets.

o Each ticket belongs to one customer.

VI.OOM
The Transformation Process
The conversion from a PDM to an OOM is a fairly natural process:
 Each Table in the PDM typically becomes a Class in the OOM.
 Each Column of the table becomes an Attribute of the class.
 The Foreign Key relationships in the PDM are represented as Association
relationships between classes. Instead of storing an ID, classes hold a reference
to the entire
related object.
Customer entity
 The Customer table becomes the Customer class. The columns CustomerID,
Name, and so on,
become the attributes customerID, name, etc., of this class.
 The Ticket class will NOT contain a customerID attribute. Instead, it will contain
an attribute
whose data type is the Customer class itself.
 The relationship is no longer just a numeric reference; it is a direct association
between two
objects. A Ticket object "knows" about the Customer object that owns it. This
allows a
developer to easily retrieve the customer's name with an intuitive command
like myTicket.getOwner().getName(), without having to think in terms of JOINing
tables.
VII. XSM
The XML Schema Model defines the structure, content, and constraints of XML
documents. It specifies
the allowed elements, attributes, data types, and their relationships, ensuring
that XML data is valid,
consistent, and interpretable by systems that exchange or process XML content.
The Transformation Process
Similar to the OOM, the XSM is also derived from the established data structure:
 Each table or entity can be defined as a complex element in the XSM.
 Each column becomes a child element within it.
Customer and Ticket entity
 The Customer table is converted
into <Customer> element. Both of these
elements are at a peer level, acting as direct
children of a single root element (in this
case, Database). This structure fails to
represent that a ticket belongs to a customer;
instead, it merely indicates that "this database
contains customers and tickets."
 The CustomerID column in the Ticket table
is a Foreign Key. It carries a special
significance: it creates a constraint and
a logical link to the Customer table.
 The CustomerID foreign key column from
the Ticket table is converted into
an ordinaryXML
element named <CustomerID> with the
type xs:int.