add Chapter4

Latex/Chapter2.tex

@@ -1,40 +1,92 @@
-\section{Обзор существующих решений}
+\section{Обзор графических средств описания сетевых конфигураций}
 \label{sec:Chapter2} \index{Chapter2}
 % \todo[inline]{Здесь надо рассмотреть все существующие решения поставленной задачи, но не просто пересказать, в чем там дело, а оценить степень их соответствия тем ограничениям, которые были сформулированы в постановке задачи.}
 
-Существующие решения, близкие к задаче описания конфигурации сети виртуальных машин, можно разделить на три группы: универсальные диаграммеры, сетевые эмуляторы и генераторы диаграмм по текстовому описанию. Их применимость целесообразно оценивать по следующим критериям: возможность изобразить структуру сети, возможность сопоставить элементам сети набор параметров, возможность интерпретировать результат как формализованное описание, пригодное для последующей обработки.
+Существующие графические средства, позволяющие описывать и/или отображать конфигурацию сети виртуальных машин, можно разделить на три группы: универсальные диаграммеры, сетевые эмуляторы и генераторы диаграмм по текстовому описанию. Их применимость целесообразно оценивать по следующим критериям: возможность изобразить структуру сети, возможность сопоставить элементам сети набор параметров, возможность интерпретировать результат как формализованное описание, пригодное для последующей обработки.
 
 \subsection{Универсальные диаграммеры}
 
-К универсальным диаграммерам относятся draw.io \cite{drawio}, Lucidchart \cite{Lucidchart} и Microsoft Visio \cite{Visio}. Такие средства позволяют строить различные виды схем, в том числе сетевые диаграммы. Например, draw.io позиционируется как онлайн-инструмент для построения блок-схем, UML-, ER- и сетевых диаграмм; Microsoft Visio также содержит шаблоны и фигуры для сетевых диаграмм; Lucidchart поддерживает технические диаграммы и визуальное моделирование систем.
+К универсальным диаграммерам относятся такие средства как draw.io \cite{drawio} (рисунок \ref{fig:drawio}), Lucidchart \cite{Lucidchart} (рисунок \ref{fig:lucidchart}) и Microsoft Visio \cite{Visio} (рисунок \ref{fig:visio}). Такие средства позволяют строить различные виды схем, в том числе сетевые диаграммы. Например, draw.io позиционируется как онлайн-инструмент для построения блок-схем, UML-, ER- и сетевых диаграмм; Microsoft Visio также содержит шаблоны и фигуры для сетевых диаграмм; Lucidchart поддерживает технические диаграммы и визуальное моделирование систем.
 
-Основное преимущество таких решений состоит в удобстве визуального построения схемы. Пользователь может быстро расположить элементы, провести связи между ними и получить наглядное изображение топологии. Однако для поставленной задачи этого недостаточно. Диаграмма в таких системах в первую очередь является графическим объектом: она хорошо передаёт внешний вид структуры, но не задаёт строгую модель данных сетевой конфигурации. Параметры виртуальных машин, интерфейсов, MAC-адресов, IP-адресов и сетевых сегментов могут быть добавлены только как текстовые подписи или дополнительные свойства объектов, но их последующая автоматическая интерпретация становится нетривиальной.
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/drawio.png}
+\caption{Пример работы в draw.io}
+\label{fig:drawio}
+\end{figure}
 
-Следовательно, универсальные диаграммеры могут использоваться для иллюстрации результата, но не являются подходящей основой для хранения и воспроизводимого редактирования конфигурации. Они не обеспечивают требуемой проверяемости описания и плохо подходят для ситуации, когда одному элементу сети необходимо сопоставить множество формализованных атрибутов.
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/lucidchart.png}
+\caption{Пример диаграммы в Lucidchart}
+\label{fig:lucidchart}
+\end{figure}
+
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/visio.png}
+\caption{Пример работы в Visio}
+\label{fig:visio}
+\end{figure}
+
+Основное преимущество таких решений состоит в удобстве визуального построения схемы сети. Пользователь может быстро расположить элементы, провести связи между ними и получить наглядное изображение сетевой топологии. Однако для поставленной задачи этого недостаточно. Диаграмма в таких системах в первую очередь является графическим объектом: она хорошо передаёт внешний вид структуры, но не задаёт строгую модель данных сетевой конфигурации. Параметры виртуальных машин, интерфейсов, MAC-адресов, IP-адресов и сетевых сегментов могут быть добавлены только как текстовые подписи или дополнительные свойства объектов, но их последующая автоматическая интерпретация становится нетривиальной.
+
+Следовательно, универсальные диаграммеры могут использоваться для иллюстрации результата, но не являются подходящей основой для хранения и редактирования конфигурации. Они не обеспечивают требуемой проверяемости описания и плохо подходят для ситуации, когда одному элементу сети необходимо сопоставить множество формализованных атрибутов.
 
 \subsection{Сетевые эмуляторы}
 
-Ко второй группе относятся сетевые эмуляторы, например Cisco Packet Tracer \cite{Cisco} и Huawei eNSP \cite{eNSP}. Cisco Packet Tracer предназначен для обучения сетевым технологиям и позволяет моделировать работу сетей в виртуальной лабораторной среде; Huawei eNSP также описывается как симулятор устройств, применяемый для подготовки в области передачи данных.
+Ко второй группе относятся сетевые эмуляторы, например Cisco Packet Tracer \cite{Cisco} (рисунок \ref{fig:cisco}) и Huawei eNSP \cite{eNSP} (рисунок \ref{fig:ensp}). Cisco Packet Tracer предназначен для обучения сетевым технологиям и позволяет моделировать работу сетей в виртуальной лабораторной среде; Huawei eNSP также описывается как симулятор устройств, применяемый для подготовки в области передачи данных.
 
-Эти решения ближе к реальной настройке сети, чем универсальные диаграммеры: они позволяют не только нарисовать топологию, но и моделировать поведение сетевых устройств. Однако их назначение отличается от цели данной работы. Они ориентированы на эмуляцию оборудования конкретного производителя и обучение настройке сетевых устройств, а не на универсальное формализованное описание конфигурации сети виртуальных машин для лабораторных стендов.
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/cisco.png}
+\caption{Пример работы в Cisco Packet Tracer}
+\label{fig:cisco}
+\end{figure}
 
-(стоит ли писать) Кроме того, сетевые эмуляторы оказываются избыточными для рассматриваемой задачи. В работе требуется зафиксировать структуру конфигурации, известные и неизвестные параметры элементов, обеспечить редактируемость и экспорт описания. Полноценная симуляция сетевых протоколов и поведения оборудования для этого не требуется.P 
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/ensp.png}
+\caption{Пример работы в Huawei eNSP}
+\label{fig:ensp}
+\end{figure}
 
-Также такие системы хуже подходят для независимого структурированного хранения модели, которую можно было бы использовать как источник данных для разных представлений: таблицы, диаграммы или YAML-файла.
+Эти решения ближе к реальной настройке сети, чем универсальные диаграммеры: они позволяют не только нарисовать топологию, но и моделировать поведение сетевых устройств. Однако их назначение далеко от цели данной работы. Диаграммеры в их составе ориентированы на описание сети на основе оборудования конкретного производителя, а не на универсальное формализованное описание конфигурации сети виртуальных машин для лабораторных стендов.
 
 \subsection{Генераторы диаграмм}
 
