|
|
|
|
\chapter{Design}\label{ch:design}
|
|
|
|
|
|
|
|
|
|
We now explain the design of Birdvisu in depth. First, we explain some
|
|
|
|
|
important decisions and present the overall structure of the project, then we
|
|
|
|
|
look into individual parts of the program.
|
|
|
|
|
|
|
|
|
|
Birdvisu is implemented in Python, using PySide6, the official bindings for
|
|
|
|
|
Qt6, for drawing on screen. We decided to use Qt, because it provides a lot of
|
|
|
|
|
pre-made widgets and tools and since it is widely used, it is easy to find help
|
|
|
|
|
for it on the Internet. The decision to use Python was not hard either. Not
|
|
|
|
|
only Qt has official bindings for it, but we use the language very often and
|
|
|
|
|
thus are comfortable writing in it. We do not expect the potential slowness of
|
|
|
|
|
Python to be an issue, because for handling graphics we are using Qt, which is
|
|
|
|
|
written in C++. Also, as we have analysed in section~\ref{s:areas}, we expect
|
|
|
|
|
the topologies to be quite small.
|
|
|
|
|
|
|
|
|
|
The project comprises of three main parts: data collection, annotation and
|
|
|
|
|
presentation part. The data collection part is tasked with finding out the
|
|
|
|
|
current topology and creating a usable representation of such topologies and
|
|
|
|
|
their combinations. In the annotation part, we add additional information to
|
|
|
|
|
the topologies like the difference from the expectation or graph properties of
|
|
|
|
|
the topology. Finally, when we have all the needed information, we draw the
|
|
|
|
|
topology on the screen, highlighting the relevant information.
|
|
|
|
|
|
|
|
|
|
\section{Recurring and general patterns}
|
|
|
|
|
|
|
|
|
|
\XXX{dictionaries everywhere, hashable recipes. ospffile with comments as a reusable format. Format of VertexID}
|
|
|
|
|
|
|
|
|
|
\section{Data collection: providers and parsing}
|
|
|
|
|
|
|
|
|
|
\XXX{sub-parts, why a topology is not a graph, stacking topologies with
|
|
|
|
|
multiedges, fake-freezing, why is everything static. Graph representation, selection of BIRD's
|
|
|
|
|
instance}
|
|
|
|
|
|
|
|
|
|
\section{Annotations}
|
|
|
|
|
|
|
|
|
|
\XXX{scoping, annotator creation, advantages of storing data in annotations and
|
|
|
|
|
not vertices. Annotator protocol and posibility of export. Various uses of annotators: enhancing, analysis, visualisation}
|
|
|
|
|
|
|
|
|
|
\section{Visualisation}
|
|
|
|
|
|
|
|
|
|
\XXX{Layouting (nonexistent), why not graphviz, why not consensual metrics, how we are re-using annotations internally. Saving layouts}
|
|
|
|
|
|
|
|
|
|
|
