UML用例图实战指南：从需求分析到软考真题全解析

同行们，先问个扎心的问题：你们团队画用例图，是不是经常画成“一堆椭圆堆在一起，旁边站着几个小人，然后评审会上被产品经理和开发两头挑毛病”？我从刚入行画到第十年，最大感受是——用例图是UML里最“轻”的一张图，但恰恰是这张图最能暴露需求分析水平。它不画数据库、不画类结构、不画时序，它只回答一个问题：系统到底要为谁、提供哪些可见的价值。就这么一个问题，绝大多数项目在开工前都说不清楚。

所以这个系列写到第4篇，我特意把用例图单独拿出来展开讲。这篇不是教科书式的图元罗列，而是结合我这几年做系统设计、看别人画图、以及带新人复盘时踩出来的实战经验，重点讲清楚用例图的核心价值、标准画法、常见误区和软考真题的解题套路。如果你最近在准备软考中级软件设计师，或者正被课程设计（比如经典的图书管理系统用例图）折磨，这篇的内容应该能直接帮到你。

1. 用例图不是“画图”，而是需求对齐工具

很多人第一步就走偏了，把用例图当成一种“交付物”，画完给老师或领导看一眼就完事。实际上，用例图真正的作用是在项目早期强制所有角色把话说清楚：谁在用系统，系统提供什么功能，功能之间是什么关系。它是一张“需求契约图”，不是“架构设计图”。

1.1 用例图在整个UML体系中的定位

UML提供了十几种图，但用途分两大类：结构图和行为图。用例图属于行为图里最“顶层”的一类——它描述的是系统外部的行为，也就是用户能感知到的功能，而不是内部实现细节。类图画的是“有什么东西、之间什么关系”，时序图画的是“一次交互按什么顺序发生”，状态图画的是“一个对象有哪些状态、怎么迁移”。而用例图回答的是更靠前的问题：系统到底边界在哪，谁来触发交互，每个交互产生什么结果。

这个“靠前”决定了它在项目流程里的位置：需求分析阶段就要画用例图，画完用例图才能谈类图、时序图。我见过不少团队跳过用例图直接画类图，结果类图改了八版，因为大家心里对“这个系统要干什么”根本没有统一答案。用例图的价值不在于图本身有多漂亮，而在于画它的过程逼着团队把“范围”和“功能清单”敲定下来。

1.2 为什么很多团队画不好用例图

原因归纳起来就三条：第一，把用例图当成“椭圆贴纸”，以为往图上随便放几个功能名称就算完事；第二，分不清参与者和用例的边界，把人名、角色、外部系统混在一起；第三，关系乱用，include、extend、泛化随意连，画出来的图外行看着热闹，内行看着头疼。

我这几年带团队评审设计文档，每次看到用例图都要先问三个问题：谁是主参与者？他通过这个系统达成什么目标？哪些功能是必须的、哪些是可选的？如果画图的人回答不上来，说明需求本身还没想清楚，图只是把“没想清楚”画了出来而已。

2. 用例图的“五要素”再拆解

用例图的基础元素我在系列第1篇里提过，但这里必须展开细讲。因为“认识符号”和“会用符号”是两码事，尤其是关系那部分，80%的错误都出在包含和扩展上。

2.1 参与者：不是“人”，而是“角色”

参与者（Actor）是系统外部与系统交互的实体，可以是人，也可以是外部系统、硬件设备、定时器等。这里最容易犯的错误是把“人”直接写上去，比如“张三”“李四”。正确的是写角色，比如“读者”“图书管理员”。角色代表的是一类拥有相同权限和目标的交互主体，不是具体某个个体。

判断一个东西是不是参与者，有个很实用的标准：它在系统边界之外，并且主动发起交互。比如图书管理系统里，“读者”发起借书请求，是参与者；“图书管理员”处理还书、罚款，是参与者；如果系统要对接图书馆门禁设备，设备自动记录入馆状态，那“门禁系统”也是参与者。反过来，数据库、打印机这些“被系统调用的东西”通常不算参与者，因为它们在系统边界内部。

还要注意参与者是有“主次”之分的。主参与者是发起用例以实现目标的角色，比如读者借书；辅助参与者是配合完成用例的角色，比如支付网关接收罚款。画图时主参与者通常放在系统边界左侧，辅助参与者放右侧，这个约定不是形式主义，而是为了看图时能一眼看出核心用户是谁。

2.2 用例：一个用例代表“一个完整的目标”

用例（Use Case）是系统提供的一个独立功能单元，注意“独立”和“完整”这两个词。每个用例应该能被参与者在一次交互中感知到一个完整结果。比如“借书”是一个用例，因为读者执行它后得到一个确定结果：借书成功或失败；“查询图书”是另一个用例，读者得到的是图书信息和状态。

实操里很多人把用例粒度拆得特别碎，比如“输入账号”“点击登录”“验证密码”各画一个用例。这是典型的错误——这些只是“登录”这个用例的内部步骤，不是独立的目标。反过来，也有人把用例合并得特别大，比如“图书管理”一个椭圆把增删改查全塞进去，这样粒度太粗，无法指导后续设计。判断粒度是否合适，我常用的方法是“一分钟测试”：如果让一个不懂系统的路人看这个用例名，他能立刻说出“这功能是给谁用的、结果大概是什么”，粒度基本合适。

一个系统通常画10到30个用例比较常见，少于10个说明粒度可能太粗，多于30个说明你很可能把内部步骤误当成了用例。

2.3 关系：关联、包含、扩展、泛化是最容易翻车的地方

用例图的关系分四种：关联（Association）、包含（Include）、扩展（Extend）、泛化（Generalization）。我和很多同行交流，大家普遍觉得包含和扩展最像“双胞胎”，用错率极高。这里我给出一个特别实用的区分方法：包含关系是“必须做的公共步骤”，扩展关系是“可选的、满足条件才发生的补充流程”。

具体来说：

• 关联：参与者和用例之间的连接线，表示“谁发起这个功能”。这是最基本的关系，注意是实线，不是箭头或虚线。
• 包含（include）：从基础用例指向被包含用例的虚线箭头，箭头上标<<include>>。含义是：执行基础用例时，一定会执行被包含用例。比如“借书”一定会执行“验证读者身份”，所以借书包含验证身份。这是一个“必不可少”的关系。
• 扩展（extend）：从扩展用例指向基础用例的虚线箭头，箭头上标<<extend>>。含义是：在满足特定条件时，才会额外执行扩展用例。比如“还书”在“超期”条件下可能触发“缴纳罚款”，所以缴纳罚款是还书的一个扩展。
• 泛化（Generalization）：带空心三角箭头的实线，用于参与者和用例之间的继承。例如“学生”泛化“读者”，“电子图书借阅”泛化“借阅”。

我用一个生活化例子来帮新人记：去餐厅吃饭，“点菜”这个动作一定会包含“看菜单”（include）；但如果菜太辣，你追加“点一瓶饮料”就是扩展（extend）——不是你每次吃饭都会做的事，只在“菜辣”这个条件下发生。

2.4 系统边界：画出系统“管什么、不管什么”

系统边界在用例图中是一个矩形框，用例写在框内，参与者写在框外。它虽然简单，却承担着需求范围管理的重要职责。很多需求扯皮（比如“读者能不能自己修改图书信息”）其实画一下边界就能解决：修改图书信息如果写在边界内，就代表系统要支持这个能力；写在边界外，就表示这是管理员线下做的事。

我见过一个很不好的习惯：把用例图里的系统边界框画完就不管了，从来不标系统名称。规范的做法是在框顶部的“系统名”位置写上系统名称和版本信息，这样这张图才能真正作为需求文档的一页使用。

3. 经典实战：从零拆解图书管理系统用例图

图书管理系统是软考、课程设计里出现频率最高的题目之一。拿它当案例，是因为它的参与者清晰、用例边界好找，非常适合用来练手。但正因为太经典，很多人反而画得很“套路”——借书、还书、续借、查询、管理图书，五个椭圆一排完事。这种图能得基础分，但拿不到高分，因为关系没画对、边界不清楚、扩展用例缺失。

3.1 参与者识别与用例清单梳理

图书管理系统的参与者，至少有以下角色：读者（借阅者）、图书管理员、系统管理员。如果系统有集成外部支付或门禁，还要考虑支付平台、门禁系统等外部参与者。

