【软考】信息系统开发基础 - UML事物、用例图关系 和类图关系（类模型）详解

一、UML中的事物

1.1 包含四类事物

• 结构事物
• 行为事物（动作事物）
• 组织事物（分组事物）
• 辅助事物（注释事物）

这些事物是UML模型中面向对象的基本建筑块
他们在模型中属于静态部分，代表物理上或概念上的元素。

1.2 四类事物图解

二、 UML - 用例图

2.1 什么是用例图？

由参与者（Actor）、用例图（Use Case）、系统边界、箭头组成，用画图的方法来完成。

用例描述：
用来详细描述用例图中每个用例，用文本文档来完成，以及由箭头所组成的所有关系
包括泛化，包括，扩展等。

2.2 用例图有什么作用？

• 获取需求，帮助开发团队以一种可视化的方式理解系统的功能需求，包括基于基本流程的“角色”关系
• 指导测试
• 在整个过程中的其他工作流起到指导作用。

三、 UML - 用例图关系

3.1 包含关系（Include）

3.1.2 图解

箭头指向的用例为被包含的用例
箭头出发的用例为基用例

3.1.3 说明

其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例系：
当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。
使用包含用例来封装一组跨越多个用例的相似动作（行为片段），以便多个基用例复用，
做基用例时，必然会做它所包含的事件。
eg：取款机的使用，包括了“识别客户”+“验证账号”，而且是必须要做的哦。
包含用例是必选的，如果缺少包含用例，基用例就不完整了

3.1.4 其他说明

几个用例可以提取他们共用的用例作为子用例，使其成为自己行为的一部分，因为子用例被提出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。由基用例指向子用例，比如几个用例都要用到登录子用例，登录作为子用例没有它的参与，其他用例也无法执行，这就是包含关系。

3.2 扩展关系 （Extend）

3.2.1 图解

箭头指向的用例为被扩展的用例
箭头出发的用例为基用例

3.2.2 说明

如果一个用例很明显地混合了两种或两种以上的不同场景，即根据情况可能会发生多种分支，则可以将这个用例分为一个基本用例和一或多个扩展用例，这样描述可能更清晰

将基用例中一段相对独立并且可选的动作，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使用基用例行为更简练和目标更集中，
做基事件之后，我们能做扩展事件，也可能不做。

3.2.3 其他说明

当某个新用例在原来的用例基础上增加了新的步骤序列，则原来用例被称为基用例，这种关系称为扩展关系，可以这样理解这里的基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能，只有当扩展点被激活时，子用例才会被执行。由子用例指向基用例，比如说充值金额查询用例中有导出Excel子用例，离开子用例不影响充值金额查询的功能，这就是扩展关系。

3.3 泛化关系（Generalization）

父子关系

3.3.1 图解

父用例是“订票”，
其两个子用例分别是，电话订票和网上订票、
这两个用例都继承了父用例的行为，并添加了自己的行为。

一般和特殊关系

发出箭头的一方代表特殊一方
箭头指向的一方代表一般一方

3.3.2 说明

当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象为父用例，其他的用例作为泛化关系中的子用例，在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构，行为和关系。

泛化和类中的泛化概念是一样的哦

常存在于父类与子类，父接口和子接口之间。
子用例继承父用例的行为和含义，还可以增加或覆盖父用例的行为
子用例可以出现在任何父用例出现的位置（父和子均有具体的用例）

包含关系（Include） VS 扩展关系

关键在于离开子用例，基用例是否可以完成一个完整的功能。

四、 UML - 类图关系

（类与类之间的关系）（类模型）
辨析UML中类之间的六大关系

英文代表关系

泛化和实现体现了逻辑上的"is a"的关系
组合、聚合和关联体现了逻辑上的"has a"的关系
“依赖”体现了逻辑上的"use a"的关系。

六种关系的耦合度大小是：泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖

4.1 依赖关系（Dependency）

4.1.1 说明【连接/使用关系】

• 逻辑上能用"use a"表示。

• 一个事物发生变化 ， 影响另一个事物

• 表示两个或多个模型元素之间

• 语义上的连接关系，是一种使用关系

• 即一个类的实现， 需要另一个类的协助。

• 描述了一个类的变化对依赖于它的类产生影响的情况

• 尽量不要使用双向依赖。

4.1.2 代码体现

局部变量、方法的参数和静态方法的调用。

4.1.3 UML绘图方式

虚线箭头
箭头指向被使用者
一条虚线+箭头

4.2 泛化/继承关系 （Generalization）

4.2.1 说明【特殊/一般关系】

• 逻辑上可以用"is a"表示。

• 描述的“is a kind of”的关系

• 描述类的一般关系与具体之间的关系

• 这种关系就是面向对象语言中的继承关系

• 若类B除具有类A的全部特性外，还可以定义新的特性，以及替换类A的部分特性，那么类A与类B之间是泛化关系

• A是B和C的父类，B，C具有公共类（父类）A ， 说明A是B，C的一般化（概括，泛化）

4.2.2 代码体现

子类继承父类

4.2.3 UML绘图方式

实线空心三角箭头
箭头指向父类
一条实线+空心箭头。

4.3 实现关系 （Realization）

4.3.1 说明【接口和类之间的关系】

• 和泛化关系相似
• 接口和类之间的关系
• 逻辑上也是用"is a"表示。
• 将一个模型关系，与另一种模型关系连接起来，从而说明和其实现之间的关系
• 将一个类或多个类实现一个接口

区别：

实现关系	继承一个抽象类（abstract、interface）
泛化关系	继承一个具体类

4.3.2 代码体现

实现接口或继承某个抽象类

4.3.3 UML绘图方式

封闭空箭头虚线
箭头指向接口
一条虚线+空心箭头

4.4 关联关系（Association）

关联关系 分为两种特例 ： 聚合关系Aggregation 和 组合关系Composition

4.4.1 说明【整体与部分关系】

• 逻辑上能用"has a"表示。
• 描述了类的结构之间的关系
• 描述一组链，链是对象之间的连接
• 表示的是一个事物的对象，与另一个事物的对象之间的语义上连接
• 两个类或类与接口之间的强依赖关系
• 在用例图中，执行者和用例之间进行交互
• 相关之间的关系用一根直线来表示（关联关系）

4.4.2 代码体现

成员变量

4.4.3 UML绘图方式

实线无箭头

4.5 关联关系 - 聚合关系（Aggregation）

属于关联关系中的一种特例情况

4.5.1 说明 【整体与部分各自独立，可分离】

• 逻辑上能用"has a"表示
• 整体与部分的关系，拥有关系
• 整体与部分生命周期不同，各自独立，可分离
• 部分能脱离整体而独立存在
• 一个较大的整体类，包含一个或多个部分类
• 通常在定义一个整体类后， 再去分析这个整体类的组成结构，从而找出一些成员类，该整体与成员类之间就是聚合关系

4.5.2 代码体现

成员变量

4.5.3 UML绘图方式

实线菱形空心箭头
一条实线+空心菱形

4.5.4 举例

（轮子和车）
（计算机与CPU）
（公司与员工的关系）

4.6 关联关系 - 组合关系（Composition）

属于关联关系中的一种特例情况
（没有组合关系的时候，选择聚合关系）

4.6.1 说明 【部分不能脱离整体而独立存在】

• 逻辑上能用"has a"表示。
• 整体与部分生命周期相同
• 语义更强的聚合
• 是整体与部分的关系
• 部分不能脱离整体而独立存在

4.6.2 代码体现

成员变量

4.6.3 UML绘图方式

实线菱形实心箭头
一条实线+实心菱形

4.6.4 举例

（公司与部门）

其他关联关系：

五、架构师与UML

在实际项目中，对于核心业务，一定要设计好业务流程，在分析业务的过程中，除了业务流程图，还可能用到活动图，序列图，用例图等。

通过视图可以帮你理解业务，建模业务，也便于同事之间的沟通与交流，方便工作交接。一定要注意业务，重视建模

UML入门：活动图+用例图+序列图。UML已经成为架构师的必备技能了