menneen~hh - dtic · defense advanced research projects agency defense sciences office systems...

AD-I46 887 PROGRAM ISUALIZTION: GRAPHICS SUPPORT FOR SOFTWARE vi

DEVELOPMENT(U) COMPUTER CORP OF AMERICA CAMBRIDGE MAA SSIFIED HEROT ET AL. 28 SEP 84 N09814-8i-C-0456IUNCL A .7ED G 9/ N

MENNEEN~hh

2.5.

23.2-

3.6.

LAD8 L

1.8-

..'

111.!2 _L

- .....

': -.1 d

Contract N00014-81-0456; NR 049-495

000

PROGRAM VISUALIZATION:(0 GRAPHICS SUPPORT FOR SOFTWARE DEVELOPMENT7.

~ Christopher F. HerotI Gretchen P. BrownO Richard T. Carling

~ David A. Kramlich

Computer Corporation of America4 Cambridge CenterCambridge, Massachusetts 02142

28 September 1984

Final Report

Prepared for

Defense Advanced Research Projects AgencyDefense Sciences OfficeSystems Sciences Division

OFFICE OF NAVAL RESEARCH800 N. Quincy StreetArlington VA 22217 D I

ELECT

SOCT 2 91984~

-J 7 Approvee for public release;L~a....Distribution Unlimited

84 10 18 014.............

Contract N00014-81-0456; NR 049-495

PROGRAM VISUALIZATION:-GRAPHICS SUPPORT FOR SOFTWARE DEVELOPMENT

Christopher F. HerotGretchen P. BrownRichard T. CarlingDavid A. Kramlich

Computer Corporation of America4 Cambridge Center t-Cambridge, Massachusetts 02142

28 September 1984

Final Report

Prepared for

Defense Advanced Research Projects AgencyDefense Sciences OfficeSystems Sciences Division

OFFICE OF NAVAL RESEARCH D I800 N. Quincy Street E E TArlington VA 22217 rce-so For

PTlf' TABUnannou.;nced ElJust, f C-" t on .

Distr~b >on/_

Av, 11, ity Codesand/or

Dist ea

'6?iciass-iriec

I. ORIGINATING ACTIVITY (Cospmee oaihas)W.RPTSEUIYCAIFAIO

Cnbridge. MA Q21423. REPORT TITLZ

PROGRAM VISUALIZATION:

GRAPHICS SUPPORT FOR SOFTWARE DEVELOPMENT4. DESCRIPTIVYE -OEs(~pe port and incl~uive deto)

Final RepartS. AU TmORIS) (First nome, widdle initi, last name)

Christopher F. Herot, Gretchen P. Brown, Richard T. Carling, David A. Kramlich

4. REPORT DATE 7.TTLN.O AE 6 O FMP

28 September 19845CON TRACT OR GRANT NO. So. ORIGINA TOm'S REPORT NUbtUERIS)

N00014-8 1-0456b. PRtOiECT NO0.

NR049-495 ________________________

C. S9b. OTHER REPORT NOIS) (Ant @Uaethumbere aol awy be assignedat& report)

10. OISTRIOUTION STATEMENT

Distribution of this document is unlimited

111. SUPPLEMENTARY NOTES 12. SPONSORING MILITARY ACTIVITY

Defense Advanced Research Projects AgencyDefense Sciences Office

___________________________________ SystemsSciencesDivision1S. ADSTRACT

).,This document is the final report on the design and implementation of aprogram visualization (PV) environment, intended to offer the user an integratedgraphics programming support system. The PV environment has capitalized onrecent progress in the graphical representation of information, to providedesigners and programmers with both static and dynamic (animated) views ofsystems. The PV research prototype supports programming in C, although largeportions of the system are independent of the software development language.\

pow 1473 :re"~ "'"idj,# Unclassified %UwMy Classification

UnclassifiedSecurity Classification________

14. LINK A LINK 9 LINK CKEY WORDS

ROLE WT ROLE WT ROLE WY

programming workstations, graphics, integratedenvironments, software engineering, computeraftimation, program instrumentation

TUnrla~ifirlSecurity Classification

Program VisualizationCONTENTS

CONTENTS

Page

1. INTRODUCTION 1

2. CATEGORIES OF VISUALIZATIONS 3

3. OVERVIEW OF THE PV ENVIRONMENT 7

4. MANIPULATION OF STATIC AND DYNAMIC DIAGRAMS 11

4.1 Graphics Editor for Static Diagrams 114.2 Creation and Control of Dynamic Diagrams 15

5. DISPLAY AND MANIPULATION OF TEXT 17

6. MULTI-DIMENSIONAL INFORMATION SPACE 19

7 . LIBRARY OF DIAGRAM AND TEXT COMPONENTS 23

7.1 Types of Components in the Library 237.2 Overview of Library Organization 247.3 Library Access 27

8. MONITORING RUNNING PROGRAMS 29

8.1 Minimizing Special Requirements 298.2 Efficiency 30

9. CONCLUSIONS 33

10. REFERENCES 35

11. PUBLICATIONS AND MAJOR PRESENTATIONS 37

Program VisualizationINTRODUCTION Section 1

1. INTRODUCTION

Some programs are so simple and so unimportant thatthey can be conceived, developed, used, and possiblythrown away in a single sitting at an interactive computerterminal. The art of conversational programming has beendeveloped to facilitate such expression.

However the bulk of programs upon which societyrelies are complex. They have been developed and refinedby many individuals working over many years. They may notnow be understood by any single person -- they may neverhave been understood by any single person.

, The gnal of program visualization is to facilitatethe understanding of programs by people. To visualizemeans-'f see or form a mental image of&. Successful pro-gram visualizations aid programmers in the formation ofclear and correct mental images of the structure and func-tion of programs.<

Program visualization can be useful in all of thestages of a program's lifecycle:

1. in listing the reAuirements that the program mustsatisfy;

2. in specifying the design of a software system to meetthe requirements;

3. in carrying out the c of the system followingthe plan of the design;

4. in testing and dbugging the code, to guarantee thatit conforms to the design and fulfills the require-ments;

5. in the mntenance of the system, to keep it func-tioning despite changes in the requirements and thediscovery of new bugs; and

6. in helping the end-user use the program by showinghow it operates and how it arrived at the results itpresents.

"': -i-

- ..-- ,. • - ..

Program VisualizationSection 1 INTRODUCTION

The challenge of a research program in program visu-alization (abbreviated here as "PV") is to encompass theseseparate phases of the software development process withina unified conceptual framework in a way which benefitsrather than burdens the user at each stage in theprogram's lifecycle.

This document is the final report for ONR ContractNumber N00014-81-C-0456, covering work from May 1981through October 1983. In addition to the authors, contri-buters to the project included Paul Souza (WGBH TV),Rebecca Allen (New York Institute of Technology), RonaldM. Baecker (Human Computing Resources Corporation), andAaron Marcus (Aaron Marcus and Associates).

The Program Visualization project included bothresearch and system-building components. Section 2enumerates different types of program visualizations,listing the visualization types supported in the PV systemprototype. Section 3 gives an overview of the PV environ-ment, identifying four classes of capabilities that arediscussed in the four sections (4-7) that follow it. Sec-tion 8 describes one solution to an important technicalproblem in program visualization, the need to monitorlarge running programs in order to detect the updates tobe displayed.

A copy of a videotape showing the PV research proto-type in operation has been submitted as a supplement tothis report.

-2-

..............................................

. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . .

Program VisualizationCATEGORIES OF VISUALIZATIONS Section 2

