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

Question

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

Answer 1

Две вещи:

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

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

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

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

НТН.

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

Answer 2

Хороший сайт для этого

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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