软件设计师 · UML用例图 · include/extend

include 和 extend 场景题怎么判断？

include 和 extend 很多人背得很熟，一到场景题却选反。原因通常不是定义没背，而是没看出题干里的业务动作到底是每次必做，还是满足条件才发生。用例图题不怕例子复杂，怕的是你不先判断业务语义。

软件设计师专题软考题库编辑部持续更新

内容整理：软考题库编辑部最近更新：2026-06-13

include 看“每次都要做”

include 表示一个基础用例执行时，总会包含另一个公共用例。比如“提交订单”每次都需要“校验库存”，“办理借书”每次都需要“验证读者身份”。这些动作不是偶尔发生，而是主流程稳定需要的一部分。

考试题干如果强调公共步骤、复用步骤、必经步骤，通常更接近 include。注意，这里的“包含”不是语文里的包含关系，而是用例执行时一定会调用的公共行为。

extend 表示在特定条件下，对基础用例增加一个扩展行为。比如用户借书时，如果有欠费，才触发“缴纳欠费”；支付订单时，如果支付失败，才触发“重新支付”或“选择其他支付方式”。不是每次都发生，就是 extend 的典型信号。

做题时不要只看到“扩展功能”四个字就选 extend。要看它是不是主流程的可选分支。如果题干说该步骤每次都必须执行，即使名字听起来像扩展，也更可能是 include。

每次下单都要计算订单金额：更像 include。

订单金额超过限额才需要主管审批：更像 extend。

用户可以选择普通支付或积分支付：可能是用例泛化或不同场景建模，不能机械套 include。

箭头方向当然要会，但对于选择题来说，真正决定答案的往往是业务语义。很多同学一上来回忆箭头从谁指向谁，结果题干都没读清楚。老师更建议先问：这个动作是不是基础流程必需？是不是多个用例共同复用？是不是只有条件满足才触发？

如果答案已经能从业务语义判断，再回头看箭头方向就比较稳。反过来，如果只背箭头方向，不理解 include 和 extend 的目的，题目换一个图书借阅、网购支付、报销审批的场景，就容易乱。

遇到 include/extend 场景题，可以把题干改写成一句话：做 A 的时候，是否一定要做 B？如果答案是一定要做，而且 B 可能被多个用例复用，优先考虑 include；如果答案是满足某个条件才做 B，优先考虑 extend。

这个方法特别适合下午题填空。不要急着把图画满，先把每个用例背后的业务规则写清楚。用例图不是为了画箭头而画箭头，它是在表达系统要给参与者提供哪些目标，以及这些目标之间的执行关系。