The Relationship between Slices and Module Cohesion

The Relationship between Slices and Module Cohesion Linda M. Ott Jeffrey J. Thuss Department of Computer Science Michigan Technological University Houghton, MI 49931 Abstract High module cohesion is often suggested as a desirable property of program modularity. The subjective nature of the definition of cohesion, however, can make it difficult to use in practice. In this paper, we examine the relationship between the data flow in a module and its level of cohesion using a processing element flow graph (PFG). Based on these PFG s, we regroup the original seven levels of cohesion into four classifications. Slice profiles are then defined by generating slices for all output variables of a module. A relationship is then shown between these slice profiles and the PFG used to indicate levels of cohesion. It is suggested that these slice profiles can be used to determine more easily the cohesiveness of a module. 1. Introduction The psychological complexity of software is a measure of how difficult it is for programmers to interact with the software [6]. It is intended to reflect how well the software is written in terms of understandability, testability, and maintainability. These concepts have been identified by Boehm [1] as essential in the development of high quality software. The decomposition of a system into modules can significantly reduce psychological complexity. Myers [10] states that "modularity is the single attribute of software that allows a program to be intellectually manageable." Studies have been completed which indicate that size is a major factor in software complexity [4, 5, 8]. Modularity offers a rational solution by breaking up large problems into several smaller, more manageable pieces. Constantine and Yourdon [3] have identified two qualitative properties of effective modularization, one of which is cohesion. Cohesion is often referred to as "module strength," "binding," or "functionality." The highest degree of cohesion is obtained in a module which performs exactly one task. Cohesion, as defined, is a subjective measure requiring an interpretation of the informal definitions provided by Constantine and Yourdon. Several attempts have been made to make this subjective concept more precise. These include the suggested use of a decision tree as proposed by Page-Jones [11] and attempts to find quantitative cohesion metrics [7, 9]. The aim of this paper is to show that the degree of cohesiveness of a module can be seen by examining slices [13-15] generated from the output variables of the module. In section 2, we will discuss cohesion and provide a simplification of the metric based on examining the relationships among the processing elements of the module using a processing element flow graph (PFG). Section 3 contains a brief description of slicing and presents a slice profile. In section 4, example slice profiles are examined to show how they can indicate the relationship among the processing elements of the module and, hence, the cohesiveness of the module. Finally, in section 5, we discuss further implications of this relationship. Current address: Autotrol Technology, 12500 Washington St., Denver, CO 80233

2. Cohesion Constantine and Yourdon [3] have identified seven levels of modular cohesion. It is proposed as a subjective measure of the "intramodular functional relatedness" of a software module. A module is viewed as a collection of processing elements which act together to compute the outputs of the module. Cohesion reflects the functionality of a module by measuring the degree of relatedness among the processing elements within the module. Modules with low cohesion consist of two or more unrelated processing elements. High cohesion modules consist of a single processing element or a collection of highly related elements. The seven levels of cohesion as originally defined are functional, sequential, communicational, procedural, temporal, logical and coincidental. In practice, this degree of discrimination is not necessary. For the purposes of this study, we regrouped the seven categories into four levels of cohesion based on similarities seen when using processing element flow graphs [12]. (Others, e.g., Emerson [7] and Card [2] have used three levels of discrimination in their work.) Nodes in a processing element flow graph (PFG) represent the processing elements within a module. Solid edges indicate data flow relationships among the processing elements. Control relationships among the elements are not indicated, but they can have an effect on how the graphs are constructed. An example of this effect is discussed in Section 2.2. Two special nodes, labeled Inputs and Outputs, represent the set of input variables used by the module and the set of output variables computed by the module, respectively. These graphs are used to identify processing element relationships typical of modules with the four cohesion classes described below. 2.1. Low : Coincidental and Temporal The low cohesion class consists of modules exhibiting two of the lowest cohesion levels defined by Constantine and Yourdon. Coincidental and temporal modules are associated with PFGs which have two or more distinct processing elements as in Figure 1. Each node in the graph corresponds to the processing elements computing the module s outputs. The edges in the graph indicate that there are no data relationships among the processing elements within the module other than the possibility of a common dependence on a subset of the input variables. Inputs F G H Outputs Figure 1. PFG for a module with low cohesion. Nodes F, G, and H, represent three distinct unrelated processing elements indicating separate data paths through the module. The elements in modules with coincidental cohesion tend to operate on different data yielding separate data flows for each element. Modules with temporal cohesion are not discernible from modules with coincidental cohesion since the time relationship cannot be determined by examining data and control flow. Temporal modules tend to exhibit data flow patterns similar to coincidental modules. 2.2. Control Cohesion: Logical and Procedural The second cohesion discrimination level is called control cohesion. It is associated with Constantine and Yourdon s logical and procedural cohesion levels. PFGs for these modules tend to be highly diversified and difficult to represent with a simple picture. The PFG in Figure 2 serves as an example. The graph represents alternate definitions of two variables under the control of a common if-then-else structure. The symbols F1 and F2 are used to represent the processing elements corresponding to the alternate definitions for the variable F. Similarly, G1 and G2 represent processing elements for the variable G. The

