题目如下。

采用 UML 进行软件设计时，可用（16）关系表示两类事物之间存在的特殊 / 一般关系，用（17）关系表示事物之间存在的整体 / 部分关系。

（16）A.依赖　B.聚集　C.泛化　D.实现

（17）A.依赖　B.聚集　C.泛化　D.实现

正确答案很明确。

（16）选择 C，泛化。

（17）选择 B，聚集。

也就是

$$
\boxed{16=C,\qquad 17=B}
$$

如果只为了考试记忆，可以压缩成一句非常实用的话。

特殊与一般，看泛化。整体与部分，看聚集。

不过，要真正理解为什么如此，还需要把 UML 里的几个关系放回面向对象设计语境中来看。因为「依赖」「泛化」「实现」「聚集」虽然都表示两个建模元素之间存在某种联系，但它们描述的完全不是同一维度的问题。

UML，也就是 Unified Modeling Language，中文通常称为统一建模语言，它不是某一种具体编程语言，而是一套描述软件系统结构和行为的建模语言。我们在做面向对象分析和设计时，经常要回答一些很基础的问题。

某个类是不是另一个类的一种特殊形式。

某个对象是不是另一个对象的一部分。

某个类是不是遵守某种接口规定。

某个类是否只是临时使用另一个类提供的能力。

这几种问题对应的 UML 关系恰好不同。

题目中的「特殊 / 一般关系」，对应的是 Generalization，也就是泛化关系。

所谓一般事物，可以理解为抽象程度更高、覆盖范围更广的概念。特殊事物则是在一般概念基础上增加限制、增加特征或者增加行为以后形成的更具体概念。

拿软件开发里最典型的对象模型来看。

我们有一个类叫 `Vehicle`，表示交通工具。

又有 `Car`、`Truck`、`Motorcycle` 三个类。

`Car` 是一种 `Vehicle`。

`Truck` 是一种 `Vehicle`。

`Motorcycle` 也是一种 `Vehicle`。

这里存在的关系并不是 `Vehicle` 包含一个 `Car`，也不是 `Car` 临时调用 `Vehicle`，而是 `Car` 属于 `Vehicle` 这一更一般类别中的一个特殊类别。

可以抽象成

$$
Car \subset Vehicle
$$

这里的集合符号只是帮助理解，并不是 UML 的正式语法。它表达的是，所有满足 `Car` 类型定义的对象，在类型语义上同时属于 `Vehicle` 这一更一般的概念。

因此可以说

`Vehicle` 是一般类。

`Car` 是特殊类。

从特殊类向一般类建立的这种关系，在 UML 中叫作泛化关系。

在面向对象程序设计语言中，它经常对应继承。

例如 Java 代码中可能写成

```java
class Vehicle {
}

class Car extends Vehicle {
}
```

这里的 `extends` 就体现了一个典型的泛化关系。

如果用自然语言判断，可以采用一个非常稳定的方法，尝试在两个概念中间加入 `is-a`。

`Car is-a Vehicle`

语义成立。

汽车是一种交通工具。

因此很适合建立泛化关系。

类似的关系还有很多。

`Dog is-a Animal`

狗是一种动物。

`Manager is-a Employee`

经理是一种员工。

`SavingsAccount is-a BankAccount`

储蓄账户是一种银行账户。

`Circle is-a Shape`

圆形是一种图形。

这里共同存在一个特征，前面的概念比后面的概念更加具体，而后面的概念更加一般。

所以 UML 中所谓特殊 / 一般关系，实际讨论的是类型分类层次。

这也是为什么第 16 题必须选择 C，泛化。

如果从编程语言角度进一步理解，泛化关系通常带来属性和行为继承。

假设存在一个 `Employee` 类。

```java
class Employee {
    String name;

    void work() {
    }
}
```

又定义

```java
class Developer extends Employee {
    void writeCode() {
    }
}
```

`Developer` 是 `Employee` 的一个特殊类型。

所有开发人员都可以拥有员工的一般属性，比如姓名、员工编号、部门，也可以拥有员工的一般行为，比如工作、申请休假、参加培训。

但开发人员又可以加入自己的特殊行为，比如编写程序、代码审查、调试程序。

这正是「一般」和「特殊」的区别。

一般类负责表达公共特征。

特殊类保留公共特征，同时加入自己的特殊特征。

在 UML 类图中，泛化关系通常使用实线加空心三角箭头表示，三角箭头指向一般分类器，也就是更一般的一端。

可以想象这样一个结构。

```text
        Vehicle
           △
           │
     ┌─────┼─────┐
     │     │     │
    Car  Truck Motorcycle
```

箭头最终指向 `Vehicle`，因为 `Vehicle` 是更一般的概念。

考试中经常有人看到继承关系后，把它误认为实现关系。这两个概念确实容易混淆，因为在一些编程语言里，两者的语法和使用位置非常接近。

