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

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

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

整理UML酒店管理系统动态图

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

系别：

计算机科学与工程系

班级：

网络0801

姓名：

XXX

学号：

200809203127

指导老师：

XXX

日期：

2010年12月24日

酒店预订系统

小组成员及分工

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

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

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

教师评语

一、课题详述

题目四：

酒店预订系统

基本业务流程：

顾客预约：

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

顾客到达：

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

用餐顾客结帐：

同时刷新餐桌和预约信息

显示：

显示当前桌子的状态

完成以下模块：

（1）预约模块

●显示预约：

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

●添加预约：

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

●修改预约：

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

●删除预约：

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

●查询预约：

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

（2）到达模块

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

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

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

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

（3）结帐模块

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

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

●工作内容及要求

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

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

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

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

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

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

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

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

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

●提交结果及要求

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

（2）可选提交：

状态机图、系统部署图

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

二、需求分析

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

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

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

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

顾客结账：

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

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

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

1客户申请注册登录模块

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

2系统管理员登陆模块

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

3顾客到达模块

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

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

4顾客结账模块

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

5餐桌信息管理模块

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

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

6客户信息管理模块

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

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

7会员权限管理模块

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

三、静态结构建模

各类之间的关系

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

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

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

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

四、动态结构建模

用例图

1业务处理系统（图1）

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

图1业务处理系统

2系统管理员的系统管理

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

组件图

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

活动图

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

时序图

1权限设置时序图

2餐桌信息设置时序图

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

3订餐时序图

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

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

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

协作图

1权限设置协作图

2餐桌信息设置协作图

状态图

1餐桌信息状态图

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

2订单状态图

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

活动图

1权限设置活动图

五、事件流文档

1用例“注册”的描述

1.1前置条件

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

1.2后置条件

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

1.3扩充点

无

1.4事件流

1.4.1基流

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

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

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

1.4.2分支流

无

1.4.3替代流

无

2用例“登陆”的描述

2.1前置条件

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

2.2后置条件

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

2.3扩充点

无

2.4事件流

2.4.1基流

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

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

同意申请。

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

拒绝申请。

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

拒绝申请。

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

2.4.2分支流

s-1同意申请

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

s-2驳回申请

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

2.4.3替代流

无

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

3.1前置条件

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

3.2后置条件

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

3.3扩充点

无

3.4事件流

3.4.1基流

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

如果该餐桌空置并无预订，执行分支流s-1：

同意申请。

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

驳回申请。

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

3.4.2分支流

s-1同意申请

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

s-2驳回申请

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

3.4.3替代流

无

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

4.1前置条件

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

4.2后置条件

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

4.3扩充点

无

4.4事件流

4.4.1基流

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

4.4.2分支流

无

4.4.3替代流

无

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

4.1前置条件

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

4.2后置条件

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

4.3扩充点

无

4.4事件流

4.4.1基流

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

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

同意申请。

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

驳回申请。

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

4.4.2分支流

s-1同意申请

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

s-2驳回申请

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

4.4.3替代流

无

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

5.1前置条件

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

5.2后置条件

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

5.3扩充点

无

5.4事件流

5.4.1基流

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

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

就餐状态。

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

空置状态。

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

预订状态。

1.环境影响评价依据的环境标准体系如果客户退订该餐桌，执行分支流s-2：

空置状态。

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

5.4.2分支流

2）规划实施可能对环境和人群健康产生的长远影响。

s-1就餐状态

客户正在进行就餐。

根据工程、系统生命周期和评价的目的，安全评价分为三类：

安全预评价、安全验收评价、安全现状评价。

s-2空置状态

（二）建设项目环境影响评价的工作等级餐桌状况良好，并无人就餐和预订。

s-3预订状态

（四）建设项目环境影响评价资质管理餐桌已有客户预订。

5.4.3替代流

无

1.建设项目环境影响评价文件的报批

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

5.建设项目环境影响评价文件的重新报批和重新审核6.1前置条件

1）直接使用价值。

直接使用价值（DUV）是由环境资源对目前的生产或消费的直接贡献来决定的。

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

6.2后置条件

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

6.3扩充点

2.量化环境影响后果无

定量安全评价方法有：

危险度评价法，道化学火灾、爆炸指数评价法，泄漏、火灾、爆炸、中毒评价模型等。

6.4事件流

6.4.1基流

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

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

6.4.2分支流

无

6.4.3替代流

无