Software Reuse Research: Status and Future

ABSTRACT:

   This paper purpose is to examine “software reuse research, primary research contributions briefly, and unsolved problems, provide pointers to leading publications.”  From  The Eight International Conference on Software Reuse (ICSR8),  selected four papers.

KEYWORDS:

Software Reuse, domain engineering, research, metrics, architectures, generators, finance

INTRODUCTION

Briefly summarizes the software reuse research, discusses significant research contributions and unsolved problems, and provides pointers to key publications. Software reuse is the use of software knowledge or existing software to construct new software. Reusable assets can be either software knowledge or reusable software. The purpose of software reuse is to improve software quality and productivity. Nowadays, people want to build systems that are bigger, more complex, more reliable, less expensive, and then delivered on time, so software reuse is of interest. domain engineering (aka product line engineering) is a key idea in software reuse. (Frakes & Kang, 2005)

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!
Find out more about our Essay Writing Service

Since programming began software reuse has been practiced. In the past twenty years, active areas of reuse research include domain engineering methods and tools, reuse libraries, design patterns, componentry, reuse design, experimentation and measurement, domain-specific software architecture, generators, and business and finance.

LITERATURE REVIEW

Stroustrup (1996) described that “the C++ language was also designed to encourage reuse.” Computer science other areas of research of crucial relevance to reuse are abstract data types and OOP’S language, software architectures, development process models, compilers, metrics and experimentation, and organizational theory.

BUSINESS AND FINANCE

“The ultimate purpose of domain engineering is to provide a company to improve the quality of products and services and, therefore maximize profits.” (Frakes & Kang, 2005)

The critical problems in this area include:

• Tech transfer.

• Sustaining reuse programs.
• Organizational issues.
• Process focus.

We will now discuss two of these issues

Process Focus

In a corporate environment implementing a reuse program requires a decision about where and when capital investment is to be made. There should be made a strategic decision as to whether the investment would be proactively or reactively, and the development of reusable assets often requires a capital investment. Waterfall approach in conventional software engineering is likely the proactive investment for software reuse. Reactive investment is an incremental approach to asset building. (Frakes & Kang, 2005)

Extractive model, another method proposed by Charles Kruger (2002), stays between the proactive and reactive approaches.  This approach reuses one or more existing software products for the product line’s initial baseline and used accumulated expertise, may not require a substantial capital investment.

Organizational Issues

For establishing a reuse program, there are two types of commonly used regulatory approaches.

1. Centralized and
2. Distributed asset development

The centralized approach has an organizational unit dedicated to developing, distributing, maintaining, and usually providing training about reusable assets. The group responsibilities are to analyze product line commonalities and variabilities of applications that are existing or that developed in the future. The unit develops reusable assets and standard architectures and then makes them available to development projects. The group also supports customization. The cost is within the product line as this organizational unit is amortized across projects. (Frakes & Kang, 2005)

Advantages of this approach are:

1)     Between the plans, the product line-wide engineering visions can be shared easily.

2)     Utilization of development knowledge and corporate expertise can be done efficiently across projects.

3)     Systematically the assets can be managed.

Disadvantages in this approach are:

1)     A substantial upfront capital investment is often required to create a reuse program.

2)     It even takes time to see a return on investment.

In the distributed approach, a reuse program is implemented collaboratively by projects in the same product line. In the distributed approach, each project responsibility is to contribute reusable assets to other participating projects. (Frakes & Kang, 2005)

Advantages of this approach are:

1)     No need to create a separate organizational unit, so there is less overboard cost.

2)     No significant up-front investments are necessary, as the assets development cost is distributed among projects.

Disadvantages are:

1)     For the reuse program if there is no shared vision than it may be challenging to coordinate asset development responsibilities.

2)     It may not be easy to provide a component that meets the needs of other projects, even if there is a shared vision among projects.

3)     There must be a convincing cost/benefit model to request active participation.

EXPERIMENTATION AND MEASUREMENT:

Organizations implement systematic software reuse program to improve quality and productivity. They must be able to identify the most effective ruse strategies and measure their progress. The six types of metrics and models that are reviewed: maturity assessment models, failure modes models, cost-benefit models, amount of reuse metrics, reuse library metrics, and reusability assessment models. (Frakes & Terry, 1996)

Experiments in software reuse have included studies of indexing methods for reusable components and correlational studies of the relationship between reuse, productivity, and quality. “One area where much work needed is measurement and experimentation of domain engineering and reuse.” (Frakes & Kang, 2005)

DOMAIN ENGINEERING:

In the early 1980s, technologies for high software productivity through domain engineering started to appear but recently reported, the success stories.

Moon et al. discuss in this paper about an approach to the vital problem of handling requirements for systems in a product line.

A brief explanation of several domain engineering approaches reported in recent publications are

categorized into two technologies: process and technique.

• FAST explains a process model of product line engineering.

Weiss & Lai (1999) explained Family-Oriented Abstraction, Specification, and                Translation method as a pattern of engineering process commonly used in product line engineering. It consists of three sub-processes

1)     Domain qualification

It identifies a product line worthy of investment.

2)     Domain Engineering

It develops product line assets and environments.

3)     Application Engineering

                        By using the product line assets, it develops the products rapidly.

• DARE focuses on digging information from existing code and documents for analysts to create domain models. Frakes, Prieto-Diaz & Fox (1998) described “DARE, domain analysis, and reuse environment, is a toolset and method for doing domain engineering. Its process draws on three information sources: code, documents & expert knowledge and the information extracted from these sources is used to build domain models for feature tables, facet tables and templates, and generic architectures.”
• FORM is a foundation for creating architectures and components, on the commonality and variability analysis. Feature-Oriented Reuse Method, it is a systematic method that captures and looks for commonality and variabilities in terms of ‘features’ of a product line. “Feature model captures commonalities and variabilities, and it is used to support both developments of products using the assets and engineering of reusable product line assets.” (Kang, Lee, & Donohoe, 2002)
• PLUS is the extention of UML based modeling methods to support software product lines for single systems development.

It provides various notations and modeling techniques for product line engineering. First, for the requirement of software product line engineering, use the given case modeling and feature modeling. Second, is analyze activity, dynamic interaction modeling, static modeling, feature/class dependency modeling and dynamic state machine modeling and the last, is design activity, component-based software design, and software architecture patterns. (Gomaa, 2004)

• KOBRA method is a component-based product line engineering with UML.

It provides an approach for accommodating variations of a product line through framework engineering and used the products of a product line for designing a context. “The context includes information on the scope, variability, and commonality of the product line, and these line requirements are analyzed and developed.” (cited from Atkinson, 2002)

• Koala is a component-based product line engineering method with tools for integrating components both at runtime and at compile-time. Koala developed for the analysis of embedded software in the domain of electrical home appliances. Diversity interfaces and switches in koala are for handling product variations. The switch can be used to route connections between the interfaces, and the diversity can be used to handle the internal variety of components. (cited from Ommering, 2000)

PROGRAMMING LANGUAGES:

In two crucial ways, the evolution of programming languages is coupled tightly with reuse.

1. Programming languages have evolved to allow developers to use ever having programming constructs, from ones and zeroes to modules, classes, subroutines, assembly statements, frameworks, etc. (Frakes & Kang, 2005)
2. Programming languages have advanced to be closer human language, more domain focused, and hence more comfortable to use. Languages like Visual C++ and Visual Basic mostly show the influence of software reuse research. (Frakes & Kang, 2005)

LIBRARIES:

A reuse library consists of a central location for storing reusable assets, representation method for the assets. A search interface that allows users to search for assets in the central area and facilities for change management and quality assessment. Reuse process, failure mode analysis shows that to be reused a component must be findable, available, and understandable, and a reuse library supports all of these. (Frakes & Kang, 2005)

Experiments on reuse libraries indicate that current methods of component representation could be improved. There is also a need for library environments that integrate facilities for measurement, and those include facilities for configuration management such as usage and return on investment. (Frakes & Kang, 2005)

ARCHITECTURES:

Shaw (1996) explored several structural models called architecture styles that were frequently used in software and then examined each form of quality attributes.

Architecture plans defined by applying a combination of architectural styles. Reference architectures for an application domain or a product can be built, using architecture patterns. These architectures embody quality attributes inherited from the architecture patterns and application domain-specific semantics. Platform architectures developed are middleware with/on which applications and components for execution of the application. Platform architecture examples are CORBA, COM+, and J2EE. A platform architecture selected for the performance of applications in the domain may influence decisions for a domain architecture. (Frakes & Kang, 2005)

The relationships among these concepts related to architecture can be seen in Fig. 1.

Architecture Pattern

Application Architecture

Domain Architecture

Style

 constrain

Platform Architecture

Fig 1. Architecture Concepts

FUTURE RESEARCH:

Software reuse and domain engineering have some problems; even there are many significant changes. One has to do with scalability, which is the problem of applying these methods to large systems. One issue is how to make the best use of reusable components for the operations. Another is how to do enough formal specifications to support the automated construction of architectures of vast networks. (Frakes & Kang, 2005)

