UML用例图怎么画？参与者、include/extend与图书管理系统实战

带过几届做课程设计的学生之后，我发现一个相当稳定的规律：用例图画得最花哨的那组，需求文档往往写得最烂；而真正把系统想明白了的那组，用例图看起来反而朴素得有点丑。用例图这个东西门槛极低，画图工具里拖几个椭圆、连几条线就能交差，但要画到能过评审、能直接支撑后面的类图和时序图、能在软考中级软件设计师的题目里稳住分数，中间隔着的是一整套判断标准。这篇就把这套标准拆开讲，从"谁算参与者"这种基础问题，一直讲到"图书管理系统用例图"这种具体场景的成图过程，最后再聊聊评审时最容易被挑出来的毛病。不管你是第一次画用例图的新手，还是已经画过几张但总觉得不对劲的人，应该都能找到能直接落地的东西。

1. 用例图到底在画什么：先破除三个最常见的误解

1.1 用例图不是流程图，也不是功能清单

用例图在 UML 的行为图家族里，描述的是"谁在用系统"和"用系统做什么"，它压根不负责回答"系统内部怎么一步步执行"。这个定位一确定，很多画法上的争论就自动消失了——顺序、判断、循环这些东西天生就不该出现在用例图里。我见过不少同学把"输入账号密码、校验、跳转首页"画成一串带箭头的椭圆，交上去看着像用例图，实际上是退化版流程图，评审的人一眼就能认出来。

另一个极端是把用例图画成菜单树。"用户管理"下面挂"增加用户""删除用户""修改用户""查询用户"，"删除用户"再挂"批量删除""单个删除"。这种画法语法上没毛病，但信息量接近零，本质上是把需求文档里的功能列表原封不动搬进了椭圆。用例图真正的价值在于同时说清三件事：系统的职责边界在哪、外部有哪些角色、每个角色能触发哪些完整目标。菜单树只呈现了第三件事里最浅的一个切面。

还有一个更隐蔽的误解，是觉得用例图必须一次画到位。实际项目里它一般要迭代三轮以上：第一轮只把参与者和主要用例铺出来，第二轮补关系（关联、包含、扩展、泛化），第三轮做减法和重命名。我自己的习惯是第二轮才动关系，因为过早加 include 会把注意力从"业务目标"拐到"代码复用"上，那是设计阶段该操心的事，放在需求阶段只会让图变复杂。

1.2 参与者不一定都是"人"

参与者的定义是"与系统交互的外部实体"。它可以是一个人，也可以是外部系统、硬件设备，某些场景下甚至可以是时间。放到图书管理系统里，"借阅者""图书管理员""系统管理员"是人；"校园一卡通接口""短信通知平台""支付渠道"是外部系统；而"每月自动生成逾期清单"这类用例，真正的触发者是时钟，不是管理员。

这一点在软考里经常被拿去出题。题干写"系统每天凌晨自动统计前一天的借阅数据并生成报表"，问参与者是谁。不少人下意识写"系统管理员"，但管理员只是"查看报表"的参与者，"生成报表"的触发者应该是"时间"或"定时器"。这道题考的就是有没有把"触发用例的东西"和"消费用例结果的东西"分开看。

还有一条硬规则：参与者必须站在系统边界之外。如果某个角色本身就在系统内部，比如"数据库""日志模块"，那它顶多算内部组件，不该出现在用例图上。判断办法很土但很管用——把系统画成一个方框，真正的参与者一定在框外，框里的全都是系统自己的事。

1.3 用例粒度失控是用例图最大的死因

粒度这件事用同一个例子讲最清楚。图书管理系统里，"借书"可以是一个用例，也可以拆成"验证读者身份""检查借阅额度""登记借阅记录""更新图书状态"四个用例。到底哪种对？

判断依据是"这个用例是否给参与者带来一个可观测、有价值的结果"。读者来借书，他要的结果是书借到手了，中间那几步对他来说是系统内部的事，所以"借书"作为单个用例就够了。反过来，如果图书管理员需要单独执行"检查借阅额度"——比如读者跑到柜台问"我还能借几本"——那它才独立成一个用例。

我在评审里总结过一条土办法：凡是参与者不会主动说"我要做这件事"的动作，基本都不该是独立用例。按这条筛一遍，通常能砍掉三到四成的椭圆，图立刻清爽很多。

2. 从一段需求描述里抠出参与者与用例的完整流程

2.1 先画边界框，再找框外的人

