Complex applications are rarely built from scratch. They are usually derived
from the reuse of similar applications or parts of them. Object-oriented
technology supports the concept of the object-oriented framework for the
development of families of similar applications.
A framework indicates, in the software community, an integrated set of
domain-specific software components (Coplien and Schmidt 1995), which
can be reused to create applications, the most common examples being
graphical user interfaces (Weinand and Gamma 1994).
A framework is more than a library of software components: it defines the
common architecture underlying the concrete applications built on the
framework (Fayad, Schmidt and Johnson 1999). Frameworks are a powerful
development approach as they consist of both reusable code (the component
library) and reusable design (the architecture). The interpretation of “frame-
work” ranges from structures of classes of cooperating objects that provide,
through extension, reusable basic designs for a family of similar applications
(Johnson and Foot 1988), to the more restrictive view (Schmid 1995) of
complete high-level components which, through customization, directly
result in specific applications for a certain domain.
The fourth part of this topic is dedicated to the exemplification of appli-
cation framework development. This is the natural continuation of Part III
where the reader has learnt how to exploit system-level reusable artifacts.
Here the focus is on how to develop such artifacts.
Systematic reuse is generally recognized as a key technology to improve the
software process (Mili et al . 1995). In many cases object-oriented technology
(OOT) is seen as an essential enabler for reuse (Kain 1994) while others
argue that OOT alone does not guarantee reuse (Griss 1995).
The failure of class-library reuse is partly due to the fact that class
libraries commonly restrict polymorphism to work on objects which are
specializations of a class supplied with that library, and that each library
provides a different, incompatible version of this top-level class. More impor-
tantly, however, the size and complexity of projects had grown significantly