IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 16, NO. 5.

MAY 1990 543

A Framework for the Automated Drawing of Data

Structure Diagrams
CHEN DING AND PRABHAKER MATETI, MEMBER, IEEE

Abstract-Data structure diagrams are two-dimensional figures made Debugging: In debugging, pictorial representations of
up of lines that aim to pictorially indicate the interrelatiomM
data often make it easier to locate problems and reasons
elements of a data structure. This paper collects the various ru
factors of aesthetics that go into the way we draw data struct for them [25], [34].
grams. We formulate the various subjective factors into computable Program Understanding: Dynamic properties of pro-
objectives and numeric parameters. These are dis grams may be understood through animated diagrams in
number of data structure drawings as found in var animation systems [22], [lo], [ 121, [311. They pictorially
reveal that the rules used have not reached a level
display the contents of interesting variables and update
pared to the relevant rules in engineering graphics. We also outline fhe
internal architecture of a (sub)system that we are building that helps the display as the values change.
draw data structure diagrams. Program Design: During the exploratory period that
precedes detailing the chosen design, people draw pic-
Index Terms-Aesthetics, data structure diagrams, documentation tures of the data structures they are considering, and var-
systems, line drawings, visual debugging.
ious other diagrams that capture the architecture of the
1. INTRODUCTION system. [32] is a book on such diagrams and their con-
ventions.
A picture is worth a thousand words.
Program Visualization is an emerging area [2 11, [28],

I T is unlikely that there are any English-speaking adults

who have not heard the above sentiment. Designers of
all disciplines throughout the ages have always graphi-
[39], [48], [53] that brings picturization to various activ-
ities of programming.
Visual Programming researchers [9], [ 111, [ 141, [ 191,
cally sketched before proceeding to symbolic or lan- [41], [45] advocate programming via pictures.
guage-oriented expression of their ideas. The sketches of Pictorial support for activities other than programming
Leonard0 da Vinci and those found in the book Program- are also receiving wide attention [6], [7], [81, [131, [361,
mers at Work [29] are but two modern examples. Dia- [471, [511.
grams help us form clear and “correct” mental images of Even though diagrams are used widely in program-
the structure and function of the design of an artifact. Dia- ming, only a few papers consider the systematic drawing
grams are often easy to understand and convey the es- of them, and address topics such as 1) what makes the
sence of an idea far more quickly than do prose with displays look pleasant or unpleasant, 2) how to draw dia-
mathematical expressions. They transcend the differences grams aesthetically and automatically, 3) how do dia-
among cultures and languages. Accurate and meaningful grams affect our productivity. Traditional fields have de-
drawings of objects are an integral part of training in all veloped standards for their drawings (e.g., [18], [2]).
engineering fields and one finds extensive literature on the Diagrams of data structures are drawn quite variedly, and,
subject (e.g., [18]). more often than not, by hand. Sometimes the pencil-and-
In the context of programming, diagrams appear in var- paper is replaced with mouse-and-screen, and instead of
ious guises, such as data structure diagrams, block dia- actually drawing them we may write other programs (in
grams, histograms, structure charts, and flow charts. languages such as pic [26]) that drive a device to draw
Pedagogy: Programming texts contain numerous line them, but it is essentially a manual process. Manually
drawings that depict the abstraction implemented by a drawn diagrams are problematic [20], [2 11, [27], [341 in
concrete data structure (Fig. 1). These data structure dia- producing, maintaining, communicating, and document-
grams help us concentrate on concepts and quickly ex- ing them which in turn make it practically impossible to
plain key operations. It is a rare book on computer science take full advantage of using pictures in programming.
that does not have any diagrams. Automatic drawing of good looking diagrams is a sur-
prisingly difficult task [6], [50].The difficulty is partially
Manuscript received January 17, 1989; revised October 15, 1989. Rec- caused by the fact that a diagram of a data structure is
ommended by C. G . Davis. The work of C . Ding was supported by the
K. C. Wong Education Foundation of Hong Kong. determined not only by its declaration, but also by its in-
C. Ding is with the Department of Computer Engineering and Science, tended usage. For example, a variable declared as an ar-
Case Western Reserve University, Cleveland, OH 44106. ray may be understood in different ways: as an ordinary
P. Mateti is with the Department of Computer Science and Engineering,
Wright State University Research Center, Kettering, OH 45420. array [Fig. 2(a)], a stack [Fig. 2(b)], a binary tree [Fig.
IEEE Log Number 9034389. 2(c)], a ring [Fig. 2(d)], a hash table [Fig.2(e)], and so

0098-5589/90/0500-0543$01.OO 0 1990 IEEE

544 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 16. NO. 5 . MAY 1990

(cr)
[Reingold and Hansen 19831 [Standish 19831

Y-J
[Standish19831
Fig. 1 . Examples of diagrams.

(d) (e)
Fig. 2. Different applications need the diagrams to be drawn differently.
Fig. 3. Traditional way of drawing is also important in understanding
diagrams.
on. This problem does not disappear with modern pro-
gramming languages supporting abstract data types either those in the graph theory area draw edges as curves or
WI. straight lines, and nodes as circles or ellipses.
Another reason for the difficulty is that aesthetics is a Aesthetic rules exist in drawing diagrams [34], [52]. To
highly subjective matter. People with different education reduce the visual complexity of a diagram, for example,
levels and cultural backgrounds have different aesthetic good diagrams are typically drawn with few edge cross-
tastes. Researchers in VLSI, for example, draw graphs ings and geometrically short paths. People use such rules,
using boxes and straight or angular lines (Fig. 3) while perhaps unconsciously, to guide and simplify the drawing
DING AND MATETI: DRAWING DATA STRUCTURE DIAGRAMS 545

and the process. Finding these rules and coding them will
make it possible to build a system to automatically draw 0
(in most cases) pleasing pictures.
In this paper, we study issues relating to the automation
of the process of drawing data structure diagrams. We
contribute a framework in which different tastes of what
makes a diagram look good, etc. can be discussed. We
formulated some commonly-used rules which are ob-
Fig. 4. Samples of figure elements.
tained by examining diagrams in many textbooks on data
structures, computer programming, and algorithm design.
connecting arc
We also examine the feasibility of implementations based
I
on these rules.

11. TERMINOLOGY
A data structure diagram (DSD) is a pictorial represen-
tation of the underlying data structure. Just as sentences
of a language can be studied at three levels-words, syn-
tax (grammar), and semantics-we can study diagrams at
three corresponding levels: figure elements, figure ob-
jects, and meaningful diagrams. The terminology that we (a) ib)
need to discuss these matters is still evolving. We offer Fig. 5 . The definition of turns: (a) smooth turn: (b) sharp turns
the following as strictly tentative suggestions for the pur-
poses of this paper. figure elements. For example, a hierarchical structure is
represented by a tree or a layered graph, a ring buffer is
A . Figure Elements represented by a ring of boxes, a linked list is represented
AJigure element is a member of a small set of geomet- by a linked list of boxes, etc.
rically defined open and closed curves. Some commonly The intended semantics of a diagram dictates the
used figure elements are shown in Fig. 4.Figure elements “look” of a diagram. The way we draw a pointer, its
correspond to words in languages, but they are two-di- origin, and target objects conveys considerable meaning.
mensional objects. They represent the smallest semanti- The traditional way of drawing is also important. For ex-
cally meaningful elements in a display of data structures. ample, a tree drawn to satisfy certain unusual require-
An arrow, for example, consists of two geometrical enti- ments may look quite different and be hard to recognize
ties: head and tail. It semantically represents a pointer. Its (Fig. 3).
tail (or head) alone does not represent the semantics of a
pointer. Thus, an arrow is a figure element whereas its C. Other Terms
head or tail, by themselves, are not. Conceptually, a fig- By the term “drawing a diagram,” we refer to the pro-
ure element is an abstract object that captures certain at- cess by which the figure elements chosen for the data ele-
tributes of the elements of a diagram. No rigid notions of ment are laid out to visualize the meaning of the data
dimensions, geometrical shapes, color or fill-texture are structure. “Automated drawing” implies that the process
associated with it. Attributes are such things as content, of drawing, sometimes guided by the user, is essentially
label, and descriptions of how the content is to be dis- done by the system. Legalistically speaking, any diagram
played. can be generated automatically if we ignore aesthetics.
But by “automated drawing” in this paper, we always
B. Semantics of a DSD mean automated drawing of nice diagrams, which is an-
While words in a language may mean what we choose other story.
them to mean, diagrams do not have that liberty. They A number of our rules regarding aesthetics deal with
have to corroborate with the real objects they are depict- the way arrows and edges are drawn. A point on a curve
ing through shape resemblance, action simulation, ab- is called a break point if the derivative of the curve is not
stract extension, etc. Traditional values must also be re- continuous at that point. A turn consists of three (possibly
spected. empty) parts: two straight line segments and a connecting
Figure elements indicate semantics. For example, a arc whose tangents at its two ending points are colinear
square or a circle may represent a node, an ellipse a pro- with its two sides. A smooth turn has no break points; an
cedure, an edge a binary relation, an arrow a pointer, etc. angular turn does. The turn angle is defined as 1 a - 01,
Semantics so indicated is achieved through symbolisms. where a and 0 are the angles that the sides of the turn
The semantics of figure elements are affected by so-called make (counterclockwise) with the x-axis (Fig. 5). We use
visual vocabulary [35]. Bertin [5] described six visual vo- the terms angular/smooth edge and arrow analogously.
cabulary: size, direction, texture, form, and color. An- When the sides are missing, we draw tangents at the end
other indication of semantics comes from the layout of points of the connecting arc and use them as the sides.
546 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 16. NO. 5. MAY 1990

(a) (b)
Fig. 6 . A comparison of the recognizability of the same diagram drawn in
different ways.

The origin of an arrow is the far end of its tail, and its
target is the sharp point of its arrow head. Analogously,
we refer to the origin figure element and target figure ele-
ments of an arrow as the figure elements that the arrow
connects. If two figure elements are connected by an (un-
directed) edge, then either can be called origin or target
figure element.

111. WHAT MAKESA DIAGRAMLOOKGOOD?

Webster’s English dictionary defines the word aesthet-
ics as “a branch of philosophy with beauty and the beau-
tiful especially with judgments of taste concerning them. ”

This is a section about the aesthetics of data structure dia-

grams.
The question “What is a good diagram?” is a highly
ulllma
Fig. 7. Comparison of straight and angular lines
subjective one. Different people and different areas have
different answers to it. Also we prefer answers that are
“potentially algorithmic. ” Factors such as visual com- We are able to identify three factors-namely, ambi-
plexity, regularity, symmetry, consistency, modularity, guity, recognizability, and geometrical complexity-that
sizes, shapes, separation, and traditional ways of drawing contribute to the visual complexity of a diagram.
affect our judgment of whether a diagram is good. We I ) Ambiguity: Often a diagram lends itself to misinter-
discuss these terms in greater detail in the subsections be- pretation and ambiguity (Fig. 8).
low. 2) Recognizability is the ease with which the drawn ob-
ject is recognized geometrically and semantically. There
A. Visual Complexity are two recognizing activities corresponding somewhat to
Visual complexity is a negative measure of the ease with microscopic and macroscopic views.
which a diagram is communicated. The lower the visual a) Physical Recognizability: People usually do not
complexity is, the easier the diagram is to understand. have problems in identifying figure elements as long as
Visual complexity is not the same as geometrical com- they are neither “too big” nor “too small.” But improper
plexity. For example, geometrically, Fig. 6(a) is compli- drawings may still make the identifying process difficult.
cated. But since the figure elements in it are well ar- First, the lengths of edges are important for identifying.
ranged, its connections are visually very clear: visually, Generally, the shorter they are (up to a threshold), the
it is simple. But, on the other hand, geometrical com- easier they are to identify. Longer edges increase visual
plexity has heavy impact on the visual one, particularly as well as geometrical complexity. Length becomes un-
on figure elements. The simpler a figure element is, the important if it is short enough so that the entire edge falls
faster it can convey its information and the simpler the into the focus of our eyes. The size of a node could also
diagram will be. Straight lines, for example, are better affect the complexity, but not as much as the lengths of
than curves (Fig. 7). edges. Straight lines are easier to follow than curves be-
DING A N D MATETI: DRAWING DATA STRUCTURE DIAGRAMS 541

l l lil
cally. For example, the structure regularity in G ( V , E )
defined in Fig. 6 can be expressed as:
+
Vi: V(edge ( i , ( i 1 ) mod 12) E E &
edge ( i , ( i - 1 ) mod 12) E E &
edge ( i ,( i + 4 ) mod 12) E E &
edge(i,(i + 5 ) m o d 1 2 ) ~ E &
edge ( i ,( i + 7 ) mod 12) E E &

and its display regularity can be stated as follows. The

n
nodes in V ( G ) = { 1, 2, , n } are positioned equi-
distant on a circle and for i E V an edge is drawn between
every pair of nodes

i, i+ 1 mod 12,
i , i - 1 mod 12,
+
i , i 4 mod 12,
+
i , i 5 mod 12,
(d) +
i , i 7 mod 12,
Fig. 8 . Some examples of high misunderstanding possibility diagrams: (a) i, i+ 8 mod 12
a chain is drawn like a binary tree; (b) the node represented by a box
could be misunderstood as a special node; (c) too closely drawn arrows To visualize what regularity there is, we first need to
could cheat our eyes; (d) two diagrams are drawn together which could
be misunderstood as one diagram. discover it from the underlying data structure. It is usually
very difficult for an algorithm to discover it without being
given some sort of hints. Then we need to find an appro-
cause the origin and destination of a straight line are more priate way to present the regularity. This is achieved by
direct than those of curves (Fig. 7). using regular polygons or drawing the diagram in a sys-
b) Semantic Recognizability is the ease with which the tematic way: to place the nodes evenly along a circle, to
interconnection patterns among figure elements of a dia- draw the (sub)diagram symmetrically, etc. Although this
gram are visually recognized. Semantic recognizability is is not as difficult as the first step, we must be careful since
more important than the physical recognizability. The regularity can be represented in different ways (Fig. 3).
physical recognizability affects the semantic recogniz- A regular diagram is more beautiful when its figure ele-
ability somewhat, but the layout of figure elements affects ments are well-organized than when drawn randomly (Fig.
it the most (Fig. 6). 6 ) . Some diagrams are drawn in such a pleasing way that
3) Geometrical Complexity: The first impression that regularity is present “everywhere.” For example, Fig. 9
a diagram makes is a geometrical one: the simpler it looks, [23], [24] has isosceles triangles: (1, 2, 6 ) , ( 1, 6, 5 ) , (2,
the simpler its components are geometrically, the easier 3, 6 ) , ( 3 , 6, 4), ( 6 , 4, 5); parallelograms: ( 1 , 2, 3, 6 ) ,
it can be understood. Factors affecting the geometrical (1, 2, 4, 5 ) , ( 2 , 6 , 4, 3), ( 3 , 4, 5, 6 ) ; trapezoid: (2, 3,
complexity include the number of edges and nodes, the 4, 5 ) .
lengths of edges, and the sizes of nodes.
C. Symmetry
B. Regularity Symmetry is the correspondence in size, form, shape,
Regularity is an important feature of data structures and and arrangement of figure elements on opposite sides of
their displays. There are two types of regularity: structure a plane, line, or point. It is also a kind of regularity (the
regularity and display regularity. The structure regularity regularity of form or arrangement with corresponding
manifests in the connections of a subset of data ele- parts). Like regularity discussed above, it too conveys in-
ments of a data structure by being expressible in a math- formation more quickly, and makes displays more beau-
ematical way. Each element of this subset is connected to tiful.
others in the subset by the connections defined by an
expression. The display regularity is the visualization of D. Consistency
the structure regularity. Regularity plays a very important Consistency means that all figure objects which have
role in improving the readability of complicated diagrams the same connectivity and semantics and geometrical
because regular interconnections are easy to recognize and structure are drawn in the same way. In Fig. 10, for ex-
remember. For example, it is easy to tell which node is ample, each node consists of figure elements for fields
connected to which in Fig. 6(a) compared to Fig. 6(b). LLink, Info, and RLink and figure elements for pointers
Display regularity requires that figure objects be sys- LLink and RLink. All the figure elements for LLink’s
tematically arranged by certain patterns such that the un- in Fig. 10 have the same meaning (they all are left point-
derlying structure regularity can be formulated geometri- ers) and geometrical structure (they are all drawn as ar-
548 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 16. NO. 5 . MAY 1990

Fig. 9. Good diagrams present regularity everywhere.

-
A XI xz 4
-

rows). It would have been inappropriate to draw the

Llinks and Rlinks inconsistently.
Consistency increases readability. In a diagram which I
contains nodes and edges, if all nodes are represented by
rectangles and edges by lines with the same thickness, I
then when we read this diagram, all rectangles and lines
are understood in the same way. But if a circle is used to
represent one of the nodes or a line with a thicker line to ,i’
represent one of the edges, then we expect them to be
indeed different. Fig. 11. Two perpendicular straight lines are easy to distlnguisHeven when
they intersect.
I
E. Modularity
ber and kind of nodes, regularity, consistence, symmetv,
Modularity in diagrams refers to the construction of
etc.
subdiagrams using some standard pattern or plan, thus re-
ducing the number of linkages that a reader need consider. G. Separations
Modularity can be viewed as the dual of connectivity.
Line separation influences the degree of ease with which
Properties a modular display should have are: 1) figure two lines are differentiated. The larger it is, the easier
elements that are semantically close are positioned close they can be identified. Large separation does not neces-
together; 2) figure elements in different subdiagrams are sarily mean that lines are geometrically separated far away
physically separated. from each other. For example, two perpendicular straight
Two principles are used in modular displays: coupling lines are very easy to distinguish even though they inter-
and cohesion. Coupling is aimed at reducing the number sect (Fig. 11). The portions of the lines that are quite far
and types of interconnections that exist between two sub- from each other do not affect the separation. It is deter-
diagrams so that each subdiagram can be understood rather mined only by those segments which are “close” to each
independently, thus reducing the visual complexity. other. In Fig. 12, the distance between points A and B in
Cohesion is aimed at keeping the relationship among se- (a) and (b) is the same. But points other than A and B are
mantically related figure elements in a single subdiagram. quite far away from each other which tend to make the
The stronger the binding is, the better is our perception separation appear wider, while points other than A and B
of the entire diagram as a single entity. in (b) are closer to each other which make the separation
seem narrower than the one in (a).
F. Sizes
Figure element and object sizes affect the appearance H . Shapes
of a diagram directly. Large figure elements make dia- We prefer to use standard figure elements such as reg-
grams awkward, while tiny ones are hard to read. Also, ular polygons, circles, ellipses, trapezoids, and diamonds
figure element sizes should be kept consistent. The con- unless special figure elements are required. Figure ele-
sistency makes them not only beautiful, but also reduces ment shapes should be kept consistent. Different shapes
the visual complexity. Factors that influence the choice of often have different meanings. For example, diamond
sizes include the size of the entire diagram itself, the num- nodes are usually used to represent decisions and circular
DING A N D MATETI: DRAWING DATA STRUCTURE DIAGRAMS 549

elements should be put symmetrically. Unrelated edges

should be kept separated from each other; related edges
should be kept close together. The number of edge inter-

:I
sections should be minimized. The length of edges should
be minimized. The number of turns should be minimized.

B. Factors
1 ) Thickness of Lines: The range of thicknesses for
lines (of edges, arrow, or node boundaries) is influenced
by many considerations. It is, for example, not reasonable
to choose one inch thick lines for just making a diagram
on 8” X 11” paper, while we may have to use that thick-
ness in making a huge poster. In this sense, line thickness
Fig. 12. Line separation is affected by its surrounding points.
depends on the size of the diagram.
Line thickness is also a function of viewing distance,
the distance between the eyes of the viewer and the dia-
nodes represent rules in AI. If no special meaning is im- gram. In our opinion, viewing distance affects line thick-
plied, it is advisable not to use different shapes for the ness more directly than the diagram size does. No matter
same kind of nodes. how far or close we are to the diagram, the viewing angle
should be kept the same. If we define the area in which
I. Traditional Ways of Drawing objects can be clearly sensed without intentionally mov-
People understand diagrams better when diagrams are ing our eyeballs as the “sensing area,” then we find that
drawn in a familiar way. The familiar ways are affected size of diagram affects the choice of line thickness only
by the traditional ways of drawing. So sticking to the tra- when the diagram is within the sensing area. Within this
ditional ways of drawing will decrease the possibility of sensing area, the smaller the diagram is, the thinner the
being misunderstood (Fig. 3). lines should be. But if the diagram is bigger than the sens-
ing area, then it will only affect line thickness in a mild
IV. AESTHETICOBJECTIVES, FACTORS,AND RULES way.
It is commonly believed that people use certain aes- Line thickness is also affected by its neighbors, more
thetic rules in drawing graphs. They learn these rules by specifically, by the separations of figure elements. This is
experience and use them intuitively. Finding these Ales about as important as the viewing distance. Numerous
and coding them into algorithms is a key step towards the samples [e.g., comparing Fig. 8(a) and 8(b)] suggest that
automated drawing of data structures. We endeavor to the smaller the separations, the thinner the lines should
formulate rules of drawing that yield diagrams perceived be for the sake of both aesthetics and easy recognizability.
as “good” according to the criteria discussed in Section Finally, since the eye cannot distinguish tiny variations
111. Doubtless they need to evolve. As the rules now stand, in line thickness, and for the sake of figure element con-
our rules not only yield pathological cases but conflict sistency, line thickness should be chosen from a small set
often. In Section V, we suggest ways of arriving at ac- of discrete values. On the other hand, we often use thicker
ceptable compromises algorithmically. than normal lines to show emphasis.
These “rules” are divided into three categories: rules, 2) Size and Shape of Arrow Heads: For the same rea-
factors, and objectives. A rule is informally defined as the sons given above, the size of the arrow heads is affected
way in which figure elements are expected to be arranged by the sizes of diagrams, the viewing distance, the sepa-
to meet certain aesthetic requirements. Examples of rules ration of neighboring figure elements, and consistency.
include “no two diagrams should overlap,” or that Also, we find that an arrow head is more pleasing to the
“edges in a tree are drawn as straight lines or arrows.” eye when the ratio of its height (the distance from the tip
A factor describes a numerical range for a certain variable to the base) to the base is close to the golden ratio,
whose value makes a critical difference in the appearance 1.61803. (See [15] for a related discussion.)
of the diagram. For example, two related edges should be 3) Turns: If the distance between two adjacent turns is
neither too far or too close to each other. An objective small and the sides other than the one between the two
describes the goals we would like to achieve such as turn points are long, both turn angles should be as small
“regularity of structure should be apparent,” or that as possible (Fig. 13). The adjacent turn angles should be
“symmetrical figure elements should be positioned sym- about the same (Fig. 14).
metrically.” Objectives do not say how the goals are 4) Separation: Let us first make the notion of separa-
achieved. tion (Section 111-G) precise. The constant CY appears fre-
quently in the factors below. A proper value for it is hard
A. Objectives to pin down, but it is influenced mainly by the distance
Regularity of structure should be apparent. Figure ele- between the eyes and object, and secondarily by the res-
ments should be drawn consistently. Symmetrical figure olution of the display medium, and the nature of the dia-
550

-
I
c
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 16, NO. 5, MAY 1990

(a) (b)
Fig. 13. (a) Large turn angles look bad. (b) Small turn angles look good.

I \
\
Fig. 14. Good: the turn angles are kept the same. (b) Not too bad: turn Fig. 15. The definition of line separation.
angles are slightly different. (c) Bad: turn angles differ too much.

6 ) The box separations in a link list:

gram. A system may permit CY to be changed by users to box-separation(box,, box,) = list-sep Ia * (size
reflect their preferences. of the bigger box).
Given a constant CY, two lines, 1, and I,, and a point p 7) The separation between parallel link lists:
E l , , we define two new lines 1; and 1;. 1; is the longest list-separation ( list,, list,) 2 a * (size of the bigger
segment of l1 containing p such that no point on I ; is far- box).
ther than a from 1,. Similarly, I; is the longest segment of 8) The separation between two diagrams:
l2 such that no point of 15 is farther than a from I , . diagram-separation (diagram,, diagram,) 2 a *
Let a , and b , be the end points of 1; and a, and b2 the (size of the bigger diagram).
ends of 1;. Then the affected area with respect to point p , 9) The level separation in a tree:
a a ( p , l 1 , 12) is defined as the area enclosed by 11, I;, and ,
level-separation (level,, level, + ) 2 CY * (size of the
lines connecting b , , b2 and a l , a2 (Fig. 15). biggest node).
The line separation is now defined as:
C. Rules
figel-sep ( lI, /,)
A rule takes one or more aspects into account and tells
us a good way (as far as these aspects are considered) to
draw the diagram. Unless explicitly credited to other re-
searchers, the rules given in this subsection were formu-
2 lated by us after examining the diagrams in numerous
where a , , a,, b , , and b2 are defined as above with respect textbooks. Because of space considerations, we can only
to point p and lines I, and E2. give a bare minimum of rules and example diagrams to
List-separation (list,, list,) is defined as the smallest support our rules. In a practical system, we expect several
separation between boxes in list, and boxes in list2. thousand rules.
Diagram-separation ( diagram,, diagram,) is defined as I ) Nodes: Nodes of one kind in a diagram should use
the smallest figure element separation between figure ele- the same shape and size. Different kinds of nodes in the
ments in diagram, and figure elements in diagram,. same diagram should use different shapes. Different kinds
The level separation in a tree is defined assuming that of nodes in different diagrams could use the same shape.
all nodes of one level are drawn along a straight line and 2) Edges: Edges of one kind in a diagram should use
lines defining levels are parallel to each other. The dis- the same shape and thickness. Different kinds of edges in
tance between these lines is called level separation. the same diagram should use different shapes and/or
1) separation (edge,, edge,) L a * size(diagram). thicknesses. Different kinds of edges in different diagrams
2) separation(line, box) 1 a * size(box). could use the same shape and thickness.
3) separation(edge, circle) L CY * size(circ1e). a) Drawing Single Edges: Edges must never cross
4) separation(circle,, circle,) L a * (the size of the nodes other than the origin and target ones. Tree or quasi-
bigger circle). tree edges are drawn as straight lines or arrows. Edges in
5 ) separation (box,, box2) = 0 or, rectangular diagrams which are not trees or quasi-trees are
separation(box,, box:) 2 CY *‘(size of the bigger drawn as straight lines o r arrows if the origin and target
box). points are on the same horizontal or vertical line which
DING AND MATETI: DRAWING DATA STRUCTURE DIAGRAMS 55 I

