1.

INTRODUCTION

1.1 Motivation

1.2 Problem Definition

The college transport pass comprises of manual work for both transportation division and
furthermore for students by remaining over a line for a considerable length of time
close counters to complete their pass where the transportation office group, enter the
points of interest of the students physically. By proceeding with this manual
procedure it requires parcel of investment to see and favor the verifications given by
each candidate productively. The span is more between applying for the pass and
recovery of pass. For applying of pass the students ought to again visit adjacent
counters.

1.3 Objective of Project

The prime purpose of this Bus Management System is to create a fully fledged web
application which would communicate with the remote server to send and retrieve data as per
requirement. This application works when there is internet connectivity. This web application
generates exhaustive reports related to the Bus Management i.e. bus route, bus number,
number of students/faculty allotted for the particular bus, Department and ID of students,
departure time of the bus, fees paid and dues. These reports highlight various bus services and
features of the bus, which can be subjected to improvement especially for the college
administration to improve bus transport system. This interface is user friendly and effective.
It is very helpful by providing a simpler method to store and access information related to
buses and students. This system is accessible either by an administrator or student where in
the administrator has the permission to create/update the record into the database. This web
application reduces paper work and makes all related information accessible easily.

1.4 Limitation of Project

You cant find all the bus pass related information in transport
department.
This online bus pass software system will help users get bus
passes online and eliminate the need of standing in queues for
passes and wasting their time.

1
 The fee payment can be done in online through credit or debit
card.

2. Literature Survey

2.1 Introduction
This project is developed in Java under Windows platform. In this modern world of
computers, every noun of our vocabulary represents a class of objects sharing some set of
characteristics and functional traits. Java leads itself naturally in embodying these areas into
its own application domain.

2.1.1 Html

HTML, an acronym of Hyper Text Markup Language, is the predominant markup

language for web pages. It provides a means to describe the structure of text-based
information in a document by denoting certain text as links, headings, paragraphs, lists, and
so on and to supplement that text with interactive forms, embedded images, and other objects.
HTML is written in the form of tags, surrounded by angle brackets.

HTML can also describe, to some degree, the appearance and semantics of a
document, and can include embedded scripting language code (such as JavaScript) which can
affect the behavior of Web browsers and other HTML processors. Web pages are built with
the help of this HTML which are called the Web Documents.

2.1.2 Overview of JAVA:

Collection Framework:

A Collection (sometimes called a Container) is a group of data that is manipulated as a single

object. This corresponds to a bag.

The idea behind Java's Collection Framework (also called the Container Class
Library) is to insulate client programs from common implementations like an array, linked
list, hash table, balanced binary tree, etc.

The Collection Framework is very similar to the Standard Template Library (STL)
found in C++. Collections can contain only Object reference types (no primitives). The

2
programmer can make a container class thread safe (concurrent access) as well as making it
not-modifiable.

Fig 1.1 Collections Hierarchy

Collections Framework takes the issue of "holding your objects" and divides it into
two distinct concepts: Collections and Maps. The key distinction between the two types of
containers is the number of items that each holds in an individual location. A Collection holds
one element while a Map holds two.

Collection

A group of individual elements, often with some rule applied to them. A List must hold the
elements in a particular order (or sequence), while a Set cannot have any duplicate elements.
List - (ArrayList, LinkedList)
Set - (HashSet, TreeSet)

Map

A group of "key=value" object pairs. Although this looks like a "Collection of pairs", trying
to implement it in this way would prove very difficult. A Map can be thought of as a mini
database. A flavor of a Map is a HashMap. As a Perl programmer, the idea of a Map may look
familiar. It is basically an "Associative Array". (In short, your keys are not integers like that

3
of an array, they are Strings). Use the put() method [passing the key and value] to add an
element to a Map.

Map - (HashMap, TreeMap)

Array

Arrays are very simple to implement in Java but has several drawbacks:
All items in the array have to be of the same type.
Must know in advance how many items will need to be stored since Arrays are
fixed in size. (Keep in mind though that Arrays can be resized)

Here are a few notes about implementing an Array:

Most efficient way to hold references to objects.

Arrays can be of any built-in type (primitive) or any object type.

For Arrays that store built-in types, the data is store directly in the Array.

For Arrays that store objects, only the object "reference" is actually stored in
the Array. Keep in mind that all normal rules of reference variables and casting
apply.

An array knows the type it holds, i.e., compile-time type checking.

An array knows its size, i.e., ask for the length.

An array can only hold one type of object (including primitives).

Arrays are fixed in size.

For all Arrays declared as Object[], then object references of ANY type can be
stored in it without casting, though a valid cast is required to take an Object
reference out and use it as its original type.

Define an array using either of the following: int[] a1; = OR = int a1[];

Both declarations produce the same result. The later actually conforms to
expectations from C and C++ programmers. The former, however, is probably

4
 a more sensible syntax, since it seems to directly say: "an int array". This is the
style used by most Java Programmers.

Reasonable integrity if provided by type checking.

The runtime system always checks array bounds.

Easy to return an array (the method simply returns a reference to the Array),
but with Java you don't have to worry about memory leaks (since the garbage
collector takes on this responsibility) like with C and C++.

Java provides a helper class called java.util.Arrays:

Search and Sort: binarySearch(), sort()

Comparison: equals() (many overloaded)

Instantiation: fill()

Conversion: asList()

Iterator

The idea behind the Iterator interface is to provide a way to select each element in a
collection.

2.1.3 Jsp:

