Object-Oriented Design Quality Models A Survey and Comparison

Transcription

1 Object-Oriented Design Quality Models A Survey and Comparison Mohamed El-Wakil Ali El-Bastawisi Mokhtar Boshra Information Systems Department {Mohamed.elwakil@acm.org, ali.elbastawisi@link.net, mbriad@cu.edu.eg} Ali Fahmy Computer Science Department afahmy@mailer.eun.eg Faculty of Computers and Information, Cairo University, Cairo, Egypt Abstract Since 1994, many Object-Oriented Design (OOD) quality models had appeared. OOD quality models aim is assessing OOD quality characteristics, such as maintainability, in a quantitative way through establishing relationships between OOD quality characteristics, and metrics computable from OOD diagrams, such as Depth of Inheritance Tree (DIT). This paper presents the results of our survey of the major OOD quality models appeared in literature since the MOOSE model in 1994, till the QMOOD model in 2002, then it proposes a set of desirable properties that should be possessed by OOD quality models and a comparison among the presented models with respect to the proposed desirable properties set Keywords: Information Systems quality, Object-Oriented Information Systems, Object- Oriented metrics, Object-Oriented quality models, quality assessment, UML. 1 Introduction Since the famous statement "What is not measurable make measurable" of Galileo Galilei ( ) it has been a major goal in science to quantify observations as a way to understand and control the underlying causes. One of the important observations that needs quantification in the Information Systems discipline is the quality of Information Systems. Producing a high quality information system (IS) is a goal required by all the stakeholders involved in any IS project. A major prerequisite to attain a high quality IS, is the continuous and early assessment of its quality. Assessing the IS quality in the early stages of its development life cycle signals any omissions or weaknesses that need to be addressed, and allows taking the necessarily measures to deviate such deficiencies as early as possible, thus, reducing the overall cost of IS development process, and increasing the IS quality level. Quality, as it applies to IS and the process of IS development, has two views; namely: the use view and the production view. The use view of IS quality is concerned with the extent to which the IS meets its intended organizational requirements; how much added-value the IS gives to its users, and how much it is easy to use and learn. The production view of IS quality is concerned with the IS software component quality. 1

2 The quality of the software component, of any computerized information system, influences the IS quality, as a whole, up to a very large extent. Analogously, software design quality affects the software end product (i.e. implemented applications) quality extensively. So, there is an intense need to guarantee the quality of the design. To achieve a high quality design there must be means to judge designs against established desirable attributes (e.g. maintainability). This judgment should be quantitative and objective to be applicable. Fortunately, information systems development projects that adhere to Object-oriented Analysis and Design (OOAD) approach tend to have many design documents available at early stages of the Software Development Life Cycle (SDLC). Over and above, design documents (e.g. class diagrams) produced by pursuing OOAD are likely to contain much information that facilitates assessing the design. Object-oriented design quality models are means for judging Object-oriented Designs. OOD quality models work by establishing relationships between desirable design attributes, such as maintainability and reusability and reckonable OOD metrics, such as depth of inheritance tree. Another prominent benefit of utilizing object-oriented design quality models is predicting estimations about the quality of the information system software component as a whole. In general, quality models consist of four parts: 1. Objectives: which are the quality characteristics that the model claims to assess. (e.g. maintainability) 2. Metrics: which is a set of quantitative design properties, that should be computable from a given design diagram. (e.g. Depth of Inheritance Tree DIT) 3. Relationships: Ways to express the association between Objectives and Metrics. (e.g. classes deep in the classes hierarchy are harder to maintain) 4. (Optional) Thresholds: that set upper/lower limits for metrics to fall within, to express a given trait. (e.g. For better maintainability the DIT should not exceed 6) In the next section, the first object-oriented quality model (MOOSE) is presented, followed by the Lorenz and Kidd metrics suite in section 3. In section 4, MOOD model is introduced, followed by QMOOD model in section 5. In section 6, we introduce six desirable properties that quality models should possess, and then, assess the presented quality models against these desirable properties. 2 MOOSE When Chidamber and Kemmerer Introduced the MOOSE (Metrics for Object-Oriented Software Engineering) metrics suite [1], also known as C.K. metrics suite, they inaugurated a plethora of Object-Oriented design metrics suits. Since 1994, many other OOD metrics suites [18,22,11,5] were presented; most of them are built upon the original C.K. metrics suite. Also, much effort [1,6] was devoted for empirically validating the original C.K. metrics and linking them to OOD quality attributes. Brito [7] published a formalization of C.K metrics based on the Object Constraint Language OCL. The C.K. metrics suite consists of six metrics that assess different characteristics of the OOD: 2

