From: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: Re: Help: OOA and OOD Methodologies
Organization: Northern Telecom Inc, Mountain View, CA
Date: Tue, 28 Jul 1992 00:35:45 GMT


A couple of weeks ago I posted the following message to comp.object:


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

Below you'll find the collection of responses. I'll let everyone draw
their own conclusions.

Chuck Irvine
ames!ntmtv!irvine


*************************************************************************
************* Responses
***********************************************************************


From ames!syl.nj.nec.com!rlc Wed Jul 15 07:10:53 1992
From: ames!syl.nj.nec.com!rlc
Date: Wed, 15 Jul 92 09:21:51 EST
To: ntmtv!irvine@uunet.UU.NET (Chuck Irvine)
Subject: Help: OOA and OOD Methodologies	
Content-Length: 1504
X-Lines: 34
Status: RO


Actually, I have recently been reviewing and studing some of the
methodologies that have been coming in the recent times.  NEC is a
member of the OMG (Object Modeling Group) that deals with issues such
as these.  Basically, what the OMG is doing is taking the best of the
best and trying to make a type of "standard".

Shlaer and Mellor's methodology, in my opinion, is losing popularity.
A number of different methodologies are starting to get support from
companies in the form of programs to create diagrams to do such tasks.

Looking at the market right now, it seems that the biggest people
going are:

Martin and Odell
Rumbaugh
Booch
Coad and Yourdan

Although Rumbaugh's methodology has a minimal program associated with
it (OMTool/OMT), I believe that it is especially good since it
contains segments that are very much indepth and complete while still
breaking up the whole picture into three different models (Object,
Functional, and Dynamic).


From ames!cs.utexas.edu!tsoft!mikael Wed Jul 15 08:12:19 1992
Date: Wed, 15 Jul 92 15:32:21 +0200
From: ames!sundsvall.trab.se!Mikael.Eriksson (Mikael Eriksson)
To: ntmtv!irvine@uunet.UU.NET
Subject: Re: Help: OOA and OOD Methodologies
Newsgroups: comp.object
Content-Length: 3579
Status: RO
X-Lines: 101

In comp.object you write:

>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


>Chuck Irvine
>ames!ntmtv!irvine


Hello!

  It sounds to me that your company jumped into the water without
checking the depth first. The Shlaer Mellor method has much
of data modelling in it and not wery much of object orientation. I
suggest that you also take a look at the following:

----
OMT - Object Modeling Technique
Described in the book
  Object Oriented Modeling and Design
  Rumbaugh J + others
  Prentice Hall 1991

A good book which describes the process from analysis to
construction. Chapters about implementing the design with
relational databases and non oo languages. This method
seems to be discussed often at OOPSLA and ECOOP.

Pros: Well thought out. Handles not only the information
modelling but also functionality of the system and the
object states. 
Cons: Nothing about testing and maintainance.
-----
OOSE - Object Oriented Software Engineering
Described in
  Object Oriented Software Engineering
  Ivar Jacobson + others
  Addison-Wesley 1992 (Also ACM Press)

I am reading this at the moment. The method is well thought
out and has been used in many systems. It has its roots in
the method used to build Ericson's AXE phone exchanges.
The book is written in a readable mannar and covers things
that are often overlooked in such books like testing and
the use of components. The modeling contains both information
modeling and modeling of the usage of the system.

They say in the book that OOSE is not really a complete
development method but a subset of Objectory a method
that is sold by Ivar Jacobson's company Objective Systems,
but I think that the material given in the book would
be enough to build an oo system.

Pros: Handles testing and components. The method has been
used in an industrial scale.
Cons: (Opinion only) Too much emphasis on the *use* of a system
in the analysis and too little on modeling reality. If you
want to go further and use Objectory and the tools that comes
with it the package is rather expensive.
-----------
OOA/OOD - The Yourdon/Coad method
Books
- Object Oriented Analysis
  Peter Coad/ Edward Yourdon
  Yourdon Press 1991
- Object Oriented Design  
  Peter Coad/ Edward Yourdon
  Yourdon Press 1991

I thought that this method was rather good when I first read
the books and took the course. However after seeing the methods
above I think that OOA/OOD takes a too narrow approach. The
only do the object modeling and nothing about the functionality
and the states of the objects. However the books are very
good on how to find the objects and their attributes and
operations so the (especially OO Analysis) might be used as
inspirational litterature when using som other method.

Pros: Well written book. Lots of advice on how to find the clases.
They sell an inexpensive tool that support their notation. Easy
to find commersial courses.

Cons: Too narrow approach. No testing or usage of components.


---------------


  Hope this will help. Could you please send be a summery of the
answers you get. (No need for this if you send it to the net.)



    Mikael

From irvine Wed Jul 15 15:17:46 1992
Date: Wed, 15 Jul 92 15:17:45 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: Help: OOA and OOD Methodologies - comp.object #6309
Content-Length: 1646
Status: RO
X-Lines: 32

In article <1992Jul15.165208.21272@cs.umn.edu>, shekar@cs.umn.edu (Shekhar Kirani) writes:
|> In <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.  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 helpful
|> 
|> >Chuck Irvine
|> >ames!ntmtv!irvine
|> 
|> Hi,
|> 
|> There is a case study done in our group comparing Shlaer amd Mellor's 
|> method, Coad and Yourdon's method and Document Driven Method (our own
|> method). A Technical report "A Case Study to Evaluate Three Object Oriented
|> Analysis Techniques" is available as a technical report at CS Dept, Univ
|> of Minnesota. And our own method DDA is also available as technical report.
|> Our study has identified pros and cons of each of these and the application
|> area to which these methods are more suitable. Contact jmdrake@cs.umn.edu
|> if you need either the technical reports or more details about the case
|> study.
|> 
|> Shekhar Kirani
|> ----------------------------------------------------------------
|> Shekhar Kirani				Computer Sc. Dept, 200
|> 1530, S.6th. St., C-410			Union St., Univ. of Minnesota
|> Minneapolis, MN-55454.			Minneapolis, MN-55455.
|> Ph: (home) 612-341-0256. 		(off)  612-625-4029.
|> ----------------------------------------------------------------

From irvine Wed Jul 15 15:25:33 1992
Date: Wed, 15 Jul 92 15:25:32 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: Help, Need Tools for OO Modeling, OO Analysis - comp.object #6305
Content-Length: 784
Status: RO
X-Lines: 26

In article <1992Jul14.162013.28@iris-dcp.es>, taf_heras@iris-dcp.es writes:
|> In article <2638@abcom.ATT.COM>, brr@abcom.ATT.COM (Rao) writes:
|> > 
|> > 
|> > I have been asked to help identify tools that can be used
|> > for Object-Oriented Modeling, Object-Oriented Requirement
|> > Analysis, and Object-Oriented Design.
|> > 
|> > I would like to request some info on such tools from knowledgeable
|> > netters.
|> > 
|> > Thanks in advance.
|> > 
|> > -bindu rama rao
|> > att.com!uxcom!brr
|> > 
|> > (708)-293-0633
|> 
|> 	Hello. Try in Versant, they distribute a tool developed by Rumbaugh,
|> wich serves for modeling using his known OMT (Object Modeling Technique).
|> 
|> 	Another: the one from Peter Coad, wich modelizes using OOA as defined
|> by Coad.
|> 
|> 	Bye.
|> 

From ames!syl.nj.nec.com!rlc Wed Jul 15 19:14:56 1992
From: ames!syl.nj.nec.com!rlc
Date: Wed, 15 Jul 92 22:13:39 EST
To: ntmtv!irvine@uunet.UU.NET (Chuck Irvine)
Subject: Help: OOA and OOD Methodologies	
Content-Length: 932
Status: RO
X-Lines: 21

> Really appreciate your input. One thing - could you say
> why you think Shlaer and Mellor's methodology is losing popularity?
> Thanks, again.

Well, the answer kind of has to do with the history of Shlaer and
Mellor.  The first version of their book was designed after
"Structured Analysis and Structured Design" (SA/SD).  With the
evolution of OOD/OOA, they came out with their second book which
basically took their last book and added some things.  The problem is
that is just lacks, in my opinion, compared to some of the other
methodologies.

