|
The state of scientific and engineering software is well described by Professor
Les Hatton at the University of Kingston in his paper
"The Chimera of Software Quality".
It may not be as good as you hope!
An engineer writes a program, often using routines borrowed from existing work.
It crashes.
The engineer debugs it until it runs.
It gives silly results
The engineer debugs it until the results are about right.
Then the engineer stops.
Fortran programs are used to design aircraft, ships, bridges, power plant,
space craft... The engineers already know that the results they generate are about right.
Man years of program development on expensive equipment are invested for the last few percent
of accuracy which go beyond the engineer's intuition.
Those last few percent depend on the quality of the code. But in 100,000 lines how can we
know that all of the subroutine arguments are consistent, that none of the statements run into
the comment field beyond column 72; that there are no commas missing from lists? Compilers and
linkers are unlikely to find these problems. Imagine the labour of checking 5000 subroutine
call sites visually to see whether the arguments are consistent with the sub-program
definitions. These checks are automated by FPT.
This example came from a real simulation program
The Q.A. checks made by FPT include the detection of:
Fortran keywords and intrinsic function names apparently used for
variables and arrays
Text running into the comment field at the end of the fixed format Fortran line
Space characters embedded in names or numbers
Variables which are read but never written, written but never read or
declared but never used. The check is made across all sub-programs, taking into account the
way different routines access modules and COMMON blocks
Subroutine and function arguments of the wrong data type or size
(e.g. REAL*8 for REAL*4)
Named COMMON block locations with different types or addresses in
different sub-programs
Different objects which occupy overlapping memory in COMMON blocks
Fortran parameters with different values in different sub-programs
Variables in COMMON blocks, derived types, STRUCTURE constructs or EQUIVALENCE
statements, which are not aligned to the appropriate byte boundaries in memory
These checks can be configured by the user, and are made with
surprising speed, even for large applications. They may be made either interactively or in
batch mode.
One user summarized the power of Fortran Partner™ by saying:
"...we needed a black box that could look at code before our developers spent
£20,000 on a day's use of the simulator. FPT paid for itself on just one day! "
| 
