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 / joos.ascii < prev    next >
Text File  |  1993-10-19  |  10KB  |  258 lines
  1.  
  2.  
  3.  
  4.  
  5.                       Tools  to  Facilitate  the  Reuse  Process
  6.  
  7.  
  8.  
  9.                                                Rebecca Joos
  10.  
  11.  
  12.  
  13.                                                   Motorola
  14.  
  15.                                      6501 William Cannon Drive
  16.  
  17.                                           Austin, Texas 78735
  18.  
  19.                                                 MD: OE112
  20.  
  21.                                            Tel:  (512) 891-3617
  22.  
  23.                                  Email:  beckyj@pets.sps.mot.com
  24.  
  25.  
  26.  
  27.                                                   Abstract
  28.  
  29.  
  30.     Once an organization has implemented a process that embodies software reuse similar to the
  31. process discussed in this position paper, tools are necessary to facilitate software development.
  32. For several years Motorola (and specifically the author) has been involved with research that
  33. is  the  base  for  technology  that  will  facilitate  the  development  and  use  of reusable  software
  34. components (RSCs) [5 , 6].
  35.  
  36.  
  37.  
  38.                                                    Jo os-1
  39.  
  40.  
  41. 1      Position
  42.  
  43.  
  44.  
  45. Software developers must design with and for reuse.  Rather than trying to finda reusable compo-
  46. nent that matches a design module at the coding phase of the software life cycle, software developers
  47. should look for reusable components at the specification phase and continue the process through
  48. the analysis, design, coding, and testing phases. Reusable components can and should be specifi-
  49. cations, analysis procedures and data, designs, test programs, etc. All experiences from concepts
  50. to algorithms involved with the software development should be captured for future reference i.e.,
  51. reuse.
  52.  
  53.  
  54. The basic premise of the reuse technology is to assist software developers with the more difficult
  55. activities of software reuse while automating themundane and tedious tasks.  In order to achieve
  56. this goal the reuse toolkit (RTk) will provide:
  57.  
  58.  
  59.  
  60.     fflintelligent assistance that helps the software developer choose the appropriate RSCs to incor-
  61.        porate into the new product,
  62.  
  63.     fflan interface that is easy and quick to use yet enables the developer to provide exact input
  64.        necessary for the RTk to select appropriate RSCs,
  65.  
  66.     ffla simple method for adding new RSCs,
  67.  
  68.     fflautomation  to  relieve  the  software  developer  of  the  burden  of  linking  RSCs  into  the  new
  69.        product, and
  70.  
  71.     ffla mechanism for viewing the new product at several different levels of detail.
  72.  
  73.  
  74.  
  75. 1.1     Designing for Reuse
  76.  
  77.  
  78.  
  79. Building new products with RSCs assumes that there exists a wealth of comp onents.  This is a
  80. simple assumption but not a simple task [4].
  81.  
  82.  
  83.  
  84. 1.1.1     Reclaiming
  85.  
  86.  
  87.  
  88. Many  companies  have  their  valuable  product  knowledge  encoded  in  software  systems  that  are
  89. undecipherable. This knowledge represents the company's competitive advantage and expertise in
  90. their product area. If this knowledge was easily gleaned from the software, new pro ducts could be
  91. developed quickly and profitably.  The activity of finding and developing these RSCs is tedious and
  92. time consuming.
  93.  
  94.  
  95. In response to this realization reverse engineering tools are appearing on the commercial market.
  96. Reverse engineering is the process of taking source code and constructing a graphical representation
  97. from that code.  It is often referred toas design capture since the end product i.e., the graphical
  98. representation should resemble the original design.
  99.  
  100.  
  101. One of the most difficult problems of reverse engineering isdetermining "what" the end product
  102. is once it is produced. In many cases the end product is pages of arrows and names. Deciphering
  103. this overwhelming amount of informationis not easy [2 , 3, 11 ].
  104.  
  105.  
  106. Reverse  engineering  tools  have  evolved  towards  analyzing  programs  for  porting  or  cloning  these
  107. programs. But design recovery tools are aimed at helping the softwaredeveloper to understand the
  108.  
  109.  
  110.  
  111.                                                           Jo os-2
  112.  
  113.  
  114. specific applications and general concepts and designs that comprise classes of applications [1 ]. It
  115. is these general items that become RSCs.
  116.  
  117.  
  118. The objective of the design recovery aspect of the RTk is to aid the software developer form a mental
  119. model of the software, to record that model for future use, and to make the recovered knowledge
  120. easily and readily available for use.  This involves taking very detailed information and creating
  121. abstract forms of the information that can be applied generically i.e., reused inmany products.
  122.  
  123.  
  124. Domain analysis (DA) is the first step in creating reusable components [7, 9 , 10 ].  DA captures
  125. product  expertise  that  is  used  to  identify  common  problems  and  solutions of  software  systems.
  126. The system recognizes domain concepts in code or textual information.  Recognition is achieved
  127. by pattern matching of names, composition, development, subordinates, and user relationships to
  128. other components. Recognized concepts are displayed to the engineer who validatesor rejects the
  129. accuracy of the recognition which the system automatically incorp oratesto improves its perfor-
  130. mance.  The system provides the user with methodological guidance primarily for understanding
  131. the software and secondly (perhaps more importantly) for re-engineering the software.
  132.  
  133.  
  134.  
  135. 1.1.2     Construction
  136.  
  137.  
  138.  
  139. When developing new software componentsthat are potential RSCs the RTk assists the developer
  140. in formatting the components for readability, do cumenting the components for understandability
  141. and traceability. Once the component is completed the RTk provides testing mechanisms to assure
  142. the accuracy and quality of the component. The component is also categorized for storage in the
  143. repository.
  144.  
  145.  
  146.  
  147. 1.2     Designing with Reuse
  148.  
  149.  
  150.  
  151. Several questions arise when searching for RSCs touse in the new product:
  152.  
  153.  
  154.  
  155.     fflWhere are the best RSCs?
  156.  
  157.     fflWhat RSCs will be profitable?
  158.  
  159.     fflWhich RSCs should be developed first?
  160.  
  161.  
  162.  
  163. The reusable component is actually a node with a set of links to the software component's require-
  164. ments, transformation rule set, analysis, design, interfaces, and test suite nodes.  This hypernet of
  165. nodes and links comprises all the RSCs and their related items (e.g., tests) plus the information
  166. required to use the RSCs.  Since differentcomp onents can share (i.e., reuse) different nodes,  the
  167. repository becomes a large hypernet of component subnets.
  168.  
  169.  
  170. There will be two repositories. One is the master repository where all the proven reusable compo-
  171. nents are stored. The second repository will be an intermediate holding place for components that
  172. are being tested for their correctness, usability, and profitability. Until validated these components
  173. must be used with the same precautions as any newly develop ed software. Once they have qualified
  174. as viable reusable components they will be entered into the master rep ository.
  175.  
  176.  
  177. Eventually introducing this technologyinto a reuse program will automate the development cycle
  178. to:
  179.  
  180.  
  181.  
  182.                                                           Jo os-3
  183.  
  184.  
  185.     1. The user enters a set of requirements for which the RTk finds a matching RSCs.
  186.  
  187.     2. Based on user input the RSCs will be customized (i.e., transformations will fire) to satisfy
  188.        the software requirements.
  189.  
  190.     3. RSCs are interfaced to new components.
  191.  
  192.     4. The new product is tested by the automated testing tool.
  193.  
  194.     5. The new components are re-engineered into RSCs for future product development.
  195.  
  196.  
  197.  
  198. 1.3     Conclusion
  199.  
  200.  
  201.  
  202. The RTk encompasses design capture, re-engineering, reuse engineering and forward engineering.
  203. Although the toolkit is designed to facilitate software reuse, its real purpose is to provide a software
  204. design environment that incorporates the best methods and techniques toquickly develope high-
  205. quality software.
  206.  
  207.  
  208.  
  209. References
  210.  
  211.  
  212.  
  213.   [1] T. Biggerstaff, J. Hoskins, and D. Webster,"DESIRE: A System for Design Recovery," Tech.
  214.       Rep.  STP-081-89, Microelectronics  and  Computer  Technology  Corporation,  Austin,  Texas,
  215.       1989.
  216.  
  217.  
  218.   [2] T.  Biggerstaff  and  M.  Lubars, "Recovering  and  Reusing  Software  Design  -  Getting  More
  219.       Mileage From Your Software Assets," Tech. Rep. STP-RU-044-91, Microelectronics and Com-
  220.       puter Technology Corporation, Austin, Texas, 1991.
  221.  
  222.  
  223.   [3] T. Biggerstaff, "Software Reusability," Tech. Rep. MT-119-91,Micro electronics and Computer
  224.       Technology Corporation, Austin, Texas, 1991.
  225.  
  226.  
  227.   [4] E.  Guerrieri,  L.  Lashway,  and  T.  Ruegsegger,  "An  Acquisition  Strategy  for  Populating  a
  228.       Software Reuse Library," Tech. Rep. 302, SofTech, Inc., Waltham, Massachusetts, July 1989.
  229.  
  230.  
  231.   [5] R. Joos. PhD thesis, Texas A&M University,College Station, Texas, 1989.
  232.  
  233.  
  234.   [6] R. Joos, "Software Reuse Department," tech.rep., Motorola, August 1990.
  235.  
  236.  
  237.   [7] M. Lubars, "Domain Analysis for Reuse." Presentation to RTSG, Arlington Heights, IL, May
  238.       1990.
  239.  
  240.  
  241.   [8] R. Prieto-Diaz and P. Freeman, "Classifying Software For Reusability," IEEE Software, Jan-
  242.       uary 1987.
  243.  
  244.  
  245.   [9] R. Prieto-Diaz, "Domain Analysis For Reusability," IEEE Software, January 1987.
  246.  
  247.  
  248. [10]  W. Vitaletti and E. Guerrieri, "Domain Analysis within the ISEC RAPID Center," Tech. Rep.
  249.       308, SofTech, Inc., Waltham, Massachusetts.
  250.  
  251.  
  252. [11]  D. Webster, "Domain Modeling and Software Design Information Recovery," Tech. Rep. STP-
  253.       358-89, Microelectronics and Computer Technology Corp oration, Austin, Texas, 1989.
  254.  
  255.  
  256.  
  257.                                                           Jo os-4
  258.