CS371p: Object-Oriented Programming

• Spring 2026: 53370 (77)
• 12 Jan - 27 Apr 2026
• MWF 1 pm: GDC 1.304
• https://gitlab.com/gpdowning-ut/cs371p/
• https://www.cs.utexas.edu/~utpc/

Project #5: Life

---

• Due: Wed, 22 Apr, 11:59 pm
• Issues: adapt Collatz.csv into Life.csv

Specification

---

• Write a program, ideally with a partner, to solve Life [C++23 (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

README.md

---

• Profile
  • Full Name
  • EID
  • GitLab ID
  • GitLab URL
  • GitLab Pipeline
  • Git SHA
  • HackerRank ID
  • Estimated completion time
  • Actual completion time
  • Comments
• 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."

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
• Canvas doesn’t support submitting Markdown files.
• So, make a copy of README.md into README.md.txt.
• Your README must contain your AI Report.
• Submit README.md.txt to the Canvas assignment.

Repos

---

• HackerRank Contest: https://www.hackerrank.com/cs371p-spring-2026-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 © cs371p, 1995-2026
Updated 8 Apr 2026