Functional Requirements - 2 From Beza

HiLCoE School of Computer Science & Technology
Online cinematic community and reservation system
A senior project document in partial fulfillment of the requirements for

the B.Sc Degree in Computer Science
Prepared by: Fasil Alemayehu
Michael Kebede
Mathias Abraham
Advisor: Mr. Mesfin Kifle

Acknowledgement
This senior project could not be accomplished with the effort of few people; many
have contributed their best for the successful accomplishment of this project. First and
for most, special thanks goes to our advisor Mr. Mesfin Kifle for his consistent support,
crucial comments and offering of relevant documents, which were helpful to each of the
steps that the project team passes through. Next we want to extend our thanks to Mr.
Tewodros, Mr. Sophonias for providing general information and describing their
obstacles. Finally we want to thank our friends who helped us by providing different
ideas and commenting on our project.
Executive Summary
MattiMultiplex, established in 2006, is a cinema that prides itself on giving top of
the line accommodations when it comes to the quality of its services. The business is
setup as a hub of entertainment where movie fanatics of all ages come and enjoy
current films of all genres. Its surround sound system and extraordinary seat
accommodations are only some of its many facets that give customers an enthralling
experience.
Although this business excels in all aspects of its business. It falls short in matching
this level of excellence when it comes to giving customers a similar degree of
entertainment when they access its system online. Furthermore all customers looking to
buy tickets for any movie are forced to be physically present in the premises of the
cinema. All in all this business could be greatly benefited if it had an online system
where customers are able to fulfill their reservation needs and also enjoy entertaining
functionalities in which they can immerse themselves.
This project plans to do just that. It can be thought of in two broad categories. One
category providing an entertainment package to allow users to take part in an
interactive community of users who enjoy numerous functionalities such as participating
in discussions and polls: functionalities that allow them to rate movies and view any film
related headlines. The other category is setup to give customers functionalities with
which they can accomplish goals by making reservations on movies any day of the week.
TABLE OF CONTENTS
Part I............................................................................................................................................................6
Project Proposal..........................................................................................................................................6
1.1 Introduction.......................................................................................................................................7
1.2 Background........................................................................................................................................7
1.3 Statement of the problem.................................................................................................................8
1.4 Objective of the project.....................................................................................................................8
1.4.1 General Objective.......................................................................................................................8
1.4.2 Specific Objectives......................................................................................................................9
1.5 Scope & Limitation.............................................................................................................................9
1.5.1 Scope..........................................................................................................................................9
1.5.2 Limitations................................................................................................................................10
1.6 Methodology, Tools & Data collection techniques..........................................................................10
1.6.1 Methodology............................................................................................................................10
1.6.2 Data Collection Techniques......................................................................................................10
1.6.3 Tools.........................................................................................................................................11
1.7 Significance......................................................................................................................................11
1.8 Team Formation..............................................................................................................................12
1.9 Cost Estimation................................................................................................................................12
1.10 References.........................................................................................................................................14
Part 2.........................................................................................................................................................15
Requirement Analysis Document..............................................................................................................15
2.1 Introduction.....................................................................................................................................16
2.2 Purpose of the system.....................................................................................................................17
2.3 Scope of the Project.........................................................................................................................17
2.4 Objective and Success criteria of the project...................................................................................18
2.4.1 General Objective.....................................................................................................................18
2.4.2 Specific Objectives....................................................................................................................18
2.5 Current System................................................................................................................................19
2.6 Proposed System.............................................................................................................................24
2.6.1 Overview...................................................................................................................................24
2.6.2Functional Requirements...........................................................................................................25
2.6.3Non-Functional Requirements...................................................................................................28
2.7 Actors involved................................................................................................................................31
2.8 Scenarios.....................................................................................................................................32
2.9 Use Case Diagram............................................................................................................................53
2.10 Use Case Text Description.............................................................................................................58
2.10 Object Model.................................................................................................................................89
2.10.1 Data Dictionary.......................................................................................................................89
2.10.2 Class Diagram..........................................................................................................................90
2.11 Dynamic Models............................................................................................................................91
2.11.1 Sequence Diagram..................................................................................................................91
2.11.2 Activity Diagrams..................................................................................................................111
2.11.3 State Chart Diagram..............................................................................................................114
2.11.4 User Screen Shots.................................................................................................................115
Part 111...................................................................................................................................................117
System Design Document........................................................................................................................117
3.1 INTRODUCTION..................................................................................................................................118
3.2 PURPOSE OF THE SYSTEM.....................................................................................................................118
3.3 DESIGN GOALS...................................................................................................................................119
3.3.1 Performance Criteria..............................................................................................................119
3.3.2. Dependability Criteria............................................................................................................121
3.3.3 Maintenance Criteria..............................................................................................................122
3.3.4 End user Criteria.....................................................................................................................123
3.4 Current Software Architecture......................................................................................................123
3.5 Proposed Software Architecture....................................................................................................125
3.5.1 Overview.................................................................................................................................125
3.5.2 Subsystem Decomposition......................................................................................................126
3.5.3 Hardware/Software mapping.................................................................................................136
3.5.4 Persistent Data Management.................................................................................................138
3.5.5 Access Control & Security.......................................................................................................140
3.5.6 Global software Control..........................................................................................................141
3.5.7 Boundary Conditions..............................................................................................................141
Part IV Object Design Document.............................................................................................................143
4.1 Introduction...................................................................................................................................144
4.1.1 Object Design Tradeoffs..........................................................................................................144
4.1.2 Interface Documentation Guidelines......................................................................................145
4.2 Packages........................................................................................................................................147
4.3 Class Interface...............................................................................................................................149
PART I
PROJECT PROPOSAL
1.1 INTRODUCTION
An online Cinematic site where members not only receive services typical to those
offered by any cinema, but where users can log in participate in an online community
and be a part of a group of film fanatics has never been done before. If any cinema were
to take the next step in offering its customers an immersive entertainment experience
online it has the potential of expanding its customer base as well as double its stream of
revenue. Powerful new capabilities would be unleashed if any cinema were to enhance
its system from giving regular services that customers are accustomed to, to a system
where users can come, share ideas and interact on a number issues related to films. The
fact of the matter is the majority of the people here in Addis especially those in their
teen years spend a considerable amount of their free time in watching movies. Films
have become a source of conversation with which people can share opinions and forge
friendships. Great films spark the imagination of the viewer entertaining thoughts and
opposing views on a variety of topics. Whether it may be an intricately woven story
telling film or a big action-packed blockbuster; films of every genre have become an
integral part of the modern society these days.
This project plans to take advantage of this desire people have and create an outlet
where they can come and be a part of community of film fanatics whose thoughts and
views are welcomed and entertained. Moreover this system will give its users a range of
offers that will keep them coming back for more. This project contains all the
ingredients to provide the users an entertaining experience and the staff an efficient
way to accomplish their day to day tasks.
1.2 BACKGROUND
MattiMultiplex is one of Addis Ababa’s most popular cinemas. The company prides
itself on giving its customers the ultimate cinematic experience by showing Movies that
are current that resonate with people of all ages. MattiMultiplex has set itself apart
from the pack by giving its customers a full-fledged entertainment experience where
they enjoy a selection of a wide array of engaging movies of different genres. A trip to
this cinema for a typical teen is an experience long to be forgotten. With its high-tech
surround sound system and its showing of top of the line newly released blockbusters it
has proven to be more than just a place to go and watch movies rather a place where
one can escape reality and immerse themselves in a virtual world albeit for a couple of
hours. It has redefined the movie going experience in Addis Ababa setting high
standards not only with the films it shows, but also by the quality of service it offers
each and every customer.
Despite showing excellence in all areas of customer service, MattiMultiplex lacks an

automated system where it can engage with its customers in an interactive manner.
Although the cinema is equipped with a computer based ticket sales system it is yet to
reap the full benefits it would achieve by having an online community site where
members can participate in the decision making process and provide feedback of their
experiences.
1.3 STATEMENT OF THE PROBLEM

MattiMultiplex cinema does not yet have an online site where users can log in and be
a part of a community of film fanatics where they can share experiences, vote on
different genres and films, get news and updates of which films are making headlines.
By providing customers an online immersive experience this cinema will be able to
increase its customer base. Also by giving users the opportunity of being VIP customers,
in which they will be awarded special privileges it will be able to attract more and more
people to the site.
Another problem that will be addressed is the seat reservation and ticket sales
service that the cinema provides. By allowing customers to buy tickets and reserve seats
online the current system will be improved a great fold.
1.4 OBJECTIVE OF THE PROJECT

1. 4. 1 G E N E R A L O B J E C T I V E
The main objective of the project is to provide the business with a system that
incorporates components with which employees will carry out their day to day activities
much more efficiently and customers will be much more involved in running the
business. By analyzing the current needs of the customers and employees the project
will solve the inherent problems of the business in addition to enhancing the way its
services are provided.
1. 4. 2 S P E C I F I C O B J E C T I V E S
 The specific objectives the project will meet in order to meet its goal are the
following
1. A thorough analysis of the current system. Includes
a. Analysis of its current functionalities and drawbacks
b. Requirement elicitation and analysis from all the major actors
2. Designing the inner workings of the proposed system
3. Implementation of the system
4. Testing how the system works under a variety of conditions
5. Preparing documentation with which actors can develop an understanding of
how to manipulate the various components of the system.
1.5 SCOPE & LIMITATION

1. 5. 1 S C O P E
The projects aim is to come up with a system that makes the users much more
involved in the functioning of the business and gives the staff of the cinema a means
whereby they can conduct their daily activities in a much more efficient manner.
Thus the project will cover the ticket sales and reservation systems, but goes beyond
the typical aspects of these functionalities by giving customers the opportunity of
carrying out these transactions online. This goes a long way in ensuring the customers
convenience and gives them a feeling that they play an integral role for the functioning
of the business.
This project will also yield a community site. This site that is built with the intention of
providing users an immersive experience will include functions with which users can
communicate with each other, share ideas, vote on different issues and a range of other
alluring activities.
The major components this project includes are the following

 A system that enhances the current ticket sales and reservation procedures
 Online registration of users.
 Allowing VIP users of the system (Users with pre-paid accounts) to be able to
reserve seats on showings any day of the week.
 A forum where users create and can be a part of discussions regarding their
film preferences, thoughts and ideas.
 A rating system where users can rate the movies they’ve seen.
 A voting system where users pick which movies they want to see.
 A section where news and reviews related to all the films are shown.
 A schedule management system where administrators are able to manage
schedules of all the films to be shown.
 A Voting and Rating management functionality where administrators are able
to feed voting and rating topics to the customers
 An account management system which the Global Administrator can make use
of to manage the employees accounts
 All in all, these functionalities are bound to provide an attractive and engaging
experience to any film enthusiast as well as make the job of the employees
much more efficient.
1. 5. 2 L I M I T A T I O N S
The main limitation of this project is time. Due to the sheer size of the project the
amount of time it would take to have a full implementation is much longer than the
time that has been awarded.
1.6 METHODOLOGY, TOOLS & DATA COLLECTION TECHNIQUES

1. 6. 1 M E T H O D O L O G Y
As a methodology this project follows the rules and notations set by UML. This is
because UML provides us with a rich set of modeling diagrams which will enable us to
represent every aspect of the system. Since UML has emerged as the leading modeling
language and has been accepted as the standard for modeling object oriented programs
the symbols and diagrams we use thus forth can be understood by most programmers
and designers.
1. 6. 2 D A T A C O L L E C T I O N T E C H N I Q U E S
 Questionnaire -> Since most of the people that will be using this system are
ordinary people, looking for entertainment a sample of the general public
must be taken and surveyed to provide feedback and input insight on the look
and feel of the system.
 Interview -> The manager of the cinema can potentially provide new insight
and reveal further requirements that should be implemented.
 Prototypes -> Prototyping can also be a vital tool to identify user preferences
and can have a major role on what the system will look like at completion.
1. 6. 3 T O O L S
Programming Tools
 Microsoft Expression Web

 WampServer 2.0
Documentation and Design Tools
 Microsoft Office Word 2010

 Microsoft Project 2003
 Pacestar UML Diagrammer
 Macromedia Fireworks
Programming Language
PHP + MySQL -> These two languages have proved to be a powerful tool for any
coder. Both are free and open source. They can run on any platform and web server.
They both have hundreds of forum sites with a community of developers offering their
assistance and experiences. This coupled with the fact that they are easy to learn and
use makes them ideal for a project with such a time constraint.
1.7 SIGNIFICANCE
The significance of this project can be expressed by these two major functionalities it
plans to provide.
1) Enhancing the reservation and ticket sales system by offering customers the
opportunity of carrying out these services online.
2) Providing customers with an opportunity where they can be a part of an
immersive community where they can share ideas on different films and provide
feedback of their experiences, vote on films they want to see. In general build a
community site that appeals to film goers by making every participant play a vital
role in enhancing the cinematic experience.
This system can play a vital role in the development of this company. By developing
such a system powerful ways in which revenue can be generated will be unleashed.
Integrating a cinema with an online entertainment experience is something that hasn’t
been done before and it something that will create a new found customer base for the
cinema and in the long hall transform it from just a cinematic business into a hub where
customers and film fanatics can come, share ideas and feel valued.
1.8 TEAM FORMATION

All of us participating in this project are undertaking this senior project document in
partial fulfillment of the requirements for the B.Sc. Degree in Computer Science. At the
academic level, we have been working on projects together in different courses.
Therefore it will be easy for us to work together share ideas and cooperate more
efficiently.
The team leader will coordinate the rest of the team members in order to succeed in
this project; he also has a responsibility to lead the project work flow, lead the group
discussions and make decisions on critical issues.
All of the team members will partake in every phase of the project. This way valuable
insight will be generated as all team members will be cooperating in undertaking
problems.
The group members of Online Cinematic Community and Reservation System:
1. Fasil Alemayehu
2. Mathias Abraham (Leader)
3. Michael Kebede
1.9 COST ESTIMATION
 Estimating the cost of a project is an essential phase of its development. The cost
should be feasible so that both the customer and developer of the will be benefited.
Cost estimation must address the following critical questions.
1) How much effort is required to complete an activity?

2) How much calendar time is needed to complete an activity?
3) What is the total cost of an activity?
4) Project estimation and scheduling are interleaved management activities.
Because, Project estimation and scheduling are interleaved management activities
we must have to determine the time it will take to finish the project, so that we can
determine the cost easily.
For our project we determined the following factors
 Hardware and software Requirements:
 Hardware Requirements: this includes a Server, 4 workstations,
Network cables, Switches, and Ethernet cards.
 Software Requirements: Windows Server 2008 Enterprise Edition
and Wamp Server.
 Travel and training costs: includes travel costs from the developers office to Edna
mall, and the cost of giving training for the employees. i.e. The desk clerks and
administrators.
 Effort Costs:
• The salaries of developers involved in the project;
• Miscellaneous costs.
 Effort costs must take overheads into account
• Costs of building, heating, lighting.
• Costs of networking and communications.
• Costs of shared facilities (e.g. library, staff restaurant, etc.).
 Description  Quantity  Duration  Total Cost(in birr)

 Hardware Costs   
 Server Computer  1  10,000.
 2950T Switch  1  850.
 UTP Cable  50 meter  400
 Work Station PC  4  20,000.
 1000BFX Ethernet  1  450.
card
 Software Costs   
 Windows Server
 1  50
2008 Enterprise
Edition
 Traveling cost   1 month  1000
 Training Cost   1 week  1000
 Effort Costs   
 Salaries  3  20,000.
 Miscellaneous costs  3,000.
Grand Total Cost 
 56,750.
Since we are using PHP& MySQL which are free and open source licensing costs won’t
be an issue and also because Edna mall already has a domain name no amount of
money will be spent in obtaining one.
1.10 REFERENCES
 Bernd Bruegge & Allen H. Dutoit “Object-Oriented Software Engineering:
Using UML, Patterns, and Java“ Prentice Hall, New Jersey
 Tim Converse and Joyce Park with Clark Morgan “”PHP5 and MySQL Bible”
Wiley Publishing Inc., Indianapolis Indiana
 www.w3c.net
 AJAX And PHP - Building Responsive Web Applications (2006)
