迭代三

2.1 业务建模（UC1,UC2）

A. 业务流程建模。

u  使用UML活动图分析目标系统所支持的业务流程。

u  使用文字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。

  

     B. 领域建模。

u  使用UML类图构建领域模型。

 

 

2.2  UC2用例模型（详述文本）

用例UC2：收银

范围：便利店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 UC2补充性规格说明

功能性

1、安全性

  • 在开始使用系统之前要进行登录。所有操作都必须先经过身份验证，保证操作合法性。

  • 在与银行系统进行交互中，系统标准达到国家相关的安全标准

2、日志和错误处理

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

3、可插拔规则

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

可用性

1、店员和顾客都能够看到POS屏幕显示器的显示；避免使用一般色盲人群难以辨认的颜色。

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

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

可靠性

1、可恢复性

如果在使用外部服务（支付授权、账务系统等）时出现错误，为了完成销售交易，需要尝试才用本地方案（如存储和转发）加以解决或者在出现其他故障时能够快速的恢复。

2、数据备份

系统要支持定时或实时的数据备份，避免数据的破坏或者丢失，要有比较高的可维护性。

3、性能

购买者希望非常快速的完成销售处理过程，而在营业高峰期，系统会产生大量的数据，因此，我们要求系统和数据库之间的交互能迅速而准确，还有系统之间的交互响应时间应低于30秒。

可支持性

1、可适应性

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

2、可配置性

不同客户对其使用的POS系统有不同的需求，所以要求系统具备一定的可配置能力以适应这些需求。

实现约束

使用的程序设计语言为C#，其具备安全，稳定，简单的特性，能够提高系统安全性和可靠性。

购买构件

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

接口

1、重要硬件和接口

• 触摸屏（作为显示器，同时触摸动作也便于操作）。

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

• 票据打印机

• 信用卡、借记卡读卡器

2、软件接口

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

所关注领域内的信息

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

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

2、销售税

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

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

 4.3 UC1,UC2相关的数据库

一．销售开单ER图

二.数据库表设计

1.订单表   tb_order