酒店住房管理.docx
《酒店住房管理.docx》由会员分享，可在线阅读，更多相关《酒店住房管理.docx（20页珍藏版）》请在冰豆网上搜索。
酒店住房管理
1前言
随着经济的迅猛发展，第三产业在国民经济中扮演着越来越重要的角色。
而随着近年来我国旅游行业的不断扩大，酒店行业的发展趋势不断看涨。
旅游业的持续火热随之而来的是酒店需求的剧增。
酒店行业的不断扩大，面临的问题也就越来越多。
对于任何一个有一定规模的酒店来说都需要有与之相媲美的管理系统。
酒店经营管理面临着越来越高的要求，一个高质量的管理信息系统不仅会为酒店创造更多的经济效益，更关系着酒店的整体形象跟运作效率，为酒店本身及顾客带来更多的利益。
酒店客房管理系统是根据酒店对客房管理的实际情况进行编写的，主要目的是为了方便酒店对客房的实际情况进行集中的查询与管理工作，以提高整个酒店的工作。
酒店客房管理的科学化、系统化、信息化成为各个酒店追求的目标。
因此，而要实现这些功能，就要求各个酒店配备一套客房管理系统，以便在酒店内实施良好、完善的管理且以最快地速度响应客户的需求，及时为他们提供服务，为他们提供一个高效、便捷的居住环境。
客房管理信息系统（MIS）是各个酒店软件建设中一个重要的应用系统，它大大了改善酒店管理的基础环境。
目前酒店客房管理系统大多采用传统的C/S体系结构，所以本系统也是采用C/S结构，并基于数据库单位系统开发，所以本文是对系统的一个在结构、功能、面向对象、数据库等方面对系统进行了详尽的阐述。
本文的系统采用“自上而下地总体规划，自下而上合自上而下综合运用地应用开发”的策略开发一个管理信息系统的过程。
通过分析某一酒店客房管理的不足，创建了一套行之有效的计算机管理酒店客房的方案。
文章介绍了酒店客房管理信息系统的系统分析部分，包括需求分析、可行性分析等；系统设计部分主要介绍了系统功能设计和数据库设计；
2需求分析与用例建模
2.1可行性分析
2.1.1技术可行性
建立一个完善的酒店住房系统，要对酒店行业的系统结构、流程运转等方面个整体的了解。
可行性分析的目的是用最小的代价在尽可能短的时间内确定问题是否能够解决。
可行性研究的目的不是解决问题，而是确定问题是否值得去解决。
通过需求分析，逐步细化对软件的需求，描述软件要求处理的数据库，并给软件开发提供一种可能转化为数据设计，结构设计和过程设计的数据与功能表示。
在软件完成后，指定的软件需求规格说明还要为评价软件质量提供依据，准确的表达所接受的用户要求，是需求分析的另一个重要的方面。
有经过确切描述的软件需求才能成为软件设计的基础。
硬件方面，我们目前拥有了计算机硬件设置，有了WindowsXP的运行环境，提供了WindowsXP的工作平台，安装了开发软件，包括运行平台的、数据库的和各类编程工具的，在编程环境上提供了可靠的支持，为系统的开发提供了必要的技术保障。
软件方面也有相关的软件可提供用于开发，如C#、JAVA等相关语言都可用于面向对象的系统开发，这些现在都具备，所以，在技术上是可行的。
2.1.2经济可行性
系统开发所需的费用是比较低的，由于系统并不复杂，其运行费用也不会占用很多资金，同时无需培训费用，编者可以直接应用软件进行编程，并且可以预见系统完成后的作用，所带来的效益远远大于系统软件的开发成本。
由此可见系统在经济上是可行的。
2.1.3社会可行性
目前市场上适用于中小型酒店的客房管理系统还没有形成商品型的产品，所以这样的产品是供不应求。
这种相对简单的系统需要的开发环境要求低，技术也相对简单，所以对于普通的开发人软就可以进行开发。
由于系统是面向对象的，用户使用起来会更加的方便，系统也趋于人性化。
且本系统的开发为初级任何法律上的问题，遵守国际国内上通用的法则，因此在社会上是可行的。
2.2需求分析
为了了解系统的确实功能，我们必须要对系统的功能进行详细的分析，最重要的是要做好系统的需求分析，需求分析是软件生命周期中的一个重要的阶段，也是开发系统首先要做的第一步工作，客户需求是系统开发的源泉，系统要做什么，都是由需求得来的，尤其是系统必须具有的功能和性能，系统要求的运行环境，以及预测系统发展的前景。
同事需求分析也要做到和客户进行详细的交流，准确听取客户的建议和意见，以此来确定系统的功能。
首先，在现在大多数的酒店没有或只有简单的计算机管理系统，工作效率很低，这也影响了服务的质量，同时增加了经营成本，从网上搜集相关软件的销售情况，我们可以清楚地看到，现在适合中小型酒店客房管理的系统很少，大多数的客房管理系统都是针对大型或是连锁性的酒店设计，所以针对中小型客房管理的系统现在是供不应求，因此从这个角度来看，这个系统的开发是很有价值和潜力的。
其次，酒店客房管理软件的需求量大，酒店客房管理软件市场刚刚起步，能够提供产品的企业较少，能够做到通用和有影响力的产品几乎没有，与此同时，酒店和旅馆等的数量正在急剧增加，传统的管理方式已不能适应当前的要求。
在调查中，绝大多数酒店都表示需要一种高度信息化的管理方式，以提高管理水平，进而提高服务质量，保留和增加用户的数量。
2.3需求分析结果
通过上面的需求分析我们得出结论，当前人们生活的节奏越来越快，对生活的质量要求也越来越高，因此出外旅游时对客房的要求也随之增高，服务快速、高质量时客户满意的一个重要前提，由此便大大促进了客房管理系统的开发和使用。
同时，酒店、客房机构的绝对数量很大，但相对数量不足，因此具有很大的发展空间：
在已建立的客房机构中采用信息化管理的很少，并且都集中在几家外资和合资的大型酒店里，而这些大型酒店在全国的分店最多不过百家。
由此可见，市场对酒店客房管理软件产品的需求是很大的，此此项目具有很好的商业前景。
2.4系统目标
由以上分析可以得到我们设计这个酒店客房管理系统目标是实现酒店客房管理的数字化、自动化、快速和清晰化，同时实现良好的人——机对话功能，提高经营效率，最大限度的实现经营自动化、一体化。
2.5用例建模
（1）图1是酒店客房管理的顶层用例图，包括整个系统的全部功能管理。
在这个用例中有两个执行者，分别是酒店管理员和前台服务员。
酒店管理员就行系统管理、客房信息管理、客户信息管理和经营状况管理。
其中系统管理包括用户信息管理和数据备份和恢复；客房信息管理包括客房类型管理和客房资料管理；客户管理酒店管理员只能对客户信息进行查询；经营状况管理包括营业额统计管理和营业额查询。
前台服务员在系统管理中只能修改自己的密码，在客房信息管理中只能查询和查看客房资料信息，在客户信息管理中则要对客户的预定、入住、退房、换房进行管理，同时还可以根据客户要求查询和修改客户资料。
图1酒店客房管理系统最高层用例图
（2）图2是系统的系统管理子系统用例图，属于第二层用例图。
在该图中有两个执行者，分别是酒店管理员和前台服务员。
酒店管理员能够对本月或历史月份数据进行备份和恢复，当用户信息有变动时更新（添加、删除、修改）用户信息列表，同时可以查询和浏览用户信息。
而在这个子系统中前台服务员只能修改个人密码。
图2第二层——系统管理子系统用例图
（3）图3是属于第二层用例图的客房信息管理子系统用例图，在该用例图中有两个执行者：
酒店管理员和前台服务员，2个用例：
客房类型管理和客房资料管理。
酒店管理员对每个用例都有更新、查询和浏览的权限，而前台服务员只能在使用时查询和浏览客房类型和客房资料。
图3第二层——客房信息管理子系统用例图
（4）图4是客户信息管理子系统，属于第二层的用例图，在这个用例图中一共包括两个执行者和六个用例，分别是：
酒店管理员、前台服务员、换房管理、退房管理、入住客房管理、预订客房管理，查询客户资料管理和修改客户资料管理。
在本子系统中，酒店管理员只能查询客户资料细心，其他的管理活动都是由前台服务员在日常经营活动中完成的。
换房管理可以发生在预定和入住两个管理活动中退房管理发生在客户已经入住的前提下，在预定管理中客户为取消预定。
入住客房管理和预订客房管理下属都有增加、删除、修改、查询和浏览相关信息的子用例。
图4第二层——客户信息管理子系统用例图
（5）图5是第二层的经营状况管理子系统的用例图，在该用例中只有酒店管理员一个执行者，包括两个用例，分别是营业额额统计和营业额查询。
酒店管理员在进行营业额统计时有生成统计营业额、删除统计营业额两个子用例，在营业额查询中有查询统计营业额和浏览统计营业额两个子用例。
图5第二层——经营状况管理子系统用例图
3系统分析与对象类建模
根据已经建立的用例图和客户需求，采用CRC卡的方法确定对象类及其属性和操作。
通过检查类的定义、分析问题的需求和运用该领域知识来完善和确定类的属性。
根据系统功能要求和系统设计需要完善和确定类的操作。
下图便是根据系统的用例图和系统分析得出系统类图。
在本系统中假设值存在一个管理员，所以在系统类图中一个酒店管理员可以同时管理多个前台服务员，同时也对多个客房、多月也就是整个的经营状况统计进行管理，这个管理中包括更新和查询、浏览功能。
酒店管理员对于客户资料只存在查询和浏览的功能，一个酒店管理员可以查询和浏览多个客户资料。
对于前台服务员来说，多个服务员同时被一个酒店管理员管理，但一个服务员具备同时管理多个客户资料的功能，这其中包括日常经营的全部过程，有客户的预订客房、入住客房、换房、退房、查询客户资料、修改客户资料等，同时预订客房、入住客房、换房、退房等每个子功能下面又都存在增加、删除、修改、查询、浏览等子功能。
对于客房来说，前台服务员只能在日常经营时查询所需要的客房类型和资料或者浏览客房类型和资料。
对于经营状况统计来说，前台服务员不具备任何权限查看或更新。
图6系统类图
4系统设计和顺序图建模
4.1系统功能设计
在需求分析与可行性分析中我们已经得到系统的设计目标，所以可以初步设计系统具有系统管理功能模块、客房信息管理功能模块、客户信息管理功能模块、经营状况管理管理功能模块等。
该系统的功能能够实现酒店客房日常业务管理的功能需要，包括客房类型管理、客房资料管理、客户在平常的住宿过程中使用客房所产生的费用，相关信息的查询以及前台服务员的信息进行管理，并且也具有用户密码以及系统权限的设置等，实现酒店客房管理的自动化、数字化，提高健身房管理的高效率和高质量。
由以上分析得到的功能模块可以得到如下的功能模块图7所示：
图7系统功能结构图
4.2顺序图建模
顺序图是描述对象间的交互行为，它注重消息的时间顺序，即对象间消息的发送和接受的顺序，顺序图还揭示了一个特定场景的交互，及系统执行期间发生在某个时间点的对象之间的特定交互，它适合描述实施系统中的时间特性和时间约束。
由此对本系统的信息流进行分析，即可得相关的顺序图，以下便是一些代表性的顺序图。
（1）如图8是一个描述管理员更新用户信息的顺序图，在这个图中，酒店管理员发送更新（添加、删除、修改）等信息到用户数据库中，与数据库中的用户信息列表进行交互，修改或删除或添加用户信息，更新完成后返回新的用户信息对象，用户数据库对更新完成的用户信息进行存储，最后用户数据库返回更新完成的新的用户信息对象。
诸如酒店管理员更新客房类型，酒店管理员更新客房资料等信息流的传递都与此类似，故在此只画出一个代表。
图8更新用户信息顺序图
（2）图9是酒店管理员查询用户信息的顺序图，在这个顺序图中我们可以看到，酒店管理员输入要查询用户的信息或代表该用户唯一性的主键到用户数据库中，并与之发生交互，系统从用户信息列表中正确的用户信息并返回查询对象给酒店管理员。
诸如此类的还有，酒店管理员查询客房类型、客房资料、用户资料，营业额等。
图9查询用户信息顺序图
（3）图10是表示客户入住客房活动的顺序图。
前台服务员先查询可用客房，即先输入查询可用客房的消息到客房数据库，客房数据库从客房信息列表中找出可用客房的信息，返回可用客房对象到数据库，返回可用客房对象给前台服务员；前台服务员根据客户需要选择可用的客房，此时系统自动把客房信息中“可用”改为“不可用”修改完成，前台服务员输入客户的基本信息并在客户数据库中创建新的客户信息然后输入客户入住的相关信息，发送到入住客房数据库，更新入住客房列表完成后，返回客房入住客房对象到入住客房数据库并把其存储在入住客房数据库中，最后返回入住客房对象给前台服务员。
在完成入住客房对象之后，客户数据库存储新添加的客户信息对象，客房数据库存储修改后的客房信息对象。
图10入住客房管理顺序图
（4）图11是客户入住后要进行换房的顺序图。
首先前台服务员输入验证客户入住信息，与入住客户数据库进行交互，在入住客房信息中修改客房编号，修改完成后返回跟新完成的入住客房对象，并把其存入入住客房数据库中，返回更新完成的入住客房资料对象给前台服务员；之后系统会根据客户换房的信息对客房资料进行修改，与客房资料数据库交互，更新客房资料信息列表，返回更新完成的客房资料对象，并把更新完成的客房资料存入数据库。
至此该活动完成操作。
图11换房管理顺序图
（5）图12是客户在入住日期结束后退房活动的顺序图。
前台服务员输入客户的退房信息，与退房数据库进行交互，更新退房列表，完成后返回给前台服务员退房信息对象同时发送客户的消费金额至营业额统计数据库，并把营业额数据记录到营业额统计列表中，统计列表更新完成存入营业额统计数据库；完成后退房数据库会发送客户退房的信息到客房资料数据库中，在此把退房的房间状态修改为可用，更新完成客房资料数据库后返回更新完成的客房资料对象，并把更新完成的客房资料数对象存储到客房资料数据库中，最后返回更新完成的客房资料信息对象。
图12退房管理顺序图
（6）图13是酒店管理员统计营业额的顺序图。
酒店管理员进入经营状况管理窗口后，输入要统计的月份（一般为本月），与营业额统计数据库发生交互，更新营业额统计列表，得到统计出的月份和金额等信息，统计完成后返回营业额统计信息对象到营业额统计数据库并把更新完成的营业额统计信息存储到相应的数据库中，返回营业额统计对象给酒店管理员，至此营业额统计活动完成。
图13营业额统计管理顺序图
5数据库设计
5.1E-R图设计
酒店客房管理系统所涉及到的实体及转换成关系模式为：
酒店管理员（管理员编号，用户名，性别，密码，权限，备注）
前台服务员（服务员编号，服务员姓名，性别，密码，权限，备注）
客户（客户编号，客户姓名，性别，身份证号，备注）
客房（客房编号，类型编号，是否可用，备注）
实体之间的联系为：
管理：
一个酒店管理员可以管理多个前台服务员，一个前台服务员被多个酒店管理员管理，一个酒店管理员可以管理多个客房，一个客房可以被多个酒店管理员管理，一个前台服务员可以管理多个客房，一个客房可以被多个前台服务员管理，一个前台服务员可以管理多个客户，一个客户可以被多个前台服务员管理。
查询：
一个酒店管理员可以管理查询多个客户，一个客户可以被多个酒店管理员查询。
预定：
一个客户可以预定多个客房，一个客房可以被多个用户预定。
入住：
一个客户只能入住一个客房，一个客房入住多个客户。
根据以上关系描述，可以得到以下总E-R图：
图14系统总E-R图
5.2数据库表设计
（1）酒店管理员信息表的结构，如表1所示：
表1酒店管理员信息表
字段名
数据类型
说明
mid
char（8）
主键，非空，长度为4
mname
nvarchar（20）
长度为10
msex
char（4）
长度为2
mpassword
char（16）
长度为16
mpower
nvarchar（40）
长度为40
remark
nvarchar（100）
长度为100
（2）前台服务员信息表的结构，如表2所示：
表2前台服务员信息表
字段名
数据类型
说明
fid
char（8）
主键，非空，长度为4
fname
nvarchar（20）
长度为10
fsex
char（4）
长度为2
fpassword
char（16）
长度为16
fpower
nvarchar（40）
长度为40
remark
nvarchar（100）
长度为100
（3）客户信息表的结构，如表3所示：
表3客户信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
kname
nvarchar（20）
长度为10
ksex
char（4）
长度为2
IDnum
nvarchar（20）
长度为10
remark
nvarchar（100）
长度为100
（4）客房类型信息表的结构，如表4所示：
表4客房类型信息表
字段名
数据类型
说明
lid
char（8）
主键，非空，长度为4
lname
nvarchar（20）
长度为10
lprice
char（8）
长度为8
remark
nvarchar（100）
长度为100
（5）客房类型信息表的结构，如表5所示：
表5客房资料信息表
字段名
数据类型
说明
zid
char（8）
主键，非空，长度为4
lid
char（8）
长度为4
ifuse
bit
长度为2
remark
nvarchar（100）
长度为100
（6）换房信息表的结构，如表6所示：
表6换房信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
newzid
char（8）
长度为4
zid
char（8）
长度为4
changedate
datetime
长度为10
remark
nvarchar（100）
长度为100
（7）退房信息表的结构，如表7所示：
表7退房信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
zid
char（8）
长度为4
date
datetime
长度为10
days
int
长度为10
cost
float
长度为15
money
float
长度为15
remark
nvarchar（100）
长度为100
（8）入住客房信息表的结构，如表8所示：
表8入住客房信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
zid
char（8）
长度为4
begindate
datetime
长度为10
duedate
datetime
长度为10
remark
nvarchar（100）
长度为100
（9）预定客房信息表的结构，如表9所示：
表9预定客房信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
zid
char（8）
长度为4
yddate
datetime
长度为10
ydmoney
remark
nvarchar（100）
长度为100
（10）客户资料信息表的结构，如表10所示：
表10客户资料信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
kname
nvarchar（20）
长度为10
ksex
char（4）
长度为2
IDnum
nvarchar（20）
长度为10
zid
char（8）
长度为4
begindate
datetime
长度为10
duedate
datetime
长度为10
cost
float
长度为15
remark
nvarchar（100）
长度为100
（11）查询客户资料信息表的结构，如表11所示：
表11查询客户资料信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
kname
nvarchar（20）
长度为10
ksex
char（4）
长度为2
zid
char（8）
长度为4
begindate
datetime
长度为10
duedate
datetime
长度为10
cost
float
长度为15
remark
nvarchar（100）
长度为100
（12）修改客户资料信息表的结构，如表12所示：
表12修改客户资料信息表
字段名
数据类型
说明
kid
char（8）
主键，非空，长度为4
kname
nvarchar（20）
长度为10
ksex
char（4）
长度为2
IDnum
nvarchar（20）
长度为10
zid
char（8）
长度为4
begindate
datetime
长度为10
duedate
datetime
长度为10
cost
float
长度为15
remark
nvarchar（100）
长度为100
（13）营业额统计信息表的结构，如表13所示：
表13营业额统计信息表
字段名
数据类型
说明
tjid
char（8）
主键，非空，长度为4
tjmonth
datetime
长度为10
tjmoney
float
长度为15
remark
nvarchar（100）
长度为100
（14）营业额查询信息表的结构，如表14所示：
表14营业额查询信息表
字段名
数据类型
说明
cxid
char（8）
主键，非空，长度为4
tjid
char（8）
长度为4
cxmonth
datetime
长度为10
cxmoney
float
长度为15
remark
nvarchar（100）
长度为100
6总结
我们最常听的是“与其临渊羡鱼，不如退而结网”，课设就是给了我们一个很好的机会来实践自己心中所想的系统模样。
课程设计是培养学生综合运用所学知识,发现,提出,分析和解决实际问题,锻炼实践能力的重要环节,是对学生实际工作能力的具体训练和考察过程。
我们这次的课设题目是面向对象的系统分析和设计，实习时间是两周，因此我们都是揣着激动的心情去完成这个课设的。
两周的课程设计很快就过去，我们在这次的课设中也学到了很多东西，同时也发现了很多自身的问题。
平时老师上课所教授的很多知识点自己都没有掌握，很多知识点甚至一点都不懂。
我选择的是一个酒店客房管理系统，难度还不是很大，可是在最开始的系统模块设计时就出现可模块分的乱七八糟的问题，经过老师分析后才发现自己设计的功能模块有很大的问题，改正后才对系统的功能有了一个清晰的了解，这样也就为接着画系统的用例图和类图做好准备。
在画用例图时，用例之间的关系要理解清楚，用例的系统范围大小要确定合适，不要系统范围确定的太细致，这样会把本身简单明晰的系统复杂化，这样在画用例图时就会简单很多，在描述时也会简单一些。
在画类图之前最好先把数据库表整理出来，这样在画类图时会更清晰一点，基本上一个数据库便就是一个类。
顺序图就是对一个活动的消息传递顺序的描述，所以在画顺序图时一定要对自己的系统处理过程有一个深入的了解，这样才能画出正确的顺序图。
通过这次课程设计，我不仅对以前学的东西有了一个更深层次的了解，同时也学到了新的知识。
知识只有在实践中才能实现它本身的价值，我们在上课时学的知识只是理论上的，没有实践，我们对知识的掌握只能停留在表面层次，只有实践之后才能领悟其精髓。
以前上课就是听课和记笔记，不懂的地方就靠解答大量习题帮助记忆，学习的主要目的是通过最后考试。
课程设计使我们发现考试真的并不是最重要，最重要的是能运用所学的知识，在整个UML软件工程的学习过程中，我们突破
升级会员 