为什么说“协作”实现“用例”而不是反之呢？

Question

我正在学习UML。我对实现和协作有些困惑。

考虑图（我希望图是正确的）

“拨打电话” 是一个协作。 “连接到目的地”是一个用例。

根据书籍和各种资源，我读到，我们说“打电话”实现“连接到目的地”。

但据我所知，协作是一个逻辑概念，我们用它来对重复模式进行分组（如设计模式）。用例（有自己的图）是实现它们的用例（间接地，因为用例最终会有相关的类图，这些类必须实现它们）。

所以我们不应该说“用例”实现“协作”吗？

我在这里发生了什么问题？

---

混乱的根源是java，我们有接口和实现它们的类。我们说一个类实现接口。实现与实现不一样吗？

这种混乱的原因是协作图，这似乎与协作无关。

Answer 1

因为你第一次有用例。它粗略地说明了系统的附加价值。还有一个故事是如何实现这个价值的。现在你开始思考如何考虑系统（SUC）了解这个用例（因此得名）。因此，您可以通过构建协作来展示类设计如何在实现用例中的单个目标方面发挥作用。您可以有多个协作来显示SUC的不同方面或变体。

关于你的图：你有从Connect to destination到另外两个用例的依赖关系。这是不正确的。用例代表了SUC带给演员的个人附加价值。所以他们基本上不能相互依赖。 SUC的所有用例均代表总增加值。通常人们会尝试使用用例进行功能分解，并添加大量的包含/扩展依赖关系。这不会导致有意义的用例，也会导致您失去焦点。也就是说，您不会显示附加值，但会偏离技术可能性。