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

【问题标题】：Why do we need to separate or breakdown one Use Case into two or more use cases?为什么我们需要将一个用例分解或分解成两个或多个用例？
【发布时间】：2019-04-21 10:09:59
【问题描述】：

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

【问题讨论】：

可以说得更清楚些，但这是一个很宽泛的问题，和为什么要把一个函数分成两个或多个 ;-)
这道题应该得5分。我可以通过使用包含和扩展关系来解释它吗？（解释他们的目的，为每个人添加一个例子）另外，泛化关系是这个问题的潜在答案吗？
可能是，但你怎么能在不提供任何上下文的情况下希望得到答案？
上下文？你是说案例研究还是场景？
teddy 尝试回答：为什么我需要用f(12) + h('a') 替换f(123)

标签： include uml extend use-case use-case-diagram

【解决方案1】：

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

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

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

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

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

【讨论】：

【解决方案2】：

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

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

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

【讨论】：