Difference between revisions of "CA Library Implementation"

m
(CA_CODE_ANALYZER interface)
Line 23: Line 23:
 
Here are other features which can be called before starting to analyze:
 
Here are other features which can be called before starting to analyze:
 
; <e>{CA_CODE_ANALYZER}.clear_classes_to_analyze</e> : Removes all classes that have been added to the list of classes to analyze.
 
; <e>{CA_CODE_ANALYZER}.clear_classes_to_analyze</e> : Removes all classes that have been added to the list of classes to analyze.
; <e>add_completed_action (a_action: attached PROCEDURE [ANY, TUPLE [ITERABLE [TUPLE [detachable EXCEPTION, CLASS_C]]]])</e> : Adds <e>`a_action'</e> to the list of procedures that will be called when analysis has completed. The procedures have one argument, a list of exceptions (with the corresponding class). In the case an exception is thrown during analysis the exception is caught by the code analyzer and is added to this list. In the graphical user interface such exceptions would show up as errors at the top of the list of rule violations.
+
; <e>.add_completed_action (a_action: attached PROCEDURE [ANY, TUPLE [ITERABLE [TUPLE [detachable EXCEPTION, CLASS_C]]]])</e> : Adds <e>`a_action'</e> to the list of procedures that will be called when analysis has completed. The procedures have one argument, a list of exceptions (with the corresponding class). In the case an exception is thrown during analysis the exception is caught by the code analyzer and is added to this list. In the graphical user interface such exceptions would show up as errors at the top of the list of rule violations.
 +
; <e>.add_output_action (a_action: attached PROCEDURE [ANY, TUPLE [READABLE_STRING_GENERAL]])</e> : Adds <e>`a_action'</e> to the procedures that are called for outputting status. The final results (rule violations) are not given to these procedures. These output actions are used by the command-line mode and by the status bar in the GUI.
 +
; <e>is_rule_checkable (a_rule: attached CA_RULE): BOOLEAN</e> : Tells whether <e>`a_rule'</e> will be checked based on the current preferences and based on the current checking scope (whole system or custom set of classes).
 +
 
 +
Then, to start analyzing simply call <e>{CA_CODE_ANALYZER}.analyze</e>.
  
 
=== Rule checking ===
 
=== Rule checking ===

Revision as of 04:40, 6 March 2014

<< 6. Adding New Rules |


The code for Code Analysis is located at three different places in the EVE source:

  1. The framework—the by far largest part, with the rule checking, the rules, the control flow graph functionality, and more—is represented as a library;
  2. The graphical user interface can be found in the interface cluster of EVE;
  3. The command-line interface for code analysis is a single class in the tty cluster of EVE.

code_analysis library

The whole code analysis framework is located in the library code_analysis.

Interface

In this section it is explained from a client view how to use the code analyzer. The code analyzer is represented by the class CA_CODE_ANALYZER, so a client must have or access an instance of this class. Before the analyzer can be launched all the classes that shall be analyzed must be added using one of the following features. If you use more than one of these commands then the added classes from all commands will be conjoined.

{CA_CODE_ANALYZER}.add_whole_system 
Adds all the classes that are part of the current system. Classes of referenced libraries will not be added. So, for example, if your system consists of the classes MY_MAIN, MY_BOX, and MY_ITEM then these three classes will be added to the list of classes to be analyzed.
.add_class (a_class: attached CONF_CLASS) 
Adds a single class.
.add_classes (a_classes: attached ITERABLE [attached CONF_CLASS]) 
Adds a list of classes.
.add_cluster (a_cluster: attached CLUSTER_I) 
Adds all classes of a cluster (and all the classes of the sub-clusters recursively).
.add_group (a_group: attached CONF_GROUP) 
Adds all classes of a configuration group. An example of a configuration group is a library.

Here are other features which can be called before starting to analyze:

{CA_CODE_ANALYZER}.clear_classes_to_analyze 
Removes all classes that have been added to the list of classes to analyze.
.add_completed_action (a_action: attached PROCEDURE [ANY, TUPLE [ITERABLE [TUPLE [detachable EXCEPTION, CLASS_C]]]]) 
Adds `a_action' to the list of procedures that will be called when analysis has completed. The procedures have one argument, a list of exceptions (with the corresponding class). In the case an exception is thrown during analysis the exception is caught by the code analyzer and is added to this list. In the graphical user interface such exceptions would show up as errors at the top of the list of rule violations.
.add_output_action (a_action: attached PROCEDURE [ANY, TUPLE [READABLE_STRING_GENERAL]]) 
Adds `a_action' to the procedures that are called for outputting status. The final results (rule violations) are not given to these procedures. These output actions are used by the command-line mode and by the status bar in the GUI.
is_rule_checkable (a_rule: attached CA_RULE): BOOLEAN 
Tells whether `a_rule' will be checked based on the current preferences and based on the current checking scope (whole system or custom set of classes).

Then, to start analyzing simply call {CA_CODE_ANALYZER}.analyze.

Rule checking

Graphical User Interface

Command-line Interface