UML

概述

UML是Unified Modeling Language的缩写，译为统一建模语言。

UML是软件行业的建模规范，可以对软件项目建立需求模型、设计模型、实现模型、测试模型。

一种建模语言，UML的定义包括UML语义和UML表示法两个部分。

UML语义：描述基于UML的精确元模型定义。
UML表示法：定义UML符号的表示法，为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型，在语义上它是UML元模型的实例。

UML2.0包含的14种图

模式六种关系

强弱关系

依赖＜关联＜聚合＜组合＜实现＜继承(泛化)

依赖关系

依赖dependency： ---> 用虚线加箭头表示

类A中使用了类B，B作为方法参数、局部变量等调用，就存在依赖关系。

关联关系

关联association：——> 用实现箭头表示

对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。关联关系分为单向关联和双向关联。在java中，单向关联表现为：类A当中使用了类B，其中类B是作为类A的成员变量。双向关联表现为：类A当中使用了类B作为成员变量；同时类B中也使用了类A作为成员变量。

聚合关系

聚合aggregation: ◇——> 用空心菱形和实线箭头表示

聚合关系是关联关系的一种，耦合度强于关联，聚合关系的对象之间是“整体-个体”的相互关系，类似于雁群和单个大雁，没了雁群，大雁也单独存在。

组合关系

组合composition: ◆——>用实心菱形和实线箭头表示

组合关系是关联关系的一种，组合关系的类表示“整体-部分”的关联关系，“整体”负责“部分”的生命周期，他们之间是共生共死的；并且“部分”单独存在时没有任何意义，类似于大雁和它的翅膀。

实现关系

实现implements: ---▷ 用虚线加三角形箭头表示类implements接口的关系。

继承关系

继承extends: ——▷ 用实线加三角形箭头表示

类extends抽象类的关系。

关联、聚合、组合的关系

在 UML 和面向对象设计中，关联（Association）、聚合（Aggregation）、组合（Composition） 均属于类与类之间的 “关系”，但它们在语义强度、依赖程度和生命周期关联上存在递进关系，本质是 “整体 - 部分” 关系的细化和泛化。

具体关系可概括为：聚合和组合是关联的特殊形式，而聚合与组合是并列的 “整体 - 部分” 关系，组合比聚合的关联强度更高。

无论聚合还是组合，菱形始终指向整体，部分在菱形的另一端。

一、从泛化到特殊：三者的层级关系

关联是最宽泛的基础关系 关联表示类与类之间存在某种 “连接”（如交互、引用、依赖等），不强调 “整体 - 部分”，仅体现两个类的 “相关性”。例如：
- 学生（Student）和课程（Course）的关联（学生选课程）；
- 用户（User）和地址（Address）的关联（用户有地址）。
聚合和组合是关联的特例 聚合和组合都属于 “整体 - 部分” 关系（即关联的一种特殊场景），但比普通关联的语义更强，明确强调 “整体由部分组成”。
- 聚合（Aggregation）：整体包含部分，部分可独立于整体存在（“弱整体 - 部分”）；
- 组合（Composition）：整体包含部分，部分完全依赖整体的生命周期（“强整体 - 部分”）。

二、三者的核心区别：从 “关联强度” 和 “生命周期” 划分

关系类型	核心语义	整体与部分的生命周期	典型示例	语义强度
关联	类之间的一般连接（非整体 - 部分）	无依赖，部分可独立于整体存在	学生 - 课程、用户 - 订单	最弱
聚合	整体包含部分（部分可独立）	部分可在整体创建前存在，或在整体销毁后存活	汽车 - 轮胎（轮胎可拆下装到其他车）	中等
组合	整体由部分构成（部分不可独立）	部分与整体同生共死：整体创建时部分被创建，整体销毁时部分也被销毁	手机 - 电池（手机销毁后，电池作为手机的一部分无意义，随手机一起处理）	最强

聚合

特点：部分可独立存在，生命周期不依赖整体。

公司与员工

公司由员工组成，但员工离职后仍可加入其他公司。

class Employee { /* 员工类 */ }
class Company {
    private List<Employee> employees; // 员工集合
    public void addEmployee(Employee e) { employees.add(e); }
}

