To perform an audit, the Audit framework applies a set of analyzers, defined by a profile, to a set of documents 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 documents. 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.
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
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 documents to be audited.
A typical document is a source file containing Java, XML, or some other kind
of structured text. These documents have an associated object model that
represents the structured text as a network (usually a tree) of objects.
For Java documents, the JDeveloper IDE provides the
{@link oracle.jdeveloper.jot JOT}; for generic XML documents, it provides the
{@link org.w3c.dom DOM}; for EJB deployment descriptors, it provides the
{@link oracle.jdeveloper.xml.j2ee.ejb ejb-jar.xml binding
},
and so forth. The objects in these trees are the constructs that can be
visited by Audit, given a suitable document model. By default, Audit in
JDeveloper 9.0.5 provides a document model only for Java source documents.
The IDE deals with document types through its
{@link oracle.ide.model.NodeFactory NodeFactory}. The node factory maps each
document to a document-specific subclass of {@link oracle.ide.model.Node Node}:
for example, in JDeveloper it maps Java source documents to
{@link oracle.jdeveloper.model.JavaSourceNode 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 adapter class, specific to the document type, for each document. The adapter class provides Audit with a standard interface to the document and to the constructs in the object model for the document. More details on creating document models can be found here.
Audit collects the results of an Audit, violations and measurements, in an
{@link oracle.jdeveloper.audit.service.AuditModel 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.