Lab Team Meeting: Preparing for Cell Society

In this lab, you will practice thinking about designing abstractions and designing a program without writing code, i.e., without worrying about exactly how it will be implemented (i.e., a specific data structure or the format and location of input files).

In your Cell Society teams, complete the following steps:

1. Introduce yourselves by sharing:
• your background and how you are doing in general this semester
• your motivation/interest in this course
• your knowledge/interest in simulations or other software tools for visualizing data/algorithms
• areas of the project you interested/concerned about
2. Discuss each person's team experiences and expectations:
   • share a good and bad past team experiences and what you learned from them, specifically:
     • how did your expectations about the project impact the outcome or conflicts with others?
     • how did the amount of communication help or hurt project progress?
     • what do you think helps or hurts the success of a team meeting?
     • how did you help someone or ask for help during the project?
   • share your beliefs regarding deadlines, communication preferences, and debating/conflict style
   • go over the Team Contract (which each person will submit individually)
   • choose a time for the next team meeting
3. Practice designing abstractions
4. High-level project design
5. Plan your project

The result of this lab will be a set of Markdown documents that capture just the important points of your team's several discussions. For shared Markdown editing, you can work directly within IntelliJ using the Code With Me feature or it can be enabled directly within Google Docs.

To help you focus on classes to create, what methods they will have, and what objects will be passed into and out of those methods — without worrying about exactly how each class or method will be implemented, use the following tools:

• CRC cards to refine your design, focusing more on the interactions between classes than their implementation
• 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

Complete each step before moving onto the next.

Practice Designing Abstractions: Breakout

For this step, summarize your discussion in the file BREAKOUT_EXERCISE.md.

Abstraction is a key design element because it allows you to clarify how to add new behavior to the program (create new subclasses) and simplify methods in classes that use the abstraction (call the superclass methods). This allows you to more easily separate and hide implementation details and thus limit their impact on the overall project.

Examine one person's Breakout project (preferably one that did not use inheritance) and discuss the commonalities and variations among the different functionalities. Create an inheritance hierarchy that improves the code's design for two of the following kinds of classes:

• blocks
• power-ups
• levels
• others?

For each abstraction (superclass), create a CRC Card that includes method signatures (i.e., just the header not the implementation, whether or not they are abstract methods) needed to support all possible subclass functionalities and a comment to describe each method's purpose. The key to good design is to focus on these abstraction's behavior, i.e., methods, rather than state (instance variables). If done well, most of your code will be written using the abstractions without needing to know about specific implementation details because they are substitutable.

High Level Design: Simulation

For this step, summarize your discussion in the file CA_EXERCISE.md.

Each person should examine one of the following Cellular Automata and describe it to the rest of the team, then discuss collectively what might be common and what might vary across a typical simulation:

• Conway's Game of Life
• Spreading of Fire
• Schelling's Model of Segregation

Consider the following questions:

• 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?
• What information about a simulation needs to be in the configuration file?
• How is configuration information used to set up a simulation?
• How is the graphical view of the simulation updated after all the cells have been updated?

Then use CRC Cards to brainstorm ideas for classes and abstractions for the Cell Society project without worrying about the details (a specific data structure, the format and location of input files, or the exact layout and OpenJFX components needed).

One of the strengths of object-oriented design is creating objects model corresponding objects from the real world. However the best way to make an effective class is to "anthropomorphizing" it, i.e., to give it human characteristics and responsibilities — this is often what helps to distinguish a good object-oriented design (a group of intelligent objects collaborating together) from a bad one (a group of passive objects coordinated by a manager object). Focus on the behavior (methods) that you would like the classes to implement, i.e., that would make it easier to do the project if they already existed, rather than the state (instance variables) and try to make each behavior as general as possible, i.e., give coders as much room to change their mind about the implementation when they have to actually writing each method.

Appendix

Class-Responsibility-Collaborator Cards

After thinking about a problem generally, many people find CRC cards useful to describe a Object-Oriented design because they help show the objects more conceptually and the logical relationship between objects more explicitly, making it is easier to understand, evaluate, and modify a design. Using index cards to represent each class card nicely limits how much a class can do and easily allows you to change them and move them around to see their relationship visually. This style also helps you focus on making smart/anthropomorphic classes by answering the following questions for each:

• What active behaviors is this class responsible for (rather than get/set methods)?
  These are the public methods other objects can call on this one without knowing how it implements that behavior.
• 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 itself.
  

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 of your design. By writing the steps needed to complete each Use 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.

• 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

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 calls to only those Java methods on your CRC cards to provide more details about the flow of the program.

To make things more interesting, pair up with another team and try to do this part using their CRC cards!

Submitting your Work

At the end of lab, push your team's Markdown files to the doc folder of your provided, shared, cellsociety_teamNN repository:

• BREAKOUT_EXERCISE.md
• CA_EXERCISE.md

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