Evaluating Design by Reusability

Robert Biddle and Ewan Tempero
Victoria University of Wellington, New Zealand
robert,ewan@mcs.vuw.ac.nz http://www.mcs.vuw.ac.nz/comp/Research/renata/

Introduction

What is good software design? Ultimately, it is design that facilitates working with the software. For end users, the interface and behaviour are paramount. For programmers, the implementation is also of critical importance. In this paper, we wish to focus on the programmer's viewpoint. Many aspects of design are important in software implementation, and some are common concerns of every programmer. For example, programmers quickly learn the importance of software being easy to create, easy to understand, effective, and efficient.

We believe there is another fundamental aspect of good design: software should be reusable. This aspect of design looks to the longer term, and facilitates programmer productivity. However, reusability is a practical and objective quality, making it useful to consider in selection or evaluation of design alternatives.

In this paper, we discuss our approach to exploring reusability for evaluation of software design. Firstly, we review our understanding of how programming languages support reusability. We studied specific languages in the structured and object-oriented paradigms, and developed a conceptual model to document the general principles involved. Secondly, we briefly explain how these these principles assisted our teaching, by enabling us to show how reusability could help in design and in design evaluation. Thirdly, we introduce our more recent work on developing programming tools designed to explicitly support understanding issues involving reuse and reusability.

Modeling Reusability

Our model focuses on units of reuse, which we call assemblies. An assembly is anything that may ultimately become valid source code. This includes simple entities such as functions, classes, or modules, but also more complex entities such as all public methods of a class, or parts of a macro definition.

Our model is intended to reflect the arrangement of assemblies depicted in figure 1. On the left of the figure, two assemblies are related in that at some place or places one uses or invokes the other. The effect is as if the second assembly has somehow been inserted into the first. In such situations, we call the invoking assembly the context and the invoked assembly the component.

Each different context that invokes a component represents a use or reuse of the component. For example, a function may be called from different places. We call this component reuse. Furthermore, each different component that is invoked by the same context, as shown on the right of the figure, represents a use or reuse of the context, or context reuse. For example, in object-oriented languages, one message send may result in different methods being invoked via polymorphism.

**Figure 1:** Component Reuse, as shown on the left of this ``jigsaw'' diagram, involves several different contexts invoking the same component. Context Reuse, as shown on the right of the diagram, involves one context invoking different components using the same interface.
$\begin{figure} \epsfxsize 70mm \centerline{\epsfbox{both-reuse.eps}} \end{figure}$

The main goal of developing our model was to understand what features of an assembly improve or reduce the likelihood that that assembly will be reused, that is, what features improve or reduce the assembly's reusability.

When a context invokes a component, it has expectations as to what the component does. Similarly, the component has expectations as to how it will be invoked. We call these expectations dependencies, and they are the fundamental low-level concept of our model. Dependencies can adversely affect the reusability of a segment of code, because they limit the number of contexts than can invoke it, or the number of segments it can invoke. However, there are dependencies that are beneficial to reusability, by allowing generality and checkability. For example, dependence on parameters makes assemblies more general and so more reusable, and dependence on types makes assembly invocation easier to check.

The concepts of assembly, context, component, and dependency are the foundation of our model; more detail is available elsewhere [BT96c,BT96b]. According to the model, reusable software involves assemblies that can be reused as components or contexts, with minimal dependencies, save those that allow greater generality or checkability.

A programming language can support the implementation of reusable software with features to allow component and context reuse, assist the programmer to identify and avoid dependencies, and allow generality and checkability. For example, this would include such language concepts as encapsulation, parameters, type-checking, and so on.

When considering the reusability of an assembly itself, there are two important characteristics that involve the human side of programming more than the technical side. One characteristic is whether or not the assembly is likely to be used again; we refer to this as usefulness. It is usefulness that we promote when doing domain analysis prior to software design; we then design software to consist of assemblies that will be useful in the future.

The other is whether the assembly is easy for the programmer to use, and does not involve too much complexity or obscurity; the issues here are similar to those in user interface design, and so we use the term used in human-computer interaction research: usability.

Together these elements allow us to design for reusability, and to evaluate reusability in design. On the technical side, we look for assemblies that can be used as components or contexts, without dependencies except those involved in generisation or checkability. On the human side, we look for assemblies that are both useful and usable.

Teaching about Design and Reusability

We use our model in our teaching to facilitate explanation of a variety of principles, involving simpler topics, such as procedures, user defined types, or scope, and also more complex topics such as encapsulation, inheritance, and polymorphism [BT98]. For example, we use our model to explain how inheritance differs from composition, because it uses interface conformance to facilitate context reuse, as shown in figure 2. We discuss this in detail separately [BT96a].

**Figure 2:** This jigsaw diagram illustrates how interface conformance makes inheritance different from composition. An ``employee'' class can reuse an existing ``address'' class by composition (top), but composition produces a different interface for employee than for address (see tabs on top part of diagram). However, a ``manager'' class can reuse the existing employee class via inheritance, and have an interface that conforms to the employee class interface (see tabs on bottom part of diagram).
$\begin{figure} \epsfxsize 80mm \centerline{\epsfbox{emp-man.eps}} \end{figure}$

