ТЗ на модуль Диспетчера

Техническое задание на разработку модуля диспетчера системы «MobileCharge»

Оглавление

1. Общие положения

• 1.1. Термины и определения (Глоссарий)
• 1.2. Цель и назначение модуля диспетчера
• 1.3. Описание автоматизируемых процессов диспетчера
• 1.4. Модель предметной области (ссылка на общую модель)
• 1.5. Ролевая модель диспетчера

2. Требования к набору функциональных блоков модуля диспетчера

2.1. Блок «Дашбоард диспетчера»

• UC001: Просмотр оперативной сводки по заказам
• UC002: Просмотр статистики по техникам и автопарку
• UC003: Просмотр аналитики выполнения заказов
• UC004: Просмотр критичных уведомлений и алертов

2.2. Блок «Управление заказами»

• UC005: Просмотр списка заказов с фильтрацией
• UC006: Просмотр детальной информации заказа
• UC007: Редактирование параметров заказа
• UC008: Изменение статуса заказа
• UC009: Создание нового заказа (от имени клиента)
• UC010: Отмена заказа с указанием причины
• UC011: Массовые операции с заказами

2.3. Блок «Управление маршрутами»

• UC012: Просмотр списка маршрутов
• UC013: Создание нового маршрута
• UC014: Автоматическое формирование оптимального маршрута
• UC015: Редактирование маршрута (добавление/удаление заказов)
• UC016: Назначение ресурсов на маршрут (техник + комплект ТС и станции)
• UC017: Просмотр детальной информации маршрута
• UC018: Отслеживание выполнения маршрута в реальном времени
• UC019: Завершение и архивирование маршрута

2.4. Блок «Управление автопарком»

• UC020: Просмотр списка сервисных ТС
• UC021: Добавление нового сервисного ТС
• UC022: Редактирование информации о сервисном ТС
• UC023: Управление статусом ТС (доступен/в работе/на ТО/недоступен)
• UC024: Просмотр истории использования ТС
• UC025: Планирование и учет технического обслуживания ТС
• UC026: Деактивация/архивирование ТС

2.5. Блок «Управление зарядными станциями»

• UC027: Просмотр списка зарядных станций
• UC028: Добавление новой зарядной станции
• UC029: Редактирование информации о станции
• UC030: Управление статусом станции
• UC031: Назначение станции на сервисное ТС (формирование комплекта)
• UC032: Отвязка станции от ТС
• UC033: Просмотр истории использования станции
• UC034: Планирование и учет технического обслуживания станций
• UC035: Деактивация/архивирование станции

2.6. Блок «Управление техниками»

• UC036: Просмотр списка техников
• UC037: Добавление нового техника
• UC038: Редактирование профиля техника
• UC039: Управление статусом техника (активен/неактивен)
• UC040: Просмотр рабочих смен техников
• UC041: Создание и редактирование рабочих смен
• UC042: Просмотр истории работы техника
• UC043: Просмотр операций техника в реальном времени
• UC044: Деактивация/архивирование учетной записи техника

2.7. Блок «Обработка обращений клиентов»

• UC045: Просмотр списка открытых обращений
• UC046: Просмотр детальной информации обращения
• UC047: Ответ на обращение клиента
• UC048: Изменение статуса обращения
• UC049: Закрытие обращения
• UC050: Просмотр истории переписки по обращению

2.8. Блок «Управление справочниками»

• UC051: Управление справочником "Производители станций"
• UC052: Управление справочником "Модели зарядных станций"
• UC053: Управление справочником "Бренды автомобилей"
• UC054: Управление справочником "Модели автомобилей"
• UC055: Управление справочником "Тарифы"
• UC056: Управление справочником "Зоны обслуживания"
• UC057: Управление справочником "Типы коннекторов"
• UC058: Управление справочником "Причины отмены заказов"
• UC059: Управление справочником "Типы операций техников"

3. Требования к интерфейсу модуля диспетчера

• 3.1. Общие требования к интерфейсу
• 3.2. Требования к навигации
• 3.3. Требования к отображению данных
• 3.4. Требования к формам ввода
• 3.5. Требования к уведомлениям

4. Требования к безопасности и разграничению доступа

• 4.1. Аутентификация диспетчеров
• 4.2. Авторизация и права доступа
• 4.3. Аудит действий диспетчера

5. Интеграционные требования

• 5.1. Интеграция с внешними сервисами (карты, уведомления)

---

Список основных функций модуля диспетчера

Основные функциональные области:

1. Дашбоард и аналитика - оперативная сводка, статистика, уведомления
2. Управление заказами - просмотр, создание, редактирование, изменение статусов
3. Управление маршрутами - создание, оптимизация, назначение ресурсов, отслеживание
4. Управление автопарком - учет ТС, статусы, ТО, история использования
5. Управление станциями - учет станций, комплектация с ТС, статусы, ТО
6. Управление техниками - профили, смены, статусы, мониторинг работы
7. Обработка обращений - просмотр, ответы, управление статусами
8. Управление справочниками - CRUD операции для всех справочных данных

Ключевые возможности:

• Создание и оптимизация маршрутов с учетом всех ограничений
• Мониторинг выполнения заказов в реальном времени
• Управление ресурсами (техники, ТС, станции) и их распределение
• Обработка обращений клиентов
• Ведение справочной информации системы
• Аналитика и отчетность по работе службы

Блок «Дашбоард диспетчера»

UC001: Просмотр оперативной сводки по заказам

Описание: Диспетчер просматривает список нераспределенных заказов, анализирует их приоритеты и принимает решения о назначении на маршруты.

Пример интерфейса

Activity-диаграмма (Диаграмма деятельности)

В данном параграфе описан алгоритм работы функции

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает дашбоард диспетчера]
    A1 --> S1[Система: Загружает нераспределенные заказы<br/>link: СписокНераспределенныхЗаказов]
    S1 --> S2[Система: Отображает заказы со статусами NEW, CONFIRMED<br/>сортированные по времени прибытия]
    S2 --> A2[Пользователь: Выбирает заказ для назначения]
    A2 --> S3[Система: Отображает варианты назначения<br/>link: ФормаНазначенияЗаказа]
    S3 --> D1{Выбор варианта назначения}
    D1 -->|Добавить в существующий маршрут| S4[Система: Отображает список подходящих маршрутов]
    D1 -->|Создать новый маршрут| S5[Система: Переходит к UC013 Создание маршрута]
    D1 -->|Изменить предложенный маршрут| S6[Система: Переходит к UC015 Редактирование маршрута]
    S4 --> A3[Пользователь: Выбирает маршрут]
    A3 --> S7[Система: Назначает заказ на выбранный маршрут]
    S5 --> End([Конец])
    S6 --> End
    S7 --> S8[Система: Обновляет статус заказа на ASSIGNED]
    S8 --> S9[Система: Обновляет список через WebSocket]
    S9 --> End

Модель интерфейсов

В данном параграфе описана модель интерфейсов

classDiagram
    class СписокНераспределенныхЗаказов {
        <<Screen>>
        +ОбластьФильтровЗаказов : ОбластьФильтров
        +ОбластьСпискаЗаказов : ОбластьСписка
        +КнопкаСоздатьМаршрут : Кнопка
        +КнопкаОбновить : Кнопка
    }
    
    class ОбластьФильтров {
        <<Area>>
        +ФильтрПоТипу : СелекторТипаЗаказа
        +ФильтрПоВремени : ВременнойИнтервал
        +ПолеПоиска : ТекстовоеПоле
    }
    
    class ОбластьСписка {
        <<Area>>
        +КарточкаЗаказа : КарточкаЗаказаВСписке[]
    }
    
    class КарточкаЗаказаВСписке {
        <<Area>>
        +НомерЗаказа : Текст
        +ТипЗаказа : ИконкаТипа
        +ВремяПрибытия : Время
        +АдресЗаказа : Текст
        +КлиентИнформация : Текст
        +КнопкаНазначить : Кнопка
        +КнопкаДетали : Кнопка
    }
    
    class ФормаНазначенияЗаказа {
        <<Screen>>
        +ВариантыНазначения : ОбластьВариантов
        +ИнформацияОЗаказе : ОбластьИнформации
        +КнопкаПодтвердить : Кнопка
        +КнопкаОтмена : Кнопка
    }
    
    СписокНераспределенныхЗаказов *-- ОбластьФильтров
    СписокНераспределенныхЗаказов *-- ОбластьСписка
    ОбластьСписка *-- КарточкаЗаказаВСписке

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

RQ001. Требование к отображению нераспределенных заказов. Система должна отображать только заказы со статусами NEW и CONFIRMED, сортированные по полю Orders.scheduledDate в порядке возрастания (ближайшие по времени первыми).

RQ002. Требование к обновлению списка в реальном времени. При получении WebSocket-сообщения о новом заказе или изменении статуса, Система должна автоматически обновить отображение списка без перезагрузки страницы.

RQ003. Требование к визуальному выделению экстренных заказов. Заказы с типом "экстренный" должны отображаться с красной иконкой молнии и выделенным фоном.

RQ004. Требование к отображению информации о заказе. Карточка заказа должна содержать: номер заказа, тип (экстренный/плановый), время прибытия, адрес, информацию о клиенте (имя, телефон), кнопки "Назначить" и "Детали".

RQ005. Требование к функции назначения заказа. При нажатии кнопки "Назначить" Система должна отобразить модальное окно с вариантами: "Добавить в существующий маршрут", "Создать новый маршрут", "Изменить предложенный маршрут".

RQ006. Требование к фильтрации заказов. Система должна предоставлять фильтры по типу заказа (все/экстренные/плановые) и поиск по номеру заказа или адресу.

RQ007. Требование к счетчику нераспределенных заказов. В заголовке секции должен отображаться счетчик количества нераспределенных заказов в формате "Нераспределенные заказы (X)".

UC002: Просмотр активных маршрутов и карты

Описание: Диспетчер мониторит текущее состояние всех активных маршрутов, отслеживает местоположение техников на карте и анализирует выполнение заказов.

Activity-диаграмма (Диаграмма деятельности)

В данном параграфе описан алгоритм работы функции

graph TD
    Start([Начало]) --> A1[Пользователь: Просматривает карту и список маршрутов]
    A1 --> S1[Система: Загружает активные маршруты<br/>link: КартаИСписокМаршрутов]
    S1 --> S2[Система: Отображает маршруты кроме статуса DRAFT]
    S2 --> S3[Система: Обновляет позиции техников через WebSocket]
    S3 --> A2[Пользователь: Выбирает маршрут для детального просмотра]
    A2 --> S4[Система: Отображает маршрут на карте<br/>link: КартаМаршрута]
    S4 --> S5[Система: Показывает текущую позицию техника и прогресс]
    S5 --> D1{Техник отстает от графика?}
    D1 -->|Да, более 15 минут| S6[Система: Отображает индикатор задержки]
    D1 -->|Нет| S7[Система: Отображает нормальный статус]
    S6 --> A3[Пользователь: Может связаться с техником]
    S7 --> A3
    A3 --> End([Конец])

Модель интерфейсов

В данном параграфе описана модель интерфейсов

classDiagram
    class КартаИСписокМаршрутов {
        <<Screen>>
        +ОбластьКарты : ОбластьИнтерактивнойКарты
        +ОбластьСпискаМаршрутов : ОбластьСписка
        +ПанельФильтров : ОбластьФильтров
    }
    
    class ОбластьИнтерактивнойКарты {
        <<Area>>
        +МаркерыТехников : МаркерТехника[]
        +МаршрутНаКарте : ЛинияМаршрута
        +МаркерыЗаказов : МаркерЗаказа[]
    }
    
    class КарточкаМаршрута {
        <<Area>>
        +НомерМаршрута : Текст
        +ИмяТехника : Текст
        +СтатусМаршрута : СтатусИндикатор
        +КоличествоЗаказов : Число
        +ТекущаяТочка : Текст
        +ОтставаниеОтГрафика : ИндикаторЗадержки
        +КнопкаПодробнее : Кнопка
    }
    
    class МаркерТехника {
        <<Area>>
        +ПозицияНаКарте : GeoPoint
        +ИконкаТехника : Иконка
        +СтатусИндикатор : СтатусЦвет
        +ВсплывающаяИнформация : Подсказка
    }
    
    КартаИСписокМаршрутов *-- ОбластьИнтерактивнойКарты
    КартаИСписокМаршрутов *-- КарточкаМаршрута
    ОбластьИнтерактивнойКарты *-- МаркерТехника

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

RQ008. Требование к отображению активных маршрутов. Система должна отображать маршруты со всеми статусами, кроме DRAFT, с актуальной информацией о текущем выполнении.

RQ009. Требование к обновлению позиций техников. Позиции техников на карте должны обновляться через WebSocket-сообщения technician_location_updated не реже чем каждые 30 секунд.

RQ010. Требование к индикации отставания от графика. Если техник отстает от запланированного времени более чем на 15 минут, карточка маршрута должна отображаться с красным индикатором и иконкой предупреждения.

RQ011. Требование к отображению маршрута на карте. При выборе маршрута из списка, Система должна отобразить на карте: траекторию маршрута, текущую позицию техника, точки заказов с их статусами.

RQ012. Требование к фильтрации маршрутов. Система должна предоставлять фильтры по статусу маршрута (все/запланированные/в работе) и по технику.

RQ013. Требование к компоновке карты и списка. Карта должна занимать верхнюю правую четверть дашбоарда (50% × 50%), список маршрутов — нижнюю правую четверть (50% × 50%).

UC003: Анализ выполнения маршрутов

Описание: Диспетчер анализирует информацию о выполнении маршрутов на основе данных, отображаемых в карточках маршрутов (план, факт, расчетные показатели).

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Просматривает карточки маршрутов]
    A1 --> S1[Система: Отображает информацию о выполнении<br/>link: КарточкиМаршрутовСАналитикой]
    S1 --> S2[Система: Показывает плановые и фактические показатели]
    S2 --> A2[Пользователь: Анализирует отклонения от плана]
    A2 --> D1{Требуется детализация?}
    D1 -->|Да| S3[Система: Отображает детальную информацию по маршруту]
    D1 -->|Нет| End([Конец])
    S3 --> End

Модель интерфейсов

classDiagram
    class КарточкиМаршрутовСАналитикой {
        <<Screen>>
        +СписокМаршрутов : КарточкаАналитикиМаршрута[]
        +ФильтрыАналитики : ОбластьФильтров
    }
    
    class КарточкаАналитикиМаршрута {
        <<Area>>
        +НомерМаршрута : Текст
        +ПлановоеВремя : Время
        +ФактическоеВремя : Время
        +ОтклонениеОтПлана : ИндикаторОтклонения
        +КоличествоЗаказовПлан : Число
        +КоличествоЗаказовФакт : Число
        +ЭффективностьВыполнения : Процент
    }
    
    КарточкиМаршрутовСАналитикой *-- КарточкаАналитикиМаршрута

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

RQ014. Требование к отображению плановых показателей. Каждая карточка маршрута должна отображать плановое время выполнения, количество заказов, расчетное время прибытия.

RQ015. Требование к отображению фактических показателей. Карточка должна показывать фактическое время выполнения, текущий прогресс, отклонения от плана.

RQ016. Требование к расчету эффективности. Система должна автоматически рассчитывать процент выполнения плана и отображать его цветовым индикатором (зеленый >90%, желтый 70-90%, красный <70%).

UC004: Обработка обращений клиентов

Описание: Диспетчер просматривает открытые обращения клиентов и отвечает на них.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Просматривает список обращений]
    A1 --> S1[Система: Загружает открытые обращения<br/>link: СписокОбращений]
    S1 --> S2[Система: Отображает обращения со статусом не CLOSED, не DELETED]
    S2 --> A2[Пользователь: Выбирает обращение]
    A2 --> S3[Система: Отображает детали обращения<br/>link: ДеталиОбращения]
    S3 --> A3[Пользователь: Читает обращение]
    A3 --> D1{Требуется ответ?}
    D1 -->|Да| A4[Пользователь: Вводит ответ]
    D1 -->|Нет| End([Конец])
    A4 --> S4[Система: Отправляет ответ клиенту]
    S4 --> S5[Система: Обновляет статус обращения]
    S5 --> End

Модель интерфейсов

classDiagram
    class СписокОбращений {
        <<Screen>>
        +ОбластьФильтровОбращений : ОбластьФильтров
        +ОбластьСпискаОбращений : ОбластьСписка
        +СчетчикОткрытыхОбращений : СчетчикУведомлений
    }
    
    class КарточкаОбращения {
        <<Area>>
        +НомерОбращения : Текст
        +ТемаОбращения : Текст
        +ИмяКлиента : Текст
        +ВремяСоздания : Время
        +ПриоритетОбращения : ИндикаторПриоритета
        +КнопкаОтветить : Кнопка
    }
    
    class ДеталиОбращения {
        <<Screen>>
        +ИсторияПереписки : ОбластьСообщений
        +ФормаОтвета : ОбластьВвода
        +ИнформацияОЗаказе : ОбластьИнформации
        +КнопкаОтправить : Кнопка
    }
    
    СписокОбращений *-- КарточкаОбращения

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

RQ017. Требование к отображению открытых обращений. Система должна отображать обращения клиентов со всеми статусами, кроме CLOSED и DELETED.

RQ018. Требование к счетчику обращений. В заголовке секции должен отображаться счетчик открытых обращений в формате "Открытые обращения (X)".

RQ019. Требование к приоритизации обращений. Обращения должны сортироваться по приоритету: сначала связанные с активными заказами, затем по времени создания.

RQ020. Требование к ответу на обращение. При отправке ответа Система должна сохранить сообщение в истории переписки и уведомить клиента.

RQ021. Требование к автоматическому закрытию. Обращения должны автоматически закрываться через 24 часа после последнего ответа диспетчера, если от клиента не поступило новых сообщений.

Модель интерфейсов дашбоарда

Общая компоновка дашбоарда

