HDTenEightyP/NetNews huggingface dataset:
From: haim@dancer.uucp (24103-kilov)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: Bellcore, Livingston, NJ
Date: Wed, 2 Sep 92 20:23:58 GMT

I agree with the class family idea of Ralph Johnson. In fact, the intersectLine
operation cannot be "owned" by a Circle and neither can it be owned by a Line.
It can be jointly owned (i.e., describe the joint behavior of) by Line and
Circle. Better still, this operation may be a subclass of the more generic
operation intersectFigure within the framework of Figures. Of course, the
question "which operations can this object participate in?" is legitimate.

-Haim Kilov
haim@bcr.cc.bellcore.com      or
haim@dancer.cc.bellcore.com
From: gt4084c@prism.gatech.EDU (SRINIVASAN,K)
Newsgroups: comp.object
Subject: Re: DFDs come naturally
Date: 3 Sep 92 15:10:41 GMT
Organization: Georgia Institute of Technology

In article <1992Sep1.143121.29965@matrix.com> srm@matrix.com (Steve Morris) writes:
>
>I have some background in OO techniques. However, every time I start
>to analyze a system via diagrams, I naturally (i.e. not-consciously)


At least to me, it has always depended on what I am trying to model.
When I try to model devices (any physical system), OOA seems to be 
natural.  However, when I try to model organizations (I have more
experience doing this), I tend to do a functional decomposition
of the organization (hierarchically).  In fact, I use the definition
of material and information flows between functions as the first approach
towards identifying objects.  Once I refine these object definitions,
I go back to redefine my functions to operate on these objects (the
so called TO BE function model of the organization).

-- 
SRINIVASAN,K
School of Textile Engineering   Georgia Tech.
uucp: ...!{allegra,amd,hplabs,seismo,ut-ngp}!gatech!prism!gt4084c
ARPA: gt4084c@prism.gatech.edu
Newsgroups: comp.object
From: Bob Hathaway <objsys@netcom.com>
Subject: Re: O.M() versus M(O) notation
Date: Wed, 26 Aug 92 00:56:05 GMT
Organization: Object Systems

  [This post is not to be taken seriously...]

In article <PCG.92Aug23210938@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>...
>		Version 0.5BETA:
>
>objsys> No I don't and never have.  As pointed out above, the is-a
>objsys> relation does not have a hierarchical restriction and indeed
>objsys> further justifies the separation of type and class.  I defended
>objsys> classification, not strict hierarchies.
>
>Comp.object as an ALPHA/BETA test site for opinions. Wonderful for some.

And Wesley can replay Captain Picard ordering him to attack a Klingon outpost
on the other side of the neutral zone by taking excerpts out of context too.
But I'll assume you and I disagree with hierarchical restrictions as *I* have
shown is reasonable and possible with both packages/modules and other more
directly object-oriented constructs.

bob

P.S.  Your comment about hierarchies came after the above repost and it should
  have taken less time to solve my puzzle than to perform your extractionsF-)
Newsgroups: comp.object
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Advanced Degrees in OOP
Organization: Computer Science, University of Melbourne, Australia
Distribution: usa
Date: Wed, 2 Sep 1992 13:19:49 GMT

moss@cs.umass.edu (Eliot Moss) writes:

>>>>>> On 1 Sep 92 05:39:23 GMT, paul@svl.cdc.com (Paul Kohlmiller) said:
>
>Paul> I would like to get an advanced degree in CS with an emphasis in
>Paul> OOP.
>
>As a CS educator in a dept that grants MS and PhD degrees, I think this is too
>narrow a focus for a degree. I can see focusing on "theory", or "AI", or
>"architecture", or ..., but what you seem to be aiming at I would call
>"software engineering", and I would hope you'd be educated to a lot more than
>(a) OO approaches and (b) programming. After all this is supposed to be
>computer *science*, not something like Evelyn Wood speed reading. That is, we
>are trying to teach something more borad and longlasting than the latest fad.
>(Which doesn't mean that we should not respond to advances in the state of the
>art!).

