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.