At a glance
Written on paper, alone, with no machine · three hours in the examination period · reaches across all four units, and asks for the reasoning as often as for the code
What it is for
Everything else in this semester was built with time, help, a repository, and at least one person to ask. That is what professional work is like and it is why the course is shaped that way. This is the one afternoon where the only thing on the desk is what you carry in your head — not to catch anybody out, but because a course that never asks that question cannot honestly claim to know what you can do alone.
It is also the only piece of evidence in the course that no team can carry and no team can sink.
What the paper contains
| Part | About | What you do in it |
|---|---|---|
| A. Reading it cold | 20% | Trace objects and recursive calls by hand and state exactly what comes out |
| B. Design on paper | 25% | Turn a described problem into classes, and choose containers with reasons |
| C. Algorithms and analysis | 30% | Write searches, sorts and recursive routines; state and compare their costs |
| D. Practice and consequences | 25% | Short answers on testing, version control, documentation, ethics, footprint, and emerging technology |
Part C is the largest because judging an algorithm — not merely producing one — is what separates this course from last year’s. Part B is next because everything in Unit 3 and Unit 4 rested on decisions made in Unit 1.
What to expect, precisely
- Tracing. Two programs of twenty to forty lines. One builds a list of objects and walks it, asking what each object holds by the end; one is recursive and asks for the call stack drawn as it grows and unwinds. Tables are provided; use them. The technique is exactly Trace It.
- Arithmetic that is not decimal. Integer division and remainders, in at least two questions: one where the answer turns on which of the two a division gives you, and one that only comes out if you use the remainder for something.
- Values changing type, and values being compared. A number arriving as text and needed as a number, and the reverse; and an ordering question about things that are not numbers, where the point is that sorted text puts “10” before “9” and a person would not. Expect one short program where the conversion is where the bug is.
- Where the representation runs out. One question about the edges of how a machine stores numbers — the comparison that should be true and is not, or the total that drifts. Say what you would do instead, and why it works.
- Design. A paragraph describing somebody’s real problem — the kind The Model sent you into the building to find. Name the classes, their attributes and their methods, say which rule must never be broken and where you would enforce it, and name one thing you would refuse to model and why.
- Splitting the work up. One long routine printed in full, and the question of where you would cut it into subprograms — what each piece is handed and what it hands back. Marks are in the seams, not in the number of pieces.
- Reuse. A short question about something you already built: which part of the class you wrote in Unit 1 would you bring into this problem unchanged, which part would need changing, and what makes the difference.
- Containers. A stated problem with its operations listed. Choose between a list, a dictionary, and a stack or queue; give the cost of each operation under your choice; and name the input at which you would change your mind. A defended second-best answer scores above an undefended best one.
- Algorithms. Write a linear or binary search and one sort from a description rather than from memorised code, state the precondition each depends on, and compare two algorithms by counting comparisons rather than by asserting which is faster. Expect at least one question that walks a grid row by row, and at least one recursive routine where the marks are in the base case.
- Short answers. Four or five, a paragraph each. What a regression test is for and what it costs you to skip it; what a commit history is evidence of; what belongs in documentation a stranger will read; two elements of a published code of ethics and why a profession needs one written down; one emerging technology, who gains and who carries the cost; one honest measure that reduces computing’s footprint, and its limit.
How to prepare
- Re-derive, do not re-read. Take a class you wrote in Unit 1 and rebuild it from your own defence document without opening the file. Reading a page you already understand will not tell you what you could rebuild without it.
- Count, do not time. The examination has no machine on it, so practise the comparison counts by hand — a linear search and a binary search over the same twenty items, on paper, until the difference is something you can see rather than recite.
- Work the practice sets you skipped. Recursion Practice, Searching Practice, Sorting Practice and Efficiency Practice were written for exactly this, and the questions you left undone are the ones worth doing now.
- Read your own journal. The entries written on the days something broke are the densest revision material you own, exactly because you wrote them while the understanding was arriving rather than afterwards.
- Bring questions to Unit 4, Days 22 to 24. Those three classes are review, and they run on what the room asks. This page is the full statement of what is on the examination; the review classes are for the parts of it you cannot yet do.
Writing code with a pen
Indent as if the interpreter were watching, because a marker is. If an exact method name escapes you, write what you mean, name it clearly and carry on — a routine with one imperfect line and a structure a reader can follow earns nearly everything. A blank space earns nothing at all, and a paragraph explaining what you would have written earns more than the blank space.
Success criteria
| Quality | What it looks like on the paper |
|---|---|
| Traces are worked, not guessed | A table with a row per step, filled in as you go |
| Designs are defensible | Every attribute answers a question somebody would ask |
| Choices carry reasons | The container and the algorithm are argued, with costs |
| Preconditions stated | What must be true before your code is correct, written down |
| Costs are counted | Comparisons counted or growth stated, not asserted |
| Recursion terminates | A base case, and every call moving towards it |
| Short answers are specific | A named example, not a general opinion |
How this is assessed
On exactly the expectations this course has been working towards since the start of the course. Per How Marks Work, this paper and The Handover together make up the thirty per cent that is not the semester’s tasks, and the bigger share of it sits here. The other seventy is the semester’s six tasks and the milestone entries in your journal, The Software Project included.
Curriculum connection
A1.1
demonstrate the ability to use integer division and resultant remainders in computer programs;
Link to original
A1.2
demonstrate an understanding of type conversion (e.g., string-to-integer, character-to-integer, integer-to-character, floating point-to-integer, casting in an inheritance hierarchy);
Link to original
A1.3
demonstrate the ability to use non-numeric comparisons (e.g., strings, comparable interface) in computer programs;
Link to original
A1.4
demonstrate an understanding of the limitations of finite data representations (e.g., integer bounds, precision of floating-point real numbers, rounding errors) when designing algorithms;
Link to original
A1.5
describe and use one-dimensional arrays of compound data types (e.g., objects, structures, records) in a computer program.
Link to original
A2.2
use modular design concepts that support reusable code (e.g., encapsulation, inheritance, method overloading, method overriding, polymorphism);
Link to original
A3.2
create linear and binary search algorithms to find data in an array;
Link to original
A3.4
create a sort algorithm (e.g., bubble, insertion, selection) to sort data in an array;
Link to original
A3.5
create algorithms to process elements in two-dimensional arrays (e.g., multiply each element by a constant, interchange elements, multiply matrices, process pixels in an image);
Link to original
A3.6
design a simple and efficient recursive algorithm (e.g., calculate a factorial, translate numbers into words, perform a merge sort, generate fractals, perform XML parsing).
Link to original
C1.1
decompose a problem into modules, classes, or abstract data types (e.g., stack, queue, dictionary) using an object-oriented design methodology (e.g., CRC [Class Responsibility Collaborator] or UML [Unified Modeling Language]);
Link to original
C1.2
demonstrate the ability to apply data encapsulation in program design (e.g., classes, records, structures);
Link to original
C1.3
demonstrate the ability to apply the process of functional decomposition in subprogram design;
Link to original
C1.4
apply the principle of reusability in program design (e.g., in modules, subprograms, classes, methods, and inheritance).
Link to original
C2.1
demonstrate the ability to analyse a precondition (i.e., starting state) and a postcondition (i.e., ending state) in an algorithm;
Link to original
C2.2
compare the efficiency of linear and binary searches, using run times and computational complexity analysis (e.g., to analyse the number of statements executed, the number of iterations of a loop, or the number of comparisons performed);
Link to original
C2.3
compare the efficiency of sorting algorithms, using run times and computational complexity analysis (e.g., to analyse the number of statements executed, the number of iterations of a loop, or the number of comparisons performed);
Link to original
C2.4
identify common pitfalls in recursive functions (e.g., infinite recursion, exponential growth in recursive algorithms such as Fibonacci numbers).
Link to original
D1.1
outline strategies to reduce the impact of computers and related technologies on the environment (e.g., reduce, reuse, and recycle; turn computers and monitors off at end of day; participate in printer cartridge recycling) and on human health (e.g. ergonomic standards);
Link to original
D2.2
describe the essential elements of a code of ethics for computer programmers (e.g., ACM [Association for Computing Machinery] and IEEE [Institute of Electrical and Electronics Engineers] standards) and explain why there is a need for such a code (e.g., plagiarism, backdoors, viruses, spyware, logic bombs);
Link to original
D3.1
explain the impact of a variety of emerging technologies on various members of society and on societies and cultures around the world and on the economy;
Link to original