MENU CHART Menu design is a data flow methodology.

The graphical representation of data flow, Communication & defining the modules & their relationship with each is known as menu Chart. This method decomposes & modularizes the system so that complexity & manageability will come down. Thus reducing the intuitive reasoning&promotes the maintainable provable systems. Menu chart shows how variables pass between variables modules in a computer. Each task can be associated with structured chart representation. For large system several levels of structured will be needed to reflect the number and complexity of the module in the system irrespective of whether multiprocessing or multitasking is in use. The relationships between modules are shown by calls. The existence and direction of the call indicates that a module has shown by calls. The existence and direction of the call indicates that a module has means to call other module and that at run time the module may call other module 0 or more times. Typically, the structured contains a hierarchy of modules which is used to show how one module will call another. As module calls normally involves the passage and return of parameters, the menu chart depicts these with couples of data and controls which are provided that indicate the passage or return of data or some value that controls the operation of the recipient module.

System menu chart Online Movie Reservation

Movie mgt

Theatre mgt Theatre registration Movie request

User mgt User registration Send feedback

Reservation mgt Reservation

Add movie Show and movie assigning View payment details

Payment

Seat information Show movie assigning

Voting History Change password

Approve theatre Add cost View feedback

Add show

Add movie

Change password

Send feedback

DATA FLOW DIAGRAM Data Flow Diagram (DFD) is an important tool used by system analysts. DFD provide an overview of what data a system would process, what transformation of data are done, what files are used and where the results flow. The graphical representation of the system makes it a good communication tool between the user and the analyst. Analysis model helps us to understand the relationship between different components in the design. Analysis model shows the user clearly, how a system will function. This is the first technical representation of the system. The analysis modeling must achieve three primary objectives. To establish a basis for creation of software design To describe what the user requires To define set of requirements that can be validated once the software is built. A data flow diagram is a graphical technique that depicts information flow and transforms that are applied as data move from input to output. The DFD is used to represent increasing information flow and functional details. A level 0 DFD, also called fundamental system model or a Context model, represents the entire software elements as single bible with input and output indicated by incoming and outgoing arrows respectively. Additional process and information flow parts are represented in the next level i.e., Level 1 DFD.Each of the process represented at level 1 are sub function of overall system depicted in the Context model. Any process which are complex in level 1, will be farther represented into sub function in the next level,i.e,in Level2. Definition Data flow diagram is a means of representing system at any level of detail with a graphic network of symbols showing data stores, data process and data sources or destinations. Data Flow Diagram Principles A system can be decomposed into subsystems, and subsystems can be further decomposed into lower level subsystems. Each subsystem represents a process or activity in which data is processed. At the lowest level, process can no longer be decomposed. Each process has the characteristics of a system.A process must have input and output. Data enters the system from the environment,data flows between processes within the system and data is produced as output from the system. Purpose or Objective The purpose of data flow diagram is to provide a semantic bridge between users and systems developers. The diagrams are graphical, eliminating thousands of words, logical representations, modeling what system does; Hierarchical, showing systems at any level of details; and jargon less, allowing user understanding and reviewing. The goal of data flow diagramming is to have a commonly understand model of a system. The diagram is the basis of structures system analysis. Data flow diagram is supported by other techniques of structured systems analysis such as data structured diagrams, data dictionaries and procedure representing techniquessuch as decision table trees and structured English.

The basic elements of DFD are Process: A process represents some amount of work being performed on data. Circle or bubble

External Entity: This represents any outside agency, which interact with the system. It represents the source or destination of data for the system under consideration. Rectangle

Dataflow: The dataflow portrays an interface among different components in a DFD.It represents flow of data between two process or between a process and an external entity or between a process and a data store. Arrows

Data store: A data store is a place for holding information within the system. Here data is stored or referenced by a process in the system. Open-ended rectangle.

Rules while drawing DFDs (1) Process should be named and numbered for easy reference. (2) The direction of flow is from top to bottom and from left to right. Data traditionally flow from the source to the destination although they may flow back to a source. (3) When a process is exploded into lower level details, they are numbered. (4) The names of data stores, sources and destination are written in capital letters.

