设计源于需求却高于需求。
《软件方法》上册（五章）所表述的逻辑：
愿景 ------ 业务建模 ------ 需求 ------ 分析 ------ 设计
1. 愿景： 明白软件的意义是什么，帮助或者提高了现有系统的那些方面，减少了那些成本。
利润 = 需求 - 设计
这个公式成立的前提是需求都已经实现，不同的设计会花费不同的成本。但看完上篇，我觉得应该改一改： 利润 = 业务 - 设计。 整个软件制作的过程中，真正的价值和输出是业务，对业务有什么帮助、提高或者减少业务成本。从业务的分析、愿景再到需求的分析之间有一定的距离和不同的理解方式，这一点也很重要。
2. 业务建模：研究 业务用例和业务对象。 业务建模主要是研究这个组织，描述现在的业务事实，划分业务的边界，分析出各个参与方的现象及状况。 反过来给组织一个购买系统的理由，给系统赋予实际的价值。
注：业务和需求分析是两个方面，业务注重对现实的描述，需求是针对于系统的分析。业务不一定和需求是一一对应的关系。业务是现实的描述，一般是不会变化的；但需求可以用不同的方式实现，并且从不同的角度出发看业务时，看到的需求也是不一样的。
3. 需求 ： 研究系统系。统执行者，是指系统外与该系统发生功能性交互的其他系统。 系统用例，系统为执行者提供的、渉众可以接受的价值。 系统用例的粒度，从业务的角度出发去思考这个问题，用例就是为了给系统的执行者用。
- 第一章 建模和UML
1. 该章主要讲软件方法的价值和思路，然后确定本书的观点：建模和软件开发完美的工作流【业务建模-需求-分析-设计】
2. 各个义务模块思考的焦点不一样，从上到下是有严格先后顺序的。
- 第二章 愿景
1. 回答问题，“在老大看来，为什么要引进这样的系统？”
2. WHO的问题：分析清楚相关的涉方，涉及到的组织和系统，利益相关方。
3. WHY的问题：为什么要做这些，现在遇到的问题是什么，系统需要提高那一部分，或者减少那一部分的开销。
4. 设定可度量的目标，量化系统的指标和价值。
5. 分析利益相关方，从不同的涉方去看待系统，明确系统的定位。
- 第三章 业务建模 之 业务用例图
1. 中心思想：软件是组织的零件。书中认为组织和人都可以当做是一个系统，而有没有软件组织都可以进行下去。所以软件就是组织的零件，在业务建模和描述业务的过程中找到组织的弱点，可以改进的地方和可以用系统来代替的地方。然后确定系统的作用，进而分析和设计系统。
2. 用例分析对象是现存的组织，分析流程： 选定要改进的组织--组织的业务用例图
3. 选定要改进的组织：
a). 分析现有的业务组织，列出现有相关业务的参与方；
b). 通过愿景的分析，将涉方画在一个圈里作为研究对象， 这里的涉方有可能是系统，也有可能是组织，也有可能是一个人；
c). 从客户的角度分析现有各个组织的功能，可以利用时序图和用例图分析，搞清楚面对客户和提供某一项服务时，各个系统之间的协作状况；
d). 寻找可以改进的地方和系统的价值所在，在时序图的分析完成之后可以观察时序图，找到系统所要实现的业务模块。
4. 组织业务用例：
a). 业务的执行者：选定要改进的组织之后需要分析系统所承担的业务。第一就是要找到业务的执行者，业务的执行者可以是其他的组织，个人。【肯定是相关组织，业务的分析都是从组织层面的分析】
b). 业务工人和业务实体。业务工人不是系统的执行者，不能和组织内的人混淆，是在组织中的人肉系统。业务执行者喝业务工人，一个在系统的外部一个在系统的内部。但这种的关系随着业务的边界有可能变化，如果包含在业务边界内部，就是业务工人，如果在业务系统的外部就有可能是业务的执行者。业务实体也是在业务边界以内充当着一定的职能，有可能是从业务工人中分离出来的机器，比如银行业务员和点钞机，银行业务员就是业务工人，点钞机就是业务实体，点钞机一定程度承担和业务工人的一部分责任，是从业务工人中分离出来的。
c). 业务用例图： 通过业务时序图来抽象系统的用例，将业务的时序图简化为用系统零件代替。用新流程替代旧流程，明确业务执行者对相关的组织的期望是什么，是具体对哪个组织的期望。
5. 业务用例的分析目的：明确系统的价值和系统对外提供的功能，以及系统会不会达到第一点所提到的愿景。
- 第四章 业务建模 之 业务序列图
1. 中心思想： 在业务用例分析清楚以后，开始描述业务用例的实现，系统所承担的业务流程是怎么样的，以便之后推导出有待开发的系统用例图是什么样的。
2. 业务流程描述的方法： a). 文本； b). 活动图，泳道图，分清楚各个业务组织之间的边界； c). 序列图，时序图：只涉及相关的组织和人，分析清楚交互的动作是什么，交互的内容是什么。
3. 业务序列图的要点： a). 序列图中的箭头消息代表责任而不是数据流，代表承担的功能业务是什么； b). 重点聚焦于系统之间的协作是什么，系统之间的交互是怎样的； c). 只需要关心核心模块的相关的分析； c). 可以把时间作为系统的特殊业务实体。
4. 业务建模的步骤：
现状业务序列图----改进业务序列图
a). 现状业务序列图： 现状不是纯手工，现状不是规范，根据业务序列图要点画出现状业务序列图
，了解认识现状，但不能以要分析的业务系统为中心拼凑。
b). 改进业务序列图： 分析清楚现状之后寻找业务改进的地方。思考的点：信息化、模块划分、职责划分、流程简化、信息流改善、封装领域逻辑。【阿布思考法：假设有充足的资源解决问题，得到一个完美方案；用手上现有的资源得到一个完美的方案】
- 第五章 需求 之 系统用例
1. 需求研究的对象是系统，业务研究的对象是组织。他们之间的研究对象不一样，分析的目的不同。
2. 系统执行者：在所研究的系统之外，能够与该系统发生功能性交互的其他系统。
a). 特点是：系统外、交互、功能性交互、系统。系统外：通过业务用例和业务序列图的分析，明确系统的边界，系统边界之外的都是系统外。交互：系统的执行者除了是系统之外的还必须与系统发生交互，也通过业务用例分析的涉众来明确是否与系统发生交互。功能性交互：系统的执行者喝系统之间发生的交互是系统的功能性需求，从系统执行者来看是执行的利益点。系统：系统可以是一个人肉系统，也可以是一个非人智能系统，甚至是一个特别的外部系统（时间）。
b). 如何识别系统的执行者：通过业务建模，识别系统的交互对象。从业务的序列图种映射系统的执行者。
c). 用例的主执行者和辅助执行者：箭头的指向是主动的访问和消息。从用例指向的外部执行者就是辅助执行者。
3. 系统用例：系统能够为执行者提供的、涉众可以接受的价值。从执行者出发，是执行者的利益诉求点；从系统出发，是系统对相关组织的价值意义。用例思考的过程就是发现价值的过程，从两方面考虑，业务执行者的利益诉求点是什么，系统能够提供的功能是什么。
a). 用例的粒度问题：把握住用例是面向系统，提供给执行者的用例，需要满足执行者的诉求点。
b). 用例是执行者的动作，并不是面向数据库的CURD。用于和动词也必须是执行者能够理解的，在业务序列图种的交互动作。
c). 如何识别系统用例：在业务序列图中，从外部指向系统的交互消息，可以映射为该系统的用例。需要明确系统的边界在哪里。
4. 需求分析中的系统用例可以直接由业务的分析而来，通过业务用例分析，到业务序列图，然后从业务序列图映射到系统的用例。
- 总结
面向对象是一种方法论，怎么去认识真实的世界，是一种思想理论。 UML是用面向对象的思想，分析真实世界的工具和交流的语言，将真实世界翻译成与软件行业交互的语言。《软件方法》中讲述了怎么去按照面向对象的思想，用UML分析真实世界，指导帮助开发软件的方法。
null