2. CATEGORIES OF VISUALIZATIONS

It is our claim that although graphics has long beena tool in program development and documentation, the fullpower of graphics has yet to be acknowledged or exploited.We have identified ten categories of program illustrationsthat, together, can be of use throughout the software r ....lifecycle. Some categories of illustrations have alreadybeen well explored with respect to programs, and the PVproject was able to draw on this work directly. Othercategories have been less thoroughly explored. The tencategories are:

1. System requirements diagrams2. Program function diagrams3. Program structure diagrams4. Communication protocol diagrams5. Composed and typeset program text6. Program comments and commentaries7. Diagrams of flow of control --

8. Diagrams of structured data9. Diagrams of persistent data

10. Diagrams of the program in the host environment

Many of these categories can apply to either the 91"o-ga, its specific activations, or its data. Moreover,illustrations can be either static or dnami . Staticillustrations portray the program at some instant of exe-cution time, or they portray those aspects of a programwhich are invariant over some interval. Dynamic illustra-tions portray the progress of an executing program. Thecategories of visualization listed are discussed morefully in (8].

In earlier work [9] done in collaboration with

18] Herot, C.F., Brown, G.P., Carling, R.T., Friedell,M., Kramlich, D., Baecker, R.M., An Integrated Environ-ment for Program Visualization, in Schneider, H.J. andWasserman, A.I. (eds.), Automated Tool Lnr InformatinSyst D-eigr North Holland, Amsterdam (1982).

(9] Herot, C.F., Carling, R.T., Friedell, M., Kramlich,D., Design for a Program Visualization System, Technical

--

Program VisualizationSection 2 CATEGORIES OF VISUALIZATIONS

experts in graphic design, we described program visualiza-tion formats from a number of different categories. Underthe current contract, static visualizations were createdfor the majority of the categories above. We chose tofocus, however, on dynamic visualizations, because rela- -.

tively little work had been done in that area.* Withindynamic visualizations, most of the visualizations created

Report CCA-81-04 (January 1981), Computer Corp. of Ameri-ca, Cambridge, MA.

• The pioneering work in dynamic program visualizationincludes:

Balzer, R.M., EXDAMS - EXtendable Debugging and Monitor-

ing System, AFIPS Joint Spring Cmputer Conference (1969) -567-580.

Baecker, R.M., Two Systems which Produce AnimatedRepresentations of the Execution of Computer Programs,A0?1 SIGSE Bulletin, 7, 1 (Feb. 1975) 158-167.

Dionne, M.S. and Mackworth, A.K., ANTICS: A System forAnimating LISP Programs, Computer Graphics and Image Pro-cessing, 7 (1978) 105-119.

Galley, S.W. and Goldberg, R.P., Software Debugging: TheVirtual Machine Approach, Proceedings: ACM Annual Confer-ence (1974) 395-401.

Knowlton, K.C., L6: Bell Telephone Laboratories Low-LevelLinked List Language, two black and white films, sound(Bell Telephone Laboratories, Murray Hill, New Jersey,1966).

The major recent work includes:

Baecker, R.M., Sorting Out Sorting, 16mm color, sound, 25minutes (Dynamic Graphics Project, Computer SystemsResearch Group, Univ. of Toronto, 1981).

7Brown, M.H. and Sedgewick, R, A System for Algorithm Ani-mation, Cmputir Graphics, 18, 3 (July 1984) 177-186.

Myers, B.A., Incense: A System for Displaying Data Struc-tures, Cmputer Graphics, 17, 3 (July 1983), 115-126.

Iom

-4-

. . . . . ... . .[.7...... ..-... ., -..-......................... ..... .. •.......... ..... •. ..

. .- . o° •• . . •. .... •. . . . . . . ..-... - - _

Program VisualizationCATEGORIES OF VISUALIZATIONS Section 2

came from the category of depictions of structured data.Structured data presents a considerable challenge forvisualization, because it takes so many forms. The PVprototype currently supports the display of simple vari-ables, one and two dimensional arrays, linked lists, andtrees. Dynamic views of flow of control were given asecondary priority because, on the whole, depictions ofcontrol flow do not need to be as varied as depictions ofdata. The PV prototype currently supports highlights mov-ing through code to indicate the line being executed; muchof the underlying mechanism is in place to support exten-sion to additional views of control flow. Some photo-graphs taken from the prototype are shown in [15].

115] Kramlich, D., Brown, G.P., Carling, R.T., Herot,C.F.v Program Visualization: Graphics Support forSoftware Development, AC)1/1EY 20_tb Deign AuitomationCnfer.ence (June 27-29 1983) Miami Beach, Florida. ~:

p .p..- --

Program VisualizationSection 2 CATEGORIES OF VISUALIZATIONS

-6

K.

-6-..

N. - . N.

Program VisualizationOVERVIEW OF THE PV ENVIRONMENT Section 3

S

3. OVERVIEW OF THE PV ENVIRONMENT

The current workstation for the Program Visualizationsystem consists of three medium-resolution AED 512 colordisplays. The user interacts with the system via a combi-nation of data tablet with four-button puck, keyboard, andtouch sensitive devices on the displays. The display ,arrangement is flexible, and design work was completed tomove to a single high-resolution color display.

A programmer uses the PV system via a menu-orienteduser interface that displays diagrams and text in multiplewindows on the screen. The current PV window system is inthe spirit of [17], which has been widely replicated. SInformation access in the PV system is aided by diagramsacting as spatial navigational aids, in the mannerpioneered in [10]. The PV system has been prototyped tosupport programming in C, although large portions of thesystem are independent of the software developmentlanguage. The implementation runs on a VAX 11/780 under .Berkeley UNIX.

The PV environment has been designed as an"umbrella", in the sense that it is not targeted to sup-port a single software development methodology. Basicprogram visualization tools can be used in the service ofthe programmer's chosen methodology. For this reason, thesystem supports the following:

- Manipulation of static and dynamic diagrams of computersystems

[17] Teitelman, W., A Display Oriented Programmer's As-Si Stan t, Fifth International Joint Conenc Dn~ Artifi-QW~a Intelligence (1977) 905-915.

(10] Herct, C.F.r Carling, R.T., Friedell, M., Kramlich,D.r A Prototype Spatial Data Management System, SIGAPk111M. Pro.eeding.A: A&k1/SIGGR&Ak Cnferenc (1980) 63-70.

-7-.

• ... ... .. . . . . . . . . . . . . .. ,.;.

Program VisualizationSection 3 OVERVIEW OF THE PV ENVIRONMENT

- Manipulation of program and documentation text

- Creation and traversal of a multi-dimensional informa-tion space

Reuse and dissemination of tools via a library ofdiagram and text components (e.g., templates)

The remainder of this section contains an introduction tothese facilities. The modules named are illustrated inthe PV architecture diagram in Figure 1.

Manipulation of Sta±t Ad Dnmic Dagran ms f Cmpu r

To create, edit, and view static diagrams, theprogrammer/user invokes the Graphics Editor. The GraphicsEditor provides a high level graphics language and givesthe programmer access to prespecified diagram components(e.g., templates and collections of notational symbols) inthe Library. The projected PV system would provide anoptional automated visualization planning capability, per-forming functions such as selecting colors, sizing andpositioning objects, and positioning labels. The currentprototype has a limited facility for automatic sizing andpositioning of objects within dynamic displays of datastructures.

