## 4 Identification of Deficient Classes Within Object-Oriented Programming Languages  
The novel identification approach, presented in Section 3, was implemented and evaluated within the context of three major object-oriented programming languages. The main goal was to detect deficient classes within the software developed in Java, C++ and C#. Following the steps of the approach presented in Figure 1 and with Algorithm 1, the identification of deficient classes is presented in three parts. Within the Section 4.1, the criteria for evaluation was set, whereas the evaluation and identification of potentially deficient classes is presented in Section 4.2, and the manual assessment of potentially deficient classes with expert judgment, that also validates the proposed identification approach, is presented in Section 5. Determination of Quality Aspects, Selection of Software Metrics and Derivation of Corresponding Threshold Values  
The evaluation of software classes was done based on four different categories reflecting different quality aspects within object-oriented software. [PERSON] and [PERSON] [16] proposed an overview pyramid that includes three quality aspects: size and complexity, coupling and inheritance. We expanded and adjusted the proposed aspects and evaluated software classes based on (1) source code **size**; (2) class **complexity**; (3) **coupling** with other classes and (4) class **cohesion**. Each of the presented quality aspects was evaluated with one or more software metrics. The software metrics used to evaluate each aspect were chosen from the list of available metrics supported by the Understand tool [40], which was used to collect software metrics values. The Understand tool [40] enables the collection of software metrics values for multiple programminglanguages. With the use of a single tool we eliminated the risk arising from the challenge presented by [PERSON] et al. [41], claiming that different software metric tools provide inconsistent values of the same software metric. This can be attributed to different implementations of the same software metric [30]. Therefore, we used a tool that allows collecting software metrics values for Java, C++ and C#. Among the available software metrics in the Understand tool [40], eight of them were chosen. Quality aspects of size and complexity combine three metrics each, whereas coupling and cohesion were each evaluated by a single software metric. The chosen metrics are presented in Table 1. The table lists software metrics as named within the used tool together with the abbreviation for each metric that is used later in the paper. Source code size and complexity are probably the most frequently used aspects when evaluating software quality [16]. The easiest way to determine the size of software is by counting lines [42]. Different software metrics count different types of lines, like the total number of lines, blank lines or comment lines. We decided to use the most expressive type: lines of code. Therefore, _CountLineCode (SLOC)_ is the first metric within our study that evaluates the quality aspect of source code size. Since just a large number of lines of code does not mean that the program entity is problematic, we also assessed the average size of methods in the evaluated class. This is rated with a software metric _AvgLineCode (AMS)_. As claimed by [PERSON] and [PERSON] [43], when large methods prevail in a class, this can be a sign of deficiency. Therefore, with a combination of metrics _CountLineCode_ and _AvgLineCode_, large classes which appropriately distribute source code into methods do not represent risky entities and are not identified as potentially problematic. The size of a program entity can also be evaluated with the software metric _CountDeclMethodAll (NOM)_ which represents several methods in a class, including inherited ones. A large number of methods is usually reflected in a large number of source code lines. Another basic aspect of quality is the complexity of the program entities.