Разработка подсистемы модулей расширения системы лингвистических исследований

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждения высшего образования «Национальный исследовательский университет «Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

Разработка подсистемы модулей расширения системы лингвистических исследований

Иванов Михаил Викторович

Пермь, 2020 год



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

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

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

По этим причинам появилась задача создания объединяющей системы для набора модулей системы лингвистических исследований, которая бы выполняла такие задачи, как: наличие веб-интерфейса, организующего доступ ко всем модулям системы из одного места; обмен информацией между модулями; интерфейс (API) для добавления новых модулей в систему.

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

Для достижения этой цели необходимо выполнить следующие задачи:

Провести анализ предметной области:

Анализ технологий и паттернов интеграции систем на различных языках.

Выбор лучшей методологии/концепции для интеграции.

Сформировать требования к системе.

Выбрать инструменты разработки (библиотеки и фреймворки) для Python, Java, C#, JavaScript.

Провести проектирование алгоритмов системы и её интерфейса.

Разработать API для добавления новых модулей.

Для разработки системы используются фреймворк для создания веб-приложений Flask, универсальный Java-фреймворк Spring и платформа для разработки веб-приложений ASP.NET.

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

Анализ предметной области

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

Состав системы лингвистических исследований

Система лингвистических исследований, для которой необходимо создать общий интерфейс и возможность обмена информацией между её частями, состоит из нескольких модулей (Рисунок 1.1).

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

Рисунок 1.1 - Состав системы лингвистических исследований

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

Обзор способов интеграции и коммуникации между языками программирования

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

Интеграция языков программирования как концепт не является новшеством - напротив, она всегда используется при разработке мультиязычных систем. Кроме того, некоторые языки программирования могут быть вызванными из других. Основными примерами такого подхода являются языки для управления данными SQL и его различные диалекты, которые вызываются из почти любого известного языка программирования, не требуя при этом наличия дополнительных инструментов.

Некоторые языки программирования, такие как Python, Lua, JavaScript достаточно просто интегрировать с другими, так как они являются сценарными языками и специально предназначены для интеграции в системы, состоящие из разнородных компонентов. Однако, в системе лингвистических исследований имеются модули, написанные на не сценарных языках, поэтому для интеграции с ними необходимо рассмотреть другие подходы.

Одним из подходов является использование платформ для интеграции. В качестве платформ используются виртуальные машины, например, Java Virtual Machine (JVM), с помощью которой достигается интеграция таких языков как Java, Kotlin и Scala. Microsoft имеет свою альтернативу - Common Language Runtime (CLR) которая интегрирует C#, F# и Visual Basic[1]. Но компонента, который бы интегрировал C# и Java, не существует, несмотря на внешнюю схожесть программного кода.

Ещё одним подходом является интеграция с помощью повторной реализации. Под повторной реализацией подразумевается добавление возможности интегрировать язык изначально, ещё на стадии проектирования языка, как это сделано в случае со сценарными языками программирования. Иначе добавление возможности интеграции развивающихся языков программирования является крайне сложной задачей, как в реализации, так и в поддержке, так как языки постоянно обрастают новыми возможностями, которые необходимо также настраивать для интеграции. Существует большое количество проектов, обеспечивающих интерпретацию кода с одного языка на другой[2, 3, 4]. Часть проектов весьма успешно развивается, например, CPython[5] (интерпретатор с Python на C), PyPy[6] (компилятор языка Python, обеспечивающий быстрое выполнение кода Python). Однако, такие проекты, как IronPython[7] и Jython[8], которые помогают исполнять программный код на языке Python в ранее упомянутых CLR и JVM соответственно; стали устаревшими, так как разработаны для Python 2.7, который считается официально устаревшим с апреля 2020[9]. Тем самым, язык перестал поддерживаться и проекты сразу же потеряли актуальность - в этом и заключается невыгодность таких проектов. Но несмотря на эту сложность, повторная реализация активно используется, так как она необходима для работы многих мультиязычных систем. Но для постоянной работы написанных программ требуется поддержка получившейся реализации по мере совершенствования и обновления языка.

Python вообще очень хорошо интегрирован с языком C. Самый распространённый интерпретатор Python, упомянутый ранее CPython, написан на C. Также на C написаны многие популярные и быстродействующие библиотеки для Python, к примеру Numpy - популярная библиотека для работы с операциями линейной алгебры (и не только) частично реализована на C, так как C более быстрый и оптимизированный чем Python.

Что касается языка Java, то с помощью технологии, называемой Java Native Interface[10], можно вызвать код написанный на C++, и наоборот. Основная проблема с этой технологией состоит в том, что она не позволяет полномасштабно интегрировать JVM и CLR, что не позволяет использовать её для в целях данной работы, так как C++ не является языком, который требуется использовать.

