用例图评审时出现“关系表达混乱”，通常集中在三类位置：系统边界、参与者、包含与扩展。排查时按“症状—原因假设—证据—修正—回放验证”推进，先确认边界框是否只圈住本系统职责，再核对参与者是否都在边界外、命名是否一致，随后检查每条连线是否对应真实交互，最后修正包含与扩展的箭头方向和触发条件。每类判断都要用需求原文、流程走查和评审记录支撑，证据不足时标为待确认。
要点总览（TL;DR）
- 关系混乱先拆成三类可观察症状：系统边界圈错、参与者位置与命名不一致、包含与扩展方向或条件画错。
- 每类症状先提原因假设，再用需求原文、流程走查、场景回放和评审记录验证；证据不足标为待确认，不写成缺陷。
- 修正按边界—参与者—连线—包含与扩展的顺序推进，边界一变参与者和连线往往要跟着调整。
- 改完用典型业务场景逐个走查，并交叉核对需求文档，确认每个用例和连线都有需求依据。
- 把边界与关系检查点固化进评审清单、统一命名规范并保留变更记录，可减少同类问题复发。
评审时关系混乱通常表现成哪几类症状
“关系混乱”是一个笼统的评审意见，落到图上往往能拆成若干可观察的具体现象。排查的第一步是把意见转成症状清单，让每位评审人对着同一组条目指认问题位置，避免反复争论“哪里乱”。以下三类症状覆盖了用例图关系表达的主要出错面。
系统边界类症状
- 边界框内出现外部系统、外部平台或第三方服务，例如把支付渠道、短信网关画成本系统的一部分。
- 边界框按组织架构划分，把某个部门的所有工作都圈进来，而不是按本系统承担的职责划分。
- 边界框缺失或范围模糊，图上无法判断哪些用例属于本系统、哪些属于周边系统。
参与者类症状
- 参与者被画在系统边界框内，与用例混在同一区域。
- 同一外部角色出现多个名称，如“客户”“用户”“会员”并存，无法判断是否为同一参与者。
- 参与者粒度过粗或过细：一个“管理员”承担了全部后台职责，或把同一角色的不同权限拆成多个参与者。
- 参与者与用例之间的连线实际表达的是系统内部模块调用，而非外部角色与系统的交互。
- 同一用例被多个参与者重复连接，导致该用例到底由谁触发、职责归谁变得不清楚。
包含与扩展类症状
- 箭头方向画反：包含关系的箭头指向了包含方，扩展关系的箭头指向了扩展用例。
- 把条件触发的可选行为画成包含，使可选动作在图上看起来是每次必做。
- 把代码层面的公共复用直接画成包含，而该行为在业务上并非每个主用例都必然执行。
- 扩展关系缺少扩展条件或扩展点说明，读者不知道在什么情况下走扩展路径。
评审时可以先按上表逐项打勾，把“关系混乱”收敛为若干条带位置的具体问题，再进入原因分析。症状清单只记录现象，不在此阶段下结论。
每类症状对应哪些原因假设与排除证据
症状确认后，下一步是为每条症状提出可能原因，并为每个原因找到能证实或排除它的证据。原因假设与证据要分开记录：假设是待验证的判断，证据是需求原文、流程走查、场景回放或评审记录中的具体内容。证据不足时标注“待确认”，不直接写成缺陷。
| 症状 | 原因假设 | 验证证据 | 排除或确认 |
|---|---|---|---|
| 边界框圈入外部系统 | 把外部系统当成本系统模块；按组织架构而非系统职责划分边界 | 需求原文中的系统职责描述；业务流程走查中该外部系统的实际归属 | 若需求明确该能力由外部系统提供，确认为边界错误；若需求未写清，标为待确认 |
| 参与者出现在边界内 | 绘图时未区分系统内外；把内部岗位当成外部角色 | 业务流程中该角色是否通过系统界面与系统交互；评审记录中的角色说明 | 确认其为本系统外部交互方则移出边界；若为本系统内部模块，改为内部实现说明 |
| 同一角色多个名称 | 不同评审人按各自习惯命名；角色粒度未统一 | 需求原文中的角色定义；业务术语表；场景回放中该角色的实际行为 | 行为一致则合并为一个参与者；行为不同则保留并补充区分说明 |
| 连线表达内部调用 | 把模块依赖误画成参与者交互；绘图时混入实现细节 | 该连线两端是否分属系统内外；场景走查中是否存在对应的外部触发 | 无外部触发则删除连线；有外部触发则改为正确的参与者—用例关系 |
| 包含箭头方向反了 | 对包含语义理解偏差；绘图时箭头随手连接 | 被包含用例是否在主用例每次执行时都必然发生 | 是则保留包含并改正箭头指向被包含用例；否则考虑改为扩展 |
| 可选行为画成包含 | 混淆必选与可选；把复用当包含 | 需求原文中该行为的触发条件；场景回放中是否每次都会执行 | 条件触发则改为扩展并写明条件；每次必做则保留包含 |
| 扩展点未写条件 | 只画了关系未补说明；需求本身未澄清触发条件 | 需求原文或业务规则中的触发条件；评审记录中的讨论结论 | 找到条件则补写扩展点；找不到则标为待确认并回到需求澄清 |
使用这张表时，注意把“原因假设”和“结论”分栏记录。例如“边界框圈入外部系统”只是症状，原因可能是按组织架构划分，也可能是绘图时疏忽；只有需求原文和流程走查都指向外部系统承担该职责时，才能确认为边界错误。对于同一用例被多个参与者重复连接的情况，还要核对各参与者是否真的都触发该用例，还是其中某条连线表达的是查看结果之类的间接关系。
证据收集可以借助评审记录和需求条目的关联管理。在ONES中，需求条目与评审意见可以放在同一工作项上下文中跟踪，评审人指出的边界或关系问题能对应到具体需求条目，修正时也有变更记录可查。这样做的目的是让“待确认”项有归属、有后续动作，而不是停留在会议纪要里。
按什么顺序排查并修正边界与参与者关系
修正顺序影响返工次数。边界一变，参与者和连线往往要跟着调整；参与者一合并，包含与扩展的判断也可能变化。建议按“边界—参与者—连线—包含与扩展”的顺序推进，每一步完成后再进入下一步。
第一步：固定系统边界
先明确本系统承担的职责范围，把外部系统、外部组织和外部人员移到边界之外。判断依据是需求中的系统职责描述，而不是当前组织架构。边界框内只保留本系统提供或承载的用例。若某个能力由外部系统提供、本系统只是调用，应放在边界外并以参与者或外部系统标识。
第二步：统一参与者
按与系统交互的外部角色重新梳理参与者：合并同义角色，拆分职责过粗的角色，删除实际是内部模块的“参与者”。命名以业务术语为准，同一角色在全图使用同一名称。拆分粒度以“该角色与系统的交互集合是否明显不同”为判断标准，避免为每个权限点建一个参与者。
第三步：核对参与者与用例的连线
逐条检查连线是否对应一次真实交互：该参与者是否通过系统发起或接收该用例的结果。表达内部调用、模块依赖或数据流向的连线应删除，必要时在用例描述中说明内部实现。同一用例被多个参与者连接时，确认每个参与者都有独立的触发场景，否则合并或删除多余连线。
第四步：修正包含与扩展
按语义重新判断：主用例每次执行都必然发生、且被多个用例共用的行为，用包含，箭头指向被包含用例；仅在特定条件下才发生的可选行为，用扩展，箭头指向被扩展用例，并写明扩展条件和扩展点。把“复用”作为包含的唯一理由是不够的，还要确认它在业务上是否必选。
修正过程中保留原图版本，每完成一步保存一次，便于对比和回退。若团队在ONES中管理需求与评审，可将修正前后的图与对应需求条目、评审意见关联，变更记录随需求条目留存，后续追溯时能看清每处调整的依据。
改完后怎么验证关系表达已经正确
修正完成不等于关系正确。验证的目标是确认图上每个元素都能在需求中找到依据，并且典型业务场景能够沿着图走通。
用典型业务场景逐个走查
选取覆盖主要业务路径的场景，逐个在图上走一遍：找到触发该场景的参与者，找到对应的用例，确认触发条件和扩展路径与场景描述一致。若某个场景在图上找不到对应参与者或用例，说明边界或参与者仍有遗漏；若场景走不通某条包含关系，说明包含判断有误。
交叉核对需求文档
每个用例至少对应一条需求或业务规则，每条参与者—用例连线能在需求中找到交互依据。包含与扩展关系所依赖的条件，应能在需求原文或业务规则中找到出处。对不上号的关系，要么补需求说明，要么修正图。
评审检查点
- 边界框内只包含本系统职责，外部系统与外部组织均在边界外。
- 所有参与者位于边界外，命名统一，粒度一致。
- 每条连线对应真实外部交互，无内部调用式连线。
- 包含箭头指向被包含用例，扩展箭头指向被扩展用例，扩展条件已写明。
- 同一用例的多条参与者连线各有独立触发场景。
复发预防
把上述检查点固化进用例图评审清单，作为每次评审的固定环节；统一参与者命名规范和边界划分口径，写入建模约定；保留每次修正的版本和评审记录，下次评审时先对照历史问题，确认同类错误没有再次出现。在ONES中，可将评审清单作为评审模板的一部分，需求条目与评审结论关联留存，使边界与关系检查成为需求评审的常规动作，而不是一次性的补救。
常见问题
评审时对某个角色算不算参与者有分歧，怎么处理？
先看该角色是否通过系统界面发起或接收交互。若它只是系统内部模块、岗位之间的内部流转，或由其他系统在后台调用，就不应作为参与者画在图上，可在用例描述中说明内部实现。若它确实从系统外部触发用例，则保留为参与者。分歧无法当场统一时，把两种判断和各自的依据记入评审记录，标注待确认，回到需求原文或业务流程走查中找证据，再决定是否调整。
包含和扩展都涉及公共行为，判断时容易混，有没有更直接的区分办法？
用“是否每次必做”作为第一判断：主用例每次执行都必然发生、且被多个用例共用的行为，用包含，箭头指向被包含用例；只在特定条件下才发生的可选行为，用扩展，箭头指向被扩展用例，并写明扩展条件和扩展点。仅因为代码或流程上可以复用就画成包含，容易把可选动作误标为必做。若需求原文没有写清触发条件，先标为待确认，回到需求澄清后再定关系。
用例图改完后，评审仍然觉得关系乱，下一步该查什么？
先确认修正是否按边界、参与者、连线、包含与扩展的顺序完成，边界调整后参与者和连线是否同步更新。再用典型业务场景逐个走查：每个场景能否在图上找到触发它的参与者、对应用例和触发条件。若场景走不通，问题多半仍在边界或参与者；若场景能走通但关系读起来别扭，重点检查包含与扩展的方向和条件说明。最后交叉核对需求文档，对不上号的关系要么补需求说明，要么修正图。
团队多人协作画用例图，怎样减少边界和命名上的反复返工？
在建模前先约定两条口径：边界按本系统承担的职责划分，外部系统、外部组织和外部人员一律放在边界外；参与者按业务术语统一命名，同一角色全图使用同一名称，拆分粒度以交互集合是否明显不同为准。把这两条写入建模约定，并在评审清单中固定边界与关系检查项。修正时保留原图版本，每完成一步保存一次，评审时先对照历史问题确认同类错误没有再次出现。
证据不足、只能标为待确认的问题，后续怎么跟踪才不遗漏？
把待确认项连同症状位置、原因假设和缺失的证据类型记录在同一条评审意见下，指定跟进人和需要补充的材料，例如需求原文、业务规则或流程说明。跟进人补齐证据后再判定是修正图还是补需求。若团队在ONES中管理需求与评审，可将评审意见与对应需求条目关联，变更记录随条目留存，待确认项有归属、有后续动作，不会停留在会议纪要里。
