Cell Society Design Exercise

This exercise asks you to start the process of designing a program before you have written the code, i.e., before you have thought about exactly how it will be implemented. The key to this process is to think about high level behavior that you would like classes to implement, i.e., that would make it easier to do the project if they already existed, while being as abstract as possible, i.e., to give your team as much room to change your minds about the implementation when you have to actually code each method.

Lab Workflow

In your Cell Society teams, complete the following activities today:

1. Introduce yourselves by sharing:
• where you are and how you are experiencing school this semester
• your motivation/interest in this course
• your knowledge/interest in simulations or other software tools for visualizing data
• areas of the project you interested/concerned about
2. Read the Team Contract and share your previous team experiences to try to derive some positive/negative practices you think affect team work
3. Clone the shared team repository to each person's machine and Open the project in IntelliJ
4. Complete this exercise to think about describing the design of a program without actually writing any code
• Summarize the group's design RPS_EXERCISE.md using Gitlab's Markdown format
5. Review someone's Breakout project to find ways to use inheritance and polymorphism to improve the code
• Summarize the group's design GAME_EXERCISE.md using Gitlab's Markdown format
6. Discuss high level design ideas for Simulation without worrying about the details (a specific data structure, the format and location of input files, or the exact layout and OpenJFX components needed)
• Review multiple Cellular Automata and think about useful abstractions by considering their commonalities and variations
• Use CRC cards to refine your design, focusing more on the 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
• Summarize the group's design SIMULATION_EXERCISE.md using Gitlab's Markdown format
7. Choose a time for the next team meeting
8. If you have additional time, discuss and begin working on your team's Plan

For shared WYSIWYG Markdown editing, you can use

• this web-based, shared, editor (sign-in required)
• this web-based editor that can be plugged into Google Docs (regular synchronization required)
• this plugin to convert your already created Google Doc to Markdown

Submission

At the end of lab, push your markdown files to the doc folder of your team's provided, shared, cellsociety_teamNN repository to submit your notes about your teams' discussions.

• RPS_EXERCISE.md
• GAME_EXERCISE.md
• SIMULATION_EXERCISE.md

Make sure the text of your final commit message is of the form "lab_cellsociety_design - NetIDs".

Program Design

Design this program without worrying about exactly how it will be implemented. In other words, without writing any actual implementation code, explore trade-offs between alternative designs and describe the best one in enough detail that other programmers could implement it for you using any data structures or file format they want. The key is to focus on abstractions, i.e., superclasses, in your project that can have multiple concrete implementations, i.e., subclasses but specifically only on their behavior, i.e., methods, rather than state, i.e., instance variables. If done well, most of your code will be written using the abstractions without needing to know about specific implementations because they are substitutable.

Inheritance Review

Examine one person's Game project (preferably one that did not use inheritance) and discuss how to create an inheritance hierarchy from the following kinds of classes to close the Game class and clarify how to make the program open to adding new kinds of these objects:

• blocks
• power-ups
• levels
• others?

For each set of objects, write the method signatures (i.e., just the header not the implementation) the superclass would need to have to support all possible subclasses in the game and a comment describing what each method's purpose is. This defines the abstraction that represents all of those concrete examples and what other classes the abstraction must absolutely be dependent on.

Simulation High Level Design

Review each person's answers to the planning questions and try to come to a team consensus to start further discussions. Also discuss any issues or concerns anyone has about the specifications or goals of the project (see the Basic Implementation for more details if necessary).

Then consider the following questions as you discuss the basic design elements of the Simulation project. Write a high-level description of the different parts of the project and how they can interact without worrying about the implementation details.

1. How does a Cell know about its neighbors? How can it update itself without effecting its neighbors update?
2. What relationship exists between a Cell and a simulation's rules?
3. What is the grid? Does it have any behaviors? Who needs to know about it?
4. What information about a simulation needs to be the configuration file?
5. How is the graphical view of the simulation updated after all the cells have been updated?

A picture may be helpful to show how your parts are related to and dependent on each other.

Class-Responsibility-Collaborator Cards

Now that your team has thought about the problem generally, use CRC cards to refine your design and help you focus on interface instead of implementation issues. A CRC card is an index card (which nicely limits how much each class can do) that answers the following questions about a class to describe its behavior without getting into the details of how it implements that behavior. Index cards are also useful because they are easy to change and move around to see their relationship visually.

• What active behaviors is this class responsible for (i.e., not getters/setters)?
• What other classes are required to help this class fulfill those responsibilities?
  These other classes will either be passed to this object's constructor or methods, returned from a method, or created by this object internally.
  

Here are some examples of completed CRC cards. In these examples, the actions are given in English, not as a Java method signature (name, parameters, and return type). Your version must be written as a Java signature to provide more details about the flow of 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. 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. To make things more interesting, pair up with another team and try to do this part using their design.

• 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 file
• Switch simulations: use the GUI to change the current simulation from Game of Life to Wa-Tor

Here are some examples of completed Use Cases. In these examples, the steps are given in English, not as a Java method calls. Your version should be written as a sequence of Java method calls to provide more details about the flow of the program.