AG

Producing Robust Programs - OCR GCSE

Defensive Design Considerations

Defensive design is used to make sure the program runs correctly no matter what the user does. This can be done by thinking about what the user might do and preparing for that situation.

There are three areas that defensive design includes:

  • Protecting against unexpected user inputs. Eg. entering a letter when they were supposed to enter a number.

  • Maintainability - making sure code is readable and understandable

  • Minimising/removing bugs

Anticipation and protection is done through: validation, sanitisation, authentication, maintenance and testing


Authentication

The process of a user confirming they are who they say they are. Often done through a password and username. For higher levels of security other methods may be used such as two factor authentication. Factors of authentication:

  • Something you are - eg. username or bank account number

  • Something you know - eg. password or pin

  • Something you have - eg. biometrics or swipe card


Input Validation

Makes sure all data that user inputs is in the correct format. Applied rules to inputted data, if the data does not meet these rules then it is rejected. Types of validation:

  • Range check - input must be within range, usually numbers or dates.

  • Length check - input can't be too long or short

  • Presence check - data value must be entered

  • Format check - data must be in correct format. Eg. data in format DD/MM/YYYY

  • Type check - data must be the correct type. Eg integer

Most programs use one or more of these checks.

Validation doesn't make sure data is correct, just possible. This means the program doesn't know if the user has entered the correct data. The program uses verification checks (when they repeat the data to the user and ask if it is correct) to combat this. This reduces errors.


Maintainability

Ensures the program can be maintained over time. If the program is written in a maintainable style then it will be easier to add to it, improve it or debug it for other people who haven’t written the original program or for the person who has.

  • Comments - lines of code that tell the programmer what the code is doing so they can understand it more easily. Are not executed when the program runs. In python a comment comes after a #.

  • Naming conventions - Choosing a variable name that represents the data that it holds, makes code easier to understand. Eg. ‘h’ is meaningless so it would be better to use ‘height’ as a variable name.

  • Indentation - Putting spaces before a line of code to show that it is part of a section. Makes code easier to read.


Testing

Testing is done to help the programmer remove bugs and errors and to make sure the program functions correctly. Types of testing:

  • Iterative testing - carried out while the program is being developed. Programmer writes a section of code then tests it for errors, then edits it and then retests it.

  • Final testing - carried out when the whole program is complete. Programmer tests the program after the whole code has been written.


Identifying Errors

There are two types of errors, syntax errors and logic errors.

  • Syntax errors - When code doesn't follow rules of language. Eg missing brackets or using a variable before it has been called. Program will not run if it has syntax errors. IDEs will usually point syntax errors to programmer.

  • Logic errors - Error in the way the program works. Program doesn't work as expected. Eg. creating an infinite loop, referring to elements in an array that is outside of the array's scope. Logic error will not stop the program from running usually.


Selecting and Using suitable test data

Test data is used to test if a program is working or not. Should cover a range of possible inputs. The three types of test data are:

  • Valid data - possible data that the program should accept and process

  • Extreme data - valid data that falls at the boundary of possible ranges

  • Invalid data - data that program should not accept or process

Testing tables: how tests are laid out, indicates: test number, description of what test will check, test data being used, type of test, expected outcome and actual outcome.