Simplifying Activity-on-Edge Graphs

02/05/2020
by   David Eppstein, et al.
University of California, Irvine
0

We formalize the simplification of activity-on-edge graphs used for visualizing project schedules, where the vertices of the graphs represent project milestones, and the edges represent either tasks of the project or timing constraints between milestones. In this framework, a timeline of the project can be constructed as a leveled drawing of the graph, where the levels of the vertices represent the time at which each milestone is scheduled to happen. We focus on the following problem: given an activity-on-edge graph representing a project, find an equivalent activity-on-edge graph (one with the same critical paths) that has the minimum possible number of milestone vertices among all equivalent activity-on-edge graphs. We provide a polynomial-time algorithm for solving this graph minimization problem.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

10/05/2017

Complexity of Edge Monitoring on Some Graph Classes

In this paper, we study the complexity of the edge monitoring problem. A...
02/10/2018

Searching isomorphic graphs

To determine that two given undirected graphs are isomorphic, we constru...
12/04/2021

Quasiplanar graphs, string graphs, and the Erdos-Gallai problem

An r-quasiplanar graph is a graph drawn in the plane with no r pairwise ...
06/30/2019

Connecting edge-colouring

This paper studies the problem of connecting edge-colouring. Given an un...
03/23/2020

A Toroidal Maxwell-Cremona-Delaunay Correspondence

We consider three classes of geodesic embeddings of graphs on Euclidean ...
12/10/2020

Path Optimization Sheaves

Motivated by efforts to incorporate sheaves into networking, we seek to ...
12/24/2018

Cops, robbers, and burning bridges

We consider a variant of Cops and Robbers wherein each edge traversed by...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Figure 1: An activity-on-node graph, above, and its naively expanded activity-on-edge graph, below, with solid arrows as task edges and dashed-dotted arrows as unlabeled edges.

The critical path method is used in project modeling to describe the tasks of a project, along with the dependencies among the tasks; it was originally developed as PERT by the United States Navy in the 1950s [malcolm1959application]. A dependency graph is used to identify bottlenecks, and in particular to find the longest path among a sequence of tasks, where each task has a required length of time to complete (this is known as the critical path).

In this paper we are interested in the problem of visualizing an abstract timeline of the possible critical paths of a given project, represented abstractly as a partially ordered set of tasks, at a point in the project planning at which we do not yet know the time lengths of each task. The most common method of visualizing partially ordered sets, as an activity-on-node graph (a transitively reduced directed acyclic graph with a vertex for each task) is unsuitable for this aim, because it represents each task as a point instead of an object that can extend over a span of time in a timeline. To resolve this issue, we choose to represent each task as an edge in a directed acyclic graph. In this framework, the endpoints of the task edges have a natural interpretation, as the milestones of the project to be scheduled. Additional unlabeled edges do not represent tasks to be performed within the project, but constrain certain pairs of milestones to occur in a certain chronological order. The resulting activity-on-edge graph can then be drawn in standard upward graph drawing style [bt1992area, battista1998graph, gt2001computational, gt1995upward, ahr2010improving]. Alternatively, once the lengths of the tasks are known and the project has been scheduled, this graph can be drawn in leveled style [junger1999level, hkl2004characterization], where the level of each milestone vertex represents the time at which it is scheduled.

It is straightforward to expand an activity-on-node graph into an activity-on-edge graph by expanding each task vertex of the activity-on-node graph into a pair of milestone vertices connected by a task edge, with the starting milestone of each task retaining all of the incoming unlabeled edges of the activity-on-node graph and the ending milestone retaining all of the outgoing edges. It is convenient to add two more milestones at the start and end of the project, connected respectively to all milestones with no incoming edges and from all milestones with no outgoing edges. The size of the resulting activity-on-edge graph is linear in the size of the activity-on-node graph. An example of such a transformation is depicted in Figure 1.

However, the graphs that result from this naive expansion are not minimal. Often, one can merge some pairs of milestones (for instance the ending milestone of one task and the starting milestone of another task) to produce a simpler activity-on-edge graph (such as the one for the same schedule in Figure 2). Despite having fewer milestones, this simpler graph can be equivalent to the original, in the sense that its critical paths (maximal sequences of tasks that belong to a single path in the graph) are the same. By being simpler, this merged graph should aid in the visualization of project schedules. In this paper we formulate and provide a polynomial time algorithm for the problem of optimal simplification of activity-on-edge graphs.

1.1 New Results

Figure 2: A simplification of the graph from Figure 1.

We describe a polynomial-time algorithm which, given an activity-on-edge graph (i.e., a directed acyclic graph with a subset of its edges labeled as tasks), produces a directed acyclic graph that preserves the critical paths of the graph and has the minimum possible number of vertices among all critical-path-preserving graphs for the given input. Our algorithm is agnostic about the weights of the tasks. In more general terms, the resulting graph has the following properties:

  • The task edges in the given graph correspond one-to-one with the task edges in the new graph.

  • The new graph has the same dependency (reachability) relation among task edges as the original graph.

  • The new graph has the same potential critical paths as the original graph.

  • The number of vertices of the graph is minimized among all graphs with the first three properties.

Our algorithm repeatedly applies a set of local reduction rules, each of which either merges a pair of adjacent vertices or removes an unlabeled edge, in arbitrary order. When no rule can be applied, the algorithm outputs the resulting graph.

We devote the rest of this section to related work and then describe the preliminaries in Section 2. We then present the algorithm in Section 3 and show in Section 4 that its output preserves the potential critical paths of the input, and in Section 5 that it has the minimum possible number of vertices. We also show that the output is independent of the order in which the rules are applied. We discuss the running time in Section 6 and conclude with Section 7.

1.2 Related work

Constructing clear and aesthetically pleasing drawings of directed acyclic graphs is an old and well-established task in graph drawing, with many publications [sugiyama1981methods, battista1998graph, bm2001layered, hn2014hierarchical]. The work in this line that is most closely relevant for our work involves upward drawings of unweighted directed acyclic graphs [bt1992area, gt2001computational, gt1995upward, ahr2010improving] or leveled drawings of directed acyclic graphs that have been given a level assignment [junger1999level, hkl2004characterization] (an assignment of a -coordinate to each vertex, for instance representing its height on a timeline).

Although multiple prior publications use activity-on-edge graphs [kulkarni1984compact, cg1986parallel, arh1994nearcritical, hd2011project] and even consider graph drawing methods specialized for these graphs [xu2010automatic], we have been unable to locate prior work on their simplification. This problem is related to a standard computational problem, the construction of the transitive reduction of a directed acyclic graph or equivalently the covering graph of a partially ordered set [agu1972transitive]. We note in addition our prior work on augmenting partially ordered sets with additional elements (preserving the partial order on the given elements) in order to draw the augmented partial order as an upward planar graph with a minimum number of added vertices [es2013confluent].

The PERT method may additionally involve the notion of “float”, in which a given task may be delayed some amount of time (depending on the task) without any effect on the overall time of the project [arditi2006selecting, householder1990owns]. We do not consider constraints of this form in the present work, although the unlabeled edges of our output can in some sense be seen as serving a similar purpose.

2 Preliminaries

We first define an activity-on-edge graph. The graph can be a multigraph to allow tasks that can be completed in parallel to share both a start and end milestone when possible.

Define an activity-on-edge graph (AOE) as a directed acyclic multigraph , where a subset of the edges of , denoted , are labeled as task edges. The labels, denoting tasks, are distinct, and we identify each edge in with its label.

Given an AOE with tasks , for all , let be the start vertex of , and let be the end vertex of .

When the considered graph is clear from context, we omit the subscript and write and . It may be that , or , or with .

To define potential critical paths formally, we introduce the following notation. Given an AOE with tasks , for all , with , say that has a path to in if there exists a path from to , or if , and write .

Given an AOE with tasks , define a potential critical path as a sequence of tasks , where for all , , and where is not a subsequence of any other sequence with this property.

Our algorithm will apply a set of transformation rules to an input AOE of a canonical form. A canonical AOE is an AOE which is naively expanded from an activity-on-node graph.

Every AOE can be transformed into a canonical AOE with the same reachability relation on its tasks. First, we start by computing the reachability relation of the tasks. The transitive closure of the resulting reachability matrix gives an activity-on-node graph (which is quadratic, in the worst case, in the size of the original AOE). Then, this activity-on-node graph can be converted to a canonical AOE as described in Section 1.

Two AOE graphs and are equivalent, i.e. , if and have the same set of tasks—i.e., there is a label-preserving bijection between the task edges of and those of —and, with respect to this bijection, and have the same set of potential critical paths.

An AOE is optimal if minimizes the number of vertices for its equivalence class: i.e., if for every AOE , .

We now formally define our problem.
Problem 1. Given a canonical AOE , find some optimal AOE with .

3 Simplification Rules

Figure 3: On the left, an AOE in which each of rules 1-3 can be applied, and on the right, the corresponding graph output by the algorithm.

Our algorithm takes a canonical AOE and greedily applies a set of rules until no more rules can be applied. Given an AOE and given two distinct vertices , the simplification rules used by our algorithm are:

  1. if and have no outgoing task edges and have precisely the same outgoing neighbors, merge and . Symmetrically, if and have no incoming task edges and have precisely the same incoming neighbors, merge and .

  2. If has an unlabeled edge to , and has another path to , remove the edge .

  3. If has an unlabeled edge to and the following conditions are satisfied, merge and :

    • rule 2 is not applicable to the edge .

    • if has an outgoing task, then has no incoming edge other than .

    • if has an incoming task, then has no outgoing edge other than .

    • every incoming neighbor of has a path to every outgoing neighbor of .

Figure 3 depicts an AOE graph and the graph output by the algorithm after applying all possible rules.

It will be convenient for the proofs in Section 5 to give a name to the output of the algorithm: An output AOE, denoted , is any AOE obtained from a canonical AOE by a sequence of applications of rules 1, 2, and 3, to which none of these rules can still be applied.

4 Correctness

In this section we prove the correctness of our algorithm (its output graph is equivalent to its input graph).

We begin with preserving potential critical paths. We show that the rules never change the existence or nonexistence of a path from one task to another, and that this implies preservation of potential critical paths.

Given two AOEs and with the same set of tasks , and have the same reachability relation on the tasks if and only if .

Proof.

Trivially, we have (or ) if and only if is earlier than in some potential critical path of (or ). Therefore, preservation of critical paths is equivalent to preservation of the reachability relation. ∎

The output of the algorithm is equivalent to its input.

Proof.

We show the invariant that given tasks and , at a given iteration of the algorithm if and only if at the next iteration. From this it follows that the output of the algorithm has the same reachability relation on its tasks as the input, and then the lemma follows from Lemma 4.

The invariant is true because merging a pair of vertices (rules 1 and 3) never disconnects a path, and no edge is ever removed (by rule 2) between two vertices unless another path exists between the two vertices. In particular, the end vertex of still has a path to the start vertex of after the application of any of the rules.

For the other direction, removing an edge never introduces a new path. Furthermore, if vertices and are merged by applying rule 1, and if some vertex has a path to some vertex through the newly merged , then the condition of rule 1 ensures that has a path, through or , to before the merge. Similarly, suppose and are merged by applying rule 3. Then if has a path to through , then (abusing notation) either and before the merge, so (via the edge ), or for some incoming neighbor of and outgoing neighbor of , and . In this case, by the conditions of the rule, before the merge. ∎

[] Any intermediate graph that results from applying rules of the algorithm to an input canonical AOE graph, is acyclic.

Proof.

Given Section 2 and Section 2, the canonical AOE input is acyclic. Now we show none of the rules can create a cycle after being applied to an intermediate acyclic graph . This is obvious for rule 2 as it removes edges. Suppose for a contradiction that merging vertices and creates a cycle. The cycle must involve the new vertex resulting from the merge. For rule 1, this implies the existence of a cycle in either from or to itself which is a contradiction. For rule 3, it implies the existence of a cycle in including the unlabeled edge or a cycle including an incoming neighbor of and an outgoing neighbor of , which is a contradiction. ∎

Any graph output by the algorithm is acyclic.

5 Optimality

