Bus+Reservation(Final)

A Unified Modeling Language Documentation for Bus Reservation System

Table of Contents

4.UML DIAGRAMS FOR BUS RESERVATION SYSTEM...................................................................................6

1. INTRODUCTION 1.1A Brief Introduction to UML The Unified Modeling Language (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as other non software systems. UML simplifies the complex process of software design, making a "blueprint" for construction, and is now the standard notation for software architecture. UML provides both the structural views and behavioral views of the system. A set of diagrams with different graphical elements is the core part as well as the most expressive presentation in UML. The UML includes nine kinds of diagrams, for the sake of grasp the most representative aspects of the design of elevator system, in this paper only following UML diagrams are used and analyzed: Use Case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Use case diagrams address the static use case view of a system, these diagrams are important in organizing and modeling the behaviors of a system. Class diagram shows a set of classes, interfaces, and collaborations and their relationships. Class diagrams are the most common diagrams used in modeling object-oriented systems. Class diagrams address the static design view of a system. Sequence diagram is an interaction diagram. Interaction diagrams address the dynamic view of a system, besides sequence diagram, the other interaction diagram in UML is the Collaboration diagram. Sequence diagram emphasizes the time ordering of messages between objects in the system, while collaboration diagram emphasizes the structural organization of the objects that send and receive messages. Sequence diagrams and collaboration diagrams are isomorphic, and can be transformed from one into the other. Since either of them contributes to the same extend of understanding of our system, while sequence diagrams give more ideas of time, which is essential for real time systems, only the sequence diagrams are given in this report. State chart diagram shows a state machine, consisting of states, transitions, events and activities. State chart diagrams address the dynamic view of a system. State chart diagrams are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems.

The rest four kinds of UML diagrams are: Object diagram, showing a set of objects and their relationships; Activity diagram, a special kind of State chart diagram showing the flow from activity to activity within a system; Component diagram, showing the organizations and dependencies among a set of components; and Deployment diagram showing the configuration of run-time processing nodes and the components that live on them.

2. SCOPE 1. Audience : Customers, Administrators. 2.

Organization : ONLINE BUS RESERVATION SYSTEM

3. SOFTWARE SPECIFICATION REQUIREMENTS The Online Bus Reservation system facilitates the user to view the bus schedules, enquire about the bus details, availability of seats and many more. The major functionality of system is to allow the user to book and cancel the bus tickets as per user requirements. Major features provided by the system are: Bus Enquiry The system allows the user or member to perform bus enquiry including bus scheduling, seats availability status, fare details, etc. User Registration It allows the user to register in order to be a member of the system. User is then granted privileges to book or cancel tickets. Bus Ticket Reservation

The system allows the member to book the tickets as per his/her requirements. The member is prompt to enter the passenger details. The member then receives the unique PNR No. Bus Ticket Cancellation The functionality is used by the member to cancel an existing reservation made by the member earlier.

3.1 Functional Model

Fig 3.1 Context Level Diagram for Bus Reservation System

Fig 3.2 Level 1 DFD Diagram for Bus Reservation System

Fig 3.3 Level 2 DFD Diagram for Bus Reservation System

4. UML Diagrams for BUS RESERVATION SYSTEM 1. Use case diagram The Use Case diagram models the user’s expectation for using the system. The people and systems that interact with the system are called the actors. The features of the system that the actors use are called the use cases. Some use cases interact with other use cases. Use case is a way to capture system functionality and requirement in UML. The use case diagrams consists of named pieces of functionality(Use cases), the persons or the things invoking the functionality(Actors) and possibly the elements responsible for implementing the use cases(Subjects). The goal of the use case is to identify all the features that the users of the system expects the system to support, but it does not reveal any details about the implementations of these features. Use case diagrams depict: •

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 your system. Actors are drawn as stick figures. Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. System boundary boxes (optional). We can draw a rectangle around the use cases, called the system boundary box, to indicate the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not. Packages (optional). Packages are UML constructs that enable you to organize model elements (such as use cases) into groups. Packages are depicted as file folders and can be used on any of the UML diagrams, including both use case diagrams and class diagrams.

Use case diagrams are valuable because: • • • •

They identify the user’s expectation of the system. They identify the specific features of the system. Identify shared behavior among system features. Provide a simple and easy way to visualize the requirements.

4.1 Use Case Diagram

Login Validation

Check Availability

Booking Pass details

Passenger Seat Selection

Window

verification()

Non Window Payment Cheque

Credit card Cancellation





Payment Deduction

Cancel receipt generated

4.2 Use Case Description Actors: 1. Passenger Use cases: 1. Login 2. Check Availability 3. Booking Pass details 4. Seat Selection 5. Window 6. Non Window 7. Payment 8. Cheque 9. Credit card 10. Cancellation 11. Cancel Receipt Generated 12. Payment Deduction 13. Validation Description: 1. Login: It allows the existing user to login. 2. Check Availability: It verifies the user login against the password. 3. Booking Pass details: It allows the user to enter the passenger details. 4. Seat Selection: It allows the user to select the passenger seat. 5. Window: It allows the user to select the window seat. 6. Non Window: It allows the user to select the non window seat. 7. Payment: It allows the user to make the payment according to the selected mode. 8. Cheque: It allows the user to make the payment. 9. Credit card: It allows the user to make the payment by credit card. 10. Cancellation: It allows the user to make cancellation. 11. Cancel Receipt Generated: It allows the user to cancel the receipt generated according to the cancellations made.

12. Payment Deduction: Calculates the refundable amount and the amount to be deducted. 13. Validation: Allows updation to be done. 4.3 Use case Table: Use case ID Use case name Actor Pre-condition Post-condition Flow of events

1 Seat selection Online Passenger Login into the system select seat

Use case ID Use case name Actor Pre-condition Post-condition Flow of events

2 Window Seat Online Passenger Seat selection select window seat

Use case ID Use case name Actor Pre-condition Post-condition Flow of events

3 Non Window Seat Online Passenger Seat selection Select non window seat

Use case ID Use case name Actor Pre-condition Post-condition Flow of events

4 Select credit card Online Passenger Purchase ticket Add credit card details

Use case ID

5

Use case name Actor Pre-condition Post-condition Flow of events

Select Cheque Online Passenger Purchase ticket

Use case ID Use case name Actor Pre-condition Post-condition Flow of events

6 Select Cancellation

Use case ID Use case name Actor Pre-condition Post-condition Flow of events

7 Booking pass details Online Passenger Enter details of passenger Details stored

Enter details Payment deduction and cancel receipt generated

5. ACTIVITY DIAGRAM Activity diagram models the logic from workflow to use cases to methods. It borrows most of the notations from the flowchart but has added the concept of concurrency to support many modern applications. The arrow traces the flow from beginning to end through decision and loops, while identifying each logic steps in the process. Activity modeling focuses on the execution and flow of the system, rather than how it is implemented. They are applicable to any type of behavioral modeling. Activity diagrams captures activities that are made up of smaller actions. When used for software modeling activities typically represents a behavior invoked as a result of a method call. Activity diagrams are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. Although UML activity diagrams could potentially model the internal logic of a complex operation it would be far better to simply rewrite the operation so that it is simple enough that

you don’t require an activity diagram. In many ways UML activity diagrams are the objectoriented equivalent of flow charts and data flow diagrams (DFDs) from structured development. The easiest way to visualize an Activity diagram is to think of a flowchart of a code. The flowchart is used to depict the business logic flow and the events that cause decisions and actions in the code to take place. Activity diagrams represent the business and operational workflows of a system. An Activity diagram is a dynamic diagram that shows the activity and the event that causes the object to be in the particular state. So, what is the importance of an Activity diagram, as opposed to a State diagram? A State diagram shows the different states an object is in during the lifecycle of its existence in the system, and the transitions in the states of the objects. These transitions depict the activities causing these transitions, shown by arrows. An Activity diagram talks more about these transitions and activities causing the changes in the object states. 5.1 Activity Diagram

Ticket Enquiry

Registered Passenger? No

Register

Yes Login Details

Get Pass_Id

Book Tickets? Yes No

Fill Booking Form

Yes

Tickets Available

Seat Selection

Make Payment

No

Cancellation

Reciept Generation No

Yes Fill Cancellation Form Valid No

Cannot Cancel

Yes Cancel Ticket

Update Database

Generate Reciept

Logout

6. UML INTERACTION DIAGRAM (Sequence And Collaboration Diagram)

Interaction Diagrams Interaction diagrams describe the communication between objects to accomplish some task such as placing an order. In UML the two types of interaction diagrams are sequence diagram and collaboration diagram. These diagrams model the dynamic aspects of the system. Sequence Diagrams Sequence diagram is one kind of interaction diagrams, which shows an interaction among a set of objects and their relationships. The purpose of the Sequence diagram is to document the sequence of messages among objects in a time based view. The scope of a typical sequence diagram includes all the message interactions for a single use case. The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. Much like the class diagram, developers typically think sequence diagrams were meant exclusively for them. However, an organization's business staff can find sequence diagrams useful to communicate how the business currently works by showing how various business objects interact. Besides documenting an organization's current affairs, a business-level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation. During the requirements phase of a project, analysts can take use cases to the next level by providing a more formal level of refinement. When that occurs, use cases are often refined into one or more sequence diagrams. Sequence Diagrams are valuable because: They have a narrow focus that helps us to see the specific questions, commands and data communicated during the execution of a specific task. They explicitly identify the communication required to fulfill an interaction. They help us to identify the interfaces required by the classes. They identify the objects that take part in the interaction. They help us to validate the features of a class. They identify the data passed as part of the interaction.

6.1 UML Interaction Diagram (Sequence Diagram)

: System

: Passenger

Database

Enquiry Details GetDetails Return Status

Availability Details

Fig 6.1.1 Sequence Diagram to check Availability

System

: Passenger

Database

Login Details Username & Password

Retrieve Member Details

Provide Access

Fig 6.1.2 Sequence Diagram for Login

System

: Passenger

Database

New User Request Registration Form

Submit Registration Form Verifying Registration Details

Succesful Update Successful Registration

Fig 6.1.3 Sequence Diagram for Reservation

System

: Passenger

Database

New User Request Registration Form

Submit Registration Form Verifying Registration Details

Succesful Update Successful Registration

Fig 6.1.4 Sequence Diagram for Passenger Registration

System

: Passenger

Database

: Payment

PNR no Retrieve Details Return Details Reservation Details Request For Cancellation Release Tickets Payment Deduction Update Succesful Cancellation Reciept Generated Cancellation Reciept Provided

Fig 6.1.5 Sequence Diagram for Cancellation 6.2 Collaboration Diagrams Collaboration diagram is very similar to a Sequence diagram in the purpose it achieves; in other words, it shows the dynamic interaction of the objects in a system. A distinguishing feature of a Collaboration diagram is that it shows the objects and their association with other objects in the system apart from how they interact with each other. The association between objects is not represented in a Sequence diagram. A Collaboration diagram is easily represented by modeling objects in a system and representing the associations between the objects as links. The interaction between the objects is denoted by arrows. To identify the sequence of invocation of these objects, a number is placed next to each of these arrows.

Collaboration diagrams are valuable because: • • •

Shows the structural requirement for completing a task. They identify the objects that participate in an interaction. Shows the interface requirement for a particular class. Identify the data that is passed as a part of the interaction.

Elements of a Collaboration diagram

A Collaboration diagram consists of the following elements:

Element and its description Object: The objects interacting with each other in the system. Depicted by a rectangle with the name of the object in it, preceded by a colon and underlined. Relation/Association: A link connecting the associated objects. Qualifiers can be placed on either end of the association to depict cardinality. Messages: An arrow pointing from the commencing object to the destination object shows the interaction between the objects. The number represents the order/sequence of this interaction.

Symbol

UML Interaction Diagram (Collaboration Diagram) 1: Enquiry Details : System 4: Availability Details

: Passenger

2: GetDetails 3: Return Status

Database

Fig 6.2.1 Collaboration Diagram to check Availability 2: Username & Password 1: Login Details

Database : System

System : System

3: Retrieve Member Details

4: Provide Access : Passenger

Fig 6.2.2 Collaboration Diagram for Login : System 1: Enter Booking Details 7: Enter Reservation Details 9: Make Payment

3: Check Amount 10: Update Payment

5: Payment Details 13: Payment Reciept Generated 6: Provide Booking Form 8: Request For Payment 14: Payment reciept 15: PNR Details 2: Provide Reservation Details 11: Update Database : Passenger 4: Availability Status 12: PNR Generated

Database : Booking

Fig 6.2.3 Collaboration Diagram for Reservation

Payment : Payment

1: PNR no 5: Request For Cancellation

System 7: Payment Deduction

4: Reservation Details 10: Cancellation Reciept Provided : Passenger

9: Cancellation Reciept Generated : Payment

3: Return Details 8: Update Succesful

2: Retrieve Details 6: Release Tickets

Database

Fig 6.2.4 Collaboration Diagram for Cancellation

1: New User Request 3: Submit Registration Form System

: Passenger

2: Registration Form 6: Successful Registration

4: Verifying Registration Details

5: Succesful Update

Database : Passenger

Fig 6.2.5 Collaboration Diagram for Passenger Registration

7. STATE TRANSITION DIAGRAM The state transition diagram represents a single object. It shows how external factors cause changes in the object over its lifetime. It captures the behavior of a software system. They provide an excellent way of modeling communications that occurs with external entities via a protocol or event. State diagrams are used to give an abstract description of the behavior of a system. This behavior is analyzed and represented in series of events that could occur in one or more possible states. Hereby "each diagram usually represents objects of a single class and tracks the different states of its objects through the system". The following are the basic notational elements that can be used to make up a diagram: Filled circle, pointing to the initial state Hollow circle containing a smaller filled circle, indicating the final state (if any) Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state. Can contain a horizontal line in the middle, below which the activities that are done in that state are indicated Arrow, denoting transition. Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines leaving. These denote join/fork, respectively. State Transition diagrams are valuable because: Identify the specific responses of an object to everything that can happen to the object. Identifies what events an object will and will not respond. Validate the data needed to define the state of the object and the attributes affected by the change. Helps in finding the internal effects of behavior that can not be seen using interaction based diagrams.

7.1 State Chart Diagram Enquiry()

Enquiry

PassReg( name,add,telno,dob )

Registration

Login

PNRGen( passid,booking_details )

Booking

PayRecieptGen( pnr )

Payment

Fig 7.1 State Chart Diagram for Ticket Reservation

8. CLASS DIAGRAM Class diagram, one of the most commonly used diagrams in object-oriented system, models the static design view for a system. The static view mainly supports the functional requirements of a system – the services the system should provide to the end users. We will see from our practical experience that lots of fun comes out when modeling out system with class diagrams. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Class diagrams involve global system description, such as the system architecture, and detail aspects such as the attributes and operations within a class as well. The most common contents of a class diagram are: Classes Interfaces Collaborations Dependency, generalization, and association relationships Notes and constraints

The class diagram models the definition of resources of the system. The class diagram is the source for code generation and the target for reverse engineering. 8.1 CLASS DIAGRAM

Booking PNRNo : Integer Pass_Id : Integer No_tickets : Integer Seat_No : Integer Destination : String Book_date : Date Journey_date : Date Amount : Double

System

1

1

1 login() 1 1

PNRGen()

*

Payment Pass_Id : Integer Amount : Integer Paymode : String Credit_No : Integer Cheque_No : Integer Pay_date : Date PayReceiptGen()

1

1

1

1

Passenger Pass_Id : Integer Pass_name : String Pass_add : Variant Pass_tel : Integer Pass_birth : Date Enquiry() PassReg() PassIdGen()

Fig 8.1 Class Diagram for Bus Reservation System

1

Cancellation PNRNo : Integer Pass_Id : Integer No_tickets : Integer Seat_no : Integer Cancel_date : Date Amount : Double TicketCancel() PayDeduct() CancelRecGen()

*

9. COMPONENT DIAGRAM The component diagram represents pieces of software in the implementation environment. It models the implementation view of the software. We can use component to represent source code, XML or any piece of software. When using large software system it is common to break the software in to manageable subsystems. In UML component classifier represents this. A component is a replaceable, executable piece of larger system whose implementation details are hidden. The functionality provided by a component is specified by a set of provided interfaces that the component realizes. In addition to providing interfaces, a component may require interfaces in order to perform. These are called required interfaces. Components are designed to be reused. Component diagram are valuable because they: Model the real software in the implementation environment. They bring forward configuration issues through the dependency relationships. They provide an accurate picture of existing systems prior to making changes or enhancements. 9.1 Component Diagram :Data base server contains all the database tables.

WEB BROWSER

BUS RESERVATION SYSTEM

MYSQL

Fig 9.1 Component Diagram for Bus Reservation System

10.DEPLOYMENT DIAGRAM The deployment diagram models the hardware of the implementing environment. Each node on a deployment diagram typically represents the type of hardware such as disk drive, a client PC, a server or a processor. A node may also represent a human being or organizational unit. Nodes are like classes. They represent a type of device, not a specific device, and the features of each device. Like classes they are related using association that explains how the nodes may be connected. Deployment diagrams models the mapping of software pieces of a system to the hardware that is going to execute it. Software elements are typically manifested using artifacts and are mapped to the hardware called nodes. Deployment diagrams are valuable because: • • •

They model the hardware platform for a system. Identify hardware capabilities that affects performance planning and software configuration.

10.1Deployment Diagram WEB SERVER

CLIENT COMPUTER TCP/IP

DATABASE SERVER

TCP/IP

Fig 10.1 Deployment Diagram for Bus Reservation System