проанализируй 4 главу в файле "ВКР-идб-20-01_Никит...

Проанализировал структуру 4-й главы у Никитина: она построена в двух крупных частях — 4.1 «Руководство пользователя» и 4.2 «Особенности реализации задачи», после чего даётся краткий вывод по главе. Для Денисова эту схему лучше сохранить, но адаптировать под то, что в системе есть только одна роль — пользователь, а ключевой акцент работы сделан на выборе алгоритма, настройке входных данных, написании кода, запуске его в изолированной среде и последующей визуализации шагов. Такая структура хорошо согласуется и с требованиями, и с проектными решениями Денисова: платформа должна показывать теорию, давать редактор кода, настраивать массивы и графы, выполнять визуализацию, отображать статус обработки, а также обеспечивать изолированное выполнение пользовательского кода, масштабируемость и адаптивный интерфейс. (ВКР_ИДБ-20-01_Никитин_ИА.pdf) (Диплом Денисов М.С. ИДБ-22-05.pdf) (Диплом Денисов М.С. ИДБ-22-05.pdf) (USER_GUIDE.md)

Ниже — готовый вариант 4-й главы для Денисова в стиле дипломного текста.

---

ГЛАВА 4. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ ВЕБ-ПЛАТФОРМЫ

4.1. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

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

Взаимодействие с системой осуществляется в рамках одной роли — пользователя. Пользователь получает доступ к полному циклу работы с платформой: выбору алгоритма, изучению теоретического материала, настройке исходных данных, написанию собственного кода, запуску выполнения и просмотру анимации шагов алгоритма. Такой подход соответствует ранее сформулированным требованиям, согласно которым система должна объединять теоретический материал, средства ввода кода, настройку входных структур и визуализацию результатов выполнения в едином интерфейсе. (Диплом Денисов М.С. ИДБ-22-05.pdf) (USER_GUIDE.md)

4.1.1. Выбор алгоритма и работа с теоретическим материалом

После открытия платформы пользователь попадает на главную страницу, где представлено краткое описание проекта и ссылки для перехода к доступным алгоритмам. Основным рабочим разделом является страница симулятора, на которой реализован интерфейс выбора алгоритма. В верхней части страницы размещены вкладки, соответствующие поддерживаемым алгоритмам: сортировке вставками, сортировке выбором, быстрой сортировке, бинарному поиску, поиску в глубину и поиску в ширину. Выбор конкретного алгоритма определяет дальнейшее поведение интерфейса: изменяется теория, шаблон кода, состав доступных входных данных и набор подсветок, применяемых при визуализации. (USER_GUIDE.md)

После выбора алгоритма пользователю отображается блок с теоретическими сведениями. Для каждого алгоритма в системе предусмотрены краткое описание принципа работы, основные шаги выполнения, сигнатура функции и пояснения по доступным режимам визуализации. Таким образом, пользователь может не только запускать алгоритм, но и предварительно ознакомиться с его назначением и особенностями применения. Это соответствует функциональному требованию о предоставлении теоретических сведений по поддерживаемым алгоритмам. (Диплом Денисов М.С. ИДБ-22-05.pdf)

4.1.2. Настройка входных данных для алгоритмов, работающих с массивами

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

Второй способ — автоматическая генерация массива. В этом случае пользователь задаёт количество элементов и диапазон значений, после чего система создаёт случайный набор данных. Дополнительно предусмотрены функции перемешивания массива, очистки текущего состояния и возврата к исходной конфигурации, сохранённой для текущего алгоритма. Такой набор действий упрощает экспериментирование с различными входными данными и позволяет быстро сравнивать поведение одной и той же реализации на разных массивах. (USER_GUIDE.md)

