Computational thinking Flashcards
Representational abstraction
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)
Abstraction applied to high level programming languages
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
Abstraction by generalisation
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
Data abstraction
Details of how data is represented is hidden
e.g. not interested in how numbers are represented in a program
Problem abstraction
Involves removing details until the problem reduces to one which has already been solved
Input, output and preconditions
- 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
Need for reusable program components
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
Procedural abstraction
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
Problem decomposition
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
Advantages of problem decomposition
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
Advantages of subroutines
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
Facilities of an IDE
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
Advantages of abstraction
- 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
