CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

From Expertiza_Wiki
Revision as of 15:56, 24 March 2024 by Slkwiatk (talk | contribs)
Jump to navigation Jump to search

This wiki page describes changes made under the E2407 OODD assignment for Spring 2024, CSC/ECE 517.

Expertiza Background

Ruby on Rails is used in the development of the open-source project Expertiza. The NC State staff and students are in charge of maintaining this online application. With this program, the teacher has total control over the tasks in their class. Expertiza is a feature-rich program that can manage any kind of assignment, with features like peer reviews, group creation, and subject addition. Go to the Expertiza wiki to find out more about all of the features that Expertiza offers.

About Controller

review_mapping_controller function is to map the reviewer to an assignment. In essence, the controller manages the distribution of reviews among various groups or individual student users, addressing situations such as peer and self-evaluations. Furthermore, the controller is essential in responding to student users' requests and enabling additional bonus reviews that comply with the assignment criteria.


Functionality of review_mapping_controller

The review_mapping_controller serves as a critical component within a system designed to manage the assignment mapping and allocation of reviewers for various types of assessments, such as peer reviews and self-assessments. Its primary function revolves around orchestrating the distribution of these reviews, whether they are assigned to multiple teams or to individual student users. This entails a sophisticated algorithmic process that takes into account factors such as fairness, diversity of perspectives, and adherence to assignment guidelines. By controlling the assignment of reviews, the controller ensures that each participant receives a balanced and constructive evaluation of their work, contributing to the overall integrity and effectiveness of the assessment process.

Furthermore, the review_mapping_controller plays a pivotal role in handling student requests for additional bonus assessments. These requests may arise due to various reasons such as a desire for more feedback, a pursuit of extra credit, or a need for reassessment. In responding to such requests, the controller must maintain alignment with the established guidelines and constraints of the assignments. This involves evaluating the feasibility of accommodating extra assessments without compromising the integrity or fairness of the evaluation process. Additionally, the controller may need to consider resource constraints, such as the availability of reviewers and the workload distribution among them.


Problem Statement

The review_mapping_controller presents a challenge due to its length, complexity, and sparse comments, making it difficult for developers to grasp its functionality efficiently. To address this, the controller should undergo a comprehensive refactoring process aimed at breaking down lengthy methods into smaller, more manageable pieces. This entails decomposing intricate logic into modular components, each responsible for a specific task or subtask within the overall functionality. Moreover, the refactoring effort should target instances of code duplication, consolidating repeated code segments into reusable functions or utility methods to enhance maintainability and reduce the risk of errors. By systematically restructuring the controller codebase and improving its documentation, developers can gain a clearer understanding of its inner workings, facilitating easier maintenance, debugging, and future enhancements.

Tasks

-Refactor the long methods in review_mapping_controller.rb like assign_reviewer_dynamically, add_reviewer, automatic_review_mapping, peer_review_strategy, etc. -Rename variable names to convey what they are used for.
-Replace switch statements with subclasses methods.
-Create models for the subclasses.
-Remove hardcoded parameters.
-Add meaningful comments and edit/remove/do not unnecessary comments.
-Try to increase the test coverage.

Phase 1

For Phase 1 of the project we have focused working on the below mentioned issues.
-Refactor assign_reviewer_dynamically function
-Corresponding changes to the tests for assign_reviewer_dynamically
-Refactor add_reviewer function
-Corresponding changes to the tests for add_reviewer
-Correct comments and add additional comments
-Methods are named descriptively to indicate their purpose
-Fixed Code climate issues

Phase 2

For Phase 2 of the project we plan working on the below mentioned issues.
-Refactor automatic_review_mapping function
-Refactor peer_review_strategy function
-Replace switch statements with subclasses methods
-Increase the test coverage
-Remove hardcoded parameters
-Create models for the subclasses

Implementation

Phase 1

add_reviewer

The changes made to the `add_reviewer` method can be checked in the commit - https://github.com/NidhayPancholi/expertiza/commit/b325810d67da2a03d3ccb15458926d0049fdb9eb. The changes are described descriptively below.:

