ftp.umcs.maine.edu

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 / detex / mayobre.detex < prev next >

Wrap

Text File | 1992-04-05 | 21.4 KB | 837 lines

[12pt] article Using Code Reusability Analysis to Identify Reusable Components from the Software Related to an Application Domain Guillermo Mayobre Hewlett Packard Grenoble Networks Division 5, Ave. Raymond Chanas 38053 Grenoble CEDEX 9 gm@hpgntol1,grenoble.hp.com The combination of SW metrics with domain expertise and economical evaluation of reuse costs, provides a way to select reusable workproducts from the software related to a domain of application. Introduction One of the major problems in software reuse is the lack of reusable components despite the large amount of existing software. Reuse efficiency and cost effectiveness highly depend on the number of available components. In fact existing software has captured past experience and knowledge, and that is particularly true under an application domain scope. The idea of using that existing software to identify reusable components is very attractive. A methodology to identify and select reusable software components from an existing code is extremely helpful, not only to provide code components, but also to identify reusable workproducts that have been codified by the past. The Code Reusability Analysis (CRA) combines three methodologies and an economical estimation to identify and select reusable workproducts from the code associated to a domain of application. Overview The first methodology involved is the one proposed by Caldeira and Basili . It allows identification of reusable components based on software metrics. The second one, the Domain Experience Based Component Identification Process (DEBCIP) is based on domain experience and uses a standard decision graph to help domain experts on the process of identifying reusable components. The third one, the Variant Analysis Based Component Identification process (VABCIP) also based on domain experience, uses code metrics to estimate the specification distance between a new product and the existing software in the domain (or subset of software of the domain). This methodology select components from the existing software, whose specification distance, to the new targeted functionality implies a re-engineering effort lower than building the component from the scratch. The economical estimation of the Component Return on Investment (CROI), uses economical models like Component Cost, Reuse Costs Investment and Benefits, Reuse Cost Effectiveness, to estimate the Return on Investment per Component. Selecting components from the existing software to be reused globally on the domain of application differs from selecting components to be reused to build a new target functionality. The second case is a subset of the first one in the sense that it reduces scope of search -(functions of a new product against all possible functions of a Domain of Application)- . The Code Reusability Analysis is useful to perform both types of selection depending on the way methodologies are combined. DEBCIP is tailored to identify components with the highest reuse potential within the overall domain scope. VABCIP is performant to identify components to be reused on a new targeted functionality. However those methodologies may be very expensive when applied to a large amount of software, in terms of time consumed by the experts and product marketing resources. C B does not require neither expert nor product marketing resources, and in addition it may be automized completely. An interesting idea is then to use C B before either DEBCIP or VABCIP to reduce the amount of code to be analysed by the experts. Once potential reusable components has been identified using C B, experts review them from the perspective of the domain of application. At the last step, an estimation of the Component Return On Investment of the candidates refines the final choice. This paper explores several ways of combining those methodologies to find the better strategy to select reusable components from the software associated to a domain of application, in order to build a new target functionality, minimising the implementation effort and maximising the external reuse level. Background This chapter gives an overview of the methodologies and economical models included on the Code Reusability Analysis. The Caldeira and Basili methodology It defines three major attributes that characterises the reusability of a component: usefulness, cost to reuse and quality. It proposes four software metrics to estimate the attributes values: Volume (V), Cyclomatic Complexity (C), Regularity (R) and Reuse Frequency (RF). Figure 1 is a fishbone diagram showing attributes and metrics relation: The Volume An Halstead's formula, represents the minimum number of bits necessary to code a module information: xxxxxxxx xxx Where n1: total number of operators used by the program, N1: total count of all usage of the operators, n2: total number of unique operands defined and used by the program, N2: total count of all usage of operands. If the component volume is too small, the cost to reuse the component (extraction, adaptation and integration), may exceed the cost to building it from scratch. If the volume is too large, the qualification will probably be lower and the component more error prone. 0.3in The Cyclomatic Complexity It computes the maximum number of independent paths: xxxxxxxx xxx Where e: number of edges, n: number of nodes. The bigger the complexity the higher the number of tests necessary to walk through all the code, and thus the effort to qualify the module. Once again a very low complexity may not repay the cost of extraction, adaptation and integration. A high complexity will probably imply a lower than expected qualification and a higher risk of error. 0.3in The Regularity Is the ratio between the expected length and the actual length of a component: In other words it measures readability and non redundancy of component implementation. A regularity close to one indicates a well implemented component. 0.3in The Reuse Frequency It measures the potentiality of a component to be reusable. It is the ratio between the number of static calls to a component with respect to the average number of static calls to a system module. The higher the reuse frequency , the bigger the reuse potentiality of a component. xxxxxxxx xxx Where M: number of system modules, n(C): number of static calls to the component C, n(Si): number of static calls to the system module Si. Ranges must be defined for every metric to measure the results. They may differ depending of the type of analysed code. Range values we used in our practical example are given in the case study section. DEBCIP and VABCIP The Domain Experience Based Component Identification Process DEBCIP and the Variant Analysis Based Component Identification Process VABCIP, illustrated in Figure 2 and 3 respectively, are both based in similar concepts. Both methodologies evaluate reuse potentiality based on specification distance and expected number of reuse instances. DEBCIP needs an important investment in domain analysis. Domain bounds must be well defined and domain model must be available to be able to evaluate the reuse potentiality of a component. Existing software functionality is compared to all the possible functionalities described in the domain model to evaluate expected number of instances and specification distance. The specification distance evaluation on DEBCIP is relatively complex. The first step is to define and intersection between all the target functionalities that we want to cover with a component, we call it the reduced functionality. Then, the specification distance from the existing software is evaluated to the reduced functionality. As the reduced functionality is very sensible to product strategies, market pressures and even resources fluctuation, the specification distance is used on DEBCIP more as an information parameter rather then a decision parameter. The biggest emphasis is put on the estimation of the expected number of reuse instances. VABCIP reduces the scope of search. Reuse potentiality of components is evaluated regarding a unique or a very few new targeted functionalities that are very close one to each other. On that case the major effort is put in the evaluation of the specification distance from the functionality of the existing software to the new targeted one. A well defined domain model is not crucial, and thus the prior investment on domain analysis is lower. R VABCIP (Reduced VABCIP) is a variant of VABCIP. The software whose functionality is compared to the new target one is a subset of the existing software related to the domain. R VABCIP process is also illustrated by Figure 3. 0.3in Collecting decisional information: Decision graphs provide a frame to collect decisional information: cost evaluation for changes on the analysed component to made it reusable, and expected number of reuse instances. (Figure 3 shows where cost of changes are evaluated in the VABCIP: SC , DC , CC ). Computed decisional information is used to feed the economical models to estimate the component Return On Investment. 0.3in Evaluating costs: Costs to change, what we called adaptation costs, are evaluated based on software metrics. We commonly use Cyclomatic complexity to evaluate the productivity. To each phase of software development: specification, design, code, unit testing, integration testing and tools development, we associate a productivity expressed in: Nb.of branches (or Independent paths = Cyclomatic Complexity)/ Engineer.week. Once a change is identified at any part of the graph, it is estimated on Cyclomatic Complexity. The adaptation effort to made the component reusable is then evaluated according to the type of change (specification, design, code,..) by applying the corresponding productivity metric. At the end of the graph walk through, the reuse potentiality of a component may be: None (non reusable) or Reusable with or without an associated adaptation cost and a number of reuse instances. The economical evaluation Reuse is cost effective when reuse cost benefits are bigger than reuse cost investments. Cost effectiveness of software reuse is an essential decision parameter that must be estimated at the earliest stage of product development. If an early estimates indicates that the total reuse benefits will be very low, we should do only a limited investment in reuse technologies. If at the contrary the estimates shows a big reuse benefits we should make substantial investment in advanced reuse technologies. On reuse oriented software development we can distinguish two main types of activities: product development and component development. Product development may be almost completely classified on the design WITH reuse side, while component development may almost completely classified on the design FOR reuse side. From this perspective reuse is cost effective when benefits of designing WITH reuse are bigger than investments on designing FOR reuse. In addition to the cost effectiveness another important parameter to evaluate the performance of an investment is the Return On Investment which is the ratio between the reuse costs benefits and the reuse costs investments. The Component Return On Investment is estimated for every candidate component to decide whether or not it is effectively reusable. Economical models like component cost, reuse costs investment and benefits, reuse cost effectiveness, are needed to estimate the component return on investment. The reusable component cost model The cost to produce a reusable component may be expressed as: xxxxxxxx xxx Where RCC: Reusable Component Cost. Measured in Eng.week. CC : Component Cost. Cost of the component as designed not for reuse.Measured in Eng.week. Eor: Reuse expansion (or multiplication) factor. DBC: Data Base Cost per component. Measured in Eng.week. Eor includes all additional costs to implement a reusable component. Additional documentation costs, specification costs, design costs , code costs, .... DBC includes the Data Base maintenance cost (system backup, configuration, maintenance) and also the Librarian activities. Librarian activities includes tasks as work in reusables assets to made them visible to potential users, marketing functions to identify users needs, component purchase, ... 0.3in Reuse cost investment Is the additional cost needed to made a component reusable. From that perspective it may be expressed as the cost difference between developing a component to be reusable against developing the same component not for reuse. xxxxxxxx xxx Where RI: Reuse Cost Investment. Measured in Eng.week. 0.3in Reuse costs benefits Benefits of reusing a component may be calculated as: xxxxxxxx xxx Where RB : Reuse Costs Benefits. Measured in Eng.week A : Adaptation cost. Measured in Eng.week. Is the cost to adapt the component to integrate it to the new application. DBR: Cost to search the component in the Data Base. Regarding the above definitions we may express the Component Return On Investment as the ratio between the sum of individual benefits for each reusing activity and the reuse costs investment to made the component reusable. xxxxxxxx xxx Where CROI : Component Return On Investment. NBinst: Number of expected reuse instances. Ai : Adaptation cost for integrating the component to an activity i. 0.3in Cost effectiveness of a reuse activity It may be also interesting to evaluate the reuse cost effectiveness of a project involved in a reuse oriented software development process considered in terms of the balance between the reuse cost benefits of designing WITH reuse against the reuse cost investment in designing FOR reuse: xxxxxxxx xxx Where NB. CNS: Is the number of consumed reusable components when designing WITH reuse. NB. PRD: Is the number of produced reusable components when designing FOR reuse. The Experience The experience was conducted over a case study to compare the usage of C B combined with R VABCIP against the usage of VABCIP. Context: The case study is on the context of the software reuse program at Hewlett Packard Grenoble Networks Division. This program has been running since 1.5 years. Models and methodologies proposed in addition to the Caldeira and Basili's one, has been developed by the reuse staff (apart from the project staff) during the reuse program development. Problem Statement It may be expressed generically as: Given an Application Domain with the associated workproducts and architecture, and given the specifications of a new product within the Domain, implement it, in such a way to maximise the external reuse level and minimise the implementation time. Of course that implies reusing, already existing components, and new selected ones, not yet recorded as reusables. The Case Study The analysed code is a subset of the software developed for the Datacomunications Front End Application Domain (DTC-FE). The subset was delimited according to architectural considerations: for example we do not analyse code involving X.25 staff, because we are leading mostly with Telnet Protocol and MPE/XL terminal IO. Size of the analysed code is 35K NCSS. The new product specification are the one of the pilot project ECRINS, involved in the Software Reuse Program. ECRINS project information: Staff: 7.5 engineers. Estimated Code Size: 40K NCSS (Non Commented Source Statements). (ECRINS is applying Formal Reuse Oriented Software Development Process, based on the results of the Code Reusability Analysis study). The Code Reusability Analysis takes four weeks. It involves a Domain Expert (architect), a Domain Analyst and a SW Engineer expert in SW metrics. Results Results are summarised in Figure 4. Column 1 shows the results of applying C B for two different Reuse Frequency: .5 and .3, and with 800 V <4000, .65 R 1.35 and 5 C 16. Column 2 shows the results after experts performed R VABCIP on the components previously selected by C B. Column 3 measures the accuracy of C B by computing the percent of components retained by the experts from those detected by C B. Those results shows C B as very accurate. Even for the case of lower reuse frequency the percent of code complexity retained after the experts advise of the code selected by C B is 88 . Column 4 shows the result of applying VABCIP directly. Column 5 and 6 compares results between C B + R VABCIP and VABCIP. As shown, the amount of selected components, code complexity and total effort avoided are higher when using VABCIP. But the selection time is 5 times longer. The Component Return On Investment estimation was 1.66 in average, and none of the components had a CROI lower than 1. Conclusion The strategy to follow to select reusable workproducts from the software related to a domain of application is shown in Figure 5. At the left side of the dashed line is shown the selection of workproducts globally reusables for the domain. That case was not considered on the case study, but, for medium to large systems we recommended to go first through C B. Then use DEBCIP for the retained components to estimate the expected number of reuse instances and specification distance, and finally do CROI to evaluate the component return on investment. At the right side of the dashed line is shown the selection of workproducts reusables on a new target functionality. In that case the strategy is the following: Use C B + R VABCIP as a first estimation. If you are about or better than the reuse objectives: shortage,... go directly through CROI. If you are far behind, perform VABCIP. In between, evaluate the cost of VABCIP with respect to the effort needed to develop from scratch the non detected components. bigg89 Biggerstaff and Perlis, Software Reusability , ACM Press, 1989. Caldieri and Basili, ``Identifying and Qualifying reusable software componentsi'' IEEE Computer , February, 1991. Booch, G., Software Components with Ada , Benjamin/Cummings, 1987. Barnes and Bollinger, ``Making reuse cost effective'', IEEE Software , January, 1991. Boehm, B., Software Engineering Economics , Prentice-Hall, 1983. Chauvet, ``Une analyse economique de la reutilisabilite'', AFCET Interfaces , Mai/Jun, 1991. Prieto-Diaz and Arango, ``Domain Analysis and System Modelling''.