CSC/ECE 517 Fall 2023 - E2371. Reimplement quiz questionnaires controller

This wiki page is for the description of changes made under E2371 OSS assignment for Fall 2023, CSC/ECE 517

Introduction

Expertiza stands as a noteworthy open-source initiative, rooted in the robust Ruby on Rails framework, and is the product of a collaborative effort between faculty and students at NC State. This web application plays a pivotal role in aiding instructors in the creation of tailored assignments, encompassing both new and existing tasks. Furthermore, instructors can curate a diverse range of topics for student enrollment. Within the Expertiza ecosystem, students possess the capability to form collaborative teams for the seamless execution of various projects and assignments. A cornerstone of this platform is its provision for students to engage in peer reviews of their peers' submissions.

What sets Expertiza apart is its versatility in accommodating an array of document types, enabling submissions in diverse formats, including URLs and wiki pages. Positioned as an open-source learning management system, Expertiza harnesses the power of Ruby on Rails to provide an extensive suite of features that empower students to submit and actively participate in peer review processes across an array of learning objects, such as articles, code, and websites. Instructors find themselves equipped with the ability to oversee and assess student submissions efficiently through the platform. In essence, Expertiza plays an indispensable role in aiding instructors and teaching assistants in the efficient management of assignments for the courses they administer.

Overview of the Controller

The QuizQuestionnairesController is a crucial component in the project, responsible for managing quiz questionnaires within the application. It extends the functionality provided by the base QuestionnairesController and incorporates the AuthorizationHelper module, making it central to handling user permissions and authorization checks. Its primary role is to determine whether users have the necessary privileges to perform various actions related to quiz questionnaires, such as creation, editing, viewing, and deletion, based on their roles and access rights.

In addition to its authorization responsibilities, the QuizQuestionnairesController plays a pivotal role in facilitating the creation and editing of quiz questionnaires. It defines methods for creating, updating, and deleting questionnaires, ensuring they adhere to specified guidelines and that edits are allowed under specific conditions. The controller also manages the intricacies of quiz data, from validating questions and managing answer choices to enforcing logic for different question types. This controller essentially acts as the backbone for handling all aspects of quiz-related actions, guaranteeing user permissions are respected and that quiz data is properly maintained throughout its lifecycle.

Background of the Project

The reimplementation of the quiz questionnaire controller in Expertiza is an important project aimed at enhancing the functionality, clarity, and maintainability of this crucial component. The existing controller is in need of a comprehensive overhaul to better align with best coding practices and user requirements. Here's a background for this project:

Project Overview: The project involves reimagining and improving the quiz questionnaire controller within the Expertiza platform. The current controller lacks clarity, has unclear functionality, and could benefit from enhanced performance. The primary objective is to implement CRUD operations (Create, Read, Update, Delete) for quiz questionnaires while ensuring that user permissions are adequately considered for these actions.

Key Tasks and Objectives:

CRUD Operations: The reimplementation will involve creating methods to handle the creation, editing, deletion, and viewing of quiz questionnaires. These methods should adhere to best coding practices and clearly indicate their functionality.

Code Refinement: Existing code should be refactored to ensure clean and concise implementation. Methods with the same names that perform different tasks should be renamed for clarity, and any unclear or redundant functionality should either be documented or removed. Performance bottlenecks, such as loops or methods that can be refactored for better efficiency, should be addressed.

Complexity Reduction: Any unused or unclear functionality should be removed from the controller. This step is essential in reducing the complexity of the codebase, making it more maintainable and understandable.

Testing: Comprehensive testing should be implemented for the quiz questionnaire controller. The tests should aim to cover at least 80% of the codebase, ensuring the reliability and correctness of the reimplementation. Tools like Rubocop and Code Climate should be used to identify and rectify code smells.

Benefits:

Improved User Experience: The reimplementation will result in a more user-friendly and intuitive interface for managing quiz questionnaires.

Enhanced Code Quality: The project will elevate the overall code quality, making it cleaner, more efficient, and easier to maintain.

Better Performance: Addressing performance issues will lead to faster and more responsive interactions with the system.

Reduced Complexity: The removal of unused or unclear functionality will simplify the controller, making it more accessible for developers and maintainers.

In summary, the reimplementation of the quiz questionnaire controller in Expertiza is a vital project that aims to revamp and optimize this component, ultimately providing a more effective and user-friendly experience for instructors, students, and developers.

Implementation

quiz_questionnaire_controller.rb:

We have reimplemented the `Api::V1::QuizQuestionnairesController` in Ruby on Rails by making several key changes to improve code readability, maintainability, and error handling. Below are the main modifications made to the code:

1. Changed Function Names: The function names have been chosen to be more concise and descriptive. For example, the method originally named 'copy' is used to create a copy of a questionnaire, and this change makes the code more intuitive.

2. Improved Code Comments: Detailed comments have been added to each action method, explaining the purpose of the method and the expected parameters. This documentation is invaluable for both developers working on the code and anyone looking to understand how the API functions.

3. Improved Error Handling: The code has been enhanced to handle exceptions more specifically, such as catching `ActiveRecord::RecordNotFound` and `ActiveRecord::RecordInvalid` exceptions. This results in more informative error messages, which is beneficial for debugging and communication with clients.

4. Refactored Create Method: The `create` method has been refactored to improve clarity and robustness. It now first checks user privileges using the `check_privilege` method. If the user has the required permissions, it proceeds to create a new `QuizQuestionnaire` based on the provided parameters. This refactoring helps separate concerns and makes the code more organized.

5. Consistent Status Codes: The code now consistently uses HTTP status codes to indicate the result of API requests. For instance, it uses `status: :not_found` when a requested resource is not found, which aligns with common HTTP conventions. This consistency in status codes improves the predictability of API responses.

6. Consistent JSON Response Format: The JSON responses have been structured consistently to follow a standardized format. Keys like "model_object" and "participants" are used to make it easier for client applications to consume the API. This consistency simplifies the parsing of responses on the client side.

These changes enhance the overall quality of the code, making it more accessible for developers, improving the API's reliability, and providing a consistent and user-friendly experience for clients interacting with the API.

Screenshots

1. Login

2. Create

3. Get/Show

4. Delete

5. Update

6. Copy Questionnaire

Test Plan

To make sure that everything works accordingly the Rspec tests are written to check the re-implemented methods. The re-implemented methods are:

1. index

2. show

3. create

4. update

5. delete

6. copy

The test are written for both success and fail scenario with keeping in mind the corner or the edge cases like when executing any method. For example, the method checks whether the user has the privilege to access the method or not. Also if the participant belongs to the appropriate team. The test plan also consider scenarios where the input to the method is invalid. For example, when a user passes a blank or null input for Quiz Questionnaire name or any other parameter in null, then the update method will return an error with status code 422 Unprocessable Entity. The test plan is devised to return appropriate success or fail status code with meaningful messages so any developer can understand and debug.

Program 4 Design Patterns Used

Design Principles in QuizQuestionnairesController.rb:

Single Responsibility Principle (SRP)

The QuizQuestionnairesController adheres to the Single Responsibility Principle (SRP) by ensuring that each of its actions is dedicated to a specific responsibility related to managing quiz questionnaires. The breakdown of responsibilities is as follows:

Index Action: Retrieves a list of quiz questionnaires.

Show Action: Retrieves details of a single quiz questionnaire.

Create Action: Creates a new quiz questionnaire based on provided parameters.

Update Action: Updates an existing quiz questionnaire.

Destroy Action: Deletes a quiz questionnaire.

Copy Action: Creates a copy of a quiz questionnaire.

This adherence to the SRP enhances maintainability and readability, making it easier to understand and modify each action independently.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle (DIP) is exemplified in the QuizQuestionnairesController through the use of ActiveRecord. Instead of directly depending on a specific database implementation, the controller relies on the ActiveRecord interface. This decouples the controller from the underlying database details, promoting flexibility and facilitating easier integration with different data storage solutions in the future.

By embracing ActiveRecord as an abstraction layer, the controller adheres to the DIP, allowing for a more modular and extensible architecture. This design choice enables easier testing, as the controller's interactions with the database are abstracted through a well-defined interface.

Design Principles in ReviewQuestionnaire.rb:

Single Responsibility Principle (SRP):

To uphold the Single Responsibility Principle, we plan to extract the logic related to assessments retrieval—specifically in the get_assessments_for and get_assessments_round_for methods—into a dedicated service or module. By doing so, we ensure that the ReviewQuestionnaire class maintains a single responsibility, focusing solely on the management of review questionnaires. This separation of concerns not only aligns with best practices but also contributes to clearer and more maintainable code.

Factory Method Pattern:

We recognize the potential need to instantiate different types of questionnaires in the future while maintaining a common interface. To address this, we plan to implement the Factory Method Pattern. This pattern will allow us to encapsulate the instantiation logic, providing flexibility in creating various questionnaire types without altering the client code.

Design Principles in MetaReviewQuestionnaire.rb:

Single Responsibility Principle (SRP):

In our ongoing efforts to enhance the maintainability and clarity of our codebase, we have identified the MetareviewQuestionnaire model as a candidate for refactoring. The model currently adheres well to the Single Responsibility Principle (SRP) by focusing on the management of metareview questionnaires. Each method within the model (post_initialization, symbol, get_assessments_for) appears to align with this singular responsibility.

Encapsulation:

To enhance encapsulation and follow best practices, we will encapsulate the class variable @print_name by providing an appropriate getter method. This step aims to hide the internal details of the class, promoting a cleaner and more maintainable code structure.

Factory Method Pattern:

We recognize the potential need to instantiate different types of questionnaires in the future while maintaining a common interface. To address this, we plan to implement the Factory Method Pattern. This pattern will allow us to encapsulate the instantiation logic, providing flexibility in creating various questionnaire types without altering the client code.

Design Principles in AssignmentQuestionnaire.rb:

Single Responsibility Principle (SRP):

The AssignmentQuestionnaire model currently handles both ActiveRecord associations and custom query methods. To adhere more closely to the SRP, we plan to separate these concerns into distinct modules or classes. This separation will not only enhance the readability of our code but also contribute to a more modular and organized structure.

Factory Method Pattern:

In cases where there are varied ways to instantiate AssignmentQuestionnaire instances, we recognize the potential benefits of applying the Factory Method Pattern. This pattern allows us to define an interface for creating instances in a superclass while enabling subclasses to alter the types of objects created.

Relevant Links

Github repository: https://github.com/rajmadhu0406/reimplementation-back-end

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/48

Team

Mentor

Muhammad Ali Qureshi

Student Team

1] Raj Madhu (rmadhu@ncsu.edu)

2] Jinil Shukla (jshukla@ncsu.edu)

3] Dhyey Shah (dshah22@ncsu.edu)