Software Reuse

([Horowitz 1984], [Prieto-Diaz 1987]).

• Costs should be reduced as the number of components that must be specified, designed and implemented in a software system is reduced.
• It is possible to reuse specifications and designs.
• Reusing the component might require modification to that component and this, conceivably, could cost as much as component development.

Advantages of systematic software reuse:

1. System reliability is increased. It can be argued that only actual operational use adequately tests components and reused components, which have been exercised in working systems, should be more reliable than components developed anew.
2. Overall risk is reduced. If a component exists, there is less uncertainty in the costs of using that component than in the costs of developing it. This is an important factor for project management as it reduces the overall uncertainty in the project cost estimation.
3. Effective use can be made of specialists. Instead of application specialists joining a project for a short time and often doing the same work with different projects, as proposed in [Brooks 1975], these specialists can develop reusable components which encapsulate their knowledge.
4. Organizational standards can be embodied in reusable components. For example, say a number of applications present users with menus. Reusable components providing these menus mean that all applications present the same menu formats to users.
5. Software development time can be reduced. It is often the case that bringing a system to market as early as possible is more important than overall development costs. Reusing components speeds up system production because both development and validation time should be reduced.

While standard subroutine libraries have been very successful in a number of application domains in promoting reuse, systematic software reuse as a general software development technique is not commonly practiced.

Technical and managerial impediments to generalization of systematic software reuse:

1. We do not really know what are the critical component attributes which make a component reusable. We can guess that attributes such as environmental independence are essential but assessing the reusability of a component in different application domains is difficult.
2. Developing generalized components is more expensive than developing a component for a specific purpose. Thus, developing reusable components increases project costs and manager’s main preoccupation is keeping project costs down. To develop reusable components requires an organizational policy decision to increase short-term costs for possible, unquantifiable, long-term gain, and senior management is often reluctant to make such decisions.
3. Some software engineers are reluctant to accept the advantages of software reuse and prefer to write components afresh as they believe that they can improve on the reusable component. In most cases, this is probably true, but only at the expense of greater risk and higher costs.
4. We do not have a means of classifying, cataloguing and retrieving software components. The critical attribute of a retrieval system is that component retrieval costs should be less than component development costs.

Some broad guidelines as to what facilities should be provided are:

1. An operation should be included to create and initialize instances of the abstract type. Creation is sometimes accomplished simply by language declarations but the programmer should not rely on default initializations provided by the implementation language.
2. For each attribute of the abstract type, access and constructor functions should be provided. Access functions return attribute values; constructor functions allow attribute values to be changed.
3. Operations to print instances of the type and to read and write type instances to and from filestore should be provided.
4. Assignment and equality operations should be provided. This may involve defining equality in some arbitrary way which should be specified in the abstract type documentation.
5. For every possible exception condition which might occur in type operations, a test function should be provided which allows that condition to be checked for before initiating the operation. For example, if an operation on lists might fail if the list is empty, a function should be provided which allows the user to check if the list has any members.
6. If the abstract type is a composite type (that is, is made up of a collection of other objects), operations to add objects to and to delete objects from the collection should be provided. If the collection is ordered, multiple add and delete functions should be provided. For example, for a list type, operations should be available to add and delete an element to and from the front and the end of the list.
7. If the abstract type is a composite type, functions to provide information about attributes of the composition (such as size) should be provided.
8. If the abstract type is a composite type, an iterator should be provided which allows each element of the type to be visited. Iterators allow each component of a composite to be visited and evaluated without destroying the structure of the entity.
9. Wherever possible, abstract types should be parameterized using generic types. However, this is only possible when parameterization is supported by the implementation language.