The Sun Microsystemss java server pages technology allows you to rapidly develop and
easily maintain rich, dynamic web pages. As a part of java family JSP enables development
of web based applications that are platform independent.

The web applications build using JSP technology works with a wide variety of web
servers, application servers, browsers and development tools. The logic that generates the
content is encapsulated in tags and JavaBeans components and tied together in scriptlets, all
of which are executed on the server side. If the core logic is encapsulated in tags and Beans
then other individuals, such as web masters and page designers, can edit and work with JSP
pages without affecting the generation of the content.
Thus the JSP technology separates the user interface from the content generation.

5
JSP page is simply an HTML web page, which contain additional bits of code that generates
dynamic content of the page. JSP technology is a part of java family.

It uses a java programming language based scripting language and JSP are compiled
into java servlets the first time they are invoked. JSP pages may call JavaBeans, EJB
components, RMI objects, DBC objects to perform processing on the server. Example JSP
page may contain HTML that display static text and graphics, as well as a method call to
JDBC object that access database, when the page is displayed in a users browser.

Features Of Jsp:

JSP technology follows the write once run anywhere rule which is the basic of the
java language.
JSP uses pure java and takes the advantage of its object oriented nature
JSP uses a combination of tags and scripting to create dynamic web pages.
The JSP page uses the components like EJB, JavaBeans which are reusable. This
gives the JSP reusability capabilities.
Applications made using JSP technology are easier to maintain.

Java Script:

Giving the user more control over the browser.

Detecting the user's browser and OS. The ability to detect the user's browser and OS
allows your script to perform platform-dependent operations, if necessary.

Performing simple computations on the client side.

Validating the user's input.

Note that JavaScript helps the browser perform input validation without wasting the user's
time by the Web server access. If the user makes a mistake in the input, the user will get an
error message immediately! On the other hand, if the input information is validated only on
the server, then the user would have to wait for the server response.

Java Scripts are used as HTML tags alone will not be sufficient in developing an
application interactively.

6
 alert(string) :This message is known as confirmation message. By this we can
display an alert window.
onsubmit() :It is invoked as soon as the user press the submit button on the web page

Database Model

Accessing the database through applets and JDBC API via an intermediate server resulted in
a new type of database model which is different from the client-server model. Based on
number of intermediate server through which the request should go is classified as single tier,
two tier and multi tier architecture.

a) Single Tier:
In a single tier the server and client are the same in sense that a client program that
needs information (client) and source of this type of architecture is also possible in
java, in case flat files are used to store the data. However this is useful only in case of
small applications. The advantage with this is the simplicity and portability of the
application developed.

Server and
client

Database

Fig 1.2 Single Tier

b)Two tier (client - server ):

In two tier architecture the database resides in one machine in the network. In this
type of architecture a database management takes control of database and provides
access to clients in a network. This software bundle is also called as server. Software
in different machines, requesting for information are called as client-server.

Server

Client
Database
7
 Client

Fig 1.3 Two Tier

c)Three tier and N-tier:

In the three tier architecture , any number of servers can access the database that
resides on server which in turn serve clients in a network. For example, you want to
access the database using java applets, the applet running in some other machine, can
send request only to the server from which it is downloaded. For this reason we will
need to have an intermediate server which will accept the requests from applets and
then to the actual database server.
This intermediate server acts as a two-way communication channel also. This
is the information or data from the database is passed on to the applet that is
requesting it. This can be extended to make n tiers of servers, each server carrying to
specific type of request from clients. However in practice only 3 tier architecture is
popular.

JDBC Driver types:

The JDBC drivers that we are aware of at this time fit into one of four categories.

(i) JDBC-ODBC BRIDGE PLUS ODBC DRIVER:

The java soft bridge product provides JDBC access via ODBC drivers. Note that
ODBC binary code end in many cases database client code must be loaded on each
client machine that uses this driver. As a result, this kind of driver is most appropriate
on a corporate network where client installations are not major problem, or for
applications server code written in java in a 3- tier architecture.
(ii) NATIVE API PARTLY-JAVA DRIVER
This type of driver converts JDBC calls into calls on the client API for oracle Sybase,
Informix, Db2, or other DBMS. Note that, like the bridge driver, this style of driver
requires that some binary code be loaded on each client machine.

(iii)JDBC-NET ALL-JAVA DRIVER:

This driver translates JDBC calls into a DBMS independent net protocol, which is
then translated to a DBMS protocol by a server. This net server middle-ware is able to
connect its all java clients to many different databases. The specific protocol used
depends on the vendor. In general, this is most flexible JDBC alternative.

8
 It is likely that all vendors of this solution will provide products suitable for
intranet use. In order for these products to also support Internet access, they must
handle the additional requirements for security, access through firewall, etc that the
web imposes. Several vendors are adding JDBC drivers to their existing database
middleware products.

(iv)NATIVE PROTOCOL ALL-JAVA DRIVER

This kind of driver converts JDBC calls into network protocol used by DBMS
directory. This allows a direct call from the client machine to the DBMS server that is
practical solution for intranet access. Since many of these protocols are proprietary,
the database vendors themselves will be the primary source. Several database vendors
have these in progress.

Eventually, we expect that driver categories 3 and 4 will be the preferred way
to access database from JDBC. Driver categories 1 and 2 are interim solutions where
direct all java drivers are not yet available. Category 4 is in some sense the ideal.
However, here are many cases where category 3 may be preferable. Example- where a
thin DBMS- independent client is desired, or if a DBMS independent protocol is
standardized and implemented directly by many DBMS vendor.

