8 UML

（41）选 A。结构事物是 UML 模型中最静态的部分，包括类、接口、协作、用例、构件、节点——都是“名词性”的建模元素。题干说“类、接口、构件”，三个全在结构事物里。

（42）选 D。注释事物就是依附在元素旁边、用来约束或解释的“便签”，UML 里画成右上角折起的矩形，可以用虚线连到被注释的元素上。

另外两类顺带记住：行为事物是动态部分，只有两种——交互（interaction）和状态机（state machine）；分组事物只有一种——包（package），用来把模型元素组织成组。

B 行为事物最容易误选在（41）：因为“操作”听起来像行为，但题干列的是“类、接口、构件”这些名词，不是操作本身。

C 分组事物在（42）也不对：包是分组的容器，不是贴在元素上的说明。

（41）选 B。依赖的判据是“只在局部用一下”：类 A 只在某个方法内部创建、调用或引用类 B 的对象，A 的属性里没有 B，A 的生命周期也不管 B。这种关系最弱，UML 画成虚线箭头，箭头指向被依赖的 B。

（42）选 D。组合的判据是“同生共死”：B 是 A 的属性，而且 A 消失时 B 必须跟着消失。UML 画成实线 + 实心菱形，菱形在整体这一端（A 侧）。

A 关联错在关系太弱——关联是长期持有的结构关系，不强调销毁联动。C 聚合错在“可以不同生共死”：聚合的整体销毁后，部分还能活着。

这道题是五种关系的“判据模板”：看代码里怎么用（局部还是成员）+ 看生命周期是否绑定，两个问题问完，答案就定了。

（45）选 A。调用“标准数学函数类库”只是使用它提供的能力，类 A 并不持有它的对象、也不负责它的生死 → 依赖。

（46）选 D。A 消失时，它包含的实例也消失 → 生命周期绑定 → 组合。

（47）选 C。A 消失时，被包含的实例仍然存在并继续工作 → 生命周期不绑定 → 聚合。

三个空正好把“依赖—组合—聚合”的边界一次考完，判断顺序建议固定成两步：

第一步：是不是“整体—部分”？不是 → 依赖或关联；是 → 进第二步。

第二步：部分能不能独立存活？不能 → 组合；能 → 聚合。

画法对应：依赖是虚线箭头，组合是实心菱形，聚合是空心菱形。这三个符号在类图题里出现频率最高，看到菱形先问“生死”，基本不会错。

（43）选 B。组合：部分与整体生命周期相同，整体完全支配部分，包括创建和销毁。

（44）选 A。聚合：同样是“拥有”，但部分可以在不同整体之间共享，生命周期也可以不同，甚至可以脱离整体单独存在。

（45）选 D。题干最后一句是关键——“上述两种关系都是（ ）关系的特殊种类”。组合和聚合都是关联的特例，所以填“关联”。

这一问很容易误选“聚合”或“组合”，但题目问的是它们的上位概念：在 UML 的关系体系里，聚合、组合都从关联派生出来，只是增加了“整体—部分”的语义和菱形标记。

四者的层次可以画成一条线：依赖（最弱）→ 关联 → 聚合 → 组合（最强）。关系越往右越强，耦合越紧。

选 D。组合关系表示整体与部分之间的一种关系，而且是最强的那一种：部分不能脱离整体独立存在，整体销毁时部分随之销毁。

A 错：包与其中模型元素的关系是分组，UML 里画成包符号（带标签的文件夹），不是菱形。

B 错：用例之间的关系只有三种——包含、扩展、泛化，没有组合。

C 错：类与其对象是“抽象与实例”的关系，属于实例化，不是组合。类图里根本不画这种关系，对象图才体现它。

这道题的价值在排除法：组合的定义里必须出现“整体—部分”，其余三个选项描述的都是别的维度（分组、用例关系、实例化），一眼可排除。

选 A。泛化（generalization）就是“一般与特殊”的关系：一个类（父类）与它的一个或多个细化类（子类）之间的关系。UML 画成实线 + 空心三角，三角指向父类。

B 关联：描述两个类之间的结构连接（比如“学生选修课程”），没有一般与特殊的含义。

C 聚集（聚合的另一种译法）：整体与部分的关系，画成空心菱形，方向是“整体包含部分”，不是“父类派生特殊类”。

D 组合：更强的一种整体—部分，画成实心菱形。

三者最容易混的是泛化和聚合，因为都涉及“层级”。判别口诀：能说“子类是一种父类”就是泛化，能说“整体由部分组成”就是聚合／组合。比如“汽车是一种交通工具”是泛化，“汽车由发动机组成”是组合。

（40）选 B。题干给的定义是“一种结构关系，描述了一组链，链是对象之间的连接”——这是 UML 对关联的标准表述。关联强调对象之间长期的结构性连接，画成实线，两端可以标多重度和角色名。

（41）选 C。“一种特殊／一般关系，使子元素共享其父元素的结构和行为”——这是泛化的定义，也就是继承关系，画成实线空心三角。

A 依赖：是一种使用关系，一个元素的变化会影响另一个元素，画成虚线箭头，语义上比关联弱。

D 实现：是类与接口之间的关系，类实现接口声明的操作，画成虚线空心三角。

四种关系的画法可按“线型 + 箭头”两两配对记：实线无箭头是关联，实线空心三角是泛化，虚线箭头是依赖，虚线空心三角是实现。这四组符号是 UML 的“字母表”，必须条件反射。

选 B。两个类之间可以有多个关联，只要用不同的角色名区分。

为什么需要多个关联？设想“人”和“公司”：一个人在公司里可能是“员工”，同时也是“股东”，这两种身份是两条不同的关联，各有各的多重度。用角色名（employee、shareholder）标注在各自那一端，就能区分开。

A 错：“不能有多个”与 UML 规范相反。

C 错：“可以有任意多个”少了约束。多个关联必须能被区分，否则模型有歧义——这正是 B 里“由不同角色标识”的作用。

D 错：把多个关联“聚合成一个”，等于丢失语义差别，也不符合规范。

记住这条：关联可以有多条，靠角色名区分，不能靠“合并”来消歧。这也解释了为什么类图里的关联线两端经常写着小字（角色名 + 多重度）。

选 D。题干问“不属于组成关系”，要找出那个部分能独立于整体存在的选项。

组成（组合）的判据是：部分是整体不可分割的构件，整体销毁时部分必须一起销毁。

A 汽车和座位：座位是出厂时就装好的构件，拆下来车就不完整 → 组成。

B 汽车和车窗：同理，车窗是车的组成部分 → 组成。

C 汽车和发动机：发动机是核心部件，整车报废时发动机随之报废 → 组成。

D 汽车和音乐系统：车载音响／播放器是可以选装、可以拆走、可以换到别的车上继续用的设备，不随汽车一起销毁，属于聚合甚至关联，不是组成。

判别窍门：问一句“这个东西能不能拆下来装到别处继续用”。能 → 聚合；不能 → 组合。

选 C。聚合对象的本质是“包含其它对象”：它由若干部件对象组合而成，对外表现为一个整体。

A 错：“只有静态方法”描述的是工具类，与聚合无关。

B 错：“只有基本类型的属性”恰恰相反——聚合对象的特征就是属性里有对象引用，而不是只有 int、double 这类基本类型。

D 错：与 B 同样的毛病，还多加了“实例方法”，仍然没有“包含对象”这个关键点。

这道题考的是“聚合”的本义：aggregate 就是“聚集、集合”。一个聚合对象持有其他对象的引用，通过它们协作完成功能，这也是聚合关系在类图里画成“整体—部分”的原因。

顺带区分：聚合对象的成员可以独立创建和销毁（空心菱形），组合对象的成员必须随整体一起销毁（实心菱形）。

（39）选 D，购物车与商品是聚合。购物车里放着商品，但商品并不属于购物车——同一件商品可以出现在多个用户的购物车里，也可以从购物车移除后继续在售。部分能独立存在、能被共享，正是聚合的特征（空心菱形）。

（40）选 C，网店与商品是组合。商品是网店经营的组成部分，网店关闭（整体销毁）时，属于它的商品记录也随之失效，生命周期绑定（实心菱形）。

A 关联是最容易误选的：它只表示“两者有关系”，不区分整体—部分。B 依赖更弱，只表示“用一下”。

这题的关键是把同一对概念（商品）放在两个不同的整体里比较：购物车对商品是“装”，网店对商品是“有”。“装”可拆卸，“有”不可分割，一个聚合一个组合。

选 C。关联的多重度（multiplicity）指的是一个类的实例能够与另一个类的多少个实例相关联，写在关联线靠近对方的那一端。

比如“学生—课程”的关联，两端都写 `*`，读作“一个学生可以选多门课，一门课可以被多个学生选”。

A 错：说的是“被调用的方法个数”，那是依赖关系里的事，与多重度无关。

B 错：说的是“方法被调用的次数”，属于运行时的调用频次，不是结构上的数量约束。

D 错：说的是“两个类有哪些相同的属性和方法”，那是泛化（继承）的语境。

记忆：多重度只回答一个问题——“1 个对几个”。常见取值有 1、0..1、*、1..*、2..4 等，星号表示“多个（含 0）”。

选 B（图 B）。题干有三个约束，逐个落到图上：

① 一个公司负责多个项目 → Company 1 端、Project * 端。图 A、B、C 都满足，D 把 Company 和 Employees 画成了继承，直接排除。

② 每个项目由一个团队开发 → Project 与 Team 是 1 对 1，图上应标“1—1”。图 B 正是这样画的；图 A 在 Project 和 Team 之间画了两条线（Employee 和 Project 都连到 Team），语义重复。

③ 团队由多名员工组成 → Team 1 端、Employee 1..* 端。图 B 标的是 1..*，符合。

图 C 错在两点：Company 与 Project 之间多了一个向上的箭头（画成了泛化），且把类名写成了复数 Projects／Employees，类名不该用复数。

图 D 错在把“公司由员工组成”画成了继承（空心三角），公司不是一种员工。

读这类题的方法：把题干拆成一句一关系，逐句对照图上的线型和多重度，不要整体“感觉像不像”。

选 A（①）。题干说的是“一些人把动物养为宠物”——注意 Pet 不是一个独立的类，而是 Animal 在“被养”这个关联中扮演的角色。UML 里角色名写在关联线靠近该端的位置。

图① 把 pet 写在 Animal 那一端（角色名），完全符合。

图② 把 pet 写成整条关联的名字（写在线上方），语义变成“这是一种叫 pet 的关系”，而不是“Animal 在这里扮演 pet”——差了一个位置，意思就变了。

图③ 建了一个独立的 Pet 类，错在把角色当成了实体：这样一来“宠物”和“动物”成了两个不相干的类，丢失了“宠物一定是动物”这层约束。

