AJIS vol. 8 no. 2 May 2001 ASSESSING SOFTWARE QUALITY THROUGH VISUALIZED COHESION METRICS Timothy K. Shih* Ming-Chi Lee** Teh-Sheng Huang* Lawrence Y. Deng* *Dept. of Computer Science and Information Engineering Tamkang University Taiwan, R.O C E-mail: e8190070@lkgis.tku.edu.tw **Dept. of Business Administration National PingTung Institute of Commerce Taiwan, R.O.C ABSTRACT Cohesion is one of the most important factors for software quality as well as maintainability, reliability and reusability. Module cohesion is defined as a quality attribute that seeks for measuring the singleness of the purpose of a module. The module of poor quality can be a serious obstacle to the system quality. In order to design a good software quality, software managers and engineers need to introduce cohesion metrics to measure and produce desirable software. A highly cohesion software is thought to be a desirable constructing. In this paper, we propose a function-oriented cohesion metrics based on the analysis of live variables, live span and the visualization of processing element dependency graph. We give six typical cohesion examples to be measured as our experiments and justification. Therefore, a well-defined, well-normalized, well-visualized and well-experimented cohesion metrics is proposed to indicate and thus enhance software cohesion strength. Furthermore, this cohesion metrics can be easily incorporated with software CASE tool to help software engineers to improve software quality. Keywords: Software metrics, Cohesion, Software Quality, Live Variables INTRODUCTION The quantitative measurement of software has been defined as one of the functions of engineering disciplines. The establishment and the use of software measurement still make a great deal of extensive discussion. Software production is often out of control due to the lack of measurement [DeMarco, T. ( 1982)]. Without software metrics, software would be error prone, expensive and with a poor quality. Therefore, suitable software measures are essential for software development. Modularization of software represents a significant software engineering activity, which continues to receive considerable research attention. Module cohesion is defined as a quality attribute, which seeks for measuring the singleness of purpose of a module. Cohesiveness is a measure of an individual module's internal strength, which is the strength of the interrelationship of its internal element [Martin, J. McClure, C. (1983)]. Module cohesion indicates how closely a module's internal components are related to others. Cohesion is a critical assessment of software design quality. A software module with low cohesion will be error prone. Fifty percent of the highly cohesive procedures are fault free, whereas only eighteen percent of procedures with low cohesion are fault free [Fifty_Percent, 1998]. Cohesion is an attribute that can predict properties of implementations such as "ease of debugging, ease of maintenance, and ease of modification" [Yourdon E. and Constantine L.L. (1979)]. Cohesiveness is one of the possible measurements for program modifiability [Stevens, W., Myers, G and Constantine, L. (1974)]. A modifiable program is made up of modules that have high Cohesiveness. Therefore, well-defined and well-proved cohesion measures can support software engineer to design a higher cohesion module and enhance software quality, maintainability and reusability. This implies that the software quality can be improving by maximizing the degree of module cohesion. However, Stevens, Myers and Contantine first define the notion of cohesion (SMC Cohesion), on ordinal order of seven levels that describes the degree of modules. The factors are functional, sequential, communicational, procedural, temporal, logical and coincidental [Stevens, W., Myers, G and Constantine, L. (1974)][Yourdon E. and Constantine L.L. (1979)]. The cohesion strength of a specific procedure is increasing from coincidental to functional. A highly cohesive software module has one basic function and is indivisible [Fenton, N. E. (1991)]. And, the coincidental is the least desirable but \hefunctional is the most desirable cohesion level. In the past decade, a few researchers work on cohesion measures. Biemen's cohesion measures is based on program slicing. A program slice is a portion of program text that affects specified program variables [Bieman, J. M. and Ott, L. M. (1994)]. The program slice based measures depends on data flow and control flow of a procedure [Bieman, J. E. and Kang, B.K. (1998)]. For complex program functionality, the program slicing method can produce slices that are either too large to understand, or too simple but not significant to comprehend [Lucia, A.D and Fasolino, A.R. (1996)]. On the other hand, the mechanism does not consider the global data variables effect and the analyzed scope is not a formal module scope. Lakhotia developed a logical analysis method to investigate cohesion types based on logical analysis [Lakhotia, A. (1993)]. Although, the result of the logical analysis meets the SMC Cohesion levels logically. But, it does not provide numerical system to compute cohesion strength. Ott and Thuss's approach is based on slice profile and processing element flow graph to express four types of module cohesion [Ott, L. M. and Thuss, J. J. (1989)]. But, this approach does not consistent 15 AJIS vol. 8 no. 2 May 2001 with the SMC Cohesion and the Fenton's cohesion spectrum. Also, this method does not express a numerical system how to compute module cohesion. Fortunately, the well-known Henry-Kafura measurement measures the relationship between procedures based information flow [Henry, S. and Kafura, D. (1981)]. But, it fails to measure the cohesion attribute of intra-procedure. Live variables describe the extent of variables to be refereed within a module, while variable span captures the range of variable to be used in a module [Conte, S. D., Dunsmore H. E. and Shen, V.Y. (1986)]. Generally, instance variable is used to derive higher-level inference on cohesion [Metr_dis, 1998]. Module cohesion aims to measure how tight between output processing elements [Ott, L. M. and Thuss, J. J. ( 1989)][Bieman, J. E. and Kang, B.K. (1998)][Bieman, J. M. and Ott, L. M. (1994)]. In this paper, we propose a function-oriented cohesion metrics, which is based on an analysis model of live variable semantics. We examine the function-oriented cohesion metrics (FOCM) for each output function, the most tightest function-oriented cohesion metrics (MTFOCM), the least tightest function-oriented cohesion metrics (LTFOCM), and the average tight function- oriented cohesion metrics (ATFOCM) of a specific procedure. In general, we always strive for a high cohesion. Although the mid-range of the cohesion spectrum is often acceptable [Pressman, R.S. (1988)]. And, a module may exhibit more than one type of cohesion. However, we will show that the proposed metrics do not only closely match SMC Cohesion and Fenton's cohesion strength spectrum [Fenton, N. E. (1991)], but also meet nonlinear cohesion scale of cohesion that was stressed by Pressman and Sommerville in [Pressman, R.S. (1988)][Sommerville, I. (1996)]. The main contributions of this paper are that we propose a formal and visualize analysis model, scientific basis, well-normalized, well- experimented, and well-evaluated function-oriented cohesion measures to improve software quality. The rest of the paper is organized as follows. We address basic works about live variable semantics and formal definitions in section 2. We examine visualized analysis model and the proposed cohesion metrics in section 3. Section 4 gives six typical cohesion procedure examples to make empirical study. To discuss and analysis our experimental results is expressed in section 5. Finally, in section 6, the conclusion and future research are presented and discussed. BASIC WORKS AND DEFINITIONS A module is a contiguous sequence of program statements that are bounded by boundary elements, and has an aggregate identifier [Yourdon E. and Constantino L.L. (1979)]. A module is usually defined as a segment of codes that is compilable independently [Conte, S. D., Dunsmore H. E. and Shen, V.Y. (1986)]. However, many researchers define a module to be a compilation unit of code, a view of program, or a procedure. By functionality, the processing elements in a procedure could be categorized into the following four categories: • Input variable (IV): a set composed of the variables that are the input arguments to a procedure. • Internal variable (INV): a set of local variables of a procedure. • Global variable (GV): a set of global variables. • Output variable (OV): a set of variables that are the output functions of a procedure. In general, variables in an individual module can be in assignment statement, initial statement, decision predicate, output function and iteration constructor, Boolean semantics which could construct the main body of the whole procedure. A module will contain specific function semantics. In practice, it will be the key issue to develop a suitable model to construct the overall reference scenarios of the function in the procedure scope. Live variables of a statement in module are the processing elements that are referenced in the statement. For sake of explaining the concept of live variables, a procedure example is given as follows: 16 AJIS vol. 8 no. 2 May 2001 1 Procedure SumAndProd(N:integer; Var sum; prod:Integer) 2 Var I:Integer 3 Begin 4 sum:=0; 5 prod:=l; 6 For I:=l to N do begin 7 sum:=sum+I; 8 prod:=prod*I; 9 end 10 end Figure 1. A procedure example As SumAndProd listed in Figure 1, sum in line 4 is a live variable. Both / and N are live variables in line 6. On the other hand, sum is only referred at two statements in the procedure. Should software engineers concern sum in other statements other than line 4 and 7? The answer is "yes". However, software engineers constantly have to keep in mind where sum may be referred between statements 4 and 7. Software engineers always realize that in each iteration sum has a different status in the for_loop, sum will be incremented, although the statements do not refer to sum in line 5 and 6. Finally, the summation operation will exit. Similarly, prod has the same scenario like sum. And, Comprehending software artifacts is an important software engineering activities. A significant amount of time of a software engineer is spent in looking at the source code to discover information during testing, review and code inspection [Canfora G and Lakhotia A.(1999)]. We also know a programmer must be aware of the status of a number of data items during the programming process [Conte, S. D., Dunsmore H. E. and Shen, V.Y. (1986)]. Thus, the more data items what a programmer must keep track of when constructing a procedure, the more difficult it is to construct. Based on the above issues, live variables of a statement are not limited to the number of variable reference in that statement. In the past years, there are several possible scopes of live variables to be defined inevitably [Curtis B. ( 1981)][ Conte, S. D., Dunsmore H. E. and Shen, V.Y. (1986)]. The first is the live variable computes from the beginning of a procedure to the end of the procedure. According to this definition, the computation is simple, but this violates the live variable abstract. The second is at a particular statement, only if variable is referenced a contain number of statements before or after that statements. Depend on the second definition, we may calculate lifespan. But there is no agreement on what "certain number of statements" should be and no successful use has been reported [Conte, S. D., Dunsmore H. E. and Shen, V.Y. (1986)]. The third one is from its first reference to its last reference within a procedure. However, the third definition not only meets the principles of live variable abstraction, but can be counted algorithmically as well. We believe that the third is a suitable domain for computing module cohesion. Therefore, we will adopt the third as the definition of live variables in this paper. For precise definition and helping software engineer to understand software easily, we use mathematics to define the live variables and use live span to visualize a live variable scope. Therefore, we denoted the lifespan of a variable to be the reference domain that begins at the first occurrence and extends through the last occurrence. Definition 1: The lifespan of a variable in a procedure is a set, denoted by LS(var_nam). The elements of the set are the name of the variable from the first (/-th line) to the last (/'-th line) referenced, LS(var_nam)={var_nami,var_nami+i ,var_nam^. And, the size of lifespan, | LS(var_«am) | =j-i+\. As an example in Figure 1, we investigate the live span of variable sum. The set LS(sum)={sum4jums,sum6^um?}, with a size of 4. The LS set also represents a mapping from the references of sum to different locations (i.e. lines 4,5,6 and 7). Definition 2: The live variables (LV) of a specific procedure (sp) is the set union of the lifespan of each variables which belongs to IV, INV, GV or OV. We denote LV(sp)= u LS(var_«a/w/) where var_namt e IV u INV u GV u OVandieN. In Figure 1, we could construct LV'(SumAndProd). First, we know the processing elements are IV={W}, OV={sumj>rod},GV=0, and INV={/} respectively. Next, LS(inv)={I6J7J8} where /V/ielVN, LS(ovy={sum4jum!ijum6jum7j>rod}j>rod6j)ord7j)rods} where oveOV, LS(gv)= 0 where gveGV, LS(/v)={A^(S} where we IV. Finally, LV(SumAndProcd)=LS(iv) u LS(ov) u LS(gv) u LS(/nv). For simplicity, we can describe the live variables and live span of the procedure as Figure 2. 17 AJIS vol. 8 no. 2 May 2001 Line 4 5 6 7 8 LV(SumAndProd) sum4 sum5j>rods sum6j}rodgj 6JJ6 sum7j)rod7J7 prodsJs Count 1 2 4 3 2 12 Live Span — SUZtL, prod, I, Figure 2. Live variables and live span of SumAndProd The live span and live variables of Figure 1 are illustrated in Figure 2. For instance, sum is firstly referenced in line 4, the last reference is in line 7. According to Definition 1, the software engineer have to keep the reference of sum from line 4 and line 7, although sum does not appear in statement 5 and statement 6. Therefore, line 4 to line 7 are the live span of variable sum and we use a symbolic "[" to describe the live span of a variable. Together, a live span could clearly be viewed as a visualized scope of live variables in a specific procedure. VISUALIZATION AND COHESION METRICS In this section, we propose function-oriented cohesion measures that are based on the analysis of live variables and live span abstraction. According to the previous section, we know that not all variables involve the computing of output functions in a specific procedure. Logically, a module is the function that processes input, internal and global variables to produce a result. The output functions in OV(sp) are on behalf of the result of the module. In fact, not all elements of live span of a variable contribute a result of the output function of the procedure. For instance, the LS(prod) consists of prod;, prodg, prod-/, and prods, in which no element influences the result of output sum. But bothprods andprodg may involve the value of the output function prod through the assignment statement. As of the result, prods andprodg are the function-oriented live variables of output function prod. Similarly, variables I6, Is, N6 are the function-oriented live variables of prod. Both /,; and Nf may change the value of the output function and compute the multiplication via I8 indirectly. Therefore, function-oriented live variables of prod is a set, denoted {prods, I6, N6, prodg, Is}. Therefore, the FOLV and FOLS of the procedure SumAndProd are shown in Figure 3. However, it is not enough formal that we express function-oriented live variables and live span just rely on the above description. Therefore, firstly we will define direct variable and indirect variable of an output function before giving the definitions of function-oriented live variables. Definition 3. Direct variable of an output function is an element of LV(sp), which may influence the result of the output function in the same statement. For instance, variable I7 contributes the value of the sum7 directly. Thus, I7 is the direct variable of the output function sum7. According to Definition 3, output variable surely is the direct variable by itself. Line 4 5 6 7 8 FOLV '(SumAndProd) sum4 prods I6J*6 sum7J7 prodsjs Count 1 1 2 2 2 8 FOLS — suin^ ^ sum, -prodi rle Nfi rLprod. LI, Figure 3. The FOLV and function-oriented live span of SumAndProd Definition 4. Indirect variable of an output function is an element of LV(sp), which may decide the execution of the output function or perform the result of the output function via direct variables. For instance, variables 16 and N6 of iteration statement in line 6 contribute the value of the sum7 indirectly. So I6 and N6 are the indirect variable of the output function sum7. Definition 5. The function-oriented live variables of an output function in the specific procedure is a set, denotes FOLV(ov,)={/v e LV(.sp) | Iv is direct or indirect variable of ov,; ov,eOV(sp)} Definition 6. The Junction-oriented live span of an output function in the specific procedure is a set, denotes FOLS(ov,)={/v e LS(sp) | Iv is direct or indirect variable of ov,; ov,eOV(sp)} 18 AJIS vol. 8 no. 2 May 2001 According to Definition 5 and 6, the function-oriented live variables and function-oriented live span of sum and prod are depicted in Figure 4. Variables sum I N prod FOLV(swm) sum 4, sum7 16, f 7 N6 5 FOLV(s«ro)nFLOV(proj directly or indirectly. Then, the size of FOLV(ov,) implies the number of live variables in the specific procedure, shall contribute to the result of the output function ov. More precisely speaking, the proportion of |FOLV(ov,)| in |LV(sp)| can be viewed as the cohesion strength which just restricts on ov, in a module. Therefore, the Junction-oriented cohesion measure restricts on ov, is defined as follows: FOCM(ov,)= | FOLV(oVj)| / \LV(sp)\ for each ov, e OV(sp) From the perspective of the cohesion, the common shared function-oriented live variables of sum and prod are the most critical elements. Module cohesion aims to measure how tight between output procession elements. And, the relation levels of output function pairs determine a cohesion level of a module [Bieman, J. E. and Kang, B.K. (1998)]. We define the most light function-oriented cohesion measure of the specific procedure (sp) as follows: MTFOCM(5p)=|nFOLV(ov,)|/|LV(s/>)| for each ov, e OV(sp) In a specific procedure, some elements of live variables really may not involve in influencing the result of output functions. This implies that not all of live variables have function-oriented relation with each ov. Obviously, the live variable VL(sp) excluding the function-oriented live variable FOLV(sp) is a subset of live variables, which is defined as VIXs/?)-FOLV(.sp). Therefore, we define the least tight function-oriented cohesion measurement as: LTFOCM(s/7>= | LV(sp) - u FOLV(ov,)| / \LV(sp)\ for each ov, € OV(sp) However, it is also an important reference point for software measures that the average strength of all live variables involves the results of output functions. We propose the average tight function-oriented cohesion measurement of the specific procedure as follows: ATFOCM(s/>)= | u FOLV(ov,) | / 1 LV(sp) \ for each ov,€ OV(5p) Consequently, We proposed four function-oriented cohesion measures in a specific procedure. The values of the four proposed cohesion measures are in the range between 0 and 1. Therefore, the numerical systems of the function-oriented cohesion measures is a well-normalized cohesion. Practically, it is necessary to express the FOLV using a dependency graph to visualize the function-oriented relationships between processing elements for helping software engineer to easily comprehend the FOLV. Definition 7. The function-oriented live variables dependency graph of an output function ov in a specific procedure is a directed graph, denoted as FOLVDGOV(V,E), where V is a finite set of elements called vertices which consist of FOLV(ov), E is a finite set of elements called edge which is defined as (/v, ov), where /v is direct or indirect variables of ov, oveOV(sp) and /v€FOLV(ov). We use directed arrow with 'id' and 'l) 07 for I:=l to N do begin 08 sum:=sum+ arrl [I]; 09 else 10 forl:=l to N do begin 11 prod:=prod* arr2[I]; 12 end By 0 function -•*• icontrol path Abstract function diagram IN an-2 Information flow diagram Figure 11. A typical logical cohesion implementation definition 1 and definition 2, ={.s«m4,SM/W5,prod5,SM7HsjTO^ iojfioj>rodn,arr2]jj]i }, and \LV(SumAndProd)lf=24, which are diagramed in Figure 12. In other way, we may have FOLV(sum)={sum4Jlag6J[7fl7,sums,arrlgJs}, and |FOLV (sum)\=7, FOLV(prod)={prodsJlag6J<>fl9j)rodi0,arrl10J,0} and |FOLV(pnw/)|=7, and nFOLV(ov)={lv € FOLV(sum) and Iv e TOLV(prod)\ Iv e LV}={flag7} and |nFOLV(ov)|=l, and they are shown in Figure 13. In Figure 14, the FOLV of sum, prod and their intersection are illustrated. FOLDGs of output functions and logical cohesion example are illustrated in Figure 15. Line 4 5 6 7 8 9 10 11 LV(SumAndProd) sum4 sum^prods sum6.prod6Jlags sum7j>rod7J7JV7 sum nrod arrl J JVosf7 Oi o**or o prodg, I9JJ9 prodioJtQjNiQ prod,,,arr2nj[ll Count 1 2 3 4 5 3 3 3 LS ^SUITl4 sum2 sum. sum7 ^sume -prodj prode flage prod, prods prod. prod,0 Lprodn -I, K, Ia arrl 8 N8 I» N, I,o NIO _ I,, arr2u 24 | Figure 12. The LV and LS of a logical cohesion example Line 5 6 7 8 9 10 11 12 ?OLV(SumAndProd) sum 4 prod} Flag6 I7JJ7 sum8,arrl8j8 linJfm prod,harr2,,J,1 Count 1 1 1 2 3 0 2 3 FOLS -sum^ -sume _prod3 fl«8« _prod,, -I, N, IB arrla ilo ISTIO -I,, arrZ,, 13 Figure 13. The FOLV and FOLS of a logical cohesion example 22 AJIS vol. 8 no. 2 May 2001 Variables Sum I N Flag Arrl Arr2 Prod FOLV(sum) sum^umg hJg N7 flag6 arris 1 FOLV(Sum)nFOLV(Prod) fag6 1 FOLV(prod) I io> In NIO flag6 arr2,i prods, prod a 7 Figure 14. The FOLV of sum, prod and their intersection prods id /^l10 arr2. Figure 15. The FOLVDGs of output functions and logical cohesion example According to the definitions of function-oriented cohesion measures, the values of function-oriented cohesion measures of logical cohesion example are given as follows: FOCM(sum)=\ fOLV(sum) | / 1 LV(SumAndProd) (=0-29 FOCM(prorf)= | FOLV(prod) | / 1 LV(SumAndProd) |=0.29 MTFOCM(SumAndProd)=\r£OLV(ov) | / 1 LV(SumAndProd) |=0.041 LTFOCM(SumAndProd)=\LV - uFOLV(ov)| / 1 LV(SumAndProd) |=0.46 ATFOCM(SumAndProd)=\uFOLV(ov) | / 1 LV(SumAndProd) |=0.64 In this example, there are some common elements that are used to decide which function to be requested logically. The value of MTFOCM of the logical cohesion is equal to 0.041. From the viewpoint of cohesion strength, this logical cohesion is just little stronger than coincidental cohesion. However, the logical cohesion is still a low-end cohesion. Procedural cohesion is to evaluate whether the module that performs more than one function, and whether the module is related to a general procedural effected by the software [Fenton, N. E. (1991)]. This means that if each function in the module needs to execute following a specific order, then it has the strong procedure cohesion. Explicitly, Both functions are elements of some iteration or decision operations [Lakhotia, A. (1993)]. In the procedural cohesion example, the module performs a series of functions related by a sequence of steps. In other words, a module consists of functions related to the procedural processes in a repetition or selection constructs. However, A \ypica\procedural cohesion example and its abstract function diagram are given as follows: 01 Procedure SumAndProd(N: integer; var sum, prod: integer;arrl,arr2:int_array); 02 var I: integer; 03 begin 04 sum:=0; 05 prod:=l; 06 forl:=l toNdo 07 sum:=sum+arrl[I]; 08 prod:=prod*arr2[I]; 09 end modik arl I N m2 Insamereptionor condition construct, without same inputs By Figure 16. A typical procedural cohesion implementation definition 1 and definition 2, we know \LV(SumAndProd)\=\4. We express LV and LS of the procedural cohesion example in Figure 17. And, we may have FOLV(sum)={sumrods,arr2sJg} with size of 6, and nFOLV(ov)={lv e FOLV(sum) and Iv e FOLV(prod)\ Iv e LV }={I6M with size of 2, and it's 23 AJIS vol. 8 no. 2 May 2001 visualized FOLS is displayed in Figure 18. In Figure 19, the FOLV of sum, prod and their intersection are presented. FOLDGs of output functions and logical cohesion example are shown in Figure 20. Line 4 5 6 7 8 LV(SumAndProd) sum4 sumsj3rod5 sumsjjrodfjf ^ sum 7,prod7,arrl 7/7 prods,arr28j8 Count 1 2 4 4 3 14 LS r-sum, sum5 "-sum? r-prods prod? I7 arr!7 prodg Ig 3rr2g Figure 17. The LV and LS of z procedural cohesion example Line 4 5 6 7 8 FOLV(SumAndProd) SUW4 prods I6^6 sum 7 cirri jJ-j7) 7t 7 prods,arr28Js Count 1 1 2 3 3 10 FOLS -sum,, -sum-. I— pnods [ I* N« J, arr!7 ^i-_'^*B IQ ax*r2g Figure 18. The FOLV and FOLS of a procedural cohesion example Variables sum I N arrl arr2 prod FOLV(sum) sum4,sum7 I6J6 N6 arr!7 6 FOLV(5ww) nFOLV(PraJ) /6 Nt 2 FOLV(pmd) 1rods,arrlgJs} and \lM(SumAndProd)^=l4, which are depicted in Figure 22. Again, fOLV(sum)={sum4J6^/6^um7,arrl7J7} with size of 6, ¥OLV(prodJ={prodsJ6^!6j)roda,arrlgJg} with size of 6 and nFOLV(ov)={lv e FOLV(sum) and Iv € ¥OLV(prod)\ Iv € LV}={I6Jf6} with size of 2, and it's visualized FOLS is sketched in Figure 23. In Figure 24, the FOLV of sum, prod and their intersection are illustrated. FOLDGs of output functions and logical cohesion example are shown in Figure 25. Line 4 5 6 7 8 LV(SumAndProd) sum4 sum;jjrod} sum6j)rod6J6 J/6 sum 7j)rod7,arrl 7J7 prod8,atrlgjg Count 1 2 4 4 3 14 LS -sum* sums sum^ *— sum? |-prods prode ,- I6 Ntf prod, I7 |-arrl7 -prodg *-IB Larrie Figure 22. The LV and LS of a communicational cohesion example Line 4 5 6 7 8 ¥OLV(SumAndProd) sum 4 prods sum7,arrl7J7 prod8,arrlgjs Count 0 1 2 0 3 6 FOLS -sum* I, r-arrl, -prod,, L- ia l_ arrl 3 Figure 23. The FOLV and FOLS of communicational cohesion example Variables sum I N arrl prod FOLV(swm) sum^um7 I 6^7 N6 arr!7 6 POLV(Sum)rfOLV(Prod) h N6 2 FOLV(prod) ItJg N6 arrlK prod5j>rodg 6 Figure 24. The FOLV of sum, prod and their intersection 25 AJIS vol. 8 no. 2 May 2001 prod5 Figure 25. The FOLVDGs of output functions and communicational cohesion example However, the values of function-oriented cohesion measures of coincidental cohesion example can be presented as follows: FOCM(s«m)=| FOLVCswm) | / 1 LV(SumAndProd) |=0.428 ¥OCM(prod)=\ FOLV(prod) \ I \ LV(SumAndProd) |=0.428 MTFOCM(SumAndProd)=\nFOLV(ov)\ I \ LV(SumAndProd) |=0.142 LTFOCM(SumAndProd)=\LV - uFOLV(ov)| / 1 LV(SumAndProd) |=0.288 AV?OCM(SumAndProd)=\v?OLV(ov)\ I \ LV(SumAndProd) |=0.712 In this example, a number of elements are involved in different activities, but the activities are sequential. The value of MTFOCM of communicational cohesion is equal to 0.142. The value seems to be the same as procedural cohesion. We have communicational cohesion, which is not significant stronger cohesion strength than procedural cohesion. Sequential cohesion is to estimate whether the module performs more than one function. Function dependency occurs in an order, which is described in the specification [Fenton, N. E. (1991)]. Generally, the output data from a function is the input for the next function in a module. In the sequential cohesion example, the module performs a series of functions related to I/O data. In other words, the functions of a module are related to perform different parts of a sequence of operations,_where the output of one function is the input to the next. However, a typical sequential cohesion example and its abstract function diagram are given as follows: 01 Procedure SumAndProd(N:integer; var sum, prod: integer;arr:int_array); 02 var I: integer; 03 begin 04 sum:=0; 05 prod:=l; module 06 forl:=l to N do begin 07 sum:=sum+arr[I]; 08 prod:=prod*sum; 09 end function / N Abstract function diagram Information flow diagram Figure 26. A typical sequential cohesion implementation By the definition of live variables and function oriented live variables, we have UJ(SumAndProd)= {sum4,sumsj>rod5jsum6j>rod6J6.Ff6jum 7j>rod7,arr7J7j)rods,sums} and $Jf(SumAndProd)\=\2i, We express LV and LS of the sequential cohesion example in Figure 27. ¥OlN(sum)={sum4J6fl6,sum7,arr7J7} with size of 6, ?G\JJ(prod)={sum4j)rod5J6JJ6,sum7J7j)rods£um8} with size of 9 and nFOLV(ov)={lv e ¥OIX(prod) and Iv e FOLV(prod)| lv e LV }={sum4J6Jf6,sum7,arr7J7} and | nFOLV(ov)|=6, and their visualized FOLS are depicted in Figure 28. In Figure 29, the FOLV of sum, prod and their intersection are illustrated. FOLDGs of output functions and logical cohesion example are detailed in Figure 30. 26 AJIS vol. 8 no. 2 May 2001 Line 4 5 6 7 8 LV(SumAndProd) sum., sum^jjrodj sum6j>rod6J6JJ6 sum7j)rod7,arr7J7 prodgjumg Count 1 2 4 4 2 13 LS r- sum, sum3 sums Sum, -sumg rprod3 prods rl« Ne prod, Ll7 arr, uprodg Figure 27. The LV and LS of a sequential cohesion example Line 4 5 6 7 8 FOLV(SumAndProd) sum4 prod) I6yN6 sum7,arr7J? prodgjumg Count 1 1 2 3 2 9 FOLS - sum* sum, - sum. r-prod3 If Ng Li, arr, Lprod. Figure 28. The LV and LS of sequential cohesion example Variables sum I N arr prod FOLV(sum) sum4^um7 I6J7 N6 arr7 6 FOLV(Sum)rtfOLV(Prod) sum^um7 I6Ji N6 arr7 6 FOLV(prod) sum4,sum7^umg ItJj N6 Arr7 prodsj)rods 9 Figure 29. The FOLV of sum, prod and their intersection surn, sum, prodj sumg Figure 30. The FOLVDG of output functions and sequential cohesion example FOCM(sum)=\ FOLV(sum) \ I \ LV(SumAndProd) (=0.46 FOCM(prod)=\ FOLV(prod) \ I \ LV(SumAndProd) (=0.69 MTFOCM(SumAndProd)=\nFOLV(ov)\ I \ LV(SumAndProd) |=0.46 LTFOCM(SumAndProd)=\LV - uFOLV(ov)| / 1 LV(SumAndProd) (=0.31 AVFOCM(SumAndProd)=\uFOLV(ov)\ I \ LV(SumAndProd) |=0.69 In this example, some elements involved in different activities. But the activities are sequential. The value of MTFOCM of the sequential cohesion is equal to 0.46. The values show that sequential cohesion is a little stronger than communicational cohesion. Functional cohesion is to check whether the module performs on a single function [Fenton, N. E. (1991)]. The module is the one on which all of the elements contribute to exactly one function. In the functional cohesion example, the module achieves exactly one goal. However, a typical functional cohesion example and its abstract function diagram are given as follows: 27 AJIS vol. 8 no. 2 May 2001 01 procedure Sum(N:integer; var sum: integer; arr:int_array); 02 var I : integer; 03 begin 04 sum:=0; 05 for I:=l to N do begin 06 sum—sum + arr[I]; 07 end faction I N an- Figure 31. A typical functional cohesion implementation Rely on definition 1 and definition 2, It is easy to know that UV(sum)={sum4,sumsJ5J^6^um6,arrgJ6} with size of 7 and ~FOlN(sum)={sum4jiJ^5^um6,arr6J6} with size of 6. Their visualized LS and FOLS are developed in Figure 32 and Figure 33 respectively. However, there is a single output function in the functional cohesion implementation. The live variables, live span, function-oriented live variables and function-oriented live span of the output function is the behalf of the functional cohesion. In Figure 34, the FOLV of the single output function sum are depicted. FOLDGs of functional cohesion example are diagramed in Figure 35. Line 4 5 6 UJ(SumAndProd) sum6,arr6J6 Count 1 3 3 7 LS t sum-5 r~Is ISTj sum e Ll^ arrc Figure 32 The LV of a functional cohesion Line 4 5 6 FOLV(SumAndPmd) sum4 IsM sum6,arr6J6 Count 1 2 3 6 FOLS -sum,. ri, N, - swne L I» arr6 Figure 33. The FOLV of functional cohesion Variables sum I N arr FOLV(sum) sum./, sum6 Wt N5 arr6 6 Figure 34. The FOLV of an output function sum 28 AJIS vol. 8 no. 2 May 2001 sum4 Figure 35. The FOLVDGs of output function and functional cohesion However, the values of function-oriented cohesion measures of functional cohesion example are given as follows: FOCM(s«ro)=| FOLV(sum) | / 1 LV(sum) |=0.86 MTFOCM(sw/n)=|nFOLV(ov)| / 1 LV(sum) |= 0.86 LTFOCM(s«ro)=|LV(sMm) - uFOLV(ov)) / 1 LV(sum) (=0.143 ATFOCM(sMm)=|uFOLV(ov)|/1 LV(sum) |=0.857 In this example, all elements involved in a single activity. The value of MTFOCM of ihe functional cohesion is 0.86. Functional cohesion is a stronger cohesion strength than sequential cohesion. The Functional cohesion is the highest cohesion level. DISCUSSIONS AND RESULTS Cohesion of a module measures the strength of the relationship between the elements within the module: good modules should be highly bound [Modularity (1999)]. Cohesion can be evaluated on a one-dimensional scale [Stevens, W.P. ( 1981)][ Fenton, N. E. (1991)]. A scale of several points can identify different types of cohesion and giving their associated strength [Modularity (1999)]. According to SMC Cohesion level and Fenton's cohesion spectrum, we know that the cohesion strength spectrum can be illustrated as follows: In the previous section, we know the values of the cohesion of all experiments are in [0,1]. This also implies that the proposed cohesion measures are well-normalized. In particular, the values of MTFOCM on the six typical cohesion examples from coincidental to functional are increasing between 0 and 1. In the other words, the cohesion strength of coincidental is the weakest type, but the functional cohesion strength is the strongest type. According to coincidental temporal cornrnuracational functional logical \ procedural Bad Good Figure 36. Cohesion strength spectrum the above experiments, it is not significant difference that the cohesion strengths of procedure cohesion and communication cohesion. More importantly, MTFOCM does match the SMC Cohesion and Fenton's cohesion strength spectrum. The quantitative values of the MTFOCM experiments the levels of cohesion are sketched in Figure 37. 29 AJIS vol. 8 no. 2 May 2001 I07 .Z! ~*1> H2 Figure 37. The non-linear curve of cohesion levels Strictly speaking, coincidental cohesion performs completely unrelated actions, which is the worst level of cohesion. In other words, a coincidental cohesion is an undesirable type of cohesion. Logical cohesion performs function dynamically, which relies on other module calling by passing input arguments. The strength of logical cohesion is a little more than coincidental cohesion. So logical cohesion is still a lower level cohesion. Procedural cohesion is also better than coincidental and logical cohesion because the procedural has more than one function being performed, which is related to one another in order to achieve the goal. But this type of cohesion is still on the lower level of cohesion. In our experiments, the cohesion strength of communication cohesion is not remarkable distinction to procedural cohesion. The cohesion strength of sequential cohesion is better than communicational cohesion because the output from one function is the input to the other functions, which is medium cohesion strength. Functional cohesion performs exactly one action, which is a high-end cohesion. In other words, it is the most desirable type of cohesion. However, the curve of the quantitative values of MTFCOM in Figure 37 shows that low-end cohesiveness is more worsen than middle-range. The value of MTFOCM of logical cohesion is just 0.041. From coincidental to logical cohesion, the cohesion strength is increasing very slowly. As a result, the difference of cohesion strength between coincidental cohesion and logical cohesion is not too significant. This implies that both coincidental and logical cohesions may be undesirable cohesion levels. The value of MTFOCM of procedural or communication cohesion is 0.142. And, the curve of cohesion strength rises slowly from logical type to procedural or communication type. This means that those procedural and communication cohesion are low-end cohesion types. The value of MTFOCM of sequential cohesion is 27.9% (more than communication). The curve of cohesion strength climbs up sharply at a turn around point of procedural or communication cohesion. This means that sequential cohesion is a high-end cohesion type. The value of MTFOCM of functional cohesion is 27.4% more than sequential. The cohesion strength soars from sequential to functional. Therefore, the functional cohesion should be a desirable cohesion type. Furthermore, The nonlinear scale from coincidental cohesion to functional cohesion consists with the assertions of Pressman and Somerville in their software engineering articles. According to the empirical experiments, the proposed cohesion measures have some paradigmatic characteristics which are: (l)MTFOCM(sp)