第一章 为什么要建模
1.1 建模的四项原理
- 选择创建什么模型，对如何动手解决问题和如何形成解决方案有着意义深远的影响。
- 可以在不同的精度级别上表示每一种模型。
- 最好的模型是与现实相联系的。
- 单个模型或视图是不充分的。对每个重要的系统最好用一小组几乎独立的模型从多个视角去逼近。
第二章 UML介绍
2.1 UML三要素
- UML的基本构造块
- 构造块的放置规则
- 一些公共机制
为了理解系统中的各项事务，需要多个相互联系的模型
2.2 构造块
2.2.1 结构事物
- 类（矩形，其中包括类的名称、属性、操作）
接口（由类提供的对外接口：用线连接到类框的小圆圈；类向其他类请求的接口：用线连接到类框的半个小圆圈）
协作（虚线椭圆）
用况（实现椭圆）
主动类：其对象至少拥有一个进程或线程，因此它能启动控制活动。主动类的对象锁表现的元素行为和其他元素的行为并发，除此以外，它和类是一样的。（类的左右外框画成双线）
构件（矩形，右上角有特殊图标）
制品：如源代码文件、可执行程序、脚本等（矩形，在其名称上方标注关键字
<<artifact>>）结点：运行时存在的物理元素，它表示一个计算机资源（立方体）
制品与结点的区别：
- 制品：物理软件构件
- 结点：硬件设备
2.2.2 行为事物
交互（一条有方向的带有操作名的直线）
状态机（圆角矩形）
活动（圆角矩形，状态和动作靠不同的语境得以区别）
2.2.3 分组事物
包（带标签的文件夹）
2.2.4 注释事物
注解（右上角是折角的矩形）
2.2.5 关系
依赖（可能有方向的虚线，偶尔在其上还带有一个标记）
关联（一条实线，可能有方向，偶尔带有一个标记，经常带有修饰）
泛化（子指向父的，一条带有空心箭头的实线）
实现（一条带有空心箭头的虚线）
2.3 UML中的公共机制
- 详述
- 修饰
- 通用划分
- 扩展机制
2.3.1 通用划分
方法一：对类和对象的划分
用与类同样的图形符号来表示对象，并且在对象名的下面画一道线。
上图表示，Customer类有3个对象，分别为Jan（它被明确标记为Customer的对象），:Customer（匿名的Customer对象）和Elyse（它在详述中被说明为是一种Customer对象）
- 方法二：接口和实现的分离
在这个图中，有一个名称为SpellingWizard.dll的构件，它实现了接口IUnknown和ISpelling，并且还需要一个由其他构件提供的名为IDictionary的接口。
- 方法三：类型和角色的分离
类型声明了实体的种类（如对象、属性或参数），角色描述了实体在语境中的含义（如类、构件或协作等）。
2.4 体系结构
最好用5个互连的视图来描述软件密集型系统的体系结构。每个图是在一个特定的方面对系统的组织和结构进行的投影。
- 用况视图：描述了形成系统体系结构的动力，由描述可被最终用户、分析人员、测试人员看到的系统行为的用况组成。
- 设计视图：包含类、接口、协作，它们形成了问题及其解决方案的词汇。
- 交互视图：展示系统不同部分之间的控制流，包括可能的并发和同步机制。
- 实现视图：包含了用于装配与发布物理系统的制品。
- 部署视图：描述组成物理系统的部件的分布、交付、安装。
第3章 模型基本介绍
3.1 机制与制品
- 机制：类似，可以使用顺序图对事件的次序建模的方式
- 制品：可看作文件或者设备
3.2 静态与动态模型
- 静态模型：常规的体现依赖或继承关系的图
- 动态模型：对行为建模的，顺序图这种描述工作机制的模型
3.3 模型间的联系
即前文，UML的4种关系
3.4 对UML的扩展
我的理解是，一个系统存在不同的观察角度，可以是程序的逻辑视图，也可以是程序的物理制品的视图。
第二部分 对基本结构建模
第4章 类
4.1 类、属性、操作和职责
4.1.1 简单名与限定名
- 简单名：单独的名称
- 限定名：包的名做前缀
4.1.2 属性与操作
属性可以有声明并给定初始值的方式来详述
操作可以添加标记说明参数的名称、类型和默认值或者返回类型
注意：不用把所有的属性及操作都放到类中。未列出的以...表示，也可以直接压缩掉这一栏。
衍型：是为了更好地组织属性和操作的长列表而添加的前缀
4.1.3 职责
相当于类的注释
