酒店餐馆管理系统用例图及规约.docx

上传人:b****5 文档编号:11922147 上传时间:2023-04-16 格式:DOCX 页数:11 大小:17.42KB
下载 相关 举报
酒店餐馆管理系统用例图及规约.docx_第1页
第1页 / 共11页
酒店餐馆管理系统用例图及规约.docx_第2页
第2页 / 共11页
酒店餐馆管理系统用例图及规约.docx_第3页
第3页 / 共11页
酒店餐馆管理系统用例图及规约.docx_第4页
第4页 / 共11页
酒店餐馆管理系统用例图及规约.docx_第5页
第5页 / 共11页
点击查看更多>>
下载资源
资源描述

酒店餐馆管理系统用例图及规约.docx

《酒店餐馆管理系统用例图及规约.docx》由会员分享,可在线阅读,更多相关《酒店餐馆管理系统用例图及规约.docx(11页珍藏版)》请在冰豆网上搜索。

酒店餐馆管理系统用例图及规约.docx

酒店餐馆管理系统用例图及规约

酒店餐馆管理系统用例图及规约

由图可见,该用例图包括8个用例、5个参与者。

理,5.核准菜单,6.产生报表,7.采购消费信息处理,8.消费统计。

参与者的名称:

顾客,前台客服,厨房工作人员,采购员,收银员。

二、用例规约

1.注册与登录

1.1简要说明

1.2事件流

1.2.1基本流

当顾客进行注册时,开始执行以下基本流:

(2)顾客填写个人信息。

(3)系统验证顾客所填写的信息的格式和内容。

(4)保存该顾客信息。

(5)顾客进入登陆界面进行登录。

1.2.2备选流

1.2.2.1顾客信息验证错误

如果系统检测到顾客输入的信息格式或内容有错,例如账号中含有非法字符、输入密码和确认输入密码不一致,会给予错误提示,并清空填写错误的文本框,要求顾客重新输入。

1.2.2.2顾客信息保存失败

如果系统发现数据库中已经保存了同样账号的顾客记录,会向顾客报告保存失败的错误信息,并使页面跳回注册页面,要求顾客修改注册信息。

1.3特殊需求

无。

1.4前置条件

顾客必须首先访问餐馆管理系统的页面,然后单击注册、登录。

1.5后置条件

如果该用例成功,系统数据库中将增加一条该顾客的信息。

否则,系统维持原状。

1.6扩展点

无。

2.个人信息管理

2.1简要说明

2.2事件流

2.2.1基本流

当顾客登录到餐馆管理系统后,开始执行以下基本流:

(1)顾客进入个人信息页面后,浏览个人信息。

(3)当顾客填写完所有的信息后,经确认后提交有其顾客订单信息的表单。

(4)系统经过验证后,反馈给顾客验证信息,同时将顾客信息连同顾客选定的饭菜信息一并存入顾客信息库。

2.2.2备选流

2.2.2.1顾客账号不存在

2.3特殊需求

无。

2.4前置条件

顾客要想订餐,必须先登录到该餐馆管理系统中;若没有顾客账号,则该顾客还需要现在该系统中注册一个顾客账号。

2.5后置条件

该用例实现后,顾客信息的情况就通过顾客订单信息被保存在了系统的顾客信息库中,由系统对此进行统一的管理;反之,系统的顾客信息库中的信息不发生任何的改变。

2.6扩展点

无。

3.食品管理

3.1简要说明

顾客登陆系统补充万个人信息后进行订餐操作,同时前台客服也可登陆系统进行顾客点餐信息的管理。

顾客登录进入餐馆食品管理系统页面后,通过查看菜单信息以后,顾客可以进行选择要点的饭菜,并将菜单信息传给产生报表系统和核准菜单系统。

3.2事件流

3.2.1基本流

当发送订货通知时,系统开始执行以下基本流:

(1)顾客进入选餐页面后,浏览所有的菜单信息。

(2)顾客对选定的饭菜,下订单。

