The last guide was about the people needed to make a computing innovation. In this guide, we'll be discussing another fundamental basis of computing innovations: a program’s function and purpose.
This topic has a lot of vocabulary words. It’s important to understand these words because they may appear on the AP test. These vocabulary words are also used in the written portion of the Create Project. Take a look at the first question of the written response:
Source: AP CSP CED, College Board, page 192
In this first question, you're asked to describe the purpose, input, and output of a program, all words covered in this topic.
So, let's get started by looking at the purpose of computing innovations.
The purpose of a computing innovation is what it's designed to do.
Solving problems is one of the major purposes of computing innovations. For example, text messaging and video-chat platforms solve the problem of needing to communicate quickly over long distances.
A computing innovation can also be a form of creative expression.
For example, making a video game, or creating a program that draws squares on a screen, are examples of designing a computing innovation as a form of creative expression.
Having a clear purpose for a computing innovation is like having a good thesis for an essay. It focuses the work of creating the innovation and establishes what the goals of the innovation are. In short, it strengthens the coder's ability to make the thing they want to make.
|purpose of computing innovations
|importance of a clear purpose
Source: GIPHY, from Reddit
A program is a collection of instructions that a computing device executes, or carries out. Programs are also known as software or applications.
Within a program, you have code segments.
A code segment is a smaller collection of statements that are part of a program. It's like the part of a cake recipe that tells you how to make the frosting.
There's no clear definition of what separates one code segment from another, so, in theory, you can take any collection of lines to be a code segment.
Each code segment is made up of statements, or individual instructions.
In summary, a computer program is made up of code segments, which themselves are made up of statements.
A program can be described in a broad sense by what it does.
My adding program lets the user add two numbers of their choice.
You can also go more in-depth by describing how the program's statements accomplish this goal.
My adding program asks the user to input two numbers, then adds them together and displays the final sum.
Programs run on inputs and outputs and exhibit specific behaviors. We'll describe these more in the next few passages.
Programs run on inputs, which are pieces of data that a computer takes in and processes. For example, the two numbers you need to add in an adding program are the inputs for that program.
These inputs can be directly submitted by the user or they can come from other programs. The above example is a user-submitted input.
- Auditory (ex: spoken words or music notes input into a sound processor)
- Visual (ex: photos input into a photo editor)
- Tactile (ex: strokes of a keyboard, swipes on a touchscreen)
- Text (ex: words input into a translation program or numbers input into a calculator)
If program inputs are data that a computer takes in, program outputs are the data that the computer returns. In the adding program example, the program output is the final sum that the program returns.
Outputs can be in any of the formats inputs can be in.
- Visual (ex: an edited photo from a photo editor)
- Tactile (ex: a video game controller vibrating in response to in-game movement)
- Text (ex: translated text from a translation program)
In order for a program to receive inputs, an event needs to happen. A program event is simply an action that gives a program data to respond to.
For example, pressing the left arrow causes a video game's program to make an avatar go left. Pressing the key is the event in this case.
Events cause programs to change how they're running. In the previous example, pressing the left key caused a change. If the arrow hadn't been pressed, the avatar would've kept moving in the direction it was before (or standing still, as the case may be.)
- clicking a button
- moving a mouse
- starting a program
- pressing a key
- a timer running down to zero
A lot of modern software is event-driven, which means that it's designed to respond to events in order to run.
Let's go back to our adding machine example. You start the program, which is an event. Then, you type the two numbers in and input numbers into the program, another event. The program is designed to respond based on these events, so it's considered event-driven. On a larger scale, your phone's software is event-driven as a whole because it responds primarily to your taps, clicks, and swipes.
When you run a program, you expect it to perform in a certain way. This is known as a program's behavior. Usually, program behaviors are defined by how a program will respond to a user interacting with it.
It's important to think of what behavior you want your program to have before you code it. In order to figure that out, you'll need to know what the purpose of your program is, how program events will give inputs for the program to process, and how the program will output information.
Even if the programmer doesn't define a program's behavior for a certain scenario, the program will exhibit behavior in response to it anyways. That response is often to crash.
Obviously, you don't want an adding program to crash your computer or return the numbers multiplied together instead of added together.
However, it can be very hard to fully define the behavior of a program.
Let's say you're making a relatively basic video game, like Snake. For those who don't know, Snake is a game where you play as a snake eating food, and each time you eat food your tail grows. The goal of the game is to eat as much food as you can and try to avoid your own tail. Clearly, the game should do the above description: make the snake eat food, make the snake's tail grow, and make the game end when you hit your tail. However, there's also the question of how the program should behave when the game starts: should there be a welcome screen? When the snake hits its tail, should the game end or should the game give you multiple chances/lives? What if you want to make the snake change colors every time it eats a piece of food?
In AP CSP, you’re not expected to make a video game. However, this example demonstrates how many questions potentially need to be answered when defining program behavior.* Even our adding program has lots of different questions about its behavior to answer: for example, what happens if the user inputs letters instead of numbers?
So, how do you develop all of this clearly? The answer to that lies in the development process.
*For the AP CSP Create Program, you won't need to define the behavior your program should exhibit for every possible scenario it could run into. You also won't be asked to define every single behavior of anything on the AP CSP test. It's just important to know that programs run into a lot of different scenarios, and have a lot of different responses in response. Those responses are known as program behavior.