Programming Principles Chapter 1

Objectives Discuss the program design process. Introduce the Game of Life. Discuss object oriented design. – Information hiding – Methods – Member functions Introduce a new documentation style. – Specification – Preconditions – Postconditions – Uses Avoiding Errors – Scaffolding – Defensive Programming – Stubs – Drivers – Black-box testing – Glass-box testing

Homework Overview Written (max 20 points) – 1.2 (a,d,i,k)(1 pt each) – 1.3 E2 (4 pts) – 1.3 E5 (a,c)(3 pts each) – 1.4 E1(4 pts) – 1.4 E3 (a,b,d)(2 pts each) – 1.4 E4(a,b)(3 pts each) – 1.4 P3(pick 3)(1 pt each)

Planning Programs A large (large enough to be useful) program must be planned. – Planning issues: How to divide the problem into subproblems. How to represent the data. – Data needs to be stored so it can be used by all parts of the program. – General approaches that can be reused and modified later are best.

Planning Process Determine the following: Exactly the problem to be solved. What data will be needed to solve the problem. How the data will be stored. The algorithm used to process the data. Finally, write the program.

Game of Life – A Simulation Game of Life Often used as an example of how complex (Emergent) behavior can result from the application of simple rules. Played on an unbounded rectangular grid of cells. Each cell is either “alive” or “dead”. Each cell changes state based on the states of its surrounding cells according to the following rules.

Game of Life – Rules 1.The neighbors of each cell are the eight cells that touch it. 1.If a cell is alive but has no living neighbors, or has only one living neighbor, it dies. 2.A living cell that has four or more living neighbors dies. 3.A living cell with two or three living neighbors stays alive. 4.A dead cell with exactly three living neighbors comes alive. 5.All births and deaths occur at the same time.

Homework – Section 1.2 (page 10) Written – Exercise 1.2 (a, d, i, k) (do these on paper) (1 pt each)

Outline of Life Program Set up Life configuration Print the Life configuration While the user wants further generations: – Update the configuration using rules 1-6 – Print the Life configuration

Using Classes We will use a C++ class to collect the data for a Life configuration and the functions used to access or modify the data. We will delay implementing the functions. – Information hiding – to use a function, we need to know what it does but not how it does it. Some functions are used by the client program of a class. – These are necessarily public. – These are called methods. Some functions are only used within the object. – These should be private. – These are simply member functions (not methods).

Main Program #include #include "utility.h" #include "life.h" using namespace std; void instructions(); int main()//Program to play Conway's game of Life. /* Pre: The user supplies an initial configuration of living cells. Post: The program prints a sequence of pictures showing the changes in the configuration of living cells according to the rules for the game of Life. Uses: The class Life and its methods initialize(), print(), and update(). The functions instructions(), user_says_yes().*/ { Life configuration; instructions(); configuration.initialize(); configuration.print(); cout << "Continue viewing new generations?" << endl; while (user_says_yes()) { configuration.update(); configuration.print(); cout << "Continue viewing new generations?" << endl; } }

Instructions Function void instructions() /* Pre: None. Post: Instructions for using the Life program have been printed. */ { cout << "Welcome to Conway's game of Life." << endl; cout << "This game uses a grid of size " << maxrow << " by " << maxcol << " in which"<< endl; cout << "each cell can either be occupied by an organism or not." << endl; cout << "The occupied cells change from generation to generation" << endl; cout << "according to the number of neighboring cells which are alive." << endl; }

Utility Header File #include using namespace std; bool user_says_yes(); /* Pre: None. Post: Return TRUE if the user responds 'Y' or 'y' and FALSE if the user responds 'N' or 'n'. */

Programming Style Notice that this book prefers to use the line using namespace std; – This avoid a lot of using commands and/or scope resolution operators. – Locks us in to using the standard namespace so it is less versatile.

Documentation Style Notice that every program, member function and method has a standard specification comment. This should contain the following: – Preconditions: what the the subprogram needs in order to run correctly. Do parameters need to be initialized? Do parameters need to have specific values? What should be the general state of the program for the subprogram to run correctly. – Postconditions: what the result of the subprogram. How will the values of parameters change? What are the side effects? How will the general state of the program change? – Uses: other subprograms that are need for this code to execute. This may be omitted if there are no other subprograms required.

Documentation Style We will be writing larger code in this class and we need to adopt a standard documentation style. 1.Every subprogram should have a list of specifications. 2.Variable names should make their use clear. 3.Introduce each significant section with a comment stating its purpose. 4.Avoid meaningless or obvious comments. 5.Explain nonobvious tricks. 6.The code should describe “how,” the comments should describe “what” and “why.” 7.Document changes to code.

Homework – Section 1.3 (page 17) Written – E2 (written on paper) (4 pts) – E5 (a, c) (written on paper) (3 pts each)

Strategies to Avoid Errors 1.Use code that has been previously written and debugged. 2.Use standard packages ( vector, list, etc.) whenever possible. 3.Scaffolding – write in “support” code to print out important values, test subprograms, etc. Delete or comment out for the final version. 4.Defensive programming – write code to check to see if preconditions have been met. 5.Explain to someone else how your program works. They may be able to find errors or make suggestions.

Debugging Strategies Stubs – write very simple “dummy” versions of subprograms to fill in for ones that have not yet been written. At least your code will compile. Example: void instructions(){} bool user_says_yes(){ return(true); } Stubs can “evolve” into the full subprogram.

Debugging Strategies Drivers – write a short program to provide the necessary preconditions for a subprogram. Example: int main(){ bool check; check = user_says_yes(); if (check) cout << “User says yes.” << endl; else cout << “User says no.” << endl; }

Debugging Strategies It is often impossible to test all possible outcomes. Alternately, do the following: Black-box testing: 1.Test input for which the answer is known. 2.Test trivial cases. 3.Test typical, realistic values. 4.Test extreme values. 5.Test input which uses all of the code Glass-box testing: – Test different input values that uses all of the code. Example: Test both branches of an if-else.

Homework – Section 1.4 (page 32) Written – E1 (written on paper) (4 pts) – E3 (a, b, d) (written on paper) (2 pts each) – E4 (written on paper) (3 pts each) – P1 (nothing to turn in) – P2 (nothing to turn in) – P3 (pick any 3, output) (1 pt each)