3 1. The Weighted Method Per Class (WMC) assesses complexity of a class through aggregating a complexity measure of its methods. Chidamber and Kemerer did not state, deliberately, a complexity measure to use, leaving the matter as an implementation detail. Given that the WMC is computed after the design phase, and before the implementation phase, it is not possible to use traditional code-based complexity measures such as McCabe Cyclomatic Complexity (CC) [9]. A viable assessment for methods complexity would be based on the methods attributes complexity. Another commonly used solution, is to consider the complexities of all methods as unity, in this case, the WMC would be a count for the number of methods in a class, and then, considered as a measure of the size, not the complexity [9] The Depth of Inheritance Tree (DIT) assess how deep, in a class hierarchy, a class is. This metric assesses the potential of reuse of a class and its probable ease of maintenance. A class with small DIT, has much potential for reuse. (i.e. it tends to be a general abstract class). On the other side, as a class gets deeper into a class hierarchy, it becomes more difficult to maintain, due to the increased mental burden needed to capture its functionally. The Number Of Children (NOC) is a simple measure of the number of classes associated with a given class using an inheritance relationship. It could be used to assess the potential influence a class has on the overall design. God classes [10] (i.e. classes with many children) are considered a bad design habit that occurs frequently. NOC helps detecting such classes. The Coupling Between Object Classes (CBO) of a class is defined as the number of other classes to which it is coupled. A class A is coupled to another class B, if A uses methods or attributes of class B. The information available in a typical class diagram dose not allow determining the methods usage part of CBO (i.e. whether class A uses method X in class B), but it is possible to determine whether a class A is using an attribute Y in class B or not (if attribute Y is a parameter of a method in class A). CBO is beneficial in judging how complex the testing of various parts of a design are likely to be [1]. A modular and encapsulated design shall yield a low CBO, and this is a desired situation. The more independent the class is, the easier to test and/or reuse it. The Response For a Class (RFC) is defined as a count of the set of methods that can be potentially executed in response to a message received by an instance of the class. The Lack of COhesion in Methods (LCOM) is the difference between the number of methods whose similarity is zero and the number of methods whose similarity is not zero. The similarity of two methods is the number of attributes used in common. LCOM can judge cohesiveness among class methods. Low LCOM indicates high cohesiveness, and vice versa. High LCOM indicates a class that shall be considered for splitting into two or more classes. However, a LCOM measure of zero is not a strong evidence that a class enjoys cohesiveness. 3 Lorenz and Kidd Object-Oriented Metrics In their fundamental book about software quality [5] Lorenz and Kidd introduced many metrics to quantify software quality assessment. Lorenz and Kidd metrics were accompanied by a justification for being considered as metrics. Eleven metrics introduced by Lorenz and 3