11
- I
W
Fig. 18. 1231

Fig. 16. [24]

(a) (b)
Fig. 19. Drawing multiple edges.
Fig. 17. [43]

6
does not cross other nodes. Otherwise, they are drawn as
orthogonal edges or arrows (Figs. 16 and 17).
Short rectangular edges are drawn as curves (Fig. 10).
Edges in circular diagrams are drawn as straight lines
or arrows if they do not cross or very close to other nodes.
Or otherwise, they are drawn as arcs or curves [Fig. 18
edge (2, 611.
Arrows between adjacent nodes in a double link list are
Fig. 20. [23]
drawn as curve arrows (Fig. 10).
b) Drawing Multiple Edges: If the number of edges
between two nodes is even and the origin and target nodes '
are circles or ellipses, then edges are so drawn that all arc
centers are on the line which is perpendicular and passes
the center of the line connecting the centers of the two
nodes (Fig. 19). If the number is two, one of the edges
I ( Jl
could be drawn as a straight line. The straight edge is Fig. 21. [43]
sometimes used to keep consistency among other
edges(Fig. 20).
If the number of edges is odd and the origin and target
nodes are circles, then one of these edges is drawn as a
straight edge, and the others are drawn as above (Fig. 19).
Two long edges are drawn along the same path (Fig.
21). I

3) Pointers: I

a) Origins: Pointers whose origin nodes are boxes Fig. 22. The definition of the center line
should originate from a point on the center line (Figs. 22
and 16). Pointers whose origin nodes are circles or el-
lipses should originate from the border of the node in such origin node is a diamond usually originate from the dia-
a way that the tangent of the edge, at the point of depar- mond's comer (Fig. 24).
tufe, passes through the center (Fig. 18). Pointers whose b) Destinations: If the target node is a circle or el-
origin nodes are boxes filled with text should originate at lipse, pointers should point to the nearest point on the
the center of the origin side (Fig. 23). Pointers whose circle in such a way that its tangent at the border passes
552 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 16. NO. 5. MAY 1990

