Information Technology Reference
In-Depth Information
procedures and test data may all be reused, as can any other portion of a software
engineering project that might serve some function in the development of a
different project.
Schach draws the distinction between two types of reuse. The first, opportu-
nistic, or accidental reuse, occurs when a component that was not originally
developed with the mindset for future implementation, is discovered to be
appropriate for use in a new project. Opportunistic reuse, however, runs an
increased risk over the second type, deliberate reuse, which refers to making use of
a component that was developed with reusability in mind. In the case of deliberate
reuse, attention is paid to ensure that the component in question will have no
unintended side effects or disabling dependencies which might have negative
consequences for future projects. Opportunistic reuse, on the other hand, has a
greater potential for such mistakes, as avoiding them was not a priority during
development (Schach
2008
). When a software component is developed with
reusability in mind, rigorous testing is performed and thorough documentation is
compiled to guide software engineers in future implementations of the component
in question. This extra attention, however, results in an increased cost for the
development of that component.
For the reasons described above, software engineering firms must weigh the
potential benefits of reuse against the cost of development when considering the
components involved in a software engineering project. A piece of software is
developed for a distinct reason, and thus, usually neither the application as a whole
nor all of its constituent parts are determined to be viable candidates for reuse.
Even pieces of software developed for the most specific purposes will generally
make use of very common routines. For this reason, extensive subroutine libraries
have been developed for many programming languages. Modules containing
common routines, such as math procedures, accounting functions or graphical
interface components, are examples of widely used reusable components. Because
the development of many such modules took place in the early development of
these languages, they are often taken for granted; but in truth, they are the quin-
tessential examples of reusable development, without which software engineers
would have to develop each and every portion of a software engineering project
from scratch. The myriad benefits of reuse have encouraged many companies to
both consider reusability in the development of new software engineering
components and to take into account the potential for making use of previously
developed
components
when
designing
and
implementing
a
new
software
engineering product.
2.3.2 Encapsulation and Information Hiding
As we have said, a modularized software product is essentially a collection of
independent modules which serve distinct purposes and are configured to interact
with each other. In addition to lending itself to logical project decomposition and
