From: mat@mole-end.matawan.nj.us
Subject: Re: Class methods
Organization: :
Date: Fri, 14 Aug 1992 23:17:01 GMT

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
Xref: sparky comp.object:3271 comp.lang.clos:675