业务建模学习

要点回顾

回顾一下前文中的提到的部分软件方法流程:

  • 愿景: 明确目标组织和老大.
  • 业务建模之业务用例图: 以组织提供的价值为依据(对组织的期望), 输出组织的用例.
  • 业务建模之业务序列图: 以现状业务序列图为基础, 将待开发的系统作为新的业务实体插入, 寻找改进点, 减少人肉.
  • 需求之系统用例: 从业务序列图直接映射.

Demo 目标

给出一个选课系统的 UML 建模, 包括愿景、业务用例(涵业务序列)、系统用例。

初版设计

愿景:

业务对象图:

业务用例图:

典型业务序列图:

系统用例图:

分析与改进

一、愿景(Vision)

业务用例图(Business Use Case)中, 对研究的组织定位是不正确的. 引申出来的愿景(Vision)也比较泛:

  • 不管有没有这个选课系统, 研究的对象-组织是客观存在的.
  • 选课系统应该解读为: 课程管理系统, 它包含了学生选课、老师排课的功能.
  • 课程管理系统的涉众包括: 教务人员、授课老师、学生.
  • 愿景是引入课程管理系统之后, 为这个组织带来的价值提升.
  • 课程管理系统, 大幅减轻了教务人员的繁杂工作, 软件系统替代部分人肉工作.
  • 学生选课, 老师授课, 通过课程管理系统也得到了便利, 价值有提升, 但并不是最主要的.
  • 所以, 选课系统, 只有教务人员才是最大的"买方", 目标组织是教务机构, "老大"是教务机构中的代表: 教务主任.

二、业务对象图

确定了目标组织和老大, 才可以明确业务对象:

  • 业务对象包括人肉-业务工人(Business Worker)和系统-业务实体(Business Entity).
  • "教务处"是不正确的, 应该是"教务人员".
  • 发邮件、身份认证, 并不是核心交互流程, 不体验核心价值, 所以可以隐藏"系统邮箱"和"校园身份系统".
  • "教务人员"主动发起操作, 所以也没有"时间".
  • 我们需要对比老-新业务序列, 所以需要引入老业务序列中需要用的到业务实体: "打印机"和"公告板".

三、业务用例

  • 确定业务用例, 就是看业务执行者(Business Actor)如何和组织打交道.
  • 对学生而言, 和组织打交道的就是"选课", 至于"查询"、"取消选课", 那都是业务用例的一部分, 应该体现在业务序列图上.
  • 同理, 对老师而言, 和组织打交道的就是"授课", 至于"查询"、"发布课程"、"调整课程"这些, 都是业务用例的一部分, 也应该体验在业务序列图上.

四、业务序列图

  • 根据前面的业务用例分析, 以"授课"用例来说, 这是一个大的序列, 包含了"发布"-"汇总"-"上课"-"调整"-"结课"这样一套流程.
  • 先厘清老的流程, 然后将"课程管理系统"引入之后, 得到新的流程. 两者对比可以得到提升的价值.

五、系统用例图

根据业务序列图映射.