拿到一段需求文字，别急着找动词，先画那个方框。方框代表系统本身，方框的名字就是系统的名字。这一步看着像形式主义，实际上是强制自己回答一个要命的问题：这套东西到底管到哪儿为止。很多用例图返工，根源就在边界没定，一会儿把第三方支付算进来，一会儿又把校园卡中心算出去，改到最后整张图自相矛盾。

框画好之后，站在框外面往里看，凡是需要跟这套系统的功能打交道的人或外部系统，全列成候选人。列的时候不要筛选，先把能想到的都写下来，包括不常见的角色，比如"审计人员""外部监管接口"。第二步再做减法：某个候选人如果从头到尾没有任何一个用例跟他交互，那他就不是参与者，删掉。

这里有个经验值可以参考。一个中等规模的业务系统，参与者数量通常在 3 到 7 个之间。如果你的候选名单超过十个，多半是把内部角色或者模块名字当成了参与者；如果只有一两个，那可能是漏掉了管理员、外部接口或者定时触发者。

2.2 动词筛选法：从需求句子里"捞"用例

边界和参与者定了，接下来从需求文字里捞用例。土办法是把每一句需求的主谓宾拆开，主语负责映射参与者，谓语动词负责映射候选用例。比如"读者可以通过系统查询图书的借阅状态"，主语是读者，动词是查询，宾语是借阅状态，候选用例就是"查询借阅记录"。

捞完之后要合并同类项。需求文档经常把一件事拆成好几句话写，比如"读者可以查看自己的借阅记录""读者可以查看借阅到期时间""读者可以查看是否逾期"，这三句其实是同一个用例的不同信息项，合并成"查询借阅记录"一个椭圆就够了。

再往下要做的是补漏。书面需求往往只写了正常流程，异常和触发式场景经常被漏掉。这时候可以问自己几组问题：有没有需要定时触发的动作？有没有需要外部系统通知才发生的事？有没有只有特定角色才能做的操作？把这几类过一遍，通常能补出三到五个被遗漏的用例。

2.3 用例命名：动宾结构，站在参与者视角

命名是用例图里最容易被忽视、又最容易被扣分的地方。规范只有一个：用"动词加名词"的动宾结构，并且站在参与者的视角描述他达成的目标。下表是我经常拿去给学生做对照的取名清单，左边是常见的错误写法，右边是改完之后的样子。

最后一行单独说一下。"登录"要不要画，争论了很久。我的处理方式是看它有没有承载业务价值：如果登录之后能做的事彼此独立、登录本身不产生业务结果，那就省略；如果系统里存在"普通读者"和"VIP读者"这类由登录区分的分支流程，那保留也无妨。软考的标准答案倾向是省略，因为登录属于系统级公共功能，画上去会让图变啰嗦。

2.4 拿图书管理系统跑一遍第一轮

把上面三步合起来，用图书管理系统做一次完整的第一轮拆解。参与者先分成三类：读者侧（借阅者）、管理侧（图书管理员）、系统侧（系统管理员），再加上两个外部系统参与者（校园一卡通接口、短信通知平台），以及一个非人的触发者——时钟。

用例部分，把需求里所有动作捞出来再合并，得到的大致清单是：借书、还书、续借、预约图书、查询图书、查询借阅记录、缴纳逾期罚金、维护图书信息、维护读者信息、统计借阅报表、生成逾期清单、发送逾期提醒。这十二个用例覆盖了系统的绝大部分业务目标，而且每一个都能对应到某个参与者主动发起的意图，颗粒度基本一致。

第一轮画完就可以停下来看一眼：有没有哪个椭圆特别大，明显能拆成好几件事？有没有哪个椭圆特别小，小到参与者根本不会专门发起？有没有参与者只连了一条线，孤零零挂在旁边？这三类问题各修一遍，图就站得住了。

3. 关联、包含、扩展、泛化：四种关系的判定标准

3.1 关联关系：为什么那条直线不该加箭头

参与者和用例之间的那条线叫关联，表示参与者能触发这个用例。它通常画成一条实线，不加箭头或者加一个空心箭头都行——UML 2.x 里两种画法都合法，但考试和评审场合我更推荐不加箭头，也就是双向关联的默认画法。原因是关联本身只表达"可以交互"，不表达控制流方向，加了箭头容易让人误以为存在调用关系。

真正容易出错的是参与者自己之间的连线。有些同学想表达"图书管理员可以操作系统管理员的功能"，就直接在两个参与者之间画一条线，这是错的。参与者与参与者之间只允许泛化关系（空心三角箭头的继承），不能有普通关联。如果两个角色之间真的有交互，那属于业务层面的事，应该在需求描述里说清楚，而不是塞进用例图。

