1 Ivan Marsic Rutgers University LECTURE 16: Class Cohesion Metrics.

Slides:



Advertisements
Similar presentations
Overview Introduces a new cohesion metric called Conceptual Cohesion of Classes (C3) and uses this metric for fault prediction Compares a new cohesion.
Advertisements

1 Ivan Marsic Rutgers University LECTURE 15: Software Complexity Metrics.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Page 1 Building Reliable Component-based Systems Chapter 7 - Role-Based Component Engineering Chapter 7 Role-Based Component Engineering.
The Architecture Design Process
Object-Oriented Metrics
The Need for Packages How do you break down a large system into smaller systems? Structured methods use functional decomposition Functions represent something.
Developed by Reneta Barneva, SUNY Fredonia Component Level Design.
SE-565 Software System Requirements More UML Diagrams.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Modeling (Chap. 2) Modern Information Retrieval Spring 2000.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Computer Science II 810:062 Section 01 Session 2 - Objects and Responsibilities.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Refactoring.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
SOFTWARE DESIGN.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
Sommerville, Mejia-Alvarez, 2009Software Engineering, Slide 1 Software Design u Deriving a solution which satisfies software requirements.
Software Design Deriving a solution which satisfies software requirements.
Introduction to Graph “theory” Why do we care about graph theory in testing and quality analysis? –The “flow” (both control and data) of a design, within.
Lecture 5: Mathematics of Networks (Cont) CS 790g: Complex Networks Slides are modified from Networks: Theory and Application by Lada Adamic.
Concepts of Software Quality Yonglei Tao 1. Software Quality Attributes  Reliability  correctness, completeness, consistency, robustness  Testability.
Cohesion and Coupling CS 4311
System Implementation
Software Design Design is the process of applying various techniques and principles for the purpose of defining a device, a process,, or a system in sufficient.
1 Graph Coverage (4). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
1 Advanced Software Architecture Muhammad Bilal Bashir PhD Scholar (Computer Science) Mohammad Ali Jinnah University.
UML Class Diagram Trisha Cummings. What we will be covering What is a Class Diagram? Essential Elements of a UML Class Diagram UML Packages Logical Distribution.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
Lecture 1: UML Class Diagram September 12, UML Class Diagrams2 What is a Class Diagram? A class diagram describes the types of objects in the system.
An Automatic Software Quality Measurement System.
CSc 461/561 Information Systems Engineering Lecture 5 – Software Metrics.
Dr D. Greer, Queens University Belfast )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes.
Jump to first page (C) 1998, Arun Lakhotia 1 Design Quality Metrics Arun Lakhotia University of Southwestern Louisiana Po Box Lafayette, LA 70504,
Chapter 3 Class Diagrams. 2 Outline Class Basics Class Basics Classes Classes Association Association Multiplicity Multiplicity Inheritance Inheritance.
1 Ivan Marsic Rutgers University LECTURE 15: Software Complexity Metrics.
11 Software Design CSCU 411 Software Engineering.
© Tan,Steinbach, Kumar Introduction to Data Mining 4/18/ Data Mining: Cluster Analysis This lecture node is modified based on Lecture Notes for Chapter.
Rohini Sharma Roll No. RA1809A01 Regd. No M.Tech.(CSE) Part Time 3 rd Semester.
Object-Oriented Software Engineering Practical Software Development using UML and Java Modelling with Classes.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix A Object-Oriented Analysis and Design A.1.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Coupling and Cohesion Schach, S, R. Object-Oriented and Classical Software Engineering. McGraw-Hill, 2002.
Coupling and Cohesion Pfleeger, S., Software Engineering Theory and Practice. Prentice Hall, 2001.
Further Modularization, Cohesion, and Coupling. Simple Program Design, Fourth Edition Chapter 9 2 Objectives In this chapter you will be able to: Further.
School of Business Administration
7. Modular and structured design
Metrics of Software Quality
Basic Concepts in Software Design
Coupling and Cohesion 1.
Design Characteristics and Metrics
Lecture 9- Design Concepts and Principles
Software Design Mr. Manoj Kumar Kar.
Object-Oriented Metrics
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
Design Metrics Software Engineering Fall 2003
Design Metrics Software Engineering Fall 2003
LECTURE 15: Software Complexity Metrics
CS223: Software Engineering
Lecture 9- Design Concepts and Principles
Software Design Lecture : 9.
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
Chapter 19 Technical Metrics for Software
Software Metrics SAD ::: Fall 2015 Sabbir Muhammad Saleh.
TECHNICAL PAPER PRESENTATION By: Srihitha Yerabaka
Cohesion and Coupling.
Chapter 8: Design: Characteristics and Metrics
Presentation transcript:

