Hotel Management System Software Architecture Design Document, Lecture notes of Computer Networks

Download Hotel Management System Software Architecture Design Document and more Lecture notes Computer Networks in PDF only on Docsity!

Hotel Management System

ANALYSIS AND DESIGN MODELS

prepared by Team 1

Sandra Busik

Susan Le

Peter Lockwood

Pradeep Miglani

Reita Sikka

Kai Zhang

TABLE OF CONTENTS

• 1 ANALYSIS MODEL.....................................................................................................................................................
  • 1.1 STATIC MODEL.....................................................................................................................................................
  • 1.2 ATTRIBUTES OF THE CLASSES ON THE STATIC MODEL.....................................................................................................................................................
  • 1.3 STATE CHARTS.....................................................................................................................................................
  • 1.4 COLLABORATION DIAGRAMS (one for each use case) & MESSAGE SEQUENCE DESCRIPTIONS...........................................................................................................
• 2 DESIGN MODEL.....................................................................................................................................................
  • 2.1 CONSOLIDATED COLLABORATION DIAGRAMS & MESSAGE SEQUENCE DESCRIPTIONS.................................................................................................................
    • 2.1.1 CONSOLIDATED COLLABORATION DIAGRAMS.....................................................................................................................................................
    • 2.1.2 MESSAGE SEQUENCE DESCRIPTIONS FOR CONSOLIDATED COLABORATION DIAGRAMS................................................................................................................
  • 2.2 DISTRIBUTED SOFTWARE ARCHITECTURE DOCUMENT.....................................................................................................................................................
    • 2.2.1 DESCRIPTION OF HOW THE SYSTEM IS DECOMPOSED INTO COMPONENT-BASED SUBSYSTEMS & CONCURRENT COLLABORATION DIAGRAM................
    • 2.2.2 DESIGN OF RELATIONAL DESIGN DATABASE.....................................................................................................................................................
  • 2.3 SUBSYSTEM SOFTWARE ARCHITECTURE.....................................................................................................................................................
    • 2.3.1 OVERVIEW DESCRIPTION OF SUBSYSTEM SOFTWARE ARCHITECTURE...............................................................................................................................................
    • 2.3.2 TASK ARCHITECTURE.....................................................................................................................................................
  • 2.4 INFORMATION HIDING CLASSES.....................................................................................................................................................

2. ATTRIBUTES OF THE CLASSES ON THE STATIC MODEL

- 1.3 STATE CHARTS

Room State Chart

VacantReservedOccupiedRoom number entered when customer check inRm No entered when customer checks inFive hrs. past check inCustomer check outRm. no. entered RROOMoom Statechart

- 1.4 COLLABORATION DIAGRAMS (one for each use case) & MESSAGE SEQUENCE DESCRIPTIONS

We have done individual collaboration diagrams (one for each use case). Per Dr. Wu, they are not required to be turned in. Please see Consolidated Collaboration Diagrams and Message Descriptions for Consolidated Collaboration Diagrams in section 2.1.1 and 2.1.2, respectively.

- 2 DESIGN MODEL - (^) 2.1 CONSOLIDATED COLLABORATION DIAGRAMS & MESSAGE SEQUENCE DESCRIPTIONS

• 2.1.2 MESSAGE SEQUENCE DESCRIPTIONS FOR CONSOLIDATED COLABORATION DIAGRAMS

Message Sequence Description for Consolidated Collaboration Diagram of Reservation and Booking System

The message sequence description below addresses the messages on the Consolidated Collaboration Diagram for Reservation and Booking System.

▲ CSR or Manager actor inputs screen selection and information to HMS Interface. ▲ HMS Interface sends the CSR's or Manager's reservation & booking transaction inputs to Reservation. ▲ Reservation sends a Retrieve Customer Info request along with customer's name to Customer to search for the customer record. ♦ (^) If the customer record is already in the system, Customer sends Customer Info to Reservation. Reservation sends Update Customer Info request along with updated info to Customer. ♦ If the customer record is not yet in the system, Reservation sends Create Customer Info request along with customer info to Customer to create a customer record. ▲ Customer sends Add/Update/Retrieve Customer Info message to HotelDatabase. ▲ Reservation sends a Check Room Availability request along with information on room type, check-in date, check-out date to Room to search for a vacant room. ▲ Room sends a Retrieve Room Availability request to HotelDatabase to get room availability information. ▲ HotelDatabase sends a Room Availability Info response to Room. ▲ Room sends Availability Status to Reservation. ▲ (^) Reservation sends an Apply Discount request to Discount. ▲ Discount sends Get Discount message to HotelDatabase to obtain discount data. ▲ Reservation sends an Update/Retrieve Data request to HotelDatabase to update/retrieve reservation&booking data, and HotelDatabase sends reservation&booking data to Reservation. ▲ Reservation sends a Generate Bill, Charge Bill (or Credit Bill) request along with balance due information to Bill/Payment.

▲ Bill/Payment sends Get Room/FoodService Bill Data message to Room/Food Services System , and Room/Food Services System sends Room/ FoodService Bill Data to Bill/Payment.

