细化迭代3——2.1、2.2、2.3、2.4

2.1业务建模

A、活动图

 

B、领域模型

 

 

2.2需求规格说明

A、系统用例图

 

B、用例详述文本

用例UC1：收银

范围：711便利店POS应用

级别：用户目标

主要参与者：收银员

涉众及其关注点：

—收银员：希望能够准确、快速地输入。

—顾客：希望以最小代价完成购买活动并得到快速服务。希望得到购买凭证，以便退货。

—公司：希望准确记录交易，满足顾客要求。希望确保记录了支付授权服务的支付票据。希望有一定的容错性。希望能够自动、快速地更新账务和库存信息。

—经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。

—政府税收代理：希望能从每笔交易中抽取税金。

—支付授权服务：希望接收到格式和协议正确的数字授权请求。

前置条件：收银员必须通过确认和认证。

成功保证（或后置条件）：存储销售信息。更新账务和库存信息。记录提成。生成票据。记录支付授权的批准。

主成功场景（或基本流程）：

1.收银员告知顾客总额，并请顾客付款。

2.顾客付款，系统处理支付。

3.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。

4.系统打印票据。

5.顾客携带商品和票据离开。

扩展（或替代流程）：

*a.经理在任意时刻要求进行超控操作：

  1.系统进入经理授权模式。

  2.经理或收银员执行某一经理模式的操作。

3.系统恢复到收银员授权模式。

*b.系统在任一时刻失败：

  1.收银员重启系统，登录，请求恢复上次状态。

  2.系统重建上次状态。

   2a.系统在恢复过程中检测到异常：

     1.系统向收银员提示错误，记录此错误，并进入一个初始状态。

     2.系统开始一次新的销售交易。

1a.顾客要求现金付款，但所携现金不足：

  1.顾客要求使用其他支付方式。

   1a.顾客要求取消此次销售交易，收银员在系统上取消销售交易。

2a.现金支付：

  1.收银员输入收取的现金额。 

  2.系统显示找零金额，并弹出现金抽屉。 

  3.收银员放入收取的现金，并给顾客找零。

  4.系统记录该现金支付。

2b.信用卡支付：

  1.顾客输入信用卡账户信息。

  2.系统显示其支付信息以备验证。

  3.收银员确认。 

   3a.收银员取消付款步骤。

     1.系统回复到“商品输入”模式。

  4.系统向外部支付授权服务系统发送支付授权请求，并请求批准

该支付。 

   4a.系统检测到与外部系统协作时的故障：

     1.系统向收银员提示错误。

     2.收银员请求顾客更换支付方式。

  5.系统收到批准支付的应答并提示收银员，同时弹出现金抽屉（以便放入签名后的信用卡支付票据）。

   5a.系统收到拒绝支付的应答：

     1.系统向收银员提示支付被拒绝。

     2.收银员请求顾客更换支付方式。

   5b.应答超时。

     1.系统提示收银员应答超时。 

     2.收银员重试，或者请求顾客更换支付方式。

  6.系统记录信用卡支付信息，其中包括支付批准。    

7.系统显示信用卡支付的签名输入机制。 

8.收银员请求顾客签署信用卡支付。顾客输入签名。 

9.如果在纸质票据上签名，则收银员将该票据放入现金抽屉并关闭抽屉。

4a.存在产品回扣：

1.系统对每个具有回扣的商品给出回扣表单和票据。

4b.顾客索要赠品票据（不显示价格）： 

1.收银员请求赠品票据，系统给出赠品票据。 

4c.打印票据： 

1.如果系统能够检测到错误，给出提示。    

2.收银员更换纸张。    

3.收银员请求打印其他票据。

特殊要求：

•使用大尺寸平面显示器触摸屏UI。文本信息可见距离为1米。

•90%的信用卡授权响应时间小于30秒。

•希望在访问远程服务（如库存系统）失败的情况下具有较强的恢复功能。

技术与数据变元表：

*a.经理超控需要刷卡或在键盘上输入授权码。

2a.信用卡账户信息可以用读卡器或键盘输入。

2b.记录在纸质票据上的信用卡支付签名。

2.3补充性规格说明

简介

本文档记录了711POS系统所有未在用例中描述的需求。

功能性

1、日志和错误处理