1 Ivan Marsic Rutgers University LECTURE 16: Class Cohesion Metrics

2 Topics Structural Cohesion Metrics Internal Cohesion or Syntactic Cohesion External Cohesion or Semantic Cohesion

3 Measuring Module Cohesion Cohesion or module “strength” refers to the notion of a module level “togetherness” viewed at the system abstraction level Internal Cohesion or Syntactic Cohesion –closely related to the way in which large programs are modularized –ADVANTAGE: cohesion computation can be automated External Cohesion or Semantic Cohesion –externally discernable concept that assesses whether the abstraction represented by the module (class in object-oriented approach) can be considered to be a “whole” semantically –ADVANTAGE: more meaningful

4 An Ordinal Cohesion Scale 6 - Functional cohesion module performs a single well-defined function 5 - Sequential cohesion >1 function, but they occur in an order prescribed by the specification 4 - Communication cohesion >1 function, but on the same data (not a single data structure or class) 3 - Procedural cohesion multiple functions that are procedurally related 2 - Temporal cohesion >1 function, but must occur within the same time span (e.g., initialization) 1 - Logical cohesion module performs a series of similar functions, e.g., Java class java.lang.Math 0 - Coincidental cohesion high cohesion low cohesion PROBLEM: Depends on subjective human assessment

5 Weak Cohesion Indicates Poor Design Unrelated responsibilities/functions imply that the module will have unrelated reasons to change in the future Because semantic cohesion is difficult to automate, and automation is key, most cohesion metrics focus on syntactic cohesion

6 Structural Class Cohesion SCC measures how well class responsibilities are related –Class responsibilities are expressed as its operations/methods C ohesive interactions of class operations: How operations can be related 3 - Operations calling other operations (of this class) 2 - Operations sharing attributes 1 - Operations having similar signatures (e.g., similar data types of parameters) weakest cohesion strongest cohesion code based interface based

7 Elements of a Software Class Controller # numOfAttemps_ : long # maxNumOfAttempts_ : long + enterKey(k : Key) – denyMoreAttempts() DeviceCtrl # devStatuses_ : Vector + activate(dev : string) : boolean + deactivate(dev :string) : boolean + getStatus(dev : string) : Object attributes methods a1a1 a2a2 m1m1 m2m2 a1a1 m1m1 m2m2 m3m3 Code based cohesion metric: To know if m i and m j are related, need to see their code Note: This is NOT strictly true, because good UML interaction diagrams show which methods call other methods, or which attributes are used by a method Interface based cohesion metric: To know if m i and m j are related, compare their signatures a1:a2:a1:a2: m1:m2:m1:m2: a1:a1: m1:m2:m3:m1:m2:m3: Note: A person can guess if a method is calling another method or if a method is using an attribute, but this process cannot be automated!

8 Interface-based Cohesion Metrics Advantages –Can be calculated early in the design stage Disadvantages –Relatively weak cohesion metric: Without source code, one does not know what exactly a method is doing (e.g., it may be using class attributes, or calling other methods on its class) Number of different classes with distinct method-attribute pairs is generally larger than the number of classes with distinct method- parameter-type, because the number of attributes in classes tends to be larger than the number of distinct parameter types

9 Desirable Properties of Cohesion Metrics Monotonicity: adding cohesive interactions to the module cannot decrease its cohesion if a cohesive interaction is added to the model, the modified model will exhibit a cohesion value that is the same as or higher than the cohesion value of the original model Ordering (“representation condition” of measurement theory): Metric yields the same order as intuition Discriminative power (sensitivity): modifying cohesive interactions should change the cohesion –Discriminability is expected to increase as: 1) the number of distinct cohesion values increases and 2) the number of classes with repeated cohesion values decreases Normalization: allows for easy comparison of the cohesion of different classes

