需求获取

用户故事

用户场景描述

作为一个收银员，我想要处理销售， 以便于客户就可以买到商品

基本流程 {
（用户） 1、 客户应带着商品到达收银台购买。
（用户） 2、 收银员应开始新的销售。
（系统） 3、 CoCoME应开始新的销售。
（用户） 4、 收银员应输入货品信息。
（系统） 5、 CoCoME应将货品加入当前购买货品队列。
（循环4~5直到输入结束）
（系统） 6、 系统显示所有货品清单及总价。
（用户） 7、 顾客选择支付方式进行支付。
（用户） 8、 收银员应向顾客提供小票。
}

扩展流程{
（可选） 1-6a、 顾客可以选择中断交易。
（系统） 系统清空当前已经加入系统的货品清单，结束本次交易。
（用户） 收银员清空收银台的货品，结束本次交易。
（可选） 4a、 收银员可以手动输入商品信息。
（用户） 收银员手动输入商品信息。
（用户） 顾客出示优惠卷。
（用户） 收银员输入优惠卷信息。
（可选） 1-5a、 用户出示优惠卷。
（系统） 系统扣除相应金额。
（系统） 系统向收银员报告错误。
（异常处理） *a、 系统在任何时间发生错误。
（用户） 收银员停止收银，错误解决后再重新收银。
（用户） 收银员改为手动输入商品信息。
（异常处理） 4b、 收银员扫描商品过程中发现无效商品。
（系统） 接受手动输入的信息，加入货品清单。
（选择） 7a、顾客可以选择不同的支付方式。
（用户） 顾客选择支付方式进行支付。
}

非功能需求：{
1、 收银员扫描货品后的延迟不能高于30ms。
2、 在系统发生错误时能够恢复之前的数据，保障数据不丢失。
3、 支持收银时多国家货币的汇率转换。
}

用例描述

• 用例名称：描述用例的意图或实现的目标，一般为动词词语或动宾短语。
  处理销售
• 用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。
  UC1
• 参与者：描述用例的参与者，包括主要参与者和其他参与者。
  收银员、顾客。
• 用例简介：对用例的一段简单的概括描述。
  收银员通过系统帮顾客结账。
• 触发条件：触发用例执行的一个事件。例如，“生成订单”用例的触发器是“用户提交了一个新订单时”。
  顾客到达收银台时。
• 前置条件：用例执行前系统状态的约束条件。
  顾客完成了商品选购。
• 基本流程：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。
  顾客完成商品选购到达收银台后，收银员和系统做好准备，收银员开始扫描顾客购买的每个商品，录入系统。所有商品信息输入完成后，系统给出货品清单和总价，顾客选择支付方式进行支付，收银员向顾提供小票。
• 扩展流程：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。
  顾客在支付完成前可以中断交易。收银员可以手动输入商品信息。用户可以在支付前出示优惠卷，收银员输入系统后按照优惠价结算。系统在任何时间发生错误。收银员扫描商品过程中若发现无效商品可以手动输入商品信息。
• 后置条件：用例执行后系统状态的约束条件。
  系统已经将当前顾客清单清零为下次处理销售做准备。
• 补充约束：非功能需求，即用例实现时需要考虑的业务规则、实现约束等信息。
  收银员扫描货品后的延迟不能高于30ms。在系统发生错误时能够恢复之前的数据，保障数据不丢失。支持收银时多国家货币的汇率转换。

用例图

系统操作合约

• 操作签名：操作的名称和参数。
  enterItem(barcode: Integer, quantity: Integer)
• 交叉引用：涉及的用例。
  处理销售
• 前置条件：执行操作前，系统满足的状态条件，包括输入参数。
  销售正在进行，并且barcode对应的商品存在
• 后置条件：完成操作后，系统满足的状态条件。分为3类（创建或者删除对象、对象属性值的变化、形成或者消除对象之间的关联）
  • 创建了SalesLineItem类的实例sli（创建实例）
  • sli实例与Sale类的当前实例sale建立了关联（形成关联）
  • sli实例的quantity属性值等于输入参数quantity（修改属性）
  • sli实例与barcode对应的Item类的实例item建立了关联（形成关联）

系统顺序图

概念类图

概要设计

包图

组件图

组件顺序图

pro版系统顺序图，系统不再是黑盒

组件状态机图

详细设计

设计类图

概念类图pro，类的可见范围、类间的语义关系、类方法的设计与实现、类属性的数据类型和可见范围

用例实现的顺序图

活动图

软件设计说明书