Chidamber and Kemerer Object-Oriented Measures: Analysis of their Design from the Metrology Perspective

Transcription

1 , pp Chidamber and Kemerer Object-Oriented Measures: Analysis of their Design from the Metrology Perspective Laila Cheikhi 1, Rafa E. Al-Qutaish 2, Ali Idri 1 and Asma Sellami 3 1 École Nationale Supérieure d'informatique et d'analyse des Systèmes (ENSIAS) UniversitéMohammed V Souissi, Rabat, Morocco 2 École de Technologie Supérieure (ÉTS) Universitédu Québec, Montréal, Québec, Canada 3 Institut Supérieur d Informatique et multimédia de Sfax ISIMS University of Sfax, Pôle technologique, Sfax, Tunisia cheikhi@ensias.ma, rafa.al-qutaish@etsmtl.ca, idri@ensias.ma, asma.sellami@isimsf.rnu.tn Abstract During the last decade, software product measurement field has known many improvements and becomes an emerging field of software engineering. Based on the used programming approaches such as object-oriented, structured programming, etc., different kinds of measures are proposed in the literature. These sets of measures were defined many years ago to measure software artifacts, for example, source code and design, However, such measures need to be verified and validated based on the lessons learned from the measurement and metrology concepts. This paper focuses on software product measures, in particular, the object-oriented measures. Moreover, it aims at analyzing the design of a wellknown and one of the most used object-oriented measures, that is, the Chidamber and Kemerer measures suite. In addition, this paper provides an investigation of the extent to which this set of measures addresses the metrology concepts related to the software measurement design. Keywords: OO Design, Chidamber and Kemerer (C&K) Metrics Suite, Measurement Process Model, Software Quality, Metrology 1. Introduction The application of object-oriented technology produces well-structured software systems with comprehensible architectures which are easy to test, maintain, and extend [1]. However, the object-oriented approach does not ensure the production of software with high quality nor avoid errors introduced by programmers during both development and maintenance phases. Therefore, various object-oriented metrics are proposed in the literature as a means of determining whether the investigated software hold desired object-oriented design properties such as coupling, complexity, cohesion, and inheritance to improve the quality of this software. Many of these measures have been proposed by different researchers and practitioners, such as those proposed by Li and Henry [2], Briand et al., [3, 4], Chidamber and Kemerer [5, 6], and Abreu et al., [7]. For example, Chidamber and Kemerer (C&K) [3, 4] proposed a suite of measures for object-oriented design measurement. Whereas, Briand et al. [3, 4] have proposed a series of coupling and cohesion measures for class in which they take into account the various ISSN: IJSEIA Copyright c 2014 SERSC

2 mechanisms offered by the C++ language. In addition, Archer and Stinson [8] presented a full description of all these measures and others proposed in the literature. Although the results of the measures are very important for software project management and evaluation, their design is of special importance for the practitioner. If the proposed measures are designed with respect to a specified purpose with its corresponding formula, then computed values are reliable. Moreover, if they are not well-documented, the same measure can be understood and applied differently by its users, and therefore, leading to a diversity of results and different interpretations of these results. A potential cause of such a problem could be related to the fact that many of these objectoriented measures have been proposed in an ad hoc fashion with no regard to their design of measurement method, and with limited emphasis on their context, appropriateness, and validity to evaluate the measured concept. In fact, a well-designed measure should be repeatable to give the same results in the same context, that is, same software and same people skills [9]. Therefore, it is important to have a good framework (such as the framework for designing measurement method [10] and the metrology concepts related to the design of measurement method [11]) to analyze the existing measures in order to avoid these limitations and to allow an accurate use of such measures in empirical, experimental, and benchmarking studies. Once achieved, the comparative studies can be reliable and will improve drastically our practices toward the improvement of the software quality. In this paper, we focus on the well-known object oriented design measures suite proposed by Chidamber and Kemerer. To help in understanding and clarifying the Chidamber and Kemerer measures, each measure is analyzed in this paper from metrology perspectives and mapped to the relevant concepts. Such mapping will contribute in identifying the metrology concepts that are not tackled in Chidamber and Kemerer measures. Moreover, it will give an opportunity to improve the design of these well-known measures. This paper is organized as follows: Section 2 provides an overview of metrology concepts related to design of measures, that is, the analysis framework. Section 3 introduces the related object-oriented concepts, and explains the definitions and the theoretical basis of the Chidamber and Kemerer suite of measures. Section 4 presents the analysis of the Chidamber and Kemerer using metrology concepts. Finally, a discussion in section 5 will conclude the paper. 2. Analysis Framework: Overview The analysis framework which is related to the metrology concepts is defined in the International Vocabulary of Basic and General Terms in Metrology (VIM). Where, it represents the international consensus on terminology of metrology concepts common to all disciplines [11]. Furthermore, the term metrology is defined by ISO experts as the science of measurement and its application [11]. In practical, metrology terms are textually defined and grouped in six categories reflecting the addressed concepts [12], that is: Quantities and Units (includes 22 terms). Measurement Standards - Etalons (includes 14 terms). Measurements (includes 9 terms). Measurement Results (includes 16 terms). Measuring Instruments (includes 31 terms). Characteristics of the Measuring Instruments (includes 28 terms). 360 Copyright c 2014 SERSC