3.2 include：被抽出来的公共行为

包含关系（«include»）解决的是"多个用例里重复出现的公共片段"。判定条件有两个，缺一不可：一是这段行为被两个以上的用例使用，二是这段行为本身是一个完整的功能单元，可以被独立命名。

画法上有个经典易错点：箭头方向是从「基用例」指向「被包含用例」，也就是说，发起方指向被复用的那一方。比如"借书"和"续借"都需要先验证读者状态，那应该是"借书"和"续借"各画一条虚线带 «include» 标签，箭头指向"验证读者状态"。很多人把箭头画反，写成"验证读者状态"指回"借书"，这在语义上完全说不通。

再强调一遍使用门槛：如果某段行为只被一个用例使用，那就算它再独立，也不该拆出去做 include，直接写成该用例内部的一个步骤就行。为了"看起来专业"而滥用 include，是用例图退化成流程图的头号原因。

3.3 extend：有条件才发生的可选行为

扩展关系（«extend»）表达的是"在特定条件下才插入的可选行为"。判定关键在"条件"两个字：基用例在通常情况下能独立完成，扩展用例只在条件成立时才追加进去，而且基用例本身不知道扩展的存在。

箭头方向和 include 正好相反：从「扩展用例」指向「被扩展的基用例」。举例来说，"还书"这个用例正常走完就结束了，但如果读者已经逾期，系统需要额外走一遍"缴纳逾期罚金"，那"缴纳逾期罚金"就是扩展用例，虚线带 «extend» 标签，箭头指向"还书"。整条链路读下来就是：正常情况还书流程闭环，逾期这个附加条件触发时才多出一段。

include 和 extend 的分水岭，说白了就一句话：被拆出来的那段行为，是每次都要执行，还是只在条件成立时才执行？每次都要执行的用 include，有条件的用 extend。这个判断标准朴素但极其好用，考场上比什么都快。

3.4 泛化：参与者泛化与用例泛化

泛化关系画成实线加空心三角箭头，箭头永远指向父元素。它有两种用法，一种是参与者泛化，一种是用例泛化。

参与者泛化处理的是"多个角色共享同一批用例"的场景。比如校内读者和校外读者都能查图书、都能借书，但只有校内读者能预约。这时候可以抽出一个父参与者"读者"，把查图书、借书这类通用用例挂到父参与者上，然后让"校内读者"和"校外读者"分别继承，各自再挂自己的专属用例。这样做的好处是不用把同一个用例重复连好几条线，图会干净很多。

用例泛化用得相对少，一般出现在"某个用例是另一个用例的特化版本"的场合。比如"缴纳罚金"可以特化成"现金缴纳"和"在线缴纳"。需要注意的是，用例泛化在实际评审里经常被认为属于过度设计——如果两种缴纳方式的业务差异很大，那不如干脆拆成两个独立用例；差异很小，那就一个用例配一段文字说明。我个人的经验是，除非确实存在可替换的多种实现路径，否则别用用例泛化。

3.5 一张对照表把四种关系的判定条件钉死

这张表可以当口诀背。考场上先判断是不是参与者连线，是就填关联；不是再看箭头方向，指向被复用的那方是 include，指向被扩展的那方是 extend；如果出现了继承层级，那就是泛化。按这个顺序过一遍，四种关系基本不会填错。

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

4.1 真题反复考的三种题型

翻近几年软考中级软件设计师的卷子，用例图相关的题目大致跑不出三种形态。第一种是选择题，给一小段需求描述，问参与者是谁、某个用例和另一个用例是什么关系、某个动作该不该作为独立用例。这类题考的是概念边界，属于送分题，但每年都有人丢分。

第二种是下午题里的填空。题干给一张画了一半的用例图，参与者画好了，用例只填了一部分，或者关系标签空着，让你根据需求文字补全。这种题的难点在于信息全藏在文字里，必须逐句对应，一旦漏读一句就会漏一个空。

第三种是让你判断给定用例图里的错误。可能是参与者画在了边界框里面，可能是 include 箭头画反了，可能是两个参与者之间连了关联线，也可能是把内部模块当成了参与者。这类题看着开放，其实考点很固定，就是上面讲的那些判定规则。

4.2 从题干文字反推填空答案

下午题的答题节奏我自己是这么走的：先通读需求，标出所有出现的人名、角色名、系统名，这一步对应参与者空；再把所有动词短语圈出来，对应用例空；最后重点抠那些出现"如果""当……时""自动""必须"的地方，这些词后面藏的基本都是扩展或包含关系。