classDiagram
    class ДашбоардДиспетчера {
        <<Screen>>
        +ЗаголовокДашбоарда : Заголовок
        +СекцияНераспределенныхЗаказов : ОбластьЗаказов
        +СекцияКарты : ОбластьКарты
        +СекцияОбращений : ОбластьОбращений
        +СекцияМаршрутов : ОбластьМаршрутов
    }
    
    class ОбластьЗаказов {
        <<Area>>
        +СписокНераспределенныхЗаказов : СписокЗаказов
        +Позиция : ВерхнийЛевыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    class ОбластьКарты {
        <<Area>>
        +ИнтерактивнаяКарта : Карта
        +МаркерыТехников : МаркерТехника[]
        +Позиция : ВерхнийПравыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    class ОбластьОбращений {
        <<Area>>
        +СписокОткрытыхОбращений : СписокОбращений
        +Позиция : НижнийЛевыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    class ОбластьМаршрутов {
        <<Area>>
        +СписокАктивныхМаршрутов : СписокМаршрутов
        +Позиция : НижнийПравыйКвадрант
        +Размер : 50процентовШиринына50процентовВысоты
    }
    
    ДашбоардДиспетчера *-- ОбластьЗаказов
    ДашбоардДиспетчера *-- ОбластьКарты
    ДашбоардДиспетчера *-- ОбластьОбращений
    ДашбоардДиспетчера *-- ОбластьМаршрутов

Технические требования к дашбоарду

Требования к компоновке

RQ022. Требование к структуре дашбоарда. Дашбоард должен состоять из четырех равных секций размером 50% × 50% каждая:

• Верхний левый квадрант: Нераспределенные заказы
• Верхний правый квадрант: Интерактивная карта
• Нижний левый квадрант: Открытые обращения
• Нижний правый квадрант: Список активных маршрутов

RQ023. Требование к фиксированному заголовку. Дашбоард должен иметь фиксированный заголовок высотой 60px с навигационными элементами и индикаторами статуса системы.

Требования к взаимодействию в реальном времени

RQ024. Требование к WebSocket-подключению. При загрузке дашбоарда Система должна автоматически установить WebSocket-соединение с сервером на эндпоинт /ws/dispatcher/{dispatcher_id}.

RQ025. Требование к обработке сообщений. Система должна обрабатывать следующие типы WebSocket-сообщений:

{
  "type": "order_created",
  "data": {
    "order": { /* объект заказа */ },
    "priority": "normal|high|urgent"
  }
}

{
  "type": "technician_location_updated", 
  "data": {
    "technician_id": "string",
    "location": {"lat": 0.0, "lng": 0.0},
    "timestamp": "datetime"
  }
}

{
  "type": "support_ticket_created",
  "data": {
    "ticket_id": "string",
    "client_id": "string",
    "subject": "string",
    "priority": "low|normal|high|urgent"
  }
}

RQ026. Требование к восстановлению соединения. При разрыве WebSocket-соединения Система должна автоматически переподключаться с экспоненциальной задержкой (1с, 2с, 4с, 8с, максимум 30с).

RQ027. Требование к ручному обновлению. Кнопка "Обновить" в заголовке дашбоарда должна выполнять полную перезагрузку всех данных, эквивалентную обновлению страницы.

Требования к производительности

RQ028. Требование к времени отклика. Обновление интерфейса при получении WebSocket-сообщения должно происходить не более чем за 200 миллисекунд.

RQ029. Требование к оптимизации рендеринга. Система должна использовать виртуализацию для списков с более чем 50 элементами.

RQ030. Требование к адаптивности. Дашбоард должен корректно отображаться на экранах с разрешением от 1366x768 до 2560x1440 пикселей с сохранением пропорций секций.

Блок «Управление заказами» - Модуль диспетчера

UC005: Просмотр списка заказов с фильтрацией

Описание: Диспетчер просматривает список всех заказов в системе, применяет фильтры для поиска нужных заказов и переходит к детальному просмотру или редактированию.

Пример интерфейса

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает страницу заказов]
    A1 --> S1[Система: Загружает список заказов<br/>сортированный по scheduledDate]
    S1 --> S2[Система: Отображает заказы с пагинацией<br/>20 записей на странице]
    S2 --> A2[Пользователь: Применяет фильтры или поиск]
    A2 --> S3[Система: Фильтрует заказы по критериям]
    S3 --> S4[Система: Обновляет список заказов]
    S4 --> D1{Выбор действия}
    D1 -->|Просмотр деталей| A3[Пользователь: Нажимает на заказ]
    D1 -->|Редактирование| A4[Пользователь: Нажимает Редактировать]
    D1 -->|Изменение статуса| A5[Пользователь: Нажимает Изменить статус]
    A3 --> S5[Система: Переход к UC006 Просмотр деталей]
    A4 --> S6[Система: Переход к UC007 Редактирование заказа]
    A5 --> S7[Система: Переход к UC008 Изменение статуса]
    S5 --> End([Конец])
    S6 --> End
    S7 --> End

Модель интерфейсов

classDiagram
    class СписокЗаказов {
        <<Screen>>
        +ЗаголовокСтраницы : Заголовок
        +ОбластьФильтров : ОбластьФильтрации
        +ОбластьПоиска : ПолеПоиска
        +СписокКарточекЗаказов : ОбластьСписка
        +Пагинация : КомпонентПагинации
        +КнопкаСоздатьЗаказ : Кнопка
    }
    
    class ОбластьФильтрации {
        <<Area>>
        +ФильтрСтатус : Селектор
        +ФильтрКлиент : ПолеВыбораКлиента
        +ФильтрДатаСоздания : ДатаИнтервал
        +ФильтрПлановаяДата : ДатаИнтервал
        +КнопкаПрименить : Кнопка
        +КнопкаСброс : Кнопка
    }
    
    class КарточкаЗаказа {
        <<Area>>
        +НомерЗаказа : Текст
        +СтатусЗаказа : СтатусИндикатор
        +ТипЗаказа : ИконкаТипа
        +КлиентИнформация : Текст
        +АдресЗаказа : Текст
        +ПлановоеВремя : ДатаВремя
        +НазначенныйТехник : Текст
        +КнопкиДействий : ГруппаКнопок
    }
    
    class ПолеПоиска {
        <<Area>>
        +ТекстовоеПоле : Ввод[255]
        +КнопкаПоиска : Кнопка
        +ПодсказкаПоиска : Текст
    }
    
    СписокЗаказов *-- ОбластьФильтрации
    СписокЗаказов *-- КарточкаЗаказа
    СписокЗаказов *-- ПолеПоиска

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

RQ101. Требование к загрузке списка заказов. Система должна загружать заказы со всеми статусами, сортированные по Orders.scheduledDate в порядке возрастания (ближайшие по времени первыми).

RQ102. Требование к пагинации. Система должна отображать 20 заказов на странице с возможностью навигации по страницам.

RQ103. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по Orders.status со всеми возможными значениями статусов.

RQ104. Требование к фильтрации по клиенту. Система должна предоставлять поле автодополнения для поиска клиента по Clients.firstName, Clients.lastName, Clients.email.

RQ105. Требование к фильтрации по датам. Система должна предоставлять интервальные фильтры:

• По дате создания (Orders.createdAt)
• По плановой дате исполнения (Orders.scheduledDate)

RQ106. Требование к функции поиска. При вводе текста в поле поиска и нажатии кнопки "Поиск", Система должна искать по вхождению подстроки в:

• Orders.orderNumber
• Orders.address
• Clients.firstName + Clients.lastName
• Clients.email

RQ107. Требование к отображению информации в карточке заказа. Каждая карточка должна содержать:

• Номер заказа с префиксом типа
• Цветовой индикатор статуса
• Иконку типа заказа (экстренный/плановый)
• ФИО клиента и телефон
• Адрес заказа
• Плановые дату и время
• ФИО назначенного техника (если есть)

RQ108. Требование к действиям с заказом. Для каждого заказа должны быть доступны кнопки:

• "Просмотр" - всегда доступна
• "Редактировать" - доступна для статусов NEW, CONFIRMED, ASSIGNED
• "Изменить статус" - доступна для активных заказов

---

UC006: Просмотр детальной информации заказа

Описание: Диспетчер просматривает полную информацию о заказе, включая историю изменений статусов, детали клиента и автомобиля, назначенные ресурсы.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает на заказ в списке]
    A1 --> S1[Система: Загружает детальную информацию]
    S1 --> S2[Система: Отображает информацию о заказе]
    S2 --> S3[Система: Загружает историю статусов<br/>из OrderStatusHistories]
    S3 --> S4[Система: Отображает информацию о клиенте<br/>и автомобиле]
    S4 --> S5[Система: Отображает назначенные ресурсы<br/>техник и маршрут]
    S5 --> D1{Выбор действия}
    D1 -->|Редактировать| A2[Пользователь: Нажимает Редактировать]
    D1 -->|Изменить статус| A3[Пользователь: Нажимает Изменить статус] 
    D1 -->|Назначить в маршрут| A4[Пользователь: Нажимает Назначить в маршрут]
    D1 -->|Вернуться| A5[Пользователь: Нажимает Назад]
    A2 --> S6[Система: Переход к UC007 Редактирование заказа]
    A3 --> S7[Система: Переход к UC008 Изменение статуса]
    A4 --> S8[Система: Переход к UC012 Назначение в маршрут]
    A5 --> End([Конец])
    S6 --> End
    S7 --> End  
    S8 --> End

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

RQ109. Требование к отображению основной информации. Система должна отображать:

• Номер заказа и текущий статус
• Тип заказа (экстренный/плановый)
• Дату и время создания, плановую дату исполнения
• Полный адрес и координаты
• Комментарий к заказу

RQ110. Требование к отображению информации о клиенте. Система должна отображать:

• ФИО клиента
• Контактные данные (телефон, email)
• Дату регистрации
• Статус клиента (активен/неактивен)

RQ111. Требование к отображению информации об автомобиле. Система должна отображать данные из связанного Vehicles:

• Марка и модель автомобиля
• Государственный номер
• Год выпуска
• Цвет

RQ112. Требование к отображению истории статусов. Система должна отображать хронологический список изменений статуса из OrderStatusHistories с указанием:

• Предыдущий и новый статус
• Дата и время изменения
• Инициатор изменения (пользователь или система)
• Причина изменения (если указана)

RQ113. Требование к отображению назначенных ресурсов. При наличии назначений Система должна отображать:

• ФИО и контакты назначенного техника
• Информацию о сервисном ТС
• Номер маршрута и ссылку на детали маршрута

---

UC007: Редактирование параметров заказа

Описание: Диспетчер изменяет параметры заказа в зависимости от его текущего статуса.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Редактировать заказ]
    A1 --> S1[Система: Проверяет статус заказа]
    S1 --> D1{Статус позволяет редактирование?}
    D1 -->|Нет| S2[Система: Отображает сообщение об ошибке]
    D1 -->|Да| S3[Система: Определяет доступные поля<br/>на основе статуса]
    S3 --> S4[Система: Отображает форму редактирования]
    S4 --> A2[Пользователь: Изменяет параметры заказа]
    A2 --> A3[Пользователь: Нажимает Сохранить]
    A3 --> S5[Система: Валидирует введенные данные]
    S5 --> D2{Данные корректны?}
    D2 -->|Нет| S6[Система: Отображает ошибки валидации]
    D2 -->|Да| S7[Система: Сохраняет изменения в Orders]
    S7 --> S8[Система: Создает запись в аудит-лог]
    S8 --> S9[Система: Отображает подтверждение]
    S9 --> End([Конец])
    S6 --> A2
    S2 --> End

Модель интерфейсов

classDiagram
    class ФормаРедактированияЗаказа {
        <<Screen>>
        +ЗаголовокФормы : Заголовок
        +ОбластьОсновныхПараметров : ОбластьПолей
        +ОбластьВремениИМеста : ОбластьПолей
        +ОбластьТарифаИАвто : ОбластьПолей
        +ПолеКомментария : ТекстовоеПоле
        +КнопкаСохранить : Кнопка
        +КнопкаОтмена : Кнопка
    }
    
    class ОбластьПолей {
        <<Area>>
        +НаборПолейВвода : ПолеВвода[]
        +ПодписиПолей : Текст[]
        +ИндикаторыОбязательности : Индикатор[]
    }

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

RQ114. Требование к проверке возможности редактирования. Система должна разрешать редактирование только для заказов со статусами NEW, CONFIRMED, ASSIGNED.

RQ115. Требование к набору редактируемых полей по статусам:

• NEW, CONFIRMED: address, scheduledDate, scheduledTime, idTariff, chargeLevel, chargeValue, комментарий, выбор автомобиля клиента
• ASSIGNED: scheduledTime, комментарий (ограниченное редактирование)
• Остальные статусы: редактирование недоступно

RQ116. Требование к валидации данных. Система должна проверять:

• Плановая дата не может быть в прошлом
• Адрес должен быть валидным и геокодируемым
• Выбранный автомобиль должен принадлежать клиенту заказа
• Выбранный тариф должен быть активным

RQ117. Требование к сохранению изменений. При успешной валидации Система должна:

• Обновить соответствующие поля в таблице Orders
• Создать запись в аудит-лог с указанием изменившихся полей
• Установить Orders.updatedBy = текущий диспетчер
• Установить Orders.updatedAt = текущее время

RQ118. Требование к ограничениям редактирования. Система не должна позволять изменять:

• Клиента заказа (Orders.idClient)
• Номер заказа (Orders.orderNumber)
• Статус заказа (только через UC008)
• Техническую информацию (totalKwh, totalPrice до завершения)

---

UC008: Изменение статуса заказа

Описание: Диспетчер изменяет статус заказа с обязательным логированием действия в истории.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Изменить статус]
    A1 --> S1[Система: Загружает текущий статус заказа]
    S1 --> S2[Система: Определяет доступные статусы<br/>для перехода]
    S2 --> S3[Система: Отображает форму изменения статуса]
    S3 --> A2[Пользователь: Выбирает новый статус]
    A2 --> A3[Пользователь: Опционально вводит причину]
    A3 --> A4[Пользователь: Нажимает Подтвердить]
    A4 --> S4[Система: Валидирует возможность перехода]
    S4 --> D1{Переход разрешен?}
    D1 -->|Нет| S5[Система: Отображает ошибку]
    D1 -->|Да| S6[Система: Обновляет Orders.status]
    S6 --> S7[Система: Создает запись в OrderStatusHistories]
    S7 --> S8[Система: Уведомляет заинтересованные стороны]
    S8 --> S9[Система: Отображает подтверждение]
    S9 --> End([Конец])
    S5 --> A2

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

RQ119. Требование к доступным переходам статусов. Диспетчер может инициировать переходы согласно диаграмме состояний, последовательно по жизненному циклу заказа.

RQ120. Требование к форме изменения статуса. Система должна отображать:

• Текущий статус заказа
• Селектор доступных статусов для перехода
• Необязательное поле для комментария/причины
• Информацию о последствиях изменения статуса

RQ121. Требование к созданию записи в истории. При изменении статуса Система должна создать запись в OrderStatusHistories:

• previousStatus = текущий статус
• newStatus = выбранный статус
• idUser = текущий диспетчер
• reason = введенный комментарий
• createdAt = текущее время

RQ122. Требование к уведомлениям. После изменения статуса Система должна:

• Отправить push-уведомление клиенту (если применимо)
• Уведомить назначенного техника (если применимо)
• Обновить связанные маршруты и смены

---

UC009: Создание нового заказа (от имени клиента)

Описание: Диспетчер создает заказ для существующего клиента с привязанной картой оплаты.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Изменить статус]
    A1 --> S1[Система: Загружает текущий статус заказа]
    S1 --> S2[Система: Определяет доступные статусы<br/>для перехода]
    S2 --> S3[Система: Отображает форму изменения статуса]
    S3 --> A2[Пользователь: Выбирает новый статус]
    A2 --> A3[Пользователь: Опционально вводит причину]
    A3 --> A4[Пользователь: Нажимает Подтвердить]
    A4 --> S4[Система: Валидирует возможность перехода]
    S4 --> D1{Переход разрешен?}
    D1 -->|Нет| S5[Система: Отображает ошибку]
    D1 -->|Да| S6[Система: Обновляет Orders.status]
    S6 --> S7[Система: Создает запись в OrderStatusHistories]
    S7 --> S8[Система: Уведомляет заинтересованные стороны]
    S8 --> S9[Система: Отображает подтверждение]
    S9 --> End([Конец])
    S5 --> A2

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

RQ123. Требование к выбору клиента. Система должна предоставить поиск по клиентам с автодополнением по ФИО, email, телефону.

RQ124. Требование к проверке карты оплаты. Система должна проверить наличие активной привязанной карты у клиента и не позволять создание заказа без неё.

RQ125. Требование к доступным типам заказов. Диспетчер может создать:

• Экстренный заказ (с префиксом "EO-")
• Плановый заказ (с префиксом "PO-")

RQ126. Требование к обязательным полям. При создании заказа обязательны:

• Клиент
• Автомобиль клиента
• Адрес
• Тип заказа
• Для планового: дата и время
• Тариф
• Параметры зарядки

RQ127. Требование к автоматическим полям. Система должна автоматически установить:

• status = NEW
• orderNumber = автогенерируемый номер
• createdBy = текущий диспетчер
• createdAt = текущее время

---

UC010: Отмена заказа с указанием причины

Описание: Диспетчер отменяет заказ с обязательным указанием причины и расчетом компенсации.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Отменить заказ]
    A1 --> S1[Система: Проверяет возможность отмены]
    S1 --> D1{Отмена разрешена?}
    D1 -->|Нет| S2[Система: Отображает сообщение о невозможности]
    D1 -->|Да| S3[Система: Отображает форму отмены]
    S3 --> A2[Пользователь: Выбирает причину отмены]
    A2 --> A3[Пользователь: Вводит комментарий]
    A3 --> A4[Пользователь: Нажимает Подтвердить отмену]
    A4 --> S4[Система: Рассчитывает сумму к возврату]
    S4 --> S5[Система: Изменяет статус на CANCELLED]
    S5 --> S6[Система: Создает запись в OrderStatusHistories]
    S6 --> S7[Система: Создает транзакцию возврата]
    S7 --> S8[Система: Освобождает назначенные ресурсы]
    S8 --> S9[Система: Уведомляет клиента и техника]
    S9 --> End([Конец])
    S2 --> End

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

RQ128. Требование к проверке возможности отмены. Отмена разрешена для заказов со статусами: NEW, CONFIRMED, ASSIGNED, EN_ROUTE. Запрещена для: CHARGING, COMPLETED, CANCELLED, FAILED.

RQ129. Требование к обязательной причине. Диспетчер обязан выбрать причину отмены из предопределенного справочника и может добавить текстовый комментарий.

RQ130. Требование к расчету возврата. Система должна рассчитать сумму возврата на основе:

• Стадии выполнения заказа
• Фактически потребленных ресурсов
• Действующих тарифов на штрафы

RQ131. Требование к освобождению ресурсов. При отмене Система должна:

• Убрать заказ из маршрута техника
• Обновить рабочую смену
• Освободить зарезервированное время техника

---

UC011: Массовые операции с заказами

Описание: Диспетчер выполняет операции над группой выбранных заказов.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Выбирает заказы в списке<br/>с помощью чекбоксов]
    A1 --> A2[Пользователь: Нажимает Массовые операции]
    A2 --> S1[Система: Отображает меню операций]
    S1 --> D1{Выбор операции}
    D1 -->|Назначить в маршрут| A3[Пользователь: Выбирает маршрут]
    D1 -->|Изменить статус| A4[Пользователь: Выбирает новый статус]
    D1 -->|Отменить заказы| A5[Пользователь: Выбирает причину]
    D1 -->|Экспорт| A6[Пользователь: Выбирает формат экспорта]
    A3 --> S2[Система: Назначает заказы в маршрут]
    A4 --> S3[Система: Изменяет статус у всех заказов]
    A5 --> S4[Система: Отменяет выбранные заказы]
    A6 --> S5[Система: Экспортирует данные заказов]
    S2 --> S6[Система: Отображает результат операции]
    S3 --> S6
    S4 --> S6  
    S5 --> S7[Система: Предлагает скачать файл]
    S6 --> End([Конец])
    S7 --> End

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

RQ132. Требование к выбору заказов. Пользователь должен иметь возможность:

• Выбирать заказы индивидуально через чекбоксы
• Выбирать все заказы на странице
• Выбирать все заказы по текущему фильтру

RQ133. Требование к доступным массовым операциям:

• Назначение в маршрут: для заказов со статусами NEW, CONFIRMED
• Изменение статуса: только разрешенные переходы
• Массовая отмена: для активных заказов с обязательной причиной
• Экспорт: в форматах Excel, CSV с выбираемым набором полей

RQ134. Требование к валидации массовых операций. Система должна:

• Проверить применимость операции к каждому заказу
• Показать предупреждение о заказах, к которым операция неприменима
• Дать возможность продолжить операцию только для подходящих заказов

RQ135. Требование к отчету о результатах. После выполнения массовой операции Система должна показать:

• Количество успешно обработанных заказов
• Количество заказов с ошибками
• Детали ошибок для заказов, которые не удалось обработать

RQ136. Требование к экспорту данных. Функция экспорта должна включать:

• Настраиваемый набор полей для экспорта
• Форматы: Excel (.xlsx), CSV (.csv)
• Экспорт с учетом текущих фильтров и сортировки
• Лимит: не более 1000 заказов за один экспорт

---

Общие требования к блоку «Управление заказами»

Требования к безопасности

RQ137. Требование к авторизации. Все функции блока доступны только пользователям с ролью ДИСПЕТЧЕР или АДМИНИСТРАТОР.

RQ138. Требование к аудиту. Все действия диспетчера должны логироваться с указанием:

• Типа операции
• Идентификатора заказа
• Пользователя-инициатора
• Времени операции
• Измененных данных (до/после)

Требования к производительности

RQ139. Требование к времени отклика. Загрузка списка заказов должна выполняться не более чем за 3 секунды при нагрузке до 10 000 заказов.

RQ140. Требование к оптимизации запросов. Система должна использовать индексы для ускорения поиска и фильтрации по полям:

• Orders.status
• Orders.createdAt
• Orders.scheduledDate
• Orders.orderNumber
• Clients.firstName, Clients.lastName

Требования к интеграции

RQ141. Требование к real-time обновлениям. Изменения статусов заказов должны отображаться в интерфейсе диспетчера в реальном времени через WebSocket-соединение.

RQ142. Требование к уведомлениям. При изменении важных параметров заказа должны отправляться уведомления:

• Клиенту - при изменении времени, отмене, назначении техника
• Технику - при назначении заказа, изменении адреса или времени
• Другим диспетчерам - при критических изменениях

Блок «Управление маршрутами» - Модуль диспетчера

UC012: Просмотр списка маршрутов

Описание: Диспетчер просматривает список всех маршрутов в системе с возможностью фильтрации по статусам, техникам и датам.

Пример интерфейса

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает раздел Маршруты]
    A1 --> S1[Система: Загружает список маршрутов<br/>отсортированный по routeDate]
    S1 --> S2[Система: Отображает маршруты с пагинацией<br/>link: СписокМаршрутов]
    S2 --> A2[Пользователь: Применяет фильтры или поиск]
    A2 --> S3[Система: Фильтрует маршруты по критериям]
    S3 --> S4[Система: Обновляет список маршрутов]
    S4 --> D1{Выбор действия}
    D1 -->|Просмотр деталей| A3[Пользователь: Нажимает на маршрут]
    D1 -->|Редактирование| A4[Пользователь: Нажимает Редактировать]
    D1 -->|Создание нового| A5[Пользователь: Нажимает Создать маршрут]
    A3 --> S5[Система: Переход к UC017 Просмотр деталей]
    A4 --> S6[Система: Переход к UC015 Редактирование маршрута]
    A5 --> S7[Система: Переход к UC013 Создание маршрута]
    S5 --> End([Конец])
    S6 --> End
    S7 --> End

Модель интерфейсов

classDiagram
    class СписокМаршрутов {
        <<Screen>>
        +ЗаголовокСтраницы : Заголовок
        +ОбластьФильтров : ОбластьФильтрации
        +ОбластьПоиска : ПолеПоиска
        +СписокКарточекМаршрутов : ОбластьСписка
        +Пагинация : КомпонентПагинации
        +КнопкаСоздатьМаршрут : Кнопка
    }
    
    class ОбластьФильтрации {
        <<Area>>
        +ФильтрСтатус : Селектор
        +ФильтрТехник : ПолеВыбораТехника
        +ФильтрДатаМаршрута : ДатаИнтервал
        +КнопкаПрименить : Кнопка
        +КнопкаСброс : Кнопка
    }
    
    class КарточкаМаршрута {
        <<Area>>
        +НомерМаршрута : Текст
        +СтатусМаршрута : СтатусИндикатор
        +ИмяТехника : Текст
        +ДатаМаршрута : Дата
        +КоличествоЗаказов : Число
        +ВремяНачалаОкончания : ВременнойИнтервал
        +ПрогрессВыполнения : ПрогрессБар
        +КнопкиДействий : ГруппаКнопок
    }
    
    СписокМаршрутов *-- ОбластьФильтрации
    СписокМаршрутов *-- КарточкаМаршрута

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

RQ201. Требование к загрузке списка маршрутов. Система должна загружать маршруты со всеми статусами, сортированные по Routes.routeDate в порядке убывания (новые маршруты первыми).

RQ202. Требование к пагинации. Система должна отображать 15 маршрутов на странице с возможностью навигации по страницам.

RQ203. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по Routes.status со всеми возможными значениями: PLANNED, IN_PROGRESS, COMPLETED, CANCELLED.

RQ204. Требование к фильтрации по технику. Система должна предоставлять поле автодополнения для поиска техника по Users.firstName, Users.lastName с ролью TECHNICIAN.

RQ205. Требование к функции поиска. При вводе текста в поле поиска Система должна искать по вхождению подстроки в номер маршрута и имя техника.

RQ206. Требование к отображению информации в карточке маршрута. Каждая карточка должна содержать:

• Идентификатор маршрута
• Цветовой индикатор статуса
• ФИО назначенного техника
• Дату маршрута
• Количество заказов в маршруте
• Плановое время начала и окончания
• Прогресс выполнения (процент выполненных заказов)

RQ207. Требование к действиям с маршрутом. Для каждого маршрута должны быть доступны кнопки:

• "Просмотр" - всегда доступна
• "Редактировать" - доступна для статусов PLANNED
• "Отслеживать" - доступна для статуса IN_PROGRESS

---

UC013: Создание нового маршрута

Пример интерфейса

Описание: Диспетчер создает новый маршрут, указывая базовые параметры и выбирая начальный набор заказов.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Создать маршрут]
    A1 --> S1[Система: Отображает форму создания маршрута<br/>link: ФормаСозданияМаршрута]
    S1 --> S2[Система: Автоматически устанавливает базу<br/>как начальную и конечную точки]
    S2 --> A2[Пользователь: Заполняет дату маршрута]
    A2 --> A3[Пользователь: Выбирает заказы для маршрута]
    A3 --> S3[Система: Рассчитывает плановые времена<br/>для каждой точки маршрута]
    S3 --> S4[Система: Рассчитывает энергозатраты<br/>по алгоритму]
    S4 --> D1{Энергии достаточно?}
    D1 -->|Нет| S5[Система: Отображает предупреждение<br/>и предлагает альтернативы]
    D1 -->|Да| A4[Пользователь: Нажимает Создать]
    A4 --> S6[Система: Валидирует введенные данные]
    S6 --> D2{Данные корректны?}
    D2 -->|Нет| S7[Система: Отображает ошибки валидации]
    D2 -->|Да| S8[Система: Создает маршрут со статусом PLANNED]
    S8 --> S9[Система: Создает записи в RoutePoints для заказов]
    S9 --> S10[Система: Отображает подтверждение создания]
    S10 --> End([Конец])
    S5 --> A3
    S7 --> A2

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

RQ208. Требование к базовым параметрам маршрута. При создании маршрута обязательны:

• Дата маршрута (Routes.routeDate)
• Начальный адрес должен быть координатами базы (Routes.startAddress, startLatitude, startLongitude)
• Конечный адрес должен быть координатами базы (Routes.endAddress, endLatitude, endLongitude)

RQ209. Требование к выбору заказов. Система должна отображать только заказы со статусами NEW и CONFIRMED, не назначенные на другие маршруты.

RQ210. Требование к автоматическим полям. При создании маршрута Система должна автоматически установить:

• status = PLANNED
• createdBy = текущий диспетчер
• createdAt = текущее время

RQ211. Требование к обязательности базы. Маршрут должен обязательно начинаться и заканчиваться на базе. Система должна автоматически устанавливать координаты базы как начальную и конечную точки маршрута.

RQ212. Требование к автоматическому расчету времен. При добавлении заказа в маршрут Система должна автоматически рассчитывать:

• Плановое время выезда с предыдущей точки (RoutePoints.plannedDepartureTime)
• Плановое время прибытия на точку заказа (RoutePoints.plannedArrivalTime)
• Ожидаемое время в пути между точками (RoutePoints.expectedTravelTimeMinutes)

RQ213. Требование к расчету энергозатрат. При добавлении заказов в маршрут Система должна рассчитывать достаточность заряда по следующему алгоритму:

Алгоритм расчета энергозатрат:

Шаг 1. Расчет энергозатрат автомобиля техника:

Общее_расстояние_маршрута = Расстояние_от_базы_до_первого_заказа + 
                             Сумма_расстояний_между_заказами + 
                             Расстояние_от_последнего_заказа_до_базы

Энергозатраты_на_поездку = Общее_расстояние_маршрута × Расход_автомобиля_кВтч_на_км

Минимальный_заряд_автомобиля = Энергозатраты_на_поездку × 1.2  // 20% запас

Шаг 2. Расчет энергозатрат зарядной станции:

Суммарная_энергия_для_зарядки = Сумма_всех_chargeValue_в_заказах_маршрута

Энергия_для_подзарядки_автомобиля = ЕСЛИ (Текущий_заряд_автомобиля < Минимальный_заряд_автомобиля)
                                   ТО (Минимальный_заряд_автомобиля - Текущий_заряд_автомобиля)
                                   ИНАЧЕ 0

Минимальная_энергия_станции = Суммарная_энергия_для_зарядки + 
                              Энергия_для_подзарядки_автомобиля × 1.1  // 10% запас

Шаг 3. Проверка достаточности:

ЕСЛИ (Текущий_заряд_автомобиля >= Минимальный_заряд_автомобиля И 
      Текущий_заряд_станции >= Минимальная_энергия_станции)
ТО Маршрут_возможен = ИСТИНА
ИНАЧЕ Маршрут_возможен = ЛОЖЬ

RQ214. Требование к проверке времени зарядки оборудования. При назначении комплекта на маршрут Система должна проверить:

• Время окончания маршрута (plannedEndTime)
• Время начала следующего запланированного маршрута для этого комплекта
• Между ними должно быть минимум 4 часа для зарядки автомобиля и станции на базе

RQ215. Требование к валидации энергозатрат. Если расчет показывает недостаточность энергии, Система должна:

• Отобразить предупреждение с детализацией проблемы
• Предложить альтернативы: уменьшить количество заказов, выбрать другой комплект оборудования
• Не позволить создать маршрут до устранения проблемы

RQ216. Требование к отображению энергетической информации. В форме создания маршрута Система должна отображать:

• Текущий уровень заряда выбранного автомобиля и станции
• Расчетные энергозатраты маршрута
• Остаток энергии после выполнения маршрута
• Цветовую индикацию (зеленый - достаточно, желтый - критично, красный - недостаточно)

---

UC015: Редактирование маршрута (добавление/удаление заказов)

Описание: Диспетчер изменяет состав заказов в маршруте и корректирует последовательность их выполнения.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Редактировать маршрут]
    A1 --> S1[Система: Проверяет статус маршрута]
    S1 --> D1{Статус позволяет редактирование?}
    D1 -->|Нет| S2[Система: Отображает сообщение об ошибке]
    D1 -->|Да| S3[Система: Отображает форму редактирования<br/>link: ФормаРедактированияМаршрута]
    S3 --> A2[Пользователь: Добавляет или удаляет заказы]
    A2 --> A3[Пользователь: Изменяет порядок заказов]
    A3 --> A4[Пользователь: Нажимает Сохранить]
    A4 --> S4[Система: Валидирует изменения]
    S4 --> D2{Изменения корректны?}
    D2 -->|Нет| S5[Система: Отображает ошибки валидации]
    D2 -->|Да| S6[Система: Обновляет записи RoutePoints]
    S6 --> S7[Система: Пересчитывает плановые времена]
    S7 --> S8[Система: Обновляет статусы заказов]
    S8 --> S9[Система: Отображает подтверждение]
    S9 --> End([Конец])
    S5 --> A2
    S2 --> End

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

RQ223. Требование к проверке возможности редактирования. Система должна разрешать редактирование только для маршрутов со статусом PLANNED.

RQ224. Требование к добавлению заказов. При добавлении заказов Система должна:

• Показывать только заказы со статусами NEW, CONFIRMED
• Исключать заказы, уже назначенные на другие маршруты
• Проверять совместимость по времени и географии
• Автоматически пересчитывать энергозатраты по алгоритму из RQ213

RQ225. Требование к удалению заказов. При удалении заказов из маршрута Система должна:

• Изменить статус заказа обратно на CONFIRMED
• Удалить соответствующую запись из RoutePoints
• Пересчитать плановые времена для оставшихся заказов
• Пересчитать энергозатраты маршрута

RQ226. Требование к изменению порядка. Система должна позволять изменять orderIndex в RoutePoints с автоматическим пересчетом всех плановых времен и энергозатрат.

---

UC016: Назначение ресурсов на маршрут (техник + комплект ТС и станции)

Описание: Диспетчер назначает на маршрут техника и комплект оборудования (сервисное ТС + зарядная станция).

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Назначить ресурсы]
    A1 --> S1[Система: Отображает форму назначения ресурсов<br/>link: ФормаНазначенияРесурсов]
    S1 --> S2[Система: Загружает доступных техников]
    S2 --> S3[Система: Загружает доступные комплекты оборудования]
    S3 --> A2[Пользователь: Выбирает техника]
    A2 --> A3[Пользователь: Выбирает комплект ТС и станции]
    A3 --> A4[Пользователь: Нажимает Назначить]
    A4 --> S4[Система: Проверяет доступность ресурсов]
    S4 --> D1{Ресурсы доступны?}
    D1 -->|Нет| S5[Система: Отображает сообщение о недоступности]
    D1 -->|Да| S6[Система: Назначает техника на маршрут]
    S6 --> S7[Система: Назначает оборудование на маршрут]
    S7 --> S8[Система: Обновляет статусы ресурсов]
    S8 --> S9[Система: Создает рабочую смену для техника]
    S9 --> S10[Система: Отображает подтверждение назначения]
    S10 --> End([Конец])
    S5 --> A2

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

RQ217. Требование к доступности техников. Система должна отображать только техников (Users с ролью TECHNICIAN), которые:

• Имеют статус isActive = true
• Не назначены на другие активные маршруты в ту же дату

RQ218. Требование к доступности оборудования. Система должна отображать только комплекты, где:

• ServiceVehicles.status = AVAILABLE
• ChargingStations.status = AVAILABLE
• Существует связь в StationVehicleAssignments

RQ219. Требование к проверке времени зарядки. При назначении комплекта Система должна проверить:

• Время окончания данного маршрута (Routes.plannedEndTime)
• Время начала следующего запланированного маршрута для этого комплекта
• Между окончанием текущего и началом следующего маршрута должно быть минимум 4 часа
• Если интервал меньше 4 часов, комплект должен быть исключен из списка доступных

RQ220. Требование к назначению ресурсов. При успешном назначении Система должна:

• Установить Routes.idTechnician = выбранный техник
• Установить Routes.idServiceVehicle = выбранное ТС
• Установить Routes.idChargingStation = выбранная станция
• Изменить статусы оборудования на IN_USE

RQ221. Требование к созданию рабочей смены. Система должна автоматически создать запись в WorkShifts с:

• idTechnician = назначенный техник
• shiftDate = дата маршрута
• plannedStartTime и plannedEndTime = времена маршрута
• status = PLANNED

RQ222. Требование к валидации временных интервалов. Если выбранный комплект не удовлетворяет требованию 4-часового интервала, Система должна:

• Отобразить предупреждение с указанием конфликтующих маршрутов
• Показать точное время окончания предыдущего и начала следующего маршрута
• Предложить альтернативные комплекты или изменение времени маршрута

---

UC017: Просмотр детальной информации маршрута

Описание: Диспетчер просматривает полную информацию о маршруте, включая список заказов, назначенные ресурсы и временную схему выполнения.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает на маршрут в списке]
    A1 --> S1[Система: Загружает детальную информацию маршрута]
    S1 --> S2[Система: Отображает основную информацию<br/>link: ДеталиМаршрута]
    S2 --> S3[Система: Загружает список заказов в маршруте]
    S3 --> S4[Система: Отображает информацию о назначенных ресурсах]
    S4 --> S5[Система: Загружает временную схему выполнения]
    S5 --> D1{Выбор действия}
    D1 -->|Редактировать| A2[Пользователь: Нажимает Редактировать]
    D1 -->|Назначить ресурсы| A3[Пользователь: Нажимает Назначить ресурсы]
    D1 -->|Отслеживать| A4[Пользователь: Нажимает Отслеживать]
    D1 -->|Вернуться| A5[Пользователь: Нажимает Назад]
    A2 --> S6[Система: Переход к UC015 Редактирование маршрута]
    A3 --> S7[Система: Переход к UC016 Назначение ресурсов]
    A4 --> S8[Система: Переход к UC018 Отслеживание]
    A5 --> End([Конец])
    S6 --> End
    S7 --> End
    S8 --> End

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

RQ227. Требование к отображению основной информации. Система должна отображать:

• Идентификатор и статус маршрута
• Дату маршрута
• Начальный и конечный адреса
• Плановые времена начала и окончания
• Фактические времена (если доступны)

RQ228. Требование к отображению заказов. Система должна отображать список заказов из RoutePoints с указанием:

• Номер заказа и его статус
• Адрес выполнения
• Плановое время прибытия
• Фактическое время прибытия (если есть)
• Статус выполнения

RQ229. Требование к отображению ресурсов. При наличии назначений Система должна отображать:

• ФИО и контакты техника
• Информацию о сервисном ТС (номер, модель)
• Информацию о зарядной станции (модель, серийный номер)

RQ230. Требование к временной схеме. Система должна отображать временную линию с:

• Плановыми точками маршрута
• Фактическим прогрессом выполнения
• Отклонениями от графика

---

UC018: Отслеживание выполнения маршрута в реальном времени

Описание: Диспетчер отслеживает выполнение активного маршрута, видит текущее местоположение техника и прогресс выполнения заказов.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает отслеживание маршрута]
    A1 --> S1[Система: Устанавливает WebSocket соединение]
    S1 --> S2[Система: Загружает карту и информацию о маршруте<br/>link: ОтслеживаниеМаршрута]
    S2 --> S3[Система: Отображает текущую позицию техника]
    S3 --> S4[Система: Показывает прогресс выполнения заказов]
    S4 --> L1[Цикл: Получение обновлений через WebSocket]
    L1 --> S5[Система: Обновляет позицию техника на карте]
    S5 --> S6[Система: Обновляет статусы заказов]
    S6 --> S7[Система: Рассчитывает отклонения от графика]
    S7 --> D1{Есть критические отклонения?}
    D1 -->|Да| S8[Система: Отображает предупреждения]
    D1 -->|Нет| S9[Система: Отображает нормальный статус]
    S8 --> D2{Пользователь закрывает отслеживание?}
    S9 --> D2
    D2 -->|Нет| L1
    D2 -->|Да| S10[Система: Закрывает WebSocket соединение]
    S10 --> End([Конец])

Модель интерфейсов

classDiagram
    class ОтслеживаниеМаршрута {
        <<Screen>>
        +ЗаголовокОтслеживания : Заголовок
        +ОбластьКарты : ИнтерактивнаяКарта
        +ОбластьИнформацииМаршрута : ИнформационнаяПанель
        +ОбластьПрогрессаЗаказов : СписокЗаказов
        +ОбластьУведомлений : ОбластьАлертов
    }
    
    class ИнтерактивнаяКарта {
        <<Area>>
        +МаркерТехника : МаркерПозиции
        +ТраекторияМаршрута : ЛинияМаршрута
        +МаркерыЗаказов : МаркерЗаказа[]
        +КонтролыКарты : КонтролыМасштаба
    }
    
    class ИнформационнаяПанель {
        <<Area>>
        +ИнформацияТехника : КарточкаТехника
        +СтатусМаршрута : СтатусИндикатор
        +ВремяВыполнения : ВременныеМетрики
        +ОтклоненияОтГрафика : ИндикаторОтклонений
    }
    
    ОтслеживаниеМаршрута *-- ИнтерактивнаяКарта
    ОтслеживаниеМаршрута *-- ИнформационнаяПанель

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

RQ231. Требование к WebSocket подключению. При загрузке отслеживания Система должна автоматически установить WebSocket-соединение для получения обновлений позиции техника.

RQ232. Требование к отображению на карте. Система должна отображать:

• Текущую позицию техника с актуальными координатами
• Траекторию маршрута с запланированными точками
• Маркеры заказов с цветовой индикацией статусов

RQ233. Требование к обновлению данных. Позиция техника должна обновляться при получении WebSocket-сообщений technician_location_updated без перезагрузки страницы.

RQ234. Требование к расчету отклонений. Система должна автоматически рассчитывать отклонения от графика на основе разности между плановыми и фактическими временами выполнения этапов.

RQ235. Требование к критическим уведомлениям. При отклонении от графика более чем на 30 минут Система должна отображать предупреждение с предложением связаться с техником.

---

UC019: Завершение и архивирование маршрута

Описание: Диспетчер завершает выполненный маршрут и переводит его в архивное состояние.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Завершить маршрут]
    A1 --> S1[Система: Проверяет статус всех заказов в маршруте]
    S1 --> D1{Все заказы завершены?}
    D1 -->|Нет| S2[Система: Отображает список незавершенных заказов]
    D1 -->|Да| S3[Система: Отображает форму завершения маршрута<br/>link: ФормаЗавершенияМаршрута]
    S3 --> A2[Пользователь: Проверяет итоговую информацию]
    A2 --> A3[Пользователь: Опционально добавляет комментарий]
    A3 --> A4[Пользователь: Нажимает Подтвердить завершение]
    A4 --> S4[Система: Изменяет статус маршрута на COMPLETED]
    S4 --> S5[Система: Завершает рабочую смену техника]
    S5 --> S6[Система: Освобождает назначенные ресурсы]
    S6 --> S7[Система: Рассчитывает итоговые метрики]
    S7 --> S8[Система: Сохраняет фактические времена]
    S8 --> S9[Система: Отображает подтверждение завершения]
    S9 --> End([Конец])
    S2 --> End

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

RQ236. Требование к проверке готовности к завершению. Система должна разрешать завершение маршрута только если все заказы в нем имеют статусы COMPLETED, CANCELLED или FAILED.

RQ237. Требование к завершению маршрута. При завершении Система должна:

• Изменить Routes.status на COMPLETED
• Установить Routes.actualEndTime = текущее время
• Обновить Routes.updatedBy = текущий диспетчер

RQ238. Требование к освобождению ресурсов. Система должна:

• Изменить WorkShifts.status на COMPLETED
• Установить ServiceVehicles.status = AVAILABLE
• Установить ChargingStations.status = AVAILABLE

RQ239. Требование к расчету метрик. Система должна рассчитать и сохранить:

• Общее время выполнения маршрута
• Отклонения от планового времени
• Количество успешно выполненных заказов
• Эффективность выполнения маршрута

RQ240. Требование к архивированию. Завершенные маршруты должны оставаться доступными для просмотра, но исключаться из основных рабочих списков диспетчера.

---

Общие требования к блоку «Управление маршрутами»

Требования к безопасности

RQ241. Требование к авторизации. Все функции блока доступны только пользователям с ролями ДИСПЕТЧЕР или АДМИНИСТРАТОР.

RQ242. Требование к аудиту. Все действия диспетчера должны логироваться с указанием:

• Типа операции
• Идентификатора маршрута
• Пользователя-инициатора
• Времени операции
• Измененных данных

Требования к производительности

RQ243. Требование к времени отклика. Загрузка списка маршрутов должна выполняться не более чем за 3 секунды при нагрузке до 1000 маршрутов.

RQ244. Требование к WebSocket производительности. Обновления через WebSocket должны отображаться в интерфейсе не более чем за 500 миллисекунд после получения сообщения.

Требования к интеграции

RQ245. Требование к real-time обновлениям. Изменения статусов маршрутов и позиций техников должны отображаться в интерфейсе диспетчера в реальном времени через WebSocket-соединение.

RQ246. Требование к синхронизации с заказами. При изменении состава заказов в маршруте должны автоматически обновляться статусы соответствующих заказов (ASSIGNED при добавлении, CONFIRMED при удалении).

RQ247. Требование к консистентности данных. Все операции с маршрутами должны выполняться в рамках транзакций для обеспечения целостности данных между связанными таблицами Routes, RoutePoints, WorkShifts и статусами ресурсов.

Блок «Управление автопарком» - Модуль диспетчера

UC020: Просмотр списка сервисных ТС

Описание: Диспетчер просматривает список всех сервисных транспортных средств с возможностью фильтрации по статусам и поиска.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает раздел Автопарк]
    A1 --> S1[Система: Загружает список сервисных ТС<br/>сортированный по licensePlate]
    S1 --> S2[Система: Отображает ТС с пагинацией<br/>15 записей на странице]
    S2 --> A2[Пользователь: Применяет фильтры или поиск]
    A2 --> S3[Система: Фильтрует ТС по критериям]
    S3 --> S4[Система: Обновляет список ТС]
    S4 --> D1{Выбор действия}
    D1 -->|Просмотр деталей| A3[Пользователь: Нажимает на ТС]
    D1 -->|Редактирование| A4[Пользователь: Нажимает Редактировать]
    D1 -->|Создание нового| A5[Пользователь: Нажимает Добавить ТС]
    A3 --> S5[Система: Переход к UC024 Просмотр истории]
    A4 --> S6[Система: Переход к UC022 Редактирование ТС]
    A5 --> S7[Система: Переход к UC021 Добавление ТС]
    S5 --> End([Конец])
    S6 --> End
    S7 --> End

Модель интерфейсов

classDiagram
    class СписокСервисныхТС {
        <<Screen>>
        +ЗаголовокСтраницы : Заголовок
        +ОбластьФильтров : ОбластьФильтрации
        +ОбластьПоиска : ПолеПоиска
        +СписокКарточекТС : ОбластьСписка
        +Пагинация : КомпонентПагинации
        +КнопкаДобавитьТС : Кнопка
    }
    
    class ОбластьФильтрации {
        <<Area>>
        +ФильтрСтатус : Селектор
        +ФильтрПоТребованиюТО : Переключатель
        +КнопкаПрименить : Кнопка
        +КнопкаСброс : Кнопка
    }
    
    class КарточкаТС {
        <<Area>>
        +ГосНомер : Текст
        +БрендМодель : Текст
        +СтатусТС : СтатусИндикатор
        +ТекущийПробег : Число
        +НазначеннаяСтанция : Текст
        +ИндикаторТО : ИндикаторТехОбслуживания
        +КнопкиДействий : ГруппаКнопок
    }
    
    СписокСервисныхТС *-- ОбластьФильтрации
    СписокСервисныхТС *-- КарточкаТС

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

RQ301. Требование к загрузке списка ТС. Система должна загружать сервисные ТС со всеми статусами, сортированные по ServiceVehicles.licensePlate в алфавитном порядке.

RQ302. Требование к пагинации. Система должна отображать 15 ТС на странице с возможностью навигации по страницам.

RQ303. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по ServiceVehicles.status со значениями: AVAILABLE, IN_USE, MAINTENANCE, UNAVAILABLE.

RQ304. Требование к фильтру по необходимости ТО. Фильтр "Требуется ТО" должен показывать ТС, у которых:

• currentMileageKm - lastServiceMileageKm >= serviceIntervalKm ИЛИ
• Дата последнего ТО + serviceIntervalMonths <= текущая дата

RQ305. Требование к функции поиска. При вводе текста Система должна искать по вхождению подстроки в ServiceVehicles.licensePlate, ServiceVehicles.brand, ServiceVehicles.model.

RQ306. Требование к отображению информации в карточке ТС. Каждая карточка должна содержать:

• Государственный номер
• Бренд и модель ТС
• Цветовой индикатор статуса
• Текущий пробег
• Назначенную зарядную станцию (если есть)
• Индикатор необходимости ТО

RQ307. Требование к индикатору ТО. Индикатор должен показывать:

• Зеленый: ТО не требуется
• Желтый: ТО потребуется в ближайший месяц (на основе статистики использования)
• Красный: ТО просрочено

---

UC021: Добавление нового сервисного ТС

Описание: Диспетчер добавляет новое сервисное транспортное средство в систему.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Добавить ТС]
    A1 --> S1[Система: Отображает форму добавления ТС]
    S1 --> A2[Пользователь: Заполняет обязательные поля]
    A2 --> A3[Пользователь: Заполняет параметры ТО]
    A3 --> A4[Пользователь: Нажимает Сохранить]
    A4 --> S2[Система: Валидирует введенные данные]
    S2 --> D1{Данные корректны?}
    D1 -->|Нет| S3[Система: Отображает ошибки валидации]
    D1 -->|Да| S4[Система: Проверяет уникальность госномера]
    S4 --> D2{Госномер уникален?}
    D2 -->|Нет| S5[Система: Отображает ошибку дублирования]
    D2 -->|Да| S6[Система: Создает запись ServiceVehicles]
    S6 --> S7[Система: Устанавливает статус AVAILABLE]
    S7 --> S8[Система: Отображает подтверждение создания]
    S8 --> End([Конец])
    S3 --> A2
    S5 --> A2

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

RQ308. Требование к обязательным полям. При добавлении ТС обязательны:

• Государственный номер (licensePlate)
• Бренд (brand)
• Модель (model)
• Интервал ТО в км (serviceIntervalKm)
• Интервал ТО в месяцах (serviceIntervalMonths)
• Текущий пробег (currentMileageKm)

RQ309. Требование к валидации госномера. Система должна проверять уникальность licensePlate среди всех ServiceVehicles.

RQ310. Требование к автоматическим полям. При создании ТС Система должна автоматически установить:

• status = AVAILABLE
• createdBy = текущий диспетчер
• createdAt = текущее время

---

UC022: Редактирование информации о сервисном ТС

Описание: Диспетчер изменяет информацию о сервисном ТС, включая параметры технического обслуживания.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Редактировать ТС]
    A1 --> S1[Система: Загружает данные ТС]
    S1 --> S2[Система: Отображает форму редактирования]
    S2 --> A2[Пользователь: Изменяет параметры ТС]
    A2 --> A3[Пользователь: Нажимает Сохранить]
    A3 --> S3[Система: Валидирует изменения]
    S3 --> D1{Данные корректны?}
    D1 -->|Нет| S4[Система: Отображает ошибки валидации]
    D1 -->|Да| S5[Система: Обновляет ServiceVehicles]
    S5 --> S6[Система: Создает запись в аудит-лог]
    S6 --> S7[Система: Отображает подтверждение]
    S7 --> End([Конец])
    S4 --> A2

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

RQ311. Требование к редактируемым полям. Диспетчер может изменять:

• Бренд и модель ТС
• Параметры технического обслуживания
• Текущий пробег
• Примечания

RQ312. Требование к нередактируемым полям. Система не должна позволять изменять:

• Государственный номер (только при создании)
• Статус ТС (только через UC023)
• Даты создания и технической информации

---

UC023: Управление статусом ТС

