Refactoring Effect Estimation Based on Complexity Metrics

Refactoring Effect Estimation Based on Complexity Metrics Yoshiki Higo, Yoshihiro Matsumoto, Shinji Kusumoto, Katuro Inoue

What’s Refactoring? • A set of operations to improve internal attributes of a software system without changing the external behavior of it • One of trenchant countermeasures to handle large-scale and complex software systems

Refactoring operating procedure • Identify where the software should be refactored • Determine which refactoring should be applied to the identified place • Guarantee that the applied refactoring preserves the behavior • Apply the refactoring • Assess the effect of the refactoring on quality characteristics of the software • Maintain the consistency between the refactored program code and other software artifacts

Refactoring requires costs • A refactoring requires a certain cost to be completed • Its impact should justify the cost • It is difficult to precisely estimate the effect of refactorings on the early stage of the refactoring • Inappropriate refactorings may be performed instead of appropriate ones • Inappropriate refactorings become software systems less maintainable or require much cost to be completed

Proposal Technique -Overview- • We propose a method estimating refactoring effect • INPUT: refactorings that developers are going to perform • OUTPUT: effect estimation of each of the refactorings • The method estimates refactoring effect from the following viewpoints (by using CK metrics suite) • How coupling between classes will change, • How cohesion of each class will change, • How inheritance relationships between classes will change

CK Metrics Suite • Measures complexity of object-oriented software[1] • Better indicator to estimate occurrences of faults than other metrics [2] [1] S. Chidamber and C. Kemerer. A metric suite for object-oriented design. IEEE Transactions on Software Engineering, 25(5):476–493, Jun 1994. [2] V. R. Basili, L. C. Briand, and W. L. Melo. A validation of object-oriented design metrics as quality indicators. IEEE Transactions on Software Engineering, 22(10):751–761, Oct 1996.

output input A B C D STEP1 STEP2 STEP6 B B’ A A D D C C’ revised structure STEP4 original structure program comparison result STEP3 STEP5 WMC DIT NOC CBO FRC LCOM WMC DIT NOC CBO FRC LCOM STEP6 A ・・・・・・・・・・・・・・・・・・ A ・・・・・・・・・・・・・・・・・・ B ・・・・・・・・・・・・・・・・・・ B’ ・・・・・・・・・・・・・・・・・・ C ・・・・・・・・・・・・・・・・・・ C’ ・・・・・・・・・・・・・・・・・・ refactoring pattern D ・・・・・・・・・・・・・・・・・・ D ・・・・・・・・・・・・・・・・・・ metrics of the original structure metrics of the revised structure Proposal Technique

Proposal Technique -STEP1- C D B A B B’ A A D D C C’ revised structure original structure program WMC DIT NOC CBO FRC LCOM WMC DIT NOC CBO FRC LCOM A ・・・・・・・・・・・・・・・・・・ A ・・・・・・・・・・・・・・・・・・ B ・・・・・・・・・・・・・・・・・・ B’ ・・・・・・・・・・・・・・・・・・ C ・・・・・・・・・・・・・・・・・・ C’ ・・・・・・・・・・・・・・・・・・ refactoring pattern D ・・・・・・・・・・・・・・・・・・ D ・・・・・・・・・・・・・・・・・・ metrics of the original structure metrics of the revised structure output output input STEP1 STEP2 STEP6 STEP4 comparison result STEP3 STEP5 STEP6 • The whole of the target program is parsed to construct a structure representing it • The structure includes all information required to measure CK metrics 8

Proposal Technique -STEP2- C D B A B B’ A A D D C C’ revised structure original structure program WMC DIT NOC CBO FRC LCOM WMC DIT NOC CBO FRC LCOM A ・・・・・・・・・・・・・・・・・・ A ・・・・・・・・・・・・・・・・・・ B ・・・・・・・・・・・・・・・・・・ B’ ・・・・・・・・・・・・・・・・・・ C ・・・・・・・・・・・・・・・・・・ C’ ・・・・・・・・・・・・・・・・・・ refactoring pattern D ・・・・・・・・・・・・・・・・・・ D ・・・・・・・・・・・・・・・・・・ metrics of the original structure metrics of the revised structure output input STEP1 STEP2 STEP6 STEP4 comparison result STEP3 STEP5 STEP6 • CK metrics are measured from the structure • These metrics represent the complexity of the original program 9

