Static Analysis of Ada Programs

Abstract

The upcoming standardization of the Ada Semantic Interface Specification (ASIS) makes possible the development of portable static analysis tools for Ada programs. This paper introduces this class of back-end CASE tools, lists their capabilities, and describes how they can be used during the software-development process to increase overall software quality. The description is based on one such tool: the Ada Analyzer developed by Little Tree Consulting.

Keywords: Ada, program analysis, quality, ASIS

The Promise of Stoneman

Along with the Steelman requirements for a new programming language, completed in 1978 and eventually named Ada, came a parallel set of requirements for software-development tools-Stoneman. Stoneman defined requirements for an Ada Programming Support Environment (APSE) that would complement and enhance the language's ability to support modern software-engineering practice. At the core of this environment concept were two key goals:

• A common set of operating-system services that would support the portability of tools from one development environment to another
• Information-storage and exchange facilities that would support the interoperability of tools within the development environment, enhancing the capabilities of all resident tools

The inevitable march of UNIX has made the first goal both implausible as originally defined, yet ironically within reach today. But the real grail of Stoneman was to define information-exchange semantics so that tools could not only coexist through inward interaction with a common OS but also reach horizontally into the information generated by other tools along the circumference. In the following diagram, the inward-pointing arrows represent interaction with a common OS, and the curved arrows represent interchange of information between tools.

There have been a few attempts to implement the Stoneman requirementsãfor example, the Portable Common Tool Environment (PCTE)-Ada in Europe and the Common APSE Interface Set (CAIS) in the United States. PCTE has had some success with the first goal, but both efforts unfortunately failed to provide any significant support for the sharing of information between tools. Individual vendors have naturally integrated their compiler with their own editor and debugger, but rarely has this interoperability extended outside the vendor's in-house toolset.

Ada Semantic Interface Specification

Static Analysis Tools

Design and Program Structure

The high-level structure of a program is often difficult to see when looking through each individual package of an Ada program. The static and dynamic dependencies between components of a program form a key part of a program's design. The following static analysis capabilities offer insight into the design structure of an Ada program:

• Understanding packaging and with dependencies
• Determining compilation closure and compilation order
• Identifying subunits and subunit candidates
• Locating declaration distribution and dependencies
• Comparing type declarations and their usage
• Analyzing object declarations and their references
• Locating generic declarations and their instantiations
• Determining subprogram call trees
• Finding program branch points (execution-path analysis)

Code Correctness

Code correctness clearly is one of the most important goals in programming. Even with the best development practice, it is all but impossible to avoid programming mistakes entirely. Although it is equally impossible to judge with certainty that a program construct is incorrect, constructs with a high likelihood for error can be identified for further inspection by the analyst. The following program characteristics can be used to find potential problems with code correctness:

• Use before set of variables
• Use of parameter defaults
• Use of when others clauses
• Inconsistent exception raising, propagation, and handling
• Locating subprogram and expression complexity (McCabe, number of statements, nesting level, external references, and so on)
• Divide-by-zero potential
• Use of System.Address
• Use of unchecked conversion (size matching and so on)
• Use of literals that violate static constraints

Code Efficiency

Software efficiency is most negatively affected by the selection of inappropriate implementation algorithms. Such problems are identified most effectively through code reviews and are difficult to detect statically with tools. It is possible, however, to identify constructs that either generate large amounts of code or execute more slowly. It is also possible to locate redundancy in software as well as places where compiler directives such as pragma Inline or pragma Pack would positively or negatively affect software efficiency. The following information impacting program efficiency can be statically collected:

• Inline candidates using subprogram size and number of call sites as criteria
• Reference to parameters and global objects by subprograms
• Use of dynamic allocation (access type and allocators)
• Redundant expressions and constants
• Operator selection
• Loop nesting (across subprogram calls)
• Type nesting and use of unconstrained types
• Automatic type initialization compared with local initialization
• Object size
• Location of any kind of Ada construct (if the compiler has difficulty with a specific construct, all usages can be quickly located for additional analysis)

