【面向对象】UML行为图：用例图（参与者/用例/关系）

考点频率：★★★★★（下午题必考，选择题也常考）
难度：⭐⭐⭐
建议：重点区分<<include>>（包含）和<<extend>>（扩展）的关系，这是下午题补全用例关系的核心得分点

1️⃣ 用例图在画什么？

用例图（Use Case Diagram）从用户视角出发，描述“系统做什么”，而不是“怎么做”。它回答的核心问题是：谁（参与者）能对系统做什么（用例）？

打个比方：你去餐厅吃饭，你不需要知道厨房里怎么切菜、怎么颠勺（那是实现细节）。你只需要知道服务员（系统边界）能帮你点单（用例）、上菜（用例）、结账（用例）。用例图就是这张“菜单”，清晰地告诉所有食客（参与者），这家店（系统）提供哪些服务。

在软考下午题中，通常给你一段需求描述，要求你补全用例图中的参与者、用例名称，以及用例之间的包含/扩展关系。

2️⃣ 用例图的三大核心组件

特别注意：参与者不一定都是人。外部系统（如支付宝支付接口）也可以是参与者。如果外部系统作为参与者，通常用矩形加<<actor>>标注，而不是火柴人。

3️⃣ 用例之间的关系（下午题核心考点）

这是软考考查的重中之重，尤其是包含和扩展的辨析。

3.1 包含关系（Include）——<<include>>

语义：一个用例（基础用例）必然会执行另一个用例（包含用例）的功能。缺少包含用例，基础用例就不完整。

• 方向：基础用例指向被包含用例（虚线箭头指向被包含者）。
• 典型场景：公共的子功能、必须执行的步骤。
• 示例：下单用例<<include>>支付用例。下单时必须支付，不支付下单就不成立。

3.2 扩展关系（Extend）——<<extend>>

语义：一个用例（扩展用例）在特定条件下，可选地扩展另一个用例（基础用例）的行为。缺少扩展用例，基础用例仍然完整。

• 方向：扩展用例指向基础用例（虚线箭头指向被扩展者，和包含方向的指向相反）。
• 典型场景：可选功能、异常处理、特定条件下的额外操作。
• 示例：下单用例<<extend>>使用优惠券用例。用户有优惠券时可以选，没有优惠券或者不想用，照样能下单。下单本身是完整的，优惠券是锦上添花。

3.3 泛化关系（Generalization）—— 实线空心三角箭头

语义：子用例（或子参与者）继承父用例（或父参与者）的行为和含义，并可扩展或覆盖。

• 方向：子用例指向父用例（与类的继承符号相同）。
• 应用场景：即可用于参与者之间（如VIP客户继承普通客户），也可用于用例之间（如扫码支付继承支付）。考试中，泛化关系在用例图中使用较少，多用于类图，了解即可。

4️⃣<<include>>vs<<extend>>（死磕对比表）

这是整个用例图部分的“杀手题”，务必刻进脑子里：

5️⃣ 经典例题

例题1（含/扩辨析）：某系统的“借书”用例中，读者每次借书前系统必须验证该读者的会员资格是否有效。如果读者当天有逾期未还书籍，则系统提示“不可借书”。

A.验证会员资格与借书之间是包含关系
B.验证会员资格与借书之间是扩展关系
C.提示不可借书与借书之间是包含关系
D.借书与验证会员资格之间是扩展关系

解析：

• “必须验证” →包含关系。基础用例借书指向被包含用例验证会员资格。
• “逾期时提示”是扩展关系。但看选项，A正确。选A。

例题2（符号识别）：在用例图中，表示扩展关系的符号是（ ）。

A. 虚线箭头 +<<include>>
B. 虚线箭头 +<<extend>>
C. 实线空心三角箭头
D. 实线箭头

解析：A是包含，B是扩展，C是泛化，D是关联/通信。选B。

6️⃣ 记忆口诀

用例三要素：参与者火柴人，椭圆功能在里面，边界框框围一圈。
包含是“必须”，基础指包含，箭头指向被含者。
扩展是“可选”，扩展指基础，触发条件才出现。

区分大招：看到题干的“必须/总是”→ 选包含；看到“如果/当…时/可选”→ 选扩展。

7️⃣ 小测验（评论区对答案）

某在线考试系统的用例图中，“开始考试”用例执行前，系统必须验证考生的身份信息。身份验证通过后，考生才能开始作答。请问“身份验证”与“开始考试”之间应该使用（ ）关系？
A.<<extend>>
B.<<include>>
C. 泛化
D. 关联

🔔本专栏日更，点击头像 → 专栏《软考中级高频考点》订阅，第一时间接收新内容

#软考中级 #软件设计师 #用例图 #UML #包含 #扩展 #软考备考