Article View: comp.sw.components
Article #10Re: Reuse Discussion Topics (Was: Reuse and Software Components)
From: Jason M Baragry
Date: Tue, 03 Nov 1992 05:09
Date: Tue, 03 Nov 1992 05:09
72 lines
3739 bytes
3739 bytes
In article <6597@dove.nist.gov>, kuhn@swe.ncsl.nist.gov (Rick &) writes: |> Joseph F. (Jeff) Hull (jhull@thor.NoSubdomain.NoDomain) wrote: |> : |> .. |> |> : |> : |> The thing that makes an integrated circuit so reusable |> : |> is that it is a member of a family of compatible integrated circuits. |> : |> There are standard interfaces so that any of them can be mixed with |> : |> any of the others. Thus, we really need to be defining abstract interfaces |> : |> as well as sets of objects that meet them. |> : |> : Absolutely! Standard interfaces were the great enabler of hardware integration |> : efforts and I believe they will perform the same role for software reuse. |> |> : followup question is, "What characteristics of interfaces enable reuse? I believe that the problem is a little different... 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. 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. Sure interfaces are important, but module interconnection languages have been around for at least 10 years and still re-use is nowhere near the level it should be. There is a fundamental difference between electronic design and SE design. SE designers modify create the objects to meet their design, whereas EE will modify their design (slightly) to accommidate the component which best provides the functionality required. Sure, you can say that it is alot easier to modify an existing SE module to meet the exact functionality than it is to rip a chip apart to change a resistor value, but it is this fundamental difference which is limiting the use of re-use. 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. Please tear this apart, your comments will help my research! Jason. ------------------------------------------------------------------------------- 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:
<1992Nov3.050919.8442@latcs1.lat.oz.au>Path:
arc1-ca.pugleaf.net!sparky!uunet!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!uwm.edu!caen!batcomputer!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!latcs1!latcs1.lat.OZ.AU!baragryReferences:
<1992Oct29.182814.17630@den.mmc.com> <6597@dove.nist.gov>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!noc.near.net!news.Brown.EDU!qt.cs.utexas.edu!cs.utexas.edu!uwm.edu!caen!batcomputer!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: Re: Reuse Discussion Topics (Was: Reuse and Software Components) Message-ID: <1992Nov3.050919.8442@latcs1.lat.oz.au> From: baragry@latcs1.lat.OZ.AU (Jason M Baragry) Date: Tue, 3 Nov 1992 05:09:19 GMT Sender: news@latcs1.lat.oz.au (news) References: <1992Oct29.182814.17630@den.mmc.com> <6597@dove.nist.gov> Organization: Comp Sci, La Trobe Uni, Australia Nntp-Posting-Host: latcs1.lat.oz.au Lines: 73