用例图用参与者、系统边界、用例以及它们之间的关系，表达“谁通过系统完成什么目标”。本文以一个假设的图书借阅系统为演示情景，给出从需求描述到完整用例图的填写示例，逐项说明参与者识别、用例命名、包含与扩展关系的取舍依据，并总结可以迁移到其他系统的建模规律与适用边界。示例仅用于说明方法，不对应真实客户或实际项目。
要点总览（TL;DR）
- 用例图用参与者、系统边界、用例和关系表达“谁通过系统完成什么目标”，本文以假设的图书借阅系统给出完整填写示例。
- 参与者按交互职责划分，读者与图书管理员目标不同应分开；外部支付系统承担明确交互职责，可列为次要参与者。
- 用例名称用动宾结构表达用户可感知的目标；多个用例必经的公共步骤用包含关系，条件触发的可选分支用扩展关系。
- 可迁移的填写顺序是先定边界、再找参与者、从用户目标划分用例、标注关联、识别公共步骤与分支，最后与需求条目和验收条件衔接。
- 用例图适合表达功能目标与角色关系，需求优先级、非功能需求细节和界面布局需要由需求分析、质量属性说明和原型图承载。
示例目标：这张用例图要回答什么
本文的演示情景是一个面向读者的图书借阅系统。读者可以借书、还书、查询图书；图书管理员负责图书信息维护、借阅记录处理与读者账户管理。这个情景足够小，能在一张图里完整呈现；又包含多类角色和可选分支，便于说明关系取舍。以下内容均为示例设定，用于演示建模过程。
建模范围限定在需求层面的功能目标：系统为哪几类角色提供哪些可观察的服务结果。架构分层、数据库设计、接口协议、页面布局与交互细节都不在本次建模范围内。这样限定是为了让用例图保持“需求视图”的定位，避免把设计决策提前混入需求表达。
这张示例图需要回答三个问题：
- 参与者有哪些：哪些人或外部系统与图书借阅系统直接交互，并从系统中获得结果。
- 用例如何划分：读者的借书、还书、查询，管理员的图书维护、借阅处理、账户管理，各自对应哪些独立目标。
- 关系如何取舍：哪些步骤是多个用例共享的必经环节，用包含关系表达；哪些是可选或条件触发的分支，用扩展关系表达。
建模范围清单可以概括为：系统边界为“图书借阅系统”；参与者为读者、图书管理员，以及承担明确交互职责的外部支付系统；用例覆盖借书、还书、查询图书、维护图书信息、处理借阅记录、管理读者账户、缴纳逾期费用；关系上标注“借书”包含“验证读者身份”、“借书”在逾期时扩展“缴纳逾期费用”。
完整示例：图书借阅系统用例图填写结果
下面用文字化结构呈现这张用例图的完整填写结果。图形上，系统边界是一个矩形框，参与者画在框外，用例以椭圆画在框内，参与者与用例之间用关联线连接，用例之间用带箭头的虚线标注包含或扩展，箭头旁注明关系类型。
参与者清单
| 参与者 | 类型 | 与系统的交互目标 |
|---|---|---|
| 读者 | 主要参与者（人） | 借书、还书、查询图书、缴纳逾期费用 |
| 图书管理员 | 主要参与者（人） | 维护图书信息、处理借阅记录、管理读者账户 |
| 外部支付系统 | 次要参与者（外部系统） | 接收并处理读者的逾期费用支付请求 |
用例清单及目标
| 编号 | 用例名称 | 参与者 | 用例目标 |
|---|---|---|---|
| UC1 | 借书 | 读者 | 读者完成一次图书借出，系统记录借阅关系 |
| UC2 | 还书 | 读者 | 读者归还图书，系统更新借阅状态 |
| UC3 | 查询图书 | 读者 | 读者按条件检索图书并查看可借状态 |
| UC4 | 缴纳逾期费用 | 读者、外部支付系统 | 读者支付逾期费用，系统更新费用状态 |
| UC5 | 维护图书信息 | 图书管理员 | 管理员新增、修改、下架图书信息 |
| UC6 | 处理借阅记录 | 图书管理员 | 管理员查看并处理异常借阅记录 |
| UC7 | 管理读者账户 | 图书管理员 | 管理员创建、冻结、恢复读者账户 |
| UC8 | 验证读者身份 | 被包含 | 确认读者账户有效且可借阅 |
关系标注
| 关系 | 源用例 | 目标用例 | 说明 |
|---|---|---|---|
| 包含 | 借书 | 验证读者身份 | 每次借书都必须先确认读者账户有效，该步骤被借书与还书共同复用 |
| 包含 | 还书 | 验证读者身份 | 还书同样需要确认读者身份，复用同一公共步骤 |
| 扩展 | 缴纳逾期费用 | 借书 | 仅当读者存在逾期未缴费用时触发，属于借书流程的可选分支 |
系统边界内包含 UC1 至 UC8 八个用例；读者关联 UC1、UC2、UC3、UC4；图书管理员关联 UC5、UC6、UC7；外部支付系统关联 UC4。UC8 不直接关联参与者，通过包含关系被 UC1、UC2 调用。这张结构表与图形版本表达同一份成果，便于逐项核对。
逐项解释：每个参与者、用例和关系为什么这样定
示例中的每个元素都有明确的判断依据。下表逐项说明填写理由，便于读者对照自己的场景做同样的判断。
| 元素 | 填写内容 | 判断依据 |
|---|---|---|
| 参与者划分 | 读者、图书管理员 | 两类角色都与系统直接交互，且从系统中获得不同的可观察结果；职责不同，不能合并为一个“用户” |
| 外部系统作为参与者 | 外部支付系统 | 它承担明确的交互职责：接收支付请求并返回处理结果，属于系统边界之外的协作方，因此列为次要参与者 |
| 用例命名 | 借书、还书、查询图书等动宾结构 | 动宾结构直接表达“谁做什么、得到什么结果”，读者和评审者能据此判断目标是否完整，避免“借阅管理”这类无法判断边界的笼统名称 |
| 包含关系 | 借书、还书包含验证读者身份 | 验证身份是两个用例都必须执行的公共步骤，单独抽出可避免重复描述，且不改变借书、还书各自的目标 |
| 扩展关系 | 缴纳逾期费用扩展借书 | 缴费只在读者存在逾期费用时发生，是条件触发的可选分支；主流程目标仍是完成借书，因此用扩展而非包含 |
| 排除内容 | 登录、点击按钮、数据库读写 | 这些是操作步骤或内部实现，不构成用户可感知的独立目标，放入用例图会稀释需求视图 |
参与者划分的关键在于“交互职责是否不同”。读者与图书管理员面对同一系统，但目标集合不同，权限与结果也不同，因此分成两个参与者。若把两者合并，后续就无法从图中看出谁负责维护图书信息。外部系统是否算参与者，取决于它是否与系统发生明确交互并产生可观察结果；仅被系统读取的静态数据源通常不列为参与者。
包含与扩展的取舍容易混淆，判断口径可以统一为：被抽出的步骤是否是主用例每次执行都必经的环节。必经则用包含，条件触发则用扩展。示例中验证身份是借书、还书的必经步骤，所以用包含；缴费只在逾期时发生，所以用扩展，并且扩展的方向是从“缴纳逾期费用”指向“借书”，表示它插入借书流程。
可迁移规律：换一个系统怎么照着填
把上面的示例抽象成步骤，可以在其他业务系统上照做。以下清单按执行顺序排列，每步都给出可检查的完成标志。
- 先定系统边界。写一句话说明系统负责什么、不负责什么，例如“本系统负责图书借还与信息维护，不负责物流配送”。完成标志是边界内外的职责没有重叠。
- 再找参与者。列出所有与系统直接交互的人或外部系统，按交互职责分组，每组给出一个名称。完成标志是每个参与者都能说出至少一个从系统中获得的结果。
- 从用户目标划分用例。对每个参与者，问“他希望通过系统完成哪些完整目标”，每个目标写成一个动宾短语。完成标志是用例名称能独立判断成功与否，且不包含操作步骤。
- 标注参与者与用例的关联。逐条连线，检查是否存在没有参与者的用例或没有用例的参与者。完成标志是每个用例至少关联一个参与者，被包含的公共用例除外。
- 识别公共步骤与可选分支。多个用例重复出现的必经步骤抽为被包含用例；条件触发、异常处理或可选增强用扩展关系标注，并写明触发条件。完成标志是每条关系都能回答“为什么是包含而不是扩展”。
- 与需求条目和验收条件衔接。为每个用例建立一条需求条目，写明前置条件、主流程、扩展分支和验收条件。完成标志是用例图中的每个用例都能在需求清单中找到对应条目，评审时可以逐条核对。
这套顺序的核心是“先边界、后角色、再目标、最后关系”。顺序颠倒容易导致参与者越列越多、用例越拆越细。用例划分以用户目标为单位，而不是以界面按钮或内部函数为单位，这样图形才能稳定支撑后续的需求评审与变更讨论。
当用例成果需要进入团队协作流程时，可以把每个用例作为需求条目登记到 ONES 的需求管理中，附上用例图与验收条件，再通过评审流程确认范围与优先级。这样图形成果与需求条目保持一一对应，后续变更时能追溯到具体用例。是否使用图形建模工具、以何种方式关联条目，建议在选型时结合团队现有流程核验。
适用边界：用例图能表达什么、不能替代什么
用例图适合表达系统对外提供的功能目标、参与者与系统的关系，以及用例之间的包含与扩展结构。它帮助产品、开发和测试在需求早期对齐“系统为谁做什么”，也便于向非技术干系人说明范围。示例中的图书借阅系统正是用一张图交代了角色分工与主要功能。
用例图不承载需求优先级判断。哪些用例先做、哪些可以延后，需要在需求分析与排期环节结合业务价值确定。它也不表达非功能需求的细节，例如响应时间、并发量、安全等级，这些需要单独的需求条目或质量属性说明。界面布局与交互流程同样不在用例图中展开，页面原型和流程图是更合适的载体。
| 内容 | 是否适合用例图承载 | 更合适的载体 |
|---|---|---|
| 参与者与功能目标 | 适合 | 用例图 |
| 用例间包含与扩展 | 适合 | 用例图加用例描述 |
| 需求优先级与排期 | 不适合 | 需求清单、评审记录 |
| 非功能需求细节 | 不适合 | 质量属性说明、验收标准 |
| 界面布局与交互 | 不适合 | 原型图、交互说明 |
用例图与需求分析是分工关系：用例图负责把功能范围与角色关系表达清楚，需求分析负责澄清每条用例的前置条件、业务规则、异常处理和验收口径。两者配合使用，图形提供全局视图，需求条目提供可执行细节。把用例图当作需求分析的全部成果，会遗漏大量需要确认的业务规则；反过来，只写需求条目而不画用例图，则容易失去角色与范围的全局视角。
常见问题
用例图里的包含关系和扩展关系，判断顺序上有没有更省事的做法？
可以先问一个问题：这个被抽出的步骤，主用例每次执行是否都要经过。必经的公共步骤用包含关系，例如借书和还书都要验证读者身份；只在特定条件下才发生的分支用扩展关系，例如读者存在逾期费用时才缴纳费用。判断时以主用例的目标是否改变为准：包含不改变主目标，扩展是在主流程上插入可选行为。把每条关系都写成一句“为什么是包含而不是扩展”，评审时更容易达成一致。
外部系统一定要画成参与者吗？
取决于它是否与系统发生明确交互并产生可观察结果。示例中的外部支付系统接收支付请求并返回处理结果，承担独立交互职责，因此列为次要参与者。仅被系统读取的静态数据源，或者只在后台同步数据、不参与业务流程的外部服务，通常不列为参与者。若外部系统的交互会影响用例的触发条件或结果，建议画出来并在用例描述中注明交互内容。
用例图画完之后，怎么和需求条目对应起来，避免图变成摆设？
为每个用例建立一条需求条目，写明前置条件、主流程、扩展分支和验收条件，并让条目与用例一一对应。这样评审时可以逐条核对范围，变更时也能追溯到具体用例。团队若使用 ONES 的需求管理承载需求条目，可以把用例图作为附件或说明关联到对应条目，再进入评审流程；具体关联方式建议结合团队现有流程核验。
小团队或需求变化快的项目，还值得画用例图吗？
用例图的价值在于用一张图对齐角色与功能范围，需求变化快时它的作用更偏向“快速确认边界”，而不是追求完整建模。可以先只画主要参与者和核心用例，把包含与扩展关系留到评审时补充。若团队规模小、角色单一，用例图可以简化到一页，重点保留参与者与用例的关联，避免在关系标注上投入过多时间。
用例图和用户故事、流程图是什么关系，会不会重复？
三者回答的问题不同。用例图表达角色与功能目标的全局关系；用户故事描述单个需求的背景、价值与验收条件；流程图展开具体步骤与分支判断。实践中可以先用例图确定范围和角色，再用用户故事或需求条目细化每条用例，流程复杂的用例再配流程图。三者配合使用，图形负责全局视图，条目和流程负责可执行细节。
