CSC/ECE 517 Fall 2022 - E2275. Further refactoring and improvement of student quizzes controller

Expertiza Overview

Ruby on Rails was used to create Expertiza, a multifunctional online application for instructors and students. Instructors using Expertiza have the ability to design their own teams, classes, assignments, quizzes, and much more. However, students are also permitted to work in groups, take tests, and do tasks. Additionally, Expertiza enables students to share peer reviews, allowing them to collaborate to enhance others' learning opportunities. It is an open-source program, and Expertiza is in Github repository Expertiza.

Prior Work

• Modified and added comments for index function to clearly indicate it’s functionality
• Refactored the calculate_score method and moved to helper method. which helped in increasing the readability and maintainability of the code while being constant with object oriented design principles.
• In the finished_quiz function, renamed the variables to help understand their purpose better.
• @quiz_taker = AssignmentTeam.find(@quiz_response_map.reviewee_id).participants.first This line of code seems to assume that only one person is on the team. Therefore, changed the name of the variables to better indicate their purpose.
• For self.take_quiz, as the method comment is correct, the name of the method was changed to something relating to what tasks it performs as what it does is not particularly clear.
• The name and the comments for the function were improved to describe the functionality better.
• The comment were grammatically incorrect. Therefore, fixed the English in the comment.

Problem Statement

Background

The student_quizzes_controller consists of methods involved in creating, scoring & recording responses of the quizzes taken by reviewers or students of the other teams with the same assignment. This controller has some issues that violate essential Rails design principles such as DRY principle. There are few methods in this controller that should have been in model classes. Some methods share code, which creates code repetition. Some method comments need to be rewritten.

Resources

Resource 1 :- https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2016/Refactor_different_question_types_from_quiz_feature
Resource 2 :- https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/oss_E1460_aua
Resource 3 :- https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2022_-_E2255._Refactor_student_quizzes_controller.rb

Required Changes

This project builds on E2225 and should begin with the refactoring done by that project. That project focused on simplifying the methods instudent_quizzes controller, while this project looks at making the code more understandable and transparent.

• Method ‘calculate_score’ was moved to the helper completely. Although, the expectation is to retain the redirection logic in the controller and move the business logic to the helper function.
• Method ‘review_questions’ contains the logic for quiz questionnaire. It makes more sense for it to be moved to the quiz_questionnaire controller instead.
• Method ‘calculate_score’ contains logic that is similar to the compute_weighted_score method in the quiz_questionnaire.rb. Refactor the logic of the method to leverage the existing implementation and eliminate duplicate code.
• Utilize the logic in method ‘validate_question’ from the quiz_questionnaire.rb in the calculate_score method instead of the multiple if else statements.

Because this is simply a refactoring project, no functionalities should change. Therefore, existing tests should still pass after these changes have been completed. To test this controller, create a new rspec file for student_quizzes_controller.rb and run the following commands to verify your changes do not break any core functions.
rspec spec/controllers/student_quizzes_controller_spec.rb
Many of these proposed changes require moving the function somewhere else, so some tests may break and require being moved or targeting a different file. Additionally, this file has very little coverage, so manual verification may be required.

Approach

Refactoring

Potential files to be modified during refactoring

1) student_quizzes_controller.rb
2) Quiz_questionnaire_controller.rb
3) student_quizzes_helper.rb
4) quiz_questionnaire.rb

Control Flow

Existing Flow:-


Proposed Flow:-

Potential Design Pattern to be used:

Strategy Pattern

The strategy design pattern was chosen because we are decoupling the logic that calculates the score, which is currently in a single method in the controller file. It is a behavioral design pattern that enables the definition of a family of algorithms, the separation of each algorithm into a different class, and the interchangeability of the algorithm objects. The idea is the split the calculate_score method into different methods which would handle cases of multiple-choice checkbox and single-choice radio in the helper class. As a result, the algorithms will switch between the methods dynamically based on the question.

Chain Of Responsibility

The Chain of Responsibility pattern was implemented as it relies on transforming specific behaviors into handlers which are stand-alone objects. Therefore, in our case, we are passing the responsibility of calculating the score of multiple varieties of questions i.e. checkbox and radio button, to their respective methods. This pattern is useful for the code as it encourages loose coupling between the sender and receiver of a request by allowing several objects a chance to handle the request.

Design Principles

DRY (Don't Repeat Yourself)

DRY principle states that any piece of code should not be repeated, therefore our current approach satisfies the principle by removing the calculate_score method and using the already existing ‘validate_question’ method in the quiz_quesionnaire.rb file to perform the same task.

Single Responsibility

The idea behind the Single Responsibility Principle is that every class, module, or function in a program should have one responsibility or purpose in a program. This would be consistent with our approach as, calculate_scores method which is currently performing multiple task, would be refactored into different methods for handling a specific task.

Maximizing cohesion

This principle ensures that design components that are self-contained: independent, and with a single, well-defined purpose. As our code would follow the strategy principle where all the methods have their specific function along with the DRY principle, this makes sure that the maximum cohesion principle is followed by the code.

Minimizing Coupling

Minimizing coupling principle expects the Modules to be as independent as possible from other modules so that changes to modules don’t heavily impact other modules. Hence, we will be moving the calculate_score method which is tightly coupled with student_quizzes_controller file to its helper file. This would prevent the changes made in the original file from impacting the module.

Increasing readability

This principle simply refers to writing and displaying your code in a way that makes it simple to understand and comprehend. This would be achieved by adding relevant indentations, comments, and documentation. Additionally, code grouping and using name schema would further make the code more cogent and easier to understand.

Test Plan

Manual Testing

Follow these instructions to manually test the functionality of student_quizzes_controller.
1. Log in as instructor using the credentials, username: instructor6, password: password.
2. Select the Assignments subheading. Here, create a new assignment by entering the necessary details. Enable the Has Teams? checkbox and create. Also enable the Has quiz? checkbox.
3. Set the proper due dates for submission review and evaluation by going to the Due Dates page. For Round 1: Review, enable Has Quiz using the dropdown Menu. Once you save, A Number of Quiz questions field will be visible on the Assignments page. Set this to 2 and save.
4. There will be a message inviting you to add participants at the top of the page. Several students should be added to the task using the given link.
5. After logging out as the teacher, log back in as the pupils. Before the deadline for submissions, turn in your assignment.
Note: To submit, you must first establish a team and give it a name.
6. There is a link to "Create a Quiz" at the bottom of the submission page. Select that link.
7. You are then sent to the quiz creation page. Here, you may set True/False questions, Checkbox questions, and Radio button questions along with the appropriate responses.
Then click "Create Quiz." Thus, the quiz is made.
8. Log out and re-enter the assignment as a different student who has registered. submit a document in this student's place. Review the first student's work when the submission deadline has passed, then go back to the main menu.
9. The option to "Take quizzes" will be visible. Select "Request" and then choose the quiz you made. You may now take the test that the other student made here.

Automated Testing using RSpec

There were no existing RSpec test file for student_quizzes_controller.rb to test its functionality. During our prior work we have added 3 RSpec test to test authorization of user. We will add more automated test cases to test calculate_score and other functions using RSpec.

GitHub and Related Link

GitHub repository corresponding to this task is publicly available at E2275 GitHub.

GitHub pull request and file changes can be viewed at "PENDING".

Contributors

Mentor

Neha Kotcherlakota (nkotche@ncsu.edu)

Team Members

Priyam Swatil Shah (pshah9@ncsu.edu)
Sanay Yogesh Shah (sshah34@ncsu.edu)
Subodh Gujar (sgujar@ncsu.edu)