HDTenEightyP/NetNews huggingface dataset:
From: James_-_Odell@cup.portal.com
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: Tue,  8 Sep 92 20:13:22 PDT
Organization: The Portal System (TM)
  <graham.715854518@galois> <1992Sep7.233327.29906@tfs.com>

 In article <graham.715854518@galois> graham@maths.su.oz.au 
(Graham Matthews) wr:
>a) I find it very unnatural to think of the relationships between
>objects as objects. This is why we have two names for the two
>different ideas.

Perhaps this is because relationship objects are a *specialization* of 
vanilla objects.  I see relationship objects as complex objects, i.e. they 
are objects composed of one or more other objects.  For example, a 
relationship could be defined between a Man object and a Woman 
object.  In other words, I ve got tuples in the form <Man, Woman>.  If 
I wish to add attributes to this tuple, then I need to treat the tuple as 
an object (otherwise I would have nowhere to attach the attribute).  
This instance of, say, marriage can then be treated as an object in its 
own right.  What makes it different is that the marriage is a complex 
object; i.e. each marriage tuple consists of a Man object and a Woman 
object.
So, yes, we have two different names for two different notions.  It s 
just that relationship types are subtypes of object types--
In other words,  a relationship is defined like any other class is 
defined...  (Kilov;9/8/92 08:58 32/1370)  Or, in other other words 
 relationships are themselves objects  (Eric Smith).


jim


------------------------------------------------------------------------
James Odell                                Ann Arbor, MI  USA
(313) 994-0833                             71051.1733@compuserve.com
------------------------------------------------------------------------
Newsgroups: comp.object
From: perezc@woods.ulowell.edu
Subject: RFI: ISA/ANSA ?
Organization: University of Lowell
Date: Sat, 5 Sep 1992 13:47:12 GMT

Hello,

	I was just wondering if anyone knew what ISA and ANSA stands for
in the context of OMG work.  

Carlos
From: santas@inf.ethz.ch (Philip Santas)
Newsgroups: comp.object
Subject: Re: Object-Oriented Methodologies - Class Specifications
Date: 8 Sep 92 18:31:52 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH



In article <graham.715918116@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>
>No, all you seem to have considered here is the "is-a" relation.
>Are there no other relations between objects? What about dealing with
>the case where A is-a B in more than one way (eg: a field is a group
>in at least two ways). This latter example suggests for example that
>you need a more general way of specifying inheritance than just A
>is-a B, something like A is a B under these conditions, is a B under
>some other conditions ... This is all to do with relations between
>types.

In this example, normal inheritance _can_ do the work.
Field(+,*) inherits from two classes Group (Group(+) and Group(*))
the operations + and * (multiple inheritance).

For a start, there is a position-paper in Ecoop92 Workshop on Multiple 
Inheritance which refers to such cases. 

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
From: eberard@bse.com (Edward V. Berard)
Newsgroups: comp.object
Subject: Re: where was this paper published?
Date: Sun, 13 Sep 92 09:27:19 EDT
Organization: Berard Software Engineering, Inc.
Reply-To: eberard@bse.com (Edward V. Berard)
Distribution: world
Keywords: layered virtual machine
X-Mailer: uAccess - Macintosh Release: 1.6v1


In article <1992Sep10.183340.12236@matrix.com> (comp.object), srm@matrix.com (Steve Morris) writes:
> 
> 
> I have (most of) a copy of a paper titled...
> 
>         Layered Virtual Machine/Object-Oriented Design
> 
> by Ken Shumate (Hughes), which appeared in an ACM publication
> in 1988. My local university library can't find it.
> 
> My copy is missing the 6th page. Does anyone know in
> what journal or conf. proceeding this paper was published?
> 
Steve,

Try the following references:

[Meyer et al., 1989]. C. Meyer, M. Wallis, and M. Meier, "Experiences
in Applying the Layered Virtual Machine/Object-Oriented Development
Methodology to an Ada Design Effort," Proceedings of TRI-Ada 89 -- Ada
Technology In Context: Application, Development, and Deployment,
October 23-26, 1989, Association for Computing Machinery, New York, New
York, pp. 416 - 425.

