宾馆住宿管理系统.docx

宾馆住宿管理系统.docx

《宾馆住宿管理系统.docx》由会员分享，可在线阅读，更多相关《宾馆住宿管理系统.docx（21页珍藏版）》请在冰豆网上搜索。

宾馆住宿管理系统

课程设计报告

学生姓名:

学号：

学院:

班级:

题目:

宾馆住宿管理系统

指导教师：

职称:

2011年7月15日

1.选题背景1

1选题背景

UML是OOA和OOD的常用工具。

使用UML来构建软件的面向对象的软件工程的过程，就是一个对系统进行不断精化的建模的过程。

这些模型包括用例模型、分析模型、设计模型等。

在我国，宾馆分成五星级、四星级、三星级、二星级和一星级。

客房和餐饮方面的管理也随着宾馆的星级不同而有所不同，但大体上是相同的。

宾馆在正常的运行中需要对客房资源、顾客信息、结算信息进行管理，利用宾馆信息管理系统及时了解各环节中信息的变更，有利于提高管理效率。

信息社会的高科技，商品经济的高效益，使对计算机的应用得到普及。

计算机虽然与人类的关系越来越密切，但还有人由于计算机操作的不便而使用手工进行管理。

为了适应现代社会高度强烈的时间观念，宾馆管理系统软件为管理人员带来了极大的方便。

通过操作手册，使用者可以了解本软件的基本工作原理。

操作人员只需输入一些简单的汉子，数字，即可达到自己的目标。

对于大中型宾馆来说，利用计算机支持高效率的完成日常事务，是适应现代要求、推动管理走向科学化、规范化的必要条件，而且宾馆管理又是一项非常繁琐的事情，数量大，核算极其不便。

同时计算机具有手工管理所无法比拟的优点。

例如：

检索迅速，查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。

这些优点能够极大地提高宾馆管理效率，也是宾馆的科学化正规化管理，与世界接轨的必要条件。

宾馆管理需要对顾客预定房间、入住和离店期间的一切服务进行管理，并存储宾馆客房的所有静态信息和动态信息，并且严格服从有关规定，按一定的模式或规律进行。

体现数量大，数据流清晰，规范的特点，因而特别适用计算机管理，宾馆管理内部从业人员中存在不少人对计算机管理系统比较陌生，对计算机的使用有一定的畏惧心理。

这就要求面向宾馆的计算机管理系统能够尽可能在功能设计上和手法上模拟现实情况，让用户使用时感觉熟悉、踏实、容易接受，否则会导致强烈的抵触心理。

宾馆管理系统要对客房资源、顾客信息、结算信息进行管理，实现宾馆管理的自动化，并利用宾馆管理信息系统及时了解各个环节中信息的变更。

有利于提高管理效率，否则无法满足宾馆方便、快捷的需求，这对软件使用和运行效率、稳定性都提出了更高要求。

2宾馆住宿管理系统需求分析

2.1宾馆住宿管理系统需求陈述

随着外出人流因为生活，商业等方面的增多，宾馆的发展也日益迅猛，由于顾客量的增多，顾客登记时间的广泛，宾馆收益的日益增多，仅仅依靠老式的手写输入记账法，是无法满足宾馆的需求。

同时这也很浪费时间和人力资源。

开发这个系统目的在于能够更好的对客房预订情况，空余情况，顾客信息，顾客住宿时间和所用费用，客房房态等进行精确的查询，以便更好的完善和更新宾馆住宿管理系统。

经过开发者同客户的需求分析后，确定酒店客房管理系统的功能模块（用例）包括：

用户信息维护、客房类型维护、客房信息维护、客房经营维护、客户信息维护、经营状况统计。

酒店系统完全采用Web方式，由前台和后台管理两个部分组成。

前台作为与用户直接交互的可视化界面，由于使用方便，能将系统的各个功能提供给用户，以帮助用户进行客房管理。

前台在考虑功能实现的同时，也考虑了操作的简洁和方便性。

为了确保客户和酒店的信息具有更好的安全性，前台管理和后台管理是分离的。

前台的各管理模块需要经过权限授权才可以使用，我们为此设计了两个角色：

一是系统管理员，二是接待员。

其中：

酒店管理员享有最高权限，可以使用酒店客房管理系统所提供的所有功能，包括员工信息维护、客房类型维护、客房信息维护、客户信息查询、经营状况统计、个人密码修改以及注销功能。