Level 0 DFD
Request

User

Online Movie Reservation

Response

Context level diagram

Level 1 DFD

User_reg
U_id

user info

User mgt

th_reg
Login theatre info theatre mgt Login

User

th_id

m_name
Movie mgt

movie info

Addmovie

m_id

resevation info

Reservation mgt

Reservation

th_id

Level 2 DFD of movie mgt

sh_id

Add movie
show details

Show

assigning details

Show_movi e assign

Movie_show

Movie_id

Movie details

Add show

Add show

assigning sh_id

Add cost Cost

Cost details

Level 2 DFD of theatre mgt

Movie detail

movie_request Movie info

Seat details

Seat info

Seat info

Feedback details
Feedback

Send feedback

payment details

View feedback

Payment

Level 2 DFD of user mgt

Voting details

User info Voting

Voting

Feedback User Send Feedback User info

Feedback

Level 2 DFD of reservation mgt

User details

u_id

Reservation

Reservation

u_id

History

Reservation details

Report

SYSTEM FLOW CHART A system flow chart, or data flow chart, is used to describe the flow of data through a complete data processing system. Different graphic symbols represent the clerical operations may indicate the specific programs used, no details are given of how the programs process the data. A program flow chart is used to describe the flow of data though a particular computer program, showing the exact sequence of operations performed by that program in order to process the data. Different graphic symbols are used to represent data input and output, decisions, branches, and subordinates. The flowchart is a means of visually presenting the flow of data through an information processing systems, the operations performed within the system and the sequence in which they are performed. A flowchart is a diagrammatic representation that illustrates the sequence of operations to be performed to get the solution of a problem. Flowcharts are generally drawn in the early stages of formulating computer solutions. Flowcharts are generally communication between programmers and business people. These flowcharts play a vital role in the programming of a problem and are quite helpful in understanding the logic of complicated and lengthy problems.

Symbols Atypical flowchart may have the following kinds of basic symbols:

Start and End Symbol: Start and end symbols, represented as lozenges, ovals or rounded rectangles, usually containing the word Start or end. Or another phrase signaling the start or end of a process, such as submit enquiry or receive product.

Arrows: Arrows, showing what is flow of controlling computer science. An arrow coming from one symbol and ending at another symbol represents that control passes to the symbol the arrow points to. Processing Steps: Processing steps, represented as rectangles. Examples:Add 1 to X;replace identified part;savechangesor similar.

Input/output: Input/output, represented as parellelogram.Examples:Get X from the user; display X.

Conditional or Decision: Conditional (or decision), represented as a diamond (rhombus). These typically contain a Yes/No question or True/False test. This symbol is unique in that it has two arrows coming out of it, usually from the bottom point and right point, one corresponding to Yes or True, and one corresponding to No or False. The arrows should always be labeled. More than two arrows can be ued,but this is normally a clear indicator that a complex decision is being taken, in which case it may need to be broken-down further, or replaced with the pre-defined symbol.

Guideline for drawing flowchart Flowchart are usually drawn using some standard symbols;however,some special symbols can also be developed when required. In drawing a proper flowchart, all necessary requirements should be listed out in logical order. The flowchart should be clear, neat and easy to follow. There should not be any room for ambiguity I understanding the flowchart. The usual direction of the flow of a procedure or system is from left to right or top to bottom.

Only one flow line should come out from a process symbol. Only one flow line should enter a decision symbol, but two or three flow lines, one for each possible answer, should leave the decision symbol. Only one flow line is used in conjunction with terminal symbol. Write within standard symbols briefly. As necessary , you can use the annotation symbol to describe data or computational steps more clearly. If the flowchart becomes complex, it is better way of communication. Ensure that the flowchart has a logical start and finish. It is useful to test the validity of the flowchart by passing through it with a simple test data.

