Cell Society : Design Plan

Every time you believe there’s only one way to accomplish your goal, question that belief. — Martin Fowler

This part is intended to get you to try to think about the design of a program without specifying about exactly how it will be implemented. In other words, you should explore a design in enough detail to convincingly describe the primary classes (and any significant supporting classes you think are necessary) that will work together to provide the project's functionality without writing any implementation code.

Take this time to get everyone on the team to start with a similar understanding.

No running code is required for this submission.

Specification

Describe the primary classes you envision are needed to represent the program's basic functionality. Focus your design on how to represent a simulation model in a general way and specifically on what behavior (i.e., methods) your classes would have instead of focusing on the instance variables. If describing an abstraction (i.e., an inheritance hierarchy), clearly identify what behaviors the classes have in common (i.e., the superclass), and what are different, (i.e., the subclasses).

In your doc/DESIGN_PLAN.md document, complete the following sections:

• Introduction
  This section describes the problem your team is trying to solve by writing this program, the primary design goals of the project (i.e., where is it most flexible), and the primary architecture of the design (i.e., what is closed and what is open). Discuss the program at a high-level (i.e., without referencing specific classes, data structures, or code).
• User Interface
  This section describes the overall appearance of program's user interface and how the user will interact with your program (keep it very simple to start). Include one or more pictures of the user interface and describe any possible erroneous situations that should be reported to the user (i.e., bad input data, empty data, etc.). These pictures can be hand drawn and scanned in, created with a standard drawing program (such as Figma or PowerPoint), ExcaliDraw (a Markdown-oriented drawing tool!), or screen shots from a dummy program that serves as a exemplar.
• Configuration File Format
  Configuration files will use the standard XML format that can be parsed automatically by Java, but the exact tag names and attributes you use within this file are up to your team. Create at least two example files to help the team agree on the information represented (such as number of tags, using attributes vs. elements, and other internal formatting decisions). Note, your examples do not need to be exhaustive, just representative of the file's format.
• Design Overview
  This section describes the abstractions you intend to create, their purpose with regards to the program's functionality, and how they collaborate with each other. Include a picture of how the modules are related (these pictures can be hand drawn and scanned, saved from an online CRC card tool, written in Markdown, created with a standard drawing program, or screen shots from a UML design program). Note, it is very common that much discussion will focus primarily on class and method names!
• Design Details
  This section describes each abstraction introduced in the Overview in detail (as well as any other concrete classes that may be needed but are not significant to include in a high-level description of the program). Describe how each handles specific Functionality Requirements, how it collaborates with other classes, and what resources it might need. Describe in detail how your method signatures do not reveal the difference between two different implementations for your data structure, file format, and OpenJFX "grid" component.
• Design Considerations
  This section justifies your team's reasoning for the classes and methods given in the design, including alternatives considered with pros and cons from all sides of the discussion. Describe in detail at least two design issues your group discussed at length (even if you have not yet resolved it), including pros and cons from all sides of the discussion and the alternate design options considered.
• Use Cases
  Describe how your classes work together to handle being extended or specific features (like collaborating with other classes, using resource files, or serving as an abstraction that could be implemented multiple ways). In addition to the cases below, write at least two Use Cases per person to further test your design (they should be based on features given in the assignment specification, but should include more details to make them concrete to a specific scenario). Then, include the Java psuedocode needed to complete all the Use Cases to help validate and make your design plan more concrete.
• Team Responsibilities
  This section describes the parts of the program each team member plans to take primary and secondary responsibility for and a rough schedule of how the team will complete the program.

This plan is not intended to be completely binding, but significant changes will be penalized. This is not meant to over-stress this process or squash your later creativity, just to note that if you end up throwing out the plan completely, then it is not clear you thought about the project in enough detail to make basic critical choices.

Any changes to this plan should be addressed in your final DESIGN document (adding descriptive comments while you write the code for it can be helpful for remembering your thought process and other details about the change so you can explain it later).

Use Cases

The following scenarios are provided to help test the completeness of your design. By writing the steps needed to complete each case below you will be able to see how effectively your design handles these scenarios and others will be able to better understand how deeply you have considered the basic issues. It may help to role play or draw a diagram of how your classes collaborate to complete each case. For this exercise each step, try to include both the class used and the method used to accomplish the step.

Clearly show the flow of calls to public methods described in your design needed to complete each example below, indicating in some way which class contains each method called (you do not have to implement any of the called functions.):

• Apply the rules to a middle cell: set the next state of a cell to dead by counting its number of neighbors using the Game of Life rules for a cell in the middle (i.e., with all its neighbors)
• Apply the rules to an edge cell: set the next state of a cell to live by counting its number of neighbors using the Game of Life rules for a cell on the edge (i.e., with some of its neighbors missing)
• Move to the next generation: update all cells in a simulation from their current state to their next state and display the result graphically
• Switch simulations: load a new simulation from a data file, replacing the current running simulation with the newly loaded one
• Set a simulation parameter: set the value of a parameter, probCatch, for a simulation, Fire, based on the value given in a data file

Resources

• CRC Cards: A Laboratory For Teaching Object-Oriented Thinking by Kent Beck and Ward Cunningham
• Writing Effective Use Case Guidelines from Alistair Cockburn (pronounced [Co-burn] the Scottish way)
• XML - Managing Data Exchange, an open Wikibook