用例图include和extend怎么区分？箭头方向、条件与完整示例

用例图里的include和extend，区别在于基础用例怎样依赖另一段行为：include把需要复用的行为纳入基础用例；extend则在指定扩展点追加行为，基础用例不依赖这段扩展也有完整意义。画箭头时记住两种方向：include从基础用例指向被包含用例，extend从扩展用例指向基础用例。

不要仅凭“这个功能是不是可选”决定关系。先写清参与者想完成什么、基础用例的完成结果和扩展触发条件，再用Boardmix UML绘图工具整理图形与说明。图中只保留能帮助理解需求的关系，详细步骤放在用例规约里。

include与extend的区别，先对照这四项

两者都使用虚线和开放箭头，分别标注«include»、«extend»。不要换成泛化关系使用的实线空心三角，也不要把箭头当作“用户下一步点击哪里”。用例图表达功能之间的关系，不负责表达全部时间顺序。

IBM的include说明强调行为复用，extend说明则强调基础用例独立成立和扩展点。实际建模时，仍应以本系统的业务规则判断，而不是照搬另一个系统的例图。

完整例子：访客预约与停车需求

考虑一个企业访客预约系统。访客提交来访日期、时段和联系人；系统核对该时段是否允许预约，然后生成预约记录。如果访客驾车，还可登记车牌及停车需求。这里约定：不申请停车，也能完成普通访客预约；停车登记不保证最终获得车位。

先写基础用例“提交访客预约”的简短规约：

1. 访客填写来访日期、时段和联系人。
2. 系统执行“校验来访时段”，返回可预约或不可预约及原因。
3. 时段不可预约时，提示修改信息；可预约时，进入预约信息确认。
4. 在“确认预约信息”扩展点，可插入“登记停车需求”。
5. 访客确认提交，系统生成预约记录并展示结果。

本例的基本完成结果是“生成访客预约记录”，不是“车位已经确认”。把两种结果混在一起，图中就很难判断停车行为到底是基础服务的一部分，还是附加需求。

为什么“校验来访时段”用include

“提交访客预约”需要时段校验结果，才知道能否继续。如果系统还允许“修改预约时间”，这个用例也需要使用同一套校验规则。于是可以画两条关系：

• 提交访客预约 —«include»→ 校验来访时段。
• 修改预约时间 —«include»→ 校验来访时段。

被包含用例可单独写清输入和输出：输入是日期、时段及必要的预约上下文，输出是可预约与否及原因。基础用例不用重复解释每条规则，却仍知道怎样处理结果。

“必需行为”不等于用户一打开页面就执行。include是对行为结构的描述；如果流程在到达相应位置前就取消，后面的校验不会凭空发生。不要因此把include换成extend，也不要把每个字段检查都拆成一个椭圆。

为什么“登记停车需求”用extend

当访客选择驾车到访时，系统在“确认预约信息”处补充车牌和停车需求；没有这段行为，普通预约仍能完成。因此关系写成：

登记停车需求 —«extend»→ 提交访客预约；条件：访客选择驾车到访；扩展点：确认预约信息。

箭头指回“提交访客预约”，因为它是被扩展的基础用例。条件描述的是什么时候增加这段行为，不是停车是否审批成功。若业务改成“所有访客都必须完成车辆登记才能预约”，就需要重新审查基础用例，不能继续沿用原来的关系而不改规则。

哪些情况不需要画include或extend

很多复杂用例图不是功能太多，而是把界面步骤都拆成了用例。拆分前可以用下面几个反例检查：

• “点击提交”包含“填写姓名”：这是界面操作与字段输入，通常留在“提交访客预约”的步骤里，不需要变成两个独立用例。
• “查看预约”包含“登录”：先看身份规则。若使用者在进入本功能前已登录，把“已通过身份验证”写为前置条件可能更清楚；不能默认每次查看都重新执行一次完整登录。
• “修改预约”扩展“提交预约”：仅因为修改通常发生在提交之后，不足以建立extend。修改预约可以是另一个独立目标，关联相应参与者，并在自己的规约中注明已有预约这一前提。
• “预约失败”扩展“提交预约”：失败结果不必自动拆成扩展用例。输入无效、名额不足等备选流程，可以先写在基础用例的异常或备选步骤中。

需要表达先后、分支和反复修改时，应另画活动图或流程图；需要表达多个系统的请求响应时，再使用时序图。用例图保留参与者目标与功能关系，往往更容易评审。

在Boardmix中画完后，按三条路径走读

在画布中先放一个标明“访客预约系统”的边界框，访客放在框外；把“提交访客预约”“修改预约时间”“校验来访时段”“登记停车需求”放在框内。参与者与其发起的目标用实线关联，再单独添加两条include和一条extend虚线，避免把关系箭头接到系统边界或参与者身上。

将基础用例步骤放在图旁，把扩展点名称和条件放在extend关系附近。使用文字、图形和连接线组织表达即可；关键是内容一致，不依赖软件自动判断UML语义。有关系统边界与参与者的完整起步方法，可继续阅读系统用例图绘制指南。

最后检查箭头和文字是否互相矛盾：include箭头有没有指向公共行为，extend箭头有没有指向基础用例，扩展点是否真的出现在基础规约中。只保留有解释价值的关系，比把图连满更有助于产品、研发和测试达成一致。

打开Boardmix，整理用例关系与评审说明