I don't think the idea is too narrow. After all, he only asked for "an
emphasis in OOP", not for a OOP course. There is certainly more than
enough possible material for a 200 hour course.

One of my CS departments two main areas of specialization is Logic
Programming.  My honours degree has included four roughly 50-hour
courses on that area (Theory of LP, Constraint LP, LP Techniques,
Parallel LP).  OOP is one of the four main programming paradigms (OOP,
LP, functional programming, and imperative programming) and I think
that there is as much justification for teaching and researching OOP as
a major part of an advanced degree as there is for any of the others.

While OOP (like any progress in CS) is being consistently over-hyped,
it is does constitute a genuine advance in the state of the art. OOP is
not a panacea; the gains using OOP are not astounding but they *are*
significant.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: p00058@mail.psi.net (Ronald C. Schultz)
Newsgroups: comp.object
Subject: Object-Oriented Methodologies - Class Specifications
Date: 31 Aug 92 12:56:09 GMT
Organization: Berard Software Engineering, Inc.
X-Mailer: PSILink (3.01)

I am continuing work on completing a methodology comparison of ten OO 
analysis and design methodologies, and I am now in the process of 
comparing methods for issues such as object coupling.

Object Coupling - In order to better support reuse, objects should be as 
decoupled as possible from any specific application, so that they may be 
reused in as many applications as possible.  In Rumbaugh's OMT text he 
provides a class specification for a circle on page 290.  I quote:

---- start of quote -------------------------
Class Description
Class Name: Circle
Version: 1.0
Description: Ellipse whose major and minor axes are equal
Super Classes: Ellipse
Features:
	Public Attributes:
		center: Point - location of its center
		radius: Real - its radius
	Public Methods: 
		draw (Window) - draws a circle in the window
		intersectLine (Line): Set of Points - finds the 
intersection of a line and a circle, returns set 0-2 points
		area(): Real - calculates area of circle
		perimeter(): Real - calculates circumference of circle
	Private Methods: none
---- end of quote --------------------------

This class specification screams of unnecessary object coupling.  Why, 
for instance, should a circle need to be aware of the existence of 
lines? or of the existence of windows?  To me, this class violates the 
very concept of a circle as defined in any geometry text.    

My question - can someone please explain to me why they feel this class 
is legitimate, (or illegitimate for that matter).  Why isn't the draw 
operation and intersectLine operation more appropriately assigned to the 
drawing application itself, rather than the circle?  Rumbaugh's OMT as 
well as some other OO methods seem to directly oppose long-term reuse of 
the method's analysis and design products.  Are others encountering the 
same issues?

Thanx for any assistance.

------------------------------------------------------------------------------
Ron Schultz 
Berard Software Engineering, Inc.
Columbus, Ohio Office                   Headquarters
5634 Claire Court                       101 Lakeforest Blvd.
Dublin, Ohio 43017-2440                 Gaithersburg, Md.  20877
(614) 798-0295 Phone                    (301) 417-9884 Phone
(614) 798-0296 FAX                      (301) 417-0021 FAX
ron@bse.com                             info@bse.com
------------------------------------------------------------------------------
From: luj@ecn.purdue.edu (John Lu)
Newsgroups: comp.object
Subject: Re: Method Dispatching
Date: 23 Aug 92 16:43:49 GMT
Reply-To: luj@ecn.purdue.edu
Organization: Purdue University Engineering Computing Network

In article <graham.714545782@dumas>, graham@maths.su.oz.au (Graham Matthews) writes:

|> 
|> 	class ratelt
|> 
|> 		representation: Tuple< integer, integer >;
|> 
|> 		* := 
|> 			function( a, b )
|> 				return < a[1] * b[1], a[2] * b[2] >;
|> 			end function;
|> 
|> 		[] :=
|> 			function( a, i )
|> 				return a[i];

Wrong.  The return statement should look something like this:
				return tuple[i];
i.e. you need to use the representation of a(of class ratelt).
This should solve your problem.

|> 			end function;
|> 
|> 	end class;
|> 

-- 
-- John Lu 
   luj@ecn.purdue.edu
