CS371p: Object-Oriented Programming

• Fall 2025: 55075 (55)
• 25 Aug - 8 Dec 2025
• MWF 1 pm: GDC 1.304
• https://gitlab.com/gpdowning-ut/cs371p/

Project #5: Life

---

• Due: Wed, 3 Dec, 11:59 pm
• Issues: adapt Grades.csv into Life.csv

Specification

---

• Write a program, ideally with a partner, to solve Life [C++20 (g++ 14.2.0, 2 sec, 512 MB, source 50 KB)]
• Life is a simple simulation of cell automata.
• Life contains a two-dimensional grid of cells. A cell can only be in one of two states: alive or dead. There are two kinds of cells: ConwayCells and FredkinCells.
• Once the grid is manually populated with live and/or dead cells, the grid represents the 0th generation of Life. After that, everything is automatic, and Life evolves from the 1st to the Nth generation. A generation is simply the state of the grid (i.e. the layout of the live and dead cells).
• Live ConwayCells are denoted with an asterisk, "*", and dead cells are denoted with a period, ".". A ConwayCell has 8 neighbors, if it's an interior cell, 5 neighbors, if it's an edge cell, and 3 neighbors, if it's a corner cell. The example below is of 1 ConwayCell that is alive surrounded by 8 ConwayCells that are dead:

    ...
    .*.
    ...
			

• ConwayCells do not have the notion of age, FredkinCells do. A FredkinCell's age is initially zero and only increments by one if the cell is alive and stays alive. Its age never goes down.

• Live FredkinCells are denoted with their age, if their age is less than 10, otherwise denoted with a plus, "+", and dead cells are denoted with a minus, "-". A FredkinCell has 4 neighbors, if it's an interior cell, 3 neighbors, if it's an edge cell, and 2 neighbors, if it's a corner cell. The example below is of 1 FredkinCell that is alive and of age 5 surrounded by 4 FredkinCells that are dead:

      -
    - 5 -
      -
			

• The rules for going from one generation to the next for ConwayCells are:

• a dead cell becomes a live cell, if exactly 3 neighbors are alive
• a live cell becomes a dead cell, if less than 2 or more than 3 neighbors are alive

• The rules for going from one generation to the next for FredkinCells are:

• a dead cell becomes a live cell, if 1 or 3 neighbors are alive
• a live cell becomes a dead cell, if 0, 2, or 4 neighbors are alive

• You will define the following classes:

• AbstractCell, an abstract class that is the base class of class ConwayCell and class FredkinCell
• Cell, a handle class that manages derived class objects of class AbstractCell
• ConwayCell, a concrete class
• FredkinCell, a concrete class
• Life<T>, a concrete class

• Life will be instantiated with either ConwayCell, FredkinCell, or Cell.
• If Life is instantiated with Cell, then when a FredkinCell's age is to become 2, and only then, it becomes a live ConwayCell instead.

• Create a good object-oriented design with no getters and setters by writing well-defined classes that are responsible for a specific and modular part of the solution:
• Read Getters and Setters and More on Getters and Setters
• Create a UML diagram to represent the design. Use any UML editor that you like. The diagram needs to show data members, methods, associations and multiplicity between the classes.
• Use Gliffy, PlantUML, yUML, or something else.
• You may not use new, delete, malloc(), free(), or allocator. You may use the STL.
• An exception is that you can use new/delete to construct ConwayCell and FredkinCell objects when you construct Cell objects and in clone and mutate.

Analysis

---

• Live Mint
• MathWorld
• Wikipedia
• YouTube

Submission

---

• create a private code repo (https://gitlab.com/GitLab-ID/cs371p-life/)
• enable issues here: Settings -> General -> Visibility, project features, permissions -> Issues
• create the following issue labels here: Manage -> Labels (labels are case sensitive):
  • correctness (Crimson)
  • build_files (Blue-gray)
  • issues (Dark coral)
  • unit_tests (Green-cyan)
  • acceptance_tests (Dark sea green)
  • continuous_integration (Carrot orange)
  • code (Titanium Yellow)
  • documentation (Lavender)
  • ai_report (Deep violet)
• import the issues: Issues -> Import issues -> Import CSV
• close all issues
• add and close new issues as you debug and optimize your solution
• provide your GitLab URL on the Canvas assignment

AI Report

---

• Summary of AI Interactions
  • List the tools used (e.g., ChatGPT, Copilot, etc.).
  • Debugging help (error explanation, bug location, runtime issue)
  • Conceptual clarification (CS concept, syntax, algorithm idea)
  • Code improvement (style, efficiency, readability, testing)
  • Alternative approaches (asking “is there a simpler way?”)
  • Other (describe)
• Reflection on Use
  • What specific improvements to your code or understanding came from this AI interaction?
  • How did you decide what to keep or ignore from the AI’s suggestions?
  • Did the AI ever produce an incorrect or misleading suggestion? How did you detect that?
• Evidence of Independent Work
  • Paste a before-and-after snippet (3–5 lines max) showing where you changed your own code in response to AI guidance.
  • In 2–3 sentences, explain what you learned by making this change.
• Integrity Statement
  • "I confirm that the AI was used only as a helper (explainer, debugger, reviewer) and not as a code generator. All code submitted is my own work."

Repos

---

• HackerRank Contest: https://www.hackerrank.com/cs371p-fall-2025-life/
• GitLab public test repo: https://gitlab.com/gpdowning-ut/cs371p-life-tests/
• GitLab private code repo: https://gitlab.com/GitLab ID/cs371p-life/

Rubrics

---

Copyright © Glenn P. Downing, 1995-2025
Updated 18 Nov 2025