博客

Pos系统的分析与设计案例

— 笔记整理自 北京理工大学 计算机学院

分析设计

Pos系统在生活中随处可见，如超时中的收银系统，建议参阅《对象模型——策略 模式 应用》的第一章：康妮的便利店。

• 运用策略和模式可以快速提高OO设计水平

  • 策略是可以用来实现特定目标的一些具体建议
  • 模式是关于相互作用的对象的模板,可以通过模板反复使用

• 建立对象模型的四种活动

  • 确定系统的目标和特性，后面的分析设计都是为了目标和特性服务的
  • 选择对象(识别对象)
  • 为对象确定职责，这个对象在系统中干什么，和其他对象是否有关联，以及关联如何发生
  • 确定对象间的交互动态场景

• Pos系统相关功能

  • 登录功能(用户名和密码)
  • 模拟收银员的工作环境，销售主窗口
  • 扫描枪扫描功能, 扫出客户商品对象的一些信息
  • 可计算总价，税率，支付价格，找零等
  • 同时可看到一些客户记录
  • 退出功能

Pos系统的对象模型设计

• Pos系统对象模型
  • 系统目标(通用,重点)
    • 提高员工效率,记录销售过程,改善经营效率
  • 系统特性(来自需求)
    • 重要信息写入日志
      • 根据UPC(条码)确定价格
      • 税金类别
      • 授权收银员
      • 持续供应的商品
      • 记录店内每笔销售的结果
      • …
    • 管理交易过程
      • 根据UPC确定价格
      • 小计和合计
      • 接收现金、支票、记账、信用卡支付
      • …
    • 分析经营结果
      • 计算某种商品售出数量
      • 计算各种支付方式的钱数
      • 评估收银员的表现
      • 评估各店的经营情况
      • …
    • 与其他系统交互
  • 多层架构(为模型选择架构模式, 如MVC三层架构)
    • 核心问题是业务逻辑
    • 窗口：双向的，用户输入和系统反馈提示(与人交互)
    • 报表：单项的，系统产生给用户看(与人交互)
    • 问题域：就是业务逻辑域
    • 数据管理：存取数据通过一个数据管理层来操作数据库，如磁盘文件、RDBMS、ODBMS
    • 与系统交互：其他系统、装置
  • 问题域PD组件(业务逻辑域，也叫业务逻辑层)
    • 选择PD对象
      • 选择参与者
        • 收银员(收银主管)
          • 如果收银员和收银主管都是一个类,那么自然考虑到收银员派生出收银主管,这是泛化关系
          • 如果不采用泛化关系,尽量少用继承和派生,是否可以在收银员类中设置一个级别,用数字来标识,级别越高,数值越大
          • 这样就可以区分更丰富的层次，取而代之的收银主管这个候选的类没有必要存在了
        • 顾客(不考虑)
          • 自助使用系统，那顾客就是一个参与者
          • 如果顾客将商品交给收银员，那顾客就不是一个参与者
          • 就可以把顾客从参与者列表中去除
        • 选择执行者(不考虑)
          • 个人(这里Pos系统中是个人)，收银员和个人之见的关系暂不考虑
          • 机构(其他系统可能是一个机构)
      • 选择地点
        • 商店
          • 对象的种类
          • 泛化和特化
          • 商店的种类: 连锁店(要考虑和商店之间的关系)，单一店面
        • 货架
          • 在大型商场中，会有不同的区(生鲜区,百货区), 区内还有不同的货架
          • 这就是一个地点容器，设计的时候要考虑哪些地点可以作为一个类放入系统之中
          • 这里的货架暂时不予考虑
      • 选择事物(谁在什么地方干了什么事)
        • 实际事物
          • 商品
          • 记录机
          • 现金抽屉
        • 描述性事物
          • 税类
        • 事务(事物性质)
          • 销售
            • 对象的种类
            • 销售种类
              • 销售
              • 退货
            • 销售单项
          • 支付
            • 现金
            • 支票
            • 记账
            • 信用卡
          • 对话(session)
            • 记录了收银员登录，销售，支付，注销整个过程
    • 组织PD对象
      • 参与者 – 事务 (谁干了什么事)
        • 收银员干了销售，支付和对话
      • 地点 – 事务 (这个地点发生了什么事)
        • 商店里面销售
      • 事务 – 后继事务 (这件事发生之后又发生了什么事，这些事有什么关系)
        • 登录 – 对话 – 销售 – 支付
      • 容器 – 内容物
        • 商店里有商品，记录机，收银员
        • 容器本身作为内容物
        • 事务 – 事务单项
          • 卖了多少件商品
          • 销售单项
      • 执行者 – 参与者
        • 一个收银员账号可以被多人来使用
        • 一个收银员账号只能被一个人来使用
    • 确定PD对象的职责
      • 执行者和参与者的职责
        • 个人
          • 我知道什么? 解决类的基本属性：整型, 浮点型, 字符串等
          • 我知道谁? 我这个对象知道其他什么对象
          • 我做什么? 对象中的成员函数
        • 收银员
          • 继承个人上的问题，实例化
      • 地点的职责
        • 商店对象：知道什么，知道谁，它能干什么?
        • 是个容器：包括实体的类，统计的职责
      • 实际物体的职责
        • 商品类(商品编号，描述，厂家，价格)
        • 拿出价格这一个属性，后续扩展是否会有各类降价促销(很多价格), 一个float字段无法保留这么多信息
        • 可以考虑把价格作为一个类单拿出来, 这个类和商品类形成一个一对多的关系
        • 设计的时候要静下心来，根据用户需求和将来可能的需求变更来对现有对象进行扩展和调整
      • 事务
        • 销售
          • 这是一个动词，要记录下整个动作发生的日期，时间，单项总价，折扣，计税，最终总价等
        • 销售单项
          • 退货单项：派生自于销售, 销售时候的价格，退货时的价格，销售的日期，退货原因等
          • 派生关系
        • 支付和支付方式
          • 拆解成需要认证的和不需要认证的方式
        • 对话
          • 开始时间，结束时间
          • 统计每个收银员买了多少东西等
    • 确定PD指责(所有对象的固定职责)
      • 和一般对象职责不一样，比如说不是一个类来承担，而是由整个整体来承担
      • 集合 – 成员
        • 参与者 – 事务 (谁干了什么事)
          • 收银员在一段时间收到的金额
          • 收银员在一段时间的内售出量
        • 事务 – 事务单项
          • 销售与销售单项的合作完成的工作：销售小计
        • 项目 – 单项
          • 对某种商品统计一段时间内的销售量
      • 利用模式检验和补充职责
    • 确定PD的动态场景(序列图)
      • 选择关键场景
        • 比如在销售过程中，每个对象和其他对象的协作关系，发送消息的次序，涉及到性能的要求
        • 销售
        • 销售单项
        • 商品
        • 商店
        • 税类
      • 应用设计模式
        • 比如：通过商品id和数量把消息传递给接口层,接口层通过业务逻辑层的分发机制发送给不同的控制器完成整个系统的流转
        • 使用设计模式来确认，优化整个类间关系和类的职责
  • 与人交互HI组件(Human Interface, 或者叫做UI层)
    • 选择HI对象
      • 窗口
        • 登录窗口
        • 事务窗口
        • 销售和支付窗口
        • 交易参与者窗口
          • 商店窗口
          • 收银员窗口
          • 登记窗口
          • 现金抽屉窗口
          • 税类窗口
          • UPC窗口
          • 商品窗口
        • 结果窗口
        • 商店评估窗口
      • 报表
        • 收据
        • 商店报表
        • 收银员报表
        • 商品报表
    • 确定HI对象的职责
      • 登录窗口
      • 销售窗口
      • 收据
    • 序列图(交互场景) 涉及到系统与用户的交互，会大量使用了序列图
      • 登录
        • 登录窗口，消息传递给服务器验证用户和密码，获取用户对象
        • 商店
          • 是个容器，通用职责由容器来提供
          • 根据收银员工号获取收银员的类和对象
        • 收银员对象
        • 对话对象
          • 什么时候登录的，谁登录的，以及其他的一些信息
        • 记录机
          • Pos机对象加入对话，一个pos机中有多个session对话
        • 销售窗口
      • 实现销售
        • 开始销售
          • 创建销售对象
          • 创建收据对象
        • 出售商品
          • 扫描
          • 从条码返回商品对象的价格等商品信息
          • 根据upc返回商品信息的方法，挂载在商店的对象上
          • 商品信息，价格信息放到销售单项里面，再把销售单项加入销售里面
        • 合计销售额
          • 通知销售和收据类计算
        • 现金(信用卡)付款
          • 根据不同的支付方式选择连接认证系统或非认证系统
          • 通知收据对象打印信息
        • 完成本次销售
          • 现金抽屉接收到信息开始打开，进行找零等操作
          • 关闭抽屉，直到下次再次接受信息后打开
          • 调用商店的完成销售的方法，将此次销售记录下去
      • 注销
        • 通知session对话对象，进行 endSession 方法
        • 记录什么时间退出，存入数据库便于将来统计
    • Cash示例
      • 登录窗口
      • 主窗口
      • 窗口对象交互
        • 双向连接
        • 设计模式
  • 系统交互IS组件(这个系统与其他系统可能有交互)
    • 认证系统IS：人力资源管理系统，库存系统，信用卡认证系统等等，与这些系统交互往往需要提供一些接口，传送一些对方需要的数据格式
    • 认证系统(PD)
    • 交互
  • 数据管理DM组件(数据访问层，主要采用ORM类的工具)
    • 对象持久
    • 对所用问题域对象增加DM对象
    • 每个DM对象执行基本的DM任务
      • 搜索
      • 保存
      • 装载
    • 序列图
      • 从HI组建的一个服务开始
      • 从PD组建的搜索需求开始
  • 暂不考虑NT组件
    • 幕后的服务器
    • 顾客
    • 收银主管
    • 机构
    • POS客户
    • 货架

总结

• 弄清楚整个业务流程不是一件容易的事情，需要开发、分析、设计、需求人员都要弄清楚整个业务流程，超越用户，发现背后的问题

扩展阅读

《道法自然——面向对象实践指南》

简介：本书是一本试图用实战案例阐释面向对象技术体系的指南。本书共分19章，以实际的开发案例——FishGUI项目为主线依次介绍了需求和用例分析、面向对象分析、架构分析、面向对象设计、设计模式、编码技巧等几个主要的技术领域，并基本按照时间顺序，描述了FishGUI系统设计和实现的全过程。