The advantages of flowcharts are as follows Communication: flowcharts are better way of communicating the logic of a system to all concerned. Effective analysis: with the help of flowchart, problem can be analyzed in more effective way. Proper documentation: program flowcharts serve as a good program documentation, which is needed for various purposes. Efficient coding: the flowchart act as a guide or blueprint during the systems analysis and program development phase. Proper debugging: the flowchart helps in debugging process. Efficient Program Maintenance: the maintenance of operating becomes easy with the help of flowcharts. It helps the programmer to put efforts more efficiently on the part. FLOWCHART

ER DIAGRAM An entity-relationship (ER) diagram is specialised graphic that illustrates the interrelationships between entities in a database.ER diagrams often used symbols to represent 3 different types of information. Boxes are commonly used to represent entity. Diamonds are normally used to represent relationships and ovals are used to represent attributes. Also called an entity-relationship model, a graphical representation of entity and their relationships to each other, typically used in computing in regard to the organization of data within database or information systems. An entity is a piece of data an object or concept about which data is stored, a relationship is how the data is shared between entities. Classifying Relationships Relationships are classified by their degree, connectivity, cardinality, direction, type, and existence. Not all modeling methodologies use all these classifications. Degree of a Relationship The degree of a relationship is the number of entities associated with the relationship. The n-ary relationship is the general form for degree n. Special cases are the binary, ternary, where the degree is 2, and 3, respectively.

Binary relationships, the association between two entities are the most common type in the real world. A recursive binary relationship occurs when an entity is related o itself. An example might be "some employees are married to other employees". A ternary relationship involves the three entities and is used when a binary relationship is inadequate. Many modeling approaches recognize only binary relationships. Ternary or n-ary relationships are decomposed into two or more binary relationships. Connectivity and Cardinality The connectivity of a relationship describes the mapping of associated entity instances in the relationship. The values of connectivity are "one" or "many". The cardinality of a relationship is the actual number of related occurrences for each of the two entities. The basic types of connectivity of the relations are: one-to-one, one-to-many, many-to-many. A one-to-one (1:1): is when at most one instance of an entity A is associated with one instance of entity B. for example: Employees in a company are each assigned their own office. For each employee there exists a unique office and for each office there exists a unique employee. A one-to-many (1:N): is when for one instance of entity A, there are zero, one, or many instances of entityB, but for one instance of entity B, there is only one instance of entity A. for example: A department has many employees. Each employee is assigned to one department. A many-to-many (M:N): relationship, sometimes called non-specific, is when for one instance of entity A, there are zero, one, or many instances of entity B and for one instance of entity B there are zero, one, or many instances of entity A. for example: Employees can be assigned to no more than two projects at the same time. Projects must have assigned at least three employees. The symbols used are Entity

Attributes

Relationship

Lines

ERDIAGRAM Sh_id Cost_id Seat_inf o Date_to Th_id Movie req U_id T_id Seate_wa nted Date M_name Sele ct Sh_id Has Show Reservati on Time Has Show Language M_id M_n ame Add movie

Cost No_of_sea t Seat_ty pe

Depe nded

Th_id

Seat_in fo

Depe nded

Has U_id Amt Payment Pay_id Date_of _pay M_id Votting U_id Feedba ck Voting Depe nded

Has

Feedba ck

U_id

