Reusable object-oriented abstract classes, frameworks, and components have
lifecycles of their own that are separate and distinct from those of the
applications in which they are incubated. They are the product of an
evolutionary process that unfolds simultaneously within and beyond
individual applications. Because this process can be characterized as a
pattern that is repeatedly replicated at all levels of a system, I call
this lifecycle perspective the Fractal Model [Foote 1988b]
[Foote 1991b]. It represents an attempt to formulate a software process
perspective indigenous to the object-oriented community.

Most researchers who have explored objects have observed that they emerged
as the result of a highly iterative process. Not unsurprisingly, the
notion of iteration inspires visions of wheels
spinning, and programmers going around in circles in the minds of many who
must manage and pay for this activity. The Fractal Model tries to more
precisely characterize the phases of this iterative activity, and describe
how mature, reusable components result from it. The Fractal Model
refines iterative notions developed in the Waterfall Model, Evolutionary
Development Model, and (in particular) the Spiral process model.

Objects, in and of themselves, have a greater potential for reuse than
do conventional software components. Each of the characteristics that
distinguish objects from conventional components contributes to this
potential. Polymorphism increases the likelihood that a family of
related objects will operate correctly in a variety of different contexts.
Inheritance allows a class to spawn an entourage of related subclasses
that do not undermine the integrity of the original class,
and promotes the emergence of abstract classes and frameworks.
Encapsulation insulates an evolving part of a system from the rest of the
system, and promotes the emergence of components with identities distinct
from the systems in which they are embedded.
Successful reuse requires not only a commitment to new languages and tools,
but a complete change in one's outlook on the software development process
as well. An organization with a commitment to reuse seeks, at the
completion of a given development effort, to produce two
distinct products. The first is a deliverable application.
The second is an enhanced legacy of reusable abstract classes,
components, and frameworks that can serve as the foundation for similar
future efforts.

The Fractal Model distinguishes three distinct stages, or phases, in the
evolution of object-oriented abstract classes, frameworks, and components.
The first is a Prototype, or Initial Design Phase.
The prototype is a quick first pass that may be quite loosely structured,
and make use of expedient, inheritance-based code borrowing.
During the prototype phase, the designer should concentrate on the
problem at hand. Reuse should be a secondary concern. Expedient,
first pass designs should never be mistaken for good designs
(though we all hit a hole-in-one occasionally). Note that prototypes
are not produced in a vacuum, but depend instead on pre-existing libraries
of reusable components.

An object that proves successful enters an Expansionary, or Exploratory Design
Phase. There is a distinctly Darwinian quality about this(2).
An object's demonstrated utility inspires attempts to reuse it for purposes
that differ from its original purpose to varying degrees. In conventional
systems, such reuse might be undertaken by scavenging copies of the original
component, or by introducing flags and conditionals into the original code.
Such activity tends to destroy the system's structure, and increase the
entropy and disorder the system. There is a risk during this phase that
the component may suffer from "mid-life" generality loss.

Object-oriented systems can retain the integrity of the original code by
placing new code in subclasses. As a result, broad, shallow white-box
class hierarchies can develop. The subclasses added during the
exploratory phase preserve the integrity and identity of the requirements that
inspired them, but are not yet truly general.

During the Consolidation, or Design Generalization Phase, experience accrued
during successive reapplications of an object is used to increase its
generality and structural integrity. As is the case everywhere else in the
universe, there can be no entropy reduction without an expenditure of
energy. During this phase, the programmer reorganizes the class hierarchy,
and abstract classes that reflect the structural regularities in the system
(and the problem domain) emerge. It comes to reflect the way you would like
to be able to tell people you arrived at the design. The informal,
inheritance-based, white-box relationships that may be present in the system
can be recast using black-box components. Consolidation is undertaken in an
opportunistic fashion, when the insight to justify refactoring has been
developed. Hence, I call the Fractal Model an opportunity driven model,
as opposed to the Spiral Model, which is risk driven.

At each level, the model moves from the prototype phase through the
expansionary phase, into the consolidation phase. From there, an element
may expand further, or serve as the basis for a new prototype.
As objects evolve, the breadth of class hierarchies decreases as the depth
increases, and discrete, black-box components emerge from ill-defined
inheritance hierarchies. Both progressions enhance this system's generality
and reusability. The same pattern is repeated at every level: within
individual classes and applications, up into the elements of the frameworks
that can encompass a family of related applications.

This model has a number of technical and managerial implications. One is
that design is more than a discrete phase in the development of a component,
instead, it is an activity which pervades the lifecycle. This model places
emphasis not so much on the generation of single applications as on the
development of the softwareinfrastructure for solving a range of application
requirements. If this perspective is correct, then perhaps current
programmer deployment practices are backwards. Skilled designers may be
most valuable during the design consolidation phase, which will occur quite
late, during what has often be thought of as the maintenance phase in
traditional process models. Recent research has found that between 60 and 85
percent of the total cost of software is incurred during maintenance.
Clearly, something is amiss with models that emphasize front-loading the
design process. Hence, this model might lead to a sort of gentrification
of software maintenance.

The disciplined reuse of object-oriented
components, abstract classes, and frameworks stands in stark contrast to the
casual reuse of conventional code and program skeletons.

1991 ending:

In order for the craftmen to triumph over the scavengers, programmersandmanagers must commit themselves to designing for the long haul.

1993 ending:

The reuse potential of objects, classes, and frameworks is a major factor that
distinguishes them from conventional software artifacts.
An object-oriented process model that does not first take into account the
distinctive fashion in which reusable objects evolve is likely to be an
impediment to reuse.

The Fractal Model was devised using previous process models as a basis, and
incorporates observations from my own work, and from many conversations with
other researchers and practitioners. I've been gratified to find that this
model seems to resonate with people who are really building object-oriented
systems. However, it should be noted that my own observations are based on
medium size projects executed by fairly small groups (<6), and that the
application domain that I work in must confront requirements that change
with unusual rapidity. I believe that this rapid change telescopes the
evolutionary process, and has made it easier to observe and
characterize. Nonetheless, the Fractal Model should be seen essentially a
hypothesis until systematic attempts are made to deploy it on a larger scale.

1995 ending (followed 1993 ending):

A distinguishing feature of this model is that it postulates that
there is a resemblance between the micro- and macro- level processes.

It further postulates that a methodology of sort for framework development
can be derived by carefully choosing different problems from a given
domain and "cultivating" the framework by successively addressing
these requirements.