A critique of cohesion measures in the object-oriented paradigm

更新时间：2023-08-28 04:34:01 阅读量：教育文库文档下载

说明：文章内容仅供预览，部分内容可能不全。下载后的文档，内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的，是否完整无缺。

奥密克戎易再感染推荐度：
相关推荐

Cohesion refers to the "relatedness " of a module's components. In the object-oriented paradigm, cohesion refers to the "relatedness " among the methods of a class. Most of the current measures of cohesion in the object-oriented paradig

Michigan Technological University Department of Computer Science Master of Science Thesis

A Critique of Cohesion Measures in the Object-Oriented Paradigm

Bindu S. Gupta March 11, 1997

AbstractCohesion refers to the\relatedness" of a module's components. In the object-oriented paradigm, cohesion refers to the\relatedness" among the methods of a class. Most of the current measures of cohesion in the object-oriented paradigm are based on the idea of data cohesion. The general assumption is that the object-oriented paradigm has modules that encapsulate abstract data types. In this thesis we examine measures of cohesion in the object-oriented paradigm. A list of properties that these cohesion measures must satisfy is presented. Some existing and new measures in the object-oriented paradigm claimed to be cohesion measures are compared with this list of properties. Inconsistencies between the measures and our understanding of cohesion are also discussed. We will be looking at some C++ classes like List, Stack, etc. that are intuitively cohesive classes. The cohesion values are computed for each of the measures to see what they indicate about the cohesion of each class. Contrary to our intuition that methods of a class will use most of the data elements, we see that in most cases methods use only a few of the data elements. This means that characterizing cohesion based on data interactions might not be the correct way of measuring cohesion in the objectoriented paradigm. For classes that seem cohesive but have no data interactions, all the measures give low cohesion values, indicating that such type of classes are not cohesive. This raises a question, is\cohesion" in the object-oriented paradigm something other than data cohesion as has been hypothesized? And, if so, what is the right measure for cohesion? We hypothesize that in addition to data cohesion another form of cohesion exists which is based in the application domain and hence we refer to it as application-based cohesion. Future work on cohesion in the object-oriented paradigm needs to address this question.

Contents1 Introduction 2 Background2.1 The Object-Oriented Paradigm::::::::::::::::::::::::: 2.2 Measures in the Object-Oriented Paradigm:::::::::::::::::: 2.3 Cohesion in the Object-Oriented Paradigm:::::::::::::::::: The Lack of Cohesion in Methods Metric:: Connectivity Metric:::::::::::::: Chen and Lu's Cohesion Measure::::::: A Composite Cohesion Measure:::::::: Bieman and Kang's Class Cohesion Measures Slice-Based Data Cohesion Measures::::: 3.6.1 Class Slicing:::::::::::::: 3.6.2 Data Cohesion Measures::::::::

1 33 4 4 7 8 9 9 10 11 12 13

3 Existing Cohesion Measures in the Object-Oriented Paradigm3.1 3.2 3.3 3.4 3.5 3.6

::::::::

:::::

:::

::::::::

::::::::::::::

4 Are These Measures Satisfactory?

4.1 Necessary Properties for Cohesion Measures:::: 4.2 Do the Cohesion Measures Satisfy the Properties? 4.2.1 Lack of Cohesion in Methods:::::::: 4.2.2 Connectivity Metric::::::::::::: 4.2.3 Chen and Lu's Cohesion Metric::::::: 4.2.4 A Composite Cohesion Measure::::::: i

::::::

15 17 17 20 21 29

4.2.5 Bieman and Kang's Class Cohesion Measure::::::::::::: 4.2.6 Slice-Based Data Cohesion Measures:::::::::::::::::: 4.3 Another View of Cohesion::::::::::::::::::::::::::::

32 33 34

5 Summary and Future Work

