A Fractal Model of the Lifecycles of Reusable Objects


Workshop on Objects, Iteration, and Developlent Process Standards



Washington, D. C.

James O. Coplien, Russell Winder, and Susan Hutz, organizers


Brian Foote

27 September 1993

The Fractal Model of the Lifecycle of Reusable Objects


Reusable object-oriented abstract classes, components and frameworks have lifecyles of their own that are distinct from those of the applications that incubate them


Objects evolve within and beyond the applications that spawned them


Structure emerges as objects evolve


Because the pattern in which they evolve is similar at each level, the overall pattern can be thought of as a fractal curve



Consider these two statements:

Iteration considered harmful

"Iteration" considered harmful


"Iteration" inspires visions of wheels spinning or dogs chasing their tails, or of money spinning down the drain...


Most researchers who have examined where Reusable objects come from have observed that they are the result of a highly iterative process


The Fractal Model tries to more precisely characterize the nature of this iterative activity and why mature, Reusable objects result from it

Software Process Models


Boehm identified four, and added a fifth:


Code-and-Fix Model

Write some code, fix it, repeat


Stagewise and Waterfall Models

feasibility -> requirements -> product design -> detailed design -> coding -> integration -> unit testing -> implementation -> operations and maintenance

Waterfall approaches add a single level of feedback between a given stage and the preceding one

Salmon Ladders

A very durable "dead horse"

Evolutionary Development Model

Arose in response to the rigidity of the waterfall approach

Stages consist of successive, incremental, increasingly realistic prototypes


Transform Models

Specifications are directly translated into executable code

The specifications can be thought of as a very high level language for a given domain

Have only succeeded in well understood domains such as 4GLs and speadsheets

Spiral Model


An attempt to reconcile previous approaches, particularly the Waterfall and Evolutionary Approaches


An iterative model

Each cycle unfolds as follows:


Objectives ->

Constraints ->

Alternatives ->

Risks ->

Risk Resolution ->

Results ->

Plan for next phase ->



Risk Driven

Kick the nearest wolf away from your door first


Radial dimension of the spiral is a function of

cumulative cost


Each cycle begins with the hypothesis that a given operational requirement might be met via a software development effort

When this test fails, the spiral is broken

What's Wrong with this Picture?


Various observers have noted that the ratio of effort between development and maintenance is 40/60, 30/70, and even 10/90


Yet, existing process models emphasize a front-loaded deployment of resources and talent


Maintenance comes in several flavors

Corrective 21%

Adaptive 25%

Perfective 50%

Others 4%


Where the money goes:

Adaptive and Perfective maintenance together account for 75% of all maintenance costs


Clearly, applications continue to evolve beyond the initial development phases of their lifecycles


Yet, "maintenance" is frequently a neglected backwater where inexperienced programmers must pay their dues

Object and Reuse


Objects, in and of themselves, have a greater reuse potential than do conventional software components



Allow a family of related objects to work correctly in a variety of different contexts



Allows a class to spawn an entourage of related subclasses

Allows core classes to be shared unscathed

Promotes the emergence of Abstract Classes and Object-Oriented Frameworks



Insulates evolving parts of a system

Maintains the integrity of black-box components

and Frameworks

From the Mythical Man-Month


Lehman and Belady have studied the history of successive releases in a large operating system.

They find that the total number of modules increases linearly with release number, but that the number of modules affected increases exponentially with release number.

All repairs tend to destroy the structure to increase the entropy and disorder of the system.

Less and less effort is spent fixing original design flaws; more and more is spent on fixing flaws introduced in earlier fixes.

As time passes, the system becomes less and less well ordered...


...Systems program building is an entropy decreasing process, hence inherently metastable.

Program maintenance is an entropy increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence...


Maintenance, it would seem, is like fixing holes in a failing dike. Eventually it fails, and must be rebuilt. Only then are lessons learned during its tenure exploited

The Lifecycle of an Object-Oriented Entity


The Fractal Model distinguishes three stages, or phases


Initial Design (Prototype) Phase

Usually a prototype (of sorts)

Informally structured

Employs expedient "code borrowing"

Constitutes a first pass at design

General design opportunities should be anticipated, where possible

Expedient design should never be mistaken for good design

Exploratory (Expansionary) Phase

Occurs when a design is successful

Frequently occurs during the "perfective" maintenance phase

