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 -- LC

3. 系统视角偏差：用技术术语命名用例

在客户信息管理系统案例中，常见以下错误命名：

错误示范：

客户 → 设置个人密码 客户 → 发送修改邮件

正确示范：

客户 → 维护个人信息

命名准则检查表：

• [ ] 是否使用业务领域术语？（维护 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

参与者识别技巧：

1. 列出所有与系统交互的外部实体
2. 按职责分组（不要按部门划分）
3. 检查每个角色是否有独立目标
4. 使用泛化处理角色继承关系

5. 关系滥用：包含与扩展的误用

教学系统中常见的关系使用错误：

错误案例：

include 登录 → 学习资料 extend 找回密码 → 登录

关系选择决策树：

是否必须执行？ → 包含关系（如"支付"必须包含在"订餐"中） 是否条件触发？ → 扩展关系（如"找回密码"扩展"登录"） 是否不同实现？ → 泛化关系（如"信用卡支付"泛化"支付"）

正确建模示例：

usecase "登录系统" as L usecase "找回密码" as FP usecase "学习资料" as S L .> FP : extends S .> L : includes

建模自查清单

在完成用例图后，可使用以下检查项验证模型质量：

1. 用户视角验证

   • 每个用例是否提供用户可感知的价值？
   • 命名是否使用业务术语而非技术术语？

2. 粒度检查

   • 用例是否避免暴露系统内部活动？
   • 是否合并了属于同一目标的细分操作？

3. 关系审核

   • 包含关系是否确实表示必选步骤？
   • 扩展点是否明确标注触发条件？

4. 参与者确认

   • 每个参与者是否都有明确目标？
   • 角色划分是否避免物理实体混入？

5. 一致性检验

   • 相同业务概念在全图命名是否一致？
   • 是否所有关系都有明确语义？

通过持续应用这些原则，开发者可以建立更准确反映用户需求的用例模型，为后续系统设计奠定坚实基础。记住：优秀的用例图应该能让领域专家（而非仅技术人员）理解并认可系统的价值主张。