4 Kidd are applicable to class diagrams. A description of these metrics and the rationale behind them is given; they are classified into three metrics categories: 1. Class size metrics, which deal with quantifying an individual class: a. Number of Public Methods (NPM). This is a count of the number of public methods in a class. It is used to help estimating the amount of work to develop a class. b. Number of Methods (NM). The total number of methods in a class counts all public, private and protected methods. This metric is a useful indication of the classes which may be trying to do too much work themselves; i.e., they provide too much functionality. c. Number of Public Variables per class (NPV). This metric counts the number of public variables in a class. Lorenz and Kidd consider the number of variables in a class to be one measure of its size. The fact that one class has more public variables than another might imply that the class has more relationships with other objects and, as such, is more likely to be a key class. d. Number of Variables per class (NV). The total number of variables including public, private and protected variables. e. Number of Class Variables (NCV) f. Number of Class Methods (NCM) 2. Class Inheritance metrics, which look at the quality of the classes use of inheritance: a. Number of Methods Inherited (NMI). This metric measures the number of methods inherited by a subclass. No mention is made as to whether that inheritance is public or private. b. Number of Methods Overridden (NMO). A large number of overridden methods indicates a design problem, indicating that those methods were overridden as a design afterthought. It is suggested that a subclass should really be a specialization of its super classes, resulting in new unique names for methods. c. Number of New Methods (NNA). The normal expectation for a subclass is that it will further specialize (or add) methods to the super class object. A method is defined as an added method in a subclass if there is no method of the same name in any of its super classes. 3. Class Internals metrics, which look at general characteristics of classes. a. Average parameters per Method (APM) which is defined as Total Number Parameters in a class / Total number of methods. Lorenz and Kidd argue that APM should not exceed 0.7 b. Specialization Index: (SIX) is calculated as (NMO*DIT)/NM This metric looks at the quality of the classes use of inheritance. The specialization index measures to what extent subclasses redefine the behavior of their super classes. 4 MOOD Metrics for Object-Oriented Design (MOOD) suite was proposed by Fernando Brito and Rogerio Carpuca in 1994 [11], embedded in a quality model in 1995 [12] empirically validated in 1996 [13], a newer version (MOOD2) and MOODKIT, a metrics collection automation tool, were introduced in 1998 [14]. A formal method for representing MOOD2 metrics using OCL [17] appeared in

5 MOOD objective was to enable identifying quality Object-Oriented designs by means of quantitative evaluation (i.e. metrics) of the object-oriented paradigm abstractions (e.g. encapsulation) that are supposed to be responsible for internal quality, and to be able to express external quality attributes (e.g. defect density) as functions of these metrics. The original MOOD set consisted of eight metrics: Method Inheritance Factor (MIF), Attribute Inheritance Factor (AIF), Coupling Factor (CF), Polymorphism Factor (PF), Method Hiding Factor (MHF), Attribute Hiding Factor (AHF), Clustering Factor (CLF) and Reuse Factor (RF). These factors are percentages that measure the presence degree of OOD desired attributes. Hence their values are ranges from 0 to one. 1. The Method Hiding Factor (MHF) of a class diagram represents the percentage of invisibilities of methods in a class diagram (degree of methods encapsulation). The MHF is computed by dividing the number of all visible methods in all classes by the number of all methods in all classes. 2. The Attribute Hiding Factor (AHF) of a class diagram represents the percentage of invisibilities of attributes in a class diagram (degree of attributes encapsulation). The AHF is computed by dividing the number of visible attributes in a class diagram by the number of all attributes in a class diagram. 3. The Method Inheritance Factor (MIF) of a class diagram represents the percentage of effective inheritance of methods. The MIF is computed by dividing the number of all inherited methods in all classes by the sum of all methods available (inherited and locally defined) of all classes. 4. The Attribute Inheritance Factor (AIF) of a class diagram the percentage of effective inheritance of attributes. The AIF is computed by dividing the number of all inherited attribute in all classes by the sum of all attributes available (inherited and locally defined) of all classes. 5. The Polymorphism Factor (PF) represents the actual number of possible different polymorphic situations with respect to the maximum number of possible distinct polymorphic situations. The PF is computed by dividing the total number of overridden methods in all classes by the result of multiplying the number of new methods times the number of descendants for all classes, respectively. 6. The Coupling Factor (CF) of a class diagram represents the percentage of couplings among classes, not imputable to inheritance, with respect to the maximum possible number of couplings in the class diagram. The CF is computed by dividing the number of associations, not related to inheritance, between all classes by the number of classes squared minus the number of classes. 7. The Clustering Factor (CLF) of a class diagram represents percentage of actual number of standalone class hierarchies (clusters) with respect to the maximum possible number of class clusters, in a class diagram. The CLF is computed by dividing the number of class clusters in by the number of classes in a class diagram. 8. The Reuse Factor (RF) of a class diagram represents the percentage of classes that are specializations (children) of previously defined classes. The parent classes may be external to the class diagram (from a library such as MFC or OWL) or internal from super classes. Computing RF precisely is not possible with class diagrams solely, unless they are augmented by external libraries usage information. Brito and others in [14] proposed MOODKIT G2, depicted below in Figure 1, which is a tool that consists of two tiers. Tier 1 is a collection of parsers that accept input from different OOD formalisms such as OMT, Fusion, C++ and Java, then outputs the OOD constructs, 5