List of Figures2.1 LIST class.:::::::::::::::::::::::::::::::::::: 4.1 Case I: Class with a pair of methods that do not share any instance variables. 4.2 Case II: Class with three methods where only two of the methods share an instance variable.::::::::::::::::::::::::::::::::: 4.3 Case III: Class with four methods where a pair of methods share an instance variable each.::::::::::::::::::::::::::::::::::: 4.4 Case IV: Class with four methods where only three of the four methods share an instance variable.::::::::::::::::::::::::::::::: 4.5 Case V: Minimally cohesive class.:::::::::::::::::::::::: 4.6 Stack class.:::::::::::::::::::::::::::::::::::: 4.7 List.h::::::::::::::::::::::::::::::::::::::: 4.8 Object.h:::::::::::::::::::::::::::::::::::::: 4.9 List class.::::::::::::::::::::::::::::::::::::: 4.10 Listiter class.::::::::::::::::::::::::::::::::::: 4.11 Pb class.:::::::::::::::::::::::::::::::::::::: 4.12 Metric data slice pro le for class Pb.:::::::::::::::::::::: 6 18 18 19 19 20 23 25 26 28 30 35 38

iii

Chapter 1

IntroductionThe object-oriented paradigm is being introduced throughout the software industry with an assumption that software developed using this paradigm will be more reliable, easier to maintain, and more likely to be reused. Various claims have been made regarding the objectoriented paradigm as being the\silver bullet" for solving the\software crisis" 15, 16, 19]. Claims made about the advantages of the object-oriented paradigm are based primarily on opinions or anecdotes rather than on rigorous and quantitative studies and metrics to support the

claims 9, 17]. Software metrics have been proposed for both the procedural and the object-oriented paradigms to measure various attributes like software quality, programmer productivity, and program complexity 3, 5, 7, 9, 17, 20, 19, 24]. Among these, software complexity has gained special focus. Module independence is argued to be the key to reducing complexity and hence improving the quality and reliability of software 8, 22, 25, 29]. In an attempt to produce more reliable and maintainable software, researchers have measured another attribute of the procedural and object-oriented paradigms, namely, cohesion 9, 11, 12, 13, 17]. Cohesion refers to the\relatedness" of the module components. It has been claimed that the more cohesive a module the easier it is to understand and maintain 8]. Module cohesion in the procedural paradigm is a function or procedure level measure and can range from the most desirable, functional cohesion, to the least desirable, coincidental cohesion 8]. Module cohesion in the object-oriented paradigm is de ned in terms of the cohesion of a class. Researchers up until now have been assuming the cohesion of a class to be a function of the interaction among the data elements in the object or more speci cally the way in which the data elements are used by the object 6, 11, 21]. The concept of cohesion is well understood in the procedural paradigm with measures supported by measurement theory. The measures are a correct numerical characterization of cohesion of a module in the procedural paradigm. We hence attempted to extend the concept of cohesion to the object-oriented paradigm using the cohesion measures de ned in the procedural paradigm as a basis for the cohesion measures in the object-oriented paradigm. The slice-based functional cohesion measures provide a quantitative basis for measuring cohesion of a module (procedure or function) in the procedural paradigm. These measures form a basis for the slice-based data cohesion 1

measures we propose for measuring data cohesion in the object-oriented paradigm. Contrary to our hypothesis that data abstractions and data interactions go hand in hand, we see that the measures always give low values. Typically, methods used only a small subset of the slice data tokens. This caused us to step back and reconsider our assumption about cohesion in the object-oriented paradigm. The result is this thesis. We examine the existing measures in the object-oriented paradigm claimed to be cohesion measures to determine if they were proper numerical characterization of cohesion. As a preliminary step towards validation of these measures, we present a list of properties that any cohesion measure should satisfy. The existing measures are then compared with the properties to see if they satisfy the properties. Although most of the measures satis ed the list of properties, there were other inconsistencies between the measures and our understanding of cohesion. The measures were not proper numer

ical characterization of cohesion. Hence, we conclude that the measures are not appropriate for measuring cohesion in the object-oriented paradigm. Chapter 2 introduces some of the basic concepts of the object-oriented paradigm, and provides a discussion of some existing metrics for measuring various attributes of objectoriented software. An introduction to the concept of cohesion and cohesion in the objectoriented paradigm is also given. Chapter 3 is a discussion of some existing measures claimed to be cohesion measures in the object-oriented paradigm. A list of properties of cohesion that any cohesion measure must satisfy is presented in Chapter 4. This is followed by a comparison of the measures discussed in Chapter 3 with the list of properties to determine if the measures satisfy the properties. In addition, inconsistencies between the measures and our understanding of cohesion are also discussed. We then look at an example class with no data interactions to see what the measures indicate about the cohesion of such a class. Along with our earlier ndings, this raises questions about the concept of cohesion in the object-oriented paradigm. We hypothesize that in addition to data cohesion another form of cohesion exists which is based in the application domain and hence we refer to it as application-based cohesion. Chapter 5 is a summary of the research work and also suggests future directions for research.

