Объединение UML и ассоциация

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

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

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

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

Ответ 1

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

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

НТН.

Ответ 2

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

Ура!

Ответ 7

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

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

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

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

Ответ 8

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

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

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

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

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