用户可见的核心功能我一般按业务流程从“读者找书”到“借书”再到“还书”来梳理：

• 读者：检索图书、查看图书详情、预约图书、借书、还书、续借、查看个人借阅记录、缴纳罚款（扩展）
• 图书管理员：处理借书、处理还书、处理续借、图书入库、图书下架、读者管理、罚款管理
• 系统管理员：账号管理、权限配置、数据备份、系统参数设置

这里要特别注意，网上很多资料会把“借书”和“处理借书”当成两个用例，一个挂在读者下，一个挂在管理员下。这其实是“过度细分”。同一个业务流程，读者发起借书、管理员在系统里完成借书登记，本质上是同一个用例的两种触发方式，规范的做法是画一个“借书”用例，关联到两个参与者上。如果你把它拆成两个用例，后续画时序图和类图时会出现大量冗余，维护起来非常痛苦。

3.2 用include和extend理清用例间的关系

图书管理系统的用例关系是画图水平的“分水岭”。拿“借书”这个用例举例，它内部一定要经过“验证读者身份”和“更新图书库存”这两个公共步骤，所以写<<include>>；，“借书”这个用例并不是每次都需要“预约取书”这个流程——只有当图书已被预约时才触发“预约取书”，所以“预约取书”是“借书”的扩展。

再看“还书”，它通常会包含“检查超期状态”（include）。但如果检查发现超期，系统需要触发“缴纳罚款”，这一流程不是每次还书都发生，所以“缴纳罚款”是“还书”的扩展（extend）。这个“检查超期—判断条件—扩展触发”的模式，是整个系统里最容易考到的知识点，也是实际需求分析里最容易遗漏的地方。

把关系补全后，这个系统的核心用例图逻辑大致如下：

• 读者 —— “借书”（含验证读者身份、更新库存、条件触发预约取书）
• 读者 —— “还书”（含检查超期、条件触发缴纳罚款）
• 读者 —— “续借”（含验证读者身份、更新应还日期）
• 读者 —— “检索图书”（含查看图书详情）
• 读者 —— “预约图书”（含检查库存状态）
• 管理员 —— “图书管理”（含图书入库、下架、信息修改）
• 管理员 —— “读者管理”（含读者注册、挂失、注销）
• 系统管理员 —— “系统维护”（含账号管理、权限配置、数据备份）

3.3 画图书管理系统用例图的实操建议

这部分是我被问得最多的：从哪开始画？用什么工具？怎么保证不漏功能？

我的建议是：别急着开画图软件，先用三张纸打草稿。第一张纸列参与者和每个参与者“想达成什么目标”；第二张纸把目标拆成“必须功能”和“可选功能”；第三张纸才画系统边界并摆放元素。这样画出来的图才能经得起“为什么没有某某功能”的追问。

画图工具方面，直接用draw.io或ProcessOn都行，收费用具其实无所谓，关键是别把时间耗在调格式上。我自己的偏好是：先用纯文本列表把“actor-用例-关系”三元组列出来，再导入画图工具。比如这样组织：

读者 - 借书（include验证身份，include更新库存，extend预约取书） 读者 - 还书（include检查超期，extend缴纳罚款）

这样一边整理一边就能发现遗漏：比如“续借是否需要检查超期”？如果续借发生在已超期状态，系统应该先要求读者处理逾期，这又可以扩展一个“处理逾期”。这些细节，光看图是看不出来的，必须在文字清单阶段就过一遍。

4. 软考中级软件设计师用例图真题套路拆解

很多考软考的朋友跟我反馈：用例图的知识点考得不难，但就是容易错在“include/extend判断”和“参与者归属”上。这里我把真题常见的考法总结成套路，看完直接能上手答题。

4.1 软考用例图题型的典型考法

软考中级软件设计师的用例图题目主要出在上午客观题和下午案例分析题。上午题一般给一个场景，让选出“哪项描述正确的是”，考概念辨析；下午题给一段需求说明和残缺的用例图，让补充参与者、用例或关系，有时候还会考“某个功能应建模为include还是extend，理由是什么”。

