Exercise: Project Planning

This exercise is intended for you to start designing your project without worrying about how it will be implemented. Begin to discuss the major design issues and possible abstractions that can work together collaboratively before implementing any functionality.

As a team, complete the following activities:

• Review multiple Cellular Automata and think about useful abstractions by considering their commonalities and variations
• Discuss your understanding of the Open-Closed Principle and the Interface Separation Principle and how they might apply to this project or how it might have applied to the OOLALA project
• Use CRC cards to find a set of classes to represent your design, focusing on the behavior and interactions between classes than their implementation
• Use Use Cases to verify the completeness and flexibility of your design, by writing "example code", a sequence of method calls from those on your CRC cards

Add notes and summarize important points from your discussion in the Markdown file LAB_DESIGN.md file to submit your work.

Discussion

Each person should examine one Cellular Automata simulation that needs to be implemented in detail and describe it to the rest of the team, then discuss collectively the ways in which they are common and how they vary across a typical simulation.

Consider the following questions as you discuss the basic design elements of the project:

• How does a Cell know what rules to apply for its simulation?
• How does a Cell know about its neighbors?
• How can a Cell update itself without affecting its neighbors update?
• What behaviors does the Grid itself have?
• How can a Grid update all the Cells it contains?
• How is configuration information used to set up a simulation?
• How is the GUI updated after all the cells have been updated?

Think abstractly about what represents the core Model objects needed to support a grid of cells. Remember to keep the following in mind:

• How will you represent basic concepts?
• How will you hide specific implementation choices of your classes in the public methods?
• How will you keep the Model and View separate?

Before deciding on any specific classes or implementations, explore trade-offs between multiple designs and summarize your conclusions. Importantly, envision at least two different implementations to make sure your design does not reveal the specifics of either one.

Design Principles

All too often code is written that does not demonstrate the designers intentions well or that is hard to change, fragile, and non-reusable. Design Principles can help you manage dependencies well so that the code remains flexible, robust, and reusable, which should help make your design goals clearly visible in your code.

• Each person should share their experience with the Open-Closed Design Principle and how it guided code design choices (or not). In what ways do you see it applying to this project?
• Each person should share their experience with the Dependency Inversion Principle and how it guided code design choices (or not). In what ways do you see it applying to this project?
• Each person should share their interpretation of the Interface Separation Principle and how it might have guided code design choices (or did before you had a name for it). In what ways do you see it applying to this project?

Designing your Classes

Now that your team has thought about the problem generally, refine your discussion into an Object-Oriented design by identifying specific abstractions and their behaviors (i.e., methods) instead of implementation details (i.e., instance variables, data structures, file formats, etc.).

• Use CRC cards for each class you want to describe in more detail.
  Write your version using full method signatures to provide more details about the required information.
• Use these Use Cases to help test the completeness and flexibility of your design.
  Write your version as a sequence of Java method calls to provide more details about the flow of information.
  • Apply the rules to a 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 of its neighbors)
  • Move to the next generation: update all cells in a simulation from their current state to their next state
  • Switch simulations: load a new simulation from a data file, replacing the current running simulation with the newly loaded one

To make things more interesting, pair up with another team and try to implement the Use Cases using each other's CRC Cards! Or show your progress to a UTA when you think you are finished to get immediate feedback.