The COMTOR Architecture

Though slightly dated in late summer 2011 by the addition of the stand-alone client, the following image represents the basic architecture of the COMTOR system as it currently exits. Essentially, the system is organized through a 10- or 11-step sequence depending on the interface.

Each of the sequences in the diagram can be further elaborated as follows:
 * 1) Input: In the case of the stand-alone client, the client interface (command-line) the user provides the location(s) of the source code on their local system. In the case of the web front-end, the user provides the input in the form of a Java .jar file. The jar file is then expanded and passed to the JavaDoc program for processing.
 * 2) Parse: JavaDoc parses the provided input an generates a RootDoc object, which is the root node of a parse tree from which we can access the various program components. Note that JavaDoc only provides us the information from the structure of the source code (packages, classes, methods, fields, constructors, etc.). Source code is not accessible, including code blocks, local variables and the like.
 * 3) Handoff: The JavaDoc parser hands off the RootDoc it has produced to a special doclet for further processing. In our case, this is the ComtorDriver class. The handoff occurs in the driver's start method.
 * 4) Processing Preparation: Here the driver class attempts to load the web interface-generated (or user-provided) XML file that dictates which analysis modules to run. Each of the modules in-turn are loaded via Java reflection.
 * 5) Process: Each individual analysis module executes separately via Java threading (ideally, if needed we can consider distributing this work to other machines), and analysis is performed. Each analysis module performs its various tasks generally by utilizing the RootDoc generated by the JavaDoc program. A simple example of an analysis module would b the BasicInfo module which provides us with simple metrics on the number of classes, methods, fields, etc.
 * 6) Build Results List: The results of the analysis are placed into a hierarchical format via a Java Properties object. A short (sorted) sample of such properties is shown in this sample COMTOR report listing. Note that this output is only representative of the contents of a Properties list, and is formatted by a small code segment and output to a file via the stand-alone client program.
 * 7) Results: The Property list generated from each analysis module is returned to the driver class. Since the modules are individual threads, the driver will wait until all results have been returned. The resulting Property list(s) are combined into one larger list (Java Vector) and either printed to a file (stand-alone client) or
 * 8) Generate Report: In the case of the web interface, a textual dump of the Properties list vector bearing the analysis results is not sufficient. We therefore use an additional class to generate a more palatable output form (currently HTML).
 * 9) Database: When required (web interface) we store the reporting output (and other information) in the system's database.
 * 10) Generate Report: (NOTE need to revise the image and correct this text). Next, the reporting vector of Property objects are turned into an HTML output stream for use in displaying the results to the web. We can however, use this stage to produce other forms of output (not currently coded), such as PDF, XML, JSON, etc.
 * 11) Return: In the case of the web interface, the user is returned to a new web page with the results of the analysis presented.