Object oriented programming


Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Object oriented programming

  1. 1. T.Z.A.S.P. MANDALSPRAGATI 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 BY1. Miss Ashwini Vaykole - Roll No. 142. Miss Priyanka Khedlekar - Roll No. 293. Miss Ashwini Godage - Roll No. 154. Miss Namrita Sundarraj - Roll No. 34
  2. 2. INDEX1. Introduction • Problem Statement • Analysis • Requirement Specification2. Domain Modelling • Identifying Classes • Identifying Attributes • Identifying Methods • Inheritance Relationship3. Use-case Modelling • Identifying Actors • Developing Use-cases • Developing Interaction Sequence Diagrams4. Completing Analysis Model5. Implementation6. Conclusion
  3. 3. INTRODUCTION • PROBLEM STATEMENT The system to be developed is intended to support day-to-day operationsof hotel management system by improving the various processes such asmaking reservations, assuring bills, allocating tables, providing services tocustomers, etc. All hotels currently operate all its administration usinghandwritten forms stored in large folders (files). These forms contain variousslots. Each of these slots contains the requirements of every customer,availability of resources that are demanded by customer, his personalinformation and other necessary things that are essential for maintaining thehotel records. Accurate and precise description in these forms are required inorder to avoid collision and rectify mistakes and also for future reference andimprove the working of hotel management system. Further, remarks are addedto these records to keep track of various events (situations). The problem ariseswhen these forms are misplaced, or lost, clashes may occur during enteringsimilar records or searching for the specific record location. • ANALYSIS The numerous problems identified with the manual system affect theregular functioning of the hotel. Since the manual system is slow, this can leadto operational problems such as the customer may be prevented from using thefacilities (services) which may be available but may appear to the hotel staffthat the particular service is already engaged. As the process is manual, there isno backup system if the forms (sheets) gets destroyed and retrieving the same isnot as easy as there is no record of what had been lost. Finally, it is very timeconsuming to get even minute details of the simple information that has beenlost. For these reasons, the system that is developed should be automated forminimizing human error, improving the accuracy of the system and to make iteasy for hotel staff to transfer all the manual details to the new system. Whennew entries are recorded or changes are made to the existing entries, the displayshould be immediately updated so that hotel staffs are always working with the
  4. 4. latest information available. Operations of the system will be as far as possibleby direct manipulation of the data presented on the screen. For example, itshould be possible to change the time of the booking, or the table it is allocatedto, simply by dragging the booking to an appropriate place on the screen. From the above discussion, we can conclude that we should develop asystem that provides the core functionality which simplifies the maintenance ofessential records. So, to implement this basic requirement is the ability tomanipulate records and update records with essential details during the workinghours of the hotel. Thus, it would be possible to use the system as a replacementfor the existing manual system, and then to develop additional functionality inlater iterations. • REQUIREMENT SPECIFICATION In order to make the system efficient and upgraded in terms ofits usage, the hotel intends to develop a software program thatperforms 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 orienteddesign process in order to provide a complete solution to the problemspecified. We begin our design process by presenting specificationthat specifies the overall purpose of hotel management system anddetermines precisely what functionality the system must include. In hotel management system loaging and boarding sectionconsist of registering a user (i.e. providing the customers identity)
  5. 5. followed by the other transactions he make’s. To do this, our softwaremodel should interact with the basic information database of our hotel(restaurant details, number of rooms available etc). After the system successfully executes transactions,the system should redisplay the main menu so that the user canperform additional transactions. If the user chooses to exit the system,the screen should display a thank you message, and then display thewelcome message for the next user. DOMAIN MODELLING • IDENTIFYING CLASSES Now we need to identify classes so that we can build the hotelmanagement system by analyzing the noun and noun phrases thatappear in the requirement specification (problem statement). We maydecide that some of these nouns and noun phrases are attributes ofother classes in the system. For example, if we consider process asone class it can be the attribute of the transaction class whichdescribes it specifically. We may also conclude that some of thenouns do not corresponds to the parts of the system and thus shouldnot be modeled at all. For example, Funds so fig (a) lists the noun andnoun phrases which are required in the system. We list them from listfrom left to right in the order in which they appear in the problemstatement. However we list only singular form of each noun or nounphrases. We create classes only that have significance in the hotelmanagement system. We do not need to model amount as a classbecause amount is not a part of our system. We do not model bills orforms as a class because these are physical objects in the real world,but they are not a part of what is being automated.
  6. 6. 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 onetransaction. In our simplified hotel system, the class’s cash andcheque can be used as attributes of other classes. Likewise, the nounsaccount number and amount represent significant pieces ofinformation in our system. They are important attributes of ofpayment (class). These classes possess specific attributes needed forexecuting the transactions they represent. For example, a cashierneeds to know the amount of money the user wants to pay in advance.A balance enquiry, however, does not require any additionalinformation.
  7. 7. • IDENTIFYING ATTRIBUTES We can identify many attributes of the classes in our systemby looking for descriptive words and phrases as mentioned in thetable. For each one, we find that class which plays a significant role inour system so that we can create an attribute and assign it to one ormore of the classes identified in the above section. We also createattributes to represent any additional data that a class may need.Identified any nouns or phrases refers to the characteristics of theclass in the system. For example, the previous section describes thesteps taken to obtain a payment so; we list cash and cheque next to theclass payment. The classes balance and advance share two attributes.Each transaction involves a bill number and amount that correspondsto the account of the customer making the transaction. So we assignan integer attribute bill number and amount to each transaction classto identify the customer account to which an object of the classapplies. Descriptive nouns and phrases also suggest some differences inthe attributes required by each transaction. The previous phaseindicates that to obtain the payment by means of cash or cheque wemust enter a specific amount of money to be deposited respectively.Thus, we assign to class’s cash and cheque an attribute amount tostore the value supplied by the user. The amount of money related tocash and cheque are defining characteristics of these transactions thatthe system requires for them to take place. The class balance however,needs no additional data to perform its task – it requires only anaccount number to indicate the account whose balance should beretrieved. The class attributes are placed in the middle compartmentclasses rectangle beneath the name. The attribute declaration containsthree pieces of information about the attribute that is the attributename, attribute type and attribute value. Data types can be used toshow the type of attribute (integer, double or Boolean). We can also
  8. 8. indicate an initial value for an attribute but if an attribute has no initialvalue specified, only its name and type are shown (separated bycolon). For example, the quantity attribute of class room is an integer.Here we show no initial value because the value of this attribute is anumber that we do not yet know – it will be determined at executiontime 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 thestructure of our model but the diagram is not complete. We need toidentify the operation that the objects will perform during the programexecution. • IDENTIFYING METHODS ( OPERATIONS ) An operation is a service that objects of a class provide to clientsof the class. The operations of a class are placed and represented inthe bottom compartment of the classs rectangle. Operations arenamed and in addition can have arguments and return results, likefunctions in programming languages. The parameter and return typesof operations can be either name of data types, as used for specifyingattributes types, all the information apart from the operations name isoptional. As little or as much information can be provided as isappropriate at the stage that the development process has reached. The classes that play a major role in achieving system goals andrequirements by using their methods are as follows:
  9. 9. Customer Class: Customer is an individual who interacts with thesystem by means of ordering, booking and payment and has its owndetails.Enquiry Class : This is a class that provides sufficient informationto the customers needs.Booking Class : This is a class that allows the customer to book thefacilities granted by the hotel.Order Class : It is a class that serves as a customers request forsomething to be supplied.Manager Class : A manager is an individual who manages staff, anorganization and acts as an interface between system and thecustomer by solving all queries.Bill Class : It is a class that serves as a written statement ofcharges 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 areautomatically defined for all descendant classes. More precisely, allthe attributes and operations defined in the ancestors of a class arealso features of the class itself. This provides the means wherebycommon features shared by a number of classes can be defined in oneplace and yet made available in a number of different classes.
  10. 10. For example, in case of ordering, this diagram states that all theclasses including the parent class and child class have price, quantityand type attributes, and operations to access these attributes. Thesefeatures 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 visiblebehavior of the system. In so far, as software developmentbegins with the consideration of the requirements of theproposed system, therefore the use – case view limitedlyforces the subsequent development. The use - case view presents a structured view of systemsfunctionality. It does this by defining a number of actors,which model the roles that users can play when interactingwith the system and describing the use-cases that those actorscan participate in. Due to this, a specific task can be definedthat user can access in the system. Thus, the use- case viewcontains the use-cases which define the complete functionalityof the system (or at least the functionality which defines thecurrent process). Here we have described the use – cases for the bookingsystem which allows users to make use of automated bookingsheet, the ordering system and the payment system in thesimilar manner. This graphical representation shows the actors
  11. 11. (may be a staff or a customer) which specifies the task thatuser would recognize as a part of their normal job (that is itsduty), the use – cases that determines the behavior of actorsand the connections between them. These actors arerepresented by a stylized icon of a person and the use – casesby ovals containing the name of the use-case. Where an actorparticipates in or can perform a particular use-case, thisrelationship is shown by connecting the actor to the relevantuse-case. It is also possible to define the shared behavior thatis common to more than one use-case. For example, acustomer who brings up the restaurant to make a booking willspeak to an employee of the restaurant who will record thebooking of the system. To do this, the employee will need toact as receptionist, even if this is not their formal jobdescription, and interact with the system in some way. In thissituation, the employee is considered to be an instance ofreceptionist actor, and the interaction that takes place betweenthem and the system is an instance of the use-case. The detailsof what happens in different instances of the use-case can varyin many ways. For example, the receptionist will have to enterspecific data for each new booking, such as the names andphone numbers of different customers and this data will varyfrom instance to instance. There may arise a situation that if there was no suitabletable available at the time the customer requested, an instanceof use-case might not in fact result in a booking being made.Therefore, a use-case description should involve a largeamount of data in a systematic way so that such occurrencesmay be avoided.
  12. 12. • INTERACTION DIAGRAMS The fig (e) shows the sequence interaction diagram showing theinteraction between the customer and the system. The classifier rolesinvolved in the interaction are displayed at the top of the diagram. Thevertical dimension in the sequence diagram represents time and themessages in an interaction are drawn from top to bottom of thediagram, in the order that they are sent. Each role has a dashed lineknown as its lifeline extending below it. Lifeline indicates the periodof time during which objects playing that role actually exists. In thefigure, all objects exist throughout the entire interaction but someobjects are not required till the end. The messages are shown as arrows leading from the lifeline ofthe sender of the message to that of the receiver. When the message issent, control passes from sender of the message to the receiver. Theperiod of time during which an object is processing is shown onlifeline as an arrow rectangle whose talk is connected to the message.When an object finishes processing a message, control returns to thesender of the message. This marks the end of the processingcorresponding to that message and is shown by the arrow going backfrom the bottom of the rectangle back to the lifeline of the role thatsent the message. These messages are shown with solid arrowhead. Inthe course of processing a message, an object may send messages toother objects.
  13. 13. COMPLETING THE ANALYSIS MODEL Figure (f) shows the class diagram for system includingthe information and decisions which are derived for carryingout realizations of the use – cases. This information is aboutbooking system, ordering system and the payment systemwhich are the essential elements of our system. This diagramalso contains the information about domain model such asrelationships between the customers: booking, ordering andpayment classes. Here, the users actions are considered asmessages and are passed between the objects of the classes inthe direction of the process being carried out. Also, the objectsin this system have been assigned a number of roles to clarifythe organization of the system. Thus, we have defined all thepossible course of events that occur during the functioning ofthe system.
  14. 14. IMPLEMENTATION The documentation produced during the analysis and designactivates describes the logical structure of the software application.This describes the system basically as a collection of classes, possiblysubdivided into a number of packages. The dynamic behavior ofinstances of the classes is further defined by means of interactiondiagrams. When the system is implemented, these classes are representedin some way in the programming language being used. At this point,the system for the first time takes on a physical form typically as acollection of files of source code. The source code is then compiled,generating various objects, executable or library files. Finally, thesefiles are executed on one or more processors, possibly in combinationwith 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
  15. 15. be created by subclasses. Note that constructors are often omittedfrom class diagrams, but are required in implementations of classes.Attributes of the class are represented with data types. Operations ofthe class are defined as methods with appropriate implementations.When a class is implemented, the visibility of its members needs to beconsidered. If visibility has not been specified by the designer, auseful rule of thumb for implementing attributes and operations is totransform attributes into private fields of the implementation class,and operations into public methods of the class. This reflects a widelyadopted policy on the implementation of classes, which states that aclasss data should be private and only accessible through itsoperational interface. An exception to this rule occurs when attributesof a class need to be accessible to instances of subclasses.
  16. 16. 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 memorizes 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.