В диаграмме классов UML композиция может быть двунаправленной?
Может ли композиция быть двунаправленной так, чтобы оба класса знали друг о друге?
И если нет, то какое направление композиции по умолчанию?
4 ответа
Да, Композиция не добавляет ограничений в отношении навигации по ассоциации. Более подробную информацию о разнице между объединением, составом и объединением можно найти здесь: Состав UML против объединения или объединения
Вы должны различать навигацию и агрегацию. Стрелка и бриллиант.
Стрелка A->B означает только то, что B достижим из A некоторым простым способом. Если A содержит композицию B, это означает, что
составной объект несет ответственность за существование и хранение составных объектов (частей).
(цитата из OMG Unified Modeling Language TM (OMG UML) - стр.109)
Итак, может ли собрание иметь двунаправленную навигацию?
Да. Это вполне нормально.
Если, например, вы решили уничтожить B в некоторых из его функций, вы ДОЛЖНЫ добраться до A и уничтожить его оттуда. Таким образом, композиция имеет двунаправленную навигацию достаточно часто. Обратите внимание, что двунаправленная навигация, согласно текущим и будущим стандартам UML, показана в виде линии без стрелок с обеих сторон. Двусторонняя стрелка устарела. Вот почему вы не будете часто это видеть.
Может ли сама композиция быть двунаправленной? Можем ли мы увидеть черные бриллианты по обе стороны ассоциации?
Нет, конечно, такого рода ассоциация не может быть взаимной, поскольку невозможно создать B только в A и одновременно создать только A в B.
Что интересно, shared aggregation (пустой бриллиант) тоже не может быть взаимным, но здесь ограничение не присуще, оно просто запрещено стандартом UML.
С https://www.lucidchart.com/pages/uml/class-diagram:
Двунаправленные ассоциации являются ассоциациями по умолчанию между двумя классами и представлены прямой линией между двумя классами. Оба класса осведомлены друг о друге и об их отношениях друг с другом. В приведенном выше примере класс Car и класс RoadTrip взаимосвязаны. На одном конце линии автомобиль принимает ассоциацию с "назначенным автомобилем" со значением кратности 0..1, что означает, что когда существует экземпляр RoadTrip, он может иметь либо один связанный с ним экземпляр автомобиля, либо не связанные автомобили. с этим. В этом случае отдельный класс Caravan со значением кратности 0..* необходим для демонстрации того, что RoadTrip может иметь несколько экземпляров автомобилей, связанных с ним. Так как один экземпляр Car может иметь несколько ассоциаций "getRoadTrip" - другими словами, один автомобиль может совершать несколько поездок - значение множественности равно 0..*
Раньше я придерживался того же мнения, что и Гангнус, с
Итак, может ли собрание иметь двунаправленную навигацию?
Но после недавнего обсуждения я более подробно рассмотрел спецификации UML. И просто это утверждение не соответствует действительности (только частично). Давайте посмотрим на спецификации UML 2.5. На стр. 110 заявлено
Иногда Свойство используется для моделирования обстоятельств, в которых один экземпляр используется для группировки набора экземпляров; это называется агрегированием. Чтобы представить такие обстоятельства, свойство имеет свойство агрегирования типа AggregationKind; экземпляр, представляющий всю группу, классифицируется владельцем свойства, а экземпляры, представляющие сгруппированных лиц, классифицируются по типу свойства. AggregationKind - это перечисление со следующими буквальными значениями:
[исключая общую агрегацию] составной: Указывает, что Свойство агрегируется составно, т. е. составной объект несет ответственность за существование и хранение составных объектов (см. определение частей в 11.2.3).
Составная агрегация - это сильная форма агрегации, которая требует включения частичного объекта не более чем в один составной объект за раз. При удалении составного объекта все экземпляры его частей, являющиеся объектами , удаляются вместе с ним.
Обратите внимание на мой акцент на объекте / экземпляре в приведенном выше тексте. Итак, UML просто говорит об ответственности. Если он составляет, он будет ответственным за удаление, когда он будет уничтожен сам. Наоборот
B будет нести ответственность за
Aразрушение. Таким образом, если у вас есть ссылки в обоих направлениях (то есть ромбы с обеих сторон), вы будете обязаны удалить объект с другой стороны. Это, конечно, работает только в том случае, если только один из них ссылается на другой. Если бы у обоих была ссылка, было бы невозможно иметь прямую ответственность (потому что она циркулярная).
Я по-прежнему считаю, что использование составной агрегации с обеих сторон - не лучшая идея. Но по спецификации это возможно.