目录
一、需求建模基础
1.1 什么是需求？
1.2 需求建模的两个阶段
1.3 需求规约的质量属性
二、用例（Use Case）
2.1 什么是用例？
2.2 用例的核心特点
2.3 用例 vs 功能点
三、参与者（Actor）
3.1 什么是参与者？
3.2 参与者的类型
3.3 如何识别参与者？
四、确定用例
4.1 主序列和备选序列
五、用例关系（重点！）
5.1 包含关系（Include）
5.2 扩展关系（Extend）
5.3 包含关系 vs 扩展关系（高频考点！）
六、用例的组织
6.1 不宜采用小粒度的包含用例
6.2 用例包（Use Case Package）
七、活动图描述用例的交互序列
7.1 什么是活动图？
7.2 活动图 vs 用例图
7.3 活动图的基本元素
八、课后思考题（含答案）
问题1：包含关系和扩展关系的区别是什么？各自在什么场景下使用？
问题2：如何识别系统的参与者？请列举四种参与者类型。
问题3：主序列和备选序列的区别是什么？请举一个生活中的例子。
九、本讲核心考点总结
内容：需求建模、用例与参与者、包含/扩展关系、活动图
一、需求建模基础
1.1 什么是需求？
需求描述用户对系统的期望，主要考虑外部特性：
| 需求类型 | 说明 | 例子 |
|---|---|---|
| 功能需求 | 系统要提供什么功能 | "用户可以登录系统" |
| 非功能需求 | 系统应该满足什么质量属性 | "登录响应时间不超过1秒" |
1.2 需求建模的两个阶段
- 需求分析：分析涉众、当前系统、新系统特性
- 需求规约：与用户达成共识的文档
1.3 需求规约的质量属性
| 属性 | 说明 |
|---|---|
| 正确 | 准确描述用户真正需要的 |
| 完整 | 没有遗漏重要需求 |
| 无二义性 | 每个需求只有一种理解方式 |
| 一致性 | 需求之间不矛盾 |
| 可验证 | 可以通过测试验证是否满足 |
| 非计算机专家能理解 | 用户也能看懂 |
| 可修改 | 容易修改和更新 |
| 可追踪 | 能追溯到来源和后续设计 |
二、用例（Use Case）
2.1 什么是用例？
用例定义了一个或多个参与者与系统之间的交互序列。
2.2 用例的核心特点
| 特点 | 说明 |
|---|---|
| 黑盒视角 | 将系统看成黑盒，不关心内部"怎么做" |
| 从参与者出发 | 用例总是从参与者的输入开始 |
| 包含主序列和备选序列 | 主序列是正常流程，备选序列是异常/替代流程 |
2.3 用例 vs 功能点
用例描述的是交互场景，不是简单的功能列表。
错误做法："系统提供登录功能" 正确做法："用户输入用户名和密码，系统验证身份，登录成功进入首页"
三、参与者（Actor）
3.1 什么是参与者？
参与者描绘与系统交互的外部用户，是一种角色，不一定是具体的人。
3.2 参与者的类型
| 类型 | 说明 | 例子 |
|---|---|---|
| 主要参与者 | 负责启动用例 | 顾客下单、管理员添加商品 |
| 次要参与者 | 参与用例但不启动 | 支付系统（被调用）、邮件系统（发送通知） |
| 其他参与者 | 其他外部交互实体 | 定时器、传感器 |
3.3 如何识别参与者？
| 类型 | 说明 | 例子 |
|---|---|---|
| 人类参与者 | 使用标准/非标准I/O设备与系统交互的人 | 普通用户、管理员 |
| 外部系统参与者 | 与系统交互的其他软件系统 | 支付网关、第三方登录系统 |
| 设备参与者 | 硬件设备 | 打印机、扫码枪、传感器 |
| 计时器参与者 | 时间触发的事件 | 定时备份、定时报表生成 |
参与者是角色不是具体的人。比如"顾客"是一个角色，张三和李四都可以扮演这个角色。
四、确定用例
4.1 主序列和备选序列
| 序列类型 | 说明 | 例子 |
|---|---|---|
| 主序列（主场景） | 正常情况下的交互流程 | 用户输入正确密码，登录成功 |
| 备选序列（替代场景） | 异常或替代情况 | 用户密码错误，提示重新输入 |
生活例子：ATM取款
- 主序列：插卡 → 输入密码 → 选择取款 → 输入金额 → 出钞 → 退卡
- 备选序列1：密码错误 → 提示重新输入 → 连续3次错误 → 吞卡
- 备选序列2：余额不足 → 提示余额不足 → 返回主菜单
五、用例关系（重点！）
5.1 包含关系（Include）
定义：标识多个用例中共同的交互序列，抽取为包含用例（抽象，不能独立执行），基用例包含并执行包含用例。
特点：
- 包含用例是抽象的，不能独立执行
- 基用例执行时，包含用例一定会被执行
- 用于将复杂的交互序列层层细分
图示：
Plain Text
基用例 "下订单" │ │ <<include>> ▼ 包含用例 "验证用户身份"生活例子： "下订单"、"查看订单历史"、"取消订单"三个用例都需要验证用户身份，抽取为包含用例。
5.2 扩展关系（Extend）
定义：将可替换/备选/异常分支分离成扩展用例。基用例不依赖扩展用例，扩展用例在条件为真时才执行。
特点：
- 扩展用例不一定执行，只在条件满足时执行
- 基用例不依赖扩展用例，可以独立运行
- 通过扩展点名称和选择条件标识
图示：
Plain Text
基用例 "下订单" │ │ <<extend>> （条件：用户是VIP） ▼ 扩展用例 "应用VIP折扣"生活例子： "下订单"用例中，只有用户是VIP时才触发"应用VIP折扣"扩展用例。
5.3 包含关系 vs 扩展关系（高频考点！）
| 对比维度 | 包含关系（Include） | 扩展关系（Extend） |
|---|---|---|
| 执行时机 | 基用例执行时一定执行 | 只在条件满足时执行 |
| 依赖关系 | 基用例依赖包含用例 | 基用例不依赖扩展用例 |
| 用例性质 | 包含用例是抽象的，不能独立执行 | 扩展用例可以独立理解 |
| 使用目的 | 抽取公共的、重复的交互序列 | 分离可选的、异常的分支 |
| 类比 | 像函数调用（必须执行） | 像条件分支（可选执行） |
| 箭头方向 | 基用例 → 包含用例 | 扩展用例 → 基用例 |
记忆口诀：包含是"必做公共事"，扩展是"条件做额外事"。
六、用例的组织
6.1 不宜采用小粒度的包含用例
包含用例的粒度要适中。如果包含用例太小（如"输入用户名"），会导致用例图过于复杂，失去可读性。
6.2 用例包（Use Case Package）
当用例数量较多时，可以使用用例包来组织：
| 组织方式 | 说明 |
|---|---|
| 按主要参与者分组 | 所有"顾客"相关的用例放在一个包 |
| 按相同非功能需求分组 | 所有需要高安全性的用例放在一个包 |
七、活动图描述用例的交互序列
7.1 什么是活动图？
活动图描述控制流和活动序列，显示顺序活动、决策结点、循环及并发活动。
7.2 活动图 vs 用例图
| 图类型 | 关注点 | 用途 |
|---|---|---|
| 用例图 | 系统有哪些功能、谁使用 | 需求概览 |
| 活动图 | 用例内部的详细流程 | 描述交互序列的细节 |
7.3 活动图的基本元素
| 元素 | 说明 | 图示 |
|---|---|---|
| 活动 | 一个执行步骤 | 圆角矩形 |
| 决策结点 | 条件分支 | 菱形 |
| 初始/终止 | 流程开始和结束 | 实心圆/同心圆 |
| 并发 | 多个活动同时执行 | 同步条（粗横线） |
八、课后思考题（含答案）
问题1：包含关系和扩展关系的区别是什么？各自在什么场景下使用？
答案：
- 包含关系：用于抽取多个用例中共同的、必须执行的交互序列。包含用例是抽象的，不能独立执行，基用例执行时一定会执行包含用例。例如：多个用例都需要"验证用户身份"，可以抽取为包含用例。
- 扩展关系：用于分离可选的、异常的或条件触发的分支。扩展用例在特定条件满足时才执行，基用例不依赖扩展用例，可以独立运行。例如："下订单"用例中，只有VIP用户才触发"应用VIP折扣"扩展用例。
问题2：如何识别系统的参与者？请列举四种参与者类型。
答案：从四个维度识别：
- 人类参与者：使用标准/非标准I/O设备与系统交互的人
- 外部系统参与者：与系统交互的其他软件系统
- 设备参与者：硬件设备
- 计时器参与者：时间触发的事件
问题3：主序列和备选序列的区别是什么？请举一个生活中的例子。
答案：
- 主序列：经常发生的正常流程，系统期望的执行路径
- 备选序列：偶尔发生的异常或替代流程，系统需要处理的异常情况
例子：ATM取款
- 主序列：插卡 → 输入密码 → 选择取款 → 输入金额 → 出钞 → 退卡
- 备选序列1（密码错误）：密码错误 → 提示重新输入 → 连续3次错误 → 吞卡
- 备选序列2（余额不足）：余额不足 → 提示余额不足 → 返回主菜单
九、本讲核心考点总结
| 考点 | 重要程度 |
|---|---|
| 包含关系 vs 扩展关系 | 高频考点 |
| 四种参与者类型 | 高频考点 |
| 主序列 vs 备选序列 | 理解考点 |
| 用例的定义和特点 | 基础考点 |
| 活动图的基本元素 | 基础考点 |
