section 2 WIP

This commit is contained in:
2026-04-29 15:41:24 +03:00
parent b570b7c9b0
commit 05f5cc692a
5 changed files with 229 additions and 0 deletions
+54
View File
@@ -0,0 +1,54 @@
# LaTeX build files
*.aux
*.bbl
*.bcf
*.blg
*.fdb_latexmk
*.fls
*.idx
*.ilg
*.ind
*.lof
*.log
*.lot
*.nav
*.out
*.run.xml
*.snm
*.synctex.gz
*.toc
*.vrb
# Beamer / minted / glossaries / nomenclature
*.acn
*.acr
*.alg
*.glg
*.glo
*.gls
*.ist
*.loa
*.lol
*.nlo
*.nls
*.pyg
_minted-*/
# Temporary files
*.tmp
*.bak
*.swp
*.swo
*~
# Editors / IDEs
.vscode/
.idea/
# OS files
.DS_Store
Thumbs.db
# Keep final PDFs ignored by default.
# Remove this line if you want to commit the compiled PDF.
*.pdf
+23
View File
@@ -3,3 +3,26 @@
% \todo[inline]{Здесь надо рассмотреть все существующие решения поставленной задачи, но не просто пересказать, в чем там дело, а оценить степень их соответствия тем ограничениям, которые были сформулированы в постановке задачи.}
Существующие решения, близкие к задаче описания конфигурации сети виртуальных машин, можно разделить на три группы: универсальные диаграммеры, сетевые эмуляторы и генераторы диаграмм по текстовому описанию. Их применимость целесообразно оценивать по следующим критериям: возможность изобразить структуру сети, возможность сопоставить элементам сети набор параметров, возможность интерпретировать результат как формализованное описание, пригодное для последующей обработки.
\subsection{Универсальные диаграммеры}
К универсальным диаграммерам относятся draw.io, Lucidchart и Microsoft Visio. Такие средства позволяют строить различные виды схем, в том числе сетевые диаграммы. Например, draw.io позиционируется как онлайн-инструмент для построения блок-схем, UML-, ER- и сетевых диаграмм; Microsoft Visio также содержит шаблоны и фигуры для сетевых диаграмм; Lucidchart поддерживает технические диаграммы и визуальное моделирование систем.
Основное преимущество таких решений состоит в удобстве визуального построения схемы. Пользователь может быстро расположить элементы, провести связи между ними и получить наглядное изображение топологии. Однако для поставленной задачи этого недостаточно. Диаграмма в таких системах в первую очередь является графическим объектом: она хорошо передаёт внешний вид структуры, но не задаёт строгую модель данных сетевой конфигурации. Параметры виртуальных машин, интерфейсов, MAC-адресов, IP-адресов и сетевых сегментов могут быть добавлены только как текстовые подписи или дополнительные свойства объектов, но их последующая автоматическая интерпретация становится нетривиальной.
Следовательно, универсальные диаграммеры могут использоваться для иллюстрации результата, но не являются подходящей основой для хранения и воспроизводимого редактирования конфигурации. Они не обеспечивают требуемой проверяемости описания и плохо подходят для ситуации, когда одному элементу сети необходимо сопоставить множество формализованных атрибутов.
\subsection{Сетевые эмуляторы}
Ко второй группе относятся сетевые эмуляторы, например Cisco Packet Tracer и Huawei eNSP. Cisco Packet Tracer предназначен для обучения сетевым технологиям и позволяет моделировать работу сетей в виртуальной лабораторной среде; Huawei eNSP также описывается как симулятор устройств, применяемый для подготовки в области передачи данных.
Эти решения ближе к реальной настройке сети, чем универсальные диаграммеры: они позволяют не только нарисовать топологию, но и моделировать поведение сетевых устройств. Однако их назначение отличается от цели данной работы. Они ориентированы на эмуляцию оборудования конкретного производителя и обучение настройке сетевых устройств, а не на универсальное формализованное описание конфигурации сети виртуальных машин для лабораторных стендов.
(стоит ли писать) Кроме того, сетевые эмуляторы оказываются избыточными для рассматриваемой задачи. В работе требуется зафиксировать структуру конфигурации, известные и неизвестные параметры элементов, обеспечить редактируемость и экспорт описания. Полноценная симуляция сетевых протоколов и поведения оборудования для этого не требуется.
Также такие системы хуже подходят для независимого структурированного хранения модели, которую можно было бы использовать как источник данных для разных представлений: таблицы, диаграммы или YAML-файла.
\subsection{Генераторы диаграмм}
\subsection{Вывод}
+42
View File
@@ -0,0 +1,42 @@
SRC_DIR := Latex
MAIN := main
BUILD_DIR := $(CURDIR)/.latexbuild
PDF := $(CURDIR)/$(MAIN).pdf
PDFLATEX := pdflatex
BIBTEX := bibtex
.PHONY: all pdf bib clean cleanall
all: pdf
pdf:
mkdir -p $(BUILD_DIR)
cd $(SRC_DIR) && \
$(PDFLATEX) -interaction=nonstopmode -halt-on-error \
-output-directory=$(BUILD_DIR) $(MAIN).tex
cd $(SRC_DIR) && \
$(PDFLATEX) -interaction=nonstopmode -halt-on-error \
-output-directory=$(BUILD_DIR) $(MAIN).tex
cp $(BUILD_DIR)/$(MAIN).pdf $(PDF)
bib:
mkdir -p $(BUILD_DIR)
cd $(SRC_DIR) && \
$(PDFLATEX) -interaction=nonstopmode -halt-on-error \
-output-directory=$(BUILD_DIR) $(MAIN).tex
cd $(BUILD_DIR) && \
$(BIBTEX) $(MAIN)
cd $(SRC_DIR) && \
$(PDFLATEX) -interaction=nonstopmode -halt-on-error \
-output-directory=$(BUILD_DIR) $(MAIN).tex
cd $(SRC_DIR) && \
$(PDFLATEX) -interaction=nonstopmode -halt-on-error \
-output-directory=$(BUILD_DIR) $(MAIN).tex
cp $(BUILD_DIR)/$(MAIN).pdf $(PDF)
clean:
rm -rf $(BUILD_DIR)
cleanall:
rm -rf $(BUILD_DIR) $(PDF)
+76
View File
@@ -0,0 +1,76 @@
# План доклада курсовой работы
!!! Акцент на хранение внутри, кодом (классы Python) может быть также важно, как и табличное представление.
## Аннотация
- краткое описание темы работы;
- цель разработки диаграммера сетевой топологии
- !меняем на необходимость формализованного описания, смещаем акцент
- итоговый результат: генерация YAML для развёртывания топологии в виртуальных машинах.
- !итоговый результат: модель данных. YAML-вывод только как пример
## Оглавление
- оглавление
## Введение
- актуальность автоматизации описания и развёртывания сетевых топологий;
- проблема отсутствия удобных диаграммеров под заданные требования;
- !попытка обыграть - есть диаграммеры, но они не подходят для задания структуры
- объект, предмет, цель и задачи работы.
## Постановка задачи
- формальное описание задачи построения топологии сети
- требования к входным данным, диаграмме и выходному YAML
- !отсюда дейтсвительно важно лишь до какой степени описываем в таблице? Какие ожидания
- всякие критерии?
## Обзор
- сравнение draw.io и аналогичных ему, нам не подходят
- обзор существующих диаграммеров: D2, Graphviz, Mermaid и аналогов;
- !только как дополнение к модели
- сравнение синтаксиса, Python-реализаций и применимости к сетевой топологии;
- обзор подходов к построению схем по табличному представлению данных (ну тут просто ничего)
- вывод - либо очень сложное, но формат в любом случае не подходит
- !а особенно для легкой воспроизводимости при лабораторных/на лекциях
## Исследование и решение задачи
- выделение сущностей предметной области: узлы, интерфейсы, связи
- представление данных в виде таблицы
- !поля, что куда относится и за что отвечает, ограничения (или их отсутствие)
- !фактически это и есть разработанная модель
- приведение к 1НФ и 3НФ
- разработка модели и алгоритма преобразования таблиц в топологию yaml и диаграммы
- !здесь остаётся только диаграммы и yaml как пример применения модели.
## Практическая часть, эксперимент
- описание реализованного кода и архитектуры программы
- !первостепенно и дополнительно: табличное хранение, UML-график с внутренним хранением внутри питона
- пример входных данных и построенной топологии
- !построенная топология снова только как показательный пример, что модель можно использовать
- пример сгенерированного YAML
- примеры на реальных лабах
## Заключение
- достигнутые цели и решённые задачи
- практическая значимость
- возможные направления дальнейшего развития.
## Список литературы
- источники по сетевым топологиям, нормализации, прочая штука
- документация по всяким диаграммерам.
## Приложения
- фрагменты кода;
- примеры таблиц в 1НФ и 3НФ;
- UML-диаграмма классов в Python
- примеры диаграмм и YAML-конфигураций на основе модели;
+34
View File
@@ -0,0 +1,34 @@
Введение подвод, стоит актуализировать/постановку
Обзор существующих решений, критерий
Состав описания, что входит в состав параметров
Далее выбор представления
(Попробовали диаграммеры, получили красивый способ рисования, но многие параметры отсутствуют формализации)
Удобство = проблематичность интерпретации
Одному элементу множество атрибутов
Ну и показать диаграммеры существующие (носят иллюстративный характер), интерпретация как формализованного описания проблематична
3 критерия:
Возможность описания структуры в виде диаграммы
Возможность сопоставления атрибутов
Возможность интерпретации как формализованного описания
Редактируемый, читаемый
Вывод:
Формат диаграммы как вид не берём
Обоснование первой формы
В программной реализации как раз модель внутри питончика
Главный недостаток - не видно всего + надо выстраивать связи
Выстроить описание рабочего процесса
На чём проверялась программная реализация (тестики, примеры)