6.1 Process

For any project you should start as follows:

1. Read all of the documents.
2. Review any source code you've been given so that you understand how the classes you are implementing will be used.
3. Stub-out all of the components (classes, enums, etc.), including all comments. This will make it much easier for you to test and debug your code. (Your stubs should conform to the style guide. This will enable you to correct style defects incrementally, rather than at the last minute.)
4. Think about the order in which you should implement the components and methods. (The specifications documents list the components and methods in alphabetical order. This is unlikely to be the order in which you should implement them.)

As you proceed, you should test one method before you move onto another. This almost always saves time in the end, and never increases the amount of time required. Whether or not you use test driven development (TDD) is up to you.

6.2 Avoiding Code Duplication

As is always the case, your implementation must avoid code duplication wherever it is reasonably possible to do so. So, for example, the parseAddress() method in the Address class must call the fromString() method. As another example, constructors must not contain duplicate code, they must call other constructors.

8.1 Gradescope Grading

Your code must compile (in Gradescope, this will be indicated in the section on “Does your code compile?”) and all class names and method signatures must comply with the specifications (in Gradescope, this will be indicated in the section on “Do your class names, method signatures, etc. comply with the specifications?”) for you to receive any points on this assignment. Gradescope will then grade your submission as follows:

• Conformity to the Style Guide (Style) - 10% (All or Nothing; Success Required)
• Passing your Tests (SelfTests) - 10% (All or Nothing; Success Required)
• Coverage of your Tests (Coverage) - 20% (Partial Credit Possible)
• Correctness of your Code (OfficialTests) - 60% (Partial Credit Possible)

Note that some of the criteria are described as "Success Required". This means that Gradescope will not assess subsequent criteria unless this criterion is satisfied (and you will receive a grade of 0 for the criteria that aren't assessed). So, for example, if your code does not conform to the style guide then nothing else will be assessed (and you will receive a grade of 0 for the assignment).

Note also that, Gradescope will provide you with hints, but may not completely identify the defects in your code.

Finally, as mentioned above, after the 10th submission, your grade will be reduced by 5 points for each submission.

8.2 Manual Grading

After the due date, the Professor may manually review your code. At this time, points may be deducted for inelegant code, inappropriate variable names, bad comments, etc.

10.1 Help with Java

This assignment is a review of the material covered in CS159 that you should already understand. The course "Help" pages (see the section on "Course Content") on Java and UML contain many useful references in case you need to refresh your memory. You also may want to refer to the lectures listed in the syllabus under the heading "Topics to Completely Understand Before the First Meeting".

10.2 Help with Eclipse

If you choose to use Eclipse and are not comfortable with it, you may want to complete the labs listed in the syllabus under the heading "Labs to Complete Before the First Meeting".

Be careful when you create classes in Eclipse that you put them in the appropriate package. Also, when you create your project(s), be careful that you do not put your code in modules.

The JMU CS Wiki on Eclipse explains how to provide an application with command-line arguments.

10.3 Help with Testing

We will be using JUnit all semester. For more information see:

• JMU CS Wiki on JUnit v5
• JUnit User Guide

10.4 Help with Coverage

In order to get 100% coverage, you sometimes have to be aware of some quirks of the language you are working in and the tool set you are using. For more information, see:

• JMU CS Wiki on EclEmma

In order to get 100% coverage, you sometimes also need to change your implementation. For example, you may not be able to test a private or protected method either directly or indirectly. This may be an indication that a public method should be using those methods (e.g., a public constructor using a protected or private setter).

10.5 Help Creating the .zip File

The directories/folders containing the packages must appear at the top of the .zip file. So, you must not compress the directory/folder containing these directories/folders, you must compress the directories/folders containing the packages. In other words, if you have a directory named src that contains the directories government and testing, you must not compress src, you must compress government and testing.

Help with creating .zip files is available on the CS Wiki. In particular, see:

• JMU CS Wiki on Creating .zip Files

As mentioned above, your .zip file must only contain .java files, not .class files. This will be much easier to accomplish if you use Eclipse and, when you create your project, you instruct Eclipse to use separate directories/folders for source and class files.