#uml #aggregation #relationships
#uml #агрегация #отношения
Вопрос:
У меня проблема с моей UML-диаграммой, и я буду рад, если вы мне поможете. У меня есть такие отношения, как
Объект A (1)<>—-(0..*) Объект В
Объект B (1)<>—-(0..*) Объект А
и я хотел бы объединить их. Как я могу это сделать? Большое спасибо.
Комментарии:
1. Разве это не то же самое, что ( .. ) ? Какой пример может быть, когда у объекта Singe A есть несколько объектов B, в то время как у одного объекта B есть несколько объектов A?
2. например, одна функция может быть частью одного сервера, в то время как один сервер может быть частью распределенной функции
Ответ №1:
Не могли бы вы, пожалуйста, определить термин «объединить их»? Чего именно вы хотели бы достичь? Вероятно, может помочь пример.
Между тем, я могу попытаться угадать и дать вам два возможных решения. Возможно, они помогут вам перефразировать ваш вопрос или даже найти решение:
В решении 1 я только что создал одно отношение, которое описывает оба ваших. Это можно использовать, если существует только один и четкий критерий связи между объектами. Типичное n ..m отношение. Каждый объект A будет содержать коллекцию связанных объектов B и наоборот.
- Например, человек (A на диаграмме) может присоединиться к нескольким клубам (B), а в клубе может быть несколько членов — за этой ситуацией стоит только одно логическое отношение — членство.
В решении 2 на самом деле существует 2 разных способа связи между этими элементами, каждый из которых 1 ..n. Итак, A содержит коллекцию Bs, а B содержит коллекцию As, но они не связаны.
- Расширяя тот же пример — человек (A) может присоединиться только к 1 клубу (B), а в клубе может быть много членов и содержать их ссылку (col_a на диаграмме). В то же время у клуба может быть только 1 владелец, и человек может владеть несколькими клубами (col_b). Здесь у нас есть два разных логических отношения — членство и владение.
Конечно, возможны и другие множества и возможности навигации, это всего лишь пример, который даст вам представление.
Похожа ли одна из этих ситуаций на вашу?
ОБНОВЛЕНИЕ (после 1-го комментария):
Итак, вот обновленное решение 1:
Здесь используется агрегация, и это скорее отношение между членами группы. Это идеально соответствует описанию моего первого решения там. Члены (B) могут быть «разделены» между группами (A), и Gruop не имеет никакого специального контроля над их жизненным циклом.
В реальных отношениях Целое-часть вместо агрегации использовалась бы композиция (визуально изображаемая черным ромбом вместо белого). Его семантика заключается в том, что весь объект имеет полный контроль над жизненным циклом содержащихся в нем объектов (частей). В результате Части не могут быть разделены между несколькими целыми и должны быть уничтожены, если будет уничтожено само Целое.
Теперь вам просто нужно выяснить, какая ситуация лучше всего описывает вашу проблему, подобрать одно из этих решений и, в конечном итоге, точно настроить кратности.
Комментарии:
1. Спасибо! Да, я использовал первое решение, но мне кажется, что оно не показывает отношения «часть-целое». Правильно ли это? Есть ли другое решение для этого случая?
2. Вы правы, это вообще не показывает природу отношений между частями. Для этого у нас есть композиции и агрегации. Пожалуйста, посмотрите мой обновленный ответ.
Ответ №2:
Вот способ, которым вы могли бы представить этот сценарий в UML.
Один сервер может содержать 0 или много функций (т.е. агрегированные отношения).
Каждая функция должна принадлежать одному серверу. Или, если это распределенная функция, она может принадлежать многим серверам.