Ещё для интеграции языков программирования возможно использование веб-технологий для отправления данных из одной программы на одном языке в другую программу на другом языке. Такой способ интеграции используется уже много лет, и называется Web API[11]. В них активно используются сетевые протоколы и межпроцессная коммуникация. Сетевые протоколы используются для обмена информацией между несколькими устройствами в сети, а межпроцессная коммуникация используется для обмена информацией между процессами на одном устройстве. Эти подходы в основном созданы для обмена информацией, а не для интеграции. При разработке веб-систем сетевые протоколы применяются при обмене информацией между сервером и клиентом, а межпроцессная коммуникация в работе сервера или клиента в зависимости от их архитектуры. Поэтому их использование необходимо для функционирования клиент-серверных веб-систем.

Но почти каждое взаимодействие с интернетом включает в себя дополнительный шаг - конвертация объекта из внутреннего представления в JSON - JavaScript Object Notation. Такая запись объектов очень распространена, и большинство языков имеют способ конвертировать JSON в обычный объект. Но зачастую конвертация туда и обратно является долгой и относительно сложной операцией, поэтому не стоит делать её слишком часто.

Кроме конвертации объектов также необходимо вызывать необходимые для работы программы функции. Поэтому для каждого языка должен быть запущен веб-сервер, который будет ждать отправляемых на него запросов, выполнять запрошенные действия и отправлять ответы на эти запросы. Несмотря на большое количество конвертаций, которые должны произойти, этот способ является более простым в реализации, чем передача тех же объектов через командную строку. Ещё одним большим плюсом является то, что веб-сервер, при правильной настройке, может быть доступен по сети, что превращает его в микросервис.

Микросервисная архитектура - это способ организации распределённой системы на основе микросервисов и их взаимодействия друг с другом при помощи сетевых протоколов и принципов, направляющих проектирование, создание и развитие архитектуры. В отличии от цельного приложения, микросервис обладает несколькими преимуществами: модули являются независимыми приложениями, поэтому ошибки и сбои в одном (речь не идёт об обмене информацией между модулями!) зачастую никак не влияют на другие модули, разве что на работоспособность системы в целом; каждый микросервис ориентирован на выполнение одной основной функции или ряда взаимосвязанных функций; каждый модуль может быть реализован с помощью разных языков программирования и стека технологий (увеличивает эффективность каждого модуля, при этом не в ущерб другим модулям). Философия микросервисов следует философии Unix - набору культурных норм и философских подходов к разработке программного обеспечения - которая сводится к тому, что программы должны делать что-то одно и делать это хорошо.

Выполнение микросервисов осуществляется как простой реализацией систем для их объединения, так и при помощи специальных систем управления контейнеризованными приложениями, такими как Kubernetes[12] и её надстройками OpenShift и CloudFoundry, Docker Swarm, Apache Mesos. В таких системах каждый микросервис находится в отдельном «контейнере», который управляется специальными средами оркестрации, которые обрабатывают возникающие ошибки и балансируют нагрузку.

Как и любая архитектура, микросервисы имеют свои недостатки. Среди них наиболее сильное значение имеют сетевые задержки, из-за которых выполнение программ, в которых необходим обмен информацией по сети, сильно замедляется. Такие системы могут иметь большое количество ошибок в процессе коммуникации, так как нет единого способа передачи информации для всех возможных пар микросервисов (зависит от используемого в них языка программирования и стека технологий). Кроме того, очевидным больным местом является балансировка нагрузки. Однако для данной работы такие сложности не настолько критичны, так как обмен информацией происходит только между несколькими подсистемами и обеспечивается при помощи JSON-объектов, которые можно стандартизировать.

Кроме JSON-объектов ещё одним способом достижения интеграции может служить общий для нескольких программ файл, за изменениями в котором наблюдают все модули, которым он необходим. В таком случае при изменении файла программы будут читать информацию из этого файла и выполнять какие-либо действия в зависимости от этой информации. Такое решение требует уведомлений от файловой системы, или постоянной проверки атрибутов файла. При использовании такого способа необходимо учитывать, что несколько модулей могут одновременно запросить доступ к файлу, что может привести к ошибкам в работе, поэтому необходимо обеспечивать предотвращение и обработку соответствующих ошибок. Этот способ менее ресурсозатратен, чем микросервис, который требует гораздо больше вычислительной мощности, но конвертации объектов будут присутствовать в обоих решениях, что весьма влияет на скорость работы.

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

Формирование требований к системе

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

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

Система должна использоваться в интернет браузерах на компьютерах с операционными системами Windows 7/8/10, MacOS и Unix-подобных систем (их версиях с графическим интерфейсом пользователя).

