Software Reuse

CSC 532
Term Paper

By

Soumitra Mishra
 Software Reuse
(CSC 532: Term Paper)

1) Abstract:
Software reuse has become a topic of much interest in the software community due to its
potential benefits, which include increased product quality and decreased product cost
and schedule. Software is rarely built completely from scratch. To a great extent, existing
software documents (source code, design documents, etc.) are copied and adapted to fit
new requirements. Yet we are far from the goal of making reuse the standard approach to
software development. The upfront investments required for software reuse are
considerable, and need to be duly considered prior to attempting a software reuse
initiative. This paper looks into the various facets if software reuse and discuses its pros
and cons.

2) Introduction:

"Waste not, want not" has never been the motto of software developers. On the contrary,
waste has been encouraged as a normal part of the one-of-a-kind system development
philosophy. The need for waste is upheld in the name of good software practices that put
user requirements first. The software tradition is to serve the customer by custom-
building from scratch each system specifically designed to meet a set of particular
customer requirements, no matter how much reinventing-of-the-wheel occurs.

i) What is Software Reuse?

In simple words software reuse can be defined as the process of creating software
systems from existing software assets rather than building them from scratch.
Software assets, or components, include all software products, from requirements
and proposals, to specifications and designs, to user manuals and test suites. In
general anything that is produced from a software development effort can
potentially be reused.

ii) Why Reuse Software?

What has not been realized is the extent of reinventing that occurs in software project
after software project. Analysis of software systems reveals that the majority of software
system could be built from predefined, interchangeable common software components
because there is a great deal of commonality across software systems. In general, the
level is about 60 percent, but within the same application area, it could reach into the 90
percent range. This commonality provides a great opportunity to practice software reuse
in almost every software project. Today, more and more organizations are filling in the
reuse by making reuse part of the mandate for re-engineering the business.
Exploiting reuse opportunities enables significant software productivity, quality and cost
improvements that are sorely needed as corporations face shrinking budgets, fierce
competition, business re-engineering and downsizing.

3) Levels of Software Reuse

Reuse is still an emerging discipline. It appears in many different forms from ad-hoc
reuse to systematic reuse, and from white-box reuse to black-box reuse.

Ad-hoc reuse - In the completely decentralized, ad-hoc model, reuse is touted as an

abstract goal, but there is no plan, no coordination, and no support from the organization
as a whole. This is very easy to achieve, but it rarely makes an observable difference.

Intra-Project reuse - In this model, reuse happens within projects. For the organization,
reuse is more-actively encouraged, and there may be central personnel helping to
motivate, educate, and assist projects trying to reuse. This takes a bit more effort, but with
that effort, some projects may become islands of reuse success.

Inter-Project reuse - In this model, reuse is encouraged among projects, with central
support. There is also a coordinating role, which attempts to bring projects together to
facilitate reuse. This requires still more effort and discipline, but the benefits are not
restricted to single projects.

Enterprise-level reuse- In this model, reusable assets are viewed as corporate assets. A
reuse-support organization provides architecture coordination and manages asset
libraries, and its staff works to ensure that the libraries continue to meet projects' needs.
[1]
 Figure 1: Levels of reuse [1]

Broadly speaking software reuse can also be classified as:

I) Horizontal Reuse
Horizontal reuse refers to software components used across a wide variety of
applications. In terms of code assets, this includes the typically envisioned library of
components, such as a linked list class, string manipulation routines, or graphical user
interface functions. Horizontal reuse can also refer to the use of a commercial off-the-
shelf (COTS) or third-party application within a larger system, such as an e-mail package
or a word processing program.

II) Vertical Reuse

Vertical reuse, significantly untapped by the software community at large, but potentially
very useful, has far reaching implications for current and future software development
efforts. The basic idea is the reuse of system functional areas, or domains that can be used
by a family of systems with similar functionality. The study and application of this idea
has spawned another engineering discipline, called domain engineering. Domain
engineering is "a comprehensive, iterative, life-cycle process that an organization uses to
pursue strategic business objectives. It increases the productivity of application
engineering projects through the standardization of a product family and an associated
production process." This gets us to application engineering, the domain engineering
counterpart: "Application engineering is the means by which a project creates a product
to meet a customer's requirements. The form and structure of the application engineering
activity are crafted by domain engineering so that each project working in a business area
can leverage common knowledge and assets to deliver a high-quality product, tailored to
the needs of its customer, with reduced cost and risk." [5] Domain engineering focuses on
the creation and maintenance of reuse repositories of functional areas, while application
engineering makes use of those repositories to implement new products.

Domain engineering is the key concept and focus of current reuse efforts. The prospect of
being able to reuse entire tested subsystems without change is a win-win situation for
both customers and software organizations.

Software Engineering with Reusable Components

Many different products for reuse range from ideas and algorithms to any documents that
are created during the software life cycle. Source code is most commonly reused;
thus many people misconceive software reuse as the reuse of source code alone.
Recently source code and design reuse have become popular with (object-oriented)
class libraries, application frameworks, and design patterns. Software components
provide a vehicle for planned and systematic reuse. Nowadays, the term component
is used as a synonym for object most of the time, but it also stands for module or
 function. Recently the term component-based or component-oriented software
development has become popular.

Software component reuse is the key to significant gains in productivity. However, to

achieve its full potential, we need to focus our attention on development for reuse, which
is a process of producing potentially reusable components. Systematic software reuse and
the reuse of components influence almost the whole software engineering process.
Software process models were developed to provide guidance in the creation of high-
quality software systems by teams at predictable costs. The original models were based
on the misconception that systems are built from scratch according to stable
requirements. Software process models have been adapted since based on experience, and
several changes and improvements have been suggested. With increasing reuse of
software, new models for software engineering are emerging. New models are based on
systematic reuse of well-defined components that have been developed in various
projects.

The emphasis should be on development for reuse rather than just on development with
reuse, which is a process of normal systems development. Developing software with
reuse requires planning, developing and providing documentation for and with reuse. The
priority of documentation in software projects has traditionally been low. However,
proper documentation is a necessity for the systematic reuse of components. If we
continue to neglect documentation we will not be able to increase productivity through
the reuse of components. Detailed information about components is indispensable. [3]
The process of developing potentially reusable components depends largely on defining
their characteristics such as language features and domain abstractions. Reuse guidelines
can represent such characteristics clearly. Therefore, we need to formulate objective and
reuse guidelines.

Initial Reusable
component component

Name Operation Exception Component

generalization generalization generalization certifica tion

Figure 2: Reusable component design [6]

4) Obstacles to Reuse

In spite of its obvious advantages, only few corporations have successfully put the theory
into practice, and many are reluctant to even try. Because of the many known obstacles to
reuse and the few known solutions, reuse is still not a popular software practice. As
shown in Table 1, there are several major obstacles to reuse. They include technical and
management/cultural obstacles. Surprisingly, the biggest obstacles fall on the non-
technical side, with just getting started being a major problem.
 Table 1: Obstacles to Reuse [4]

o No understanding of what to reuse and how to create it for reuse

o No planning for reuse
o Reuse confined to an individual or within one system
o Limited to code-level reuse
o No management involvement or support
o No or negative reuse incentives
o Reuse practiced only in the coding phase
o Cost of reuse is too high
o Reuse is contrary to current software culture
o Nothing to reuse; absence of a library of reusable components
o Inability to recognize what has high potential for reuse
o No reuse activities defined as part of the software life cycle process
o Reuse is not supported by current software tools
o Management not convinced of value of reuse

o Software professionals not trained in reuse

Reuse cannot work without management support. Currently, reuse is viewed as a

technology strategy, but to get management support it also must become a viable business
strategy. To convince management of the business value of reuse it is important to link
reuse to strategic business and system planning. They are identifying systems that are
strategically important, and then looking for commonality across these systems.
Commonality presents an opportunity for reuse. For example, systems that share common
requirements or comply with common standards can be built from common components.

5) Where to start?

The traditional software development process does not take into account reuse. Typically
software projects are built as a one time only entity with no support for reuse. They offer
no flexibility for future reuse. Here the problem lies with the software development
process. Thus there is a need for a new approach to software development with software
reuse in mind. This can be achieved in one way by having a product line approach. A
product line can be defined as a group of similar products usually catering a specific
market segment. This gives a great opportunity for reuse. Thus generalization is the keep
to successful software reuse. It enables one to create a new product from existing
components or products.

Managed reuse, in which reuse is built into the software development and maintenance
processes, is the key to getting reuse to have an impact on the bottom line. Reuse
management is much more important for this than is reuse technology. The technology,
such as repositories, catalogs, or sophisticated browsers, will be much more beneficial if
the management infrastructure and planning for reuse are sound. [1] There is a need for
strong commitment towards the goal of reuse. The goals of reuse, as defined in the
Software Reuse Key Process Area of the Software Engineering Institute's (SEI)
Capability Maturity Model, are to (1) Incorporate reusable software assets into new or
existing applications and (2) Collect, evaluate, and make available to software projects
reusable software assets. SEI claims that two important commitments must be made by
an organization as well: (1) to follow a written policy which outlines the software reuse
tasks in the software process and the methods and tools to identify, build, acquire, and
reuse assets, and (2) to maintain the reusable assets by storing and providing an
identification mechanism[5].

Incorporation of reuse in the software development process is not a straight forward task.
Even companies those are willing to make long-term investments need a solid strategy to
ensure that those investments will pay off. There are many potential obstacles that could
be avoided with the right planning and infrastructure. On the other hand, investing in
misdirected discipline, architecture, planning and infrastructure will not help you achieve
reuse. If you make investments in the name of reuse but don't deliver, even after the
expected learning curve, you could ruin the prospects for reintroducing reuse at a later
date. In other words, although you are well poised to take advantage of managed software
reuse, it is critical to learn everything you can about growing a reuse program the right
way. Sufficient resources and funding must be provided for incorporating software reuse,
including technical skills (domain analysis, development of reusable assets, asset storage
and identification), tools, and incentive to build reusable assets as well as use them.