При выборе бинарного поиска интерфейс дополняется полем для указания искомого значения. При этом введённый массив автоматически приводится к отсортированному виду, поскольку бинарный поиск корректно работает только на упорядоченных данных. Пользователь получает уже подготовленную структуру, пригодную для запуска алгоритма, что снижает вероятность ошибок на этапе настройки входных параметров. Такой пользовательский сценарий полностью согласуется с платформо-независимым проектом, где для бинарного поиска предусмотрены ввод массива, его сортировка и указание целевого элемента. (Диплом Денисов М.С. ИДБ-22-05.pdf) (USER_GUIDE.md)

4.1.3. Настройка входных данных для графовых алгоритмов

Для алгоритмов обхода графа платформа предоставляет отдельный режим настройки графовой структуры. Пользователь может добавлять вершины, указывая их текстовые метки, например A, B, C, а затем соединять вершины направленными рёбрами. Поддерживаются и петли, то есть рёбра вида A → A. Помимо добавления, система позволяет удалять рёбра, удалять вершины вместе со всеми инцидентными рёбрами и полностью очищать граф.

Важной особенностью интерфейса является возможность интерактивного размещения вершин на рабочем поле. Пользователь может перемещать вершины мышью, формируя более наглядную схему графа. После построения структуры необходимо указать стартовую и конечную вершины. Без выбора контрольных точек запуск BFS и DFS невозможен, поскольку алгоритмы требуют корректно заданных параметров обхода. Такой сценарий полностью соответствует спроектированным действиям пользователя при формировании входного графа: добавлению элементов структуры, фиксации стартовой и целевой вершин и немедленной визуальной отрисовке результата. (USER_GUIDE.md) (Диплом Денисов М.С. ИДБ-22-05.pdf)

4.1.4. Выбор режима написания алгоритма

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

Второй режим — контролируемая анимация. В нём пользователь самостоятельно определяет шаги трассировки и желаемые подсветки, получая тем самым более детализированную и управляемую визуализацию. При переключении режима система автоматически подставляет в редактор соответствующий шаблон кода для выбранного алгоритма. Наличие двух режимов позволяет использовать платформу как для первоначального знакомства с алгоритмом, так и для более глубокого анализа собственной реализации. (USER_GUIDE.md)

4.1.5. Работа с редактором кода

Центральным элементом практической части платформы является встроенный редактор кода. В редакторе уже присутствует шаблон программы, соответствующий выбранному алгоритму и режиму анимации. Пользователь может изменить шаблон, дополнить его собственной логикой или полностью переписать реализацию. Для удобства предусмотрены подсветка синтаксиса и обновление содержимого редактора в реальном времени. В проектной модели этот сценарий выделен как самостоятельное действие пользователя, при котором интерфейс принимает ввод кода, выполняет его визуальное оформление и сохраняет для дальнейшего запуска. (Диплом Денисов М.С. ИДБ-22-05.pdf)

Редактор содержит не только функцию алгоритма, но и полную заготовку программы, включая точку входа и подготовку входных данных. Благодаря этому пользователь может сосредоточиться на реализации самого алгоритма, не тратя время на настройку служебной части программы. Возможность изменять код и повторно запускать выполнение соответствует одной из центральных задач дипломной работы — предоставить обучающемуся инструмент для самостоятельного написания и проверки алгоритмов. (Диплом Денисов М.С. ИДБ-22-05.pdf) (USER_GUIDE.md)

4.1.6. Запуск выполнения и получение результата

После подготовки входных данных и написания кода пользователь запускает выполнение нажатием кнопки Run. С этого момента интерфейс отправляет код и текущее состояние структуры данных на серверную сторону. Согласно спроектированному сценарию, сервер принимает запрос, сохраняет задачу, присваивает ей идентификатор, помещает её в очередь обработки и возвращает пользователю подтверждение о принятии задачи. Далее фоновый обработчик получает задачу из очереди, извлекает её параметры и передаёт код в изолированную среду выполнения. (Диплом Денисов М.С. ИДБ-22-05.pdf)

