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

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

2 голосов
/ 23 мая 2010

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

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

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

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

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

1 Ответ

4 голосов
/ 23 мая 2010

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

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

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

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

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

...