Automation of Web-Application and Web-Services

A PROJECT REPORT
(SOFTWARE REQUIREMENT AND DESIGN SPECIFICATION)

Submitted in partial fulfilment for the award of the degree

of

Master of Science
in
Information Technology
by

NEETHA
(13MIN0133)
Under the guidance of

Prof. Ramesh
VIT University

School of Information Technology and Engineering

June, 2017
 School of Information Technology and Engineering

DECLARATION BY THE CANDIDATE

I hereby declare that the thesis entitled Automation of Web-Application and

Web-Services submitted by me to Vellore Institute of Technology University
Vellore, in partial fulfillment of the requirement for the award of the degree of
Master of Science in Information Technology is a record of bonafide project
work carried out by me under the supervision of Prof. Ramesh. I further
declare that the work reported in this project has not been submitted and will not
be submitted, either in part or in full, for the award of any other degree or
diploma in this institute or any other institute or university.

Place:
Date: Signature of the Candidate

i
 School of Information Technology and Engineering

BONAFIDE CERTIFICATE

This is to certify that the project work entitled Automation of Web-Application

and Web-Services by NEETHA (13MIN00133), to Vellore Institute of
Technology University, Vellore, in partial fulfillment of the requirement for the
award of the degree of Master of Science in Information Technology, is a
project bonafide work carried out by him/her under my supervision. The project
fulfills the requirement as per the regulations of this Institute and in my opinion
meets the necessary standards for submission. The contents of this report have
not been submitted and will not be submitted either in part or in full, for the award
of any other degree or diploma in this Institute or any other Institute or University.

Prof. Pranshu Sakalley

Internal Supervisor

VIT University

Internal Examiner(s) External Examiner(s)

ii
Abstract

The objective of this project is to provide a solution to the Railway Department of India to help
passengers to book local railway journey tickets from their mobiles without internet connection just
simply via SMS (Short Message Service). Which reduces amount of time spent in buying the tickets for
travelling in the train to reach their destinations. Passengers should book their ticket from their mobiles
without waiting in the queue so that they can effectively utilize their valuable time in other activities.

Entire project is divided into separate sections to reach the final implementation.

iii
Table of Contents
CHAPTER PAGE
TITLE
NO. NO.
ABSTRACT iii
LIST OF FIGURES v
LIST OF TABLES v
LIST OF ABBREVATIONS vi

CHAPTERS
1 INTRODUCTION 1
1.1 PURPOSE 2
1.2 SCOPE 3
2 SOFTWARE REQUIREMENT SPECIFIACATION 4
2.1 EXTERNAL INTERFACE REQUIREMENT 5
2.2 FUNCTIONAL REQUIREMENT 6
2.3 NON- FUNCTIONAL REQUIREMENT 8
3 LITERATURE SURVEY 10
3.1 PURPOSE OF LITERATURE SURVEY 10
3.2 METHODOLOGY 11
4 DETAILED DESIGN OF THE PROJECT 14
4.1 PRODUCT PERSPECTIVE 14
4.2 SOFTWARE INTERFACE 14
4.3 PRODUCT FUCTIONALITY 15
4.4 ARCHITECTURE DESIGN 16
4.5 USE CASE DIAGRAM 17
4.6 CLASSES/OBJECTS 19
4.7 CONTEXT DIAGRAM 21
4.8 SEQUENCE DIAGRAM 22
4.9 DATA DESCRIPTION 22
4.10 DATA DICTIONARY 29
4.11 SCREEN IMAGES 31
5 REFERENCES 38

iv
List of Figures
SERIAL PAGE
TITLE
NO. NO.
1 Architecture Diagram 16
2 Use Case Diagram 17
3 Classes/Objects Diagram 19
4 Context Diagram 21
5 Sequence Diagram 22
6 Zero Level DFD 24
7 One Level DFD 25
8 Two Level DFD 25
9 ER Diagram 28
10 Home Screen 31
12 Sign-Up Screen 32
13 Sign-In Screen 33
14 Registration Screen 34
15 Book Ticket 35
16 Recharge Account 36
17 Check Ticket 37