泛化主要回答的是

某个类型是不是另外一个更一般类型的特殊形式。

实现关系则主要回答

某个分类器是否按照某项规格、契约或者接口提供具体实现。

例如 Java 中有一个接口

```java
interface PaymentService {
    void pay();
}
```

再定义

```java
class AlipayPaymentService implements PaymentService {
    public void pay() {
    }
}
```

`PaymentService` 更接近一份能力契约，它规定某个实现者必须提供 `pay` 操作。

`AlipayPaymentService` 提供了这一契约的具体实现。

这里体现的是 Realization，也就是实现关系。

在 UML 中，实现关系经常用虚线加空心三角箭头表示。

外形上它和泛化很像。

泛化通常是

实线加空心三角形。

实现通常是

虚线加空心三角形。

两者非常容易在选择题里一起出现。

但如果只从图形记忆，考试时很容易混乱。更稳妥的方法还是看语义。

特殊 / 一般，关注分类层次，倾向于泛化。

规格 / 实现，关注契约落实，倾向于实现。

这也解释了第 16 题为什么不是 D。

再回到第 17 题。

题目问的是整体 / 部分关系。

这已经不再讨论「谁是谁的一种」，而是在讨论「谁是谁的一部分」。

这类关系与 Aggregation 对应，中文通常译为聚集或者聚合。

以汽车为例。

汽车不是发动机的一种。

发动机也不是汽车的一种。

所以

`Engine is-a Car`

显然不成立。

但可以说

发动机是汽车的组成部分。

或者说

汽车由发动机、车轮、车身、座椅等部分组成。

此时更自然的关系是整体和部分。

可以写成

$$
Car = Engine + Wheel + Body + Seat + \cdots
$$

这个式子同样只是语义示意，不代表真正的软件实现。

在 UML 中，用来表达这种整体 / 部分结构的核心概念就是聚集。

因此第 17 题选择 B。

这里有一个非常有价值的判断技巧。

泛化可以用 `is-a` 检查。

聚集可以用 `has-a` 检查。

例如

`Car is-a Vehicle`

成立。

因此 `Car` 与 `Vehicle` 适合泛化。

再看

`Car has-an Engine`

成立。

汽车拥有发动机。

因此 `Car` 与 `Engine` 更接近整体 / 部分关系。

两个短语非常适合放在一起记。

$$
is\text{-}a \Rightarrow Generalization
$$

$$
has\text{-}a \Rightarrow Aggregation
$$

当考试题把多个 UML 关系混合在一起时，这种语义判断通常比死记图形可靠得多。

聚集关系内部还需要继续区分普通聚集和组合。

这也是 UML 考试里非常喜欢向下延伸的一组知识。

普通聚集通常使用空心菱形表示。

组合通常使用实心菱形表示。

两者都属于整体 / 部分语义，但生命周期约束并不相同。

例如某个 `Department` 部门与 `Employee` 员工之间，可以建立一种相对松散的整体 / 部分联系。

员工属于某个部门。

但部门被撤销，并不代表员工这个对象必须在现实业务世界里彻底消失。

员工可能被调整到另外一个部门。

也就是说，部分对象能够脱离当前整体继续存在。

这种关系更接近普通聚集。

可以写成

```text
Department ◇──── Employee
```

空心菱形放在整体一侧。

而 `House` 与 `Room` 的关系经常被拿来说明更强的组合语义。

房间通常作为某套房屋结构的一部分存在，它在该模型中的生命周期对整体具有更强依附性。

可以写成

```text
House ◆──── Room
```

这里使用实心菱形。

再拿软件系统里更加贴近开发实践的场景来看。

一个订单 `Order` 下面包含多个订单行 `OrderItem`。

订单行记录商品、数量、单价、小计等内容。

如果订单被彻底删除，对应的订单行通常也没有继续单独存在的业务意义。

这种模型就很适合用组合表达。

```text
Order ◆──── OrderItem
```

如果我们正在设计电商订单领域模型，这样的关系比简单继承更加准确。

`OrderItem` 并不是一种 `Order`。

所以泛化不成立。

`Order` 也并非只是短暂调用 `OrderItem`。

订单对象在结构上拥有订单行。

因此整体 / 部分关系才是这里的核心。

OMG 发布的 UML 2.5.1 规范也明确区分了不同的聚集语义，其中 `shared` 表示共享聚集语义，而 `composite` 表示组合聚集。组合是更强的整体 / 部分约束，部分实例在同一时刻至多属于一个组合整体，并且组合整体与组成部分之间存在更强的生命周期联系。:chatgpt-content-reference{index="0"}

看到这里，可以顺便解决一个考试中很容易出现的疑惑。

为什么题目写的是「聚集」，而不是「组合」。