有个特别好用的技巧是看句式。"系统可以……"通常对应一个基础用例；"当……时，系统需要……"通常对应扩展；"在……之后，系统……"如果这个动作被多个场景提到，通常对应包含。掌握这三种句式，填空的准确率会明显提升。

另外提醒一句：题干里出现的名词不一定都是参与者。像"数据库""服务器""接口层"这类名词属于系统内部构成，题目里提到它们只是背景交代，不要往上填。

4.3 include 与 extend 的真题判定实例

举个典型题干："读者归还图书时，系统首先记录归还信息。如果该书已超过归还日期，系统需要计算逾期天数并生成罚金记录。"这里"记录归还信息"是还书流程的固有部分，不单独拆；"计算逾期天数并生成罚金记录"带明确条件"如果已超过归还日期"，而且还书流程本身在没有逾期时也能正常走完，所以它是扩展，箭头从"计算罚金"指向"还书"。

再换一段："读者办理借书和续借时，系统都需要先验证读者的借阅资格和当前借阅数量。"注意"都需要"三个字——这是复用信号，说明"验证借阅资格"被两个用例共同使用，属于包含关系，箭头从"借书""续借"分别指向"验证借阅资格"。

同样是验证类动作，一段写成条件触发，一段写成共同复用，答案就完全不同。差别只在"如果"和"都需要"这几个字上，读题时用笔圈出来，基本不会翻车。

4.4 答题格式与最容易丢分的四个细节

答题书写上有几个地方每年都有人栽。一是关系标签的写法，规范是双尖括号包住关系名，写成 «include» 和 «extend»，别只画一条虚线不写标签。二是箭头方向，include 从基用例指向被包含用例，extend 从扩展用例指向基用例，这两个方向记反了扣分很实在。三是参与者不能画在系统边界框内，画进去等于承认它是系统内部的东西。四是用例命名必须动宾结构，"借阅管理""图书模块"这种名词性写法在阅卷标准里是不给分的。

还有一个细节容易被忽略：系统边界框一定要画，并且要写上系统名称。有些同学的答案图只有参与者、用例和连线，没有那个大方框，虽然内容没错，但结构分拿不满。

5. 图书管理系统用例图：从零到成图的完整实操

5.1 需求梳理与角色划分

假设需求是这样一段描述：读者可以查询图书、借阅图书、归还图书、续借图书、预约已被借出的图书、查询自己的借阅记录、缴纳逾期罚金；图书管理员负责图书信息维护、读者信息维护、处理借还业务、生成借阅统计报表；系统每天凌晨自动统计前一天的借阅情况，对即将到期的借阅发送提醒；系统需要通过校园一卡通接口核验读者身份，通过短信通知平台发送提醒。

按角色划分，参与者一共六个：借阅者、图书管理员、系统管理员、校园一卡通接口、短信通知平台、时钟。其中校园一卡通接口和短信通知平台是外部系统，时钟是非人触发者，这四个是最容易被漏掉的。

再确认一遍边界：图书馆管理系统本身包含图书信息、借阅记录、读者资料这三块数据；校园一卡通只负责身份核验，短信平台只负责消息投递，两者都在边界外。边界一旦画清楚，后面的连线就不会乱。

5.2 用例清单与关系标注

按前面讲的合并与筛选规则，整理出十二个用例：借书、还书、续借、预约图书、查询图书、查询借阅记录、缴纳逾期罚金、维护图书信息、维护读者信息、统计借阅报表、生成逾期清单、发送到期提醒。

关系部分逐个过一遍。借书和续借都要核验读者身份，所以抽出"核验读者身份"作为被包含用例，两条 «include» 虚线分别从借书、续借指向它。还书时如果存在逾期，需要缴纳罚金，所以"缴纳逾期罚金"是扩展用例，箭头指向"还书"。生成逾期清单由时钟触发，发送到期提醒由短信平台承接，这两条用关联线连到对应参与者。

参与者泛化方面，图书管理员和系统管理员都涉及读者信息相关的部分操作，可以抽一个父参与者"系统用户"，让两者继承，把公共的"查询借阅记录"挂到父参与者上，减少连线数量。

5.3 图形布局与工具选择

布局上有几条实战经验。参与者统一放在左右两侧或者上下两端，不要围着方框乱撒。用例按业务分组摆放，比如借阅相关的放一起，信息维护相关的放一起，报表相关的放一起，视觉上一眼能看出模块划分。连线尽量不交叉，实在交叉就在交叉处画一个小跳跃符号或者用弧度绕开。

