ARLOW, J., AND NEUSTADT, I. UML 2 and the Unified Process, 2nd ed
ブック、異なるオブジェクト間の関係には7つのタイプがあります。
依存
協会
集計
組成
封じ込め
汎化
実現
しかし、私は別の場所で、リレーションシップが次の条件のいずれかである場合、それはaggregationリレーションシップである必要があることを読みました:
a)メンバーシップb)封じ込めc)議会
問題は、集約と包含関係の違いを別の関係として見つけられないことです。
用語については多くの混乱がありますが、すべての定義が一致するとは限りません。
包含とは、包含オブジェクトが包含オブジェクトを直接公開しないことを意味します。独自のインターフェースを公開し、クライアントに代わって含まれているオブジェクトを呼び出す場合があります。したがって、クライアントが含まれているオブジェクトを混乱させる方法はありません。包含オブジェクトは、包含オブジェクトを所有し、作成した可能性があります。オーナーがあなたのために注文したものをすべて作成し、結果を提供するカウンター付きの食堂のように。
集約では、集約オブジェクトが集約オブジェクトのインターフェースを直接公開しています。クライアントが集約オブジェクトを呼び出すと、集約オブジェクトは仲介者として機能せず、クライアントは集約オブジェクトを直接操作します。集約オブジェクトは、集約オブジェクトなしで存在する可能性があり、後者はそれを所有せず、通常は作成しませんでした。それ。独自のインターフェースを通じてアクセスできるようにするだけです。キッチンにアクセスして自分で食事を作ることができるセルフサービスのダイナーのように。
参照しているコネクタはパッケージのマージです。 UML 2.5のP. 276:
パッケージのマージは、あるパッケージのコンテンツが別のパッケージのコンテンツによってどのように拡張されるかを定義します。
その背後にある規則は、UML 2.5 pに詳細に(詳細に)記載されています。 240。
サークルプラス表記は、<<merge>>
キーワードを使用した破線の開いた三角形(依存関係)の代替です。
ほとんど(すべて?)のUMLツールは、ネストできる(および要素/ダイアグラムを含むことができる)パッケージを使用することにより、構造的な包含を可能にします。これらの場合、パッケージのマージは必要ありません。パッケージの依存関係を記述し、抽象/メタレベルでマージする場合は、そのコネクタを使用します。これらのオントロジーがうまく分離されなかったのは少し不運です。したがって、ツールベースの包含を使用し、これらのコネクタを上から使用するモデルを見つけます。