2.2 Existing System

Existing system of bus pass consists of manual work for both transportation department and also for
students by standing over a line for hours near counters to get their pass done where the transportation
department team enter the details of the student manually. By continuing with this manual process it
takes lot of time to view and approve the proofs given by every applicant efficiently. The duration is
more between applying for the pass and retrieval of pass. For applying of pass the student should
again visit nearby counters. This procedure is time consuming and needs lot of paper work.

2.3 Disadvantages of Existing System

There is a high demand for the students that they need to communicate with each other from
any place to any place to synchronize their bus information.
To change the bus routes again application form must be filled. And long process of changing
the route fees according to the distance.

9
2.4 Proposed system
The software system allows the users to get bus passes online and eliminate the need of standing in
queues for passes.

Online bus pass software system allows the users to:

Apply for the new bus pass.

Verification of the student can be done in online using student roll no and photo proofs. Once
all the details are verified the system request the user to mention the route they want to travel
provided by college by paying amount through online.

It also shows appropriate schemes for quarterly, one sem and yearly passes.

The admin should maintain a record of the Approved passes and Disapproved passes of the
applicants for to avoid further violations.

10
 3. ANALYSIS
3.1 Introduction

Requirement analysis in system engineering and software engineering encompasses those

tasks that go into determining the needs or conditions to meet for a new or alerted
product, taking account of the possibly conflicting requirements of the various
stakeholders, such as beneficiaries or users.

Input design is a part of overall system design. The main objective during the input design is as given
below:

To produce a cost-effective method of input.

To achieve the highest possible level of accuracy.
To ensure that the input is acceptable and understood by the user.

INPUT STAGES:

The main input stages can be listed as below:

Data recording
Data transcription
Data conversion
Data verification
Data control
Data transmission
Data validation
Data correction

INPUT TYPES:

It is necessary to determine the various types of inputs. Inputs can be categorized as follows:

External inputs, which are prime inputs for the system.

Internal inputs, which are user communications with the system.
Operational, which are computer departments communications to the system?
Interactive, which are inputs entered during a dialogue.

11
INPUT MEDIA:

At this stage choice has to be made about the input media. To conclude about the input media
consideration has to be given to;

Type of input
Flexibility of format
Speed
Accuracy
Verification methods
Rejection rates
Ease of correction
Storage and handling requirements
Security
Easy to use
Portability
Keeping in view the above description of the input types and input media, it can be said that most of
the inputs are of the form of internal and interactive. As

Input data is to be the directly keyed in by the user, the keyboard can be considered to be the most
suitable input device.

OUTPUT DEFINITION

The outputs should be defined in terms of the following points:

Type of the output
Content of the output
Format of the output
Location of the output
Frequency of the output
Volume of the output
Sequence of the output

It is not always desirable to print or display data as it is held on a computer. It should be decided as
which form of the output is the most suitable.

12
For Example

Will decimal points need to be inserted

Should leading zeros be suppressed.

OUTPUT MEDIA:

In the next stage it is to be decided that which medium is the most appropriate for the output. The
main considerations when deciding about the output media are:

The suitability for the device to the particular application.

The need for a hard copy.
The response time required.
The location of the users
The software and hardware available.

Keeping in view the above description the project is to have outputs mainly coming under the
category of internal outputs. The main outputs desired according to the requirement specification are:

The outputs were needed to be generated as a hard copy and as well as queries to be viewed on the
screen. Keeping in view these outputs, the format for the output is taken from the outputs, which are
currently being obtained after manual processing. The standard printer is to be used as output media
for hard copies.

SDLC (Umbrella Model):

13
 DOCUMENT CONTROL Umbrella
Activity

Umbrella
Business Requirement Activity
Documentation

Feasibility Study
Requirements TEAM FORMATION
Project Specification ANALYSIS &
Gathering CODE UNIT TEST ASSESSMENT
PREPARATION DESIGN

INTEGRATION
ACCEPTANCE
& SYSTEM DELIVERY/INS TEST
TESTING TALLATION

Umbrella
TRAINING
Activity

SDLC is nothing but Software Development Life Cycle. It is a standard which is used by software
industry to develop good software.

Stages in SDLC:

Requirement Gathering
Analysis
Designing
Coding
Testing
Maintenance
Requirements Gathering stage:

14
 The requirements gathering process takes as its input the goals identified in the high-level
requirements section of the project plan. Each goal will be refined into a set of one or more
requirements. These requirements define the major functions of the intended application, define

operational data areas and reference data areas, and define the initial data entities. Major functions
include critical processes to be managed, as well as mission critical inputs, outputs and reports. A user
class hierarchy is developed and associated with these major functions, data areas, and data entities.
Each of these definitions is termed a Requirement. Requirements are identified by unique requirement
identifiers and, at minimum, contain a requirement title and

textual description.

These requirements are fully described in the primary deliverables for this stage: the
Requirements Document and the Requirements Traceability Matrix (RTM). The requirements
document contains complete descriptions of each requirement, including diagrams and references to
external documents as necessary. Note that detailed listings of database tables and fields are not
included in the requirements document.

The title of each requirement is also placed into the first version of the RTM, along with the title
of each goal from the project plan. The purpose of the RTM is to show that the product components
developed during each stage of the software development lifecycle are formally connected to the
components developed in prior stages.

15
 In the requirements stage, the RTM consists of a list of high-level requirements, or goals, by
