пробный шар:

Войти в систему:
-   Клиент запускает Приложение
-   В появившемся окне вводит свой логин\пароль
-   Приложение соединяется с Сервером.
-   Сервер проверяет пару логин\пароль. Если пара -
   o   не верна, то отправляется сообщение об ошибке - Конец сценария.
   o   верна, то
      §   проверяет список онлайн клиентов и отключает все соединения данного пользователя.
      §   регистрирует данного клиента в списке онлайн
      §   сообщает Приложению об успешной авторизации
      §   отправляет запрос Брокеру об ордерах клиента
      §   получает данные об ордерах и отправляет их Приложению
      §   отправляет Приложению Данные о Ценах и Товарах и Другие Данные (дополнительный сценарий, дополнительное исследование)
-   Конец сценария


Верный ли подход, уровень детализации?
Имеет ли смысл составлять Activity Diagram если сценарий довольно прост и легко воспринимается из текстового попунктного описания?

пробный шар:

Войти в систему:

Вот вам эталон: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=197.msg1798#msg1798
Вам нужно гонять шарик м/у актером и Сиситемой и все, никике детали про Сервере не нужны ...

Имеет ли смысл составлять Activity Diagram если сценарий довольно прост и легко воспринимается из текстового попунктного описания?

Нет, не имеет. Если сценарий сложный, то можно пояснить диаграммой.

ВИ: Получить доступ к торгам

Мне кажется очень обширное понятие. ИМХО, лучше написать: "Войти в Систему"

- Брокер должен авторизовать клиента и обеспечить соблюдение других правил
- Другие клиенты ?? (хотят видеть, кто сейчас находится в системе??)

Брокером в данном случае являемся мы или Система. Если ты о внешнем Брокере, то тут при Логине заинтересованности внешнего Брокера никакой нет.
Др. Клиенты ничего тоже не хотят. Если только Админ хочет видеть все сессии в системе.

Постусловие:

Постусловие ИМХО лучше писать после ветки событий

1. Клиент идентифицирует себя

Как он себя идентифицирует с функц. точки зрения?

З.Ы. Ну зачем изобретать велосипед??? Наберите в гугле Use Case Login .....

переделал

Сценарии для ВИ «Войти в систему»:
Главный успешный сценарий:
1.   Клиент запускает Приложение
2.   В появившемся окне вводит свой логин\пароль
3.   Приложение соединяется с Сервером.
4.   Сервер проверяет пару логин\пароль.
5.   Проверяет список онлайн клиентов и отключает все соединения данного пользователя.
6.   Регистрирует данного клиента в списке онлайн
7.   Сообщает Приложению об успешной авторизации
8.   Отправляет запрос Брокеру об ордерах клиента
9.   Получает данные об ордерах и отправляет их Приложению
10.   Отправляет Приложению Данные о Ценах и Товарах и Другие Данные (дополнительный сценарий, дополнительное исследование)
11.   Конец сценария

Расширения:
4а. Пара логин\пароль не присутствует в базе.
4а1. Сервер уведомляет Пользователя об ошибке авторизации.
4а2. Соединение разрывается.

Как такового, линейного сценария я не обнаружил, получился список действий не связанных друг с другом.
ВИ «Управлять счетом»
Главный успешный сценарий
1.   Если счетов несколько, то Пользователь выбирает счет, с которым будет работать
2.   Пользователь выбирает одно из следующих действий:
   -   Посмотреть текущее или историю состояния счета(Cash and Positions Summary, Margin Summary,Open Positions)
   -   Посмотреть историю всех событий в системе “Activity Log” выбрав одно из следующих значений:
      o   All - показать все записи включая системные, чат, торговые и прочие
      o   Trade Activity - подтверждения и запросы о торгах
      o   Order Activity - размещенные и отменныные ордера
      o   Chat Activity - диалоги с брокером
      o   Other Activity - изменения счета и системные сообщения
   -   Посмотреть историю совершенных торгов «Trades Executed» в виде таблицы*
    -   Прользователь подает заявку на перевод денег со счета на его карточку.
   -    Пользователь пополняет счет с кредитной карточки.
   -    Пользователь посылает сообщение через чат.

Дополнительная информация:
Колонки таблицы  “Trades Executed”: Instrument, B / S, Order, Trade date, Value date, Amount, Price, Commission, Total Trade Cost, Expiry Date, Strike



Это сценарий Пользователя. У Админа есть расширенный сценарий
"Управлять счетом Пользователя"
1. Выбрать Пользователя
2. Выбрать Счет Пользователя
3. Выполнить одно из следующих действий:
3а Перевести деньги с КК Пользователя на Счет
3б Перевести деньги со Счета на КК Пользователя.
3в Перевести деньги со Счета Пользователя на любой другой Счет Пользователя.


Верной дорогой иду?

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

Вы критикуете предыдущий пост или выражаете сомнения по своим ВИ?

ВИ «Управлять счетом»
Главный успешный сценарий
1.   Если счетов несколько, то Пользователь выбирает счет, с которым будет работать
2.   Пользователь выбирает одно из следующих действий:
   -   Посмотреть текущее или историю состояния счета(Cash and Positions Summary, Margin Summary,Open Positions)
   -   Посмотреть историю всех событий в системе “Activity Log” выбрав одно из следующих значений:
      o   All - показать все записи включая системные, чат, торговые и прочие
      o   Trade Activity - подтверждения и запросы о торгах
      o   Order Activity - размещенные и отменныные ордера
      o   Chat Activity - диалоги с брокером
      o   Other Activity - изменения счета и системные сообщения
   -   Посмотреть историю совершенных торгов «Trades Executed» в виде таблицы*
    -   Прользователь подает заявку на перевод денег со счета на его карточку.
   -    Пользователь пополняет счет с кредитной карточки.
   -    Пользователь посылает сообщение через чат.

Дополнительная информация:
Колонки таблицы  “Trades Executed”: Instrument, B / S, Order, Trade date, Value date, Amount, Price, Commission, Total Trade Cost, Expiry Date, Strike

Олег, не в обиду будет сказано, но Ваш сценарий практическое пособие как не надо делать. Конечно, я не имею большого практического опыта и базируюсь лишь на теоритичексих познаниях книги Коберна
Мое мнение - проштудируйте эту книгу для начала.
Мои замечания:
Избегайте, если в основном сценарии. Основной сценарий - это типичный УСПЕШНЫЙ ход действий. Их может быть несколько. Каждый такой вариант успешного варианта можно выразить как альтернативный поток. В случае срабатывания исключительных ситуаций описывайте их в разделе Исключений. Для примера посмотрите переведенные мною образцы документов по К.Вигерсу(сообщение 19).
Сценарий пишется от третьего лица в настоящем времени действительного залога. Четко прописывайте участников взаимодействия (как минимум основное действующее лицо и система). Должна четко ощущаться передача "мяча" между участниками (воздействие - реакция).
Определите уровень ВИ: бизнес-цель, обобщенный уровень, цель пользователя, подфункция...
Шаг в ВИ может вызывать выполнения другого подчиненного ВИ, в этом случае такой шаг подчеркните и опишите его как ОТДЕЛьНЫЙ ВИ
Старайтесь писать ВИ в одном ключе, не допускайте смешение инфинитива (неопределенной или безличной формы глагола ) и личной в одном описании сценария

Это сценарий Пользователя. У Админа есть расширенный сценарий
"Управлять счетом Пользователя"
1. Выбрать Пользователя
2. Выбрать Счет Пользователя
3. Выполнить одно из следующих действий:
3а Перевести деньги с КК Пользователя на Счет
3б Перевести деньги со Счета на КК Пользователя.
3в Перевести деньги со Счета Пользователя на любой другой Счет Пользователя.

