Refactoring Effect Estimation Based on Complexity Metrics

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


Refactoring requires costs

A refactoring requires a certain cost to be completedIts 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


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


CK Metrics Suite Measures complexity of object-oriented software [1]

6

Better indicator to estimate occurrences of faults than other metrics [2]

Inheritance DIT (Depth of Inheritance Tree)NOC (Number Of Children)

Coupling RFC (Response For a Class)CBO (Coupling Between Object-class)

Cohesion WMC (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 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.


Proposal Technique

7

refactoring pattern

original structure

A

B

CD

revised structure

A

B’

C’D

program

DC

BA

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C

・・・・・・

・・・

・・・

・・・

・・・

B

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC

metrics of the original structure

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C’

・・・・・・

・・・

・・・

・・・

・・・

B’

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC

metrics of the revised structure

input

comparison result

output

STEP1 STEP2

STEP3

STEP4

STEP5

STEP6

STEP6


Proposal Technique -STEP1-

The whole of the target program is parsed to construct a structure representing itThe structure includes all information required to

measure CK metrics8

output

refactoring pattern

original structure

A

B

CD

revised structure

A

B’

C’D

program

DC

BA

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C

・・・・・・

・・・

・・・

・・・

・・・

B

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C’

・・・・・・

・・・

・・・

・・・

・・・

B’

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


input

comparison result

output

STEP1 STEP2

STEP3

STEP4

STEP5

STEP6

STEP6



CK metrics are measured from the structureThese metrics represent the complexity of the original

program

9

refactoring pattern

original structure

A

B

CD

revised structure

A

B’

C’D

program

DC

BA

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C

・・・・・・

・・・

・・・

・・・

・・・

B

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C’

・・・・・・

・・・

・・・

・・・

・・・

B’

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


input

comparison result

output

STEP1 STEP2

STEP3

STEP4

STEP5

STEP6

STEP6



The refactorings that developers are going to perform are inputWhere of the target program is refactoredHow the part is refactored

10

refactoring pattern

original structure

A

B

CD

revised structure

A

B’

C’D

program

DC

BA

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C

・・・・・・

・・・

・・・

・・・

・・・

B

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C’

・・・・・・

・・・

・・・

・・・

・・・

B’

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


input

comparison result

output

STEP1 STEP2

STEP3

STEP4

STEP5

STEP6

STEP6



The structure is revised based on the refactorings input in STEP3

11

refactoring pattern

original structure

A

B

CD

revised structure

A

B’

C’D

program

DC

BA

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C

・・・・・・

・・・

・・・

・・・

・・・

B

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C’

・・・・・・

・・・

・・・

・・・

・・・

B’

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


input

comparison result

output

STEP1 STEP2

STEP3

STEP4

STEP5

STEP6

STEP6


STEP4 It is impossible to fully-automatically revise the

structureSome 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( ) call a1( )

call a1( )

D

d1( )

B

b1( )

C

c1( )

call a1( )

call a1( )

D’

d1( )

C’

c1( )

B’

b1( )a1( )

A’

a2( )

Original program Revised program


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


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() (ClassB)???.a1()

Can’t modify automatically

Can’t modify automatically

A

a2( )



CK metrics are measured from the revised structureThese metrics represent the complexity of the revised

program

15

refactoring pattern

original structure

A

B

CD

revised structure

A

B’

C’D

program

DC

BA

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C

・・・・・・

・・・

・・・

・・・

・・・

B

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C’

・・・・・・

・・・

・・・

・・・

・・・

B’

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


input

comparison result

output

STEP1 STEP2

STEP3

STEP4

STEP5

STEP6

STEP6



The technique outputs how the complexity of the target software will change by performing the refactoring

16

refactoring pattern

original structure

A

B

CD

revised structure

A

B’

C’D

program

DC

BA

・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C

・・・・・・

・・・

・・・

・・・

・・・

B

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


・・・・・・

・・・

・・・

・・・

・・・

D

・・・・・・

・・・

・・・

・・・

・・・

C’

・・・・・・

・・・

・・・

・・・

・・・

B’

・・・・・・

・・・

・・・

・・・

・・・

A

LCOMFRCCBONOCDITWMC


input

comparison result

output

STEP1 STEP2

STEP3

STEP4

STEP5

STEP6

STEP6


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 structureA’, B’, C’, and D’ are ones in the revised structureWMC(x) is the value of metric WMC for class x

Only the classes affected by the refactoring are used for calculating change rate

17


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 FieldMove Method, Pull Up Method, Pull Down MethodExtract 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 studentThe number of classes is 37, the LOC is 4,815It 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


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 GUIThe function consists of 1

field and 2 methods


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)


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.

CASE1 CASE2 CASE3 CASE4

WMC 0.0 0.0 0.0 0.0

DIT 0.0 0.0 0.0 0.0

NOC 0.0 0.0 0.0 0.0

CBO -1.90 1.67 3.03 0.60

RFC 0.18 0.09 0.40 0.00

LCOM 0.00 0.00 0.00 0.00


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

CASE1 CASE2 CASE3 CASE4

WMC 0.0 0.0 0.0 0.0

DIT 0.0 0.0 0.0 0.0

NOC 0.0 0.0 0.0 0.0

CBO -1.90 1.67 3.03 0.60

RFC 0.18 0.09 0.40 0.00

LCOM 0.00 0.00 0.00 0.00


A case study -Master Student’s Decision- Before tool’s application

The master student selected CASE3He thought that class CL had a similar function to the

class of CASE3His decision was based on his instinct rather than

objective basis like bug information, software metrics, or design patterns

After tool’s applicationHe 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 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


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 rateThe 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 refactoringsReal refactorings require source code modification

cost and regression test costIn 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 proposalApplied 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

Documents

Transcript of Refactoring Effect Estimation Based on Complexity Metrics