1

Cinema Booking System

Course: Modelling and Design (fall 2007)

Course responsible: Thomas Hildebrandt

Submitted by: Toomas Kutt(toomas@itu.dk),

Fraz Tabassam(tabassam@itu.dk)
Jens kaae Christensen(jenschr@itu.dk)

Contents
System Introduction: ........................................................................................................... 3
System definition ................................................................................................................ 4
Factor Analysis: .................................................................................................................. 4
Problem Domain overview ................................................................................................. 4
Application domain overview ............................................................................................. 5
The problem domain ........................................................................................................... 5
Structure ........................................................................................................................... 5
Classes: ........................................................................................................................... 5
Events:............................................................................................................................. 7
Behavior: ......................................................................................................................... 8
The Application Domain: ................................................................................................... 9
Usage............................................................................................................................... 9
Actors: ........................................................................................................................... 11
Use Cases: ......................................................................................................................... 11
Search ............................................................................................................................ 11
Booking ......................................................................................................................... 11
Payment......................................................................................................................... 12
TicketPrint..................................................................................................................... 12
SessionEditing............................................................................................................... 12
CinemaEditing .............................................................................................................. 12
Functions: .......................................................................................................................... 14
Design Document.............................................................................................................. 21
Purpose:......................................................................................................................... 21
Correction to the analysis: ............................................................................................ 21
Quality Goals: ............................................................................................................... 21
Technical Platform: ........................................................................................................... 22
Equipment: .................................................................................................................... 22
System Software: .......................................................................................................... 22
Design Language: ......................................................................................................... 22
Architecture: ..................................................................................................................... 22
Component Architecture: .............................................................................................. 22
Process Architecture: .................................................................................................... 23
Model Component: ....................................................................................................... 24
Function Component:.................................................................................................... 26
Conclusion: ....................................................................................................................... 27
References: ........................................................................................................................ 27

Cinema Booking System

System Introduction:
The system covers all cinemas in a country, but depending upon needs, it can integrate
cinemas of other countries as well. Any cinema has one or more rooms, and each room
contains a set of seats. A room can be built and integrated in the system through a room
Designer interface, managed through a web based cinema manager interface. In future
releases, this system will provide an interface allowing existing cinema management
systems to easily adapt to communicate with our system.
People should use our system to find particular movie-sessions by various search criteria
like country, area, city, time, cinema or movie title. When entering the web-page the
system automatically sets the search conditions to the local area, and a time interval
spanning the rest of the current day. When the user has entered search criteria he or she
will be presented with a list of session-links that fulfill the criteria or an empty list.
Clicking a session link returns a graphical presentation of the room of the session, at
which seats can be selected/deselected, a total prize displayed and a booking-commit
button. A booking number will be displayed at the screen. The user can bring along this
booking number and have the tickets printed later. Also, this booking number is essential
if the user should have his/her money back due to session-cancellation, disease or other
problems. If a user does not pay before some time limit, specified by the local cinema,
before the session begins, the reservation will automatically be cancelled and the
corresponding set of seats becomes available for other users. When the movie has been
on for some time-span, which is also set by the cinema manager, booking or buying a
ticket for that particular session is no longer possible. However, the session information
is kept for some time to handle any customer-requests or -complaints. Upon payment,
printing the corresponding tickets is possible at any computer connected to the internet
and a printer, or at any cinema covered by the system. It is the users responsibility to
take care of the tickets because a given ticket, representing a seat, can only be printed
once.
The system provides functionality for a cinema manager to schedule future movies at
his/her own cinema, i.e., entering sessions into the database, as well as changing the
scheduling and correcting errors in scheduling (If any bookings have been made this
becomes a bit more tricky!).
Thus, the system has two kinds of clients,
1- User: (Searching, Booking, Paying)

4
2- Cinema manager (persons who use the system for their cinema)
If some cinema wants to be part of the system, someone responsible for managing the
cinema must contact the system administration. The system administration will grant
permission to the cinema so scheduling of movies at the particular cinema can be
performed.

System definition
People can use this system to search movies and cinemas in any area specified by the
user. Cinemas consists of rooms and seats. Users of the system can search for cinemas
or movies. They should be able to narrow down the search to any area and time interval.
Booking, payment and printing tickets is possible from any computer on-line. The central
class is the session class that have information about movie, cinema, room, time, seats
and bookings. Cinema managers can schedule, reschedule and correct movie session
scheduling. Session information is collected in timetable-objects for making searching
more efficient.

