Z1411_tyutterin_Yakov_KR

5. Техническое задание

Цель проекта: создание веб-портала с тестами для пользователей

разного уровня.

Функциональные требования:

1.Регистрация и авторизация пользователей.

2.Возможность прохождения тестов различной тематики.

3.Возможность просмотра результатов тестов и сохранения их в профиле пользователя.

4.Возможность добавления новых тестов администратором системы.

5.Отображение результатов прохождения тестов.

6.Разграничение прав доступа и отдельные меню для пользователя и администратора.

Технические требования:

1.Использование современных технологий для разработки веб-портала.

2.Адаптивный дизайн для удобного использования портала на различных устройствах.

3.Безопасность данных пользователей (защита от SQL-инъекций, XSS-

атак и др.).

4.Высокая скорость работы портала и отзывчивость интерфейса.

Дополнительные требования:

1.Ограничение на количество попыток прохождения теста отдельных пользователем.

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

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

Сроки разработки: до 3 месяцев.

Бюджет проекта: 5 рублей.

11

6. Схема базы данных

Схема базы данных представлена на рисунке 1.

Рисунок 1 – Схема Базы данных.

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

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

2.Сравнивает файлы миграции с таблицей истории. Если номер версии в имени файла ниже или равен версии, отмеченной как текущая, он игнорируется.

3.Ставит оставшиеся файлы миграции в очередь. Они сортируются по номеру версии.

12

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

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

Таблица categories – содержит лишь три поля. Id – эта колонка хранит информацию по первичным ключам для каждой отдельной записи. В качестве типа используется UUID. UUID (англ. universally unique identifier — «всемирно уникальный идентификатор») — стандарт идентификации, используемый в создании программного обеспечения. Он стандартизирован

Open Software Foundation (OSF) как часть DCE — среды распределённых вычислений. Title – хранит значение заголовка категории, а description – ее описание.

Таблица users – хранит информацию о каждом зарегистрированном пользователе в системе. Большую часть полей пользователь может задать и изменить самостоятельно, за исключением полей с ролью и активностью, которые может изменить лишь администратор БД. Пароли пользователей не хранятся в открытом виде, а хешируются с использованием BCryptPasswordEncoder (это реализация интерфейса PasswordEncoder, которая использует функцию сильного хеширования BCrypt.) на уровне приложения и только потом попадают в БД.

Таблица results хранит результаты прохождения тестов пользователями. За счет наличия внешних ключей поддерживается целостность данных. Также, для хранения состояния теста на момент просмотра результатов по нему – в results включены поля, которые рассчитываются после завершения прохождения теста. То есть при редактировании теста администратором, перерасчет и обновление ответов/вопросов – не будет происходить. Ответа пользователя хранятся в виде json в колонке exam_answers.

13

7. Реализация проекта

Начнем с BackEnd-части, а именно с регистрации пользователя, чтобы строить систему с этого. Для этого введем контроллер, который будет отвечать за три эндпоинта:

•Регистрация

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

•Логаут (выход из системы)

Также, зная, что наш BackEnd будет работать с отдельным веб-

сервисом (FrontEnd), зададим Cross-политику, указав соответствующий адрес сервера в файле конфигурации. Стандартным локальным адресом в случае

Angular используется http://localhost:4200/. То есть запросы будем принимать лишь с него. Результат указания его в файле конфигурации зафиксирован на рисунке 2.

Рисунок 2 – Допустимый адрес, с которого будут допускаться запросы Реализация контроллера представлена на рисунке 3. Для получения адреса на уровне контроллера используется Spel. SpEL — это язык выражений,

созданный для Spring Framework, который поддерживает запросы и управление графом объектов во время выполнения. Также важно отметить, что

SpEL создан в виде API-интерфейса, позволяющего интегрировать его в другие приложения и фреймворки. Также для представления данных,

получаемых от пользователя, введены DTO-классы, реализация которых представлена на рисунках 4-5.

Data Transfer Object (DTO) — один из шаблонов проектирования,

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

В отличие от business object или Data Access Object, DTO не должен содержать какого-либо поведения.

14

используется для хранения неструктурированных данных в файлах журналов или базах данных NoSQL, таких как Microsoft Azure Cosmos DB. Многие веб-

службы REST возвращают результаты в формате текста JSON или принимают данные в формате JSON.

Классы DTO используются при сериализации-десериализации. В нашем случае при регистрации/аутентификации, данные приходит на Back в виде json, а затем десериализуются в наши классы-DTO, с которыми нам будет удобно работать. Дополнительно, для поддержания валидности данных и описания правил валидации декларативно – используется jakarta.validation,

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

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

В качестве БД будет использоваться PostgreSQL. Сама она будет развернута в Docker-контейнере. Docker – это программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации.

Позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть развёрнут на любой Linux-

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

Рисунок 6 – Docker image

17

Также для подключения БД к проекту, необходимо добавить соответствующий драйвер в файл XML для системы сборки Maven.

Добавление драйвера представлено на рисунке 7.

Рисунок 7 – Драйвер БД.

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

Рисунок 8 – Зависимость для flyway.

Теперь необходимо прописать параметры подключения к БД и настроить поведение flyway при запуске. Дополнительно настраиваются некоторые параметры ORM, в нашем случае – это Hibernate. Например, такие параметры, как имя пользователя, пароль, адрес БД, отображение SQL-

запросов в консоли и тд, рисунок 9. Также при первом запуске приложения flyway, за счет выставленного флага create-schemas – создаст новую схему,

соответствующую той, что указана в currentSchema. Для того, чтобы SQL-

запросы при выводе отображались в читаемом виде, указывается флаг format_sql. Также в locations описан путь к миграциям, которые будут прогоняться при запуске (только в том случае, если БД еще не была приведена к последней версии).

18