| CONTENTS
Description Features supported Work breakdown Platform independence Existing tools Miscellaneous points Some relevant links |
We are designing VOTE to track the execution of a system written in C++.
It will use the message passing analogy. Classes will be modeled as vertical timelines. If a routine in class A calls a routine in class B, then this will be modeled as A passing a message to B. Classes that are highly interdependent can be expected to pass messages to each other frequently. The display of this information is known as the message sequence chart (MSC).
What will the MSC tell us about a system? Two things. First, we will see the code in motion. This will be useful for observing how execution proceeds and understanding how a system behaves in different situations. Second, the MSC will give us valuable insight into the structure of the system. In contrast with other methods for studying software structure such as system coupling and cohesions metrics and interconnection diagrams, the MSC shows how frequently two classes talk to each other under real execution conditions.
We see VOTE as a lightweight tool to be used throughout the software development process. It will be invaluable for both gaining a general, high-level understanding of a complex system and studying the specific execution of well-defined components under certain inputs. We anticipate that it will be used by both technical Managers and Software Designers. Designers may use it as they learn and explore unfamiliar system components and as they debug faulty software. Managers will use it to develop a high-level understanding of the motion and structure of the entire system.
How will we do it?
A text preprocessor will parse the original source code and insert an AutoLog object declaration at the beginning of each class method, immediately after the function prototype and before any instructions or variable declarations.
During system execution the AutoLog's constructor will be called immediately on entrance into the routine as the system begins to push the local variables on to the stack. The AutoLog constructor will write information to a log file. This information will include a timestamp and the routine/class identifier gathered by the preprocessor. When the function returns, the AutoLog's destructor is automatically called as the system pops the stack, writing the timestamp and the routine/class identifier to the log file. This log file is parsed to generate the MSC.
Integration with documentation tools.
The MSC will be constructed so that it is highly mobile and translatable. We anticipate that users will wish to import such diagrams to word processing packages and display them for internal use on the corporate intranet.
Compile-time filtering.
The user can specify which classes are to be logged. The parser will only insert the AutoLog object declaration into the routines of these classes, limiting the scope of the log. This feature will be useful as users target a fine subsection of the system and wish to limit the Heisenberg effects on subsystems that are not to be monitored.
Log-based filtering.
Given a particular log generated from a system execution, the user can request that an MSC include some classes, but not others. This allows the user to target the scope of the profile after measurement. Note that this enables the user to generate profiles of the same system execution repeatedly from different perspectives.
Clustering of highly connected timelines.
In order for the MSC to be concise and expressive, those classes that pass messages amongst themselves frequently should be close together. During parsing of the log file, we compute coupling statistics to order the class timelines in such a manner.
User specification of profiling granularity.
We have discussed profiling on a class-based level of granularity. For smaller systems, or if analyzing a well-specified region of the system, the user may wish to increase the fineness of the profiling granularity to the function level. In this case, the vertical timelines will represent actual functions, not classes.
The development of the core of the project involves the construction of the following main components:
4.0 Tools and platform independency
We have decided to implement VOTE in C++. We discarded the idea of building the application web-based because of the security concerns associated with file read/write system calls from an applet or active\X control.
We will use Tcl/Tk to build the GUI. The big advantage of Tcl/Tk is its platform independence. Tcl/Tk binary libraries exist on most popular platforms - Windows 95/NT, Solaris, and MacOS. So porting the tool to these platforms will be much easier than if using a platform dependent GUI library such as MFC.
Screen Shot 1 and Screen Shot 2 show mock ups of our GUI.
We considered using PERL for the text scanning and extraction. Considering the simplicity of pattern matching and text replacing required in parsing the source code in this project, we have determined not to use PERL to avoid complications from combining PERL with Tcl/Tk.
5.0 Existing tools with similar functionality
Some software engineering tools available in industry provide similar functionality. The Visual modeling tool Rational Rose for C++ from Rational software Corporstion (http://www.rational.com) provides views of a system including a message chart illustrating the interaction among C++ modules. GDpro from Advanced Software Technologies Inc. (http://www.advancedsw.com) is another visual design and re-engineering tool, offering interaction charts as well. Some profiling and tracing tools such as DEC’s PIXIE and QPT from University of Wisconsin are available only on the UNIX platform. A similar tool has been developed in Finland in University of Helsinky: more information about it can be found at http://www.cs.helsinki.fi/~viljamaa/kana/kanahelp.html#kappale12.
The cross-platform products, however, are either expensive (GDpro costs ~$7000),or their functionalities on message sequence chart are not particularly emphasized. VOTE will be useful to developers who need to get detailed information on the run-time interaction between routines.
Duplicate names with the existing processing function:
In order to record entry and exit of a subroutine, we will insert the AutoLog object declaration at the beginning of every function. Our parsing routines will take care to make sure that the name of the AutoLog object does not conflict with other identifiers.
Anticipated Heisenberg effects:
How will the act of observation effect the execution of the system? Some overhead will be incurred with each function call and return. On function call the AutoLog object must be constructed, writing the log information to file. On function return, the AutoLog destructor will be called, again writing to the log file. This activity will affect the execution of the system. In order to minimize Heisenberg effects, the AutoLog object will be kept simple.
With systems that are heavily timer driven, the profile of the Autologged system can be expected to differ in the ordering of events from that of the non-monitored system. The user should take these potential effects into consideration.
Extension to JAVA:
We are currently looking at the feasibility of extending the scope of our tool to Java source code. The major difficulty is that in Java an objects destructor is not called as an object passes out of scope. Therefore, we cannot rely on a destructor to log exit from a routine. We have investigated using the finalize method and garbage collection to log the exit from a routine. Unfortunately, the garbage collector cannot be relied on to kick in as an object passes out of scope. We are currently not certain that a workaround to this problem will be found. If not, our tool will be limited to C++ source code.
An introduction to MSCs can be found at the following address:
Scenario diagrams and functional model diagrams of the OMT methodology are very similar to MSCs; they are indeed meant to express the same kind of information. Examples of both diagrams can be found at the following links:
