订单系统用例图：send notification与add order的Extend关联合理性咨询

首先明确UML用例图中<<extend>>关系的核心定义：扩展用例仅在特定条件下可选地补充基础用例的功能，基础用例本身可以独立完成流程。结合你的订单系统场景，是否使用<<extend>>关系，核心取决于「发送通知」的触发逻辑：

适合用<<extend>>关系的场景 #

如果「发送通知」仅在**库存检查不通过（库存不足）**时触发，此时用<<extend>>完全合理：

• 「添加订单」作为基础用例，在库存充足时可以独立完成下单流程，不需要执行「发送通知」
• 只有当库存不足这个特定条件满足时，才会触发「发送通知」这个扩展用例，用来告知用户库存状态
• 绘制时箭头从「发送通知」指向「添加订单」，并标注触发条件：<<extend>> [库存不足]

不适合用<<extend>>关系的场景 #

如果「发送通知」是下单流程中必然执行的步骤（比如库存充足时发送下单成功通知，库存不足时发送库存不足通知），此时应该使用<<include>>关系，或者直接将通知逻辑整合到「添加订单」的用例描述中：

• <<include>>关系的核心是包含用例是基础用例必须执行的部分，「添加订单」无法脱离通知步骤完成完整的用户反馈
• 这种场景下「发送通知」是下单流程的必要环节，不属于可选扩展

额外提醒 #

库存检查本身建议作为「添加订单」的前置校验逻辑，或者单独拆分为<<include>>的用例（因为下单必须先做库存检查，属于基础用例的必要步骤），避免流程逻辑模糊。

内容的提问来源于stack exchange，提问作者user17329175