-Третью группу составляют генераторы диаграмм по текстовому описанию: D2 \cite{D2}, Graphviz \cite{Graphviz}, PlantUML \cite{PlantUML}. Все три инструмента используют декларативный язык, позволяющий преобразовывать текстовое описание в диаграмму и выполняют смежные задачи.
+Третью группу составляют генераторы диаграмм по текстовому описанию: D2 \cite{D2} (рисунок \ref{fig:d2netw}), Graphviz \cite{Graphviz} (рисунок \ref{fig:graphviz}), PlantUML \cite{PlantUML} (рисунок \ref{fig:plantuml}). Все три инструмента используют декларативный язык, позволяющий преобразовывать текстовое описание в диаграмму и выполняют смежные задачи.
 
-Такие инструменты лучше соответствуют требованию воспроизводимости, поскольку исходное описание диаграммы хранится в текстовом виде, что упрощает интеграцию с программной реализацией. По этой причине генераторы диаграмм могут быть полезны как вспомогательный механизм визуализации сетевой топологии. В частности, в рамках работы D2 используется для построения графа L1 топологии сети на основе внутренней модели данных.
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/d2netw.png}
+\caption{Пример диаграммы в D2}
+\label{fig:d2netw}
+\end{figure}
 
-Однако эти решения не решают задачу полностью. Их основной результат — диаграмма, а не предметная модель конфигурации сети виртуальных машин. Узлы и связи в таких языках можно снабжать дополнительными атрибутами, наращивая необходимые свойства, но такое представление, по мере увеличения сложности топологии, быстро становится трудно читаемым. Генератор диаграмм может отобразить уже подготовленную модель, но не заменяет саму модель данных и табличный способ её редактирования.
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/graphviz.png}
+\caption{Пример диаграммы в Graphviz}
+\label{fig:graphviz}
+\end{figure}
+
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/plantuml.png}
+\caption{Пример диаграммы в PlantUML}
+\label{fig:plantuml}
+\end{figure}
+
+Такие инструменты упрощают интеграцию с программной реализацией, поскольку исходное описание диаграммы хранится в текстовом виде. По этой причине генераторы диаграмм могут быть полезны как вспомогательный механизм визуализации сетевой топологии. В частности, в рамках данной работы D2 используется для построения графа L1 топологии сети на основе внутренней модели данных.
+
+Однако эти средства не решают задачу полностью. Они позволяют генерировать диаграмму, но не редактировать ее структуру или атрибуты ее элементов. Узлы и связи во входных языках таких средств можно снабжать дополнительными атрибутами, наращивая необходимые свойства, но такое представление, по мере увеличения сложности топологии, быстро становится трудно читаемым. Генератор диаграмм может отобразить уже подготовленное описание сетевой диаграммы, но не предоставляет язык описания конфигурации сети и способ её редактирования.
 
-\todo[inline]{картиночек, насколько неудобно в графе держать}
 
 \subsection{Вывод}
 
-Рассмотренные решения покрывают отдельные аспекты поставленной задачи, но не удовлетворяют ей полностью. Универсальные диаграммеры удобны для ручного построения схем, но плохо подходят для формализованного хранения параметров. Сетевые эмуляторы позволяют моделировать работу сети, но являются избыточными и ориентированы на симуляцию, а не на независимое описание конфигурации виртуальных машин. Генераторы диаграмм обеспечивают воспроизводимую визуализацию, однако требуют внешней модели данных, в которой будут определены сущности, атрибуты и правила экспорта.
+Рассмотренные решения покрывают отдельные аспекты поставленной задачи, но не позволяют ее решить полностью. Универсальные диаграммеры удобны для ручного построения схемы сети, однако результат их работы в первую очередь является графическим представлением. Такие средства плохо подходят для хранения набора формализованных параметров устройств, интерфейсов и сетевых сегментов, а также для последующей программной обработки этого описания. Сетевые эмуляторы ориентированы на оборудование и сценарии конкретного производителя, что ограничивает их применимость для описания лабораторных стендов общего вида. Генераторы диаграмм по текстовому описанию лучше подходят для интеграции с программной реализацией, поскольку позволяют получать визуальное представление на основе текстовых данных. Тем не менее их основная функция заключается в построении диаграммы, а не в задании и редактировании конфигурации сети.
 
-Таким образом, в качестве основы разрабатываемого решения целесообразно использовать не формат диаграммы, а структурированную модель данных сетевой конфигурации. Диаграмма и YAML-файл в этом случае выступают вспомогательными представлениями: диаграмма используется для визуального контроля топологии, а YAML — как пример формализованного экспорта описания. Такой подход соответствует цели работы: разработать инструмент планирования частично сконфигурированных сетевых конфигураций с табличным вводом, воспроизводимым хранением и возможностью дальнейшей обработки.
+Таким образом, в качестве основы разрабатываемого решения целесообразно использовать не формат диаграммы, а структурированную модель данных сетевой конфигурации. Диаграмма в этом случае рассматривается как вспомогательное представление. D2 был выбран в качестве генератора диаграмм, поскольку для него существует лёгкая в использовании библиотека в языке Python \cite{py-d2}, позволяющая генерировать текстовое описание диаграммы. Другие генераторы диаграмм также могли бы использоваться.
 
+\todo[inline]{Трудно обосновать d2, т.к. действительно любой другой также можно было бы использовать, выбирали только потому что библиотека простая и диаграммки красивые}

Latex/Chapter3.tex

@@ -1,18 +1,15 @@
-\section{Исследование и построение решения задачи}
+\section{Выбор формата табличного представления конфигурации сети}
 \label{sec:Chapter3} \index{Chapter3}
 % \todo[inline]{Здесь надо декомпозировать большую задачу из постановки на подзадачи и продолжать этот процесс, пока подзадачи не станут достаточно простыми, чтобы их можно было бы решить напрямую (например, поставив какой-то эксперимент или доказав теорему) или найти готовое решение.}
-\subsection{Представление модели}
 
-Рассмотрение существующих решений показывает, что диаграмма удобна для визуального восприятия, но недостаточна как основная форма хранения данных: графическое изображение сложно интерпретировать как строгое описание конфигурации. Поэтому в качестве основы решения выбрано табличное представление данных, а диаграмма рассматривается только как производное отображение модели. Такой подход позволяет отделить логическое описание сети от способа его визуализации.
+Исходя из результатов обзора, в качестве пользовательской формы задания конфигурации выбрано табличное представление. Такая форма представления удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения.
 
-Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения.
+При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: представление в первой нормальной форме (далее - 1НФ) и представление в третьей нормальной форме (далее - 3НФ). Оба варианта позволяют структурированно описать сеть, однако различаются сложностью редактирования данных в случае непосредственной работы с таблицами. Вторая нормальная форма отдельно не рассматривалась как самостоятельный вариант представления, поскольку для данной задачи она является промежуточным этапом между компактным пользовательским описанием и полностью разнесённой структурой данных.
-
-При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: представление в первой нормальной форме и представление в третьей нормальной форме. Оба варианта позволяют формализовать описание сети, однако различаются удобством редактирования данных. Вторая нормальная форма отдельно не рассматривалась как самостоятельный вариант представления, поскольку для данной задачи она является промежуточным этапом между компактным пользовательским описанием и полностью разнесённой структурой данных.
 
 Разберём оба представления на примере топологии, изображённой на рисунке~\ref{fig:exmpl1}
 
 
-\begin{figure}[h]
+\begin{figure}[htbp]
 \centering
 \includegraphics[width=0.8\textwidth]{files/exmpl1.png}
 \caption{Пример топологии}
@@ -21,14 +18,14 @@
 
 \subsubsection*{Первая нормальная форма}
 
-Первая нормальная форма (далее - 1НФ) \cite{DB}:
+Первая нормальная форма \cite{DB}:
 
 Переменная отношения находится в \textbf{1НФ} тогда и только тогда, когда в любом допустимом значении этой переменной отношения каждый её кортеж содержит только одно значение для каждого из атрибутов.
 
-В первой нормальной форме данные представляются в виде одной таблицы, где каждая строка содержит атомарные значения: имя узла, интерфейс, адреса, принадлежность сети и т.д.. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации.
+В первой нормальной форме данные представляются в виде одной таблицы, где каждая строка содержит атомарные значения: имя узла, интерфейс, адреса, принадлежность сети и т.д. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации.
 
 
-Пример представления в 1НФ (таблица \ref{tab:1nf}):
+Пример представления конфигурации сети в 1НФ приведен в таблице \ref{tab:1nf}.
 
 \begin{table}[h!]
 \centering
@@ -54,7 +51,7 @@ com\_right & Switch & eth3 & C  &  \\
 
 \subsubsection*{Третья нормальная форма}
 
-Третья нормальная форма (далее - 3НФ) \cite{DB}:
+Третья нормальная форма \cite{DB}:
 
 Переменная отношения находится в \textbf{3НФ} тогда и только тогда, когда её неключевые атрибуты, если они существуют, являются одновременно:
 
@@ -69,9 +66,9 @@ com\_right & Switch & eth3 & C  &  \\
     \item \textbf{Взаимно независимые атрибуты} --- это два или больше атрибутов, таких что ни один из них функционально не зависит от какой-либо комбинации остальных атрибутов. Подобная независимость подразумевает, что каждый такой атрибут может обновляться независимо от остальных атрибутов.
 \end{itemize}
 
-В третьей нормальной форме данные разделяются на отдельные сущности: узлы, интерфейсы, сетевые сегменты и связи. Такой подход уменьшает дублирование данных и лучше соответствует классической реляционной модели, однако делает представление более громоздким. Для понимания одной связи приходится обращаться сразу к нескольким таблицам.
+В третьей нормальной форме данные разделяются на отдельные сущности: узлы (устройства), интерфейсы, сетевые сегменты и связи. Каждой из этих сущностей сопоставляется отдельная таблица. Такой подход уменьшает дублирование данных по сравнению с 1НФ, однако делает представление более громоздким. Для понимания одной связи приходится обращаться сразу к нескольким таблицам.
 
-Пример представления в 3НФ (таблицы \ref{tab:3nf1} - \ref{tab:3nf3}):
+Пример представления конфигурации сети в 3НФ приведен в таблицах \ref{tab:3nf1} - \ref{tab:3nf3}.
 
 \begin{table}[h]
 \centering
@@ -131,25 +128,6 @@ PC4.eth1 & 10.0.0.4/24 \\
 
 \subsubsection*{Выбор формы}
 
-В качестве основного пользовательского представления была выбрана первая нормальная форма. Она удобнее для ручного заполнения, проще воспринимается при описании лабораторных стендов и не требует постоянного перехода между большим количеством связанных таблиц.
+В качестве основного пользовательского представления была выбрана первая нормальная форма. Она удобнее в сравнении с 3НФ для ручного заполнения, проще воспринимается при описании лабораторных стендов и не требует постоянного перехода между большим количеством связанных таблиц.
 
-Табличное представление в 1НФ используется как удобная форма ввода, а при дальнейшей обработке данные могут преобразовываться во внутреннюю модель, где отдельно выделяются узлы, интерфейсы и связи. Такой подход сохраняет простоту заполнения таблицы и одновременно позволяет использовать данные для экспорта во входные форматы средства развертывания сетевых конфигураций или средства построения диаграмм топологии.
+Табличное представление в 1НФ используется как форма ввода, а при дальнейшей обработке данные могут преобразовываться во внутреннюю модель, где отдельно выделяются узлы, интерфейсы и связи. Такой подход сохраняет простоту заполнения таблицы и одновременно позволяет использовать данные для экспорта во входные форматы средства развертывания сетевых конфигураций или средства построения диаграмм топологии.
-
-\subsection{Внутренняя модель данных}
-
-Табличное представление используется для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор объектов Python (рисуок \ref{fig:uml_model1}), соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого данные могут быть преобразованы в другие форматы.
-
-\begin{figure}[h]
-\centering
-\includegraphics[width=0.8\textwidth]{files/UML.png}
-\caption{UML диаграмма классов Python}
-\label{fig:uml_model1}
-\end{figure}
-
-\subsection{Преобразование модели данных}
-
-Также одной из подзадач является разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель , экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сети из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели.
-
-\subsection{Вывод}
-
-Таким образом, решение строится не вокруг построения диаграммы, а вокруг формальной модели сетевой конфигурации. Табличное представление используется как способ ввода и редактирования, внутренняя модель — как основа обработки данных, а YAML и диаграмма — как формы представления результата. Такой подход позволяет обеспечить редактируемость, воспроизводимость и возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.

Latex/Chapter4.tex

@@ -1,10 +1,50 @@
 \section{Описание программной реализации}
 \label{sec:Chapter4} \index{Chapter4}
-\todo[inline]{Если в рамках работы писался какой-то код, здесь должно быть его описание: выбранный язык и библиотеки и мотивы выбора, архитектура, схема функционирования, теоретическая сложность алгоритма, характеристики функционирования (скорость/память).}
 
-\begin{figure}[h]
+%\begin{figure}[htbp]
+%\centering
+%\includegraphics[width=0.8\textwidth]{files/UML.png}
+%\caption{UML диаграмма классов Python}
+%\label{fig:uml_model}
+%\end{figure}
+
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/schema.png}
+\caption{Процесс работы}
+\label{fig:schema}
+\end{figure}
+
+Табличное представление используется для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор объектов Python (рисуок \ref{fig:uml_model1}), соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого данные могут быть преобразованы в другие форматы.
+
+\begin{figure}[htbp]
 \centering
 \includegraphics[width=0.8\textwidth]{files/UML.png}
 \caption{UML диаграмма классов Python}
-\label{fig:uml_model}
+\label{fig:uml_model1}
-\end{figure}
+\end{figure}
+
+Также необходима разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт во входные языки средства развертывания сетевых конфигураций и средства построения диаграмм. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сети из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели.
+
+Программная реализация средства описания конфигурации сети виртуальных машин выполнена на языке Python. Объём написанного кода: 710 строк, 48 килобайт. На рисунке \ref{fig:schema} представлен основной процесс работы с утилитой. Построение диаграмм происходит с помощью модуля py-d2 (пример на рисунке \ref{fig:diagram}).
+
+\begin{figure}[htbp]
+\centering
+\includegraphics[width=0.8\textwidth]{files/diagram.png}
+\caption{Пример диаграмммы, построенной утилитой}
+\label{fig:diagram}
+\end{figure}
+
+Воспроизводимость описания конфигурации обеспечивается тем, что результат хранится в виде структурированных данных. Одна и та же таблица при повторной обработке приводит к построению той же внутренней модели и, соответственно, к одинаковому описанию конфигурации. А преобразование в формат, пригодный для использования в средстве развёртывания сети виртуальных машин, обеспечивает возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.
+
+\todo[inline]{вынести в отдельное приложение?}
+
+Пример экспортированного YAML-описания конфигурации сети приведён в листинге~\ref{lst:yaml-config}.
+
+\lstinputlisting[
+  language=yaml,
+  caption={Фрагмент YAML-описания конфигурации сети виртуальных машин},
+  label={lst:yaml-config}
+]{files/topology.yaml}
+
+% Таким образом, решение строится не вокруг построения диаграммы, а вокруг формальной модели сетевой конфигурации. Табличное представление используется как способ ввода и редактирования, внутренняя модель — как основа обработки данных, а YAML и диаграмма — как формы представления результата. Такой подход позволяет обеспечить редактируемость, воспроизводимость и возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.

Latex/Chapter6.tex

@@ -28,6 +28,10 @@ Graphviz. Open source graph visualization software, 2026. Available at \url{http
 \bibitem{PlantUML}
 PlantUML. Tool for creation of a wide array of diagrams, 2026. Available at \url{https://plantuml.com/guide} (accessed May~19, 2026).
 
+\bibitem{py-d2}
+py-d2. Fully typed python interface for building .d2 diagram files in python.
+\url{https://github.com/MrBlenny/py-d2} (accessed May~23, 2026)
+
 \bibitem{DB}
 \textbf{Дейт \;К.\;Дж.} Введение в системы баз данных (8-е изд.)~// Издательский дом "Вильяме". – 2005. – 1327 с.
 

Latex/files/schema.d2

@@ -1,8 +1,8 @@
-сетевая топология -- табличное представление: ручное задание
+сетевая топология -- "табличное представление (.csv)": ручное задание
-табличное представление -- внутренняя модель (Python) : преобразование кодом
+"табличное представление (.csv)" -- внутренняя модель (Python) : преобразование кодом
-внутренняя модель (Python) -- диаграмма : py-d2
+внутренняя модель (Python) -- "диаграмма (.svg)" : преобразование кодом (py-d2)
-внутренняя модель (Python) -- YAML-описание : преобразование кодом
+внутренняя модель (Python) -- "описание для Netloom (.yaml)" : преобразование кодом
-YAML-описание -- средство развёртывания сетевой топологии (Netloom) {
+"описание для Netloom (.yaml)" -- средство развёртывания сетевой топологии (Netloom) {
 	style.stroke-dash: 5
 }
 средство развёртывания сетевой топологии (Netloom).style.stroke-dash: 5

Latex/files/topology.yaml

@@ -0,0 +1,78 @@
+meta:
+  id: topology.yaml
+  name: topology.yaml
+networks:
+- name: NA
+- name: NB
+- name: NC
+nodes:
+- role: host
+  name: H1
+  interfaces:
+    eth1:
+      ip: null
+      network: NA
+      gateway: null
+      index: 1
+    eth2:
+      ip: null
+      network: NB
+      gateway: null
+      index: 2
+  bridges: []
+  vlans: []
+- role: host
+  name: H2
+  interfaces:
+    eth1:
+      ip: null
+      network: NA
+      gateway: null
+      index: 1
+  bridges: []
+  vlans: []
+- role: host
+  name: H3
+  interfaces:
+    eth1:
+      ip: null
+      network: NA
+      gateway: null
+      index: 1
+  bridges: []
+  vlans: []
+- role: host
+  name: H4
+  interfaces:
+    eth1:
+      ip: null
+      network: NB
+      gateway: null
+      index: 1
+  bridges: []
+  vlans: []
+- role: host
+  name: H5
+  interfaces:
+    eth1:
+      ip: null
+      network: NC
+      gateway: null
+      index: 1
+  bridges: []
+  vlans: []
+- role: host
+  name: H6
+  interfaces:
+    eth1:
+      ip: null
+      network: null
+      gateway: null
+      index: 1
+    eth2:
+      ip: null
+      network: NC
+      gateway: null
+      index: 2
+  bridges: []
+  vlans: []

example/0_vvedenie.tex

@@ -28,7 +28,7 @@
 
 На примере (рис. \ref{fig:example}), видно, что для одного и того же графа работ могут быть построены разные расписания. Так, в расписании 1 целевая функция равна 9 и достигается в момент выполнения работы $V_2$. В расписании 2 пиковое использование ресурса достигает 11 во время выполнения работ $V_3$ и $V_4$. Таким образом, в расписании 1 целевая функция меньше, чем в расписании 2. 
 
-\begin{figure}[h]
+\begin{figure}[htbp]
     \centering
     \includegraphics[width=\textwidth]{pictures/example.png}
     \caption{Граф работ и возможные расписания для него}