Department of Computer Science CMPT 145

176 Thorvaldson Building Spring/Summer 2023

110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Assignment 6
Inheriting Conway

Date Due: August 17th, 2023, 11:59pm Total Marks: 67

General Instructions

• This assignment is individual work. You may discuss questions and problems with anyone, but
the work you hand in for this assignment must be your own work.

• Assignments are being checked for plagiarism. We are using state-of-the-art software to com-
pare every pair of student submissions.

• Each question indicates what to hand in. You must give your document the name we prescribe
for each question, usually in the form aNqM, meaning Assignment N, Question M.

• Make sure your name, NSID, student number and course number aappear at the top of every
document you hand in. These conventions assist the markers in their work. Failure to follow these
conventions will result in needless effort by the markers, and a deduction of grades for you.

• Do not submit folders, or zip files, even if you think it will help. Unless given permission to do so.
It might help you, but it adds an extra step for the markers.

• Programs must be written in Python 3, unless question states otherwise.

• Assignments must be submitted to Canvas. There is a link on the course webpage that shows
you how to do this.

• Canvas will not let you submit work after the assignment deadline. It is advisable to hand in
each answer that you are happy with as you go. You can always revise and resubmit as many
times as you like before the deadline; only your most recent submission will be graded.

• You may only use methods and modules explained in class, unless explicitly told otherwise. If you
wish to use another module first check with the professor.

• Read the purpose of each question. Read the Evaluation section of each question.
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Question 1 (49 points):

Purpose: Reflect on previous code and design decisions after some time has passed. Encourage pro-
gramming for the future.
Degree of Difficulty: Moderate

Within this course the statement "code for whomever comes next" had been said providing, TAs and your-
self in the future as examples. Now you get to examine what your previous self has coded and reflect on
the this idea.

RECALL Assignment 1 Question 3, parts A and B have already been completed by you. The parts A and B
are merely here to remind you what was expected. The code itself is not the primary focus the reflection
and critical thinking is what matters. Within this assignment question you will be expected to complete
only parts C and D.
Now using your original submissions reflect on the previous design and code, and extend Conway’s Game
of Life even further.
Conway’s game of life, aka Game of Life, aka Life is a zero player game developed by the British mathe-
matician John Horton Conway in 1970. The game’s evolution is determined by its initial state and requires
no further input. One interacts with the game by setting up the initial input, and observing how the input
evolves.

On a grid every cell interacts with its neighbouring cells; a cell is either alive ("*") or dead("-"). At each “Time
Step” (iteration) that occurs the following transitions are possible;
• Any living cell with less than 2 neighbours dies of loneliness.
• Any living cell with 2 or 3 neighbours remains alive.
• Any living cell with more than 3 neighbours dies of claustrophobia.
• Any dead cells with exactly 3 neighbours become alive, rising from the ashes like a phoenix.
Your task is to implement this game.

Note this is with diagonal neighbours counted.

Page 2
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Initial Specification Clarifications

These are the minimum requirements for your solution.
• Initially the grid will be either 1x1, 2x2, or 3x3.
• Initially only consider orthogonal neighbours; ie up, down, left, right.
• Initially only 1 “time step” (iteration) is required.
• It must be possible to read in the initial state from a file (see the examples).
• The updated state should be saved to a new file with the same name as the input file followed by an
underscore aand the amount of steps that have occurred.
Example: “nxn_updated.txt”, where n is the size of the grid.
• The way the game should be run is with a function called conway(input_textfile), that takes in a
string that is the file name of the input text file.
Note: this does not mean you cannot have other functions (you are strongly encouraged to have other
functions). It merely means this is how the program will begin its execution.

Expansion Specifications
These are the expanded requirements your solution must be able to satisfy.
• The grid can be a rectangle of any size.
• Consider all adjacent neighbours; up, up right, up left, down, down right, down left, left, and right.
• It must be possible to read in the initial state from a file (see the examples).
• The user will pass in an input file as an argument to the python script and the desired amount of
itterations (steps)
Example: python3 conway.py input4.txt 5
• The user will pass in the number of steps that should occur or else the default will be 3.
• The use should be asked if they also wish to see the results in the console.
If yes each step should be easily identifiable if no there should still be a way to let the user know when
the program is complete.
• The updated state should be saved to a new file with the same name as the input file followed by an
underscore and the amount of steps that have occurred.
Example: input1_nsteps.txt, where input1 was the original name and n is the number of itterations
that have occurred.
• Original rules related to cells being alive or dead still apply.
• Zombie Cells - cells that were initially dead but come back to life will now be denoted with a "Z".
• Zombie Cells can now infect neighbouring living cells after the cell has been a zombie for 1.
• The Zombie Cells are still considered "living" for the rules of the game only their symbol has change.

Page 3
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Part A - Design Plan

The purpose of Part A is to encourage people to think before they code.