To create, edit, and view dynamic diagrams of pro-grams, the programmer uses the Dynamic Object Controller.The creation of dynamic diagrams can be semiautomatic; inparticular, the programmer can point to variables in hisor her C code and the system will automatically selectappropriate diagrams to display them. Alternatively, theuser can build or select diagrams and bind diagrams tocode with the Binder. In either case, when the programmerfinally runs the program, the Execution Manager in theDynamic Object Controller will monitor the running code toactivate the visualization.

All diagrams are currently stored in the UNIX filesystem. The projected PV system would provide a designdatabase to store diagrams and associated text.

Manipulation Qf jrogra And Documentation Text

The programmer can use the PV system to create andmanipulate static text and also dynamic text (e.g.,highlights moving through code to indicate flow of con-trol).

-.

So. . . . . , -.

' ...o •

. . . .. . , ° . , ', '..

Program VisualizationOVERVIEW OF THE PV ENVIRONMENT Section 3

VISUALIZATIONLIRARY _4PLANNER

IMAGE 1GENERATORj

IEXECUTION PEMil LIOGE]MANAGER

Figure 1. Architecture of the Program Visualization System.

-9-

Program VisualizationSection 3 OVERVIEW OF THE PV ENVIRONMENT

To create and manipulate static text, the programmerinvokes the Text Editor. This text editor is an implemen-tation of EMACS enhanced for the purposes of the PVenvironment. EMACS was chosen because of its power andextensibility. Labeled keycaps on terminal function keyssimplify the use of the text editor. Text (includingcode) files are stored using the UNIX file system, withthe PV system providing additional spatial file accessmechanisms.

To create and manipulate dynamic text, the programmerinvokes the Dynamic Object Controller.

Creationad rnaveral DI A Mlti-DPimensionI Information

Fundamental to the programmer's ability to use thesystem is an information integration mechanism that allowsconvenient access to the quantities of diagrams and docu-ments that are part of a large-scale system developmenteffort. The PV system provides a multi-dimensional infor-mation space in which the programmer can establish linksbetween graphic and textual information. For example, auser viewing a program structure diagram can "zoom-in" onprogram illustrations, moving from one level of abstrac-tion to another, until at the most detailed level the pro-gram code is displayed.

Lrar Diagram And Text Cmpnnts Template-)

Individual programmers or groups of programmers canadd useful graphic and text components to the PV Library.The Library is a network of programming and graphics com-ponents accessible spatially, via a library organizationdiagram that acts as a navigational aid. Through theLibrary, the PV system supports efforts to standardize andshare graphic notations and it supports the re-use of bothcode and illustration segments.

The PV system, then, is designed as a comprehensivesoftware development environment that supports the crea-tion and manipulation of both code and its accompanyinggraphic documentation. The four classes of facilities inthe PV environment are discussed in more detail in each ofthe following four sections.

-10-

. . . . . . . . . . . . . .. ' . . . . .

Program VisualizationMANIPULATION OF STATIC AND DYNAMIC DIAGRAMS Section 4

4. MANIPULATION OF STATIC AND DYNAMIC DIAGRAMS

The PV prototype supports the creation and manipula-tion of both static and dynamic diagrams. Each is dis-cussed in turn.

4.1 Graphics Editor for Static Diagrams

The user begins using the graphics editor by invokingthe command to create a graphics window. This results inthe display of an empty rectangular background whosecolor, size, and location are specified by the user. Theuser may either work on a single window or alternatebetween several different windows. Windows may overlap orcompletely obscure each other; obscured windows are viewedvia a cycle-window command that sequences through the pileof windows. The option to have diagrams larger than the-size of the screen, presenting a portion at a time in awindow, was designed but not implemented (due to time con-straints) in the prototype system.

The graphics editor supports two methods of diagramcreation:

1. drawing/specification

2. assembly

The drawing/specification method is used to creategraphic objects from scratch. Assembly allows the crea-tion of objects using pre-existing components, usuallyentailing considerable time savings. Drawing and specifi-cation are treated as a single method because they form acontinuum. For example, specifying a straight line bypointing to the two endpoints is such a natural activitythat one does not think much about the fact that the lineitself is "drawn" by the graphics system rather than theuser. Most of the specification currently supported in ..the PV prototype involves pointing to other objects toindicate relationships or pointing to locations.

2. assemb.

Program VisualizationSection 4 MANIPULATION OF STATIC AND DYNAMIC DIAGRAMS

The assembly method of diagram creation is simple tounderstand. To assemble pre-existing components, eitherwhole components or parts of components can be copied intoa diagram from other windows. In particular, componentscan be copied from the Library, a section of the PV infor-mation structure supporting the standardization and re-useof graphic (as well as code) components. Three types ofcomponent are used with the copy operation: buildingblock, template, and kit. Building blocks are the sim-plest structures, although they may be complex visually.An example of a building block would be a graphic iconused as a label. Templates are objects with slots thatthe user may fill with text, or in some cases graphics.Kits are mixed collections of building blocks and tem-plates. To take a familiar example, standard flowchartnotation might be implemented as a kit. The user wouldthen create flowcharts by copying symbols from the kit tothe diagram window, filling text in slots as necessary.Connectors would be created by selecting a connector sym-bol from the kit and specifying the end points of the con- 7.

nector.* If the user wished to revise a flowchart diagram,he or she could use diagram editing commands describedlater in this section.

For drawing/specification, the system's main model ofgraphic objects is structural, i.e., it represents graphiccomponents as named entities that have parts and subparts.The system also supports a secondary, vector model usedfor detail drawing to give specific visual or symboliccharacteristics of an object. Finally, a third graphicmodel, the character model, is supported for text in theform of labels and short comments. The difference betweenthe structural and the vector model becomes clear if onethinks of four lines drawn to form a square. In the vec-tor model, if a person points to a place inside the squareand close to one of the lines, we would assume a referenceis being made to that closest line. In the structuralmodel, pointing to this same place (or to anywhere withinthe square) would constitute a reference to the object as

In the prototype, all connector drawing is done throughcommands on the menu. The ability to include connectorsas separate symbols in kits was not implemented as partof the prototype, although it is clearly desirable whendifferent line colors, weights, and textures are avail-able as options. Further work in this direction, alongwith work on automatic routing of complex connectors,would be desirable.

-12-


a whole. In the vector model, a move command would resultin one line moved away from the other three. In thestructural model, all four lines and the space theyenclose would move.

For the structural model, the current PV prototypesupports the creation of rectangles, circles, andpolygons.* The user designates an object as part ofanother by pointing to the parent object at the time theobject is created. This explicit reference allows partsto overlap or to be partially outside the boundaries oftheir parent part. This is a useful feature when objectsare first created, to allow the user to experiment freelywith part sizes. The user designates connectors betweenobjects by either drawing them directly or selecting anoption that causes the system to draw straight line con-nectors for the user. Note that connectors are logicalconstructs rather than purely graphic ones. When anobject is moved, any of its associated system-generated -connectors are redrawn to reflect the new position. Afinal type of object in the structural model is the"slot", used for constructing templates. Slots are rec-tangular objects that the user creates by specifying twopoints and giving a name.

For the vector model, the PV prototype supports thecreation of lines of different weights, circles, andfilled regions. For the character model, the system sup-ports a choice of text fonts (MIT shaded fonts, Berkeleyfonts, and those available on the host hardware). For allmodels, graphic object construction is aided by user-specified rectangular grids, both global grids associatedwith entire diagrams and local grids associated with indi- - "vidual parts. Grids are specified by either pointing totwo points (to indicate the box size) or keying in thenumber of vertical and horizontal divisions of the space.Color mixing is supported in the RGB model by selectingpositions on three color bars.

• Support for polygons is somewhat limited in the PV pro-totype because the hardware that we were using did notsupport polygon generation in the firmware. Sincefirmware support for polygons is now common in graphicshardware, duplication of this work in software was givenlow priority.

-13-• T . . .]--:~-:-, .--


Besides creation of graphic objects, the system sup-ports manipulation operations: copy, move, resize, delete,and recolor.* These operations have two options. Choosingone option causes the operation to apply only to the partthe user has pointed to; choosing the other option causesthe operation to apply to the part and all its subpartsrecursively. Although both options apply to each opera-tion, the default differs. For example, it is more commonto recolor a single part than to recursively recolor (in asingle color). Alternatively, it is more common to deleterecursively than to delete a containing part out fromunder its subparts. (For simple parts, of course, dele-tion behaves the same either way.)

A set of dual-option commands paralleling the set ofobject manipulation commands is provided for graphic text.Thus, blocks of graphic text may be manipulated eitherindividually or recursively. The current unit of textthat can be manipulated in this way is defined withrespect to an object or part, although extension to alower level of granularity may be desirable.

In addition to creating and manipulating graphicobjects, the user can create links between graphics andtext or between two levels of graphics. These links arediscussed in Section 6. An object-info command displaysthe status of each object: name, graphic properties, andexisting links. When the user wishes to stop editing,diagrams can be named and saved for later use.

• The structural and vector models are represented by twoparallel sets of manipulation commands. The PV prototypefully implemented the manipulation commands for thestructural model. There are some gaps in coverage formanipulation commands in the vector model, although thebasic create and move commands are in place. Support forthe vector model within PV was given low priority becausewe were able to use a separate graphic editor previouslyimplemented at CCA. Note that a single set of commandscould be used for both models if two different modes wereintroduced. The use of parallel command sets was helpfulfor development, since we did not know if the sets wouldultimately need to diverge. The need to treat structuraland vector manipulation separately is obvious from theexample of the square cited above. In that case, point-ing to the same place could mean two different referentsaccording to which model the user is assuming.

-14-

.. :,......±, o- ..- -••.-.- ..... •..... . ' ._.-.-.. ---......................................


4.2 Creation and Control of Dynamic Diagrams

The project focused on dynamic views of structureddata, due to the challenge presented by the many formsthat data can take. The types of dynamic graphics sup-ported in the prototype are:

1. in-place updates of values

2. indicators moving on vertical or horizontal scales

3. data cells created, rearranged, and deleted toreflect different pointer relationships

xo specify dynamic graphics, the user must supplyenough information for the system to establish correspon-dences between the code and the static graphic componentsof the dynamic visualization. We refer to this process as"binding". There are two binding methods, paralleling thetwo methods for static object creation: the user mayeither draw/specify the binding from scratch or he or shemay assemble the binding by combining pre-bound com-ponents.

To create a binding from scratch, the user first

creates any necessary static components using techniquesdescribed above. Taking a simple example, a user wishingto display an integer might create a special cell thatshows the variable name and indicates the type and preci-sion. Once the necessary static components have beencreated, the user accesses a pop-up menu of dynamic typesand selects the type desired. In the current prototype,binding for each dynamic type is done by a discrete sub-routine which asks the user questions appropriate to thetype. Questions relate to the type, range, and relatedproperties of a data structure as well as the graphicregions in which information~ is to appear. While thediscrete subroutine approach was useful for the earlystages of the work, it is desirable to replace the fixedbinding protocols by more flexible interactions. Aforms-oriented interface would allow the user to order theinteractions, and it would permit more sharing of bindingcode across dynamic types.

Once the user has finished the binding for each com-ponent in the visualization, this information remainsassociated with the graphic objects. This not only

-15-

. .Uo O.-


permits dynamic visualization specifications to be savedfor re-use, but it also permits dynamic graphic componentsto be "packaged" so that they can be used in other assem-blies. Thus, creation by assembly works for dynamic aswell as static graphics. This supports the cluster capa-bility described in Section 7, whereby a code template anda corresponding graphic template can be pre-defined(including dynamics) and then inserted in the code and thevisualization, respectively. To complete that part of thevisualization, the user need only fill in specifics, suchas the name of the variable. Use of such a cluster to dobinding "by assembly" is illustrated in the videotape thataccompanies this report.

To view dynamic visualizations once they have beencreated, the system provides both speed control and step-ping. Viewing speed is controlled by a bar on the menu,which the user can lengthen or shorten to get differentpercentages of the maximum speed. Since absolute timesare not particularly meaningful in this context, we choseto mark only quarters on the bar, although finer grada-tions may be selected. For stepping, the visualization isdisplayed one step at a time, in the lowest level ofgranularit currently displayed. Thus, if program code isdisplayed, the system behaves like the standard step modeand executes one line, waiting for a user signal (in thiscase a button-push) to continue. If, however, only avisualization of one data structure is displayed, then thepauses come only each time the data structure is updated.This is an important capability, because it lets the usermove from very general view of the program to very local-ized view merely by selecting different diagrams. It alsopermits the user to view program execution from the per-spective of selected data structures, either key datastructures or those that are of current, temporaryinterest for debugging.

The PV prototype, then, embodies a representative setof dynamic types that can be used for common data struc-tures such as numeric variables, arrays, linked lists, andtrees. This area deserves further research, both toextend the coverage of dynamic types and to increase thesophistication of the animation techniques available.Besides visual polish, more sophisticated animation tech-niques can add considerably to the clarity and comprehen-sibility of the dynamic visualization, particularly forlarge data structures.

-16-:-.

Program VisualizationDISPLAY AND MANIPULATION OF TEXT Section 5

5. DISPLAY AND MANIPULATION OF TEXT

Due to the magnitude of the task of PV system designand implementation, we made a pragmatic decision to incor-porate existing non-graphic software development tools.In the case of text editing, this decision lead to a work-able arrangment, although one with less integration ofgraphics and text than we would have liked. This sectionbriefly describes text handling within the PV prototype,followed by some comments on desirable directions for thefuture.

The text editor chosen for the PV prototype wasEMACS, in the form of CCA's EMACS implementation for LBerkeley UNIX. EMACS was selected because of its powerand because of the support it gives programmers in custom-izing their editing environment. The PV project fundedextensions to CCA EMACS to achieve a closer couplingbetween text and graphics. One such extension allowedextraction of enough information from C code to permit asimple level of pattern matching on variable declarations.This pattern matching was used in automatic access of agraphic depiction appropriate to the variable type.Another extension was the addition of EMACS "picturemode", which permits the user to manipulate text as atwo-dimensional object. This mode provides an alternativeto the line-oriented "one-dimensional" mode that is stan-dard to EMACS. From the PV user's point of view, the twodimensional model is closer to the model used for graph-ics, and it is useful for certain types of editing.

In the PV prototype, text is displayed in three typesof windows:

1. EMACS

2. UNIX shell

3. read-only text or code

EMACS windows allow the text to be edited, with viewingcontrolled by the standard EMACS commands to page throughfiles. Text is currently stored in the UNIX file system.Shell windows display the UNIX C-shell command prompt and

-17- . . ... ..

Program VisualizationSection 5 DISPLAY AND MANIPULATION OF TEXT

permit users to execute the full range of commands andapplication programs that have non-graphic output.Finally, read-only windows are used for temporary displaysof text or code displayed for the user's information orfor the user to verify.