Chapter 2

Background2.1 The Object-Oriented ParadigmIn order to be able to de ne metrics to measure the attributes of a paradigm, it is of foremost importance to rst understand the paradigm. Details of the object-oriented paradigm can be found in most C++ books such as 23, 27]. This section is a brief introduction to some of the concepts of the object-oriented paradigm, such as classes, methods, and objects. The procedural paradigm is based on the approach of functional decomposition of the tasks to achieve the goal (or solve a problem). The basic unit is a procedure or a function. Languages that support this paradigm provide facilities for passing arguments to functions and returning values from the functions 27]. Unlike the procedural paradigm, the objectoriented paradigm views any given problem as being a collection of interacting objects 26, 28]. Languages that support the object-oriented paradigm have facilities for de ning a set of operations (functions or operators) for a data type and then restricting the access to the objects of the particular type only to the set of operations de ned 27]. The basic unit of the object-oriented paradigm is a class. A class is an aggregate of named data elements, and a set of operations designed to manipulate that data. The class members or methods are composed of operations that can be performed on the data type by the class and the data required to represent the class abstraction. Methods can have their own local variables and can use the variables de ned in the class. A class can use the me

thods of another class. The same methods are always invoked in response to a similar message from its own class or from another class. The protected, private and public keywords control access to the class members. Members that occur in the public section of the class can be accessed from anywhere within the general program. Members and data elements that occur in a protected or private section can be accessed only by members of the class. The data elements are also referred to as the instance variables of the class. A private declaration of data elements or instance variables is said to be encapsulated 27]. A class can encapsulate a data type. Such access restriction is referred to as information hiding. An object is an instantiation of a class. An object, too, encapsulates both data and operations.

2.2 Measures in the Object-Oriented ParadigmResearchers have proposed various metrics in an attempt to measure the attributes of the object-oriented paradigm such as complexity, and reuse. In 24], Monarchi, Sheetz and Tegarden address object-oriented system complexity at the application, object, method, and variable levels. Measures are proposed to measure the cohesion and coupling aspects of the system. Each measure is presented as a function of the measurable characteristics such as fan-in, fan-out, number of input-output variables, fan-up, fan-down and polymorphism. They claim that each measure is also applicable to all phases of the object-oriented development life cycle. They also claim that the proposed measures could be used to develop a theoretically based methodology to reduce the object-oriented system complexity for any given application. Metrics used to measure the reuse in object-oriented software are proposed in 3, 5, 7, 20]. Bieman 5] derives measures for software reuse in the object-oriented paradigm and measures the levels of reuse and improvements that could be made. Lewis and Henry 20], propose a suite of metrics to measure reuse in the object-oriented paradigm. They claim that reuse signi cantly improves productivity in both the procedural and object-oriented paradigm. And they claim that the object-oriented paradigm de nitely showed an a nity towards reuse. Caldiera and Basili 3] propose a reusability attributes model and metrics to extract reusable components from existing software. They apply their model and metrics to case studies and conclude that the reusable components thus extracted perform useful functions in the context of the application they come from. Bieman and Karunanithi 7] present a set of measurable reuse attributes and metrics to quantify these attributes in object-oriented software. They also propose a tool for generating the proposed reuse measures and the metrics for Ada programs.

2.3 Cohesion in the Object-Oriented ParadigmIn 18], Fenton has de ned cohesion as: Cohesion is an attribute of individual modules, describing their relative functional strength, i.e., the extent to which the individual modu

le components are needed to perform the same task. Constantine and Yourdon 14] de ne cohesion to be the\intramodular functional relatedness" of a software module. Cohesion is commonly categorized into seven levels, ranging from low cohesion to high cohesion, namely, coincidental, logical, temporal, procedural, communicational, sequential, and functional. Low cohesion modules, for example modules with coincidental cohesion, are indicative of a module that performs two or more basic functions or tasks. Further, the module may itself be a part of a basic function or task. High cohesion modules, for example modules with functional cohesion, on the other hand are indicative of modules that perform only one basic function. In such modules all the module components are needed to perform the same task. Hence, functional cohesion is the most desirable. 4