(3)系统将点餐订单交给核准菜单系统和产生报表系统。

3.2.2备选流

3.2.2.1订餐通知发送失败

由于网络或各种原因向采购部门发送的订货通知发送失败,系统会提示失败字符。

3.2.2.2取消发送订餐通知

若取消发送订餐通知,则系统销毁该订单。

3.3特殊需求

无。

3.4前置条件

顾客要想订餐,必须先登录到该餐馆管理系统中;当顾客补充信息保存后,该顾客才能进入食品管理系统进行点菜。

3.5后置条件

该用例实现后,顾客预定饭菜的情况就通过该系统传给核准菜单系统和产生报表系统;反之,系统不向其他系统发送任何的信息。

3.6扩展点

无。

4.餐台管理

4.1简要说明

本用例是用来确定顾客餐台信息之用。

当顾客提交了顾客信息单后,系统与餐台信息库进行连接,通过检测若有满足的餐台类型,则直接反馈给顾客他们的餐台信息(包括餐台类型和餐台号等);若发现顾客所需的餐台类型暂时没有空台时,系统反馈信息给顾客,让顾客进行一些选择(比如是调整就餐时间还是分开就坐等)。

4.2事件流

4.2.1基本流

当接收到顾客信息单信息时,开始执行以下基本流:

(1)根据顾客细信息单信息,连接餐台信息库。

(2)根据就餐时间和就餐人数对比餐台数据库,确定餐台号。

(3)向顾客发送反馈信息,给定餐台号。

4.2.2备选流

4.2.2.1餐台无空缺

若发现顾客所需的餐台类型暂时没有空台时,系统反馈信息给顾客,让顾客进行一些选择(比如是调整就餐时间还是分开就坐等)。

4.3特殊需求

无。

4.4前置条件

顾客个人信息和就餐时间就餐人数必须已经填写完成并提交,被保存至顾客信息库。

4.5后置条件

如果该用例成功,会生成通知顾客的反馈信息。

否则,系统维持原状。

4.6扩展点

无。

5.核准菜单

5.1简要说明

本用例是用来确定顾客菜单信息之用。

当顾客提交了点餐信息单后,系统与食品库存清单进行连接,通过检测若全部能够满足,则直接打印出菜单交给厨房工作人员,并将该菜单信息传给产生报表系统;若发现有不能满足的食品,则将核准后的菜单交由厨房工作人员与产生报表系统。

5.2事件流

5.2.1基本流

当核准菜单系统收到食品管理系统传来的菜单信息以后,开始执行以下基本流:

(1)检查菜单信息。

(2)连接食品库存清单。

(3)进行对比,确定核准后菜单。

(4)打印出核准后菜单,交由厨房工作人员并将核准菜单传给产生报表系统。

5.2.2备选流

无。

5.3特殊需求

无。

5.4前置条件

顾客必须提交了订餐信息。

5.5后置条件

如果该用例成功,则打印出菜单交给厨房工作人员,并将菜单传给产生报表系统。

否则,系统维持原状。

5.6扩展点

无。

6.产生报表

6.1简要说明

对比原始菜单和核准后的菜单,确定是否需要食品采购,如若需要采购,则产生采购清单,并将采购清单交由采购员,同时将采购单信息传给采购消费信息处理系统

6.2事件流

6.2.1基本流

当产生报表系统收到原始菜单和核准后的菜单时,开始执行以下基本流:

(1)系统对比原始菜单和核准后的菜单。

(2)如需采购,打印出采购清单给采购员,让采购员去采购。

(3)将采购信息传给采购消费信息处理系统。

6.2.2备选流

6.2.2.1打印失败

由于网络或各种原因没有出处数据导致打印失败,系统会提示失败字符,重新进行打印。

6.3特殊需求

无。

6.4前置条件

原始菜单和核准后的菜单必须都已经传入产生报表系统。

6.5后置条件

如有需要,则打印出采购清单交给采购员并同时将采购信息交给采购消费信息处理系统。

6.6扩展点

无。

7.采购消费信息处理

