Rawilay Reservation System

Online Railway Reservation

CONTENTS

1. INTRODUCTION.................................................................................................... 6

1.1 PURPOSE............................................................................................................... 61.2 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS..................................................61.3 REFERENCES.......................................................................................................... 6

2. OVERALL DESCRIPTION......................................................................................7

2.1.1 System Interfaces...................................................................................................72.1.2 User Interfaces.......................................................................................................72.1.3 Hardware Interfaces...............................................................................................72.1.4 Software Interfaces................................................................................................72.1.5 Communications Interfaces....................................................................................7

2.2 CONSTRAINT......................................................................................................... 82.3 ARCHITECTURE DIAGRRAM...................................................................................82.4 DATABASE DESIGN...............................................................................................9

3. SOFTWARE IMPLEMENTATION...........................................................................10

3.1 THE SOFTWARE LIFE CYCLE.......................................................................103.2 IMPLEMENTATION......................................................................................... 113.3 TESTING........................................................................................................... 123.4 VERIFICATION AND VALIDATION..............................................................12

3.4.1 4.4.1 VERIFICATION.........................................................................................133.4.2 VALIDATION....................................................................................................13

3.5 ABOUT CODING.............................................................................................. 13

4. SPECIFIC REQUIREMENTS.................................................................................14

4.1 USE CASE REPORT..............................................................................................144.1.1 Ringing Alarm.....................................................................................................14

4.2 USER INTERFACE................................................................................................. 154.2.1 Image...................................................................................................................154.2.2 Image...................................................................................................................154.2.3 Communications Interfaces..................................................................................15

4.3 SOFTWARE PRODUCT FEATURES.........................................................................154.3.1 Future..................................................................................................................15

5. GLOSERY............................................................................................................ 16

5.1 A......................................................................................................................... 165.1.1 Aggregation.........................................................................................................165.1.2 Analysis...............................................................................................................165.1.3 Architecture.........................................................................................................165.1.4 Association..........................................................................................................16

5.2 B......................................................................................................................... 175.2.1 Behavior..............................................................................................................175.2.2 Binary association................................................................................................17

5.3 C......................................................................................................................... 175.3.1 Class diagram......................................................................................................175.3.2 C#........................................................................................................................175.3.3 Component..........................................................................................................175.3.4 Context................................................................................................................18

5.4 D......................................................................................................................... 185.4.1 Delegation...........................................................................................................185.4.2 Dependency.........................................................................................................185.4.3 Deployment diagram............................................................................................185.4.4 Derived element...................................................................................................18

5.5 E......................................................................................................................... 195.5.1 Extends................................................................................................................19

5.6 G......................................................................................................................... 195.6.1 Generalization......................................................................................................19

5.7 I.......................................................................................................................... 195.7.1 Implementation....................................................................................................195.7.2 Interaction............................................................................................................195.7.3 Interface...............................................................................................................19

5.8 M........................................................................................................................ 205.8.1 Message...............................................................................................................205.8.2 Model..................................................................................................................205.8.3 Module................................................................................................................20

5.9 0......................................................................................................................... 205.9.1 Object diagram....................................................................................................205.9.2 Object lifeline......................................................................................................205.9.3 Operation.............................................................................................................21

5.10 R......................................................................................................................... 215.10.1 Relationship.........................................................................................................21

5.11 S......................................................................................................................... 215.11.1 Specification........................................................................................................215.11.2 Structural feature..................................................................................................21

5.12 U......................................................................................................................... 215.12.1 Use case...............................................................................................................215.12.2 Use case diagram.................................................................................................225.12.3 Use case instance.................................................................................................225.12.4 Use case model....................................................................................................225.12.5 Uses.....................................................................................................................22

6. APPENDICES....................................................................................................... 23

6.1 APPENDEX A CODING........................................................................................236.1.2 RingAlarm...........................................................................................................266.1.3 SendingDetector..................................................................................................296.1.4 SmsSender...........................................................................................................316.1.5 ContactBean........................................................................................................326.1.6 DatabaseHandler..................................................................................................34

1. INTRODUCTION

This project aims at development of an Online Railway Reservation Utility which facilitates the Railway customers to manage their reservations online, and the Railway administrators to modify the backend databases in a User-Friendly manner.

The Customers are required to register on the server for getting access to the database and query result retrieval. Upon registration, each user has an account which is essentially the ‘view level’ for the customer. The account contains comprehensive information of the user entered during registration and permits the customer to get access to his past reservations, enquire about travel fare and availability of seats, make afresh reservations, update his account details, etc.

