Diagram Generation Algorithm

Diagram Generation Algorithm

Overview

When I was first shown an arrow diagram I did not understand what was I looking at. I took it as a node diagram and couldn't figure out what was it about. After learning more about arrow diagrams and building a few manually I eventually faced the complexity of building large arrow diagrams.

Although, admittedly, creating node diagrams of the same project was less complex, the result was confusing and convoluted. Still, my starting point for this algorithm is the node diagram for the activity list.

The reason for that is that after many hours thinking about the problem I have a somewhat clear mapping between the two in my head and I can see how they are equivalent. For each upside of an arrow diagram you can find a downside in the node diagram and vice-versa. It just so happens, that for representing projects, arrow diagrams turn out clearer.

The Algorithm

Input

The input to the algorithm is a list of activity IDs and for each activity, also the list of predecessor IDs. For visualization purposes, each activity has some metadata like its duration and total slack.

For the purpose of this explanation, I will work on the following toy project data:

• Activity 1
• Activity 2 - Predecessors 1
• Activity 3 - Predecessors 1
• Activity 4 - Predecessors 1
• Activity 5 - Predecessors 2, 3
• Activity 6 - Predecessors 1, 5, 4
• Activity 7 - Predecessors 5, 6

Creating a Node Diagram

Converting this list to a node diagram is a straight forward operation. Each activity gets a node, each dependency gets an edge from the predecessor to the activity.

It is expected that for a valid project there would be a single node which has no in-edges and a single node which has no out-edges.

Here is how such a diagram would look like: