Based on our conversation, here is my understanding of the architecture of
the current tool and some suggestions on how it might be generalized and
adapted.

Spencer

=========================

Architecturally the tool has, or can be modified to have the following
indepenent components.

      o Source code analyzer (currently SUN C++ compiler front end) for
	performing static analysis on C++ programs plus some scripts to
	ASCIIfy the IR.  GEN++ has also been used in a previous version.

      o Program instrumenter (PERL scripts) that construct a program version
	that, when executed, will produce the event log.
      
      o Executer/event trace generator executes the instrumented program
	and logs the resulting events.
      
      o Visualizer/abstractor provides a variety of graphic views of the
	events that are controllable by an analyst.
      
      o Pattern matcher searches for specific events in the event log.

"Componentizing" the tool will enable the delivery of several independent
pieces.  For example, breaking out the static analyzer and specifying the
format of its output will allow analyzers to be inserted for other languages.
Areas for other such generalizations include the following.

      o Programming language independence (also allows other off-the-shelf
	tools such as the Software Refinery and Xinotech's tool to be
	inserted)

      o Typed events: the tool currently only understands method call events.
	Dean plans to extend it to deal with returns, object creation, and
	object destruction.  I suggest that any event that could be
	statically instrumented should be allowed, including application
	dependent events.  This would require the pattern-matcher to be
	able to deal with typed events.

      o On the object side, the tool currently understands files, functions,
	and classes, as well as the aggregation relations among them, as
	well as the aggregation relations among.  I suggest extending this
	to deal with any statically determinable entity, particularly
	architectural units.

      o If the above two chances are made, then the visualizer becomes a tool
	for manipulating arbitrary, time ordered events among entities.

      o The analyst should be able to suggest abstractions/patterns/operators
	that might occur in the event data.  In particular, I suggest the
	ability to aggregate entities, select/hide entities, reorder entities,
	detect repeated and conditional event sets, and aggregate events.

      o The analyst should also be able to try out patterns and when a
	combination yields an interesting abstraction, save the operator
	sequence that got him/her there.  Also, operators should be able
	to be combined and applied.

      o The tool currently visualizes an event log from a single execution.
	I suggest the ability to deal with multiple executions, possibly
	indicating differences visually.