- 核心知识点: 参与者、用例、关联关系、包含<<include>>、扩展<<extend>>、泛化
- 精炼讲解: 用例识别方法与用例粒度控制
- 真题实战: 用例图设计题(案例分析高频题)
- 实践应用: 为电商系统设计完整用例图
用例图是软考系统分析师考试中的必考内容，也是面向对象分析与设计的核心工具。从历年真题分析来看，用例图相关题目在上午选择题和下午案例分析题中出现频率极高，占比可达35-40%。掌握好用例图，不仅能在考试中稳拿基础分，更为后续学习类图、时序图等高级UML图打下坚实基础。本文将从核心概念出发，结合历年真题，深入剖析用例图的应用技巧，助你轻松应对考试。
图：UML用例图核心知识体系架构
一、用例图核心概念
1.1 什么是用例图
用例图（Use Case Diagram）是一种用于描述系统功能需求的UML行为图。它从外部用户（参与者）的视角，展示系统提供的服务（用例）以及它们之间的关系。简单来说，它回答了"系统为谁做什么"的问题。
核心价值：
- 界定系统边界，明确功能范围
- 作为需求分析与系统设计的沟通桥梁
- 为后续测试用例设计提供依据
1.2 三大核心要
1. 参与者
参与者是与系统交互的外部实体，可以是人、其他系统或硬件设备。
|-------|------------|------------|
| 参与者类型 | 示例 | 特点 |
| 人 | 顾客、管理员、操作员 | 系统的使用者 |
| 外部系统 | 支付系统、物流系统 | 与系统有交互的第三方 |
| 硬件设备 | ATM机、传感器 | 与系统直接交互的设备 |
关键点：
- 参与者位于系统边界外部
- 识别参与者时，要区分主要参与者（主动触发用例）和辅助参与者（系统为完成用例需要调用的外部对象）
- 一个人或事物在与系统交互时可以扮演多个角色
2. 用例
用例是系统为参与者提供的、有价值的、完整的功能单元。
用例特征：
- 命名通常采用动宾短语 （如"提交订单"、"查询库存"）
- 代表一个完整的、对参与者有价值的业务目标
- 用例之间相互独立，每个用例可独立执行
- 存在可观测的执行结果
用例粒度控制：
- 过大："管理系统"（过于笼统）
- 过小："点击提交按钮"（过于细节）
- 合适："处理订单"、"验证支付信息"（完整功能单元）
3. 关系
用例图中的关系主要包含三种：包含关系、扩展关系和泛化关系。这是历年考试中最常考的知识点，也是考生最容易混淆的地方。
二、用例关系深度解析
2.1 包含关系（<>）
本质：强制性依赖
包含关系表示基础用例必须使用被包含用例的功能。就像程序中的函数调用，被包含的用例是基础用例的必需组成部分。
箭头方向： 从基础用例指向被包含用例（虚线箭头 + <>）
触发条件： 无条件触发，基础用例执行时必然执行被包含用例。
典型场景： 多个用例共享的通用流程（如验证、登录）。
示例：
- "提交订单"包含"验证支付信息"
- "修改订单"包含"检查用户登录"
- "注册账号"包含"填写基本信息"
记忆口诀： 包含必用，指向零件
2.2 扩展关系（<>）
本质：有条件扩展
扩展关系表示基础用例可能在特定条件下扩展执行扩展用例的功能。就像一个插件功能，可选、有条件。
箭头方向： 从扩展用例指向基础用例（虚线箭头 + <> + 标注扩展条件）
触发条件： 需满足扩展点条件（如用户勾选项）。
典型场景： 非必须的附加功能（如升级服务、异常处理）。
示例：
- "申请退货"扩展"查询订单"（仅在需要退货时触发）
- "预订机票"可扩展"购买行李额"（仅在行李超重时）
- "下单"在余额不足时可扩展"使用优惠券"
记忆口诀： 扩展可选，指向本体
2.3 泛化关系
本质：继承关系
泛化关系表示子用例继承父用例的行为，并可扩展或重写功能。这是面向对象中继承思想在用例图中的体现。
箭头方向： 从子用例指向父用例（实线空心三角箭头）
触发条件： 子用例替代父用例执行，实现多态性。
典型场景： 同一操作的不同实现方式。
示例：
- "支付"是父用例，"微信支付"、"支付宝支付"、"信用卡支付"是子用例
- "用户认证"是父用例，"密码登录"、"短信验证码登录"、"人脸识别登录"是子用例
记忆口诀： 泛化继承，指向父亲
三种关系对比表
|------|------------|-------|-----------|----------|
| 关系类型 | 箭头方向 | 执行方式 | 典型场景 | 记忆关键词 |
| 包含 | 基础用例→被包含用例 | 必然执行 | 公共步骤复用 | 必须、每次 |
| 扩展 | 扩展用例→基础用例 | 条件触发 | 可选功能、异常处理 | 可能、有时 |
| 泛化 | 子用例→父用例 | 继承并特化 | 多种实现方式 | 是一种、特殊形式 |
三、历年真题实战解析
真题1：关系判断（2023年5月 系统分析师）
题干： 在UML用例图中，如果用例A与用例B相似，但A的动作序列是通过在B的动作序列中插入一些额外动作来构成的，则称（）。
选项：
A. A包含B
B. A扩展B
C. A泛化B
D. B泛化A
正确答案：B
答案解析：
"插入额外动作"并具有条件性，是扩展关系的典型特征。扩展关系描述在基础用例的特定扩展点，可以插入扩展用例的行为。A是扩展用例，B是基础用例，所以是A扩展B。
真题2：包含vs扩展（2021年11月 软件设计师）
题干： 在订单管理模块中，新建订单和修改订单都需要检查用户是否登录，用例"新建订单"、"修改订单"与用例"检查用户登录"之间是（）
选项：
A. 包含关系
B. 扩展关系
C. 泛化关系
D. 聚集关系
正确答案：A
答案解析：
当两个或两个以上的用例中提取公共行为时，应该使用包含关系。题干中"都需要检查用户是否登录"说明这是必须执行的公共步骤，属于包含关系。扩展关系是可选的、有条件的，泛化关系是继承关系，聚集关系是类图中的关系，不属于用例图。
真题3：概念识别（2022年5月 系统分析师）
题干： 当（）时，用例是捕获系统需求最好的选择。
选项：
A. 系统具有很少的用户
B. 系统具有很少的接口
C. 系统算法复杂，功能单一
D. 系统有很多参与者
正确答案：D
答案解析：
用例图的核心优势是从参与者视角描述交互，参与者越多，越需要通过用例来梳理不同角色的需求，明确系统边界。A、B、C情况更适合用流程图、数据流图等描述内部逻辑。
真题4：关系定义（2020年11月 软件设计师）
题干： 在用例图中，用例A和用例B之间为（）关系，表示用例B的执行必然包含用例A的执行。
选项：
A. 扩展
B. 包含
C. 泛化
D. 实现
正确答案：B
答案解析：
"包含"关系表示基础用例（B）执行时，必须执行被包含用例（A）的行为。"必然包含"是关键词，明确指向包含关系。
四、用例识别方法与实战应用
4.1 用例识别方法
方法1：从参与者出发
针对每个参与者，思考以下问题：
- 参与者希望通过系统实现什么目标？
- 参与者需要在系统中执行哪些操作？
- 系统为参与者提供哪些服务？
- 参与者会触发哪些系统事件？
方法2：从业务流程出发
分析业务流程中的关键步骤：
- 业务流程中的每个关键环节可能对应一个用例
- 每个需要系统支持的业务操作都是一个潜在的用例
- 系统状态改变时的操作可能是用例
方法3：从系统功能出发
梳理系统功能需求：
- 系统需要支持哪些功能模块？
- 每个功能模块的核心操作是什么？
- 哪些功能是完整的、有价值的业务单元？
4.2 用例粒度控制
粒度过大的问题：
- "管理商品系统"（过于笼统，无法清晰描述）
粒度过小的问题：
- "点击提交按钮"（过于细节，不是完整的业务功能）
合适的粒度：
- "添加商品"（完整功能，有明确目标）
- "查询商品信息"（完整功能，有明确目标）
- "提交订单"（完整功能，有明确目标）
判断标准：
- 是否能独立执行并产生可观测结果？
- 是否对参与者有价值？
- 是否是完整的业务目标？
五、电商系统完整用例图设计实战
5.1 系统需求描述
设计一个在线电商系统，支持顾客购物、商家管理、系统管理等功能。
核心功能需求：
- 顾客可以浏览商品、搜索商品、添加购物车、提交订单、支付、查询订单
- 商家可以添加/删除/修改商品、查询订单、处理订单
- 管理员可以管理用户、管理商品、查看统计报表
- 支持多种支付方式（支付宝、微信、银行卡）
5.2 识别参与者
|------|------|------------------|
| 参与者 | 类型 | 说明 |
| 顾客 | 人 | 系统的主要使用者，进行购物操作 |
| 商家 | 人 | 系统的服务提供者，管理商品和订单 |
| 管理员 | 人 | 系统的管理者，负责系统维护 |
| 支付系统 | 外部系统 | 第三方支付接口，处理支付请求 |
| 物流系统 | 外部系统 | 第三方物流接口，处理配送 |
5.3 识别用例
顾客相关用例：
- 浏览商品
- 搜索商品
- 添加商品到购物车
- 修改购物车商品数量
- 从购物车删除商品
- 提交订单
- 支付订单
- 查询订单
- 申请退货
商家相关用例：
- 添加商品
- 删除商品
- 修改商品信息
- 查询订单
- 处理订单
- 处理退货
管理员相关用例：
- 用户管理
- 商品审核
- 查看统计报表
- 系统设置
公共用例（可被包含）：
- 验证用户登录
- 验证支付信息
- 发送通知
5.4 确定关系
包含关系：
- 提交订单<>验证用户登录
- 支付订单<>验证支付信息
- 添加商品<>验证用户登录
- 删除商品<>验证用户登录
扩展关系：
- 申请退货<>查询订单（仅在需要退货时）
- 提交订单<>使用优惠券（仅当有优惠券时）
- 支付订单<>选择支付方式
泛化关系：
- 支付订单（父用例）
- 支付宝支付（子用例）
- 微信支付（子用例）
- 银行卡支付（子用例）
5.5 完整用例图设计
5.6 关键设计要点
系统边界明确： 所有用例都在"电商系统"矩形框内，参与者在框外
参与者合理： 顾客、商家、管理员为主要参与者，支付系统、物流系统为外部系统参与者
用例粒度适中： 每个用例都是完整的、有价值的业务功能
关系清晰：
- 包含关系用于公共步骤（验证登录、验证支付）
- 扩展关系用于可选功能（使用优惠券、申请退货）
- 泛化关系用于多种实现方式（支付方式）
业务流程完整： 覆盖了电商系统的核心业务流程
六、备考策略与实战技巧
6.1 高频考点总结
必考点1：包含vs扩展区分
- 关键词：每次、总是→包含；有时、如果...则...→扩展
- 本质区别：包含是必须的，扩展是可选的、有条件的
必考点2：参与者识别
- 参与者必须在系统边界外部
- 识别主要参与者和辅助参与者
- 外部系统也可以作为参与者
必考点3：用例粒度控制
- 过大："管理系统"（错误）
- 过小："点击按钮"（错误）
- 合适："处理订单"（正确）
6.2 真题解题技巧
技巧1：抓关键词
- "必须"、"每次"、"总是" → 包含关系
- "可能"、"有时"、"如果...则..." → 扩展关系
- "是一种"、"特殊形式" → 泛化关系
技巧2：看箭头方向
- 包含：基础用例→被包含用例（<<include>>）
- 扩展：扩展用例→基础用例（<<extend>>）
- 泛化：子用例→父用例（空心三角箭头）
技巧3：理解业务场景
- 将题目中的用例关系代入熟悉的业务场景
- 例如：支付必须包含验证，退货只是查询订单的扩展
6.3 学习建议
第一轮：掌握基本概念
- 理解参与者、用例、关系的定义
- 记住箭头方向和标记符号
- 掌握三种关系的本质区别
第二轮：动手实践
- 尝试为熟悉的系统（如图书馆管理系统、ATM机）绘制用例图
- 练习识别参与者和用例
- 练习确定用例之间的关系
第三轮：真题演练
- 精练近5年真题中所有关于用例图的题目
- 总结出题角度和常见陷阱
- 针对薄弱点进行专项练习
第四轮：知识串联
- 将用例图与类图、时序图、活动图联系起来理解
- 建立完整的UML知识体系
- 理解用例图在面向对象分析与设计中的位置
七、知识延伸与综合应用
7.1 用例图与UML其他图的关系
|------|-----------|--------------|
| UML图 | 作用 | 与用例图的关系 |
| 用例图 | 描述系统功能需求 | 需求分析的起点 |
| 类图 | 描述系统静态结构 | 用例中的名词常发展为类 |
| 时序图 | 描述对象间交互顺序 | 细化单个用例的交互过程 |
| 活动图 | 描述业务流程 | 描述用例内部的复杂逻辑流 |
| 状态图 | 描述对象状态变迁 | 描述用例中对象的状态变化 |
7.2 用例图在需求工程中的位置
- 需求获取 ：通过与用户沟通，识别参与者和用例
- 需求分析 ：通过用例图梳理系统功能，界定系统边界
- 需求规格说明 ：每个用例对应一份详细的用例规约
- 需求验证 ：用例图作为验证需求完整性的依据
7.3 用例图与测试的关系
- 每个用例对应一组测试用例
- 用例的规约（基本流、备选流）是测试用例设计的依据
- 用例图确保功能测试覆盖的完整性