if and else blocks are of a low cohesion level since they each contain two unrelated processing elements computing F and G. The effect of the control structure is shown in the graph by the presence of four processing element nodes instead of two. Inputs F1 G1 F2 G2 Outputs Figure 2. PFG for a module with control cohesion. F1 and G1 correspond to processing elements contained within the if block of an enclosing if-then-else structure. F2 and G2 correspond to elements contained within the else block. Control cohesion is assumed to be present when the only processing element relationship is a result of common enclosing control structures. Control bindings among processing elements are considered to be much weaker than data bindings. In modules with higher cohesion levels, however, the control and data bindings become interrelated. 2.3. Data Cohesion: Communicational The third discrimination level is called data cohesion. Communicationally cohesive modules are typified as having a common data relationship among several processing elements in the module. For example, consider the PFG for a module with input-sided communicational data flow in Figure 3. This PFG contains two processing elements computing values F and G that are related by the fact that they are required to generate another value H. In this case, the common data relationship is in the computation for H, which binds the data flow patterns together and increases the cohesiveness of the module. Inputs F G H Outputs Figure 3. PFG for a module with input-sided communicational data flow among its processing elements. The nodes labeled F and G correspond to processing elements which compute values to be used by the element labeled H. Similarly, the processing elements for modules exhibiting output-sided communicational data flow are bound together by a common element that is produced by the inputs. The result of this common element is then used to generate two or more outputs. The PFG of Figure 4 is typical of a module with output-sided communicational data flow.

Inputs F G H Outputs Figure 4. PFG for a module with output-sided communicational data flow among its elements. Node F corresponds to a processing element which computes a value required by the elements labeled G and H. Modules with both types of communicational data flow have a similar amount of cohesiveness among their processing elements. The input-sided PFG contains two distinct data paths consisting of the elements F-H and G-H. The output-sided graph has similar paths consisting of elements F-G and F-H. This similarity in data relationships suggests classifying modules with both of these communicational flow types as having data cohesion. 2.4. High Cohesion: Sequential and Functional The high cohesion discrimination level consists of the sequential and functional levels of Constantine and Yourdon. Modules exhibiting sequential cohesion also have sequential data flow graphs. Figure 5 shows a PFG for a module with sequential cohesion. Each processing element in the PFG computes an output that is then used by the next processing element in the chain. Modules with high cohesion tend to be very independent. Processing elements in sequential modules are highly interrelated due to their strong data dependencies. Functional modules typically compute a single output represented by a single processing element. Inputs F G Outputs Figure 5. PFG for a module with high cohesion. Nodes F and G represent a chain of processing elements typical in a module with sequential data flow.

3. Program Slicing Slicing is a method of program reduction introduced by Weiser [13-15]. Starting from a subset of a program s behavior, called a slicing criterion, the slicing process results in a minimal form program that reflects the same subset of the program s behavior. Slices have been proposed as potential debugging tools and program understanding aids. 3.1. The Definition of a Slice Weiser s formal definition of a slice as presented in [13] is based on a program flow graph and state trajectories defined by the slicing criterion. The definitions below restrict slices to a single module and are based on definitions given in Longworth s thesis [9]. The symbol M is used to indicate an arbitrary module, e.g., a procedure, function, or main program. Definition 1. Definition 2. A slicing criterion is a tuple < i, V >, where i denotes a specific statement number in a module M and V is a subset of the variables in M. An intraprocedural slice S of a module M on a slicing criterion C is any executable module with the following properties. i. S can be obtained from M by deleting zero or more statements from M. ii. For any given input, the execution behavior at all points in the slice S is the same as would be observed in the module M with respect to the variables in V at statement i. As an example, consider the module in Figure 6. There are two distinct tasks performed by the module (the computations for the sum and for the product of the first N integers.) The only relationships between the two tasks are the common input value for N and the control structure used to compute the sum and product. This module clearly falls into the category of control cohesion as described in the previous section. 1 procedure SumAndProduct( N : integer; 2 var SumN : integer; 3 var ProdN : integer ); 4 var 5 I : integer; 6 begin 7 SumN := 0; 8 ProdN := 1; 9 for I := 1 to N do begin 10 SumN := SumN + I; 11 ProdN := ProdN * I 12 end 13 Figure 6. A module that computes two functions, the sum and the product of the first N integers. The module in Figure 7 was obtained with slicing criterion C = < 13, {SumN}>. Statements 8 and 11 have been deleted since they have no effect on the value computed for SumN. Note that the slice obtained is a module that computes a single function, the sum of the first N integers. A similar slice for the product function can be obtained using the criterion C = < 13, {ProdN}>.

