UML酒店管理系统动态图.docx

UML酒店管理系统动态图.docx

《UML酒店管理系统动态图.docx》由会员分享，可在线阅读，更多相关《UML酒店管理系统动态图.docx（18页珍藏版）》请在冰豆网上搜索。

UML酒店管理系统动态图

《UML系统分析与设计》实训报告

系别:

计算机科学与工程系

班级:

　网络0801　　　

姓名:

　XＸX　　　

学号:

　2　

指导老师：

　XＸX　　　

日期：

2010年12月２4日　

酒店预订系统

小组成员及分工

XXX餐桌信息设置时序图、协作图,订餐时序图、协作图,餐桌信息状态图，订单状态图

XXX　组件图,用例图及事件流文档

XXＸ类图、权限设置时序图、权限设置协作图、权限设置活动图

教师评语

一、课题详述

题目四:

酒店预订系统

基本业务流程:

顾客预约：

记录,取消，修改,查询和显示

顾客到达：

有预约顾客和无预约顾客相分离；

用餐顾客结帐：

同时刷新餐桌和预约信息　

显示:

显示当前桌子的状态

完成以下模块:

（１）预约模块

●显示预约:

显示当天所有预约，同时桌子根据当前时间显示当前状态

●添加预约:

添加一个新的预约，并插入数据库,如果是当天预约则显示在预约状态栏中

●修改预约：

修改一个已有的预约，可以修改订餐人数,预约日期,时间以及餐桌

●删除预约：

删除一个已有预约，删除数据库信息,如果是当天预约则刷新预约状态栏

●查询预约:

根据订餐人姓名,餐桌号，预约日期，时间查询预约状态

（2）到达模块

●到达情况有两种，一种是有预约的到达,另一种是无预约的到达

●有预约的到达首先要查询预约,故在预约模块中添加到达的功能

●无预约的到达,就可以立即找空桌子用餐

在到达操作中还要刷新当前桌子状态,由预约或空闲状态转为用餐状态

（3）结帐模块

●显示当前正在用餐的桌子信息,从中选中需要结帐的桌子,进行结帐操作

●结帐完成后,将桌子置为空闲状态,若当天还有不同时间预约此桌子的则置该桌为预约状态

●工作内容及要求

根据三人的分工，请在一周内完成下列工作内容:

（1）进一步细化需求分析的内容，识别出系统的参与者,并完成用例图；

（2）将用例图中的每个用例都写成相应的事件流文档;

（3）进一步使用活动图来描述每个用例，为后续的系统设计做好准备;

（4）按照系统的功能分析,从用例的描述中提取出系统的对象类和界面类,建立类图;

（5）分析类图中的实体类和实体类之间的关系，画出数据库的逻辑模型图（只包含实体类，且注明角色和阶元）。

（6）对数据库的逻辑模型进行优化,取消多对多的联系,完成最终的逻辑模型设计;

（7）使用交互作用图或状态机图完成系统动态行为的建模。

（建议使用顺序图按功能分别描述）。

●提交结果及要求

（1）请提交用例图（包括事件流文档）、类图、活动图、交互作用图。

（2）可选提交：

状态机图、系统部署图

（3）完成规定格式的实验报告（纸质），以小组为单位上交电子版实验报告和系统建模的成果（各类图和相关文档，电子文档）。

二、需求分析

酒店管理系统要能完成以下功能：

用户能够了解酒店的信息，根据信息申请预定餐桌。

工作人员能够处理顾客预定餐桌:

首先检查客户的订餐信息，然后根据订餐信息选择相应级别的餐桌或包间。

顾客结账：

显示当前正在用餐的桌子信息,从中选中需要结帐的桌子,进行结帐操作，结帐完成后,将桌子置为空闲状态,若当天还有不同时间预约此桌子的则置该桌为预约状态。

员工能够对信息进行管理。

根据要求可将系统分为七个模块

1客户申请注册登录模块

会员能够查询酒店的餐桌信息情况，然后根据自己的需要，填写申请单，向工作人员递交申请,工作人员根据系统情况，回复客户。

2系统管理员登陆模块

　系统管理员工作需要登陆系统,才能够进行操作，系统中的各项数据都不允许外人随便查看和更改,所以设置登陆模块是必须的。

3顾客到达模块

到达情况有两种,一种是有预约的到达，另一种是无预约的到达，有预约的到达首先查询预约,故在预约模块中添加到达的功能。

无预约的到达,就可以立即找空桌子用餐，在到达操作中还要刷新当前桌子状态,由预约或空闲状态转为用餐状态

４顾客结账模块

显示当前正在用餐的桌子信息,从中选中需要结帐的桌子,进行结帐操作，结帐完成后，将桌子置为空闲状态,若当天还有不同时间预约此桌子的则置该桌为预约状态。

5餐桌信息管理模块

　工作人员可以对公司的餐桌进行管理。

工作人员可以查询公司的餐桌情况,包括就餐情况，就餐历史,餐桌状况。

6客户信息管理模块

　在酒店就餐过的会员，工作人员需要记录下就餐情况,以便再次预定就餐时可以查询。

新注册的客户，工作人员需要添加新会员进系统中。

7会员权限管理模块

　管理员查询会员的权限，写入新的权限。

三、静态结构建模

各类之间的关系

类不是单独一个模块,各个类之间是存在联系。

酒店预订系统各类之间的联系如图：

从图中可以看出，系统管理员可以查看会员的个人信息，并修改会员的权限，还可以设置餐桌的状态信息。

会员可以浏览餐桌信息和申请订单,申请订单成功后,就可以通过网上支付系统支付定金。

四、动态结构建模

用例图

1业务处理系统（图１）

客户登陆系统进入个人信息管理,如果不是会员,先注册成为会员,然后登陆系统选择查询餐桌相关信息，最后下订单。

图1　业务处理系统

2系统管理员的系统管理

　　　　　　　图2系统管理员的系统管理

组件图

该图是系统的各个组件图,由主界面、个人信息管理、权限设置、餐桌信息设置、餐桌信息、个人订单管理。

活动图

　　会员查看餐桌信息，在登陆状态下请求订餐,并选择底单、支付方式，在管理员确定后，订餐成功。

时序图

1　权限设置时序图

2餐桌信息设置时序图

管理员可以查看、设置餐桌的状态信息。

3订餐时序图

会员可以通过登陆订餐系统，查询餐桌信息,选择餐桌，并进行网上支付定金，最终生成订单。

然后管理员修改相关餐桌状态信息。

管理员可以打开权限窗口，查询所有会员或某个会员,写入新的权限后，保存，完成设置。

协作图

1权限设置协作图

2　餐桌信息设置协作图

状态图

１　餐桌信息状态图

管理员和会员都可以查询餐桌状态信息,会员可以预订、退订,管理员根据实际情况修改餐桌信息。

2　　订单状态图

订单状态图显示,系统记录餐桌信息、餐桌信息及付款信息，会员可以修改订单，请求通过后可以生成订单。

活动图

１权限设置活动图

五、事件流文档

1用例“注册”的描述

1.1前置条件

　　　在客户网上注册成为会员之前，必须要先进入该酒店的网上酒店预订系统。

1.2后置条件

如果“注册”用例成功,客户就成为了改酒店的会员。

1.3扩充点

无

１．４　事件流

　　1．４.1基流

　用户进入系统是用例订约注册的开始,填写申请表,填写正确提交后,工作人员根据申请表,回复用户申请表是否通过。

用户可以通过电话和前台，询问工作人员自己的申请,工作人员根据系统记录，处理申请。

　　　管理员根据用户填写的申请表，给予该用户会员的资格,并回复该用户已经注册成功可以登陆。

　1.4.2　分支流

　　　　　　　无

　1.4.３替代流

　　无

2用例“登陆”的描述

2.１前置条件

　在客户网上登陆之前,必须要先成为酒店的网上会员，并登陆进入该酒店的网上酒店预订系统。

2.2后置条件

　如果“登陆”用例成功，客户可以填写申请表，进行网上订餐。

2.3扩充点

无

2.4事件流

２.4.1基流

　　会员成功登陆进入系统后,查询餐桌信息,填写订餐信息并提交,等待管理员处理申请。

　　　　如果该餐桌状态良好并且闲置，执行分支流s－1:

同意申请。

　如果该餐桌不能使用，执行分支流s-2:

拒绝申请。

如果该餐桌已有人预定，执行分支流s－2:

拒绝申请。

如果用户申请完成,则用例结束推出。

2.４.2分支流

s-1同意申请

