跳转至

UML 图、关系与读图练习

本篇根据用户提供的软件设计师 UML 讲义整理,覆盖图的分类、关系符号,以及类图、对象图、用例图、顺序图、通信图、活动图、状态机图、构件图和部署图的读法。类图与对象图作为一组讲解,其余按原讲义的八个主题组织。

33 张原配图已保存为本地文件,8 道例题保留题干与选项并统一编号。解释、参考答案和易错辨析为整理时补充;原配图中的简化说法以正文说明为准。

UML 是什么,图如何分类

UML(Unified Modeling Language,统一建模语言)是一套描述系统结构与行为的建模语言,可以用于需求、分析、设计和沟通。它不规定必须采用哪一种开发流程,也不是某一种编程语言。

UML 与面向对象方法及结构图、行为图的概览

原讲义对常见 UML 图用途的分类表

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 类图通常不用于对(③)进行建模。

Shop 关联 Magazine,Magazine 组合 Page 的题图

选项 第①空 第②空 第③空
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 端为 1、B 端为星号的类图约束

第①空选项:

选项 内容
A 一组对象、接口、协作和它们之间的关系
B 一组用例、参与者以及它们之间的关系
C 某一时刻一组对象以及它们之间的关系
D 以时间顺序组织的对象之间的交互活动

第②空的对象图选项:

A:

选项 A:一个 A 实例关联一个 B 实例

B:

选项 B:一个 A 实例关联两个 B 实例

C:

选项 C:两个 A 实例分别关联各自的 B 实例

D:

选项 D:同一个 B 实例关联两个 A 实例

参考答案与解析

对象图展示某一时刻的实例及其关系,所以第①空选 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 是类型继承。 名称相似,不能混为一谈。

用例建模流程

  1. 识别参与者,明确系统边界。
  2. 按参与者目标组织需求,提炼用例。
  3. 细化用例描述,包括前置条件、主要流程、备选流程和结果。
  4. 按需要调整用例模型及关系。

原讲义将前三项列为必须、模型调整列为可选。实际开发可以迭代进行,不必将“合并需求”理解成把多个独立目标强行合成一个大用例。

例题 4:用例和参与者共有的关系

UML 用例图展现了一组用例、参与者以及它们之间的关系。其中,( )关系既可以存在于用例和用例之间,又可以存在于参与者与参与者之间。

A B C D
扩展 泛化 关联 包含
参考答案与解析

参考答案:B。

用例可以有一般与特殊形式,参与者也可以有一般与特殊角色,两者都能使用泛化关系。include 和 extend 则是用例之间的关系。

顺序图:沿生命线读消息顺序

顺序图也称序列图、时序图,是强调 消息先后关系 的交互图。横向通常排列参与交互的对象或角色,纵向沿生命线从上往下展示事件。

ATM、读卡器和 Session 的顺序图

元素 如何读
对象或角色框 谁参与这次交互,例如 :CardReader、:Session
生命线 该参与者在交互中的存在过程;普通垂直虚线不表示消息
执行规格(常称激活条) 该参与者执行某个行为的期间
消息箭头 从发送方指向接收方,名称说明请求或信号
返回消息 通常用虚线箭头,可标注结果,也可省略
创建与销毁 创建消息到达新生命线起点;销毁通常以叉号表示
alt、opt、loop 等组合片段 表达选择、可选和循环等交互结构

顺序图不要求必须标有 1、2、3…;沿生命线的事件先后关系比数字编号更重要。不同生命线之间没有因果联系的事件,也不应仅凭画面高度推断绝对先后。

消息的接收者决定方法属于谁

Session 向 CardReader 发送 readCard 消息

readCard 消息对应的类和方法伪代码

箭头从 Session 指向 CardReader,消息为 readCard(),说明 Session 发起请求,CardReader 提供被调用操作。调用者需要能获得接收者,例如通过字段、参数或其他查询方式。

下面是这条消息的最小 Java 演示,可保存为 ReadCardDemo.java。它只展示对象协作,不覆盖整张 ATM 图的所有流程。

public class ReadCardDemo {
    static class CardReader {
        String readCard() {
            return "card-001";
        }
    }

    static class Session {
        String read(CardReader reader) {
            return reader.readCard();
        }
    }

    public static void main(String[] args) {
        System.out.println(new Session().read(new CardReader()));
    }
}

“有括号就是方法、没括号就是返回值”只能作为这张示例图的辅助线索。识别消息要结合 箭头形状、线型、方向与标注:同步调用通常用实心箭头,异步消息用开放箭头,返回通常用虚线;返回消息也可能带操作签名,括号不是通用判据。创建消息同样可以使用虚线,因此还需看箭头是否到达新生命线的起点,不能把所有虚线都读成返回。

通信图:先看对象连接,再读消息编号

通信图也是交互图,强调 参与交互的对象如何连接和组织。它在链接附近标注消息及编号,以表达调用顺序和嵌套关系。

订单处理对象通过带编号的消息协作

对比 顺序图 通信图
主要关注 沿生命线的消息先后关系 对象连接及消息协作
典型布局 顶部排列参与者,向下展开生命线 对象分布在平面上,以链接相连
顺序表达 主要依靠生命线及消息位置,也可带编号 通常依靠消息编号,如 1、1.1、1.2
推代码时 判断接收者、调用先后、循环和分支 判断对象持有或获得关系,再按编号还原调用

1.1 常表示处理消息 1 过程中发出的嵌套消息。编号格式只是辅助线索,不能仅凭有没有小数点判定图的类型。

例题 5:汽车导航系统的消息

如下所示的图为 UML 的(①),用于展示某汽车导航系统中(②)。Mapping 对象获取汽车当前位置(GPS Location)的消息为(③)。

汽车导航中 UI、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 图是(①),图中(Ⅰ)表示(②),(Ⅱ)表示(③)。

订单活动图中标注 I 的分叉节点与标注 II 的守卫条件

选项 第①空 第②空 第③空
A 序列图 合并分叉 分支条件
B 状态图 分支 监护表达式
C 通信图 合并汇合 动作名
D 活动图 流 流名称
参考答案与解析

参考答案:D、A、B(第②空原选项有措辞问题)。

图展示订单处理的动作和控制流,属于活动图。Ⅰ 是一入两出的粗线,语义为并发分叉 Fork;原材料 A 写作“合并分叉”,这里保留原选项,但正确概念应记为“并发分叉”。下方多入一出的粗线才是并发汇合 Join。

Ⅱ 指向 [not complete],即守卫条件/监护表达式,按题目术语选 B。它在此处确实起到分支条件的作用,因此不能把选项 A 与 B 理解为在所有语境下都完全互斥;本题考查的是图上标注的专门名称。

详细读图与补图方法见活动图:知识讲解与软件设计师考点。

状态机图:事件如何改变对象状态

状态图也称状态机图,描述 状态、事件、转换与行为,适合表达一个对象在生命周期中如何响应事件。

烧水设备的 Off、On 状态及事件触发的转换

活动图关注“处理步骤怎样进行”,状态机图关注“对象处于什么状态,什么事件使它进入下一状态”。两者都可能出现初始和终结符号,不能仅凭这些符号判断类型。

转换标注:触发器、守卫条件与效果

常见写法:

触发事件 [守卫条件] / 转换效果
turnOn [有水] / 烧水

源状态、目标状态、触发事件、监护条件、动作和转换的标注

部分 含义
源状态 对象当前必须处于的状态
触发器/事件 促使模型考虑该转换的事件,如 turnOn
守卫条件/监护条件 允许转换发生的布尔条件,如 [有水]
转换效果 Effect 取该转换时执行的行为,如“烧水”
目标状态 转换后进入的状态

有外部转换时,可以按“退出源状态 → 执行转换效果 → 进入目标状态”理解基本顺序。内部转换不退出状态,不能把它与回到自己的外部自转换混淆。

守卫条件为真不等于自动触发转换。 通常还要有匹配的事件被处理、源状态活跃等条件;如果要响应某个布尔表达式从假变真,可以使用变化事件。多个候选转换存在冲突时,还须按状态机的选择规则判断。

原讲义简化说法的适用边界

  • 初始节点的数量按区域判断。 一个状态机区域至多有一个初始伪状态;复合状态可以包含多个区域,整张图并非只能有一个初始点。
  • 终态可以不止一个,也可以没有。 区域到达终态表示该区域完成,不一定意味着整个系统结束。
  • 转换不一定恰好有一个显式触发器。 完成转换可以不标触发事件;一条转换也可以定义多个备选触发器,事件匹配其中之一即可触发候选转换。
  • 一个事件不限制只能执行一个动作。 转换效果或状态行为可以由多个步骤构成,进入/退出行为也应纳入考虑。

做题优先依据题图标出的源状态、触发器、守卫和区域结构,不把“每个转换只有一个事件、每个事件只有一个动作”当成 UML 的通用限制。

四种常见事件

事件类型 含义 例子
信号事件 SignalEvent 接收到异步信号 接收到“设备告警”信号;鼠标事件是否建模为信号取决于具体模型
调用事件 CallEvent 接收到调用某项操作的请求 请求执行 open()
变化事件 ChangeEvent(材料称变换事件) 布尔表达式从假变为真 when(A > 100)
时间事件 TimeEvent 到达绝对时间或经过相对时长 after(10s);绝对时刻可使用 at(...) 等对应记法

不能把 when(...) 一概归为时间事件;它通常表示变化事件,最终应看所描述的事件语义。

状态内部的行为与信息

Lighting 状态的 entry、do、exit 和延迟事件

元素 含义
状态名 Name 标识当前状态
entry / ... 进入状态时执行的行为
do / ... 进入行为完成后开始的状态内活动,可持续一段时间;若退出状态时仍未完成,会被中止
exit / ... 退出状态时执行的行为
内部转换 Internal transition 响应事件但不退出当前状态,因此不重新执行 entry/exit
子状态 Substate 复合状态内部更细的状态结构
延迟事件 Deferred event 在当前状态暂不处理、保留到后续合适时机处理的事件

原图的 event selfTest/defer 表示在该状态中延迟处理 selfTest;它不等于创建一个定时器并在固定时长后执行。

顺序子状态与并发区域

单一区域中的直接子状态通常互斥。 图中先处于 A1,再进入 A2,最后到达终态。

复合状态 A 的单一区域内依次经过 A1 和 A2

这张图的路径经过 A1、A2,不代表所有复合状态都必须访问内部每个子状态。存在分支、循环和外部退出转换时,要按实际路径分析。

正交复合状态具有多个可以并发推进的区域。 下面的虚线把 A 分为两个区域:上方为 A1 → A2,下方为 A3 → A4。

复合状态 A 的两个并发区域

  • 可以同时处于 A1 与 A3、A2 与 A3、A1 与 A4,或 A2 与 A4 等组合。
  • 同一区域内的 A1 与 A2 互斥;不能说 A1、A2、A3、A4 四个状态会同时激活。
  • 对图示没有额外持续活动的情况,全部区域都到达终态时,复合状态完成;若还定义了 doActivity 等行为,也要结合其完成条件。
  • 复合状态完成与退出不是同一概念;有相应的外出完成转换时,才能据此判断后续去向。外部事件触发的退出也可能在各区域完成之前发生。

例题 7:什么情况下不一定离开 B

如下所示的 UML 状态图中,( )时,不一定会离开状态 B。

B 的两个并发区域及通向 C1、C2、C3 的转换

选项 内容
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 图为(①),用于展示(②)。图中标号 ① 和 ② 分别表示(③)。

Order System 与 Customer Repository 等组件的接口题图

选项 第①空 第②空 第③空
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、* 等 从对端一个实例出发,数本端允许关联多少实例
方括号 [条件] 常用于守卫条件;还需结合所在图和元素理解
活动图中的粗线 看入边、出边区分分叉与汇合
组件旁的完整小圆、半圆 分别是提供接口、需要接口

答题方法

  1. 先确定问题在考 图类型、关系、数量约束,还是执行行为。
  2. 找最有区分度的线索,结合图形核对;“动态视图”“有起点终点”“出现消息”往往不足以单独确定答案。
  3. 明确两端是谁、箭头朝哪边、当前处于哪个状态,再判断结果。
  4. 对“不一致”“不一定”“不包括”等否定问法,主动构造一个反例。例如 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。

关联阅读与资料来源

评论