Buxton and Macro 10] extended the original seven levels of cohesion to include another type of cohesion which included modules that encapsulate abstract data types. They called this abstract cohesion or data cohesion. Fenton 18], describes such cohesion as a completely di erent type of cohesion and disagrees that it is an extension of the original seven levels of cohesion. This type of cohesion characterizes a data type as cohesive because the operations are performed on a single object. Thus a module in this case can perform a variety of functions, which are related by the abstract data type they characterize. Unlike the procedural programming paradigm where a module is de ned to be a procedure or a function, in the object-oriented paradigm we de ne a module to be a class. A class with a private representation of data elements and a public set of methods is referred to as an abstract data type. A class has several methods that perform certain functions on the class data type. Consider the list class described in Figure 2.1. Here we see that each method of the class uses the data elements head and tail to de ne various operations that can be performed on a LIST of objects, such as, append, remove, and is empty. All the methods are operating on a single LIST object. The list class encapsulating the abstract data type, LIST. Hence, the list class can be considered to be a cohesive class.

list::list(){ head= NULL; tail= NULL;} list::~list(){ remove();} void list::append(Type someitem){ item *pt; pt= new item(someitem); assert (pt != 0); if (is_empty()){ head= pt;} else{ tail->next= pt;} pt->next= NULL; tail= pt;} void list::remove(){ item *pt; item *temp; pt= head; while (pt){ temp= pt; pt= pt->next; delete(temp);} head= tail= NULL; cout<<"Removed all list elements"<<"\n";} boolean list::is_empty(){ if (head== NULL) return(true) else return(false);}

Figure 2.1: LIST class encapsulates abstract data type LIST and performs all operations on a LIST of objects as presented in a standard text 27].

Chapter 3

Existing Cohesion Measures in the Object-Oriented ParadigmHer

e we will be presenting some measures that have been proposed by researchers for measuring cohesion in the object-oriented paradigm. Some of the measures like LCOM, Connectivity metric, Chen and Lu's cohesion measure, and Bieman and Kang's cohesion measure are claimed to measure cohesion in the object-oriented paradigm. We, too, propose a cohesion measure in the object-oriented paradigm which is a modi cation of the slice-based functional cohesion measure in the procedural paradigm.

3.1 The Lack of Cohesion in Methods MetricChidamber and Kemerer 12] have proposed a cohesion measure called Lack of Cohesion in Methods, LCOM, based on the number of disjoint sets of instance variables that are used by the method. The cohesion of the class is inversely related to the number of disjoint sets, i.e., the smaller the number of disjoint sets the more cohesive the class is assumed to be. Li and Henry 19] attempted to rephrase the de nition of LCOM given by Chidamber and Kemerer in order to overcome the ambiguity in the original de nition. Chidamber and Kemerer 13] later revised their own de nition for LCOM and formally restated it as follows: Consider a class C1 with n methods M1, M2, . . ., Mn . Let Ij= set of instance variables used by the method Mj . There are n such sets I1,...,In. Let P= f (Ii,Ij ) j Ii\ Ij=;g and Q= f (Ii,Ij ) j Ii\ Ij 6=; g If all n sets I1,...,In are; then let P= 0.

LCOM=

(

jP j? jQj; if jP j> jQj0 otherwise 7

LCOM= 0 indicates a cohesive class since all the methods share instance variables. Hence the class need not be split. For LCOM> 0, the class needs to be or can be split into two or more classes since the instance variables belong in disjoint sets.

3.2 Connectivity MetricHitz and Montazeri 21], present a graph theoretic version of the cohesion metric proposed by Chidamber and Kemerer. They formulate a regression model for measuring the quality of software both at run-time and during the maintenance phase based on their metric. They de ne LCOM as follows: Consider a class X with a set of instance variables, IX, and a set of methods of the class, MX . Let GX (V,E) be a simple undirected graph representing the methods of the class, where V= MX and E= f(m; n) 2 V V j (9 i 2 IX: (m accesses i)^ (n accesses i)) _ (m calls n) _ (n calls m)g LCOM(X) is then de ned as the number of connected components of GX, where 1 LCOM (X ) jMX j where\m accesses i" means that m uses instance variable i.\m calls n" means that they share a common instance variable. For classes with more than two methods, they re ne the LCOM further to be able to measure the structural di erence between the methods of a set of classes with the same value of LCOM. Hence they de ne a connectivity metric, C, used in conjunction with the LCOM metric. The connectivity metric gives a measure of the deviation of a given graph from a minimally cohesive case. Hitz and Montazeri formally de ned connectivity, C, to be 21]: 1) C= 2 (nE? (n(??

2)? 1) n where C is a measure of the deviation of any given graph from the minimally cohesive case, E is the number of edges in the graph and n is the number of vertices (i.e., methods) of the graph. The more the number of connected vertices the more the connectivity (i.e., cohesion). The value of C is always a positive integer as the value is the absolute value of the di erence in the numerator. The value always lies between 0 and 1 21].