title, with a listing of associated requirements for each goal, listed by requirement title. In this
hierarchical listing, the RTM shows that each requirement developed during this stage is formally
linked to a specific product goal. In this format, each requirement can be traced to a specific product
goal, hence the term requirements traceability.

The outputs of the requirements definition stage include the requirements document, the RTM,
and an updated project plan.

Feasibility study is all about identification of problems in a project.

No. of staff required to handle a project is represented as Team Formation, in this case only
modules are individual tasks will be assigned to employees who are working for that project.
Project Specifications are all about representing of various possible inputs submitting to the server
and corresponding outputs along with reports maintained by administrator
Analysis Stage:

The planning stage establishes a bird's eye view of the intended software product, and uses this
to establish the basic project structure, evaluate feasibility and risks associated with the project, and
describe appropriate management and technical approaches.

The most critical section of the project plan is a listing of high-level product requirements, also
referred to as goals. All of the software product requirements to be developed during the requirements

16
definition stage flow from one or more of these goals. The minimum information for each goal
consists of a title and textual description, although additional information and references to external
documents may be included. The outputs of the project planning stage are the configuration
management plan, the quality assurance plan, and the project plan and schedule, with a detailed listing
of scheduled activities for the upcoming Requirements stage, and high level estimates of effort for the
out stages.

Designing Stage:

The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements will be produced
as a result of interviews, workshops, and/or prototype efforts. Design elements describe the desired
software features in detail, and generally include functional hierarchy diagrams, screen layout
diagrams, tables of business rules, business process diagrams, pseudo code, and a complete entity-
relationship diagram with a full data dictionary. These design elements are intended to describe the
software in sufficient detail that skilled programmers may develop the software with minimal
additional input.

When the design document is finalized and accepted, the RTM is updated to show that each design
element is formally associated with a specific requirement. The outputs of the design stage are the
design document, an updated RTM, and an updated project plan.

17
Development (Coding) Stage:

The development stage takes as its primary input the design elements described in the approved
design document. For each design element, a set of one or more software artifacts will be produced.
Software artifacts include but are not limited to menus, dialogs, data management forms, data
reporting formats, and specialized procedures and functions. Appropriate test cases will be developed
for each set of functionally related software artifacts, and an online help system will be developed to
guide users in their interactions with the software.

The RTM will be updated to show that each developed artifact is linked to a specific design
element, and that each developed artifact has one or more corresponding test case items. At this point,
the RTM is in its final configuration. The outputs of the development stage include a fully functional
set of software that satisfies the requirements and design elements previously documented, an online
help system that describes the operation of the software, an implementation map that identifies the
primary code entry points for all major system functions, a test plan that describes the test cases to be
used to validate the correctness and completeness of the software, an updated RTM, and an updated
project plan.

Integration & Test Stage:

18
 During the integration and test stage, the software artifacts, online help, and test data are
migrated from the development environment to a separate test environment. At this point, all test
cases are run to verify the correctness and completeness of the software. Successful execution of the
test suite confirms a robust and complete migration capability. During this stage, reference data is
finalized for production use and production users are identified and linked to their appropriate roles.
The final reference data (or links to reference data source files) and production user list are compiled
into the Production Initiation Plan.

The outputs of the integration and test stage include an integrated set of software, an online help
system, an implementation map, a production initiation plan that describes reference data and
production users, an acceptance plan which contains the final suite of test cases, and an updated
project plan.

Installation & Acceptance Test:

During the installation and acceptance stage, the software artifacts, online help, and initial
production data are loaded onto the production server. At this point, all test cases are run to verify the

19
correctness and completeness of the software. Successful execution of the test suite is a prerequisite to
acceptance of the software by the customer.

After customer personnel have verified that the initial production data load is correct and the
test suite has been executed with satisfactory results, the customer formally accepts the delivery of the
software.

The primary outputs of the installation and acceptance stage include a production application, a
completed acceptance test suite, and a memorandum of customer acceptance of the software. Finally,
the PDR enters the last of the actual labor data into the project schedule and locks the project as a
permanent project record. At this point the PDR "locks" the project by archiving all software items,
the implementation map, the source code, and the documentation for future reference.

Maintenance:

Outer rectangle represents maintenance of a project, Maintenance team will start with
requirement study, understanding of documentation later employees will be assigned work and they
will under go training on that particular assigned category.

For this life cycle there is no end, it will be continued so on like an umbrella (no ending point to
umbrella sticks).

20
3.2 Software Requirement Specification

3.2.1 User Requirements

3.2.2 Software requirement

In Software engineering and systems engineering, a functional requirement defines a function
of a system or its component. A function is described as a set of inputs, the behavior, and
outputs.

Software Requirement Specification (SRS) is the starting point of the software developing
activity. As system grew more complex it became evident that the goal of the entire system cannot be
easily comprehended. Hence the need for the requirement phase arose. The software project is
initiated by the client needs. The SRS is the means of translating the ideas of the minds of clients (the
input) into a formal document (the output of the requirement phase.)

The SRS phase consists of two basic activities:

1) Problem/Requirement Analysis:

The process is order and more nebulous of the two, deals with understand the
problem, the goal and constraints.

2) Requirement Specification:

Here, the focus is on specifying what has been found giving analysis such as
representation, specification languages and tools, and checking the specifications are
addressed during this activity.

The Requirement phase terminates with the production of the validate SRS document.
Producing the SRS document is the basic goal of this phase.

ROLE OF SRS

The purpose of the Software Requirement Specification is to reduce the communication gap
between the clients and the developers. Software Requirement Specification is the medium though

