用例图绘制要点：明确系统使用者与功能

用例图用来回答三个问题：系统给谁用，能做什么，边界在哪里。它适合放在需求分析章节，帮助读者快速理解功能范围。它不负责展示按钮顺序，也不负责说明模块结构，更不应该把数据库表画进去。

一张好的用例图，评阅者一眼能看出学生、教师、管理员这些角色分别能做哪些事；一张差的用例图，通常把所有角色都叫“用户”，再把页面菜单逐条贴进去，看起来很多，实际没有需求分析价值。

这张图由哪些东西组成

本工具的用例图由系统名称、参与者、用例和关系组成。文本 DSL 用缩进表达关系层级：最左侧是参与者，参与者下方写它关联的用例，用例下面可以继续写包含、扩展或泛化关系。

组件	DSL 写法	图里表达什么
系统名称	#系统 在线选课管理系统	用例边界框里的系统名
图标题	#标题 在线选课用例图	论文图题和预览标题
参与者	学生	系统外部的人或外部系统
关联	关联 查询课程	参与者可以使用某个用例
包含	包含 校验学分上限	必然发生、可复用的子用例
扩展	扩展 发起复诊建议	特定条件下才发生的扩展行为
泛化	泛化 维护角色权限	更一般/更具体的用例关系

关系还支持显式方向标记 -> 和 <-，但普通论文场景多数不需要写。工具默认会让包含关系从父用例指向被包含用例，让扩展和泛化按 UML 常见方向处理。

一个可用的文本例子

#系统 论文图表工作台
#标题 项目与导出用例图
学生
  关联 创建项目
  关联 编辑图表
    包含 预览图表
    包含 保存脚本
  关联 导出 Word 文档
    扩展 导出 PDF 预览
管理员
  关联 管理用户权限

这个例子里，“学生”和“管理员”是系统外部角色；“创建项目”“编辑图表”“导出 Word 文档”是系统边界内能力；“预览图表”和“保存脚本”是编辑图表必然包含的行为。

参与者不是岗位表

参与者代表和系统交互的外部角色，可以是人，也可以是外部系统。判断一个角色是否该出现，关键看它是否有不同权限、不同目标或不同交互方式。不要把组织结构里的所有职位都画进去。

例如“学生”“教师”“管理员”通常是合理参与者；“张三”“李四”不是；“普通用户”太泛，如果系统里确实有学生和教师两个不同目标，就不要都合成用户。

include 和 extend 少用，但要用对

包含 表示主用例一定会执行某个子用例，常见于登录校验、权限检查、保存日志。扩展 表示某个条件满足时才额外发生，例如“支付失败后重新支付”“导出失败后查看错误详情”。

不要为了让图更复杂，把所有关系都画成包含。评阅者看到满图 include，通常会怀疑你只是会画线，不一定理解业务。

图后最好补一个用例规约

用例图只能展示概貌。核心用例应该配简短规约，写清前置条件、基本流程、异常流程和后置结果。

用例名称：导出 Word 文档
前置条件：用户已登录，并拥有项目编辑权限
基本流程：选择图表 -> 点击导出 -> 系统生成文件 -> 用户下载
异常流程：脚本解析失败时返回错误提示，不生成文件

这样图和需求说明才能互相支撑。

定稿前检查

• 参与者是否是系统边界外的真实角色。
• 用例名称是否使用动宾短语。
• 参与者和用例之间是否只使用关联关系。
• include/extend/generalization 是否有业务理由。
• 核心用例是否配了文字规约，而不是只有一张图。