chapter3 wip

Latex/Chapter2.tex

@@ -18,11 +18,23 @@
 
 Эти решения ближе к реальной настройке сети, чем универсальные диаграммеры: они позволяют не только нарисовать топологию, но и моделировать поведение сетевых устройств. Однако их назначение отличается от цели данной работы. Они ориентированы на эмуляцию оборудования конкретного производителя и обучение настройке сетевых устройств, а не на универсальное формализованное описание конфигурации сети виртуальных машин для лабораторных стендов.
 
-(стоит ли писать) Кроме того, сетевые эмуляторы оказываются избыточными для рассматриваемой задачи. В работе требуется зафиксировать структуру конфигурации, известные и неизвестные параметры элементов, обеспечить редактируемость и экспорт описания. Полноценная симуляция сетевых протоколов и поведения оборудования для этого не требуется. 
+(стоит ли писать) Кроме того, сетевые эмуляторы оказываются избыточными для рассматриваемой задачи. В работе требуется зафиксировать структуру конфигурации, известные и неизвестные параметры элементов, обеспечить редактируемость и экспорт описания. Полноценная симуляция сетевых протоколов и поведения оборудования для этого не требуется.P 
 
 Также такие системы хуже подходят для независимого структурированного хранения модели, которую можно было бы использовать как источник данных для разных представлений: таблицы, диаграммы или YAML-файла.
 
 \subsection{Генераторы диаграмм}
 
+Третью группу составляют генераторы диаграмм по текстовому описанию: D2, Graphviz, PlantUML. Все три инструмента используют декларативный язык, позволяющий преобразовывать текстовое описание в диаграмму и выполняют смежные задачи.
+
+Такие инструменты лучше соответствуют требованию воспроизводимости, поскольку исходное описание диаграммы хранится в текстовом виде, что упрощает интеграцию с программной реализацией. По этой причине генераторы диаграмм могут быть полезны как вспомогательный механизм визуализации сетевой топологии. В частности, в рамках работы D2 используется для построения графа L1 топологии сети на основе внутренней модели данных.
+
+Однако эти решения не решают задачу полностью. Их основной результат — диаграмма, а не предметная модель конфигурации сети виртуальных машин. Узлы и связи в таких языках можно снабжать дополнительными атрибутами, наращивая необходимые свойства, но такое представление, по мере увеличения сложности топологии, быстро становится трудно читаемым. Генератор диаграмм может отобразить уже подготовленную модель, но не заменяет саму модель данных и табличный способ её редактирования.
+
+\todo[inline]{картиночек, насколько неудобно в графе держать}
+
 \subsection{Вывод}
 
+Рассмотренные решения покрывают отдельные аспекты поставленной задачи, но не удовлетворяют ей полностью. Универсальные диаграммеры удобны для ручного построения схем, но плохо подходят для формализованного хранения параметров. Сетевые эмуляторы позволяют моделировать работу сети, но являются избыточными и ориентированы на симуляцию, а не на независимое описание конфигурации виртуальных машин. Генераторы диаграмм обеспечивают воспроизводимую визуализацию, однако требуют внешней модели данных, в которой будут определены сущности, атрибуты и правила экспорта.
+
+Таким образом, в качестве основы разрабатываемого решения целесообразно использовать не формат диаграммы, а структурированную модель данных сетевой конфигурации. Диаграмма и YAML-файл в этом случае выступают вспомогательными представлениями: диаграмма используется для визуального контроля топологии, а YAML — как пример формализованного экспорта описания. Такой подход соответствует цели работы: разработать инструмент планирования частично сконфигурированных сетевых конфигураций с табличным вводом, воспроизводимым хранением и возможностью дальнейшей обработки.
+

Latex/Chapter3.tex

@@ -1,3 +1,21 @@
 \section{Исследование и построение решения задачи}
 \label{sec:Chapter3} \index{Chapter3}
-\todo[inline]{Здесь надо декомпозировать большую задачу из постановки на подзадачи и продолжать этот процесс, пока подзадачи не станут достаточно простыми, чтобы их можно было бы решить напрямую (например, поставив какой-то эксперимент или доказав теорему) или найти готовое решение.}
+% \todo[inline]{Здесь надо декомпозировать большую задачу из постановки на подзадачи и продолжать этот процесс, пока подзадачи не станут достаточно простыми, чтобы их можно было бы решить напрямую (например, поставив какой-то эксперимент или доказав теорему) или найти готовое решение.}
+
+Поставленная задача состоит в разработке средства, позволяющего описывать частично сконфигурированную сеть виртуальных машин и получать на основе этого описания формализованное представление конфигурации. Для построения решения общая задача была разложена на несколько подзадач: определение состава описываемой информации, выбор формы представления данных, построение внутренней модели, разработка способа редактирования и реализация механизмов преобразования описания.
+
+\todo[inline]{пока что нет конретики в том, какие поля мы описываем. Куда вставить их?}
+
+Первой подзадачей является определение состава информации, необходимой для описания сетевой конфигурации. Конфигурация сети виртуальных машин рассматривается как совокупность узлов, сетевых интерфейсов и связей между ними. Узел соответствует виртуальной машине, интерфейс задаёт точку подключения узла к сети, а связь описывает соединение интерфейсов или их принадлежность к одному сетевому сегменту. Для этих сущностей необходимо хранить имена, адреса, роли, параметры подключения и другие атрибуты, которые могут использоваться при последующей настройке или визуализации.
+
+---
+
+Второй подзадачей является выбор основного представления конфигурации. Рассмотрение существующих решений показывает, что диаграмма удобна для визуального восприятия, но недостаточна как основная форма хранения данных: графическое изображение сложно интерпретировать как строгое описание конфигурации. Поэтому в качестве основы решения выбрано структурированное представление данных, а диаграмма рассматривается только как производное отображение модели. Такой подход позволяет отделить логическое описание сети от способа его визуализации.
+
+Третья подзадача связана с разработкой табличного способа задания конфигурации. Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения. Для уменьшения неоднозначности данные должны быть разнесены по сущностям предметной области: отдельно описываются узлы, интерфейсы и связи.
+
+Четвёртой подзадачей является построение внутренней модели данных. Табличное представление удобно для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор классов Python, соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого могут формироваться другие виды результата.
+
+Пятой подзадачей является разработка механизмов преобразования модели. Минимально необходимыми преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как читаемое структурированное описание, пригодное для дальнейшей обработки, а Graphviz может применяться для генерации визуального представления сети на основе уже построенной модели.
+
+Таким образом, решение строится не вокруг ручного рисования диаграммы, а вокруг формальной модели сетевой конфигурации. Табличное представление используется как способ ввода и редактирования, внутренняя модель — как основа обработки данных, а YAML и диаграмма — как производные формы представления результата. Такой подход позволяет обеспечить редактируемость, воспроизводимость и возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин.