CSE1301 Computer Programming: Lecture 29 Group Project: “Quabble”

Topics

• Motivation • Tasks • The Game:

Quabble

• Design Document

Motivation

• Experience developing software with others • Go through phases of software development cycle • Produce a design document, write code from it • Write code using functions, arrays and structs • Construct test sets: – for functions – for complete program.

• Combine functions written by different people

Tasks

• Analyse a problem specification • Decompose a large program into smaller pieces – combine top-down and bottom-up design • Design data structures • Write algorithms for functions • Turn algorithms into code • Test functions and complete program

“Quabble”

• The Bag of Tiles, each tile: • The Game Board: W 4

Quabs:

A 1 I 1 W 4 D 2 A 1 M 3 E 1 N 1 • The Main Aim: – form words using tiles on the board – word must include all quabs – score: sum of the points on the tiles

Example

Quabs:

A 1 I 1

Valid Words:

aid (4) aide (5) aim (5) aimed (8) amid (7) anemia (8) maiden (9) median (9)

Score:

55 W 4 D 2 A 1 M 3 E 1 N 1

Invalid Words:

men (no A and I) dawn (no I) wait (T not in board) aided (two D’s)

Possibly Valid Words: (Depending on the “official” dictionary)

Aida (5) Damian (9) Weidman (13)

The Blank Tile

• • Can be used as a substitute to any letter • Does not earn points

Example: Quabs:

Y 4 D 2 T 1 Z 10  M 3 I 1 C 3

Valid words:

D A Y (6), DI R TY (8), DIZ Z Y (17)

Bonus Points

• Double Points: – If there are no blank tiles on the board, and – player forms a word using all the tiles – Then, player earns twice the points for that word. • Extra Points: – If the player is able to guess all the valid words found by the program – Then, player earns twice the number of words found

Dictionary File

• Lists all (almost) known English words • Plain text (not Word document!) • One word per line • Not necessarily alphabetically sorted • Some words may be capitalised • Sample dictionary:

words.txt

– used by a spell checker – contains proper nouns – US English spelling

Configuration File

• Sample configuration file:

quabble.cfg

8 2 words.txt

* 2 0 A 9 1 B 2 3 C 2 3 D 4 2 E 12 1 ...

The Program: Initialization

• Reads configuration file to determine: – number of tiles on the board – number of quabs – how many tiles per letter (including blank) – how many points per letter • Set up the bag of tiles

The Program: Board Setup

• Pick the tiles from the bag at random • Find all valid words – while there is no solution, put the tiles aside and pick a new set of tiles from the bag – Q: What if no valid words can be formed, and the bag ran out of tiles?

– A: Put all tiles back into the bag and re-mix.

• Compute maximum total points the player can earn

The Program: Interaction

• Must be case insensitive –

Eg

: “Maiden”, “maiden”, “maIdEN”, “MAIDEN” • Must show: – player’s current score – number of valid words the player has found so far – number of words yet to be found – total points left for the player to earn • Correct guess: show points earned • Wrong guess: preferably, say why

The Program: End of Game

• Game finishes when: – player found all the valid words (and earns extra points) – player gives up • If player gave up: – show all words missed by the player – show total points the player could have earned • Show: – player’s cumulative score on all boards played – cumulative maximum total points

The Program: New Game

• At the end of each game, the player can: – end program, or – play a new board (game): • If player wants to play a new board: – Tiles on the board are set aside, and a new set is taken from the bag – If there are not enough tiles left in the bag, put all tiles back into the bag and re-mix.

– (Recall: Board must have at least one solution)

How Do We Start?

• How do we represent the data?

• What are the data sources, sinks and storage?

• What operations / actions / manipulations can we do with each of those data?

• How can we use these operations as building blocks to accomplish the task?

– top-down – bottom-up • Design Document

Design Document

• Sections: – data – modules – algorithms – test data – Program I/O – Group Organization • Marked as a group effort

Data Structures

• How do we represent the data?

– a tile – a board – a bag of tiles – a word – the program’s answer key – the player’s answer sheet – a game – transaction data • Actual C code

Data and Modules

• Bottom-Up approach: – From simple operations on simple data to complex operations on complex data – Example: • operations on a tile : initialize, print • operations on a board : initialize, print • printing a board : print a tile at a time

Modules

• Top-Down Approach: – From biggest to smallest task – Example: Main algorithm • initialization • board setup • interaction • validation • end game

Modules

• Top-Down Approach: – From biggest to smallest task – Example: Main algorithm • initialization – read configuration file – initialize bag of tiles – initialize score • board setup • interaction • validation • end game

Modules

• Structure chart – control coupling – data coupling • avoid implicit data coupling (global variables) • size of data coupling corresponds roughly to level • Purpose and functionality of each module • Actual C function name and prototype (parameters and return type)

Algorithms

• Describe in pseudo-code or flow-chart • Review structure chart: – Do the parameters provide all the information we need?

– Can the encapsulation of the parameters and return values into a single transaction data structure help produce a cleaner algorithm for the module?

– Are the modules coherent?

Test Data

• How do we test that modules, and the whole program, are correct?

• Test data: Valid, Invalid, Boundary • Test all possible execution paths • Need for small test programs which pass test data into a function, and show the results.

• Possible limitations with respect to invalid test data.

Program I/O

• • Input and Output: Data-flow diagram

Not

just user interface: I/O to file, printer, etc as well • Simple text-based user interface: okay

Group Organization

• Equal distribution of labor • Demonstrator’s approval • Basis for marking Part 2.

Individual Modules

• Code, compile, test, document • “The C Style Guide” • Need for test programs (simple

main()

) • Marking: Individual – proportional to how much of your assigned tasks you were able to complete – no extra marks for doing other people’s tasks

System Integration

• Usual cause of problems: – global variables (implicit coupling) – poor design: overlapping modules – module’s functionality not clearly defined – conflicting data structure or function name – data coupling (parameters and return values) do not match – embedded numbers in the code, rather than using

const

or

#define

.

– poor documentation (functions and in-line)

Advanced Component

• Specification 1 – Dictionary Update – Multiple Players • Specification 2 – Unique Boards • Specification 3 – Timer

Miscellaneous

• Sample Bingo Program – Randomization (also: Dietel & Dietel 5.9) – Avoiding duplicates – Validating numerical input – Use of #include and #define • Tip: No need to load the whole dictionary file into memory • Group coordination: Contact details!

• Questions? • Have fun!