🚀 go-pugleaf

baragry@latcs1.lat.OZ.AU (Jason M Baragry) writes:

>When I open one of my electronics books or undergrad electronics notes and 
>look at the index what do I see ?? Architectures.

>This is a AND gate, etc
>This is an AMPLIFIER
>This is an ACTIVE FILTER
>This is a PHASE LOCKED LOOP
>and so on and so on.

>If I open a Comp Sci book I find don't see architectures I see paradigms.

>This is how to do Object Orientated
>This is how to do Rule Based Approach
>etc.

Perhaps you have different books than I do.  My Comp Sci books say
things like "This is a compiler" and "This is a B-tree".  Only the
programming language books fit your characterization of them.

I've been in groups that talk a lot about architecture lately.  The
more I talk about it, the less sure I am about the definition.  Certainly 
the TI data book isn't about architecture, but rather describes a library
of components.  I guess you are talking about EE textbooks, which I would
think would be more "architecture-oriented".  How can you tell whether a
paper is about architecture or is about implementation?  About a component
library?  About a design paradigm?  People talk about things like the
"client-server" architecture, and I agree with you that this isn't really
an architecture.  But why do I (and apparently you) feel that way?
What *exactly* is an architecture?

>Consequently, when I design an electronic circuits (and I have designed
>electronic circuits) I think about objects with a specified and understood
>functionality. "I need an amplifier here or a voltage regulator there."
>Although I don't exactly know the specifics of the interface of these 
>components, I can design with them in mind and add bits to my design to 
>suit the implementation specifics of the componentry.

This is exactly the way I program in Smalltalk.  I don't HAVE to know the
specifics of the interfaces of the components because they all use
standard interfaces.  I can put a Wrapper around any VisualCOmponent and
can stick any number of them in a VisualComposite.  I don't have to know
the parameters of the display routine or how to determine the location of
a component.  Since they are all VisualComponents, they all have the same
parameters and use the same operation for returning the location.

Common interfaces eliminate the need for module interconnection languages.
A MIL is way of hooking components together even when they do not have
similar interfaces.  You still have to do a bit of work to connect them.

A great example of a standard interface is the electric system.  In the
U.S., all houses have 110 volts 60 hz current, and a consumer can buy
appliances from any store, hook them into any house, and they all work.
The consumer doesn't have to know very much about electricity, other than
things like "you have to plug an appliance in before it will work" and
"don't stick a fork in the wall socket".  An engineer designing a toaster
(i.e. someone designing a new component) has to know a lot about 
electricity, but the average consumer (i.e. someone useing the component)
does not.  EXACTLY the same is true of software.

>I agree that standard interfaces are required, software bus technology is 
>another area needing much research, but I dont think SE designers are going to
>utilize these interfaces until they change the way the think about designing
>systems.

My only complaint with this is that there are already a lot of us who
have changed the way we think about design systems and are using a component
based approach.  Of course, we are currently only a small fraction of the
total, but the numbers are growing.  New technologies, like the Parts system
from Digitalk, will increase the numbers of people who think this way.

Ralph Johnson -- University of Illinois at Urbana-Champaign