UML集約：「部分」なしで「全体」がどのように存在できるか
集約は「全体/部分」の関係であり、「親」クラスは全体であり、「子」クラスは部分であり（これは単方向です）、各クラスは（構成ではなく）独立して存在することを理解しています。しかし、私が見たいくつかの例は私を混乱させています。たとえば、path/segment関係です。パスがなくてもセグメントが存在する可能性があることは理解していますが、それらが独立している場合は、パスも存在するはずです。
同じことがcar/wheelにも当てはまります。両方のオブジェクトが独立したライフサイクルを持つことができ、ホイールはまだ車の一部でなくても作成できることがわかりますが、車はウィールなしでどのように存在できますか？車の他の一部が存在する可能性がありますが、車輪があるまで完全な車ではありません...
triangle/lineも見ました。線を引いて三角形にすることも、線だけにすることもできます。しかし、線のない三角形をどのように作成できますか？
これは関係が単方向であるためと思われますが、混乱するのは、両方のクラスが独立しているという事実です。集約せずに子クラスがどのように存在できるかは理解していますが、親クラスが子オブジェクトなしで独自のライフサイクルを持つことができる方法を理解していません。
メンバーのない集約が意味をなす場合があります...システムのクラスの1つが映画を表すと想像してください。そして、あなたはシステムが映画でアクターにクレジットされたままにすることを望みます。俳優のいない映画は意味がありますか？はい。それは、俳優を何とか持たないなんらかのサイレントアニメーションまたは他の芸術的なものである可能性があります。
テセウスのパラドックスに簡単に降りることができる車と車輪よりも、アグリゲーションの優れたテキストブックの例を見つけました（つまり、学生の頭では、主キーをそれに置いています）。ああ、そして、ホイールが同時に2台の車に存在することはできないことを忘れないでください。ただし、俳優は2つの映画でクレジットされても問題ありません。
一方、メンバーのない集計は意味をなさない場合があります。そのために、Multiplicityがあります。会員数の制限はありますか？三角形には3つの線が必要です。それ以上でもそれ以下でもありません。ラインはそれ自体でまだ存在できることに注意してください。したがって、三角形はラインのライフサイクルを制御しません...それはコンポジションではありません。
パスとセグメントの例について。セグメントのないパスは、現在地から同じ場所に移動します。あなたのシステムでそれが理にかなっているかどうかにかかわらず、あなたは決定しなければなりません。つまり、システムごとに答えは異なります。
実際、システムの一部で異なる場合があります。たとえば、ビューモデルオブジェクトとして線のない三角形を許可すると、複数のユーザー入力を作成して着実に取り込むことができるため、理にかなっています。インタラクション...同時に、3つのライン以外の任意の数のTriangleドメインモデルクラスは許可されません...実際、それを格納するために使用されるデータベースエンティティには、その制約がまったくない場合があります（「正確に3」データベースエンジンは簡単ではなく、データベースエンジンによっては不可能である場合があります）。
構成は私のものです！手を離してください。
集約とは、ここに表示されたものを調べることです。
関連とは、私が見つけられるものを探すことを意味します。
これらの例に実際のストーリーをいくつか示してみましょう。
車がタイヤで構成されている場合、それらのタイヤはその車に属し、他には何もありません。自転車に貼り付けないでください。車がジャンクヤードで押しつぶされるとき、タイヤはそれとともに行きます。
車にタイヤの集合体がある場合、それらのタイヤはたまたま車に付いているだけです。彼らは、後で、または今でも何か他のものになるかもしれません。タイヤは自立した生活を送っています。
車はどちらの場合もタイヤが必要です。これは車のニーズについてではありません。タイヤについてです。
構成と集計の違いを説明しようとする実際の例は、違いを意味のあるものにするストーリーを語らないことがよくあり、結局のところ、著者が自分の車のタイヤについてどのように感じているかがわかります。
たとえば、三角形のセグメントは、三角形の一部である一方で、他の形状の一部である場合があります。しかし、これらは、この三角形の一部になる以外には存在しないセグメントである可能性があります。
ストーリーのない例は単に時間の無駄です。それらが理にかなっていると期待するのをやめてください。ストーリーを教えてください。あなたがどんな種類を持っているかを教えてあげます。ストーリーのない例を挙げてください。あなたの車のタイヤについて学ぶすべては私の私の気持ちです。
集計は、UMLによって「意味が共有されるプロパティ」として定義されています（セクション9.5.3）。
プロパティが集計セマンティクスを共有していることを示します。 共有集約の正確なセマンティクスは異なりますアプリケーション領域とモデラーによって。
これはかなり曖昧です：
- 一般に、共有できる部分を含む部分/全体の関係として理解されます。これは、一部が全体なしに存在できることを強く示唆しています。
- 完全に指定されていないため、誤解を招きやすい。したがって、最善の方法は、可能であれば集約を回避することです。パーツ/全体の関係をモデル化するために集約する必要はありません。
共有集約は、複合集約とは異なります。後者の場合、UML仕様は明示的であり、全体（複合）は部品（構成されたオブジェクト）の存在と保管に責任を負うと述べています。したがって、構成された部分は複合全体なしでは存在できません。
これは、あなた（開発者、または開発者のチーム）が問題のモデル化を決定する方法（つまり、問題と関係の理解に基づいて、関連するさまざまな要素を表示および表現することを決定する方法）についてです以内に）。
つまり、同じの例は、2つの異なる方法でモデル化されたさまざまな状況下にある可能性があります（たとえば、レーシングゲームでは、プレーヤーモデルは車モデルの一部と見なされ、その特定の目的のためにゲーム、それは独立した存在を持たないかもしれません;通常あなたが歩いているゲームですが、乗り物を使うことができます、それらは時々「封じ込め」関係を想定するかもしれない別個の実体です）。
そのため、さまざまな資料をオンラインで読むときは、例の詳細にあまり焦点を合わせないでください。ただし、intentを理解し、コンテキストに基づいて行われた仮定と、構成と集約について知っていることについて。
いくつかの例を見てみましょう：
パスとセグメントの関係：ある種の描画ソフトウェア、ある種のアニメーションエディタなどを作成しているとします。ユーザーにとっては、セグメントのないパスはありませんが（おそらく、パスのないフリーフローティングセグメントはありません）、内部的に、開発者として、パスは、交換可能なセグメントを含む抽象的な概念であると考えるかもしれません。さまざまな方法で組み合わせて操作し、特定の特殊効果を実現するために共有することもできます（私は、途中でこれを作り上げています-ところで、これは1つの正しい方法だと言っているわけではありませんやれ）。ですから、あなたにとって、ソフトウェアがどのように機能し、物事がどのように表現されるかという点では、それらは独立して存在しています。プレースホルダーとして機能するnullパス（セグメントなし）、または後で使用する空のセグメントコンテナー、または単にパスインターフェイスを実装する（各メソッドは何も実行しないため）、クライアントコードをより簡単な方法で記述できます。繰り返しになりますが、ソフトウェアのユーザーは、これらの概念についてまったく異なる見方をしている可能性があります。これは、パスを表す問題を解決し、目的の動作をサポートするために内部でどのように取り組んだか、つまり問題をモデル化した方法についてです。
車/ホイール：繰り返しますが、問題の領域によって異なります。ホイールを交換したり、車とホイールを別々に追跡したりする必要がある場合（わかりません。ソフトウェアは自動車修理店向けかもしれません）、それを集約としてモデル化します。車なしで車輪が存在できるようにするために何をしているのかが意味をなさない場合、またはそれをサポートしていないの決定が受け入れ可能であり、問題とコードを簡略化している場合でも、モデル化します構成として。
2つのことに注意してください。最初に、所有権の詳細を指定せずに、一般的な関連付けを使用してモデル化することを選択できます。これで問題ありません。 2つのモデル要素間の正確な関係が重要であり、同じプロジェクトで作業している可能性がある他の開発者にそれを伝えたい場合は、集約と構成を使用します。第二に、言語機能、使用するキーワードなどに関して、これらすべての関係が同じ方法で実装されることがよくあります。違いを生むのは、インスタンスの動作、相互作用、ライフサイクルです。