Proposal Technique -STEP3- C D B A B B’ A A D D C C’ revised structure original structure program WMC DIT NOC CBO FRC LCOM WMC DIT NOC CBO FRC LCOM A ・・・・・・・・・・・・・・・・・・ A ・・・・・・・・・・・・・・・・・・ B ・・・・・・・・・・・・・・・・・・ B’ ・・・・・・・・・・・・・・・・・・ C ・・・・・・・・・・・・・・・・・・ C’ ・・・・・・・・・・・・・・・・・・ refactoring pattern D ・・・・・・・・・・・・・・・・・・ D ・・・・・・・・・・・・・・・・・・ metrics of the original structure metrics of the revised structure output input STEP1 STEP2 STEP6 STEP4 comparison result STEP3 STEP5 STEP6 • The refactorings that developers are going to perform are input • Where of the target program is refactored • How the part is refactored 10

Proposal Technique -STEP4- C D B A B B’ A A D D C C’ revised structure original structure program WMC DIT NOC CBO FRC LCOM WMC DIT NOC CBO FRC LCOM A ・・・・・・・・・・・・・・・・・・ A ・・・・・・・・・・・・・・・・・・ B ・・・・・・・・・・・・・・・・・・ B’ ・・・・・・・・・・・・・・・・・・ C ・・・・・・・・・・・・・・・・・・ C’ ・・・・・・・・・・・・・・・・・・ refactoring pattern D ・・・・・・・・・・・・・・・・・・ D ・・・・・・・・・・・・・・・・・・ metrics of the original structure metrics of the revised structure output input STEP1 STEP2 STEP6 STEP4 comparison result STEP3 STEP5 STEP6 • The structure is revised based on the refactorings input in STEP3 11

call a1( ) call a1( ) A a1( )a2( ) call a1( ) D d1( ) D’ B’ B A’ call a1( ) d1( ) b1( )a1( ) C’ C b1( ) a2( ) c1( ) c1( ) call a1( ) STEP4 • It is impossible to fully-automatically revise the structure • Some operations require developer’s intention • STEP4 consists of automatic and interactive change Example: method a1 in class A is moved to class B Original program Revised program

A a1( )a2( ) D ・・ d1( ) ・・・・ C a1( ) move automatically c1( ) modify automatically (ClassB)a1() STEP4 -Automatic change- • Automatic change is completely automatic processing, it doesn’t require developer’s interventions • In the example, • Delete method a1 from class A, and add it to class B, • In class B, a1 invocations are changed as internal method invocations B Method b1() offset instruction b1( ) *** (ClassA)instanceA.a1()

D A ・・・・ a2( ) d1( ) ・・・・・・・・ C c1( ) Can’t modify automatically Can’t modify automatically (ClassB)???.a1() (ClassB)???.a1() STEP4 -Interactive change- • Some operations require developer’s interventions, they cannot be completed automatically • In the example, • A developer needs to determine which instance invokes method a1 in class C and D • After receiving her intervention, the method revises the structure based on it B Method d1() Method c1() offset instruction offset instruction b1( )a1( ) *** (ClassA)instanceA.a1() *** (ClassA)instanceA.a1()

Proposal Technique -STEP5- C D B A B B’ A A D D C C’ revised structure original structure program WMC DIT NOC CBO FRC LCOM WMC DIT NOC CBO FRC LCOM A ・・・・・・・・・・・・・・・・・・ A ・・・・・・・・・・・・・・・・・・ B ・・・・・・・・・・・・・・・・・・ B’ ・・・・・・・・・・・・・・・・・・ C ・・・・・・・・・・・・・・・・・・ C’ ・・・・・・・・・・・・・・・・・・ refactoring pattern D ・・・・・・・・・・・・・・・・・・ D ・・・・・・・・・・・・・・・・・・ metrics of the original structure metrics of the revised structure output input STEP1 STEP2 STEP6 STEP4 comparison result STEP3 STEP5 STEP6 • CK metrics are measured from the revised structure • These metrics represent the complexity of the revised program 15

Proposal Technique -STEP6- C D B A B B’ A A D D C C’ revised structure original structure program WMC DIT NOC CBO FRC LCOM WMC DIT NOC CBO FRC LCOM A ・・・・・・・・・・・・・・・・・・ A ・・・・・・・・・・・・・・・・・・ B ・・・・・・・・・・・・・・・・・・ B’ ・・・・・・・・・・・・・・・・・・ C ・・・・・・・・・・・・・・・・・・ C’ ・・・・・・・・・・・・・・・・・・ refactoring pattern D ・・・・・・・・・・・・・・・・・・ D ・・・・・・・・・・・・・・・・・・ metrics of the original structure metrics of the revised structure output input STEP1 STEP2 STEP6 STEP4 comparison result STEP3 STEP5 STEP6 The technique outputs how the complexity of the target software will change by performing the refactoring 16