Fig. 23. [23]

Fig. 25. Abbreviation of tree branches (231.

Binary tree

Fig. 24. [49]

... ... ... ...
through (one of) the center(s) of the circle or ellipse (Fig.
Fig. 26. Abbreviation of tree levels 1491
18).
If the origin and target nodes are boxes and the centers
of the origin and target sides are on the same horizontal jects from the third in the series could be omitted. We
or vertical line which does not cross any other nodes, then give more specific rules for special data structures.
the pointer should point to the center of theqafget side * 6) Trees: Trees are abbreviated by omitting ’the inter-

(Fig. 16). If the origin and target nodes are boxes and the mediate branches, if there are too many branches (Fig.
centers of the origin and target sides are on the same hor- 25), by omitting the intermediate levels, if there are too
izontal or vertical line which does cross other nodes or if many levels (Fig. 26).
the centers are not on the same horizontal or vertical line, a ) Binary Trees: Nodes at the same level should lie
then i) if the arrow is composed of strictly horizontal and/ on a straight line, and straight lines defining the levels
or vertical lines only then the arrow should point to the should be parallel. A left son should be positioned to the
center of the target side (Fig. 17), ii) if the arrow is left of its father and a right to the right. A father should
curved, then the arrow should point to one of the target be centered over its sons [52], [42]. Levels should be
side ends (Fig. 10). equidistant. Higher levels are drawn below lower levels.
If the target node is a diamond, then the destination b) Ordinary Trees: Nodes at the same level of the
should be one of the diamond comers (Fig. 24). tree should lie along a straight lines, and straight lines
4) Turns: When nodes other than boxes are present, a defining the levels should be parallel. A father should be
90” turn can be replaced by two smaller turns. These two centered over its sons.
turns should be as far as possible, while not getting too c) B-Trees are drawn in the same way as that of or-
close to other figure elements. dinary trees except that arrows originate from beside or
Consecutive turns that are close together should use as between elements in nodes (Fig. 27).
small angles of turn as possible (Fig. 13). d) Quasi-Tree is a diagram containing one or more
5) Repetitive Structures: The following structures are trees as subdiagrams (Fig. 28). A chosen tree subdiagram
called repetitive structures for the obvious reason that their is drawn as an ordinary tree with the rest of edges being
diagrams are composed of repetitions of figure objects drawn curved usually with a different shape or thickness
representing the elements: arrays, trees, stacks, queues, (Fig. 28).
rings, and linked lists. e) Heaps are visualized as binary trees.
Abbreviation of repetitive structures is an important is- 7) Miscellaneous Data Types:
sue. When there is not enough space to put all figure ele- a ) Scalars: Strings, integers, reals, booleans, char-
ments in, or some of the figure elements are not important acters, enumerated types are among the most common
to the user, the structures can be abbreviated by the fol- scalar types. They are “drawn” showing their values,
lowing rules: a) If it is a finite repetition, the figure ob- with or without enclosing boxes (Fig. 29).
jects from the third to the last second one in the repetition b) Records: A record is drawn as a horizontal or ver-
series could be omitted. b) If it is infinite, the figure ob- tical stack of rectangles, each of which corresponds to one
DING A N D MATETI: DRAWING DATA STRUCTURE DIAGRAMS 553

