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 / wisr6 / proceedings / ascii / hislop2.ascii < prev    next >
Text File  |  1993-10-19  |  12KB  |  303 lines

  1.  
  2.  
  3.  
  4.  
  5.       Using  Existing  Software  in  a  Software  Reuse  Initiative
  6.  
  7.  
  8.  
  9.                                            Gregory W. Hislop
  10.  
  11.  
  12.  
  13.                                        Working Knowledge, Inc.
  14.  
  15.                                                738Elgin Rd.
  16.  
  17.                                      Newtown Square, PA 19073
  18.  
  19.                                            Tel:  (215) 359-9080
  20.  
  21.                                Email: hislopg@duvm.ocs.drexel.edu
  22.  
  23.  
  24.  
  25.                                                   Abstract
  26.  
  27.  
  28.     Existing software is often not well-suited for reuse. At the same time, it isa natural starting
  29. point for organizations trying to adopt a reuse strategy. Any efficient techniquesfor extracting
  30. value from existing software would ease the transition to a reuse-based approach.
  31.     My efforts have focused on trying to derive value for reuse from existing software.  I have
  32. been exploring ways to apply to reuse ideas developed to detect plagiarism.  I am also quite
  33. interested in the behavioral issues, both individual and organizational, related to starting and
  34. sustaining a reuse strategy.
  35.  
  36.  
  37. Keywords: software reuse, software similarity, plagiarism detection
  38.  
  39.  
  40. Workshop Goals: My goals for the workshop are to exchange information on researchefforts
  41. and to discuss the status and results of formal reuse initiatives in commercial and governmental
  42. organizations.
  43.  
  44.  
  45. Working Groups: Useful and collectable metrics; Reuse management, organization, andeco-
  46. nomics; Reusable component certification.
  47.  
  48.  
  49.  
  50.                                                   Hislop- 1
  51.  
  52.  
  53. 1      Background
  54.  
  55.  
  56.  
  57. I approach reuse from the perspective of both research and industry.  I have recentlycompleted a
  58. doctorate with a thesis focused on reuse. In addition, I am involved with fledgling reuse efforts at
  59. several commercial organizations.
  60.  
  61.  
  62. Having a foot on both sides of the fence keeps me quite conscious of thegap b etween state of the
  63. art and state of the practice in software engineering.  Ihave a general interest in technology transfer
  64. and ways to close that gap.
  65.  
  66.  
  67.  
  68. 2      Position
  69.  
  70.  
  71.  
  72. Existing software contains a large amount of encoded knowledge about the organization and the
  73. organization's  past  software  needs.  This  material  could  be  very  valuable  for  reuse  if  we  could
  74. extract it efficiently.
  75.  
  76.  
  77. Existing software is also a natural starting pointfor implementing reuse, especially for an incre-
  78. mental implementation. Existing software provides a familiar point of reference that may reduce
  79. uncertainty, and help create a feeling of ownership.  Finally, it may be difficultto justify a ma jor
  80. initiative that does not start with the existing software.
  81.  
  82.  
  83. At the same time, working with existing software may involve significant problems. The quality of
  84. source code is uneven. The documentation is often inadequate. And existing software was probably
  85. not designed for reuse.
  86.  
  87.  
  88. In short,  while the idea of using existing software is app ealing,  the reality is difficult.  We need
  89. special tools to support this work. We can extract gold from ore that looks like common rock. If
  90. we are going to use existing software, we need todevelop more economical extraction techniques
  91. to find the flakes of gold in our software.
  92.  
  93.  
  94. Intuitively  we  might  be  inclined  to  evaluate  existing  software  by  function,  i.e.,  what  it  does.
  95. Reusable  parts  are  generally  selected  by  function, and  functional  categories  are  the  usual  basis
  96. for organizing parts collections.  It would be logical to analyzethe existing software by function
  97. too.  Unfortunately, analysis  by  function  is  very  difficult  to  automate  and  so  tends  to  be  quite
  98. expensive.
  99.  
  100.  
  101. An alternative to evaluating by software function is to measure software form, i.e., what the software
  102. looks like.  Software form includes characteristics such as size and structure.  It is well suited to
  103. automated measurement, and there is a wealth of prior work that has studied various attributes of
  104. form.
  105.  
  106.  
  107. One way to look at software form is toconsider the broader question of software similarity. That is,
  108. are there parts in the existing software that arevery similar to each other? A possible application of
  109. this type of analysis would be for locating instances of informal reuse with or without mo dification.
  110.  
  111.  
  112. There is an existing pocket of research that measures software form to detect similarity.  These
  113. studies are attempts to detect plagiarized student programming assignments.  Clearly, this is quite
  114. close to our interest. Plagiarism, after all, is simply a socially unacceptable form of reuse.
  115.  
  116.  
  117. A basic problem in many plagiarism studies stems from the fact that most software metrics are
  118.  
  119.  
  120.  
  121.                                                          Hislop- 2
  122.  
  123.  
  124. single values. For example, Non- Comment Source Statements (NCSS), is a single value. Single-
  125. valued metrics are very convenient for reporting and analysis, but their conciseness may not provide
  126. the discriminant power needed to detect similarity.
  127.  
  128.  
  129. For example, similar programs might have similar NCSS  values.  However, it is easy to imagine
  130. programs with similar NCSS values that are not atall similar except in size.
  131.  
  132.  
  133. An alternative approach is to representattributes of software form in a less concise manner than a
  134. single-valued metric. Whale has proposed a structure profile which is a variable length descriptor
  135. based on control structure.[1] He reports better success at detecting plagiarism with this approach
  136. than with methods based on single-valued metrics.
  137.  
  138.  
  139. I have taken concepts from the work on plagiarism and applied them to reuse. Student assignments
  140. are generally different from commercial software in size, complexity, and style, so it was not clear
  141. whether the concepts would transfer to this new application. I created a prototype tool, SoftKin,
  142. and conducted a series of case studies to test the concepts.
  143.  
  144.  
  145.  
  146. 2.1     SoftKin Prototype
  147.  
  148.  
  149.  
  150. SoftKin is a prototype tool for exploring approaches to measuring software similarity.  The name
  151. reflects the idea that SoftKin looks for related software parts.
  152.  
  153.  
  154. SoftKin  consists  of  a  data  collector  and  analyzer.  The  collector  processes  existing  software  and
  155. calculates measures of form for each module. The analyzer computes similarity measures for each
  156. module pair. The pairs of modules can then be ranked from most similar to least similar by each
  157. similarity measure.
  158.  
  159.  
  160. SoftKin can calculate similarity based on a variety of measures of software form.  These include
  161. single-value metrics (such as McCabe's CyclomaticComplexity), a metric composite, and also a
  162. structure profile that is a slight variant of the profile proposed by Whale.
  163.  
  164.  
  165. The case study goal was to see if any of the approaches to measuring similarity show promise for
  166. identifying candidate parts that might be reengineered for areusable parts collection.
  167.  
  168.  
  169. To evaluate the various similarity rankings, I focused on the task of locating informal reuse.  In each
  170. of the case studies, we were ableto identify a set of instances of reuse in the existing software. This
  171. allowed me to evaluate each measure by where the known instances of reuse fall in the similarity
  172. ranking. A good ranking is one that places the actual reuse instances near the top of the list.
  173.  
  174.  
  175. This evaluation provides a relative measure of various methods of similarity detection. As a pro-
  176. duction tool, SoftKin would guide an analysis of existing software. The ranking by similarity would
  177. suggest where to focus attention in looking for candidate reusable parts. If SoftKin is successful,
  178. the best candidates for a parts collection would be clustered near the top of thelist.
  179.  
  180.  
  181.  
  182. 2.2     Case Studies
  183.  
  184.  
  185.  
  186. The case studies analyzed existing software from 3large commercial organizations. The applications
  187. were all commercial data processing systems including areas such as finance, sales, and distribution.
  188. The analyzed software consisted of about 360 modules totaling 156,000 NCSS.
  189.  
  190.  
  191.  
  192.                                                          Hislop- 3
  193.  
  194.  
  195. The case study results are quite interesting. The results of the single-value metrics are all fairly
  196. poor.  In fact, a ranking by similarity of size provides as good a result as a ranking by any of the
  197. other single-value metrics. However,the average similarity, which is a composite of thesingle-value
  198. rankings, provides substantially improved performance.
  199.  
  200.  
  201. The ranking by structure profile is the best method for locating instances of actual reuse. This is
  202. particularly true for the top part of the ranking, which is the part that has practicalvalue.  For
  203. example, a sizeable percentage of the known cases of reuse fall in the first 100 ranked pairs.  (The
  204. actual results are 37, 50, and 63 percent, respectively, for the three case studies.)
  205.  
  206.  
  207. We can test the statistical significance of the result based on the structure profile vs.  the other
  208. metrics. Using Dunnett's T to control for Type I error across the set of comparisons, the structure
  209. profile  shows  a  significant  performance  improvement  versus  the  single-value  metrics  at  the  0.05
  210. level. The improvement over the average similarity, while substantial, is not significant at the 0.05
  211. level.
  212.  
  213.  
  214. The pattern of results is very consistent across the three case studies.  This is particularly encourag-
  215. ing since the case study settings vary substantially including differences in programming language,
  216. development methodology, andorganization size.
  217.  
  218.  
  219. In general, concepts carried overquite well from plagiarism detection to reuse. Single-value metrics
  220. show poor results for locating the instances of informal reuse.  On the other hand, a composite
  221. based on these metrics performed much better. Finally, the structure profile approach provided the
  222. best performance.
  223.  
  224.  
  225.  
  226. 3      Comparison
  227.  
  228.  
  229.  
  230. A number of studies have applied measures of form to software reuse.  Selby conducted a general
  231. analysis to determine the characteristics of software that is known to have been reused.  [2] This
  232. work provides some general guidelines that may indicate attributes that are desirable for reusable
  233. software.
  234.  
  235.  
  236. Calderia and Basili make extensive use of form metrics in their strategy for locating reusable parts in
  237. existing software in the Care system.[3] They propose a reusability attributes model for determining
  238. probable reusability for a part. The major attributes are:
  239.  
  240.  
  241.  
  242.     fflQuality of the part.
  243.  
  244.     fflCosts of using the part.
  245.  
  246.     fflUsefulness of the part.
  247.  
  248.  
  249.  
  250. It is easiest to associate measures of software form with thequality and cost attributes of the model.
  251. It is more difficult to propose automated measures to predict usefulness of the part.
  252.  
  253.  
  254. For the Care system, "reuse frequency" is taken as a predictor of usability.  This value is based
  255. on the number of static calls to a software part.  This approach may be quite effective in some
  256. environments. However, it requires that a given part have only one name. In addition, it does not
  257. consider cases in which there are variants of a part each with a different name.
  258.  
  259.  
  260. The  software  similarity  approach  that  SoftKin  explores  could  be  used  to  complement  the  reuse
  261. frequency measure of the Care system.
  262.  
  263.  
  264.                                                          Hislop- 4
  265.  
  266.  
  267. References
  268.  
  269.  
  270.  
  271. [1]  G. Whale, "Software Metrics and Plagiarism Detection," vol. 13, pp. 131-138, 1990.
  272.  
  273.  
  274. [2]  R. W. Selby, "Quantitative Studies of Software Reuse," in Software Reusability, Vol II (T. Big-
  275.      gerstaff and A. Perlis, eds.), pp. 213-233, ACM Press, 1989.
  276.  
  277.  
  278. [3]  G.  Calderia and  V.  R.  Basili,  "Identifying  and  Qualifying  Reusable  Software  Components,"
  279.      IEEE Computer, February 1991.
  280.  
  281.  
  282.  
  283. 4      Biography
  284.  
  285.  
  286.  
  287. Greg Hislop has held technical and management positions in software organizations for almost
  288. 20 years.  He is principal of Working Knowledge, Inc., a company he founded in 1987 to provide
  289. services and education to information systems groups.
  290.  
  291.  
  292. His current work involves software reuse, downsizing mainframe applications, I/S tools and tech-
  293. niques for distributed organizations, and practical application of software metrics. He also provides
  294. services related to measuring and analyzing I/S workloads andcharging for I/S services.
  295.  
  296.  
  297. Dr.   Hislop  holds  degrees  in  Economics  from  Georgetown University,  Computer  Science  from
  298. Queen's University, and Information Studies from Drexel University.
  299.  
  300.  
  301.  
  302.                                                          Hislop- 5
  303.