21
which the client and user needs are accurately specified. It forms the basis of software development.
A good SRS should satisfy all the parties involved in the system.

SCOPE

This document is the only one that describes the requirements of the system. It is meant for
the use by the developers, and will also be the basis for validating the final delivered system. Any
changes made to the requirements in the future will have to go through a formal change approval
process. The developer is responsible for asking for clarifications, where necessary, and will not make
any alterations without the permission of the client.

SOFTWARE REQUIREMENTS

Operating System : Windows 10

User Interface : HTML, CSS

Client-side Scripting : Java Script

Programming Language : Java

Web Applications : JDBC, JSP

Database : MySQL

Server Deployment : Apache Tomcat 7.0

3.2.3 Hardware requirements

Functional requirements are supported by non-functional requirements (also known as quality

requirements), which impose constraints on the design or implementation (such as
performance requirements, security, or reliability). As defined in requirements engineering,
functional requirements specify particular results of a system. The performance of the
developed applications can be calculated by using following methods:

Measuring enables you to identify how the performance of your application stands in relation
to your defined performance goals and helps you to identify the bottlenecks that affect your
application performance. It helps you identify whether your application is moving toward or
away from your performance goals. Defining what you will measure, that is, your metrics,
and defining the objectives for each metric is a critical part of your testing plan.

Performance objectives include the following:

22
 Response time or latency
Throughput

Resource utilization

Safety& Security:

The security design process is cyclical. The security of an application depends upon the
vigilance of the developers and administrators not just during the design phase but also for
the life of the application. Since new threats arise almost daily, an application must be
scrutinized constantly for potential security flaws. However, the initial design of an
application determines how often those flaws are likely to occur.

Security threats are any potential occurrence, malicious or otherwise, that can have an
undesirable effect on the application. Vulnerabilities in the application or operating system
make a threat possible. An attack on the application is an action taken by a malicious intruder
to exploit certain vulnerabilities in order to enact the threat. The risk involved is the potential
damage that attack can inflict on the application or even the business.

Repudiability

Reputability is the notion of denying that an action occurred. Denying that you received an
item, when in fact you did, and expecting the vendor to supply you another is an example of
repudiability.

Actions that you would otherwise not want an unauthorized user to perform should be
logged. Such non-repudiability can also be obtained through the use of digital signatures and
timestamps. Additionally, digital signatures can be used to help provide non-repudiability.

Maintainability:

The increased complexity of modern software applications also increases the difficulty of
making the code reliable and maintainable. In recent years, many software measures, known
as code metrics, have been developed that can help developers understand where their code
needs rework or increased testing.

23
Developers can use Visual Studio Application Lifecycle Management to generate code
metrics data that measure the complexity and maintainability of their managed code. Code
metrics data can be generated for an entire solution or a single project.

Portability:

Portability is one of the key concepts of high-level programming. Portability is the software
codebase feature to be able to reuse the existing code instead of creating new code when
moving software from an environment to another. The prerequirement for portability is the
generalized abstraction between the application logic and system interfaces. When one is
targeting several platforms with the same application, portability is the key issue for
development cost reduction.

Processor : Pentium-Iv

Processor Speed : 2.4GHZ

Hard Disk : 80GB
RAM : 1GB

4. DESIGN

4.1 Design
Requirements gathering followed by careful analysis leads to a systematic Object
Oriented Design (OOAD). Various activities have been identified and are represented using
Unified Modeling Language (UML) diagrams. UML is used to specify, visualize, modify,
construct and document the artifacts of an object-oriented software-intensive system under
development.
4.1.1. Use Case Diagram

In the Unified Modeling Language (UML), the use case diagram is a type of
behavioral diagram defined by and created from a use-case analysis. It represents a graphical
over view of the functionality of the system in terms of actors, which are persons,

24
organizations or external system that plays a role in one or more interaction with the system.
These are drawn as stick figures. The goals of these actors are represented as use cases, which
describe a sequence of actions that provide something of measurable value to an actor and
any dependencies between those use cases.

In this application there is only actor soldier and below is the use case diagram of
this application.

System

Register

Login

Admin
View Members

Add Bus

Add Stops Student

Bus Info
Faculty

Logout

Figure 4-1 Use Case Diagram

4.1.2 Sequence Diagram

UML sequence diagrams are used to show how objects interact in a given situation.
An important characteristic of a sequence diagram is that time passes from top to bottom: the
interaction starts near the top of the diagram and ends at the bottom (i.e. Lower equals later).
A popular use for them is to document the dynamics in an object-oriented system. For
each key, collaboration diagrams are created that show how objects interact in various
representative scenarios for that collaboration.

25
 Sequence diagram is the most common kind of interaction diagram, which focuses on
the message interchange between a numbers of lifelines.
The following nodes and edges are typically drawn in a UML sequence diagram:
lifeline, execution specification, message, combined fragment, interaction use, state invariant,
continuation, destruction occurrence.

Student Register Login Bus Info Logout

: Student
1 : Fill Details()

2 : Enter Crendetails()

3 : Check Credentials()

4 : View Bus Details()

5 : Logout()

6 : Back to Home Page()

Figure 4-2.1 Sequence Diagram for Student

26
 Student Register Login Bus Info Logout

: Faculty
1 : Fill Details()

2 : Enter Crendetails()

3 : Check Credentials()

4 : View Bus Information()

5 : Logout()

6 : Back to Home Page()

Figure 4-2.2 Sequence Diagram for Faculty

Login Bus Members Add Bus Logout

Add Stop

: Admin