a:3
b: '@
ca: -2
cb: This is a test
internalREC: cc: T R h

Fig. 30. [38]

Fig. 27. B-tree 1491.

- 1 I
(a) (b)
Fig. 3 1. Multidimensional arrays

V . AUTOMATION CONSIDERATIONS
Previous efforts in drawing systems can be categorized
as:
Those that concentrate on building a system to au-
tomatically draw diagrams [17], [37], [381, [lo], [401,
[34]. Due to a lack of an appropriate theory and the dif-
ficulties in drawing nice diagrams automatically, aesthetic
issues were not addressed systematically in these systems.
Those that concentrate on automated drawing of dia-
grams for specific classes of data structures [20], [ 121,
IThis is a test 1 [52], [42], [3]. Efforts were made in both aesthetics and
SlWNG ENUMERAlED PROCEDURE
automation issues, but they are typically restricted to a
Fig. 29. [38] small range of data structures such as binary trees.
Those that concentrate on a particular drawing strat-
egy [46], 141, [30], [ 161. These strategies have the poten-
of its fields. If the field is also a record, then it is recur- tial to be incorporated in the systems (like those listed
sively drawn as a record (Fig. 30). above) to achieve our goals.
c) Arrays: One-dimensional arrays are drawn as a In our framework, rules and factors are explicitly rep-
vertical or horizontal stack of boxes. Two-dimensional ar- resented while objectives are implicit in the way the rules
rays are drawn as arrays of boxes [Fig. 31(a)]. Three- are weighted and applied by the driver (Fig. 32). The da-
dimensional arrays are drawn as arrays of two-dimen- tabase, shown in the dashed box, is the result of combin-
sional arrays [Fig. 31(b)]. Arrays of n dimensions, n > ing the builtin rules and factors, such as those discussed
3, are drawn as linear arrays of ( n - 1 )-dimensions. in the previous section, with those contributed by the user.
d ) Linear Lists are drawn horizontally or vertically, When a data structure is being diagrammed, the work area
with arrows originating from the center line and pointing consists of three parts: 1) a (partially-constructed) repre-
to the center of target side (Fig. 16). sentation of the pictorial view of the data structure, 2) a
e) Doubly Linked Li;ts are drawn horizontally or ver- representation of the abstraction of the data structure con-
tically, with arrows originating from the center line and structed from its memory image, and 3) a subset of the
pointing to the nearest corner of the target box (Fig. 10). data base of rules and factors that the driver deemed rel-
f) Rings are drawn as circles of boxes. evant and cached for the data structure.
g) Stacks are drawn as a one-dimensional array, with
or without an arrow or number indicating the top element. A . Memory Image to Abstractions
h) Queues are drawn either as 1) a one-dimensional In this subsection, we briefly describe a phase of pro-
array, or as 2) a ring. Arrows or numbers indicate the cessing that occurs prior to any attempt at drawing a dia-
head and tail of the queue. gram. Where and how do we get the contents of the data
i) Hash Tables: Chained hash tables are drawn as a structure that we are drawing? The drawing system de-
set of linear lists connected by a head array (Fig. 16). scribed in this paper is intended as a component in de-
Other hash tables are drawn as one-dimensional arrays bugging systems as well as in documentation systems. In
where elements receiving the same hashing addresses are a debugging system, the contents are retrieved from the
connected by arrows [Fig. 2(e)]. address space of the program being debugged.
554 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING. VOL. 16. NO. 5. MAY 1990

