NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sw/componen/166

Internet Message Format | 1992-11-09 | 4.4 KB

Path: 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: <[e-mail]>
From: [e-mail] (Jason M Baragry)
Date: Tue, 10 Nov 1992 04:28:18 GMT
Sender: [e-mail] (news)
References: <[e-mail]> <jubo.720960526@rwthi3>
 <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Comp Sci, La Trobe Uni, Australia
Nntp-Posting-Host: latcs1.lat.oz.au
Lines: 78

    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.,        |    [e-mail]
Bundoora. 3083.            |    Phone:    [phone]
Australia.            |    Fax:    [phone]
--------------------------------------------------------------------------------