Данный модуль предназначен для создания учётной записи G Suite. Результатом выполнения этой задачи является автоматическое создание учётной записи электронной почты в общей системе электронной почты ВоГУ.

Реализация данного функционала является ключевым требованием для качественного развития АС УЗОР.

Выполним функциональное моделирование модуля. Специфика работы модуля допускает отсутствия любых входных данных на верхнем уровне модели А0. Результатом выполнения работы модуля является учётная запись сервиса G Suite, заполненная требуемыми данными обучающегося. Диаграмма А0 представлена на рисунке 3.8. Задача получения задания из очереди задач выполняется по расписанию. Результатом выполнения опроса являются данные

Рисунок 3.8 - Диаграмма А0 модели модуля создания учётных записей G Suiteобучающегося, в случае, если задача была поставлена в очередь задач

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

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

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

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

4) удаление учётной записи.

Данные детализации задач представлены ранее в таблицах 1, 2, 3 и 4. При выполнении задачи, модуль удаляет задачу из очереди задач. Задача представлена блоком А3 на контекстной диаграмме А0. На этапе полного выполнения выходными данными являются следующие сущности:

1) Настроенная, в соответствии с требованиями Управления информатизации ВоГУ , учётная запись G Suite;

2) изменённая, в соответствии с результатами выполнения задачи, очередь задач;

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

Декомпозиция диаграммы А0 представлена на рисунке 3.9.

Выполним декомпозицию блока А2. Контекстная диаграмма представлена на рисунке 3.10. Диаграмм представлена следующими блоками:

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

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

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

4) А24 - функция обратной связи сервиса G Suite с внешними сервисами. Результатом выполнения функции является буквенно-числовой код ответа, в зависимости от которого модуль АС УЗОР может определить с каким результатом была выполнена работа со стороны сервиса G Suite.

Рисунок 3.9 - Декомпозиция блока А0 диаграммы модуля создания учётных записей G Suite

Рисунок 3.10 - Контекстная диаграмма декомпозиции блока А2 модели модуля создания учётной записи сервиса G Suite

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

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

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

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

1) блок А1 выполняет функцию определения типа задачи и извлечение данных детализации задачи;

Рисунок 3.11 - Диаграмма А0 модели модуля взаимодействия с доменами

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

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

Рисунок 3.12 - Диаграмма А0 модели модуля взаимодействия с доменами

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

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

Проведём моделирование модуля, с учётом требований. Диаграмма А0 результатов моделирования представлена на рисунке 3.13. В работе модуля участвуют следующие сущности:

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

2) механизмами являются непосредственно модуль АС УЗОР, СУБД MS SQL 2008 R2.

3) входящими сущностями является информация из источника информации. И управляющие модулем задачи из модуля очереди задач АС УЗОР. В контексте текущей работы, источником информации является база данных ИС КИС УЗ.

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

Рассмотрим контекстную диаграмму А0, представленную на рисунке 3.14. На рисунке представлены следующие блоки:

Рисунок 3.13 - Диаграмма А0 модели модуля получения информации

1) А1 - аналогично остальным модулям, данный модуль получает задания от модуля очереди заданий;

2) А2 - функцией данного блока является подключение и получение данных из базы данных или иного источника данных;

3) А3, А4, А5 - в этих блоках формируются и отправляются пакеты сообщений для модуля ядра и модуля очереди задач АС УЗОР.

Рисунок 3.14 - Контекстная А0 модели модуля получения информации

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

Проведём функциональное моделирование взаимодействия сервиса ЛК ВоГУ и АС УЗОР. Общий вид модели представлен на рисунке 3.15. Взаимодействие между двумя система предполагается в формате управляющих сообщений. Согласно задачам из пункта 1.7, необходимо предусмотреть механизм смены данных обучающегося и механизм сброса пароля для учётных записей сервисов ВоГУ. На основе это сформулируем следующее:

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

2) результатом работы модуля является запрос на постановку задания в очередь задач АС УЗОР;

3) механизмами модели являются сервис ЛК ВоГУ и сам обучающийся непосредственно;

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

На рисунке 3.16 представлен контекст диаграммы А0. Контекст содержит 4 блока, в функционал которых входит:

1) А1 и А2 - приём запроса на выполнение определённой задачи;

2) А3 - формирование корректного JSON сообщения для модуля задач АС УЗОР.

3) А4 - постановка задачи на исполнение, через передачу сформированного сообщения в модуль задач АС УЗОР через API модуля.

Рисунок 3.15 - Диаграмма А0 модели взаимодействия ЛК ВоГУ и АС УЗОР

Рисунок 3.16 - Контекстная А0 модели модуля получения информации

4. Разработка модулей приложения

4.1 Накладываемые ограничения

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

1) исходные коды модернизированной АС УЗОР не публикуются;

2) адреса и структура API сервисов не раскрываются;

3) данные, позволяющие идентифицировать узлы исполнения АС УЗОР, не публикуются.

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

4.2 Выбор инструментов разработки

Для разработки программного обеспечения современный мир может предложить множество решений. По данным сайта «Энциклопедия языков программирования» [23], сайт содержит описание более 170 языков программирования. Однако точное количество существующих языков программирования невозможно указать, т.к. каждый год создаются новые языки программирования.

Для каждого языка программирования создаются собственные среды разработки. Для известных и широко распространённых языков программирования перечень сред разработки может содержать более ста сред разработки.

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

Наличие большого количества СУБД позволяет выбрать наиболее подходящую систему управления базами данных, основываясь на требованиях, предъявляемых к программному продукту, где планируется использовать базу данных.

Python - это универсальный современный язык программирования (ЯП) высокого уровня, к преимуществам которого относят высокую производительность программных решений и структурированный, хорошо читаемый код. Синтаксис Питона максимально облегчен, что позволяет выучить его за сравнительно короткое время. Ядро имеет очень удобную структуру, а широкий перечень встроенных библиотек позволяет применять внушительный набор полезных функций и возможностей. ЯП может использоваться для написания прикладных приложений, а также разработки WEB-сервисов.

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

Python является инструментом разработки de facto в связи с тем, что Samba написана с использованием этого языка программирования. Открытость, модульность языка и простота повторного использования программного кода позволяет использовать функционал Samba в УУЗОР. Как на уровне отдельных функций и методов, так и на уровне целых программных модулей.

Для работы над проектом используется Python версии 2.7.12. Интерпретатор этой версии используется на сервере-контроллере домена PI.VOGU. Для реализации необходимых механизмов были установлены на сервер дополнительные пакеты Python:

1) Flask 1.0.2. Данный пакет необходим при реализации модуля API приложения [24];

2) pymongo 3.7.2 [25]. Данный пакет необходим для взаимодействия с СУБД mongodb;

3) pymssql 2.1.4 [26]. Данный пакет необходим для взаимодействия с Microsoft SQL Server 2008 R2.

Flask - это микрофреймворк, написанный на Python. Состоит из таких элементов, как web-сервер Werkzeug, шаблонизатор Jinja. В сущности, это обёртка, объединяющая в себе несколько обособленных проектов

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

Альтернативой Flask является Django [27]. Django - это свободный фреймворк, использующий шаблон проектирования MVC [28]. Этот фрейморк является аналогом таких разработок, как YII2, Laravel, Ruby on Rails, Express.js и т.д. Преимуществом данного фреймворка является широкий встроенный функционал и большое количество подключаемых пакетов расширений.

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

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

Возможной альтернативой является реляционная SQL СУБД, например MySQL или PostgreSQL. Рассмотрим MySQL. Преимуществом такой СУБД является её широкая распространённость, масштабируемость и надёжность.

В целях ускорения разработки приложения, с учётом расширяющихся требований к приложению, в качестве базы данных была выбрана mongodb. Эта СУБД позволяет изменять используемый набор данных «на лету», не изменяя и не теряя при этом исторические данные. MongoDB является одной из наиболее распространённых баз данных, используемых в приложениях с микросервисной архитектурой, а так же в приложениях в активной стадии разработки.

В качестве среды разработки выбрана IDE Jet Brains [29]. Эта среда разработки является многофункциональным программным продуктом, разработанным строго для работы с Python. Среда разработки реализована на языке Java. Интерфейс среды разработки представлен на рисунке 4.1.

Рисунок 4.1 - Интерфейс среды разработки JetBrains PyCharm

Ключевыми возможностями этой среды разработки является:

1) подсветка синтаксиса;

2) быстрое отображение внутренней документации пакетов Python;

3) гибкая настройка окружения;

4) возможность доставки файлов проекта на тестовый сервер;

5) полная поддержка системы версионирования git.

Основным критерием выбора PyCharm является персональное предпочтение этой IDE остальным программным продуктам.

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

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

1) модуль должен запускаться по требуемому расписанию;

2) модуль должен запускаться по запросу.

Составим порядок выполнения действий, необходимых для решения задачи получения данных из БД ИС КИС УЗ.

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

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

3) модуль должен получить требуемые в задании данные;

4) модуль должен передать данные в модуль ядра.

Блок-схема алгоритма работы модуля получения данных представлен на рисунке 4.2.

База данных ИС КИС УЗ представлена решением Microsoft SQL Server. В зависимости от типа задания, необходимо выполнить различные выборки требуемых данных. Пример запроса на выборку данных для создания учётных записей представлен на рисунках 4.3 и 4.4. Критерием выборки является наличие факта прохождения образовательной программы, т.е. быть действующим студентом ВоГУ и идентификатор обучающегося в ИС КИС УЗ. В зависимости от деталей задачи, запрос может быть динамически изменён. Блок-схема алгоритма представлена на рисунке 4.5.

На рисунке 4.4 приведён текст запроса на выборку требуемых данных для определённого обучающегося. Пример запроса на выборку всех записей студентов, проходящих обучение в ВоГУ, представлен на рисунке 4.5.

Рисунок 4.2 - Блок-схема алгоритма работы модуля получения информации

Рисунок 4.3 - Текст запроса выборки данных определённого человека

Рисунок 4.4 - Текст запроса выборки данных всех обучающихся

Рисунок 4.5 - Блок-схема алгоритма составления запроса выборки данных

4.4 Модуль ядра

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

В соответствии с моделью модуля составим блок-схему алгоритма работы модуля. Блок-схема алгоритма представлена на рисунке 4.6.

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

Алгоритм модуля обработки информации при создании записи представлен на рисунке 4.7. Основными особенностями данной процедуры является фильтрация входящих данных на предмет неверно заполненных полей. При формировании объекта User проводятся следующие проверки:

1) заполнение полей. Ключевые поля sn и name не могут быть пустыми. Поле middlename может быть пустым;

2) поля не могут содержать символы @, _, -, “, ”, а так же символ пробела. Исключение проводится для поля middlename и символа дефиса, поля email и символа @;

3) значения поля company не может быть кодом факультета.

4) идентификатор login должен быть уникальным в базе данных модуля ядра.



Рисунок 4.6 - Блок-схема работы алгоритма модуля ядра



Рисунок 4.7 - Блок-схема алгоритма обработки данных модулем ядра

Тип задачи - создание учётных данных

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

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

Рисунок 4.8 - Блок-схема алгоритма работы модуля очереди задач

Внешний сервис/модуль должен обратиться к API, используя HTTP запросы. Модуль определяет тип запроса и извлекает информацию из запроса. На основе полученной информации, модуль выполняет предписанную задачу, на основе моделирования модуля в п.3.2. В соответствии со спецификацией протокола HTTP, внешней сущности передаются итоги работы модуля. Для запросов на постановку и удаление задач используются коды ответов HTTP, для запроса информации ответ расширяется запрошенными данными.