1 : Enter Crendetails()

2 : Check Credentials()

3 : View Bus Members()

4 : Add Busses On Route()

5 : Add Stops On Particular Route()

6 : Logout()

7 : Back to Home Page()

Figure 4-2.3 Sequence Diagram for Admin

27
4.1.3 Collaboration diagram

A collaboration diagram, also called a communication diagram or interaction diagram, is an

illustration of the relationships and interactions among software objects in the Unified
Modeling Language (UML). The concept is more than a decade old although it has been
refined as modeling paradigms have evolved.

Collaboration diagrams are best suited to the portrayal of simple interactions among
relatively small numbers of objects. As the number of objects and messages grows, a
collaboration diagram can become difficult to read. Several vendors offer software for
creating and editing collaboration diagrams.

Fig 4.3.1: Collaboration diagram for Strudent

28
 Fig 4.3.2: Collaboration diagram for Faculty

Fig
4.3.3: Collaboration diagram for Admin

4.1.4 Activity Diagram

Activity diagram is another important diagram in UML to describe dynamic aspects

of the system. Activity diagram is basically a flow chart to represent the flow form one
activity to another activity. The activity can be described as an operation of the system.So the
control flow is drawn from one operation to another. This flow can be sequential, branched or

29
concurrent. Activity diagrams deals with all type of flow control by using different elements
like fork, join etc.Activity is a particular operation of the system.

Enter Details
Register

Enter Credentials

Login Back To Login Page

Check Credentilals Login Fail

In Valid

Valid

Enter To Admin Enter To Student

Enter To Faculty

Admin
Seller User

View Bus Members

Bus Members View Busses On Their Location View Busses On Their Location

Add Busses On Route Bus Info Bus Info

Add Busses

Add Stops On Particular Route

Exit
Exit

Add Stops
Exit

Logout

Back to Index

Fig 4-4 Activity Diagram

4.1.5 Class Diagram

In software engineering, a class diagram in the Unified Modeling Language (UML) is

a type of static structure diagram that describes the structure of a system by showing the
systems classes, their attributes, operations (or methods), and the relationships among the
classes.

The class diagram is the main building block of object oriented 30odeling. It is used
both for general conceptual 30odeling of the 30odeling30c of the application, and for detailed

30
31odeling translating the models into programming code. Class diagrams can also be used for
data modeling. The classes in a class diagram represent both the main objects, interactions in
the application and the classes to be programmed.

Bus Memebers
Student Register
+User Email: String
+Bus No: String Add Bus
+Hall Ticket: String Admin
+Name: String +Stops: String
+Bus No: String
+Email: String +User Name: String +Money: String
+Driver Name: String
+Password: String +Password: String +Paydate: String
+Driver No: String
+Mobile No: String +Pending: String
+login() +Route: String
+Branch: String +Total Seats: String
+view()
+Gender: String
+add()
+register()

Student Add Stop

+User Email: String +Bus No: String
+Password: String +Route: String
+Stops: String
+login() +Fare: String

Bus Info +add()

Faculty Register
+Name: String +Add Location: String
+Email: String +search()
+Password: String View Busses
Faculty
+Mobile No: String +Bus No: String
+Branch: String +User Email: String +Route: String
+Gender: String +Password: String +Stops: String
+register() +login() +Fare: String
+view()
+paymoney()

Figure 4-5 Class Diagram

31
4.1.6 Statechart diagram

Statechart diagram is one of the five UML diagrams used to model dynamic nature of
a system. They define different states of an object during its lifetime. And these states are
changed by events. So Statechart diagrams are useful to model reactive systems. Reactive
systems can be defined as a system that responds to external or internal events.

Register

entry/Details

Login

entry/User Credentials

Admin Student

Faculty

Bus Members
do/View All Bus Members

Bus Info

do/View Busses On Particular Route

Add Busses Bus Info

entry/Add Busses On Route do/View Busses On Particular Route

Add Stops

entry/Add Stops On Particular Route

Logout

exit/Home Page

Figure 4-6 State Chart Diagram

32
4.1.7 Component diagram

Component diagram is a special kind of diagram in UML. The purpose is also different from
all other diagrams discussed so far. It does not describe the functionality of the system but it
describes the components used to make those functionalities. So from that point component
diagrams are used to visualize the physical components in a system. These components are
libraries, packages, files etc. Component diagrams can also be described as a static
implementation view of a system. Static implementation represents the organization of the
components at a particular moment.

Register

Bus Members
Add Busses

Admin

Add Stops
Login

Student

Bus Info

Faculty
Logout

Figure 4-7 Component Diagram

33
4.1.8 E-R Diagram

Let us now learn how the ER Model is represented by means of an ER diagram. Any object,
for example, entities, attributes of an entity, relationship sets, and attributes of relationship
sets, can be represented with the help of an ER diagram.

addbus

sregister busno: varchar

drname: varchar
sid: varchar drphone: varchar
shtno: varchar route: varchar addstop
sname: varchar total_seats: varchar busno: varchar
semail: varchar bus_statusl: varchar
D:R I:R route: varchar
spwd: varchar
U:R U:R stop: varchar
smno: varchar D:R fare: varchar
sbranch: varchar U:R
sgender: varchar
srdate: varchar
sstatus: varchar

I:R
I:SN D:R
U:R
U:SN U:R
I:R
U:R assign

semail: varchar
busno: varchar
D:SN
U:SN stop: varchar
fregister amount: varchar
pay_date: varchar
fid: varchar
fname: varchar
femail: varchar
fpwd: varchar
fmno: varchar
fbranch: varchar
fgender: varchar
frdate: varchar
fstatus: varchar