Описание: Диспетчер изменяет статус сервисного ТС с проверкой ограничений.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Изменить статус]
    A1 --> S1[Система: Загружает текущий статус ТС]
    S1 --> S2[Система: Определяет доступные статусы для перехода]
    S2 --> S3[Система: Отображает форму изменения статуса]
    S3 --> A2[Пользователь: Выбирает новый статус]
    A2 --> A3[Пользователь: Вводит причину изменения]
    A3 --> A4[Пользователь: Нажимает Подтвердить]
    A4 --> S4[Система: Проверяет возможность перехода]
    S4 --> D1{Переход разрешен?}
    D1 -->|Нет| S5[Система: Отображает ошибку и ограничения]
    D1 -->|Да| S6[Система: Обновляет ServiceVehicles.status]
    S6 --> S7[Система: Логирует изменение статуса]
    S7 --> S8[Система: Обновляет связанные записи]
    S8 --> End([Конец])
    S5 --> A2

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

RQ313. Требование к переходам статусов. Разрешенные переходы статусов:

• AVAILABLE → IN_USE, MAINTENANCE, UNAVAILABLE
• IN_USE → AVAILABLE, MAINTENANCE, UNAVAILABLE
• MAINTENANCE → AVAILABLE, UNAVAILABLE
• UNAVAILABLE → AVAILABLE (после устранения проблем)

RQ314. Требование к обязательной причине. При изменении статуса обязательно указание причины для аудита.

RQ315. Требование к проверке использования. При переводе в MAINTENANCE или UNAVAILABLE Система должна проверить отсутствие активных назначений.

---

UC024: Просмотр истории использования ТС

Описание: Диспетчер просматривает детальную информацию о ТС, включая историю маршрутов, техническое обслуживание и назначенное оборудование.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает на ТС в списке]
    A1 --> S1[Система: Загружает детальную информацию ТС]
    S1 --> S2[Система: Отображает основную информацию ТС]
    S2 --> S3[Система: Загружает историю маршрутов из Routes]
    S3 --> S4[Система: Загружает информацию о назначенной станции]
    S4 --> S5[Система: Загружает историю ТО]
    S5 --> S6[Система: Рассчитывает статистику использования]
    S6 --> D1{Выбор действия}
    D1 -->|Редактировать| A2[Пользователь: Нажимает Редактировать]
    D1 -->|Изменить статус| A3[Пользователь: Нажимает Изменить статус]
    D1 -->|Планировать ТО| A4[Пользователь: Нажимает Запланировать ТО]
    D1 -->|Переназначить станцию| A5[Пользователь: Нажимает Изменить станцию]
    A2 --> S7[Система: Переход к UC022]
    A3 --> S8[Система: Переход к UC023]
    A4 --> S9[Система: Переход к UC025]
    A5 --> S10[Система: Отображает форму переназначения станции]
    S7 --> End([Конец])
    S8 --> End
    S9 --> End
    S10 --> End

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

RQ316. Требование к отображению основной информации. Система должна отображать:

• Полную информацию о ТС
• Текущий статус и назначенную зарядную станцию
• Статистику использования (общий пробег, количество маршрутов)

RQ317. Требование к истории маршрутов. Система должна отображать:

• Список выполненных маршрутов с датами
• Общее количество километров по маршрутам
• Расход энергии по маршрутам

RQ318. Требование к информации о ТО. Система должна отображать:

• Дату последнего ТО и пробег
• Дату следующего планового ТО
• Список всех проведенных ТО

RQ319. Требование к переназначению станции. Диспетчер должен иметь возможность:

• Просмотреть текущую назначенную станцию
• Выбрать новую станцию из доступных
• Отвязать станцию от ТС

---

UC025: Планирование и учет технического обслуживания ТС

Описание: Диспетчер планирует и регистрирует проведенное техническое обслуживание сервисного ТС.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Запланировать ТО]
    A1 --> S1[Система: Отображает форму планирования ТО]
    S1 --> A2[Пользователь: Выбирает тип действия]
    A2 --> D1{Тип действия}
    D1 -->|Запланировать| A3[Пользователь: Указывает дату планового ТО]
    D1 -->|Зарегистрировать выполненное| A4[Пользователь: Заполняет данные о проведенном ТО]
    A3 --> S2[Система: Сохраняет плановую дату ТО]
    A4 --> S3[Система: Создает запись в ServiceVehicleMaintenances]
    A4 --> S4[Система: Обновляет lastServiceDate и lastServiceMileageKm]
    S4 --> S5[Система: Рассчитывает nextMaintenanceDate]
    S5 --> S6[Система: Переводит ТС в статус AVAILABLE если было MAINTENANCE]
    S2 --> End([Конец])
    S6 --> End

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

RQ320. Требование к планированию ТО. Диспетчер должен иметь возможность:

• Запланировать дату следующего ТО
• Указать тип планового ТО (плановое/внеплановое)
• Добавить комментарии к плановому ТО

RQ321. Требование к регистрации выполненного ТО. При регистрации ТО обязательны:

• Дата проведения ТО (maintenanceDate)
• Пробег на момент ТО (mileageKm)
• Описание выполненных работ (description)
• Стоимость ТО (опционально)

RQ322. Требование к автоматическому расчету. При регистрации ТО Система должна:

• Обновить lastServiceDate и lastServiceMileageKm в ServiceVehicles
• Рассчитать nextMaintenanceDate = maintenanceDate + serviceIntervalMonths
• Рассчитать nextMaintenanceMileageKm = mileageKm + serviceIntervalKm

---

UC026: Деактивация/архивирование ТС

Описание: Диспетчер деактивирует сервисное ТС с предварительной проверкой связанных данных.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Деактивировать ТС]
    A1 --> S1[Система: Проверяет использование ТС]
    S1 --> S2[Система: Загружает связанные маршруты]
    S2 --> S3[Система: Загружает назначенные станции]
    S3 --> D1{Есть активные связи?}
    D1 -->|Да| S4[Система: Отображает предупреждение со списком связей]
    D1 -->|Нет| S5[Система: Отображает форму деактивации]
    S4 --> A2[Пользователь: Просматривает список маршрутов и комплектов]
    A2 --> A3[Пользователь: Принимает решение о продолжении]
    A3 --> D2{Продолжить деактивацию?}
    D2 -->|Нет| End([Конец])
    D2 -->|Да| S5
    S5 --> A4[Пользователь: Указывает причину деактивации]
    A4 --> A5[Пользователь: Нажимает Подтвердить]
    A5 --> S6[Система: Устанавливает isDeleted = true]
    S6 --> S7[Система: Отвязывает назначенные станции]
    S7 --> S8[Система: Логирует деактивацию]
    S8 --> End

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

RQ323. Требование к проверке перед деактивацией. Система должна проверить и отобразить:

• Список активных маршрутов (Routes со статусами PLANNED, IN_PROGRESS)
• Список назначенных зарядных станций через StationVehicleAssignments

RQ324. Требование к отображению связанных данных. Система должна показать:

• Все маршруты, где использовалось ТС (за последние 6 месяцев)
• Текущие назначения станций
• Предупреждение о последствиях деактивации

RQ325. Требование к процессу деактивации. При подтверждении деактивации Система должна:

• Установить ServiceVehicles.isDeleted = true
• Удалить активные записи из StationVehicleAssignments
• Сохранить причину деактивации в аудит-лог

RQ326. Требование к мягкому удалению. Деактивированные ТС должны:

• Исключаться из основных рабочих списков
• Оставаться доступными в отчетах и истории
• Иметь возможность восстановления администратором

---

Общие требования к блоку «Управление автопарком»

Требования к безопасности

RQ327. Требование к авторизации. Все функции блока доступны пользователям с ролями ДИСПЕТЧЕР или АДМИНИСТРАТОР.

RQ328. Требование к аудиту. Все действия должны логироваться с указанием:

• Типа операции
• Идентификатора ТС
• Пользователя-инициатора
• Времени операции
• Измененных данных

Требования к производительности

RQ329. Требование к времени отклика. Загрузка списка ТС должна выполняться не более чем за 2 секунды при нагрузке до 500 ТС.

RQ330. Требование к оптимизации запросов. Система должна использовать индексы для ускорения поиска по:

• ServiceVehicles.licensePlate
• ServiceVehicles.status
• ServiceVehicles.brand, ServiceVehicles.model

Требования к интеграции

RQ331. Требование к синхронизации с маршрутами. При изменении статуса ТС должны автоматически обновляться связанные маршруты.

RQ332. Требование к уведомлениям. Система должна отправлять уведомления:

• О приближающемся сроке ТО (за 7 дней)
• О просроченном ТО
• При критических изменениях статуса ТС

Блок «Управление зарядными станциями» - Модуль диспетчера

UC027: Просмотр списка зарядных станций

Описание: Диспетчер просматривает список всех зарядных станций в системе с возможностью фильтрации по статусам, моделям и производителям.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Открывает раздел Зарядные станции]
    A1 --> S1[Система: Загружает список зарядных станций<br/>сортированный по serialNumber]
    S1 --> S2[Система: Отображает станции с пагинацией<br/>15 записей на странице]
    S2 --> A2[Пользователь: Применяет фильтры или поиск]
    A2 --> S3[Система: Фильтрует станции по критериям]
    S3 --> S4[Система: Обновляет список станций]
    S4 --> D1{Выбор действия}
    D1 -->|Просмотр деталей| A3[Пользователь: Нажимает на станцию]
    D1 -->|Редактирование| A4[Пользователь: Нажимает Редактировать]
    D1 -->|Создание новой| A5[Пользователь: Нажимает Добавить станцию]
    A3 --> S5[Система: Переход к UC033 Просмотр истории]
    A4 --> S6[Система: Переход к UC029 Редактирование станции]
    A5 --> S7[Система: Переход к UC028 Добавление станции]
    S5 --> End([Конец])
    S6 --> End
    S7 --> End

Модель интерфейсов

classDiagram
    class СписокЗарядныхСтанций {
        <<Screen>>
        +ЗаголовокСтраницы : Заголовок
        +ОбластьФильтров : ОбластьФильтрации
        +ОбластьПоиска : ПолеПоиска
        +СписокКарточекСтанций : ОбластьСписка
        +Пагинация : КомпонентПагинации
        +КнопкаДобавитьСтанцию : Кнопка
    }
    
    class ОбластьФильтрации {
        <<Area>>
        +ФильтрСтатус : Селектор
        +ФильтрПроизводитель : ПолеВыбораПроизводителя
        +ФильтрМодель : ПолеВыбораМодели
        +ФильтрПоТребованиюТО : Переключатель
        +КнопкаПрименить : Кнопка
        +КнопкаСброс : Кнопка
    }
    
    class КарточкаЗаряднойСтанции {
        <<Area>>
        +СерийныйНомер : Текст
        +МодельСтанции : Текст
        +СтатусСтанции : СтатусИндикатор
        +НазначенноеТС : Текст
        +КоличествоСессий : Число
        +ИндикаторТО : ИндикаторТехОбслуживания
        +КнопкиДействий : ГруппаКнопок
    }
    
    СписокЗарядныхСтанций *-- ОбластьФильтрации
    СписокЗарядныхСтанций *-- КарточкаЗаряднойСтанции

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

RQ401. Требование к загрузке списка станций. Система должна загружать зарядные станции со всеми статусами, сортированные по ChargingStations.serialNumber в алфавитном порядке.

RQ402. Требование к пагинации. Система должна отображать 15 станций на странице с возможностью навигации по страницам.

RQ403. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по ChargingStations.status со значениями: AVAILABLE, IN_USE, MAINTENANCE, UNAVAILABLE.

RQ404. Требование к фильтрации по производителю и модели. Система должна предоставлять связанные селекторы для фильтрации по Manufacturers.name и ChargingStationModels.name.

RQ405. Требование к функции поиска. При вводе текста Система должна искать по вхождению подстроки в ChargingStations.serialNumber и ChargingStationModels.name.

RQ406. Требование к отображению информации в карточке станции. Каждая карточка должна содержать:

• Серийный номер станции
• Модель и производитель
• Цветовой индикатор статуса
• Назначенное сервисное ТС (если есть)
• Общее количество сессий зарядки
• Индикатор необходимости ТО

RQ407. Требование к индикатору ТО. Индикатор должен показывать статус на основе циклов зарядки:

• Зеленый: ТО не требуется (< 80% от интервала циклов)
• Желтый: ТО потребуется скоро (80-100% от интервала циклов)
• Красный: ТО просрочено (> 100% от интервала циклов)

RQ408. Требование к отслеживанию циклов зарядки. Система должна автоматически увеличивать счетчик циклов зарядки (totalChargingSessions) при каждом завершении сессии зарядки и проверять необходимость ТО.

---

UC028: Добавление новой зарядной станции

Описание: Диспетчер добавляет новую зарядную станцию в систему с указанием модели и основных параметров.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Добавить станцию]
    A1 --> S1[Система: Отображает форму добавления станции]
    S1 --> A2[Пользователь: Выбирает модель станции]
    A2 --> S2[Система: Автозаполняет характеристики модели]
    S2 --> A3[Пользователь: Заполняет серийный номер и даты]
    A3 --> A4[Пользователь: Нажимает Сохранить]
    A4 --> S3[Система: Валидирует введенные данные]
    S3 --> D1{Данные корректны?}
    D1 -->|Нет| S4[Система: Отображает ошибки валидации]
    D1 -->|Да| S5[Система: Проверяет уникальность серийного номера]
    S5 --> D2{Серийный номер уникален?}
    D2 -->|Нет| S6[Система: Отображает ошибку дублирования]
    D2 -->|Да| S7[Система: Создает запись ChargingStations]
    S7 --> S8[Система: Устанавливает статус AVAILABLE]
    S8 --> S9[Система: Отображает подтверждение создания]
    S9 --> End([Конец])
    S4 --> A3
    S6 --> A3

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

RQ409. Требование к обязательным полям. При добавлении станции обязательны:

• Модель станции (idChargingStationModel)
• Серийный номер (serialNumber)
• Дата производства (manufactureDate)
• Интервал ТО по циклам зарядки (maintenanceIntervalCycles)

RQ409. Требование к валидации серийного номера. Система должна проверять уникальность serialNumber среди всех ChargingStations.

RQ410. Требование к автозаполнению характеристик. При выборе модели Система должна автоматически отобразить технические характеристики из ChargingStationModels.

RQ412. Требование к автоматическим полям. При создании станции Система должна автоматически установить:

• status = AVAILABLE
• totalChargingSessions = 0
• totalKwhDelivered = 0
• currentMaintenanceCycle = 0 (счетчик текущих циклов до ТО)
• createdBy = текущий диспетчер
• createdAt = текущее время

---

UC029: Редактирование информации о станции

Описание: Диспетчер изменяет информацию о зарядной станции, включая даты ТО и гарантии.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Редактировать станцию]
    A1 --> S1[Система: Загружает данные станции]
    S1 --> S2[Система: Отображает форму редактирования]
    S2 --> A2[Пользователь: Изменяет параметры станции]
    A2 --> A3[Пользователь: Нажимает Сохранить]
    A3 --> S3[Система: Валидирует изменения]
    S3 --> D1{Данные корректны?}
    D1 -->|Нет| S4[Система: Отображает ошибки валидации]
    D1 -->|Да| S5[Система: Обновляет ChargingStations]
    S5 --> S6[Система: Создает запись в аудит-лог]
    S6 --> S7[Система: Отображает подтверждение]
    S7 --> End([Конец])
    S4 --> A2

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

RQ413. Требование к редактируемым полям. Диспетчер может изменять:

• Дату окончания гарантии (warrantyEndDate)
• Дату последнего ТО (lastMaintenanceDate)
• Дату следующего ТО (nextMaintenanceDate)
• Интервал ТО по циклам (maintenanceIntervalCycles)

RQ414. Требование к нередактируемым полям. Система не должна позволять изменять:

• Серийный номер (только при создании)
• Модель станции
• Статус станции (только через UC030)
• Счетчики использования (totalChargingSessions, totalKwhDelivered)
• Текущий счетчик циклов ТО (currentMaintenanceCycle)

---

UC030: Управление статусом станции

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

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Изменить статус]
    A1 --> S1[Система: Загружает текущий статус станции]
    S1 --> S2[Система: Определяет доступные статусы для перехода]
    S2 --> S3[Система: Отображает форму изменения статуса]
    S3 --> A2[Пользователь: Выбирает новый статус]
    A2 --> A3[Пользователь: Вводит причину изменения]
    A3 --> A4[Пользователь: Нажимает Подтвердить]
    A4 --> S4[Система: Проверяет возможность перехода]
    S4 --> D1{Переход разрешен?}
    D1 -->|Нет| S5[Система: Отображает ошибку и ограничения]
    D1 -->|Да| S6[Система: Обновляет ChargingStations.status]
    S6 --> S7[Система: Логирует изменение статуса]
    S7 --> S8[Система: Обновляет связанные записи]
    S8 --> End([Конец])
    S5 --> A2

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

RQ415. Требование к переходам статусов. Разрешенные переходы статусов:

• AVAILABLE → IN_USE, MAINTENANCE, UNAVAILABLE
• IN_USE → AVAILABLE, MAINTENANCE, UNAVAILABLE
• MAINTENANCE → AVAILABLE, UNAVAILABLE
• UNAVAILABLE → AVAILABLE (после устранения проблем)

RQ416. Требование к обязательной причине. При изменении статуса обязательно указание причины для аудита.

RQ417. Требование к проверке использования. При переводе в MAINTENANCE или UNAVAILABLE Система должна проверить отсутствие активных назначений в StationVehicleAssignments.

---

UC031: Назначение станции на сервисное ТС (формирование комплекта)

Описание: Диспетчер создает связь между зарядной станцией и сервисным ТС для формирования рабочего комплекта.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Назначить на ТС]
    A1 --> S1[Система: Отображает форму назначения]
    S1 --> S2[Система: Загружает доступные ТС]
    S2 --> A2[Пользователь: Выбирает сервисное ТС]
    A2 --> A3[Пользователь: Нажимает Назначить]
    A3 --> S3[Система: Проверяет доступность ресурсов]
    S3 --> D1{Ресурсы доступны?}
    D1 -->|Нет| S4[Система: Отображает сообщение о недоступности]
    D1 -->|Да| S5[Система: Создает запись в StationVehicleAssignments]
    S5 --> S6[Система: Обновляет статусы ресурсов]
    S6 --> S7[Система: Отображает подтверждение назначения]
    S7 --> End([Конец])
    S4 --> A2

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

RQ418. Требование к доступности ТС. Система должна отображать только сервисные ТС со статусом AVAILABLE.

RQ419. Требование к доступности станций. Для назначения доступны только станции со статусом AVAILABLE.

RQ420. Требование к проверке существующих назначений. Система должна проверить отсутствие активных записей в StationVehicleAssignments для выбранной станции.

RQ421. Требование к созданию назначения. При успешном назначении Система должна:

• Создать запись в StationVehicleAssignments с assignedAt = текущее время
• Изменить статус станции на IN_USE
• Изменить статус ТС на IN_USE

---

UC032: Отвязка станции от ТС

Описание: Диспетчер разрывает связь между зарядной станцией и сервисным ТС.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Отвязать от ТС]
    A1 --> S1[Система: Проверяет использование комплекта]
    S1 --> S2[Система: Загружает активные маршруты]
    S2 --> D1{Есть активные маршруты?}
    D1 -->|Да| S3[Система: Отображает предупреждение с деталями]
    D1 -->|Нет| S4[Система: Отображает форму отвязки]
    S3 --> A2[Пользователь: Просматривает активные маршруты]
    A2 --> A3[Пользователь: Принимает решение о продолжении]
    A3 --> D2{Продолжить отвязку?}
    D2 -->|Нет| End([Конец])
    D2 -->|Да| S4
    S4 --> A4[Пользователь: Указывает причину отвязки]
    A4 --> A5[Пользователь: Нажимает Подтвердить]
    A5 --> S5[Система: Обновляет StationVehicleAssignments.unassignedAt]
    S5 --> S6[Система: Возвращает статусы AVAILABLE]
    S6 --> S7[Система: Логирует отвязку]
    S7 --> End

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

RQ422. Требование к проверке перед отвязкой. Система должна проверить и отобразить:

• Список активных маршрутов (Routes со статусами PLANNED, IN_PROGRESS)
• Предупреждение о последствиях отвязки

RQ423. Требование к процессу отвязки. При подтверждении отвязки Система должна:

• Установить StationVehicleAssignments.unassignedAt = текущее время
• Изменить статусы станции и ТС на AVAILABLE
• Сохранить причину отвязки в аудит-лог

---

UC033: Просмотр истории использования станции

Описание: Диспетчер просматривает детальную информацию о зарядной станции, включая историю маршрутов, технические характеристики и статистику использования.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает на станцию в списке]
    A1 --> S1[Система: Загружает детальную информацию станции]
    S1 --> S2[Система: Отображает основную информацию станции]
    S2 --> S3[Система: Загружает историю маршрутов из Routes]
    S3 --> S4[Система: Загружает информацию о назначенном ТС]
    S4 --> S5[Система: Загружает статистику использования]
    S5 --> S6[Система: Рассчитывает метрики эффективности]
    S6 --> D1{Выбор действия}
    D1 -->|Редактировать| A2[Пользователь: Нажимает Редактировать]
    D1 -->|Изменить статус| A3[Пользователь: Нажимает Изменить статус]
    D1 -->|Планировать ТО| A4[Пользователь: Нажимает Запланировать ТО]
    D1 -->|Назначить на ТС| A5[Пользователь: Нажимает Назначить на ТС]
    A2 --> S7[Система: Переход к UC029]
    A3 --> S8[Система: Переход к UC030]
    A4 --> S9[Система: Переход к UC034]
    A5 --> S10[Система: Переход к UC031]
    S7 --> End([Конец])
    S8 --> End
    S9 --> End
    S10 --> End

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

RQ424. Требование к отображению основной информации. Система должна отображать:

• Полную информацию о станции и её модели
• Текущий статус и назначенное ТС
• Технические характеристики из ChargingStationModels
• Текущий счетчик циклов и прогресс до ТО

RQ425. Требование к истории маршрутов. Система должна отображать:

• Список выполненных маршрутов с датами и техниками
• Детали заказов по каждому маршруту с энергопотреблением
• Общее количество сессий зарядки и прогресс до ТО
• Суммарный объем переданной энергии по заказам

RQ426. Требование к статистике использования. Система должна рассчитывать и отображать:

• Среднее количество сессий в день/месяц/цикл ТО
• Средний объем энергии за сессию и за заказ
• Интервалы зарядки: минимальный, максимальный, средний
• Объем накопленной энергии станцией между зарядками
• Расход энергии по типам заказов (экстренные/плановые)
• Время простоя vs время в работе
• Эффективность использования станции по циклам

RQ427. Требование к энергетической аналитике. Система должна отображать:

• График энергопотребления по дням/неделям
• Распределение объемов зарядки (до 50%, 50-80%, 80-100%)
• Сравнение фактического и теоретического энергопотребления
• Анализ деградации батареи станции (если применимо)

---

UC034: Планирование и учет технического обслуживания станций

Описание: Диспетчер планирует и регистрирует проведенное техническое обслуживание зарядной станции.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Запланировать ТО]
    A1 --> S1[Система: Отображает форму планирования ТО]
    S1 --> A2[Пользователь: Выбирает тип действия]
    A2 --> D1{Тип действия}
    D1 -->|Запланировать| A3[Пользователь: Указывает дату планового ТО]
    D1 -->|Зарегистрировать выполненное| A4[Пользователь: Заполняет данные о проведенном ТО]
    A3 --> S2[Система: Сохраняет плановую дату ТО]
    A4 --> S3[Система: Создает запись о ТО]
    A4 --> S4[Система: Обновляет lastMaintenanceDate]
    S4 --> S5[Система: Рассчитывает nextMaintenanceDate]
    S5 --> S6[Система: Переводит станцию в статус AVAILABLE]
    S2 --> End([Конец])
    S6 --> End

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

