NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3217

Text File | 1992-08-15 | 4.3 KB | 95 lines

Newsgroups: comp.object
Path: sparky!uunet!mole-end!mat
From: [e-mail]
Subject: Re: Class methods
Message-ID: <[e-mail]>
Organization: :
References: <[e-mail]>
Date: Sat, 15 Aug 1992 08:31:37 GMT
Lines: 84

I'm afraid I may not have been explicit about all my concerns
with Sally Shlaer's reply.  I'll try not to repeat myself needlessly.

In article <[e-mail]>, [e-mail] (Sally Shlaer) writes:
> In ... (1992Aug11.180111.4658 etc.), mat@mole-end writes:
>
> > We have here a 'relationship" that is also a transaction or process of
> > some sort.  May I suggest the term 'temporality"?
> > We're still not paying enough attention to relationships.

>     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.

> > 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 Shlaer-Mellor methods, but I invite
> > Stephen or Sally to prove me wrong.

If the diagram on p. 97 shows objects coming into existance, then it
has prejudiced the case, deciding that the temporalities are to be
represented by objects.  I would not expect a purely analytic model to
make that assumption.  If it expresses only the sequencing inherent in
the temporalities, I wonder why a standard engineering tool (the timing
diagram, in its various forms, used by EEs and communication engineers)
cannot express what happens, especially as there are things (such as
limit on action and dwell times) not expressed on the t-of-c chart.

But I ask more than that.  When _events_ synchronize but _states_ (and
subcycles of states) do not, I would like tools that provide insight
into what is happening.  There is an example of this in the state model
on p. 40 ofthe same book.  The checking account exhibits state-based
dynamic behavior, since the `overdrawn' condition is not synchronized
with the arrival of checks, and the state cycle of checks coming in
is affected by the state of the account.

To go back to an analogy in the EE world, which I like to pretend I
understand (I've never earned money with my BE degree):

    I can write equations describing a complicated circuit and solve
    them by brute force with linear algebra.  I may have to if I need
    to investigate stability with respect to some component of the
    circuit.  Or I can apply (ulp) transformations and other models
    to the circuit.  By successive source transformations, I can
    reduce parts of it to simple, two-terminal Thevenin or Norton
    equivalents.  I can model parts of it as three-terminal networks.
    I can model it as a two-port network with a transfer function
    and input and output equivalent circuits.  If I am interested
    in stability, I can find the poles of the system response, and
    then apply the Nyquist stability criterion, and after that,
    root-locus techniques.  I can apply Routh's rule to the
    characteristic equation.  I can model the system with block
    diagrams OR signal flow diagrams.  I can ...

    Each of these things can offer me insight that would be
    difficult to extract from the linear equations, and might
    be clear from a graphical solution only if I found the
    right couple of things to graph.

So far as I can tell, we have no way to do that with interacting
state machines.

In _this_ sense, our use of the word `analysis' is fundamentally
different from the use of the word by an engineer in a traditional
physical discipline.

And that traditional use was my intended meaning in the phrase
`analytic model.'

On the other hand, I _would_ consider your competition models
(monitor, assigner) to be analytic models.  Likewise the description
of systems as bottom-driven and top-driven.

> P.S.  Stay tuned for a continuation article from Steve Mellor.

I mean to reply to it; I think I have an angle on it that's been
missed--a real engineering angle at that.  Same mole-time, same
mole-channel, y'all hear!
--
 (This man's opinions are his own.)
 From mole-end                Mark Terribile

 [e-mail], Somewhere in Matawan, NJ