CompSci 308
Spring 2024
Advanced Software Design and Implementation

SLogo : Change Implementation

Clean code is not written by following a set of rules. You don’t become a software craftsman by learning a list of heuristics. Professionalism and craftsmanship come from values that drive disciplines. ― Robert C. Martin

This part is intended to emphasize the project Design Specification by introducing new features that challenge assumptions you may have made in your Basic version.

Changes

Build on your Basic version to add these variations to each part in a thoughtful manner that clearly shows the intentions of your design goals and avoids duplicate code structures. The best strategy is to make your APIs closed to modification while open to extension by depending mostly on abstractions that hide the implementation details. Simply adding extra functionality by substantially changing your APIs, not related to an abstraction or adding poor code that exposes implementation details, adds special case conditionals, hardcodes values, or otherwise diminishes the rest of your design efforts will not be rewarded.

Refactor and implement as much variety as you can to clearly demonstrate your design supports further such extensions. If you are not able to implement a variation, you must still be able to justify that your overall design handles adding it in an intentionally well designed manner in your DESIGN document.

The full list of new functional requirements is given here. The design requirements remain the same.

API Changes

At the beginning of this project your team defined three APIs (one External, two Internal). For most of you this was your first time intentionally designing an API and you also did not know a lot about the project you were building. We have given you some flexibility in changing your initial APIs since you have also learned new Java techniques that you may have incorporated into your design. However, at this point, your APIs should, as much as possible, not be changed without deliberation because it affects how the other's code might work.

If a method must be changed, the original version must be marked as deprecated, and the change and its reasons must be described in a separate file, doc/API_CHANGES.md.

Design Issue Report

We have used Gitlab's CI Pipeline to analyze your code each time you push it and generate a report to help you find easily detectable design issues. Note, this analysis in no way guarantees your code is well designed, it only brings obvious potential flaws to your attention. For example, it is an obvious design flaw to have public instance variables, but you can still have a bad design even if all of your instance variables are private.

You can access the report by visiting your project repository hosted in the course's Gitlab group and clicking on the red "X" or green check mark above your list of files (next to the Hex ID of the latest commit). On the next page, click on the "Code Quality" tab to show the list of issues found in the project code. The URL of the resulting page should look like this:

https://coursework.cs.duke.edu/compsci308_2024spring/slogo_teamNN/-/pipelines/NN/codequality_report

While you are not required to remove all issues found, you should be prepared to justify why you left significant issues in your code (e.g., with comments near the lines flagged as issues in any of the reports).

GIT

As usual, your team's project GIT repository should continue to show many, purposeful, commits from all team members. Specifically, we will be looking for deliberate attempts to regularly:

Everyone must push at least four commits that show the results of refactoring existing code to improve its design, with a commit message that references the Design Requirement ID represented by the code change.

README

In addition to organizing your code according to the Submission Guidelines and documenting your code, complete your README file — especially documenting your assumptions about the functional requirements and attributions for any images or resources you used.

Also, describe your choices regarding the SLogo language semantics and each potential error checked for to prevent your program from crashing and how they are handled.