Abstract
Keywords: Ada, program analysis, quality, ASIS
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.
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.
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:
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:
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:
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:
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:
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:
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:
Exception | This Usage | Visible? | Unit | Library |
---|---|---|---|---|
>>ANON<< | raise | Msg_Manager'B | Communication | |
Bad_Input | declaration | Yes | Input_Parser'S | User_Interface |
Bad_Input | handler | Keyboard_Mgr'B | User_Interface | |
Bad_Input | raise | Input_Parser'B | User_Interface | |
Constraint_Error | raise | Input_Parser'B | User_Interface | |
Id_Not_Found | declaration | Yes | Msg_Storage'S | Database |
Id_Not_Found | raise | Msg_Storage'B | Database | |
Rxit_Search | declaration | No | Msg_Storage'B | Communication |
Exit_Search | handler | Msg_Storage'B | Communication | |
Numeric_Error | raise | Data_Storage'B | System_State |
Static analysis tools can also help with the correction and verification process. If items to be corrected are located in hypertext, the developer can use the built-in traversal to quickly locate the areas of the code requiring correction. Some part of the verification process can also be performed by reexecuting the analysis tools to rapidly verify that corrected problems are no longer present.
Validation of Coding Standards
Most software-development projects have a set of coding standards for developers to follow. These standards generally consist of a set of prohibited language constructs or specifications for the form in which a construct can be used. These standards may be motivated by any combination of style, consistency, or efficiency considerations. Use of host-based development of software for embedded targets may also involve compatibility issues between the two compilation systems used in that process.
The difficulty with such standards is that they often contain a long, complicated list of restrictions that are difficult to remember and follow during day-to-day development. This form of analysis attempts to verify that software does not contain any standards violations or compatibility errors. The existence of table entries implies that the code under analysis has violated one of these standards. Using the traversal built into hypertext output, the user can move to each reported violation and make the necessary changes to correct the problem.
Generation of Project Information
Information about Ada units and their interdependencies is one example of information that can be useful to all project members. Location of all key programming constructs and data-dictionary information is another. Cross-referenced lists of declarations and their dependencies constitute a third example. This information can be distributed internally to project members or be used to augment the documentation delivered to the customer.
New opportunities for additional static analysis capabilities appear as each new project uses the Ada Analyzer. As clients become familiar with the concept of seeing condensed reports on the content of their software programs, they quickly begin to imagine other kinds of information that would be even more insightful. The Ada Analyzer and other static analysis tools like it are just beginning to discover the impact that this kind of analysis can have on software quality and software-engineering methods.
Department of Defense Requirements for an Ada Programming Support Environment, "Stoneman," Defense Advanced Research Project Agency, Arlington, Virginia, February 1980.
Goos, G., W. A. Wulf, A. Evans, and K. Butler, DIANA: An Intermediate Language for Ada, LNCS #161, Springer-Verlag, New York, 1983.
Munck, R., P. Oberndorf, E. Pledoereder, and R. Thall, "An Overview of DOD-STD-1838A (proposed): The Common APSE Interface Set," SIGPLAN Notices, 24, 2, February 1989, pp. 235247.
Pierce, R., "ECLIPSEãAn APSE Based on PCTE," Proceedings of the Ada-Europe Conference, Stockholm, May 26-28, 1987, S. Tafvelin (ed.), Cambridge University Press, pp. 3245.
Reference Manual for the Ada Programming Language, ANSI/MIL-STD-1815, ISO 8652-1987.
Software Productivity Consortium, "Ada Quality and Style: A Guide for Professional Programmers," SPC-91061-N, Version 02.00.02, 1991.