Модернизация автоматизированной системы по управлению учетными записями обучающихся в ФГБОУ ВО "Вологодский государственный университет"

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Федеральное государственное бюджетное образовательное учреждение высшего образования

Вологодский государственный университет

Институт математики, естественных и компьютерных наук

Кафедра информатики и информационных технологий

Направление подготовки Информационные системы и технологии

Специальность Мультимедиа технологии

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

Тема:

Модернизация автоматизированной системы по управлению учетными записями обучающихся в ФГБОУ ВО «Вологодский государственный университет»

Выполнил Елгаев А.В.

Руководитель В.А. Горбунов

г. Вологда

ОГЛАВЛЕНИЕ

• ВВЕДЕНИЕ
• 1. Анализ предметной области
• 1.1 Бизнес-процессы движения обучающихся в ВоГУ
• 1.2 Информационные системы ВоГУ
• 1.3 Взаимодействие сервисов и информационных систем
• 1.4 Автоматическая система управления учётными записями обучающихся и работников
• 1.5 Необходимые сервисы и возможности IT-инфраструктуры ВоГУ
• 1.6 Существующие решения и возможность их адаптации к текущим требованиям
• 1.7 Постановка задачи на реализацию
• 2. Моделирование модернизированного приложения
• 2.1 Программное обеспечение для моделирования
• 2.2 Моделирование новой структуры АС УЗОР
• 2.3 Модуль получения информации
• 2.4. Модуль ядра
• 2.5 Модуль взаимодействия с доменами
• 2.6 Модуль очереди задач
• 2.7 Модуль взаимодействия с сервисом «Личный кабинет студента»
• 2.8 Модуль взаимодействия с G Suite
• 3. Моделирование модулей приложения
• 3.1 База данных модуля ядра
• 3.2 Модуль очереди задач
• 3.3 Модуль создания учётной записи G Suite
• 3.4 Модуль взаимодействия с доменами
• 3.5 Модуль получения информации
• 3.6 Модуль взаимодействия с сервисом Личный кабинет
• 4. Разработка модулей приложения
• 4.1 Накладываемые ограничения
• 4.2 Выбор инструментов разработки
• 4.3 Модуль получения информации
• 4.4 Модуль ядра
• 4.5 Модуль очереди задач
• 4.6 Модуль G Suite
• 4.7 Модуль взаимодействия с доменами
• 4.8 Модуль взаимодействия с ЛК ВоГУ
• 5. Внедрение модулей приложения
• ЗАКЛЮЧЕНИЕ
• СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
• ВВЕДЕНИЕ
• Актуальность темы: задачи интеграции информационных систем и сервисов поставлено остро. Большое количество различных сетевых служб создано ради решения определённых задач. В большом количестве случаев требуется набор различных программ, сервисов или информационных систем, для решения определённого спектра задач. В образовательной организации перечень подобных инструментов может исчисляться десятками. Все эти инструменты решают свою задачу в рамках своих функциональных возможностей. Зачастую возникает задача взаимной интеграции используемых информационных систем и сервисов, для улучшения качества работы. В некоторых случаях возможно привлечь непосредственных разработчиков программного продукта. В некоторых случаях разработчики предусмотрели возможность интеграции с определёнными программными продуктами. В подавляющем большинстве случаях, у программного продукта нет готовой реализации модулей, для интеграции с другими программными продуктами. В таких случаях необходимы работы по изучению программного продукта на предмет возможных средств коммуникации, а так же разработка программ, выполняющих роль коммуникационной шины, между такими продуктами.
• Цель данной работы: модернизация существующей автоматизированной системы управления учётными записями обучающихся в ФГБОУ ВО «Вологодский государственный университет» (ВоГУ). Система была создана в ответ на требование создания такого программного продукта, который решал бы задачи создания учётных записей в автоматизированном режиме работы. Во время эксплуатации системы выявлялись различные недочёты в функционировании системы, а так же были предложены способы улучшения всей системы и запрошено расширение в функциональных возможностях системы. Анализ предложений сформировал определённый круг задач, который необходимо решить.
• Задачи работы: для достижения целей работы необходимо проанализировать предметную область, для формирования актуализации общего представления о текущих реалиях, формирующих контекст цели работы. Необходимо рассмотреть текущее состояние развития информационных систем, участвующих в работе системы. Так же необходимо рассмотреть и проанализировать те информационные сервисы, которые должны быть интегрированы в общую инфраструктуру ВоГУ, в разрезе развития системы по управлению учётными записями студентов. Для последующих шагов требуется проанализировать саму систему, с целью поиска путей модернизации.

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

Необходимо выполнить построение алгоритмов работы модернизированной системы и на основе разработанных алгоритмов реализовать систему.

Требуется выполнить программную реализацию разработанной системы. Необходимо выполнить её тестирование и оценку результатов тестового запуска.

• Научная новизна работы: новизна разработки состоит в модернизации существующей системы и расширении её функциональных возможностей.
• Практическая значимость работы: значимость работы состоит в упрощении управлением различными бизнес-процессами, выполняемых в ВоГУ. Решение задач, поставленных в рамках текущей работы, позволяет высвободить человеческие ресурсы, расходующиеся на выполнение большого объёма неавтоматизированных работ.
• Апробация работы: апробация работы выполнена в ФГБОУ ВО «Вологодский государственный университет». Иная площадка для апробации модернизированной системы не рассматривалась ввиду того, что проводится работа по модернизации уже действующей в инфраструктуре ВУЗа системы.
• Выпускная квалификационная работа состоит из 5 глав.
• В первой главе выполняется предметный анализ. Рассматривается бизнес-процессы приёма и предоставления доступа к различным системам ВУЗа обучающемуся, для расширения контекстных данных, относительно необходимости тех или иных данных об обучающемся. Перечисляются информационные системы, участвующие в работе модернизируемой системы, а так же системы, планируемые к интеграции в систему. Проводится их детальное рассмотрение, с целью выявления критически важных моментов, необходимых для выполнения задач, поставленных перед работой.
• Вторая глава содержит результаты моделирования модернизированного программного комплекса. Приводится новая структура приложения и его составляющих. Приводится новая функциональная модель работы системы. Кратко перечислены модули системы и их назначение.
• В третьей главе выполнено моделирование модулей системы. Представлены графические результаты моделирования, а так же инфраструктура модулей.
• В четвёртой главе представлена реализация основных алгоритмов работы программных модулей.

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

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

1.1 Бизнес-процессы движения обучающихся в ВоГУ

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

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

При подаче заявления в ВоГУ, абитуриент обязан предоставить список документов в соответствии с правилами приёма. На примере правил приёма на 2019-2020 учебный год перечислим данные о гражданине, критически важные в разрезе текущей работы [1].

1) фамилия, имя, отчество;

2) дата рождения;

3) ИНН/СНИЛС;

4) согласие на обработку персональных данных.

Полученные данные передаются в единую базу данных университета для последующей обработки.

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

1) корпоративный домен ВоГУ (образовательный сегмент). В ВоГУ внедрены сервисы доменного управления IT-инфраструктурой;

2) сервис «личный кабинет студента» предоставляет обучающемуся актуальную информацию о пройденной части образовательной программы, а так же позволяет использовать хранилище данных для формирования электронного портфолио;

3) порталы электронных образовательных ресурсов «Портал электронных образовательных технологий» и «Учебная дистанционная среда педагогического образования» [2-3]

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

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

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

1) уход в академический отпуск по заявлению от обучающегося;

2) отчисление обучающегося с последующим восстановлением;

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

Обучающийся перестаёт быть студентов ВоГУ в следующих случаях:

1) отчисление в связи с окончанием прохождения образовательной программы;

2) отчисление в связи с неуспеваемостью.

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

1.2 Информационные системы ВоГУ

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

Комплексная информационная система управления учебным заведением Модус (КИС УЗ Модус) [4] является ключевой системой обработки данных обучающихся в ВоГУ. Эта система является отечественной разработкой ООО «Информационные системы», расположенной в г. Ярославль. Данное программное обеспечение было разработано в ответ на требование о создании комплексной информационной системы для учебных заведений.

Структурно, эта информационная система состоит из ряда модулей: «Учебные планы», «Расписание», «Кабинет студента», «Преподаватели», «Студенты», «Приёмная комиссия», «Администрирование»

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

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

Используется база данных Microsoft SQL 2008 R2. Настройки сервера БД таковы, что возможны сетевые запросы от разрешённых сетевых узлов. База данных состоит из более чем 960 таблиц.

На запрос к разработчикам о наличии инструментов для интеграции с иными системами и программными продуктами, был получен ответ о полном отсутствии подобного функционала. Модернизацию автоматизированной системы по управлению учётными записями обучающихся и сотрудников следует проводить в рамках взаимодействия с КИС УЗ в рамках прямого взаимодействия с базой данных.

В разрезе работы, ключевыми таблицами являются man, profile, fullfac, gruppa, razdely.

Таблица man представляет собой таблицу, каждая запись которой соответствует одному человеку. Данные заносятся в момент подачи документов в ВУЗ и остаются в базе на период, необходимый для обработки данных.

Структурно, таблица состоит из 101 поля, из которых 27 являются внешними ключами.

Ключевой таблицей является таблица man. Таблица содержит исчерпывающую информацию об абитуриенте/обучающемся. Основные данные заносятся в таблицу на этапе подачи документов. В работе используются следующие поля таблицы man: oid, fam, imja, otch, birthdate, email, inn, pfr. Схема таблицы в разрезе указанных полей приведена на рисунке 1.1.

Таблица profile является перечнем образовательных программ, которые проходил или проходит обучающийся. Таблица содержит данные об образовательной программе, как то: код группы, принадлежность к институту (до 2019 принадлежность к факультету), направление подготовки, код личного дела и т.д. Таблица связана с таблицами man, gruppa, fullfac по первичным ключам. Схема таблицы в разрезе необходимых полей представлена на рисунке 1.2.

Рисунок 1.1 - Неполная схема таблицы man

Рисунок 1.2 - Неполная схема таблицы profile

Таблицы fullfac, gruppa, razdely являются перечнем институтов (до 2019 года факультетов), списком групп и перечнем статусов обучающихся соответственно. Схема таблиц приведена на рисунке 1.3, 1.4 и 1.5 соответственно.



Рисунок 1.3 - Неполная схема таблицы fullfac

Рисунок 1.4 - Неполная схема таблицы gruppa

Рисунок 1.5 - Неполная схема таблицы razdely

На рисунке 1.6 представлена неполная схема связи таблиц между собой.

Рисунок 1.6 - неполная схема связей между таблицами БД КИС УЗ Модус

Анализ данных выявил следующие проблемы:

1) в таблице man присутствуют повторные записи об одном и том же обучающемся. Основной причиной является ошибка персонала приёмной комиссии, при заведении личного дела;

2) в записях таблицы man отсутствуют данные, позволяющие со 100% вероятностью идентифицировать человека. Такими данными является номер СНИЛС и/или ИНН;

3) записи содержат «грязные» данные. Примером таких данных являются строковые данные «Фамилия», «Имя» или «Отчество» обрамлённые символами пробела, содержащие в себе символы кавычек, апострофов или скобок;

4) записи содержат неверные данные принадлежности к определённому институту, как следствие изменения структуры университета в 2019 году.

Анализ бизнес-процессов, связанных с КИС УЗ Модус выявил следующую проблему организационного характера. При изменении персональных данных или контактных данных, обучающиеся не предоставляют новые данные в директорат института. В связи с этим, у подразделений ВУЗа отсутствует центральная база актуальных контактных данных обучающихся. В некоторых случаях, отсутствуют актуальные данные о документах, удостоверяющих личность обучающегося. Как следствие, некоторые подразделения ведут собственные информационные базы, в разрезе персональных и контактных данных обучающихся.

Сервис «Личный кабинет студента ВоГУ» (ЛК ВоГУ) разработан и введён в эксплуатацию в 2019 году в рамках развития электронной образовательной среды Вологодского государственного университета [5]. Внешний вид страницы авторизации сервиса представлен на рисунке 1.7.

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



Рисунок 1.7 - Внешний вид сервиса «Личный кабинет студента ВоГУ»

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

Рисунок 1.8 - Внешний вид сервиса «Личный кабинет студента ВоГУ»

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

Сервис личного кабинета является web-приложением, реализованным с помощью фреймворка YII 2. Данный фреймворк является мощным инструментом для создания web-приложений любого уровня сложности. Язык программирования PHP, на котором написан этот фрэймворк, является наиболее распространённым языком программирования в web-среде.

Портал интегрирован с доменной инфраструктурой ВУЗа в части централизованной аутентификации и авторизации, на основе учётной записи и её метаданных. Интеграция выполнена с использованием протокола LDAP. Реализация со стороны портала выполнена с использованием широко известной библиотеки Adldap2 [6]. Благодаря этой интеграции, сервис позволяет авторизоваться любому обучающемуся в ВоГУ с использованием его учётной записи, что является обязательным условием по предоставлению доступа к личной информации студента.

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

Основная задача сервиса «Расписание занятий» - это предоставление актуального расписания занятий обучающихся. Расписание формируется сектором расписания занятий учебного управления ВоГУ и публикуется на сайте сервиса.

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

Анализ сервиса расписания выявил организационно-техническую проблему. Отсутствует механизм автоматической подписки обучающегося на рассылку изменений расписания.

Сервис домена PI.VOGU создан на основе решения Samba 4 [7]. Данное программное обеспечение является альтернативной реализацией сервисов доменной инфраструктуры Microsoft Active Directory Domain Service. Решение написано на языке программирования Python 2.7, что является предпосылкой к использованию данного языка в первой реализации системы, обновление которой и является целью данной работы.

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

На базе домена PI.VOGU построен механизм единой учётной записи студента и, соответственно, на базе этого домена построена система единой аутентификации обучающегося. Данный механизм реализован через использование протокола LDAP [8], который поддерживает множество информационных систем. Реализация протокола LDAP выполнена на множестве языков программирования, включая PHP и Python.

Структура дерева LDAP представлена следующими ключевыми контейнерами: Students, Workers. В контейнере Students хранятся учётные записи студентов ВоГУ, с группировкой по институтам. Аналогично в контейнере Workers хранятся учётные записи сотрудников университета с группировкой по подразделениям. Графически структура контейнера Students представлена на рисунке 1.9.

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

На рисунке 1.9 видна совмещённая структура. Присутствуют как контейнеры организационных единиц «институт», так и контейнеры организационных единиц «факультет».

Анализ домена выявил проблему техническую проблему. Из-за некорректной LDAP схемы домена невозможно провести обновление текущей версии Samba 4 до более новой. Так же невозможно провести процедуру установления доверительных отношений между текущим доменом PI.VOGU и любым иным по причине проблем с NETBIOS именованием домена, что является критически важным механизмом в инфраструктуре ВоГУ.

Домен EDU.VOGU представлен в IT-инфраструктуре университета как сервис, обслуживающий все учебные подразделения ВоГУ во всех учебных корпусах университета. По задумке ответственных сотрудников, должен заменить домен PI.VOGU в качестве сервиса единой аутентификации обучающихся и сотрудников учебных подразделений.

Рисунок 1.9 - Структура контейнера Students домена PI.VOGU

Доменная инфраструктура предполагает 2 типа серверов:

1) рядовые сервера, реализованные на решении Microsoft Active Directory Domain Service R2 и обслуживающие учебные корпуса.

2) технический сервер, реализованный на Samba 4. Права, предоставленные серверу - управление учётными записями пользователей домена и синхронизация структуры дерева LDAP домена EDU.VOGU.

В Вологодском государственном университете в образовательном процессе активно используются системы электронного обучения. Данные сервисы представлены решением на основе системы дистанционного обучения Moodle [9].

В университете используются 2 портала Moodle для образовательных целей.

«Портал электронных образовательных технологий» (ПЭОТ ВоГУ) [2] является основной системой дистанционного обучения в ВоГУ. Данный сервис используется во всём учебном пространстве университета и предоставляет курсы в электронном виде для обучающихся всех институтов. На 2019 год в базе данных системы зарегистрировано более 7700 учётных записей обучающихся. Внешний вид ПЭОТ ВоГУ представлен на рисунке 1.10.

Рисунок 1.10 - Интерфейс ПЭОТ ВоГУ

Портал «Учебная дистанционная среда педагогического образования» (УДС ПО ВоГУ) [3] предназначен для практических работ по созданию и управлению электронными курсами, на базе системы Moodle. Данный ресурс используется при реализации образовательных программ педагогических направлений. На 2019 год в базе данных зарегистрировано более 2100 учётных записей обучающихся. Внешний вид УДС ПО ВоГУ представлен на рисунке 1.11.

Аутентификация в системе Moodle выполняется через единую учётную запись обучающегося домена PI.VOGU.

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

Рисунок 1.11 - Интерфейс УДС ПО ВоГУ

Возможным путём взаимодействия с Moodle является API [10]. Изучение предоставленных возможностей выявило следующее: невозможно удалит учётную запись пользователя, с использование API. Предлагаются возможные способы реализации данного функционала, с использованием встроенных возможностей Moodle [11-12].

В Вологодском государственном университете внедрен сервис корпоративной электронной почты на базе решения Google G Suite for Education [13]. Данный сервис предоставляет сотрудникам официальные электронные почтовые ящики в домене vogu35.ru.

Механизм администрирования учётных записей выполняется только вручную. Для выполнения этих работ задействованы 4 сотрудника, работающие в режиме выполнения заявок по мере из поступления Учётные записи почты создаются по запросу от сотрудников или обучающихся.

Взаимодействие сервиса электронной почты с составными элементами инфраструктуры ВоГУ отсутствует полностью.

Анализ возможностей интеграции G Suite выявил следующее:

1) для каждого сервиса, входящего в пакет G Suite for Education предоставляется свой собственный интерфейс взаимодействия. Интерфейс представлен через REST API;

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

3) созданы библиотеки, реализующие взаимодействия с сервисами. Библиотеки реализованы на таких языках, как: Python, PHP, Ruby.

Из вышесказанного следует, что техническая возможность взаимодействия модернизируемой системы с сервисами G Suite возможна и практически была реализована в других проектах. Примером такого взаимодействия является авторизация на сторонних интернет-сервисах с помощью учётной записи Gmail или Google+. В рамках набора сервисов G Suite это одна учётная запись, предоставляющая доступ ко всем сервисам сразу.

Отметим следующие функциональные возможности, предоставляемые данными API:

1) создание, сопровождение и удаление учётной записи [14];

2) управление дополнительными полями [15];

3) управление контейнерами пользователей [16]:

4) управление группами пользователей (списки рассылок) [17].

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

Для отделения учётных записей обучающихся от учётных записей сотрудников ВоГУ и от служебных учётных записей необходимо использовать структуру контейнеров пользователей. Пример структуры контейнеров учётных записей приведён на рисунке 1.12

Рисунок 1.12 - Структура контейнеров учётных записей сервисов G Suite

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

1.3 Взаимодействие сервисов и информационных систем

Конкретизируем взаимодействие рассмотренных сервисов IT-инфраструктуры ВоГУ и рассмотрим их более подробно. В соответствии с пунктом 1.1:

1) информация вносится и постоянно актуализируется в ИС КИС УЗ;

2) на основе этой информации необходимо создавать и актуализировать данные учётных записей доменов PI.VOGU и EDU.VOGU;

3) на основе этой информации, с учётом состояния учётных записей доменов, необходимо управлять учётными записями ПЭОТ ВоГУ и УДС ПО ВоГУ;

4) на основании этой информации, с учётом состояния учётных записей доменов, необходимо управлять учётными записями сервиса электронной почты ВоГУ;

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

На рисунке 1.13 представлено взаимодействие сервисов ВоГУ. Пунктиром отмечено взаимодействие между обучающимися и ответственными сотрудниками, управляющими информационными системами и сервисами.

Рисунок 1.13 - Взаимодействие между информационными системами ВоГУ

1.4 Автоматическая система управления учётными записями обучающихся и работников

Автоматическая система управления учётными записями обучающихся и работников (далее АС УЗОР) - это программная разработка, решающая задачи автоматизации процессов создания учётных записей и обновления данных учётных записей обучающихся и работников ВоГУ. В рамках данной работы система рассматривается только в разрезе управления учётными записями обучающихся.

Реализация АС УЗОР выполнена на языке программирования Python 2.7, что обуславливается использованием Samba 4, в качестве сервера домена PI.VOGU. Т.к. Python является языком программирования с широкими возможностями в области повторного использования ранее написанного программного кода, то реализация рассматриваемой системы для своего функционирования использует библиотеки Samba. На момент начала работ по анализу, система имеет внутреннюю версию 0.x.x, на основе которой и была введена в эксплуатацию. Для отличия УЗОР старой версии и новой, модернизированной, определим версию модернизированной системы как 1.х.х

Перечислим функционал, который обеспечивает АС УЗОР версии 0.х.х:

1) массовое создание учётных записей обучающихся. В рамках данного функционала выполняется задача проверки входных данных на полноту, производится уникализация учётных данных обучающихся; Пример входного файла данных представлен на рисунке 1.14.

2) массовое обновление учётных данных обучающихся. В рамках данного функционала решаются задачи сопоставления учётной записи обучающемуся и непосредственного обновления данных учётной записи;

3) формирование списка учётных данных, с указанием ФИО обучающегося, института, группы, логина и пароля учётной записи.

4) протоколирование выполнения операций по созданию и модификации учётных записей. Пример протокола представлен на рисунке 1.15.

Рисунок 1.14 - Пример входного файла данных для АС УЗОР

Программа выполнена в виде модулей, где каждый модуль решает собственные задачи:

1) stud_create.py - основное тело программы. Управляет запуском остальных модулей. Результатом выполнения является результат выполнения всей программы - создание учётных записей обучающихся.

2) stud_csv.py - модуль чтения из файла данных. Результатом выполнения модуля является объект типа «словарь», с подготовленными для работы данными.

3) stud_compare.py - модуль сравнения входных данных с существующими учётными данными. Выходными данными является управляющее решение по созданию или обновлению данных учётной записи.

4) stud_modify.py - модуль изменения данных учётной записи. Результатом выполнения является изменённая учётная запись.

5) stud_pass.py - модуль генерирования пароля учётной записи.

6) stud_translate.py - модуль транслитерации ФИО обучающегося.

Рисунок 1.15 - Пример протокола действий АС УЗОР

За время эксплуатации автоматизированной системы, с 2017 по 2018 год, были выявлены следующие недостатки системы версии 0.х.х:

1) необходимость участия человека в работе системы;

2) отсутствие требуемого функционала в обработке данных;

3) проблемный источник входных данных, в виде файла;

4) невозможность управления ходом выполнения программы.

1.5 Необходимые сервисы и возможности IT-инфраструктуры ВоГУ

В связи с активным внедрением сервиса корпоративной электронной почты в ВоГУ, возникает необходимость в предоставлении возможностей этого сервиса обучающимся. Большое количество компаний предоставляют преференции обучающимся и преподавателям ВУЗов. В большом количестве случаев достаточно указать действующую электронную почту университета, для получения послаблений в использовании требуемого сервиса или продукта. В качестве примера можно привести такие примеры, как JetBrains с их набором продуктов программных продуктов, Microsoft Office 365 Education и т.д [18-19].

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

Следует учесть то, что не редки ситуации, когда де-юре человек не является обучающимся, а де-факто он проходит образовательную программу на общих основаниях. Это случаи перевода из другого ВУЗа в ВоГУ, отчисление обучающегося с его последующим восстановлением и некоторые другие. Подобные ситуации требуют такого механизма управления учётными записями, что бы он позволял отмечать «неотключаемые» и/или «неудаляемые» учётные записи.

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

Самым востребованным функционалом стала возможность сброса пароля учётной записи обучающегося самим обучающимся. За 2018-2019 учебный год в системе учёта заявок Управления информатизации было зарегистрировано более 6000 заявок на сброс паролей учётных записей. Учитывая то, что доступ к функционалу сброса паролей в требуемых сервисах предоставлен ограниченному кругу лиц, заявки такого типа являются проблемой с большим весом.

1.6 Существующие решения и возможность их адаптации к текущим требованиям

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

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

В рамках модернизации АС УЗОР, необходимо интегрировать оба типа сервисов, с учётом новых механизмов работы АС УЗОР.

1.7 Постановка задачи на реализацию

На основе сказанного в пункте 1.5 сформулируем задачи, требующие решения:

1) необходимо изменение механизма получения данных из КИС УЗ;

2) необходима реализация механизма сброса паролей учётных записей обучающихся самими обучающимися. Решение этой проблемы позволит освободить человеческие ресурсы, направленные на выполнение процедур сброса паролей учётных записей;

3) необходима реализация блокирования и удаления учётных записей обучающихся в сервисах ВоГУ. Решение этой проблемы позволит держать актуальный список обучающихся в сервисах ВоГУ и не позволит разрастаться соответствующим базам данных;

4) необходимо создавать учётную запись электронной почты обучающегося совместно с доменной учётной записью.

Необходимо отметить следующее: данные задачи являются частью общих задач представленной работы, в части общей модернизации существующей АС УЗОР 0.х.х.

2. Моделирование модернизированного приложения

2.1 Программное обеспечение для моделирования

Для моделирования, здесь и в дальнейшем, используется программное обеспечение Ramus Educational [20]. Данное ПО является свободно распространяемым, с лицензированием на основе лицензии GNU GENERAL PUBLIC LICENSE Version 3 [21].

Ramus позволяет выполнить моделирование по методологии IDEF0, в соответствии с рекомендациями по стандартизации [22]. Интерфейс программы представлен на рисунке 2.1.

Рисунок 2.1 - Интерфейс Ramus Educational с открытой моделью

2.2 Моделирование новой структуры АС УЗОР

АС УЗОР требует изменения структуры приложения. Это связано с тем, что изначальное решение реализовано в виде монолитного приложения, модули которого «жёстким» способом прописаны непосредственно в коде всего приложения. Подобный подход является нерациональным, в первую очередь из-за того, что каждая последующая модификация приложения требует всё больших трудозатрат.

Решение поставленных в пункте 1.7 задач предполагает моделирование и реализацию новых программных модулей. При условии неизменной архитектуры приложения, их подключение в систему, предполагается, трудоёмким процессом.

Так же следует учесть то, что анализ потребностей ВУЗа, по отношению к IT-сервисам, выявил стабильно растущий спрос на внедрение и интеграцию новых сервисов. Так за 2016-2017 учебный год было внедрено 3 сервиса, за 2017-2018 учебный год было внедрено 5 сервисов. На 2018-2019 учебный год затребована интеграция 4 существующих сервисов между собой на уровне полной автоматизации.

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

Главные критерии, которым должна удовлетворять новая архитектура сервиса:

1) модульность. Система должна состоять из модулей. Модули могут быть как обязательными, без которых система не будет полноценно работать, так и не обязательными или подключаемыми. Отсутствие последних не должно влиять на выполнение главной задачи АС УЗОР - поддержка данных обучающихся в постоянном актуальном состоянии.

2) динамическое подключение дополнительных модулей. Система должна иметь возможность динамически подключать или отключать модули. Эта возможность позволит расширять функционал системы без её отключения.

3) простота подключения модулей. Модули должны иметь простой интерфейс коммуникации. Реализация этого условия позволит ускорить разработку дополнительных модулей системы.

Рассмотрим основу системы АС УЗОР в предполагаемой реализации:

1) ядро системы, отвечающее за работу с базой данных с возможностью постановки заданий в очередь задач;

2) модуль очереди задач с API, для взаимодействия различных модулей системы между собой;

Графическое отображение взаимосвязи основных элементов модернизированной АС представлено на рисунке 2.2.

Рисунок 2.2 - Графическое отображение взаимосвязи основных элементов модернизированной АС УЗОР

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

1) модуль получения информации из источников данных;

2) модуль взаимодействия с доменами;

3) модуль взаимодействия с G Suite;

4) модуль взаимодействия с сервисом ЛК.

На рисунке 2.3 представлено графическое отображение предполагаемой полной структуры модернизируемой системы.

В результате моделирования можно выделить основные потоки данных. Это поток данных между источником данных и модулем ядра системы УЗОР. Модуль ядра должен обрабатывать поступающую информацию и хранить её в центральной базе данных. Между модулем очереди задач и остальными модулями идут потоки данных о задачах и данные детализации задач.

