UML - ассоциация или агрегация (простые фрагменты кода)

Question

Я сводил меня с ума, сколько книг противоречит самим себе.

Class A {} class B {void UseA(A a)} //some say this is an association,
no reference is held but communication is possible
Class A {} class B {A a;} //some say this is
    aggregration, a reference is held

Но многие говорят, что удержание ссылки - все еще просто ассоциация, и для агрегирования они используют список - ИМХО, это то же самое, если это все еще ссылка.

Я очень смущен, я хотел бы понять проблему.

Например, здесь: http://aviadezra.blogspot.cz/2009/05/uml-association-aggregation-composition.html - в чем разница между сильной ассоциацией и агрегацией, в обоих случаях автор использует поле для хранения ссылки.,

Другой пример: это называется Ассоциация:

И это называется Агрегация:

public class Professor {
  // ...
}

public class Department {
  private List<Professor> professorList;
  // ..

}

Опять какая разница? Это ссылка в обоих случаях

Answer 1

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

Связь между двумя классами устанавливается не с помощью параметра метода, а скорее через ссылочные свойства (атрибуты класса), диапазон / тип которых являются связанными классами. Если тип параметра метода является классом, это не устанавливает связь, а устанавливает зависимость.

Прежде чем смотреть на то, как они кодируются, необходимо сначала понять логическую концепцию ассоциаций. Ассоциация между типами объектов классифицирует отношения между объектами этих типов. Например, ассоциация Committee-has-ClubMember-as-стул, который визуализируется как линия соединения на диаграмме классов, показанной ниже, может классифицировать отношения FinanceCommittee-has-PeterMiller-as-chair, RecruitmentCommittee-has-SusanSmith-as-chair и AdvisoryCommittee-has-SarahAnderson-as кресло, в котором находятся объекты PeterMiller, SusanSmith и SarahAnderson ClubMemberи объекты FinanceCommittee, RecruitmentCommittee и AdvisoryCommittee имеют тип Committee,

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

class Committee { ClubMember chair; String name;}

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

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

Answer 2

Смотрите надстройки 2.1.1:

Ассоциация может представлять составную агрегацию (т. Е. Отношение "целое / часть"). Только двоичные ассоциации могут быть агрегатами. Составное агрегирование - это сильная форма агрегации, которая требует, чтобы экземпляр детали включался не более чем в один композит за один раз. Если составная часть удаляется, все ее части обычно удаляются вместе с ней. Обратите внимание, что часть может (где это разрешено) быть удалена из композита до удаления композита и, следовательно, не может быть удалена как часть композита. Композиции могут быть связаны в ориентированном ациклическом графе с характеристиками транзитивной делеции; то есть удаление элемента в одной части графика также приведет к удалению всех элементов подграфа ниже этого элемента. Композиция представлена ​​атрибутом isComposite в конце части ассоциации, для которого установлено значение true.

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

Ваши приведенные выше примеры находятся на разных уровнях абстракции. Department/Course конкретные классы кодирования в то время как Department/Professor находятся на каком-то абстрактном бизнес-уровне. Хотя нет хорошего источника (я знаю), объясняющего этот факт, composition а также aggregation это концепции, которые вы будете использовать только на бизнес-уровне и почти никогда на уровне кодирования (исключение ниже). Когда вы находитесь на уровне кода, вы живете намного лучше с Association имея имена ролей с обеих сторон. Сами роли представляют собой различную (/ избыточную!) Визуализацию свойств класса, которые ссылаются на противоположный класс.

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

ТЛ; др;

Если есть связь между классами, покажите это как простую ассоциацию. Добавление деталей, таких как роли, поможет при обсуждении деталей домена. Использование композиции / агрегации рекомендуется только при моделировании на уровне бизнеса и не рекомендуется на уровне кода.

Answer 3

Я написал статью о различиях между ассоциацией UML и агрегацией против композиции на основе фактической спецификации UML, а не интерпретаций авторов книг.

Основной вывод заключается в том, что

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

Навигация является совершенно другим свойством и не зависит от AggregationKind.

Answer 4

Во-первых, UML - это богатый язык, означающий, что есть несколько способов описать одно и то же. Это одна из причин, почему вы находите разные способы, описанные в разных книгах (и противоречивые ответы по SO).

Но ключевой вопрос заключается в огромном разрыве между UML и исходным кодом. То, как конкретная конструкция исходного кода представлена ​​в UML, и наоборот, вообще не является частью спецификации UML. Насколько мне известно, только один язык (Java) имеет официальный профиль UML, и это устарело.

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

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