home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sw / componen / 151 next >
Encoding:
Internet Message Format  |  1992-11-04  |  4.9 KB
  1. Path: sparky!uunet!pipex!warwick!uknet!mcsun!Germany.EU.net!Urmel.Informatik.RWTH-Aachen.DE!rwthi3!jubo
  2. From: jubo@rwthi3.informatik.rwth-aachen.de (Juergen Boerstler)
  3. Newsgroups: comp.sw.components
  4. Subject: Re: Reuse Discussion Topics (Was: Reuse and Software Components)
  5. Message-ID: <jubo.720960526@rwthi3>
  6. Date: 5 Nov 92 10:48:46 GMT
  7. References: <1992Oct29.182814.17630@den.mmc.com> <6597@dove.nist.gov> <1992Nov3.050919.8442@latcs1.lat.oz.au> <Bx56G1.8pr@cs.uiuc.edu>
  8. Sender: news@Urmel.Informatik.RWTH-Aachen.DE (Newsfiles Owner)
  9. Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
  10. Lines: 81
  11. Nntp-Posting-Host: john
  12.  
  13. johnson@cs.uiuc.edu (Ralph Johnson) writes:
  14.  
  15. >baragry@latcs1.lat.OZ.AU (Jason M Baragry) writes:
  16. [... stuff deleted ...]
  17. >What *exactly* is an architecture?
  18.  
  19. >>Consequently, when I design an electronic circuits (and I have designed
  20. >>electronic circuits) I think about objects with a specified and understood
  21. >>functionality. "I need an amplifier here or a voltage regulator there."
  22. >>Although I don't exactly know the specifics of the interface of these 
  23. >>components, I can design with them in mind and add bits to my design to 
  24. >>suit the implementation specifics of the componentry.
  25.  
  26. >This is exactly the way I program in Smalltalk.  I don't HAVE to know the
  27. >specifics of the interfaces of the components because they all use
  28. >standard interfaces.  I can put a Wrapper around any VisualCOmponent and
  29. >can stick any number of them in a VisualComposite.  I don't have to know
  30. >the parameters of the display routine or how to determine the location of
  31. >a component.  Since they are all VisualComponents, they all have the same
  32. >parameters and use the same operation for returning the location.
  33.  
  34. Right, if you assume inheritance=subtyping!
  35. In "designing" this way you will loose control over your "architecture",
  36. since most of the dependencies you introduce are not explicitely visible in
  37. your interfaces. Ok, there are a lot of tools that help (e.g. browsers), but
  38. to find the places of interest (i.e. which methods are executed) is a mess.
  39.  
  40. >Common interfaces eliminate the need for module interconnection languages.
  41.  
  42. This is a definite NO!! How do you want to define common interfaces without
  43. a common (module interconnection) language? 
  44.  
  45. >A MIL is way of hooking components together even when they do not have
  46. >similar interfaces.  You still have to do a bit of work to connect them.
  47.  
  48. How is this different from "... put a Wrapper around ..." (see above)?
  49.  
  50. >A great example of a standard interface is the electric system.  In the
  51. >U.S., all houses have 110 volts 60 hz current, and a consumer can buy
  52. >appliances from any store, hook them into any house, and they all work.
  53. >The consumer doesn't have to know very much about electricity, other than
  54. >things like "you have to plug an appliance in before it will work" and
  55. >"don't stick a fork in the wall socket".  An engineer designing a toaster
  56. >(i.e. someone designing a new component) has to know a lot about 
  57. >electricity, but the average consumer (i.e. someone useing the component)
  58. >does not.  EXACTLY the same is true of software.
  59.  
  60. And exactly to communicate the important aspects of such things is the essence
  61. and purpose of MILs (module interconnection languages). Your common interface
  62. is useless, if the consumer does not know what "you have to plug an appliance
  63. in before it will work" means.
  64.  
  65. >>I agree that standard interfaces are required, software bus technology is 
  66. >>another area needing much research, but I dont think SE designers are going to
  67. >>utilize these interfaces until they change the way the think about designing
  68. >>systems.
  69.  
  70. >My only complaint with this is that there are already a lot of us who
  71. >have changed the way we think about design systems and are using a component
  72. >based approach.  Of course, we are currently only a small fraction of the
  73. >total, but the numbers are growing.  New technologies, like the Parts system
  74. >from Digitalk, will increase the numbers of people who think this way.
  75.  
  76. >Ralph Johnson -- University of Illinois at Urbana-Champaign
  77.  
  78. jubo
  79.  
  80. ****************************************************************************
  81. * Ju"rgen Bo"rstler             * e-mail:                                  *
  82. * RWTH Aachen                   *    jubo@rwthi3.informatik.rwth-aachen.de *
  83. * Lehrstuhl fuer Informatik III *                                          *
  84. * Ahornstrasse 55               *                                          *
  85. * W-5100 Aachen                 * phone: +49/ 241/ 80-21310                *
  86. * Germany                       * fax:               -21329                *
  87. ****************************************************************************
  88.  
  89. --
  90. ****************************************************************************
  91. * Ju"rgen Bo"rstler             * e-mail:                                  *
  92. * RWTH Aachen                   *    jubo@rwthi3.informatik.rwth-aachen.de *
  93. * Lehrstuhl fuer Informatik III *                                          *
  94.