home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / software / 5148 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  2.8 KB
  1. Path: sparky!uunet!dove!swe.ncsl.nist.gov!kuhn
  2. From: kuhn@swe.ncsl.nist.gov (Rick Kuhn)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: Putting Engineering into Software Engineering
  5. Message-ID: <7679@dove.nist.gov>
  6. Date: 24 Dec 92 14:57:13 GMT
  7. References: <1992Dec20.234713.10503@latcs1.lat.oz.au>
  8. Sender: news@dove.nist.gov
  9. Lines: 50
  10. X-Newsreader: TIN [version 1.1 PL6]
  11.  
  12. Jason Baragry (baragry@amdahl1.lat.oz.au) wrote:
  13.  
  14. ..
  15.  
  16. : 
  17. :     I think the difference is that in other engineering disciplines these
  18. : modelling / analysis techniques provide a way to analyse the properties of the
  19. : components which constitute the system. In these engineering fields there is
  20. : a high level of reuse and to compare components you need some way of
  21. : representing the properties of these components.
  22.  
  23. Exactly, that's why reusable software components will require some type of
  24. formal specifications for their properties.  The current approach of
  25. relying on English descriptions of components makes it hard to say how
  26. well a component matches a requirement specification.
  27.  
  28. :     Sure, algorithms in SE can be measured by speed but if I am looking
  29. : at which electronic components I would want to reuse to meet my needs I can
  30. : use circuit analysis, frequency & phase analysis, transmission line theory,
  31. : etc to do it. How can I analytically compare to high-level SE components to
  32. : see which one meets my needs the best? (assumming people may one day actually
  33.  
  34. I've been interested in this problem for some time.  I have a paper in the
  35. Dec. 92 Computer Journal (BCS) that has a start to answering this
  36. question.  It describes a technique for analyzing the effects of changes
  37. in formal specifications, which can also be used to determine which of two
  38. specifications more closely matches a requirement.
  39.  
  40. : think like this!) I have to rely on written documentation of what the thing
  41. : does and how the thing does it. Perhaps there isn't any way of modelling high
  42. : level SE components. Perhaps the only way to compare SE modules without
  43. : simply relying on documentation (which is very quantifiable) is to animate
  44. : those components and compare their operating performance.
  45. : 
  46. : Jason.
  47. : 
  48. : -------------------------------------------------------------------------------
  49. : Jason Baragry.            |    Amdahl Australian Intelligent 
  50. : Dept Comp. Sci. & Comp. Eng.,    |        Tools Program
  51. : La Trobe University.,        |    baragry@latcs1.lat.oz.au
  52. : Bundoora. 3083.            |    Phone:    +61 3 479 1477
  53. : Australia.            |    Fax:    +61 3 470 4915
  54. : --------------------------------------------------------------------------------
  55.  
  56. --
  57.  
  58. Rick Kuhn                                   Telephone: +1 301 975 3337       
  59. Natl Institute of Standards & Technology    Fax:       +1 301 590 0932      
  60. Technology Bldg. B266                       Internet: kuhn@nist.gov
  61. Gaithersburg, Md.  20899  USA                       DRKuhn@dockmaster.ncsc.mil
  62.