ВИ_2. "Управлять счетом Пользователя"
ОДЛ: Администратор - Адм
Предусловие: загружена форма (таблица) пользователей системы
Основной поток событий:
1. Адм выбирает Пользователя из списка (возможно выполняет подчиненый ВИ Найти пользователя)
2. Система отображает карточку пользователя (да что отображает система в ответ на выбор пользователя? Как Вы думаете можно ли об этом догадаться? Сможет ли скажем программист понять а как должна выглядеть информация о пользователе?)
3. Адм выбирает Счет Пользователя (а если у пользователя нет еще счета? - кандидат для обработки исключения)
4. Система предоставляет Адм варианты действий (все они вполне возможные кандидаты на варианты использования, которые должны прописаны - опять же смотрите примуры Вигерса и Коберна):
   4а Перевести деньги с КК Пользователя на Счет
       бла-бла-бла
   4б Перевести деньги со Счета на КК Пользователя.
       бла-бла-бла
   4в Перевести деньги со Счета Пользователя на любой другой Счет Пользователя.
       бла-бла-бла

Думаю лучше описать не управление счетом пользователя а три конкретных ВИ либо один под названием Перевести деньги с 1 основным (типичным чаще всего возникающих ситуация) и 2 альтернативными (см Вигерс - мой перевод - ссылка выше)

Очень надеюсь, что был Вам полезен, и сам не допустил особо грубых ошибок

Вы критикуете предыдущий пост или выражаете сомнения по своим ВИ?

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

В общем, ушел читать Коберна, но я продолжу выставлять свои поделки.

Как такового, линейного сценария я не обнаружил, получился список действий не связанных друг с другом.
ВИ «Управлять счетом»
...............................
Верной дорогой иду?

Вы все смешали в кучу: управление счетом, просмотр статистики/отчетов, и, возможно, управление позициями.
Как сказал Galogen, не бойтесь если у вас будет несколько основных сценариев

И так,
Управлять Счетом:
Пользователь просматривает счета
Прользователь подает заявку на перевод денег со счета на его карточку.
Пользователь пополняет счет с кредитной карточки.
3а Перевести деньги с КК Пользователя на Счет
3б Перевести деньги со Счета на КК Пользователя.
3в Перевести деньги со Счета Пользователя на любой другой Счет Пользователя.

Просмотреть статистику/отчеты:
Посмотреть историю всех событий в системе “Activity Log” выбрав одно из следующих значений:
Посмотреть историю совершенных торгов «Trades Executed» в виде таблицы*

Послать сообщение через чат:
Пользователь посылает сообщение через чат.

В общем, ушел читать Коберна, но я продолжу выставлять свои поделки.

И это правильно. Сначала, конечно, следует прочитать и изучить "теорию". Почему в кавычках? Потому как это, конечно, не теория, а квинтэссенция жизненного опыта.
Я лишь посоветую. Напишите, сначала, простую связную историю того, как пользователь  управляет счетом. Думаю у Вас сразу появятся проблемы. Поскольку "Управлять счетом" - это довольно много различных потоков событий, которые вполне могут быть независимыми. Какая основная цель написания таких сценариев? Понять требования пользователей или цели пользователй от использования системы. Попытаться ихописать максимально понятным и простым языком. Поэтому и предлагается избавляться от если - ВИ - это не чистый алгоритм действий, а набор действий, который можно рассмотреть как набор основных успешных типичных потоков = альтернативных потоков и исключительных ситуаций.

Например Оплата товара:
Покупатель подходит к кассе
Кассир вводит цену каждого товара и его количество.
Кассир подсчитывает сумму покупки
Кассир пробивает чек
Покупатель расплачивается
Кассир выдает сдачу.

Т.е. неявно в нашем сценарии делается упор на оплату наличными, а что если оплата производится кредитной или депозитной картой.
Поэтому можно в приницпе описать два сценария: Оплата товара наличными и Оплата товара по кредитной карте. В дальнейшем можно слить два сценария в один, но с альтернативой.

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