One use of EMACS windows is in the display of dynamictext, e.g., code with moving graphic indicators(highlights or arrows) to indicate the progress of theexecution of a program. The current prototype supportsthe dynamic display of one level of code in a window,although extension to show subroutine execution is possi-ble. Once dynamic text is extended to multiple windows,it would be straightforward to couple the text displaywith a stack diagram and a highlighted program structurediagram. The PV prototype provides the basic framework tosupport these extensions (see Section 8).

We mentioned that integration of graphics and text,while acceptable, is less extensive than we would haveliked. One capability that would be desirable is theability to assign a fuller range of graphic attributes toprogram text, which has been explored by Baecker andMarcus [2]. Another desirable capability is structure-editing for both code and formatted text. Incorporationof a structure editor in the spirit of [16] would be par-ticularly useful for handling templates and for specifying '""pattern matches for automatic library accesses (e.g., finda graphic depiction that matches information in a variabledeclaration).

7 7

(2] Baecker, R.M. and Marcus, A., On Enhancing the In-terface to the Source Code of Computer Programs, Huma.Factors in Compuing Systems, CHI83 Conference Proceed-ings, Association for Computing Machinery, New York(1983) 251-255.

(163 Teitelbaum, R.T., The Cornell Program Synthesizer: AMicrocomputer Implementation of PL/CS, TR 79-370 (1979),Department of Computer Science, Cornell Univ.

-18-

Program VisualizationMULTI-DIMENSIONAL INFORMATION SPACE Section 6

6. MULTI-DIMENSIONAL INFORMATION SPACE

The multi-dimensional information space provided bythe PV system permits the programmer to establish links:diagram to diagram, text to text, diagram to text, andtext to diagram. Links are associated with the whole orwith individual parts of the diagrams or text. Theselinks are then traversed by the user by selecting a "zoom"command and then pointing to the relevant object, objectpart, text file or text section.

Links are created by the user by selecting from amenu of relationships. The user then points to theobjects that participate in that relationship or, if adestination object is not currently shown, its name iskeyed in. The relationships currently supported withinthe PV prototype are:

1. source: graphics to code

2. object: graphics, text or code to graphics

3. documentation: graphics or code to text

4. notes: anything to text

uther code to code relationships were implemented forexperimentation. In the prototype, the user follows linksby selecting a command of the appropriate link type andthen pointing to an item (graphic, text or code) displayedon the screen. One special command, "zoom", is intendedfor following object links that relate items at two dif-ferent levels of detail.

In keeping with PV's role as an umbrella system, adesirable (and straightforward) extension would be toallow the user to define new binary link types. Anotherdesirable extension is support for simple type checking oflink parameters when the links are established.

The links provided by the PV system are intensionallygeneral enough that they make few constraints on the type "of information relationships that can be specified. Inworking with the PV prototype to build examples, however,

-19-

- '- .• ... ...

Program VisualizationSection 6 MULTI-DIMENSIONAL INFORMATION SPACE

we followed the approach used in SDMS [10]. In our exam-ples, the dominant information organization is hierarchic.Other non-hierarchic relationships are then used asneeded. That is, the dominant motion through the informa-tion space is "zooming in" on graphic objects to get amore detailed view of a particular section.

For the PV prototype, we suggested a core set of fourhierarchies: system requirements, structure, evolution(i.e., version control), and the library. The first threeof these hierarchies are project-specific collections ofinformation about the system being developed by the user.The fourth hierarchy, which is shared by all users of thePV system, is described in the next section. Note thatthe project-specific hierarchies are suggested asdefaults, and additions corresponding to any of the stepsin the software lifecycle would be appropriate.

We have called the top level diagram for each hierar-chy the navigational aid, or navaid. This term is bor-rowed from SDMS, where navaids present visual context fordetailed views and they give a means for moving around aninformation space to select more detailed views. Althoughthe PV navaid is not exactly equivalent to the SDMS one,we use the term to emphasize the role of the top leveldiagrams as a map of their respective information spaces.For example, the system structure navaid might show a toplevel structure diagram in the user's prefered graphicalnotation. A more detailed diagram is then associated witheach module, with this process continuing to the depthneeded. At the most detailed level the user might thenattach the actual code. The navaid diagram can serve as astarting point for access to any part of the structurehierarchy, and so it acts as a global map.

To keep the user from getting lost as he or she movesbetween levels of the hierarchies, there is also a needfor immediate context. Clear diagram labeling and number-ing schemes are important aids; the project designedgraphic icons for the suggested hierarchies so that eachwindow could be labeled with the hierarchy to which itbelonged. Again applying techniques from SDMS, we foundit helpful to display with each diagram a miniaturizedview of the diagram above it in the hierarchy. The

1101 Herot, C.F., Carling, R.T., Friedell, M., Kramlich,D., A Prototype Spatial Data Management System, SIGGRPH.&

-20-

Program VisualizationMULTI-DIMENSIONAL INFORMATION SPACE Section 6

miniaturization has a "you are here" region marked, and aset of bars on the side show the current depth in thehierarchy.* One question that needs to be investigated iswhether these miniaturized views should only reflectstatic hierarchic relationships or whether they shouldinstead reflect the path that the user took to access theinformation during the current session. That is, ifaccess was via a cross-hierarchy link rather than viazooming, is it most useful to see a miniaturization of thehierarchic context or the access context.

In summary, the PV system provides a multi-dimensional information space that aims to be neutral withrespect to the information structures defined. The sug-gested mode of use, however, is to construct a set ofhierarchies, interrelated by cross-links as necessary.

*A small amount of additional code would be necessary tocompletely support this feature in the prototype.

-21-

. . -.-. -.

Program VisualizationSection 6 MULTI-DIMENSIONALJ INFORMATION SPACE

-22-

Program VisualizationLIBRARY OF DIAGRAM AND TEXT COMPONENTS Section 7

7. LIBRARY OF DIAGRAM AND TEXT COMPONENTS

The PV Library is a collection of code, text, sym-bols, and diagrams shared by users of the PV system. Itis the repository for code components (e.g., code tem-plates) for individual projects as well as for generaldesign notations shared by projects. Graphical components ,-stored in the Library allow PV users to construct manytypes of program visualizations simply by combining ele-ments rather than by starting from scratch.

7.1 Types of Components in the Library

Four basic types of components are stored in the PVLibrary:

1. building blocks

2. templates

3. kits

4. generators

Building blocks are fully instantiated objects orcomplete modules. A code example of a building blockwould be a subroutine to compute square roots. A graphicexample would be a symbol used as an iconic label, forexample the icons used to label classes of commands on thePV menus.

Templates are objects with internal slots that mustbe filled in by the user (or the system) to complete thespecification of the object. The initial PV prototypedoes not support checking of information placed in slots,but it does support automatic propagation of slot entriesso that the user is not required to fill in informationmore than once. This is discussed in more detail below.

-23-

."-• o..."... . ........-.. • ... . . .. . .

Program VisualizationSection 7 LIBRARY OF DIAGRAM AND TEXT COMPONENTS

Kits are sets of templates and building blocks, e.g.,standard flowchart notation could be represented within akit.

Generators can be though of as general tools andapplication programs that produce objects, either directlyor interactively. Examples of generators are text for-matters, code formatters, and graphic menu building pro-grams. The difference between generators and subroutinesthat are used as building blocks is that building blocksare used directly by the PV user, while generators are runto create objects that are used.

The PV prototype as implemented supports the firstthree types of components. Generators can be stored inthe Library and they can be run within UNIX shell windows;they cannot, however, be automatically invoked when theLibrary node is accessed.

To support the user in carrying out related paralleltasks, the PV Library permits components to be groupedinto "clusters". For example, the user may want to con-struct graphic visualizations, write code, and create theappropriate textual documentation all at the same time.To permit the application of assembly techniques to thesetasks, clusters of components may be stored in theLibrary. For example, code for a numeric subroutine, itsdynamic visualization, and its manual page may be storedas three building block components in a cluster in thelibrary. The members of the cluster may either be accessedindividually, or they may be accessed by a specialautomatic method discussed at the end of this section.Finally, note that when templates participate in clusters,automatic propagation of slot-fillers is supported acrosstemplates. For example, the variable name slot in a datadeclaration template might be linked to a name slot on agraphic depiction of the data type. Filling in the textin one or the other slot can lead to automatic propagationof the text to the related slot.

7.2 Overview of Library Organization

While the PV prototype does contain some specialized ..-code related to the Library, the Library is basicallyimplemented as an application of the information linkingtechniques described in Section 6. As such, Libraryorganization is relatively open-ended. We do, however,suggest some methods of organization that we expect to be

-24-


of use when large numbers of components are added to theLibrary.

The proposed Library organization consists of threetaxonomies:

1. general programming concepts

2. graphical structures

3. projects

component in the Library may be a descendant of anyone, or any combination of, the three major taxonomies.The organization of each taxonomy is discussed in turn.

An attractive candidate for the taxonomy of generalprogramming concepts is the AFIPS Taxonomy of ComputerScience and Engineering [14]. This taxonomy contains Jabout 1500-2000 nodes under the major headings:

1. hardware

2. computer systems

3. data

4. software

5. mathematics of computing

6. theory of computation

7. methodologies

8. applications/techniques (illustrative)

9. computing milieux

The taxonomy is a tree with cross-references that is at

[14] Taxon.m of Cmputer Science a Engine.eing, AFIPSTaxonomy Committee, AFIPS Press, Arlington, VA (1980).

-25-

1i gram VisualizationSection 7 LIBRARY OF DIAGRAM AND TEXT COMPONENTS

most six nodes deep. Some additions to this taxonomywould be necessary to reflect technological change sinceits publication, and some categories (e.g., computingmilieux) might be pruned as irrelevant to the PV environ-ment. On the whole, however, it appears that this taxon-omy can provide a useful framework for organizing PV com-ponents according to their relevance to programming.

To organize components according to their graphicstructure, we propose to use an approach described by Twy-man [15]. Twyman lists what he calls "methods of confi-gurationu by which he means "the graphic organization orstructure of a message which influences and perhaps deter-mines the 'searching', 'reading', and 'looking' strategiesadopted by the user" (p.120). Twyman proposes the follow-ing categories, for which we have added examples relevantto programming:

1. Pure Linearpure examples are rare, but some depictions ofstrings belong to this class

2. Linear Interruptede.g., connected text

3. List*e.g., certain types of graphic pop-up menus

4. Linear Branchinge.g., depictions of tree data structures with nodesand connectors drawn; also, indented code

5. Matrixe.g., tables with discrete alphanumeric elements suchas two-dimensional arrays

6. Non-Linear Directed Viewinge.g., network diagrams

7. Non-Linear, Most Options Opene.g., two-dimensional memory maps

A second dimension suggested by Twyman, the aMode of

115] Twyman, M., A Schema for the Study of GraphicLanguage, in Proessinggf Vinihle La ngua I., 117-150.