Система должна быть разработана на языках программирования C#, Python, Java. Система должна иметь возможность работать по сети. Входные данные в системе - модули системы лингвистических исследований (через их API). API модулей должны поддерживать архитектурный стиль REST. Требования к выходным данным отсутствуют, так как подсистема отвечает не за генерацию или обработку данных, а за их передачу. Подсистема должна иметь возможность работать по сети.

Более подробно все требования изложены в Техническом задании, которое находится в приложении Приложение А. Для приема работы разработан документ Программа и методика испытаний, который находится в приложении

Выбор инструментов разработки

В этой главе будет представлено сравнение нескольких популярных фреймворков для разработки Web API в таких языках программирования, как Python, Java и C#, и для разработки интерфейса веб-приложения на JavaScript. Для каждого языка будет выбран оптимальный инструмент для выполнения разработки системы модулей расширения.

Инструменты для Python

Наиболее популярными фреймворками для Python на данный момент являются такие фреймворки как Django[13], Flask[14], AioHTTP[15], Sanic[16], Tornado[17] и Vibora[18]. О них и пойдёт речь в данном пункте обзора.

Первый из фреймворков, Django, в качестве шаблона проектирования использует MVC. Одной из его отличительных особенностей является то, что обработчики URL в нем конфигурируются явно при помощи регулярных выражений. Для работы с базами данных используется собственный ORM (Object-Relational Mapping - технология программирования, которая позволяет связать базу данных с языком программирования, создавая «виртуальную объектную базу данных». Это нужно для преобразования таблиц данных в классы и наоборот.). Этот фреймворк используется на многих известных сайтах, таких как Instagram, YouTube, Google, Mozilla и многих других. Данный фреймворк разрабатывался в основном как средство работы новостных ресурсов, поэтому в нем есть встроенные инструменты для управления содержимым страницы, что облегчает процесс разработки.

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

Второй фреймворк - Flask[19, 20] - это микро-фреймворк для создания вебсайтов. «Микро» обозначает не только простоту использования и небольшой размер, а ограниченное количество проектных решений. Он предоставляет самые базовые возможности для обеспечения безопасности, простоты и быстроты разработки. Тем не менее, в нем достаточно инструментов для разработки небольших веб-приложений. Он не имеет большого количества конфигурационных файлов для работы, как Django, а для его запуска не требуются специальные команды. Это значительно упрощает работу с ним, как и то, что для работы приложения требуется добавить в скрипт одну строчку - создание объекта Flask, и запустить этот файл как любой другой файл Python.

Если необходимо производить какие-либо сложные вычисления, то наилучшим выбором будут являться асинхронные фреймворки, такие как AioHTTP. В таких фреймворках поток, проводящий вычисления, распараллеливается, что значительно ускоряет обработку данных. Этот фреймворк примечателен тем, что он обладает удобными асинхронными запросами с клиента, а также содержит реализацию веб-сервера. Для работы в нем активно используются web-сокеты (WebSocket - протокол, основанный на TCP, который позволяет осуществлять взаимодействие между браузером и сайтом, использующийся для создания real-time приложений и обработки интерактивного содержимого). Такие фреймворки требуют знаний асинхронного программирования.

Следующие фреймворки в этом обзоре - Sanic и Tornado, также использующие асинхронное программирование. Как и AioHTTP, имеют веб-сервер и веб-фреймворк, однако эти фреймворки имеют куда большую скорость. Для ускорения работы Sanic может использовать uvloop и ujson - библиотеки для реализации цикла событий (обработка и ответ на приходящие запросы). Tornado же гораздо «старее» (был разработан ещё в 2010 году), однако до сих пор довольно успешно развивается, но имеет высокий порог вхождения. Такие фреймворки используются не столько в определенных типах проектов, сколько при необходимости равномерно распределить нагрузку на сервер в случае большого потока запросов. К примеру, такие фреймворки используются на популярном сайте объявлений Avito, где также используется микросервисная архитектура - около 20 микросервисов было разработано к 2019 году.

Последним фреймворком в этом обзоре будет Vibora - асинхронный клиент-серверный фреймворк. Он был разработан не так давно, в 2018 году, и на данный момент позиционирует себя как самый быстрый фреймворк среди себе подобных. Этот фреймворк объединяет множество библиотек и шаблонов, однако пока что он подвергается значительным изменением и пользоваться им пока-что нельзя.

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

Инструменты для Java

Для языка Java существует огромное множество фреймворков, рассмотреть все из них попросту невозможно. Поэтому для обзора были выбраны такие фреймворки как Spring[21], Google Web Toolkit[22] и Vaadin[23].