2 Boatman
Я идею твою понял, но зря ты разбил ВИ на более мелкие, это еще больше запутает Олега. Не надо вообще показывать пока, что так можно делать, т.к. ты бьешь ВИ на ф-ции, что неправильно. ДД в тему.

Про других клиентов.. Я тода не понял, с какой целью (в чьих интересах) вошедший засвечивается в списке игроков онлайн? Если убрать это требование, то чьи интересы пострадают?

Пострадает только Админ и Чат-Сотрудник(если таковой есть), т.к. другие клиенты не должны видеть тебя. Ведь когда ты Форекс платформу открываешь, ты же не видешь там др. участников.

Давайте подведем промежуточный итог.

Черновик целей и возможностей проекта: http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=200.msg1813#msg1813


Диаграмма.
Уровень: обобщенный.
Область действия: бизнес.
http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=200.msg1828#msg1828

Актеры	ВИ
Пользователь	Войти в систему
.	Управлять счетом
.	Вставить/изменить заявку
Поставщик данных	Поставить данные

Сценарий для Войти в систему приведен выше, это был ВИ №1. http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=200.msg1905#msg1905

Новое


Сценарий для ВИ №2 Управлять счетом:
Основное действующее лицо: Пользователь (П)
Область действия: клиентская программа.
Уровень: цель пользователя.

Главный сценарий:
1.   П выбирает счет, с которым будет работать
2.   П запускает один из следующих ВИ:
-   Посмотреть состояние счета.
-   Посмотреть историю событий в системе.
-   Посмотреть историю совершенных торгов

Расширения:
2а Распечатывает необходимую информацию.


ВИ №3 «Вставить/Изменить заявку»
Основное действующее лицо: Пользователь (П)
Область действия: система Опти (клиентская программа).
Уровень: цель пользователя.

Главный сценарий:
1.   П создает новую заявку.
2.   П записывает необходимые данные (инструмент, цена и т.д)
3.   П одобряет заявку и передает ее системе.
4.   Система передает заявку Клирингу.
5.   Клиринг ее проверяет и одобряет.
6.   Заявка сохраняется в системе
7.   Счет П обновляется.

Расширения:
1а. П открывает одну из старых заявок.
5а. Заявка не получает одобрения
   5а1. П получает сообщение о несоответствии заявки каким-либо требованиям
   5а2. П отменяет заявку либо меняет ее и снова посылает.


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

Следующий сценарий совсем поставил меня в тупик, потому, что уровень обобщенный\цели пользователя не несет никакой полезной информации, он просто просится в подфункцию, но, если делать сценарий уровня цели пользователя, то:

ВИ №4 «Поставить данные»
Основное действующее лицо: Поставщик данных (ПД)
Область действия: система Опти (сервер).
Уровень: цели пользователя.
Главный сценарий:
1. Система регистрируется у ПД.
2. ПД передат данные системе.

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


В сценариях активно используется слово "система" и из некоторых шагов сценария хочется заглянуть внутрь и написать ВИ "прозрачного ящика", соответственно введя новых актеров Сервер и Клиентское приложение, это приемлемо?

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

Очень неплохо на мой взгляд.

Однако немного критики.
Управлять счетом пока пропущу. Мне, кажется, его надо сначала закончить.

Вставить/изменить заявку. Думается, для начала имеет смысл рассмотреть их как отдельные UC. Одно дело когда создается новая заявка, другое, когда изменяется уже имеющаяся.
Вы определили в данном случае цель пользователя. Это, кажется, очевидным. Однако какой тип UC. Черный или белый ящик?
Черный, когда внутренние действия системы не раскрываются, т.е. случай когда пользователь не знает, как это делает система. Он лишь знает как она должна реагирует на действия пользователя. На мой взгляд мы имеем в данном случае все-таки прозрачный ящик (хотя я могу и ошибаться). Почему? Мы видим что система передает заявку Клирингу, то ее одобряет, после чего система сохраняет заявку и изменяет счет.
На мой взгляд если мы пишем "черный ящик" нужно передавать мяч между пользователем и системой.

1.   П создает новую заявку.
2.   П записывает необходимые данные (инструмент, цена и т.д)
3.   П одобряет заявку и передает ее системе.
4.   Система сохраняет заявку и обновляет счет
Исключения
1а. П открывает одну из старых заявок (другой ВИ, а не исключение существующего. Либо другой альтернативный поток).
5а. Заявка не удовлетворяет требованиям
   5а1. Система извещает пользователя о несоответствии заявки каким-либо требованиям
   5а2. П отменяет заявку или переходит к пункту 2.


Далее
ВИ №4 «Поставить данные»
Основное действующее лицо: Поставщик данных (ПД)
Область действия: система Опти (сервер).
Уровень: цели пользователя.
Главный сценарий:
1. ПД передает данные системе.
2. Система подтвержадет получение данных

Думаю в данном случае могут быть особо интересны исключения: данные не приняты, разорвано соединение, и т.д.

Олег, уже лучше.

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

Д. у тебя уровня пользователя или СДВИ, тут никак бизнесом не пахнет. И Адмимнтратор тому подтверждение.

ВИ №4 «Поставить данные»

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

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

А это уже будет Дизайн и элементы реализации, это потом, ты пока описываешь функционирование/функционал.

В сценариях активно используется слово "система" и из некоторых шагов сценария хочется заглянуть внутрь и написать ВИ "прозрачного ящика", соответственно введя новых актеров Сервер и Клиентское приложение, это приемлемо?

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

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

2 Galogen

На мой взгляд мы имеем в данном случае все-таки прозрачный ящик (хотя я могу и ошибаться). Почему? Мы видим что система передает заявку Клирингу, то ее одобряет, после чего система сохраняет заявку и изменяет счет.
На мой взгляд если мы пишем "черный ящик" нужно передавать мяч между пользователем и системой.

Между АКТЕРОМ и Системой, Клиринг - это актер, Олег почему-то упорно не хочет назвать его Брокером, ну да ладно... Олег более правильно описал ВИ, т.к. если не взять Клиринг, то цель будет не достигнута - заявка не будет выставлена на Бирже.
Да, я был не прав, когда назвал ВИ "Вставить/изменить заявку", сам учу тому, что низя делать. ВИ должен называться однозначно - "Вставить заявку". В рамках этого ВИ будет альтернативный поток - "изменить (replace) заявку"

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

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

Итак список актеров:
Пользователь, Сервер, Клиринг, Поставщик Данных.

Из них все, кроме Поставщика Данный, будут иметь конкретные реализации, Поставщик Данных - это открытый вход в систему для возможных внешних актеров, которые будут поставлять данные. Конкретной реализации в ближайшее время не предвидится.

На данный момент у меня 6 ВИ уровня моря.
Сценарии для ВИ #1 «Войти в систему»:
Основное действующие лицо: Пользователь
Область действия: клиентская программа
Уровень: голубой (цель пользователь)
Главный успешный сценарий:
1. П запускает Приложение
2. В появившемся окне вводит свой логин\пароль
3. Приложение соединяется с Сервером.
4. Сервер проверяет пару логин\пароль.
5. Сервер проверяет список онлайн клиентов и отключает все соединения данного пользователя.
6. Сервер регистрирует данного клиента в списке онлайн
7. Сервер сообщает Приложению об успешной авторизации (which is recorded in logs with date and time)
8. Сервер отправляет запрос Клирингу об ордерах клиента и всю клиентскую информацию.
9. Сервер получает данные от Клиринга о текущих и старых ордерах и отправляет их Приложению
10. Сервер отправляет Приложению данные о ценах и товарах.
11. Конец сценария
 
 
Расширения:
4а. Пара логин\пароль не присутствует в базе.
4а1. Сервер уведомляет Пользователя об ошибке авторизации.
4а2. Соединение разрывается.
Вариант Использования № 05 "Работать с клиентской программой"
Основное действующее лицо: Пользователь
Область действия: клиентская программа.
Уровень: цель пользователя.
 
Главный успешный сценарий:
1. П выбирает счет с которым хочет работать.
2. П выбирает одно из следующих действий:
- Управлять счетом
- Вставить заявку
3. Это продолжается до тех пор пока пользователь не выйдет из программы.
 Сценарий для ВИ №2 Управлять счетом:
Основное действующее лицо: Пользователь (П)
Область действия: клиентская программа.
Уровень: цель пользователя.
Предусловия: П зарегистрирован в системе.
 
Главный сценарий:
1.   Система предоставляет доступные функции, П выбирает и выполняет одну из них:
-   Посмотреть состояние счета.
-   Посмотреть историю событий в системе.
-   Посмотреть историю совершенных торгов

ВИ №3 "Вставить заявку"
Основное действующее лицо: Пользователь (П)
Область действия: система (клиентская программа).
Уровень: цель пользователя.
 
Главный сценарий:
1.   П создает новую заявку.
2.   П заполняет необходимые данные (инструмент, цена и т.д)
3.   П одобряет заявку и передает ее системе.
4.   Система передает заявку Клирингу.
5.   Клиринг ее проверяет и одобряет.
6.   Заявка сохраняется в системе
7.   Счет П обновляется.


Расширения:
1а. П открывает одну из старых заявок.
5а. Заявка не получает одобрения
 5а1. П получает сообщение о несоответствии заявки каким-либо требованиям
 5а2. П отменяет заявку либо меняет ее и снова посылает.
 
ВИ №4 "Поставить данные"
Основное действующее лицо: Поставщик Данных (ПД)
Область действия: система.
Уровень: цель пользователя.
Предусловие: Между Сервером и ПД установлено соединение.
 
Главный сценарий:
1. Сервер отравляет заявку ПД.на определенные данные*.
2. ПД передает данные Серверу.
 
Расширения:
Происходит разрыв соединения:
1. Сервер соединяется снова.
2. Сценарий запускается сначала.
 
 
Комментарии:
*Данные могут быть: Price, Commodity, Contract, Trader, Order, Fill, Charts.
Вариант Использования №06 "Подписаться на данные"
Основное действующее лицо: Сервер
Область действия: система.
Уровень: цель пользователя.
Предусловие: Сервер подключен к Клирингу
 
Главный успешный сценарий:
1. Сервер отправляет Клирингу заявку на подписку*.
2. Клиринг заносит Сервер в список  и начинает передавать ему данные.
3. Это продолжается пока Сервер не отпишется или не отключится.
 
 
Расширения:
Разрыв соединения означает отписку от всех подписок.


Комментарии:
*Подписки могут быть: Price Update, Order State, Fill details for an order.


Как мне кажется, отдельные шаги данных ВИ будут уже более низкого уровня, кишки программы или интерфейс, не уверен нужно ли их детализировать.

Верно ли?
Что дальше?

Красивый файл в виде CHM пралагается.

Ну во первых сервер ни к чему. Это точно не актер, так же как и приложение, это элемент представления (частично прозрачный ящик).

Разве целью Пользователя можно назвать - "Работать с клиентской программой". НЕТ. Ты мешаешь иерархическое представление требований и ВИ. Так нельзя. Цель может - управлять счетом, выставить заявку, но не как не "Работать с клиентской программой".

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

Ты мешаешь иерархическое представление требований и ВИ. Так нельзя.

От неба к маллюскам. Шаг верхнего уровня детализируется ВИ нижнего уровня. Разве ВИ не являются иерархией? Хотя практической пользы от ВИ "работать с программой" не увидел.

Добавил 5 новых ВИ:
- Посмотреть состояние счета
- Посмотреть историю событий в системе
- Посмотреть историю совершенных торгов
Их я посчитал подфункциями.
Вариант Использования №06 "Посмотреть состояние счета"
Основное действующее лицо: Пользователь
Область действия: система.
Уровень: подфункция

Главный успешный сценарий:
1. Приложение отображает состояние счета на текущую дату.
2. Пользователь выбирает дату на которую смотреть состояние счета.
3. Приложение запрашивает у сервера данные за определенную дату.
4. Сервер запрашивает данные у Клиринга.
5. Клиринг предает данные серверу.
6. Сервер передает данные приложению.
7. Приложение отображает состояние счета за выбранную дату.


Расширения:
На любом этапе произошел разрыв связи между приложением и сервером
 а1. Приложение делает недоступными свои функции пока соединение не восстановится.


На любом этапе произошел разрыв связи между сервером и Клирингом.
 а1. Сервер уведомляет приложение о разрыве связи.
 а2. Приложение делает недоступными свои функции.
и ВИ "Общаться по чату" уровня "цели пользователя"
Вариант Использования №09 "Общаться по чату"
Основное действующее лицо: Пользователь
Область действия: клиентская программа.
Уровень: цели пользователя.

Главный успешный сценарий:
1.Приложение отображает сообщения за последнюю неделю.
2.Пользователь пишет и отправляет сообщение.
3.Приложение отправляет сообщение серверу.
4.Сервер рассылает сообщение всем Пользователям.
5.Это продолжается пока Пользователь не закроет чат.


Расширения:
На любом этапе произошел разрыв связи между приложением и сервером
 а1. Приложение делает недоступными свои функции пока соединение не восстановится.

Объединил "Подписаться на данные" и "Поставить данные"
ВИ №4 "Поставить данные"
Основное действующее лицо: Поставщик Данных (ПД)
Область действия: система.
Уровень: цель пользователя.
Предусловие: Между сервером и ПД установлено соединение.

Главный сценарий:
1.Сервер отправляет ПД заявку на данные.
2.ПД оформляет постоянную подписку* на конкретные данные.
3.ПД передает данные серверу.
4.Сервер обновляет данные у Пользователей.
5.Пока подписка действует ПД продолжает передавать данные серверу.



Расширения:
1.Происходит разрыв соединения:
2.ПД исключает сервер из всех подписок.
3.Сервер снова соединяется с ПД.
4.Сценарий запускается сначала.

2а ПД оформляет единовременную подписку**


Комментарии:
*Постоянные подписки могут быть: Price Update, Order State, Fill details for an order.
**Единовременные  могут быть: Price, Commodity, Contract, Trader, Order, Fill, Charts.

ВИ №05 "Обновить данные"
Основное действующее лицо: Пользователь (П)
Область действия: система
Уровень: подфункция.
Предусловие: Пользователь вошел в систему, Сервер получил новые данные от Поставщика Данных.

Главный сценарий:
1.   Сервер проходит по списку пользователей и проверяет каким Пользователям необходимы новые данные.
2.   Сервер отсылает Пользователю новые данные.
3.   Приложение отображает Пользователю новые данные.

Расширения:
НЕТ
"Обновить данные" получается подфункция ВИ "Поставить данные". Странно, что у ВИ "Поставить данные" основное действующее лицо Поставщик Данных, а у ВИ "обновить данные" - Пользователь. Наверное, я тут чего-то наворотил не того.

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

Нужно детализировать:
-   какие данные получают

Не уверен где их расписывать... 
Добавить шаги в местах где передаются данные, такие как "Войти в систему", поподробнее расписать "запросить список commodities, список контрактов"? Или добавить шаг к "Вставить заявку" допустим "1. Пользоватль выбирает контракт", который будет детализирован в ВИ уровня подфункции? Например:
ВИ "Выбрать контракт".
1. Приложение запрашивает Сервер о списке контрактов
2. Сервер передает последний список приложению.
3. Приложение отображает список Пользователю.
4. Пользователь выбирает контракт.

Расширения
2а Список не удовлетворяет представлению о "свежести"
2а1. Сервер запрашивает последний список контрактов у Клиринга.
2а2. Клиринг передает список серверу.

Диаграмма и красивый файл в виде chm прилагаются: