Washington, D. C.

27 September 1993

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

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

Boehm identified four, and added a fifth:

Write some code, fix it, repeat

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

A very durable "dead horse"

Stages consist of successive, incremental, increasingly realistic prototypes

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

An iterative model

Each cycle unfolds as follows:

Objectives ->

Constraints ->

Alternatives ->

Risks ->

Risk Resolution ->

Results ->

Plan for next phase ->

Commitment

Risk Driven

Kick the nearest wolf away from your door first

Radial dimension of the spiral is a function of

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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