Lesson Overview
Plan a small program using decomposition, pseudocode, data choices and a simple class outline before coding.
Portfolio focus: Sketch a design for a grade calculator.
Starter: think before typing
Before running this design example, find the line where the main idea becomes active. Write a prediction: what must already be true for that line to work, and what should be different after it runs? The checked run ends with `Mark 67 means pass`; predict how the focus line helps produce that evidence.
Learning Objectives
- Break a problem into smaller program responsibilities.
- Use pseudocode to describe logic before syntax.
- Choose suitable data and method boundaries.
- Explain how design reduces rework during coding.
Learning Outcomes
- By the end of the lesson, you can break a problem into smaller program responsibilities.
- By the end of the lesson, you can use pseudocode to describe logic before syntax.
- By the end of the lesson, you can choose suitable data and method boundaries.
- By the end of the lesson, you can explain how design reduces rework during coding.
Why this idea exists
Design sits between the problem and the program. Early software engineering grew partly from the realisation that large programs could not be reliably built by simply starting at line one and continuing until something worked.
Pseudocode, diagrams and decomposition give programmers a way to reason without being trapped by syntax. This matters because syntax errors are often easy to fix, while structural mistakes can make a program difficult to extend or test.
A good design is not a huge document. For a first-year portfolio it is a clear account of responsibilities, data, flow and boundaries, so that the Java implementation feels like a translation of thinking rather than guesswork.
Deep dive
Mechanism in this example
The important mechanism is visible around `if (mark >= 40) {`. Read it as a concrete move in the program, not as decorative syntax: identify what value, object, branch, call or boundary is being created at that point.
Design pressure
A good design is not a huge document. For a first-year portfolio it is a clear account of responsibilities, data, flow and boundaries, so that the Java implementation feels like a translation of thinking rather than guesswork.
Failure mode to watch
For Program Design Before Java, deliberately disturb the assumption behind `if (mark >= 40) {`: use an awkward value, missing input, wrong order of calls or boundary case. The useful question is how that disturbance exposes a weakness in the design design.
Extension step
Extend the example by doing this: Identify inputs, processing steps and outputs. The point is to make one small change that forces you to revisit the concept, rather than adding unrelated features.
Portfolio standard
The portfolio note should not repeat the lesson wording. It should show the edited code, the run result, and your own explanation of this evidence: write pseudocode before writing any java.
Lesson visual
Type this and run it
Create ProgramDesignPseudocodeJavaDemo.java, type the program, and run it before changing anything. This section is about reproducing the checked baseline.
public class ProgramDesignPseudocodeJavaDemo {
public static void main(String[] args) {
int mark = 67;
String status;
if (mark >= 40) {
status = "pass";
} else {
status = "resit";
}
System.out.println("Mark " + mark + " means " + status);
}
}Build and run it with:
javac ProgramDesignPseudocodeJavaDemo.java && java ProgramDesignPseudocodeJavaDemoExpected baseline: Mark 67 means pass
Run the code in your browser
Use the editor as an experiment surface. First run the checked version, then make one small change to the part of the program that demonstrates design and compare the new behaviour with the reference output.
Mark 67 means passLine-by-line explanation
Read the code as a sequence of responsibilities. The focus line for this lesson is if (mark >= 40) {; the surrounding lines prepare it, use its result or make the behaviour observable.
public class ProgramDesignPseudocodeJavaDemo {This names the runnable class for the Program Design Before Java example, giving the compiler and JVM one clear unit to build.
public static void main(String[] args) {This is the program entry point. In Program Design Before Java, it keeps the demonstration of design in one traceable starting script.
int mark = 67;This introduces mark as named state for Program Design Before Java. Later lines can read, update, pass or print that specific value as evidence.
String status;This reserves a typed name in the Program Design Before Java example before a value is assigned. Trace where it next receives a value before it is read.
if (mark >= 40) {This makes the Program Design Before Java decision point. Trace the condition first, then trace only the branch that can actually run.
status = "pass";This assignment changes status in Program Design Before Java to "pass". Trace where that new value is used next.
} else {This opens the alternative Program Design Before Java branch, which runs only when the earlier condition is false.
status = "resit";This assignment changes status in Program Design Before Java to "resit". Trace where that new value is used next.
}This closes the innermost Program Design Before Java block, so the immediately preceding method, branch or loop has finished.
System.out.println("Mark " + mark + " means " + status);This prints "Mark " + mark + " means " + status as the observable evidence for Program Design Before Java. The output lets the learner check whether the design idea behaved as predicted.
}This closes the outer Program Design Before Java structure, returning the reader to the surrounding class or file.
}This closing brace number 3 completes another layer of the Program Design Before Java source structure Java has been checking.
Worked example
From code to explanation
Problem: Use Program Design Before Java to complete a small portfolio-quality step: Sketch a design for a grade calculator.
Method: Locate the line `if (mark >= 40) {`, explain the exact role it plays, then decide what you would change to extend the example without changing the whole program.
Reveal worked answer
The checked run should produce `Mark 67 means pass`. A strong answer links the result back to design: what was created, selected, stored, called or protected, and why that matters for the portfolio task.
Trace the program
Before: Before the key operation, identify the relevant value, object, branch or resource that the design concept depends on.
During: Trace `if (mark >= 40) {` as the Program Design Before Java example executes. Say whether that operation creates data, checks a condition, calls behaviour, stores information or crosses a boundary.
After: Compare the run with the expected evidence: `Mark 67 means pass`.
Change: Now identify inputs, processing steps and outputs, run again, and explain the smallest reason the behaviour changed.
Common misconception
A common mistake in program design before java is treating the example as a finished answer. For design, the important question is narrower: which operation carries the idea, what does it make possible, and what would break if you changed it carelessly?
Quick checks
1. In this Program Design Before Java example, what is the best reason to focus on `if (mark >= 40) {`?
2. Which evidence is strongest after you edit and rerun this example?
How to study this lesson
For Program Design Before Java, predict how design changes the run before you press Run.
Use the first portfolio task as your main edit: Sketch a design for a grade calculator.
Use the second task as your variation: Identify inputs, processing steps and outputs.
Finish with evidence, not a diary entry: Write pseudocode before writing any Java.
Portfolio Practice
- Sketch a design for a grade calculator.
- Identify inputs, processing steps and outputs.
- Write pseudocode before writing any Java.
Final self-check
Can you explain the key operation?
Explain the line identified in the quick check in one or two sentences. Your answer should say what it does before the output Mark 67 means pass appears.
Can you justify the portfolio evidence?
Your evidence should include the original run, one edited run, and a short note explaining how the edit affected design.
Study route
Practise design by predicting the Java example, typing it, running it in the browser, tracing the result and saving portfolio evidence.
Next, move into Java Types, Variables and Expressions and carry forward one improvement from this lesson into the next program.