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

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

用例图的编号和名称是：1.注册与登录，2.个人信息管理，3.食品管理，4.餐台管理，5.核准菜单，6.产生报表，7.采购消费信息处理，8.消费统计。

参与者的名称：顾客，前台客服，厨房工作人员，采购员，收银员。

二、用例规约1.注册与登录1.1 简要说明本用例用于向顾客提供注册功能和注册后的登陆以及前台客服的登陆。

每位顾客必须注册后才能登录系统内订餐。

注册信息包括使用本系统的账号、密码、联系地址和电子邮件等。

注册完成后，可登录餐馆管理系统，系统将会保存这些信息，以方便管理及联系用户。

1.2 事件流1.2.1 基本流当顾客进行注册时，开始执行以下基本流：（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）顾客进入个人信息页面后，浏览个人信息。

（2）顾客补填有关其个人资料的表单并将本次就餐人数与就餐时间填写清楚。

（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 食品信息：食品的名称、价格、所属类型和现有数量等信息。