Current Software Release: version 1.0
Dec 30, 1997
Dean F. Jerding
Copyright 1997, Georgia Institute of Technology
All rights reserved.
The purpose of the Interaction Scenario Visualizer (ISVis) tool is to support the browsing and analysis of execution (or usage) scenarios, derived from actual program executions. It is useful during software engineering tasks requiring a behavioral understanding of programs, such as design recovery, architecture localization, design/implementation validation, and reengineering. The key features of ISVis are its use of visualization techniques to depict the large amounts of information available to a user, and the notion of recurring scenarios, or "interaction patterns", as abstractions which help bridge the gap between low-level event traces and high-level design models. Users of the system might be software designers, programmers, testers, or maintainers.
The process of using ISVis requires several phases:
While this system is intended to handle object-oriented (OO) programs, its architecture allows for "global" functions, meaning that a completely procedural program can be analyzed as well. The interaction events being analyzed include messages (function invocation/return), and can be extended to object creation/destruction and data read/write.
ISVis is most useful for two related tasks:
For example, a user can define execution scenarios that (s)he expects to occur during a particular program execution and query ISVis to determine the existence and locations of that scenario or others closely related. Design-level models can be specified and modified based on entities in the program, and the implementation's behavior examined with respect to those models. A user can browse execution scenarios and either visually identify or use the tool to automatically identify repeated sequences of interactions, or interaction patterns. These recurring scenarios can be understood and then used as abstractions to build higher-level scenarios. As such, users can develop and validate design-level behavioral models, validate the implementation with respect to existing models, and/or uncover inefficiencies in the existing design.
This screen snapshot shows the main ISVis view in the background and a Scenario View in the foreground. The main view includes lists and information about the actors and interactions being analyzed, including components defined by the user, scenarios read in as traces, and scenarios created by the user. The Scenario View includes a global Information Mural of a particular scenario (used for navigation), and a focus area where individual interactions and actors can be manipulated.
ISVis also uses XEmacs to view the source code of the system, which is an important supplement to the scenarios during the understanding process. Entities in the source code can be grouped into architectural components as the analyst uncovers common scenarios and functionality, and the system's behavior can then be viewed based on such architectural divisions.
Installation is covered in the README file included with the distribution. A summary of the steps is as follows:
ISVis is executed in a manner similar to a debugger, by specifying the
path to the executable for the subject program on the command line:
isvis foopath/foo, where foopath should be "." if executing in the same directory.
ISVis should be executed in the directory which contains the static information file for the subject program (if one has been created).
The ISVis Main View contains the main menu and information about the actors, interactions, and scenarios in the subject program. From the main menu, all of the ISVis functionality can be accessed. The next section describes the contents of the Main View and user interaction. The following section details how to use the Main View to perform the basic ISVis tasks.
The Main View has two areas, the upper which contains information about the program and the lower being the textual command area for user input and output. The first row of program information is the actor lists: components, files, classes, and functions (from left). The second row contains two lists, one of scenarios and the other of interactions. To the right of the interaction list is the focus area, which contains information about the item selected as the primary focus (see below) and a legend (key) for the ISVis views.
The lists in the Main View contain the actors, interactions, and scenarios currently in the ISVis model of the subject program. By default the lists, with the exception of the component list, are filled in when a trace file for the subject program is read into ISVis. Components are defined by the user, as well as additional interactions and scenarios. Each of the lists has an Information Mural scrollbar to the right, which allows the list to be scrolled up/down and shows colors and highlights of all items in the list. The left mouse button can be used to select an item (typically done before a menu option is chosen), and holding the shift key down and selecting an item allows multiple items to be selected.
A single item out of all the lists can be selected as the primary focus using the middle mouse button. The primary focus item is shown with a red rectangle framing it. Items related to the primary focus become the secondary focus, and are displayed with an orange frame. For example, if a class actor is selected primary focus, any components which contain that class, the file which contains that class, and any functions of that class gain secondary focus. The focus feature is useful for selecting an item in one ISVis view to highlight related items in the other ISVis view.
The key near the bottom of the Main View contains a number of color buttons which can be used to assign colors to the items in the ISVis program model. For example, the user can select an interaction of interest, highlight it blue by clicking on the blue button, and then examine a Scenario View to find everywhere that interaction occurs in the scenario.
In order to perform a static analysis of a subject program, that program must have been compiled using either the Solaris CC or cc compiler, with the -xsb flag set to generate source browser information (static information used by Sun's Source Browser). ISVis can read these files and extract the necessary static information about the subject program. The result of a static analyis of the subject program is a static information file describing the files, classes, and functions in the source code.
Under the Program menu in the Main View, select Perform static analysis. When this option is selected, the user must enter a list of directories in which to search for Source Browser files. If the subject system contains multiple sub-directories, the user must enter each of these in sequence.
The next step is the instrumentation of the subject system source code, such that when re-compiled the instrumented system will generate event trace files. Choose Instrument source under the Program menu of the Main View. If static analysis has not yet been performed, this will be done first. Then, the user will be asked what directory to place the instrumented code, and then whether an existing trace info file should be used or a new one should be created for the subject program. Then, the user will be presented with a list of all the files in the system. The user can selectively choose whether or not to instrument each file in turn. Currently, the options to instrument within a file to the class or function level are not available. However, the user can create a trace info file off-line with the appropriate syntax to drive instrumentation at the class or function level.
Once the instrumented files are created, the user must leave the ISVis tool and compile the annotated system, making sure to link in the tracing library in ISVIS_HOME/bin/isvis_tracelib.o. When executed, the instrumented system will then generate a trace file [program name].trace.
An event trace is read in using the Read trace file option from the Program menu in the Main View. The user is then queried for several parameters as follows:
When the trace has been read, a scenario for the trace is added to the scenario list in the Main View.
To open a Scenario View for a scenario listed in the Main View, simply select the scenario with the left mouse button and choose Open view under the Scenario menu in the Main View.
It is possible to create a new scenario to which actors and interactions can be added interactively by selecting a set of actors for the scenario and using the New, from selected actors option under the Scenario menu in the Main View. After the scenario is named and information about it is entered, the scenario will be added to the list in the view. It can then be selected and a Scenario View of it opened, in order to add interactions.
A user can define a component actor as a set of any other actors in the ISVis program model. Simply use the mouse to select the set of actors, and choose the New, Component, from selected actors option from the Actor menu in the Main View. The user will then be prompted for the name of the component, and then the new component will be added to the component list. It is also possible to add and remove selected actors to/from a primary selected component, using the Add and Remove options under the Actor menu.
An XEmacs view of source code for a particular actor can be launched as follows. Use the middle mouse button to make the actor primary focus. Then choose the View source option under the Actor menu in the Main View. This will start an XEmacs window showing the file and line number for the specified actor.
At any time during an analysis session, the user can save the current session using the Save option under the Session menu in the Main View. This will save all scenarios, interactions, and actors currently in the internal ISVis program model. Saved sessions can be read in using the Open option under the same Session menu. Note that for the current implementation, a session file cannot be opened except when ISVis is first executed.
The Scenario View shows the actors and interactions in a particular interaction scenario. It is essentially an interactive, editable Temporal Message Flow Diagram, which looks much like an event trace diagram or interaction diagram. The next section describes the contents of the Scenario View and user interaction. The following section details how to use the Scenario View to perform basic tasks.
The Scenario View shows the sequence of interactions between actors in a particular scenario. The top of the view contains the pull-down menu for the Scenario View. Underneath are several option menus, which allow parameters of the view to be set. The main part of the view shows whatever portion of the scenario details can fit in the window, the so-called focus area. Each actor in the scenario is assigned a column with a vertical line, and their labels appear at the top of the view. An interaction is drawn as a horizontal line between the source and destination actor, with a circle at the end corresponding to the destination actor. An Information Mural at the right of the view serves as a global overview and navigation area for the entire scenario. The Mural depicts the entire sequence of interactions, no matter how many there are in the scenario. The borders of the Information Mural are shaded to show the area of the detailed focus view within the entire scenario, both vertically and horizontally. The detail part of the scenario can be panned by pressing the left mouse button in the Mural and dragging up/down/left/right to scroll.
Two option menus under the menu bar let the user set parameters controlling the display. The first specifies which set of actors the interactions are being viewed between. The default is the actual set of actors specified in the scenario, which are typically function actors if the scenario is based on a trace file. The interactions in the scenario can be projected across function actors, class actors, file actors, or an arbitrary set of actors selected by the user. It is important to note the setting of this option, because ISVis considers the default actors when copying a scenario or doing matching, not the particular set of actors which the Scenario View happens to be projecting the interactions over at the current time.
The second option menu controls how interactions are selected using the left mouse button. If the selection mode is single, then when the user selects a particular interaction it is that instance of the interaction and only that instance in the scenario that is selected. If the selection mode is all, then when an interaction is selected every instance of that interaction in the scenario is also selected. These two modes are used because each is powerful for particular tasks; however, other tasks will not work if the mode is wrong so the user must pay attention to this setting as well. For example, the single selection mode is required to select a contiguous set of interactions and define them as a scenario, and to see the results of finding matching interactions and scenarios. Multiple selection is useful for removing all instances of uninteresting interactions but will not allow the two previously mentioned tasks to be accomplished.
If any interactions or actors have been colored using the key in the Main View, they are colored correspondingly in the Scenario View. Actors and interactions can be selected using the left mouse button, or designated as primary focus using the middle mouse button, as in the Main View. A button in the top right of the view depicts the scenario name and is colored gray if the scenario represents a trace file or white if the scenario is a default scenario. Scenarios created from trace files cannot be edited but can be copied. Pressing the button prints the name and information about the scenario in the Main View text area, and allows the user to edit that information.
To create an editable copy of a trace-based scenario, choose the New, copy option under the Scenario menu in the Scenario View. The user is then prompted in the Main View text area to enter a name for the new scenario, and then it will be added to the list in the Main View and can be opened from there.
In default scenarios, actors can be added by selecting from the actor lists in the Main View and choosing the Add option from the Actor menu in the Scenario View. Actors can be removed by selecting them (in the Scenario View or the Main View) and choosing the Remove option from the Actor menu in the Scenario View. If an actor is removed from a scenario, all interactions to or from the actor will be removed as well. This operation cannot be undone.
In default scenarios, interactions can be appended to a scenario by selecting one or two actors and choosing the Append option from the Interaction menu in the Scenario View. The user will then be prompted (in the Main View) for the type of interaction, name, and asked to specify the direction of the interaction. If only one actor is selected when the command is executed, the user will have the option of appending a self-interaction or an interaction where either actor is the "." actor, or "don't care" actor, which matches all actors during pattern-matching (as in regular expressions).
Interactions can be removed using the Remove option from the Interaction menu, with the option of removing all selected interactions or all leaf messages (as in the leaves of the call graph) interactions.
To find a particular interaction in the scenario, select it using the left mouse button, either in the interaction list in the Main View, or in a Scenario View, and choose the Find option under the Interaction menu in the Scenario View. This will start from the current position of the scenario in the view and scroll the view down to the next instance of the interaction in the scenario, if there is one.
To define a new scenario from a set of interactions in the Scenario View, first select a contiguous sequence of interactions in the scenario using the left mouse button to click on each interaction (make sure the selection mode is set to single). Then choose the New, from selected interactions option under the Scenario menu in the Scenario View. The user will be prompted (in the Main View) to name the scenario and give a description of it, after which it will be added to the scenario list in the Main View. It can then be selected and its own Scenario View opened as described previously.
The Replace match option in the Scenario menu of the Scenario View can be used to replace sequences of interactions matching a particular scenario with a visual representation of the scenario. For example, while viewing scenario A an interesting sequence of interactions is observed, selected, and defined as a new scenario B. Then, scenario B is selected in the Main View, and the Replace match option in the Scenario menu of the Scenario View for A is chosen. This means that the entire scenario A is searched for instances of interactions exactly matching those in scenario B. For every occurrence of interactions matching scenario B, the interactions in scenario A are replaced with a reference to scenario B and the Scenario View for A updated accordingly.
Scenarios can be searched for the occurrence of other scenarios using a variety of pattern-matching options. The scenario being looked for is used as a pattern, which can include a ".", or wildcard, actor. The user can choose to look for an exact match in the scenario (actors in the pattern and the scenario match exactly and interactions in the pattern occur contiguously in the scenario), an interleaved match (all actors match exactly and interactions in the pattern occur in order, but others may be interleaved), a contained exact match (actors in the scenario contain the actors in the pattern, and the interactions occur in exact order), and a contained interleaved match. These searches are invoked by selecting a scenario in the Main View and choosing the Find match option from the Scenario menu in the Scenario View to be searched, using the appropriate exact, contained exact, interleaved, and contained interleaved option. If a match is found the focus area of the Scenario View will be scrolled to the interactions, which will be selected (make sure the selection mode is set to single).
A simple, brute-force pattern matching algorithm can be invoked to let ISVis automatically identify repeated sequences of interactions within a scenario. Use the Pattern settings... option in the Interaction menu of the Scenario View to set the search parameters. The user will be prompted (in the Main View) for the minimum size scenario (number of interactions) to find, maximum size scenario to find, and number of interactions for the search to span. The search is activated from the first interaction in the focus area of the Scenario View by choosing the Find pattern option under the Interaction menu in the Scenario View. A message sequence pattern is simply a sequence of interactions meeting the pattern search criteria which occurs more than once in the scenario. A message context pattern is the same as a message sequence, with the additional requirement that the pattern start on a call and end with a corresponding return interaction. If ISVis finds a pattern when the search is activated, the view will scroll to the pattern and the interactions will be selected. The user can then define those interactions as a new scenario if the pattern seems interesting.
It is often useful to display the sequence of call interactions that led up to a particular interaction so that successive enclosing scopes can be examined. Pressing the right mouse button over an interaction in the Scenario View will bring up a pop-up menu showing a list of the call tree which led to that interaction. The user can select one of the interactions in the list to pan the focus area of the Scenario View directly to that interaction.
To help create a more visually useful global overview, the ordering of the actors along the horizontal axis can be changed such that the distance between actors which communicate most frequently is minimized. This serves to minimize the length of the lines representing interactions in the Scenario View. Use the Order by clustering option in the Actor menu of the Scenario View to run this algorithm.
The process and tactics for using ISVis during design recovery and architectural localization tasks are discussed in this section in the context of a case study. The subject system for this case study is the NCSA Mosaic web browser, version 2.4. This version uses MIME types to denote internal and external viewers for different types of web pages. The enhancement task is the extension of version 2.4 to support user-configurable external viewers, whereby Mosaic provides users interactive control over which viewers are used for specific types of web pages. The first steps in the reengineering process are understanding which parts of the system implement relevant functionality and which components must be changed or added to support the new requirements.
The process for using ISVis in an architectural localization task can be summarized by the following steps.
During the use of ISVis for architectural localization type tasks, we have identified a number of tactics useful for solving this class of problems. Some of these tactics are certainly appropriate for solving other program understanding problems as well.
Abstract the view of scenarios by using the natural actor containment hierarchy.
Eliminate interactions unrelated to the functionality we are trying to localize.
Use the global overview and browse the scenario to identify interaction patterns.
In the mural at the right side of the Scenario View of the Mosaic trace, you can see four different phases in the first two-thirds of the scenario, one for each HTML document visited. Repetitive patterns occur as each document is processed. Differences arise from the number of images in each document, another pattern that we found. Early on the analyst also discovered interaction patterns for the processing of a mouse click on an anchor, of which there are six in the scenario-three in the first two-thirds of the scenario for HTML links and three at the end for the PostScript documents displayed.
Understand interaction pattern behavior and replace the low-level interactions with a reference to the recovered scenario.
Use pattern matching to locate similar scenarios.
Investigate the behavior of actors by viewing their source code.
During the latter part of this case study, the analyst began to open XEmacs views of the source code for various actors. The analyst then located the interaction "HTSaveAndExecute" in those interactions occurring after the handling of a PostScript link. By viewing the source code, the analyst verified that this function was in fact where the external viewer for the link was determined.
Build components of related actors that provide related, cohesive functionality.
Future implementation.
Internal binary representation of the ISVis session, used to record scenarios, interactions, actors, etc. currently being analyzed for future use; not useful externally to ISVis. This file is currently in the internal binary serialization format for Roque Wave persistant objects.
ASCII file containing static information about the subject system.
FILE <full filename>
CLASS <class name> <full filename> <line number>
INHERITS <class name> <parent class name>
MEMBER_FUNC <function name> <class name> <full filename> <line number>
GLOBAL_FUNC <function name> <full filename> <line number>
ASCII event trace file generated from executing instrumented system. First line is trace information file used to generate trace file, then subsequent lines describe execution events such as Call, Return, Instantiation, and Destruction.
<trace information filename>
C <timestamp> <function name> <class name> <object id> <filename> <line number>
R <timestamp>
I <timestamp> <object id> <class name> <object name> <filename> <line number>
D <timestamp> <object id> <filename> <line number>
ASCII file describing files, classes, and functions instrumented to generate a particular trace file.
FILE <full filename>
CLASS <class name>
FUNCTION <function name> <class name>
actor: actors may be either simple or composite. A simple actor is a syntactically identifiable program unit. A composite actor is a set of actors, each of which may be either simple or complex. Examples of simple actors include functions, objects or data items.
default scenario: a scenario created by the user during an isvis session. These scenarios are modifiable by the user during an ISVis session.
event: a discernable unit of program execution. Examples of events include function invocaton or return, object creation or deletion or a data reference.
event trace: a record of the events that occur in the execution of the program.
execution scenario : See usage scenario
interaction: a relation between an event and one or more actors.
interaction patterns: a description of interaction scenarios. The pattern specifies an ordered list of interactions, where one or more of the elements of the list can be a wildcard denoting interpolated events that do not conceptually contribute to matching a scenario.
interaction scenario: a sequence of interactions identified by the analyst as having some signifigance in the overall understanding of the program under analysis.
recurring scenario : See interaction scenario
scenarios: a specification of some set of behaviors. Within ISVis, there are two principle types of scenarios, usage scenarios and interaction scenarios.
trace-based scenario: a scenario created directly from a programs instrumented execution. These scenarios are typically read-only and consist of all the interactions that occurred when the usage scenario was executed.
usage scenario: The execution of a subject program with a specific set of input test data. A usage scenario is a specification of how the functionality of the instrumented ISVis program will be exercised so that the analyst can understand the interaction sequences that occur.