7.1简要说明

采购信息进入该系统,该系统连接食材价格表,对采购花费进行统计,并将花费消息进行统计存入财务数据库。

7.2事件流

7.2.1基本流

当采购信息进入该系统时,开始执行以下基本流:

(1)该系统连接食材价格表。

(2)对比采购信息和食材价格表,统计出采购花费信息。

(3)将采购花费信息存入财务数据库。

7.2.2备选流

7.2.2.1食材价格表连接失败

由于网络等原因,无法连接食材价格表。

进行再次连接或者稍后重试。

7.2.2.2采购花费信息存入失败

由于网络或者线路问题,存入失败,系统提示错误信息,系统进行重传。

7.3特殊需求

无。

7.4前置条件

采购信息必须进入该系统。

7.5后置条件

该用例成功,则财务数据库存入一条新的信息,否则,系统数据库维持现状。

7.6扩展点

无。

8.消费统计

8.1简要说明

该系统连接食材价格表,和核准后菜单进行对比,计算出顾客消费情况,并将顾客消费情况传给收银员,同时将信息存入财务数据库。

8.2事件流

8.2.1基本流

当核准后菜单进入该系统时,开始执行以下基本流:

(1)该系统连接食材价格表。

(2)对比食材价格表和核准菜单,计算出顾客消费情况。

(3)将顾客消费情况传给收银员。

(4)将顾客消费情况存入财务数据库。

8.2.2备选流

8.2.2.1食材价格表连接失败

由于网络等原因,无法连接食材价格表。

进行再次连接或者稍后重试。

8.2.2.2顾客消费信息存入失败

由于网络或者线路问题,存入失败,系统提示错误信息,系统进行重传。

8.3特殊需求

无。

8.4前置条件

核准菜单必须进入该系统。

8.5后置条件

该用例成功,则财务数据库存入一条新的信息,否则,系统数据库维持现状。

8.6扩展点

无。

三补充规约

1.目的

本补充规约列出了餐馆管理系统的非功能性需求和部分全局性需求。

它和用例模型在一起,组成了完整的系统需求规格说明书。

2.范围

本说明书除定义了许多用例中共有的功能性需求以外,还定义了系统的非功能性需求,如可靠性、可用性、系统性能和可支持性等。

3.参考

4功能性

4.1满足多个顾客的并发执行。

4.2当顾客预定饭菜时,系统必须判断该食品是否还有剩余,若该食品已无库存,需提醒顾客,并通知采购部门进行采购。

5可用性

顾客界面视窗与WINDOWS系统兼容。

6.可靠性

保证系统在配置完成以后24小时都可用,平均无故障时间应超过300小时。

7.性能

7.1该系统应支持多达1000名顾客在任意特定时间使用中央数据库,并支持多达500名顾客在任何时候访问本地服务器。

7.2系统要求对数据库的访问,存取速度要快,特别是对食品目录的访问的反应时间要在8秒内

8.可支持性

无。

9.安全性

系统要求有较高的安全性,由于在管理订单时,顾客的信息都在网络上传输,所以必须提供额外的安全性措施。

10设计约束

无。

四术语表

1.简介

本文档用来对一些术语进行定义,同时对用例说明或其他文档中读者不太熟悉的术语进行解释性的描述。

2.名词定义

这份术语表包含了餐馆管理系统的重要概念。

2.1顾客:

指每个使用该餐馆管理系统进行预定的人和每个到餐厅吃饭时登记的人。

2.2前台客服:

负责接待顾客和管理输入顾客的个人信息及点餐信息。

2.3厨房工作人员:

餐馆的工作人员,包括核准菜单打印人员和厨师以及传菜生。

2.4收银员:

顾客就餐结束时的接待处理人员,负责顾客的结账管理。

2.5食品:

餐馆供应的一切食物(包括主食、零食以及酒水等)。

2.6个人信息:

用户注册时填写的信息。

2.7食品信息:

食品的名称、价格、所属类型和现有数量等信息。

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工程科技 > 能源化工

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1