Вы находитесь на странице: 1из 42

Online Hotel Reservation System

The UML Mini Project report submitted in partial fulfillment Of the requirements of the Case tools lab in

Bachelor of Technology In Information Technology By T.Sireesha P.Prudhvini G.Sowmya N.Bhuvana 09241A1242 09241A1229 09241A1243 10245A1201

Under the Esteemed Guidance of

Mr.S.V.Appaji (Assistant Professor)

DEPARTMENT OF INFORMATION TECHNOLOGY GOKARAJU RANGARAJU INSTITUTE OF ENGINEERING AND TECHNOLOGY


HYDERABAD

2012

CERTIFICATE

This is to certify that it is a bonafide record of the UML Mini Project work entitled ONLINE HOTEL RESERVATION SYSTEM done by T.SIREESHA(09241A1242), P.PRUDHVINI(09241A1229), G.SOWMYA(09241A1243), N.BHUVANA KRANTHI (10245A1201), students of B.Tech in the Department of Information Technology, Gokaraju Rangaraju Institute of Engineering and Technology during the period 2012 in the in the partial fulfillment of the Case Tools Lab requirements for the degree of B.Tech in Information Technology. This work is not submitted to any other university/college..

S.V APPAJI
UML Mini Project guide Department of IT, GRIET

ACKNOWLEDGEMENT

We wish to express our deep gratitude to our guide S.V APPAJI, Assistant Professor, in the Department of Information Technology, for all the advice, encouragement and constant support he has given us throughout our project work. This work would not have been possible without his support and valuable suggestions. We are grateful to Prof. Dr. T.V.RajiniKanth, Head of the Department of Information Technology for their valuable suggestions. We are also grateful to Dr. Jandhyala N.Murty, Principal and Prof P.S.Raju, Director of GRIET for giving us the necessary facilities to carry out our project work successfully. We would like to thank all our friends for their help and constructive criticism during our project work.

T.Sireesha P.Prudhvini G.Sowmya N.Bhuvana

09241A1242 09241A1229 09241A1243 10245A1201

ABSTRACT
The main aim of the entire project is to automate the process of day to day activities of Hotel like Room activities, Admission of a New Customer, Assign a room according to customers demand, checkout of a computer and releasing the room and finally compute the bill etc. The main purpose of this exercise is performing each Users activity in computerized way rather than manually which is time consuming.

Contents
1. INTRODUCTION ABOUT LAB .................................................................................................................. 6 1.1 CHARACTERISTICS OF CASE.................................................................................................. 6 1.2 OBJECTIVES OF THE LAB ....................................................................................................... 7 1.3 AIMS OF UML............................................................................................................................. 7 1.4 UML Diagrams ........................................................................................................................... 7 1.5 REQUIREMENTS ....................................................................................................................... 7 2. INTRODUCTION TO UNIFIED MODELING LANGUAGE ................................................................... 8 2.1 THE ARTIFACTS OF A SOFTWARE SYSTEM ....................................................................... 8 2.2 CONCEPTUAL MODEL OF THE UML .................................................................................. 10 2.2.1 UML building blocks ........................................................................................................... 10 2.2.2 Structural things ................................................................................................................... 10 2.2.3 Relations .............................................................................................................................. 11 2.2.4 Diagrams .............................................................................................................................. 13 3. PROJECT INTRODUCTION ..................................................................................................................... 23 4. PROJECT ANALYSIS .................................................................................................................................. 24 4.1 THE OVERALL DESCRIPTION .............................................................................................. 24 4.2 SPECIFIC REQUIREMENTS.................................................................................................... 25 5. UML DIAGRAMS ........................................................................................................................................ 28 5.1 CLASS DIAGRAM .................................................................................................................... 28 5.2 USE CASE DIAGRAM .............................................................................................................. 30 5.3 STATE CHART DIAGRAM...................................................................................................... 32 5.4 SEQUENCE DIAGRAM............................................................................................................ 34 5.5 ACTIVITY DIAGRAMS ........................................................................................................... 36 5.6 COLLABORATION DIAGRAMS ............................................................................................ 38 5.7 COMPONENT DIAGRAM ........................................................................................................ 39 5.8 DEPLOYMENT DIAGRAM .................................................................................................... 41 6. CONCLUSION .............................................................................................................................................. 42

