Размещено на http://www.allbest.ru/

Аннотация

информационный приложение программный приемный комиссия

Целью данной выпускной квалификационной работы является разработка информационной системы поддержки принятия решений приемной комиссией НИУ ВШЭ, которая позволит получать, хранить и обрабатывать данные об абитуриентах. Данное решение будет использоваться в приемной комиссии университета.

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

Приложение создано с использованием принципов клиент-серверной архитектуры и развернуто на внутренних серверах университета. Основным языком программирования был выбран JavaScript и фреймворки React.js и Node.js. Разработанная информационная система имеет следующие функции: импорт и экспорт файлов с информацией об абитуриентах в формате xls, представление данных об абитуриентах в виде таблицы, заполнение данных по абитуриентам, синхронизация таблиц для каждой действующей сессии в режиме реального времени, вывод статистической информации о конкурсной ситуации, разделение прав доступа к системе, проведение операций с таблицами (сортировка, фильтр, поиск и т.п.).

Объем отчета по выпускной квалификационной работе, за исключением приложения, составляет 48 страниц. Количество иллюстраций в работе - 20, использованных источников - 48.

Введение

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

Каждый год число абитуриентов растет, соответственно растет и количество информации, которую надо обрабатывать, хранить и обеспечивать удобный доступ для сотрудников приемной комиссии. Создание автоматизированной информационной системы - наверное, одно из лучших решений этой проблемы [2]. Такая система могла бы взять на себя много рутинных задач, всегда поддерживала бы информацию в актуальном виде на всех компьютерах сотрудников и помогала в принятии решений.

На сегодняшний день основные рабочие процессы сотрудников приемной комиссии Национального Исследовательского Университета “Высшая школа экономики” (НИУ ВШЭ) проходят в программном обеспечении Microsoft Office Excel [13]. В этих таблицах хранятся данные об абитуриентах, производятся операции над ними, ежедневно эти данные нужно вручную актуализировать и т.д. Такой подход неудобен, медленен и может стать причиной многих ошибок. Для решения этой проблемы было решено разработать веб-приложение для поддержки принятия решений приемной комиссией НИУ ВШЭ.

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

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

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

Глава 1. Обзор и анализ предметной области

Обзор и анализ литературы

Документ правила приема в НИУ ВШЭ [11] и информационная модель централизованной приемной кампании в российских вузах [3] подробно описывает все необходимые для этой работы термины, а также помогает разобраться в непростом и уникальном процессе отбора абитуриентов как в этом университете, так и в России в целом.

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

В некоторых работах [5, 8, 12] делается вывод, что приемная комиссия является одним из важнейших подразделений университета, местом, где начинаются основные взаимоотношения абитуриента с ВУЗом, поэтому её работа требует особенного внимания. Согласно работе Рубцовой и Хорошаевой [12], приемной комиссии вуза приходится решать широкий круг задач,

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

Другие исследователи [6, 9] выражают согласие с этой точкой зрения, Автоматизация работы отдела приемной комиссии существенно облегчит, увеличит скорость и правильность обработки информации; поможет избежать дублирования информации и процессов; урегулирует согласованность действий подразделений между собой.

Рубцова и Хорошаева в своей статье [12] приводят результаты исследований проблемы выбора программного обеспечения для проведения приемной кампании в университетах. Во-первых, информационная система по администрированию приемной кампании должна быть достаточно гибкой, легко подстраивающейся под изменяющиеся условия, потому что даже в одном университете правила и порядок приема абитуриентов меняются из года в год. Во-вторых, в каждом учебном заведении есть свои особенности проведения кампании, уникальные процессы (например, Зеленая волна в НИУ ВШЭ[14]). Поэтому нет такой универсальной информационной системы, которая подошла бы всем ВУЗам. Авторы задаются вопросом «лучший выбор - это купить готовый продукт, максимально адаптированный к потребностям приемной комиссии, или разработать его специалистами самого ВУЗа?» (стр. 2) Чаще всего даже самый подходящий продукт на рынке не будет учитывать всех особенностей процессов приема студентов, поэтому в любом случае будет нуждаться в доработке. Поэтому самым выгодным вариантом является разработка своей собственной информационной системы средствами штатных специалистов или студентов. По словам автора, это хорошо еще и тем, что,