Фреймворк Spring - самый популярный Java фреймворк, который имеет открытый исходный код. Он позволяет решать множество задач, связанных с созданием информационных систем, так как обладает очень большими возможностями. Иногда его рассматривают как коллекция «фреймворков в фреймворке», которые могут использоваться как отдельно, так и совместно. Такие мини-фреймворки группируются по таким функциональным задачам, как конфигурирование и управление жизненным циклом объектов; доступ к реляционным базам данных; управление транзакциями; реализация шаблона MVC; передача данных через удалённый доступ; аутентификация и авторизация; удалённое управление; работа с сообщениями из очереди сообщений; тестирование. «Ядром» фреймворка является контейнер Inversion of Control, позволяющий при помощи рефлексии конфигурировать и управлять объектами Java. Он управляет жизненным циклом специальных управляемых объектов beans - позволяет создавать, инициализировать и конфигурировать их путём связывания между собой.

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

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

Фреймворк Google Web Toolkit (GWT), в отличие от других фреймворков, в своей работе позволяет большинство кода разработки писать на Java и только самый минимум реализовывать на JavaScript, HTML и CSS. Он позволяет создавать Ajax-приложения. Подход Ajax основывается на таком способе реализации интерфейсов веб-приложений, в которых браузер обменивается данными с веб-сервисом в фоновом режиме. Это означает, что веб-страница при обновлении сохраняет часть контента, отчего перезагрузка значительно ускоряется. В отличие от стандартных моделей работы веб-приложений, в которых сервер в ответ на запрос браузера генерирует новую веб-страницу, при Ajax-подходе специальные скрипты определяют, какие элементы страницы нуждаются в обновлении и в ответ на запрос браузера вносят соответствующие изменения в код страницы, от чего странице не требуется полная перезагрузка. Этот фреймворк имеет большой перечень особенностей, среди которых, кроме вышеперечисленных, есть также такие как удалённый вызов процедур - сервер в ответ на запрос передаёт сразу данные, а не HTML. Этот фреймворк используется для различных проектов, но наибольшей популярности достиг в сложных клиентских приложениях, в частности, в банковской сфере. Для данной задачи он не совсем подходит, так как необходимо реализовать не полноценное веб-приложение, а API для объединения существующих, отчего использование такой технологии будет излишним.

Последний фреймворк в этом обзоре - Vaadin, который предлагает сервер-ориентированную архитектуру, базирующуюся на Java Enterprise Edition. Приложения, использующие этот фреймворк, основную часть логики выполняют на сервере, а на стороне клиента используют Ajax, взаимодействуя с GWT. Этот фреймворк используется при разработке приложений, которые должны отображать в браузере большие объёмы данных. Использование организации событийной модели данных и виджетов позволяет значительно облегчить использование оперативной памяти, при этом делает это автоматически, без дополнительных действий программистов. Vaadin ориентирован именно на серверную часть приложения, поэтому взаимодействует с GWT, который ориентирован на клиентскую. Опять же, использование Vaadin будет излишним, так как реализовывать серверную часть нет необходимости. Несмотря на это, рассмотренные фреймворки можно было бы использовать, однако так как уже имеется опыт работы с фреймворком Spring, будет выбран именно он для реализации поставленной задачи.

Инструменты для C#

Программа на C# будет реализована при помощи ASP.NET, так как это единственный фреймворк, позволяющий реализовывать веб-приложения с использованием этого языка. Этот фреймворк самый распространённый для C#, так как он встроен в .NET Framework, включает в себя большое количество библиотек, которые можно использовать при разработке. Также он очень хорошо интегрирован с остальными библиотеками, входящими в .NET: при разработке приложений с помощью ASP.NET программист использует классы и методы, похожие на те, что используются в остальных библиотеках .NET.

Инструменты для Web программирования

В этом пункте будет проведён краткий обзор фреймворков для реализации общего интерфейса модулей и будет произведён выбор наиболее подходящего для поставленной задачи. Здесь будут рассмотрены такие фреймворки, как React[24], Angular[25], Ember.js[26], JQuery[27] и Ext JS[28].

React - библиотека для JavaScript, ведущая себя как фреймворк. Разработана и поддерживается компанией Facebook. Может использоваться для разработки как веб-приложений, так и мобильных приложений. Вместе с этой библиотекой используются такие библиотеки, как Redux, осуществляющая управление приложением, и GraphQL, языком и средой для выполнения запросов. При разработке используется модификация JSX - расширение JavaScript, позволяющая вписывать HTML-код, не превращая его в строку. Этот фреймворк предоставляет высокий уровень гибкости при разработке. Особенностью этого фреймворка является однонаправленная передача данных, при которой свойства передаются от родительских компонентов к дочерним. При этом компоненты получают свойства как множество неизменяемых значений. Это означает, что компонент сможет изменять свойства не напрямую, а только через механизм обратного вызова (callback).