struct this geometric representation of the diagram with-

out considering the limitations of display devices. It is
then a simple matter to actually draw a diagram on a phys-
ical medium using an appropriate device driver.
We refer to this data structure as a figure object. It is
stored in the first part of the work area (Fig. 3 2 ) . This
information is accessible to all rules. The goal of the
driver is to finish the construction of this representation.
Figure objects are hierarchically composed. At the bot-
W o k Area tom level, they are sets of related figure elements, which
form a composite (sub)figure. Each figure element de-
Fig. 32. Structure of the drawing system. scribes a primitive such as a rectangle of size w X h , a
circle of radius r , an ellipse of major radius a , minor ra-
dius b , an arrow from (x,,y , ) to (x2,y 2 ) ,etc. At higher
Gathering the memory contents of a data structure is a levels, they are made up of related figure objects. Each
nontrivial process. In the case of variables of primitive figure object has its own x-y coordinate system, within
types, arrays, and records, the contents are typically found which it specifies various attributes of its constituent fig-
in a contiguous block of memory. When pointers are in- ure objects. Some example attributes are the location of
volved, we must collect the contents of all cells (transi- the origin, thickness of lines, etc.
tively) reachable via these pointers. It is also necessary to
tag the contents as to its type whether the data represents C. Representation of Rules
integers, reals, characters, strings, boolean values, etc. A rule has several components. A class is a key word
Unfortunately, declarations in typical languages such used as a basis for clustering the rules into groups. Classes
as Ada, and C are such that we cannot readily deduce that are hierarchical. Its primary use is in reducing search time
a certain data structure is a linked list, a binary tree, etc. as the system begins to draw a diagram subject to the
given only the declarations and the memory image of the rules. An applicability condition is a symbolic boolean
data structure. Even more difficult to deduce are such ab- expression. The rule is applicable only if this condition
stract relationships as the father-son relationships in a evaluates to true. The expression may involve factors,
heap structure, or the element relationship in a hash table. function calls, etc., such as length(edge(x)) >
Also, it is quite common to compose data structures out 20&nintersections( edge (x)) L 3 . An action list is a se-
of several individual variables. Examples of such “con- quence of calls to functions that cause certain actions
nections” include arrays and their indexes, pointers, and (computations) to occur. Free variables list the names and
the pointed objects, etc. We can employ various heuris- types of formal parameters in a rule. There are two further
tics in guessing the abstractions. These tend to be quite components, called weight and badness function, that we
time-consuming, and are impractical in debugging sys- discuss later.
tems, but usable in documentation systems. In debugging It is possible to represent each rule as a procedure in
systems, we expect the user to make additional declara- the implementation language of the system, with compo-
tions to the debugger that certain root pointers point to nents embedded in the procedure. There are two imme-
dynamically linked lists, trees, stacks, etc. The abstrac- diate disadvantages in this scheme. It becomes difficult
tion so obtained, along with the memory image, and type- for the user to add or change rules in the system. It is also
tags, is itself represented as a data structure of the draw- hard to maintain these algorithms, particularly because not
ing system. We refer to this structure as the representation all users will be disciplined enough to avoid burdening
of the abstract value. It is stored in part two of the work these procedures with computations irrelevant to the rules
area (Fig. 3 2 ) . but otherwise useful to the system.
When this drawing system is used as a component in a In our framework, each rule is represented as a data
documentation system, we provide with an editor-like user structure that has a field for each of the components of the
interface to directly construct the representation of the ab- rule. These data structures are then “interpreted” by a
stract value. driver. An example representation of part of Rule 2 is:

B. Abstract Values to Diagrams class = arrow-origin

params = n: node
The subject matter of this paper can now be described applicability = is-box(n)
as “given a representation of an abstract value, construct actions = apply-rule(arrow-box-origin)
a good pictorial view of it.” This pictorial view is rep- weight - ...
resented as a data structure of the drawing system. It con- badness - ...
sists of graphical information such as shapes of figure ele-
ments, the layout of nodes, edges, and arrows, the origin The rule-base is organized as a tree. Each major rule is
and destination points of an arrow, etc. It collects all the represented by a set of subrules based on the applicability
geometrical objects that make up the diagram. We con- conditions. To reduce search time, if a set of rules share
I
DING A N D MATETI: DRAWING DATA STRUCTURE DIAGRAMS

some conditions, a new parent rule is constructed with the

common applicability conditions.

D . Applying the Rules

In applying the rules, we must resolve conflicts, eval-
uate their relative importance, and consider many ways of
combining them. Conflicts arise, for example, in drawing 1

the edge from 1 to 3 of Fig. 33. That edge should not

cross 2 as required by our rules, but the edge length min- (b)
imization objective causes the edge to cross the node. Fig. 33. Rules conflict sometimes.
Conflicts arise because many aesthetic requirements are
not logically consistent and also because each rule ad-
dresses only a few of the aesthetic requirements. We be-
lieve rule conflicts to be inevitable in a system such as
this. To obtain an overall optimal result, in the face of
conflicts, decisions can be made only after having consid-
ered all possible choices. However, the number of pos-
b
sible choices is typically exponential in the number of
nodes or edges in the graph and the number of rules ap-
plicable.
Fig. 34. The definition of badness function for arrow head position.
We propose a schema that uses rule weights, badness
functions, and control variables to solve rule conflicts.
I ) Rule Weights: Each rule, of course, affects the
drawing in its own way, and yet not all of them are equally badness (edge-crossing) = nintersections(edge)
important. For example, “edges should never cross
nodes” has a heavier impact on the result than “the num- where c is the badness factor assigned by the system and
ber of edges intersections should be minimized” does. changeable by the user.
The relative importance of a rule is formalized as its The badness functions need to be combined together to
weight, given as a number. Obviously, weight assignment generate an overall badness functions which meaningfully
is subjective and depends on the assigner’s preference. reflects the appearance of the whole diagram.
2) Badness Functions: A badness function computes a 3) Conflict Resolution: In part one of the work area
figure of merit of the proposed diagram based on its con- (Fig. 32), a data structure representing the graphical lay-
stituents and how they are laid out. (The badness numbers out and structure of the diagram is created. Each node of
of TEX [54] are widely known and experienced.) Discov- this data structure represents one figure element of the
ering appropriate badness functions is an art, and is crit- diagram. In each node is a collection of ways of drawing
ical to the success of the system. The following two ex- the figure element as arrived at by applying different and
amples are illustrative of the issues involved. possibly conflicting rules. If this collection has conflicting
a) Badness of Arrow Destination: Suppose we need information, a merger algorithm is called. This algorithm
to draw an arrow pointing at a box. Assume further that arbitrates among the conflicts and gives a final position
our subjective preferences are as follows. The perfect po- and layout for the figure element attempting to reduce the
sition for the arrow head is the center of the target side. badness of the whole diagram.
The next best position is either end of the side. If none of
E. EJJiciencyIssues
these three positions is possible, then the arrow head
should be positioned as close as possible to these pre- The drawing system described in this paper is intended
as a component in debugging systems as well as docu-

