目录
一、引言：UML 概述与发展历史
统一建模语言（Unified Modeling Language，UML）是软件工程领域用于可视化描述、构造和文档化软件系统的一种标准化建模语言。它提供了一组图形化的表示法，帮助开发者、架构师和业务人员在统一的"语言"下沟通系统的结构与行为。在软考（系统架构设计师）中，UML 是每年必考的核心知识点，尤其在面向对象分析与设计、软件建模部分占据重要分值。
UML 是一种通用的、可视化的建模语言，用于对软件密集型系统进行规约、构造和文档化。它不是一种编程方法，也不是一种开发过程，而是一套表示法（Notation）。UML 独立于开发过程，可结合瀑布、RUP、敏捷等各类过程使用。
1.1 UML 的发展历史
UML 的诞生是面向对象方法学"三巨头"融合的结果。在 20 世纪 90 年代，面向对象分析与设计（OOAD）领域出现了多种建模方法并存的局面，其中最具影响力的三种是：
- Booch 方法（Grady Booch）：强调类与对象的逻辑设计和物理设计，在设计与构造阶段表现突出。
- OMT 方法（Object Modeling Technique，Jim Rumbaugh 等）：以对象模型、动态模型、功能模型三个视角描述系统，强于分析阶段。
- OOSE 方法（Object-Oriented Software Engineering，Ivar Jacobson）：引入用例（Use Case）驱动的设计思想，强于需求与业务建模。
方法林立导致开发者无所适从，"统一"呼声渐起。1994 年 Booch 与 Rumbaugh 相聚 Rational 公司，开始统一工作；1995 年 Jacobson 加入。三人被称为"三个朋友"（The Three Amigos）。1997 年 OMG（对象管理组织）采纳 UML 1.1 作为标准，标志着 UML 正式成为业界统一的建模语言。
1.2 UML 2.x 的图分类
UML 2.x（从 UML 2.0 到当前的 2.5.1）定义了 13 种图（部分文献计为 14 种，将"包图"独立或计入交互概览图）。所有图按语义分为两大类：结构图（Structure Diagram）描述系统的静态组成，行为图（Behavior Diagram）描述系统的动态行为。行为图中又包含一个交互图（Interaction Diagram）子集，专门刻画对象间的消息交互。
· UML 1.x 定义了 9 种图，UML 2.x 扩展为 13 种（新增对象图、包图、组件图、部署图细节、复合结构、通信、定时、交互概览等）。
· 交互图不是独立于行为图的第三类，而是行为图的子集，包含序列、通信、定时、交互概览四种。
· 软考中"UML 有多少种图"按 13 种作答。
二、UML 图分类总览
本节给出 13 种 UML 图的完整清单及其用途，帮助建立全局认知。结构图关注系统"由什么构成"，行为图关注系统"做什么、如何做"。
2.1 结构图（Structure Diagrams，7 种）
结构图描述系统的静态构成要素及其关系，包括类、对象、组件、节点、包等。它们回答"系统有哪些部分、如何组织"。
- 类图（Class Diagram）：描述类的结构、属性、操作及类间关系，是最常用、最核心的 UML 图。
- 对象图（Object Diagram）：类图的实例化快照，展示某一时刻系统中的对象及其链接。
- 组件图（Component Diagram）：描述系统组件（可替换的物理单元）及其依赖、接口。
- 部署图（Deployment Diagram）：描述软件构件到硬件节点的物理部署及通信路径。
- 包图（Package Diagram）：以包为组织单元，描述模块间的依赖关系。
- 复合结构图（Composite Structure Diagram）：描述类内部的组成结构、端口与连接器。
- 轮廓图（Profile Diagram）：UML 的扩展机制，定义特定领域的构造型（stereotype）。
2.2 行为图（Behavior Diagrams，6 种）
行为图描述系统的动态行为：功能的组织（用例）、流程的控制（活动）、状态的变化（状态机）以及对象间的交互。
- 用例图（Use Case Diagram）：从外部参与者视角描述系统功能与边界。
- 活动图（Activity Diagram）：描述业务流程或算法的控制流与数据流，类似流程图。
- 状态机图（State Machine Diagram）：描述对象在其生命周期内的状态及状态转换。
- 序列图（Sequence Diagram）：按时间顺序展示对象间消息交互。
- 通信图（Communication Diagram）：强调对象结构关系上的消息交互（序列图的另一视角）。
- 定时图（Timing Diagram）：描述对象状态随时间变化的时序关系。
此外还有交互概览图（Interaction Overview Diagram），它是活动图与交互图的混合，把交互片段作为活动节点。四种交互图（序列、通信、定时、交互概览）共同构成"交互图"这一子类。
2.3 各图用途对照表
| 图类型 | 分类 | 核心用途 | 软考出现频率 |
|---|---|---|---|
| 类图 | 结构图 | 描述类的结构及六种关系，面向对象设计核心 | ★★★★★ |
| 用例图 | 行为图 | 需求建模，描述功能与参与者 | ★★★★★ |
| 序列图 | 交互图 | 按时间顺序描述对象消息交互 | ★★★★★ |
| 活动图 | 行为图 | 描述业务流程/算法流程 | ★★★★ |
| 状态机图 | 行为图 | 描述对象生命周期状态转换 | ★★★★ |
| 组件图 | 结构图 | 描述组件及接口依赖 | ★★★ |
| 部署图 | 结构图 | 描述物理部署与节点通信 | ★★★ |
| 对象图 | 结构图 | 类图的实例快照 | ★★ |
| 包图 | 结构图 | 模块组织与依赖 | ★★ |
| 通信图 | 交互图 | 对象结构上的消息（序列图变体） | ★★ |
| 复合结构图 | 结构图 | 类内部端口与连接器 | ★ |
| 定时图 | 交互图 | 状态随时间变化 | ★ |
| 轮廓图 | 结构图 | UML 扩展机制 | ★ |
结构七：类、对、组、部、包、复、轮（类图、对象图、组件图、部署图、包图、复合结构图、轮廓图）
行为六：用、活、状、序、通、定（用例、活动、状态机、序列、通信、定时）+ 交互概览
交互四：序、通、定、概（序列、通信、定时、交互概览）
三、类图（Class Diagram）详解
类图是 UML 中使用最广泛、软考中考查最细致的图。它描述系统的静态结构：类的内部构成（属性、操作）以及类与类之间的各种关系。掌握类图，是掌握面向对象设计的基础。
3.1 类的表示法
在 UML 中，一个类用一个被分成三层的矩形表示：最上层是类名，中间层是属性，最下层是操作（方法）。每一行的可见性用符号表示。
可见性符号
| 符号 | 名称 | 含义 | Java 等价 |
|---|---|---|---|
| + | 公有（Public） | 所有类均可访问 | public |
| - | 私有（Private） | 仅本类可访问 | private |
| # | 受保护（Protected） | 本类及子类可访问 | protected |
| ~ | 包内（Package） | 同包内可访问 | default |
属性的标准格式为：可见性 名称 : 类型 [多重性] = 默认值；操作的格式为：可见性 名称(参数列表) : 返回类型。
3.2 类间的六种关系（重点）
类间关系是软考最高频的考点，必须精确掌握每种关系的箭头样式和语义。从强到弱依次为：泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖。下面逐一详解并给出 SVG 示例。
泛化（继承） ≈ 实现 > 组合（强拥有，同生共死） > 聚合（弱拥有，可分离） > 关联（平等连接） > 依赖（临时使用）
① 泛化 / 继承（Generalization）
泛化描述"是一种（is-a）"关系，子类继承父类。表示为实线 + 空心三角箭头，箭头指向父类（超类）。
② 实现（Realization）
实现描述类与接口的关系，类实现接口中定义的操作。表示为虚线 + 空心三角箭头，箭头指向接口。
③ 关联（Association）
关联表示两个类之间存在结构上的联系（如"拥有""知道"）。表示为实线，可带方向（单向关联用开箭头）、角色名和多重性。关联是平等的双向或单向引用关系。
④ 聚合（Aggregation）
聚合表示"整体与部分"的弱关系：部分可以脱离整体独立存在。表示为实线 + 空心菱形，菱形在整体一端。例如球队与球员，球队解散后球员仍存在。
⑤ 组合（Composition）
组合表示"整体与部分"的强关系：部分不能脱离整体存在，整体消亡则部分同时消亡。表示为实线 + 实心菱形，菱形在整体一端。例如鸟与翅膀、订单与订单明细。
⑥ 依赖（Dependency）
依赖表示一个类的变化会影响另一个类（如作为方法参数、局部变量使用）。表示为虚线 + 开箭头，箭头指向被依赖的类。依赖是最弱的关系，是"使用"而非"拥有"。
3.3 六种关系对比表
| 关系 | 语义 | 线型 | 箭头/端点 | 强弱 | 示例 |
|---|---|---|---|---|---|
| 泛化 | is-a 继承 | 实线 | 空心三角→父类 | 最强 | Dog → Animal |
| 实现 | 实现接口 | 虚线 | 空心三角→接口 | 最强 | Bird ⇢ Flyable |
| 组合 | 强拥有，同生共死 | 实线 | 实心菱形◆整体端 | 强 | Bird ◆— Wing |
| 聚合 | 弱拥有，可分离 | 实线 | 空心菱形◇整体端 | 较强 | Team ◇— Player |
| 关联 | 结构联系，平等引用 | 实线 | 无/开箭头 | 中 | Teacher — Student |
| 依赖 | 临时使用 | 虚线 | 开箭头→被依赖 | 最弱 | Person ⇢ Car |
看"部分能否脱离整体独立存在"：
· 能独立 → 聚合（空心菱形）：球队-球员、图书馆-书、班级-学生
· 不能独立 → 组合（实心菱形）：鸟-翅膀、公司-部门、订单-订单明细
3.4 多重性（Multiplicity）规则
多重性标注在关联线两端，表示一个对象与对方多少个对象相关联。
| 表示 | 含义 | 说明 |
|---|---|---|
| 1 | 恰好一个 | 必须且只能有一个对象 |
| 0..1 | 零或一个 | 可选，最多一个 |
| * 或 0..* | 零或多个 | 任意数量 |
| 1..* | 一或多个 | 至少一个 |
| m..n | m 到 n 个 | 指定区间，如 2..5 |
| n | 恰好 n 个 | 如 2 表示固定 2 个 |
3.5 完整类图示例：Shape 图形体系
下面是一个综合了泛化、实现、组合、依赖等关系的完整类图示例：抽象类 Shape 派生 Circle 和 Rectangle，Shape 组合了 Color，依赖 Canvas，Circle 实现 Drawable 接口。
类图设计要点
- 抽象类名用斜体，抽象方法也用斜体（如 Shape 及其 area()）。
- 接口用 «interface» 构造型标注。
- 菱形（聚合/组合）总是画在整体一端，不是部分端。
- 三角箭头（泛化/实现）总是指向父类/接口。
- 静态成员用下划线表示。
四、用例图（Use Case Diagram）
用例图是从外部视角描述系统功能的利器，常用于需求分析阶段。它回答"系统能为谁做什么"，是软件需求规约的重要组成部分。
4.1 基本元素
- 参与者（Actor）：与系统交互的外部实体，用小人图形表示。可以是人、外部系统、设备等。
- 用例（Use Case）：系统为参与者提供的一项完整功能，用椭圆表示，通常用动宾短语命名（如"取款"）。
- 系统边界（System Boundary）：用矩形框表示系统的范围，框内是用例，框外是参与者。
- 关联关系：参与者与用例之间用实线连接。
4.2 用例间的关系
| 关系 | 表示 | 语义 |
|---|---|---|
| 包含 include | 虚线箭头，«include»，指向被包含用例 | 基用例必然执行被包含用例，用于提取公共行为 |
| 扩展 extend | 虚线箭头，«extend»，指向基用例（扩展指向基） | 扩展用例在特定条件下才执行，是可选行为 |
| 泛化 generalization | 实线空心三角，指向父用例 | 子用例继承并特化父用例 |
· include：基用例 →（«include»）→ 公共用例。例如"取款"必然"身份验证"。
· extend：扩展用例 →（«extend»）→ 基用例。例如"打印凭条"扩展"取款"（可选）。
记忆：包含是"必须"，扩展是"可选"。
4.3 ATM 用例图示例
案例研究：在线购物用例图
参与者：买家、卖家、支付系统（外部）。核心用例：浏览商品、加入购物车、下单、支付、物流跟踪。其中"下单"必然包含"库存校验"；"使用优惠券"扩展"下单"（可选）；"支付"包含"身份验证"。
- «include»：下单 → 库存校验；支付 → 身份验证（必须执行）
- «extend»：使用优惠券 → 下单（满足条件时执行）
- 泛化：买家 → VIP买家（特化，享受更多权益）
· 把"扩展"和"包含"的方向画反。记住：扩展用例指向基用例，包含基用例指向公共用例。
· 把参与者画成系统内部模块。参与者必须是系统外部的实体。
· 用例描述过于细碎（如"点击按钮"不是用例，用例应是完整的功能）。
五、序列图（Sequence Diagram）
序列图按时间顺序展示对象之间的消息交互，是交互图中最常用的一种。它强调"谁在什么时候给谁发了什么消息"。
5.1 基本元素
- 生命线（Lifeline）：对象下方的垂直虚线，表示对象在时间上的存在。
- 激活条（Activation Bar）：生命线上的矩形条，表示对象正在执行操作。
- 消息（Message）：对象间的水平箭头，分同步、异步、返回、创建、删除等。
| 消息类型 | 表示 | 含义 |
|---|---|---|
| 同步消息 | 实线 + 实心箭头 ▶ | 调用者等待返回 |
| 异步消息 | 实线 + 开箭头 > | 调用者不等待，立即继续 |
| 返回消息 | 虚线 + 开箭头 | 返回结果 |
| 创建消息 | 带 «create» 的箭头 | 创建新对象 |
| 删除消息 | 箭头末端加 X | 销毁对象 |
5.2 组合片段（Combined Fragment）
组合片段用于表达更复杂的控制逻辑，是序列图的高级特性，也是软考常考点。
| 片段 | 含义 | 等价程序结构 |
|---|---|---|
| alt | 备选（多分支，互斥） | if-else if-else |
| opt | 可选（单分支） | if（无 else） |
| loop | 循环 | for / while |
| break | 中断（条件成立时跳出） | break |
| par | 并行（多区域同时执行） | 并行任务 |
| ref | 引用（复用其他序列图） | 调用子流程 |
5.3 在线支付序列图
案例研究：用户登录序列
对象：User、LoginUI、AuthService、UserDAO。流程：User 输入凭证 → LoginUI 调用 AuthService.login() → AuthService 查询 UserDAO → UserDAO 返回用户信息 → AuthService 校验密码 → 返回 token 给 LoginUI → 显示登录成功。其中"密码校验失败"可用 opt 片段表示重试逻辑，三次失败用 loop + break 跳出锁定账户。
六、活动图（Activity Diagram）
活动图类似流程图，用于描述业务流程、算法步骤或工作流。它能清晰表达控制流、分支、并发与数据流，是需求分析与流程设计的利器。
6.1 基本节点
- 活动（Activity）：圆角矩形，表示一个动作步骤。
- 判断（Decision）：菱形，根据条件分支，带守卫条件 [条件]。
- 合并（Merge）：菱形，多个分支汇合。
- 分叉/汇合（Fork/Join）：粗实线，表示并发开始/结束。
- 初始节点：实心圆；结束节点：圆中带实心圆。
- 泳道（Swimlane）：划分责任主体，明确"谁做什么"。
6.2 订单处理活动图（含泳道）
· Fork/Join（粗实线）：表示并发执行，多流同时进行，Join 等待全部完成。
· Decision/Merge（菱形）：表示互斥选择，根据条件走其中一条，Merge 汇合。
这是活动图最高频考点，切勿混淆。
案例研究：退款流程活动图
客户发起退款 → 系统校验订单状态 → 判断是否在退款期内：[是] 进入审核流程，[否] 拒绝并通知客户；审核通过则退款到原账户 → 通知客户完成；审核拒绝则驳回。该流程可用泳道划分为"客户、客服、系统、财务"四条泳道，清晰体现各角色职责与流程并发。
七、状态图（State Machine Diagram）
状态图描述一个对象在其生命周期内所经历的各种状态、状态间的转换以及触发转换的事件。它特别适合描述具有明显状态特征的实体（如订单、连接、文档审批）。
7.1 基本元素
- 状态（State）：圆角矩形，表示对象所处的稳定情形。可包含 entry/do/exit 动作。
- 转换（Transition）：带箭头的实线，标注
事件[守卫条件]/动作。 - 初始状态：实心圆；终止状态：圆中带实心圆。
7.2 订单状态机示例
案例研究：TCP 连接状态图
TCP 连接的有限状态机是状态图的经典案例。主要状态：CLOSED → SYN_SENT → ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED（主动关闭方）；服务端则 LISTEN → SYN_RCVD → ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED。事件包括 SYN、SYN+ACK、ACK、FIN、RST 等报文。绘制时注意 TIME_WAIT 的 2MSL 定时器转换。这是软考论述题常考的综合性状态图。
八、组件图与部署图
组件图与部署图都属于结构图，用于描述系统的物理视角：组件图关注软件的模块化构成，部署图关注软件到硬件的映射。
8.1 组件图（Component Diagram）
组件图描述系统中可替换的物理单元（组件）及其通过接口的依赖关系。组件用带 «component» 构造型或右上角小图标的矩形表示。接口分为提供接口（lollipop 棒糖符号）和需求接口（半圆符号）。
8.2 部署图（Deployment Diagram）
部署图描述软件构件（Artifact）部署到硬件节点（Node）上的物理拓扑，以及节点间的通信路径。节点用立体方块表示，构件画在节点内部。
案例研究：微服务部署图
一个典型微服务部署：网关节点（Nginx + API Gateway）部署在 DMZ；多个应用节点（K8s Worker）分别运行订单服务、支付服务、商品服务容器；缓存节点（Redis）；数据库主从节点；消息队列节点（Kafka）。节点间通过内部网络通信，对外通过 HTTPS 网关。绘制时把每个容器作为构件画在对应 Worker 节点内，节点间标注 gRPC/MQ 协议。
九、其他 UML 图简介
9.1 对象图（Object Diagram）
对象图是类图在某一时刻的实例化快照，展示具体的对象及其链接（Link）。对象名格式为 对象名:类名，下方列出属性的具体值。常用于验证类图设计、理解复杂场景。
9.2 包图（Package Diagram）
包图以包（文件夹形状）为组织单元，描述模块间的依赖关系。包可用于组织类、用例等元素，依赖用虚线开箭头表示。它体现系统的分层与模块化。
9.3 通信图（Communication Diagram）
通信图（UML 1.x 称协作图）与序列图表达相同信息，但更强调对象间的结构关系而非时间顺序。消息用带序号的箭头标注在连接线上，序号表示发送顺序。
9.4 定时图（Timing Diagram）
定时图描述对象状态或属性值随时间轴（横轴）的变化，常用于实时系统、嵌入式系统，刻画时序约束。状态用水平条带表示，时间轴上标注事件。
对象图是类图的实例化。类图描述"结构定义"，对象图描述"某一时刻的实例快照"。类图中属性只有类型，对象图中属性有具体值；类图中类名不加下划线，对象图中对象名加下划线。
· 序列图：强调时间顺序，生命线自上而下。
· 通信图：强调对象结构关系，消息带序号。
两者语义等价，可相互转换，都是交互图的子类型。
十、UML 建模实战案例：在线考试系统
本节以"在线考试系统"为例，完整演示如何从需求出发，逐步用多种 UML 图进行建模。一个典型的建模流程是：用例图（需求）→ 类图（静态结构）→ 序列图（关键交互）→ 活动图（业务流程）→ 部署图（物理架构）。
10.1 用例图：需求建模
参与者：学生、教师、管理员。学生参加考试；教师出题、阅卷；管理员管理用户与系统。核心用例：登录、参加考试、自动判分、出题、阅卷、统计成绩。
10.2 类图：静态结构建模
识别核心实体类：User（用户基类）、Student、Teacher（继承 User）、Exam（考试）、Paper（试卷）、Question（题目）、Answer（作答）、Score（成绩）。关系：Student/Teacher 泛化自 User；Exam 组合 Paper；Paper 聚合 Question；Student 关联 Answer；Answer 关联 Score。
10.3 序列图：关键交互建模
描述学生参加考试的关键交互：Student → ExamUI → ExamService → Paper → Question，含 loop 循环答题与提交判分。
10.4 活动图：考试流程建模
考试流程：登录 → 选择考试 → 加载试卷 → 判断是否客观题：客观题自动判分，主观题教师阅卷 → 汇总成绩 → 发布。用泳道划分学生、系统、教师三方。
10.5 部署图：物理架构建模
部署架构：客户端浏览器 → Web 服务器（考试应用）→ 应用服务器（判分服务）→ 数据库服务器；外部对接题库服务。
用例图明确"做什么" → 类图明确"由什么组成" → 序列图明确"如何交互" → 活动图明确"流程如何走" → 部署图明确"部署在哪里"。五种图从需求到实现逐层细化，构成完整的建模链条。
十一、软考考点总结与真题
11.1 必背考点清单
核心记忆要点
- UML 起源：Booch + OMT + OOSE 三方法统一，OMG 标准化，UML 2.x 共 13 种图。
- 两大分类：结构图（7 种，静态）+ 行为图（6 种，动态，含 4 种交互图子集）。
- 六种关系及箭头（最高频）：泛化(实线空心三角)、实现(虚线空心三角)、组合(实心菱形)、聚合(空心菱形)、关联(实线)、依赖(虚线开箭头)。
- 关系强弱：泛化=实现 > 组合 > 聚合 > 关联 > 依赖。
- 菱形方向：聚合/组合的菱形总在整体一端；三角总指向父类/接口。
- 用例关系：include（必须，基→公共）、extend（可选，扩展→基）、泛化。
- 序列图组合片段：alt(分支)、opt(可选)、loop(循环)、break(中断)、par(并行)。
- 活动图：Fork/Join 表并发，Decision/Merge 表选择，二者不可混淆。
- 可见性符号：+ 公有、- 私有、# 受保护、~ 包内。
- 多重性：1、0..1、*、1..*、m..n。
11.2 历年真题精讲
真题一（类图关系辨析）
在某在线交易系统中，"订单"与"订单明细"之间的关系是：订单删除时其所有订单明细一并删除。则订单与订单明细之间应使用 UML 类图中的哪一种关系？请给出表示符号。
解析：订单明细不能脱离订单独立存在，订单删除则明细同时删除，属于"同生共死"的强整体-部分关系，故为组合。表示为实线 + 实心菱形，菱形画在订单（整体）一端。
易错点：若题目说明"部分可独立存在"（如球队-球员），则为聚合（空心菱形）。
真题二（用例图 include/extend）
某 ATM 系统，"取款"用例执行时必然执行"身份验证"用例；而"打印凭条"用例仅在用户选择打印时才执行。请分别说明这两个用例关系类型及箭头方向。
1. 取款与身份验证为 «include»（包含）关系：取款（基用例）→（«include»虚线箭头）→ 身份验证（被包含用例）。"必然执行"是 include 的标志。
2. 打印凭条与取款为 «extend»（扩展）关系：打印凭条（扩展用例）→（«extend»虚线箭头）→ 取款（基用例）。"可选/条件执行"是 extend 的标志。
记忆：包含是"必须"（基→公共），扩展是"可选"（扩展→基）。
真题三（UML 图分类与序列图片段）
UML 2.0 共提供了多少种图？请说明其分类。在序列图中，用于表示"条件成立时执行，否则跳过"的组合片段是哪一个？表示"多分支互斥选择"的又是哪一个？
UML 2.0 共提供 13 种图，分为两大类：结构图（7 种）——类图、对象图、组件图、部署图、包图、复合结构图、轮廓图；行为图（6 种）——用例图、活动图、状态机图、序列图、通信图、定时图（其中序列/通信/定时/交互概览统称交互图）。
序列图中："条件成立时执行，否则跳过"对应 opt（可选片段）；"多分支互斥选择"对应 alt（备选片段）。
辨析：opt 等价于无 else 的 if；alt 等价于 if-else if-else；loop 表循环；par 表并行。
11.3 记忆技巧与易错点
· 六关系速记："泛实组聚关依"（泛化、实现、组合、聚合、关联、依赖），强弱从左到右递减。
· 菱形口诀："空聚实组"——空心菱形是聚合（弱），实心菱形是组合（强）。
· 三角口诀："实泛虚实"——实线三角是泛化，虚线三角是实现。
· 图分类口诀：结构七（类对组部署包复轮），行为六（用活状序通定）+ 交互概览。
· 组合片段：alt 选一、opt 可选、loop 循环、par 并行、break 中断。
1. 把 include 和 extend 方向画反——记住 include 是基指向公共，extend 是扩展指向基。
2. 把聚合和组合搞混——关键看"部分能否脱离整体独立存在"。
3. 把 Fork/Join（并发）与 Decision/Merge（选择）混淆——前者是粗实线，后者是菱形。
4. 把序列图与通信图混为一谈——前者强调时间顺序，后者强调对象结构。
5. 把交互图当成独立于行为图的第三类——交互图是行为图的子集。
6. 把 UML 1.x 的 9 种图与 UML 2.x 的 13 种图混淆——考试按 13 种作答。
| 对比维度 | 序列图 | 通信图 | 活动图 |
|---|---|---|---|
| 强调重点 | 时间顺序 | 对象结构关系 | 控制流与数据流 |
| 消息表示 | 纵向生命线箭头 | 带序号的连线箭头 | 不直接表示消息 |
| 适合场景 | 方法调用时序 | 对象协作结构 | 业务流程/算法 |
| 所属类别 | 交互图 | 交互图 | 行为图 |
11.4 结语
UML 是软件架构师与系统分析师的"通用语言"。掌握 UML 不仅是应对软考的需要，更是进行规范化软件设计的基础。在实际工程中，不必拘泥于画出所有 13 种图，而应根据建模目的选择最合适的图：需求阶段多用用例图，设计阶段多用类图与序列图，流程梳理用活动图，状态复杂的对象用状态机图，部署交付用组件图与部署图。建模的核心价值在于"沟通与思考"——把脑中模糊的设计可视化、可讨论、可验证。
建议结合本系列其他文章（软件架构风格、质量属性、ATAM 评估等）一起复习，形成从建模→架构→评估的完整知识体系。多动手画图、多做真题，是掌握 UML 建模的不二法门。