Должна ли агрегация быть один ко многим?

Question

Я всегда избегал использования агрегации, потому что она кажется настолько субъективной, что отношения один ко многим следует классифицировать как агрегацию.Но я рассматриваю модель, созданную кем-то другим, в которой агрегаты используются для отношений «многие ко многим» (например, курс состоит из нескольких модулей, модуль может быть частью нескольких курсов).Это кажется мне совершенно неправильным, но я не могу найти окончательного правила против этого.Какое официальное решение?

Answer 1

Две вещи:

1. Разрешены ли общие агрегации?Согласно спецификации UML, да.
2. Это полезно на практике?Обычно я бы сказал нет.

Я не фанат отношений агрегации UML.Хотя владение интуитивно привлекательно, оно слишком субъективно практически.Я не использую его, и, как правило, не рекомендую его использовать (хотя см. Сноску).Вместо этого сосредоточьтесь на важных вопросах:

1. Что такое кардинальность?
2. Что такое поведение создания / удаления?
3. Почему существуют отношения?(т.е. какой бизнес-факт / правило захватывает отношения?

Все вышеперечисленное может быть сделано с прямыми ассоциациями. Если ответ (а) один-ко-многим, (б) конец «один»отвечает за создание / удаление конца 'many' и (с), который вы действительно хотите, затем использование объединения Composite. Однако агрегация, как правило, не улучшает читабельность модели, она добавляет путаницу и мешает выходу на поверхность базовых правил домена /требования.

hth.

сноска: существует один сценарий, в котором агрегация имеет четко определенную семантику и может быть полезной. В частности, если у вас рекурсивная связь, агрегация говорит о структуре результирующего объектаявляется ациклическим (то есть DAG). Недостатком является то, что относительно мало людей понимают, что это свойство - конечно, не эксперты в области бизнеса. Поэтому вам, как правило, приходится выделять в любом случае, например, в комментарии / ограничении.

Answer 2

Хороший веб-сайт для этого:

http://www.uml -diagrams.org / class-diagrams.html

Если вы ищете там «Общая и составная агрегацияmsgstr "вы прочтете, что общие части могут быть смоделированы как агрегаты.Даже если состав, удерживающий деталь, будет отброшен, детали могут выжить.

Кажется, что это делает возможным множество отношений.Например, совместное использование части представления для нескольких компонентов представления.Почему бы не ...

Лично это соответствует моему пониманию того, что UML очень интерпретативен.

Answer 3

1. Давайте установим условия. Агрегация является мета-термином в стандарте UML и означает ОБА композицию и общую агрегацию, просто названную shared . Часто это называется неправильно «агрегация». Это ПЛОХО, потому что композиция - это тоже совокупность. Как я понимаю, вы имеете в виду "поделился".

2. Опять же, если мы посмотрим на стандарты UML (см. Документацию по надстройке там), мы обнаружим, что «точная семантика совместного агрегирования зависит от области приложения и моделирующего устройства. " Таким образом, любая выбранная вами стратегия приемлема. И вы даже можете использовать разные стратегии для разных проектов.

3. Но общая агрегация полезна и МОЖЕТ использоваться с кратностями с обеих сторон, и даже пустой ромб может быть с обеих сторон.

Ассоциация в UML - это абстракция, которая может быть реализована на любом языке и любым способом, только реализация должна соответствовать диаграмме.

Такое объединение, как на диаграмме, может быть реализовано следующим образом:

У каждого экземпляра Студента есть список курсов, на которые он зарегистрирован, и каждый экземпляр курсов имеет список зарегистрированных студентов / участников.

Но это не единственный способ реализации. Могут быть массивы вместо списков, и даже кто-то может сделать это без какой-либо нормальной коллекции вообще - просто используя адреса в памяти в C ++.

Конечно, мы могли бы составить две ассоциации: одну для списка курсов студентов, а вторую для списка студентов. Но при этом:

• наша диаграмма становится более сложной и, следовательно, менее читаемой.
• мы подробно описываем элементарные вещи, которые любой кодер будет делать в любом случае в 99% случаев.
• мы ограничиваем свободу кодеров. И в 1% случаев им придется выбирать между не следствием диаграммы и неэффективным кодированием. Это просто не твоя работа.

Итак, делай, как хочешь. Запрещено изменять стратегию только в течение одного проекта и запрещать другим использовать единственную стратегию.