前台服务员的主要职能是负责订房和退房，以及查询入住的客户信息。

所有该角色只可以使用部分功能，包括客房经营管理、客户信息查询、个人密码修改以及注销功能。

后台管理主要由数据库系统作为支持，后台管理的维护工作主要由系统管理员进行，包括完成对各个数据表单的维护、数据库的备份及恢复等工作。

2.2宾馆住宿管理系统需求分析

2.2.1系统功能需求分析

客房信息系统可分为两大块:

数据库的后台管理和前台旅客住宿管理。

后台管理主要维护数据库的基本信息,如各类代码,操作员帐号,客房信息。

前台管理主要用于原始数据的采集,即客户入住和预定等信息,为最后的统计报表提供了数据基础。

后台管理包括以下部分:

（1）客房信息的输入:

包括每间客房的大小级别,地理位置,预设租金等信息。

（2）客房信息查询:

用于及时掌握客房情况,并且协助作出决策。

（3）前台操作员管理:

用于设置前台操作员的密码和基本信息。

（4）统计报表:

将各类信息进行统计,从而支持决策系统。

前台管理包括以下部分:

（1）客房的预定:

处理各类客户的预定请求。

预定可以通过各种方式,如电话,e-mail,传真等前

台需要根据当前客房情况,及时反馈给客户预定结果。

（2）登记入住:

当客户实际入住时,需要及时登录客户信息,以便今后查询。

（3）客房查询:

可以根据各种信息查询房客是否入住以及入住的情况。

（4）收费管理:

包括入住时的定金,各类其他消费情况和最终的结帐管理。

2.2.2性能需求

本系统使用UML建模技术，对宾馆住宿管理系统进行分析与设计，使开发的系统方面用户的使用和维护，根据宾馆管理工作性质和环境决定了本系统在性能方面要达到以下要求。

（1）系统响应时间：

要求系统最长响应时间不得超出5秒钟。

（2）系统最大并发用户数：

每次最少可同时兼容5个用户，最大8个用户。

（3）界面友好性：

要求系统提供统一的操作界面和方式。

要求操作界面美观大方、布局合理、功能完善，对于初级用户容易上手。

（4）服务个性化要求：

系统针对不同级别的用户提供方便的界面形式，以满足用户需求。

2.3系统需求建模

系统需求建模的分析几乎在任何情况下都需要使用用例，通过用例可以获取用户需求，规划和控制宾馆住宿管理系统项目。

获取用例是需求分析阶段的主要工作之一，而且是首先要做的工作。

大部分用例将在项目的需求分析阶段产生而且随着开发工作的深入还会发现更多用例。

创建用例模型的工作包括：

定义系统、寻找参与者和用例、描述用例、定义用例之间的关系、确定模型，其中关键是寻找参与者和用例。

2.3.1确定参与者

经过对系统需求的分析，确定系统中有两个参与者：

系统管理员、接待员。

参与者的描述如下:

1.系统管理员：

负责设置权限、密码设置等工作。

2接待员：

负责客房信息管理，客户住宿与退宿信息管理。

2.3.2确定用例

前面已经识别出了参与者，通过对需求的进一步分析，可以确定系统中有如下用例存在。

从用例图中我们可以看出系统管理员和接待员对本系统所具有的用例。

系统管理员所包含的用例有。

1.权限设置。

管理员可以设置用户的权限；

2.密码设置。

管理员设置登录系统的密码；

3.客房设置。

管理员可以设置客房的信息显示形式；

4.操作员设置。

管理员设置系统操作员的操作范围。

接待员所包含的用例有。

1.客房查询：

接待员能够进行客房信息的查询，以便判断顾客是否可以入住，同时也为顾客提供选择条件。

2.住宿登记：

接待员要对顾客入住信息进行及时登记，包括时间，顾客个人信息的登记。

3.调房登记：

如果顾客要求调换房间，那么接待员将要负责换房信息的登记。

4.退宿结账：

顾客结束入住，在离开之前接待员要负责退宿结账工作，显示住宿信息，根据时间天数与单价等条件进行宿费结算。

5.挂账查询：

如果顾客或管理员要求查看挂账信息，那么接待员必须从系统中调出挂账的信息。

8.住宿查询：

