A Unified Modeling Language
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.
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.2 Level 1 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
Cheque
Credit card
Payment Deduction
Cancel receipt generated Booking Pass details
Payment <<extend>> <<extend>> Cancellation <<include>> <<include>> Check Availability Login Seat Selection Passenger verification() Window <<extend>> Validation <<uses>> Non Window <<extend>>
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 1
Use case name Seat selection
Actor Online Passenger
Pre-condition Login into the system
Post-condition select seat
Flow of events
Use case ID 2
Use case name Window Seat
Actor Online Passenger
Pre-condition Seat selection
Post-condition select window seat
Flow of events
Use case ID 3
Use case name Non Window Seat
Actor Online Passenger
Pre-condition Seat selection
Post-condition Select non window seat
Flow of events
Use case ID 4
Use case name Select credit card
Actor Online Passenger
Pre-condition Purchase ticket
Post-condition Add credit card details
Flow of events
Use case name Select Cheque
Actor Online Passenger
Pre-condition Purchase ticket
Post-condition Flow of events
Use case ID 6
Use case name Select Cancellation
Actor
Pre-condition Enter details
Post-condition Payment deduction and cancel receipt generated
Flow of events
Use case ID 7
Use case name Booking pass details
Actor Online Passenger
Pre-condition Enter details of passenger
Post-condition Details stored
Flow of events
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 object-oriented 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.
Ticket Enquiry Login Details Registered Passenger? Yes Register No Get Pass_Id Fill Booking Form Seat Selection Book Tickets?
Yes Make Payment
Reciept Generation Cancellation No Fill Cancellation Form Yes Cancel Ticket Update Database Cannot Cancel No Valid Yes No Generate Reciept Logout
Tickets Available Yes
No
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.
: Passenger : System Database
Enquiry Details
Availability Details
GetDetails
Return Status
Fig 6.1.1 Sequence Diagram to check Availability
: Passenger System Database
Login Details
Username & Password
Retrieve Member Details
Provide Access
: Passenger System Database New User Request
Registration Form
Submit Registration Form
Verifying Registration Details
Succesful Update Successful Registration
Fig 6.1.3 Sequence Diagram for Reservation
: Passenger System Database
New User Request Registration Form
Submit Registration Form
Verifying Registration Details Succesful Update Successful Registration
: Passenger System Database : Payment PNR no
Release Tickets
Payment Deduction
Cancellation Reciept Generated Cancellation Reciept Provided
Retrieve Details Return Details Reservation Details
Request For Cancellation
Update Succesful
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 Symbol
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.
UML Interaction Diagram (Collaboration Diagram) : Passenger : System Database 1: Enquiry Details 4: Availability Details 2: GetDetails 3: Return Status
Fig 6.2.1 Collaboration Diagram to check Availability
Fig 6.2.2 Collaboration Diagram for Login
: Passenger : System Database : Booking Payment : Payment 1: Enter Booking Details
7: Enter Reservation Details 9: Make Payment
6: Provide Booking Form 8: Request For Payment 14: Payment reciept
15: PNR Details
2: Provide Reservation Details 11: Update Database 4: Availability Status 12: PNR Generated 3: Check Amount 10: Update Payment 5: Payment Details
13: Payment Reciept Generated
Fig 6.2.3 Collaboration Diagram for Reservation
: Passenger System : System Database : System 1: Login Details 4: Provide Access
2: Username & Password
: Passenger
System
Database
: Payment 1: PNR no
5: Request For Cancellation
10: Cancellation Reciept Provided4: Reservation Details
6: Release Tickets2: Retrieve Details 3: Return Details
8: Update Succesful
7: Payment Deduction
9: Cancellation Reciept Generated
Fig 6.2.4 Collaboration Diagram for Cancellation
: Passenger
System
Database : Passenger 1: New User Request
3: Submit Registration Form
2: Registration Form 6: Successful Registration
4: Verifying Registration Details
5: Succesful Update
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
Booking PayRecieptGen( pnr ) Payment PNRGen( passid,booking_details )
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 Passenger Pass_Id : Integer Pass_name : String Pass_add : Variant Pass_tel : Integer Pass_birth : Date Enquiry() PassReg() PassIdGen() Cancellation PNRNo : Integer Pass_Id : Integer No_tickets : Integer Seat_no : Integer Cancel_date : Date Amount : Double TicketCancel() PayDeduct() CancelRecGen() * 1 * 1 Payment Pass_Id : Integer Amount : Integer Paymode : String Credit_No : Integer Cheque_No : Integer Pay_date : Date PayReceiptGen() 1 1 1 1 Booking PNRNo : Integer Pass_Id : Integer No_tickets : Integer Seat_No : Integer Destination : String Book_date : Date Journey_date : Date Amount : Double PNRGen() 1 * 1 * System login() 1 1 1 1 11 11 11 11
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 <<GUI>> BUS RESERVATION SYSTEM <<INFRASTRUCTURE>> MYSQL
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
CLIENT COMPUTER
<<WEB BROWSER>> WEB SERVER<<SERVER>>
DATABASE SERVER <<MYSQL>> TCP/IP <<JDBC>> TCP/IP <<HTTP>>
Fig 10.1 Deployment Diagram for Bus Reservation System