DATABASE DESIGN A database is a collection of interrelated data stored with minimum redundancy to server many users quickly and effectively. The database serves as the repository of data, so a well designed database can lead to a better program structure and reduce procedural complexity. In a database environment, common data are available and used by several users. Database design is considered as a standard for management information systems and is available virtually for every computer system. The general theme behind a database is to handle information as an integrated whole. A database is a collection of interrelated data stored with minimum redundancy to serve many users quickly and effectively. After designing input and output, the analyst must concentrate on database design or how data should be organized around user requirements. The general objective is to make information access, easy quick, inexpensive and flexible for other users. During database design the following objectives are concerned: Controlled Redundancy Ease of learning and use Data independence More information at low cost Accurate and integrating Recovery from failure Privacy and security Performance SPECIFIC OBJECTIVES IN DATABASE DESIGN ARE EXPLAINED BELOW: Controlled Redundancy A unique aspect of database is storing data only once, which controls redundancy and improves system performance. Ease of learning and use Database should be modified without interfering with established ways of using data. Data independence It refers to the ability to add new data without rewriting an application program. More information at low cost Using, storing and modifying more information at low cost is important. Accuracy and integrity The accuracy of database ensures that data quality and content remain constant. Integrity controls detect data inaccuracies when they occur. Recovery from failures With multi-user access to a database, the system must recover quickly after it is down with no loss of transaction. Privacy and Security Database should be prevented from unauthorized access. Users must be positively identified and their action monitored.

Performance This emphasizes on the response time to enquire suitable to the use of data.

KEY A Key is column or column used to identify rows: it is not as same as an index Primary Key: The primary key is the column(s) used to uniquely identify, the values of which uniquely identify each row of the table. The primary key of a relational table uniquely identifies each record in the table. It can either be a normal attribute that is guaranteed to be unique (such as Social Security Number in a table with no more than one record per person) or it can be generated by the DBMS (such as a globally unique identifier, or GUID, in Microsoft SQL Server). Primary keys may consist of a single attribute or multiple attributes in combination. Candidate Key: A candidate key is a combination of one or more columns, the values of which uniquely identify each row of the table. A candidate key is a combination of attributes that can be uniquely used to identify a database record without any extraneous data. Each table may have one or more candidate keys. One of these candidate keys is selected as the table primary key. The candidate keys of a relation tell us all the possible ways we can identify its tuples. As such they are an important concept for the design database schema.For practical reasons RDBMSs usually require that for each relation one of its candidate keys is declared as the primary key, which means that it is considered as the preferred way to identify individual tuples. Foreign keys, for example, are usually required to reference such a primary key and not any of the other candidate keys. Foreign Key: A foreign key is one or more column whose value is based on the primary or candidate key values from another. A foreign key is a field in a relational table that matches the primary key of another table. The foreign key can be used to cross-reference tables. The foreign key identifies a column or a set of columns in one (referencing) table that refers to a set of columns in another (referenced) table. The columns in the referencing table must be the primary key or other candidate key in the referenced table. The values in one row of the referencing columns must occur in a single row in the referenced table. Thus, a row in the referencing table cannot contain values that don't exist in the referenced table (except potentially NULL). This way references can be made to link information together and it is an essential part of database normalization. Multiple rows in the referencing table may refer to the same row in the referenced table. Most of the time, it reflects the one (parent table or referenced table) to many (child table, or referencing table) relationship. The referencing and referenced table may be the same table, i.e. the foreign key refers back to the same table. Such a foreign key is known in SQL:2003 as a self-referencing or recursive foreign key. A table may have multiple foreign keys, and each foreign key can have a different referenced table. Each foreign key is enforced independently by the database system. Therefore, cascading relationships between tables can be established using foreign keys. Improper foreign key/primary key

relationships or not enforcing those relationships are often the source of many database and data modeling problems. Unique Key: A unique is a one or more column that must be unique for row of table. Unique is allowed to be null.

Login Field Name username password type User reg Field Name user_name user_pass user_id first_name last_name gender dob mob_num email_id question answer Show Field Name Sh_id theatreid Show Time Add Movie Field Name Movieid Moviename Language Director Cast&Crew Music Plot Data Type Varchar Varchar int Size 15 15 5 Constraints Not null Not null Not null Description Username Password User/Theatre Manager/Admin

Data Type Varchar Varchar Int Varchar Varchar Varchar Varchar Numeric Varchar Varchar Varchar

Size 15 15 6 15 15 6 10 10 20 20 20

Constrains Not null Not null Primary key Not null Not null Not null Not null Not null Not null Not null Not null

Description User name User password User identity First name Last name User gender User date of birth Mobile number Email address Security Question Answer

Data Type Int int Varchar Varchar

Size 6 6 10 10

Constrains Primary key Not null Not null Not null

Description Show Identity Show theatre Show Name Time of show

Data Type int Varchar Varchar Varchar Varchar Varchar Varchar

Size 6 25 25 15 100 15 25

Constrains Primary key Not null Not null Not null Not null Not null Not null

Description Movie Identity Movie Name Movie Language Director Cast&Crew Music Plot

Length Release_date Img

Varchar Datetime Nvarchar

10 5

Not null Not null Not null

Lengtof Movie ReleasingDate Image

Add Cost Field Name Cost_id Thaetreid Seat _type Amount Movie Request Field Name Reqid Theatre_id M_name Language Director Cast&Crew Show movie Field Name Show_movieid Sh_id M_id Start_date End_date Seattype Amount Theatre reg Field Name Th_id Th_name Location Address Contact_no No_of_seat

Data Type Int int Varchar int

Size 6 6 10 3

Constrains Primary key Not null Not null Not null

Description Cost Identity Theatre identity Type of seat Amount

Data Type int Int Varchar Varchar Varchar Varchar

Size 10 10 25 25 20 50

Constrains Primary key Foreign key Not null Not null Not null Not null

Description Request identity Request Identity Movie name Language director Cast and crew

Data Type Int Int Int datetime Datetime Varchar Decimal

Size 6 6 6

Constrains Primary key Foreign key Foreign key Not null Not null Not null Not null

10 6

Description Show movie Identity Show identity Movie Identity Starting date Ending date Seat type Amount

Data Type int Varchar Varchar Varchar Varchar Int

Size 6 20 15 50 10 4

Constrains Primary key Not null Not null Not null Not null Not null

Description Theatre Identity Theatre Name Location Address Contact number No of Seat

Licence_no Class Date Status Username

Varchar Varchar Datetime Int Varchar

15 6 6 20

Not null Not null Not null Not null Not null

Licence Number A,B,C Class Date Status User name

Seat_Information Field Name Data Type Th_id int Seat_type varchar No_of_seat int Reservation Field Name Ticket_id User_id Movie_id Show No_of_seats Theatre_id Date_of_reser Amount Feedback Field Name F_id U_id Feedback Status Type Payment Field Name Pay_id U_id Date_of_pay Amt History Field Name User name

Size 6 50 4

Constrains Primary key Notnull Not null

Description Theatre Identity Seat type No of Seat

Data Type int Int Int Varchar Varchar Int Datetime Decimal

Size 6 6 6 20 10 6 6

Constrains Primary key Foreign key Foreign key Not null Not null Not null Not null Not null

Description Ticket Identity User Identity Movie identity Show Number of seats Theatre identity Date of resrvation Amount

Data Type int Int Varchar Varchar Int

Size 6 6 200 10 10

Constrains Primary key Foreign key Not null Not null Not null

Description Feedback Identity User Identity Feedback Status Type

Data Type int Int Datetime Bigint

Size 6 6

Constrains Primary key Foreign key Not null Not null

Description Payment Identity User Identity Date of payment Amount

Data Type Varchar

Size 10

Constrains Primary key

Description User identity

Movie Date Total_seat

Varchar Date time Varchar

10 10

Not nul Not null Not null

Movie Date Total seat

Location Field Name Loc_id Location User_vote Field Name User_id Movie_id Date_of_vote Votting Field Name Movie_id Rate

Data Type Int Varchar

Size 6 20

Constrains Primary key Not null

Description Location identity Location

Data Type Int Int Datetime

Size 6 6

Constrains Primary key Forign key Not null

Description User id Movie id Date of vote

Data Type Int Int

Size 6 6

Constrains Primary key Not null

Description Movie identity Rate