1. INTRODUCTION ABOUT LAB


CASE tools known as Computer-aided software engineering tools is a kind of component-based development which allows its users to rapidly develop information systems. The main goal of case technology is the automation of the entire information systems development life cycle process using a set of integrated software tools, such as modeling, methodology and automatic code generation. Component based manufacturing has several advantages over custom development. The main advantages are the availability of high quality, defect free products at low cost and at a faster time. The prefabricated components are customized as per the requirements of the customers. The components used are pre-built, ready-tested and add value and differentiation by rapid customization to the targeted customers. However the products we get from case tools are only a skeleton of the final product required and allot of programming must be done by hand to get a fully finished, good product.

1.1 CHARACTERISTICS OF CASE

Some of the characteristics of case tools

It is a graphic oriented tool. It supports decomposition of process.

Some typical CASE tools are:

Unified Modeling Language Data modeling tools, and Source code generation tools

1.2 OBJECTIVES OF THE LAB


1 .Documenting user requirements using the UML notation 2. Description of the various components of UML 3. The use of Use Cases

1.3 AIMS OF UML


1. Models helps us to visualize a system as it is or an as we want it to be. 2. Models permit us to specify the structure or behavior of a system. 3. Models gives us a template guides us in constructing a system. 4. Models document the decisions we have made.

1.4 UML Diagrams


UML diagrams to be developed are:

1. Use Case Diagram. 2. Class Diagram. 3. Sequence Diagram. 4. Collaboration Diagram. 5. State Diagram 6. Activity Diagram. 7. Component Diagram 8. Deployment Diagram.

1.5 REQUIREMENTS
Hardware and Software required:

1. A working computer system with either Windows or Linux 2. Rational Rose Software or Visual Paradigm Software or Star UML

2. INTRODUCTION TO UNIFIED MODELING LANGUAGE


The unified modeling language (UML) is a standard language for writing software blue prints. The UML is a language for Visualizing Specifying Constructing Documenting

2.1 THE ARTIFACTS OF A SOFTWARE SYSTEM


UML is a language that provides vocabulary and the rules for combing words in that vocabulary for the purpose of communication. A modeling language is a language whose vocabulary and rules focus on the concept and physical representation of a system. Vocabulary and rules of a language tell us how to create and real well formed models, but they dont tell you what model you should create and when should create them. 2.1.1 Visualizing The UML is more than just a bunch of graphical symbols. In UML each symbol has well defined semantics. In this manner one developer can write a model in the UML and another developer or even another tool can interpret the model unambiguously. 2.1.2 Specifying UML is used for specifying means building models that are precise, unambiguous and complete. UML addresses the specification of all the important analysis, design and implementation decisions that must be made in developing and deploying a software intensive system.

2.1.3 Constructing UML is not a visual programming language but its models can be directly connected to a variety of programming languages. This means that it is possible to map from a model in the UML to a programming language such as java, c++ or Visual Basic or even to tables in a relational database or the persistent store of an object-oriented database. This mapping permits forward engineering. The generation of code from a UML model into a programming language. The reverse engineering is also possible you can reconstruct a model from an implementation back into the UML. 2.1.4 Documenting UML is a language for Documenting. A software organization produces all sorts of artifacts in addition to raw executable code. These artifacts include Requirements, Architecture, Design, Source code, Project plans, Test, Prototype, and Release. Such artifacts are not only the deliverables of a project, they are also critical in controlling, measuring and communicating about a system during its development and after its deployment.

2.2 CONCEPTUAL MODEL OF THE UML


To understand the UML, we need to form a conceptual model of the language and this requires learning three major elements. The UML Basic Building Blocks. The Rules that direct how those building blocks may be put together. Some common mechanisms that apply throughout the UML. As UML describes the real time systems it is very important to make a conceptual model and then proceed gradually. Conceptual model of UML can be mastered by learning the following three major elements: UML building blocks Rules to connect the building blocks. Common mechanisms of UML.

2.2.1 UML building blocks The building blocks of UML can be defined as:

Things Relationships Diagrams

Things can be:


Structural Behavioral Grouping Annotational

2.2.2 Structural things Class: A class is the descriptor for a set of objects with similar structure, behavior, and

relationships. It is represented by a rectangle.

10

Interface: An interface is a specified for the externally-visible operations of a class, component, or other classifier (including subsystems) without specification of internal structure. It is represented by a circle.

2.2.3 Relations Association Dependency Generalization Realization

In addition to this there are Directed Association Aggregation Composition

Association: An association is a structural relationship that specifies the relation between two objects when they are at the same level (peer level systems). An Association can specify the relationship, role of the class and Multiplicity. An Association used in class diagram, Component diagram, deployment diagram, use case diagrams. The multiplicity can be represented as 1-1..*, *, 01.

It is represented as follows:

11

Directed Association: Links a semantic association between two classes in the UML diagram. Directed association is used in class diagram, Component diagram, deployment diagram, use case diagrams.

Aggregation Links a semantic association between two classes in the UML diagram. Aggregation is used in class diagram.

Composition Links a semantic association between two classes in the UML diagram. Composition is used in class diagram.

Generalization Generalization is a specification relationship in which objects of the specialized element (the child) are substitutable for objects of the generalization element (the parent).It is used in class diagram.

Dependency: A dependency is a semantic relationship in which if there is any change occurred in one object that may affect other object. Dependency is used in class diagram, Component diagram, deployment diagram, usecase diagrams. -----------------------------------------

12

Realization: Realization is a Specified tool that can be represented by providing a relationship with classifier. Dependency is used in class diagram, Component diagram, deployment diagram, usecase diagrams. ----------------------------------------------

2.2.4 Diagrams Class diagrams: A class diagram is that which represents a set of classes, interfaces, and collaborations and their relationships, graphically a class diagram is a collection of vertices and arcs. It consists of three compartments.
Name Attributes Operations

Uses: A class diagram is used to model the static design view of a system.

Object diagrams: An object diagram shares the same common properties of all other diagrams. ; Name
Attributes Operations

Uses: An object diagram is used to model the static design view of a system.

13

Use Case Diagrams: A use case diagram shares the common properties as all diagrams. It distinguishes in the contents of use cases, actors, dependency, and generalization relationships.

Actor Uses: A Usecase diagram is used to model the static design view of a system.

Interaction Diagrams: An Interaction diagram shares the same common properties as all other diagrams. It differs in its contents Objects Links Messages

It includes two diagrams Sequence and Collaboration

Sequence Diagrams: A sequence diagram emphasizes the time ordering of messages. Sequence diagrams have two features that distinguish them from collaboration diagrams. (i) (ii) Object life time The focus of control

Collaboration Diagrams: A collaboration diagram emphasizes the organization of the objects that participate in an interaction Collaboration diagrams have two features that distinguish them from sequence diagrams. (iii) (ii) Path The Sequence number

14

Object: It is an instance of a class.


Object name

Stimulus: A Stimulus is a communication between two Instances that conveys information with the expectation that action will ensue. A Stimulus will cause an Operation to be invoked, raise a Signal, or cause an Instance to be created or destroyed.

It can be annotated by a name. It has a property as Action kind.

Call:

Send:

Return: ------------------------------------------

Create:

<<create>>

15

Destroy:

<<destroy>>

Uses: Interaction diagrams are used to model the dynamic aspects of a system. It is obtained in two ways: (i) (ii) To model flows of control by time ordering. To model flows of control by organization.

State Chart Diagrams: State: A state is a condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event. It is represented by a rounded rectangle.
State Name

Sub machine State: A submachine state is a syntactical convenience that facilitates reuse and modularity. It is shorthand that implies a macro-like expansion by another state machine and is semantically equivalent to a composite state.

Sub State Name

Initial State: An initial is a kind of pseudo state that represents the starting point in a region of a state machine. It has a single outgoing transition to the default state of the enclosing region, and has no incoming transitions. There can be one (and only one) initial state in any given region of a state machine. It is not itself a state but acts as a marker.

16

Final State: A final state represents the last or "final" state of the enclosing composite state. There may be more than one final state at any level signifying that the composite state can end in different ways or conditions. When a final state is reached and there are no other enclosing states it means that the entire state machine has completed its transitions and no more transitions can occur. Symbol:

Junction Point: Junction Point chains together transitions into a single run-to-completion path. May have multiple input and/or output transitions. Each complete path involving a junction is logically independent and only one such path fires at one time. May be used to construct branches and merges.

