业务建模、业务用例图、系统用例图都是啥？一文读懂《软件方法》

👉目录

0 引子

1 业务建模

2 需求

3 分析

4 结尾

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

《软件方法》

• 业务建模：描述目标领域的内部系统间如何协作，这里的系统是广义的领域内的各个系统，不是单指要开发的系统；

• 需求：想要的功能和性能，注意，必须是涉众在意的；

• 分析：从需求中提炼出核心域的机能，核心域是系统能在市场上生存的理由，也就是核心竞争力、门槛；

• 设计：将核心域机制映射到实现方法上。

如果缺乏清晰、共享的愿景，开发人员会在错误的方向上狂奔，做得越多，浪费越多，却反而还乐在其中。

《软件方法》

1. 定位目标组织及其“老大”（也就是系统最优先照顾其利益的那个人）

1. 定位人群：人群属性必须细化再细化，要找到最有代表性的老大进行调研，而不是大街上随便找一个人，随着互联网发展越来越完善，想要得到市场，只有深耕行业，深耕的意思就是要细化人群，好比要做一个文本编辑器，Word、WPS 等已经很好地满足了绝大多数人的需求，你再去做一个标准编辑器很难卖出去，更好的选择是选择一个细分领域，如医生的病历编辑器，然后把调研的人群定位于医生群体；

2. 定位机构：先明确机构的范围、要替换的既有系统（人脑或电脑），老大应该是目标机构的主管或负责人，且是业务负责人，而不是 IT 负责人，也不是企业最大的领导。在和传统企业或机构的合作中，我们往往会对接一个信息中心主任，但要明确老大应该是最了解业务的人，而不是管信息化的人，只有这样才能靠近最真实的需求。

2. 提炼改进目标。要注意的是，目标应该是改善组织行为的某个指标，如 IoT 设备的材料提交速度、审批步骤等，而不是系统的功能，也不是系统本身的规模、质量，这些都是基于指标分析出的需求和结果

• 业务执行者：指组织的边界外，和组织交互的其他组织（人群或机构）；
• 业务的执行者应该是组织，而不是个人或者系统（因为他们都可能被替代），只有组织才反应了业务的交互；
• 时间不应该被作为执行者，而应该是对应的业务组织。
• 业务用例：业务执行者希望通过和所研究组织交互获得的价值（如取款、存款等）。它代表了组织的本质价值，很难变化，会变化的只是用例的实现——业务流程（如取款机取款流程、网银转账流程等）。

• 业务工人：组织内部的人，可被其他业务工人或业务实体替换；
• 业务实体：组织中的非人智能系统。

在找到业务用例后，我们需要进一步研究用例的业务流程，这需要借助业务序列图的帮助。业务序列图描绘的是该业务用例的流程现状。

要如实地画出现状的序列图，只有描绘现状，才能找到改善的途径。

而不能是描绘想象中的或打算做的样子（这会导致改进点可能根本不合适或者已经被实现了）；

也不能是组织给出的所谓规范（那是理想情况，实际流程可能与规范大不相同，毕竟人都会钻空子或者节省力气，如何保障流程按规范进行，也是一种改进点）；

更不能因为是创新产品就认为没有现状（大部分创新都是基于某个既有流程做的改进，很少有凭空创造需求并成功的）。

业务序列图主要由业务对象和消息构成，长得很像研发人员熟悉的时序图。

序列图上的业务对象的最小颗粒是人和非人系统；消息是指业务对象 A 请求业务对象B做某事，或A调用B做某事的服务，做某事是 B 的责任。

在画业务序列图时，要注意以下几个反模式（不好的做法）：

• 业务对象突然细化到某个存储载体，如“关系型数据表”，这不是改进业务流程所关心的（除非改进的是一个数据库系统之类）；

• 业务对象扩大到某个组织，而不区分内部的人或系统，这会导致可能遗漏改进点；

• 关心与核心域流程不影响的各种系统（如通讯工具、word 文档等），这同样不是业务流程关心的（除非你就是要改进这一点）；

• 把定时器当做执行者（业务对象），执行者是时间，定时器只是和时间打交道的边界类；

• 赋予业务对象超出其能力的责任，如发送写专利的消息给 word，word 本身并不会写专利，专利是专利人写的，word 只用于“编辑专利文档”；

• 包含系统内的多次细致的交互流程，过于繁琐，又不在改进点内；

• 把一个不具备智能的消息传递参数（如某个物品）当做业务对象；

• 消息内容中包含“请求”二字，箭头本身就包含了请求的意思。

画好业务序列图后，我们就要看看这个图中，存在什么改进点，可以被我们的软件系统所解决，也就是有没有可以让我们发挥价值的地方。改进模式一般分以下几类：

• 把物流变成信息流（物体和人的流动，改为信息的流动，常见于各种信息化、线上化）；

• 改善信息流转（减少人与多个系统打交道的流程，减少系统间沟通不畅）；

• 封装领域逻辑（把人的经验与思考封装到系统中，需要深耕领域业务，现在这种改进的比重越来越大）。

如果发现一个业务流程已经很完善了，很难找到常规的改进点了，怎么办呢 ？这里有一些建议：

• 遇到困难、资源受限等问题，展开想象，打破思维障碍，而不是接受现实做一个普普通通的系统；

• 用廉价的方案来“山寨”富豪、高官的生活（如下属们周到的服务安排），再把这种生活复制给普通人；

• 观察和调研领域内最成功的组织，找到其中的借鉴点，不能闭门造车。

如何找到改进点，上文已经有建议，这里更加深入介绍一下，当要具体考虑需求细节前，我们需要尽可能地多从涉众处了解到他们的真实需求，前文也说过，要找到真正的涉众和“老大”，去得到需求的启发。在和涉众沟通时，应该尽量以其能够快速理解的方式，而不是画一个 UML 图去沟通。UML 图适合在软件开发团队内部作为专业的交流手段，和涉众交流时，则应该视其习惯转换成合适的形式来获取需求，他们熟悉网页界面，就拿原型沟通，他们熟悉文件材料，就拿文件讨论。

做需求启发时，有几个手段和注意事项：

• 与涉众沟通前，要充分调研好资料，做好知识储备，才能让沟通过程有价值，不能什么也不清楚就去问，没人愿意花时间教你；

• 针对个体很多的涉众，可以问卷调查，但要注意避免无效答卷（可以埋钉子问题，筛选出明显乱答的）；

• 做访谈，和真正的不同涉众进行访谈，不能只找好交流的人交流（如只咨询熟悉手机的年轻人，不管中老年）；

• 善观察，观察涉众的环境、工作流程，甚至亲自去体验；

• 研究竞争对手，在竞争过程中，不同的阶段需要有不同的战略意识：

• 开拓者：作为市场领先者，要开拓本领域，不要只关心追赶者；

• 追赶者：研究领先者的优点，攻击其强势外表下背后的弱点；

• 侧翼战：专攻细分市场做创新，也能占据一份市场；

• 游击战：依靠地域优势、人际关系来生存，并逐渐凝聚出自己的特色。

通过需求启发，希望能够打造出尽可能有价值的系统来。

这里提到了执行者的类别，有两种：

• 主执行者：主动发起用例的交互，箭头从执行者指向用例。
• 辅执行者：在交互的过程中被动参加进来，箭投从用例指向执行者。

再来看用例，对系统用例图中的用例，也有以下几点要求：

• 在业务序列图中，从外部指向系统的消息，即可映射为系统的用例，所以画好业务序列图，也就能得到准确的系统用例；
• 用例必须是可以对执行者带来价值的，而不是任何一步繁琐的交互都算；
• 用例要明确其主要的目标客户，而不是谁可以来做就算作谁的用例，用例满足的是目标用户的期望；
• 用例不能描述为数据库某个表的增删改查，而应从涉众的业务需求出发，描绘真实使用场景；
• 不要把不同涉众的看起来实现类似的用例合并起来，比如把不同用户的查看行为合并为一个查看用例（如员工查看信息，组长审核信息），实际上他们的涉众、用途都是不同的：
• 这里需要警惕：需求不要有“复用”的思想，如果考虑了“复用”，就要警惕是否转换到了设计的视角来思考问题；
• 多个执行者不能指向同一个用例，如果真的无区别，那就应该泛化出更抽象的执行者，如果有区别，则应该区分为不同用例。
• 系统用例不用分层次，如果分了，可能是研究的对象没明确好；用例图中也不应该分模块、子系统，这是设计的思路；
• 用例命名，采用动宾结构，（状语）+动词+（定语）+名词。

一般来说，细节需要明确的会有下面这些内容：

1. 前置、后置条件：

• 前置条件是用例开始前要满足的约束：必须是系统能检测到的！
• 后置条件是用例成功后的约束，是某种状态，而不是一个动作。

• 用例最成功和最核心价值的路径，就是基本路径；
• 路径交互一般可分为四步：请求、验证、改变、回应；
• 路径书写的注意事项：
• 时间的请求写“当到达时间周期时”；
• 验证步骤不要写“是否”，直接写期望的结果；
• 与辅执行者的交互可以是回应；
• 主语要明确责任方（只能是主执行者或系统）；
• 步骤要使用业务的核心术语描述，不要用不同的习惯用语；
• 不要涉及界面交互的细节，这是设计约束；
• 需求的判断标准是：“不这样不行”，而不是“这样也行”，这两者是有区别的。

• 系统能感知到的意外才需要扩展路径；
• 设计、开发不足导致的错误不是意外扩展，比如数据库保存失败，这不是需求需要关心的；
• 不引起交互行为变化的选择分支不是扩展；
• 界面跳转不是扩展。

• 字段列表。
• 业务规则。
• 质量需求。
• 设计约束。

市场上需要花样繁多的各种系统，这是竞争和分工导致的必然结果。很多系统之间可能在关键的点上有微妙差别，但许多内在机制是类似的。如果能高效复用这些机制，软件组织就能以较低成本变出各种系统来满足市场。

《软件方法》

• 核心域的复用：真正涉及到业务的核心域知识，是复用的最重要领域。但大部分软件研发人员，这一步往往都没有做好。
• 非核心域的复用：目前大多数软件组织的复用仅停留在基础设施领域的复用，即使有自己的"内部开发平台"，也仅是根据自己所开发系统的需要对基础设施作进一步封装。这种非核心域的复用，各个公司组织都大同小异，没有长久的竞争优势。

分析类有三种：

• 边界类：输入、输出，及简单的过滤；
• 控制类：控制用例流，为实体分配责任；
• 实体类：系统的核心，封装领域逻辑和数据。

识别分析类与类属性的要点（设计源于需求，高于需求）：

• 命名以专业术语为准。
• 命名不要带冗余信息（不要加类、C、表、库、信息等词）。
• 属性名前不要加类名（冗余）。
• 英文命名则用单数。
• 多处重复的同一概念，命名要一致（如顾客与客户）。
• 类图不能像用例图。
• 类不能像一个过程，而应该是一个对象。
• 分析类属性时，不能完全照搬某张文件表单里的字段，他们不一定是一个领域的。
• 透过现象（非核心域的实现手段）看本质（核心域的机制、专业术语）。
• 属性要能直接用于描述类，在划分属性从属于哪个类时，试试“[类]的[属性]”能否说通。
• 如果属性再分解就得到其他领域的概念（如人的姓名，姓名再分解就是 string 类型，属于其他领域知识），那么这个属性可以留在类中。如果可以继续分解成本领域的概念（比如人的组织，组织可继续分解），可以考虑把这个属性独立出去变成另一个类。
• 多重性大于一的属性，可以再分解出其他类，比如人可以有多个电话，那么电话可以是另一个类（联系方式）。

确定好类后，还需要明确类与类之间的关系，关系分三种：

• 泛化：类似面向对象中的继承，子类通过继承超类而拥有超类的特征，是一种集合关系，如人与男人、女人。识别泛化关系的方法有：
• 对类与类之间，思考 A 是否是 B 的一种，而 B 是否是 A 的一种。
• 对多个已有的类，抽象出公共部分，形成超类。
• 从一般的类，细化出特殊的子类。
• 尽量不要跨领域形成泛化关系。
• 关联：对象通过组装其他对象而拥有其他对象的特征，是个体类间的关系，如人与手、脚。只有系统负责维护的关系，才构成关联。泛化和关联，可以视分析场景进行转变，可用于简化模型。关联的形式有：
• 普通关联（一根直线）。
• 聚合（直线一端是空心菱形）：多个对象和某个对象的关联紧密，视为受其影响的分区（如公司与各个部门）。
• 组合（直线一端是实心菱形）：比聚合更严格，“部分”对象跟随“整体”对象销毁而销毁；“部分”对象只属于一个“整体”对象；“整体”对象负责“部分”对象的创建与销毁。
• 自反关联，即关联发生在同一个类上。
• 依赖：其他不能视为泛化或关联的类间关系。

• 事物：其状态值得关注，在其身上发生领域事件。
• 描述：对象较少，封装某方面的规则，状态变化不值得关注。
• 时段时刻：对象多，属性不应修改。
• 角色：解耦事物与时段时刻。