一、建模和uml
利润 = 需求 - 设计
需求：解决“提升销售”的问题
设计：解决“降低成本”的问题
从需求直接映射设计，会得到大量重复代码；
从设计出发来定义需求，会得到一堆伪需求。
| 需求 | 设计 |
|---|---|
| 解决“提升销售”的问题 | 解决“降低成本”的问题 |
| 卖的视角 | 做的视角 |
| 具体 | 抽象 |
| 产品当做项目 | 项目当产品做 |
| 设计源于需求，高于需求 |
建模工作流
| 建模工作流 | 功能 |
|---|---|
| 业务建模 | 描述组织内部各系统如何协作，使得可以为其他组织提供有价值的服务。 |
| 需求 | 描述为了解决组织的问题，系统必须具有的表现——功能和性能。 |
| 分析 | 提炼为了满足功能需求，系统需要封装的核心域机制。 |
| 设计 | 为了满足质量需求和设计约束，核心域机制如何映射到选定平台上实现。 |
不同工作流产出的工件之间的区别不在于形式，而在于内容，也就是思考的边界。如果清楚了这点，及时使用C，照样可以表达需求，用word也可以“编码”
UML应用于建模工作流
（●表示优先使用，√表示可以使用）
二、业务建模和愿景
定义：一个东西的愿景就是：东西最应该卖给谁，对他有什么好处？
爆炸法
假设投资人在你身上绑了炸弹，要你在几分钟内把当前研究的系统推销出去，且只能找一个人推销。假设这个炸弹可以感应脑电波，推销完毕后，如果炸弹感应到被推销的人对这个系统不感兴趣，就会爆炸。这种情况下，你会向谁推销，推销时选择说什么话？这个问题的答案就是老大和愿景。
定位目标组织和老大
目标组织：待引入系统将改进其流程的组织。可以是一个机构，也可以是一个人群。
老大：目标组织的代表。
思考几个问题：
- 用户满意就是好产品吗？
- 谁是用户？
- 凭什么人家就满意？
例子：可乐想要卖给谁？
正确而无用的废话：卖家消费者、卖给想喝可乐的人。
三、业务建模之业务用例图
3.1 识别业务执行者
定义：在组织之外和组织交互的对象就是该组织的执行者。
例如，以某国税局为研究对象，可以观察到企业财务人员到国税报税，但是业务执行者不是企业财务人员，而是企业。
3.2 识别业务用例
定义：业务用例指业务执行者希望通过和所研究组织交互获得的价值。
以上图为例，业务用例就是存款、取款、转账。
业务用例应该是稳定的，很难变化。业务用例代表组织的本质价值，很难变化，变化的是业务用例的实现——业务流程。
我们把业务流程看做是业务用例的实现。
先归纳出组织对外提供什么价值，再思考如何更好地优化组织内部流程来实现这些价值。
用好用例：关键在于理解“价值”。价值是期望和承偌的平衡点、买卖的平衡点。
患者到医院的目的应该是看病，而不是挂号。
业务用例是组织对组织的服务，相对于系统为系统提供的服务（系统用例）来说，所需要的时间是比较长的，不能把用例实现过程中的某个交互片段当成用例。
一些带有“系统”味道的词汇： 新增、查看、录入、查询、修改、配置……
识别业务用例的思路：
- 从业务执行者开始，思考业务执行者和组织交互的目的；（主要的）
- 通过观察组织的内部活动，一直问为什么，向外推导出组织外部的某个业务执行者。（补漏）
常见的错误：
- 把业务工人的行为当做业务用例
- 业务用例随带引入系统伸缩
从组织的价值来推导系统应该具备什么价值才会对组织有帮助。
- 把害怕漏掉的扩展路径片段提升为业务用例
4. 管理型业务用例，这样的“业务用例”不可取。没有特定组织的味道，哪家盈利机构不是为了赚钱？
四、业务序列图
业务序列图要点：
- 消息代表责任分配而不是数据流动
正确的应该是员工使用财务主管的“审批报销单”的服务。
- 抽象级别是系统之间的协作
业务建模的研究对象是组织，出现在业务序列图生命线上的对象，其最小颗粒是系统。
- 只画核心域相关的系统
如果描述的是采购流程，应该画成左边这样。如果描述的是工作人员制作文档，可能是要画成右边这样，还要具体分析。
- 把时间看做特殊的业务实体
6. 为业务对象分配合适的责任
阿布思考法：
- 假设有充足的资源去解决问题，得到一个完美方案；
- 用手上现有的资源去山寨这个完美方案。
五、系统用例图
系统用例的定义：系统能够为执行者提供的、涉众可以接受的价值。和业务用例图相比较，研究对象从组织变成了系统。
系统执行者要点
系统执行者的定义：在所研究系统外，与该系统发生功能性交互的其他系统。
- 系统是能独立对外提供服务的整体
- 系统边界是责任的边界，而不是物理边界
- 系统执行者和系统有交互
- 交互是功能性交互
- 系统执行者可以是人或非人系统
识别系统执行者
业务序列图上，和所研究系统有实线相连的对象映射为所研究系统的执行者。
系统用例要点
- 价值是买卖的平衡点
- 价值不等于“可以这样做”
- 增删改查用例的根源是从设计映射需求
- 从设计映射需求的错误二：“复用”用例
- 系统用例不存在层次问题
- 用例的命名是动宾结构（如果“名词+动词”已经成为行业中的一个术语，也未必要严格的动宾结构）
六、用例规约
- 前置条件和后置条件
- 前置条件：用例开始前，系统需要满足的约束
- 后置条件：用例结束后，系统需要满足的约束
- 前置条件和后置条件必须是系统能检测
- 前置后置是状态，不是动作
- 前置后置条件要用核心域词汇描述
- 涉众利益
- 业务规则
- 设计约束
- 基本路径
- 按照交互四部曲书写：（请求、验证、改变、回应）
- 只写系统能感知和承偌的内容
- 使用主动语句理清责任
- 主语只能是主执行者或系统
- 使用核心域属于描述
- 不要涉及界面细节
- 不要涉及交互细节
- 需求是“不这样不行”
- 扩展路径：基本路径每一步都可能发生意外，其中某些意外是系统要负责处理的，处理意外的路径就是扩展路径。
- 补充约束
- 字段列表
- 业务规则
- 质量需求
- 性能、可靠性、可支持性
- 设计约束
七、需求启发
- 需求启发要点
- 和涉众交流的形式应该采用视图，而不是模型
- 和涉众交流的内容应该聚焦涉众利益，而不是需求
- 需求启发手段
- 研究资料
- 问卷调查
- 访谈
- 观察
- 研究竞争对手
- 需求人员培养
- 好奇心
- 搜索力
- 沟通力
- 表达力
- 热情
八、分析
本书使用类图、状态机图、和 序列图三种UML图形来表达面向对象的分析模型。
- UML类图表达分析类模型
- UML状态机图表达分析状态机模型
- UML序列图表达分析交互模型
识别类和属性
分析类
- 边界类
- 责任：接收输入、提供输出以及做简单的过滤
- 控制类
- 责任：相当于用例在系统中的“代理”，控制用例流，为实体类分配责任。如果在分配责任时发现控制类只起到传递的作用，没有起到分解和分配的作用，也可以把控制类去掉。
- 实体类
- 使用严谨的领域属于命名领域模型中的元素
| 构造型 | 责任 | 和需求的关系 | 命名 |
|---|---|---|---|
| 边界类 | 输入、输出以及简单的过滤 | 每个有接口的外系统映射一个边界类 | 外系统名称 + 接口 |
| 控制类 | 控制用例流，为实体类分配责任 | 每个用例映射一个控制类 | 用例名称 + 控制 |
| 实体类 | 系统的核心，封装核心域逻辑和数据 | 用例和实体类的关系是多对多的 | 领域概念名称 |