Transition: A transition is a directed relationship between a source state vertex and a target state vertex. It may be part of a compound transition, which takes the state machine from one state configuration to another, representing the complete response of the state machine to a particular event instance.

17

Activity Diagram: It represents the different activities in the system. Action State: An action state represents the execution of an atomic action, typically the invocation of an operation. An action state is a simple state with an entry action whose only exit transition is triggered by the implicit event of completing the execution of the entry action. The state therefore corresponds to the execution of the entry action itself and the outgoing transition is activated as soon as the action has completed its execution.

Sub Activity State: A sub activity state represents the execution of a non-atomic sequence of steps that have some duration; that is, internally it consists of a set of actions and possibly waiting for events. That is, a sub activity state is a hierarchical action, where an associated sub activity graph is executed.

Sub Activity Name

Initial State: An initial is a kind of pseudo state that represents the starting point in a region of a state machine. It has a single outgoing transition to the default state of the enclosing region, and has no incoming transitions. There can be one (and only one) initial state in any given region of a state machine. It is not itself a state but acts as a marker.

Final State: A final state represents the last or "final" state of the enclosing composite state. There may be more than one final state at any level signifying that the composite state can end in different ways or conditions. When a final state is reached and there are no other

18

enclosing states it means that the entire state machine has completed its transitions and no more transitions can occur.

Decision: A state diagram (and by derivation an activity diagram) expresses a decision when guard conditions are used to indicate different possible transitions that depend on Boolean conditions of the owning object.

19

Component Diagrams:

Package: A package is a grouping of model elements. Packages themselves may be nested within other packages. A package may contain subordinate packages as well as other kinds of model elements. All kinds of UML model elements can be organized into packages.

Component: A component represents a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.

Artifact: An Artifact represents a physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An Artifact may constitute the implementation of a deployable component.

<<Artifact>>

20

Deployment Diagrams: Node: A node is a run-time physical object that represents a computational resource, generally having at least a memory and often processing capability as well, and upon which components may be deployed.

Node Name

Node Instance: A node instance is an instance of a node. A collection of component instances may reside on the node instance.

Node Name

Artifact: An Artifact represents a physical piece of information that is used or produced by a software development process. Examples of Artifacts include models, source files, scripts, and binary executable files. An Artifact may constitute the implementation of a deployable component.
<<Artifact>>

21

2.3. Architecture of UML


Any real world system is used by different users. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewers perspective. The better we understand the better we make the system. UML plays an important role in defining different perspectives of a system. These perspectives are:

Design Implementation Process Deployment

And the centre is the Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with use case. 2.3.1 Design of a system consists of classes, interfaces and collaboration. UML provides class diagram, object diagram to support this. 2.3.2 Implementation defines the components assembled together to make a complete physical system. UML component diagram is used to support implementation perspective. 2.3.3 Process defines the flow of the system. So the same elements as used in Design are also used to support this perspective. 2.3.4 Deployment represents the physical nodes of the system that forms the hardware. UML deployment diagram is used to support this perspective.

22

3. PROJECT INTRODUCTION
This project is used by two types of users.

A. Online Users. B. Administrator (management of the Hotel).

Online users can see the required articles or news

Administrator can maintain daily updates in the hotel records. Administrator is must be an authorized user. He can further change the recovery, logout etc. password. There is the facility for password

This system has been designed to computerize the following functions that are performed: Room Detail Functions Opening a New Room Modification to room assigned Check-in and check-out Detail Functions Admission of New customer Check-out of customer Room assigning related to customers need. Statement of Customer Details Check-in customer Check-out customer Room Details Total number of Customers in the Hotel Individual customer Report

23

4. PROJECT ANALYSIS
4.1 THE OVERALL DESCRIPTION
This section describes the general factors that affect the product and its requirements.

4.1.1 Product perspective


This online hotel reservation system is the stand-alone system. It is totally self contained.

Hardware Interfaces This system will be placed on PCs throughout the hotel.

Software Interfaces In this system, we maintain two data bases. These databases include hotel rooms and customers information. These can be modified by the end users. The room databases will include the room numbers and if they are vacant or occupied. The customers information database maintains all the information about the customer such as name, number of occupants, assigned room, default room rate, phone number, whether or not the room is guaranteed, credit card number etc.

4.1.2 Product Functions


