As outlined in the UI Overview, the Grader Program is comprised of two separate application programs. The student program runs on student's computers and has a limited functionality. It provides functionality to view that student's grades, statistics for the rest of the class, and preform grade prediction by modifying grades and dragging graphs. It retrieves the student's grades by connecting to a central server on which the grade book information is stored. The other application program is for instructors and allows for full access and modification for all student's grades. It provides functionality to add, delete, and modify entire grade books. These changes can then be posted to the server for students to receive.

In both the instructor and student version, the major object in the program is the Gradebook. It's implementation will need to provide efficient access to both its contained Students and Categories. This is because almost every aspect of the grader program will retrieve its data from the Gradebook's Categories and Students. Because of this, it will need to use a fast data structure that supports these various forms of access. For example, it could use a tree structure for the categories, and a list structure for the students.

Aside from the Gradebook, the other objects in the Grader Program should have reasonably straightforward implementations. The different forms of Gradebook viewing (including graphs and statistics) will produce dynamic objects, that need not exist in persistent storage. Rather, the views are computed form the underlying Gradebook data, displayed on user demand, and then discarded. The Gradebook data structure will need to provide access functions to support the different views.

Regarding administrative tasks in the instructor version, the instructor is able to post a Gradebook to the Authentication Server, and also receive a class roster from the Authentication Server. In the student version, students are able to view their classes from the posted Gradebooks on the Authentication Server. The major object here is the Gradebook as it is what the instructor posts and the student recives. The projected size of this Gradebook database is probably not big enough to require implementation using a database management system. Rather, some form of efficiently searchable collection should do.

Creating the Authentication Server will require specific development expertise. In particular, the developers need knowledge of client/server design and implementation. Functionality to support client/server architectures is available in many modern libraries. It will make sense for the developers to choose an implementation language in which client/server support is available, dependable, and well documented.