Object oriented programming

T.Z.A.S.P. MANDAL'S
PRAGATI COLLEGE OF
ARTS,COMMERCE AND SCIENCE

S.Y. B.Sc.(IT)

A CASE STUDY REPORT ON
HOTEL MANAGEMENT SYSTEM

PRESENTED ON : 15 / 10 / 2009

ABLY GUIDED BY Madam Mrs. Rupali Patil

SUBMITTED BY

1. Miss Namrita Sundarraj - Roll No. 34
2. Miss Priyanka Khedlekar - Roll No. 29
3. Miss Ashwini Godage - Roll No. 15
4. Miss Ashwini Vaykole - Roll No. 14

INDEX

1. Introduction
• Problem Statement
• Analysis
• Requirement Specification

2. Domain Modelling
• Identifying Classes
• Identifying Attributes
• Identifying Methods
• Inheritance Relationship

3. Use-case Modelling
• Identifying Actors
• Developing Use-cases
• Developing Interaction Sequence Diagrams

4. Completing Analysis Model

5. Implementation

6. Conclusion

INTRODUCTION

• PROBLEM STATEMENT

The system to be developed is intended to support day-to-day operations
of hotel management system by improving the various processes such as
making reservations, assuring bills, allocating tables, providing services to
customers, etc. All hotels currently operates all its administration using
handwritten forms stored in large folders (files). These forms contain various
slots. Each of these slots contains the requirements of every customers,
availability of resources that are demanded by customer, his personal
information and other necessary things that are essential for maintaining the
hotel records. Accurate and precise description in these forms are required in
order to avoid collision and rectify mistakes and also for future reference and
improve the working of hotel management system. Further, remarks are added
to these records to keep track of various events (situations). The problem arises
when these forms are misplaced, or lost, clashes may occur during entering
similar records or searching for the specific record location.

• ANALYSIS

The numerous problems identified with the manual system affect the
regular functioning of the hotel. Since the manual system is slow, this can lead
to operational problems such as the customer may be prevented from using the
facilities (services) which may be available but may appear to the hotel staff
that the particular service is already engaged. As the process is manual, there is
no backup system if the forms (sheets) gets destroyed and retrieving the same is
not as easy as there is no record of what had been lost. Finally, it is very time
consuming to get even minute details of the simple information that has been
lost.

For these reasons, the system that is developed should be automated for
minimising human error, improving the accuracy of the system and to make it
easy for hotel staff to transfer all the manual details to the new system. When
new entries are recorded or changes are made to the existing entries, the display
should be immediately updated so that hotel staff are always working with the

latest information available. Operations of the system will be as far as possible
by direct manipulation of the data presented on the screen. For example, it
should be possible to change the time of the booking, or the table it is allocated
to, simply by dragging the booking to an appropriate place on the screen.

From the above discussion, we can conclude that we should develop a
system that provides the core functionality which simplifies the maintenance of
essential records. So, to implement this the basic requirement is the ability to
manipulate records and update records with essential details during the working
hours of the hotel. Thus, it would be possible to use the system as a replacement
for the existing manual system, and then to develop additional functionality in
later iterations.

• REQUIREMENT SPECIFICATION

In order to make the system efficient and upgraded in terms of
its usage, the hotel intends to develop a software program that
performs the following basic operations :

• Customer Registration
• Booking Transactions
• Ordering Transactions
• Billing Operation
• Payment Operation
• Storing Operation (.i.e. keeping track of all these transactions
till the customer check – outs )

For this we will perform various steps of an object oriented
design process in order to provide a complete solution to the problem
specified. We begin our design process by presenting specification
that specifies the overall purpose of hotel managament shstem and
determines precisely what functionality the system must include.

