1 / 33

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

tyrell
Download Presentation

Refactoring Effect Estimation Based on Complexity Metrics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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

  3. 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

  4. 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

  5. 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

  6. 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.

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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()

  14. 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()

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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.

  23. 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.

  24. 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.

  25. 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

  26. 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

  27. 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

  28. 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

  29. 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

  30. 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

  31. 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

  32. 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

More Related