UML 用例图 5 大常见误区解析：以订餐/教学系统为例，避免功能分解与粒度错误
UML 用例图 5 大常见误区解析：以订餐/教学系统为例，避免功能分解与粒度错误
在软件开发的需求分析阶段，用例图作为UML中最直观的建模工具之一，常被用于捕捉系统功能需求。然而，许多开发者在绘制用例图时容易陷入典型误区，导致模型偏离了"用户视角"和"有价值结果"的核心思想。本文将通过订餐系统和远程教学系统的实际案例，剖析五大常见错误模式，并提供可落地的修正方案。
1. 功能分解陷阱：将系统操作误认为用例
在订餐系统案例中，开发者常犯的第一个错误是将"增删改查"等底层操作直接作为用例。例如：
错误示范：
前台 → 增加菜式 前台 → 删除菜式 前台 → 修改菜式这种建模方式的问题在于：
- 将系统内部活动暴露为用户目标
- 忽略了用户真正的业务意图（管理菜单）
- 导致用例数量爆炸式增长
修正方案：
%% 正确示范 actor 前台 as F usecase "管理菜单" as UM F -- UM关键区别：
- 合并CRUD操作为单一高阶目标
- 将实现细节保留到用例规约中描述
- 符合"动词+宾语"的用例命名规范（管理菜单）
实际项目中，可在"管理菜单"用例规约中补充：
基本事件流： 1. 前台选择添加新菜品 2. 系统显示菜品信息表单 3. 前台填写菜品详情并提交 4. 系统验证并保存菜品信息 备选事件流： 3a. 前台选择删除现有菜品... 3b. 前台选择修改菜品价格...2. 用例粒度过细：把操作步骤当作独立用例
远程教学系统中，开发者经常错误地将连续的操作步骤拆分为独立用例：
错误示范：
学生 → 登录系统 学生 → 浏览课件 学生 → 下载课件 学生 → 观看视频这种建模的弊端包括：
- 混淆了用户目标与实现路径
- 破坏了用例的完整性（每个步骤不能独立产生价值）
- 增加了模型复杂度
修正方案对比表：
| 错误类型 | 问题分析 | 正确做法 |
|---|---|---|
| 步骤分解 | 将"登录"作为独立用例 | 登录是前置条件而非目标 |
| 动作堆砌 | "浏览/下载/观看"是操作序列 | 整合为"学习课程资料" |
| 技术视角 | 从系统功能出发命名 | 从用户价值出发命名 |
修正后的模型应体现学生的核心目标：
actor 学生 as S usecase "学习课程资料" as LC S -- LC3. 系统视角偏差：用技术术语命名用例
在客户信息管理系统案例中，常见以下错误命名：
错误示范：
客户 → 设置个人密码 客户 → 发送修改邮件正确示范：
客户 → 维护个人信息命名准则检查表：
- [ ] 是否使用业务领域术语？（维护 vs 设置）
- [ ] 是否体现用户目标？（个人信息管理 vs 密码操作）
- [ ] 是否避免技术实现细节？（不出现"发送邮件"等）
典型命名模式应为：
[状语] 动词 + [定语] 宾语 示例： - 预约定期订餐 - 找回账户密码4. 参与者混淆：角色与物理实体不分
订餐系统中存在多种参与者类型，需注意区分：
错误示范：
员工 → 订餐 餐厅员工 → 备餐问题分析：
- 未区分常规顾客与特殊角色
- 混用组织角色和物理人员
修正方案：
actor 员工 as E actor "餐厅员工" as RE actor "菜单管理员" as MA usecase "提交午餐订单" as SO usecase "处理餐饮准备" as HP usecase "管理菜单" as MM E -- SO RE -- HP MA -- MM参与者识别技巧：
- 列出所有与系统交互的外部实体
- 按职责分组（不要按部门划分）
- 检查每个角色是否有独立目标
- 使用泛化处理角色继承关系
5. 关系滥用：包含与扩展的误用
教学系统中常见的关系使用错误：
错误案例：
include 登录 → 学习资料 extend 找回密码 → 登录关系选择决策树：
是否必须执行？ → 包含关系（如"支付"必须包含在"订餐"中） 是否条件触发？ → 扩展关系（如"找回密码"扩展"登录"） 是否不同实现？ → 泛化关系（如"信用卡支付"泛化"支付"）正确建模示例：
usecase "登录系统" as L usecase "找回密码" as FP usecase "学习资料" as S L .> FP : extends S .> L : includes建模自查清单
在完成用例图后，可使用以下检查项验证模型质量：
用户视角验证
- 每个用例是否提供用户可感知的价值？
- 命名是否使用业务术语而非技术术语？
粒度检查
- 用例是否避免暴露系统内部活动？
- 是否合并了属于同一目标的细分操作？
关系审核
- 包含关系是否确实表示必选步骤？
- 扩展点是否明确标注触发条件？
参与者确认
- 每个参与者是否都有明确目标？
- 角色划分是否避免物理实体混入？
一致性检验
- 相同业务概念在全图命名是否一致？
- 是否所有关系都有明确语义？
通过持续应用这些原则，开发者可以建立更准确反映用户需求的用例模型，为后续系统设计奠定坚实基础。记住：优秀的用例图应该能让领域专家（而非仅技术人员）理解并认可系统的价值主张。