Towards a Severity and Activity based Assessment of Code Smells

Available online at www.sciencedirect.com Available online at www.sciencedirect.com

Available online at www.sciencedirect.com

ScienceDirect

Procedia Computer Science 00 (2017) 000–000 Procedia Computer Science (2017)460–467 000–000 Procedia Computer Science 11600(2017)

www.elsevier.com/locate/procedia www.elsevier.com/locate/procedia

2nd International Conference on Computer Science and Computational Intelligence 2017, 2nd International Conference on Computer Science andBali, Computational ICCSCI 2017, 13-14 October 2017, Indonesia Intelligence 2017, ICCSCI 2017, 13-14 October 2017, Bali, Indonesia

Towards Towards aa Severity Severity and and Activity Activity based based Assessment Assessment of of Code Code Smells Smells a a

Harris Kristanto Husienaa , Muhammad Firdaus Harunbb , Horst Lichterbb Harris Kristanto Husien , Muhammad Firdaus Harun , Horst Lichter

King Mongkut’s University of Technology North Bangkok, The Sirindhorn International Thai-German Graduate School of Engineering, King Mongkut’s University of Technology North Bangkok,Bangkok, The Sirindhorn International Thai-German Graduate School of Engineering, Thailand Bangkok, Thailand b RWTH Aachen University, Research Group Software Construction, Aachen, Germany b RWTH Aachen University, Research Group Software Construction, Aachen, Germany

Abstract Abstract Code smells are the structural weaknesses which reside in a software system. They evolve negatively over time reducing the Code structural weaknesses which reside in a software They evolveand negatively over time systemsmells qualityare i.e.,themaintainability, understandability etc. Therefore, theysystem. should be detected prioritized based onreducing criticalitythe in system i.e., maintainability, understandability etc. should be detected prioritized based in order toquality be refactored. Most of the existing approaches areTherefore, based on they severity score, but little and works have been doneontocriticality include the order to be refactored. Most of the existing approaches are based on severity score, but little works have been done to include the information from changes history. Thus, we introduce a Harmfulness Model that integrates both information: severity and changes information history. Thus, we introduce a Harmfulness Model thatbased integrates information: severity and changes history (i.e., from code changes smells activity). This study characterizes a god class activity on itsboth severity and change frequency of the history (i.e., code smells activity). study characterizes godtwo class activity based severity and be change frequency of and the JHotDraw open source system. TheThis result indicates that therea are main activities ofon goditsclass that can assessed as active JHotDraw open source system. The result indicates that there are two main activities of god class that can be assessed as active and passive smells. In fact, an active god class can be differentiated as strong, stable, and ameliorate smells while a passive god class passive In fact, an active god class differentiated as strong, stable, and while passive god score class has one smells. type called dormant. Besides that, can frombeseverity and activity information, theameliorate model cansmells compute theaharmfulness has called that, from and activitylevel information, the model can compute harmfulness score and one alsotype indicate thedormant. degree ofBesides harmfulness level.severity The harmfulness may be useful to improve changethe likelihood estimation and also indicate the degree of harmfulness level. The harmfulness level may be useful to improve change likelihood estimation and refactoring candidates prioritization. and refactoring candidates prioritization. c© 2017  2017 The The Authors. Authors. Published Published by by Elsevier Elsevier B.V. B.V. c 2017  The Authors. Published by Elsevier B.V. Peer-review Computer Science Science and and ComPeer-reviewunder underresponsibility responsibility of of the the scientific scientific committee committee of of the the 2nd 2nd International International Conference Conference on on Computer Peer-review under responsibility putational Intelligence 2017.2017.of the scientific committee of the 2nd International Conference on Computer Science and ComComputational Intelligence putational Intelligence 2017. Keywords: Code smell activity, Code smell impact, Change-likelihood, Evolution, Harmful code smell Keywords: Code smell activity, Code smell impact, Change-likelihood, Evolution, Harmful code smell