The Railway Administrator is the second party in the transactions. The administrator is required to login using a master password, once authenticated as an administrator, one has access and right of modification to all the information stored in the database at the server. This includes the account information of the customers, attributes and statistics of stations, description of the train stoppages and physical description of coaches, all the reservations that have been made, etc. The railway administrator has the right to modify any information stored at the server database.The purpose of this source is to describe the railway reservation syste which provides the train timing details, reservation, billing and cancellation on various types of reservation namely,• Confirm Reservation for confirm Seat.• Reservation against Cancellation.• Waiting list Reservation.• Online Reservation.• Tatkal Reservation.

MOTIVATIONThis project is dedicated to

model the existing Railway/(other) reservation systems provide a comprehensive set of features to enhance their

operational limits evaluate their performance in different scenarios suggest modifications for greater efficiency

2. OVERALL DESCRIPTION

2.1.1 System Interfaces

Front End Client: Smart Phone

DataBase Server: ANDROID SQLITE, Operating System ANDROID

Back End: Java, Operating System (Android)

2.1.2 User Interfaces

Smart Phone Application

2.1.3 Hardware Interfaces

1. P-IV or faster Processor.

2. Minimum 2 MB hard disk space.

3. 64 MB of RAM or more.

4. GSM Service.

2.1.4 Software Interfaces

IDE:

Name: Eclipse Android

Version: 14.0

Source: https:/eclipse.org/downloads/

Java:

Name: JDK 1.7.0

Version: 1.7.0

Source : http://java.com/en/download/index.jsp

2.1.5 Communications Interfaces

Client on Mobile will be using GSM.

2.2 Constraint GUI is only in English

http://java.com/en/download/index.jsp

https://netbeans.org/downloads/

Roll number and card number is used for the pay fees of student.

Only registered students are authorized to use the services.

This system is working for single server.

.

3. SOFTWARE IMPLEMENTATION

3.1 DATA FLOW DIAGRAM

A data flow diagram (DFD) is a graphical representation of the "flow" of data

through an information system. DFDs can also be used for the visualization of data processing

(structured design).On a DFD, data items flow from an external data source or an internal data

store to an internal data store or an external data sink, via an internal process. A DFD provides no

information about the timing of processes, or about whether processes will operate in sequence or

in parallel. It is therefore quite different from a flowchart, which shows the flow of control through

an algorithm, allowing a reader to determine what operations will be performed, in what order, and

under what circumstances, but not what kinds of data will be input to and output from the

system, nor where the data will come from and go to, nor where the data will be stored (all of

which are shown on a DFD).

It is common practice to draw a context-level data flow diagram first, which shows the interaction

between the system and external agents which act as data sources and data sinks. On the context

diagram (also known as the 'Level 0 DFD') the system's interactions with the outside world are

modelled purely in terms of data flows across the system boundary. The context diagram

shows the entire system as a single process, and gives no clues as to its internal organization.

This context-level DFD is next "exploded", to produce a Level 1 DFD that shows some of the detail

of the system being modeled. The Level 1 DFD shows how the system is divided into sub-systems

(processes), each of which deals with one or more of the data flows to or from an external agent,

and which together provide all of the functionality of the system as a whole. It also

identifies internal data stores that must be present in order for the system to do its job, and shows

the flow of data between the various parts of the system.

3.2 Architecture Diagrram

Cell Phone Clients

3.3 Database Design

Database

Database & Content Management System

3.4 USE CASE DIAGRAM

A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases. The main purpose of a use case diagram is to show what system functions are performed for which actor. Roles of the actors in the system can be depicted.

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent description of the desired behavior, perhaps the system or use case boundaries should be re-examined. Alternatively, interaction among actors can be part of the assumptions used in the use case.

Use cases

A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.

Actors

An actor is a person, organization, or external system that plays a role in one or more interactions with the system.

System boundary boxes (optional)

A rectangle is drawn around the use cases, called the system boundary box, to indicate the scope of system. Anything within the box represents functionality that is in scope and anything outside the box is not.

3.5 Railway reservation system

3.6 RAILWAY RESERVATION LEVEL 0 DFD

3.7 RAILWAY RESERVATION LEVEL 1 DFD

3.8 REFERENTIAL DIAGRAM

Software Requirements Specification

4. SPECIFIC REQUIREMENTS

4.1 Use Case Report

4.1.1 Ringing Alarm

Name: Ringing Alarm

Description: The boss send sms to clients and client receive sms and alarm ringing

Actor: BOSS, CLIENT

Main scenario:

