UML学习文档（一）
参考资料：
https://zhuanlan.zhihu.com/p/669466741
UMLChina《软件方法》
https://cloud.tencent.com
目录
1. 概论
--需求和设计的关键区别
--核心工作流
--使用UML开发过程、工具、资料介绍
编辑
2. 愿景
--愿景的要点
定位目标组织及其“老大”（也就是系统最优先照顾其利益的那个人）
定位人群
定位机构
提炼改进目标
--愿景的格式
3. A-业务建模
--组织的外部和内部
--选取合适的建模业务单元
--业务执行者和业务用例
--业务用例图
定义
价值
组成
业务执行者
业务用例
业务流程内对应具体的业务对象
--业务用例图不是系统用例图（参考知乎）
--现状业务序列图
--改进业务序列图
物流->信息流
编辑
举例：
改善信息流转
举例：
封装领域逻辑
举例：
4. B-需求
--注意事项
--系统用例图
系统
系统执行者
主执行者
辅执行者
注意
涉众
以餐馆为例
系统用例与系统用例图的定义
系统用例图元素
注意事项
--用例规约
前置、后置条件
基本路径
使用主动语句—理清责任
使用核心域词汇
不涉及界面组件和交互
注意可用性需求和交互设计的区别
路径书写的注意事项
举例：
补充约束
字段列表
业务规则（核心域规则）
质量需求
设计约束
注意事项（精简原则）
格式
用例规约类图：
文字模板（线性式）：
表格模板（表格式）：
--用例关系
扩展（分离扩展路径）
包含（提取公共步骤集合）
泛化（扩展的变体（可不用））
--需求启发技术（从涉众处获取素材）
要领
要领1：
要领2：
研究资料
问卷调查
访谈
观察
研究竞争对手
原型（不等于界面且不一定指图形界面原型）
需求工程师
1. 概论
--需求和设计的关键区别
| 需求 | 设计 |
| 卖的视角 | 做的视角 |
| 具体 | 抽象 |
| 产品当项目做 | 项目当产品做 |
软件开发中需求工作的目的是让系统更加好卖
软件开发中设计工作的目的是降低开发维护成本
--核心工作流
A-业务建模（business modeling）-组织改进
——定位需要改进的目标组织以及该组织接下来最需要改进的问题。
B-需求（requirements）-系统责任
——描述为了改进组织的问题，待引入的信息系统必须具有的整体表现。
C-分析（analysis）-核心域逻辑
——提炼为了满足功能需求，待引入的信息系统需要封装的核心域机制。
D-设计（design）-实现
——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。
--使用UML开发过程、工具、资料介绍
2. 愿景
--愿景的要点
愿景必须有具体的定义，不能是“正确而无用的废话”，大而泛的目标谁都会提，真正具有指导意义的，是具体的细节定义。
定位目标组织及其“老大”（也就是系统最优先照顾其利益的那个人）
定位人群
人群属性必须细化再细化，要找到最有代表性的老大进行调研，而不是大街上随便找一个人，随着互联网发展越来越完善，想要得到市场，只有深耕行业，深耕的意思就是要细化人群，好比要做一个文本编辑器，Word、WPS 等已经很好地满足了绝大多数人的需求，你再去做一个标准编辑器很难卖出去，更好的选择是选择一个细分领域，如医生的病历编辑器，然后把调研的人群定位于医生群体；
定位机构
先明确机构的范围、要替换的既有系统（人脑或电脑），老大应该是目标机构的主管或负责人，且是业务负责人，而不是 IT 负责人，也不是企业最大的领导。在和传统企业或机构的合作中，我们往往会对接一个信息中心主任，但要明确老大应该是最了解业务的人，而不是管信息化的人，只有这样才能靠近最真实的需求。
提炼改进目标
要注意的是，目标应该是改善组织行为的某个指标，如 IoT 设备的材料提交速度、审批步骤等，而不是系统的功能，也不是系统本身的规模、质量，这些都是基于指标分析出的需求和结果
--愿景的格式
| 系统 | XXXX系统 |
| 目标组织 | |
| 老大 | |
| 目标 | |
| 度量指标 |
3. A-业务建模
--组织的外部和内部
外部：价值的集合
内部：系统的集合
--选取合适的建模业务单元
--业务执行者和业务用例
业务执行者：在组织之外的和组织交互的人群或机构
业务用例：组织为业务执行者提供的价值
业务流程：业务用例的实现
--业务用例图
定义
业务执行者希望通过和所研究组织交互获得的价值。
价值
这个价值不是指你（组织）能提供什么而是指我（执行者）想要什么，这个时候就需要把视角放在组织外部，切换到执行者上，看看他希望从组织获得什么，而不是把视角放在组织内部，看组织能提供什么。
比如说以餐馆这个组织为例，其业务执行者主要是顾客，虽然餐馆可以提供零钱兑换、球赛播放、充电宝租借等服务，但是顾客来餐馆就是为了吃饭的，顾客->就餐就是餐馆的业务用例，提供就餐服务就是餐馆这个组织最大的价值。
试想一个餐馆如果不围绕“提供物美价廉的就餐服务”这一理念去经营，而是饭菜质量做的很差，提供了很多充电宝服务，那么这个餐馆的结果可想而知。
组成
业务用例图有几个组成部分：
业务执行者
指组织的边界外，和组织交互的其他组织（人群或机构）；
业务的执行者应该是组织，而不是个人或者系统（因为他们都可能被替代），只有组织才反应了业务的交互；
时间不应该被作为执行者，而应该是对应的业务组织。
业务用例
业务执行者希望通过和所研究组织交互获得的价值（如取款、存款等）。它代表了组织的本质价值，很难变化，会变化的只是用例的实现——业务流程（如取款机取款流程、网银转账流程等）。
业务流程内对应具体的业务对象
业务工人：组织内部的人，可被其他业务工人或业务实体替换；
业务实体：组织中的非人智能系统
--业务用例图不是系统用例图（参考知乎）
- 业务用例是用来捕获功能性需求的，功能性需求是由actor的业务目标来体现的。也就是对于actor来说，他所负责的业务需要由一系列的业务目标组成。
- 业务用例体现了需求，而需求的实现有多种方式。如何实现它，是由系统用例来体现的，它们并不是一个简单的细分关系，虽然看上去抽象。
- 业务用例和系统用例是分别站在客户的业务视角和系统建设视角来规划的。
- 业务用例不是接近，而是完全的直接需求，系统用例也不是业务逻辑的详细划分，而是系统对需求的实现方式，但不是与程序设计无关，它只是说，要建设的系统功能性需求由这些系统用例构成。
所以业务用例和系统用例都是需求范畴，它们分别代表了业务范围和系统范围。
比如：
1.一个档案管理员，他的业务目标就是维护档案。
2.一个论坛管理员，他的业务目标有维护用户，维护帖子等..这些业务目标构成actor职责的全部。
维护档案这样一个业务目标，会有多种不同的用例场景去完成它，这些场景包括如何增加档案，如何修改档案，如何删除档案....对于系统用例来说，就是通过分析这些场景，来决定哪些场景中的哪些部分是要纳入系统建设范围的。假设由于某个原因，修改档案很困难，只能通过先删除，再全部重建的方式来实现，那么系统用例就增加档案，删除档案，而没有修改档案。
区分业务用例图和系统用例图
经过上面的分析，两个用例图的异同点在图中更直观的对比：
两个图的最大的不同就是有无“/”，业务用例图在业务执行者和业务用例上是有“/”的，系统用例图在系统执行者和系统用例图上没有“/”。
--现状业务序列图
消息：责任和目的
人抽象成系统
--改进业务序列图
物流->信息流
举例：
改善信息流转
举例：
封装领域逻辑
举例：
改进前：
改进后：
4. B-需求
--注意事项
涉众(stakeholder)是与建设的企业系统相关的人和事。涉众不等同于用户，用户是系统的使用者，是涉众的一部分。涉众可以是企业内部人员也可以是与企业发生关系的外部组织或实体。涉众与业务系统存在关系，提取涉众并分析各个涉众对系统的期望，对全面分析业务系统有重要意义。
与涉众沟通前，要充分调研好资料，做好知识储备，才能让沟通过程有价值，不能什么也不清楚就去问，没人愿意花时间教你；
针对个体很多的涉众，可以问卷调查，但要注意避免无效答卷（可以埋钉子问题，筛选出明显乱答的）；
做访谈，和真正的不同涉众进行访谈，不能只找好交流的人交流（如只咨询熟悉手机的年轻人，不管中老年）；
善观察，观察涉众的环境、工作流程，甚至亲自去体验；
研究竞争对手，在竞争过程中，不同的阶段需要有不同的战略意识：
- 开拓者：作为市场领先者，要开拓本领域，不要只关心追赶者；
- 追赶者：研究领先者的优点，攻击其强势外表下背后的弱点；
- 侧翼战：专攻细分市场做创新，也能占据一份市场；
- 游击战：依靠地域优势、人际关系来生存，并逐渐凝聚出自己的特色。
通过需求启发，希望能够打造出尽可能有价值的系统来。
--系统用例图
系统
封装了自身的数据和行为，能独立对外提供服务的东西才能称为系统。
要注意的系统是一个整体，系统可能会有很多子系统。
比如银行转账交易时候需要做风控，如果有商家向银行售卖交易系统，那么风控这个子系统肯定是包含在整个交易系统内的，一起打包卖给银行的。
系统执行者
系统执行者是在所研究系统外，与该系统发生功能性交互的其他系统。
主执行者
主动发起用例。
辅执行者
用例进行过程中被目标系统请求。
注意
系统执行者一定是在系统外的，可以是人或者其他系统。
系统执行者必须是要和系统有交互的。
系统执行者不一定是业务执行者。
涉众
涉众是与要建设的业务系统相关的一切人和事，系统执行者也是涉众的一部分。
以餐馆为例
假如顾客是通过口头告诉服务员（不是自己扫码下单）我要点啥菜，服务员通过下单系统为顾客下单，那么研究这个下单系统可以得出：
1.系统执行者：服务员，虽然顾客作为餐馆这个组织的业务执行者，但是与下单系统直接交互的是服务员，所以服务员才是点餐系统的系统执行者；
2.涉众，这个就很多了，顾客、服务员、餐馆老板、厨师等等都是涉众，因为都是下单系统的利益关系者；
a.顾客担心自己下单没成功，等了很久不上菜；
b.服务员担心没出单导致顾客投诉，自己奖金被扣；
c.老板担心系统故障引起很多顾客投诉，生意受到影响；
d.厨师担心下单系统分配不合理，所有的菜都分配给自己做；
一般这个下单系统可以登录、下单，查看下单记录，这些都是下单系统的一些功能。
| 登录 | 下单 | 查看下单记录 | |
| 服务员 | 我需要，要不然别人下错单了怪我头上咋办 | I need it！ | 我需要，方便查看顾客菜品上齐了没 |
| 顾客 | I don't care！ | 能不能下单直接影响我能不能吃上饭 | 我也需要，得打印出来我的菜单，结账时候好核对 |
| 老板 | 我也需要，可以看看服务员的工作情况 | 下单系统不能下单我买它来干啥 | 我需要，方便订单管理，也方便看看哪个菜客人点的最多 |
| 厨师 | I don't care！ | 不能下单谁告诉我该做什么菜 | 我需要，要不然说我少做了一道菜没法解释 |
所以，从上可以得出下单、查看下单记录满足系统用例的概念，系统用例图如下
可以看到，和业务用例不同的是在研究系统用例时我们需要把视角切换到系统，从系统出发看看能为执行者提供什么样的、涉众都可以接受价值。
系统用例与系统用例图的定义
系统用例是系统能够为执行者提供的、涉众可以接受的价值。
（期望和承诺的平衡点&买和卖的平衡点）
系统用例图就是用图形展示“谁能用这个系统做什么”。它属于UML（统一建模语言），专门用来描述系统的功能需求，以及外部用户或系统如何与它互动。
系统用例图元素
系统边界 (大方框)： 圈定你要研究的系统范围，名字写在框顶。
用例 (小椭圆)： 代表系统提供的一个具体功能点，比如“用户登录”、“下单支付”。
参与者 (小人或方块)： 代表在系统外部、与用例互动的角色，比如“顾客”、“管理员”或“银行支付系统”。
关系 (连线/箭头)：包括关联（参与者与用例之间的交互关系）、包含（用例之间的复用关系）、扩展（用例的可选行为）和泛化（参与者或用例之间的继承关系）。
注意事项
1.用例的名字一般是动宾结构，也就是“动词+名词”，但是不严格要求的。比如“成果分析”这个行业术语没必要硬倒过来改成“分析成果”
2.老老实实去研究业务流程，做好业务建模，尽量从业务序列图中映射出系统用例，这样得到的系统用例才是最真实的。
3.用例是可以有主执行者和辅执行者的：主执行者从执行者指向用例，而辅执行者从用例指向执行者，主执行者发起用例的交互，辅执行者在交互过程中被动参与进来。一般说来，辅执行者是人肉系统的情况比较少，更多时候是另一个非人智能系统。
4.主执行者和辅执行者是相对于用例来说的，“ xx 是xx用例的主/辅执行者” 是正确的，“ xx 是xx系统的主/辅执行者” 说法是错误的。
对系统用例图中的用例，也有以下几点要求：
- 在业务序列图中，从外部指向系统的消息，即可映射为系统的用例，所以画好业务序列图，也就能得到准确的系统用例；
- 用例必须是可以对执行者带来价值的，而不是任何一步繁琐的交互都算；
- 用例要明确其主要的目标客户，而不是谁可以来做就算作谁的用例，用例满足的是目标用户的期望；
- 用例不能描述为数据库某个表的增删改查，而应从涉众的业务需求出发，描绘真实使用场景；
- 不要把不同涉众的看起来实现类似的用例合并起来，比如把不同用户的查看行为合并为一个查看用例（如员工查看信息，组长审核信息），实际上他们的涉众、用途都是不同的：
- 这里需要警惕：需求不要有“复用”的思想，如果考虑了“复用”，就要警惕是否转换到了设计的视角来思考问题；
- 多个执行者不能指向同一个用例，如果真的无区别，那就应该泛化出更抽象的执行者，如果有区别，则应该区分为不同用例。
- 系统用例不用分层次，如果分了，可能是研究的对象没明确好；用例图中也不应该分模块、子系统，这是设计的思路；
- 用例命名，采用动宾结构，（状语）+动词+（定语）+名词。
--用例规约
| 需求类别 | 用例规约中的对应 |
| 功能需求 | 用例路径步骤字段列表业务规则 |
| 质量需求 | 质量需求 |
| 设计约束 | 设计约束 |
系统用例，描述了系统对外提供的一个个服务与价值，实际上是系统要达成的一个功能目标。
但要落实到需求方面，还远远不足，需要更加细化。
用例规约可以是文档的形式，但也可以直接画在 UML 图中，主要还是讲清楚细节。
一般来说，细节需要明确的会有下面这些内容：
前置、后置条件
前置条件是用例开始前要满足的约束：必须是系统能检测到的！
后置条件是用例成功后的约束，是某种状态，而不是一个动作。
涉众利益：要考虑用例过程中，涉众的利益，涉众来自系统的人类执行者，要充分考虑上下游以及信息来源的涉众，综合考虑他们的利益诉求。
基本路径
记录一个系统用例的步骤
用例最成功和最核心价值的路径，就是基本路径；
路径交互一般可分为四步：请求、验证、改变、回应；
使用主动语句—理清责任
| 错误 | 评点 | 正确 |
| 会员保存订单 | 保存在自己肚子里？ | 会员提交订单信息系统保存订单 |
| 会员查询商品 | 会员在自己肚子里面查？ | 会员提交查询条件系统查询商品系统反馈查询结果 |
使用核心域词汇
| 系统 | 描述 | 涉众 | 合格吗 |
| 零件采购系统 | 系统建立连接，打开连接，执行SQL语句， | 从“零件”表查询… 采购员 | 不合格 |
| 零件采购系统 | 系统按照查询条件搜索零件 | 采购员 | 合格 |
| 数据访问框架 | 系统建立连接，打开连接，执行SQL语句 | 开发人员 | 合格 |
不涉及界面组件和交互
| 错误示例 | 更正 |
| 系统显示订单信息 | 系统反馈订单信息 |
| 系统反馈查询到的商品列表 | 系统反馈查询到的商品 |
| 会员拖动商品到购物篮，勾选优惠券，点击结算按钮 | 会员输入商品和优惠券信息，请求结算 |
| 顾客填写用户名 系统验证用户名未被使用 顾客填写密码 系统验证密码合法 | 顾客提交用户名和密码 系统验证用户名和密码合法 |
注意可用性需求和交互设计的区别
90%的顾客应该能在6秒种内，通过少于四次动作，定位任意一条视频
-需求工程师的责任
什么样的交互界面适合满足这样的需求
-交互设计师的责任
如何用软件组件实现这样的交互界面
-程序员的责任
判断需求的标准：不这样行吗
扩展：系统要处理的意外和分支
路径书写的注意事项
- 时间的请求写“当到达时间周期时”；
- 验证步骤不要写“是否”，直接写期望的结果；
- 与辅执行者的交互可以是回应；
- 主语要明确责任方（只能是主执行者或系统）；
- 步骤要使用业务的核心术语描述，不要用不同的习惯用语；
- 不要涉及界面交互的细节，这是设计约束；
- 需求的判断标准是：“不这样不行”，而不是“这样也行”，这两者是有区别的。
- 扩展路径：记录异常、意外情况处理的路径，需要注意：
- 系统能感知到的意外才需要扩展路径；
- 设计、开发不足导致的错误不是意外扩展，比如数据库保存失败，这不是需求需要关心的；
- 不引起交互行为变化的选择分支不是扩展；
- 界面跳转不是扩展。
有了以上这些信息，基本就能对需求有一个完整的描述和印象了。
举例：
| 目标系统 | 用例 | 前置后置条件 | 错误原因 |
| 保单系统 | 内勤→录入保单 | 前置条件：有等待内勤录入的保单 | 检测不到 |
| 收银系统 | 收银员→收银 | 后置条件：顾客已带着所购商品离开商店 | 检测不到 |
| 取款机 | 储户→取现金 | 前置条件：储户账户里有足够的余额 | 用例开始前检测不到 |
补充约束
用于扫除路径步骤中的模糊，可以直接放在用例中，也可以单独集中到另外的文档，从用例规约指向。
字段列表
可用自然语言，也可用表达式
和步骤输入、输出相关：
1.不同于数据模型或类模型－－只是一部分
可以用E/R图或类图作为辅助说明，但不宜直接作为需求
2. 不等于“数据字典” －－容易过早把时间花在细节上
一开始好像做了很多事情，其实却回避了最困难的问题
业务规则（核心域规则）
决策表
文字说明
行业上适用的任何方式
质量需求
可用性
- 系统是否按程序员的意图工作
- 系统是否可以执行任务
- 系统能按照程序员意图工作，并且支持任务，但用户是否知道如何使用系统执行任务或者用户是否喜欢使用系统执行任务
- 表达方式举例：
人事专员第一次使用时30分钟内能学会添加新员工（任务时间）
前台5次击键能完成客人入住服务，不需要使用鼠标（操作次数）
可靠性
- 系统应能防范磁盘故障（安全）
（对照）系统应采用冗余磁盘阵列
- 系统应保证收到的数据和发送的数据一致（完整）
- MTBF（Mean Time Between Failures）（稳定）
- MTTR（Mean Time To Repair）（稳定）
性能
- 系统应在0.5秒之内拍摄超速车的照片（速度）
- 系统应允许1000个用户同时使用（容量）
- 在标准工作负荷下，系统的CPU占用率应少于50%（能力）
可支持性
- 95%的紧急错误应能在30工作时内修复
- 在修复故障时，未修复的相关缺陷平均数应小于0.5
- 在两年内，以每功能点××的价格升级系统
- 升级新版本时，应保存所有系统设置和个人设置
设计约束
- 界面样式
- 报表
- 平台
- 语言
- 外系统接口
注意事项（精简原则）
- 和涉众利益对照，涉众利益不能省
- 路径步骤和前置后置可省其一
- 交互类似的用例，写一个作为样例即可
- 非关键用例，可以不写用例规约
格式
用例规约类图：
文字模板（线性式）：
用例编号：UC001
用例名：下采购订单
执行者：
采购员（主）、供应商（辅）
前置条件：
系统中保存有供应商信息
采购员在系统中有账号及权限
后置条件：
系统保存采购订单
涉众利益：
采购员觉得方便
会计方便统计
老板
基本路径：
1. 采购员提交采购申请
2. 系统显示供应商选择列表
3. 采购员选择供应商（或者）
4. 采购员完善订单信息
5. 采购请求录入订单项详细信息
6. 系统显示订单项详细信息
7. 采购员录入需购买产品（服务）详细信息（同时，选择支出科目类别）
8. 重复第7步，直到采购员录入完所有订单项的信息，并确认
9. 系统保存订单信息
10. 系统显示订单已保存
扩展路径：
2a，采购供应商未在列表中
2a1：新增供应商（参考用例UC002）
字段列表：
订单信息：采购员ID+日期+供应商+项目+账期+客户+说明
订单项详细信息：订单ID+日期+描述+（支出科目）+数量+单价+税率
业务规则：
账期：普通的账期30天，采购量在1000万/年的账期60天。
税率：7%
质量需求：
可用性：20分钟可以学会添加订单，系统需要同时支持手机操作
可靠性：
性能：
可支持性：修复bug的时间<2小时
设计约束：
采用网页版的前端，数据存放在postgres数据库。
表格模板（表格式）：
| 步骤 | 基本路径 | 扩展路径 | 补充约束 |
| 1 | 字段列表 业务规则 质量需求 设计约束 |
--用例关系
扩展（分离扩展路径）
包含（提取公共步骤集合）
泛化（扩展的变体（可不用））
--需求启发技术（从涉众处获取素材）
要领
要领1：
交流内容聚焦于涉众利益，涉众无资格、无责任提供需求
要领2：
交流形式采用视图启发技能，交流和开发分离
模型和视图分离
交流和开发分离
视图的宽松和模型的严格
研究资料
知识准备
研究内容
--行业书籍文章、竞争态势
--工作手册、规章制度
--工作表格、作业日志、Email…
--过去的涉众利益积累
通过类图整理领域知识
通过序列图整理业务流程知识
涉众利益预整理
问卷调查
访谈
- 涉众
（名副其实，不能是主管等，选择经验丰富的）与需求人员直接交流收集信息
单独访谈，鼓励涉众参与的积极性
（二）需求人员的注意事项：
- 客服心态，谈话前，尽量了解对方
岗位的“重要性”
有哪些得意事迹
- 手机静音，收起来
- 姿态：身体前倾、点头、嗯－嗯
- 手上做笔记（表明重视）
- 适当的时候作两句总结
- 自己做笔记－－节奏经常被打断
- 录音－－只记录了声音
- 录像－－可以看到肢体语言，可能影响受访者
- 两人做笔记+双份录音，有可能的话录像(要取得授权)
- 把录音录像当作好像不存在
（三）问题技巧：
好事说本人
坏事说别人
-以前这个岗位出过什么问题
-其他类似单位发生过什么问题
引导涉众举例，具体不要抽象
用“最”激发涉众
不要忽略人脑的逻辑
观察
亲身体验涉众的工作－－最直接，某些情况下最艰难
研究竞争对手
防御战
领先者完善自己，进攻另外的领域（Google vs. Google，微软 vs. 微软）
进攻战
攻击领先者强势中的弱点（Compaq vs. IBM，Nokia vs. Motorola）
侧翼战
在无人区发动突击（各种创新…）
游击战
紧紧守住小块市场（××晚报，小区商店）
原型（不等于界面且不一定指图形界面原型）
| 原型类别 | 说明 | 优点 | 缺点 |
| 水平原型 | 只描述表面部分，不深入内部 | 可以直观演示功能需求 让涉众判断遗漏和错误 | 不能代表非功能需求－可能速度很快 注意力应集中在功能上，而不是外观的精确设计 |
| 垂直原型 | 在整个技术层面上实现某项功能 | 验证非功能需求 验证设计约束 | 被挑中的功能不一定是优先级最高的功能 注意力应集中非功能需求上 |
| 静态原型 | - | - | - |
| 动态原型 | - | - | - |
| 低保真原型 | - | - | - |
| 高保真原型 | - | - | - |
| 废弃型原型 | - | - | - |
| 演化型原型 | - | - | - |
需求工程师