Reservation and Booking system Allows for typing in customer information Has a default room rate that is adjustable Includes a description field for the changed rate When a customer checks in, the room number will be changed to occupied in the database Ability to modify a reservation when a customer checks out the amount owed is displayed records that room is vacant records payment allows for space to write customers feedback 24

General Manager Services and Automated Tasks System Reports generated to audit hotel occupancy, future occupancy and room revenue. Exception reports listing to the normal cost Allows addition, deletion and modification of information on rooms and rates. Creation of users and assigning passwords.

4.2 SPECIFIC REQUIREMENTS 4.2.1 External Interfaces


User Interfaces The user interface screens are: Login Reservation log into the system as a CSR or Manager.

Retrieve button, update/save reservation, cancel reservation, change reservation, adjust room rate, accept payment credit card.

Check-in

Modify room stay (e.g., new credit card), check-in customer (with or without a reservation), adjust room rate, special requests, accept payment type/credit card.

Checkout Payment RoomService

checkout customer and generate bill.

accept payment for room.

Create order, modify order, view order, cancel order, generate Meal bill.

Customer Record Administer rooms Administer user

Add or update customer records. availability and rates. create, modify, and delete users; change password. 25

Reports

select, view, save, and delete reports.

Software Interfaces The system shall interface with an oracle or access database.

Hardware Interfaces The system shall run on Microsoft Windows based system.

Communication Interface The system shall be standalone product that does not require any communication interfaces.

Functional Requirements Functional requirements define the fundamental actions that system must perform. Two categories in Functional Requirements: 1. Reservation/booking. 2. Management.

Reservation/Booking The system shall record reservations. The system shall record customer details. The system shall record the room number. The system shall display the default room rate. The system shall display whether or not the room is guaranteed. The system will generate unique confirmation for each reservation. The system will record expected check in time and date and also expected check out time and date. The system shall display the amount owed by the customer and record the payment. The system shall record the customer feedback.

Management The system shall display the hotel occupancy for a specified period of time. The system shall display the room revenue for a period of time. The system shall display an exception report where default room has been overridden. 26

The system shall allow for the addition, deletion and also modification of information, regarding rooms, rates, and user profiles. The system shall allow managers to assign user passwords.

27

5. UML DIAGRAMS

4.1 CLASS DIAGRAM


Classes declared for Reservation system Facility. RoomRate: Hotel. RoomType. Employee. TravelAgent. HotelBooking. Room. RoomBooking. Person. Client. CreditCard.

Interfaces for Reservation System Booking. Booking is an interface which can be declared to provide the operations such as doBooking(), cancelBooking() to the classes Employee, TravelAgent and Client where the implementation of those methods can be done. Here the relationship between the class and interface is the realization where classes realize the interface such that the interface give the contract and the classes need to carry out that work.

This is the brief description about the class diagram and the classes, interfaces declared for the online hotel reservation system.

28

29

5.2 USE CASE DIAGRAM

Actors in Online Hotel Reservation System: Client. Travel Agent. Hotel Receptionist. Hotel Administrator.

Use cases with brief description: Inquire Information: The customer needs to interact with the hotel interface through the personal system. It involves set of actions.

Reserve/Update Reservation: To reserve the room, the customer needs to interact with the website. If the customer already reserved room, want some updates regarding the increase in occupancy, he must able to update the data by using his login and password which can be provided by the administrator.

Pay for Hotel: This involves set of actions. If the customer ready to book or reserve the room, he needs to enter his complete details and occupancy level. After furnish the details in the form, he demanded to pay the advance. That can be through credit card/debit card. He must enter the correct card number.

Cancel Reservation: The system software should support all the requests made by the each authorized customer. If the customer not satisfied with the facilities and occupancy of each room after few hours he checked in, he may want to cancel the reservation for remaining hours. System software must be in a position that the payment for the staying hours should captured and cancel the reservation. Update Hotel Information:

30

According to the customer feedback, the administrator is update the hotel information such as offers, discounts on rooms and meals provided by the hotel. When the customers checkout from the hotel, the database need to Update and show the availability to the new customers.

Return Payment: This use case extends cancel reservation. Whenever the customer wants to cancel the reservation, system must cancel the reservation and return the payment which remains. Each and every transaction made by the customer or administrator must be updated with the customer database and room database.

31

5.3 STATE CHART DIAGRAM