RQ428. Требование к планированию ТО. Диспетчер должен иметь возможность:

• Запланировать дату следующего ТО
• Установить интервал ТО по количеству циклов зарядки
• Указать тип планового ТО (плановое/внеплановое/по циклам)
• Добавить комментарии к плановому ТО

RQ429. Требование к регистрации выполненного ТО. При регистрации ТО обязательны:

• Дата проведения ТО
• Количество циклов зарядки на момент ТО
• Описание выполненных работ
• Стоимость ТО (опционально)
• Результат ТО (успешно/требуются дополнительные работы)

RQ430. Требование к автоматическому расчету ТО. При регистрации ТО Система должна:

• Обновить lastMaintenanceDate в ChargingStations
• Сбросить счетчик циклов для отсчета до следующего ТО
• Рассчитать nextMaintenanceDate на основе интервала циклов и средней интенсивности использования
• Обновить счетчики использования и энергопотребления

RQ431. Требование к мониторингу циклов ТО. Система должна:

• Автоматически отслеживать приближение к лимиту циклов
• Уведомлять диспетчеров за 50 циклов до планового ТО
• Блокировать назначение станции на новые маршруты при превышении лимита циклов на 10%

---

UC035: Деактивация/архивирование станции

Описание: Диспетчер деактивирует зарядную станцию с предварительной проверкой связанных данных.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Деактивировать станцию]
    A1 --> S1[Система: Проверяет использование станции]
    S1 --> S2[Система: Загружает связанные маршруты]
    S2 --> S3[Система: Загружает назначения на ТС]
    S3 --> D1{Есть активные связи?}
    D1 -->|Да| S4[Система: Отображает предупреждение со списком связей]
    D1 -->|Нет| S5[Система: Отображает форму деактивации]
    S4 --> A2[Пользователь: Просматривает список маршрутов и назначений]
    A2 --> A3[Пользователь: Принимает решение о продолжении]
    A3 --> D2{Продолжить деактивацию?}
    D2 -->|Нет| End([Конец])
    D2 -->|Да| S5
    S5 --> A4[Пользователь: Указывает причину деактивации]
    A4 --> A5[Пользователь: Нажимает Подтвердить]
    A5 --> S6[Система: Устанавливает isDeleted = true]
    S6 --> S7[Система: Отвязывает от назначенных ТС]
    S7 --> S8[Система: Логирует деактивацию]
    S8 --> End

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

RQ432. Требование к проверке перед деактивацией. Система должна проверить и отобразить:

• Список активных маршрутов (Routes со статусами PLANNED, IN_PROGRESS)
• Текущие назначения на ТС через StationVehicleAssignments

RQ433. Требование к отображению связанных данных. Система должна показать:

• Все маршруты, где использовалась станция (за последние 6 месяцев)
• Текущие назначения на ТС
• Предупреждение о последствиях деактивации

RQ434. Требование к процессу деактивации. При подтверждении деактивации Система должна:

• Установить ChargingStations.isDeleted = true
• Удалить активные записи из StationVehicleAssignments
• Сохранить причину деактивации в аудит-лог

RQ435. Требование к мягкому удалению. Деактивированные станции должны:

• Исключаться из основных рабочих списков
• Оставаться доступными в отчетах и истории
• Иметь возможность восстановления администратором

---

Общие требования к блоку «Управление зарядными станциями»

Требования к безопасности

RQ436. Требование к авторизации. Все функции блока доступны пользователям с ролями ДИСПЕТЧЕР или АДМИНИСТРАТОР.

RQ437. Требование к аудиту. Все действия должны логироваться с указанием:

• Типа операции
• Идентификатора станции
• Пользователя-инициатора
• Времени операции
• Измененных данных

Требования к производительности

RQ438. Требование к времени отклика. Загрузка списка станций должна выполняться не более чем за 2 секунды при нагрузке до 1000 станций.

RQ439. Требование к оптимизации запросов. Система должна использовать индексы для ускорения поиска по:

• ChargingStations.serialNumber
• ChargingStations.status
• ChargingStationModels.name
• Manufacturers.name

Требования к интеграции

RQ440. Требование к синхронизации с маршрутами. При изменении статуса станции должны автоматически обновляться связанные маршруты.

RQ441. Требование к уведомлениям. Система должна отправлять уведомления:

• О приближении к лимиту циклов ТО (за 50 циклов)
• О просроченном ТО по циклам
• При критических изменениях статуса станции

RQ442. Требование к консистентности данных. Все операции со станциями должны выполняться в рамках транзакций для обеспечения целостности данных между связанными таблицами ChargingStations, StationVehicleAssignments, Routes и статусами ресурсов.

Блок «Управление техниками»

Общее описание блока

Блок предназначен для комплексного управления техниками - сотрудниками компании, которые выполняют заказы по зарядке электромобилей с помощью мобильных зарядных станций. Блок обеспечивает полный жизненный цикл управления техниками: от регистрации в системе до архивирования учетной записи.

Основные возможности блока:

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

---

UC036: Просмотр списка техников

Актор: Диспетчер, Администратор

Описание: Просмотр полного списка техников с возможностью фильтрации и сортировки для оперативного управления персоналом.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Управление техниками']
    A1 --> S1[Система: Загружает список техников из БД]
    S1 --> S2[Система: Отображает список техников с основной информацией<br/>ссылка: СписокТехников]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Применить фильтр| A2[Пользователь: Выбирает критерии фильтрации]
    D1 -->|Сортировать| A3[Пользователь: Выбирает поле для сортировки]
    D1 -->|Просмотреть техника| A4[Пользователь: Нажимает на техника]
    D1 -->|Добавить техника| A5[Пользователь: Нажимает 'Добавить техника']
    A2 --> S3[Система: Применяет фильтр и обновляет список]
    A3 --> S4[Система: Сортирует список по выбранному полю]
    A4 --> S5[Система: Переход к UC042]
    A5 --> S6[Система: Переход к UC037]
    S3 --> S2
    S4 --> S2
    S5 --> End([Конец])
    S6 --> End

Модель интерфейсов

classDiagram
    class СписокТехников {
        <<Screen>>
        +ОбластьФильтрации : ОбластьФильтрацииТехников
        +ТаблицаТехников : ТаблицаТехников
        +КнопкаДобавитьТехника : Button
    }
    
    class ОбластьФильтрацииТехников {
        <<Area>>
        +ФильтрПоСтатусу : DropDown
        +ФильтрПоДоступности : DropDown
        +ПоискПоИмени : TextField[50]
        +КнопкаПрименить : Button
        +КнопкаСброс : Button
    }
    
    class ТаблицаТехников {
        <<Area>>
        +СтолбецИмя : TableColumn
        +СтолбецТелефон : TableColumn
        +СтолбецСтатус : TableColumn
        +СтолбецТекущаяСмена : TableColumn
        +СтолбецДействия : TableColumn
    }
    
    СписокТехников *-- ОбластьФильтрацииТехников
    СписокТехников *-- ТаблицаТехников

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

RQ320. Требование к отображению списка техников. Система должна отображать список всех техников с основной информацией: ФИО, телефон, текущий статус, наличие активной смены.

RQ321. Требование к фильтрации техников. Система должна обеспечивать фильтрацию по:

• Статусу (Активен/Неактивен/Все)
• Доступности (Доступен/На смене/Недоступен/Все)
• Поиску по ФИО (частичное совпадение)

RQ322. Требование к сортировке списка. Система должна обеспечивать сортировку по полям: ФИО, статус, дата последней активности.

RQ323. Требование к отображению доступности. Система должна определять доступность техника на основе:

• Активного статуса
• Наличия текущей рабочей смены
• Отсутствия назначения на активный маршрут

---

UC037: Добавление нового техника

Актор: Диспетчер, Администратор

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

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает 'Добавить техника']
    A1 --> S1[Система: Отображает форму добавления техника<br/>ссылка: ФормаТехника]
    S1 --> A2[Пользователь: Заполняет обязательные поля]
    A2 --> A3[Пользователь: Нажимает 'Сохранить']
    A3 --> S2[Система: Валидирует введенные данные]
    S2 --> D1{Данные корректны?}
    D1 -->|Нет| S3[Система: Отображает сообщения об ошибках]
    D1 -->|Да| S4[Система: Проверяет уникальность email и телефона]
    S3 --> S1
    S4 --> D2{Данные уникальны?}
    D2 -->|Нет| S5[Система: Отображает сообщение о дублировании]
    D2 -->|Да| S6[Система: Создает запись в таблице Users]
    S5 --> S1
    S6 --> S7[Система: Генерирует временный пароль]
    S7 --> S8[Система: Отправляет учетные данные на email]
    S8 --> S9[Система: Отображает сообщение об успешном создании]
    S9 --> End([Конец])

Модель интерфейсов

classDiagram
    class ФормаТехника {
        <<Screen>>
        +ОсновнаяИнформация : ОбластьОсновнойИнформации
        +КонтактныеДанные : ОбластьКонтактныхДанных
        +КнопкаСохранить : Button
        +КнопкаОтмена : Button
    }
    
    class ОбластьОсновнойИнформации {
        <<Area>>
        +Фамилия : TextField[50]*
        +Имя : TextField[50]*
        +Отчество : TextField[50]
        +ДатаРождения : DateField
        +Фото : FileUpload
    }
    
    class ОбластьКонтактныхДанных {
        <<Area>>
        +Email : TextField[100]*
        +Телефон : TextField[20]*
        +АдресПроживания : TextField[200]
        +Комментарий : TextArea[500]
    }
    
    ФормаТехника *-- ОбластьОсновнойИнформации
    ФормаТехника *-- ОбластьКонтактныхДанных

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

RQ324. Требование к обязательным полям. При создании техника обязательными являются поля: Фамилия, Имя, Email, Телефон.

RQ325. Требование к валидации данных. Система должна проверять:

• Корректность формата email
• Корректность формата телефона (российский формат)
• Уникальность email и телефона в системе

RQ326. Требование к генерации учетных данных. Система должна автоматически:

• Создать учетную запись с ролью "Техник"
• Сгенерировать временный пароль
• Отправить учетные данные на указанный email

RQ327. Требование к статусу по умолчанию. Новый техник должен создаваться со статусом "Активен".

---

UC038: Редактирование профиля техника

Актор: Диспетчер, Администратор

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

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Выбирает техника для редактирования]
    A1 --> S1[Система: Загружает данные техника из БД]
    S1 --> S2[Система: Отображает форму редактирования<br/>ссылка: ФормаРедактированияТехника]
    S2 --> A2[Пользователь: Изменяет необходимые поля]
    A2 --> A3[Пользователь: Нажимает 'Сохранить']
    A3 --> S3[Система: Валидирует измененные данные]
    S3 --> D1{Данные корректны?}
    D1 -->|Нет| S4[Система: Отображает сообщения об ошибках]
    D1 -->|Да| S5[Система: Проверяет уникальность email и телефона]
    S4 --> S2
    S5 --> D2{Данные уникальны?}
    D2 -->|Нет| S6[Система: Отображает сообщение о дублировании]
    D2 -->|Да| S7[Система: Обновляет запись в таблице Users]
    S6 --> S2
    S7 --> S8[Система: Отображает сообщение об успешном сохранении]
    S8 --> End([Конец])

Модель интерфейсов

classDiagram
    class ФормаРедактированияТехника {
        <<Screen>>
        +ОсновнаяИнформация : ОбластьОсновнойИнформации
        +КонтактныеДанные : ОбластьКонтактныхДанных
        +СлужебнаяИнформация : ОбластьСлужебнойИнформации
        +КнопкаСохранить : Button
        +КнопкаОтмена : Button
    }
    
    class ОбластьСлужебнойИнформации {
        <<Area>>
        +ДатаРегистрации : TextField[readonly]
        +ДатаПоследнейАктивности : TextField[readonly]
        +КоличествоВыполненныхЗаказов : TextField[readonly]
        +Рейтинг : TextField[readonly]
    }
    
    ФормаРедактированияТехника *-- ОбластьОсновнойИнформации
    ФормаРедактированияТехника *-- ОбластьКонтактныхДанных
    ФормаРедактированияТехника *-- ОбластьСлужебнойИнформации

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

RQ328. Требование к редактируемым полям. Пользователь должен иметь возможность изменять все поля профиля, кроме служебной информации.

RQ329. Требование к сохранению изменений. Система должна сохранять изменения только при успешной валидации всех данных.

RQ330. Требование к отображению служебной информации. Система должна отображать в режиме только для чтения:

• Дату регистрации в системе
• Дату последней активности
• Количество выполненных заказов
• Средний рейтинг от клиентов

---

UC039: Управление статусом техника (активен/неактивен)

Актор: Диспетчер, Администратор

Описание: Изменение статуса техника между "Активен" и "Неактивен" с контролем влияния на назначения и смены.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Выбирает техника]
    A1 --> A2[Пользователь: Нажимает 'Изменить статус']
    A2 --> S1[Система: Определяет текущий статус техника]
    S1 --> D1{Текущий статус 'Активен'?}
    D1 -->|Да| S2[Система: Проверяет активные назначения]
    D1 -->|Нет| S3[Система: Отображает диалог активации]
    S2 --> D2{Есть активные назначения?}
    D2 -->|Да| S4[Система: Отображает предупреждение о назначениях]
    D2 -->|Нет| S5[Система: Отображает диалог деактивации]
    S3 --> A3[Пользователь: Подтверждает активацию]
    S4 --> A4[Пользователь: Принимает решение]
    S5 --> A5[Пользователь: Подтверждает деактивацию]
    A3 --> S6[Система: Устанавливает статус 'Активен']
    A4 --> D3{Продолжить деактивацию?}
    A5 --> S7[Система: Устанавливает статус 'Неактивен']
    D3 -->|Да| S7
    D3 -->|Нет| End([Конец])
    S6 --> End
    S7 --> End

Модель интерфейсов

classDiagram
    class ДиалогИзмененияСтатуса {
        <<Screen>>
        +ТекущийСтатус : TextField[readonly]
        +НовыйСтатус : TextField[readonly]
        +СписокАктивныхНазначений : ListBox
        +ПричинаИзменения : TextArea[200]
        +КнопкаПодтвердить : Button
        +КнопкаОтмена : Button
    }
    
    class ПредупреждениеОНазначениях {
        <<Screen>>
        +ТекстПредупреждения : Label
        +СписокМаршрутов : ListBox
        +СписокСмен : ListBox
        +КнопкаПродолжить : Button
        +КнопкаОтмена : Button
    }

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

RQ331. Требование к проверке активных назначений. При деактивации техника Система должна проверить:

• Наличие активных маршрутов
• Наличие запланированных смен
• Наличие заказов в статусе "Назначен"

RQ332. Требование к предупреждению. Система должна отображать предупреждение со списком всех активных назначений перед деактивацией.

RQ333. Требование к принудительной деактивации. Система должна позволить деактивацию техника даже при наличии активных назначений с обязательным указанием причины.

RQ334. Требование к влиянию на доступность. Неактивный техник не должен:

• Отображаться в списках для назначения на маршруты
• Иметь возможность входа в мобильное приложение
• Получать новые смены

---

UC040: Просмотр рабочих смен техников

Актор: Диспетчер, Администратор

Описание: Просмотр календаря рабочих смен всех техников с возможностью фильтрации по периоду и технику.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Смены техников']
    A1 --> S1[Система: Загружает смены на текущую неделю]
    S1 --> S2[Система: Отображает календарь смен<br/>ссылка: КалендарьСмен]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Изменить период| A2[Пользователь: Выбирает новый период]
    D1 -->|Фильтр по технику| A3[Пользователь: Выбирает техника]
    D1 -->|Создать смену| A4[Пользователь: Нажимает 'Создать смену']
    D1 -->|Редактировать смену| A5[Пользователь: Нажимает на смену]
    A2 --> S3[Система: Загружает смены за выбранный период]
    A3 --> S4[Система: Фильтрует смены по выбранному технику]
    A4 --> S5[Система: Переход к UC041]
    A5 --> S6[Система: Переход к UC041]
    S3 --> S2
    S4 --> S2
    S5 --> End([Конец])
    S6 --> End

Модель интерфейсов

classDiagram
    class КалендарьСмен {
        <<Screen>>
        +ПанельФильтрации : ОбластьФильтрацииСмен
        +КалендарнаяСетка : ОбластьКалендаря
        +КнопкаСоздатьСмену : Button
    }
    
    class ОбластьФильтрацииСмен {
        <<Area>>
        +ВыборПериода : DateRange
        +ВыборТехника : DropDown
        +ВыборСтатусаСмены : DropDown
        +КнопкаПрименить : Button
    }
    
    class ОбластьКалендаря {
        <<Area>>
        +Заголовки : CalendarHeader
        +ЯчейкиДней : CalendarCell[]
        +БлокиСмен : ShiftBlock[]
    }
    
    КалендарьСмен *-- ОбластьФильтрацииСмен
    КалендарьСмен *-- ОбластьКалендаря

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

RQ335. Требование к отображению календаря. Система должна отображать календарь смен в виде недельной сетки с возможностью навигации по периодам.

RQ336. Требование к визуализации смен. Каждая смена должна отображаться блоком с информацией:

• ФИО техника
• Время начала и окончания
• База начала и окончания
• Статус смены (Запланирована/Активна/Завершена)

RQ337. Требование к фильтрации смен. Система должна обеспечивать фильтрацию по:

• Периоду (дата начала и окончания)
• Конкретному технику
• Статусу смены

RQ338. Требование к контролю пересечений. Система должна визуально выделять пересекающиеся смены одного техника.

---

UC041: Создание и редактирование рабочих смен

Актор: Диспетчер, Администратор

Описание: Создание новых рабочих смен для техников с контролем временных пересечений и редактирование существующих смен.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> D1{Тип операции}
    D1 -->|Создание| A1[Пользователь: Нажимает 'Создать смену']
    D1 -->|Редактирование| A2[Пользователь: Выбирает существующую смену]
    A1 --> S1[Система: Отображает форму создания смены<br/>ссылка: ФормаСмены]
    A2 --> S2[Система: Загружает данные смены]
    S2 --> S3[Система: Отображает форму редактирования смены<br/>ссылка: ФормаСмены]
    S1 --> A3[Пользователь: Заполняет поля формы]
    S3 --> A3
    A3 --> A4[Пользователь: Нажимает 'Сохранить']
    A4 --> S4[Система: Валидирует данные смены]
    S4 --> D2{Данные корректны?}
    D2 -->|Нет| S5[Система: Отображает ошибки валидации]
    D2 -->|Да| S6[Система: Проверяет пересечения с другими сменами]
    S5 --> A3
    S6 --> D3{Есть пересечения?}
    D3 -->|Да| S7[Система: Отображает предупреждение о пересечениях]
    D3 -->|Нет| S8[Система: Сохраняет смену в БД]
    S7 --> A5[Пользователь: Принимает решение]
    A5 --> D4{Сохранить принудительно?}
    D4 -->|Да| S8
    D4 -->|Нет| A3
    S8 --> End([Конец])

Модель интерфейсов

classDiagram
    class ФормаСмены {
        <<Screen>>
        +ВыборТехника : DropDown*
        +ДатаНачала : DateField*
        +ВремяНачала : TimeField*
        +БазаНачала : DropDown*
        +ДатаОкончания : DateField*
        +ВремяОкончания : TimeField*
        +БазаОкончания : DropDown*
        +Комментарий : TextArea[200]
        +КнопкаСохранить : Button
        +КнопкаОтмена : Button
    }
    
    class ПредупреждениеПересечений {
        <<Screen>>
        +ТекстПредупреждения : Label
        +СписокПересечений : ListBox
        +КнопкаПродолжить : Button
        +КнопкаОтмена : Button
    }

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

RQ339. Требование к обязательным полям. При создании смены обязательными являются: Техник, Дата начала, Время начала, База начала, Дата окончания, Время окончания.

RQ340. Требование к валидации времени. Система должна проверять:

• Время окончания позже времени начала
• Общая продолжительность смены не более 12 часов
• Дата окончания не ранее даты начала

RQ341. Требование к проверке пересечений. Система должна проверять отсутствие пересечений смен одного техника по времени.

RQ342. Требование к базам. База окончания может отличаться от базы начала. Система должна предоставлять список всех доступных баз из справочника.

RQ343. Требование к принудительному сохранению. Система должна позволить сохранение смены с пересечениями после подтверждения пользователем.

---

UC042: Просмотр истории работы техника

Актор: Диспетчер, Администратор

Описание: Просмотр детальной истории работы конкретного техника, включая выполненные заказы, статистику и оценки.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Выбирает техника в списке]
    A1 --> S1[Система: Загружает профиль техника]
    S1 --> S2[Система: Отображает детальную информацию<br/>ссылка: ПрофильТехника]
    S2 --> S3[Система: Загружает статистику работы]
    S3 --> S4[Система: Загружает историю заказов]
    S4 --> S5[Система: Загружает историю смен]
    S5 --> D1{Пользователь выбирает действие}
    D1 -->|Просмотр заказов| A2[Пользователь: Переходит к истории заказов]
    D1 -->|Просмотр смен| A3[Пользователь: Переходит к истории смен]
    D1 -->|Редактировать| A4[Пользователь: Нажимает 'Редактировать']
    D1 -->|Изменить статус| A5[Пользователь: Нажимает 'Изменить статус']
    A2 --> S6[Система: Отображает подробную историю заказов]
    A3 --> S7[Система: Отображает подробную историю смен]
    A4 --> S8[Система: Переход к UC038]
    A5 --> S9[Система: Переход к UC039]
    S6 --> End([Конец])
    S7 --> End
    S8 --> End
    S9 --> End

Модель интерфейсов

classDiagram
    class ПрофильТехника {
        <<Screen>>
        +ИнформацияОТехнике : ОбластьПрофиля
        +СтатистикаРаботы : ОбластьСтатистики
        +ИсторияЗаказов : ОбластьИсторииЗаказов
        +ИсторияСмен : ОбластьИсторииСмен
        +КнопкаРедактировать : Button
        +КнопкаИзменитьСтатус : Button
    }
    
    class ОбластьСтатистики {
        <<Area>>
        +ВсегоЗаказов : TextField[readonly]
        +ВыполненныхЗаказов : TextField[readonly]
        +ОтмененныхЗаказов : TextField[readonly]
        +СреднийРейтинг : TextField[readonly]
        +ОбщееВремяРаботы : TextField[readonly]
    }
    
    class ОбластьИсторииЗаказов {
        <<Area>>
        +ТаблицаЗаказов : TableView
        +ФильтрПоПериоду : DateRange
        +ФильтрПоСтатусу : DropDown
    }
    
    ПрофильТехника *-- ОбластьПрофиля
    ПрофильТехника *-- ОбластьСтатистики
    ПрофильТехника *-- ОбластьИсторииЗаказов
    ПрофильТехника *-- ОбластьИсторииСмен

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

RQ344. Требование к отображению статистики. Система должна рассчитывать и отображать:

• Общее количество назначенных заказов
• Количество успешно выполненных заказов
• Количество отмененных заказов
• Средний рейтинг от клиентов
• Общее время работы (сумма всех смен)

