Software Engineering for Students A Programming Approach

238 Chapter 17 ■ Software robustness
some systems, when a user error arises, again it is the role of the software to cope. In many
situations, of course, when a fault arises nothing is done to cope with it and the system
crashes. This chapter explores measures that can be taken to detect and deal with all types
of computer fault, with emphasis on remedial measures that are implemented by software.
We will see in Chapter 19 on testing that eradicating every bug from a program is
almost impossible. Even when formal mathematical methods for program development
are used to improve the reliability of software, human error creeps in so that even mathematical
proofs can contain errors. As we have seen, in striving to make a piece of software
as reliable as possible, we have to use a whole range of techniques
Software fault tolerance is concerned with trying to keep a system going in the face
of faults. The term intolerance is sometimes used to describe software that is written
with the assumption that the system will always work correctly. By contrast, fault tolerance
recognizes that faults are inevitable and that therefore it is necessary to cope with
them. Moreover, in a well-designed system, we strive to cope with faults in an organized,
systematic manner.
We will distinguish between two types of faults – anticipated and unanticipated.
Anticipated faults are unusual situations, but we can fairly easily foresee that they will
occasionally arise. Examples are:
■ division by zero
■ floating point overflow
■ numeric data that contains letters
■ attempting to open a file that does not exist.
What are unanticipated faults? The name suggests that we cannot even identify, predict
or give a name to any of them. (Logically, if we can identify them, they are anticipated
faults.) In reality this category is used to describe very unusual situations.
Examples are:
■ hardware faults (e.g. an input-output device error or a main memory fault)
■ a software design fault (i.e. a bug)
■ an array subscript that is outside its allowed range
■ the detection of a violation by the computer’s memory protection mechanism.
Take the last example of a memory protection fault. Languages like C++ allow the
programmer to use memory addresses to refer to parameters and to data structures.
Access to pointers is very free and the programmer can, for example, actually carry out
arithmetic on pointers. This sort of freedom is a common source of errors in C++ programs.
Worse still, errors of this type can be very difficult to eradicate (debug) and may
persist unseen until the software has been in use for some time. Of course this type of
error is a mistake made by a programmer, designer or tester – a type of error sometimes
known as a logic error. The hardware memory protection system can help with the
detection of errors of this type because often the erroneous use of a pointer will eventually
often lead to an attempt to use an illegal address.