|
0
|
1 \input texinfo @c -*-texinfo-*-
|
|
|
2
|
|
|
3 @c %**start of header (This is for running Texinfo on a region.)
|
|
|
4 @setfilename br-design.info
|
|
|
5 @settitle The OO-Browser Design
|
|
|
6 @c %**end of header (This is for running Texinfo on a region.)
|
|
|
7 @synindex vr fn
|
|
|
8
|
|
|
9 @iftex
|
|
|
10 @finalout
|
|
|
11 @end iftex
|
|
|
12
|
|
|
13 @titlepage
|
|
|
14 @sp 4
|
|
|
15 @center @titlefont{Design Issues in the OO-Browser}
|
|
|
16 @sp 5
|
|
|
17 @center Bob Weiner
|
|
|
18 @center Motorola Inc.
|
|
|
19
|
|
|
20 @sp 2
|
|
|
21 @center March 1991 and January 1993
|
|
|
22
|
|
|
23 @end titlepage
|
|
|
24 @page
|
|
|
25
|
|
|
26 @node Top, Design Issues, (dir), (dir)
|
|
|
27 @unnumbered Abstract
|
|
|
28
|
|
|
29 The OO-Browser is an efficient object-oriented class browser. It has a
|
|
|
30 completely direct-manipulation interface with multiple modalities. It
|
|
|
31 may be used for both system exploration and for browsing purposes as
|
|
|
32 part of a professional software development tool chest. It quickly
|
|
|
33 displays and provides views of complicated inheritance trees, making
|
|
|
34 it an important tool for understanding object-oriented systems. It is
|
|
|
35 integrated with a powerful editing environment that can be customized
|
|
|
36 to meet personal work styles.
|
|
|
37
|
|
|
38 The OO-Browser is the first such tool to work with a multiplicity of
|
|
|
39 object-oriented languages. It currently supports five object-oriented
|
|
|
40 languages (Eiffel, C++, Objective-C, CLOS (Lisp), and Smalltalk) and
|
|
|
41 one documentation language (GNU Info). Adding a new language is fairly
|
|
|
42 straightforward and can be done in one to five days.
|
|
|
43
|
|
|
44 This paper has three main parts. The first discusses issues in the design
|
|
|
45 of the OO-Browser, emphasizing its unique aspects. Issues pertinent to
|
|
|
46 all class browsers are touched upon and an explanation is given for how
|
|
|
47 the OO-Browser approaches each of them.
|
|
|
48
|
|
|
49 The second part examines the actual implementation. It concentrates on
|
|
|
50 the user interface aspects and how they empower the user. Novel
|
|
|
51 concepts introduced by the browser are discussed. They include: a
|
|
|
52 merged help/command menu construct, dynamic method location, Environment
|
|
|
53 class groupings, and browsing based on source code only.
|
|
|
54
|
|
|
55 The third part suggests directions for future work.
|
|
|
56
|
|
|
57 @menu
|
|
|
58 * Design Issues::
|
|
|
59 * Design Specifics::
|
|
|
60 * Further Work::
|
|
|
61 * Conclusion::
|
|
|
62
|
|
|
63 --- The Detailed Node Listing ---
|
|
|
64
|
|
|
65 Interactivity
|
|
|
66
|
|
|
67 * Build Speed::
|
|
|
68 * Query Response Time::
|
|
|
69
|
|
|
70 Textual User Interface
|
|
|
71
|
|
|
72 * Environments::
|
|
|
73
|
|
|
74 Direct Manipulation
|
|
|
75
|
|
|
76 * In C++::
|
|
|
77 * In Eiffel::
|
|
|
78
|
|
|
79 Alternate Interfaces
|
|
|
80
|
|
|
81 * Environments::
|
|
|
82
|
|
|
83 Environments
|
|
|
84
|
|
|
85 * Env Create::
|
|
|
86 * Env Build::
|
|
|
87 * Env Load::
|
|
|
88 * Env Save::
|
|
|
89 * Env Update::
|
|
|
90
|
|
|
91 Expand Query Types
|
|
|
92
|
|
|
93 * Dynamic Object Browsing::
|
|
|
94 * Tool Integration::
|
|
|
95 * Graphical Interface::
|
|
|
96 * Version Control::
|
|
|
97 @end menu
|
|
|
98
|
|
|
99 @node Design Issues, Design Specifics, Top, Top
|
|
|
100 @chapter Design Issues in the OO-Browser
|
|
|
101
|
|
|
102 @section Background
|
|
|
103
|
|
|
104 The OO-Browser was initially conceived for utilitarian reasons. A
|
|
|
105 simple, fast class browser was needed for a development project based
|
|
|
106 in the object-oriented language, Eiffel. The browsers available for
|
|
|
107 Eiffel were deemed weak and of not much value.
|
|
|
108
|
|
|
109 Since I had built tools in the past on top of the GNU Emacs
|
|
|
110 environment, I knew that this could be a rapid process, even when a
|
|
|
111 high-level interface was needed. GNU Emacs was also the preferred local
|
|
|
112 editor, so close integration with it was considered a benefit.
|
|
|
113
|
|
|
114 A simple prototype of the browser was completed in two days from
|
|
|
115 conception to implementation. Its user interface was based in part on
|
|
|
116 the Smalltalk-80 class browser under the assumption that this interface
|
|
|
117 had been developed over a long period of time to maximize developer
|
|
|
118 productivity.
|
|
|
119
|
|
|
120 The prototype showed promise as a tool that would be useful for other
|
|
|
121 languages besides Eiffel. I identified C++ and Objective-C as the
|
|
|
122 languages most needy of such a tool. A separate prototype version for
|
|
|
123 each of these languages was done in a single day as a dramatic
|
|
|
124 demonstration of the generality of the concept.
|
|
|
125
|
|
|
126 The road from prototype to a professional tool required a good amount
|
|
2
|
127 of work over an extended period as an independent project. Browser
|
|
0
|
128 performance, structure and features were improved throughout this
|
|
|
129 period. A number of new languages were also added and all of these were
|
|
|
130 integrated via a single common kernel. A complete user manual was
|
|
|
131 written. The shared kernel browser was dubbed the OO-Browser.
|
|
|
132
|
|
|
133 The architecture layered on top of GNU Emacs turned out to be a great
|
|
|
134 success for a number of reasons.
|
|
|
135
|
|
|
136 @itemize @bullet
|
|
|
137
|
|
|
138 @item
|
|
|
139 Both computational and interaction speed of the browser exceeded
|
|
|
140 most people's expectations.
|
|
|
141
|
|
|
142 @item
|
|
|
143 Integration with Emacs meant that when interacting with the browser,
|
|
|
144 people could reuse the editing skills they had acquired from other
|
|
|
145 tasks.
|
|
|
146
|
|
|
147 @item
|
|
|
148 The flexibility of Lisp provided a direct means for implementing
|
|
|
149 the common browser kernel.
|
|
|
150 @end itemize
|
|
|
151
|
|
|
152 @menu
|
|
|
153 * Design Goals::
|
|
|
154 * Interactivity::
|
|
|
155 @end menu
|
|
|
156
|
|
|
157 @node Design Goals, Interactivity, Design Issues, Design Issues
|
|
|
158 @section Design Goals
|
|
|
159
|
|
|
160 The OO-Browser was initially designed in response to the lack of easy to
|
|
|
161 use class browsers in the many emerging object-oriented language
|
|
|
162 environments of today. In fact, many environments still consist of
|
|
|
163 nothing more than a compiler and a debugger. Even those environments
|
|
|
164 that contain browsers, often offer weak ones with barely usable interfaces.
|
|
|
165 The well-known Smalltalk environments [@cite{Goldberg 83}] are the only
|
|
|
166 notable exceptions. Some excellent C++ support environments are now
|
|
|
167 just emerging (Saber-C++, ObjectWorks for C++, Field, ET++).
|
|
|
168
|
|
|
169 The OO-Browser was meant to be small, fast, and easy to use. So far it
|
|
|
170 has met all of those goals. There are three main uses that I see for a
|
|
|
171 class browser:
|
|
|
172
|
|
|
173 @table @strong
|
|
|
174 @item Design Tool
|
|
|
175 A browser should allow for the location of classes
|
|
|
176 that meet a specified set of criteria. It should be just as easy to
|
|
|
177 determine that no such class exists. A more difficult task is to
|
|
|
178 determine similar classes that might be of interest to the user.
|
|
|
179
|
|
|
180 @item Exploration Tool
|
|
|
181 The browser should allow one to explore libraries of classes as well as
|
|
|
182 full programs. It should be especially useful when one is unfamiliar
|
|
|
183 with the set of components that one is browsing.
|
|
|
184
|
|
|
185 @item Engine Interface
|
|
|
186 The browser engine should be usable without the user interface, so that
|
|
|
187 one can use the browser features while editing and so that programs may
|
|
|
188 use the browser capabilities with their own user interfaces.
|
|
|
189 @end table
|
|
|
190
|
|
|
191
|
|
|
192 The quality with which a browser provides the above services can be surveyed by
|
|
|
193 examining a number of issues:
|
|
|
194
|
|
|
195 @table @strong
|
|
|
196 @item Interactivity
|
|
|
197 The browser should preprocess source files quickly.
|
|
|
198 It should also answer queries with minimal delay so that the user
|
|
|
199 maintains a sense of interactivity.
|
|
|
200
|
|
|
201 @item Usability
|
|
|
202 It should be easy to invoke and just as easy to put
|
|
|
203 away, so that it does not distract from other tasks in which the
|
|
|
204 developer is involved.
|
|
|
205
|
|
|
206 @item Consistency
|
|
|
207 A user of the browser should be able to learn a small
|
|
|
208 set of interaction techniques and thereby access a broad set of
|
|
|
209 functions. He should also be able to build on these fundamental
|
|
|
210 concepts to achieve higher levels of proficiency with the tool.
|
|
|
211
|
|
|
212 @item Scalability
|
|
|
213 It should scale up well and maintain its speediness
|
|
|
214 with libraries of thousands of classes.
|
|
|
215
|
|
|
216 @item Integration
|
|
|
217 It should integrate well with a program editing
|
|
|
218 environment, providing language specific features to speed the
|
|
|
219 development process.
|
|
|
220
|
|
|
221 @item Extensibility
|
|
|
222 The browser should be extensible by a competent programmer.
|
|
|
223 @end table
|
|
|
224
|
|
|
225 @noindent
|
|
|
226 Let us discuss separately each of these issues to see how the OO-Browser
|
|
|
227 addresses them.
|
|
|
228
|
|
|
229
|
|
|
230 @node Interactivity, , Design Goals, Design Issues
|
|
|
231 @section Interactivity
|
|
|
232
|
|
|
233 There are two interactivity concerns associated with most class
|
|
|
234 browsers, speed of database construction and query response time.
|
|
|
235
|
|
|
236 @menu
|
|
|
237 * Build Speed::
|
|
|
238 * Query Response Time::
|
|
|
239 @end menu
|
|
|
240
|
|
|
241 @node Build Speed, Query Response Time, Interactivity, Interactivity
|
|
|
242 @subsection Build Speed
|
|
|
243
|
|
|
244 The first concern involves the speed with which the browser can
|
|
|
245 extract any information it needs in building a cache or database of
|
|
|
246 information from the code. If this is a long, involved process, users
|
|
|
247 will want it performed in a batch fashion so that it does not delay
|
|
|
248 their workflow. The rebuilding of databases at night or on idle
|
|
|
249 processors is a common solution. The drawback to this is that it
|
|
|
250 likely precludes the use of the browser for immediate exploration of
|
|
|
251 newly discovered or procured class libraries. If on the other hand,
|
|
|
252 this building process is rapid, the user will be much more likely to
|
|
|
253 experiment with the tool and to use it for exploring new class sets.
|
|
|
254
|
|
|
255 The OO-Browser takes the latter approach. It builds a minimal lookup
|
|
|
256 structure derived directly from class source. It assumes that the
|
|
|
257 classes it scans are syntactically correct and therefore needs parse
|
|
|
258 only a small fraction of the code scanned. This scanner can
|
|
|
259 distinguish between declarations and definitions. It recognizes
|
|
|
260 commented passages and so ignores valid definitions embedded within
|
|
|
261 them.
|
|
|
262
|
|
|
263 The result is that even though this scanning code has not yet been
|
|
|
264 optimized, it can scan hundreds of classes a minute on a single
|
|
|
265 processor machine. This speed is fast enough that when users come
|
|
|
266 upon an unfamiliar class library, they simply ask the browser to scan
|
|
|
267 it and wait for its initial display of the class list found from the
|
|
|
268 scan.
|
|
|
269
|
|
|
270 Still, on some platforms, the lookup structures for very large class
|
|
|
271 libraries may be better built in a batch fashion. The OO-Browser
|
|
|
272 includes a mechanism for doing so via a simple command line invocation
|
|
|
273 which can be scheduled with the UNIX 'cron' utility.
|
|
|
274
|
|
|
275 @node Query Response Time, , Build Speed, Interactivity
|
|
|
276 @subsection Query Response Time
|
|
|
277
|
|
|
278 Most browsing operations represent some form of query. Show the
|
|
|
279 ancestors for this class. List all classes that contain the string,
|
|
|
280 'window'. How many classes are in this library?
|
|
|
281
|
|
|
282 Query responses must therefore be fast enough to give the user a sense
|
|
|
283 of close knit interaction. This is the reason much effort is often
|
|
|
284 put into the database back ends of program support environments.
|
|
|
285
|
|
|
286 The OO-Browser instead uses basic caching techniques to optimize the
|
|
|
287 most common queries. These techniques work surprisingly well, even
|
|
|
288 for environments containing thousands of classes.
|
|
|
289
|
|
|
290 One of the most common queries given to the OO-Browser is to show
|
|
|
291 descendency or ancestry graphs for a set of classes. On a
|
|
|
292 workstation, a graph involving about 500 classes can be computed and
|
|
|
293 displayed in three to four seconds. Smaller queries receive
|
|
|
294 instantaneous replies.
|
|
|
295
|
|
|
296
|
|
|
297 @section Usability
|
|
|
298
|
|
|
299 With the emergence of multi-windowed graphical interfaces in recent
|
|
|
300 years, man-machine interaction has become much more complex. Many
|
|
|
301 environments have been converted to these interfaces in the name of
|
|
|
302 ease of use, but often the user is left with less control than he had
|
|
|
303 before.
|
|
|
304
|
|
|
305 A common example is the window pile problem that results when many
|
|
|
306 applications share a display space and each creates a new window every
|
|
|
307 time a simple action, like setting a parameter value, must be
|
|
|
308 performed. A user often is left to use simple push and pop funtions
|
|
|
309 to wade through the window layers to find one he may want.
|
|
|
310
|
|
|
311 This sort of behavior was considered unacceptable for the OO-Browser.
|
|
|
312 To avoid those situations, the browser performs its own window
|
|
|
313 management. The browser is invoked by a key press or menu selection.
|
|
|
314 It then displays all of its windows. Another key can be used to put
|
|
|
315 the browser away, essentially to hide it from view. All of its
|
|
|
316 windows then disappear. Since the user has not actually quit from the
|
|
|
317 browser, when he invokes it again, his entire context is restored,
|
|
|
318 both visually and computationally. With such an interface, browsing
|
|
|
319 becomes a basic reflex. Invoke browser. Locate desired class for
|
|
|
320 editing. Hide browser, leaving selected class visible. Continue work.
|
|
|
321
|
|
|
322
|
|
|
323 @section Consistency
|
|
|
324
|
|
|
325 Consistency and usability go hand in hand. Techniques of good design
|
|
|
326 dictate that a designer should play upon the skills that his user base
|
|
|
327 brings with them. New interface metaphors should be carefully thought
|
|
|
328 out. Their benefits should be weighed against the cognitive strain
|
|
|
329 that new users will necessarily endure.
|
|
|
330
|
|
|
331 Editing skills, for example, become almost hard-wired into skilled
|
|
|
332 computer users psyches so that little conscious action is needed to
|
|
|
333 perform common tasks. Yet often, each new application offers a
|
|
|
334 different editing model without adding any new editing benefits for the
|
|
|
335 user. This sort of design is especially egregious in a tool-based
|
|
|
336 environment where the designer knows that his users will likely need a
|
|
|
337 variety of tools to do their work.
|
|
|
338
|
|
|
339 The OO-Browser avoids this sin by integrating with the popular GNU
|
|
|
340 Emacs editor. Since Emacs provides a modeless editing environment in
|
|
|
341 which any command may be executed at any time, all normal Emacs
|
|
|
342 editing funtions are available while the user is within the browser's
|
|
|
343 Emacs interface. So, for example, if one already knows how to search
|
|
|
344 an edit buffer for a particular string, one simply does the same thing
|
|
|
345 within the browser.
|
|
|
346
|
|
|
347 Browser key bindings are carefully selected to be both mnemonic and
|
|
|
348 consistent with standard Emacs key usage. In mouse-based
|
|
|
349 environments, direct manipulation techniques are supported, so the
|
|
|
350 user can select the entity he wants to operate on and the command he
|
|
|
351 wants to apply without the need to memorize any key names.
|
|
|
352
|
|
|
353
|
|
|
354 @section Scalability
|
|
|
355
|
|
|
356 The term educational programming environment is too often used to
|
|
|
357 describe tools too weak to be used for real development projects.
|
|
|
358 This is a common syndrome associated with highly interactive tools.
|
|
|
359 They simply don't scale up for use in large, distributed projects.
|
|
|
360
|
|
|
361 @noindent
|
|
|
362 The symptoms of this syndrome in browsing tools include:
|
|
|
363 @enumerate
|
|
|
364 @item
|
|
|
365 the ability to browse code from only one root directory at a time;
|
|
|
366
|
|
|
367 @item
|
|
|
368 support for only one browsing environment under which all classes must
|
|
|
369 be lumped;
|
|
|
370
|
|
|
371 @item
|
|
|
372 slow performance with large class sets;
|
|
|
373
|
|
|
374 @item
|
|
|
375 ability to operate on only one class/category at a time;
|
|
|
376
|
|
|
377 @item
|
|
|
378 no portability of the interface or tool itself.
|
|
|
379 @end enumerate
|
|
|
380
|
|
|
381 The OO-Browser has so far seemed to scale well. It uses the concept
|
|
|
382 of Environments to address symptoms (1) and (2). For each instance of
|
|
|
383 the OO-Browser, the user selects a current Environment which he wants
|
|
|
384 to browse. (Environments are discussed later in this paper.) Each
|
|
|
385 Environment may include source from any number of directories,
|
|
|
386 distributed across machines using file sharing systems like NFS or
|
|
|
387 Apollo's Domain system. Each Environment contains classes written in
|
|
|
388 a single language. The user may select another Environment at any
|
|
|
389 time and thereby switch languages.
|
|
|
390
|
|
|
391 Symptom (3) has been addressed in the previous section on @strong{Query
|
|
|
392 Response Time}.
|
|
|
393
|
|
|
394 Symptom (4) does not exist in the OO-Browser. Virtually all commands
|
|
|
395 that can be applied to a single class may also be applied to any class
|
|
|
396 list returned by a browser query.
|
|
|
397
|
|
|
398 Symptom (5) is not a problem either. The OO-Browser is extremely
|
|
|
399 portable. The browser runs on any UNIX system on which GNU Emacs
|
|
|
400 runs, which is virtually every one. Therefore, a user can run the
|
|
|
401 browser on platforms from any vendor. The graphical interface to the
|
|
|
402 OO-Browser runs under the portable X Window System. It currently uses
|
|
|
403 a Motif-based interface, but may in the future be converted to an even
|
|
|
404 more portable interface toolkit.
|
|
|
405
|
|
|
406
|
|
|
407 @section Integration
|
|
|
408
|
|
|
409 A browsing tool is but one piece of the development environment. It
|
|
|
410 must therefore not only do its job but also support the style of
|
|
|
411 program development followed at a site.
|
|
|
412
|
|
|
413 The OO-Browser supports object-oriented development. Object-oriented
|
|
|
414 development is necessarily incremental and component-based. The browser
|
|
|
415 allows one to edit a class and then incrementally update the browsing
|
|
|
416 environment with any changes. It lets developers think in terms of
|
|
|
417 classes, the building blocks of object-oriented languages, without
|
|
|
418 regard to where the classes are located.
|
|
|
419
|
|
|
420 Each browser language mode is tailored to the specifics of the
|
|
|
421 language. For Eiffel, it supports the location of method definitions
|
|
|
422 that have been repeatedly renamed throughout the inheritance
|
|
|
423 graph. For C++, support for method overloading and multiple
|
|
|
424 inheritance is included.
|
|
|
425
|
|
|
426 Editor integration is critical in a browser, as this is the mainstay
|
|
|
427 tool for program development. Surprisingly, this is not universally
|
|
|
428 understood. Stepstone Corporation's Objective-C browser still does
|
|
|
429 not allow one to edit classes that it displays. Only the newest
|
|
|
430 versions of Interactive Software Engineering's Eiffel browsers allow
|
|
|
431 one to edit classes; one still cannot simply select a class name
|
|
|
432 returned as a result of a query in order to edit it.
|
|
|
433
|
|
|
434 Besides the Emacs interface, the current OO-Browser version allows the
|
|
|
435 use of alternate editors, so that a user need not become familiar with
|
|
|
436 the Emacs editing model if he is not already. It still uses the Emacs
|
|
|
437 lisp engine as a back end to process browser requests, but allows the
|
|
|
438 user to edit classes with whatever program he likes. The graphical
|
|
|
439 interface also supports the use of any desired editor. For non-Emacs
|
|
|
440 users, it is a simple matter to produce a turnkey command that allows
|
|
|
441 use of the browser without any prior knowledge.
|
|
|
442
|
|
|
443
|
|
|
444 @section Extensibility
|
|
|
445
|
|
|
446 The whole open systems phenomenon arose after corporate users tired of
|
|
|
447 relying on vendors to provide proprietary solutions to simple
|
|
|
448 problems. The choice of an open system allows one to seek software
|
|
|
449 solutions and system support from a larger pool of organizations than
|
|
|
450 with closed systems.
|
|
|
451
|
|
|
452 Similar needs are now arising in the programming support arena.
|
|
|
453 Closed systems seldom meet all of the needs of the user base. Without
|
|
|
454 a back end customization language, users are left to the whims of the
|
|
|
455 developer to decide whether a feature is important enough to include.
|
|
|
456 Macro language provisions are too weak to allow all the changes that may be
|
|
|
457 desired, so a full programming language interface is needed for
|
|
|
458 advanced user customization.
|
|
|
459
|
|
|
460 Simple customizations are performed by setting values of attributes
|
|
|
461 included as user variables in the OO-Browser. More advanced
|
|
|
462 customizations, like the addition of a new query type are performed in
|
|
|
463 GNU Emacs Lisp. Most of the OO-Browser is written in the Lisp dialect.
|
|
|
464 It is a fully interpreted language and so is natural to use as a
|
|
|
465 customization language since each change may be immediately tested.
|
|
|
466
|
|
|
467 As noted earlier, an entire language interface can be built in a
|
|
|
468 matter of days, demonstrating both the flexibility of Lisp and of the
|
|
|
469 language interface provided by the OO-Browser.
|
|
|
470
|
|
|
471
|
|
|
472 @node Design Specifics, Further Work, Design Issues, Top
|
|
|
473 @chapter OO-Browser Design Specifics
|
|
|
474
|
|
|
475 @menu
|
|
|
476 * Textual User Interface::
|
|
|
477 * Graphical Tree Display::
|
|
|
478 * Direct Manipulation::
|
|
|
479 * Alternate Interfaces::
|
|
|
480 * Environments::
|
|
|
481 @end menu
|
|
|
482
|
|
|
483 @node Textual User Interface, Graphical Tree Display, Design Specifics, Design Specifics
|
|
|
484 @section Textual User Interface
|
|
|
485
|
|
|
486 The screen shot on the following page highlights the major components
|
|
|
487 of the OO-Browser textual user interface. The windows across the top of the
|
|
|
488 OO-Browser screen are called @dfn{class listing windows}; they display
|
|
|
489 @dfn{class listing buffers} with a single class name per line. The
|
|
|
490 @dfn{class viewer window}, sometimes simply referred to as the
|
|
|
491 @dfn{viewer window}, fills the bottom half of the screen. It is used
|
|
|
492 to display class source and summary information. Pictured here in the
|
|
|
493 viewer window is the command help/menu buffer, summarizing the browser's
|
|
|
494 command key bindings.
|
|
|
495
|
|
|
496 The number of listing windows is limited only by the screen width. The
|
|
|
497 width of the windows may be interactively adjusted to permit more or
|
|
|
498 fewer windows for particular tasks. CLOS identifiers are typically much
|
|
|
499 longer than Eiffel identifiers, so one would want to raise the window
|
|
|
500 width when operating on CLOS classes.
|
|
|
501
|
|
|
502 @menu
|
|
|
503 * Hierarchy Listings::
|
|
|
504 @end menu
|
|
|
505
|
|
|
506 @node Hierarchy Listings, , Textual User Interface, Textual User Interface
|
|
|
507 @subsection Hierarchy Listings
|
|
|
508
|
|
|
509 The directed, acyclic graph relations prevalent in languages with
|
|
|
510 multiple inheritance are translated into textual hierarchies by repeating
|
|
|
511 elements with multiple parents throughout the tree structure. So if
|
|
|
512 class B inherits from C and class C inherits from P1, P2 and P3. One
|
|
|
513 view of descendants would show:
|
|
|
514
|
|
|
515 @example
|
|
|
516 P1
|
|
|
517 C
|
|
|
518 B
|
|
|
519 P2
|
|
|
520 C ...
|
|
|
521 P3
|
|
|
522 C ...
|
|
|
523 @end example
|
|
|
524
|
|
|
525 The ellipses indicate that C's subtree has been expanded somewhere
|
|
|
526 above, so it is not repeated. The resultant structure is easy to
|
|
|
527 understand and very useful. This sort of structure allows one to use
|
|
|
528 the browser on a text-only terminal and still be able to visualize
|
|
|
529 significant inheritance relations.
|
|
|
530
|
|
|
531 @noindent
|
|
|
532 Queries that may be made under this interface include:
|
|
|
533 @itemize @bullet
|
|
|
534 @item
|
|
|
535 show parents
|
|
|
536 @item
|
|
|
537 show children
|
|
|
538 @item
|
|
|
539 show ancestors
|
|
|
540 @item
|
|
|
541 show descendants
|
|
|
542 @item
|
|
|
543 total selected classes
|
|
|
544 @item
|
|
|
545 select classes matching regular expression or string.
|
|
|
546 @end itemize
|
|
|
547
|
|
|
548 @noindent
|
|
|
549 All of these commands may be applied to any grouping of classes,
|
|
|
550 eliminating the sequential bottleneck found in many other such tools.
|
|
|
551
|
|
|
552 All displays that move up the inheritance tree consume a listing window
|
|
|
553 to the left of the current one. Descendancy displays do the opposite
|
|
|
554 and select the window to the right. At the edges of the display, the
|
|
|
555 window selected wraps around to the other side. An exit command
|
|
|
556 clears the current listing buffer and returns to the last one,
|
|
|
557 regardless of how the user walks up and down the trees. Ancestor
|
|
|
558 listings may be shown with parent down to root (highest level ancestor)
|
|
|
559 or inverted, with root down to parent, so that children are always
|
|
|
560 displayed below their parents.
|
|
|
561
|
|
|
562 The class matching command is fast and easy to use.
|
|
|
563
|
|
|
564
|
|
|
565 @noindent
|
|
|
566 Besides queries, a few of the useful commands provided are:
|
|
|
567 @itemize @bullet
|
|
|
568 @item
|
|
|
569 sort classes
|
|
|
570 @item
|
|
|
571 view class source
|
|
|
572 @item
|
|
|
573 edit class source
|
|
|
574 @item
|
|
|
575 save class listing.
|
|
|
576 @end itemize
|
|
|
577
|
|
|
578 The editor is user selectable. The ability to sort any class listing
|
|
|
579 simplifies class location. The @emph{save class listing} command is
|
|
|
580 useful to record the output of interesting queries for documentation and
|
|
|
581 reference purposes.
|
|
|
582
|
|
|
583 All browser queries and commands work with class source code only. This
|
|
|
584 makes the tool useful in exploratory situations where a compiler is not
|
|
|
585 available. It also ensures that the browser receives up to date
|
|
|
586 information from which to work.
|
|
|
587
|
|
|
588
|
|
|
589 @node Graphical Tree Display, Direct Manipulation, Textual User Interface, Design Specifics
|
|
|
590 @section Graphical Tree Display
|
|
|
591
|
|
|
592 The graphical interface to the browser provides a compact tree-based
|
|
|
593 view of a set of classes or an Info manual. (A sample enlarged display
|
|
|
594 is shown on the following page. It uses the same set of classes as the
|
|
|
595 prior picture of the textual display, for ease of comparison.) This
|
|
|
596 interface supplements the textual interface so that the user can easily
|
|
|
597 comprehend large inheritance structures. (Nodes with more than one
|
|
|
598 incoming pointer (parent) are repeated throughout the tree, but their
|
|
|
599 subtrees are excised and replaced with the ellipses symbol, ..., just as
|
|
|
600 in the textual interface. Subtrees may be collapsed or expanded
|
|
|
601 interactively. Scrolling mechanisms are limited to horizontal and
|
|
|
602 vertical scroll bars, but a panning construct is being considered.
|
|
|
603
|
|
|
604 When the user finds a class he is interested in, he simply selects it
|
|
|
605 with the same mouse button he uses to select classes in the textual
|
|
|
606 interface. The node is highlighted and the associated class is
|
|
|
607 displayed in the text editor.
|
|
|
608
|
|
|
609 The graphical interface can be invoked on any portion of the current
|
|
|
610 browser Environment. One may for instance, obtain a list of classes
|
|
|
611 with 'Stack' in their name and then through a mouse click, invoke the
|
|
|
612 graphical browser on just the descendancy trees of the selected classes.
|
|
|
613
|
|
|
614 Any number of graphical browser views may be shown at the same time.
|
|
|
615 Each view is independent, so each may provide a view of any environment
|
|
|
616 previously created by the OO-Browser. All views can communicate with a
|
|
|
617 single instance of the editor, so that one can maintain onscreen views
|
|
|
618 of multiple environments, even across languages, and simply select any
|
|
|
619 node from any view to access the corresponding source.
|
|
|
620
|
|
|
621 A new, window-system independent version of the graphical interface
|
|
|
622 provides double buffered display updates for smooth scrolling, a panner
|
|
|
623 device for rapid movement throughout a view, and a number of useful tree
|
|
|
624 display representation alternatives.
|
|
|
625
|
|
|
626 The graphical interface is presently somewhat limited, but that is only
|
|
|
627 because it is so new. It is a straightforward matter to provide a user
|
|
|
628 of the graphical interface with the full complement of browser commands
|
|
|
629 by adding the commands to a set of menus and sending each command to the
|
|
|
630 browser engine as it is selected.
|
|
|
631
|
|
|
632
|
|
|
633 @node Direct Manipulation, Alternate Interfaces, Graphical Tree Display, Design Specifics
|
|
|
634 @section Direct Manipulation
|
|
|
635
|
|
|
636 To maximize the utility of the displays presented to the user, most
|
|
|
637 displayed entities may be operated upon through simple mouse clicks.
|
|
|
638 For example, clicking on a class name displays the associated class
|
|
|
639 definition. Clicking to the left of a class displays its ancestors and
|
|
|
640 to the right its descendants. Selection of the ellipses after a class
|
|
|
641 name shifts the display focus to the class' descendants list.
|
|
|
642
|
|
|
643 A click in an empty listing buffer may display the browser help text or
|
|
|
644 a menu of language-specific source files which the user has browsed.
|
|
|
645 This menu permits random access selection of any class file.
|
|
|
646
|
|
|
647 A click on any of the command descriptions in the help display executes
|
|
|
648 the associated command on the previously selected item. This is such a
|
|
|
649 useful, intuitive means of control that it is surprising that one never
|
|
|
650 sees this capability in application interfaces.
|
|
|
651
|
|
|
652
|
|
|
653
|
|
|
654 @menu
|
|
|
655 * In C++::
|
|
|
656 * In Eiffel::
|
|
|
657 @end menu
|
|
|
658
|
|
|
659 @node In C++, In Eiffel, Direct Manipulation, Direct Manipulation
|
|
|
660 @subsection In C++
|
|
|
661
|
|
|
662 @cindex C++
|
|
|
663 Entities in C++ programs may be selected for inspection with the middle
|
|
|
664 mouse button. Most importantly, once a class header file is displayed,
|
|
|
665 one simply clicks on a method declaration to see its corresponding
|
|
|
666 definition. Each feature declaration should be given separately to
|
|
|
667 ensure accurate parsing. If the method is inherited from another class,
|
|
|
668 a message at the bottom of the screen describes which class the method
|
|
|
669 is defined in once the browser displays the method definition.
|
|
|
670
|
|
|
671 The browser dynamically handles full function overloading and numerous
|
|
|
672 other complex mappings between declaration and definition that are
|
|
|
673 permitted in C++. A complex set of pattern matching heuristics are used
|
|
|
674 which work in almost all cases. This is a novel approach that speeds
|
|
|
675 the construction of Environments, since no normalization is performed on
|
|
|
676 function signatures until they are operated upon. All other browsers
|
|
|
677 rely on preprocessing techniques which store a normalized form of the
|
|
|
678 declaration to match against the definition signature.
|
|
|
679
|
|
|
680 Parent classes may be browsed in a similar manner by clicking on their
|
|
|
681 names in an inheritance or declaration clause. Multiple inheritance is
|
|
|
682 fully supported. There is no support as yet for locally scoped classes.
|
|
|
683
|
|
|
684 Include files may be browsed by selecting their inclusion declarations
|
|
|
685 (@strong{#include} ...).
|
|
|
686
|
|
|
687
|
|
|
688
|
|
|
689 @node In Eiffel, , In C++, Direct Manipulation
|
|
|
690 @subsection In Eiffel
|
|
|
691 @cindex Eiffel
|
|
|
692 Selection of a feature name in an export clause displays the feature
|
|
|
693 definition, even if it is renamed several times within ancestors.
|
|
|
694 Parent classes may be browsed in a similar manner by clicking on their
|
|
|
695 names in an inheritance or declaration clause.
|
|
|
696
|
|
|
697 The following example of locating a renamed feature is taken from an
|
|
|
698 actual set of Eiffel library classes:
|
|
|
699
|
|
|
700 @example
|
|
|
701 User selects feature @emph{subwindow} of @emph{POPUP_MENU}
|
|
|
702 inherited from @emph{WINDOW}
|
|
|
703 which renames @emph{child} as @emph{subwindow}
|
|
|
704 inherited from @emph{TWO_WAY_TREE}
|
|
|
705 which renames @emph{active} as @emph{child}
|
|
|
706 inherited from @emph{TWO_WAY_LIST}
|
|
|
707 inherited from @emph{LINKED_LIST}
|
|
|
708 which defines @emph{active}.
|
|
|
709 @end example
|
|
|
710
|
|
|
711 The browser would display the feature @emph{active} and explain to the
|
|
|
712 user that feature @emph{subwindow} of class @emph{POPUP_MENU} is
|
|
|
713 inherited from feature @emph{active} of class @emph{LINKED_LIST}.
|
|
|
714 Location of this sort of feature definition would be incredibly tedious
|
|
|
715 without programmatic support.
|
|
|
716
|
|
|
717 If a feature reference is selected within a non-deferred (non-abstract)
|
|
|
718 class, then deferred features are automatically ignored when searching
|
|
|
719 for the feature definition. If the reference class is deferred
|
|
|
720 (abstract), the first matching ancestral feature found is selected,
|
|
|
721 whether it is deferred or not.
|
|
|
722
|
|
|
723 The algorithm used to locate features is dynamic, so if another class
|
|
|
724 is inserted into the inheritance structure given above, the feature
|
|
|
725 definition still will be located properly.
|
|
|
726
|
|
|
727
|
|
|
728
|
|
|
729 @node Alternate Interfaces, Environments, Direct Manipulation, Design Specifics
|
|
|
730 @section Alternate Interfaces
|
|
|
731
|
|
|
732 Earlier we mentioned that the computational back end, the @dfn{engine}
|
|
|
733 part of the browser should be available for use without its interface.
|
|
|
734 The interactive nature of Lisp allows the prototyping and delivery of
|
|
|
735 different interfaces quickly. For example, the graphical interface to
|
|
|
736 the browser was originally a standalone tree drawing program. A
|
|
|
737 prototype interface to the browser was developed in a matter of two
|
|
|
738 hours, with most of the time spent examining the unfamiliar code in the
|
|
|
739 tree drawing program.
|
|
|
740
|
|
|
741 @noindent
|
|
|
742 Other simple but extremely useful interfaces we have provided include:
|
|
|
743 @itemize @bullet
|
|
|
744 @item
|
|
|
745 the ability to perform completion on type identifiers when programming;
|
|
|
746
|
|
|
747 @item
|
|
|
748 support for compiler error parsing when the compiler outputs only the
|
|
|
749 class name and line number of the error;
|
|
|
750
|
|
|
751 @item
|
|
|
752 a command that prompts for a class name and then edits the class,
|
|
|
753 with class name completion included.
|
|
|
754 @end itemize
|
|
|
755
|
|
|
756 @noindent
|
|
|
757 All of these were straightforward to implement based upon the browser
|
|
|
758 engine functions.
|
|
|
759
|
|
|
760 @menu
|
|
|
761 * Environments::
|
|
|
762 @end menu
|
|
|
763
|
|
|
764 @node Environments, , Alternate Interfaces, Design Specifics
|
|
|
765 @section Environments
|
|
|
766
|
|
|
767 @cindex Environment, the
|
|
|
768 @cindex Library search list
|
|
|
769 @cindex System search list
|
|
|
770 Whenever the OO-Browser is in use, an Environment is selected. An
|
|
|
771 Environment may be built or simply specified. An @dfn{Environment
|
|
|
772 specification} tells the browser what to include in the construction of
|
|
|
773 an Environment. (@xref{Env Create, , Creating Envir Specs}, for more
|
|
|
774 info.) An OO-Browser @dfn{Environment} includes a set of inter-class
|
|
|
775 relationships together with a few browser settings. The phrase,
|
|
|
776 @dfn{the Environment}, refers to the current OO-Browser Environment.
|
|
|
777 Many browser commands depend on information in the Environment. A
|
|
|
778 summary of the components of the Environment may be displayed any time
|
|
|
779 during browser use. See the next page.@refill
|
|
|
780
|
|
|
781 The set of classes included in an Environment is specified by two lists
|
|
|
782 of directories, below which all of the Environment's class source files
|
|
|
783 are to be found. (The OO-Browser will automatically search
|
|
|
784 sub-directories below the directories specified.) The first list of
|
|
|
785 directories is called the @dfn{Library search list}; it defines the
|
|
|
786 locations of stable, typically reusable classes that have been released
|
|
|
787 for general use. The second list is called the @dfn{System search
|
|
|
788 list}; it defines the locations of unreleased classes being developed,
|
|
|
789 often for a particular system. All class names within a single
|
|
|
790 Environment must be unique to ensure proper operation of the browser.
|
|
|
791 This also implies that the Library and System class sets be disjoint.
|
|
|
792
|
|
|
793 The OO-Browser lets one create, update and save Environments. Once an
|
|
|
794 Environment file has been created, it may be loaded at any time. The
|
|
|
795 browser will then use this Environment for all of its operations until
|
|
|
796 another one is loaded.
|
|
|
797
|
|
|
798 The browser maintains a separate Environment for each programming
|
|
|
799 language on which it is used. Thus, if one switches from Eiffel to
|
|
|
800 C++ browsing and then back to Eiffel browsing, the Eiffel environment
|
|
|
801 will not need to be reloaded; it will appear immediately and the
|
|
|
802 screen will appear as if the Eiffel OO-Browser were invoked for the
|
|
|
803 first time. Only one Environment per language is kept in memory.
|
|
|
804
|
|
|
805 @cindex Environment, default
|
|
|
806 There is a default Environment file name for each browser-supported
|
|
|
807 language; these names are unique to each user account on the system:
|
|
|
808 @file{~/.br-eif-env}, @file{~/.br-c++-env}, @file{~/.br-objc-env},
|
|
|
809 @file{~/.br-clos-env}, @file{~/.br-smt-env}, and @file{~/.br-info-env}.
|
|
|
810 Environment files are automatically created and loaded by the OO-Browser
|
|
|
811 so that one need never become familiar with their format.@refill
|
|
|
812
|
|
|
813 Environments provide a simple, uniform way of managing numerous class
|
|
|
814 libraries. A simple extension to the browser is planned which will
|
|
|
815 allow one to interactively select Environments as one typically does
|
|
|
816 with files. Each Environment stores an indication of what language its
|
|
|
817 classes are in, so it can dictate which browser version to invoke.
|
|
|
818
|
|
|
819
|
|
|
820 @menu
|
|
|
821 * Env Create::
|
|
|
822 * Env Build::
|
|
|
823 * Env Load::
|
|
|
824 * Env Save::
|
|
|
825 * Env Update::
|
|
|
826 @end menu
|
|
|
827
|
|
|
828 @node Env Create, Env Build, Environments, Environments
|
|
|
829 @c node-name, next, previous, up
|
|
|
830 @subsection Creating Environment Specifications
|
|
|
831
|
|
|
832 @cindex Environment specification
|
|
|
833 Environment specifications are useful when one wants to describe a
|
|
|
834 number of Environments to the OO-Browser but wants to defer their
|
|
|
835 construction until later. Large environments then can be built
|
|
|
836 overnight. @xref{Env Build, , Building Environments}, for more
|
|
|
837 info.@refill
|
|
|
838
|
|
|
839 @findex br-env-create
|
|
|
840 @cindex initialization file
|
|
|
841 Every Environment must be specified before it can be built or used.
|
|
|
842 Thus, specifying an Environment is the first step in creating it.
|
|
|
843 An Environment create command interactively prompts for all information
|
|
|
844 necessary to specify and to build an Environment. This command may
|
|
|
845 be invoked repeatedly to quickly specify a number of different
|
|
|
846 Environments.@refill
|
|
|
847
|
|
|
848 @noindent
|
|
|
849 Here are the Environment specification components for which the
|
|
|
850 OO-Browser prompts:
|
|
|
851 @table @code
|
|
|
852 @item System search directories
|
|
|
853 List of directories below which other System directories containing
|
|
|
854 class source code and directories of class source files may be found.
|
|
|
855
|
|
|
856 @item Library search directories
|
|
|
857 List of directories below which Library files of class source code
|
|
|
858 and directories of class source files may be found.
|
|
|
859
|
|
|
860 @item Save all Environment lookup tables?
|
|
|
861 @emph{Yes} means that a complete set of lookup tables should be saved as
|
|
|
862 a class Environment. @emph{No} means that some lookup tables should be
|
|
|
863 built from others when the tables are loaded from an Environment file.
|
|
|
864 Answering @emph{yes} doubles the size of each Environment file but
|
|
|
865 slightly speeds the loading of an Environment into the browser.
|
|
|
866 @emph{No} is the default that works best on most computers.
|
|
|
867 @end table
|
|
|
868
|
|
|
869
|
|
|
870 @node Env Build, Env Load, Env Create, Environments
|
|
|
871 @c node-name, next, previous, up
|
|
|
872 @subsection Building Environments
|
|
|
873
|
|
|
874 @cindex Environment building
|
|
|
875 An Environment specification tells the OO-Browser what to include in the
|
|
|
876 Environment, but the Environment still must be built before use. When
|
|
|
877 class names or locations have changed or the Environment's inheritance
|
|
|
878 structure is modified, the Environment must be rebuilt. For small
|
|
|
879 Environment changes, one may use the class addition and deletion
|
|
|
880 features of the browser. @xref{Env Update, , Updating Environments},
|
|
|
881 for more info.@refill
|
|
|
882
|
|
|
883 @cindex Environment building, batch
|
|
|
884 @cindex large Environments
|
|
|
885 Very large Environments may be built overnight by invoking Emacs in
|
|
|
886 batch mode at a scheduled time. Note that the Environment specification
|
|
|
887 file must have been created prior to execution of this command so that
|
|
|
888 the browser knows what to build.
|
|
|
889
|
|
|
890 @node Env Load, Env Save, Env Build, Environments
|
|
|
891 @c node-name, next, previous, up
|
|
|
892 @subsection Loading Environments
|
|
|
893
|
|
|
894 @cindex Environment loading
|
|
|
895 A new Environment may be loaded for use at any time within the
|
|
|
896 OO-Browser. One may either select the load Environment command from
|
|
|
897 the on screen OO-Browser command summary or simply use the
|
|
|
898 language-specific browser invocation command that was originally used to
|
|
|
899 start the browser, except in this case, it should be preceded by a
|
|
|
900 prefix argument. For example, the @code{(eif-browse)} command, would
|
|
|
901 prompt for and then load a new Eiffel environment, even when one is
|
|
|
902 already browsing an Eiffel environment.
|
|
|
903
|
|
|
904
|
|
|
905 @node Env Save, Env Update, Env Load, Environments
|
|
|
906 @c node-name, next, previous, up
|
|
|
907 @subsection Permanently Storing Environments
|
|
|
908
|
|
|
909 The OO-Browser automatically builds and saves Environments in most
|
|
|
910 cases. Occasionally one may find a need to force the Environment to
|
|
|
911 be saved to a file, as in the case when one wants to save an Environment
|
|
|
912 under a different file name.
|
|
|
913
|
|
|
914 The Environment save command is used to force an Environment save to
|
|
|
915 occur. The command prompts for a file to save to, with the default
|
|
|
916 as the current Environment file name.
|
|
|
917
|
|
|
918
|
|
|
919 @node Env Update, , Env Save, Environments
|
|
|
920 @c node-name, next, previous, up
|
|
|
921 @subsection Updating Environments
|
|
|
922
|
|
|
923 @findex br-add-class-file
|
|
|
924 @cindex class, adding to Environment
|
|
|
925 @cindex class, replacing in Environment
|
|
|
926 @cindex Environment, adding classes
|
|
|
927 @cindex Environment, replacing classes
|
|
|
928 @cindex initialization file
|
|
|
929 A file containing class definitions may be added to the Environment with
|
|
|
930 the add class file command. This will prompt for the file name, scan
|
|
|
931 the file, and then update the Environment. If a class defined in the
|
|
|
932 file is already in the Environment, its information will be replaced
|
|
|
933 with the information gathered from the file; otherwise, the class will
|
|
|
934 be added to the Environment.
|
|
|
935
|
|
|
936 @cindex Environment, adding individual classes
|
|
|
937 To add a single class from a file containing multiple classes, the file
|
|
|
938 can be read into an Emacs buffer, the buffer narrowed to the desired
|
|
|
939 class and then the add command executed. @xref{Narrowing, , Narrowing,
|
|
|
940 emacs, The Gnu Emacs Manual}.@refill
|
|
|
941
|
|
|
942 This command may also be used outside of the browser user interface when
|
|
|
943 one is editing a file in Emacs, so that there is no need to jump in and
|
|
|
944 out of the browser.
|
|
|
945
|
|
|
946 @kindex C-c C-d
|
|
|
947 @findex br-delete
|
|
|
948 @cindex class, deleting from Environment
|
|
|
949 @cindex Environment, deleting classes
|
|
|
950 A class is deleted from the Environment, by pointing to its name in a
|
|
|
951 class listing buffer and then executing the delete class command.
|
|
|
952 The class matching command may be used to locate it. The browser
|
|
|
953 confirms the deletion by removing the class name from the listing
|
|
|
954 buffer.
|
|
|
955
|
|
|
956
|
|
|
957 @node Further Work, Conclusion, Design Specifics, Top
|
|
|
958 @chapter Suggestions of Further Work
|
|
|
959
|
|
|
960 @section Expand Query Types
|
|
|
961
|
|
|
962 The browser really only works with inheritance and method relations
|
|
|
963 right now. There is an undeniable need for the addition of supplier,
|
|
|
964 client, and category-based browsing.
|
|
|
965
|
|
|
966 Suppliers are classes which contain methods invoked by other classes,
|
|
|
967 the clients. Computation of these recursive relations is expensive. A
|
|
|
968 technique must be developed which preserves the quickness of Environment
|
|
|
969 construction and supports queries using these relations.
|
|
|
970
|
|
|
971 Method breakdowns by visibility (public, private, protected) would also
|
|
|
972 be useful to add. This should not require too much work.
|
|
|
973
|
|
|
974 Category-based browsing should be the next major addition. Some other
|
|
|
975 people have already done work on adding facet-based categories to the
|
|
|
976 browser. Facets are traits that classes have. Classes sharing facets
|
|
|
977 are grouped into a facet category. Facet examples might be: fixed sized
|
|
|
978 container classes, domain-specific classes, or classes that contain a
|
|
|
979 name field.
|
|
|
980
|
|
|
981 @menu
|
|
|
982 * Dynamic Object Browsing::
|
|
|
983 * Tool Integration::
|
|
|
984 * Graphical Interface::
|
|
|
985 * Version Control::
|
|
|
986 @end menu
|
|
|
987
|
|
|
988 @node Dynamic Object Browsing, Tool Integration, Further Work, Further Work
|
|
|
989 @section Support Dynamic Object Browsing
|
|
|
990
|
|
|
991 The OO-Browser works with static structures. It therefore utilizes
|
|
|
992 class groupings but has no concept of run-time objects. The techniques
|
|
|
993 and query relations desired in an object browser are very different from
|
|
|
994 that of a class browser. Therefore, a separate tool should be built.
|
|
|
995 It could, however, utilize the OO-Browser user interfaces. It would
|
|
|
996 then act as a back-end engine communicating with the class browser
|
|
|
997 interface. This raises the inter-application communication issue of the
|
|
|
998 next section.
|
|
|
999
|
|
|
1000
|
|
|
1001 @node Tool Integration, Graphical Interface, Dynamic Object Browsing, Further Work
|
|
|
1002 @section Provide Mechanism for Integration with Other Tools
|
|
|
1003
|
|
|
1004 Emacs supports subprocess control. This is how the textual interface
|
|
|
1005 communicates with the graphical interface. They use a simple
|
|
|
1006 redirection of standard input and standard output.
|
|
|
1007
|
|
|
1008 A much more desirable and flexible strategy is to use a communications
|
|
|
1009 medium like sockets to allow peer-to-peer communication. On top of this
|
|
|
1010 low-level mechanism, a method like Field's Selective Broadcasting
|
|
|
1011 [@cite{Reiss 88}] or ET++'s Multiple Views [@cite{Weinand 89}] might be used.
|
|
|
1012
|
|
|
1013 @node Graphical Interface, Version Control, Tool Integration, Further Work
|
|
|
1014 @section Extend Graphical Interface
|
|
|
1015
|
|
|
1016 A lot could be done here, none of it particularly difficult. As
|
|
|
1017 mentioned before, a full suite of browser commands should be added.
|
|
|
1018 A technique that allows dynamic menu entry additions would provide the
|
|
|
1019 requisite flexibility. This could probably be achieved with a basic
|
|
|
1020 resource file format and a small amount of application code to cache the
|
|
|
1021 entries.
|
|
|
1022
|
|
|
1023 @node Version Control, , Graphical Interface, Further Work
|
|
|
1024 @section Support Version Control Systems
|
|
|
1025
|
|
|
1026 RCS is the likely candidate system. One would want to be able to
|
|
|
1027 browse particular releases and to avoid mixing code from one release
|
|
|
1028 with that of another when building Environments.
|
|
|
1029
|
|
|
1030
|
|
|
1031
|
|
|
1032 @node Conclusion, , Further Work, Top
|
|
|
1033 @unnumbered Conclusion
|
|
|
1034
|
|
|
1035 The OO-Browser is a robust tool for class or generalized hierarchy
|
|
|
1036 browsing. New subsystems are easy to integrate, so we expect the
|
|
|
1037 available types of queries and means of user interaction to continue
|
|
|
1038 to expand.
|
|
|
1039
|
|
|
1040 The browser demonstrates useful user interface techniques. It supports
|
|
|
1041 multiple interaction modalities: keyboard and mouse inputs, graphical
|
|
|
1042 and textual views, menu and direct selection techniques. This allows
|
|
|
1043 the user to choose a style with which he is comfortable. The ease of
|
|
|
1044 entry and exit from the browser coupled with its access speed,
|
|
|
1045 encourages a developer to use it often. It integrates well with the
|
|
|
1046 incremental development cycles often found in object-oriented projects.
|
|
|
1047 It further supports the developer with external interfaces for compiler
|
|
|
1048 error parsing and type name completion.
|
|
|
1049
|
|
|
1050 The browser implementation vividly illustrates that a single, portable
|
|
|
1051 tool and interface can be used for a variety of languages. Departmental
|
|
|
1052 language needs often change. So the ability to continue to use the same
|
|
|
1053 tool with a different language lessens developer slow down and actually
|
|
|
1054 provides an immediate comfort zone, so that the change need not be
|
|
|
1055 overwhelming. Another good example of interface reuse is the ET++
|
|
|
1056 application development framework [@cite{Weinand 89}]. It provides a
|
|
|
1057 means of building highly interactive, window system independent
|
|
|
1058 applications that all share common interface constructs. One would hope
|
|
|
1059 that more developers of programmer support tools will start taking an
|
|
|
1060 approach of this kind.
|
|
|
1061
|
|
|
1062 @sp 2
|
|
|
1063 [@cite{Goldberg 83}] Goldberg, Adele and David Robson.
|
|
|
1064 @emph{Smalltalk-80: The Language and its Implementation}.
|
|
|
1065 Addison-Wesley, 1983.
|
|
|
1066
|
|
|
1067
|
|
|
1068 [@cite{Reiss 88}] Reiss, Steven P. "Integration Mechanisms in the FIELD
|
|
|
1069 Environment," Brown University Technical Report CS-88-18, October 1988.
|
|
|
1070
|
|
|
1071
|
|
|
1072 [@cite{Stallman 87}] Stallman, Richard. @emph{GNU Emacs Manual}. Free
|
|
|
1073 Software Foundation, Cambridge: MA, March 1987.
|
|
|
1074
|
|
|
1075
|
|
|
1076 [@cite{Weinand 89}] Weinand, Andre, Erich Gamma, and Rudolf Marty.
|
|
|
1077 Design and Implementation of ET++, a Seamless Object-Oriented
|
|
|
1078 Application Framework, @i{Structured Programming}, Springer-Verlag: NY,
|
|
|
1079 NY, Vol. 10, No. 2, 1989.
|
|
|
1080
|
|
|
1081
|
|
|
1082 @contents
|
|
|
1083 @bye
|
|
|
1084
|
