6

私は最近、私が書いたさまざまなSWコンポーネントの詳細なUML設計を実行するのにかなりの時間を費やしました。私が最近終えたことを振り返り、それを最初にUMLを学んだときと比較すると、今ではほぼ厳密に集約と構成の関係を使用し、「バニラ」の無向/有向の関係を事実上放棄していることがわかります。もちろん、私はまだ一般化と実現を使用していますが、これらは上記のものとは明らかに異なり、この質問の一部とは見なされません。

アグリゲーション/コンポジションは、「バニラ」アソシエーションなどと同じ意味を持っているように私には思えます。アグリゲーションとコンポジションは当然方向性を意味します。最新のUMLプログラムでは、アグリゲーション/コンポジションの関係に多重度を定義し、その関係に動詞を適用することもできます。その時点で、私はバニラ協会にほとんど目的を見ていません。

アグリゲーションとコンポジションの違いを理解するのが難しい人もいると思います。早い段階で、それらがどのように異なるかを理解するのは少し困難でした。混乱がバニラアソシエーションを使用した理由の一部だったと思います。私は今、バニラアソシエーションの使用がほとんどまたはまったく見られず、実際には、バニラアソシエーションがいくつかの問題（特に2つのオブジェクト間の強いまたは弱いライフサイクル関係）を残していると信じているため、それらが使用されるのを見るのが嫌いです。バニラアソシエーションの唯一の実用的な用途は、目前の問題についての理解がまだ十分に発達しておらず、集約と構成のライフサイクルの違いを判断できない場合だと思います。そのような場合は、少なくともショーをする方が良いです関係が存在し、目前の問題をよりよく理解したときに、戻って適切に変更できること。

簡単に言えば、人々がバニラアソシエーションを使用する時間の大部分は、より正確には集合体として、場合によっては構成として説明できると思います。私は自分の信念がひどく間違っていますか？私は何かが足りないのですか？聞かせて！

4

5 に答える 5

3

実際、UMLクラスモデルでの関連付けのほとんどのケースは、集約でも構成でもありません。たとえば、出版社によって出版された本はこの出版社の一部または構成要素ではないため、クラス間の関連付け、PublisherおよびBook出版社によって出版された本をこの出版社に割り当てるための関連付けは、集約でも構成でもありません。

出版社と本の間の関連のモデル

集約は、部分全体の関係の意図された意味との特別な形式の関連付けですが、正確なセマンティクスはありません（UML仕様では、「共有集約の正確なセマンティクスはアプリケーション領域とモデラーによって異なります」と記載されています）。たとえば、クラス間およびクラス間の集約をモデル化できます。エンジンCarは車の一部であり、講義はコースの一部であるためです。EngineCourseLecture

コンポジション（UML仕様では「コンポジットアグリゲーション」とも呼ばれます）は、コンポーネントインスタンスが一度に最大で1つのアグリゲートインスタンスの一部である（つまり、複数のアグリゲート間で共有できない）特殊な形式のアグリゲーションです。つまり、との間の集約はCar（Engine2台の車で同時にエンジンを共有できないため）構成ですが、講義は2つのコース間で共有できるため（データベース管理など）、との間の集約CourseはLecture必ずしも構成ではありません。コースとソフトウェアエンジニアリングコースでは、UMLに関する講義を共有できます）。これは、アグリゲート側でのコンポジションの関連付けの終了の多重度が1または0..1のいずれかであることを意味しますが、非コンポジットアグリゲーションの場合は*の場合もあります。

コンポジションのこの主な特性（排他的なパーツを持つ）に加えて、コンポジションには、アグリゲートとそのコンポーネントの間にライフサイクルの依存関係があり、アグリゲートが削除されると、そのすべてのパーツが一緒に削除されることを意味します。ただし、これは構成の一部のケースにのみ適用され、他のケースには適用されないため、明確な特性ではありません。UML仕様には、「複合インスタンスが削除される前に、一部が複合インスタンスから削除される可能性があるため、複合インスタンスの一部として削除されない可能性があります」と記載されています。車とエンジンの構成の例では、車が破壊される前にエンジンを車から取り外すことができるのは明らかです。この場合、エンジンは破壊されず、再利用できます。

于 2014-08-04T13:59:17.367 に答える
2

バニラアソシエーション、アグリゲーション、コンポジションは、次のセマンティクスで説明されることがあります。

  • バニラアソシエーション：1つのオブジェクトが「知っている」1つ以上の他のオブジェクト
  • 集約：1つのオブジェクトが「1つ以上の他のオブジェクトを持っている」
  • 構成：1つのオブジェクト'は'1つ以上の他のオブジェクトで構成されます-サブオブジェクトは構成コンテナなしではありえません

集約と構成のほとんどの違いは、「マスターオブジェクトがなくなった場合、パーツオブジェクトはどうなるのか」という質問を回避します。

したがって、「カスケードの削除時」のような整合性制約を、3つのオプションのいずれかを使用する際の差別化を使用して記述するという考え方があります。UMLには、このための3つの異なる記号があります

  • シンボルなし-バニラ協会
  • ダイヤモンド-集約
  • 満たされたダイヤモンド-組成

これらの3つのオプションの問題は、特に時間の経過とともに変化する状況を見る場合、セマンティクスが実際の状況に対して十分に正確ではないことです。

例： 「私の車にはタイヤホイールがいくつありますか？」という簡単な質問に答えようとしています。 さまざまな答えにつながります：

  • 私の車に恒久的に取り付けられている4つの車輪
  • 緊急時に使用するスペアタイヤ1本
  • 私の夏または冬のホイールであり、他の季節には車に取り付けられていない4つのホイール

車のホイール

見る

車がなくなると、これらの車輪はいくつなくなりますか？UMLが提供する3つの記号を使用してこの状況をモデル化しようとすると、モデルが実際に何を意味するのかについて多くの議論と交渉が行われることになります。集約記号と構成記号を使用しない方がはるかに良いと思いますが、代わりに、常に数行のテキストで可能な限り正確に関連付けのセマンティクスを記述します。このようにして、モデルを読んでいる人々にあなたが本当に欲しいものを明確にすることができます。「車は車輪を含むパーツの組み合わせだ……」と書いても大丈夫だと思います。

しかし今、あなたは作曲記号を使用していませんが、実際に何かを作曲する行為を参照しています。

http://de.wikipedia.org/wiki/Assoziation_%28UML%29#Aggregation_und_Komposition （ドイツ語）も参照してください 。

于 2014-08-04T17:46:11.083 に答える
1

クラス図では、クラス間の静的な関係について考えています。クラス図でこれらの関係の動作の側面について考える必要はおそらくないでしょう。それは単に水を濁し、過剰分析の証拠です。（もちろん私見）

于 2009-07-16T23:18:38.513 に答える
1

「バニラアソシエーション」と言うとき、頭に浮かんだのは、目前の問題についての理解がまだ十分に発達しておらず、ライフサイクルの違いを判断し、関係が存在することを示してから戻ってくることができる場合だけです。手元の問題をよりよく理解できたら、適切に変更してください。

UMLメタモデルは、アグリゲーションとコンポジションをアソシエーションの拡張として定義します。ドメインオブジェクトが洗練されていないクラスであるのと同じように、アソシエーションはドメインオブジェクト間の洗練されていない関係と見なすことができます。私は通常、ドメインモデリングの段階で単純な関連付けを使用し、詳細なクラスモデルを解決するときに、必要に応じて構成または集約のいずれかに改良します。

于 2009-10-07T15:39:02.757 に答える
0

集約と構成の両方は、関係の参加者が他の参加者を「支配する」ことを意味します（構成では、支配がより強くなります）が、通常の関連付けにはこの意味がありません。したがって、両方の参加者が関係において同じ重要性を持っている場合、私は通常の関連付けを使用します

于 2009-07-16T19:56:42.320 に答える