You are on page 1of 23

CONTENTS:

Problem Statement Use case diagram Use case description Activity Diagrams Sequence Diagrams Class Diagram Collaboration Diagram

PROBLEM STATEMENT FOR RAILWAY RESERVATION SYSTEM


Software has to be developed for automating the manual reservation system of railway. The system should be standalone in nature. It should be designed to provide functionalities like booking of tickets in which a user should be able to applied for tickets of any train and of any class. A limitation is imposed when the number of tickets for which user apply is greater then available seats or no seats are available. If seats are not available then put user transaction in the waiting queue.If the tickets are available then it is issued to the user and it must be updated in the database concurrently. The system generates the receipt for the same. The software takes the current system date and time as the date of issue and calculates the amount to be paid by the user. It also provide the functionality of cancellation of tickets .If the user wants to cancel the tickets, he/she must enter the details. The system check the records from the database if it is matched with the user entered details, then it cancels the tickets. The system also calculates the amount to be return to the user after deductions. The system must update the database for the same. After that system must check for waiting passenger for that train, if any then these tickets are issued to waiting passenger and update the database. The system displays the details of train of which user enter the name. The information is saved and the corresponding updating take place in the database. In the enquiry, the system should be able to provide information like the availability of tickets of particular train, train schedule.

The system should be able to reserve a ticket for a particular user if the tickets are not currently available. The corresponding print outs for each entry (issue/cancel) in the system should be generated. There should be proper information if the waiting list ticket is confirmed, through mail or via sms. It should tell us as to which all stations it haults and current status of the train should be informed. Security provisions like the login authenticity should be provided. Each user should have a user id and a password. Record of the users of the system should be kept in the log file. Provision should be made for full backup of the system.

USE CASE DIAGRAM

Login

Enquiry Operator User

Booking

Cancellation

USE CASE DESCRIPTION


1.

LOGIN

1.1 INTRODUCTION This use case documents the procedure for logging into the Railway Reservation System based on user privileges. Operator (Login, Enquiry, Booking, Cancellation). User (Login, Enquiry, Booking, Cancellation). 1.2 ACTORS Operator, User 1.3 PRE-CONDITIONA None 1.4 POST-CONDITION If use case is successful, the user is logged into the system, otherwise the system state is unchanged. 1.5 FLOW OF EVENTS 1.5.1 BASIC FLOW This use case starts when actor wishes to log into the Railway Reservation System. 1. The system requests that the actor enters his/her user_id and password. 2. The actor enters user_id and password. 3. The system validates the user_id and password and checks for his/her privileges. 4. If the actor is operator, he/she will be logged into the system and presented with operators menu. 5. Otherwise, if the actor is User, he/she will be logged into the system and presented with users menu.

6. The use case ends.

1.5.2

ALTERNATE FLOW

1.5.2.1 INVALID NAME/PASSWORD If the system receives an invalid user_id or password, an error message is displayed and the use case ends. 1.6 SPECIAL REQUIREMENTS None 1.7 RELATED USE CASES None

2.

ENQUIRY

2.1 INTRODUCTION This use case documents the procedure of ENQUIRY for following accounts : 1. Enquiry regarding trains 2. Enquiry for reservation status. 2.2 ACTORS Operator, User. 2.3 PRE-CONDITION Operator must be logged in to the system 2.4 POST-CONDITION If use case is successful, the user can get information regarding trains,reservation Otherwise, the system state is unchanged. 2.5 FLOW OF EVENTS 2.5.1 BASIC FLOW The use case starts when a system can get the enquiry from the user. 1. The system checks the type of enquiry 2. The system submits the user query to controller of the system .

3. The controller search the information from the database. 4. The resultant information is presented infront of the user. 5. The use case ends. 2.5.2 ALTERNATE FLOWS

2.5.2.1 INVALID ENQUIRY If the user enter the wrong details ,then the system shows message according to the query and the use case ends. 2.6 SPECIAL REQUIREMENT None 2.7 RELATED USE CASES None.

3.

BOOKING

3.1 INTRODUCTION This use case documents the procedure of booking of tickets and update the database after each transaction . 3.2 ACTOR Operator, User 3.3 PRE-CONDITION Operator/User must be logged into the system

3.4 POST-CONDITION If the use case is successful, the ticket is issued to the passenger , otherwise the system state is unchanged. 3.5 FLOW OF EVENTS

3.5.1

BASIC FLOW 1.This use case starts when a user enter train name. 2.The system read the information and check the availability of the seats. 3.If the seats are available ,the system execute the transaction . 4.The resultant information is updated in the data base. 5. The issue details are sent to the printer to generate the tickets. 6. The use case ends.

3.5.2

ALTERNATE FLOW

3.5.2.1 NON -AVAILABILTY If the seats are not available the system sends the message accordingly ,and puts the user transaction in waiting state ,and according to the priority the seats are allotted to the users . The use case end here. 4. CANCELLATION 4.1 INTRODUCTION This use case documents the procedure for canceling of issued tickets according to the customer transaction. 4.2 ACTORS Operator, User. 4.3 PRE-CONDITION Operator/ user must be logged into the system. 4.4 POST-CONDITION If the use case is successful , the request or recommendation are fulfilled and database is updated accordingly. 4.5 FLOW OF EVENTS 4.5.1 BASIC FLOW This use case starts when a enters the details regarding canceling of tickets. 1. The system check the details regarding the query of the customer. 2. The system updates the train reservation status. 3. The system refunds the amount to the user after suitable deductions.

4. The system checks list of waiting passengers and allot the vacant seats. 5. The use case ends.

4.6 SPECIAL REQUIRMENTS None 4.7 RELATED USE CASES None

SEQUENCE DIAGRAM:
A sequence diagram shows interaction among objects as a two dimensional chart. The chart is read from top to bottom. The objects participating in the interaction are shown at the top of the chart as boxes attached to a vertical dashed line. Inside the box, the name of the object is written with a colon separating it from the name of the class, and both the name of the object and class are underlined. The objects appearing at the top signify that the object already existed when the use case execution was initiated. However, if some object is created during the execution of the use case and participates in the interaction (e.g. a method call), then the object should be shown at the appropriate place on the diagram where it is created. The vertical dashed line is called the objects lifeline

SEQUENCE DIAGRAM : BOOKING

Operator / User

Booking Form

Controller

Train_detail

Sorry message box

Passenger detail

Passenger Train Detail

Enter1: Train name 2: name Submit 3: Get Train Detail

4: Check availability of seats 5: Seat not available 6: Add Record 7: Update Details Update Details 8: 9: Booking Successfully

SEQUENCE DIAGRAM : CANCELLATION

Operator / User

Cancellation Form

Controller

Train Table

Passenger Train Detail Table

1: Enter Train Details

2: Submit Details

3: Check Details Cancel4: seat Update table 5:table Update

6: Cancellation successful

SEQUENCE DIAGRAM : ENQUIRY

User / Operator

Enquiry Form

Controller

Train_master

1: Enter Details 2:Details Submit Search 3:

4:Train Show Information

SEQUENCE DIAGRAM : LOGIN

Operator / User

Login Form

Controller

Login_Detail

1: id,password 2: details submit

3: Get Login details

4: 5: Error or Success Check Login

CLASS DIAGRAM :
A class diagram describes the static structure of a system. It shows how a system is structured rather than how it behaves. The static structure of a system comprises of a number of class diagrams and their dependencies. The main constituents of a class diagram are classes and their relationships: generalization, aggregation, association, and various kinds of dependencies. The classes represent entities with common features, i.e. attributes and operations. Classes are represented as solid outline rectangles with compartments. Classes have a mandatory name compartment where the name is written centered in boldface. The class name is usually written using mixed case convention and begins with an uppercase. The class names are usually chosen to be singular nouns.

Login_Detail Username Password Add() Delete() Update() Train_Details Date Time Train Name Available seats(I/II) Add() Delete() Update() GetDetails()

Train_Master Train id Train Name Capacity(I/II) Source Destination Time Days Add() Delete() Update() GetDetails() Passenger_Train_Detail Train Name Seat no. Class(I/II) date Time Add() Delete() Update() GetDetails()

Passenger_Details Passenger Name Address Age Phone no. Train Name

COLLABRATION DIAGRAM: A collaboration diagram shows both structural and behavioural aspects explicitly. This is unlike a sequence diagram which shows only the behavioural aspects. The structural aspect of a collaboration diagram consists of objects and the links existing between them. In this diagram, an object is also called a collaborator. The behavioural aspect is described by the set of messages exchanged among the different collaborators. The link between objects is shown as a solid line and can be used to send messages between two objects. The message is shown as a labeled arrow placed near the link. Messages are prefixed with sequence numbers because they are the only way to describe the relative sequencing of the messages in this diagram

COLLABORATION DIAGRAM : LOGIN


1: Operator / User Login Form

5: 4: 2: 3: Controller Login_Det ail

COLLABORATION DIAGRAM : ENQUIRY


1: Operator /user Enquiry form

2:

4: 3:

Controlle -r

Train Master

COLLABORATION DIAGRAM: BOOKING

4:

1: Operator /User Booking form

2: Controll-er 9: 7

3: Train Detail

8 5: 6:

Sorry Message box

Passenger Detail

Passenger Train Detail

7: 8: 7

STATE DIAGRAM A state chart diagram is normally used to model how the state of an object changes in its lifetime. State chat diagrams are good at describing how the behaviour of an object changes across several use case executions. However, if we are interested in modelling some behaviour that involves several objects collaborating with each other, state chart diagram is not appropriate. State chart diagrams are based on the finite state machine (FSM) formalism. An FSM consists of a finite number of states corresponding to those of the object being modelled. The object undergoes state changes when specific events occur. The FSM formalism existed long before the object-oriented technology and has been used for a wide variety of applications. Apart from modelling, it has even been used in theoretical computer science as a generator for regular languages.

ACTIVITY DIAGRAM The activity diagram is possibly one modelling element which was not present in any of the predecessors of UML. No such diagrams were present either in the works of Booch, Jacobson, or Rumbaugh. It is possibly based on the event diagram of Odell [1992] though the notation is very different from that used by Odell. The activity diagram focuses on representing activities or chunks of processing which may or may not correspond to the methods of classes. An activity is a state with an internal action and one or more outgoing transitions which automatically follow the termination of the internal activity. If an activity has more than one outgoing transition, then these must be identified through conditions. An interesting feature of the activity diagrams is the swim lanes. Swim lanes enable you to group activities based on who is performing them, e.g. academic department vs. hostel office. Thus swim lanes subdivide activities based on the responsibilities of some components. The activities in a swim lane can be assigned to some model elements, e.g. classes or some component, etc.

You might also like