Fig. 1
Drag to turn · shift-drag to pan · click to break it down
Scroll to turn the page
Computer Science Principles · AP Computer Science Principles
collaboration, design and debugging
Programs are not written in one pass. They are investigated, designed, built in rough, tested, and revisited, lap after lap, until they do what their users need.
The figure runs one common development process: investigating and reflecting, designing, prototyping and testing. The red ball is the work in hand; at every station it can send the team back to an earlier phase. Each lap leaves the program (blue) more complete: version 3 after 3 laps.
A process can be ordered and intentional, following phases on a plan, or exploratory, trying ideas and keeping what works. There are many processes; these four phases are common to most of them.
This chapter is Big Idea 1 of AP Computer Science Principles, Creative Development: 10–13% of the multiple-choice exam. It covers working together (1.1), what a program does and with what inputs and outputs (1.2), how programs are designed, built and documented (1.3), and how errors are found and fixed (1.4). It is also the work of the Create performance task, the last page of the chapter.
and the perspectives that improve them
A computing innovation includes a program as an integral part of its function.
It can be physical, like a self-driving car; nonphysical computing software, like picture-editing software; or a nonphysical computing concept, like e-commerce.
Innovations are improved through collaboration. Effective collaboration produces an innovation that reflects the diversity of talents and perspectives of the people who designed it, and diverse perspectives help avoid bias: a team whose members all share one experience will tend to build for that experience.
The figure is a hypothetical team listing the cases its app must handle. Developer A alone thinks of 5 of the 12. Three developers together think of 10. The rest come from consulting the users: 12 of 12.
That is why consultation and communication with users matter. Information gathered from potential users helps developers understand the program’s purpose from diverse perspectives, and build a program that fully incorporates them.
pair programming, online tools, interpersonal skills
Groups develop innovations with common models of collaboration. One is pair programming.
Two programmers share one computer. The driver (red) types the code; the navigator (blue) reviews each line as it is written, catches mistakes and thinks ahead. Halfway through the figure they swap: the role goes with the keyboard, not the person. The program they are writing is the one on the next page.
Online tools support collaboration by letting programmers share ideas and documents and give feedback on them, whether or not they work in the same room.
Effective teams practice interpersonal skills, including but not limited to:
what a program does, and how
A program is a collection of program statements that performs a specific task when run by a computer. A program is often referred to as software.
total ← 0 REPEAT 3 TIMES { n ← INPUT() total ← total + n } DISPLAY(total / 3) A code segment is a collection of program statements that is part of a program: here, the loop on lines 2–6 (blue in the figure).
A program can be described broadly, by what it does: “it displays the average of three numbers the user types.” Or in more detail, by what it does and how its statements do it: “it sets total to 0; three times, it reads a number into n and adds it to total; then it displays total / 3.”
A program needs to work for a variety of inputs and situations. The figure runs it twice:
| inputs | total after the loop | displayed |
|---|---|---|
| 4, 8, 9 | 21 | 7 |
| −2, 0, 5 | 3 | 1 |
Its behavior is how it functions during execution, often described by how a user interacts with it: the user types three numbers, and one number appears.
Every innovation has a purpose: to solve a problem, or to pursue an interest through creative expression. Developers who understand the purpose are better able to develop the program.
data in, data out, in many forms
Program inputs are data sent to a computer for processing by a program. Program outputs are any data sent from a program to a device.
Both come in a variety of forms: tactile (a touch, a vibration), audio (a spoken word, a sound), visual (a camera image, the screen) or text. The figure sends one input of each form in turn into a program, and one output of each form out of it.
Input can come from a user or from other programs; the text output at the bottom right goes to another program, for which it is input.
Inputs usually affect the output a program produces. And output is usually based on the program’s input or its prior state: values it has stored. This program keeps a count (blue) of the inputs it has received, so the same touch on the screen can produce a different output the second time.
In the average program on the last page, the three calls to INPUT() were its inputs, and DISPLAY sent its output to the screen.
statements run when triggered
An event is associated with an action and supplies input data to a program.
Events are generated when a key is pressed, a mouse is clicked, a program is started, or any other defined action occurs that affects the flow of execution.
In event-driven programming, program statements are executed when triggered rather than through the sequential flow of control. Nothing runs line after line from the top: each event runs the procedure that handles it, and the program waits for the next.
PROCEDURE onStart() { count ← 0 DISPLAY(count) } PROCEDURE onClick() { count ← count + 1 DISPLAY(count) } PROCEDURE onKeyPress() { count ← count - 1 DISPLAY(count) } The exam reference sheet has no event syntax, so here each handler is a procedure and a hypothetical environment calls it when its event happens. In the figure the program starts, the button is clicked three times, a key is pressed and the button is clicked once more. The displayed values are 0, 1, 2, 3, 2, 3.
count belongs to the whole program, so each click’s output depends on the events before it.
iterative and incremental
A development process can be ordered and intentional, or exploratory in nature. There are many; most use phases of investigating and reflecting, designing, prototyping and testing.
A process that is iterative requires refinement and revision based on feedback, testing or reflection throughout the process. This may require revisiting earlier phases. In the bottom row the whole program exists from the first pass, rough; each round of feedback (red) sends it back, and every part comes out more complete.
A process that is incremental breaks the problem into smaller pieces and makes sure each piece works before adding it to the whole. In the top row one piece is built and tested at a time, and joins the whole only when its test passes.
The two are not opposites. Most teams do both: they build piece by piece, and revise each piece, and the whole, as feedback arrives.
requirements, specification, storyboard, modules
The design of a program begins with investigation, to determine its requirements.
Investigation identifies the program’s constraints, and the concerns and interests of the people who will use it. It can be done by surveys, user testing, interviews and direct observations.
Program requirements describe how a program functions, and may include a description of the user interactions it must provide. A program’s specification defines its requirements. For a hypothetical app that books library study rooms: (1) the user picks a date; (2) the user sees the rooms free that day; (3) the user books one and gets a code.
The design phase outlines how to accomplish the specification. It may include:
The figure draws two of them: a storyboard of the interface, one screen per step, with the user’s tap carrying them from screen to screen; and the program organized into modules, one per requirement.
and acknowledging code from others
Program documentation is a written description of the function of a code segment, event, procedure or program, and of how it was developed.
Comments are a form of documentation written into the program to be read by people; they do not affect how the program runs. Not all programming environments support comments, and the exam reference sheet has none, so in the figure each procedure’s documentation sits beside it instead.
PROCEDURE average(numList) { total ← 0 FOR EACH num IN numList { total ← total + num } RETURN(total / LENGTH(numList)) } PROCEDURE isEven(n) { RETURN(n MOD 2 = 0) } average([6, 9, 3, 10]) returns 7. Documentation is written throughout development: the card for average grows with its code. It helps in developing and maintaining correct programs, alone or in a team, because the next reader (often the writer, later) can see what each part is for.
It is important to acknowledge any code segment developed collaboratively or by another source. The acknowledgment can be in the program documentation, and should include the origin or the original author’s name. In the figure, isEven (blue) comes from another source, and its card says so.
when each one shows itself
Three programs, each meant to display every score in [90, 75, 82]; each has one mistake.
A syntax error is a mistake in the program where the rules of the programming language are not followed. In the first program, line 5 is missing its closing parenthesis. The program does not run at all: no line runs, and nothing is displayed.
A run-time error is a mistake that occurs during the execution of a program; programming languages define their own run-time errors. The second program adds 1 to i before it displays, so it displays 75 and 82, then asks for scores[4]. On the reference sheet, an index less than 1 or greater than the length of the list is an error, and the program terminates.
A logic error is a mistake in the algorithm or program that causes it to behave incorrectly or unexpectedly. The third program repeats one time too few. Nothing stops it: it ran to the end, but displayed 2 of 3 scores. Only comparing its output with the expected output shows the error.
scores ← [90, 75, 82] i ← 1 REPEAT LENGTH(scores) - 1 TIMES { DISPLAY(scores[i]) i ← i + 1 } Corrected, line 3 is REPEAT LENGTH(scores) TIMES.
a number outside the range
An overflow error occurs when a computer attempts to handle a number that is outside the defined range of values.
Many programming languages store integers in a fixed number of bits, which limits the range of values. Take a hypothetical language that stores whole numbers in 4 bits: the largest it can hold is 1111, which is 15.
The figure counts up from 12. Each step flips the bits that change. At 15, adding 1 needs a fifth bit (16 is 10000), and the store has only 4: an overflow. What happens next depends on the language: some stop with an error, others keep the bits that fit and carry on with a wrong value (here, 0).
Real languages use more bits, so their limits are far larger, but they are limits all the same. The language on the exam reference sheet is different: there, the size of an integer is limited only by the computer’s memory.
defined inputs, expected outputs
Testing uses defined inputs to make sure an algorithm or program produces the expected outcomes. Programmers use the results to revise it.
A hypothetical theater’s requirement: under 13, or 65 and over, a ticket costs $8; everyone else pays $12. The requirement is what tells the tester which inputs to try and what to expect for each.
PROCEDURE price(age) { IF(age < 13 OR age ≥ 64) { RETURN(8) } RETURN(12) } Good test inputs demonstrate the different expected outcomes and sit at or just beyond the extremes (the minimum and maximum) of the input data, where mistakes cluster: here 12 and 13 either side of one boundary, 64 and 65 either side of the other, and the smallest age, 0.
| age (input) | expected | actual | |
|---|---|---|---|
| 0 | $8 | $8 | pass |
| 12 | $8 | $8 | pass |
| 13 | $12 | $12 | pass |
| 40 | $12 | $12 | pass |
| 64 | $12 | $8 | fail |
| 65 | $8 | $8 | pass |
The test at 64 fails: the code says age ≥ 64 where the requirement means age ≥ 65, a logic error. A test at a typical age like 40 would never have found it.
tracing, visualizing, debugging, displaying
Effective ways to find and correct errors: test cases, hand tracing, visualizations, debuggers, and adding extra output statements.
findMax should return the largest number in a list. Tested on [-3, -7, -2] it returns 0, not −2. To see why, the programmer adds DISPLAY(max) inside the loop (blue): an extra output statement.
PROCEDURE findMax(numList) { max ← 0 FOR EACH num IN numList { IF(num > max) { max ← num } DISPLAY(max) } RETURN(max) } Hand tracing it, one row per element:
| num | num > max? | max after | DISPLAY shows |
|---|---|---|---|
| −3 | false | 0 | 0 |
| −7 | false | 0 | 0 |
| −2 | false | 0 | 0 |
max never changes: no element is greater than 0. A debugger shows the same thing by pausing the program and showing its variables (the cells in the figure, a visualization of its state). The error is on line 3: max starts at 0, larger than every element of an all-negative list.
The fix is max ← numList[1]: start from an element of the list. Run again, the extra output shows −3, −3, −2, and it returns −2. Then the extra DISPLAY comes out.
your own program, and questions about it
The Create performance task is this chapter put to work: a program of your own choice, developed with the process, documentation and testing of 1.1–1.4.
You submit three things in the AP Digital Portfolio: your program code, a video of it running, and a Personalized Project Reference (PPR). You are given at least 9 hours of class time for it. Your program must include certain elements, such as lists and procedures.
On exam day comes the written response: 60 minutes, 2 questions about the code in your own PPR, which you can see while you answer.
The task and the written response together are 30% of the AP score; the multiple-choice exam (70 questions in 120 minutes) is the other 70%.
So the questions of this chapter come back about your own program: what is its purpose and function, what are its inputs and outputs, what did you test and with which inputs, and what error did you find and fix.