Thursday, 29 August 1991
Wednesday, 28 July 1993
Tuesday, 15 August 1995

Workshop on Reuse
OOPSLA '91, Phoenix, AZ
Monday, 30 September 1991
Rebecca Joos and John D. McGregor, organizers

Workshop on Process Standards and Iteration
OOPSLA '93 Washington, DC
Jim Coplien, Russell Winder, and Susan Hutz, organizers

Workshop on OO Process and Metric for Effort Estimation
OOPSLA ’95, Austin, TX
Sunday, 15 October, 1995
Dennis de Champeaux, Simon Horner, and Granville Miller, organizers

Department of Computer Science
University of Illinois at Urbana-Champaign
1304 West Springfield Ave. 
Urbana IL 61801 
(217) 328-3523
foote@cs.uiuc.edu

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 software infrastructure 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.

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

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.

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.

(2) Gould has noted that natural taxonomic hierarchies exhibit maximal diversity during this early evolutionary phase.

[Apple 1984]
	Apple Computer, Inc.
	Lisa Toolkit 3.0 
	Apple Computer, Cupertino, CA

[Balzer 1983]
	R Balzer, T.E. Cheatham, and C. Green
	Software Technology in the 1990s:
	Using a New Paradigm
	Computer, Nov. 1983, pp. 39-45

[Boehm 1988]
	Barry W. Boehm
	A Spiral Model of Software 
	Development and Enhancement
	Computer, May 1988, Volume 21, Number 5

[Brooks 1975]
	Frederick P. Brooks
	The Mythical Man-Month:  
	Essays on Software Engineering
	Addison-Wesley, Reading MA, 1975

[Brooks 1987]
	Frederick P. Brooks
	No Silver Bullet:  
	Essence and Accidents of Software Engineering
	IEEE Computer, Vol. 20, No. 4, April 1987

[Cox 1986]
	Brad Cox
	Object-Oriented Programming:  
	An Evolutionary Approach
	Addison-Wesley, 1986

[Deutsch 1983]
	L. Peter Deutsch
	Reusability in the Smalltalk-80 
	Programming System
	pp 72-76 
	ITT Proceedings of the Workshop on 
	Reusability in Programming
	(reprinted in Tutorial on Software Reusability,
	IEEE Computer Society Press, 1987)

[Foote 1988]
	Brian Foote
	Designing to Facilitate Change
	with Object-Oriented Frameworks
	Masters Thesis, 1988
	University of Illinois at Urbana-Champaign

[Foote 1988b]
	Brian Foote
	Domain Specific Frameworks Emerge as
	a System Evolves
	OOPSLA '88 Workshop on Methodologies
	and Object-Oriented Programming
	San Diego, CA
	Norman L. Kerth, organizer

[Foote 1988c]
	Brian Foote
	Designing Reusable Realtime Frameworks
	OOPSLA '88 Workshop on 
	Realtime Systems
	San Diego, CA
	John Gilbert, organizer

[Foote 1989a]
	Brian Foote
	The Craftsmen vs. the Scavengers:
	The Ruminations of a Foot Soldier
	on the Reuse Revolution
	OOPSLA '89 Workshop on the
	Reusable Component Marketplace
	New Orleans, LA
	John T. Mason, organizer

[Foote 1991b]
	Brian Foote
	A Fractal Model of the Lifecyle
	of Reusable Objects
	OOPSLA '91 Workshop on Reuse
	Ottawa, Ontario, Canada
	Rebecca Joos and John D. McGregor,
	organizers

[Gould 1987]
	Stephen Jay Gould, Norman L. Gilinsky,
	and Rebecca Z. German
	Asymmetry of Lineages and the Direction
	of Evolutionary Time
	Science, Volume 236, pp. 1437-1441
	12 June 1987

[Johnson & Kaplan 1986]
	Ralph E. Johnson and Simon Kaplan
	Towards Reusable Software 
	Designs and Implementations
	Proceedings of the Workshop on 
	Future Directions in 
	Computer Architecture and Software
	May 5-7, 1986, Seabrook Island, Charlston, SC
	Sponsored by the Army Research Office (ARO)

[Johnson & Foote 1988]
	Ralph E. Johnson and Brian Foote
	Designing Reusable Classes
	Journal of Object-Oriented Programming
	Volume 1, Number 2, June/July 1988 
	pages 22-35

[McCracken 1982]
	Daniel D. McCracken and Michael A. Jackson
	Life Cycle Concept Considered Harmful
	Software Engineering Notes, Volume 7, Number 2, 
	April 1982, pages 29-32

[McGregor & Sykes 1993]
	Object-Oriented Software Development:
	Engineering Software for Reuse
	Van Nostrand Reinhold, 1992]

[Meyer 1988]
	Ware Meyers
	Interview with Wilma Osborne
	IEEE Software, 5 )4):  104-105, 1988

[Parikh 1984]
	Girish Parikh
	What is Sofware Maintenance Really?  
	What is in a Name?
	Software Engineering Notes, Volume 9, Number 2, 
	April 1984, pages 114-116

[Parikh 1985]
	Girish Parikh
	SOFTWARE MAINTENANCE NEWS
	Software Engineering Notes, Volume 10, Number 2, 
	April 1985, pages 58-60

[Schmucker 1986]
	Kurt J. Schmucker
	Object-Oriented Programming for the Macintosh
	Hayden, Hasbrouck Heights, NJ, 1986

[Tracz1986]
	William J. Tracz
	Why Reusable Software Isn't
	Proceedings of the Workshop on 
	Future Directions in Computer 
	Architecture and Software
	May 5-7, 1986, Seabrook Island, Charleston, SC

Brian Foote foote@cs.uiuc.edu
Last Modified: 23 April 2004