home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3213 < prev    next >
Encoding:
Text File  |  1992-08-14  |  10.7 KB  |  219 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: <1992Aug14.231701.24374@mole-end.matawan.nj.us>
  6. Organization: :
  7. References: <1992Aug12.200125.20809@projtech.com>
  8. Date: Fri, 14 Aug 1992 23:17:01 GMT
  9. Lines: 208
  10.  
  11. In article <1992Aug12.200125.20809@projtech.com>, sally@projtech.com (Sally Shlaer) writes:
  12. > In a fascinating article (1992Aug11.180111.4658 etc.), mat@mole-end writes:
  13.  
  14. (I'm flattered by the `fascinating.')  By the way, did you train in
  15. touch-typing on a mechanical or electric typewriter?  I notice that
  16. every line of your text seems to have a trailing space.
  17.  
  18. > > We have here a 'relationship" that is also a transaction or process of
  19. > > some sort.  May I suggest the term 'temporality"? ...
  20.  
  21. > I don't think we need a new term.  You are pointing to one dimension of
  22. > a more general problem:  dynamic relationships.  See chapter 4 of Object
  23. > Lifecycles:  ...
  24.  
  25. Well, the term _is_ found in _Webster's New Collegiate_, so it's not
  26. exactly new.  I suppose that `dynamic relationship' is a good term as
  27. well, but I think the different term helps to focus attention.  Besides,
  28. `temporality' can include events; whether something is an event or a
  29. transaction may not be apparent until after the analysis is underway.
  30. You might choose to include `event' under dynamic relationship'; it's
  31. true that it's a relationship that exists for a brief time between the
  32. things affected by it, but it may not have any internal lifecycle.
  33. I'd prefer to limit your term to those temporalities that do.
  34.  
  35. > But you make a good point:  Relationships are excrutiatingly important
  36. > in explaining how the world works.  ...  [This is] very serious for
  37. > applications where there is contention or competition (two airplanes want
  38. > to put down on the same runway, ...  etc.).
  39. > ...
  40.  
  41. Those are important, but limited cases: where one relationship (server-to-
  42. N-current-clients) must be created from another (server-to-<infinite>-
  43. potential-clients).  I agree that they are worthy of study, especially
  44. if one or two models (or families of models) can be shown to deal well
  45. with them in all (or 99.998% of the) cases actually seen.
  46.  
  47. I'm not quite convinced of that, especially since you haven't seperated
  48. the `philosophical' analysis of the problem from the method you apply
  49. to depict the problem.  Nor am I convinced that you have presented the
  50. relationship issue in its full glory.
  51.  
  52. What, after all, is a data structure but a collection of data and
  53. relationships 'twixt them, with a great deal of information _in_
  54. the relationships?  I think there's room for a _lot_ of study here,
  55. especially  in subtleties and relationships between relationship.  For
  56. example, when parallel inheritance is involved, how do you express
  57. covariant restrictions on the relationships?  For that matter, _when_
  58. do you apply those covariant restrictions?  In what classes of problems
  59. is it applicable?
  60.  
  61. `Research,' in this case, can certainly include cogitation followed
  62. by the writing of essays, especially if the cogitation identifies the
  63. critical issues and the essay describes them in razor-sharp outline and
  64. clear, few words.  (Without discussing the value of their subject matter,
  65. I admire how both Aristotle and von Clausewitz do this.)
  66.  
  67. To be fair, I think you and Steve Mellor have done about the best job
  68. of presenting relationship issues, but I think you've just hinted at
  69. the breadth of the matter.  In part, you seem to have done well because
  70. of the E/R stuff that gets carried over from S.M.'s `Structured' writings.
  71. I do shudder at the term `conditional' instead of `-or-zero' in the
  72. description of relationship cardinality; it seems to me that you are
  73. forgetting that zero is as much a number as one.
  74.  
  75. > > Some authors have used a timing diagram/event trace to represent objects
  76. > > and relationships in time, with lines diverging and converging as objects
  77. > > and relationships come and go.
  78.  
  79. > What authors are you referring to here?  ...
  80.  
  81. I just checked my bookshelf and I can't find the example that I remember
  82. seeing.
  83.  
  84. I was describing--or trying to describe--tools and models upon which
  85. there seems to be some degree of agreement between authorities.  I'm
  86. sorry if I misled anyone.
  87.  
  88. >     Shlaer-Mellor uses an Object Communication Model to show the event
  89. > communication that results from arrival of *all* external events.  This
  90. > diagram also doesn't say anything about the dynamics of existance.
  91. >     Shlaer-Mellor also use a thread-of-control chart (page 97, Object
  92. > Lifecycles) to show event communication between objects that results from the
  93. > arrival of *several* external events.  This diagram *does* show objects
  94. > coming into existance and ceasing to exist.
  95.  
  96. Yes, it does.
  97.  
  98. (I have a nit to pick here; on pg 98 the term `capacitor symbol' is used
  99. near the bottom of the page.  Perhaps if we all had a true education in
  100. SE, with a grounding in the basics of all the fundamental engineering
  101. disciplines, you would be safe in using the term.  But I suspect that
  102. many readers, professional methodologists among them, will have to guess
  103. at the term.)
  104.  
  105. The format of the diagram, however, does not seem to allow timing
  106. information to be placed on the diagram.  There are diagrams in common
  107. engineering use that could present the same information, perhaps with
  108. just a little extension.  That's what I was trying to suggest in my
  109. previous article.  The Thread-of-Control chart may make be able to
  110. present alternatives in processing, but the generic engineering
  111. timing/protocol/messaging/sequencing diagram (I have never found a
  112. definitive name for it) might be extended to do the job, too.
  113.  
  114. > Why am I making such a deal of such a trivial point?  ...  The methods
  115. > of interest to this forum are NOT all the same -- they have very
  116. > different and distinguishing properties.  ...
  117.  
  118. And, at this point, I don't think that any is definitive, so I feel
  119. comfortable discussing them as a body.  Of course, you disagree.  I
  120. will try to keep my point of view clear to all.
  121.  
  122. Notice that in other engineering disciplines, there is not, (or is no
  123. longer) any hot debate about tools and work products.  People understand
  124. what this diagram or mathematical model shows, and use them as they
  125. need them to achieve a good solution.  Perhaps this atmosphere will
  126. not work for software; I'm prejudiced to think that it will.
  127.  
  128. > > Notice here that I am looking for an _analytic_ model, which describes
  129. > > the world modelled, not a _design_ model, which describes how to program
  130. > > it.  I think this excludes the S[c]hlaer-Mellor methods, but I invite
  131. > > Stephen or Sally to prove me wrong.
  132.  
  133. [I apologize for the misspelling.  I will try to correct it in the future.]
  134.  
  135. > Argh, I cannot believe that we have not been clear about this -- so let us
  136. > state our views one more time.
  137.  
  138. >     THE PURPOSE OF ANALYSIS IS TO CAPTURE ALL OF THE INFORMATION ABOUT A
  139. > PROBLEM DOMAIN:  What are the conceptual entities in the problem ... the
  140. > the interrelationships between those entities, how the entities have to
  141. > behave over time.  That is what Shlaer-Mellor OOA is all about.
  142.  
  143. It appears to me that there is at least the begining of a prejudice
  144. toward some solutions over others in the thread-of-control chart.  The
  145. use of arrows and a rendevous-like graph suggest self-synchronizing
  146. entities rather than externally synchronized entities.  Have I read
  147. too much into it?  (I think I assumed that this diagram was used instead
  148. of a conventional timing diagram to convey just that information.)
  149.  
  150. > ...
  151. > ...
  152. > > Insight three:  That if we want to design without excessive iteration . . .
  153. > > we must learn to ask the right questions during analysis.
  154. > > IMO, recognizing these "temporalities" is part of those right questions.
  155.  
  156. >     Yes, and that is why Shlaer-Mellor gives explicit direction as to
  157. > how to recognize them and how to put this information into your
  158. > analysis models.
  159.    ...
  160. > > Insight four:  Our methods must support us in asking those questions, and
  161. > > must preserve the information in a useful form until we need it.
  162.  
  163. > Yes.  And to preserve the information in a *useful form*, we must keep the
  164. > information about the problem domain segregated from the information about
  165. > the solution (a.k.a. design).  Once you mix these two domains of
  166. > information, later designers and implementers cannot tell what they are
  167. > free to change (design information) and what must be left intact (problem
  168. > information).
  169.  
  170. I fully agree with this premise.  I don't support the conclusion that
  171. the symbology must differ, or must differ entirely.  Not everything
  172. must be or should be expressed in symbology.  Consider the diagram on
  173. p. 187 of _Object Lifecycles_.  I cannot fathom what the hexagons
  174. contribute; so far as I can tell, the information could be presented
  175. purely as text.
  176.  
  177. If you go back a ways, I think you'll find that I've argued that one of the
  178. most important pieces of information about a class or object (in the object
  179. world) is the phase in which it was introduced: analysis, architecture
  180. (which word I use differently than you), design, detailing (which you
  181. include in architecture), or even coding.
  182.  
  183. On the other hand, there are things that are better illustrated by
  184. symbology.  It ought to be clear on an object communication diagram,
  185. of whatever kind, whether the information passed is a pure value or
  186. an object identity (`referential value,' if you like).  The diagram
  187. ought to show (IMO, of course) where the reference is taken, so that
  188. the origin and identity of the acquaintanceships is clear.
  189.  
  190. > For a simple example, suppose you have analysis models describing an
  191. > electrical power grid.  ...  You will have linkage information that
  192. > tells you which cable is connected to which transformer, etc.  ...  At
  193. > design time, you may *also* want to have linkages to facilitate the
  194. > operation of the system -- say linkages that allow you to construct
  195. > iterators.  Now this is design information -- and if later it turns out
  196. > that you don't need the design linkage information, the designer/maintainer
  197. > is free to make such a change.  But he must *never* remove the linkages
  198. > that tell how the grid is connected in the real world.
  199.  
  200. There are several ways in which this can be made clear.  First, the
  201. diagrams can be preserved from analysis so that they can be examined
  202. both with and without the design artifacts.  Good engineering practice
  203. should require this anyway; you need a `paper' trail so that you can
  204. check your work, and so, heaven forbid, the NTSB or whoever else can
  205. check them as well when the catastrophe has occurred.
  206.  
  207. (Of course, with CASE, the artifacts of different phases may be
  208. displayed in different colors, weights, line continuities, etc.)
  209.  
  210. Second, the textual documentation of everything on the drawing should
  211. describe its origins.
  212.  
  213. Third, as you suggest, a second symbology may be invented.
  214. -- 
  215.  (This man's opinions are his own.)
  216.  From mole-end                Mark Terribile
  217.  
  218.  mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
  219.