Other documents found online

PART 2
REQUIREMENT ANALYSIS DOCUMENT
2.1 INTRODUCTION
Currently, in Addis Ababa, entertainment is one of the ways where people get
relaxed. A big part of this entertainment extravaganza is now taking place at Edna Mall,
specifically in MattiMultiplex cinema.
MattiMultiplex prides itself in providing the best cinematic experience in the country.
The following is an official statement made by the cinema in accordance to its services.
“MattiMultiplex, Ethiopia’s first 3 screen movie Theatre complex that will showcase
the latest and best of Hollywood, foreign, regional and local films.
The Digital Projection System from world renowned Christie complemented by the best
of Dolby Digital and THX (of Star Wars Fame) surround sound technology and latest
bucket seats with drink holders provides you with a gold class movie viewing
experience.
Our exclusive partnership with the leading movie distributors only means that our
customers who were denied the latest and the best will now get to enjoy their cinema,
KING SIZE!!! That’s not all … a movie experience is never complete without a visit to
concessions counter for your Flavored Popcorn, Nachos with jalapenos n cheese, Hot
Dogs, Soda, and the Fizz!!!
Screen 2 at MattiMultiplex is a multifunctional auditorium that is capable of playing

host to an array of activities besides screening latest cinemas.
With a seating capacity of 400, this multi-functional auditorium is equipped with the
state of the art technology for staging live theatrical plays; elaborate musicals special
events, live bands Y performances and conferences and conventions too.
From professional cutting edge digital sound systems, projection equipment,

motorized curtains, sophisticated lighting, conference equipment, wireless bi-lingual
simultaneous interpreter systems, multimedia equipment, wireless voting systems to
green rooms control room, equipment pits and back of house facilities, every
perceivable requirement to stage a successful international quality event has been
planned for and catered to. The carefully planned seating configuration combined with
special acoustic wall and ceiling panels only ensures that visitors enjoy the finest audio
and visual clarity.
Planning a world class event … we have the venue.”
2.2 PURPOSE OF THE SYSTEM

Though MattiMultiplex Cinema currently has a web based system which is primarily
used for displaying static information, we feel that such a business that has a profound
impact in shaping the entertainment industry should have a system whereby it can
enhance the user’s online experience to match the level of appeal it provides with its
services. Thus the main purpose of the system is to stamp out some of the limiting
aspects of the current system, such as the functionality it provides its customers, the
way day to day business is carried out by the employees and introduce much more
efficient, immersive and effective measures whereby all the users of the system benefit
significantly.
2.3 SCOPE OF THE PROJECT

The projects aim is to come up with a system that makes the users much more
involved in the functioning of the business and the staff of the cinema a means whereby
they can conduct their daily activities in a much more efficient manner.
Thus the project will cover the ticket sales and reservation systems, but goes beyond
the typical aspects of these functionalities by giving customers the opportunity of
carrying out these transactions online. This goes a long way in ensuring the customers
convenience and gives them a feeling that they play an integral role for the functioning
of the business.
This project will also yield a community site. This site that is built with the intention of
providing users an immersive experience will include functions with which users can
communicate with each other, share ideas, vote on different issues and a range of other
alluring activities.
The major components this project includes are the following
1) A system that automates the ticket sales and reservation procedures

2) Online registration of users.
3) Allowing VIP users of the system (Users with pre-paid accounts) to be able to
reserve seats on showings any day of the week.
4) A forum where users create and can be a part of discussions regarding their film
preferences, thoughts and ideas.
5) A rating system where users can rate the movies they’ve seen.
6) A voting system where users pick which movies they want to see.
7) A section where news and reviews related to all the films are shown.
8) A schedule management system where administrators are able to manage
schedules of all the films to be shown.
9) A Voting and Rating management functionality where administrators are able to
feed voting and rating topics to the customers
10)An account management system which the Global Administrator can make use of
to manage the employees accounts
All in all, these functionalities are bound to provide an attractive and engaging
experience to any film enthusiast as well as make the job of the employees much more
efficient.
2.4 OBJECTIVE AND SUCCESS CRITERIA OF THE PROJECT

2. 4. 1 G E N E R A L O B J E C T I V E
The main objective of the project is to provide the business with a system that
incorporates components with which employees will carry out their day to day activities
much more efficiently and customers will be much more involved in running the
business. By analyzing the current needs of the customers and employees the project
will solve the inherent problems of the business in addition to re-engineering the way its
services are provided.
2. 4. 2 S P E C I F I C O B J E C T I V E S
 The specific objectives the project will meet in order to meet its goal are the
following
1. A thorough analysis of the current system. Includes
a. Analysis of its current functionalities and drawbacks
b. Requirement elicitation and analysis from all the major actors
2. Designing the inner workings of the proposed system
3. Implementation of the system
4. Testing how the system works under a variety of conditions
5. Preparing documentation with which actors can develop an understanding
of how to manipulate the various components of the system.
2.5 CURRENT SYSTEM

MattiMultiplex cinema comprises of three Auditoriums where customers can watch
films.
Edna uses a desktop application, which automates the ticketing system, and a static
website. These two domains are completely separated
The Desktop application
This application used for ticketing system is installed on 2 desktops: one per each
desk clerk. One clerk is assigned to an auditorium to control the reservation of seats and
ticket sales through the use of this application. When a customer arrives and wants a
ticket, the clerk will make them choose a seat on this application corresponding to the
one in the cinema. The application then locks the seat and marks it as reserved and
prints a ticket which is then forwarded to the customer. There is one server where the
database for pricing resides in. The other three client PCs are connected to the server in
order to successfully apply the ticketing system.
The static Website (www.ednamall.net)
This site is a mere collection of pages showing movies currently showing, Movies
that are coming soon etc. It includes the following pages
 Home - www.ednamall.net/index.html
Figure 2. 1 Current home page
 The home page has two sections. The most recent film being shown will be
displayed on the left side of the page. On the right side of the page, i.e. the
News corner, information like new upcoming movies, new technologies
coming soon (like 3D movies) are displayed
 Show Time- www.ednamall.net/show_time.html
Figure 2. 2Current Show Time page.
This page is used to show today’s movie schedule pertaining to all 3 auditoriums.
 Now Showing- www.ednamall.net/now_showing.html

Figure 2. 3 Current Now Showing Page
This page displays movies that are currently showing in each of three halls. If there are
no movies currently showing it will display recent movies that are new to the cinema.
 Coming Soon- www.ednamall.net/comming_soon.html

Figure 2. 4 Current Coming soon Page
This page displays information about imminent movies which will be shown in the
near future.
 Cinema View- www.ednamall.net/cinema_view.html

Figure 2. 5 Current Cinema View Page.
This page introduces and gives general information about Edna mall.
2.6 PROPOSED SYSTEM

2. 6. 1 O V E R V I E W
The system this project yields will give customers a range of components with which
they can be much more involved in the business. Customers will be offered
opportunities whereby they will reserve seats online, discuss on a variety of issues
related to films. In general customers will be given a portal to immerse themselves in an
online entertainment experience. But this project is not just limited to offering services
to customers, but is also composed of offering the employees of the business a more
efficient way of carrying out their daily tasks. Therefore since this project plans to offer
two different user domains a means of accomplishing tasks its final output is going to be
two different Systems catering to these two domains.
The first system is an online system which customers access to either carry out
reservations or participate in discussions and respond to a selection of choices.
The second system is a local intranet system catering to the needs of the employees.
Administrators and desk clerks will make use of this system to undertake their jobs. Only
employees of the business are able to access this system and as such it is not available
on the internet.
2. 6. 2F U N C T I O N A L R E Q U I R E M E N T S
Any system that deals with credit/money has to implement the best possible means
of handling credit transactions. When it comes to online reservation systems a number
of ways of accomplishing this goal come to mind. From credit card payment to bank
account transfers and even including “SIM card” like imbursement there are a range of
methods which customers can utilize in order to carry out these transactions. This
project however follows a different approach when it comes to money dealings.
Considered Approaches
Our first consideration was implementing an online credit card payment system.
Many projects follow this approach in handling money transactions as it is simpler to
implement and is considered by many as “The Obvious Choice”. But due to the fact that
credit card use in Ethiopia remains in its infancy, this type of functionality will ultimately
have a negative impact on the total number of customers using the system.
Another means of handling transactions is through bank account transfers.

Customers looking to reserve seats online will be able to make payments through
money transfers from an account. Although this approach seems a good alternative it
isn’t a feasible one just because of the demographic of the customers. More than 60%
of the customers are adolescents. The assumption of relatives of these customers
providing a bank account number so that they may be able to reserve a seat in a cinema
is not plausible one. Also customers who don’t have bank accounts would be hindered
from accessing the reservation functionality.
Chosen Approach
The method that was chosen for this project, despite having some drawbacks, is the
best possible means in which customers can carry out online seat reservation without
going through much hassle.
First off any customer that intends to reserve seats online needs to have an account
in this system. Before doing any kind of transaction the customer has to purchase a
reservation credit from the cinema. This reservation credit is not something imprinted
on a card or a sheet of paper; it doesn’t have a physical existence. This purchase is a
virtual one in that when customers pay a certain amount, the desk clerk makes use of a
functionality provided by the system to charge their accounts with the amount of paid.
In the process of obtaining this credit the customer will be asked to provide his
username by the desk clerk. The desk clerk will then receive cash from the customer and
charge his account with the amount paid.
For e.g. if a customer wants to be able to reserve one seat he will pay the desk clerk
at the cinema 25birr (Amount of one seat). The desk clerk will then make sure the
customer has an account in the system by his username and will make use of the credit
sale functionality to charge his account with 25birr. In due course this customer will be
able to reserve one seat any day of the week.
The only drawback this approach has is that the customer has to be physically
present at the cinema to obtain a reservation credit. But since the customer will be
present to watch a certain movie, all that is expected of him is to plan ahead and buy a
reservation credit during the times he comes to watch a movie.
Customer’s Activities
 Customers will be able to register for online accounts
 Customers will be able to reserve seats any day of the week as well as being
able to cancel these reservations
 Customers will be able to create as well as participate on different discussion
topics
 Customers will be able to rate movies
 Customers will be able to vote on different issues
 Customers will be able to view news releases, movie schedules as well as
updates on currently showing and upcoming movies
 Customer’s will be able to purchase credit to enable them to reserve seats
online
Administrator’s Activities
 Administrators will feed the time schedule and the viewing hall of films to be
shown to the system on a weekly basis
 Administrators will post all movies that are showing so that users will be able
to rate them
 Administrators will make votes available so that users can give their opinions.
 Administrators will manage News releases shown to customers
 Administrators will manage Forum categories
 Administrator’s will be able to generate reports concerning reservation and
desk clerks activities
Global Administrator’s Activities
 The Global Administrator is capable of carrying out all of the Administrator’s

tasks
 The Global Administrator manages the accounts of all the employees
Desk Clerk #1’s Activities
 The desk clerk will reserve seats and sell tickets
Desk Clerk #2’s Activities
 The desk clerk will charge the accounts of customers so that may be able to
reserve seats online
 The desk clerk will carry out reservation confirmation activities.
Activities inherent in all human actors
 The actor logins to the system
System’s Activities
 The system will keep track of the clerk’s activity as log information
 The system will keep track of the customer’s reservation activities as log
information
2. 6. 3N O N -F U N C T I O N A L R E Q U I R E M E N T S
2.6.3.1 Documentation
During the completion of this project three different documents that are essential to
the functioning of the business will be delivered.
USER MANUAL DOCUMENTATION

 Delivery of the user manual is an essential part of the documentation process as
it is the document where each and every user of the system looks to for guidance. It
serves as a tutorial to all users of the system by giving them a detailed description of
how to work with the system to accomplish different tasks. The final software package
of this project will be utilized by three different user groups and hence three user
manuals per user group should be part of the final deliverable.
CODING DOCUMENTATION
There are a variety of reasons why the final implementation of this project may be
revised. Whether it may be to add additional components or to rectify errors and
exceptional cases, the final software may be revised and eventually modified. In order to
be able to do this any programmer should have an understanding of how the projects’
code works. Therefore a documentation outlining the code and modules coupled with
comments showing what each module performs should be a part of the final
deliverable.
MODELING DOCUMENTATION
A modeling documentation is also another deliverable that is necessary. A
documentation of the different UML models used along the advancement of the project
will prove to be of great use to other programmers and designers wanting to familiarize
themselves with this project for one reason or another.
Plus working and making headway on this project through the use of these UML
models will greatly improve the amount of work that will be done in this short period.
2.6.3.2 Hardware Consideration

The physical specifications of all the hardware that will be utilized during deployment
must be put into consideration bearing in mind the nature of the project. The main
objective of this project is to give customers an online interactive system and the
employees an intranet system. In order to achieve this, a total of 2 server computers; 1
intranet server handling requests from users and one database server should be
present. Furthermore special considerations have to be taken concerning hardware
specifications of these machines in order to ensure maximum performance. An ideal
specification for these servers that puts both performance and cost into consideration is
as follows.
o Intel Core 2 Duo 64-bit 3.2 GHZ

o 16GB of RAM
o Three 200GB fast SCSI hard disk drives (10,000 RPM or faster with caching)
o Fast SCSI RAID Controllers
o Windows Server 2008 Enterprise
o Twisted Pair 32-bit /1GB Ethernet cards
2.6.3.3 Performance Consideration

Performance is a major factor that impacts the user’s choice of whether or not to use
a system. The final software has to perform at a level that every user expects it to. The
nature of this project is one where users expect an alluring interface that draws them in.
But with this goal of having an engaging site, the implementation should not downgrade
the load time. There should be a reasonable compromise with how much visually
graphic the site should be with the level of performance it has to maintain.
The hardware consideration mentioned above also has a high impact on how well the
system performs and as such will be done in the manner specified.
2.6.3.4 Error Handling

Like any piece of software the final implementation of this project will raise error
conditions on some scenarios. There are a variety of conditions in which errors occur.
Whether these errors arise from poor practice by the users of the system or because of
some unhandled event in the code of the software, errors must be controlled in such a
way that the program either exists gracefully or shows the user the type of error raised.
Either way the way the program responds when the error is raised depends on the
severity of the error condition.
In this project we plan to minimize the amount of errors that could arise by following
safe coding practices. Typical error conditions such as buffer overflows, format string
problems and integer range errors can be avoided by simply enhancing the coding
practices we follow. But the main source of errors on many systems is the user. Users of
this system may be the causes of a variety of error conditions. Some users commit
errors because they are simply unaware of certain aspects of the system and others give
rise to error conditions intentionally just to see how the system would react. In any case
errors originating from users will be minimized by reducing the range of choices users
have in carrying out certain transactions and by giving feedback to the users of what
they are doing wrong.
2.6.3.5 Quality Issues

A variety of solutions and practices will be followed to ensure the quality of the
project. The quality considerations taken into account encompass both the hardware
and software aspects of the system. The project will be carried out in such a manner
that in the end the following qualities will be reflected on the project.
Availability
The system will be available to all users 99% of the time. The only time that
availability will be compromised is if and when the site is undergoing modifications.
Modifiability
The coding standards we follow will make sure that the final implementation is easily
modifiable. This fact is ensured as the project follows the standards set by UML.
Fault tolerance Scheme
There is always the possibility of partial data loss on the server due to a variety of
circumstances. Whether it may be the malfunctioning of the disk or disk controller the
system should be able to recover from the data loss that arises. In other words a fault
tolerance scheme that keeps the system up and running regardless of any damage to
the disk storage should be put in place.
A fault tolerance scheme that is ideal for this system is a RAID-5 disk configuration
with a minimum of 3 disks. This ensures that in the case of one disk malfunction the
data on that disk will be recovered using the parity information stored on one disk and
actual data stored on the second disk.
Flexibility
The final software implementation of this project will be a flexible one. The software
will be built in such a way that most of the major functionalities can be accessed from
any interface.
2.6.3.6 Security Issues