[Nielsen and Shumate, 1987]. K.W. Nielsen and K. Shumate, "Designing
Large Real-Time Systems With Ada," Communications of the ACM, Vol. 30,
No. 8, August 1987, pp. 695 - 715.

[Shumate, 1988]. K. Shumate, "Layered Virtual Machine/Object-Oriented
Design," Proceedings of the Fifth Washington Ada Symposium, June 27 -
30, 1988, Association for Computing Machinery, New York, New York,
1988, pp. 177 - 190.

There are other related references, e.g., K.W. Nielsen has recently published
a book.

By the way, Layered Virtual Machine/Object-Oriented Development Methodology
is what is referred to as an "evolutionary" approach to object-oriented software
engineering, i.e., it is a blend of more traditional approaches with object-oriented
design.

Hope this helps.

				-- Ed

----------------------------------------------------------------------------
Edward V. Berard                                | Phone: (301) 417-9884
Berard Software Engineering, Inc.               | FAX:   (301) 417-0021
101 Lake Forest Blvd., Suite 360                | E-Mail: eberard@bse.com
Gaithersburg, Maryland 20877                    | 
----------------------------------------------------------------------------
Newsgroups: comp.object
From: johnson@m.cs.uiuc.edu (Ralph Johnson)
Subject: Re: Why is GC needed?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 15 Sep 1992 22:45:35 GMT

jrobbins@oahu.cs.ucla.edu (Jason Robbins) writes:

>  I must disagree on the point about C++ and other hybrid languages
>being OO. Those languages are meant for dealing with algorithms, they
>support objects as ADT's or "smart data structures".  When you think
>of a C++ program you think of a big call graph rooted in main() and
>here and there are transitory objects are created as local variables
>inside individual functions. The idea that objects are better ADT's is
>productive but I think that the real OO paradigm has more to offer.

>  I think of real OO programs as big graphs of objects (instances, not
>classes, classes are just the way you organizes code, the object-graph
>is where the real information is located, and it is what should drive
>your choice of class decomposition) with each object having little
>transitory algorithms hanging off of it. The running of the program is
>not so much determined by the progress of the program counter through
>control structures as it is by the propagation of state-changing
>messages through the object-graph.

I agree completely with Jason's characterization of the right way to 
structure OO programs.  And he might well know more about the way 
people use C++ than I do.  However, I don't believe that "real" OO
programming is impossible in C++.  InterViews is one good example.
It is true that memory management is a pain (as Jason explained in
some sentences I deleted), which is why I generally use Smalltalk.
Nevertheless, the people around here write C++ programs as big graphs
of objects, just like Jason advocates.

-Ralph


Newsgroups: comp.object
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: School of Mathematics and Statistics, University of Sydney
Date: Thu, 10 Sep 1992 01:03:21 GMT

graham@maths.su.oz.au (Graham Matthews) writes:
>>You have to do more than this I think Phillip as you also have to
>>get a new element for your carrier set. A field is a multiplicative
>>group with addition and a zero element (I think I have this the
>>right way round). So you have to pick up a zero somewhere in your
>>carrier set.

santas@inf.ethz.ch (Philip Santas) writes:
>My above solution was just a hint. Of course I do have more parameters:
>Field((+,0),(*,1)) :< Group(+,0) /\ Field((+,0),(*,1)) :< Group(*,1)
>or more general:
>Field((op1,Zero),(op2,One)) :< Group(op1,Zero) /\ 
>Field((op1,Zero),(op2,One)) :< Group(op2,One)
>or
>Field((op1,Zero),(op2,One)) :< (Group(op1,Zero) + Group(op2,One))
>As you see we do not have just one class Ring or Group, but many of them.

I am not sure that this solves my problem. Lets turn this round.
A car is a vehicle in the sense that to treat a car a vehicle I do
not have to do anything. To treat a field as a group however I must
be able to to throw away an element of my carrier set. Above you 
describe which operations parameterise a group and a field, but you
make no mention of the carrier set. How does the inheritance system
know for example which element of the carrier set it must remove to
view a field as a group?

>The above are functors which construct these classes.
>You can say describe them as parameterised classes, but they are
>actually functions which return classes.

And now we are getting closer to the point. These functors are maps
between "types". They are relationships between types describing
how one type may be views as another.

>Really, here _normal_ multiple subclassing does a pretty good job.

Perhaps we have a difference of taste here.

>The problem arises when we have instances of these classes,
>ie. Reals, Rationals, Integers. Normal subclassing as it is understood
>in traditional OOP, is _very_ poor indeed.

This reminds me of something else. Say I want to say that all rings
are closed and finite (just assume they are). Now do I have to make
some class heirarchy like closed_ring < finite_ring < ring, or perhaps
I should make finite_ring < closed_ring < ring? Whichever I chose
there is an implied order in the class heirarchy that is not in the
mathematics. 

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
Newsgroups: comp.object
From: eric@tfs.com (Eric Smith)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: TFS
Date: Sun, 6 Sep 1992 00:30:55 GMT

In article <graham.715679543@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>And this to me is the single biggest problem that OO will face in the
>future. In my opinion OO is good in small problem domains where there
>are only a small number of fairly static relations between objects.
>Get into a domain like mathematics where every object is related to
>every other object in many many ways, and OO begins to show its failures.
>Class lattices get clumsy, many properties are not known or knowable
>until run-time, etc etc.

If you insist on modelling all possible relationships at once, then yes,
it does get complicated.  But trying to model them without OO would be
far more complicated.
Newsgroups: comp.object,comp.databases,comp.benchmarks
From: bkerr@mariner.amc.edu.au (Bruce  Kerr)
Subject: Advice on DBMS      
Organization: Australian Maritime College
Date: Wed, 9 Sep 92 06:33:05 GMT

Hi,
I need some advice or suggestions from DB guru's regards
"THE KILLER" dbms for our college student admin system.

What we desire is true life experiences of one who has
travelled this path(or something like it!).   

We are presently between systems and would like to build 
the system in house??? though if someone has one readymade
we would take a look at it.

The college is small with only 1400 students per year and
have to provide for 
   1: Course and subject data.
   2: Student details and accounting(gov fees and lib etc)
   3: Grades
   4: Reports(this is the biggy, must have SQL)
   5: Archiving

The reports required are complex so the report generator must
be real good and REAL friendly.

Stored procedures on the form definitions would be real handy.

Our hardware at present is a baby VAX, a baby SPARC station,
a Netware 3.11 system, oh and a couple of Mac's. 
There are gateways between everything and some applications on 
each system accessed through terminals or emulators on PC's.

Under consideration are: 
  1: RDB, Ralley, Dectrieve etc on the VAX
  2: Ctree, Rtree, Dtree etc on Novell
  3: Foxbase on Novell
  4: Paradox wherever it will work?
  5: Any other suggestions.

If you have had any good or bad times with any of these products
I would like to hear about them.

Hoping for a reply or a Lotto win,
Bruce
From: reiner@ksr.com (David Reiner)
Newsgroups: comp.object
Subject: OODBMS oppt'y, Boston, KSR
Date: 14 Sep 92 17:56:57 EDT
Distribution: na
Organization: Kendall Square Research Corp.

Kendall Square Research is looking for a creative software designer to
adapt, enhance, and tune third-party object-oriented DBMSs (OODBMSs) and
associated object-oriented development environments for the KSR parallel
machine. 

Areas of focus include large objectbase support, parallel objectbase
processing, and integration of OO development environments/languages with
OODBMSs. 

Essential knowledge: Current OO development environments including OODBMS
internals, with both hands-on experience and theoretical grounding.  Important
skills: Unix, C, and C++.  A significant plus: experience with relational DBMS
internals, parallel machines, performance tuning, software porting, or large
commercial database/objectbase applications.  MSCS in Computer Science 
preferred, or equivalent experience.