图④ 用了带箭头的导航性并标注 keeps as pet，同时把 Animal 端写成 0..*，语义偏向“人拥有一组被标记为宠物的动物”，但关键是箭头把关联变成了单向导航，与原意不符。

一句话记：角色用“端名”，关系用“线名”，两者位置不同，含义也不同。

选 C（医生和病人）。题干问“需要对两者之间关系创建新类”——也就是哪一对是多对多、且联系自身带属性，必须用关联类来表达。

A 汽车和座位：整体—部分，用组合即可，不需要新类。

B 主人和宠物：一对一或一对多，用关联即可。

C 医生和病人：一名医生看多个病人，一名病人被多个医生看，而且每次诊疗要记录“什么时间、什么诊断”——这条联系本身带有属性，UML 的做法是建一个关联类（比如 Treatment），用虚线连到医生—病人的关联线上。所以需要新类。

D 部门和员工：一对多，把部门号作为外键放进员工即可，不需要新类。

判别标准：多对多 + 联系有属性 → 关联类。这也是数据库里“多对多联系单独建表”的 UML 版本，两章的知识点是通的。

选 B（覆盖／重置）。图中的结构是：Transport 是抽象类（类名斜体），声明了 `+move()`；Car 和 Boat 通过空心三角继承它，并各自实现了 `+move()`。

子类方法名、参数表都与父类完全相同，只是实现不同——这是覆盖（override，也叫重置）。

A 继承：继承是“子类自动拥有父类的属性和方法”这件事本身，而题目问的是“子类里的 move() 对父类 move() 做了什么”，动作是覆盖。

C 重载：重载要求同一个类里同名方法参数表不同。这里是父子两个类、参数也相同，不是重载。

D 聚合：是整体—部分关系，与方法的重新实现毫无关系。

把三个词分清：继承是“拿到”，覆盖是“改写”，重载是“同名不同参”。图中 move() 在父类里是抽象方法，子类必须实现，这正是多态的前提。

（42）选 C。图里有类名、属性和关联线，是标准的类图。

（43）选 A（图①）。题干的关键信息有两条：医生与病人是多对多；同一对医患可能多次治疗，每次要记录日期和时间。

“联系自身带属性”在 UML 里的标准解法是关联类：建一个 Treatment 类，用虚线连到 Doctor—Patient 的关联线上。图① 正是这样画的，并且标了 `{non-unique}`——明确告诉读者“同一对医患可以有多条治疗记录，不做唯一约束”。

图② 把 Treatment 画成独立实体，两边都用 1—* 连接，丢掉了“医生—病人”这条多对多关系本身。

图③ 与图① 结构相似，但缺少 `{non-unique}` 约束，且连线方式不严谨。

图④ 把 date／time 直接挂在关联线上，没有建关联类，属性无处安放。

关联类的三个特征记住：多对多、联系有属性、用虚线连到关联线。

（41）选 A。Shop 和 Magazine 之间是一条实线，标注了关联名 sells，Magazine 端多重度为 *，没有菱形也没有箭头 → 关联。它表达“一个商店销售多种杂志”，是两个独立对象之间的结构连接。

（42）选 C。Magazine 和 Page 之间，Magazine 端是实心菱形，Page 端是 * → 组合。含义是“杂志由页面组成，杂志销毁时页面随之销毁”，页面不能脱离杂志单独存在。

（43）选 D。类图不用于对对象快照建模——那是对象图的职责。类图建模的是系统的词汇（A）、简单的协作（B）、逻辑数据库模式（C），这三项都是类图的典型用途。

这道题把“关联 vs 组合”和“类图 vs 对象图”两组易混点放在一起。判别组合只看一个符号：实心菱形在谁那一端，谁就是整体。

（42）选 B。图中有类名 A、B，有属性分区，有关联线和多重度，还有自关联，是类图。

（43）选 A（不正确的叙述）。图中 A 端是实心菱形，说明 A 是整体、B 是部分，组合关系。组合的销毁方向是整体 → 部分：A 销毁时 B 跟着销毁。选项 A 说“B 的一个实例被删除，所有包含 A 的实例都被删除”，把方向说反了，所以不正确。

B 正确：B 端多重度是 *，一个 A 可以关联多个 B，当然也可以只关联一个。

C 正确：A 端标的是 1，从 B 看过去，每个 B 只属于一个 A。

D 正确：B 上有一条自关联（1 对 n，角色名 v），所以一个 B 可以关联另外的 B。

这题提醒一句：组合的“同生共死”是单向的——整体死则部分死，部分死不影响整体。

选 D。图里有四个关键信息：A 标了 `{abstract}`（抽象类）；B1 与 A 关联（B1 端 *、A 端 2..4）；A 有一条自关联（* 到 *）；A1、A2 继承 A；A2 与 C1 关联（* 到 *）。

D 错在“A 的直接对象”——抽象类不能被实例化，根本不存在“A 的直接对象”。所以“有可能 A 的直接对象与 B1 的对象关联”这句话从前提上就不成立。

A 正确：A1 和 A2 都是 A 的子类，A 有自关联，所以 A1 的对象可以关联 A2 的对象。

B 正确：“A 的非直接对象”就是子类 A1／A2 的对象，它们与 A1 的对象之间同样可以走 A 的自关联。

C 正确：B1 关联 A，A2 是 A 的子类（可替代父类），A2 又关联 C1，所以 B1 可以经由 A2 到达 C1。

这题的核心考点只有一个：抽象类没有实例，但它的子类实例可以出现在父类出现的任何地方（里氏替换）。抓住这一点，D 立刻出局。

