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 / patel.ascii < prev   
Internet Message Format  |  1991-11-05  |  20KB

  1. From patel@moriarty.rdd.lmsc.lockheed.com Mon Nov  4 13:10:35 1991
  2. Received: from eagle.is.lmsc.lockheed.com by gandalf.umcs.maine.edu (5.59/1.34-seg070391)
  3.     id AA20832; Mon, 4 Nov 91 13:10:24 EST
  4. Received: by eagle.is.lmsc.lockheed.com (5.57/Ultrix3.0-C)
  5.     id AA04370; Mon, 4 Nov 91 10:09:41 -0800
  6. Received: from moriarty.noname (moriarty.rdd.lmsc.lockheed.com) by galahad.rdd.lmsc.lockheed.com (4.1/SMI-4.1)
  7.     id AA04019; Mon, 4 Nov 91 10:07:23 PST
  8. Received: by moriarty.noname (4.1/SMI-4.1)
  9.     id AA04310; Mon, 4 Nov 91 10:07:38 PST
  10. Date: Mon, 4 Nov 91 10:07:38 PST
  11. From: patel@moriarty.rdd.lmsc.lockheed.com (Sukesh Patel)
  12. Message-Id: <9111041807.AA04310@moriarty.noname>
  13. To: larry@gandalf.umcs.maine.edu
  14. Subject: lockheed_ascii.txt
  15. Status: RO
  16.  
  17. A TOP-DOWN 
  18. SOFTWARE REUSE 
  19. SUPPORT ENVIRONMENT
  20.  
  21. Sukesh Patel, William Chu, Rich Baxter, Brian Sayrs, and Steve Sherman
  22.  
  23. Lockheed Software Technology Center
  24. Lockheed Palo Alto Research Laboratories
  25. 3251 Hanover Street, B/254E, O/96-10
  26. Palo Alto, CA. 94304-1191
  27. patel@stc.lockheed.com
  28.  
  29. ABSTRACT
  30.  
  31. The true potential of software reuse lies in providing facilities for reusing 
  32. large scale software systems. Given appropriate tool support software engineers 
  33. can leverage existing software investments by recovering the design of the 
  34. software and then systematically partitioning and extracting reusable 
  35. components from existing systems. It is also suggested that reusable components 
  36. must be subjected to a certification process prior to inclusion in a reuse 
  37. library. Moreover, simply retrieving large scale reusable components from a 
  38. library is not enough and appropriate software understanding tools must be 
  39. provided to permit interactive component understanding and selection. 
  40.  
  41. Keywords: Reuse, Certification, Reverse Engineering, Design Recovery, 
  42. Restructuring.
  43.  
  44.         INTRODUCTION
  45.  
  46. The potential benefits of Software Reuse has been extensively reported, both in 
  47. commercial and defense publications and in conferences world wide. [2,5,14]. 
  48. Libraries of mathematical functions (e.g., the IMSL library collection of 
  49. mathematical routines [6]) and Booch components [4] are instances of successful 
  50. (albeit limited) reuse programs. This is what we term bottom-up reuse: the 
  51. development of compact general purpose software components that can be combined 
  52. to synthesize a class of applications.
  53.  
  54. We believe that the true potential of software reuse is in exploiting the reuse 
  55. of very large scale software systems[2]. Although one would like reuse to 
  56. inform the complete software life-cycle, many times such investments are cost 
  57. prohibitive and software engineers must turn to existing systems/components for 
  58. reuse opportunities. Disparagingly, such reuse has been termed code scavenging. 
  59. But given appropriate tools, our belief is that incremental component 
  60. identification and improvement supports evolutionary development and is a cost 
  61. effective means of leveraging existing software investments. Large scale reuse 
  62. requires top-down reuse: the development of tools and techniques to understand, 
  63. certify, extract, and restructure components from existing software systems.  
  64. Our research suggests that solutions to the following problems must be pursued 
  65. to facilitate top-down reuse(1):
  66.  
  67.     Reusable Component Extraction: Tools and techniques to understand and 
  68. extract components from existing software systems.
  69.  
  70.     Reusability Certification Procedures/Metrics: A set of documentation, 
  71. coding, quality and reusability checks that instill confidence in reusable 
  72. software.
  73.  
  74.     Component Location and Composition Support: Processes and tools for 
  75. designing new applications by glueing together reusable and newly developed 
  76. software components.
  77.  
  78. We believe that (1) and (2) are critical technologies for leveraging existing 
  79. software investments. Issue (3) provides a framework to put pieces of the 
  80. puzzle together, and although important, must be established in the context of 
  81. particular applications and will not be addressed here in any depth.  This 
  82. paper is organized as follows. We cover our key technology thrusts in Sections 
  83. 2 (software re-engineering and restructuring) and 3 (reuse certification). 
  84. Section 4 illustrates our overall top-down reuse support environment and 
  85. provides a context for our technology thrusts. Section 5 summarizes our 
  86. progress.
  87.  
  88.         SOFTWARE RE-ENGINEERING & RESTRUCTURING
  89.  
  90. Our first key technology thrust is software re-engineering and restructuring 
  91. [1]. Software re-engineering and software restructuring are techniques that 
  92. facilitate the process of design recovery [3]. Design recovery attempts to 
  93. create design concepts and relationships based on analyzing source code and 
  94. available software artifacts. Our approach recognizes that full scale 
  95. automation for design recovery is difficult and instead supports tool 
  96. development that emphasizes automation of ``routine'' chores like system 
  97. partitioning and fact finding tasks. The principle steps that have been 
  98. implemented are:
  99.  
  100.     Partitioning systems based on minimizing the coupling relationships.
  101.  
  102.     Extracting ADTs that act as communication links between independent 
  103. components.
  104.  
  105.     Exploiting the visibility relation to yield sets of independent 
  106. components (If A and B both, call C and C does not contain state information, 
  107. then copies of C can be made to yield two components {{A,C},{B,C}}. If C 
  108. contains recognizable traits for state information, then {{A,B,C}} must be 
  109. treated as a primitive component).
  110.  
  111.     Exploiting cohesion properties to identify misplaced components (e.g., 
  112. a integer add operation in a STACK package can be identified and moved to some 
  113. INTEGER-OPS utilities package that can be with'ed)
  114.  
  115. Ultimately, isolation of independent components facilitates complexity 
  116. management and permits reuse/maintenance personnel to acquire system knowledge 
  117. on a piecemeal basis. This in turn provides knowledge of past systems that can 
  118. be used to supplement domain analysis to define application architectures.
  119.  
  120. In summary software re-engineering and restructuring technology provide the 
  121. following services for top-down reuse:
  122.  
  123.     Software Understanding: Large scale software is selectively displayed 
  124. and understood.
  125.  
  126.     Software Selection: Independent components can be recognized and 
  127. extracted and reused in different contexts.
  128.  
  129.     Software Translation: Existing software must be super-imposed with 
  130. different structural views (e.g., a system in C must be partitioned into CSCIs, 
  131. CSCs, CSUs, ADTs etc.) before the system can be syntactically converted to 
  132. Ada(2).
  133.  
  134.     Software Generalization: Software components comprised of independent 
  135. sub-components can be recognized and generalized by domain experts.
  136.  
  137.         REUSE CERTIFICATION
  138.  
  139. Reuse certification seeks to extract domain specific characteristics of 
  140. software components at all levels of abstractions that help to facilitate 
  141. reuse. In general, reusable software is quality software. Our strategy for 
  142. certification has been to survey characteristics of software components that 
  143. encourage reuse and then attempt to provide automated techniques for ensuring 
  144. that reusable software complies with or displays the required characteristics. 
  145. In cases where automated detection is ineffective or cost-prohibitive, 
  146. check-lists must be designed and manual procedures must be outlined as part of 
  147. a reusable software inspection process. For example, semantic checks can be 
  148. developed to recognize incomplete or inconsistent components.
  149.  
  150. Aspects of the certification process that can be automated are:
  151.  
  152.     Documentation Standards. Documentation prologues and certain 
  153. consistency checks on documentation (e.g., checks can be automated to ensure 
  154. that a module's call list is complete (all calls are mentioned) and consistent 
  155. (mentioned names are called somewhere in the program body)). Enforcement of 
  156. Variable and Type naming standards etc..
  157.  
  158.     Identification of system dependent features like primitive type 
  159. representations and the use of primitive I/O packages.
  160.  
  161.     Path analysis to determine if functions and procedures return valid 
  162. results on all logical paths.
  163.  
  164.     Measurable system quality indicators (cohesion, coupling, and 
  165. complexity)(3).
  166.  
  167. Notice that the above checks not only facilitate software reuse but are also 
  168. required to ensure quality software. Our research indicates that there are two 
  169. facets of reusable software: (a) a quality facet that all software should 
  170. satisfy (simple interface, minimal complexity, minimal testing complexity, 
  171. etc.); and (b) a domain appropriateness facet that determines to a large extent 
  172. whether a piece of software can be used in several applications (e.g., a 
  173. generalized stack is such a component). The later facet is much more difficult 
  174. to recognize and evaluate. Issues here include:
  175.  
  176.     Component Granularity: Is this component a valid primitive in the 
  177. domain, or does the component require further decomposition into primitive 
  178. operations and primitive data elements?
  179.  
  180.     Component Naming Conventions: Given a potentially reusable component, 
  181. are the objects and operations named with semantically meaningfully taxonomic 
  182. terms?
  183.  
  184.     Component Flexibility: Are the objects and operations sufficient to 
  185. synthesize required components in many situations?
  186.  
  187.     Component Generality: Is the component applicable to various problem 
  188. situations?
  189.  
  190. In view of the difficulty of recognizing the domain specific attributes of 
  191. reusable components we have initiated a research project for circumscribing the 
  192. domain appropriateness facet. More specifically, we have initiated a pilot 
  193. project whereby software engineers and researchers will interact with experts 
  194. in particular domains and establish a set of enforceable guidelines that can 
  195. help the process of identifying reusable software as (i) either one of the 
  196. output of domain analysis, or (ii) extracting such components from existing 
  197. systems. Certain progress has been made for (ii) at the Software Productivity 
  198. Consortium [12] and we shall extend both the scope and applicability of this 
  199. research.
  200.  
  201.         OVERALL APPROACH
  202.  
  203. Fig. 1 depicts the support necessary for depositing components into a reuse 
  204. repository. As shown in Fig. 1 reusable components are generated from two 
  205. primary sources: (1) the extraction and restructuring of components from 
  206. existing systems written in conventional imperative languages (C, Fortran, and 
  207. Ada), and (2) the development of domain specific components given broad 
  208. knowledge of intended applications.
  209.  
  210. Given a collection of reusable components, we must provide for some means to 
  211. organize these components in a user friendly manner. Software components can be 
  212. organized as appropriate to the intended applications: (a) a large set of 
  213. independent domain specific components for libraries, and (b) organization 
  214. along application architectures for narrow domains. Library organization is 
  215. common and is not discussed further.
  216.  
  217. Fig. 2 displays our vision of structures to support the reuse of existing 
  218. components for narrow domains.  This vision follows the design memory metaphor 
  219. outlined in [7,8] and seeks to provide designers a platform for visualizing and 
  220. inferring the consequences of design decisions. A user typically enters the 
  221. reuse environment and is given a top level view of a typical application 
  222. architecture. The architectures displays the principle top-level architectural 
  223. components, their associated information flows and relationships, and the 
  224. top-level storage structures. Components that be further decomposed into 
  225. sub-components are shaded. Such components have sub-components that may be 
  226. organized and controlled to perform the task required of the higher level 
  227. component. Components that are hatched indicate that there is no available 
  228. executable image associated with the module(4). This can occur when a component 
  229. is functionally coupled [13] to environmental objects that are likely to 
  230. change; for example a set of routines that read radar sensors and organize the 
  231. data in specific formats. 
  232.  
  233. For existing software systems without an associated knowledge base, the system 
  234. hierarchy is generated by reverse engineering tools that act as selective 
  235. display mechanisms. Here the system provides little inferencing ability but 
  236. allows a user to traverse the system and select components of various 
  237. granularity. 
  238.  
  239.         CONCLUSIONS
  240.  
  241. In this paper we have illustrated a promising architecture for solving problems 
  242. associated with large scale reuse. Currently, we are tackling both angles of 
  243. our overall approach (Figs. 1 and 2). We are in the process of developing a 
  244. prototype system that can accomplish the objectives of Fig. 2 for the target 
  245. tracker domain. Here our intent is to provide knowledge based support for 
  246. enhancing reuse opportunity. We have made substantial strides in re-engineering 
  247. and restructuring technology. We have applied our techniques to large software 
  248. systems in C and Ada with encouraging results. Currently, we are actively 
  249. involved in the following: (1) refining our re-engineering and restructuring 
  250. capabilities and expanding the scope of our techniques by experimenting with 
  251. other imperative languages like COBOL and FORTRAN, and (2) establishing 
  252. cooperative efforts to flesh out reuse certification procedures.
  253.  
  254.         REFERENCES
  255.  
  256.  R.S. Arnold (Ed.), Tutorial: On Software Restructuring, IEEE Press, Washington 
  257. D.C., 1986.
  258.  
  259.  T. J. Biggerstaff, & A. J. Perlis (Eds.), Software Reusability Volume 1: 
  260. Concepts and Models, and Volume 2: Applications and Experience, ACM Press, 
  261. Addison-Wesley Publishing Company, New York, NY, 1989.
  262.  
  263.  Biggerstaff, T. J., ``Design Recovery for Maintenance and Reuse'', IEEE 
  264. Computer, July 1989, pp. 36-49.
  265.  
  266.  G. Booch, Software Components with Ada: Structures, Tools, and Subsystems, The 
  267. Benjamin/Cummings Publishing Company, Inc., Menlo Park, CA., 1987.
  268.  
  269.  P. Freeman (Ed.), Tutorial: Software Reusability, IEEE Press, Washington D.C., 
  270. 1987.
  271.  
  272.  IMSL Inc., Library Reference Manual, Huston TX, 1987.
  273.  
  274.  Mark, W., ``Software Design Memory'', Proc. Workshop Notes AAAI-91: Automating 
  275. Software Design: Interactive Design, AAAI, Anaheim, CA., July 15, 1991, pp. 
  276. 115-120.
  277.  
  278.  Mark, W., & Schlossberg, J., ``Interactive Acquisition of Design Decisions'', 
  279. Proc. 5th Knowledge Knowledge Acquisition for Knowledge-Based Systems, Banff, 
  280. Canada, Nov. 1990.
  281.  
  282.  Neighbors, J.M., ``The Draco Approach to Constructing Software from Reusable 
  283. Components'', In P. Freeman (Ed.), Tutorial: Software Reusability, IEEE Press, 
  284. Washington D.C., 1987, pp. 181-191.
  285.  
  286.  Patel, S. J., Chu, W., and Baxter, R. W., ``A Measure for Composite Module 
  287. Cohesion'', Submitted, Proc. 14-th Intl. Conf. Soft. Engr., Melbourn, 
  288. Austrilia, 1992.
  289.  
  290.  Prieto-Diaz, R., ``Domain Analysis for Reusability'', InW. Tracz (Ed.), 
  291. Tutorial: Software Reuse: Emerging Technology, IEEE Press, Washington D.C., 
  292. 1988, pp. 347-353.
  293.  
  294.  Software Productivity Consortium (Author: R.S. Arnold), ``Heuristics for 
  295. Salvaging Reusable Parts from Ada Source Code'', SPC Tech. Report: Ada Reuse 
  296. Heuristics-90011-N, Version 01.00.00, March 1990.
  297.  
  298.  Stevens, W. P., Myers, G. J., & Constantine, L.L., ``Structured Design'', IBM 
  299. Systems Journal, Vol. 13, No. 2, 1974, pp. 115-139.
  300.  
  301.  W. Tracz (Ed.), Tutorial: Software Reuse: Emerging Technology, IEEE Press, 
  302. Washington D.C., 1988.
  303.  
  304.  Tracz, W., ``Software Reuse Myths'' in W. Tracz (Ed.),  Tutorial: Software 
  305. Reuse: Emerging Technology, IEEE Press, Washington D.C., 1988, pp. 18-22.
  306.  
  307. NOTES
  308.  
  309. (1) As noted in Tracz [15], management and economic reasons can also hinder 
  310. software reuse. However, in the following we assume the existence of 
  311. appropriate management structures that encourage and reward software reuse.
  312.  
  313. (2) Ada is a registered trademark of the U.S. Government (Ada Joint Program 
  314. Office).
  315.  
  316. (3) We have successfully developed a metric for module cohesion [10]. We have 
  317. also established some criteria that  lead to undesiriable coupling and are in 
  318. the process of proposing a measure for module coupling.
  319.  
  320. (4) Note that it is not necessary to always have a executable object file of 
  321. the component. Rather the component may itself be a application generator or 
  322. some expert system that can synthesize the required executable image.
  323.  
  324. Dr. Sukesh Patel is the  Principal Investigator for the Software Reuse and 
  325. Maintenance project at Lockheed's Software Technology Center (STC). Sukesh 
  326. received his B.S. in Electrical Engineering from Sadar Patel University (India) 
  327. and his M.S. and Ph.D. degrees in Computer Engineering from the Center for 
  328. Advanced Computer Studies at the University of Southwestern Louisiana. His 
  329. primary interests are design automation, design recovery, and the development 
  330. of evaluation techniques for large scale hardware and software systems. Sukesh 
  331. is a member of the IEEE and AAAI societies.
  332.  
  333. Dr. William Chu received his B.S. degree from the Tamkung University (Taipei, 
  334. Taiwan) in 1982 and his M.S. and Ph.D. degrees from Northwestern University, 
  335. Evaston, Illinois in 1987 and 1989, respectively, all in computer science. He 
  336. is currently a research scientist at the Software Technology Center of Lockheed 
  337. Missiles and Space Company, Palo Alto, California. His current interests are 
  338. software maintenance and reuse, with special focus on software re-engineering 
  339. and restructuring, software engineering, and software quality.
  340.  
  341. Mr. Rich Baxter received his M.S. degree in Computer Science in 1985 from the 
  342. New Mexico Institute of Mining and Technology (NMIMT). Mr Baxter joined 
  343. Lockheed Missiles and Space, Co. (LMSC) Research and Development Division's 
  344. Software Technology Center's (STC) Ada Technology group as a Scientific 
  345. Programmer/Analyst in 1988. Mr. Baxter is participating in several Ada related 
  346. internal research and development (IRAD) projects in the STC including the 
  347. Software Reuse in Large Ada Systems project. As a member of the Ada technology 
  348. group, Mr. Baxter is actively participating in the group's infusion of Ada 
  349. technology into LMSC and other Lockheed companies. Mr. Baxter has co-authored 
  350. several papers dealing with Ada Software topics while at Lockheed. Mr. Baxter 
  351. has been a member of the ACM since 1981 and of the IEEE Computer society since 
  352. 1989.
  353.  
  354. Mr. Brian Sayrs is the principal investigator for Software Re-engineering at 
  355. the Software Technology Center (STC). Brian has been involved with several 
  356. software re-engineering projects and is currently developing methods and 
  357. techniques for integrating forward and reverse engineering.
  358.  
  359. Dr. Steve Sherman is manager of the Software Technology Center (STC), Research 
  360. and Development Division, Lockheed Missiles and Space Company (LMSC). Dr. 
  361. Sherman received his B.S. in Mathematics from North Carolina State University. 
  362. After working for Pratt & Whitney in West Palm Beach, FL, Dr. Sherman joined 
  363. the University of Wisconsin where he received his M.S. in Computer Science in 
  364. 1968. Dr. Sherman worked for Sandia Corporation in the systems and nuclear 
  365. simulation groups in Albuquerque and subsequently received his Ph.D. in 
  366. Computer Science from the University of Texas at Austin in 1972. His 
  367. dissertation addressed the simulation of operating system heuristics for 
  368. performance prediction.
  369.  
  370. Dr. Sherman taught at the University of Houston for 2 years in the Computer 
  371. Science Department and left on leave in 1974 to work for the Institute for 
  372. Computer Applications in Engineering at NASA Langley in Hampton, VA where he 
  373. conducted research in data base management. In 1976, Dr. Sherman joined the 
  374. University of Nevada at Las Vegas as a faculty member in the Computer Science 
  375. department and was promoted to full professor in 1984.In 1985, Dr. Sherman 
  376. joined LMSC working for the STC in Austin, Texas where he led the technology 
  377. transfer group and the Ada environment project. In 1987, STC teamed with the 
  378. Space Systems Division (SSD) of LMSC to merge the Ada environment with SSDs 
  379. language independent software engineering environment. In 1988 Dr. Sherman led 
  380. his group to support a Lockheed Space Operations Company proposal and training 
  381. effort. Dr. Sherman led the Software Automation research group in Palo Alto and 
  382. his current group, also in Palo Alto, is conducting research in software 
  383. engineering.
  384.  
  385.  
  386.