CSE1301 Computer Programming:

Lecture 29Group 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”

W4• The Bag of Tiles, each tile:

• The Game Board:

A1 I1 W4 D2 A1 M3 E1 N1

Quabs:

• The Main Aim:– form words using tiles on the board– word must include all quabs – score: sum of the points on the tiles

Example

A1 I1 W4 D2 A1 M3 E1 N1

Quabs:

Valid Words:

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

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)Score: 55

The Blank Tile

• Can be used as a substitute to any letter

• Does not earn points

• Example:

Y4 D2 T1 Z10 M3 I1 C3

Quabs:

Valid words: DAY (6), DIRTY (8), DIZZY (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 2words.txt* 2 0A 9 1B 2 3C 2 3D 4 2E 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!