UML 2.5 用例图实战：ATM系统需求分析，识别5大核心用例与3类参与者

UML 2.5 用例图实战：ATM系统需求分析与建模全流程指南

在软件开发的生命周期中，需求分析是决定项目成败的关键阶段。作为统一建模语言（UML）中最直观的图形化工具之一，用例图能够清晰地展现系统功能与外部参与者的交互关系。本文将以ATM系统为例，带你从零开始掌握UML 2.5标准下的用例建模全流程。

1. 需求分析基础与ATM系统概述

需求分析工程师的工作始于对业务领域的深入理解。ATM（自动柜员机）系统作为银行业务的重要延伸，其核心使命是在无人值守的环境下，安全可靠地完成各类金融交易。与传统的银行柜台服务不同，ATM系统需要同时兼顾操作便捷性、交易安全性和系统稳定性三大维度。

一个典型的ATM系统需要支持以下基础功能：

• 现金存取：支持不同面额的纸币处理
• 账户查询：实时反馈账户余额和交易记录
• 转账汇款：跨账户资金划转
• 密码管理：PIN码修改与安全验证
• 票据打印：交易凭证生成

在非功能性需求方面，ATM系统需要特别关注：

• 交易完整性：确保每笔交易要么完全成功，要么完全回滚
• 故障恢复：断电、断网等异常情况下的数据一致性保障
• 反欺诈机制：防止卡片克隆、密码窃取等安全威胁

提示：在绘制用例图前，建议先创建一份术语表（Glossary），明确定义如"预授权"、"冲正交易"等专业术语，确保团队成员对业务概念的理解一致。

2. 参与者识别与关系建模

识别正确的参与者（Actor）是用例建模的首要步骤。在ATM系统中，参与者不仅限于直接操作设备的用户，还包括各类与系统交互的外部实体。通过多角度分析，我们可以识别出以下核心参与者：

参与者之间存在泛化（Generalization）关系，这是UML中表示继承关系的核心元素。例如：

«Actor» 银行客户 ^ | «Actor» 借记卡客户 «Actor» 信用卡客户 «Actor» 贵宾客户

这种泛化关系意味着子类型参与者自动继承父类型的全部用例。在ATM场景中，所有类型的银行客户都可以执行"查询余额"等基础操作，而"贵宾客户"可能额外拥有"大额取现免手续费"等专属用例。

常见误区纠正：

• 将ATM硬件本身作为参与者（错误：ATM是系统边界内的组件）
• 忽略定时任务参与者（如"日终批处理"触发对账操作）
• 混淆角色与具体用户（一个物理用户可能对应多个角色）

3. 核心用例分析与规约编写

基于ATM系统的功能需求，我们提炼出5个最具代表性的核心用例，每个用例都需要编写详细的规约（Specification）。以下是"取款"用例的完整规约模板：

用例名称：取款（Withdraw Cash）
主要参与者：银行客户
前置条件：

1. 客户已插入有效银行卡
2. 已通过PIN码验证
3. ATM现金箱余额充足

基本事件流：

1. 客户选择"取款"功能
2. 系统显示可选取款金额（如100、500、1000等）
3. 客户输入取款金额
4. 系统验证账户余额是否充足
5. 系统验证单笔取款限额
6. 系统扣减账户余额
7. ATM出钞口提供现金
8. 系统打印交易凭条
9. 系统记录交易日志

备选事件流：

• A1. 账户余额不足：
  1. 系统提示"余额不足"
  2. 返回主界面
• A2. 超出单笔限额：
  1. 系统提示"超过单笔取款限额"
  2. 建议分次取款
  3. 返回金额输入步骤

非功能性需求：

• 响应时间：从输入金额到出钞完成 ≤ 30秒
• 安全性：传输过程使用TLS 1.2+加密
• 可靠性：交易失败率 < 0.01%

其他核心用例的简要特征：

1. 存款：

   • 扩展点：钞票识别失败时的重试机制
   • 特殊需求：支持不同面额混合存入

2. 转账：

   • 包含关系：必须执行"验证收款人账户"子用例
   • 业务规则：跨行转账需额外手续费

