UML 图、关系与读图练习¶
本篇根据用户提供的软件设计师 UML 讲义整理,覆盖图的分类、关系符号,以及类图、对象图、用例图、顺序图、通信图、活动图、状态机图、构件图和部署图的读法。类图与对象图作为一组讲解,其余按原讲义的八个主题组织。
33 张原配图已保存为本地文件,8 道例题保留题干与选项并统一编号。解释、参考答案和易错辨析为整理时补充;原配图中的简化说法以正文说明为准。
UML 是什么,图如何分类¶
UML(Unified Modeling Language,统一建模语言)是一套描述系统结构与行为的建模语言,可以用于需求、分析、设计和沟通。它不规定必须采用哪一种开发流程,也不是某一种编程语言。
UML 2.x 常见的分类方式是 7 种结构图、7 种行为图,其中 4 种交互图属于行为图。不同版本教材的列表可能有差异,做题应注意题干采用的版本与术语。
| 大类 | 图 | 关注的问题 |
|---|---|---|
| 结构图 | 类图、对象图、包图、构件图、组合结构图、部署图、轮廓图 | 系统由什么组成,元素之间有什么静态关系 |
| 行为图中的非交互图 | 用例图、活动图、状态机图 | 系统提供什么功能,流程如何执行,对象状态如何变化 |
| 行为图中的交互图 | 顺序图、通信图、交互概览图、时间图 | 对象如何通过消息协作,以及顺序和时间约束 |
原图中的“制品图”反映材料的分类口径;制品(Artifact)是模型元素,常在部署等视图中展示,不应直接拿它替代上述常见 14 图分类中的轮廓图。
例题 1:软件与硬件的物理关系¶
在 UML 图中,( )图用于展示所交付系统中软件组件和硬件之间的物理关系。
| A | B | C | D |
|---|---|---|---|
| 类 | 组件 | 通信 | 部署 |
参考答案与解析
参考答案:D。
关键词是“软件与硬件”“物理关系”,对应部署图。构件图关注软件组件及接口、依赖;部署图关注软件部署到哪些设备或执行环境上。
类图中的六种关系¶
| 关系 | 核心含义 | 图形与方向 | 代码理解 |
|---|---|---|---|
| 关联 Association | 描述实例之间可以存在的结构性连接;对象间的具体连接称为链或链接 | 实线,可带导航方向、角色及多重性 | 一个对象持有另一个对象或集合的引用是常见实现 |
| 依赖 Dependency | 一方使用另一方,被使用方的变化可能影响使用方 | 虚线箭头从使用方指向被依赖方 | 方法参数、局部变量、调用等可以形成依赖 |
| 泛化 Generalization | 特殊类型与一般类型的关系 | 实线空心三角指向一般者/父类型 | Java 类的 extends,接口之间的 extends |
| 聚合 Aggregation | 较弱的整体与部分关系 | 空心菱形位于整体端 | 部分可以独立存在;具体共享规则由模型约定 |
| 组合 Composition | 较强的整体所有权关系 | 实心菱形位于整体端 | 部分同一时刻至多归属于一个组合整体,整体负责其生命周期 |
| 实现 Realization | 实现者履行规范或契约 | 虚线空心三角指向规范/接口 | Java 类的 implements 是常见形式 |
读图顺序:先看线型,再看箭头或菱形,最后看它位于哪一端。箭头“指向 B”与“菱形在 B 端”表达的含义不同。
聚合与组合:生命周期口诀的边界¶
“聚合的整体和部分生命周期不同,组合生命周期相同”是记忆口诀,不能机械理解为是否同时创建、同时销毁。
- 聚合本身不强制部分随整体销毁。共享聚合的具体语义较弱,需要结合领域模型理解。
- 组合强调强所有权。销毁整体时,它仍然拥有的对象部分随之销毁;部分可以在整体销毁前移出。
- 组合不要求整体与部分在同一时刻创建,也不能仅凭一个字段的存在断定它是组合关系。
Java 引用和垃圾回收不会自动完整表达 UML 的组合契约,还需要由创建、归属变更和清理等逻辑落实。
从类图推代码¶
| 读图信息 | 实现时检查什么 |
|---|---|
| 类名、属性、操作 | 对应类、字段和方法;图可省略与当前问题无关的成员 |
+、-、#、~ |
分别是公有、私有、保护、包可见 |
| 泛化、实现 | 分别检查继承关系和接口实现关系 |
| 可导航关联 | 能否从一端获得另一端对象,例如通过字段或访问方法 |
多重性为 1 |
单个关联对象,并维护“必须存在”的约束 |
多重性为 0..1 |
可选的单个关联对象 |
多重性为 * 或 1..* |
通常使用集合,并按需要保证是否允许为空 |
不是每张概念类图都能直接翻译为代码。领域模型强调业务概念,设计类图才更接近实现;同一张图也可能允许多种满足约束的实现。
例题 2:Shop、Magazine 与 Page¶
如下所示的 UML 类图中,Shop 和 Magazine 之间为(①)关系,Magazine 和 Page 之间为(②)关系。UML 类图通常不用于对(③)进行建模。
| 选项 | 第①空 | 第②空 | 第③空 |
|---|---|---|---|
| A | 关联 | 关联 | 系统的词汇 |
| B | 依赖 | 依赖 | 简单的协作 |
| C | 组合 | 组合 | 逻辑数据库模式 |
| D | 继承 | 继承 | 对象快照 |
参考答案与解析
参考答案:A、C、D。
Shop 与 Magazine 通过普通实线连接,表示关联。Magazine 一端有实心菱形,表示 Magazine 是组合整体,Page 是部分。某一时刻的具体对象快照由对象图表达。类图可以描述协作中的静态结构,但不展示具体交互的时间顺序。
类图、对象图与多重性¶
**类图**描述类、接口及其静态关系,例如属性、操作、继承和关联。它展示类型层面的结构;原讲义“类图描述一组对象”的说法不够准确,应与对象图区分。
**对象图**描述某一时刻的对象实例及链接,是实例层面的静态快照。常用 对象名 : 类名 标记实例,并以带下划线的名称区分于类,例如 a1 : A。
类图可以用于系统词汇、静态协作结构和逻辑数据库模式建模。若模型包含活动类,还可表现相关的静态进程结构;这不意味着类图本身能显示运行时的消息先后顺序。
多重性必须从对端读起¶
某一端的多重性,表示对端一个实例可以关联到本端多少个实例。
| 标记 | 含义 |
|---|---|
1 |
恰好一个 |
0..1 |
零个或一个 |
*、0..* |
零个或多个 |
1..* |
一个或多个,至少一个 |
例如 A 1 ─── * B 应读成:每个 A 可以关联零个或多个 B;每个 B 必须关联恰好一个 A。* 不是“至少一个”,也不能把 A 端的 1 误读为“A 只能关联一个 B”。
例题 3:对象图是否符合类图¶
UML 图中,对象图展现了(①),(②)所示对象图与下图所示类图不一致。
第①空选项:
| 选项 | 内容 |
|---|---|
| A | 一组对象、接口、协作和它们之间的关系 |
| B | 一组用例、参与者以及它们之间的关系 |
| C | 某一时刻一组对象以及它们之间的关系 |
| D | 以时间顺序组织的对象之间的交互活动 |
第②空的对象图选项:
A:
B:
C:
D:
参考答案与解析
对象图展示某一时刻的实例及其关系,所以第①空选 C。题图规定每个 B 只对应一个 A。选项 D 中,b1 : B 同时关联 a1 : A 和 a2 : A,违反 A 端的 1,因此不一致。选项 B 则符合 B 端的 *:一个 A 可以关联多个 B。
用例图与三种用例关系¶
用例图描述 参与者、用例、系统边界及它们之间的关系。参与者代表系统外部的角色,既可以是人,也可以是其他系统或设备。
参与者与用例之间的实线表示参与或通信,不表达功能执行的先后顺序。用例描述的是参与者通过系统实现的目标,也不一定与某个页面或某个方法一一对应。
包含 include¶
包含关系把另一个用例的行为纳入基础用例,常用于提取多个用例都需要的公共行为,也可以用于组织较复杂的用例,不要求被包含用例必须有两个以上的包含者。箭头从 包含者指向被包含用例,使用虚线箭头并标注 «include»。
图中,“学习课程”和“课程测试”都包含“检查权限”。教材有时将提取的公共用例称为抽象用例,但不应仅凭存在 include 就断定它必须被标成 UML 的抽象分类器。
记忆时可用“大功能纳入公共行为”。更精确地说,执行到包含位置时,要执行被包含的行为;若该位置处于条件分支中,不能脱离流程说所有执行路径都必然经过它。也不能以两段需求文字是否挨在一起判断包含关系。
扩展 extend¶
扩展关系在指定扩展点为基础用例加入额外行为,可以附带扩展条件;基础用例本身应有独立、完整的含义。条件为真或没有指定条件时,可以执行扩展行为。箭头从 扩展用例指向基础用例,使用虚线箭头并标注 «extend»。
图中“充入学习币”扩展“课程测试”。“如果”“若”“只有”等词可以提示条件,但仅有条件分支并不足以决定采用 extend,还要看是否存在基础用例之外的附加行为及合适的扩展点。
泛化 generalization¶
用例泛化表达“一种特殊形式”的关系。子用例继承一般用例的特征,并可进一步特化或增加行为。使用 实线空心三角,指向父用例。
参与者之间也可以存在泛化关系,例如“管理员”是某类“用户角色”的特化。
| 关系 | 核心判断 | 箭头从哪里指向哪里 |
|---|---|---|
| include | 纳入公共、必需的行为片段 | 基础用例 → 被包含用例 |
| extend | 在扩展点加入额外行为,可以附带条件 | 扩展用例 → 基础用例 |
| 泛化 | 一般形式与特殊形式 | 特殊用例/参与者 → 一般用例/参与者 |
UML 的 extend 是用例扩展,Java 的 extends 是类型继承。 名称相似,不能混为一谈。
用例建模流程¶
- 识别参与者,明确系统边界。
- 按参与者目标组织需求,提炼用例。
- 细化用例描述,包括前置条件、主要流程、备选流程和结果。
- 按需要调整用例模型及关系。
原讲义将前三项列为必须、模型调整列为可选。实际开发可以迭代进行,不必将“合并需求”理解成把多个独立目标强行合成一个大用例。
例题 4:用例和参与者共有的关系¶
UML 用例图展现了一组用例、参与者以及它们之间的关系。其中,( )关系既可以存在于用例和用例之间,又可以存在于参与者与参与者之间。
| A | B | C | D |
|---|---|---|---|
| 扩展 | 泛化 | 关联 | 包含 |
参考答案与解析
参考答案:B。
用例可以有一般与特殊形式,参与者也可以有一般与特殊角色,两者都能使用泛化关系。include 和 extend 则是用例之间的关系。
顺序图:沿生命线读消息顺序¶
顺序图也称序列图、时序图,是强调 消息先后关系 的交互图。横向通常排列参与交互的对象或角色,纵向沿生命线从上往下展示事件。
| 元素 | 如何读 |
|---|---|
| 对象或角色框 | 谁参与这次交互,例如 :CardReader、:Session |
| 生命线 | 该参与者在交互中的存在过程;普通垂直虚线不表示消息 |
| 执行规格(常称激活条) | 该参与者执行某个行为的期间 |
| 消息箭头 | 从发送方指向接收方,名称说明请求或信号 |
| 返回消息 | 通常用虚线箭头,可标注结果,也可省略 |
| 创建与销毁 | 创建消息到达新生命线起点;销毁通常以叉号表示 |
alt、opt、loop 等组合片段 |
表达选择、可选和循环等交互结构 |
顺序图不要求必须标有 1、2、3…;沿生命线的事件先后关系比数字编号更重要。不同生命线之间没有因果联系的事件,也不应仅凭画面高度推断绝对先后。
消息的接收者决定方法属于谁¶
箭头从 Session 指向 CardReader,消息为 readCard(),说明 Session 发起请求,CardReader 提供被调用操作。调用者需要能获得接收者,例如通过字段、参数或其他查询方式。
下面是这条消息的最小 Java 演示,可保存为 ReadCardDemo.java。它只展示对象协作,不覆盖整张 ATM 图的所有流程。
“有括号就是方法、没括号就是返回值”只能作为这张示例图的辅助线索。识别消息要结合 箭头形状、线型、方向与标注:同步调用通常用实心箭头,异步消息用开放箭头,返回通常用虚线;返回消息也可能带操作签名,括号不是通用判据。创建消息同样可以使用虚线,因此还需看箭头是否到达新生命线的起点,不能把所有虚线都读成返回。
通信图:先看对象连接,再读消息编号¶
通信图也是交互图,强调 参与交互的对象如何连接和组织。它在链接附近标注消息及编号,以表达调用顺序和嵌套关系。
| 对比 | 顺序图 | 通信图 |
|---|---|---|
| 主要关注 | 沿生命线的消息先后关系 | 对象连接及消息协作 |
| 典型布局 | 顶部排列参与者,向下展开生命线 | 对象分布在平面上,以链接相连 |
| 顺序表达 | 主要依靠生命线及消息位置,也可带编号 | 通常依靠消息编号,如 1、1.1、1.2 |
| 推代码时 | 判断接收者、调用先后、循环和分支 | 判断对象持有或获得关系,再按编号还原调用 |
1.1 常表示处理消息 1 过程中发出的嵌套消息。编号格式只是辅助线索,不能仅凭有没有小数点判定图的类型。
例题 5:汽车导航系统的消息¶
如下所示的图为 UML 的(①),用于展示某汽车导航系统中(②)。Mapping 对象获取汽车当前位置(GPS Location)的消息为(③)。
| 选项 | 第①空 | 第②空 | 第③空 |
|---|---|---|---|
| A | 类图 | 对象之间的消息流及其顺序 | 1: getGraphic() |
| B | 组件图 | 完成任务所进行的活动流 | 2: getCarPos() |
| C | 通信图 | 对象的状态转换及其事件顺序 | 1.1: CurrentArea() |
| D | 部署图 | 对象之间消息的时间顺序 | 2.1: getCarLocation() |
参考答案与解析
参考答案:C、A、D。
图中对象通过链接组织,消息用编号表达顺序,属于通信图,因此前两空选 C、A。通信图也表达消息顺序,但本题 D 项的“时间顺序”更直接对应顺序图的侧重点。Mapping 发给 GPS location 的消息是 2.1: getCarLocation();2: getCarPos() 则是 UI 发给 Mapping 的请求,要区分调用层次。
活动图:动作、条件与并发同步¶
活动图描述业务流程或计算过程中的 控制流和对象流/数据流,重点是一件事经过哪些步骤、何时选择分支,以及哪些步骤可以并发。
| 元素 | 符号 | 核心区别 |
|---|---|---|
| 初始节点 | 实心圆 | 启动控制流 |
| 动作 | 圆角矩形 | 表示执行的工作,如收款、配送 |
| 判定/分支 | 通常一入多出的菱形 | 按守卫条件选择出边 |
| 合并 | 通常多入一出的菱形 | 汇集备选路径,不等待所有路径 |
| 分叉 Fork | 通常一入多出的粗线 | 将控制拆为可以并发执行的流 |
| 汇合 Join | 通常多入一出的粗线 | 默认等待所需的各条输入流后继续 |
| 活动终结 | 实心圆外套圆,即靶心 | 结束整个活动 |
| 流终结 | 圆圈内叉号 | 只终结当前流 |
| 泳道 | 按参与者或职责划分的区域 | 表示谁负责哪些动作 |
并发不等于实现时必须使用多线程。 它表达模型中多个流程可以独立推进,实现时可能采用线程、进程、异步任务,甚至由不同人员或系统分别执行。
“有起点和终点”也不足以区分活动图与状态机图。要看节点表达的是 做什么动作,还是 对象处于什么状态。原图中的椭圆状动作框属于讲义画法,读图仍以动作及控制流语义为准。
例题 6:分叉与监护表达式¶
如下所示的 UML 图是(①),图中(Ⅰ)表示(②),(Ⅱ)表示(③)。
| 选项 | 第①空 | 第②空 | 第③空 |
|---|---|---|---|
| A | 序列图 | 合并分叉 | 分支条件 |
| B | 状态图 | 分支 | 监护表达式 |
| C | 通信图 | 合并汇合 | 动作名 |
| D | 活动图 | 流 | 流名称 |
参考答案与解析
参考答案:D、A、B(第②空原选项有措辞问题)。
图展示订单处理的动作和控制流,属于活动图。Ⅰ 是一入两出的粗线,语义为并发分叉 Fork;原材料 A 写作“合并分叉”,这里保留原选项,但正确概念应记为“并发分叉”。下方多入一出的粗线才是并发汇合 Join。
Ⅱ 指向 [not complete],即守卫条件/监护表达式,按题目术语选 B。它在此处确实起到分支条件的作用,因此不能把选项 A 与 B 理解为在所有语境下都完全互斥;本题考查的是图上标注的专门名称。
详细读图与补图方法见活动图:知识讲解与软件设计师考点。
状态机图:事件如何改变对象状态¶
状态图也称状态机图,描述 状态、事件、转换与行为,适合表达一个对象在生命周期中如何响应事件。
活动图关注“处理步骤怎样进行”,状态机图关注“对象处于什么状态,什么事件使它进入下一状态”。两者都可能出现初始和终结符号,不能仅凭这些符号判断类型。
转换标注:触发器、守卫条件与效果¶
常见写法:
| 部分 | 含义 |
|---|---|
| 源状态 | 对象当前必须处于的状态 |
| 触发器/事件 | 促使模型考虑该转换的事件,如 turnOn |
| 守卫条件/监护条件 | 允许转换发生的布尔条件,如 [有水] |
| 转换效果 Effect | 取该转换时执行的行为,如“烧水” |
| 目标状态 | 转换后进入的状态 |
有外部转换时,可以按“退出源状态 → 执行转换效果 → 进入目标状态”理解基本顺序。内部转换不退出状态,不能把它与回到自己的外部自转换混淆。
守卫条件为真不等于自动触发转换。 通常还要有匹配的事件被处理、源状态活跃等条件;如果要响应某个布尔表达式从假变真,可以使用变化事件。多个候选转换存在冲突时,还须按状态机的选择规则判断。
原讲义简化说法的适用边界¶
- 初始节点的数量按区域判断。 一个状态机区域至多有一个初始伪状态;复合状态可以包含多个区域,整张图并非只能有一个初始点。
- 终态可以不止一个,也可以没有。 区域到达终态表示该区域完成,不一定意味着整个系统结束。
- 转换不一定恰好有一个显式触发器。 完成转换可以不标触发事件;一条转换也可以定义多个备选触发器,事件匹配其中之一即可触发候选转换。
- 一个事件不限制只能执行一个动作。 转换效果或状态行为可以由多个步骤构成,进入/退出行为也应纳入考虑。
做题优先依据题图标出的源状态、触发器、守卫和区域结构,不把“每个转换只有一个事件、每个事件只有一个动作”当成 UML 的通用限制。
四种常见事件¶
| 事件类型 | 含义 | 例子 |
|---|---|---|
| 信号事件 SignalEvent | 接收到异步信号 | 接收到“设备告警”信号;鼠标事件是否建模为信号取决于具体模型 |
| 调用事件 CallEvent | 接收到调用某项操作的请求 | 请求执行 open() |
| 变化事件 ChangeEvent(材料称变换事件) | 布尔表达式从假变为真 | when(A > 100) |
| 时间事件 TimeEvent | 到达绝对时间或经过相对时长 | after(10s);绝对时刻可使用 at(...) 等对应记法 |
不能把 when(...) 一概归为时间事件;它通常表示变化事件,最终应看所描述的事件语义。
状态内部的行为与信息¶
| 元素 | 含义 |
|---|---|
| 状态名 Name | 标识当前状态 |
entry / ... |
进入状态时执行的行为 |
do / ... |
进入行为完成后开始的状态内活动,可持续一段时间;若退出状态时仍未完成,会被中止 |
exit / ... |
退出状态时执行的行为 |
| 内部转换 Internal transition | 响应事件但不退出当前状态,因此不重新执行 entry/exit |
| 子状态 Substate | 复合状态内部更细的状态结构 |
| 延迟事件 Deferred event | 在当前状态暂不处理、保留到后续合适时机处理的事件 |
原图的 event selfTest/defer 表示在该状态中延迟处理 selfTest;它不等于创建一个定时器并在固定时长后执行。
顺序子状态与并发区域¶
单一区域中的直接子状态通常互斥。 图中先处于 A1,再进入 A2,最后到达终态。
这张图的路径经过 A1、A2,不代表所有复合状态都必须访问内部每个子状态。存在分支、循环和外部退出转换时,要按实际路径分析。
正交复合状态具有多个可以并发推进的区域。 下面的虚线把 A 分为两个区域:上方为 A1 → A2,下方为 A3 → A4。
- 可以同时处于 A1 与 A3、A2 与 A3、A1 与 A4,或 A2 与 A4 等组合。
- 同一区域内的 A1 与 A2 互斥;不能说 A1、A2、A3、A4 四个状态会同时激活。
- 对图示没有额外持续活动的情况,全部区域都到达终态时,复合状态完成;若还定义了
doActivity等行为,也要结合其完成条件。 - 复合状态完成与退出不是同一概念;有相应的外出完成转换时,才能据此判断后续去向。外部事件触发的退出也可能在各区域完成之前发生。
例题 7:什么情况下不一定离开 B¶
如下所示的 UML 状态图中,( )时,不一定会离开状态 B。
| 选项 | 内容 |
|---|---|
| A | 状态 B 中的两个结束状态均达到 |
| B | 在当前状态为 B2 时,事件 e2 发生 |
| C | 事件 e2 发生 |
| D | 事件 e1 发生 |
参考答案与解析
参考答案:C。
e2 对应的是从 B2 指向 C3 的转换。仅仅知道 e2 发生,不能保证上方区域已经处于 B2;如果它还在 B1,该转换就不具备源状态条件,因此不一定离开 B。
- A:两个区域均到达终态后,B 完成,按图中通向 C2 的无显式触发器的完成转换离开 B。
- B:已经处于 B2 且 e2 发生,转换到 B 外的 C3,退出整个 B,而不只是结束上方区域。
- D:e1 标在从 B 边界通往 C1 的转换上,图中没有额外守卫,可在 B 活跃时触发退出。
读图关键是 转换从哪个状态出发,不要只看到相同事件名就忽略源状态。
构件图:组件、接口与依赖¶
构件图也称组件图,描述软件组件及其提供接口、需要接口、连接与依赖。组件是封装内部实现、对外提供契约的模块化单元,不应直接等同于普通的类。
| 符号 | 含义 | 记忆方式 |
|---|---|---|
| 完整小圆/棒棒糖 | 提供接口 Provided interface | 我能提供这个服务 |
| 半圆/插座 | 需要接口 Required interface | 我需要别人提供这个服务 |
| 组件矩形及组件标记 | 封装的组件 | 内部实现通过接口与外部协作 |
| 连接或依赖 | 组件之间的协作要求 | 结合端点、接口名称及箭头理解 |
“半圆需、整圆供”适合识别标准 ball-and-socket 接口记法,但要看标注箭头究竟指向哪个符号,而不是只按左右位置记答案。
例题 8:组件接口的识别¶
下图所示 UML 图为(①),用于展示(②)。图中标号 ① 和 ② 分别表示(③)。
| 选项 | 第①空 | 第②空 | 第③空 |
|---|---|---|---|
| A | 类图 | 一组对象、接口、协作和它们之间的关系 | 供接口和供接口 |
| B | 组件图 | 收发消息的对象的结构组织 | 需接口和需接口 |
| C | 通信图 | 组件之间的组织和依赖 | 供接口和需接口 |
| D | 部署图 | 面向对象系统的物理模型 | 需接口和供接口 |
参考答案与解析
参考答案:B、C、C。
图中是组件及其接口、依赖,选组件图。标号 ① 指向 Customer Repository 一侧的完整小圆,即提供接口;标号 ② 指向 Order System 一侧的半圆,即需要接口。Order System 需要的 CustomerLookup 服务由 Customer Repository 提供。
部署图:软件部署在哪里¶
部署图展示设备、执行环境、制品及其部署关系,回答“软件运行在什么节点上,节点之间如何连接”。它是结构图;描述运行时的配置,并不因此变成行为图。
| 元素 | 含义 |
|---|---|
| 节点 Node | 承载执行的计算资源,可以进一步区分设备与执行环境 |
| 设备 Device | 物理计算资源,例如服务器、手机 |
| 执行环境 ExecutionEnvironment | 为其他软件提供运行服务,例如 JVM、应用服务器 |
| 制品 Artifact | 可部署的信息实体,例如可执行文件、JAR、配置文件 |
| 通信路径 | 节点之间的连接,可以标注协议等信息 |
长方体是节点的常见画法,不只表示物理硬件。UML 2.x 中通常将制品部署到节点,并用制品与组件的关系说明实现;旧教材或简化图可能直接把组件画在节点中。
原材料“一个节点包含一个或多个部署图”应理解为“一个节点可以承载多个部署元素”,不是节点内部再存放若干张图。部署图也可以只展示硬件环境、执行环境或制品部署中的某一层细节。
关键词、读图步骤与易错对照¶
根据题干定位图的用途¶
| 题干关键词 | 优先想到 | 核对点 |
|---|---|---|
| 类、接口、属性、静态结构 | 类图 | 讨论的是类型层面 |
| 某一时刻、实例、对象快照 | 对象图 | 讨论的是具体对象和链接 |
| 外部参与者、系统功能、用户目标 | 用例图 | 描述谁通过系统完成什么 |
| 生命线、消息先后、时间次序 | 顺序图 | 检查生命线与交互结构 |
| 对象组织、连接、消息编号 | 通信图 | 检查对象链接与编号消息 |
| 工作流、动作、控制流、数据流 | 活动图 | 重点是步骤、选择与同步 |
| 状态、事件、转换、守卫 | 状态机图 | 重点是对象状态与事件响应 |
| 组件、供接口、需接口、依赖 | 构件图 | 重点是软件模块的协作契约 |
| 物理节点、执行环境、软件部署 | 部署图 | 重点是软件与运行资源的映射 |
先识别关系,再核对方向¶
| 看到的特征 | 判断 |
|---|---|
| 空心三角 | 再看实线还是虚线:分别常为泛化和实现 |
| 空心菱形、实心菱形 | 分别是聚合、组合;菱形在整体端 |
«include» |
箭头指向被包含用例 |
«extend» |
箭头指向被扩展的基础用例 |
关联端的 1、* 等 |
从对端一个实例出发,数本端允许关联多少实例 |
方括号 [条件] |
常用于守卫条件;还需结合所在图和元素理解 |
| 活动图中的粗线 | 看入边、出边区分分叉与汇合 |
| 组件旁的完整小圆、半圆 | 分别是提供接口、需要接口 |
答题方法¶
- 先确定问题在考 图类型、关系、数量约束,还是执行行为。
- 找最有区分度的线索,结合图形核对;“动态视图”“有起点终点”“出现消息”往往不足以单独确定答案。
- 明确两端是谁、箭头朝哪边、当前处于哪个状态,再判断结果。
- 对“不一致”“不一定”“不包括”等否定问法,主动构造一个反例。例如 e2 在 B1 时发生,就足以说明“不一定离开 B”。
答案速查:1:D;2:A、C、D;3:C、D;4:B;5:C、A、D;6:D、A、B(原选项措辞说明见解析);7:C;8:B、C、C。
关联阅读与资料来源¶
- 面向对象技术课件提要与回顾:本章五篇课件的阅读入口与复习要求。
- UML 建模:UML 学习入口。
- 活动图:知识讲解与软件设计师考点:深入学习节点、控制流、并发同步及补图。
- UML 学习资源与路线:书籍、课程和建模练习。
- 面向对象技术总览:软件设计师第 08 章知识提纲。
- 原始材料:用户提供的希赛软件设计师 UML 讲义(课件 ID:161756)文本与 33 张配图;已与 Web Clipper 提取内容核对。整理日期:2026-09-28。例题参考解析与语言/建模边界说明为本笔记补充,不代表原机构官方答案。
- 语义核对:OMG UML 2.5.1 正式规范。聚合与组合见 §9.5.3,组件见 §11.6.3,事件及状态机见 §13.3、§14.2.3,交互及消息见 §17,用例关系见 §18.1.3,部署见 §19。
































