Posted inAI AI Chatbot AI Visual Modeling

创建用例图的全面指南

🔍 概述

一个用例图是需求工程中的基本建模工具需求工程用于可视化参与者（用户或外部系统）与系统（或其功能）。它帮助利益相关者从功能角度理解系统必须做什么，并作为技术团队与业务用户之间的沟通桥梁。

尽管用例图很简单，但经常被误用原因在于参与者识别不当、用例模糊或关系错误。本指南旨在阐明关键概念，提供一个逐步方法，并指出常见陷阱以避免。

🔑 关键概念

概念 解释
参与者 与系统交互的人类用户、组织或外部系统。在系统上下文中充当“用户”。示例：学生、教师、管理员、支付网关。
用例 系统为参与者执行的特定目标或功能的描述。定义了什么系统做什么，而不是如何. 例如：“注册课程”、“提交成绩”、“生成报告”。
系统边界 区分系统与外部参与者和系统的边界。边界内的所有内容都是系统的一部分。
关联 连接参与者与用例的一条线，表示该参与者可以执行该用例。
泛化 一种关系，其中一个参与者从另一个参与者继承行为（例如，“学生”是“用户”的一种）。
依赖 一种表示一个用例依赖于另一个用例的关系（例如，
“生成报告”依赖于“获取学生数据”）。
包含 一个用例，它需要被要求才能被执行（例如，“提交成绩”包含“验证学生ID”）。
扩展 一个用例，它在特定条件下有条件地增加功能（例如，“发送通知”在成绩低于阈值时扩展“提交成绩”）。

⚠️ 重要提示：用例并非关于功能——它们关注的是功能目标以满足用户需求。

🚀 创建用例图的逐步流程

步骤1：识别参与者

问自己以下核心问题，以识别所有相关的参与者：

问题 为何重要
谁使用主要用例？ 识别主要用户（例如，学生、教授）。
谁需要日常工作的支持？ 找出支持角色（例如，人力资源人员、IT支持人员）。
谁负责系统管理？ 识别管理员角色（例如，系统管理员、数据库管理员）。
系统与哪些外部设备/软件系统交互？ 识别外部系统（例如，电子邮件、支付网关、ERP系统）。
谁对系统的成果感兴趣？ 识别利益相关者（例如，家长、董事会成员）。

📌 提示：从 最关键的用户 开始，逐步向外扩展。使用现实场景或访谈来验证角色识别。

💡 示例：在 大学学生管理系统中，角色可能包括：

  • 学生

  • 教师

  • 学术顾问

  • 行政人员

  • 支付网关

  • ERP系统

步骤2：识别用例

确定角色后，针对每个角色提出以下问题：

问题 目的
角色必须执行的主要任务是什么？ 识别功能目标（例如，注册、选课、查看成绩）。
该参与者是否希望查询或修改系统中的数据？ 表示读/写操作（例如，查看记录、编辑个人资料）。
该参与者是否希望向系统通报其他系统中的变更？ 暗示基于事件的触发机制（例如，当添加课程时通知系统）。
该参与者是否应被告知意外事件？ 表示通知用例（例如，“警告：课程容量已超”）。

📌 使用简洁、目标导向的语言避免使用技术术语。

✅ 良好的用例：“注册课程”
❌ 不良用例：“提交带验证的注册表单” → 过于技术化。

步骤3：在不同层级组织用例

用例可以在不同层级进行建模：

层级 描述
顶层用例 反映业务目标的广泛功能目标（例如，“管理学生记录”）。
细化后的用例 从顶层目标衍生出的详细操作。

🔁 迭代式开发方法:

  1. 从高层次的业务目标开始。

  2. 将其分解为子目标。

  3. 不断细化每个用例，直到其具体且可执行。

📌 示例分解:

  • 顶层：“支持学生管理”

  • 细化：

    • 学生可以注册

    • 学生可以选课

    • 系统存储成绩

    • 系统发送注册确认

这确保了系统满足业务目标同时保持实用且可测试.

步骤4：构建用例图

现在，将参与者和用例放置在图上，并适当地连接它们。

图结构：

[参与者] --> [用例]
    ↑
[包含]     [扩展]
    ↓
[依赖]

绘图规则：

  • 将参与者放置在系统边界之外（通常在左侧、右侧或上方）。

  • 将用例放置在系统边界内部（中心或下方）。

  • 使用实线表示关联。

  • 使用虚线表示依赖关系。

  • 使用包含箭头（→）表示包含关系。

  • 使用扩展箭头（→）表示扩展关系。

  • 避免用例重叠；保持图表清晰易读。

📌 可视化示例（基于文本）：

