Two papers for Nicole Winter's talk on 1/24/96:<P>

<A HREF="#provide report">PROVIDE</A> - Thomas G. Moher<P>

<A HREF="#field report">FIELD</A> - Steven P. Reiss<P>
<BR>
<HR>
<BR>

<H2><A NAME="provide report">PROVIDE - Process Visualization and
Debugging Environment</A>
</H2>

PROVIDE is an interactive understanding and debugging environment for
software visualization. PROVIDE strives to allow the user to control the
level of abstraction at which they interact with their environment.
PROVIDE introduces the features of deferred-binding program animation
and process history consistency maintenance. PROVIDE is an experimental
system that was designed in the mid 1980's.<P>

<H4>Deferred-binding picture definition:</H4>

This system provides a potential for a high level of data abstraction during
visualization. The user is able to specify this abstraction by selecting a
picture icon provided by the environment and a program data set or
object. These are bound dynamically so the user can change the
specifications or add new ones during program execution. This allows for
great flexibility, assuming there is a reasonably large library of possible
visualizations. Would this still work in a system which can handle all the
possible data structures of a language like C? Remember, this system was
experimental and doesn't handle a large set of data types, like pointers,
trees, etc. How big would the library of pictures have to be to give all the
pictures for all the data structures one could want?<P>


Another important feature that arises from PROVIDE's relatively high level
of data visualization abstraction is the ability for the user to define atomic
transitions consisting of multiple lines of code. In a very low abstraction
visualization system, this ability is not of any use or significance as the
meaning of the data, one step through the execution at a time, is
technically always precise. However, given the paper's example of a pie
chart, where all the wedges in the pie are updated in a series of lines of
code, viewing the data display after each line is meaningless - and
potentially misleading to the user. For high abstraction levels, this atomic
transition specification is of great value and I am surprised it has not been
brought up again in any of the later papers we have seen. I can't come up
with an explanation myself and will see if there are any comments in
class.<P>


<H4>History Consistency Maintenance:
</H4>
PROVIDE also provides the ability for bidirectional execution. The system
calculates all state transitions at the start of execution. The user is allowed
to jump directly to any state (frame) or to run the program from the point
they are at either forwards or backwards. An interesting feature is the
ability for the user to set breakpoints and then to run from where they are
either forwards or <I>backwards</I> to that breakpoint. This would be very
useful when trying to determine where a particular piece of data diverged
from the value the programmer was expecting. Since the history of states
is stored in a database, the system needs only examine the database for
points where the variable in question was changed - it does not have to
step through all the code again. The system also allows selection of
breakpoints via Boolean expressions. This is old news now, but was
probably a very new concept back then.<P>


The user is also able to modify data through manipulating the pictures or
modify the source code during execution. The program will then unroll
back to the point where the data/code was modified and recalculate all
states after this point - thus maintaining a consistent history.<P>
 

<B>Question: How does it handle programs where the execution path is
determined by user input? How would it handle an event-driver program?
</B><P>

PROVIDE  seems to implement some powerful abstractions and
mechanisms for debugging purposes. I especially liked being able to step
through one's code backwards or jump backwards to a breakpoint.
However, I realize this is quite difficult to implement with very large
software systems as it would require a huge database.<P>
<BR>
<HR>
<BR>

<H2><A NAME="field report">FIELD - the Friendly Integrated Environment
for Learning and Development</A>
</H2>
The main purpose of FIELD is to provide an visualization environment that
takes advantage of a variety of UNIX tools in order to simplify the process
of program understanding and debugging.<P>


FIELD uses a central server that can be queried by the client applications
used for visualizations. The server receives messages from the executing
program and can send these messages to requesting clients. This allows for
dynamic visualizations of the data browsers as well as the state visualizers.
This is significant as the data browsers are now able to interact with the
executing code and provide more feedback during debugging than just
providing information on simple static relationships.<P>


FIELD has the following components:
<OL><LI> control panel - shows the available tools
<LI> annotation editor - source code viewing tool
<LI> debugging tool - both textual and visual - includes:
<LI> 	data structure display
<UL> <LI> 		user can specify how to display the data
<LI> 		user can modify data through the display
</UL>
<LI> 	current program state displays - 
<UL><LI> 		stack display
<LI> 		heap visualizer		
<LI> 		file I/O viewer
<LI> 		performance statistics graph?
</UL>
<LI> configuration management front end
<LI> textual cross-referenced data-base display
<LI> browser tools
<UL> <LI> 	flowview - gives a hierarchical view of the call graph
<LI> 	cbrowse - graphical display of object class hierarchies
<LI> 	formview - shows file and build dependencies
</UL></OL>
<P>

Since there is too much information in large scale system software to easily
visualize everything, FIELD takes two approaches for ease of
understanding:<P>


<H4>1. To allow the user to focus on a portion of the total information - as
meets their interests.<P></H4>


This is accomplished through the various browsing tools listed above: 
In these views, the user is able to expand and collapse nodes, display only
selected nodes, or display portions of subgraphs.<P>


<H4>2. To give as much information as possible in the limited space
available.<P></H4>


This is accomplished through information encoding. Colors and symbols are
used to represent information about relationships, sizes, dates, status, etc
of the relevant data. However, I believe FIELD is trying to do too much at
once. In the description of the class browser alone I was able to count
some 7 different colors, 3 fill tones, and about 13 possible combinations of
symbols - all giving different information about the class data. Neither the
colors or symbols seem to be covered by redundant information methods,
forcing the user to rely on their memory of all the different meanings. If
the user were color-blind or the system were used on a monochrome
monitor, the information is lost. Also, the system relies on color to denote
size, date, and other relationships. Color scales are not really intuitive to
humans. It is hard to remember the exact order of the color spectrum and
the relationships between the color ordering.<P>


<B>Question: How can we improve FIELD's method of information coding so
the user has less to remember (or can remember the meanings more
easily)? Idea: Maybe the user can double-click on a piece of data and a
pop-up window would give all the information the encoding gives spelled
out in plain English.
</B><P>

I agree with the author's claim that FIELD has successfully integrated
various UNIX tools into a visual environment. However, I am left
wondering as to how successful this achievement is at improving program
understanding.  The author claims the environment does help improve
understanding the dynamic behavior of the program but does not much
improve understanding of the static structure. The author's attributes this
to the time it takes to generate the visualizations and the time it takes to
learn all the features of all the tools. I am surprised by these results. For
the purposes of debugging (interaction with the dynamic behavior of a
program) I don't see many of these tools to be very useful. I am mostly
interested in the data structure display whereas, as the author of the
program I'm debugging, I am already familiar with the class definitions,
file dependencies, call flow, etc. Where I would imagine these tools to be
most useful would be in learning the static structure of a program. When
one is given another person's code to modify, restructure, etc (as is often
the case in industry), the hardest initial task is understanding the layout of
that code. I would imagine all the browsing tools would be very useful at
this point. <P>


<B>Question: If the author claims the system was not very good for
understanding the static program structure, how useful are many of these
tools at all?</B>