3 These metrology concepts are widely used in other disciplines, such as physics and chemistry, but they are rarely referred to in the software engineering literature. To facilitate and understand this set of categories, its corresponding terms, and the links between them, a graphical representation of these categories has been proposed by Abran and Sellami [12]. Moreover, they have founded that the first two categories Quantities and Units and Measurement Standards - Etalon are related to the design of measurement methods. Nowadays, the applicability of metrology concepts in information technology has risen in different studies (for more details, see [13]), for examples: Investigation of metrology concepts in software engineering domain. Identification of ambiguities in the domain of software measurement, and proposition of the corresponding metrology terms for these ambiguous terms. Analysis of the design of different measures from the metrology concepts, such as the ISO related to COSMIC-FFP. Since there is no standard formalism for defining software measures, many of the existing measures present some ambiguity in their definitions and design which affect their use and the interpretation of the measurement results. To avoid this problem, the ISO [14] standard has adopted the International Vocabulary of Basic and General Terms in Metrology (VIM) in defining software measurement related terminology. However, the definitions of terms used in this paper are based on the ISO [14] and the International Vocabulary of Basic and General Terms in Metrology [11]. Table 1 shows the definitions of the used terms. Term Objective Entity Attribute Bases attribute Derived attribute Measurement of an attribute Measurement method Measurement function Measurement unit Value Table 1. Definitions of the used Metrology Terms [11, 12] Definition Refers to what we want to measure and what the measurement point of view will be. Refers to any distinguishable object in the empirical world for which a measurement can be applied. Examples of entities to be measured are: piece of code, design artifact, etc. The property of an entity that can be determined quantitatively, that is, for which a magnitude can be assigned (called quantity in metrology terminology). A simple property defined by convention, with no reference to other attributes, and possibly used in system of attributes to define other attributes (called base quantity in metrology terminology). A property defined in a system of attributes as a function of base attributes (called derived quantity in metrology terminology). The characterization of that attribute in terms of numbers or symbols. Generic description of a logical organization of operations used in a measurement. Function of quantities, the value of which, when calculated using known quantity values for the input quantities in a measurement model, is a measured quantity value of the output quantity in the measurement model Real scalar quantity, defined and adopted by convention, with which any other quantity of the same kind can be compared to express the ratio of the two quantities as a number. number and reference together expressing magnitude of a quantity To illustrate the use of these terms, Figure 1 below describes the metrology terms used to collect (data collection section) and prepare data (data preparation section) in the measurement information model. A brief description of each section and a resume Copyright c 2014 SERSC 361

4 Metrology International Journal of Software Engineering and Its Applications of the steps to be followed in order to collect the base and derived measures are as the following [15, 16]: Information Product Data Analysis Interpretation Indicator Analysis Model Data Preparation Measurement of Multiple Entities / Attributes Derived Measure Measurement Function Measurement of Single Entity / Attribute Data Collection Base Measure Measurement Method Attributes Figure 1. Metrology Parts in the ISO Measurement Information Model [21, 16] A base measure must correspond to a single distinct software attribute, and to be obtained we have to: 362 Copyright c 2014 SERSC

5 o Identify and define appropriately the attribute of the entity to be measured. o Quantify the attribute through its measurement method. o Identify the measurement unit of the base measure. A derived measure is a composition of two or more base measures. However, in order to obtain a derived measure we have to: o Collect the different base measures composing the derived measure (depends on the information needs). o Assemble them in accordance with a measurement function (e.g., a computational formula) defined for each derived measure. o Identify the measurement unit of the derived measure. In fact a derived measure is the product of a set of measurement units properly combined (through a measurement function). o The name assigned to the derived measure should correspond to the concept representing the particular combination of measurable attributes. o The accuracy of a derived measure is directly related to the accuracy of each of its base measures and to how these base measures are mathematically combined. In practice, although it is not usual in software measurement to take into account the metrology concepts, many studies have been done recently in order to analyze the design of well-known and used measures from metrology concepts, such as the Cyclomatic s complexity number [17]), Halstead s measures [18], function points [19], use case points [20] and ISO 9126 measures [13]. This paper analyzes the design of the well-known suite of Object-Oriented measures proposed by Chidamber and Kemerer [5, 6]. 3. Chidamber and Kemerer Measures: Overview Understanding the object-oriented approach concepts is important to define Object- Oriented measures and therefore analyze the design of the proposed measures. Thus, these concepts are presented so that the terminology used to describe the Chidamber and Kemerer object-oriented measures is as uniform as possible [22] Object-Oriented Concepts According to object-oriented approach, the basic concept in an object-oriented system is an object. An object is characterized by a state (a set of properties characterizing the object as well as the value of each property) and a behavior (a set of operations of the object). A class is the specification of the object; it is the basic model or prototype from which the objects are created. The classes are defined by the public services offered to the users by the intermediary of the methods and public attributes. The methods implement the operations that can be carried out in a class (the logic of programming). The attributes represent the properties of a class. They are defined by their names and their types, that is, simple or complex (int i or Class_A i). The Coupling is defined as the degree of interdependence between the components of the system. Two classes are coupled if a method of one class uses an attribute or method of the other class [5]. Whereas, the Cohesion reflects the degree to which the methods within a class are related to one another. The more is the cohesion of a class, the more it is coherent and constitutes a whole entity inseparable, and the more simple maintainability. The dependence in a software system is a direct relationship between the entities of that system (X & Y) such that the programmer who modifies X must be aware of the potential side effects in Y [23]. For example, the dependence between classes corresponds to the Copyright c 2014 SERSC 363

6 relation between the classes. A class can use the functionalities (attributes or methods) offered by another class via the exchange of messages through the following dependence links: Aggregation: represents the relationship of whole/part. According to Li and Offut [24], it is a capacity relationship. For example, we say that a car has doors or an airplane has wings. Use: Class_A uses Class_B, if Class_A (or its instances) send message(s) to Class_B (or its instances) [25]. In more details, Class_A needs the functionalities provided by Class_B, and Class_B provides its services to Class_A. Inheritance: corresponds to the creation of new classes (derived classes), but based on the existing classes (base classes) whether by reuse or by extension of the functionalities of the previous ones. A derived class inherits the structure and the behavior of the basic class and can be used as a basic class for a later derivation, giving rise to a hierarchy of classes called an inheritance tree Chidamber and Kemerer Measures Chidamber and Kemerer [5] stated that the measures suite of object-oriented design is built upon projects that used Object Oriented design approach, and the aim of this was to propose a set of measures which are not based on the language syntax. However, Chidamber and Kemerer measures can be applied during the later-design and implementation (coding) phases of the software development life cycle, for example, they can be applied on the class diagram (during the later-design phase) and on the source code (during the implementation phase) [26]. The definitions and theoretical basis for the Chidamber and Kemerer measures are illustrated in Table 2 [5, 6, 27]. Furthermore, the following explains these measures: 1) Coupling Between Object (CBO): It is related to the number of non-inherited classes with which a particular class is coupled. Such number reflects the degree of interdependence between the object-oriented system components. However, class X is coupled to class Y if and only if X sends a message to Y; that is, a method of one class use methods or instances variables of another class. 2) Response For a Class (RFC): It represents the number of methods of a class and the number of invoked methods by those class methods. It measures the degree of communication between the classes of the system. 3) Lack of Cohesion in Methods (LCOM): It is the number of pairs of methods which do not share instance variable, minus the number of pairs of methods that share instance variables of the class. 4) Weighted Methods per Class (WMC): It represents the sum of the complexities of all methods of a class. If all the complexities of all methods are ones, then WMC is the number of class methods. 5) Depth of Inheritance Tree (DIT): It measures the level number for a class in the inheritance tree. DIT of the root class in the inheritance tree is equal to zero. 6) Number of Children (NOC): It measures the number of direct subclasses of a class (the children). Moreover, if the subclasses are dependent of their superclass (methods or instance variables), any changes to the superclass may affect the subclasses, and therefore, the harder is the superclass maintainability. 364 Copyright c 2014 SERSC