接待员能够从系统中查询所用顾客的住宿信息，包括时间，天数，入住客户的个人信息等。

7.退宿查询：

接待员也必须能够查询顾客退宿的所有信息，包括退宿时间，是否结账等信息。

2.3.3系统用例建模

住宿与退宿是由客户执行的，但是对于软件系统来说，这些操作是由接待员与系统进行交互完成的，也即用例客户的住宿与退宿及调房实际上是与接待员交互的，在参与者“住宿”和参与者“退宿”与接待员之间存在着依赖关系，为了系统的安全性，系统还需要提供进行身份验证的功能，以确保只有具有权限的“接待员”才可以使用系统的功能，所以“接待员”必须与用例“登录”交互，即“接待员”在使用系统前，要使用用户名和密码进行登录，系统验证用户的密码正确后，用户才可以执行进一步的操作。

图2.1系统总体用例图

2.3.4用例描述

用例的事件流图是对完成用例行为所需的事件的描述。

事件流图描述了系统应该做什么，也就是说，事件流图描述是用域语言描述的，而不是用实现语言描述的。

宾馆住宿管理系统的用例的事件流描述如下：

1．权限设置：

管理员可以设置用户的权限；

2．客房设置：

管理员可以设置客房的信息显示形式；

3．客户管理：

接待员对客户的入住信息与退宿结账信息进行管理。

4．客房管理：

接待员可以为客户提供客房信息。

3宾馆住宿管理系统分析

3.1系统用例建模

作为描述系统的用户或参与者所能操作的图，它在需求分析阶段有着重要的作用，整个开发过程都是围绕系统的需求用例表述的问题和问题模型进行的。

所用到的执行者有：

系统管理员和接待员。

下面对本系统中的相关用例进行描述。

（1）系统管理员可以通过以下活动对系统进行管理

设置权限：

管理员可以设置用户的权限；

密码设置：

管理员设置登录系统的密码；

操作设置：

管理员设置系统操作员的操作范围；

客房设置：

管理员可以设置客房的信息显示形式。

（2）接待员员可以通过以下活动对宾馆进行管理

客房查询：

提供客房的信息，如大小，是否空闲，租金等给管理员或顾客。

住宿登记：

接待员及时对入住的顾客信息进行登记。

调房登记：

接待员为客户进行调房服务。

退宿结账：

顾客结束入住，在离开之前接待员要负责退宿结账工作，显示住宿信息，根据时间天数与单价等条件进行宿费结算。

挂账查询；如果顾客或管理员要求查看挂账信息，那么接待员必须从系统中调出挂账的信息。

住宿查询；接待员能够从系统中查询所用顾客的住宿信息，包括时间，天数，入住客户的个人信息等。

退宿查询：

接待员也必须能够查询顾客退宿的所有信息，包括退宿时间，是否结账等信息。

图3.1系统总体用例图

图3.2系统详细用例图

3.2静态结构模型

3.2.1类的识别

可以根据系统需求识别出系统中存在的类。

系统类的识别可以通过寻找系统域描述和需求描述中的名词来进行。

1.找出候选类

从前述的系统需求描述中可以找到的名词有：

系统管理员，接待员，客户，房号，客房，租金，入住率，满意率，天数，日期，押金，身份证，姓名，编号，密码，账单，发票，顾客，记录，结账管理，床铺等。

2.筛选正确类

接下来要从中去掉不正确的、不必要的，仅保留确实应该记录的类。

按照如下标准进行筛选

a.冗余

如果两个类表达了同样的信息，则应该保留在此问题中最富于描述力的名称。

此系统中“客户”、“顾客”、描述相同的信息，因此应该用“顾客”。

b.属性

在需求陈述中有些名词实际上描述的是其他对象的属性，应该把这些名词从候选类中去掉。

此系统中“房号”、“租金”、“入住率”、“满意度”、“天数”、“日期”、“押金”、“身份证”、“姓名”、“编号”、“密码”、“账单”、“发票”、“顾客”、“床铺”等，都应该作为属性。

综上所述，经过初步的筛选剩下的类有:

记录，顾客，客房，接待员，系统管理员，结账管理。

3.2.2类的关联分析

两个或多个对象之间的相互依赖、相互作用的关系就是关联。

分析确定关联能促使分析员考虑问题域的边缘情况，有助于发现那些尚未被发现的类。

对于宾