- 第四章 业务建模 之 业务序列图
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分析真实世界，指导帮助开发软件的方法。