home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr4 / proceedings / ascii / knight.ascii < prev    next >
Internet Message Format  |  1991-11-10  |  11KB
  1. From @uvacs.cs.Virginia.EDU:jck@neptune.cs.Virginia.EDU Thu Nov  7 14:17:57 1991
  2. Received: from uvaarpa.Virginia.EDU by gandalf.umcs.maine.edu (5.59/1.34-seg070391)
  3.     id AA19732; Thu, 7 Nov 91 14:17:55 EST
  4. Received: from uvacs.cs.virginia.edu by uvaarpa.Virginia.EDU id aa28396;
  5.           7 Nov 91 14:17 EST
  6. Received: from neptune.cs.Virginia.EDU by uvacs.cs.Virginia.EDU (4.1/5.1.UVA)
  7.     id AA05845; Thu, 7 Nov 91 14:17:41 EST
  8. Posted-Date: Thu, 7 Nov 91 14:16:50 EST
  9. Return-Path: <jck@neptune.cs.Virginia.EDU>
  10. Received: by neptune.cs.Virginia.EDU (4.1/SMI-2.0)
  11.     id AA13337; Thu, 7 Nov 91 14:16:50 EST
  12. Date: Thu, 7 Nov 91 14:16:50 EST
  13. From: jck@neptune.cs.Virginia.EDU
  14. Message-Id: <9111071916.AA13337@neptune.cs.Virginia.EDU>
  15. X-Mailer: Mail User's Shell (7.2.0 10/31/90)
  16. To: larry@gandalf.umcs.maine.edu
  17. Subject: Ascii of posn paper
  18. Status: RO
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  
  36.                              ISSUES IN THE CERTIFICATION
  37.  
  38.                                   OF REUSABLE PARTS
  39.  
  40.  
  41.  
  42.                                    John C. Knight
  43.  
  44.                            Department of Computer Science
  45.                                University of Virginia
  46.                                     Thornton Hall
  47.                               Charlottesville, VA 22903
  48.  
  49.                                  knight@virginia.edu
  50.  
  51.  
  52.                                       ABSTRACT
  53.  
  54.      A substantial difficulties that is limiting reuse is a  lack  of  perceived
  55.      quality  in  the  artifacts  being  reused.   Availability  of  a part with
  56.      suitable functionality is not sufficient if the prospective user  does  not
  57.      trust  the part and refuses to use it as a result.  We present a definition
  58.      of certification to deal with this situation and propose  to  exploit  this
  59.      definition to permit savings during testing and maintenance.
  60.  
  61.  
  62.      Keywords: software reuse, part certification, software reliability
  63.  
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  80.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.                     ISSUES IN THE CERTIFICATION OF REUSABLE PARTS
  93.  
  94.           We claim that one of the substantial  difficulties  that  is  limiting
  95.      reuse  is  a  lack  of  perceived  quality  in  the artifacts being reused.
  96.      Although a software engineer may have a reuse library available,  there  is
  97.      frequently  a  reluctance to use it because of concerns about part quality.
  98.      Essentially, the engineer feels that without a lot of knowledge of a  part,
  99.      he  or  she  would  be  better  off  rebuilding it.  That lack of perceived
  100.      quality is a detractor from reuse is an observation based only on anecdotal
  101.      evidence  but  appears to be the software-reuse manifestation of the ``not-
  102.      invented-here'' syndrome.
  103.  
  104.           The adjective _c_e_r_t_i_f_i_e_d is sometimes used to describe parts that  have
  105.      been tested in some way prior to entry into a library (e.g., [3]).  Testing
  106.      parts prior to their insertion into a reuse library is often claimed to  be
  107.      a  productivity  advantage.   There  is the vague expectation that building
  108.      software from tested parts  will  somehow  make  testing  simpler  or  less
  109.      resource  intensive, and that products will be of higher quality [1, 2, 3].
  110.      Despite the various discussions of testing and reuse, the term certified is
  111.      not formally defined in the reuse literature.
  112.  
  113.           We are engaged in a research program that is addressing the  issue  of
  114.      certifying  reusable  parts.   We  advocate  the development of software by
  115.      reuse with the specific intent of establishing  as  many  of  the  required
  116.      properties  in  the  final product as possible by depending upon properties
  117.      present in the reusable  parts.   For  this  goal  to  succeed,  a  precise
  118.      definition  of  certification  of  reusable  parts  is required.  Given the
  119.      informal notions of certification that have appeared,  it  is  tempting  to
  120.      think  that  a  definition of certification should be in terms of some test
  121.      metric or similar.  The major difficulty with this approach, no matter  how
  122.      carefully  applied,  is  that  any single definition that is offered cannot
  123.      possibly meet the needs of all interested parties.  A second difficulty  is
  124.      that  by focusing on a testing-based definition, other important aspects of
  125.      quality, such as efficient execution performance or  ease  of  maintenance,
  126.      are  omitted  from  consideration.   These  difficulties  have  lead  us to
  127.      establish the following definitions:
  128.  
  129.      Definition:   _C_e_r_t_i_f_i_c_a_t_i_o_n _I_n_s_t_a_n_c_e
  130.                A certification instance is a  set  of  properties  that  can  be
  131.                possessed by the type of part that will be certified according to
  132.                that instance.
  133.  
  134.      Definition:   _C_e_r_t_i_f_i_e_d _P_a_r_t
  135.                A part is certified according to a given  certification  instance
  136.                if it possess the set of properties prescribed by that instance.
  137.  
  138.      Definition:   _C_e_r_t_i_f_i_c_a_t_i_o_n
  139.                Certification is the process by which it is  established  that  a
  140.                part is certified.
  141.  
  142.           An important byproduct of this precise definition of certification  is
  143.      that  it  provides a mechanism for _c_o_m_m_u_n_i_c_a_t_i_o_n about part quality between
  144.      the developer of a part and users of the part.  Users  no  longer  have  to
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.      question the quality of parts - certification describes for the prospective
  159.      user exactly what can be expected of a part.  When developing  a  part  for
  160.      placement in the library, it is the developer's responsibility to show that
  161.      the part has the properties required for that library.  When using a  part,
  162.      it  is  the  user's  responsibility  to  enquire  about  the precise set of
  163.      properties that the part has and ensure that they meet his or her needs.
  164.  
  165.           These definitions appear to be of  only  marginal  value  because  the
  166.      prescribed  properties  are  not  included.   However, it is precisely this
  167.      aspect that makes the definitions useful.  The definitions have three  very
  168.      valuable characteristics:
  169.  
  170.      (1)  _F_l_e_x_i_b_i_l_i_t_y.
  171.           As many different  certification  instances  can  be  defined  as  are
  172.           required.
  173.  
  174.      (2)  _G_e_n_e_r_a_l_i_t_y.
  175.           Nothing is assumed about the _t_y_p_e of part  to  which  the  definitions
  176.           apply.
  177.  
  178.      (3)  _P_r_e_c_i_s_i_o_n.
  179.           Once the prescribed property list in  the  certification  instance  is
  180.           established, there is no doubt about the meaning of certification.
  181.  
  182.           The properties included in a specific instance of certification can be
  183.      anything relevant to the organization expecting to use the certified parts.
  184.      However,  since  preparation  of  reusable  parts  is   a   major   capital
  185.      undertaking,  it  is  inappropriate  to  include  properties  that  are not
  186.      essential.  The opposite circumstance is also a factor.  If establishing  a
  187.      necessary  system  characteristic  is facilitated by the parts in the reuse
  188.      library having a  certain  property,  then  that  property  had  better  be
  189.      included in the certification instance.
  190.  
  191.           Thus the key to the definition of any specific certification  instance
  192.      is  the  use  to  be  made  of  the properties in the definition.  The _o_n_l_y
  193.      justification for the inclusion of a  particular  property  in  a  specific
  194.      certification  instance  is  that possession of that property by parts in a
  195.      library contributes to  the  establishment  of  useful  characteristics  in
  196.      systems built from those parts.
  197.  
  198.           We now have a general definition of certification for  reusable  parts
  199.      and  a  conceptual approach to developing specific definitions as required.
  200.      The key issues to be addressed in the area of certification are:
  201.  
  202.      (1)  What _s_y_s_t_e_m properties are common and of sufficiently high value  that
  203.           supporting them in a reuse development environment is cost effective?
  204.  
  205.      (2)  What techniques are required to permit the maximum exploitation of the
  206.           properties  of  parts  in  the  establishment  of  the properties of a
  207.           system?
  208.  
  209.      (3)  What library structures are required to store the  relatively  complex
  210.           entity formed from a part and an associated set of properties?
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.      (4)  Is there value in permitting library users to  search  based  on  both
  225.           part semantics and required certification properties?
  226.  
  227.      (5)  How does certification according to the approach outlined here  affect
  228.           the economic models of reuse?
  229.  
  230.      (6)  Since it is clear that properties of parts based on  testing  will  be
  231.           included  in  certification definitions, what issues are raised in the
  232.           area of testing parts?  The difficulty of testing  artifacts  such  as
  233.           Ada [4] generic units immediately comes to mind.
  234.  
  235.      (7)  What effect  does  the  adaptation  of  reusable  parts  have  on  the
  236.           definition of certification and its exploitation?
  237.  
  238.      (8)  Can  the  notion  of  certification  summarized   above   be   applied
  239.           successfully  to  parts  other  than  source  code and it is similarly
  240.           advantageous?
  241.  
  242.      (9)  What  would  the  instantiation  of  certification   look   like   for
  243.           requirements or test-plan parts?
  244.  
  245.           For software reuse to succeed in delivering a substantial  improvement
  246.      in  programmer  productivity  requires progress in a number of areas.  Part
  247.      certification is an important one.
  248.  
  249.  
  250.                                      REFERENCES
  251.  
  252.      [1]  Bassett, P.G.,  "Frame-Based  Software  Engineering",  _I_E_E_E  _S_o_f_t_w_a_r_e,
  253.           July, 1987.
  254.  
  255.      [2]  Lenz, M., H.A. Schmid, and P.F. Wolf, "Software Reuse Through Building
  256.           Blocks", _I_E_E_E _S_o_f_t_w_a_r_e, July, 1987.
  257.  
  258.      [3]  Tracz, W., "Software Reuse: Motivators and Inhibitors", _P_r_o_c_e_e_d_i_n_g_s _o_f
  259.           _C_O_M_P_C_O_N _S'_8_7, 1987.
  260.  
  261.      [4]  U.S. Department of Defense, Ada Joint Program Office, _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l
  262.           _F_o_r _T_h_e _A_d_a _P_r_o_g_r_a_m_m_i_n_g _L_a_n_g_u_a_g_e, ANSI/MIL-STD-1815A, January, 1983.
  263.  
  264.  
  265.                                      AUTHOR BIOGRAPHY
  266.  
  267.           John C. Knight is an associate professor of computer  science  at  the
  268.      University of Virginia.  Before joining the University of Virginia in 1981,
  269.      he was with NASA's Langley Research Center.  His research interests  center
  270.      on developing techniques for building software for safety-critical systems.
  271.      To that end, he is undertaking  a  research  project  in  certification  of
  272.      reusable  parts  with  a  view  to  exploiting  reuse  to  support software
  273.      reliability.
  274.  
  275.  
  277.  
  279.  
  280.  
  281.  
  282.  
  283.