include - 为什么我们需要将一个用例分解或分解成两个或多个用例？

Question

在许多情况下，为什么您需要将一个用例分离或分解为两个或多个用例？

Answer 1

将一个用例拆分为多个用例的唯一原因是通过在单独的用例中隔离该功能，在多个用例之间共享一个重要的功能。

示例：“搜索产品信息”可能是包含在用例“购买产品”和“租用产品”中的单独用例。

除了“包含”之外，还有使用“扩展”或“概括”的相同原理的示例。

通过这样做，您可以防止在多个用例中复制共享行为，从而增加不一致的可能性。

在前面的示例中：我们希望确保客户在购买时不会以与租用产品时不同的方式来搜索产品信息。使用包含的用例，阅读用例的人会立即意识到这一事实。

Answer 2

首先：你没有。开始这样做意味着您正在进行功能分析。用例综合的重点是找到不同参与者在与所考虑的系统交互时的目标（也就是附加值）。在那个层次上把​​一个目标分成子目标是徒劳的。要么你有一些附加价值，要么你没有。因此，如果有人已经解决了一个用例并试图将其分解，那么该用例要么是错误的（没有用例），要么是无用的，因为用例已经显示了附加值。

我个人对 include 和 extend 的看法：它们基本上是邪恶的，并且是没有商业背景的技术人员（大多数 UML 设计人员都是）引入的错误概念。使用它们意味着您已经开始了功能分析。但是 UC 是从需求中合成的。也就是说，您将您的网络从需求汤中拉出来，并找出那些适合在一起的故事，以构建一个有意义的故事 - 并提供附加价值：一个用例。

和往常一样：阅读 Bittner/Spence 关于用例的信息。