RQ345. Требование к истории заказов. Система должна отображать список всех заказов техника с возможностью фильтрации по:

• Периоду выполнения
• Статусу заказа
• Типу заказа (срочный/плановый)

RQ346. Требование к истории смен. Система должна отображать все смены техника с информацией:

• Дата и время смены
• База начала и окончания
• Фактическое время работы
• Количество выполненных заказов за смену

---

UC043: Просмотр операций техника в реальном времени

Актор: Диспетчер, Администратор

Описание: Мониторинг текущей деятельности техника в реальном времени, включая местоположение, статус заказа и взаимодействие с клиентом.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Выбирает активного техника]
    A1 --> S1[Система: Проверяет наличие активной смены]
    S1 --> D1{Техник на смене?}
    D1 -->|Нет| S2[Система: Отображает сообщение о неактивности]
    D1 -->|Да| S3[Система: Загружает текущие данные<br/>ссылка: МониторингТехника]
    S2 --> End([Конец])
    S3 --> S4[Система: Отображает местоположение на карте]
    S4 --> S5[Система: Отображает статус текущего заказа]
    S5 --> S6[Система: Обновляет данные каждые 30 секунд]
    S6 --> D2{Пользователь остается на экране?}
    D2 -->|Да| S7[Система: Загружает обновленные данные]
    D2 -->|Нет| End
    S7 --> S4

Модель интерфейсов

classDiagram
    class МониторингТехника {
        <<Screen>>
        +ИнформацияОТехнике : ОбластьИнформацииТехника
        +КартаМестоположения : ОбластьКарты
        +ТекущийЗаказ : ОбластьТекущегоЗаказа
        +ИсторияОперацийДня : ОбластьИсторииОпераций
    }
    
    class ОбластьКарты {
        <<Area>>
        +КартаGPS : MapView
        +МеткаТехника : MapMarker
        +МеткаКлиента : MapMarker
        +МаршрутДвижения : MapRoute
    }
    
    class ОбластьТекущегоЗаказа {
        <<Area>>
        +НомерЗаказа : TextField[readonly]
        +СтатусЗаказа : TextField[readonly]
        +ВремяНачала : TextField[readonly]
        +ИнформацияОКлиенте : TextField[readonly]
        +ПрогрессВыполнения : ProgressBar
    }
    
    МониторингТехника *-- ОбластьИнформацииТехника
    МониторингТехника *-- ОбластьКарты
    МониторингТехника *-- ОбластьТекущегоЗаказа
    МониторингТехника *-- ОбластьИсторииОпераций

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

RQ347. Требование к отображению местоположения. Система должна отображать на карте:

• Текущее местоположение техника (по GPS)
• Местоположение клиента (при наличии активного заказа)
• Маршрут движения к клиенту

RQ348. Требование к мониторингу заказа. Система должна отображать в реальном времени:

• Номер и статус текущего заказа
• Время начала выполнения заказа
• Прогресс выполнения (В пути/Прибыл/Заряжает/Завершает)
• Контактную информацию клиента

RQ349. Требование к автообновлению. Система должна автоматически обновлять данные каждые 30 секунд без участия пользователя.

RQ350. Требование к истории операций дня. Система должна отображать список всех операций техника за текущий день:

• Время начала и окончания смены
• Выполненные заказы
• Время в пути между заказами
• Перерывы и простои

---

UC044: Деактивация/архивирование учетной записи техника

Актор: Диспетчер, Администратор

Описание: Процесс архивирования учетной записи техника с контролем активных назначений и возможностью последующего восстановления.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Выбирает техника для архивирования]
    A1 --> A2[Пользователь: Нажимает 'Архивировать']
    A2 --> S1[Система: Проверяет активные назначения]
    S1 --> S2[Система: Формирует список невыполненных маршрутов]
    S2 --> D1{Есть активные назначения?}
    D1 -->|Да| S3[Система: Отображает предупреждение<br/>ссылка: ПредупреждениеАрхивирования]
    D1 -->|Нет| S4[Система: Отображает диалог архивирования]
    S3 --> A3[Пользователь: Просматривает список назначений]
    A3 --> A4[Пользователь: Принимает решение]
    A4 --> D2{Продолжить архивирование?}
    D2 -->|Нет| End([Конец])
    D2 -->|Да| S4
    S4 --> A5[Пользователь: Указывает причину архивирования]
    A5 --> A6[Пользователь: Подтверждает архивирование]
    A6 --> S5[Система: Устанавливает статус 'Архивирован']
    S5 --> S6[Система: Деактивирует учетную запись]
    S6 --> S7[Система: Отображает сообщение об успешном архивировании]
    S7 --> End

Модель интерфейсов

classDiagram
    class ПредупреждениеАрхивирования {
        <<Screen>>
        +ТекстПредупреждения : Label
        +СписокАктивныхМаршрутов : ListBox
        +СписокЗапланированныхСмен : ListBox
        +ПричинаАрхивирования : TextArea[200]*
        +КнопкаПродолжить : Button
        +КнопкаОтмена : Button
    }
    
    class ДиалогВосстановления {
        <<Screen>>
        +ИнформацияОТехнике : TextField[readonly]
        +ДатаАрхивирования : TextField[readonly]
        +ПричинаАрхивирования : TextField[readonly]
        +КнопкаВосстановить : Button
        +КнопкаОтмена : Button
    }

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

RQ351. Требование к проверке активных назначений. Система должна проверить и отобразить:

• Список активных маршрутов, на которые назначен техник
• Список запланированных смен
• Заказы в статусе "Назначен" или "В работе"

RQ352. Требование к обязательной причине. При архивировании техника обязательно указание причины архивирования для ведения кадрового учета.

RQ353. Требование к последствиям архивирования. После архивирования:

• Техник переводится в статус "Архивирован"
• Учетная запись деактивируется (вход в систему невозможен)
• Все активные назначения снимаются
• Запланированные смены отменяются
• История работы сохраняется

RQ354. Требование к восстановлению. Система должна обеспечивать возможность восстановления архивированного техника:

• Восстановление статуса "Активен"
• Активация учетной записи
• Сохранение всей истории работы
• Возможность создания новых смен

---

Модель предметной области (связанные сущности)

Основные сущности блока "Управление техниками"

classDiagram
    class Пользователи {
        +Id : Number
        +Фамилия : String
        +Имя : String
        +Отчество : String
        +Email : String
        +Телефон : String
        +Статус : СтатусыПользователей
        +Роль : РолиПользователей
        +ДатаРегистрации : Date
        +ДатаПоследнейАктивности : Date
    }
    
    class РабочиеСмены {
        +Id : Number
        +Техник : Пользователи
        +ДатаНачала : Date
        +ВремяНачала : Time
        +БазаНачала : Базы
        +ДатаОкончания : Date
        +ВремяОкончания : Time
        +БазаОкончания : Базы
        +Статус : СтатусыСмен
        +Комментарий : String
    }
    
    class Маршруты {
        +Id : Number
        +НазначенныйТехник : Пользователи
        +ДатаВыполнения : Date
        +Статус : СтатусыМаршрутов
        +СпискЗаказов : Заказы[]
    }
    
    class СтатусыПользователей {
        <<enumeration>>
        Активен
        Неактивен
        Архивирован
    }
    
    class СтатусыСмен {
        <<enumeration>>
        Запланирована
        Активна
        Завершена
        Отменена
    }
    
    class Базы {
        +Id : Number
        +Название : String
        +Адрес : String
        +Координаты : String
    }
    
    Пользователи --> СтатусыПользователей
    РабочиеСмены --> Пользователи
    РабочиеСмены --> Базы
    РабочиеСмены --> СтатусыСмен
    Маршруты --> Пользователи

Блок «Обработка обращений клиентов»

Модель предметной области (связанные сущности)

Основные сущности блока "Обработка обращений клиентов"

classDiagram
    class ОбращенияКлиентов {
        +Id : Number
        +НомерОбращения : String
        +Клиент : Пользователи
        +ТемаОбращения : String
        +ОписаниеПроблемы : String
        +Приоритет : ПриоритетыОбращений
        +Статус : СтатусыОбращений
        +ТипОбращения : ТипыОбращений
        +СвязанныйЗаказ : Заказы
        +ДатаСоздания : Date
        +ДатаПоследнегоОтвета : Date
        +НазначенныйДиспетчер : Пользователи
        +ДатаЗакрытия : Date
        +ПричинаЗакрытия : String
    }
    
    class СообщенияПереписки {
        +Id : Number
        +Обращение : ОбращенияКлиентов
        +Автор : Пользователи
        +ТекстСообщения : String
        +ДатаСоздания : Date
        +ТипСообщения : ТипыСообщений
        +ВложенияФайлов : String[]
        +ПрочитаноКлиентом : Boolean
        +ПрочитаноДиспетчером : Boolean
    }
    
    class СтатусыОбращений {
        <<enumeration>>
        NEW
        ASSIGNED
        IN_PROGRESS
        WAITING_CLIENT
        RESOLVED
        CLOSED
        DELETED
    }
    
    class ПриоритетыОбращений {
        <<enumeration>>
        LOW
        NORMAL
        HIGH
        CRITICAL
    }
    
    class ТипыОбращений {
        <<enumeration>>
        QUESTION
        COMPLAINT
        TECHNICAL_ISSUE
        PAYMENT_ISSUE
        ORDER_RELATED
        OTHER
    }
    
    class ТипыСообщений {
        <<enumeration>>
        CLIENT_MESSAGE
        DISPATCHER_RESPONSE
        SYSTEM_MESSAGE
        INTERNAL_NOTE
    }
    
    class Пользователи {
        +Id : Number
        +Фамилия : String
        +Имя : String
        +Email : String
        +Телефон : String
        +Роль : РолиПользователей
    }
    
    class Заказы {
        +Id : Number
        +НомерЗаказа : String
        +Клиент : Пользователи
        +Статус : СтатусыЗаказов
    }
    
    ОбращенияКлиентов --> СтатусыОбращений
    ОбращенияКлиентов --> ПриоритетыОбращений
    ОбращенияКлиентов --> ТипыОбращений
    ОбращенияКлиентов --> Пользователи : Клиент
    ОбращенияКлиентов --> Пользователи : НазначенныйДиспетчер
    ОбращенияКлиентов --> Заказы
    СообщенияПереписки --> ОбращенияКлиентов
    СообщенияПереписки --> Пользователи : Автор
    СообщенияПереписки --> ТипыСообщений

---

UC045: Просмотр списка открытых обращений

Описание: Диспетчер просматривает список всех открытых обращений клиентов с возможностью фильтрации и сортировки для эффективной обработки.

Актор: Диспетчер

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел Обращения]
    A1 --> S1[Система: Загружает список открытых обращений<br/>link: СписокОткрытыхОбращений]
    S1 --> S2[Система: Отображает обращения со статусом не CLOSED, не DELETED]
    S2 --> S3[Система: Сортирует по приоритету и времени создания]
    S3 --> D1{Применить фильтры?}
    D1 -->|Да| A2[Пользователь: Устанавливает фильтры]
    D1 -->|Нет| D2{Выбрать обращение?}
    A2 --> S4[Система: Фильтрует список обращений]
    S4 --> D2
    D2 -->|Да| A3[Пользователь: Нажимает на обращение]
    D2 -->|Нет| End([Конец])
    A3 --> S5[Система: Переход к UC046 Просмотр детальной информации]
    S5 --> End

Модель интерфейсов

classDiagram
    class СписокОткрытыхОбращений {
        <<Screen>>
        +ЗаголовокСекции : ЗаголовокСоСчетчиком
        +ОбластьФильтров : ОбластьФильтровОбращений
        +СписокОбращений : КарточкаОбращения[]
        +ОбластьПагинации : ОбластьПагинации
    }
    
    class ОбластьФильтровОбращений {
        <<Area>>
        +ФильтрПоСтатусу : МультиСелект
        +ФильтрПоПриоритету : МультиСелект
        +ФильтрПоТипу : МультиСелект
        +ФильтрПоДате : ИнтервальныйФильтр
        +ПоискПоТексту : ПолеПоиска
        +КнопкаСброса : Кнопка
    }
    
    class КарточкаОбращения {
        <<Area>>
        +НомерОбращения : ТекстовыйБлок
        +ИндикаторПриоритета : ЦветнойИндикатор
        +ТемаОбращения : ТекстовыйБлок
        +ИмяКлиента : СсылкаНаПрофиль
        +ТелефонКлиента : ТекстовыйБлок
        +ВремяСоздания : ВремяОтносительное
        +СвязанныйЗаказ : СсылкаНаЗаказ
        +СтатусОбращения : СтатусныйБадж
        +КоличествоСообщений : Счетчик
        +КнопкаОтветить : Кнопка
    }
    
    СписокОткрытыхОбращений *-- ОбластьФильтровОбращений
    СписокОткрытыхОбращений *-- КарточкаОбращения

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

RQ451. Требование к загрузке открытых обращений. Система должна отображать все обращения со статусами NEW, ASSIGNED, IN_PROGRESS, WAITING_CLIENT, RESOLVED, исключая CLOSED и DELETED.

RQ452. Требование к счетчику обращений. В заголовке раздела должен отображаться счетчик открытых обращений в формате "Открытые обращения (X)".

RQ453. Требование к сортировке по умолчанию. Обращения должны сортироваться по убыванию приоритета (CRITICAL → HIGH → NORMAL → LOW), затем по времени создания (новые первыми).

RQ454. Требование к фильтрации по статусу. Система должна предоставлять мультиселект фильтр по всем активным статусам обращений.

RQ455. Требование к фильтрации по приоритету. Система должна предоставлять фильтр по уровням приоритета с цветовыми индикаторами.

RQ456. Требование к поиску. При вводе текста в поле поиска Система должна искать по вхождению подстроки в номер обращения, тему, имя клиента и описание проблемы.

RQ457. Требование к пагинации. Система должна отображать 15 обращений на странице с возможностью навигации.

RQ458. Требование к отображению приоритета. Каждая карточка должна содержать цветовой индикатор приоритета: красный (CRITICAL), оранжевый (HIGH), желтый (NORMAL), серый (LOW).

---

UC046: Просмотр детальной информации обращения

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

Актор: Диспетчер

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает на обращение в списке]
    A1 --> S1[Система: Загружает детальную информацию обращения]
    S1 --> S2[Система: Отображает основную информацию<br/>link: ДеталиОбращения]
    S2 --> S3[Система: Загружает историю переписки из СообщенияПереписки]
    S3 --> S4[Система: Отображает информацию о клиенте и связанном заказе]
    S4 --> S5[Система: Помечает сообщения как прочитанные диспетчером]
    S5 --> D1{Выбор действия}
    D1 -->|Ответить| A2[Пользователь: Нажимает Ответить]
    D1 -->|Изменить статус| A3[Пользователь: Нажимает Изменить статус]
    D1 -->|Закрыть обращение| A4[Пользователь: Нажимает Закрыть]
    D1 -->|Назначить себе| A5[Пользователь: Нажимает Взять в работу]
    D1 -->|Вернуться| A6[Пользователь: Нажимает Назад]
    A2 --> S6[Система: Переход к UC047 Ответ на обращение]
    A3 --> S7[Система: Переход к UC048 Изменение статуса]
    A4 --> S8[Система: Переход к UC049 Закрытие обращения]
    A5 --> S9[Система: Назначает текущего диспетчера на обращение]
    A6 --> End([Конец])
    S6 --> End
    S7 --> End
    S8 --> End
    S9 --> S10[Система: Обновляет статус на ASSIGNED]
    S10 --> S2

Модель интерфейсов

classDiagram
    class ДеталиОбращения {
        <<Screen>>
        +ШапкаОбращения : ОбластьОсновнойИнформации
        +ИсторияПереписки : ОбластьСообщений
        +ИнформацияОКлиенте : ОбластьИнформацииКлиента
        +ИнформацияОЗаказе : ОбластьИнформацииЗаказа
        +ПанельДействий : ОбластьКнопокДействий
    }
    
    class ОбластьОсновнойИнформации {
        <<Area>>
        +НомерОбращения : Заголовок
        +СтатусОбращения : СтатусныйБадж
        +ПриоритетОбращения : ИндикаторПриоритета
        +ТемаОбращения : ТекстовыйБлок
        +ВремяСоздания : Время
        +НазначенныйДиспетчер : ИмяПользователя
    }
    
    class ОбластьСообщений {
        <<Area>>
        +СписокСообщений : СообщениеПереписки[]
        +ИндикаторНовыхСообщений : Индикатор
    }
    
    class СообщениеПереписки {
        <<Area>>
        +АватарАвтора : Аватар
        +ИмяАвтора : ИмяПользователя
        +ВремяСообщения : Время
        +ТекстСообщения : ТекстовыйБлок
        +ВложенныеФайлы : СписокФайлов
        +ИндикаторПрочтения : ИндикаторСтатуса
    }
    
    class ОбластьКнопокДействий {
        <<Area>>
        +КнопкаОтветить : Кнопка
        +КнопкаИзменитьСтатус : Кнопка
        +КнопкаЗакрыть : Кнопка
        +КнопкаВзятьВРаботу : Кнопка
    }
    
    ДеталиОбращения *-- ОбластьОсновнойИнформации
    ДеталиОбращения *-- ОбластьСообщений
    ДеталиОбращения *-- ОбластьКнопокДействий
    ОбластьСообщений *-- СообщениеПереписки

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

RQ459. Требование к отображению основной информации. Система должна отображать номер обращения, тему, приоритет, статус, дату создания, назначенного диспетчера.

RQ460. Требование к отображению переписки. История сообщений должна отображаться в хронологическом порядке с указанием автора, времени и статуса прочтения.

RQ461. Требование к информации о клиенте. Система должна отображать ФИО клиента, контактные данные, дату регистрации и ссылку на профиль.

RQ462. Требование к информации о связанном заказе. При наличии связи с заказом должна отображаться информация: номер заказа, статус, дата и ссылка на детали заказа.

RQ463. Требование к пометке прочитанных сообщений. При открытии обращения Система должна автоматически помечать все сообщения как прочитанные диспетчером.

RQ464. Требование к доступности действий. Кнопки действий должны быть доступны в зависимости от статуса обращения и роли пользователя.

---

UC047: Ответ на обращение клиента

Описание: Диспетчер отвечает на обращение клиента, отправляя текстовое сообщение с возможностью прикрепления файлов.

Актор: Диспетчер

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Ответить на обращение]
    A1 --> S1[Система: Отображает форму ответа<br/>link: ФормаОтветаНаОбращение]
    S1 --> S2[Система: Предзаполняет контекст обращения]
    S2 --> A2[Пользователь: Вводит текст ответа]
    A2 --> D1{Прикрепить файлы?}
    D1 -->|Да| A3[Пользователь: Выбирает файлы для прикрепления]
    D1 -->|Нет| A4[Пользователь: Нажимает Отправить]
    A3 --> S3[Система: Валидирует прикрепленные файлы]
    S3 --> D2{Файлы корректны?}
    D2 -->|Нет| S4[Система: Отображает ошибки валидации]
    D2 -->|Да| A4
    S4 --> A3
    A4 --> S5[Система: Валидирует текст сообщения]
    S5 --> D3{Текст корректен?}
    D3 -->|Нет| S6[Система: Отображает ошибку валидации]
    D3 -->|Да| S7[Система: Создает запись в СообщенияПереписки]
    S6 --> A2
    S7 --> S8[Система: Сохраняет прикрепленные файлы]
    S8 --> S9[Система: Обновляет ДатаПоследнегоОтвета в обращении]
    S9 --> S10[Система: Изменяет статус обращения при необходимости]
    S10 --> S11[Система: Отправляет уведомление клиенту]
    S11 --> S12[Система: Отображает подтверждение отправки]
    S12 --> End([Конец])

Модель интерфейсов

classDiagram
    class ФормаОтветаНаОбращение {
        <<Screen>>
        +КонтекстОбращения : ОбластьКонтекста
        +ОбластьВводаТекста : ТекстовыйРедактор
        +ОбластьПрикрепления : ОбластьЗагрузкиФайлов
        +ПанельДействий : ОбластьКнопокФормы
    }
    
    class ОбластьКонтекста {
        <<Area>>
        +НомерОбращения : Текст
        +ТемаОбращения : Текст
        +ПоследнееСообщениеКлиента : ТекстовыйБлок
    }
    
    class ТекстовыйРедактор {
        <<Area>>
        +ПолеВводаТекста : ТекстоваяОбласть[2000]
        +СчетчикСимволов : Счетчик
        +ПанельФорматирования : ПанельИнструментов
    }
    
    class ОбластьЗагрузкиФайлов {
        <<Area>>
        +КнопкаВыбораФайлов : КнопкаЗагрузки
        +СписокВыбранныхФайлов : СписокФайлов
        +ОграниченияПоФайлам : ИнформационныйБлок
    }
    
    class ОбластьКнопокФормы {
        <<Area>>
        +КнопкаОтправить : Кнопка
        +КнопкаОтмена : Кнопка
        +КнопкаСохранитьЧерновик : Кнопка
    }
    
    ФормаОтветаНаОбращение *-- ОбластьКонтекста
    ФормаОтветаНаОбращение *-- ТекстовыйРедактор
    ФормаОтветаНаОбращение *-- ОбластьЗагрузкиФайлов
    ФормаОтветаНаОбращение *-- ОбластьКнопокФормы

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

RQ465. Требование к валидации текста ответа. Текст ответа не должен быть пустым и не должен превышать 2000 символов.

RQ466. Требование к прикреплению файлов. Система должна поддерживать прикрепление файлов размером до 10 МБ каждый, форматы: jpg, png, pdf, doc, docx, txt.

RQ467. Требование к созданию сообщения. При отправке ответа Система должна создать запись в СообщенияПереписки с типом DISPATCHER_RESPONSE.

RQ468. Требование к обновлению времени ответа. Система должна обновить поле ДатаПоследнегоОтвета в обращении текущим временем.

RQ469. Требование к изменению статуса. Если обращение имело статус NEW, Система должна изменить его на ASSIGNED и назначить текущего диспетчера.

RQ470. Требование к уведомлению клиента. Система должна отправить push-уведомление и email клиенту о получении ответа на обращение.

RQ471. Требование к сохранению черновика. Система должна автоматически сохранять черновик ответа каждые 30 секунд во время ввода текста.

---

UC048: Изменение статуса обращения

Описание: Диспетчер изменяет статус обращения с обязательным логированием действия и указанием причины.

Актор: Диспетчер

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Изменить статус]
    A1 --> S1[Система: Загружает текущий статус обращения]
    S1 --> S2[Система: Определяет доступные статусы для перехода]
    S2 --> S3[Система: Отображает форму изменения статуса<br/>link: ФормаИзмененияСтатуса]
    S3 --> A2[Пользователь: Выбирает новый статус]
    A2 --> A3[Пользователь: Вводит причину изменения]
    A3 --> A4[Пользователь: Нажимает Подтвердить]
    A4 --> S4[Система: Валидирует переход статуса]
    S4 --> D1{Переход разрешен?}
    D1 -->|Нет| S5[Система: Отображает ошибку и разрешенные переходы]
    D1 -->|Да| S6[Система: Обновляет статус в ОбращенияКлиентов]
    S6 --> S7[Система: Создает системное сообщение об изменении]
    S7 --> S8[Система: Обновляет метаданные обращения]
    S8 --> S9[Система: Отправляет уведомления]
    S9 --> S10[Система: Отображает подтверждение изменения]
    S10 --> End([Конец])
    S5 --> A2

Модель интерфейсов

classDiagram
    class ФормаИзмененияСтатуса {
        <<Screen>>
        +ТекущийСтатус : СтатусныйБлок
        +СелекторНовогоСтатуса : ВыпадающийСписок
        +ПолеПричины : ТекстоваяОбласть[500]
        +ИнформацияОПоследствиях : ИнформационныйБлок
        +КнопкаПодтвердить : Кнопка
        +КнопкаОтмена : Кнопка
    }
    
    class СтатусныйБлок {
        <<Area>>
        +НазваниеСтатуса : Текст
        +ЦветовойИндикатор : ИндикаторСтатуса
        +ВремяУстановки : Время
    }

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

RQ472. Требование к доступным переходам статусов. Разрешенные переходы статусов:

• NEW → ASSIGNED, IN_PROGRESS, RESOLVED, CLOSED
• ASSIGNED → IN_PROGRESS, WAITING_CLIENT, RESOLVED, CLOSED
• IN_PROGRESS → WAITING_CLIENT, RESOLVED, CLOSED
• WAITING_CLIENT → IN_PROGRESS, RESOLVED, CLOSED
• RESOLVED → CLOSED, IN_PROGRESS (переоткрытие)

RQ473. Требование к обязательной причине. При изменении статуса обязательно указание причины для аудита и истории обращения.

RQ474. Требование к созданию системного сообщения. При изменении статуса Система должна создать сообщение типа SYSTEM_MESSAGE с описанием изменения.

RQ475. Требование к уведомлениям. Система должна уведомлять клиента об изменении статуса обращения через push-уведомления и email.

RQ476. Требование к валидации статуса RESOLVED. При установке статуса RESOLVED обязательно наличие хотя бы одного ответа диспетчера в переписке.

---

UC049: Закрытие обращения

Описание: Диспетчер закрывает обращение клиента с указанием причины закрытия и финальным комментарием.

Актор: Диспетчер

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Закрыть обращение]
    A1 --> S1[Система: Проверяет возможность закрытия]
    S1 --> D1{Обращение можно закрыть?}
    D1 -->|Нет| S2[Система: Отображает сообщение об ошибке]
    D1 -->|Да| S3[Система: Отображает форму закрытия<br/>link: ФормаЗакрытияОбращения]
    S3 --> A2[Пользователь: Выбирает причину закрытия]
    A2 --> A3[Пользователь: Вводит финальный комментарий]
    A3 --> D2{Запросить оценку у клиента?}
    D2 -->|Да| A4[Пользователь: Устанавливает флаг запроса оценки]
    D2 -->|Нет| A5[Пользователь: Нажимает Закрыть обращение]
    A4 --> A5
    A5 --> S4[Система: Валидирует данные формы]
    S4 --> D3{Данные корректны?}
    D3 -->|Нет| S5[Система: Отображает ошибки валидации]
    D3 -->|Да| S6[Система: Устанавливает статус CLOSED]
    S5 --> A2
    S6 --> S7[Система: Сохраняет причину и дату закрытия]
    S7 --> S8[Система: Создает финальное сообщение]
    S8 --> S9[Система: Отправляет уведомление клиенту]
    S9 --> D4{Запрашивать оценку?}
    D4 -->|Да| S10[Система: Отправляет запрос оценки клиенту]
    D4 -->|Нет| S11[Система: Отображает подтверждение закрытия]
    S10 --> S11
    S11 --> End([Конец])
    S2 --> End

Модель интерфейсов

classDiagram
    class ФормаЗакрытияОбращения {
        <<Screen>>
        +ИнформацияОбОбращении : ОбластьКонтекста
        +ВыборПричиныЗакрытия : ВыпадающийСписок
        +ПолеФинальногоКомментария : ТекстоваяОбласть[1000]
        +ЧекбоксЗапросаОценки : ЧекБокс
        +ИнформацияОПоследствиях : ИнформационныйБлок
        +КнопкаЗакрыть : Кнопка
        +КнопкаОтмена : Кнопка
    }

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

RQ477. Требование к возможности закрытия. Закрытие обращения доступно для статусов RESOLVED, IN_PROGRESS, WAITING_CLIENT, ASSIGNED.

RQ478. Требование к причинам закрытия. Система должна предоставлять справочник причин: "Проблема решена", "Дубликат обращения", "Неактуальный вопрос", "По запросу клиента", "Другое".

RQ479. Требование к финальному комментарию. Финальный комментарий не должен превышать 1000 символов и должен быть обязательным для причины "Другое".

RQ480. Требование к сохранению данных закрытия. При закрытии Система должна сохранить: дату закрытия, причину закрытия, финальный комментарий, диспетчера, закрывшего обращение.

RQ481. Требование к запросу оценки. При установке флага запроса оценки Система должна отправить клиенту отдельное уведомление с просьбой оценить качество обработки обращения.

RQ482. Требование к автоматическому закрытию. Обращения со статусом RESOLVED должны автоматически закрываться через 72 часа, если клиент не отвечает.

---

UC050: Просмотр истории переписки по обращению

Описание: Диспетчер просматривает полную историю переписки по обращению в удобном формате с возможностью поиска и фильтрации сообщений.

Актор: Диспетчер

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Нажимает Просмотр истории]
    A1 --> S1[Система: Загружает все сообщения обращения<br/>link: ИсторияПереписки]
    S1 --> S2[Система: Сортирует сообщения по дате создания]
    S2 --> S3[Система: Отображает сообщения с группировкой по дням]
    S3 --> D1{Применить фильтры?}
    D1 -->|Да| A2[Пользователь: Устанавливает фильтры по типу сообщений]
    D1 -->|Нет| D2{Поиск по тексту?}
    A2 --> S4[Система: Фильтрует сообщения по выбранным типам]
    S4 --> D2
    D2 -->|Да| A3[Пользователь: Вводит текст для поиска]
    D2 -->|Нет| D3{Экспорт истории?}
    A3 --> S5[Система: Выполняет поиск по тексту сообщений]
    S5 --> S6[Система: Подсвечивает найденные совпадения]
    S6 --> D3
    D3 -->|Да| A4[Пользователь: Нажимает Экспортировать]
    D3 -->|Нет| End([Конец])
    A4 --> S7[Система: Генерирует файл с историей переписки]
    S7 --> S8[Система: Предлагает скачать файл]
    S8 --> End

Модель интерфейсов

classDiagram
    class ИсторияПереписки {
        <<Screen>>
        +ПанельФильтров : ОбластьФильтровИстории
        +ОбластьСообщений : ОбластьХронологииСообщений
        +ПанельДействий : ОбластьДействийИстории
    }
    
    class ОбластьФильтровИстории {
        <<Area>>
        +ФильтрПоТипуСообщения : МультиСелект
        +ФильтрПоАвтору : ВыпадающийСписок
        +ФильтрПоДате : ИнтервальныйФильтр
        +ПоискПоТексту : ПолеПоиска
        +КнопкаСброса : Кнопка
    }
    
    class ОбластьХронологииСообщений {
        <<Area>>
        +ГруппыПоДням : ГруппаСообщенийДня[]
        +ИндикаторПрокрутки : СкроллБар
    }
    
    class ГруппаСообщенийДня {
        <<Area>>
        +ЗаголовокДня : ДатовыйЗаголовок
        +СписокСообщений : СообщениеВИстории[]
    }
    
    class СообщениеВИстории {
        <<Area>>
        +АватарАвтора : Аватар
        +ИмяАвтора : ИмяПользователя
        +ВремяСообщения : Время
        +ТипСообщения : БаджТипа
        +ТекстСообщения : ТекстовыйБлок
        +ВложенныеФайлы : СписокФайлов
        +СтатусПрочтения : ИндикаторПрочтения
    }
    
    class ОбластьДействийИстории {
        <<Area>>
        +КнопкаЭкспорта : Кнопка
        +СтатистикаСообщений : ИнформационныйБлок
    }
    
    ИсторияПереписки *-- ОбластьФильтровИстории
    ИсторияПереписки *-- ОбластьХронологииСообщений
    ИсторияПереписки *-- ОбластьДействийИстории
    ОбластьХронологииСообщений *-- ГруппаСообщенийДня
    ГруппаСообщенийДня *-- СообщениеВИстории

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

RQ483. Требование к загрузке истории. Система должна загружать все сообщения обращения из таблицы СообщенияПереписки, включая удаленные сообщения (для аудита).

RQ484. Требование к группировке по дням. Сообщения должны группироваться по дням с отображением даты в качестве заголовка группы.

RQ485. Требование к фильтрации по типу. Система должна предоставлять фильтр по типам сообщений: клиентские сообщения, ответы диспетчера, системные сообщения, внутренние заметки.

RQ486. Требование к поиску по тексту. Поиск должен выполняться по полному тексту сообщений с подсветкой найденных совпадений.

RQ487. Требование к экспорту истории. Система должна поддерживать экспорт полной истории переписки в форматах PDF и CSV с сохранением структуры и метаданных.

RQ488. Требование к статистике. В нижней части должна отображаться статистика: общее количество сообщений, количество по типам, период переписки.

RQ489. Требование к производительности. Загрузка истории переписки не должна превышать 3 секунд для обращений с количеством сообщений до 1000.

---

Общие требования к блоку "Обработка обращений клиентов"

Требования к безопасности и авторизации

RQ490. Требование к авторизации. Все функции блока доступны только пользователям с ролями ДИСПЕТЧЕР или АДМИНИСТРАТОР.

RQ491. Требование к аудиту действий. Все действия диспетчера должны логироваться с указанием типа операции, идентификатора обращения, пользователя-инициатора, времени операции.

Требования к производительности

RQ494. Требование к real-time обновлениям. Новые сообщения и изменения статусов должны отображаться в интерфейсе в реальном времени через WebSocket-соединение.

Требования к интеграции

RQ495. Требование к уведомлениям. Система должна интегрироваться с сервисом уведомлений для отправки push-уведомлений в мобильное приложение

RQ496. Требование к файловому хранилищу. Прикрепленные к сообщениям файлы должны сохраняться в безопасном файловом хранилище с ограниченным доступом.

Блок «Управление справочниками»

Общее описание блока

Блок предназначен для комплексного управления справочной информацией системы MobileCharge. Блок обеспечивает централизованное ведение всех справочников, используемых в различных модулях системы, с разграничением прав доступа по ролям.

Основные возможности блока:

• Ведение справочников производителей и моделей зарядных станций
• Управление каталогом брендов и моделей автомобилей
• Настройка тарифной системы и зон обслуживания
• Управление типами коннекторов и причинами отмены заказов
• Ведение справочника типов операций техников
• Контроль целостности и консистентности справочных данных

Права доступа:

• Диспетчер: только просмотр справочников (R)
• Администратор: полные права CRUD для всех справочников

---

Диаграмма Use Case

graph TD
    subgraph "Блок: Управление справочниками"
        Администратор[Администратор]
        Диспетчер[Диспетчер]
        
        UC051[UC051. Управление справочником<br/>Производители станций]
        UC052[UC052. Управление справочником<br/>Модели зарядных станций]
        UC053[UC053. Управление справочником<br/>Бренды автомобилей]
        UC054[UC054. Управление справочником<br/>Модели автомобилей]
        UC055[UC055. Управление справочником<br/>Тарифы]
        UC056[UC056. Управление справочником<br/>Зоны обслуживания]
        UC057[UC057. Управление справочником<br/>Типы коннекторов]
        UC058[UC058. Управление справочником<br/>Причины отмены заказов]
        UC059[UC059. Управление справочником<br/>Типы операций техников]
        
        Администратор --> UC051
        Администратор --> UC052
        Администратор --> UC053
        Администратор --> UC054
        Администратор --> UC055
        Администратор --> UC056
        Администратор --> UC057
        Администратор --> UC058
        Администратор --> UC059
        
        Диспетчер -.->|только просмотр| UC051
        Диспетчер -.->|только просмотр| UC052
        Диспетчер -.->|только просмотр| UC053
        Диспетчер -.->|только просмотр| UC054
        Диспетчер -.->|только просмотр| UC055
        Диспетчер -.->|только просмотр| UC056
        Диспетчер -.->|только просмотр| UC057
        Диспетчер -.->|только просмотр| UC058
        Диспетчер -.->|только просмотр| UC059
    end

---

UC051: Управление справочником "Производители станций"

Актор: Администратор

Описание: Администратор управляет справочником производителей зарядных станций, включая добавление новых производителей, редактирование контактной информации и деактивацию записей.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Производители станций']
    A1 --> S1[Система: Загружает список производителей из Manufacturers]
    S1 --> S2[Система: Отображает справочник производителей<br/>ссылка: СправочникПроизводителей]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить производителя']
    D1 -->|Редактировать| A3[Пользователь: Нажимает на производителя]
    D1 -->|Поиск/фильтр| A4[Пользователь: Вводит критерии поиска]
    A2 --> S3[Система: Отображает форму создания<br/>ссылка: ФормаПроизводителя]
    A3 --> S4[Система: Отображает форму редактирования<br/>ссылка: ФормаПроизводителя]
    A4 --> S5[Система: Применяет фильтр и обновляет список]
    S3 --> A5[Пользователь: Заполняет данные производителя]
    S4 --> A6[Пользователь: Изменяет данные производителя]
    A5 --> A7[Пользователь: Нажимает 'Сохранить']
    A6 --> A8[Пользователь: Нажимает 'Сохранить']
    A7 --> S6[Система: Валидирует данные]
    A8 --> S7[Система: Валидирует изменения]
    S6 --> D2{Данные корректны?}
    S7 --> D3{Данные корректны?}
    D2 -->|Нет| S8[Система: Отображает ошибки валидации]
    D3 -->|Нет| S9[Система: Отображает ошибки валидации]
    D2 -->|Да| S10[Система: Создает запись в Manufacturers]
    D3 -->|Да| S11[Система: Обновляет запись в Manufacturers]
    S10 --> S12[Система: Отображает подтверждение создания]
    S11 --> S13[Система: Отображает подтверждение обновления]
    S5 --> S2
    S8 --> A5
    S9 --> A6
    S12 --> End([Конец])
    S13 --> End

Модель интерфейсов

classDiagram
    class СправочникПроизводителей {
        <<Screen>>
        +ОбластьПоиска : ОбластьПоискаПроизводителей
        +ТаблицаПроизводителей : ТаблицаПроизводителей
        +КнопкаДобавить : Button
    }
    
    class ОбластьПоискаПроизводителей {
        <<Area>>
        +ПоискПоНазванию : TextField[100]
        +КнопкаПоиск : Button
        +КнопкаСброс : Button
    }
    
    class ТаблицаПроизводителей {
        <<Area>>
        +СтолбецНазвание : TableColumn
        +СтолбецКонтактноеЛицо : TableColumn
        +СтолбецТелефон : TableColumn
        +СтолбецEmail : TableColumn
        +СтолбецДействия : TableColumn
    }
    
    class ФормаПроизводителя {
        <<Screen>>
        +НазваниеПроизводителя : TextField[100]*
        +КонтактноеЛицо : TextField[100]
        +КонтактныйТелефон : TextField[20]
        +КонтактныйEmail : TextField[100]
        +ВебСайт : TextField[255]
        +Адрес : TextArea[500]
        +Примечания : TextArea[1000]
        +КнопкаСохранить : Button
        +КнопкаОтмена : Button
    }
    
    СправочникПроизводителей *-- ОбластьПоискаПроизводителей
    СправочникПроизводителей *-- ТаблицаПроизводителей

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

RQ500. Требование к отображению списка производителей. Система должна отображать список всех активных производителей с основной информацией: название, контактное лицо, телефон, email.

RQ501. Требование к функции поиска. Система должна обеспечивать поиск по названию производителя с поддержкой частичного совпадения.

RQ502. Требование к валидации при создании. При создании производителя обязательно заполнение поля "Название". Система должна проверять уникальность названия среди всех записей Manufacturers.

RQ503. Требование к валидации контактных данных. При заполнении email Система должна проверять корректность формата. При заполнении телефона допустимы только цифры и символы +, -, (, ), пробел.

RQ504. Требование к автоматическим полям. При создании производителя Система должна автоматически установить: createdBy = текущий администратор, createdAt = текущее время, isDeleted = false.

RQ505. Требование к связанным записям. Перед удалением производителя Система должна проверить наличие связанных моделей зарядных станций в ChargingStationModels и предупредить о невозможности удаления при их наличии.

---

UC052: Управление справочником "Модели зарядных станций"

Актор: Администратор

Описание: Администратор управляет справочником моделей зарядных станций с их техническими характеристиками и привязкой к производителям.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Модели станций']
    A1 --> S1[Система: Загружает список моделей из ChargingStationModels]
    S1 --> S2[Система: Отображает справочник моделей<br/>ссылка: СправочникМоделейСтанций]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить модель']
    D1 -->|Редактировать| A3[Пользователь: Нажимает на модель]
    D1 -->|Фильтр| A4[Пользователь: Выбирает фильтр по производителю]
    A2 --> S3[Система: Отображает форму создания модели<br/>ссылка: ФормаМоделиСтанции]
    A3 --> S4[Система: Загружает данные модели]
    A4 --> S5[Система: Применяет фильтр по производителю]
    S4 --> S6[Система: Отображает форму редактирования<br/>ссылка: ФормаМоделиСтанции]
    S3 --> A5[Пользователь: Выбирает производителя]
    S6 --> A6[Пользователь: Изменяет параметры модели]
    A5 --> A7[Пользователь: Заполняет технические характеристики]
    A6 --> A8[Пользователь: Нажимает 'Сохранить']
    A7 --> A9[Пользователь: Нажимает 'Сохранить']
    A8 --> S7[Система: Валидирует изменения]
    A9 --> S8[Система: Валидирует данные]
    S7 --> D2{Данные корректны?}
    S8 --> D3{Данные корректны?}
    D2 -->|Да| S9[Система: Обновляет ChargingStationModels]
    D3 -->|Да| S10[Система: Создает запись в ChargingStationModels]
    D2 -->|Нет| S11[Система: Отображает ошибки]
    D3 -->|Нет| S12[Система: Отображает ошибки]
    S5 --> S2
    S9 --> End([Конец])
    S10 --> End
    S11 --> A6
    S12 --> A7

Модель интерфейсов

classDiagram
    class СправочникМоделейСтанций {
        <<Screen>>
        +ФильтрПроизводитель : DropDown
        +ТаблицаМоделей : ТаблицаМоделейСтанций
        +КнопкаДобавить : Button
    }
    
    class ТаблицаМоделейСтанций {
        <<Area>>
        +СтолбецПроизводитель : TableColumn
        +СтолбецНазвание : TableColumn
        +СтолбецМощность : TableColumn
        +СтолбецКоличествоПортов : TableColumn
        +СтолбецТипыКоннекторов : TableColumn
        +СтолбецДействия : TableColumn
    }
    
    class ФормаМоделиСтанции {
        <<Screen>>
        +ПроизводительСтанции : DropDown*
        +НазваниеМодели : TextField[100]*
        +МощностьКВт : NumberField*
        +КоличествоПортов : NumberField*
        +ПоддерживаемыеКоннекторы : MultiSelect*
        +МаксимальныйТокА : NumberField*
        +ВходноеНапряжение : NumberField*
        +ВыходныеНапряжения : TextField[100]
        +ВесКг : NumberField
        +Габариты : TextField[100]
        +СтепеньЗащитыIP : TextField[10]
        +РабочаяТемпература : TextField[50]
        +ТипОхлаждения : TextField[50]
        +ДополнительныеХарактеристики : TextArea[1000]
        +КнопкаСохранить : Button
        +КнопкаОтмена : Button
    }
    
    СправочникМоделейСтанций *-- ТаблицаМоделейСтанций

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

RQ506. Требование к обязательным полям модели. При создании модели обязательны: производитель, название модели, мощность (кВт), количество портов, поддерживаемые коннекторы, максимальный ток, входное напряжение.

RQ507. Требование к уникальности модели. Система должна проверять уникальность комбинации idManufacturer + name среди всех записей ChargingStationModels.

RQ508. Требование к валидации технических параметров. Система должна проверять:

• Мощность > 0 кВт
• Количество портов >= 1
• Максимальный ток > 0 А
• Входное напряжение в допустимых значениях (110, 220, 380, 400В)

RQ509. Требование к типам коннекторов. Поле supportedConnectors должно содержать один или несколько значений из enum ConnectorType: TYPE1, TYPE2, CCS, CHADEMO, TESLA_SUC, TESLA_CCS, GB_T.

RQ510. Требование к проверке связанных станций. Перед удалением модели Система должна проверить наличие станций данной модели в ChargingStations и запретить удаление при их наличии.

---

UC053: Управление справочником "Бренды автомобилей"

Актор: Администратор

Описание: Администратор управляет справочником брендов автомобилей с возможностью синхронизации с внешним источником open-ev-data.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Бренды автомобилей']
    A1 --> S1[Система: Загружает список брендов из VehicleBrands]
    S1 --> S2[Система: Отображает справочник брендов<br/>ссылка: СправочникБрендовАвтомобилей]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить бренд']
    D1 -->|Синхронизация| A3[Пользователь: Нажимает 'Синхронизировать с open-ev-data']
    D1 -->|Редактировать| A4[Пользователь: Нажимает на бренд]
    A2 --> S3[Система: Отображает форму создания бренда<br/>ссылка: ФормаБрендаАвтомобиля]
    A3 --> S4[Система: Подключается к API open-ev-data]
    A4 --> S5[Система: Отображает форму редактирования<br/>ссылка: ФормаБрендаАвтомобиля]
    S4 --> S6[Система: Загружает актуальные данные брендов]
    S3 --> A5[Пользователь: Заполняет данные бренда]
    S5 --> A6[Пользователь: Изменяет данные бренда]
    S6 --> S7[Система: Сопоставляет с существующими брендами]
    A5 --> A7[Пользователь: Нажимает 'Сохранить']
    A6 --> A8[Пользователь: Нажимает 'Сохранить']
    S7 --> S8[Система: Обновляет/создает записи в VehicleBrands]
    A7 --> S9[Система: Валидирует данные]
    A8 --> S10[Система: Валидирует изменения]
    S8 --> S11[Система: Отображает отчет о синхронизации]
    S9 --> D2{Данные корректны?}
    S10 --> D3{Данные корректны?}
    D2 -->|Да| S12[Система: Создает запись в VehicleBrands]
    D3 -->|Да| S13[Система: Обновляет запись в VehicleBrands]
    S11 --> End([Конец])
    S12 --> End
    S13 --> End

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

RQ511. Требование к обязательным полям бренда. При создании бренда обязательно поле "Название". Система должна проверять уникальность названия среди всех записей VehicleBrands.

RQ512. Требование к синхронизации с open-ev-data. При синхронизации Система должна:

• Сопоставлять бренды по названию
• Обновлять externalId для существующих брендов
• Создавать новые бренды из внешнего источника
• Сохранять ссылку на файл моделей в поле modelsFile

RQ513. Требование к отчету синхронизации. После синхронизации Система должна отобразить отчет: количество добавленных брендов, количество обновленных записей, список ошибок.

RQ514. Требование к проверке связанных моделей. Перед удалением бренда Система должна проверить наличие связанных моделей в VehicleModels и запретить удаление при их наличии.

---

UC054: Управление справочником "Модели автомобилей"

