Michael A. Hennell

A Measure of Control Flow Complexity in Program Text

This paper discusses the need for measures of complexity and unstructuredness of programs. A simple language independent concept is put forward as a measure of control flow complexity in program text and is then developed for use as a measure of unstructuredness. The proposed metric is compared with other metrics, the most notable of which is the cyclomatic complexity measure. Some experience with automatic tools for obtaining these metrics is reported.

On program analysis

Interpretation and Static Analysis David Schmidt Kansas State University Four parts:

On the relationship between two control-flow coverage criteria: all JJ-paths and MCDC

Abstract Coverage criteria may be used to assess the adequacy of software test data. Improved test data, that takes account of any inadequacies identified by lack of coverage, may then be developed. It is natural to seek ways of comparing different criteria and the ‘subsumes’ relationship is one such way: one criterion subsumes another, if satisfying the first always implies satisfaction of the second. This paper considers two criteria: ‘all jump-to-jump paths’ (all JJ-paths) and ‘modified condition/decision coverage’ (MCDC). It might be anticipated that there would be a relationship between these criteria since both are based on advanced control-flow concepts. MCDC has particular importance since it is involved in the DO-178B standard for avionics software. However, it is shown that ‘all JJ-paths’ and MCDC are, in general, incomparable, but for programs written under certain specific constraints ‘all JJ-paths’ subsumes MCDC.

A Static Analysis of the NAG Library

This paper reports results obtained from a static analysis of the NAG Mark 4 Fortran numerical algorithms library.

Some problems concerning the automatic translation of Fortran to Algol 68

We consider briefly some of the problems encountered in the initial implementation of a system to automatically convert Fortran programs to Algol 68.

Quantifying the test effectiveness of Algol 68 programs

In this paper we describe how a software testbed is used to determine the quality of testing of Algol 68 programs. The system monitors the execution of an Algol 68 program and obtains a run-time execution history. This history is then compared with the results of a static analysis and three levels of testing are calculated. The third level is an extension to Algol 68 of a method originally devised for analysing Fortran IV programs. The system has been used extensively in the coordination stage of the NAG Algol 68 numerical algorithms library and we quote some results obtained from an analysis of stringent tests on these library routines.

Data flow analysis of recursive procedures

Data flow analysis is a technique used to detect suspicious variable usage within a program. Its evaluation requires analysis of the flow graphs of the program. This causes difficulties when the program contains recursive procedures because in order to fully evaluate each procedure, the data flow value of its own recursive invocation needs to be known first. This however cannot be determined until the whole procedure has been analysed. This paper describes a technique for resolving this difficulty and successfully completing data flow analysis on recursive procedures.

Static dataflow-aided weak mutation analysis (SDAWM)

Abstract A new static analysis methodology (known as static dataflow-aided weak mutation (SDAWM) intended for use as a preprocessor to a variable mutation system is described. The procedure is based around a marriage of existing static dataflow analysis concepts and weak mutation ideas. The (dataflow) path expression of a variable is analysed to assess what the impact of strong mutation would be if it was performed. A methodology is presented that pre-empts strong or weak mutation by removing a significant number of variable mutants statically and without actually creating them, thus saving processor time later.

Program analysis and systematic testing

The authors of this chapter have had considerable experience with the use of automated testing tools, both in the real world of industry and commerce, as well as in a research environment. The automated testing tools referred to are various derivatives of the LDRA Testbeds [1]. These tools in various languages, namely Ada, C, Cobol, Coral 66, Fortran, Pascal, PL/1, and PL/M86 have been used in industry since 1975 and have been the subject of extensive experimentation at the University of Liverpool since 1970.