home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / software / 2940 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  3.5 KB
  1. Xref: sparky comp.software-eng:2940 comp.object:2986
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!ames!agate!dog.ee.lbl.gov!network.ucsd.edu!sdcc12!cs!wgg
  3. From: wgg@cs.ucsd.edu (William Griswold)
  4. Newsgroups: comp.software-eng,comp.object
  5. Subject: Re: Software costs revisited?
  6. Message-ID: <36065@sdcc12.ucsd.edu>
  7. Date: 24 Jul 92 01:39:35 GMT
  8. References: <1992Jul20.120345.26472@cs.tu-berlin.de> <22493@hacgate.SCG.HAC.COM>
  9. Sender: news@sdcc12.ucsd.edu
  10. Followup-To: comp.software-eng,comp.object
  11. Organization: CSE Dept., U.C. San Diego
  12. Lines: 64
  13. Nntp-Posting-Host: gremlin.ucsd.edu
  14.  
  15. In article <22493@hacgate.SCG.HAC.COM> hayes@valkris.aero.org (Brian Hayes 74-35 x65129) writes:
  16. >...
  17. >It is always interesting to read about motivation for using OO.  I'm
  18. >currently reading Booch's "Object-Oriented Design With Applications"
  19. >(1991) and his stated motivation for OO is that previous/other methods 
  20. >have failed to master complexity (with regard to "industrial strength
  21. >software") which leads to the software crisis were a project is "late,
  22. >overbudget and deficient in their stated requirements."
  23. >
  24. >I am new to OO, so forgive my ignorance, but, IMHO:  These motivations
  25. >are not good enough to justify using OO.  I believe that functional 
  26. >oriented analysis and design is as good as OOA and OOD if not better.
  27. >The problem in the past (and currently) is that few people/projects
  28. >apply a rigorous life-cycle methodology when producing systems.  One 
  29. >problem, of course is that there are few methodolgies that are 
  30. >rigorous enough (appoligies to Hatley-Pirbahi method, ADARTS, and 
  31. >other similar methods and methodologies who fall short of being 
  32. >rigorous).
  33. >
  34. >As I investage and analyze the OO paradigm, I will be attempting to 
  35. >find answers to the following questions:
  36. >Are the OO methodologies rigorous enough? 
  37. >When I complete my OOA phase, can I be assured that the system will 
  38. >work and meet requirements?
  39. >When I complete the OOD phase, can I be assured that the system 
  40. >will work and will meet requirements?
  41. >
  42. >*** Brian Hayes hayes@hac2arpa.hac.com (310) 616-5129 ***
  43.  
  44. I don't know how OOA/D fares with regard to completeness criteria.  However,
  45. one important quality of a design is how well it positions the implementors
  46. for future change, since most of a good program's lifetime is spent in
  47. maintenance.  
  48.  
  49. For maintenance, one desirable characteristic of a system is locality of
  50. change.  If an enhancement or repair can be implemented within one or two
  51. modules/classes (and it is not necessary to check every module in the system
  52. for consistency), then the design has succeeded in making the life of
  53. maintainers easier, and improves the chances of a reliable product.
  54.  
  55. It is widely understood that functional design tends to lead to
  56. implementations that require non-local changes more often than
  57. data-oriented design methods.  A classic reference in this regard is:
  58.  
  59. @article{ParnasCriteria,
  60. author = "D. L. Parnas",
  61. title = "On the Criteria to be Used in Decomposing Systems into Modules",
  62. journal = CACM,
  63. volume = 15,
  64. number = 12,
  65. year = 1972,
  66. month = Dec,
  67. pages = "1053--58"}
  68.  
  69. In fact, modules only succeed in isolating representation (which is one
  70. class of likely change), but do not particularly help you with extending
  71. interfaces and behavior.  Classes help some in this regard via suclassing,
  72. inheritance and polymorphism.  An article in June 1992 IEEE Computer,
  73. ``Using Tool Abstraction to Compose Systems'' by Garlan, Kaiser and Notkin
  74. describes a rather different, more dynamic approach.
  75.  
  76.                         Bill Griswold
  77.                         UCSD, Dept. of CS&E
  78.                         wgg@cs.ucsd.edu
  79.