HDTenEightyP/NetNews huggingface dataset:
From: pryals@projtech.uucp (Phil Ryals)
Subject: Re: Object-oriented analysis (general query)
Organization: Project Technology, Inc., Berkeley, CA
Date: Fri, 10 Apr 1992 00:23:36 GMT

In article <1992Apr3.180413.2731@colorado.edu> scotth@sigi.cs.colorado.edu (Scott Henninger) writes:
>Could someone give me a concise explanation of the difference between
>object-oriented *analysis* and structured analysis methods?
>
>What are some good references for object-oriented analysis?

The major difference is that object-oriented analysis uses the information
in the problem as the foundation for analysis, instead of the processing that
structured analysis uses.

OOA:

1.  Determine the things in the problem and how they are related.
2.  Determine the lifecycles of the things in the problem.
3.  Determine the processing needed to drive the things through their 
    lifecycles.

SA:

1.  Determine the processing needed to implement the solution to the problem.
2.  Determine when the processing needs to be done.
3.  Determine the data needed to allow the processing.

OOA is much more stable under changing requirements than SA because the basic
things in the problem don't change as much as the required processing.  Thus
the OOA models are not as severely disrupted by changing requirements (that
usually mean changes in processing).

References:

Object-Oriented Systems Analysis: Modeling the World in Data, S. Shlaer &
   S. Mellor, 1988, Prentice-Hall

Object-Lifecycles: Modeling the World in States, S. Shlaer & S. Mellor, 1991,
   Prentice-Hall

Understanding Object-Oriented Analysis, S. Shlaer & S. Mellor, 1989, Hewlett-
   Packard DesignCenter Magazine
From: hasko@heeg.de (Hasko Heinecke)
Newsgroups: comp.object
Subject: Re: help required
Date: 15 Apr 92 15:35:44 GMT
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG

In article <1992Apr7.185808.48861@ccvax.ucd.ie> bharat@ccvax.ucd.ie writes:
>Does this mean that we can define
>each layer as a class (say, physical layer as a class and modem,MUX, as 
>instances of the class "physical layer", and so on?

IMHO, it's always a good approach to have real world objects represented as
classes. Abstract concepts may also appear as classes, but then they could
be just attributes of these real world objects, like "layer",
"protocolsSupported", and so on.

>(ii)HIERARCHY AND INTERELATION OF OBJECT CLASSES AND OBJECTS:In the context of
>network management how would i define the hierarchy and interrelationship 
>between network resources (i.e. modem, PBX, bridge, router, gateway, 
>workstation etc.)

With real world objects represented in you OOL, this should be no problem.
Imagine you have a class "Computer" with an attribute "peripherals". This
attribute contains a list of things like instances of the class "Modem" or
"InternetConnector". Then e.g. Computer would understand a message "canConnect"
which looks if both computers have an InternetConnector with the same subnet
address or if they both have modems. These peripherals can have speeds or
measures of security attached to them, and computers could know about their
CPU powers or whatever.

Again, don't be too theoretical about your objects. If you have computers - 
fine, they're just objects. If you have abstract concepts like protocols,
layers, etc, find out if they have a state and a behaviour, do they communicate
or do they just kind of exist? Then maybe you don't need them at all.

Do it in Smalltalk (or any other real OOL) and you have less problems.

Hasko


-- 
+--------------------------------------------------------------------------+
| hasko@heeg.de  --  Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| "Computers are different from telephones - computers do not ring." --AST |
+--------------------------------------------------------------------------+
From: knox@spruce.gsfc.nasa.gov (Robert Knox)
Newsgroups: comp.object
Subject: OOA TOOL for Windows3
Date: 7 Apr 92 23:54:25 GMT
Article-I.D.: spruce.1992Apr7.195425
Reply-To: knox@spruce.gsfc.nasa.gov (Robert Knox)
Organization: NASA/GSFC code 923

Windows 3.1 is now available retail, and I gleefully bought a 
copy last night.  Then today I used ftp to pick up a copy of 
the OO Documentation Tool developed by Roman Zielinski, in 
this case stored in oot-1-03.zip (either on garbo.uwasa.fi or 
the SIMTEL server at White Sands, NM).  Everything seemed to 
transfer and unpack without a hitch.  I followed the simple 
installation instructions . . . and ...

Imagine my disappointment when the application comes up in
its own window with scroll bars and a label across the top, 
but does nada, no menu, nothing.  Except, well the right mouse 
button brings up the outline of a rectangle which disapears 
when you release it.  This gets dull after a few tries.

Has anyone else tried using this OOA drawing tool under Windows 
3.1?  Perhaps as a Windows naif I did something wrong in the 
installation, or maybe I got bit by trying to run Window 3.1 on 
top of DOS 4.01.  Maybe I need a boatload more memory.  (Config: 
Packard Bell 286-Notebook, VGA screen, Microsoft "ball point" 
mouse, 384K extended memory.)  

Sorry if this seems off-topic, it's just that this program
seemed like the next cheapest thing to 3x5 cards for doing
OO-Analysis conveniently.  When most competing tools are built
into expensive CASE framworks, which can have serious impacts on
personal finances or the budget of a small research project, I'd 
really like to be able to try this program out.

- Bob Knox
- Biospheric Sciences Branch, Code 923.0
- NASA/Goddard Space Flight Center, Greenbelt, MD 20771 
- knox@spruce.gsfc.nasa.gov      | BITNET: knox@ricevm1
From: mfausett@bbn.com (Mark Fausett)
Newsgroups: comp.object
Subject: Re: Can C++ / X empower us to make great apps for the 90's?
Date: 9 Apr 92 19:40:13 GMT
NNTP-Posting-Host: kirin.bbn.com
Keywords: nn

eric@tfs.com (Eric Smith) writes:

>In article <1992Apr8.060832.9260@sfc.sony.com> berger@sfc.sony.com (Bob Berger) writes:
>>The dynamic-binding of the Objective C extensions to the NeXTstep C++
>>compiler seem to be a key to allowing for the easy sharing, reuse and
>>incremental development process. The fact that the NeXTstep compiler
>>(and gcc-2.x) allows for the mixing of Objective C and C++ (and of
>>course C) in one program now allows the PROGRAMMER (as opposed to the
>>language designer!) to choose the level of binding (static or dynamic)
>>as appropriate for the application.

>What do you mean?  C++ has always had dynamic binding.  It's the single
>most important feature of the language.

Excuse me, but I think that the closest thing that C++ has to dynamic binding is
virtual functions, and these are limited enough to be very annoying.

Mark Fausett,
mfausett@bbn.com
#import <std/disclaimer.h>
From: laub@Software.Mitel.COM (Boniface Lau)
Newsgroups: comp.object
Subject: Re: SUMMARY: complexity in O-O
Date: 12 Apr 92 17:06:02 GMT
Followup-To: comp.object
Organization: Mitel. Kanata (Ontario). Canada.
In-reply-to: kalakota@ccwf.cc.utexas.edu's message of 9 Apr 92 05:34:59 GMT

>>>>> On 9 Apr 92 05:34:59 GMT, kalakota@ccwf.cc.utexas.edu said:

[...]

kalakota> What are the several categories of complexity? [Ejiogu 85]

kalakota> There are several categories of software complexity. Five of
kalakota> them are:

kalakota> Structural Complexity: Has to do with the natural expression
kalakota> of the topological relationships of a system's components.
kalakota> Structural complexity is more than just the effects of the
kalakota> control paths. It is a global attribute.

kalakota> Computational complexity: Concerns the relative difficulty
kalakota> in accomplishing arithmetical/logical computations of an
kalakota> algorithm on data. This complexity is an attribute of the
kalakota> algorithm.

kalakota> Logical complexity: Has to do with the relative difficulty
kalakota> of logical decisions or flows and branches within a system.

kalakota> Conceptual complexity: Has to do with the psychological
kalakota> perception or the relative difficulty of undertaking or
kalakota> completing a system; it may also include the diversity of
kalakota> human and material resources.

kalakota> Textual complexity: has to do with the static analysis of
kalakota> program source texts. This condition influences reliability.

Depending on the perspective, there are also:

Intrinsic complexity - complexity of the problem itself that the
software is modeling.

Extrinsic complexity - complexity introduced to a software system due
to the implementation.

kalakota> Which does type of complexity does O-O affect most? 

For sure, O-O cannot reduce the intrinsic complexity.

kalakota>                                                     As Ralph
kalakota> Johnson pointed out, most of the complexity is inherent in
kalakota> the problem being solved, but O-O can provide a way of
kalakota> managing complexity. 

I would say the reason complexity is bothering us is because we
address complex problems with relative primitive tools. In other
words, a poor match between problems and tools.

[...]

kalakota> We find that OO does not reduce complexity, in fact our complexity
kalakota> increases dramatically.  

While OO cannot reduce the intrinsic complexity, it does reduce
certain extrinsic complexity such as housekeeping.  

--
Boniface Lau    (613) 592-2122 ext. 3042    Boniface_Lau@Mitel.COM
Mitel Corp.  				    
350 Legget Drive, Kanata
Ontario, Canada, K2K 1X3
From: sam@staypuffed (Sam Griffith)
Newsgroups: comp.object
Subject: Re: C++ binding vs. Obj-C binding
Keywords: OOP, C++, Obj-C
Date: 14 Apr 92 16:42:22 GMT
Reply-To: sam@pencom.com
Organization: Pencom Software

In article <0dwjqld.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
|> >
|> >I think what he is alluding to is that the dynamic binding in C++ is  
somewhat  
|> >limited.  For example, in C++, you can't dynamically load a class into the  
|> >class hierarchy at runtime, which is how IB loads in new interface objects.
|> 
|> Thats an extreme example.  C++ (as a paragon of statically-typed OO
|> languages) can't create and send messages at run-time and all polymorphism
|> must take place with overridden virtual functions, so bases must have
|> virtual declarations for all common member functions of all derived
|> classes.  This is clearly an efficiency trick, but a good one *when* such
|> a derived-base binding isn't considered a problem.  Obviously dynamically
|> loaded objects couldn't be accessed without dynamic typing (without IMHO
|> gross processes), even by definition.

I don't feel that that is an extreme example.  It seems to me to be easily  
adaptable to learning systems etc.  It seems to me that the ability to  
dynamically load classes, or objects is what you need for a flexible OODMS  
also.  It's very useful for alot of situations.

---------------
Sam Griffith Jr.
Pencom Software
sam@pencom.com
From: mr@delfin.com (Mark Rosenberg)
Newsgroups: comp.object
Subject: Re: Can C++ / X empower us to make great apps for the 90's?
Date: 15 Apr 92 22:17:14 GMT
Organization: Delfin Systems, Sunnyvale, CA.


|> In article <1992Apr8.060832.9260@sfc.sony.com>, berger@sfc.sony.com (Bob Berger) writes:
|> How does one do true Object Oriented GUI development under X and C++?
|> 
|> I want to treat my GUI objects (widgets, structured graphics, etc) as
|> first class objects. I want to create modified versions of existing
|> widgets through OO techniquies like inheretance using the OO language
|> mechanisms, not kludge toolkit mechanisms. ...

|> All the other so called C++ X toolkits that I have seen are just
|> kludge wrappers around C implementations. They do not allow the
|> widgets to be first class objects. ...
|> 
|> My goal here is not so much to praise NeXT. But to remind all of us
|> C++ / X folks that we are not living up to the promise of the OO
|> paradigm. The current C++ / X environments are not making it that much
|> easier to stand on the shoulders of people who have done the
|> foundation work. We still keep finding ourselves reinventing the
|> wheel, starting each project from first principles. ...

Although "native" C++ implementations of X and X toolkits would undeniably
allow the power of OO techniques to be less awkwardly applied to UI
development, the need to develop project-specific GUI object
class libraries from raw C libraries has some positive implications as well.

Most toolkits are designed to provide a wide selection of GUI objects
and interaction paradigms so that any conceivable (or so the designer's
hope) application will have what it needs. In order to provide a
consistent interaction paradigm as well as a clearly defined product look
and feel, most applications will use only a subset of the toolkit's facilities.

The thought invested in designing a application-specific C++ class library
of GUI objects is repaid not only by code reused but also by implicitly
enforcing interface consistency. Of course, the same class library could
be more easily built from a native C++ toolkit although I suspect that
many projects might not see fit to if they had one.
From: rebuffel@granit.unice.fr (Manuel Rebuffel)
Newsgroups: comp.object
Subject: Articles quest...
Date: 6 Apr 92 09:30:06 GMT
Organization: University of Nice - Sophia Antipolis


		Hello,

	I'm looking for two articles :

	 - "Inheritance of synchronization constraints in concurrent
object-oriented programming languages", Svend Frolund, University of Illinois -
USA, 1992.

	 - "EPEE : an Eiffel environment to program distributed memory parallel
computers", J.-M. Jezequel, IRISA - France, 1992.

	Thanks for all informations about them.

		Manuel Rebuffel.

E-mail : rebuffel@mimosa.unice.fr
Newsgroups: comp.object
From: eric@tfs.com (Eric Smith)
Subject: Re: Can C++ / X empower us to make great apps for the 90's?
Keywords: nn
Organization: TFS
Date: Thu, 9 Apr 1992 07:49:24 GMT

In article <1992Apr8.060832.9260@sfc.sony.com> berger@sfc.sony.com (Bob Berger) writes:
>The dynamic-binding of the Objective C extensions to the NeXTstep C++
>compiler seem to be a key to allowing for the easy sharing, reuse and
>incremental development process. The fact that the NeXTstep compiler
>(and gcc-2.x) allows for the mixing of Objective C and C++ (and of
>course C) in one program now allows the PROGRAMMER (as opposed to the
>language designer!) to choose the level of binding (static or dynamic)
>as appropriate for the application.

What do you mean?  C++ has always had dynamic binding.  It's the single
most important feature of the language.
From: lief@hpfcso.FC.HP.COM (Lief Sorensen)
Newsgroups: comp.object
Subject: Re: OOP Disavantages?
Date: 16 Apr 92 18:59:17 GMT
Organization: Hewlett-Packard, Fort Collins, CO, USA

>  Hi OOPland,
> 
> 	Just one quickie questions.
> 	What are the real disadvantages of OOP. There must be a down side. True
> 	the learning curve is one but I dont consider that serious enough.
> 
> 	_Devon_C
> --
> ======================================================================
> Devon T. Caines                             Berrien Springs MI 49103
> Andrews University                           (616) 471-3516   hh
> Computer Science & Information Systems Dept
> -----------------------------------------------:----------------------
> caines@andrews.edu  :C ing is be leaving the BASICs 
> ======================================================================
> 

A few months ago I took a 1-week course here at HP on C++.  I was hoping to
follow-up with an Object Oriented course (more in depth) but it was cancelled
twice due to lack of takers!

Personally, I do not use C++ yet for two reasons:
  (1) The compilers are still in development stage and thus not real
      efficient -- and in some cases some serious bugs still exist.
  (2) The code will never run as fast as standard C code simply because
      of the extensive use of dynamic memory allocation used with
      Object Oriented programming.

I would not consider the learning curve a disadvantage, because no matter what
language you use, there will be a learning curve to it.  I believe that once
the compilers have had a chance to improve and the dynamic memory allocation
schemes have been optimized, this will be the wave of the future.  Already I
am seeing major 3rd party software vendors using OOP for their packages.  One
good example here is Mentor.  They totally remade their Schematic Capture and
Board Station software as they went from version 7.X to 8.X to incorporate OOP
concepts.  Let me say, interfacing to their new package is a piece of cake
because of the OOP!  But then, who am I to say, since I am a hardware engineer!

By the way, you guys still use APL?  The first computer language I ever learned
was APL when taking some Physics classes from Dr. Rowland.

 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 + Lief Sorensen         lief@hpfclm.fc.hp.com +         --\\\\o___           +
 + Hewlett Packard Co.                         +     --\\\\o___               +
 + Fort Collins, Colorado                      + --\\\\o___      Rev. 14:6-12 +
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Xref: sparky comp.object:1745 eunet.misc:299
From: jldurand@lusignan.lusignan.inra.fr (Jean-Louis Durand)
Newsgroups: comp.object,dk.general,nordunet.followup,eunet.misc
Subject: Re: call-for-participation
Summary: 13 april earthquake in Europe
Date: 14 Apr 92 11:44:19 GMT
Distribution: eunet
Organization: Institut National de la Recherche Agronomique - JOUY

Hello,

I would like to have some reports on personnal experience of the 13 april
earthquake in Bonn. Did anybody notice it ?

Bye
Newsgroups: comp.object
From: jjfeiler@relief.relief.com (John Jay Feiler)
Subject: Re: Can C++ / X empower us to make great apps for the 90's?
Reply-To: jjfeiler@relief.relief.com
Organization: KiaB, relief consulting
Date: Sun, 12 Apr 1992 21:16:08 GMT

In article <1992Apr11.021508.29048@ux1.cso.uiuc.edu> mlanett@void.ncsa.uiuc.edu  
(Mark Lanett) writes:
> linton@marktwain.rad.sgi.com (Mark Linton) writes:
> 
> >I agree that interface builders are a good thing and the Next one
> >is quite nice.  I believe that dynamic loading is the important feature
> >missing from most C++ environments; I'm less convinced that
> >I need to be able to get "method not defined for this object" errors.
> 
> A friend bought a NeXT (he's an experiences MacApp/C++ developer) and has not
> been terribly impressed with NextStep. One of his biggest complaints is that
> he *isn't* getting "method not defined for this object". Next has their
> doesNotUnderstand message just swallow everything and not provide any error
> messages at all! The only way he's figured out to tell if a message is  
actually
> received and understood by the correct object is to step into every method
> dispatch. To top it off, which Obj-C allows typed objects, the Next IB cannot
> parse them; it requires everything to be 'id'. So even if he wants to type 
> things to reduce a really ridiculous number of runtime errors... he can't.
> Maybe 3.0 will be better.
> -- 
> Mark Lanett, Software Tools Group, NCSA           mlanett@uiuc.edu or   
NCSA.STG
> "People wander in and out of virtual rooms in virtual settings with virtual
> characters and virtual money and virtual armor and virtual weapons, which is
> virtually a good way to spend time, but not quite." -- Usenet Oracle

The easiest way to tell if a message is actually recieved and understood is to  
override the method -doesNotUnderstand: in a subclsss of Object, then have that  
object -poseAs: the Object class.  I use a debugging object during development  
that pops up an alert panel that tells me what message got sent to where when  
it doesn't get understood.  Quite useful really.  When it comes time to ship  
the final production code (without any messages going to the wrong place), I  
just remove the -poseAs: call.

It *IS* annoying that IB does not allow you to do any static typing, but IB is  
still better than any other similar tool I've ever worked with....

--
John Feiler					jjfeiler@relief.relief.com
3800 14th Ave. SE D-165
Lacey, WA  98503-2273		   
Independent NeXT Developer
From: hasko@heeg.de (Hasko Heinecke)
Newsgroups: comp.object
Subject: Re: Scanner, Parser Generator Critique
Date: 15 Apr 92 14:54:46 GMT
Organization: Georg Heeg Objektorientierte Systeme, Dortmund, FRG

In article <hppjbka.objsys@netcom.com> objsys@netcom.com (Bob Hathaway) writes:
>In article <MARKF.92Apr3114645@montreux.ai.mit.edu> markf@zurich.ai.mit.edu writes:
>>  I still think that some of the posters to this thread think that
>>funtional programming just means using an applicative style. What
>>really distinguishes functional programming is the use of higher order
>>functions (i.e. functions that accept functions as arguments and
>>return functions).
>
>Does this include C's function pointers and Modula's procedural variables
>and Ada's subprogram values (or even generic subprogram parameters) and etc.?

Or Smalltalk's ability to pass BlockClosures, Processes, message selectors,
or - in general - objects either way?

Hasko

-- 
+--------------------------------------------------------------------------+
| hasko@heeg.de  --  Hasko Heinecke @ Georg Heeg Objektorientierte Systeme |
| "Computers are different from telephones - computers do not ring." --AST |
+--------------------------------------------------------------------------+
From: skow@cs.utwente.nl (Jacek Skowronek)
Newsgroups: comp.object
Subject: INFO NEEDED on standards activities
Date: 12 Apr 92 14:19:51 GMT
Reply-To: skow@cs.utwente.nl
Organization: University of Twente, Dept. of Computer Science

I was recently on the kick-off meeting of ANSI X3H7 committee on Object Information
Management. I would like to know what groups or committees are working on standards
within Europe. I mean object-oriented programming and databases. Could You point me
to the addresses of the people taking part in it ?

Jacek


---
-------------------------------------------------------------------
Jacek Skowronek				e-mail: <skow@cs.utwente.nl>
Departament of Computer Science
Twente University
Enschede, The Netherlands
Xref: sparky comp.object:1695 comp.lang.c++:6536
From: freed@tfs.com (Erik Freed)
Newsgroups: comp.object,comp.lang.c++
Subject: Booch Libraries
Date: 6 Apr 92 20:36:39 GMT
Article-I.D.: tfs.1992Apr6.203639.12617
Organization: TRW Financial Systems

Has anyone any experience with the Booch/Rational Class library? I
will summarize to the net.
	thanks,
		erik

-- 
		-Erik Freed (freed@tfs.com)
From: mday@jukebox.lcs.mit.edu (Mark Day)
Newsgroups: comp.object
Subject: Re: Scanner, Parser Generator Critique
Date: 7 Apr 92 16:07:17 GMT
Article-I.D.: jukebox.MDAY.92Apr7110717
	<1992Mar31.004257.18397@mintaka.lcs.mit.edu>
	<MARKF.92Apr3114645@montreux.ai.mit.edu> <hppjbka.objsys@netcom.com>
Organization: /u/mday/.organization


   "Bob Hathaway" <objsys@netcom.com> writes:

   > markf@zurich.ai.mit.edu writes:
   >  I still think that some of the posters to this thread think that
   >funtional programming just means using an applicative style. What
   >really distinguishes functional programming is the use of higher order
   >functions (i.e. functions that accept functions as arguments and
   >return functions).

   Does this include C's function pointers and Modula's procedural variables
   and Ada's subprogram values (or even generic subprogram parameters) and etc.?

No.

Why is this thread in comp.object?

--Mark Day

mday@lcs.mit.edu
Newsgroups: comp.object