关于用例图扩展点使用include及2FA登录流程建模的咨询

让我逐个帮你解答这两个问题：

绝对不推荐这么做，这不符合UML用例图的规范语义。

要搞清楚include、extend以及扩展点的核心定位：

• include是强制依赖关系：基用例在执行过程中必须调用被包含的用例，本质是把重复的通用流程抽出来复用，被包含的用例是基用例完成核心逻辑的必要组成部分。
• 扩展点（extension point）是专门为extend关系设计的：它标记了基用例中可以被外部用例“插入”可选逻辑的位置，extend表示的是条件触发的可选扩展流程——只有满足特定条件时，扩展用例才会被执行，基用例本身可以独立完成核心流程。

如果在扩展点上用include，会完全混淆两种关系的语义：扩展点的位置原本是留给可选逻辑的，而include却强制要求这里必须执行某个流程，这就违背了扩展点的设计初衷。正确的做法是，只有extend关系才应该关联到扩展点上。

这种方式是合理且符合UML语义的，非常适配你描述的场景。

你的场景是用户登录时需要二选一完成2FA（密保问题/短信验证码），核心流程是「登录」，而两种验证方式是可选的扩展分支。具体的设计建议：

• 定义基用例：登录流程，在其中设置一个扩展点，比如命名为「完成2FA验证」，对应登录流程中需要用户选择验证方式的节点。
• 定义两个扩展用例：通过密保问题完成2FA、通过短信验证码完成2FA，分别用extend关系关联到基用例的「完成2FA验证」扩展点上。
• 给每个extend关系加上触发条件：比如用户选择密保问题、用户选择短信验证码，这样能更清晰地表示不同场景下触发的扩展逻辑。

哪怕你的2FA是登录的必要步骤（用户必须选一种方式完成，不能跳过），这种设计依然适用——因为extend在这里表示的是“从多个可选扩展中选一个执行”，而非“可以跳过扩展”，只要明确触发条件，就能准确表达业务逻辑。

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