Странно, публиковал ответ, а его не вижу. Я удивляюсь не незнанию человека, а нашему образованию. Это же классика!

А чему удивляться? Для меня, например, что DFD, что ДНД - всё едино.

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

Вот я уже раз двадцать заглядывал в словарь, чтобы вспомнить, что такое BPMS. И опять забыл.
А такие сокращения как IDEF0, IDEF1 и т. д. вообще придумали злобные извращенцы.

Да именно так. Исходящих судя по всему 2: из каждого альтернативного сценария + нужно ли в NT какое-то подтверждение слать или нет?

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

Диаграмма коммуникации - collaboration
Примеры в каждой диаграммы в атаче

Спасибо!
Итак, collaboration - она же "коммуникации", "она же контекстная", "она же Д взаимодействия". Я прав?

И я натыкаюсь вот на такие collaboration диаграммы:



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

Спасибо!

Очень совету посмотреть сюда: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_19

Спасибо!
Заглянул. С английским пока туго, ибо "еще учусь". Точнее "перевожу со словарем"

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

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

Итак, collaboration - она же "коммуникации", "она же контекстная", "она же Д взаимодействия". Я прав?

Контекстная Д это не то же самое что collaboration. collaboration=Контекстная Д, когда у Вас показана ваша и др. ИС без внутренностей.

И я натыкаюсь вот на такие collaboration диаграммы:

Простите, где натыкаетесь??

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

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

В вашем конкретном случае (когда идет один запрос) в Д я не вижу смысла.

Смысл, я полагаю, в том, что человек (разработчик, заказчик), читая пункт, с названием функционального требования "Подключение услуги X" глазом упирается в картинку, где видны участники процесса.

Простите, где натыкаетесь??

Повсюду, в интернете. А это не правильный пример? Или... в чем подвох?

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

Спасибо. В разделе "Функциональные требования" не стоит запихивать подразделом "Требования к GUI"? Это уже не есть "ФТ", правильно?

1. Вам виднее, если нужно так делайте, серебряной пули нет.
2. Подвоха нет, просто не понял эту часть Вашего поста.
3. Правильно, "Требования к GUI" - это НЕ "ФТ"

2. Подвоха нет, просто не понял эту часть Вашего поста.

А... просто привел другую, отличающуюся от Вашего примера диаграмму.
Вы привели:



А я "натыкаюсь" на:

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

замечания по потокам:
из п. 2 не понятно что Система находит Пользователя. Т.е. надо так и писать - Система находит зарегистрированного Пользователя по параметрам Запроса. А в 2.1. писать: "Система обнаружила, что Пользователь не зарегистрирован (отсутствует профайл абонента)."
в. п.3. можно написать исключение прямо в этом п., например, "Система проверяет наличие у Пользователя Услуги. Если Услуга не найдена, то сценарий продолжается. Если услуга найдена, то Системе формирует сообщение о наличии услуги у пользователя и сценарий завершается."

Спасибо.

То есть альтернативу засовываем в основной поток? Простите, а что тогда "спускать" в альтернативу? И в каких случаях?
Хочется понять... научиться.

То есть альтернативу засовываем в основной поток? Простите, а что тогда "спускать" в альтернативу? И в каких случаях?
Хочется понять... научиться.

Альтернативу МОЖНО засунуть в основной поток, если она не большая (1-2 пункта) и встречается 1 раз в осн потоке, тем самым получается более полный взгляд и не надо все время сверяться где же она наступила.

Еще раз повторюсь, что для интеграционных задач ВИ лучше не рожать

Почему?

Ты сам сказал выше, что интеграционные задачи касаются взаимодействия 2-х и более систем. А use cases как раз и были придуманы для выявления и хранения требований к интерактивным, а не трансформационным системам.

Ты сам сказал выше, что интеграционные задачи касаются взаимодействия 2-х и более систем. А use cases как раз и были придуманы для выявления и хранения требований к интерактивным, а не трансформационным системам.

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

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

Да почему наша ИС не может быть актором? Где это написано и какой в этом смысл?

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

Получается, вопрос такой: если ВИ нельзя разместить на ДВИ, то он не имеет права на существование? Или это просто терминологическая проблема, и его всего лишь не нужно называть вариантом использования (хотя бы вслух )?

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

Вообще-то может для этого использоваться суррогатный Агент, типа Таймера или Демона.

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

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