UMLの関連付けと構成および詳細レベル

Question

実際、アマチュアUMLの質問をいくつか作成してください。いくつかのドメイン概念をモデル化するUMLダイアグラムを作成し、別の概念に関する情報を「保持」するドメイン概念に出くわした場合、そのエンティティへのスタンプ/参照を保持するか、モデル自体にエンティティ全体を保持する方がよいでしょうか。これは単純な高レベルモデルの作成に関連していることを覚えておいてください。実装段階では、状況が少し異なると確信しています。

たとえば、以下の2つのモデルのどちらが実際に正しいですか？ 1つ目は構成関係にあり、FlightBookingがFlight全体を保持します。 2つ目では、FlightBookingにはFlightへの参照があります。

次に、ドメインの概念をモデル化する高レベルのUMLダイアグラムを作成する場合、実際にどの程度詳細に説明するつもりですか。たとえば、次の図では、フライトに出発地/目的地の詳細を文字列として保持したり、これらの概念の個別のクラスをモデル化して構成関係を作成したりできます。 2つのうちどちらがお勧めですか？

また、フライトが文字列ではなく別のクラスとして出発地/目的地を「保持」する上記をモデル化する場合、2つの方法のどちらがこれをモデル化する正しい方法ですか？いつ連想を示すのか、いつ構成を示すのか、私はかなり混乱しています。

sgokhales · Answer

アソシエーション：
これは、2つのクラスが何らかの関係を持っていることを意味し、実際には何でもかまいません。
例：AはBを使用し、Aは特定の方法でBに関連付けられています。

構成：
これは、「所有権」のモデル化に使用される特殊なタイプの関連付けでもあります。これは集約と非常に似ていますが、全体の関係を表し、「部分」エンティティには独自の独立した存在がないという唯一の違いがあります。

例：AはBで構成されます。 BはAの一部であるため、Aなしでは存在できません。

良い説明： MLクラス図：関連付け、集約、構成

sfinnie · Answer

これが少し長い場合は申し訳ありません...

ドメインの概念をモデル化しようとしている場合は、構成/集約を忘れて、単純な関連付けに固執することをお勧めします。どうして？構成/集約の決定が重要な質問の邪魔になるからです。彼らです：

なぜ関係が存在するのですか？具体的には、どのドメインルール/制約をキャプチャしますか？
どちらかの端のカーディナリティは何ですか？
作成と削除の動作は何ですか？つまり、関連付けのインスタンスを作成/削除するのは誰ですか？

関係の命名relの終わりに名前を付けることで（1）を達成します。役割名（最初の例の「フライト」など）では、なぜ関係が存在するかについては何もわかりません。それであなたの例1では：関係は何を表していますか？機内の指定席ですか？確認済みですか？のために支払われた？現状の図からはわかりません。動詞ベースの命名にはさまざまなアプローチがあります。たとえば、この投稿。なぜこれをするのですか？ドメインを理解していることを確認するように求められるためです。ドメインルールの大部分（私はそれを証明したことはありませんが、おそらく大多数）が関係に存在します。したがって、関係が存在する理由を理解することは、ドメインを理解するための基本です。

カーディナリティおそらく命名よりも明白です。両端（上部と下部の両方）で決定する必要があります。下端で重要なのは、それがオプションであるかどうか（つまり、0または1）です。上端では、1つまたは複数。繰り返しますが、これはドメインからの重要なルールを明らかにします。もう一度あなたの例に戻ります：フライト予約のフライト数は？ 1つのフライトを複数の予約に含めることはできますか？（「in」が意味するものは何でも...）。

動作の作成/削除関係のインスタンスを作成するのは誰ですか？誰が削除しますか？一方の端が削除された場合、もう一方の端はどうなりますか？繰り返しますが、問題のドメインからのすべての重要なルール。

それらはうまくいけばあなたの2番目の質問にも答えます。人間関係を軽蔑しないでください。それらを理解するために時間をかけてください。それらはドメインを理解するための秘訣です。上記のすべての質問に答えることで、構成/集約/関連付けの中から決定しようとするよりもはるかに多くの洞察が得られます。

本当に構成と関連付けを表示したい場合でも、上記の質問に答えると機械的です。

関係の一方の端のカーディナリティーが1：1である場合（つまり、1つにしかなり得ない場合）、および
その同じ端が、もう一方の端のインスタンスを作成および削除する責任があります。
構図として表示できます。

それ以外の場合は、単純な関連付けを使用します。集計については無視してください。語彙からそれを削除します。それが価値があるより多くの混乱を引き起こします。集約で言えることはすべて、適切に定義された単純な関連付けを使用すると、はるかに明確かつ正確に言うことができます。

hth。

PS：構文のポイント：コンポジションは塗りつぶされたひし形を使用します。あなたが示したのは集約です。

Gangnus · Answer

構成、集約、および関連付け。

他のことの前に、AからBへの関連付けが何であるかを理解する必要があります。
- 基本的にはAとBの間の実線です。これは、Aのクラス/インスタンスとBのクラス/インスタンスを接続する1つの構造を表すことができます。構造は任意の種類で、どこにでも属することができます。この行について書かれたすべての情報は、この構造を説明しています。
- Aの1つのインスタンスをBのインスタンスに接続する1つの構造と、BのインスタンスをAのインスタンスに接続する別の構造の2つの構造がある場合、両方を1つの関連付けで表示できます。次に、そのB端について書かれた情報は、最初の構造（b-> a）を記述し、もう一方の端についての情報は、他の構造を記述します。
- AからBにガイドする構造が複数ある場合は、2つの異なる関連付けを描画する必要があります。
- 結合構造が複雑な場合は、それを関連クラスとして表すことができます。そこで、詳細を定義できます。
- 結合構造は3つ以上のクラスを接続でき、これらのクラスへの実線の分岐を持つ大きなひし形として表示されます。まだ連想です！注意：これらの2つのより複雑な関連付けは、既存のツールでは非常に不十分にサポートされています。あなたはそれらで全く無意味な何かを簡単に作ることができます。そして、彼らは難しいです。慎重に使用してください。
C++インスタンスでは、Aはポインタではなく直接Bインスタンスを持つことができます。特別なUML記号はありません。通常のポインタ属性と同じように表示する必要があります。

example Class diagram

組成は、いわゆるブラックまたはフルダイヤモンドで示されます。 containerの側にあります。
もう1つは空のひし形で、「共有アグリゲーション」または略して「共有」と呼ばれます。厳密には定義されておらず、独自の標準を作成するために使用できます。もちろん、それをアイテムとコンテナの関連付けのアイテム側に配置するのはばかげています。しかし、それは簡単に関連付けの両端にある可能性があります。
- なぜコンポジションダイヤモンドは片側だけにできるのですか？構成とは、アイテムがコンテナ（またはコンテナ自体）からの参照として存在する場合にのみ存在することを意味するためです。もちろん、それは双方にとってうまくいくことはできませんでした。
- それどころか、両側の「共有」には意味があることがよくあります。たとえば、Studentインスタンスには、参加しているすべてのコースのリストを含めることができ、Coursesインスタンスには、参加しているすべての学生のリストを含めることができます。
多くの場合、「共有アグリゲーション」に使用される「アグリゲーション」という名前が表示されます。それは悪い間違いです。標準によれば、composition、shared、さらにはnoneであるため、3つすべてが集計です。

そう、 composition のサブセットです aggregation そして aggregation の機能です association

dwk · Answer

最初の例では、構成を含む最初の図が正しいです。 2番目のオプションであるflightIDをintとして参照すると、couldは機能しますが、不完全です。そのint自体では、Flightオブジェクトにアクセスする方法が提供されません。 Flightクラスは、番号で取得できるフライトオブジェクトのリストを魔法のように保存しないため、2番目のオプションではすべてのFlightオブジェクトを保存するために3番目のクラスが必要になります。

2番目の質問については、大まかに言えば、それは実際には個人的な好み（または教授の個人的な好み！）に依存します。最善の判断を下してみてください。