4. Developer Overview

The objects and operations discussed in this summary can be referenced in the data dictionary in Section 5.

The Test Tool project has been specified as a program with four main categories of use. These four categories are question creation and management, test generation, test taking, and grading. The four programs use objects related by inheritance which logically follows the progression of data through the program. From the highest level, this can be described as (1) questions are created and then (2) get put into a test that then (3) gets taken by a user and finally (4) is graded. Through the development of this requirements document, we have seen that each of these steps uses all of the data from the previous way. From that pattern, our objects in grading inherit from our objects in test taking which inherit from test generation which inherit from question management/creation. One concrete example is the hierarchy of questions in Test Tool: GradedQuestion extends AnsweredQuestion extends TestQuestion extends Question.

The question creation and management interface, for the most part, should be very straightforward to implement. The one component to consider for careful implementation is the filtering capabilities of the program. We believe that the use of several different booleans and the use of parenthesis for grouping will be the complicating factors of the filtering algorithm. In terms of object modeling, the Question has been modeled to only directly include elements common to all question types. For the components specific to a given question type, a separate object inheriting from Prompt is referenced by the Question object.

The test generation section we developed uses a test with multiple sections, each having an associated filter on the questions in the databases which have been selected for the test. In order to separate the user's requirements for a test from the actually generated test, our GenerationSession contains both a GeneratedTest with GeneratedSection objects as well as a corresponding SectionCriteria object for each GeneratedSection. Implementation of this section will require much attention to detail and coordinating data and logic from several different sources. The specification team believes that the AutoGenerateSection operation will be among the most difficult parts of the program to implement. This can be attributed, as explained briefly above, to the amount of options the user has to specify how they would like their test to be generated.

The test taking interface must be implemented to be conscious of a student's needs during a test. Carefully implementing these features using our specification should ensure a smooth test taking experience for the user.

The grading portion of the software should be sure to follow two of our main specifications: 1) anonymity of students while the exams are being graded; 2) the grader is given an intuitive blend of manual and automatic grading tools that helps them quickly and without undue clicking and typing grade the test.


Prev: non-functional | Next: specification | Up: index | Top: index