«Если в ВУЗе работает специалист по разработке ПО, то проблемы долговременных доработок программного обеспечения, как правило, не возникают. Данный программист всегда будет знать о последних изменениях порядка и правил приема и будет адаптировать под них программный продукт и, как следствие, не возникнет вопросов с интеграцией модуля в систему автоматизации учебного процесса» (стр. 2)

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

Актуальность работы

Ежегодный мониторинг качества приема в ВУЗы от научно исследовательского университета Высшей школы экономики за 2018 год [10] показывает, что с каждым годом количество абитуриентов неуклонно увеличивается, в отличии от мирового тренда [15], где в данный момент наблюдается устойчивое плато, и в кампании прошлого года количество абитуриентов по всей России составило около полумиллиона человек.

Поэтому управление приемом в современное учебное заведение требует сбора, обработки и анализа достаточно больших объемов различной информации об абитуриентах. Использование средств информационных технологий позволяет успешно решать подобные задачи [2].

Описанный подход не является новым в этой сфере. Многие университеты используют в работе своей приемной комиссии информационные системы определенной степени автоматизации. Проблема заключается в том, что процессы приема в разные университеты отличаются. В НИУ ВШЭ они очень специфичны, по сравнению с другими ВУЗами. Это является причиной того, что нет такой информационной системы, которая бы идеальна подошла для приемных процессов нашего университета.

Постановка задач на проект

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

· Определить требования к информационной системе и неавтоматизированные процессы

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

· Спроектировать и разработать информационную систему максимально покрывающую неавтоматизированные процессы

· Развернуть веб-приложение на внутреннем сервере университета

· Протестировать разработанную информационную систему

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

Вывод к главе 1

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

Глава 2. Методы, инструменты и технологии

В данном разделе будет представлено описание методов, инструментов и технологий, использованных в этой работе. Будут приведены причины, согласно которым их использование будет уместным и обоснованным.

Методы

Основным методом, который будет использоваться в этой работе, является итеративная инкрементная модель разработки программного обеспечения [1]. Основная идея этого метода заключается в разработке системы с помощью повторяющихся циклов (итераций) и шагов внутри цикла (инкрементов), что позволяет разработчикам программного обеспечения использовать то, что было сделано в ходе разработки более ранних частей или версий системы.

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

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

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

Инструменты и технологии

Технология хранения данных. SQL vs NoSQL

При выборе технологии базы данных существует два основных направления: SQL (Structured Query Language)[48] и NoSQL (Not Only SQL) [16], реляционные и нереляционные базы данных (БД). Принципиальные отличия между ними лежат не только в том, как они хранят информацию, но и в том, как они спроектированы и какие типы данных поддерживают.

Реляционные БД хранят данные в структурированном формате, они сгруппированы в таблицах, формат которых определяется еще на этапе проектирования.

В нереляционных БД все устроено по-другому. Речь может идти об объектах с произвольным набором атрибутов. То, что в реляционной БД будет разбито на несколько взаимосвязанных таблиц, в нереляционной может храниться в виде целостной сущности.

Поводом для выбора реляционной БД могут стать следующие две причины: необходимость соответствия базы данных требованиям ACID (Atomicity, Consistency, Isolation, Durability -- атомарность, непротиворечивость, изолированность, долговечность) [17], что позволяет уменьшить вероятность неожиданного поведения системы и обеспечить целостность базы данных; данные, с которыми вы работаете, структурированы, при этом структура не подвержена частым изменением.

А NoSQL выбирают в следующих ситуациях.

1. Хранение больших объёмов неструктурированной информации. База данных NoSQL не накладывает ограничений на типы хранимых данных. Более того, при необходимости в процессе работы можно добавлять новые типы данных.

