UML-зависимость между интерфейсами в предоставленной / обязательной нотации - PullRequest
0 голосов
/ 13 января 2019

Что точно означает стрелку зависимости между предоставленным и требуемым интерфейсом и что означает направление? enter image description here

В моем понимании, предоставленный "леденец на палочке" является отношением реализации к интерфейсу, а требуемый "сокет" является зависимостью использования от интерфейса.

Как имеет смысл для интерфейса иметь зависимость от другого интерфейса или даже от самого себя? Ниже я прочитал схему слева.

enter image description here

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

enter image description here

Поиск в Google показывает много возможных мнений, и мы будем благодарны за обоснованный ответ (возможно, со ссылкой на соответствующую метамодель UML).

1 Ответ

0 голосов
/ 14 января 2019

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

В вашем случае, такое отношение, которое вы демонстрируете, указывая от требуемого интерфейса к предоставленному интерфейсу (в обозначениях сокетов и шаров), представляет собой так называемую зависимость проводки . Использование зависимости в направлении опоосайта не имеет смысла. Эти зависимости от проводки не предназначены для выражения того, что интерфейс имеет самостоятельную зависимость, конечно, но это обычно неверная интерпретация из-за неудачной записи. Первоначально целью связывания зависимостей между требованием к интерфейсу и провоцированием интерфейса было добавить небольшую разницу между отношениями использования и зависимости, то есть пользователь также зависит от других аспектов спецификации, а не только от предоставленного контракта, например, от спецификаций ресурса или временных ограничений. , Сегодня это понимание полностью ухудшено, и оно просто используется для улучшения читаемости диаграмм, показывая то, что принадлежит друг другу.

Чтобы устранить ваше недопонимание (что является довольно распространенным явлением), зависимость не от интерфейса к себе, а от интерфейса, требующего к предоставлению интерфейса. Предполагается, что обеспечение и требование интерфейса также является элементом модели.

Зависимости проводки используются только между статическими элементами модели, например, классами, компонентами или портами классов (не частями / объектами). Если вы хотите выразить, что зависимость объекта / части разрешается конкретным другим объектом / частью, тогда вы моделируете эти два экземпляра и используете соединитель (или что-то производное от него) между экземплярами или портами, показанными на экземплярах. , Мысль, когда статический элемент имеет порты, порты должны быть связаны. Соединители могут использоваться только между экземплярами, а не между их классификаторами.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...