Рисунок 2.3 - Графическое отображение полной структуры АС УЗОР

Результаты DFD моделирования представлены на рисунке 2.4

2.3 Модуль получения информации

Модуль обработки информации является модулем извлечения требуемой информации. Данную структурную часть системы необходимо модернизировать, в соответствии с поставленной задачей. Как ранее было указано, в версии АС УЗОР 0.х.х данный модуль мог обработать только ту информацию, которая поступает через файлы формата CSV. Поставленная задача гласит о том, что данные необходимо выбирать непосредственно из базы данных ИС КИС УЗ.

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

1) запросы к БД должны быть предопределены и ограничены;

2) запросы к БД не должны быть подвержены изменению внешними сущностями;

3) полученная информация должна быть сформирована в сообщение, с использованием JSON нотации.



Рисунок 2.4 - DFD модель АС УЗОР

2.4 Модуль ядра

Сформулируем базовую концепцию модуля ядра. Модуль ядра отвечает за наполнение, сопровождение и удаление информации об обучающихся на основе данных, поставляемых от модуля получения информации и модуля задач. База данных модуля ядра АС УЗОР должна быть центральным хранилищем самой актуальной информации. Остальные системы и сервисы, как действующие, так и несуществующие должны опираться на данные, предоставляемые данным модулем.

Основные задачи, решаемые модулем:

1) идентификация записи обучающегося, на основе поступивших данных;

2) создание записи об обучающемся, в случае отсутствия записи в базе данных;

3) актуализация данных об обучающемся, в случае обновления данных;

4) блокирование и/или удаление записи обучающегося на основе внутреннего регламента по управлению учётными записями профильного подразделения Вологодского государственного университета;

5) постановка задач в очередь задач, на основании создания или изменения информации в базе данных.

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

2.5 Модуль взаимодействия с доменами

Данный модуль выполняет операции создания, модификации и удаления учётных записей доменов PI.VOGU и EDU.VOGU, использующихся в Вологодском государственном университете.

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

Существующий модуль требует незначительной доработки, т.к. его основной функционал не изменяется в модернизируемой системе.

2.6 Модуль очереди задач

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

Этот модуль должен иметь реализацию API на основе REST, что должно максимально упростить взаимодействие модулей системы между собой.

Основные задачи модуля состоят в следующем:

1) обработка и регистрация входящих заданий от модулей системы.

2) обработка и предоставление списка задач, доступных запросившему их модулю.

3) обработка и снятие задачи, по запросу модуля, выполнившего задачу.

2.7 Модуль взаимодействия с сервисом «Личный кабинет студента»

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

Основной функционал, предоставляемый модулем, представлен следующими возможностями:

1) сброс паролей учётных записей сервисов, доступных обучающемуся;

2) обновление личных данных обучающегося.

2.8 Модуль взаимодействия с G Suite

Модуль должен обеспечивать взаимодействие между АС УЗОР и сервисами Google, входящих в пакет G Suite for Education. Модуль выполнять задачи, аналогичные задачам модулю взаимодействия с доменами и сверх того, а именно:

1) создание учётной записи;

2) изменение учётной записи;

3) Блокировка и/или удаление учётной записи;

4) сброс или изменение пароля учётной записи;

5) включение/удаление учётной записи в определённый организационный контейнер;

6) администрирование списков рассылки, в соответствии с перечнем учебных групп;

7) включение/удаление учётной записи в список рассылки.

3. Моделирование модулей приложения

3.1 База данных модуля ядра

Проведём функциональное моделирование модуля ядра, но основе методологии IDEF0. Рассмотрим диаграмму А0, представленную на рисунке 3.1.

В соответствии с основным функционалом модуля ядра, главная функция называется «Внесение данных в центральную базу данных АС УЗОР». Входящими данными являются данные об обучающемся и заявки на обработку учётной записи. Входные данные поставляются модулем получения информации. Заявки предоставляются модулем очереди заявок, по запросу модуля ядра. Основными исполнительными механизмами являются сам модуль ядра, а так же система управления базами данных. Выходными данными являются записи в базу данных.

Рассмотрим контекстную диаграмму А0, представленную на рисунке 3.2. Функционально вся модель разбита на 4 блока. Блок А1 формирует выполняет функцию создания логического объекта пользователя. На этапе создания объекта, входные данные должны быть проверены на наличие ошибок. В случае наличия ошибок, создаётся запись в логах с меткой об ошибке и контекстными данными, позволяющими определить место и характер ошибки. В случае успешного создания объекта, выполняется следующий этап. Функция блока А2 выполняется для защиты системы УЗОР от дублирования записей в базе данных, а так же при выполнении задания, поступившего из очереди задач. При 100% нахождении записи обучающегося в БД, выполняется модификация данных, при необходимости. При отсутствии записи обучающегося создаётся новая запись. В случае, когда идентификатор сформированного объекта данных ставится в соответствие другому обучающемуся, из-за совпадения ключевого идентификатора, ключевой идентификатор изменяется индексированием.

Рисунок 3.1 - Диаграмма А0 модели модуля ядра АС УЗОР

Рисунок 3.2 - Контекстная диаграмма А0 модели модуля ядра АС УЗОР

информационный программный учетный студент работник

Блок А4 выполняет функцию фиксирования ошибок и ошибочных данных. Результат выполнения функции записывается в базу данных и доступен для просмотра.

Рассмотрим набор данных, с которым необходимо работать всей системе. В первую очередь, это данные, необходимые для создания учётной записи: Имя, Фамилия, Отчество. Для идентификации обучающегося на уровне КИС УЗ необходимо хранить идентификатор обучающегося oid из таблицы man.oid. Для уникализации учётной записи обучающегося, в рамках всего вуза, необходимо сгенерировать и хранить его уникальный идентификатор. Этот идентификатор будет использоваться в качестве логина во всех информационных системах, подключенных к АС УЗОР. Для корректного администрирования учётных записей в домене, а так же для корректного распределения обучающихся по группам списков почтовых рассылок, необходимо хранить данные об институте обучения и группе обучающегося. На рисунке 3.3 представлен необходимый для хранения перечень данных.

Рисунок 3.3 - Набор данных базы данных модуля ядра

На рисунке 3.4 представлен набор данных базы данных логирования. Эта база данных предназначена для хранения записей об ошибках, возникших в ходе работ по обработке данных, поступивших в АС УЗОР. В записях хранится информация о характере ошибки и об оштбочных данных обучающегося.



Рисунок 3.4 - Набор данных коллекции warning

3.2 Модуль очереди задач

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

Выполним функциональное моделирование модуля с использованием методологии IDEF0. На рисунке 3.5 и 3.6 представлены диаграммы А0 и её декомпозиция, разработанные для модуля очереди задач.

На контекстной диаграмме А0 перечислены следующие блоки:

1) А1 - функцией данного блока является определение типа запроса, в соответствии с REST. Определяя тип HTTP запроса, модуль выполняет функцию одного из трёх функциональных блоков: А2, А3 или А4.

2) А2 - функция данного блока выполняется в случае поступления POST запроса. Данный запрос соответствует постановке задачи в очередь задач. Результатом выполнения функции является добавление задачи в очередь задач.

3) А3 - функция данного блока выполняется в случае GET запроса. Данный запрос соответствует запросу списка задач из очереди задач. Результатом выполнения функции является ответ запросившему модулю, в формате JSON.

4) А4 - функция данного блока выполняется в случае DELETE запроса. Данный запрос соответствует удалению задачи из списка задач. Результатом выполнения данного блока является удаление из очереди задач указанной задачи

Рисунок 3.5 - Диаграмма А0 модуля очереди задач

Рисунок 3.6 - Декомпозиция блока А0 диаграммы модуля очереди задач

Рассмотрим набор данных, необходимый для корректного полного формирования задания остальным модулям системы УЗОР.

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

Базовый набор данных базы данных модуля представлен на рисунке 3.7

Рисунок 3.7 - Набор данных базы данных модуля очереди задач.

В зависимости от задачи, массив данных детализации отличается. В таблицах 1, 2, 3 и 4 представлены наборы детализации, в зависимости от постановленной задачи.

Таблица 1

Набор данных детализации задачи создания учётной записи

Элементы детализации	Модуль-постановщик задачи	Модуль исполнитель
sn	Модуль ядра	Модуль взаимодействия с доменами, модуль взаимодействия с G Suite
name
middlename
oid
login
email
password
OU

Таблица 2

Набор данных детализации задачи блокирования учётной записи

Элементы детализации	Модуль-постановщик задачи	Модуль исполнитель
login	Модуль ядра	Модуль взаимодействия с доменами, модуль взаимодействия с G Suite

Таблица 3

Набор данных детализации задачи удаления учётной записи

Элемент детализации	Модуль-постановщик задачи	Модуль исполнитель
login	Модуль ядра	Модуль взаимодействия с доменами Модуль взаимодействия с G SuiteМодуль взаимодействия с СДО

Таблица 4

Набор данных детализации задачи сброса пароля учётной записи

Элемент детализации	Модуль-постановщик задачи	Модуль исполнитель
login	Модуль взаимодействия с сервисом личного кабинета	Модуль взаимодействия с доменами Модуль взаимодействия с G Suite

Т.к. непосредственный доступ сторонним модулям к очереди задач не предоставляется, всё взаимодействие ведётся через API. В соответствии с концепцией REST используются стандартные HTTP запросы. Для постановки задачи используется запрос типа POST, для запроса списка задач используется запрос типа GET.

3.3 Модуль создания учётной записи G Suite