3.3 Chen and Lu's Cohesion MeasureChen and Lu 11] propose a cohesion metric based on the idea that operations (i.e., methods) with overlapping arguments tend to be related, thus making a class cohesive. Let a class C have N operations, namely, F(1), F(2), . . ., F(N) and correspondingly there will be N sets of arguments, namely, I(1), I(2), . . ., I(N). According to Chen and Lu, M is the number of disjoint sets formed by the intersection of the N sets of arguments. But what they are doing can be more accurately explained using a graph with N vertices where the vertices represent the parameter sets. An edge exists between the vertices if the parameter sets represented by the vertices share parameters. A connected component is a set of connected vertices in the graph. M is the number of connected components in the graph. The cohesion metric is de ned as: M 100% N Hence, the lower the value of the metric the more cohesive a class. If N is far greater than M, it means that the argument sets are related and that the operations manipulate the related attributes of the class. The value of M can never be more than N since N is the total number of sets of arguments and M is the number of disjoint sets. In the worst case where all the argument sets are disjoint, M= N. The previous cohesion measure, namely LCOM, measures cohesion in terms of the intersection of the instance variables used by the methods, instead of the arguments. Instance variables used may be unavailable in the design phase 11]. Chen and Lu claim that the arguments however will be available at the design phase which makes their metric better than the LCOM metric.

3.4 A Composite Cohesion MeasureBaxter, Chu and Patel 4], propose a composite cohesion measure to measure the cohesion in Ada packages. They claim that their cohesion measure is based on measuring the cohesive strength of a module consisting of two or more primitive components (e.g. an Ada package consisting of subprograms such as procedures, functions, and tasks) 4]. Baxter, Chu and Patel claim that programs from the same package will use the same type of variables and hence have higher cohesion than programs from completely di erent packages. The following de nition is taken directly from 4]. Given a composite module P= fp1,p2, ..., pm g (where pi may either be a procedure or a function), the cohesion of a composite module is de ned as:

Cohesion(P )=

S Sim2(pi; pj ) Pm?1 i i

where S= f(i,j) j i,j 2 (1,m)^ i> jg Sim2(pi; pj ) is the summation of the similarity betw

een distinct pairs of functions or procedures in the module; the i>j condition insures that the similarity computation between a pair is only considered once within the summation.

Sim2(pi; pj )= qPn1

x2 i

pj S piq

n y2 1 i

where n is the number of members in the module. The numerator represents the summation of the product of the frequencies of the set of variables shared between modules pi and pj . This is explained in detail in the later part of this section. The denominator is the cardinality of modules pi and pj . Pm?1 i i computes the the total number of possible pairs for which the similarity metric is computed in the numerator. The composite module cohesion is thus computed to be the average of the similarity measures over distinct pairs of functions and procedures in the module 4]. Baxter, Chu and Patel claim that their proposed composite cohesion measure is based on information retrieval principles that accomplish the task of highlighting properties shared between members of a module. They claim that in the domain of information retrieval a logical organization of related members in a group is determined by a measure of similarity. A similarity measure is de ned so that an object is more like other objects in the same group and less like objects from other groups 30]. In order to compute the similarity between members of a module, rst a type vector for each member of the module must be computed. The basic idea is to scan the module for references to variables of a given type. If a member references a variable, V, and V is of type, T, then the counter associated with type T is incremented. Thus a type vector contains the frequency of the variables referenced of a particular type. The type vectors of all members are placed in a table where the rows represent the type vectors and the columns represent the members of the module. Once this is done, the similarity between the members is computed as Sim2(pi; pj ) where pi; pj are members of the module. The cohesion of the module, Cohesion(P), is de ned to be a ratio of the similarities between modules to the possible number of pairs for which the similarities can be computed. Baxter, Chu and Patel have obtained measurements for some Ada and C packages 4].