1. The boss send sms to the all clients will receive sms and alarm will automatically ringing to all

clients cell phones.

4.2 User Interface

4.2.1 Image

4.2.2 Image

4.2.3 Communications Interfaces

Connect the mobile phone to Internet or Gsm

4.3 Software Product Features

document.doc (04/18/14) Page 1


4.3.1 Future

In future we will provide Email service also



5. GLOSERY

GLOSSARY

5.1 A

5.1.1 Aggregation

A special form of association that specifies a whole-part relationship between the aggregate

(whole) and a component part.

5.1.2 Analysis

The part of the software development process whose primary purpose is to formulate a model of

the problem domain. Analysis focuses what to do, design focuses on how to do it.

5.1.3 Architecture

The organizational structure of a system. An architecture can be recursively decomposed into

parts that interact through interfaces, relationships that connect parts, and constraints for

assembling parts.

5.1.4 Association

The semantic relationship between two or more classifiers that involves connections among their

instances.

Attribute



A named slot within a classifier that describes a range of values that instances of the classifier

may hold.

5.2 B

5.2.1 Behavior

The observable effects of an operation or event, including its results.

5.2.2 Binary association

An association between two classes. A special case of an n-ary association.

5.3 C

5.3.1 Class diagram

A diagram that shows a collection of declarative (static) model elements, such as classes, types,

and their contents and relationships.

5.3.2 C#

It is developed in the behalf of C/C++ and Java.

5.3.3 Component

An executable software module with identity and a well-defined interface.



5.3.4 Context

A view of a set of related modeling elements for a particular purpose, such as specifying an

operation.

5.4 D

5.4.1 Delegation

The ability of an object to issue a message to another object in response to a message. Delegation

can be used as an alternative to inheritance.

5.4.2 Dependency

A relationship between two modeling elements, in which a change to one modeling element (the

independent element) will affect the other modeling element (the dependent element).

5.4.3 Deployment diagram

A diagram that shows the configuration of run-time processing nodes and the components,

processes, and objects that live on them. Components represent run-time manifestations of code

units.

5.4.4 Derived element

A model element that can be computed from another element, but that is shown for clarity or that

is included for design purposes even though it adds no semantic information.



5.5 E

5.5.1 Extends

A relationship from one use case to another, specifying how the behavior defined for the first use

case can be inserted into the behavior defined for the second use case.

5.6 G

5.6.1 Generalization

A taxonomic relationship between a more general element and a more specific element. The

more specific element is fully consistent with the more general element and contains additional

information.

5.7 I

5.7.1 Implementation

A definition of how something is constructed or computed. For example, a class is an

implementation of a type, a method is an implementation of an operation.

5.7.2 Interaction

A specification of how messages are sent between instances to perform a specific task. The

interaction is defined in the context of a collaboration.

5.7.3 Interface

A declaration of a collection of operations that may be used for defining a service offered by an

instance.



5.8 M

5.8.1 Message

A specification of a communication between instances that conveys information with the

expectation that activity will ensue. The receipt of a message instance is normally considered an

instance of an event.

5.8.2 Model

A semantically closed abstraction of a system.

5.8.3 Module

A software unit of storage and manipulation. Modules include source code modules, binary code

modules, and executable code modules.

5.9 0

5.9.1 Object diagram

A diagram that encompasses objects and their relationships at a point in time. An object diagram

may be considered a special case of a class diagram or a collaboration diagram.

5.9.2 Object lifeline

A line in a sequence diagram that represents the existence of an object over a period of time.



5.9.3 Operation

A service that can be requested from an object to effect behavior. An operation has a signature,

which may restrict the actual parameters that are possible.

5.10 R

5.10.1 Relationship

A semantic connection among model elements. Examples of relationships include associations

and generalizations.

5.11 S

5.11.1 Specification

A declarative description of what something is or does.

5.11.2 Structural feature

A static feature of a model element, such as an attribute.

5.12 U

5.12.1 Use case

The specification of a sequence of actions, including variants, that a system (or other entity) can

perform, interacting with actors of the system.



5.12.2 Use case diagram

A diagram that shows the relationships among actors and use cases within a system.

5.12.3 Use case instance

The performance of a sequence of actions being specified in a use case. An instance of a use case.

5.12.4 Use case model

A model that describes a system’s functional requirements in terms of use cases.

5.12.5 Uses

A relationship from a use case to another use case in which the behavior defined for the former

use case employs the behavior defined for the latter.



6. APPENDICES

6.1 Appendex A Coding


Rawilay Reservation System

Education

Transcript of Rawilay Reservation System