旅店住宿系统课程设计.docx
- 文档编号:9008158
- 上传时间:2023-02-02
- 格式:DOCX
- 页数:28
- 大小:652.03KB
旅店住宿系统课程设计.docx
《旅店住宿系统课程设计.docx》由会员分享,可在线阅读,更多相关《旅店住宿系统课程设计.docx(28页珍藏版)》请在冰豆网上搜索。
旅店住宿系统课程设计
信息系统分析与设计
课程设计报告
题目旅店住宿系统设计
目录
1前言2
1.1系统开发的必要性2
1.2.1经济可行性3
1.2.2技术上的可行性3
1.2.3时机可行性3
2.1系统的功能需求4
2.2.1基本数据维护模块5
2.2.2基本业务模块5
2.2.3数据库模块6
2.2.4信息查询模块7
2.2系统UML用例图8
2.2.1确定参与者用例8
2.2.2旅店员工参与的用例9
3分析工作流10
3.1提取系统的各种类,进行类建模10
3.1.1客户和员工类图11
3.1.3各个类之间的关系12
3.2系统的的活动图13
3.3系统的顺序图15
3.3.1客户预定房间的顺序图15
3.3.2客户删除订单的顺序图16
3.3.3工作人员处理预定订单的序列图17
3.4对系统功能进行划分,设计系统的包图18
4设计工作流18
4.1数据库设计18
4.2系统界面设计21
5总结25
6参考文献25
1前言
1.1系统开发的必要性
随着计算机硬件技术和系统软件技术的高速发展,计算机的应用系统开发就显得越来越迫切和重要。
对于不同行业的用户来说,要想真正让计算机为本行业本单位服务,主要还是取决于本行业的应用系统的开发水平。
对于旅店这一特殊的服务行业来说,旅店MIS(ManagementInformationSystem,管理信息系统)就成了帮助旅店全面实现计算机管理的关键。
近年来,我国的现代旅店业得到了蓬勃的发展。
无论是行业规模、设施质量,还是经营理念或管理水平,都取得了长足的进步,进入了现代化水平的阶段,出现了一大批旅店管理集团,旅店计算机管理作为我国旅游行业信息化建设中的重点实施项目,一直与知识、创新、才能、管理相伴而生、相行相随。
随着旅店管理的发展和市场竞争日趋激烈,各旅店逐步采用标准化、制度化及预算管理、目标管理、定额管理、数理统计分析等科学的管理方法,并采用计算机现代化办公及通讯设备,对旅店的人流、物流和资金流进行统筹规划,在旅店管理中开发并使用一套科学先进的旅店管理系统成为众多旅店的当务之急。
1.2可行性研究
可行性研究也称为可行性分析(FeasibilityAnalysis),是在系统调查的基础上,针对新系统的开发是否具备必要性和可能性,对新系统的开发从技术、经济、社会的方面进行分析和研究,以避免投资失误,保证新系统的开发成功。
可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
该系统的可行性分析从以下几个方面进行。
1.2.1经济可行性
主要是对项目的经济效益进行评价,本系统开发经费对于一般的旅店(中、小型旅店)在经济上是可以接受的,并且本系统实施后可以显著提高工作效率,有助于旅店的信息化管理,所以本系统在经济上是可行的。
1.2.2技术上的可行性
技术上的可行性分析主要分析技术条件能否顺利完成开发工作,软、硬件能否满足开发者的需要等。
该旅店管理系统采用了C/S模式进行开发,而且又紧密的结合了Intemet/Intranet技术,是技术发展的大势所趋,它把应用系统带入了一个崭新的发展时代。
数据库服务器选用SQLServer2000数据库,它能够处理大量数据,同时保持数据的完整性并提供许多高级管理功能。
它的灵活性、安全性和易用性为数据库编程提供了良好的条件。
因此,系统的软件开发平台已经成熟可行。
硬件方面,科技飞速发展的今天,硬件更新的速度越来越快,容量越来越大,可靠性越来越高,价格越来越低,其硬件平台完全能满足该系统的需要。
1.2.3时机可行性
目前国外的旅店信息化管理已经发展的很成熟,但国外系统在国内的使用过程中,由于旅店经营方式与管理模式上的差别,加之价格昂贵,越来越多的星级旅店更趋向于采用适合自身需要的国产旅店软件。
目前,国内市场上出现的各类旅店管理软件基本上都是为大型旅店专业设计的,很多功能对于中小型旅店不适用,一般价格也较昂贵。
而占着绝大多数的中小型旅店由于资金、人员等多方面原因还未使用旅店管理类软件,全凭原始的手工记录管理,效率低、易出错。
因此,为中小型旅店开发价格低廉、服务完善,功能齐全以及使用方便的管理系统已经刻不容缓。
综上所述,该系统开发目标已明确,在技术和经济等方面都可行,并且投入少、见效快。
因此,系统的开发是完全可行的。
2需求工作流
2.1系统的功能需求
系统的功能需求包括一下几个方面。
(1)客户能够通过不同的方式(包括电话、前台、网上)预定旅馆房间。
(2)能够保存客户的预定记录。
(3)能够保存客户的入住记录。
(4)工作人员可以处理客户的预定记录。
(5)工作人员可以访问旅店房间信息。
满足上述需求的系统主要包括以下几个模块。
(1)基本数据维护模块
基本数据维护模块提供了使用者录入、修改并维护基本数据的途径。
例如对客户个人信息、房间信息、入住信息等的录入和修改。
(2)基本业务模块
基本业务模块中,客户可以提出房间预定,而作人员负责录入预定记录。
同时,工作人员还可以提交每个房间的状态,以便工作人员可以根据这些资料决定为客户保留哪个房间。
(3)数据管理模块
在旅店住宿管理信息系统中,对所有的客户、工作人员以及房间的信息都要进行统一的管理,房间的使用情况也要进行详细的登记。
(4)信息查询模块
信息查询模块主要用于主要查询相关信息,例如工作人员查询房间旅店信息管理。
图2-1功能需求图
2.2.1基本数据维护模块
数据维护模块包括如图所示的几个方面。
(1)添加房间信息
旅店的房间信息需要保存到数据库,房间信息包括房间的类型、房间的号码和房间的状态。
(2)修改房间信息
房间被使用后状态会发生改变,要根据具体情况修改房间的状态,如预留、使用中和空闲。
(3)添加员工信息
公司员工信息应保存在系统数据库中,以便管理人员,根据员工的表现对员工进行考核。
(4)修改员工数据
员工服务满意率要保存在员工信息中,员工信息发生变化后,要更新员工的个人信息
②描述系统需求,运用建模工具画出相应的用例图,并对用例进行详细描述,用活动图描述参与者与系统的交互过程。
图2-2基本数据维护功能模块
2.2.2基本业务模块
基本业务模块包括如图所示的几个方面。
(1)用户提出房间预订请求
工作人员为客户录入预定记录。
(2)工作人员处理预订记录
工作人员要处理客户的预订申请,可以根据客户的要求(时间和房间类型)和目前房间的状况决定为顾客分配哪间房间。
(3)工作人员填写服务记录
旅店的工作人员要在客户退房后对房间进行彻底的清扫,清扫完毕以后要填写服务记录。
(4)工作人员处理退房请求
工作人员将根据使用房间的时间和会员的风机收取此次房间使用的费用。
如果房间的物品有损坏,还要收取一定的罚金,并更新客户的信息。
图2-3基本业务模块
2.2.3数据库模块
数据库模块包括如图所示的以下几个方面。
(1)客户信息管理
客户信息包括客户的基本信息外,还包括客户的入住历史记录。
(2)房间信息管理
房间信息包括房间的类型、房间的价格、房间的状态。
(3)房间的使用信息管理
房间的使用信息包括客户的预定记录和工作人员的服务记录。
(4)员工信息
员工信息包括工作人员、管理人员的基本信息以及工作人员的工作记录等。
图2-4数据库模块功能
2.2.4信息查询模块
信息查询模块包含如图所示的几个方面。
(1)查询客户信息
负责客户信息的查询。
(2)查询员工信息
旅店员工信息的查询。
(3)查询房间信息
负责公司房间信息的查询。
(4)查询客户记录
负责查询客户入住的历史记录信息查询模块
图2-5信息查询模块
2.2系统UML用例图
2.2.1确定参与者用例
(1)在旅店管理系统中,客户可以提出房间预定请求,预定请求得到确认以后可以入住旅店,离开旅店之前要班里退房手续。
(2)旅店的员工则需要处理客户的房间预定,并在客户退房时检查和清扫房间。
有以上分析可以看出,所有的动作都是围绕着客户和旅店员工进行的。
因此,系统中的参与者主要有来年两类:
客户和旅店员工。
下面描述客户参与的用例,如图所示
2-6客户参与的用例
(1)预定房间用例。
客户在入住之前应该首先预定房间。
(2)入住用例。
如果客户的房间预定得到确认,要在确定的日期入住旅店。
(3)退房用例。
客户在离开旅店前要办理相关的退房手续。
【用例说明】
(1)ReserveRoom:
预定房间。
其中,Bycall和OntheWeb两个用例扩展
了这个用例,它们分别表示使用电话预订和通过网上预定。
(2)GetRoom:
入住旅店用例。
(3)ReturnRoom:
退房用例。
它包含了ReturnFine(缴纳押金)用例。
(4)FillOrderForm:
填写房间预定表格。
OnTheWeb用例包含了填写房间预定表格这个步骤。
2.2.2旅店员工参与的用例
(1)登录系统用例:
旅店员工输入工作号和密码可以登录系统。
(2)处理预定申请用例。
工作人员可以处理客户的预定申请。
(3)将预定的房间交付客户用例。
客户预定请求得到确认后,可以在规定的时间入住旅店,工作人员应该能够提供入住服务。
(4)结束业务用例。
客户退房,工作人员确定房间无损坏后,可以确定该次业务结束,工作人员清扫房间
2-7员工参与用例
【用例说明】
(1)SystemLogin:
系统登录用例。
(2)ReserveProcess:
预定处理用例。
(3)QueryCustomerOrderRecord:
查询客户预定记录用例。
(4)RefuseRequest:
拒绝预定请求用例。
工作人员可以根据情况拒绝客户的预定请求。
(5)AcceptRequest:
接受预定请求。
可以根据情况接受客户的请求。
(6)GivenRoomToCustomer:
将预定房间交付客户用例。
(7)CheckRoom:
检查房间设备。
(8)CleanRoom:
清扫房间。
(9)EndBusiness:
退房处理用例。
包括了CheckRoom和CleanRoom用例。
3分析工作流
3.1提取系统的各种类,进行类建模
3.1.1客户和员工类图
根据需求分析,系统中客户和旅店员工如图所示。
【类图说明】
(1)person类是所有类的父类它包含四个属性:
姓名(name),身份证号(ID),地址(address)和电话号码(phoneNo)。
(2)Customer类是包含客户信息的类,除了继承父类的属性和方法,它包括会员编号(ClubNo)等属性。
(3)Employee类是包含员工信息的类,其中包含了员工的聘用日期等信息。
同时,它还是Manager和CommonWorker的父类。
(4)Manager是旅店管理人员的类,管理人员可以查看工作人员的工作记录。
CommonWorker类是普通员工的类,commissionRate属性是该员工任务完成率;方法calculate()是用来计算该工作人员完成的任务率;CheckRequest()是用来查询是否有没有处理的申请单。
图3-1客户及旅店员工的类图
3.1.2其他的类
(1)CustomerRecord类表示客户记录。
CustomerID是该客户的身份号码,rentRate是入住日期,RoomType是所租房间类型,RoomNumber是该房间的号码,isfinishe代表该业务是否结束。
Check()用来得到该客户的记录,End()是用来结束该业务。
(2)Room类代表房间记录。
Type是该房间类型,RoomNumber是房间号码,status是指该房间是否被预定、正在使用中或空闲状态,condition是指该房间的状态。
Inservice()用来判断该房间是否为空闲,update-Room-status()是用来修改房间所处状态。
(3)ServiceRecord类是表示每一次租赁服务的记录。
Servicehistory是服务的历史记录,progressreport是该过程中的报告。
FillRecord()用于填写表格。
(4)RequestOrder类表示的是填写客户预定申请的表格。
RoomType表示客户申请房间的类型,rentdate是租房的时间,isallow属性表示该客户的申请是否得到批准。
Allow()用来接受客户的请求,FillOrder()是指客户填写表格,Check()用来检查是否存在这个申请,isHandled()设置该申请已被处理。
(5)WorkRecord类是职员的工作记录。
属性包括交易中涉及的员工、客户、房间以及房间的使用信息。
FillWorkRecord()用来填写这份记录,ViewRecord()是用来查看这份记录,updateRecord()是用来修改这份记录。
图3-2其他类图
3.1.3各个类之间的关系
各个类之间的关系如图所示
图3-3类之间的关系
【类图说明】
从图中可以看出,工作人员(CommonWorker)可以查看所有客户(Customer)的租赁历史记录(CustomerRecord),可以处理几个客户的预定申请(RequestOrder)。
由于工作人员可以同时处理多个业务,那么他可以拥有多个服务记录(ServiceRecord)和工作记录(WorkRecord)。
每个房间也需要多个人员进行维护。
经理(Manager)可以查看多个职员的工作记录。
3.2系统的的活动图
旅店管理系统的活动图如图所示,流程描述如下:
(1)客户可以向系统提交房间预订申请(CustomerRequest),系统收到提交的请求之后会将这个请求存储起来等待处理(StoreRequest)。
(2)旅店员工可以检查是否有新的客户请求(EmployeeCheckRequest)。
如有新的请求之后,则开始处理这个新的请求(HandleNewRequest),如有空闲的房间(RoomisAvailable),则通知客户可以入住。
(3)客户退房的时候(CustomerReturnRoom),需要检查房间(CheckRoom),并打扫房间(CleanRoom)。
图3-4系统的活动图
【活动图说明】
(1)CustomerRequest:
客户提交房间预定。
(2)StoreRequest:
存储客户申请。
(3)EmployeeCheckTheRequest:
工作人员处理客户的预定申请。
(4)HandleNewRequest:
处理新的申请。
(5)RoomisAvailable:
可以满足客户的要求。
(6)Sendmessage:
返回信息,告诉客户可以入住。
(7)CustomerAcquireTheRoom:
客户入住旅店。
(8)CustomerReturnRoom:
客户退房。
(9)CheckRoom:
工作人员检查房间设施。
(10)CleanRoom:
工作人员清扫房间。
3.3系统的顺序图
3.3.1客户预定房间的顺序图
用户在网上预定房间,首先要登入系统,房间预定模块提示客户输入预定房间信息,客户输入适当的房间信息后,等待工作人员对订单懂得处理,如果有符合客户要求条件的房间,系统将显示符合预定房间的详细信息。
客户达到信息列表后,提交自己预定房间的信息,预定模块得到房间的预定单号,生成订单并提交给数据库保存,保存成功后,预定模块提示客户预定房间成功。
客户预定房间的序列图如图所示:
图3-5客户预定房间顺序图
【时序图说明】
(1)RequestOrder:
按条件输入预订房间的信息。
(2)showRoomInfo:
工作人员受理订单,系统返回满足客户预订房间要求的房间信息。
(3)New:
创建一个新的订单。
(4)Add:
向订单添加预订的房间。
(5)SaveOrder:
保存订单到数据库。
3.3.2客户删除订单的顺序图
客户在提交订单后可以对订单进行维护(添加、删除、修改)。
客户首先登入到系统查询模块。
订单查询模块显示该客户当前所有的订单。
客户得到该表后,选择需要删除的预定房间号。
订单处理模块把删除信息提交非数据模块,数据模块保存信息。
订单处理模块删除操作成功。
客户删除订单的顺序图如图所示:
图3-6客户删除订单顺序图
【顺序图说明】
(1)Login:
系统登入。
(2)SearchOrder:
搜寻客户的订单信息。
(3)ShowOrderInfo:
系统显示客户所有的预定房间信息。
(4)Delete:
删除订单。
(5)Updateorder:
更新订单到数据库。
3.3.3工作人员处理预定订单的序列图
旅店工作人员使用其账号和密码登录后,登录模块会将管理员的ID保存在系统缓存中,并提交订单处理模块。
订单处理模块提交给工作人员未处理订单列表,工作人员提交房间号得到房间的状态信息,如果有符合客户预定要求的房间则接受订单,并把接受信息提交给数据模块,数据模块更新客户客户的订单信息,并返回成功信息给订单处理模块,订单处理模块提示工作人员该操作成功。
工作人员处理订单的顺序图如图所示:
图3-7工作人员处理订单顺序图
【顺序图说明】
(1)Login:
系统登入。
(2)SearchOrder:
搜寻所有未处理的订单信息。
(3)ShowOrderInfo:
系统显示客户所有未处理的订单。
(4)handle:
处理该订单。
(5)Updateorder:
更新订单到数据库
3.4对系统功能进行划分,设计系统的包图
图3-8系统包图
4设计工作流
4.1数据库设计
旅店管理信息系统的核心实际上就是如何使用和操作数据库,所以,数据库设计极其重要。
从用户使用的角度来看,旅店系统的组成部分分成三个层次:
数据存储层、业务处理层和界面表示层。
数据存储层就是完成对数据的各种更新和维护操作,一般由数据库管理系统来完成该层上的工作。
业务处理层是应用程序要处理的、与用户密切相关的各种业务操作,这一层次的工作通常是通过程序设计语言的编程来完成的。
界面表示层是应用程序系统提供给用户的可视化操作界面,是用户提出请求和接受回应的地方。
这三个层次都与数据库相关。
数据存储层就是指数据库本身,业务处理层处理的对象,实际上就是数据库中的数据,界面表示层是操作界面,其目的是为了方便用户使用数据库中的数据。
因此数据库的设计是旅店管理信息系统开发的基础和关键。
根据调研中从中小型旅店得到的基本数据资料,并经过严密分析和论证,建立了系统数据库。
限于篇幅的关系,下面只列出了Customer-lodge表、Employee表、Room表ServiceRecord表、RequestOrder表、WorkRecord表等几个主要表的详细设计内容。
表4-1客户住宿表(Customer-lodge)
表4-2职工表(Employee)
表4-3房间表(Room)
表4-4预订信息表(RequestOrder)
表4-5服务记录表(ServiceRecord)
4.2系统界面设计
4.2.1进行系统登录界面设计
为了保护旅店各种数据信息,本系统实行操作员使用本人账号和密码登录系统。
只有账号和密码均正确后方可进入系统,否则,系统会根据具体情况提示账号不存在或是密码不正确。
成功登录后,系统会根据相应的权限显示相关的操作模块。
系统登录界面如图所示:
图4-1系统登入界面
4.2.2预定管理
(1)房间预定
预定功能只是作为一个登记客人预定本旅店信息的一个记录,便于以后查阅或办理预定入住手续。
房间预定界面如图所示,需要输入客人的基本信息.例如姓名、性别、证件类(身份证、军自证、工作证等)、证件号码等,选择对应的入住类型(钟点房、全日房)和入住时间,并缴纳押金(如果客人没缴押金,把押金金额置为0即可)方可进行房间预定。
图4-2客户预订房间界面
(2)预定入住
如果预定的客人来办理客房的登记入住手续,则在“预定管理”模块下面直接点击“预定入住”,进入图所示界面。
在己预订客房列表中,列出了所有预定信息,使用鼠标单击要入住的客房.在下面的客人信息中自动导入客人预定时留下的详细信息,井可以根据需要进行编辑。
需要注意的是,在办理预定入住的时候,如果客人再预交押金,可以在客人信息栏中填写“再预交押金”的数额,客人的预交金额会自动更新到数据库中。
图4-3预定入住界面
(3)退房结算
房界面如图所示,窗口界面上部分在住客房中显示了所有的在住房间,使用鼠标点击上面的客房,则点击的客房会相应的移动到下面的列表中,这个操作即选择要办理的客房。
选择多个客房同时办理结算,但有个前提,即登记信息是同个客人登记的客房。
例如,某个客人办理了203,204,205,206客房,那么在办理结算的时候,可以一次性全部办理全部客房的退房,也可选择其中部分退房。
图4-4退房结算
5总结
经过本学期课程的学习和这次课程设计,我体会到了理论和实践结合的重要性。
以下是我对课程学习的几点认识:
面向对象的开发思想。
面向对象是从现实世界中客观存在的事物(即对象)出发来构造软件系统,并在系统构造中尽可能运用人类的自然思维方式,强调直接以问题域(现实世界)中的事物为中心来思考问题,认识问题,解决问题的方法和过程。
首先将面向对象的思想应用到系统开发的过程中去,可以使系统直接映射到问题域,使得解空间和问题域能够在结构上尽可能取得一致,这样程序便于理解和维护,其次面向对象强调运用人类在日常生活中的逻辑思维中采用的思想方法进行系统开发构造。
UML则是一种建模语言,UML提供了标准的面向对象的模型元素的定义和表示法,以及对模型的表示法的规定,使得对系统的建模有章可循,有标准的语言工具可用,有利于保质保量地建立起软件系统模型。
在做课程设计的过程中,遇到过很多困难,尤其是刚开始的功能建模中。
很难从整体上把握整个系统所具备的功能,在细化用例时,各个细小用例的划分和相互之间的关系也很难理清,在查阅相关资料和自己的分析理解之后,在整体上对住宿管理系统有了大致的了解,在对照老师所给的设计步骤的基础上一步一步完成了设计,也体验到了在解决困难的过程成长的感觉。
我也懂得了要做一件事就应该坚持不懈,要靠自己的努力和思考去结成智慧的结晶。
6参考文献
[1]何克清,计算机软件工程学.武汉大学出版社,1983。
[2]胡克瑾,软件工程基础.上海科学技术出版社,1986。
[3](美)WalkerRoyce,软件项目管理.周伯生译,机械工业出版社,2002。
[4]林国璋,张雪兰,系统软件与软件工程技术基础。
北京理工大学出版社,1990。
[5]陈世鸿,彭蓉,面向对象软件工程.电子工业出版社,1999。
[6][美]约翰斯(Johns,M.P.),UML面向对象设计.基础科学出版社,2003。
[7][美]兰博,UML参考手册.机械工业出版社,2001.
[8]黄梯云,冯玉强.管理信息系统.北京:
高等教育出版社,2006。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 旅店 住宿 系统 课程设计