home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sw / componen / 152 < prev    next >
Encoding:
Internet Message Format  |  1992-11-04  |  3.2 KB
  1. Path: sparky!uunet!dove!swe.ncsl.nist.gov!kuhn
  2. From: kuhn@swe.ncsl.nist.gov (Rick &)
  3. Newsgroups: comp.sw.components
  4. Subject: Re: Standard SW Interfaces (Was: Reuse Discussion Topics)
  5. Message-ID: <6718@dove.nist.gov>
  6. Date: 5 Nov 92 19:00:41 GMT
  7. References: <1992Nov3.000359.17029@den.mmc.com>
  8. Sender: news@dove.nist.gov
  9. Lines: 63
  10. X-Newsreader: TIN [version 1.1 PL6]
  11.  
  12.  
  13. My previous followup got clobbered somehow; sorry for the empty posting.
  14.  
  15. Rick Kuhn
  16.  
  17.  
  18.  
  19. Joseph F. (Jeff) Hull (jhull@thor.NoSubdomain.NoDomain) wrote:
  20. : 
  21. : Are there any generalizations we can make (with any degree of 
  22. : assurance) about what constitutes a "good" standard interface?
  23. : Or a bad one?
  24. : 
  25. One characteristic of a good interface (i.e. good w.r.t. a particular
  26. problem) is that it provides a collection of services that are "close
  27. to the problem domain", i.e., neither too high or too a level of
  28. abstraction.  (Lots of people have written about this, so
  29. what I've said isn't particularly new.)  For example, Xlib might be
  30. considered a good interface for dealing with the X protocol, but not
  31. for doing higher level things like writing a menu driven package, where
  32. you want widgets to do menu bars, etc.
  33.  
  34. ..
  35.  
  36.  
  37. : |> 
  38. : |> These are major research questions, of course, but one problem with 
  39. : |> such interfaces today is lack of rigorous definition of the services 
  40. : |> provided.  ...  Formal descriptions would be even better.  
  41. :  
  42. : Who is proposing formal systems for such descriptions? How can I 
  43. : get in touch with them?  How do we get them involved in this thread?  
  44. : How do we get copies of their proposals posted here so we can read 
  45. : them?
  46.  
  47. There are a variety of formal description techniques that are suitable
  48. for these interface descriptions; VDM and Z are becoming well known.
  49. The programming research group at Oxford has specified some UNIX
  50. interfaces using Z.  However, the IEEE Tech. Committee on Operating
  51. Systems (TCOS), the parent body of the POSIX standards, does not plan
  52. to write formal descriptions of the POSIX interfaces.  TCOS has decided
  53. that formal interface descriptions would, in most cases, require too
  54. much effort to write, and there are relatively few people knowledgable
  55. enough to either write them or use them if they were provided.
  56. Although I think formal descriptions would be beneficial, I think the
  57. TCOS view is probably valid.  What might make formal descriptions cost
  58. effective would be tools to generate conformance tests from the
  59. descriptions, since building conformance tests is currently very labor
  60. intensive.  I've heard talk of some efforts in that direction and have
  61. been meaning to track down the details, but don't know much more now.
  62.  
  63. The situation is different for protocols.  There are some formal
  64. descriptions of OSI protocols; NIST and other organizations have built
  65. tools for generating code from specifications written in Estelle.  
  66. Some of this stuff can be ftp'ed from osi.ncsl.nist.gov.
  67.  
  68. --
  69.  
  70. Rick Kuhn                                   Telephone: +1 301 975 3337       
  71. Natl Institute of Standards & Technology    Fax:       +1 301 590 0932      
  72. Technology Bldg. B266                       Internet: kuhn@swe.ncsl.nist.gov
  73. Gaithersburg, Md.  20899  USA                       DRKuhn@dockmaster.ncsc.mil
  74.  
  75.