Reuse contract extractor for Smalltalk

Contents:
Last revision: October 18, 1996
We have developed a tool to extract reuse contracts from Smalltalk class hierarchies. Classes contain much more information than we like to lay down in a reuse contract. Since one cannot assess which information is important and which is not, more information is extracted than one would put in a reuse contract written from scratch. But the extracted reuse contracts, although rather large, give a good indication of the several basic operations you perform in one subclassing step. You can also use the extracted information to examine a class hierarchy. Design breaching reuse operators give an indication of possible problems in the hierarchy.

The extractor at work

The figure below gives an overview of the reuse contract extractor.

extractor

The two lists in the top-left corner are the same as in the Smalltalk browser. Use them to select a class.
When a class is selected, the extractor is put to work. It extracts the reuse contracts corresponding to the selected class and all its superclasses. It also extracts the increments between two classes in the inheritance chain, the so-called modifiers. The modifiers and the reuse contracts are listed in the bottom-left corner of the window. A reuse contract has the same name as the class from which its was extracted. Reuse contracts are listed by their boldfaced name, while modifiers are listed by type (one of the six reuse operators).
When a reuse contract is selected, its specialisation interface is shown in the list in the top-right corner. A specialisation interface has two parts: abstract and concrete (the so-called annotations). Each part lists method signatures together with their specialisation clause between braces (the self sends invoked in the method's body). Note that all self sends are shown in the specialisation clause of a method, since the extractor has no way of knowing which self sends are important for the design of a class and which are not. Extraction is purely based on inheritance relationships and syntactic information in method bodies.
When a modifier is selected the specialisation interface section of the window should be interpreted in a different way, as is explained in the next section.
When a method is selected, its specialisation clause and its body are displayed in the bottom-right corner. The body of a method is only shown when the class, corresponding to the selected method, actually implements that method.

The extractor is an inspector, not a browser. One cannot edit the displayed information.

Examining a Class Hierarchy

By inspection of the extracted modifiers one can easily examine a class hierarchy. The figures below explain how the modifiers should be interpreted.

Note that, in general, multiple reuse operators are performed in one subclassing step. You will see that several combinations of reuse operators appear frequently:

Refinement Modifier

Coarsening Modifier

Extension Modifier

Cancellation Modifier

Concretisation Modifier

Abstraction Modifier

Spotting Bad Designs in a Class Hierarchy

Problems often arise when design breaching reuse operators are applied. As an example we have selected a class chain from the Stream hierarchy. After extracting the reuse contracts and the modifiers for this hierarchy, we see a few peculiarities. In the figure below, we took a closer look at the #next method.

Problems in the Stream hierarchy