2. Быстрая разработка. Если вы разрабатываете систему, используя agile-методы [18], применение реляционной БД способно замедлить работу. NoSQL базы данных не нуждаются в том же объёме подготовительных действий, которые обычно нужны для реляционных баз.

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

Следующим шагом является выбор системы управления базой данных (СУБД) [19]. MongoDB является одной из самых популярных СУБД для NoSQL баз данных. Еще одним плюсом стало то, что MongoDB [20] принято использовать в сочетании с Node.js [21], выбранным для данного проекта фреймворком серверной части. И это не просто так, ведь в случае использования этой СУБД данные в базе хранятся в формате JavaScript Object Notation или JSON [22]. Данный формат хранит в себе набор свойств объекта в формате «ключ: значение», при этом значением может является как число или строка, так и объект или даже массив объектов (рис. 1). Это формат описания объектов, с которым работает JavaScript, поэтому количество преобразования данных к нужному виду сведено к минимуму.

Рисунок 1. Пример файла формата JSON

Выбор языка программирования для клиентского приложения

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

React

React.js [23] -- созданный компанией Facebook фреймворк для разработки пользовательских интерфейсов. Для разработки приложения был использован именно React.js, т. к. он имеет несколько ключевых особенностей, которые помогают улучшить работу приложения.

Пожалуй, главная отличительная особенность React - виртуальное дерево Document Object Model (DOM) [24], благодаря ему фреймворк сам понимает, что изменилось на данной странице при каком-либо действии и обновляет только эту часть страницы. Например, рассмотрим простое приложение, которые считает количество нажатий на кнопку. Даже если на странице будут другие элементы, React будет обновлять именно ту часть, где выводится количество нажатий, а все остальное останется нетронутым.

Вторая отличительная черта - это разделение всей страницы на отдельные компоненты. Для языка JavaScript есть знаменитое выражение: “Все - объект”, потому что любой элемент языка является объектом. Немного перефразировав, можно сказать, что в React.js “Все - компонент”, что не является абсолютной истиной, но хорошо отражает идею и суть этого фреймворка. Идеология состоит в том, что разрабатывать элементы страницы надо так, чтобы потом их можно было использовать в любом другом месте сайта или вообще в другом проекте. Такая декомпозиция задач позволяет сконцентрироваться на небольших задачах, которые в совокупности являются решением общей, более сложной задачи.

Третьей особенностью можно считать жизненный цикл компонента, схема жизненного цикла отображена на рисунке 2.

Рисунок 2. Схема жизненного цикла React компонента

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

Все компоненты существуют как бы отдельно друг от друга, что позволяет отображать информацию частично, даже если в каких-то объектах произошла ошибка. Все запросы к серверу происходят по технологии Asynchronous JavaScript and XML (AJAX) [25], в противном случае использование React.js было бы лишено всякого смысла.

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

Ant.design

Помимо фреймворка React.js, который контролирует то, как ведут себя компоненты, была использована библиотека готовых React компонентов Ant.design [26] -- она содержит многие основные компоненты, например, управляющие элементы (кнопки, выпадающие списки, вкладки), элементы для демонстрации данных (таблицы, карточки, подсказки), элементы разметки и многое другое. Данные компоненты очень гибкие, легко видоизменяются и имеют понятный дружественный пользователю дизайн (рис. 3).



Рисунок 3. Пример страницы, разработанной с использованием Ant.design

Библиотеки и фреймворки для серверного приложения

Node.js

Node.js [21] - это серверная платформа для работы с JavaScript через движок V8. JavaScript выполняет действие на стороне клиента, а Node -- на сервере. С помощью Node можно писать полноценные приложения. Node умеет работать с внешними библиотеками, вызывать команды из кода на JavaScript и выполнять роль веб-сервера. Его преимущество в том, что с Node проще масштабироваться. При одновременном подключении к серверу тысяч пользователей Node работает асинхронно, то есть ставит приоритеты и распределяет ресурсы грамотнее. Java [27] же, например, выделяет на каждое подключение отдельный поток. Пакетная экосистема Node.js npm является самой большой экосистемой библиотек с открытым исходным кодом в мире. Благодаря этому все решения для распространенных задач всегда можно подключить в качестве модуля, а не писать самому, тратя на это много времени.

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

Express.js

Express.js [7], или просто Express, фреймворк web-приложений для Node.js, реализованный как свободное и открытое программное обеспечение под лицензией MIT [28]. Он спроектирован для создания веб-приложений и Application Programming Interface (API) [29]. Де-факто является стандартным каркасом для Node.js. Автор фреймворка, TJ Holowaychuk, описывает его как созданный на основе написанного на языке Ruby каркаса Sinatra, подразумевая, что он минималистичен и включает большое число подключаемых плагинов.

Выбирая фреймворк Express, получаем популярный программный стек веб-разработки MEAN (MongoDB, Express.js, Angular.js/Vue.js/React, Node.js).

Mongoose

Mongoose [30] - это библиотека JavaScript, часто используемая в приложении Node.js с базой данных MongoDB. Mongoose - это ODM (Object Document Mapper - объектно-документный отобразитель) [31]. Это означает, что Mongoose позволяет вам определять объекты со строго-типизированной схемой, соответствующей документу MongoDB.

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

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

Инфраструктурные инструменты

Docker

Во время разработки приложения время от времени возникает необходимость разворачивать готовое приложение и его окружение на удаленном сервере. Инструмент Docker [32] отлично подходит для этих целей. Это программное обеспечения для быстрого развертывания приложений и управления ими. При использовании Docker создается так называемый контейнер, внутри которого находится какая-либо часть приложения, также существует docker-композиция, которая описывает в каком порядке и с какими параметрами должны запускаться элементы приложения, что позволяет развернуть приложение на сервере одной командой в терминале этого сервера. В данной работе он использовался для быстрого поднятия серверной и клиентской части проекта.

BitBucket

Для хранения кода и файлов, а также для удобной организации командной разработки приложения использовался BitBucket.

BitBucket [33] -- веб-сервис для хранения репозиториев, работает по системе контроля версий Git [34]. В используемом сервисе существует возможность хранения кода приложения в приватном репозитории, т. е. недоступным никому, кроме людей, участвующих в проекте. Система контроля версий Git позволяет совместно разрабатывать программное обеспечение, а также клонировать весь проект на любой компьютер при наличии необходимых прав доступа.

Вывод к главе 2

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

Глава 3. Практическая часть

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

Формализация требований к ИС

Интервью с представителем от приемной комиссии помогло выявить и формализовать требования к разрабатываемой информационной системе. Основной проблемой сотрудников call-центра комиссии является отсутствие такой информационной системы, которая предоставляла бы доступ к единой базе информации об абитуриентах, автоматически обновляла бы её и поддерживала в актуальном состоянии на каждом компьютере сотрудника. На данный момент их основные рабочие процессы протекают в ПО Microsoft Excel. Эти таблицы без всяких сомнений являются очень мощным инструментом с огромным спектром возможностей, но слабо подходят для децентрализованной обработки информации о студентах. Каждый день работникам приходится вручную синхронизировать информацию в своих таблицах с присылаемыми обновленными таблицами. Такой подход является причиной ошибок и неточностей, и разрабатываемая система сможет изменить эту ситуацию.

Реализация базы данных

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

Для создания прототипа была спроектирована БД для хранения сущностей «Абитуриент», «Образовательная программа», «Пользователи» и др. Сущность абитуриент содержит следующие поля: фамилия, имя, отчество, выбранные ОП, баллы за ЕГЭ, комментарий о студенте, приоритетная ОП и другие. Поля «выбранные ОП» и «Приоритетная ОП» ссылаются на сущность «Образовательная программа», которая имеет следующие поля: короткое имя, полное имя, код. Сущность «Пользователи» используется для хранения логинов и хешированных значений паролей пользователей и прав доступа, выданных данному пользователю. MongoDB автоматически присваивает каждой хранимой записи уникальные идентификаторы, использующиеся для создания ссылок и поиска. Конечная реализация БД содержит эти основные сущности, но с расширенным количеством атрибутов, что позволяет хранить всю необходимую для работы информацию об абитуриенте.