7 Table 2. Definitions and Theoretical Basis for Chidamber and Kemerer Measures Definition: Theoretical basis: Assumption(s): Definition: Theoretical basis: Assumption(s): Definition: Theoretical basis: Assumption(s): Definition: Theoretical basis: Assumption(s): Definition: Theoretical basis: Assumption(s): Definition: Theoretical basis: Assumption(s): Coupling Between Object (CBO) CBO for a class is a count of the number of non-inheritance related couples with other classes. CBO relates to the notion that an object is coupled to another object if two objects act upon each other, i.e., methods of one use methods or instance variables of another. The higher the CBO of a class is, the more difficult is reusing in another application and the more complex is the testing of that class. Response For a Class (RFC) RFC = RS where RS is the response set for the class. The response set for the class can be expressed as: RS=M i U alln {R i}, where M i = all methods in the class and {R i} = set of methods called by M i The response set is a set of methods available to the object, and its cardinality is a measure of the attributes of an object; Since it specifically includes methods called from outside the object, it is also a measure of communication between objects. - The larger the RFC is the more complex is the class, and the harder is its maintainability (difficult to trace an error). Lack of Cohesion in Methods (LCOM) Consider a Class C l with methods M l, M 2,... M n. Let {I i} = set of instance variables used by method M i. There are n such sets {I 1},... {I n}. LCOM = The number of disjoint sets formed by the intersection of the n sets. This uses the notion of degree of similarity of methods. The degree of similarity for the methods in class C l is given by: σ () = {I 1} {I 2} {I n}. If there are no common instance variables, the degree of similarity is zero. However, this does not distinguish between the case where each of the methods operates on unique sets of instance variables and the case where only one method operates on a unique set of variables. The number of disjoint sets provides a measure for the disparate nature of methods in the class. Fewer disjoint sets imply greater similarity of methods. LCOM is intimately tied to the instance variables and methods of an object, and therefore is a measure of the attributes of an object. - The Lack of cohesion implies that the classes should be split into more sub-classes. - The larger the LCOM of a class is, the more difficult is its maintainability. Weighted Methods per Class (WMC) Consider a Class C l, with methods M l,... M n. Let C l,... C n be the static complexity of the methods. Then If all static complexities are considered to be unity, WMC = n, the number of methods. WMC relates directly to the definition of complexity of an object, since methods are properties of objects and complexity of an object is determined by the cardinality of its set of properties. The number of methods is, therefore, a measure of object definition as well as being attributes of an object, since attributes correspond to properties. The larger the WMC is, the more complex is the class and the greater the potential impact on children. Depth of Inheritance Tree (DIT) Depth of inheritance of the class is the DIT metric for the class. DIT relates to the notion of scope of properties. DIT is a measure of how many ancestor classes can potentially affect this class. The lower the class is; the more are its superclasses and the larger is its DIT, and therefore, the harder is the class maintainability. Number of Children (NOC) NOC = number of immediate subclasses subordinated to a class in the class hierarchy. NOC relates to the notion of scope of properties. It is a measure of how many sub-classes are going to inherit the methods of the parent class. The more a superclass has subclasses, the larger is its NOC. Copyright c 2014 SERSC 365

8 DIT and NOC are used to measure Inheritance from two perspectives. Inheritance implies dependence implicitly. In fact, DIT indicates the number of superclasses that a class has, that is, on which the class may depend on, while NOC indicates the number of direct subclasses that a class has, that is, those which may be affected by a change in the class. Since their appearance, Chidamber and Kemerer object-oriented measures are interesting for both researchers and practitioners. Several studies have been undertaken to validate Chidamber and Kemerer measures both theoretically and empirically [28, 29, 30, 31, 32, 33]. For example, Chidamber and Kemerer measures were analyzed empirically in order to assess their usefulness for practicing managers and investigate the relation between the measures and productivity, rework effort, and design effort [30], and to find out the nature of relationship of these measures with defects [33]. What to be concluded from these is that - despite the criticism - the Chidamber and Kemerer measures [31]: have still been widely cited and adopted since they are simple and intuitive to use and, as mentioned in a few experiments; have shown their usefulness in constructing prediction systems for size and number of defects; have the advantage of being available in the design stage of the software development process, when the classical size measure is not available, yet. This clearly helps developers in taking a healthy development road right from the beginning; and have the convenience that several automatic-modeling tools, such as Rational Rose, GDPro, and TOGETHER are able to compute them. All the studies focus on using Chidamber and Kemerer measures in empirical studies to validate their usefulness in evaluating the object-oriented design, and none of them focuses on analyzing their design from metrology perspectives. 4. Analysis of the Chidamber and Kemerer Measures using the Metrology As a rule of thumb, any given number does not make sense without its unit of measurement. For example, when crossing the border to Canada, American drivers are often surprised to see speed limits of 90 or 100. If they don't realize that Canadians measure speed in kilometers/hr while Americans measure it in miles/hr (1.00 mile/hr = 1.61 kilometers/hr; 60 miles/hr = 97 km/hr) they may soon be in for trouble with the law. However, if an American driver accelerates until her speedometer (measured in miles/hr) reaches 100, he/she will be traveling 38 miles/hr over the posted speed limit of 100 km/hr since a speed of 100 km/hr is equal to only 62 miles/hr. As this example illustrates, measurements without units are meaningless and may lead to serious misunderstandings. Everything that can be measured must be expressed with appropriate units [34]. The objective of Chidamber and Kemerer measures is to measure the design of objectoriented program; that is, to measure coupling between object, response for a class, lack of cohesion in methods, weighted methods per class, depth of inheritance tree, and number of children during the later-design and implementation phases. The entities that can be used to apply Chidamber and Kemerer measures are the source code itself, the algorithm of that source code, or the class diagram. The CBO measures the coupling between object classes. A class is coupling with another if the methods of one class use ( use can mean a member type, parameter type, method local variable type or cast) the methods or attributes of the other [29]. 366 Copyright c 2014 SERSC

