🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sw.components
Article #394

SE and EE components

#394
From: Jason M Baragry
Date: Tue, 10 Nov 1992 04:28
78 lines
4552 bytes
	I've been reading the thread for a while now entitled:

"Reuse Discussion Topics (Was: Reuse and Software Components)" 

And alot of people have put in their point of view (including me). In my
research I have briefly compared SE and EE components however with the number
of comparisions being made in recent articles I believe it would be a good 
idea to start a discussion about what people think are the differences
between SE and EE components. (just to ensure these analogies are reasonable)

	I'll collect the replies and write a TR and
post it if people are interested. I guess the discussion doesn't have to be
limited to EE but traditional engineering components in general (mechanical,
structural)

	The sort of differences I've noted already include:

- Implementation types: SE has many implementation types (programming languages)
	which support particular design paradigms. ie: OO design and C++, 
	rule based design and prolog, etc.
	EE has only a single SET (ananlog & digital could be considered sep.
	sets but can be easily connected) of components, which leads to 
	a single design paradigm (modular).

- Complex Interconnections: SE modules can pass complex abstract data types
	and can use call be reference and call by value methods. EE modules
	do not invoke other modules, all modules operate constantly but the
	inputs which trigger the outputs are simply changed. In addition,
	the inputs are simple signals not complex data types.

- Predefied components: EE modules are manufactured and mass produced.
	It is much simpler to purchase a chip with the required functionality
	than it is to design and construct the chip again. Components which
	use these chips evolve and develop their own particular functionality,
	which can also be mass produced on a single chip, etc.

- Families of components: EE components exist in families where the
	functionality is similar however the implementation characteristics
	differ. Eg: speed, gain, etc. This helps the designer think in terms
	of the functionality of the family while designing and then choose the
	required member during the implementation.

- Malleability of Components: EE components are mass produced on chips which 
	are easy (sometimes) to integrate with other components. It is therefore
	advantageous in terms of money, time, and size to utilize these chips
	instead of re-inventing the component. Although SE re-use is advantageous
	in terms of time saved, the components are constructed from words which
	do not need to be purchased from a manufacturer and the physical size
	of these 'words' is not an issue. Additionally, it is much easier
	to take existing code and modify it with a text editor than it is to
	rip the top of a chip and change a resitor value! 
	Using existing components is imperative in EE while it is merely
	advantageous in SE. Consequently, programmers find it easier to modify
	an existing component or write a new one to meet the design rather
	than slightly modifying the design to accommodate the component as
	engineers do.


	Are there any other differences / similarities between SE and traditional
engineering disciplines that people can think of ? 

	Also, the notion of predefined and understood functionality of components
seems to be an important factor in engineering design. Are there plans for 
standardizing the functionality of software components rather than the interfaces
to them? 


regards,

Jason Baragry

-------------------------------------------------------------------------------
Jason Baragry.			|	Amdahl Australian Intelligent 
Dept Comp. Sci. & Comp. Eng.,	|		Tools Program
La Trobe University.,		|	baragry@latcs1.lat.oz.au
Bundoora. 3083.			|	Phone:	+61 3 479 1477
Australia.			|	Fax:	+61 3 470 4915
--------------------------------------------------------------------------------
Technical Details
Message-ID: <1992Nov10.042818.11581@latcs1.lat.oz.au>
Path: arc1-ca.pugleaf.net!sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!latcs1!latcs1.lat.OZ.AU!baragry
References: <Bx56G1.8pr@cs.uiuc.edu> <jubo.720960526@rwthi3> <ksand-051192155051@wintermute.apple.com> <1992Nov6.175825.2978@ampex.com> <ksand-061192220347@wintermute.apple.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!latcs1!latcs1.lat.OZ.AU!baragry
Newsgroups: comp.sw.components
Subject: SE and EE components
Message-ID: <1992Nov10.042818.11581@latcs1.lat.oz.au>
From: baragry@latcs1.lat.OZ.AU (Jason M Baragry)
Date: Tue, 10 Nov 1992 04:28:18 GMT
Sender: news@latcs1.lat.oz.au (news)
References: <Bx56G1.8pr@cs.uiuc.edu> <jubo.720960526@rwthi3> 
 <ksand-051192155051@wintermute.apple.com> <1992Nov6.175825.2978@ampex.com> <ksand-061192220347@wintermute.apple.com>
Organization: Comp Sci, La Trobe Uni, Australia
Nntp-Posting-Host: latcs1.lat.oz.au
Lines: 78