Article View: comp.sw.components
Article #394SE and EE components
From: Jason M Baragry
Date: Tue, 10 Nov 1992 04:28
Date: Tue, 10 Nov 1992 04:28
78 lines
4552 bytes
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!baragryReferences:
<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