（42）选 C。对象图的定义是“某一时刻一组对象以及它们之间的关系”——注意两个限定词：某一时刻（快照）、对象（不是类）。

A 错：那是类图的定义（一组对象、接口、协作和它们之间的关系）。B 错：那是用例图。D 错：那是序列图（以时间顺序组织的交互）。

（43）选 D。类图是 A（1）—（*）B：一个 A 可以关联多个 B，但一个 B 只能属于一个 A。四个对象图里，只有 D 违反了这个约束——它画的是 a1:A 和 a2:A 同时关联到同一个 b1:B，等于一个 B 对应了两个 A。

A（a1 关联 b1、b2）、B（a1—b2、a2—b1）、C（a1—b1）都符合类图。

读对象图的顺序：先看每个对象属于哪个类，再数每个对象连着几条线，最后拿多重度去卡。多重度是“从对方看过来”的数量，方向别搞反。

（40）选 A。（Ⅰ）指向左侧的小人符号，那是参与者（Actor）——代表与系统交互的人、硬件或其他系统所扮演的角色。

（41）选 C。（Ⅱ）指向 Capture Deal 与 Limits Exceeded 之间的箭头，箭头是空心三角，从子用例指向父用例，这是泛化关系。含义是“Limits Exceeded 是一种特殊的 Capture Deal”。

（42）选 B。（Ⅲ）指向椭圆，椭圆是用例的符号，代表系统提供的一个功能单元。

D 包含关系（`<<include>>`）在图里也出现了——Analyze Risk 和 Price Deal 都有虚线箭头指向 Valuation，标着 include，表示“执行前者时一定会执行后者”。

四种元素的符号要形成条件反射：小人是参与者，椭圆是用例，空心三角是泛化，带 <<include>> 的虚线是包含。

选 A。参与者（Actor）表示人、硬件或其他系统在系统中扮演的角色——注意是“角色”，不是具体的人。

A 正确，这正是 UML 对参与者的定义。

B 错：“可以完成多种动作的相同用户”——一个参与者可以对应多个具体用户，但“能不能完成多种动作”不是参与者的判据。

C 错：“不管角色的实际物理用户”表述含混。参与者是角色抽象，但它必须能被识别为某一类外部交互者，不是“什么都不管”。

D 错：“带接口的物理系统或者硬件设计”——这是把参与者和构件／节点混为一谈。

记住参与者的三个来源：人（顾客、管理员）、外部硬件（传感器）、外部系统（支付网关）。同一个具体人可以扮演多个参与者，同一个参与者也可以由多个具体人扮演。

（39）选 C（evaluation）。序列图里消息分三种箭线：

同步消息：实线 + 实心三角箭头，表示调用并等待返回。

异步消息：实线 + 开放箭头，表示发出后不等待。

返回消息：虚线 + 开放箭头，表示把结果返回给调用者。

图中只有 evaluation 那条是虚线，所以它是返回消息。

（40）选 B（xfer()、plus() 和 minus()）。判断依据是“Account 类收到了哪些消息”——收到的消息，接收方就必须有对应的方法。

图里 a1:Account 收到 xfer(m:Money, a2)，所以要有 xfer()；a1 自己调用 minus(m)（自消息），所以要有 minus()；a2:Account 收到 plus(m)，所以也要有 plus()。

check() 是发给 john:Person 的，由 Person 实现，不算 Account 的；evaluation 是返回消息，不对应方法。

一条口诀：箭头指向谁，谁就要有这个方法；虚线返回不算。

（42）选 B（balance）。图中 3:balance 是虚线箭头，从 src:Account 指回 FundsTransactionManager，是返回消息。其余 1、2、4、5 都是实线实心箭头，属于同步调用。

（43）选 D（checkBalance()、withdraw() 和 deposit()）。看 Account 这类对象收到了哪些消息：

2:checkBalance(transID) 发给 src:Account → 需要 checkBalance()。

4:withdraw(transID) 发给 src:Account → 需要 withdraw()。

5:deposit(transID) 发给 tgt:Account → 需要 deposit()。

1:start(transID) 是外部发给 FundsTransactionManager 的，不属于 Account；3:balance 是返回消息，不需要方法。

和真题 24 是同一套判断法：先挑出指向 Account 生命线的实线箭头，再去掉虚线返回。两道题连着做，这个套路就固化了。

（42）选 C。图中有若干条竖直的生命线、激活条（细长矩形）、以及按从上到下顺序排列的横向消息箭头，这是序列图（顺序图／时序图）。

A 用例图没有生命线和消息；B 活动图是流程节点和判断菱形；D 交互图是父类概念，序列图和通信图都属于交互图，但在具体图上应选更精确的“序列图”。

（43）选 B。序列图描述的是一个用例的执行过程中，多个对象如何通过消息协作完成这个用例——图里能看到 Student、StudentInfoPage、TranscriptBuilder、Student、Seminar、Printer 六个对象参与同一次“打印成绩单”。

A 错：“一个用例和一个对象”太少，序列图的本质就是多对象协作。C、D 错在“多个用例”——一张序列图通常只对应一个用例场景，多个用例应该画多张图。

顺带认一下图里的细节：`loop [for each seminar]` 是循环组合片段，`<<system>>` 是构造型。

（41）选 C。图里没有生命线，对象用矩形框表示（框里写 `:Order`、`b:Book`），对象之间用实线连接，消息写成带序号的箭头（1*、1.1、1.2、2.1……）——这是通信图（旧称协作图）的典型特征。

