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

Интерфейс AntConc схож по внешнему виду с интерфейсом GATE Developer (см. рисунок 1.2). В отличие от GATE, где количество корпусов произвольно, здесь корпус один и фиксированный. Здесь так же есть центральное текстовое поле для отображения аннотированного текста.

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

Далее будут рассмотрены несколько подходов к хранению данных корпусов текстов, и будет принят выбор в сторону оптимального. У каждого подхода будут освещены достоинства и недостатки.

Первым и самым очевидным способом хранения информации является использование дискового хранилища. Основным объектом анализа на портале будут загружаемые пользователями документы Project Proposal на английском языке, в среднем объем которых составляет 20 МиБ. Такой объем делает хранение полного текста в классической базе данных затруднительным, в то время как данный подход позволяет хранить файлы настолько большие, насколько это позволяет файловая система.

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

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

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

Новейшие базы данных, такие как MongoDB, соревнуются в скорости с традиционными реляционными БД, а также позволяют хранить крупное содержимое прямо в записях. Записи в MongoDB можно расширять динамически - здесь нет фиксированной табличной структуры, как в реляционных БД. Согласно документации MongoDB [4], максимальный размер документа, который можно сохранить напрямую в БД, составляет 16 МиБ, что достаточно для разрабатываемого портала, так как по сравнению с этой цифрой, размеры обрабатываемых текстов на порядки меньше.

В случае, если документы становятся больше 16 МиБ, MongoDB позволяет использовать встроенную файловую систему GridFS для хранения таких документов, что потребует использования APIдля их получения. MongoDB не поддерживает многопоточный доступ в отличие от SQL баз данных.

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

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

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

Обзор литературы был проведен с целью сбора информации, имеющейся в области исследований. Данный проект является частью текущего исследования, проводимого совместно с Высшей школой экономики. С предыдущих лет остались как программные наработки, так и публикации. В частности, в материалах конференции [5] подробно обсуждается развитие аналитической системы, представлены различные детали методологии оценки текста, а также некоторые функции, которые система должна выполнять. Программное обеспечение, описанное в публикации, использует маркеры академического жанра, разработанные для библиотеки GATE ранее, в качестве основного средства анализа текста. В данном проекте при разработке приложения будет использоваться библиотека GATE с теми же маркерами.

В источнике [6] утверждается, что уровень владения студентами письменностью и связанными с ней навыками обычно уступает другим коммуникативным задачам. В частности, это связано с методикой обучения, которая фокусируется на аудировании, разговорной речи, грамматике и т. д., в то время как навыки письма часто рассматриваются как дополнительные. Автор описывает несколько подходов к обучению и в заключение предлагает комбинированную методику, которая, как утверждается в тексте, работает лучше. Первый из представленных здесь подходов - продуктовый подход (англ. Productapproach), который предполагает, что для написания текста обучающемуся следует знать некоторое количество шаблонов, следуя которым он сможет произвести текст. Автор утверждает, что эффективность такого метода сомнительна, и обучающиеся способны создавать качественные тексты только при изучении большого количества текстов, написанных носителями языка. Следующий - процессный подход (англ. Processapproach), который концентрируется на том, как пишется текст, а не на конечном результате. Применяя такой подход, обучающийся оперирует не шаблонами, а определенными активностями, которые он чередует, чтобы на выходе получился текст. Далее автор описывает жанровый подход (англ. Genreapproach), который схож с продуктовым подходом, но больше акцентирует внимание на социальном контексте написанного. Наконец, в статье предлагается гибридный подход (англ. Product-Genrebasedapproach), который объединяет процессный и жанровый подходы. Такой способ мышления может помочь избавиться от часто повторяющихся шаблонов, которые встречаются в продуктовом подходе, и в то же время создать естественный поток для письма студента.

Исследование, проведённое в [7], направлено на изучение трудностей, возникающих при написании академического текста на английском в восприятии иностранных студентов. Автор провел исследование с помощью опросников в одном из университетов Австралии. Оказалось, что многие испытуемые указали одинаковые сложности, учитывая то, что история их обучения английскому была различной. Среди трудностей были названы использование лексики, согласованность, связность, выбор подходящих источников. Наименьшей проблемой, как сообщалось, были перефразировка, ссылка и цитирование. Так как данная публикация указывает на проблемные точки при написании академических текстов, при разработке программной системы особое внимание будет уделяться вышеуказанным сложностям.

В работе [8] основное внимание уделяется выявлению жанровых сигналов в академической письменной форме. Жанровые сигналы - характерные шаблоны, появляющиеся в текстах определенного жанра. Это исследование особенно важно, так как его цель напрямую связана с задачей текущего исследования. Утверждается, что в академическом тексте имеются распознаваемые закономерности, которые в зависимости от автора могут быть сформулированы разными словами, но иметь в основе одну структуру. В то же время у каждого автора есть свой узнаваемый и уникальный стиль, который идентифицирует автора вне зависимости от жанровых сигналов. В приложении возможно применение такого подхода для улучшения качества выдаваемых рекомендаций.

В исследовании [9] проводится различие между носителями языка ииностранцами. Проведенный здесь анализ показывает, что люди, не являющиеся носителями языка, как правило, создают более длинные и синтаксически более сложные предложения по сравнению с носителями. Автор связывает такое различие с попыткой иностранцев донести свое сообщение точнее, вследствие чего ему потребуется писать более специфично и многословно. Напротив, носители языка чаще используют идиомы и менее специфичные конструкции, что приводит к более кратким предложениям. С помощью данной публикации можно улучшить рекомендации, сравнивая конструкции, написанные пользователем, с конструкциями носителей языка.

Использование идиом в академическом контексте широко обсуждается в [10]. Считается, что идиомы, будучи несколько неточными, редко встречаются в академической письменности. Однако исследование показывает, что идиомы довольно распространены, особенно непрозрачные и не имеющие возможности быть двояко интерпретированными. Данное исследование может служить источником для выработки рекомендаций о том, какие идиомы и как их использовать. Также программа сможет посоветовать пользователю, какую конструкцию можно сократить к более краткой форме с помощью идиомы.

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

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

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

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

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

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

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

Задачи по проектированию будут осуществлены в Visio [13]. Это программное обеспечение может создавать различные диаграммы на протяжении всего цикла разработки, в то время как его близкие аналоги, как правило, подходят лишь для конкретных этапов процесса, не охватывая весь цикл. программный контроллер серверный

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

Для разработки будет использоваться Intelli JIDEA [14]. Данная IDEв наибольшей степени подходит для разработки на Java, а также для развертывания и тестирования ПО. Используемый язык программирования -Java - на данный момент считается одним из основополагающих языков для разработки Enterprise-приложений: помимо множества сторонних библиотек, он использует широкие возможности встроенного инструментария, которые позволяют разрабатывать сложные программы, не прибегая к сторонним решениям.

В качестве фреймворка для разработки серверной части портала был выбран Spring Boot [15], так как он позволяет быстро создать приложение с минимумом конфигурационного кода, а также имеет мощные и выразительные инструменты для разработки MVCприложений. Внутри Spring Boot будет использоваться обработчик шаблонов Thymeleaf [16], который является одним из самых мощных для Java.

Для создания клиентской части портала будет использоваться HTML5 (с дополнительными атрибутами от Thymeleaf), CSS4 и Java Script нового стандарта ECMAScript-262 [17] без фреймворков для облегчения файлов клиентской части и для увеличения производительности

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

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

Наконец, ожидается, что проект будет иметь письменную документацию, которая является либо описанием для конкретно взятой диаграммы, либо самостоятельным документом. Документы этапа анализа предметной области подробно описывают функции и примеры использования, чтобы сделать их более понятными и точными. Будут также созданы документы, в которых указываются некоторые нюансы проектирования, не заданные диаграммами, документы этапа реализации, в которых подробно описывается процесс разработки. Кроме того, ожидается, что проект будет иметь Руководство пользователя и Справочник API.

Далее к разрабатываемому приложению будут выдвинуты требования (см. рисунок 1.3). Система должна быть оформлена в виде микросервиса и являться порталом, а также иметь три уровня иерархии пользователей: администратор, пользователь и неавторизованный посетитель. Основные прецеденты, с которыми будет работать система:

1. Регистрация пользователя позволяет посетителю портала стать пользователем системы с приобретением всех преимуществ последнего.

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

3. Просмотр публичных корпусов доступен всем посетителям, а также внешним сервисам посредством API. Одним из таких сервисов станет сервис визуализации статистики.

4. Редактирование общих корпусов (здесь и далее для краткости «редактирование» включает в себя создание, просмотр, обновление и удаление, если не обговорено иное) доступно, начиная с уровня «пользователь». Таким образом, анонимному посетителю понадобится авторизоваться, чтобы редактировать корпуса.

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

6. Редактирование всех корпусов доступно только администраторам портала, так как это действие потенциально опасно в руках злоумышленников.

7. Просмотр статистики по корпусу доступен администраторам и внешним сервисам посредством API. Скорее всего, обычным пользователям статистика не пригодится. В то же время было принято решение создать открытый API для этого прецедента, так как в рамках НУЛ будет разработан сервис по визуализации статистики.

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

Рисунок 1.3 - Диаграмма прецедентов для портала