A Fractal Model of the Lifecycle of Reusable Objects

A Fractal Model of the Lifecycle of Reusable Objects

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 ofabstract 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 byscavenging 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 usingblack-box components. Consolidation is undertaken in an opportunistic fashion, when the insight to justify refactoring has been developed. Hence, I call the Fractal Model anopportunity 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.

1991 ending:

In order for the craftmen to triumph over the scavengers, programmers and managers 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.

References


 [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 


来源：http://www.laputan.org/frameworks/fractal.html