Students learning programming for the first time have difficulty in learning design because they lack experience with the effects of good or bad program design. To address this lack of experience, we harness experience from another domain. The domain we use is audio systems, meaning CD players, tape-recorders, speakers, headphones, and so on. Most students have experience with these systems, and are able to understand the implications of various designs. We establish analogies from principles of audio system design to principles of software design, and then recall them when discussing specific object designs. We explain our approach more fully elsewhere [BT97], but we will explain here how the analogy can illuminate the connection between reusability and good design.

The fundamental level of our software reusability model involves dependencies between segments of code. According to the model, dependencies reduce reusability unless they foster generality or checkability. A favourite example of the utility of the analogy concerns a perennial student design decision. Every year, students design many classes with methods that must make some decision and report the result. Every year, some students print out the result, rather than returning it. Every year, these students resist the idea that returning a result is superior design, because in the instance they are considering, printing out the result is exactly what they want. However, we have had success in asking if they would consider purchasing a cassette player that came only with permanently attached headphones, or permanently attached speakers, or a permanently attached cassette!

We make the point that indeed in some circumstances these might, surprisingly, indeed be justifiable. However, they must consider the consequences of design in light of reasoning on such a basis, considering future reusability as a key way of making design decisions.

Programming Tools and Reusability

**Figure 3:** *An early browser tool diagram, displaying a class featuring both composition and inheritance, showing in particular how inheritance is diagrammatically presented as interface conformance.*
$\begin{figure} \epsfxsize 70mm \centerline{\epsfbox{ev-emp-man.eps}} \end{figure}$

Our more recent work has concentrated on exploration of programming tools designed to explicitly support reusability. There are already tools such as code repository systems that support reuse, but we believe every kind of programming tool has a role to play. Some of our prototype tools concentrate on assisting the programmer to understand the structure of their program from the viewpoint of reusability. Our education work suggests that students need such assistance during program development to keep a focus on how their program design relates to principles of reusability [BMWTV98]. We suspect that similar issues affect programmers in industry, although on a larger scale.

The concepts we want tools to support are those associated with reuse and reusability. Our language model shows that these are: assemblies, context reusability, component reusability, and dependencies. One of our tools addresses static program structure, and so is similar to a CASE tool featuring a class browser, where a diagram representing classes may be used to navigate the program code. However, we have adapted the diagrammatic notation to highlight the interplay of context and component reuse, and dependencies.

**Figure 4:** *A recent browser prototype, showing dependencies between classes. A class list is shown at the left, and at right two trees showing ``depends on'' and ``is depended on by'' relationships.*
$\begin{figure} \par \epsfxsize 90mm \centerline{\epsfbox{browser.ps}} \end{figure}$

The main inspiration for our diagrammatical notation is the pictorial structure shown in the kind of ``jigsaw diagram'' shown in figures 1 and 2, and an early version of our browser diagram, figure 3, shows the resemblance.

A more recent experimental browser is shown in figure 4. This version shows a list of classes in the leftmost column, and there are two tree diagrams to the right. The tree diagrams show dependencies between classes, with the centre column showing the ``depends on'' relationship, and the rightmost column shows the ``is depended on by'' relationship. Each tree diagram can focus on an any class, and the detail can be expanded or contracted as necessary.

This recent browser is designed for Java programs, and the diagrams show every kind of dependency relationship in a Java classes. The dependencies are determined by parsing the Java code itself. The browser can be used to control a source code viewer or text editor. Because inspection and modification of source code often involves moving between classes that are related by dependence, the browser thus facilitates program understanding and modification.

The browser diagrams are generated from the code, and then themselves used to work with the code, so the diagrams and the code are strongly coupled by feedback. In our earlier prototypes, we found that automatic layout of the diagrams assisted this strong coupling, so we abandoned the manual layout typical of CASE tools. As the coupling between the diagram and the code became stronger, we saw signs of a deeper effect. The barriers between program and tool began to diminish: the diagrams seemed to become the code, and the structure of the diagrams began to influence our thinking about the programs. In particular, we found ourselves more aware of the dependencies in any code we create. In this way, the tool leads us to continually evaluate our design for reusability.

Our experience with our prototype tools has been positive, and we are encouraged that such tools really can facilitate programming and good design. It is our hope that these tools will assist students and programmers in understanding the reusability of the software as it is being developed, so blending design and evaluation together.

Conclusions

There are many aspects to good software design, even if we only concentrate on issues involving implementation. In this paper, we have outlined our case for regarding reusability as a promising approach to understanding and evaluating good design.

Unlike many common characteristics of good design, reusability involves the longer term because it concerns productivity. Moreover, our work shows that it is possible to plan for and assess reusability using practical principles and objective criteria.

As we have outlined, the approach can be used to understand issues in programming language design, provide assistance in teaching, and form the basis for improved tool support for the software development process.

Bibliography

About this document ...

This document was generated using the LaTeX2HTML translator Version 98.1p7 (June 18th, 1998)