APE
文章标签归档关于

© 2026 APE.PUB

2026-07-05· 8 分钟

UML类图

umloop

UML 类图常见关系示例

本文整理了 UML 类图中几种最常见的关系表示方式，包括：

  • 关联（Association）
  • 聚合（Aggregation）
  • 组合（Composition）
  • 继承（Generalization）
  • 实现（Realization）
  • 依赖（Dependency）

并结合示例说明它们的含义和区别。

1. 普通关联（Association）

场景

老师教学生。

这里表示的是“有联系”，但不是整体—部分关系。

Teacher ───── Student

理解

  • Teacher 和 Student 是两个独立对象
  • 只是存在业务关系
  • 谁都不是谁的组成部分

适用场景

  • 用户使用系统
  • 医生治疗病人
  • 老师教学生

2. 聚合（Aggregation）

场景

部门包含员工。

Department ◇──── Employee

理解

  • Department 是整体
  • Employee 是部分
  • 员工离开部门后仍然存在
  • 员工还可以加入别的部门

特点

  • 是“整体—部分”关系
  • 部分对象可以独立存在
  • 生命周期不依赖整体

3. 组合（Composition）

场景

房子包含房间。

House ◆──── Room

理解

  • House 是整体
  • Room 是部分
  • Room 依赖 House 才有意义
  • House 不存在了，Room 通常也不存在

特点

  • 是更强的“整体—部分”关系
  • 部分不能脱离整体独立存在
  • 生命周期强绑定

4. 继承（Generalization）

场景

猫和狗继承动物。

Cat ─────|> Animal
Dog ─────|> Animal

理解

  • Cat 是 Animal
  • Dog 也是 Animal
  • 这是 is-a 关系，不是 has-a 关系

5. 实现（Realization）

场景

支付宝支付、微信支付都实现支付接口。

AlipayPayment - - -|> Payment
WechatPayment - - -|> Payment

理解

  • Payment 是接口
  • AlipayPayment、WechatPayment 是实现类
  • 使用虚线 + 空心三角箭头表示

6. 依赖（Dependency）

场景

订单服务调用支付服务。

OrderService - - - -> PaymentService

理解

  • OrderService 临时使用 PaymentService
  • 不是长期拥有关系
  • 表示“用到”而不是“组成”

7. 带属性和方法的类图示例

场景

部门和员工。

+---------------------+
|     Department      |
+---------------------+
| -name: String       |
+---------------------+
| +addEmployee():void |
+---------------------+
          ◇
          |
          |
+---------------------+
|      Employee       |
+---------------------+
| -name: String       |
| -age: int           |
+---------------------+
| +work(): void       |
+---------------------+

理解

  • 上面是 Department
  • 下面是 Employee
  • 空心菱形在 Department 一端，说明它是整体
  • Employee 是部分，但可以独立存在

8. 组合的完整类图示例

场景

订单和订单项。

+----------------------+
|       Order          |
+----------------------+
| -orderNo: String     |
+----------------------+
| +create(): void      |
+----------------------+
           ◆
           |
           |
+----------------------+
|      OrderItem       |
+----------------------+
| -count: int          |
| -price: double       |
+----------------------+
| +calc(): double      |
+----------------------+

理解

  • Order 是整体
  • OrderItem 是部分
  • 没有订单，订单项通常没有独立意义
  • 所以这是组合关系

9. 多重性（Multiplicity）

示例 1：一个部门有多个员工

Department 1 ◇──── 0..* Employee

表示：

  • 一个 Department 对应多个 Employee
  • 0..* 表示零到多个

示例 2：一个订单有多个订单项

Order 1 ◆──── 1..* OrderItem

表示：

  • 一个订单至少有一个订单项
  • 订单项依附于订单存在

常见多重性写法

  • 1：一个
  • 0..1：零或一个
  • *：多个
  • 0..*：零到多个
  • 1..*：一个或多个

10. 综合小案例

学校系统

School ◇──── Class
Class ◇──── Student
Teacher ───── Class
Student ───── Course
GraduateStudent ─────|> Student

理解

  • School 聚合 Class
  • Class 聚合 Student
  • Teacher 和 Class 是普通关联
  • Student 和 Course 是普通关联
  • GraduateStudent 继承 Student

11. 一眼区分 UML 关系符号

普通关联

A ───── B

聚合

A ◇──── B

组合

A ◆──── B

继承

A ─────|> B

实现

A - - -|> B

依赖

A - - - -> B

12. 看图时的判断顺序

看到一条线，可以按下面顺序判断：

第一步：看是不是虚线

  • 是虚线：多半是 依赖 或 实现
  • 是实线：继续看

第二步：看有没有空心三角箭头

  • 有：可能是 继承 或 实现
  • 没有：继续看

第三步：看有没有菱形

  • 空心菱形：聚合
  • 实心菱形：组合
  • 都没有：通常是 关联

13. 最实用记忆法

has-a

  • 普通拥有关系：关联
  • 松散整体—部分：聚合
  • 强整体—部分：组合

is-a

  • 继承

use-a

  • 依赖

14. 总结

UML 类图中最常见的几种关系可以这样理解：

  • 关联：有关系
  • 聚合：整体和部分，但部分能单独存在
  • 组合：整体和部分，而且部分离不开整体
  • 继承：是一个（is-a）
  • 实现：实现接口
  • 依赖：临时使用

在实际建模时：

  • 如果只是一般联系，用关联
  • 如果是松散整体—部分，用聚合
  • 如果是强绑定整体—部分，用组合
  • 如果是父类子类关系，用继承
  • 如果是类实现接口，用实现
  • 如果只是调用或临时使用，用依赖
← 返回首页