Cell Society : Design Document

Design makes ideas tangible so that they can be understood and evaluated before committing them to reality. — Christina Wodtke

This part of the project is intended to get you to try to design 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.

Specification

In a markdown formatted file, doc/DESIGN_PLAN.md, describe the primary classes (in packages if possible) you envision are needed to read in and represent a CA model and its simulation. Focus your design on how to represent a model in a general way and specifically on what behavior (i.e., methods) your classes would have. If describing an inheritance hierarchy, clearly identify what behaviors the classes have in common, the superclass, and what are different, the subclasses, rather than the instance variables.

In your design document, include 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). This section should discuss the program at a high-level (i.e., without referencing specific classes, data structures, or code).
• Overview
  This section serves as a map of your design for other programmers to gain a general understanding of how and why the program was divided up, and how the individual parts work together to provide the desired functionality. As such, it should describe specific components you intend to create, their purpose with regards to the program's functionality, and how they collaborate with each other. It should also include a picture of how the components are related (these pictures can be hand drawn and scanned in, created with a standard drawing program, or screen shots from a UML design program). This section should discuss specific classes, methods, and data structures, but not individual lines of code.
• User Interface
  This section describes how the user will interact with your program (keep it very simple to start). It should describe the overall appearance of program's user interface components and how users interact with these components (especially those specific to your program, i.e., means of input other than menus or toolbars). It should also include one or more pictures of the user interface (these pictures can be hand drawn and scanned in, created with a standard drawing program, or screen shots from a dummy program that serves as a exemplar). Finally, it should describe any erroneous situations that are reported to the user (i.e., bad input data, empty data, etc.). This section should go into as much detail as necessary to cover all your team wants to say.
• Design Details
  This section describes each component introduced in the Overview in detail (as well as any other sub-components that may be needed but are not significant to include in a high-level description of the program). It should describe how each component handles specific features given in the assignment specification, what resources it might use, how it collaborates with other components, and how each could be extended to include additional requirements (from the assignment specification or discussed by your team). Include the steps needed to complete the Use Cases below to help make your descriptions more concrete. Finally, justify the decision to create each component with respect to the design's key goals, principles, and abstractions. This section should go into as much detail as necessary to cover all your team wants to say.
• Design Considerations
  This section describes any issues which need to be addressed or resolved before attempting to devise a complete design solution. It should include any design decisions that the group discussed at length (include pros and cons from all sides of the discussion) as well as any assumptions or dependencies regarding the program that impact the overall design. This section should go into as much detail as necessary to cover all your team wants to say.
• Team Responsibilities
  This section describes the program components each team member plans to take primary and secondary responsibility for and a high-level plan of how the team will complete the program.

Use Cases

The following scenarios are provided to help test the completeness and flexibility 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.

• 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
• Set a simulation parameter: set the value of a parameter, probCatch, for a simulation, Fire, based on the value given in an XML fire
• Switch simulations: use the GUI to change the current simulation from Game of Life to Wator