Designx

yompmulligrubsInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 7 μήνες)

72 εμφανίσεις







SYSTEM DESIGN

HOTEL MANAGEMENT SYS
TEM








J O H A N N L U T T E R O D T

Y O R DA N L Y U B E N O V

E R M I R
I S M A I L I

1 1/
1
6/2 0 1 2



2

1

CONTENTS

1

Contents

................................
................................
................................
.............

2

2

Introduction

................................
................................
................................
.......

3

Purpose

................................
................................
................................
..............

3

Product Scope

................................
................................
................................
....

3

Design goals

................................
................................
................................
.......

3

References

................................
................................
................................
..........

4

3

System architecture

................................
................................
.............................

5

4

Hardware/Software mapping
................................
................................
..............

8

5

Access control and security

................................
................................
.................

9

6

Boundary conditions
................................
................................
.........................

10

6.1

Startup boundary condition
................................
................................
...

10

6.2

Shut down boundary condition

................................
.............................

11

6.3

Exceptions

................................
................................
............................

12

7

Global software control

................................
................................
....................

13

8

Persistent data design
................................
................................
........................

14

9

Subsystem services
................................
................................
............................

16






3

2

INTRODUCTION


PURPOSE

The purpose of this document
is to focus on the solution domain of the project and to lay down
the fundamentals of the design process. Aspects of system design such as the high
-

and low
-

level architectural structure of system will be analyzed in detail.


PRODUCT SCOPE

The aim of this project is to develop a hotel management system. The software is used
exclusively for the management of data of our hotel. It should be easy to efficiently manage data
on all guests, employees, items and assets. A Centralized

data management as well as a multi
-
user
system is to be implemented.


DESIGN GOALS

The design goals represent the expected qualities of the final product. The following goals were
highly ranked on importance and have to be implemented as such.




Usability

The
HMS

should be easily operated by an individual with basic computer skills. The user
interface should be intuitive and ensure a big learning curve of the software for user.




Performance

The system has to support multi
-
access by several terminals simult
aneously and is to use a
minimal amount of time (2 seconds) to query data from the database and display them.




Access Permission

The hotel management system has to provide several types of access permissions.





4



Security Requirements

Only the system admin
istrator should be able to grant/remove permission access to employees.
Information passing between a client application and a service shall be encrypted using SSL
protocol to reduce the chances of tampering by a third party who is monitoring the network.




Implementation

The standalone software should be developed in C#. The RDBMS has to be MySQL. The main
server has to be located in the Server room, in the hotel’s building. Extra hardware facilities (for
instance external HDDs) should be present to back up

database information as described above.
The web application should be developed in PHP.


REFERENCES

For a full list of functional and non
-
functional requirements please check with the
“Requirements” handout issued on the 10.08.2012.







5

3

SYSTEM
ARCHITECTURE


Architectural d
esign

The following section documents the system design model (high
-
level). The class diagram
from the analysis phase was redesigned. Classes with working on a common function of the
application were placed in one subsystem.
The classes and subsystems were organized having in
mind the implementation of high cohesion and low coupling.

(fig.1)


Decomposition description

The main application is composed of five subsystems. Each subsystem had a functionality of
its own, independen
t of other subsystems.

The GUI subsystem is the user interface with which the user can interact with the system.
The content consists of four packages; the
mainWindow
,
Content
,
LoginDialog

and
Tab

classes.

Control objects handle the flow of operations bet
ween boundary and entity objects. The
Control Subsystem encloses all control classes which control these operations. Included

in the
following
diagram

(fig. 1)

are the
FinanceController
,
DatabaseConnector
,
HotelOrganisationController
,
SystemUserController
, and
Access

objects.

The
Finance

package encapsulates all functions that deal with the issuing of receipts and
payment procedure.

The
SystemUsers

package deals with users who interact directly or indirectly with the system.
The object Person acts as a
su
per class

for both
Staff
and
Guest

objects and is indicated as such.

Objects
Booking

and
Room

which have no direct connection to the functionality of the
other subsystems are located within the
HotelOrganisation

package.



6


Figure
1

System design model



7

The

diagram

below (fig. 2)

depicts

a coarse
-
grained

full scale system structure.



Figure
2

Coarse
-
grained

system structure



8

4

HARDWARE/SOFTWARE MA
PPING


The deployment diagram

(fig. 3)

shows how users will connect to the system. They will need
to do this from a site, every browser will be supported. People will use the GUI to enter. Then,
according to the level of authorization, one will have different options to do


if client, booking
,
feedback, etc. Same goes for employees. All subsystems are going to be related to the database,
because we need all kinds of information for our storage.





















Figure
3

Deployment

diagram



9

5

ACCESS CONTROL AND
SECURITY


