Обозначение UML - агрегирование/композиции vs "Vanilla" Ассоциации
==================================================================

Недавно я потратил много времени на выполнение подробных UML-проектов различных компонентов SW, которые я написал с тех пор. Оглядываясь на то, что я недавно закончил, и сравнивая это с тем, когда я впервые узнал UML, я вижу, что теперь я почти полностью использую отношения агрегирования и компоновки и фактически отказался от "vanilla" не направленных/направленных отношений. Я все же, конечно, использую обобщения и реализации, но они явно отличаются от приведенных выше и не считаются частью этого вопроса.

Мне кажется, что Aggregation/Composition подразумевает то же значение ассоциаций "vanilla" и многое другое. Агрегация и композиция, естественно, подразумевают направление, и любая современная программа UML по-прежнему позволит вам определить множественность по отношению к агрегированию/составу и применить также глагол к этой взаимосвязи. В этот момент я вижу небольшую цель для ассоциаций ванили.

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

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

 

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

 .i1a { width: 336px; height: 280px; }
 @media(min-width: 768px) { .i1a { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .i1a { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .i1a { width: 728px; height: 90px; } }

 (adsbygoogle = window.adsbygoogle || []).push({});

 [Мета-модель UML](http://www.omg.org/spec/) определяет агрегирование и состав как расширения ассоциации. Ассоциацию можно рассматривать как нерафинированное отношение между объектами домена, так же, как объект Domain является неочищенным классом. Обычно я использую простые ассоциации на этапе моделирования домена и при необходимости уточняю его в составе или агрегации, когда я разрешаю подробную модель класса.

 

Фактически, большинство случаев ассоциаций в моделях классов UML не являются ни агрегатами, ни композициями. Например, связь между классами `Publisher` и `Book` для присвоения книг, изданных издателем для этого издателя, не является ни агрегацией, ни композицией, потому что книги, изданные издателем, не являются частями или компонентами этого издателя.

 ![A model of the association between Publisher and Book](/img/a69d0761230483918fae0b3613bf1013.png)

Агрегация - это особая форма ассоциации с предполагаемым значением частично-целостной связи, но без точной семантики (спецификация UML гласит: "Точная семантика общей агрегации зависит от области приложения и модельера" ). Например, мы можем моделировать агрегацию между классами `Car` и `Engine` и между классами `Course` и `Lecture`, так как движок является частью автомобиля, а лекция является частью курса.

 .i2a { width: 336px; height: 280px; }
 @media(min-width: 768px) { .i2a { width: 728px; height: 90px; } }
 @media(min-width: 992px) { .i2a { width: 360px; height: 300px; } }
 @media(min-width: 1083px) { .i2a { width: 728px; height: 90px; } }

 (adsbygoogle = window.adsbygoogle || []).push({});

Композиция (также называемая "составная агрегация" в спецификации UML) представляет собой особую форму агрегации, где экземпляр компонента является частью не более одного совокупного экземпляра за раз (то есть он не может быть разделен между несколькими агрегатами). Это означает, что агрегирование между `Car` и `Engine` является композицией (поскольку двигатель не может совместно использоваться между двумя автомобилями одновременно), тогда как агрегация между `Course` и `Lecture` не обязательно является композицией, поскольку лекция может быть разделена между двумя курсами (например, курс управления базой данных и курс по разработке программного обеспечения могут поделиться лекцией по UML). Это означает, что кратность ассоциации композиций заканчивается со сборочной стороны или равна 1 или 0..1, а также может быть * в случае некомпозитной агрегации.

В дополнение к этим основным характеристикам композиции (чтобы иметь эксклюзивные части), композиция может также иметь зависимость жизненного цикла между агрегатом и его компонентами, подразумевая, что при удалении агрегата все его части удаляются с этим. Однако это относится только к некоторым случаям композиции, а не к другим, и поэтому не является определяющей характеристикой. Спецификация UML гласит: "Часть может быть удалена из составного экземпляра перед удалением составного экземпляра и, следовательно, не будет удалена как часть составного экземпляра". В нашем примере состава Car Engine ясно, что двигатель может быть удален из автомобиля до того, как автомобиль будет уничтожен, и в этом случае двигатель не будет разрушен и может быть повторно использован.

 

На диаграмме классов вы думаете о статических отношениях между классами. Вероятно, вам действительно не нужно думать о поведенческих аспектах этих отношений на диаграмме классов, он просто мутит воды и свидетельствует о чрезмерном анализе. (ИМХО, конечно)

 

Ванильные ассоциации, агрегирование и композиции иногда объясняются следующей семантикой:

* ассоциация ванили: один объект "знает" один или несколько других объектов.
* агрегация: у одного объекта есть "один или несколько других объектов"
* состав: один объект 'состоит из одного или нескольких других объектов - подобъект не может быть без компоновщика контейнера

В основном различение агрегации и состава обходит вопрос "если главный объект ушел - что происходит с объектами детали?".

Итак, идея состоит в том, чтобы описать ограничение целостности, например, "on delete cascade", с использованием дифференциации при использовании одного из трех вариантов. UML имеет три разных символа для этого

* no symbol - ассоциация ванили
* алмаз - агрегация
* заполненный алмаз - состав

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

например. Попытка ответить на простой вопрос  **"Сколько шинных колес имеет моя машина?"** 
Приведёт к различным ответам:

* 4 колеса, которые перманентно прикреплены к моей машине.
* 1 запасное колесо, которое я мог бы использовать в чрезвычайной ситуации
* 4 колеса, которые являются либо моим летом, либо зимними колесами и не привязаны к машине в другие сезоны.

Сколько из этих колес исчезнет, когда автомобиль исчезнет?
Если вы попытаетесь смоделировать эту ситуацию с помощью трех символов, которые предлагает UML, вы получите много обсуждений и переговоров о том, что означает ваша модель. Я думаю, что гораздо лучше никогда не использовать символы aggegation и состава, но вместо этого всегда описывать семантику ассоциации как
насколько это возможно, несколькими строками текста. Таким образом, вы можете ясно дать понять людям, читающим вашу модель, что вы действительно хотите.
Я думаю, что это даже o.k. написать "Автомобиль - это состав частей, который включает в себя колеса..." 

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

см. также
<http://de.wikipedia.org/wiki/Assoziation_%28UML%29#Aggregation_und_Komposition> (немецкий)

 

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