Diagram Description From the diagram which is for reservation of room in a hotel, it is clear that there is a transition from the idle state to composite state.

Composite state is a state in which again the object undergoes different transitions throughout its life time.

Whenever the customer interact with the window interface and make a request for reservation, then the object states changes from idle to composite state.

In composite state, the object moves from one state to another until the customer reserved room by paying some amount in advance.

Once the room reserved, then the reservation letter may send to the customer mail id by moving its state to transmitting.

Once the room reserved by the customer, then the object comes to the idle state again by coming out of the composite state.

This is the brief description about the state chart diagram for the hotel reservation system.

32

33

5.4 SEQUENCE DIAGRAM

Here the sequence diagram shows the making of hotel reservation where the object initiating the sequence of messages is a Reservation window.

The reservation window sends a makeReservation() message to aHotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation. Here reservation equivalent to the term Booking.

In the diagram, each vertical dotted line is a lifeline. Representing the time that an object exists.

Each arrow is a message call.

An arrow goes from the sender to the top of the activation bar of the message on the receivers lifeline.

The activation bar represents the duration of execution of the message.

In our diagram, hotel which is requested for booking of the room through makeReservation, issues a self call to determine if a room is available.

If available, the hotel creates a Reservation and a Confirmation. The asterisk on the self call means iteration.

34

35

5.5 ACTIVITY DIAGRAMS


Diagram description: The activities are rounded rectangles.

The activity diagram for the customer who wants to check out of the room from the hotel with swim lanes can be shown in the diagram.

Each swim lane talks about each object i.e. which object is responsible for which activity.

A single transition comes out of each activity, connecting it to the next activity. Here we are dealing with customer and receptionist/administrator.

From the diagram, the activity started by the customer object which starts as request made by the customer wants to check out of the room at desk top interface.

Then it given a form such that asking about the customer details which are already loaded in the database.

If the customer enters the information which matches with the database information, then the customer bill should be printed.

And then the sequence of activities is done step by step such that check out customer, unassigned room, finally gives the customer bill to the customer.

Then the customer gets the bill and simply pays by the credit card and simply leaves the room.

If the details entered by the customer at the starting stage are not matched with the information from the database, the customer must be informed that he didnt check into the hotel room.

36

37

5.6 COLLABORATION DIAGRAMS

Diagram description In this online hotel reservation system we maintain mainly two databases i.e. customer database and room database.

Mainly the information about the customer and rooms are stored in databases in tabular forms (relational).These tables are components.

In the diagram, two components which are executable files are inquireroom.exe and inquirehotel.exe Which are having the documents regarding the available rooms and vacant rooms and also the customer information.

There is a dependency relationship between the two components in which inquireroom.exe depends on inquirehotel.exe

38

5.7 COMPONENT DIAGRAM


In this online hotel reservation system we maintain mainly two databases i.e. customer database and room database.

Mainly the information about the customer and rooms are stored in databases in tabular forms (relational).

These tables are components.

In the diagram, two components which are executable files are inquireroom.exe and inquirehotel.exe

Which are having the documents regarding the available rooms and vacant rooms. And also the customer information.

There is a dependency relationship between the two components in which inquireroom.exe depends on inquirehotel.exe

39

40

5.8 DEPLOYMENT DIAGRAM


Diagram Description Deployment diagram for the online hotel reservation system mainly depicts the processors which are widely distributed around the world and the components which are configured them.

These all processors are connected through the device in the distributed system

Cache server is used to store the transactions which are done by the customer at the time shortage of memory until the memory storage should extended.

The primary server is placed at the head branch of hotel chain and remaining servers or processors are located geographically dispersed and connected through the internet.

In our project we assumes as we have a chain of hotels which are at different places such as UK, US etc.

41

6.

CONCLUSION

In the entire project documentation of online hotel reservation system, I deal with the modeling of UML Diagrams such as use case diagram, class diagram, sequence diagram, collaboration diagram, state chart diagram, activity diagram, component diagram and finally with the deployment diagram.

In all these diagrams, class and component diagrams deals with the structure of the entire reservation system.

Sequence, collaboration, state chart, and activity diagrams depicts the behavior of the software. At the edge of the Systems software and hardware, we use deployment diagrams to model the topology of processors and devices on which the software executes.

42

Вам также может понравиться