9 Therefore, CBO is the number of other classes with which a class is coupled. It includes inheritance-based coupling, that is, coupling between classes related via inheritance. A variant of CBO, known as CBO', excludes inheritance coupling [5]. Therefore, the basic measure of CBO is completely based in checking if the object is coupled or not, so it is a logical decision and based on true or false results. So, if the result is true add one otherwise add zero, thus, there is no base unit of measurement since the value is logical (i.e., true or false), see Table 3. Table 3. Analysis of the Coupling Between Object (CBO) Measure Objective Entity Can be implemented during the design phase? Attribute Base Measure Base Unit of Measurement Computational Formula Measurement Function Derived Measure Derived Unit of Measurement Object-Oriented design measurement Source code Algorithm Class Diagram Yes, when applied to the class diagram Coupling Class Logical (True or False) CBO A = C 1 + C 2 + C C n, Where: A: a particular object, n: number of objects. C i : one if object C is coupled to the object A, zero otherwise Count of the number of non-inheritance related couples with other classes Number of non-inheritance related couples with other classes Couple The RFC measure is the response for a class coupling measure [6]. The response set of a class consists of the set M of methods of the class, and the set of methods invoked directly by the methods in M, that is, the set of methods that can potentially be executed in response to a message received by that class. A variant of RFC excludes methods indirectly invoked by a method in M [5], see Table 4. Table 4. Analysis of the Response For a Class (RFC) Measure Objective Entity Can be implemented during the design phase? Attribute Base Measure Base Unit of Measurement Computational Formula Measurement Function Derived Measure Derived Unit of Measurement Object-Oriented design measurement Source code Algorithm No Response for a class Number of Invoked methods Number of Class methods Method RS = M i U {R i } Where: M i : all methods in the class {R i }: set of methods called by M i Count Number of Distinct Methods and Constructors invoked by a particular Class Number of Distinct Methods and Constructors invoked by a particular Class Method LCOM measures the number of pairs of methods in the class that have no attributes in common, minus the number of pairs of methods that do. If the difference is negative, the measure value is set to zero. For more details, see Table 5 below. Copyright c 2014 SERSC 367

10 Table 5. Analysis of the Lack of Cohesion in Methods (LCOM) Measure Objective Entity Can be implemented during the design phase? Attribute Base Measure Base Unit of Measurement Computational Formula Measurement Function Derived Measure Derived Unit of Measurement Object-Oriented design measurement Source code Algorithm No Lack of Cohesion in Methods - Number of pair methods accessing no common instance variables - Number of pair methods sharing the same instance variables - Pairs of methods which do not share instance variable - Pairs of methods that share instance variables LCOM = A - B Where: A: the number of pairs of methods which do not share instance variable of the class B: the number of pairs of methods that share instance variables of that class Count the number of not connected method pairs in a particular class representing independent parts having no cohesion Number of not connected method pairs in a particular class representing independent parts having no cohesion Pairs of Methods Generally, the WMC (Weighted Methods per Class) measure can be classified as a traditional complexity measure. It is a count of the methods in a class. It has been suggested that neither methods from ancestor classes nor friends in C++ be counted [35, 36]. The developers of this measure leave the weighting scheme as an implementation decision [6]. Some authors weight it using Cyclomatic s complexity [2]. However, others do not adopt a weighting scheme [36, 37]. In general, if Cyclomatic s complexity is used for weighting, then WMC cannot be collected at design phase. Alternatively, if no weighting scheme is used, then WMC becomes simply a size measure, that is, the number of methods implemented in a class, see Table 6 for the metrology analysis. Table 6. Analysis of the Weighted Methods per Class (WMC) Measure Objective Entity Can be implemented during the design phase? Attribute Base Measure Base Unit of Measurement Object-Oriented design measurement Source code Algorithm Class Diagram Yes, if no weighting scheme is used No, if Cyclomatic s complexity is used for weighting Weighted method per class Number of methods in a class complexity Computational Formula, Where: n: the number of methods within a particular class c i : the complexity for each method within that class Measurement Function Sum all the methods complexities within a particular class Derived Measure Complexities of all class methods Derived Unit of Measurement Weighted Methods per Class The DIT measure is defined as the length of the longest path from a particular class to its root in the inheritance hierarchy. The derived unit of measurement is Depth since the resulted number reflects the depth of inheritance tree, see Table Copyright c 2014 SERSC

11 Table 7. Analysis of the Depth of Inheritance Tree (DIT) Measure Objective Entity Can be implemented during the design phase? Attribute Base Measure Base Unit of Measurement Computational Formula Measurement Function Derived Measure Derived Unit of Measurement Object-Oriented design measurement Source code Algorithm Class Diagram Yes, when applied to the class diagram Depth of inheritance tree Number of classes (ancestor that a class have) Ancestor Classes None Identify the maximum length of the path from a particular class to the root of the inheritance tree the depth of the inheritance tree for a particular class Depth For the NOC measure, this measure counts the number of classes that inherit from a particular class, that is, the number of class in the inheritance tree down from that class. Again, it based on a logical (true or false) decision to decide whether the class is a subordinated for the intended class or not. Thus, the base unit of measurement is logical, and based on it the derived measure will be consist of the number of true values, see Table 8 for more details. Table 8. Analysis of the Number of Children (NOC) Measure Objective Entity Can be implemented during the design phase? Attribute Base Measure Base Unit of Measurement Computational Formula Measurement Function Derived Measure Derived Unit of Measurement Object-Oriented design measurement Source code Algorithm Class Diagram Yes, when applied to the class diagram Number of children Class Logical (True or False) NOC A = C 1 + C 2 + C C n Where: A: a particular class, n: number of classes. C i : one if class C is a subclass subordinated to the class A, zero otherwise. Count the number of children for a particular class Number of children for a particular class Children Tables 3 to 8 summarize the findings of the analysis of the Chidamber and Kemerer measures from the metrology perspective. We can note that each Chidamber and Kemerer measure: Has a value from zero to N (integer positive). Copyright c 2014 SERSC 369

12 Can measure a specific attribute. Not always can be implemented during the design phase. Has a measurement function to produce derived measure. Has derived measures. Has derived unit of measurement. 5. Discussion This paper focused on software product measures, in particular, the object-oriented measures. Furthermore, it analyzed the design of a well-known and one of the most used object-oriented measures proposed by Chidamber and Kemerer. In addition, this paper investigated the extent to which these set of measures address the metrology concepts related to the software measurement design. In practice, although it is not usual in software measurement to take into account the metrology concepts, many studies have been done recently in order to analyze the design of well-known and used measures from metrology concepts [2-7,]. In the other hand, the Chidamber and Kemerer object-oriented measures since their appearances have gained researchers and practitioners interest. As cited in this paper, several studies have been undertaken to validate Chidamber and Kemerer measures both theoretically and empirically. However, none of these studies focused on analyzing the design of Chidamber and Kemerer measures from metrology perspectives; which is the subject of that paper. What can be noted here from this analysis is that all Chidamber and Kemerer measures have base measures. However, Abran [9] stated that the distinction between a base attribute and a derived one is based on the way the attribute is defined, which is independent of the way it will be measured. That is, in a system of attributes, an attribute is a base attribute if it is defined by convention as functionally independent of the other attributes, but it can also be used to define other attributes ; this is the fact of the base measures (Class and method) identified for Chidamber and Kemerer measures suite. In addition, Abran et al. [38] stated that the addition of base measures of the same type does not lead to derived measures. For example, the addition of houses (of the same types or different types) gives a total number of houses. However, this not always true because for example, adding five red houses to 3 black houses will give us 8 houses, in this example we lost some details about the houses (i.e., the houses color). Furthermore, from Tables 3 to 8 above, we can note that there are derived measures and derived units of measurement for all of Chidamber and Kemerer measures, some of such derived units are completely based on the name of the measure, for example, the measure WMC has weighted methods per class. In summary, all Chidamber and Kemerer measures are functions of the counts of a particular concept of the object-oriented paradigm, such as, class and method depending on the objective of the measures and the attributes to be measured. Moreover, each Chidamber and Kemerer measure varies from zero to N (integer positive) and has valid base unit of measurement to measure a specific attribute and applies to design of object-oriented program. However, what is missing in the Chidamber and Kemerer measures is the distinction of measurement method and measurement procedure is not well defined in terms of metrology concepts, and the computational formula for some measures is unclear. Furthermore, the following comments can be concluded: The base units of measurement for the Response For a Class (RFC) measure are Number of Invoked methods and Number of Class methods. Whereas, the Derived unit of measurement for RFC is method. However, in this way we lost the 370 Copyright c 2014 SERSC