NORMALIZATION Designing a database is a complex task and the normalization theory is a useful aid in the design process. The process of normalization is concerned with transformation of conceptual schema in to computer representation form. There will be need for most databases to grow by adding new attributes and new relations. The data will be used in new ways.Tuples will be added and deleted. Information stored may undergo updating also. New association may also be added. In such situations the performance of a database entirely depends upon its design. A bad database design may lead to certain undesirable things like. Repetition of information Inability to represent certain information Loss of information To minimize these anomalies, Normalization may be used. If the database is in a normalized form, the data can be restructured, and the database can grow without, in most cases, forcing the rewriting of application programs. This is important because of the excessive and growing cost of maintaining an organizations application programs and its data from the disrupting effects of database growth. As the quality of application programs increases, the cost of maintaining them without normalization will rise to prohibitive levels. A normalized database can also encompass many related activities of an organization thereby minimizing the need for rewriting the application s of programs. Thus normalization helps one attain a good database design and there by ensures continued efficiency of database NORMAL FORMS First Normal Form: A relation is in first normal form (1 NF), if and only if all its attributes are based on single domain. The objective of normalizing a table is to remove its repeating groups and ensure that all entries of the resulting table have at most single value. Second Normal Form: A table is said to be in second normal form (2 NF), when it is in 1 NF and every attribute in the record is functionally dependent upon the whole key, and not just a part of the key. Third Normal Form: A relation is said to be in 3NF if and only if, for all the nontrivial dependencies in F of the form XA, either X contains a key (X is a super key) or A is the prime attribute. 3NF is achieved when transitive dependencies are removed from a record design. Some of the non-key attributes are dependent not only on the primary key but also on a non-key attribute. There are additional normalization levels such as Boyce-code Normal Form (BCNF), fourth normal Form (4 NF) and fifth normal form (5 NF). While normalization makes databases more efficient into so many different tables. The tables in our system are normalized into third normal form.

BENEFITS OF NORMALIZATION Helps to simplify the structure of tables. To structure the data so that there is no repetition of data, that helps in saving spaces. To permit simple retrieval of data in response to query and report requests. To simplify the maintenance of data through updates, insertions and deletions. To reduce the need to restructure data when new application requirement arise. Greater overall database organization. Data consistency within the database. Much more flexible database design. A better handle on database security. CLASS DIAGRAM Class diagrams are widely used to describe the types of objects in a system and their relationships. Class diagrams model class structure and contents using design elements such as classes, packages, and objects. Class diagrams describe three different perspectives when designing a system, conceptual, specification, and implementation. These perspectives become evident as the diagram is created and help solidify the design. Class is composed of three things: a name, attributes, and operations. A class diagram is an illustration of the relationships and source code dependencies among classes in the Unified Modeling Language (UML). In this context, a class defines the methods and variables in an object, which is a specific entity in a program or the unit of code representing that entity. Class diagrams are useful in all forms of object-oriented programming (OOP). The concept is several years old but has been refined as OOP modeling paradigms have evolved. In a class diagram, the classes are arranged in groups that share common characteristics. A class diagram resembles a flowchart in which classes are portrayed as boxes, each box having three rectangles inside. The top rectangle contains the name of the class; the middle rectangle contains the attributes of the class; the lower rectangle contains the methods, also called operations, of the class. Lines, which may have arrows at one or both ends, connect the boxes. These lines define the relationships, also called associations, between the classes.

USECASE DIAGRAM A use case is a set of scenarios that describing an interaction between user and system. A use case diagram displays the relationship among the actors and use cases. The two main components of a use case diagram are use cases and actors.

Actor

Usecase

A use case is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents action the user might perform in order to complete a task Uses cases are used in almost every project. They are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible. A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted. Use Case diagrams are formally included in two modeling languages defined by the OMG: the Unified Modeling Language (UML) and the Systems Modeling Language (SysML).

USE CASE DIAGRAM

Seat information Add movie Movie request Assume show movie Theatre mgt Add cost Send feed back Add show Registration Change password

Add movie Assume show movie Add cost Send feed back Add show View payment details Movie mgt View feed back

Approve theatre

Reservation

Payment

Reservation mgt

History

Send feed back Voting

User mgt

Change password

User registration