Research Article
a
December
2017
Computer Science and Software Engineering
ISSN: 2277-128X (Volume-7, Issue-12)
An Analytical Evolution of Usability for Object Oriented
Metrics
Dr. Sanjeev Punia1, Dr. Kuldeep Malik2, Harendra Singh3
1
Department of Computer Science, JIMSEMTC, Greater Noida, Uttar Pradesh, India
2
Department of Computer Science, ITS Engineering College, Greater Noida, Uttar Pradesh, India
3
Department of Computer Science, GNIOT, Greater Noida, Uttar Pradesh, India
Abstract: Object oriented design metrics are most essential part of software development environment and being more popular day by day. This study focus on a set of object oriented metrics that can be used to measure the quality of an object oriented design. The object oriented design metrics focus on the measurements of class and design characteristics. These measurements permit designers to access the software in the early stage of the process and changes accordingly to reduce complexity and improve the continuing capability of the design. This paper summarizes the existing metrics those guide the designers to support their design. We categorized and discussed metrics in such a way that novice designers can apply metrics in their design as needed.
Keywords: Object-Oriented (OO), Maintainability Index (MI), Metrics for Object-Oriented Software Engineering (MOOSE), Extended Metrics for Object-Oriented Software Engineering (EMOOSE), Metrics for Object-Oriented Design (MOOD), Quality Model for Object-Oriented Design (QMOOD)
I. INTRODUCTION
Several researchers have proposed a variety of criteria for evaluation and validation of software metric adhere. Kaner C. [1] stated that validation can be proved through measurement theory However, most of the existing evaluation and validation criteria were proposed at the time of procedural languages domination. Basili and Briand [2] explained that only efforts has been made to develop a model/framework to measure software complexity in object oriented domain after the adaptation of object oriented languages by the software industry.
Weyuker [3] proposed some proposals for object oriented languages however most of them cover only specific features of evaluation. Zuse [4] use mathematical properties for object oriented metrics based on the principles of measurement theory. The lack of proper guidelines for evaluation and validation of object oriented metrics motivate us to develop a new evaluation criterion which includes all the features required to evaluate the object oriented metrics. First we analyzed available validation and evaluation criteria by extracting their important features to achieve the goal then we suggest additions or modifications in the formal way. The validity of the proposed model is evaluated by applying eleven different well-known object oriented metrics.
Wang [5] stated that object oriented metrics are the measurement tools to achieve high quality in software process and product. However, in general, software measurement has not yet achieved the maturity degree needed and it needs more standardization. Weyuker et. al. [6] discussed on the application of measurement theory in software engineering named as Weyuker’s properties. We worked in software measurement related area and presented several papers also. We presented a paper on the usefulness of Weyuker’s properties for procedural languages.
In another work, Sharma and Joshi [7] analyzed the use of Weyuker’s properties for object oriented metrics. Mishra [8] analyzed the current situation of standard measurement activities in small and medium software companies. Pfleeger S. L. and Kitchenham [9] proposed a model based on empirical validation situation of software complexity measures in practice. The applicability of measurement theory on software complexity measures is also investigated in one of our previous works.
In the present paper we analyze the present practices used for evaluation and validation of object oriented metrics and accordingly present a model for evaluating object oriented metrics. We also propose a framework for evaluating software complexity measures. Specifically, this paper is for object oriented metrics since object oriented languages do not share same features with procedural languages.
II. LITERATURE SURVEY
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 61-67
some expert evaluation. They compare most of the software maintainability assessment model and compared with each other models. Schach and Binkley [11] collect the maintenance data for the development of project written in any language like C, C++, COBOL etc and produce a modules interaction level between low coupling subjected to fewer maintenance effort, maintenance fault and failures.
Tolga et. al. [12] proposed linear prediction model evaluated by some industrial software system to estimate the large system maintainability. It also identifies fault prone models to define impact rate, effort and error rate. R. Marinescu [13] prescribed object-oriented design matrix for ease of maintenance to provide better understandability and modifiability. It describes three discriminate techniques (correlation between maintainability and structural complexity), weighted score level technique (combination of understanding and modifiability) and weighted predicate level technology (combination of predicate understandability and modifiability). Khan and Rizvi [14] proposed MEMOOD model to improve the maintainability or understandability of class diagram and consequently the maintainability in final software. Gautam et. al. [15] describe that the compound MEMOOD model is better the MEMOOD model to determine the maintainability of class diagram in terms of their understandability, modifiability, scalability and level of complexity. Walter et. al. [16] suggested a new classification framework for the TAPROOT. This framework was defined with two category and granularity independent vectors. The six categories of object-oriented metrics were defined as design metrics, complexitymetrics, size metrics, quality metrics, productivity metrics and reuse metrics. They also proposed three levels of granularity i.e. software, class and methods but no empirical/theoretical base for the metrics was provided.
Alshayeb et. al. [17] proposed two iterative procedures for the pragmatic study of object oriented metrics as short-cycled agile and long cycled framework evolution process. The result shows that the design efforts and source code lines added, changed and deleted were triumphantly predicted by object-oriented metrics in short-cycled agile process where same features were not successfully predicted in long-cycled framework process. This shows that the design and implementation changes during development iterations can be predicted by object-oriented metrics but the same cannot be the case with long-term development of an established system.
III. CLASSIFICATION OF OBJECT-ORIENTED METRICS 3.1 Metrics for Object-Oriented Software Engineering (MOOSE):
Kemerer and Shyam [18] proposed many metrics that generates a significant amount of interest and currently the most well known measurements suite for object-oriented software. These metrics suite consists of six metrics that assess different characteristics of the object-oriented design as:
(i) Weighted Methods per Class (WMC): WMC metric is used to measure the sum of complexity of methods in a class. This is a predictor of the time and effort required to develop and maintain a class that uses the number of methods with complexity. A large number of methods in a class may have potentially a larger impact on the children of a class since the methods in the parent will be inherited by the child. The complexity of the class may be calculated by the cyclomatic complexity of the methods also. The high value of WMC indicates that the class is more complex as compare to the low values.
(ii) Depth of Inheritance Tree (DIT): DIT metric is used to find the length of the maximum path from the root node to the end node of the tree. DIT represents the complexity and the behavior of design and reuse potential of a class. Thus it can be hard to understand a system with many inheritance layers. On the other hand, a large DIT value indicates that many methods might be reused. A deeper class hierarchy indicates that more inherited methods make the behavior prediction of a class more complex. The deeper tree indicates that there is high complexity in the design because all of the involved facts contained more methods and class. A deep hierarchy of the class may indicate a possibility of reusing the inherited method.
(iii) Number of Children (NOC): According to Lorenz and Kidd [19] the Number of Children (NOC) metric may be defined for the immediate sub-class that is coordinated by the class hierarchy form. These points show that NOC is used to measure that no of subclasses those are going to inherit the methods of the parent class. The greater is the number of children, the greater the potential for reuse since inheritance is a form of reuse. The greater is the number of children, the greater the likelihood of improper abstraction of the parent class. The number of children also gave an idea of the potential influence for the design class.
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 61-67
(v) Response for Class (RFC): RFC is defined as set of executed methods for received messages response by class object. Large values make the testing and debugging of the object complicated so tester requires more knowledge of the functionality. The larger RFC value makes the class more complex and a worst case scenario RFC value helps in the time estimation for testing the class.
(vi) Lack of Cohesion in Methods (LCOM): LCOM is used to count the number of disjoints methods pairs except the number of similar method pairs used. The disjoint methods have no common instance variables in the methods while the similar methods have at least one common instance variable. It is used to measuring the pairs of methods within a class those use the same instance variable. Cohesiveness increases the encapsulation within a class hence cohesion should be high as lack of cohesion may split the class in two or more than two sub classes. Low cohesion in methods increases the complexity when it increases the error proneness during the development.
3.2 Extended Metrics For Object-Oriented Software Engineering (EMOOSE):
Chris and Shyam [20] proposed the MOOSE model metrics. These models are described as:
(i) Message Pass Coupling (MPC): It is used to count the number of message sent by the class operations.
(ii) Data Abstraction Coupling (DAC): It is used to count the number of aggregated currently used classes and defined the data abstraction coupling also.
(iii)Number of Methods (NOM): It is used to count the number of operations that are local to the class i.e. only those class operation which can give the number of methods for its measure.
(iv)Size1: It is used to find the number of line of code.
(v) Size2: It is used to count the number of local attributes & the number of operation defined in the class.
3.3 Metrics for Object-Oriented Design (MOOD):
Abreu et. al. [21] defined object-oriented design metrics. MOOD refers a structural model of the object oriented paradigm like encapsulation as (MHF, AHF), inheritance (MIF, AIF), polymorphism (POF) and message passing (COF). Each metrics express the measure where numerator defines the actual use of any one of the feature for a particular design. In MOOD metrics model have two main features as attributes and methods. Attributes are used to represent the status of object in the system and methods are used to maintain or modify several kinds of the objects status. These metrics are defined as:
(i) Method Hiding Factor (MHF): MHF is defined as the ratio of the sum of all invisible methods defined in all classes to the total number of methods defined in the system under consideration. The invisibility of a method is the percentage of the total classes from which this method is not visible.
(ii) Attribute Hiding Factor (AHF): AHF is defined as the ratio of the sum of all invisible attributes defined in all classes to the total number of attributes defined in the system under consideration.
(iii) Method Inheritance Factor (MIF): MIF is defined as the ratio of the sum of the inherited methods in all classes of the system under consideration to the total number of available methods (locally defined plus inherited) for all classes.
(iv) Attribute Inheritance Factor (AIF): AIF is defined as the ratio of the sum of inherited attributes in all classes of the system under consideration to the total number of available attributes (locally defined plus inherited) for all classes.
(v) Polymorphism Factor (PF): PF is defined as the ratio of the actual number of possible different polymorphic situation. MIF & AIF are used to measure the inheritance of the class & provide the classes similarity also. CF is used to measure the coupling between the classes. There are two types of coupling as static & dynamic coupling. The static and dynamic coupling increases the class complexity, reduce the encapsulation and reuse potentially for better maintainability. Software developers always avoid the high coupling factor for object oriented system. Polymorphism potential of the classes is used to measure the polymorphism in the particular class that arises from inheritance.
3.4 Goal Question Metrics (GQM):
V. L. Basili [22] developed GQM approach that was defined originally for evaluating defects for a set of projects in NASA Goddard Space Flight Center environment. He also provided the set of sequence which are helpful for the designers. The goal of GQM is to express the templates meaning like purpose, perspective and environment. These define a set of guidelines to propose driving question and metrics. It provides a framework involving three steps:
(i) List major goals of the development or maintenance project.
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 61-67
Goal (Conceptual level): The goal of an object is defined for a variety of reasons with respect to various quality models from various points of view with respect to a particular environment. The objects of measurement are products, processes and resources.
Question (Operational level): A set of questions used to characterize the assessment or achievement way of a specific goal that is going to be performed based on some characterizing model.
Metric (Quantitative level): A set of data is associated with every question in order to answer quantitatively. This data can be objectives or subjective. It depends only on the measured objects and not on the viewport. For example, number of versions of a document, staff hours spent on a task and size of a program.
3.5 Quality Model for Object-Oriented Design (QMOOD):
Bansiya and Davis [23] proposed QMOOD that establishes a clearly defined and empirically validated model to assess object-oriented design quality attributes such as understandability and reusability shown in figure 1. QMOOD relates with structural object-oriented design properties such as encapsulation and coupling through mathematical formulas. The QMOOD model consists of six equations that establish relationship between six object-oriented design quality attributes (reusability, flexibility, understandability, functionality, extendibility and effectiveness) and eleven design properties.
Bansiya’s [23]
explained complete description for QMOOD in his thesis and classify QMOOD metrics further into two measures as:
System Measures: System measures describe DSC (Design Size in Metrics), NOH (Number of Hierarchies), NIC (Number of Independent Classes), NSI (Number of Single Inheritance), NMI (Number of Multiple Inheritance), NNC (Number of Internal Classes), NAC (Number of Abstract Classes), NLC (Number of Leaf Classes), ADI (Average Depth of Inheritance), AWI (Average Width of Classes), ANA (Average Number of Ancestors) metrics.
Class Measures: Class measure describe MFM (Measure of Functional Modularity), MFA (Measure of Functional Abstraction), MAA (Measure of Attribute Abstraction), MAT (Measure of Abstraction Type), MOA (Measure of Aggregation Type), MOS (Measure of Association), MRM (Modeled Relationship Measure), DAM (Data Access Metrics), OAM (Operation Access Metrics), MAM (Member Access Metrics), DOI (Depth of Inheritance), NOC (Number of Children), NOA (Number of Ancestor), NOM (Number of Methods), CIS (Class Interface Size), NOI (Number of Inline Method), NOP (Number of Polymorphic Method), NOO (Number of Overloaded Operators), NPT (Number of Unique Parameter Types), NPM (Number of Parameter per Method), NOA (Number of Attributes), NAD (Number of Abstract Data Types), NRA (Number of Reference Attributes), NPA ( Number of Public Attributes), CSB (Class Size in Bytes), CSM (Class Size in Metrics), CAM (Cohesion Among Methods of class), DCC (Direct Class Coupling), MCC (Maximum Class Coupling), DAC (Direct Attribute based Coupling), MAC (Maximum Attribute based Coupling), DPC (Directed Parameter based Coupling), MPC (Maximum Parameter based Coupling), VOM (Virtual ability Of Method), CEC (Class Entropy Complexity), CCN (Class Complexity based on Data), CCP (Class Complexity based on method Parameter), CCM (Class Complexity based on Members) metrics.
Figure 1: QMOOD Metrics
Class
Number of attributes
Number of methods
It show the number of super class in terms of ration of sub
class
Number of attributes per class
If shows number of classes in terms of ratio of super class
It calculates the average of depth of inheritance for the
class in the system
Number of public methods in a class
Number of attributes defined in a class in terms of ratio of private and protected attributes Reuse
Coupling Inheritance
Information Hiding
Number of modules
Reuse Ration
Specification ratio
Avg. No. of Ancestors Ancestors
Class Interface Size
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 61-67
3.5 LI W. METRICS
Li et al. [24] proposed six metrics as Number of Ancestor Classes (NAC), Number of Local Methods (NLM), Class Method Complexity (CMC), Number of Descendent Classes (NDC), Coupling Through Abstract data type (CTA) and Coupling Through Message passing (CTM).
(i) Number of Ancestor Classes (NAC): NAC metric proposed an alternative to the DIT metric that measures the total number of ancestor classes from an inherited class in the class inheritance hierarchy. The theoretical basis and viewpoints both are same as the DIT metric. In this, the unit for the NAC metric is “class” which is justified
by the number of NAC metric captures attribute in other inherited classes environments.
(ii) Number of Local Methods (NLM): NLM is defined as the number of the local methods in a class which are accessible outside the class. It measures the attributes of a class intends to capture by WMC metric. The theoretical basis and viewpoints are different from the WMC metric. The theoretical basis describes the attribute of a class that the NLM metric captures. This attribute is for the usage of the class in an object-oriented design because it indicates the size of a class’s local interface to use the other class. They stated three viewpoints for NLM metric as following:
1) The NLM metric is directly linked to a programmer’s effort when a class is reused in an object-oriented design. More effort is required to comprehend the class behavior w.r.t. more local methods in the class. 2) The larger the local interface of a class, the more effort is needed to design, implement, test and maintain
the class.
3) The larger the local interface of a class, the more influence the class has on its descendent classes.
(iii) Class Method Complexity (CMC): CMC metric is defined as the summation of the internal structural complexity of all local methods. The CMC metric’s theoretical basis and viewpoints are significantly different from WMC metric. The NLM and CMC metrics are fundamentally different as they capture two independent attributes of a class. These two metrics affect the effort required to design, implement, test and maintain a class. (iv) Number of Descendent Classes (NDC): NDC metric is an alternative to NOC and defined as the total number
of descendent classes (subclass) of a class. The stated theoretical basis and viewpoints indicate that NOC metric measures the scope of influence of the class on its sub classes because of inheritance. Li et al. [24] claimed that the NDC metric captures the classes attribute better than NOC.
(v) Coupling Through Abstract data Type (CTA): CTA metric is defined as the total number of used classes as abstract data types in the data-attribute declaration of a class. Two classes are coupled when one class uses the other class as an abstract data type. The theoretical view was that the CTA metric relates to the notion of class coupling through the use of abstract data types. This metric gives no of classes need to services a class in order to provide its own service to others.
(vi) Coupling Through Message Passing (CTM): CTM defined as the number of different messages sent out from a class to other classes excluding the messages sent to the objects created as local objects in the local methods of the class. Two classes can be coupled as one class sends a message to an object of another class through inheritance or abstract data type. Theoretical view gives that the CTM metric relates to the notion of message passing in object-oriented programming. The CTM metric gives an indication of how many methods of other classes are needed to fulfill the class own functionality.
3.6 SATC’s Metrics
Rosenberg Linda [25] proposed select object oriented metrics that supports the goal of measuring the code, quality and result. They showed that many object-oriented metrics due to lack of theoretical basis can be validated. These metrics may be used to evaluate the object oriented concepts like methods, coupling and inheritance. The main focus is on the internal and external (both) efficiency measures of the psychological complexity factors that affect the ability of the programmer. They proposed two traditional and six new metrics for the object-oriented system metrics-
Traditional Metrics
(i) Cyclomatic Complexity (CC): Cyclomatic Complexity is used to measure the complexity of an algorithm of a class method. Cyclomatic Complexity of methods can be combined with other methods to measure the complexity of the class. Generally, this is only used for the evaluation of quality attribute complexity.
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 61-67
New Object Oriented Metrics
The six new object oriented system metrics are classified as:
(i) Weight Method per Class (WMC): It is used to count the methods implemented within a class. The number of methods and complexities involved as predictors. It also finds the time and effort required to develop and maintain the class.
(ii) Response for a Class (RFC): It is used to calculate the class combination complexity through the number of methods and the communication of methods with other classes. This is used to evaluate the understandability and testability.
(iii) Lack of Cohesion of Method (LCOM): Cohesion is a degree of methods through which all the methods of the class are inter-related with each other and provide a well bounded behavior. It also measures the degree of methods similarity by data inputs variables and attributes. Generally, it is used to evaluate the efficiency and reusability.
(iv) Depth of Inheritance Tree (DIT): Inheritance is a relationship between the class that enables the programmer to use previously defined object including the operators and variables. It also helps to find the inheritance depth of the tree from current node to the ancestor node. It is also used to evaluate the reusability, efficiency, understandability and testability.
(v) Number of Children (NOC): This is used to measure the subclass subordinate to a class in the hierarchy. Greater the number of children means greater reusability and inheritance i.e. in the form of reuse. Generally, it is used to measure efficiency, testability and reusability.
SATC focused on some selected criteria for the object oriented metrics as: (i) Efficiency of constructor design to decrease architecture complexity. (ii) Specification of design and enhancement in testing structure
(iii) Increase capacity of psychological complexity.
IV. CONCLUSION AND FUTURE ASPECT
This paper introduces the basic metric suite for object-oriented design. The need for such metrics is particularly acute when an organization is adopting a new technology. It is different form universally valid object-oriented quality measures. The models could be devised to fit/suit for all languages in all development environments and for all different kind of application domains also. Therefore measures and models should be investigated as well as validated locally in each studied environment. It should be kept in mind that metrics are only guidelines and not rules. Metrics are guidelines that give an indication of the progress and design quality of a project.
REFERENCES
[1] Kaner C. “New Software Quality Metrics Methodology Standards Fills Measurement Needs” IEEE Computer
Society Washington, pp. 15-18, April 2017.
[2] Basili V. R. and Briand L. C. “Property-based Software Engineering Measurement” IEEE Transactions on
Software Engineering, pp. 27-29, September 2017.
[3] Weyuker R. “Towards a Model for Object-oriented Design Measurement” in Proceedings of International
ECOOP Workshop on Quantitative Approaches in Object-oriented Software Engineering, pp. 171-184, September 2016.
[4] Zuse H. “Foundations of Object-oriented Software Measures” in Proceedings of 3rd International Symposium
on Software Metrics-IEEE Computer Society, Washington-USA, pp. 7-8, 2017.
[5] Wang Y. “The Measurement Theory for Software Engineering” in Proceedings Canadian Conference on
Electrical and Computer Engineering, pp. 132-134, 2016.
[6] Weyuker E. J. and Fenton N. “Evaluating software complexity measures” IEEE Transaction on Software
Complexity Measure, pp. 15-18, 2017.
[7] Sharma N. and Joshi P. “Applicability of Weyuker’s Property to OO Metrics” IEEE Transactions on Software Engineering, pp. 29-31, August 2017.
[8] S. Mishra “An Analysis of Weyuker’s Properties and Measurement Theory” Proceedings Indian National Science Academy, pp. 5-6, 2016
[9] Pfleeger S. L. and Kitchenham B. “Towards a Framework for Software Measurement Validation” IEEE
Transactions on Software Engineering, 21(12), pp. 929-943
[10] Zhuo F., Hagemeister Jack. and Oman P. “Constructing and testing software maintainability assessment
ISSN(E): 2277-128X, ISSN(P): 2277-6451, pp. 61-67
[11] Schach S. and Binkley A. “Validation of the coupling dependency metrics as a predictor of run time failures
and maintainability measures” Proceeding 20th International conference of software engineering, pp. 452-455,
2017
[12] Tolga O. P. and Misra S. “Software Measurement Activities in Small and Medium Enterprises: An Empirical
Assessment” IEEE Transactions on Software Engineering, pp. 84-87, January 2017
[13] R. Marinescu “Measurement and Quality in Object-Oriented Design” In Proceedings 21st IEEE International
Conference on Software Maintenance, pp. 701-704, 2015
[14] Rizvi S. and Khan R.A. “Maintainability Estimation Model for Object-Oriented Software in Design Phase
(MEMOOD)” Journal of Computing, Volume 2, Issue 4, April 2016
[15] Gautam C. and kang S. “Comparison and Implementation of Compound MEMOOD MODEL and MEMOOD
MODEL” International journal of computer science and information technologies, pp. 294-298, 2017
[16] Walter de Gruyter, Berline, Morasca S. and Zuse H. “A Framework of Software Measurement” Handbook of
Software Engineering and Knowledge Engineering, World Scientific Publication, Company, pp. 239-276, September 2016
[17] Alshayeb M. and Li. W. “An empirical validation of object-oriented metrics in two different iteration software
processes”, IEEE transaction of Software Engineering, pp. 29-33, 2015
[18] C. Shyam and F. Kemerer “A Metrics Suite for Object Oriented Design” IEEE Transactions on Software
Engineering, Vol. 20, pp. 46-49, 2014
[19] M. Lorenz and J. Kidd “Object Oriented Software Metrics” Prentice Hall, NJ, 2016
[20] F. Chris and C. Shyam "A Metrics Suite for Object-Oriented Design" M.I.T. Sloan School of Management, pp. 53-57, 2015
[21] B. F. Abreu and Rosenberg L. H. “Design metrics for OO software system” ECOOP Quantitative Methods
Workshop, 2017
[22] V. L. Basili “A validation of object-oriented Metrics as Quality Indicators” IEEE Transaction Software
Engineering. Vol. 22, pp. 751-761, 2014
[23] J. Bansiya and C. Davis “A Hierarchical Model for Object-Oriented Design Quality Assessment” IEEE
Transactions on Software Engineering, pp. 14-17, 2017
[24] W. Li, and Henry “Metrics for Object-Oriented system” Transactions on Software Engineering, 2014
[25] Rosenberg Linda “Software Quality Metrics for Object Oriented System Environments” A report of SATC’s
