, если пользователь может быть частью многих групп, а группа может содержать много пользователей, в UML это отношение должно быть представлено как отношение агрегирования? или мы можем просто использовать простую ассоциацию?отношение агрегации пользовательской группы в UML
ответ
В большинстве случаев достаточно ассоциации. Скорее всего, вы добавите множественность в любой конец, чтобы показать, что пользователь (должен быть) по крайней мере один или может быть во многих группах (конечно, это зависит от домена), поэтому вы увидите множественность 1..*
. И наоборот, у группы будет 0..*
пользователей.
Вы можете использовать Aggregation
(полый алмаз на стороне группы), чтобы показать, что группа образована несколькими пользователями. Использование композиции обычно (в контексте управления пользователями) не имеет смысла, поскольку это означает, что группа может состоять только в том случае, если есть пользователи, которые принадлежат ей.
Во всяком случае, в контексте управления пользователями я бы не использовал Aggregation
. Причина в том, что пользователь и группа являются концепциями почти на одном уровне (YMMV), а Aggregation
расскажет читателю, что агрегированный элемент находится на более низком уровне, чем агрегирующий.
В этом случае ясно, что «композитный» не является вариантом, поэтому он будет либо «общим», либо «ни одним». OMG спецификация определяет общие, как это:
«Точная семантика общей агрегации зависит от области применения и модельера.»
Таким образом, вы можете выбрать либо из вариантов. Если вы хотите, чтобы представить это в UML диаграмме ,,,,,
("1 .. *" может быть право множественность ..)
Мой ответ основан на UML Спецификация 2.4.1 - [7.3.2 AggregationKind]
AggregationKind является перечислением следующих значений литералов:
ни
Указывает, что свойство не имеет A ggregation.
совместно
Указывает, что свойство имеет общую агрегацию.
композит
Указывает, что свойство агрегируется композитно, т.е. составной объект несет ответственность за существование и хранения объектов, состоящих (частей).
Семантический Вариация Очки
Точная семантика общей агрегации варьируется в зависимости от области применения и моделировщика.
Порядок и способ создания экземпляров частей не определены.
- 1. Отношение диаграмм класса UML
- 2. [UML] Композиция против агрегации: уточнение
- 3. Может ли отношение агрегации в UML иметь отношение один к одному
- 4. Определение UML - классы обобщения, агрегации и абстракции
- 5. Условное отношение зависимости UML
- 6. Отношение зависимости UML
- 7. функция пользовательской агрегации в dcast
- 8. MongoDB агрегации группы $ толчок
- 9. Отношение классов нотации UML Java
- 10. Как использовать отношение агрегации в диаграмме классов?
- 11. Две группы функций агрегации по
- 12. Условный группы путем агрегации в SQL (улей)
- 13. Django 1.5 + Отношение пользовательской модели
- 14. Отношение UML от одного до многих классов
- 15. Отношение UML статического вызова от другого класса
- 16. UML отношение между usecases (удлините/включить)
- 17. Как определить ключевую функцию для группы агрегации
- 18. Структура агрегации Mongo: пользователи группы по возрасту
- 19. Mongo средний запрос агрегации без группы
- 20. MongoDB агрегации $ группы, а затем $ толкать объект
- 21. Какое отношение «интерфейс расширяет интерфейс» выглядит в UML?
- 22. Как показать отношение частного наследования в диаграмме классов UML
- 23. Как создать отношение пользователя/ролей в диаграмме классов UML?
- 24. Как добавить отношение many2one к пользовательской модели
- 25. Найти отношение группы пользователей и AD через вложенные группы AD
- 26. aggreagation вид в UML
- 27. UML-сопоставление в C#
- 28. отношение Compute размеров группы с использованием SQL
- 29. Rails 4 has_many отношение группы по
- 30. UML Диаграммы классов: Взаимодействие с элементами коллекции
большое вам спасибо – Yuri