汽车与轮胎

轮胎可拆卸更换，独立于汽车存在。

class Tire { /* 轮胎类 */ }
class Car {
    private Tire tire; // 轮胎通过外部传入
    public Car(Tire tire) { this.tire = tire; }
}

组合

特点：部分不能独立存在，生命周期与整体绑定。

汽车与引擎

引擎是汽车的固有部件，汽车销毁时引擎随之销毁。

class Engine { /* 引擎类 */ }
class Car {
    private Engine engine; // 引擎随汽车创建
    public Car() { engine = new Engine(); }
}

三、总结：三者的关系图谱

包含关系：聚合和组合是关联的子集（特殊形式）；
并列关系：聚合和组合同属 “整体 - 部分” 关系，但组合的关联强度更高（部分完全依赖整体）；
递进关系：从关联（无整体 - 部分）→ 聚合（弱整体 - 部分）→ 组合（强整体 - 部分），关系的紧密程度和依赖程度逐渐增强。

判断整体与部分

在 UML 和面向对象设计中，“整体 - 部分” 关系（如聚合、组合）的核心是一个类（整体）由另一个或多个类（部分）组成，部分是整体的构成要素。识别这种关系需要结合语义、功能和生命周期等维度，以下是具体的识别方法和判断依据：

一、核心判断标准：语义上的 “组成性”

整体 - 部分关系的本质是 “部分是整体的物理或逻辑构成要素”，可以通过以下语义特征识别：

能用 “整体由部分组成” 或 “整体包含部分” 描述，且语句逻辑通顺。
部分的 “身份” 依赖于整体的存在（即使部分可独立存在，其核心意义之一也是作为整体的构成要素）。

二、具体识别方法

1. 语义验证法：用 “组成” 语句测试

操作：尝试将两个类 A（候选整体）和 B（候选部分）代入以下句式，若成立则可能是整体 - 部分关系：

“A 由 B 组成”（如 “汽车由发动机组成”）；
“B 是 A 的一部分”（如 “发动机是汽车的一部分”）；
“A 包含 B”（且此处 “包含” 是 “构成包含”，而非 “持有” 或 “管理”，如 “书架包含书籍” 是持有，而非整体 - 部分；“书架包含隔板” 是整体 - 部分）。

反例：

“用户由订单组成” 不成立（订单是用户创建的，不是用户的构成部分）；
“学校包含学生” 中 “包含” 是 “管理”，而非构成，因此不是整体 - 部分（学生是学校的成员，而非组成部分）。

2. 功能依赖法：部分的功能服务于整体

核心逻辑：部分的主要功能是支撑整体完成其核心职责，离开整体后，部分的功能价值会显著降低或失去核心意义。

示例：

手机（整体）与电池（部分）：电池的核心功能是为手机供电，若离开手机，电池的主要价值（作为供电组件）就无法充分体现；
电脑（整体）与 CPU（部分）：CPU 的功能是处理数据，但其核心意义是作为电脑的计算核心，离开电脑后，CPU 无法单独完成 “计算” 的完整场景（如运行操作系统）。

反例：

电脑与 U 盘：U 盘的核心功能是存储和传输数据，可独立于电脑使用（如在电视、相机上使用），因此不是电脑的 “部分”，而是关联关系。

3. 存在意义法：部分的 “核心身份” 与整体绑定

判断依据：部分的存在意义（或主要身份）是否依赖于整体的定义。若部分的名称或定义中隐含 “属于某个整体”，则更可能是整体 - 部分关系。

示例：

“书页”（部分）的名称隐含 “属于书（整体）”，离开书后，“书页” 的身份会弱化（更可能被称为 “纸张”）；
“车轮”（部分）的名称隐含 “属于车（整体）”，离开车后，其身份更偏向 “圆形部件”，核心意义下降。

反例：

“用户” 与 “地址”：地址的定义不依赖用户（可属于公司、学校等），因此不是用户的部分，而是关联关系。

4. 层次分解法：整体可分解为部分的 “层级结构”

判断逻辑：若整体可以按 “层级” 分解为更小的构成单元，且分解后的单元（部分）仍服务于整体的核心目标，则构成整体 - 部分关系。

示例：

软件系统（整体）→ 模块（部分）→ 类（更小的部分）：系统按功能层级分解为模块，模块再分解为类，每个层级的 “部分” 都是上一层 “整体” 的构成要素；
汽车（整体）→ 底盘、车身、动力系统（部分）→ 发动机、变速箱（动力系统的部分）：按物理结构层级分解，每一层都是整体 - 部分关系。

三、典型误区与排除标准

有些关系看似 “包含”，但并非整体 - 部分，需注意排除：

“持有 / 管理” 而非 “组成”：如 “图书馆（整体）持有书籍（部分）”—— 书籍是图书馆管理的对象，而非图书馆的物理 / 逻辑组成部分（图书馆的组成部分是书架、阅览室等）；
“成员关系”：如 “团队（整体）有成员（部分）”—— 成员是团队的参与者，而非组成部分（团队的组成部分可能是分工角色、任务模块等）；
“依赖传递”：如 “订单依赖商品，商品依赖库存”—— 这是依赖链，而非订单包含商品（订单与商品是关联关系，商品与库存是关联关系）。

14种图

1. 类图（class diagram）

类图描述一组类、接口、协作和它们之间的关系。在OO（面向对象）系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。

类图中常见关系：

2. 对象图（object diagram）

对象图描述对象在某个时刻的状态和关系。

对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。

对象图中一般包括“对象”和“链”两类基本的模型元素。

类的具体表示称为对象，对象是类的实例。
链（link）是两个或多个对象之间的独立连接，是关联的实例。

3. 组件图（component diagram）

组件图描述一个封装的类和它的接口、端口，以及由内嵌的组件和连接件构成的内部结构。组件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，组件图是最重要的。组件图是类图的变体。

4. 组合结构图（composite structure diagram）

组合结构图描述结构化类（例如：构件或类）的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容。

5. 用例图（use case diagram）

用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的。

元素

参与者（actor）：可以是操作员、外部系统、外部设备、时间。
用例（use case）：参与者和系统交互的场景描述。

关系

角色之间：泛化关系（generalization）。
用例之间：包含（include）、扩展（extend）、泛化（generalization）。

用途

通过用户使用系统的场景描述功能需求。

角色与用例之间的实线称为“关联”，用来表示角色和用例之间的交互和通信途径。关联有时候也用带箭头的实线来表示。

用例图的组成还有系统边界

用例之间的泛化关系

参与者泛化关系

6. 时序图（sequence diagram，序列图、顺序图）

时序图是一种交互图，交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。时序图是强调消息的时间次序的交互图。（描述对象按照时间顺序的消息流来建模用例）

时序图（即顺序图）侧重对象消息传递的时间顺序，垂直方向展示时间流；定时图（timing）则重在展示对象状态变化与时间关系，时间轴通常是水平的。

顺序图是强调消息时间顺序的交互图，而通信图则是强调接收和发送消息的对象间关系的交互图。

顺序图主要包括的元素

时序图（Sequence Diagram）是 UML（统一建模语言）中用于描述对象之间交互行为的动态建模图，主要包含以下核心建模元素：

对象（Object）
- 表示参与交互的实体，以 “对象名：类名” 的形式表示（如user:User），若对象名省略则为匿名对象（如:OrderService）。
- 在图中以矩形框表示，位于时序图顶部，沿水平方向排列。
生命线（Lifeline）
- 从对象底部向下延伸的垂直虚线，表示对象在交互过程中的存在时间。
- 若对象在交互中被销毁，生命线末端会以 “X” 标记。
消息（Message）
- 表示对象之间的交互行为，用带箭头的水平线连接两个对象的生命线。
- 类型包括：
  - 同步消息（Synchronous Message）：实心箭头，发送方需等待接收方处理完成（如方法调用）。
  - 异步消息（Asynchronous Message）：空心箭头，发送方无需等待接收方响应（如事件通知）。
  - 返回消息（Return Message）：带箭头的虚线，表示方法调用的返回结果（可省略）。
