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