home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3239 < prev    next >
Encoding:
Text File  |  1992-08-17  |  4.1 KB  |  89 lines

  1. Newsgroups: comp.object
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end.matawan.nj.us
  4. Subject: Re: Class methods
  5. Message-ID: <1992Aug18.060553.3373@mole-end.matawan.nj.us>
  6. Summary: Yes, this people would disagree ..
  7. Organization: :
  8. References: <1992Aug12.200125.20809@projtech.com> <1992Aug15.143426.18445@m.cs.uiuc.edu>
  9. Date: Tue, 18 Aug 1992 06:05:53 GMT
  10. Lines: 77
  11.  
  12. In article <1992Aug15.143426.18445@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
  13.  
  14. > The Scandinavian school of objects says that programming is modeling,
  15. > and that an application program should be a model of the application
  16. > problem.  If you take this to an extreme, there shouldn't be any
  17. > difference between analysis and design.
  18.  
  19. > Another point of view is that one person's specification is another
  20. > person's design.  You might write an equation that must hold between
  21. > a set of attributes of different objects and claim that this is a
  22. > specification that falls out of analysis, that it is part of the problem
  23. > domain and not the solution domain.  However, if you are using a
  24. > constraint programming language then those equations ARE your program.
  25.  
  26. And the _design_ decision--the sole design decision--is to use the
  27. constraint model for solution.  More a little later ...
  28.  
  29. > The only real point I am trying to make here is that the boundary
  30. > between analysis and design is not only currently fuzzy, it will
  31. > always be fuzzy.  ...
  32.  
  33. > Thus doesn't mean that we shouldn't try to separate analysis from design,
  34. > since first figuring out what problem you are trying to solve and then
  35. > trying to solve it is a standard and time-proven technique for solving
  36. > problems.  However, as in math and physics, trying to solve a problem
  37. > often shows us that we are trying to solve the wrong problem, so there
  38. > can never be an absolute separation between the two.
  39.  
  40. > Probably everybody knows this already and I am just rambling.  But it
  41. > seemed like the two people I quoted might disagree with it.
  42.  
  43. Well, two people _might_ but this one people _do_.
  44.  
  45. That we sometimes have to backtrack when we discover an inconsistency
  46. does not mean that you cannot seperate the activity out of which you
  47. backtrack from the activity into which you backtrack.  All it means
  48. is that you have to backtrack.
  49.  
  50. If I dig a basement for a house (excavation) and start to lay out
  51. forms for the footings (masonry), then discover I have made an error
  52. in the hole I have dug, I have not blurred or fuzzed the distinction
  53. between excavation and masonry; I have discovered an error in my
  54. excavation.  It is excavation I must resume, even though I had started
  55. the masonry.
  56.  
  57. With that red herring sent to its (we may hope) eternal rest ...
  58.  
  59. The fuzziness between analysis and design is much greater than it
  60. ought to be.  I believe that there is a reason for this: that when
  61. we describe the problem, we organize the description with possible
  62. solutions in mind.  If we think of Analysis, we say of this organizing
  63. `no, it must be Design.'  If we think of Design, we say of it `no, it
  64. must be Analysis.'  The activity, it seems to me, is neither Analysis
  65. nor Design, but Architecture-- at least, it is Architecture as I use
  66. the term: to mean the defined relationships among parts and whole in
  67. the system that give the parts their meaning in within the system.
  68.  
  69. In your constraint programming example, your design decision (to
  70. use constraint programming) led you to organize your analysis as
  71. constraints (Architecture and Detailing).  A fascinating example,
  72. really, since we get  Design=>Analysis=>Architecture=>Detailing .
  73. I'll put it in my files on that basis.
  74.  
  75. Recognize Architecture, and the boundaries become much, much less
  76. fuzzy.
  77.  
  78. Understand a clear definition of Detailing, and the boundaries between
  79. Design, Detailing (or Detailed Design) and Programming snap into sharp
  80. relief.  Not perfectly sharp, not sharp at the atomic level, but sharp
  81. in dimensions of centimeters and millimeters.  (Needst thou femtometer
  82. sharpness?  Then why not zeptometer and yoctometer sharpness?  Where
  83. will it end?  Wilt thou shave the skin off the skin of a quark?)
  84. -- 
  85.  (This man's opinions are his own.)
  86.  From mole-end                Mark Terribile
  87.  
  88.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  89.