|
|
@@ -1,15 +1,18 @@
|
|
|
\section{Assumptions}\label{sec:assumptions}
|
|
|
The following assumptions are made for the implementation of the node placement algorithm:
|
|
|
-\begin{itemize}
|
|
|
- \item There are no hyperedges.
|
|
|
- \item There are no port constraints.
|
|
|
- \item There are no labels.
|
|
|
- \item There are no cross-hierarchy edges.
|
|
|
- \item No edges over multiple layers (the previous phases should have added dummy nodes).
|
|
|
- \item Graphs are connected (see below).
|
|
|
-\end{itemize}
|
|
|
+\begin{enumerate}
|
|
|
+ \item \label{itm:hyperedges} There are no hyperedges.
|
|
|
+ \item \label{itm:constraints} There are no port constraints.
|
|
|
+ \item \label{itm:labels} There are no labels.
|
|
|
+ \item \label{itm:cross-hierarchy-edges} There are no cross-hierarchy edges
|
|
|
+ \item \label{itm:multi-layer-edge} No edges over multiple layers (the previous phases should have added dummy nodes).
|
|
|
+ \item \label{itm:connected} Graphs are connected (see below).
|
|
|
+\end{enumerate}
|
|
|
+
|
|
|
+Assumptions~\ref{itm:hyperedges},~\ref{itm:constraints} and~\ref{itm:labels} were made just to make it easier for us by reducing the complexity of the task.
|
|
|
+Assumption~\ref{itm:cross-hierarchy-edges} was made because these are not possible with the Sugiyama approach.
|
|
|
|
|
|
-Regarding the last assumption, we found an example where for a disconnected graph the algorithm behaved incorrectly.
|
|
|
+Regarding assumption~\ref{itm:connected}, we found an example where for a disconnected graph the algorithm behaved incorrectly.
|
|
|
Maybe we will get rid of this assumption later, see chapter~\ref{ch:progress}.
|
|
|
This example is included in the appendix (figures~\ref{fig:error_disconnected_img} and~\ref{fig:error_disconnected}).
|
|
|
|
|
|
@@ -24,6 +27,14 @@ Meanwhile the view displays the same \code{LayeredGraphNode}s and \code{LayeredG
|
|
|
|
|
|
Figure~\ref{fig:components} contains a component diagram that illustrates these dependencies of the different packages.
|
|
|
|
|
|
+Advantages of this architecture include:
|
|
|
+\begin{itemize}
|
|
|
+ \item Modularity, since the class \code{BKNodePlacement} can easily be replaced by other node placement algorithms.
|
|
|
+ Minor changes to the internal data structure might be necessary.
|
|
|
+ \item It is easily possible to open multiple windows for different graphs.
|
|
|
+ This happens already, for example, when loading a graph from a file or when generating a new random graph.
|
|
|
+\end{itemize}
|
|
|
+
|
|
|
\begin{figure}[htp]
|
|
|
\centering
|
|
|
\includegraphics[width=0.8\linewidth,trim=0 1cm 0 0,clip]{img/components.pdf}
|
|
|
@@ -101,9 +112,9 @@ The internal representation of graphs is further explained in the section~\ref{s
|
|
|
The node can be higher if it contains other nodes that need more space.
|
|
|
If the whole layout is too large, it is resized, such that all nodes are proportionately shrunk: In that case the minimum height can be exceeded after the shrinking.
|
|
|
Default 40.\\\hline
|
|
|
- dummy & boolean & yes & Iff this is explicitly set to true, then the node is a dummy node. \\\hline
|
|
|
+ dummy & boolean & yes & Iff this is explicitly set to true, then the node is a dummy node. This attribute is necessary, because we expect previous stages to have eliminated multilayer edges, see section~\ref{sec:assumptions}. \\\hline
|
|
|
layers & < < node > > & yes & The layers of nodes inside this node (Hierarchy). \\\hline
|
|
|
- edges & < edge > & yes & The edges between nodes whose parent node is this node. Also see section~\ref{sec:assumptions}. \\\hline
|
|
|
+ edges & < edge > & yes & The edges between nodes whose parent node is this node. \\\hline
|
|
|
\caption[Node Attributes]{Node Attributes. < \emph{element type} > is a list.}
|
|
|
\label{table:node-attributes}
|
|
|
\end{longtable}
|
|
|
@@ -175,6 +186,8 @@ Similarly, edges have the following attributes in addition to those given throug
|
|
|
\end{itemize}
|
|
|
The last bullet point is available separately for each of the four extremal layouts and for the combined layout.
|
|
|
|
|
|
+The user has to make sure that each graph meets the requirements in section~\ref{sec:assumptions}, we do not check them and wrong usage might result in errors.
|
|
|
+
|
|
|
A class diagram of the package \code{graph} is displayed in figure~\ref{fig:graph}.
|
|
|
There you will find some less important (from a documentation point of view) attributes that were not listed here.
|
|
|
|
|
|
@@ -214,6 +227,7 @@ These stages, however, do not run the algorithm, but instead create lines of pse
|
|
|
More precisely, each \code{PseudoCodeNode} is a line of code that can be displayed and contains a \code{CodeLine} that can be executed.
|
|
|
The \code{PseudoCodeNode}s are arranged hierarchically to form a whole pseudocode tree.
|
|
|
All the stages are displayed in class diagram~\ref{fig:bk} while the different kinds of \code{CodeLine}s are listed in class diagram~\ref{fig:codeline}.
|
|
|
+This separation was made to distinguish viewable \code{PseudoCodeNode}s from executable \code{CodeLine}s.
|
|
|
|
|
|
For the execution of the \code{CodeLine}s a \code{PseudoCodeProcessor} interacts with its own \code{ProcessController} and \code{Memory}.
|
|
|
Note that the \code{ProcessController} is not a controller in the MVC sense that it processes user input, but in the sense that it \emph{controls} the execution of steps/stages.
|
|
|
@@ -254,6 +268,7 @@ A class diagrams for the \code{processor} package is displayed in figure~\ref{fi
|
|
|
\section{View}\label{sec:view}
|
|
|
This section only covers the software architecture regarding the views.
|
|
|
For an explanation of what is actually displayed, see chapter~\ref{ch:ui}
|
|
|
+\TODO{outdated}
|
|
|
|
|
|
\begin{itemize}
|
|
|
\item The main window displays a \code{lane} of the class \code{JLayeredPane} and a \code{menue} of the class \code{JPanel}.
|
