Агрегация и судоходство на одном конце


В UML можно ли построить агрегацию, в которой компонентный объект может получить доступ к составному объекту? Как на этом изображении, но только с одной ассоциативной линией, так что конец ассоциации, соприкасающийся с А, будет иметь алмаз и стрелу. Если это невозможно, то схема, которую я нарисовал, действительна? Если нет, то почему?

2 2

2 ответа:

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

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

Спецификация описывает (стр. 198): Навигируемость означает, что экземпляры, участвующие в ссылках во время выполнения (экземпляры ассоциации), могут быть эффективно доступны из экземпляров на других концах Ассоциации. Точный механизм путем каким образом достигается такой эффективный доступ, зависит от конкретной реализации. Если один конец не является судоходным, доступ с других концов может быть или не быть возможным, а если это так, то он может быть неэффективным.

И о классе свойств (p 149): запрос isNavigable () указывает, можно ли перемещаться по свойству. тело: не классификатор- > isEmpty () или ассоциация.navigableOwnedEnd - > включает (self).

Так что моделировать или нет навигацию важно.

Если вы хотите иметь судоходство в обе стороны, следующее изображение показывает, что:

Введите описание изображения здесь

Но в разделе 6 спецификации написано:

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

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

Таким образом, следующая схема совпадает с приведенной выше. Это сложно, но кажется правдой.

Введите описание изображения здесь

Конечно, это возможно.

Если вы хотите сэкономить место, вы можете использовать одну строку для ассоциации:

Введите описание изображения здесь

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

П. 110 спецификации:

Если свойство принадлежит классификатору, отличному от Ассоциации через ownedAttribute, то оно представляет атрибут классификатора.

P. 200:

Обозначения судоходства часто использовались в прошлом в соответствии с неофициальной конвенцией, согласно которой несудоходные концы считались принадлежащими ассоциации, тогда как судоходные концы считались принадлежащими классификатору на противоположном конце. Эта конвенция теперь устарела. Тип агрегации, навигационная способность и конечное владение-это отдельные понятия, каждое из которых имеет свою собственную явную нотацию. Цели ассоциации, принадлежащие классам, всегда судоходны, в то время как те, что принадлежат ассоциациям, могут быть судоходными или нет.

Но что такое ассоциация, которая только что названа? Пока что это бесполезная конструкция. То, что вы намереваетесь в конечном итоге создать атрибуты в любом классе - с помощью свойств, в этом случае вы добавляете эту (новую) точку. Для меня это просто переосмысление и непрактичность. Кто на самом деле использует эти точки? В ЕА у вас есть, чтобы открыть суб-меню, чтобы сделать их появляются. Для меня (и, вероятно, для большинства читателей UML) имя роли представляет собой свойство и этот атрибут в другой стороне. Это просто "моя человеческая логика", стоящая за этим предложением. Итак, мой практический подход:
  • используйте простые соединители для объединения
  • в конечном итоге добавить (не) судоходность (кресты и) стрелки
  • позже добавьте имена ролей, чтобы указать использование атрибутов на другом конце (вместо добавления типизированного атрибута в список класса).

И это все. Просто забудьте эту глупую точку, которую А) трудно произвести (в EA) и б) еще труднее распознать.

Еще раз: эта последняя часть-моя рекомендация для практического моделирования.