Goal: The goal of this assignment is to gain practical experience with procedural abstraction - how complex functionality can be broken up between different methods and different classes.
Task Overview: In brief, you will write a method for reading in the sections of a track from a file, and you will write a method for allocating routes to trains (so that they don't collide). More specifically, you must code method read from the TrackReader class and method allocate from the Allocator class that are available in the zip file that accompanies this handout, according to their specifications in those files.
You must complete these methods and classes as if other programmers were, at the same time, implementing classes that use it. Hence:
- Don't change the class names, specifications, or alter the method names, parameter types, return types, exceptions thrown or the packages to which the files belong.
- You are encouraged to use Java 8 SE API classes, but no third party libraries should be used. (It is not necessary, and makes marking hard.)Don't write any code that is operating-system specific (e.g. by hard-coding in newline characters etc.), since we will batch test your code on a Unix machine.
- Any new methods or fields that you add to TrackReader or Allocator must be private (i.e. don't change the specification of these classes.)
- Your source file should be written using ASCII characters only. Implement the classes as if other programmers are going to be using and maintaining them. Hence:
- Your code should follow accepted Java naming conventions, be consistently indented, readable, and use embedded whitespace consistently. Line length should not be over 80 characters. (Hint: if you are using Eclipse you might want to consider getting it to automatically format your code.)
- Any additional methods that you write, and fields that you introduce should be private to hide implementation details and protect invariants.
- Private methods that you write must be commented using preconditions and postconditions (require and ensures clauses). Informal description is OK.
- Fields and local variables (except for-loop variables) should have appropriate comments. Comments should also be used to describe any particularly tricky sections of code. However, you should also strive to make your code understandable without reference to comments; e.g. by choosing sensible method and variable names, and by coding in a straightforward way.
- Any exceptions that are created and thrown should have appropriate messages to help the user understand why the exception was thrown. This is particularly important for the read method in TrackReader, since if there is an error with the file format, then the user will want to know what is wrong with it when a FormatException is thrown. Each FormatException thrown should have a meaningful message that accurately describes the problem with the input file format, including the line of the file where the problem was detected. (You can create a new FormatException with a message using the constructor that takes a string parameter.)
- The methods that you have to write must be decomposed into a clear and not overly complicated solution, using private methods to prevent any individual method from doing too much. I recommend that you attempt to write loop invariants for all non-trivial while-loops in your code, but this is not compulsory. The Zip file for the assignment also includes some other code that you will need to compile your classes as well as some junit4 test classes to help you get started with testing your code. Do not modify any of the files in package railway other than TrackReader and Allocator, since we will test your code using our original versions of these other files. Do not add any new files that your code for these classes depends upon, since you won't submit them and we won't be testing your code using them. The JUnit4 test classes as provided in the package railway.test are not intended to be an exhaustive test for your code. Part of your task will be to expand on these tests to ensure that your code behaves as required by the javadoc comments. (not required to submit your test file TrackReaderTest.java.) We will test your code using our own extensive suite of JUnit test cases. (Once again, this is intended to mirror what happens in real life. You write your code according to the "spec", and test it, and then hand it over to other people ... who test and / or use it in ways that you may not have thought of.)
- More about the allocate method from the Allocator class: In this section we explain some of the terminology used in the specification of the allocate method.
- A route describes a path through a track. A route is a list of zero or more (non-null) segments.
- A segment, implemented as the class Segment from the railway package, is a part of route. A segment is located on one section of track, and it has a direction of travel along that section, and a first and last location that are on that section.
The direction of travel is specified with respect to the end-points of the section: one of the section end-points is designated as the departing end-point and the other as the approaching end-point. The direction of travel is away from the departing end-point towards the approaching end-point.
Let startOffset and endOffset be the offset of the segment's first location and last location (respectively) with respect to the departing end-point of the segment. We must have that startOffset < endOffset. For every offset x satisfying startOffset <= x <= endOffset, the segment of track contains every location at distance x from the segment's departing end-point.
The location at distance startOffset from the departing end-point is referred to as the first location on the segment, the location at distance startOffset+1 from the departing end-point is the second location on the segment, etc. The length of the segment is endOffset - startOffset, and it contains (1 + endOffset - startOffset) locations. Since startOffset < endOffset, this length must be greater than or equal to one.
Attachment:- assignment.zip