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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы приспособиться к изменяющимся схемам баз данных, Flyway:

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

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

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

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.