home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.object
- Path: sparky!uunet!mole-end!mat
- From: mat@mole-end.matawan.nj.us
- Subject: Re: Class methods
- Message-ID: <1992Aug18.060553.3373@mole-end.matawan.nj.us>
- Summary: Yes, this people would disagree ..
- Organization: :
- References: <1992Aug12.200125.20809@projtech.com> <1992Aug15.143426.18445@m.cs.uiuc.edu>
- Date: Tue, 18 Aug 1992 06:05:53 GMT
- Lines: 77
-
- 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
-