As with any long-term investment, you need to be able to reassure the investors that
things are progressing according to plan, and this requires an effective feedback loop.
Besides reuse management, you will also need to invest in honing your skills at project
estimation, measurement, and development process review. Responsibilities have to be
specifically assigned for the acquisition and maintenance of reusable components for the
project. You will need to set up an infrastructure that is continuously examining and
improving its effectiveness. This means that we need to monitor the progress in order to
make sure that software reuse improves our efficiency even if it is in the long run.

6) Technicalities

One of the core technologies to realize software reuse is domain engineering, which
covers the exploration, analysis, production and management of reusable software assets
of a domain to support subsequent application engineering activities. It involves
producing a domain model of the product line that identifies common members and
allowable variations for each. Product line software architecture is built based on this
domain model. Thus, domain model framework, which provides necessary capabilities to
model commonality and variability of a domain, is the basic aspect to ensure the
competence of the domain model to fulfill its role played in software reuse. While
designing new applications based on the domain model, it has to be considered that the
application under consideration will not necessarily reuse all the requirements covered by
the domain model; on the other side, there are always some application-specific
requirements that are not covered by the domain model. Customization seems to be a
natural way to reusing the domain model. At the same time how to ensure the validity of
the results from customization, and how to identify, resolve the potential conflicts
between the newly added requirements and existing requirements, become the critical
issues related to the customization-based approach.

Figure 3: Domain components [2]

7) Investment

There is a large cost associated with software reuse. It is an extra cost on top of the
traditional development costs, since designing reusable assets takes more time and care
than designing a one-time specific system. The extra investment required spans
organizational, technical, and process changes, as well as the cost of tools to support
those changes, and the cost of training people on the new tools and changes.

Some of the procedures that must be specified in order to adopt reuse are:

 Procedures for developing reusable assets and inclusion of assets in the repository
 Procedures for domain analysis and architecture design and modification
 Procedures for configuration management and control of reusable assets [5]

Because of the fact that the quality of reusable software affects not just the current
application but also many future applications therefore it demands some extra effort and
time for designing, implementing, and testing. It is only through a deliberate attempt to
incorporate reuse throughout the software development process that a complete
organization wide utility of software reuse can be harnessed.

To implement a product line approach, a group of domain experts must be established

and maintained to perform domain analysis and develop architectures for the domain. In
their analysis, this group must partition the domain into segments that can be developed
independently and can evolve for future changes. This partitioning usually involves the
determination of specific functional areas, along with roles and responsibilities, within
the domain. As analysis evolves into architecture design, the group must create interfaces
to these encapsulated functional areas in such a way that a future change within one area
will not require a change throughout the entire system. Clear and complete
documentation of the software architecture is a must, and all proposed changes to the
architecture should be filtered through the domain expert group.

8) Training

Software reuse is still far from achieving the status of a standard software development
process. Because of this fact, specialized training of the staff becomes very essential. But
before software reuse and its associated training can be incorporated, it is important that
all the people associated with the software development are convinced about the concept
behind reuse and its benefits. Developing software with reuse in mind requires a lot more
effort than building one-time software. It should be the responsibility of the management
to provide incentives to the individuals who contribute to the reuse initiative by creating
reusable assets or reusing assets from the library. This also involves emphasizing upon
not just the long term benefits but also the short term benefits.

9) Advantages

Despite software reuse's promise to significantly improve software quality and produc-
tivity, its practice remains elusive. The difficult issues outside the technical realm are
seldom addressed. To be practical, reuse must address not only technical but managerial,
economic, performance, cultural, and technology transfer issues. But once a unified
process for software reuse is evolved in an organization then its advantages become very
apparent.

Some of the advantages associated with software reuse can be summarized as:

 Increases in productivity and quality.

 Increased reliability with components exercised in working systems.

 Easy scheduling and timeline.

  Cheaper software development (in the long run).

 Reduced process risk with less uncertainty in development costs.

 Effective use of specialists with reuse of components instead of people.

 Compliance of standards with embedded standards in reusable components.

 Accelerated development because of avoiding original development and hence

speed-up production.

10) Conclusion

Software reuse will not achieve its expected benefits unless reuse is systematized. The
product line approach to software reuse requires substantial upfront investment with
substantial, but not immediate, benefits. Much commitment, planning, and effort are
required to begin a reuse program. Reuse processes and procedures must be incorporated
into the existing software development process. Components should be built specifically
for reuse. Domain Engineering takes advantage of the similarities inherent in systems
within one domain and builds a domain model that defines the basic structure for existing
and future requirements. With appropriate software reuse process in place substantial
benefits can be achieved in almost all facets of software development.

References

1) http://www.reuse.com

2) http://www.comp.lancs.ac.uk

3) J. Sametinger, Software Engineering with Reusable Components

4) http://www.reusability.com

5) http://www.baz.com

6) http://sunset.usc.edu
… Soumitra Mishra