+------------------+
|   学生           |  --> 注册课程
+------------------+
          |
          v
+------------------+
|   系统           |  --> 存储课程注册信息
| （边界）         |
+------------------+
          ^
          |
+------------------+
|   支付网关       |  --> 处理费用支付
+------------------+

🚨 常见错误：将参与者绘制在系统边界内——这暗示它们是系统的一部分，但实际上并非如此。

此图由 Visual Paradigm AI 聊天机器人生成：

 

🚫 常见陷阱及如何避免

陷阱 为什么是错误的 如何纠正
🚫 过度复杂化参与者 创建过多参与者（例如“约翰·多伊”、“莎拉·史密斯”），而不是对角色进行分组 将相似的角色分组（例如“学生”、“教职员工”）
🚫 使用模糊的用例 使用“管理数据”、“做某事”之类的表述 替换为具体且目标导向的表述（例如“提交课程注册”）
🚫 遗漏依赖关系 未展示一个用例如何依赖于另一个用例 添加包含或扩展在需要时添加关系
🚫 ‘扩展’的错误使用 使用扩展用于常规工作流程 使用包含用于必选步骤；使用扩展仅用于可选或条件性步骤
🚫 忽略外部系统 不包括支付网关、电子邮件等 识别所有外部系统并展示它们之间的交互
🚫 仅使用一个参与者 假设只有一个用户使用该系统 识别所有利益相关者及其需求
🚫 使用技术术语 例如，“更新数据库”，“调用API” 坚持功能行为——“提交请求”更好

✅ 有效用例建模的最佳实践

实践 说明
✅ 从业务目标开始 自上而下建模——与战略目标保持一致。
✅ 尽早让利益相关者参与 访谈最终用户或领域专家以验证用例。
✅ 保持用例相互独立 每个用例应代表一个单一且明确的目标。
✅ 使用现实场景 基于实际用户活动来构建用例（例如，学生选课）。
✅ 与团队验证 与开发人员、测试人员和业务分析师一起审查该图。
✅ 迭代更新 随着需求的演变，以较小的周期逐步完善该图。
✅ 详细记录用例 在单独的文档中包含前置条件、后置条件以及成功/失败标准。

📚 参考资料与进一步阅读

  • [30] 需求工程 – 用例建模的基础性著作。

  • [27] 在软件需求中识别用例 – 从参与者推导用例的实用方法。

  • [16, 40] – 关于需求工程与系统设计的全面文献。

  • IEEE/ISO 标准: ISO/IEC 29148 – 用例规范指南。

推荐书籍：

  • 软件需求：首次就做对 作者：伊恩·斯普劳尔

  • 统一软件开发过程（RUP） – 介绍UML中的用例建模

📝 示例：图书馆管理系统用例图

参与者：

  • 成员

  • 图书管理员

  • 管理员

  • 在线目录系统

  • 支付网关

用例：

  • 成员：

    • 借书

    • 还书

    • 搜索书籍

    • 查看会员状态

  • 图书管理员：

    • 借书

    • 还书

    • 更新书籍记录

    • 生成逾期清单

  • 管理员：

    • 添加新书

    • 管理用户账户

    • 生成年度报告

  • 在线目录系统：

    • 搜索书籍

    • 通知会员新到书籍

  • 支付网关：

    • 处理罚款

    • 处理续借费用

关系：

  • 成员 → 借书 → 包含 → 还书

  • 图书管理员 → 借出 → 延期 → 发送提醒（若逾期）

  • 管理员 → 添加书籍 → 包含 → 更新目录

此图清晰地展示了谁做什么，他们能做什么，以及系统之间如何交互。

🧩 图表定稿前最终检查清单

✅ 我是否识别了所有相关参与者？
✅ 用例是否描述清晰且目标明确？
✅ 所有参与者是否都至少连接到一个用例？
✅ 依赖关系（包含/扩展）是否正确建模？
✅ 是否有遗漏的参与者或用例？
✅ 该图是否易于阅读和理解？
✅ 我是否已与利益相关者进行过评审？

🏁 结论

创建一个 用例图 不仅仅是画线和方框——它是一种 战略过程 需要 对用户需求的深刻理解, 语言的清晰性，以及 对细节的关注.

尽管该图看起来简单， 参与者和用例的误用 会导致系统设计不佳、需求遗漏以及用户沮丧。通过遵循本指南中的步骤——通过现实问题识别参与者，从参与者需求推导用例，并避免常见陷阱——你可以创建准确、可操作且与利益相关者一致的用例图。

✅ 记住： 一个好的用例图讲述一个故事 ——讲述用户如何与系统交互以实现其目标的故事。