Для описания архитектуры системы этапа проектирования была создана диаграмма компонентов, на которой указаны отдельные элементы разрабатываемого веб-портала (см. рисунок 2.9).
Рисунок 2.9 - Диаграмма компонентов веб-портала
В рамках портала данные предполагается хранить в MongoDB, за извлечение, модификацию и удаление данных отвечает сервис для их хранения. Далее сервисы на стороне сервера выполняют обработку данных по запросу клиентской части. На клиентской части данные отображаются пользователю.
Все приложение размещается в единственном JAR-файле, в том числе статические элементы - верстка, таблицы стилей и скрипты. MongoDB планируется запускать в виде сервиса - в таком случае база данных будет всегда доступна модулю Spring Data.
3. Реализация системы для анализа академического письма
В данной главе будет подробно описан процесс реализации портала для анализа академического письма на английском языке, а также описаны процедуры и артефакты, примененные для тестирования системы.
Реализация серверной части
Для разработки серверной части еще на этапе выдвижения требований к программной системе были подобраны подходящие для задачи инструменты разработки, а также программные компоненты и языки программирования, база данных. Важным аспектом является взаимодействие серверной и клиентской части. Также будет описан процесс создания конвейера GATE, который интегрирован в систему как ее неотъемлемая часть.
Инструменты разработки
Серверная часть веб-приложения написана на языке Javaи базируется на фреймворке SpringBoot, который существенно упрощает разработку веб-приложений по сравнению с SpringMVC. В качестве базы данных используется документоориентированная MongoDB, которая позволяет беспрепятственно сохранять документы большого объема в свое хранилище. Для коммуникации с клиентской частью используется шаблонный процессор Thymeleaf, который обрабатывает HTML5_совместимые шаблоны страниц на сервере и далее отсылает их конечному пользователю.
Для разработки серверной части приложения основным инструментом стала IDE Intelli JIDEA. Система заточена на использование для разработки на языке Java(и некоторых других совместимых языков). Однако, небольшой неожиданностью оказалось отсутствие поддержки фреймворка Spring, вследствие чего IDEпри сборке выводит предупреждения, которые по своей сущности являются одной из особенностей работы Spring.
На официальном сайте Springможно сразу же создать готовый шаблон для проекта на SpringBoot, подключив все необходимые модули Spring, в том числе для работы с базами данных [20]. Здесь можно выбрать систему сборки, язык программирования (Java-совместимые), версию фреймворка Spring, а также указать информацию о создаваемом проекте (см. рисунок 3.1).
Рисунок 3.1 - Инициализатор приложения Spring
После создания проекта таким образом, его можно скачать, разархивировать - и он уже будет готов к разработке. После сборки в любой студии для разработки на Javaпроект можно будет запустить, правда, на этот момент там ничего не будет.
Для проведения анализа текстов используется Java-библиотека GATE Embedded, которая с помощью заранее созданной программы-конвейера обрабатывает тексты. В данный конвейер интегрированы встроенные маркеры GATE, а также набор маркеров, разработанных ранее в рамках Научно-учебной лаборатории.
Создание конвейера GATE
GATEявляется довольно гибким семейством программ, позволяя работать с собой как программистам, так и исследователям-лингвистам. Для этого GATEподразделяется на несколько частей, самые важные из которых для данной работы являются GATEDeveloper и GATEEmbedded. GATEDeveloper представляет собой среду, в которой можно создавать конвейеры для обработки текстов, собственно обрабатывать корпуса текстов, проводить статистические исследования и многое другое. В сущности, GATEDeveloper является user-friendly оболочкой для GATEEmbedded (см. рисунок 3.2).
Рисунок 3.2 - Взаимодействие пользователя с GATEDeveloper
Очевидно, что практически все, что можно сделать в GATEDeveloper, можно провести и в GATEEmbedded, но при создании программы-конвейера для данного проекта был избран первый путь, так как создание в среде Developerпроще, быстрее, и позволяет на месте сериализовать полученную программу в XML.
Если использовать GATEEmbedded для этой же цели, то теоретически можно загрузить плагины GATEво время запуска сервера, но так как GATEEmbedded предоставляет возможность десериализовать XML в программу, преимущества динамического подхода для портала неясны, так как на данный момент программа-конвейер одна. В будущем, если будет принято решение добавить возможность модифицировать конвейер, то, возможно, будет рассмотрено описанное решение для динамической загрузки плагинов. Однако, как уже было упомянуто, GATEEmbedded используется внутри сайта по схеме, представленной ниже (см. рисунок 3.3).
Рисунок 3.3 - Взаимодействие программиста с GATEEmbedded
С помощью библиотеки портал десериализует XML-программу (загрузка плагинов происходит автоматически из classpath внутри jar), динамически создает документы с содержимым, загружаемым пользователями портала, и далее проводит обработку. По окончании обработки и в случае отсутствия исключений, на выход поступает XML-разметка, содержащая текст и аннотации.
Разработка слоя контроллеров
Слой контроллеров внутри приложения поделен на две независимые части: слой контроллеров для обработки поступающих HTTP запросов на получение представлений (Views), а также слой API, внутри которого разработаны REST_контроллеры, принимающие JSON-данные (для GET-запросов параметры передаются в адресной строке для кэширования), обрабатывающие их, и возвращающие JSONв ответе. Подробное описание контроллеров представлено ниже (см. таблица 3.1).
Таблица 3.1 - Описание контроллеров серверной части
|
Название контроллера |
Тип запроса Путь запроса |
Параметры |
Примечания |
|
|
IndexController |
GET/index |
Возвращает представление стартовой страницы, с которой уже можно переместиться на все остальные страницы портала. |
||
|
CorporaController |
GET/corpora |
Возвращает представление страницы с корпусами системы. Было принято решение загружать корпуса динамически, поэтому заполнение списка происходит на клиентской стороне. |
||
|
DocumentsController |
GET/documents |
id |
Аналогично предыдущему контроллеру, данный контроллер возвращает представление списка документов. Требует id корпуса для отображения документов. |
|
|
CorpusApiController |
POST/api/create_corpus |
name |
Данный запрос создает новый корпус с заданным именем, далее возвращает его. |
|
|
GET/api/read_corpus |
Считывает существующие и доступные корпуса и возвращает их в JSON-массиве. |
|||
|
POST/api/delete_corpus |
id |
Удаляет корпус с заданным IDиз системы. |
||
|
DocumentApiController |
POST/api/create_documents |
Array of: corpusId content name |
Создает документs в указанном корпусе с указанным именем (в текущем проекте имя файла становится именем документа), отправляя строки с содержанием на обработку GATE. Затем система автоматически создает объектыText с размеченным текстом, и сохраняет данные в БД. |
|
|
GET/api/read_document |
corpusId |
Считывает документы, принадлежащие к заданному корпусу. |
||
|
POST/api/delele_document |
corpusId id |
Удаляет документ из базы, а также удаляет его из корпуса, к которому он принадлежит. |
||
|
TextApiController |
GET/api/read_text |
id |
По idдокумента считывается размеченный текст вместе с аннотациями, и отправляется на клиентскую часть. |
|
|
UserApiController |
POST/api/register |
login password |
Портал регистрирует нового пользователя с заданным логином и зашифрованным паролем. |
|
|
POST /api/login |
login password |
Портал проверяет, существует ли заданный пользователь, и далее по результату проверки авторизует его (или отказывает в авторизации). |
||
|
StatisticsApiController |
GET /api/statistics |
corpusId |
Возвращается статистика по маркерам по заданному корпусу. |
В своей реализации контроллеры, как правило, обращаются к классам сервисного слоя, которые уже, в свою очередь, извлекают, модифицируют или удаляют информацию в базе данных.
Разработка сервисного слоя
Сервисный слой в данной системе фокусируется на обработку поступающих запросов на создание сущностей, чтение, удаление и модификацию. В основном методы классов сервисного слоя обслуживают соответствующие методы классов слоя контроллеров.
Отдельно разработан сервис, инкапсулирующий GATE Core, таким образом, проводящий обработку поступающих в систему текстов с помощью встроенных в портал аннотаций. Сервис использует библиотеку GATE Embedded для обработки текстов с помощью, заранее написанной в среде GATE Developer программы, которая, в сущности, является конвейером из нескольких маркеров, каждый из которых получает результат от предыдущего маркера, обрабатывает его, и отправляет дальше (см. рисунок 3.4).
Рисунок 3.4 - Конвейер, разработанный с помощью GATEDeveloper
Конвейер GATE использует как стандартные плагины, так и разработанные прошлыми командами, которые входили в состав научно-учебной лаборатории. Многие плагины оформлены отдельным Java-модулем, что требовало знание Javaпри их разработке. Для некоторых задач было достаточно использования плагина JAPE Transducer, который позволяет с помощью языка разметки, подобного регулярным выражениям, создавать аннотации.
Корпус и документы для GATEсоздаются динамически, далее они обрабатываются с помощью библиотеки. Итоговая разметка передается в конструктор класса Text, где происходят преобразования, позволяющие отображать и анализировать текст внутри данного портала (подробнее об этом см.ниже).
Разработка моделей предметной области
Были разработаны модели предметной области для сохранения информации о ключевых объектах в базе данных, а также сущности, являющиеся временными при получении данных от клиентской части. Например, при создании документа создается временный объект, который содержит исходный текст, но после обработки средствами GATEэтот текст уже не требуется, так как уже создана отдельная сущность, хранящая текст с аннотациями в формате XML. Описания моделей предметной области представлены в таблице ниже (см. таблица 3.2).
Таблица 3.2- Описания моделей предметной области
|
Название |
Поля |
Примечания |
|
|
Corpus |
id name {documents} |
Корпус хранит свой id, название, а также набор уникальных документов, которые являются idдокументов в их таблице. |
|
|
Document |
id corpusId name textId |
В документе хранится id документа и родительского корпуса, а также его название и idаннотированного текста. |
|
|
Text |
id [nodes] [annotationList] |
Класс текста содержит id, узлы в размеченном тексте (который десериализуется из GATE), а также список аннотаций для их дальнейшего отображения и анализа. |
|
|
User |
id login password |
О пользователе портал хранит минимальную информацию: id, логин, указанный при регистрации, а также пароль в зашифрованном виде. |
Для работы с базой данных используется механизм репозиториев SpringData. Для каждого из классов моделей предметной области был создан репозиторий, который, в сущности, является расширением стандартного интерфейса, определенного в Spring. При запуске портала фреймворк находит все репозитории и ссылки на них и генерирует шаблонные реализации этих интерфейсов (см. листинг3.1).
Пример расширения интерфейса MongoRepository<Entity, Id>
publicinterfaceCorpusRepositoryextends MongoRepository<Corpus, String> {
Optional<Corpus>findByName(String name);
}
Все остальные репозитории выглядят примерно так же, и в них уже определены основные CRUD-операции. В примере выше приведен пример создания запроса findк репозиторию. Springанализирует название, параметры и возвращаемое значение метода, и далее пытается сконструировать запрос. В случае, если необходимое поле найдено в классе модели, то этот запрос можно будет использовать сразу же в коде без необходимости реализации интерфейса (возможность создания собственной реализации интерфейса присутствует, но в данном проекте она оказалась не востребована).
Разработка вспомогательных классов
Не менее важной частью программной системы являются ключевые вспомогательные классы. Некоторыми из задач, решаемых ими, является построение дерева на основе XMLразметки, полученной от GATE, инкапсуляция статистики по корпусу, а также хранение информации об аннотациях. Отдельно были разработаны классы исключений, соответствующих предметной области.
Для парсингаXML-файлов, полученных от GATE, были разработаны два класса: TextHandler и AnnotationHandler, каждый из которых расширяет базовый класс DefaultHandler. Этот класс используется во встроенном в JavaSAX (SimpleAPIforXML) парсере. Механизм работы этого парсера таков, что он проходит по документу и сообщает объекту Handlerо встреченных во время прохода XML-тегах, вследствие чего не требуется конструирование дерева в памяти, и проходы выполняются довольно быстро.
Для простоты реализации парсингXML, полученных от GATE, выполняется в два прохода: первый проход парсер работает с TextHandler, после чего из исходного файла считывается текстовые данные (размещены в особых узлах). Второй проход осуществляется с помощью AnnotationHandler, и он извлекает аннотации. В будущем возможно объединение объектов Handler для ускорения парсинга, но на данный момент это некритично.
Пример XML-файла, создаваемого GATE
<?xmlversion='1.0' encoding='UTF-8'?>
<GateDocumentversion="3">
<!-- Признаки документа, не используются -->
<GateDocumentFeatures>
<Feature>...</Feature>