-26-

- .-i


Symbolization" continuum (verbal/numerical, pictorial andverbal/numerical, pictorial, and schematic), is relevantfor PV as well. It can be used as a secondary classifica-tion scheme within method of configuration. It might alsobe useful to subclassify by whether a component isdynamic, and, if so, what type of dynamics is used.

Finally, project-specific entries may be made andindexed under the third proposed PV taxonomy. The projecttaxonomy allows a group to identify a set of components,both standard technical tools (e.g., Jackson diagrams,etc.) and special-purpose components constructed for thegroup. The structure of the project taxonomy is up toindividual projects. Projects can add intermediate clas-sifying nodes to the Library information structure, sothat the organization of components for a given project isas simple or complex as desired.

7.3 Library Access

The Library is available to the user as soon as thePV environment is invoked. There are three ways to accesscomponents in the Library: by navaid, by keyboard, andautomatically from a cluster entry. Each is discussed inturn.

The main method of PV Library access is spatial, viathe Library navaid. The Library navaid, like the othernavaids proposed for the PV system, is a standard PVdiagram in a standard PV window. The navaid displays theorganization of the Library as a lattice, with nodes foreach component, cluster, and classifying category.Graphic icons may supplement text to label major classify-ing nodes. A more limited example navaid constructed forthe prototype is a tree with nodes connected by straightline connectors. The user moves around the navaid by thestandard PV display command set. This set includes a com-mand to move an entire window-full in any of four direc-tions relative to the current window, as well as a "goto"command that takes a node name as argument and centers thewindow on that node. Note that motion over navaidsrequires support for diagrams larger than a window;although this capability was designed, it was not imple-mented in the prototype system.

Once the user has chosen a component node, he or shecan zoom in on it to get a view of the component itself.The zoom command has two options: to display the component

-27-

Program VisualizationSection 7 LIBRARY OF DIAGRAM AND TEXT COMPONENTS

in the current window, replacing the navaid, or to createa separate window for viewing the component. In eithercase, components can then be copied from the detail windowto an editing window. This copying operation actuallycreates an instance copy, which the user can augment ormodify as desired.

A second way to access Library components isdirectly, by keyboard. Since the Library is implementedas a collection of standard objects linked via the stan-dard information structure, the user can execute a "use"command and key in the unique identifier of the component.While these identifiers would not necessarily be easy toremember (hence our emphasis on spatial access vianavaid), they are accessible to the user by executing an"object-info" command on the component detail window. Forfrequently accessed components, this direct approach canbe efficient.

The third way that library components are accessed isautomatically by the PV system itself. This is done topick up components within clusters, e.g., visualizationsassociated with data structure types. First, an elementin a cluster is accessed by either of the two meansdescribed above, and the component is copied to the targetwindow. If the component is a template, text slots in thetemplate may be filled in by the user. The user thenselects a special "autoaccess" button from the PV menu.The system goes to the Library, retrieving other elementsin the cluster. In the current implementation, autoaccessis restricted to clusters of two elements (code and visu-alization), but extension to larger clusters would bestraightforward. The system would need to display thetypes of the information links used to construct the clus-ter, and the user would then choose the type, and hencethe component, of interest. When autoaccess finds thecomponent desired, it returns it with any necessary slotfiller propagations done. The component is shown in atemporary window, and, if the user is satisfied with theselection, a button-push causes the component to beinserted into the editting window. This automatic accesssequence is illustrated in the PV videotape that accom-panies this report.

In summary, the PV Library currently accomodatesthree kinds of access: spatial, direct, and automaticaccess within clusters.

-28-

. .. . . . ..-. -- . .< . -. .' . '< - -. -.. - . -. - - - ' . - ' . - - . -.. < .. • • - - - " - ." -" " - " . . - - '2-

Program VisualizationMONITORING RUNNING PROGRAMS Section 8

5..

8. MONITORING RUNNING PROGRAMS

In order for program visualization to be a practicaltechnique for monitoring large programs, the monitoringmust be non-intrusive. That is, visualization of compiledcode must be done without recourse to the inclusion ofspecial graphics statements into the source code. Wedescribe here techniques that can be applied to monitorprograms (other than real-time systems) that run under theUNIX operating system. Our discussion centers on the Exe-cution Manager module shown in Figure 1.

