0

代替テキスト

このタイプのUMLダイアグラムを描くのが苦手なので、誰かが私のクラス図を確認できますか？

  1. ユーザーは、PersonalUserまたはBusinessUserにすることができます
  2. 管理者は特別なタイプのPersonalUserです
  3. PersonalUserまたはBusinessUserは多くのオークションを作成できます
  4. ただし、オークションは1人のPersonalUserまたは1人のBusinessUserのみが作成できます。
  5. そこにオークションはPersonalUserまたはBusinessUserなしでは存在できません
  6. オークションに含めることができるアイテムは1つだけです
  7. アイテムは1つのオークションにのみ参加できます
  8. アイテムはオークションなしでは存在できません
  9. オークションはアイテムなしでは存在できません
  10. アイテムには1つのカテゴリがあります
  11. カテゴリは多くのアイテムを持つことができます
  12. アイテムはカテゴリなしでは存在できません
  13. カテゴリには親カテゴリを含めることができますが、これは必須ではありません
  14. カテゴリには多くの属性を含めることができます
  15. ただし、属性は1つのカテゴリのみを対象としています
  16. 属性はカテゴリに存在できません
  17. 属性には多くのAttributeOptionを含めることができます
  18. ただし、AttributeOptionは1つの属性にのみリンクされています
  19. AttributeOptionは、属性なしでは存在できません
  20. オークションには多くの入札があります
  21. 入札は1回のオークションのみです
  22. 入札は、オークションと個人ユーザーまたはビジネスユーザーなしでは存在できません。
  23. アイテムは多くの写真を持つことができます
  24. 写真は1回限りのアイテムであり、アイテムなしでは写真は存在できません。
  25. ユーザーは多くのForumTopicsを作成できますが、ForumTopicは1人のユーザーのみが作成できます
  26. ForumTopicsには、1つ以上のForumMessageを含めることができます
  27. ForumTopicはユーザーなしでは存在できず、ForumMessageはForumTopicなしでは存在できません。
  28. BusinessUserは多くのBusinessContactNumberを持つことができますが、BusinessContactNumberは1人のBusinessUser専用です
  29. BusinessContactNumberはビジネスなしでは存在できません
4

2 に答える 2

5

一見すると、多くの集計を使用しました。これは非常にまれです。集計が正当化されるときの良い例を見たことがありません。これは通常、単純な関連付け（全体の関係がない）または構成（全体が削除されると部分が削除される）のいずれかです。

なしでは存在できませんが、集約を意味するものではありません。適切な多重度で十分です。作成できるということは、集約を意味するものではありません。作成者と作成物の間に関連付けが存在する場合を除き、作成物は通常、適切にステレオタイプ化された使用関係（つまり破線の矢印）でモデル化されます（この場合、作成物について明示的に言及する必要はありません）。

4ただし、オークションは1人のPersonalUserまたは1人のBusinessUserのみが作成できます。

その場合、Auction-PersonalUserアソシエーションの多重度をPersonalUser側で1にすることはできず（オークションはBusinessUserによって作成された可能性があるため）、Auction-BusinessUserアソシエーションの多重度をBusinessUser側で1にすることはできません（ほぼ同じ理由で）。 ）。多重度として0..1を使用しますが、3について書くことに注意してください。

3PersonalUserまたはBusinessUserは多くのオークションを作成できます

これは、ユーザーが多くのオークションを作成できるのと同じです。

6オークションに含めることができるアイテムは1つだけです

7アイテムは1つのオークションにのみ参加できます

8アイテムはオークションなしでは存在できません

9オークションはアイテムなしでは存在できません

次に、アイテムとオークションの間に単一の関連付けがあり、両端で多重度が1になります。それから集計を作成したり、2つの関連付けを使用したりしないでください。

13カテゴリには親カテゴリを含めることができますが、これは必須ではありません

アソシエーションの終了にラベルを付けると、それが明確になります。

25ユーザーは多くのForumTopicsを作成できますが、ForumTopicは1人のユーザーのみが作成できます

これは漠然とオークションに関連しているだけであり、オークションとは独立して存在する可能性もあります。フォーラムのものを別のパッケージに入れます。それなら、オークションのものとユーザーのものも別々のパッケージに値するかもしれません。

ところで：あなたは入札サービスについて言及していませんでした。これらのオブジェクトの概念をモデル化するためだけに、薄い空気には存在しないようです。実際には、一部のソフトウェアで使用されています。その場合は省略してください。

于 2011-01-22T15:35:46.233 に答える
1

私は以前の回答者に概ね同意するので、相違点と追加の意見のみを提示します。

もう少し正確に言うと、「作成できます...」は、依存関係を使用して表現する必要があります（使用ではありません）。

  1. 何らかの区別が存在する必要がある場合、それは完全に同等ではありません。何らかの理由で列挙を避けたい場合は、列挙またはUserTypeクラスでUserクラスを使用できます。

6.-9。したがって、オークションまたはアイテムオブジェクトは存在できません。ある方法で関係を緩めて構成を使用するか、これら2つを1つのクラスにマージするか、関連付けクラスを作成します。

  1. たぶん、1つのカテゴリに多くのサブカテゴリを含めることができますか？trueの場合、対応する多重度を編集します。

  2. 4.と同じように、他の答えを表示します。

また、デザイン内のクラスの数を再考してください。クラスは単なるデータホルダーではなく、振る舞いをする必要があります。AttributeOption、Attribute、BusinessContactなどの動作はどうなりますか？ゲッターとセッターは動作にカウントされません...BidingServiceでこの動作をすべて実行することを計画していると思います。そのため、これを削除し、オブジェクトのクラスに応じてこれらのメソッドを分割することをお勧めします。それぞれの方法。

于 2011-01-27T23:58:08.067 に答える