Актор: Администратор

Описание: Администратор управляет справочником моделей автомобилей с их техническими характеристиками и возможностями зарядки.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Модели автомобилей']
    A1 --> S1[Система: Загружает список моделей из VehicleModels]
    S1 --> S2[Система: Отображает справочник моделей<br/>ссылка: СправочникМоделейАвтомобилей]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить модель']
    D1 -->|Фильтр по бренду| A3[Пользователь: Выбирает фильтр по бренду]
    D1 -->|Синхронизация| A4[Пользователь: Нажимает 'Синхронизировать модели бренда']
    A2 --> S3[Система: Отображает форму создания модели<br/>ссылка: ФормаМоделиАвтомобиля]
    A3 --> S4[Система: Применяет фильтр по бренду]
    A4 --> S5[Система: Загружает модели выбранного бренда из open-ev-data]
    S3 --> A5[Пользователь: Выбирает бренд автомобиля]
    S4 --> S2
    S5 --> S6[Система: Обновляет/создает записи моделей]
    A5 --> A6[Пользователь: Заполняет характеристики модели]
    S6 --> S7[Система: Отображает отчет о синхронизации]
    A6 --> A7[Пользователь: Настраивает параметры зарядки]
    S7 --> End([Конец])
    A7 --> A8[Пользователь: Нажимает 'Сохранить']
    A8 --> S8[Система: Валидирует данные модели]
    S8 --> D2{Данные корректны?}
    D2 -->|Да| S9[Система: Создает запись в VehicleModels]
    D2 -->|Нет| S10[Система: Отображает ошибки валидации]
    S9 --> End
    S10 --> A6

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

RQ515. Требование к обязательным полям модели автомобиля. При создании модели обязательны: бренд, название модели, год выпуска, емкость батареи, напряжение зарядки, порты AC, максимальная мощность AC.

RQ516. Требование к уникальности модели автомобиля. Система должна проверять уникальность комбинации idVehicleBrand + model + variant + releaseYear + releaseMonth.

RQ517. Требование к валидации параметров зарядки. Система должна проверять:

• usableBatterySize > 0 кВт·ч
• chargingVoltage в допустимых значениях (48, 400, 800В)
• acMaxPower > 0 кВт
• dcMaxPower > 0 кВт (если указано)

RQ518. Требование к кривой зарядки DC. Поле dcChargingCurve должно содержать массив объектов {percentage: число, power: число}, где percentage от 0 до 100, power > 0.

---

UC055: Управление справочником "Тарифы"

Актор: Администратор

Описание: Администратор управляет тарифной системой, включая создание тарифных планов, настройку ценообразования и условий применения.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Тарифы']
    A1 --> S1[Система: Загружает список тарифов]
    S1 --> S2[Система: Отображает справочник тарифов<br/>ссылка: СправочникТарифов]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить тариф']
    D1 -->|Редактировать| A3[Пользователь: Нажимает на тариф]
    D1 -->|Деактивировать| A4[Пользователь: Нажимает 'Деактивировать']
    A2 --> S3[Система: Отображает форму создания тарифа<br/>ссылка: ФормаТарифа]
    A3 --> S4[Система: Отображает форму редактирования<br/>ссылка: ФормаТарифа]
    A4 --> S5[Система: Деактивирует тариф]
    S3 --> A5[Пользователь: Заполняет основные параметры тарифа]
    S4 --> A6[Пользователь: Изменяет параметры тарифа]
    S5 --> S6[Система: Обновляет статус тарифа на неактивный]
    A5 --> A7[Пользователь: Настраивает ценообразование]
    A6 --> A8[Пользователь: Нажимает 'Сохранить']
    S6 --> End([Конец])
    A7 --> A9[Пользователь: Устанавливает условия применения]
    A8 --> S7[Система: Валидирует изменения]
    A9 --> A10[Пользователь: Нажимает 'Сохранить']
    S7 --> D2{Данные корректны?}
    A10 --> S8[Система: Валидирует данные тарифа]
    D2 -->|Да| S9[Система: Обновляет тариф]
    S8 --> D3{Данные корректны?}
    D2 -->|Нет| S10[Система: Отображает ошибки]
    D3 -->|Да| S11[Система: Создает новый тариф]
    D3 -->|Нет| S12[Система: Отображает ошибки валидации]
    S9 --> End
    S10 --> A6
    S11 --> End
    S12 --> A5

Модель интерфейсов

classDiagram
    class СправочникТарифов {
        <<Screen>>
        +ФильтрПоСтатусу : DropDown
        +ТаблицаТарифов : ТаблицаТарифов
        +КнопкаДобавить : Button
    }
    
    class ТаблицаТарифов {
        <<Area>>
        +СтолбецНазвание : TableColumn
        +СтолбецТипТарифа : TableColumn
        +СтолбецБазоваяСтоимость : TableColumn
        +СтолбецСтоимостьЗаКВтЧ : TableColumn
        +СтолбецСтатус : TableColumn
        +СтолбецДействия : TableColumn
    }
    
    class ФормаТарифа {
        <<Screen>>
        +НазваниеТарифа : TextField[100]*
        +ОписаниеТарифа : TextArea[500]
        +ТипТарифа : DropDown*
        +БазоваяСтоимость : NumberField
        +СтоимостьЗаКВтЧ : NumberField*
        +МинимальнаяСтоимость : NumberField
        +МаксимальнаяСтоимость : NumberField
        +ДатаНачалаДействия : DateField*
        +ДатаОкончанияДействия : DateField
        +ВремяНачалаДействия : TimeField
        +ВремяОкончанияДействия : TimeField
        +ДниНедели : MultiSelect
        +ПриоритетПрименения : NumberField
        +АктивенТариф : Checkbox
        +КнопкаСохранить : Button
        +КнопкаОтмена : Button
    }
    
    СправочникТарифов *-- ТаблицаТарифов

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

RQ519. Требование к обязательным полям тарифа. При создании тарифа обязательны: название, тип тарифа, стоимость за кВт·ч, дата начала действия.

RQ520. Требование к типам тарифов. Система должна поддерживать типы тарифов: "Базовый", "Экстренный", "Плановый", "Ночной", "Льготный".

RQ521. Требование к валидации стоимостных параметров. Система должна проверять:

• СтоимостьЗаКВтЧ > 0
• БазоваяСтоимость >= 0
• МинимальнаяСтоимость <= МаксимальнаяСтоимость (если указаны)

RQ522. Требование к периодам действия. При указании времени действия должны быть заполнены оба поля: время начала И время окончания. Время начала должно быть меньше времени окончания.

RQ523. Требование к контролю пересечений тарифов. Система должна предупреждать о пересечении периодов действия тарифов одного типа.

---

UC056: Управление справочником "Зоны обслуживания"

Актор: Администратор

Описание: Администратор управляет географическими зонами обслуживания для планирования маршрутов и определения доступности услуг.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Зоны обслуживания']
    A1 --> S1[Система: Загружает список зон обслуживания]
    S1 --> S2[Система: Отображает справочник зон<br/>ссылка: СправочникЗонОбслуживания]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить зону']
    D1 -->|Редактировать| A3[Пользователь: Нажимает на зону]
    D1 -->|Просмотр на карте| A4[Пользователь: Нажимает 'Показать на карте']
    A2 --> S3[Система: Отображает форму создания зоны<br/>ссылка: ФормаЗоныОбслуживания]
    A3 --> S4[Система: Отображает форму редактирования<br/>ссылка: ФормаЗоныОбслуживания]
    A4 --> S5[Система: Отображает карту с границами зон]
    S3 --> A5[Пользователь: Заполняет название и описание]
    S4 --> A6[Пользователь: Изменяет параметры зоны]
    S5 --> A7[Пользователь: Просматривает границы зон]
    A5 --> A8[Пользователь: Указывает границы зоны на карте]
    A6 --> A9[Пользователь: Нажимает 'Сохранить']
    A7 --> End([Конец])
    A8 --> A10[Пользователь: Устанавливает приоритет зоны]
    A9 --> S6[Система: Валидирует изменения]
    A10 --> A11[Пользователь: Нажимает 'Сохранить']
    S6 --> D2{Данные корректны?}
    A11 --> S7[Система: Валидирует данные зоны]
    D2 -->|Да| S8[Система: Обновляет зону обслуживания]
    S7 --> D3{Данные корректны?}
    D2 -->|Нет| S9[Система: Отображает ошибки]
    D3 -->|Да| S10[Система: Создает новую зону обслуживания]
    D3 -->|Нет| S11[Система: Отображает ошибки валидации]
    S8 --> End
    S9 --> A6
    S10 --> End
    S11 --> A5

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

RQ524. Требование к обязательным полям зоны обслуживания. При создании зоны обязательны: название, границы зоны (координаты), приоритет обслуживания.

RQ525. Требование к формату границ зоны. Границы зоны должны быть представлены в формате GeoJSON полигона с валидными координатами широты и долготы.

RQ526. Требование к валидации приоритета. Приоритет обслуживания должен быть числом от 1 до 10, где 1 - наивысший приоритет.

RQ527. Требование к проверке пересечений зон. Система должна предупреждать о пересечении границ зон и позволять их существование с разными приоритетами.

RQ528. Требование к отображению на карте. Система должна отображать все зоны обслуживания на интерактивной карте с цветовым кодированием по приоритетам.

---

UC057: Управление справочником "Типы коннекторов"

Актор: Администратор

Описание: Администратор управляет справочником типов коннекторов для зарядки электромобилей с их техническими характеристиками.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Типы коннекторов']
    A1 --> S1[Система: Загружает список типов коннекторов из enum ConnectorType]
    S1 --> S2[Система: Отображает справочник коннекторов<br/>ссылка: СправочникТиповКоннекторов]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Просмотр описания| A2[Пользователь: Нажимает на тип коннектора]
    D1 -->|Редактировать описание| A3[Пользователь: Нажимает 'Редактировать']
    A2 --> S3[Система: Отображает детальную информацию коннектора<br/>ссылка: ИнформацияОКоннекторе]
    A3 --> S4[Система: Отображает форму редактирования описания<br/>ссылка: ФормаОписанияКоннектора]
    S3 --> A4[Пользователь: Просматривает характеристики]
    S4 --> A5[Пользователь: Редактирует описание и характеристики]
    A4 --> End([Конец])
    A5 --> A6[Пользователь: Нажимает 'Сохранить']
    A6 --> S5[Система: Сохраняет изменения в метаданных]
    S5 --> End

Модель интерфейсов

classDiagram
    class СправочникТиповКоннекторов {
        <<Screen>>
        +ТаблицаКоннекторов : ТаблицаТиповКоннекторов
    }
    
    class ТаблицаТиповКоннекторов {
        <<Area>>
        +СтолбецТипКоннектора : TableColumn
        +СтолбецНазвание : TableColumn
        +СтолбецТипЗарядки : TableColumn
        +СтолбецМаксМощность : TableColumn
        +СтолбецОписание : TableColumn
        +СтолбецДействия : TableColumn
    }
    
    class ИнформацияОКоннекторе {
        <<Screen>>
        +ТипКоннектора : Label
        +НазваниеКоннектора : Label
        +ТипЗарядки : Label
        +МаксимальнаяМощность : Label
        +НоминальныйТок : Label
        +РабочееНапряжение : Label
        +СтандартПротокола : Label
        +ОписаниеКоннектора : TextArea
        +КнопкаРедактировать : Button
    }
    
    СправочникТиповКоннекторов *-- ТаблицаТиповКоннекторов

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

RQ529. Требование к отображению типов коннекторов. Система должна отображать все значения из enum ConnectorType: TYPE1, TYPE2, CCS, CHADEMO, TESLA_SUC, TESLA_CCS, GB_T.

RQ530. Требование к характеристикам коннекторов. Для каждого типа коннектора должны быть определены: полное название, тип зарядки (AC/DC), максимальная мощность, номинальный ток, рабочее напряжение, стандарт протокола.

RQ531. Требование к предустановленным данным. Система должна содержать предустановленные характеристики для всех типов коннекторов согласно международным стандартам.

RQ532. Требование к редактированию описаний. Администратор может редактировать только описания и дополнительные примечания, но не технические характеристики стандартизированных коннекторов.

---

UC058: Управление справочником "Причины отмены заказов"

Актор: Администратор

Описание: Администратор управляет справочником причин отмены заказов, используемых клиентами и диспетчерами при отмене заказов.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Причины отмены заказов']
    A1 --> S1[Система: Загружает список причин отмены]
    S1 --> S2[Система: Отображает справочник причин<br/>ссылка: СправочникПричинОтмены]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить причину']
    D1 -->|Редактировать| A3[Пользователь: Нажимает на причину]
    D1 -->|Деактивировать| A4[Пользователь: Нажимает 'Деактивировать']
    A2 --> S3[Система: Отображает форму создания причины<br/>ссылка: ФормаПричиныОтмены]
    A3 --> S4[Система: Отображает форму редактирования<br/>ссылка: ФормаПричиныОтмены]
    A4 --> S5[Система: Деактивирует причину]
    S3 --> A5[Пользователь: Заполняет данные причины]
    S4 --> A6[Пользователь: Изменяет данные причины]
    S5 --> S6[Система: Помечает причину как неактивную]
    A5 --> A7[Пользователь: Нажимает 'Сохранить']
    A6 --> A8[Пользователь: Нажимает 'Сохранить']
    S6 --> End([Конец])
    A7 --> S7[Система: Валидирует данные]
    A8 --> S8[Система: Валидирует изменения]
    S7 --> D2{Данные корректны?}
    S8 --> D3{Данные корректны?}
    D2 -->|Да| S9[Система: Создает новую причину]
    D3 -->|Да| S10[Система: Обновляет причину]
    D2 -->|Нет| S11[Система: Отображает ошибки]
    D3 -->|Нет| S12[Система: Отображает ошибки]
    S9 --> End
    S10 --> End
    S11 --> A5
    S12 --> A6

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

RQ533. Требование к предустановленным причинам. Система должна содержать стандартный набор причин отмены:

• "Передумал / Не нужна зарядка"
• "Поменялись планы"
• "Указал неверные данные (местоположение, время)"
• "Нашел альтернативный способ зарядки"
• "Слишком долгое ожидание"
• "Техническая проблема в приложении"
• "Другое"

RQ534. Требование к обязательным полям причины. При создании причины обязательны: текст причины, тип инициатора (клиент/диспетчер/система), порядок отображения.

RQ535. Требование к уникальности причин. Система должна проверять уникальность текста причины в рамках одного типа инициатора.

RQ536. Требование к флагу "Требует комментария". Для причин типа "Другое" должен быть установлен флаг, требующий обязательного ввода комментария пользователем.

RQ537. Требование к проверке использования. Перед удалением причины Система должна проверить её использование в истории заказов и запретить удаление при наличии связанных записей.

---

UC059: Управление справочником "Типы операций техников"

Актор: Администратор

Описание: Администратор управляет справочником типов операций, выполняемых техниками в процессе работы с заказами.

Activity-диаграмма (Диаграмма деятельности)

graph TD
    Start([Начало]) --> A1[Пользователь: Переходит в раздел 'Типы операций техников']
    A1 --> S1[Система: Загружает список типов операций]
    S1 --> S2[Система: Отображает справочник операций<br/>ссылка: СправочникТиповОпераций]
    S2 --> D1{Пользователь выбирает действие}
    D1 -->|Добавить| A2[Пользователь: Нажимает 'Добавить тип операции']
    D1 -->|Редактировать| A3[Пользователь: Нажимает на тип операции]
    A2 --> S3[Система: Отображает форму создания операции<br/>ссылка: ФормаТипаОперации]
    A3 --> S4[Система: Отображает форму редактирования<br/>ссылка: ФормаТипаОперации]
    S3 --> A4[Пользователь: Заполняет данные операции]
    S4 --> A5[Пользователь: Изменяет данные операции]
    A4 --> A6[Пользователь: Устанавливает временные нормативы]
    A5 --> A7[Пользователь: Нажимает 'Сохранить']
    A6 --> A8[Пользователь: Нажимает 'Сохранить']
    A7 --> S5[Система: Валидирует изменения]
    A8 --> S6[Система: Валидирует данные]
    S5 --> D2{Данные корректны?}
    S6 --> D3{Данные корректны?}
    D2 -->|Да| S7[Система: Обновляет тип операции]
    D3 -->|Да| S8[Система: Создает новый тип операции]
    D2 -->|Нет| S9[Система: Отображает ошибки]
    D3 -->|Нет| S10[Система: Отображает ошибки]
    S7 --> End([Конец])
    S8 --> End
    S9 --> A5
    S10 --> A4

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

RQ538. Требование к предустановленным типам операций. Система должна содержать стандартный набор операций:

• "Получение заказа"
• "Выдвижение к клиенту"
• "Прибытие к клиенту"
• "Подключение к автомобилю"
• "Начало зарядки"
• "Мониторинг зарядки"
• "Завершение зарядки"
• "Отключение от автомобиля"
• "Завершение заказа"

RQ539. Требование к обязательным полям операции. При создании типа операции обязательны: название операции, описание, категория операции (подготовительная/основная/завершающая).

RQ540. Требование к временным нормативам. Для каждого типа операции могут быть указаны: плановое время выполнения (минуты), максимальное время выполнения, признак автоматического завершения.

RQ541. Требование к последовательности операций. Система должна поддерживать определение порядка выполнения операций через поле "Порядок в процессе".

RQ542. Требование к проверке использования операций. Перед удалением типа операции Система должна проверить его использование в логах операций техников и запретить удаление при наличии связанных записей.

---

Модель предметной области (справочники)

Основные сущности справочников

classDiagram
    class Производители {
        +Название : String
        +КонтактноеЛицо : String
        +КонтактныйТелефон : String
        +КонтактныйEmail : String
        +ВебСайт : String
        +Адрес : String
        +Примечания : String
        +СписокМоделейСтанций : МоделиЗарядныхСтанций[]
    }
    
    class МоделиЗарядныхСтанций {
        +Производитель : Производители
        +НазваниеМодели : String
        +МощностьКВт : Number
        +КоличествоПортов : Number
        +ПоддерживаемыеКоннекторы : ТипыКоннекторов[]
        +МаксимальныйТокА : Number
        +ВходноеНапряжение : Number
        +ВыходныеНапряжения : Number[]
        +ВесКг : Number
        +Габариты : String
        +СтепеньЗащитыIP : String
        +РабочаяТемпература : String
        +ТипОхлаждения : String
        +ДополнительныеХарактеристики : String
    }
    
    class БрендыАвтомобилей {
        +Название : String
        +ВнешнийИдентификатор : String
        +СсылкаНаФайлМоделей : String
        +СписокМоделей : МоделиАвтомобилей[]
    }
    
    class МоделиАвтомобилей {
        +БрендАвтомобиля : БрендыАвтомобилей
        +НазваниеМодели : String
        +Вариант : String
        +ТипТранспорта : ТипыТранспорта
        +ГодВыпуска : Number
        +МесяцВыпуска : Number
        +ЕмкостьБатареи : Number
        +НапряжениеЗарядки : Number
        +СреднийРасход : Number
        +ЗапасХода : Number
        +ПортыAC : ТипыКоннекторов[]
        +МаксимальнаяМощностьAC : Number
        +ПортыDC : ТипыКоннекторов[]
        +МаксимальнаяМощностьDC : Number
        +КриваяЗарядкиDC : String
    }
    
    class Тарифы {
        +НазваниеТарифа : String
        +ОписаниеТарифа : String
        +ТипТарифа : ТипыТарифов
        +БазоваяСтоимость : Number
        +СтоимостьЗаКВтЧ : Number
        +МинимальнаяСтоимость : Number
        +МаксимальнаяСтоимость : Number
        +ДатаНачалаДействия : Date
        +ДатаОкончанияДействия : Date
        +ВремяНачалаДействия : Time
        +ВремяОкончанияДействия : Time
        +ДниНедели : Number[]
        +ПриоритетПрименения : Number
        +АктивенТариф : Boolean
    }
    
    class ЗоныОбслуживания {
        +НазваниеЗоны : String
        +ОписаниеЗоны : String
        +ГраницыЗоны : String
        +ПриоритетОбслуживания : Number
        +МаксимальноеВремяОжидания : Number
        +АктивнаЗона : Boolean
    }
    
    class ТипыКоннекторов {
        <<enumeration>>
        TYPE1
        TYPE2
        CCS
        CHADEMO
        TESLA_SUC
        TESLA_CCS
        GB_T
    }
    
    class ПричиныОтменыЗаказов {
        +ТекстПричины : String
        +ТипИнициатора : ТипыИнициаторов
        +ПорядокОтображения : Number
        +ТребуетКомментария : Boolean
        +АктивнаПричина : Boolean
    }
    
    class ТипыОперацийТехников {
        +НазваниеОперации : String
        +ОписаниеОперации : String
        +КатегорияОперации : КатегорииОпераций
        +ПлановоеВремяВыполнения : Number
        +МаксимальноеВремяВыполнения : Number
        +ПорядокВПроцессе : Number
        +АвтоматическоеЗавершение : Boolean
    }
    
    class ТипыТарифов {
        <<enumeration>>
        Базовый
        Экстренный
        Плановый
        Ночной
        Льготный
    }
    
    class ТипыТранспорта {
        <<enumeration>>
        CAR
        MOTORBIKE
        MICROCAR
    }
    
    class ТипыИнициаторов {
        <<enumeration>>
        Клиент
        Диспетчер
        Система
    }
    
    class КатегорииОпераций {
        <<enumeration>>
        Подготовительная
        Основная
        Завершающая
    }
    
    Производители --> МоделиЗарядныхСтанций
    МоделиЗарядныхСтанций --> ТипыКоннекторов
    БрендыАвтомобилей --> МоделиАвтомобилей
    МоделиАвтомобилей --> ТипыКоннекторов
    МоделиАвтомобилей --> ТипыТранспорта
    Тарифы --> ТипыТарифов
    ПричиныОтменыЗаказов --> ТипыИнициаторов
    ТипыОперацийТехников --> КатегорииОпераций

---

Общие требования к блоку

Требования к разграничению доступа

RQ543. Требование к ролевому разграничению. Система должна обеспечивать доступ к справочникам согласно ролевой модели:

• Диспетчер: только просмотр (R) всех справочников
• Администратор: полные права (CRUD) для всех справочников

RQ544. Требование к аудиту изменений. Все изменения в справочниках должны логироваться с указанием: пользователя, времени, типа операции, измененных полей.

Требования к интерфейсу

RQ545. Требование к единообразию интерфейса. Все справочники должны иметь единообразный интерфейс с стандартными функциями: поиск, фильтрация, сортировка, пагинация.

RQ546. Требование к пагинации. Система должна отображать 20 записей на странице с возможностью навигации по страницам и изменения количества записей на странице.

Требования к валидации

RQ547. Требование к комплексной валидации. Система должна выполнять валидацию на уровне полей, записей и межтабличных связей с информативными сообщениями об ошибках.

RQ548. Требование к контролю ссылочной целостности. Перед удалением записей справочников Система должна проверять наличие ссылок из других таблиц и предотвращать нарушение целостности данных.

Требования к производительности

RQ549. Требование к времени отклика. Операции просмотра справочников должны выполняться не более чем за 2 секунды, операции создания/редактирования - не более чем за 5 секунд.

RQ550. Требование к индексации. Все поля, используемые для поиска и фильтрации, должны быть проиндексированы в базе данных.