下面把 UML 建模（下午试题三）相关的知识点系统整理成一份完整文档，结构参照 DFD 和 ER，从 UML 整体定位、六大关系、类图、用例图、序列图，到考试题型、答题方法和检查清单，最后给出背诵口诀。
UML 建模 · 系统整理
一、UML 在软考中的定位
UML 建模是下午试题三（15 分必答），考法以补充类名、补充多重度、补充用例关系、补充消息名为主，极少要求从零画整张图。
软件设计师涉及的 UML 图按用途分为三类：
- 静态建模：类图、对象图、用例图。
- 动态建模：序列图（时序图/顺序图）、通信图、状态图、活动图。
- 物理建模：构件图、部署图。
下午题高频图种是类图和用例图，序列图次之；状态图和活动图偶尔出现，通常只要求补状态名或转换条件。上午选择题则可能涉及图的分类（静态/动态/物理）和接口、部署图的使用阶段等边角知识。
二、UML 类图的六大关系（核心考点）
类图是 UML 的核心，描述系统的静态结构——类的属性、方法以及类与类之间的关系。六大关系必须从符号、语义、代码表现、强度排序四个维度同时掌握。
1. 六种关系总表
| 关系 | 线条与端点符号 | 箭头/菱形方向 | 语义 | 代码表现 |
|---|---|---|---|---|
| 依赖 | 虚线 + 开口箭头 | 指向被依赖的类 | 临时使用，一方变化“波及”另一方 | 方法参数、局部变量、返回值 |
| 关联 | 实线（可带开口箭头） | 有箭头时指向被关联类 | 长期结构关系，“知道并持有” | 成员变量 |
| 聚合 | 实线 + 空心菱形 | 菱形在整体端 | 弱拥有，部分可脱离整体独立存在 | 成员变量，外部注入 |
| 组合 | 实线 + 实心菱形 | 菱形在整体端 | 强拥有，部分生命周期由整体控制 | 成员变量，整体内部创建 |
| 泛化（继承） | 实线 + 空心三角 | 三角尖端指向父类 | “is-a”，子类继承父类 | extends（Java） |
| 实现 | 虚线 + 空心三角 | 三角尖端指向接口 | 类实现接口契约 | implements（Java） |
符号速记：依赖虚线开口，关联实线直连；聚合空心菱，组合实心菱；泛化实线空心三角，实现虚线空心三角。菱形永远在整体端。
2. 强度排序（易错，但考得隐蔽）
六种关系的耦合强度从强到弱为：泛化 > 组合 > 聚合 > 关联 > 实现 ≈ 依赖。绑定越紧，一方的修改对另一方的影响越大。这个排序在选择题中可能以“哪种关系耦合最强/最弱”的形式出现。
3. 聚合 vs 组合（最高频辨析）
两者的区分只看生命周期是否同步：
- 聚合：整体消失，部分仍然存在。如“部门”与“员工”，部门撤销，员工调到其他部门继续存在。
- 组合：整体消失，部分随之销毁。如“订单”与“订单项”，订单删除，订单项也不复存在。
考试中如果题干强调“同生共死”“不可分割”“随整体销毁”，选组合；如果强调“可独立存在”“可脱离整体”，选聚合。
4. 依赖的判定（容易漏判）
依赖是最弱的关系，表现为临时使用：一个类的方法把另一个类的对象作为参数、局部变量或返回值，就构成依赖。如果两个类之间只是“方法里用了一下”，没有成员变量长期持有，就画依赖虚线，而不是关联实线。
5. 类框与可见性
类框通常分三层：类名、属性、方法。可见性符号：+ 公开（public），- 私有（private），# 保护（protected）。
下午题注意：业务分析层面的类图不应出现 getter/setter 等纯技术方法，应列出与业务规则相关的核心操作。
三、多重度（类图必考填空）
多重度写在关联线两端，表示“一个类的实例可以与另一个类的多少个实例相关联”。考试中常以填空形式出现，要求补齐 (1)~(4) 处的多重度。
| 写法 | 含义 |
|---|---|
1 | 恰好一个 |
0..1 | 零个或一个 |
* 或 0..* | 零个或多个 |
1..* | 至少一个 |
判定方法（最关键） ：站在每一端，看对方。
- 站在 A 端看 B：一个 A 对象对应几个 B 对象？把答案写在 B 端。
- 站在 B 端看 A：一个 B 对象对应几个 A 对象？把答案写在 A 端。
易错点：只标一边、把“0”漏掉（新系统刚上线可以没有订单）、把 1..* 和 0..* 搞混。题干中出现“一个……可以对应多个……”或“至少一个”的描述，直接对应到两端的多重度。
四、用例图
用例图描述参与者、用例以及它们之间的关系，用于获取需求和指导测试。下午题常考“补充参与者名、补充用例名、判断用例之间的关系”。
1. 基本图形
- 参与者（Actor） ：火柴人，画在系统边界之外。可以是人、硬件或其他系统扮演的角色。“时间”不能作为参与者。
- 用例：椭圆，内写“动词 + 名词”的用例名（如“借书”“还书”）。用例必须对参与者有可观测的完整结果，不能把内部步骤拆成独立用例（“验证密码”不是用例，“登录”才是）。
- 系统边界：可选矩形框包围所有用例，参与者画在框外。
2. 四种关系与箭头方向（最大陷阱）
| 关系 | 线条 | 箭头方向 | 语义 |
|---|---|---|---|
| 关联 | 实线（可带箭头） | 参与者指向用例 | 参与者使用用例 |
| 包含（include） | 虚线 + 箭头 + 《include》 | 指向被包含的用例 | 基本用例一定会执行被包含用例 |
| 扩展（extend） | 虚线 + 箭头 + 《extend》 | 指向基础（被扩展）用例 | 扩展用例有条件才执行 |
| 泛化 | 实线 + 空心三角 | 三角指向父用例/父参与者 | 继承关系 |
箭头口诀：“包箭被，扩箭基”——include 箭头指向被包含的用例；extend 箭头指向基础（被扩展） 的用例。
3. include 与 extend 的语义区分
- include：把多个用例的公共行为抽出来，必然执行。如“借书”和“还书”都需要“验证借书证”，把“验证借书证”抽成被包含用例。
- extend：扩展用例是可选的、条件性的，基础用例本身是完整的，只有扩展点被激活时才执行扩展用例。如“还书”时如果超期才触发“计算罚款”。
答题判断：题干说“必须”“一定”“公共步骤”→ include；说“可选”“如果”“特殊情况下”→ extend。
五、序列图（时序图）
序列图是交互图，强调对象之间消息传递的时间顺序。下午题常考“补充对象名、补充消息名、补充消息顺序”，上午题常考消息类型和生命线。
1. 三大核心元素
- 对象：矩形框，格式为“对象名 : 类名”，两者都可省略。发起交互的对象通常放在最左边。
- 生命线：从对象框底部垂直向下的虚线，代表对象在交互中的存在时间。
- 激活期（控制焦点） ：生命线上的细长矩形，表示对象执行一个操作的时间段。生命线是虚线，激活期是长条，不能混淆。
2. 消息类型（高频辨析）
- 同步消息：实心三角箭头，发送者等待接收者处理完成（如客户端上传文件后等服务器确认）。
- 异步消息：空心三角箭头，发送者不等待返回，继续执行。
- 返回消息：虚线 + 开口箭头，表示方法调用返回结果。
时间方向自上而下，消息按发生的先后顺序从上到下排列。
六、其他图种（低频，认识即可）
- 状态图：描述一个对象在生命周期内的状态变迁，常考补状态名和转换条件。
- 活动图：描述流程和并行行为，常考补活动结点名称。
- 部署图：通常在实施阶段使用，考图分类时可能涉及。
七、下午题题型与答题方法
题型一：补充类名
题干给出类名清单（表 3-1）和类图框架，要求把类名填入空缺的类框。方法：读题干中每个类的职责描述，与清单中的类名逐一匹配；先填职责最明确的类，用排除法处理剩余空缺。
题型二：补充多重度
按“站在每一端看对方”的方法逐一判定。题干中的数量词（“一个”“多个”“至少一个”“可以没有”）是直接线索。两端都要标，不能只标一边。
题型三：判断或补充类图关系
看两个类之间是“临时使用”（依赖）、“长期持有”（关联）、“整体—部分”（聚合/组合，看生命周期）还是“父子继承”（泛化）。符号要严格对应：菱形在整体端、三角指父类/接口。
题型四：补充用例名/参与者名，判断用例关系
参与者从题干中的“人/部门/外部系统”提取，用题干原词。用例名用“动词+名词”，不要拆内部步骤。关系判断用“必须/公共”→ include，“可选/如果”→ extend，箭头方向对照“包箭被，扩箭基”。
题型五：补充序列图的消息名或对象名
消息名通常对应接收对象类中的方法名；对象名对应类名。结合题干描述的操作步骤，按时间顺序从上到下补全。
答题规范
- 类名、用例名、消息名用题干原词，不要自己发明。
- 多重度写标准形式（
1、0..*、1..*），不要写“多个”这种口语。 - 关系符号画标准：菱形在整体端、泛化三角指父、include/extend 箭头方向不能反。
八、高频易错点汇总
- 聚合/组合菱形方向反：菱形必须在整体端，不是部分端。
- 把组合和聚合的生命周期语义搞反：组合是同生共死，聚合是可分离。
- include 与 extend 箭头方向搞反：记住“扩箭基”——extend 指向基础用例。
- 把“可选/条件”画成 include：可选行为必须用 extend。
- 多重度只标一边或漏标“0”：两端都要标，
0..*的“0”不能省。 - 依赖与关联混淆：临时使用（参数/局部变量）是依赖，长期持有（成员变量）是关联。
- 泛化和实现混用：继承父类用实线空心三角，实现接口用虚线空心三角。
- 把内部步骤拆成用例：用例必须对参与者有完整可观测结果，“验证密码”不是用例。
- 参与者画进系统边界内：参与者一定在外部。
- 序列图生命线与激活期混淆：虚线是生命线（对象存在），细长矩形是激活期（对象忙碌）。
九、UML 答题检查清单
第一步：符号与方向
- 类图：菱形在整体端？泛化三角指父类/接口？泛化实线、实现虚线？
- 用例图：include 箭头指向被包含用例？extend 箭头指向基础用例？
- 序列图：同步消息实心三角、异步消息空心三角、返回消息虚线？
第二步：标注
- 多重度两端都标了吗？“0”有没有漏？
- 用例关系的构造型
《include》/《extend》写了吗？ - 类框的类名、属性、方法层级是否合理？
第三步：语义
- 聚合 vs 组合看生命周期：同生共死是组合，可分离是聚合。
- include vs extend 看必然性：必须执行是 include，有条件才执行是 extend。
- 依赖 vs 关联看持续性：临时使用是依赖，成员变量持有是关联。
第四步：用词
- 类名、用例名、消息名是否用了题干原词？
- 有没有把内部步骤拆成用例？
- 参与者是否在系统边界之外？
十、UML 背诵清单（直接背）
- 六大关系符号：依赖虚线开口，关联实线直连；聚合空心菱，组合实心菱；泛化实线空心三角，实现虚线空心三角。
- 菱形在整体端，泛化三角指父类/接口。
- 强度排序：泛化 > 组合 > 聚合 > 关联 > 实现 ≈ 依赖。
- 聚合 vs 组合：生命周期同步是组合，可分离是聚合。
- 依赖：方法参数/局部变量/返回值中使用，临时关系。
- 多重度：
1、0..1、0..*、1..*；站在每一端看对方，两端都标。 - 用例关系箭头：包箭被，扩箭基——include 指被包含，extend 指基础。
- include = 必须/公共行为；extend = 可选/条件触发。
- 用例名“动词+名词”，不拆内部步骤；参与者必须在系统边界外。
- 序列图：对象名:类名；生命线是虚线，激活期是长条；同步实心三角，异步空心三角，返回虚线开口。
- 答题用题干原词，不自己发明名称。
- 业务类图不塞 getter/setter，只列业务核心操作。
十一、UML 速记口诀
类图六关系：依赖虚线箭，关联实线连；聚合空心菱，组合实心菱；泛化实线三角指父，实现虚线三角指接口；菱形永远在整体端，生命周期分聚合组合。
用例四关系：关联实线指用例，包含虚线箭头指被包，扩展虚线箭头指基础，泛化空心三角指父类。包箭被，扩箭基；必须 include，可选 extend。
多重度：站一端看另一端，两端都标不漏零；同生共死是组合，可脱整体是聚合。
序列图：对象在上线向下，同步实心异步空，返回虚线开口箭，激活长条命是虚。
十二、UML 与 DFD、ER 的区分（防止混淆）
| 对比项 | UML | DFD | ER |
|---|---|---|---|
| 用途 | 面向对象建模，静态结构 + 动态交互 | 结构化分析，数据流动与加工 | 概念设计，业务对象与联系 |
| 矩形 | 类框（类名/属性/方法） | 外部实体 | 实体 |
| 菱形 | 聚合/组合的端点符号（在整体端） | 无 | 联系 |
| 椭圆/圆 | 用例（椭圆） | 加工（圆角矩形/圆） | 属性 |
| 带箭头线 | 部分关系带箭头（依赖、泛化、实现、用例关系） | 全部数据流带箭头 | 无箭头（无向边） |
| 核心标注 | 多重度、构造型 《include》 / 《extend》 | 数据流名词、加工动宾 | 联系类型、主键下划线 |
关键区分：UML 的矩形是类，ER 的矩形是业务实体，DFD 的矩形是系统外部实体；UML 中菱形只作为聚合/组合的端点符号，ER 中菱形是联系本身；UML 的箭头有方向语义，ER 的连线不带箭头。
把以上内容按“六大关系→多重度→用例图→序列图→题型→易错点”的顺序过一遍，再拿历年真题的 UML 题练手，重点练 “多重度两端判定” 和 “include/extend 箭头方向” ，这两条是 UML 下午题最高频的采分点和丢分点。