Детализируем процедуру «Определение типа запроса и его обработка». Результат детализации представлен на рисунке 4.9

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

Рисунок 4.9 - Блок-схема алгоритма определения типа запроса и его обработки

4.6 Модуль G Suite

Данный модуль является подключаемым. Неработоспособность или отключение модуля не является критически важным инцидентом.

На модуль накладывается ограничение порядка работы:

1) модуль не может выполнить создание учётной записи G Suite до создания учётной записи домена;

2) после создания учётной записи G Suite, модуль ставит задачу обновления поля email обучающегося. Контактным адресом электронной почты становится почтовый адрес Вологодского государственного университета. Личный адрес электронной почты обучающегося хранится как дополнительный в базе данных модуля ядра и в данных учётной записи G Suite:

3) модуль не может выполнить удаление учётной записи до удаления доменной учётной записи обучающегося, что свидетельствует об отчислении обучающегося;

4) модуль не блокирует электронную почту обучающегося;

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

Для создания модуля обратимся к документации Directory API [14-17, 30]. Для взаимодействия с API необходимо соответствие следующим требованиям:

1) наличие учётной записи Google. Включение сервиса API и создание проекта в API Console;

2) установка клиентской библиотеки;

3) настройка авторизации через протокол OAuth 2.0.

4) формирование сообщений в соответствии с документацией API.

Алгоритм авторизации АС УЗОР в API G Suite представлен на рисунке 4.10.

API G Suite предполагает различные области видимости и прав доступа, иначе scopes, предоставляемых сторонним сервисам. В реализации модуля использованы следующие области:

1) https://www.googleapis.com/auth/admin.directory.group - для решения задач управления группами;

2) https://www.googleapis.com/auth/admin.directory.orgunit - для решения задач управления организационными контейнерами пользователей;

3) https://www.googleapis.com/auth/admin.directory.user - для решения задач управления пользователями.

Рисунок 4.10 - Диаграмма последовательности авторизации АС УЗОР API G Suite

Протокол взаимодействия через API G Suite предполагает обмен сообщениями в JSON формате. С целью правильного формирования JSON сообщений, вместе с документацией к API предоставляется инструмент для генерации JSON сообщения. Внешний вид генератора представлен на рисунке 4.11.

Для решения задачи создания учётной записи используются:

1) метод insert библиотеки реализации;

2) область видимости

3) POST запрос на

Рассмотрим формат и содержимое передаваемого сообщения.



Рисунок 4.11 - Генератор JSON-сообщений для API G Suite

При создании учётной записи необходимо указать ряд необходимых значений:

1) фамилия и имя пользователя;

2) пароль;

3) идентификатор ящика электронной почты.

Для корректного решения задачи создания учётной записи обучающегося необходимо добавить поля:

1) changePasswordAtNextLogin: true - обучающийся обязан сменить пароль учётной записи при первом входе, в целях безопасности;

2) orgUnitPath: “/stud” - контейнер учётных записей обучающихся;

Пример сформированного JSON сообщения представлен на рисунке 4.12

При изменении данных используются:

1) метод update:

2) scope

3) PUT запрос на

Обязательный параметр userKey может быть заменён значением полей primaryEmail. Шаблон JSON сообщения представлен на рисунке 4.13.

Рисунок 4.12 - Пример JSON-сообщения для создания учётной записи

Рисунок 4.12 - Шаблон JSON-сообщения для изменения данных учётной записи

Для удаления пользователей используются:

1) метод delete:

2) scope https://www.googleapis.com/auth/admin.directory.user

3) DELETE запрос на https://www.googleapis.com/admin/directory/v1/users/userKey

Обязательный параметр userKey может быть заменён значением полей primaryEmail. Формирование JSON сообщения не требуется.

Для включения учётной записи в список рассылки используются:

1) метод insert;

2) scope

3) POST запрос на

Обязательный параметр groupKey может быть заменён значением полей groupEmail. Шаблон JSON сообщения представлен на рисунке 4.13.

Рисунок 4.13 - Шаблон JSON-сообщения для включения учётной записи в группу

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

Модуль взаимодействия с доменами реализован на основе модуля ядра. На логическом уровне, модуль взаимодействия с доменами идентичен модулю ядра. Различие в реализации вызвано базой данных. Модуль ядра взаимодействует с собственной базой данных, в то время как модуль домена взаимодействует с Samba.

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

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

Задачи блокирования/разблокирования и удаления учётной записи идентичны по функционалу, с модулем ядра. Выполняется поиск учётной записи домена. В случае успешного поиска, выполняется формирование и передача LDAP сообщения контроллеру домена.

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

Рисунок 4.14 - Пример JSON-сообщения для создания учётной записи

4.8 Модуль взаимодействия с ЛК ВоГУ

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

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

5. Внедрение модулей приложения

Согласно ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания» ввод автоматизированной системы состоит из семи пунктов:

1) подготовка объекта автоматизации к вводу АС в действие;

2) подготовка персонала;

3) комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

4) строительно-монтажные работы;

5) пусконаладочные работы;

6) проведение предварительных испытаний;

7) проведение опытной эксплуатации;

8) проведение приёмочных испытаний.

Анализ результатов проведённых испытаний выявил следующее:

1) модуль получения информации работает в соответствии с заявленными характеристиками. В связи с особенностью IT-инфраструктуры ВоГУ, для работы модуля был настроен отдельный сервер с БД КИС УЗ. Результаты мониторинга базы данных средства СУБД MSQ SQL говорят о большой нагрузке на сервер в момент первоначальной инициализации базы данных центральной базы данных АС УЗОР. При выходе на режим работы обновлений информации, нагрузка на базу данных представляется незначительной. Работа модуля возможна на действующем сервере КИС УЗ, при условии первоначальной инициализации АС УЗОР в часы минимальной нагрузки на БД КИС УЗ.

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

2) модуль ядра АС УЗОР работает в соответствии с заявленными характеристиками. Функциональные возможности модуля полностью соответствуют требованиям, предъявляемым к модулю. Нагрузка на базу данных в режиме инициализации системы в пределах нормы.

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

3) работа модуля очереди задач не соответствует заявленными характеристиками. В ходе тестового запуска выявлена проблема потери заданий. Требуется дополнительная проработка механизма удаления задач из очереди задач.

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

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

5) взаимодействие с сервисом ЛК ВоГУ было реализовано в тестовом режиме. На основе реализации подтвержден правильный выбор архитектуры системы, направленный на разбиение функционала системы на отдельные сервисы. Опытным путём доказана жизнеспособность микросервисной архитектуры системы с взаимодействием между элементами через очередь задач.

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

6) в ходе реализации и последующей апробации модуля взаимодействия с G Suite выявлено большое количество элементов, влияющих на работу взаимодействие АС УЗОР и сервисами G Suite. Библиотеки API реализованы с использование Python 3, реализация библиотек на ЯП Python 2.7 объявлена deprecated и более недоступна [32]. В связи с этим, необходимо использовать Python 3 в разработке модуля. Работа модуля предполагает взаимодействие с оператором на первоначальном этапе, в ходе инициализации системы. Необходимость оператора при запуске вызвана особенностями протокола OAuth 2.

Тестовый запуск модуля в целом показал положительные результаты. Выявлены критические проблемы в реализации программного модуля в контексте определения полей JSON-сообщений. Получена рекомендация на доработку модуля и повторное тестирование.

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

ЗАКЛЮЧЕНИЕ

В представленной выпускной квалификационной работе были выполнены следующие задачи:

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

2) выполнено комплексное моделирование АС УЗОР версии 1.х.х, а так же его заявленных компонентов.

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

