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

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

В нашей практике ВИ идеально подходят, например, для описания взаимодействия приложения терминала ("наша система") с банковским хостом ("внешняя система").
Есть основной сценарий, есть альтернативы, есть начальные условия, есть целевые и минимальные гарантии. Одинаково понятно и разработчику, и заказчику, и тестировщику. То есть выглядит как ВИ и используется как ВИ.

А если что-то выглядит как утка, крякает как утка, плавает как утка и летает как утка, но не укладывается в концепцию "диаграммы уток" - то как его следует называть?

Я допускаю, конечно, что я просто чего-то не знаю. Так дай ссылочку - попробую разобраться, в чём я не прав.

Для размышления.

Пример из книги UML2 b унифицированный процесс Арлоу и Нейшдатда
стр. 452 русского издания  раздел 20.5

Рассматривается проектирование вариантов использования для системы безопасности.

Акторами там являются некий SecurityGuard, Fire(Пожар)  и Intruder(Взломщик)
и рассамтриваются ВИ - деактивация системы, Активациявсего, АктивацияСигналапоПожару и какойто триггерсенсор

система безопасности встроеная работает в автоматическом режиме

Аааааааааааааааааааааааааааааааааа, товарищи,

Ну зачем придумывать Демонов каких-то???

Кто сказал придумывать? На того, кто инициирует интеграционное взаимодействие – на того и вешаем, если Админ – то на Админа, если cron – то на cron'а (Отличая его от Системы как Таймер либо не отличая). В последнем случае это будет чисто Технический Способ Применения (Системный Вариант Использования).

Ну сами говорите, что ВИ - это ПТ, и что ВИ - это цель, а при описании Тр. к интеграции в лучшем случае получаем ФТ и Задачи.

Обновить, скажем, срез куба продаж за последние сутки – вполне себе Цель, связанная с реализацией интересов определённых Заинтересованных Лиц. Про только ФТ и Задачи – когда мы, например, моделировали Гарантированную Доставку для выгрузки Документов Дня Банка в отдельный Архив, мы вполне себе получили полноценный набор сценариев взаимодействия, с ожиданием подтверждения доставки и исключениями. Ещё раз – если интеграционная задача простейшая, не вариативная, т.е. не требующая учёта реакции агента, с которым она взаимодействует, например, генерация RSS или отправка фрагмента данных по почте – то да, можно попытаться обойтись без сценариев, хотя это только основной поток будет вырожденным до 1-2 шагов, а исключения всё равно лучше сценарными методами описывать.

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

А с чего ты решил, что не по назначению? Чем "словесное описание" лучше набора сценариев? Д взаимодействия, как и любая Д, всегда носит вспомогательный характер и не может быть исчерпывающей.

Для размышления.

Пример из книги UML2 b унифицированный процесс Арлоу и Нейшдатда
стр. 452 русского издания  раздел 20.5

Рассматривается проектирование вариантов использования для системы безопасности.

Акторами там являются некий SecurityGuard, Fire(Пожар)  и Intruder(Взломщик)
и рассамтриваются ВИ - деактивация системы, Активациявсего, АктивацияСигналапоПожару и какойто триггерсенсор

система безопасности встроеная работает в автоматическом режиме

Эд, ну встроенное ПО здесь не совсем в кассу, т.к. мы всё-таки про интеграцию. Хотя как пример того, что Способ Применения "Сообщать об инциденте" инициируется отнюдь не Взломщиком и не Огнём – это хорошо.

Ещё хороший пример – отработка любого триггера в БД, например, Журналирование Операций в независимую специализированную систему из, скажем, АБС. Понятно, что запись отдельной операции при взаимодействии с другой системой может пройти более или менее удачно, для описания чего прекрасно подойдут сценацрии, а Агентом будет либо АБС, либо Демон Журналирования (на ваш выбор, меня вполне устроит АБС).

Интересно посмотреть на определения Use Case в интернет.

Первое определение - из Википедии. Именно такой трактовки, насколько я понимаю, придерживается BAS:

A use case is a description of a system’s behaviour as it responds to a request that originates from outside of that system.

Остальные определения, насколько я понял, содержатся в глоссариях различных проектов. Здесь трактовки более широкие, не настолько однозначные. Но интересны тем, что взяты из не учебников, а из реальной практики.

Use case is a sequence of actions that an actor (a person, external entity or another system) performs within a system to achieve a particular goal. Or from inside out, a use case is a sequence of actions a system executes that yield observable results of value to a particular actor.

http://costg9.plan.aau.dk/Bremen2001/Rados/RadosGlossary.htm

Use case describes, from a user’s perspective, a behaviourally related set of transactions that are normally performed together to produce some value for the user. Use cases may be modelled at varying degrees of abstraction, essential use cases, the most abstract, are technologically and implementation independent whereas real use cases describe how the use case actually operates in a particular environment.

http://highered.mcgraw-hill.com/sites/0077110005/student_view0/glossary.html

A use case is a description of how end-users will use a software code. It describes a task or a series of tasks that users will accomplish using the software, and includes the responses of the software to user actions. Use cases may be included in the Software Requirements Document (SRD) as a way of specifying the end-users' expected use of the software.

http://mydocs.epri.com/docs/SDRWeb/processguide/glossary.html

