大象Thinking.in.UML第二版读书笔记第2章：建模基础

1、建模

两个问题：
1.怎么建
做需求时，不需要弄清楚业务是如何一步步完成的，而是要弄清楚有多少业务的参与者（actor），每个参与者的目标是什么，参与者的目标就是你的抽象角度。这实际上就是用例（use case）

1.模是什么
模：一个由抽象角度确定了的目标需要由静态的事务加上特定条件下产生的一个特定的场景来完成。说白了就是：
静态的事物（物）+特定的条件（规则）+特定的动作（参与者的驱动）=特定的场景（事件）

人=业务主角，业务工人，参与者
事=业务用例，系统用例
物=业务实体、实体

建模公式

2、用例驱动

用例驱动方法的原理
整个软件生产过程就是用例驱动的。也就是说软件就是一个实现用例的的过程。进一步说就是为事、物、规则和行为实现所有必要的用例，这个问题领域（场景）就被解决了。一旦用例实现了，问题领域就解决了。

软件开发中，所有的分析，设计，实现，测试都是由用例来驱动，即以实现用例为目标。

在同一过程中，一个用例就是一个分析单元、设计单元、开发单元、测试单元、部署单元。

用例驱动的内容

1、逻辑视图：

• 系统只有一个逻辑视图，即人，事，物，规则是如何分类组织的

2、进程视图：

• 系统只有一个进程视图，以图形方式说明了系统中进程的详细组织结构，其中包括类和子系统到继承和线程的映射。
• 即人、事、物、规则是如何交互的。他们的关系如何。也是所谓的分析设计视图

3、部署视图：

• 系统只有一个部署视图，以图形方式说明处理活动在系统中各节点的分布，包括进程和线程的物理分布。
• 即人、事、物、规则是如何部署在物理节点（主机、网络环境）上的

4、实施视图：

• 作用是获取为实施指定的构架决策，包含
• 列举实施模型中的所有子系统
• 描述子系统如何组织为层次和分层结构的构件图
• 描述子系统间的导入依赖关系的图解

3、抽象层次

抽象层次越高，具体信息越少，但概括能力越强，反之则反是。从信息的表达能力上说，抽象层次越高表达能力越丰富，越容易理解。（不用关注细节，因此好理解）。这可以延伸到选择用例的粒度。

抽象的两种方法

• 自顶向下
• 自底向上

在软件开发过程中，主体上应当采用自顶向下的方法，用少量概念覆盖系统需求，再逐步降低抽象层次，知道代码编写。

同时辅以自底向上的方法，通过总结在较低抽象层次的时间经验，来改进较高层次的概念以提升软件质量。

4、视图

1、视角
建模的目的是向相关的人（干系人）展示将要生产的软件产品。UML里面定义了用例图，对象图，类图，包图，活动图等不同的视图（视角）。所有这些视图的集合表达了一个软件的完整含义。

5、对象分析方法（实际就是多角度抽象）

1、一切都是对象
2、对象都是独立的（独立于所处的场景）
深入了解对象，我们需要经常分析很多个该对象的实例所参与的场景，以获得对象的多个侧面，再通过归纳整理这些独享的多个实例抽象出对象的一般特性，这就是对象的分析方法。

这样当你发现多个场景中的对象最终可以抽象成一个共同的对象

3、对象具有原子性

• 在同一个抽象层次上，分析过程中都应当将对象视为一个不可分割的院子，即便这个对象的规模很大。
• 在分析过程中，对象总有一个便捷，永远也不应该打破便捷去窥探内部的对象。
• 我们应当将分析过程中得到的所有对于对象的认识附加在对象边界上，在实现这个对象之前不理会其内部的细节，这称之为面向接口编程。

4、对象都是可抽象的

• 对象所具有的方面，或者说对象所参加的场景越多，对象越有抽象价值，反之则越没有抽象价值。

5、对象都有层次性

• 应当根据问题领域的复杂程度设定多个抽象层次，在每个层次上使用合适的抽象程度的对象描述。