6.4 Pseudocode Design
When designing the implementation of a particular function, it is sometimes helpful to write an outline of the algorithm at an abstract level in pseudocode rather than immediately writing C code. This form of function-level design concentrates on the algorithm structure without getting bogged down in syntactical details.
Pseudocode, also called program design language, is basically an English description of the intent of a code segment. For example, consider the following pseudocode to get value from the user and to calculate them factual.
loop number of times
prompt user and get integer value
calculate factorial
print factorial
Given a pseudocode layout, it becomes straightforward to replace the pseudocode with C constructs. In sections where the code intent is not obvious, it is good practice to leave the original pseudocode in place as a comment.
6.5 Case Study: A Tic-Tac-Toe Game
As an example of modular program design, this section presents the design and implementation of a simple game: Tic-Tac-Toe (also known as Noughts-And-Crosses). This program is simple enough to describe in a reasonable period of time, and complex enough to demonstrate the concepts required for larger-scale programs.
6.5.1 Requirements
The aim of this program is to play a game of Tic-Tac-Toe against the computer. To begin, the user is welcomed to the game and asked if he wishes to have first go. The following game is turns-based, alternating between a request for the user’s move, and the computer’s own-move decision. After each turn, the result is printed in ASCII and, if there is a winner or a draw, the user is asked if he wishes to play again.
6.5.2 Specification
The program is to print a welcome message to introduce the game and its rules.
Welcome to TIC-TAC-TOE.
-----------------------
The object of this game is to get a line of X’s before the computer gets a line of O’s. A line may be across, down, or diagonal.
The board is labelled from 1 to 9 as follows:
1|2|3
-----
4|5|6
-----
7|8|9
This is followed by a request for whether the user wishes to start, with the integer 1 meaning ‘yes’ and 0 for ‘no’.
Do you wish to go first (1-Yes, 0-No) ?
Each time the user is to make a move, a request is made for which location he wishes to choose, designated by a number between 1 and 9.
Your turn (1 - 9):
After the user or the computer has made a decision, the resulting table is printed in ASCII. For example, after 5 turns, the board might look like
X| |
-----
X|O|
-----
|X|O
The game will terminate with a winner or a draw, and a comment is to be printed on account of the user’s win, loss or draw, respectively.
You win. Congratulations!!
You lose. Better luck next time.
Its a draw. How dull.
Finally, the user is asked if he wishes to play again and, if so, the game returns to the request of whether he wishes to have first go. Otherwise, the program terminates.
Do you wish to play again (1-Yes, 0-No) ?
6.5.3 Program Flow and Data Structures
A rough sketch of the flow and dependencies of the program is shown in Figure 6.2. Such diagrams are very useful for getting an initial impression of modular composition and interaction. For small-scale projects, a simple hand-drawn diagram may be su cient; for larger or team-built programs, they are typically precursors to more formal design diagrams. Figure 6.2 shows that there are a series of initialisation operations—a welcome screen and a prompt asking whether the users wants to go first—and then a main game-play loop. The game loop takes each player’s decision in turn, prints the resulting game-board, and determines if the game continues or is over. On game-over, a message is printed based on the result (win, lose, or draw), and the user can choose to play again or quit.
The internals of this program are very simple, but it is necessary to specify the main variable types as they will a ect the design of the function interfaces. From the flow diagram, it can be seen that there are three key data structures passed between the various functions. The first is the current state of the game for each of the nine locations on the Tic-Tac-Toe board. Each location may be in one of three states: empty, cross, or nought. It was decided to make the game states an integer array, and the possible states enumerated constants.
#define NUMSTATES 9
enum { NOTHING, CROSS, NOUGHT };
int state[NUMSTATES];
The other two data structures are the state of whose current turn it is (user or computer) and the state of the game result (still playing, user won, user lost, or draw). These variables were chosen to be enumerated types, and their possible states given by enumerated constants.
enum Turn { USER, COMPUTER };
enum Result { PLAYING, WIN, LOSE, DRAW };
enum Turn turn;
enum Result result;
No comments:
Post a Comment