Presentation is loading. Please wait.

Presentation is loading. Please wait.

Department of Computer Science, Graduate School of Information Science & Technology, Osaka University A Metric-based Approach for Reconstructing Methods.

Published byBruno Bryant Modified over 8 years ago

Similar presentations

Presentation on theme: "Department of Computer Science, Graduate School of Information Science & Technology, Osaka University A Metric-based Approach for Reconstructing Methods."— Presentation transcript:

1 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University A Metric-based Approach for Reconstructing Methods in Object-Oriented Systems Tatsuya Miyake, Yoshiki Higo, Katsuro Inoue

2 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Research Overview Propose a method that automates some of refactoring steps – Identify where the software should be refactored – Determine which refactoring pattern should be applied – Estimate the effect of the refactoring ⇒ Support to perform appropriate refactorings with low cost. 2016/6/27WoSQ2008 2

3 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Refactoring 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 Procedure – Step 1: Identify where the software should be refactored – Step 2: Determine which refactoring pattern should be applied to the identified place – Step 3: Estimate the effect of the refactoring – Step 4: Apply the refactoring – Step 5: Maintain the consistency between the refactored program code and other software artifacts 2016/6/27WoSQ2008 3

4 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Issue with Refactoring Refactoring often requires the high costs  A good deal of knowledge and experiences There are few skillful developers Inappropriate refactorings may be performed instead of appropriate ones  A lot of time and energy It is difficult to precisely estimate the effect of refactorings on the early stage of the refactoring  The refactoring may not be worth the cost 2016/6/27WoSQ2008 4

5 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Research Purpose Automatization of a part of refactoring process  Reduction of the refactoring cost  Appropriate refactoring Improve the maintainability  Efficient and effective refactoring Estimate the effect of refactoring 2016/6/27WoSQ2008 5

6 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Proposal Technique -Overview- Identify where the software should be refactored  Target: A code fragment within a method Several software metrics Coupling of block statements with their surrounding code  Vertical coupling  Horizontal coupling Determine which refactoring pattern should be applied to the identified place  By reference to the used variables and the invoked methods  Turn the fragment into a new method Extract Method Pull Up Method Move Method Estimate the effect of the determined refactoring  Based on the change of software metrics 2016/6/27WoSQ2008 6

7 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Proposal Technique -Overview- Identify where the software should be refactored  Target: A code fragment within a method Several software metrics Coupling of block statements with their surrounding code  Vertical coupling  Horizontal coupling Determine which refactoring pattern should be applied to the identified place  By reference to the used variables and the invoked methods  Turn the fragment into a new method Extract Method Pull Up Method Move Method Estimate the effect of the determined refactoring  Based on the change of software metrics 2016/6/27WoSQ2008 7

8 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Proposal Technique -Overview- Identify where the software should be refactored  Target: A code fragment within a method Several software metrics Coupling of block statements with their surrounding code  Vertical coupling  Horizontal coupling Determine which refactoring pattern should be applied to the identified place  By reference to the used variables and the invoked methods  Turn the fragment into a new method Extract Method Pull Up Method Move Method Estimate the effect of the determined refactoring  Based on the change of software metrics 2016/6/27WoSQ2008 8

9 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Identify where the software should be refactored Measure metrics on each method and each block statements in it  Cyclomatic complexity The complexity of control logics The number of linearly independent paths from the start node to the end one of a graph  Represented by the number of conditional expressions plus 1  LOC (Lines Of Code) Used for measurement of the identified fragment’s occupancy rate (OR) in the method  ALV ( Available Local Variables ) Identify the block statements having undesirable metrics value with their surrounding code 2016/6/27WoSQ2008 9

10 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Local Variable Encapsulation 2016/6/27WoSQ2008 10 To hide unused local variables may improve maintainability of a mehtod  Extract the code fragment as a new method  Access by arguments and a return value as needed Local variable encapsulation ⇒ Reduce the number of available variables Attributes of classes should be hidden for improving maintainability  Declare a field as a private attribute  Use accessor methods as needed Field encapsulation