（42）选 B。`[:Order]` 和 `[b:Book]` 这种“对象名:类名”的写法（对象名可省略，冒号不能省）表示对象，即某个类的实例。

（43）选 D。`1*:find_books()` 和 `1.1:search()` 是带序号的消息，序号表示调用层次（1 是第一条，1.1 是 1 内部调用的第一条），所以它们表示消息。

通信图和序列图的关系要理清：两者都描述对象交互，序列图靠上下位置表示时间，通信图靠序号表示顺序。通信图独有的两个元素就是“链（对象之间的连线）”和“消息序号”。

（41）选 C。图中对象是矩形框（UI、:Mapping、:BD map、:JourneyCalculations、:GPS location、:Destination details），消息带层次序号（1、1.1、2、2.1、3、3.1、3.2）→ 通信图。

（42）选 A。通信图展示的是对象之间的消息流及其顺序。B 是活动图的职责（活动流），C 是状态图的职责（状态转换），D 是序列图强调的重点（时间顺序）。

（43）选 D（2.1:getCarLocation()）。题干问“Mapping 对象获取汽车当前位置的消息”，就到图里找从 :Mapping 出发、名字与“位置”相关的那条——`2.1:getCarLocation()` 从 Mapping 指向 :GPS location，正是它。

A `1:getGraphic()` 是 Mapping 返回给 UI 的图形数据；B `2:getCarPos()` 是 UI 向 Mapping 发起的请求；C `1.1:CurrentArea()` 是去取当前区域。三条都不是“获取位置”。

读通信图的顺序：先找起点对象，再顺着序号找它发出的消息，序号的小数点表示调用深度。

（41）选 C（不正确的叙述）。状态图描述的是单个对象在生命周期中的状态变化，不是多个对象之间的交互——描述多个对象交互的是交互图（序列图／通信图）。所以 C 错。

A 正确：状态图可以描述一个对象在多个用例中的行为。

B 正确：状态图适用于“具有多个状态、行为受事件影响”的对象，不是系统里所有对象都值得画状态图。

D 正确：用户界面、控制对象这类“反应型对象”正是状态图的典型应用。

（42）选 D。图中外面的大圆角框标着 ON，里面包含 Idle、Playing、Rewinding 三个子状态——这是超状态（组合状态），ON 是它的名字。

A 错：ON 内部没有并发分区（没有用虚线隔开的两条并行区域），所以不是并发状态。B 错：状态图不要求必须有终止状态，没有终态不代表无效。C 错：play、stop、rew 标在箭头上，是事件（触发转换），不是动作。

选 C（事件 e2 发生）。题干问“不一定会离开状态 B”，关键是找出那个“要看当前处在哪个子状态”的选项。

图的结构：B 是超状态，内部有两条并发分区——上区 B1→B2（B2 是终态），下区 B3→B4（B4 是终态）。B2 有一条出口 e2 通向 C3；B 本身有出口 e1 通向 C1；两个分区都完成后还有一条出口通向 C2。

A：两个结束状态均达到 → B 内部活动全部完成 → 离开 B 到 C2，一定会离开。

B：当前在 B2，事件 e2 发生 → e2 的源状态就是 B2，直接触发离开 B，一定会离开。

C：只笼统说“事件 e2 发生”，没说当前在哪个子状态。如果此刻在 B1、B3 或 B4，e2 根本不是当前状态上的事件，不会触发任何转换，对象仍留在 B 内。所以“不一定”离开。

D：事件 e1 的源是超状态 B 本身，只要在 B 内任何子状态，e1 都能触发离开，一定会离开。

这题考的是事件的作用域：事件只在它的源状态上生效，跨状态不响应。

选 C（不正确的叙述）。“一个转换可以有事件触发器、监护条件和一个状态”——这句话把转换的组成部分说错了。

UML 里转换（transition）的标准组成是四部分：源状态、事件触发器、监护条件、动作（效果）、目标状态。注意最后是“目标状态”，不是“一个状态”；转换连接的是两个状态，说“一个状态”既不准确也不完整。

A 正确：活动（动作）既可以在状态内部执行（entry／do／exit），也可以在转换时执行。

B 正确：监护条件只有在相应事件发生时才会被求值，事件不发生就谈不上检查条件。

D 正确：事件触发转换，这是转换的定义。

记忆：转换 = “从哪来 + 什么事件 + 什么条件 + 做什么 + 到哪去”。五个要素里，“状态”出现了两次（源和目标），所以选项里笼统说“一个状态”一定是错的。

选 C（不正确的叙述）。和真题 31 是同一个考点、同一年份的另一场：转换的组成里不能只有“一个状态”。

C 说“迁移可以包含事件触发器，监护条件和状态”——迁移（转换）连接的是源状态和目标状态两个状态，说“包含一个状态”表述错误，规范的说法是“迁移由源状态、事件、监护条件、动作和目标状态构成”。

A 正确：活动可以在状态内执行（do 活动），也可以在迁移时执行（迁移上的动作）。

B 正确：若事件触发一个没有监护条件的迁移，条件默认为真，对象离开当前状态。

D 正确：事件触发迁移。

顺带记住“迁移不一定离开当前状态”这个反例：如果迁移的目标状态就是源状态自己（自迁移），对象执行完动作后仍留在原状态。这也是真题 30 考的那个点。

（41）选 B。状态图用于对系统、类或用例的动态方面建模时，通常针对的是反应型对象——即行为表现为“等待事件 → 响应事件”的对象，比如控制器、界面、通信协议实体。A 系统的词汇是类图的职责，C 活动流程是活动图的职责，D 对象快照是对象图的职责。

（42）选 B。图的结构是：超状态 C 内部依次有 A、B 两个状态，A 的 do 是 count、exit 是 l++，B 有 entry/a=0、do/print、exit/a++，C 有一条出口 `when b=0 [a>5]` 通向 D。

要从 C 转到 D，必须先把 C 内部的活干完——A 和 B 的所有动作（包括 A 的 exit、B 的 entry／do／exit）都执行完，才能离开超状态。所以选 B。

A、C 都只等到 A 完成就离开，太早——B 还没执行。D 只等 B 的 exit，同样不完整：A 的动作也要先完成。

（43）选 D（不正确的叙述）。“状态由事件触发”这句话把主客体搞反了：被事件触发的是转换（迁移），不是状态。状态是对象在生命周期中满足某条件、执行某活动或等待某事件的阶段，它不由事件“触发”。

A 正确：动作既可在状态内执行，也可在转换时执行。B 正确：事件发生且无监护条件时，对象离开当前状态、do 活动终止。C 正确：`when(b=5)` 是时间事件（到达某个时刻自动触发）。

（41）选 B。图里 Logging in 有一条 `Valid Entry [tries<3]` 的出口通向 Logged in。事件 Valid Entry 发生时，先检查监护条件 `[tries<3]`：为真才转移，为假则留在原状态。所以“若 [tries<3] 为 true，则 Logging in 变为下一个活动状态”，选 B。

A 错：条件成立时是要转移的，不会“保持”。C 错：忽略了监护条件，不是“立刻”转移。D 错：`tries=3` 是另一条出口的监护条件（通向 Logging Denied），与 Valid Entry 无关。

（42）选 C，`[tries<3]` 是监护条件——方括号包起来的布尔表达式，转换发生前必须为真。

（43）选 B（转换）。这里要说明一下命题口径：`tries++` 是转换上的动作，严格按 UML 术语它属于转换的“效果（effect）”，但官方给的标准答案是“转换”——理由是“转换包括事件与动作，动作是转换的组成部分”。

考场策略：如果选项里同时出现“转换”和“转换后效果”，要留意命题人想考哪个层次；本题的官方答案就是 B，按 B 记，同时知道它在规范里叫效果即可。

选 B（a22、a33 和 a44）。判断“能否同时执行”只看一个符号：分叉（粗黑线）。从同一条分叉出来的多个分支是并发的，可以同时跑。

图中 a11 之后有一个分叉，伸出三条线：a22、a33、a44——这三条是并发分支，可以同时执行。

A（a44 和 a66）：a66 在 a44 之后的条件分支里，中间隔了汇合和判断，不是同一层的并发。

C（a11 和 a77）：a11 在最前面，a77 在最后，是先后关系。

D（a66 和 a77）：两者分别位于 `[x>5]` 和 `[x<=5]` 两条互斥的条件分支上，同一时刻只能走一条，不可能同时执行。

顺带记住另一组并发：`[x>5]` 之后还有一个分叉，a55 和 a66 也是并发的，只是选项里没给这个组合。

区分两个符号：菱形是分支（选一条走），粗黑线是分叉（全都走）。

选 C（2）。活动图的并发线程数，就是分叉之后同时存活的最长路径数。

顺着图走一遍：A1 → 判断 `[C1]`／`[C2]`。走 `[C1]` 是单线的 A2；走 `[C2]` 进入分叉，分成两条：一条 A3 → A5，另一条 A4。

这两条分支并行推进：一条要跑 2 个活动（A3、A5），另一条跑 1 个（A4）。所以在 A3、A5 执行期间，两条线程同时存在——最大并发线程数 = 2。

A（4）、B（3）都是把分支上的活动数当成了线程数：A3、A4、A5 三个活动确实都在，但同时存活的只有两条路径。

D（1）错在忽略了分叉——如果全是顺序执行才是 1。

窍门：给每条路径标长度，取最长的那个长度（这里 2），而不是把活动总数加起来。

选 D（活动图）。题干的关键词是“业务处理流程”——流程、步骤、先后、分支、并发，这些正是活动图的建模对象。

活动图本质上是“特殊的状态图”，但它描述的不是单个对象的状态，而是一个过程从开始到结束的活动序列，特别适合对用例内部的业务逻辑做进一步细化。

A 状态图：描述单个对象的状态变化，不适合表达“流程步骤”。B 顺序图：描述对象之间按时间传消息，关注交互而不是业务流程的分支与并发。C 类图：静态结构，与流程无关。

判断“该用什么图”的口诀：问“是什么”用类图，问“谁用”用例图，问“怎么交互”序列图／通信图，问“怎么流转”活动图，问“状态怎么变”状态图。

（41）选 D。图里有圆角矩形（活动）、粗黑线（分叉／汇合）、菱形（判断）、开始与结束节点——这是活动图。

（42）选 A。（Ⅰ）指向 a11 之后的粗黑线：一条流进、多条流出，把流程拆成并发的几条，这是分叉（fork）。选项里叫“合并分叉”。

（43）选 B。（Ⅱ）指向 `[not complete]`——方括号里的布尔表达式，控制流程走哪条分支，这叫监护表达式（分支条件／监护条件）。

容易混的是同样标方括号的“流名称”，但流名称一般不带判断语义；而 `[not complete]` 明显是在判断“订单是否完成”，属于条件。

活动图四类节点记牢：菱形 = 分支／合并，粗黑线 = 分叉／汇合，圆角矩形 = 活动，方括号 = 条件。看到粗黑线就想“并发”，看到菱形就想“二选一”。

（46）选 A。图里每个元素都带 `<<component>>` 构造型、右上角有构件图标，元素之间通过接口（棒棒糖）连接——这是组件图。

（47）选 B。看图的方向：CreditCardServices 和 Logger 各自连着一个圆圈（供接口），说明是它们提供 IdentityVerifier 和 TransactionLogger 接口；AccountManagement 从上方连到这两个接口，说明它是使用方。

所以 AccountManagement 需要“调用 CreditCardServices 实现的 IdentityVerifier 接口”，选 B。

A 错：说 AccountManagement 去“实现”接口并被别人调用，方向反了——它是调用方，不是提供方。

C 错：把提供方换成了 Logger，而 Logger 提供的是 TransactionLogger 接口，不是 IdentityVerifier。

D 错：既把提供方弄错，又把动作说成“调用 Logger 实现的 IdentityVerifier”，两处都不对。

读组件图的口诀：棒棒糖在谁身上，谁就是提供方；线连到棒棒糖的那一方，就是使用方。

选 C（组件图）。图里有四个带构件图标的元素——BookingsDll、ServicesDll、GUILib、Main.exe，它们之间用虚线箭头连接，表示依赖（谁调用谁）。这是典型的组件图，用来描述程序构件之间的组织与依赖关系。

A 类图：元素是类，有属性和操作分区，关系用实线／菱形／三角，不会画成“xxx.dll／xxx.exe”这种部署单元。

B 部署图：画的是节点（服务器、设备）和其上部署的构件，节点用立体方块表示。本图没有节点，只有构件。

D 网络图：不是 UML 的标准图种。

顺带读一下依赖链：Main.exe 依赖 BookingsDll、GUILib、ServicesDll；BookingsDll 又依赖 ServicesDll。这表示主程序调用三个库，其中 BookingsDll 内部还要用 ServicesDll。

记：组件图看“构件 + 接口 + 依赖”，部署图看“节点 + 部署”。

（41）选 B。图中有 `<<component>>` 风格的组件框（Order System、Customer Repository、Inventory System），以及供接口（完整圆）和需接口（半圆插座）、虚线依赖，这是组件图。

（42）选 C。组件图展示的是组件之间的组织和依赖。A 是类图，B 是通信图（收发消息的对象结构组织），D 是部署图（物理模型）。

（43）选 C。①指向 Customer Repository 一侧的完整圆——按 UML 规范，完整圆是供接口（provided interface），表示该组件对外提供的能力；②指向 Order System 一侧的半圆插座——这是需接口（required interface），表示该组件需要外部提供的能力。

所以①和②分别是“供接口和需接口”。

注意这道题的图在教材上曾有标记争议，但官方答案是 C。记牢规范：完整圆＝供（我给别人的），半圆＝需（我要别人的）。

顺带看下半部分：Inventory System 提供 ProductAccessor，Order System 通过插座使用它，是同一套画法。

选 D（实施）。部署图描述的是系统物理层面的部署结构——哪些软件构件装在哪台机器、节点之间怎么连接，这些内容只有在系统要交付、要上线时才需要确定，所以属于实施（部署）阶段。

A 需求分析：只关心“做什么”，不涉及物理部署。B 架构设计：会考虑分层和技术选型，但通常不到“哪台服务器装什么”的粒度。C 实现：关注编码，部署图不是代码产物。

这道题的判断依据是“部署图的用途”：它对应 UML 的部署视图，属于物理视图，是实施阶段的产物。

顺带对比：组件图对应实现视图（开发阶段用），部署图对应部署视图（实施阶段用）。两者一个管“软件怎么分块”，一个管“软件装在哪”。

选 B（部署图）。题干的关键词是“软件组件和硬件之间的物理关系”——只要题干把“软件”和“硬件”并列，答案就是部署图。

部署图的职责就是描述物理层面的部署结构：有哪些节点（服务器、终端、设备）、每个节点上部署了哪些构件、节点之间怎么连接通信。

A 组件图：只画软件构件之间的组织和依赖，不涉及硬件。

C 类图：静态逻辑结构，与物理部署无关。

D 网络图：不是 UML 的标准图种，是网络拓扑的概念。

区分组件图和部署图的一句话：组件图里全是软件，部署图里既有软件也有硬件（节点）。看到立体方块（节点）就是部署图。

选 D（部署）。题干说“展示所交付系统中软件和硬件之间的物理关系”，四个选项都是图的种类，只有“部署”图是这个职责。

A 类图：描述类与类的静态结构。B 组件图：描述软件构件的组织与依赖，不涉及硬件。C 通信图：描述对象之间的消息交互，属于动态行为。

这题和真题 43 是同一句话的两次考查（2012 下、2019 上），连措辞都几乎一样。看到“软件和硬件”+“物理关系”，直接选部署图，不用犹豫。

顺带记部署图的三个特征：节点用立体方块、构件部署在节点上、通常在实施阶段使用。

（39）选 A、（40）选 B、（41）选 D。这道题考的是 UML 的设计视图由哪些图组成。

设计视图包含类、接口和协作，可以分两个方面看：

静态方面：类图（39）表现类的结构与关系，对象图（40）表现某一时刻的对象快照。两者一静一动，但都属于“静态结构”的范畴——对象图只是类图的实例化快照，不描述行为。

