Architecture

The overall architecture of our project is split into modules which are independent and have their own responsibilities. They interact with each other to run the full program, which consists of taking the command line inputs and the task graph to running a scheduling algorithm and giving the user an output file. More information about how each module is implemented is on found in on their own respective pages.

Modules

• The CLI module is responsible for parsing the arguments and flags set by the user when running the app from the command line. It creates a CLIConfig object which stores information about the input, such as the input filename, the number of processors to schedule on and whether to show the visualisation.

• The input parsing module takes in the graph .DOT file representing the tasks to be scheduled and builds a graph object to be used in the algorithm.

• The algorithm module contains different algorithms that can be used to schedule the tasks. Algorithms all implement SchedulingAlgorithm, which contains a method calculateOptimal() for the graph to return a valid (and hopefully optimal) schedule. This method takes in a SchedulingContext object which contains the graph object as well as the number of processors to schedule on. Related to this are solution spaces which the algorithms run on. We have refactored so that solution spaces are independent of algorithm, however the important one is allocation ordering which is to be used.

• The output generation module takes the output of a SchedulingAlgorithm and creates the .DOT output file to give back to the user.

• The visualisation module takes in information about the algorithm while it is running to provide visual feedback to the user.

• There is also a bench-marking module which is used to test algorithms and their performance against test graphs.