- Refactored the `add_reviewer` method to focus on single tasks per method, enhancing code readability and maintainability.
- Extracted the functionality to find a user's ID by name into a separate method named `find_user_id_by_name`.
- Separated the logic to check if a user is trying to review their own artifact into its own method named `user_trying_to_review_own_artifact?`.
- Abstracted the process of assigning a reviewer to the assignment into a method named `assign_reviewer`.
- Created a method named `registration_url` to generate the registration URL for the assignment based on provided parameters.
- Divided the code to create a review response map into a separate method named `create_review_response_map`.
- Extracted the logic to redirect to the list mappings page after adding the reviewer into its own method named `redirect_to_list_mappings`.
- Added descriptive comments to each method to explain its purpose and functionality clearly.

assign_reviewer_dynamically

The changes made to the `assign_reviewer_dynamically` method can be checked in the commit - https://github.com/NidhayPancholi/expertiza/commit/30a3625d4188e56a58e4b6472c52b60bbfb83df5. The changes are described descriptively below:

- Restructured the `assign_reviewer_dynamically` method to perform single tasks per method, improving code organization and readability.
- Extracted the functionality to find the assignment participant into a separate method called `find_participant_for_assignment`.
- Abstracted the logic to handle errors when no topic is selected into a method named `topic_selection_error?`.
- Created a method named `dynamically_assign_reviewer` to handle the process of dynamically assigning a reviewer based on the assignment type.
- Separated the logic to assign a reviewer when the assignment has topics into a method named `assign_reviewer_with_topic`.
- Developed a method called `select_topic_to_review` to handle the selection of a topic for review.
- Extracted the logic to assign a reviewer when the assignment has no topics into a method named `assign_reviewer_without_topic`.
- Created a method named `select_assignment_team_to_review` to handle the selection of an assignment team for review.
- Abstracted the process to redirect to the student review list page into a method called `redirect_to_student_review_list`.
- Added clear comments to each method to explain its purpose and functionality effectively.

Changes to the spec file

The changes made to the test files are described below and can be found in the commit - https://github.com/expertiza/expertiza/commit/7c08070f0c2c000e64e55561b882e44fc81bc98f:

- Updated the `ReviewMappingController` spec file.
- Added a test case in the `ReviewMappingController` spec file for the `add_reviewer` method to ensure correct behavior when a team user exists and `get_reviewer` method returns a reviewer.
- Adjusted the expectation in the `assign_reviewer_dynamically` test case to match the corrected error message in the controller. Specifically, removed the extra space from the expected error message to align with the actual error message generated by the controller.
- Ensured that all test cases are descriptive and cover the relevant scenarios for each method.
- Verified that the test cases accurately reflect the behavior of the controller methods after the code changes.

Test Plan

We plan on adding more tests, increasing the test coverage in Project 4.

In our Test-Driven Development (TDD) endeavors, our team would strategically adopt Mustafa Olmez's meticulously crafted test skeletons. These meticulously designed skeletons will serve as invaluable blueprints, delineating the essential tests necessary for our unit. By integrating these meticulously designed test skeletons into our workflow, we conduct comprehensive testing of our controller module. This method would enable us to thoroughly explore the functionality of our controller, ensuring meticulous examination and validation of its behavior. Incorporating these test skeletons will not only establish a sturdy framework for our unit tests but also elevate the overall quality and dependability of our codebase.

Test Plan

Our Test Plan includes test for review_mapping_controller.rb file for the following functions:

1. Test `action_allowed?` method:

  - Test when the action is 'add_dynamic_reviewer'.

  - Test when the action is 'show_available_submissions'.

  - Test when the action is 'assign_reviewer_dynamically'.

  - Test when the action is 'assign_metareviewer_dynamically'.

  - Test when the action is 'assign_quiz_dynamically'.

  - Test when the action is 'start_self_review'.

  - Test when the action is not any of the allowed actions for different roles.

2. Test `add_calibration` method:

  - Test when the participant is already assigned.

  - Test when the participant is not assigned.

  - Test when a calibration map already exists.

  - Test when a calibration map does not exist.

  - Test redirection to the response creation page.

3. Test `select_reviewer` method:

  - Test when called with a valid contributor_id.

  - Test when called with an invalid contributor_id.

4. Test `select_metareviewer` method:

  - Test when given a valid response map id.

  - Test when given an invalid response map id.

5. Test `add_reviewer` method:

  - Test when the reviewer is not assigned to review their own artifact.

  - Test when the reviewer is assigned to review their own artifact.

  - Test when the reviewer is already assigned to the contributor.

6. Test `assign_reviewer_dynamically` method:

  - Test when a topic is selected and review is allowed.

  - Test when no topic is selected and review is allowed.

  - Test when no topic is selected and review is not allowed.

  - Test when a topic is selected and review is not allowed.

  - Test when there are no available topics to review.

  - Test when there are no available artifacts to review.

  - Test when the reviewer has reached the maximum number of outstanding reviews.

7. Test `review_allowed?` method:

  - Test when the reviewer has not reached the maximum number of reviews allowed for the assignment.

  - Test when the reviewer has reached the maximum number of reviews allowed for the assignment.

8. Test `check_outstanding_reviews?` method:

  - Test when there are no review mappings for the assignment and reviewer.

  - Test when there are review mappings for the assignment and reviewer, and all reviews are completed.

  - Test when there are review mappings for the assignment and reviewer, and some reviews are in progress.

9. Test `assign_quiz_dynamically` method:

  - Test when the reviewer has already taken the quiz.

  - Test when the reviewer has not taken the quiz yet.

  - Test when an error occurs during the assignment process.

10. Test `add_metareviewer` method:

   - Test when a metareviewer is successfully added.

   - Test when the metareviewer is already assigned to the reviewer.

   - Test when an error occurs during the process.

11. Test `assign_metareviewer_dynamically` method:

   - Test when there are reviews to Meta review.

   - Test when there are no reviews to Meta review.

   - Test when an error occurs during assignment of metareviewer.

12. Test `get_reviewer` method:

   - Test when the user is a participant in the assignment.

   - Test when the user is not a participant in the assignment.

13. Test `delete_outstanding_reviewers` method:

   - Test when there are outstanding reviewers.

   - Test when there are no outstanding reviewers.

14. Test `delete_all_metareviewers` method:

   - Test when there are metareview mappings to delete.

   - Test when there are unsuccessful deletes.

   - Test when there are no metareview mappings to delete.

15. Test `unsubmit_review` method:

   - Test when the response is successfully unsubmitted.

   - Test when the response fails to be unsubmitted.

16. Test `delete_reviewer` method:

   - Test when the review response map exists and there are no associated responses.

   - Test when the review response map exists but there are associated responses.

   - Test when the review response map does not exist.

17. Test `delete_metareviewer` method:

   - Test when the metareview mapping exists.

   - Test when the metareview mapping does not exist.

19. Test `list_mappings` method.

20. Test `automatic_review_mapping` method.

21. Test `automatic_review_mapping_strategy` method.

22. Test `automatic_review_mapping_staggered` method.

23. Test `save_grade_and_comment_for_reviewer` method.

24. Test `start_self_review` method.

25. Test `assign_reviewers_for_team` method.

26. Test `peer_review_strategy` method.

27. Test `review_mapping_params` method.

Design Pattern

During our code refactoring process, we leveraged various design patterns to enhance readability and maintainability. One commonly applied pattern was "Extract Method," where we identified lengthy and intricate methods and extracted segments of functionality into separate methods. This restructuring made the code more comprehensible and easier to grasp by isolating specific tasks within dedicated methods.

Additionally, we addressed the issue of excessive conditional statements by employing the "Refactoring Conditionals" design pattern. Instead of cluttering the code with numerous conditionals, we refactored by encapsulating the logic within these conditionals into distinct methods. By doing so, we streamlined the code's flow and improved its readability, making it clearer to understand the purpose and execution of each segment.


Relevant Links

Team

Mentor

  • Ananya Mantravadi (amantra)

Team Members

  • Lagani Patel (lpatel)
  • Nidhay Pancholi (nrpancho)
  • Saloni Shah (sshah39)
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management&oldid=153401"