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

вот я, с другим вопросом об агрегации и ассоциации. Я хотел изучить некоторые основы UML, поэтому я начал читать "UML distilled" Мартина Фаулера. Я прочитал обе главы о классах, и есть одна вещь, которую я не могу полностью понять, я думаю, и это агрегация против ассоциации. В книге есть такая цитата:

в дни до UML люди обычно были довольно расплывчатыми о том, что такое агрегация и что такое ассоциация. Неясно или нет, они всегда были несовместимы со всеми остальными. В результате, многие моделисты считают, что агрегация важна, хотя и по разным причинам. Так УЯМ включенная агрегация (рис. 5.3), но почти без семантики. Как говорит Джим Рамбо: "подумайте об этом в качестве модельного плацебо"[Rumbaugh, UML Reference].

Как я понимаю из этой цитаты и тем, которые я читал при переполнении стека, не имеет значения, какое из этих двух отношений я использую, они означают bassicly то же самое, или есть какая-либо ситуация, когда использование агрегации вместо ассоциации было бы оправдано и/или я не мог бы изменить один на другой без изменения "значения" диаграммы классов?

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

47
aggregation associations uml

8 ответов

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

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

hth.

26

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

разница заключается в импликации. Агрегация обозначает целое / часть отношения, тогда как ассоциации-нет. Однако, нет вероятно, будет большая разница в том, как эти два отношения выполненный. То есть, было бы очень сложно посмотреть на код и определить, должны ли определенные отношения быть агрегация или ассоциация. Для эта причина, довольно безопасна к полностью игнорируйте отношение агрегации.
[Robert C. Martin / UML]

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

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

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

29

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

3

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

Е. Г. автомобиль имеет четыре колеса. Возможно, вы захотите рассчитать общее количество метров, которые каждое колесо проехало для каждого автомобиля. Этот расчет выполняется Car-entity, так как он знает, какие колеса у него есть, и вам все равно, какие колеса принадлежат автомобиль.

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

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

0

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

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

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

0

этот термин часто путается.

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

вы можете получить идею из этой аналогии.

класс:A(человек) и класс:B(автомобиль) и ассоциация отношении, если Класс: A есть Класс:B декларации, а также класс:B(автомобиль)

0

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

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

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

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

0

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

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

агрегация отношения: класс содержит другой класс. Но если контейнер(класс) разрушен, то содержащийся (стул) - нет. На самом деле стул принадлежит классу. Агрегация более сильна отношения, чем отношения Ассоциации.

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

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

-1