Factor Analysis:
Functionality searching, booking, buying, scheduling
Appl. domain - serving cinema customers, clerks.
Conditions - Cooperation with cinema clerks, other similar booking systems,
(Multilingual system. Non skilled users. 99.99% uptime, almost unlimited ressources.)
Technology - client-server, replicated server farms, incrementally built upon need, 1.0001.000.000 concurrent users.
Objects Cinema, Room, Seat, Session, Movie, Booking, TimeTable.
Responsibility - reliably searching movies and cinemas and booking and buying.

Problem Domain overview

The target system should provide facilities for clients and cinema clerks to search for
vacant seats at particular movie-sessions using various criteria like city, cinema, movie
title, movie category etc.. When users have identified a particular session, the session
screen is displayed, at which, depending on the color of the seat-symbols, it is possible to
choose a number of seats to book or reserve. A reservation can either be followed directly
by payment or a reservation number can be brought to another computer and used as
login or to the cinema and in both cases payment can be made and tickets printed. If a
cinema burns down or for any other reason a session is cancelled, it is announced on the
web page. It is crucial that users keep his/her reservation number if, for any reason,
money for bought tickets should be refunded. Thus, sessions are kept in some session
storage for some time to make it possible to track any relevant information in any cases
of complaint.

Application domain overview

The system should sustain all tasks necessary for any customer to make the cinema
experience nice and easy. Whether a cinema wants to have clerks employed at the
cinema, is a matter of choice of the cinema owner. This system is supposed to work in a
way that all necessary tasks can be done solely by the user. The whole spectrum from
searching a movie and location to having bought and printed a set of tickets is managed
by the system and controlled by the user. Cancellation and handling of erratic scenarios
or use-cases is covered by keeping past session information stored for some limited time.
The system contains all movies that any cinema manager has bothered to enter into the
system. So, if an old or new movie has not been entered and a cinema manager wants to
schedule the movie at his/her cinema in the near future, he or she has to enter it with all
required fields. This is done through the cinema manager interface.

The problem domain

Structure
Clusters
Figure 1 show the class diagram and the only cluster we have in our system is indicated:
Cinemas have rooms which have seats. Cinemas aggregate rooms which aggregates seats.
A description of classes and events follows.

Classes:
Time table
Time table is container class in current system. It contains list of all sessions, list of all
movies and cinemas. Time table class is selected for searching point of view. As it
contains complete information about cinemas, movies and session, user can search all
the sessions available for movie or can search all the cinemas registered with cinema
booking system.
Attributes: timeTableID, cinemaList, movieList, sessionList.
Session
A session object uniquely holds together time, room, seat, booking and movie. Session
is the central class that coordinates this information, thus it holds the data model read to
present a screen of vacant and reserved seats. It also keeps track of booking and payment
information.
Attributes: time, session ID
Booking
Information on a set of seats at a session a user can be identified through a reservation
number.
Attributes: booking ID.
Movie
Movie contains information about the movies in general. For example it carries
information about the tiltel of movie, actors, category (action, comedy, etc.).
Attributes: title, category, abstract, author, year.

Cinema
Cinema class carries general informatin about a cinema i.e. name of cinema, location, and
contact information.
Attributes: name, address, municipal, telephone, fax, manager.
Room
A room has a number and contains a seat plan (set of seats). Room is aggregation of
cinema. A cinema can have one or many rooms.
Attributes: room ID, seat plan.
Seat
Seat class is a template for all seats and every seat object knows whether it is free. Seat
class is aggregation of room class. A room can have several numbers of seats.
Attributes: seat ID, reserved, and paid.
Booking
The booking class has information about the session and a set of seats.
Attributes: Booking ID, seat List.

Figure 1: Class Diagram.