在持久性存储中记录所有的操作，以便进行错误处理和对操作人员的操作进行监督。

2、可插拔规则

在几个用例的不同场景点执行任意一组规则，以支持对系统功能的定制。

3、安全性

任何使用都需要经过用户认证。

可用性

人性因素

店员和顾客都能够看到POS大屏幕显示器的显示；因此：

1、应该在一米外轻松看到文本。

2、避免使用一般色盲人群难以辨认的颜色。

快捷、准确的销售交易处理及其重要，因为购买者希望快速离开，否则会给他们的购买体验带来负面影响。

收银员的视线通常停留在顾客或商品，而不是计算机显示器上。因此，提示和告警应该通过声音传递而不仅仅是通过图像传递。

可靠性

1、可恢复性

系统要支持数据的备份，要有比较高的可维护性。如果在使用外部服务（支付授权、账务系统等）时出现错误，为了完成销售交易，需要尝试采用本地方案（如存储和转发）加以解决。

2、性能

正如“人性因素”中所提及，购买者希望非常快速的完成销售处理过程。外部的支付授权是瓶颈之一。所以我们的目标是：希望在正常情况下，能够在一分钟之内完成授权。

可支持性

1、可适应性

711POS的不同客户在处理销售时有其特有的业务规则和处理需求。因此，在场景中的几个预定之处（如开始新的销售交易时，增加新的商品时），需要能够启用可插拔的业务规则。

2、可配置性

不同客户对其使用的POS系统有不同的配置需求，因此，系统应该具备一定的可配置能力以适应这些需求。对此需要进一步分析，以发现哪些地方需要灵活性和灵活性的程度，以及实现这种灵活性所需的工作。

实现约束

711的领导层坚持使用Java技术的解决方案，他们认为采用Java技术除了易于开发外，还能够提高远期的移植和可支持性能力。

购买构件

税金计算器，必须支持用于不同国家的可插拔计算器。

接口

1、重要硬件和接口

触摸屏（操作系统将此视为普通监视器，且触摸动作也视为鼠标事件）。

条形码激光扫描仪（通常附加在一种特殊键盘上，扫描输入在软件中视为键盘输入）。

票据打印机

信用卡/借记卡读卡器

2、软件接口

由于存在众多外部协作系统，如税金计算器，账务，库存等，我们需要采用不同的接口，接入不同的系统。

所关注领域内的信息

1、信用卡和借记卡支付处理

当支付授权服务批准了信用卡或借记卡支付后，将由支付授权服务而不是买方来负责对卖方的支付。因此，对于每笔支付，卖方都需要将授权服务的未付金额记录于其应收账户下。通常，授权服务在每晚执行电子转账操作，将卖方当天的应收总额转入其账户下，同时对每笔交易扣除（少量的）服务费。

2、销售税

对税金计算采用税金计算器计算。

    3、商品标识：UPC、EAN、SKU、条形码和条形码读取装置。

 

2.4 系统顺序图与操作契约

A、系统顺序图

 

B、操作契约

契约CO1：makeNewSale

操作：	makeNewSale ()
交叉引用：	用例：收银
前置条件：	无
后置条件：	创建了Sale的实例s（创建实例）
	s被关联到Register（形成关联）
	s的属性被初始化（修改属性）

契约CO2：enterItem

操作：	enterItem (itemID:ItemID,quantity:integer)
交叉引用：	用例：收银
前置条件：	正在进行中的收银
后置条件：	创建SalesLineItem的实例sli（创建实例）
	sli被关联到当前Sale（形成关联）
	Sli.quantity赋值为quantity（修改属性） 基于itemID的匹配，sli被关联到ProductDescription(形成关联)

契约CO3：endSale

操作：	endSale ()
交叉引用：	用例：收银
前置条件：	正在进行中的收银
后置条件：	Sale.isComplete被置为真（修改属性）

契约CO4：makePayment

操作：	makePayment (amount：Money)
交叉引用：	用例：收银
前置条件：	正在进行中的收银
后置条件：	创建了Payment的实例p（创建实例）
	p.amountTendered被赋值为amount（修改属性） p被关联到当前的Sale（形成关联）
	当前的Sale被关联到Store（形成关联）（将其加入到完成收银的历史日志中）