A specific way of using the system by performing some part of the functionality. Each use case constitutes a complete course of action initiated by an actor, and it specifies the interaction that takes place between an actor and the system. The collected use cases specify all the existing ways of using the system.

http://www.iram.fr/~lucas/almassr/SSR-UC-Glossary.html

A Use Case is a series of steps an actor performs on a system to achieve a goal. Actors are "objects" of any type, such as people, parts or other systems.

Следующее определение интересно тем, что помещено почему-то в описание типов данных. Оно самое короткое, но вполне выражает суть.

use case — type of interaction between a system and its environment.

Ну и у тестировщиков, как всегда, свой взгляд на вещи.

Use Case
The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.

http://mavericsys.blogspot.com/2007/11/software-testing-dictionary.html

Ну что еще можно сказать

Нравится Вам описывать требования к интеграции через ВИ - описывайте. Никто Вам запретить не может.

ИМХО у нас получилась путаница, Вы говорите, что Тр. хорошо описывать в виде сценария, я с этим не спорю и даже поддерживаю, но только поэтому Вы назваете эти сценария ВИ, с чем я не согласен.

З.Ы. Гриша, показательно, что у тя нет ни одной цитаты от Коберна

Ну что еще можно сказать

Нравится Вам описывать требования к интеграции через ВИ - описывайте. Никто Вам запретить не может.

ИМХО у нас получилась путаница, Вы говорите, что Тр. хорошо описывать в виде сценария, я с этим не спорю и даже поддерживаю, но только поэтому Вы назваете эти сценария ВИ, с чем я не согласен.

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

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

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

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

З.Ы. Гриша, показательно, что у тя нет ни одной цитаты от Коберна

Мы говорим "usecase", подразумеваем Коберна, мы говорим "Коберн", подразумеваем usecase.

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

Да просто разнеси терминологически на пользовательские use cases (инициируемые пользователями) и системные use cases (инициируемые системой).

Да просто разнеси терминологически на пользовательские use cases (инициируемые пользователями) и системные use cases (инициируемые системой).

ИМХО, ВИ - это часть системы (я имею ввиду системный уровень - более детальный), поэтому лучше все таки выделять акторов. Я например знаю следующие типы акторов:
1. Время (Таймер) - всегда за границами системы (среда)
2. Событие (Обработчик событий) - В одном ВИ завершилось действие, обработчик событий выявил его и инициировал новый ВИ. Я обычно такого актора не ввожу, а описываю события как предусловия в ВИ или подпотоками одного ВИ.
3. Девайс (Датчик) - например, датчик пожара, сообщает системе что начался пожар, датчик дождя сообщает системе о дожде и в машине начинают работать дворники и тд и тп. Причем датчик может мониторить не внешнюю среду но и состояние системы (обработчик событий - частный случай такого датчика)
4. Внешняя система - посылает инициирующее сообщение
5. Пользователь - инициирует какой-либо ВИ руками, через GUI или какой-нибудь скрипт

Один из способов структуризации модели ВИ - в пакеты по акторам. Чтобы отделить пользовательские от других, можно сгруппировать их таким образом.

Да просто разнеси терминологически на пользовательские use cases (инициируемые пользователями) и системные use cases (инициируемые системой).

Тогда уж разделять ВИ на Пользовательские и уровня подфункции.

Сценарии, назовите ЭТО сценариями и делайте ВСЕ ЧТО ХОТИТЕ!
Рисуйте себе статику и динамику КАК УГОДНО -- дерево функций в виде иерархической диаграммы, Взаимодействие, activity ... богатейший арсенал в распоряжении. Зачем рисовать диаграмму ВИ обязательно? Просто чтобы buzzword использовать?
 

Сценарии, назовите ЭТО сценариями и делайте ВСЕ ЧТО ХОТИТЕ!
Рисуйте себе статику и динамику КАК УГОДНО -- дерево функций в виде иерархической диаграммы, Взаимодействие, activity ... богатейший арсенал в распоряжении. Зачем рисовать диаграмму ВИ обязательно? Просто чтобы buzzword использовать?
 

Я скажу по секрету: диаграммы ВИ я вообще не рисовал. До сих пор такой необходимости не возникало.

А вот сами... хм... сценарии мы более-менее освоили.

Урааааааааааааааа, Сценарии - вот так я соглашусь

GUI в ТЗ могут быть, а могут не быть. Ничего предосудительно в этом нет, это как Вам удобнее, мне с GUI удобнее.
Только GUI в этом случае должны быть вынесены в отдельный раздел (требования к экр. формам) и из ФТ должна быть просто ссылка на них.

Я всегда рассматривал ТЗ, как некое описание того, что "должно" (каким-либо образом) быть реализовано в Системе.
А "как это уже реализовано" (или "as is") - это уже был не ТЗ. Это уже был другой документ.
Так вот, готовые снимки экранных форм - это уже (по идее) - "as is".
Насколько правильно их размещать в ТЗ?

Поясните пожалуйста. Или я недопонимаю чего-то.

PS. То же самое касается описания функций (функциональных требований), точнее глубина их детализации.

К примеру: "Система производит переотправку сообщений с интервалом отправки, заданным параметром "Таймер переотправки"".
То есть в примере указано уже конкретное название таймера. Насколько это правильно в ТЗ? Насколько правомерно?