Software Technological Roles, Usability, and Reusability

M. Burgin H. K. Lee N. Debnath Department of Department of Science Department of Mathematics and Mathematics Computer Science University of California, . University of Texas of the Winona State University Los Angeles Permian Basin Winona, MN 55987 Los Angeles, CA 90095 Odessa, TX 79 762

Abstract That is why it is so important to have efficient reuse metrics that quickly tell us the relative ease of using a Software reuse is an important and relatively nav given software component in new environment and for approach to sofiare engineering. The aim of this paper another sohare system [22, 231. Many problems with is &rther development of a methodolo# and reuse metrics are also considered in [24]. mathematical theo y of software metrics for evaluation of In this paper, we develop methodological and software reusabilig. In the second section, going after theoretical foundations for building effective reuse Introduction, it is demomstraied that reusability is U form metrics. In the second section, going after Introduction, it of usabiliv. This allows one io use experience in the is demonstrated that reusability is a form of usability. This development and utilization of sofiare usabilig metria allows one to use experience in the development and for the development and utilization of sofhvare reuse utilization of software usability metrics for the metria. In the third section, different opes and classes of development and utilization of software reuse metrics. For softwore metrics are explicated and compared, while in instance, in the extended IS0 model of software quality, the fourth section, sofware metrics and their properties these are nine characteristics (understandability, in a formalized coniexf are studied The research is learnability, operability, explicitness, customisability, oriented at the advancement of softWnre engineering and, attractivity, user-friendliness, clarity, and helpfulness) for in particular, at creation of more efficient reuse metrics. usability and only two characteristics (the ratio of reusable parts and the ratio of reused parts) for reusability. Our approach makes it possible to use usability characteristics 1. Introduction for building new useful software metric for reusability. In addition, this approach provides for utilization of some According to [ 161 the idea of software reuse appeared important types of software reusability metrics for in 1968, opening new horizons for software design. A measuring software usability. good sohare reuse process is able to facilitate the In the third section, different types and classes of increase of productivity of program design and software metrics are explicated and compared, while in development, reliability of software product, and the the fourth section, software metrics and their properties decrease of costs and implementation time, That is why, are studied in a formal context. as Devanbu, Peny, and Poulin [14] write, increasing levels of software reuse constitute one of the most 2. Reusability as a form of usability pervasive and profound influences in software engineering today and there is actually now a reuse marketplace. To compare usability and reusability, let us look at However, a direct application of the reusability idea definitions of these two software properties. has been hindered by many obstacles and most of the Definition 1. Usability is a property of software expectations have not been met. One of the problems characterizing its (potency for) utilization. encountered is the selection of the right software This definition has two consequences. First, usability component for reuse. This is related not only to the is characterized by a set of attributes that bear on the similarity between the desired functionality and the effort needed for use, and on the individual assessment of hnction delivered by the retrieved software component, such use, by a stated or implied set of users. Second, there but also to the effort needed to modify the chosen are two types of reusability metrics - potential and actual. component to accommodate the desired functionality.

0-7803-8819-4/04/$20.00 02004 IEEE. 210 Usability is formalized in [8] as a kind of program building a system by writing code is replaced with hardship, which consists of three components: DC- building a system by assembling and integrating existing complexity, C-complexity, and P-complexity. software components. By enhancing the flexibility and Definition 2. Software reuse is the process of maintainability of systems, this approach can potentially implementing or updating software systems using existing be used to reduce software development costs, assemble software assets [ 11 1, systems rapidly, and reduce the spiraling maintenance This implies the foliowing deJnition. burden associated with the support and upgrade of large Definition 3. Reusability is a property of software systems. In addition, software testing and validation are characterizing its (potency for) reuse. also simplified [ZO]. At the foundation of this approach is In other words [ 191, reusability is the degree to which the assumption that certain parts of large software systems a software module or other work product can be or is used reappear with sufficient regularity that common parts in more than one computing program or software system. should be written once, rather than many times, and that Thus, we have two types of reusability metrics - potential common systems should be assembled through reuse and actual. rather than rewritten over and over. Taking the extended IS0 model of sohare quality It is necessary to remark that programming Ianguages 1301, we see that such indicator of reusability as the ratio constitute an important factor for reusability. Modularity of reusable parts that compares the number of reusable of the utilized programming language orients software parts of the software product to the total number of parts developers, who now are not only programmers but also of the same software product is a potential software end users [lo], to use the component-based approach in metric. At the same time, such indicator of reusability as building software. Some languages provide better the ratio of reused parts that compares the number of modularity than others. For instance, programming reused parts of the software product to the total number of languages formed on the base of such programming parts of the same software product is an actual software metalanguage as BS-language [3] are oriented to achieve metric. high modularity of programs. The same is true for object To explicate relations between usability and oriented programming languages. As a result such reusability, we consider technological roles of objects languages would provides better facilities for software involved in a technological process, in our case, the reuse. process is information processing. According to the Comparing Definitions 4-6, we come to a natural mathematical theory of technology [4, 51, the main roles conclusion that reusability is also a kind of usability as of objects in astechnological process are: materials, tools, reuse is a kind (constructive type) of software utilization. and executors/perfonners. This correlates with the empirical understanding of This implies types of software utilization: reusability in some cases. For instance, Tracz observed 1. Functional utilization. that for programmers to reuse software, they must first 2. Processual utilization. find it use~W[28].At the same time, Poulin indicates [22] 3. Constructive utilization. that the usefulness of a component depends as much on Definition 4. When a program is used to compute the framework in which it fits as it does on intemal (realize) some function, it is calledfunctionol utilization. characteristics of the component. We consider these Functional utiiization appeared as the first function of aspects in the next Section. computers and is the most conventional mode of their functioning. Definition 5; When a program is used to realize some 3. Types of Software Metrics process, it is calledprocessuai utilization. Operating programs and educational software give The traditional software metrics, such as the LOC examples of processual utilization. Operating programs (lines of code), length of the program, volume of the organize the process of computer hnctioning. Educational program, cyclomatic number, and software science effort software organizes learning processes. depend completely on the properties of the evaluated Definition 6. When a program is used as material for program [3 11, construction, it is called constructive utilization. As Poulin writes [22], the ability to reuse software Thus, program reuse is a constructive utilization when depends on environmental factors that fall completely out another program is constructed. Such construction of of the scope of individual software modules or programs from components of other programs is called components. The search for a general reusability metric component-based software development (CBSD). must consider these environmental factors as well as Component-based software development focuses on factors derived from the software. We conclude that building large software systems by integrating previously- although we can determine empirical values for reusability existing sofhare components [I, 2, 271. The notion of

21 1 awibutes of software, we cannot establish a general Definition 10. Any function m: A + L , or n: I + L, reusability metric. is an internal softwllre metric or measure with the scale L. This demonstrates necessity in such software metrics Let Pr = { Pr, ;je J } be a class of processes and m: that depend not only on the evaluated program itself. Pr + A be a total mapping, We call such processes Programmers use metrics of this type. Examples are program related. benefit of program reuse [13], cost, staffing, and schedule Definition 11. Any function p: Pr -+ L , or q: J + L, of the program design [18j. is an exteemolsoftware metric or measure with the scale L. A general approach to this problem was suggested by Proposition 1. For a system of program related Fenton [15]. He categorizes software measures along two processes, any intemal software metric defines an external orthogonal two-dimensional axes. The first is the software metric with the same scale. process/product axis. In the first dimension along this Definition 12. Any fiction k AxPr 3 L, or h: IxJ axis, a metric measures an attribute of sohare product, + L, is an intermediate sofhvare metric or measure with e.g., quality of code. In the second dimension along this the scale L. axis, a metric measures an attribute of software process, Proposition 2. Any pair of internal and external e.g., cost of design review meetings. Another axis is the software metrics with the same scale L induces an internaUexterna1 axis. In the first dimension along this intermediate software metric with the same scale. axis, a metric measures an internal attribute, e.g., the There are following important cases of sohare number of loops in a module. In the second dimension metrics. along this axis, a metric measures an extemal attribute, Definition 13. If the range of a software metric r is a e.g., maintability of a module. subset of the set: Extending Fenton’s approach, we consider three types a) of all non-negative real numbers RI, then r is called of sohare metrics: a numerical metric; - Intemal software metrics. b) of all natural numbers N,then r is called an integer - Extemal sohare metrics. metric; - Intermediate software metrics. c) (RY, (the set (N)“ ), then r is called a vector Definition 7. An ilzternal sofmare metric is a measure (integer vector) mepic;. of software systems that completely depends on the d) of all real number (natural number) arrays, then r is estimated system itself. called a (integer) multidimensional metric. Examples of intemal software metrics are LOC, SLOC, Traditionally software metrics have numerical values. program fength, voIume, level, dificulty and software science At the same time, Prather writes [26] that “it is fairly effort [17], cyclomatic complexity of the program [21]. certain that no one “magic number” can serve as a Definition 8. An external sojiware metric is a measure measurement for all characteristics of sohare that might of software systems that completely depends on some be considered important., ,” Orientation at numerical process(es) that involves the estimated software system. metrics also hinders development of reusability metrics. Examples of extemal software metrics are staffing for As Poulin emphasizes (1996), “many people have program development [ 181 and benefit of program reuse identified factors and attributes that tend to make software r 131. easier to reuse, but arriving at single, unifying metric that Definition 9. An intermediate sohare metric is a brings these attributes together continues to elude US.” measure of software systems that depends on connections Thus, as it is demonstrated in [6, 91, it is necessary to between the estimated software system and some build and use vector valued and higher dimensional process(es) that involves this system. software metrics. Examples of intermediate software metrics are: Given some software metrics, it is often useful to build software hardship [SI, which evaluates programs with new metrics applying different operations. For instance, respect to their utilization by users; program productivity, Here we consider two operations in spaces of vector and which depends on computer that realizes this program. multidimensional metrics: a) a projection, which corresponds to a vector (array) one of its elements; 4. Software Metrics and their Properties in a b) an association, in which vectors (arrays) are Formalized Context combined into vectors (arrays) of higher dimension, in particular, separate elements are combined into vectors In comparison with previous approaches [7,9, 15, 17, (arrays). 22,311, here we extend the concept of a software metric. Let A = { Ai ; if I be a class of programs and L be a partially ordered set.

212 1. Examples of associations: Remark 2. Monotonicity of software metrics is based Functionality, according to the extended IS0 model on a natural assumption that any part of the whole has [30], is a vector association of suitability, accuracy, lower complexity than the whole, i.e., the complexity interoperability, compliance, security, and traceability. mesure is monotonous. Reliability, according to the extended IS0 model [30], Proposition 5. If a vector (multidiniensional) software is a vector association of maturity, fault tolerance, metric is monotonous, then any its projection is recoverability, availability, and degradability. monotonous with the induced order relation on its scale. Maintainability, according to the extended IS0 model Building an association of software metrics, we form [30], is a vector association of analysability, the scale of the association as the direct product of the changeability, stability, testability, manageability, and scales of the combined metrics. Partial orders on the reusability. combined scales in a natural way induce a partial order on Software quality, according to the extended IS0 model the direct product. This allows us to prove the following [30], is a two dimensional association of result. subcharacteristics of such characteristics as functionality, Proposition 6. Any association of monotonous reliability, usability, efficiency, maintainability, and software metrics is a monotonous vector portability. (multidimensional) software metric with the induced order I. Examples of projections: relation on its scale. Interoperability is a projection of functionality. Fault tolerance is a projection of reliability. Reusability is a projection of maintainability. 5. Conclusion Proposition 3. Any one-dimensional projection of B vector (multidimensional) software metric is a numerical Reusability is primarily connected with component- software metric of the same type. based software development, which is focused to develop Proposition 4. Any association of numerical software the technologies needed to enable systematically reusable metrics that have the same type is a vector software components - relatively small, carehlly (multidimensional) software metric of the same type. engineered software elements suitable for a broad array of Usually software metrics satisfy some additional applications. These technologies would enable software conditions and have additional properties (cf., EX, 9, 13, companies to build specialized components that can be 26,291). Let us consider some of them. sold to systems integrators and custom builders, who One of the most important is monotonicity. Let m be a would combine them with other, largely purchased, off- software metric. the-shelf components to create high-quality custom rf an algorithm Ai from A is a subalgorithm of an applications. an established softwarecomponents industry algorithm Ajfiom A, then m(i) 2 m(9. would provide a rapid, responsive channel for marketing Remark 1. Monotonicity is a principal property of software innovations, while constantly improving quality, complexity measures because it is natural to suggest that a reliability, and capability. part is always simpler, or has lower complexity, than the However, software reusability is wider than whole. However, this is not always true. For instance, if component-based software development. Software assets, we can see a chair, but cannot see atoms, which are parts or components, include all software products, fiom of the chair. So, for such an operation as seeing, atom has requirements and proposals, to specifications and designs, infinite complexity, while a chair has very low to user manuals and test suites [12]. Anything that is complexity. produced from a software development effort can To eliminate this possibility for programs, we consider potentially be reused. explicit and implicit subprograms, assuming that SA is It is necessary to remark that relations between satisfied onbfor explicit subprograms. sohare reusability and usability metrics allows one to Definition 14. A subprogram A of a program B is introduce new kinds of software usability metrics. For called expIicit if the complete text of A is included in the instance, Devanbu et al, [13] introduce and study reuse text of B. Otherwise, the program A is called an implicit benefit metrics. In a similar way, it is possible to subprogram of the program B. introduce, study, and use utilization benefit metrics. For instance, a program B utilizes operator A, which is realized as program outside B. It is possible that the text 6. References of this realization is written in a different programming language than the program B. In this case, A is an implicit [I] Brooks, F. P. Jr. "No Silver Bullet: Essence and Accidents of subprogram of the program B. Software Engineering," Campuler, v. 20, No. 4, 1987, pp. 10-9

213 [2] Brown, A. W. “Preface: Foundations for Component-Based [ 191 Institute of Electrical and Electronics Engineers, IEEE Software Engineering“, Component-Based Sofhvare Standard Computer Dictionay: A CompiIation of IEEE Engineering: Selected Papers from the Sofiwore Engineering Standard Computer Glossaries, New York, NY, 1990. Insfitufe, Los Alamitos, CA, IEEE Computer Society Press, [20] Kansomkeat, S., and Rivepiboon, W. “Component 1996, vii-x. Specification to Test Component-based Software”, in [3] Burgin, M. “Recursion Operator and Representability of Proceedings of the ISCA 19‘h International Conference Functions in the Block-Scheme Language”, Programming and “Computers and their Applications”, ISCA, Seattle, Computer Software, v. 2, No.4, 1976, pp. 13-23 (translated Washington, 2004, pp. 282-285 from Russian) [21] McCabe, T. J., “A Complexity Measure”, IEEE Transaction [4] Burgin, M. “Mathematical Theory of Technology”, in on Software Engineering, SE-2, 1976, pp. 308-320 Methodological Problems of Mathematics and Information [22] Poulin, J. S. “The Search for a General Reusability Metric”, Sciences, Kiev, 1997, pp. 91-100 (in Russian) Proceedings of the Workshop on Reuse and the NASA Sofnyare I5 J Burgin, M. “Mathematical Models for Simulating Straregic Plan, Fairfax, VA, 1996, pp. 24-21 Technological Processes”, in “Proceedings of the Business and [23] Poulin, J. S. Measuring Sofhvare Reuse: Principles, Industry Simulafion Symposium,” SCS, San Diego, California, Practices, and Economic Models, Addison-Wesley, Reading, 2002, pp. 165-1 68 MA, 1997 [6] Burgin, M.S., and Chelovskii, Yu. A. “Multidimensional [24] Poulin, J. S., ”Reuse Metrics Deserve a Warning Label: structural analysis of FORTRAN programs”, Control Systems The Pitfalls of Measuring Software Reuse“, Crosstalk; The crndMuchines, No. 1, 1982, pp. 38-39 (in Russian) Journal of Defense Sofmare Engineering, Vol. 10, No. 7, 1997, [7] Burgin, M., and Debnath, N.C. “Complexity of Algorithms pp. 22-24 and Software Metrics”, in Proc. ISCA 181h Int. Conf. I251 Poulin, J. S., ”Measurement and Metrics for Software “Computers and their Applications”, Honolulu, 2003, pp. 259- Components,” in G. T. Heineman and W. Council1 (eds.). 262 Component Based Software Engineering, Addison-Wesley, [SI Burgin, M., and Debnath, N.C. “Hardship of Program Boston, MA, 2001, pp. 435-452. Utilization and User-Friendly Software”, in Proc. ISCA 161h Ifit. 1261 Prather, R.E. “An Axiomatic Theory of Software Con$ “Computer Applicalions in Industry and Engineering”, Complexity Measure”, Computer Journal, v. 27, No. 4, 1984, Las Vegas, 2003, pp. 314-311 pp. 340-347 [9] Burgin, M., and Debnath, N.C. “Measuring Software I271 Szyperski, C. Component Sofhvure: Beyond Object- Maintenance”, in Proceedings of the ISCA 19th lntemational oriented Programming, Addison-Wesley, 1998 Conference “Computers and their Application<’, ISCA, Seattle, [28] Tracz, W., Software Reuse Maxims, ACM Sofhvure Washington, 2004, pp. 118-321 Engineering Notes, Vol. 13, No. 4, 1988, pp. 28-3 1. [IO] Cypher, A. (Ed.), Watch What I Do: Programming by [29] Weyker, E.J. “Evaluating Software Complexity Metrics”, Demonstration, MIT The Press, Cambridge, Massachusetts, IEEE Transactions on Software Engineering, v. 14, No. 9, London, England, I993 1988, pp. 1357-1365 [ 111 Department of Defense, Sojtwclre Reuse Executive Primer, (301 B. van Zeist, P. Hendriks, R. Paulussen en J. Trienekens, Falls Church, VA, April, 1996 (http://sw-eng.fulls- Kwaliteit van sofrwareprodukten - Prakfijkervaringen me# een church. vu. h fm) us/ReuselC/policy/primer/primer, haliteitsmodel, Kiuwer Bedrij fswetenschappen, 1996. [ 121 Department of the Navy, DONSoftware Reuse Guide, [3 11 Zuse, H. Histoory of Sofhvure Measurement, Berlin, 1998 NAVSO P-5234-2, 1995 (htrp://nv-engJulls- church. va.us/ReuseIC/policy/navy/guide95/guide95. him) [13] Devanbu, P.T.,Karstu, S., Melo, W., and Thomas, W. “Analytical and Empirical Evaluation of Software Reuse Metrics”, IEEE Proceedings ofICSE-18, 1996, pp. 189-199 [I41 Devanbu, P.T., Perry, D.E., and Poulin, J.E. Wext Generation Software Reuse”, IEEE Transactions on Sofiare Engineering, v. 26, No. 5,2000, pp. 1-2 [ 151 Fenton, N.E. Sofmare Metrics: A Rigorous Approach, ChapmanWall, 1991 [16] Comes, P. and Bento, C. “A case similarity metric for sohare reuse and design”, Artificial Intelligence for Engineering Design, Analysis and Manufacturing, v. 15, Issue 1,2001, pp. 21 - 35 [ 171 Halstead, M.H. Elements of Software Science, New York, Elsevier, 1977 [ 181 Hefner, R., and Mann, B. “The Evolution of a Software Measurement Program”, Proceedings of the 6’h World Multiconference on Systemics, Cybernetics and Informatics, v. 7, Orlando, Florida, 2002, pp. 307-3 12

214