home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lsi / testing / 286 < prev    next >
Encoding:
Text File  |  1992-11-17  |  3.5 KB  |  80 lines
  1. Newsgroups: comp.lsi.testing
  2. Path: sparky!uunet!sun-barr!ames!elroy.jpl.nasa.gov!sdd.hp.com!apollo.hp.com!cupnews0.cup.hp.com!scd.hp.com!hpscdm!hpscdc!vinoski
  3. From: vinoski@ch.apollo.hp.com (Stephen Vinoski)
  4. Subject: Re: OOP and Testing
  5. Message-ID: <Bxx55r.5Kt@scd.hp.com>
  6. Sender: news@scd.hp.com (News Account)
  7. Organization: Hewlett-Packard Corporation, Chelmsford, MA
  8. References: <18848@ksr.com>
  9. Distribution: comp.lsi.testing
  10. Date: Wed, 18 Nov 1992 15:46:39 GMT
  11. Lines: 67
  12.  
  13. In article <18848@ksr.com> chuck@ksr.com (Chuck Shavit) writes:
  14. >
  15. >Dear netters,
  16. >
  17. >Writing ATPG and other testing-related tools in object oriented languages
  18. >(C++ comes to mind) seems like a good idea.  Did anyone in NetLand actually
  19. >do it?
  20.  
  21. A good idea?  Why, it's a great idea! :-)
  22.  
  23. For the Apollo DN10000 I wrote an interactive symbolic hardware
  24. debugger two years ago that allowed access to every scan path in the
  25. system under test via a local area network.  Users could group
  26. non-contiguous scan bits into logical registers for interactive
  27. symbolic access and control.  This system was designed using
  28. object-oriented (OO) techniques and implemented using C++.  (The
  29. software implementing the command line interface is called the Tool
  30. Command Language (Tcl) from Dr. John Ousterhout at Berkeley, see
  31. comp.lang.tcl.  This portion was not written in C++.)
  32.  
  33. A system of this sort was attempted two or three times before I tried
  34. it, and success was very limited each time.  I personally believe that
  35. my attempt ended up being highly successful due to my use of OO and
  36. C++.  I seriously doubt that I could have completed the implementation
  37. had I used C.  Some might argue that anything one can do in C++, one
  38. can do in C, and they'd be partially correct.  People who say such
  39. things do not realize how valuable compiler support for OO techniques
  40. really is.
  41.  
  42. The use of OO and C++ for this project paid off when we realized that
  43. we needed a translator that could convert ATPG test patterns into a
  44. format suitable for our offline scan test executive program.  I was
  45. able to simply replace the network communications objects in the
  46. debugger program mentioned above with objects allowing output to
  47. files.  I then augmented the command line interface with several
  48. commands specific to the translator requirements, and that was it.
  49. Talk about software reuse!
  50.  
  51. The key is that when using OO techniques you end up modeling the
  52. objects that exist in your problem domain.  The alternative
  53. algorithmic techniques, as Grady Booch says, merely "highlight the
  54. ordering of events."* Once you have suitably modeled the objects in
  55. your problem domain, those objects can readily be reused to solve
  56. multiple problems in that domain.  This is exactly what happened when
  57. I converted the debugger into a test translator.  The objects in my
  58. scan testing problem domain, such as Devices, Boards, ScanPaths,
  59. ScanVectors, etc., are the same for both problems, so I reused almost
  60. all of my debugger code for the translator solution.  The behaviors
  61. exhibited by these objects are essentially independent of any one
  62. specific problem.
  63.  
  64. Finally, the problem domains of hardware design and test are very easy
  65. to model with OO techniques, since they are inherently
  66. object-oriented.  I'm sure many others have pointed this fact out
  67. before.
  68.  
  69. -steve
  70.  
  71. *Object-Oriented Design With Applications.
  72.  Grady Booch.
  73.  The Benjamin/Cummings Publishing Company, Inc.
  74.  1991
  75.  ISBN 0-8053-0091-0
  76.  
  77. Steve Vinoski  (508)436-5904   vinoski@apollo.hp.com
  78. Distributed Object Computing Program
  79. Hewlett-Packard, Chelmsford, MA 01824       These are my opinions.
  80.