Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!abvax!icd.ab.com!ejp
From: ejp@icd.ab.com (Ed Prochak)
Newsgroups: comp.software-eng
Subject: Re: OOP and estimating
Message-ID: <1493@abvax.UUCP>
Date: 3 Jul 90 17:48:01 GMT
References: <25062@mimsy.umd.edu> <5253@stpstn.UUCP> <31116@cup.portal.com> <26855613.749b@petunia.CalPoly.EDU>
Sender: news@abvax.UUCP
Reply-To: ejp@icd.ab.com (Ed Prochak)
Organization: Allen-Bradley Company, Industrial Computer Division
Lines: 102

I am way behind in this discussion, so I this point has been covered
go ahead and ignore my bringing it up again. One point that John mades
is that you should be able to pick objects and use them without regard
(at least initially) to performace:

In article <26855613.749b@petunia.CalPoly.EDU>,
 jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
> 

> cliffhanger@cup.portal.com (Cliff C Heyer) writes:
   [deleted stuff about outside interfaces]
> >
> >But nothing to change the fundamental problem: When you are programming
> >you are not assembling pre-engineered components. You are developing
> >an new sequence of steps to perform a task. This is not and will never be
> >accurately quantifiable. (I'm just waiting for some manager to give me
> >his logic why this is wrong...and post it)
> 
> I would like to see some managerial-level input on this topic, too!
> 
   [deleted psychology stuff too]
> 
> >With objects, you may have to tune that internal algorithm for a specific 
> >task to save CPU time. Oh, but wait - you can't do this because this 
> >would violate the fundamental principle of objects. Why should you not be 
> >able to take advantage of a flexibility that software affords over
hardware???
> 
> The idea is that you shouldn't have to be concerned unless you want to be,
> about such aspects as algorithm fine-tuning.  Certainly I wouldn't advocate
> that algorithms shouldn't be fine-tuned to an application.  I would say
> that if you can show that an algorithm used in an object in your application
> is the cause of performance that does not meet your requirements, then you
> should find the sourcecode of the object and fine tune it, or else otherwise
> come to a solution.
> 
> >>But that does not
> >>mean that every time I go to write a program I will write every line of
> >>code from scratch.  If there is a way that I can use well-made components,
> >>so much the better.  Then I can spend my energy working on the real design
> >>issues of the project.
> >I agree, but my experience with the "real world" makes me suggest this 
> >to be impractical.
> 
> You're probably right for now.  Whether or not this continues to be
> impractical in the future will depend on how well the technology
> catches on.
> 

I haven't done any OOP yet, so my comments are based on reading this
newsgroup and Abstract Data Types ideas.

  John assumes access to the source code. This is unlikely for
objects purchased from a software vendor. It seems that for there to
be a component marketplace, there must be several vendors of the same
or similar objects. How will the vendors promote their product against
a competitor? 

Consider a market for software components with two types of customers:
1 mainframe system users (or at least systems with virtual menory)
  with large processing requirements.
2 micro users with embedded systems applications.

Both need some graphics widgets with essentially the same properties
except that
-users in group 1 expect fast response for many on-line users
-users in group 2 need to have a known maximum memory requirement.

Vendors may develop the widgets with various peformance properties,
one vendor with a fast, memory hog widget and another with a slower,
but memory lean widget. Beyond those attributes, the widgets are
exactly the same. There may even be other vendors with widgets that
have performance, momory requirements in between the first two. The
users will buy the ones that match their requirements. And if the
requirements change, they can move to another widget, possibly from
another vendor. Hopefully, some interface standards will allow the
vendors components to interoperate.

I see it as very similar to the choice in hardware: should the
product used super fast logic like ECL?   Or must it meet strict
power limits so CMOS is best? or something in between?
Even in regular TTL there are families: Schotky (S), Lowpower
Schotky (LS), Advanced LS (ALS), others?? with different power
and speed tradeoffs.
Note that hardware has interoperate requirements also,
for example signal voltage levels must be compatible.

My bottomline point is that tuning
 may not require change source code.
It may just as likely involve swapping
one object with a similar one having 
different performance attributes that
better match the application.

Does this sound close to being in the ballpark?


(Pardon the inconvenience during our remodelling of the signature file)
Edward J. Prochak        (216)646-4663         I think. 
{cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com    I think I am.
Allen-Bradley Industrial Computer Div.       Therefore, I AM!
Highland Heights,OH 44143                      I think?  --- Moody Blues