Depending on level of authorization, one will acquire the respected operations. We will be
using Access Control List Realization. Every account is going to be created in conjunction with
the necessary operations for it, so whenever one logs in, t
he necessary information will pop up.























Figure
4
Access matrix



10

6

B
OUNDARY CONDITIONS


During this activity, additional

administrator

(here: Top level Manager)

use cases

are
described
.

In order to manage startup

and shutdown sessions, user must have administrative
rights which means only admin user type can start and shutdown the server.

Once
the startup
process

is

completed,
the users

shall be able to

use the system.
Whilst

shutdown process is
initiated users
s
hall

not able to use the system.

Bearing in mind that our system has t
wo

major
parts : the server
-
side and the

client
-
side, each use case narrative is followed by additional table
that describes in details the boundary conditions.


6.1

STARTUP
B
OUNDARY
C
ONDITI
ON

Use case n
ame

Start

System


Actor

Top level Manager

Entry condition

The computer serving the system
boots

into the operating system.

Exit Condition

The connection to MySQL is established

Flow of events

User runs the HMS

The MainWindow is activated

T
he script connects to the MySQL server

Table 1
-

Startup use case

Additional

explanatory case
:

Client
-
side

operationN
r

Operation

Pre
-
condition

Comments

1

Boot the front desk computer

None


2

Connect to the intranet

1

The OS automatically connects the
computer to the internet so that it
can communicate with the
database.

3

Run the
Palace HMS


1

The useart initiates the software.


Table 2
-

Startup use case

(client
-
side)




11

Server
-
side

operationNr

Operation

Pre
-
condition

Comments

1

Boot the Database Server

None

DB is

booted
before

start
ing

the
DBMS service

2

Start the DBMS service

1



3

Boot the Application Server

None

Application server
is initiated

4

Start the

HMS application

2, 3

Now the
system

can be used

Table 3

Startup use case (
s
erver
-
side)


6.2

SHUT DOWN

BOUNDARY CONDITION

Use case name

ShutDown
System

Actor

Top level Manager

Entry condition

The system is running and an event that requires system to shut down
is triggered

Exit
Condition

The connection to MySQL is
disabled

and application is terminated

Flow of events

The user terminates the front end application

The script shuts down the MySQL server

The MainWindow is closed

Table 4
-

S
hutdown
use case


Additional explanatory c
ase:


Client
-
side

operationNr

Operation



Pre
-
condition

Comments

1

Close the application

None


2

Shut down computer

1


Table 5
-

Shutdown use case (client
-
side)



12

Server
-
side

operationNr

Operation

Pre
-
condition

Comments

1

Close the application

None

The
application is closed

2

Close the
DBMS

1

The DBMS is closed

3

Shut down Database server

2

Shut down the
database

server

Table 6
-

S
hutdown

use case (server
-
side)



6.3

EXCEPTIONS

The Palace HMS can experience
the below described

types of system failures during its
operation:


Exception 1
: If either server fails to launch, a diagnostic message is printed and the
appropriate error log is updated

Exception 2
: Errors occurring while system is shutting down will be saved in an error
log

Exception 3
: An unexpected server failure, which leads the System to be terminated in an
unexpected way

Exception 4
: Network failure that will cause the interruption between MainWindow (GUI)
and MySQL server

Exception5
: Network failure that will cause

the interruption between System (The Palace
Server) and the WebBrowser.

“The Palace” system

handle
s

network failures that interrupt connections between
the
MainWindow (front
-
desk GUI or WebBrowser)
and the System (The Palace Server) by
acknowledging the
user of the network
/connection

failure.
However, unexpected crashes may
occur and the server may be forced to shut down. To prevent data loss, back up operations will
be performed by the system in a specific time period, specified by the Top level Manager.







13

7

GLOBAL SOFTWARE CONT
ROL




As shown in the System architecture diagram (fig. 1)

the subsystems

that compose our
system

are:

HotelOrganization, SystemUsers, Finance subsystems, also Control and GUI
subsystems.
These subsystems were determined through t
he use
-
case
-
based collaboration
diagrams

(presented in the last deliverable).

The objects in
the latter diagram

communi
cate
frequently with each other and
are related to each other, and

they were placed in a same
subsystem because they have
high coupling.

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.
The major three subsystems
(HotelOrganization, SystemUsers and Finance
)
are

composite subsystems because
e
ach
o
f

them
controls a given aspect of the system. They encapsulate the objects they contain. The
communication betwe
en the three subsystems is loosely coupled asynchronous message
communication.


The “Palace” Management System is a multi
-
client web
-
based application. The key idea
of the system is ensuring scalable performance and simultaneous operations for more than
one
user. To support the simultaneous accessibility by many users at the same time, the global
control of flow is event
-
driven with threads. To comply with the event
-
driven control of flow
principle, all operations will be controlled by the system through
their session id. The system will
control all operations by session id. The typical pattern should be as follows



