home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / object / 3518 < prev    next >
Encoding:
Text File  |  1992-09-11  |  5.0 KB  |  111 lines
  1. Newsgroups: comp.object
  2. Path: sparky!uunet!mole-end!mat
  3. From: mat@mole-end.matawan.nj.us
  4. Subject: Re: Object-Oriented Methodologies - Class Specifications
  5. Message-ID: <1992Sep11.093338.15487@mole-end.matawan.nj.us>
  6. Summary: To Characterize Relationships Ask
  7. Organization: :
  8. References: <1992Sep8.192520.2575@projtech.com>
  9. Date: Fri, 11 Sep 1992 09:33:38 GMT
  10. Lines: 99
  11.  
  12. In article <1992Sep8.192520.2575@projtech.com>, sally@projtech.com (Sally Shlaer) writes:
  13.  
  14. > Graham writes:
  15. > >There are many many
  16. > >more relationships that I cannot model with inheritance, so I am
  17. > >suggesting that people need to look very carefully at inheritance. 
  18. >                                                        ~~~~~~~~~~~
  19.  
  20. > I would suggest instead that we need to look carefully at *additional
  21. > techniques* for modeling relationships.  ...
  22.  
  23. (I'm sure I mentioned this before ... but ...)
  24.  
  25. In teaching OO to programmers skilled in procedural programming, I found
  26. it useful to treat Inheritance as something other than a `relationship.'
  27. When I tried to treat them together, students spent a lot of time coming
  28. up with `unnatural' Object-Relationship diagrams.  When I had them
  29. identify behavioral inheritance early in analysis (when the objects
  30. themselves were identified) a plausible, workable inheritance diagram
  31. resulted almost w/out effort.  It needed augmentation as types were added
  32. to complete the solution (principally MI to bring in capabilities from
  33. libraries), but it was never dismantled.  And most of the students came
  34. up with workable O-R diagrams in a very short time.
  35.  
  36. >  ... entities in the world are related in very interesting and complex
  37. > ways -- and to capture these relationships accurately requires a much
  38. > richer topology than can be attained with hierarchies alone.  ...
  39.  
  40. While I've disagreed with Sally Shlaer and Steve Mellor on elements of
  41. methodology, their treatment of relationships is probably the strongest--
  42. and some of the work from Structured methods (esp. Ward-Mellor, if I
  43. recall; the book is not here) maps quite well into OO design and
  44. detailing.
  45.  
  46. > 1.  Inheritance
  47. > 2.  Use a pointer to point to the related object
  48. > 3.  Use an instance variable to contain an identifier of the related object
  49. > 4.  Define a class to implement the relationship, and use either a pointer
  50. >     or an instance variable with an identifier to link the related objects.
  51. >     (per the suggestion from eric@tfs.com (Eric Smith):
  52. >         . . .
  53.  
  54. > Is it possible to state guidelines to help a designer decide what
  55. > is the best way to implement each of the relationships in
  56. > the Dog example above?  I would like to see a discussion
  57. > on this matter.
  58.  
  59. The first place to look is at the cardinalities of the relationships
  60. themselves.  It helps, IMO, to look at `pure' E-R diagrams (those that
  61. do not prejudice the question by deciding what is an attribute) as well
  62. as O-R diagrams.  The cardinality must be considered both by Object
  63. existence and by Object value (entity).  A relationship that is 1-1 on
  64. object identity (and {n or N}-1 on entities) can be represented by making
  65. the second object a member or subobject of the first.  A relationship
  66. that is 1-{0,1} on object identities requires a pointer in one object
  67. to identify the second object.  Etc.
  68.  
  69. I haven't written a truly exhaustive description of these, but I believe
  70. that one can be written.  (And the rules for posting entities to data
  71. stores in the structured world are probably a good guideline to have
  72. at hand while writing it.)
  73.  
  74. I found these `steps' helpful in describing how to program relationships
  75. reliably:
  76.  
  77.     1) Determine how the relationship must be represented.
  78.  
  79.     2) Identify the `rules' of the representation
  80.         (e.g.: When an A is created, a B must be created; when a
  81.         C is created, there must exist a (not-necessarily-unique) D.)
  82.  
  83.     3) Write the `policies' that enforce the rules
  84.         (e.g.: When an A is created, a B shall be created; when a C
  85.         is created, the creation requires the identity of a D as a
  86.         parameter)
  87.  
  88.     4) Assign responsibilities for the policies to various methods
  89.         in the various objects, creating methods as necessary.
  90.  
  91. I believe that, should it be necessary, these could be enumerated
  92. exhaustively, just as the rules for the `minimum' data structure to
  93. support the relationship can be.
  94.  
  95. And yes, they could probably be implemented by a CASE system.  Such a
  96. system, in the OO world, would also have to be cognizant of which side(s)
  97. of the relationship needed to know of the relationship, and of
  98. acquaintanceships established during various process steps.  These, in
  99. turn, require that the Object-Communication diagram(s) be worked out (as
  100. overlays to the O-R diagram, and with acquaintanceships shown).
  101.  
  102. IMO, such CASE support would be far more valuable than trying to raise
  103. the level of process steps by grouping all the domain interfaces at one
  104. `level,' a process which discards dependency information among domains.
  105. (Ok, a cheap shot at an old issue ...)
  106. -- 
  107.  (This man's opinions are his own.)
  108.  From mole-end                Mark Terribile
  109.  
  110.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  111.