Events:
seatSelected/seatDeselected
A customer selects and deselects seats while choosing the appropriate seats at the session
screen.
seatPaid
A seat has been paid for.
Book
If a seat was selected at the time of committing the booking it becomes reserved.
bookCancelled
A customer may enter the booking ID and cancel the reservations.
bookTimeOut
Before session-start, before some time-interval set by the cinema manager, all non-paid
reservations are set free automatically for other customers to book.
ticketPrinted
Tickets, representing single seats
When the cinema manager enters can be printed only once.
sessionScheduled/sessionCancelled session data to the database a number of sessions get
scheduled, like pressing a commit session schedule button. Sessions can be cancelled.
sessionTimeOut
A number of minutes into a movie session, the number is decided by the cinema
manager, the seats of a session become unavailable for buying. The session is then stored
for later use in case of any inquiries or complaints.
searchTermsEntered
The customer has pressed the search button, search-criteria being valid or not.
roomUpdated(created/deleted)
Rooms can be designed, relating to number and arrangement of seats, in the system using
the room-designer interface available for cinema managers. Also rooms can be renovated
and changed.
cinemaUpdated(entered/exited)
Cinemas may enter or exit the system. This information is fed to the system by the
cinema managers.

8
movieUpdated(entered)
When a new movie has been produced it should be entered into the system, with all
relevant descriptive fields, so that cinema managers can pick the title from a ListBox and
schedule it at his/her cinema.

Events
seatSelected
seatDeselected
seatPayed
selectionBooked
bookCancelled
bookTimeOut
roomCreated
roomDeleted
cinemaEntered
cinemaExited
sessionScheduled
sessionTimeOut
sessionCancelled
ticketPrinted
movieEntered

Classes
Cinema

+
+
+
+

Seat
*
*
+
+
+
+
+
+

Room

Session

Movie

Timetable Booking

+
+
+
+
+
+
+
+
+

+
+
+
+

+
+
+
+

+
+
+
+
+

Table 1: Event table.

Behavior:
Problem domain dynamics is mainly associated with session, booking and seat classes.
Booking:
On committing a request for a booking of a selected set of seats, a booking object is
created that hold the relevant information. It is destroyed when it is cancelled, paid for or
timed out.

Figure 2: Behavioral pattern, state chart, for the class Booking.

Session:
A session is created by the cinema manger when he schedules it. It then becomes
available for booking and so on. When the session has begun it is no longer available for
any booking or buying and is thus destroyed. (It is stored on disc for accommodating
possible complaints).

Figure 3: Behavioral pattern for the class Session.

Seat:
Seats are created in connection to the creation of session objects. When a session is
scheduled the seats are active in the sense that they can be booked and cancelled until
close to session beginning.

Figure 4: Behavioral pattern for the class Seat.

The Application Domain:

Usage
Overview:
Two actors have been identified, Enduser and Cinema Manager and six use cases
associated with these actors. Figure 5 shows both actors and use cases.

10

Use Cases
Search
Booking
Payment
Ticket print
Sesseion editing
Cinema editing
Figure 5: Actors and use cases

Figure 6: Use case diagram

Actors
Enduser
X
X
X
X

Cinema Manager

X
X

11

Actors:
Figure 7 explains the details of two actors of the system.
Enduser
Purpose: A person who uses current
system to search movie, cinema or
make booking of seat.

Cinema Manager
Purpose: A person who can edit session and
cinema information.

Characterization: The person performing this work does not need some
special experience.

Characterization: The person perforim this

work need some administritive experience.

Examples: Any person who want to

Watch movie or want to get information about cinema. A cinema clerk
also uses this system.

Examples: A person who administrate the

cinema. It could be the cinema owner.

Figure 7: Definition of the actors.

Use Cases:
Six use cases of current system are described in detail as follow.

Search
When a visitor of the web-site enters the main page the three listboxes named Continent,
Country and region are prefilled according to the location of the visitor. Also two sets of
list boxes specifying date and time are prefilled to define a time period corresponding to
the rest of the present day, which is most likely the relevant interval for the user. Any
search can not proceed before the user has accepted these search criteria. This is to limit
the content of the listboxes that follow; city, city area, cinema, movie-title. The user can
press the search button after entering any combination of criteria and an SQL query will
be generated accordingly so as for the system to return a result list. Alternatively, a
message stating the search result be the empty list, or an error message is generated and
displayed so the user is assured that the system understood the criteria entered but
deemed it meaningless.

