Page 72 -

CHAPTER 2 THE PROCESS 43

Classes created in past software engineering projects are stored in a class
library or repository (Chapter 31). Once candidate classes are identified, the class
library is searched to determine if these classes already exist. If they do, they are
extracted from the library and reused. If a candidate class does not reside in the
library, it is engineered using object-oriented methods (Chapters 21–23). The first
iteration of the application to be built is then composed, using classes extracted
from the library and any new classes built to meet the unique needs of the appli-
cation. Process flow then returns to the spiral and will ultimately re-enter the
component assembly iteration during subsequent passes through the engineer-
ing activity.
The component-based development model leads to software reuse, and reusabil-
ity provides software engineers with a number of measurable benefits. Based on stud-
ies of reusability, QSM Associates, Inc., reports component assembly leads to a 70
percent reduction in development cycle time; an 84 percent reduction in project cost,
and a productivity index of 26.2, compared to an industry norm of 16.9. [YOU94]
Although these results are a function of the robustness of the component library, there
is little question that the component-based development model provides significant
XRef advantages for software engineers.
UML is discussed in The unified software development process [JAC99] is representative of a number of
some detail in Chapters component-based development models that have been proposed in the industry.
21 and 22.
Using the Unified Modeling Language (UML), the unified process defines the compo-
nents that will be used to build the system and the interfaces that will connect the
components. Using a combination of iterative and incremental development, the uni-
fied process defines the function of the system by applying a scenario-based approach
(from the user point of view). It then couples function with an architectural frame-
work that identifies the form the the software will take.

2.9 THE FORMAL METHODS MODEL
The formal methods model encompasses a set of activities that leads to formal math-
XRef
Formal methods are ematical specification of computer software. Formal methods enable a software engi-
discussed in Chapters neer to specify, develop, and verify a computer-based system by applying a rigorous,
25 and 26.
mathematical notation. A variation on this approach, called cleanroom software engi-
neering [MIL87, DYE92], is currently applied by some software development organi-
zations.
When formal methods (Chapters 25 and 26) are used during development, they
provide a mechanism for eliminating many of the problems that are difficult to
overcome using other software engineering paradigms. Ambiguity, incomplete-
ness, and inconsistency can be discovered and corrected more easily, not through
ad hoc review but through the application of mathematical analysis. When formal
methods are used during design, they serve as a basis for program verification and