At first, user sends a request to the server from the browser, or at the same time the
receptionist from his/her own terminal



Web server
creates unique threads for every system user’s action



Server

concurrently responds to browser of related user










14

8

PERSISTENT DATA DESI
GN

Database descriptions

In the following section the database design will be visualized using the Entity
-
Relationship
(E/R) diagram. For the most part, the Database design is based on the already existing class
diagram. The associations and classes of the class diagram were implemented as tables and
relations between the tables in the E/R diagram. The necessary tables nee
ded to complete the
relations between tables were added. Important to note is the implementation of Guest and staff
as an inheritance of the Person table.

(fig.

5)

The f
ollowing SQL code
is used
to create the necessary tables and relationships.


CREATE TAB
LE Item (ItemID int(10) NOT NULL AUTO_INCREMENT, ItemName varchar(35)
NOT NULL, ItemPrice int(10) NOT NULL, ItemTax int(10) NOT NULL, PRIMARY KEY
(ItemID));

CREATE TABLE Receipt_has_Items (ItemItemID int(10) NOT NULL,
ReceiptReceiptNumber int(10) NOT
NULL);

CREATE TABLE Booking_has_Receipt (ReceiptReceiptNumber int(10) NOT NULL,
BookingBookingNumber int(10) NOT NULL);

CREATE TABLE Receipt (ReceiptNumber int(10) NOT NULL AUTO_INCREMENT, `Date` date
NOT NULL, Status varchar(10) NOT NULL, TotalAmount int(
10), PRIMARY KEY
(ReceiptNumber));

CREATE TABLE Guest_has_booking (GuestGuestID int(10) NOT NULL,
BookingBookingNumber int(10) NOT NULL);

CREATE TABLE Booking_Room (BookingBookingNumber int(10) NOT NULL, RoomRoomNumber
int(10) NOT NULL);

CREATE TABLE Room
(RoomNumber int(10) NOT NULL AUTO_INCREMENT, RoomType
varchar(15) NOT NULL, Floor int(10) NOT NULL, Size int(10) NOT NULL, MinibarStatus
varchar(25) NOT NULL, CleanedStatus binary(1) NOT NULL, PRIMARY KEY (RoomNumber));

CREATE TABLE Booking (BookingNumber
int(10) NOT NULL AUTO_INCREMENT, CheckInDate
date NOT NULL, CheckOutDate date NOT NULL, BookingDate date NOT NULL, PRIMARY KEY
(BookingNumber));

CREATE TABLE Staff (StaffID int(10) NOT NULL AUTO_INCREMENT, PersonGuestID
int(10) NOT NULL, Username varchar(2
5) NOT NULL UNIQUE, Password varchar(25) NOT
NULL, AuthorisationLevel varchar(15) NOT NULL, PRIMARY KEY (StaffID));

CREATE TABLE Guest (GuestID int(10) NOT NULL AUTO_INCREMENT, PersonGuestID
int(10) NOT NULL, CardNumber int(10), CardHolder varchar(50), Ban
kName varchar(30),
BIN varchar(20), PRIMARY KEY (GuestID));

CREATE TABLE Person (GuestID int(10) NOT NULL AUTO_INCREMENT, Prefix varchar(10)
NOT NULL, Firstname varchar(20) NOT NULL, Surname varchar(50) NOT NULL, DoB date
NOT NULL, Street varchar(50) NOT N
ULL, HouseNumber varchar(5) NOT NULL, City
varchar(25) NOT NULL, Country varchar(30) NOT NULL, ZIP varchar(7) NOT NULL,
TelephoneNumber varchar(30), Email varchar(50), PRIMARY KEY (GuestID));





15


Figure
5

E/R diagram



16

9

SUBSYSTEM SERV
ICES

“The Palace” management system is composed of 5 subsystems and a database server.

Our first subsystem will be the first thing people are going to see


the graphic user interface. Via
main window login, one will input credentials in order to proceed.
This is going to be the first
part of our whole system.

After that, one will be redirected by our control subsystem towards the functionality one can
do. This is going to be the place that will decide what type of access control will be allowed to a
certai
n person.

SubsystemUsers is going to provide necessary information about our clients (users) and staff
members.


Finance subsystem is going to deal with the financial part of the business. It will have a class
related to receipt and accruing some addition
al costs to it. In addition, the receipt is going to be
related to another class that is reserved for different way of payments.

HotelOrganization

subsystem has 2 classes. One is concerned with the booking that one
might create, edit, delete, etc. The other class is necessary for the rooms and their statuses


this
is going to be the main service of this subsystem, as well.

The database will hold a
ll of our information together. It will have guest, booking, room, staff,
receipt items, mainly.











Figure
6
Subsystem services

diagram