Small application project
AdvancedThe project four-step: requirements → design → implementation → testing. Design fixes the data structure (dictionary) and the division of functions (add, stats, save); testing covers normal and extreme input (text as score, empty dictionary, duplicate names).
- The project four-step: requirements → design → implementation → testing, in that order.
- Design fixes two things first: the data structure (dictionary, name → score) and the function split (one job each).
- Menus pair with while loops; remember input returns a string, so compare with == "1".
文體小知識：專案指南課由企劃到評估逐步帶你完成整個製作，適合接著做小組功課和比賽作品。
§Text Passage
1Writing a real program does not start with typing code. The professional flow has four steps: requirements analysis (what to build, and for whom) → design (plan the data structure, the division of functions, the interface) → implementation (write in pieces, testing as you go) → testing (normal and extreme cases alike). Skip the first two and you will almost surely start over.
2Take the demo project 'score recorder'. Requirements analysis: classmates want a program to record test scores per subject, add new scores any time, view the average and highest, and keep the data after closing. Those three sentences are the requirements — each must be verified in testing later.
3Design stage: the data structure is a dictionary grades = {"Mary": 85, "John": 90}, keys as names and values as scores; the functions split into add_score(), show_stats(), save() and load(); the main program loops in while showing a menu so the user types 1 to 4 to pick a feature. Draw the design on paper and you will not get lost while coding.
4Implementation and testing: write one function at a time and try it immediately before moving on. Testing asks three questions: is normal input right (the average of 85 and 90 is 87.5)? What about extreme input (typing "abc" as a score, a duplicated name, averaging an empty dictionary)? Does reloaded data match what was saved? Only when all pass is the project done.
1Summary 重點摘要
The project four-step: requirements → design → implementation → testing. Design fixes the data structure (dictionary) and the division of functions (add, stats, save); testing covers normal and extreme input (text as score, empty dictionary, duplicate names).
2Vocabulary cards Vocabulary
The stage deciding what the program must do and for whom, ending with a clear feature list.
Planning the data structure, the split of functions and the interface before coding.
Writing the code function by function following the design, testing as you go.
Verifying the program against requirements with normal and extreme inputs.
An interface listing numbered features for the user to pick, shown repeatedly inside a while loop.
Checking that user input is sensible (e.g. a score must be a number) and asking again when not.
Splitting a program into small functions with single jobs, easy to write, test and change.
The extremes most often overlooked, such as empty lists, zero scores or duplicated names.
Recording what the program does, how to use it and why it was designed that way.
3Step by step Steps
- Step one: the requirements listWriting a real program does not start with typing code. The professional first step is the requirements list: every desired behaviour, one sentence each. For a 'score recorder': one, add a student's name and score; two, show the average and the highest score; three, data survives closing the program. Each line is later accepted or rejected — an unfinished line means the project is not done. Clear requirements anchor the design and testing that follow; skip this and halfway through you discover a missing feature and start over.
- Choosing the data structureStep two picks the data structure from the requirements. A score recorder needs 'look up a score by name', so a dictionary fits: grades = {"Mary": 85, "John": 90}, names as keys and scores as values. Adding a record is grades["Peter"] = 78; a lookup is grades["Mary"]; before statistics, grades.values() takes out every score. Recording events in order would want a list; a name-to-phone search wants a dictionary. The right structure makes every feature easy; the wrong one blocks everything.
- Dividing the work among functionsStep three assigns the work to functions, one job each: add_score(grades, name, score) adds a record; show_stats(grades) computes and prints the average and highest; save(grades) and load() handle the file. Single responsibility pays twice: when something breaks, the culprit function is found quickly, and changing how the average is computed touches only show_stats. Functions pass data through parameters and return results, while the main program merely directs the flow.
- The menu loop and inputThe main program runs a menu inside while True:: first print("1 add 2 stats 3 quit"), then choice = input("choose: "), then if choice == "1": add a score, elif choice == "3": break. The crucial detail: input() returns a string, so "1" is not the number 1 — compare with choice == "1", or convert with int(choice) for arithmetic. Forgetting this is the beginner's commonest bug: the program ignores the input 1 entirely, leaving everyone puzzled.
- Input validation: foolproofingUsers do not always follow the rules. If a user types "abc" as a score, int(text) raises an error and the program crashes. The fix is try/except: after text = input("score: "), write try: score = int(text) except ValueError: print("please enter a number") and continue back to the menu. Illegal input then draws a message instead of a crash. The foolproofing of every professional application and game grows from this idea: assume the user will err and block it in advance, so the experience stays smooth.
- Testing normal and extreme casesTesting splits in two. Normal cases: add 85 then 90 and choose stats, expecting an average of 87.5 and a highest of 90 — write the expected values on paper first and tick each off after running. Extreme cases: choosing stats with no records divides by zero unless len(grades) == 0 is checked first; a duplicated name must update rather than double-record; and after saving, closing and reopening, the data must be identical. Extreme cases expose the hidden bugs best and must all pass before delivery.
- When the project is finishedA project is finished not when 'it runs' but when three questions all pass: is normal input correct, does extreme input survive without crashing, does saved data reload unchanged? Then tick the requirements list line by line. The discipline of writing one function at a time and testing it immediately keeps debugging narrow; writing everything before testing lets errors tangle together. Requirements, design, piecewise coding and two-sided testing — this flow serves every programming project to come.
4Diagrams Diagrams
5Worked example Example
Example: write show_stats(grades) for the score recorder, printing the average and highest score, and demo it with grades = {"Mary": 85, "John": 90, "Peter": 78}.
- Block the empty dictionary first: if len(grades) == 0: print("no records yet") and return, avoiding division by zero.
- Take out the scores: scores = list(grades.values()), giving [85, 90, 78].
- Compute: average = sum(scores) / len(scores) = 253 ÷ 3 ≈ 84.33 and highest = max(scores) = 90.
- Print: print("average", round(average, 1), "highest", highest), showing average 84.3 highest 90.
- Extra test: call once with the empty dictionary {} and confirm it prints 'no records yet' instead of crashing.
- Answer: show_stats blocks the empty dictionary first, then prints an average of 84.3 and a highest of 90 from [85, 90, 78] — the keys are the defensive opening check and round() for tidy decimals.
6Common mistakes Mistakes
7Quick check Quick check
Q1The correct order for building a small application? A. code → test → design → requirements B. requirements → design → code → test C. design → code → requirements → test
Q2In the score recorder, grades = {"Mary": 85, "John": 90}; after grades["Peter"] = 78, what is len(grades)?
Q3The user types "abc" as a score — which pattern keeps the program from crashing?
Q4Calling show_stats() on an empty grades dictionary — what goes wrong and how to handle it?
Q5Name any three checks when testing the score recorder.
8Recap Recap
- The project four-step: requirements → design → implementation → testing, in that order.
- Design fixes two things first: the data structure (dictionary, name → score) and the function split (one job each).
- Menus pair with while loops; remember input returns a string, so compare with == "1".
- Validate input with try-except catching ValueError so bad input never crashes the program.
- Test normal and extreme cases alike: empty dictionary, duplicate names, save-and-reload all verified.