6 inputted earlier, represented using a proposed OOD specification language (Generic Object- Oriented Design Language? Yes! GOODLY). The second tier processes GOODLY specifications to verify its completeness and correctness, and then extract MOOD metrics to be stored in a repository for later utilization. Such an architecture will be helpful in situations when different object-oriented formalisms are used to design/develop different parts of the same system. (e.g. systems with parts developed using Java and other parts developed using C++) Figure 1: MOODKIT G2 Architecture [14] The MOOD2 set, referenced in [14], added many metrics to the MOOD set, however, the definitions of MOOD2 metrics are detailed in an internal report [16] that is not available in public. In [17] Brito and others introduced FLAME -a Formal Library for Aiding Metrics Extraction- that defined OOD metrics extractable from UML class diagrams in terms of the Object Constraint Language (OCL). However, OCL seems to be ineffective for such a purpose, since it is not rich enough to represent computationally complex metrics. 5 QMOOD The QMOOD [18] (Quality Model for Object-Oriented Design) is a comprehensive quality model that establishes a clearly defined and empirically validated model to assess OOD quality attributes such as understandability and reusability, and relates it through mathematical formulas, with structural OOD properties such as encapsulation and coupling. Also, it presents the OOD metrics needed to quantify these OOD properties. 6

7 The QMOOD model consists of six equations that establish relationship between six OOD quality attributes (reusability, flexibility, understandability, functionality, extendibility, and effectiveness) and eleven design properties (see Figure 2 below). How to measure these design properties is also a part of QMOOD. For example, reusability is a function of the coupling measure, cohesion measure, messaging measure, and the design size. The coupling measure is quantified using Direct Class Coupling (DCC) metric. The cohesion measure is quantified using Cohesion Among Methods in a Class (CAM) metric. The Messaging metric is quantified by Class Interface Size (CIS) metric. Finally, design size is quantified by Design Size in Classes (DSC) metric. All these are measurable directly from class diagrams, and applicable to UML class diagrams. Figure 2: QMOOD quality attributes, design properties and design metrics [18] 6 Desirable properties of OOD quality models Based on our survey of the existing OOD quality models, we propose a set of properties that should be exhibited by any OOD quality model to be of practical use. Lacking any of these properties will result in an inapplicable quality model. 1. Depend on high level design features only. High level design features are those design models available early in software development life cycle, such as abstract class diagrams (i.e. without implementation). Depending on high level design features allow assessing the design in its early stages. 2. The model objectives, quality characteristics to be assessed, should be stated explicitly. Some models [19, 20, 5, and 21] just introduce metrics without stating how these metrics could be used to assess quality. 3. The metrics should be precisely defined. Ambiguity in metrics definitions allows many interpretations for the same metric, for example, in [1] the Weighted Method per Class metric does not state clearly what methods are to be considered. Are inherited methods considered? Are overridden methods included? What about overloaded methods? Does visibility affect the counting? These and other question will arise when it comes to applying the model. 7

8 4. The models should express the relationships between the characteristics and design metrics in a clear, preferably, formal manner. Just stating that a given set of metrics affect fault-proneness, is not enough. A formal expression that involves metrics and how they coincide to the assessed characteristic is very important. This formal expression could be in the form of a mathematical equation [18] or a set of thresholds within which the metrics should lay for the design to be considered adhering to desired design characteristic. Some other formal methods are possible: Genero in [22] uses fuzzy classification and regression trees to classify design diagrams with respect to their ease of maintainability into one of seven levels. 5. There should be an interpretation of the results. The famous Lord Kevin quote The degree to which you can express something in numbers is the degree to which you really understand it [24] is overly exaggerated. Numbers are no more than numbers! They do not have a meaning by their own. Till the values produced by a model are given interpretations that could be used in making decisions, there is no extra understanding is gained. 6. Models should be validated empirically. Quality models could be developed based on a person s own expertise. However, a proof of the validity of any proposed model is a strong support to its thesis. Empirical validation of proposed models received a great attention in the literature [23,3,8,15]. Empirical validation works, in general, by assessing the quality characteristics of a given design in two ways, one way using the proposed model, the other way using human judgment. The confidence we can put on the proposed model, depends on the degree of coincidence between the human assessment and the model assessment. Models without validation are always in doubt concerning their correctness. Hence, only validated models were considered in this paper and in our work in general. The results of assessing the presented OOD quality models against our proposed OOD quality desirable properties are summarized in table 1: Property MOOSE LK OO Metrics MOOD QMOOD Dependence on high NO 1 YES YES YES level design characteristics only Explicit quality characteristics NO 2 NO 3 Error Density, Fault Density and Normalized Rework Reusability, Flexibility, Understandability, Extendibility, and Effectiveness Precise metrics Yes, except the YES YES YES definitions WMC Formal relationships NO 2 NO YES (Pearson r YES (Equations) correlation coefficients) Results interpretation NO 2 NO YES YES Empirical validation Validated NO Validated [13] Validated [11] Table 1: Assessment of the four major OOD quality models against our proposed OOD quality models desirable properties. 8

9 1 Chidamber and Kemmerer metric set focuses on class level metrics and that several of them are highly dependent on low level metrics for their derivation, and as such are not ideally suited to early stage design analysis. 2 The original MOOSE suite did not refer to any quality characteristic, however, later experiments linked the MOOSE with maintenance effort [4] and fault proneness [3] 3 Lorenz and Kidd metrics are criticized [2] for being mere counts of class properties such as the number of public methods, the number of all instance methods, the number of all class methods and so. 7 Conclusion In this paper, we have surveyed four object-oriented design quality models. The work of Chidamber and Kemerer has been seminal in defining, and validating quality models. Lorenz and Kidd metrics are criticized for not being a part of a quality model, however, they have the advantages of being well-defined, easy to collect, and could be computed in the early phases of design. MOOD model is as a very well-defined, through mathematical formulas and OCL statements, empirically validated, supported by a tool, and most importantly provides thresholds that could be used to judge the metrics collected from a given design. The QMOOD model enjoys similar properties as the MOOD model of being well-defined, empirically validated and supported by a tool. QMOOD distinguishes itself by providing mathematical formulas that links design quality attributes with design metrics. This allowed computing a Total Quality Index (TQI), which was already used by [18] authors to compare fourteen class diagrams. We proposed a group of desirable properties for OOD quality models, and then we used them to compare the presented OOD quality models. Based on this comparison, we conclude that the QMOOD suite is the most complete, comprehensive, and supported suite. 9

10 References [1] Shyam R. Chidamber and Chris F. Kemerer,1994, A METRICS SUITE FOR OBJECT ORIENTED DESIGN, IEEE Transactions on Software Engineering, Vol. 20, No. 6, June 1994, pp [2] R. Harrison, S. Counsell, and R. Nithi,1997, An Overview of Object-Oriented Design Metrics,Proceedings of the 8th International Workshop on Software Technology and Engineering Practice (STEP '97). [3] Victor R. Basili, Lionel C. Brian and Walchlio L. Melo,1996, Validation of Object- Oriented Design Metrics as Quality Indicators, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 22, NO. 10, OCTOBER [4] Li, W. and Henry, S.,1993, Object-Oriented Metrics that predict Maintainability, Journal of Systems and Software, 23(2), pages [5] Mark Lorenz, Jeff Kidd,1994, Object-Oriented Software Metrics, Prentice Hall; ISBN: X. [6] Giancarlo Succi, Witold Pedrycz, Milorad Stefanovic, and James Miller,2003, Practical assessment of the models for identification of defect-prone classes in object-oriented commercial systems using design metrics, The Journal of Systems and Software 65 (2003) [7] Aline Lúcia Baroni, and Fernando Brito e Abreu,2003, An OCL-Based Formalization of the MOOSE Metric Suite, 7th ECOOP Workshop on Quantitative Approaches in Object- Oriented Software Engineering. [8] Marcela Genero, José Olivas, Mario Piattini, and Francisco Romero,2001, Using metrics to predict OO information systems maintainability,13th International Conference Advanced Information Systems Engineering. [9] McCabe, Thomas J. & Butler, and Charles W,1989, Design Complexity Measurement and Testing,Communications of the ACM 32, 12 (December 1989): [10] Alexander Chatzigeorgiou,2003, Mathematical Assessment of Object-Oriented Design Quality,IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 29, NO. 11, NOVEMBER [11] Fernando Brito e Abreu and Rogério Carapuça,1994, Object-Oriented Software Engineering: Measuring and Controlling the Development Process, 4th Int. Conf. on Software Quality, McLean, VA, USA, 3-5 October [12] Fernando Brito e Abreu Miguel Goulão, Rita Esteves,1995, Toward the Design Quality Evaluation of Object-Oriented Software Systems,5th International Conference on Software Quality, Austin, Texas, 23 to 26 October [13] Fernando Brito e Abreu and Walcélio Melo,1996, Evaluating the Impact of Object- Oriented Design on Software Quality,3rd Int l S/W Metrics Symposium, March 1996, Berlin, Germany. 10

11 [14] Fernando Brito e Abreu and Luis Ochoa, Miguel Goulão,1999, The GOODLY Design Language for MOOD Metrics Collection, International Workshop on Quantitative Approaches in Object-Oriented Software Engineering. [15] Marcela Genero, and Mario Piattini, Empirical validation of measures for class diagram structural complexity through controlled experiments, 5th International ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering. [16] Abreu, F. Brito,1998, The MOOD2 Metrics Set,INESC/ISEG internal report, April [17] Aline Lúcia Baroni, and Fernando Brito e Abreu,2003, A Formal Library for Aiding Metrics Extraction,4th International Workshop on OO Reengineering. [18] Jagdish Bansiya, and Carl G. Davis,2002, A Hierarchical Model for Object-Oriented Design Quality Assessment,IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 28, NO. 1, JANUARY [19] Hyoseob Kim1 and Cornelia Boldyreff,2002, Developing Software Metrics Applicable to UML Models,6th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering. [20] Michele Marchesi,1998, OOA Metrics for the Unified Modeling Language,Proceedings of the 2nd Euromicro Conference on Software Maintenance and Reengineering. [21] Michele Lanza and Stephane Ducasse,2002, Beyond Language Independent Object Oriented Metrics: Model Independent Metrics, 6th International Workshop on Quantitative Approaches in Object-Oriented Software Engineering. [22] Marcela Genero, Mario Piattini and Coral Calero, 2000, Early measures for UML class diagrams, L' Objet. Volume 6 No. 4/2000. [23] Khaled El Emam, Saida Beniarbi, Nishith Goel, and Shesh Rai, 1999, A Validation of Object-oriented Metrics,National Research Council Canada Internal Report No [24] Kelvin, W. T. Popular Lectures and Addresses. 11