# I. INTRODUCTION bject-Oriented design is more beneficial in software development environment and objectoriented design metrics is an essential feature to measure software quality over the environment [1]. object-oriented design is those design which contained all the properties and quality of software that is related to any large or small project [2]. It is a degree through which a system object can hold a particular attribute or characteristics. object-oriented is a classifying approach that is capable to classify the problem in terms of object and it may provide many paybacks on reliability, adaptability, reusability and decomposition of problem into easily under stood objects and providing some future modifications [3]. Software metrics makes it possible for software engineer to measure and predict software necessary resource for a project and project work product relevant to the software development effort. Metrics provide insight necessary to create and design model through the test. It also provide a quantative way to access the quality of internal attributes of the product, thereby it enables the software engineer to access quality before the product is build [4]. Metrics are the crucial source of information through which a software developer takes a decision for design good software. Some metrics may be transformed to serve their purpose for a new environment. M. Alshayeb et al. [13] have given two iterative procedures for the pragmatic study of object oriented metrics. They include the short-cycled agile process and the long cycled framework evolution process. By observing the results, it can be seen that the design efforts and source lines of code added, changed, and deleted were triumphantly predicted by object-oriented metrics in short-cycled agile process where as in the case long-cycled framework process the same features were not successfully predicted by it. This has shown that the design and implementation changes during development iterations can be predicted by objectoriented Metrics, but the same cannot be the case with long-term development of an established system. R.D. Neal et al. [20] also gives the study for the validation of the object-oriented software metrics and found that some of the proposed metrics could not be considered as the valid measure for the dimension then, they could be measured. He defined a model based on measurement theory of the validation through which they can proposed 10 new metrics -Potential Methods Inherited (PMI), Proportion of Methods Inherited by a Subclass (PMIS), Density of Methodological Cohesiveness (DMC), Messages and Arguments (MAA), Density of Abstract Classes (DAC), Proportion of Overriding Methods in a Subclass (POM), Unnecessary Coupling through Global Usage (UCGU), Degree of Coupling Between Class Objects (DCBO), Number of Private Instance Methods (PrIM), and Strings of Message Links (SML). R. Harrison et al. [12]suggested a statistical model which is obtained from the logistic regression for identifying threshold values for the Chidamber and Kemerer metrics. The process is authenticated empirically on a large Open-Source System-the Eclipse project. Their conclusion depending on the experimental results is that the Chidamber and Kemerer Metrics have threshold effects at different risk levels. The usefulness of these thresholds on later releases was authenticated with the aid of decision trees. Another conclusion by L.H. Ethzkorn [23] is that the chosen threshold values were more precise than those were chosen depending on either intuitive perspectives or on data distribution parameters. object-oriented design metrics has also been assign the high level design quality attributes for the object-oriented software with the help of hierarchical model. H. Lieu. et al. [33] have given perception that quality of software also plays an important role in terms of safety aspects and financial aspects. They bridged the gap between quality measurement and design of these metrics, with the help of measuring the excellence of object-oriented designs during development and redevelopment process of the software. M. Subramanyam et al. [34] proposed some Metrics suites and concluded that for the developers, designs metrics are very important to know the design aspects of the software and to enhance the quality of software. Rachel Harrison et al. [35] discussed about the six properties of metrics for object-oriented design (MOOD) Metrics and measured the object-oriented features like Inheritance, coupling, encapsulation, and polymorphism. In the result they showed that the metrics could be used to provide an overall assessment of the system. A. Goldberg et al. [46] have experimentally checked size estimation models that are objectoriented. The pragmatic examination of object-oriented Function Points has been extended to a considerable amount with the aid of a bigger data set and by comparing Object Oriented Function Points with other predictors of LOC (Lines of Code) in their work. Linear models where the independent variable is either a conventional Object-Oriented entity or an Object-Oriented Function Points-related measure were built and assayed by using a cross validation approach. C. Shyam et al. [14] suggests some software metrics through which we can calculating the quality of modularization of an object oriented software. They aimed that it provide a set of metrics for the large scale object oriented software system with having some dependencies and also provide some metrics for characterizing the quality for modularization regarding the APIs of the one side. On the another side, they provide some object-oriented dependencies like inheritance, associates relationship and base class designing. Y. Zhou et al. [54] considered the fault severity using the machine learning methods with their experimental exploration of fault proneness which predict the capability of object-oriented design metrics and all of these of the predictions and the fault severity are also taken from the domain NASA data sets. J. Xu. et al. [53] have proposed an object-oriented metrics which describes the fault estimation using empirical analysis and also used the CK metrics to apprise the number of faults in the particular program. This also includes some neural and fuzzy technique. At last, the result showed that we can get a dependable fault by using CBO, RFC, WMC, SLOC. Here SLOc is more considerable for the effect on the number of defects. C. Neelamegan et al. [45] surveyed four object-oriented metrics and mostly focused on the measurements that are totally applied on the design and class characteristics. Dr. B.R. Sastry et al. [42] trying to implement the graphics user interaction with the aid of software metrics and also tried to determine the quantity and quality of object oriented software development lifecycle. Metrics (i) and (iii) are very subjective in nature, Metrics (iv) and metric (vii) mostly involve the count of features; and metric (viii) is a Boolean (0 or 1) indicator metric. Therefore, all of the terminologies in object oriented language, consider as the basic components of the paradigm are objects, classes, attributes, inheritance, method, and message passing. They proposed all of that each object oriented metrics concept implies a programming behavior. defined the complexity of the object-oriented system in the form of the depth of the tree. Depth of the tree measures the number of the sub nodes of the tree. The more the number of sub nodes of tree the more complex the system. So, complexity of an object is equal to the depth of tree or total number of sub nodes. # III. REVIEW OF METRICS # c) Lorenz & Kidd Metrics Lorenz & Kidd [19] proposed a set of metrics that can be grouped in four categories are size, inheritance, internal and external. Size oriented metrics for object oriented class may be focused on count of the metrics, operations and attributes of an individual class and average value of object-oriented software as a whole. Inheritance based metrics is totally concentrated in which operations that are reused through the class hierarchy. Metrics for the class intervals are totally oriented towards the cohesion, while the external metrics were used to examine and reuse. It divide the class based metrics into the broad categories like size, internal, external inheritance and the main metrics which are focused on the size and complexity are class size (CS), Number of operations overridden by a subclass (NOO), Number of operations added by a subclass (NOA), Specialization index (SI), Average operation size (OS), Operation complexity (OC), Average number of parameters per operation (NP). D. Metrics for Object-Oriented Software Engineering (MOOSE) : Chidamber and Kemerer (CK) et al. [11] proposed some metrics that have generated a significant amount of interest and are currently the most well known object-oriented suite of measurements for Object-Oriented software. The CK metrics suite consists of six metrics that assess different characteristics of the object-oriented design are-(i)Weighted Methods per Class (WMC): This measures the sum of complexity of the methods in a class. A predictor of the time and effort required to develop and maintain a class we can use the number of methods and the complexity of each method. A large number of methods in a class may have a potentially larger impact on the children of a class since the methods in the parent will be inherited by the child. Also, the complexity of the class may be calculated by the cyclomatic complexity of the methods. 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. The following figure shows that the value of the DIT from a simple hierarchy. DIT represents the complexity and the behavior of a class, and the complexity of design of a class and potential reuse. 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 the more methods was used or inherited through which this making more complex to predict the behavior of the class and the deeper tree indicates that there is high complexity in the design because all of the facts contained more methods and class are involved. A deep hierarchy of the class may indicates a possibility of the reusing an inherited methods. (iii)Number of children (NOC) -According to Chidamber and Kemerer, the Number of Children (NOC) metric may be defined for the immediate sub class coordinated by the class in the form of class hierarchy [14,15]. These points are come out as NOC is used to measure that "How many subclasses are going to inherit the methods of the parent class". The greater the number of children, the greater the potential for reuse, since inheritance is a form of reuse. The greater 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 class which may be design. (iv)Coupling Between Objects (CBO) -CBO is used to count the number of the class to which the specific class is coupled. The rich coupling decrease the modularity of the class making it less attractive for reusing the class and more high coupled class is more sensitive to change in other part of the design through which the maintenance is so much difficult in the coupling of classes. The coupling Between Object Classes (CBO) metric is defined as "CBO for a class is a count of the number of non-inheritance related couples with classes". It claimed that the unit of "class" used in this metric is difficult to justify, and suggested different forms of class coupling: inheritance, abstract data type and message passing which are available in objectoriented programming. (v)Response for class (RFC) -The response set of a class (RFC) is defined as set of methods that can be executed in response and messages received a message by the object of that class. Larger value also complicated the testing and debugging of the object through which, it requires the tester to have more knowledge of the functionality. The larger RFC value takes more complex is class is a worst case scenariovalue for RFC also helps the estimating the time needed for time needed for testing the class. (vi)Lack of Cohesion in Methods (LCOM): This metric is used to count the number of disjoints methods pairs minus 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 using the same instance variable. Since cohesiveness within a class increases encapsulation it is desirable and due to lack of cohesion may imply that the class is split in to more than two or more sub classes. Low cohesion in methods increase the complexity, when it increases the error proneness during the development is so increasing. E Each of the metrics was expressed to measure where the numerator defines the actual use of any one of the feature for a particular design [38]. In MOOD metrics model, there are two main features are methods and attributes. Attributes are used to represent the status of object in the system and methods are used to maintained or modifying several kinds of status of the objects [5]. Metrics are defined as: (i)Method Hiding Factor (MHF): MHF is defined as the ratio of the sum of the invisibilities of all 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 the invisibilities of all 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 for class Ci to the maximum number of possible distinct polymorphic situations for class Ci. (vi)Coupling Factor (CF): CF is defined as the ratio of the maximum possible number of couplings in the system to the actual number of couplings not imputable to inheritance. MIF & AIF are used to measure the inheritance of the class & also provide the similarity into the classes. CF is used to measure the coupling between the classes. the coupling are of two types static & dynamic coupling, due to which is increase the complexity of the class & reduce the encapsulation & potential reuse that provide better maintainability. Software developers for the object-oriented system always avoid the high coupling factor. Polymorphism potential of the class are used to measure the polymorphism in the particular class & also arise from inheritance G. Goal Question Metrics (GQM):V. L. Basili [18] developed GQM approach. This approach was originally defined for evaluating defects for a set of projects in the NASA Goddard Space Flight Center environment. He has also provided the set of sequence which are helpful for the designers. The goal of GQM is to express the meaning of the templates which covers purpose, perspective and environment; a set of guidelines also proposed for driving question and metrics. It provides a framework involving three steps: i. List major goals of the development or maintenance project. ii. Derive from each goal the questions that must be answered to determine if the goals are being met. # iii. Decide what must be measured in order to be able to answer the questions adequately. Goal (Conceptual level): A goal is defined for an object, for a variety of reasons, with respect to various models of quality, from various points of view, relative to a particular environment. Objects of measurement are products, processes and resources. Question (Operational level): A set of questions is used to characterize the way the assessment/achievement of a specific goal 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 it in a quantitative way. This data can be objectives and subjective, if they depend only on the objects that can be measured and not on the viewport from which they may be taken. For example, number of versions of a document, staff hours spent on a task, size of a program. # Global Journal of Computer Science and Technology Volume XII Issue VII Version I The GQM approach define some goals, refine those goals into a set of questions, and the questions are further refined into metrics. Consider the following figure, for a particular question; G1 and G2 are two goals, Q2 in common for both of these goals. Metric M2 is required by all three questions. The main idea of GQM is that each metric identified is placed within a context, so metric M1 is collected in order to answer question Q1 to help achieve the goal G1. The QMOOD [25] is a comprehensive quality model that establishes a clearly defined and empirically validated model to assess object-oriented design quality attributes such as understandability and reusability, and relates it through mathematical formulas, with structural object-oriented design properties such as encapsulation and coupling. The QMOOD model consists of six equations that establish relationship between six objectoriented design quality attributes (reusability, flexibility, understandability, functionality, extendibility, and effectiveness) and eleven design properties. -The Number of Ancestor classes (NAC) metric proposed as an alternative to the DIT metric measures the total number of ancestor classes from which a class inherits 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", justified that because the attribute that the NAC metric captures is the number of other classes" environments from which the class inherits. (ii)Number of Local Methods (NLM) -The Number of Local Methods metric (NLM) is defined as the number of the local methods defined in a class which are accessible outside the class. It measures the attributes of a class that WMC metric intends to capture. 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 objectoriented design because it indicates the size of a class"s local interface through which other classes can use the 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 the local methods in a class, the more effort is required to comprehend the class behavior. 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) -The Class Method Complexity 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) -The Number of Descendent Classes (NDC) metric as an alternative to NOC is 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 claimed that the NDC metric captures the classes attribute better than NOC. (v)Coupling through Abstract Data Type (CTA) -The Coupling through Abstract Data Type (CTA) is defined as the total number of classes that are used 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 [16]. 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 the scope of how many other classes" services a class needs in order to provide its own service to others. (vi)Coupling through Message Passing (CTM) -The Coupling through Message Passing (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 because one class sends a message to an object of another class, without involving the two classes through inheritance or abstract data type [Li.,98]. Theoretical view given was that the CTM metric relates to the notion of message passing in object-oriented programming. The metric gives an indication of how many methods of other classes are needed to fulfill the class" own functionality. a) SATC"s Metrics Rosenberg Linda [48] proposed to select object oriented metrics that supports the goal of measuring the code, quality, result and they proposed many objectoriented metrics due to lack of theoretical basis and that can be validated. These metrics may be used to evaluate the object oriented concepts like methods, coupling and inheritance and mostly focus on both of the internal and external efficiency measures of the psychological complexity factors that affect the ability of the programmer. It proposed three traditional metrics and six new metrics for the object-oriented system metricsb) Traditional Metrics (i)Cyclomatic Complexity (CC): -Cyclomatic Complexity is used to measure the complexity of an algorithm in a method of class. 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. (ii)Line of Code: -It is a method used to evaluate the ease of understandability of the code by the developer and the maintainer. It can easily be counted by the counting the number of lines for the code and so on. Generally, used to measure the reusability and maintainability. # c) New Object Oriented Metrics The six new object oriented metrics are may be discussed 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, how many time and effort is required to develop and maintain the class. (ii)Response for a Class (RFC):-It is used to the combination of the complexity of a class 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 met hods through which all the methods of the class are inter -related with one another and provide a well bounded behavior. It also measures the degree of similarity of methods by data inputs variables and attributes. Generally, ii is used to evaluate the effi ciency 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 out the inheritance dept h of the tree from current node to the ancestor node. It is used to evaluate the reusability, efficiency, understandability and testability. (v)Number of Children (NOC):-his 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. # V. COMPARISON TABLE There is a comparison table through which, we can compare all the metrics with the multiples number of methods which are using in object-oriented design. These metrics can help for a software developer to measure the size, complexity and efforts by using these metric. They may be represented as- Source Metrics C H E N M O R R I S L & K M O O S E E M O O S E M O O D G Q M Q M O O D L I W S A T C CCM Y - - - - - - Y - Y OXM Y - - - - - - - - - OACM Y - - - - - - - - - ACM Y - - - - - - - - - OCM Y - - - - - - - - - CM Y - - - - - - - - - CHM Y - - - - - - - - - RM Y - - - - - - - - - DIT -Y - Y - - - Y - Y LCOM -Y - Y - - - - - Y CBO -Y - Y - - - - - - CS -- Y - - - - - - - NOA -- Y - - - - Y - - NOO -- Y - - - - Y - - SI -- Y - - - - - - - OS -- Y - - - - - - - OC -- Y - - - - - - - NP -- Y - - - - - - - WMC -- - Y - - - - - Y © 2012April NOC -- - Y - - - Y - Y RFC -- - Y - - - - - Y MPC -- - - Y - - Y - - DAC -- - - Y - - Y - - NOH -- - - Y - - - - - MHF -- - - - Y - - - - AHF -- - - - Y - - - - MIF -- - - - Y - - - - AIF -- - - - Y - - - - PF -- - - - Y - - - - CF -- - - - Y - - - - NOH -- - - - - - Y - - NIC -- - - - - - Y - - NMI -- - - - - - Y - - NNC -- - - - - - Y - - CCP -- - - - - - Y - - NAC -- - - - - - - Y - NLM -- - - - - - - Y - CMC -- - - - - - - Y - NDC -- - - - - - - Y - CTA -- - - - - - - Y - CTM -- - - - - - - Y - VI. # CONCLUSION AND FUTURE WORKS This manuscript contributes to an increased understanding of the state of the software metrics. A mechanism is provided for comparing all the object oriented software metrics which define all the methods, attributes are used in software engineering environment. The increase is software development means the measurement was also so high. The increasing significance being placed software measurement which has to lead and increase amount of research on developing the new software measures. In this paper, we have presented all of the software metrics for object oriented development. They provided a basis for measuring all of the characteristics like size, complexity, performance and quality. In rely of some notions the quality may be increased by added some features like abstraction, polymorphism and inheritance which are inherent in object orientation. This paper provides some help for researchers and practitioners for better understanding and selection of software metrics for their purposes. 1![Fig 1: Goal Question Metrics Hierarchy H. Quality Model for Object-Oriented Design (QMOOD):The QMOOD[25] is a comprehensive quality model that establishes a clearly defined and empirically validated model to assess object-oriented design quality attributes such as understandability and reusability, and relates it through mathematical formulas, with structural object-oriented design properties such as encapsulation and coupling. The QMOOD model consists of six equations that establish relationship between six objectoriented design quality attributes (reusability, flexibility, understandability, functionality, extendibility, and effectiveness) and eleven design properties.](image-2.png "Fig 1 :") i.Message Pass Coupling (MPC):-It means that thenumber of message that can be sent by the classoperations.ii.Data Abstraction Coupling (DAC):-It is used tocount the number of classes which an aggregatedto current class and also defined the dataabstraction coupling.iii.Number of Methods (NOM):-It is used to countthe number of operations that are local to theclass i.e. only those class operation which cangive the number of methods to measure it.iv.Size1:-It is used to find the number of line ofcode.v.Size2:-It is used to count the number of localattributes & the number of operation defined inthe class.F. Metrics For Object-Oriented Design (MOOD): F.B. Abreu et al.[37] defined MOOD (Metrics for 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). Comparison Study and Review on Object-Oriented Metrics201245 ## Appendix Global Journal of Computer Science and Technology Volume XII Issue VII Version I * A survey on object oriented quality metrics CNeelamegam MPunithavali Global journal of computer science and technologies 2011 * Software quality estimation through object oriented design metrics ADeepak KPooja TAlpika SSharma IJCSNS International journal of computer science and network security april 2011 * object oriented metrices: measure of complexity AHenderson 1996 Prentice Hall * AShaik CP KReddy BManda KPrakashine Deepti Journal of emerging trend in engineer and applied science (JETEAS) 2010 Metrics for object oriented design software system:A Survey * Software metrices: a rigorous and practical approach NFenton 1996 International Thomson computer press * Exploring the Relationships Between Design Measures and Software Quality In Object Oriented Systems LCBriand JWuest JDaly VPorter Journal of Systems and Software 51 2000 * Assessing the Applicability of Fault Proneness Models Across Object Oriented Software Projects LCBriand WLMelo JWust IEEE transactions on Software Engineering 28 7 2002 * Object Oriented Analysis PCoad EYourdon 1990 Yourdon Press * Metrics for Object-Oriented system WLi HenrySallie Transactions on Software Engineering 1995 * Applying and interpreting object oriented metrics LHRosenberg LHyatt Proceedings of software technology conference software technology conferenceutah April 1998 * A Metrics Suite for Object-Oriented Design AShyam FKemerer Chris M.I.T. Sloan School of Management 1993 * Comparing Programming Paradigms: An Evaluation of Functional and Object-Oriented Programs RHarrison LGSamaraweera Dobie PLewis Software Eng. J 11 July 1996 * An empirical validation of object-oriented metrics in two different iteration software processes MAlshayeb LiW IEEE transactionod Software Engineering 29 11 Nov 2003 * Towards a Metrics Suite for Object Oriented Design AShyam CFKemerer Proceeding on Object Oriented Programming Systems, Languages and Applications Conference (OOPSLA"91), ACM eeding on Object Oriented Programming Systems, Languages and Applications Conference (OOPSLA"91), ACM Nov 1991 26 * A Metrics Suite for Object Oriented Design CShyam CFKemerer IEEE Transactions on Software Engineering 20 6 June 1994 * Another Metric Suite for Object-oriented Programming WLi The Journal of System and Software 44 2 December 1998 * Estimating Software Costs: Bringing Realism to Estimating CJones 2007 Mc Graw Hill New York 2nd Edition * Avalidation of object-oriented Metrics as Quality Indicators VLBasili LBriand WLMelo IEEE Transaction Software Engineering 22 10 1996 * Object Oriented Software Metrics MLorenz JKidd 1994 Prentice Hall, NJ * The Measurement Theory Validation of Proposed Object-Oriented Software Metrics RDNeal 1996 Dissertation, Virginia Commonwealth University * Design, Implementation and Evolution of Object-Oriented Frameworks: Concepts and Guidelines VGurp JBosch Software-Practice and Experience 31 3 2001 * Case Studies To Evaluate a Domain Specific Application Framework Based on Complexity and Functionality Metrics HFujiwara SKusumoto KInoue ASuzuki TOotsubo KYuura Information and Software Technology Jan 2003 45 * Automated Reusability Quality Analysis of OO Legacy Software HEtzkorn WEHughes CGDavis Information and Software Technology 2001 43 * Measuring Software Evolution at a Nuclear Fusion Experiment Site: A Test Case for Applicability of OO and Reuse Metrics in Software Characterization GManduchi CTaliercio 2002 44 * A Hierarchical Model for Object-Oriented Design Quality Assessment JBansiya CGDavis IEEE Transactions on Software Engineering 28 1 2002 * An Empirical Study of Certain Object-Oriented Software Metrics GSubramanian WCorbin Journal of Systems and Software 59 1 2001 * Metrics for Object-oriented Software Development Environments KMorris 1989 MIT Masters Thesis * Object-Oriented Analysis and Design with Applications Benjamin Cummings 1994 2nd ed. * RSPressman Software Engineering Fifth edition * A New Metrics for Object-Oriented Design JChen Lum Information of Software Technology 35 4 April 1993 * BAbreu Fernando Proc. ECOOP'95 Workshop on Metrics ECOOP'95 Workshop on Metrics 1995 The MOOD Metrics Set * Mathematical Assessment of Object-Oriented Design Quality Alexander IEEE Transactions on Software Engineering 29 11 2003. November 2003 * Quality metrics of OOD for Software development and Re-development HLilu KZhou SYang First Asia-Pacific Conference on Quality Software August 2002 * Emphirical Analysis of CK metrics for OOD complexity: Implication for software defect MSubramanyam RKrishnan IEEE transaction on software engineering 2003 * An evaluation of the MOOD set of OOSM RHarrison SJCounsell RVNithi IEEE Transaction on Software Engineering 24 6 67308 June 1998 SD METRICS TOOL. in der Lache 17 * Coupling and Cohesion in ObjectOriented Systems JEder GKappel MSchreft 1994 University of Klagenfurt Technical Report * Design metrics for OO software system BFAbreu ECOOP"95, Quantitative Methods Workshop 1995 * The Design of Eiffel Program: Quantitative Evaluation Using the MOOD metrics BAbreu Fernando MiguelRita G Proceeding of TOOLS"96 eeding of TOOLS"96USA, Santa Barbara, California July 1996 * Evaluation and Metrication of Object Oriented System AKaur SSingh KSKahlon ; IImecs Proceedings of the International Multi Conference of Engineers and Computer Scientists the International Multi Conference of Engineers and Computer ScientistsHong Kong 2009. 2009. March 18 -20, 2009 * Evaluating the Impact of Object-Oriented Design on Software Quality FBrito EAbreu WMelo 1996. March 1996 Berlin, Germany 3rd Int"l S/W Metrics Symposium * A metrics suite for object oriented design SRChidamber CFKemerer IEEE Transactions on Software Engieneering June 1994 * Impact of software metrics on Object Oriented Software Development life cycle BRDr MVSastry Vijaya Saradhi International Journal of Engineering Science and Technology 2 2 2010 * Empirical Analysis of CK metricsfor Object Oriented Design Complexity: Implications of Software defects RSubramanyam MSKrishnan IEEE transactions on Software Engineering 29 4 2003 * Metrics for Object Oriented design focusing on class Inheritance metrics KMDr Breesam 2007 2nd International conference on dependability of computer system IEEE * A Survey-Object Oriented quality metrics CNeelamegan .MDr Punithavalli Global journal of Computer Sc. And Technology 9 4 2009 * Smalltalk-80: the language and its implementation AGoldberg DRobson 1983 Addison Wesley Reading, MA * The annotated C++ Reference manual MAEliss & BStroustrup 1990 Addison-Wesley Reading MA * Software Quality Metrics for Object Oriented System Environments RosenbergLinda A report of SATC"s research on OO metrics * Towards the Design Quality Evaluation of Object Oriented Software System ABrito EAbreu (Inesc/Iseg) MiguelGoulao Revised version: originally published in Proceedings of 5 th International Conference of Software Quality Austin, Texas 23 to 26 October, 1993 Rita Esteves (INESC/IST) * Foramal Definition of Object Oriented Design Metrics ALBaroni 2002 Vrije Universities Brussels-belgium MS Thesis * Candidate Metrics for Object -Oriented Software within a Taxonomy Framework Abreu FBrito RogerioCarapuca selected for reprint in the Journals of Systems and Software Venice, Italy October 1993. July 1994 23 Proceddings of AQUIS"93 (Achieving Quality In Software) * A metrics Suite for Object Oriented Design SChidamber CKemerer IEEE Transaction on Software Engineering June 1994 * An Empirical Validation of Object-Oriented Design Metrics for Fault Prediction JXu HDanny LFernandoCapretz Computer Science 4 7 2008 * Empirical Analysis of Object-Oriented Design Metrics for Predicting High and Low Severity Faults YZhou HLeung IEEE transaction on software engineering 2006 32