PROJECT

REPORT
ON
“BUS RESERVATION SYSTEM”

Project Submitted in partial fulfillment

of the requirement of the award of
degree of
(BCA Project)
Table of Contents

Chapter 1 Introduction

Chapter 2 Development model

Chapter 3 System Study

Chapter 4 Project Monitoring

System
Chapter 5 System Analysis

Chapter 6 Technology Used

Chapter 7 System Design

Chapter 8 System Testing

Chapter 9 System Implementation

Chapter 10 Conclusion

Chapter 11 Scope of the Project

Introduction
In bus reservation system there has been a collection of buses, agent who are
booking tickets for customer’s journey which give bus number and departure
time of the bus. According to its name it manages the details of all agent,
tickets, rental details, and timing details and so on. It also manages the updating
of the objects.

In the tour detail there is information about bus, who has been taking
customers at their destination, it also contain the detailed information about the
customer, who has been taken from which bus and at what are the number of
members he or she is taking his/her journey.

This section also contain the details of booking time of the seat(s) or
collecting time of the tickets, this section also contain the booking date and the
name of agent which is optional, by which the customer can reserve the seats
for his journey

In Bus no category it contains the details of buses which are

old/new. New buses are added with the details with bus no, from city to the
city, type of the bus, rent of a single seat, if the bus has sleeper than the cost of
sleeper, if the cabin has the facility for sitting than the cost of cabin seats, tour
timings of the new bus has also been stored. How many buses are currently
given and available in office?

In seats specification it gives the list of given issued and currently

available seats and contain the information about seats like sleeper, cabin etc.

The main objective of this project to provide the better work efficiency,
security, accuracy, reliability, feasibility. The error occurred could be reduced
to nil and working conditions can be improved.

Development model
Development model

Software Process Model

Our project life cycle uses the waterfall model, also known as classic life cycle
model or linear sequential model.

System/Information
Engineering

Analysis Design Code Test

The Waterfall Model

The waterfall model encompasses the following activities:

1. System/information Engineering and Modeling

System Engineering and Analysis encompass requirements gathering at the

system level with a small amount of Top-level design and analysis. Information
Engineering encompasses requirements gathering at the strategic business level
and at the business area level.

2. Software requirements analysis

Software requirements analysis involves requirements for both the system and
the software to be document and reviewed with the customer.

3. Design

Software design is actually a multi-step process that focuses on for distinct

attributes of a program: data structure, software architecture, interfaces
representation and procedural detail. The design process translates
requirements into a representation of the software that can be accessed for
quality before coding begins.

4. Code Generation

Code-Generation phase translates the design into a machine-readable form.

5. Testing

Once code has been generated, program testing begins. The testing focuses on
the logical internals of the software, ensuring that all statement have been
tested, and on the functional externals; that is, conducting test to uncover errors
and ensure that define input will produce actual results that agree with required
results.

6. Support
Software will undoubtedly undergo change after it is delivered to the customer.
Change will occur because errors have been encountered, because the software
must be adapted to accommodate changes in its external environment or
because the customer requires functional or performance enhancements .

System Study
Before the project can begin, it becomes necessary to estimate the work to be
done, the resource that will be required, and the time that will elapse from start
to finish. During making such a plan we visited site many more times.

2.1 Project planning objectives

The objective of software project planning is to provide a framework that

enables the management to make reasonable estimates of resources, cost, and
schedule. These estimates are made within limited time frame at the beginning
of a software project and should be updated regularly as the project progresses.
In addition, estimates should attempt to define best case and worst case
scenarios so that project outcomes can be bounded.

2.2 Software Scope

The first activity in software project planning is the determination of software

scope. Software scope describes the data and control to be processed, function,
performance, constraints, interfaces, and reliability.

2.2.1 Gathering Information Necessary for Scope

 The most commonly used technique to bridge communication gap between
customer and the software developer to get the communication process started
is to conduct a preliminary meeting or interview. When I visited the site we
have been introduced to the Manager of the center, there were two another
persons out of one was the technical adviser and another one was the cost
accountant. Neither of us knows what to ask or say; we were very much
worried that what we say will be misinterpreted.

