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.
• IMehtods that were for quiz_questionnaires were moved to quiz_questionnaire.rb??
• 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

Design Pattern

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.

Design Principle

DRY Single Resp Dependancy inversion Maximizing cohesion Minimizing Coupling separation of responsibility Incresing readability

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)