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

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

## 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-частей. 
*   Сквозное тестирование сценариев создания, редактирования и удаления занятий с пересчетом часов нагрузки.