next up previous contents
Next: Components Up: No Title Previous: Testers vs. Developers

Our Phase II Prototype Tools

The tool that we are delivering to NIST is named ASSERT++. ASSERT++ has two sub-utilities:

  1. A utility that supports the assertion language that we have created. This works for both Java and C++.
  2. A utility that we call CBrowse, which recommends where assertions should be placed based on the testability scores.
These tools are quite simple to use, and are well suited for the tester/developer team that we have advocated.

The first tool currently works for Solaris but could easily be ported to other UNIX platforms like SunOS, HPUX, and Linux. Also, this tool could be ported to Windows-NT or Windows95 quite easily. The CBrowse tool that does the testability-based placement only works on the UNIX (currently Solaris) platforms.

The first utility allows a developer to include complex assertion statements directly in the source code of a program that he or she is working with. The assertion statements have the appearance of C++ / Java statements, and are included in the source code just like any other programming statement. These statements are transformed into valid C++ / Java statements by this utility, and can then be evaluated at run-time. This utility is composed of three parts: (1) the shell, (2) the instrumentor, and (3) the compiler. These components work together to allow the user to place complex assertions in his or her code, and to have these assertions evaluated at run time.

The second utility, CBrowse, is the tool that allows the user to see his or her code with the testability scores, thus suggesting where assertions are needed. For this tool to work properly, it must have access to the source code as well as to the testability scores after sensitivity analysis is performed.

Figure 4 shows how this Phase II innovation fits in the software Validation and Verification process. Here, we see that the original source-code first receives software testability analysis. >From that, the tester looks at the results and makes recommendations to the developer as to where assertions should be placed. The developer then derives the appropriate predicates, and the assertion instrumentor then adds the assertions to the source code, thus creating the annotated source-code version. Now, this new version of the code is ready for testing.

 
Figure 4:   The Testability-guided Assertion Placement Process.





next up previous contents
Next: Components Up: No Title Previous: Testers vs. Developers



Roger Gima
Tue Jan 20 16:43:17 EST 1998