CC BY
21
ИССЛЕДОВАНИЕ ПОДХОДОВ К ПРОЕКТИРОВАНИЮ
ТРЕЙДИНГОВОЙ ИНФОРМАЦИОННОЙ ПЛАТФОРМЫ
1 2
Ключев А.О. , Трезубов К.А. Email: Klyuchev689@scientifictext.ru
1Ключев Аркадий Олегович - кандидат технических наук, доцент;
2Трезубов Кирилл Аркадьевич - магистрант, факультет программной инженерии и компьютерной техники, Санкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, г. Санкт-Петербург
Аннотация: в статье анализируются программная, проектная архитектуры, методологии проектирования трейдинговой информационной платформы. Цель работы: выбрать лучшую методологию проектирования трейдинговой информационной платформы. Основные задачи: произвести сравнительный анализ моделей ЖЦ, архитектурных стилей, архитектурных шаблонов, фреймворков (каркасов) проектирования архитектуры предприятия, выбрать наилучший архитектурный шаблон для проектирования трейдинговой информационной платформы, разработать проектную архитектуру.
Ключевые слова: архитектура, жизненный цикл, информационная система, трейдинговая платформа, архитектурный стиль, архитектурный шаблон, фреймворк, микросервисная архитектура, микросервис, платформа.
RESEARCH OF APPROACHES TO DESIGNING A TRADING
INFORMATION PLATFORM 12 Klyuchev A.O. , Trezubov K.A.
1Klyuchev Arkady Olegovich - Candidate of Technical Sciences, Docent;
2Trezubov Kirill Arkadevich - Master, FACULTY OF SOFTWARE ENGINEERING AND COMPUTER ENGINEERING, SAINT-PETERSBURG NATIONAL RESEARCH UNIVERSITY OF INFORMATION TECHNOLOGIES, MECHANICS AND OPTICS, ST.-PETERSBURG
Abstract: the article analyzes software architecture, design architecture, design methodologies of a trading information platform. Objective: to choose the best methodology for designing a trading information platform. The main tasks: to conduct a comparative analysis of life cycle models, architectural styles, architectural templates, frameworks (frames) for enterprise architecture design, choose the best architectural template for designing a trading information platform, and develop design architecture. Keywords: architecture, life cycle, information system, trading platform, architectural style, architectural template, framework, microservice architecture, microservice.
УДК 004.274
Современные компании получают массу преимуществ от внедрения средств электронной коммерции по работе с заказчиком, поставщиком или клиентами, так называем трейдинговыми платформы или CRM систем.
Трейдинговая платформа - компьютерная система, которая может использоваться, чтобы разместить заказы финансовых продуктов, таких как акции, облигации, валюты, биржевой товар и деривативы с финансовыми посредниками по сети.
На данный момент существует ряд проблем с проектированием трейдинговых платформ: выбор определенного процесса и выбор модели жизненного цикла разработки таких систем, существует множество типов архитектур для проектирования систем, в которых сложно разобраться, существует множество
архитектурных стилей, существует множество фреймворков (каркасов) для построения коммуникационных платформ, проблема интеграции и внедрения разработанной информационной системы в бизнес - процесс рабочего предприятия.
Обилие проблем делает порой задачу проектирования трейдинговой платформы сложной и не понятной.
В данной статье авторы рассматривают различные методологии проектирования коммуникационных платформ, производят сравнительный анализ и выбирают лучшую методологию в зависимости от выбранной архитектуры.
Начинать проектирование любой трейдинговой платформы стоит с выбора модели жизненного цикла (далее ЖЦ) разработки программного продукта. Сравнительный анализ моделей ЖЦ детально описан в книге Рудакова А.В. [1].
На основании [1] сформулируем следующие требования к программным продуктам, построенным на определенных моделях ЖЦ (таблица 1).
Таблица 1. Сравнительная характеристика требований к проектам в зависимости от
выбранной модели ЖЦ
Модель Требования к проектам
Каскадная модель 1. Информационные системы, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования с целью предоставить разработчикам свободу реализовать их технически лучше.
V - образная модель 1. Высокая надежность
Модель прототипирования 1. Требования к ПП заранее неизвестны; 2. Требования не постоянны или неудачно сформулированы; 3. Требования необходимо уточнить; 4. Нужна проверка концепции; 5. Существует потребность в GUI; 6. Выполняется новая, не имеющая аналогов разработка; 7. Разработчики не уверены в том, какое решение следует выбрать.
Модель быстрой разработки приложений (RAD) 1. Программные продукты хорошо поддаются моделированию; 2. Требования к ПП хорошо известны; 3. Заказчик может принять непосредственное участие в процессе разработки.
Многопроходная модель 1. Большинство требований к ПП сформулировано заранее; 2. Для выполнения проекта выделен большой период времени.
Спиральная модель 1. Целесообразно создание прототипа; 2. Организация обладает навыками, требуемыми для адаптации модели; 3. Требуется выполнять проекты со средней и высокой степенями риска; 4. Заказчик не уверен в своих потребностях; 5. Требования слишком сложные; 6. Проект очень большой.
На основании таблицы 1 можно сделать вывод, что водопадная (каскадная) модель подходит для сложных систем с большим числом вычислительных задач, систем реального времени. V - образная модель подходит для систем с четким ТЗ, в план разработки которых включен значительный этап тестирования. RAD - модель можно применять при разработке программных продуктов (ПП далее), которые хорошо поддаются моделированию, когда требования к ПП хорошо известны и заказчик может принять непосредственное участие в процессе разработки. Многопроходную модель применяют для систем, в которых большинство требований сформулировано заранее и для выполнения проекта выделен большой период времени. Модель прототипирования подходит для быстрого создания MVP коммуникационной платформы или когда заказчик не знает, чего ожидать от системы. Спиральная модель хорошо подходит для команд, которые работают по Agile методологии.
После выбора модели ЖЦ идет выбор архитектуры программной платформы. Существует несколько шаблонов архитектуры [2]. В данной статье рассматриваются следующие архитектурные шаблоны: многоуровневая архитектура, событийная архитектура, микроядерная архитектура, микросервисная архитектура, облако.
За критерии сравнения авторы решили взять: общую подвижность (Overall Agility), развертывание (Deployment), тестирование (Testability), производительность (Performance), масштабирование (Scalability), разработка (Development). В качестве критериев оценивания были выбраны: Low - низкая эффективность, High - высокая эффективность.
Общая подвижность (Overall Agility) - способность системы к быстрым изменениям под действием окружающих факторов.
Сравнительная характеристика представлена в таблице 2.
Таблица 2. Сравнительная характеристика архитектурных шаблонов разработки программного обеспечения
Многоур овневая (Layered) COSMT iiiiiiai (Event driven) Микрояде рная (Microkern el) MHKpocep liiiciiasi (Microserv ices) Облачна я (Space -Based)
Общая подвижность (Overall Agility) Low High High High High
Развертывание (Deployment) Low High High High High
Тестировавние (Testability) High Low High High Low
Производительность (Perfomance) Low High High Low High
Масштабирование (Scalability) Low High Low High High
Разработка (Development) High Low Low High Low
На основании таблицы можно сказать, что абсолютно универсального шаблона, который подходил под все ситуации не существует, однако можно выделить некоторые общие тенденции. Так, например, если основная архитектурная задача состоит в создании системы, которая обладает большой способностью к масштабируемости, то имеет смысл обратить внимание на шаблон, управляемый событиями, микросервисный шаблон и шаблон на основе облачной архитектуры.
Следующим шагом проектировщика может стать анализ архитектурных стилей. Авторы предлагают рассмотреть следующие архитектурные стили: пакетно-последовательный, конвейеры и фильтры, программа - сопрограмма, объектно-
ориентированный, клиент-серверный, иерархический многоуровневый, взаимодействующие процессы, управляемый событиями, централизованная база данных, классная доска. Рассмотрение, анализ и сравнение архитектурных стилей детально приведен в [1] и в данной статье не рассматривается.
Так как программная архитектура и архитектура предприятия тесно связаны между собой, то следующий шагом может стать выбор архитектуры предприятия. В данной статье рассматриваются следующие фреймворки для выбора архитектуры предприятия: Фреймворк Захмана [3], TOGAF [4], DoDAF [5], FEA [6], Gartner [7].
Приведенные фреймворки очень сильно отличаются между собой, поэтому для правильного и корректного сравнения между ними необходимо задать определенные критерии. Зададим следующие критерии (таблица 3): полнота таксономии, полнота процесса, руководство по эталонным моделям, практическое руководство, модель готовности, ориентированность на бизнес, руководство по управлению, руководство по разбиению, наличие каталога, нейтральность по отношению к поставщикам услуг, доступность информации, время окупаемости инвестиций и произведем сравнение. Шкала оценивания: 1 - 4.
Таблица 3. Оценка современных фреймворков по критериям
Критерии Захман TOGAF FEA Gartner DoDAF
Полнота таксономии 4 2 2 1 2
Полнота процесса 1 4 2 2 3
Руководство по эталонным 1 4 2 3 3
моделям
Практическое руководство 1 2 2 4 2
Модель готовности 1 1 3 2 1
Ориентированность на бизнес 1 2 1 4 2
Руководство по управлению 1 2 3 3 2
Руководство по разбиению 1 2 4 3 2
Наличие каталога 1 2 4 2 3
Нейтрально к поставщикам 2 4 3 1 2
Доступность информации 2 4 2 1 2
Время окупаемости инвестиций 1 3 1 4 1
Исходя из анализа таблицы 3, можно сделать вывод, что ни один из фреймворков не является полным. Для того чтобы выбрать правильный фреймворк, необходимо задавать критерии, которые важны определенной организации. Очень часто не удается выбрать один единственный фреймворк и приходится прибегать к практике смешивания конкретных фреймворков для конкретной компании.
Основываясь на сравнении фреймворков, моделей жизненного цикла, архитектурных шаблонов и стилей, таблицах 1 - 3, составим таблицу 4.
Архитектурный шаблон Архитектурный стиль Модель ЖЦ Фреймворк
Многоуровневая архитектура 1. Клиент -серверный 2. Иерархический многоуровневый 3. Централизованная БД 1. Каскадная 2. V - образная 1. Захман 2. DoDAF 3. Gartner
Событийная архитектура 1. Пакетно -последовательный 2. Управляемый событиями 3. Объектно -ориентированный 4. Конвейеры и фильтры 5. Клиент - серверный 1. Прототипирован ия 2. RAD 3. Спиральная 1. TOGAF 2. FEA 3. Gartner
Архитектура микроядра 1. Программа -сопрограмма 2. Централизованная БД 3. Клиент - серверный 1. Каскадная 2. V - образная 3. Многопроходная 1. Захман 2. DoDAF 3. Gartner
Микросервисная архитектура 1. Пакетно -последовательный 2. Управляемый событиями 3. Объектно -ориентированный 4. Конвейеры и фильтры 5. Клиент - серверный 1. Прототипирован ия 2. RAD 3. Спиральная 1. TOGAF 2. FEA 3. Gartner
Облачная архитектура 1. Клиент -серверный 2. Взаимодействуют^ е процессы 3. Классная доска 1. Многопроходная модель 1. TOGAF 2. FEA 3. Gartner
При анализе таблицы 4 можно увидеть, что фреймворк Gartner подходит для всех типов архитектур. Это связано с тем, что он ориентирован на бизнес и является практическим руководством, которое дает рекомендации по построению архитектуры предприятия.
На основании таблицы 2 можно заключить, что микросервисный шаблон обладает самым большим количеством преимуществ. В современных компаниях стартапах данный шаблон стал де-факто. Авторы предлагают выбирать именно его для построения трейдинговой платформы в сочетании с архитектурными стилями, моделями ЖЦ и фреймворками представленными в таблице 4. На это есть ряд причин:
1. Большая поддержка IT сообществом;
2. Легко внедряется в бизнес-процесс CRM (один раздел - один микросервис);
3. Устойчивость к падению системы, что важно для клиент ориентированных платформ.
Архитектуру проектов рекомендуется организовать по принципу чистой архитектуры [8]. Разделение программного обеспечения должно происходить на четыре уровня (рисунок 1).
Рис. 1. Чистая архитектура
На практике, для удобства проекты следует организовать следующим образом:
Уровень домена (Data Layer) - директория domain - состоит из сущностей (entities), сценариев использования (use case) и репозитория с интерфейсами.
Уровень данных (Data Layer) - директория data - включает в себя репозиторий (repository) с реализацией интерфейсов, драйвера базы данных, шину брокера сообщений, API и фреймворки.
Приложение (Application) - содержит конфигурационные файлы, класс Main для запуска приложения.
В данной статье был произведен анализ и сравнение методологий разработки трейдинговой платформы на разных уровнях проектирования: фреймворков, моделей ЖЦ, архитектурных стилей, корпоративной архитектуры, архитектуры программы. В ходе написания была выбрана и обоснована микросервисная архитектура с сочетанием принципа чистой архитектуры.
Список литературы /References
4.
Рудаков А.В. Технологии разработки программных продуктов: учеб. пособие для студ. сред. проф. образования // М.: Издательский центр «Академия», 2006. 208 с. Richards Mark. Architecture Patterns // O'Reilly Media, 2015. P. 55. Архитектура информационных систем // Фреймворк Захмана. [Электронный ресурс], 2020. Режим доступа: https://studme.org/282509/informatika/freymvorki/ (дата обращения 11.05.2020).
Архитектура информационных систем // Архитектурный фреймворк TOGAF. [Электронный ресурс], 2020. Режим доступа:
https://studme.Org/138731/ekonomika/arhitekturnyy_freymvork_togaf#410/ (дата
обращения 11.05.2020)
Википедия - свободна энциклопедия // Dodaf. [Электронный ресурс], 2020. Режим доступа: https://ru.wikipedia.org/wiki/DoDAF/ (дата обращения: 11.05.2020).
6. A Common Perspective on Enterprise Architecture Developed and Endorsed by The Federation of Enterprise Architecture Professional Organizations. [Электронный ресурс], 2020. Режим доступа: https://feapo.org/wp-content/uploads/2018/10/Common-Perspectives-on-Enterprise Architecture-Final-1-copy.pdf/ дата обращения: 01.06.2020).
7. Общая схема архитектурного процесса // Описание модели Gartner. [Электронный ресурс], 2020. Режим доступа: https://studfile.net/preview/5611891/page:13/ (дата обращения: 11.05.2020).
8. Мартин Р. Чистая архитектура. Искусство разработки программного обеспечения // СПб.: Питер, 2018. 352 с.
ОБЗОР ФИЗИКО-МЕХАНИЧЕСКИХ СВОЙСТВ ЛЬДА Коновалов С.В. Email: Konovalov689@scientifictext.ru
Коновалов Сергей Вадимович - магистрант, кафедра гидротехники, теории зданий и сооружений, Инженерная школа Дальневосточный федеральный университет, г. Владивосток
Аннотация: в данной статье проведен обзор физико-механических свойств льда. Здесь было установлено, что прочность на изгиб колеблется в значениях от 0,7 до 3,1 МПа, а прочность на сжатие варьируется в диапазоне 5-25 МПа, в зависимости от температуры (от -10оС до - 20оС). Прочность на сжатие находится в обратной зависимости от температуры окружающей среды и скорости приложения нагрузки. Прочность на растяжение уменьшается с увеличением размеров зерен льда. Вязкостное разрушение находится в диапазоне 50-150 кПа м1/2.
Ключевые слова: физико-механические свойства льда, лёд, обзор, прочность на сжатие, прочность на растяжение, вязкостная прочность, термическое разрушение, структура льда, зависимость параметров льда.
OVERVIEW OF THE PHYSICAL AND MECHANICAL PROPERTIES OF ICE Konovalov S.V.
Konovalov Sergey Vadimovich - Undergraduate, DEPARTMENT OF HYDROTECHNICS, THEORY OF BUILDINGS AND STRUCTURES,
SCHOOL OF ENGINEERING FAR EASTERN FEDERAL UNIVERSITY, VLADIVOSTOK
Abstract: this article reviews the physical and mechanical properties of ice. It was found here that the compressive strength varies in the range of values from 0.7 to 3.1 MPa, and the compressive strength varies in the range of 5-25 MPa, depending on temperature (from -10°С to - 20°С). Depending on temperature and load application speed. Tensile strength decreases with increasing grain sizes of ice. Viscous fracture is in the range of50-150 kPa m112. Keywords: physico-mechanical properties of ice, ice, review, compressive strength, tensile strength, viscosity strength, thermal fracture, ice structure, ice parameter dependence.
УДК 551.467
Введение:
Физико-механические свойства льда играют важнейшую роль в различных отраслях. Благодаря им можно находить требуемую прочность для гидротехнических