1 procedure SumAndProduct( N : integer; 2 var SumN : integer; 3 var ProdN : integer ); 4 var 5 I : integer; 6 begin 7 SumN := 0; 9 for I := 1 to N do begin 10 SumN := SumN + I; 12 end 13 Figure 7. Slice of SumAndProduct obtained with slicing criterion C = < 13, {SumN}>. 3.2. Slice Profiles A slice profile is a convenient representation for revealing slice patterns within a module. They are based on figures used by Longworth [9] to identify the relationship between slices and data flow. As an example, the slice profile for procedure SumAndProduct is given in Figure 8. The "Line" column contains the line number of each statement in the module. Each column with a variable name as the heading in the slice profile corresponds to the slice associated with that variable. All rows in the profile marked with a vertical bar " " are statements included in a slice for a particular variable, otherwise the row is blank. The "Statement" column contains the source statement. For example, the column with heading SumN in Figure 8 corresponds to the slice for the variable SumN. The slice for SumN consists of all statements containing a vertical bar in the column for SumN, i.e., statements 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, and 13. Line SumN ProdN Statement 1 procedure SumAndProduct( N : integer; 2 var SumN : integer; 3 var ProdN : integer ); 4 var 5 I : integer; 6 begin 7 SumN := 0; 8 ProdN := 1; 9 for I := 1 to N do begin 10 SumN := SumN + I; 11 ProdN := ProdN * I 12 end 13 Figure 8. Slice profile for SumAndProduct. Statements included in the slice for C = <13, {SumN}> are indicated with a " " in the column labeled SumN of the profile. The slice for C = <13, {ProdN}> is indicated in the column labeled ProdN. 3.3. Slicing Criteria The selection of suitable slicing criteria is necessary in obtaining an appropriate set of slices for examining the cohesiveness of a module. The following definition is for the sets of slices which will be considered in this paper. Definition 3. SL outputs is the set of all slices obtained with the criterion C = < M, {v}>, where v is any variable defined by M such that one of the following holds for v.

i. v is a reference parameter (or any variable which retains its assigned value after the module has completed execution). ii. If M is the main program module, v is any data object passed to the module by the operating system, e.g., the standard output file. The definition of SL outputs is based on the assumption that the purpose of any module is to compute one or more outputs. The slice of any output variable will consist of statements contained in processing elements involved in the computation of that output. If slices are obtained for all of the module s outputs, their union will completely encompass the module (unless it contains unused or "dead" code). This union of slices should also encompass all of the processing elements in the module. 3.4. Statement Inclusion Criteria Another factor to consider is the types of statements to include in a slice. Weiser s slices include in addition to executable statements both declaration statements and the begin/ends of compound statements. This is desirable if the slices are to be used for debugging or for obtaining executable slices. Eliminating these statements can simplify the problem when using slices to identify cohesiveness. Type definition and declaration statements have no apparent effect on processing element relationships. Begins and ends do not constitute separate statements, but serve as grouping symbols for the statements contained within a compound statement. Inclusion of these statements can significantly increase the size of the slice intersection when no real overlap exists between the slices. We, therefore, consider the following definition. Definition 4. Variable-referent executable statements (VRES) include all executable statements which reference a variable. VRES were defined by Emerson [7], and his cohesion metric is based on the use of these statements. Since we are concerned with using slices to identify the processing elements within a module, VRES will be used in the remainder of this paper. Figure 9 contains a profile for the SumAndProduct module using only VRES in the slices. Line SumN ProdN Statement procedure SumAndProduct( N : integer; var SumN : integer; var ProdN : integer ); var I : integer; begin 1 SumN := 0; 2 ProdN := 1; 3 for I := 1 to N do begin 4 SumN := SumN + I; 5 ProdN := ProdN * I end Figure 9. Slice profile for SumAndProduct. Only VRES are included in the slices. 4. Slice Patterns and Processing Element Relationship In this section, we will examine several examples of slice profiles and show how they indicate the relationships among the processing elements in the module. As the first example, the module in Figure 10 exhibits low cohesion since it consists of three distinct processing elements which correspond to the three module outputs, SumN, SumSqrN, and ProdN. There is no relationship among the elements. The slices of the output variables partition the module into three disjoint subsets of the set of all the module s VRES