This project gives a special emphasis on security. One of the major components it
provides is an online reservation system that deals with credit balances. Hence any
security compromise can have a potentially devastating effect on the business.
In order to better protect from any hacking attacks measures will be taken in writing
the underlying code to minimize the chances of an intrusion. Some of the potent attacks
like SQL injection, hidden URLs and a range of other spells can be avoided just by
following safe coding practices. The fact that customers will be asked to login before
carrying out any transactions is another security measure that provides more protection
to the system. Firewalls and recently updated virus protection is also another major
protection measure that ensures that the users data is safe from prying eyes.
2.7 ACTORS INVOLVED

There are six different actors that are directly involved with the system.
1) Customers ->The Customers of the business access the system online and carry
out various transactions.
2) Administrator ->The Administrator is in charge with all the site’s content
management aspects.
3) Global Administrator ->The Global Administrator is able to carry out all of the
Administrator's activities, but is also capable of managing the accounts of all the
employees
4) Desk Clerk #1 ->Makes use of this system to carry out reservation and ticket sales
transactions.
5) Desk Clerk #2->Makes use of the system to carry out credit sales and reservation
verification.
6) The System ->The System keeps track of keeping track of log information
concerning the activities of the desk clerks and the Customers.
2.8 SCENARIOS
Scenario is a concrete, focused, informal description of a single feature of the system
from the point of a single actor view. It is narrative description of what people do and
experience as they try to make use of computer systems and applications .
Scenario Name Login(Successful)

Participating Actor Tewodros: Administrator, Genet: Desk
Clerk #1, Marta: Desk Clerk #2,Dagim:
Customer, Samuel: Global Administrator
Flow of Events 1. The actor types the website’s URL
on his/her browser
2. The Home page of the system is
displayed
3. The actor inputs his/her user name
and password into The Login Form.
4. The system checks the validity of
the actor’s input.
5. The actor is logged in to the system
Table 2.1 A Scenario for Login (Successful).
Scenario Name Login(Unsuccessful)

Participating Actor Tewodros: Administrator, Genet: Desk
Clerk #1, Marta: Desk Clerk #2,Dagim:
Customer, Samuel: Global Administrator
Flow of Events 1. The actor types the website’s URL
on his/her browser
2. The Home page of the system is
displayed
3. The actor inputs his/her user name
and password into The Login Form.
4. The system checks the validity of
the actor’s input.
5. The actor is directed back to the
home page and is also presented
with an error message
Table 2.2 A Scenario for Login (Unsuccessful).
Scenario Name Feed Schedule

Participating Actor Tewodros: Administrator, Samuel: Global
Administrator
Flow of Events 1) The actor clicks on the schedule menu
on the home page
2) The actor is directed to the Schedule
Page
3) The actor clicks on the New Schedule
button on the Schedule Page
4) The actor is redirected to the Feed
Schedule Page.
5) The actor inserts the date the schedule
is associated with
6) The actor then inserts the time
schedule of each movie that will be
shown that day. He Enters
6.1) The Movie’s start time
6.2) The Movie’s Ending Time
6.3) The Title of the movie
6.4) The auditorium number where
the movie will be shown
7) The system checks if there are any
clashing time frames of the different
movies that will be shown in a certain
auditorium
7.1) If there are The actor will be
informed of the error
7.2) If there isn’t the system will
show The actor a message
stating the success of the
transaction
Table 2.3 A Scenario for Feed Schedule.
Scenario Name Modify Schedule
Administrator
Flow of Events 1) The actor clicks on the Schedule
Menu on the home page
2) The actor is directed to the
schedule page
3) The actor selects the date where
the schedule will be modified
4) The actor is redirected to the
modify schedule page.
5) The actor will edit the movie
schedule he so chooses and will
submit the new schedule
6) The actor is faced with a
confirmation dialog asking him to
proceed with the modification
7) The system saves the modification
changes
Table 2.4 A Scenario for Modify Schedule.
Scenario Name Delete Schedule
Administrator
Flow of Events 1) The actor clicks on the Schedule
Menu on the home page
schedule page
3) The actor selects the date where
the entire schedule will be removed
4) The actor clicks on the Delete
Schedule button
5) The actor is shown a confirmation
dialog asking him to proceed with
the deletion
6) The actor clicks on the delete
button once again.
7) The system deletes the entire
schedule
Table 2.5 A Scenario for Delete Schedule.
Scenario Name Feed News

Administrator
Flow of Events 1) The actor clicks on the News
menu on the Home Page
2) The actor is directed to the News
page
3) The actor clicks on the “Feed
News” button
4) The actor is directed to the “Feed
News” Page
5) The actor inserts the topic of the
news to be posted as well as the
body of the news.
6) The actor clicks the submit button.
7) The System saves the inserted
news.
Table 2.6 A Scenario for Feed News.
Scenario Name Modify News
Administrator
Flow of Events 1) The actor clicks on the News Menu
of the Home Page
Page
3) The actor sifts through all the news
and clicks the corresponding modify
button of the news he wants to
modify
4) The actor is directed to the modify
page where he sees the news post
he wants to modify.
5) The actor edits the news segment
6) The actor clicks on the submit
button.
Page
Table 2.7 A Scenario for Modify News.
Scenario Name Delete News

Administrator
Flow of Events 1) The actor clicks on the News
menu on the Home Page
page
3) The actor sifts through all the
news and clicks the corresponding
delete button of the news he
wants to delete
the deletion
button once again
6) The system deletes the news piece
Table 2.8 A Scenario for Delete News.
Scenario Name Feed Vote
Administrator
Flow of Events 1) The actor clicks on the “Voting”
Menu on the Home Page
2) The actor is directed to the “Voting”
Page
3) The actor clicks on the New Vote
button
4) The actor is directed to the New
Vote page
5) The actor inserts the voting Topic as
well as voting choices and submits
the forum
6) The actor is directed to “Voting”
Page
Table 2.9 A Scenario for Feed Vote.
Scenario Name Modify Vote

Administrator
Page
3) The actor clicks on the Modify Vote
button
4) The actor is directed to the Modify
Vote Page
5) The actor performs modification on
the vote and clicks the Submit
button.
6) The actor is directed back to the
“Voting” Page
Table 2.10 A Scenario for Modify Vote.
Scenario Name Delete Vote
Administrator
Page
3) The actor selects the row he wants
to remove from the table of current
votes
4) The actor clicks the Delete Vote
button
the deletion
6) The actor clicks the delete button
once again
7) The system deletes the voting topic
Table 2.11 A Scenario for Delete Vote.
Scenario Name Feed Movie

Administrator
Flow Events 1) The actor clicks on the Movies
2) The actor is directed to the Movies
Page
3) The actor clicks on the New Movie
Button
Movie Page
5) The actor inserts the Movie Title,
description as well as its image and
clicks on the submit button
Movies Page
Table 2.12 A Scenario for Feed Movie.
Scenario Name Remove from Movie List
Administrator
Flow of Events 1) The actor clicks on the Movies
2) The actor is directed to the Movies
Page
3) The actor sifts through all the
Movies that are available for rating
and clicks the check box of the
movie he wants to remove
button
the deletion
6) The actor clicks the delete button
once again
7) The Movie is effectively removed
from the Movies List
Table 2.13 A Scenario for Remove from Movie List.
Scenario Name Create Employee Account

Participating Actor Samuel: Global Administrator
Flow of Events 1) Samuel clicks on the Employee
Account Menu on the Home Page
2) Samuel is directed to the Employee
Account Page
3) Samuel clicks on the New Account
Page
4) Samuel is directed to the New
Account Page
5) Samuel inserts the User Name and
Password of the Employee and
clicks on the submit button.
6) Samuel is shown a dialog showing
him the success of the transaction
7) Samuel is directed back to the
Employee Account Page
Table 2.14 A Scenario for Create Employee Account.
Scenario Name Modify Employee Account
Account Page
3) Samuel sifts through the employee
accounts and clicks on the check
box corresponding to the account
he wants to modify
4) Samuel clicks on the Modify button
5) Samuel is directed to the Modify
Account Page
6) Samuel inserts the new account
information and clicks the submit
button
7) Samuel is shown a dialog showing
him the success of the transaction
8) Samuel is directed back to the
Employee Account Page
Table 2.15 A Scenario for Modify Employee Account.
Scenario Name Delete Employee Account
Account Page
3) Samuel sifts through the employee
accounts and clicks on the check
box corresponding to the account
he wants to Delete
4) Samuel clicks on the Delete button
5) Samuel is shown a confirmation
the deletion
6) Samuel clicks the delete button
once again
7) The Account is effectively removed
from the system
Table 2.16 A Scenario for Delete Employee Account.
Scenario Name Feed Forum

Administrator
Flow of Events 1) The actor clicks on the Forum link
on the Home Page
2) The actor is directed to the Forum
page
3) The actor clicks on the New Forum
button
Forum Page
5) The actor inserts the Forum Name
and description and clicks the
Submit button
6) The actor is shown a dialog that
states the success of the transaction
Forum Page
Table 2.17 A Scenario for Feed Forum.
Scenario Name Modify Forum
Administrator
Flow of Events 1) The actor clicks on the Forum Menu
on the Home Page
Page
3) The actor sifts through the forum’s
and clicks on the forum of his choice
and clicks on the corresponding
check box
4) The actor clicks on the modify
button
5) The actor is directed to the Modify
Forum Page
6) The actor edits the details of the
Forum and clicks the Submit button.
7) The actor is shown a dialog that
states the success of the transaction
Forum Page
Table 2.18 A Scenario for Modify Forum.
Scenario Name Delete Forum
Administrator
Flow of Events 1) The actor clicks on the Forum Menu
on the Home Page
Page
3) The actor sifts through the forum’s
and clicks on the forum of his choice
and clicks on the corresponding
check box
button
the deletion
button once again
7) The Forum is effectively deleted
from the system
Table 2.19 A Scenario for Delete Forum.
Scenario Name View “Clerk Activity” Report
Administrator
Flow of Events 1) The actor clicks on the Report Menu
on the Home Page
2) The actor clicks on the “Clerk’s
Activity” Submenu
3) The actor is directed to the Clerk
Report page
4) The actor clicks on the User Name
of the clerk selling tickets with the
date and clicks on the submit
button
5) The actor is shown all ticket sales
transactions conducted by the clerk
6) The actor clicks on the print button
7) The actor clicks on the return
button
Home Page
Table 2.20 A Scenario for View “Clerk Activity” Report.
Scenario Name View “Reservation & Sales” Report
Administrator
Flow of Events 1) The actor clicks on the Report Menu
on the Home Page
2) The actor clicks on the “Reservation
& Sales” Report Submenu
Reservation and Sales Report Page
4) The actor enters the date for which
the report should be generated and
clicks on the Submit button
5) The actor is shown a page of all the
sale transactions conducted that
day
6) The actor clicks on the print button
7) The actor clicks on the return
button
Home Page
Table 2.21 A Scenario for View “Reservation & Sales” Report.
Scenario Name Sell Ticket

Participating Actor Genet: Desk Clerk #1
Flow of Events 1) Genet Clicks on the Reservation and
Ticketing Menu on the Home Page
2) Genet is directed to the Reservation
and Ticketing Page
3) Genet Selects the Auditorium and
the time frame for the transaction
4) Genet is directed to the
corresponding Auditorium Page
5) Genet clicks on the seat number the
user asked for and clicks on the
reserve button.
6) The System prints a ticket
pertaining to the seats reserved.
7) Genet is directed back to the
Reservation and Ticketing Page
Table 2.22 A Scenario for Sell Ticket.
Scenario Name Sell Credit
Participating Actor Marta: Desk Clerk #2
Flow of Events 1) Marta clicks on the Sell Credit Menu
on the home page
2) Marta is directed to the Selling
Credit page.
3) Marta inserts the User Name of the
user buying the credit as well as the
amount of credit and clicks on the
submit button
4) Marta is shown a confirmation
dialog telling her that the
transaction was successful
5) Marta is directed back to the Selling
Credit
Table 2.23 A Scenario for Sell Credit.
Scenario Name Reservation Verification

Participating Actor Marta: Desk Clerk #2
Flow of Events 1) Marta clicks on the Reservation
Verification Menu on the Home
Page
2) Marta is directed to the Reservation
Verification page
3) Marta inserts the reservation
number of the customer and clicks
on the submit button
4) Marta is redirected to the Reserved
Seats page where she is shown the
seats the customer reserved
5) Marta clicks on the print button to
print the tickets the for the seats
the user reserved
6) Marta is shown a confirmation
dialog telling her that the
transaction was successful
7) Marta is directed back to the
Reservation verification page.
Table 2.24 A Scenario for Reservation Verification.
Scenario Name  Registration
 Participating Actor  Dagim: Customer
 Flow of events 1) Dagim clicks on the register link on
the home page.
2) Dagim is directed to the registration
Page
3) Dagim enters the following
information:
 E-mail Address
 Password
 First Name
 Last Name
 Gender
 Tel. Number
 Then presses the register button.
4) Dagim is directed back to the home
page
Table 2.25 A Scenario for Registration.
 Scenario Name  Reservation
 Flow of events 1) Dagim clicks on the reserve link on
the home page.
2) Dagim is directed to the Reservation
Page
3) Dagim selects the date where he
wants to come and see
4) Dagim selects the Movie he wants
to see, the time and in which
Auditorium he wants to see it and
clicks on the reserve seat button.
5) Dagim is directed to the Cinema
Layout Page
6) Dagim checks the availability of
seats and selects the seat/s he
wants to reserve and clicks on the
reserve button
7) Dagim is directed to a page showing
him the success of his transaction
and is given a reservation number
which he uses to get a ticket.
8) Dagim receives an e-mail containing
his Seat No., Movie Name, Date, the
Auditorium number and the
reservation number
9) Dagim is directed back to the
Reservation Page.
Table 2.26 A Scenario for Reservation.
 Scenario Name  Cancel Reservation
 Flow of events 1) Dagim clicks on the reserve link on
the home page.
2) Dagim is directed to the Reservation
Page
3) Dagim clicks on the Cancel
Reservation Menu.
4) Dagim is directed to the Cancel
Reservation Page.
5) Dagim sifts through the seats
reserved and clicks on the check
box corresponding to the
reservation he wants to cancel
6) Dagim clicks on the Cancel
Reservation button
7) Dagim is shown a confirmation
the deletion
8) Dagim clicks on the delete button
9) The reservation is effectively
removed from the system
10) Dagim is directed back to the Cancel
Reservation page
Table 2.27 A Scenario for Cancel Reservation.
 Scenario Name  Vote on Topic

 Flow of events 1) Dagim clicks on the Rating & Voting
Link on the Home Page
2) Dagim is directed to the Voting and
Rating Page
3) Dagim sifts through the voting topics
and submits his vote on a specific
topic by selecting his choice and
clicking submit
4) Dagim is shown the current
percentage of votes on the topic he
voted on
Table 2.28 A Scenario for Vote on Topic.
 Scenario Name  Rate Movie
 Flow of events 1) Dagim clicks on the Voting & Rating
link on the Home Page
2) Dagim is directed to the Voting and
Rating Page
3) Dagim sifts through the Movies
available for rating and gives a
rating to the movie he desires
Table 2.29 A Scenario for Rate Movie.
Scenario Name Create Forum Discussion

Participating Actor Dagim: Customer
Flow of Events 1) Dagim clicks on the Forum he so
chooses on the Forums Page
2) Dagim is directed to the Discussions
Page
3) Dagim clicks on the “Create
Discussion” Link.
4) Dagim is directed to the Create
Discussions Page
5) Dagim inserts the discussion topic
and the forum he chooses and clicks
6) Dagim is directed back to the
Discussions Page where he can see
his newly created discussion topic.
Table 2.30 A Scenario for Create Forum Discussion.
Scenario Name Create Discussion Post
Participating Actor Dagim: Customer
Flow of Events 1) Dagim clicks on the Discussion Topic
he so chooses on the Discussions
Page
2) Dagim is directed to the Posts page
3) Dagim clicks on the “Create Post”
link
4) Dagim is directed to the create post
page
5) Dagim inserts the posts Message
and clicks the submit button
6) Dagim is directed back to the Posts
page where he can see his newly
created post
Table 2.31 A Scenario for Create Discussion Post.
 Scenario Name  View Schedule

 Flow of events 1) Dagim clicks on the View Schedule
2) Dagim is directed to the Schedules
Page
3) Dagim clicks on the date of which
he wants to see the schedule
4) Dagim is shown the schedule of the
time schedule of the movies that
are seen that day
Table 2.32 A Scenario for View Schedule.
 Scenario Name  View Contact us
 Participating Actor  Dagim: User
 Flow of events 1) Dagim clicks on the Contact Us link
on the Home Page
2) Dagim is directed to the Contact Us
page.
3) Dagim provides his email, topic and
he writes the message and clicks
the Submit button.
4) The system sends an email to the
website Administrator that contains
Dagim’s topic, email address, and
the message.
5) Dagim is directed back to the Home
Page
Table 2.33 A Scenario for Viewing Contact us.
2.9 USE CASE DIAGRAM
A use case specifies the behavior of a system or a part of a system and is a description
of a set of sequences of actions, including variants that a system performs to yield an
observable result of value to an actor.
The Actors of this system were identified by grouping users of the systems in terms of
required behaviors they have to exhibit in order to perform various functions.
The use cases were identified by considering the primary ways in which each actors
interacts with the various elements of the system. We also took into consideration
interactions that change the state of the system.
Figure 2. 6 Use Case Diagram (a).
Figure 2. 7 Use Case Diagram (b).
Figure 2. 8 Diagram for Manage Schedule
Figure 2. 9 A Diagram for Manage News
Figure 2. 10 A Diagram for Manage Movie

Figure 2. 11 A Diagram for Manage Votes.
Figure 2. 12 A Diagram for Manage Forum Category
Figure 2. 13 A Diagram for Manage Employee Account.

2.10 USE CASE TEXT DESCRIPTION
A use case is an abstraction that describes all possible scenarios involving the
described functionality. Its focus is no completeness. To describe a use case we used a
use case text description. The use case should be described using natural language. This
enables developers to use them for communicating with the client and the users who
generally do not have an extensive knowledge of software engineering notations. The
following are the description of the main use cases. The use text description for Online
Cinematic Reservation and Community System is as follows:
Use Case name Log in
Description This functionality allows the actor to gain access to the system
Participating Actors Administrator, Customer, Desk clerk #1, Desk clerk #2, Global
Administrator
Entry Condition  The Actor types the URL of the Home Page on
the browser
Flow of Event 1) The Actor is directed to the Login Home Page of the
system
2) The Actor fills the user name and Password fields on
the input form.
3) The Actor presses the “Log in” button or the return
key.
4) The system checks the validity of the user name and
password then
5) It will display the desired page according to their
privilege.
Alternate Flow (If the actor is not a valid user)
1) Steps 1-4
2) The system directs the actor back to the login and
informs him the error committed
Exit Condition The Actor is logged into the System
Special Requirement The Actor is given a maximum of three trials to login
Table 2.34 A Use Case Diagram for Login.
Use Case Name Feed Schedule

Description This functionality allows the actor the schedule of movies to
be shown on any day of the year
Participating Actors Administrator, Global Administrator
Entry Condition The actor initiates the “Feed Schedule” functionality.
Flow of Events 1) The System directs the actor to the “Feed Schedule”
page
2) The actor fills the date the movies are to be shown as
well as the following information for every movie to be
seen that day
 The Movie title
 The Movie’s start time
 The Movie’s Ending Time
 The Title of the movie
 The auditorium number
3) The actor clicks on the submit button
4) The system checks if there are any clashing time
frames that have occurred when the actor inserted
time intervals
5) If there aren’t any the system inserts the schedule data
in the database.
Alternate Flow (If there are clashing time frames on a certain schedule)
1) Steps 1-4
2) The system shows the actor an error dialog
Exit Condition The system displays a confirmation dialog showing the
success of the transaction
Special Requirement The system should handle unfilled entries
Table 2.35 A Use Case Diagram for Feed Schedule.

Use case Name Modify Schedule
Description This functionality allows the actor to make changes
concerning the time or date or the auditorium number a
movie is shown
Entry Condition The actor initiates the “Schedule” functionality.
Flow of Events 1) The actor sifts through the schedule dates available
clicks on the check box of the corresponding schedule
he wants to modify and clicks the “Modify” button
2) The System directs the actor to the “Modify Schedule”
page.
3) The actor will edit parameters like the Movie name,
starting time, ending time, and Auditorium number &
click on the submit button.
4) The system checks if there are any clashing time
frames that have occurred when the actor was
inserting time intervals
5) If there aren’t any the system modifies the schedule
data in the database
Alternate Flow (If there are clashing time frames on a certain schedule)
1) Steps 1-4
successful nature of the transaction
Table 2.36 A Use Case Diagram for Modify Schedule.

Use case Name Delete Schedule
Description This functionality allows the actor to remove a schedule
pertaining to a certain day of the week
Entry Condition The actor initiates the “Schedule” functionality.
Flow of Events 1) The actor sifts through the schedule dates and clicks the
check box corresponding to the schedule date he wants
to remove
2) The actor clicks on the delete button
3) The system shows the actor a confirmation dialog asking
him to proceed with the transaction
4) The actor clicks on the delete button once again and the
system effectively removes the schedule pertaining to
that date from the database.
Alternate Flow (If the actor decides not to delete the schedule)
1) Steps 1-3
2) The actor clicks on the cancel button to cancel the
transaction
Special Requirement None
Table 2.37 A Use Case Diagram for Delete Schedule.

Use Case Name Feed News
Description This functionality enables the actor to post film news on the
site
Entry Condition The actor initiates the “Feed News” functionality
Flow of Events 1) The system directs the actor to the “Feed News” Page.
2) The actor inserts the News topic, News description and
News Image(Optional) and clicks on the submit button
3) The system checks if there is already a news post with
the title specified
4) If there isn’t the system inserts the News data into the
database
Alternate Flow (If there is a News Topic with the title specified)
1) Steps 1-3
2) The system displays an error dialog
Exit Condition The system shows a dialog displaying the successful nature of
the transaction
Table 2.38 A Use Case Diagram for Feed News.

Use case Name Modify News
Description This functionality allows the actor to make changes to News
Posts
Entry Condition The actor initiates the “News” functionality.
Flow of Events 1) The actor sifts through the news posts available clicks
the check box corresponding to the News post he
wants to modify
2) The actor clicks the Modify button
3) The System directs the actor to the “Modify News”
page.
4) The system populates the fields of the News post to be
modified
5) The actor will edit parameters like News title, body or
image& click on the submit button.
6) The system checks if there is already a news post with
the title specified
7) If there isn’t the system modifies the News data in the
database
Alternate Flow (If there is already a News Post with the same title)
1) Steps 1-6
Table 2.39 A Use Case Diagram for Modify News.

Use case Name Delete News
Description This functionality allows the actor to remove a News post
from the system
Entry Condition The actor initiates the “News” functionality.
Flow of Events 1) The actor sifts through the News posts and clicks the
check box corresponding to the post he wants to
remove
3) The system shows the actor a confirmation dialog
asking him to proceed with the transaction
4) The actor clicks on the delete button once again and
the system effectively removes the News post from the
database.
Alternate Flow (If the actor decides not to delete the schedule)
1) Steps 1-3
transaction
Table 2.40 A Use Case Diagram for Delete News.

Use Case Name Feed Vote
Description This functionality enables the actor to post voting topics with
which customers can give opinions on various issues
Entry Condition The actor initiates the “Feed Vote” functionality
Flow of Events 1) The system directs the actor to the “Feed Vote” Page.
2) The actor inserts the Vote topic and Voting parameters
and clicks on the submit button
3) The system checks if there is already a vote topic with
the title specified
4) If there isn’t the system inserts the Vote into the
database
Alternate Flow (If there is a Vote Topic with the title specified)
1) Steps 1-3
the transaction
Table 2.41 A Use Case Diagram for Feed Vote.

Use case Name Modify Vote
Description This functionality allows the actor to make changes to Voting
Topics
Entry Condition The actor initiates the “Vote” functionality.
Flow of Events 1) The actor sifts through the votes available clicks the
check box corresponding to the Vote he wants to
modify
2) The actor clicks the Modify button
3) The System directs the actor to the “Modify Vote”
page.
4) The system populates the fields of the vote to be
modified
5) The actor edits parameters like the Vote title or voting
parameters
6) The system checks if there is already a Vote with the
title specified
7) If there isn’t the system modifies the Vote data in the
database
Alternate Flow (If there is already a Vote topic with the same title)
1) Steps 1-6
Table 2.42 A Use Case Diagram for Modify Vote.

Use case Name Delete Vote
Description This functionality allows the actor to remove a Voting Topic
from the system
Entry Condition The actor initiates the “Vote” functionality.
Flow of Events 1) The actor sifts through the Voting topics and clicks the
check box corresponding to the topic he wants to
remove
the system effectively removes the Voting topic from
the database.
Alternate Flow (If the actor decides not to delete the vote)
1) Steps 1-3
transaction
Table 2.43 A Use Case Diagram for Delete Vote.

Use Case Name Feed Movie
Description This functionality enables the actor to post Movies that will be
rated and incorporated as part of the schedule
Entry Condition The actor initiates the “Feed Movie” functionality
Flow of Events 1) The system directs the actor to the “Feed Movie” Page.
2) The actor inserts the Movie title, description and image
of the movie and clicks on the submit button
3) The system checks if there is already a Movie with the
title specified
4) If there isn’t the system inserts the Movie into the
database
Alternate Flow (If there is a Movie with the title specified)
1) Steps 1-3
the transaction
Table 2.44 A Use Case Diagram for Feed Movie.

Use case Name Modify Movie
Description This functionality allows the actor to make changes to Movie
details of showing movies
Entry Condition The actor initiates the “Movie” functionality.
Flow of Events 1) The actor sifts through the movies available clicks the
check box corresponding to the movie he wants to
modify
2) The actor clicks the “modify” button
3) The System directs the actor to the “Modify Movie”
page.
4) The system populates the fields of the movie to be
modified
5) The actor will edit parameters like the movie title,
description or image
6) The system checks if there is already a Movie with the
title specified
7) If there isn’t the system modifies the Movie data in the
database
Alternate Flow (If there is already a Movie with the same title)
1) Steps 1-6
Table 2.45 A Use Case Diagram for Modify Movie.

Use case Name Delete Movie
Description This functionality allows the actor to remove a details of a film
from the system
Entry Condition The actor initiates the “Movie” functionality.
Flow of Events 1) The actor sifts through the Movies and clicks the check
box corresponding to the topic he wants to remove
the system effectively removes the Movie description
from the database.
Alternate Flow (If the actor decides not to delete the Movie)
1) Steps 1-3
transaction
Table 2.46 A Use Case Diagram for Delete Movie.

Use case Name Ticket Sale
Description This functionality allows the desk clerk to perform reservation
and ticket sale transactions for a customer
Participating Actor Desk Clerk #1
Entry Condition The desk clerk initiates the Ticket Sale functionality
Flow of Event 1) The system will direct the clerk to the Movie Schedule
page.
2) The actor will select the time, movie, Auditorium
number.
3) The System validates whether there are any available
seats
4) If there are the system activates the corresponding
Auditorium Page
5) The system displays all the available seats and marks
the reserved seats.
6) The desk clerk selects the seats the customer wants to
settle on and clicks on the Reserve button
7) The system once again checks the availability of the
seat before completing the transaction
8) If the seats still remains free the System marks the
seats as reserved and makes changes in the database
Alternate Flow (If all the seats in the cinema are occupied)
1) Steps 1-3
2) The system shows the desk clerk a dialog displaying the
fact that all the seats are occupied
Alternate Flow #2 (If the seats the desk clerk marked are already reserved)
1) Steps 1-7
2) The system shows the desk clerk a dialog displaying
the fact that the seat/s she marked are occupied
Exit Condition The system prints the ticket/s.
Table 2.47 A Use Case Diagram for Ticket Sales.

Use Case name Credit Sale
Description This functionality allows the desk clerk to charge the credit
account for any registered customer so that they may be able
to accomplish online reservations
Entry Condition  The desk clerk initiates the Credit Sale
functionality
Flow of Event 1) The System directs the clerk to the “Credit Sales” page.
2) The Desk Clerk will type the User Name of the
customer who requested the credit with the amount of
credit requested.
3) The System checks whether the account is available in
the system
4) If the user exists the amount of credit specified will be
supplemented to his/her account
Alternate Flow (If the customer is not a registered user of the system)
1) Steps 1-3
2) If the User Name is non-existent such a message will be
shown to the desk clerk
Exit Condition The system displays a dialog showing the successful nature of
the transaction
Special Requirement The customer purchasing the credit has to be a registered
user of the system
Table 2.48 A Use Case Diagram for Credit Sale.

Use Case name Reservation Verification
Description This functionality allows the desk clerk to verify whether the
customer has indeed reserved a seat online
Entry Condition The desk clerk activates the Reservation Verification
functionality
Flow of Event 1) The system directs the clerk to the Reservation
Verification page
2) The actor will type the reservation verification number.
3) The system will verify whether a reservation identified
by the reservation number exists
4) If the reservation number is able to identify an actual
reservation the system will notify the clerk the seats
reserved, removes the reservation number from the
database then prints a ticket to the customer.
Alternate Flow (If the reservation number provided by the customer doesn’t
identify an actual reservation)
1) Steps 1-3
2) If the reservation number doesn’t identify an actual
reservation the system will notify the clerk such a
message
Exit Condition The system shows a confirmation dialog of the successful
nature of the transaction
Table 2.49 A Use Case Diagram for Reservation Verification.

Use Case Name Registration
Description This functionality allows the customer to be a registered
member of the system
Participating Actor Customer
Entry Condition The Customer activates the register functionality
Flow of Events 1) The System directs the actor to the Registration page
2) The Customer inputs the following information
 User Name
 E-mail Address
 Password
 First Name
 Last Name
 Gender
 Tel. Number
 and clicks the register button
3) The System checks the validity of the customer’s input
4) If the customer’s input is correct the System shows the
customer a confirmation and logs him/her in.
5) The system checks whether there is already a user
registered with the same username.
6) If there isn’t the system will insert the account
information to the database
 4.1)
 4.2) If the customer’s input is invalid the System
shows the customer a message of what he/she
did wrong
Alternate Flow (If the customer’s input is not valid)
1) Steps 1-3
2) The customer is shown a message of what error he
committed.
Alternate Flow #2 (If there is a customer registered with the same username)
1) Steps 1-5
2) The customer is shown an error dialog telling him/her
to change their username.
Exit Condition The customer is logged in to the system with the appropriate
credentials.
Table 2.50 A Use Case Diagram for Registration.

Use Case name Online Reservation
Description This functionality allows the customer to reserve seats online
Entry Condition The customer activates the reservation functionality
Flow of Event 1) The system will direct the customer to the Reserve seat
page.
2) The system checks if the customer has any credit that
would allow him/her to carry out the transaction
3) If the customer has any credit the system will load the
reservation schedule page
4) The customer selects the movie he/she wants to see as
well as the date and the Auditorium number and clicks
5) The system will direct the customer to the
corresponding Auditorium Page.
6) The system displays all the available seats and marks
the reserved seats.
7) The customer selects the seat/s he/she wants to
reserve
8) The system calculates if the customer’s credit balance
is enough to complete the transaction
9) The system checks if the customer had made any
reservations on the same date and time frame in
another Auditorium
10) If the customer fulfills both requirements the system
will reserve the selected seats, deduct the total cost of
entry from the customer’s credit, generate a
reservation number for the customer which is later
used for verification, and sends this number through
email to the customer.
Alternate Flow (If the customer doesn’t have any credit)
1) Steps 1-2
2) The system displays a dialog of “Insufficient funds”
Alternate Flow #2 (If the customer doesn’t have enough credit to reserve the
number of seats he has chosen)
1) Steps 1-8
2) The system displays a dialog of “Insufficient funds”
Alternate Flow #3.1 (If the customer had made a reservation on same date and
time frame in another auditorium and wants to proceed with
the transaction)
1) Steps 1-9
2) The system shows a confirmation dialog asking the
customer to proceed with the transaction
3) The actor clicks the “Yes” button
4) Step 10
Alternate Flow #3.2 (If the customer had made a reservation on same date and
time frame in another auditorium and wants to cancel the
transaction)
1) Steps 1-9
2) The system shows a confirmation dialog asking the
customer to proceed with the transaction
3) The actor clicks the “No” button
4) Step 10
Exit Condition The system shows a confirmation dialog showing the
Special Requirement The customer has to have a credit balance amount necessary
to complete a transaction
Table 2.51 A Use Case Diagram for online Reservation.
Use Case name Cancel Reservation