Another problem is sustainability. Now there are many reuse programs, and the current issue is to find the means of sustaining reuse programs on a long-term basis. One approach for this problem is to determine how to make better links between reuse and domain engineering and cooperate strategy. Related to this finding what should be made reusable, that is, which reusable corporate products and processes will give the highest return on investment? And another is determining how to make better technology transfer, that is, how to better support practitioners in the application of reuse and domain engineering research. (Frakes & Kang, 2005)

CONCLUSION

The success of reuse and domain engineering key element is to predict needed variabilities in future assets. Recently, most reuse research focuses on creating and integrating adaptable components at compile time or development. Reuse research has been ongoing for many years. Accomplished much, but still so much to achieve the vision of better system building via domain engineering and reuse. (Frakes & Kang, 2005)

REFERENCES

• Atkinson, C., Bayer, J., Bunse, C., Kamsties, E., Laitenberger, O., Laqua, R.,….Zettel, J.
• (2002). Component-Based Product Line Engineering with UML. Addison-Wesley.

KOBRA method is a component-based product line engineering with UML. It provides an approach for accommodating variations of a product line through framework engineering, and this starts with the products of a product line are used for designing a context. The context includes information on the scope, variability, and commonality of the product line, and these line requirements are analyzed and developed.

Frakes, W.B. (2005, July). Software Reuse Research: Status and Future. IEEE

 transactions on software engineering, 31 (7).

Frakes, W., Prieto-Diaz, R., & Fox, C. (1998). DARE Domain Analysis and Reuse Environment. Annals of Software Eng., 5, 125-141.

DARE focuses on digging information from existing code and documents for analysts to create domain models. DARE, domain analysis, and reuse environment is a toolset and method for doing domain engineering. Its process draws on three information sources: code, documents & expert knowledge and the information extracted from these sources is used to build domain models for feature tables, facet tables and templates, and generic architectures.

Frakes, W. & Terry, C. (1996). Software Reuse: Metrics and Models. ACM computing

 surveys, 28, 415-435.

 Organizations implement systematic software reuse program to improve quality and productivity. They must be able to identify the most effective ruse strategies and measure their progress. The six types of metrics and models that are reviewed: maturity assessment models, failure modes models, cost-benefit models, amount of reuse metrics, reuse library metrics, and reusability assessment models.

Gomaa, H. (2004). Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison-Wesley.

PLUS is the extension of the UML based modeling methods to support software product lines for single systems development. It provides various notations and modeling techniques for product line engineering. First, use case modeling, and feature modeling for the requirement of software product line engineering. Second, introduced dynamic state machine modeling to analysis activity, dynamic interaction modeling, static modeling, feature/ class dependency modeling. Lastly,  added component-based software design, and software architecture patterns, to design event.

Kang, K.C., Lee, J., & Donohoe, P. (2002, July/ August). Feature-Oriented Product Line Engineering. IEEE Software, 19 (4), 58-65.

FORM is the foundation for creating architectures and components, on the commonality and variability analysis. Feature-Oriented Reuse Method, it is a systematic method that captures and looks for commonality and variabilities in terms of ‘features’ of a product line. Feature model captures commonalities and variabilities, and it is used to support both developments of products using the assets and engineering of reusable product line assets.

Kruger, C. (2002, July/August). Eliminating the Adoption Barrier. IEEE Software, 29-31.

Extractive model, another approach, stays between proactive and reactive strategies.  This approach reuses one or more existing software products for the product line’s initial baseline.  When using accumulated expertise, it may not require a significant capital investment.

Ommering, R., Linden, F., Kramer, J., & Magee, J. (2000, March). The Koala Component

Model for Consumer Electronics Software. Computer, 33 (3), 78-85.

Koala is a component-based product line engineering method with tools for integrating components both at runtime and at compile-time. Koala developed for the analysis of embedded software in the domain of electrical home appliances. Diversity interfaces and switches in koala, for handling product variations. The switch can be used to route connections between the interfaces, and the diversity can be used to handle the internal variety of components.

Stroustrup, B. (1996). Language-Technical Aspects of Reuse. Proc. Fourth International

Conf. Software Reuse (ICSR ‘96).

Weiss, D.M., & Lai, C.T. R. (1999). Software Product-Line Engineering: A Family-Based Software Development Process. Addison-Wesley.

It explained Family-Oriented Abstraction, Specification, and Translation method as a pattern of engineering process commonly used in product line engineering. It consists of three sub-processes: Domain qualification identifies a product line worthy of investment. Next is Domain Engineering, develops product line assets and environments. Last is Application Engineering, by using the product line assets it develops the products rapidly.