From the first phase of the project you should have code which can build a graph and solve shortest-path problems using Dijkstra's algorithm.
For Part II, the graph nodes represent "events", which are things that occur at a particular point of time. Event nodes have names, as well as attributes such as when the event took place (if known). Events may be dependent on previous events; there is an edge to an event from the events that it is dependent on. Except as noted below, the weights on these edges are 0.
There is assumed to be a unique master START event, on which all other events depend. There is a unique master STOP event, which depends on all other events. (Hint: it may not be necessary to explicitly store edges for all of these dependencies). You can assume that all other events derive from "activities", which are things that take a certain amount of time to accomplish. You can model an activity as two events, its start and stop. The stop event is dependent on the start event. The weight on the edge between start and stop is the time it takes (actually, the time it is estimated to take) to complete the event.
Input representation: Activity and event names are strings without embedded whitespace and will not contain the colon delimter ":". Times and durations are integers.
Input directives are read from a file, and come in two forms:
a activity-name duration
This is interpreted to describe an activity of a given duration. It should be represented in the graph as two event nodes, called activity-name:START and activity-name:STOP, with a weighted edge between them of the given duration. Note the use of the colon as a delimiter between the activity name and the start or stop indication.
d event-name1 event-name2
This is interpreted to mean that event-name2 is dependent on event-name1. As above, event names occuring in this directive will be events derived from activities. (In theory, the special events 'STOP' and 'START' could appear but we don't think this is likely to occur, since these dependencies are assumed, as described above.)
File error handling. If a format error is detected, an error message is given. The directive should be skipped, and processing resumes with the next directive. You can assume that a properly formatted input file will initialize all activities using the 'a' directive before defining their dependencies.
Logical error handling. If the data is illogical (e.g., inconsistent with previously seen data), then give an error message and continue with the next directive. You should detect cycles in the project graph, and issue an appropriate error message, but this may be done in conjunction with the tasks below.
The program should be able to produce the following upon demand, and also after each input directive has been processed: