どちらの場合も、ダイヤモンドに最も近いクラスは、ダイヤモンドから最も遠いクラスを含むクラスです。関係は、単一の包含オブジェクトまたはそれらのコレクションを示します。通常、それはデータベースのERM図で使用されているものと同様の凡例で「1..1」、「1..m」などのようにグラフィカルに示されます。
塗りつぶされたひし形は合成を意味します。含まれているオブジェクトはコンテナの外ではほとんどまたはまったく使用されず、おそらくコンテナはそれらなしでは不完全です（または無効/それらなしで不安定な状態）。たとえば、すべてのiPhoneにはタッチスクリーンパネル（側面にフラットケーブルが接続された透明なもの）があります。 iPhoneから分離されたタッチスクリーンパネルはあまり役に立ちません。フラットケーブルが垂れ下がっている状態で、タッチスクリーンパネルを取り外してポケットに入れている人は見えません。
空のひし形は集約を意味します。含まれているオブジェクトはコンテナとは別に存在することができ、コンテナの外で役立ちます。コンテナは、含まれているオブジェクトがなくても存続できます。キーチェーンは、多数のキーが接続された複合オブジェクトであり、キー、レーザーポインター、缶切りは、キーチェーンに接続されていなくても単独で機能し、キーチェーンもツール（キーなど）も不安定な状態のままになります状態。このアイテムをキーチェーンに追加したり削除したりできますが、それらは機能ツールとして単独で存在できます。キーチェーン自体は空っぽになる可能性があり、そのために壊れているとは言えません。
この回答もご覧ください： https://softwareengineering.stackexchange.com/a/336764/61852
これは、例が役立つものです。
私たちは池にアヒルの集合体を持っています。少なくともアヒルの季節になると。アヒルには池がありません。まあ、彼らはそれから飲みますが、それは別の関係です。車とキャブレターの関係とは異なり、池はアヒルで構成されていません。アヒルが去っても、池は池ではありません。
関連関係の方向を表す矢印は、集約を表す必要さえありません。
この時点でUMLには多くのバージョンがあり、人々は必ずしも正式なルールに忠実であるとは限らないため、ほとんどすべての クラス図 を独自の言語のように扱う必要があります。
FWIW pのUML仕様から定義を追加します。 110：
noneプロパティに集約セマンティクスがないことを示します。共有しました
sharedプロパティが共有セマンティクスを共有していることを示します。共有集約の正確なセマンティクスは、アプリケーション領域とモデラーによって異なります。
compositeプロパティが複合的に集約されていることを示します。つまり、複合オブジェクトは、構成されたオブジェクトの存在と格納に責任を持ちます（11.2.3のパーツの定義を参照）。
特にshared（白抜きのひし形を使用した例）の説明は、「特定の意味はない」と記載されているため注目に値します。したがって、ドメインで使用する十分な理由がない限り、これは避けてください。後者の場合、そのセマンティクスの明示的な定義が必要です。