The output is Change Rate, which is a quantitative result of the effect estimation The below formula represents the change rate of metric WMC in the example A, B, C, and D are classes in the original structure A’, B’, C’, and D’ are ones in the revised structure WMC(x) is the value of metric WMC for class x Only the classes affected by the refactoring are used for calculating change rate Change Rate

Implementation (a prototype) • Target language: Java • Structure representing the program: Bytecode • There are useful and practical tools/libraries to handle bytecode • Target refactorings: • Move Field, Pull Up Field, Pull Down Field • Move Method, Pull Up Method, Pull Down Method • Extract Class, Extract SuperClass, Extract SubClass

A case study -Outline- • We conducted a small case study to evaluate the usefulness of the proposed technique • Target is a program developed by a single master student • The number of classes is 37, the LOC is 4,815 • It has been maintained for about 1 year • We manually identified which modules had undesirable conditions with the master student • We thought out 4 refactoring candidates to improve the modules

CL GVP BP FLGV CP Extract Panel ep; setExtractPanel() setStartClass() A case study -Identified Problem- • Class ComponentList (CL) was designed not related to GUI originally • But, after 1-year maintenance, CL has a function related to GUI • The function consists of 1 field and 2 methods GUI classes

CL GVP BP FLGV CP Extract Panel ep; setExtractPanel() setStartClass() A case study -Refactoring Candidates- • The variable and the methods should be moved to another class related to GUI • CASE1: FeatureLocationGraphViewer (FLGV) • CASE2: BirdPanel (BP) • CASE3: ComponentPanel (CP) • CASE4: GraphViewPanel (GVP) GUI classes

A case study -Tool’s result- • All candidates will not change the change rates of metrics WMC, DIT, NOC, and LCOM • All candidates will have no or a little bit of change on metric RFC • CASE1 will be able to greatly reduce the change rate of metric CBO while all of other candidates will increase it.

A case study -Tool’s result- • All candidates will not change the change rates of metrics WMC, DIT, NOC, and LCOM • All candidates will have no or a little bit of change on metric RFC • CASE1 will be able to greatly reduce the change rate of metric CBO while all of other candidates will increase it

A case study -Master Student’s Decision- • Before tool’s application • The master student selected CASE3 • He thought that class CL had a similar function to the class of CASE3 • His decision was based on his instinct rather than objective basis like bug information, software metrics, or design patterns • After tool’s application • He recognized that the tool’s estimation was better than his own determination, and adopted the CASE1 refactoring

A case study -Measurement Precision- • After the estimation, we actually performed each of the 4 refactorings on the source coderespectively • CK metrics were measured from the refactored source code, and change rates were calculated • All of the metrics and change rates were the same as ones measured from the revised bytecode

Validity of the method • No research has revealed obvious foundation that good refactoring lead to lower CK measures • When a maintainer perform a refactoring, there is a obvious goal of it • The proposal technique enables the maintainer to know whether the goal can be accomplished or not • Side-effects of the refactoring can be represented by the change rate • The maintainer can avoid regretting the refactoring after actually performing it

Limitations -the case study- • The examinee is a single master student • We need to conduct case studies involving more examinees, which consist of different level programmers • The target program size is not practical • Only the change of complexity metrics values was considered as the effects of refactorings

Limitation -the case study- • The examinee is a single master student • The target program size is not practical • We need to conduct case studies on more practical size software systems • But, this case study revealed that it is difficult to perform effective refactorings on even a small-size program • Only the change of complexity metrics values was considered as the effects of refactorings

Limitation -proposal technique- • The examinee is a single master student • The target program size is not practical • Only the change of complexity metrics was considered as the effects of refactorings • Real refactorings require source code modification cost and regression test cost • In order to estimate refactoring effectiveness more precisely, we have to considerer those costs

Conclusion and Future Works • In this study, we • proposed a new technique to estimate refactoring effect • Implemented a software tool based on the proposal • Applied it to a small software system • We are going to • re-implement the tool for revising not bytecode but source code, which can achieve automated source code modification • handle other refactoring patterns

Refactoring Effect Estimation Based on Complexity Metrics