magistr/tz2.md

План выполнения работ по новым интерфейсам расписания

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

1. Вкладка "Загрузка аудиторий"

Концепция: Динамическая таблица, визуализирующая текущее использование аудиторного фонда в конкретную учебную неделю.

Интерфейс

• Сетка данных:
  • Столбцы: Аудитории.
  • Строки: Время пар (расписание звонков).
  • Ячейки: Информация о проходящем занятии (Группа, Преподаватель, Дисциплина).
• Элементы управления:
  • Календарь недель: Выпадающий список или слайдер для переключения между учебными неделями семестра. Учитывает изменения в графике (сессии, приезд заочников и т.д.).
  • Фильтр аудиторий: Чекбоксы, мультиселект или группировка по корпусам/типам, позволяющие скрывать неотображаемые аудитории для удобства просмотра.

Функционал

• Отображение данных на основе сохраненного расписания из БД с привязкой к выбранной неделе.
• Интерактивность: Возможность клика по пустой ячейке для добавления нового занятия. Открывается модальное окно с предзаполненными полями Аудитория, Время и Неделя.

---

2. Вкладка "Загруженность преподавателей"

Концепция: Интерфейс, дублирующий логику загрузки аудиторий, но с фокусом на профессорско-преподавательский состав (ППС).

Интерфейс

• Сетка данных:
  • Столбцы: Список преподавателей.
  • Строки: Время пар.
  • Ячейки: Информация о занятии (Группа, Аудитория, Дисциплина).
• Элементы управления:
  • Календарь недель (аналогично аудиториям).
  • Поиск/фильтрация по ФИО преподавателя или кафедре.

---

3. Рабочее окно составителя расписания

Концепция: Основной инструмент диспетчера. Интерактивная среда для распределения нагрузки.

Интерфейс

• Сетка расписания:
  • Столбцы: Учебные группы.
  • Строки: Время пар.
• Панель нагрузки: Боковая панель или вызываемое окно со списком нераспределенных предметов для выбранной группы/курса.

Алгоритм работы (User Flow)

1. Старт: Диспетчер кликает в конкретную ячейку сетки (выбирает группу и время проведения пары).
2. Выбор предмета: Появляется меню со списком предметов, которые необходимо поставить данной группе. Диспетчер выбирает нужный.
3. Выбор преподавателя и проверка его занятости:
   • Система автоматически подтягивает преподавателя (или список возможных), закрепленного за этой дисциплиной.
   • Отображается карта свободных слотов преподавателя, чтобы убедиться, что он не ведет пару в это же время у другой группы (предотвращение накладок).
4. Выбор аудитории (Умный подбор):
   • Если преподаватель свободен, всплывает карта загрузки аудиторий.
   • Аудитории отображаются с цветовой индикацией:
     • 🟢 Зеленый: Аудитория свободна и её характеристики (тип, вместимость) полностью подходят для занятия.
     • 🟡 Желтый: Аудитория свободна, но не подходит по требованиям (например, это лекционный зал для маленькой группы, или обычная аудитория для компьютерного практикума).
     • 🔴 Красный: Аудитория занята (при наведении или клике показывается, кто именно там занимается).
   • Диспетчер выбирает подходящую аудиторию.
5. Финал: Занятие фиксируется в сетке, предмет вычитается из пула нераспределенной нагрузки.

---

Этапы реализации и анализ архитектуры БД

На основе анализа существующей базы данных проекта (см. docs/DATABASE.md) выявлено, что значительная часть необходимых данных уже присутствует, однако для полного удовлетворения ТЗ требуются точечные доработки структуры БД.

Анализ требований ТЗ и текущей БД

1. "Аудитории: нет пункта о том, в каком корпусе она находится":
   • Текущее состояние в БД: В таблице classrooms уже существуют поля building (Корпус) и floor (Этаж).
   • Вывод: Добавление характеристик корпуса в БД не требуется. Информацию нужно просто вывести через Backend API на Frontend.
2. Динамическое расписание и календарь недель ("закончился семестр у магистров", "заочники"):
   • Текущее состояние в БД: Таблица lessons содержит поле week (с текстовыми значениями Верхняя / Нижняя / Обе), что подразумевает статический цикличный график (раз в 2 недели).
   • Чего не хватает: Текущая схема не позволяет гибко привязывать занятия к конкретным календарным датам или конкретным учебным неделям семестра (например, с 1 по 18 неделю).
   • Вывод: Потребуется миграция БД для внедрения календаря (например, таблица academic_weeks или изменение структуры lessons).
3. Умный подбор аудиторий (желтая индикация — "не подходит оборудование"):
   • Текущее состояние в БД: Есть таблица classroom_equipments, описывающая инвентарь аудитории.
   • Чего не хватает: В системе отсутствует информация о том, какое оборудование требуется для конкретной дисциплины.
   • Вывод: Необходимо добавить новую связующую таблицу (например, subject_equipments или lesson_type_equipments), чтобы алгоритм мог сопоставлять требования предмета с оснащением выбранной аудитории.
4. Списки нагрузки для распределения:
   • Текущее состояние в БД: Присутствует таблица schedule_data со столбцом number_of_hours (часы, подлежащие распределению).
   • Вывод: Архитектура готова. Потребуется лишь бизнес-логика для связывания созданных записей lessons с нераспределенной нагрузкой schedule_data (для вычета распределенных часов).

---

Детализированный план реализации

Этап 1: Доработка базы данных (Flyway миграции)

• Миграция БД (Календарь): Проектирование и создание механизма привязки расписания к конкретным неделям/датам, отход от жесткой привязки "Верхняя/Нижняя".
• Миграция БД (Оборудование): Создание таблицы для хранения технических требований дисциплин к аудиториям (subject_equipments), чтобы стала возможна "желтая" индикация.
• (Напоминание: все миграции создаются как новые файлы V2__...sql, V3__...sql в директории db/migration/, изменение V1__init.sql запрещено).

Этап 2: Разработка Backend API (Java Spring Boot)

• Эндпоинты получения видов (View API):
  • API для сетки аудиторий: агрегация занятий по аудиториям с учетом выбранной недели.
  • API для сетки преподавателей: агрегация занятий по преподавателям.
  • API нераспределенной нагрузки: получение остатка часов из schedule_data для выбранной группы.
• Интеллектуальные алгоритмы проверок (Service Layer):
  • Логика проверки накладок преподавателей.
  • Алгоритм "Цветофор" для аудитории:
    • Красный (занятость по времени).
    • Желтый (сопоставление вместимости capacity с group_size + проверка наличия нужного оборудования).
    • Зеленый (все проверки пройдены).

Этап 3: UI-разработка (Frontend)

• Верстка трех основных табличных сеток (Audience Load, Teacher Workload, Schedule Maker).
• Реализация календаря/селектора недель (влияющего на выводимые данные).
• Программирование интерактивного Flow диспетчера в Vanilla JS:
  1. Клик в ячейку.
  2. Вызов списка нагрузки -> выбор предмета.
  3. Отображение свободных слотов преподавателя.
  4. Вывод карты аудиторий с динамической цветовой индикацией.
  5. Сохранение результата.

Этап 4: Интеграция и стабилизация

• Интеграция Front и Back-частей.
• Сквозное тестирование сценариев создания, редактирования и удаления занятий с пересчетом часов нагрузки.