ATAL BIHARI VAJPAYEE

Indian Institute of Information Technology

andManagement, Gwalior

SOFTWARE DESIGN REPORT

on
Railway Reservation System
24 April 2020

Submitted by:

Mansi Meena | 2018-IMG-030

Rishu Kumar| 2018-IMG-048
Saumya Srivastava |2018-IMG-056
TABLE OF CONTENTS
1. Design considerations ............................................................................................................................... 2
1.1. Assumptions ....................................................................................................................................... 2
1.2. Constraints ......................................................................................................................................... 2
1.3. System environment ........................................................................................................................... 2
1.4. Design methodology .......................................................................................................................... 2
2. Architecture............................................................................................................................................... 2
2.1. System design .................................................................................................................................... 2
2.2. System decomposition ....................................................................................................................... 4
2.2.1. Functional decomposition tree .................................................................................................... 4
3. Data design ................................................................................................................................................ 5
3.1. Data description ................................................................................................................................. 5
3.2. Data dictionary ................................................................................................................................... 5
4. Component design .................................................................................................................................... 9
4.1. Login ................................................................................................................................................ 10
4.2. Provide biometric characteristics ..................................................................................................... 11
4.3. Select language ................................................................................................................................ 13
4.4. Create new group / subgroup / type ................................................................................................. 15
4.5. Import of assets / licenses / locations / persons................................................................................ 17
4.6. View/Add/Modify – assets / licenses / locations ............................................................................. 19
4.7. Assign/Modify - role ........................................................................................................................ 20
4.8. Add request ...................................................................................................................................... 22
4.9. View/Approve/Reject request .......................................................................................................... 24
4.10. Assign assets / licenses / locations ................................................................................................. 26
4.11. Delete assets / licenses / locations / persons .................................................................................. 28
4.12. View/Modify - person .................................................................................................................... 30
4.13. Add / View / Modify – faculty / department .................................................................................. 32
4.14. Report ............................................................................................................................................. 33
4.15. Borrow – asset / location ................................................................................................................ 35
4.16. View/Print – plan of big location ................................................................................................... 36
5. Class diagrams ........................................................................................................................................ 56
5.1. Basic folders for class diagram ........................................................................................................ 56
5.2. Basic class diagram .......................................................................................................................... 57
5.3. Full class diagram ............................................................................................................................ 58
Page x
5.4. Module Add new asset ..................................................................................................................... 59
5.5. Module Add new request ................................................................................................................. 61
5.6. Module Search ................................................................................................................................. 63
5.7. Module Assign asset to location ...................................................................................................... 75
1. Design considerations

1.1Assumptions:

The system design would be able to manage all the reservation related functions.
The system is distributed in nature and has been divided into different zones. Each
zone has same functionalities and can store the information about Train name, train
schedules, availability.

This system is developed in three categories:

1. Ticket Reservation
2. Ticket Cancellation
3. Status checking

Modules:
 Admin Module
 Train Details Module
 Reservation Module
 Billing Module
 Cancellation Module

Features:
• The administrator would be able to enter any change related to the train
information like change in train name, number etc.
• The system is able to reserve seat in a train for a passenger and cancel a
reservation.
• The passengers can check their reservation status online by entering their PNR no.
• The system can display passenger’s current status like confirmed, RAC or waiting
list. They are also able to see information related to the train schedules.
• The system is able to print the report and can generate reservation chart, train
report, reservation ticket which will have train no and name, date of journey,
Boarding station, destination station, person name, age, [censored], total fare and a
unique PNR no.
 • The system is able to print the cancellation ticket which will have total fare and the
amount deducted.

1.2 Constraints:

Design constraints can be imposed by other standards, hardware limitations, etc.

 Standards Compliance:

Specify the requirements derived from existing standards or regulations. They

might include:

(1) Report format

(2) Data naming
(3) Accounting procedures
(4) Audit Tracing.

For example, this could specify the requirement for software to trace processing activity.
Such traces are needed for some applications to meet minimum government or
financial standards. An audit trace requirement might, for example, state that all
changes to a payroll data base must be recorded in a trace file with before and after
values.

 Hardware Limitations:
Identify the requirements for the software to operate inside various
hardware constraints.
25

 Quality Characteristics:
There are a number of quality characteristics that can apply to software. Pick the
ones most important to this product and develop a section for each one.

Definitions of the quality characteristics follow:

 Correctness - extent to which program satisfies specifications, fulfills user’s

mission objectives
  Efficiency - amount of computing resources and code required to perform function
 Flexibility - effort needed to modify operational program
 Integrity/security - extent to which access to software or data by unauthorized
 people can be controlled
 Interoperability - effort needed to couple one system with another
 Maintainability - effort required to locate and fix an error during operation
 Portability - effort needed to transfer from one h/w or s/w environment to another
 Reliability - extent to which program performs with required precision
 Reusability - extent to which it can be reused in another application
 Testability - effort needed to test to ensure performs as intended
 Usability - effort required to learn, operate, prepare input, interpret output

1.3 System environment:

To develop this application, a high-speed internet connection, a database server, a web

server and software is required.
Project RRS is a complete web-based application. The main technologies and tools that
are associated with RRS are:

Software Requirement (Any one of the servers are used):

* WAMP Server
* XAMPP Server
* MAMP Server
* LAMP Server

Hardware Requirement:
* Intel Processor 2.0 GHz or above.
* GB RAM or more.
* 160 GB or more Hard Disk Drive or above.
* Front end:
* HTML
* CSS
* JavaScript
* Back end:
* PHP
* MySQL

1.4 Design methodology:

  This project is carried out using SPIRAL DEVELOPMENT MODEL.
o The spiral model is a software development process combining elements of
both design and prototyping-in-stages
o This model of development combines the features of the prototyping model
and the waterfall model.
o The spiral model is intended for large, expensive and complicated projects.

SPIRAL MODEL:
A spiral model is divided into a number of framework activities
Typically, there are six task regions as shown in figure.
 Customer communication—tasks required to establish effective communication
between developer and customer.
 Planning—tasks required to define resources, timelines, and other project related
information
 Risk analysis—tasks required to assess both technical and management risks.
 Engineering—tasks required to build one or more representations of the
application.
 Construction and release—tasks required to construct, test, install, and provide
user support (e.g., documentation and training).
 Customer evaluation—tasks required to obtain customer feedback based on
evaluation of the software representations created during the engineering stage
and implemented during the installation stage.

The decision to use the spiral model methodology is due to the following characteristics
of the project:

 Early iterations of the project are the cheapest, enabling the highest risks to be
addressed at the lowest total cost. This ensures that as costs increase, risks
decrease.
 Each iteration of the spiral can be tailored to suit the needs of the project.
2. Architecture

2.1 System design:

A typical three-layer structure is used in the system: the database layer, the application
service layer and the user interface layer.

The context diagram shows the main actors interacting with the system.

The database layer

The database is used to hold data, including user registration information, ticket
ordering information, ticket information and all of the other information.

The application service layer

The application service layer is the core of this three-layer structure, the system functions
and business logic are handled in this layer. In this layer, the system's business logic is
encapsulated, the application service interfaces is provided for the user interface layer
and the system modules between the function calls. The application service layer also
updates data in the database, according to the service request of the top layer.

The user interface layer

The user interface layer is a program that runs on a remote user computer. It
displays the provided services by the server to the user. When the user selects a service,
this program sends request to the server. When the server returns the processed result,
this program shows it to the user.
 2.2. System decomposition: System decomposition for RRS begins by decomposing the
system into cohesive, well-defined subsystems. Subsystems are then decomposed into
cohesive, well-defined components. Components are then decomposed into cohesive,
well-defined sub-components:

 System decomposition Tree

Railway reservation system

Booking profile
history
help
PNR enquiry Find Train
Reservation
Edit Change password
Cancellation

Enter PNR no Submit

Fill
Reset
details
Submit query
Search
Enter details Make payment

Check availability
Enter details Fin Reset
d

Decomposition tree for Railway reservation system

6. Class diagrams

6.1 Basic folders for class diagram

6.2 Class diagram for RRS
6.3 Class Diagram for booking ticket
The PHP class for booking new ticket is:“passenger.php” ,it import
sfiveotherclassestousethemfor calling different methods. The five classes are : “Train” ,
“Clerk”, “Railway system” , “Ticket” and “ Payment”.
“Ticket
class”containsseveralmethodstoconnecttothedatabase,“Passenger”usesthisclasstoselectdat
a
fromtheDatabase,orUpdatetheDatabase.Therelationshipbetweenthetwoclassesisasimpl
eaggregation
relationship.Theparent(Container)classis“Passenger”andthechild(Contained)classis“ticket
” .the childclasscanstillexistandfunctioniftheparentclassisdestroyed.
Themainmethodsusedby“passenger”are:“delete ticket”and “new ticket”.
.Thismethodexecutesand computes fare amount and form new ticket or delete the old
ticket.

“Train ”class contains no operations of its own it just gets information about the
train no and the train name and update the database
accordingly.Theparent(Container)classis“passenger”andthechild(Contained)classis“train”
.

“Clerk ”class contains two operations of its own namely cancellation form and form
details cancellation form generates a cancellation request form for the who want to delete
his booked ticket while form details is a function that return details of the form to the
parent class “passenger”.

“Payment” is a class that do not have functions of its own ,it just contains return total
amount that has to be paid by the user who has just booked ticket.
Lastly the parent class “passenger” contains a class named railway system that has id
attribute and a class named response which basically returns a response to the
passenger class so that the booking ticket process is initiated and done completely.
6.4 Class Diagram for ticket Cancellation
ThePHP classforticket cancellation
is:“Customer.java”,itimportsfiveotherclassestousethemfor
callingdifferentmethods.Thefourclassesare:“Refund”,“Ticket”,“Agent”, “Booking
counter” and “common functions”.

“Ticket
class”containsseveralmethodstoconnecttothedatabase,“Passenger”usesthisclasstoselectdat
a
fromtheDatabase,orUpdatetheDatabase.Therelationshipbetweenthetwoclassesisasimpl
 eaggregation
relationship.Theparent(Container)classis“Passenger”andthechild(Contained)classis“ticket
”the child class can still exist and function if the parent class is destroyed.

“Common functions ”class has many other important functions like “search ticket”,
“book ticket”, , “cancel ticket”, “make payments” and “fill details” .All the functions
do their respective jobs and return the data to the customer class to update the database.

“Refund” class the child class contains an operation refund amount that calculates &
returns the amount to be refunded to the user when he/she cancel the ticket. it has several
function inside it to deduce the required amount of money from the original amount paid
by the user and return the required data to the customer function.

“Agent class ” contains no other functions of its own it just contains two attributes
namely id and name of the user that is taking the charge of canceling the ticket of the
user.
6.5 Module Search

Figure 50. Class diagram for Search

 Interface IGenericSearch – this interface contains names of universal methods
which are applicable for any type of search.

Class AGenericSearch – this is abstract class contains abstract methods. Those

methods performs particular task, but they don‟t know where data come from.
Also this class inherits all methods from interface IGenericSearch.

Class SQLSearch – this is more concrete class, which inherits all methods from
interface IGenericSearch and class AGenericSearch. This class performs search in
specific area, in databases.

Class DB_Utiles – this class connects with DB and return result of query
in different data structures. Class SQL_query - general class to run any
SQL query and receive a table as the result.

Class Message – this class transfers information (for example, about errors) from class
to class. We choose message instead of String because it is more universal. String is
not mutable, as soonaswecreatenew String, weloseoldinformation, while
withmessagethis problem is absent.

Class SearchDriver – this class shows in which way we perform search. It takes
from user request what and where to search, creates necessary objects, after all
another class performs search in thoseobjects.

Class SearchException – this class and its subclasses are form of Throwable that
indicates conditions that a reasonable application might want to catch.

Class ResultBean – contains getters for accessing Data Module (JAVA classes)
from the View Module (HTML). Getters must have names with following strong
rule: “get” + MethodName. Correspondent method will be automatically called.

Class SearchBean – contains getters for accessing Data Module (JAVA classes)
from the View Module (HTML). Getters must have names with following strong
rule: “get” + MethodName. Correspondent method will be automatically called.

Classes RunSearch, SQLSearchTest, SQLQueryTest used to run application or test

some application‟s functions.

We implemented module SQLSearch, based on the data access method (SQL

database), it is no class CollectionSearch. However modules design allows
performing search in any collections in easy way. For this it is necessary to add
 concrete class (for example CollectionSearch) with specific methods (for example,
getFromCollection()). The logic of search in this collection doesn‟t change,
because this class will inherit methods from abstract file AGenericSearch and
interface IGenericSearch.

So from this follows that in our design we use Abstract Factory Pattern. By
definition Abstract Factory Pattern “provides an interface for creating families of
related or dependent objects without specifying their concrete classes”. In
implementation it is no families (it is only one class SQLSearch), because as was
mentioned earlier, in our project Basic search is a one of the cases of Advanced
search. In addition all information in inventory system keeps in databases, so there
is no necessity to perform search in another collections. However design is flexible
and allows creating families (for example, SQLSearch, CollectionSearch) for more
complicated task.

We didn‟tuse Visitorpattern in ourdesign, becauseof its maindisadvantages:

argumentsandthereturntype ofvisitingmethodshave to be known in advance;

visitor pattern breaks the Open-Closed Principle (Software entities should be open
for extension but closed for modification);

writing additional code: the visitor class with one abstract method per class, and a
accept method per class. If we add anewclass, thevisitor class needsanewmethod
7. Questions
OBJECTIVE:

 The main objective of this section is to pin out major advantages and limitations of
railways reservation system.

 There are a number of questions that we would use to guide our review.

Q1. Is the Passenger Reservation System an optimal application for the users?

Ans. The Internet-based E-ticketing reservation system, whose front end has been
developed using CRIS. It allows a passenger anywhere to book train tickets from
any station to any station. RRS handles reservations, changes, cancellations and
refunds. Complex rules, validations and fare-computation techniques are
interwoven in the application.

Q2. Is the mode used for payment services efficient?

Ans. RRS provides an E-Ticket system for better passenger experience and convenience.
Many of RRS’s customers could pay through an electronic payment gateway
interfaced with the FOIS.

Q3. Does the website keep proper track of train timings?

Ans. National Train Enquiry System has been used in RRS for latest train running times
and live train tracking which uses optimal devices and systems.

Q5. Does RRS provide optimal E-Systems?

Ans. Provides a secure, fair and transparent service methods through a web-based
interface. It enables passengers to securely upload their information to a central server in
encrypted form, which can be decrypted only by authorized railway
officials after the opening.
Q4. Does RRS provide a platform for Web-enabled claims?
Ans. The Web-based software used in RRS enables the public to file and track claims
online.

Q6. Does the website provide proper train route information to ensure safety during
journey?
Ans. The RRS software provides real-time railway route information. Information
includes location, status and keeps a proper track of all the intermediate stations between
the destinations. The software issue SMS alerts to management and supervisors if crew
levels drop below a level likely to affect train operations.