User:Bkurra

Expertiza

The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

Problem Statement

The ResponseController in Expertiza, a historical system with conventions that predate Rails standards, is too intricate, incorporating functionalities that extend beyond simple CRUD operations and requiring compliance with contemporary Rails nomenclature and design concepts. Critical concerns encompass the direct execution of functions such as sorting reviews and verifying reviewer roles within the controller, indicating a transition towards polymorphism and a more systematic method of code organization. Moreover, the controller's management of email notifications and feedback systems is erratic, highlighting the need for a specialized assistant to optimize communication procedures. The reimplementation initiative must concentrate on streamlining the controller, conforming to Rails principles, and enhancing code readability and maintainability through the judicious allocation of responsibilities.

Design Goal

The redesign of `responses_controller.rb` is driven by several primary aims aimed at enhancing code quality, system performance, and developer engagement. The objectives encompass:

• Maintainability and Scalability: Guaranteeing the code is comprehensible, modifiable, and extensible. The reimplementation should facilitate future updates and the incorporation of new features.

• Compliance with Rails Best Practices: Adhering to Rails conventions on nomenclature, architecture, and coding methodologies to guarantee code uniformity and dependability.

• DRY Principle: "Don't Repeat Yourself" - eliminating unnecessary code and logic to enhance efficiency and reduce errors in the codebase.

• Single Responsibility Principle: Reorganizing the controller and related models to ensure that each class and method has a singular purpose, hence facilitating enhanced testing and management.

• Enhanced Testing and Coverage: Augmenting test suites to encompass a broader range of scenarios and edge situations, hence bolstering confidence in the application's stability and performance.

• Performance Optimization: Recognizing and enhancing sluggish or ineffective segments in the code to guarantee the application operates seamlessly.

• Eliminate Obsolete Methods: Conduct an audit of the codebase to identify and delete any unneeded ("dead") methods inside the present controller to streamline the code.

• Diminished Controller Complexity: We have already streamlined the `ResponseController` to concentrate mostly on CRUD activities and have extracted non-essential functionality to suitable models or helpers; now we intend to implement the remaining operations.

By achieving these design objectives, the project seeks to create a `responses_controller.rb` that is resilient, efficient, and user-friendly for both the current development team and future system maintainers.

Design Pattern

Throughout the code rewriting effort, we meticulously adhered to certain design patterns to improve the overall architecture. During the redesign of the Response model and its corresponding controller and helper methods within the application, several fundamental design patterns and concepts were adhered to in order to enhance code quality, maintainability, and scalability. The following are the principal patterns and principles that were taken into account:

Single Responsibility Principle (SRP)

This technique was utilized to decompose intricate methods into smaller, more targeted functions that manage a specific aspect of the process.

In the Response Model, Validate_params was subdivided into several smaller methods, each responsible for a distinct aspect of the validation process. This enables each method to oversee a specific facet of the validation, hence enhancing the maintainability and modifiability of the code. The establishment and administration of relationships and fundamental properties were distinctly articulated, ensuring that the Response class remains unencumbered by logic unrelated to its specific attributes or relationships.

In the ResponsesController, the methods such as create, update, and show are designed solely to manage HTTP requests while delegating business logic to the model or helper methods. This maintains the controller actions in a clean and focused manner for routing and fundamental request management.

In the ResponseHelper, methods like create_answers and update_answers exemplify the principle that each method is designated for either the creation or the updating of answers, but not both. This adheres to SRP by partitioning duties into more manageable, distinct operations.

Factory Method

The Factory Method design is implicitly evident when object generation procedures are encapsulated within the model or auxiliary methods, such as instantiating a new ResponseMap or generating new Answer objects. This guarantees that object instantiation is modular and distinct from the primary application logic.

Strategy Pattern

The strategy design enables the independent variation of algorithms by establishing a family of encapsulated algorithms, such as validation criteria for activities like creation or updating, and allowing them to be interchangeable for the clients that utilize them. Separating the validation criteria for response creation and updating facilitates the flexible interchange and enhancement of validation logic without necessitating direct alterations to the controller or model. Observer Pattern Typically employed in situations where modifications to a certain object must automatically inform other dependant objects. Within the framework of this program, this may pertain to alerting instructors or peers following the submission or modification of responses, managed via the auxiliary ways for dispatching emails.

Template Method

This pattern can be employed to delineate the framework of an operation within a method, postponing certain phases to subclasses or other methods. The validation process in validate_params employs a generic framework while delegating specific details to methods such as validate_create_conditions and validate_update_conditions.

The refactoring seeks to establish a more resilient, manageable, and scalable system through the integration of various design patterns and concepts. This method not only resolves existing complexities but also establishes a basis for more straightforward future improvements and alterations.

Class Diagram

Use cases

== Solutions/Details of Changes Made== 

Response Model

Methods in the response model were either refactored or newly added, including: 

set_content

 Reengineered to collect and organize the necessary data for response objects, enhancing the interaction with related models.

validate_params

This is the original approach including 46 lines.

This method underwent substantial refactoring to enhance parameter validation. It was divided into several smaller, targeted procedures, each assigned to address a certain facet of the validation process. Each new method performs a singular function, hence enhancing comprehension and maintainability.

• Assigns the map_id for the response according to the specified parameters, ensuring the accurate map ID is utilized for both creation and modification of responses.

• set_and_validate_response_map: Confirms and verifies the existence of the response_map according to map_id. It is essential to verify that any answer being generated or modified is associated with a proper response map.This method seeks to locate a ResponseMap using map_id. If it cannot locate one, it logs an error and ceases further validation, indicating a problem early in the procedure.

File:Set and validate response.png

• set_response_attributes(params): Allocates supplementary attributes to the response object derived from the parameters. This consolidates attribute configuration, minimizing redundancy and errors.Extracts values such as round, version_num, additional_comment, and visibility from the arguments and assigns them to the answer object.

• action_specific_validation(params, activity): Orchestrates the validation process contingent upon whether the action pertains to creating or updating a response, systematically structuring the logic to avert condition proliferation in the primary validation procedure.Invokes various validation methods according to the action type: validate_create_conditions for creation and validate_update_conditions for updates.

• validate_create_conditions: Verifies that a new response does not replicate an existing response inside the same response map, round, and version number.Conducts a search for a pre-existing response that corresponds to the current map_id, round, and version_num. If such a response exists, it generates a validation error and inhibits the generation of a duplicate answer.

validate_update_conditions(params): Verifies the validity of updates to a response, specifically confirming that the response has not been previously sent and that its map_id remains constant.Verifies the submission status and assesses any attempts to modify the map_id. Should either criteria be breached, an error is documented.

validate_submission_status(params): Modifies the submission status of the response during the update procedure, guaranteeing that the attribute is accurately configured according to the supplied parameters.Extracts and establishes the is_submitted state from the parameters, which is essential for regulating the editability of the answer. File:Validate submission status.png

serialize_response

Optimized for the effective serialization of answer data in API contacts, hence boosting the clarity and usefulness of data exchanges.

Response Controller

The ResponseController, initially comprehensive with several features exceeding simple CRUD operations, has been optimized for our API application. In this scenario, it is unnecessary to manage data variables for view pages, hence streamlining the handling of request data exclusively through request methods.To improve the architecture and efficiency of our program, we have removed unnecessary methods and integrated functionality across the model, controller, and helper files. The restructure was crucial for optimizing the response endpoints specifically designed for an API application.

Prior to the incorporation of fundamental CRUD operations such as Create, Read, Update, Edit, and Delete.

Removed Methods: The legacy methods Questionnaire_from_response_map and Questionnaire_from_response were eliminated with the reworking of set_content, which now internally manages their functionalities.

=== Show_calibration_results_for_student ====

Before:

File:Display calibration outcomes for student.PNG

The previous solution also utilized database queries within the display. The reimplemented Expertiza will not permit this, necessitating that the relevant data be included in the JSON response sent by the controller.

The new show_calibration_results_for_student method obtains and presents calibration and review replies according to specified map IDs. It retrieves responses utilizing these IDs, acquires corresponding questions and answers, and presents the data as a structured JSON object. In the absence of a response, an error is generated to signify the lack of a response. The method manages all exceptions by providing a standardized error message, hence assuring comprehensive error handling during the operation. Functions as an API endpoint to retrieve comprehensive response data for a student's calibration and review activities, supplying all pertinent information regarding the questions posed and the answers given in both scenarios.

Response Helper

The method create_update_answers(response, answers) initially managed both the generation and modification of answer records within a singular function.

To enhance code maintainability and comply with the Single Responsibility Principle, this method has been separated into two distinct methods:

Create_answers ==== ==== This method is exclusively concerned with generating new answer records. It traverses the submitted responses, verifying that each answer is not already present in the database. If the response is absent, it generates a new record for that answer. This guarantees the uniqueness of each response and inhibits redundancy.

Update_answers

This technique updates existing response records. It queries the database for existing replies using the response and question identifiers. Upon discovering an answer, it revises the current record with the newly supplied information. This method guarantees the precise recording of all response updates and maintains the database's currency.

Files Modified/Added

List of primary files modified or created includes:

• responses_controller.rb
• response_helper.rb
• response.rb

Test

Validate Parameters

Postman Tests

Separated Answer Creation and Update Logic

Postman Tests

Creation:

Update:

Team

Mentor

• Richard Li

Members

• Loyda Yusufova
• Bhuvan Chandra Kurra

Links

Postman Video Links:

• create: https://youtu.be/hXQl-JkfuUc
• update: https://youtu.be/BeifLsCRQlk
• show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

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

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU