larry@JPL-VLSI.ARPA.UUCP (02/27/87)
I've been talking recently with several people about the relationship of
object orientation to requirements analysis. The following is my answer,
which borrows from Russell Abbott's _An Integrated Approach to Software
Development_ (John Wiley & Sons, 1986). Abbott is the person to whom Grady
Booch gives credit for his particular approach to object-oriented design and
programming. My interpretation may differ from Abbott's, but the bottom
line is the same: object orientation is essential to requirements study, but
is not enough by itself.
THE CHINESE BLACK-BOX PROBLEM
Abbott splits requirements analysis into two phases (or roles, if as I do
you see development as a parallel rather than a serial process.) The needs
analysis phase is concerned with the environment of a problem, with WHY a
new system of some kind is to be developed. Since no system can solve all
problems or garner all profits, the client and analyst(s) prioritizes the
pains and gains to be dealt with and drops some of them. Boundary
conditions are then set for those that remain. The end product of this
phase is a Requirements Specification.
The second part of the requirements study is the system synthesis phase,
which focuses on WHAT the new system will be. This phase produces a
description of a system that will meet the constraints defined earlier.
There may be several that would satisfy the client. The one picked becomes
the Target Specification. Abbott emphasizes that the Req spec must be kept
as loose as possible and distinguished from the Target Spec to keep from
painting oneself into a corner.
Design is concerned with the insides of the system, with HOW resources are
to be partitioned and allocated to make the system real. There may be more
than one good way to partition/allocate resources; one must be picked. To
manage the complexity inherent in any non-trivial system, design is often
broken into a preliminary and one or more detailed phases.
This brings to light a confusion that I call the Chinese Black-box Problem.
Each target that satisfies a higher-level requirement establishes
requirements for the next level down, so how do you know the difference
between requirements and design? The resolution is that requirements and
design are duals of each other, and are distinguished by whether you are
looking up or down abstraction levels.
Or put another way: every coin has three sides, the inside, the outside, and
the coin-purse.
NOUNS/VERBS/ADWORDS
Defining important objects is often the first action done at each level of
abstraction, whether it be the two requirements phases, two or more design,
or the various implementation phases. Most writing makes object orientation
sound very esoteric, but in fact the situation is just the opposite. An
object is simply an entity with fairly definite boundaries.
This is the sole criterion, but in the real world most objects have three
other attributes. One is a skin at the boundary that hides/protects some of
its interior and shows/exposes other parts. Also, they have relationships
with other objects, one of the more important ones being membership in one
or more classes. Lastly, they tend to be long-lived or combine to make up
larger objects that are long-lived.
Each of these characteristics (bounds, skins, relations, longevity) are
important because they simplify the thinking of everyone concerned. It is
for this reason that objects are often the starting point in each phase.
Longevity is also important at the end of the development process: the
"maintenance" phase. Enhancement or error correction is much easier when
major parts of a system are stable.
But a system without time (or with eternal time) is useless. Change is also
needed--attributes of objects (color, location, etc.), relationships with
other objects (before/after, brighter- or dimmer-than), the creation and
deletion and transformation into other objects, etc. This is a procedural
orientation. Ed Berard (and I believe Booch) distinguish two types. A
mapping from a domain of objects to a range of them (before and after:
binary time) is a functional abstraction. More complex temporal
changes need an explicit or implicit controller and is labeled a process
abstraction.
In many cases it makes more sense to start a phase defining the nouns
(objects) of a (sub)system being developed, but there are also systems where
time is more important and it may be best to start with the system's verbs
(functional relationships, attributes, and decomposition). In either case,
however, developers will have to deal with both nouns and verbs and rarely
will one be more more important than the other in the long run.
But there's another linguistic element that needs attention, especially in
regards to requirements: adwords (adjectives and adverbs). Ada (or
Ada-like) "sentences" can adequately specify the noun and verb elements of a
target specification, with expressions on the order of OBJ2 := Func(OBJ1).
But how can requirements be specified? What's the Ada equivalent of the
following?
Size(OBJECT) < MAX and Time(Func) > WAIT
Larry @ jpl-vlsi.arpa