《软件方法》读书笔记

2019-05-09

开始于 2019 年 5 月 9 日，整理于 2020 年 3 月 5 日

基于 Enterprise Architect（EA）初始模型，参考每一章节的【案例和工具操作】进行画 UML 图，能够加深理解。

  1. 根据模版项目创建个人的新项目
  2. 愿景
  3. 用例
  4. 业务序列图
Table of contents

为什么需要建模？

请注意这一节的小标题是“为什么需要建模”，而不是“为什么需要业务建模”。

《领域驱动设计精粹》第一章列举了软件项目中的一些问题，其中第一条为：

软件开发被视为成本中心而非利润中心。这通常是因为从业务的角度来看计算机和软件技术是必要的消耗，而不是战略优势的重要来源（不幸的是，在根深蒂固的商业文化下，这种观念不太可能被转变）。

「软件开发是以利润为中心」，《软件方法（上）》给到了这样一个公式：

利润 = 需求 - 设计

在软件开发中，需求工作致力于解决“提升销量”的问题（即如何让系统更好卖），设计工作致力于解决“降低成本”的问题（即降低开发维护成本），二者不能相互取代。

第 1 章 建模和 UML

需求与设计

在软件开发中，需求致力于“提升销售”，设计致力于“降低成本”，二者不能相互取代。

利润 = 需求 - 设计

如果需求和设计不分，利润就会缩水。从需求直接映射设计，会得到大量重复代码；如果从设计出发来定义需求，会得到一堆假的“需求”。

需求包是基于涉众视角对系统功能分包而得到的，子系统是基于内部视角根据系统部件的耦合和内聚情况分割而得到的。

需求与设计的区别

需求 设计
卖的视角 做的视角
具体 抽象
产品当项目做 项目当产品做
设计源于需求，高于需求

目标：“低成本制造好卖的系统”

  1. 业务建模——描述组织内部各系统如何协作，使得组织可以为其他组织提供有价值的服务。通过业务建模推导新系统的需求。例如，思考组织的流程
  2. 需求——描述为了解决组织的问题，系统必须具有的表现（功能和性能）。强迫我们从“卖”的角度思考，哪些是涉众（Stakeholder）在意的、不能改变的契约，哪些不是。需求规约。例如，思考系统需要具有的功能和性能
  3. 分析——提炼为了满足功能需求，系统需要封装的核心域机制。例如，思考系统要包含的领域概念之间的关系
  4. 设计——为了满足质量需求和设计约束，核心域机制如何映射到选定平台上实现

=> 为了得到需求（结果），需要做的建模工作流有业务建模和需求；为了得到设计（结果），需要做的建模工作流有分析和设计。

UML 所提供了各种工具，建模人员只需要根据当前所开发系统的特点，从这个工具箱中选择合适的工具就可以，并不需要“完整地”使用 UML。

重点学习三种图：用例图、类图和序列图

掌握统一的建模语言之后，开发团队在基本共识上沟通，会大大提高沟通的效率和深度。

需要注意的是：使用 UML 沟通仅限于软件组织内部，UML 模型不是用来和涉众沟通的！

建模，为口号提供了方法；愿景、业务建模方法，帮助迅速定位最重要的需求；领域分析方法，帮助厘清各种概念的变和不变。

UML 建模没有绑定到特定的过程。当前主流的软件过程都是强调增量和迭代开发，应该把前面所讲的业务建模、需求、分析、设计看做是一个迭代周期里的工作流，做一点业务建模，做一点需求，做一点分析，做一点设计……不可误解成“做完了所有的业务建模才能做需求”

需要建立起的认知：

  • 没有“小系统”，无论什么样的系统都是需要建模的，即需要经历前面提到的业务建模、需求、分析、设计各个阶段
  • “你的系统不特别”

第 2 章 业务建模之愿景

愿景的定义：在目标组织代表（老大）看来，引进该系统应该给组织带来的改进。

通俗一点说，一个东西的愿景：东西最应该卖给谁，对他有什么好处？

第 3 章 业务建模之业务用例图

第 4 章 业务建模之业务序列图

描述业务用例的实现，即业务流程，然后改进它，推导出待引入系统的用例。

使用 UML 序列图来描述业务流程

  • 最主要的出发点：把人脑系统和电脑系统平等看待。不仅仅关注人和部门的活动，还关注各种非智能系统。
  • 期望和承诺是用例和对象技术的关键思想。使用序列图来做业务建模，“对象协作以完成用例”的思想就可以统一地贯彻业务建模和系统建模的始终。
  • 序列图使用 alt、loop 等结构化片段来描述业务流程，有时候需要按照场景分开画很多张序列图来表达（但这也揭露了业务流程的糟糕现状）。

业务序列图要点

  1. “消息”代表责任分配，而不是数据流动：A 指向 B 的消息，代表“A 请求 B 做某事”，或者“A 调用 B 做某事的服务”，做某事是 B 的一个责任。可以这么理解，例如，员工请求财务主管审批报销单，这里“审批报销单”这一功能接口是由财务主管对外提供的（即“审批报销单”是财务主管的责任）。
    • draw.io 将 A 指向 B 的消息称为“dispatch”，中文可以翻译为“指派”或者“调度”；
    • 注意消息名称中不用带“请求”二字，消息箭头已经有“请求”的意思；
    • 在序列图中，数据流仅仅作为消息的输入输出参数存在 ，“审核报销单(报销单)”；
  2. 抽象级别是系统之间的协作：业务建模的研究对象是组织，出现在业务序列图生命线上的对象，其最小粒度是系统，包括人和非人系统。
    • 切忌将需求和分析工作流一股脑儿带入业务建模，1）将系统内部组件暴露了出来（应该在分析和设计流中描述），2）将两个系统间详细的交互步骤暴露了出来（这应该在需求工作流中描述），业务序列图只关心两个系统协作的目的，避免出现抽象级别跳跃错误；
    • 切忌过早地将多个抽象级别的知识混杂，正确的做法是分开表述；
    • 切忌将不具备任何智能的物体放到业务序列图的生命线上；
    • 需要了解组织内部包含哪些岗位，各自承担什么责任；
  3. 只画核心域相关的系统。
    • 业务流程中涉及到的非人智能系统，远远比我们意识到的多，业务序列图上只能表现出其中一部分；
    • 大致的判断标准是：如果是核心域相关的系统，应该出现在业务序列图中，如果不是，可以不出现；
    • 如何判断核心域和非核心域？在不确定是否是核心域时，可以先画出来，在之后如果发现其与改进无关，再将它删掉；
  4. 把时间看做特殊的业务实体：时间就像上帝造好挂在天上的一个大钟，向全世界各种系统发送时间消息。
    • 什么情况下使用时间执行者？
    • 执行者是时间，而非定时器；
  5. 为业务对象分配合适的责任：分配给业务对象的责任必须是该对象有能力承担的。

尽力“如实”地描绘出目标组织的需求现状。

PDF P133 分析序列图，用对象的思想去构思我们所开发的系统的内部结构和行为，就得到了订单、申请单等假想的有生命的对象。

第 5 章 需求之系统用例图

第 6 章 需求之系统用例规约

第 7 章 需求启发

版权声明

本作品采用知识共享署名 4.0 国际许可协议进行许可，转载时请注明原文链接。