RECON2 - OVERVIEW

A Tool for Software ``Reconnaissance''

Reconnaissance: In military science, the act or process of obtaining information about an enemy area...
[Webster's Dictionary]

Software Engineers frequently need to ask: "Where in this program is feature X implemented?" RECON implements a simple, yet powerful method for addressing this question, based on comparing the execution paths of different test cases. For example, the program in Figure 1 is part of a reverse Polish notation calculator from a well known text [1]. We could ask "where is the division operation handled?" Using RECON, a Software Engineer would perform four steps:

1. "Instrumentation Process": Tell RECON2 to make an instrumented copy of the program
2. "Compile Process": Compile the instrumented copy to an executable
3. "Test Process": Run test cases using this executable, for example:
• One case involving division (the "/" operator)
• One case with each of the 3 other operators ("+", "-", "*")
4. "Analysis Process:" Tell RECON2 to analyze the 4 test cases (1 with the division feature, 3 without the feature).

RECON2 tracks execution of each branch of the original program. Each ``if'' or ``while'' statement has two branches, one for the true side and one for the false. Each switch has as many branches as there are different values for the switch index.

RECON2 counts the number of test cases "with" the feature that executed the branch and the number of total test cases that executed the branch. Branches that executed when the feature was demonstrated are probably involved in implementing that feature.

You can ask for a ``deterministic'' analysis that only gives branches for which

test cases with the feature = total test cases

(test cases with the feature) x 100 / (total test cases)

      main()
         {
         int type;
         double op2;
         char s[MAXOP};
         while ((toupper(type = getops(s))) !='Q')
    >>>>> 47 ("/")
         switch (type)
           {
              case NUMBER: push(atof(s));
                 break;
              case '+': push(pop() + pop());
                 break;
              case '*': push(pop() * pop());
                 break;
              case '-': op2 = pop();
                 push(pop() - op2);
                 break;
              case '/': op2 = pop();
     >>>>> T
                 if (op2 != 0.0)
                    push(pop() / op2);
                 else
                    printf("error: zero divisor");
                 break;
              case NEWLINE: printf(" %.8g", pop());
                 break;
              default:printf(" %s unknown", s);
                 break;
           }
           return 0;
         }

Figure 1 shows a sample of the output of RECON2. A listing of the program is created with branches that the Software Engineer should investigate marked with ">>>>>" so that they can be easily found by searching in an editor.

For if and while statements, the predicate value associated with the feature is shown as ``T'' or ``F'' or possibly both. For switch statements, the value of the switch expression is given, together with its ASCII character equivalent, if any.

In this particular case, RECON2 noticed that only test cases with division executed the statement

switch (type)

with type = 47 so it marked that statement with:

>>>>> 47 ('/')

This is the statement where the division operator is detected.

Similarly RECON noticed that only test cases with division gave a true value at the statement

if (op2 != 0.0)

so it marked that statement with:

>>>>> T

This statement is inside a code segment that only handles division. Any such conditional statement will be detected.

Environment

RECON2 is written in ANSI Standard C and is distributed in source form. A version for pre-ANSI compilers and a pre-compiled version for MS-DOS platforms are also available. It has been used successfully on Unix and MS-DOS operating systems. RECON2 analyzes target systems written in C. It will also analyze most C++ code but with some limitations. RECON2 tools for other target languages are under development.

Conclusions

We expect software ``reconnaissance'' and the RECON2 tool to be useful in many program understanding situations, but it is a complement, not a replacement, for other tools. The results depend both on the user's ability to find good test cases and on the way the original designer may have combined features in the code. RECON2 won't necessarily find all the code related to a particular feature but our experiments show it will usually find good starting points for a search [2, 3].

Acknowledgment

Our thanks to the students in the Software Engineering Project course who have helped develop the theory and the operation of the RECON2 tool.

References

1. B. Kernighan, D. Ritchie, "The C Programming Language, Second Edition", Prentice-Hall, 1988.
2. N. Wilde, J. Gomez, T. Gust, D. Strasburg, "Locating User Functionality in Old Code", Proc. IEEE Conf. on Software Maintenance 1992, Orlando, November, 1992, pp. 200 - 205.
3. M. Scully, "Augmenting Program Understanding Strategies with Test Case Based Methods", SERC-TR-68-F, Software Engineering Research Center, University of Florida, Gainesville, Florida 32611, July 1993.