Следующие изображения являются примерами создания в MongoDB схем сущностей «Образовательная программа» для хранения данных об образовательных программах и «Абитуриент» для хранения информации об абитуриентах.

Основными параметрами (рис. 4) для учебной программы являются: полное имя, короткое имя (аббревиатура) и код (аббревиатура на латинице для возможности обращение к ней в коде программы).

Рисунок 4. Структура, описывающая учебную программу

Основными параметрами (рис. 5) для абитуриента являются: имя, фамилия, отчество, выбранные учебные программы, количество баллов ЕГЭ, комментарий работника приемной комиссии и id приоритетной учебной программы.

Рисунок 5. Структура, описывающая абитуриента

Архитектура проекта

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

Рисунок 6. Многоуровневая архитектура клиент-сервер

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

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

Инфраструктура проекта

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

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

Разработка клиентской и серверной части ведется на локальном компьютере, но иногда возникает необходимость посмотреть, как это будет работать на удаленном сервере или продемонстрировать проект заказчику. Специально для проекта были выделены ресурсы на университетских серверах, именно там и будет происходить развертывание проекта. Для этого необходимо выполнить подключение по SSH, обновить версию проекта и развернуть его. С помощью контейнеризации Docker и небольшого скрипта все эти действия выполняются в пару команд (рис. 7)

Рисунок 7. Скрипт deploy.sh

Он выполняет следующие действия:

1. Останавливает и удаляет все запущенные контейнеры Docker

2. Обновляет репозиторий проекта и переходит на нужную ветку (на данный момент develop)

3. Строит новый образ Docker для клиентского и серверного приложения на основе созданной конфигурации

4. Запускает эти образы

Таким образом приложения работают в независимых друг от друга контейнерах, которые можно легко создать, запустить, автоматически перезапускать в случае падений, масштабировать и следить за их работой (рис.8). Этот подход гарантирует стабильную работу для всего проекта.

Рисунок 8. Состояние контейнеров

Клиентское приложение

Подготовка к разработке