The Execution Manager, as its name implies, interactswith and manages the program being monitored. It has twomain tasks: determine where the program is currently exe-cuting, and monitor user-selected variables for updates.

Our implementation of the Execution Manager makes useof software debugging facilities provided in the UNIXoperating system and hardware features used to implementvirtual memory. The UNIX environment provides a set offacilities by which one process may manipulate the regis-ters and address space of another process. Several new . -

features were added to allow the monitoring process (Exe-cution Manager) to manipulate the memory mapping of themonitored process (the user's program). In addition, the LPortable C Compiler was modified to produce a supplementedsymbol table, which the Execution Manager uses to locatevariables and code in the user's program.

There were two primary goals in the implementation ofthe Execution Manager: minimize any special requirementson the monitored program, and make monitoring as efficientas possible.

8.1 Minimizing Special Requirements

The first goal was achieved by placing the burden ofprogram monitoring on the C compiler and the ExecutionManager. The modified C compiler produces a completedescription of the global variables, procedures, localvariables, and source code to machine code mapping. Theuxecution Manager uses this augmented symbol table to map

-29-

4 . . - - .- - . - - . . . . . . . . .. --. .

Program VisualizationSection 8 MONITORING RUNNING PROGRAMS

symbol names into addresses in the monitored process. Itshould be noted that the C compiler is a modified versionof the one distributed by U.C. Berkeley. Berkeley's ver-sion produces a very complete symbol table; the compilerwas modified to correct the few deficiencies that it had.

In order to monitor a particular program, the onlyrequirements are that it be compiled by the modified C -compiler and that it be linked with a special assist rou-tine described below. The code generated by the modifiedC compiler is identical to that generated by the conven-tional compiler. That is, there are no performance penal-ties in using the modified compiler. The only differenceis the larger symbol table that is produced.

8.2 Efficiency

The second goal, efficiency in program monitoring,was supported by exploiting applicable hardware charac-teristics. Two of the characteristics exploited are foundon nearly all machines: the single-step execution modeand the breakpoint instruction. The third characteristicis virtual memory, a feature common on new machines.

The single-step mode of execution is used principallyto track the execution of the monitored process. Aftereach machine instruction has executed, the process trapsto the operating system which then notifies the ExecutionManager. The Execution Manager reads the current value ofthe program counter and maps the value into a file name,procedure name, and line number in the source code usingthe mapping provided by the compiler in the symbol table.This information then can be used for highlighting a lineof code in a source code display or highlighting a pro-cedure invocation on a stack.

The breakpoint instruction also is used to track exe-cution, but at a coarser granularity. Although the usermay insert breakpoints anywhere in the code, the most com-mon use of the breakpoint is at the beginning of a pro-cedure that contains local variables to be monitored.

Our use of virtual memory is less self-evident, andwe spend the rest of this section discussing it. In orderto maintain an accurate display of data structures whichthe user has selected for viewing, the Execution Managermust detect any updates. There are several ways in whichthis detection might be done: analyze the executing

-30-

. . . . . ..

Program VisualizationMONITORING RUNNING PROGRAMS Section 8

program for all assignments to the selected data struc-tures; examine each data structure after every instructionfor value changes; tag the data structures so that an

update will cause an event. These approaches are dis-cussed below.

Code analysis will catch most, but not all, assign-ments. Programs written in languages that allow indirectreferences through pointers (as in C) or which allow thedynamic creation of data structures at run-time (throughmemory allocation routines) may have "hidden" assignmentsin them. Examining each data structure after everyinstruction is very inefficient and slows the speed ofexecution of the monitored process significantly. Taggingthe data structures is the most general approach, but itsuffers from several limitations: most machines do notallow individual memory locations to be tagged; localvariables pose a problem because their locations in memoryare not fixed; and register variables usually cannot be

I tagged.

To overcome these limitations, the PV implementationuses a variation on tagged memory. Instead of taggingindividual memory locations, an entire page is tagged. Bysetting the protection of a page that contains a datastructure being monitored to be read-only, a trap willoccur whenever a write occurs on that page. The ExecutionManager then checks to see whether the address(es) justwritten include a data structure which it is monitoring.If so, the new value is read and displayed.

The process of catching updates works in a straight-forward way for global and static variables because theiraddresses are fixed at load time and do not change. How-ever, variables local to a procedure are allocated spaceon the stack. Thus their real addresses will vary,depending on the history of procedure invocations. Toovercome this problem, the Execution Manager sets a spe-cial breakpoint at the beginning of each procedure thatcontains local variables to be monitored. When one ofthese breakpoints is executed, the following steps areperformed:

1. Record the value of the stack pointer at that point.

2. Copy the current stack frame (corresponding to theprocedure just invoked) on the stack to make room fora new interposed stack frame. This new framerepresents the context of the special assist routinementioned earlier and is used during the cleanupafter the watched procedure returns.

-31-

• . o.

Program VisualizationSection 8 MONITORING RUNNING PROGRAMS

3. Set the stack page(s) that contain the local vari-ables to be read-only.

4. Resume execution of the interrupted procedure.

Execution continues as in the case of global variables.Traps will occur when the protected stack pages are writ-ten to. When the procedure returns, it returns to thespecial assist routine. The assist routine signals theExecution Manager that a procedure that had local vari-ables being monitored has returned. The Execution Managerthen resets the protection on the pages and resumes execu-tion of the monitored program.

The implementation of the Execution Manager has beendescribed. The Execution Manager monitors the status ofthe executing program in such a way as to minimize theeffects of the monitoring on performance. This isachieved by means of modifications to the C compiler usedto compile the monitored programs and by extending theUNIX kernel to allow one process access to another pro-cess' memory map.

7.

-32-

°..... ...-. "

Program VisualizationCONCLUSIONS Section 9

9. CONCLUSIONS

We expect on-line, interactive graphics to have aprofound impact on software development, analogous to theway that word processors have affected the production oftext. With respect to static graphics, the multi-dimensional graphic information structure that we have Sdeveloped for PV will allow the programmer to move easilybetween pieces of related information (e.g. requirementsand system structure). With respect to dynamic graphics,PV's animated views of program execution can help program-mers achieve a deeper and more accurate understanding ofthe behavior of their programs. .

The work done under this contract has led to a betterunderstanding of the role of diagrams, particularlydynamic diagrams, in the software development lifecycle.Because the research area is relatively new, however, con-siderable work remains to be done. One challenge is the I.graphical depiction of very large data structures. The PVgraphic representation supports multiple levels of detailso that users can view more detail as needed. Therequisite support for data abstraction is not presentwithin C, however, so that this technique can be bestexplored in the context of a language such as Ada. L

Another challenging problem is the controlled use ofdynamic graphics. The PV project has explored techniquesfor drawing the user's attention to parts of the displaythat are about to change. More work must be be done, how-ever, to insure that dynamics enhance the clarity of the Svisualization. A more complete dynamic vocabularyappropriate to programming needs to be developed, withparticular attention paid to the demands of visualizations -.-.(both graphic and text) that are so large that they canonly be viewed in segments.

-33--

. . .. . . . . .. 2.

-33- .I.* _____

I Program VisuLizationSection 9 CONCLUSIONS

-34-

Program VisualizationREFERENCES Section 10

10. REFERENCES

0

[I] Balzer, R.M., EXDAMS - EXtendable Debugging and Moni-toring System, AFIPS Joint Spring Computer ConfgeJr e.(1969) 567-580.

[2] Baecker, R.M. and Marcus, A., On Enhancing the Inter-face to the Source Code of Computer Programs, Human £ac-torn in Computing SysJem , CHI83 Conference Proceedings,Association for Computing Machinery, New York (1983) 251-255.

[3] Baecker, R.M., Sorting Out Sorting, 16mm color,sound, 25 minutes (Dynamic Graphics Project, Computer Sys-tems Research Group, Univ. of Toronto, 1981).

[4] Baecker, R.M., Two Systems which Produce AnimatedRepresentations of the Execution of Computer Programs, ACMSGCSE Blletin, 7, 1 (Feb. 1975) 158-167. p

[5] Brown, M.H. and Sedgewick, R, A System for AlgorithmAnimation, Cmpute~r Graphics, 18, 3 (July 1984) 177-186.

[6] Dionne, M.S. and Mackworth, A.K., ANTICS: A Systemfor Animating LISP Programs, Computer Graphics and ImageProcessing, 7 (1978) 105-119.

[7] Galley, S.W. and Goldberg, R.P., Software Debugging:The Virtual Machine Approach, Proceedings: ACM AnnualConference (1974) 395-401.

[8] Herot, C.F., Brown, G.P., Carling, R.T., Friedell,M., Kramlich, D., Baecker, R.M., An Integrated Environmentfor Program Visualization, in Schneider, H.J. and Wasser-man, A.I. (eds.), Automae Tools fr Informati n ,sDesign, North Holland, Amsterdam (1982).

[9] Herot, C.F., Carling, R.T., Friedell, M., Kramlich,D., Design for a Program Visualization System, TechnicalReport CCA-81-04 (January 1981), Computer Corp. of Amer-ica, Cambridge, MA.

-35-3 . ., " .. •.

Program VisualizationSection 10 REFERENCES

[101 Herot, C.F., Carling, R.T., Friedell, M., Kramlich,D., A Prototype Spatial Data Management System, SI.GGAPl'80 iin: APo/SAP (1980) 63-70.

[11] Kramlich, D., Brown, G.P., Carling, R.T., Herot,C.F., Program Visualization: Graphics Support for ScftwareDevelopment, ACM/IEEE 20th Design AJ1omation Cnfernce(June 27-29 1983) Miami Beach, Florida.

(12] Knowlton, K.C., L6: Bell Telephone Laboratories Low-Level Linked List Language, two black and white films,sound (Bell Telephone Laboratories, Murray Hill, New Jer-sey, 1966).

[13] Myers, B.A., Incense: A System for Displaying DataStructures, Comput Graph.L, 17, 3 (July 1983), 115-126.

[141 Tax.nofn1 Compute Scienc and Engineering, AFIPS .

Taxonomy Committee, AFIPS Press, Arlington, VA (1980).

[15] Twyman, M., A Schema for the Study of GraphicLanguage, in Priocessing f Visibl Language I., 117-150.

[16] Teitelbaum, R.T., The Cornell ... gram Synthesizer: AMicrocomputer Implementation of PL/CS, TR 79-370 (1979),Department of Computer Science, Cornell Univ.

[17] Teitelman, W., A Display Oriented Programmer's Assis-tant, Fifth International Joint Cnference .n ArIfic ial'Intelligence (1977) 905-915.

-36-

............................................................................................

o...........................

Program VisualizationPUBLICATIONS AND MAJOR PRESENTATIONS Section 11

11. PUBLICATIONS AND MAJOR PRESENTATIONS

December 1981

Christopher Herot, Mark Friedell, and Diane Smithtook part in a DARPA conference organized by Craig Fieldsof the System Sciences Division. Copies of the presenta-tions were compiled in "DARPA Conference on ComputerSoftware Graphics", Key West Florida, Dec. 13-15 1981.

January 1982

Christopher Herot and Gretchen Brown participated inthe IFIP WG 8.1 Working Conference on Automated Tools forInformation Systems Design and Development, New Orleans,26-28 January, 1982. The paper presented at this confer-ence, "An Integrated Environment for Program Visualiza-tion", appeared in Schneider and Wasserman (eds.),Automated Tools for Information Systems Design, North-Holland Publishing Co., 1982.

February 1982

Christopher Herot gave a presentation on PV at ameeting of the Northeastern ACM Chapter on February 18.

March 1983

Gretchen Brown was a panelist at the ACMSIGSOFT/SIGPLAN Symposium on High-Level Debugging. Theposition paper for this workship appeared as: ChristopherF. Herot, David Kramlich, Richard T. Carling, Gretchen P.Brown Debugging in an Integrated Graphics ProgrammingEnvironment, Preprint of the Proceedings of the ACMSIGSOFT/SIGPLAN Symposium on High-Level Debugging, 1983March 20-23, Pacific Grove, California.

May 1983 S

Christopher Herot, David Kramlich, and Paul Souza(graphic designer affiliated with WGBH) participated inthe DARPA Program Visualization Conference, organized byClinton Kelly of the System Sciences Division. L.

-37-

.......................................................... .°°

. . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . .

Program VisualizationSection 11 PUBLICATIONS AND MAJOR PRESENTATIONS

June 1983

David Kramlich presented a paper at the ACM/IEEEDesign Automation conference, which appeared as: DavidKramlich, Gretchen P. Brown, Richard T. Carling, Christo-pher F. Herot Program Visualization: Graphics Support for .Software Development, ACM/IEEE 20th Design AutomationConference, June 27-29 1983, Miami Beach, Florida.

-.-

- °"

S. . -

p.-..

-38-.o

m-_- l

. . . . . . .. . . . . . . . . . . .... . .

. . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . .. -°

. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . .

DISTRIBUTION LIST

Defense Documentation Center 12 copies SCameron StationAlexandria, VA 22314

Office of Naval ResearchArlington, VA 22217 : -

Information Systems Program (437) 2 copiesCode 200 1 copyCode 455 1 copyCode 458 1 copy

Office of Naval ResearchEastern/Central Regional Office 1 copyDldg. 114 Section D666 Summer StreetBoston, MA 02210

Office of Naval ResearchBranch Office, Chicago 1 copy536 South Clark StreetChicago, IL 60605

Office of Naval ResearchWestern Regional Office 1 copy1030 East Green Street t.Pasadena, CA 91106

Naval Research LaboratoryTechnical Information Division, Code 2627 6 copiesWashington, DC 20375

Dr. A. L. SlafkoskyScientific Advisor 1 copyCommandant of the Marine Corps (RD-l)Washington, DC 20380

Naval Ocean Systems CenterAdvanced Software Technology Division 1 copyCode 5200San Diego, CA 92152

Mr. E. H. GleissnerNaval Ship Research & Development Center 1 copyComputation & Mathematics DepartmentBethesda, MD 20084

L

-39-

... ~~ ...... . . . . . . . . . . . . . . .

Capt. Grace M. Hopper (008)Naval Data Automation Command 1 copyWashington Navy YardBldg. 166Washington, DC 20374

Defense Advanced Research Projects AgencyAttn: Program Management/MIS 3 copies1400 Wilson BoulevardArlington, VA 22209

Mr. Robert J. Power 1 copyDCRB-DCB-B8Administrative Contracting OfficerDefense Contract Administration ServicesManagement Area, Boston495 Summer StreetBoston, MA 02210 -

-40-

. . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . .

Pt P

~w 40-f,.,~

, Itixq,

Ft. 'k -44 /

S.4I 1A'

14 , -1',

1,1

WK '4 ~~ .

N ' t',. '

menneen~hh - dtic · defense advanced research projects agency defense sciences office systems...

Documents