Write a design document in a markdown file (.md), markdown is a markup language. Typically markup
languages are used to control the display of a document or enrich the context of the document. Markup
languages are a set of rules governing what markup information may be included in a document and how it
is combined with the content of the document in a way to facilitate use by humans and computer programs.

Within your design document consider what options you have before you, consider the pros and cons of
the different options. Consider what assumptions you’re making and wha dependencies exist. What are
the goals of your code? How do you plan to accomplish your goals? Document design decisons and how
you plan to solve the problem.
Remember an important part of computer science is breaking up a big problem into easier to manage
sub-problems. As you write this document, COMMIT THROUGHOUT THIS PROCESS.

Part A - Your Tasks

1. Prior to coding
• Document how you plan to implement your solution.
• Document design decisions and ideas, and why you are making the choice you’re making, what
other options were considered,
• Within the choices made address your consideration to the software goals; Correctness, Effi-
ciency, Robustness, Adaptability and Reusability.
2. After creating your design plan, answer the following
• How do I know the program will work correctly?
• What situations may break my program?
• Are there ways to make the program more efficient? (This one may be difficult to recognize right
now, but even saying “I am unsure“ shows the question has been considered.)
• Have I made choices that reduce future adaptability?
• Which parts of this program might be useful in another project?
3. As you are doing the test driven development, and implementing your code document
• Design decisions you’ve changed and why you’ve changed them.
4. After you have completed your code answer the following.
5. What assumptions are you making?
• How did you allow your code to be extendable?
• What of your design plan was accomplished and what was left unfinished?
• What risks or bugs currently exist in your code?
• Where do might issues exist? If there was more time how would you solve them?
• If there was more time what else would you consider doing?

Page 4
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Part B - Test Driven Development

Mini Purpose: Recognize the importance of testing, and recognizing different forms of testing.

COMMIT THROUGHOUT THIS PROCESS.

Test-driven development (TDD) is a software design strategy, use your design plan from Part A of this ques-
tion. Follow the TDD process based on the principles within your textbook.

An important aspect of this will be having an easy way to make sure as your tests increase and your code
increases you’re also making sure that previous test cases continue to pass (regression testing).
Make sure you are able to test multiple test cases without a user needing to compare and contrast print
statements on a terminal.
To do this keep in mind chapter 7 of the textbook, and the importance of test scripts, aka test drivers. Au-
tomating tests so you only need to worry if tests have failed or what tests were unsuccessful can assist
in determining where errors may exist. A test should contain input, output, and the purpose of the test.
You can go further with your testing by grouping together tests that are related to a specific function or
element of your code. However, so long as your test cases are easy to understand and readable this is not
mandatory.

Consider how the different aspects of your code will interact with each other when writing test cases (in-
tegration testing).
Rather than having both your tests and your implementation code within the same file, you are required to
have your tests within a separate python file that imports the file containing your implementation of Con-
way’s Game of Life.

Part B - Your Tasks

Using TDD implement Conway’s Game of Life.
Do not forget Part A’s final questions and do not forget to commit.

Page 5
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Part C - Retrospective
You are now looking at this code months after it has been written rather than minutes.

COMMIT THROUGHOUT THIS PROCESS

Within a text file reflect on your design document and the your initial code. Keep in mind the extensions
that we wish to add, and our design and implementation goals.
1. Reflecting on your design document, the implementation and the testing:
• What lacks clarity, or is hard to understand now?
• Identify places where you forgot details
Example: How things worked, what variables intended purpose was, why decisions were made,
etc.
• Recognize the flaws within your code. Why do they exist? Provide Examples.
Examples: where code was brittle, inflexible
• Recognize the strengths within your code, what was flexible, or is easy to expand?
2. Based on the new specifications examine your original code through the software design and imple-
mentation goals.
For each goal what was done well, and what could be improved upon (unless no code is changed
both should be addressed, with examples.)
• Correctness
• Efficiency
• Reusability
• Adaptability
• Reliability
3. While expanding your code
• Document what needed to be changed, how much "cost" (time and effort) will these changes
require, why must the change occur?
• What within the code still works with the extended constraints?
• Document known bugs/ risks/ and errors at the time of submission.
4. Based on this retrospective and what you’ve expanded;
• What obstacles did you encounter, how can you reduce them going forward?
• What can mistakes will you try and avoid in the future?
• What lessons from can you take forward for future code you create?
• How can you improve?

Page 6
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Part D - Update the code

Make sure you keep a copy of your original work and a copy of your changes. Update your code with the
new constraints in mind, as you expand your code you must update your testing as needed.
Remember to commit as you go. Your commits should also be documenting what changes occurred and
why.
Testing should not be print statements, if your testing is print statements you will get a 0.

What to Hand In
• Part C - The retrospective should be named a6q1_retrospective.txt
• Part D - The updated implementation should be named a6q1.py
• Part D - The updated test file should be named a6q1_testing.py
• A gitlog associated with the assignment as a whole named a6.log. Clearly identify commits made for
each question. Examples:
 
A # Q # - Commit Title
A # Q2 - Added provided files for question # to repo
A # Q4 - Implemented function _____ to allow
for ______ to pass .
 