We started to asking context-free questions; that is, a set of questions that will
lead to a basic understanding of the problem. The first set of context-free
questions was like this:
What do you want to be done?
Who will use this solution?
What is wrong with your existing working systems?
Is there another source for the solution?

 Can you show us (or describe) the environment in which the solution
will be used?
After first round of above asked questions. We revisited the site and asked
many more questions considering to final set of questions.

 Are our questions relevant to the problem that you need to be solved?
 Are we asking too many questions?
 Should we be asking you anything else?

2.2.2 Feasibility

Not everything imaginable is feasible, not even in software. Software

feasibility has four dimensions:
 Technology—is a project technically feasible? Is it within the state of the
art?

Finance – Is it financially feasible?

Time—will the project be completed within specified time?

Resources—does the organization have the resources needed to succeed?

After taking into consideration of above said dimensions, we found it could be

feasible for us to develop this project.

.3 Software Project Estimation

Software cost and effort estimation will never be an exact science. Too may
variables—human, technical, environmental, political—can affect the ultimate
cost of software and effort applied to develop it. However, software project
estimation can be transformed a black art to a series of systematic steps that
provide estimates with acceptable risk.

To achieve reliable cost and effort estimates, a number of options arise:

1. Delay estimation until late in the project (since, we can achieve

100% accurate estimates after the project is complete!)
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project
cost and effort estimates.
4. Use one or more empirical models for software cost and effort

estimation.

Unfortunately, the first option, however attractive, is not practical. Cost estimates
must be provided “Up front”. However, we should recognize that the longer we
wait, the more we know, and the more we know, the less likely we are to make
serious errors in our estimates.
 The second option can work reasonably well, if the current project is quite
similar to past efforts and other project influences (e.g., the customer, business
conditions, the SEE, deadlines) are equivalent. Unfortunately past experience has
not always been a good indicator of future results.

The remaining options are viable approaches the software project estimation.
Ideally, the techniques noted for each option be applied in tandem; each used as
cross check for the other. Decomposition techniques take a “divide and conquer”
approach to software project estimation. By decomposing a project into major
functions and related software engineering activities, cost and effort estimation
can be performed in the stepwise fashion.

Empirical estimation models can be used to complement decomposition

techniques and offer a potentially valuable estimation approach in their own
right. A model based on experience (historical data) and takes the form

D = f (vi)

