Оценка и выбор перспективных направлений разработки

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

Обоснование выбора инструментальных средств

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

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

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

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

Для создания rest, который позволил создать взаимодействие между серверной и клиентской частью, был использован веб-микрофреймворк для JavaSpark. Он позволил быстро создать API, который в дальнейшем использовался для связывания между собой rest и ui.

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

Проектные решения

Обоснованность разделения приложения на клиента и сервер

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

4.2 Диаграмма вариантов использования

Диаграмма вариантов использования (usecasediagram) — диаграмма, на которой изображаются отношения между актерами и вариантами использования.

Вариант использования (usecase) — внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с актерами .

Актер (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними[3].

Рисунок 1. Диаграмма вариантов использования серверной части.

Таблица 1. Детализация вариантов использования

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

Диаграмма классов

Диаграмма классов (англ. StaticStructurediagram) — диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними[3].

Рисунок 3. Диаграмма классов

Диаграмма классов, представленная в рис.3, построена на основе диаграммы вариантов использования. Класс Generic состоит в отношениях наследования со всеми основными объектами, содержит информацию о типе объекта и его идентификаторе. Сущности Пользователь, Оплата тарифа, Счет, Заявки и История тренда являются наследниками класса Generic.

Стержневые сущности:

1. Пользователи(Users) содержит информацию о пользователе: ФИО пользователя, email, телефон, статус активации, статус блокировки, роль, дата создания и обновления записи. Класс Пользователи является наследником класса Geneic. Класс Пользователи имеет связь один-ко-многим со следующими классами: Счет, История сделок, Оплата тарифа и Заявки.

2. История тренда(TrendStory) содержит информацию о прошедших объёмах в каждую минуту времени по активу, его цену открытия, закрытия, наибольшую и наименьшую цену в течение прошедшей минуты. Класс История тренда является наследником класса Generic. Класс История тренда не связан ни с одним из других классов напрямую, но данные формируются на основе проходящих данных в классе Заявки каждую минуту.

Характеристические сущности:

1. Счет(Score) содержит информацию о состоянии счёта(сумма средств) пользователя в данный момент, тип счёта(демо или нет) и id пользователя. Счет является наследником класса Generic. Связан с классом Пользователи многие-к-одному.

2. История сделок(TradeStory) содержит информацию об истории сделок, проведённых определённым пользователем. Имеет информацию об объёме проведённой сделки, о цене покупки и продажи актива, о направлении сделки(long или short) и id пользователя, проведённого сделку. История сделок является наследником класса Generic. Связан с классом Пользователи многие-к-одному.

3. Оплата тарифа(Tariffing) содержит информации обо всех оплатах тарифа пользователем. Имеет сумму оплаты, дату оплаты и id пользователя, произвёвшего оплату. Оплата тарифа является наследником класса Generic. Связан с классом Пользователи многие-к-одному.

4. Заявки(Request) содержит ордера на покупку или продажу по текущему активу. Имеет информацию о цене покупки/продаже актива, объёме ордера, о направлении сделки(покупка/продажа), о времени назначения сделки и id пользователя. Заявки являются наследником класса Generic. Связан с классом пользователи многие-к-одному.

Отношения между классами серверной части:

● Стержневая сущность Пользователи(Users) связана со всеми характеристическими классами по полю user_id, которое указывает какому пользователю принадлежит каждая из записей.

● Сущность История тренда(TrendStory) связана с сущностью Заявки(Request) косвенно. В ходе прохождения заявок в течение минутного таймфрейма формируется класс TrendStory с определёнными полями.

● Класс Generator, который создаётся в отдельном потоке и генерирует случайное число заявок со случайным объёмом проходимых заявок(Request) и по окончанию прохождения генерации создаёт новый класс TrendStory, который сохраняет в базу данных.

● Классы UserService и UserController, которые позволяют через RESTAPI получать данные стержневых и характеристических сущностей, сохранённых в базе данных.

Диаграмма классов клиентской части является такой же, как и диаграмма классов серверной части(рис. 3), т.к. необходимо будет преобразовывать данные из Json в объекты данных классов, которые существуют в серверной части приложения.

Отношения между классами клиентской части:

● Класс FxMarketPxFeeder посылает POST-запросы на сервер для получения ответа в формате Json, который содержит данные о Заявках(Request) и Истории тренда(TrendStrory). Всё это происходит в отдельном потоке. После получения данных они преобразуются в объекты соответствующих типов и далее они преобразуются при помощи библиотек JTable и JFreeChart в графическое представление.

Диаграмма компонентов

Диаграмма компонентов, Componentdiagram — статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т.п.[3]

Рисунок 4. Диаграмма компонентов серверной части.

На диаграмме компонентов(рис. 4) представлен набор библиотек, используемых в данном приложении:

OpenCSV — библиотека для работы с csv-файлами.

SimpleXML — библиотека для работы с xml-файлами.

JDBC (Postgres) — библиотека для работы с базами данных. В данном случае используется спецификация, предназначенная для работы с PostgreSQL.

Log4j — библиотека для журнализации событий.

JUnit — библиотека для создания тестов.

Gson — Google-библиотека, позволяющая работать с Json.

SparkJava — веб-микрофреймворк, предназначенный для создания RESTAPI.

Также приложение предоставляет CLI.

Рисунок 6. Диаграмма деятельности торговли

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