工具方面，做课程设计和项目文档我用得比较多的是几款免费在线建模工具，优点是导出图片方便、支持中文标签；写技术文档的时候更倾向于用纯文本描述的绘图语言，因为改起来快，版本管理也友好，改一行字就能重画一张图，不用重新拖拽对齐。软考考场上只能手绘，那就记住一个原则：先把方框、参与者、用例的位置铅笔轻轻标一遍，确认不挤了再描实，能省下大量涂改时间。

5.4 交图前的自检清单

图快画完的时候，按下面这张清单逐条过，一条不合格就回去修。

• 系统边界框是否画了，名字是否写全。
• 所有参与者是否都在框外，有没有混进内部模块。
• 每个参与者是否至少连了一条线，有没有孤立的角色。
• 每个用例是否至少连了一个参与者或者一个关系，有没有孤立的椭圆。
• 用例命名是否全部是动宾结构。
• «include» 箭头是否从基用例指向被包含用例。
• «extend» 箭头是否从扩展用例指向基用例。
• 参与者之间是否存在关联线（不允许，只能泛化）。
• 是否有两个用例名字重复或者语义重复。
• 是否存在只被一个用例使用的 include（应改回普通步骤）。

这张清单我用了很多年，几乎每次都能揪出两三个问题，尤其是第八条和第十条，出错率最高。

6. 图画完之后：评审时最常被挑的毛病与用例规约

6.1 系统性缺陷：缺边界、命名不一致、关系滥用

评审时被挑得最多的一类问题是"缺少系统边界"。很多人觉得那个方框没信息量就省了，但在评审视角里，没有边界框的用例图无法判断哪些是你负责的系统、哪些是外部依赖，等于需求范围没界定。

第二类问题是命名不一致。用例图里写"借阅者"，需求文档里写"读者"，数据库设计里写"user"，三套叫法混着来。评审的人不会去帮你对齐，只会觉得你没想清楚。我的做法是画图之前先定一张术语表，人、角色、实体、用例的名字全部统一，后面所有文档都从这张表取词。

第三类问题是关系滥用。图上密密麻麻全是 «include»，掰开一看，八成都是可以合并回主用例的内部步骤。判断标准还是那句老话：被拆出来的行为是否被多个用例复用、是否是完整功能单元。两条都满足才拆，只满足一条就留着。

6.2 用例规约该怎么配：用例图的下半场

用例图只画出了轮廓，具体每个用例怎么走，要靠用例规约补。规约一般包含这几个部分：用例名称、参与者、前置条件、后置条件、主事件流、备选流、异常流。主事件流是正常情况下从触发到结束的步骤序列，备选流是条件不满足时的分支，异常流是出错时的处理。

拿"借书"举例。前置条件是读者身份已核验且借阅额度未满；后置条件是借阅记录新增一条、对应图书可借数量减一；主事件流是读者提交借书请求、系统核验身份、系统检查额度、系统登记借阅记录、系统提示借阅成功；备选流是额度已满时提示拒绝并给出可借数量；异常流是核验接口超时，提示稍后重试。

提示：主事件流的每一步都应该是一个可以被参与者感知的动作，不要写成"系统调用 DAO 层查询数据库"这种实现细节，那属于设计文档的内容。

6.3 一个可复用的小模板

最后给一个我一直在用的规约模板，直接抄就行：

• 用例名称：动宾结构，与用例图上的椭圆文字完全一致。
• 参与者：主参与者是谁，有没有辅助参与者（比如支付接口）。
• 前置条件：执行该用例之前系统必须满足的状态。
• 后置条件：用例成功结束后系统发生的状态变化。
• 主事件流：编号列出正常路径，每条一句话，动作主体明确。
• 备选流：编号列出分支，标明触发条件。
• 异常流：编号列出异常，标明处理方式。
• 业务规则：额度上限、逾期天数计算方式这类约束。

模板本身不复杂，难的是坚持让每一个椭圆都配一份规约。我见过太多只交图不交规约的作业，评审的时候被问一句"这个备选流怎么处理"就答不上来。

我个人在做课程设计和写需求文档时最大的体会是：用例图的价值不在于它画得多完整，而在于画图这个动作逼着你把"谁用、用来干什么、什么情况下有不 一样的分支"这三件事逐条回答清楚。图上的每一个椭圆背后其实都有一份没写出来的规约，图画完、规约补齐、术语统一，这套东西才算是真的交付了。