Seating Chart File I/O

Introduction

During the latest round of code reviews it was discovered that the team responsible for writing the file I/O methods for SitRite3K included proprietary source code copied from a competitor's product. Distributing this code would expose EduCorp to significant legal liability.

You have been assigned the task of performing a "clean-room implementation" of the necessary file I/O methods. In other words, you have been asked to re-implement the file I/O code without being given any access to the tainted code. You will also take this opportunity to make some improvements to the original I/O code: There will be some changes to the file format and you will provide new functionality for saving modified seating charts.

Seating Chart File Format

Under the new file format, configuration files will include three blocks of information. First, the "Size" block will indicate the size and shape of the room. Next, the "Seats" block will describe the location of each student. Finally, the "Friends" block will specify student friendships. The following list of requirements provides a more detailed file specification:

See below for an example of a properly-formatted file. In this example there are four students seated in the front row of an otherwise empty classroom. 

6 6

Jonathan,Melissa,Richard,Kaitlyn,-,-
-,-,-,-,-,-
-,-,-,-,-,-
-,-,-,-,-,-
-,-,-,-,-,-
-,-,-,-,-,-

Jonathan:Melissa,Kaitlyn
Melissa:Richard
Richard:Melissa
Kaitlyn:
small_sparse.sr3

Note the .sr3 extension. These are plain-text files, but we will use this alternate extension to distinguish them from the .txt files used in the previous project.

Modifications to the Student Class

The Student class must conform to the following UML diagram. The only difference between the specification of the Student class for this project and the previous specification is the addition of the toString method, indicated in green.

Detailed Requirements

toString

The toString method must return a String containing the student's name, followed by a colon, followed by a comma separated list of names corresponding to the student's friends. There must be no empty spaces between names, and the string must not be terminated with a newline character. Note that this is exactly the same format as the lines in the Friends block described above.

Modifications to the SeatingChart Class

The updated SeatingChart class must conform to the following UML diagram. The requirements for the existing methods are unchanged from the previous project. New methods are indicated in green.

Detailed Requirements

Constructors

The two new constructors must create a seating chart object from a properly-formatted .sr3 file. The first constructor takes a String containing the path to the file. The second constructor takes a File object. Both constructors must throw a FileNotFoundException if the file cannot be opened for reading.

Both constructors must throw a FileFormatException if the .sr3 file contains errors. See the Submission section below for more details.

FileFormatException is not a standard Java exception type. You must use the implementation provided below.

getStudent(String)

This overloaded version of the getStudent method must return a student based on her name instead of her position in the seating chart. This method should loop through all students in the seating chart until the desired student is found. If there is no matching student, then this method must return null.

toString

The toString method must return a string representation of the seating chart that matches the "Seats" block described above. The example below would be the correct format for a SeatingChart object corresponding to the sample file above. 

Jonathan,Melissa,Richard,Kaitlyn,-,-
-,-,-,-,-,-
-,-,-,-,-,-
-,-,-,-,-,-
-,-,-,-,-,-
-,-,-,-,-,-

toStringVerbose

The toStringVerbose method must return a string that exactly matches the .sr3 file format described above. The order that students are listed in the "Friends" block must match the order that they appear in the "Seats" block.

save

The save methods must save the SeatingChart object as a properly formatted .sr3 file. The first method takes a String containing the path to the file. The second method takes a File object. Both methods must throw a FileNotFoundException if the file cannot be opened for writing. Again, the order that students are listed in the "Friends" block must match the order that they appear in the "Seats" block.

export

The export methods must create a text file with a format matching the "Seats" block described above. The first method takes a String containing the path to the file. The second method takes a File object. Both methods must throw a FileNotFoundException if the file cannot be opened for writing.

Provided Code and Data Files

FileFormatException.java - This is the exception class you should use to signal a badly formed .sr3 file.

SitRite3K_PA2.jar - This JAR file provides a GUI application that may be used to help test your completed code.

Here are a few classroom configuration files that you may use for testing. These represent the same configurations as the files from the previous assignment.

Submitting

This project will involve two separate Web-CAT submissions with the same deadline. Part A will only include tests involving correctly formatted files. Part B will test your code against incorrectly formatted files.

Parts A and B will both include a penalty for excessive Web-CAT submissions. You are allowed 10 submissions total between the two parts. There will be a one point deduction for each submission beyond 10.

Your final submissions for each part must match. In other words you can't use one implementation for Part A, and a separate implementation for Part B.

Part A (80%)

Submit your completed Student.java and SeatingChart.java files through Web-CAT. You do not need to submit FileNotFoundException.java.

Code that fails any of the Web-CAT submission tests will receive at most 50% of the possible credit for part A. This includes both the functionality tests and the Checkstyle tests.

Part B (20%)

The submission tests for part B will involve constructing SeatingChart objects from incorrectly formatted files. It will not be possible to get any credit for Part B unless your code passes all of the submission tests for Part A.

Ideally, your code should throw the correct exception for all possible formatting errors. Minimally, Your code must throw the correct exception in each of the following cases:

Assuming your code passes all of the Checkstyle tests, your base score for Part B will be proportional to the number of submission tests that you pass. Code that fails any Checkstyle tests will receive no more than 50% of the possible credit.