Where d is one of a number of estimated values (e.g., effort, cost, project

duration and we are selected independent parameters (e.g., estimated LOC (line
of code)).

Each of the viable software cost estimation options is only as good as the
historical data used to seed the estimate. If no historical data exist, costing rests
on a very shaky foundation.

Project Monitoring System

4.1 PERT Chart

Program evaluation and review technique (PERT) and critical path

method (CPM) are two project scheduling methods that can be applied to
software development. These techniques are driven by following information:

 Estimates of Effort
 A decomposition of the product function
  The selection of the appropriate process model and task set
 Decomposition of tasks
PERT chart for this application software is illustrated in figure 3.1. The critical
Path for this Project is Design, Code generation and Integration and testing.
Aug-2008

Requirement Design Integration

Start Analysis and test
Aug 1, 2008 Aug 5, 2008 Oct 10 2008
Figure 4.1 PERT charts for “University Study Center
Coding

Aug 15,2008

Documentati Finish
on and Jan 3, 2008
Report
Oct 30, 2008
Management System”.

4.2 Gantt Chart

Gantt chart which is also known as Timeline chart contains the

information like effort, duration, start date, completion date for each task. A
timeline chart can be developed for the entire project.
Below in figure 4.2 we have shown the Gantt chart for the project. All project
tasks have been listed in the left-hand column.
Start: Jan 1, 2008.

Planned Actual Planned Actual Notes

Work tasks start start complete Complete
1.1 Identify needs and benefits

Meet with customers Wk1,d1 Wk1,d1 Wk1,d2 Wk1,d2

Identified needs and constraints Wk1,d2 Wk1,d2 Wk1,d2 Wk1,d2

Established Product Statement Wk1,d3 Wk1,d3 Wk1,d3 Wk1,d3

Milestone:Product statement defined Wk1,d3 Wk1,d3 Wk1,d3 Wk1,d3

1.2 Defined Analysis

Desiredoutput/control/input (OCI) and design

Scope modes of interacton Wk2,d1 Wk2,d2 is more

Documented (OCI) Wk2,d1 Wk2,d3 time

FTR: reviewed OCI with customer Wk3,d3 Wk3,d5 consuming.

Revised OCI as required Wk4,d1 Wk4,d2

Milestore: OCI defined Wk4,d3 Wk4,d5

1.3 Defined the function/behavior

Milestone: Data Modeling completed Wk5,d1 Wk5,d2 Wk5,d5

1.4 Isolation software elements

Coding Wk5,d1 Wk6,d1 W7,d5

Reports Wk7,d6 W8,d6

1.5 Integration and Testing W9,d1 W9,d3 W11,d3

Finish: Jan 3,

2008

Figure: 4.2 Gant chart for the Project University Study Center Management
System. Note: Wk1—week1, d1—day1.

System Analysis
 Software requirements analysis is a process of discovery, refinement,
modeling, and specification. Requirement analysis proves the software designer
with a representation of information, function, and behavior that can be
translated to data, architectural interface, and component -level designs. To
perform the job properly we need to follow as set of underlying concepts and
principles of Analysis.

5.1 Analysis Principles

Over the past two decades, a large number of analysis modeling

methods have been developed. Investigators have identified analysis problems
and their caused and have developed a variety of modeling notations and
corresponding sets of heuristics to overcome them. Each analysis method has a
unique point of view. However, all analysis methods are related by a set of
operational principles:

1. The information domain of a problem must be represented and understood.

2. The functions that the software is to perform must be defined.
3. The behavior of the software (as a consequence of external events) must be
represented.
4. The models that depict information function and behavior must be
partitioned in a manner that uncovers detail in layered (or hierarchical)
fashion.
5. The analysis process should move from essential information toward
implementation detail.

By applying these principles, we approach the problem systematically. The

information domain is examined so that function may be understood more
completely. Models are used so that the characteristics of function and behavior
can be communicated in a compact fashion. Partitioning is applied to reduce
complexity. Essential and implementation vies of the software are necessary to
accommodate the logical constraints imposed any processing requirements and
the physical constraints imposed by other system elemIn addition to these
operational analysis principles, Davis suggests a set o guiding principles for
requirements analysis:

 Understand the problem before you begin to create the analysis

model. There is a tendency to rush to a solution, even before the
problem is understood. This often leads to elegant software that
solves the wrong problem! We always tried to escape from such
situation while making this project a success.
 Develop prototypes that enable a user to understand how
human/machine interaction will occur. Since the perception of the
quality of software is ofter based on the perception ot the
“friendliness” of the interface, protoptying (and the iteration that
results) are highly recommended.
 Record the origin of and the reason for every requirement. This is
the first step in establishing traceability back to the customer.
 Use multiple views of requirements. Building data, functional, and
behavioral models provide the software developer with three views.
This reduces the likelihood that something will be missed and
increases the likelihood that inconsistency will be recognized.
 Rank requirements. Tight deadlines may preclude the
implementation of every software requirement.
 Work to eliminate ambiguity. Because most requirements are
described in a natural language, the opportunity for ambiguity
abounds. The use of formal technical reviews is one way to uncover
and eliminate ambiguity.

We have tried to takes above said principles to heart so that we could

provide an excellent foundation for design.
5.1.1 The Information Domain

All software applications can be collectively called data processing. Software is

built to process data, to transform data from one form to another; that is, to
accept input, manipulate it in some way, and produce output. This fundamental
statement of objective is true whether we build batch software for a payroll
system or real-time embedded software to control fuel flow to an automobile
engine.

The first operational analysis principle requires an examination of the

information domain and the creation of a data model. The information domain
contains three different views of the data and control as each is processed by a
computer program:

(1) information contend and relationships (the data model)

(2) information flow, and
(3) Information structure.

To fully understand the information domain, each of these views should be

considered.

Information content represents the individual data and control objects

that constitute some larger collection of information transformed by the
software. For example, the data object, Status declare is a composite of a
number of important pieces of data: the aircraft’s name, the aircraft’s model,
ground run, no of hour flying and so forth. Therefore, the content of Status
declares is defined by the attributes that are needed to create it. Similarly, the
content of a control object called System status might be defined by a string of
 bits. Each bit represents a separate item of information that indicates whether
or not a particular device is on-or off-line.

Data and control objects can be related to other data and control objects.
For example, the date object Status declare has one or more relationships with
the objects like total no of flying, period left for the maintenance of aircraft an
others.

Information flow represents the manner in which date and control

change as each moves through a system. Referring to figure 6.1, input objects
are transformed to intermediate information (data and / or control), which is
further transformed to output. Along this transformation path, additional
information may be introduced from an existing date store ( e.g., a disk file or
memory buffer). The transformations applied to the date are functions or sub
functions that a program must perform. Data and control that move between
two transformations define the interface for each function.

Figure 5.1 Information flow and transformation.

Input Intermediate Output Transf

Objects data and Object(s) m
control #1

5.1.2 Modeling
The second and third operational analysis principles require that we build
models of function and behavior.

Functional models. Software transforms information, and in order to

accomplish this, it must perform at lease three generic functions:

 Input
 Processing
 And output.

The functional model begins with a single context level model (i.e., the name
of the software to be built). Over a series of iterations, more and more
functional detail is gathered, until a through delineation of all system
functionality is represented.

Behavioral models. Most software responds to events from the outside

world. This stimulus/response characteristic forms the basis of the behavioral
model. A computer program always exists in some state- an externally
observable mode of behavior (e.g., waiting, computing, printing, and polling)
that is changed only when some even occurs. For example, in our case the
project will remain in the wait state until:

 We click OK command button when first window appears

 An external event like mouse click cause an interrupt and
consequently main window appears by asking the username and
password.
 This external system (providing password and username) signals the
project to act in desired manner as per need.

A behavioral model creates a representation of the states of the software and

the events that cause software to change state.
5.1.2 Partitioning (Divide)

Problems are often too large and complex to be understood as a whole,

for this reason, se tend to partition (divide) such problems into parts that can be
easily under stood and establish interfaces between the part so that overall
function can be accomplished. The fourth operational analysis principle
suggests that the information, functional, and behavioral domains of software
can be partitioned.

In essence, partitioning decomposes problem intoits constituent parts.

Conceptually, we establish a hierarchical representation of function or
information and then partition and uppermost element by

(1) exposing increasing detail by moving vertically in the hierarchy

or
(2) Functionally decomposing the problem my moving horizontally
in the hierarchy.
To issulstate these partitioning approaches let us consider our project
“Bus Reservation System”. Horizontal partitioning and vertical partitioning of
Bus Reservation system is shown below.

Horizontal partitioning:

Bus Reservation System

System configuration Password acceptance Interact with user

 During installation, the software (Bus Reservation System) used
to program and configure the system. A master password is programmed for
getting in to the software system. After this step only user can work in the
environments (right cornor naming operation, administration and maintenance)
only.

Vertical partitioning of Bus Reservation System function.

Bus Reservation System

Configure system Username and Password

Acceptance Rejection

Interact with user Fail Retry

5.2 Software Prototyping.

Some circumstances require the construction of a prototype at the

beginning of analysis, since the model is the only means through which
requirements can be effectively derived. The model then evolves into
production software.
5.2.1 Selecting the Prototype Approach
The prototyping paradigm can be either close-ended or open-ended. The
close-ended approach is often called throwaway prototyping. Using this
approach, a prototype serves solely as a rough demonstration of requirements.
It is then discarded, and the software is engineered using a different paradigm.
An open-ended approach, called evolutionary prototyping, uses the prototype
as the first part of an analysis activity that will be continued into design and
construction. The prototype of the software is the first evolution of the finished
system.

Before a close-ended or open-ended approach can be chosen, it is

necessary to determine whether the system to be built is amenable to
prototyping. A number of prototyping candidacy factors can be defined:
application area, application complexity, customer characteristics, and project
characteristics.
Figure 5.5 selecting the appropriate prototyping approach

Throwawa Evolutiona Additional

y ry preliminary work
Question Prototype prototype required
Is the application domain Yes Yes No
understood?
Can the problem be modeled? Yes Yes No
Is the customer certain of basic
system requirements? Yes/No Yes/No No
Are requirements established and
stable? No Yes Yes
Are any requirements
ambiguous? Yes No Yes
Are there contradictions in the
requirements? Yes No Yes

The above six questions are made as per the Andriole suggestions for
prototyping approach.
 E-R DIAGRAM:

BUS RESERVATION
SYSTEM

Give
service
Divid

BUSES

Work
area
Care
DIFFERENT
examin TYPE OF Full
Wor
BUSES
SLEEPER
OR
WITHOUT DEPARTMENT SEATS
SLEEPER
The following DFD shows how the working of a reservation system could be
smoothly managed:

WORK AREAS

DEPTT WITH ITS AGENT

BUSES

BUSES RESERVED
RECORDS AGENT

DAILY ENTRY VISITING

REC AGENT

AGENT
DETAILS

REPORT TABLE
DETAIL DESCRIPTION OF DATA FLOW DIAGRAM:

We have STARBUS as our database and some of our tables (relation) are

such as AGENT_BASIC_INFO, FEEDBACK, PASSANGER_INFO, STATIS

and TIMELIST

STARBUS

AGENTBASICINFO

FEEDBACK

PASSANGERIFNO

STATIS

TIMELIST
In our table AGENT_BASIC_INFO we have following field such as agent_id,

agent_name, agent_name, agent_fname, agent_shop_name,

agent_shop_address, agent_shop_city, agent_phon_number etc.

AGENT_BASIC_INFO

AGENT_ID

AGENT_NAME

AGENT_FNAME

AGENT_SHOP_NAME

AGENT_SHOP_ADDRESS

AGENT_SHOP_CITY

AGENT_PHON_NUMBER

AGENT_MOBIL_NUMBER

AGENT_CURRENT_BAL
In our FEEDBACK table we have fields like name, Email, Phon, Subject,

Comment, and User_type.

Email
Name
Phone

FEEDBACK

Comment Subject

User_type
In our table PASSANGER_INFO we have filed like bill_no, c_name, c_phone,

c_to, c_from, c_time, Ttalseat, Seatnumber, Amount, Agent_id and Status.

C_name
C_phon
Bill_no
C_to

Status
PASSANGER
_INFO C_from

Agent_id
C_time

Amount
Seat_no
Total_seat
In the table of TIME_LIST we have fields such as Sno, Satation_name,

Rate_per_seat, Time, Reach_time and Bus_number.

Station_name
Sno
Rate_perSeat

TIME_LIST

Bus_number Time

Reach_time

PROCESS LOGIC:

As the privatization of buses is increasing thus the need of its smooth

management is also increasing the more we could facilitate the customers,

the more they are comfortable with us, the more customers we have

visiting our reservation unit .the above tables and modules facilitates

many logics like:

 Number of buses in one unit

 Number of computers in particular department

 Number of users in a department

 Which bus has what tour on which day

 What are time table for different buses of different department

 What are the schedule for buses

 Schedule of a particular bus

 How many buses are there

 Each bus has how many seats

 How many seats are occupied

 Advance booking for seat

 How much money is collected in a particular day

 Bills for different customers

 Which seat has booked by agent

 Technology used
6.1 Tools and Platform used for the Development

6.1.1 Front-end Environment (.NET Framework)

The Internet revolution of the late 1990s represented a dramatic shift in the way
individuals and organizations communicate with each other. Traditional
applications, such as word processors and accounting packages, are modeled as
stand-alone applications: they offer users the capability to perform tasks using
data stored on the system the application resides and executes on. Most new
software, in contrast, is modeled based on a distributed computing model
where applications collaborate to provide services and expose functionality to
each other. As a result, the primary role of most new software is changing into
supporting information exchange (through Web servers and browsers),
collaboration (through e-mail and instant messaging), and individual
expression (through Web logs, also known as Blogs, and e-zines — Web based
magazines). Essentially, the basic role of software is changing from providing
discrete functionality to providing services.
The .NET Framework represents a unified, object-oriented set of services and
libraries that embrace the changing role of new network-centric and network-
aware software. In fact, the .NET Framework is the first platform designed
from the ground up with the Internet in mind.

Microsoft .NET Framework is a software component that is a part of several

Microsoft Windows operating systems. It has a large library of pre-coded
solutions to common programming problems and manages the execution of
programs written specifically for the framework. The .NET Framework is a key
Microsoft offering and is intended to be used by most new applications created
for the Windows platform.
Benefits of the .NET Framework

The .NET Framework offers a number of benefits to developers:

A consistent programming model
Direct support for security
Simplified development efforts
Easy application deployment and maintenance

The .NET Class Library is a key component of the .NET Framework — it is

sometimes referred to as the Base Class Library (BCL). The .NET Class
Library contains hundreds of classes you can use for tasks such as the
following:

Processing XML
Working with data from multiple data sources
Debugging your code and working with event logs
Working with data streams and files
Managing the run-time environment
Developing Web services, components, and standard Windows applications
Working with application security
Working with directory services

The functionality that the .NET Class Library provides is available to all .NET
languages, resulting in a consistent object model regardless of the
programming language developer’s use.
Elements of the .NET Framework

The .NET Framework consists of three key elements as show in below diagram

VB.NET VC#.NET VC++.NET JSCRIPT.NET

ASP.NET
Window Forms
Web Server Web Form Visual

Studio.NET

.NET Class Library

System Data I/O Security

Common Language Runtime

Common Type System

Operating System

Components of the .NET Framework

Common Language Runtime

.NET Class Library
Unifying components

1. Common Language Runtime

The Common Language Runtime (CLR) is a layer between an application and
the
operating system it executes on. The CLR simplifies an application's design
and reduces the amount of code developers need to write because it provides a
variety of execution services that include memory management, thread
management, component lifetime management, and default error handling.

The CLR is also responsible for compiling code just before it executes. Instead
of
producing a binary representation of your code, as traditional compilers
do, .NET
compilers produce a representation of your code in a language common to
the .NET Framework: Microsoft Intermediate Language, often referred to as
IL. When your code executes for the first time, the CLR invokes a special
compiler called a Just In Time (JIT) compiler, Because all .NET languages
have the same compiled representation, they all have similar performance
characteristics. This means that a program written in Visual Basic .NET can
perform as well as the same program written in Visual C++ .NET.

2 .NET Class Library

The .NET Class Library containing hundreds of classes that model the system
and services it provides. To make the .NET Class Library easier to work with
and understand, it's divided into namespaces. The root namespace of the .NET
Class Library is called System, and it contains core classes and data types, such
as Int32, Object, Array, and Console. Secondary namespaces reside within the
System namespace.

Examples of nested namespaces include the following:

System.Diagnostics: Contains classes for working with the Event Log
System.Data: Makes it easy to work with data from multiple data sources
System.IO: Contains classes for working with files and data streams

The benefits of using the .NET Class Library include a consistent set of
services available to all .NET languages and simplified deployment, because
the .NET Class Library is available on all implementations of the .NET
Framework.

3. Unifying components
Until this point, this chapter has covered the low-level components of the .NET
Framework. The unifying components, listed next, are the means by which you
can access the services the .NET Framework provides:

ASP.NET

Windows Forms
Visual Studio .NET

Characteristics

Pages

ASP.NET pages, known officially as "web forms", are the main building block
for application development. Web forms are contained in files with an ASPX
extension; in programming jargon, these files typically contain static (X)HTML
markup, as well as markup defining server-side Web Controls and User
Controls where the developers place all the required static and dynamic content
for the web page. Additionally, dynamic code which runs on the server can be
placed in a page within a block <% -- dynamic code -- %> which is similar to
other web development technologies such as PHP, JSP, and ASP, but this
practice is generally discouraged except for the purposes of data binding since
it requires more calls when rendering the page.
Note that this sample uses code "inline", as opposed to code behind.
<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<script runat="server">

protected void Page_Load(object sender, EventArgs

e)
{
Label1.Text =
DateTime.Now.ToLongDateString();
}

</script>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<title>Sample page</title>
</head>
<body>
<form id="form1" runat="server">
<div>
The current time is: <asp:Label
runat="server" id="Label1" />
</div>
</form>

</body>
</html>

Code-behind model

It is recommended by Microsoft for dealing with dynamic program code to use

the code-behind model, which places this code in a separate file or in a
specially designated script tag. Code-behind files typically have names like
MyPage.aspx.cs or MyPage.aspx.vb based on the ASPX file name (this
practice is automatic in Microsoft Visual Studio and other IDEs). When using
this style of programming, the developer writes code to respond to different
events, like the page being loaded, or a control being clicked, rather than a
procedural walk through the document.

ASP.NET's code-behind model marks a departure from Classic ASP in that it

encourages developers to build applications with separation of presentation and
content in mind. In theory, this would allow a web designer, for example, to
focus on the design markup with less potential for disturbing the programming
code that drives it. This is similar to the separation of the controller from the
view in model-view-controller frameworks.

Example

<%@ Page Language="C#"

CodeFile="SampleCodeBehind.aspx.cs"
Inherits="Website.SampleCodeBehind"
AutoEventWireup="true" %>

The above tag is placed at the beginning of the ASPX file. The CodeFile
property of the @ Page directive specifies the file (.cs or .vb) acting as the
code-behind while the Inherits property specifies the Class the Page derives
from. In this example, the @ Page directive is included in SamplePage.aspx,
then SampleCodeBehind.aspx.cs acts as the code-behind for this page:

using System;

namespace Website
{
public partial class SampleCodeBehind :
System.Web.UI.Page
{
 protected override void Page_Load(EventArgs e)
{
base.OnLoad(e);
}
}
}
In this case, the Page_Load () method is called every time the ASPX page is
requested. The programmer can implement event handlers at several stages of
the page execution process to perform processing.

System Design
1. Index page

This webpage is the starting page of the Website.It gives the followings:
  Login for the Admin and Agent
 TollFree number of the other city.
 Display adventage of the StarBus
 Links for TicketBooking, Agent and Recovery password.
 Links for Feedback, FAQ, Terms and Condition’s.
2. Status.

As in the above image the Status webpage is displaying:

 Accessed by anyone.
 Information about the booking which seat is booked and which
is empty.

3. Agent name.
As in the above image the Agent name webpage is displaying :

 Accessed by anyone.
 Contains information about name, address and phone number
of the agent.
4. Feedback
As in the above image Feedback webpage is displaying:

 This page is access by any user

 Anyone can give feedback related to the site or services.
 Links for Terms and Condition’s and Policy and Privacy.

5. FAQ
As in the above image FAQ webpage is displaying:

 This page is access by any user

 Contain information about tour and services of web site.
Such as how many agent office are there and what is the mode
Of the pament.
6. Privacy and Policy.

As in the above image the Privacy and Policy webpage is displaying:

 This page is access by any user

 This page say that when customer using our services, we
required information about customer his/her name, age, route and
email so that we can inform them to there email also.
7. Terms and Conditions.

As in the above image the Terms and Conditions webpage is

displaying:

 Accessed by anyone.
 Useful for customer
 Contain information when to reach the starting point and what
should do, in case when our ticket is lost.
8. Login page

As in the above image Login webpage is displaying:

 Accessed by the agent.

 Agent entered its user name and password and click on login.
 Contain link for Forget Password.
9. Forget Password Page

As in the above image Forget Password webpage is displaying:

 It required user name who forget its password and then click on
Next button.
 And also provide link for administration and other.
10. Identity Confirmation.

As in the above image Identify Confirmation for user webpage is

displaying:

 The Question you have select at the time of registration.

 You need to enter the answer for that question.
 After click on Next button. You will get your password on the
show password webpage.
 11. Ticket Booking page.

As in the above image the ticket booking page is displaying:

 Only accessed by the agent.

 Select the destination, depature date and time.
11. Select Seat page

As in the above image the Select Seat page is displaying:

 Only accessed by the agent.

 Red seat indicate booked seat. You can choose rest of the seat.
It converted into green seat.
12. Customer Information page

As in the above image the Customer Information webpage is displaying:

 After selecting the seat.

 Agent enters the name and phnumber of the customer.
 Click on Go button for printing the ticket.
13. Ticket Print page

As in the above image the Ticket print webpage is displaying:

 This page prints the Customer ticket.

 This contain customer information such as name, destination
Number of seat.
 These also reduce the agent balance.
14. Search Ticket.

As in the above image the Ticket Search webpage is displaying:

 Only accessed by the Agent and Administration.

 Using PNR number, Agent can search the ticket.
15. Ticket Cancellation

As in the above image the Ticket cancellation webpage is displaying—

 Only accessed by the Agent and Administration

 Using PNR number, Agent can see the status ticket.
16. Ticket Cancellation

As in the above image the Search Book webpage is displaying:

 Only accessed by the Agent and Administration

 Using PNR number, Agent can cancel the ticket.
17. Change Password

As in the above image the Change password web page is displaying:

 Only accessed by the Agent

 Agent can change password by entering the old and new
password
 Administrator Area

18. Create Agent

As in the above image the Change password web page is displaying:

 Only accessed by the Administrator.

 New agents are added by this page
 Required following information:-

 Username
  Password
 Email
 Security Question.
 Security Answer.

19. Create agent continue page

As in the above image the Create agents continue page web page is
displaying:

 After click on Create user button it brings you on this page.

 This shows confirmation of creation of the agent.
 After click on continue button it sent you on Agent Basic
Information webpage.
20. Agent Basic Information page

As in the above image the agent’s Basic information web page is

displaying:

 Agents Basic Information are added by this page

 Required following information are :-

 Name
 Father’s Name
 Shop Name
  Shop City
 Shop phone number
 Mobile Number
 Deposit amount

21. Agent List page

As in the above image the agent’s List web page is displaying:

 Only accessed by the Administrator.

 Displaying Agent information such as:-

 Agent ID
 Name
 Shop Name
 Shop City
 Current Balance
  Mobile Number

22. Agent Deposit Amount Page

As in the above image the agent’s Deposit Amount web page is

displaying:

 Only accessed by the Administrator.

 Requires agent name and amount he wants to deposit.
23. Agent Balance Page

As in the above image the agent’s Balance web page is displaying:

 Only accessed by the Administrator.

 Requires agent name and amount he wants to deposit.
24. Search Agent Page
25. Search Agent Page
Scope of the Project
Future scope of the project: -
The project has a very vast scope in future. The project can be implemented on
internet in future. Project can be updated in near future as and when
requirement for the same arises, as it is very flexible in terms of expansion.
With the proposed software of Web Space Manager ready and fully functional
the client is now able to manage and hence run the entire work in a much
better, accurate and error free manner. The following are the future scope for
the project: -

 The number of levels that the software is handling can be made

unlimited in future from the current status of handling up to N levels as
currently laid down by the software. Efficiency can be further enhanced
and boosted up to a great extent by normalizing and de-normalizing the
database tables used in the project as well as taking the kind of the
alternative set of data structures and advanced calculation algorithms
available.
 We can in future generalize the application from its current customized
status wherein other vendors developing and working on similar
applications can utilize this software and make changes to it according
to their business needs.

THANKYOU.