3.5 Bieman and Kang's Class Cohesion MeasuresBieman and Kang 6] propose two class cohesion measures to evaluate the relationship between class cohesion and private reuse in the system. They de ne class cohesion to be an attribute of a class that refers to the\relatedness" or\connectivity" among components of the class. The components include the instance variables and the methods de ned in a class plus those that are inherited. A method is said to be\related" or\connected" to an instance variable if the method uses that instance variable. 10

The class cohesion measures proposed by Bieman and Kang 6] are based on the direct or indirect connectivity between a pair of methods. Two methods that use one or more common instanc

e variables are said to be directly connected. Two methods that are connected through other directly connected methods, are indirectly connected. Let NDC(C), be the number of directly connected methods in a class C. NIC(C), is the number of indirectly connected methods in a class C. NP(C)=N * (N - 1)/2 is the maximum possible number of connections in a class. Tight class cohesion (TCC) is de ned to be a ratio of the number of directly connected methods in a class, NDC(C), to the maximum possible number of connections in a class. TCC(C)= NDC(C)/ NP(C) Loose class cohesion (LCC) is de ned to be a ratio of all directly connected methods, NDC(C), and indirectly connected methods, NIC(C), in a class to the maximum possible number of connections in a class, NP(C). LCC(C)= (NDC(C)+ NIC(C))/ NP(C)

3.6 Slice-Based Data Cohesion MeasuresHere we propose measures based on the slice-based functional cohesion measures in the procedural paradigm. By modifying the functional cohesion measures we de ne slice-based data cohesion measures for the object-oriented paradigm. In 9] Bieman and Ott introduce the concept of data slices to measure slice-based functional cohesion in the procedural paradigm. In order for the metrics to be sensitive to changes in code, they use data tokens (i.e., variable and constant de nitions and references) to measure cohesion. A data slice for a slice data token, v, is de ned to be the sequence of all data tokens Ti in the statements that comprise the\backward" and\forward" slices for v, where the i in Ti indicates ith occurrence of the data token T in the module 9]. Thus each data token can be uniquely identi ed. A data slice is computed for each output of the procedure. An\output" is the output to a le (or user output), an output parameter, or an assignment to a global variable. The functional cohesion measures are developed using an abstract model of a procedure based on data slices. The slice abstraction of a procedure p, SA(p), models the procedure as a set of data slices, and a data slice as a sequence of data tokens. Thus, when analyzing the cohesion of a procedure, it is important to know when one token is in more than one data slice. Data tokens that are in all the data slices of a procedure, p, are called super-glue 9]. It is denoted as SG(SA(p)), read as the super-glue tokens in the slice abstraction of procedure, p. Data tokens in two or more data slices of procedure, p, are called glue tokens, denoted as G(SA(p)). All super-glue tokens are also glue tokens 9]. Bieman and Ott measure the cohesion of a module in the procedural paradigm by examining the percentage of tokens that are glue and super-glue tokens. Since the glue tokens bind the data slices to di erent degrees depending on how many slices are a ected, the cohesion can also vary depending 11

on the number of data slices that particular glue token binds. tokens(p), denotes the total number of data tokens in procedure, p. These concepts of data tokens, gl

ue, and super-glue are used to de ne the slice-based functional cohesion measures 9]. The slice-based functional cohesion measures are based on the concepts of data tokens, slice abstraction, glue and super-glue tokens. Following are the slice-based functional cohesion measures for the procedural paradigm 9]: Strong Functional Cohesion, SFC, is de ned to be a ratio of the super-glue tokens to the total number of data tokens in a procedure, p, tokens(p). (p)) SFC (p)= jSG(SA(p)j j jtokens

Weak Functional Cohesion, WFC, is de ned as the ratio of glue tokens to the total number of data tokens in a procedure, p, tokens(p). It indicates a\weaker" type of cohesion than indicated by super-glue tokens as adding a glue token can\glue" together previously non-cohesive elements even if the token does not glue together all of the slices.p)) WFC (p)= jjG(SA((p)jj tokens

Adhesiveness, A, is de ned to be the ratio of the sum of all the slices containing gluetokens to the product of the total number of tokens and the number of data slices.

A(p)=

t G(SA(p))# slices containing t

jtokens(p)j jSA(p)j

3.6.1 Class SlicingWe used modi cations of the slice-based functional cohesion measures de ned by Bieman and Ott 9] in the procedural paradigm, to de ne the slice-based data cohesion measures in the object-oriented paradigm. We used the concept of data tokens, glue and super-glue tokens to de ne the metric data slices for a class and the data cohesion measures. The slice data tokens in the object-oriented paradigm were de ned to be the data tokens de ned in the private or the protected sections in the class. We considered these data tokens to be the slice data tokens as all the operations de ned in a class are performed on these data tokens. In the case of the object-oriented paradigm, a class including all the methods of the class is the basic unit considered to be a module. A metric data slice for each method of the class is obtained using the same de nitions of\forward" and\backward" slices as de ned for the procedural paradigm 9]. The slices thus obtained for each method are then combined to obtain the metric data slice for a class. Thus, a metric data slice for a class is the concatenation of the metric data slices for each of the methods of the class. The rede ned measures will then be applied to the class as a module. 12

