Uses of Directed Edge Constraints

Figure: A screenshot from Dunnart showing the context menu that allows user to manipulate connectors that translate into graph edges. Note the option allowing the user to remove the directed edge constraint.

r250pt

Below are a few examples showing the application of directed edge constraints. All images were drawn in Dunnart. Using Dunnart, the graphs were created by dragging shapes onto the canvas and creating connections between the shapes. The tool converted the diagram to a graph data structure and using the cyclic detection algorithm presented in Fig , highlighted all cyclic edges in purple. In order to properly deal with directed cycles, Dunnart used both the No Cycle Constraints and the Acyclic Subgraph techniques. For the Acyclic Subgraph approach, the user can use an implementation of the maximum acyclic subgraph algorithm to determine the edge not to have a directed edge constraint. If the user needs to maintain a higher level of control over the layout, a context menu^6.1 allows the user to place or remove directed edge constraints for vertices $(u, v)$ that are connected by the user selected edge. To highlight the fact that an edge did not have a directed edge constraint, the edge is highlighted in red. When the layout algorithm was applied, Dunnart generated directed edge constraints for the vertices whose edges did not have the constraints removed. In the images shown, all the cyclic edges are shown in purple dashed edges, all cyclic edges that do not have a directed edge constraint on them are in dotted red, and acyclic edges are solid black edges.

Figure: () contains a `hand drawn' graph showing nodes in a network and the connections between those nodes. () and () are the same graph from Fig. , but laid out with directed edge constraints to show potential flow of data through the network, to visualise the network under certain conditions. () shows what the layout could look like using the No Cycle Constraints approach

[] [] []
[]

Figure: () shows a simplified version of a diagram visualising an architecture proposed in [2] with original layout preserved. () shows the same diagram, with directed edge constraints and a users choice of which edge(s) not to have directed edge constraints on. () is more informative because it is quick and easy to see the flow of data through the architecture, how the data is processed as it progresses through the processes, and how the output of the entire process can be used as subsequent input for later processing.

[] []

Figure: A very simple graph showing a flowchart of some generic syntax. () shows one layout using a combination of directed edge constraints that lays out the components of the loops in a manner that clearly shows the order of loop execution. () is a layout that shows the order of execution for statements, based on the result of passing or failing certain conditionals in the graph. Allowing the user to have control over the choice of which edges not to have directed edge constraints, allows the user to highlight certain paths through the graph.

[] []

Figure: () is a hand drawn Deterministic Finite Automata. () is the same DFA laid out with directed edge constraints. By placing the START node of the DFA at the top, the layout in Fig. could be argued to be a better layout as is shows a better progression from the START state to the END states. () is the same DFA from Fig., but with some user adjustment to compact the DFA, in order to make it shallower thus improving on the layout in Fig.. However given that the convention for DFA is to draw them left to right, the layout in () may be better. An extension to the directed edge constraint interface could be to allow the user to specify which direction they want the directed edges to face, thus being able to achieve a layout similar to ().

[]
[] []