List of Tables
SERIAL PAGE
TITLE
NO. NO.
1 Database_Version Table 29
2 User Table 29
3 Load_Money Table 29
4 Transactions Table 30
5 Balance Table 30

v
List of Abbreviations
The following are the list of conventions and acronyms used in this document:
J2ME (Java 2 Mobile Edition) It is a programming platform, belonging to
The Java platform, which is used for developing and running java
Based Mobile Applications.
HTTP (Hyper Text Transfer Protocol) It is a transaction oriented client/ server Protocol
between a web browser and a web server.
Database Collection of information in a structured form.
JDK Java Development Kit
JRE Java Runtime Environment
SDLC Software Development Life Cycle
XML eXtensible Markup Language
DFD Data Flow Diagram
SMS - Short Message Service
MMS - Multimedia Message Service
TC - Ticket Collector/Ticket Checker Officer
CVM - Coupon Vending Machine
ATVM - Automatic Ticket Vending Machine
MTRN - Mobile Ticket Reference Number

vi
1.1. Introduction
An SRS is basically an organizations understanding of a customer or clients system
requirements prior to any actual design or development work. It establishes a basis for
agreement between customers and contractors or suppliers on what the software product is
expected to do. It sets a basis for software design, test, deployment, training, etc. It also sets a
pre-requisite for a good design though it is not enough. Local Railway Ticket Booking by SMS
System allows one to Register for Mobile Ticket, Account Information, Ticket Booking &
Transaction history.
The objective of this project is to provide a solution to the Railway Department of India to help
passengers to book local railway journey tickets from their mobiles without internet connection
just simply via SMS (Short Message Service). Which reduces amount of time spent in buying
the tickets for travelling in the train to reach their destinations.

PROBLEM:
In India, we have multiple cities where lacs of passengers avail local train facility commutation
extensively in their daily routing travels. Major railway stations have long waiting queues for
tendering the railway tickets. Sometimes, time of train travel journey would be less than the
time taken to book the train ticket due to long queues. Passengers end-up in losing their energy
& time in waiting in the queues for their turn to buy tickets & travel in trains to reach their
destination.

Railway has introduced CVM (Coupon Vending Machines), where railways issues coupons
which are equivalent to rupees which will be punched in the CVM machine which attest the
timestamp & station details on the coupon which can be used only once. Which requires lot of
papers of printing the coupons which are used only once & it is paper waste. CVM machines
requires energy & ink for attesting on the coupons.

Later on Railway has introduced ATVM (Automatic Ticket Vending Machines) in major
stations to reduce the long queues in the railway station ticket vending windows. But these
machines are most of the times out-of-service &/or sometimes stations does not have necessary
equipment to load the money into the smart cards.

Certainly, above solution solved some of the problems of the railway department & passengers,
but not fully reduced their railway stations ticket vending long queues or ATVM machines
queues. During festive sessions, rush hours on week-days, railways will have long waiting

vii
queues in the stations ticket vending windows & long queues in the ATVM machines queues
as well.

Railways definitely requires some other solution to solve this problem of the passengers
travelling in the local trains.

1.2. PURPOSE

We have a solution to the above problem of Indian local trains departments. Below solution
has been implemented to solve the problems of Mumbai Local Train Passengers to book their
tickets without standing in the railways ticket vending windows.

We will develop a onetime installable mobile software which can be installed on the
passengers mobile device & register to use it. Once registered, he can recharge his account by
visiting the railway stations as we do for recharging the ATVM smart cards or by the Online
payment gateway transactions. Passenger can book the tickets when he wants to travel by local
trains by lunching application which will provide the options to select the required details for
the ticket booking. Once all the details are filled & user clicks on book ticket then software will
convert the details into request in the form of SMS & would be sent to the server SMS server
where it would be received, processed, accounting, response generations & response would be
sent to the requested user mobile number via SMS. This electronic ticket will have the similar
details as that of the normal railways paper local ticket. Ticket will have the timestamp, fare
& account details for authorization.

The proposed system provides below benefits,

Passengers can obtain tickets within fraction of seconds

Saving of time, money and efforts
Easier accessibility
Same ticket rates
Reach to customer
Reduce huge maintenance cost to railways
Go-Green with paperless
Less queue lengths on the railway ticket vending windows
No dependency on the equipment of the railway.
Can have ticket transaction history

viii
1.3. SCOPE

Local Railway Train Ticket Booking by SMS application enables the users of the
application/passengers to Register themselves to use Mobile Ticket Application, Book Ticket,
Check fares for the journey, transaction history. This application is designed to improve current
legacy system local train ticketing process in the India. To Maximize the use of assets we have
in everyones hand. Minimize the effort, time in booking ticket for the local train journeys.
Reduce the paper waste which indulge with current local train ticketing system produces.

ix
2. Software Requirement Specification

The remainder of the document describes requirements for the Local Railway Train Ticketing
by SMS which are collected from the clients and what are the expectation from the solution
point of view. The requirements will be described with scenarios for clear understandings.

Local Railway Ticketing by SMS Application will help the users of the application/Passengers
to register themselves to use this application, book ticket for any local journey, view transaction
history, Cancel Ticket, Check Journey Fares, Update database, etc.
Register for Ticketing Application: Users who are interested to avail to use this
application must register in order to utilize the facility provided by the railway
department. In order proceed with this process user must have a running Mobile
Number, setup password, Date of birth, Email ID, etc.
Users need to login into the application once they have sign-up/registers.
In order to book the tickets user must have enough account balance.
All the booked tickets will be received as the SMS & will be available once server
responds to the requests.
Unique Mobile Ticket Reference Number will be available on the tickets,
Ticket Collectors/Checkers will verify the above MTRN.
Cancel the booked tickets within specified time limits.
Maximum last 5 transactions history.
Recharge account details.
Update the database for any modifications in the system such as fares, stations,
application version update etc.

2.1. EXTERNAL INTERFACE REQUIREMENTS

This section describes how the software interfaces with other software products or users for
input or output.

2.1.1 User Interfaces

User Perspective: The User Interface is J2ME (Java 2 Mobile Edition) supported mobile
handset where application would be launched in the mobile screen & user can interact
with application either by screen touch or by the buttons.

x
2.1.2 Hardware Interfaces
Operating System Windows 7 or higher version
Processor CORE i3
RAM 4 GB
Hard Disk 500 GB or more

2.1.3 Software Interfaces

J2ME, JDK, JRE, PHP, XAMPLITE, MySQL.

2.1.4 Communication Interfaces

The user must be able to connect to Mobile Service Providers network in order to send
messages to the server for any requests from it.

2.2. FUNCTIONAL REQUIREMENT

The functional requirements describe the core functionality of the application. This section
includes the data and functional process requirements. Use-case is a story or a scenario that
describes the functionality of the system.
2.2.1 Sign-Up
2.2.1.1 Introduction
The User sign-up into Mobile Ticketing application..
2.2.1.2 Inputs
Userid and Password are passed as the inputs for this functionality.
2.2.1.3 Processing
The User Id and password combination is checked for its authenticity, based on which the
user is allowed to proceed further.
2.2.1.4 Outputs
User successfully signs-up into the Application password matches required criteria.
2.2.1.5 Error Handling
User will be thrown with the proper error message when inputs does not meet the
required criteria defined for each fileds.

xi
2.2.2 Register
2.2.2.1 Introduction
User registers themselves to Local Ticketing Application by providing the personal
details.
2.2.2.2 Inputs
Inputs taken from the User such as First Name, Middle Name, Last Name, Date of
Birth, Email ID, etc.
2.2.2.3 Processing
Once clicked on the Register button then system will store above details in the system.
Same details would be sent to the server for storing.
2.2.2.4 Outputs
Status of the message whether is it success or failed.
2.2.2.5 Error Handling
If valid inputs in the above inputs are not provided then it will throw error
messages.