从历年真题看，高频考点集中在这几个位置：一是参与者识别，题干里描述了一个“外部系统”和一个人工角色，干扰选项把角色写成人名；二是include和extend的判别，题干会写“所有预约操作前需验证用户身份”和“当库存不足时触发缺货登记”之类的话，让你判断归属；三是用例命名的规范性，有时候选项里出现“数据库操作”“更新界面”这类明显不是用例的名词，直接排除。

4.2 真题风格案例：从题干到答案的完整推理

我拿一个非常接近软考风格的场景来演示推理过程。题干大致描述：“某网上图书商城系统，读者可以检索图书、下单购买。所有订单提交前必须验证用户登录状态。当用户账户余额不足时，订单支付将跳转到充值页面。读者可以查看历史订单，管理员可以管理图书上下架。”

这种题通常会问：用例“提交订单”与用例“验证登录”之间是什么关系？用例“跳转充值页面”与“支付订单”之间是什么关系？

推理思路如下：题干里“所有订单提交前必须验证登录状态”，说明“验证登录”是“提交订单”的必经步骤，因此是包含关系（<<include>>）。再看“余额不足时”才“跳转充值页面”，这是一个条件触发，不是每次支付都发生，所以是扩展关系（<<extend>>）。

这类题的答题技巧是：划“必”字。题干中出现“必须”“所有...都”“需先”时，大概率指向include；出现“如果...则”“当...时”“可选”“额外”时，大概率指向extend。用这个方法应付上午题基本不会错。

4.3 软考避坑：两个最容易丢分的小细节

第一个坑是没有把“外部系统”识别成参与者。题干一说“通过与支付平台对接完成支付”，很多人立刻把“支付平台”当成一个用例。实际上支付平台对当前系统来说是外部实体，它主动或被动参与交互，应当建模为参与者，而不是用例。鉴别方法是：它能独立于当前系统存在，且不是系统内部功能模块。

第二个坑是在用例图上画数据流或内部处理步骤。有些同学在用例图里顺手画了“读数据库”“计算价格”之类的小方框或注释，这会直接扣分。用例图只关注外部可见的功能，内部实现细节是类图、时序图、活动图的事。画用例图就把它当成“用户眼中的系统全貌”，不要把“系统”画进“系统边界”内部。

5. 用例图的进阶用法与管理方法

前面讲的都是“怎么画”，这节聊聊“怎么用”。因为很多团队画完用例图就束之高阁，根本没有把它当设计依据。其实用例图做得好，可以直接推导出测试用例、验收标准、甚至权限矩阵，价值非常大。

5.1 从用例图推导验收标准和测试场景

每个用例背后都对应着输入、处理、输出和异常分支。画完用例图，我会顺手在用例名后面补充“用例说明表”，表里至少包含：参与者、前置条件、主成功场景、可选分支、异常分支。比如“借书”这个用例，主成功场景是“验证通过→更新库存→记录借阅信息→返回成功”；可选分支是“预约取书”；异常分支是“读者有逾期未还图书、账号挂失、馆藏无副本”。

有了这个表，测试工程师可以直接把主成功场景变成一条主流程测试用例，把每个分支拆成若干条异常测试用例。这比看图猜功能靠谱得多，也是用例图从“文档”变成“工具”的关键一步。

5.2 用例图与UML其他图的衔接

我见过不少优秀的项目文档，用例图后面紧跟的是一张类图和几张时序图。这不是偶然，而是有内在逻辑的：用例图中的每个“参与者-用例”关联，往后就会变成时序图中的一个交互链路；用例图中的“验证读者身份”这种被包含的公共用例，往往对应类图里的一个服务类或接口。

如果你发现用例图里的某个公共用例，在后续类图设计中找不到归属，说明类图漏了类；反过来，如果类图里某个类在用例图中找不到对应场景，说明这个类可能是过度设计。这就是我常说的“图与图互相审讯”，比任何代码评审机制都管用。

5.3 不同规模项目，用例图的“画法尺度”不同

我经常被问：一个敏捷迭代里，用例图需要画多细？我的经验是：项目越小，用例图越要“抓大放小”；项目越复杂，用例图越要“分层的画”。一个单片系统可以用一张图画完所有核心用例，但一个中大型项目，每个业务模块最好各画一张用例图，再加一张总览级的“系统级用例图”。

