Проверьте мой UML Class Diagram

Question

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

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

Answer 1

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

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

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

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

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

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

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

7 Элемент может быть только в одном аукционе

8 Элемент, не может существовать без аукциона

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

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

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

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

25 Пользователь может создать много ForumTopics но ForumTopic может быть создан только одним пользователем

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

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

Answer 2

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

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

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

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

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

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

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