Software reuse can be defined as all activity that has using previously written software ( in the form of specification, design, code, or related texts) as its goal. Reuse is a matching between new and old contexts. Whenever matching succeeds partially or completely,reuse is possible.
Software reusability is the quality of a piece of software that enables it to be used again in another application, be it partial, modified or complete. In other words, software reusability is a measure of the ease with which previously acquired concepts and objects can be used in new contexts Software reuse is not only about the re-application of a software component in another context or environment, it is also about the reuse of knowledge. This knowledge can include mathematical, engineering, and any other competencies that were needed for the construction of the reused software.
Two basic reasons for software reuse are:
• Increased productivity. If the emphasis is on production speed and minimizing cost/effort, then being able to plug-in a collection of ready-made parts will be of great help. There is a reduction in the need for software design, implementation, testing, and documentation.
• Increased software quality. If the emphasis is on quality, then it will be advantageous if one has access to well-designed, well-tested, and well-documented code that has a proven correct and well-understood behaviour.
In order to increase productivity and quality, a programmer or (virtual) organization ideally constructs a piece of software once, verifies that it functions correctly and efficiently, and then reuses it as many times as possible in a variety of applications. In an environment where large-scale (international) software projects are carried out and multiple development projects exist at the same time, careful collaboration is needed to consider the possibilities for reuse.
Nevertheless, despite the above considerations, reuse of software happens all the time. Especially if one considers that writing programs in a high-level language involves reusing language constructs and definitions, standard libraries, low-level program generators (compilers), the operating system, etc. Appropriate questions are therefore: What forms of reuse are there? What is it that we are reusing? How can we promote reuse in all its forms? Reusable software is software (specification, design, code, etc.) made with reuse in mind. Planned reusable software may need upfront significantly extra investments and time to create while only at a later stage benefits can be reaped.
Development for reuse
Reuse impacts the software development process in two distinct ways:
1. Development with reuse.
Software design takes place in an environment where a significant number of potentially reusable components are available. It is an existing form of software reuse practice. An example of this kind is UNIX environment. The objective is to produce a software product. Reusable components are produced as a ‘side-effect’ of normal systems development. We have to put more effort to reuse these components because they are not made for reuse. During the past years of active research on reuse, most emphasis has been given to development with reuse. As a result, there is no large body of components, except in specific domains such as mathematical libraries, which have been generalized for reuse.
2. Development for reuse
An objective of the design process is to produce components which are potentially reusable. They should be easy to reuse because they have been designed for reuse. These components form building blocks for future development (over the long term) and are applicable for various situations and perhaps across application domains. They are generalized for reuse which means improved benefits such as quality, reliability, faster production, lower cost and greater pay-off over long-term reuse. But, extra cost and effort are involved to create potentially reusable components. Of course, these different modes of design are not mutually incompatible and design of components with reuse may result in new, potentially reusable components.
In development with reuse, the principal objective is to produce a software product. Reuse is desirable but there need be no resources expended in creating new reusable components. Development for reuse implies expending resources specifically to increase the reusability of components. In many cases, this process might follow development with reuse where components generated during normal system development are made more reusable by generalization and improvement.
In the development for reuse process, as shown in Figure (1), there are a number of stages to be followed which start from identifying an application domain, identify & classify reusable abstractions, language-oriented reuse, domain-oriented reuse, design components, assessment for reuse, improvement for reuse, and deliver potentially reusable components.
This development for reuse process falls into a number of stages.
1. Identify domain. Domain analysis has been identified as essential for effective reuse. The first step is to identify a specific application domain and define its boundary.
2. Identify and classify (frequently) reusable abstractions. To identify potentially reusable components, the reuse assessor must know what the important domain abstractions are and how frequently these abstractions are used in systems developed for that domain. There is not much point in devoting a lot of effort in producing a reusable domain abstraction if that abstraction is rarely used. Domain classification helps to identify effective reusable abstractions.
3. Identify design/ programming language constructs that support reuse. Selecting an appropriate language is an important part of development for reuse. We should be able to express our reuse guidelines effectively using language mechanisms.
4. Study and formulate language reuse guidelines (rules concerning language support for reuse). This emphasizes the effective use of language features for reuse. This process includes studies of existing techniques and appropriate modifications to them.
5. Study and formulate domain reuse guidelines (rules concerning the domain characteristics for reuse). This emphasizes the reusable domain abstractions that are identified in the application domain. Guidelines should not just be general advice but should be specific and verifiable for creating potentially reusable components. Design/ redesign components based on these guidelines.
6. The next step, known as reuse assessment is a process of assessing components based on the number of guidelines satisfied against the total number of guidelines that are applicable, and then produce an assessment report. This is where we need to automate this process. The outcome of this process is to make sure that the components designed for reuse satisfy some of the key characteristics.
7. The final step, known as reuse improvement is a process of modifying and improving these components for reuse by adding attributes of an abstraction for reuse. This process is based on the assessment report produced during the previous step. The reuse improver must know what attributes of an abstraction must be generalized to make it reusable. Again, an automatic reuse improvement is essential. Finally, produce potentially reusable components.
8. Automate, where possible, these two processes of assessing and improving components for reuse.
It is unrealistic to expect reusable components to be produced as a side-effect of normal systems development. The reasons for this are partly technical and partly managerial. Technically, the notion of what constitutes a reusable component is not well-understood and engineers working on a project cannot be expected to wrestle with this problem while developing to a given set of requirements. Furthermore, the requirements for a particular project may be such that components have to be very specific in order to satisfy them.
Furthermore, a project manager’s principal responsibility is to deliver the required software system on time and within budget. Creating reusable components requires additional effort to be expended which is of no immediate benefit to that project. The project manager cannot reasonably be expected to give reusable component production a high priority.
Thus, we believe that the normal mode of production of reusable components should be to take existing components and to add reusability to them. This extra cost for reuse must be an organizational rather than a project responsibility. Reusability is an attribute which can be added at any level from the specification through to the implementation. In our work, we are principally concerned with the reusability of compilable components. However, we believe that the approach discussed is equally applicable to formal specifications and software designs.
Reusability is a complex component attribute and it is dependent on the effective use of the programming language used to implement the component and application domain knowledge. Application domain knowledge allows the abstractions in a domain to be identified and encoded as a set of reusable components. The objective of our work is to use language and domain knowledge to assess, with automatic assistance, the reusability of a component and to suggest to the software engineer how that component may be made more reusable.
Finally we can say that re-usable components can be produced and re-engineered in a large scale if we can formulate objectives, plan according to some considerations and apply them systematically. Domain analysis can play a major role in supporting development for reuse in the near future.