Today we did accomplished a lot. We started first by talking about current problems and what we are going to need to start look at now that we have somewhat developed our server and testing models. During these discussions many things were developed further for our prototype system. Of these the ones that effect my portion of the system (compiling, testing, reporting results) are the file structure of the system, and what information constitutes a submission, user, and assignment.

The File Structure of the submission system was finalized today so we can start implementing features for transferring files from the users to the system. We initially started with two different designs that offered benefits when displaying the directory structure to the user, for example a professor or teacher assistant would be interested in having the students be grouped by course offering while a student might want the directories to be based around their courses.

 

Design A

 

As you can see in Design A there are two main sub-directories, Courses and Course Offerings, this structure was designed with the teacher assistants and professors in mind where the students are grouped under the courses they are currently taking. This layout allows professors and teacher assistants of the course to quickly access each student within the course while if a student saw this layout they’d have to open their user folder in each course in order to get to their assignments and would quickly find this tedious.

 

Design B

 

In figure B the system is more centered around the individual users and what courses that are participating in. In this design you’d run into similar problems as in figure A only now it would be on the professor and teacher assistant having to go to each student open their directories and find the course they want for each student.

While each of these designs have similar problems vs benefits what ultimately tipped the balance in favor of design B was the fact that the number of students will be far higher than the number of professors and Teacher assistants and cleaning up the directories of old users will be accomplished with greater ease with Design B than Design A. After all in design A we’ll have to go into each course offering the student was involved with and delete the students directory there as opposed just deleting the entire student directory and hitting all the course offerings at once.

Users, Assignments, and Submissions.

The changes to these models were just clarifying what data should be included in each. For example we removed the directory field for users and Assignments as they are computable given other pieces of information. For example a user’s directory can be computed by concatnating the wpi_submission_system directory with ‘Users/’ and ‘Username+userID+”/”‘. So those fields have been removed from the model of a user and assignment.

Where to go from here?

At this point we are trying to merge Richard’s Hazelcast/cajo with Chance’s database and my junit prototypes into a somewhat cohesive system as a basis for starting the rest of our project. At the same time I’m going to be looking into authorization libraries, and sandboxes for running code with restrictions on what can be accessed such as directories and other system resources.