UML 建模案例：读图步骤与三道完整案例¶
本篇整理“【软件设计】UML建模（案例题）”整章 8 篇课件，保存 20 张教学图片，并完整保留网上商店、自动售货机、图书借阅三道案例的说明、问题和原参考答案。“课件原参考答案”保留来源表述；“补充推导与纠错”是本笔记的核对和说明。 图片中的印刷错误也在邻近文字中指出。
基础概念可结合已有的 UML 图与关系和 UML 状态图阅读，本篇重点练习把题干、图示与填空对应起来。
课程提要列出：类图与对象图、构件图和部署图*、用例图、通信图、顺序图、状态图、活动图。星号保留课件标记；构件图与部署图的概念参见已有 UML 笔记。
一、类图与对象图：先看关系，再填名称¶
本节课件列出的三类填空是：类名／方法名／属性名、多重度、关系。类图描述类型层次和结构；对象图描述某一时刻的实例与连接，不能把对象快照当成类定义。
读上图时，先找空心三角指向的“书籍”，可知“计算机类书籍”和“非计算机类书籍”是子类；再看空心菱形所在的“书籍列表”“借阅记录列表”，可知它们在各自关系中是整体端。多重度读法是：固定这一端的一个对象，到对端看允许关联几个对象。例如书籍—借阅记录关系中，书籍端是 1、借阅记录端是 0..1，表示每条借阅记录对应一本书、每本书在这个模型里至多对应一条借阅记录。这是图给定的约束；不能据此否定现实系统保存多次历史借阅的需求。
| 图中编号 | 正确关系 | 识别与方向 |
|---|---|---|
| a | 关联 | 实线，描述类型之间的结构联系；对象之间的实例连接称为链 |
| b | 依赖 | 虚线箭头，由使用者指向被依赖者 |
| c | 泛化 | 实线、空心三角，由子类指向父类 |
| d | 聚合 | 空心菱形位于整体端，表示共享聚合 |
| e | 组合 | 实心菱形位于整体端，表示组合聚合 |
| f | 实现 | 虚线、空心三角，由实现者指向接口或其他规约 |
补充纠错： 课件正文把 a/b 和 d/f 的名称写错了位置，上表按原图实际图形校正。“整体与部分生命周期相同／不同”只是记忆简化：组合强调部分同一时刻至多属于一个组合整体；整体销毁时，其当时仍归属的组成部分随之销毁。部分可以晚于整体创建，也可以在整体销毁前被移除或转移，不能说两者一定同时创建、同时消亡。共享聚合没有强制规定部分随整体销毁；不能仅凭两对象恰好同时销毁就判成组合。
从业务句子填多重度，再用对象快照核对¶
独立例子：“每个班级恰有一位班主任，每位教师至多担任一个班级的班主任，也可能不担任。”类图可读成：
固定一个班级，到教师端读 1，得到“恰有一位教师”；固定一位教师，到班级端读 0..1，得到“零个或一个班级”。端点旁的数字约束该端对象的数量，要从对端的一个对象来读。 1 与 0..1 的区别是能不能没有，1..* 与 0..* 也一样。题干只说“可以有多个”通常不能据此断言至少一个。
假设快照里教师 t1 同时连着班级 c1、c2，就违反了班级端 0..1；教师 t2 没有连接班级则合法。由类图可以检查快照是否合法，但一张恰好只有一个学生的班级快照，不能反推“班级最多一名学生”。快照展示当前事实，多重度表达所有合法状态的约束。
填类名时还要交叉检查属性和方法：若某空缺类持有多个“预约”对象并接收 addReservation(...)，它可能承担管理职责；不能只因题干多次出现“顾客”就填顾客。类型、多重度、消息接收方应同时自洽，不能各空独立猜词。
二、用例图：参与者、目标与箭头方向¶
参与者是系统外部与系统交互的角色；椭圆是用户目标对应的用例，矩形是系统边界。图中“图书管理员”是参与者，“查询书籍信息”等是用例。参与者与用例的连接不表示一张业务流程图的执行顺序。
包含、扩展与泛化¶
基础用例 ──«include»──→ 被包含用例。图中“学习课程”“课程测试”都指向“检查权限”，表示复用其行为。包含不是“文字上离得近”就成立，也不要求必须有两个调用者；要确认该公共行为确实被纳入基础用例的流程。
扩展用例 ──«extend»──→ 基础用例。图中“充入学习币”指向“课程测试”，不是反过来。基础用例本身应有独立意义；扩展在扩展点、条件满足时插入行为。“如果／若／没有信息”是线索，但还要核对是否为基础功能的条件性扩充，不能把任何 if 都画成扩展。
泛化的空心三角指向一般用例。图中“电话注册”“网上注册”是“课程注册”的特殊形式。包含与扩展用虚线开放箭头，泛化用实线空心三角；课件部分箭头绘制较简略，识别时应同时看构造型文字和业务含义。
课件中的用例规约：购买饮料¶
以下是用例图课件的原规约，也是后面自动售货机案例的依据。
参与者：顾客。
主要事件流：
（1）顾客选择需要购买的饮料和数量，投入硬币；
（2）自动售货机检查顾客是否投入足够的硬币；
（3）自动售货机检查饮料储存仓中所选购的饮料是否足够；
（4）自动售货机推出饮料；
（5）自动售货机返回找零。
备选事件流：
（1）若投入的硬币不足，则给出提示并退回到1；
（2）若所选购的饮料数量不足，则给出提示并退回到1。
三、顺序图与通信图：消息由谁接收¶
顺序图沿生命线从上往下读，重点记录“发送者 → 接收者：消息”。上图 Session 向 CardReader 发送 readCard()，说明 readCard() 是接收方 CardReader 应提供的操作；返回的 card 是结果，不能因为它也是箭头文字就当成另一个方法。
课件伪代码展示了 Session 通过持有或传入的 CardReader 引用调用 CR.readCard()，不应直接当作可编译的完整 Java 程序。
消息机制补充： 常见调用消息画实线；同步调用通常用实心三角箭头，异步消息用开放箭头，回复消息通常用虚线开放箭头。同步调用的发送方等待调用完成，异步发送方不必等待接收方处理完毕。不能只看“实线”就断言同步，也不能把对象间消息一概视为异步；括号不是区分调用与返回的可靠标准。图中的生命线终止叉号表示实例销毁，激活条表示执行期间，两者含义不同。
通信图：对象名与消息¶
通信图课件的两个要点是**对象名、消息**。基础知识参见 UML 图与关系。
上图中 dispatchForm:Form 表示名为 dispatchForm 的 Form 对象，aOrder:Order 表示名为 aOrder 的 Order 对象，:OrderItem、:Product、:DeliverOrder 省略了对象名。按箭头及编号阅读：
1:dispatch()从 Form 发往 Order，因此dispatch是 Order 接收的操作。1.1从 Order 发往 OrderItem，1.1.1再由 OrderItem 发往 Product；小数层级表达嵌套消息，不能把1.1.1读成另一个无关的顶层步骤。*[for each orderItem]标记重复；图中的[... Not Exist]标记条件，既不是对象名，也不是单独的方法名。1.3:create(...)、1.4:Add(ProductId)发往 DeliverOrder，最后1.5:Summary返回 Form。虚线返回消息与实线调用应分开阅读。
本章图书借阅案例也采用同样的方法：箭头方向确定接收者，消息编号确定顺序，不要按对象在页面上的左右位置推断先后。
四、状态图：拆开事件、条件和动作¶
本节重点填**状态名、触发事件、监护条件、动作**。转换标签的一般格式是：
原图 turnOn[有水]/烧水 应分为：事件 turnOn、监护条件 [有水]、转换效果 /烧水。源状态是 Off，目标状态是 On。条件为真并不自动等于触发事件发生；相关事件发生也不保证任意源状态都能转换。
按图，Off 收到 turnOn 且有水才转入 On；无水时沿画出的自转换回到 Off。On 遇到“水开了”执行 turnOff 并转回 Off。黑点表示初始伪状态，靶心形表示终态。图中未带斜线的“烧坏”按转换标签位置理解为触发的简写，不要与状态名混淆。
本章售货机的原参考答案把整个转换标签称为“事件名”，需要按事件、条件、动作分别理解。并发区域、完成转换与事件处理细节参见 UML 状态图。
五、活动图：跟踪分支、汇合和责任¶
本节课件关注**活动名、开始／结束、并发分支／并发汇合、活动发起者**。
上图在“用户下订单”后分叉，一路生成送货单，另一路选择支付方式并收款，随后汇合再送货。菱形处根据条件选择分支；粗线式分叉／汇合表达并发与同步。并发是模型的语义，不保证实现必须使用多个线程。
泳道用来划分职责：客户选择支付方式，系统生成送货单并收款，供应商送货并修改订单项状态。看图时还要顺着“所有订单项已送货完毕”的 Yes／No 分支检查是否回到送货步骤。第二张原图顶部起点画成了空心圆，标准 UML 活动初始节点应画实心圆；保留原图并在这里说明，不把印刷样式当作新符号。
六、案例题的看图顺序与关键词¶
课件建议定期复习常见 UML 图，并在初读题干、图、问题后，先仔细分析图中信息，再返回题干找剩余答案。可以落实为下面的步骤：
- 先看问题要求填类、用例、状态还是消息，以及是否要求使用题干术语、图中英文。
- 标出图中已有名称、方法、关系端点、箭头方向、编号和多重度；先整理确定的信息。
- 将题干的业务名词映射到类／对象，将用户目标映射到用例；将行为前后的情形区分为状态、事件与动作。
- 用图中约束筛选候选项：谁包含谁、谁是一种谁、消息发给谁、转换从哪里出发。
- 把填完的答案代回整张图走一遍，再对照题干检查分支和异常情况。
| 题干或图中线索 | 可以帮助定位什么 | 必须继续核对什么 |
|---|---|---|
| “是一种”、空心三角 | 泛化，找一般类型 | 三角指向父类／一般用例 |
| “由……组成”、菱形 | 整体与部分 | 空心／实心、菱形在哪一端，不能只凭句式认定组合 |
| “如果没有……则添加” | 条件性的扩展行为 | 扩展箭头由新增行为指向基础用例 |
| “从列表中选择” | 已有选择行为和信息实体 | 不要把“选择”与“新增”填到同一空 |
| “收到……且满足……” | 事件与条件 | 源状态是否允许、方括号里是什么、斜线后是什么 |
obj:Class、n:method() |
接收对象及消息顺序 | 方法应属于接收对象的类，大小写按图中词汇 |
关键词用于定位，图中端点、方向、操作签名和业务约束才是填空依据。下面三道题按原课件顺序保留。
七、案例一：网上学术出版物商店 ACShop¶
（一）阅读下列说明和图，回答问题1至问题3，将解答填入对应栏内。
原题说明¶
某出版社拟开发一个在线销售各种学术出版物的网上商店（ACShop），其主要的功能需求描述如下：
（1）ACShop在线销售的学术出版物包括论文、学术报告或讲座资料等。
（2）ACShop的客户分为两种：未注册客户和注册客户。
（3）未注册客户可以浏览或检索出版物，将出版物添加到购物车中。未注册客户进行注册操作之后，成为ACShop注册客户。
（4）注册客户登录之后，可将待购买的出版物添加到购物车中，并进行结账操作。结账操作的具体流程描述如下：
①从预先填写的地址列表中选择一个作为本次交易的收货地址。如果没有地址信息，则可以添加新地址。
②选择付款方式。ACShop支持信用卡付款和银行转账两种方式。注册客户可以从预先填写的信用卡或银行账号中选择一个付款。若没有付款方式信息，则可以添加新付款方式。
③确认提交购物车中待购买的出版物后，ACShop会自动生成与之相对应的订单。
（5）管理员负责维护在线销售的出版物目录，包括添加新出版物或者更新在售出版物信息等操作。
现采用面向对象方法分析并设计该网上商店ACShop，得到如图3-1所示的用例图和图3-2所示的类图。
问题 1（4 分）¶
根据说明中描述，给出图3-1中（1）~（4）所对应的用例名。
问题 2（4 分）¶
根据说明中的描述，分别说明用例“添加新地址”和“添加新付款方式”会在何种情况下由图3-1中的用例（3）和（4）扩展而来？
问题 3（7 分）¶
根据说明中的描述，给出图3-2中（1）~（7）所对应的类名。
参考答案与补充解析
课件原参考答案（保留原表述）
问题 1
（1）添加出版物到购物车 （2）结账
（3）选择收货地址 （4）选择付款方式
问题 2
当选择收货地址时，没有地址信息，则使用扩展用例“添加新地址”来完成新地址的添加。当选择付款方式时，没有付款方式信息，则使用扩展用例“添加新付款方式”来完成新付款方式的添加。
问题 3
（1）出版物目录 （2）待购买的出版物 （3）出版物
（4）~（6）论文、学术报告、讲座资料 （7）订单
补充推导与纠错¶
用例先定“结账”，再沿箭头填子功能。 图 3-1 中（2）由注册客户发起，并包含（1）（3）（4），结合结账流程可定位为“结账”。（3）接收“添加新地址”的 «extend» 箭头，因此是“选择收货地址”；（4）接收“添加新付款方式”的扩展箭头，因此是“选择付款方式”。（1）还与客户和浏览／检索出版物关联，对应“添加出版物到购物车”。
问题 2 的业务条件与箭头方向是两回事。 没有地址时执行添加新地址，没有付款信息时执行添加新付款方式；画图方向均为“添加……”→“选择……”。原问题“由用例（3）和（4）扩展而来”容易使人误画反向箭头；应理解为新增用例对基础选择行为提供条件性扩展。原图部分 include/extend 连线画成实线，标准画法应使用虚线开放箭头。
| 类图空位 | 图中证据 | 对应类 |
|---|---|---|
| （1） | 位于 ACShop 下方，并聚合（3） | 出版物目录 |
| （2） | 位于购物车下方，关联（3），又被（7）聚合 | 待购买的出版物，可按购物项来理解；不是出版物类型本身 |
| （3） | （4）～（6）的空心三角共同指向它 | 出版物 |
| （4）～（6） | 三个同层子类，题干列出三种学术出版物 | 论文、学术报告、讲座资料；图中没有进一步区分位置，可互换 |
| （7） | 关联收货地址与付款方式，聚合（2） | 订单 |
这里不能只把题干中的七个名词按出现顺序塞进七个空。应先用泛化确定（3），再用“购物车—待购买出版物”“订单—地址／付款”两组关系锁定剩余位置。图 3-2 的菱形是空心，按原图是聚合，不能因为业务上“包含”就读成实心组合。
关键词： “确认提交后生成”→订单；“分为论文／报告／讲座资料”→出版物及子类；“没有信息则添加”→扩展条件。
八、案例二：自动售货机¶
（二）阅读下列说明，回答问题1至问题3，将解答填入对应栏内。
原题说明¶
某种出售罐装饮料的自动售货机（Vending Machine）的工作过程描述如下：
（1）顾客选择所需购买的饮料及数量。
（2）顾客从投币口向自动售货机中投入硬币（该自动售货机只接收硬币）。硬币器收集投入的硬币并计算其对应的价值。如果所投入的硬币足够购买所需数量的这种饮料且饮料数量足够，则推出饮料，计算找零，顾客取走饮料和找回的硬币；如果投入的硬币不够或者所选购的饮料数量不足，则提示用户继续投入硬币或重新选择饮料及数量。
（3）一次购买结束之后，将硬币器中的硬币移走（清空硬币器），等待下一次交易。自动售货机还设有一个退币按钮，用于退还顾客所投入的硬币。已经成功购买饮料的钱是不会被退回的。
现采用面向对象方法分析和设计该自动售货机的软件系统，得到如图3-1所示的用例图，其中，用例“购买饮料”的用例规约描述如下。
参与者：顾客。
主要事件流：
（1）顾客选择需要购买的饮料和数量，投入硬币；
（2）自动售货机检查顾客是否投入足够的硬币；
（3）自动售货机检查饮料储存仓中所选购的饮料是否足够；
（4）自动售货机推出饮料；
（5）自动售货机返回找零。
备选事件流：
（1）若投入的硬币不足，则给出提示并退回到1；
（2）若所选购的饮料数量不足，则给出提示并退回到1。
根据用例“购买饮料”得到自动售货机的4个状态：“空闲”状态、“准备服务”状态、“可购买”状态以及“饮料出售”状态，对应的状态图如图3-2所示。
所设计的类图如图3-3所示。
问题 1（6 分）¶
根据说明中的描述，使用说明中的术语，给出图3-2中的S1~S4所对应的状态名。
问题 2（4 分）¶
根据说明中的描述，使用说明中的术语，给出图3-2中的E1~E4所对应的事件名。
问题 3（5 分）¶
根据说明中的描述，使用说明中的术语，给出图3-3中的C1~C5所对应的类名。
参考答案与补充解析
课件原参考答案（保留原表述）
问题 1
S1：空闲，S2：准备服务，S3：饮料出售，S4：可购买。
问题 2
E1：饮料数量不足，E2：选择饮料[硬币数量足够]。
E3：饮料数量足够/推出饮料，E4：取走饮料/返回找零并清空硬币器。
问题 3
C1：自动售货机
C2：硬币器，C4：硬币。
C3：饮料储存仓，C5：饮料。
（C2\C4组合与C3\C5组合可互换位置）
补充推导与纠错¶
状态名按进入条件和后续行为定位¶
| 状态 | 看图证据 | 结论 |
|---|---|---|
| S1 | 初始箭头在清空硬币器后进入它；投入硬币前可以选择饮料 | 空闲 |
| S2 | 从 S1 经“投入硬币／计算硬币价值”进入；金额不足仍在这里补币或重新选择 | 准备服务 |
| S4 | 从 S2 经足额检查进入，但还可能因库存不足退回 S2 | 可购买：此图表示进入库存核验阶段，不代表已出货 |
| S3 | 从 S4 推出饮料后进入；有“计算找零”自转换，最后取货回到 S1 | 饮料出售 |
不要按 S1、S2、S3、S4 的编号套题干列举的状态顺序。图上的执行路径是 S1 → S2 → S4 → S3 → S1，库存不足的分支是 S4 → S2。
E1～E4 是转换上的填空，原答案并非全是纯事件名¶
| 空位与方向 | 原答案要表达的业务含义 | 事件／条件／效果辨析 |
|---|---|---|
| E1：S4 → S2 | 饮料数量不足 | 库存检查结果。“不足”描述条件；若严格建模，需要说明何种事件或完成检查使这条转换被考虑 |
| E2：S2 → S4 | 选择饮料 [硬币数量足够] |
“选择饮料”是触发；方括号是监护条件。这里实际比较的是投入硬币**总价值与所选饮料总价**，不是单纯硬币枚数 |
| E3：S4 → S3 | 饮料数量足够 /推出饮料 |
“足够”是库存条件，“推出饮料”是转换效果；原答案把条件简写成事件，未明确触发 |
| E4：S3 → S1 | 取走饮料 /返回找零并清空硬币器 |
“取走饮料”是事件；返回找零、清空硬币器是转换效果，可以包含多个动作 |
例如可以把库存检查后的两个分支进一步写成“库存检查完成 [库存不足]”和“库存检查完成 [库存足够] /推出饮料”，也可按具体模型用完成转换表示。这是补充的规范化表达，不是课件原答案，不是题目给出的额外事件。 原图初始箭头上的“清空硬币器”同样应理解为初始化效果，规范标注可写 /清空硬币器。
原图与答案没有展开“退币按钮”的状态转移。题干明确成功购买饮料的钱不能退还，不能自行给所有状态添加“全额退款”，也不能声称图已经覆盖该异常路径。
类名按两条整体—部分链配对¶
图 3-3 中 C1 同顾客交互，且拥有两条部件链，因此是自动售货机。两条链为：
自动售货机 → 硬币器 → 硬币：C1 → C2 → C4。自动售货机 → 饮料储存仓 → 饮料：C1 → C3 → C5。
C2/C4 与 C3/C5 可以**整对互换**，不能只换中间部件而不换其对应物品。原答案“C2、C4组合与C3、C5组合可互换”中的“组合”表示两组答案的配对；图中菱形实际为空心，UML 关系是**聚合**，不要误读为组合关系。
关键词： “投入硬币后”→准备服务；“金额足够但还要检查库存”→S4；“推出饮料后计算找零”→S3；“取走并清空”→回到空闲。
九、案例三：图书借阅系统¶
（三）阅读下列说明和图，回答问题1至问题3，将解答填入对应栏内。
原题说明¶
某高校图书馆欲建设一个图书馆管理系统，目前已经完成了需求分析阶段的工作。功能需求均使用用例进行描述，其中用例“借书（Check Out Books）”的详细描述如下。
参与者：读者（Patron）。
典型事件流：
（1）输入读者ID；
（2）确认该读者能够借阅图书，并记录读者ID；
（3）输入所要借阅的图书ID；
（4）根据图书目录中的图书ID确认该书可以借阅，计算归还时间，生成借阅记录；
（5）通知读者图书归还时间。
重复步骤3~5，直到读者结束借阅图书。
备选事件流：
（1）若读者不能借阅图书，说明读者违反了图书馆的借书制度（例如，没有支付借书费用等）
①告知读者不能借阅，并说明拒绝借阅的原因；
②本用例结束。
（2）读者要借阅的书无法外借
①告知读者本书无法借阅；
②回到步骤3。
说明：图书的归还时间与读者的身份有关。如果读者是教师，图书可以借阅一年；如果是学生，则只能借阅3个月。读者ID中包含读者身份信息。
现采用面向对象方法开发该系统，得到如图3-1所示的系统类模型（部分）；以及如图3-2所示的系统操作“CheckOut(bookID)（借书）”通信图（或协作图）。
问题 1（8 分）¶
根据说明中的描述，以及图3-1和图3-2，给出图3-1中C1-C4处所对应的类名（类名使用图3-1和图3-2中给出的英文词汇）。
问题 2（4 分）¶
根据说明中的描述，以及图3-1和图3-2，给出图3-2中M1-M4处所对应的方法名（方法名使用图3-1和图3-2中给出的英文词汇）。
问题 3（3 分）¶
用例“借书”的备选事件流4a中，根据借书制度来判定读者能否借阅图书。若图书馆的借书制度会不断地扩充，并需要根据图书馆的实际运行情况来调整具体使用哪些制度。为满足这一要求，在原有类设计的基础上，可以采用何种设计模式？简要说明原因。
参考答案与补充解析
课件原参考答案（保留原表述）
问题 1
C1：Patron C2：Book
C3：Catalog C4：CheckoutSessionController
问题 2
M1：getForCheckOut M2：isFaculty
M3：circulates M4：recordBookLoan
问题 3
应采用策略模式，策略模式定义了一系列算法，并将每个算法封装起来，而且使它们可以相互替换。策略模式让算法独立于使用它们的客户而变化。适用于需要在不同情况下使用不同的策略（算法），或者策略还可能在未来用其他方式来实现。
补充推导与纠错¶
类模型与通信图要交叉对照¶
图 3-2 已经写出了 sc:CheckoutSessionController、patron:Patron、:Catalog 和 b:Book。冒号前是对象名，冒号后是类名；省略对象名的 :Catalog 仍是 Catalog 的实例。再用图 3-1 的操作确认，而不是猜英文翻译。
| 空位 | 图 3-1 已有操作 | 图 3-2 对应对象 | 答案 |
|---|---|---|---|
| C1 | recordBookLoan(b:C2)、isFaculty() |
patron:Patron |
Patron |
| C2 | circulates()、checkOut(dd:Date)、find(bookID:string) |
b:Book，以及表示一组书的 :Book |
Book |
| C3 | getForCheckOut(id:string) |
:Catalog |
Catalog |
| C4 | checkOut(bookID:string) |
sc:CheckoutSessionController |
CheckoutSessionController |
方法名由箭头的接收方和已有签名确定¶
| 图中消息 | 发送方 → 接收方 | 方法名及理由 |
|---|---|---|
1:M1() |
会话控制器 → :Catalog |
getForCheckOut：由目录取得要借阅的图书 |
2:M2() |
会话控制器 → patron:Patron |
isFaculty：判断是否教师，为归还期限提供依据 |
3:b:=find(bookID) |
:Catalog → 图书集合 |
图中已给出，按图书 ID 查找得到 b，不是需要填写的新方法 |
4:M3() |
:Catalog → b:Book |
circulates：检查该书是否允许外借 |
5:checkOut(dd) |
会话控制器 → b:Book |
图中已给出，带归还日期办理借阅 |
6:M4() |
会话控制器 → patron:Patron |
recordBookLoan：将借阅记录登记到读者 |
M2 和 M4 都发给 Patron，但目的不同：前者询问读者身份，后者登记本次借阅。M3 发给 Book，不能填成读者是否具备借阅资格；“人能不能借”和“这本书能不能外借”是两个判断。题目只填方法名，图上消息省略的参数应以类中签名为准，不据 M1() 的空括号推断操作无参数。
归还期限是教师一年、学生三个月，由 isFaculty() 的结果辅助确定，随后传给 checkOut(dd)。通信图没有给出一个单独的“计算日期”方法名，不应凭业务描述添加为原图答案。
原题编号问题与策略模式的适用边界¶
原问题 3 写“备选事件流 4a”，但当前题干的备选事件流只有（1）、（2），不存在 4a。根据紧随其后的“判定读者能否借阅图书”，它指的是备选事件流（1）及典型事件流（2）中的**读者资格检查**，不是“书不能外借”的分支。这里保留原题文字并说明该编号错误，不编造一个缺失的 4a 步骤。
按原参考答案采用**策略模式**：把可变化的借阅资格判定规则封装在统一接口下，让使用规则的对象通过该接口调用，并可替换具体规则。这样新增、调整制度时，减少对借阅流程的修改。类图中的资格检查入口是 canCheckOut(patronID:string)；原图将所在类拼为 Accouts，本笔记不擅自把它当成题目要求填写的类名。
如果实际需求是**同时应用多条制度**，单一策略并不自动解决组合问题；可以让一个组合策略持有若干规则，并明确“全部通过／任一通过”、优先级和拒绝原因。此处是对模式适用边界的补充，题目给出的模式答案仍是策略模式。
关键词： :Patron／:Book→读者与图书分开；isFaculty→身份与期限；circulates→图书是否外借；“规则不断扩充、可调整使用”→封装可变化策略。
补充解析：题干关键词
| 题干或图中线索 | 可以帮助定位什么 | 必须继续核对什么 |
|---|---|---|
| “一系列规则持续扩充、运行时调整” | 策略模式的可能适用场景 | 是否确实需要封装可变化规则、是否还需要组合多个规则 |
历年大题练习¶
本节按年份由近到远收录 18 道完整历年大题。先展开题干独立作答，再展开其中的答案与解析；平台答案与整理补充继续分别保留。
题目复用题库中的同一份正文，题图使用本地文件。普通 Markdown 阅读器可通过原题链接进入；完整性与剩余试卷见大题整理进度。
2024年下半年 · 第 3 题：智能交通管理系统的 UML 分析与设计¶
展开原题（先作答，再查看解析）
智能交通管理系统的 UML 分析与设计
（三）（15分）
【说明】
某城市计划开发一个智能交通管理系统，实时监控并优化城市的交通流量。该系统的主要功能描述如下：
（1）交通流量监控（TrafficMonitor）。系统将从各种传感器（Sensor）（如路面摄像头、车辆GPS设备、交通信号灯等）收集交通数据。交警根据这些数据进行实时分析，预测交通拥堵，优化交通信号灯（TrafficLightOptimizer）的配时。
（2）公共交通管理（PublicTransportManager)。系统需管理和优化公共交通工具（Public Transport)（如公交车（Bus)、地铁（Subway）等）的调度，公交调度员根据实时路况和乘客需求调整路线和班次。
（3）应急响应管理（EmergencyRespoaseCoordinator)。在发生交通事故或者其他突发事件时，系统需要通知相关应急响应部门并给出最优的应急方案。同时，系统还需重新设计和发布新的交通路线，以避开事故区域。
（4）智能停车管理。系统将帮助驾驶者实时找到附近的停车位，并提供导航服务。还能进行停车费用的自动支付和账单管理。
采用面向对象分析与设计方法开发上述系统，得到如图1所示的用例图以及图2所示的初始类图（部分）。
01（8分）
根据说明中的描述，给出图1中A1A3所对应的参与者名称和U1U5处所对应的用例名称。
02（4分）
根据说明中的描述，给出图2中C1~C4所对应的类名。
03（3分）
在应急响应管理功能中，需要根据事件的严重程度和优先级，按照应急事件的处理流程，逐步将处理任务分配给合适的应急响应单位。请用文字说明哪种设计模式适合于实现该需求并简单说明原因?
答案与解析
平台参考答案（原意保留）
平台参考答案（保留原意）：
- A1 交警；A2 调度员；A3 应急响应部门。U1 收集分析交通数据；U2 预测交通拥堵；U3 优化交通信号灯配时；U4 管理优化公共交通工具；U5 获取通知以及最优应急方案。
- C1
TrafficMonitor；C2Sensor；C3PublicTransportManager；C4PublicTransport。 - 责任链模式。平台解释为级联处理请求，可以灵活组织处理链，直到某一级处理完就停止传递，适应性强。
解析与纠错
解析与纠错：
- A1 与数据分析、拥堵预测、信号灯配时用例相连，符合交警职责；A2 对应公共交通调度员；A3 与应急方案、新路线发布等用例相连，符合应急响应部门。U1 同时与传感器相连，其余用例填法可按平台答案理解。图1未提供进一步区分 U2 与 U3 的条件；“预测交通拥堵”“优化交通信号灯配时”分占二者是平台给出的排列，题干语义和所示连线本身不足以唯一确定二者的上下顺序。
- 图中的
«extend»箭头从扩展用例指向被扩展的基本用例。它表示满足扩展条件时插入行为，不能解释成“先做 U1，之后必做 U2／U3”的顺序流程，也不能据此把所有应急功能都归入公共交通管理。平台解析以业务先后顺序解释扩展关系，表述不严谨；填写用例名称时，还应区分既有关系图的准确语义。 - 根据功能与关联，C1 是交通流量监控，C2 是传感器，C3 是公共交通管理，C4 应是公共交通工具。关联本身不能直接等同于所有权。
- 已核查图2：Bus、SubWay 附近的空心三角箭头实际指向这两个类，而题意要求 Bus、Subway 是 PublicTransport 的子类。按 UML，泛化箭头应指向父类 C4，现有图片方向与题意相反。图中的箭头方向与题意冲突，类名按需求语义填写。
- 图2的空心菱形位于
EmergencyResponseCoordinator一端，表达该端聚合 C1／C3，而非平台解析所说的“C1 聚合应急响应协调器”。题干文字另拼为EmergencyRespoaseCoordinator，图中为EmergencyResponseCoordinator，Subway／SubWay 也有大小写差异；两处资料的拼写并不一致。 - 按严重程度、优先级逐级选择合适响应单位，责任链模式能让各处理者判断是否处理、转交或在处理后继续传递，避免请求发起方绑定某个具体单位。“处理后立即停止”是常见实现，并非模式的强制规则；若业务要求多个单位接续协作，需要明确转交条件、终止条件及无人能处理时的处理方式。
2024年上半年 · 第 2 题：在线教育平台的用例、类与分析设计模型¶
展开原题（先作答，再查看解析）
在线教育平台的用例、类与分析设计模型
阅读下列说明和图，回答问题。
【说明】
某公司预开发一个在线教育平台。学生（Student）可以在该平台上注册账户、浏览课程、购买课程、学习课程内容、参与课程讨论、提交作业、获得成绩反馈；教师（Teacher）可以创建课程、发布课程内容、批改作业、与学生互动并提供成绩反馈。该平台的主要功能描述如下：
（1）用户（User）注册与登录。学生、教师在平台上填写个人信息进行注册。注册成功后，可以使用平台生成的账户登录平台。用户可以修改个人信息，也可以注销自己的账户。
（2）浏览与购买课程（Course）。学生登录平台后，可以浏览不同课程的详细信息，包括课程简介、课程目标、授课内容说明等。学生可以购买课程，购买后可以获得访问课程内容的权限。
（3）学习课程内容（Content）。对于已经购买的课程，学生可以在平台上观看该课程的教学视频、下载教学材料、参加在线测试。
（4）参与课程讨论（Discussion）。学生可以参与已购买课程的课程论坛，在论坛中提问、回复其他人的问题、查看讨论记录。课程论坛由教授该课程的教师维护。
（5）提交作业（Assignment）。学生通过平台提交已购买课程的作业。
（6）获取成绩反馈（Grade）。授课教师在平台上批改学生提交的作业，并给出成绩和反馈意见。学生可以在平台上查看教师的反馈。
现在采用面向对象方法实现该线上教育平台，得到如图1所示的用例图和图2所示的初始类图。
01（7分）
根据说明中的描述，给出图1中A1A3所对应的参与者名称以及U1U4所对应的用例名。
02（6分）
根据说明中的描述，给出图2中C1~C6所对应的类名。
03（2分）
在基于模型驱动的软件开发方法中，在分析阶段和设计阶段通常会使用不同的模型。面向对象方法作为典型的模型驱动开发方法，在分析阶段和设计阶段分别使用的是哪种模型？这两个阶段的模型有何区别？
答案与解析
平台参考答案（原意保留）
平台参考答案：
- A1 User；A2 Teacher；A3 Student。U1 登录；U2、U4 分别为参与课程讨论和获取成绩反馈，两者可交换；U3 购买课程。
- C1 User；C2、C3 分别为 Student、Teacher，两者可交换；C4 Course；C5 Assignment；C6 Grade。
- 平台认为分析阶段使用用例模型，设计阶段使用类图模型：用例模型描述功能需求、系统行为及参与者交互；类图模型描述类、接口、关联和继承等静态结构，为设计实现提供指导。
解析与纠错
解析与纠错：
- A1 是学生和教师共同的用户角色；A3 与浏览、购买、学习课程、提交作业关联，因此为 Student；A2 为 Teacher。图中两个位置都标为 A2，表示同一教师角色的重复绘制，不是新增一种参与者。
- 参与课程讨论和获取成绩反馈同时涉及学生、教师。U2、U4没有进一步区分语义的标注，因此二者可以交换。U3按说明对应购买课程。
- C1是父类User，C2、C3是其两个子类Student、Teacher。图中两子类与Course的普通关联缺少进一步角色限定，二者可交换。C4与Content、Discussion、C5相连且菱形位于C4端，结合业务语义应为Course；C5为Assignment，C6为Grade。图中的实心菱形表示组合关系，而非普通关联。
- 用例图中
«extend»箭头指向被扩展的基本用例，不能表达“必须先注册再登录”或“必须先购买才能学习”的一般先后条件。已购课程是访问课程内容等功能的前置条件；并不意味着每次学习都触发一次购课行为。平台以这些前置条件直接解释扩展关系不够严谨。 - 第3问的核心区别是 分析模型与设计模型的关注层次。分析模型描述问题域、业务概念、需求、对象职责与交互，侧重系统“需要做什么”；设计模型进一步确定软件类与接口、操作、协作、组件、数据结构和实现约束，侧重系统“如何实现”。设计模型通常由分析模型细化、补充并映射到技术方案。
- 用例图和类图分别侧重行为需求与静态结构，但不能把“分析模型=用例模型、设计模型=类图模型”作为阶段的严格对应关系。分析阶段也会使用领域类图、交互图等；设计阶段也会使用设计类图、顺序图、状态图、组件图等。平台对两种图用途的介绍有参考价值，但不足以准确回答两个阶段模型的完整区别。
2023年下半年 · 第 3 题：线上商城的用例、类与多重度¶
展开原题（先作答，再查看解析）
线上商城的用例、类与多重度
【考生回忆版】
某公司用微信小程序开发线上商城，维护销售商品列表ProductCatalog。商品Product的信息包括商品名称、商品参数、快递费用、商品规格、库存数量。系统功能如下。
- 浏览商品：顾客可查看在售商品的详细信息。
- 管理收货地址：系统为每位顾客建立AddressBook，可设置1个或多个Address，并选定一个默认地址。顾客可添加、修改、删除地址；地址包含姓名、联系方式、详细地址。
- 管理ShoppingCart：顾客可添加、删除、编辑其中的商品，添加时必须选择商品规格和购买数量；购物车允许为空。
- 生成Order：顾客可在商品页选择规格和数量后直接生成订单，也可从购物车选择商品生成订单。一个订单可包含多个OrderItem，每个条目对应一个订购商品。
- 取消订单：顾客可主动取消未支付订单或已支付但未发货订单；已生成的订单在30分钟内仍未支付，系统自动取消。
- 提交订单：必须确定收货地址和付款方式Payment，通常采用默认地址；要换地址，应先修改再提交。付款方式为微信WeChat、支付宝Alpay、数字人民币D-ECN。
- 物流追踪：顾客可查询订单状态和物流信息。状态包括待付款、待发货、已完成等；订单处于待收货状态时可查询其物流信息。
面向对象分析得到以下用例图和类图。
【问题1】（4分）写出图1中U1～U4的用例名称。
【问题2】（9分）
（1）写出图2中C1～C7的类名。
（2）写出图2中M1～M4的多重度。
【问题3】（2分）按需求，类C5和C7至少应包含哪些属性？
答案与解析
平台参考答案（原文保留）
【问题1】
U1：生成订单
U2：提交订单
U3：取消订单
U4：付款方式
【问题2】（类名1分，多重度0.5分）
C1：Order
C2：Address
C3：AddressBook
C4：ProductCatalog
C5：Product
C6：Payment
C7：OrderItem
M1：0..*/*
M2：1..*
M3：1..*
M4：1..*
【问题3】
C5应当包括商品名称、商品参数、快递费用、商品规格、库存数量等。
C7应当包括商品名称、商品数量、订单ID等。
解析与纠错
- 按平台映射，U1生成订单、U2提交订单、U3取消订单，U4付款方式。U2与U4之间的include线，以及微信/支付宝/数字人民币支付指向U4的泛化线，说明U4处在支付相关行为的位置；用例通常以“支付”等动作命名，“付款方式”是平台保留用词。
- 类名依次是C1 Order、C2 Address、C3 AddressBook、C4 ProductCatalog、C5 Product、C6 Payment、C7 OrderItem。C1端实心菱形表示订单组合订单条目；C3和C4端的空心菱形分别对应地址列表和商品列表；三种支付实现泛化到C6。
- M1位于购物车对应的商品端，购物车可空，因此是0..；M2为一个订单包含的条目数，按有效订单至少有一条购买项取1..；M3由每份地址列表可设1个或多个地址，取1..。M4平台填1..，但“维护商品列表”本身并不推出目录永远非空；若允许尚未上架或全部下架，0..*也合理。保留平台M4并说明其需要非空目录的额外假设。
- C5的属性由说明直接取得：商品名称、商品参数、快递费用、商品规格、库存数量。C7需要表达购买数量，以及关联的商品和所属订单；所选规格也必须能被确定，可通过条目属性或所关联的具体商品规格对象表达。平台给出的“商品名称、商品数量、订单ID”保留，但在类模型中，商品/订单关联可以承担标识关系，不一定必须把名称和订单ID都重复存成独立属性。
图示局限：C5与C7连线两端都印有1，实际上限制了一个商品只对应一个订单条目，不能表达同一商品出现在多个订单中的常见情况；ShoppingCart端的1也限制每个Product实例只属一个购物车。这里保留原图，不通过改M1～M4掩盖这些已印出的约束。U2、U3以extend指向U1，并不表示“先生成再提交/取消”的时间先后；include也表示被包含行为必然执行，而非仅有付款方式字段。平台以业务先后解释extend不严谨。正文WeChat、Alpay、D-ECN与图中的WeChatPay、Alipay、D·ECN拼写不同，按各来源保留。
2023年上半年 · 第 3 题：数字图书馆的对象模型¶
展开原题（先作答，再查看解析）
数字图书馆的对象模型
阅读下列说明和图，回答问题1至问题3，将解答填入答题纸的对应栏内。
【说明】
某高校图书馆购买了若干学术资源的镜像数据库（MirrorDB）资源，现要求开发一套数字图书馆 （Digital Library） 系统，面向校内用户 （User） 提供学术资源 （Resource） 的浏览、检索和下载服务，系统的主要要求描述如下：
（1）系统中存储了每个镜像数据库的基本信息，包括：数据库名称、访问地址、数据库属性以及数据库简介等信息，用户进入某个镜像数据库后，可以浏览、检索以及下载其中的学术资源。
（2）学术资源包括会议论文（Conference Paper）、期刊论文（Journal Article）以及学位论文（Thesis）等。系统中存储了每个学术资源的题名、作者、发表时间、来源（哪个镜像数据库）、被引次数、下载次数等信息。对于会议论文，还需记录会议名称、召开时间以及召开地点；同一次会议的论文被收录在会议集（Proceeding）中。对于期刊论文，还需记录期刊名称、出版月份、期号以及主办单位；同一期号的论文被收录在一本期刊（Edition）中。对于学位论文，记录了学位类别 （博士/硕士）、毕业学校、专业以及指导教师。
会议集包含发表在该会议 （在某个特定时间段、特定地点召开） 上的所有文章。期刊的每一期在特定时间发行，其中包含若干篇文章。
（3）系统用户 （User） 包括在校学生 （Student）、教师 （Teacher） 以及其他在职人员 （Staff） 。用户使用学校的统一身份认证登录系统后，使用系统提供的各项服务。
（4）系统提供多种资源检索的方式，主要包括：按照资源的题名检索 （Search By Title） 、按照作者名称检索 （Search By Author） 、按照来源检索 （Search By Source） 等。
（5）用户可以下载资源，系统记录每个资源被下载的次数。
现采用面向对象分析与设计方法开发该系统，得到如图3-1所示的用例图以及图3-2所示的初始类图。
【问题1】（8分）
根据说明中的描述，给出图3-2中的C1~C8所对应的类名。
【问题2】（4分）
根据说明中的描述，给出图3-2中的类C1~C4的关键属性。
【问题3】（3分）
在该系统的开发过程中遇到了新的要求：用户能够在系统中对其所关注的数字资源注册他引通知，若该资源的他引次数发生变化，系统可以及时通知该用户。为了实现这个新的要求，可以在图3-2所示的类图中增加哪种设计模式？用150字以内文字解释选择该模式的原因。
答案与解析
平台参考答案（原意保留）
【问题1】
C1：Resource C2：ConferencePaper C3：JournalArticle C4：Thesis C5：User C6--C8不限顺序 C6：Student C7：Teacher C8：Staff
【问题2】
C1： 题名、作者、发表时间、来源、被引次数、下载次数
C2： 会议名称、召开时间、召开地点
C3： 期刊名称、出版月份、期号、主办单位
C4： 学位类别、毕业学校、专业、指导教师
【问题3】
观察者模式
观察者模式定义对象间的一对多的关系，当一个对象的状态发生改变、所有依赖于它的对象都将得到通知并自动更新。符合系统需求。
解析与纠错
类名。 C1是Resource；C2连向Proceeding，故是ConferencePaper；C3连向Edition，故是JournalArticle；C4是Thesis。C5是User，其三个子类C6、C7、C8可分别为Student、Teacher、Staff，三者排列可互换。判断依据是泛化箭头朝向父类，以及各类和会议集、期刊的关联位置，而不是类框编号的先后。
关键属性。 Resource集中保存题名、作者、发表时间、来源、被引次数、下载次数，子类继承这些属性。ConferencePaper另有会议名称、召开时间、召开地点；JournalArticle另有期刊名称、出版月份、期号、主办单位；Thesis另有学位类别、毕业学校、专业、指导教师。来源可以实现为指向MirrorDB的关联，不必同时存一份可能不一致的数据库名称。
通知需求（150字以内示例）。 采用观察者模式。将资源作为被观察对象，关注该资源的用户或通知服务作为观察者，支持订阅和取消订阅。当资源他引次数变化时，通知已注册观察者。资源无须依赖各用户的具体通知方式，新增通知渠道也不必修改资源更新逻辑。
图例纠错。 图3-2中Proceeding、Edition端画的是空心菱形，表示聚合；平台解析称之为“组合关系”不准确，组合通常使用实心菱形。空心菱形不承诺论文与容器具有不可分离的生命周期。新需求说“他引次数”，而已有属性说“被引次数”；若业务区分他引与自引，应明确新增统计口径和触发字段，不能把所有被引变化都自动当作他引变化。
2022年下半年 · 第 3 题：温度换算界面的用例与类图¶
展开原题（先作答，再查看解析）
温度换算界面的用例与类图
温度控制模块的界面提供华氏度（原文Farechet）与摄氏度（Celsius）两种单位。在任一输入框输入温度时，另一单位的数值会自动换算并显示。用户可用Raise、Lower按钮升高或降低温度；右侧温度计把数值按刻度比例显示，并随温度同步变化。
面向对象分析得到以下用例图和类图。
【问题1】（4分）填写图3-2的U1～U4用例名。
【问题2】（8分）使用图3-1中标注的词汇，填写图3-3的C1～C8类名。
【问题3】（3分）现要把界面改为通用GUI，支持任意计量单位的换算，如千克与磅、厘米与英寸。可在图3-3的类图中增加哪种设计模式？用不超过50字解释原因。
答案与解析
平台参考答案（原文保留）
【问题1】
U1：显示温度
U2：显示华氏度
U3：温度计显示
U4：温度计量换算
【问题2】
C1：TemperatureCovertorDialog
C2C4：
FahrenheitEditBox
CelsiusEditBx
TemperatureBar
C5C8：
FahrenheitRaise
FahrenheitLower
CelsiusRaise
CelsiusLower
【问题3】
策略模式
原因：多种单位之间不同的换算规则可以写成不同的算法策略，这些算法之间是平等关系，可以根据自己的需求选择不同的策略，并且可以灵活切换。策略模式的功能就是把具体的算法实现，从具体的业务处理里面独 立出来，把它们实现成为单独的算法类，从而形成一系列的算法，并让这些算法可以相互替换。
解析与纠错
U1为显示温度，U2为显示华氏度，U3为温度计显示，U4为温度计量换算。用例图中的空心三角箭头表示U2、显示摄氏度、U3对U1的泛化；输入、升高、降低温度与U1之间，以及数值显示与换算之间，才是图中标注的include关系。平台解析把泛化与“包含”混用，应按实际箭头区分。
C1可按图3-1标注写TemperatureCovertorDialog。C2～C4为FahrenheitEditBox、CelsiusEditBox、TemperatureBar；C5～C8为FahrenheitRaise、FahrenheitLower、CelsiusRaise、CelsiusLower。类图在两个组内没有进一步区分位置，组内采用一致的对应即可；平台列出的CelsiusEditBx漏了字母o，与界面标注CelsiusEditBox不同。原图还将按钮父类标为Bottom，整理实现时应统一为Button，题图保留原样。
新增模式采用策略模式。符合50字限制的理由可写：“封装不同单位的换算算法为可替换策略，让界面按需要选择，增加换算规则时无需改动界面。”例如摄氏与华氏换算为F=9C/5+32、C=5(F−32)/9，规则应与界面显示分离。
图中Widget一端的实心菱形与通常由对话框拥有部件的含义相反；C1一侧拥有各部件的关系仍可支持本题填空。这里不以错误的菱形方向推导部件拥有对话框。
2022年上半年 · 第 3 题：地址簿管理系统¶
展开原题（先作答，再查看解析）
地址簿管理系统
阅读下列说明和图，回答问题1至问题3，将解答填入答题纸的对应栏内。
某公司的人事部门拥有一个地址簿（AddressBook）管理系统（AddressBookSystem），用于管理公司所有员工的地址记录（PersonAddress）。员工的地址记录包括：姓名、住址、城市、省份、邮政编码以及联系电话等信息。
管理员可以完成对地址簿中地址记录的管理操作，包括：
（1）管理地址记录。根据公司的人员变动情况，对地址记录进行添加、修改、删除等操作。
（2）排序。按照员工姓氏的字典顺序或邮政编码对系统中的所有记录进行排序。
（3）打印地址记录。以邮件标签的格式打印一个地址单独的地址簿。
系统会对地址记录进行管理，为便于管理，管理员在系统中为公司的不同部门建立员工的地址簿的操作，包括：
（1）创建地址簿。新建一个地址簿并保存。
（2）打开地址簿。打开一个已有的地址簿。
（3）修改地址簿。对打开的地址簿进行修改并保存。
系统将提供一个GUI（图形用户界面）实现对地址簿的各种操作。
现采用面向对象方法分析并设计该地址簿管理系统，得到如图3-1所示的用例图和图3-2所示的类图。
图3-2 类图
[问题1]（6分）
根据说明中的描述，给出图3-1中U1～U6所对应的用例名。
[问题2]（5分）
根据说明中的描述，给出图3-2中类AddressBook的主要属性和方法以及类PersonAddress的主要属性（可以使用说明中的文字）。
[问题3]（4分）
根据说明中的描述以及图3-1所示的用例图，请简要说明extend和include关系的含义是什么?
答案与解析
平台参考答案（原意保留）
【问题1】
U1：按姓氏字典顺序排序；U2：按邮政编码排序（其中U1和U2可互换）；
U3：创建地址簿； U4： 修改地址簿； U5：打开地址簿； U6：保存地址簿。
【问题2】
类PersonAddress的主要属性包括：姓名、住址、城市、省份、邮政编码以及联系电话等。
类AddressBook的主要属性包括：部门名/编号，姓名、住址、城市、省份、邮政编码以及联系电话等。
类AddressBook的需要包括创建地址簿、打开地址簿、修改地址簿。综上，类AddressBook的方法包括：添加、修改、删除、创建、打开、打印、排序等。
【问题3】
extend属于用例图的三种关系之一，表示的是扩展关系。
描述为：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能会发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，关系图示指向为扩展用例指向基本用例。 如图所示，创建和打开就是一对扩展关系，创建成功之后可以直接保存关闭之后，如果想要进行后续修改工作，就需要打开地址簿，由扩展用例指向基本用例。
include属于用例图的三种关系之一，表示的是包含关系。
描述为：当可以从两个或两个以上用例中提取公共行为的时候，应该使用包含关系来表示它们。其中这个提取出来的公共用例称之为抽象用例，而把原始用例称为基本用例和基础用例。 如图所示：创建、修改和保存就是一对包含关系，在创建和修改它们都有公共的行为保存，提取出来称之为抽象用例，用包含关系表示它们。
解析与纠错
用例编号。 U1和U2分别为按姓氏字典顺序排序、按邮政编码排序，可以互换。U3为创建地址簿，U4为修改地址簿，U5为打开地址簿，U6为保存地址簿。U3、U4的include箭头都指向U6；图中extend箭头是 U5→U4，不是平台答案所说的“创建和打开”之间。
类的职责。 PersonAddress保存单条地址记录的姓名、住址、城市、省份、邮政编码、联系电话。AddressBook则宜保存部门名或编号，以及PersonAddress记录集合；不应把一套姓名、城市、电话等标量字段平铺到地址簿上，导致无法表达同一部门的多名员工。图中的组合关系也说明地址簿包含地址记录。
AddressBook主要业务方法可列添加、修改、删除地址记录，按姓氏／邮政编码排序、打印及保存。创建、打开、修改地址簿也是系统必须提供的操作；具体实现时，创建或打开可以由系统、工厂或持久化服务承担，不必把每个界面操作机械当作AddressBook实例方法。平台方法列表漏列“保存”，但创建和修改后保存已由题干及include关系明确要求。
include。 从基本用例指向被包含用例，把其所需的行为纳入基本用例。例如创建和修改都包含保存。它常用于复用共同步骤，但不要求一定由两个以上用例共享，也不使目标自动成为UML中的“抽象用例”。
extend。 从扩展用例指向被扩展的基本用例，在规定的扩展点及条件下追加行为，基本用例本身应能独立成立。图示可读作“打开”扩展“修改”；但题干没有明确扩展条件或扩展点，不能把“先打开才能修改”的普通前置条件直接当作extend的定义。平台对创建、打开、修改的时序解释不能替代UML语义。严格的泛化关系使用空心三角箭头，题图的排序变体应结合文字辨认，不宜把其简化箭头画法当作标准符号范本。
已回看原页确认，打印句确为“以邮件标签的格式打印一个地址单独的地址簿。”，没有遗漏后续句段。该句的范围表述含混，因此这里只列打印行为和邮件标签格式，不据此补出单条、整簿或批量范围。
2021年下半年 · 第 3 题：吃金币游戏的用例与类图¶
展开原题（先作答，再查看解析）
吃金币游戏的用例与类图
某游戏公司开发吃金币游戏。背景是回廊式迷宫Maze，迷宫不同位置设有墙；机器人Robots分为小精灵PacMan与幽灵Ghost。玩家控制小精灵在迷宫路径上吞吃金币，并避免被幽灵抓到；幽灵会在迷宫内游走，吃掉遇到的小精灵。游走路径长度按单位距离的倍数计算，迷宫中至少有一个小精灵和一个幽灵时游戏开始。
每个机器人具有两种传感器：
- 前向传感器FrontSensor探测当前位置左侧、右侧、前方是否有墙。遇墙必须改变方向，机器人依据探测结果决定运动方向。
- 近距离传感器ProxiSesor探测视线范围内、正前方是否有隐藏的金币或幽灵。它不直接报告对象是否移动及移动方向；若连续两次探测显示对象位置不同，可推断对象正在移动。
每个机器人还有一个计时器Timer，用来支持预先定义的定时事件。机器人的动作包括原地向左或向右旋转90°，以及向前或向后移动。
用户可用编辑器Editor编写迷宫文件，并把文件导入游戏系统，建立自定义迷宫。采用面向对象分析与设计，得到图3-1用例图和图3-2初始类图。
【问题1】（3分）根据说明，填写图3-1中U1～U3的用例名。
【问题2】（4分）U1～U3分别与哪些用例有关系？各是什么关系？
【问题3】（8分）根据说明，填写图3-2中C1～C8的类名。
答案与解析
平台参考答案（原文保留）
【问题1】(3分)
U1编写迷宫文件;
U2导入迷宫文件;
U3设置计时器。
或者
U1是导入文件，U2,U3分别是旋转、移动
【问题2】(4分)
U1和U2与建立迷宫用例是泛化关系;U3与操作机器人是包含关系。
或者
导入文件与建立迷宫是包含关系。
旋转、移动 和 操作机器人 是泛化关系。
【问题3】(8分)
C1 机器人(Robots)；C2 计时器(Timer)；C3小精灵(PacMan)；C4幽灵(Ghost) ； C5 传感器（Sensor) ； C6 前向传感器(FrontSensor) ； C7 近距离传感器(ProxiSesor)； C8 迷宫(Maze)
其中C3与C4可换；C6与C7可换
解析与纠错
类图部分可以从泛化和整体—部分关系确定：C1为Robots，C3、C4为PacMan与Ghost；C5为Sensor，C6、C7为FrontSensor与ProxiSesor；每个机器人对应一个计时器，故C2为Timer；聚合多个机器人的C8为Maze。C3与C4、C6与C7可各自对换，但应成对保持一致。图中的2..*只保证机器人总数至少为2；“至少一个小精灵和一个幽灵”还需要附加业务约束，不能只靠该多重性表达。
用例部分的平台答案本身提供两套方案：第一套把U1、U2、U3分别解释为编写迷宫文件、导入迷宫文件、设置计时器；第二套把它们解释为导入文件、旋转、移动。原图的U1～U3均没有连线，文字也没有唯一规定它们的位置对应关系，所以不能仅按椭圆之间的距离认定某一套是唯一答案。
按UML含义，include表示执行基础用例时必须包含的行为，泛化表示特殊用例继承一般用例的行为与关系。建立自定义迷宫的文字描述是编写后导入，不足以证明“编写”和“导入”是可替代的两种建立方式；题面也没有说每次操作机器人都必须设置计时器。因而平台第一套的两项泛化及计时器包含关系都依赖额外假设。若把旋转、移动抽象为操作机器人的特殊用例，可以讨论第二套泛化，但仍不是原图直接给出的唯一结论。平台解析将“建立迷宫”称为特殊用例也不符合其所主张的泛化方向；若采用该方案，它应是一般用例。
2021年上半年 · 第 3 题：线上抓药系统的用例与类图¶
展开原题（先作答，再查看解析）
线上抓药系统的用例与类图
某中医医院拟开发线上抓药APP，患者可凭本院医生开具的处方在线抓药，系统提供免费送药上门服务。主要功能如下。
- 注册：患者扫描医院二维码，提供病历号，系统据此自动取得患者基本信息。
- 登录：已注册患者可登录抓药，未注册者被拒绝登录。
- 确认处方：登录后可查看医生开具的所有处方，选择本次处方、药的副数，并说明是否煎制。取药可自行到店或送药上门；选择配送时提供收货人姓名、联系方式、收货地址。系统自动计算费用，患者可用微信、支付宝等方式支付；支付成功后，把处方送给药师配药。
- 处理处方：药师按处方配药，并按患者要求煎制；煎制完成后将处方设置为已完成。自行取药者取药后确认已取药。
- 药品派送：处方完成后，对于选择配送的患者，向快递人员发送药品配置信息，等待取药，同时向患者发送“收获验证码”。
- 送药上门：快递人员将药送至指定地址；患者“收获”时出示验证码，快递人员凭此确认已送达。
图3-1为用例图，图3-2为类图。
【问题1】（7分）填写图3-1中A1～A3的参与者名称，以及U1～U4的用例名称。
【问题2】（5分）填写图3-2中C1～C5的类名。
【问题3】（3分）简述用例之间include、extend、generalize关系的含义。
答案与解析
平台参考答案（原文保留）
【问题1】 A1：患者 A2：快递员 A3：药师 U1：确认处方 U2：支付 U3：微信支付 U4：支付宝支付 U3和U4可互换。 【问题2】 C1：支付方式 C2：微信支付 C3：支付宝支付 C4：处方 C5：派送信息 C2和C3可互换。 【问题3】 include（包含）包含关系：其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例；当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。 本系统中，确认药方过程中系统会自动计算本次抓药的费用，患者可以使用微信或支付宝等支付方式支付费用，所以确认药方包含支付过程。 extend （扩展）扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。 generalize（泛化）泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。 本系统中患者可以使用微信或支付宝等支付方式支付费用，即支付可以有不同种方式，包括微信支付、支付宝支付等，所以微信支付和支付宝支付是支付的特殊化，支付是二者的泛化。 注：本题分值较少，写明定义即可，可以不结合本题实例进行说明。
解析与纠错
注册、登录、确认处方由患者发起，所以A1是患者；参与配送和送达确认的是A2快递员；处理处方的是A3药师。U1为确认处方，所包含的U2为支付；泛化到U2的U3、U4分别为微信支付、支付宝支付，两者可互换。当前完整说明已明确快递人员及验证码流程，平台长解析中“A2线索不明确、当前未给出”的说法不适用于这份题面。
类图的C1为支付方式，其子类C2、C3为微信支付、支付宝支付，可互换；连接支付方式与药师的C4为处方，C5为派送信息。应保持每组父类、子类的语义一致。
include是基础用例在相应执行点必须包含被包含用例的行为，箭头从基础用例指向被包含用例；把公共行为抽出是常见用途，但不要求一定已有两个调用它的用例。extend是在扩展点按条件加入行为，基础用例本身可以独立成立，箭头从扩展用例指向基础用例，不能把任意分支都直接当作extend。generalize表示特殊用例继承一般用例的行为和关系，空心三角箭头指向一般用例，如微信支付、支付宝支付泛化到支付。
说明中的“收获验证码”“收获时”按业务含义应理解为收货验证及收货时，原写法保留。
2020年 · 第 3 题：房产信息系统的用例与类图¶
展开原题（先作答，再查看解析）
房产信息系统的用例与类图
某房产公司拟开发房产信息管理系统，需求如下。
- 房产Property分为住宅House、公寓Cando。每套房产保存房产证明、地址、建造年份、建筑面积、销售报价、房产照片、销售状态（在售、售出、停售）。住宅另存楼层、公摊面积、是否有地下室；公寓另存是否有阳台。
- 公司雇佣多名房产经纪Agent销售房产，记录姓名、家庭住址、联系电话、受雇起止时间。一套房产在同一时段只由一名经纪负责；系统另记录经纪负责每套房产的起始时间、终止时间。
- 用户User包括房产经纪与系统管理员Manager，必须通过身份验证后才能登录。经纪可录入、查询本人负责的房产信息；修改本人负责的房产信息须经管理员审批授权。
- 管理员可导出所有房产的信息报表，定期归档已售出和停售的房产。公司确定不再销售某套房产时，由管理员删除其信息。
图3-1为用例图，图3-2为初始类图。
【问题1】（7分）（1）填写图3-1参与者A1、A2及用例U1～U3的名称；（2）填写图中(a)、(b)处的用例关系。
【问题2】（6分）填写图3-2中C1～C6的类名。
【问题3】（2分）图3-2用AgentList进一步阐述C1、C6之间的关系；根据需求绘出其主要属性。
答案与解析
平台参考答案（原文保留）
【问题1】（7分）
A1：房产经纪；A2：系统管理员
U1：审批授权；U2：修改房产信息；U3：删除房产信息
（a）： < < include > > ；（b）： < < extend > >
【问题2】 （6分）
C1: Property C2: House C3: Cando C4： User C5：Manager C6：Agent
【问题3】（2分）
AgentList的主要属性有：房产经纪负责该房产的起始时间和结束时间
解析与纠错
A1为房产经纪，A2为系统管理员；U1为审批授权，U2为修改房产信息，U3为删除房产信息。(a)从修改指向审批，按题图填include：修改必须包含审批授权，不能据此理解为平台解析所说的“先修改，再审批”；授权应先于修改生效。(b)从删除指向归档，按图填extend，表示满足不再销售等条件时加入删除行为。需求文字并未进一步规定所有删除都必须先归档，该关系是本题图采用的建模表达。
C1～C6依次为Property、House、Cando、User、Manager、Agent；Cando沿用原题类名，不擅改为常见拼法Condo。左侧House、Cando指向Property的空心三角表示继承，方向正确；右侧原图却把空心三角画向C5、C6，与用户角色的语义相反。应由Manager、Agent的泛化箭头指向父类User，即C4。原图保留，不能按错误箭头倒置父子类。平台解析也提示了该图错误。
AgentList通过虚线挂在Property与Agent的关联上，表示关联类；主要属性是经纪负责该套房产的起始时间、终止时间。它们不同于经纪自身的受雇起止时间，也不是房产建造年份。同一房产的负责时段不能重叠，才能满足“同一时段仅一名经纪”的条件。
2019年下半年 · 第 3 题：牙科诊所的用例与类图¶
展开原题（先作答，再查看解析）
牙科诊所的用例与类图
某牙科诊所拟开发系统管理病人基本信息和就诊信息。工作人员包括医护人员（Dental Staff）、接待员（Receptionist）、办公人员（Office Staff）等，功能如下。
- 记录病人基本信息（Maintain patient info）：病人初次就诊时由接待员录入姓名、身份证号、出生日期、性别、首次就诊时间、最后一次就诊时间等。每位病人与其医保信息（Medical Insurance）关联。
- 记录就诊信息（Record office visit info）：每次就诊由接待员录入就诊信息（Office Visit），包括就诊时间、就诊费用、支付代码、病人支付费用、医保支付费用等。
- 记录治疗信息（Record dental procedure）：一次就诊可能接受多项治疗（Procedure），每项治疗可能由多位医护人员服务。治疗信息包括治疗项目名称、治疗项目描述、治疗的牙齿、费用等，每位参与治疗的医护人员分别录入。
- 打印发票（Print invoices）：办公人员打印发票（Invoice），分给医保机构的发票（Insurance Invoice）及给病人的发票（Patient Invoice）；两种内容相同，仅支付费用不同。收到治疗费用后，由办公人员更新支付状态（Enter payment）。
- 记录医护人员信息（Maintain dental staff info）：办公人员录入医护人员姓名、职位、身份证号、家庭住址、联系电话等。
- 医护人员可查询并打印本人参与的治疗项目相关信息（Search and print procedure info）。
采用面向对象方法，得到图3-1用例图及图3-2初始类图。
【问题1】（6分）依据说明，填写图3-1参与者A1～A3及用例U1～U3的名称。
【问题2】（5分）依据说明，填写图3-2类C1～C5的名称。
【问题3】（4分）依据说明，写出图3-2中C4、C5、Patient、Dental Staff的必要属性。
答案与解析
平台参考答案（原文保留）
【问题1】 A1： Receptionist（接待员） A2： Dental Staff（医护人员） A3： Office Staff（办公人员） U1：Maintain patient info （记录病人基本信息） U2：Record office visit info （记录就诊信息） U3： Print invoices（打印发票） 【问题2】 C1： Patient Invoice C2： Insurance Invoice C3： Invoice C4： Procedure C5：Office Visit 【问题3】 C4：治疗项目名称、治疗项目描述、治疗的牙齿和费用 C5：病人就诊时间和费用、支付代码、病人支付费用、医保支付费用 Patient：姓名、身份证号、出生日期、性别、 首次就诊时间和最后一次就诊时间 Dental Staff：姓名、职位、身份证号、住址、联系电话。
解析与纠错
先按角色职责匹配：A1为接待员，负责U1记录病人基本信息、U2记录就诊信息；A2为医护人员，负责治疗记录及查询打印；A3为办公人员，负责U3打印发票、更新支付状态、维护医护人员信息。图中A3连向U2，但说明没有给办公人员记录就诊信息的职责，平台解析也指出这一额外连线缺乏依据；保留题图，不由该线自行增加权限。
C1、C2的公共父类C3对应发票Invoice；两类分别是Patient Invoice、Insurance Invoice。C4与Dental Staff及一次就诊相连，故为Procedure；C5与病人及治疗相连，为Office Visit。C2端的0..*表示一份医保信息可以暂时没有关联的医保发票，不能仅由这一个端点就推出具体某次就诊必为全自费；平台用全自费作业务解释，需要支付情况支持。初始图中的其他多重度也不能取代文字需求的完整约束。
属性从描述逐项提取：C4为治疗项目名称、治疗项目描述、治疗的牙齿、费用；C5为就诊时间、就诊费用、支付代码、病人支付费用、医保支付费用。Patient为姓名、身份证号、出生日期、性别、首次就诊时间、最后一次就诊时间；Dental Staff为姓名、职位、身份证号、家庭住址、联系电话。一次就诊可含多项治疗、每项治疗可涉及多人，不应把这些多值关系直接压成单个姓名字段。
2019年上半年 · 第 3 题：书籍销售系统的用例与类图¶
展开原题（先作答，再查看解析）
书籍销售系统的用例与类图
图书公司计划开发Web书籍销售系统，供顾客（Customer）在线购买书籍（Books），并管理库存和销售。功能要求如下。
- 首次使用时注册（Registerdetail）：顾客填写姓名name、收货地址address、电子邮箱email等，系统生成注册码。
- 注册成功后可登录并购买书籍（Buybooks），浏览书名title、作者author、内容简介introduction等。库存量为0的书籍无法查询。顾客选择书籍和购买数量quantities；超过库存量时提示库存不足，小于库存量时显示验证界面，要求输入注册码。验证正确则自动生成订单Order，否则提示验证错误；顾客可按需打印订单（Printorder）。
- 派送人员（Dispatcher）每天早晨从系统获取当日派送列表（Producepicklist），按收货地址派送书籍。
- 采购人员（Buyer）负责采购（Reorderbooks），每天查询库存量低于再次订购量的书籍并补货；新书到货时，向在线销售目录Catalog添加书籍信息（Addbooks）。
- 采购人员按销售情况，为销量较低的书籍设置折扣或促销（Promotebooks）。
- 新书到货时，仓库管理员（Warehouseman）接收书籍并更新库存（Updatestock）。
图3-1为用例图，图3-2为初始类图的一部分。
【问题1】（6分）填写图3-1参与者A1～A3及用例U1～U3的名称。
【问题2】（6分）根据说明为U3编写用例描述，必须包括基本事件流和所有备选事件流。
【问题3】（3分）填写图3-2中C1～C3的类名。
答案与解析
平台参考答案（原文保留）
【问题1】（6分） A1：采购人员或Buyer A2：仓库管理员Warehouseman A3：派送人员或Dispatcher U1：注册或Registerdetail U2：打印订单或 Printorder U3：购买书籍或Buybooks 【问题2】 U3用例描述 参与者顾客。 主要事件流： 1、顾客登录系统； 2、顾客浏览书籍信息； 3、系统检查某种书籍的库存量是否为0； 4、顾客选择所需购买的书籍及购买数量； 5、系统检查库存量是否足够； 6、系统显示验证界面； 7、顾客输入验证码验证； 8、系统自动生成订单； 备选事件流： 3a. 若库存量为0则无法查询到该书籍信息，退回到2； 5a. 若购买数量超过库存量，则提示库存不足，并退回到4； 7a. 若验证错误，则提示验证错误，并退回到6； 8a. 若顾客需要可以选择打印订单。 前置条件： 1、注册成功。 后置条件： 1、购买成功 【问题3】 C1：顾客或Customer C2：订单或Order C3：书籍或Books
解析与纠错
A1采购人员Buyer负责补货、促销和添加书籍，A2仓库管理员Warehouseman负责更新库存，A3派送人员Dispatcher获取派送列表。顾客独立的U1是注册Registerdetail；图中extend箭头由U2指向U3，故U2为可选的打印订单Printorder，U3为购买书籍Buybooks。
U3的参与者为顾客，前置条件是注册成功。基本事件流可写：顾客登录并浏览可售书籍，选择书籍与数量；系统检查数量符合题设“小于库存量”条件后显示验证界面；顾客输入注册码，验证成功后系统生成订单，购买流程成功结束。
备选流需要覆盖四种情况：库存为0，书籍不显示，继续浏览其他书；购买量超过库存，提示不足并重新选择数量；注册码错误，提示错误并返回验证界面；订单生成后，顾客可选择打印。参考答案称“验证码”，应按题意理解为注册时生成的注册码，不能另发明短信校验流程。
原页已核实说明只写“大于”和“小于”库存量，未另述购买数量恰好等于库存量的处理；题干保留严格小于。实际系统通常允许等于库存，但那是需求补全，不是原题已明确的分支。
C1含name/address/email，为Customer；C3含title/author/introduction，为Books；C2聚合OrderedBook订单项，故为Order。OrderedBook的quantity是每项购买量，不能与书籍总库存混为一项属性。
2018年下半年 · 第 3 题：SNS群组的类图设计¶
展开原题（先作答，再查看解析）
SNS群组的类图设计
社交网络平台SNS支持在线群组，成员可互相分享或挖掘兴趣和活动。群组记录标题、管理员、成员列表等。
用户可自行加入或退出群组。每个群组有一个主页，所有成员都可查看；主页发布或更新信息时，组内成员会自动收到相应信息。退出后不再接收该群组的任何发布或更新信息。
采用面向对象方法得到表3-1类列表及图3-1类图，二者在下图中。
【问题1】（6分）根据说明填写图3-1中C1～C3的类名。
【问题2】（6分）指出图3-1采用的设计模式，并说明其意图和适用场合。
【问题3】（3分）新增需求：一个群体可成为另一群体的成员，例如群体A加入B后，A中的所有成员自动成为B的成员。用文字说明图3-1需要怎样修改。
答案与解析
平台参考答案（原文保留）
【问题1】
C1：SNSGroup；C2：SNSUser；C3：SNSAdmin。
（其中C2、C3可以互换）
【问题2】
采用的设计模式：观察者模式
意图：定义对象间的 一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。
适用场合：
（1）当一个抽象模型有两个方面，其中一个方面依赖于另一个方面，将这两者封装在独立的对象中以使它们可以各自独立地改变和复用。
（2）当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变时。
（3）当一个对象必须通知其他对象，而它又不能假定其他对象是谁，即不希望这些对象是紧耦合的。
【问题3】
（1）在SNSSubject和SNSObserver之间增加继承关系，SNSObserver为基类，SNSSubject为派生类。
（2）为类SNSGroup增加自关联（自己到自己的关联关系）。
解析与纠错
SNSSubject提供AddUser、RemoveUser、Notify，是被观察目标的抽象；发布群组主页内容的具体目标C1为SNSGroup。SNSObserver声明Update，具体关注者为SNSUser和SNSAdmin，对应C2、C3，两者位置可互换。
采用观察者模式：一个目标状态变化时，通知已登记的多个观察者，目标只依赖统一接口。适用于目标与显示/关注方应分别变化、观察者数量动态变化，或通知方不应依赖具体接收者的场景。加入群组对应注册，退出对应撤销，不能只在界面移除成员却仍保留通知登记。
按平台对嵌套群组的修改：让SNSSubject继承SNSObserver，使群组既能作为通知源，也能作为其他群组的观察者；SNSGroup再增加自关联表达群组成员关系。A加入B时可把A登记为B的观察者，A收到更新后向本组成员转发。仅画继承和自关联并不会自动实现传播，更新操作仍需承担这一逻辑；实现时还应明确重复成员和循环嵌套的处理。这些是对图意的说明，不替换原参考答案。
2018年上半年 · 第 3 题：ETC收费系统的用例与类图¶
展开原题（先作答，再查看解析）
ETC收费系统的用例与类图
某ETC（ElectronicTollCollection，不停车收费）系统在高速公路特定位置设置龙门架（Tollgantry）。每个龙门架下有6条车道（Trafficlanes），每条车道装有雷达传感器（Radarsensor）、无线传输器（Radiotransceiver）、数码相机（DigitalCamera）等设备，使车辆以正常速度行驶时完成收费。业务过程如下。
- 汽车安装车载器，驾驶员（Driver）插入具有唯一识别码的磁卡，卡内保存驾驶员账户当前信用记录。
- 车辆经过车道时，设备识别车载器特有编码、判断车型，将信息发往该路段所属区域系统（Regionalcenter）。区域系统计算通行费、创建收费交易（Transaction），从驾驶员专用账户扣款；透支时记录透支账户交易，再将交易后账户信息发给维护账户的中心系统（Centralsystem）。
- 车载磁卡可在邮局付款机充值；充值信息传至中心系统，更新驾驶员账户余额。
- 无车载器或车载器故障时，数码相机拍照，将照片及拍摄时间发至区域系统，记录失败交易，再将该交易信息发至中心系统。
- 区域系统获取收费设备记录的交通事件（Trafficevents）；交通广播电台（Trafficadvicecenter）据此分析并播报路况。
采用面向对象方法得到表3-1用例列表、图3-1用例图与图3-2分析类图。
【问题1】（4分）写出图3-1中A1～A4对应的参与者名称。
【问题2】（5分）结合说明和表3-1，写出图3-1中U1～U5对应的用例名称。
【问题3】（6分）写出图3-2中C1～C6对应的类名。
答案与解析
平台参考答案（原文保留）
【问题1】 A1： Central system或中心系统 A2： Driver 或驾驶员 A3： Regional center 或区域系统 A4： Traffic advice center 或交通广播电台 其中A1、A2可以互换；A3、A4可以互换。 【问题2】 U1： Underpaid transaction U2： Record Illegal use U3： Create transaction U4： Record traffic event U5： Charge card 其中U1、U2可以互换，用例名称必须为英文，因为表中的汉字是对用例的说明。 【问题3】 C1： Central system C2： Toll gantry C3： Traffic lanes C4： Radar sensor C5： Radio transceiver C6： Digital Camera 其中C4、C5、C6可以互换。
解析与纠错
U3是正常创建收费交易，U1/U2是在透支、无法识别车载器等特殊条件下记录异常，因此是指向U3的extend；二者可互换。独立的U4记录交通事件，与区域系统和交通广播电台关联；U5磁卡充值与驾驶员、中心系统关联。相应A1/A2与A3/A4分别可以互换，平台提供的英文用例名全部保留。
类图按“中心系统—区域系统—龙门架—6条车道—三种设备”定位：C1为Central system，C2为Toll gantry，C3为Traffic lanes；C4～C6为Radar sensor、Radio transceiver、Digital Camera，三种设备的空位可互换。C3与Transaction关联，也支持C3是实际进行交易的车道。
平台解析称“C4、C5、C6与C3组合，对应龙门架”不准确：三种设备组成的是车道，龙门架组合6条车道。图3-2在Regional Center—C2连线的Regional Center端标*，不能反过来当作C2端的多重性；若要表达一个区域系统对应多个龙门架，多重性应标在龙门架端。原图和答案均保留，按类名和业务层次区分，不将解析中的口误带入填空。
2017年下半年 · 第 3 题：学术出版物的类图设计¶
展开原题（先作答，再查看解析）
学术出版物的类图设计
某大学拟开发数字图书馆，供用户查询、下载已发表的学术出版物（Publication）。系统需求如下。
- 用户（User）仅限本校学生（Student）、教师（Faculty）及其他工作人员（Staff）；访问前必须使用校园账户、密码登录。
- 可按作者（Author）查询全部出版物。系统保存会议文章（Conf Paper）、期刊文章（JournalArticle）、校内技术报告（TechReport）的题目、作者、出版年份。会议文章还记录会议名称、召开时间、召开地点；期刊文章记录期刊名称、出版月份、期号、主办单位；校内技术报告记录学校分配的唯一ID。
- 可查询指定会议集（Proceedings）或期刊某一期（Edition）的全部文章。会议集包含特定时间段、特定地点召开的会议所发表的全部文章；期刊每一期在特定时间发行，包含若干文章。
- 用户可下载出版物，系统记录每个出版物的下载次数。
- 可查询引用某篇出版物的所有出版物。出版物可引用他人或早期文献作为相关工作、背景资料；用户可为某篇出版物注册引用通知，有新出版物引用它时，系统以电子邮件通知该用户。
采用面向对象方法得到图3-1初始设计类图。
【问题1】（9分）填写图3-1中C1～C9的类名。
【问题2】（4分）写出C6～C9的属性。
【问题3】（2分）指出图中设计模式，以及它实现的系统功能。
答案与解析
平台参考答案（原文保留）
【问题1】
C1：Person
C2：User
C3：Student
C4：Faculty
C5：Staff
C6：Publication
C7：ConfPaper
C8：JournalArticle
C9：TechReport
注：C3/C4/C5可互换。
【问题2】
C6：题目，作者，出版年份
C7：会议名称，召开时间，召开地点
C8：期刊名称，出版月份，期号，主办单位
C9：ID
【问题3】
观察者模式，实现：引用他人学术出版物发送电子邮件通知该用户。
解析与纠错
C2有三种校园用户子类，所以为User，C3～C5是Student、Faculty、Staff，可互换。C2和Author共用的C1可抽象为Person；题干没有给这个父类名称，Person是合理抽象，不是题面明确提供的单词。C6为Publication，C7/C8/C9依次为ConfPaper、JournalArticle、TechReport。
C7连接Proceedings，C8连接Edition，已限制它们分别为会议文章、期刊文章；平台长解析称C7～C9“次序也可随意”不适用于这张带关联的原图。仅C3～C5没有相应区分关联，可以按平台说明互换。
C6保存题目、作者、出版年份；C7补会议名称、召开时间、地点，C8补期刊名称、出版月份、期号、主办单位，C9补ID。子类继承共有信息，不必把共同属性再视为各自独有字段。下载次数也是说明中的持久信息，平台属性答案未列；若覆盖完整需求，可在Publication补下载次数。作者也可由关联表达，而不必重复存为不受约束的文本。
意图是观察者模式：用户注册对某出版物的关注，新引用出现后通知该用户。原图却把Publication画为Observer子类，没有画出User与Subject/Observer的完整登记及通知关系，且Subject—Observer端写0..1，不能单靠这些线就宣称已满足多个用户订阅。常见实现可让出版物或引用管理服务作被观察目标，已登记的用户或通知对象作观察者；此为整理建模建议，原图与平台模式答案保留。
2017年上半年 · 第 3 题：电动玩具订单的类与状态设计¶
展开原题（先作答，再查看解析）
电动玩具订单的类与状态设计
某玩具公司建设电动玩具在线销售系统，向注册会员提供端对端的定制与销售服务。创建新订单（New Order）的详细设计用例、候选设计类分类和部分类图分别见表3-1、表3-2、图3-1。用例的前提、典型事件流、候选事件流3a/7a及C1～C12标记均保留在表中。
表3-1 创建新订单设计用例
表3-2 候选设计类分类
图3-1 部分类图
订单处理时会员可点击“取消订单”。支付失败则挂起，可稍后重新支付；挂起超过30分钟仍未支付，系统自动取消。支付成功后，按订单类型处理：常规订单进入备货，将订单信息发送货运部，打包后交付快递；定制订单进入定制，完成后交付快递。会员点击“收货”后进入收货状态，结束处理。图3-2给出相应状态图。
【问题1】（6分）将表3-1的候选设计类C1～C12按类别填入表3-2的（a）、（b）、（c）。
【问题2】（4分）按创建新订单用例，填写图3-1中X1～X4的类名。
【问题3】（5分）按订单处理过程，填写图3-2中S1～S5的状态名。
答案与解析
平台参考答案（原文保留）
【问题1】
（a）：C2、C4、C7、C10、C11
（b）：C3、C5、C8
（c）：C1、C6、C9、C12
【问题2】
X1：收货地址
X2：支付方式
X3：邮箱地址
X4：电动玩具定制属性
【问题3】
S1：订单挂起
S2：订单备货
S3：订单定制
S4：订单发货
S5：订单收货
解析与纠错
表中的分类标准是职责：显示列表、确认支付信息和完整订单的是边界/接口类，故(a)为C2、C4、C7、C10、C11；总价计算、调用支付、发送订单信息是控制行为，故(b)为C3、C5、C8；会员、订单、邮箱、支付方式是持久信息，故©为C1、C6、C9、C12。C2等在此指展示这些信息的界面职责，不是说“价格”等业务数据在所有建模中都只能作为接口类。
会员资料及订单都使用收货地址和支付方式。图中Profile只关联一个X1，却可关联多个X2；结合候选流7a允许新增并设为默认支付方式，得到X1收货地址、X2支付方式。资料另关联X3邮箱地址，玩具关联X4定制属性（尺寸、颜色等）。
沿事件判状态：支付失败到S1挂起，重新支付返回订单处理，超时到终止；常规订单到S2备货、定制订单到S3定制，两支交付快递后均到S4发货；确认收货到S5收货，再结束。图中“订单类型”两支结合文字的支付成功前提阅读，不能把支付失败也送去备货。
2016年下半年 · 第 3 题：自动售货机的状态与类设计¶
展开原题（先作答，再查看解析）
自动售货机的状态与类设计
出售罐装饮料的自动售货机（Vending Machine）按以下流程工作。
- 顾客选择饮料及数量。
- 顾客从投币口投入硬币，机器只接收硬币。硬币器收集硬币并计算其价值；金额足够且所选饮料库存足够时，推出饮料、计算找零，顾客取走饮料和找零。金额不足或库存不足时，提示继续投币或重选饮料及数量。
- 一次购买结束后移走硬币器中的硬币，即清空硬币器，等待下次交易。另设退币按钮退回顾客投入的硬币，已成功购买饮料的钱不退。
图3-1为用例图。
“购买饮料”的参与者为顾客。主要事件流依次为：①选饮料及数量并投币；②检查投入硬币是否足够；③检查饮料储存仓中所选饮料是否足够；④推出饮料；⑤返回找零。备选流2a在硬币不足时提示并返回步骤1，3a在库存不足时提示并返回步骤1。
据此得到“空闲”“准备服务”“可购买”“饮料出售”四种状态；图3-2给出状态图，图3-3给出类图。
【问题1】（6分）用说明中的术语填写图3-2中S1～S4的状态名。
【问题2】（4分）用说明中的术语填写图3-2中E1～E4的事件名。
【问题3】（5分）用说明中的术语填写图3-3中C1～C5的类名。
答案与解析
平台参考答案（原文保留）
【问题1】
S1：空闲，S2：准备服务，S3：饮料出售，S4：可购买。
【问题2】
E1：饮料数量不足，E2：选择饮料【硬币数量足够】。
E3：饮料数量足够/推出饮料，E4：取走饮料/返回找零并清空硬币器。
【问题3】
C1：自动售货机
C2：硬币器，C3：饮料储存仓，C4：硬币，C5：饮料。/C2：饮料储存仓，C3：硬币器，C4 ：饮料；C5：硬币。
解析与纠错
S1能在清空硬币器后等待交易，为空闲；投币并计算价值进入S2准备服务；金额足够后进入S4可购买；推出饮料进入S3饮料出售。图中的S3、S4顺序与题干列举顺序不同，应沿箭头判断。
E1是库存不足，S4退回S2提示重新选择；E2按平台写选择饮料并满足硬币足够条件；E3为饮料足够时推出饮料；E4为取走饮料后返回找零、清空硬币器，回到空闲。标准状态转移标签可区分“事件[条件]/动作”，不能把条件本身都当成外部事件。平台“硬币数量足够”应结合题干解释为硬币总价值足以支付所选数量的饮料，不是仅数硬币枚数；不同面值不能只比数量。
C1是自动售货机，拥有硬币器和饮料储存仓；它们分别容纳0..*个硬币与饮料。因此可取C2硬币器、C4硬币，C3储存仓、C5饮料；图中两个分支结构相同，也可把C2/C4与C3/C5成对交换。不能只换父类名、不同时换其所容纳的对象。
原用例还包含退还硬币，但这张购买状态图未单独画全退币按钮的事件，不据此增补原题空位或宣称图已经覆盖全部退款规则；已完成购买的金额仍按说明不退。
2016年上半年 · 第 3 题：虚拟世界与机器人的用例及类设计¶
展开原题（先作答，再查看解析）
虚拟世界与机器人的用例及类设计
某软件公司拟实现虚拟世界仿真系统。用户设置并创建不同环境以模拟现实世界，通过1～2个机器人探索；机器人用b1、b2两个变量保存读出的字符。
系统包含以下功能。
- RunRobots：用户用Editor编写环境文件，经LoadFile导入，完成SetupWorld；另在文件中定义机器人的行为，完成SetupProgram。RunProgram有两种模式：Run按预编排的Instruction序列连续动作，若干条Instruction构成InstructionSet；Step是自动控制的特殊形式，每次只执行指定指令的一个动作。
- ManipulateRobots：先SelectRobot选定1个机器人，再手动控制。Move使它向正前方移动一个交叉点；Left使它原地逆时针转90度；Read读取当前位置字符赋给b1，若没有字符则b1不变；Write把b1中的字符写到当前位置，已有字符则覆盖。若b1尚无值，即说明中所说Write前未执行过Read，则ShowErrors提示错误。
Step每次只能执行指令中的下个动作；手动方式有上述4种动作可选。采用面向对象方法得到图3-1用例图和图3-2初始类图；Interpreter、Parser用于解析环境文件及机器人行为文件中的指令集。
【问题1】（6分）按说明填写图3-1中U1～U6的用例名。
【问题2】（4分）说明U1～U6分别与哪个（哪些）用例有关系，以及关系类型。
【问题3】（5分）按说明填写图3-2中C1～C5的类名。
答案与解析
平台参考答案（原文保留）
【问题1】
U1/U2：Run、Step U3：Write U4/U5/U6：Move、Left、Read 【问题2】 U1和U2和RunProgram有泛化关系。 U3，U4，U5，U6和 Manipulate Robots 有泛化关系。
【问题3】
C1：World/虚拟世界
C2：Robot/Robots
C3：Instruction
C4：InstructionSet
C5：Error/Errors
解析与纠错
U1、U2对应Run、Step，两者位置可交换；U3与ShowErrors相连，依据无字符值时Write报错确定为Write；U4～U6可依次填Move、Left、Read，三者位置可交换。
按平台参考答案，Run、Step分别泛化到RunProgram，四种手动动作分别泛化到ManipulateRobots。泛化箭头的空心三角指向一般用例，不能画成动作调用的普通实线箭头。题目将Step称为自动控制的特殊形式，但平台的预期空位是Run和Step同列为RunProgram的特化，不额外改变原图。
问题2问到“哪个（哪些）用例”，而U3与ShowErrors的关系已画在原图中，平台文字答案只列了待补泛化关系。现图的普通箭头缺少标准UML关系标注，不能直接说它已明确标成include或extend。若另作标准用例建模，错误提示仅在b1无值时出现，可由ShowErrors以extend指向Write，并注明触发条件；无条件include会误说每次写都报错。
C1包含1～2个C2，因此是World和Robot；C4聚合1..n个C3，因此是InstructionSet和Instruction；C1依赖C5，对应Error。Interpreter、Parser与World/InstructionSet相连，不应把World本身答成解释器或文件解析器。
原说明把“b1没有值”等同于“从未执行Read”并不严密：机器人在无字符位置执行Read时b1不变，仍可能无值。实际判断应检查b1是否已有有效值；保留原条件但不沿用该等价推论。b2虽在背景出现，题目未给其读写规则，不擅自补用法。
2015年上半年 · 第 3 题：拍卖平台的类模型¶
展开原题（先作答，再查看解析）
拍卖平台的类模型
某拍卖网站组织物品拍卖，并支持在线与线下交易。参与者分个人和团体，不同团体还可组成新的团体参加拍卖；每个参与者均记录名称。
一次拍卖中，参与者担任买方或卖方。每次只拍卖一位卖方的一件物品，多名买方可出价，卖方接受一个出价后结束拍卖。结算有两种方式：线下在约定地点当面付款交货；在线由买方通过网上支付平台付款，卖方通过快递邮寄物品。
一次拍卖的基本事件流如下：
- 卖方在网站发起拍卖并设置起拍价。
- 确定拍卖标的及保留价；若拍卖时间结束时所有出价均低于保留价，拍卖失败。
- 发布拍卖品介绍。
- 买方参与并给出竞拍价。
- 卖方接受一个竞拍价作为成交价，结束拍卖。
- 系统记录成交价，进入结算。
- 双方协商成交方式并完成成交。
采用面向对象方法得到表3-1的类列表、图3-1的类图，以及表3-2的关键属性和方法列表。
【问题1】（7分）确定图3-1中（1）～（7）的类名，用表3-1的类序号作答。
【问题2】（5分）确定表3-2中每个属性或方法属于哪个类，使用表3-1、表3-2中的序号作答。
【问题3】（3分）指出图3-1采用的设计模式，并用100字以内说明采用原因。
答案与解析
平台参考答案（原文保留）
【问题1】
注意：C8和C10可互换，互换后在问题2中也必须交换对应位置。
【问题2】
【问题3】
组合模式，在本题中由于拍卖者分为个人参与者和团体参与者两种，而团体也可以组成新的团体参与拍卖活动。这样的整体部分关系，适合于使用组合模式表达。
解析与纠错
从两组泛化关系入手：参与者是共同抽象，个人和团体是其特例，因此（1）为C5、（2）为C9、（3）为C7；成交方式是共同抽象，线下与在线是其特例，因此（4）为C6、（5）为C8、（6）为C10；与一次拍卖对应的物品是（7）C2。
按参考答案整理属性与职责：
| 属性或方法 | 所属类 | 判断依据 |
|---|---|---|
| M1 | C5 | 所有参与者的名称 |
| M2 | C2 | 拍卖品介绍 |
| M3 | C3 | 拍卖活动的起拍价 |
| M4 | C4 | 结算采用的成交价 |
| M5 | C11 | 原表按Bid分配，术语问题见下文 |
| M6 | C8 | 线下交付地点 |
| M7、M8 | C10 | 在线付款账号、邮寄地址 |
| M9 | C12 | 买方出价 |
| M10 | C1 | 卖方发起拍卖 |
问题3可答：采用组合模式。以共同参与者接口表示个人与团体，团体可包含其他参与者，递归表达整体与部分，使调用者能以一致方式处理个人和团体。
补充说明
订正与图示限制：C11的类名Bid通常表示一次出价，但原类表说明写成“拍卖标的”，M5又把Bid Price描述为保留价。按照参考答案保留M5→C11；实际建模应把买方出价与卖方设定的保留价区分，不能把二者视为同一数值。
原图在（1）参与者一端画了聚合菱形，和“（2）团体包含参与者”的整体方向不一致；按组合模式解释时，整体应是团体。参考答案的类填空仍保留，不以该菱形位置证明整体方向。图上0..1归属限制也比文字中的一般团体组合更强，不宜据此断言任何业务中成员都只能属于一个团体。
（5）、（6）位置可以互换，但C8始终代表OfflinePay，C10始终代表OnlinePay；交换图中位置不会改变M6→C8、M7/M8→C10这些固定类编号对应关系。原答案的“问题2也必须交换对应位置”仅能理解为同步图示位置，不能改写类本身含义。
下表为来源解析中的属性对应表，与参考答案表一致：
课件来源与图片归档¶
来源为希赛《【2026版本】软件设计师考试精讲班视频教程讲义电子版》，以 Obsidian Web Clipper 正文摘录整理；课程提要和通信图短页中被插件遗漏的列表、图片，已经原页面复核补全。网页导航、账户和客服信息已移除；三道案例合计 9 个问题、45 分，原参考答案与补充解析分开保存。
| 课件 | 章节 ID | 本篇对应内容 |
|---|---|---|
| 课程内容提要 | 161760 | 原页面复核的七项课程范围 |
| 类图与对象图 | 161762 | 类图填空与关系识别 |
| 用例图 | 161763 | 用例关系与购买饮料规约 |
| 顺序图 | 161764 | 顺序图与消息机制 |
| 通信图 | 161765 | 原页面复核的对象名、消息及订单派发图 |
| 状态图 | 161766 | 状态名、事件、监护条件与动作 |
| 活动图 | 161767 | 活动、并发、泳道与看图步骤 |
| 实战演练 | 161768 | 三道完整案例及原参考答案 |
20 张图片均引用本地文件；原地址、来源课件及 SHA-256 校验值见图片来源清单。