Customization

There are two main ways in which Ada-Audit can be customized:

• By customizing the built-in STYLE relation.

• By defining new relations.

Customizing the STYLE Relation

As delivered, the STYLE relation reports on violations of the Software Productivity Consortium's (SPC) Ada Quality and Style Guidelines for Professional Programmers.

The built-in STYLE relation can be customized in three ways:

• By setting parameters for the SPC guidelines, e.g., how long can a procedure be before it is considered too long.

• By defining new audit facts, e.g., you may wish to report on certain patterns of Ada code.

• By defining new information for each fact, e.g., the name of the repsonsible programmer for each violation.

Parameters of the STYLE Relation

See Chapters 7 and 16 of the Ada-ASSURED User Guide and Reference Manual for instructions on setting these parameters.

Defining New STYLE Facts

The audit criteria of the STYLE relation are defined in script file flaws.95.stk and flaws.83.stk. These two files differ according to differences in the Ada 83 and Ada 95 grammars. New facts can be defined by ammending the pattern matching cases that appear after the line:

;;; ADD THE DEFINITION OF NEW FACTS HERE.

Files style.stk, flaws.95.stk and flaws.83.stk illustrate how a site can define a new audit criteria of local interest. These files contain several occurrences of pseudo-ifdef's of the form:

;;;ifdef LOCAL_CRITERIA
;;; text to be inserted
;;;endif LOCAL_CRITERIA

If you (manually) delete the comment symbols from the bracketed code, e.g., if you change the above example to

;;;ifdef LOCAL_CRITERIA
text to be inserted
;;;endif LOCAL_CRITERIA

then the computed STYLE relation will contain a row for each assignment statement that appears in the audited Ada file. Although the example is trivial, it shows exactly where and how to add new audit criteria. Consult documentation on the Ada-ASSURED Scripting Language documentation for further details.

Changing the STYLE Schema

The predefined STYLE schema is defined in file style.stk. The STYLE schema can be changed by ammending the lines that appear after the comment

;;; MAKE CHANGES TO THE STYLE SCHEMA HERE.

Additional places in files style.stk, flaws.95.stk, flaws.83.stk that must be changed when the STYLE schema is changed follow occurrences of the comment:

;;; ACCOUNT FOR CHANGES TO THE STYLE SCHEMA HERE.

The example of adding a field to the STYLE schema for the name of the programmer responsible for the flawed line of code is illustrated in files style.stk, flaws.95.stk, and flaws.83.stk. These files contain several occurrences of pseudo-ifdef's of the form:

;;;ifdef LOCAL_STYLE_SCHEMA
;;; text to be inserted
;;;endif LOCAL_STYLE_SCHEMA

If you (manually) delete the comment symbols from the bracketed code, e.g., if you change the above example to

;;;ifdef LOCAL_STYLE_SCHEMA
text to be inserted
;;;endif LOCAL_STYLE_SCHEMA

then every flaw in the STYLE relation will be reported as the fault of "Ada Lovelace". In practice, of course, the repsonsible programmer would have to be determined based on the customer's local documentation, e.g., file or procedure headers.

Note that changing the STYLE schema invalidates all cached or saved copies of the STYLE relation.

Defining a New Relation