CompSci 308
Spring 2024
Advanced Software Design and Implementation

Lab Team Meeting: Preparing for Cell Society

In this lab, you will practice thinking about designing abstractions and designing a program before you have written any code, i.e., without worrying about exactly how it will be implemented. The result of this lab will be a set of documents that captures the important points of your team's several directed discussions.

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
    • areas of the project you interested/concerned about
  2. Discuss each person's team experiences and expectations:
    • share good and bad past team experiences and what you learned from them
    • share preferences and styles regarding expectations, communication, and debating/conflict
    • go over the Team Contract (which each person will submit individually)
    • choose a time for the next team meeting
  3. Practice designing Abstractions
  4. Practice designing without coding
  5. High-level project design
  6. Plan your project

For shared Markdown editing, you can work

Please complete each step before moving onto the next.

Practice Designing Abstractions: Breakout

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 how to create an inheritance hierarchy and to improve the overall code from two of the following kinds of classes:

For each abstraction (superclass), write the 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.

Describe your Abstractions, the commonalities and variations of the concrete subclasses, and their impact on the rest of the program in the file

Practice Designing Without Coding

Complete this exercise to think about describing the design of a program without actually writing any code in the file

This means focusing on which classes you will 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 (such as a specific data structure, the format and location of input files, or the exact layout and OpenJFX components needed).

In other words, without writing any actual implementation code, try to explore trade-offs between alternative designs and describe the best one in enough detail that another programmer has the freedom to implement it using any data structures or file format they want. 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 someone has to actually code each method.

High Level Design: Simulation

For this step, summarize your project ideas in the file

Discuss high level design ideas 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). Also discuss any issues or concerns anyone has about the project's specifications or goals.

Cellular Automata

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:

Consider the following questions:

Ideally, without any coding or requiring any specific implementation, try to explore trade-offs between several designs and to determine the best one to explore in detail (creating simplified UML style pictures can be helpful here).

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:

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 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.

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, sharedcellsociety_teamNN repository:

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