Be sure to include your name, NSID, student number, course number and section number at the top of all
documents (including your git log).
WARNING: Marks can be deducted if instructions are not followed, or if the answers are not legible.

Evaluation
WARNING: Marks can be deducted if instructions are not followed.
WARNING: If resources not identified you risk getting 0 for this assignment question.
• 29 marks: Part C
– Evidence of critical analysis of the original works as whole must occur to get marks.
– 8 marks: Reflection on the original work (2 marks for each sub-question)
* 1 mark: The answer mark for the reasoning
* 1 mark: At least 1 example.
– 15 marks: Software design and Implmentation goals (3 marks for each goal)
* 1 mark: Justification of something done well (relating to the goal).
* 0.5 marks: Example of something done well (relating to the goal).
* 1 mark: Justification of something that could be improved upon (relating to the goal).
* 0.5 marks: Example of something that could be improved upon (relating to the goal).
– 3 marks: Expanding the code - Documenting changes made to your code and why.
– 3 marks: Key takeaways
* 2 marks: Lessons learned and why (at least 2).
* 1 mark: Things to work on/ avoid in the future and why.
• 20 marks: Part D.
– 18 marks: 0.5 marks for Implementation 1.5 marks for Testing

Page 7
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

* 2 marks: Flexible grid size.

* 2 marks: The amount of neighbours is updated.
* 2 marks: Taking in as the first argument to the python file the input textfile and the number of
steps as the second argument.
* 2 marks: If number of steps not present defaults to 3.
* 2 marks: Asking user if they should print all steps to the console. Steps and/ or program
complete easy to identify.
* 2 marks: File appropriately read in and updated.
* 2 marks: Original rules still behave correctly.
* 2 marks: "Zombie Cells" now denoted with a "Z".
* 2 marks: Zombie cells after 1 step target neighbours
– 2 marks: Good Commit messages
* Identify what the commit is intended for in relation to the assignment as a whole.
* Commits should not be atomic not lumped all together.
* Document what’s changing and why.

Further Resources
• Wikipedia - Conways Game of Life
• Play Game of Life
• Part A Resources
– Please note that no singular method is best for writing your design document instead these are
ideas of what to consider including within your design document.
– Berkely - How to Write a Design Document
– Free Code Camp - How to write a good software design doc
– BIT.AI Blog - Software Design Document: What it is & How to Create it!
– Markdown Guide Cheatsheet
– Github Markdown Cheatsheet
– Wikipedia - Markup Languages
• Part B
– Spiceworks - What is regression testing
– Guru99 - How to write test cases
– Wikipedia - Integration Testing
– Examples of Testing Software*
• Part C / Part D
– Talks at Google - A Philosophy of Software Design - John Ousterhout

Page 8
 Department of Computer Science CMPT 145
176 Thorvaldson Building Spring/Summer 2023
110 Science Place, Saskatoon, SK, S7N 5C9, Canada
Telephine: (306) 966-4886, Facimile: (306) 966-4884 Principles of Computer Science

Question 2 (18 points):

Purpose: To practise inheritance.
Chapter 24 introduced the concept of inheritance. We’ve used the Node-based Stack and Queue classes
a few times already this course. Let’s take some time to improve them, using inheritance.
For this question, rewrite the provided Stack and Queue classes, using inheritance to encapsulate common
attributes and methods. You are expected to write proper doc-strings (interfaces) for each method.
To succeed in this question you will need to complete the following tasks:
(a) Implement a super-class called Container. This class should contain all the attributes and methods
common to the Stack and Queue classes provided. Put your solution in a file called a6q2_Container.py.
Some of attributes and methods may have to be changed to make them more generalizable.
(b) Rewrite the Stack class so that it inherits all the Container attributes and methods. Put your solution
in a file called a6q2_Stack.py. You can use the provided test script test_Stack.py to make sure your
new Stack class works correctly.
(c) Rewrite the object-oriented Queue class so that it inherits all the Container attributes and methods.
Put your solution in a file called a6q2_Queue.py. You can use the provided test script test_Queue.py to
make sure your new Queue class works correctly.

What to Hand In
• A file titled a6q2_Container.py
• A file titled a6q2_Stack.py
• A file titled a6q2_Queue.py.
• A gitlog associated with the assignment as a whole named a6.log. Clearly identify commits made for
each question. Examples:
 
A # Q # - Commit Title
A # Q2 - Added provided files for question # to repo
A # Q4 - Implemented function _____ to allow
for ______ to pass .
 
Be sure to include your name, NSID, student number, course number and lecture section at the top of all
documents.

Evaluation
• Container Class
– 7 marks for implementation
– 3 marks for documentation
• Stack Class
– 1 mark for correctly setting up inheritance
– 2 marks for implementation
– 1 mark for documentation
• Queue Class
– 1 mark for correctly setting up inheritance
– 2 marks for implementation
– 1 mark for documentation

Page 9