Первым шагом на пути к созданию клиентского приложения была задача - настроить рабочее окружение для проекта. В Front-end [35] разработке это подразумевает под собой создание конфигурации проекта (обычно это делается с помощью инструмента npm), необходимо указать первичные настройки, установить необходимые для разработки библиотеки и указать зависимости и т.д. Но, когда разработка происходит на React, можно воспользоваться удобным шаблоном от Facebook [36] (так называемым boilerplate'ом), который уже содержит предустановленные настройки, делается это с помощью команды `npx create-react-app my-app'.

Однако, такой подход не решает все проблемы, после создания проекта из шаблона необходимо настроить под собственные требования следующие два инструмента - Webpack[37] и Babel[38]. Webpack - самый популярный на данный момент сборщик JavaScript проектов, его функциональность очень широка и может изменяться в зависимости от конфигурации. Главной его задачей является разрешение всех зависимостей (рис. 9) в проекте таки образом, чтобы собрать готовые статические пакеты (например, объединение всех js модулей в один скрипт и т.д.). Так же он может собирать и другие необходимые для веб-страницы ресурсы, такие как HTML [39], CSS[40], картинки и много другое. Следующим идет Babel, так называемый транспайлер (тип компилятора, который использует исходный код программы, написанной на одном языке программирования, в качестве исходных данных и производит эквивалентный исходный код на другом языке программирования) языка JS. Основная его работа - переводить код самых современных стандартов JS (ES6+ [41]) в стандарты более старые (ES5 [42]), но хорошо поддерживаемые всеми браузерами. При разработке на React он еще используется и для компиляции в код JavaScript кода JSX (JSX код позволяет использовать язык разметки, подобный языку HTML, прямо в JS коде). Грамотная настройка этих инструментов позволит подключить и использовать библиотеку Ant.design.

Рисунок 9. Webpack

Процесс разработки

Пользовательский интерфейс

Следующая задача - изучить, что собой представляет Ant.design, одна из наиболее известных библиотек готовых компонентов для React. Использование библиотек готовых компонентов очень важно, это позволяет не изобретать заново различные широко используемые компоненты пользовательского интерфейса, такие как выпадающие списки, кнопки, таблицы и т.д. Такие библиотеки предоставляют программисту на выбор все, что может пригодится, API таких компонентов хорошо проработан, они гибкие, легко настраиваемы и персонифицируемы, и, что самое главное, уже работают «из коробки». Такой подход экономит сотни часов работы.

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

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

Аутентификация

Процесс аутентификации в приложении реализован следующим образом: пользователь заходит в приложение, если во время текущей сессии он уже проходил авторизацию, то он беспрепятственно попадает в само приложение, если нет, то он попадает на страницу аутентификации; когда пользователь вводит логин и пароль, на сервер отправляется запрос, цель которого получить строку ключ для хеширования пароля для его безопасной отправки вместе с логином на сервер, далее сервер определяет - существует ли пользователь с таким логином в системе и верно ли указан пароль, сервер возвращает так называемый токен (идентификатор) сессии, который сохраняется в браузере (для сохранения используется sessionStorage из API HTML5, это хранилище, которое позволяет сохранять данные в браузере в виде пар «ключ - значение» до того момента пока не закончится сессия, то есть будет закрыто окно браузера, или будет нажата кнопка «Выход», в таком случае токен сессии удаляется из хранилища); далее каждый запрос на сервер из приложения содержит данный токен, что позволяет не только определить инициатора определенного действия, но и проверить, имеет ли он на это право. Такой подход реализует минимально необходимые требования к безопасности приложения, обеспечение дополнительной безопасности присутствует в планах разработки.

Изменения в режиме реального времени

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

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

Для реализации этого механизма в клиентском приложении была выбрана библиотека Socket.io[43, 44], часто использующаяся в связке с компонентными фреймворками (React, Vue, Angular и т.д.). Socket.io - JavaScript библиотека, позволяющая обмениваться данными между клиентом и сервером в режиме реального времени, а так же реагировать клиентскому приложению на серверные события. Главным образом она использует протокол WebSocket, но могут так же использоваться протоколы Adobe Flash sockets, JSONP или AJAX. После того, как между клиентом и сервером будет установлено соединение, сервер, не полагаясь на запросы клиента, самостоятельно инициирует передачу данных.

Реализация на клиенте подразумевает создание и настройку клиента Socket.io, который будет подключаться к модулю Socket.io на сервере и программирование поведения при получении данных с сервера. Для этого нужно:

1. Импортировать и вызвать главную экспортируемую функцию из модуля socket.io-client и передав в неё данные о сервере

import openSocket from 'socket.io-client';

const socket = openSocket('http://localhost:8000');

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

socket.on('dataUpdated', updatedData => {

updateTable(updatedData);

}

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

Инструменты работы с таблицей

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

Большинство этих инструментов легко реализуется на клиенте с использованием средств Ant.design. Но у такого подхода есть один минус. Данной информационной системе предстоит работать с большим объемом данных, например, если выбрать раздел «Все студенты», то нужно будет выводить и обрабатывать данные тысяч абитуриентов. А так как наша система предполагает пониженные требования к аппаратному обеспечению для клиентских приложений, то такой вариант явно не подходит. Это значит, что, во-первых, фильтрацию, сортировку и поиск необходимо выполнять на сервере и присылать на клиент уже обработанные данные, а во-вторых, данные будут выводиться на клиенте постранично с возможностью регулирования количества записей на одной странице, это значит, что сервер будет присылать на клиент только те данные которые будут выведены на страницу (например, если всего имеется сто студентов, на одной странице выводится пятьдесят записей и нужно открыть вторую страницу, то придут данные только второй половины списка).

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

Статистика

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

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

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

Обновление данных в базе

Одной из важных задач разрабатываемой системы является ежедневное обновление данных об абитуриентах. На данный момент синхронизация данных происходит вручную. Каждый день на протяжении всей приемной кампании работникам приходят новые таблицы в формате Microsoft Office Excel, содержащие данные о новых абитуриентах, пришедших за прошлый день, которых предстоит обработать, а также измененные данные о существующих абитуриентах, например, когда кто-то донес оригинал диплома о школьном образовании и т.д. Данный процесс необходимо автоматизировать, это сохранит работникам время и поможет избежать ошибок. Эти таблицы необходимо загрузить на сервер, обработать содержащиеся внутри данные, сохранить новые записи в базу данных или обновить существующие.

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

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

Рисунок 10. Модальное окно загрузки Excel файла

Серверное приложение

Процесс разработки

Разработка API

Основной задачей серверного приложения является получение запросов с клиента, взаимодействие с базой данных, подготовка и обработка данных и отправка их на клиент. Для взаимодействия клиента с сервером было создано несколько конечных точек (адресов для запросов) с разными url, каждый из которых интерпретируется сервером как определенное действие, которое надо выполнить, и запрограммировано соответствующее поведение для них. Далее будут представлены примеры некоторых запросов.

· Для структуры, описывающей абитуриента:

o Запрос для создания записи об абитуриенте. Тип запроса: POST. Клиент отправляет серверу данные об абитуриенте, т. е. все значения для полей структуры описывающей абитуриента, сервер же в свою очередь создает в базе запись об этом абитуриенте, подставляя полученные от клиента значения. (Алгоритм - Приложение А1)

o Запрос для получения всех данных этого типа из базы. Тип запроса: GET. При обращении по адресу, который соответствует этому запросу, сервер возвращает записи обо всех абитуриентах, имеющихся в базе данных.

o Запрос для получения объекта по id. Тип запроса: GET. Адрес для данного запроса оканчивается на идентификатор абитуриента, благодаря чему сервер возвращает запись только об одном абитуриента, имеющем данный id.

o Запрос для получения всех абитуриентов определенной программы. Тип запроса: GET. Адрес для данного запроса оканчивается на идентификатор учебной программы, благодаря чему сервер возвращает запись только об абитуриентах, которые подали документы на определенную программу.

o Запрос для изменения комментария к абитуриенту по его id. Тип запроса: POST. Клиент отправляет серверу данные в которых содержится id абитуриента и текст комментария, сервер же в свою очередь изменяет текст комментария абитуриента на новый текст, присланный клиентом.

o Запрос на изменение данных об определенном абитуриенте по его id. Тип запроса: POST. Клиент отправляет серверу данные в которых содержится id абитуриента и новые данные об этом абитуриенте, запрос может содержать любой набор свойств этой структуры, сервер же в свою очередь изменяет свойства в записи абитуриента на новые значения, присланные клиентом.

· Для структуры, описывающей учебную программу:

o Запрос для создания структуры. Тип запроса: POST. Клиент отправляет серверу данные об учебной программе, т. е. все значения для полей структуры описывающей учебной программу, сервер же в свою очередь создает в базе запись об этой учебной программе, подставляя полученные от клиента значения. (Алгоритм - Приложение А1)

o Запрос для получения всех данных этого типа из базы. Тип запроса: GET. При обращении по адресу, который соответствует этому запросу, сервер возвращает записи обо всех учебных программах, имеющихся в базе данных.

o Запрос для получения объекта по id. Тип запроса: GET. Адрес для данного запроса оканчивается на идентификатор учебной программы, благодаря чему сервер возвращает запись только об одной учебной программе, имеющей данный id.

o Запрос для получения объекта по коду учебной программы. Тип запроса: GET. Адрес для данного запроса оканчивается на код учебной программы, благодаря чему сервер возвращает запись только об одной учебной программе, имеющей данный код.

Изменения в режиме реального времени

Для того, чтобы описанный ранее подход заработал, необходимо поддержать его на серверном приложении. Для этого тоже будет использоваться библиотека Socket.io.

Примерный план действий такой:

1. Импортировать модуль socket.io

const io = require('socket.io')();

2. Далее нужно сообщить на каком порту ожидать подключения клиент

const port = 8000;

io.listen(port);

console.log('listening on port ', port);

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

function DBUpdated (data) {

io.emit('dataUpdated', data)

}

Таким образом, когда на каком-то из клиентов произойдут изменения и данные в базе обновятся, для каждой открытой сессии будет вызвана данная функция обработчик, которая вызовет отправку на клиент события dataUpdated с обновленной датой.

Аутентификация

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

Инструменты работы с таблицей

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

Для этих операций используются встроенные функции библиотеки mongoose. Например, для сортировки используется функция sort, которая выглядит следующим образом array.sort{fieldName: 1, fieldName: -1, …}. Так, при использовании на клиенте инструмента «Сортировать по имени по возрастанию» посылается специальный запрос, содержащий наименование выбранной образовательной программы, поле, по которому производится сортировка и направление сортировки - по возрастанию или по убыванию. На сервере вызывается функция sort со следующими параметрами students.sort{name: -1, userScore: 1}, как результат на клиент отсылаются уже отсортированные по имени от а до я, а затем по баллам ЕГЭ данные.

Постраничный вывод результатов реализован следующим образом, на клиенте внизу таблицы присутствует элемент управления страницами следующего вида (рис. 11).

Рисунок 11. Элемент управления страницами

При нажатии на который на сервер отсылается запрос, содержащий необходимую страницу и текущую конфигурацию максимального числа выводимых на странице записей. Далее на сервере снова используются встроенные функции mongoose, такие как limit(m) и skip(n), они пропускают n элементов и устанавливают предел в m элементов при поиске записей, таким образом на клиент отсылаются ровно те m записей, что должны отображаться на запрошенной странице. Такой запрос с использованием mongoose имеет следующий вид

Abiturient.find({}).sort(req.body.sort ? req.body.sort : {}).skip(countOfSkipElements).limit(countOnPage).populate('programs').exec()

Алгоритм изображен в Приложении А3.

Статистика

Реализация статистических расчетов на серверной стороне не является сложной задачей. Основная цель - посчитать запрошенные данные и отправить обратно на клиент.

Так, например, при запросе минимального проходного балла с клиента приходят данные о наименование образовательной программы и лимите n мест на этой программе. Далее абитуриенты, подавшие документы на эту программу, сортируются по убыванию баллов ЕГЭ и отбирается n абитуриентов сверху списка, количество баллов по ЕГЭ последнего студента в списке характеризует минимальный проходной балл образовательной программы. Полученные данные отсылаются на клиентское приложение.

Алгоритм изображен в Приложении А4.

Обновление данных в базе

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

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

Для решения этой задачи используется популярная библиотека для Node.js - Node XLSX. Она позволяет парсить Excel таблицы в JavaScript массивы с данными и создавать из таких массивов Excel таблицы.

Пример использования Node XLSX:

import xlsx from 'node-xlsx';

// Or var xlsx = require('node-xlsx').default;

// Parse a buffer

const workSheetsFromBuffer = xlsx.parse(fs.readFileSync(`${__dirname}/myFile.xlsx`));

Алгоритм изображен в Приложении А5.

Тестирование

Тестирование разрабатываемой информационной системы производилось после этапа разработки с использованием подхода ручного [45] системного [46] тестирования. Модульное и интеграционное тестирование не проводилось и не автоматизировалось в связи с ограничениями во времени и ресурсах.

...