# Predicting Software Cohesion Metrics with Machine Learning Techniques
## 2 Related Work  
Many metrics and tools have been developed in the literature to measure the cohesion of the software. According to the measured cohesion value, it is possible to comment on the quality of the software. In this section, prominent studies to measure the cohesion of the software are examined. LCOM1 [9] was described by Chidamber and Kemerer in 1991. It is calculated as the number of method pairs that do not share attributes between. The LCOM1 metric is not normalized between 0 and 1. For LCOM1, the minimum value is 0 and the maximum value is the number of method pairs in a class. Since the LCOM metric measures incompatibility, a low LCOM value means a high cohesion. LCOM2 [10] was described by Chidamber and Kemerer in 1994. Similar to LCOM1, the LCOM2 metric is not normalized, and a low LCOM2 value indicates a high cohesion. Two parameters are calculated for the calculation of the LCOM2 metric. P is calculated as the number of method pairs that do not share attributes, and Q is calculated as the number of method pairs that share attributes among them. P-Q gives the value of LCOM2. LCOM3 [11] was proposed by Hitz and Montazeri in 1995. Unlike LCOM1 and LCOM2, the LCOM3 metric provides the calculation using the graphical structure. In the graph created, the nodes show the methods, while the links show the relationship between the methods. If two methods share attributes between them, in other words, if they use same attribute, a link is drawn between those two methods. When the connected nodes are counted as one, the number of independent components provides the value of LCOM3. The LCOM4 [12] metric was also proposed by Hitz and Montazeri in 1995. It uses a similar calculation method as LCOM3. The only difference with LCOM3 is that in LCOM3, only the relationship of methods is checked according to whether they share attributesbetween them, while in LCOM4, in addition to this, the case of methods calling each other is also checked. The LCOM5 [13] metric was created by Henderson and Sellors in 1996. The LCOM5 metric can take values between 0 and 1. In order to calculate the LCOM5 metric, they utilized the number of attributes, the number of methods, and the sum of the number of attributes used by each method. TCC and LCC [14] metrics were developed by Bieman and Kang in 1995. A, B, and C are the methods of the class. When method A calls method B, A and B are directly linked. When method A calls method B and method B calls method C, A and C are indirectly related. TCC and LCC metrics also use graph structures such as LCOM3 and LOM4. While TCC only considers direct connections, LCC also considers indirect connections. LSCC [6] was proposed by Dallal and Briand in 2012. The LSCC metric aims not only to measure whether there is cohesion between the two methods, but also to measure the degree of cohesion, if there is any. The LSCC metric is normalized between 0 and 1. The closer the value is to 1, the better the cohesion. In addition, according to Dallal and Briand's experimental study, LSCC was shown to be one of the top three cohesion metrics in identifying fault occurrences. LSCC is also a normalized cohesion metric between 0 and 1. In the study conducted by Alzahrani et al. [15] in 2019, the client-based cohesion metric (CCC) was proposed, and it was emphasized that this metric is a powerful factor in predicting maintainability. It was thought that cohesion metrics should be obtained at the design stage, before the implementation stage. It is thought that it cannot fully reflect the class cohesion since the inter-method and method-attribute connections are not yet clear at the design stage. The modified approach on the LCOM (MALCOM) metric [16] was proposed in the study by Ganesh and Raj. This metric categorizes the cohesion as low, medium, and high according to the result. The difference with the LCOM metric is that while LCOM only checks for the presence of cohesion, MALCOM also measures the level of cohesion.