jahorton / unitgrader Goto Github PK

Prerequisites

• Console UI rework - Scanner consolidation (#2)
• Student Folder method/property rework (#3)

All build warnings for the project should be corrected.

One requested feature would be to allow the UnitGrader to connect to a database for its grade outputs (at minimum), if not for other data tracking features. This would need investigation to ensure a good database interfacing solution is chosen that could be designed to support different database types.

In its original form, the UnitGrader has three separate modules that were run separately from within the development IDE:

• unitgrader.grade - the grading-oriented module
• unitgrader.define - the test-suite construction module
• unitgrader.verify - the reflection-based interface test-case generation module

These should instead be accessible from a 'main menu' of sorts that can serve properly as the single entry point for when run via JAR file.

Some instructors like to incorporate the lateness of an assignment into their grading schemes. While this shouldn't affect the results and grading of the test cases, it ideally should have its own parameterization scheme within testing suites and be incorporated as part of the UnitGrader.

Before implementation of a GUI feature for this app is undertaken, a proper refactoring of the current UI code would be extremely wise, as the current UI code is unfortunately rather embedded into the program's functionality.

Ideally, the console UI should instead implement an interface which is used by the rest of the program, paving the way for a separate GUI implementation. This would also facilitate a test-case oriented implementation for automated testing of the UnitGrader itself.

Due to the current serialization strategy, loading old results is likely to cause a secondary LMSAssignmentManager instance to be loaded as well, which could easily cause problems when merging result files.

Fortunately, this is intended behavior when resuming a grading process; the only issue appears to be when merging results.

The console UI code typically creates a new Scanner each time that the program wishes to receive console input. This is an artifact due to the rapid development/prototyping used during the original development of the project - one that needs to be refined and/or replaced, as it's prone to causing memory leaks.

Referencing https://stackoverflow.com/questions/19766566/java-multiple-scanners, the 'best practice' is to instead maintain a singleton Scanner for use throughout the program, since repeatedly opening and closing input streams tends to create lots of problems instead. This will help to eliminate many of the currently-existing build warnings.

Some of the currently existing build warnings will be fairly difficult to fix without some minor changes to code organization for the StudentData class and its interactions with the LMSAssignmentManager interface. In particular, the isStudentFolderPresent method is part of the LMSAssignmentManager.

• Both StudentData and LMSAssignmentManager are generic and have related type parameters.
• Many uses of LMSAssignmentManager should be LMSAssignmentManager<?> - wildcarded.
  • This causes serious conflicts with attempts to wildcard StudentData... which should probably not be generic at all.

As a result, LMSAssignmentManager.isStudentFolderPresent should be reworked to StudentData.getStudentFolder. The LMSDataTag inner class/interface of LMSAssignmentManager could prove useful in rerouting the important functionality to facilitate this restructure.

Alternatively, if it is possible to reasonably preserve the current generic specifications while being more precise in their use, that would be ideal.

At present, the UnitGrader is entirely a console-only app. While this is fine for limited-scale use, a GUI solution would suit this sort of application well and would be a highly-desired and highly-useful feature.

This would, of course, require significant refactoring and redesign of the project, though its present object-orientation and modularity should prove helpful in making the necessary adjustments.

The UnitGrader was originally designed to interface with two Learning Management Software (LMS) solutions - Canvas and Sakai - and designing with this in mind validated numerous assumptions that facilitated rapid development at the time.

A better design would allow definition of profiles for assignment organization schemes that could be customized to each user's taste.

• Predefined profiles would then be provided for various LMS schemes.
• Users without LMSes could create custom profiles matching their preferred organization schemes for student submissions.
• While initially complex to create, this solution would be more maintainable long-term, since LMS profiles could be shared without requiring changes to the actual UnitGrader code base.

Checklist:

• AssignmentManager redesign implemented
• Canvas profile provided
• Sakai profile provided