Online railway reservation system
32 likes•51,047 views
This document describes a railway reservation system project created by three computer engineering students. It includes requirements, UML diagrams, and an abstract. The functional requirements are secure registration, payment, and account management. Non-functional requirements include performance, quality, and security. Technical requirements include using a browser, Apache server, MySQL, PHP, JavaScript, HTML and CSS. UML diagrams created for the project include class, object, use case, activity, statechart, sequence, collaboration, deployment, and package diagrams. These diagrams model different aspects of the railway reservation system.
Online railway reservation system
- 1. College of Engineering, Pune (An Autonomous Institute of Government of Maharashtra) Wellesley Road, Shivajinagar, Pune 411005 THIRD YEAR COMPUTER ENGINEERING SOFTWARE ENGINEERING PROJECT RAILWAY RESERVATION SYSTEM SUBMITTED BY GUIDED BY RITESH NEVE (111203055) PROF. SHIKHA GUPTA RAJENDRA KADAM (111203050) NINAD RAJPUT (111203052)
- 2. INDEX 1. ABSTRACT 1 2. REQUIREMENTS: 2 2.1 FUNCTIONAL REQUIREMENTS 2.2 NON FUNCTIONAL REQUIREMENTS 2.3 TECHNICAL REQUIREMENTS 3. DIAGRAMS: 3.1 CLASS DIAGRAM 3 3.2 OBJECT DIGRAM 5 3.3 USE CASE DIAGRAM 6 3.4 ACTIVITY DIAGRAM -WITH SWIM LANE 7 -WITHOUT SWIM LANE 8 3.5 STATECHART DIAGRAM 9 3.6 SEQUENCE DIAGRAM 11 3.7 COLLABORATION DIAGRAM 12 3.8 DEPLOYMENT DIAGRAM 13 3.9 PACKAGE DIAGRAM 14
- 3. 1 ABSTRACT The railway reservation system is software for the purpose of reserving train seats at any time and from anywhere. This application provides us complete information about a train between specified source and destination. This application gives current status of reservations of particular train, fares for different classes of train and also waiting status. For this application, a visitor must register to avail the service. In this system, train records are maintained and retrieved. Administrator monitors all users and their transactions. Administrator has complete access to database and can add train or cancel train or add station for particular train or skip a station for train. There are several payment options for user like credit card, debit card and a user can also cancel ticket. This application also provides current position of train i.e. name of stations between which the train is currently running. It provides familiar and attractive interface with inserting and reporting capabilities.
- 4. 2 REQUIREMENTS: 2.1 Functional requirements 1. Secure registration and profile management facilities for Customers 2. Secured mechanism for Payment 3. Account management 2.2 Non-functional requirements 1. Performance 2. Quality 3. Secure access of confidential data (user’s details). 4. 24 X 7 availability 2.3 Technical requirements 1. Browser 2. Apache server 3. MySQL 4. PHP 5. javascript 6. HTML & CSS
- 5. 3 3.1 CLASS DIAGRAM: A class diagram is description of set of objects that share same attributes, operations, methods, relationships and semantics. In our project following classes are identified – 1. User This class consists of both registered user and visitor. A visitor must register to avail the service. 2. Admin This class consists of administrators to manage a system in different areas.
- 6. 4 3. Database This class is the major part of the system which contains all the information about trains, customers, administrators. 4. Train This class contains the data about trains i.e. Train id, train name, source, destination, position. 5. Ticket This class contains the data about tickets i.e. PNR, Status, no. of persons, date. MULTIPLICITY: 1. User - database This relationship is many to one since so many users can access the one railway database. 2. Train - user This relationship is one to many since many users can travel by a single train. 3. Admin – database This relationship is many to one since so many Administrators can handle single database. 4. User – ticket This relationship is one to many since one user can book many tickets. 5. Train – database This relationship is many to one since so many Administrators can handle single database.
- 7. 5 3.2 OBJECT DIAGRAM: Object diagram describes the static structure of the system at any instant. In our case a registered users “Ritesh” and “Rajendra” access the database to see the details of book ticket. Ritesh books a ticket from pune to mumbai by Sahyadri express. Rajendra books a ticket from Delhi to Mumbai by Rajdhani express. Pundlik is administrator with Admin_id = 1.
- 8. 6 3.3 USE CASE DIAGRAM: A use case describes an interaction with actors as a sequence of messages between the system and one or more actors. The term actor includes humans, as well as other computer systems and processes. The use case diagram is having following three actors 1. Visitor: - Visitor must register to use the service. 2. Registered user: - A registered user can Login, book ticket, cancel ticket, pay and inquire ticket. 3. Administrator: - Administrator maintains the database. Administrator can add train or station, remove train or station from database.
- 9. 7 3.4 ACTIVITY DIAGRAM: WITHOUT SWIM LANE
- 10. 8 3.4 ACTIVITY DIAGRAM: WITH SWIM LANE ACTIVITIES: 1. User login and authentication 2. Select train, book ticket and pay 3. Select ticket, cancel ticket and refund 4. Logout
- 12. 10 STATES : 1. Authentication and logged in 2. Train availability 3. Book ticket 4. Payment 5. Show ticket 6. History 7. Cancel ticket 8. Refund 9. Logout TRANSITIONS : 1. Authenticate - Logged in 2. Logged in – Enter train details – Train availability – Enter passenger details – Booking ticket – Enter payment info – Pay – Show ticket - Logout 3. Logged in – Check previous tickets – Cancel ticket – Refund - Logout
- 13. 11 3.6 SEQUENCE DIAGRAM: A sequence diagram shows a set of messages arranged in time sequence. Each classifier role is shown as a lifeline—that is, a vertical line that represents the role over time through the entire interaction. Messages are shown as arrows between lifelines. A sequence diagram can show a scenario that is, an individual history of a transaction. User logging in gets authenticated. On successful authentication, he/she can book ticket or cancel ticket. While booking the user will be shown a new ticket and pay accordingly. A message is displayed on successful payment. While canceling a ticket, user gets refund. This whole sequence has been captured by sequence diagram.
- 14. 12 3.7 COLLABORATION DIAGRAM: A collaboration is a description of a collection of objects that interact to implement some behavior within a context. It describes a society of cooperating objects assembled to carry out some purpose. A collaboration contains slots that are filled by objects and links at run time. A collaboration slot is called a role because it describes the purpose of an object or link within the collaboration. Given is the collaboration diagram. In which collaboration of user are shown, that include the entire process of user logging, booking the new ticket, canceling ticket.
- 15. 13 3.8 DEPLOYMENT DIAGRAM: Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities where the components are deployed. The deployment view represents the arrangement of runtime component instances on node instances. A node is a runtime resource, such as a computer, device, or memory. This view permits the consequences of distribution and resource allocation to be assessed. Deployment diagrams are used for visualizing deployment view of a system. This is generally used by the deployment team. So the deployment diagrams are used to describe the static view of system. When we are going to build a software intensive system, you have to consider both its logical and physical dimensions. On the logical side, you'll find things such as classes, interfaces, collaborations, interactions, and state machines. On the physical side, we'll find components and node which are used in the deployment diagram.
- 16. 14 3.9 PACKAGE DIAGRAM: Package diagram is UML structure diagram which shows packages and dependency between packages. This diagram shows different views of system. Basically package is a collection of classes and use cases. Packages contain top- level model elements, such as classes and their relationships, state machines, use case graphs, interactions, and collaborations anything not contained in some other element. Elements such as attributes, operations, states, lifelines, and messages are contained in other elements and do not appear as direct contents of packages.