CSC/ECE 517 Fall 2024 - E2468. Reimplement due date
About Expertiza
Expertiza is an open-source project built using Ruby on Rails. It provides a platform for instructors and students to manage, submit, and evaluate assignments and projects. Instructors can create, edit, and grade assignments, while students can collaborate in teams, submit their work, and review peers' submissions. Expertiza supports submission across various document types, including URLs and wiki pages.
Issues with previous Functionality
- Outdated Code: The original implementation seems to be very old code that does not utilize features that are standard in current ruby versions. Updating this code improves maintainability and code clarity. A prime example is the use of a flag attribute, which apparently has not been used in nearly a decade.
- Readability: The original due_date.rb had become quite bloated and messy, with overly complex methods that were difficult to read. An example of this is self.get_next_due_date. This could hamper future development as understanding exactly what due dates can and cannot do could become difficult due to unclear code.
- Single-Responsibility Principle Violations: The original implementation violated several SOLID principles, primarily violations around the Single-Responsibility Principle. These issues create difficulty in maintainability as code may need to be updated in multiple places that each do the same thing.
Design Goals
- We had one overarching goal with this reimplementation: clean up the old bloated model. To do so, we broke down functionality into two separate buckets - code that was overly complex and/or wordy, which could be reused after some basic cleanup and simplification; and code that was obsolete and therefore could be removed entirely with the reimplementation
- Some attributes of the old model were determined to not be reused in the new implementation. However, these attributes need to be present for backward compatibility, so we removed any references to them but left their associated column within our table.
Implementation
Reimplemented Methods
DueDate
While most of the methods in the original model were functionally correct, we saw areas of possible improvement both in readability and complexity. We also removed a few methods that were unnecessary after reimplementation.
| Reimplemented method | Description |
|---|---|
| due_at_is_valid_datetime | Simple validation that due_at is a datetime and not some other data type. |
| self.sort_due_dates | Sorts the due dates by earliest to latest. |
| self.fetch_due_dates | Fetches all the due dates for the assignment or topic, then returns the sorted list of due dates. |
| self.any_future_due_dates? | Method that returns a boolean of whether there are any upcoming due dates left in the assignment or topic. |
| self.next_due_date | Calls the fetcher to retrieve all the due dates for an assignment, then returns the next upcoming due date. |
| set | Instance method used to update a due date's deadline type, assignment, and round. |
| copy | Instance method to copy all the due dates from one assignment or topic to another. |
TopicDueDate
| Reimplemented method | Description |
|---|---|
| self.next_due_date | Overloaded super method to first look for any upcoming topic due dates, and return the next one if so. If there are not any, it returns the next due date for the topic's assignment instead. |
Other changes
We did not reimplement these methods as they were unused and therefore obsolete
| Obsolete method | Description |
|---|---|
| self.teammate_review_allowed | Unnecessary method now that teammate_review_allowed is an attr_accessor |
| self.done_in_assignment_round | This determined the round that the due date was used in. Unnecessary as we can just grab the deadline_type_id directly from a due_date instance. |
| set_flag | Simple setter of the flag attribute. Not reimplemented as flag had not been used since 2015 and no one was really sure what it was used for. |
Project 4 Design Doc
Issues
1. Determining Late Submissions:
- There is a need to calculate whether submissions or reviews are late based on the due dates.
- Issue: The current system does not have a straightforward way to identify late submissions or track submission dates easily.
2. Handling Late Team Formation:
- Teams that form after the due date should incur a penalty.
- Issue: Team formation dates may not be explicitly tracked in the current system, or if they are, they are not used for penalty calculation.
3. Handling Review Penalties:
- Participants who fail to complete reviews on time should incur a penalty as well.
- Issue: Reviews are often tied to the response maps or individual participants, so there's a challenge in ensuring penalties are applied consistently across different models.
4. Penalty Application:
- The penalty calculation should be easily extensible, and transparent for debugging.
- Issue: Penalties may need to be applied in multiple places within the codebase, but should be kept modular and readable.
5. Code Maintainability and Readability:
- The code should remain maintainable as penalties could apply to more parts of the application in the future.
- Issue: Repeating penalty logic across models may lead to code duplication, increasing maintenance cost.
Proposed Solutions
A. Introduction of a PenaltyCalculator Mixin
- Solution: A new module `PenaltyCalculator` will be created to handle the penalty calculations. This module will contain methods for calculating submission, review, and team formation penalties.
- Benefit: It makes the penalty calculation logic reusable, keeps the code DRY, and ensures the logic is centralized.
B. Tracking Submission Dates
- Solution: Ensure that submission dates are explicitly tracked in the `Submission` model. Add a method to check if a submission is late based on the due date.
- Benefit: Provides a straightforward way to identify late submissions and apply penalties accordingly.
C. Tracking Team Formation Dates
- Solution: Use the team formation date in the `Team` model to track when a team is formed. Use this date to calculate penalties for late team formation.
- Benefit: Ensures that penalties for late team formation are applied consistently and accurately.
D. Handling Review Penalties
- Solution: Extend the `PenaltyCalculator` mixin to include methods for calculating penalties for late reviews. Ensure that review deadlines are tracked and used in penalty calculations.
- Benefit: Ensures that penalties for late reviews are applied consistently across different models.
E. Extensible Penalty Application
- Solution: Design the `PenaltyCalculator` mixin to be easily extensible, allowing new types of penalties to be added in the future. Use clear and transparent methods for debugging.
- Benefit: Keeps the penalty calculation logic modular and readable, making it easier to maintain and extend.
F. Code Maintainability and Readability
- Solution: Centralize the penalty calculation logic in the `PenaltyCalculator` mixin to avoid code duplication. Ensure that the mixin is included in relevant models where penalties need to be applied.
- Benefit: Reduces code duplication, making the codebase easier to maintain and ensuring that penalty logic is consistent across the application.
Implementation of PenaltyCalculator Module
module PenaltyCalculator
def calculate_penalty(submission_date, due_date, penalty_rate)
return 0 if submission_date <= due_date
days_late = (submission_date.to_date - due_date.to_date).to_i
penalty = days_late * penalty_rate
penalty
end
end
UML Diagram
Testing Plan
We primarily tested using automated testing through RSpec. Since due dates are a relatively self-contained structure, RSpec testing was more than sufficient for covering all testing scenarios. Here are some of our test cases:
Relevant Links
- Github Repository: https://github.com/akuldevali/reimplementation-back-end
- Pull Request: https://github.com/expertiza/reimplementation-back-end/pull/129
Team
Mentor: Dr. Ed Gehringer - efg@ncsu.edu
- Akul Devali - devali@ncsu.edu
- Pete Chopelas - pechopel@ncsu.edu
- Snehil Behar - sbehar@ncsu.edu