diff --git a/Latex/Chapter1_1.tex b/Latex/Chapter1_1.tex index 21a0c4c..a83bbaa 100644 --- a/Latex/Chapter1_1.tex +++ b/Latex/Chapter1_1.tex @@ -3,6 +3,64 @@ Под конфигурацией сети виртуальных машин в данной работе понимается формализованное описание набора виртуальных машин и связей между ними, необходимое для воспроизведения сетевой топологии лабораторного стенда. Такое описание должно фиксировать не только внешний вид схемы, но и параметры элементов сети, пригодные для дальнейшей обработки программой. -В состав описания конфигурации входят основные сущности сетевой топологии: узлы, сетевые интерфейсы и связи между ними. Узел соответствует виртуальной машине или иному элементу стенда. Для него могут задаваться имя, тип или роль в топологии, а также связанные с ним интерфейсы. Сетевой интерфейс описывает точку подключения узла к сети и может содержать имя интерфейса, MAC-адрес, IP-адрес и другие параметры, необходимые для настройки. Связь определяет соединение между интерфейсами или принадлежность интерфейса к определённому сетевому сегменту. +В текущей версии модели описываются следующие элементы и поля: + +\begin{enumerate} + \item \textbf{Топология сети} + + Топология представляет собой полное описание рассматриваемой конфигурации. Она объединяет все устройства и сети, входящие в состав лабораторного стенда. + + В составе топологии фиксируются: + \begin{itemize} + \item список устройств; + \item список сетей; + \end{itemize} + + \item \textbf{Устройство} + + Устройство соответствует отдельному элементу стенда. В зависимости от назначения оно может рассматриваться как хост, маршрутизатор или коммутатор. Такое деление нужно для указания роли устройства в топологии, но все эти элементы имеют общую структуру описания. + + Для устройства задаются: + \begin{itemize} + \item \textbf{имя устройства}~--- уникальное обозначение элемента в пределах топологии; + \item \textbf{роль устройства}~--- назначение элемента в сети, например хост, маршрутизатор или коммутатор; + \item \textbf{набор сетевых интерфейсов}~--- перечень интерфейсов, принадлежащих данному устройству. + \end{itemize} + + Одно устройство может иметь один или несколько сетевых интерфейсов. Каждый интерфейс принадлежит ровно одному устройству. + + \item \textbf{Сетевой интерфейс} + + Сетевой интерфейс описывает точку подключения устройства к сети. Через интерфейсы задаются адресация, принадлежность к сетям, VLAN и отношения между физическими или логическими интерфейсами. + + Для интерфейса задаются: + \begin{itemize} + \item \textbf{имя интерфейса}~--- обозначение интерфейса внутри устройства; + \item \textbf{тип интерфейса}~--- характеристика интерфейса, например физический, виртуальный, VLAN-интерфейс или bridge-интерфейс; + \item \textbf{адаптер}~--- сведения о сетевом адаптере, с которым связан интерфейс; + \item \textbf{подчинённые интерфейсы}~--- список интерфейсов для bridge-интерфейса; + \item \textbf{родительский интерфейс}~--- интерфейс, на основе которого создан vlan-интерфейс; + \item \textbf{IP-адрес}~--- адрес интерфейса в соответствующей сети; + \item \textbf{сеть}~--- имя сети или сегмента, к которому подключён интерфейс; + \item \textbf{маска подсети}~--- параметр, определяющий размер IP-сети; + \item \textbf{шлюз по умолчанию}~--- адрес маршрутизатора, используемый для выхода из сети; + \item \textbf{VLAN}~--- идентификатор виртуальной локальной сети; + \item \textbf{устройство-владелец}~--- устройство, которому принадлежит данный интерфейс. + \end{itemize} + + Интерфейс связан с одним устройством и может быть включён в одну сеть. При этом сеть может содержать несколько интерфейсов разных устройств. + + \item \textbf{Сеть} + + Сеть описывает общий сетевой сегмент, к которому могут быть подключены интерфейсы устройств. Она используется для группировки интерфейсов и задания их "физической" связи. + + Для сети задаются: + \begin{itemize} + \item \textbf{имя сети}~--- обозначение сетевого сегмента в пределах топологии; + \item \textbf{список подключённых интерфейсов}~--- интерфейсы устройств, входящие в данную сеть; + \end{itemize} + + Одна сеть может объединять один или несколько интерфейсов. Каждый интерфейс в текущей модели относится к одной сети или остаётся без указания сети, если этот параметр ещё не определён. +\end{enumerate} Так как на этапе планирования часть параметров может быть неизвестна, описание конфигурации должно допускать частично заполненные данные. Это позволяет зафиксировать структуру сети, а затем уточнять отдельные значения без изменения общей модели. Таким образом, конфигурация рассматривается как редактируемое структурированное описание, которое может быть представлено в табличном виде, использовано для построения диаграммы или экспортировано в формат YAML. diff --git a/Latex/Chapter3.tex b/Latex/Chapter3.tex index 72e2931..407835c 100644 --- a/Latex/Chapter3.tex +++ b/Latex/Chapter3.tex @@ -4,18 +4,119 @@ Поставленная задача состоит в разработке средства, позволяющего описывать частично сконфигурированную сеть виртуальных машин и получать на основе этого описания формализованное представление конфигурации. Для построения решения общая задача была разложена на несколько подзадач: определение состава описываемой информации, выбор формы представления данных, построение внутренней модели, разработка способа редактирования и реализация механизмов преобразования описания. -\todo[inline]{пока что нет конретики в том, какие поля мы описываем. Куда вставить их?} +\subsection{Представление модели} -Первой подзадачей является определение состава информации, необходимой для описания сетевой конфигурации. Конфигурация сети виртуальных машин рассматривается как совокупность узлов, сетевых интерфейсов и связей между ними. Узел соответствует виртуальной машине, интерфейс задаёт точку подключения узла к сети, а связь описывает соединение интерфейсов или их принадлежность к одному сетевому сегменту. Для этих сущностей необходимо хранить имена, адреса, роли, параметры подключения и другие атрибуты, которые могут использоваться при последующей настройке или визуализации. +Рассмотрение существующих решений показывает, что диаграмма удобна для визуального восприятия, но недостаточна как основная форма хранения данных: графическое изображение сложно интерпретировать как строгое описание конфигурации. Поэтому в качестве основы решения выбрано табличное представление данных, а диаграмма рассматривается только как производное отображение модели. Такой подход позволяет отделить логическое описание сети от способа его визуализации. -Второй подзадачей является выбор основного представления конфигурации. Рассмотрение существующих решений показывает, что диаграмма удобна для визуального восприятия, но недостаточна как основная форма хранения данных: графическое изображение сложно интерпретировать как строгое описание конфигурации. Поэтому в качестве основы решения выбрано табличное представление данных, а диаграмма рассматривается только как производное отображение модели. Такой подход позволяет отделить логическое описание сети от способа его визуализации. +Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения. -Третья подзадача связана с разработкой табличного способа задания конфигурации. Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения. +При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: представление в первой нормальной форме и представление в третьей нормальной форме. Оба варианта позволяют формализовать описание сети, однако различаются удобством редактирования данных. -Четвёртой подзадачей является построение внутренней модели данных. Табличное представление удобно для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор классов Python, соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого могут формироваться другие виды результата. +В первой нормальной форме данные представляются в виде одной или нескольких таблиц, где каждая строка содержит атомарные значения: имя узла, интерфейс, адреса, принадлежность сети и т.д.. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации. + +Разберём оба представления на примере топологии, изображённой на рисунке~\ref{fig:exmpl1} + +\begin{figure}[h] +\centering +\includegraphics[width=0.8\textwidth]{files/exmpl1.png} +\caption{Пример топологии} +\label{fig:exmpl1} +\end{figure} + +Пример представления в 1НФ: + +\begin{table}[h!] +\centering +\begin{tabular}{|l|l|l|l|l|} +\hline +\textbf{Name} & \textbf{Role} & \textbf{Interface} & \textbf{Network} & \textbf{Device IP} \\ +\hline +PC1 & Host & eth1 & A & 10.0.0.1/24 \\ +PC2 & Host & eth1 & B & 10.0.0.2/24 \\ +PC3 & Host & eth1 & C & 10.0.0.3/24 \\ +PC4 & Host & eth1 & D & 10.0.0.4/24 \\ +com\_left & Switch & eth1 & tr & \\ +com\_left & Switch & eth2 & A & \\ +com\_left & Switch & eth3 & B & \\ +com\_right & Switch & eth1 & tr & \\ +com\_right & Switch & eth2 & D & \\ +com\_right & Switch & eth3 & C & \\ +\hline +\end{tabular} +\caption{Network device configuration} +\end{table} + +В третьей нормальной форме данные разделяются на отдельные сущности: узлы, интерфейсы, сетевые сегменты и связи. Такой подход уменьшает дублирование данных и лучше соответствует классической реляционной модели, однако делает представление более громоздким. Для понимания одной связи приходится обращаться сразу к нескольким таблицам. + +Пример представления в 3НФ: + +\begin{table}[h] +\centering +\begin{tabular}{|l|l|} + \hline + Name & Device \\ + \hline + PC1 & Host \\ + PC2 & Host \\ + PC3 & Host \\ + PC4 & Host \\ + com\_left & Switch \\ + com\_right & Switch \\ + \hline +\end{tabular} +\caption{Devices} +\end{table} + +\begin{table}[h] +\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{Interfaces} +\end{table} + +\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{IPs} +\end{table} + +В качестве основного пользовательского представления была выбрана первая нормальная форма. Она удобнее для ручного заполнения, проще воспринимается при описании лабораторных стендов и не требует постоянного перехода между большим количеством связанных таблиц. + +Табличное представление в 1НФ используется как удобная форма ввода, а при дальнейшей обработке данные могут преобразовываться во внутреннюю модель, где отдельно выделяются узлы, интерфейсы и связи. Такой подход сохраняет простоту заполнения таблицы и одновременно позволяет использовать данные для экспорта в YAML или построения диаграммы топологии. + +\subsection{Внутренняя модель данных} + +Табличное представление удобно для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор классов Python, соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого могут формироваться другие виды результата. \todo[inline]{хоть и акцент обычно на табличках, это не совсем центральное. Представить пример uml для python классов} -Пятой подзадачей является разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сеьи из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели. +\subsection{Преобразование модели данных} + +Также одной из подзадач является разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сеьи из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели. + +\subsection{Вывод} Таким образом, решение строится не вокруг построения диаграммы, а вокруг формальной модели сетевой конфигурации. Табличное представление используется как способ ввода и редактирования, внутренняя модель — как основа обработки данных, а YAML и диаграмма — как формы представления результата. Такой подход позволяет обеспечить редактируемость, воспроизводимость и возможность дальнейшего применения описания при подготовке лабораторных стендов из виртуальных машин. \ No newline at end of file diff --git a/Latex/Chapter4.tex b/Latex/Chapter4.tex index 15ebe15..af038e9 100644 --- a/Latex/Chapter4.tex +++ b/Latex/Chapter4.tex @@ -1,3 +1,10 @@ \section{Описание практической части} \label{sec:Chapter4} \index{Chapter4} -\todo[inline]{Если в рамках работы писался какой-то код, здесь должно быть его описание: выбранный язык и библиотеки и мотивы выбора, архитектура, схема функционирования, теоретическая сложность алгоритма, характеристики функционирования (скорость/память).} \ No newline at end of file +\todo[inline]{Если в рамках работы писался какой-то код, здесь должно быть его описание: выбранный язык и библиотеки и мотивы выбора, архитектура, схема функционирования, теоретическая сложность алгоритма, характеристики функционирования (скорость/память).} + +\begin{figure}[h] +\centering +\includegraphics[width=0.8\textwidth]{files/UML.png} +\caption{UML диаграмма классов Python} +\label{fig:uml_model} +\end{figure} \ No newline at end of file diff --git a/Latex/Chapter6.tex b/Latex/Chapter6.tex index 10a4dde..905fa29 100644 --- a/Latex/Chapter6.tex +++ b/Latex/Chapter6.tex @@ -1,16 +1,20 @@ \begin{thebibliography}{} + +\bibitem{drawio} + draw.io. Configurable diagramming application, 2026. Available at \url{https://github.com/jgraph/drawio/wiki} (accessed May~19, 2026). -\bibitem{TEST} -\textbf{Балашов\;В.\;В., Абрамов \;А.\;В., Чупахин \;А.\;А. и др.} Муравьиный алгоритм -для построения однопроцессорного расписания с минимизацией пикового -использования ресурса~// Дискретный анализ и исследование операций. – -2024. – Т. 31, №2. – С. 5–26. +\bibitem{Lucidchart} +Lucidchart. Visual workspace for diagramming, 2026. Available at \url{https://www.lucidchart.com/pages} (accessed May~19, 2026). -\bibitem{DB} -\textbf{Date \;C.\;J.} Введение в системы баз данных~// Издательский дом "Вильяме". – 2005. – 457-488 с. -\bibitem{BAKER} -\textbf{Baker \;K.\;R., Trietsch \;D.} Principles of Sequencing and Scheduling~// John Wiley \& Sons. – 2009. – 510 p. +\bibitem{Visio} +Microsoft Visio. Visual workspace for diagramming, 2026. Available at \url{https://support.microsoft.com/en-US/Visio/beginner-tutorial-for-visio} (accessed May~19, 2026). + +\bibitem{Cisco} +Cisco Packet Tracer. Network simulation tool, 2026. Available at \url{https://www.netacad.com/cisco-packet-tracer} (accessed May~19, 2026). + +\bibitem{eNSP} +Huawei eNSP. Enterprise network simulation platform, 2026. Available at \url{https://support.huawei.com/enterprise/en/nce-data-communication/ensp-pid-9017384} (accessed May~19, 2026). \bibitem{D2} D2. Diagram scripting language, 2026. Available at \url{https://d2lang.com/tour/intro/} (accessed May~19, 2026). @@ -21,20 +25,18 @@ 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{Cisco} -Cisco Packet Tracer. Network simulation tool, 2026. Available at \url{https://www.netacad.com/cisco-packet-tracer} (accessed May~19, 2026). +\bibitem{DB} +\textbf{Date \;C.\;J.} Введение в системы баз данных~// Издательский дом "Вильяме". – 2005. – 457-488 с. -\bibitem{eNSP} -Huawei eNSP. Enterprise network simulation platform, 2026. Available at \url{https://support.huawei.com/enterprise/en/nce-data-communication/ensp-pid-9017384} (accessed May~19, 2026). +\bibitem{TEST} +\textbf{Балашов\;В.\;В., Абрамов \;А.\;В., Чупахин \;А.\;А. и др.} Муравьиный алгоритм +для построения однопроцессорного расписания с минимизацией пикового +использования ресурса~// Дискретный анализ и исследование операций. – +2024. – Т. 31, №2. – С. 5–26. -\bibitem{Lucidchart} -Lucidchart. Visual workspace for diagramming, 2026. Available at \url{https://www.lucidchart.com/pages} (accessed May~19, 2026). -\bibitem{Visio} -Microsoft Visio. Visual workspace for diagramming, 2026. Available at \url{https://support.microsoft.com/en-US/Visio/beginner-tutorial-for-visio} (accessed May~19, 2026). - -\bibitem{drawio} -draw.io. Configurable diagramming application, 2026. Available at \url{https://github.com/jgraph/drawio/wiki} (accessed May~19, 2026). +\bibitem{BAKER} +\textbf{Baker \;K.\;R., Trietsch \;D.} Principles of Sequencing and Scheduling~// John Wiley \& Sons. – 2009. – 510 p. \end{thebibliography} \ No newline at end of file diff --git a/Latex/files/UML.png b/Latex/files/UML.png new file mode 100644 index 0000000..bf068f4 Binary files /dev/null and b/Latex/files/UML.png differ diff --git a/Latex/files/UML.svg b/Latex/files/UML.svg new file mode 100644 index 0000000..6979430 --- /dev/null +++ b/Latex/files/UML.svg @@ -0,0 +1,105 @@ +Interface+namestr+itype[str]+adapter[str]+slave_interfaces[List[str]]+parent_interface[str]+ip_address[str]+network[str]+subnet_mask[str]+default_gateway[str]+vlan[str]+deviceDevice+__init__(name, ...)void+__repr__(): strvoidDevice+namestr+rolestr+interfacesDict[str, Interface]+__init__(name: str)void+add_interface(interface: Interface)void+rm_interface(interface: Interface)void+__repr__(): strvoidHost+rolestrRouter+rolestrSwitch+rolestrNetwork+namestr+interfacesList[Interface]+network_ip[str]+__init__(name: str, [vlan: [str]], [network_ip: [str]])void+add_interface(interface: Interface)void+rm_interface(interface: Interface)void+__repr__(): strvoidTopology+devicesDict[str, Device]+networksDict[str, Network]+__init__()void+add_device(device: Device)void+rm_device(device: Device)void+add_network(network: Network)void+rm_network(network: Network)void+__repr__(): strvoid interfaces1..*1interfaces1..*1devices1..*1networks1..*1 + + + + + + diff --git a/Latex/files/exmpl1.png b/Latex/files/exmpl1.png new file mode 100644 index 0000000..9e3f9f6 Binary files /dev/null and b/Latex/files/exmpl1.png differ diff --git a/notes.md b/notes.md new file mode 100644 index 0000000..b82f0fb --- /dev/null +++ b/notes.md @@ -0,0 +1,49 @@ +дд: в пт 10:00 + +/раздел 4.1 перетянуть в 2 раздел + +?4.1 4.2 - представление конфигурации сети для редактирования +ссылка на 2 раздел, отсылка к обзору +/=> 4.2 и 4.3 объединяются + +/убрать подсчёт подзадач + +набор полей в таблице + +почему остальные нф нет + +сслыки на таблицы тоже +явное определение 3нф и 1нф +ввести сокращение +убрать рамку + +/сделать более полную таблицу + +- no need + +UML перенести в 4.4 +вырезать все методы у UML + +раздел 4.5 в описание программной реализации +там же говорим и про csv - модель данных - yaml + +- диаграмма как что куда генерится (пунктиром развертывание конфигурации сети) + +Переименвать 4 в Построение модели данных + +В 5 раздел +Объектная там, делает преобразования такие-то +объем строк, размер, бла-бла, гитхаб репу +там же картинки с визуализацией +тут же в подразделе, что только L1 +табличное - внешний редактор (в диаграмках) + +заключение +в будущем: +разработка редактора конфигурации сети, использующее модель +доп отображение уровней +по итогу: +разработана модель +выполнено сопряженение +на основе обзора табличное редактирование сторонним редактором +разработана программа для преобразования табл в входной язык netloom. Програмное средство трансляцию и визуализацию