10 Example of 2 x 2 classes attributes methods a1a1 a2a2 m1m1 m2m2 List all possible cases for classes with two methods and two attributes. We intuitively expect that cohesion increases from left to right: If we include operations calling other operations, then:

11 Example of 2 x 2 classes attributes methods a1a1 a2a2 m1m1 m2m2 List all possible cases for classes with two methods and two attributes. We intuitively expect that cohesion increases from left to right: If we include operations calling other operations, then:

12 Cohesion Metrics Running Example Classes a1a1 m1m1 m4m4 a4a4 class C1 a1a1 m1m1 m4m4 a4a4 class C2 a1a1 m1m1 m4m4 a4a4 class C3 a1a1 m1m1 m4m4 a4a4 class C4 a1a1 m1m1 m4m4 a4a4 class C5 a1a1 m1m1 m4m4 a4a4 class C6 a1a1 m1m1 m4m4 a4a4 class C7 a1a1 m1m1 m4m4 a4a4 class C8class C9 a1a1 m1m1 m4m4 a4a4

13 Example Metrics (1) Lack of Cohesion of Methods (LCOM1) (Chidamber & Kemerer, 1991) LCOM1 = Number of pairs of methods that do not share attributes LCOM2 (Chidamber & Kemerer, 1991) P = Number of pairs of methods that do not share attributes Q = Number of pairs of methods that share attributes LCOM2 = P – Q, if P – Q  0 0, otherwise LCOM3 (Li & Henry, 1993) LCOM3 = Number of disjoint components in the graph that represents each method as a node and the sharing of at least one attribute as an edge Class Cohesion MetricDefinition / Formula (1) (2) (3) # Method Pairs = NP = M2M2 = M! 2!  (M – 2)! LCOM1(C1) = P = NP – Q = 6 – 1 = 5 LCOM1(C2) = 6 – 2 = 4 LCOM1(C3) = 6 – 2 = 4 LCOM1(C4) = 6 – 1 = = 6 a1a1 m1m1 m4m4 a4a4 class C1 a1a1 m1m1 m4m4 a4a4 class C2 a1a1 m1m1 m4m4 a4a4 class C3 LCOM2(C1) = P – Q = 5 – 1 = 4 LCOM2(C2) = 4 – 2 = 2 LCOM2(C3) = 4 – 2 = 2 LCOM2(C4) = 5 – 1 = 4 C3: LCOM3(C1) = 3 LCOM3(C2) = 2 LCOM3(C3) = 2 LCOM3(C4) = 3 NP(Ci) = LCOM4 (Hitz & Montazeri, 1995) Similar to LCOM3 and additional edges are used to represent method invocations (4) LCOM4(C1) = 3 LCOM4(C2) = 2 LCOM4(C3) = 2 LCOM4(C4) = 1 LCOM1: LCOM3: LCOM2: LCOM4: a1a1 m1m1 m4m4 a4a4 class C4 C2, C3:C4: C2:C1, C4: C1:

14 LCOM3 and LCOM4 for class C7 a1a1 m1m1 m4m4 a4a4 class C7 LCOM3 = Number of disjoint components in the graph that represents each method as a node and the sharing of at least one attribute as an edge a1a1 m1m1 m4m4 a4a4 class C7 m1m1 m2m2 m3m3 m4m4 Steps: 1. Draw four nodes (circles) for four methods. 2. Connect the first three circles because they are sharing attribute a 1. LCOM3 creates the same graph for C7 and C7 --- there are two disjoint components in both cases LCOM3(C7) = LCOM3(C7) = 2 LCOM4 = Similar to LCOM3 and additional edges are used to represent method invocations m1m1 m2m2 m3m3 m4m4 Steps: 1. Draw four nodes (circles) for four methods. 2. Connect the first three circles because they are sharing attribute a For C7 only: Connect the last two circles because m 3 invokes m 4. C7 & C7: C7: m1m1 m2m2 m3m3 m4m4 LCOM4 finds two disjoint components in case C7 LCOM4(C7) = 2 LCOM4 finds one disjoint component in case C7 LCOM4(C7) = 1

15 Example Metrics (1) Lack of Cohesion of Methods (LCOM1) (Chidamber & Kemerer, 1991) LDA1) When the number of method pairs that share common attributes is the same, regardless of how many attributes they share, e.g., in C7 4 pairs share 1 attribute and in C8 4 pairs share 3 attributes each LDA2) When the number of method pairs that share common attributes is the same, regardless of which attributes are shared, e.g., in C7 4 pairs share same attribute and in C9 4 pairs share 4 different attributes LCOM2 (Chidamber & Kemerer, 1991) LDA1) and LDA2) same as for LCOM1 LDA3) When P  Q, LCOM2 is zero, e.g., C7, C8, and C9 LCOM3 (Li & Henry, 1993) LDA1) same as for LCOM1 LDA4) When the number of disjoint components (have no cohesive interactions) is the same in the graphs of compared classes, regardless of their cohesive interactions, e.g., inability to distinguish b/w C1 & C3 Class Cohesion MetricLack of Discrimination Anomaly (LDA) Cases (1) (2) (3) LCOM1(C1) = P = NP – Q = 6 – 1 = 5 LCOM1(C3) = 6 – 2 = 4 LCOM1(C7) = 6 – 3 = 3 LCOM1(C8) = 6 – 3 = 3 LCOM1(C9) = 6 – 3 = 3 a1a1 m1m1 m4m4 a4a4 class C1 a1a1 m1m1 m4m4 a4a4 class C3 LCOM2(C1) = P – Q = 5 – 1 = 4 LCOM2(C3) = 4 – 2 = 2 LCOM2(C7) = 0 P < Q LCOM2(C8) = 0 P < Q LCOM2(C9) = 0 P < Q LCOM3(C1) = 3 LCOM3(C3) = 2 LCOM3(C7) = 2 LCOM3(C8) = 2 LCOM3(C9) = 1 LCOM4 (Hitz & Montazeri, 1995) Same as for LCOM3 (4) LCOM4(C1) = 3 LCOM4(C3) = 2 LCOM4(C7) = 2 LCOM4(C8) = 2 LCOM4(C9) = 1 LCOM1: LCOM3: LCOM2: LCOM4: a1a1 m1m1 m4m4 a4a4 class C7 a1a1 m1m1 m4m4 a4a4 class C8 a1a1 m1m1 m4m4 a4a4 class C9

16 LCOM3 and LCOM4 for class C7 a1a1 m1m1 m4m4 a4a4 class C7 LCOM3 = Number of disjoint components in the graph that represents each method as a node and the sharing of at least one attribute as an edge a1a1 m1m1 m4m4 a4a4 class C7 m1m1 m2m2 m3m3 m4m4 Steps: 1. Draw four nodes (circles) for four methods. 2. Connect the first three circles because they are sharing attribute a 1. LCOM3 creates the same graph for C7 and C7 --- there are three disjoint components in both cases LCOM3(C7) = LCOM3(C7) = 3 LCOM4 = Similar to LCOM3 and additional edges are used to represent method invocations m1m1 m2m2 m3m3 m4m4 Steps: 1. Draw four nodes (circles) for four methods. 2. Connect the first three circles because they are sharing attribute a For C7 only: Connect the last two circles because m 3 invokes m 4. C7 & C7: C7: m1m1 m2m2 m3m3 m4m4 LCOM4 finds three disjoint components in case C7 LCOM4(C7) = 3 LCOM4 finds one disjoint component in case C7 LCOM4(C7) = 1

17 Example Metrics (2) LCOM5 (Henderson-Sellers, 1996) LCOM5 = (a – kℓ) / (ℓ – kℓ), where ℓ is the number of attributes, k is the number of methods, and a is the summation of the number of distinct attributes accessed by each method in a class Coh (Briand et al., 1998) Class Cohesion MetricDefinition / Formula (5) (6) Coh = a / kℓ, where a, k, and ℓ have the same definitions as above a1a1 m1m1 m4m4 a4a4 class C1 a1a1 m1m1 m4m4 a4a4 class C2 a1a1 m1m1 m4m4 a4a4 class C3 LCOM5 = k (1 – Coh) k – 1 Coh = 1 – (1 – 1/k)LCOM5 a(C1) = ( ) = 5 a(C2) = ( ) = 6 a(C3) = ( ) = 6 a(C4) = ( ) = 5 LCOM5(C1) = (5 – 4  4) / (4 – 4  4) = 11 / 12 LCOM5(C2) = 10 / 12 = 5 / 6 LCOM5(C3) = 5 / 6 LCOM5(C4) = 11 / 12 Coh(C1) = 5 / 16 Coh(C2) = 6 / 16 = 3 / 8 Coh(C3) = 3 / 8 Coh(C4) = 5 / 16 LCOM5:Coh: a1a1 m1m1 m4m4 a4a4 class C4

18 Example Metrics (2) LCOM5 (Henderson-Sellers, 1996) LDA5) when classes have the same number of attributes accessed by methods, regardless of the distribution of these method-attribute associations, e.g., C2 and C3 Coh (Briand et al., 1998) Class Cohesion Metric (5) (6) Same as for LCOM5 a1a1 m1m1 m4m4 a4a4 class C1 a1a1 m1m1 m4m4 a4a4 class C2 a1a1 m1m1 m4m4 a4a4 class C3 LCOM5 = k (1 – Coh) k – 1 Coh = 1 – (1 – 1/k)LCOM5 a(C1) = ( ) = 5 a(C2) = ( ) = 6 a(C3) = ( ) = 6 a(C4) = ( ) = 5 LCOM5(C1) = (5 – 4  4) / (4 – 4  4) = 11 / 12 LCOM5(C2) = 10 / 12 = 5 / 6 LCOM5(C3) = 5 / 6 LCOM5(C4) = 11 / 12 Coh(C1) = 5 / 16 Coh(C2) = 6 / 16 = 3 / 8 Coh(C3) = 3 / 8 Coh(C4) = 5 / 16 LCOM5:Coh: a1a1 m1m1 m4m4 a4a4 class C4 Lack of Discrimination Anomaly (LDA) Cases

19 Example Metrics (3) Class Cohesion MetricDefinition / Formula a1a1 m1m1 m4m4 a4a4 class C1 a1a1 m1m1 m4m4 a4a4 class C2 a1a1 m1m1 m4m4 a4a4 class C3 Tight Class Cohesion (TCC) (Bieman & Kang, 1995) TCC = Fraction of directly connected pairs of methods, where two methods are directly connected if they are directly connected to an attribute. A method m is directly connected to an attribute when the attribute appears within the method’s body or within the body of a method invoked by method m directly or transitively (7) (8) Loose Class Cohesion (LCC) (Bieman & Kang, 1995) LCC = Fraction of directly or transitively connected pairs of methods, where two methods are transitively connected if they are directly or indirectly connected to an attribute. A method m, directly connected to an attribute j, is indirectly connected to an attribute i when there is a method directly or transitively connected to both attributes i and j TCC(C1) = 1 / 6 TCC(C2) = 2 / 6 TCC(C3) = 2 / 6 TCC(C4) = 3 / 6 LCC(C1) = 1/6 LCC(C2) = 2/6 LCC(C3) = 3/6 LCC(C4) = 3/6 (9) Degree of Cohesion-Indirect (DC I ) (Badri, 2004) (10) DC I = Fraction of directly or transitively connected pairs of methods, where two methods are transitively connected if they satisfy the condition mentioned above for LCC or if the two methods directly or transitively invoke the same method Degree of Cohesion-Direct (DC D ) (Badri, 2004) DC D = Fraction of directly connected pairs of methods, where two methods are directly connected if they satisfy the condition mentioned above for TCC or if the two methods directly or transitively invoke the same method = 1 – LCOM1 NP NP – P NP TCC = Q* / NP = TCC:LCC: In class C3: m 1 and m 3 transitively connected via m 2 DC D (C1) = 1/6 DC D (C2) = 2/6 DC D (C3) = 2/6 DC D (C4) = 4/6 DC D : DC I (C1) = 1/6 DC I (C2) = 2/6 DC I (C3) = 3/6 DC I (C4) = 4/6 DC I : a1a1 m1m1 m4m4 a4a4 class C4 C4: C1:C3: C2: C1, C2: same as for TCC C3: C4: C1, C2: same as for TCC C3: C4: C1, C2: same as for TCC C3: C4: Q*(C4) = 3 NP(Ci) = 6

