我建模基本用例及其扩展用例。我一直在阅读当基本用例满足条件时，触发并执行扩展用例，并且在执行扩展用例之后，恢复基本用例。 我怀疑扩展用例是否可以终止继续使用的基本用例的流量？
在＆＃34;撰写有效使用案例＆＃34; 一书中，有一个基本用例是＆＃34的ATM示例;使用ATM＆＃34;和扩展用例是 ＆＃34;使用其他银行的卡＆＃34;。在这种情况下，我认为正确地完成了扩展用例的流程（当用户不接受使用外部银行ATM的费用时）
答案 0 :(得分：3)
好吧，基本上任何异常都可以随时终止用例。所以答案很简单＆＃34;是的，它可以＆＃34;。
然而，虽然Cockburn是使用案例的教皇，但他更像是技术人员而非分析师。用例是附加价值。 UC＆＃34;使用ATM＆＃34;不仅值得怀疑。它没有说明使用的任何信息。您可以使用自动取款机将它绑在Cockburn的脚上并将他淹死在最近的海域。此外，应该简单地避免扩展/包含，因为它们不会为用例合成增加好的价值（原文如此！），而是引诱人们进行功能分解。只有极少数情况才有意义。即使在那里，你也可以没有他们。
我建议更多地阅读Bittner / Spence。在我看来，他们得到了它。保持Cockburn强调＆＃34;写＆＃34;，但读Bittner / Spence到＆＃34;理解＆＃34;。
答案 1 :(得分：0)
在多次尝试保持此类扩展准确且易于阅读之后，我最终将它们包装到＆＃34;系统验证某些条件已满足＆＃34;。在本书中，这种情况并未真正给出一个完整的用例（或者我发现了一个错误的用例），所以我将从头开始编写提议方法的示例。
级别：用户目标
...
3. User provides amount.
4. User confirms operation.
5. [UC_02 System validates transaction].
6. System performs transaction.
...
9. System returns the card.
前提条件：步骤5验证失败。
6. System displays error message to User.
7. The use case continues from step 9.
等级：子功能
...
3. [UC_06 System validates that user agrees with processing fee].
4. [UC_07 System validates that there is enough money on the account].
...
前提条件：步骤3验证失败。
4. The use case terminates.
P.S。对于单个用例，9个步骤通常太多了，我只是强调它们。