Newsgroups: comp.object
From: sm86+@andrew.cmu.edu (Stefan Monnier)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: Future Issues of Object Orientation
Date: 31 Aug 92 14:29:09 GMT
Article-I.D.: andrew.8ecdopy00awJ4HOlo0
	<17tiuqINNn7i@network.ucsd.edu>
Distribution: usa
Organization: Junior, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.lang.eiffel: 31-Aug-92 Re: Future Issues of
Object.. Mike Markley@network.ucs (964)
> From where I sit it appears that the biggest issues will be in
> the areas of speed and size of executables. I have heard that
> some experimental OOP languages are approaching the speed of
> compiled C (if anyone has info on these please let me know how
> to obtain more info.) but I have not seen a commercial package
> that even comes close to being very efficient at run time. The
> other problem, that of size, may be addressable when the speed
> increases.

> Mike Markley
> ENFIN Software Corp.

> -- 
> Mike Markley
> markley@network.ucsd.edu
> The opinions here are mine and do not always agree with my 
> employers.  Reader discretion is advised.


Self (which is since recently available at self.stanford.edu in version 2.0)
claims to approach the C speed although it is FULLY dynamic
(even dynamic inheritance) by special 'run-time' compilation (which
writes different versions for special cases) !

About speed, some 'lightly' OO languages (Pascal object and the likes)
are not that slow !

In fact, I believe that speed increase will mainly become possible with
special hardware: since current processors are specifically designed
to run C like programs, it seems normal that different language 
paradigms can't really rivalise ! (see functional programming on a
data-flow machine)

On another hand, typical strongly typed OOL are generally not worse
than 2 times slower! that seems acceptable if you consider the design
speed increase !

Of course, improvements are still necessary. But maybe not in speed or
size: rather in 'maturity', power and other points (like integrating
the prototyping language and the final implementation language to 
further increase design time)

	Stefan Monnier


-----------------------------------------------------
-- On the average, people seem to be acting normal --
-----------------------------------------------------
From: thinman@netcom.com (Technically Sweet)
Subject: Re: Beginner's Question - CLOS
Date: Thu, 27 Aug 92 02:23:56 GMT
Organization: International Foundation for Internal Freedom



Here's how SELF handles this problem:  all classes are just
objects.  An object delegates messages it doesn't know about
to parents following a (too) complicated priority system.
SELF has this snapshot problem in spades.

The technique is simple: there are really two kinds of
object.  One is a prototype, which only serves as a
blueprint.  The other is a real live data object.
Data objects are made by 'cloning' prototypes.
Each prototype has a reference count of the number of
data objects which use it as a blueprint.  When an
object is modified, it's prototype is itself modified
if it has a refcount of 1. If more than one, a new copy 
is made of the prototype and that is then modified.

It does solve the problem, and is probably amenable to
modular compilation.
-- 

Lance Norskog

Data is not information is not knowledge is not wisdom.
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 1 Sep 92 22:05:59 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

After examining an example of Rumbaugh's,
"Ronald C. Schultz" <p00058@mail.psi.net> writes:

>This class specification screams of unnecessary object coupling.  Why, 
>for instance, should a circle need to be aware of the existence of 
>lines? or of the existence of windows?  To me, this class violates the 
>very concept of a circle as defined in any geometry text.    

>My question - can someone please explain to me why they feel this class 
>is legitimate, (or illegitimate for that matter).  Why isn't the draw 
>operation and intersectLine operation more appropriately assigned to the 
>drawing application itself, rather than the circle?  

I would be happy to.  The class looks fine to me.  I can see where you
are coming from, since I have argued with Ed Berard on this point a
lot.  Basically, I think your assumption that a Circle shouldn't know
anything about a Line is mistaken.  You wouldn't want to make Circle
independent of Point, would you?  If you want to be able to intersect
geometric figures, and I claim that is *essential* to the meaning of
geometric figures, then you have to be able to compare one with another.
This means that you have to have something like intersectLine.

