16 June 1995

Illinois State University, Normal, Illinois

Billy Lim, Organizer

Diane Crawford (the Executive Editor of CACM) 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

Fred Brooks (from No Silver Bullet)

Many students of the art hold out more hope for object-oriented programming than for any of the other technical fads of the day.

I am among them.

Productivity

Libraries

Abstract Classes

Components

Frameworks

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

A framework can be thought of as the embodiment of an abstract design for solutions to problems drawn from such a domain

Frameworks are often characterized by an inversion of control

A framework is

the design for an application or subsystem

A set of abstract classes and the way objects in those classes collaborate

MacApp

InterViews

ET++

OWL

MFC

Taligent Frameworks

Choices

Battery Simulation

Accounts

Persistence/Distribution (e.g. SOM)

The analysis and evolution underlying MVC

now permeates the industry

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

Communication is in conformity with the component's 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

A first-pass design is seldom truly reusable

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

Reusable objects 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

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

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 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

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

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 and refactored

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

Refactoring 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

Refactorings are program transformations that preserve program semantics, while improving structure

Refactoring has traditionally been done by hand, but tools are starting to emerge

Languages differ significantly in the degree to which they support refactoring

Eliminate Case Analysis

Reduce the Number of Arguments

Reduce the Size of Methods

Class Hierarchies should be Deep and Narrow

The Top of a Class Hierarchy should be Abstract

Minimize Access to Variables

Subclasses should be Specializations

Split large classes

Factor implementation differences into subcomponents

Separate methods that do not communicate

Send messages to components instead of to self

Reduce implicit parameter passing

Examples: VisualWorks, MFC, OWL

This will take on increasing importance as dynamic components come into their own

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

From Gould, Gilinsky, and German

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

Maintenance burden is reduced, since all applications share a common core

Lavishing effort on this core becomes cost effective

Tools become practical

New applications can leverage the effort and design insight embodied in the framework

Coding is minimized, even eliminated

Framework construction is domain analysis

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

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

Are about the architectural insights that underlie the code you have to write to put together your abstract classes, components and frameworks

A movement whose goal is to get programmers to write down and disseminate this information

A literary rather than technical form

Examples: The Gang of Four book

Strategy, Composite, Command, Factory

Building systems out of objects encourages the emergence of reusable abstract classes, components and frameworks

Truly reusable objects can not be designed through superior insight and sheer force of will

They are the instead the result of an iterative evolutionary process that unfolds at all levels in a system, within and beyond the applications that spawn these objects.