Агрегация UML против ассоциации

Заявление Рамбо - самый красноречивый и хороший совет дяди Боба. Как я уже сказал в другом месте, агрегирование семантически настолько слаб, что не предлагает ничего практически полезного. У него есть только один допустимый угловой случай (ацикличность рекурсивных отношений), однако немногие люди знают и понимают это. Так что в любом случае вам придется указывать на это в комментариях.

Я просто им не пользуюсь. И никогда не чувствовал потерь. Придерживайтесь простых бинарных ассоциаций и сосредоточьтесь на том, что действительно важно - на определении мощности и правильного наименования. Вы получите гораздо больше, чем пытаясь решить неразрешимую ассоциацию или агрегирование.

hth.

Возможно, это поможет вам, но я не думаю, что вы найдете идеальное объяснение:

Разница лишь косвенная. Агрегация означает отношения целое / часть, тогда как ассоциации - нет. Однако вряд ли будет большая разница в способах реализации этих двух отношений. То есть было бы очень сложно взглянуть на код и определить, должно ли конкретное отношение быть агрегированием или ассоциацией. По этой причине вполне безопасно вообще игнорировать отношение агрегирования.
[Роберт С. Мартин | UML]

И пример для каждой ситуации:

а) Ассоциация - это отношения, при которых у всех объектов свой жизненный цикл и нет владельца. Возьмем пример Учителя и Студента. Несколько учеников могут связываться с одним учителем, а один ученик может связываться с несколькими учителями, но между объектами нет права собственности, и оба имеют свой собственный жизненный цикл. Оба могут создавать и удалять независимо друг от друга.

б) Агрегация - это специализированная форма ассоциации, в которой все объекты имеют свой собственный жизненный цикл, но есть право собственности, а дочерний объект не может принадлежать другому родительскому объекту. Возьмем для примера кафедру и учителя. Один учитель не может принадлежать к нескольким отделам, но если мы удалим отдел, объект учитель не будет уничтожен. Мы можем думать об отношениях «есть».
[Maesh | GeeksWithBlogs]

Я склонен использовать агрегирование, чтобы показать отношение, аналогичное компоновке, с одним большим отличием: содержащий класс НЕ отвечает за жизненный цикл содержащегося объекта. Обычно (ненулевой) указатель или ссылка на объект, который должен содержаться, передается конструктору содержащего класса. Содержащий объект на протяжении своего жизненного цикла зависит от существующего содержащегося объекта. Содержащий объект не может выполнять свою работу (полностью) без содержащегося объекта. Это моя интерпретация отношения «часть / целое», подразумеваемого агрегированием.

Этот термин часто путают.

Агрегация и композиция - это некоторые из типов ассоциации. Между агрегацией и ассоциациями во время реализации практически нет разницы, и многие вообще пропускают отношения агрегации в своих диаграммах с отношением ассоциации.

Вы можете получить представление об этой аналогии.

Класс: A (человек) и Класс: B (автомобиль) имеет отношение ассоциации, если Class: A имеет объявление Class: B, а также объект Class: B (car) не важны для создания Class: A (person ) объект.

Класс: A (автомобиль) и Класс: B (шина) имеет отношение агрегирования, если Класс: A имеет объявление Class: B, а также объект Class: B (шина) необходимы для создания Class: A (автомобиль) объект.

Ваше здоровье!

В UML агрегация недооценена и поскольку у них нет четко определенной семантики. Правильный вариант использования агрегации - это инкапсуляция нескольких классов, как указано в "Domain Driven Design" Эрика Эванса.

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

Автомобиль является корнем агрегирования для всех его частей, таких как колеса, и вы не можете получить доступ к частям автомобиля извне агрегирования, только к корню.

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

Они не означают одно и то же! Я могу сказать это так:

Связь связи: класс ссылается на другой класс. На самом деле это показывает, что класс связан с другим классом, но у них не обязательно есть атрибуты, чтобы показать эту взаимосвязь ... например, классы «Учитель» и «Ученик», хотя класс «Учитель» не имеет атрибута, относящегося к ученикам, но мы знаем, что на самом деле у учителя действительно есть ученики ... А также у класса «Школа» есть свойства «учителя» и «ученики», которые теперь связывают эти два класса друг с другом.

Отношения агрегирования: класс содержит другой класс. Но если контейнер (ClassRoom) уничтожен, содержащийся (Chair) - нет. Фактически Классная Комната владеет Стулом. Агрегация - более сильные отношения, чем отношения ассоциации.

Вот также учебное пособие по этому поводу и весь UML2.0, в котором все объясняется просто и просто, вы можете найти его полезным: https://github.com/imalitavakoli/learn-uml2

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

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

• найти подкомпоненты в иерархии
• добавлять / удалять подкомпоненты в / из иерархии
• изменить общие атрибуты всех компонентов
• рекурсивно перемещаться по иерархии (шаблон посетителя)
• перенастроить иерархию и связи (ассоциации) между компонентами

При работе с ассоциациями большинство этих операций не требуется.

Чтобы добавить, я бы просто предложил загрузить спецификацию UML с сайта OMG: лучшая ссылка и см. Стр. 110.

none Указывает, что свойство не имеет семантики агрегирования.

shared Указывает, что свойство имеет общую семантику агрегирования. Точная семантика совместной агрегации зависит от области приложения и разработчика.

составной Указывает, что Свойство агрегировано составно, т. е. составной объект несет ответственность за существование и хранение составных объектов (см. определение частей в 11.2.3).