2.2.3 Load Account

2.2.3.1 Introduction
Each Mobile User should have sufficient balance in his account before booking the
ticket. Account balance can be loaded from the payment gateway or from railway stations.
2.2.3.2 Inputs
Inputs to the payment gateway to process the bank transaction. Railway stations will
have equipment to money into this account.
2.2.3.3 Processing
Users account would be loaded with the amount loaded by user.
2.2.3.4 Outputs
Sufficient funds in the mobile account.
2.2.3.5 Error Handling
If payment is unsuccessfully then User account wont be loaded with the amount,
the exceptions are handled in the system with proper error messages.

2.2.4 Ticket Booking

2.2.4.1 Introduction

xii
 Users book ticket for the journey they want to travel.
2.2.4.2 Inputs
From Station, To Station, No. Of Adults, No. Of childrens, Class, Type of Ticket,
Password, etc.
2.2.4.3 Processing
Inputs details would be sent to the Server along with Account details which would be
validated against accounting then ticket will be booked. The same ticket would be sent
to the user by SMS which act as the train local ticket for that particular journey.
2.2.4.4 Outputs
Booked ticket would be sent to the user by SMS which act as the local train
ticket for that particular journey.
2.2.4.5 Error Handling
It will verify all the necessary information if constraints are failed then
appropriate error messages would be thrown to the user.

2.2.5 Previous Transactions History

2.2.5.1 Introduction
Users can view the previous booked tickets by this functionality.
2.2.5.2 Inputs
Password to authenticate the application.
2.2.5.3 Processing
System will process the request of the previous transaction history by verifying the
password & mobile number.
2.2.5.4 Outputs
Previously booked tickets would be shown.
2.2.5.5 Error Handling
System checks to see whether credentials provided are valid or not. If not, proper
error message would be displayed.

2.2.6 Balance Enquiry:

2.2.6.1 Introduction
Allows the user to check users mobile account.
2.2.6.2 Inputs

xiii
 Credentials & Mobile Number.
2.2.6.3 Processing
Application validates the password & mobile number.
2.2.6.4 Outputs
Users account balance.
2.2.6.5 Error Handling
System checks to see whether credentials provided are valid or not. If not, proper
error message would be displayed.

2.2.7 Check Ticket:

2.2.7.1 Introduction
Allows the Ticket Collector/Checker to verify any ticket of the travelling passenger.
2.2.7.2 Inputs
TC user Id & Credentials.
2.2.7.3 Processing
Application validates the password & TC User Id.
2.2.7.4 Outputs
Validates the ticket of any travelling passenger.
2.2.7.5 Error Handling
System checks to see whether credentials provided are valid or not. If not, proper
error message would be displayed.

2.3. NON-FUNCTIONAL REQUIREMENTS

A software requirement that describes not what the software will do, but how the software will
do it, for example, software performance requirements, software external interface
requirements, design constraints, and software quality attributes. Nonfunctional requirements
are difficult to test; therefore, they are usually evaluated subjectively.

2.3.1 Performance
Some Performance requirements identified is listed below:
The database shall be able to accommodate as much data information possible.
Response time: For each User requests such as Book Ticket, Balance Enquiry,

xiv
 Previously Booked Tickets, Load Balance system response in the timely nature.
Capacity: Current system will handle capacity for the Mumbai Central Railway
passengers, if needed capacity can be increased

2.3.2 Reliability
The database may get crashed/hanged at any certain time due to virus or operating system
failure. Therefore, it is required to take the database backup frequently. Java platform is robust
application can manage hundreds of users with transparency.

2.3.3 Availability
Since its an SMS based application its available for almost all time. There can be chance of
failure due to server problem which can be resolved quickly at the server side.
Accuracy: Its very accurate as the system generated responses will be triggered to the
requested users in timely nature.

