Почему говорится, что «Сотрудничество» реализует «Случай использования», а не наоборот?

Question

Я изучаю UML. У меня есть путаница в реализации и сотрудничестве.

Рассмотрим диаграмму (я надеюсь, что схема верна)

«Посылка вызова» является сотрудничество. «Подключение к месту назначения» является прецедентом.

Согласно книге и различным ресурсам, я читал, что мы говорим, что «Сделать звонок» реализует «Подключиться к месту назначения».

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

Нельзя сказать, что «Случаи использования» реализуют «сотрудничество»?

Что я здесь не так?

Источник путаницы - это java, где у нас есть интерфейсы и классы, которые их реализуют. мы говорим, что класс реализует интерфейс. Разве реализация не такая же, как реализация?

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

Answer 1

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

Относительно вашей диаграммы: у вас есть зависимости от Connect to destination до двух других прецедентов. Это неправильно. Примеры использования представляют собой индивидуальную добавленную стоимость, которую SUC приносит своим актерам. Поэтому они в принципе не могут зависеть друг от друга. Все варианты использования SUC представляют собой общую добавленную стоимость. Часто люди пробуют функциональную декомпозицию в случае использования и добавляют много зависимостей include/extend. Это не приводит к значимым вариантам использования, и вы теряете фокус. То есть вы не показываете добавленные значения, но отклоняетесь от технических возможностей.