原因在于题干只说整体 / 部分，没有附加更强的生命周期条件。

整体 / 部分是聚集这一类语义的核心描述。

组合则可以理解为聚集的一种更强形式。

因此在这组选项里，B 最准确。

剩下的依赖关系也需要弄清楚，否则下一道 UML 题很可能继续遇到。

Dependency，也就是依赖，描述的是一个模型元素的变化可能影响另一个模型元素的关系。

它常见于一个类临时使用另外一个类。

例如

```java
class ReportService {

    void export(PdfWriter writer) {
        writer.write();
    }
}
```

`ReportService` 的 `export` 方法接收 `PdfWriter` 参数，并在方法内部调用它。

这里 `ReportService` 使用了 `PdfWriter`。

这种使用可能仅仅发生在某个方法执行期间，并不代表 `PdfWriter` 是 `ReportService` 的组成部分。

所以不能简单地看到「A 使用 B」就判断为聚集。

依赖关系强调使用。

聚集关系强调拥有。

泛化关系强调类型层次。

实现关系强调契约落实。

把这四个关键词放在一起，整道题就非常清晰。

依赖对应 Use。

聚集对应 Whole / Part。

泛化对应 General / Special。

实现对应 Specification / Implementation。

这四种关系看起来都是两个类之间画一条线，但语义方向完全不同。

假设我们正在设计一个真实的电商支付系统，可以把四种关系同时放进去理解。

系统中存在一个抽象的 `Payment` 支付类型。

`CreditCardPayment` 信用卡支付继承 `Payment`。

这属于泛化。

因为

`CreditCardPayment is-a Payment`

成立。

系统又定义一个 `PaymentGateway` 接口。

`StripeGateway` 按照这个接口完成支付网关功能。

这里属于实现。

因为重点不是 Stripe 网关是不是一种抽象父类，而是它实现了接口规定的契约。

一个 `Order` 内包含多个 `OrderItem`。

这里属于整体 / 部分关系，因此可以采用聚集或者更强的组合建模。

一个 `OrderService` 在生成订单完成通知时调用 `EmailService`。

如果 `EmailService` 只是方法调用过程中被使用，这里就可能体现依赖关系。

同一个业务系统中，四种关系可以同时出现。

```text
CreditCardPayment → Payment
泛化

StripeGateway → PaymentGateway
实现

Order → OrderItem
整体 / 部分

OrderService → EmailService
使用依赖
```

这比孤立背四个术语要牢固很多。

再回到「特殊 / 一般」这个词。

国内不少软件工程、系统架构设计、软件设计师考试教材会使用这个表述。第一次看到时容易觉得很抽象，其实它就是继承层次里的父类和子类关系。

例如

动物是一般概念。

鸟是更特殊的动物。

麻雀又是更特殊的鸟。

可以形成

```text
Animal
  △
  │
 Bird
  △
  │
Sparrow
```

这里越往上，概念覆盖范围越大，抽象程度越高。

越往下，概念范围越窄，特征越具体。

因此叫作泛化和特殊化。

从 `Sparrow` 向 `Bird`、`Animal` 看，是从特殊概念向一般概念上升，可以称为泛化。

从 `Animal` 向 `Bird`、`Sparrow` 看，则是不断增加限制并变得具体，可以理解为特殊化。

同一套类型层次可以从两个方向观察。

数学上甚至可以把它理解成集合包含关系。

假设

$$
A = \{所有动物\}
$$

$$
B = \{所有鸟类\}
$$

$$
C = \{所有麻雀\}
$$

那么

$$
C \subseteq B \subseteq A
$$

某个麻雀对象既属于麻雀集合，也属于鸟类集合，同时属于动物集合。

这与面向对象中的多态思想能够很好地对应起来。

例如一个函数要求接收 `Animal`。

```java
void feed(Animal animal) {
}
```

那么 `Bird` 或 `Sparrow` 对象在满足类型规则的情况下也可以作为 `Animal` 使用。

因为特殊类型继承了一般类型所表达的类型身份。

这也是泛化关系远比画一根箭头更加重要的原因。

它会影响类型系统、继承、多态、方法覆盖以及架构设计。

整体 / 部分关系则完全是另一条思维路线。

考虑一台计算机。

计算机包含 CPU、内存、主板、硬盘。

CPU 不是一种计算机。

内存也不是一种计算机。

所以不能建立类似

`CPU is-a Computer`

这样的模型。

合理表达是

`Computer has-a CPU`

`Computer has Memory`

这里描述的是对象结构，而不是类型层次。

同样地，一个学校拥有多个学院，一个学院拥有多个专业，一个专业包含多个班级。

这种结构关注对象怎样组合成更大对象或者业务实体。

所以它进入了聚集和组合的范畴。

有一个很容易犯的错误，就是看到「包含」两个字便机械选择聚集。