Angular - фреймворк для TypeScript - языка программирования, расширяющего возможности JavaScript. Этот язык - модификация, добавляющая ограничения, связанные с типами, ко всем переменным в JavaScript. Эти ограничения, присутствующие в некоторых других языках, позволяют ускорить работу программ, написанных на TypeScript по сравнению с теми же программами на JavaScript. Этот фреймворк использует Data Binding - привязывание данных. Это обеспечивает автоматическое обновление данных на странице при их изменении в коде, что позволяет избежать некоторых ошибок, которые могут возникнуть в связи с состоянием элементов. Кроме того, Angular придерживается шаблона MVC.

Ember.js - фреймворк для разработки Web-приложений на JavaScript. Его главное преимущество - использование синтаксиса шаблонов Handlebars для генерации HTML. Это позволяет не перемешивать код с разметкой, как это делается в React и Angular, что помогает гораздо лучше мысленно их разделить. Кроме шаблонов, основными принципами фреймворка являются маршруты (URL-адреса, которые определяют состояние веб-приложения), модели (соответствующие маршруту модели с данными о состоянии) и контроллеры (логика отображения модели). Основной минус этого фреймворка в том, что нет хорошего способа создавать и получать пользовательские события из компонентов.

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

Ext JS - фреймворк для JavaScript. Изначально этот фреймворк разрабатывался как расширенная версия Yahoo! UI Library - библиотеки с большим количеством интерактивных компонентов страниц (различные слайдеры, деревья, календари и проч.). Но так как его возможности превысили запланированные, он очень быстро был преобразован в отдельный фреймворк. В своих начальных версиях использовал адаптеры, преобразовывающие данные из одного формата в другой, для доступа к библиотекам Yahoo! UI Library, jQuery и другим, но затем они были убраны за ненадобностью. Поддерживает технологию AJAX, анимацию, работу с DOM, реализацию таблиц, вкладок, обработку событий и все остальные возможности Web 2.0.

Основное его достоинство состоит в том, что большое количество компонентов уже написано и готово к использованию. Эти компоненты предоставляют большие возможности для их кастомизации. Основной недостаток этого фреймворка - невозможность создания собственных компонентов с нуля. В нем объявляются новые свойства для существующих компонентов, что превращает фреймворк в один большой конструктор, в котором возможна только настройка предустановленных свойств. Зачастую это вызывает проблемы при разработке компонентов, ранее нигде не реализованных. Для данной задачи можно воспользоваться любым из рассмотренных фреймворков, однако, предпочтение будет отдано Angular, по причине того, что TypeScript является весьма интересным языком для разработки и хотелось бы изучить его возможности.

Проектирование подсистемы модулей расширения

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

Проектирование API

API будет использован программистами для регистрации плагина, а также для коммуникации между плагинами. Этот API будет состоять из двух частей: регистрационная и связывающая. Регистрационная часть отвечает за добавление модулей и регистрации их как в веб-интерфейсе, так и для проверки правильности вызванного модуля. В связи с наличием этих функций будет создано два отдельных класса для регистрации и вызова функций объектов.

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

Основная цель класса связи состоит в том, чтобы конвертировать данные, переданные в функцию в JSON, передавать их и ждать ответа. Этот класс будет вызывать функции, определённые регистратором, и возвращать значения - результаты выполнения этих функций. Также будет актуализировано состояние объекта, чьи функции были вызваны - в том случае, если оно было изменено после выполнения функции.

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

В таком случае в качестве API выступают два класса, структура которых изображена на рисунках Рисунок 3.1 и Рисунок 3.2

Рисунок 3.1 - Схема класса Registrator

Рисунок 3.2 - Схема класса RemoteObject

В качестве обработчика (параметр handler функции addFunction класса Registrator) тогда выступает регистрируемая функция. Удаление должно иметь возможность производиться как по функции, так и по названию (параметр name функции addFunction класса Registrator).

Проектирование Web-API

Web-API будет использован для передачи данных между языками. Это будет использоваться для работы функций API, так как метод интеграции с помощью микросевисов основан на передаче данных. Передаваться должны не только имя функции и её аргументы - если были проведены изменения объекта, то необходимо выполнять функции с последними значениями, так как результаты выполнения функции могут зависеть от всех значений. Также такое обновление производится после выполнения функции, перед отправлением ответа, так как функции могут менять значения полей объектов.

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

Отсылать прямо на IP-адрес JSON со всеми данными: тогда все данные необходимо доставать из пришедшего словаря. В таком случае, как было сказано выше, необходимо конвертировать объект из JSON.

Отсылать данные через адресную строку: в таком случае можно вложить в адресную строку сколько угодно данных. Главная проблема этого подхода состоит в том, что вложенные массивы и объекты передавать через адресную строку не всегда самая лучшая идея - конвертация из этого формата может быть ещё более сложной и ресурсозатратной чем конвертация из JSON.

В итоге наилучшее решение лежит где-то посередине между этими двумя крайностями. Класс объекта и вызываемый метод могут составлять путь к обработчику этого метода, в таком случае в передаваемый объект должны быть включены такие вещи, как:

Идентификатор объекта.

Последняя версия объекта.

Аргументы вызываемого метода.

Аргументы передаются потому, что большинство методов требуют аргументов для работы. Причина передачи последней версии объекта была объяснена выше. Идентификатор объекта передаётся для того, чтобы отличать объекты друг от друга и не перезаписывать данные. Если иметь один объект на всех клиентов рано или поздно возникнут ошибки. Поэтому все объекты будут храниться в словаре, соотносящем индикатор с самим объектом. Чтобы не переполнять память старыми объектами необходимо периодически удалять их.

Проектирование интерфейса

Интерфейс подсистемы, по выявленным ранее требованиям должен объединять все модули. Для того, чтобы модуль мог быть объединён он должен иметь интерфейс. Для этого в функции addModule класса Registrator есть параметр guiUrl - в него предполагается передавать URL, указывающий на веб-интерфейс. Подсистема соберёт эти ссылки, и веб-интерфейс при запросе получит к ним доступ, и они появятся в боковой панели. Макет интерфейса показан на рисунке Рисунок 3.3.

Рисунок 3.3 - Макет интерфейса подсистемы

Вкладки вверху будут показывать имена последних посещённых подсистем, полный список которых может быть просмотрен в боковой панели. Она должна иметь возможность быть скрытой и показанной обратно, так как боковая панель занимает много места по сравнению с панелью вкладок сверху. Для того, чтобы показывать веб-страницы и не мешать их функционалу используется элемент iframe, часто использующийся для виджетов соц. сетей и встраивания видео. Не любой сайт можно показать в iframe, некоторые сайты, к примеру Google, это запрещают. Поэтому для корректной работы встраивания необходима правильная конфигурация сайта, на который предоставляется ссылка.

Разработка подсистемы модулей расширения

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

Реализация Web API

