Design Decisions and Development Findings

Design Decisions

Reading Input File

• Created a InputFileReader class to parse the relevant node and edge information from the .dot file into their respective objects
• Adds each node/task into a Queue, and each edge into a ArrayList
• Every time an edge is added, we reference the relevant nodes that edge is attached to. This allows for greater flexibility as we can see what all the outgoing or incoming edges from Node A are.
• Regex is the main form of parsing and separating unwanted information.

Output File

• Line as an inner class because no other class is ever gonna use it, more logical to embed the 'helper class'. It also increases encapsulation. It is a private class, other classes do not worry about it and can not modify it.
• Line class handles what is to be printed to each line. Holds pointers to other classes where information needs to be printed from.
• Also because different lines have different data types, need a class to handle the logic rather than overloading several methods.
• Originally thought that ordering was to be the same as the input file, so a list of line information is stored, used to print to order.

Node and Edge Classes

• Created these objects to represent tasks to be scheduled.
• Didn't include start and end times for nodes as the Processor concerns these.

These two classes were eventually removed and replaced with HashMaps and int arrays to increase performance/reduce memory usage.

Greedy Algorithm

• Used a greedy algorithm as Milestone 1 required a valid schedule, not an optimal schedule
• Easier to conceptually understand while solidifying our understanding of parallelisation

Ordering of Nodes

• We decided to take into consideration if the input file was unordered
• This means taking into account if the first node in the .dot input file was not the root of the tree
• When designing our solution, we drew out all the examples of the .dot input files and their associated trees
• Found that when scheduling, we needed to consider if a task was dependent on another task being scheduled
• Led us to create helper methods such as addToSchedule within the input reader to create a list of tasks to be scheduled in order so no dependencies would be violated
• Decided to use an arrayList over a Queue as this allows us to access tasks more quickly (O(1) vs O(n))
• Lists and arrayLists also have more functionality in Java (can iterate through more easily)

Processors

• Design decision to create own Processor class that represents one Processor
• Abstracted from all other classes to keep it loosely coupled
• Encapsulates start and end times into two Hashmaps. We weighed the advantages and disadvantages of having either one Hashmap with an array, or separate hashmaps. Decided that two hashmaps has better abstraction and ease of access although less compact, more readable.
• AddToSchedule method considers communication costs and ensures that the node is scheduled AFTER the last scheduled parent + communication costs
• Individual Processor object encapsulates all the logic that a single processor needs to schedule an incoming node (handled by Scheduling, this is where I'll pass over to Hong)

Scheduling

• Implemented using a Greedy Algorithm
• Algorithm schedules nodes onto each processor according to the finishing times of the processors -> EARLIEST FINISHING COST OF PROCESSORS
• Scheduling follows the user input of <NUMBER-OF-PROCESSORS> to create <NUMBER-OF-PROCESSORS> Processor objects for the algorithm
• Comparators were used to customise the sorting options i.e processor end times
• Scheduling encapsulates the overall logic of reading inputs, choosing a processor and calling Processors to do the logic
• Processors know about schedules however schedules do not have any information about processors, therefore, making it more modular

Command Line

• Used Google-Options library
• Set Options (help, output file, cores, visualisation) in a new CommandLineArguments class that implements the OptionsBase class.
  • Allowed us to add options using annotations (@Option), along with a field that stores the value of the option when entered on the command line.
• CommandLineArguments class was used in the CommandLineParser class by an OptionsParser (from the library) object.
  • OptionsParser then takes the user's input (as an array of Strings), and parses into the fields specified in the CommandLineArguments that we made.
  • The fields were then referenced later in the code, namely the output file name (the cores and visualisation options are yet to be implemented).

Development Findings

Code Quality

• Including coding standards, comments, documentation, testing
• When writing methods, write Javadoc comments about the method to ensure other team members have clear understanding of code
• Ideally, want self commenting code but use in-line commenting where some areas are unclear (don't want redundant comments)
• Testing was done on a variety of machines across the team: Windows and Linux

Project Management Performance

• Difficult to keep track of messages/status of tasks in Facebook Messenger

• Aiming to utilise Github Project Board more to keep track of bugs and PRs

• Accidentally taking over other's tasks and scope creeping due to lack of clear definitions of tasks and expectations

• Aiming to improve clear communication by updating Issues and Project Board more frequently

Compliance with Waterfall Model Development Process

• Our feedback for our Project Plan was we did not include an essential part of the Waterfall Model: Design phase
• This was left out by mistake, however, we created a detailed design of our objects and algorithm before implementing
• With this development process, we were inclined to make tests beforehand (based on the best practice of TDD)

Github

• Difficulty adjusting to using Github as a central portal for software development tools e.g. Using the Issues tracker, Project Board to update team members about new bugs and tasks to be done

Unexpected Findings