The ideal candidate has 5+ years of experience with a track record of design,
implementation, or porting OO products.  S/he is a creative software designer,
a strong, hands-on implementor, a team player able to work independently as
well, and a good communicator.  S/he welcomes challenge and complexity in a
very focused professional environment.

Email resumes to: reiner@ksr.com 

or send via US Mail to:
  Kendall Square Research Corporation
  Attn: Personnel Dept OODSR
  170 Tracer Lane
  Waltham, MA 02154

Kendall Square Research Corporation is an Equal Opportunity Employer.
Newsgroups: comp.object
From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 14 Sep 1992 01:27:30 GMT


In article <graham.716429522@galois> graham@maths.su.oz.au (Graham Matthews) writes:
>(Philip Santas) writes:
>>
>>class Field((op1,ZERO),(op2,ONE)),
                  ^^^^^^
>
>No I do not necessarily have the zero in my parameterisation. You are
>assuming that because I want to "deconstruct" my field by removing a
>zero (to make it into a group) that I necessarily "constructed" my field
>by giving the zero. That is not necessarily the case!

What is the case?

You may try:
Field((op1,ZERO),(op2,ONE)) :< Ring((op1,ZERO),(op2,ONE))

>               FiniteRing < FiniteSet < Set
>               NonFiniteRing < NonFiniteSet < Set

This looks correct.
But why don't you decmpose it into its parts?

    FiniteSet :< Set
    Ring :< Set
    FiniteRing :< FiniteSet + Ring

>But no you chose to make your previous heirarchy? Why? There is no
>reason to make the heirarchy in the way you suggested, why not do
>it the way I suggested? 

The above scheme poses no problems. I just decompose it into more
basic parts.

>Also try adding in enumerability while you are
>at it - doing so ably demonstrates the lack of order in the mathematical
>properties, but the imposed order in the inheritance heirarchy.

When you do the decomposition, you do not have limits in the order.
Do you want to have an enumerable Set?

    EnumSet :< Set

Notice that the order in which I add these links is not important.
Important is to have them.

Philip Santas

 "Creativity in programming is to find deep simplicities in a complex process."  
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
      



Newsgroups: comp.object
From: steve@projtech.com (Steve Mellor)
Subject: Re: DFDs come naturally
Organization: Project Technology, Inc., Berkeley, CA
Date: Mon, 7 Sep 1992 15:33:53 GMT

James Odell writes:  (reformatted to save lines)
|In addition, DFDs--as they are classically defined--are not  ade-
|quate  for  methods  specification.   That s why CASE tools can t
|generate executable code from them.  In order generate executable
|IF...THEN...ELSE-code  the  notation  needs to be  strengthened .
|Conventionally when a Process_A flows to a Process_B in a DFD  it
|means that Process_A *precedes* Process_B.  If the meaning of the
|dataflow line could be changed from one of precedence to causali-
|ty,  an  effective  execution-directed notation could be defined.
|Here, the dataflow line would actually become a trigger, so  that
|the  completion of Process_A *triggers* Process_B.  If Process_A,
|Process_B were defined to be OO operations with signatures and  a
|class  assignment (or class assignment*s* for you CLOS fans), the
|diagram would  be  a  true  OO  method  specification--in  an  OO
|analysis  sense.   If  this technique were adopted, the notion of
|data store would probably no longer be useful.
|
Right you are about the need to extend dfds.  We have found  that
we need the concepts of:
 1. data flow: comprising data and triggering
 2. control flow: triggering only
 3. conditionality: on data or control flows
 4. data stores: (data, no triggering)

By organizing the data flow diagrams for each state  in  a  state
machine  (rather than functionally decomposed for the system as a
whole, as in Rumbaugh et al.), we can in fact build a set of ful-
ly executable object-oriented method definitions.

