DATA FLOW ANOMALY

5.2 DATA FLOW ANOMALY

An anomaly is a deviant or abnormal way of doing something. For example, it is an abnormal situation to successively assign two values to a variable without using the first value. Similarly, it is abnormal to use a value of a variable before assigning a value to the variable. Another abnormal situation is to generate a data value and never use it. In the following, we explain three types of abnormal situations concerning the generation and use of data values. The three abnormal situations are called type 1, type 2, and type 3 anomalies [1]. These anomalies could be manifestations of potential programming errors. We will explain why program anomalies need not lead to program failures.

Defined and Then Defined Again (Type 1) : Consider the partial sequence of computations shown in Figure 5.1, where f1(y) and f2(z) denote functions with the inputs y and z , respectively. We can interpret the two statements in Figure 5.1 in several ways as follows:

• The computation performed by the first statement is redundant if the second statement performs the intended computation.

• The first statement has a fault. For example, the intended first compu- tation might be w = f1(y).

• The second statement has a fault. For example, the intended second computation might be v = f2(z).

A fourth kind of fault can be present in the given sequence in the form of

a missing statement between the two. For example, v = f3(x) may be the desired statement that should go in between the two given statements.

: x = f1(y) x = f2(z)

Figure 5.1 Sequence of computations showing data flow anomaly.

114 CHAPTER 5 DATA FLOW TESTING

It is for the programmer to make the desired interpretation, though one can interpret the given two statements in several ways, However, it can be said that there is a data flow anomaly in those two statements, indicating that those need to be examined to eliminate any confusion in the mind of

a code reader. Undefined but Referenced (Type 2) : A second form of data flow anomaly is

to use an undefined variable in a computation, such as x = x − y − w, where the variable w has not been initialized by the programmer. Here,

too, one may argue that though w has not been initialized, the programmer intended to use another initialized variable, say y, in place of w. Whatever may be the real intention of the programmer, there exists an anomaly in the use of the variable w, and one must eliminate the anomaly either by initializing w or replacing w with the intended variable.

Defined but Not Referenced (Type 3) : A third kind of data flow anomaly is to define a variable and then to undefine it without using it in any subsequent computation. For example, consider the statement x = f (x, y) in which a new value is assigned to the variable x . If the value of x is not used in any subsequent computation, then we should be suspicious of the computation represented by x = f (x, y). Hence, this form of anomaly is called “defined but not referenced.”

Huang [2] introduced the idea of “states” of program variables to identify data flow anomaly. For example, initially, a variable can remain in an “undefined” (U ) state, meaning that just a memory location has been allocated to the variable but no value has yet been assigned. At a later time, the programmer can perform

a computation to define (d ) the variable in the form of assigning a value to the variable—this is when the variable moves to a “defined but not referenced” (D ) state. At a later time, the programmer can reference (r ), that is, read, the value of the variable, thereby moving the variable to a “defined and referenced” state (R). The variable remains in the R state as long as the programmer keeps referencing the value of the variable. If the programmer assigns a new value to the variable, the variable moves back to the D state. On the other hand, the programmer can take an action to undefine (u) the variable. For example, if an opened file is closed, the value of the file pointer is no more recognized by the underlying operating system, and therefore the file pointer becomes undefined. The above scenarios describe the normal actions on variables and are illustrated in Figure 5.2.

However, programmers can make mistakes by taking the wrong actions while

a variable is in a certain state. For example, if a variable is in the state U —that is, the variable is still undefined—and a programmer reads (r ) the variable, then the variable moves to an abnormal (A) state. The abnormal state of a variable means that a programming anomaly has occurred. Similarly, while a variable is in the state

D and the programmer undefines (u) the variable or redefines (d ) the variable, then the variable moves to the abnormal (A) state. Once a variable enters the abnormal state, it remains in that state irrespective of what action—d, u, or r —is taken. The actions that take a variable from a desired state, such as U or D , to an abnormal state are illustrated in Figure 5.2.

5.3 OVERVIEW OF DYNAMIC DATA FLOW TESTING

Legend: States

Actions

U : Undefined

d : Define

D : Defined but not referenced

r : Reference

R : Defined and referenced

u : Undefine

A : Abnormal Figure 5.2 State transition diagram of a program variable. (From ref. 2. © 1979 IEEE.)

Now it is useful to make an association between the type 1, type 2, and type 3 anomalies and the state transition diagram shown in Figure 5.2. The type 1, type 2 , and type 3 anomalies are denoted by the action sequences dd , ur , and du, respectively, in Figure 5.2.

Data flow anomaly can be detected by using the idea of program instrumen- tation . Intuitively, program instrumentation means incorporating additional code in a program to monitor its execution status. For example, we can write addi- tional code in a program to monitor the sequence of states, namely the U , D , R, and A, traversed by a variable. If the state sequence contains the dd , ur , and du subsequence, then a data flow anomaly is said to have occurred.

The presence of a data flow anomaly in a program does not necessarily mean that execution of the program will result in a failure. A data flow anomaly simply means that the program may fail, and therefore the programmer must investigate the cause of the anomaly. Let us consider the dd anomaly shown in Figure 5.1. If the real intention of the programmer was to perform the second computation and the first computation produces no side effect, then the first computation merely represents a waste of processing power. Thus, the said dd anomaly will not lead to program failure. On the other hand, if a statement is missing in between the two statements, then the program can possibly lead to a failure. The programmers must analyze the causes of data flow anomalies and eliminate them.