动态方面：交互图（序列图、通信图）、状态图和活动图（41）。状态图管单个对象的状态变化，活动图管流程，交互图管对象间消息。

C（39 选活动图）、D（39 选序列图）都错在把动态图当成了静态表现。C（40 选通信图）、D（40 选定时图）同理，都是动态图。

（41）的 A、B、C 都含类图或对象图，属于静态，只有 D（状态图和活动图）两张都是动态图。

记这张表：静态 = 类图 + 对象图；动态 = 交互图 + 状态图 + 活动图。

选 B（对象图）。题干已经给出了交互图的定义——“显示一个交互，由一组对象及其之间的关系组成，包含它们之间可能传递的消息”——然后问哪个不是交互图。

UML 的交互图有四种：序列图（顺序图／时序图）、通信图（协作图）、定时图、交互概览图。它们的共同点是都描述对象之间传消息。

对象图不在其中：它只画某一时刻有哪些对象、对象之间有什么链接、各属性的当前值，不描述消息传递，所以不是交互图。它属于结构图（静态图）。

A 序列图、C 通信图、D 时序图（序列图的别名）都是交互图。

这道题的陷阱在“时序图”这个别名——它和“序列图”是同一个东西，看到它别以为是另一种图。

（42）选 C（用例图）。题干说“对新开发系统的需求进行建模，规划开发什么功能或测试用例”——这是用例图的标准用途：从使用者视角描述系统提供哪些功能。

A 类图管结构，B 对象图管快照，D 交互图管对象间的消息，都不解决“需求与功能”的问题。

（43）选 B（部署图）。题干说“展示交付系统的软件组件和硬件之间的关系”——又是那句话，答案还是部署图。

A 类图、C 组件图都只涉及软件，D 网络图不是 UML 图种。

这两空一前一后，正好覆盖 UML 的两端：最前面的需求（用例图）和最末端的交付（部署图）。记这条线：用例图 → 类图 → 序列图 → 组件图 → 部署图，正好是开发流程的顺序。

（46）选 D（组织支持的业务过程）。业务用例和参与者一起描述的是“这个组织对外提供哪些业务价值、由谁发起”，也就是组织所支持的业务过程。

A、B 错在“静态元素／动态元素”——业务用例不是按静态动态划分的。C 错在“逻辑视图”——逻辑视图是设计阶段的概念，不是业务用例的描述对象。

（47）选 C（业务结构以及结构元素如何完成业务用例）。业务对象模型描述两件事：业务的结构（有哪些业务实体、它们之间的关系）+ 这些结构元素如何协作完成业务用例。

A 只说结构，漏了“怎么完成用例”。B 只说完成方式，漏了结构。D 与（46）的答案重复，是典型的干扰项。

这组概念的关系：业务用例 = 做什么；业务对象模型 = 用什么做、怎么做。前者是需求视角，后者是实现视角。

（40）选 A。异步消息与同步消息的根本区别：同步消息发出后，发送者要等待返回才能继续；异步消息发出后不等待，发送者立刻继续执行。所以“异步消息并不引起调用者终止执行而等待控制权的返回”，选 A。

B 错：异步消息正好不是阻塞调用。C 错：异步消息不是“同步消息的响应”，两者是并列的消息类型。D 错：异步消息不等待返回，与同步消息的行为相反。

（41）选 A（1）。图中 1 是实线 + 实心三角箭头，从 LifelineA 指向 LifelineB，是同步消息。

（42）选 C（3）。3 是从 LifelineB 指向 LifelineC 的开放箭头（没有实心三角），表示发出后不等待，是异步消息。

（43）选 B（2）。2 是虚线箭头，从 LifelineB 指回 LifelineA，是返回消息。

三种箭头的对应关系是本章的必背项：实心三角＝同步，开放箭头＝异步，虚线＝返回。

选 D（声明对象类所需要的服务）。UML 里的接口是一组操作的声明，只说明“能做什么”，不给出实现——它声明的是类对外需要提供的服务契约。

A 错：接口不能是“具体类”，具体类是实现接口的一方，两者是对立概念。`<<interface>>` 是构造型标记，标在接口上，不是标在具体类上。

B 错：接口是 UML 的通用概念，与具体语言无关。Java 有 interface，C# 也有 interface，C++ 用纯虚类模拟，说“C# 不支持”是错的。

C 错：“定义可以在多个类中重用的可执行逻辑”描述的是继承（父类里的方法实现被子类复用），接口本身不含可执行逻辑。

一句话记：接口只声明、不实现；类实现接口、提供具体逻辑。画法上，接口可以用带 `<<interface>>` 的方框，也可以用棒棒糖。

选 B（部署组件之间的依赖关系类似于包依赖）。

A 错：部署图里的依赖是单向的——一个节点或构件依赖另一个，不代表反向也依赖。题干把“消息有响应”当成“依赖双向”，是两件事的混淆。

C 错：部署图恰恰用于描述代码的物理模块——它展现的是运行处理节点以及其中构件的配置，属于物理视图。

D 错：部署图的核心用途之一就是描述系统在不同计算机系统上的物理分布，说“不用于”正好反了。

B 正确：部署图中组件之间的依赖，在语义和画法上都与包依赖类似——用虚线箭头表示“一个元素需要另一个元素”，可以带构造型标注。区别只在于部署图的元素是节点与部署其上的构件。

记住部署图的三句话：描述物理分布、展现节点与构件配置、依赖关系类似包依赖。