To perform an audit, the Audit framework applies a set of analyzers, defined by a profile, to a set of IDE nodes and collects the resulting measurements and violations into a result model. To begin an audit, Audit builds a tree of constructs. The constructs are the workspaces, projects, files, and (in the case of Java files), classes, methods, fields, statements, and so on that contain or are contained by the nodes. After building the tree, Audit walks it, depth-first, from the root (the Workspaces object), "visiting" each construct as it goes. Each analyzer can supply visitor methods for any construct type it wishes; when the framework visits a construct, it invokes the visitor method in each analyzer that best matches the construct type (if any). The visitor methods can do anything they want, but typically they either collect information for later use by some other visitor method, or report measurements or violations into the result model.
Analyzer
.
An instance of an analyzer subclass defines the rules and/or metrics that are
the subject of its analysis, the properties that configure it, and the visitor
methods that actually do the analysis.
The view of a profile that Audit presents to users is one of rules with properties, with no hint of analyzers: In this view,
Audit builds this view by iterating through the analyzers in the profile, getting from each analyzer the rules which it analyzes, and organizing them by their categories. The rules are themselves beans with properties, a couple of which are used by Audit. An analyzer can add extra properties to rules it defines, allowing the user to configure its analysis. User changes to property values are saved with the profile.
AuditContext
. The type
of the second, the construct type, can be anything, but the method will never
be called unless Audit actually traverses a construct that is an instance of the
type. When called, the visitor method will typically either collect information
for use by another visitor method later in the audit, or analyze collected
information and report rule violations or measurements. Reporting is done
through the AuditContext
object passed to the visitor method.
More details on the processing typical of visitor methods can be found in
here.
Audit builds a tree of constructs from the nodes to be audited.
A typical model is a source file containing Java, XML, or some other kind
of structured text. These nodes have an associated object model that
represents the structured text as a network (usually a tree) of objects.
For Java nodes, the JDeveloper IDE provides the Java model,
oracle.javatools.parser.java.v2.model
; for generic XML nodes,
it provides the DOM. org.w3c.dom
; and so forth. The objects in
these trees are the constructs that can be visited by Audit, given a
suitable model model.
The IDE deals with file types through the model factory,
oracle.ide.model.NodeFactory
. The model factory maps each
file type to a subclass of Node
, oracle.ide.model.Node
:
for example, in JDeveloper it maps Java source nodes to
oracle.jdeveloper.model.JavaSourceNode
. Usually, the
Node
subclass gives access to the corresponding object model.
Audit deals with the NodeFactory and the various Node classes and object models by using an model class, specific to the model type, for each model. The model class provides Audit with a standard interface to the model and to the constructs in the object model for the model. More details on creating model models can be found here.
Audit collects the results of an Audit, violations and measurements, in an
AuditModel
. This is essentially
a tree table model of the audited constructs, violations, and measurements.
Usually only code that invokes Audit programmatically will use the
AuditModel
and usually not even then.
Copyright © 1997, 2005, Oracle. All rights reserved.