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

Text File | 1992-07-28 | 7.3 KB | 154 lines

Newsgroups: comp.object
Path: sparky!uunet!portal!ntmtv!irvine
From: [e-mail] (Chuck Irvine)
Subject: Re: Thoughts on the Progression from SA/SD Models to OO Models
Message-ID: <1992Jul28.175326.10956@ntmtv>
Sender: irvine@ntmtv (Chuck Irvine)
Nntp-Posting-Host: nmtvs318
Organization: Northern Telecom Inc, Mountain View, CA
References:  <[e-mail]>
Date: Tue, 28 Jul 1992 17:53:26 GMT
Lines: 141

I find this comparison to be extremely useful and interesting. Thanks very much
to Ms. Shlaer. It would be equally useful and interesting to get the views of
other OOA/OOD leaders on how their approach compares and contrasts with the
approaches of their colleagues.

In article <[e-mail]>, [e-mail] (Sally Shlaer) writes:
|> 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

I think a significant aspect of the Information Model as
described in Shlaer-Mellor is the fact that it (seems) heavily influenced
by the dictates and constraints of relational database modelling techniques.
In my opinion, the relational view of data is not as general or natural as
the object oriented view. While in some cases a relational model of data
will be most appropriate, in other cases it surely will not be. I'm a bit
concerned that the Shlaer-Mellor might force, or at least coerce, implementations
to adopt the relational modelling of data.

Any comments?

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

FYI- Booch has something that is at least roughly equivalent to the Object
Communication Model. He calls it an object diagram.


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