home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / object / 2952 < prev    next >
Encoding:
Text File  |  1992-07-21  |  4.5 KB  |  104 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!projtech!sally
  3. From: sally@projtech.com (Sally Shlaer)
  4. Subject: Re: SHlaer-Mellor OOA Model, Problem with definition of Object
  5. Message-ID: <1992Jul21.175138.18096@projtech.com>
  6. Organization: Project Technology, Inc., Berkeley, CA
  7. Date: Tue, 21 Jul 1992 17:51:38 GMT
  8. Lines: 94
  9.  
  10. >> [from sally@projtech.com (Sally Shlaer):]
  11. >> In summary, in OOA we are interested in the typical instance.  
  12. Because we
  13. >> are dealing with analysis, we are not interested in particular 
  14. instances.
  15.  
  16. > [from johnson@m.cs.uiuc.edu (Ralph Johnson) :]
  17. > It seems to me that there are plenty of times in analysis where you 
  18. are
  19. > concerned with individual instances.  [Then a pretty example follows.]
  20.  
  21. Yes, you are right.  I was not clear.  I should have said we are not 
  22. interested in *specified* instances.  We are obviously interested in 
  23. individual unspecified instances that meet certain criteria.  There are 
  24. many examples of this in Object Lifecycles.
  25.  
  26. ===================================
  27. On the terminology discussion :
  28. >> [from sally@projtech.com (Sally Shlaer):]
  29. >> In OOA, we use "object" to mean a single, typical but *unspecified* 
  30. instance.
  31. >> So a Car object means a single car, I don't care which one.  Most 
  32. OODers
  33. >> today (I think) would find this a reasonable use of the word object
  34.  
  35. > [from johnson@m.cs.uiuc.edu (Ralph Johnson) :]
  36. > If I did, I wouldn't have complained!
  37.  
  38. Fair enough  :-).
  39.  
  40. >> [from Sally]  Now let us switch over into OOD land.  As I see it,
  41. >> the word "class" today combines two ideas:
  42. >>  +    the typical unspecified instance (I don't care which instance
  43. >> you are thinking about, this operation works the same way on any 
  44. instance).
  45. >>  +    the collection of all existing instances (as in class data, 
  46. iterators
  47. >> and similar class methods)
  48.  
  49. > {from Ralph]  I only use "class" for the first concept.
  50.  
  51. OK.  Then I think this is what we are saying:  A typical unspecified 
  52. instance is a class to Ralph (who I am taking to be a spokesman for 
  53. OOD), and an object in S-M OOA.  OOA does not have a word for the 
  54. collection of existing instances.
  55.  
  56. Questions:  1.  Do you have a word for the collection of existing 
  57. instances?
  58. 2.  What do you mean when you say "object"?  Can you answer in terms of  
  59. "how many" and specified vs. unspecified -- or is there another 
  60. dimension that we need to take into account? 
  61. 3.  When you said "Like you, I consider a collection of instances to be 
  62. an object", you were using the OOA definition of object -- right?
  63. 4.  When you said "Moreover, I don't consider a class to be an object 
  64. during high level design", were you using the same or a different 
  65. definition?  (This one has me somewhat more puzzled.)
  66.  
  67. ======================================
  68.  
  69. Now, since you asked earlier, here is the historical truth on why we 
  70. chose the word "object" to mean typical unspecified instance.
  71.  
  72. In 1986-87, when we were writing the first book on S-M OOA, there were 
  73. three terminologies current:  the structured methods terminology, the 
  74. database terminology, and oo terminology.
  75.  
  76. The structured methods people (the Yourdon courses of that era and Matt 
  77. Flavin's book) used "object" to mean typical unspecified instance.  So 
  78. "object" was closely associated with analysis.
  79.  
  80. The database people were using "entity".  These people were somewhat 
  81. more closely associated with design.  Based on this, we were slightly 
  82. more inclined to use "object" for the concept in an analysis context.
  83.  
  84. But as you may remember, the terminology in the OO community was fairly 
  85. variable at this time, particularly when dealing with concepts that were 
  86. not strictly tied to a particular OOPL.  We read copious amounts of the 
  87. literature, attended conferences, and talked to everyone we could locate 
  88. to try to find the center of mass -- and "object" or "object-instance" 
  89. seemed to be the center of mass for "typical unspecified instance", as 
  90. well as we could tell.
  91.  
  92. So the choice was made in 1986-87 taking into consideration all the 
  93. factors we could think of that might be relevant.  Now we are now stuck 
  94. with this choice (can you imagine the outrage of our clients if we were 
  95. to try to change it now??  Or the bizarre nature of this discussion if 
  96. we weren't consistent from one book or paper to the next??).  So the 
  97. right thing for us to do is to be careful to define our terms and to 
  98. write as clearly and consistently as we can.  It is also right for us to 
  99. understand exactly how our terms bother/confuse/irritate others -- hence 
  100. my interest in this discussion.
  101.  
  102. Sincerely
  103. Sally Shlaer      sally@projtech.com
  104.