From @BNRCARTA:Janet.Noye.5E22@BNR Thu Jul 16 13:26:21 1992
Date: 16 Jul 92 16:27:00 EDT
To: <IRVINE@NTMTV> (Charles R. Irvine :Dept 4K31)
From: <Janet.Noye.5E22@BNR> (Janet J. Noye :Dept 5E22)
Subject: re. comp.object posting
Sender: <Janet.Noye.5E22@BNR> (Janet J. Noye :Dept 5E22)
Content-Length: 727
X-Lines: 19
Status: RO
Hi Chuck,
I saw your posting about OOA/OOD on comp.object. There are a number of groups
throughout BNR that are, like you, starting to do some OOA/OOD. I wanted to
make certain that you knew about the bnr.lang.c++ news group, just in case
you are a C++ programmer.
I am looking into OOA/OOD methodologies for my group and have found a few
groups in BNR using Shlaer/Mellor and one in RTP that is evaluating Booch
and their tools Rose.
I have been trying to keep track of what OO and C++ work is going on in the
company. I would appreciate it if you could give me a short description
of the project you are working on and what your impressions are of the
tools and methodologies that you are using now.
Thank you,
Janet
From irvine Thu Jul 16 13:56:18 1992
Date: Thu, 16 Jul 92 13:56:17 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: Help: OOA and OOD Methodologies - comp.object #6323
Content-Length: 1931
X-Lines: 40
Status: RO
In article <1992Jul16.182124.25270@cbfsb.cb.att.com>, vicki@cbnewsg.cb.att.com (marie.ellen.glezman) writes:
|> In article <1992Jul15.002425.14891@ntmtv> irvine@ntmtv.UUCP (Chuck Irvine) writes:
|> >The company I work for is interested in pursuing the possible benefits of OOA and OOD. As such we have brought in a company called Project Technology to train us in their version of these. My question is would anyone like to comment on the pros and cons |> of the approach as presented by this company - essentially they teach the methodology as described in the two books by Sally Shlaer and Stephen Mellor. A discussion of the pros and cons of the methodologies as formulated by others would also be helpf
|>
|>
|>
|>
|>
|>
|> a
|> >
|> >
|> >
|> >
|> >nks for your help.
|> >
|> >Chuck Irvine
|> >ames!ntmtv!irvine
|>
|> I work for an organization that helps other organizations in our company
|> select and apply specification techniques. Approximately a year ago, I
|> researched several popular Object Oriented Methodologies (OOM) and selected
|> the Shlaer/Mellor (S/M) approach. I felt that their methodology was
|> excellent in that it built on structured techniques while eliminating the
|> limitations of structured techniques, it was easier to apply than several
|> of the methodologies examined, had much better trainning for the practitioner,
|> offered consulting from a group of highly competent professionals (although
|> we usually provide this support inside our company) and is supported by a
|> reputable tool vender(CADRE).
|> During the last year I have been in contact with several organizations who have
|> used S/M to develop their analysis models and they have all expressed postive
|> experiences using the analysis techniques. We have less experience with
|> recursive design but feel that it will meet our expectations.
|> Vicki Glezman
|>
|> 908-615-4207
|> vicki@bhopal.att.com
|>
|>
|>
From irvine Thu Jul 16 14:02:08 1992
Date: Thu, 16 Jul 92 14:02:07 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: Shlaer-Mellor OOA Model - comp.object #6324
Content-Length: 1294
X-Lines: 20
Status: RO
In article <1992Jul16.192639.6176@ntmtv>, squierts@ntmtv.UUCP (Tony Squier) writes:
|> Regarding the Shlaer/Mellor Method. I am also new to the method and I
|> am curious what others think about the approach. One of the areas I
|> would like some help with is regarding the implementation phase of the method.
|> My understanding is that their method does not assume that an Object-Oriented
|> Programming Language is being used. Thus, one could do an OOA/OOD and implement
|> the design in a non-OO programming language. The question I have, is what are the
|> advantages and disadvantages of doing the OOA/OOD then implementing in
|> a non-OOPL? I myself can see some problems with this, in part when it comes to
|> maintaining the software. It appears to me that any changes to the software would
|> require a complete re-design, rather then building on what you've got already.
|> Note, I've only seen the Analysis part of the Shlaer/Mellor method and am waiting
|> to see how the analysis maps into a design, then an implementation.
>The company I work for is interested in pursuing the possible benefits of OOA and OOD. As such we have brought in a company called Project Technology to train us in their version of these. My question is would anyone like to comment on the pros and cons of the approach as presented by this company - essentially they teach the methodology as described in the two books by Sally Shlaer and Stephen Mellor. A discussion of the pros and cons of the methodologies as formulated by others would also be helpfu
>nks for your help.
I read the S/M book Object-oriented systems analysis which was
published in 1988. This was a very lightweight work which had little
to do with OOA. Primarily it simply restated some of the basics of
Structure analysis, but used some of the terminology of OOA (i.e. they
used the word "object" occasionally).
I have heard that their more recent works are better, but havent read
them yet.
My recommendation, however, is to stay away from the evolutionary
pathway of SA->OOA and SD->OOD. Here there be dragons (IMHO).
Rather, you might want to study the work of Rumbaugh and Booch. These
works are along the direct path to OOA and OOD, and do not depend on
an evolution from the structured techniques.
---------------
I am an independent consultant specializing in OOA/OOD and C++. I
provide design and development consulting as well as training in OOA,
OOD and C++. Should you have any need of my services, please do not
hesitate to call.
From irvine Fri Jul 17 14:33:46 1992
Date: Fri, 17 Jul 92 14:33:45 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: Need Feedback on OOA/OOD Methodologies - comp.object #6332
Content-Length: 1654
X-Lines: 46
Status: RO
In article <1992Jul17.132620.20063@aragorn.unibe.ch>, hueni@iam.unibe.ch (Hermann Hueni) writes:
|> In article 1360001@hpcc01.corp.hp.com, fariba@hpcc01.corp.hp.com (Fariba Mehran) writes:
|> Hello,
|>
|> Our group is in the process of selecting an Object Oriented
|> methodology. We have been looking at Booch, Rumbaugh, and Shlaer/
|> Mellor OOA/OOD methods. If you have used any of the above methods
|> or know of a better one, please respond to me either to this note or
|> to my email address. I'd like to hear your experiences before
|> deciding on one method.
|>
|> Last year I was teching to under-graduate students object-oriented design
|> based on CRC, RDD and the Booch notation.
|>
|> A second person (having a lot of experience with TEAMWORK and SA/SD)
|> was in charge of teaching OOA. He selected the Shlaer/Mellor approach.
|>
|> The students got very confued because of the Shlaer/Mellor
|> mixture of classes with objects.
|>
|> At the end of the course, we both presented the analysis/design of
|> a complete example.
|> My impression about the Shlear/Mellor approach is "a big mess".
|> I feel especially hard to understand how all the partial views
|> fit together.
|>
|> I believe that a mixture of CRC (beck, cunningham),
|> RDD (rebecca wirfs-brock, brian wilkerson) and ideas from the Booch notation
|> provide much much more OO than any of the refitted SA/SD approaches
|> like Shlaer/Meller, Coad, etc.
|>
|> hueni@optolab.unibe.ch
|>
|>
|>
|>
|>
|> Thank you very much
|>
|> Fariba Mehran
|>
|> fariba@hphome.mayfield.hp.com
|>
|>
|>
|>
From irvine Fri Jul 17 14:33:10 1992
Date: Fri, 17 Jul 92 14:33:09 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: Help: OOA and OOD Methodologies - comp.object #6334
Content-Length: 1954
X-Lines: 39
Status: RO
In article <2A66F3CE.13821@ics.uci.edu>, song@berault.ics.uci.edu (Xiping Song) writes:
|> >
|> > ....
|> >I work for an organization that helps other organizations in our company
|> >select and apply specification techniques. Approximately a year ago, I
|> >researched several popular Object Oriented Methodologies (OOM) and selected
|> >the Shlaer/Mellor (S/M) approach. I felt that their methodology was
|> >excellent in that it built on structured techniques while eliminating the
|> >limitations of structured techniques, it was easier to apply than several
|> >of the methodologies examined, had much better trainning for the practitioner,
|> >offered consulting from a group of highly competent professionals (although
|> >we usually provide this support inside our company) and is supported by a
|> >reputable tool vender(CADRE).
|> >During the last year I have been in contact with several organizations who have
|> >used S/M to develop their analysis models and they have all expressed postive
|> >experiences using the analysis techniques. We have less experience with
|> >recursive design but feel that it will meet our expectations.
|> >Vicki Glezman
|> >
|> >908-615-4207
|> >vicki@bhopal.att.com
|>
|> One possible strength (or weakness to some people) is that Shlaer/Mellor
|> method describes the object-oriented concept from the view of the relatioanl
|> data model. This is very comprehensible for the people who have the relational
|> modeling experiences.
|>
|> Shlaer/Mellor's classification on the attributes is unique and more
|> explicit than other OODs. (referece, naming, descriptive, ...)
|>
|> Shlaer/Mellor's classification on the relationships between classes(objects)
|> is unique. It is based on the mapping relationships (1-1, 1-m, n-m, conditional
|> 1-1, ...). This might be most useful for certain application domains.
|>
|> Its weakness is on descrbing operation parts of an object.
|>
|> --Song
|>
|>
From irvine Fri Jul 17 16:25:00 1992
Date: Fri, 17 Jul 92 16:24:58 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: SHlaer-Mellor OOA Model, Problem with definition of Object - comp.object #6338
Content-Length: 3368
X-Lines: 62
Status: RO
In article <1992Jul17.203403.8474@projtech.com>, sally@projtech.com (Sally Shlaer) writes:
|> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
|>
|> > irvine@ntmtv.UUCP (Chuck Irvine) writes: (about object and class being
|> > synonyms)
|> >
|> > >You could probably argue either way. Sometimes "object" is used synonymously
|> > >with the term "instance", but sometimes, it seems, its also used as a generic
|> > >term denoting both classes and instances.
|> >
|> > Lots of analysts do this, and it drives me crazy. The class/instance
|> > distinction is important, and they are throwing it away for no reason
|> > that I can see. I've heard several explanations (sometimes it is hard
|> > to tell whether there is more than on instance, it is easier for
|> > structured folks to understand) but none of them convince me. I would
|> > like to know why they do this.
|> >
|> Let me try to explain the terminology used in Shlaer-Mellor OOA
|> (netters seem to have it almost right, but may be missing a fine point).
|>
|> In OOA, we use "object" to mean a single, typical but *unspecified* instance.
|> So a Car object means a single car, I don't care which one. Most OODers
|> today (I think) would find this a reasonable use of the word object.
|>
|> If OOA wants to talk about a *collection* of *unspecified* instances (say a
|> Fleet of Cars), it captures the idea as a new object: It is our perspective that
|> a collection is itself a respectible conceptual entity with properties
|> and behavior above and beyond the properties and behavior of the instances.
|> So a Fleet could have attributes that indicate the policies pertaining to the Fleet:
|> Maximum mileage permitted between overhauls, maximum price to pay for
|> a new vehicle, etc.
|>
|> Note that by abstracting a new object as Fleet, we now can support *multiple*
|> fleets in the analysis: Now we can reason about a typical unspecified Fleet.
|>
|> Now let us switch over into OOD land. As I see it,
|> the word "class" today combines two ideas:
|> + the typical unspecified instance (I don't care which instance
|> you are thinking about, this operation works the same way on any instance.)
|> + the collection of all existing instances (as in class data, iterators
|> and similar class methods)
|>
|> Consider the Car example. In OOD, you could make a Car class. Suppose that is
|> all you make. Then the fleet concept would be reflected in class data -- but
|> you could only support a single fleet. Alternatively, you could make
|> a Car class *and* a Fleet class. Then you could support multiple fleets, but
|> you would do it in instance data. The second way is more the way OOA thinks
|> about it.
|>
|> In summary, in OOA we are interested in the typical instance. Because we
|> are dealing with analysis, we are not interested in particular instances.
|>
|> As far as the collection idea goes, either
|> we aren't interested at all (so we don't need an additional word), or
|> we're sufficiently interested that we look at the **typical**
|> **collection** -- in which case we'd abstract that as an object.
|>
|> So, I assert that OOA isn't throwing away the class/instance distinction --
|> OOD is mixing together ideas of instance and collection. :-)
|>
|> For ever-increasing hair-splitting,
|> Sally Shlaer sally@projtech.com
From irvine Fri Jul 17 19:13:12 1992
Date: Fri, 17 Jul 92 19:13:11 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: SHlaer-Mellor OOA Model, Problem with definition of Object - comp.object #6341
Content-Length: 1879
X-Lines: 41
Status: RO
In article <1992Jul17.205419.8754@projtech.com>, pryals@projtech.com (Phil Ryals) writes:
|> In article <2639@abcom.ATT.COM> brr@abcom.ATT.COM (Rao) writes:
|> >
|> >In their book on OOA, Shlaer and Mellor provide the following
|> >definition of an object:
|> >
|> >Def: An object is an abstraction of a set of real-world
|> >things such that -
|> >
|> > . all of the real world things in the set - the instances -\
|> > have the same charecteristics
|> > . all instances are subject to and conform to the same rules.
|> >
|> >This definition of an "Object" seems to me similar to the
|> >definition of a "Class" in C++ type environments.
|> >
|> >Question:
|> >Are the authors misusing the term Object and using Object where they
|> >should have been using "Class"?
|> >
|> >-BINDU RMA RAO
|>
|> I think your misunderstanding comes from mixing the concepts of OOA and OOD.
|> In OOA we are striving to understand the conceptual entities (= objects) in
|> the problem, hence the definition of object as given in the book. That such
|> abstractions can be drawn is independent of whether we *EVER* consider the
|> object-oriented design concept of "class." We can do OOA on a system and
|> happily code up an implementation of the system in a conventional language
|> without ever considering classes in any way.
|>
|> Now, at design time, if I choose to implement my system using an OOD, it is
|> true that each analysis object found in the OOA will be implemented by a class
|> in the OOD, but they are separate and distinct concepts as far as I'm
|> concerned.
|>
|> It is unfortunate that "object" is sometimes used in OOD to refer to an
|> instance of a class, which seems to be where the confusion arises. But then
|> I guess name overloading is a way of life in object land. :-)
|>
|> Phil Ryals pryals@projtech.com ...!uunet!projtech!pryals 510/845-1484
|>
From irvine Fri Jul 17 19:12:52 1992
Date: Fri, 17 Jul 92 19:12:51 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: SHlaer-Mellor OOA Model, Problem with definition of Object - comp.object #6342
Content-Length: 2282
X-Lines: 40
Status: RO
In article <1992Jul17.221742.27937@m.cs.uiuc.edu>, johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
|> sally@projtech.com (Sally Shlaer) writes:
|>
|> >In OOA, we use "object" to mean a single, typical but *unspecified* instance.
|> >So a Car object means a single car, I don't care which one. Most OODers
|> >today (I think) would find this a reasonable use of the word object.
|>
|> If I did, I wouldn't have complained!
|>
|> >Now let us switch over into OOD land. As I see it,
|> >the word "class" today combines two ideas:
|> > + the typical unspecified instance (I don't care which instance
|> >you are thinking about, this operation works the same way on any instance.)
|> > + the collection of all existing instances (as in class data, iterators
|> >and similar class methods)
|>
|> I only use "class" for the first concept. It is true that some programming
|> environments (such as Smalltalk) allow you to iterate over all existing
|> instances in a class, but this is metaprogramming, and not part of the
|> standard meaning of class. Like you, I consider a collection of instances
|> to be an object. Moreover, I don't consider a class to be an object during
|> high-level design, even when I am using Smalltalk.
|>
|> >In summary, in OOA we are interested in the typical instance. Because we
|> >are dealing with analysis, we are not interested in particular instances.
|>
|> It seems to me that there are plenty of times in analysis where you are
|> concerned with individual instances. For example, suppose you want to
|> state the rule that a man may not marry his daughter, or that a grandparent
|> is the parent of a parent. The easiest way to do this is to say something
|> like grandparent(x) = parent(parent(x)) where x is a person. But you only
|> can say grandparent(person) = parent(parent(person)), which is wierd.
|> As soon as you have to talk about several people at once, you are in
|> trouble. Perhaps you don't talk about things like this when you do analysis,
|> but it seems to me that it is pretty useful.
|>
|> So, I can't see how you can say that you don't need to talk about individual
|> instances in analysis. You might not need to talk about particular
|> instances, but individual instances is another story.
|>
From ames!bse.com!joseph!joseph Mon Jul 20 07:39:34 1992
From: ames!bse.com!joseph (Joseph E. Richardson)
To: ntmtv!irvine
Subject: Re: Help: OOA and OOD Methodologies
Date: Mon, 20 Jul 92 07:19:41 EDT
Organization: Berard Software Engineering, Inc.
Reply-To: ames!bse.com!joseph (Joseph E. Richardson)
X-Mailer: uAccess - Macintosh Release: 1.6v0
Content-Length: 1330
Status: RO
X-Lines: 24
In Regards to your letter <9207171716.AA01270@nmtvs318.mtvyp>:
> > Personally, I find their (Shlaer and Mellor's) approach to be little
> > more than window dressing for more traditional methods. I think their
> > view of objects revolves too heavily around data. (Note the subtitle
> > of their first book, "... Modeling the World in _Data_". Data is
> > _not_ the same as an object.) This is personal opinion, not really a
> > comparitive list of pros and cons as you asked for. Also, I work for a
> > company that teaches its own OO methods. (Which, of course, we would
> > be glad to tell you about if you're interested. :-) So I'll offer
> > something else...
>
> Thanks very much for your contribution. I will be posting the collection of
> all responses that I get.
I think I would prefer if you left mine out. That is, please don't
