Compare commits

..
10 Commits
Author SHA1 Message Date
krosh 876d8f99f9 final 2026-05-25 10:48:31 +03:00
krosh fd0aaa0b18 цшз 2026-05-25 10:17:23 +03:00
krosh 2bc55b2cf7 final?? 2026-05-25 02:20:10 +03:00
krosh 3974a44fb2 final& 2026-05-25 02:16:22 +03:00
krosh 2661ef1437 wip 2026-05-25 01:47:25 +03:00
krosh d10d6d1352 wip 2026-05-24 22:39:13 +03:00
krosh 1b2c84b6ae add ref 2026-05-24 15:42:50 +03:00
krosh 5a425e8991 add ref 2026-05-24 15:40:30 +03:00
krosh 905b00af02 add Chapter4 2026-05-24 15:38:09 +03:00
krosh 9e6f52bbca WIP 2026-05-24 15:05:42 +03:00
25 changed files with 367 additions and 136 deletions
BIN
View File
Binary file not shown.
BIN
View File
Binary file not shown.
+4 -4
View File
@@ -290,15 +290,15 @@
}
\newenvironment{abstractenv}{
\def\skip@bstr@ctp@ges{\@@skip@bstr@ctp@ges}
\afterpage{\skip@bstr@ctp@ges \thispagestyle{empty}}
\pagestyle{empty}
\afterpage{\skip@bstr@ctp@ges \thispagestyle{plain}}
\pagestyle{plain}
}
% Redefine above commands if etd option is specified. The blank pages make printing nice,
% but they don't want them in the submitted PDF
\DeclareOption{etd}{
\renewcommand{\clearemptydoublepage}{ \clearpage }
\renewenvironment{abstractenv}{\afterpage{\thispagestyle{empty}}\pagestyle{empty}}{}
\renewenvironment{abstractenv}{\afterpage{\thispagestyle{plain}}\pagestyle{plain}}{}
}
% ------------------------ Load the class and needed packages ---------------------------------
@@ -572,7 +572,7 @@
\newcommand{\abstractpage}{
\thispagestyle{empty}
% \thispagestyle{empty}
\begin{abstractenv}
\begin{center}
\providecommand\pdfbookmark[3][]{} \pdfbookmark[1]{Abstract}{bm:Abstract}
+4 -4
View File
@@ -16,9 +16,9 @@
Для достижения поставленной цели необходимо решить следующие задачи:
\begin{itemize}
\item Проанализировать существующие подходы к описанию и визуализации сетевых конфигураций и сформулировать требования к разрабатываемому инструменту по поддержке редактирования конфигураций.
\item Разработать модель представления конфигураций в виде структурированных данных, позволяющую задавать известные параметры и оставлять поля для последующего заполнения.
\item Реализовать выбранный способ ввода и редактирования конфигурации, обеспечивающий проверяемость и воспроизводимость описания.
\item Разработать механизм экспорта выбранного представления в структурированный текстовый формат, входной для средства развертывания конфигурации сети ВМ.
\item проанализировать существующие подходы к описанию и визуализации сетевых конфигураций и сформулировать требования к разрабатываемому инструменту по поддержке редактирования конфигураций;
\item разработать модель представления конфигураций в виде структурированных данных, позволяющую задавать известные параметры и оставлять поля для последующего заполнения;
\item реализовать выбранный способ ввода и редактирования конфигурации, обеспечивающий проверяемость и воспроизводимость описания;
\item разработать механизм экспорта выбранного представления в структурированный текстовый формат, входной для средства развертывания конфигурации сети ВМ.
\end{itemize}
+4 -6
View File
@@ -3,7 +3,7 @@
Под конфигурацией сети виртуальных машин в данной работе понимается формализованное описание набора виртуальных машин и связей между ними, необходимое для развертывания сетевой топологии лабораторного стенда. Такое описание должно фиксировать не только структуру сети ВМ, но и параметры элементов сети, необходимые для настройки ВМ.
В модель конфигурации сети ВМ входят следующие элементы и поля:
В модель конфигурации сети ВМ входят следующие элементы и их атрибуты:
\begin{enumerate}
\item \textbf{Топология сети}
@@ -18,7 +18,7 @@
\item \textbf{Устройство}
Устройство соответствует отдельному элементу стенда (виртуальной машине). В зависимости от назначения оно может рассматриваться как хост, маршрутизатор или коммутатор. Такое деление нужно для указания роли устройства в топологии, но все эти элементы имеют общую структуру описания.
Устройство соответствует отдельному элементу стенда (виртуальной машине). В зависимости от назначения оно может рассматриваться как хост, маршрутизатор или коммутатор. Такое деление нужно для указания роли устройства в топологии, но все эти элементы имеют одинаковую структуру описания.
Для устройства задаются:
\begin{itemize}
@@ -57,12 +57,10 @@
Для сети задаются:
\begin{itemize}
\item \textbf{имя сети}~--- обозначение сетевого сегмента в пределах топологии;
\item \textbf{список подключённых интерфейсов}~--- интерфейсы устройств, входящие в данную сеть;
\item \textbf{список подключённых интерфейсов}~--- интерфейсы устройств, входящие в данную сеть.
\end{itemize}
Одна сеть может объединять один или несколько интерфейсов. Каждый интерфейс в текущей модели относится к одной сети или остаётся без указания сети, если этот параметр ещё не определён.
\end{enumerate}
Так как на этапе описания конфигурации часть параметров может быть неизвестна, необходимо допускать частично заполненные данные. Это позволяет зафиксировать структуру сети и часть параметров, а затем уточнять отдельные поля без изменения общей структуры.
\todo[inline]{Мне очень не нравится факт "фиксируем стуктуру, меняем, но "общую" мы её не меняем". + термин поля тут ещё не актуален, ибо не таблица}
Так как на этапе описания конфигурации часть параметров может быть неизвестна, необходимо допускать частично заполненные данные. Это позволяет зафиксировать структуру сети и часть параметров, а затем уточнять отдельные атрибуты без изменения общей структуры.
+66 -16
View File
@@ -1,40 +1,90 @@
\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 также позиционируется как средство моделирования сетей, применяемое для подготовки специалистов в области сетевой передачи данных.
Эти решения ближе к реальной настройке сети, чем универсальные диаграммеры: они позволяют не только нарисовать топологию, но и моделировать поведение сетевых устройств. Однако их назначение отличается от цели данной работы. Они ориентированы на эмуляцию оборудования конкретного производителя и обучение настройке сетевых устройств, а не на универсальное формализованное описание конфигурации сети виртуальных машин для лабораторных стендов.
Эти решения ближе к реальной настройке сети, чем универсальные диаграммеры: они позволяют нарисовать топологию сетевых устройств, однако их назначение далеко от цели данной работы. Диаграммеры в их составе ориентированы на описание сети на основе оборудования конкретного производителя, а не на универсальное формализованное описание конфигурации сети виртуальных машин для лабораторных стендов.
(стоит ли писать) Кроме того, сетевые эмуляторы оказываются избыточными для рассматриваемой задачи. В работе требуется зафиксировать структуру конфигурации, известные и неизвестные параметры элементов, обеспечить редактируемость и экспорт описания. Полноценная симуляция сетевых протоколов и поведения оборудования для этого не требуется.P
\begin{figure}[H]
\centering
\includegraphics[width=0.8\textwidth]{files/cisco.png}
\caption{Диаграмма сети в Cisco Packet Tracer}
\label{fig:cisco}
\end{figure}
Также такие системы хуже подходят для независимого структурированного хранения модели, которую можно было бы использовать как источник данных для разных представлений: таблицы, диаграммы или YAML-файла.
\begin{figure}[H]
\centering
\includegraphics[width=0.8\textwidth]{files/ensp.png}
\caption{Диаграмма сети в Huawei eNSP}
\label{fig:ensp}
\end{figure}
\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}[H]
\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}, позволяющая генерировать текстовое описание диаграммы. Другие генераторы диаграмм также могли бы использоваться.
+56 -90
View File
@@ -1,34 +1,27 @@
\section{Исследование и построение решения задачи}
\section{Выбор формата табличного представления конфигурации сети}
\label{sec:Chapter3} \index{Chapter3}
% \todo[inline]{Здесь надо декомпозировать большую задачу из постановки на подзадачи и продолжать этот процесс, пока подзадачи не станут достаточно простыми, чтобы их можно было бы решить напрямую (например, поставив какой-то эксперимент или доказав теорему) или найти готовое решение.}
\subsection{Представление модели}
Рассмотрение существующих решений показывает, что диаграмма удобна для визуального восприятия, но недостаточна как основная форма хранения данных: графическое изображение сложно интерпретировать как строгое описание конфигурации. Поэтому в качестве основы решения выбрано табличное представление данных, а диаграмма рассматривается только как производное отображение модели. Такой подход позволяет отделить логическое описание сети от способа его визуализации.
Исходя из результатов обзора, в качестве пользовательской формы задания конфигурации выбрано табличное представление. Такая форма представления удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения.
Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения.
При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: единая таблица и раздельные таблицы. Оба варианта позволяют структурированно описать сеть, однако различаются сложностью редактирования данных в случае непосредственной работы с таблицами.
При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: представление в первой нормальной форме и представление в третьей нормальной форме. Оба варианта позволяют формализовать описание сети, однако различаются удобством редактирования данных. Вторая нормальная форма отдельно не рассматривалась как самостоятельный вариант представления, поскольку для данной задачи она является промежуточным этапом между компактным пользовательским описанием и полностью разнесённой структурой данных.
Разберём оба представления на примере топологии, изображённой на рисунке~\ref{fig:exmpl1}
Разберём оба представления на примере топологии, изображённой на рис.~\ref{fig:exmpl1}
\begin{figure}[h]
\begin{figure}[htbp]
\centering
\includegraphics[width=0.8\textwidth]{files/exmpl1.png}
\caption{Пример топологии}
\label{fig:exmpl1}
\end{figure}
\subsubsection*{Первая нормальная форма}
\subsubsection*{Представление в единой таблице}
Первая нормальная форма (далее - 1НФ) \cite{DB}:
Переменная отношения находится в \textbf{1НФ} тогда и только тогда, когда в любом допустимом значении этой переменной отношения каждый её кортеж содержит только одно значение для каждого из атрибутов.
В первой нормальной форме данные представляются в виде одной таблицы, где каждая строка содержит атомарные значения: имя узла, интерфейс, адреса, принадлежность сети и т.д.. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации.
При представлении данных в виде одной таблицы (аналогично первой нормальной форме в СУБД \cite{DB}) каждая строка содержит сведения об отдельном элементе или связи конфигурации: имя узла, интерфейс, адреса, принадлежность сети и т.д. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации.
Пример представления в 1НФ (таблица \ref{tab:1nf}):
Пример представления конфигурации сети в единой таблице приведен в таблице \ref{tab:1nf}.
\begin{table}[h!]
\centering
@@ -48,32 +41,20 @@ com\_right & Switch & eth2 & D & \\
com\_right & Switch & eth3 & C & \\
\hline
\end{tabular}
\caption{Конфигурация сетевых устройств}
\caption{Единая таблица конфигурации сетевых устройств}
\label{tab:1nf}
\end{table}
\subsubsection*{Третья нормальная форма}
\subsubsection*{Представление в раздельных таблицах}
Третья нормальная форма (далее - 3НФ) \cite{DB}:
При представлении данных в виде раздельных таблиц (аналогично третьей нормальной форме в СУБД) сведения о конфигурации распределяются по основным видам сущностей: узлы (устройства), интерфейсы, сетевые сегменты и связи. Каждой из этих сущностей сопоставляется отдельная таблица. Такой подход уменьшает дублирование данных по сравнению с единой таблицей, однако делает представление более громоздким. Для понимания одной связи приходится обращаться сразу к нескольким таблицам.
Переменная отношения находится в \textbf{3НФ} тогда и только тогда, когда её неключевые атрибуты, если они существуют, являются одновременно:
Пример представления конфигурации сети в раздельных приведен в таблицах \ref{tab:3nf1}~-- \ref{tab:3nf3}.
\begin{table}[H]
\centering
\small
\begin{enumerate}
\item взаимно независимыми;
\item неприводимо зависимыми от первичного ключа.
\end{enumerate}
\begin{itemize}
\item \textbf{Неключевой атрибут} --- это атрибут, который не входит в состав первичного ключа рассматриваемой переменной отношения.
\item \textbf{Взаимно независимые атрибуты} --- это два или больше атрибутов, таких что ни один из них функционально не зависит от какой-либо комбинации остальных атрибутов. Подобная независимость подразумевает, что каждый такой атрибут может обновляться независимо от остальных атрибутов.
\end{itemize}
В третьей нормальной форме данные разделяются на отдельные сущности: узлы, интерфейсы, сетевые сегменты и связи. Такой подход уменьшает дублирование данных и лучше соответствует классической реляционной модели, однако делает представление более громоздким. Для понимания одной связи приходится обращаться сразу к нескольким таблицам.
Пример представления в 3НФ (таблицы \ref{tab:3nf1} - \ref{tab:3nf3}):
\begin{table}[h]
\begin{minipage}[t]{0.3\textwidth}
\centering
\begin{tabular}{|l|l|}
\hline
@@ -87,69 +68,54 @@ com\_right & Switch & eth3 & C & \\
com\_right & Switch \\
\hline
\end{tabular}
\caption{Сетевые устройства}
\captionof{table}{Сетевые устройства}
\label{tab:3nf1}
\end{table}
\begin{table}[h]
\end{minipage}
\hfill
\begin{minipage}[t]{0.38\textwidth}
\centering
\begin{tabular}{|l|l|l|}
\hline
Host Name & Interface & Network \\
\hline
PC1 & eth1 & A \\
PC2 & eth1 & B \\
PC3 & eth1 & C \\
PC4 & eth1 & D \\
com\_left & eth1 & tr \\
com\_left & eth2 & A \\
com\_left & eth3 & B \\
com\_right & eth1 & tr \\
com\_right & eth2 & D \\
com\_right & eth3 & C \\
\hline
\end{tabular}
\caption{Интерфейсы}
\label{tab:3nf2}
\end{table}
\begin{table}[h]
\centering
\begin{tabular}{|l|l|}
Host Name & Interface & Network \\
\hline
PC1 & eth1 & A \\
PC2 & eth1 & B \\
PC3 & eth1 & C \\
PC4 & eth1 & D \\
com\_left & eth1 & tr \\
com\_left & eth2 & A \\
com\_left & eth3 & B \\
com\_right & eth1 & tr \\
com\_right & eth2 & D \\
com\_right & eth3 & C \\
\hline
Interface & IP \\
\hline
PC1.eth1 & 10.0.0.1/24 \\
PC2.eth1 & 10.0.0.2/24 \\
PC3.eth1 & 10.0.0.3/24 \\
PC4.eth1 & 10.0.0.4/24 \\
\hline
\end{tabular}
\caption{IP-адреса интерфейсов}
\label{tab:3nf3}
\captionof{table}{Интерфейсы}
\label{tab:3nf2}
\end{minipage}
% \hfill
% \begin{minipage}[t]{0.28\textwidth}
% \centering
% \begin{tabular}{|l|l|}
% \hline
% Interface & IP \\
% \hline
% PC1.eth1 & 10.0.0.1/24 \\
% PC2.eth1 & 10.0.0.2/24 \\
% PC3.eth1 & 10.0.0.3/24 \\
% PC4.eth1 & 10.0.0.4/24 \\
% \hline
% \end{tabular}
% \captionof{table}{IP-адреса интерфейсов}
% \label{tab:3nf3}
% \end{minipage}
\end{table}
\subsubsection*{Выбор формы}
\begin{table}[H] \centering \begin{tabular}{|l|l|} \hline Interface & IP \\ \hline PC1.eth1 & 10.0.0.1/24 \\ PC2.eth1 & 10.0.0.2/24 \\ PC3.eth1 & 10.0.0.3/24 \\ PC4.eth1 & 10.0.0.4/24 \\ \hline \end{tabular} \caption{IP-адреса интерфейсов} \label{tab:3nf3} \end{table}
В качестве основного пользовательского представления была выбрана первая нормальная форма. Она удобнее для ручного заполнения, проще воспринимается при описании лабораторных стендов и не требует постоянного перехода между большим количеством связанных таблиц.
\subsubsection*{Выбор представления}
Табличное представление в 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 и диаграмма — как формы представления результата. Такой подход позволяет обеспечить редактируемость, воспроизводимость и возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.
Единая таблица используется как форма ввода с помощью табличного процессора (например, LibreOffice Calc), а при дальнейшей обработке данные могут преобразовываться во внутреннюю модель, где отдельно выделяются узлы, интерфейсы и связи. Такой подход сохраняет простоту заполнения таблицы и одновременно позволяет использовать данные для экспорта во входные форматы средства развертывания сетевых конфигураций или средства построения диаграмм топологии.
+70 -5
View File
@@ -1,10 +1,75 @@
\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}[H]
\centering
\includegraphics[width=0.8\textwidth]{files/UML.png}
\caption{UML диаграмма классов Python}
\label{fig:uml_model}
\includegraphics[width=1\textwidth]{files/UML.png}
\caption{UML-диаграмма классов Python}
\label{fig:uml_model1}
\end{figure}
Табличное представление используется для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, которое было реализовано в виде набора объектов Python (рис. \ref{fig:uml_model1}), соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого данные могут быть преобразованы в другие форматы.
Также необходима разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт во входные языки средства развертывания сетевых конфигураций \cite{netloom} и средства построения диаграмм (D2).
Программная реализация выполнена на языке Python. Объём написанного кода: 710 строк, 48 килобайт. Код выложен на веб-сервисе Github \cite{github}. На рис. \ref{fig:schema} представлен процесс работы с утилитой. Построение диаграмм происходит с помощью модуля py-d2 (пример на рис. \ref{fig:diagram}).
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{files/diagram.png}
\caption{Пример диаграмммы, построенной утилитой}
\label{fig:diagram}
\end{figure}
\begin{figure}[H]
\centering
\includegraphics[width=1\textwidth]{files/schema.png}
\caption{Схема работы программной реализации}
\label{fig:schema}
\end{figure}
Воспроизводимость описания конфигурации обеспечивается тем, что результат хранится в виде структурированных данных. Одна и та же таблица при повторной обработке приводит к построению той же внутренней модели и, соответственно, к одинаковому описанию конфигурации. А преобразование в формат, пригодный для использования в средстве развёртывания сети виртуальных машин, обеспечивает возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.
Пример экспортированного YAML-описания конфигурации сети приведён в листинге~\ref{lst:yaml-config}.
% \newpage
\lstinputlisting[
language=yaml,
caption={Фрагмент YAML-описания конфигурации сети виртуальных машин},
label={lst:yaml-config},
frame=single,
framerule=0.4pt,
numbers=left,
numberstyle=\tiny,
basicstyle=\ttfamily\footnotesize,
lineskip=-1pt,
breaklines=true,
columns=fullflexible,
keepspaces=true
]{files/topology.yaml}
% \lstinputlisting[
% language=yaml,
% caption={Фрагмент YAML-описания конфигурации сети виртуальных машин},
% label={lst:yaml-config}
% ]{files/topology.yaml}
% Таким образом, решение строится не вокруг построения диаграммы, а вокруг формальной модели сетевой конфигурации. Табличное представление используется как способ ввода и редактирования, внутренняя модель — как основа обработки данных, а YAML и диаграмма — как формы представления результата. Такой подход позволяет обеспечить редактируемость, воспроизводимость и возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.
+3 -7
View File
@@ -1,16 +1,12 @@
\anonsection{Заключение}
\label{sec:Chapter5} \index{Chapter5}
В ходе выполнения курсовой работы был разработан подход к описанию сетевых конфигураций виртуальных машин, ориентированный на формализованное задание структуры сети и последующий экспорт результата во входной формат средства развертывания конфигурации сети ВМ.
В результате работы были получены следующие результаты:
В работе получены следующие результаты:
\begin{itemize}
\item выполнен анализ существующих подходов к описанию и визуализации сетевых конфигураций; на его основе выбран способ редактирования конфигурации с использованием табличного представления во внешнем редакторе;
\item разработана модель представления конфигурации сети виртуальных машин в виде структурированных данных, позволяющая описывать устройства, интерфейсы, сети и связи между ними, а также оставлять отдельные параметры незаполненными;
\item разработана модель для представления конфигурации сети виртуальных машин в виде структурированных данных, позволяющая описывать устройства, интерфейсы, сети и связи между ними, а также оставлять отдельные параметры незаполненными;
\item выполнено сопряжение табличного представления с разработанной моделью данных, что обеспечивает ввод, редактирование и последующую обработку описания конфигурации;
\item разработана программа преобразования табличного описания во входной язык NetLoom, обеспечивающая дальнейшее использование для разворачивания конфигурации сети виртуальных машин.
\item разработана программа преобразования табличного описания во входные языки средства визуализации конфигурации сети виртуальных машин и средства развертывания конфигурации.
\end{itemize}
Таким образом, поставленная задача была решена: получено средство, позволяющее описывать частично заданные сетевые конфигурации виртуальных машин, редактировать их в табличной форме и преобразовывать в структурированный текстовый формат, пригодный для дальнейшей обработки.
В качестве направлений развития работы можно предложить разработку отдельного редактора конфигурации сети, использующего созданную модель данных. Также перспективным является встраивание в редактор функций проверки корректности конфигурации, а также поддержка диаграмм для отображения конфигурации сети на разных уровнях стека протоколов.
+15 -1
View File
@@ -28,8 +28,22 @@ 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 с.
Дейт К.Дж. Введение в системы баз данных (8-е изд.)~// Издательский дом "Вильямс". 2005. 1327 с.
\bibitem{netloom}
Netloom. A CLI tool for creating and managing network lab topologies.
\url{https://github.com/wlix13/NetLoom/} (accessed May~23, 2026)
\bibitem{github}
Программная реализация инструмента.
\url{https://github.com/kr0sh512/network-diagrams-tool} (accessed May~19, 2026)
% \bibitem{TEST}
% \textbf{Балашов\;В.\;В., Абрамов \;А.\;В., Чупахин \;А.\;А. и др.} Муравьиный алгоритм
Binary file not shown.

Before

Width:  |  Height:  |  Size: 120 KiB

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 500 KiB

After

Width:  |  Height:  |  Size: 283 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 157 KiB

After

Width:  |  Height:  |  Size: 76 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 507 KiB

After

Width:  |  Height:  |  Size: 105 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 214 KiB

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 78 KiB

After

Width:  |  Height:  |  Size: 64 KiB

+10
View File
@@ -0,0 +1,10 @@
сетевая топология --> "табличное представление (.csv)": ручное задание
"табличное представление (.csv)" --> внутренняя модель (Python) : разбор
внутренняя модель (Python) --> "описание диаграммы (.d2)" : визуализация
"описание диаграммы (.d2)" --> "диаграмма (.svg)" : использование D2
внутренняя модель (Python) --> "описание для Netloom (.yaml)" : экспорт
"описание для Netloom (.yaml)" --> средство развёртывания сетевой топологии (Netloom) {
style.stroke-dash: 5
}
средство развёртывания сетевой топологии (Netloom).style.stroke-dash: 5
Binary file not shown.

After

Width:  |  Height:  |  Size: 53 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 24 KiB

+26
View File
@@ -0,0 +1,26 @@
meta:
id: topology.yaml
name: topology.yaml
networks:
- name: A
nodes:
- role: host
name: PC1
interfaces:
eth1:
ip: 10.0.0.1/24
network: A
gateway: null
index: 1
bridges: []
vlans: []
- role: host
name: PC2
interfaces:
eth1:
ip: 10.0.0.2/24
network: A
gateway: null
index: 1
bridges: []
vlans: []
Binary file not shown.

Before

Width:  |  Height:  |  Size: 103 KiB

After

Width:  |  Height:  |  Size: 61 KiB

+1 -1
View File
@@ -49,7 +49,7 @@
\Consultant{Курячий Георгий Владимирович}
\ConsultantDegree{}
\Abstract{В данной работе рассматривается задача разработки средства описания конфигурации сети виртуальных машин для лабораторных работ. Изучены существующие решения и выявлены их недостатки. Разработана и реализована модель данных для представления конфигурации сети. Разработаны и реализованы программные инструменты для редактирования, графического представления и вывода в структурированном текстовом формате конфигурации сети.}
\Abstract{В данной работе рассматривается задача разработки средства описания конфигурации сети виртуальных машин для лабораторных работ. Изучены существующие решения и выявлены их недостатки. Разработана и реализована модель данных для представления конфигурации сети. Разработаны и реализованы программные инструменты для редактирования, графического представления и вывода в структурированном текстовом формате конфигурации сети, входном для средства развертывания сети виртуальных машин.}
%%%% DON'T change this. It is here because .sty does not support cyrillic cp properly %%%%
+1 -1
View File
@@ -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{Граф работ и возможные расписания для него}