Нотация UML - Агрегации / Композиции против Ассоциаций "Ваниль"

Question

Недавно я потратил много времени на выполнение подробных UML-проектов различных компонентов ПО, которые я написал с тех пор. Оглядываясь назад на то, что я недавно закончил, и сравнивая это с тем, когда я впервые изучил UML, я вижу, что теперь я почти строго использую отношения Агрегации и Композиции и практически отказался от «ванильных» ненаправленных / направленных отношений. Я, конечно, все еще использую Обобщения и Реализации, но они явно отличаются от описанных выше и не считаются частью этого вопроса.

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

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

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

Answer 1

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

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

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

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

Answer 2

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

• ванильное объединение: один объект «знает» один или несколько других объектов
• агрегация: один объект «имеет» один или несколько других объектов
• состав: один объект «состоит из» одного или нескольких других объектов - подобъект не может быть без контейнера-составителя

В основном различие в агрегации и составлении сводится к вопросу «если мастер-объект исчез - что происходит с объектами детали?».

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

• без символа - ванильное объединение
• алмаз - агрегация
• бриллиант с наполнителем - состав

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

например. Пытаясь ответить на простой вопрос «Сколько колесных шин у моей машины?» Приведет к разным ответам:

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

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

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

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

Answer 3

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

Answer 4

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

Мета-модель UML определяет Агрегацию и Композицию как расширения Ассоциации. Ассоциация может рассматриваться как неопределенная связь между объектами домена, так же, как объект Домена является неопределенным классом. Обычно я использую простые ассоциации на этапе моделирования домена и уточняю их либо в виде композиции, либо в зависимости от обстоятельств, когда решаю подробную модель класса.

Answer 5

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