UML集約と関連付け
ここに、集約と関連付けに関する別の質問があります。 UMLの基礎を学びたかったので、Martin Fowlerによる「UML蒸留」を読み始めました。私はクラスに関する両方の章を読みましたが、私が思うに完全に把握できないことが一つあります。それは集約と関連付けです。本にはこの引用があります：
UML以前の時代、人々は通常、集約とは何かについて漠然としていました。曖昧であるかどうかにかかわらず、彼らは常に他の皆と矛盾していました。そのため、多くのモデラーは、さまざまな理由で集計を行うことが重要だと考えています。そのため、UMLには集約（図5.3）が含まれていましたが、セマンティクスはほとんどありませんでした。ジム・ランボーが言うように、「それをプラセボのモデリングと考えてください」[Rumbaugh、UML Reference]。
この引用とStack Overflowで読んだトピックから理解しているように、使用する2つのリレーションのうちどちらを使用しても問題ありません。基本的に同じことを意味します。および/またはクラス図の「意味」を変更せずに一方を他方に変更できませんでしたか？
この本は2003年のものであり、この数年でいくつかのことが変わった可能性があるためです。
Rumbaughの声明は、最も重要であり、叔父ボブの良いアドバイスです。 elsewhere で述べたように、集約は意味的に非常に弱く、実質的に何も有益ではありません。有効なコーナーケース（再帰的な関係の非周期性）は1つしかありませんが、それを知っている人や理解している人はほとんどいません。だからとにかくコメントで指摘する必要があります。
使用しません。そして、損失を感じたことはありません。単純なバイナリアソシエーションに固執し、本当に重要なことに集中します-カーディナリティと命名を正しくします。決定不能なアソシエーションと集約を決定しようとすることよりも、はるかに多くのことが得られます。
hth。
たぶんこれはあなたを助けることができますが、私はあなたが完璧な説明を見つけるとは思わない：
違いは含意の1つです。集約は全体/部分の関係を示しますが、関連付けはそうではありません。ただし、2つの関係の実装方法に大きな違いはない可能性があります。つまり、コードを見て、特定の関係が集約であるか関連付けであるかを判断することは非常に困難です。このため、集計関係を完全に無視することは非常に安全です。
[ロバートC.マーティン| UML]
そして、各状況の例：
a）関連付けは、すべてのオブジェクトに独自のライフサイクルがあり、所有者がいない関係です。教師と生徒の例を見てみましょう。複数の生徒が単一の教師に関連付けられ、単一の生徒が複数の教師に関連付けられますが、オブジェクト間に所有権はなく、両方に独自のライフサイクルがあります。どちらも独立して作成および削除できます。
b）集約は、すべてのオブジェクトに独自のライフサイクルがありますが、所有権があり、子オブジェクトが別の親オブジェクトに属することができない特殊な形式の関連付けです。学科と教師の例を見てみましょう。 1人の教師が複数の部門に属することはできませんが、部門を削除しても、教師オブジェクトは破棄されません。 「has-a」関係について考えることができます。
[Maesh | GeeksWithBlogs]
私は、Aggregationを使用して、1つの大きな違いがあるコンポジションと同じ関係を示す傾向があります。含まれるクラスは、含まれるオブジェクトのライフサイクルを担当しません。通常、（null以外の）ポインターまたは含まれるオブジェクトへの参照は、包含クラスのコンストラクターに渡されます。含まれるオブジェクトは、そのライフサイクルの間、存在する含まれるオブジェクトに依存します。含まれているオブジェクトは、含まれているオブジェクトなしではそのジョブを（完全に）実行できません。これは、集計によって暗示される「部分/全体」関係の私の解釈です。
この用語はしばしば混乱します。
アグリゲーションとコンポジションはアソシエーションのタイプの一部です。実装中にアグリゲーションとアソシエーションの間に違いはほとんどなく、多くはアソシエーション関係を持つダイアグラムでアグリゲーション関係をスキップします。
この類推からアイデアを得ることができます。
Class：A（person）およびClass：B（car）は関連付け関係、ifClass：AにClass：B宣言、およびClass：B（car）オブジェクトは必須ではないを作成してClass：A（person）オブジェクト。
Class：A（car）およびClass：B（tyre）は集約関係、ifClass：AにClass：B宣言、およびClass：B（tyre）オブジェクトは必須を作成してClass：A（car）オブジェクト。
乾杯！
UMLでは、集約は不十分に定義されており、明確に定義されたセマンティックを持っていないためです。集約の有効な使用例は、Eric Evansによる「ドメイン駆動設計」で述べられているように、いくつかのクラスのカプセル化です。
例えば。車には4つの車輪があります。車ごとに、各車輪が駆動したメートルの合計量を計算することができます。この計算は、車のエンティティによって行われます。これは、どの車輪がどの車輪に属しているかを気にする必要がないためです。
車は車輪などのすべての部品の集約ルートであり、集約の外部から車の部品にアクセスすることはできず、ルートだけにアクセスできます。
したがって、基本的に集約は、互いに属するクラスのセットをカプセル化します。
実装に関しては大きな違いはありませんが、概念的には大きな違いがあります：階層を表現するために集約が使用されます。コンポーネントの階層を操作する場合、ルートインターフェイスで必要な特定のタイプの操作があります。
- 階層内のサブコンポーネントを見つける
- 階層への/からのサブコンポーネントの追加/削除
- すべてのコンポーネントの共通属性を変更します
- 階層を再帰的に走査する（訪問者パターン）
- コンポーネント間の階層とリンク（関連付け）を再構成する
関連付けを処理する場合、これらの操作のほとんどは必要ありません。
追加するには、OMGサイトからUML仕様をダウンロードすることをお勧めします。最適なリファレンスとp 110を参照してください。
noneプロパティに集計セマンティクスがないことを示します。
sharedプロパティが共有集計セマンティクスを持っていることを示します。共有集約の正確なセマンティクスは、アプリケーション領域とモデラーによって異なります。
compositeプロパティが複合的に集約されていることを示します。つまり、複合オブジェクトは、合成オブジェクトの存在と保存に責任を持ちます（11.2.3のパーツの定義を参照）。