Написанная система состоит из клиентской и серверной частей. Обе части необходимо написать на каждом из языков программирования, которые обсуждались ранее (Java, Python, C#), поэтому в следующих подглавах будет описан их разработки. Поскольку написанная подсистема будет служить для связи других подсистем системы лингвистических исследований между собой, то описанные далее библиотеки и модули будут использоваться при их создании. Для упрощения процесса получения и добавления написанных модулей и библиотек они могут быть загружены в соответствующие языку репозитории. Шаги, предшествующие загрузке библиотек в репозитории также будут описаны в дальнейших подглавах.

Для работы с Web-API, который был спроектирован ранее, были написаны функции, которые совершают следующие действия:

Создание, сохранение и отправление созданного объекта клиенту.

Приём объекта, выполнение необходимой функции, обновление сохранённого объекта, и отправление результата обратно.

Отправление объекта клиенту.

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

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

Реализация на Python

Основное отличие Python-модуля от Python-скрипта состоит в том, что в момент импорта модуль выполняет весь код, присутствующий в файле. Поэтому чтобы не создавать ненужные задержки в выполнении, модуль не должен выполнять большое количество кода, а это значит, что модуль должен состоять в основном из функций и классов, и даже загрузку других библиотек лучше переместить внутрь самих функций. Хорошие модули так же имеют детальную документацию, объясняющую что делает модуль, что делает класс и что делает каждая отдельная функция. Стандартная документация для Python делается при помощи добавления строки в начало функции, класса или файла. Параметры, передающиеся в функцию, описываются там же, с помощью конструкции, изображённой на рисунке Рисунок 4.1.



Рисунок 4.1 - Описание параметров, передаваемых в python функцию

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

Для языка Python основным репозиторием является PyPI, также известный как Python Package Index[29]. Для того чтобы загрузить в него модуль, необходимо иметь файлы Readme, License и setup.py. Readme обычно содержит примеры использования модуля, или основные классы, присутствующие в нём. License содержит информацию о лицензии, под которой распространяется код. Это влияет на возможность использования кода в коммерческих проектах. Setup.py обычно не пишут вручную - его чаще генерируют с помощью разнообразных орудий.

Что касается реализации модулей, то в них необходимо получать функцию как переменную, вызывать её с необходимыми аргументами, и периодически удалять объекты из списка. Для вызова функций, на которые хранящихся в переменной, можно вызвать эту переменную, как будто она является функцией. Благодаря разворачиванию листов в Python очень просто вызвать функцию со всеми её аргументами. Назначение действий на выполнение в определённое время имеется в стандартной библиотеке, эта часть решается при помощи класса scheduler из.

Web-API на Python реализовывался с помощью фреймворка Flask. Этот фреймворк, в отличие от остальных выбранных для других языков программирования, по умолчанию отправляет значение, переданное в качестве результата выполнения функции, что показано на рисунке Рисунок 4.2.

Рисунок 4.2 - Flask - метод, возвращающий строку

На этом рисунке также показано, каким образом обозначается путь. Это делается с помощью аннотации app.route, в которую передаётся сам путь. Для корректной работы выбранных запросов необходимо извлекать параметры из URL. Для этого нужно использовать конструкцию, аналогичную изображённой на рисунке Рисунок 4.3.

Рисунок 4.3 - Flask - метод с переменной username, находящейся в URL

Несмотря на это, для полноценной работы приложения как API необходимо возвращать не строку, а массив или словарь. Словарь во Flask автоматически конвертируется в формат JSON, а массив - нет. Для конвертации массива в JSON необходимо передать его в функцию Flask.jsonify. Также можно воспользоваться любым другим способом превращения объектов в JSON, доступным в Python.

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

Также для корректной работы было необходимо удостоверится в том, что функции без объектов добавляются корректно. Поэтому для сохранения спроектированного ранее Web API все функции, не находящиеся в классе, регистрируются как функции класса NoneType.

Для работы с серверной частью библиотеки необходимо сначала зарегистрировать функции, которые будут вызываться клиентом. Это делается с помощью функции register_method которая добавляет переданную в неё функцию и класс в словарь, из которого они берутся при запросе от клиента. Их можно удалить с помощью функции remove_method. Код обеих функций изображён на рисунке Рисунок 4.4.

Рисунок 4.4 - Функции register_method и remove_method

Запросы обрабатываются функциями new_instance и call_method, которые создают объект и вызывают функцию соответственно. Как уже было сказано выше, объекты, созданные клиентами, сохраняются на сервере. Для генерации идентификаторов используется стандартный генератор случайных чисел, генерирующий массив, после чего этот массив передаётся как данные для шифрования с помощью Base64 - способе кодирования данных, используемом для преобразования данных из бинарного формата в формат, который можно использовать для передачи данных в интернете. Его основное преимущество состоит в том, что является важным при некоторых способах передачи данных. Код функции изображён на рисунке Рисунок 4.5.

Рисунок 4.5 - Функция generate_id

Также присутствуют функции для добавления и удаления модулей - register_module и remove_module. В них имеется два разных списка: модули с графическим интерфейсом и без него. Оба вида можно зарегистрировать при помощи функции register_module и удалить при помощи remove_modules. Эти функции регистрируют URL, по которому находится модуль и интерфейс. Код этих функций изображён на рисунке Рисунок 4.6.

Рисунок 4.6 - Функции register_module и remove_module

Функция get_guis возвращает все зарегистрированные интерфейсы при запросе на /gui/here. Также можно получить все интерфейсы, зарегистрированные в известных модулях, с помощью запроса /gui/all. Код обеих функций изображён на рисунке Рисунок 4.7. Серверная часть библиотеки запускается с помощью функции run, которая в свою очередь запускает Flask приложение.

Для упрощения коммуникации клиента с сервером были написаны функции new_object и call_method, позволяющие отправить запрос по корректному пути на сервер и получить ответ более быстро и просто, чем вручную. Код этих функций представлен на рисунке Рисунок 4.8.

Рисунок 4.7 - Функции get_guis и get_all_guis

Рисунок 4.8 - Функции new_object и call_method



Таким образам был написан модуль, состоящий из клиентской и серверной части на языке Python. Далее будет описана реализация модуля на языке Java.

Реализация на Java

Документация кода в Java также имеет общепринятый формат, и он по большей части похож на комментарий. В отличие от комментария, который в Java помечается символом «*», документирование кода использует два символа «*». Документировать можно как отдельные функции, так и классы. Документирование позволяет программистам, которые будут добавлять модули в систему с помощью этой работы, быстрее разбираться с тем, каким образом происходит внедрение модулей.

Для обозначения аргументов функции используется текст @param, после которого следует имя параметра. Пример такого комментария представлен на рисунке Рисунок 4.9.

Рисунок 4.9 - Комментарий, описывающий функцию в Java

Для публикации в Maven[31] - основной репозиторий библиотек на Java - требуется один файл со всей информацией о библиотеке, а таже jar-файл, содержащий все классы библиотеки.

Функция, на которую имеется ссылка, в Java имеет тип Method и вызывается она с помощью метода invoke, в который передаются объект, и аргументы функции. Периодическое выполнение функций происходит с помощью объектов класса ScheduledExecutorService.

При реализации на языке Java использовался фреймворк Spring. Чтобы контроллер Spring отправлял JSON, ему требуется добавить аннотацию ResponseBody. Также её можно добавить к отдельным функциям. Конвертация приходящих запросов в JSON происходит автоматически. Конвертация ответов происходит автоматически, но только если указан их тип, поэтому была использована библиотека Gson для конвертации в Json случайных объектов.

Рисунок 4.10 - Spring - функция с параметром name

Web API был спроектирован ранее, поэтому как аргументы и пути, по которым программа должна отвечать, так и форматы ответов уже известны. Но из-за большого различия между языками будут рассмотрены основные проблемы, возникшие при разработке на Java.

Функция, изображённая на рисунке Рисунок 4.11 при отправлении запроса создаёт объект заданного типа, или получает запрошенный по идентификатору и отправляет его в качестве ответа. Для этого сначала проверяется наличие в пришедшем наборе значений идентификатора. Далее, при его наличии возвращается объект с соответствующим идентификатором. Иначе из запроса получаются аргументы и с их помощью создаётся и возвращается объект одного из зарегистрированных типов.

Рисунок 4.11 - Spring - функция, создающая объект



Вызов методов, изображённый на рисунке Рисунок 4.12, работает похожим образом - сначала определяется нужно ли получать объект из запроса или из словаря объектов. Далее производится поиск среди зарегистрированных методов, и если метод найден, то он вызывается и его результат отправляется. При ошибке отправляется ответ, содержащий сообщение об ошибке.

Рисунок 4.12 - Spring - функция, вызывающая метод

Регистратор, за исключением того, что он является классом, не отличается от своего аналога в Python и также имеет поля для хранения зарегистрированных методов, методы для регистрации и удаления методов и модулей. Единственная его особенность состоит в том, что он реализует паттерн Singleton. Для этого класс имеет статическую функцию getInstance, возвращающую единственный созданный объект этого класса.

Клиентская же часть этой библиотеки состоит из двух основных функций - New и Call, изображённых на рисунках Рисунок 4.13 и

Рисунок 4.14, и используемых для создания объекта и вызова метода соответственно.

Рисунок 4.13 - Клиентская функция New

Используемая в обеих функциях Http.postJson также не является стандартной, поскольку эта операция на языке Java содержит в себе достаточно кода для его обоснованного выделения в отдельную функцию. Эта функция показана на рисунке Рисунок 4.15.

Рисунок 4.14 - Клиентская функция Call

Рисунок 4.15 - Функция postJson

Эта функция ставит метод запроса, добавляет к нему несколько заголовков, и отправляет переданный в неё объект по указанному соединению. Таким образом была завершена разработка библиотеки на языке Java.

Реализация на C#

Для документации в C# используется xml-тэг summary, для документации переданных в функцию параметров используется следующий за ним тэг param с атрибутом name, значение которого соответствует имени параметра функции. Также, summary-комментарии отличаются от обычных тем, что начинаются не с двух слэш-символов, а с трёх. Пример такого комментария показан на рисунке Рисунок 4.16.

Рисунок 4.16 - Документирующий комментарий в C#

Чтобы опубликовать библиотеку в nuget - основной репозиторий для библиотек для .NET - необходимо кроме .dll-файла самой библиотеки иметь файл .nuspec[30], в котором даны имя, идентификатор, имя автора, ссылки на лицензию, и т. п. Также необходим файл Readme.

В C# для вызова функции, которая хранится в переменной необходимо применение рефлексии. Ссылка на функцию имеет тип MethodInfo, для вызова этой функции необходимо вызвать метод Invoke с объектом, чья функция вызывается, а также с необходимыми аргументами. Периодические действия выполняются при помощи класса Threading.Timer.

Для реализации на C# использовался ASP.NET. Для того, чтобы контроллер в этом фреймворке отправлял данные, а не веб-страницы его необходимо пометить как ApiController с помощью добавления одноимённой аннотации на класс, отвечающий за контроллер. Указание URL может быть произведено при помощи аннотации Route, в которую передаётся путь. Также при помощи этой функции можно обозначить параметры, передающиеся с помощью URL - такие параметры нужно поставить в фигурные скобки. Пример изображён на рисунке Рисунок 4.17.

Рисунок 4.17 - ASP.NET - метод с параметром page в URL

Реализованная библиотека состоит из трёх основных классов для серверной части и одного класса для клиента. Сервер состоит из двух контроллеров - MainApiController и GuiController. Они отвечают за создание и вызов объектов и за возвращение списка графических интерфейсов соответственно.

Поскольку C# статически типизирован, такие операции, как конвертация случайного JSON в объект, более сложны в выполнении, чем в Python. Для конвертации объектов использовался встроенный в ASP.NET конвертер, а также библиотека Newtonsoft.Json.

...