r
ferred points. Based on this observation, a badness func-
tion may look like: menting systems. In a debugging system, diagram draw-
ing is on-line and interactive. Some systems of this kind
0,x + K, ifa Ix Id are [17], [38], [40], [34], [ 2 5 ] . Many diagrams are used
only for the purpose of debugging. The user can only wait
badness(x) =
09 + K~ ifd Ix 5 c
for rather short period of time to compute the diagrams.
09 + K~ i f c Ix 5 e A perfect but very time consuming picture is not desir-
04x + K4 if e Ix 5 b able. In systems such as this, the optimal solution is at-
tempted only if it does not take a long time. Otherwise,
-
where a , b , * * , e are points, Oi are the slopes, and K~ an approximate solution is generated.
are the offsets (Fig. 34). In contrast, in documentation preparation systems, dia-
b) Badness of a Diagram Due to Edge Intersec- grams are no longer the intermediate products and the re-
tions: It is ideal to have no intersections. Otherwise, bad- quirements for the goodness are much higher than those
ness is proportional to the number of intersections. in debuggers. Users now wish the diagram to be drawn as
556 I E E E TRANSACTIONS O N SOFTWARE E N G I N E E R I N G . VOL. 16. NO. 5 , MAY IYYO

perfectly as possible. The computing time, while still not We also formulated how the aesthetic rules and objec-
infinite, is not very limited here. tives can be represented in a system. We are in the process
There are numerous optimization problems in drawing of building a (sub) system based on these ideas.
diagrams such as the minimization of the number of in-
tersections, of the number of turns, of the length of edges,
etc. Most of these optimization problems have exponen- REFERENCES
tial complexity. Since time is a very important factor in A. V. Aho, J. E. Hopcroft, and J . D. Ullman, The Design and Anal-
drawing diagrams, most optimization problems can only ysis of Computer Algorithms. Reading, MA: Addison-Wesley, 1974.
J . Amstein, The International Dictionary of Graphic Symbols. Lon-
be solved approximately. Another strategy is to use mul- don: Century, 1986.
tiple steps in drawings, i.e., the diagram is drawn at dif- M. Augenstein and Y. Langsam, “Graphic displays of data structures
ferent levels of badness depending on the available amount on the IBM PC,” SIGCES Bull., vol. 18, no. I , pp. 73-81. Feb.
1986.
of time. The system tries its best to draw it within the R . I . Becker and S . R. Schach, “Drawing labeled directed binary
specified timespan. If the user is not happy with the re- graphs on a grid,” in Proc. ACM 20th Southeast Regional Conf.,
sult, more’time is then given and the system further re- Knoxville, TN, 1982.
J . Bertin, Semiologie Graphique: Les Diagrammers, Les Reseaux, Les
fines the drawing. Cartes. Paris: Mouton, 1967.
H.-D. Bocker, G. Fisher, and H. Nieper, “The enhancement of un-
F. Customization derstanding through visual representation,” in CHI ’86 Proc., Apr.
1986, pp. 44-50.
Customization is always needed to the diagrams gen- H. D. Boecker and H. Nieper, “Making the invisible visible: Tools
erated by the system. The reasons for the need are nu- for exploratory programming,” in Proc. First Pan Pacijic Computer
Conf., Australian Comput. Soc., Melboune, Australia, Sept. 1985.
merous. Users have their own preference and aesthetic P. R . Bono, “A survey of graphics standards and their role in infor-
tastes. One of the typical examples for customization is mation interchange,” Computer, vol. 18, no. 10, pp. 63-75, Oct.
the orientation of one dimensional arrays. Some users like 1985.
A. Borning, “The programming language aspects of ThingLab. a
them to be drawn vertically, while others horizontally; constraint-oriented simulated laboratory,” ACM Trans. Program.
some applications need them to be drawn vertically, while Lung. Syst., vol. 3 , no. 4,Oct. 1981.
others horizontally. M. H. Brown and R . Sedgewick, “A system for algorithm anima-
tion,’’ ACM Comput. Graphics, vol. 18, no. 3, pp. 177-186, July
We also find that different communities of computer 1984.
science have different preferences. Lispers, for example, S.-K. Chang, Ed., Visual Language. New York: Plenum, 1986.
have their “peculiar” way of drawing [12] lists. Users in M. S. Dionne and A. K. Mackworth, “ANTICS: A system for ani-
mating LISP programs,” Comput. Graphics Image Processing, vol.
programming area and researchers in graph theory area 7, pp. 105-119, 1978.
draw graphs in different ways. A programmer likes to S . Feiner, S. Nagy, and A. van Dam, “An experimental system for
draw nodes as a stack of boxes and have the field names creating and presenting interactive graphical documents,” ACM
Trans. Graphics, vol. 1, no. I , pp. 59-77, 1982.
and values expressed explicitly. But graph theorists prefer W. Finzer and L. Gould, “Programming by rehearsal,” Byte, vol. 9,
drawing nodes as circles or ellipses. VLSI researchers like no. 6, pp. 187-210, June 1984.
using straight lines and view the line intersections more J . Gait, “An aspect of aesthetics in human-computer communica-
tions: Pretty windows,” IEEE Trans. Software Eng., vol. SE-11, no.
seriously than do users in other areas. ..
8. DD. 714-717. Aug. 1985.
5.
I

There are several ways to allow users to have their pref- 1161 E. R., Gansner, S. North, and K . P. Vo, “DAG-A program that
erence: draws directed graphs,” Software-Practice and Experience, vol. 18,
no. 11, ..
PP. 1047-1062, Nov. 1988.
The system allows the user to gather his own rules S . L. Getz, G. Kalligiannis, and S . R . Schach, “A very high-level
into a file, and the system will overwrite the correspond- interactive graphical trace for the Pascal heap,” IEEE Trans. Soft-
ing builtin rules. ware Eng., vol. SE-9, no. 2, pp. 179-185, Mar. 1983.
F. E. Giesecke, Engineering Graphics, 4th ed. New York: Mac-
Rules in the system are modifiable by the user. millan 1987.
Most rules have default values or actions which are E. P. Glinert and S . L. Tanimoto, “Pict: An interactive graphical
changeable by users. programming environment,” Computer, vol. 17, no. 11, pp. 7-25,
Nov. 1984.
G. Hain and K. Hain, “A general purpose automatic flowcharter,”
in Proc. Fourth Annu. Meeting UAIDE, New York, Oct. 1965, pp.
VI. CONCLUSION iv- 1-iv- 12.
Data structure diagrams convey technical information. C. F. Herot et a l . , “An integrated environment for program visual-
ization,” in Automated Tools f o r Information Systems Design, H. J .
While subjective preferences may prevail as to how an Schneider and A. I. Wasserman, Eds. Amsterdam, The Nether-
arrow or an array should be drawn, the overall concern lands: North-Holland, 1982, pp. 237-259.
ought to be the clarity with which this information is com- F. R. A. Hopgood, “Computer animation used as a tool in teaching
computer science,” in Proc. I974 IFIP Congr., Applications vol-
municated. Based on some commonly agreed principles, ume, 1974, pp. 889-892.
we have discussed what factors make a diagram look good E. Horowitz and S . Sahni, Fundamentals of Computer Algorithms.
and convey its information easily and consistently. ’ Woodland Hills, CA: Computer Science Press, 1976.
[24] -, Fundamentals of Data Structures. Woodland Hills, CA: Com-
We divided the aspects that govern the drawing of these puter Science Press, 1976.
figures into rules, factors, and objectives. While there are [25] S . Isoda, T. Shimomura, and Y. Ono, “VIPs: A visual debugger,”
some aspects that apply to all diagrams, most of the rules IEEE Software, pp. 8-19, May 1987.
[26] B. W. Kernighan, “PIC-A language for typesetting graphics,” in
and objectives are specific to the abstraction that a data Proc. of the ACM SIGPLAN SIGOA Symp. Text Manipulation, Port-
structure represents. land, OR, 1981, pp. 92-98.
DING A N D MATETI: DRAWING DATA STRUCTURE DIAGRAMS 557

[27] D. E. Knuth, “Computer drawn flowcharters,” Commun. ACM, vol. [47] B. Schneiderman “Direct manipulation: A step beyond programming
6, no. 9 , pp. 555-563, Sept. 1963. languages,” Computer, vol. 16, no. 8, pp. 57-69, Aug. 1983.
[28] D. Kramlich et a l . , “Program visualization: Graphics support for [48] B. Schneiderman, P. Shafer, R. Simon, and L. Weldon, “Display
software development,” in Proc. 20th Design Automation Conf. , strategies for program browsing,” in Proc. Conf. Sofware Mainte-
1983, pp. 143-149. nance, IEEE Comput. Soc., Washington, DC, 1985.
[291 S . Lammers, Programmers at Work. Microsoft Press, 1986. [49] T. A. Standish, Data Structure Techniques. Reading, MA: Addi-
[30] R. J. Lipton, S . C. North, and J. S . Samdberg, “A method for draw- son-Wesley, 1980.
ing graphics,” in Proc. ACM Symp. Computational Geometry, Bal- [50] D. Thalmann, “An interactive data visualization system,’’ Soft-
timore, MD, 1985, pp. 153-160. ware-Practice and Experience, vol. 14, no. 3, pp. 277-290, Mar.
[31] R. L. London and R. A. Duisberg, “Animating programs using 1984.
Smalltalk,” Computer, vol. 18, no. 8, pp. 61-71, Aug. 1985. [51] E. R. Tufte, The Visual Display of Quantitative Information.
[32] J . Martin, Recommended Diagramming Standards for Analysts and Cheshire, CT: Graphics Press, 1983.
Programmers: A Basis for Automarion. Englewood Cliffs, NI: Pren- [52] C. Wetherell and A. Shannon, “Tidy drawings of trees,” IEEE Trans.
tice-Hall, 1987. Sofware Eng., vol. SE-5, pp. 514-520, 1979.
1331 P. Mateti, Visualization of Abstract Data Types, to be published. [53] E. Yarwood, “Toward program illustration,” Univ. Toronto Com-
[34] P. Mateti and G. M. Radack, “Automated drawing of data structure puter Systems Research Group, Rep. CSRG-84, Oct. 1977.
diagrams,” in Proc. 4th Annu. Nat. Con$ Ada Technology, Mar. [54] D. E. Knuth, The TEXbook. Reading, MA: Addison-Wesley, 1984.
1986, pp. 165-172.
[35] G . F. McCleary, Jr., “An effective graphic vocabulary,” IEEE Com-
put. Graphics Applications, pp. 46-53, Mar./Apr. 1983.
[36] F. S . , Montalvo, “Diagram understanding: Associating symbolic de-
scriptions with images,” in Proc. Second IEEE Workshop Visual Chen Ding received the B.Sc. degree in computer
Languages, Dallas, TX, June 1986. science from the University of Science and Tech-
[37] B. A. Myers, R. Chandhok, and A. Sareen, “Automatic data visu- nology of China, Hefei, Anhui, People’s Repub-
alization for novice Pascal programmers,” in Proc. 1988 IEEE Work- lic of China, in 1984.
shop Visual Languages, Pittsburgh, PA, Oct. 1988, pp. 192-198. He received a fellowship from K. C. Wong Ed-
[38] B. A. Myers, “Incense: A system for displaying data structures,” ucation Foundation, Hong Kong, in 1986 and is
Comput. Graphics, vol. 17, no. 3, pp. 115-125, July 1983. currently completing his Ph.D. dissertation at
[39] W. M. Newman, “A graphical language for display programming,” Case Western Reserve University, Cleveland, OH.
in Proc. Int. Conputer Graphics Symp., Brunel Univ., Uxbridge, En- His research interests include user interfaces, pro-
gland, Aug. 1968. gram visualization, and computer animation.
[40] F. J . Ojeda, “DDS: A subsystem for displaying data structures for
interactive debugging,” M.S. thesis, Dep. Comput. Eng. Sci., Case
Western Reserve Univ., Aug. 1985.
[41] M. C. Pong and N. Ng, “PIGS-A system for programming with
interactive graphical support,” Software-Practice and Experience, Prabhaker Mateti (S’75-M’76) received the
vol. 13, no. 9 , pp. 847-855, Sept. 1983. Bachelor’s degree in electrical engineering from
1421 E. M. Reingold and J. S . Tilford, “Tidier drawings of trees,” IEEE Regional Engineering College at Warangal in
Trans. Software Eng., vol. SE-7, pp. 223-228, 1981. 1969, the M. Tech degree in electrical engineer-
[43] E. M. Reingold and W. J. Hansen, Data Structures. Boston, MA: ing from Indian Institute of Technology at Kanpur
Little Brown, 1983. in 1972, and the Ph.D. degree in computer sci-
[44] S . P. Reiss, “PECAN: Program development systems that support ence from the University of Illinois at Urbana-
multiple views,” IEEE Trans. Sofware Eng., vol. SE-11, no. 3, pp. Champaign in 1976.
276-285, Mar. 1985. He is an Associate Professor of Computer Sci-
[45] -, “Graphical program development with PECAN program devel- ence and Engineering at Wright State University,
opment systems,” in Proc. ACM SIGSOFT/SIGPLAN Software En- Dayton, OH. His research interests include pro-
gineering Symp. Practical Sojiware Development Environments, gramming language design, formal aspects of software engineering, graph
Pittsburgh, PA, Apr. 1984, pp. 30-48. algorithms, and man-machine interaction. His recent work is aimed toward
[46] M. I. Shamos and D. Hoey, “Geometric intersection problems,” in constructing a computer-aided environment for the precision design of soft-
Proc. 17th Annu. Symp. Foundarions of Compurer Science, Houston, ware.
TX, 1976, pp. 208-215. Dr. Mateti is a member of the IEEE Computer Society.