Conformance to Programming Standards and Readability

Almost every project has a set of programming guidelines. Sometimes these criteria are a fairly strict set of rules that must not be violated without explanation. Other rules are simply warnings. Static tools can be used to locate nonconformance to standards in the following categories:

• Ada style guidelines such as those from the Software Productivity Consortium
• Ada 95 compatibility checking
• Naming selection (sorted by kind of declaration)
• Consistent use of selected constructs such as renaming

Portability and Compatibility

Software developed on host development environments is often cross-compiled for another target. Developing software that is compatible with the target-dependent features of the cross-compiler can be checked, in part, with static analysis tools. More stringent portability requirements can also be checked with the following information:

• Use of predefined types
• Checking of representation specifications
• Use of duplicate unit names when the code is developed in multiple libraries
• Use of host-specific and target-dependent features and/or interfaces

Software Content

Tools in this category can be used to support any of the above analysis objectives or to generate status information for internal use or delivery to the customer:

• Construct counting and location (locates the use of any specific Ada construct)
• Source lines of code (SLOC) counting, including options for semicolon limitations, comments, and blank lines
• Detailed construct analysis of:

  -Construct counting and location (locates the use of any specific Ada construct)

  -Source lines of code (SLOC) counting, including options for semicolon limitations, comments, and blank lines

• Detailed construct analysis of:

  -Tasking

  -Generics

  -Subprogram data reference

  -Exceptions

Use of Analysis Tools

Online Analysis

The utility of static analysis information can be greatly enhanced when generated in hypertext form. The Ada Analyzer generates all reports in hypertext form to minimize the time required to perform analysis and affect quality improvements. Hypertext tables can be used to display condensed forms of information, with each row of the table containing a separate instance of an Ada construct that matches the analysis criteria. Table columns contain attributes of each construct and help to characterize details or provide the context in which each construct appears. In hypertext output forms, some columns are connected back to the construct or attribute in the software under analysis. In this way, tables can be scanned for a quick overview, with traversal used to gather more information when necessary. If a change is necessary, it can be made immediately in code, since traversal arrives at the exact point in the code where the construct was located.

Support for Code Reviews

Code reviews should be an essential part of any large-scale software-development process. In some studies, extensive use of peer review uncovered more programming defects than testing and debugging combined. Code reviews, when used at selective points in the development process, can provide a large return on the time invested. Early code reviews can ensure that a consistent design and structure is used throughout the program. This can reduce implementation costs and avoid the need to restructure in later development phases. Code reviews held after the code is implemented can find programming errors, ensure a consistent use of the Ada language and the application's meta-language interfaces, and improve the execution efficiency of the code.

One problem is that code reviews require a large time investment by a large number of project members. Information generated by static analysis tools can make the process of preparation for code review less expensive in several ways. Online analysis can be used by reviewers before the review meeting to prepare their comments. Reviewers usually have not written the code that they are reviewing and thus are likely to be unfamiliar with its detail before the review. Structural analysis can thus be used to locate key constructs and increase the reviewers' overall understanding of the code and its design.

Complexity analysis can be used to reduce the time required to find potential problems or areas in the code that deserve more attention. Information related to code correctness, portability, and readability can be used to identify additional areas for improvement. If general structural problems or inconsistencies are found through visual inspection, the analysis tools can assist in finding all occurrences of this pattern within the code.

As an example, the following report displays all exception declarations, handlers, and raise statements in a single hypertable. Exceptions often play a central role in a program's error-handling concept and thus are an important part of the structural analysis of a program. In this report, the first two columns contain the name of the exception and kind of use. The third column specifies whether the exception appears in a visible specification. The fourth and fifth columns specify the location of each construct. The table columns are sorted to highlight the handlers and raise statements that exist for each exception declaration. Declarations without handlers and/or raise statements might indicate a potential problem. Use of predefined exceptions or anonymous raises also may be of interest to code reviewers.

Exceptions: