Please enable JavaScript.
Coggle requires JavaScript to display documents.
2.3 Producing Robust Programs - Coggle Diagram
2.3 Producing Robust Programs
Defensive Design considerations
Input validation
Checking data input by the user meets specific criteria/rules before being processed
Presence check: Some data has been entered, e.g. rejecting blank inputs
Format check: The input is in the correct format, e.g. dd/mm/yyyy
Range check: The input is within the correct range, e.g. between 1 and 2
Length check: The input has the correct (or min/max) number of characters, e.g. password
Type check: The input is in the correct data range, e.g. Integer
By using Input validation techniques, a programmer makes their program:
More user friendly
Prevents further errors occurring later in the algorithm
More robust
Authentication
Ensuring data is secure and protected, as well as preventing bots from submitting spam data
Username and passwords to access systems
Recovering a password requiring to click on a link within the email that is sent to the registered address
Encryption of data files
Using software such as reCAPTCHA to verify that data entries are being made by a human
Anticipating misuse
Division by zero
In maths, there is no number which when multiplied by zero returns a non-zero number
Therefore the ALU cannot compute a division by 0
A programmer should always check that a variable is not zero before attempting a division by said variable value
Communication error
Online systems require connections to host servers
If this connection is dropped, unable to be established, or the server is overloaded, it could potentially cause a program to crash or hang when loading/saving data
A programmer should enable ways for the user to cancel requests or for them to fail gracefully, reporting the connection error, with the program being able to automatically resume when the connection is re-established
Peripheral errors, e.g. printers
If a program outputs a hardcopy, the printer may run out of ink, or jam
The programmer should not assume that an output to a printer was successful and always have options to reprint reports or receipts
Disk errors
Programs that read and write to files need to handle many exceptions, including
The disk being out of space
The data in the file being corrupt
The file/folder not being found
The end of the file being reached
Robust programs will handle all these situations by checking files and data before attempting to use them for further processing
Maintainability
Use comments to:
Explain the purpose of the program
Explain sections of code. Typically selections, iterations and procedures
Explain unusual approach's that were necessary
Visually divide sections of a program
Use white space to make sections of a program easier to see
Use indentation for every selection and iteration branch
Use descriptive variable names and explain their purpose with a comment when declared
User procedures and/or functions to:
Structure the code
Eliminate duplicating code
Use constants declared at the top of a program
Testing
Types of testing
Iterative testing
Program branches are checked for functionality
Checking new modules do not introduce new errors in existing code
Each new module is tested as it is written
Tests to ensure the program handles erroneous data and exceptional situations
Performed whilst the software is being developed
Final/Terminal testing
Testing the program produces the required results with normal, boundary, invalid and erroneous data
Checking the program meets the requirements with real data
Testing that all modules work together (integration testing)
A beta test may find more errors
Performed when the program is finished
Reasons for testing
To check that the program has an acceptable performance and usability
To ensure that unauthorised access is prevented
To ensure there are no errors (bugs) in the code
To check the program meets the requirements
Syntax and logic errors
Syntax errors
The program will not run (compiled languages)
Syntax errors can happen because
Variables are not declared or initialised before use
Incompatibility of variables types, e.g. total = "A" (total declared as an integer
Using assignments incorrectly, e.g. 2 + 2 = x
Keywords misspelt, e.g.
prnt
("Enter input")
The rules of the program have been broken
Logic errors
The program runs but does not give the expected output
Logic errors can happen because:
Conditions and arithmetic operations are wrong
Sequence of commands is wrong
Division by zero
Exceptions, e.g. file not found
Suitable test data
Test data needs to include a range of:
Boundary inputs
Data of the correct type which is on the edge of accepted validation boundaries
Invalid inputs
Data of the correct type but outside accepted validation checks
Normal inputs
Data which should be accepted by a program without causing errors
Erroneous inputs
Data of the incorrect type which should be rejected by a computer system
This includes no input being given when one is expected
Refining algorithms to make them more robust
Making sure "bad" data doesn't crash the program
Making sure prompts to the user are descriptive and helpful
Those inputs could be invalid data or erroneous data
Making sure only data of the correct "data type" are entered
Writing code which anticipates a range of possible inputs
Checking and handling missing or blank data
One common option is to use simple exception handling commands available in most programming languages