激活期（Activation）
- 又称 “控制焦点”，是生命线上的矩形区域，表示对象正在执行操作（如处理消息）的时间段。
- 激活期可嵌套（如对象 A 调用对象 B 的方法时，A 和 B 的激活期同时存在）。
组合片段（Combined Fragment）
- 用于表示复杂的交互逻辑（如条件、循环、并行等），以带标签的矩形框包裹相关消息。
- 常见类型：
  - alt：分支选择（类似if-else），包含多个备选交互路径。
  - loop：循环执行（类似for或while）。
  - par：并行执行（多个交互路径同时进行）。
  - opt：可选执行（条件满足时才执行）。
分支与合并（Branch and Merge）
- 用于表示交互中的条件分支（如alt片段内的分支）和分支合并，通过菱形节点标记。
对象创建与销毁（Creation and Destruction）
- 创建消息：以 “创建” 关键字或带 <<create>> 构造型的消息表示，用于创建新对象（新对象的生命线从此时开始）。
- 销毁消息：以带 <<destroy>> 构造型的消息表示，或直接在对象生命线末端标记 “X”，表示对象被销毁

7. 通信图（communication diagram）

通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。

通信图有五个概念

类角色。
关联角色：两个类角色之间的关联。
对象。
通信链接。
消息。

8. 定时图（timing diagram）

定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。

9. 状态图（state diagram）

状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤其重要，而且它强调事件导致的行为，这非常有助于反应式系统建模。（描述了一个对象在其生命周期中可能得状态组合）

简单来理解状态图（也称为状态机图）：描述了一个对象所处的状态，以及用什么操作可促成状态的转变。

状态图有五种表达方式

状态（写法：主语+状态）。
转移：表示每种状态的转移顺序。线上标记触发转移的操作和条件。
开始：标记流程的起点，不代表任何状态，开始只有一个。
结束：标记流程的终点，不代表任何状态，结束可以没有，也可以有一个或多个。
内部转移：是一个回环，表示在一个活动后，当前状态并没有改变。

流程图中的活动要写在圆角矩形里，状态图中的活动要写在带箭头的直线上。

10. 活动图（activity diagram）

活动图是UML用于对系统的动态行为建模的另一种常用工具。活动图本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。

活动图和流程图区别

流程图着重描述处理过程，活动图着重表现的是系统的行为。
活动图能够表示并发活动的情形，而流程图不能。
活动图是面向对象的，而流程图是面向过程的。

活动图的核心元素是活动，两个活动的图标之间用带箭头的直线连接

活动图的组成元素

活动状态。
动作状态。
转移。
判定。
开始和结束状态。
事件和触发器。
泳道：泳道将活动图划分为若干组，每组指定给负责这组活动的业务组长，即对象。在活动图中，泳道区分了负责活动的对象，它明确表示了哪些活动是由哪些对象进行的。
对象流。
发送信号动作。
接收事件动作。

b. 时序图和协作图是等价的

c. 两者都来自UML元模型的相同信息，因此他们的语义是等价的，他们可以从一种形式的图转换成另一种形式的图，而不丢失任何信息。

不同点

a. 协作图强调的是空间，但时间顺序必须从序列号获得。

b. 时序图强调的是时间但是没有明确的表达对象间的关系。

2. 状态图 and 活动图

相同点

都属于行为图，都是描述对象的动态行为。

不同点

a. 描述对象不同

状态图：描述对象状态及状态之间的转移，它主要表现该对象的状态。

活动图：描述从活动到活动的控制流，它主要表现的是系统的动作。

b. 使用场合不同

状态图：描述对象在其生命期中的行为状态变化。

活动图：描述过程的流程变化。

3. 对象图 and 类图

相同点

对象图是类图的实例，几乎使用与类图完全相同的标识。

不同点

对象图显示类的多个对象实例，而不是实例的类。由于对象存在生命周期，因此对象图只能在系统某一个时间段存在。

看懂UML类图和时序图

UML基础与Rose建模实用教程（第三版）

https://www.iteye.com/blog/zz563143188-1841234

https://blog.csdn.net/xiaobai51509660/article/details/27693251

https://blog.csdn.net/u011385940/article/details/131420348

https://blog.csdn.net/weixin_47872288/article/details/136094957?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-136094957-blog-131420348.235%5Ev43%5Econtrol&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1-136094957-blog-131420348.235%5Ev43%5Econtrol&utm_relevant_index=2