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.

The updated design includes one new utility class that provides some methods for generating formatted strings:

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:

• Size block: The first line will contain two integers, separated by a single space. The first integer represents the number of rows in the seating chart. The second integer represents the number of columns.
• The second line of the file will be blank.
• Seats block:There will then be one line for each row in the seating chart. Each line will contain a comma-separated sequence of names. Empty seats will be represented by a hyphen. Duplicate names are not allowed.
• The seats block will be followed by a single empty line.
• Friends block:There will then be one line for each student in the seating chart. Each line will begin with the name of a particular student, followed by a colon, followed by a comma separated list of names where each name represents one friend of the current student. The order that students are listed in the "Friends" block will match the order that they appear in the "Seats" block when traversing the "Seats" block in row-major order.
• All lines in the file will be terminated with a single newline character ("\n").

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. The .sr3 file extension should be considered a convention, not a requirement. It is not necessary to write code to guarantee that this file extension is used.

SitRiteStringUtils

The SitRiteStringUtils class must conform to the following UML diagram.

Detailed Requirements

studentsToDelimitedString

The four-parameter version studentsToDelimitedString must return a String containing the names from a portion of the provided array. The first name in the String must be the name of the element at offset in the array, String must contain length names, and the String named delim must appear between each pair of names. If an element of the array is null, then a dash must be used in place of the name. It is not necessary to perform any data validation on the values of offset or length.

The two parameter version of the studentsToDelimitedString method must do the same thing, but for all of the elements in the provided array.

Modifications to the Student Class

The Student class must conform to the following UML diagram. The only differences between the specification of the Student class for this project and the previous specification are the additional methods indicated in green.

Detailed Requirements

addFriends

The addFriends method must add an array (possibly of length 0) of Student objects to the owning object's Posse. It must not duplicate code that is in the addFriend method.

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 Posse Class

The updated Posse class must conform to the following UML diagram. The requirements for the existing methods are unchanged from the previous project. One new method is indicated in green.

Detailed Requirements

toString

The toString method must return a comma-delimited list containing the names of all of the Student objects in the Posse.

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 java.io.FileNotFoundException if the file cannot be opened for reading.

Both constructors must throw a java.util.zip.DataFormatException if the .sr3 file contains errors.

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.

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

SitRite3K_PA3.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.

• small.sr3
• small_sparse.sr3
• small_tie.sr3
• pairs.sr3
• easy_cliques.sr3
• hard_cliques.sr3
• challenge.sr3

Submission and Grading

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 for each part. 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

Submit your completed Java files through Web-CAT.

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

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:

• Missing or badly formatted size data.
• Invalid number of rows or columns in the "Size" block. Both must be greater than zero.
• Missing blank lines between blocks.
• Number of rows or columns in the "Seats" block doesn't match the numbers in the "Size" block.
• Duplicate students in the "Seats" block.
• Names in the "Friends" block that do not appear in the "Seats" block.

For full credit, it is not necessary to check that every student in the "Seats" block also appears in the "Friends" block.

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.

Grading

Part A Web-CAT Correctness	50%
Part A Checkstyle	10%
Part B Web-CAT Correctness	20%
Instructor Style Points	20%

---