I am not saying that this methodology is bad.  Perhaps, rather, there
are better methodologies for particular tasks.  If you could give me
an input of what the application of this training is going to be
towards, I could probably tell you a little bit more about which would
be the better methodology.

Would you care to have titles of books by the authors that I have
mentioned?


From ames!decwrl!alberta!agt!aguilla Wed Jul 15 21:07:25 1992
Date: Wed, 15 Jul 1992 11:34:56 +0100
From: ames!cs.ualberta.ca!agt!aguilla
To: ntmtv!irvine
Subject: OOA
Content-Length: 1899
X-Lines: 43
Status: RO

Dear Chuck:

I am in the process of reading (carefully) the book by Shlaer and Mellor in

order to assess whether they have been able to document a consistent set of
rules that will make OO analysis as powerful as some claim it can be.

My problem domain (telecommunications) is rather complex and any investment
in methodology better work!

In general, OO is state of the art, and any other modeling methodology does
not
come close. I have found other OO documented methodologies rather weak in
some 
areas such as communicating entities and concurrent time dependent
situations. Its not that OO in itself is weak, just the many rules to
ensure implementation and testing is less problematic is very difficult to
get together. 

I would appreciate if we could compare notes as your company goes through
the
training. Feel free to bounce any comments off in my direction, and if you
wish,
I can forward questions I have to you.

I am getting the feeling that a methodology such as in the book works well
only if there is a corresponding tool which enforces the rules. Voluntary
compliance leads to shortcuts and (small) rule violations making it more
difficult for 
implementation.

On what grounds did your company decide to try Shlaer and Mellor?


+------------------------------+--------------------------------------+
+ August Guillaume             + Internet:                            +
+ Senior Researcher            +  aguilla%agt.uucp@cs.ualberta.ca     +
+ AGT Research & Development   +                                      +
+ 500 Capitol Square           +                                      +
+ 10065 - Jasper Ave           +    Voice: (403) 493-3677             +
+ Edmonton, Alberta CAN        +      Fax: (403) 493-4277             +
+ T5J-3B1                      +                                      +
+------------------------------+--------------------------------------+

From hattingh@nmtvs254 Thu Jul 16 11:44:12 1992
From: hattingh@nmtvs254 (Christina Hattingh)
Date: Thu, 16 Jul 92 11:31:00 PDT
Subject: Re:OOA
To: irvine@ntmtv
Content-Length: 3991
X-Lines: 93
Status: RO

In the stuff we had done (CCR and M911) this methodology (in my view)
did not work out at all well. The part that seems helpful is the
Analysis (information model). The desgin stage is iffy and the recursive
design (low level design) was next to useless. The methodology bogs down
so much into notation and rules that the development becomes prohibitive
- you spend all your time figuring out what notation to use next and
what diagram to draw and forget completely about designing the system
you're supposed to build.

that may be OK for educational/academic developments, it sure doesn't do
the trick for commercial developments that have tight deadlines and
customers on the other side.

I'm not at all a supporter of rules and notations. Methodologies should
teach/enforce concepts - that is what is fundamental to a good
design - a good grasp of the concepts and the problem. How you choose to
represent them is immaterial so long as everybody on the project does it
the same way and understands each other.

I also found that the Sclaer/Mellor methodology did not address
real-time systems (eg. time dependent issues as pointed out below), or
even how the mass of objects in the high level design should break out
into processes. Inter-process communication and inter-processor (multi-
CPU) communication is not at all addressed so we resorted to traditional
design/experience to do that part of the project.

All in all we have had mixed results applying the technology. I think we
have some pieces of code that turned out well, but we also have some of
the worst written code in history produced by ostensibly following this
methodology.

CH

>  
>  ----- Begin Included Message -----
>  
>  >From ames!decwrl!alberta!agt!aguilla Wed Jul 15 21:07:25 1992
>  Date: Wed, 15 Jul 1992 11:34:56 +0100
>  From: ames!cs.ualberta.ca!agt!aguilla
>  To: ntmtv!irvine
>  Subject: OOA
>  Content-Length: 1899
>  
>  Dear Chuck:
>  
>  I am in the process of reading (carefully) the book by Shlaer and Mellor in
>  
>  order to assess whether they have been able to document a consistent set of
>  rules that will make OO analysis as powerful as some claim it can be.
>  
>  My problem domain (telecommunications) is rather complex and any investment
>  in methodology better work!
>  
>  In general, OO is state of the art, and any other modeling methodology does
>  not
>  come close. I have found other OO documented methodologies rather weak in
>  some 
>  areas such as communicating entities and concurrent time dependent
>  situations. Its not that OO in itself is weak, just the many rules to
>  ensure implementation and testing is less problematic is very difficult to
>  get together. 
>  
>  I would appreciate if we could compare notes as your company goes through
>  the
>  training. Feel free to bounce any comments off in my direction, and if you
>  wish,
>  I can forward questions I have to you.
>  
>  I am getting the feeling that a methodology such as in the book works well
>  only if there is a corresponding tool which enforces the rules. Voluntary
>  compliance leads to shortcuts and (small) rule violations making it more
>  difficult for 
>  implementation.
>  
>  On what grounds did your company decide to try Shlaer and Mellor?
>  
>  
>  +------------------------------+--------------------------------------+
>  + August Guillaume             + Internet:                            +
>  + Senior Researcher            +  aguilla%agt.uucp@cs.ualberta.ca     +
>  + AGT Research & Development   +                                      +
>  + 500 Capitol Square           +                                      +
>  + 10065 - Jasper Ave           +    Voice: (403) 493-3677             +
>  + Edmonton, Alberta CAN        +      Fax: (403) 493-4277             +
>  + T5J-3B1                      +                                      +
>  +------------------------------+--------------------------------------+
>  
>  
>  ----- End Included Message -----
>  
>  



From irvine Thu Jul 16 12:14:30 1992
Date: Thu, 16 Jul 92 12:14:28 PDT
From: irvine (Chuck Irvine)
To: hattingh@nmtvs254
Subject: Re:OOA
Cc: irvine
Content-Length: 5131
X-Lines: 118
Status: RO

Christina,

Thanks for sharing your insight gained from real world experience, which
is where "the rubber hits the road" as they say. I intend to post the
collection of responses that I get to the net and would like to include yours.
Do you mind? I would be sure to edit out people, project, and company names. 
Also, do you mind if I forward it to the people in the lab that I`ve been forwarding
all these other messages to?

What I'm finding is that there are major differences in OOA/OOD depending
on which authority you're reading. The thing that so far seems most common
from approach to approach
is the technique for modelling the domain by identifying the objects and
relationships. After that the approaches start to diverge considerably.


Chuck

> From hattingh@nmtvs254 Thu Jul 16 11:44:12 1992
> From: hattingh@nmtvs254 (Christina Hattingh)
> Date: Thu, 16 Jul 92 11:31:00 PDT
> Subject: Re:OOA
> To: irvine@ntmtv
> Content-Length: 3991
> 
> In the stuff we had done (CCR and M911) this methodology (in my view)
> did not work out at all well. The part that seems helpful is the
> Analysis (information model). The desgin stage is iffy and the recursive> design (low level design) was next to useless. The methodology bogs down
> so much into notation and rules that the development becomes prohibitive
> - you spend all your time figuring out what notation to use next and
> what diagram to draw and forget completely about designing the system
> you're supposed to build.
> 
> that may be OK for educational/academic developments, it sure doesn't do
> the trick for commercial developments that have tight deadlines and
> customers on the other side.
> 
> I'm not at all a supporter of rules and notations. Methodologies should
> teach/enforce concepts - that is what is fundamental to a good
> design - a good grasp of the concepts and the problem. How you choose to
> represent them is immaterial so long as everybody on the project does it
> the same way and understands each other.
> 
> I also found that the Sclaer/Mellor methodology did not address
> real-time systems (eg. time dependent issues as pointed out below), or
> even how the mass of objects in the high level design should break out
> into processes. Inter-process communication and inter-processor (multi-
> CPU) communication is not at all addressed so we resorted to traditional
> design/experience to do that part of the project.
> 
> All in all we have had mixed results applying the technology. I think we
> have some pieces of code that turned out well, but we also have some of
> the worst written code in history produced by ostensibly following this
> methodology.
> 
> CH
> 
> >  
> >  ----- Begin Included Message -----
> >  
> >  >From ames!decwrl!alberta!agt!aguilla Wed Jul 15 21:07:25 1992
> >  Date: Wed, 15 Jul 1992 11:34:56 +0100
> >  From: ames!cs.ualberta.ca!agt!aguilla
> >  To: ntmtv!irvine
> >  Subject: OOA
> >  Content-Length: 1899
> >  
> >  Dear Chuck:
> >  
> >  I am in the process of reading (carefully) the book by Shlaer and Mellor in
> >  
> >  order to assess whether they have been able to document a consistent set of
> >  rules that will make OO analysis as powerful as some claim it can be.
> >  
> >  My problem domain (telecommunications) is rather complex and any investment
> >  in methodology better work!
> >  
> >  In general, OO is state of the art, and any other modeling methodology does
> >  not
> >  come close. I have found other OO documented methodologies rather weak in
> >  some 
> >  areas such as communicating entities and concurrent time dependent
> >  situations. Its not that OO in itself is weak, just the many rules to
> >  ensure implementation and testing is less problematic is very difficult to
> >  get together. 
> >  
> >  I would appreciate if we could compare notes as your company goes through
> >  the
> >  training. Feel free to bounce any comments off in my direction, and if you
> >  wish,
> >  I can forward questions I have to you.
> >  
> >  I am getting the feeling that a methodology such as in the book works well
> >  only if there is a corresponding tool which enforces the rules. Voluntary
> >  compliance leads to shortcuts and (small) rule violations making it more
> >  difficult for 
> >  implementation.
> >  
> >  On what grounds did your company decide to try Shlaer and Mellor?
> >  
> >  
> >  +------------------------------+--------------------------------------+
> >  + August Guillaume             + Internet:                            +
> >  + Senior Researcher            +  aguilla%agt.uucp@cs.ualberta.ca     +
> >  + AGT Research & Development   +                                      +
> >  + 500 Capitol Square           +                                      +
> >  + 10065 - Jasper Ave           +    Voice: (403) 493-3677             +
> >  + Edmonton, Alberta CAN        +      Fax: (403) 493-4277             +
> >  + T5J-3B1                      +                                      +
> >  +------------------------------+--------------------------------------+
> >  
> >  
> >  ----- End Included Message -----
> >  
> >  
> 
> 
> 

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
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.  
|> 
|> 
|> Thanks.
|> =================================================================================
|> 			    Tony Squier
|> 			squierts@ntmtv.bnr.ca
|> =================================================================================

From irvine Thu Jul 16 17:30:42 1992
Date: Thu, 16 Jul 92 17:30:41 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Shlaer/Mellor Methodology... - comp.object #6327
Content-Length: 2562
X-Lines: 46
Status: RO

In article <RLC.92Jul17071912@phoenix.syl.nj.nec.com>, rlc@syl.nj.nec.com (Richard Chung) writes:
|> It has been stated before, even on this board, that that Shlaer and
|> Mellor's methodology is a bit cluttered.  Their first book was based
|> on Structured Analysis and Structured Design.  Their second book, was
|> more or less the same thing except trying to change to OOD and OOA.
|> While it is true this is fine for information modeling, it does not
|> address many of the issues that OOD and OOA methodologies such as
|> Coad/Yourdon, Martin/Odell, Booch, and Rumbaugh address.
|> 
|> >> 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 
|> 
|> The interesting part of this post is "a year ago".  I am don't mean to
|> pick on people or be one of those nity picky people but a number of
|> books have come out since that time.  While one can say that CADRE
|> (which by the way is not that bad of a tool) supports S/M, many of the
|> other methods have reputable companies backing them up.  
|> 
|> My point is basically this.  S/M, in my opinion, is limited in some
|> respects and should be rethought out.  After reading the books, I just
|> get this feeling that they were trying to "reuse" their previous book
|> and SA/SD have enough differences to OOD/OOA that it deserves a whole
|> new appoach.
|> 
|> --
|> 
|> Rich Chung
|> rlc@syl.nj.nec.com
|> 4 Independance Way				Work: (609) 734-6141
|> NEC Systems Laboratory				Fax:  (609) 734-6001
|> Princeton, New Jersey 08540			Home: (609) 921-7193

From ames!bse.com!joseph!joseph Thu Jul 16 23:09:21 1992
From: ames!bse.com!joseph (Joseph E. Richardson)
To: ntmtv!irvine
Subject: Re: Help: OOA and OOD Methodologies
Date: Thu, 16 Jul 92 09:13:09 EDT
Organization: Berard Software Engineering, Inc.
Reply-To: ames!bse.com!joseph (Joseph E. Richardson)
X-Mailer: uAccess - Macintosh Release: 1.6v0
Content-Length: 2080
X-Lines: 36
Status: RO


In article <1992Jul15.002425.14891@ntmtv> (irvine@ntmtv.UUCP), you write:
> 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 helpful.

My first comment would be that I wonder a little why you are asking
for opinions when you've already hired someone to come in.  I suppose
you could have hired them on a trial basis. Still,...

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

In the July 1992 issue (Vol.3, No. 9) of "Hotline on Object-Oriented
Technology" there is a review of Shlaer and Mellor's second book.
If you can not get a hold of a copy, I would be glad to fax or mail
a copy to you. (The review is, in general, not positive.)

--------Address--------Phone Number-------FAX Number--------Disclaimer-----
Joseph E. Richardson         | Phone: (301) 417-9884 |"He said WHAT???!!!"
Berard Software Eng., Inc.   | FAX:   (301) 417-0021 | - my boss expressing
101 Lake Forest Blvd,Ste 360 | Email: joseph@bse.com |   his agreement with
Gaithersburg, MD 20877-2611  |                       |   anything I say.
---------------------------------------------------------------------------

From ames!uunet.UU.NET!igor!ctbu!rmartin Fri Jul 17 09:46:37 1992
Date: Fri, 17 Jul 92 07:59:29 PDT
From: ames!uunet.UU.NET!igor!ctbu!rmartin (Bob Martin)
To: ntmtv!irvine@uunet.UU.NET
Subject: Re: Help: OOA and OOD Methodologies
Newsgroups: comp.object
Content-Length: 1901
Status: RO
X-Lines: 39

In comp.object you write:

>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
post my comments.  Thanks.

--------Address--------Phone Number-------FAX Number--------Disclaimer-----
Joseph E. Richardson         | Phone: (301) 417-9884 |"He said WHAT???!!!"
Berard Software Eng., Inc.   | FAX:   (301) 417-0021 | - my boss expressing
101 Lake Forest Blvd,Ste 360 | Email: joseph@bse.com |   his agreement with
Gaithersburg, MD 20877-2611  |                       |   anything I say.
---------------------------------------------------------------------------

From irvine Mon Jul 20 16:02:04 1992
Date: Mon, 20 Jul 92 16:02:02 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: SHlaer-Mellor OOA Model, Problem with definition of Object - comp.object #6364
Content-Length: 3837
X-Lines: 70
Status: RO

In article <1992Jul20.184212.24764@meaddata.com>, sdw@meaddata.com (Stephen Williams) writes:
|> johnson@m.cs.uiuc.edu (Ralph Johnson) writes:
|> : bradcox@infoage.com (Brad Cox) writes:
|> : 
|> : >What set me off was the original poster's quotation attributed to Shlaer-Mellor
|> : >|> Def: An object is an abstraction of a set of real-world 
|> : >|> things such that -
|> 
|> In OOA, whenever object is mentioned it is meant to represent any
|> single instance out of the pool of ALL POSSIBLE INSTANCES.  Just like
|> any other reasoning environment, statements must be true about all
|> possibilities unless the set is first restricted.  In the same way,
|> reasoning about relationships between hypothetical instances imply
|> partitioning (x isnota y, x and y are obviously different hypothetical
|> instances).
|> 
|> I know that this has been argued before, but I like to think,
|> especially during OOA, in terms of a prototype based language rather
|> than a class/instance based language.  (I happen to be
|> designing/implementing one right now also.)  Creating a new instance
|> is just a 'copy on write' like operation.
|> 
|> An Object (/class) is a coherent whole.  Everything inherently related
|> to a central idea (operations, state, interfaces, etc.) should be part
|> of a class/object.  The object can include other coherent wholes if
|> they are fundamental parts.  Almost anything could be considered an
|> object at some level of detail.  The trick is to find the most
|> expressive, concise, and flexible ways to model a world (real,
|> virtual, imagined, etc.).  Modeling real world entities/things is a
|> good place to start for beginners, but may not be the 'most correct'
|> or elegant way to design/develop.  Unfortunately, while some problem
|> spaces are sparse and produce predictable designs, others are very
|> dense and interrelated.
|> 
|> Although it may make many people uncomfortable, in some design
|> situations the best solution has arrived at based on skill, expertise,
|> and freethinking creativity.  Optimal software design wavers between
|> an art and a science.  Repeatedly redesigning something until one
|> feels it is the best you can make it is one of the best ways to build
|> skill.
|> 
|> I try to learn as many methods of breaking down problems and
|> organizing as I can keep in my head.  I try to apply many of them
|> quickly to problems to find a good pool of solutions to choose from.
|> 
|> It is disturbing when a more coherent design is challenged because the
|> suggestion of realworld modeling is carried too far.  (How can a
|> ticket print itself?...)  Personification/Anthropomorphism is the
|> best way I have found to learn to avoid this.  Eventually however,
|> such imagery is not really needed.
|> 
|> : >These issues get *real* messy. What the heck _is_ an object anyway? An
|> : >abstraction? Wouldn't we be much better off if they were concretions;
|> : >tangible things you can pull off a shelf and use, not an abstract ghost
|> : >that you have to code and retest from first principles?
|> 
|> : From an analysis point of view, it is less clear that an object is
|> : a concretion.  Analysis tends to be pretty abstract.  This might be a
|> : necessary evil, a blessing, or a curable disease.  It also might be
|> : too philosophical for us to think about without getting confused.
|> 
|> In a reuse of the old: "One person's data is another's program", 
|> "One person's abstraction is another's concretion".
|> 
|> sdw
|> --
|> Stephen D. Williams    SDW Systems (513) 496-5223 Pager (513) 439-5428 VMail
|> Object Oriented R&D    Internet: sdw@world.std.com CIS 76244.210@compuserve.com
|> Source Distribution    By Horse: 10028 Village Tree Ct., Miamisburg, OH 45342
|> GNU Support            ICBM: 39 34N 85 15W I love it when a plan comes together

From irvine Thu Jul 23 09:56:34 1992
Date: Thu, 23 Jul 92 09:56:33 PDT
From: irvine (Chuck Irvine)
To: irvine
Subject: Re: Help: OOA and OOD Methodologies - comp.object #6404
Content-Length: 2004
X-Lines: 40
Status: RO

In article <1992Jul22.181912.23392@mole-end>, mat@mole-end writes:
|> In article <2A66F3CE.13821@ics.uci.edu>, song@berault.ics.uci.edu (Xiping Song) writes:
|> 
|> >  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.
|> 
|> Relational data model, or Entity-Relationship model?  E/R is very useful
|> to the Relational model, but they are seperable concepts.
|> 
|> >  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.
|> 
|> Yes, the Sh/Me viewpoint emphasises the data model.  I think that a strong
|> data model is a good component of OOA.
|>  
|> >  Its weakness is on descrbing operation parts of an object.
|> 
|> I think it has other weakneses as well.  In particular, it seems better
|> suited to identifying and describing the types that describe the Application
|> and Subject-specific parts of a program, and weaker in dealing with types
|> whose purpose is to express Programming technologies (types that support
|> or embody algorithms, that provide lists and iterators and the like, etc.)
|> In fairness, most OOA/D methods have the same weaknesses.
|> 
|> It also doesn't provide a good model above the object level; IMO the
|> `architecture' Shlaer and Mellor provide echoes the procrustian bed
|> approach of SA/SD.  Something better is needed, something that expresses
|> features of the problem.
|> -- 
|>  (This man's opinions are his own.)
|>  From mole-end				Mark Terribile
|> 
|>  uunet!mole-end!mat, Somewhere in Matawan, NJ


Keywords: