A REPORT ON ONLINE BUS RESERVATION SYSTEM

Table of Contents

3.UML DIAGRAMS FOR BUS RESERVATION SYSTEM...................................................................................

!. INTRODUCTION
!.!A B"#ef Int"o$%&t#on 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 comple process of software design, ma!ing a "#lueprint" for construction, and is now the standard notation for software architecture. UML provides #oth the structural views and #ehavioral views of the system. $ set of diagrams with different graphical elements is the core part as well as the most e pressive presentation in UML. The UML includes nine !inds of diagrams, for the sa!e 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 $#a'"a( shows a set of use cases and actors (a special !ind 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 #ehaviors of a system. Class $#a'"a( shows a set of classes, interfaces, and colla#orations and their relationships. &lass diagrams are the most common diagrams used in modeling o#'ect-oriented systems. &lass diagrams address the static design view of a system. Se)%en&e $#a'"a( is an interaction diagram. (nteraction diagrams address the dynamic view of a system, #esides se)uence diagram, the other interaction diagram in UML is the Collabo"at#on $#a'"a(. *e)uence diagram emphasizes the time ordering of messages #etween o#'ects in the system, while colla#oration diagram emphasizes the structural organization of the o#'ects that send and receive messages. *e)uence diagrams and colla#oration diagrams are isomorphic, and can #e transformed from one into the other. *ince either of them contri#utes to the same e tend of understanding of our system, while se)uence diagrams give more ideas of time, which is essential for real time systems, only the se)uence diagrams are given in this report. State &*a"t $#a'"a( shows a state machine, consisting of states, transitions, events and activities. *tate chart diagrams address the dynamic view of a system. *tate chart diagrams are especially important in modeling the #ehavior of an interface, class, or colla#oration and

emphasize the event-ordered #ehavior of an o#'ect, which is especially useful in modeling reactive systems. The rest four !inds of UML diagrams are% Ob+e&t $#a'"a(, showing a set of o#'ects and their relationships+ A&t#,#t- $#a'"a(, a special !ind of *tate chart diagram showing the flow from activity to activity within a system+ Co(.onent $#a'"a(/ showing the organizations and dependencies among a set of components+ and De.lo-(ent $#a'"a( showing the configuration of run-time processing nodes and the components that live on them.

0. SOFT1ARE SPECIFICATION RE2UIREMENTS

The ,nline -us .eservation system facilitates the user to view the #us schedules, en)uire a#out the #us details, availa#ility of seats and many more. The ma'or functionality of system is to allow the user to #oo! and cancel the #us tic!ets as per user re)uirements. Ma'or features provided #y the system are% B%s En)%#"The system allows the user or mem#er to perform #us en)uiry including #us scheduling, seats availa#ility status, fare details, etc. Use" Re'#st"at#on (t allows the user to register in order to #e a mem#er of the system. User is then granted privileges to #oo! or cancel tic!ets. B%s T#&3et Rese",at#on The system allows the mem#er to #oo! the tic!ets as per his/her re)uirements. The mem#er is prompt to enter the passenger details. The mem#er then receives the uni)ue 01. 1o. B%s T#&3et Can&ellat#on

The functionality is used #y the mem#er to cancel an e isting reservation made #y the mem#er earlier.

0.! F%n&t#onal Mo$el

&onte t Level 2iagram for -us .eservation *ystem

Level 3 242 2iagram for -us .eservation *ystem

Level 5 242 2iagram for -us .eservation *ystem

3. UML D#a'"a(s fo" BUS RESERVATION SYSTEM

!. 3.! Use &ase $#a'"a( The Use &ase diagram models the user6s e pectation 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. *ome use cases interact with other use cases. Use case is a way to capture system functionality and re)uirement in UML. The use case diagrams consists of named pieces of functionality(Use cases), the persons or the things invo!ing the functionality($ctors) and possi#ly the elements responsi#le for implementing the use cases(*u#'ects). The goal of the use case is to identify all the features that the users of the system e pects the system to support, #ut it does not reveal any details a#out the implementations of these features. Use &ase $#a'"a(s $e.#&t%

Use &ases. $ use case descri#es a se)uence of actions that provide something of measura#le value to an actor and is drawn as a horizontal ellipse.