13 details of the methods (i.e., invoked and class). The same is applied to the Coupling Between Object (CBO) measure and the Lack of Cohesion in Methods (LCOM) measure. For the Analysis of the Depth of Inheritance Tree (DIT) measure there is no any relationship between the base and derived units of measurements. Thus, how it comes to derive the depth derived unit of measurement from the Number of classes base unit of measurement! The same is applied to the Number of Children (NOC) measure. References [1] L. C. Briand, J. Wust and H. Lounis, Using Coupling Measurement for Impact Analysis in Object Oriented Systems, Proceedings of the IEEE International Conference on Software Maintenance (ICSM 99), Oxford, England, UK, (1999) August 30-September 3, pp [2] W. Li and S. Henry, Maintenance Metrics for the Object-Oriented Paradigm, Proceedings of the 1st International Software Metrics Symposium (ISMS 93), Baltimore, Maryland, USA, (1993) May 21-22, pp [3] L. C.Briand, J. Daly and J. Wuest, A Unified Framework for Cohesion Measurement in Object-Oriented Systems, Empirical Software Engineering, vol. 3, no. 1, (1998). pp [4] L. C. Briand, J. Daly and J. Wuest, A Unified Framework for Coupling Measurement in Object-Oriented Systems, IEEE Transactions on Software Engineering, vol. 25, no. 1, (1999), pp [5] S. R. Chidamber and C. F. Kemerer, Towards a Metrics Suite for Object-Oriented Design, Proceedings of the 6th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 91), October 6-11, Phoenix, Arizona, USA, (1991), pp [6] S. R. Chidamber and C. F. Kemerer, A Metrics Suite for Object- Oriented Design, IEEE Transaction on Software Engineering, vol. 20, no. 6, (1994), pp [7] F. B. Abreu, M. Goulao and R. Esteves, Toward the Design Quality Evaluation of Object-Oriented Software Systems, Proceedings of the 5th International Conference on Software Quality, Austin, Texas, USA, (1995) October 23-26, pp [8] C. Archer and M. Stinson, Object-Oriented Software Measures, Technical Report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, USA, (1995). [9] A. Abran, Software Metrics and software Metrology, IEEE Computer Society and John Wiley & Sons, Inc., New York, USA, (2010). [10] J.-P. Jacquet and A. Abran, From Software Metrics to Software Measurement Methods: A Process Model, Proceedings of the 3rd International Symposium and Forum on Software Engineering Standards (ISESS'97), June 1-6, Creek, CA, USA, (1997), pp [11] ISO/IEC, Guide 99: International Vocabulary of Metrology - Basic and General Concepts and Associated Terms (VIM), International Organization for Standardization, Geneva, Switzerland, (2007). [12] A. Abran and A. Sellami, Initial Modeling of the Measurement Concepts in the ISO, Vocabulary of Terms in Metrology, Proceedings of the 12th International Workshop on Software Measurement (IWSM 02), October 7-9, Magdeburg, Germany, (2002), pp [13] A. Abran, R. E. Al-Qutaish and J. J. Cuadrado-Gallego, Analysis of the ISO 9126 on Software Product Quality Evaluation from the Metrology and ISO Perspectives, WSEAS Transactions on Computers, vol. 5, no. 11, (2006), pp [14] ISO/IEC, ISO/IEC IS 15939: Software Engineering-Software Measurement Process, International Organization for Standardization, Geneva, Switzerland, (2002). [15] A. Abran, J.-M. Desharnais and J. J. Cuadrado-Gallego, Metrology and Quantitative Analysis in ISO 15939, Proceedings of the International Conference on Software Engineering Research and Practice (SERP09), Las Vegas, Nevada, USA, (2009) July 13-16, pp [16] R. E. Al-Qutaish and A. Abran, A Maturity Model of Software Product Quality, Journal of Research and Practice in Information Technology, vol. 43, no. 4, (2011), pp [17] A. Abran, M. Lopez and N. Habra, An Analysis of the McCabe Cyclomatic s Complexity Number, Proceedings of the 14th International Workshop on Software Measurement (IWSM'04), Berlin, Germany, (2004) November 2-5, pp [18] R. E. Al-Qutaish and A. Abran, An Analysis of the Designs and the Definitions of the Halstead's Metrics, Proceedings of the 15th International Workshop on Software Measurement (IWSM'2005), Montreal, Quebec, Canada, (2005) September 12-14, pp Copyright c 2014 SERSC 371

