Skip to main content
AP CSP course

C04 · Topic 1.2 · 40 minutes · CRD-2.A, CRD-2.B, CRD-2.C, CRD-2.D

Inputs, outputs and behaviour

By the end you can:

  • Identify external inputs and outputs.
  • Trace a specified interaction through processing.
  • Distinguish internal state from displayed results.

Before this lesson: topics 1.1.

Purpose
The goal a computing innovation or programme is intended to serve.
Input/output
Data or events supplied to a system, and information or effects it communicates externally.

Understand

An input may be data entered by a person, a sensor reading or a received event. Processing transforms or uses those inputs. Output is an externally observable result, such as a displayed message, sound or transmitted value; an internal variable is not automatically an output.

Describe behaviour using a stated input, the relevant processing and the resulting effect. Keep an intended behaviour separate from an observed one when debugging. A programme may receive several inputs, and its output may depend on stored state as well as the most recent event.

Worked example

The capacity model receives name Code and the text 0.

IF (places = 0) { DISPLAY(name + " is full.") }
ELSE { DISPLAY(name + " has " + text + " places left.") }
  1. The name and raw text are inputs; validation/conversion occurs before this shown branch.
  2. The numerical places value 0 makes the first branch true.
  3. The displayed output is Code is full.; places is internal state used to choose it.

Explore each concept

Choose a concept, change its inputs and follow the explanation. Each example models the stated rule or scenario; completing it is practice rather than evidence of mastery.

  • Purpose versus feature
  • Event-driven execution
  • Input, processing, state and output
Open this example on its own

Change it · step through · explain

Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.

Ready · Make a prediction

Ready to explore: Purpose, events and observable output
  1. Program purposefind-a-roomWaiting
  2. Input eventclickWaiting
  3. Initial internal count (0–10)2Waiting

Ready to explore: Purpose, events and observable output

Why: Change an input, predict the first effect, then advance one step.

Try this: Change one input or choose another listed case. Predict the effect, reset and compare the states and governing rule.

Step through and experiment

Change it · step through · explain

Change an input, predict what will happen, then advance one step. Read why the state changes, reset and experiment. This fixed teaching model does not save progress or award XP.

Ready · Make a prediction

Ready to experiment
  1. Input 1ArtWaiting
  2. Input 25Waiting

Ready to experiment

Why: Predict the first change, then advance one step.

Try this: Try 0, 007, an empty input and a letter. Does validation or display change?

Check a misconception

Claim: Every value stored by a programme is an output.

Storage inside a computation differs from information presented or sent externally.

Guided practice

Classify entered arrival times, calculated waits and a displayed bus list as input, processing/state or output.

Work with a partner. Make a prediction, compare your reasoning, then identify the rule that supports your answer.

Independent transfer

If a second input changes available places from 0 to 5, describe the resulting capacity message.

Exit check

Why should a behaviour explanation include a concrete input?

Write your reasoning before comparing with a classmate. If your teacher assigned this task, submit it through My classes to save your work and receive feedback.

Check yourself

  1. Question 1 of 2In this model, which is an external output?

    Select one answer.

  2. Question 2 of 2A sensor reading arrives automatically. Which statement is correct?

    Select one answer.

Your practice so far

Check an answer to see its rationale.

Teacher guidance and scoring