介绍
作为 程序员、产品经理或需求分析师，你一定听过“用例图”这个词。它是UML（统一建模语言）中最基础、最常用的图表之一，也是需求分析和系统设计的“入门钥匙”。很多新手觉得用例图简单，却常常画得混乱，要么遗漏核心功能，要么混淆关系逻辑——今天这篇博客，就带你从0到1吃透用例图，不管是工作汇报、系统设计还是面试准备，都能直接用得上。
一、先搞懂：用例图到底用来做什么？
很多人画用例图，只是为了“走个流程”，却不知道它的核心价值。其实用例图的本质，是「从用户视角 描述 系统功能」——它不关心系统内部怎么实现，只关注“谁能用这个系统”“能用到哪些功能”“功能之间有什么关联”。
打个通俗的比方：用例图就像餐厅的“菜单”，参与者是“食客”，用例是“菜品”，系统边界是“餐厅本身”。食客不用知道菜品怎么炒的（系统内部实现），只需要知道自己能点什么菜（用例）、不同菜品之间有没有搭配要求（用例关系），这就是用例图的核心作用。
具体来说，用例图能帮我们解决3个核心问题：
明确系统范围：区分“系统内的功能”和“系统外的实体”，避免需求蔓延；
对齐多方认知：让产品、开发、测试、用户快速达成共识，减少需求歧义；
指导后续工作：为用例文档编写、测试用例设计、代码开发提供基础框架。
二、核心构成：4个元素+4种关系，记牢就不会错
用例图的组成很简单，核心就4个元素+4种关系，不用死记硬背，结合例子一看就懂。
1. 参与者（Actor）——“谁在用系统”
定义：与系统发生交互的外部实体，不是系统内部的模块或功能，常见的有3类：
人：比如“用户”“管理员”“游客”“老师”；
外部系统：比如“支付系统”“短信接口”“数据库系统”；
硬件/时间：比如“传感器”“定时器”（比如定时备份系统的“时间触发器”）。
符号：简笔小人，下方标注角色名（注意：角色名要明确，比如“管理员”而不是“人”）。
2. 用例（Use Case）——“系统能做什么”
定义：系统为参与者提供的完整、独立的功能单元，简单说就是“一个可完成的动作”，命名有个硬性要求：必须是「动宾短语」。
错误示例：“图书”“用户”（名词，不是功能）；
正确示例：“查询图书”“借阅图书”“添加用户”“支付订单”。
符号：椭圆，内部填写用例名，椭圆的大小不影响，只要清晰即可。
3. 系统边界（System Boundary）——“系统的范围在哪里”
定义：用矩形框表示，框内是系统自身的用例，框外是参与者和外部系统，核心作用是“划清边界”，避免把外部功能当成系统内部功能。
符号：矩形，顶部标注系统名称（比如“图书管理系统”“电商下单系统”），用例全部放在矩形内部，参与者放在矩形外部。
4. 关系（Relationship）——“元素之间怎么关联”
这是用例图的“灵魂”，也是新手最容易出错的地方，4种核心关系，用表格一次性讲清楚，建议收藏：
| 关系类型 | 符号 | 核心含义 | 实战示例 |
|---|---|---|---|
| 关联（Association） | 实线（无箭头） | 参与者直接使用用例，是最基础的关系 | 用户 ↔ 登录、管理员 ↔ 添加图书 |
| 包含（Include） | 虚线箭头 + «include» | 基用例必须依赖包含用例，包含用例是基用例的“必选步骤” | 下单 → «include» 验证库存（下单前必须验证库存） |
| 扩展（Extend） | 虚线箭头 + «extend» | 扩展用例是基用例的“可选增强”，基用例可独立执行 | 支付 → «extend» 积分抵扣（支付时可选择用积分，也可不用） |
| 泛化（Generalization） | 实线 + 空心三角箭头（箭头指向父类） | 特殊角色/用例，继承通用角色/用例的所有特性 | VIP用户 → 泛化 → 用户（VIP用户拥有普通用户的所有权限，还多了专属权限） |
💡 重点提醒：包含和扩展的箭头方向不要搞反！包含是“基用例指向被包含用例”，扩展是“扩展用例指向基用例”，记不住就想：“包含是必须的，基用例要‘包含’它；扩展是可选的，扩展用例‘扩展’基用例”。
三、绘制步骤：3步搞定，新手也能画规范
强烈推荐下面视频，8分钟掌握用例图
https://www.bilibili.com/video/BV1qN41177fw/?spm_id_from=333.1387.favlist.content.click
很多人画用例图混乱，是因为没有固定步骤，记住这3步，不管什么系统，都能快速画好：
第一步：确定参与者（谁在用）
先列出所有与系统交互的外部实体，问自己3个问题：
谁会使用系统的核心功能？（比如图书管理系统的“读者”）；
谁会管理系统？（比如“管理员”）；
系统需要和哪些外部系统/硬件交互？（比如“支付系统”“传感器”）。
注意：不要把系统内部的模块（比如“订单模块”“用户模块”）当成参与者！
第二步：梳理用例（能做什么）
针对每个参与者，列出他能使用的“完整功能”，记住2个原则：
用例必须是“完整的动作”，比如“借阅图书”（从查询到确认借阅的完整流程），而不是“点击借阅按钮”（只是一个步骤）；
用例必须是“系统能提供的”，比如用户“修改密码”是系统功能，用户“忘记密码”不是用例（忘记密码是用户的行为，系统对应的用例是“找回密码”）。
第三步：建立关系（怎么关联）
先给每个参与者和对应的用例画“关联”（实线），再梳理用例之间的关系：
如果A用例必须执行B用例，就用“包含”关系（A→«include»B）；
如果A用例可以选择执行B用例，就用“扩展”关系（B→«extend»A）；
如果有特殊角色/用例，继承通用角色/用例，就用“泛化”关系（特殊→通用）。
四、实战案例：图书管理系统用例图（可直接复用）
光说不练假把式，以最常见的“简易图书管理系统”为例，完整演示用例图的绘制过程，你可以直接照搬这个逻辑，替换成自己的系统。
1. 确定参与者
读者（使用系统借阅、归还图书）、管理员（管理图书和用户）、图书数据库（外部系统，存储图书信息）。
2. 梳理用例
读者：查询图书、借阅图书、归还图书、找回密码；
管理员：添加图书、删除图书、修改图书信息、管理读者信息；
图书数据库：同步图书信息（被管理员用例包含）。
3. 建立关系
关联：读者↔查询图书、读者↔借阅图书、管理员↔添加图书等；
包含：借阅图书→«include»验证读者权限；添加图书→«include»同步图书信息；
扩展：归还图书→«extend»缴纳滞纳金（逾期归还时才执行）；
泛化：无（如果有“VIP读者”，可以泛化“读者”）。
这里给大家一个简化版的用例图描述（可直接复制到绘图工具中）：
参与者：读者、管理员、图书数据库
系统边界：图书管理系统
用例：查询图书、借阅图书、归还图书、找回密码、添加图书、删除图书、修改图书信息、管理读者信息、验证读者权限、同步图书信息、缴纳滞纳金
关系：
读者 -- 查询图书
读者 -- 借阅图书
读者 -- 归还图书
读者 -- 找回密码
管理员 -- 添加图书
管理员 -- 删除图书
管理员 -- 修改图书信息
管理员 -- 管理读者信息
借阅图书 --<<include>>-- 验证读者权限
添加图书 --<<include>>-- 同步图书信息
缴纳滞纳金 --<<extend>>-- 归还图书
图书数据库 -- 同步图书信息
五、常见误区：避开这4个坑，用例图更规范
新手画用例图，很容易踩以下4个坑，对照检查，避免出错：
坑1：用例命名用名词，不是动宾短语
错误：“图书”“订单”“用户”；正确：“查询图书”“创建订单”“添加用户”——用例是“动作”，不是“事物”。
坑2：把系统内部模块当参与者
错误：把“订单模块”“用户模块”当成参与者；正确：参与者必须是外部实体，内部模块是系统的一部分，不用画在系统边界外。
坑3：包含和扩展关系搞反
错误：把“验证库存”→«include»“下单”；正确：“下单”→«include»“验证库存”（基用例指向被包含用例）。
坑4：用例太细或太粗
太细：把“点击借阅按钮”“输入借阅数量”当成用例（这是用例的步骤，不是用例本身）；
太粗：把“图书管理”当成一个用例（这是一个功能模块，不是独立的功能单元）。
六、常用绘图工具推荐（新手友好）
不用纠结工具，选一个上手快、免费的就好，推荐3个常用的：
DrawIO（免费）：浏览器端可用，拖拽式操作，支持导出PNG、SVG，适合快速绘制；
StarUML（付费，有免费试用）：专业UML工具，功能齐全，适合复杂系统的用例图绘制；
Visio（付费）：微软旗下工具，和Office兼容，适合需要插入Word、PPT的场景。
最后：用例图的核心是“清晰”，不是“复杂”
很多人追求用例图的“专业性”，画得密密麻麻，却忽略了它的本质——传递需求。好的用例图，应该是“新手看了也能懂”，不用太多复杂关系，只要能明确参与者、用例和核心关联，就是合格的。
如果觉得自己画的用例图不规范，或者不知道怎么梳理用例，可以评论区留言你的系统类型（比如电商、管理系统、嵌入式系统），我帮你梳理核心用例和关系~
觉得有用的话，点赞收藏，下次画用例图直接对照这篇博客，高效不出错！