Software Engineering for Students A Programming Approach

242 Chapter 17 ■ Software robustness
17.3 ● Fault detection by hardware
We have already seen how software checks can reveal faults. Hardware also can be vital
in detecting consequences of such software errors as:
■ division by zero, more generally arithmetic overflow
■ an array subscript outside the range of the array
■ a program which tries to access a region of memory that it is denied access to, e.g.
the operating system.
Of course hardware also detects hardware faults, which the hardware often passes on
to the software for action. These include:
■ memory parity checks
■ device time-outs
■ communication line faults.
Memory protection systems
One major technique for detecting faults in software is to use hardware protection mechanisms
that separate one software component from another. (Protection mechanisms
have a different and important role in connection with data security and privacy, which
we are not considering here.) A good protection mechanism can make an important
contribution to the detection and localization of bugs. A violation detected by the
memory protection mechanism means that a program has gone berserk – usually
because of a design flaw.
To introduce the topic we will use the analogy of a large office block where many
people work. Along with many other provisions for safety, there will usually be a number
of fire walls and fire doors. What exactly is their purpose? People were once allowed
to smoke in offices and public buildings. If someone in one office dropped a cigarette
into a waste paper basket and caused a fire, the fire walls helped to save those in other
offices. In other words, the walls limited the spread of damage. In computing terms,
does it matter how much the software is damaged by a fault? – after all it is merely code
in a memory that can easily be re-loaded. The answer is “yes” for two reasons. First, the
damage caused by a software fault might damage vital information held in files, damage
other programs running in the system or crash the complete system. Second, the
better the spread of damage is limited, the easier it will be to attempt some repair and
recovery. Later, when the cause of the fire is being investigated, the walls help to pinpoint
its source (and identify the culprit). In software terminology, the walls help find
the cause of the fault – the bug.
One of the problems in designing buildings is the question of where to place the firewalls.
How many of them should there be, and where should they be placed? In software
language, this is called the issue of granularity. The greater the number of walls,
the more any damage will be limited and the easier it will be to find the cause. But walls
are expensive and they also constrain normal movement within the building.