同行们先问个扎心的问题你们团队画用例图是不是经常画成“一堆椭圆堆在一起旁边站着几个小人然后评审会上被产品经理和开发两头挑毛病”我从刚入行画到第十年最大感受是——用例图是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 高频错误场景与修正对照为了更直观我把“错误画法”和“修正思路”列一张对照表常见错误错误原因修正方法把“数据库”画成参与者混淆了系统内部模块与外部实体数据库属于系统内部不画在用例图中把“登录”标为所有用例的include“登录”本身是否是公共步骤要看登录是否为每次操作的必经环节登录通常是系统前置条件不是每个用例的公共流程“借书”和“管理员办理借书”画成两个用例把同一业务动作按角色重复拆分一个用例关联多个参与者即可“缴纳罚款”直接连在读者上不标extend忽略触发条件从“还书”用例画extend到“缴纳罚款”用例图里画出“判断读者是否有逾期”这种分支把活动图内容混入用例图分支流程放到活动图或用例说明表修正后你会发现最明显的变化是“图变干净了”。一张合格的用例图不该出现连成蛛网的关系线更不该出现“箭头满天飞”的乱象。6.3 排查技巧通过“动词”和“必须”快速定位问题最后分享一个我做快速评审时用的“动词检查法”看遍所有椭圆里的用例名如果出现了“进行”“处理”“管理”这类动作加名词的组合要警惕粒度过粗如果出现“输入”“点击”“显示”这类描述交互细节的动词要警惕粒度过细。只有表达“用户目标的达成”的动词借、还、检索、下单、续借、预约才是用例的最优选择。检查关系时我习惯给每个include说“必须”这句话“执行A时必须执行B”说不通就改extend给每个extend说“如果”这句话“在某个条件下可能执行B”说不通就改include。我拿这两个句式和新人过一遍关系基本能改对九成。另外还要注意软考答题时让“指出图中错误”的常见类型是参与者位置放错、包含和扩展箭头方向颠倒、用例名称不符合规范。你只要把“谁主动谁被动”“谁必须谁可选”这两个维度想透考场上基本能稳定拿分。写到这用例图的核心内容也就覆盖得差不多了。最后再分享一个我个人的实操习惯每次画完用例图我不会急着输出到文档而是先找一位“完全不懂这个系统”的同事让他看图复述一遍系统有哪些用户、每个用户能干什么。如果他复述的内容和你心里的需求理解一致这张图才算过关。这个方法看着简单但它帮我在项目早期挡掉了好几次重大需求返工比任何检查和评审都来得直接有效。