Object Oriented Programming
Content
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 2. Miss Priyanka Khedlekar 3. Miss Ashwini Godage 4. Miss Ashwini Vaykole Roll No. 34 Roll No. 29 Roll No. 15 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 Contact number Name Address Enquiry Booking system Booking Date and time Table Room Hall Type Capacity Ordering system Order Meal Beverages Quantity Services Manager Duty Staff Department Catering Room Service Account Number Hygiene Restaurant Telephone section Payment system Payment Amount Advance Credit card Cash Engine Cashier Transactions Bill Bill number Duration Balance Tax Discount
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 quantity Meal 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.
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 2. Miss Priyanka Khedlekar 3. Miss Ashwini Godage 4. Miss Ashwini Vaykole Roll No. 34 Roll No. 29 Roll No. 15 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 Contact number Name Address Enquiry Booking system Booking Date and time Table Room Hall Type Capacity Ordering system Order Meal Beverages Quantity Services Manager Duty Staff Department Catering Room Service Account Number Hygiene Restaurant Telephone section Payment system Payment Amount Advance Credit card Cash Engine Cashier Transactions Bill Bill number Duration Balance Tax Discount
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 quantity Meal 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.
