- Email: [email protected]
Finding reusable components in smalltalk-80
Computers Educ. Vol. 20, No. I, pp. 63-72, 1993 Printed in Great Britain. All rights reserved
FINDING
Copyright
REUSABLE
COMPONENTS
for Information
0360-1315/93 $6.00 + 0.04 1993 Pergamon Press Ltd
IN SMALLTALK-
Lr
YIBING
Centre
0
Technology in Education, Institute of Educational University. Milton Keynes MK7 6AA, England
Technology,
The Open
Abstract-Smalltalkis an object-oriented programming system. It promotes the “programming by reuse” approach. Programmers use existing programs to construct new ones. However, in Smalltalk, non-expert users have difficulties in finding reusable components. In this paper, the causes of this problem are analysed and a tool developed to help non-expert users overcome this problem is described. With this tool, users can query the system to get the information they require and their navigational difficulties are significantly reduced.
INTRODUCTION
Object-oriented programming exploits multiple representations of information and is particularly suitable for simulation. In addition, object-oriented programming languages allow an easy correspondence between a real world object and a data process object. For these reasons, the object-oriented programming paradigm has become increasingly popular and has attracted interests in the computer assisted learning community. Smalltalk is not only a pioneer of object-oriented systems, but is also the most uniform system, since it is based on the single paradigm of objects. It is an interactive system and has a powerful set of tools as well as a large library of components which can be used to build graphical interfaces. This system has been used to develop educational software to facilitate learning (e.g.[l-31). However, it has been reported[4] that non-expert users have difficulties in learning and using Smalltalk. One problem which we shall discuss below is that users have difficulties in finding required components in their programming. An important aspect of the object-oriented programming paradigm is that it promotes the “programming by reuse” approach [5] (here only reuse of code is considered). Programmers do not always have to code from the beginning; they use existing components as the basis of new programs. Smalltalk(abbreviated to Smalltalk) has a large components library and reuse of existing components, classes and associated methods, is the recommended programming style. The reuse approach seems promising for improving the efficiency of the code production. However, reuse is not without cost. Biggerstaff and Charles[6] suggests that in order to reuse software successfully, a system must address the following fundamental problems: finding components understanding components modifying components and composing components, Among these problems, being able to find required components efficiently is a prerequisite to success. This is because to reuse components, users must know what components should be used and where they can find them in the system. In Smalltalk, finding the required components is not easy for non-expert users. An empirical study [4] shows that this is one of the main factors affecting the learnability and usability of this system. In this paper, the causes of this problem are analysed and a tool is described to help users overcome the difficulty. The term ‘users’ here refers to the non-expert users. Although the tool is developed for Smalltalk, the idea is directly applicable to other object-oriented systems.
THE
CAUSES
OF
THE
PROBLEM
The problem of finding required components in Smalltalk is exacerbated by the size of the system. Smalltalk has over 250 classes and more than 3000 methods. In such a large system, finding required 63
64
YIBING LI
classes or methods is no easy task for users. The system must provide users with supporting mechanisms. The System Browser of Smalltalk is a tool which allows users to access classes and methods but it only allows users to access them according to their names. As non-expert users usually have only a limited knowledge of the system’s terminology and structure, there is a great vocabulary barrier[7]. Since names of the components do not always convey enough information, users would have difficulties in finding the necessary components. They sometimes have to choose a wider range of components and study their functions in detail, often by reading the implementation code. The code to perform certain functions is usually distributed among many classes. Therefore users need to gather all pieces of relevant code from different classes to form a complete picture about how a function is performed. Moreover, the task of understanding the execution of a given function is made more difficult by the polymorphism and dynamic binding of Smalltalk which make it difficult to understand which method is being executed during a computation. As a result of these difficulties, users sometimes find themselves in a situation where they either overlook the relevant components or after making considerable efforts in studying a particular set of components, realize that those components are in fact irrelevant to their tasks. Although the above discussion is mainly based on Smalltalk, it is also applicable to other object-oriented programming systems. Because of the ease of adding new objects into systems, object-oriented programming systems tend to encourage large libraries of components[8]. At a certain stage, users will have similar problems to those discussed in relation to Smalltalk. It is essential therefore for these systems to provide supporting tools to help users find reusable components and reduce their difficulties. Existing tools, such as the System Browser in Smalltalk, are useful but not sufficient. It is necessary to develop other tools.
THE
PROPOSED
SOLUTION
The proposed solution to the problem discussed above is to augment the System Browser of Smalltalk with a query tool. When users give a description of their target components, the tool would provide the users with a list of candidate components whose functions match their description. Users may then choose the components they require from this list. Such a tool reduces users’ search space, since they only need to study the relevant components. Therefore users are saved the time and resources wasted on studying irrelevant components and their navigational difficulties would be greatly reduced. Based on this idea, we have developed a tool BRRR (BRowser for Retrieval by Reformulation) for a subset of Smalltalk’s components. The details of BRRR will be described in the following sections. One point to note is that although the kind of tool we proposed aims mainly at helping non-expert users, it also has the potential to help expert users. Object-oriented programming systems are usually large. It has been suggested that with very large software systems, there are few experts who have a complete mastery of all components[9]. Expert users would therefore benefit from this tool when they need to use components in the system with which they are not familiar.
AN OVERVIEW
OF BRRR
BRRR comprises two parts: the software component. library and the user interface. It is designed to facilitate the process of constructing a query. Users start the retrieval in BRRR by entering an initial query into the system. BRRR presents a list of classes or methods which match the initial query. The description of one of the matched individuals, the example instance, is shown to users. Users may examine the example instance and modify the initial query by selecting information embedded in the description of the example instance. This modified query may be used to retrieve a new set of matches and a new example instance. The query can then be further refined based [IO] is repeated until on the new information. This process, known as “retrieval by reformulation” users are satisfied with the result or until it is established that there is no item in the system satisfying users’ requirements.
Reusable THE
components
COMPONENT
in Smalltalk-
65
LIBRARY
In Smalltalk, the basic reusable components are classes and associated methods. Related classes are grouped together into class categories (see Fig. 1). In this system, a class can belong to only one category. This organization has a drawback. If users do not follow the system designer’s classification, then they may not be able to identify the category which contains the classes they need. In BRRR, classes performing similar functions are grouped together into one category and some categories may have sub-categories. An example of this classification for part of the Collection classes is illustrated in Fig. 2. In this classification scheme, a class may belong to more than one class category. For example, in Fig. 2, the class Dictionary belongs to both the category: Arbitrary-keyed and the category: Unordered. By allowing a class to belong to more than one category, the probability of finding it is increased. In Smalltalk, each class has a number of methods associated with it. Related methods within individual classes are grouped together into method categories. Each method belongs to only one method category (see Fig. 3). In BRRR, all methods associated with the classes within a class category are classified into different method categories. The methods which have similar functions are grouped into a category. Some method categories, similar to that of the class categories, may have sub-categories. Each method belongs to one or more categories. Taking the Collection classes as an example again, all instance methods in all Collection classes are grouped into the following method categories, some of which are shown in Fig. 4: adding; accessing; removing; enumerating; testing; copying; converting. The method category: accessing, for example, includes all methods elements in collections. This category has three sub-categories:
in collection
classes for accessing
querying-elements/parameters; finding-index; replacing-elements. The category: querying-elements/parameters contains methods which are used to query elements or parameters in collections. Some of the methods in the category are: size in class size in class at: anlndex the position
values of
Array returns the storage space of the collection. OrderedCollection returns the number of the elements in the collection. in class SequenceableCollection returns the element of the collection which is at specified by an integer index represented by the argument anlndex.
Associated with each method category is a set of attributes the methods in the category. Each method in a category
SortedCollection Fig. 1. The class classification
MappedCollection
w
which characterizes the functions of has values corresponding to those
IdentityDictionary
IdentitySet
in Smalltalk for a subset of the Collection classes. The root nodes are class categories and the leaf nodes are classes.
YIBING LI
66
/
Array
Interval SortedCollection
OrderedCollection Fig. 2. Class classification
IdentityDictionary
for a part of the Collection classes in BRRR. categories and the leaf nodes are classes.
attributes according to its function. on the following criteria: the the the the
LinkedList
The designation
of the attributes
The non-leaf
IdentitySet
bg
nodes are class
to a method
category
is based
operation that methods in the category perform; action for handling exceptional situations; objects these methods manipulate; objects produced as a result of the operation.
The method
category:
replacing-elements,
for example,
has attributes:
operation; object-replaced; position-in-the-receiver; object-returned. One method in this category is atAll: anInterval put: anobject in the class SequenceableCollection. Its function is to put the argument: anobject at every index specified by the integer elements an Interval. It is described as follows: Operation: Object-replaced: Position-in-the-receiver: Object-returned: For the category:
replace multiple-elements positions-specified-by-an-interval receiver
adding, the attributes
are:
operation; elements-added; position-in-the-receiver; objects-returned.
size Fig. 3. The method
first
classification in Smalltalk for the class OrderedCollection. The nodes in the middle of the tree are method categories and the leaf nodes are methods.
of
Reusable components in Smalltalk-
at: ifAbsent: (Dictionary) Fig. 4. The method classification in BRRR. The text in parentheses are names of the classes with which the methods are associated.
A method in this category is add: anobject in the class SortedCollection. Its function is to add an object into a sorted collection. The operation is performed according to a sorting algorithm so that all elements in this collection will be automatically ordered according to their values. Its description is: Operation: Object-added: Position-in-the-receiver: Object-returned:
add one-element positiondetermined-by-the-receiver’s-sorting-rule anElement.
In the case of one method belonging to more than one category, the method would have the sum of all the attributes that it possesses in each category.
QUERY
AND
RETRIEVAL
IN BRRR
The interface
BRRR’s interface consists of three main windows: the class level query window (see Fig. 5) the method level query window (see Fig. 6) and the trace window (see Fig. 7). The class level query window has five panes: Class Category Hierarchy pane; Class Query pane; Matched Classes pane; Method Categories pane; Example pane. The Class Category Hierarchy pane illustrates the hierarchical structure of class categories. This is to help users comprehend the overall structure of the component organization. The Class Query pane contains users’ queries about the classes for which they look. The Matched Classes pane displays all classes which match a class query. The Method Categories pane shows the method categories in a class which is selected by users. The Example pane presents a description of one of the matched classes. The description includes class categories to which the class belongs and a comment describing the function of the class. The method level query window has a similar structure to that of the class level query window. BRRR also has a browsing capability, it allows users to select any class (or method) which appears in the Matched Classes pane (or the Matched Method pane in a method level query window) to examine its relevance. However, one problem is that users may not remember which class (or method) they have examined before. Therefore BRRR provides a Trace window which shows users the components they have inspected before to reduce users’ navigational overheads.
68
YIBING
LI
Class Category Hierarchy
Class Query
Matched Classes
Method Categories
OrderedCollection LinkedList
Collections Keyed Integer-keyed
adding accessing COPyi% enumerating testing
with method attributes: Operation: add Objects-added: one-element Position-in-the-receiver: end Object-returned: anElement I
Explain
I
Example p
Collections Keyed Integer-keyed
Require-this-category
-
Prohibit-this-category Show-allclasses
OrderedCollection Class OrderedCollection represents a collection of elements explicitly ordered by the sequence in which objjts are added and removed. Elements are accessible by external keys that are indices. Fig. 5. The class level query window.
Query construction
A query in BRRR is constructed in two steps: the class level query and method level query. They are described in turn in the following sections. The class level query. Users start a query by first using the class level query window. They create an initial query by using the class categories in the Class Category Hierarchy pane. They can click on a class category in which they believe the required classes to be and then manipulate the category with options appeared in a pop up menu. The menu options are: Require-this-category; Prohibit-this-category; Show-classes; Explain.
The Require option adds the category into the class query; the Prohibit option applies the relative complement of the category to the class query. The Explain option gives a text explanation about the characteristics of classes in the category. The Show-classes option shows users the names of the classes in this category and provides a preview. Users should comprehend the meaning of a category better by seeing the items contained in it. Once an initial query is constructed, users can request BRRR to perform a retrieval. The system retrieves all classes which belong to the required class categories but do not belong to the prohibited categories. The result is then shown to the users. The description of one of the matched classes is displayed in the Example pane. One purpose of the Example pane is to provide users with a concrete example of the components which match the current query. It tells users the system’s understanding of their query. In addition, the description of the example instance supplies the users with information necessary to reformulate the partial query. The users can use the information provided in the description of the example instance to refine the initial query. They can use the
69
Reusable components in SmalltalkMethod Category Hierarchy
Method
Matched Methods
Query
adding position-relevent Operation: add Object-added: one-element Position-in-the-receiver: positiondetermined-by-the-receiver’s-sorting-rule Object-returned: anElement
Explain
add: (SortedCollection)
Example adding position-relevent add: newObject (SorteredCollection) “I add an element newObject into the receiver and put it at the position determined receiver’s sorting rule. ” Operation: Objects-added: Position: Object-returned:
add one-element positiondeterminded-by-the-receiver’s-sorting-rule anElement Fig. 6. The method level query window.
Trace .~ .,...,,,,. ~~~~~~~~~~~~~~~
SortedCollection
Bag bay Dictionary Set
collections Keyed Integer-keyed Arbitrary-size Class OrderedCollection represents a collection of elements which are ordered explicitly by the sequence in which they are added or removed. Elements of it are accessible by external keys that are indices. Fig. 7. Trace window.
by the
YIBING LI
70
class categories shown in the descriptions of the example instance (the boldface words in Fig. 5) in the same way as that used in the Class Category Hierarchy pane. The method letlel query. After several cycles of class retrieval, users would be shown a list of classes. However, it is likely that users still do not know which class to choose and they are not certain which class category to select either. At this stage, they can study the functions of the matched classes by examining the methods associated with them. This is because the function of a class is more fully specified by its methods. In addition, users can further refine the current class query by constructing a method level query. From the Method Categories pane in the class level query window, users can select a method category and initiate a method query. A method level query window would subsequently be open. The relationship between the selected method category and its sub-categories would be illustrated in the Method Category Hierarchy pane (see Fig. 6). Query and retrieval processes in this window are similar to that of the class level. To compose an initial method query. users select a method category and manipulate it in much the same way as in the class level query. In the Example pane of the method level query window, the description of an example method comprises: the method a comment the method
categories describing descriptors
to which this method belongs; the function of the method; (i.e. the attributes and their corresponding
In addition to manipulating the method options to manipulate the attribute-value
values).
categories in the Example pane, users can use a set of menu pairs to modify the partial method query. The options are:
Require-this-value; Prohibit-this-value; Alternative-values. The first two options have similar functions to those of the class query level window. The option: Alternative-values suggests a set of alternative values to a value of an attribute. For example, for the add: method in the class OrderedCollection, the value of the attribute Position-in-the-receiver is end. which means every time this method is used, the element added is put into the last position of an OrderedCollection. Users may, however, intend to find an adding method such that it adds an object into a collection and the added element should be ordered according to its value. In this case they can use the Alternative-values option to get a list of other values, among them, the value: “position-determined-by-the-receiver’s-sorting-rule”, which would be the appropriate one to choose. When users request the system to do a method retrieval, the system will retrieve the methods which satisfy the following conditions: (1) They must be methods of one of the matched classes. (2) They must belong to the required method categories but not belong to the prohibited (3) The values of the attributes must be the same as those in the query.
ones.
After the system performs a method retrieval, users may merge the method query into the Class Query pane. This allows a request to the system to find classes which contain those methods. Users may repeat the same process until they find the satisfactory classes. In BRRR, query is constructed mainly by selecting the descriptors (categories, attribute-value pairs, etc.). Users do not need to remember their names. This should reduce users’ learning overheads and should be particularly helpful for the non-expert users. The descriptors which appear in both the class and method query panes are implicitly connected by the logical operator ‘and’. The prohibited descriptors are in the form of ‘not’. Currently, BRRR only has a limited capability to process the ‘or’ operation. Given the above description, it is not difficult to understand the meaning of the query appearing in the Class Query pane of Fig. 5. The query requests the system to retrieve the classes which are: Collection classes; classes which should
be accessible
by a key;
Reusable
components
in Smalltalk-
71
classes which should have integer keys; classes which should have methods which can perform an ‘add’ operation and the added single element will be put into the last place of the collection. The methods visible to users In BRRR, only methods which are regarded as ‘public’ are presented to users. The methods regarded as ‘private’ are not shown. This is to provide better support for the concept of data encapsulation. Private methods are only for internal uses and should not be made visible to users. Another feature of BRRR is that all methods of a class including those inherited from its super classes are shown to users. In Smalltalk, classes are organized into a hierarchy. An object inherits all methods of its super classes. The System Browser only shows users methods explicitly defined in a class. To find the inherited methods, users need to navigate through the hierarchy by following the inheritance chain. This increases the burden of the users. In BRRR, all methods of a class are shown, so users should more easily find all methods of a class. RELATED
WORK
Wu[l l] proposed a browser for object-oriented systems. It has some of the features of BRRR (e.g. showing users all methods of a class; hiding private methods). However, it does not support queries. Prieto-Diaz and Freeman [ 121used principles developed in library science, the facet classification scheme, to design a classification and retrieval scheme for reusable components. Frakes and Nejmeh [13] used keyword search techniques employed in bibliographic databases to retrieve reusable components. Similar work can be found in Burton et al. [14] and Arnold and Stepoway [ 151. These approaches presume users comprehend the meaning of keywords correctly. Consequently, these approaches have the vocabulary problem which we mentioned above. Wood and Sommerville[l6] developed a system based on the principle of conceptual dependency as proposed in artificial intelligence. In the particular field of helping users learn Smalltalk, several attempts have been made. The main approach is that of using a pre-designed tutorial about a subset of Smalltalk, plus the use of a graphical tool to facilitate users to comprehend the functions of these components[l7-191. Singley and Carroll [20] developed an intelligent instructional system employing the minimalist [21] approach to teach novice users Smalltalk programming. However, because the system’s library grows dynamically, the success of these approaches, which rely on pre-designed materials, is seriously limited. CONCLUSION A prototype of BRRR has been implemented in Smalltalkon a Macintosh IIcx. So far, we have only chosen to experiment with the Collection classes of Smalltalk. We believe that this selection is complex enough to reflect the typical situation where users need help in finding information from the system. Presently, BRRR cannot process the components defined by users. However, the framework of BRRR is flexible enough to be extended to deal with such a situation. For example, users may choose one of the class categories to put a new class under it. They may then retrieve one of the existing methods as a template, input the appropriate values for the attributes and subsequently store them. The newly added components would then be treated equally as the existing ones and ready for further retrieval. BRRR is yet to be integrated with the original Smalltalksystem. Currently, we are evaluating BRRR with users. The result is expected to be reported in the near future. Acknowledgements-I would like to thank Tim O’Shea, Steve Cook, Randall Smith, Alan Borning, and Pat Fung for helpful advice and Benedict Heal, Mike Brayshaw, Royston Sellman for constructive discussions during this project. I am grateful to Pat Fung for critical comment to drafts of this paper. The author is supported by an Open University research studentship.
72
YIBING
LI
REFERENCES I. Borne I. and Girardot C., Object-oriented programming in the primary classroom. Computers Educ. 16,93-98 (1991). 2. Smith R. B., The Alternate Reality Kit: an animated environment for creating interactive simulations. Proc. IEEE Workshop on Visual Languages. IEEE, Washington (1986). 3. Twigger D., Byard M., Draper S., Driver R., Hartley R., Hennessy S., Mallen C., Mohamed R., O’Malley C., O’Shea T. and Scanlon E., The ‘conceptual change in science’ project. J. Comput. Assisted Learning 7, 144-155 (1991). 4. O’Shea T., Why object-oriented programming is hard to learn. Human Compurer Interaction. In press (1993). 5. Meyer B., Reusability: the case for object-oriented design. IEEE Software 4(2) (March 1987). 6. Biggerstaff T. and Charles R., Reusability framework, assessment, and directions. In SoftWare Reusability Vol. I Concepts and Models (Edited by Biggerstaff T. and Perlis A.), pp. l-7. Addison-Wesley, New York (1989). 7. Furnas G. W., Landauer T. K., Gomez L. M. and Dumais S. T., The vocabulary problem in human-system communication. Commun. ACM 30, 964-971 (1987). 8. Halbert D., Learnability of object-oriented programming systems, Proc. OOPSLA’86, Oregon, pp. 503-504 (1986). 9. Draper S. W., The nature of expertise in UNIX. Proc. INTERACT’@, Amsterdam, pp. 182-186 (1984). IO. Williams M. D., What makes RABBIT run? Int. J. Man-Machine Stud. 21, 333 -352 (1984). 11. Wu C. T., A better browser for object-oriented programming. J. Object-Oriented Programming 22-28 (November/December 1990). 12. Prieto-Diaz R. and Freeman P., Clasifying software for reusability. IEEE Software 4, 616 (1987). 13. Frakes W. B. and Neimeh B. A., Software reuse through information retrieval. Proc. 12th Annual Hawaii hf. ConJ on System Science, Hawaii, pp. 530-535 (1987). 14. Burton B. A.. Araeon R. W.. Bailev S. A.. Koehler K. D. and Maves L. A.. The reusable software librarv. IEEE Software 25-33 (JuTy 1987). . 15. Arnold S. and Stepoway S., The reuse system: cataloguing and retrieval of reusable software. Tutorial: Software Reuse: Emerging Technology. IEEE Computer Society, EH0278-2, pp. 1388141 (1988). 16. Wood M. and Sommerville I.. An information retrieval system for software components. SIGIR FORUM 22, 1 l-28 (Spring/Summer 1988). 17. Carroll J., Singer J. A., Bellamy R. and Alpert S., A view matcher for learning Smalltalk. Proc. CHI’90, Seattle, Wash. (1990). 18. Cunningham W. and Beck K., A diagram for object-oriented programs. Proc. OOPSLA’86, pp. 361-367 (1986). 19. Kaehler T. and Patterson D., A Taste of Smalltalk. Hayden, N.J. (1986). 20. Singley M. K. and Carroll J. M., Minimalist planning tools in an instructional system for Smalltalk. Proc. INTERACT’90 Cambridge, U.K., pp. 9377944 (1990). 21. Carroll J. M., The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill. MIT Press, Cambridge, Mass. (1990).
FINDING
Copyright
REUSABLE
COMPONENTS
for Information
0360-1315/93 $6.00 + 0.04 1993 Pergamon Press Ltd
IN SMALLTALK-
Lr
YIBING
Centre
0
Technology in Education, Institute of Educational University. Milton Keynes MK7 6AA, England
Technology,
The Open
Abstract-Smalltalkis an object-oriented programming system. It promotes the “programming by reuse” approach. Programmers use existing programs to construct new ones. However, in Smalltalk, non-expert users have difficulties in finding reusable components. In this paper, the causes of this problem are analysed and a tool developed to help non-expert users overcome this problem is described. With this tool, users can query the system to get the information they require and their navigational difficulties are significantly reduced.
INTRODUCTION
Object-oriented programming exploits multiple representations of information and is particularly suitable for simulation. In addition, object-oriented programming languages allow an easy correspondence between a real world object and a data process object. For these reasons, the object-oriented programming paradigm has become increasingly popular and has attracted interests in the computer assisted learning community. Smalltalk is not only a pioneer of object-oriented systems, but is also the most uniform system, since it is based on the single paradigm of objects. It is an interactive system and has a powerful set of tools as well as a large library of components which can be used to build graphical interfaces. This system has been used to develop educational software to facilitate learning (e.g.[l-31). However, it has been reported[4] that non-expert users have difficulties in learning and using Smalltalk. One problem which we shall discuss below is that users have difficulties in finding required components in their programming. An important aspect of the object-oriented programming paradigm is that it promotes the “programming by reuse” approach [5] (here only reuse of code is considered). Programmers do not always have to code from the beginning; they use existing components as the basis of new programs. Smalltalk(abbreviated to Smalltalk) has a large components library and reuse of existing components, classes and associated methods, is the recommended programming style. The reuse approach seems promising for improving the efficiency of the code production. However, reuse is not without cost. Biggerstaff and Charles[6] suggests that in order to reuse software successfully, a system must address the following fundamental problems: finding components understanding components modifying components and composing components, Among these problems, being able to find required components efficiently is a prerequisite to success. This is because to reuse components, users must know what components should be used and where they can find them in the system. In Smalltalk, finding the required components is not easy for non-expert users. An empirical study [4] shows that this is one of the main factors affecting the learnability and usability of this system. In this paper, the causes of this problem are analysed and a tool is described to help users overcome the difficulty. The term ‘users’ here refers to the non-expert users. Although the tool is developed for Smalltalk, the idea is directly applicable to other object-oriented systems.
THE
CAUSES
OF
THE
PROBLEM
The problem of finding required components in Smalltalk is exacerbated by the size of the system. Smalltalk has over 250 classes and more than 3000 methods. In such a large system, finding required 63
64
YIBING LI
classes or methods is no easy task for users. The system must provide users with supporting mechanisms. The System Browser of Smalltalk is a tool which allows users to access classes and methods but it only allows users to access them according to their names. As non-expert users usually have only a limited knowledge of the system’s terminology and structure, there is a great vocabulary barrier[7]. Since names of the components do not always convey enough information, users would have difficulties in finding the necessary components. They sometimes have to choose a wider range of components and study their functions in detail, often by reading the implementation code. The code to perform certain functions is usually distributed among many classes. Therefore users need to gather all pieces of relevant code from different classes to form a complete picture about how a function is performed. Moreover, the task of understanding the execution of a given function is made more difficult by the polymorphism and dynamic binding of Smalltalk which make it difficult to understand which method is being executed during a computation. As a result of these difficulties, users sometimes find themselves in a situation where they either overlook the relevant components or after making considerable efforts in studying a particular set of components, realize that those components are in fact irrelevant to their tasks. Although the above discussion is mainly based on Smalltalk, it is also applicable to other object-oriented programming systems. Because of the ease of adding new objects into systems, object-oriented programming systems tend to encourage large libraries of components[8]. At a certain stage, users will have similar problems to those discussed in relation to Smalltalk. It is essential therefore for these systems to provide supporting tools to help users find reusable components and reduce their difficulties. Existing tools, such as the System Browser in Smalltalk, are useful but not sufficient. It is necessary to develop other tools.
THE
PROPOSED
SOLUTION
The proposed solution to the problem discussed above is to augment the System Browser of Smalltalk with a query tool. When users give a description of their target components, the tool would provide the users with a list of candidate components whose functions match their description. Users may then choose the components they require from this list. Such a tool reduces users’ search space, since they only need to study the relevant components. Therefore users are saved the time and resources wasted on studying irrelevant components and their navigational difficulties would be greatly reduced. Based on this idea, we have developed a tool BRRR (BRowser for Retrieval by Reformulation) for a subset of Smalltalk’s components. The details of BRRR will be described in the following sections. One point to note is that although the kind of tool we proposed aims mainly at helping non-expert users, it also has the potential to help expert users. Object-oriented programming systems are usually large. It has been suggested that with very large software systems, there are few experts who have a complete mastery of all components[9]. Expert users would therefore benefit from this tool when they need to use components in the system with which they are not familiar.
AN OVERVIEW
OF BRRR
BRRR comprises two parts: the software component. library and the user interface. It is designed to facilitate the process of constructing a query. Users start the retrieval in BRRR by entering an initial query into the system. BRRR presents a list of classes or methods which match the initial query. The description of one of the matched individuals, the example instance, is shown to users. Users may examine the example instance and modify the initial query by selecting information embedded in the description of the example instance. This modified query may be used to retrieve a new set of matches and a new example instance. The query can then be further refined based [IO] is repeated until on the new information. This process, known as “retrieval by reformulation” users are satisfied with the result or until it is established that there is no item in the system satisfying users’ requirements.
Reusable THE
components
COMPONENT
in Smalltalk-
65
LIBRARY
In Smalltalk, the basic reusable components are classes and associated methods. Related classes are grouped together into class categories (see Fig. 1). In this system, a class can belong to only one category. This organization has a drawback. If users do not follow the system designer’s classification, then they may not be able to identify the category which contains the classes they need. In BRRR, classes performing similar functions are grouped together into one category and some categories may have sub-categories. An example of this classification for part of the Collection classes is illustrated in Fig. 2. In this classification scheme, a class may belong to more than one class category. For example, in Fig. 2, the class Dictionary belongs to both the category: Arbitrary-keyed and the category: Unordered. By allowing a class to belong to more than one category, the probability of finding it is increased. In Smalltalk, each class has a number of methods associated with it. Related methods within individual classes are grouped together into method categories. Each method belongs to only one method category (see Fig. 3). In BRRR, all methods associated with the classes within a class category are classified into different method categories. The methods which have similar functions are grouped into a category. Some method categories, similar to that of the class categories, may have sub-categories. Each method belongs to one or more categories. Taking the Collection classes as an example again, all instance methods in all Collection classes are grouped into the following method categories, some of which are shown in Fig. 4: adding; accessing; removing; enumerating; testing; copying; converting. The method category: accessing, for example, includes all methods elements in collections. This category has three sub-categories:
in collection
classes for accessing
querying-elements/parameters; finding-index; replacing-elements. The category: querying-elements/parameters contains methods which are used to query elements or parameters in collections. Some of the methods in the category are: size in class size in class at: anlndex the position
values of
Array returns the storage space of the collection. OrderedCollection returns the number of the elements in the collection. in class SequenceableCollection returns the element of the collection which is at specified by an integer index represented by the argument anlndex.
Associated with each method category is a set of attributes the methods in the category. Each method in a category
SortedCollection Fig. 1. The class classification
MappedCollection
w
which characterizes the functions of has values corresponding to those
IdentityDictionary
IdentitySet
in Smalltalk for a subset of the Collection classes. The root nodes are class categories and the leaf nodes are classes.
YIBING LI
66
/
Array
Interval SortedCollection
OrderedCollection Fig. 2. Class classification
IdentityDictionary
for a part of the Collection classes in BRRR. categories and the leaf nodes are classes.
attributes according to its function. on the following criteria: the the the the
LinkedList
The designation
of the attributes
The non-leaf
IdentitySet
bg
nodes are class
to a method
category
is based
operation that methods in the category perform; action for handling exceptional situations; objects these methods manipulate; objects produced as a result of the operation.
The method
category:
replacing-elements,
for example,
has attributes:
operation; object-replaced; position-in-the-receiver; object-returned. One method in this category is atAll: anInterval put: anobject in the class SequenceableCollection. Its function is to put the argument: anobject at every index specified by the integer elements an Interval. It is described as follows: Operation: Object-replaced: Position-in-the-receiver: Object-returned: For the category:
replace multiple-elements positions-specified-by-an-interval receiver
adding, the attributes
are:
operation; elements-added; position-in-the-receiver; objects-returned.
size Fig. 3. The method
first
classification in Smalltalk for the class OrderedCollection. The nodes in the middle of the tree are method categories and the leaf nodes are methods.
of
Reusable components in Smalltalk-
at: ifAbsent: (Dictionary) Fig. 4. The method classification in BRRR. The text in parentheses are names of the classes with which the methods are associated.
A method in this category is add: anobject in the class SortedCollection. Its function is to add an object into a sorted collection. The operation is performed according to a sorting algorithm so that all elements in this collection will be automatically ordered according to their values. Its description is: Operation: Object-added: Position-in-the-receiver: Object-returned:
add one-element positiondetermined-by-the-receiver’s-sorting-rule anElement.
In the case of one method belonging to more than one category, the method would have the sum of all the attributes that it possesses in each category.
QUERY
AND
RETRIEVAL
IN BRRR
The interface
BRRR’s interface consists of three main windows: the class level query window (see Fig. 5) the method level query window (see Fig. 6) and the trace window (see Fig. 7). The class level query window has five panes: Class Category Hierarchy pane; Class Query pane; Matched Classes pane; Method Categories pane; Example pane. The Class Category Hierarchy pane illustrates the hierarchical structure of class categories. This is to help users comprehend the overall structure of the component organization. The Class Query pane contains users’ queries about the classes for which they look. The Matched Classes pane displays all classes which match a class query. The Method Categories pane shows the method categories in a class which is selected by users. The Example pane presents a description of one of the matched classes. The description includes class categories to which the class belongs and a comment describing the function of the class. The method level query window has a similar structure to that of the class level query window. BRRR also has a browsing capability, it allows users to select any class (or method) which appears in the Matched Classes pane (or the Matched Method pane in a method level query window) to examine its relevance. However, one problem is that users may not remember which class (or method) they have examined before. Therefore BRRR provides a Trace window which shows users the components they have inspected before to reduce users’ navigational overheads.
68
YIBING
LI
Class Category Hierarchy
Class Query
Matched Classes
Method Categories
OrderedCollection LinkedList
Collections Keyed Integer-keyed
adding accessing COPyi% enumerating testing
with method attributes: Operation: add Objects-added: one-element Position-in-the-receiver: end Object-returned: anElement I
Explain
I
Example p
Collections Keyed Integer-keyed
Require-this-category
-
Prohibit-this-category Show-allclasses
OrderedCollection Class OrderedCollection represents a collection of elements explicitly ordered by the sequence in which objjts are added and removed. Elements are accessible by external keys that are indices. Fig. 5. The class level query window.
Query construction
A query in BRRR is constructed in two steps: the class level query and method level query. They are described in turn in the following sections. The class level query. Users start a query by first using the class level query window. They create an initial query by using the class categories in the Class Category Hierarchy pane. They can click on a class category in which they believe the required classes to be and then manipulate the category with options appeared in a pop up menu. The menu options are: Require-this-category; Prohibit-this-category; Show-classes; Explain.
The Require option adds the category into the class query; the Prohibit option applies the relative complement of the category to the class query. The Explain option gives a text explanation about the characteristics of classes in the category. The Show-classes option shows users the names of the classes in this category and provides a preview. Users should comprehend the meaning of a category better by seeing the items contained in it. Once an initial query is constructed, users can request BRRR to perform a retrieval. The system retrieves all classes which belong to the required class categories but do not belong to the prohibited categories. The result is then shown to the users. The description of one of the matched classes is displayed in the Example pane. One purpose of the Example pane is to provide users with a concrete example of the components which match the current query. It tells users the system’s understanding of their query. In addition, the description of the example instance supplies the users with information necessary to reformulate the partial query. The users can use the information provided in the description of the example instance to refine the initial query. They can use the
69
Reusable components in SmalltalkMethod Category Hierarchy
Method
Matched Methods
Query
adding position-relevent Operation: add Object-added: one-element Position-in-the-receiver: positiondetermined-by-the-receiver’s-sorting-rule Object-returned: anElement
Explain
add: (SortedCollection)
Example adding position-relevent add: newObject (SorteredCollection) “I add an element newObject into the receiver and put it at the position determined receiver’s sorting rule. ” Operation: Objects-added: Position: Object-returned:
add one-element positiondeterminded-by-the-receiver’s-sorting-rule anElement Fig. 6. The method level query window.
Trace .~ .,...,,,,. ~~~~~~~~~~~~~~~
SortedCollection
Bag bay Dictionary Set
collections Keyed Integer-keyed Arbitrary-size Class OrderedCollection represents a collection of elements which are ordered explicitly by the sequence in which they are added or removed. Elements of it are accessible by external keys that are indices. Fig. 7. Trace window.
by the
YIBING LI
70
class categories shown in the descriptions of the example instance (the boldface words in Fig. 5) in the same way as that used in the Class Category Hierarchy pane. The method letlel query. After several cycles of class retrieval, users would be shown a list of classes. However, it is likely that users still do not know which class to choose and they are not certain which class category to select either. At this stage, they can study the functions of the matched classes by examining the methods associated with them. This is because the function of a class is more fully specified by its methods. In addition, users can further refine the current class query by constructing a method level query. From the Method Categories pane in the class level query window, users can select a method category and initiate a method query. A method level query window would subsequently be open. The relationship between the selected method category and its sub-categories would be illustrated in the Method Category Hierarchy pane (see Fig. 6). Query and retrieval processes in this window are similar to that of the class level. To compose an initial method query. users select a method category and manipulate it in much the same way as in the class level query. In the Example pane of the method level query window, the description of an example method comprises: the method a comment the method
categories describing descriptors
to which this method belongs; the function of the method; (i.e. the attributes and their corresponding
In addition to manipulating the method options to manipulate the attribute-value
values).
categories in the Example pane, users can use a set of menu pairs to modify the partial method query. The options are:
Require-this-value; Prohibit-this-value; Alternative-values. The first two options have similar functions to those of the class query level window. The option: Alternative-values suggests a set of alternative values to a value of an attribute. For example, for the add: method in the class OrderedCollection, the value of the attribute Position-in-the-receiver is end. which means every time this method is used, the element added is put into the last position of an OrderedCollection. Users may, however, intend to find an adding method such that it adds an object into a collection and the added element should be ordered according to its value. In this case they can use the Alternative-values option to get a list of other values, among them, the value: “position-determined-by-the-receiver’s-sorting-rule”, which would be the appropriate one to choose. When users request the system to do a method retrieval, the system will retrieve the methods which satisfy the following conditions: (1) They must be methods of one of the matched classes. (2) They must belong to the required method categories but not belong to the prohibited (3) The values of the attributes must be the same as those in the query.
ones.
After the system performs a method retrieval, users may merge the method query into the Class Query pane. This allows a request to the system to find classes which contain those methods. Users may repeat the same process until they find the satisfactory classes. In BRRR, query is constructed mainly by selecting the descriptors (categories, attribute-value pairs, etc.). Users do not need to remember their names. This should reduce users’ learning overheads and should be particularly helpful for the non-expert users. The descriptors which appear in both the class and method query panes are implicitly connected by the logical operator ‘and’. The prohibited descriptors are in the form of ‘not’. Currently, BRRR only has a limited capability to process the ‘or’ operation. Given the above description, it is not difficult to understand the meaning of the query appearing in the Class Query pane of Fig. 5. The query requests the system to retrieve the classes which are: Collection classes; classes which should
be accessible
by a key;
Reusable
components
in Smalltalk-
71
classes which should have integer keys; classes which should have methods which can perform an ‘add’ operation and the added single element will be put into the last place of the collection. The methods visible to users In BRRR, only methods which are regarded as ‘public’ are presented to users. The methods regarded as ‘private’ are not shown. This is to provide better support for the concept of data encapsulation. Private methods are only for internal uses and should not be made visible to users. Another feature of BRRR is that all methods of a class including those inherited from its super classes are shown to users. In Smalltalk, classes are organized into a hierarchy. An object inherits all methods of its super classes. The System Browser only shows users methods explicitly defined in a class. To find the inherited methods, users need to navigate through the hierarchy by following the inheritance chain. This increases the burden of the users. In BRRR, all methods of a class are shown, so users should more easily find all methods of a class. RELATED
WORK
Wu[l l] proposed a browser for object-oriented systems. It has some of the features of BRRR (e.g. showing users all methods of a class; hiding private methods). However, it does not support queries. Prieto-Diaz and Freeman [ 121used principles developed in library science, the facet classification scheme, to design a classification and retrieval scheme for reusable components. Frakes and Nejmeh [13] used keyword search techniques employed in bibliographic databases to retrieve reusable components. Similar work can be found in Burton et al. [14] and Arnold and Stepoway [ 151. These approaches presume users comprehend the meaning of keywords correctly. Consequently, these approaches have the vocabulary problem which we mentioned above. Wood and Sommerville[l6] developed a system based on the principle of conceptual dependency as proposed in artificial intelligence. In the particular field of helping users learn Smalltalk, several attempts have been made. The main approach is that of using a pre-designed tutorial about a subset of Smalltalk, plus the use of a graphical tool to facilitate users to comprehend the functions of these components[l7-191. Singley and Carroll [20] developed an intelligent instructional system employing the minimalist [21] approach to teach novice users Smalltalk programming. However, because the system’s library grows dynamically, the success of these approaches, which rely on pre-designed materials, is seriously limited. CONCLUSION A prototype of BRRR has been implemented in Smalltalkon a Macintosh IIcx. So far, we have only chosen to experiment with the Collection classes of Smalltalk. We believe that this selection is complex enough to reflect the typical situation where users need help in finding information from the system. Presently, BRRR cannot process the components defined by users. However, the framework of BRRR is flexible enough to be extended to deal with such a situation. For example, users may choose one of the class categories to put a new class under it. They may then retrieve one of the existing methods as a template, input the appropriate values for the attributes and subsequently store them. The newly added components would then be treated equally as the existing ones and ready for further retrieval. BRRR is yet to be integrated with the original Smalltalksystem. Currently, we are evaluating BRRR with users. The result is expected to be reported in the near future. Acknowledgements-I would like to thank Tim O’Shea, Steve Cook, Randall Smith, Alan Borning, and Pat Fung for helpful advice and Benedict Heal, Mike Brayshaw, Royston Sellman for constructive discussions during this project. I am grateful to Pat Fung for critical comment to drafts of this paper. The author is supported by an Open University research studentship.
72
YIBING
LI
REFERENCES I. Borne I. and Girardot C., Object-oriented programming in the primary classroom. Computers Educ. 16,93-98 (1991). 2. Smith R. B., The Alternate Reality Kit: an animated environment for creating interactive simulations. Proc. IEEE Workshop on Visual Languages. IEEE, Washington (1986). 3. Twigger D., Byard M., Draper S., Driver R., Hartley R., Hennessy S., Mallen C., Mohamed R., O’Malley C., O’Shea T. and Scanlon E., The ‘conceptual change in science’ project. J. Comput. Assisted Learning 7, 144-155 (1991). 4. O’Shea T., Why object-oriented programming is hard to learn. Human Compurer Interaction. In press (1993). 5. Meyer B., Reusability: the case for object-oriented design. IEEE Software 4(2) (March 1987). 6. Biggerstaff T. and Charles R., Reusability framework, assessment, and directions. In SoftWare Reusability Vol. I Concepts and Models (Edited by Biggerstaff T. and Perlis A.), pp. l-7. Addison-Wesley, New York (1989). 7. Furnas G. W., Landauer T. K., Gomez L. M. and Dumais S. T., The vocabulary problem in human-system communication. Commun. ACM 30, 964-971 (1987). 8. Halbert D., Learnability of object-oriented programming systems, Proc. OOPSLA’86, Oregon, pp. 503-504 (1986). 9. Draper S. W., The nature of expertise in UNIX. Proc. INTERACT’@, Amsterdam, pp. 182-186 (1984). IO. Williams M. D., What makes RABBIT run? Int. J. Man-Machine Stud. 21, 333 -352 (1984). 11. Wu C. T., A better browser for object-oriented programming. J. Object-Oriented Programming 22-28 (November/December 1990). 12. Prieto-Diaz R. and Freeman P., Clasifying software for reusability. IEEE Software 4, 616 (1987). 13. Frakes W. B. and Neimeh B. A., Software reuse through information retrieval. Proc. 12th Annual Hawaii hf. ConJ on System Science, Hawaii, pp. 530-535 (1987). 14. Burton B. A.. Araeon R. W.. Bailev S. A.. Koehler K. D. and Maves L. A.. The reusable software librarv. IEEE Software 25-33 (JuTy 1987). . 15. Arnold S. and Stepoway S., The reuse system: cataloguing and retrieval of reusable software. Tutorial: Software Reuse: Emerging Technology. IEEE Computer Society, EH0278-2, pp. 1388141 (1988). 16. Wood M. and Sommerville I.. An information retrieval system for software components. SIGIR FORUM 22, 1 l-28 (Spring/Summer 1988). 17. Carroll J., Singer J. A., Bellamy R. and Alpert S., A view matcher for learning Smalltalk. Proc. CHI’90, Seattle, Wash. (1990). 18. Cunningham W. and Beck K., A diagram for object-oriented programs. Proc. OOPSLA’86, pp. 361-367 (1986). 19. Kaehler T. and Patterson D., A Taste of Smalltalk. Hayden, N.J. (1986). 20. Singley M. K. and Carroll J. M., Minimalist planning tools in an instructional system for Smalltalk. Proc. INTERACT’90 Cambridge, U.K., pp. 9377944 (1990). 21. Carroll J. M., The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill. MIT Press, Cambridge, Mass. (1990).