The Relationship between Slices and Module Cohesion

Transcription

1 The Relationship between Slices and Module Cohesion Linda M. Ott Jeffrey J. Thusst Department of Computer Science Michigan Technological University Houghton, M 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. n this paper, we examine the relationship between the data flow in a module and its level of cohesion using aprocessing element jow 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 iables of a module. A relationship is then shown between these slice profiles and the PFG used to indicate levels of cohesion. t is suggested that these slice profiles can be used to determine more easily the cohesiveness of a module.. ntroduction The psychological coniplexity of software is a measure of how difficult it is for programmers to interact with the software []. t is inted to reflect how well the software is written in terms of understandability, testability, and maintainability. These concepts have been identified by Boehm [l] as essential in the development of high quality software. The decomposition of a system into modules can significantly reduce psychological complexity. Myers [ 0 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 [,,8]. Modularity offers a rational solution by breaking up large problems into several smaller, more manageable pieces. Constantine and Yourdon 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 [ll] and attempts to find quantitative cohesion metrics [7,]. t Current address: Autotrol Technology, 00 Washington St., Denver, CO 80 Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specfic permission. The aim of this paper is to show that the degree of cohesiveness of a module can be seen by examining slices [. generated from the output iables of the module. n section, we will discuss cohesion and provide a simplification of the metric based on examining the relationships among the processing elements of the module using aprocessing elementflow graph (PFG). Section contains a brief description of slicing and presents a slice profile. n section, 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, we discuss further implications of this relationship.. Cohesion Constantine and Yourdon [] have identified seven levels of modular cohesion. t 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. n 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 []. (Others, e.g., Emerson [7] and Card [] have used three levels of discrimination in their work.) Nodes in a processing element Jlow 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.. Two special nodes, labeled nputs and Outputs, represent the set of input iables used by the module and the set of output iables computed by the module, respectively. These graphs are used to identify processing element relationships typcal of modules with the four cohesion classes described below... 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. 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 depence on a subset of the input iables. L8 0 8 ACM 0707/8/000/08$00.7 Recommed by: Priscilla Fowler

2 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. Figure. 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 t 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 t to exhibit data flow patterns similar to coincidental modules... Control Cohesion: Logical and Procedural The second cohesion discrimination level is called control cohesion. t is associated with Constantine and Yourdon s logical and procedural cohesion levels. PFGs for these modules t to be highly diversified and difficult to represent with a simple picture. The PFG in Figure serves as an example. The graph represents alternate definitions of two iables under the control of a common ifthenelse structure. The symbols F and F are used to represent the processing elements corresponding to the alternate definitions for the iable F. Similarly, G and G represent processing elements for the iable 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 %e control structure is shown in the graph by the presence of four processing element nodes instead of two. w outputs Figure. PFG for a module with inputsided 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 outputsided 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 is typical of a module with outputsided communicational data flow. W Figure. PFG for a module with control cohesion. Fl and G correspond to processing elements contained within the if block of an enclosing ifthenelse structure. F and G 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. n modules with higher cohesion levels, however, the control and data bindings become interrelated... 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 inputsided communicational data flow in Figure. 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. n this Figure. PFG for a module with outputsided 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 inputsided PFG contains two distinct data paths consisting of the elements FH and GH. The outputsided graph has similar paths consisting of elements FG and FH. This similarity in data relationships suggests classifying modules with both of these communicational flow types as having data cohesion... 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 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 t to be very indepent. Processing elements in sequential modules are highly interrelated due to their strong data depencies. Functional modules typically

3 compute a single output represented by a single processing element. Q nputs h 0 Y outputs Figure. 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.. Program Sticing Slicing is a method of program reduction introduced by Weiser [. 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... The Definition of a Slice Weiser's formal definition of a slice as presented in [] 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 []. The symbol M is used to indicate an arbitrary module, e.g., a procedure, function, or main program. Definition. A slicing criterion is a tuple c i, V>, where i denotes a specific statement number in a module M and V is a subset of the iables in M. Deftnition. An intruprocedurul 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 iables in V at statement i. As an example, consider the module in Figure. 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 L procedure SumAndProduct( N : integer: SU" : integer: Prom : integer ): : integer; SU" := 0; Prom := ; for := to N do SU" := SU" + ; Prom := Prom * ; Figure, 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 = c, {SumN)>. s 8 and 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 = c, {Pro&}>. 7 0 procedure SumAndProduct( N : integer: Sum?? : integer: Prom : integer ); : integer: SU" := 0; for := to N do SumN := SumN + ; ; Figure 7. Slice of SumAndProduct obtained with slicing criterion c = <, {SU"}>... Slice Profiles A slice proje is a convenient representation for revealing slice patterns within a module. They are based on figures used by Longworth [] to identify the relationship between slices and data flow. As an example, the slice profile for procedure SumAndProduct is given in Figure 8. The "" column contains the line number of each statement in the module. Each column with a iable name as the heading in the slice profile corresponds to the slice associated with that iable. All rows in the profile marked with a vertical bar "" are statements included in a slice for a particular iable, otherwise the row is blank. The "" column contains the source statement. For example, the column with heading SumN in Figure 8 corresponds to the slice for the iable SumN. The slice for SumN consists of all statements containing a vertical bar in the column for SumN, i.e., statements,,,,,, 7, 8,, 0,, and. 00

4 8 0 ProdN procedure SumAndProduct( N : integer; SumN : integer; ProdN : integer ); : integer; sum := 0; ProdN := ; for := to N do SU" := SU" t ; ProdN := ProdN * Figure 8. Slice profile for SumAndProduct. s included in the slice for C = <, {SumN}> are indicated with a "" in the column labeled SumN of the profile. The slice for C = ~, {ProdN}> is indicated in the column labeled ProdN... 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. SLoutpm is the set of all slices obtained with the criterion C = c., {v)>, where v is any iable defined by M such that one of the following holds for V. i. v is a reference parameter (or any iable which retains its assigned value after the module has completed execution). ii. f 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 SLourpuu is based on the assumption that the purpose of any module is to compute one or more outputs. The slice of any output iable will consist of statements contained in processing elements involved in the computation of that output. f 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... nclusion 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 begids 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 s do not constitute separate statements, but serve as grouping symbols for the statements contained within a compound statement. nclusion 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. Defrnition. Variablereferent executable statements (VRES) include all executable statements which reference a iable. 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 contains a profile for the SumAndProduct module using only VRES in the slices. SumN ProdN procedure SumAndProduct( N : inteqer; SumN : integer; ProdN : integer ); : integer; sum := 0; ProdN := ; for := to N do sum := sum t ; ProdN := ProdN * : Figure. Slice profile for SumAndF'roduct. Only VRES are included in the slices. 0

5 procedure SumAndProductl ( N : integer; su" : integer; SumSqrN : integer; Prom : integer ; : integer; SU" := 0; for := to N do SLl" := SU" + ; SumSqrN := 0; for := to N do SumSqrN := SumSqrN + *; ProdN := ; for := to N do ProdN := Pro& * Figure 0. Slice profile for SumAndProductl.. Slice Patterns and Processing Element Relationship n 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 0 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 iables partition the module into three disjoint subsets of the set of all the module's VRES statements as shown in the figure. n 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 nonintersecting slices in the profile for the module. Figure contains a iation of the module in Figure 0. n SumAndProduct, the computation of the outputs is enclosed in a forloop 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. f this statement is removed from each slice, the resulting set of slices again partitions the module into its three unrelated processing elements. A slice profile for procedure ProcessAnay is shown in Figure. This module consists of three processing elements computing 7 SumN SumSqrN ProdN the output iables 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 depency 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 depency is indicated in the slice profile by the intersection of all the slices at statements through. The intersection contains data definitions (statements and ) 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 through 7 and 8 through 0. Note that the module exhibits outputsided 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 is identical to the PFG for ProcessArray, where F, G, and H, in the figure, correspond to processing elements computing the iables X, SumX, and SumSqrX, respectively. Modules exhibiting communicational data flow are classified as having data cohesion. A profile for module FindLargest is shown in Figure. This module consists of two processing elements computing the positions of the largest (Max) and second largest (NextMax) elements in the anay X. The processing elements are highly interrelated due to the strong depency of NextMax on the value of Max. The depency 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 procedure SumAndProduct( N : integer; SumN : integer; SumSqrN : integer; ProdN : integer ); : integer; sum := 0: SumSqrN := 0; Prom := ; for := to N do SumN := SumN + ; SumSqrN := SumSqrN + *; ProdN := ProdN * ; Figure. Slice profile for SumAndProduct. 0

6 _. 8 0 X SumX SumSqrX procedure ProcessArray( N : integer; X : ntvector; SumX : integer ; SumSqrX : integer );, J : integer; for := to N do X[] = 0; for J := to do X[l := X[ t J : SumX := 0; for := to N do SumX := SumX + X[]; SumSqrX := 0: for := to N do SumSqrX := SumSqrX t X[l*X[l Figure. Slice profile for ProcessArray. relationship is indicated in the profile by the amount of overlap between the slices. n particular, the slice for Max is entirely contained within the slice for NextMax.. Conclusion The observations made in the previous section on the relationship between slice patterns and processing element relationships, are summarized below. Observation. The partition of a module induced by the slice of an output iable 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 iable. Observation. The intersection of two or more slices is a subset of the module's processing elements. l a 0 Max NextMax Observation. Slice intersections indicate processing element relationships. f the intersection of slices contains primarily control statements and definitions for the control iables, the processing elements t to exhibit control cohesion. f the intersection of slices contains noncontrol iable data definitions, the processing elements t to exhibit data cohesion. SumAndProductl serves as an example of the first observation. n this case, the slices clearly partition the module into its three distinct processing elements. SumAndF'roductZ 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 depency in the processing elements for SumX and SumSqrX on the element procedure FindLargest( A : Realvector; N : integer: Max : integer; NextMax : integer va r : integer; if (A[ >= A[) then Max := ; NextMax := else Max := : NextMax := : := ; while ( <= N) do if (AL >= A[Max]) then NextMax := Max: Max := else if (AL > ALNextMaxl) then NextMax := ; :=+l : Figure. Slice profile for FindLargest. 0

7 computing X. Finally, the second observation can be seen in Processhay 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. n 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 []) 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. t 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 B. W. Boehm, J. R. Brown, H. Kaspar, M. Lipow, G. J. MacLeod and M. J. Merritt, Characteristics of software quality, TRW and NorthHolland Publishing Co., 78. D. N. Card, V. E. Church and W. W. Agresti, An empirical study of software design practices, EEE Trans. on Software Eng. SE, (February 8), 7. L. L. Constantine and E. Yourdon, Structured design, Englewood Cliffs, PrenticeHall, New Jersey, 7. S. D. Conte, H. E. Dunsmore and V. Y. Shen, in Software engineering metrics and models, BenjamidCummings Publishing Company, nc., 8. 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 th international conference on software engineering, Munich, Germany, 7,0. B. Curtis, Measurement and experimentation in software engineering, Proceedings of the BEE 8, (September 80), 7. T. J. Emerson, A discriminant metric for module cohesion, Proceedings of the 7th international conference on software engineering, Chicago, l., 8,0. T. Gilb, Software Metrics, Winthrop Publishers, nc., 77. H. Longworth, Slice based program metrics, Master s Thesis, Michigan Technological University, 8. G. Myers, Composite structured design, Van Nostrand, 78. M. PageJones, in The practical guide to structured systems design, New York, NY, 80, Yourdon Press. J. J. Thuss, An nvestigation into Sliced Based Cohesion Metrics, Master s Thesis, Michigan Technological University, 88. M. D. Weiser, Program slicing, Proceedings of the th international conference on software engineering, San Diego, CA., 8,. M. D. Weiser, Programmers use slices when debugging, Comm. ACM,7 (July 8),. M. D. Weiser, Program slicing, EEE Trans. on Software Eng. SE0, (July 8), 7. 0