Browsing class libraries

Using class libraries is an important part of modern programming, and reuse of library classes is a fundamental software development technique. To be effective, a course based on an object-oriented language must integrate the use of libraries at an early stage in the curriculum [Tewari 1994]. It has frequently been observed that introducing the practice of reuse into existing organisations is very difficult. Many programmers rather reimplement classes than reuse existing ones. Three character- istics have been identified as prerequisites for the acceptance of reuse:

· the programming language must support a mechanism for reuse of existing code,

· the environment must ensure that the effort of finding an appropriate class to be reused is smaller than writing it again, and

· a culture must be established in which the programmer views the reuse of class libraries as an intrinsic part of normal programming.

The first point has been addressed by object-oriented languages. A substantial part of the hope that object-oriented languages may improve the quality of software being developed has to do with the possibility of greater reuse. The other two points, however, have initially been neglected.

The second point Ð finding classes Ð can be addressed with better tools. A good class browser is needed that allows a programmer to search and browse libraries of existing

CHAPTER 7: THE BLUE ENVIRONMENT

classes easily. The third point Ð reuse culture Ð is best addressed by teachers. If reuse is conveyed as normal part of programming from the very beginning, the difficulties associated with requiring an attitude shift later on are avoided.

For a teaching context this means that a good, easy to use browser is an important part of the environment.

The Blue browser can be opened by selecting the ÒLibrary BrowserÓ command from the ÒToolsÓ menu. The main browser window is shown in Figure 7.20.

Figure 7.20: The Blue library browser

The browser uses a pane based design with three panes. Pane based designs have successfully been used in several other systems, e.g. in Smalltalk-80 [Goldberg 1984] and the Dylan environment [Dumas 1995]. At the top left a list of library sections is shown. Each section groups related classes together. On the top right a graphical representation of the currently selected section is shown in the same manner in which Blue projects are presented. In the bottom pane detailed information about the currently selected class is displayed. This includes the class comment and a list of interface functions. The bottom pane is updated each time the user clicks on a class icon to display the details of the selected class. The class icon may also be opened (with a double-click) in the same manner as classes in user projects are opened to display its full interface or (depending on permission) its implementation.

CHAPTER 7: THE BLUE ENVIRONMENT

7.9.1 Browsing

When browsing the library, a user first examines the list of sections in the library and selects a section which most likely includes classes for the task at hand. The section is then presented using the same graphical display used for a project.

It has often been argued that a browser should enable the user to find related classes. Relevant relationships are super- and subclasses, used classes and clients, and other classes with related functionality. Some existing browsers provide functionality to find some of those related classes.

The graphical display used in Blue provides all of this information in an easily understandable manner. Inheritance and uses relationships are immediately obvious, and even semantically related classes which have no technical relation can be visually associated by placing them close to another class in the same section. If, for example, a programmer looks for a list class, the classes ÒStackÓ and ÒQueueÓ (and other collection classes) will also be visible on screen, encouraging the programmer to also examine and consider those classes for use.

When a suitable class is found, the programmer can select the class and invoke the ÒUse class in projectÓ command from the ÒClassÓ menu. The class will then appear in the current project, identified as a library class by its colour. Library classes in a project can be opened, read, called and used like other classes in the project. They cannot be edited, though.

The concept of browsing classes is significantly different from browsing in a Smalltalk system. The first noticeable difference is the graphical presentation. While the Smalltalk browser displays a single class tree as a nested list, the Blue browser uses several independent library sections and graphics for representation. Dividing the library into sections makes it easier to find relevant classes and to switch between related classes. The graphical display visualises relationships. In Smalltalk, inheritance relations are displayed through the list nesting structure (by indenting subclasses under their superclass). Client relationships, however, are not displayed. It is, in fact, not possible in Smalltalk to extract client information from a class definition, since Smalltalk code is not statically typed. Call relationships between classes are only known at runtime.

The main difference, however, between browsing in Smalltalk and in Blue is the clear distinction between the current project and the libraries in Blue. In Smalltalk the browser presents a unified view of the ÒuniverseÓ which includes all user-defined and library classes. This unification, while consistent and powerful, has been named as one of the most serious problems for beginners in dealing with Smalltalk environ- ments (see chapter 4). The distinction between the current project and the libraries in Blue, and the process of explicitly importing library classes into the project, greatly simplify the appearance of the project under development and ease studentsÕ understanding of the environment.

CHAPTER 7: THE BLUE ENVIRONMENT

7.9.2 Searching

Another important browser function is searching. The browser provides a ÒFind classÓ command that displays a find dialogue. In this dialogue details about the search can be specified. This includes the search string, the search context and the set of classes to be searched.

The search context gives the user the option to search in the whole class source, in the interface of a class, in comments only, in routine names only, by author name or any combination of these. The set of classes to be searched can be restricted to the current section, the whole library or all classes in all known libraries.

Search results are then displayed in a list. Selecting a result in that list displays the class by opening its section and highlighting the class.

7.9.3 Integration

The browser closely cooperates with the compiler. This integration provides the basis for better functionality than would be achievable with a stand-alone browser.

The information used and displayed in the browser is not taken from the classesÕ source text, but from the symbol table produced during compilation. The compiler stores the symbol tables and makes them available to the browser. This ensures that the information shown in the browser is syntactically correct. It also provides a simple mechanism to allow different levels of access to library classes. Creators of libraries can, for example, decide whether they want to allow read access to the source text of the library or not. This can then be implemented by using the access restrictions of the underlying operating system. Because the source is not otherwise used for browsing, a library can be searched, browsed and used with access to only the code and symbol tables. An author can easily deny access to the source and still provide a fully functional library. One example where this may be used is in the context of student assignments. A teacher can provide a sample solution in a library which students can execute to examine the behaviour of the program, but without having the ability to view the source code.

On the other hand, the author of a library may wish to allow access to the source. In the library of collection classes in the current Blue system, for instance, all source code is readable by users. They serve as useful examples of well written Blue code that students might find interesting to look at and study.

7.9.4 Documentation

A class library should not only provide the code of useful classes, but also its documentation. Users need to know the signatures and the semantics of library routines.

Many systems separate these issues and use two different tools to provide these two sides of the same coin. Borland C++, for instance, uses the standard C++ include

CHAPTER 7: THE BLUE ENVIRONMENT

mechanism for the inclusion of library classes and provides documentation for those libraries through a separate help system. This mechanism is error prone, duplicates effort and is not easily extensible. It is error prone because it can easily happen (and does regularly happen) that the implementation and the documentation get out of sync. Library classes might be changed or added, while the documentation is not updated. It duplicates effort because the creator of a library class is forced to write explanations twice: once in the class interface and once in the help system. (In the case of C++ it is, in fact, often written three times: in the implementation file as well.) And it is not extensible because it is not always equally easy to add library classes and help files. In the Borland system, for instance, user classes may be added into the library collection for general inclusion, but help information cannot be added, effectively leaving the user-defined library classes without documentation.

Java tries to overcome some of these problems with a similar construct as Blue: interface comments. Certain comments in the Java classes are especially marked as interface documentation and can be extracted by a separate tool (called ÒJavadocÓ). This creates documentation for a class. This mechanism avoids the duplication of effort: documentation is only written once (in the class source) and automatically extracted for outside documentation. It does not, however, solve the problem of outdated or missing documentation. It may still happen that a classÕs code is updated while its documentation is not, leaving the user with incorrect information. It also does not guarantee the availability of documentation.

In Blue, the documentation is written only once in the classÕs source code. It is then stored together with the class in its symbol table. The classÕs code and its documen- tation cannot be separated. This guarantees the accuracy and availability of the documentation (as far as it has been written by the author). The class browser doubles as a help system that can display detailed information about interfaces and semantics of classes and routines.

7.9.5 Additional functionality

The description so far reflects the current implementation that derives its design from an early prototype. Currently work is under way to implement an improved library browser which provides additional functionality to improve the usefulness of class libraries. The new design includes two new areas of functionality: improved library

management and library creation.

The library creation facilities allow users to create their own class libraries easily. A student then can, over time, create a private collection of useful classes and store them in a personal library that may be searched and browsed with the standard browser. Libraries can also be created by work groups for current projects. The creator of a library can specify access restrictions. This allows individual libraries to be kept private or to be published for the whole world to use. The access model used is similar to the three level Unix model that distinguishes the user, a work group and the rest of the world.

CHAPTER 7: THE BLUE ENVIRONMENT

The library management facilities let every user configure the browser to offer access to different libraries. In effect, they make libraries known to the browser. By default, each browser will offer access to the Blue standard library and a personal, private user library. Other libraries can then be added to the browser. These are included in a menu for easy access to all known class libraries.

7.9.6 The libraries

As with other parts of the programming environment, the requirements for libraries used for teaching differ from those used in professional software development. Tewari and Gitlin [Tewari 1994] state that Òmost discussions about the design of object- oriented libraries revolve around the need of professional programmers. However, we should not assume that the needs of students are identical with the needs of experienced software engineers. In fact, there are a number of areas in which the two differ.Ó The primary requirements for a teaching context are ease of use and clarity. This means that, as with the environment as a whole, the libraries used should be specifically designed for a teaching system. If a library is complicated and the student needs to study it for a long time before it can be effectively used, its value is greatly reduced. It will then detract from other concepts the student is investigating. Tewari and Gitlin [Tewari 1994] observe that many libraries are unsuitable for teaching because Òmany commercial vendors seem fixated on supplying every possible option imaginable. The extensive features add to the difficulty of using the library without necessarily adding to its pedagogical value.Ó

Blue currently offers four library sections: collection classes, graphical user interface (GUI) classes, input/output classes (such as files), and ÒutilityÓ classes (such as date and time classes). All of these were designed to offer an interface that is easy to understand and to use.

A discussion of the details of the library design is beyond the scope of this work. The interested reader can download the Blue system from one of the locations listed in Appendix B. The system distribution includes the libraries.