1. Introduction 1. Introduction Code smells indicate a structural weakness either in code or design. Those smells can be detected by a set of Code smells structural weakness eithercritical in code or design. Those smells can be detected by a set of 1 dedicated metricsindicate and area prioritized based on their score 1 . However, some very critical smells may not be dedicated metrics and are prioritized based on their critical score . However, some very critical smells mayand nothas be exploits some code smells important or urgent to be refactored immediately 22 . For example, although a class . For example, although a class exploits some code smells and has important or urgent to be refactored immediately a high critical score, it can be used as it is stable and does not change over time. Therefore, this class should not be aconsidered high critical score, it can refactoring be used as itcandidate. is stable and does not change over time. Therefore, this class should not be as an important considered as an important refactoring candidate. E-mail addresses: [email protected] (Harris Kristanto Husien)., [email protected] (Muhammad Firdaus E-mail addresses: [email protected] Harun)., [email protected] (Horst Lichter). (Harris Kristanto Husien)., [email protected] (Muhammad Firdaus Harun)., [email protected] (Horst Lichter). c 2017 The Authors. Published by Elsevier B.V. 1877-0509  cunder 1877-0509  2017 The Authors. of Published by Elsevier B.V. the 2nd International Conference on Computer Science and Computational IntelliPeer-review the scientific committee 1877-0509 © 2017responsibility The Authors. Published Elsevier of B.V. Peer-review responsibility of the scientificby committee of the 2nd International Conference on Computer Science and Computational Intelligence 2017. under Peer-review under responsibility of the scientific committee of the 2nd International Conference on Computer Science and gence 2017. Computational Intelligence 2017. 10.1016/j.procs.2017.10.040



2

Harris Kristanto Husien et al. / Procedia Computer Science 116 (2017) 460–467 H.K. Husien et al. / Procedia Computer Science 00 (2017) 000–000

461

To understand the evolution of smells and hence their impact, an analysis of historical information on smells is required 3 , as the historical information conserves the code smell’s activities and changes in the past. This information may give valuable hints for future refactoring candidates, in terms of change-proneness and the types of changes. Recently, several studies on code smell activity have been published. For example, 4 introduces the concept of an active smell and 5 introduces stable and persistent code smells, which are further classified as harmless or harmful. Unfortunately, the published studies focus on unstable code smells (code smells that were changed frequently in the past), even though these changes might eliminate the code smells. In addition, to classify the stability of code smells, those studies rely only on the changes that increase or decrease the code smells presence or intensity (neglecting other changes). Therefore, the definition and classification of code smell activity can be revised and further extended. Moreover, the relationship between the activity and severity of code smells is not clearly understood. Therefore, in this paper we explore the characteristics of code smells based on its history and measure its effects. We improve a hint to identify critical smells that subject to change by characterizing its behavior based on its activity and severity. We also introduce a harmfulness level and its four quadrant model. By measuring the degree of harmfulness, we can signify its existence and prioritization for refactoring. The remainder of this paper is organized as follows: We propose a Harmfulness Code Smell Model in Section 2. Section 3 describes the initial case study. The results of this case study are explained in Section 4 and evaluated in Section 5. Finally, we conclude the paper and suggest some future works in Section 6. 2. Harmfulness Code Smell Model Rapu et al. classify code smell harmfulness by considering two historical measurements, stability and persistency 5 . The stability of a class shows how many times it has been classified as unstable. A class is unstable, if a specified metric value changes after a modification of the class has been performed. If the modification does not change the metric value, it is labeled as stable. The persistency of a class refers to how long it has been suspected as a certain type of code smell. It is computed as the fraction of the number of versions in which the class exhibits a code smell over the total number of versions. When the persistency of a class reaches 95%, this class will be classified as persistent, otherwise, it will be classified as not-persistent. Furthermore, with these two historical measurements, Rapu et al. define harmful god classes as unstable and not-persistent, in contrast harmless god classes are stable and persistent. This paper tries to redefine Rapu et al. code smell harmfulness model by refining stability, persistency and harmful classification. Firstly, we refine Rapu’s stability according to the performed changes. As they are treated uniformly as long as the class measurements are modified. We argue that this classification can be enhanced since a more refined stability classification can give more meaning to the harmful code smell. For example, a class that tends to increase their measurement over time is expected to have a more harmful effect than classes that tend to decrease their measurement. Therefore, we introduce activeness as the degree of class stability to represent how active a class is. Secondly, we introduce impact as a redefinition of Rapu’s persistency. The persistency, in Rapu’s model, is only based on the number how often a class is being suspected as a certain type of code smell. We argue that the severity of this suspected class and its evolution will give more meaning to the harmful effect of code smell. As an example, when the suspected class is severe and tends to increase its severity, it should be more harmful since this has a higher impact on the maintenance. Therefore, our impact variable extends the class persistency with the class complexity and severity. By aggregating the activeness and impact, we refine the harmful classification. Rapu et al. specifically classify god classes as either harmful, harmless or not classified. The not classified category requires manual inspection since Rapu et al. argued that the historical information could not improve the code smell detection (metrics-based detection 6 ). However, we argue that our activeness and impact variables can outperform the not-classified problem. Through activeness and impact, we can see the types of changes and code smell severity respectively. As an example, when a code smell has high activeness but low impact, it can be classified as quite dangerous (since it has high changelikelihood). And, a code smell that has low activeness but high impact, can be classified as less dangerous since it has low change-likelihood (but it is still dangerous since it has high severity). This paper also contributes by introducing the harmfulness score of a code smell. When two code smells are classified as harmful, it is hard to determine which code smell that is more harmful using Rapu’s model. Therefore,

Harris Kristanto Husien et al. / Procedia Computer Science 116 (2017) 460–467 H.K. Husien et al. / Procedia Computer Science 00 (2017) 000–000

462

3

our harmfulness score gives a hint to decide which code smell is more harmful (for code smells in the same harmful category). To sum up, we argue that our harmful classification and score may indicate fined-grain behaviour of code smells since our model is more fine-grained than Rapu’s harmful model. The overview of our proposed harmfulness model is depicted in Figure 1. The details of each elements are presented in the following subsections.

Fig. 1. Harmfulness Model

2.1. Program Units and Code Smells Every system (s) consists of a set of program units (pu), e.g. components, interfaces, packages, or classes. A program unit may exhibit several code smells (cs) of defined code smell types. Furthermore, program units exist in different versions. This leads to the following basic definitions: PU s : set of all program units of a system s with pu ∈ PU s , put : program unit pu in version t, CS : set of code smell types with cs ∈ CS (e.g. CS = {God Class, Data Class,...}) , Mcs : set of metrics to detect code smells of type cs ∈ CS , PUcs : set of program units exhibiting code smells of type cs with pucs ∈ PU cs , obtained by applying Mcs on PU s , tncs : the total number of program units in PUcs

2.2. Severity of Code Smells Radu in 1 introduces the characteristic severity of a code smell to rank its smelliness among other code smells. The severity is computed by applying a set of metrics known as the Most Critical Symptom (MCS) of that code smell type. For example, the severity of god class code smells is computed based on the Access To Foreign Data (ATFD) metric. The set of metrics representing the MCS of a code smell type cs is denominated MCS cs ⊂ Mcs . Hence, the severity of a code smell of type cs of a program unit pu is defined as follows: severity : PU cs → R where function severity applies the metrics of MCS cs on a given program unit to compute the intensity value.

(1)



Harris Kristanto Husien et al. / Procedia Computer Science 116 (2017) 460–467 H.K. Husien et al. / Procedia Computer Science 00 (2017) 000–000

4

463

2.3. Activeness of Code Smells To express the activity of a code smell, we introduce the function activeness, returning a value representing the activity degrees: Dormant (D), Ameliorate Active (AA), Stable Active (SA), and Strong Active (STA). A code smell is a strong active, if the performed changes increase its severity. It is a stable active, if the changes only affect the severity of the code smell a little. If its severity decreases after changes have been made, the code smell is a ameliorate active. Finally, if the changes do not change the severity, the activity of the smell is assessed as dormant. Based on these semantics, the activeness of a program unit pu in version t is defined as follows: activeness : PU cs × N∗ → {D, AA, S A, S T A}  S T A severity(put ) ≥ severity(put−1 ) × IAIF cs   t t−1  S A severity(pucst−1 cs ) × DAIF < severity(pucs ) < severity(pucs ) × IAIF activeness(pucs , t) =  t  cs ) × DAIF  AA severity(pucst ) ≤ severity(put−1 t−1 D

(2) (3)

severity(pucs ) = severity(pucs )

with IAIF (increasing activeness impact factor) : IAIF > 1 and DAIF (decreasing activeness impact factor) : 0 ≤ DAIF ≤ 1. 2.4. Complexity

According to 7 , the maintenance effort is strongly related to code churn and the size of a program unit, as large units that are often changed are more error-prone which lead to extra maintenance efforts. Obviously, the maintenance effort also depends on the complexity of a program unit, since a more complex unit will need more effort to be understood, analyzed and refactored. The complexity of a program unit can be measured by referring to one of any known complexity metrics (CM), for example cyclomatic complexity 8 or cognitive complexity 9 . To normalize this metric, its value is divided by the Lines of Code (LOC) of the considered program unit, to represent the density of complexity per line of code. complexity : PU cs → R

with

complexity(pucs ) =

CM(pucs ) LOC(pucs )

(4)

2.5. Impact of Code Smells Based on the introduced characteristics complexity and severity, we define the impact value of a code smell as the product of complexity and severity: impactValue : PU cs → R

with

impactValue(pucs ) = complexity(pucs ) × severity(pucs )

(5)

In order to compare the impact values of all program units exhibiting a code smell of type cs, the tuples (pu, impactValue) are collected version-wise in a set (I MPtcs ) which has a descending ordering regarding the impact values of the program units. The impactRank of a program unit pu in version t exhibiting a code smell of type cs is thus represented by its index in the respective set I MPtcs , and is defined as follows: impactRank : PU cs × N∗ → N∗

impactRank(pucs , t) = index(putcs , I MPtcs )

with

(6)

Analogous to the definition of activeness of a code smell, we equally distribute the determined impactRank values into four partitions (low impact (LI), medium impact (MI), high impact (HI), very high impact (VHI)) using the following function: impact : PU cs × N∗ → {LI, MI, HI, V HI}  |I MPt |  V HI impactRank(pucs , t) ≤ 4 cs     |I MPtcs |   < impactRank(pucs , t) ≤  HI 4 impact(pucs , t) =  |I MPtcs |   MI < impactRank(pucs , t) ≤   2   3×|I MPtcs |  LI impactRank(pu , t) > cs

4

(7) |I MPtcs | 2 3×|I MPtcs | 4

(8)

Harris Kristanto Husien et al. / Procedia Computer Science 116 (2017) 460–467 H.K. Husien et al. / Procedia Computer Science 00 (2017) 000–000

464

5

2.6. Harmfulness of Code Smells Harmfulness of a program unit is expressed by multiplying the version-wise accumulated activity (ACT) and impact (IMP) values of a program unit as follows: harm f ulness : PU cs × N∗ a STA  n      aS A ACT (pucs , n) =   a    AA i=1

aD

with aD , aAA , aS A , aS T A ∈ N0 i V HI  n      iHI I MP(pucs , n) =   i    MI i=1

iLI

→ N0

with

↔ activeness(pucs , i) = S T A ↔ activeness(pucs , i) = S A ↔ activeness(pucs , i) = AA ↔ activeness(pucs , i) = D

(9) n : number of considered versions

(10)

: 0 ≤ aD ≤ aAA ≤ aS A ≤ aS T A ↔ impact(pucs , i) = V HI ↔ impact(pucs , i) = HI ↔ impact(pucs , i) = MI ↔ impact(pucs , i) = LI

(11)

with iLI , i MI , iHI , iV HI ∈ N0 : 0 ≤ iLI ≤ i MI ≤ iHI ≤ iV HI harm f ulness(pucs , n) = ACT (pucs , n) × I MP(pucs , n)

(12)

Obviously, the harmfulness value of a program unit depends on the number of considered versions. Therefore, these values need to be normalized and furthermore mapped to a simple scale of so-called harmfulness levels. As usual, we define the following four levels: low (L), medium (M), high (H), and very high (VH). To map concrete harmfulness values, we consider the respective ACT and IMP values of the program unit. Figure 2 depicts the underlying model, which defines four quadrants, each defining a harmfulness level, based on low and high range ACT and IMP values.

Fig. 2. Four Quadrants Model of Harmfulness Level

Accordingly, the harmfulness level of a program unit is low, if its respective ACT and IMP values are in the low range. On the contrary, its level is very high, if both values are in the high range. Hence, the harmfulness level (harmfulnessLevel) of a program unit pu exhibiting a code smell of type cs and considering n versions is defined as follows: Let maxACT = n × aS T A , minACT = n × aD , maxI MP = n × iV HI and minI MP = n × iLI then, lowRangeACT = [minACT , ..., maxACT × POR], highRangeACT = (maxACT × POR) + 1, ..., maxACT ], lowRangeI MP = [minI MP , ..., maxI MP × POR] and highRangeI MP = (maxI MP × POR) + 1, ..., maxI MP ] with POR (proportion of range) : 0 ≤ POR ≤ 1.  V H ACT (pu , n) ∈ highRange  cs ACT ∧ I MP(pucs , n) ∈ highRangeI MP     H ACT (pu , n) ∈ highRange  cs ACT ∧ I MP(pucs , n) ∈ lowRangeI MP harm f ulnessLevel(pucs , n) =   M ACT (pu , n) ∈ lowRange  cs ACT ∧ I MP(pucs , n) ∈ highRangeI MP    L ACT (pucs , n) ∈ lowRangeACT ∧ I MP(pucs , n) ∈ lowRangeI MP

(13)



Harris Kristanto Husien et al. / Procedia Computer Science 116 (2017) 460–467 H.K. Husien et al. / Procedia Computer Science 00 (2017) 000–000

6

harm f ulnessLevel : PU cs × N∗ → {L, M, H, V H}

465

(14)

To sum up, the harmfulness level of a program unit exhibiting a code smell of type cs represents the future trend of error- and change-proneness and maintenance effort of the considered program unit, based on its code smell history. 3. Initial Case Study The harmfulness code smell model composes several variables that are allowed to be defined by developers. The usage of these variables, instead of predefined constants for these variables, is to allow the developers in specifying different values or data that are used by the model. In this study, we aim to find out the effect of different parameter sets applied to variables of activeness and impact. These two variables were focused as they give highest factor to harmfulness computation. Moreover, there are three parameter sets that are used in this study, namely linear, exponential and power of two parameters (Table 1). The result, as depicted in figure 3, shows that the distribution of harmfulness classification for the exponential and power of two parameters are more or less similar. Table 1. Values of the applied Parameter Sets

Activeness/Impact Dormant / Low Impact Ameliorate Active / Medium Impact Stable Active / High Impact Strong Active / Very High Impact

Linear Parameters (n) 0 1 2 3

Exponential Parameters (n2 ) 0 1 4 9

Power of Two Parameters (2n ) 1 2 4 8

The context of this case study is the god class that exists in an open-source system, namely JHotDraw. The god class was chosen due to its bad effect on the maintenance 10,7 . To detect these god classes, we utilize PMD 11 , which uses Lanza and Radu’s god class detection strategy. JHotDraw is a Java GUI framework for drawing technical or structured 2D graphics. It has been developed since October 2000 12 , which makes it has a variety of historical information. The historical information includes the bugfixing, refactoring, improvement and new feature implementation. We investigated these types of historical changes in the six versions of JHotDraw, starting from version 7.1 to 7.6. The results show that the classes in JHotDraw in these versions tend to be active (frequently changed). The variety of class activeness in JHotDraw, makes it a very good sample for exemplifying different parameters applied to our activeness variable. The following section will further detail the result of this case study. 4. Result The results obtained by applying different input parameter sets (Table 1) to our model in an initial case study are shown in figure 3. The resulting different harmfulness level classifications indicates that the proposed harmfulness model strongly relies on the proposed parameter sets. Therefore, different parameters can be used to express the developer’s point of view about activeness and impact of relevant code smells. As an example, as described in table 1, the linear parameters can be used to finely grain activeness and impact. In contrast, the exponential and power of two parameters can be used to give more weight to the higher degrees of activeness (Strong Active) and impact (Very High Impact). Moreover, the power of two parameters set defines Dormant and Low Impact as 1, which is intended to increase the code smell harmful effect over time (even though the respective class has no activity and low impact). Furthermore, figure 3 visualizes the relationship between the parameter sets and the harmfulness level classification. It can be seen that the classification resulting from the linear parameters are different to the results of the exponential and power of two parameters. It also shows that the exponential and power of two parameters lead a to more or less similar harmfulness level distribution. By applying the linear parameters, figure 3 shows that the god classes in the six JHotDraw versions are most likely classified as Very High. While in the case of the exponential and power of two parameters, the god classes are most likely classified as High or Low. We manually tracked the activity and impact values of these god classes in all six

466

Harris Kristanto Husien et al. / Procedia Computer Science 116 (2017) 460–467 H.K. Husien et al. / Procedia Computer Science 00 (2017) 000–000

7

Fig. 3. Total Number of Classified God Classes Based on Harmfulness Level for Each Parameter Set

versions. The findings clearly showed that the linear parameters lead to a bad classification indicator, compared to the exponential and power of two parameters. It is because of god classes that have a medium degree of activeness (Ameliorate Active, Dormant) and impact (Medium Impact, Low Impact) are classified as Very High applying the linear parameters. While in the case of the exponential and power of two parameters, these god classes are classified as High, Medium or Low (according to their activeness and impact degree). Moreover, only god classes that have a very high impact and a high activeness are classified as Very High when applying the exponential and power of two parameters (although there are some Dormant classes that are classified as Very High by the power of two parameters). Therefore, we argue that in this case the exponential and power of two parameters determine the harmfulness level classification better as they finely classify the harmfulness level. As mentioned earlier, the parameters Dormant and Low Impact are set to 1 in the power of two parameters set. The problem with this definition is when a god class activity is classified as Dormant, its activeness still contributes to the activeness and harmful effect computation. It also affects the harmfulness level classification, where god classes that are Dormant in their lifetime are classified as Very High applying the power of two parameters. However, using the exponential parameters, the corresponding god classes are classified as Medium (high impact but low activity). Through these findings, we claim that the exponential parameters are the most suitable parameters to depict the activeness and impact of a god class. 5. Evaluation When changes are performed, these changes can be rooted to refactoring, bug-fixing, new feature implementation, etc. We believe that these changes supposedly have a high correlation with our model. As an example, when a refactoring was performed, the harmfulness level of a code smell has to decrease or at least to remain the same. And, if a new feature is implemented, it may increase the code smell severity which affects its harmfulness level. Therefore, based on our results, we try to evaluate the ability of our model to reflect the performed changes. There are two types of changes that we focused on; refactoring and new feature implementation. The information about these changes is manually gathered from the JHotDraw Git log. In our model, we introduce Ameliorate Active as an activity when the code smell severity is decreasing due to performed changes. We argue that changes like refactoring contribute to decrease the code smell severity. This decrease could be observed e.g. for class AbstractAttributedCompositeFigure in JHotDraw version 7.2 and 7.3.1 (depicted in Table 2). In the earlier version, the harmfulness level of this class is classified as High. However, since a refactoring occurred in version 7.3.1, the harmfulness level of this class turned to Low. Furthermore, changes were also performed to class SVGImageFigure in version 7.3.1. However, these changes were about implementing a new feature to this class. These changes increased the severity of this class which further increased the class harmfulness level (from High to Very High).



8

Harris Kristanto Husien et al. / Procedia Computer Science 116 (2017) 460–467 H.K. Husien et al. / Procedia Computer Science 00 (2017) 000–000

467

Table 2. Relation between Ameliorate Active and Harmfulness Level Version

Class Name

Activity

Harmfulness Level

7.1 7.2 7.3.1

AbstractAttributedCompositeFigure AbstractAttributedCompositeFigure AbstractAttributedCompositeFigure

Strong Active Ameliorate Active Ameliorate Active

High High Low

Table 3. Relation between Strong Active and Harmfulness Level Version

Class Name

Activity

Harmfulness Level

7.1 7.2 7.3.1

SVGImageFigure SVGImageFigure SVGImageFigure

Strong Active Stable Active Strong Active

High High Very High

Based on the results of our case study on these classes and their evaluation, we conclude that in this case study our model has the ability to reflect the increasing or decreasing of harmfulness level based on the performed changes. In addition, a manual inspection of the source-code and its historical information was also performed by Rapu et al. 5 . The result shows that, by adding information related to class evolution, the accuracy of detection-result was improved. This result motivated our case study to evaluate our model’s ability in reflecting performed changes. 6. Conclusion and Future Works In this paper, we introduce the Harmfulness Code Smell model as an approach to determine and classify the harmful effect of a code smell. It takes two parameter sets; activeness and impact. The activeness describes the change frequency of a code smell as well as the type of changes (whether it increases, decreases or does not modify the code smell severity). We classified activeness into Strong Active, Stable Active, Ameliorate Active and Dormant. We also introduce impact as the product of code smell severity and its complexity. We classified a code smell impact into Very High Impact, High Impact, Medium Impact and Low Impact. Moreover, we showed that different parameter sets can be applied to express the activeness and impact. Therefore, our model is flexible to express the developer’s perspective on their code. Our model also performs well in depicting the changes, for example when refactoring has been made, the harmful effect of a code smell will be moved to a lower level. In future, we plan to apply this model to other code smell types, identify the effect of other parameter sets and conduct expert reviews to evaluate and improve our model. References 1. Marinescu, R.. Assessing technical debt by identifying design flaws in software systems. IBM Journal of Research and Development 2012; 56(5):9:1–9:13. 2. Santiago A., V., Claudia, M., J. Andrs, D.P.. An approach to prioritize code smells for refactoring. Automated Software Engineering 2016; 23(3):501–532. 3. Tsantalis, N., Chatzigeorgiou, A.. Ranking refactoring suggestions based on historical volatility. In: 2011 15th European Conference on Software Maintenance and Reengineering. 2011, p. 25–34. 4. Chatzigeorgiou, A., Manakos, A.. Investigating the evolution of code smells in object-oriented systems. Innov Syst Softw Eng 2014;10(1):3– 18. 5. Rapu, D., Ducasse, S., Grba, T., Marinescu, R.. Using history information to improve design flaws detection. In: Eighth European Conference on Software Maintenance and Reengineering, 2004. CSMR 2004. Proceedings. 2004, p. 223–232. 6. Marinescu, R.. Detection strategies: metrics-based rules for detecting design flaws. In: 20th IEEE International Conference on Software Maintenance, 2004. Proceedings. 2004, p. 350–359. 7. Sjberg, D.I.K., Yamashita, A., Anda, B.C.D., Mockus, A., Dyb, T.. Quantifying the effect of code smells on maintenance effort. IEEE Transactions on Software Engineering 2013;39(8):1144–1156. 8. McCabe, T.J.. A complexity measure. IEEE Transactions on Software Engineering 1976;SE-2(4):308–320. 9. Wang, Y., Shao, J.. Measurement of the cognitive functional complexity of software. In: The Second IEEE International Conference on Cognitive Informatics, 2003. Proceedings. 2003, p. 67–74. 10. Olbrich, S.M., Cruzes, D.S., Sjberg, D.I.K.. Are all code smells harmful? a study of god classes and brain classes in the evolution of three open source systems. In: 2010 IEEE International Conference on Software Maintenance. 2010, p. 1–10. 11. PMD, . A souce code analyzer. 2015. URL http://pmd.sourceforge.net/pmd-5.3.2/. 12. Penta, M.D., Cerulo, L., Gueheneuc, Y.G., Antoniol, G.. An empirical study of the relationships between design pattern roles and class change proneness. In: 2008 IEEE International Conference on Software Maintenance. 2008, p. 217–226.