Description This functionality allows the customer to cancel a reservation
he had already made
Entry Condition The customer activates the “Cancel Reservation” functionality
Flow of Event 1) The system will direct the customer to the cancel
reservation page.
2) The system will check whether or not the user already
had reserved a seat online then
3) If the customer has made a reservation but hasn’t
processed (had a ticket printed) the reservation, the
system will show all the details of all the reserved seats
along with the date.
4) The customer sifts through all the seats reserved and
clicks the check box corresponding to the seat he
wants to remove from the reserved list.
5) The customer clicks on the “cancel reservation” button
Alternate Flow (If the customer hasn’t previously made a reservation)
1) Steps 1-2
2) The system shows a dialog showing a “No Reservation
Made” message
Exit Condition The system shows a confirmation dialog displaying the
Table 2.52 A Use Case Diagram for Cancel Reservation.
Use Case name Vote Topic

Description This functionality allows the customer to cast a vote on a
topic posted by the administrator
Entry Condition The customer activates the “Voting & Rating” functionality
Flow of Event 1) The customer is directed to the “Voting & Rating” page
2) The system will check the topics that the customer
already voted on and just displays their percentage and
the rest to be voted on
3) The customer casts his vote on one of the available
voting topics
4) The system stores his vote.
Exit Condition The system calculates and displays the voting percentage
given by all the users
Special Requirement The customer will not be able to vote if there aren’t any
voting topics available
Table 2.53 A Use Case Diagram for Vote Topic.
Use Case name Rate Movie

Description This functionality allows the customer to give a movie an
appropriate rating
Entry Condition The customer activates the “Voting & Rating” functionality
Flow of Event 1) The system will direct the customer to the “Voting
&Rating” page.
2) If the customer has already given a rating to a movie it
will be displayed
3) If he hasn’t the rating topic will be displayed in such a
way that the customer may be able to cast a vote on it
4) The customer rates a movie from those available
5) The system stores the rating in the database
Exit Condition The system displays the rating given by the customer
Special Requirement The customer will not be able to submit ratings if there aren’t
any Rating topics available
Table 2.54 A Use Case Diagram for Rate Movie.
Use Case name View Schedule
Description This functionality allows the customer to view the schedule of

the movies currently showing
Entry Condition The actor activates the view schedule functionality
Flow of Event 1) The system will direct the user to the Schedule page.
2) The customer will view the schedule of upcoming dates
Exit Condition  The customer clicks a link to visit some other
functionality
Table 2.55 A Use Case Diagram for View Schedule.
Use Case name View Now showing

Description This functionality allows the customer to view the current
movie being shown
Participating Actors Customer
Entry Condition The actor activates the “Now Showing” functionality.
Flow of Event 1) The system directs the customer to the “Now Showing”
page.
2) The customer views the movies currently showing
Exit Condition The customer clicks a link to visit some other functionality
Special Requirement None.
Table 2.56 A Use Case Diagram for View Now Showing.
Use Case Name Feed Forum Category

Description This functionality enables the actor to create forum categories
in which customers create discussion topics to talk about a
range of issues
Entry Condition The actor initiates the “Feed Forum Category” functionality
Flow of Events 1) The system directs the actor to the Create Forum page.
2) The actor feeds the Category name and description and
clicks “Create Forum” button
3) The System checks whether there is a category already
created with the same name
4) If there isn’t the system saves the changes to the
database
Alternate Flow (If there is a Category with the title specified)
1) Steps 1-3
the transaction
Table 2.57 A Use Case Diagram for Feed Forum Category.
Use case Name Modify Forum Category

Description This functionality allows the actor to make changes to either
the title or description of a specific forum
Entry Condition The actor initiates the “Forum” functionality.
Flow of Events 1) The actor sifts through the categories available clicks
the check box corresponding to the category he wants
to modify
2) The actor clicks the “modify” button
3) The system directs the actor to the modify forum page.
4) The system populates the fields of the category to be
modified
5) The actor selects and changes either the name or
description of the forum and clicks the “Modify Forum”
button.
6) The System checks whether there is a category already
created with the same name
7) The system saves the changes to the database
Alternate Flow (If there is already a category with the title specified)
1) Steps 1-6
Table 2.58 A Use Case Diagram for Modify Forum Category.

Use case Name Delete Forum Category
Description This functionality allows the actor to remove any forum
Entry Condition The actor initiates the “Forum” functionality.
Flow of Events 1) The actor sifts through the forums available clicks on
the corresponding check box of the forum he wants to
remove and clicks Delete Forum link
3) The actor clicks on the delete button once again
4) The system removes the forum from the database
Alternate Flow (If the actor decides not to delete the Category)
1) Steps 1-2
transaction
Table 2.59 A Use Case Diagram for Delete Forum Category.
User Case Name Create Forum Discussion
Description This functionality allows the actor to create discussions topics

in which users can interact through posts
Participating Actor Customer, Administrator, Global Administrator
Entry Condition Customer activates the “Create Forum Discussion”
functionality
Flow of Events 1) The system directs the actor to the “Create Discussion
Forum” Page
2) The actor enters the discussion topic, the topic
description and clicks on the “Create Discussion”
button.
3) The system inserts the data and directs the actor to the
Discussion Page.
Exit Condition The system displays the discussion topic posted by the actor
Special Requirement If no forums exist the actor won’t have ability to carry out the
transaction
Table 2.60 A Use Case Diagram for Create Forum Discussion
User Case Name Create Post
Description This functionality allows the actor to create posts concerning

different discussion topics
Participating Actor Customer, Administrator, Global Administrator
Entry Condition The actor activates the “Create Post” functionality
Flow of Events 1) The system directs the actor to “Create Post” Page.
2) The actor enters the message of the post and enters
Submit button.
3) The system directs the actor to the Posts Page.
Exit Condition The system displays the post created by the actor
Special Requirement If no discussions exist the actor won’t have ability to carry out
the transaction
Table 2.61 A Use Case Diagram for Create Post.
Use Case name View Report

Description This functionality allows the administrator to view reports
concerning reservation and sales activities conducted by the
users of the system
Participating Actor Administrator, Global Administrator
Entry Condition The actor activates the “Report” functionality
Flow of Event 1) The system directs the actor to the “Reports” page
2) The actor activates one of the following functionalities
3.1) The actor clicks on the “Online Reservation
activity” Menu
3.1.1) The system directs the user to the date
page
3.1.2) The actor clicks on the date for which he
wants to see the report
3.1.3) The system directs the actor to the
“Reservation Report” Page.
3.1.4) The actor sifts through the reservation
activities and clicks on the print button
3.2) The actor clicks on the “Clerk Activity” Menu
3.2.1) The system directs the user to the “Identify
Clerk” page
3.2.2) The actor chooses the clerk and the date
for which he wants to see the report
3.2.3) The system directs the actor to the “Clerk
Report” Page
3.2.4) The actor sifts through the clerk’s activities
and clicks on the print button.
Exit Condition The system prints the sales and reservation activity conducted
by the actors
Table 2.62 A Use Case Diagram for View Report.

Use Case Name Create Employee Account
Description This functionality enables the Global administrator to create
accounts for the employees so they may be able to use the
system
Participating Actors Global Administrator
Entry Condition The actor initiates the “Create Account” functionality
Flow of Events 1) The System directs the Administrator to the New
Account Page
2) The Administrator inputs the User Name, Password
and Privilege of the Employee and clicks on the submit
button
3) The System checks if there is already an account with
the username specified
4) If the Account doesn’t exist the System inserts the
account to the database
Alternate Flow (If an account with the specified username already exists)
1) Steps 1-3
the transaction
Table 2.63 A Use Case Diagram for Create Employee Account.

Use case Name Modify Employee Account
Description This functionality allows the Global Administrator to make
changes to the account of a specific user
Entry Condition The actor initiates the “Employee Account” functionality.
Flow of Events 1) The Global Admin. sifts through the accounts available
checks the box corresponding to the Account he wants
to modify
2) The Global Admin. clicks on the modify button
3) The System directs the Administrator to the Modify
Account Page
4) The System populates the fields of the Account to be
modified
5) The Administrator edits the Employees account
information and clicks the submit button
6) The System checks if there is already an account with
the user name specified
7) If the Account doesn’t exist the System saves the
changes made to the database
Alternate Flow (If an account with the specified username already exists)
1) Steps 1-6
Table 2.64 A Use Case Diagram for Modify Employee Account.

Use case Name Delete Employee Account
Description This functionality allows the actor to remove the account of a
specific employee
Entry Condition The actor initiates the “Employee Account” functionality.
Flow of Events 1) The Global Admin. sifts through the Accounts available
checks the box corresponding to the Account he wants
to remove and clicks on the Delete button
2) The System checks whether the account to be deleted
is the actor’s.
3) If the account is different from the one the actor used
to login the System effectively removes the account
from the database.
4) If that isn’t the case the Global Admin. is shown a
confirmation dialog asking him to proceed with the
transaction
5) The Global Admin. Clicks the delete button once again
Alternate Flow (If the account is the same as the one the Administrator used
to login)
1) Steps 1-2
2) The Global Admin. is shown an error dialog displaying
the faulty nature of the transaction
Alternate Flow #2 (If the Administrator decides not to remove the account)
1) Steps 1-4
2) The Administrator clicks on the cancel button
Table 2.65 A Use Case Diagram for Delete Employee Account.

Use case Name Maintain Clerk Log
Description With this functionality the system keeps log information of the
desk clerk’s activity
Participating Actor System
Entry Condition  The Desk Clerk reserves a seat/s for a customers
and clicks on the print ticket button
Flow of Events 1) The System stores the following fields as Log information
 The date & time of the transaction
 The No. of tickets sold on the single transaction
 The Auditorium number
 The price of the transaction
Exit Condition The system successfully stores the log data
Special None
Requirement
Table 2.66 A Use Case Diagram for Maintain Clerk Log.
Use Case Name Maintain Online Reservation Log

Description With this functionality the system keeps log information of the
customers online reservation activities
Participating Actor System
Entry Condition  A customer chooses a seat/s and clicks on the
reserve button
Flow of Events 1) The System stores the following fields as Log information
 The date & time of the transaction
 The No. of seats the customer reserved
 The Auditorium Number
 The credit the system used to carry out the
transaction
Exit Condition  The system successfully stores the log data
Special None
Requirement
Table 2.67 A Use Case Diagram for Maintain Online Reservation Log.
2.10 OBJECT MODEL
Object diagram are used to render a set of object and their relationships as an instance.
An object diagram is an instance of a class diagram. It implies that an object diagram
consist of instances of thing used in a class diagram. . The basic concepts are similar for
class diagrams and object diagrams. Object diagrams also represent the static view of a
system but this static view is a snapshot of the system at a particular moment.
So both diagrams are made of same basic elements but in different form. In class
diagram elements are in abstract form to represent the blue print and in object diagram
the elements are in concrete form to represent the real world object.
2. 10. 1 D A T A D I C T I O N A R Y
Data dictionary is the description of the data flow. Here below we tried to show the
data flow for Online Cinematic Reservation and Community System.
Users=UserName + FName + LName + Gender + DOB + Tel + Password
Customer: -UserName + Email + Password
Movie= MovieName + Description + Image
Schedule= SchId + MovieName + StartTime + EndTime + AudiNo + Date
Vote=VoteTopic + PostDate + VoteParam + TotalVotes
Forum Category=CatName + Description
Credit Balance= CreditId + UserName + CreditBalance
Reservation Log=UserName + MovieName + StartTime + AudiNo + Date
Reservation=ResId + SchId + UserName+ SeatNum + ReservationNum
Employee=UserName + Position + Address
Post=PostId + DiscussionId + Body + CreatedBy + CreatedDate

Discussion=DiscussionId + Topic + CatName + CreatedBy + CreatedDate
Weekly Cost=Day + Price
2. 10. 2 C L A S S D I A G R A M
Class diagram helps to analyze the structure of the system. Class diagrams are the
backbone of almost every object-oriented method including UML. They describe the
static structure of a system. They are drawn by identifying objects in the system. Once
use cases have been consolidated, we start to identify in the system. Once use cases
have been organized, we start to identify the participating objects for each use case. The
participating objects correspond to the main concepts in our system. By examining each
use case we found participating objects correspond to the main concepts in our system.
We also use natural language analysis which is an intuitive set of heuristics for
identifying objects, attributes, and associations from a system specification.
Figure 2.12 A Class Diagram.
2.11 DYNAMIC MODELS

Dynamic model represents the internal behavior of the system using sequence, state
chart diagrams and activity diagram.
2. 11. 1 S E Q U E N C E D I A G R A M
The following diagrams depict the activities the different actors of the system
perform. These diagrams also portray the interactions between the boundary, control
and entity objects that go into each activity sequence.
Figure 2. 14 Sequence Diagram for Log in
Figure 2. 15 Sequence Diagram for feed schedule

Figure 2. 16 Sequence Diagram for Modify Schedule
Figure 2. 17 Sequence Diagram for delete schedule

Figure 2. 18 Sequence diagram for feed news
Figure 2. 19 Sequence diagram for modify news
Figure 2. 20 Sequence diagram for delete news

Figure 2. 21 Sequence diagram for feed vote
Figure 2. 22 Sequence Diagram for Modify Votes
Figure 2. 23 Sequence diagram for delete votes

Figure 2. 24 Sequence diagram for feed movie
Figure 2. 25Sequence Diagram for Modify Movie
Figure 2. 26 Sequence diagram for delete movie

Figure 2. 27 Sequence Diagram for Ticket Sales
Figure 2. 28 Sequence Diagram for Credit Sales

Figure 2. 29 Sequence Diagram for Reservation Verification
Figure 2. 30 Sequence Diagram for Registration

Figure 2. 31 Sequence Diagram for Online Reservation
Figure 2. 32 Sequence Diagram for Cancel Reservation
Figure 2. 33 Sequence Diagram for Vote topic

Figure 2. 34 Sequence Diagram for Rate Movie
Figure 2. 35 Sequence Diagram for View Schedule

Figure 2. 36 Sequence Diagram for View Now Showing
Figure 2. 37 Sequence Diagram for Feed Forum

Figure 2. 38 Sequence Diagram for Modify Forum
Figure 2. 39 Sequence Diagram for Delete Forum

Figure 2. 40 Sequence Diagram for create discussion
Figure 2. 41Sequence Diagram for create post

Figure 2. 42 Sequence Diagram for View Report
Figure 2. 43 Sequence Diagram for create account

Figure 2. 44 Sequence Diagram for Modify Employee Account
Figure 2. 45 Sequence Diagram for Delete Employee Account.

2. 11. 2 A C T I V I T Y D I A G R A M S
An activity diagram is one of the ways to model the dynamic aspects of a system. It is
used to model the flow of control of an operation. The following figures show the
activity diagrams of some of the more heavy weight operations.
Figure 2. 46 Activity diagram for Reservation
Figure 2. 47 Activity diagram for Reservation Verification
2. 11. 3 S T A T E C H A R T D I A G R A M
State chart diagram show the flow of control from state to state through the process
of modeling the behavior of reactive objects. State chart diagrams allow the developers
to have a thorough understanding over the behavior of objects. The need for this
diagram is especially heightened in the case of complex objects which attain several
states at different times. The following figures depict the state chart diagrams of some
of the more heavy weight objects.
Figure 2. 48 A State chart diagram for user account.

Figure 2. 49 State chart Diagram for Reservation.
2. 11. 4 U S E R S C R E E N S H O T S
The user interface is the part of the system that users will always see, and interact
with. So having screen shots of the user interface in our documentation will allow our
users to see what it looks like and minor changes can be done according to their need.
Figure 2. 50 Registration Page

Figure 2. 51 Main Page
PART 111
SYSTEM DESIGN DOCUMENT
3.1 INTRODUCTION
This part of the project will focus on establishing a meaningful representation of the
software to be built. By elaborating the system structure it will act as a medium in
transforming the analysis model into a working implementation. It does this through
decomposing the system into subsystems and selecting strategies with which the
system will be built, such as the hardware/software platform on which the system will
run, the persistent data management strategy, the global control flow, the access
control policy, and the handling of boundary conditions.
3.2 PURPOSE OF THE SYSTEM

The proposed system will enhance the way reservation and ticket sales transactions
are carried out. This enhancement will be carried out by re-engineering the project from
the ground up instead of making modifications to the current system. The main reason
this route was taken is to produce a software implementation built on a framework
through which modifications or modules can be incorporated much more easily and
effectively. Furthermore the project also plans to produce a site that acts as a hub for
customers looking for entertainment. Customers will be able to rate movies, vote on
different topics and take part in discussions by sharing their inputs on their film
experiences. In order to meet both these goals this project will have as its final
deliverable two very different systems.
The Intranet System
This system is setup for the employees of the business so that they may be able to do
their jobs effectively. All the functionalities pertaining to those actors that fit into the
employee user domain will be deployed on this system. It encapsulates all the
components that are necessary for employees to do their daily jobs. This system will be
offline thereby preventing outside access. Therefore for all the employees to use this
system they have to be accessing it from a workstation connected to the intranet server
on a Local Area Network.
The Online System
This system serves as a platform for all users to be a part of an online entertainment
experience. It encapsulates all the components necessary for customers to carry out
transactions and still captivate them with all the options made available to them. Such
functionalities that enable the customer to make reservations and participate in
discussions are included in this system. This system will also be deployed on the same
server machine as the intranet system but will be made available over the internet.
3.3 DESIGN GOALS

Setting design goals’, being the first step in the system design phase, is a means
through which the qualities the system should maintain are defined. Therefore most of
the design goals are derived from the non-functional requirements of the project. Since
the project plans to deliver both an intranet and an online system the design goals have
to take both into consideration. The goals take the following 4 criteria into
consideration.
3. 3. 1 P E R F O R M A N C E C R I T E R I A
The performance criterion declares how the system performs on a variety of
scenarios. The performance is evaluated by the following standards.
3.3.1.1 RESPONSE TIME

Intranet System
RESPONSE TIME IS NOT A MAJOR ISSUE WHEN IT COMES TO INTRANET SYSTEMS. ACCESSING
RESOURCES LOCALLY DOES NOT TAKE UP MUCH BANDWIDTH. AS LONG AS THE MAIN SERVER IS IN
A STABLE STATE AND ALL THE CABLES WITHIN THE NETWORK ARE SOUND GOOD RESPONSE TIME
IS GUARANTEED FOR ALL THE EMPLOYEES IN THE SYSTEM.
Online System
In the case of the online system, response time is a major issue that makes or breaks
the usability factor of the system. Due to the emergence of various technologies
enhancing connection speeds of many computers, people in Ethiopia are raising the bar
as to what qualifies as a good response time. Therefore the online system that is
available for the customers to access has to meet the highest standards when it comes
to loading time. In order to meet this need the server machine should be in such a state
as to accept and respond to hundreds of requests at a time. In addition a decision will
be made on the amount of visual elements the site will incorporate. Developing a site
that is visually stunning that takes a long time to load is not practical. Therefore a
compromise is necessary when it comes to balancing efficiency and beauty. To ensure
this fact the following considerations will be met in implementing this system.
Considerations
 ALL RESOURCES WHETHER IT IS A WEB PAGE OR MULTIMEDIA MUST HAVE A SIZE

BELOW 2MB.
 FRAMES ARE TO BE AVOIDED -> DUE TO SOME OF THE HEAVY VISUAL COMPONENTS
FOUND IN ALMOST ALL PAGES IMPLEMENTING FRAMES WOULD HAVE A NEGATIVE
IMPACT ON THE LOADING TIME.
 IT WOULD GREATLY INCREASE THE SITE’S APPEAL IF IT MADE A PROFOUND USE OF
FLASH ANIMATIONS. IT IS A WELL-KNOWN FACT THAT USERS RESPOND MORE TO PAGES
PRESENTING ANIMATION THAN STATIC PAGES. BUT THE FACT REMAINS THAT
INCORPORATING THIS KIND OF CONTENT GREATLY WILL IMPACT RESPONSE TIME.
THEREFORE FLASH ANIMATIONS WILL NOT BE IMPLEMENTED COMPREHENSIVELY
UNLESS IT IS FOR ENHANCING THE VISUAL STYLE OF SOME CONTROLS.
3.3.1.2 Throughput
Intranet System
Throughput, just like response time, is not a major issue in the intranet system. The
number of users in the intranet is not more than a handful so implementing solutions to
enhance throughput for these users is infeasible.
Online System
Here however, the system will be responding to hundreds of users at a time and
hence the number of users the server machine can serve at a time can be drastically
improved by implementing solutions such as enhancing the memory and storage
capabilities of the server.
3.3.1.3 Memory
Both Systems
Since both systems will be residing on one central server the memory capacity of the
server will have equal effects on the two systems. Therefore the memory capability of
the server is a crucial factor in the smooth operation of the two systems and hence
should be of the highest degree. In order to achieve this, the server should slot in 16GB
of RAM and three 200GB fast SCSI hard disk drives (10,000 RPM or faster with caching).
3. 3. 2. D E P E N D A B I L I T Y C R I T E R I A
FOR THE SYSTEM TO BE DEPENDABLE IT HAS TO IMPLEMENT SAFEGUARDS AGAINST RANDOM
SYSTEM CRASHES AND PROVIDE SOLUTIONS TO VARIOUS SECURITY RISKS.
3.3.2.1 Robustness
Both Systems
Both systems will be coded to protect against a variety of error conditions. Whether
these errors may arise knowingly or unknowingly by the hand of the users any kind of
exception will be handled and if worst comes to worst and the program has to
terminate it will do so gracefully.
3.3.2.2 Availability
Intranet System
The intranet system will be available 24/7 just like the online system, but this is
simply because it resides on the same machine as the online system. In reality however
it will only be in use only during working hours of the business.
Online System
The system will be available to all users 99% of the time. The only time that
availability will be compromised is if and when the site is undergoing modifications.
3.3.2.3 Fault tolerance

Both Systems
There is always the possibility of partial data loss on the server due to a variety of
circumstances. Whether it may be the malfunctioning of the disk or disk controller the
system should be able to recover from the data loss that arises. In other words a fault
tolerance scheme that keeps the system up and running regardless of any damage to
the disk storage should be put in place.
A fault tolerance scheme that is ideal for this system is a RAID-5 disk configuration
with a minimum of 3 disks. This ensures that in the case of one disk malfunction the
data on that disk will be recovered using the parity information stored on one disk and
actual data stored on the second disk.
3.3.2.4 Security
Both Systems
As stated in the non-functional requirements section this project gives a special

emphasis on security. One of the major components it provides is an online reservation
system that deals with credit balances. Hence any security compromise can have a
potentially devastating effect on the business.
In order to better protect from any hacking attacks like SQL injection, hidden URLs
and a range of other spells measures will be taken in writing the underlying code to
minimize the chances of an intrusion. Safe coding practices, firewalls and virus
protection are simple but effective means through which this goal can be met.
3. 3. 3 M A I N T E N A N C E C R I T E R I A
MAINTAINABILITY IS A MEASURE OF THE QUALITY OF ANY SOFTWARE. ANY IMPLEMENTATION
DEVELOPED WITH MAINTAINABILITY IN MIND THRIVES IN THE INEVITABLE EVENT THAT THE
CODE HAS TO BE MODIFIED. ESPECIALLY IN THE KIND OF BUSINESS WHERE THE OPERATING RULES
CHANGE ALL THE TIME IN ORDER TO REMAIN COMPETITIVE, AS THIS BUSINESS IS, WRITING CODE
THAT IS MAINTAINABLE IS NOT A LUXURY, BUT A NECESSITY.
3.3.3.1 Extensibility
Both Systems
MATTIMULTIPLEX CINEMA IS ONE OF THOSE BUSINESSES THAT CONSTANTLY ALTER THE WAY
IT OPERATES. TO ATTRACT NEW CUSTOMERS AND REMAIN COMPETITIVE ANY BUSINESS SELLING
ENTERTAINMENT AS ITS MAJOR PRODUCT IS SUBJECT TO CHANGES IN ITS BUSINESS RULES. AND
HENCE THESE CHANGES CONSEQUENTLY HAVE TO BE REFLECTED IN THE SOFTWARE. THEREFORE
THE SOFTWARE SHOULD BE EXTENSIBLE. I.E. THE INTRODUCTION OF NEW MODULES AND
COMPONENTS SHOULD BE SIMPLE. SINCE THIS PROJECT FOLLOWS THE DOCUMENTATION AND
MODELING PRACTICES OF UML, IT IS MUCH EASIER TO IDENTIFY WHERE A NEW MODULE IS TO BE
PLACED FOR IT TO HAVE AN OPTIMAL INTERACTION WITH OTHER ENTITIES OF THE SYSTEM.
3.3.3.2 Modifiability
Both Systems
The coding standards we follow will make sure that the final implementation is easily
modifiable. This fact is ensured as the project follows the standards set by UML.
3.3.3.3 Readability
THIS PROJECT WILL HAVE AS ITS DELIVERABLE, A
 MODEL DOCUMENTATION
 CODING DOCUMENTATION
 USER MANUAL DOCUMENTATION
ANY USER, DEVELOPER OR DESIGNER INTENT ON EITHER UNDERSTANDING THE DEVELOPMENT OF

THE PROJECT OR INTENT ON MAKING MODIFICATIONS TO THE CODE, OR IS JUST LOOKING TO
UNDERSTAND HOW THE SOFTWARE WORKS CAN DO SO FOLLOWING THE ABOVE
DOCUMENTATIONS.
3. 3. 4 E N D USER CRITERIA
THE ULTIMATE GOAL OF THE PROJECT IS TO HELP USERS OF THE SYSTEM ACCOMPLISH TASKS
MUCH MORE EFFICIENTLY AND THEREBY ACCOMPLISH TASKS MUCH MORE EASILY.
3.3.4.1 Usability
Both Systems
No matter how many functionalities the systems support or how many components
they incorporate unless users are able to navigate through the systems and accomplish
tasks easily, the project will be more or less useless. Therefore the layouts of the design
and the means through which functionalities are accessed have to make the user feel at
home and comfortable. Furthermore the final systems have to attain a high degree of
flexibility.
3.3.4.2 Utility
IT IS A MEASURE OF HOW WELL THE SYSTEM SUPPORTS THE WORK OF THE USER. THIS GOAL CAN BE
MET BY PROVIDING VARIOUS LINKS TO USERS TO A VARIETY OF PAGES WHERE THE USER IS ABLE TO
ACHIEVE AN IN DEPTH UNDERSTANDING OF A CERTAIN MATTER.
3.4 CURRENT SOFTWARE ARCHITECTURE

The current software architecture can be expressed in terms of two different
partitions.
The first is the system that handles the reservation and ticket sale transactions of
customers. There are two stands where customers are able to purchase tickets. The
clerk operating in the first stand carries out ticket sales for the two ground auditoriums
whereas the desk clerk operating in the second stand handles ticket sales for the third
auditorium. On both these stands there are desktop computers running systems that
handle these reservation and ticket printing transactions. The two systems access their
data from a central database server connected to them through a Local Area Network.
Figure3.1 Current intranet architecture
The second partition is the online website of the cinema. This website embodies the
client/server architecture where requests coming from online users are transferred to
the server machine which in turn processes and sends resources back to client.
Figure3.2 Current online architecture
3.5 PROPOSED SOFTWARE ARCHITECTURE

3. 5. 1 O V E R V I E W
The final deliverable of this project will be two systems serving 2 different user
domains (Employees and Customers) and as such the architecture will be composed of
one application server serving both user domains and one database server from which
this application server can access data. Therefore this architecture will be running two
different systems accessing the same data from a central data server.
One of these systems is the intranet system dedicated to serving the employees of
the business. By accessing resources over a Local Area Network employees will use this
system to carry out their day to day jobs.
The other system is the online system that is accessible to customers over the
internet. This system will also be deployed on its own dedicated server and will use the
services of the database server for access of permanent data.
Figure3.3 Proposed Software Architecture
3. 5. 2 S U B S Y S T E M D E C O M P O S I T I O N
A subsystem is simply a part of a system, and is used to decompose a complex system
into nearly independent parts. A system at one level of abstraction may be a subsystem
of a system at a higher level of abstraction. The complex consequences that would arise
when trying to implement a solution to one large system can be decreased by classifying
the system into manageable subsystems. These manageable subsystems are essentially
interactions between various objects in accomplishing an activity.
Most of the subsystems identified are common to both the systems (i.e. the online
system and the Intranet system) implemented for this project. Along the way
differences in subsystem implementation among these two systems will be pointed out.
Unique subsystems to one of the two systems will be shown as well.
Data Management Subsystem
This subsystem is responsible for connecting to the system database that stores
system data. It handles database connection services through its DBConnection class.
This subsystem is a crucial one as every subsystem of this project except the interface
subsystem makes use of it. Any subsystem looking for data access gains that privilege by
using the services offered by this subsystem.
3.5.2.2 User Authentication Subsystem
Before going in to the application and performing transactions every user must be
successfully verified. Verification is an essential part of the system the user has to go
through before gaining access to it. This authentication procedure is different for every
user domain in that the functionality available per each domain is unique. After a user
has been authenticated the components available to him is dependent on his level of
permission. Furthermore the authentication process is not just limited to the login
phase. This authentication has to be performed every time there is a page request. This
is to protect against a URL intrusion. This will safeguard against any user trying to access
any resource forbidden to him by typing the resources link directly as a URL. Therefore
user authentication is a crucial subsystem that plays a major role in the security of the
system.
These facts apply to the intranet system where there are four different users with
varying levels of permissions. Hence much emphasis on security will be taken during the
implementation of this subsystem.
When it comes to the online system, since the only user domain in contact with this
system is the customer little or no emphasis will be given in selecting site content after
authentication.
3.5.2.3 Account Subsystem

This subsystem is a composition of all functionalities related to the creation,
modification and removal of user accounts. This subsystem is a vital one as each user
looking to make abundant use of this system will have to obtain an account first.
The implementation of this subsystem in the two systems is once again very different.
In the online system customers are able to create their own accounts. If everything
checks out the customer will have an account with which he can login to the system. In
the case of the intranet system however employees looking for an account first have to
contact the global administrator. This actor after filling the employees profile
information will make use of the systems “Manage Account” functionality to create an
account for the employee. Profile data customers fill when creating an account is also
different with the profile data employees are required to submit.
3.5.2.4 Forum Subsystem
This subsystem is a composition of all the functionalities that allow the user to be an
interactive member of any discussion forum. Such functionalities as creating discussion
topics and posts are components of this subsystem.
The implementation of this subsystem on both systems is much alike. Both customers
and Administrators (i.e. Users of both systems) are able to create discussions and post
their opinions on different matters. The only difference is the fact that the
implementation of the forum subsystem on the intranet contains the functionality
“Create Forum” while the online system doesn’t.
3.5.2.5 Interface Subsystem

In order to accomplish any task a user has to be in direct contact with at least one
boundary object at a time. It is an obvious fact that a user interacts with the system by
clicking on links, submitting forms or typing URLs. The boundary objects or interfaces
users are in direct contact with make up this subsystem.
The interfaces available in both systems are completely different. The collections of
pages that make up both systems are distinct both in their layout and in the
components they encapsulate.
3.5.2.6 Scheduling Subsystem

Maintaining up-to-date schedule of movies to be shown is an integral part of the
smooth functioning of the business. It is according to schedules that the customers and
the desk clerk are able to carry out seat reservation activities. In addition customers are
able to make decisions on whether to partake as an audience during a movie showing
based on the movie’s schedule. Henceforth updating movie schedules daily will be the
highest priority of the Administrators.
The implementation of this subsystem is exactly the same in both systems. Whether
it is Customers or the desk clerk, they are both able to access the schedule of every
movie available.
3.5.2.7 Reservation Subsystem

This subsystem is a composition of all the functionalities that allow users to carry out
reservation related activities. Making a reservation, cancelling a reservation and
reservation verification are the functionalities that make up this subsystem.
The implementation of this subsystem is quite different among both systems. In the
online system customers are able to make reservations according to the amount credit
they have and cancel any reservations they’ve made at their whim. But in the case of
the intranet system the desk clerks are able to make reservations and verify
reservations made by customers.
3.5.2.8 Credit Management Subsystem

This subsystem is a composition of functionalities with which the credit balance of
customers is charged or reduced. With reservation comes dealing with credit
transactions. This subsystem encapsulates such transactions and allows credit balances
of users to be handled with much care.
When it comes to implementation this subsystem is implemented fully in the intranet

system and only partially in the online system. When customers buy credit their balance
is charged with the amount they purchased. This transaction is made by the desk clerk
and hence the intranet system is deployed with the capability of charging and
discharging the credit balance of any customer. But the same capability of charging ones
account should not be an option a customer enjoys and as such this component will not
be implemented in the online system.
3.5.2.9 Movie Subsystem

MattiMultiplex cinema introduces newly released movies weekly and gets rid of
movies after two or three weeks of showing depending on their popularity. This coupled
with a daily changing movie schedule calls for a subsystem dedicated to manipulating
movie data. And as such this subsystem will handle the introduction of new movies,
their modification and inevitable disposal.
This subsystem much like the previous ones also has a different implementation on
the both systems. In the online system users are only allowed to retrieve movie data.
This is due to the fact that customers shouldn’t any control over any movies data. In the
intranet system however all functionalities pertaining to manipulating movie data are
included as it is the job of the administrators to deal with such operations.
3.5.2.10 News Subsystem

This subsystem contains all functionalities pertaining to managing News content. This
subsystem is setup with the intention of giving the customers an update on some of the
headline making movies and actors. It is setup as an attempt to draw users into the
system.
Its implementation on both systems is once again very different. On the intranet
system Administrators will be able to access functionalities offered by this subsystem to
manage news data. On the online system however customers will be able to use this
subsystem only to retrieve News data.
3.5.2.11 Rating Subsystem

This subsystem is implemented as part of the projects objective to make the online
system as interactive as possible. Giving online users the option of rating the movies
available in the system is a great means of obtaining this goal. As its name suggests this
subsystem is a composition of functionalities that enable the customer to rate movies
and the administrators a feedback mechanism on the popularity of the movies available.
The implementation of this subsystem on both systems remains different. In the

online system users are not able to access any methods of this subsystem apart from
rating a movie. In the intranet subsystem however administrators also have the
capability of looking at and analyzing the overall percentage of rating given to any
particular movie.
3.5.2.12 Voting Subsystem

This subsystem is also implemented as part of the projects objective to make the
online system an interactive one. It refers to components available allowing users to
access various voting functionalities according to their privilege.
The implementation of this subsystem in the intranet system is completely different

than its implementation in the online system. In the online system the components of
this subsystem are built in such a way as to interact with the customer. In the intranet
system however the entertainment subsystem is built in such a way as to give the
Administrator full control over the components properties.
For example; Customers (i.e. online users) will be able to vote on topics made
available by administrators of the system. This functionality is a purely interactive one.
But Administrators (i.e. Intranet users) have the capability of feeding vote topics to the
system, updating these topics and deleting them if they choose so.
3.5.2.13 Report Subsystem
This subsystem provides functionalities that allow the administrator to generate
different kinds of reports concerning the purchase and reservation activities of
employees and customers.
This subsystem is deployed only on the intranet system as the only user with the
privilege of generating reports is the administrator.
Interface Subsystem
Login Interface Manage schedule Interface Charge credit Interface
Manage News Interface Auditorium #1 Interface Vote Interface
Manage Forum Interface Auditorium #2 Interface Schedule Interface

Reservation details
Manage Account Interface Auditorium #3 Interface Rating Interface
Manage Movie Interface View Schedule Interface Forum Interface
Manage Votes Interface Res. Verification Interface Discussion Interface
Posts Interface Now Showing Interface Coming Soon Interface
Figure 3.3 Interface Subsystem
Schedule subsystem
Schedule
Figure 3.4 Schedule Subsystem

Movie subsystem
Movie
Figure 3.5 Movie subsystem
News Subsystem
News
Figure 3.6 News subsystem
Reservation subsystem
Reservation
Figure 3.7 Reservation subsystem

Forum Subsystem
Forum Category
Discussion
Post
Figure 3.8Forum subsystem
Credit Management Subsystem
Credit
Figure 3.9 Credit Management subsystem
Voting subsystem
Vote
Figure 3.10 Voting subsystem

Rating subsystem
Rating
Figure 3.11 Rating subsystem
User Authentication
SubsystemAA
Authentication
LL
Figure 3.12 User Authentication subsystem
Account Subsystem
User
Customer Employee
Figure 3.13 Account subsystem

Report Subsystem
Reservation_Log
Figure 3.14 Report subsystem
Data Management SubsystemR
DB_Configuration
Figure 3.15Data Management subsystem
Subsystem Relationships
Figure 3.16 a Diagram for subsystem Relationships.
3. 5. 3 H A R D W A R E /S O F T W A R E MAPPING
This section describes how subsystems are assigned to computers and the design of
the infrastructure for supporting communication between subsystems. This section is
nothing but a clarification of how the two systems map to the hardware equipment
utilized by the business. The following section shows the hardware specification of each
of the equipment needed to support the two systems.
Workstations’ Specification
In order for this project to be realized all the employees identified as actors must
have a workstation on their desks where the system would execute. Each workstation
should meet the following specification in order to yield maximum performance.
o Dual core 3.2 GHZ processor
o 2 GB RAM
o 80 GB Hard disk
o 17” monitor
o Windows XP Operating System or higher (Preferably Windows 7)
o Twisted Pair Fast Ethernet cards
Server Machines’ Specification
Both server computers should at least meet the following criteria
o Intel Core 2 Duo 64-bit 3.2 GHZ

o 16GB of RAM
o Fast SCSI RAID Controllers
o Windows Server 2008 Enterprise
o 2 Twisted Pair 32-bit /1GB Ethernet cards
The database server should be equipped with three 200GB fast SCSI hard disk drives
(10,000 RPM or faster with caching) since it is the primary data storing entity.
Devices and Cabling
o 1 “2950T” Switch
o 1 Router
o Straight-through UTP cables one per workstation
This hardware/software mapping is depicted through a deployment diagram. A UML

deployment diagram depicts a static view of the run-time configuration of processing
nodes and the components that run on those nodes. In other words, deployment
diagrams show the hardware for the system, the software that is installed on that
hardware, and the middleware used to connect the disparate machines to one another.
The following image is the deployment diagram for the proposed system.
Figure 3.17 Deployment Diagram
3. 5. 4 P E R S I S T E N T D A T A M A N A G E M E N T
Persistent data management describes the persistent data stored by the system and
the data management infrastructure required for it. Data is created during the
interaction of users with the system, and this data will be different based on the
operation performed by the user. The storage of data in an organized manner where
access to it is done efficiently is an essential matter for the commencement of the
system. This data that needs to be stored is very important for the information
exchange between classes or subsystems. The following diagram is an illustration of the
database diagram adopted for this project.
Figure 3.18 Persistence Database Diagram

3. 5. 5 A C C E S S C O N T R O L & S E C U R I T Y
In this subsystem there are 5 human actors with different access levels. The
functionalities all these user domains can access are mostly different with one or 2
overlapping components between actors. The online system is only there to serve
customers so no consideration should be taken in restricting any functionality on this
system. The intranet system, however, has 4 different actors with varying level of access
to the system. Strong enforcement of access and security should therefore be
undertaken to prevent an actor from one domain from accessing resources or
completing transactions pertaining to a user of another domain. The following diagram
illustrates the level of access each actor has in accessing different functionalities.
3. 5. 6 G L O B A L SOFTWARE CONTROL
This project follows an event driven approach when it comes to control flow. An
event driven control flow is the invocation of methods originating from the activities of
users or other objects. This kind of approach means decisions are made on the order of
execution of the software based on the users action. In both systems this control follows
an event driven approach, but with some key differences.
The Online System
The users of this system have functionalities available to them whether they’re
logged in or not. Customers are able to access this system and carry out rudimentary
transactions such as viewing certain pages without being logged in. However for
customers to be able to access some of the more heavy weight aspects of the system
that allow them to complete more advanced transactions they have to be logged in
members.
The Intranet System
Unlike users of the online system the users of this system have to be logged in to
make use of any of its functionalities. There are 4 different user domains making use of
this system all with different tasks to accomplish. And since these different user
domains don’t have any common functionalities which they’re all able to access there
can’t be any resources on this system that are made available for users that aren’t
logged in. And also because all these user domains have different tasks to carry out
functionalities will be made available to them according to their privilege.
3. 5. 7 B O U N D A R Y C O N D I T I O N S
Boundary conditions state how the system is started, initialized and shutdown. It also
depicts as to how the project deals with data corruption, software errors as well as
during a power outage. The boundary conditions stipulated are inherent to both
systems so in this section they will be referred to as one system.
The startup of this system will commence when the user types a link on his/her
browser to access some resource from the system. The server hosting the system upon
receiving this request will process it and pass it on to the system. The system will check
the availability of the resource and will send back an appropriate message. Users will
then login to the system after being authenticated and carry out a variety of
transactions.
System shutdown from the user’s perspective will proceed when the user logs out of
the system and clicks the close button on the browser window. A shutdown may also
occur from the server side where the two systems reside. Although it is an unlikely
event since both systems are expected to run 24/7, it will happen if and when code
maintenance is necessary. It may also happen in the case of an unexpected power
outage. Even though the building where the business resides is equipped with automatic
generators which will startup during a power outage it would be somewhat naïve as to
assume there won’t be any power outage in the lifetime of the business.
In order to safeguard against data loss caused by an unexpected power outage the
business is expected to implement UPS systems on some if not all of its machines. A UPS
system is mandatory on the server machines especially on the database server as all the
data is stored there and any unexpected power outage could potentially have terrible
effects unless proper safeguards are deployed.
Error conditions raised during the execution of the system will be handled as they
arise by throwing exceptions. Users will be notified in such cases through the use of
dialogs.
PART IV OBJECT DESIGN DOCUMENT
4.1 INTRODUCTION
In system design document we showed how the new system solution should be
implemented. Now in the object design phase we will further extend the requirement
analysis and system design model by adding type, signature and visibility information to
the identified classes so that there may be a better understanding of the classes and
subsystems identified in system design.
Object Design tradeoffs, Interface documentation guidelines, package and class
interfaces will be discussed in this section so as to give much deeper insight on the rules
and conventions followed in system development.
4. 1. 1 O B J E C T D E S I G N T R A D E O F F S
Design tradeoffs are inevitable phenomena when undertaking any project with such
complexity. The completion of one aspect of a system with great level of detail and
maximum performance may have a negative impact on another facet of the system. In
other words as we meet one goal of the project with a high level of sophistication we
may hurt the chances of another equally important goal from having that same level of
sophistication or even an adequate performance. This section depicts the various
features having characteristics with adverse effects on their performance and what has
been done to minimize these effects.
4.1.1.1 Throughput vs. Response Time

The extent to which the systems meet these two criteria will decide the number of
users accessing the system. The amount of user requests that can be accommodated
and the speed of this accommodation are two of the major design goals the project has
as its target. Although both aspects are vital to the success of the project it is difficult to
accommodate both as they have an adverse relationship. As the number of users
accessing the two systems increases the speed with which the server can respond to
requests coming in may decline. This phenomena is somewhat magnified as both
systems reside on the same machine and this machine is expected to accommodate all
the users of the two systems.
The biggest entity responsible for resolving this effect is the memory capacity.
Increasing the amount of memory present on the server will in turn increase the
amount of throughput and response time of the two systems. Therefore fitting a
Random Access Memory with a capacity to handle hundreds of requests at a time will
put this issue to rest.
Another entity that will go some way in resolving this issues it the nature of the cable
connecting the users to the server machine. Two cables will be connected to the server
machine one originating from the LAN and another from a router which is in turn
connected to the internet. These two cables will act as mediums in transmitting multiple
requests. This figure is much more magnified on the cable receiving requests from the
internet. Therefore in order to have good response times as well as a decent amount of
throughput fiber cables having a high transmission rate have to be installed.
4.1.1.2 Speed vs. Interface

These two aspects are also important parts on the usage of the online system. Since
the usage of the intranet is to perform work related tasks its level of visual appeal is
something that isn’t much stressed over. When it comes to the online system its
intention is to draw users in and as such it should be equipped with an exciting
interface. But the level of speed the system has to maintain should not be overlooked
when trying to meet this goal. The tradeoff issue becomes apparent due to this inverse
relationship between the speed of the system and level of visual components
embedded in the system’s interface. Therefore while still implementing a slick interface
the following rules should be obeyed so as not to negatively impact the speed.
 The size of pages and multimedia should be below 2MB

 Frames will be avoided at all costs
 Minimal use of flash animations
4. 1. 2 I N T E R F A C E D O C U M E N T A T I O N G U I D E L I N E S
Rules and regulations should be followed when writing code in order for it get global
acceptance. In other words the code of the system should be easily understandable to
any novice developer wishing to get acquainted with how the system functions. By
going through the documentation and the code a developer should achieve ample
understanding on some of the functionalities. Furthermore a developer must be able to
recognize where to look for a given functionality and also where to put modification
code if he chooses to change how the system functions. Following these guidelines will
also help us in writing consistent code through in collaboration.
In order to achieve these goals the following considerations will be taken.
 All variables will have camel casing declarations

String $movieName
Var $fName
 Codes accomplishing more significant tasks will be thoroughly commented.
function connection()//connect incoming requests to the server and
specifically to maticinema database
{
$link = mysql_connect('localhost','root','')
or die ("Could not connect to mysql because
".mysql_error());
// select the database

mysql_select_db('maticinema',$link)
or die ("Could not select database because
".mysql_error());
return $link;
function closeConnection()// closes the connection to the

server
{
mysql_close($link);
}
 The naming of functions and classes will be descriptive of their use
function feedNews($newsTopic,$body,$imagePath,$createdBy,
$createdAt)
{
}
 Every part of the code will have proper indentation
function closeConnection(); {
mysql_close($link);//
}
 Class names consisting of a single word will have their first letter capitalized
the rest being small
class Connection
{
public $server = "localhost"; // server to connect to.

public $database = "maticinema"; // the name of the
database.
public $db_user = "customer "; // mysql username to
access the database with.
public $db_pass = "maticinema"; // mysql password to
access the database with.
 Class names made up of more than one word will have the first letters of each
distinct word capitalized the rest being small.
class NewsClass
{
function __construct($Topic,$msg,$path,$createdAt,$user)
{
$this->newsTopic=$Topic;
$this->date=$createdAt;
$this->userName=$user;
$this->body=$msg;
$this->imagePath=$path;
}
}
4.2 PACKAGES
Packages describe the decomposition of subsystems into packages as well as the file
organization of the code implementing the subsystems. This section depicts each
package used in the implementation, their dependencies, and usage. We have identified
a total of 13 packages corresponding to all 13 subsystems with the same
correspondence with encapsulated classes. All the package descriptions outlined below
apply to both of the systems.
1) Data Management Package: is responsible for connecting to the system database

that stores system data. It handles database connection services through its
DBConnection class.
2) User Authentication Package: contains Authentication class responsible for the
authentication of users before gaining access to any resource. It is composed of
methods setting and checking session variables in order to make sure a user is
properly identified before gaining access to components of the system.
3) Account Package: is responsible for the creation, modification and removal of
user accounts and profiles. It encapsulates three classes representing all user
domains containing methods for performing the above functions.
4) Forum Package: is responsible for handling forum discussions. From posting
discussions and topics to managing forums this package encapsulates every aspect
of the forum functionality. It essentially handles every forum transaction through
the methods found in the Forum, Discussion and Post classes.
5) Interface Package: This package encapsulates every interface made use by the
system. All the interfaces through which all the functionalities can be accessed are
found in this package.
6) Schedule Package: This package encapsulates the schedule class which is
responsible for managing movie schedule data. It has various methods with which
it can feed, modify, remove and retrieve schedule data.
7) Reservation Package: This package encapsulates the reservation class which is
responsible for handling reservation transactions. Activities such as making and
cancelling reservations as well as managing reservation details such as marking
reserved seats can all be found in the context of this package.
8) Credit Management Package: This package encapsulates the Credit class which is
responsible for handling credit transactions. Activities such as charging and
discharging the credit balance of each customer are found within the context of
this package.
9) Movie Package: This package encapsulates the Movie class which is responsible
for controlling movie data. The entire movie data present in the system is
manipulated through the methods found within the context of this package.
10)News Package: This package encapsulates all functionalities in charge of
controlling News data within the system. Through the News class and its methods
this package captures activities integral to the management of News data.
11) Rating Package: This package encapsulates functionalities associated with
maintaining rating data pertaining to all the movies in the system. Through the
methods of the rating class this package captures tasks inherent to managing
rating data.
12)Voting Package: This package encapsulates all activities inherent to maintaining
polls on different topics. Through the vote class and its methods this package
captures tasks fundamental to maintaining voting data.
13)Report Package: This package is responsible for carrying the means through which
report data can be maintained and generated. It encompasses the Report class
which is responsible for generating reservation activities conducted by the
different actors of the system.
4.3 CLASS INTERFACE