Figure 4-8 E-R Diagram

4.1.9 Deployment Diagram

Deployment diagram shows execution architecture of systems that represent the

assignment (deployment) of software artifacts to deployment targets (usually nodes).

Nodes represent either hardware devices or software execution environments. They could be
connected through communication paths to create network systems of arbitrary complexity.
Artifacts represent concrete elements in the physical world that are the result of a
development process and are deployed on nodes.

34
Figure 4-9 Deployment Diagram of the system

35
 5. IMPLEMENTATION & RESULTS
5.1 Introduction:

A module description provides detailed information about its supposed components, which is
accessible in different manners. The included description is available by reading directly, by
generating a short html-description, or by making an environment check for supposed
components to check if needed types and services are available in the environment where
they will be used. This environment checks registration/installation or a separate consistency
check for a component.

5.2 Explanation of key Functions

Admin:

Admin will also have to login into the application with help of their credentials and
once they login they have different sets of feature or functionality provided under them.
Basically the admin is the owner of the e commerce site; hence they got an option to create
the category.

Add Busses:

36
Only admin has the right to add busses on particular route. Then after add the bus stops on
that busses on particular route.

Payment Module:

In this module, the complete payment structure and process is been covered. Student And
Faculty adds the card details and then it gets saved in dummy transaction and the
products are purchased successfully.

Bus Info:
Faculty/Student has login using his credentials those which are fill in registrattion. Then after
he will add his location to find the bus on particular route.

Student module:
Students should register in the site before proceeding onto further process.
After the registration is successful they receive the login details from admin through which
they can access the system.
After logging student can request for new bus pass or reissue bus pass if it is lost.
Once all the details are filled in application form, they need to submit it and it is sent to
admin.

Faculty module:

Faculty should register in the site before proceeding onto further process.
If registration is successful they receive login details from admin through which they can
access the system.
Admin provide special discounts in the fee payment to the faculty who are requesting for
the bus pass.
They can post important notifications regarding the functioning of college. (ex: college
remains closed due to orientation day.)

37
5.3 Method Of Implementation
5.3.1 Output Screens

38
 6. TESTING AND VALIDATIONS
6.1 Test cases

6.1.1 Test case for student register

S.No Test Case Input Expected Output Actual Output Status

User
Name,
Password, Registered Registered
1 Registration Passed
Email, Successfully Successfully
Phone,
Place

6.1.2 Test case for student and admin login

Test
S.No Input Expected Output Actual Output Status
Case

Valid username
1 Login Login successfull Login successfull Passed
and password

6.2 Validations

6.2.1 Validation and messages for student registration

S No Field Name Validations Messages Remarks

If the field is not No

1 User Name Enter username
filled

If the field is not

Password is No
2 Password filled (max 8
incorrect
characters)

If the field is not Enter valid No

3 Email
filled email

4 Phone If the field is not Should contain No

filled maximum of 10

39
 characters

If the
Enter the No
5 Place field is
field
not filled

6.2.2 Validation and messages for student login

S.No Field Name Validations Messages Remarks

Invalid
User If field is username
1 No
Name not filled or
password

Invalid
If field is username
2 Password No
not filled or
password

Testing
Software testing is a critical element of software quality assurance and
represents the ultimate review of specification, design and code generation.

7.1 TESTING OBJECTIVES

To ensure that during operation the system will perform as per specification.
TO make sure that system meets the user requirements during operation
To make sure that during the operation, incorrect input, processing and output will be
detected
To see that when correct inputs are fed to the system the outputs are correct
To verify that the controls incorporated in the same system as intended
Testing is a process of executing a program with the intent of finding an error
A good test case is one that has a high probability of finding an as yet undiscovered
error

The software developed has been tested successfully using the following testing strategies and
any errors that are encountered are corrected and again the part of the program or the procedure or
function is put to testing until all the errors are removed. A successful test is one that uncovers an as
yet undiscovered error.

40
 Note that the result of the system testing will prove that the system is working correctly. It
will give confidence to system designer, users of the system, prevent frustration during
implementation process etc.,

7.2 TEST CASE DESIGN:

White box testing

White box testing is a testing case design method that uses the control structure of the
procedure design to derive test cases. All independents path in a module are exercised at least once, all
logical decisions are exercised at once, execute all loops at boundaries and within their operational
bounds exercise internal data structure to ensure their validity. Here the customer is given three
chances to enter a valid choice out of the given menu. After which the control exits the current menu.

Black Box Testing

Black Box Testing attempts to find errors in following areas or categories, incorrect or
missing functions, interface error, errors in data structures, performance error and initialization and
termination error. Here all the input data must match the data type to become a valid entry.

The following are the different tests at various levels:

Unit Testing:

Unit testing is essentially for the verification of the code produced during the coding
phase and the goal is test the internal logic of the module/program. In the Generic code project,
the unit testing is done during coding phase of data entry forms whether the functions are
working properly or not. In this phase all the drivers are tested they are rightly connected or not.

41
Integration Testing:

All the tested modules are combined into sub systems, which are then tested. The goal is to see
if the modules are properly integrated, and the emphasis being on the testing interfaces between
the modules. In the generic code integration testing is done mainly on table creation module and
insertion module.

Validation Testing

This testing concentrates on confirming that the software is error-free in all respects. All the specified
validations are verified and the software is subjected to hard-core testing. It also aims at determining
the degree of deviation that exists in the software designed from the specification; they are listed out
and are corrected.

System Testing

This testing is a series of different tests whose primary is to fully exercise the computer-based system.
This involves:

Implementing the system in a simulated production environment and testing it.

Introducing errors and testing for error handling.

42
TYPES OF TESTS

Unit testing

Unit testing involves the design of test cases that validate that the internal program logicis
functioning properly, and that program input produce valid outputs.

All decisionbranches and internal code flow should be validated. It is the testing of
individual software units of the application .it is done after the completion of an
individual unitefore integration.

This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests
perform basic tests at component level and test a specific business process, application, and/or system
configuration. Unit tests ensure that each unique path of a business process performs accurately to the

documented specifications and contains clearly defined inputs and expected results .

Integration testing

Integration tests are designed to test integrated software components to determine if they
actually run as one program. Testing is event driven and is more concerned with the basic outcome of
screens or fields. Integration tests demonstrate that although the components were individually
satisfaction, as shown by successfully unit testing, the combination of components is correct and
consistent. Integration testing is specifically aimed at exposing the problems that arise from the
combination of components.

43
Functional test

Functional tests provide a systematic demonstrations that functions tested are available as
specified by the business and technical requirements, system documentation , and user manuals.

Functional testing is centered on the following items:

Valid Input : identified classes of valid input must be accepted.

Invalid Input : identified classes of invalid input must be rejected.

Functions : identified functions must be exercised.

Output : identified classes of application outputs must be exercised.

Systems/Procedures : interfacing systems or procedures must be invoked.

Organization and preparation of functional tests is focused on requirements, key functions, or

special test cases. In addition, systematic coverage pertaining to identify

Business process flows; data fields, predefined processes, and successive processes must be
considered for testing. Before functional testing is complete, additional tests are identified and the
effective value of current tests is determined.

System Test

System testing ensures that the entire integrated software system meets requirements. It tests a
configuration to ensure known and predictable results. An example of system testing is the
configuration oriented system integration test. System testing is based on process descriptions and
flows, emphasizing pre-driven process links and integration points.

White Box Testing

White Box Testing is a testing in which in which the software tester has knowledge of the inner
workings, structure and language of the software, or at least its purpose. It is purpose. It is used to
test areas that cannot be reached from a black box level .

44
Black Box Testing

Black Box Testing is testing the software without any knowledge of the inner workings, structure
or language of the module being tested . Black box tests, as most other kinds of tests, must be
written from a definitive source document, such as specification or requirements document, such as
specification or requirements document. It is a testing in which the software under test is treated, as
a black box .you cannot see into it. The test provides inputs and responds to outputs without

considering how the software works .

6.1 Unit Testing:

Unit testing is usually conducted as part of a combined code and unit test phase of the
software lifecycle, although it is not uncommon for coding and unit testing to be conducted as two

distinct phases.

Test strategy and approach

Field testing will be performed manually and functional tests will be written in detail.

Test objectives

All field entries must work properly.

45
 Pages must be activated from the identified link.
The entry screen, messages and responses must not be delayed.

Features to be tested

Verify that the entries are of the correct format

No duplicate entries should be allowed
All links should take the user to the correct page.
6.2 Integration Testing

Software integration testing is the incremental integration testing of two or more

integrated software components on a single platform to produce failures caused by interface
defects.

The task of the integration test is to check that components or software applications,
e.g. components in a software system or one step up software applications at the company
level interact without error.

Integration testing for Database Synchronization:

Testing the links that call the Change Username & password, Migration and
Synchronization screens etc.
The username should be retained throughout the application in the form of hidden
variables or by using cookies.
If the login user does not have enough privileges to invoke a screen, the link should
be disabled.
Any modification in the Master server should be reflected in the Slave server.
The XML file should retrieve only the records, which have been modified.

46
Test Results: All the test cases mentioned above passed successfully. No defects
encountered.

6.3 Acceptance Testing

User Acceptance Testing is a critical phase of any project and requires significant
participation by the end user. It also ensures that the system meets the functional
requirements.

Acceptance testing for Data Synchronization:

Users have separate roles to modify the database tables.

The timestamp for all insertions and updating should be maintained.
Users should have the ability to modify the privilege for a screen.
Once the Synchronization starts, the Master server or Slave Server should not be
stopped without notifying the other.
The XML file should be generated in short time, i.e., before the next modification
occurs.
Test Results: All the test cases mentioned above passed successfully. No defects
encountered.

47
48
 7. CONCLUSION

By developing ONLINE BUSPASS MANGEMENT SYSTEM we can save students time

and eradicate manual process of filling the details in application form from transport
department. This provides the students to receive their bus pass and other notifications in fast
and efficient manner. In case of any modifications in the existing data can be easily sorted
out.

49
REFERENCES:

1. Bernd. Allen, H Dutit OBJECT-ORIENTED SOFTWARE ENGINEERING

Using UML, Patterns and Java, Second Editon.

2. C.J. Date AN INTRODUCTION TO DATABASE MANAGEMENT SYTEM.

3. Ivan Bayross, Sharanam Shah, Cynthis Bayross, Vaishali Shah JAVA

SERVER PROGRAMMING FOR PROFESSIONALS.

4. Kevin Loney, George Kouch and the experts at TUSC ORACLE 9i: The
Complete Reference .

5. James Jaweorski Mastering Java Script and JScript

Web Sites:

www. Sunmicrosystems.com

www. Google.com

www. Newprojects.com

www. Advancedjava.com

www.wikipedia.com

50