Учредитель журнала

Анализ информационных процессов для системы отображения учебного расписания

УДК 004.65 + 004.946

DOI 10.52815/0204-3653_2022_56189190_82
EDN: HYODCN

Егорова Екатерина
Доцент кафедры «Прикладная информатика», к. э. н., Пензенский государственный технологический университет.
E-mail: katepost@yandex.ru

Колобова Екатерина
Доцент кафедры «Прикладная информатика», к. т. н., Пензенский государственный технологический университет.
E-mail: bel-eka@yandex.ru

Чигирева Ирина
Доцент кафедры «Прикладная информатика», к. т. н., Пензенский государственный технологический университет.
E-mail: ichigireva@yandex.ru

Попова Наталия
Доцент кафедры «Математическое обеспечение и применение ЭВМ», к. т. н., Пензенский государственный университет.
E-mail: popov.tasha@yandex.ru

Юранов Владимир
Ведущий разработчик ООО «БОГГ.АРТ».

Составление расписания – одна из наиболее распространённых задач в планировании и оптимизации учебного процесса в учебных заведениях. От того, насколько хорошо составлено расписание, зависит эффективность работы преподавателей, усвоение учебного материала студентами, рациональное использование материальных ресурсов.
Автоматизация составления и сопровождения расписания является классической задачей в системах управления учебным заведением. Однако, на данный момент, нет единого, общепринятого способа её решения.
В Пензенском государственном технологическом университете используется система для отображения расписания на сайте вуза. Проблема такого подхода состоит в отсутствии удобного поиска расписания по преподавателю или аудитории, невозможности использовать эти данные ­какими-либо сторонними системами. Решением данной проблемы может стать разработка системы-­посредника, которая будет осуществлять процесс интеграции данных из одной системы в другую.
Интеграция данных предполагает объединение данных, находящихся в различных источниках, и предоставление данных пользователям в унифицированном виде. Этот процесс становится важным в двух направлениях. Во-первых, при решении коммерческих задач, когда двум похожим компаниям необходимо объединить их базы данных. Во-вторых, в научных задачах при комбинировании результатов исследования из различных биоинформационных репозиториев. При этом роль интеграции данных возрастает, когда увеличивается объём и необходимость совместного использования данных.
При создании подсистемы интеграции возникает ряд задач, состав которых зависит от требований к ней и используемого подхода. К ним, в частности, относятся:
разработка архитектуры системы интеграции данных;
создание интегрирующей модели данных, являющейся основой единого пользовательского интерфейса в системе интеграции;
разработка методов отображения моделей данных, а также их построение в интегрирующую модель для конкретных прикладных задач, поддерживаемых отдельными источниками данных;
интеграция метаданных, используемых в системе источников данных;
преодоление неоднородности источников данных;
разработка механизмов семантической интеграции источников данных [3].
Разработка автоматизированной системы для отображения расписания занятий вуза, включающую подсистему интеграции для получения и накопления информации, а также разработка мобильного приложения, которое является ее потребителем и отображает расписание аудитории при помощи технологии дополненной реальности, позволит решить описанную проблему.
В настоящее время в большинстве высших учебных заведений расписание составляется вручную сотрудниками диспетчерской службы и в полном объеме хранится в файлах формата Excel, размеченных специальным образом. На сайт эти данные транслируются специальной программой, и получить доступ к данным возможно только через сайт университета. Для реализации задачи интеграции необходимо решить вопрос получения данных расписания и добавления их в базу данных по раздельным таблицам, которые будут хранить сведения об аудиториях, преподавателях, дисциплинах. Очевидно, что для этого целесообразно применение технологии парсинга сайта, последовательного синтаксического анализа информации, размещённой на интернет-­страницах.
Поскольку текст интернет-­страниц представляет из себя иерархичный набор данных, структурированный с помощью человеческих и компьютерных языков, то задача парсинга сайтов включает в себя два процесса: поиск необходимых данных на страницах, осмысливание полученных данных [6].
Поддержка формального языка поиска и осуществления манипуляций с подстроками в тексте, основанного на использовании метасимволов (символов-­джокеров, англ. wildcard characters) присутствует во многих языках программирования. Помимо этого, такая поддержка реализована и в некоторых текстовых редакторах, поэтому в качестве метода для поиска информации было принято решение использовать регулярные выражения. Для поиска используется строка-­образец (англ. pattern), так называемая «маска», состоящая из символов и метасимволов и задающая правило поиска. Для манипуляций с текстом дополнительно задаётся строка замены, которая также может содержать в себе специальные символы [4, 5].
Для обращения к конкретной странице и выполнения регулярных выражений для поиска необходимой информации на сайте лучше всего подходит такой инструмент как PhantomJS, являющийся полнофункциональным браузером без графической оболочки, управлять которым можно с помощью скриптов написанных на JavaScript.

Расписание приемной комиссии вуза
Источник: мичуринск-наукоград.рф / photos.istu.ru

В качестве средства для создания автоматизированного интеграционного сервиса (серверной части системы) необходимо использовать программный комплекс с СУБД, поддерживающий обмен информацией по протоколу http, позволяющий выдавать ответ на запрос информации в виде html-файла, и поддерживающий клиент-­серверную архитектуру. Поэтому было принято решение использовать свободный фреймворк для веб-приложений на языке Python – Django, использующий шаблон проектирования Model View Controller (MVC). Кроме того, проект является бесплатным, модульным, поддерживает СУБД Sqlite, и позволяет обеспечить клиент-­серверное взаимодействие со всеми частями системы.
Кроме того, в процессе разработки приложений с клиент-­серверной архитектурой неизбежно возникает проблема выбора формата обмена данными между клиентскими и серверным модулями. Такие параметры как время отклика, объем передаваемой информации по каналу связи, расширяемость и портируемость, требуемые ресурсы, могут зависеть от формата обмена данными и оказать значительное влияние, как на работу приложения, так и на трудоемкость дальнейшей модернизации. В настоящее время не существует сформулированных критериев, благодаря которым можно было бы сравнить форматы обмена данными в приложениях с клиент-­серверной архитектурой. В то же время на различных ресурсах, посвященных IT-тематике, профессиональными разработчиками и архитекторами информационных систем не раз делались попытки такие критерии рекомендовать. Стоит отметить, что, несмотря на значительное число характерных черт, рекомендованных в качестве критериев сравнения, не все они представляют теоретическую или практическую пользу. Ниже представлены те критерии сравнительного анализа, которые в настоящее время представляются наиболее важными при принятии решения в процессе разработки клиент-­серверного приложения:
Человекочитаемость – предполагает простую и удобную разметку передаваемых данных. При этом язык должен иметь незначительное количество символов-­разделителей (скобки, кавычки и т. д.).
Простота сериализации – преобразования объекта (данных) в поток байтов для дальнейшего хранения или передачи по каналу связи, в память или файл.
Простота десериализации – преобразования потока байтов в объект данных.
Возможность проверки формата входных данных – наличие в формате обмена данными внутреннего языка описания структуры документа, необходимого для осуществления предварительной проверки на соответствие приходящих данных, например, со стороны клиента.
Эффективность сжатия данных – включает скорость выполнения алгоритма компрессии и коэффициент сжатия.
Распространенность – наличие большого количества разработчиков, использующих тот или иной формат обмена данными.
Динамика развития, которая характеризуется скоростью популяризации и развития [7].
Исходя из проведенного анализа по выделенным критериям было принято решение использовать формат JSON (Java Script Object Notation) для обмена данными между различными частями системы, представляющий собой облегченный формат обмена данными между компьютерами. В соответствии с определением стандарта сценарного языка программирования ECMA (Европейской ассоциации производителей компьютеров), он является производным от литералов Java Script. JSON более компактен, чем XML, его конструкции легче анализируются средствами Java Script, для которого JSON является внутренним используемым типом данных. Основная сфера применения JSON – программирование web-приложений, где он служит альтернативой XML [8, 9].
Одним из возможных решений задачи демонстрации расписания занятий по аудиториям является использование приложений дополненной реальности. Они основанны на маркерах и позволяют решать задачи в областях, в которых возможно явное указание места сцены, где должно быть размещено дополнение. Безусловными преимуществами таких систем является меньшая, по сравнению с безмаркерными системами, трудоёмкость и наукоёмкость разработок, а также большая надежность определения точных координат расположения дополнительного контента. Поэтому в качестве средства реализации технологии дополненной реальности была выбрана платформа Vuforia, разработанная компанией Qualcomm, которая является инструментарием разработчика программного обеспечения дополненной реальности (Software Development Kit – SDK) для мобильных устройств. Vuforia является наиболее гибкой и быстроразвивающейся на данный момент, использует технологии компьютерного зрения, а также отслеживания плоских изображений и простых объёмных реальных объектов в реальном времени.
После определения всех необходимых инструментов для реализации поставленных задач, следующим этапом является определение концепции системы.
В ходе создания концепции построения системы для отображения расписания занятий вуза выделены следующие участники бизнес-­процессов:
диспетчерская;
управление информатизации;
подсистема интеграции;
внешние потребители.
Интеграция имеющейся системы расписания с новыми потребителями через дополнительный сервис, а также состав информационных потоков и носители данных показаны на диаграмме потоков данных автоматизированной системы (рис. 1).

Рис. 1. Диаграмма потоков данных автоматизированной системы

На представленной диаграмме отражены следующие данные:
оперативные: расписание аудитории, расписание преподавателя;
справочные: аудитории, преподаватели, время, дисциплины, неделя.
Таким образом, разрабатываемая система включает в себя:
подсистему разбора текста сайта расписания для составления БД;
подсистему вывода результатов запроса пользователя информации о расписании;
мобильное приложение, выводящее расписание аудитории с использованием технологии дополненной реальности.
Исходя из этого, система выполняет следующие функции:
парсинг сайта расписания ПензГТУ при обновлении информации;
добавление данных о аудиториях, дисциплинах, преподавателях в БД;
формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») в формате JSON;
формирование расписания по заданному критерию («Аудитория», «Преподаватель», «Дисциплина») и вывод в окно браузера;
интеграция с мобильным приложением дополненной реальности.
Для реализации концепции системы необходимы выполнить ряд работ. На рис. 2 представлен состав и последовательность этапов по созданию автоматизированной системы.

Рис. 2. Этапы разработки компонентов автоматизированной системы

Рассмотрим подробнее некоторые из представленных этапов.
Этапы разработки RESTful-сервиса и подсистемы автоматического разбора существующего расписания, web-интерфейса просмотра расписания, функциональной и информационной части мобильного приложения, префабов для приложения, а также алгоритма работы приложения были подробно описаны в работе [1].
Этап разработки моделей и представлений. Модели отображают информацию о данных, с которыми работает приложение. Одна модель представляет одну таблицу в базе данных. После создания модели, Django автоматически создает API для работы с базой данных, который позволяет создавать, получать, изменять и удалять объекты. Перечень созданных моделей приведен в таблице 1.

Таблица 1. Модели таблиц базы данных

В результате выполнения команд миграции была создана база данных в формате SQLite3 со структурой, которая соответствует описанию моделей (рис. 3).

Рис. 3. Структура БД серверной части системы

Django выбирает представление, анализируя запрошенный URL, и после обработки запроса использует шаблон для генерации страницы. В разрабатываемой системе представления используются для отображения информации о расписании в формате JSON ответа для внешних потребителей, а также для отображения html-страницы расписания аудитории.
Этап разработки маршрутизатора web-запросов. Для обработки web-запросов в Django используется специальный внутренний механизм, основанный на регулярных выражениях. При запросе к странице Django-­сайта, используется следующий алгоритм определения кода:
Django определяет, какой корневой модуль URLconf использовать. Обычно, это значение настройки ROOT_URLCONF, но если объект запроса HttpRequest содержит атрибут urlconf (установленный request middleware), его значение будет использоваться вместо ROOT_URLCONF.
Django загружает модуль конфигурации URL и ищет переменную urlpatterns. Это должен быть список экземпляров django.conf.urls.url().
Django перебирает каждый URL-шаблон по порядку и останавливается при первом совпадении с запрошенным URL.
Если одно из регулярных выражений соответствует URL, Django импортирует и вызывает соответствующее представление, которое является просто функцией Python (или представление-­класс). При вызове передаются следующие аргументы:
объект HttpRequest;
если в результате применения регулярного выражения получили именованные совпадения, они будут переданы как позиционные аргументы;
именованные аргументы создаются из именованных совпадений. Они могут быть перезаписаны значениями из аргумента kwargs, переданного в django.conf.urls.url().
Если ни одно регулярное выражение не соответствует, или возникла ошибка на любом из этапов, Django вызывает соответствующий обработчик ошибок [10].
На рис. 4 приведен пример разработанного модуля URLConf.

Рис. 4. Пример файла конфигурации URL-обработчика

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

Таблица 2. Список регулярных выражений

Для сбора информации по всем ссылкам на странице был разработан Javascript-код, результат выполнения которого в консоли браузера представлен на рис. 5.

Рис. 5. Результат выполнения кода поиска информации о расписании

Этап разработки процесса автоматизации парсинга сайта расписания. Для записи полученных данных в базу данных, сформированные данные последовательно посылаются в виде POST-параметров AJAX-запроса на адрес разработанного REST сервиса (POST /api/timetable/). Таким образом, происходит отделение способа получения данных о расписании и способа занесения их в БД.
На следующих этапах разработки системы отображения расписания необходимо создать web-интерфейс системы и мобильное приложение, подробно описанные в работе [1].
Для демонстрации работоспособности системы необходимо запустить скрипт парсинга расписания сайта учебного заведения. После завершения этого процесса база данных подсистемы интеграции будет заполнена данными о расписании. Далее необходимо запустить мобильное приложение на выполнение на мобильном устройстве, используя маркер дополненной реальности, при этом должно произойти соединение с сервером и при ответе сервера на экране должно быть выведено расписание аудитории (рис. 6).

Рис. 6. Пример работы мобильного приложения

Таким образом, разработанная автоматизированная система отображения расписания учебного заведения [2] позволяет решить ряд задач:

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