statements as shown in the figure. In this case, it is clear that the partition imposed by the slices has isolated the three processing elements. There are no control or data relationships among the processing elements. This lack of processing element relationship is reflected by the three non-intersecting slices in the profile for the module. Line SumN SumSqrN ProdN Statement procedure SumAndProduct1( N : integer; var SumN : integer; var SumSqrN : integer; var ProdN : integer ); var I : integer; begin 1 SumN := 0; 2 for I := 1 to N do 3 SumN := SumN + I; 4 SumSqrN := 0; 5 for I := 1 to N do 6 SumSqrN := SumSqrN + I*I; 7 ProdN := 1; 8 for I := 1 to N do 9 ProdN := ProdN * I Figure 10. Slice profile for SumAndProduct1. Figure 11 contains a variation of the module in Figure 10. In SumAndProduct2, the computation of the outputs is enclosed in a for-loop structure. The common control structure is the only binding force that has been gained among the processing elements in this version of the module. Since this is the only relationship among the processing elements, the module exhibits control cohesion. This is reflected in the slice profile by determining the intersection of all of the slices which results in the for statement at line 4. If this statement is removed from each slice, the resulting set of slices again partitions the module into its three unrelated processing elements. Line SumN SumSqrN ProdN Statement var I : integer; begin 1 SumN := 0; procedure SumAndProduct2( N : integer; var SumN : integer; var SumSqrN : integer; var ProdN : integer ); 2 SumSqrN := 0; 3 ProdN := 1; 4 for I := 1 to N do begin 5 SumN := SumN + I; 6 SumSqrN := SumSqrN + I*I; 7 ProdN := ProdN * I end Figure 11. Slice profile for SumAndProduct2.

A slice profile for procedure ProcessArray is shown in Figure 12. This module consists of three processing elements computing the output variables X, SumX, and SumSqrX. The module first computes values for the array X. The array values are then used by the processing elements computing SumX and SumSqrX. This implies a data dependency for these processing elements on the element computing the X array. There is no other relationship between the elements computing SumX and SumSqrX. The module, therefore, falls into the data cohesion category. The data dependency is indicated in the slice profile by the intersection of all the slices at statements 1 through 4. The intersection contains data definitions (statements 2 and 4) which are required by the processing elements computing SumX and SumSqrX. A separation of the elements computing SumX and SumSqrX is indicated in the profile by the disjoint subsets of the slices at statements 5 through 7 and 8 through 10. Note that the module exhibits output-sided communicational data flow. The common "input" is the array X, which is used to compute both of the outputs, SumX and SumSqrX. The PFG shown in Figure 4 is identical to the PFG for ProcessArray, where F, G, and H, in the figure, correspond to processing elements computing the variables X, SumX, and SumSqrX, respectively. Modules exhibiting communicational data flow are classified as having data cohesion. Line X SumX SumSqrX Statement procedure ProcessArray( N : integer; var X : IntVector; var SumX : integer ); var SumSqrX : integer ); var I, J : integer; begin 1 for I := 1 to N do begin 2 X[I] = 0; 3 for J := 1 to I do 4 X[I] := X[I] + J 5 SumX := 0; 6 for I := 1 to N do 7 SumX := SumX + X[I]; 8 SumSqrX := 0; 9 for I := 1 to N do 10 SumSqrX := SumSqrX + X[I]*X[I] Figure 12. Slice profile for ProcessArray. A profile for module FindLargest is shown in Figure 13. This module consists of two processing elements computing the positions of the largest (Max) and second largest (NextMax) elements in the array X. The processing elements are highly interrelated due to the strong dependency of NextMax on the value of Max. The dependency is sequential in nature since any assignments of NextMax are made after Max has been determined. This places FindLargest in the high cohesion level. The high processing element relationship is indicated in the profile by the amount of overlap between the slices. In particular, the slice for Max is entirely contained within the slice for NextMax.

Line Max NextMax Statement procedure FindLargest( A : RealVector; N : integer; var Max : integer; var NextMax : integer ); var I : integer; begin 1 if (A[1] >= A[2]) then begin 2 Max := 1; 3 NextMax := 2 end else begin 4 Max := 2; 5 NextMax := 1 6 I := 3; 7 while (I <= N) do begin 8 if (A[I] >= A[Max]) then begin 9 NextMax := Max; 10 Max := I end else 11 if (A[I] > A[NextMax]) then 12 NextMax := I; 13 I := I + 1 end Figure 13. Slice profile for FindLargest. 5. Conclusion The observations made in the previous section on the relationship between slice patterns and processing element relationships, are summarized below. Observation 1. Observation 2. The partition of a module induced by the slice of an output variable consists of the union of the statements from all the processing elements in the module which can affect the final value computed for the sliced variable. The intersection of two or more slices is a subset of the module s processing elements. Observation 3. Slice intersections indicate processing element relationships. If the intersection of slices contains primarily control statements and definitions for the control variables, the processing elements tend to exhibit control cohesion. If the intersection of slices contains non-control variable data definitions, the processing elements tend to exhibit data cohesion. SumAndProduct1 serves as an example of the first observation. In this case, the slices clearly partition the module into its three distinct processing elements. SumAndProduct2 is an example of the third observation since the slice intersection contains only a control statement. The third observation can also be seen in the ProcessArray module since the slice intersection contains data definitions for the X array. This intersection is common to the slices for SumX and SumSqrX indicating a data dependency in the processing elements for SumX and SumSqrX on the element computing X. Finally, the second observation can be seen in ProcessArray since the slice for X is completely contained within the intersection of all the slices. Therefore, the slice for X is the processing element which computes X.

In this paper, we attempted to show that a relationship exists between the slice profile of a module and the cohesion of the module. Slice profiles can be automatically generated easily (see [12]) and therefore could be used as a tool for detecting modules with inappropriately low cohesion levels. This could be useful during both the implementation of a system as well as during system maintenance. These slice profiles are also being examined as the basis for cohesion metrics. It is hoped that in future work, we will be able to present quantitative metrics for cohesion based on measuring the properties of the slice profiles. References 1. B. W. Boehm, J. R. Brown, H. Kaspar, M. Lipow, G. J. MacLeod and M. J. Merritt, Characteristics of software quality, TRW and North-Holland Publishing Co., 1978. 2. D. N. Card, V. E. Church and W. W. Agresti, An empirical study of software design practices, IEEE Trans. on Software Eng. SE-12,2 (February 1986), 264-271. 3. L. L. Constantine and E. Yourdon, Structured design, Englewood Cliffs, Prentice-Hall, New Jersey, 1979. 4. S. D. Conte, H. E. Dunsmore and V. Y. Shen, in Software engineering metrics and models, Benjamin/Cummings Publishing Company, Inc., 1986. 5. B. Curtis, S. B. Sheppard and P. Milliman, Third time charm: stronger replication of the ability of software complexity metrics to predict programmer performance, Proceedings of the 4th international conference on software engineering, Munich, Germany, 1979, 356-360. 6. B. Curtis, Measurement and experimentation in software engineering, Proceedings of the IEEE 68,2 (September 1980), 1144-1147. 7. T. J. Emerson, A discriminant metric for module cohesion, Proceedings of the 7th international conference on software engineering, Chicago, Il., 1984, 294-303. 8. T. Gilb, Software Metrics, Winthrop Publishers, Inc., 1977. 9. H. Longworth, Slice based program metrics, Master s Thesis, Michigan Technological University, 1985. 10. G. Myers, Composite structured design, Van Nostrand, 1978. 11. M. Page-Jones, in The practical guide to structured systems design, New York, NY, 1980, Yourdon Press. 12. J. J. Thuss, An Investigation into Sliced Based Cohesion Metrics, Master s Thesis, Michigan Technological University, 1988. 13. M. D. Weiser, Program slicing, Proceedings of the 5th international conference on software engineering, San Diego, CA., 1981, 439-449. 14. M. D. Weiser, Programmers use slices when debugging, Comm. ACM 25,7 (July 1982), 446-452. 15. M. D. Weiser, Program slicing, IEEE Trans. on Software Eng. SE-10,4 (July 1984), 352-357.