Introduction and Basic Concepts
Software reuse is the use of existing software or software knowledge to construct new software. Defined in this way, it is clear that reuse is a good idea, and that ad hoc software reuse has been practiced from the earliest days of programming. Programmers have always reused sections of code, templates, functions, and procedures. Software reuse as a recognized area of study in software engineering, however, dates only from 1968 when Doug McIlroy of Bell Laboratories proposed basing the software industry on reusable components.
Since then, many papers have been written on software reuse, and organizations have spent much time and money attempting to implement reuse. Most organizations want to implement systematic reuse programs. A systematic reuse program focuses on reuse of higher level lifecycle objects such as domain based product line architectures. The final goal is to ingrain reuse into an organization’s entire software production process.
Organizations are investing significant resources in reuse to achieve one or more of the following benefits:
- Improved productivity — If you write less of a system from scratch, it should require less resources.
- Improved reliability – If you build your system out of reusable parts that have been rigorously tested and verified, your system should be more reliable.
- Better bid estimation – If you know more about a system because a significant portion of it will be built from reusable parts, you should be able to bid more accurately.
- Better early estimates – If you know more about a system because a significant portion of it will be built from reusable parts, you should be able to do more accurate early estimates of needed resources.
- Faster time to market – Increased productivity will allow faster time to market for a product.
Industrial data indicates that significant quality and productivity improvements can be achieved from successful reuse. Reuse payoffs from organizations that have formally described their business domains and built generators capable of producing significant parts of new systems can achieve higher reuse payoffs.
Factors affecting reuse
To achieve these benefits, a systematic reuse program must address several kinds of issues.
Technical – Currently there is much attention given to technical issues, in areas like support environments.
But there is not enough attention being paid to other important issues like:
Managerial – How does one organize a software engineering environment to promote and reward reuse? An example of a managerial variable might be employee economic incentive to create reusable parts, expressed in dollars.
Economic -This deals with our ability to find out whether reuse will pay off financially. How does one create economic viability for software reuse? An example variable might be level of payment for creators of commercial parts repositories.
Legal – How does one legally protect the rights of creators and consumers of reusable software? A variable here might be whether a law limiting part supplier liability is in place.
Domain Engineering (aka Product Line Engineering)
A key concept in systematic reuse is the domain, a software business area that contains systems sharing commonalities. Most organizations work in only a few domains, repeatedly building similar systems with variations to meet the needs of different customers. Rather than building each variant system from scratch, as is often done today, significant gains are achievable by reusing large portions of previously built systems in the domain to construct new ones.
The process of identifying domains, bounding them, and discovering commonalities and variabilities among the systems in the domain is called domain analysis. The entire process of reusing domain knowledge in the production of new systems is called domain engineering or product line engineering.
Types of reuse
There are two basic technical approaches to reuse – parts based and formal language based. Parts based reuse is done by incorporating reusable parts into an application. Some common types of reusable parts are FORTRAN subroutines, C functions, Ada packages, C++ and Java objects,and interacting collections of objects called frameworks. Work has also been reported on reusable processes and on high level problem solving methods called design patterns. There are four ways of getting reusable parts; they can be designed from scratch, re-engineered from existing software, purchased in a growing reuse marketplace, or obtained from a freeware source such as the Free Software Foundation.
The other technical approach to reuse is to embed the reusable information into a generative or formal language environment. This can be a complete programming language. The SPSS language, for example, is a programming language that provides constructs from the statistics domain. Snobol is a language that provides text processing constructs, and so on. Little languages are small domain specific languages developed for a narrow problem domain.
Another formal language method is to build an application generator. The generator contains knowledge about a domain, and generates systems in that domain based on a high level specification. Lex and Yacc in the UNIX environment are well-known application generators for lexical analysis and parsing. Metacompilers are tools that help with the construction of application generators.
More information on software reuse, domain engineering, and product line engineering can be found at the ReNews website.