Рабочая ситуация
Система приёма заказов и система исполнения разработаны разными командами и говорят на разных языках: несовпадающие поля, форматы дат, коды статусов. Студент получает каркас обработчика обмена, который «почти работает», и задачу довести интеграцию до проверяемого состояния.
Сначала нужно согласовать контракт с ИИ-разработчиком смежного сервиса и исправить обработчик. Затем сценарий вводит тайм-ауты и повторные запросы: без защиты от дублей один заказ исполняется дважды. Наконец, смежная команда выпускает новую версию API, и нужно пройти переход без потери данных и регрессий.
Рабочее место
- Коллекции запросов и тесты по логике Postmanпозитивные, негативные и повторные сценарии обмена.
- Редактор и отладчик по логике VS Codeисправление обработчика и отладка на трассах из песочницы.
- Спецификация OpenAPIконтракт как основа документации и исполняемых проверок, а не самоцель.
- Песочница исполненияреальное выполнение обработчика на заданных трассах с журналом обмена.
Как проходит работа
- Сравнить ожидания двух сервисов и зафиксировать расхождения.
- Согласовать контракт и обновить спецификацию.
- Исправить обработчик, добавить тесты на основные и граничные случаи.
- Выдержать тайм-ауты и повторы: добавить идемпотентность и проверку двойной обработки.
- Перейти на новую версию API, подтвердить отсутствие регрессий и описать остаточные риски.
ИИ-команда
- Разработчик смежного сервисаобъясняет своё API, спорит о формате и присылает новую версию контракта.
- Владелец процесса заказовприносит реальные случаи: отменённые заказы, повторные нажатия, запоздавшие подтверждения.
- Инженер по качествутребует воспроизводимых тестов и журнала обмена для каждого инцидента.
Что проверяется
| Итоговый артефакт | Автоматическая проверка в заданных границах | Оценка преподавателя |
|---|---|---|
| Контракт API, исправленный обработчик, тесты и журнал обмена | Реальное исполнение в песочнице: позитивные, негативные, повторные и регрессионные сценарии | Границы контракта, выбор поведения при сбоях и объяснение остаточных рисков |
Отсутствие дублей подтверждается поведением обработчика на заданных трассах, а не наличием поля в схеме.
Связанные дисциплины
Тренажёр подходит для дисциплин по объектно-ориентированному программированию, алгоритмам и структурам данных, сетям и качеству информационных систем.
Общая механика серии
- Рабочая ситуациясинтетические документы, данные, сроки и противоречия образуют конкретную задачу, а не свободную беседу.
- Ролевой мессенджерзаказчик, оператор, разработчик или эксплуатация располагают только сведениями своей роли; допустимые факты сценария заданы заранее.
- Первый результатстудент создаёт спецификацию, схему, код, модель или прототип, который можно сохранить и проверить.
- Изменение условийсценарный движок вводит новую версию контракта, ограничение, возмущение или новые данные; ИИ не придумывает эти события самостоятельно.
- Пересмотрстудент обновляет решение, повторяет проверки и объясняет, почему изменил или сохранил первоначальный подход.
- Безопасное исполнениепользовательский код и SQL запускаются только в изолированной среде; реальные секреты, персональные данные и производственные системы не нужны.
Ролевые ИИ-персонажи не получают скрытый ключ проверки и не выставляют итоговые баллы: вычисляемую часть результата проверяет программное ядро, открытое инженерное решение оценивает преподаватель по заранее известной рубрике.
Статус описания: Проектируется. На странице описан проектируемый тренажёр — целевой учебный сценарий, а не готовое приложение. Состав воспроизводимых сред, механика и критерии проверки согласуются с вузом; реализация и приёмка выполняются отдельно.
Названия и логотипы сторонних платформ обозначают учебные профили интерфейсов и операций и не означают поставку оригинальных продуктов, интеграцию с ними, партнёрство или одобрение правообладателей. Упоминание программ Топ-ИТ и «Приоритет-2030» обозначает область применения тренажёра, а не официальное включение в эти программы.
