爲什麼說「協作」實現「用例」而不是反之呢？

Question

我正在學習UML。我對實現和協作有些困惑。

考慮圖（我希望圖是正確的）

「撥打電話」 是一個協作。 「連接到目的地」是一個用例。

根據書籍和各種資源，我讀到，我們說「打電話」實現「連接到目的地」。

但據我所知，協作是一個邏輯概念，我們用它來對重複模式進行分組（如設計模式）。用例（有自己的圖）是實現它們的用例（間接地，因爲用例最終會有相關的類圖，這些類必須實現它們）。

所以我們不應該說「用例」實現「協作」嗎？

我在這裏發生了什麼問題？

---

混亂的根源是java，我們有接口和實現它們的類。我們說一個類實現接口。實現與實現不一樣嗎？

這種混亂的原因是協作圖，這似乎與協作無關。

Answer 1

因爲你第一次有用例。它粗略地說明了系統的附加價值。還有一個故事是如何實現這個價值的。現在你開始思考如何考慮系統（SUC）瞭解這個用例（因此得名）。因此，您可以通過構建協作來展示類設計如何在實現用例中的單個目標方面發揮作用。您可以有多個協作來顯示SUC的不同方面或變體。

關於你的圖：你有從Connect to destination到另外兩個用例的依賴關係。這是不正確的。用例代表了SUC帶給演員的個人附加價值。所以他們基本上不能相互依賴。 SUC的所有用例均代表總增加值。通常人們會嘗試使用用例進行功能分解，並添加大量的包含/擴展依賴關係。這不會導致有意義的用例，也會導致您失去焦點。也就是說，您不會顯示附加值，但會偏離技術可能性。