14 [19] A. Abran and A. Sellami, Analysis of Software Measures Using Metrology Concepts - ISO Case Study, Proceedings of the International Workshop on Software Audits and Metrics (SAM 04) at the 6th International Conference on Enterprise Information Systems (ICEIS'04), Porto, Portugal, (2004) April 14-17, pp [20] J. Ouwerkerk and A. Abran, Evaluation of the Design of Use Case Points (UCS), Proceedings of the International Conference on Software Process and Product Measurement (MENSURA'06), Cadiz, Spain, (2006) November 6-8, pp [21] R. E. Al-Qutaish, SPQ MM : A Software Product Quality Maturity Model using ISO/IEEE Standards, Metrology, and Sigma Concepts, Ph.D. Thesis, Dept. of Software Engineering and IT, School of Higher Technology (École de Technologie Supérieure - ÉTS), University of Québec, Montréal, Québec, Canada, (2007). [22] L. Cheikhi, Modèles de Qualitédu Logiciel: Estimation de l'impact du Changement dans les Programmes Orientés Objets en utilisant les Algorithmes d'apprentissage, Editions Universitaires Européennes, Sarrebruck, Germany, (2011). [23] N. Wilde and R. Huitt, Maintenance Support for Object- Oriented Programs, IEEE Transaction Software Engineering, vol. 18, no. 12, (1992), pp [24] L. Li and A. J. Offutt, Algorithmic Analysis of the Impact of Changes to Object- Oriented Software, Proceedings of the IEEE International Conference on Software Maintenance (ICSM 96), Monterey, California, USA, (1996) November 4-8, pp [25] Y.-G. Guéhéneuc and H. Albin-Amiot, Recovering Binary Class Relationships: Putting Icing on the UML Cake, Proceedings of the 19th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 04), Vancouver, British Columbia, Canada, (2004) October 24-28, pp [26] N. Herr and J. B. Cunningham, Hands-on Chemistry Activities with Real-life Applications, John Wiley & Sons Inc., New York, USA, (1999). [27] G. Booch, Object-Oriented Analysis and Design, 2nd Edition, Benjamin / Cummings, Redwood City, CA, USA, (1994). [28] S. R. Chidamber, D. P. Darcy and C. F. Kemerer, Managerial Use of Metrics for Object-Oriented Software: An Exploratory Analysis, IEEE Transactions on Software Engineering, vol. 24, no. 8, (1998), pp [29] K. El-Emam, Object-Oriented Metrics: A Review of Theory and Practice, Erdogmus, H. & Tanir, O. (Eds.), Advances in Software Engineering, Springer-Verlag, New York, USA, (2002), pp [30] D. P. Darcy and C. F. Kemerer, OO Metrics in Practice, IEEE Software, vol. 22, no. 6, (2005), pp [31] G. Succi, W. Pedrycz, S. Djokic, P. Zuliani and B. Russo, An Empirical Exploration of the Distributions of the Chidamber and Kemerer Object-Oriented Metrics Suite, Empirical Software Engineering, vol. 10, no. 1, (2005), pp [32] A. Kaur, S. Singh, K. S. Kahlon and P. S. Sandhu, Empirical Analysis of CK & MOOD Metric Suite, International Journal of Innovation, Management and Technology, vol. 1, no. 5, (2010), pp [33] M. P. Thapaliyal and G. Verma, Software Defects and Object Oriented Metrics-An Empirical Analysis, International Journal of Computer Applications, vol. 9, no. 5, (2010), pp [34] J. McQuillan and J. Power, A Definition of the Chidamber and Kemerer Metrics Suite for UML, Technical Report, National University of Ireland, Galway, Ireland, (2006). [35] S. R. Chidamber and C. F. Kemerer, Authors' Reply, IEEE Transactions on Software Engineering, vol. 21, no. 3, (1995), pp [36] V. Basili, L. Briand and W. Melo, A Validation of Object-Oriented Design Metrics as Quality Indicators, IEEE Transactions on Software Engineering, vol. 22, no. 10, (1996), pp [37] M. H. Tang, M. H. Kao and M. H. Chen, An Empirical Study on Object-Oriented Metrics, Proceedings of the 6th International Conference on Software Metrics Symposium (ICSM 99), Boca Raton, Florida, USA, (1999) November 4-6, pp [38] A. Abran, J.-M. Desharnais, and J. J. Cuadrado-Gallego, Measurement and Quantification are not the same: ISO and ISO 9126, Journal of Software: Evolution and Process, vol. 24, no. 5, (2012), pp Authors Laila Cheikhi, she is a Professor at Computer Science and Systems Analysis School (ENSIAS, Rabat, Morocco). She received a M.Sc. (2004) from University of Montréal and Ph.D. (2008) from ETS, University of Quebec at Montreal, and Both in software engineering. She has over eight years of experience in computer engineering at the Ministry of Finance of Morocco. Her research interests include software quality models, software metrics, software 372 Copyright c 2014 SERSC

15 engineering ISO standards, software product and process quality, software engineering principles and data analysis. Rafa E. Al-Qutaish, he is an Associate Professor at École de Technologie Supérieure (ÉTS), University of Québec, Canada. He received B.Sc. in Computer Science and M.Sc. in Software Engineering degrees in 1993 and 1998, respectively. Also, he received the Ph.D. degree in Software Engineering from the School of Higher Technology (ÉTS), University of Québec, Canada in His research interests are in Software Measurement, Software Product Quality, Software Engineering Standardization, Reverse Engineering, Software Comprehension and Maintenance, and Compiler Construction. Dr. Al-Qutaish is a senior member of the IEEE & IEEE-CS, and also a senior member of the IACSIT. Ali Idri, he is a Professor at Computer Science and Systems Analysis School (ENSIAS, Rabat, Morocco). He received DEA (Master) (1994) and Doctorate of 3rd Cycle (1997) degrees in Computer Science, both from the University Mohamed V of Rabat. He has received his Ph.D. (2003) in Cognitive Computer Sciences from ETS, University of Quebec at Montreal. His research interests include software cost estimation, software metrics, fuzzy logic, neural networks, genetic algorithms and information sciences. Amae Sellami, she holds a PhD in Software Engineering (2005) from École de Technologie Supérieure (ETS) - Universitédu Québec (Montréal, Canada) and Master's degree in Management Information from Universitédu Québec àmontréal. Since 2006, she is an Assistant Professor at the Institut Supérieur d'informatique et de Multimédia de Sfax (ISIMS) - University of Sfax (Tunisia). Her research interests include Software Measurement and Metrology, Software Quality, and Software Project Management. Copyright c 2014 SERSC 373

16 374 Copyright c 2014 SERSC