bas mcureenab
Прецедент, в частности "Редактирование клиента" не может одновременно быть расширением и включением.


А можно ссылку на источник, а то вроде об этом читал тоже, но не могу вспомнить где.

Точно не помню название. Вроде "Введение в Rational Unified Process".
Конкретно такого ограничения я не видел, но могу сделать вывод о его наличии.

Рассмотрим, например, прецедент "Приготовление чая".

1. Подогреть воду.
2. Насыпать чай в чайник.
3. Залить кипятком.

Акторов и систему я не указал.

Теперь расширим прецедент "Понтами" и получим сценарий "Приготовление чая с понтами".

1.а Заказать музыку
1. Подогреть воду.
2.а Прогреть чайник.
2. Насыпать чай в чайник.
3. Залить кипятком.
3.а Быстро слить воду
4.а Залить кипятком

Расширение "Понты" заключается в добавлении к обычному сценарию дополнительных действий:

1.а Заказать музыку
2.а Прогреть чайник.
3.а Быстро слить воду.
4.а Залить кипятком.

И акторов - DJ.

Очевидно, что повторно использовать совокупность этих действий отдельно от основного сценария невозможно. Прецедент "Приготовление чая" может существовать без "Понтов", но "Понты" без чая нет. Если мы выделим "Заливание кипятком" в отдельный включаемый прецедент, то сможем многократно использовать его как для приготовления чая, так и растворимого кофе или лапши. Включить Понты в приготовление растворимого кофе или лапши нельзя.
Если приготовление чая рассматривать как некую процедуру, то это будет процедура с параметром "с понтами" и с ветками, для вызова действий из расширяющего прецедента "Понты" при условии, что "с понтами" = TRUE.

bas mcureenab
Если мы выделим "Заливание кипятком" в отдельный включаемый прецедент, то сможем многократно использовать его как для приготовления чая, так и растворимого кофе или лапши.

А теперь еще добавим ВИ "Заливание молоком" и ВИ "Приготовление Каши". Представим, что каша готовится только на молоке, а кофе может быть как черным так и с молоком. и Получаем, что ВИ "Заливание молоком" есть включение в ВИ "Приготовление каши" и расширением в ВИ "Приготовление кофе". Что то упустил?

Вот пример странных включений.

asafreeЧто касается вопроса 2, то в нём некорректно определён C. Он специализирует сразу 2 UC: А и D. В жизни трудно придумать такой пример поведения.

Формально ошибки нет. То что такая конструкция редко встречается не даёт повода говорить, что C неправильный.

asafreeНо, даже если задаться такой целью и придумать, я бы не стал использовать UC в таком виде. Я упростил бы UC.
Это приведёт к тому, что включающий UC будет однозначно понимать, какой другой UC он включает.

Согласен. Упростить можно. Однако, со временем кто то другой может воспользоваться прецедентом C, чтобы расширить им какой то свой D. В результате мы получим то, что изображено на диаграмме.

asafree mcureenabСогласен. Упростить можно. Однако, со временем кто то другой может воспользоваться прецедентом C, чтобы расширить им какой то свой D. В результате мы получим то, что изображено на диаграмме.
Видимо, я неточно выразил то, что хотел. На мой взгляд такая ситуация бессмыслена. В неформальном варианте. Получается, что я имею некоторый кейс, который специализирует сразу два других по сути (типу) кейса? Кейсы на диаграмме это аналоги классов, это типы кейсов (процессов, ВИ, прецендентов, сценариев, как угодно). Попробуйте придумать инстанции кейса C, который уточняет сразу два других кейса A и D. Мне кажется, это трудно придумать. Я интерпретирую "расширение" примерно так: C является таким же кейсом, что и A, но у него есть вот такое особенное поведение, т.е. C достигает тех же целей, что и A. Трудно сделать так, чтобы C достигал также и цели D. В чём я ошибаюсь?

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

Что касается обобщения и специализации, то это третий вариант зависимости ВИ. Например все переговоры проходят примерно одинаково и имеют единую цель, но переговоры можно проводить по телефону, e-mail, факсами, телеграфом и т.д.. В этом отношении абстрактный ВИ "Переговоры" можно уточнить или специализировать в зависимости от вида связи.

bas mcureenabВот пример странных включений.
И что?? Это ответ на мой вопрос??


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

Ещё можно припомнить, что зависимости не танзитивны (а включение и расширение это именно виды зависимостей), т.е. включение B не означает включение A и тем более C. Это станет понятным, если случай 1 преобразовать в случай 2, т.е. с помощью B расширить какой то другой прецедент G. Тогда все наши соглашения относительно случая 1 потеряют смысл.

_внимательный mcureenabВот пример странных включений.

Если я не ошибаюсь, то
"includingUC" <--- "includedUC"
"extedingUC" ---> "extendedUC"

И для того, чтобы Е включало А(В) надо направить связь расширения от А к В (а не наоборот) и соответсвенно другие связи расширения так же.

Надо, но это полностью изменит суть диаграммы. На диаграмме показано, что при данном расширении (считаем, что оно корректно), включение читается неоднозначно.

Включение это зависимость включающего ВИ от включаемого. Т.е. E зависит от B, а не наоборот, как программа зависит от подпограммы, но не наоборот.

Расширение это зависимость расширения от базового ВИ. Базовый ВИ не зависит от расширения, зато расшиение долно быть полностью согласовано с базой, чтобы добавить к ней новое поведение.