CompSci 308
Spring 2024
Advanced Software Design and Implementation

Cell Society : Change Implementation

Design, by nature, is a series of trade-offs. Every choice has a good and bad side, and you make your choice in the context of overall criteria defined by necessity. Good and bad are not absolutes, however. A good decision in one context might be bad in another. — Allen Holub

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


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 core classes closed to modification while open to extension by depending mostly on abstractions that hide the implementation details. Simply adding extra functionality 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.

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:

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).


Your team's project GIT repository must continue to show many, purposeful, commits from all team members with deliberate attempts to regularly integrate each other's work and refactor code rather than just one or two large "kitchen sink" commits and marathon merging or redesign sessions.

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.


Again, even though we will not practice more formal ways to automatically test your code until the next project, you should get in the habit of creating easily repeatable ways to validate your confidence in your code. This article provides guidance about “negative” testing, i.e., how to think about what kinds of input errors might occur when coming up with tests.

You must create at least 30 more simulation configuration files (for a minimum total of 60) that can be run to show your code works as expected.


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 each potential error checked for to prevent your program from crashing and how they are handled.