График Backend Tech Spec - moiaa/College_Management_System GitHub Wiki

Техническое задание на разработку бэкэнда модуля "Расписание"

1. Назначение модуля

[Модуль «Расписание» предназначен для работы с расписанием учебных занятий в колледже. Backend-часть обеспечивает обработку запросов, получение, создание, изменение и удаление записей о занятиях, а также передачу данных интерфейсной части через REST API. Модуль позволяет получать актуальную информацию о занятиях, включая название дисциплины, преподавателя, учебную группу, аудиторию, дату и время проведения.]

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

2,1. Основные функции

Получение списка занятий из базы данных. Получение информации о отдельном занятии по его идентификатору. Создание новой записи о занятиях. Изменение информации о существующем занятии. Удаление записи о занятиях. Проверка правильности входных данных. Обработка ошибок при обращении к API и работе с базой данных.

2,2. Пользовательские сценарии

Сценарий 1: [Просмотр расписания]

Пользователь открывает страницу расписания. Frontend отправляет GET-запрос к Backend. Backend получает записи о занятиях из базы данных. Backend возвращает список занятий в формате JSON. Frontend отображает полученное расписание.

Сценарий 2: [Добавление занятия]

Изоватем вводит данные нового занятия через интерфейс. Frontend отправляет POST-запросы с данными занятия. Бэкэнд проверяет правильность полученных данных. При успешной проверке Backend сохраняет запись в базе данных.

Сценарий 3: [Изменение занятия]

Пользователь выбирает занятие и меняет его данные. Frontend отправляет PUT-запрос с идентификатором занятия и обновленными данными. Бэкэнд проверяет наличие записи и правильность данных. Backend сохраняет изменения и возвращает обновленную запись. Backend возвращает созданную запись и статус успешного выполнения операции.

Сценарий 4: [Удаление запятых]

Пользователь инициирует удаление занятия. Frontend отправляет DELETE-запросы с идентификатором занятия. Бэкэнд проверяет наличие записи и удаляет ее из базы данных. Backend возвращает ответ об успешном удалении.

##3. Нефункциональные требования

Производительность: обработка запросов без неоправданных задержек; при необходимости фильтрация расписания должна поддерживаться. Безопасность: проверка входных данных и корректная обработка ошибок. Доступ к операциям по изменению данных должен соответствовать механизмам аутентификации и авторизации, принятым в ядре системы. Совместимость: использование Python и FastAPI, а также существующих компонентов проекта из каталога core/. Надежность: корректная работа с базой данных и отсутствие потери данных при выполнении операций. Тестируемость: возможность автоматической проверки основных функций с помощью pytest. Качество кода: соблюдение PEP 8 и успешное прохождение проверок flake8.

4. Интерфейсы

4.1. Конечные точки API

Согласуется с фронтенд-командой того же модуля до начала Модуля 2 — что это значит и как оформлять, см. 🔌 API-контракт.

| Метод | Конечная точка | Описание | Успешный ответ | Ошибки | |---|---|----|---|---|---| | ПОЛУЧИТЬ | /api/v1/schedule/... | [...] | [...] | [...] | | ПОСТ | /api/v1/schedule/... | [...] | [...] | [...] |

4.2. Взаимодействие с другими модулями

  • [Модуль]: [что именно нужно от другого модуля или ядра core/]

5. Структура базы данных

5.1. Таблицы

Таблица: [имя_таблицы]

Поле Тип Описание
id Integer Первичный ключ
... ... ...

##6. Критерии приема

  • Все функции реализованы
  • Тесты написаны и проходят (pytest)
  • CI зелёный (pytest + flake8)
  • Раздел 4.1 согласован с specification-frontend.md этого модуля (см. чек-лист в 🔌 API-контракт)
  • Pull Request создан и принят

##7. Приложения

[Схемы, диаграммы, если нужны]