11 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Example of Local Variable Encapsulation 2016/6/27WoSQ2008 11 public void sample ( ) { int i = 0; String str; int j = 0; boolean b; String str2; ・ ・ while( hoge() ) { int k = bar(); jar( str ); foo(i, k); } ・ } There are 6 available variables i, str, j, b, str2, k j, b, str2 are not used public void sample ( ) { int i = 0; String str; int j = 0; boolean b; String str2; ・ newMethod(i, str); ・ } void newMethod(int i, String str) { while( hoge() ) { int k = bar(); jar( str ); foo(i, k); } } Available variables are only i, str, k Only the used variables are referenced as arguments Refactoring ALV : 6 ALV : 5 ALV : 3 The unused variables, j, b, str2, are hidden

12 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Proposal Technique -Overview- Identify where the software should be refactored  Target: A code fragment within a method Several software metrics Coupling of block statements with their surrounding code  Vertical coupling  Horizontal coupling Determine which refactoring pattern should be applied to the identified place  By reference to the used variables and the invoked methods  Turn the fragment into a new method Extract Method Pull Up Method Move Method Estimate the effect of the determined refactoring  Based on the change of software metrics 2016/6/27WoSQ2008 12

13 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Relation between block statements 2016/6/27WoSQ2008 13 public void sample ( ) { int i = 0; String str; while( hoge() ) { str = “string”; if( jar( I ) ) { make(str); } foo(i); for( int j = 0; j < I ; j++) { sam( i ); if( log ) { System.out.println(i); } ・ while( ) { bar(i); make(str); } sample ( ) while iffor if Vertical relation – Between a block statement and its outer or inner block statements. Horizontal relation – Between two block statements in the same scope

14 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Vertical Coupling between Block Statements A coupling between block statements that have the vertical relation each other Measure based on the number of outer variables that are the used local variables defined outside the bock statement – NRV ( Number of Referenced Variables ) Pass the values to the new method as arguments, If extract the new method – NAV ( Number of Assigned Variables ) The new method may have to return the assigned variables as return value 2016/6/27WoSQ2008 14

15 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Example of Vertical Coupling ~ Low Coupling~ 2016/6/27WoSQ2008 15 public void sample ( ) { ・ newMethod(); ・ } private void newMethod ( ) { while( hoge() ) { int i = 0; String str = “string”; foo(i); } public void sample ( ) { ・ while( hoge() ) { int i = 0; String str = “string”; foo(i); } ・ } Just extract as a new method NRV : 0 NAV : 0

16 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Example of Vertical Coupling ~ Strong Coupling~ 2016/6/27WoSQ2008 16 public void sample ( ) { int i = 0; boolean bool ; String str; str = newMethod(i, bool); ・ return str; } private String newMethod (int i, boolean bool) { String str; while( hoge() ) { str = “string”; foo(i); bar( bool ); } return str; } public void sample ( ) { int i = 0; boolean bool ; String str; ・ while( hoge() ) { str = “string”; foo(i); bar( bool ); } ・ return str; } NRV : 2 NAV : 1 Two outer variables, i and bool, are referenced These value have to be passed to the new method as arguments Extract as a new method An outer variable, str, is assigned str is subsequently referenced Have to return a value of the assigned variable If the number of assigned outer variables is more than one Strong vertical coupling ⇒ a lot of operations to complete the refactoring

17 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Horizontal Coupling between Block Statements A coupling between two block statements that have horizontal relation each other Measured based on the number and the kind of data flows between the two block statements 2016/6/27WoSQ2008 17 Strong couplingLow coupling Usage of the same variables in both block statements no data flow Extract as a new single method Extract as different new methods The kind of data flows Refactoring threshold indirect data flows

18 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University public void newMethod2 (int i, String str){ while( ) { bar(i); make(str); } public String newMethod1 (int i) { String str; while( hoge() ) { str = “string”; foo(i); } return str; } Example of Horizontal Coupling ~Strong coupling~ 2016/6/27WoSQ2008 18 public void sample ( ) { int i = 0; String str; ・ while( hoge() ) { str = “string”; foo(i); } ・ while( ) { bar(i); make(str); } ・ } Extract as different new methods public void sample ( ) { int i = 0; String str; ・ str = newMethod1 ( i ); ・ newMethod2( i, str ); ・ } Two variables, str and i, are referenced or assigned Two same variables, str and i, are referenced or assigned The two variables, str and i, have to be shared

19 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Example of Horizontal Coupling ~Strong coupling~ 2016/6/27WoSQ2008 19 public void sample ( ) { int i = 0; String str; ・ while( hoge() ) { str = “string”; foo(i); } ・ while( ) { bar(i); make(str); } ・ } Public void sample () { int i = 0; ・ newMethod ( i ); ・ } public String newMethod1 (int i) { String str; while( hoge() ) { str = “string”; foo(i); } ・ while( ) { bar(i); make(str); } Extract as a new single method Easier than extracting as different methods All you have to do is to pass variable i The signature is simple

20 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Example of Horizontal Coupling ～ Low coupling ～ Extract as a new single method  The signature of the new method is simple Few arguments Need no return value Extract as different new methods  Division based on functionality Each variable has its own role 2016/6/27WoSQ2008 20 public void sample ( ) { int i = 0; String str; ・ while( hoge() ) { str = “string”; foo(i); } ・ String str2 = str; ・ while( ) { bar(); make(str2); } ・ } There is no outer variable used in the both while statement A data flow between two while-statement by the assignment of str to str2

21 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Proposal Technique -Overview- Identify where the software should be refactored  Target: A code fragment within a method Several software metrics Coupling of block statements with their surrounding code  Vertical coupling  Horizontal coupling Determine which refactoring pattern should be applied to the identified place  By reference to the used variables and the invoked methods  Turn the fragment into a new method Extract Method Pull Up Method Move Method Estimate the effect of the determined refactoring  Based on the change of software metrics 2016/6/27WoSQ2008 21

22 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Determine which refactoring should be applied Determine based on what kinds of members are used in the target fragment  Members of its own class are mainly used ⇒ Apply “Extract Method”  Only members of the super class are used ⇒ Apply “Pull Up Method”  Members of other classes are mainly used Local feature envy  Only the identified spot may be interested in other classes Extract the identified spot as a method of the class whose members are most used ⇒ Apply both “Extract Method” and “Move Method” 2016/6/27WoSQ2008 22

23 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Proposal Technique -Overview- Identify where the software should be refactored  Target: A code fragment within a method Several software metrics Coupling of block statements with their surrounding code  Vertical coupling  Horizontal coupling Determine which refactoring pattern should be applied to the identified place  By reference to the used variables and the invoked methods  Turn the fragment into a new method Extract Method Pull Up Method Move Method Estimate the effect of the determined refactoring  Based on the change of software metrics 2016/6/27WoSQ2008 23

24 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Estimate the effect of refactoring Definition of the effect of refactoring  Change of complexity metrics values Cyclomatic complexity  The number of conditional expressions in the extracted code LOC( Lines of Code)  The number of lines of the code extracted as a new method ALV( Available Local Variables )  The number of local variable declaration in the extracted code Coupling between classes  May change in the case of applying “Move Method” 2016/6/27WoSQ2008 24

25 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Proposal Technique -Overview- Identify where the software should be refactored  Target: A code fragment within a method Several software metrics Coupling of block statements with their surrounding code  Vertical coupling  Horizontal coupling Determine which refactoring pattern should be applied to the identified place  By reference to the used variables and the invoked methods  Turn the fragment into a new method Extract Method Pull Up Method Move Method Estimate the effect of the determined refactoring  Based on the change of software metrics 2016/6/27WoSQ2008 25

26 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Experiment Target language: Java Target software  High-quality software JHotDraw  Low-quality software Programs written by undergraduate students  Several versions of the same software Evaluation standard  Adequacy of automatic identification of the spot should be refactored  Adequacy of automatic determination of the applied refactoring  Change of complexity metrics value 2016/6/27WoSQ2008 26

27 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Case Study 2016/6/27WoSQ2008 27 The number of available outer variable is 13 The number of really used outer variable is 3 Low vertical coupling ↓ It is easy to extract from outer block statements Low horizontal coupling ↓ The upper for- statement is not included in the extracted part There is no outer variable referenced in both “for-statement” Identification is adequate from functional standpoint because of the code comment

28 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Summary In this study, we  proposed ALV of new metrics for representing the maintainability of software  proposed the method that automates some of refactoring steps based on ALV and other metrics  Showed there are cases where our method is effective 2016/6/27WoSQ2008 28

29 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Future work We are going to  experiment more to confirm the adequacy of our refactoring method Quantitative data derived from the result of our planned experiment Evaluation of the result of our method by developers  investigate the relation between ALV and the quality of software Whether there is correlation between ALV and bugs or not  propose and implement program slicing method to identify more adequately the surrounding code of the block statement 2016/6/27WoSQ2008 29

30 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Thank you for your attention Please speak slowly, if you have some questions. 2016/6/27WoSQ2008 30

31 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Target software High-quality software  JHotDraw5.3b About 18000 loc About 288 classes Low-quality software  Programs written by under undergraduate students Support code clone analysis About 3000 loc About 107 classes Several versions of the same software 2016/6/27WoSQ2008 31

32 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Refactoring 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 Effect of Refactoring – Enhance readability of a target software – Improve software design Maintainability Scalability Reusability – Find bugs of a target software 2016/6/27WoSQ2008 32

33 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Procedure of Refactoring Step 1: Identify where the software should be refactored  Long Method  Complicated Control Structure Step 2: Determine which refactoring should be applied to the identified place  Various refactoring patterns have been proposed Step 3: Estimate the effect of the refactoring  Prevent from performing inefficient or ineffective refactorings Step 4: Apply the refactoring Step 5: Maintain the consistency between the refactored program code and other software artifacts 2016/6/27WoSQ2008 33

34 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Example of applying “Extract Method” 2016/6/27WoSQ2008 34 class A { public boolean field1; public void a2(); public void a3(); public void sample ( ) { ・ while( field1() ) { a2(); b.b1(); a3(); } ・ } Class B { public b1(); public b2(); } Members of the same class are mainly used class A { public boolean field1; public void a2(); public void a3(); public void sample(); public void newMethod ( ) { while( field1() ) { a2(); b.b1(); a3(); } Class B { public b1(); public b2(); } Extract as a new method of the same class

35 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Example of applying “Pull Up Method” 2016/6/27WoSQ2008 35 class A extends B{ public void a1(); public void a2(); public void a3(); public void sample ( ) { a1(); a2(); while( fieldB ) { b1(); b2(); } a3(); } class B { protected bool fieldB; protected void b1(); protected void b2(); } class A extends B{ ・・・・・・・・・・ public void sample ( ) { a1(); a2(); newSuperMethod(); a3(); } class B { protected bool fieldB; protected void b1(); protected void b2(); protected void newSuperMethod() { while( fieldB ) { b1(); b2(); } Extract as a new method of the super class Using only members of the super class in the extraction target

36 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Case Study (2/2) 2016/6/27WoSQ2008 36 Low vertical coupling with owner method Low horizontal coupling Strong horizontal coupling

37 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Determine which refactoring should be applied Determine based on what kinds of members are used in the target fragment  Members of its own class are mainly used ⇒ Apply “Extract Method”  Only members of the super class are used ⇒ Apply “Pull Up Method”  Members of other classes are mainly used Local feature envy  Only the identified spot may be interested in other classes Extract the identified spot as a method of the class whose members are most used ⇒ Apply both “Extract Method” and “Move Method” 2016/6/27WoSQ2008 37

38 Department of Computer Science, Graduate School of Information Science & Technology, Osaka University Estimate the effect of refactoring Definition of the effect of refactoring  Change of complexity metrics values Cyclomatic complexity  The number of conditional expressions in the extracted code LOC( Lines of Code)  The number of lines of the code extracted as a new method ALV( Available Local Variables )  The number of local variable declaration in the extracted code Coupling between classes  May change in the case of applying “Move Method” 2016/6/27WoSQ2008 38

Download ppt "Department of Computer Science, Graduate School of Information Science & Technology, Osaka University A Metric-based Approach for Reconstructing Methods."

Similar presentations

Based on Java Software Development, 5th Ed. By Lewis &Loftus

Based on Java Software Development, 5th Ed. By Lewis &Loftus
Quality of a Class Abstraction: Coupling & Cohesion Michael L. Collard, Ph.D. Department of Computer Science Kent State University.

Quality of a Class Abstraction: Coupling & Cohesion Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Chapter 10 THINKING IN OBJECTS 1 Object Oriented programming Instructor: Dr. Essam H. Houssein.

Chapter 10 THINKING IN OBJECTS 1 Object Oriented programming Instructor: Dr. Essam H. Houssein.
Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.

Refactoring Overview  What is refactoring?  What are four good reasons to refactor?  When should you refactor?  What is a bad smell (relative to refactoring.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Extracting Code.

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University Extracting Code.
1 Static Testing: defect prevention SIM3302. 2 objectives Able to list various type of structured group examinations (manual checking) Able to statically.

1 Static Testing: defect prevention SIM objectives Able to list various type of structured group examinations (manual checking) Able to statically.
Lecture 3: Topics If-then-else Operator precedence While loops Static methods Recursion.

Lecture 3: Topics If-then-else Operator precedence While loops Static methods Recursion.
Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.

Inheritance and Class Hierarchies Chapter 3. Chapter 3: Inheritance and Class Hierarchies2 Chapter Objectives To understand inheritance and how it facilitates.
Fall 2007CS 2251 Inheritance and Class Hierarchies Chapter 3.

Fall 2007CS 2251 Inheritance and Class Hierarchies Chapter 3.
OOP in Java Nelson Padua-Perez Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.

OOP in Java Nelson Padua-Perez Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
Module: Definition ● A logical collection of related program entities ● Not necessarily a physical concept, e.g., file, function, class, package ● Often.

Module: Definition ● A logical collection of related program entities ● Not necessarily a physical concept, e.g., file, function, class, package ● Often.
1 Chapter 7 l Inheritance Basics l Programming with Inheritance l Dynamic Binding and Polymorphism Inheritance.

1 Chapter 7 l Inheritance Basics l Programming with Inheritance l Dynamic Binding and Polymorphism Inheritance.
ASP.NET Programming with C# and SQL Server First Edition

ASP.NET Programming with C# and SQL Server First Edition
Refactoring Support Tool: Cancer Yoshiki Higo Osaka University.

Refactoring Support Tool: Cancer Yoshiki Higo Osaka University.
Algorithm Programming 2 89-211 Coding Advices Bar-Ilan University 2005-2006 תשס ו by Moshe Fresko.

Algorithm Programming Coding Advices Bar-Ilan University תשס " ו by Moshe Fresko.
Lecture From Chapter 6 & 7 2015/8/10 1 Method of Classes.

Lecture From Chapter 6 & /8/10 1 Method of Classes.
Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.

Chapter 9: Coupling & Cohesion Omar Meqdadi SE 273 Lecture 9 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Debugging Support.

Software Engineering Laboratory, Department of Computer Science, Graduate School of Information Science and Technology, Osaka University 1 Debugging Support.
Chapter 8 More Object Concepts

Chapter 8 More Object Concepts
2006/09/19AOAsia 21 Towards Locating a Functional Concern Based on a Program Slicing Technique Takashi Ishio 1,2, Ryusuke Niitani 2 and Katsuro Inoue 2.

2006/09/19AOAsia 21 Towards Locating a Functional Concern Based on a Program Slicing Technique Takashi Ishio 1,2, Ryusuke Niitani 2 and Katsuro Inoue 2.

Similar presentations

Ads by Google