From: mat@mole-end.matawan.nj.us
Subject: Re: Class methods
Summary: Yes, this people would disagree ..
Organization: :
Date: Tue, 18 Aug 1992 06:05:53 GMT

In article <1992Aug15.143426.18445@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
 
> The Scandinavian school of objects says that programming is modeling,
> and that an application program should be a model of the application
> problem.  If you take this to an extreme, there shouldn't be any
> difference between analysis and design.
 
> Another point of view is that one person's specification is another
> person's design.  You might write an equation that must hold between
> a set of attributes of different objects and claim that this is a
> specification that falls out of analysis, that it is part of the problem
> domain and not the solution domain.  However, if you are using a
> constraint programming language then those equations ARE your program.

And the _design_ decision--the sole design decision--is to use the
constraint model for solution.  More a little later ...
 
> The only real point I am trying to make here is that the boundary
> between analysis and design is not only currently fuzzy, it will
> always be fuzzy.  ...
 
> Thus doesn't mean that we shouldn't try to separate analysis from design,
> since first figuring out what problem you are trying to solve and then
> trying to solve it is a standard and time-proven technique for solving
> problems.  However, as in math and physics, trying to solve a problem
> often shows us that we are trying to solve the wrong problem, so there
> can never be an absolute separation between the two.

> Probably everybody knows this already and I am just rambling.  But it
> seemed like the two people I quoted might disagree with it.

Well, two people _might_ but this one people _do_.

That we sometimes have to backtrack when we discover an inconsistency
does not mean that you cannot seperate the activity out of which you
backtrack from the activity into which you backtrack.  All it means
is that you have to backtrack.

If I dig a basement for a house (excavation) and start to lay out
forms for the footings (masonry), then discover I have made an error
in the hole I have dug, I have not blurred or fuzzed the distinction
between excavation and masonry; I have discovered an error in my
excavation.  It is excavation I must resume, even though I had started
the masonry.

With that red herring sent to its (we may hope) eternal rest ...

The fuzziness between analysis and design is much greater than it
ought to be.  I believe that there is a reason for this: that when
we describe the problem, we organize the description with possible
solutions in mind.  If we think of Analysis, we say of this organizing
`no, it must be Design.'  If we think of Design, we say of it `no, it
must be Analysis.'  The activity, it seems to me, is neither Analysis
nor Design, but Architecture-- at least, it is Architecture as I use
the term: to mean the defined relationships among parts and whole in
the system that give the parts their meaning in within the system.

In your constraint programming example, your design decision (to
use constraint programming) led you to organize your analysis as
constraints (Architecture and Detailing).  A fascinating example,
really, since we get  Design=>Analysis=>Architecture=>Detailing .
I'll put it in my files on that basis.

Recognize Architecture, and the boundaries become much, much less
fuzzy.

Understand a clear definition of Detailing, and the boundaries between
Design, Detailing (or Detailed Design) and Programming snap into sharp
relief.  Not perfectly sharp, not sharp at the atomic level, but sharp
in dimensions of centimeters and millimeters.  (Needst thou femtometer
sharpness?  Then why not zeptometer and yoctometer sharpness?  Where
will it end?  Wilt thou shave the skin off the skin of a quark?)
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