2.3.4 Security
Some of the factors that are identified to protect the software from accidental or malicious
access, use, modification, destruction, or disclosure are described below.
Only registered users are able to access Local Train Ticketing application.
Amount will be deducted from Users account only in case of successful from User
transaction.

2.3.5 Maintainability
Probability that a failed component system will be repaired or restored to a specified condition
with a specified period of time.
Mean time to repair
Modularization and accessibility

2.3.6 Portability
This application is mainly supported in Java/Android based Mobile Handsets.
J2ME: Local Train Ticketing Application Screens are written in the Java platform which
are simulated in the Mobile Emulator.

xv
3. Literature Survey

Literature study of samples J2ME Mobile examples which helped me in a way to know the
various features of J2ME packages. To understand the functionality of the interfaces, packages,
etc.

3.1. PURPOSE OF LITERATURE SURVEY

Literature study of samples J2ME Mobile examples which helped me in a way to know the
various features of J2ME packages. To understand the functionality of the interfaces, packages,
etc.

I went through the basic implementation of the J2ME software development projects, their
internal use of the Packages, Interfaces, Classes, etc.

Following are the literature from the survey are,

Implementation of any new requirement in the Mobile simulator.

Implementing mobile related small functionalities
Understanding Lists, Combo boxes, text boxes, frames, etc
Deploying the implemented features in the mobile applications
Running the deployed mobile application

xvi
3.2. METHODOLOGY
3.2.1 Agile Methodology
Agile SDLC methodology is a combination of iterative and incremental process models with
focus on process adaptability and customer satisfaction by rapid delivery of working software
product.

Agile Methods break the product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves
cross functional teams working simultaneously on various areas like planning, requirements
analysis, design, coding, unit testing, and acceptance testing.

At the end of the iteration a working product is displayed to the customer and important
stakeholders.

At a high-level, the steps in the agile model are as follows:

Steps 1 & 2: User Story Writing and Estimation

User stories are user requirements in the plain customers language without including too many
details. Usually User stories are written in following format.

As a <User> I want to <Perform a function> to <achieve something>

Some of the user stories can be huge, and could be divided into many smaller user stories; those
big user stories are also called Epics or Features. One Epic or Feature can have many
smaller user stories.

Story Estimation

Once story is completed, it needs to be estimated, in a session with the help of the team.
Participants of the story estimation team are development team members and product owner.
Presence of development team is important since they can provide good feedback regarding
design, development and testing activities. Product owner presence is also important because
of his knowledge of business.

xvii
Story points: Story points are used as unit of estimation in agile world. Sometimes teams
assigned a time frame to story point to get exact idea how much time it will take to complete
the story. Sometimes team select the hours instead of story point though it's not preferred
estimation unit.

The question is why we want to estimate the stories, the simple answer to this question is to
know how long would it take to complete them, knowing the estimate is important to get an
idea how many user stories can be completed within one Release.

Steps 3 & 4: Story Prioritization in the backlog

Only a set of stories are selected to be implemented in iteration. To select the stories for
iteration, team prioritizes them based on their importance, need and risk value. For example in
the start of the project user stories which are related to design will take precedence over
development related user-stories. Usually higher risk stories are also of highest priority ones.

Out of iteration stories can be prioritized and re-prioritize when needed inside the product
backlog, but once added to the iteration (sprint) adding or replacing user-stories with the
existing ones is not recommended.

There are couple of famous techniques used to prioritize the user stories. One of them is called
MoSCoW (Must Should Could Won't) technique. In this method user storys priority is defined
by words 'must', 'should', 'could' and 'wont'.

Step 5: Release Planning

A release is a time-boxed activity in which certain high ranked user stories are set to be
completed. A release planning meeting is arranged so team could see what product owner and
stakeholders want to achieve in a specific time. And also gets chance to look into the vision
and road map for the product. This meeting helps everyone in the team to come on the same
page. Stakeholders and product owner transfer their vision and expectation to the development
team. Development team contributes in refining the concept of the project by asking more
questions and in some cases providing the answers of the unknowns given by product owner
or come up as a result of the discussions.

xviii
Step 6 & 7: Sprint Planning & Task Creation Process

The Sprint planning meeting takes place in the beginning of iteration. The development team
selects a higher priority user story and divides it into one or many tasks. Tasks are created and
assigned by developers.

Same process is repeated for all the stories until capacity of the team is reached. Once capacity
is reached no more user stories are added. During the process of dividing the user stories into
task, everyone in the development team collaborate and give his/her estimate to complete a
task, planning poker technique can be used for that purpose. Team identifies the work to
perform and commits to delivering potential product increment at the end of iteration.

Step 8-12: Sprint Iteration

Development team works on design, development and testing activities during an iteration
(sprint). Duration of a sprint varies from team to team. 1-4 weeks iteration can be selected but
mostly 2 week iteration is popular in agile.

Step 8-12 shows sprint and activities performed during and at the end of a sprint. At the end of
each sprint product output is produced and demonstrated to the customer in Sprint Review
meeting. Also at the end of each sprint retrospective is performed to review the scrum process
within scrum team.

A release may consist of many sprints. Release output is a product that can be used by the
customer.

xix
4. Detailed design of the project

4.1 PRODUCT PERSPECTIVE

We have a solution to the legacy local train booking system problems of Indian local trains
departments. Below solution has been implemented to solve the problems of Mumbai Local
Train Passengers to book their tickets without standing in the railways ticket vending
windows.

We will develop a onetime installable mobile software which can be installed on the
passengers mobile device & register to use it. Once registered, he can recharge his account by
visiting the railway stations as we do for recharging the ATVM smart cards or by the Online
payment gateway transactions. Passenger can book the tickets when he wants to travel by local
trains by lunching application which will provide the options to select the required details for
the ticket booking. Once all the details are filled & user clicks on book ticket then software will
convert the details into request in the form of SMS & would be sent to the server SMS server
where it would be received, processed, accounting, response generations & response would be
sent to the requested user mobile number via SMS. This electronic ticket will have the similar
details as that of the normal railways paper local ticket. Ticket will have the timestamp, fare
& account details for authorization.

The proposed system provides below benefits,

Passengers can obtain tickets within fraction of seconds

Saving of time, money and efforts
Easier accessibility
Same ticket rates
Reach to customer
Reduce huge maintenance cost to railways
Go-Green with paperless
Less queue lengths on the railway ticket vending windows
No dependency on the equipment of the railway.
Can have ticket transaction history

4.2 SOFTWARE INTERFACE

Operating System Windows 7 or higher version

xx
 Memory Constraints: At least 4 GB RAM and 500 GB space on server hard disk
will be required for running the application.
J2ME, JDK, JRE, PHP, XAMPLITE, MySQL

4.3 PRODUCT FUNCTIONALITY

Local Railway Ticketing by SMS Application will help the users of the application/Passengers
to register themselves to use this application, book ticket for any local journey, view transaction
history, Cancel Ticket, Check Journey Fares, Update database, etc.
Register for Ticketing Application: Users who are interested to avail to use this
application must register in order to utilize the facility provided by the railway
department. In order proceed with this process user must have a running Mobile
Number, setup password, Date of birth, Email ID, etc.
Users need to login into the application once they have sign-up/registers.
In order to book the tickets user must have enough account balance.
All the booked tickets will be received as the SMS & will be available once server
responds to the requests.
Unique Mobile Ticket Reference Number will be available on the tickets,
Ticket Collectors/Checkers will verify the above MTRN.
Cancel the booked tickets within specified time limits.
Maximum last 5 transactions history.
Recharge account details.
Update the database for any modifications in the system such as fares, stations,
application version update etc.

xxi
4.4ARCHITECTURE DESIGN

The architecture of a system is a comprehensive framework that describes its form and structure
- its components and how they fit together. Software architecture must model the structure of
a system and the manner in which data and procedural components collaborate with one
another.

Local Railway Train Ticketing by SMS systems architecture design comprises of the all
components, sub-components of this system & how they are connected to each other.

4.5 USE CASES

Use-case is a story or a scenario that describes the functionality of the system. The
various use cases are Sign-Up, Register, Load Account, Book Ticket, Previously
booked ticket history.
Following are the use-cases used

Sign-Un

Sign-In

Register

Load Account

Book Ticket

Previously Booked Ticket History

xxii
 Balance Enquiry

Validate Ticket

4.5.1 Sign-Up:
The user who wants to use the application Sign-Up.
4.5.2 Sign-In:
Once users Sign-Up then he will Sign-In into the application with the credentials.
4.5.3 Register:
User registers with the personal details & saves the details.
4.5.4 Load Account:
User load the money into his mobile account either by payment gateway/ railway station
equipment.
4.5.5 Book Ticket:
User books local train ticket by using this application.
4.5.6 Previously Booked Ticket History:
Allows users to view the previously booked ticket history.
4.5.7 Balance Enquiry:
Allows the user to get account balance.
4.5.8 Check Ticket:
Allows the Ticket Collector/Checker to verify the ticket of any travelling user.

xxiii
 UML use case diagram example - top level use case
Use-Case Model Hierarchy
Users: User initially download the Mobile Local Railway Ticketing application. User
Sign-Up to use application by entering Mobile Number, Password which will be saved
into the system later on User Signs-In into the application with the credentials which
allows the user to register, book ticket, Load Account balance, view previously booked
ticket history, update the database, synchronize the version update.

Ticket Collector/Checker: Ticket Collector/Checker validates the ticket of any passenger

travelling in local trains.

xxiv
Railway Dept. Clerks: Railway department has equipment to load account balance in the
passengers mobile account, clerks in the railway department will those equipment to load
funds in the passengers mobile account.

4.6 CLASSES / OBJECTS

Class diagram is UML structure diagram which shows structure of the designed system
at the level of classes and interfaces, shows their features, constraints and relationships
- associations, generalizations, dependencies, etc.
4.6.1 Register
4.6.1.1 Attributes
First Name, Last Name, Mobile Number, Password, Email-ID are the attributes of
Register class.
4.6.1.2 Functions
Reset Password, Unlock User, Change Profile are the actions performed by the user on
the system.
4.6.2 Book Ticket
4.6.2.1 Attributes
To, From, # of Childs, # of Adults, Class, Type are the attributes of Book Ticket class.
4.6.2.2 Functions
Book ticket for the user are the actions that can be performed on the Book Ticket class.
4.6.3 Load Account
4.6.3.1 Attributes
Mobile Number, Payment details, Railway department Id, Amount, validity are the
attributes of the Load Account Class.
4.6.3.2 Functions
Load Account balance are the actions can be performed on the Load Accont Class.
4.6.4 Balance Enquiry
4.6.4.1 Attributes
Mobile Number, Credentials, Balance are the attributes of the Balance Class.
4.6.4.2 Functions
Get the Account Balance are the actions can be performed on the Balance Enquiry
Class.
4.6.5 Check Ticket
4.6.5.1 Attributes

xxv
 Mobile Ticket Reference Number, TC Id, Credentials are the attributes of the Check
Ticket Class.
4.6.5.2 Functions
Validate the Ticket of any passenger is the action performed on the Check Ticket
Class.

xxvi
4.7 CONTEXT DIAGRAM

xxvii
4.8 SEQUENCE DIAGRAM

4.9 DATA DESCRIPTION

Local Railway Train Ticketing by SMS application data description can be described as,

4.9.1 Data Flow Diagrams

A data flow diagram (DFD) is a graphical system model that shows all of the main
requirements for an information system in one diagram: inputs and outputs, processes, and
data storage. A DFD describes what data flows rather than how it is processed. Everyone
working on a development project can see all aspects of the system working together at once
with DFD. That is one reason for its popularity. The DFD is also easy to read because it is
graphical model.
The DFD is mainly used during problem analysis. End Users, management, and all
information systems workers typically can read and interpret the DFD with minimal training.

xxviii
Symbols used:

Sr Symbol Name Description

no.

1 External An external entity is source or

entity destination of a data flow
which is outside the area of
study. For e.g. , Customer,
Or Student etc.

2 Process
A process shows a
transformation or
manipulation of data flows
Or within the system

3 Dataflow A data flow shows the flow of

information from its source to
or its destination. A data flow is
represented by a line, with
arrowheads showing the
direction of flow.

4 Datafile or A data store is a holding place

Datastore for information within the
system. Data stores may be
long-term files such as sales
or ledgers, or may be short-term
accumulations: i.e. batches of
documents that are waiting to
be processed.

xxix
4.9.1.1 ZERO LEVEL DFD

xxx
4.9.1.2 DFD 1.0

4.9.1.3 DFD 2.0

xxxi
4.9.1.4 DFD 2.1

4.9.1.5 DFD 2.2

xxxii
4.9.2 Entity Relationship Diagram

There are several notations for data modeling. The actual model is frequently called Entity
Relationship Diagram (ERD) because it depicts data in terms of the entities and relationships
described by the data.

Entity Relationship Diagram (Model):

The Entity Relationship Diagram (Model) is based on perception of a real world

that consists of a collection of basic objects called as Entities and relationships among these
objects. Entities in database are described as set of attributes.

A Relationship is an association among several Entities.

The set of Entities of the same type are called as Entity Set.

The set of Relationships of same type are called as Relationship Set.

The ER Diagram is built with the following components

Rectangles which represents Entity Set.

Ellipses which represents Attributes.
Daimond, which represents Relationships.
Lines, which represents Link
Double ellipse which represents multivalve attributes
Dashed ellipse, which represents derived attributes.
Double line, which represents total participation of an entity in a relationship set

xxxiii
xxxiv
4.10 DATA DICTIONARY

Database_Version
SR No Number
Version Number
Updated DateTime

Users
Data
Column Name Type
SR No Number
First Name Varchar
Last Name Varchar
Mobile Number Number
DOB Date
Version Number

Load_Money
SR No Number
Version Number
Mobile Number Number
Amount Number
Updated DateTime

xxxv
 Transactions
Data
Column Name Type
SR No Number
TicketID Number
FromStn Varchar
Mobile Number Number
ToStn varchar
Adults Number
Childs Number
Total Tickets Number
Type Varchar
Class Varchar
Fare Number
Date Date
Time Time
Version Number

Balance
Data
Column Name Type
SR No Number
Mobile Number Number
Balance Number
Date Date
Time Time
Version Number

xxxvi
4.11 SCREEN IMAGES

4.11.1 Home Screen

xxxvii
4.11.2 Sign-Up Screen

xxxviii
4.11.3 Sign-In Screen

xxxix
4.11.4 Registration Screen

xl
4.11.5 Book Ticket Screen

xli
4.11.6 Recharge Screen

xlii
4.11.7 Check Ticket

xliii
5. References

This complete project report has been prepared on the basis of following references:

Software Specification and Design: An Engineering Approach By John C. Munson

Software Engineering Design - By Carlos Otero
Head First JSP & Servlets By Kathy Sierra, Bert Bates, Bryan Basham (Publisher :
OReilly)
JSP Complete Reference By Phil Hanna
JDBC, Servlets and JSP Black Book By Santosh Kumar k.
JDK 5th edition By Ivor Horton
JAVA How to Program by Harvey M. Deitel, and Paul J. Deitel
Bible Javascript By Danny Goodman
JAVA Server Pages By Hans Bergsten (Publisher : OReilly}
www.guru99.com
www.mysql.com
www.php.nets
www.apache.org

xliv