Computational thinking

representation arrived at by removing unnecessary details e.g. a computer model (climate change, flight simulation), map of the London underground (simple model of actual geography of tube stations)

Machine code (enter 0/1, which is unrelated) –> mnemonic codes (complex, can’t run on another computer) –> high level (don’t need to worry about memory, etc.) Finally, programmers can focus on problem rather than technological details

Grouping by common characteristics to arrive at a hierarchical relationship of the ‘is a kind of’ type e.g. dog ‘is a kind of’ animal, so is a cat and a mouse

Details of how data is represented is hidden e.g. not interested in how numbers are represented in a program

Involves removing details until the problem reduces to one which has already been solved

• Input – information relevant to the problem, passed in as parameters into a subroutine • Output – solution to the problem, passed back from a subroutine • Condition specified with the documentation for a function to prevent it from crashing e.g. an algorithm looking for the largest number in an empty list will crash, so has a precondition of the length of the list being >0

Having functions that have been written, debugged and tested saves effort for doing simple tasks like adding or deleting from stacks, queues, etc, so programmers can focus on main problem

Abstraction hides details of how sending an email, playing music, etc is actually done, only focusing on which button to press Using a procedure to carry out a sequence of steps for achieving some task e.g. calculating a student’s grade Procedure interface hides details of how a procedure works, only needing to know what the procedure is called and which arguments to pass and what order to write them in

Large problems must be broken down into sub-problems before that can be solved e.g. presenting user with menu of choices, each of which will have a self-contained module - Top-down design – technique of breaking down a problem into major tasks to be performed, further broken down into separate subtasks until each subtask is simple enough to be written as a module or subroutine

Easy to write program Simple to test and maintain Modules are self-contained and well documented (inputs, outputs, preconditions), so changes can be made easily, not affecting main program

Easy to understand, debug, maintain if it is clearly documented Can be tested independently Can be reused by other programmers/other parts of the program Several subroutines can be coded at the same time, reducing time taken to complete a large project Large projects become easier to monitor and control

Entering a new program – ‘file, new’ will present a blank screen to type the program; ‘file, save’ saves program Compiling and running a program (debugging) – compiler/interpreter translates code into machine code and reports any syntax errors (tells which line it is on); logic errors can be spotted by setting a breakpoint (causes program to stop on that line), setting a watch on a variable (displays value of variable every time it changes), stepping through a program line by line to see what is happening

• reduces development time since unnecessary details are ignored • program is more likely to solve problem since unnecessary details don’t hinder the main purpose • reduces complexity of code, so can be run on lower spec computer