4. Developer Overview

As outlined in the UI Overview, the Grader tool consists of three user interfaces: Instructor, Student, and TA. These three interfaces will need to be implemented with significant overlap. The Student view will include a unique grade spreadsheet that has not been modeled in the specification. In addition, the Student and TA views will need to omit certain menubar items and functionality(Students all have the same permissions, but the TA functionality will be limited according to their customized permissions).

The primary organizational hierarchy for the program lies in the gradebook package. It includes classes for the Gradebook itself, Courses, and Sections. Each of these will need to be implemented according to the model specification; each item aggregates the necessary classes to maintain this hierarchy. Courses will need to keep track of the course assignments, and sections will need to keep track of the grades, students, and groups associated with that section of the course.

The Scores class presents some interesting implementation details. Since the scores table is two dimensional (student to assignment mapping), the data structure used is important. A nested HashMap is a viable solution that will make accessing scores relatively simple by keying in with one piece of data, and then by another. For example, the outer map could be keyed by Student and return another map keyed by Assignment with RawScore values. The organization of this nested map will have performance implications, since data is often accessed in bundles according to the Student or Assignment.

Implementation for the people package should be relatively straightforward. The biggest challenge is determining how to integrate the system with the PeopleSoft network, which has not yet been explored. The system will need a way to access the network to pull in the roster, and a way to manage any conflicts that arise from synchronization. Additionally, there will need to be a way for instructors to manage TA permissions, which has not yet been modeled. Finally, authentication will also need to be managed and integrated with PeopleSoft.

The items package presents a few interesting implementation challenges, the most significant of which is handin functionality. A system will need to be implemented that will manage the submission and retrieval of handin files from the department server. Integration with the grade spreadsheet will also need to be done.

Implementation of the visuals package will require some graphics work, which may be relatively challenging. The most difficult part of this implementation will likely be allowing the user to modify the grading curve by adjusting visual representations.

Finally, File and Edit implementation will require the full implementation of the WorkSpace, including an efficient way to manage undo/redo history and the management of selected context for cut/copy/paste functionality. Export, Import, and Print may be implemented if time allows, but are low priority items. Because Find functionality has been modeled in the specification, its implementation will rely mostly on the implementation of Scores. Ideally, this class will contain the necessary methods to allow Find to request the data it needs to perform searches.




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