FD快餐店迭代三设计文档
2.1业务建模
A.业务流程建模
涉众：顾客，收银员，pos机系统，授权服务
业务规则：
ID |
规则 |
可变性 |
来源 |
规则1 |
购买者折扣规则： 会员价：10%折扣额 员工价：15%折扣额 一般顾客：无折扣 |
高 每个餐饮店有不同的规则 |
餐饮业规则 |
规则2 |
会员卡积分规则： 积分100以上：享受会员价后再打九折的优惠 积分200以上：享受会员价后再打八折的优惠 更高的积分同200及以上一样享受同等优惠，不设更高打折优惠 |
高 每个餐饮店有不同的规则 |
餐饮业规则 |
B.领域模型
2.2 UC2用例模型以及详述文本
A.用例模型
B.用例模型详述文本
用例名称：收银
范围：FD POS应用
主要参与者：收银员
前置条件：收银员必须经过登录和认证身份
后置条件：存储销售交易信息，确定一个订单号对应一笔销售交易。准确计算销售总价和折扣。更新账务和库存信息。生成票据
主成功场景：
1. 顾客点餐完毕，收银员根据该销售订单进行结账操作
2. 系统显示应付总金额，收银员告知顾客并等待顾客付款
3. 顾客付款，系统处理支付
4. 系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统和库存系统。
5. 系统打印票据
6. 顾客携带票据等待领取餐品就餐
扩展:
*a.经理在任意时刻要求进行超控操作：
1.系统进行经理授权模式。
2.经理或收银员执行某一经理模式的操作。例如取消处理支付。
3.系统恢复到收银员授权模式。
*b.系统在任意时刻失败
1.收银员重启系统，登录，请求恢复上次状态。
2.系统重建上次状态
2a.系统在恢复过程中检测到异常
1.系统向收银员提示错误，记录此错误，并进入初始状态。
2.收银员开始一次新的销售交易。
2-3a.顾客发现现金不足,无法付款:
1.顾客要求取消本次销售交易,收银员在系统上取消该销售交易
2.顾客要求使用其他方式支付
2a.顾客使用信用卡支付：
1.顾客输入信用卡密码。
2.系统显示支付信息以验证。
3.收银员确认。
4.系统向外部的支付授权服务系统发送请求
5.支付授权服务系统批准该支付，系统收到回答并提示收银员
3b.系统崩溃,
1. 无法开始处理支付消息,收银员重启系统服务,继续操作
1a.重启服务失败,,收银员向经理请求超控操作,重新开始一次销售交易
2.系统处理支付事件时出现故障,无法计算(显示)找零金额
2a.收银员重启系统服务,继续操作
1.重启失败,收银员手工计算找零金额
3c.pos机无法自动弹出现金抽屉
1.收银员手工开启现金抽屉,若无法手工开启,则请求经理执行超控操作
3d.现金抽屉里零钱不足,无法给顾客找零
1.收银员询问顾客是否有零钱支付或者是否使用其他方式付款
2.收银员从其他现金抽屉里取出零钱,给顾客找零
2a.所有现金抽屉均没有足够的零钱,收银员通知经理,经理及时补充零钱
3e.顾客要求使用会员卡消费或声称他们符合某种优惠条件(例如,会员卡账户积分达到一定程度可以享受打折优惠)
1. 收银员向系统提示打折请求
2. 收银员输入顾客手机号码或会员卡ID确认身份
3. 系统按照打折规则显示折扣总计(若为兑现积分,则在打折的同时扣除结余积分)
5a.打印票据时出现问题
1. 系统检测出错误,给出提示
2. 收银员更换纸张
3. 收银员请求打印其他票据
2.3 UC2补充性规格说明
（主要是修改迭代二中的补充性规格说明）
补充性规格说明在用例中未提及的其他类型的需求，如可用性、可靠性、接口（如支持网银支付接口）等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。
可用性：
在1米外轻松可看到文本
可靠性;
可允许多人同时访问该系统；
需要体现出系统的稳定性以及反应速度。
支持定时进行数据备份（防止系统崩溃时数据丢失）；
功能性：
日志与错误处理（在持久性存储中记录所有错误）
安全性（使用系统必须经过用户认证）
权限管理（不同用户有不同的使用管理权限）
可插拔规则（ 在几个用例的不同场景点执行任意一组规则，以支持对系统功能的定制。）
可对系统任意时刻数据进行查询；
可导入导出系统数据以及打印报表等
可支持性
可适应性
不同客户在处理销售时有其特有的业务规则和处理需求。因此，在场景中的几个预定之处（如开始新的销售交易时，增加新的商品时），需要能够启用可插拔的业务规则。
可配置性（系统可适应快餐店对其POS系统的不同的网络配置需求）
实现约束：
使用java程序设计语言
接口：
1.重要硬件和接口
触摸屏
票据打印机
信用卡读卡器
2．软件接口
需要采用不同接口，接入不同系统（账务、库存等）
所关注的领域内信息
1. 定价
食物餐品的价格根据市场价格定价。
2. 编码
可参考都城快餐店的编码来进行编码。