\chapter{Introduction}
\markboth{Introduction}{}

This thesis has two main goals:
\begin{enumerate}
\item the investigation of a new paradigm for picture drawing programs, and
\item the investigation of the use of a program's user's manual as its requirement specification.
\end{enumerate}

\section{A new paradigm for picture drawing programs}
\markright{A new paradigm for picture drawing programs}

\subsection{Motivation and goals}
Line diagrams are widely used in today's computer science technical documents, especially in software engineering documents. They are used through out the whole process of software development, from requirements specification, system design, testing and maintenance. Flow charts, state diagrams, system structure graphs, program call graphs, and object-to-object dependency graphs are some commonly used line diagrams. Therefore, it is important to have some good tools to draw the diagrams. Many researchers are working on picture drawing tools. Each of most of these tools can be classified into one of two categories~\footnote{This dichotomy is used by the customer of \program{WD-pic}, Berry, to motivate the requirements and to provide goals.}:
\begin{itemize}
\item WYSIWYG (What You See Is What You Get) direct manipulation, \eg\ \program{xfig}, \program{Paint}, \program{MacDraw}, and
\item batch, \eg\ \program{pic}~\cite{unixtype2:book, bk:pic, unixtype1:book}, \program{dot}~\cite{eksn:dot}.
\end{itemize}

Shpilberg discusses the advantages and disadvantages of these categories~\cite{fs:wdpic}. The advantages of a WYSIWYG picture-drawing program are as follows:
\begin{itemize}
\item The user can see the whole picture while composing.
\item It is easier for the user to decide the objects' shapes, sizes, positions, \etc\ Therefore, obvious errors can be avoided. 
\end{itemize}

Each of many WYSIWYG picture-drawing programs has the following 
disadvantages:
\begin{itemize}
\item Changing one object in the picture might destroy the whole picture, because the layout of each object in the picture is done manually by the user. For example, if the user changes the size or position of one object, the size or position of the other objects which are connected to the changed one have to be changed as well. 

\item It is not easy to manipulate the objects of a category as a group, \eg\ changing all the boxes in the picture to circles and changing the sizes of all the boxes in the picture.
\end{itemize}

Programs in batch mode, on the other hand, have advantages which are lacking in WYSIWYG mode programs. The advantages of a batch mode program are as follows:
\begin{itemize}
\item Inserting or deleting an object or changing its size or location does not destroy the entire picture. The batch program recalculates the layout of the whole picture and redraws it automatically.

\item It is easy to manipulate objects of a category as a group. For example, if the user wants to change all the boxes in the picture to circles. Since the description of whole picture is stored in a plain text file, the user can search for each ``box'' in the picture and replace it with a  ``circle''. 
\end{itemize}

The disadvantages of a batch mode program are as follows:
\begin{itemize}
\item The user cannot see a picture while composing its description.
\item It is easier for the user to make an error.
\end{itemize}

Our motivation is to develop a picture drawing program that gets the best of both batch and WYSIWYG modes.

The \program{pic} program is a \program{troff}~\cite{bk:troff} preprocessor. It is ideally suited for drawing diagrams in computer science documents. The internal representation of a picture in \program{pic} language is easily understood by a human. Based on these facts, we built \program{WD-pic} on top of the \program{pic} program. Our goal is to keep the \program{pic} program's batch defaults and additionally, make it possible for users to compose pictures through a graphic user interface, \ie\ by mouse clicking or by typing from the keyboard. For example, to draw a picture with a circle in it, the user can use any text  editor to compose a \program{pic} file with ``circle" in it, as with the batch \program{pic} program. Alternatively, in \program
{WD-pic}, the user can either type ``circle'' from the keyboard, or simply click the \wid{circle} button on the palette. Either way, a circle is drawn on \program{WD-pic}'s canvas. What the user sees on the canvas is what the user gets. 

\program{WD-pic} can be run as an independent program on a \program{Unix Solaris} or a \program{Windows 95/98/2000} environment, or as a preprocessor of the \program{pic} program. It draws pictures on its built-in canvas. Its internal representation can be made into a \program{pic} file, and then passed to the \program{pic} program, which outputs to \program{troff}, as illustrated in Figure 1.1. What is printed finally is what was shown on the canvas in \program{WD-pic}.  

The reader should be aware that all the line-drawing figures in this 
thesis were produced by the author using \program{WD-pic}. The produced 
\program{pic} file was then processed, as suggested in Figure 1.1, by \program{pic} and \program{troff} to produce a \program{\sc PostScript} file that is included into the \LaTeX\ source for this thesis.

\begin{figure}
\begin{center}
\scalebox{0.8}[0.8]{\includegraphics{wdpicusage.ps}}
\end{center}
\caption{\program{WD-pic} usage}
\end{figure}

\subsection{Basic design idea}
Like other WYSIWYG picture drawing programs, \program{WD-pic} has a Graphic User Interface (GUI), which provides menus, palette, canvas, and a built-in text editor to users for directly manipulating pictures or textually composing and editing picture descriptions. The canvas provides a  graphical view of the picture, while a textual view of the picture is shown in the editor window. The basic design ideas are as follows:

\begin{enumerate}
\item \program{WD-pic} is made up of a GUI and a \program{pic} interpreter built from the \program{pic} program, which is effectively a \program{pic} compiler, thus obtaining \program{pic} code reuse. They are connected by a bridge. 
\item The GUI consists of standard components, \eg\ menu bar, tool bar, and a palette which contains all the \program{pic} primitive tokens, a canvas for graphical view of the picture and direct manipulations, and a text editor window (EW) for a textual view of the internal representation (IR) of the picture.
\item All the mouse clicking and keyboard typing events from the GUI are classified into two categories:
  \begin{itemize}
  \item affecting the IR, and
  \item affecting the session.
  \end{itemize}
\item After an event of the former kind, the current complete IR is sent to the \program{pic} interpreter.
\item The \program{pic} interpreter builds from the IR a data structure describing each picture element and its size, location, and other attributes.
\item The GUI gets the picture information from the data structures and draws the entire picture on the canvas.
\end{enumerate}

Figure 1.2 illustrates the process of how \program{WD-pic} works.
\begin{figure}
\begin{center}
\scalebox{0.8}[0.8]{\includegraphics{execsteps.ps}}
\end{center}
\caption{Execution steps in \program{WD-pic}}
\end{figure}

Some other design goals of the user interface of \program{WD-pic} are the following:
\begin{itemize} 
\item All styles of input, \ie\ by mouse or by keyboard, are fully interchangeable, without the need to inform the application from where its next input is coming.
\item There is no need to move the mouse to the canvas or the EW except to explicitly and directly identify a point or an object; therefore, the mouse movement is minimized. 
\item The internal representation should be as much as possible what a human would write in the pic language to achieve the picture shown on the canvas.
\item When inputting text that is expected and that has a definite end, there is no need to move the mouse to a text window and to confirm at the end. 
\end{itemize}

  
\subsection{Related work}
Most picture drawing programs come in either WYSIWYG mode or batch mode. Shpilberg discussed a few of each in \cite{fs:wdpic}. A famous diagram visualization system with both WYSIWYG and textual views of the pictures is \program{Graphviz}~\cite{att:gviz, org:gviz}. It was developed by AT\&T research lab. \program{Graphviz} is a set of graph drawing tools, including \program{dot}~\cite{eksn:dot}, \program{neato}~\cite{sn:neato}, \program{lefty}~\cite{ek:lefty}, \program{dotty}~\cite{eksn:dotty}, \etc, which are similar in construction to \program{WD-pic}.

\subsubsection{dot \& pic}
Like \program{pic}, \program{dot} is a batch picture drawing program. It accepts input in the \program{dot} language and makes hierarchical layouts of directed graphs. Undirected graphs are handled by \program{neato}, which shares with \program{dot} the input file format and the graphics drivers. Figure 1.3 is a simple graph generated from the \program{dot} code in Figure 1.5. It has four nodes connected by three edges. Figure 1.4 is a graph generated from the \program{pic} code in Figure 1.6, showing the same layout.