3. 查询余额：

   • 最简用例：仅需身份验证
   • 变体：可显示最近5笔交易记录

4. 修改PIN：

   • 安全约束：禁止与旧密码相同
   • 审计要求：记录密码修改操作

4. 高级用例关系与系统边界

UML 2.5提供了三种主要的用例关系类型，每种都有特定的应用场景：

4.1 包含关系（Include）

表示基础用例必须调用被包含用例的功能。在ATM系统中：

取款 --> 验证身份 转账 --> 验证账户

包含关系的特点：

• 具有强制性
• 被包含用例不可独立存在
• 通常表示公共功能模块

4.2 扩展关系（Extend）

描述有条件触发的附加功能。例如：

«extend» 取款 --> 打印凭条 条件：用户选择需要凭条

扩展点的典型应用场景：

• 异常处理流程
• 可选功能模块
• 业务规则分支

4.3 泛化关系

体现用例之间的继承与多态。一个经典案例：

«AbstractUseCase» 交易 ^ / \ / \ 取款 存款 转账

在定义系统边界时，需要明确哪些功能属于ATM系统范畴，哪些属于外部系统职责。例如：

• 系统内：钞票识别、凭条打印、操作日志
• 系统外：账户余额更新、风控审核、短信通知

使用「子系统」包来组织复杂用例是推荐做法：

+-- ATM系统（顶层包） +-- 用户交互子系统 +-- 交易处理子系统 +-- 设备管理子系统 +-- 安全审计子系统

5. 建模工具实操与常见问题排查

StarUML作为主流建模工具，其操作效率直接影响用例图质量。以下是关键操作指南：

快速创建用例图的7个步骤：

1. 新建UML 2.5项目
2. 添加Use Case Diagram
3. 拖拽Actor元素定义参与者
4. 使用椭圆工具创建用例
5. 选择合适的关系连接线
6. 添加注释和约束条件
7. 导出为PNG/SVG格式

常见警告及解决方法：

• 警告UC01：用例缺少关联参与者
  方案：检查是否有孤立用例，或误将系统组件作为参与者

• 警告UC02：泛化关系形成循环
  方案：重构用例层次，确保继承关系为树状结构

• 警告UC03：包含/扩展关系混淆
  方案：用"必须/可选"准则判断，必须执行用包含，条件触发用扩展

模型质量检查清单：

1. 每个用例至少关联一个参与者
2. 用例名称使用"动词+名词"格式
3. 避免超过3层的用例泛化
4. 系统边界明确无歧义
5. 关键扩展点标注触发条件

对于团队协作项目，建议采用分层建模策略：

# 模型文件目录结构 /docs /use-cases /level1-basic # 基础用例 /level2-extended # 扩展场景 /level3-exception # 异常流程 /tools /staruml # 建模工具配置

6. 从用例图到详细设计的衔接

高质量的用例图应该能够自然过渡到后续设计阶段。以下是关键衔接点：

1. 用例规约转为用户故事：

作为[银行客户]， 我希望[通过ATM查询余额]， 以便[了解账户资金情况] 验收标准： - 需插入有效银行卡 - 通过PIN验证 - 显示实时可用余额 - 响应时间<3秒

2. 识别领域对象： 用例中的名词往往对应类图的候选类：

• 银行卡
• 交易记录
• 现金箱
• 凭条打印机

3. 状态转换触发点： 用例中的前置/后置条件暗示状态变化：

「取款成功」事件触发： 账户状态: 可用余额更新 ATM状态: 出钞量统计递增

4. 测试用例衍生： 每个事件流对应一组测试场景：

# 取款测试用例示例 def test_withdraw_insufficient_balance(): card = insert_test_card(balance=100) input_pin('1234') select_withdraw(amount=500) assert_message_displayed("余额不足")

在实际项目中，我们经常发现用例图需要持续演进。例如当新增"刷脸取款"功能时，需要：

1. 添加「面部识别设备」参与者
2. 创建「生物特征验证」子用例
3. 扩展「取款」用例的关系
4. 更新相关用例规约的安全约束

这种迭代过程体现了UML建模的敏捷性——它不是一次性的文档，而是随着需求变化而不断精化的活文档。