UML用例图 作者：马育民 • 2026-04-11 18:43 • 阅读：10018 ## 介绍 作为 **程序员、产品经理或需求分析师**，你一定听过“用例图”这个词。它是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的场景。 ## 最后：用例图的核心是“清晰”，不是“复杂” 很多人追求用例图的“专业性”，画得密密麻麻，却忽略了它的本质——传递需求。好的用例图，应该是“新手看了也能懂”，不用太多复杂关系，只要能明确参与者、用例和核心关联，就是合格的。 如果觉得自己画的用例图不规范，或者不知道怎么梳理用例，可以评论区留言你的系统类型（比如电商、管理系统、嵌入式系统），我帮你梳理核心用例和关系~ 觉得有用的话，点赞收藏，下次画用例图直接对照这篇博客，高效不出错！ 原文出处：https://malaoshi.top/show_1GW373krEfwj.html