Booking
The potential customer clicks a session from the list that results from the search. A screen
representation of a room with seats appears. Seats already booked and paid for will be
red, booked but not paid seats are yellow, whereas vacant are green. The customer can
now select and deselect green seats and press the book button to commit a booking. The
customer can also appear half an hour before the beginning of a session and hope that
some of the yellow seats have not been paid for. When committing a booking, a message
about possible rescheduling are announced at the site and that money can be refunded
using proper identification.

12

Payment
When a booking has been committed, the user is presented with a choice of paying
immediately or later. If immediately is chosen the user is presented with a standard
procedure from PayPal or other third-party Payment-service.

TicketPrint
When Payment for a set of seats has been performed either outside or at the cinema, the
individual tickets can be printed. This is done by the user identifying him-/herself with
either a stripe-code printed at home or elsewhere which can be interpreted by a machine
at cinema, or identification through the card used for payment. If payment is performed at
the cinema, identification is not necessary.

SessionEditing
Cinema managers schedule movie sessions through an interface. Sessions can be entered
into and deleted from the system. Sessions can also be edited. All this is done through the
cinema manager interface. If, for some reason a movie-session must be cancelled or
rescheduled, this is straight forward while there are no bookings for the session it
becomes a more complex task if bookings have already been made for the session. Then
announcements must be made on the site. Because users are anonymous, they cannot be
notified directly. However, users of the system are made aware of this risk when making
a booking.

CinemaEditing
Cinema managers can be allowed to register their cinema with the system, at which point
the rooms should be built and become available to the system. The use case is best
described as a how to use the cinema managers room designer. New rooms can be
built, new seats added and so on. These tasks are performed through the cinema manager
interface.

13

Figure 8: The state-chart diagram defines different ways the system can change state.
The booking use-case is the central use-case of our system.

14

Functions:
Table 2 shows list of function, associated with the system. Table also shows type of each
function and complexity level.

Search

Booking

Payment

Cinema
manager

Function
GetContinentList
GetCountryList
GetRegionList
GetSessionList
GetCinemaList
GetMovieTitleList
SetTimeInterval
DisplaySessionSeats
SelectSeat
DeselectSeat
BookSelectedSeats
CalculatePrice
CreateReceipt
PrintReceipt
CreateTickets
PrintTickets
GetSessions

HasAnyBookings
EditSession
StoreSessionInfo
GetCinema
GetRoomPlan
GetSeatList
SetPayTimeOut
SetBuyTimeOut
EditCinema
EditSeatList
Table 2: Function list.

Update

Read
+
+
+
+
+
+
+
+

Signal Compute

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Complexity
+
+
+
++
++
++
+
+++
++
++
++
+
+
+
+
++
+
++
+
+
+
+
+
+
+
+
+

Probably the most complex of all the functions in this system is the DisplaySessionSeats
function. It reads the SeatList contained in the Session object and displays it on the client
screen with seat information encoded by color.

15

User Interface:
System has in total ten user interface forms. These forms are divided in to three parts.
1- End user
2- Cinema clerk
3- Cinema manager
English is the language for all the user interface forms.

Figure 9: Navigation diagram for user interface forms.

16
We decided to make different user interface forms for cinema clerk. Cinema clerk is also
enduser of the system, as clerk is standing at local cinema and he does not need all the
forms with searching and other criterias. He can directly view all the seats for particular
session and able to book any of the avaialble seat. Cinema manager also has separete
user interface forms. For cinema managers a special form with administrative login has
been added.

Figure 10: Enduser form1.

17

Figure 11: Enduser form2.

Figure 12: Enduser form3.

18

Figure 13: Enduser form4.

Figure 14: Enduser form 5.

19

Figure 15: Enduser form 6.

Figure 16: Cinema clerk form1.

20

Figure 17: Cinema clerk form2.

Figure 18: Cinema manager form1.

21

Figure 19: Cinema manager form2.

Design Document
Purpose:
The target system should be able to search for movie or cinema. It should also be able to
book or buy a ticket for a movie. By using the target system customer should be able to
cancel the booking. The current system should be integrated with another system that
takes the responsibility of secure payment system.

Correction to the analysis:

Some corrections were made to analysis document. New attributes added to classes in
order to capture the information of events.

Quality Goals:
Figure 19 shows priority of design criteria. Special emphasis was put on the usability,
security and reliability. Customers of the current system are going to use their credit
cards that are why security and reliability are of greater concern. We made secure
connection with another system which takes the responsibility of secure payment system.
Correction is also important because it target system is not interacting with other systems
correctly then there may be chances of wrong payments.

22
Criterion

Very
Important
X
X

Important

Usable
Secure
Efficient
Correct
X
Reliable
X
Maintainable
Testable
Flexible
Comprehensible
X
Reusable
Portable
Interoperable
X
Figure 20: Priority of design criteria

Less
Important

Irrelevant

Easily
fulfilled

X
X
X

X
X

Technical Platform:
Equipment:
The system is for all the web browsers running on regular PCs.

System Software:
Design of our system based on implementing the system in C# (C Sharp) language.

Design Language:
The design document is based on the UML notation.

Architecture:
Component Architecture:
The Current application is basically a web application and user can get all the relavent
information by using any web borwoser from any where. Keeping this scenario we
selected the client-server arcitecture for current system. It consists of two layers, a client
and a server layer. Serve interacts with several clients at the same time. Figure 21 shows
the systemss architecture.

23

Figure 21: Diagram showing the systems component architecture.[1]

Process Architecture:
The system is executed on a central server and all clients communicate with it. A client
handles user interface while server handles function and model component. Central
server provides common data to all clients. This central server has the ability to interact
with several clients at the same time, so running several processes concurrently. One
reason for keeping all data on central server is to make data consistent among all clients.
Keeping data consisten among all clients is one of the key issues in current system. If
data is consisten then there are chances of dublicate booking for the same seat which is
ofcourse idication of system failure. Figure 22 shows the typical structure of clientserver architecture with central server and associated clients.

24

:Client User

:Client Clerk
Other system

user interface

system interface

user interface

system interface

:Server

user interface

system interface

function

model

Figure 22: Diagram showing the Systems process architecture.[1]

Model Component:
The model component implements model and contains all the classes of the current
system.

25
Structure:
Few changes were made to class diagram in relation to analysis document. New
attributes added to classes. Figure 23 shows new class diagram. Now we describe
classes with more detail.
Classes
Cinema
Purpose: Register the basic information about cinemas
Attributes: name, address, tlf no, muncipality.
Operations: GetCinemaName, EditCinema, GetRoomList.
Room
Purpose: Register information of room within specific cinema.
Attributes: roomName, roomScheduledDate, roomEnteredDate, roomExitedDate
Operations: GetSeatList,GetRoomName
Seat
Purpose: Register basic information of seat within specific room.
Attributes: seatNumber, seatState, seatBookedDate, seatPaidDate
Operations: CreateSeat, GetSeatNumber, GetSeatState, SelectSeat, DeselectSeat
TimeTable
Purpose: Register all the information about sessions, movies and cinemas.
Attributes: timetableScheduledDate, timetableEnteredDate, timetableExitedDate
Operations: GetSessionList, GetCinemaList, GetMovieList
Session
Purpose: Register information of movie and its associated room and seat
Attribute: sessionStartedDate, sessionEnteredDate, sessionId, sessionStartedTime
Operations: DisplaySessionSeats, GetSeatList, GetRoomList
Movie
Purpose: Register basic information about movie
Attributes: title, movieCategory , movieScheduledDate
Operations: GetMovieTitleList,
Booking
Purpose: Register information of booking for movie at specific time, specific seat in
room and at specific cinema. It also keeps the information about payment.
Attributes: bookingId, bookingState, bookingPaymentState, bookingPaymentDate
Operations: BookSelectedSeats, PaySelectedSeats

26

Figure 23: Class diagram for model component.[1]

Function Component:
Three new classes were created and placed in the function component. The purpose of
these classes is to carry out some of the functions. The search class takes care of
returning geographical information, to narrow down the amount of data to search.
PrintTicket is in the function component because it does not belong anywhere else. Last,
the payment interface is exposed in the function component.

Figure 24: Class in the function component.

27

Conclusion:
We believe to have created an overview of a cinema booking system that may be
developed over time. We prove that understanding only the modeling concepts and not
the underlying technologies makes a result that may not be proper. We have drawn a
framework that may serve as a template for programmers to start out from. Whether a
completely different approach should have been used we are unable to judge. We
expected to have obtained such knowledge either through this course or the basic
programming courses of ITU.

References:
[1] Lars Mathiassen et.al 2000. Object oriented analysis & design. Marko, Aalborg. Dk.