《软件方法》学习

一、建模与 UML

《软件方法》聚焦两方面的技能: 需求 & 设计.

作者提出一个适用于软件行业的观点:

利润 = 需求 - 设计

需求工作, 致力于解决产品好卖的问题; 设计工作, 致力于解决降低成本的问题.

核心工作流: 业务建模 -> 需求 -> 分析 -> 设计

工作流 思考焦点 推荐 UML 元素
业务建模 组织内系统之间 业务用例图、类图、业务序列图
需求 系统边界 系统用例图
分析 系统内核心域 类图、序列图、状态机
设计 系统内各域之间 代码即设计

UML 模型仅用于内部沟通, 和涉众交流的是视图, 内容聚焦涉众利益.

二、愿景

愿景, Vision, 即在老大(目标组织代表)看来, 引入这个系统给组织带来的改进.

  • 组织: 要改进其流程的组织. 它可以是机构, 也可以是人群.
  • 老大: 目标组织的代表, 最有地位的涉众, 改进目标在他的脑中度量.

Step 1. 定位组织和老大.

Step 2. 提炼改进目标, 即愿景.

UMLChina 业务系统的愿景:

三、业务用例图

业务用例, Use Case, 指业务执行者希望通过和组织交互达到的, 而且组织能提供的价值.

业务流程是业务用例的实现, 组织里发生的一切都是为了给业务执行者提供价值.

关键是思路: 先归纳出组织对外提供什么价值, 再思考如何更好的优化组织内部流程来实现价值.

业务用例的中的角色定义:

  • 业务执行者, Business Actor, 组织外和组织交互的其他组织(人群或者机构).
  • 业务工人, Business Worker, 组织内的人群.
  • 业务实体, Business Entity, 组织内的智能系统.

如何识别业务用例?

  • 思考业务执行者和组织打交道的目的 -> "执行者对组织的期望, 组织对执行者的承诺"
  • 通过观察组织的内部活动, 一直问为什么, 向外推到组织外部的某个业务执行者 -> "补漏"

Step 1. 选定改进的组织

画一个圈, 把大多数责任可能被(部分/全部)替换的系统(人肉系统/电脑系统…)包在里面

从外部看, 组织是一些价值的集合 -- 用业务用例图来表示

从内部看, 组织是一些系统的集合 -- 用业务序列图来表示

Step 2. 输出组织的业务用例图

业务用例是组织的、而不是组织内某个系统的用例. 组织的用例不会因为某个人肉系统或电脑系统的存在或消失而改变. 所以, "这个系统的业务用例是什么"这样的说法是错误的.

业务用例不是思考系统提供什么"功能", 而是思考组织购买了这个系统, 对组织本来就有的哪些"功能"会带来一点点帮助?

《软件方法》中给出的一个图例:

四、业务序列图

期望和承诺,是用例和对象技术的关键思想.

使用序列图来做业务建模, "对象协作以完成用例".

要点:

  • 消息代表责任分配, 而不是数据流动: A -> B, 代表 A 请求 B 做某事, 或者 A 调用 B 的做某事的服务. 消息封装的是责任.
  • 聚焦系统之间的协作, 抽象级别一致, 不暴露系统内部的细节.
  • 只画核心域相关的系统.
  • 把时间当作特殊的业务实体.

Step 1. 输出现状业务序列图

Step 2. 改进业务序列图

  • 物流 -> 信息流, 物流变成信息流促进了人类社会的进步.
  • 改进信息流转, 将信息流转点从业务工人流转到业务实体.
  • 封装领域逻辑, 业务实体代替业务工人.

《软件方法》中给出的示例:

业务对象图

交互概述图

业务序列图

五、系统用例图

系统用例的定义: 系统能够为执行者提供的, 涉众可以接受的价值

  • 思考用例的过程, 就是发现价值的过程.
  • 需求: 系统"做"什么; 用例: 系统"卖"什么.
  • 系统用例图, 研究的是系统; 业务用例图, 研究的是组织.

系统执行者: 在系统外, 与系统发生功能性交互的其他系统:

  • 系统是能独立对外提供服务的整体.
  • 系统边界是责任的边界.
  • 系统执行者和系统有交互.
  • 交互是功能性的.
  • 系统执行者可以是人或者系统, 还可以是时间.

Step 1. 识别系统执行者

从业务序列图映射系统执行者: 有交互的

不要把执行者和权限管理混淆

Step 2. 识别系统用例

从业务序列图映射, 区分主执行者(主动发起)和辅执行者(被动参与).

画好现状的业务序列图, 然后把待开发的系统作为新的业务实体空降到序列图中, 寻找改进点, 得到该业务实体的责任, 就可以直接映射到待开发系统的系统用例.

不是从设计来映射需求, 不要带入程序思维, 不存在复用、分层、增删改查. 用例一定是动宾结构.

《软件方法》中给出的案例:

源序列图

映射系统用例图

六、系统用例规约

规约, specification, 是共同遵循的规章和约定. 系统用例规约是以用例为核心, 组织需求内容的需求规约.

系统用例规约的内容包括:

  1. 前置条件: 用例开始前, 系统要满足的约束.
  2. 后置条件: 用例成功结束后, 系统要满足的约束.
  3. 涉众利益: 涉众关注的目标. 愿景本质上是最重要涉众的利益.
  4. 基本路径:
    • 按照交互四部曲书写: 请求、(验证)、(改变)、回应.
    • 只写系统能感知和承诺的内容.
    • 主动语句, 理清责任.
    • 主语只能是主执行者或系统.
    • 使用核心域术语.
    • 不涉及UI
    • 不涉及交互
  5. 扩展路径:
    • 扩展是能感知、要处理的意外.
    • 设计实现的异常, 不是扩展.
    • 不引起交互行为变化的选择, 不是扩展.
    • 界面跳转, 不是扩展.
  6. 补充约束:
    • 字段列表
    • 业务规则
    • 质量需求: 可用性、可靠性、性能、可支持性
    • 设计约束

七、总结

总结一下要点:

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

业务建模是一个发现价值的过程: 明确研究对象-组织, 梳理现有模型, 找出能提供价值的改进点(往往是软件系统代替人肉系统), 得到业务序列图, 映射出系统用例, 最终形成系统用例规约,即需求.

最后梳理一张脑图:

八、阅读延伸

《软件方法》