I claim that you don't want to make a Circle class that is an independent
standalone entity.  The problem with small classes is that it takes too
much work to reuse them.  There is much bigger payoff when classes come
in families of similar classes, because then you can learn one class and
then just reuse your knowledge for all the other classes.  A Circle should
be part of a GeometricObject family of classes.  There will be a standard
set of operations that all the classes must implement, such as intersecting
with a point or another GeometricObject.  These classes will be designed
as a family and will probably be used as a family.  You are unlikely to use
a Circle in an application and not use a Line.  

Draw is definitely more debatable.  My guess is that if you ask a Circle
to draw on a window, it just performs the DrawCircle operation on the
window, which isn't all that bad.  But in general, different applications
will want to draw on different things, and will want to interpret drawing
differently.  Is color needed? Line-width?  Neither of these are attributes
of Circles, so it seems unreasonable to make Circles be responsible for
drawing.

In Smalltalk, there is a separation between geometric objects and
graphical objects.  A circle is not displayable.  Instead, you have
to put a wrapper on it that includes color and line width information,
as well as the display operations.

Ralph Johnson -- University of Illinois at Urbana-Champaign
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 3 Sep 92 14:26:19 GMT

p00058@mail.psi.net (Ronald C. Schultz) writes:

|Object Coupling - In order to better support reuse, objects should be as 
|decoupled as possible from any specific application, so that they may be 
|reused in as many applications as possible.  In Rumbaugh's OMT text he 
|provides a class specification for a circle on page 290.  I quote:

[ circle spec deleted ]

|This class specification screams of unnecessary object coupling.  Why, 
|for instance, should a circle need to be aware of the existence of 
|lines? or of the existence of windows?  To me, this class violates the 
|very concept of a circle as defined in any geometry text.    

|My question - can someone please explain to me why they feel this class 
|is legitimate, (or illegitimate for that matter).  Why isn't the draw 
|operation and intersectLine operation more appropriately assigned to the 
|drawing application itself, rather than the circle?  Rumbaugh's OMT as 
|well as some other OO methods seem to directly oppose long-term reuse of 
|the method's analysis and design products.  Are others encountering the 
|same issues?

I agree with you, the example is unecessarily coupled.  Circles, in
general, should not know about windows, and probably not about lines.

In order to create a Circle that knows how to draw itself in a window,
you could multiply inherit from both Circle and WindowObject.
WindowObject has a 'draw' method, which is implemented, in the derived
class, to draw the circle.

As for methodologies, I use a variation of the Booch method.  I group
my classes into logically cohesive units which Booch calls
"Categories".  Then I measure the number of class relationships within
the category, and call that "Cohesion".  The number of class
relationships which extend outside the category I call "Coupling".
Dividing both by the number of classes in the category gives me
normalized values which can be used to compare one category to
another.  Finally, the ration of these two numbers (Cohesion/Coupling)
is a metric  which I call "Health"  The bigger this number, the more
cohesive and less coupled the category is.

Thus, I don't measure the coupling and cohesion of classes directly.
I measure the coupling and cohesion of categories.  This makes more
sense to me since most applicatoins are assemblages of many, highly
collaborative groups of classes.


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Xref: sparky comp.object:3384 comp.lang.smalltalk:1755 comp.lang.eiffel:1105
From: nagle@netcom.com (John Nagle)
Newsgroups: comp.object,comp.lang.smalltalk,comp.lang.eiffel
Subject: Re: Future Issues of Object Orientation
Date: 2 Sep 92 18:38:35 GMT
Distribution: usa
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

sm86+@andrew.cmu.edu (Stefan Monnier) writes:
>Self (which is since recently available at self.stanford.edu in version 2.0)
>claims to approach the C speed although it is FULLY dynamic
>(even dynamic inheritance) by special 'run-time' compilation (which
>writes different versions for special cases) !
      Similar claims were made for MACLISP years ago.

>In fact, I believe that speed increase will mainly become possible with
>special hardware: since current processors are specifically designed
>to run C like programs, it seems normal that different language 
>paradigms can't really rivalise ! (see functional programming on a
>data-flow machine)
      Unclear.  That was the premise behind Symbolics and their LISP
machines.  It turned out, though, that simple RISC machines with a decent
compiler run Common LISP with substantially better price/performance than
Symbolics' refrigerator-sized machines.  (Is Symbolics still in business,
by the way?)  Lisp Machines Incorporated went bankrupt years ago.
But Lucid is still selling LISP compilers for Sun machines.  Vanilla hardware 
seems to win out.

					John Nagle
From: mm@inf.rl.ac.uk (Mike Mead)
Newsgroups: comp.object
Subject: RFI: Object Management Group
Date: 27 Aug 92 15:57:03 GMT
Organization: Rutherford Appleton Laboratory, Informatics Department, U.K.


Apologies if this is a FAQ...

Need info on the Object Management Group (OMG).  Tell me all,
tell me ANYTHING!  OMG seems very elusive.

Please email and I'll summarise (I don't normally read here).

Many thanks in anticipation.
M
From: rmartin@thor.Rational.COM (Bob Martin)
Newsgroups: comp.object
Subject: Re: DFDs come naturally
Date: 3 Sep 92 14:55:29 GMT

srm@matrix.com (Steve Morris) writes:


|I have some background in OO techniques. However, every time I start
|to analyze a system via diagrams, I naturally (i.e. not-consciously)
|start to draw a data-flow diagram.

|I don't necessarily say to myself... "Today, I'm going to use
|structured analysis". It just comes out that way.

|Has anyone else experienced this?

|To those of you who use OOA; does your OOA method come naturally
|or do you consciously apply it?


OOA was difficult at first, just as DFDs were.  But it didn't take
long before analysing a problem in terms of its objects and behaviors
became quite natural.  

What I have found with OOA/OOD is that it allows a much more complete
and meaningful analysis and subsequent design than SA/SD ever did.  I
can explore each behavior of the system, in excrutiating detail, long
before I begin to design my implementation.

Also, I find the techniques of OOA far less ambiguous than DFDs.  The
processes in a DFD often had an evanescence, a phantom like quality,
which never got translated into any form of reality.  This was not
true of all processes, but was often an attribute of intermediate
processes, one or two layers down in the hierarchy.  I have not
experienced this ambiguity with OOA.  Objects are seldom, if ever,
phantoms.  They always have state and behavior.  

Suggestion:  Don't give up.  If you are having trouble facing OOA and
are sliding back into SA, then read more about OOA and examine the
work of other people.  Learn how to do it, it will pay off!


--
Robert Martin                        Training courses offered in:
R. C. M. Consulting                       Object Oriented Analysis
2080 Cranbrook Rd.                        Object Oriented Design
Green Oaks, Il 60048 (708) 918-1004       C++
Newsgroups: comp.object
From: ede978e@monu6.cc.monash.edu.au (Robert D. Nicholson)
Subject: ECOOP article
Summary: ECOOP article
Organization: Monash University, Caulfield Campus
Date: Sat, 29 Aug 1992 06:05:06 GMT


Could somebody please send me the article on OOP and GUI's that appeared
in ECOOP-87 (Electronic form prefered)

Anybody know any other interesting articles that have appeared on this topic.
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.object
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Date: 26 Aug 92 08:03:51 GMT
	<KERS.92Aug21150658@cdollin.hpl.hp.com> <t5anrkq.objsys@netcom.com>
Organization: Department of Computer Science, University of Manchester
In-reply-to: objsys@netcom.com's message of 25 Aug 92 22:06:58 GMT

In article <t5anrkq.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
   Coplien uses the same terminology, that using the dynamic types of
   all arguments, with M ... or O.M ...  notation, is called
   multi-methods.  Please don't get this wrong again, its getting
   ridiculous.  You can say: "We in CLOS don't like others using the
   O.M ... notation to use the term "multi-methods" for their
   multiple-polymorphism even though this is becoming a standard
   practice." But I think a single term is preferred to two.

So lets take the CLOS one.  After all, as far as I'm aware it predates
both Coplien's and you useage of the term.

bevan