Originally, I started out with a pretty simplistic idea. I planned on running various tests against the submission and indicate if points should be awarded for each verification (a grade item). It was loosely based on the idea of being a unit test framework with points. There was a very vague concept of relating tests to each other by way of a string in each grade item called the test suite.

This has a few primary issues:

• There is no real sense of aggregation of the grade items. I had a way to assign a “test suite” name to them, but that wasn’t sufficient.
• There is no way of saying “this is the total amount of points for the project”. I didn’t want to put grader developers in a position of declaring that there was 150 possible points and then making sure the grade items summed to that total. Instead, I calculate the total as the grade items are added to the project’s grade. I stand by this approach, but it has a bitch of a flaw: if there is an unexpected error from the student’s submission (as students, it’s understandable that this is a pretty common occurrence) and the grade items are not added, that project has a lower total grade than the rest.
• The grader developer has to implement one method (grade()) as the hook into CodeTurtle. That means any protection against the above scenario must be provided in the grader itself. This led to a lot of try/catch blocks as the grader’s grade() method called out to smaller grade methods.

After some time at my whiteboard, I came up with the following changes.

• The model now goes: a project grader has one or more grade test methods, each of which has one or more grade assertions. The idea of an aggregation of grade assertions is now a first-class concept.
• Each grade test method is run by CodeTurtle independently of each other, preventing an unexpected error in one from stopping the execution of the others.
• The domain model has been changed to reflect this, allowing an unexpected error in a grade test to be captured and indicated at the test level (as compared to simply a failed assertion).
• Grade tests are indicated through the @GradeTest annotation. It takes a name parameter that is the display name used on the report.
• Additionally, @Setup and @Teardown annotations indicate methods that should be run at the start and end of running all of the tests (yes, this looks very much like JUnit, it’s intentional).
• All project graders must extend the ProjectGrader base class, which provides (among other things) the all important register() method (more on that later).

The most important change is how grade assertions are created. At the start of each grade test, the register() method should be run for each assertion that will take place over the course of that test. The register method returns a GradeAssertion object that can be used later in the method to indicate the success/failure of each assertion (through the new correct() and incorrect(String result) methods respectively).

This was a big change as it allows me to dynamically calculate the total number of points instead of requiring the grader developer to manually add up the total points, but with a much greater degree of safety than previously offered. Making these calls to register at the outset of a test method guarantees that any unexpected exception that occurs will still result in a correct total. Capturing the unexpected exception and associating it with the test itself provides an explanation of why some assertions may not have been run.

To add some concreteness to this, here’s a quick example of what a grader might look like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

public class CalcGrader extends ProjectGrader {
 
  @GraderTest(name = "Add Test")
  public void add() {
    GradeAssertion twoNums = register(5,
      "Adds two numbers correctly");
    GradeAssertion nullNums = register(5,
      "Handles null parameter");
 
    // Setup to get to student's add method
    int result = add(2, 3);
    if (result == 5) {
      twoNums.correct();
    } else {
      twoNums.incorrect("Adding [2, 3] failed. Expected [5]," + 
      "Found [" + result + "]");
    }
 
    try {
      add(null, null);
      nullNums.incorrect(
        "Null parameters did not cause exception");
    } catch (IllegalArgumentException e) {
      nullNums.correct();
    }
}

It’s a bitch changing a domain model (in this case, adding a layer for GradeTest in between Grade and GradeAssertion). I think I got everything hashed out, short of a few variables that may still carry the old naming (GradeItem became GradeAssertion). So far, so good, as grading project 3 was significantly easier and cleaner than it was when I started it on the old model. There are still a few more projects in the semester, so I’ll have a few more chances to see how this stands up before actually declaring CodeTurtle “1.0″.

In short, an enum is a collection of constant values. They provide a simple way of limiting the options you can use for a variable if there are only a standard, or in other words enumerated, set of values it can be.

For instance, imagine if you were modeling a deck of cards. Each card would be one of 4 possible suits: clubs, diamonds, spades, or hearts. One option is to store the suit in a string variable, however this is cumbersome for two reasons:

• There has to be careful validation in the setter for the suit to ensure only the four possible suits are allowed, taking into account the capitalization of the string.
• If you needed to do different handling based on the suit, if/elses would have to be used; a switch statement cannot be used on strings.

Instead of using a string to track the suit, an enum is a good candidate. An enum is defined just like a class except using the enum keyword instead of class. Also like a class, an enum is typically defined in its own file of the same name.

1
2
3

public enum Suit {
    HEARTS, CLUBS, SPADES, DIAMONDS
}

A simple enum, which is usually sufficient, just lists the possible values. Since these values are effectively constant, the convention is the same as for final variables (all caps).

Using an enum is the same as any other object:

1
2
3
4
5
6
7
8
9
10
11

public class Card {
    private Suit suit;
 
