тестовая реализация подсчёта курса и семестра

tz2.md

@@ -0,0 +1,120 @@
+# План выполнения работ по новым интерфейсам расписания
+
+На основе предоставленного технического задания составлен следующий детализированный план разработки макетов и функционала новой подсистемы составления и просмотра расписания.
+
+## 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-частей. 
+*   Сквозное тестирование сценариев создания, редактирования и удаления занятий с пересчетом часов нагрузки.