Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Да-да от 29 Марта 2007, 11:57:57
-
Как я себе это представляю:
Задача:
Создать программу для торговли фьючерсными контрактами, опционами и форекс контрактами. Программа включает клиентское приложение и серверное, осуществляющее связь клиентов с clearing firm.
После беседы с заказчиком появляются следующие термины
Conract - ключевая сущность, в которой агрегируются все торгуемые контракты Инструментов. Нужно для обеспечения ссылочной целостности к этой одной сущности из других сущностей, не показанных на схеме
Spot - содержит данные по наиболее простым торгуемым контрактам, таким как: Акций, Облигаций, Индексов, Металов и т.д.
Future - содержит данные по Фьючерсным контрактам
Option - содержит данные по Опционным контрактам. Каждый опцион содержит так называемый underlining контракт, им может быть либо Фьючерс, либо Spot
Asset - базовый актив. Торгуемый контракт Spot или Future имеет под собой один базовый актив, т.е. что реально покупается или продается.
Exchange - Биржа. Один контракт может торговаться только на одной Бирже.
А так же он рассказывает. - "Хочу иметь программу, как trading floor 2, чтобы пользователи подключались и видели информацию по ценам, списки доступных инструментов, размещали ордера различных видов, "оne triggers other", "one cancels other", отложенные ордера. Как администратор хочу иметь доступ к их сделкам, возможность повышать-понижать их maintanance margin, чтобы в конце дня у меня был отчет с балансом, а так же если из-за ситуации на рынке у пользователя баланс начинает стремительно уменьшатся, то я оперативно получаю письмо или смс об этом и связываюсь с ним для решения проблемы, и, если ситуация совсем плоха, то контракты начинают продваться автоматически."
Как бы выглядила диаграмма и звучало резюме аналитика в этом случае?
-
Это достаточно большая задача, на прошлой работе я как раз занимался этим и строил похожую систему. Резюме аналитика в двух словах быть не может. Если Вы только начали заниматься данной темой, то вам будет очень не просто. Сформулируйте пока цели проекта и основные возможности системы в виде каждого отдельного пункта, предложите на базе какой архитектуры будете это делать и оформите в виде документа - Vision. Потом начертите какие по вашему мнению есть бизнес объекты, потом можно накалякать СДВИ (только правильно,если не знаете как, то лучше просто детализируйте каждую фичу) и каждый ВИ распешите в виде сценария. Вот пока ближайшее ваши действия. Я могу накалакать основные БО, какие должны быть в системе, и помочь вам в описании требований, но это уже получиться прямое решение вашей проблемы, которе за бесплатно не делается. Если хотите бесплатных советов, то спрашивайте конкретно, и я вам отвечу.
-
Цели проекта:
Создать программу для онлайн торговли фьючерсами и опционами на биржах.
Возможности системы:
- Получать данные с внешних источников (clearing firm, новостные сайты, другие провайдеры)
- Отсылать ордера в clearing firm.
- Редактировать ордера.
- Менять и запоминать layout клиентской программы.
- Менять и запоминать цвета форм, шрифты клиентской программы.
- Экспортировать формы и таблицы клиентской программы.
- Предоставлять графики.
- Распечатывать ордера.
- Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
- Возможность у клиента иметь несколько accounts.
- Управление accounts для админа.
- Отчеты по account – для админа и клиента.
- Размещение ордера админом для клиента.
- Клиентская программа ведет лог событий.
- События сопровождаются звуками.
- Авто обновление компонентов клиентского приложения.
- Управление margins клиентов админом.
Реализация программ планируется на C# DOT.NET.
В качестве протокола для связи с clearing firm используется patsystem API.
Связь клиентского приложения и сервера через remoting.
Можно выделить два актера
- Админ
- Клиент
Как видно многие функции у них совпадают, но админ имеет больше возможностей. Как мне кажется админ не наследуется от клиента, а они оба происходят от одного предка – пользователя.
Часть фичей сразу просятся в ВИ для актеров:
Пользователь:
- Разместить ордер
- Редактировать ордер
- Создавать отчет
- Экспортировать данные
- Распечатать ордер
Админ:
- Размесить заказ для клиентов
- Управление пользовательским эккаунтом
- Управление margins клиентов
но не все, например
- Получать данные с внешних источников.
- Отсылать ордера в clearing firm
- Менять и запоминать layout клиентской программы.
- Менять и запоминать цвета форм, шрифты клиентской программы
- Предоставлять графики.
- Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
- Возможность у клиента иметь несколько accounts
- Клиентская программа ведет лог событий.
- События сопровождаются звуками.
- Авто обновление компонентов клиентского приложения
Если бы существовал актер Сервер или Клиентская программа, то они ложились бы их ВИ. Как оформляются такие вещи в документации?
ps диаграмму визио выложу завтра, если сумею зарегистрироваться.
-
Цели проекта:
Создать программу для онлайн торговли фьючерсами и опционами на биржах.
Нужна цель Разработки или Системы:
2.4.2. В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.
Возможности системы:
- Получать данные с внешних источников (clearing firm, новостные сайты, другие провайдеры)
Что за данные?[/i]
- Отсылать ордера в clearing firm.
Я бы называл clearing firm - брокером. Разница огромна. Вам же не нужно осуществлять clearing как таковой?[/i]
- Редактировать ордера.
Я бы сказал в первую очередь выствить ордера и только потом редактировать[/i]
- Менять и запоминать layout клиентской программы.
- Менять и запоминать цвета форм, шрифты клиентской программы.
- Экспортировать формы и таблицы клиентской программы.
В один пункт, да и то я бы это опустил[/i]
- Предоставлять графики.
В пукнт с данными[/i]
- Распечатывать ордера.
Только ордера?? Это не та важно[/i]
- Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
- Возможность у клиента иметь несколько accounts.
- Управление accounts для админа.
- Отчеты по account – для админа и клиента.
Входит в управление[/i]
- Размещение ордера админом для клиента.
В п. размещение ордера[/i]
- Клиентская программа ведет лог событий.
Не так важно[/i]
- События сопровождаются звуками.
Не важно[/i]
- Авто обновление компонентов клиентского приложения.
- Управление margins клиентов админом.
А это огромный пукнт, Вы сами не знаете еще на что подписались[/i]
Реализация программ планируется на C# DOT.NET.
В качестве протокола для связи с clearing firm используется patsystem API.
Связь клиентского приложения и сервера через remoting.
Можно БД и ОС указать
Можно выделить два актера
- Админ
- Клиент
А Брокера или Поставщика данных куда дели??
Пользователь:
- Разместить ордер
- Редактировать ордер
- Создавать отчет
- Экспортировать данные
- Распечатать ордер
Это не ВИ - это функции. ВИ должен нести цель для актера. Какая цель у ВИ "Распечатать ордер"?
Админ:
- Размесить заказ для клиентов
- Управление пользовательским эккаунтом
- Управление margins клиентов
Вот это больше похоже на ВИ. Но если Вы пишите все в глаголах, то так и пишите, н-р, "Управлять ...."
но не все, например
Многие ваши ф-ии, войдут в ВИ как составная часть
Как оформляются такие вещи в документации?
Какие??
-
Цели проекта:Создать систему дающую пользователям доступ к онлайн торговле фьючерсами и опционами на биржах посредством одного брокера. Брокер должен поддерживать протокол patsystem API. Система рассчитана на 10 тысяч работающих пользователей. Состоит из двух частей: клиентское приложение и сервер. Клиентское приложение связывается с сервером через интернет по TCP протоколу. Сервер является промежуточным звеном между клиентом и брокером.
Возможности системы:
- Получать данные с внешних источников :
o Списки товаров и их цены
o Историю изменений цен определенных товаров.
o Новости
- Выставлять ордера брокеру и редактировать их.
o Клиент делает это самостоятельно
o Админ делает это для клинта.
o Выставлять отложенные ордера, OCO, OTO.
- Управлять эккаунтом
o Demo accounts (without sending data to the clearing firms) – дает 30 дней бесплатного доступа.
o Возможность у клиента иметь несколько accounts.
o Управление accounts для админа.
o Отчеты по account – для админа и клиента.
Еще добавлю
o Пополнять и снимать деньги со счета.
- Авто обновление компонентов клиентского приложения.
- Авто обновление компонентов клиентского приложения.
- Управление margins клиентов админом.
А это огромный пукнт, Вы сами не знаете еще на что подписались
Хм, в теории этот пункт звучит так: админ неуверен в способности пользователя вести торговлю и завышает его margin. То есть попытки пользователя поместить ордер будут отвергнуты если его текущий баланс ниже какого-то уровня.
Наверное нужно сделать пункт и подпункт.
- Управление эккаунтами клиентов админом
o Управление margins клиентов.
Архитектура
Реализация программ планируется на C# DOT.NET.
В качестве протокола для связи с clearing firm используется patsystem API.
Связь клиентского приложения и сервера через remoting. База данных MSSQL Server 2000. OC - Windows.
Можно выделить следующих актеров:
- Админ
- Клиент
- Брокер
- Поставщик данных
Брокреа наследуем от Поставщика данных, а Админа и Клиента наследуем от Пользователя и выделяем ВИ для всех актеров:
Пользователь:
- Управлять эккаунтом
- Управлять ордерами
Админ:
- Управлять эккаунтами клиентов.
Поставщик данных
- Поставить данные
Брокер
- ?
Получается такая очень мальенькая диаграмма:
Это нонсенс или для верхнего уровня нормально?
-
Цели проектато указаны, а вот какие цели создания самой системы? ;-).
-
Цели проектато указаны, а вот какие цели создания самой системы? ;-).
Ммм... Зачем создавать систему?
- Заказчик хочет отделиться от своего брокера и стать самостоятельным ведя свой бизнес.
-
Так, уже лучше. Т.е.:
Предоставить новый сервис/возможность для 10.000 Клиентов одновреммной торговли на Биржах (каких? всех? какими инструментами?).
Контролировать процесс торговли Клиентами.
Далее ....
З.Ы. Все таки предлагаю отказаться от термина clearing firms, если Вы не вкладываете что-то еще в это понятие кроме Брокера.
З.З.Ы. Выложите диаграмму в формате Розы, я подправлю.
-
Так, уже лучше. Т.е.:
Предоставить новый сервис/возможность для 10.000 Клиентов одновреммной торговли на Биржах (каких? всех? какими инструментами?).
Futures and options. Но предусмотреть возможность расширения для форекса.
З.Ы. Все таки предлагаю отказаться от термина clearing firms, если Вы не вкладываете что-то еще в это понятие кроме Брокера.
В моем понимании Брокер - это посредник между трейдером и биржей. Но если быть точным то эта цепочка на физическом уровне выглядит так:
клиент - брокер - cleargin firm - exchange
Система призвана реализовать звено "Брокер" и, боюсь, при общении с экспертами может возникнуть путаница.
-
Через кого Вы будете торговать, имя?? Т.е. протокол patsystem API к кому будет идти от вас.
Мне кажется Вы путаете понятия. Вообще процесс идет так:
Брокер->Биржа (или даже скорее ECN, а потом уже биржа) - выставление ордера
Брокер->Клиринг - сообщить все ордера, какие были выполнены на Бирже за промежуток времени (день, час ...)
Клиринг->Биржа - сверить полученный список отправленных и реально исполненых на Бирже
Клиринг->Брокер - сообщить какие Ордера реально исполнены, а какие нет. Это происходит раз в день
Причем этот процесс делают только прайм Брокеры. А подброкеры просто все отправляют прайм прокеру:
Брокер -> Прайм Брокер -> Биржа (или даже скорее ECN, а потом уже биржа)
Вы что реально хотите клиерить ордера или просто отправлять их на Биржу??
-
Через кого Вы будете торговать, имя?? Т.е. протокол patsystem API к кому будет идти от вас.
Заказчик не определился. Сошлись на том, что PATSAPI подходит для него, так как существуют десятки брокеров поддерживающих этот протокол и при желании можно свободно переместиться от одного к другому.
Причем этот процесс делают только прайм Брокеры. А подброкеры просто все отправляют прайм прокеру:
Брокер -> Прайм Брокер -> Биржа (или даже скорее ECN, а потом уже биржа)
Вы что реально хотите клиерить ордера или просто отправлять их на Биржу??
В интервью заказчик употреблял clearing firm как партнера через которого ордера будут уходить на биржу. Себя он называл брокером. Этот вопрос я проясню, но, безусловно, задача стоит просто отправлять ордера на биржу, ни о каком клиринге речи не идет.
-
Заказчик не определился. Сошлись на том, что PATSAPI подходит для него, так как существуют десятки брокеров поддерживающих этот протокол и при желании можно свободно переместиться от одного к другому.
Ну Вы и сами ответили себе на вопрос. Заказчик не всегда знает о чем говрит ...
-
Вот что получилось:
-
Целый ВИ под "Войти в систему"? Но ведь на практике пользователь совершит всего несколько поростых действий, навроде "распечатать отчет". Хотя некая законченнченность и невключенность в другие ВИ у "войти в систему" есть...
Так, в голове проясняется. Куда двигаться дальше, по науке?
-
У ВИ "Войти в систему" - одна большая цель - получить доступ к контексту Системы, не сделав этого он не может ничего делать дальше.
Теперь расписывайте каждый ВИ в виде сценария.
-
пробный шар:
Войти в систему:
- Клиент запускает Приложение
- В появившемся окне вводит свой логин\пароль
- Приложение соединяется с Сервером.
- Сервер проверяет пару логин\пароль. Если пара -
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
Олег, не в обиду будет сказано, но Ваш сценарий практическое пособие как не надо делать. Конечно, я не имею большого практического опыта и базируюсь лишь на теоритичексих познаниях книги Коберна (http://www.uml2.ru/index.php?option=com_remository&Itemid=28&func=fileinfo&id=65)
Мое мнение - проштудируйте эту книгу для начала.
Мои замечания:
Избегайте, если в основном сценарии. Основной сценарий - это типичный УСПЕШНЫЙ ход действий. Их может быть несколько. Каждый такой вариант успешного варианта можно выразить как альтернативный поток. В случае срабатывания исключительных ситуаций описывайте их в разделе Исключений. Для примера посмотрите переведенные мною образцы документов по К.Вигерсу (http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=131.msg1795#new)(сообщение 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 прилагаются:
-
ВИ №4 "Поставить данные"
Все начинается с Клиента, он запрашивает данные, потом приложение и только потом ПД
Лучше назвать "Получить данные по котировкам", т.к. основной актер - Клиент.
ВИ №05 "Обновить данные"
Это должно быть альтернативным потоком в сценарии "Поставить данные"
Вообще, не могу ухватить ВИ относящиеся к данным.
Например, логично было бы, что в ВИ где получают данные от Клиринга, например "Посмотреть состояние счета". Шаг "5. Клиринг предает данные серверу" означал бы ссылку на ВИ "Поставить данные". Но они же разного уровня, один "подфункция", другой "цели пользователя". По-видимому ВИ написаны с ошибкой. ???
Или, например, ВИ "Войти в систему " шаги 8 и 9 ведут на "Поставить данные" и "Обновить данные", как-то не уверен что это правильно.
Не уверен где их расписывать... ???
Добавить шаги в местах где передаются данные, такие как "Войти в систему", поподробнее расписать "запросить список commodities, список контрактов"? Или добавить шаг к "Вставить заявку" допустим "1. Пользоватль выбирает контракт", который будет детализирован в ВИ уровня подфункции? Например:
Все это описывается в альтернативных потоках
И все таки ниужели у вас одни и те же функции и у Клиента и у Админа. Админ ничего дополнительного не делает??