UML - отношение ассоциации или агрегации?

Когда класс содержит в качестве атрибута тип другого класса, какая это связь — ассоциация или агрегация?

e.g.

класс Flight, содержащий тип класса City в качестве атрибута Destination — это ассоциация или агрегация? Как будут называться их отношения в любом случае? Рейс-"прилет"-Город?

Другой сценарий:

Класс FlightBooking, содержащий тип класса BusinessClass в качестве атрибута, чтобы показать, что это бронирование рейса бизнес-класса — это ассоциация или агрегация?

Спасибо!


person Roger2233    schedule 22.05.2011    source источник
comment
@marcin, может быть, ОП пытается учиться, чтобы у него был словарный запас, который он мог бы использовать для обмена общими идеями с другими. Зачем еще учить правильные слова для вещей?   -  person Sam Holder    schedule 23.05.2011
comment
@Sam Holder: Для меня это звучит как домашняя работа. Я также нахожу странным, что кто-то заботится об имени, когда семантика ясна. Наконец, я думаю, что UML препятствует хорошему дизайну.   -  person Marcin    schedule 23.05.2011
comment
@Marcin: UML препятствует хорошему дизайну? Может быть, вы могли бы уточнить?   -  person sfinnie    schedule 23.05.2011
comment
@sfinnie: UML поощряет сосредоточение внимания на модели данных (хорошо во многих отношениях), но почти полностью скрывает роль методов. Вы можете представлять интерфейсы в стиле Java, но это мало что вам скажет. Представление ограничений и предположений о методах также громоздко.   -  person Marcin    schedule 23.05.2011
comment
@Marcin: спасибо за ответ. В равной степени можно утверждать, что основные языки программирования «препятствуют хорошему дизайну» из-за отсутствия хорошей поддержки отношений. Суть в том, что UML, как и все другие инструменты в нашем арсенале, не всегда хорош или плох. У него есть сильные и слабые стороны. Общие заявления на самом деле не помогают, особенно в контексте вопроса новичка. Ваш последующий ответ проясняет вашу точку зрения, поэтому делает ее более полезной.   -  person sfinnie    schedule 23.05.2011
comment
@sfinnie: В каком смысле в языках программирования отсутствует поддержка отношений?   -  person Marcin    schedule 23.05.2011
comment
@Marcin: отношения не являются конструкциями первого класса в прог-языках. Вместо этого нужно разложить отношения на классы указателей/коллекций. Таким образом, понимание отношений представляет собой упражнение по «обратному инжинирингу» свойств отношений из кода (множественность, необязательность, ответственность за создание/удаление, бизнес-правила/ограничения, которые представляет rel).   -  person sfinnie    schedule 23.05.2011
comment
@sfinnie: я не знаю, что ты имеешь в виду под деконструкцией. То, что они не называются отношениями, не означает, что они не являются овеществленными репрезентациями отношений. Если вам нужны первоклассные объекты, вы можете просто создать их — нет необходимости в том, чтобы ваш язык обеспечивал специальную поддержку. Причина, по которой люди этого не делают, заключается в том, что они не считают это ценным, поскольку реализация модели данных в коде не является проблемой. Проектирование и моделирование динамический аспект.   -  person Marcin    schedule 23.05.2011
comment
@Marcin: «деконструировать» = взять отношения и разделить их на две части, по одной в каждом участвующем классе. И отношения — это не просто статичные вещи, они также отражают динамику. Не так просто, как просто создавать объекты. Это все равно, что сказать, что вы можете создавать полиморфные типы в C: да, это возможно, но требует значительных накладных расходов без языковой поддержки.   -  person sfinnie    schedule 23.05.2011
comment
@sfinnie: я не понимаю, как это препятствует хорошему дизайну - в конце концов, код, который фиксирует эти отношения, написать не так уж сложно, и поддержка теперь с помощью инструментов разработки через тестирование довольно приличная.   -  person Marcin    schedule 23.05.2011
comment
@Marcin: при всем уважении, вы уходите от сути. Вы сделали общее заявление о том, что UML препятствует хорошему дизайну. Когда вас спросили, вы пояснили, что поскольку UML плохо поддерживает методы (с неявным сравнением с языками программирования). Моя точка зрения заключалась в том, что UML — это такой же инструмент, как и любой другой, который можно использовать так и там, где мы считаем нужным. Я использовал поддержку UML для отношений как относительную силу - позиция, с которой вы, похоже, согласились в своем комментарии. UML поощряет сосредоточение внимания на модели данных (хорошо во многих отношениях). Но дело не в отношениях или методах. Это ли...   -  person sfinnie    schedule 23.05.2011
comment
(продолжение) ... общие утверждения, такие как язык X или инструмент Y, препятствуют хорошему дизайну, полезны. Особенно в контексте вопроса новичка. Я бы сказал, что нет. Ваше объяснение этого утверждения гораздо ценнее. Мы могли бы продолжить дискуссию об относительных достоинствах поддержки отношений, но мы, вероятно, слишком далеко отклонились от темы для этого вопроса. Предложите нам уйти оттуда (и надеюсь, что диалог будет полезен для ОП!).   -  person sfinnie    schedule 23.05.2011
comment
возможный дубликат ассоциации UML и уровня композиции и детализации   -  person Rick Smith    schedule 24.08.2015


Ответы (2)


Класс Flight, содержащий тип класса City в качестве атрибута Destination — это ассоциация или агрегация?

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

person Doc Brown    schedule 22.05.2011

Подумайте о терминологии — ассоциации звучат гораздо шире. Имеет смысл сказать, что для «класса Flight, содержащего тип класса City в качестве атрибута с именем Destination» — это ассоциация.

person Caffeinated    schedule 22.05.2011