20 Example Metrics (4) Class Cohesion MetricDefinition / Formula Class Cohesion (CC) (Bonja & Kidanmariam, 2006) CC = Ratio of the summation of the similarities between all pairs of methods to the total number of pairs of methods. The similarity between methods i and j is defined as: (11) Similarity(i, j) = | I i  I j | | I i  I j | where, I i and I j are the sets of attributes referenced by methods i and j a1a1 m1m1 m4m4 a4a4 class C1 a1a1 m1m1 m4m4 a4a4 class C2 a1a1 m1m1 m4m4 a4a4 class C3 a1a1 m1m1 m4m4 a4a4 class C4 (12) Class Cohesion Metric (SCOM) (Fernandez & Pena, 2006) CC = Ratio of the summation of the similarities between all pairs of methods to the total number of pairs of methods. The similarity between methods i and j is defined as: where, ℓ is the number of attributes Similarity(i, j) = | I i  I j | min(| I i |, | I j |) | I i  I j | ℓ. (13) where ℓ is the number of attributes, k is the number of methods, and x i is the number of methods that reference attribute i Low-level design Similarity-based Class Cohesion (LSCC) (Al Dallal & Briand, 2009) 0 otherwise LSCC(C) = x i (x i – 1) ℓk (k – 1) i=1  ℓ 1if k = 1 if k = 0 or ℓ = 0 CC(C1) = 1 / 2 CC(C2) = 1 CC(C3) = 1 CC(C4) = 1 / 2 CC: SCOM(C1) = 2 / 4 = 1 / 2 SCOM(C2) = 2 / / 4 = 1 SCOM(C3) = 2 / / 4 = 1 SCOM(C4) = 2 / 4 = 1 / 2 SCOM: LSCC(C1) = 2 / (4*4*3) = 2 / 48 = 1 / 24 LSCC(C2) = (2 + 2) / (4*4*3) = 1 / 12 LSCC(C3) = 1 / 12 LSCC(C4) = 1 / 24 LSCC:

21 Example Metrics (5) Class Cohesion MetricDefinition / Formula Normalized Hamming Distance (NHD) (Counsell et al., 2006) (15) Cohesion Among Methods in a Class (CAMC) (Counsell et al., 2006) CAMC = a/kℓ, where ℓ is the number of distinct parameter types, k is the number of methods, and a is the summation of the number of distinct parameter types of each method in the class. Note that this formula is applied on the model that does not include the “self” parameter type used by all methods (14) NHD = 1 – x j (k – x j ) ℓk (k – 1) j=1  ℓ 2, where k and ℓ are defined above for CAMC and x j is the number of methods that have a parameter of type j Scaled Normalized Hamming Distance (SNHD) (Counsell et al., 2006) (16) SNHD = the closeness of the NHD metric to the maximum value of NHD compared to the minimum value

22 Cohesion Metrics Performance Comparison class C2 class C3 class C4 class C1 class C5 class C6 class C7 class C8 class C9 LCOM LCOM LCOM /12 5/6 11/12 2/3 13/12 7/12 2/3 1 LCOM4Coh 5/16 3/8 5/16 1/2 3/16 9/16 1/2 1/4 LCOM5 TCC 1/6 2/6 1/6 1/2 1/6 LCC 1/6 2/6 3/6 4/6 2/6 3/6 DC D 1/6 1/3 2/3 DC I 1/6 1/3 1/2 2/3 CC 1/2 1 1 SCOM 1/2 1 1 LSCC 1/24 1/12 1/24 3/6 2/6 3/6 4/6 2/6 3/6 5/6 4/ / /24 or 5/6? or 3/6?