Modifying the de nitions found in 9], we de ne the class slice abstraction of a class C with n methods, CSA(C ) to be the concatenation of all the slice abstractions of its methods denoted as MSA(mn) assuming MSA(mi) is the method slice abstraction of method mi of class C. The slice abstraction for class C is de ned as: CSA(C)= f MSA(m1 ), MSA(m2 ), . . ., MSA(mn )g

3.6.2 Data Cohesion MeasuresThe data cohesion measures are described in terms of slice abstractions, data tokens, and glue and super-glue tokens 9] but as applied to the object-oriented paradigm. The basic de nition for a data token and glue and super-glue to

kens remained similar to their de nition in the procedural paradigm. The set of super-glue tokens for the class, C, denoted as, SG(CSA(C)), was de ned to be a union of the super-glue tokens of each of the methods of the class. Similarly, the set of glue tokens for the class, C, denoted as G(CSA(C)), was de ned to be the union of the glue tokens of each of the methods of the class. tokens(C) is a set of all data tokens of a class C. Strong data cohesion, SDC, is a measure based on the number of data tokens included in all the data slices for a class, i.e., a count of the number of super-glue tokens in the class C . The super-glue tokens bind all the data slices together and are indicative of a highly cohesive class. Thus, a class where all data tokens are super-glue tokens will have data cohesion of 1 while a class with no super-glue tokens will have no cohesion. Classes with fewer number of super-glue tokens will have lower strong data cohesion than classes where all data tokens are super-glue. (C SDC (C )= jSG(CSAC )j))j jtokens(

Weak data cohesion, WDC, is indicative of the amount of cohesion in a class based onthe number of glue tokens. Glue tokens, unlike the super-glue tokens, do not necessarily bind all the data slices together, hence are indicative of a weaker type of cohesion. A class with no glue tokens will have no cohesion. This type of cohesion is more sensitive than strong data cohesion which is based on super-glue tokens. Adding a glue token may bind together previously non-cohesive elements even if it does not bind together all the slices. (C )) WDC (C )= jG(CSA(C )j j jtokens

Adhesiveness, A, is a measure of the cohesiveness of a class, i.e. the binding or relatedness

among the data slices. It is a comparison between the glue tokens and the total number of data tokens in a class. Adhesiveness for a class C can be de ned as the ratio of the sum of all the slices containing glue tokens to the product of the number of data tokens in the class and the number of data slices. Thus,

A(C )=

d G(CSA(C ))# slices containing d

jtokens(C )j jCSA(C )j13

Weak data cohesion and Adhesiveness di er from Strong data cohesion in cases of three or more data slices. In the case of 1 or 2 data slices, SDC(C)=WDC(C)=A(C). The values of the measures always lies between 0 and 1, where 0 indicates no cohesion and 1 indicates high cohesion.

本文来源：https://www.bwwdw.com/article/daii.html

相关文章：

沥青路面施工组织设计04-04

（工程文档）四川省某市医院职工住宅楼水电安装施工组织设计12-02

化学反应工程习题集04-04

中学十佳班主任颁奖词摘抄03-14

小学三年级班主任计划表(通用版)06-06

人教版八下政治第二单元第四课人人享有人格尊严权(18张幻灯片)06-07

氧化还原滴定08-11

实验十五氧化还原反应和氧化还原平衡11-13

小学优秀班主任先进事迹材料07-05

上一篇：水浒传读后感下一篇：2005年10月全国高等教育自学考试管理心理学试题