home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.object
- Path: sparky!uunet!mole-end!mat
- From: mat@mole-end.matawan.nj.us
- Subject: Re: Class methods
- Message-ID: <1992Aug14.231701.24374@mole-end.matawan.nj.us>
- Organization: :
- References: <1992Aug12.200125.20809@projtech.com>
- Date: Fri, 14 Aug 1992 23:17:01 GMT
- Lines: 208
-
- In article <1992Aug12.200125.20809@projtech.com>, sally@projtech.com (Sally Shlaer) writes:
- > In a fascinating article (1992Aug11.180111.4658 etc.), mat@mole-end writes:
-
- (I'm flattered by the `fascinating.') By the way, did you train in
- touch-typing on a mechanical or electric typewriter? I notice that
- every line of your text seems to have a trailing space.
-
- > > We have here a 'relationship" that is also a transaction or process of
- > > some sort. May I suggest the term 'temporality"? ...
-
- > I don't think we need a new term. You are pointing to one dimension of
- > a more general problem: dynamic relationships. See chapter 4 of Object
- > Lifecycles: ...
-
- Well, the term _is_ found in _Webster's New Collegiate_, so it's not
- exactly new. I suppose that `dynamic relationship' is a good term as
- well, but I think the different term helps to focus attention. Besides,
- `temporality' can include events; whether something is an event or a
- transaction may not be apparent until after the analysis is underway.
- You might choose to include `event' under dynamic relationship'; it's
- true that it's a relationship that exists for a brief time between the
- things affected by it, but it may not have any internal lifecycle.
- I'd prefer to limit your term to those temporalities that do.
-
- > But you make a good point: Relationships are excrutiatingly important
- > in explaining how the world works. ... [This is] very serious for
- > applications where there is contention or competition (two airplanes want
- > to put down on the same runway, ... etc.).
- > ...
-
- Those are important, but limited cases: where one relationship (server-to-
- N-current-clients) must be created from another (server-to-<infinite>-
- potential-clients). I agree that they are worthy of study, especially
- if one or two models (or families of models) can be shown to deal well
- with them in all (or 99.998% of the) cases actually seen.
-
- I'm not quite convinced of that, especially since you haven't seperated
- the `philosophical' analysis of the problem from the method you apply
- to depict the problem. Nor am I convinced that you have presented the
- relationship issue in its full glory.
-
- What, after all, is a data structure but a collection of data and
- relationships 'twixt them, with a great deal of information _in_
- the relationships? I think there's room for a _lot_ of study here,
- especially in subtleties and relationships between relationship. For
- example, when parallel inheritance is involved, how do you express
- covariant restrictions on the relationships? For that matter, _when_
- do you apply those covariant restrictions? In what classes of problems
- is it applicable?
-
- `Research,' in this case, can certainly include cogitation followed
- by the writing of essays, especially if the cogitation identifies the
- critical issues and the essay describes them in razor-sharp outline and
- clear, few words. (Without discussing the value of their subject matter,
- I admire how both Aristotle and von Clausewitz do this.)
-
- To be fair, I think you and Steve Mellor have done about the best job
- of presenting relationship issues, but I think you've just hinted at
- the breadth of the matter. In part, you seem to have done well because
- of the E/R stuff that gets carried over from S.M.'s `Structured' writings.
- I do shudder at the term `conditional' instead of `-or-zero' in the
- description of relationship cardinality; it seems to me that you are
- forgetting that zero is as much a number as one.
-
- > > Some authors have used a timing diagram/event trace to represent objects
- > > and relationships in time, with lines diverging and converging as objects
- > > and relationships come and go.
-
- > What authors are you referring to here? ...
-
- I just checked my bookshelf and I can't find the example that I remember
- seeing.
-
- I was describing--or trying to describe--tools and models upon which
- there seems to be some degree of agreement between authorities. I'm
- sorry if I misled anyone.
-
- > Shlaer-Mellor uses an Object Communication Model to show the event
- > communication that results from arrival of *all* external events. This
- > diagram also doesn't say anything about the dynamics of existance.
- > Shlaer-Mellor also use a thread-of-control chart (page 97, Object
- > Lifecycles) to show event communication between objects that results from the
- > arrival of *several* external events. This diagram *does* show objects
- > coming into existance and ceasing to exist.
-
- Yes, it does.
-
- (I have a nit to pick here; on pg 98 the term `capacitor symbol' is used
- near the bottom of the page. Perhaps if we all had a true education in
- SE, with a grounding in the basics of all the fundamental engineering
- disciplines, you would be safe in using the term. But I suspect that
- many readers, professional methodologists among them, will have to guess
- at the term.)
-
- The format of the diagram, however, does not seem to allow timing
- information to be placed on the diagram. There are diagrams in common
- engineering use that could present the same information, perhaps with
- just a little extension. That's what I was trying to suggest in my
- previous article. The Thread-of-Control chart may make be able to
- present alternatives in processing, but the generic engineering
- timing/protocol/messaging/sequencing diagram (I have never found a
- definitive name for it) might be extended to do the job, too.
-
- > Why am I making such a deal of such a trivial point? ... The methods
- > of interest to this forum are NOT all the same -- they have very
- > different and distinguishing properties. ...
-
- And, at this point, I don't think that any is definitive, so I feel
- comfortable discussing them as a body. Of course, you disagree. I
- will try to keep my point of view clear to all.
-
- Notice that in other engineering disciplines, there is not, (or is no
- longer) any hot debate about tools and work products. People understand
- what this diagram or mathematical model shows, and use them as they
- need them to achieve a good solution. Perhaps this atmosphere will
- not work for software; I'm prejudiced to think that it will.
-
- > > Notice here that I am looking for an _analytic_ model, which describes
- > > the world modelled, not a _design_ model, which describes how to program
- > > it. I think this excludes the S[c]hlaer-Mellor methods, but I invite
- > > Stephen or Sally to prove me wrong.
-
- [I apologize for the misspelling. I will try to correct it in the future.]
-
- > Argh, I cannot believe that we have not been clear about this -- so let us
- > state our views one more time.
-
- > THE PURPOSE OF ANALYSIS IS TO CAPTURE ALL OF THE INFORMATION ABOUT A
- > PROBLEM DOMAIN: What are the conceptual entities in the problem ... the
- > the interrelationships between those entities, how the entities have to
- > behave over time. That is what Shlaer-Mellor OOA is all about.
-
- It appears to me that there is at least the begining of a prejudice
- toward some solutions over others in the thread-of-control chart. The
- use of arrows and a rendevous-like graph suggest self-synchronizing
- entities rather than externally synchronized entities. Have I read
- too much into it? (I think I assumed that this diagram was used instead
- of a conventional timing diagram to convey just that information.)
-
- > ...
- > ...
- > > Insight three: That if we want to design without excessive iteration . . .
- > > we must learn to ask the right questions during analysis.
- > > IMO, recognizing these "temporalities" is part of those right questions.
-
- > Yes, and that is why Shlaer-Mellor gives explicit direction as to
- > how to recognize them and how to put this information into your
- > analysis models.
- ...
- > > Insight four: Our methods must support us in asking those questions, and
- > > must preserve the information in a useful form until we need it.
-
- > Yes. And to preserve the information in a *useful form*, we must keep the
- > information about the problem domain segregated from the information about
- > the solution (a.k.a. design). Once you mix these two domains of
- > information, later designers and implementers cannot tell what they are
- > free to change (design information) and what must be left intact (problem
- > information).
-
- I fully agree with this premise. I don't support the conclusion that
- the symbology must differ, or must differ entirely. Not everything
- must be or should be expressed in symbology. Consider the diagram on
- p. 187 of _Object Lifecycles_. I cannot fathom what the hexagons
- contribute; so far as I can tell, the information could be presented
- purely as text.
-
- If you go back a ways, I think you'll find that I've argued that one of the
- most important pieces of information about a class or object (in the object
- world) is the phase in which it was introduced: analysis, architecture
- (which word I use differently than you), design, detailing (which you
- include in architecture), or even coding.
-
- On the other hand, there are things that are better illustrated by
- symbology. It ought to be clear on an object communication diagram,
- of whatever kind, whether the information passed is a pure value or
- an object identity (`referential value,' if you like). The diagram
- ought to show (IMO, of course) where the reference is taken, so that
- the origin and identity of the acquaintanceships is clear.
-
- > For a simple example, suppose you have analysis models describing an
- > electrical power grid. ... You will have linkage information that
- > tells you which cable is connected to which transformer, etc. ... At
- > design time, you may *also* want to have linkages to facilitate the
- > operation of the system -- say linkages that allow you to construct
- > iterators. Now this is design information -- and if later it turns out
- > that you don't need the design linkage information, the designer/maintainer
- > is free to make such a change. But he must *never* remove the linkages
- > that tell how the grid is connected in the real world.
-
- There are several ways in which this can be made clear. First, the
- diagrams can be preserved from analysis so that they can be examined
- both with and without the design artifacts. Good engineering practice
- should require this anyway; you need a `paper' trail so that you can
- check your work, and so, heaven forbid, the NTSB or whoever else can
- check them as well when the catastrophe has occurred.
-
- (Of course, with CASE, the artifacts of different phases may be
- displayed in different colors, weights, line continuities, etc.)
-
- Second, the textual documentation of everything on the drawing should
- describe its origins.
-
- Third, as you suggest, a second symbology may be invented.
- --
- (This man's opinions are his own.)
- From mole-end Mark Terribile
-
- mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
-