In this section we prove the optimality of our algorithm: it uses as few vertices as possible. Let be any output AOE. Let Opt be any optimal AOE such that . Our proof relies on an injective mapping from the vertices of to the vertices of Opt. The existence of this mapping shows that has at most as many vertices as Opt, and therefore has the optimal number of vertices. Once we have identified the vertices of with the vertices of Opt in this way, we show that, for a given input, any two graphs output by the algorithm (but not necessarily Opt) must have the same unlabeled edges. Since the task edges are determined, and since the injective mapping to Opt determines the vertices, determining the unlabeled edges implies the order-independence of our algorithm’s choice of simplification rules.

Before defining the mapping between and Opt, we establish some facts about the structure of .

For every unlabeled edge in any output AOE , there exist tasks and such that and .

Proof.

By Definition 3, is produced by the algorithm from some canonical AOE . This property holds for by Section 2. As every rule of the algorithm either removes an unlabeled edge or merges two vertices, and never creates a new edge or vertex, the proof is complete. ∎

Every vertex in an output AOE has an incident task edge.

We can now define a mapping from the vertices of to those of Opt:

Given an output AOE with task set , and given an optimal AOE Opt with , let be the following mapping: for every :

  • Let , for some for which , if such a task exists.

  • Let , where , otherwise.

As shown in Section 5, every vertex in has an incident task edge, and by Definition 2, and Opt have the same set of tasks. Therefore, this mapping is well-defined (up to its arbitrary choices of which task to use for each ). To prove that is injective, we will use the fact that since , and Opt have the same reachability relation (by Section 4 and Section 4).

The heart of the proof that is injective lies in showing that if two tasks do not share a vertex in , the corresponding tasks also do not share the corresponding vertices in Opt. From this it follows that cannot map distinct vertices in to the same vertex in Opt.

Given an output AOE , and an optimal AOE , with task set , let and be two distinct tasks in . If , then . If , then .

Proof.

Suppose for a contradiction that , but (the other case is symmetrical). Let and . Consider the following (exhaustive) cases for and :

  1. and have no incoming edges

  2. or has an incoming unlabeled edge, but neither nor has an incoming task edge

  3. or has an incoming task edge

In case 1, applying rule 1 results in merging and . However, since is the output of the algorithm, no rule can be applied to . This is a contradiction.

In case 2, and cannot have the same incoming neighbors or else rule 1 would apply. We may assume without loss of generality that there exist a vertex and an unlabeled edge , such that the edge does not exist. By Section 5, there exists a task where . Since and (by Lemma 4), then by Lemma 4, , so , since . Again by Lemma 4, , so there is a path from to . If , then this contradicts that does not exist. Suppose . Then we show there exist some vertex and an unlabeled edge . The following cases are exhaustive:

  1. contains a path from to . As such a path to exists and has no incoming task edge, there exist a vertex and an unlabeled edge (), not belonging to unless rule 3 can be applied to vertex and its incoming neighbor in path .

  2. does not contain a path from to . As , an unlabeled edge belonging to path exists.

Given the existence of , by Section 5, there exists a task where . , so by reasoning similar to the above, . Then, one can apply rule 2 and either remove edge in case a or in case b (Figure 5); this contradicts the definition of .

In case 3, we can assume without loss of generality that has an incoming task ; consequently, . Then, by Lemma 4, we have and thus via a path . Consider the following cases for :

  1. contains a task edge

  2. is a sequence of unlabeled edges

In case a, by Lemma 4 , and thus , and therefore . This creates a cycle between and , contradicting Section 4.

In case b, illustrated in  Figure 5, since rule 3 cannot be applied (if it could, this would contradict the definition of ), there exist a vertex not on the path from to , and an edge (a task edge or an unlabeled edge). Therefore, there exists a task where either or by Section 5, . Considering Opt and applying Section 4, so . This path either creates a cycle in or allows for removing edge by rule 2, which is a contradiction.

Thus if , then .

Figure 4: Section 5, case 2, subcase b (double arrows indicate paths).
Figure 5: Section 5, case 3, subcase b.
Figure 4: Section 5, case 2, subcase b (double arrows indicate paths).

[]

Given an output AOE , and an optimal AOE , with task set , let and be two distinct tasks in . If , then .

Proof.

The proof, which is in Appendix A.1, uses essentially the same approach as the proof of Lemma 5: supposing that the two vertices are the same, then using the fact that and Opt have the same reachability relation on their tasks, and the definition of as having no more rules to apply, to derive a contradiction.