A&to"s. $n actor is a person, organization, or e ternal system that plays a role in one or more interactions with your system. $ctors are drawn as stic! figures. Asso&#at#ons. $ssociations #etween actors and use cases are indicated in use case diagrams #y solid lines. $n association e ists whenever an actor is involved with an interaction descri#ed #y a use case. $ssociations 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. S-ste( bo%n$a"- bo4es 5o.t#onal6. 7e can draw a rectangle around the use cases, called the system #oundary #o , to indicate the scope of your system. $nything within the #o represents functionality that is in scope and anything outside the #o is not. Pa&3a'es 5o.t#onal6. 0ac!ages are UML constructs that ena#le you to organize model elements (such as use cases) into groups. 0ac!ages are depicted as file folders and can #e used on any of the UML diagrams, including #oth use case diagrams and class diagrams.

Use &ase $#a'"a(s a"e ,al%able be&a%se7 They identify the user6s e pectation of the system. They identify the specific features of the system. (dentify shared #ehavior among system features. 0rovide a simple and easy way to visualize the re)uirements.

Use Case D#a'"a(

<<uses>> Login &alidation

Check Availability

Booking Pass details

<<extend>> Passenger eat veri!ication"# election <<extend>> $indo%

'on $indo% <<extend>> Payment <<extend>> Cheque

Credit card Cancellation <<include>>

<<include>>

Payment Deduction

Cancel receipt generated

3.!.! Use Case Des&"#.t#on A&to"s7 3. 0assenger Use &ases7 3. Login 5. &hec! $vaila#ility 8. -oo!ing 0ass details 9. *eat *election :. 7indow ;. 1on 7indow <. 0ayment =. &he)ue >. &redit card 3?. &ancellation 33. &ancel .eceipt @enerated 35. 0ayment 2eduction 38. Aalidation Des&"#.t#on7 3. Lo'#n7 (t allows the e isting user to login. 5. C*e&3 A,a#lab#l#t-7 (t verifies the user login against the password. 8. Boo3#n' Pass $eta#ls7 (t allows the user to enter the passenger details. 9. Seat Sele&t#on7 (t allows the user to select the passenger seat. :. 1#n$o87 (t allows the user to select the window seat. ;. Non 1#n$o87 (t allows the user to select the non window seat. <. Pa-(ent7 (t allows the user to ma!e the payment according to the selected mode. =. C*e)%e7 (t allows the user to ma!e the payment. >. C"e$#t &a"$7 (t allows the user to ma!e the payment #y credit card. 3?. Can&ellat#on7 (t allows the user to ma!e cancellation. 33. Can&el Re&e#.t Gene"ate$7 (t allows the user to cancel the receipt generated according to the cancellations made.

35. Pa-(ent De$%&t#on7 &alculates the refunda#le amount and the amount to #e deducted. 38. Val#$at#on7 $llows updation to #e done. 3.!.0 Use &ase Table7 Use case (2 Use case name $ctor 0re-condition 0ost-condition 4low of events Use case (2 Use case name $ctor 0re-condition 0ost-condition 4low of events Use case (2 Use case name $ctor 0re-condition 0ost-condition 4low of events 3 *eat selection ,nline 0assenger Login into the system select seat 5 7indow *eat ,nline 0assenger *eat selection select window seat 8 1on 7indow *eat ,nline 0assenger *eat selection *elect non window seat

Use case (2 Use case name $ctor 0re-condition 0ost-condition 4low of events Use case (2

9 *elect credit card ,nline 0assenger 0urchase tic!et $dd credit card details

Use case name $ctor 0re-condition 0ost-condition 4low of events Use case (2 Use case name $ctor 0re-condition 0ost-condition 4low of events Use case (2 Use case name $ctor 0re-condition 0ost-condition 4low of events

*elect &he)ue ,nline 0assenger 0urchase tic!et

; *elect &ancellation Bnter details 0ayment deduction and cancel receipt generated

< -oo!ing pass details ,nline 0assenger Bnter details of passenger 2etails stored

3.0 ACTIVITY DIAGRAM

$ctivity diagram models the logic from wor!flow to use cases to methods. (t #orrows most of the notations from the flowchart #ut has added the concept of concurrency to support many modern applications. The arrow traces the flow from #eginning to end through decision and loops, while identifying each logic steps in the process. $ctivity modeling focuses on the e ecution and flow of the system, rather than how it is implemented. They are applica#le to any type of #ehavioral modeling. $ctivity diagrams captures activities that are made up of smaller actions. 7hen used for software modeling activities typically represents a #ehavior invo!ed as a result of a method call. $ctivity diagrams are typically used for #usiness process modeling, for modeling the logic captured #y a single use case or usage scenario, or for modeling the detailed logic of a #usiness rule. $lthough UML activity diagrams could potentially model the internal logic of a comple operation it would #e far #etter to simply rewrite the operation so that it is simple enough that

you don6t re)uire an activity diagram. (n many ways UML activity diagrams are the o#'ectoriented e)uivalent of flow charts and data flow diagrams (242s) from structured development. The easiest way to visualize an $ctivity diagram is to thin! of a flowchart of a code. The flowchart is used to depict the #usiness logic flow and the events that cause decisions and actions in the code to ta!e place. $ctivity diagrams represent the #usiness and operational wor!flows of a system. $n $ctivity diagram is a dynamic diagram that shows the activity and the event that causes the o#'ect to #e in the particular state. *o, what is the importance of an $ctivity diagram, as opposed to a *tate diagramC $ *tate diagram shows the different states an o#'ect is in during the lifecycle of its e istence in the system, and the transitions in the states of the o#'ects. These transitions depict the activities causing these transitions, shown #y arrows. $n $ctivity diagram tal!s more a#out these transitions and activities causing the changes in the o#'ect states. 3.0.! A&t#,#t- D#a'"a(

(icket )nquiry

*egistered Passenger+ 'o ,es Login Details Book (ickets+ ,es 'o Cancellation 0ill Booking 0orm (ickets Available ,es eat election 1ake Payment -et Pass./d *egister

'o *eciept -eneration 'o

,es 0ill Cancellation 0orm &alid 'o ,es Cancel (icket Cannot Cancel

2pdate Database

-enerate *eciept

Logout

9 UML INTERACTION DIAGRAM 5Se)%en&e An$ Collabo"at#on D#a'"a(6

Inte"a&t#on D#a'"a(s (nteraction diagrams descri#e the communication #etween o#'ects to accomplish some tas! such as placing an order. (n UML the two types of interaction diagrams are se)uence diagram and colla#oration diagram. These diagrams model the dynamic aspects of the system. 9.! Se)%en&e D#a'"a(s *e)uence diagram is one !ind of interaction diagrams, which shows an interaction among a set of o#'ects and their relationships. The purpose of the *e)uence diagram is to document the se)uence of messages among o#'ects in a time #ased view. The scope of a typical se)uence diagram includes all the message interactions for a single use case. The se)uence diagram is used primarily to show the interactions #etween o#'ects in the se)uential order that those interactions occur. Much li!e the class diagram, developers typically thin! se)uence diagrams were meant e clusively for them. Dowever, an organizationEs #usiness staff can find se)uence diagrams useful to communicate how the #usiness currently wor!s #y showing how various #usiness o#'ects interact. -esides documenting an organizationEs current affairs, a #usiness-level se)uence diagram can #e used as a re)uirements document to communicate re)uirements for a future system implementation. 2uring the re)uirements phase of a pro'ect, analysts can ta!e use cases to the ne t level #y providing a more formal level of refinement. 7hen that occurs, use cases are often refined into one or more se)uence diagrams. Se)%en&e D#a'"a(s a"e ,al%able be&a%se7 They have a narrow focus that helps us to see the specific )uestions, commands and data communicated during the e ecution of a specific tas!. They e plicitly identify the communication re)uired to fulfill an interaction. They help us to identify the interfaces re)uired #y the classes. They identify the o#'ects that ta!e part in the interaction. They help us to validate the features of a class. They identify the data passed as part of the interaction.

UML Inte"a&t#on D#a'"a( 5Se)%en&e D#a'"a(6

3 Passenger )nquiry Details

ystem

Database

-etDetails *eturn tatus

Availability Details

9.3.3 *e)uence 2iagram to chec! $vaila#ility

3 Passenger

ystem

Database

Login Details 2sername 4 Pass%ord

*etrieve 1ember Details

Provide Access

9.3.5 *e)uence 2iagram for Login

3 Passenger 'e% 2ser *equest *egistration 0orm

ystem

Database

ubmit *egistration 0orm &eri!ying *egistration Details

ucces!ul 2pdate uccess!ul *egistration

9.3.8 *e)uence 2iagram for .eservation

3 Passenger 'e% 2ser *equest *egistration 0orm

ystem

Database

ubmit *egistration 0orm &eri!ying *egistration Details

ucces!ul 2pdate uccess!ul *egistration

9.3.9 *e)uence 2iagram for 0assenger .egistration

3 Passenger P'* no

ystem

Database

3 Payment

*etrieve Details *eturn Details *eservation Details *equest 0or Cancellation *elease (ickets Payment Deduction 2pdate ucces!ul Cancellation *eciept -enerated Cancellation *eciept Provided

9.3.: *e)uence 2iagram for &ancellation 9.0 Collabo"at#on D#a'"a(s &olla#oration diagram is very similar to a *e)uence diagram in the purpose it achieves+ in other words, it shows the dynamic interaction of the o#'ects in a system. $ distinguishing feature of a &olla#oration diagram is that it shows the o#'ects and their association with other o#'ects in the system apart from how they interact with each other. The association #etween o#'ects is not represented in a *e)uence diagram. $ &olla#oration diagram is easily represented #y modeling o#'ects in a system and representing the associations #etween the o#'ects as lin!s. The interaction #etween the o#'ects is denoted #y arrows. To identify the se)uence of invocation of these o#'ects, a num#er is placed ne t to each of these arrows.

&olla#oration diagrams are valua#le #ecause% *hows the structural re)uirement for completing a tas!. They identify the o#'ects that participate in an interaction. *hows the interface re)uirement for a particular class. (dentify the data that is passed as a part of the interaction.

Ele(ents of a Collabo"at#on $#a'"a(

$ &olla#oration diagram consists of the following elements%

Blement and its description ,#'ect% The o#'ects interacting with each other in the system. 2epicted #y a rectangle with the name of the o#'ect in it, preceded #y a colon and underlined. .elation/$ssociation% $ lin! connecting the associated o#'ects. Fualifiers can #e placed on either end of the association to depict cardinality. Messages% $n arrow pointing from the commencing o#'ect to the destination o#'ect shows the interaction #etween the o#'ects. The num#er represents the order/se)uence of this interaction.

*ym#ol

UML Inte"a&t#on D#a'"a( 5Collabo"at#on D#a'"a(6

53 )nquiry Details 3 63 Availability Details 73 -etDetails 83 *eturn tatus ystem

3 Passenger

Database

9.5.3 &olla#oration 2iagram to chec! $vaila#ility

5% Username G 0assword 3% Login 2etails 2ata#ase % *ystem

*ystem % *ystem
9% 0rovide $ccess % 0assenger 8% .etrieve Mem#er 2etails

9.5.5 &olla#oration 2iagram for Login

3 ystem 53 )nter Booking Details 93 )nter *eservation Details :3 1ake Payment 83 Check Amount 5>3 2pdate Payment

=3 Payment Details 583 Payment *eciept -enerated ;3 Provide Booking 0orm <3 *equest 0or Payment 563 Payment reciept 5=3 P'* Details 73 Provide *eservation Details 553 2pdate Database 3 Passenger 63 Availability tatus 573 P'* -enerated Payment 3 Payment

Database 3 Booking

9.5.8 &olla#oration 2iagram for .eservation

53 P'* no =3 *equest 0or Cancellation

ystem 93 Payment Deduction

63 *eservation Details 5>3 Cancellation *eciept Provided 3 Passenger 83 *eturn Details <3 2pdate ucces!ul :3 Cancellation *eciept -enerated 3 Payment

73 *etrieve Details ;3 *elease (ickets

Database

9.5.9 &olla#oration 2iagram for &ancellation

53 'e% 2ser *equest 83 ubmit *egistration 0orm ystem 73 *egistration 0orm ;3 uccess!ul *egistration

3 Passenger

63 &eri!ying *egistration Details

=3 ucces!ul 2pdate

Database 3 Passenger

9.5.:

&olla#oration 2iagram for 0assenger .egistration

:.STATE TRANSITION DIAGRAM

The state transition diagram represents a single o#'ect. (t shows how e ternal factors cause changes in the o#'ect over its lifetime. (t captures the #ehavior of a software system. They provide an e cellent way of modeling communications that occurs with e ternal entities via a protocol or event. *tate diagrams are used to give an a#stract description of the #ehavior of a system. This #ehavior is analyzed and represented in series of events that could occur in one or more possi#le states. Dere#y "each diagram usually represents o#'ects of a single class and trac!s the different states of its o#'ects through the system". The following are the #asic notational elements that can #e used to ma!e up a diagram% 4illed circle, pointing to the initial state Dollow circle containing a smaller filled circle, indicating the final state (if any) .ounded rectangle, denoting a state. Top of the rectangle contains a name of the state. &an contain a horizontal line in the middle, #elow which the activities that are done in that state are indicated $rrow, denoting transition. Thic! horizontal line with either H3 lines entering and 3 line leaving or 3 line entering and H3 lines leaving. These denote 'oin/for!, respectively. State T"ans#t#on $#a'"a(s a"e ,al%able be&a%se7 (dentify the specific responses of an o#'ect to everything that can happen to the o#'ect. (dentifies what events an o#'ect will and will not respond. Aalidate the data needed to define the state of the o#'ect and the attri#utes affected #y the change. Delps in finding the internal effects of #ehavior that can not #e seen using interaction #ased diagrams.

State C*a"t D#a'"a(

)nquiry"# )nquiry Pass*eg" name?add?telno?dob # *egistration Login

P'*-en" passid?booking.details #

Booking

Pay*eciept-en" pnr #

Payment

:.3 *tate &hart 2iagram for Tic!et .eservation

. CLASS DIAGRAM
&lass diagram, one of the most commonly used diagrams in o#'ect-oriented system, models the static design view for a system. The static view mainly supports the functional re)uirements of a system I the services the system should provide to the end users. 7e will see from our practical e perience that lots of fun comes out when modeling out system with class diagrams. $ class diagram shows a set of classes, interfaces, and colla#orations and their relationships. &lass diagrams involve glo#al system description, such as the system architecture, and detail aspects such as the attri#utes and operations within a class as well. The most common contents of a class diagram are% &lasses (nterfaces &olla#orations 2ependency, generalization, and association relationships 1otes 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.

Booking P'*'o 3 /nteger Pass./d 3 /nteger 'o.tickets 3 /nteger eat.'o 3 /nteger Destination 3 tring Book.date 3 Date Aourney.date 3 Date Amount 3 Double P'*-en"#

ystem

5 login"# 5 5
Payment Pass./d 3 /nteger Amount 3 /nteger Paymode 3 tring Credit.'o 3 /nteger Cheque.'o 3 /nteger Pay.date 3 Date Pay*eceipt-en"#

Cancellation P'*'o 3 /nteger Pass./d 3 /nteger 'o.tickets 3 /nteger eat.no 3 /nteger Cancel.date 3 Date Amount 3 Double (icketCancel"# PayDeduct"# Cancel*ec-en"#

Passenger Pass./d 3 /nteger Pass.name 3 tring Pass.add 3 &ariant Pass.tel 3 /nteger Pass.birth 3 Date )nquiry"# Pass*eg"# Pass/d-en"#

;.3 &lass 2iagram for -us .eservation *ystem

;.COMPONENT DIAGRAM
The component diagram represents pieces of software in the implementation environment. (t models the implementation view of the software. 7e can use component to represent source code, JML or any piece of software. 7hen using large software system it is common to #rea! the software in to managea#le su#systems. (n UML component classifier represents this. $ component is a replacea#le, e ecuta#le piece of larger system whose implementation details are hidden. The functionality provided #y a component is specified #y a set of provided interfaces that the component realizes. (n addition to providing interfaces, a component may re)uire interfaces in order to perform. These are called re)uired interfaces. &omponents are designed to #e reused. Co(.onent $#a'"a( a"e ,al%able be&a%se t*e-7 Model the real software in the implementation environment. They #ring forward configuration issues through the dependency relationships. They provide an accurate picture of e isting systems prior to ma!ing changes or enhancements.

Co(.onent D#a'"a( 72ata #ase server contains all the data#ase ta#les.

<<-2/>> $)B B*B$ )*

<</'0*A (*2C(2*)>> B2 *) )*&A(/B' , ()1

1, CL

<.3 &omponent 2iagram for -us .eservation *ystem

<.DEPLOYMENT DIAGRAM
The deployment diagram models the hardware of the implementing environment. Bach node on a deployment diagram typically represents the type of hardware such as dis! drive, a client 0&, a server or a processor. $ node may also represent a human #eing or organizational unit. 1odes are li!e classes. They represent a type of device, not a specific device, and the features of each device. Li!e classes they are related using association that e plains how the nodes may #e connected. 2eployment diagrams models the mapping of software pieces of a system to the hardware that is going to e ecute it. *oftware elements are typically manifested using artifacts and are mapped to the hardware called nodes. 2eployment diagrams are valua#le #ecause% They model the hardware platform for a system. (dentify hardware capa#ilities that affects performance planning and software configuration.

De.lo-(ent D#a'"a(
<< )*&)*>> $)B )*&)* <<E((P>> (CPD/P

<<$)B B*B$ )*>> CL/)'( CB1P2()*

<<ADBC>> <<1, CL>> DA(ABA ) )*&)*

(CPD/P

=.3 2eployment 2iagram for -us .eservation *ystem