本系列笔记是针对张传波老师所著的《火球：UML大战需求分析》的学习笔记，内容完全是对张老师书籍中重点内容的摘抄。如有侵犯，请联系本人处理。

目录

二、分析业务模型——类图

2.1 类和类图

2.1.1 类

类：需求中提到的各种业务概念、人物等，进过抽象后都可以视之为类。

类的用途：每个软件系统都会涉及到很多人、业务概念和物品等，这些东西之间可能会有很多关系，发生很多事情。类图能帮助我们识别出这些人、业务概念、物品和事情等，并理清它们的关系。

2.1.2 类图

一个类的类图

一个类就是一个矩形的方框，最上面是类的名字，中间是属性（Attribute），最下面是操作（Operation）。表示一个类时，可只显示类名，也可以只显示类名和属性，或者是类名和操作。

+  Attribute A: int

“+”表示这个属性是public类型的（“-”表示private），冒号后面的int，表示属性的类型是int型（整数型），往往在需求分析初始阶段，可不必标注属性的类型。

每一个类应该具备表征它核心特点的关键属性，而一般的无特殊意义的属性，可不必标记进去。

2.1.3 抽象类

注意图中抽象部门四个字是斜体字，这表明这个类是抽象类（Abstract Class），抽象类表示这个类是提炼出来的一种概念，不是具体存在的，具体存在的是继承抽象部门的各个具体的部门。

2.1.4关联类

上图中在表示公司与雇员关系的直线上，拉出一条虚线，虚线另一端连接劳动合同类，这样的类叫做关联类（Association Class），关联类是对两个类的关系的进一步约束。

2.2 类之间的关系

2.2.1 关联关系（Association）

a. 一对一的关系

b. 一对多的关系

c. 一对零到三个的关系

d. 角色关系

角色前的“+”号表示这个角色的类型是public，“-”号则表示private。

e. “导航”关系

表示由“教师”可以找到“学生”

2.2.2 “包含”关系

两种“包含”关系：聚合和复合

a. 聚合关系（“弱”包含）Aggregation

班级消失，则学生依然存在。学生可属于多个班级。

b. 复合关系（“强”包含）Composition

班级消失，学生消失。学生仅属于此班级。

c. “包含”关系中的数量关系

存在0到多个班级、0到多个学生，每个学生仅属于某一班级。

2.2.3 “继承”关系（泛化Generalization）

表示A继承了B，A具备B的特点，同时也有自己特有的特点，注意不要搞错继承方向。

UML中文标准术语是泛化（Generalization），上图可读作：A泛化为B。

2.2.4 “依赖”关系（依赖Dependency）

表示A依赖于B，依赖程度是相对而言的，不一定是A没有B就无法存在了。在具体的业务逻辑中，对于某个事情，A需要B来协助才能完成，这样也是一种依赖。

2.2.5 读图检查法

你可以分别从左往右、从右往左来读图，看看有没有不合理的地方。以上图为例，从左往右读：1个你对应多个你的另一半。从右往左读：1个你的另一半对应1个你，而不要读成多个你的另一半对应１个你。

注意：由“多”的一边往另一半读时，仍然是1个什么对应多少个什么，无论你从哪边开始读起，都是由“1个……”开头。

2.2.6 “递归”关系

“自包含”

“自关联”

2.2.7 “三角”关系

2.3 如何识别类

用类图获取需求的大致步骤如下：

1） 识别出类；

2） 识别出类的主要属性；

3） 描绘出类之间的关系；

4） 对各类进行分析、抽象、整理。