实际软件模型里还需要结合生命周期、所有权以及业务语义。

例如一个 `Team` 团队与 `Developer` 开发人员之间，虽然可以说团队包含开发人员，但一个开发人员离开原团队以后仍然存在，也可能加入另一个团队。

因此这里更偏向普通聚集或者普通关联。

而订单 `Order` 与订单项目 `OrderItem` 往往具有更紧密的生命周期关系。

订单项目脱离所属订单后通常没有独立业务意义。

这类情况更适合组合。

OMG 的 UML 规范对于组合聚集的定义也强调了这种更强的所属关系。组合中的部分对象在同一时刻至多属于一个组合对象，当组合对象被删除时，其组成部分通常会随之删除。:chatgpt-content-reference{index="1"}

这道考试题没有要求进一步区分普通聚集与组合，因此不需要把问题复杂化。

看到整体 / 部分，选择聚集即可。

再看几个容易制造干扰的表述，会发现题目其实有固定语言模式。

如果题干出现「一种」「属于某种类型」「一般和特殊」「父类和子类」「继承」，通常应该想到泛化。

如果题干出现「整体和部分」「由若干部件组成」「拥有」「包含」，通常应该想到聚集或组合。

如果题干出现「使用」「调用」「参数」「局部变量」「一个元素变化可能影响另一个元素」，通常应该想到依赖。

如果题干出现「接口与实现类」「规格与实现」「契约与实现者」，通常应该想到实现关系。

可以把四者浓缩成四个英文语义模型。

```text
Generalization
is-a

Aggregation
has-a

Dependency
uses-a

Realization
implements
```

这四组对应关系很适合长期记忆。

拿题目两个空重新代入。

第 16 空写的是特殊 / 一般。

我们测试

特殊类型 `is-a` 一般类型。

成立。

所以选择 Generalization，泛化。

答案 C。

第 17 空写的是整体 / 部分。

我们测试

整体 `has-a` 部分。

成立。

所以选择 Aggregation，聚集。

答案 B。

因此最终答案为

$$
\boxed{C,\ B}
$$

也就是

（16）C，泛化。

（17）B，聚集。

如果考试现场只剩十几秒，可以直接抓住两个词。

「特殊 / 一般」是在回答「是什么」，所以属于泛化。

「整体 / 部分」是在回答「有什么」，所以属于聚集。

`Car` 是一种 `Vehicle`，这是泛化。

`Car` 有一个 `Engine`，这是聚集。

一旦把 `is-a` 和 `has-a` 这两个模型真正建立起来，这道题就不再需要背答案。更重要的是，后续遇到继承、接口、组合、关联、依赖等 UML 题，也可以沿着同一套语义判断，而不是靠记忆箭头和菱形碰运气。

UML 类图真正希望表达的不是线条长什么样，而是软件元素之间到底存在什么关系。

父类和子类讨论的是类型分类，所以用泛化。

整体和零件讨论的是结构组成，所以用聚集。

接口和实现类讨论的是契约落地，所以用实现。

某个类暂时调用另一个类讨论的是使用关系，所以用依赖。

把这四句话放进脑中，题目的两个答案自然就是 C 和 B。

考试时最终可以记成一个极短的判断式。

$$
特殊/一般 \Rightarrow 泛化 \Rightarrow C
$$

$$
整体/部分 \Rightarrow 聚集 \Rightarrow B
$$

因此本题答案确定为

$$
\boxed{16=C,\qquad17=B}
$$

参考资料

OMG，Unified Modeling Language 2.5.1 规范。[OMG UML 2.5.1 官方规范](https://www.omg.org/spec/UML/2.5.1/PDF?utm_source=chatgpt.com)

OMG，Unified Modeling Language 2.5.1 规范主页。[OMG UML 2.5.1 规范信息](https://www.omg.org/spec/UML/2.5.1/?utm_source=chatgpt.com)

采用 UML 进行软件设计时，可用（16）关系表示两类事物之间存在的特殊  一般关系，用（17）关系表示事物之间存在的整体  部分关系。

从特殊与一般到整体与部分，彻底读懂 UML 中的泛化、聚集、依赖与实现关系

紫薇堂堂主

编程语言

开发工具

架构设计

UML关系辨析题：特殊/一般关系对应泛化（16选C），整体/部分关系对应聚集（17选B）。记忆口诀：is-a用泛化，has-a用聚集。

软件工程

软件开发

软件设计

代码解释

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从特殊与一般到整体与部分，彻底读懂 UML 中的泛化、聚集、依赖与实现关系-腾讯云开发者社区-腾讯云

从特殊与一般到整体与部分，彻底读懂 UML 中的泛化、聚集、依赖与实现关系

从特殊与一般到整体与部分，彻底读懂 UML 中的泛化、聚集、依赖与实现关系

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