NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/object/3031

Text File | 1992-07-27 | 5.8 KB | 128 lines

Newsgroups: comp.object
Path: sparky!uunet!projtech!sally
From: [e-mail] (Sally Shlaer)
Subject: Thoughts on the Progression from SA/SD Models to OO Models
Message-ID: <[e-mail]>
Organization: Project Technology, Inc., Berkeley, CA
Date: Tue, 28 Jul 1992 02:14:55 GMT
Lines: 118

I would like to submit a clarification to the posting by Mark Terribile on 27 July.
The posting does not identify the OO method that is being discussed,
and may therefore be confusing to some readers.
I am not intimately familiar with all OO methods, but
can comment on Shlaer-Mellor OOA, the OMT of Rumbaugh et al.,
and the Coad-Yourdon method.

> In the Object world, there is usually a Class-Relationship or
> Object-Relationship diagram depicting the existential relationships
> between them, and usually the Inheritance relationships as well.  This
> corresponds pretty closely to the E/R diagram of the data model.
>
Quite right.  The Object-Relationship diagram is called an
    Information Model in Shlaer-Mellor
    Object Model in Rumbaugh.
    Class-and-Object model in Coad-Yourdon

> There is also an Object-Communication diagram depicting the message
> communication between objects.

There is an Object Communication Model in Shlaer-Mellor OOA.  The
Object Communication Model depicts asynchronous communication
between objects.  There is also a Object Access Model in Shlaer-Mellor.
The OAM depicts *synchronous* communication between objects.

There is no model corresponding to the Object Communication Model or
Object Access Model in the Rumbaugh method.  There is an informal
sketch called the Event Trace that presents a subset of such information,
but this is described more as an initial mind-jogger for
the analyst, and not as a work product for the method.

There is no model in Coad-Yourdon that shows message
communication between objects.

> Notice that the Dynamic Model, represented by the State Machine, has
> no clear correspondence to the Object Model.
>
In Shlaer-Mellor a state machine corresponds to an object
or a relationship on the Information Model.

A special "Assigner" state model is used to manage relationships
that express competition or contention.

In Rumbaugh, there is one state model for each object appearing
on the Object Model.  Rumbaugh does not have state models for
relationships, and does not propose a scheme for dealing with
contention.

Coad-Yourdon allow you to have a state model for an object
from the Classes-and-Instances diagram.
This is presented with little detail, since it is described as a
"secondary strategy" in this method.


> For the OO, Schlaer and Mellor have attempted to produce stable state
> machines by identifying stable state-features in the problem.  It's an
> interesting approach; I'm not convinced that it is as valuable as Schlaer
> and Mellor make it out to be.  Nevertheless, it does not have any close
> correspondence with the SA/SD state machine, which is intimately tied to
> the structure of the Process Model.

Correct.  In SA/SD (here I assume you mean Ward-Mellor or Hatley-Pirbhai)
the state machines are used to turn the processes on and off.  As Mark
points out (earlier in the posting), this kind of state machines are
tightly coupled with the process models -- they are unstable together,
if you will (less so in Ward-Mellor, but the point is well taken.)

Shlaer_Mellor state machines model the lifecycles of objects.
These state machines are much more stable, since they are based on the
semantics of the problem, and are not connected with any kind of
arbitrary decision an analyst must make -- here I am referring to
the kinds of arbitrary decisions one makes in doing a functional
decomposition in the classical DeMarco SA.


> It appears we need something better than the current State Model approach, if
> only because the State Model isn't well integrated into the other models.

The three methods (Shlaer-Mellor, Rumbaugh, and Coad-Yourdon exhibit very
different degrees of integration, as follows:

In Shlaer-Mellor, there are state models for each object and
relationship on the Information Model.
The actions of the State Models are then broken down into
elementary processes (no functional decomp -- the objects and actions
have already partitioned the problem along object lines).
Each action is depicted on a separate small Action Data Flow
Diagram.
There are strong guidelines for partitioning the
action into the processes, and rules by which the processes
are assigned to the objects on the Information Model.
In addition, all the data on the Action DFD must correspond
to the attributes shown on the Information Model.
So there is a very high degree of integration.  In fact,
there is a sufficient degree of definition and integration
that **the analysis models are entirely executable**.

In the Rumbaugh method, there are state models for each object
(but not relationship) on the information model.  The Process
Model is built by successive decomposition, so you get a deeply layered
set of DFDs.  I did not find guidelines for decomposing the
processes or associating them with objects, but the processes do
turn into methods on the Object Model.
It is asserted that the State Models in this method tell you
when the processes run, but I have been unable to work out exactly
what the rules are on that.  Perhaps someone else out there in
netland can explain that aspect of the integration.

Coad-Yourdon does not have a Process Model.  They
encourage the analyst to identify the required methods and
put them on the Classes-and-Instances diagrams, but don't
provide a lot of guidance as to how to do that.  They do show
one state model in the book, but it isn't discussed much --
only two pages, and it doesn't appear in the index, either.
So this method appears to have a bit less in the way of
integration.

Sally Shlaer         [e-mail]