CSC/ECE 517 Fall 2023 - E2366. Reimplement assignment model and assignment controller (Phase 2)

Expertiza

Expertiza is a Ruby on Rails based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

Introduction

A reimplementation is required for the assignment model and assignment controller in the Expertiza backend.

Problem Statement

The following tasks were required for the reimplementation :

Enhancing Code Clarity: This involves renaming methods with ambiguous names, optimizing loops and adding comments for unclear lines of code.
Removing unused methods Removing unused methods will reduce complexity.
Reimplement Assignment model and controller: Reimplement the methods from Assignment model that are complex and can be implemented in a better way to reduce complexity and by not violating the DRY principles.
Writing tests for assignment models: Tests have to be written for Assignment Model.
Writing tests for the assignment controller: RSwag tests should be written for Assignment Controller

Design Goal

While reimplementation of Assignment model and controller, the following design rules have to be ensured:

Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplications already present in the expertiza system.
Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

Implementation Plan

Documentation for methods that will be re-implemented and implemented as it is:

valid_num_review

This method raises an error if more reviews are required than are allowed. But it is a single method for both reviews and meta reviews. In the reimplemented method, type of review will be a parameter.

varying_rubrics_by_round?

This method checks whether different rubrics are being used in different rounds of review. It does it, however, by checking whether more than one rubric is listed as being used in Round 2 (used_in_round = 2). The reimplemented method will check if we have more than one rubric of a given type for an assignment.

badge?

This method returns the value of the has_badge instance variable and this should be renamed to has_badge?.

calibrated?

This method returns the value of the is_calibrated instance variable and should be renamed is_calibrated?.

current_stage

his method returns the current stage (Submission, Review, Finished, etc.) potentially based on which topic the logged-in user holds. It returns a string, which is useful for printing, though a bit informal. However, since this method is quite similar to two other methods - current_stage_name and stage_deadline, these three can be combined with some modifications in the reimplementation for clarity. For these, we will create a duedate model and implement the get_next_due_date method 2 subclasses- TopicDueDate and AssignmentDueDate.

current_stage_name

This is a convoluted method that returns the same thing as current_stage, except in a few specialized cases, such as when the assignment has topics and the user hasn’t chosen a topic. However, since this method is quite similar to two other methods - current_stage and stage_deadline, these three can be combined with some modifications in the reimplementation for clarity. For these, we will create a duedate model and implement the get_next_due_date method 2 subclasses- TopicDueDate and AssignmentDueDate.

stage_deadline

This method is similar to current_stage, but returns the time of the next deadline unless the assignment is finished. However, since this method is quite similar to two other methods - current_stage_name and current_stage, these three can be combined with some modifications in the reimplementation for clarity. For these, we will create a duedate model and implement the get_next_due_date method 2 subclasses- TopicDueDate and AssignmentDueDate.

num_reviews_greater?

This method checks whether the number of reviews required is greater than the number of reviews allowed. Basically, it just compares two instance variables of Assignment,but handles the special cases of reviews_allowed being null or negative. In the reimplemented method, we will check if reviews_allowed is valid or not in a separate function.

quiz_allowed

This method returns the quiz_allowed_id field of the next due date, i.e., whether a participant is currently allowed to take a quiz. This method will be reimplemented without making a direct call to the check_condition.

response_map_to_metareview

This method finds the “most appropriate” ResponseMap to use as the reviewed_object in a new MetareviewResponseMap. This can be made as a class method of MetareviewResponseMap and combined with the reviewer_metareviews_map method that is basically a step of this method.

review_questionnaire_id

This method finds the questionnaire in use for reviews of work submitted for the assignment. This is a complicated method because it calculates to find the round number, instead of using number_of_current_round(...). In the reimplementation, instead of creating a new form, we can use an already existing form that is associated with the assignment. The logic behind determining a round number based on the topic can also be improved.

reviewer_metareviews_map

This is a step in finding the response_map_to_metareview. There is no need for a separate method for finding reviewer_metareviews_map. This method can be combined with response_map_to_metareview during reimplementation.

Note : The following methods do not require specific changes and will be implemented accordingly.

create_node

This method creates an AssignmentNode for this assignment.

pair_programming_enabled?

This method returns the value of the enable_pair_programming instance variable.

staggered_and_no_topic?

This method checks if the assignment is a staggered-deadline assignment and the logged-in user has not chosen a topic.

team_assignment?

This method checks whether max_team_size > 0 (should be > 1).

teams?

This method is used to check whether any teams exist for this assignment.

topics?

This method is used to check whether any topics exist for this assignment.

create_node

This method creates an AssignmentNode for this assignment.

Files added / modified

reimplementation-back-end/blob/main/app/models/course.rb
reimplementation-back-end/blob/main/app/models/assignment.rb
reimplementation-back-end/blob/main/app/models/assignment_participant.rb
reimplementation-back-end/blob/main/app/controllers/api/v1/assignments_controller.rb
reimplementation-back-end/blob/main/config/routes.rb
reimplementation-back-end/blob/main/spec/models/assignment_spec.rb
reimplementation-back-end/blob/main/spec/factories/factories.rb

reimplementation-back-end/blob/main/db/schema.rb

Test Plan

We plan to use the given test skeletons for assignment model and implement the respective Rspec test cases. The test cases for other methods will be included later as reimplementation might have methods which are combined versions of multiple other methods. The test scenarios for some for the methods are mentioned in the following table.

Sr No	Test Description
1	team_assignment?
1.1	Scenario 1: Max_team_size is greater than 0. Expected: true
1.2	Scenario 2: Max_team_size is equal to 0. Expected: false
1.3	Scenario 3: Max_team_size is less than 0. Expected: false
2	topics
2.1	Scenario 1: Sign_up_topics is empty. Expected: false
2.2	Scenario 2: Sign_up_topics is not empty. Expected: true
3	calibrated?
3.1	Scenario 1: The object is calibrated. Expected: true
3.2	Scenario 2: The object is not calibrated. Expected: false
4	teams
4.1	Scenario 1: Teams are present. Expected: true
4.2	Scenario 2: Teams are not present. Expected: false
5	valid_num_review
5.1	Scenario 1: Number of reviews required is greater than the number of reviews allowed. Expected: Error message
5.2	Scenario 2: Number of meta-reviews required is greater than the number of meta-reviews allowed. Expected: Error message
6	dynamic_reviewer_assignment?
6.1	Scenario 1: Review assignment strategy is RS_AUTO_SELECTED. Expected: true
6.2	Scenario 2: Review assignment strategy is not RS_AUTO_SELECTED. Expected: false
7	badge?
7.1	Scenario 1: Has_badge is nil. Expected: false
7.2	Scenario 2: Has_badge is true. Expected: true
7.3	Scenario 3: Has_badge is false. Expected: false
8	create_node
8.1	Scenario 1: Parent node exists. Expected: New node created with parent_id set.
8.2	Scenario 2: Parent node does not exist. Expected: New node created with no parent_id set.
9	varying_rubrics_by_round?
9.1	Scenario 1: Rubrics of a given type exist in round 2. Expected: true
9.2	Scenario 2: Multiple rubrics of a given type exist in round 2. Expected: true
9.3	Scenario 3: No rubrics of a given type exist in round 2. Expected: false
10	num_review_rounds
10.1	Scenario 1: No due dates. Expected: 0
10.2	Scenario 2: Single due date with round 1. Expected: 1
10.3	Scenario 3: Multiple due dates with different rounds. Expected: Highest round number
10.4	Scenario 4: Multiple due dates with the same round number. Expected: Highest round number
11	review_questionnaire_id
11.1	Scenario 1: No round_number and topic_id provided. Expected: id of the current round's review questionnaire.
11.2	Scenario 2: No round_number and topic_id provided, no next due date. Expected: nil
12	pair_programming_enabled?
12.1	Scenario 1: Pair programming is enabled. Expected: true
12.2	Scenario 2: Pair programming is disabled. Expected: false
13	staggered_and_no_topic?
13.1	Scenario 1: Staggered deadline is enabled, topic_id not provided. Expected: true
13.2	Scenario 2: Staggered deadline is enabled, topic_id provided. Expected: false

Manual Testing Using POSTMAN

Postman was used for manually testing the added method in assignment.rb and their respective controllers actions and routes. Before testing any of these methods using Postman, a request to /login needs to be sent with user_name an password fields which sends a authentication token. This token needs to be added in Postman’s ‘Authorization’ tab as ‘Bearer token’ before any further requests can be made.