Below is a detailed representation of the classes used in this project. Different
aspects of each class are discussed in this section including their attributes, methods,
preconditions, post conditions and invariant conditions. This will give novice developers
from any background a detailed understanding on some of the major classes involved in
this project as well as offer deep insight into the inner workings of each class.
User Class
Figure 4.1 User Class
Attribute Data Visibility Description

Name type
UserId Int private Holds ID assigned to identify each user uniquely
UserName String private Holds system name of a user
FName String private Holds the first name of the user
LName String private Holds the last name of the user
Gender Char private Holds sex/gender of the user
Telephone String private Holds the phone number of the user
Password String private Holds the password with which the user logs into
the system
DOB Date private Holds the date of birth of the user
Table 4.1 Attribute table for user class
Method Return Visibility Description

Name type
insertUser int Protected Method that registers user data in the system
ModifyUser int Protected Method that modifies a user’s data
removeUser Int Protected Method that removes a user from the system
verifyUser Int Protected Method that checks the existence of a user in
the system
Table 4.2 Method Table for user class
Customer Class
Figure 4.2 Customer class
Attribute Name Data Visibility Description

type
Email String Private Holds the e-mail address of the customer
Table 4.3 Attribute table for Customer class
Method Name Return Visibility Description

type
insertCustomer Int Public Method that registers customer data into
the system
modifyCustomer Int Public Method that modifies a customer’s data
retrieveCustomers Custome Public Retrieves an array of all customers available
r or a single customer if his/her ID is passed as
a parameter
Table 4.4 Method table for Customer class
Employee Class
Figure 4.3 Employee class

Attribute Name Data type Visibility Description
Position String Private Holds the position of the employee in
the system
Telephone String private Holds the phone number of the
employee
Table 4.5 Attribute table for Employee class

type
insertEmploye Int Public Method that registers employee data
into the system
modifyEmployee Int Public Method that modifies employee data
retrieveEmployees Employee Public Retrieves an array of all employees
available or a single employee if his/her
ID is passed as a parameter
Table 4.6 Method table for Employee class
Schedule Class
Figure 4.4 Schedule class
Attribute Name Data type Visibility Description

ScheduleId Int Private Holds the ID assigned to identify each
schedule in the system uniquely
MovieID Int Private Holds the Movie ID to which the schedule
pertains to
StartTime Double Private Holds the start time of the movie
AudiNum Int Private Holds the Auditorium Number where the
movie will be shown
Date Date Private Holds the date the schedule is associated
with
Table 4.7 Attribute table for Schedule class

type
feedSchedule int Public Method that registers schedule data
into the system
modifySchedule int Public Method that modifies an attribute/s
of a schedule
removeSchedule int Public Method that removes a schedule
from the system
retrieveSchedules Schedule Public Method that Retrieves an array of all
schedules available or a single
schedule if its ID is passed as a
parameter
checkScheduleExistence int Public Method that checks whether a
movies schedule is repeated or not
Table 4.8 Method table for Schedule class
Movie Class
Figure 4.5 Movie class

type
MovieId int Private Holds the ID assigned to identify each movie
uniquely
MovieName String Private Holds the name of the movie
Description String Private Holds the description of the movie
ImagePath String Private Holds the file path of the movie’s image on
the server
ProductionStatus String Private Holds the production status of the movie
Genre String Private Holds the movie genre
Director String Private Holds the name of the movie’s director
Release date Date Private Holds the Release date of the movie
Distributor String Private Holds the name of the movie’s distribution
company
ProductionCompany String Private Holds the name of the movie’s production
company
Studio String Private Holds the studio name involved in the
movie’s production
FilmingLocation String Private Holds the name of the movie’s filming
location
ProdcuedIn String Private Holds the state the movie was produced
Table 4.9 Attribute table for Movie class
type
feedMovie Int Public Method that registers movie data into the
system
modifyMovie Int Public Method that modifies an attribute/s of a
movie
removeMovie Int Public Method that removes movie data from the
system
retrieveMovies Movie Public Method that Retrieves an array of all
Movies available or a single Movie if its ID is
passed as a parameter
checkMovieExistence Int Public Method that checks whether a movie
already exists in the system
Table 4.10 Method table for Movie class
Reservation Class
Figure 4.6 Reservation class

type
ResId Int Private Holds the ID assigned to identify each
reservation uniquely
ScheduleId Int Private Holds the ID of the schedule the
reservation is associated with
UserId Int Private Holds the User ID who made the
reservation
ReservationNumber Long Private Holds the reservation number with which
the reservation can later be verified
ReservedSeats Int Private Holds the reserved seats encapsulated
within one reservation
Table 4.11 Attribute table for Reservation class

type
retrieveReservedSeats String Public Method that retrieves the reserved
seats pertaining to one reservation in
the form of an array
makeReservation int Public Method that feeds reservation data to
the system
cancelReservation int Public Method that is invoked when cancelling
a reservation
generateResNumber long Public Method that generates a number per
each reservation made by customers
checkClashingTimes int Public Methods that checks whether the actor
has made another reservation at the
time in another auditorium
Table 4.12 Method table for Reservation class
Forum Category Class

Figure 4.7 Forum category class
Attribute Data type Visibility Description

Name
ForumId Int Private Holds the ID assigned to identify each Forum
uniquely
ForumName String Private Holds the name of the forum
Description String Private Holds the description of a forum
Table 4.13 Attribute table for Forum category class

type
feedCategory Int PublicMethod that registers a forum into the
system
modifyCategory Int Public Method that modifies an attribute/s of a
forum
removeCategory Int Public Removes a forum from the system
retrieveCategory Forum_C Public Method that Retrieves an array of all
ategory Forums available or a single Forum if its ID is
passed as a parameter
checkCategoryExi Int Public Method that checks whether a Forum
stence already exists in the system
Table 4.14 Method table for Forum category class
Discussion Class
Figure 4.8 Discussion class

Name type
DiscussionId int Private Holds the ID assigned to identify each Discussion
uniquely
Topic String Private Holds the actual text of the discussion topic
ForumId int Private Holds the ID of the forum to which the discussion
belongs
CreatedBy int Private Holds the User ID of the person who created the
discussion
CreatedAt Date Private Holds the date when the discussion topic was posted
Table 4.15 Attribute table for Discussion class

Type
PostDiscussion Int Public Method that registers discussion data
into the system
RetrieveDiscussions Discussion Public Method that Retrieves an array of all
Discussions available or a single
Discussion if it’s ID is passed as a
parameter
checkDiscussionExiste Int Public Method that checks whether a
nce Discussion already exists in the system
Table 4.16 Method table for Discussion class
Post Class
Figure 4.9 Post class

Name type
PostId Int Private Holds the ID assigned to identify each Post uniquely
DiscussionId Int Private Holds the ID of the discussion to which the post
belongs
Body Int Private Holds the main text of the post
CreatedBy Int Private Holds the User ID of the user who made the post
CreatedAt Date Private Holds the date when the post was created
Table 4.17 Attribute table for Post class

type
CreatePost int Public Method that registers post data into the system
retrievePosts Post Public Method that Retrieves an array of all posts
available or a single post if it’s ID is passed as a
parameter
Table 4.18 Method table for Post class
Credit Balance Class
Figure 4.10 Credit Balance class

type
CreditId int Private Holds the ID assigned to identify each credit
account uniquely
UserId Int Private Holds the User ID of the customer to which the
balance belongs to
Balance Double Private Holds the amount of credit the customer has
Table 4.19 Attribute table for Credit Balance class

type
chargeBalance Int Public Method that increases the credit balance of
the customer
DischargeBalnce Int Public Method that decreases the credit balance of
the customer
retrieveBalance Int Public Method that retrieves the current credit
balance the user has from the database
Table 4.20 Method table for Credit Balance class
News Class
Figure 4.11 News class

Name type
NewsId Int Private Holds the ID assigned to identify each News post
uniquely
NewsTopic String Private Holds the news topic data
Body String Private Holds the main message of the news
ImagePath String Private Holds the file path to which the news image is stored
on the server
Created_at Date Private Holds the date when the news post was created
Created_by Int Private Holds the User ID of the user who created the News
post
Table 4.21 Attribute table for News class

type
feedNews int Public Method that registers News data into the
system
modifyNews int Public Method that modifies an attribute/s of a
News post
removeNews int Public Method that removes News data from the
system
retrieveNews News Public Method that retrieves an array of all the
News posts available or a single News post
if its ID is passed as a parameter
checkNewsExistence int Public Method that checks whether a News Topic
already exists in the system
Table 4.22 Method table for News class
Vote Class
Figure 4.12 Vote Class

Name type
VoteId Int Private Holds the ID assigned to identify each poll uniquely
VoteTopic String Private Holds the topic of the poll
VoteParams String Private Holds the voting choices associated with a certain
vote
TotalVotes int Private Holds the total number of votes cast for one
parameter
Postdate Date Private Holds the date when the vote was posted
Table 4.23 Attribute table for Vote Class

type
feedVote() Int Public Method that registers poll data into the
system
modifyVote Int Public Method that modifies an attribute/s of a poll
removeVote Int Public Method that removes poll data from the
system
castVote Int Public Method that allows the user to cast a vote on
a poll
retrieveVotes Vote Public Method that retrieves an array of all the polls
available or a single poll if its ID is passed as a
parameter
checkVoteExistence Int Public Method that checks whether a poll already
exists in the system
Table 4.24 Method table for Vote Class
Rating Class
Figure 4.13 Rating class

Name type
RatingId int Private Holds the ID assigned to identify each Rating uniquely
UserId int Private Holds the User ID of the user who submitted the rating
MovieId int Private Holds the movie to which the rating is associated with
Rating short Private Holds the rating value assigned to the movie
Table 4.25 Attribute table for Vote Class
type
postRating int Public Method that registers rating data
into the system
retrieveRatingPercentage int Public Method that retrieves percentage of
rating assigned to a specific Movie
Table 4.26 Method table for Vote Class
Authentication Class
Figure 4.14 Authentication class

type
UserSession String Private Is the session variable that is set and unset as a
user logs in and logs out respectively
defaultPage string Private Holds the default Page to which users will be
redirected in the case of unauthorized access
Table 4.27 Attribute table for authentication class

Type
verifyUser int Public Method that checks whether the user session
has been set (checks whether the user has
logged in or not)
setSessionVar int Public Method that sets the UserSession variable
according to his/her privilege (On Login)
unsetSessionVar int Public Method that unsets the UserSession variable
(On Logout)
directToPage void Public Method that directs the user to the default
page in the case of an attempted unauthorized
access
Table 4.28 Method table for Authentication class
Reservation_Log Class
Figure 4.15 Reservation log Class

Name Type
LogID int Private Holds the ID assigned to identify each log information
uniquely
UserName int Private Holds the User Name of the user who made the
reservation
MovieName int Private Holds the name of the movie to which the reservation
applies to
StartTime double Private Holds the start time of the movie
AudiNum int Private Holds the auditorium number of the hall in which the
movie was showed
Date date Private Holds the date of the movie schedule
Price double Private Holds the price of reservation
Table 4.29 Attribute table for Reservation log Class
Method Name Return Type Visibility Description
retrieveActivity ReservationLog Public Method that retrieves the log activity of
a user whose username is passed as a
parameter
Table 4.30 Method table for Reservation log Class
Db_configuration Class

Name Type
ServerName String Private Holds the Server name with which the application uses
to connect with the database
UserName String Private Holds the User Name used to connect with the
database
Password String Private Holds the password used to connect with the database
TimeOut Int Private Holds the amount of seconds until any page times out
Table 4.31 Attribute table for Db_configuration Class
Method Name Return Type Visibility Description

DBConnection bool Public Method that retrieves a connection
object after connecting to the database
Table 4.30 Method table for Db_configuration Class
o Reliability: The extent to which program can be expected to perform its intended
function with required precision.
o This might be measured in terms of:
 Availability, the percentage of a particular time interval that a system is
usable;
 Mean time between failures, the total service time divided by the number of
failures;
 Failure on demand, the probability that a system will not be available at the
time required or the probability that a transaction will fail;
 Support activity, the number of fault reports that are dealt with.

Functional Requirements - 2 From Beza

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Functional Requirements - 2 From Beza

Uploaded by

Copyright:

Available Formats

HiLCoE School of Computer Science & Technology

Online cinematic community and reservation system

A senior project document in partial fulfillment of the requirements for

Prepared by: Fasil Alemayehu

Advisor: Mr. Mesfin Kifle

Despite showing excellence in all areas of customer service, MattiMultiplex lacks an

1.3 STATEMENT OF THE PROBLEM

1.4 OBJECTIVE OF THE PROJECT

1.5 SCOPE & LIMITATION

The major components this project includes are the following

1.6 METHODOLOGY, TOOLS & DATA COLLECTION TECHNIQUES

 Microsoft Expression Web

Documentation and Design Tools

 Microsoft Office Word 2010

1.8 TEAM FORMATION

The group members of Online Cinematic Community and Reservation System:

Cost estimation must address the following critical questions.

1) How much effort is required to complete an activity?

 Description  Quantity  Duration  Total Cost(in birr)

Other documents found online

Screen 2 at MattiMultiplex is a multifunctional auditorium that is capable of playing

From professional cutting edge digital sound systems, projection equipment,

Planning a world class event … we have the venue.”

2.2 PURPOSE OF THE SYSTEM

2.3 SCOPE OF THE PROJECT

The major components this project includes are the following

1) A system that automates the ticket sales and reservation procedures

2.4 OBJECTIVE AND SUCCESS CRITERIA OF THE PROJECT

2.5 CURRENT SYSTEM

The Desktop application

The static Website (www.ednamall.net)

 Now Showing- www.ednamall.net/now_showing.html

 Coming Soon- www.ednamall.net/comming_soon.html

 Cinema View- www.ednamall.net/cinema_view.html

2.6 PROPOSED SYSTEM

Another means of handling transactions is through bank account transfers.

Global Administrator’s Activities

 The Global Administrator is capable of carrying out all of the Administrator’s

Desk Clerk #1’s Activities

 The desk clerk will reserve seats and sell tickets

Desk Clerk #2’s Activities

Activities inherent in all human actors

 The actor logins to the system

USER MANUAL DOCUMENTATION

2.6.3.2 Hardware Consideration

o Intel Core 2 Duo 64-bit 3.2 GHZ

2.6.3.3 Performance Consideration

2.6.3.4 Error Handling

2.6.3.5 Quality Issues

Fault tolerance Scheme

2.6.3.6 Security Issues

2.7 ACTORS INVOLVED

Scenario Name Login(Successful)

Scenario Name Login(Unsuccessful)

Scenario Name Feed Schedule

Scenario Name Feed News

Scenario Name Delete News

Scenario Name Modify Vote

Scenario Name Feed Movie

Scenario Name Create Employee Account

Scenario Name Feed Forum

Scenario Name Sell Ticket

Scenario Name Reservation Verification