\begin{figure}
\parbox{2.5in}{
\scalebox{0.8}[0.8]{\includegraphics{dotsample.ps}}
\caption{A sample drawn by \program{dot}}
}
\hspace{0.5in}
\parbox{2.6in}{
\scalebox{0.8}[0.8]{\includegraphics{picsample.ps}}
\vspace{0.32in}
\caption{A sample drawn by \program{pic}}
}

\parbox{2.5in}{
\vspace{0.2in}
\code{digraph G \{ \\
a [shape=box]; \\
a} \textendash \textgreater\ \code{b [style=dotted];\\
c [shape=circle];\\
b} \textendash \textgreater\ \code{c [label="event"];\\
d [label="Hello World"];\\
b} \textendash \textgreater\ \code{d;\\
\}
}
\caption{\program{dot} code of Figure 1.3}
}
\hspace{0.5in}
\parbox{3.0in}{
\vspace{0.2in}
\code{down\\
box "a" \\
arrow dotted\\
B:ellipse "b" \\
arrow left down "event" below\\
circle "c" \\
arrow from B.s right down\\
ellipse wid 1 "Hello World"}
\caption{\program{pic} code of Figure 1.4}
}
\end{figure}

We can see the main differences between \program{dot} and \program{pic} from the above sample. In \program{dot}, the user specifies the nodes and their attributes including shape; label, which by default is the node's name; and the edges and their attributes including the source and the target nodes. The sizes and positions of nodes and edges are calculated automatically. The picture drawing orientation by default is from top to bottom. In \program{pic}, nodes and edges are equally treated as objects. The user has to specify the length and path of the line object that connects two node objects. The drawing orientation by default is from left to right. Therefore, \program{dot} is more powerful in drawing complex graphs, \ie\ graphs with lots of nodes. However, it draws directed, acyclic graphs only hierarchically. \program{pic} is more suitable for drawing simple directed or undirected graphs. 

There are some other advantages of \program{dot}. It has color and font attributes and outputs in common graphics languages, \eg\ \program{ps}, \program{gif}, and \program{png}, while \program{pic}, being a \program{troff} pre-processor, does not have these features.  

\subsubsection{lefty}
\program{lefty}~\cite{fh:lan, ek:lefty} is a two-view graphics editor: WYSIWYG view and textual view. The user can edit the picture from any of the views. From the WYSIWYG view, a node can be added or relocated by mouse movement. An equivalent result can be obtained by entering expressions in the editor's language in the textual view. 

A unique feature of \program{lefty} is its use of a single language to describe all aspects of picture handling. A picture description consists of two parts: 
\begin{enumerate}
\item a data structure that holds information about the picture, \ie\ the objects in the picture and their locations and sizes, and 
\item the functions that implement operations on the data structure, \eg\ 
functions to insert, delete, move, and draw objects. 
\end{enumerate}

The \program{lefty} language was inspired by the language in the 
\program{EZ} system~\cite{fh:lan}. It is similar to \program{AWK} and 
\program{C} and is, in this author's opinion, not as easy to read as the 
\program{pic} language.

Another prominent feature of \program{lefty} is its programmability, \ie\ 
a user can program and customize \program{lefty} to the way he or she 
likes by using its programming language. For example, by default, a left 
mouse click on the canvas inserts a new node. The user can change the 
program to cause insertion of  a new node by a middle mouse click.  
However, with only a simple split window for the WYSIWYG view and the text view together with a long pop-up menu, which is invoked by a right mouse click on the canvas, \program{lefty} is not convenient to use. It does not have a menu bar, a tool bar, a palette, \etc\ as do most GUI picture drawing tools.  

\program{lefty}'s ability to communicate with other processes allows it to use existing tools to compute specific picture layouts and allows external processes to use it as a front end to display pictures' data structures graphically.

\subsubsection{dotty}
\program{dotty} is built on top of \program{dot} and \program{lefty}. Like \program{lefty}, it can be customized and controlled by a WYSIWYG interface and a textual interface. \program{dotty} loads the picture file in the \program{dot} language.  \program{lefty} starts up \program{dot} as a separate process to compute layouts. When the user asks for a new layout, \program{lefty} sends the graph to \program{dot}. \program{dot} has very good auto-layout algorithms. So it does the computation, and sends the new layout information, such as coordinates, sizes, \etc, back to \program{lefty}. \program{lefty} then redraws the graph. 

As with \program{lefty}, \program{dotty} is intended to be programmed to 
act as a front end for other applications. It can run also as a 
stand-alone application. However, because \program{dotty} is built on top of \program{dot} and \program{lefty}, \program{dotty}'s features are limited to the features that \program{dot} and \program{lefty} provide. The same as \program{lefty}, it has only a simple window as the canvas and a pop-up menu which can be invoked by a right mouse click on the canvas. This GUI is, in this author's opinion, not as user friendly as \program{WD-pic}'s. However, \program{dotty} uses \program{dot} to do layout. Therefore, \program{dotty} is more suitable for drawing a complex picture with lots of nodes or to be used a font end.

\subsubsection{Rational Rose}
\program{Rational Rose} is a UML-based, model-driven tool, which can 
generate diagrams for object-oriented analysis, modeling, and design~\cite{omg:uml, rational:rose}. Ignoring its analysis and design functions, we discuss only its diagram drawing functions. \program{Rose} has a standard GUI, which contains a menu bar, a tool bar, a browser, a documentation window, and a diagram window, or canvas. \program{Rose} has a limited set of elements for the purpose of design and analysis. The user can generate only class, use-case, state-machine, interaction, component, and deployment diagrams. Working with these diagrams, the user can do move, resize, copy, paste, cut, \etc\ direct manipulations in the diagram window. \program{Rose} does not have a textual view of the diagram. However, it does have a savable, editable internal representation, which is in ASCII form. The documentation window is only for showing and editing information of a selected object. Unlike  most other WYSIWYG picture drawing tools, \program{Rose} has  partial auto layout. For example, in a class or use case diagram, if the user changes the size or location of one node, the edges that are connected to that node are adjusted automatically. Therefore, the layout of the entire picture might be still good. The most prominent feature of \program{Rose} in drawing diagrams is that the diagrams of the same system share elements. Each diagram actually describes the same system in a different view.      

\program{Rose} does a good job in drawing diagrams that it is supposed to draw. It is widely used in designing software systems, but it cannot draw other kind of diagrams.  

\section{Case study of using a user's manual as a requirements specification}
\markright{Case study of using a user's manual as a requirements 
specification}

\subsection{Motivation and goals}
Berry \etal\ discuss the motivation to use user's manual as requirements specification~\cite{berryall:req}. The motivation to do the case study in this work is to find out how well a user's manual works as a requirements specification and how effectively the manual can be used as a reference in each phase of software development. 

For case study of this thesis, Berry, the supervisor, worked as the customer. The author of this thesis was the software engineer. Berry helped the author to make the user's manual of \program{WD-pic} capture his requirements. The author wrote the design document based on the user's manual and implemented the features described in the user's manual. Finally, the user's manual was used as the plan for testing \program{WD-pic}. During the whole process, the manual was kept up to date.
 
\subsection{Related work}

\subsubsection{Previous work of \program{WD-pic}}
Shpilberg, at the Technion, designed and implemented the first prototype of \program{WD-pic} with Berry as her customer~\cite{berryall:req,fs:wdpic}. The prototype established the basic requirements and proved the concept, but the customer was not happy with the final user interface. He was inundated by the profusion of pop-up windows in this prototype. For example, if the user wants to draw a box with a specified size and location. The user has to do the following steps:
\begin{enumerate}
\item Click the \wid{box} button on the palette.
\item Click the \wid{size} button on the palette. The \wid{Size} dialog shows up.
\item Input the size of the box.
\item Click the \wid{OK} button.
\end{enumerate}
Then, the user has to do the similar steps to change the location of the box. 

This causes lots of mouse movement, and the click of the \wid{OK} button to confirm the correctness of inputting text is actually not necessary. It would be much nicer if the user can just click the \wid{box} button and type from the keyboard the size and location of the box without moving the mouse.

The UI problem in Shpilberg's prototype is not fixable, because she used standard widgets to make it easy to change the prototype, a necessity in requirements prototyping. These widgets require bringing up an interaction window when it is desired to input from the key board, and these windows require confirmation of the input. Fixing this problem means rewriting all the UI code.

Note that despite Berry's dissatisfaction with the final user interface, he was happy with the match between the user's manual and the final code. Thus, he was determined to continue to insist on writing a user's manual as the specification of future software products. 

Still later, four students, Daudjee, Dong, A. and T. Nelson, at the University of Waterloo wrote user's manuals for improved versions of \program{WD-pic}. Because of time limits, they did not implement the specified systems.  

The documents of the previous work of \program{WD-pic} were given to the author at the beginning of the project for her to get familiar with the project. She laid these documents aside when she started to design the program. Shpilberg's prototype was developed in \program{X-windows} environment using \program{C}. In the new \program{WD-pic}, the idea of re-use of the \program{pic} compiler is the same. But the author did not reuse any of Shpilberg's code. The new \program{WD-pic} was coded in \program{Java} from scratch. Major improvements and new features added in the new \program{WD-pic} are as the follows:

\begin{itemize}
\item Mouse movements are minimized. Pop-up windows are used only when necessary.
\item A built-in text editor is added.
\item All syntax errors are reported.
\item More direct manipulations are added. The user can now specify an object to be drawn anywhere on the canvas by a mouse-click at the desired point. 
\item The user can preview font settings.
\item Recently opened file history is added.
\item A grid capability is added. The user can define as many grids as he 
or she like. Gravity is supported at three levels.
\item The user can both see and change current values of the \program{pic} variables.
\item A tool bar and a status bar are added. 
\item Preference setting is added.
\item The program can run on \program{Windows} as well as \program{Unix} environments. 
\end{itemize}

The GUI of the new \program{WD-pic} is much more user friendly to the 
customer, who reports that he is happy with the product.

\subsubsection{Development of \program{flo}}
Wolfman designed and developed the program \program{flo} by using user's manual as the requirements document and the omnibus test case~\cite{berryall:req}. \program{flo} is a \program{pic} preprocessor. It translates a flowchart specification that is embedded inside a file containing \program{ditroff} input into a \program{pic} specification. In this project, Wolfman was the software engineer. Berry was the customer. The project was research in electronic publishing and was only incidentally a case study in the use of a user's manual as a requirements specification.

\subsubsection{Industrial case study}
Finestein did a case study of using user's manual as a requirements 
specification in the development of \program{ExpressPath}, an industrial product~\cite{if:IBMcase}. \program{ExpressPath} is a natural language speech recognition system developed by LGS, an IBM company. Finestein participated in the entire requirements analysis and system design. The results of the case study show that it was easier than normal to work with the customer to address potential human-computer interface issues with a user's manual form of requirements specification. The user's manual reduced the learning curve of new developers by at least 50\% over having a traditional SRS. The customer was satisfied with the fact that the requirements processes allowed the customer to detect and readily address human-computer interaction problems that arose during the requirement specification.

\section{Conventions}
\markright{Conventions}

\subsection{Notational conventions}
The following text conventions are used in the thesis:

\begin{itemize}

\item \textrm{Times Roman} is used for normal
text.

\item \textit{Times Italics} is used for emphasis and new
terms in normal text.

\item \textbf{Times Bold} is used for section names.

\item \textsf{Helvetica} is used for program, file, class, module, and method names except in command lines.

\item \textsf{\textit{Helvetica Oblique}} is used
for widget and key name variables.

\item \textsf{\textbf{Helvetica Bold}} is used for
widget and key name constants.

\item \texttt{Courier} is used for internal representation
contents.

\item \texttt{\textit{Courier Oblique}} is used
for variables of \program{pic} internal representation syntax.

\item \texttt{\textbf{Courier Bold}} is used for
constants of \program{pic} internal representation syntax.

\item {\cmss Computer Modern Sans Serif} is used for
command code and use case names.

\end{itemize}

\subsection{Terms}
The following terms are used throughout the thesis. They assume familiarity with \program{pic}.

\begin{itemize}
\item \program{WD-pic} --- the name of the program.

\item user --- the person who uses \program{WD-pic}.

\item \program{pic} primitive --- abbreviate as ``primitive'', defined by the \program{pic} grammar, \eg\ \token{box}, \token{line}, \token{arrow}, \token{circle}, \token{ellipse}, \token{arc}, \token{spline}, and \token{move}. 

\item \program{pic} object --- abbreviate as ``object'', a \program{pic} primitive together with its attributes. 

\item \program{pic} token --- abbreviate as ``token'', a smallest semantically meaningful syntactic unit in the \program{pic} language, \eg\ \token{box}, \token{line}, \token{arrow}, \token{circle}, \token{ellipse}, \token{arc}, \token{spline}, \token{move}, \token{up}, \token{down}, \token{left}, \token{right}, \token{;}, \token{:}, \widquote, and variable identifiers. 


\item attribute --- used to give more information about a primitive, consisting of a keyword, perhaps followed by a value, \eg
\begin{center}
\begin{tabular}{ll}
\token{h(eigh)t} \picvar{expr},		& \token{wid(th)} \picvar{expr}, \\ 
\token{rad(ius)} \picvar{expr},		& \token{diam(eter)} \picvar{expr}, \\
\token{up} \picvar{opt-expr},		& \token{down} \picvar{opt-expr}, \\
\token{right} \picvar{opt-expr},	& \token{left} \picvar{opt-expr}, \\
\token{from} \picvar{position},		& \token{to} \picvar{position}, \\
\token{at} \picvar{position},		& \token{with} \picvar{corner}, \\
\token{by} \picvar{expr},		& \token{then}, \\
\token{dotted} \picvar{opt-expr},	& \token{dashed} \picvar{opt-expr}, \\
\token{chop} \picvar{opt-expr},		& \token{-> <- <->}, \\
\token{invis},				& \token{solid}, \\
\token{fill} \picvar{opt-expr},		& \token{same}, \\
\picvar{text-list},			& \picvar{expr}.
\end{tabular}
\end{center}


In these attributes, the parenthesized text describes an optional full spelling of the containing token.

\item internal representation --- abbreviate as ``IR'', the text file containing the \program{pic} code corresponding to the picture drawn on the canvas.

\item session --- an invocation of \program{WD-pic}.

\item edit window --- abbreviate as ``EW'', the window used to view and edit the IR.

\item external editor --- your preferred text editor, not part of \program{WD-pic}, indicated to your operating system by setting a shell variable, \eg\ \cmmd{setenv EDITOR vi}.

\item canvas --- used for displaying the picture corresponding to the IR.

\item palette --- used for causing input to the IR, made up of the \wid{box}, \wid{circle}, \wid{ellipse}, \wid{line}, \wid{arrow}, \wid{spline}, \wid{arc}, \wid{;}, \widquote, \wid{Constructs}, \wid{Copy}, \wid{Macros}, \wid{Label}, and \wid{Variables} buttons, and an attribute area, whose content changes to provide the attributes for the object that was most recently inserted.   

\item menu bar --- used for operating and adjusting current session, made up of the \wid{File}, \wid{Edit}, \wid{Tools}, and \wid{Help} menus.

\item menu item --- a unit of a menu.

\item tool bar --- shortcuts to some menu items, made up of the \wid{New}, \wid{Open}, \wid{Save}, \wid{Copy}, \wid{Paste}, \wid{Undo}, \wid{Redo}, \wid{Grid}, and \wid{Help} buttons. 

\item screen layout --- made up of a menu bar, a tool bar, a palette, a canvas and an EW, as shown in Figure 2.1.

\item left mouse click --- abbreviate as ``LMC'', a left mouse click.

\item right mouse click --- abbreviate as ``RMC'', a right mouse click.

\item double click --- two LMCs not more than 1 second apart.

\item current insertion point --- abbreviate as ``CIP'', the point in the IR in which the next object will be inserted, indicated by the cursor on the canvas and the cursor in the EW; normally, it is after the last inserted object.

\item the picture corresponding to an IR --- the picture generated by \program{pic} when it interprets the entire IR from start to end, regardless of where in the IR the CIP is.  

\item current file name --- a name for the file into which a \usecase{Save} would cause writing of the entire IR.

\item basic interpretation cycle --- abbreviate as ``BIC'', the process starts with inputting into the IR, and ends with the picture on the canvas being redrawn. For example, following sequenced steps illustrate a BIC:  
\begin{enumerate}
 \item LMC a \program{pic} token on the palette.
 \item The token is added to the IR. 
 \item The picture on the canvas is redrawn.
\end{enumerate}

\item pop-up menu --- a menu that is opened by a RMC on the canvas.  

\item grid --- a network of horizontal and vertical lines that provide 
coordinates for locating points on the canvas; a grid is determined by 
\widvar{Center}, \widvar{dX}, and \widvar{dY} values, where 
\widvar{Center} is the origin; \widvar{dX} is the distance between any two 
adjacent horizontal lines; \widvar{dY} is the distance of any two adjacent 
vertical lines.

\item grid point --- a point in a grid at which a horizontal line and a vertical line cross.

\item gravity --- used to control the restriction of positioning points; it has no effect on the IR.

\item gravity tightness radius --- abbreviate as ``tightness radius'', the radius of the area around a grid point or an object corner around which gravity is effective.

\item approximate point --- the point on the canvas that you LMCed.

\item indicated point --- the point corresponding to an approximate point that is finally indicated by \program{WD-pic} by use of gravity and inserted into the IR.

\item type \picvar{xxx} --- type \picvar{xxx} from the keyboard without concern for the location of the cursor; \picvar{xxx} is added to the IR at the CIP and is shown also in the EW.

\item type \picvar{xxx} into the EW --- make sure the cursor is in the EW; type \picvar{xxx} from the keyboard; \picvar{xxx} is added to the EW at the CIP.

\item type \picvar{xxx} into the external editor --- make sure the cursor is in the external editor, type \picvar{xxx} from the keyboard; \picvar{xxx} is added to the to-be-edited file, which is taken as the IR after you save and quit the external editor. 

\item type \picvar{xxx} into the \widvar{yyy}\ field of \widvar{zzz}\ dialog --- make sure the cursor is in the \widvar{yyy} field of \widvar{zzz} dialog; type \picvar{xxx} from the keyboard; \widvar{xxx} is added to the \widvar{yyy} field of \widvar{zzz} dialog.

\end{itemize}

\subsection{Abbreviations}
\begin{itemize}
\item BIC --- \textbf{B}asic \textbf{I}nterpretation \textbf{C}ycle
\item CIP --- \textbf{C}urrent \textbf{I}nsertion \textbf{P}oint
\item EW --- \textbf{E}dit \textbf{W}indow
\item GUI --- \textbf{G}raphic \textbf{U}ser \textbf{I}nterface
\item IR --- \textbf{I}nternal \textbf{R}epresentation
\item LMC --- \textbf{L}eft \textbf{M}ouse \textbf{C}lick
\item RMC --- \textbf{R}ight \textbf{M}ouse \textbf{C}lick
\item WD --- \textbf{W}YSIWYG \textbf{D}irect-manipulation 
\item WYSIWYG --- \textbf{W}hat \textbf{Y}ou \textbf{S}ee \textbf{I}s \textbf{W}hat \textbf{Y}ou \textbf{G}et
\end{itemize}

\subsection{Organization of this document}
Chapter 2 describes \program{WD-pic}'s requirements, user interface, high-level design, implementation, and evaluation. Chapter 3 gives the details of the case study, the project plan, results and introspection,  and future work. Chapter 4 is a conclusion.   