▲ Timer sends Scheduler Events to Scheduler. ▲ Scheduler sends a Get Reservation Data request to HotelDatabase. HotelDatabase returns Reservation Data to Scheduler. ▲ (^) Scheduler sends a Cancel Non-Guaranteed Reservation request to Reservation. ▲ Scheduler sends Bill No-Show, Bill Additional Day, Bill GuaranteedReservation request to Bill/Payment.

▲ HMS Interface sends Make Payment (or Credit Payment) message along with customer's payment information to Bill/Payment. ▲ Bill/Payment sends a Payment Made (or Payment Credited) acknowledgment message to HMSInterface. ▲ Bill/Payment sends an Update Bill/Payment request to HotelDatabase.

▲ HMS Interface sends GenerateReport request along with ReportType, ReportParameters to Report.

- 2.2 DISTRIBUTED SOFTWARE ARCHITECTURE DOCUMENT

1. DESCRIPTION OF HOW THE SYSTEM IS DECOMPOSED INTO COMPONENT-BASED SUBSYSTEMS &

CONCURRENT COLLABORATION DIAGRAM

As shown on the Concurrent Collaboration Diagram below, the subsystems consist of a Reservation and Booking subsystem, a Room and Food Services subsystem, and a Management Services subsystem. These subsystems were determined through the use-case-based collaboration diagrams. The objects in the use-case-based collaboration diagrams that communicate frequently with each other, are related to each other, and have high coupling were placed in the same subsystem. Each of these subsystems also performs a major function, which is relatively independent of the functionality provided by the other subsystems. These subsystems can be allocated to a separate node in the distributed environment or can be executed on the same node as other subsystems. These three subsystems are composite subsystems because they all reside at the same location. They all have localized autonomy. Each subsystem controls a given aspect of the system. They encapsulate the objects they contain. The communication between the three subsystems is loosely coupled asynchronous message communication. The Hotel Management System component encompasses the three subsystems. The Hotel Management System is also a composite system. It also encapsulates the objects it contains. All of these components are logical and physical containers.

Concurrent Collaboration Diagram Documentation

The Hotel Management System contains three subsystems. These are Reservation and Booking, Room and Food Services, and Management Services. The Reservation and Booking subsystem encompasses customer check in, check out, room reservation, billing for the customers' stay, and room availability. The Room and Food Services subsystem allows the customer service representative to create the customers' food order and will generate a bill for the order. The Management Services subsystem deals with the maintenance of the hotel services. This subsystem allows management to add, modify, and delete information on rooms and rates and food menu items and prices. Management Services also may administer new employee user profiles for the HMS. The managers may delete, modify, and add employee profiles. This subsystem will also generate reports on these uses. The Hotel Management System Interface will allow the users; Managers and customer service representatives to interact with the system. The users will be able to administer Reservation & Booking services, Room & Food services, and Management services (for management only). The external output device, the printer, is not part of the software to be created. The computers in the hotel will have printers available. The report on pending checkouts and the bill data generated from the Reservation & Booking subsystem will be able to be printed. The reports of all subsystem data from the Management Services subsystem will be able to be printed. The bill generated from the Room & Food Services subsystem will be able to be printed.

Concurrent Collaboration Diagram below

CONCUR

RENT

COLLAB

ORATION

DIAGRA

- 2.3 SUBSYSTEM SOFTWARE ARCHITECTURE

• 2.3.1 OVERVIEW DESCRIPTION OF SUBSYSTEM SOFTWARE ARCHITECTURE

The Hotel Management System is functionally decomposed into the Reservations and Management subsystems. This section describes the criteria used to determine which objects are active and which are information-hiding classes. Active objects execute concurrently and run in their own thread. The active objects are modeled as tasks and the other objects are modeled as information hiding classes. A collaboration diagram is given for each subsystem. The objects having the thicker, bolded borders are tasks. In the Information Hiding Classes Diagram, each class has been given a <> to reflect the type of class being shown. Here are the criteria used to determine which objects in each subsystem are active.

• Keep design simple by not having too many tasks
• Objects that execute concurrently can be made into tasks
• Identify user interface objects
  • HMS Interface
• Identify device interfaces
  • None, other than standard i/o (keyboard, mouse, monitor, and printer)
• Identify system interfaces
  • Room and Food Service System
  • Reservation and Management subsystems
• Identify entity objects
  • See Information Hiding Classes Diagram
• Identify timer objects
  • Scheduler
• Identify state dependent control objects
  • No state dependent control objects that need to run in their own thread
• Identify coordinator objects
  • HotelDatabase object coordinates access to the database
• Identify business logic objects
  • The only business logic object in this stand-alone system is the Reservation object. This object will not be accessed concurrently, so it does not need to run in its own thread. Each client will have its own instance of the Reservation object.
• Identify algorithm objects
  • No substantial algorithms used in the problem domain
• 2.3.2 TASK ARCHITECTURE

Room Availability Info Room Availability Info

Room Availability Info Room Availability Info

TASK

ARCHITEC

TURE

DIAGRAM

FOR

RESERVATI