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 firstname.lastname@example.org
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