比如图书管理系统，你可以先画一张总览图，列出所有核心业务用例；再分别画“流通管理用例图”“读者管理用例图”“系统管理用例图”。这样既能让领导快速看到系统全貌，又能让开发人员拿到模块级的细节。这里还要注意，用例图与包图可以配合使用：当模块多时，把用例按包组织，每个包对应一组用例图，整体结构就会非常清晰。

5.4 工具选型与协作模式

工具这块我踩过不少坑。最早用Visio画图，导出图片很漂亮，但多人协作是噩梦，改一版重新发图，版本管理一片混乱。后来换用Draw.io，好处是免费、开源、支持直接在代码仓库里存XML文件做版本管理。PlantUML我也用过，能用文本描述生成用例图，适合喜欢“万物皆代码”的团队。如果是远程协作，ProcessOn、boardmix这类在线工具体验也不错。

不管用哪个工具，我强烈建议遵循一条原则：图和源文件要一起保存。只导出PNG放到文档里，后面想改却找不到源文件的痛苦，画过图的人都懂。另一个协作建议是：用例图评审时不要“对着图讲功能”，而是让评审人“拿着场景找路径”。比如“读者想借一本已被预约的书，图上能看到什么分支”，这种追问能很快找出关系的缺失。

6. 常见错误、排查技巧与速查表

这节把我在代码评审和软考辅导中碰到的高频问题集中整理成速查表，同时给几个“一眼发现问题”的小技巧，方便你画完图后自查。

6.1 用例图自查清单

画完用例图，按下面清单过一遍，可以规避大部分丢分或打回问题：

• 参与者是否都是“边界外”的角色？有没有把普通用户人名写上去？
• 每个用例是否都表达了一个“完整目标”？有没有“更新界面”“打印报表”这种内部步骤混入？
• 系统边界是否绘制清楚，有没有把参与者放进边界里？
• 包含关系是否真正是“每次必做”？扩展关系是否真正是“条件触发”？
• 用例命名是“动词+名词”结构吗？有没有用“图书管理”这种过粗的名字，或者“点击按钮”这种过细的名字？
• 线型是否正确：关联是实线、include/extend是虚线箭头、泛化是空心三角？

这里还要强调一点：很多人分不清“包含”和“扩展”时，会想着“我标不标关系不都一样吗”。这个想法很危险。用例图的关系标注直接决定后续工作量评估和测试用例设计。一个被误标为extend的include（比如把“验证登录”标成extend），会让开发误以为验证登录是可选的，后果不堪设想。

6.2 高频错误场景与修正对照

为了更直观，我把“错误画法”和“修正思路”列一张对照表：

修正后你会发现，最明显的变化是“图变干净了”。一张合格的用例图，不该出现连成蛛网的关系线，更不该出现“箭头满天飞”的乱象。

6.3 排查技巧：通过“动词”和“必须”快速定位问题

最后分享一个我做快速评审时用的“动词检查法”：看遍所有椭圆里的用例名，如果出现了“进行”“处理”“管理”这类动作加名词的组合，要警惕粒度过粗；如果出现“输入”“点击”“显示”这类描述交互细节的动词，要警惕粒度过细。只有表达“用户目标的达成”的动词（借、还、检索、下单、续借、预约）才是用例的最优选择。

检查关系时，我习惯给每个include说“必须”这句话：“执行A时，必须执行B”，说不通就改extend；给每个extend说“如果”这句话：“在某个条件下，可能执行B”，说不通就改include。我拿这两个句式和新人过一遍关系，基本能改对九成。

另外还要注意，软考答题时让“指出图中错误”的常见类型是：参与者位置放错、包含和扩展箭头方向颠倒、用例名称不符合规范。你只要把“谁主动谁被动”“谁必须谁可选”这两个维度想透，考场上基本能稳定拿分。

写到这，用例图的核心内容也就覆盖得差不多了。最后再分享一个我个人的实操习惯：每次画完用例图，我不会急着输出到文档，而是先找一位“完全不懂这个系统”的同事，让他看图复述一遍系统有哪些用户、每个用户能干什么。如果他复述的内容和你心里的需求理解一致，这张图才算过关。这个方法看着简单，但它帮我在项目早期挡掉了好几次重大需求返工，比任何检查和评审都来得直接有效。