Во время обработки пользователь видит текущий статус выполнения, общий таймер и длительность отдельных этапов. По мере продвижения задачи отображаются состояния, связанные с постановкой в очередь, компиляцией, выполнением, завершением либо ошибкой. Такой механизм обеспечивает прозрачность серверной обработки и соответствует функциональному требованию по информированию пользователя о текущем состоянии запроса и его результате. (Диплом Денисов М.С. ИДБ-22-05.pdf) (USER_GUIDE.md)

На стороне клиента также предусмотрена кнопка остановки ожидания или воспроизведения. Это не прерывает серверный процесс напрямую, но позволяет пользователю прекратить текущее взаимодействие с анимацией и подготовить новый запуск.

4.1.7. Управление анимацией

После завершения исполнения кода и получения журнала шагов система строит анимацию. Визуализация формируется не в процессе выполнения программы, а после него, на основе собранных логов. Такой подход обеспечивает воспроизводимость просмотра, возможность пошагового анализа и повторного воспроизведения без повторного запуска кода. (USER_GUIDE.md)

Под областью визуализации расположена панель управления. Пользователь может запускать и приостанавливать проигрывание, выполнять сброс к исходному состоянию, переходить к следующему шагу вручную, включать и отключать автоматическое воспроизведение, а также изменять скорость анимации. Скорость влияет на темп смены шагов и продолжительность переходов между состояниями. Подобный сценарий уже был заложен в проектных CRC-картах и диаграммах последовательности: интерфейс запрашивает следующий шаг, получает данные из модели и отрисовывает новое состояние с учётом установленной задержки. (Диплом Денисов М.С. ИДБ-22-05.pdf)

4.1.8. Интерпретация легенды и подсветок

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

Таким образом, пользователь получает не просто анимированное представление данных, а структурированное объяснение происходящих операций. Это делает платформу полноценным учебным инструментом, а не только средством демонстрации результата. (USER_GUIDE.md)

---

4.2. ОСОБЕННОСТИ РЕАЛИЗАЦИИ ЗАДАЧИ

4.2.1. Общая схема обработки пользовательского запроса

Практическая реализация платформы строится вокруг идеи разделения интерактивного интерфейса и фонового безопасного выполнения пользовательского кода. Пользователь взаимодействует с клиентской частью приложения, где выбирает алгоритм, подготавливает входные данные, редактирует код и запускает выполнение. После этого начинается многоэтапный сценарий обработки запроса: API принимает задачу, помещает её в очередь, фоновый воркер извлекает параметры и передаёт их в изолированную среду исполнения. По завершении выполнения результаты преобразуются в журнал шагов, пригодный для дальнейшей анимации на стороне клиента. Такой механизм был заложен в архитектуре ещё на этапе проектирования. (Диплом Денисов М.С. ИДБ-22-05.pdf)

Подобная организация позволяет решить сразу несколько задач: сохранить отзывчивость интерфейса, исключить блокировку веб-сервера длительными вычислениями, а также обеспечить контролируемое выполнение пользовательских программ. Это напрямую соответствует нефункциональным требованиям по отказоустойчивости, безопасности и производительности обработки промежуточных состояний. (Диплом Денисов М.С. ИДБ-22-05.pdf)

4.2.2. Реализация клиентской части

Клиентская часть платформы отвечает за отображение теоретического блока, редактора кода, панели настройки входных данных, области визуализации и элементов управления анимацией. Согласно выбранному стеку, для реализации интерфейса используется React, что особенно оправдано для подобной задачи, поскольку платформа содержит большое количество динамически меняющихся компонентов. В работе отдельно отмечено, что использование клиентского сервиса обеспечивает плавную смену кадров анимации и уменьшает задержки интерфейса за счёт механизма Virtual DOM. (Диплом Денисов М.С. ИДБ-22-05.pdf)

На стороне клиента реализована логика, отвечающая за переключение алгоритмов, замену шаблонов кода, формирование массивов и графов, локальное хранение исходного состояния и последовательное воспроизведение полученных шагов. Для массивов отрисовка выполняется в виде набора элементов, высота или положение которых отражают текущее состояние данных. Для графов визуализация строится на основе набора вершин и рёбер с учётом координат, заданных пользователем в интерактивном режиме. Подобная организация интерфейса делает возможной повторную отрисовку каждого шага без нового обращения к серверу.

4.2.3. Реализация серверной части и асинхронной обработки

Серверная часть платформы разработана на основе ASP.NET Core и языка C#. В третьей главе указано, что система построена как целостная архитектура для интерактивного изучения алгоритмов и использует асинхронную обработку задач через RabbitMQ, а хранение промежуточных статусов — через Redis. (Диплом Денисов М.С. ИДБ-22-05.pdf)

После отправки запроса сервер сохраняет параметры задачи, присваивает ей идентификатор и публикует сообщение в очередь. Выбор брокера RabbitMQ обусловлен его надёжностью доставки, поддержкой подтверждений обработки и удобством распределения нагрузки между воркерами. Это особенно важно для платформы, где разные пользователи могут одновременно отправлять вычислительно насыщенные задачи на запуск. В результате пользовательский интерфейс не блокируется, а тяжёлая обработка переносится в фоновый контур системы. (Диплом Денисов М.С. ИДБ-22-05.pdf)

4.2.4. Изолированное выполнение пользовательского кода

Ключевой особенностью платформы является безопасное исполнение пользовательских программ. В качестве технологии изоляции в проекте выбран Docker. Данный выбор объясняется тем, что контейнеризация обеспечивает отделение пользовательского кода от основной инфраструктуры сервера, ограничивает доступ к файловой системе и системным ресурсам, а также позволяет задавать квоты на память и процессорное время. В работе прямо отмечено, что даже в случае запуска вредоносного или ошибочного кода ущерб будет ограничен пределами временного контейнера. (Диплом Денисов М.С. ИДБ-22-05.pdf)

Использование контейнеров позволяет запускать алгоритмы в заранее подготовленном окружении, собирать вывод программы и завершать контейнер после окончания работы. Благодаря библиотекам экосистемы .NET жизненный цикл контейнера может управляться программно из воркер-сервиса. Это делает возможным централизованный контроль выполнения, отслеживание ошибок и сбор логов без прямого участия пользователя. Кроме того, контейнерный подход открывает возможность дальнейшего расширения платформы на другие языки программирования без полной перестройки архитектуры. (Диплом Денисов М.С. ИДБ-22-05.pdf)

4.2.5. Формирование шагов визуализации

Отличительной чертой разработанной платформы является то, что визуализация строится не на заранее заданных алгоритмах, а на основе выполнения пользовательского кода. Это достигается за счёт логирования операций, выполняемых во время работы программы. В автоматическом режиме система отслеживает базовые действия над структурой данных. В контролируемом режиме пользователь может самостоятельно указывать важные точки трассировки и формировать более детализированные сценарии анимации. Такой подход полностью соответствует задаче, поставленной в первой главе: разработать систему визуализации пользовательского кода на массиве или графе по результатам его выполнения. (Диплом Денисов М.С. ИДБ-22-05.pdf) (USER_GUIDE.md)

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

4.2.6. Хранение статусов и промежуточных данных

Для оперативного отслеживания состояния задачи в проекте используется Redis. Такой выбор объясняется высокой скоростью доступа к данным в оперативной памяти и возможностью эффективно обслуживать многократные запросы статуса со стороны фронтенда. В работе отдельно подчёркивается, что Redis позволяет хранить этапы обработки задачи — в очереди, в процессе выполнения, завершено — и тем самым снижать нагрузку на основную базу данных. (Диплом Денисов М.С. ИДБ-22-05.pdf)

Журнал выполнения и результаты запуска образуют отдельную сущность информационной модели. На этапе проектирования было зафиксировано, что журнал выполнения хранит статус запуска, ошибки и сопутствующую информацию, необходимую для воспроизведения результата. Это означает, что система не ограничивается простым возвратом факта успешного выполнения, а формирует полноценный набор данных для последующего анализа и визуализации. (Диплом Денисов М.С. ИДБ-22-05.pdf)

4.2.7. Адаптивность и кроссплатформенность интерфейса

Одним из требований к платформе является корректная работа на различных пользовательских устройствах. В дипломе Денисова адаптивность закреплена как отдельное нефункциональное требование, а сама система проектируется как веб-решение, не требующее локальной установки среды разработки. (Диплом Денисов М.С. ИДБ-22-05.pdf) (Диплом Денисов М.С. ИДБ-22-05.pdf)

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

---

4.3. ВЫВОДЫ ПО ГЛАВЕ 4

В данной главе рассмотрена практическая реализация разработанной интерактивной веб-платформы для изучения алгоритмов сортировки и поиска данных. Составлено руководство пользователя, охватывающее весь цикл работы с системой: выбор алгоритма, изучение теоретического материала, настройку входных данных, написание программного кода, запуск его выполнения и анализ полученной визуализации. Отдельно рассмотрены особенности реализации платформы, связанные с построением клиентского интерфейса, асинхронной серверной обработкой задач, использованием очередей сообщений, кэшированием статусов и безопасным исполнением пользовательского кода в изолированной контейнерной среде. (Диплом Денисов М.С. ИДБ-22-05.pdf) (Диплом Денисов М.С. ИДБ-22-05.pdf)

Результаты главы показывают, что разработанная платформа удовлетворяет ранее сформулированным функциональным и нефункциональным требованиям. Система предоставляет пользователю единую среду, сочетающую теоретическую подготовку, практическую реализацию алгоритмов и наглядную визуализацию их работы, что позволяет повысить эффективность обучения и обеспечить удобное взаимодействие с изучаемым материалом. (Диплом Денисов М.С. ИДБ-22-05.pdf) (USER_GUIDE.md)

---

Если нужно, я могу сразу сделать и готовое оглавление для 4 главы в формате твоего диплома, чтобы его можно было просто вставить в документ.

Да — для этих скриншотов лучше давать не название функции, а смысловую подпись, чтобы рисунок работал как доказательство реализации, а не как “просто кусок кода”.

Я бы вставил их так:

1. document.getElementById('run').addEventListener(...)
Раздел: «Запуск выполнения и получение результата»
Лучшее место: сразу после абзаца

«После подготовки входных данных и написания кода пользователь запускает выполнение нажатием кнопки Run…»
потому что именно этот фрагмент показывает обработку нажатия Run, отправку данных и запуск дальнейшего сценария выполнения. В твоём тексте этот фрагмент уже логически привязан к описанию запуска и статусов. (Диплом_редактированный.docx)

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

Фраза в тексте для ссылки:

Реализация запуска выполнения по нажатию кнопки Run представлена на рисунке 4.7.

Если на скриншоте видно ещё и вызов pollStatus(...), можно усилить подпись: Рисунок 4.7. Обработчик запуска выполнения алгоритма и последующего опроса статуса задачи

---

2. LogPlayer и applySpeed(...)
Раздел: «Управление анимацией»
Лучшее место: после абзаца про Play / Pause / Step / Autoplay / изменение скорости, потому что в user guide и в тексте главы этот блок как раз описывает проигрывание шагов и регулировку темпа анимации.
По коду LogPlayer отвечает за пошаговую обработку очереди событий, а applySpeed(...) меняет задержку шага, базовую задержку визуализации и длительность подсветок.

Подпись: Рисунок 4.8. Реализация проигрывателя шагов и настройки скорости анимации

Фраза в тексте для ссылки:

Механизм последовательного воспроизведения шагов и изменения скорости анимации реализован в проигрывателе логов, представленном на рисунке 4.8.

Если хочешь разделить на два отдельных скрина, тогда лучше так:

• Рисунок 4.8. Реализация проигрывателя шагов анимации (LogPlayer)
• Рисунок 4.9. Реализация изменения скорости воспроизведения анимации (applySpeed)

Но если они на одном экране и тематически связаны, лучше объединить в один рисунок.

---

3. animateSwap(i, j)
Раздел: «Управление анимацией»
Лучшее место: сразу после предложения, где пишешь про визуализацию шагов и переходов между состояниями массива, либо после рисунка с LogPlayer/applySpeed.
Этот фрагмент уже относится не к запуску, а к визуальной интерпретации события обмена элементов. В коде видно, что функция вычисляет позиции элементов, переставляет их в модели и запускает анимацию перемещения.

Подпись: Рисунок 4.9. Реализация анимации обмена элементов массива

Фраза в тексте для ссылки:

Пример реализации визуального перехода при обмене двух элементов массива приведён на рисунке 4.9.

Можно сделать чуть более технически: Рисунок 4.9. Реализация анимированного обмена элементов при обработке события swap

---

Как лучше перестроить нумерацию

У тебя сейчас в отредактированном тексте уже есть:

• 4.6 — статус выполнения,
• 4.7 — панель управления анимацией,
• 4.8 — легенда.

Если добавлять новые скриншоты внутрь главы, я бы перенумеровал так:

• Рисунок 4.6 — Отображение статуса выполнения задачи
• Рисунок 4.7 — Обработчик запуска выполнения алгоритма и отправки запроса на сервер
• Рисунок 4.8 — Панель управления анимацией
• Рисунок 4.9 — Реализация проигрывателя шагов и настройки скорости анимации
• Рисунок 4.10 — Реализация анимации обмена элементов массива
• Рисунок 4.11 — Динамическая легенда подсветок

Это самый логичный порядок:
запуск → получение статуса → управление воспроизведением → внутренняя логика анимации → легенда.

---

Как лучше разместить

Лучший вариант такой:

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

Для этих трёх скриншотов:

• скрин run.addEventListener — в подраздел «Запуск выполнения и получение результата»;
• скрин LogPlayer + applySpeed — в подраздел «Управление анимацией»;
• скрин animateSwap — туда же, сразу после описания проигрывателя как более низкоуровневый пример конкретной анимации.

---

Что лучше вынести в листинги в приложение

Так как ты сам написал, что функции большие, в основной текст лучше оставить скриншоты ключевых фрагментов, а полные версии вынести в приложение:

• Листинг А.1. Обработчик запуска выполнения и опроса статуса задачи
• Листинг А.2. Класс проигрывателя шагов анимации LogPlayer
• Листинг А.3. Функция настройки скорости анимации applySpeed
• Листинг А.4. Функция анимации обмена элементов animateSwap

Тогда в тексте можно писать так:

Обработчик запуска выполнения алгоритма показан на рисунке 4.7, а его полный текст приведён в листинге А.1.
Логика пошагового воспроизведения и изменения скорости анимации представлена на рисунке 4.9; полная реализация приведена в листингах А.2–А.3.
Пример реализации анимации обмена элементов массива приведён на рисунке 4.10, полный текст функции приведён в листинге А.4.

---

Готовые подписи, которые можно просто вставить

Рисунок 4.7. Обработчик запуска выполнения алгоритма и отправки запроса на сервер
Рисунок 4.9. Реализация проигрывателя шагов и настройки скорости анимации
Рисунок 4.10. Реализация анимации обмена элементов массива

Если хочешь, я могу следующим сообщением сразу дать тебе готовые абзацы с уже встроенными ссылками на рисунки и листинги, чтобы ты просто вставил их в 4 главу.