Проверьте мою диаграмму классов UML

Question

Может кто-нибудь проверить мою диаграмму классов, потому что я не слишком хорош в рисовании этого типа диаграммы uml

1. Пользователь может быть PersonalUser или BusinessUser
2. Администратор - это особый тип PersonalUser
3. PersonalUser или BusinessUser могут создавать несколько аукционов
4. Но Аукцион может быть создан только одним PersonalUser или только одним BusinessUser
5. Аукцион не может существовать без PersonalUser или BusinessUser
6. Аукцион может содержать только один предмет
7. Предмет может быть только на одном аукционе
8. Предмет не может существовать без Аукциона
9. Аукцион не может существовать без предмета
10. У предмета есть одна категория
11. Категория может иметь много предметов
12. Предмет не может существовать без категории
13. Категория может иметь родительскую категорию, но это не обязательно
14. Категория может иметь много атрибутов
15. Но атрибут только для одной категории
16. Атрибут не может существовать Категория
17. У атрибута может быть много атрибутов
18. Но AttributeOption связан только с одним атрибутом
19. AttributeOption не может существовать без атрибута
20. Аукцион может иметь много ставок
21. Ставка только на один аукцион
22. Заявка не может существовать без Аукциона и Личного пользователя или BusinessUser
23. У предмета может быть много картинок
24. Изображение только для одного предмета, и изображение не может существовать без предмета
25. Пользователь может создать много тем форума, но форум может создать только один пользователь
26. ForumTopics может содержать одно или несколько сообщений ForumMessage
27. ForumTopic не может существовать без пользователя, а ForumMessage не может существовать без ForumTopic
28. BusinessUser может иметь несколько BusinessContactNumber, но BusinessContactNumber предназначен только для одного BusinessUser
29. BusinessContactNumber не может существовать без Business

Answer 1

На первый взгляд, вы использовали много агрегатов.Это довольно необычно.Я никогда не видел хорошего примера, когда агрегация оправдана.Обычно это либо простая связь (без отношения целой части), либо композиция (часть удаляется при удалении целого).

Не может существовать без , не подразумевает агрегирование.Достаточная кратность достаточно. Может создавать не подразумевает агрегацию.Создание обычно моделируется с использованием подходящего стереотипного отношения использования (то есть пунктирная стрелка), если только связь между создателем и созданием не существует (в этом случае создание не должно упоминаться явно).

4 НоАукцион может быть создан только одним PersonalUser или только одним BusinessUser.

Тогда кратность ассоциации Auction-PersonalUser не может быть 1 на стороне PersonalUser (поскольку аукцион мог быть создан BusinessUser) и множественность ассоциации Auction-BusinessUser не может быть 1 на стороне BusinessUser (по той же причине).Используйте 0..1 в качестве кратности, но остерегайтесь того, что я напишу о 3.

3. PersonalUser или BusinessUser могут создавать несколько аукционов

Это эквивалентно Пользователь может создать несколько аукционов .

6. Аукцион может содержать только один предмет

7. Предмет может быть только на одном аукционе

8 Предмет не может существовать без Аукциона

9 Аукцион не может существовать без Предмета

Тогда существует единственная связь между Предметом и Аукционом с кратностью 1 на обоих концах.Не делайте из этого агрегатов и не используйте для этого две ассоциации.

13 Категория может иметь родительскую категорию, но это не обязательно

Тобудет ясно, если вы пометите, что ассоциация заканчивается.

25 Пользователь может создать много тем форума, но форум может создать только один пользователь

Это только смутносвязаны с аукционами и могут также существовать независимо от них.Поместите материал форума в отдельный пакет.Тогда, возможно, аукционные и пользовательские вещи также заслуживают отдельных пакетов.

Кстати: вы не упомянули тендерную службу.Кажется, только для того, чтобы смоделировать концепцию , эти объекты не существуют в воздухе, они фактически используются некоторым программным обеспечением .В таком случае, оставьте это.

Answer 2

Я в значительной степени согласен с предыдущим респондентом, поэтому я представлю только различия и дополнительные мнения.

Чтобы быть более точным, «Может создать ...» должно быть изображено с использованием отношений зависимости (не использует).

1. Это не совсем эквивалентно, если какое-то различие должно существовать.Вы можете использовать класс User с перечислением или класс UserType, если по какой-то причине хотите избежать перечислений.

6.-9.Таким образом, объект Аукцион или Предмет не может существовать.Либо ослабьте связь одним способом и используйте композицию, либо объедините эти два в один класс, либо создайте класс ассоциации.

1. Может быть, одна категория может содержать много подкатегорий?Если true, отредактируйте соответствующую кратность.

2. То же, что и 4., просмотрите другой ответ.

Также переосмыслите количество классов в вашемдизайн.Классы не просто держатели данных, они должны иметь поведение.Каково будет поведение AttributeOption или Attribute или BusinessContact и т. Д.?Методы получения и установки не учитывают поведение ... Я предполагаю, что вы запланировали все это поведение в BidingService, поэтому я советую вам удалить его и разделить эти методы в соответствии с тем, какой класс объектов должен отвечать за поведение, достигаемое с помощьюсоответствующий метод.