　　管理人员根据用户的申请,根据系统中餐桌的情况,同意用户的申请，把申请结果返回给用户,用例结束。

s-2　驳回申请

　　工作人员根据用户的申请,根据系统中餐桌的情况，驳回用户的申请,用例重新开始。

　2．4.3替代流

　　　　　　　无

３用例“选择订单”的描述

３．1前置条件

在用例个选择订单之前,用户必须成为该酒店的网络会员并成功登陆系统。

3.2后置条件

如果这个用例成功，则用户可以处理个人的订单管理。

3.3扩充点

无

3.4事件流

3．4.1基流

会员进入选择订单系统后，通过查询餐桌信息，可以选择申请订单,等待系统管理员处理申请。

如果该餐桌空置并无预订,执行分支流ｓ-1:

同意申请。

如果该餐桌处于就餐状态,执行分支流s-2：

驳回申请。

如果用户选择订单完成,则用例结束推出。

3.4.2分支流

　ｓ-1　同意申请

　　工作人员根据餐桌的空置并且无预订状况，同意用户的申请,把申请结果返回给用户，用例结束。

s-2驳回申请

工作人员根据该餐桌处于就餐状态,驳回用户的申请，用例重新开始。

３.4.3替代流

　　　　无

4用例“个人信息管理”的描述

４.１前置条件

在用例个人信息管理之前,用户必须成为该酒店的网络会员,并登陆订餐系统。

4.2后置条件

如果这个用例成功，则用户可以处理个人信息管理。

4.3扩充点

无

４.4事件流

4.４.1基流

会员进入个人信息管理系统后,可以查询个人信息，也可以修改个人信息并保存。

4.4.2分支流

　　　　　　　　无

４.4.3替代流

　　　　　无

4用例“个人订单管理”的描述

4．1前置条件

在用例个人订单管理之前,用户必须成为该酒店的网络会员。

4.2后置条件

如果这个用例成功,则用户可以处理个人的订单管理。

4.3扩充点

无

4．4事件流

4.４．1基流

会员进入个人订单管理系统后,可以查询个人餐桌信息及缴费情况,也可以申请修改订单,等待系统管理员处理申请。

如果管理员根据实际情况确定能够修改，执行分支流s-1:

同意申请。

如果管理员根据实际情况确定不能够修改，执行分支流s－２：

驳回申请。

如果用户申请修改订单完成，则用例结束推出。

４.４.2分支流

　　　ｓ-１同意申请

　工作人员根据用户的申请的要求和现实的状况，同意用户的申请,把申请结果返回给用户，用例结束。

s-2　驳回申请

　工作人员根据用户的申请的要求和现实的状况，驳回用户的申请,用例重新开始。

４．4.3替代流　

无

5　用例“餐桌管理”的描述

５．1前置条件

在用例餐桌管理之前，管理员必须先登录订餐管理系统。

5．2后置条件

　　在管理员用例餐桌信息管理后,管理员可以更改、预订、退订餐桌的状态信息。

5.3扩充点

无

５.4事件流

　５.4.1基流

管理员成功登陆进入系统后,查询餐桌状态或预订情况,可以进行餐桌状态的修改。

　　如果该餐桌从空置状态进入就餐状态,执行分支流s-1:

就餐状态。

如果该餐桌从就餐状态进入空置状态,执行分支流s-2:

空置状态。

　　　如果客户预订该餐桌,执行分支流s－3：

预订状态。

如果客户退订该餐桌，执行分支流s-2：

空置状态。

如果餐桌管理完成，则用例结束推出。

５.4．2分支流

　s-1就餐状态

　　客户正在进行就餐。

s-2空置状态

　餐桌状况良好，并无人就餐和预订。

s-３预订状态

　　　餐桌已有客户预订。

５.4．3替代流

　　　　　　　无

6用例“用户权限管理”的描述

６.1前置条件

　　在用例用户权限管理之前,管理员必须先登录用户权限管理系统。

6．2后置条件

　管理可以修改会员的权限。

6.3扩充点　

无

６.4　事件流

6.4.１基流

　管理员成功登陆进入用户权限系统后，可以查询全部会员的权限，或某个会员的权限，也可以修改用户的权限。

如果管理员需要修改某个会员的权限,根据实际情况进行修改，修改成功后退出用例。

6.4.2　分支流　　

无

6.4.３替代流　　

　无