home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 2950 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  3.6 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!sgi!iphasew!igor!yosemite!rmartin
  2. From: rmartin@yosemite.Rational.COM (Bob Martin)
  3. Newsgroups: comp.object
  4. Subject: Re: OOA: Should "Classification" be performed in OOD phase?
  5. Keywords: Class based vs Classless implementations.
  6. Message-ID: <rmartin.711732459@yosemite>
  7. Date: 21 Jul 92 15:27:39 GMT
  8. References: <2640@abcom.ATT.COM>
  9. Sender: news@Rational.COM
  10. Lines: 79
  11.  
  12. brr@abcom.ATT.COM (Rao) writes:
  13.  
  14.  
  15. |A few postings on OOA (and a few personal emails ) suggested
  16. |that "identification" of classes should perhaps be done
  17. |during the OOD phase, while "identification" of objects
  18. |should be performed in the OOA phase.
  19.  
  20. |This would allow for OOA without being influenced by issues
  21. |such as Class-based implementation (and Class-based OOD) or
  22. |Class-less implementation (meaning Delegation based).
  23.  
  24. |Question: When does OOA end and OOD begin?
  25.  
  26. That is a meaningless question, It is like asking the wavelength at
  27. which orange begins and red stops.  In a spectrum, there is definitely
  28. red and orange, but no specific boundary.  The same is true of OOA and
  29. OOD.
  30.  
  31. |Another Question: In what phase do we decide if objects should be 
  32. |    "Classified"? During OOA or OOD?
  33.  
  34. There is no firm answer to this question, since "Classification' can
  35. happen both as part of analysis and of design.  However, I have a
  36. bias.  I accept classification as a valid part of analysis, but such
  37. classifications are 'soft' in that they need not imply inheritance.
  38. In Analysis we can say that object X conforms to such and such an
  39. interface, or that object y and object z are polymorphic forms of
  40. object w.  But it is generally premature to say that D inherits from
  41. B.
  42.  
  43. I view inheritance as a design tool.  The construction of huge
  44. inheritance hierarchies requires a decision process which employs
  45. design trade-offs.  Many inheritance decisions have more to do with
  46. the structure of the solution rather than the structure of the
  47. problem.
  48.  
  49. Thus, when we classify object in analysis, we are stating a soft
  50. relationship.  During design, that relationship may be hardened into
  51. inheritance, or it may be manipuated into some other form such as
  52. generic instantiation or simple interface congruence.
  53.  
  54. |Most OOA models include "Classification of objects" as part
  55. |of the OOA phase. For example, in the OMT (Rumbaugh et. al.)
  56. |the following process is recommended:
  57.  
  58. |Step 1. Initial written description.
  59.  
  60. |Step 2. Build an object Model.
  61. |    - Identify object classes.
  62. |    - Begin a data dictionary ,......
  63. |    - Add association between classes.
  64. |    etc.
  65.  
  66. |    Clearly, Rumbaugh's OMT model is "Class-based".
  67.  
  68. We are learning more and more every day about OOA and OOD.  In earlier
  69. times it seemed that OO == inheritance, thus OOA must involve
  70. inheritance in some way.  Now, this equation is weakining.  It was
  71. common to see inheritance bandied about in the OOA book of the last
  72. few years.  I think this trend will decrease.
  73.  
  74. Classification will remain important as an analysis tool, but it
  75. represents more options than just inheritance.  So inheritance will,
  76. more and more, be relagated to the domain of design.
  77.  
  78. |I hope I am not repeating old arguments and rehashing old
  79. |battles. If so, please ignore.
  80.  
  81. This is cutting edge stuff.  Nobody really knows what OOA is.  We all
  82. have clues and guesses.  It will take time (many man-millenia) before
  83. we can be more definitive.
  84.  
  85.  
  86. --
  87. +---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
  88. | rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
  89. |     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
  90. +----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
  91.