Исследование, проведённое в [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 - Диаграмма прецедентов для портала
Далее будут приведены требования к разрабатываемой системе с учетом анализа, проведенного ранее в этой главе. Подробно требования расписаны в техническом задании (см. Приложение А):
1. Разрабатываемая система должна быть веб-порталом.
2. Разрабатываемый портал должен быть написан на Javaс применением фреймворка SpringBoot, а также модулей расширения для этого фреймворка.
3. Клиентская часть портала должна быть написана на HTML5. CSS 4, ECMAScript2015 без применения фреймворков.
4. Система должна быть расширяемой: должна иметься возможность подключения к другихмикросервисов посредством RESTAPI.
5. Система должна хранить данные вдокументоориентированной MongoDB.
6. В качестве ядра для анализа текстов система будет использовать библиотеку GATE с разнообразными плагинами, в том числе написанными ранее командой Научно учебной лаборатории.
7. Система должна эффективно выполнять запросы пользователя, не «зависать».
8. Система должна хранить пользователей и уровни их привилегий, и на их основе разрешать либо запрещать определенные действия.
9. Система должна работать с корпусами и документами внутри них, для работы с каждой сущностью у пользователя должны быть определенные элементы управления.
2. Проектирование системы для анализа академического письма
В данной главе будут освещены основные этапы проектирования программной системы, такие как проектирование базы данных, проектирование серверной и клиентской частей, а также интерфейса.
Проектирование базы данных
Для хранения информации веб-портала была выбрана MongoDB. Всего в базе данных предполагается хранить 7 сущностей (см. рисунок 2.1): сущности, связанные с пользователем, с документами и корпусами, а также сущности аннотаций, текста и статистики.