    public Suit getSuit() {
        return suit;
    }
 
    public void setSuit(Suit s) {
        suit = s;
    }
}

When attempting to set a suit on a card, the compiler will only allow one of the four values defined in the enum, so there is no need to add validation in the setter. The value is accessed by using the enum name and the value name, similar to calling a static method or variable:

1
2

Card card = new Card();
card.setSuit(Suit.DIAMONDS);

If for some reason, we needed to do different handling based on suit (not an overly applicable scenario in this use case, but often a common usage of enums), enums are supported in switch statements:

1
2
3
4
5
6
7
8

switch (myVariable) {
    case Suit.HEARTS:
        // do hearts processing
        break;
    case Suit.CLUBS:
        // do clubs processing
        break;
}

Keep in mind that an enum can also take on other properties of a class. Instance variables and methods can still be defined in the enum. Since the only creation of enum values are done inside of the enum itself, any instance variables must be initialized in the constructor. For example, assume we wanted a display name for each suit. The following changes would support this addition:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public enum Suit {
    HEARTS("Hearts"),
    DIAMONDS("Diamonds"),
    CLUBS("Clubs),
    SPADES("Spades");
 
    private String name;
 
    private Suit(String n) {
        name = n;
    }
 
    public String getName() {
        return name;
    }
}

Given the above changes, the public methods can be called on the enum values as if they were any other object::

1

System.out.println(Suit.HEARTS.getName());

For another example, check out the enum for each column in the grades table in CodeTurtle.

The attached code is released under the GNU General Public License.

Click here to download the source.

This code sample demonstrates a few different possibilities for working with dialog boxes. When running the application, a simple frame will appear with a button for each example. Pressing the button will result in its corresponding dialog box being displayed. In certain cases, logging information will be written to standard output to reflect the user’s interaction with a dialog box.

The attached code is released under the GNU General Public License.

Click here to download the source.

Be sure to take a look at the code as this sample is intended as a reference or tutorial. A number of configuration settings for each component are indicated in the code itself. Feel free to play around with these settings to see their effects on the UI.

The main layout of the components uses a GridBagLayout. A full description of how to use GridBagLayout is outside the scope of this sample. There is still value in looking over its use, however the in code documentation on its usage is intentionally admitted for now. I’ll probably do a specific sample dedicated to GridBagLayout and its usage.

The attached code is released under the GNU General Public License.

Click here to download the source.

Named inner classes are defined just like any other class, however they are defined inside of another class (this is compared to anonymous inner classes that are defined at object instantiation time). There are specific rules on where and how they can be accessed outside of the class that are outside of the scope of this post.

One benefit to named inner classes is that they can be instantiated more than once, as compared to the single instantiation of anonymous inner classes. Additionally, as named inner classes function just like other classes, they can implement more than one interface. This code sample demonstrates using one implementation to function as multiple listener types.

The attached code is released under the GNU General Public License.

Click here to download the source.

Anonymous inner classes are called as such because they do not have a name. They are instantiated at the same time the class is defined. The code in this sample includes comments describing the syntax of how these types of inner classes are defined, so be sure to look at the source in addition to compiling and running the application.

Going forward, I’m going to post another sample of this application, ported to use named inner classes for the implementation instead of anonymous inner classes.

The attached code is released under the GNU General Public License.

Click here to download the source.