There is one remaining technicality: we have defined an optimal AOE as being acyclic; the question arises whether one could reduce the number of vertices by allowing (unlabeled) cycles. However, this is not the case; it is easy to see that any unlabeled cycle can be merged into one vertex, reducing the number of vertices, without changing the reachability relation on the tasks.

We are ready to prove our main results. Given a canonical AOE , the algorithm produces an optimal AOE .

Proof.

Let be the output AOE produced by the algorithm on . Given any optimal AOE Opt and , the mapping in Section 5 is injective: suppose for a contradiction that and are distinct vertices in , and . Then by the definition of , either , , and have the same incoming task, or , , and have the same outgoing task, or there exist tasks and such that (without loss of generality) , and . By Lemmas 5 and 5, all three of these cases imply that .

Therefore, . Furthermore, , by Lemma 4. The theorem follows. ∎

Given an input, the algorithm produces the same output regardless of the order in which the rules are applied.

Proof.

As stated earlier, all task edges of an input canonical AOE are present in any output of the algorithm and the mapping determines the vertices. Therefore, it suffices to show that any two graphs output by the algorithm have the same set of unlabeled edges. Suppose for a contradiction that and are two distinct outputs of the algorithm, resulting from applying different sequences of rules. By Section 5, the algorithm always produces an optimal AOE. Therefore, . Since , there is an unlabeled edge in (without loss of generality) that is not in . By Section 5, there exist task edges and such that and . We have . Since by Section 4 and Section 4, and both preserve the reachability relation of the tasks of , we have . Consider the cases for path from to in :

  1. There exists a task in other than and .

  2. Path is a sequence of unlabeled edges.

In case 1, we have and therefore, . Then by rule 2, one can remove the edge , which contradicts the definition of .

In case 2, the length of is at least two, and contains a vertex . By Section 5, there exist tasks and where . Now, since , both graphs are optimal, and both graphs are outputs of the algorithm, Lemma 5 implies that . Call this vertex . Then there exists a path from to , through , by Lemma 4, and one can remove the edge by rule 2. This contradicts the definition of . ∎

6 Analysis

Let be the number of vertices in a canonical AOE (which is linear in the number of tasks), and the number of unlabeled edges. There are at most iterations in the algorithm, because each iteration either merges two vertices or removes an edge, by applying one of the three rules. This requires finding an edge to remove ( potential edges) or two vertices to merge ( potential pairs), then performing the merge or the removal. Intuitively, our algorithm runs in polynomial time as it takes polynomial time to find and apply a rule.

We provide a faster implementation of our algorithm than the naive approach. The algorithm transforms a canonical AOE graph into an optimal AOE graph by applying rules 1, 2 or 3. For simplicity, we label the vertices . At each iteration, compute a reachability matrix for the current graph. indicates whether there exist zero, one, or more than one paths from to . In order to compute , for all and initialize if the edge exists. Then sort the vertices in topological order (such an ordering exists according to Section 4). For each vertex in this order, and for each vertex , set to , where is the set of all vertices such that either or there exists an edge . This procedure takes time. Algorithm 1 provides a summary.

Data: Canonical AOE
Result: Optimal AOE Opt
1 while true do
2       Initialize and compute the reachability matrix ;
3       Remove, by rule 2, all unlabeled edges where ;
4       if rule 1 applies then
5             apply rule 1;
6            
7       else if rule 3 applies then
8             apply rule 3;
9            
10       else
11             return the graph;
12            
13      
Algorithm 1 the proposed transformation algorithm.

Given the reachability matrix, an unlabeled edge is removed by rule 2 in time, if . Therefore, checking rule 2 for all edges takes time.

Without loss of generality, for rule 1, we only consider merges of pairs of vertices with the same outgoing neighbors. This requires, for each vertex with no outgoing task edge, a sorted list of outgoing neighbors (S). To obtain such lists for all vertices, list unlabeled edges as pairs of vertices and sort all the pairs with two bucket sorts: first over the first elements of the pairs, then over the second elements. Breaking the sorted list into chunks of pairs with the same first element (say ), gives the outgoing neighbors of , in the second elements of the pairs, in a numerically sorted order. This takes time. Then find pairs of vertices to merge, if any exist: first, bucket sort vertices based on their out-degree. Vertices in different buckets cannot be merged by rule 1. For each bucket containing vertices with degree (), call MergeDetection:

14 Function MergeDetection(bucket ):
15       if  then
16            return bucket
17      else
18            bucket sort vertices of based on S foreach newly created bucket  do
19                   MergeDetection()
20            
21      

The vertices in each resulting bucket have the same outgoing neighbors and can be merged by rule 1. As each vertex with degree appears in one bucket in each of iterations, this sort takes time. Upon merging vertices and , name the new vertex min.

To check rule 3, for each vertex , compute : the intersection of the reachable sets of the incoming neighbors of . This takes time. Consider only those unlabeled edges that meet the preconditions of rule 3 concerning the existence of outgoing and incoming tasks of and respectively. Test whether the last point in rule 3 applies to edge by testing in time whether all outgoing neighbors of are in .

Computing the reachability matrix takes time, and using this matrix to check for rule 2 takes time per iteration. Checking for rule 1 or 3 takes time per iteration. Further, the outer loop in Algorithm 1 runs at most times as it either merges two vertices or returns the output. This gives a total complexity of for our algorithm.

7 Conclusion

Our algorithm reduces the visual complexity of an activity-on-edge graph, making it easier to understand bottlenecks in a project. The algorithm repeatedly applies simple rules and therefore can be implemented easily. However, one can measure the complexity of a graph in other ways. One question for future work is whether one can minimize the number of edges in an AOE graph in polynomial time. Another question is whether one can, in polynomial time, convert an AOE graph into a graph that (i) has the same critical paths as , and (ii) has a plane drawing with fewer edge crossings than all other graphs satisfying (i).

References

Appendix A Appendix

a.1 Proof of Section 5

See 5

Proof.

Suppose for a contradiction that , but . Since , then by Lemma 4, , so has a path to . Consider the following possible cases for path :

  1. There exists a task in .

  2. only consists of unlabeled edges. Consider the cases for any unlabeled edge in :

    1. There exist incident tasks and , pointing away from and toward and , respectively.

    2. There exists an incident unlabeled edge pointing away from and an incident task pointing toward .

    3. There exists an incident task pointing away from and an incident unlabeled edge pointing toward .

    4. There exists an incident unlabeled edge pointing away from and an incident unlabeled edge pointing toward . Vertices and have no outgoing or incoming task edges, respectively.

These cases are exhaustive as path either has a task or it is a sequence of unlabeled edges. Further, for case 2, suppose for an unlabeled edge , none of the subcases of 2a, 2b, 2c and 2d holds. Then, by rule 3, one can merge vertices and ; this contradicts the definition of .

Figure 6: Section 5, case 1.
Figure 7: Section 5, case 2a.
Figure 6: Section 5, case 1.
Figure 8: Section 5, case 2b.
Figure 9: Section 5, case 2d.
Figure 8: Section 5, case 2b.

In case 1, shown in Figure 7, we have so by Section 4, . Therefore, there is a path in Opt (through ) from to . Since , this path creates a cycle in Opt. However, Opt is an AOE graph and is therefore acyclic by Section 2.

In case 2a, shown in Figure 7, , so by Section 4, , i.e. there is a path from to . Similarly, , so there is a path from to . Since , this implies , so by Section 4, . Therefore, there is a path in from to . This path creates a cycle in and contradicts Section 4.

In case 2b, shown in Figure 9, by Section 5, there exists a task where . Since we have and and , by Section 4, we have . Therefore, there is a path in from to . This path either creates a cycle between and , contradicting Section 4 or by rule 2, one can remove edge , which is a contradiction by the definition of .

Case 2c is almost identical to case 2b, and again leads to the existence of a path from to (similarly defined), resulting in either a cycle or an application of rule 2 .

In case 2d, shown in Figure 9, by Section 5, there exist task edges and where and , and unlabeled edges and . We have , then by Section 4, . Therefore, there is a path in from to . This path either creates a cycle between and , contradicting Section 4 or by rule 3, one can merge and in , which is a contradiction by the definition of .

Thus if , then .