Characterized by the spawning of a number of specialized variations on the original theme

Broad, shallow class hierarchies may develop

There is a risk of "mid-life" generality loss

These may be somewhat informally organized

A "white-box" phase

Design Consolidation (Generalization) Phase


Where entropy reduction gets done

Class hierarchy is reorganized, abstract classes that reflect structural regularities in the system emerge

Hierarchy comes to reflect the way you'd like to tell people you got it there

Redesign at this point in a system's evolution allows the designer to exploit the insights available from having specialized a design to suit a number of applications

Hindsight, which is now available, can be brought to bear on the redesign

A "black-box" phase

These phases unfold independently at all levels of the system

At each level, objects move from the prototyping phase, through the exploratory phase, and then into consolidation


Components, Abstract Classes, and Frameworks

all evolve in this fashion


Both exploration and consolidation should be undertaken in an "opportunistic" fashion as opposed to the "risk-based" criterion of the Spiral Model

White-Box vs. Black-Box Frameworks


White-Box Frameworks


Are extended primarily via inheritance

Each method must abide by the internal conventions of its superclasses

Are informally organized internally, yet encapsulated

"Permissive" scope rules allow structure to undergo experimentation

Are characteristic of the early, exploratory phases of a framework's evolution

Black-Box Frameworks


As a framework evolves, the relationship among its elements become better defined

Portions of the framework emerge as distinct components

Communication among this components is then in conformity with the components external protocol

Are indicative of a better, more mature understanding of the structure of a system

Are a goal toward which framework designers should aspire


Black-box frameworks are easier to reuse than white-box frameworks, since only the external component protocols need be understood, and any components conforming to these protocols may be substituted for an equivalent one

Frameworks vs. Conventional Generalization Approaches


Dealing with volatile requirements


Conventional programming environments cope with volatile, evolving requirements in relatively haphazard ways

Object-oriented approaches can subsume these, and, in the process, allow applications themselves, as well as their constituent components, to be reused


Object Oriented


Variants as Subclasses


Prototype Objects



Implications of this Lifecycle Perspective


Design pervades the lifecycle


Emphasis is not so much on single applications as on developing the software infrastructure for solving a range of application requirements


If hindsight is so valuable, the perhaps current programmer deployment practices are backwards

Skilled designers may be most valuable during the design consolidation phase


Perhaps this perspective can lead to a gentrification of maintenance


Greater reuse potential can make lavishing greater care, resources, and attention on components pay

Any increase in robustness so achieved benefits all the applications which use a component

From Gould, Gilinsky, and German

Asymmetry of Lineages and the Direction of Evolutionary Time


Evolutionary groups generally concentrate diversity during their early histories

Any taxonomic group builds to maximum diversity, and declines to extinction


They suggest that their documented temporal asymmetry may display a fractal character of self similarity at all scales


[Early] asymmetry arises when an initial emptiness permits unusual opportunity for diversification


Such patterns have been noted in the evolution of Egyptian pottery designs, New England headstones, and 19th century gas lanterns


...the structural principles that fashion the molds and set the constraints upon the pathways of change be may more abstract, and therefore more common to a broad range of disciplines wedded to differing immediate mechanisms

Risks and Pitfalls


Over-design: Proving Parkinson's Law by exhaustion

Outside application domains that are well understood, the paths to generality may not be obvious


Attempts to exploit generality that's not really there

Or, time may be spent solving problems that will never arise


The construction of Swiss Army Knives

Like blank check ICs, components with complex interfaces are hard to learn and reuse


The hiding of power in the name of generality

Designers may reject good domain specific solutions

A Fractal Methodology


Framework Cultivation

Framework Farming

Selective Breeding

Framework Eugenics


The idea: Exploit the evolutionary characteristic of object oriented frameworks by "seeding" the framework with a broad range of representative requirements drawn from the domain of interest


Building frameworks for unfamiliar domains is hard to do up-front

Building a domain-specific framework is a good way to explore a domain's design space


One program is easier to maintain than are five.

Communications of the ACM

September 1993

Volume 36, Number 9


Diane Crawford (the Executive Editor) states:

Our most recent survey results indicate more than half the Communications readers rate object-oriented programming and related technologies their Number One area of technical interest

Brian Foote foote@cs.uiuc.edu
Last Modified: 8 June 2004