Когда использовать memberEnd и когда navigableOwnedEnd в диаграмме классов UML?

Question

Я скачал пробную версию Altova UModel и начинаю использовать UML. В качестве практического начала я моделирую приложение для управления персональной информацией, которое включает в себя управление веб-закладками.

Закладка может принадлежать сразу нескольким (или не иметь) тегам, а тег может содержать много (или нет), если все содержащиеся в нем закладки были удалены). Отношение должно быть двусторонним для навигации - пользователь должен иметь возможность видеть все закладки с определенными тегами и все теги закладки.

Каково правильное отношение UML между классами Bookmark и Tag?

Насколько я понимаю UML сейчас, это Ассоциация (а не Агрегация). Но для двусторонней судоходной связи "многие ко многим" я могу указать конечные роли как "memberEnd" или "when navigableOwnedEnd", графически соединение выглядит одинаково в обоих случаях (стрелка) (что, как я понимаю, означает навигацию), но свойство появляется в поле класса только в том случае, если используется "memberEnd".

Как мне указать это в модели? Если я имею в виду двустороннее судоходное отношение "многие ко многим"?

Answer 1

Из спецификации надстройки UML, v2.1.2, раздел 7.3.3:

• memberEnd: Недвижимость [2..*] Каждый конец представляет участие экземпляров классификатора, связанного с концом, в ссылках ассоциации. Это упорядоченная ассоциация. Подмножества Namespace::member.
• Owner: конец [*] Концы, которые принадлежат самой ассоциации. Это заказная ассоциация. Ассоциация подмножеств::memberEnd, Classifier::feature и Namespace:: OwnerMember.
• navigableOwnedEnd: Свойство [*] Судоходные концы, которые принадлежат самой ассоциации. Ассоциация Подмножеств:: OwneEnd.

Таким образом, если конец "принадлежит" ассоциации, используйте тип ownEnd / navigableOwnedEnd, в противном случае используйте тип memberEnd.

Любой из них может использоваться для "двустороннего судоходного отношения" многие ко многим "; если каждая ссылка отношения является отдельным экземпляром в вашем дизайне, она может владеть целями (например, класс A и класс B имеют ссылку на список пар ссылок на связанные As и Bs), но если ссылка отношения неявная, то она не имеет ничего (например, класс A имеет список ссылок на связанные B, класс B имеет список ссылок на связанные As).

Пользуясь UML с конца 90-х годов, вы первый, кого я встретил, и который позаботился о разнице!