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

Smirnov D. P., Dedovich T. G. Analysis and selection of modern tools and technologies for the development of a learning management system. System Analysis in Science and Education, 2022;(1):105–116(In Russ). Available from:

В современном мире, наравне с очным образованием все большую роль начинает играть электронное обучение. По данным на 2021 год, в связи с COVID-19 , в разных сферах образования доля электронного обучения колеблется от 30% до 40% [1]. Для контроля над электронным образованием в университетах и школах используются системы управления обучением ( LMS ). До недавнего времени такие системы справлялись со своими обязанностями, однако в связи с резким повсеместным переходом на электронное образование стало появляться все больше требований к таким системам. Добавление новых компонент в системы либо является нетривиальной задачей и требует много времени, либо невозможно.

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

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

• -    модернизации системы контроля и оценивания знаний;

• -    специализированных форм для проверки доказательств;

• -    модулей-тренажеров для изучения алгоритмов;

• -    учета очных занятий.

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

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

Нефункциональные требования к разрабатываемой системе

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

Расширяемость:

• -    платформонезависимость системы;

• -    возможность добавить новый функционал без изменения высокоуровневой архитектуры;

• -    масштабируемость системы для возможности простого увеличения количества пользователей;

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

Производительность:

• -    высокая скорость работы системы;

• -    низкие аппаратные и программные требования к компьютеру студента.

Безопасность:

• -    наличие защиты от взломов и основных типов уязвимостей веб-приложений;

• -    высокий уровень защиты от сбоев с возможностью восстановления (система резервного копирования);

• -    отслеживание изменений, вносимых пользователями при работе в системе.

Удобство:

• -    наличие приятного внешнего вида и удобного интерфейса, необходимых для быстрого освоения и работы с приложением;

• -    интерактивность изменения данных;

• -    поддержка удаленного обучения (через Интернет) и корректная работа в современных веббраузерах: Firefox 3.5+, Opera 10.5+, Google Chrome 6+, Apple Safari 3+.

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

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

Безопасность подразумевается прежде всего в смысле защищенности системы от неправомерных действий студентов, направленных на получение непредназначенных для них данных (например, правильных ответов или формул).

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

Анализ и выбор архитектуры приложения

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

Расширяемость

Расширяемость разрабатываемой системы достигается за счет:

• -    использования типовых архитектурных решений, модулей;

• -    применение гибких масштабируемых технологий разработки;

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

• -    покрытия тестами;

• -    документации.

Ниже рассмотрим анализ возможных решений для обеспечения системы расширяемости.

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

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

На рис. 1 показана история появления API спецификаций в веб среде.

Рис. 1. История появления API спецификаций для web приложений

1993	1999		2005		2015
RDA	SOAP		JSON-RPC		GRAPHQL
1	--О	——
1991	1998	2000		2007	2016
CORBA	XML-RPC	REST		ODATA	gRPC

Сегодня актуальными спецификациями для API являются REST [3] и GraphQL [4]. Проведем сравнительный анализ этих спецификаций:

• -    Архитектура REST API определяется несколькими конечными точками на сервере. Обмен данных в GraphQL происходит через одну конечную точку, которая может возвращать сложный граф данных, что приводит к уменьшению количества запросов по сети до одного показа.

• -    Набор данных возвращаемый в REST API состоит из необработанных объектов, найденных на сервере. Такие данные содержать избыточную информацию, например, если для представления требуется только одно свойство из ответа. В другом случае конечная точка списка может возвращать не все запрошенные свойства, тогда потребуется дополнительный запрос. При помощи декларативных запросов GraphQL предотвращает избыточное или неполное получение данных.

• -    Обработка ошибок в REST, использует различные коды HTTP [5] уровня 400 для ошибок клиента и коды уровня 200 для успешных ответов. GraphQL не обязательно обслуживается через HTTP, соответственно нет никаких требований об использовании кодов ответов HTTP для ошибок. Обычно все конечные точки GraphQL разрешаются ответом кода 200, а неудачные результаты будут включать свойство “ error ” вместе со свойством data в ответе.

• -    Для управления версиями конечных точек в шаблоне REST применяются дополнительные префиксы. API -интерфейсы GraphQL стремятся к обратной совместимости и избегают критических изменений, часто выдавая / v1 или / v2 в самом URL -адресе для обозначения версии.

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

• -    Запросы декларативны, что позволяет клиенту точно указать интересующие его поля, и ответ будет содержать только заданные свойства.

• -    Запросы иерархичны. Возвращаемые данные соответствуют форме запроса.

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

• -    На основе схем запросов можно сгенерировать документацию при помощи специализированных инструментов.

• -    Спецификация имеет простую и неизбыточную семантику.

Также для корректной разработки использовались базовые принципы:

• -    SOLID [6] ( Single responsibility , Open-closed , Liskov substitution , Interface segregation и Dependency inversion ) - аббревиатура пяти основных принципов проектирования в объектноориентированном программировании.

• -    DRY [7] ( Don’t repeat yourself) - принцип нацеленности на снижение повторения информации различного рода.

• -    KISS [8] ( Keep it short and simple ) - принцип, при котором простота системы декларируется в качестве основной цели и/или ценности.

• -    YAGNI [9] ( You Ain't Gonna Need It ) - принцип, при котором в качестве основной цели и/или ценности декларируется отказ от добавления избыточной функциональности.

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

Для проверки работоспособности системы и предотвращения дефектов, было решено проводить тестирование следующих видов: Unit , Integration , E2E [10].

Unit (Модульные) тесты - это тип тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения

Integration (Интеграционные) тесты используются для проверки бизнес-логики без подключения пользовательского интерфейса.

E2E (Сквозные) тесты - это тип тестирования программного обеспечения, который проверяет программную систему вместе с ее интеграцией с внешними интерфейсами.

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

Количество тестов

Рис. 2. Пирамида тестов

Производительность

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

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

Проведем анализ наиболее часто используемых форматов данных. Рассмотрим JSON , XML , YAML [11] по следующим критериям:

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

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

• -    Простота десериализации – преобразования потока байтов в объект данных.

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

• -    Сжатие данных – скорость выполнения алгоритма компрессии и коэффициент сжатия.

• -    Распространенность – наличие большого количества разработчиков, использующих тот или иной формат обмена данными.

• -    Динамика развития - характеристика, связанная со скоростью популяризации и развития.

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

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

Табл. 1. Сравнительный анализ форматов обмена данных

	JSON	XML	YAML
Удобство чтения	5	4	4
Простота сериализации	5	5	5
Простота десериализации	5	5	5
Проверка входных данных	4	4	3
Сжатие данных	5	3	1
Распространенность	5	4	1

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

Безопасность

Реализация мер безопасности сводится к анализу потенциальных угроз для веб-приложения и принятия мер к их предотвращению. При исследовании популярных угроз для веб-приложения использовался OWASP [12]. В нем перечислены основные угрозы веб-приложений, защиту от которых стоит предусмотреть уже в процессе проектирования. Также к проблемам в безопасности можно отнести:

• -    Ошибки, допущенные во время разработки или развертывания веб-приложения;

• -    Отказ от полноценного тестирования веб-приложения на наличие уязвимостей или недостаток опыта при его проведении;

• -    Пренебрежение средствами защиты и мониторинга для своевременного реагирования на инциденты информационной безопасности.

Удобство

Для обеспечения требования интерактивности изменения данных, а также получения изменений в реальном времени, применяется технология веб-сокетов [13]. Веб-сокеты определяются как двусторонняя связь между серверами и клиентами, что означает, что обе стороны могут обмениваться данными одновременно. Решение очевидно, так как альтернативы веб сокетов, которые не являются современными и оптимизированными ( Short polling , Long polling [14]), или не обладающими полноценным функционалом ( SSE [15]).

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

Исследование инструментов разработки

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

Если проанализировать существующие системы управления образовательным процессом ( Moodle [16], Ё-стади [17], iSpring Learn [18]), то при их реализации в основном использовались следующие программные средства:

• -    РНР [19];

• -    JavaScript [20];

• -    MySQL [21].

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

Клиентская часть

При выборе языка написания клиентской части рассматривался стандартный Javascript , используемый в большинстве веб продуктов, и Typescript [22] расширяющий возможности Javascript и добавляющий статическую типизацию.

Разница между Javascript и Typescript:

• -    Javascript – это легкий для изучения язык, в то время как Typescript требует большого времени на изучение и предварительных знаний в области написания сценариев;

• -    Javascript – это язык сценариев, а Typescript – это объектно-ориентированный язык программирования;

• -    Typescript поддерживает интерфейсы, классы, подклассы;

• -    Typescript поддерживает модули, а Javascript – нет;

• -    Typescript поддерживает статическую типизацию, которая позволяет проверять правильность типа во время компиляции, тогда как JavaScript не поддерживает ее;

• -    Код Typescript должен быть скомпилирован, но нет необходимости компилировать Javascript ;

• -    Typescript предотвращает часть потенциальных runtime ошибок при компиляции;

• -    Typescript является просто надстройкой над Javascrip t, поэтому он обладает всем функционалом последнего.

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

За последнее время инструменты и технологии для создания интерфейса клиентской части значительно развились, и если раньше не было библиотек сложней jQuery [23], то сейчас появилось огромное количество актуальных и производительных замен. И за несколько лет появились несомненные лидеры в лице: React [24], Vue.js [25] и Angular [26].

Все эти три фреймворка были бы отличным выбором для разработки клиентской части, хоть и у каждого из них есть как свои плюсы, так и минусы. Но при анализе других существующих инструментов по производительности обращает внимание на себя Solid js [27]. Solid js - это Javascript библиотека, аналогичная React , Vue или Angular , которая спроектирована для эффективной отрисовки интерфейса веб приложений. Она обеспечивает все современные наборы возможностей, включая поддержку Typescript , Granular Reactivity , Async Concurrency и JSX размеченных шаблонных литералов. Кроме того, Solid js уже три года является наиболее производительной библиотекой отрисовки в браузере и занимает верхние строчки тестов производительности. На рисунке 3 изображен график анализа производительности тестового приложения при использовании различных фреймворков. Коэффициент, характеризующую каждую библиотеку, рассчитывается на основе нормировки к самой быстрой реализации.

Vanilla

Solid 1.0.0

Inferno 7.4.8

Svelte 3.37.9

Preact 10.5.12

Vue 3.0.6

React 17.0.1

Angular 12.0.1

Ember 3.22.0

2.21

Рис. 3. Характеристика фреймворков для рендера веб приложений

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

Серверная часть

Рассмотрим инструменты разработки серверной части веб приложения.

Для сокращения время изучения новых языков и реализации сервера был рассмотрен вариант Node js [28]. Node.js – платформа для использования Javascript на стороне сервера. Эта платформа позволяет писать серверный код для динамических веб-страниц и веб-приложений, а также для программ командной строки. Если говорить о языке, то как для клиентской, так и для серверной части используется один и тот же Javascript . Разница только в наборе используемых спецификаций API .

Выбор Node js обеспечивает проекту ряд преимуществ:

• -    Рост эффективности разработки благодаря использованию одного языка для клиентской и серверной части, с помощью возможности переиспользования кода;

• -    возможность использования пакетного менеджера, содержащего большое количество библиотек npm [29];

• -    более простой по сравнению с другими стеками поиска исполнителей, так как Javascript входит в число самых популярных языков программирования;

• -    Node.js хорошо подходит для разработки веб-приложений, реагирующих на действия пользователя в режиме реального времени.

На основе вышесказанного было решено в качестве языка разработки серверного приложения использовать Node js с поддержкой Typescript.

При анализе фреймворка для серверного приложения рассматривалась статистика, приведенная в “ The state of JS 2021 ” [30]. В этой системе был проведен опрос JavaScript разработчиков для составления рейтингов сторонних библиотек и фреймворков. На рисунке 4 изображены рейтинги различных фреймворков начиная с 2017 и заканчивая 2021 годом. Стоит учитывать, что в рейтинге помимо полноценных серверных фреймворков ( Fastify, Express, Nest, Strapi, Blitz, Redwood ) участвуют фреймворки для серверного рендеринга клиентской части ( SvelteKit, Astro, Next.js, Remix, Eleventy, Nuxt, Gatsby ). В данном представлении нас интересуют полноценные серверные фреймворки.

Рейтинги

Рис. 4. Рейтинг Node js фреймворков за 2017-2021 годы

На основе рейтинга (рис. 4) были выявлены два популярных Node js фреймворка для сервера: Express [31] и Nest [32]. При тщательном анализе установлено, что Express популярней, но не предоставляет полнофункциональный режим работы с сервером. Nest является мощным инструментом, который ускоряет и упрощает разработку масштабируемых серверных приложений на основе программной платформы Node.js. Он использует прогрессивный JavaScript и полностью поддерживает Typescript. В связи с этим финальным выбором был Nest js.

Для обеспечения аудита пользователей и мониторинга попыток взлома было решено использовать библиотеку для Node js – Winston [33]. Также для создания и управления резервными копиями использовалась комплексная система – New Relic [34].

Проведено исследование современных технологий и инструментов для разработки системы заданным требованиям. На основе анализа были выбраны следующие клиентские технологии: Typescript как язык программирования и Solid js как фреймворк для разработки пользовательского интерфейса. Для серверной части был выбрана платформа Node js с Typescript , и фреймворк Nest js .

Заключение

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

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

Проведено исследование современных технологий и инструментов для разработки системы заданным требованиям. На основе анализа были выбраны следующие клиентские технологии: Typescript как язык программирования и Solid js как фреймворк для разработки пользовательского интерфейса. Для серверной части был выбрана платформа Node js с Typescript , и фреймворк Nest js .