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

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

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

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

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

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

Другой пример: Говорят, что это Ассоциация:

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

public class Professor {
  // ...
}

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

}

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

Ответы

Ответ 1

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

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

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

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

class Committee { ClubMember chair; String name;}

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

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

Ответ 2

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

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

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

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

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

TL;DR;

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

Ответ 3

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

Основной вывод состоит в том, что

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

Навигационная способность - совершенно другое свойство и не зависит от AggregationKind.

Ответ 4

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

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

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

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