![\includegraphics[width=.8\linewidth]{figs/hpdc.eps}](Timg12.png)
|
Reduced Development Time. By reusing existing software components, fewer programs are written, and thus less time is spent in programming. Furthermore, because reusable components are usually carefully tested already, less time is needed in debugging and testing, which are the ``hard and slow part'' of programming [Brooks, 1995]. Lim [Lim, 1994] has reported that in a Hewlett-Packard division, a nearly linear relationship exists between the percentage of reused code in the product and the productivity of programmers, measured in LOC/pm (the number of lines of noncomment source code produced by a programmer in a month). Only 5% of reused code yields an LOC/pm of 550, and as the percentage of reused code increases to 81%, the LOC/pm reaches 2,850. Similar reports can be found in [Browne et al., 1990,Hallsteinsen and Paci, 1997].
Improved Quality. Because software components are often repeatedly reused, the defect fixes from each reuse accumulate, resulting in higher quality of the developed software systems. Raymond has vividly described this incremental bug fix process as ``given enough eyeballs, all bugs are shallow'' in his seminal essay that explains why Open Source software systems tend to have high quality [Raymond and Bob, 2001]. Basili et al. [Basili et al., 1996] have reported that the error density (errors per thousand lines of code) drops from 6.11 for systems developed without reuse to 0.12 for systems developed from reusable components. Similar formal evaluations on the contribution of reuse to the improved quality of software systems can be found in [Lim, 1994,Thomas et al., 1997].
Easy Maintenance. Reusable components contribute to easy maintenance not only because they have fewer defects, but also because they facilitate communication among software developers by providing a set of common vocabulary, especially for the indirect communication between system builders and system maintainers. Because reused software components are high-level abstractions, system maintainers do not need to look into the details of implementation to uncover the original intentions of the system builders.
Improved Evolvability. To cope with constantly changing requirements and implementation platforms, software systems must be able to evolve. Reusing software components improves the evolvability of software systems because it can limit the needed change to components instead of identifying and changing all occurrences distributed all over the system. Graham [Graham, 1995] has reported a very typical example as follows. Three project teams in a company had used the same formula in their software systems. Later, they discovered an error in the formula and needed to modify the systems. The team that had not created a component for the formula spent 5 weeks to find and correct each incidence of the formula. The other two teams, which had put the formula in a set of components, spent 1.5 days and 2 days, respectively to correct the system.
Increased Problem Framing Ability. The representation of a problem is an important determinant of the range of solutions that will be considered, as well as an important source of problem-solving difficulty [Hayes and Simon, 1977]. Reusable software components provide programmers with higher level concepts that are both close to application domains and easy to implement. Components increase programmers' ability to frame the problem into representations that are easier to solve. A component creates an abstraction for an existing solution, and it reduces the number of items that a programmer has to hold in simultaneous contemplation because the programmer can refer to the whole solution with the abstraction, in place of the details of the solution. Figure 2.4 illustrates the contribution software components make to the problem-framing ability. Without the support of reusable components, programmers have to frame each concept in the problem domain based on their knowledge of the programming language; with the support of software components, however, the difficulty of problem framing is reduced because certain concepts can be directly mapped to the components.