4) выполнена программная реализация системы и её модулей.

5) выполнен тестовый запуск системы на тестовом стенде, в среде ВоГУ. Выполнен анализ тестового запуска, получены рекомендации к доработке модулей системы.

Выполнены задачи, поставленные в пункте 1.7.

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

2) в рамках задачи разработки и реализации API модуля задач, был реализован функционал сообщений сброса паролей учётных записей. Функционал прошёл проверку на тестовом стенде, с использованием тестовой версии сервиса ЛК ВоГУ. Подтверждена работоспособность функционала сброса паролей учётных записей;

3) реализован функционал блокирования/разблокирования учётных записей в части сервисов ВоГУ.

4) реализовано взаимодействие модернизированной системы и набором сервисов G Suite.

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Правила приёма 2019-2020 [Электронный ресурс] // PRIEM.VOGU35.RU: Приёмная комиссия Вологодского государственного университета

2. Главная страница [Электронный ресурс] // DO.VOGU35.RU: Портал электронных образовательных технологий ВоГУ

3. Главная страница [Электронный ресурс] // E-LEARNING.VOLOGDA-UNI.RU: Учебная среда педагогического образования ВоГУ

4. Комплексная информационная система управления учебным заведением Модус [Электронный ресурс] // YARINSI.RU: Информационные системы

5. Личный кабинет студента ВоГУ [Электронный ресурс]

6. A PHP LDAP Package for humans. [Электронный ресурс] // GITHUB.COM: GitHUB, Inc.

7. Samba: opening windows to a wider world [Электронный ресурс]

8. Lightweight Directory Access Protocol (LDAP): The Protocol [Электронный ресурс] // IETF Documents

9. About Moodle [Электронный ресурс] //MOODLE.ORG: Moodle - Open-source learning platform.

10. Core APIs [Электронный ресурс] //DOCS.MOODLE.ORG: Moodle documentation.

11. Delete user with API [Электронный ресурс] // MOODLE.ORG: General developer foru

12. What's the right way to delete users through the API? [Электронный ресурс] // MOODLE.ORG: General developer forum

13. G Suite for Education [Электронный ресурс] // Google for Education

14. Directory API: User Accounts [Электронный ресурс] // G Suite admin SDK. Directory API.

15. Directory API: Custom User Fields [Электронный ресурс] // G Suite admin SDK. Directory API.

16. Directory API: Organizational Units [Электронный ресурс] // G Suite admin SDK. Directory API.

17. Directory API: Groups [Электронный ресурс] // G Suite admin SDK. Directory API.

18. Free individual licenses for students and faculty members [Электронный ресурс] // JetBrains Store

19. Office 365 Education [Электронный ресурс] // Microsoft: Microsoft education

20. ramus [Электронный ресурс] // GITHUB.COM: Vitaliy-Yakovichuk/ramus

21. GNU General Public License [Электронный ресурс] // Операционная система GNU

22. Р 50.1.028 - 2001. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования [Электронный ресурс]: введ.2.06.2001 // Техэксперт: инф.- справ.система/ Консорциум «Кодекс»

23. Энциклопедия языков программирования [Электронный ресурс]

24. What the flask? [Электронный ресурс] //HABR.COM

25. PyMongo Documentation [Электронный ресурс] // API documentation fo MongoDB drivers

26. Docs > pymssql [Электронный ресурс] // PYMSSQL

27. The Web framework for perfectionists with deadlines [Электронный ресурс] // Djangoproject.com

28. Django [Электронный ресурс] // RU.WIKIPEDIA.ORG: Википедия свободная энциклопедия

29. PyCharm - Интеллектуальная Python IDE [Электронный ресурс] // JetBrains.

30. API reference [Электронный ресурс] // Google Developers

31. Messaging that just works - RabbitMQ [Электронный ресурс]

32. Deprecated Python Versions [Электронный ресурс]

Размещено на allbest.ru