There is a description of the extended dfds in Chapter 6 of Sally
Shlaer's  and  my  book,  Object Lifecycles.  The description in-
cludes assignment of processes to objects.  Then Chapter 9  shows
how  to turn the dfds into an object-oriented design by *transla-
tion*  of   the   OOA,   rather   than   *elaboration*   as   per
Booch/Rumbaugh.
-------------------------------------
Steve Mellor            steve@projtech.com
Project Technology      Training and Consulting using Shlaer-Mellor OOA/RD
Berkeley, CA            Tel: (510) 845 1484
--------------------------------------
Newsgroups: comp.object
From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 7 Sep 1992 00:38:13 GMT


In article <PFKEB.92Sep5213354@kaon.SLAC.Stanford.EDU> pfkeb@kaon.SLAC.Stanford.EDU (Paul Kunz) writes:
>In article <715276480.1.p00058@mail.psi.net> p00058@mail.psi.net (Ronald C. Schultz) writes:
>
>|   Class Name: Circle
>|   Description: Ellipse whose major and minor axes are equal
>|   Super Classes: Ellipse

>Nonsense.   A Circle is not a *subclass* of Ellipse, it is a *subset*
>of all possible Ellipses.   There's no need to define such a class.

Do you mean that a Circle c is not a subclass of Ellipse?
If so then you are half correct. c is an instance of the class Circle 
or the class Ellipse. But then I do not see how it is a subset of any of them.

If you say that the Set of Circles is not a subclass of Ellipse,
I'm wondering on what base you justify such aggression from your side.

>Confusion between subset and subclass is happening here.

Please, elaborate. You seem to consider many disciplines
as confused, and we are all interested in knowing what the on-going research
of more than a century has brought into confusion.

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391
     



Newsgroups: comp.object
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Object-Oriented Methodologies - Class Specifications
Organization: School of Mathematics and Statistics, University of Sydney
Date: Mon, 7 Sep 1992 08:28:38 GMT

graham@maths.su.oz.au (Graham Matthews) writes:
>still ... the challenge is in modelling the relationships between 
>objects, not in modelling the objects themselves. In my opinion OO 
>does a good job of the latter and a poor job of the former.

eric@tfs.com (Eric Smith) writes:
>The trick is to see that relationships are themselves objects.  For 
>example, the ways a line and a circle can relate to each other are 
>the line-circle relationship, which is a subclass of the two-geometric
>-figure relationship. Intersections are a feature of geometric figures,
>and the intersections of a line and a circle are a feature of the 
>line-circle-relationship subclass of the two-geometric-figure 
>relationship.

Three points in reply:

a) I find it very unnatural to think of the relationships between
objects as objects. This is why we have two names for the two
different ideas.

b) you assume that the relationships between objects can be modelled
using your inheritance structure, or more generally that the 
mechanism for classifying the types of objects is to be the same
mechanism for handling relationships between types. I see no reason
to assume that this assumption is true.

c) if you have a lot of relationships your scheme gets pretty clumsy.
Moreover many of these relationships are not naturally specified
in an inheritance framework.

graham
--
Graham Matthews                 And it's true we are immune
Pure Math, Uni.Sydney, Oz       When fact is fiction and T.V. is reality
graham@maths.su.oz.au
Newsgroups: comp.object
From: Goran Ericsson <ergo@incosys.kth.se>
Subject: Conferences on Object-orientation
Organization: KTH, Industrial Control Systems
X-Useragent: Nuntius v1.0
Date: Wed, 9 Sep 1992 13:37:02 GMT


Newsgroups: comp.object
From: Goran Ericsson <ergo@incosys.kth.se>
Subject: Conferences on Object-orientation
Organization: KTH, Industrial Control Systems
X-Useragent: Nuntius v1.0
Date: Wed, 9 Sep 1992 13:44:08 GMT


From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Mon, 14 Sep 1992 11:10:30 GMT
Subject: Re: O.M(...) vs M(...), and is the Real World O-O?
Organization: Hewlett-Packard Laboratories, Bristol, UK.