なぜ「コラボレーション」は「ユースケース」を実現するのですか？

Question

私はUMLを勉強しています。私は、実現とコラボレーションについていくらか混乱しています。

は

は "電話をかける" コラボレーションです（私は図が正しいことを願っています）図を考えてみましょう。 "接続先"はユースケースです。

本とさまざまな資料によると、私は「電話をかける」と言うと、「接続先に接続する」ことを理解しています。

私が理解する限り、コラボレーションは、（デザインパターンのように）繰り返しパターンをグループ化する論理的な概念です。ユースケース（独自のダイアグラムを持つ）は、それらを実装するユースケースです（間接的に、ユースケースには最終的に関連するクラス図があるため、それらのクラスで実装する必要があります）。

「ユースケース」が「コラボレーション」を実現すると言っても過言ではありませんか？

ここで何が間違っていますか？

---

混乱の原因は、インターフェイスとそれを実装するクラスがあるjavaです。私たちはクラスがインターフェイスを実装すると言う。実装と実装が同じではありませんか？

この混乱に加えて、コラボレーション図と言えば、コラボレーションとは何の関係もないようです。

Answer 1

最初にユースケースがあるためです。おおまかに、システムの付加価値が何であるかを伝えます。そして、この価値がどのように達成されたかの話もあります。ここでは、検討中のシステム（SUC）がこのユースケースをどのように実現しているか（したがって名称）について考え始める。そこで、ユースケースの単一の目標を達成するためのクラス設計の仕組みを示すコラボレーションを構築します。複数のコラボレーションを使用して、SUCのさまざまな側面またはバリアントを表示することができます。

Connect to destinationから他の2つのユースケースに依存しています。それは正しくありません。ユースケースは、SUCがその俳優にもたらした個々の付加価値を表しています。だから、彼らは基本的にお互いに依存することはできません。 SUCのすべてのユースケースは、合計加算値を表します。多くの場合、ユースケースで機能分解を試み、多くのインクルード/エクステンション依存関係を追加します。それは意味のあるユースケースにつながりません。つまり、追加された値は表示されませんが、技術的な可能性が失われます。