In hotel management system loadging and boarding section
consist of registering a user ( i.e. providing the customer's identity )

followed by the other transaction's he make's . To do this, our
software model should interact with the basic information database of
our hotel ( restaurant details , number of rooms available etc).

After the system successfully executes a transactions,
the system should redisplay the main menu so that the user can
perform additional transactions. If the user chooses to exit the system,
the screen should display a thank you message, then display the
welcome message for the next user.

DOMAIN MODELLING

• IDENTIFYING CLASSES

Now we need to identify classes so that we can build the hotel
management system by analysing the noun and noun phrases that
appear in the requirement specification (problem statement). We may
decide that some of these nouns and noun phrases are attributes of
other classes in the system. For example, if we consider process as
one class it can be the attribute of the transaction class which
describes it specifically. We may also conclude that some of the
nouns do not corresponds to the parts of the system and thus should
not be modelled at all. For example, Funds so fig (a) lists the noun
and noun phrases which are required in the system. We list them from
list from left to right in the order in which they appear in the problem
statement. However we list only singular form of each noun or noun
phrases. We create classes only that have significance in the hotel
management system. We do not need to model amount as a class
because amount is not a part of our system. We do not model bills or
forms as a class because these are physical objects in the real word,
but they are not a part of what is being automated.

Noun and noun phrases

Customer Catering
Contact number Room Service
Name Account Number
Address Hygiene
Enquiry Restaurant
Booking system Telephone section
Booking Payment system
Date and time Payment
Table Amount
Room Advance
Hall Credit card
Type Cash
Capacity Engine
Ordering system Cashier
Order Transactions
Meal Bill
Beverages Bill number
Quantity Duration
Services Balance
Manager Tax
Duty Discount
Staff
Department

The classes identified above may appear in more than one
transaction. In our simplified hotel system, the classes cash and
cheque can be used as attributes of other classes. Likewise , the nouns
account number and amount represent significant pieces of
information in our system. They are important attributes of of
payment (class) . These classes possess specific attributes needed for
executing the transactions they represent. For example, a cashier
needs to know the amount of money the user wants to pay in advance.
A balance enquiry, however , does not require any additional
information.

• IDENTIFYING ATTRIBUTES

We can identify many attributes of the classes in our system
by looking for descriptive words and phrases as mentioned in the
table. For each one, we find that class which plays a significant role in
our system so that we can create an attribute and assign it to one or
more of the classes identified in the above section. We also create
attributes to represent any additional data that a class may need.
Identified any nouns or phrases refers to the characteristics of the
class in the system. For example, the previous section describes the
steps taken to obtain a payment so, we list cash and cheque next to the
class payment. The classes balance and advance share two attributes.
Each transaction involves a bill number and amount that corresponds
to the account of the customer making the transaction . So we assign
an integer attribute bill number and amount to each transaction
class to identify the customer account to which an object of the class
applies.

Descriptive nouns and phrases also suggest some differences in
the attributes required by each transaction. The previous phase
indicates that to obtain the payment by means of cash or cheque we
must enter a specific amount of money to be deposited respectively.
Thus, we assign to classes cash and cheque an attribute amount to
store the value supplied by the user . The amount of money related to
cash and cheque are defining characteristics of these transactons that
the system requires for them to take place. The class balance however,
needs no additional data to perform its task – it requires only an
account number to indicate the account whose balance should be
retrieved.

The class attributes are placed in the middle compartment class's
rectangle beneath the name . The attribute declaration contains three
pieces of information about the attribute that is the attribute name ,
attribute type and attribute value. Datatypes can be used to show the
type of attribute ( integer, double or boolean ). We can also indicate

an inital value for an attribute but if an attribute has no initial value
specified, only its name and type are shown ( seperated by colon ).
For example, the quantity attribute of class room is an integer. Here
we show no initial value because the value of this attribute is a
number that we do not yet know – it will be determined at execution
time when the quantity will be entered by the customer.

Room Meal
quantity type
price

Figure (a)

The class diagram in above figure (a) provides a solid basis for the
structure of our model but the diagram is not complete. We need to
identify the operation that the objects will perform during the program
execution.

• IDENTIFYING METHODS ( OPERATIONS )

An operation is a service that objects of a class provide to clients
of the class. The operations of a class are placed and represented in
the bottom compartment of the class's rectangle. Operations are
named and in addition can have arguments and return results, like
functions in programming languages. The parameter and return types
of operations can be either names of data types, as used for specifying
attributes types, all the information apart from the operations name is
optional. As little or as much information can be provided as is
appropriate at the stage that the development process has reached.

The classes that play a major role in achieving system goals and
requirements by using their methods are as follows :

Customer Class : Customer is an individual who interacts with the
system by means of ordering, booking and payment and has its own
details.

Enquiry Class : This is a class that provides sufficient information
to the customer's needs.

Booking Class : This is a class that allows the customer to book the
facilites granted by the hotel.

Order Class : It is a class that serves as a customer's request for
something to be supplied.

Manager Class : A manager is an individual who manages staff, an
organisation and acts as an interface between system and the customer
by solving all queries.

Bill Class : It is a class that serves as a written statement of
charges for services.

Payment Class : It is a class that keeps track of transaction, type,
date, time, amount, quantity and balance.

• INHERITANCE RELATIONSHIP

Inheritance is the process by which properties of a class are
automatically defined for all descendant classes. More precisely, all
the attributes and operations defined in the ancestors of a class are
also features of the class itself. This provides the means whereby
common features shared by a number of classes can be defined in one
place and yet made available in a number of different classes.

For example, in case of ordering, this diagram states that all the
classes including the parent class and child class have price, quantity
and type attributes, and operations to access these attributes. These
features are defined in the parent (root) class that is ordering.

USE CASE MODELLING

• IDENTIFYING ACTORS AND DEVELOPING
USE-CASES

The use – case view describes the externally visible
behaviour of the system. In so far , as software development
begins with the consideration of the requirements of the
proposed system , therefore the use – case view limitedly
forces the subsequent development.

The use - case view presents a structured view of systems
functionality. It does this by defining a number of actors,
which model the roles that users can play when interacting
with the system and describing the use-cases that those actors
can participate in. Due to this , a specific task can be defined
that user can access in the system . Thus, the use- case view
contains the use-cases which defines the complete
functionality of the system ( or atleast the functionality which
defines the current process ).

Here we have described the use – cases for the booking
system which allows users to make use of automated booking
sheet, the ordering system and the payment system in the
similar manner. This graphical representation shows the actors

( may be a staff or a customer ) which specifies the task that
user would recognise as a part of their normal job ( that is its
duty), the use – cases that determines the behaviour of actors
and the connections between them. These actors are
represented by a stylized icon of a person and the use – cases
by ovals containing the name of the use-case. Where an actor
participates in or can perform a particular use-case, this
relationship is shown by connecting the actor to the relevant
use-case. It is also possible to definr the shared behaviour that
is common to more than one use-case. For example, a
customer who rings up the restaurant to make a booking will
speak to an employee of the restaurant who will record the
booking of the system. To do this, the employee will need to
act as receptionist, even if this is not their formal job
description, and interact with the system in some way. In this
situation, the employee is considered to be an instance of
receptionist actor, and the interaction that takes place between
them and the system is an instance of tha use-case. The details
of what happens in different instances of the use-case can vary
in many ways. For example, the receptionist will have to enter
specific data for each new booking, such as the names and
phone numbers of different customers and this data will vary
from instance to instance.

There may arise a situation that if there was no suitable
table available at the time the customer requested, an instance
of use-case might not in fact result in a booking being made.
Therefore, a use-case description should involve a large
amount of data in a systematic way so that such occurances
may be avoided.

• INTERACTION DIAGRAMS

The fig (e) shows the sequence interaction diagram showing the
interaction between the customer and the system. The classifier roles
involved in the interaction are displayed at the top of the diagram. The
vertical dimension in the sequence diagram represents time and the
messages in an interaction are drawn from top to bottom of the
diagram, in the order that they are sent. Each role has a dashed line
known as its lifeline extending below it. Lifeline indicates the period
of time during which objects playing that role actually exists. In the
figure, all objects exists throughout the entire interaction but some
objects are not required till the end.

The messages are shown as arrows leading from the lifeline of
the sender of the message to that of the reciever. When the message is
sent, control passes from sender of the message to the reciever. The
period of time during which an object is processing is shown on
lifeline as an arrow rectangle whose talk is connected to the message.
When an object finishes processing a message, control returns to the
sender of the message. This marks the end of the processing
corresponding to that message and is shown by the arrow going back
from the bottom of the rectangle back to the lifeline of the role that
sent the message. These messages are shown with solid arrowhead. In
the course of processing a message, an object may send messages to
other objects.

COMPLETING THE ANALYSIS MODEL
Figure (f) shows the class diagram for system including
the informations and decisions which are derived for carrying
out realisations of the use – cases. This information is about
booking system , ordering system and the payment system
which are the essential elements of our system. This diagram
also contains the information about domain model such as
relationships between the customer : booking, ordering and
payment classes. Here, the user's actions are considered as
messages and are passed between the objects of the classes in
the direction of the process being carried out. Also, the objects
in this system have been assigned a number of roles to clarify
the organisation of the system. Thus, we have defined all the
possible course of events that occur during the functioning of
the system.

IMPLEMENTATION
The documentation produced during the analysis and design
activites describes the logical structure of the software application.
This describes the system basically as a collection of classes, possibly
subdivided into a number of packages. The dynamic behavior of
instances of the classes is further defined by means of interaction
diagrams.

When the system is implemented, these classes are represented
in some way in the programming language being used. At this point,
the system for the first time takes on a physical form typically as a
collection of files of source code. The source code is then compiled,
generating various objects, executable or library files. Finally, these
files are executed on one or more processors, possibly in combination
with other resources.

Class booking
{
private :
int cover;
setcover();
public :
int date;
int arrtime;
int deptime;
setarrtime();
setdeptime();
getdate();
};

A constructor is defined to initialize the values of the attributes,
but it is declared to be private, so that instances of the class can only

be created by subclasses. Note that constructors are often omitted
from class diagrams, but are required in implementations of classes.
Attributes of the class are represented with data types. Operations of
the class are defined as methods with appropriate implementations.

When a class is implemented, the visibility of its members needs to be
considered. If visibility has not been specifed by the designer, a useful
rule of thumb for implementing attributes and operations is to
transform attributes into private fields of the implementation class,
and operations into public methods of the class. This reflects a widely
adopted policy on the implementation of classes, which states that a
class's data should be private and only accessible through its
operational interface. An exception to this rule occurs when attributes
of a class need to be accessible to instances of subclasses.

CONCLUSION

From the above analysis we conclude as under :

1. Receptionist is always equipped with the latest and updated
status about the booking by the customer.
2. The system provides details about CHECK-IN/CHECK-OUT
status of the customer.
3. The system provides details about the BILLING/PAYMENT
status for the customer.
4. The system provides complete information about the customer
such as Name/Address/Occupation/Purpose of visit/Duration of
stay/Contact No., etc.
5. The system helps avoid unnecessary documentation and record
keeping. Eliminate paper work but at the same time memorises
each and every activity performed/demanded by the customer
during his/her stay. Moreover these are sequentially
noted/recorded and can easily be monitored thereby exercising
full control on the services rendered to the customer.
6. The system provides round-the-clock updated information/status
about the customer.

Object oriented programming

More Related Content

Similar to Object oriented programming

Recently uploaded

Object oriented programming