Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Refactoring Effect Estimation Based on Complexity Metrics Yoshiki Higo, Yoshihiro Matsumoto, Shinji Kusumoto, Katuro Inoue

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 2 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Refactoring operating procedure 1. Identify where the software should be refactored 2. Determine which refactoring should be applied to the identified place 3. Guarantee that the applied refactoring preserves the behavior 4. Apply the refactoring 5. Assess the effect of the refactoring on quality characteristics of the software 6. Maintain the consistency between the refactored program code and other software artifacts 3

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Refactoring requires costs A refactoring requires a certain cost to be completed  Its impact should justify the cost 4 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 5

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University CK Metrics Suite Measures complexity of object-oriented software [1] 6 Better indicator to estimate occurrences of faults than other metrics [2] InheritanceDIT (Depth of Inheritance Tree) NOC (Number Of Children) CouplingRFC (Response For a Class) CBO (Coupling Between Object-class) CohesionWMC (Weighted Method per Class) LCOM (Lack Of Cohesion Method) [1] S. Chidamber and C. Kemerer. A metric suite for object-oriented design. IEEE Transactions on Software Engineering, 25(5):476–493, Jun [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.

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Proposal Technique 7 refactoring pattern original structure A B C D revised structure A B’ C’ D program D C B A ・・・ D C B A LCOMFRCCBONOCDITWMC metrics of the original structure ・・・ D C’ ・・・ B’ ・・・ A LCOMFRCCBONOCDITWMC metrics of the revised structure input comparison result output STEP1STEP2 STEP3 STEP4 STEP5 STEP6

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Proposal Technique -STEP1- 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 output refactoring pattern original structure A B C D revised structure A B’ C’ D program D C B A ・・・ D C B A LCOMFRCCBONOCDITWMC metrics of the original structure ・・・ D C’ ・・・ B’ ・・・ A LCOMFRCCBONOCDITWMC metrics of the revised structure input comparison result output STEP1STEP2 STEP3 STEP4 STEP5 STEP6

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Proposal Technique -STEP2- CK metrics are measured from the structure  These metrics represent the complexity of the original program 9 refactoring pattern original structure A B C D revised structure A B’ C’ D program D C B A ・・・ D C B A LCOMFRCCBONOCDITWMC metrics of the original structure ・・・ D C’ ・・・ B’ ・・・ A LCOMFRCCBONOCDITWMC metrics of the revised structure input comparison result output STEP1STEP2 STEP3 STEP4 STEP5 STEP6

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Proposal Technique -STEP3- The refactorings that developers are going to perform are input  Where of the target program is refactored  How the part is refactored 10 refactoring pattern original structure A B C D revised structure A B’ C’ D program D C B A ・・・ D C B A LCOMFRCCBONOCDITWMC metrics of the original structure ・・・ D C’ ・・・ B’ ・・・ A LCOMFRCCBONOCDITWMC metrics of the revised structure input comparison result output STEP1STEP2 STEP3 STEP4 STEP5 STEP6

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Proposal Technique -STEP4- The structure is revised based on the refactorings input in STEP3 11 refactoring pattern original structure A B C D revised structure A B’ C’ D program D C B A ・・・ D C B A LCOMFRCCBONOCDITWMC metrics of the original structure ・・・ D C’ ・・・ B’ ・・・ A LCOMFRCCBONOCDITWMC metrics of the revised structure input comparison result output STEP1STEP2 STEP3 STEP4 STEP5 STEP6

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 A a1( ) a2( ) call a1( ) D d1( ) B b1( ) C c1( ) call a1( ) D’ d1( ) C’ c1( ) B’ b1( ) a1( ) A’ a2( ) Original programRevised program

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 A a1( ) a2( ) D d1( ) C c1( ) B b1( ) *** instructionoffset Method b1() ・ ・ ・ ・ ・ ・ (ClassA)instanceA.a1() (ClassB)a1() modify automatically move automatically a1( )

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 D d1( ) C c1( ) B b1( ) a1( ) (ClassA)instanceA.a1() *** instructionoffset Method d1() ・ ・ ・ ・ ・ ・ (ClassA)instanceA.a1() *** instructionoffset Method c1() ・ ・ ・ ・ ・ ・ (ClassB)???.a1() Can’t modify automatically A a2( )

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Proposal Technique -STEP5- CK metrics are measured from the revised structure  These metrics represent the complexity of the revised program 15 refactoring pattern original structure A B C D revised structure A B’ C’ D program D C B A ・・・ D C B A LCOMFRCCBONOCDITWMC metrics of the original structure ・・・ D C’ ・・・ B’ ・・・ A LCOMFRCCBONOCDITWMC metrics of the revised structure input comparison result output STEP1STEP2 STEP3 STEP4 STEP5 STEP6

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Proposal Technique -STEP6- The technique outputs how the complexity of the target software will change by performing the refactoring 16 refactoring pattern original structure A B C D revised structure A B’ C’ D program D C B A ・・・ D C B A LCOMFRCCBONOCDITWMC metrics of the original structure ・・・ D C’ ・・・ B’ ・・・ A LCOMFRCCBONOCDITWMC metrics of the revised structure input comparison result output STEP1STEP2 STEP3 STEP4 STEP5 STEP6

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Change Rate 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 17

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University A case study -Identified Problem- Class ComponentList (CL) was designed not related to GUI originally CL Extract Panel ep; setExtractPanel() setStartClass() GVP BPFLGV CP GUI classes But, after 1-year maintenance, CL has a function related to GUI  The function consists of 1 field and 2 methods

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University A case study -Refactoring Candidates- The variable and the methods should be moved to another class related to GUI CL Extract Panel ep; setExtractPanel() setStartClass() GVP BPFLGV CP GUI classes CASE1: FeatureLocationGraphViewer (FLGV) CASE2: BirdPanel (BP) CASE3: ComponentPanel (CP) CASE4: GraphViewPanel (GVP)

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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. CASE1CASE2CASE3CASE4 WMC0.0 DIT0.0 NOC0.0 CBO RFC LCOM0.00

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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. CASE1CASE2CASE3CASE4 WMC0.0 DIT0.0 NOC0.0 CBO RFC LCOM0.00

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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. CASE1CASE2CASE3CASE4 WMC0.0 DIT0.0 NOC0.0 CBO RFC LCOM0.00

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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 CASE1CASE2CASE3CASE4 WMC0.0 DIT0.0 NOC0.0 CBO RFC LCOM0.00

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University A case study -Measurement Precision- After the estimation, we actually performed each of the 4 refactorings on the source code respectively 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 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

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University