thesis bart du bois

8/14/2019 Thesis Bart Du Bois

http://slidepdf.com/reader/full/thesis-bart-du-bois 1/267

A Study of QualityImprovements By

Refactoring

Bart Du Bois

September, 2006

Promotor: prof. dr. Serge DemeyerCo-promotor: prof. dr. Jan Verelst

Proefschrift ingediend tot het behalen van de graad vanDoctor in de Wetenschappen



2



To mother . . .



4



Acknowledgements

First and foremost, I would like to acknowledge the support of myfamily. I thank my loving parents for their everlasting devotion,presence and patience. My grandfather, for warm welcomes andconversations. And Jan and Jasmina, for playful distraction.

I owe my interests in software engineering to Prof. Demeyer. I thankhim for welcoming me in his research lab, for providing opportunitiesto explore, and for stimulating an atmosphere of curiosity, opennessand creativity. My gratitude goes out to Prof. Verelst, for sharingreflections, and generally sharpening my thinking.

Numerous inspirational conversations were held with office comradesPieter Van Gorp, Hans Stenten, Hans Schippers, more recently Bart

Van Rompaey and Matthias Rieger, as well as with research labbuddies Andy Zaidman, Filip Van Rysselberghe, Niels Van Eetvelde,Olaf Muliawan, and witty office pal Koen Van Leemput. I thank youall for the wonderful atmosphere, stimulating discussions and beer.

Two people were exceptionally supportive in starting up this re-search. At the early start of this research, Amela Karahasanovicwas one of the kind people at the Simula Research Laboratory whosupported my initiation in the domain of empirical software engi-neering. Tom Mens directed me to interesting research topics, andactively supported my first publications.

For assisting in organizing controlled experiments, I thank TomMens and Marijn Temmerman. To support my application of MotMot,the help of Hans Schippers, Pieter Van Gorp and Olaf Muliawan ismost appreciated.

I sincerely hope that I have expressed my appreciation to all of youin our interactions and collaborations.



6



Abstract

Refactorings, behavior preserving transformations, are claimed tomake software easier to understand and to improve software de-sign. However, these claimed quality improvements have yet to bevalidated. This dissertation reports on our contributions to theirvalidation.

First, a validation of two existing reengineering patterns that userefactoring to support program comprehension is presented. Second,we discuss the results of formal analysis of the conditions in whichknown refactorings improve coupling and cohesion as criteria forwell-balanced object-oriented design.

The results of this research confirm that, indeed, the claimed benefits

can occur, and describe how and when the application of refactoringcan improve selected quality characteristics.

The integration of these results in today’s refactoring tools can sup-port maintainers in assessing which refactorings to apply where,ultimately reducing the effort of transforming towards an optimalsolution.



8



Publications

During the process of this PhD, the following peer-reviewed confer-

ence papers were published.

As main author:

• Accommodating changing requirements with EJB , published inthe proceedings of the 9th International Conference on Object-Oriented Information Systems (OOIS 2003), [Du Bois and De-meyer, 2003]

• Refactoring – improving coupling and cohesion of existing code,published in the proceedings of the 11th IEEE Working Con-

ference on Reverse Engineering (WCRE 2004), [Du Bois et al.,2004]

• Does the “Refactor to Understand” reverse engineering pattern improve program comprehension? , published in the proceedingsof the 9th European Conference on Software Maintenance andReengineering (CSMR 2005) [Du Bois et al., 2005]

• Does God Class decomposition affect comprehensibility? , pub-lished in the proceedings of the 24th IASTED InternationalMulti-Conference on Software Engineering (IASTED SE 2006),[Du Bois et al., 2006]

As second author:

• How webmining and coupling metrics improve early program comprehension , by A. Zaidman, B. Du Bois and S. Demeyer,published in the proceedings of the 14th International Confer-ence on Program Comprehension (ICPC 2006) [Zaidman et al.,2006]



10

• An experimental investigation of UML modeling conventions,by C.F.J. Lange, B. Du Bois, M.R.V. Chaudron and S. De-meyer, published in the proceedigns of the 9th InternationalConference on Model-driven Engineering Languages and Sys-tems (MoDELS 2006), [Lange et al., 2005]



Contents

1 Introduction 11.1 Problem Description . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Related Work 72.1 Program comprehension improvements . . . . . . . . . . . . . . . 7

2.2 Internal product quality improvements . . . . . . . . . . . . . . . 92.2.1 Related work by Sahraoui et al. . . . . . . . . . . . . . . . 92.2.2 Related work by Kataoka et al. . . . . . . . . . . . . . . . 112.2.3 Related work by Tahvildari et al. . . . . . . . . . . . . . . 11

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

I Program Comprehension Improvements 15

3 Program Comprehension 173.1 Software maintenance . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 The process of program comprehension . . . . . . . . . . . . . . . 193.2.1 Bottom-up comprehension . . . . . . . . . . . . . . . . . . 203.2.2 Top-down comprehension . . . . . . . . . . . . . . . . . . 233.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.4 Structure of Part I . . . . . . . . . . . . . . . . . . . . . . 25

4 The Refactor to Understand Pattern 274.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

i



ii CONTENTS

4.2 Pattern Description . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.1 Research Question . . . . . . . . . . . . . . . . . . . . . . 29

5 Validating Refactor to Understand 315.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2 Research Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Experimental Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1 Experimental Design . . . . . . . . . . . . . . . . . . . . . 355.3.2 Experimental Participants . . . . . . . . . . . . . . . . . . 365.3.3 Experimental Procedure . . . . . . . . . . . . . . . . . . . 37

5.3.4 Experimental Tasks . . . . . . . . . . . . . . . . . . . . . 405.3.5 Comprehension Questions . . . . . . . . . . . . . . . . . . 42

5.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.4.1 Analysis Procedure . . . . . . . . . . . . . . . . . . . . . . 475.4.2 Applications of Refactorings . . . . . . . . . . . . . . . . . 485.4.3 H 0,accuracy – Differences in response accuracy . . . . . . . 505.4.4 H 0,time – Differences in response time . . . . . . . . . . . 535.4.5 Post-experiment questionnaire . . . . . . . . . . . . . . . 55

5.5 Interpretation of Results . . . . . . . . . . . . . . . . . . . . . . . 565.5.1 Comprehension Technique as a Factor . . . . . . . . . . . 56

5.5.2 Degree of Coupling as a Factor . . . . . . . . . . . . . . . 575.6 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 585.6.1 Internal Validity . . . . . . . . . . . . . . . . . . . . . . . 585.6.2 External Validity . . . . . . . . . . . . . . . . . . . . . . . 59

5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 The Split Up God Class Pattern 636.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Pattern Description . . . . . . . . . . . . . . . . . . . . . . . . . 646.3 Illustrative Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.1 Research questions . . . . . . . . . . . . . . . . . . . . . . 68

7 Validating Split Up God Class 737.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.2 Research Hypotheses . . . . . . . . . . . . . . . . . . . . . . . . . 757.3 Experimental Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 76

7.3.1 Experimental Design . . . . . . . . . . . . . . . . . . . . . 767.3.2 Experimental Participants . . . . . . . . . . . . . . . . . . 787.3.3 Experimental Procedure . . . . . . . . . . . . . . . . . . . 79



CONTENTS iii

7.3.4 Experimental Tasks . . . . . . . . . . . . . . . . . . . . . 837.4 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.4.1 Analysis Procedure . . . . . . . . . . . . . . . . . . . . . . 867.4.2 Descriptive statistics . . . . . . . . . . . . . . . . . . . . . 877.4.3 Statistical tests . . . . . . . . . . . . . . . . . . . . . . . . 897.4.4 H0,accuracy – Differences in task accuracy . . . . . . . . . 907.4.5 H0,time – Differences in task duration . . . . . . . . . . . 94

7.5 Interpretation of Results . . . . . . . . . . . . . . . . . . . . . . . 967.6 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 98

7.6.1 Internal Validity . . . . . . . . . . . . . . . . . . . . . . . 98

7.6.2 External Validity . . . . . . . . . . . . . . . . . . . . . . . 987.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

8 Summary 1018.1 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018.2 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

II Coupling and Cohesion Improvements 105

9 Quality-Driven Refactoring 1079.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1079.1.1 Structure of Part II . . . . . . . . . . . . . . . . . . . . . 110

10 Predicting Quality Impacts 11110.1 Meta-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

10.1.1 Analysis functions . . . . . . . . . . . . . . . . . . . . . . 11310.2 Selection of Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 114

10.2.1 Import Coupling . . . . . . . . . . . . . . . . . . . . . . . 11410.2.2 Export Coupling . . . . . . . . . . . . . . . . . . . . . . . 11610.2.3 General Coupling . . . . . . . . . . . . . . . . . . . . . . . 117

10.2.4 Aggregation Import Coupling . . . . . . . . . . . . . . . . 11810.2.5 Cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . 11810.2.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

10.3 Selection of Refactorings . . . . . . . . . . . . . . . . . . . . . . . 12110.3.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12210.3.2 Extract Method . . . . . . . . . . . . . . . . . . . . . . . 12310.3.3 Move Method . . . . . . . . . . . . . . . . . . . . . . . . . 12410.3.4 Replace Method with Method Object . . . . . . . . . . . 126



iv CONTENTS

10.4 Quality Impact Prediction . . . . . . . . . . . . . . . . . . . . . . 128

10.4.1 Extract Method . . . . . . . . . . . . . . . . . . . . . . . 129

10.4.2 Move Method . . . . . . . . . . . . . . . . . . . . . . . . . 132

10.4.3 Replace Method with Method Object . . . . . . . . . . . 135

11 Validating Predicted Impacts 139

11.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

11.1.1 System Under Study . . . . . . . . . . . . . . . . . . . . . 141

11.1.2 Measurement Instrument . . . . . . . . . . . . . . . . . . 142

11.2 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14211.2.1 Extract Method . . . . . . . . . . . . . . . . . . . . . . . 143

11.2.2 Move Method . . . . . . . . . . . . . . . . . . . . . . . . . 146

11.2.3 Replace Method with Method Object . . . . . . . . . . . 149

11.3 Threats to Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 153

11.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

12 Case Study: Move Method Variant 155

12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

12.2 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15612.3 Specifying the Move Method Variant . . . . . . . . . . . . . . . . 159

12.3.1 Refining the precondition . . . . . . . . . . . . . . . . . . 161

12.3.2 Resulting qualitative postcondition . . . . . . . . . . . . . 163

12.4 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

12.4.1 Validating predicted impacts . . . . . . . . . . . . . . . . 167

12.4.2 Applicability of the Move Method variant . . . . . . . . . 168

12.5 Interpretation of Results . . . . . . . . . . . . . . . . . . . . . . . 170

12.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

13 Summary 173

13.1 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

13.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

14 Further Work 177

14.1 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

14.2 Tool Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 178



CONTENTS v

15 Conclusions 18115.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

15.1.1 Program Comprehension Improvements . . . . . . . . . . 18115.1.2 Coupling and Cohesion Improvements . . . . . . . . . . . 18215.1.3 General Conclusions . . . . . . . . . . . . . . . . . . . . . 182

A Experimental Material 183A.1 Refactor to Understand . . . . . . . . . . . . . . . . . . . . . . . 183

B Formal Impact Derivation 187

B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187B.2 Extract Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189B.2.1 Import Coupling . . . . . . . . . . . . . . . . . . . . . . . 190B.2.2 Export Coupling . . . . . . . . . . . . . . . . . . . . . . . 193B.2.3 General Coupling . . . . . . . . . . . . . . . . . . . . . . . 194B.2.4 Aggregation Import Coupling . . . . . . . . . . . . . . . . 197B.2.5 Normalized Cohesion . . . . . . . . . . . . . . . . . . . . . 197B.2.6 Non-normalized Cohesion . . . . . . . . . . . . . . . . . . 200

B.3 Move Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205B.3.1 Import Coupling . . . . . . . . . . . . . . . . . . . . . . . 205B.3.2 Export Coupling . . . . . . . . . . . . . . . . . . . . . . . 207B.3.3 General Coupling . . . . . . . . . . . . . . . . . . . . . . . 210B.3.4 Aggregation Import Coupling . . . . . . . . . . . . . . . . 221B.3.5 Normalized Cohesion . . . . . . . . . . . . . . . . . . . . . 222B.3.6 Non-normalized Cohesion . . . . . . . . . . . . . . . . . . 223

B.4 Replace Method with Method Object . . . . . . . . . . . . . . . 225B.4.1 Import Coupling . . . . . . . . . . . . . . . . . . . . . . . 225B.4.2 Export Coupling . . . . . . . . . . . . . . . . . . . . . . . 226B.4.3 General Coupling . . . . . . . . . . . . . . . . . . . . . . . 227B.4.4 Aggregated Import Coupling . . . . . . . . . . . . . . . . 234B.4.5 Normalized Cohesion . . . . . . . . . . . . . . . . . . . . . 235

B.4.6 Non-normalized Cohesion . . . . . . . . . . . . . . . . . . 236



vi CONTENTS



List of Figures

5.1 Guidelines for the Refactor to Understand experiment . . . . . . 385.2 Task sheet for task 1 . . . . . . . . . . . . . . . . . . . . . . . . . 385.3 Task sheet for task 2 . . . . . . . . . . . . . . . . . . . . . . . . . 395.4 Task sheet for task 3 . . . . . . . . . . . . . . . . . . . . . . . . . 405.5 Comprehension questions for task 1 . . . . . . . . . . . . . . . . . 435.6 Comprehension questions for task 2 . . . . . . . . . . . . . . . . . 445.7 Comprehension questions for task 3 . . . . . . . . . . . . . . . . . 45

6.1 Decomposition A . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.2 Decomposition B . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.3 Decomposition C . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.4 Decomposition D . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.5 Decomposition E . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.1 Pretest task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817.2 Posttest task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 827.3 Posttest PMV observations . . . . . . . . . . . . . . . . . . . . . 917.4 Posttest PMS observations . . . . . . . . . . . . . . . . . . . . . . 927.5 Frequency of observations with PMV=100% . . . . . . . . . . . . 93

7.6 Frequency of observations with PMS=100% . . . . . . . . . . . . 947.7 Mean ET of observations with PMV=100% . . . . . . . . . . . . 967.8 Mean ET of observations with PMS=100% . . . . . . . . . . . . 97

12.1 Move Method source class precondition story diagram . . . . . . 1 6 012.2 Move Method target class precondition story diagram . . . . . . 1 6 112.3 Qualitative precondition on msrc and csrc . . . . . . . . . . . . . 16412.4 Qualitative precondition on msrc and ctrg . . . . . . . . . . . . . 165

vii



viii LIST OF FIGURES

12.5 Move Method variant applicability in ArgoUML v0.19.8 . . . . . 1 6 8

A.1 Page 1 of the debriefing questionnaire . . . . . . . . . . . . . . . 184A.2 Page 2 of the debriefing questionnaire . . . . . . . . . . . . . . . 185



List of Tables

2.1 Impact description by Sahraoui et al. . . . . . . . . . . . . . . . . 102.2 Impact description by Tahvildari et al. . . . . . . . . . . . . . . . 13

5.1 Questions for evaluating abstractions . . . . . . . . . . . . . . . . 325.2 Experimental variables . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Task order across experimental executions . . . . . . . . . . . . . 405.4 Properties of the code fragments . . . . . . . . . . . . . . . . . . 415.5 Application of refactorings . . . . . . . . . . . . . . . . . . . . . 49

5.6 Comparison of the response accuracy between groups . . . . . . . 505.7 Data loss w.r.t. accuracy observations . . . . . . . . . . . . . . . 525.8 Rejection of H 0,accuracy,X,Y . . . . . . . . . . . . . . . . . . . . . 525.9 Comparison of the response time between groups . . . . . . . . . 545.10 Data loss w.r.t. time observations . . . . . . . . . . . . . . . . . . 545.11 Rejection of H 0,time,X,Y . . . . . . . . . . . . . . . . . . . . . . . 555.12 Average comprehension accuracy . . . . . . . . . . . . . . . . . . 57

7.1 Experimental variables . . . . . . . . . . . . . . . . . . . . . . . . 777.2 Replications of the experiment . . . . . . . . . . . . . . . . . . . 787.3 Participant assignment . . . . . . . . . . . . . . . . . . . . . . . . 79

7.4 Properties of the code fragments used . . . . . . . . . . . . . . . 847.5 Descriptive statistics (N=63) . . . . . . . . . . . . . . . . . . . . 887.6 Statistical tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.7 Test of group differences w.r.t. accuracy . . . . . . . . . . . . . . 907.8 Test of group differences w.r.t. time . . . . . . . . . . . . . . . . 957.9 Rejection of H0,accuracy and H0,time . . . . . . . . . . . . . . . . . 95

10.1 Metrics indicating import coupling . . . . . . . . . . . . . . . . . 115

ix



x LIST OF TABLES

10.2 Metrics indicating export coupling . . . . . . . . . . . . . . . . . 11610.3 Metrics indicating general coupling . . . . . . . . . . . . . . . . . 11710.4 Metrics indicating aggregated import coupling . . . . . . . . . . . 11810.5 Metrics indicating cohesion . . . . . . . . . . . . . . . . . . . . . 11910.6 Selected metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12010.7 Impact table for Extract Method . . . . . . . . . . . . . . . . . . 12910.8 Impact description for Extract Method. . . . . . . . . . . . . . . 13110.9 Impact table for Move Method . . . . . . . . . . . . . . . . . . . 13310.10Impact description for Move Method. . . . . . . . . . . . . . . . . 13510.11Impact table for Replace Method w Method Object . . . . . . . 136

10.12Impact description for Replace Method with Method Object . . . 137

11.1 MPC impact validation for Extract Method. . . . . . . . . . . . . 14311.2 OMMEC impact validation for Extract Method. . . . . . . . . . 14411.3 CBO impact validation for Extract Method. . . . . . . . . . . . . 14411.4 DAC impact validation for Extract Method. . . . . . . . . . . . . 14411.5 LCOM5 impact validation for Extract Method . . . . . . . . . . 14511.6 LCOM1 impact validation for Extract Method . . . . . . . . . . 14511.7 MPC impact validation for Move Method . . . . . . . . . . . . . 14611.8 OMMEC impact validation for Move Method . . . . . . . . . . . 14711.9 CBO impact validation for Move Method . . . . . . . . . . . . . 14711.10DAC impact validation for Move Method . . . . . . . . . . . . . 14811.11LCOM5 impact validation for Move Method . . . . . . . . . . . . 14811.12LCOM1 impact validation for Move Method . . . . . . . . . . . . 14911.13MPC impact validation for Replace Method w Method Object . 15011.14OMMEC impact validation for Replace Method w Method Object 15011.15CBO impact validation for Replace Method w Method Object . . 15111.16DAC impact validation for Replac e Method w Method Object . 15111.17LCOM5 impact validation for Replace Method with Method Object15211.18LCOM1 impact validation for Replace Method with Method Object152

12.1 Move Method impact optimization table. . . . . . . . . . . . . . 15612.2 Story Driven Modeling (SDM) notation. . . . . . . . . . . . . . . 15812.3 Move Method variant effect description. . . . . . . . . . . . . . . 16512.4 Impact table for the Move Method variant. . . . . . . . . . . . . 16612.5 Variant impact validation. . . . . . . . . . . . . . . . . . . . . . . 167



Chapter 1

Introduction

In this chapter, we describe the problem statement which is at the core of thisthesis.

1.1 Problem Description

A refactoring is a transformation of the structure of a software system whichpreserves key aspects of the systems’ behavior. Typically, behavior preservingis interpreted as a guarantee that the system will still reach the same end statesunder identical conditions as the initial system. Alternatively, refactoring is alsoused to refer to the application of one or more refactorings.

Non-functional properties, e.g., the time and space complexity, are not guar-anteed to be preserved. The guarantee that some properties are preserved whileothers can be manipulated provides interesting perspectives on the explorationof the software solution space, e.g., to optimize specific properties.

Problem statement – Refactoring is suggested as a means to improve qual-ity characteristics such as the comprehensibility and modifiability of a softwaresystem. However, the existence of inverse transformations (e.g., the existenceof both Extract Method and its counterpart Inline Method) suggests that, if affected at all, these quality characteristics can be both impaired and improvedby the application of refactorings. Therefore, there is a need for guidelines thathighlight where and how to apply which refactorings in order to optimize asoftware system with regard to a quality characteristic.

1



2 CHAPTER 1. INTRODUCTION

1.2 Refactoring

Fowler’s catalogue of refactoring [Fowler, 1999] can be considered to be the workwhich triggered industry adoption of refactoring practices. In his book, Fowlersuggests four purposes of refactoring:

• Improve the design of software – Through accumulating code changes,code loses its structure, thereby increasingly drifting towards a state of decay. Refactoring can be used to cure software decay by redistribut-ing parts of the code to the “right” places, and by removing duplicated

code. The claim that refactoring can improve the design of software isconfirmed by [Simon et al., 2001] with regard to cohesion and by [Kataokaet al., 2002] w.r.t. coupling, as indicators for internal software quality.Another claimed benefit in the area of improved design is improved flexi-bility [Deursen and Moonen, 2002].

• Make software easier to understand – Refactoring can help make the codemore readable by making it better communicate its purpose. A differ-ent way in which refactoring supports program understanding is in re-flecting hypotheses about the purpose of the code by changing the code,and afterwards testing that understanding through rerunning the code.

The suggested process to do so is to start refactoring the little detailsto clarify the code, thereby exposing the design. The potential to im-prove understandability through refactoring is confirmed by many au-thors [Opdyke, 1992,Simon et al., 2001,Kataoka et al., 2002,Deursen andMoonen, 2002, Demeyer et al., 2002, van Emden and Moonen, 2002, vanDeursen et al., 2003,Mantyla et al., 2004]. In more specific terms, [Wake,2003] discusses how refactorings can be used to improve communicatingthe purpose of the code.

• Help find bugs – Through clarifying the structure of the code, the assump-tions within the code are also clarified, making it easier to find bugs.

• Program faster – Through improving the design and overall understand-ability of the code, rapid software development is supported.

Traditionally, Opdyke [Opdyke, 1992] is referenced for publishing the firstPhD w.r.t. refactoring. However, in his PhD thesis, Opdyke refers to the PhDof Griswold, acknowledging his precedence. Griswold did not use the wordrefactoring explicitly, yet referred to the same concept: automatable meaning-preserving restructurings [Griswold, 1991].



1.2. REFACTORING 3

Restructurings are propoposed by Griswold as a means to reorganize a de-cayed structure, caused by the accumulation of unanticipated changes. What ischaracteristic about these changes is their non-local character: the implementa-tion of these changes requires modifications at multiple locations in the sourcecode. The key to resolving decayed structure is in isolating design decisions,requiring global search and global changes in order to preserve behavior. I.e.,we can’t simply change the definitions, yet also have to adapt the references tothese definitions. While the former changes can be described locally, the latterhave a global impact. The focus on a description of a local definition changethat has a global impact is essential for Griswold’s contribution.

As a cost-efficient way to perform these global changes, automatable restruc-turings have been proposed, e.g., by [Griswold, 1991, Opdyke, 1992, Roberts,1999,Fowler, 1999,Tokuda and Batory, 2001, O Cinneide, 2001]. These restruc-turings are distinct from other maintenance activities in that the maintainercan focus on local structural changes. The automated restructuring takes careof the global search, and assures consistent changes. Such restructurings areused to transform the code to a form which is better suited for future changes.Once a selected set of changes has been accommodated in the structure, theapplication of these changes will be facilitated.

The concept of refactoring is an exploitation of Parnas’s design guidelines,

stating that structural system modifications can be postponed by assuring lo-cality of change for likely changes [Parnas, 1978].To assure locality, Parnas suggests the following steps: (i) identify the

items that are likely to change; (ii) locate specialized components in separatemodules; and (iii) design intermodule interfaces insensitive to the anticipatedchanges [Parnas, 1978]. These steps respectively correspond to three design prin-ciples: (i) abstraction; (ii) encapsulation; and (iii) information hiding. Theseconcepts are clearly distinguished by [Berard, 1993] based on an extensive lit-erature survey:

Abstraction: As a process, abstraction denotes extracting the essential details

about an item or a group of items while ignoring the inessential details.Examples of these essential details are difficult or likely-to-change designdecisions. As an entity, abstraction denotes a model, a view, or some otherfocused representation for an actual item. Among others, abstractiondiffers from information hiding in that it does not specify a mechanismfor handling the unimportant information.

Encapsulation: As a process, encapsulation means the act of enclosing one ormore items within a (physical or logical) container. As an entity, encap-




sulation refers to a package or an enclosure that holds (contains, encloses)one or more items. Encapsulation can be used as a strategy to packagewhat has to be extracted, disregarding whether these items should bevisible or hidden.

Information hiding: The process of hiding information, especially difficult orlikely-to-change design decisions. Information hiding does not incorporatethe identification of which information is to be hidden (e.g., through ab-straction), nor the strategy for hiding them (e.g., through encapsulation).

As refactoring is an exploitation of assuring locality of design decisions likelyto change, there should be a close relationship between refactoring and the threedesign principles abstraction, encapsulation and information hiding. In thisthesis, we investigate the exploitation of abstraction and encapsulation usingrefactorings.

To investigate the exploitation of abstraction using refactorings, we studyhow the process of people trying to comprehend parts of a software system canbe supported through refactorings. Accordingly, we discuss two known usagesof refactoring, which are claimed to support program comprehension.

To investigate the exploitation of encapsulation using refactorings, we em-

ploy the concepts of coupling and cohesion. Coupling is defined as “the measureof the strength of association established by a connection from one module toanother ”, and cohesion as “a measure of the degree to which the elements of a module belong together ” [Stevens et al., 1974], as cited in respectively [Briandet al., 1996] and [Briand et al., 1997].

A well known guideline for both structured and object-oriented design isto minimize coupling and maximize cohesion [Coad and Yourdon, 1991, Page-Jones, 1992, McConnell, 1993]. Coupling and cohesion have been recognized tobe in fact two aspects of a single principle, termed connascence. In [Page-Jones,1992], connascence is defined as:

“. . . I define two software elements A and B to be connascent if thereis at least one change that could be made to A that would necessitatea change to B in order to preserve overall correctness ”

Using this unified concept of connascence, the aim of minimal coupling andmaximal cohesion is formulated in a single statement about object-orienteddesign, as cited from [Page-Jones, 1992]:



1.3. CONTRIBUTIONS 5

“Eliminate any unnecessary connascence and then minimize con-nascence across encapsulation boundaries by maximizing connascencewithin encapsulation boundaries.”

Using this terminology, coupling can be described as connascence acrossencapsulation boundaries, and cohesion as connascence within encapsulationboundaries. Accordingly, we study existing refactorings that affect these bound-aries, to learn how these refactorings can be used to optimize encapsulation byminimizing coupling and maximizing cohesion.

1.3 Contributions

The three contributions of this research are:

1. Report on the mental effects of physically applying refactorings that in-troduce abstraction . This application of refactoring has been previouslyintroduced by [Demeyer et al., 2002] as a reverse engineering pattern en-titled Refactor to Understand .

2. Report on comprehensibility improvements when applying refactoringsthat introduce encapsulation . This application of refactoring was alsopreviously introduced by [Demeyer et al., 2002] as a reengineering patternentitled Split Up God Class.

3. Demonstrate formal analysis of refactorings (Extract Method, Move Methodand Replace Method with Method Object) and indicative coupling and co-hesion metrics to identify the conditions under which the application of these refactorings minimize coupling and maximize cohesion.

1.4 Organization

This thesis is organized as follows. First, Chapter 2 discusses work related tothe exploitation of reengineering or refactoring techniques to improve quality.The remainder of this thesis is divided into two parts.

Part I presents the contributions w.r.t. the use of refactoring to improve pro-gram comprehension.




Chapter 3 delineates program comprehension within the larger contextof software maintenance, and clarifies the program comprehension modelsemployed in this thesis.

Chapter 4 describes the Refactor to Understand reverse engineering pat-tern, of which we report our efforts for validation in Chapter 5.

Chapter 6 presents the Split Up God Class reengineering pattern, whosevalidation is discussed in Chapter 7.

Chapter 8 summarizes the findings of the first part of this thesis, anddiscusses lessons learned.

Part II reports the contributions w.r.t. the use of refactoring to improve cou-pling and cohesion.

Chapter 9 introduces the process of Quality Driven Refactoring .

Chapter 10 presents a selection and formalization of coupling and cohe-sion metrics and refactorings, and presents impact tables describing theeffect of a refactoring on metrics. The impact derivation process itself isdiscussed in Appendix B. These impact tables are validated in Chapter11.

Chapter 12 illustrates the exploitation of impact tables through refininga variant of the Move Method refactoring, and applying it in a case study.

Chapter 13 summarizes the findings of the second part of this thesis,and discusses lessons learned.

Finally, we discuss future work in Chapter 14 and present our conclusionsin Chapter 15.



Chapter 2

Related Work

In this chapter, we discuss previous research on quality improvements by refac-toring. This overview is used to describe opportunities for advancing the currentstate of the art.

2.1 Program comprehension improvementsTo the best of our knowledge, there has been no previous attempt to evalu-ate how program comprehension can be improved using refactorings. However,we are aware of two works that investigated the relationship between class de-composition and program comprehension. As the software solution before andafter a refactoring can be considered to be alternative class decompositions, thisresearch is related to our problem statement.

[McGregor and Kamath, 1995] performed research on a so called Psycho-logical Complexity Measure, which uses information on class responsibilities andclass collaborations to calculate the psychological development complexity as

a measure of effort. By defining a measure called Permitted Collaborations(PC), they suggest a means for estimating the cognitive load imposed on thedevelopers of a software system from a set of Class-Responsibility-Collaboratorcards [Beck and Cunningham, 1989] that represent a domain.

One of the purposes of this measure is to “aid the developers in selecting theright class decomposition when there are conflicting choices” [McGregor andKamath, 1995]. Among others, the measure is suggested to be applicable intrade-off analysis when deciding whether or not a weakly cohesive class should

7



8 CHAPTER 2. RELATED WORK

be partitioned. Their measure indicates that the partitioning of a class yields“a lower combined complexity value for the two partitioned classes ”, yet therelative complexity increase or decrease is “dependent on whether the complexity increase due to an additional collaborator is greater or less than the reduction in collaboration complexity due to smaller collaborators”. The suggested measurewas shown to correlate with expert judgements in an initial experiment.

[Arisholm and Sjøberg, 2004] conducted experiments to empirically comparetwo alternative design solutions with a fundamentally different control style.These alternatives were composed by assigning responsibilities and collabora-tions among classes in different ways. One alternative distributed a well-defined

set of responsibilities across a number of classes, which typically results in a dele-gated control style. In contrast, in a centralized control style, a few large controlclasses coordinate a set of simple classes. The main hypothesis investigated inthese experiments is that a delegated control style is easier to understand andchange than is a centralized control style.

While the work of Arisholm et al. does not describe how the two alternativeswere composed, the two alternatives are behaviorally equivalent, which allowsto refactor one into the other. Therefore, any quality differences observed be-tween these two alternative solutions provide indications of quality benefits anddisadvantages that can be achieved using refactorings.

In their first experiment, Arisholm et. al surprisingly observed that it tookundergraduate students more effort to implement a given set of changes on thedelegated control style. A hypothetical explanation for this contradiction to ex-pert opinions was suggested, leading to the second experiment. In this secondexperiment, the authors hypothesized that differences in maintainability of thedesigns might be due to cognitive models of the developers, which would requireto incorporate a factor distinguishing the level of experience of the participant.Therefore, the second experiment incorporated junior, intermediate and seniorsoftware consultants aside undergraduate and graduate students, and the com-parison of the maintainability of the two alternative designs was observed foreach of these experience levels.

The results of the second experiment rejected that the design alternativeaffected change effort, defined as the time spent performing change tasks. Evenwhen incorporating interaction with the developer category, the control stylewas not found to significantly affect change effort. However, a posthoc analysisbetween the high (intermediates and seniors) and low (undergraduates, gradu-ates and junior) experience developers indicated that the interaction betweendesign and developer category was, in fact, significant.

With regard to change task correctness, the results indicated that subjects



2.2. INTERNAL PRODUCT QUALITY IMPROVEMENTS 9

were much less likely to produce correct solutions on the delegated control styledesign. For both change effort and correctness, the authors found that onlysenior consultants benefited from the delegated control style. In contrast, lessskilled developers performed better on the centralized control style design.

Accordingly, we ask ourselves whether these results would be confirmed orrefuted in the context of refactoring. In a refactoring context, classes with acentralized control style tend to grow out to become god classes [Brown et al.,1998]. These god classes encapsulate the responsibilities of a whole subsystem,therefore forming an incohesive grouping of unrelated functionality. In casewe can generalize the findings of [Arisholm and Sjøberg, 2004], then a god

class would be more maintainable than an equivalent class decomposition whichdistributes responsibilities across a number of collaborators, thereby exhibitinga delegated control style.

2.2 Internal product quality improvements

To identify existing research approaches w.r.t. the exploitation of refactoring toimprove internal program quality characteristics, we reviewed key conferencesand journals related to the subject of software maintenance and evolution. Thisreview of the literature led to the identification of three research approaches,

respectively by [Sahraoui et al., 2000, Kataoka et al., 2002, Tahvildari et al.,2003].

2.2.1 Related work by Sahraoui et al.

[Sahraoui et al., 2000] propose to use metrics both for detecting potential designflaws, and for suggesting potentially useful transformations for correcting them.The reengineering strategy proposed by Sahraoui et al. consists of the followingsteps:

• Diagnosis of design flaws – An engine applies rules of a quality es-timation model to classes of the software system. The goal is to detectsymptoms of violated design rules using combinations of metrics.

• Prescription of transformations– Prescription refers to the exploita-tion of the (possibly indirect) relationship between transformations andquality improvement. The logic behind this approach is that if a gooddesign is reflected in a good combination of metric values, then we mightassume that a good combination of metric values corresponds to a good




design. Accordingly, the goal is to improve quality through manipulatingmetric values.

The prescription step is supported through formal analysis of the effect of three transformations on inheritance and coupling metrics. The resulting impactdescription is illustrated in Table 2.1. The metrics themselves are unimportantin this discussion, as we are merely pointing out the level of detail of the impactdescription.

Table 2.1: Impact description by Sahraoui et al.

Classes Global variations

Classes that reference the abstracted methods IH-ICP + i ( I ≥ 0)Classes referenced in the common code CBO - [0, N - 1]

DMMEC - i ( i ≥ 0)OMMEC - i ( i ≥ 0)

Ci CBO N.D.IH-ICP N.D

Impact of the Create Abstract Class transformations on coupling metrics, as ex-

tracted from [Sahraoui et al., 2000].

Table 2.1 describes the impact of the Create Abstract Class transformationon coupling metrics, in which N stands for the number of factorized classes.In general, the impact tables presented in [Sahraoui et al., 2000] suggest threepossible impact descriptions:

• Exact impact specification – The value of a metric after the applicationof a refactoring is specified exactly, possibly but not necessarily using avariable for an unknown cardinality, e.g., N .

• Impact spectrum – The value of a metric after the application of a

refactoring can be determined within an interval, e.g., a finite interval(CBO - [0, N - 1]) or an infinite interval (DMMEC - i, with i ≥ 0).

• Indeterminate impact – The value of a metric after the application of a refactoring can not be determined, e.g., CBO N.D.

This description of the impact of a representative set of transformations ona selected set of object-oriented metrics is suggested to be used by prescriptiontools to propose transformations that cure detected design flaws. The validation



2.2. INTERNAL PRODUCT QUALITY IMPROVEMENTS 11

of a transformation suggestion then requires two tasks: (i) an evaluation of thesuggestion by the maintainer based upon the particular semantics of the affectedcode part ; and (ii) an evaluation of the transformation precondition.

2.2.2 Related work by Kataoka et al.

[Kataoka et al., 2002] describe a refactoring process consisting of three mainsteps, involving three roles:

• Identify refactoring candidates – First, a developer finds source codeparts to be refactored. The developer is responsible for validating thefunctional equivalence of the refactoring.

• Validate refactoring effect – Second, an analyst performs cost andeffect estimation to select appropriate refactorings from the set of can-didates. The analyst is responsible for validating the intended effect of each refactoring. At the manager level, the cost-effect trade-off should bevalidated, and a prioritization should take place.

• Application of refactoring – Thirdly, the developer applies the selectedrefactorings on the target program in the proposed order.

Kataoka et al. focus on the second step, being the validation of the effectof refactoring. The authors propose an evaluation method for the degree of maintainability enhancement of a refactoring. This evaluation method comparesthe value of an appropriate metric before and after applying the refactoring.Their approach was demonstrated by validating the effect on coupling of anidentified refactoring candidate.

An illustration of the validation was provided for a Move Method refactor-ing candidate. As an indicator for maintainability, a coupling metric was usedto quantify the effect of moving the selected method to another class. The re-sulting impact specification described the effect as a formula using an unknownvariable for the number of polymorphic invocation targets of a method invo-cation contained in the selected method. This formula allowed the authors todescribe the condition under which moving the selected method would reducethe coupling metric.

2.2.3 Related work by Tahvildari et al.

[Tahvildari et al., 2003] adhere quite closely to the approach of [Sahraoui et al.,2000]. Tahvildari et al. propose to exploit the effect of transformations on




metrics to improve quality. The proposed reengineering strategy consists of thefollowing steps:

• Apply metrics – Selected object-oriented metrics are measured (andcollected) to detect classes with deteriorated quality. The focus is on socalled key classes, which implement the most important concepts of asystem, i.e., recognized through their coupling and complexity values.

• Apply transformations – Transformations are identified which canreengineer the detected design flaws. The preconditions of these transfor-

mations are evaluated to verify their applicability, and the transformationis applied.

• Evaluate improvement – The metrics are re-applied to evaluate thedesign and source code improvement using before-after comparison.

Essential to this reengineering strategy is the adherence to the non-functionalrequirement (NFR) framework. The NFR framework represents software qualityrequirements in soft-goals [Chung et al., 2000]. Soft-goals are goals with noclear-cut criterion for their fulfillment. Soft-goals contribute either positively ornegatively towards achieving other soft-goals, and can be satisficed (satisfied,

but not necessarily optimally so) or not. Soft-goals are organized in a soft-goal interdependency graph (SIG), specifying the soft-goals considered and theirinterdependencies. The leaves of a SIG represent design decisions.

Tahvildari et al. analyzed the contribution of so called meta-pattern transfor-mations to these design decisions. Meta-pattern transformations exploit motifsshared between multiple design patterns. These design motifs can be com-bined into existing design patterns [Tahvildari and Kontogiannis, 2002a], andare themselves composed of lower-level refactorings. Meta-pattern transforma-tions can contribute positively (make ++, or merely help +) or negatively (break--, or merely hurt -) to design decisions, or can have no impact. Through theircontribution to design decisions, the SIG clarifies how these transformations

indirectly contribute to (potentially conflicting) software qualities.Similar to [Sahraoui et al., 2000], the impact specification is provided as an

impact spectrum , which specifies the impact in a (mostly infinite) interval. As anexample, Table 2.2 illustrates the impact specification of the Movement trans-formation on soft-goals in a SIG for maintainability (extracted from [Tahvildariand Kontogiannis, 2002b]). The Movement transformation corresponds to theExtract Class refactoring as described by [Fowler, 1999]: it creates a new classand fills it with method from an existing class.



2.3. SUMMARY 13

Using such impact descriptions, a SIG for maintainability can be extended toindicate which transformations to apply to improve the most refined soft-goals,and therefore indirectly to improve maintainability.

Table 2.2: Impact description by Tahvildari et al.

Soft-goal Effect

High Modularity ++Low Control Flow Coupling -High Module reuse +

Impact of the Movement meta-pattern transformations on maintainability re-

lated soft-goals as extracted from [Tahvildari and Kontogiannis, 2002b].

2.3 Summary

Based on the overview of related work, we summarize previous research w.r.t.quality improvements by refactoring as follows.

It has been shown that alternative class decompositions can differ w.r.t.maintainability [Arisholm and Sjøberg, 2004]. Thus, this leads us to assume

that refactorings, which manipulate the class decomposition, can potentiallyimprove quality attributes related to maintainability. However, the effect of theclass decomposition was found to interact with the experience of the personperforming the maintenance task. Accordingly, we should be careful to incor-porate personal characteristics when comparing different class decompositionsachieved through refactoring.

With regard to internal program quality, researchers have demonstratedthe usefulness of evaluating how refactorings affect design quality indicatorsas coupling and cohesion [Sahraoui et al., 2000, Tahvildari and Kontogiannis,2002b, Kataoka et al., 2002]. However, this research has focused mostly ontransformations at the level of design patterns rather than the level of current

automatable refactorings, such as the ones catalogued by [Fowler, 1999]. We areparticularly interested in the effect of automatable refactorings for two reasons.

First, knowledge on the effect of refactorings supported in current refactoringtools can be more easily exploited in current refactoring practices. Second, ithas been demonstrated that higher-level refactorings can be composed from theset lower-level automatable refactorings [Kniesel and Koch, 2004], forming so-called composite refactorings. Since the formal description of these compositerefactorings can be derived from its constituting parts (e.g., as performed by




[O Cinneide, 2001]), it should be theoretically possible to reuse the descriptionsof the effects of lower-level refactorings in composite refactorings.

Accordingly, we are intrigued by the work of [Kataoka et al., 2002] whodemonstrated the derivation of an exact impact specification of an automatablerefactoring. The benefit of an exact impact specification is that it enumeratesthe conditions under which the optimal effect can be achieved. When used asadditional preconditions, the studied refactorings can be refined towards theoptimization of a selected set of metrics. Accordingly, such exact impact speci-fications can enable quality driven refactoring.



Part I

Program Comprehension

Improvements

15



Chapter 3

Program Comprehension

This chapter delineates the maintenance activity of program comprehension .We start by providing a life cycle model for processing a maintenance task,and indicate how program comprehension contributes to this wider context.Then, we provide an overview of the main features of program comprehensionas described in existing literature, clarifying how program comprehension can

be evaluated. The selected evaluation methods for program comprehension willbe used in the further chapters of this part of the thesis for the validation of two typical usages of refactoring.

3.1 Software maintenance

In this section, we discuss the general life cycle model (or “ framework for or-ganizing the experienced reality ” as described by [Chapin, 1988]) for fulfillingsoftware maintenance tasks proposed by [Khan et al., 1996] based on a surveyof the literature.

Chapin defines the objective of software maintenance as “to modify an ex-isting software system while preserving the integrity of that system’s existing contribution to the organization’s performance capability ”. [Chapin, 1988].

Khan et al. stress that software maintenance is performed within the contextof a larger process. This larger process is termed the Change Control or Con-figuration Management procedure by [Chapin, 1988], and the general softwaredevelopment process by [Khan et al., 1996]. By embedding software mainte-nance in such a wider context, one can focus (e.g., relatively to their weight) on

17



18 CHAPTER 3. PROGRAM COMPREHENSION

the activities which are specific to the processing of a single maintenance task.These activities are:

1. Modification requirement analysis – Understand the modification re-quirements originating from a user already using the system. Chapin termsthis activity as the definition of the modification objectives, consisting of the determination of the business function which the modification shouldaccomplish (what ), and also how this function should be accomplished.

2. Feasibility determination – Assess the importance and relevance of the

modification, as well as the effort required to implement the change. Thisphase incorporates refining and filtering of user requirements, as well asestimation of costs and staff.

3. Program comprehension – Extract the system design rationale to un-derstand how the product was designed and implemented.

4. Localization – Identify the precise location where the proposed modifi-cation is to be applied.

5. Impact analysis – Analyze potential side-effects in consequence of the

proposed modifications.

6. Implementation plan – The implementation of the proposed modifi-cation is planned, describing the necessary updates to the existing spec-ification and design documents, but also stating how to implement andconfigure modified or to-be-added components.

The distinction and order between the three comprehension related activi-ties (program comprehension, localization and impact analysis) is not entirelyconsistent with program comprehension literature. I.e., Khan et al. stress thatthe maintainer has to have a complete understanding before localization can

start. However, this conflicts with the traditional perspective on comprehen-sion strategies applied in practice, which mainly report on an as-needed strategyin which comprehension is applied very selectively [von Mayrhauser and Vans,1995]. We therefore are somewhat reluctant to stress the difference between theactivity of program comprehension and that of localization.

More specific, [Koenemann and Robertson, 1991] observed that professionalprogrammers study code or documention only in case they are convinced thatthe code is relevant for their task. In fact, Koenemann et al. differentiated



3.2. THE PROCESS OF PROGRAM COMPREHENSION 19

between three types of ”relevancy”. Code segments which will have to be mod-ified are tagged as directly relevant . Code which is assumed to interact withdirectly relevant code is termed intermediate relevant . Finally, code or docu-mentation which helps to locate directly or intermediate relevant code is calledstrategic relevant code. Using this vocabulary, the activity of localization couldbe defined as localizing directly relevant code; impact analysis as the determi-nation of intermediate relevant code; and finally, the first activity of programcomprehension could be considered the determination of strategic relevant code,preparing for localization and impact analysis.

Khan et al. indicate that providing the implementation plan is the last

maintenance-specific activity. From that moment, the further activities con-sist of modifying and revalidating the system, which can be supported by thesoftware development life cycle framework.

7. Requirement analysis – Apply the described updates to the existingspecification.

8. Design – Apply the described updates to the existing design documents.

9. Coding – Implement the described modifications.

10. Testing – Create tests for the previously described side-effects (as anoutput of the impact analysis activity), and perform the tests, includingregression tests.

Chapin distinguishes between validating and verifying the modificationitself, and revalidating (regression testing) the software system. The lat-ter focuses on the preservation of the unmodified functionality while theformer focuses on the correctness of the modified functionality.

After this last activity, the larger process of configuration management takesover.

3.2 The process of program comprehension

Khan’s lifecycle model proposed three activities related to program comprehen-sion: (i) program comprehension; (ii) localization; and (iii) impact analysis. Inthis subsection, we discuss different comprehension models that describe theprocesses that programmers apply when trying to comprehend a program.




Research on program comprehension has led to a number of comprehensionmodels, which can be categorized into bottom up, top down or integrated (hy-brid models). A bottom up model develops mental representations, top downmodels decompose code into typical elements, and an integrated model combinesboth top-down and bottom-up understanding. While it has been shown thatprogrammers switch between all models, top-down comprehension is typicallyapplied for familiar code, while bottom-up comprehension is mostly applied forunfamiliar code [von Mayrhauser and Vans, 1995,O’Brien and Buckley, 2001].

3.2.1 Bottom-up comprehensionNancy Pennington performed research on the mental representations that pro-grammers construct when reading unfamiliar program code [Pennington, 1987b].The basis for these mental representations were abstractions of program text,which were suggested by formal analysis of procedural programs. These abstrac-tions convey information “about what should be accomplished (goal hierarchy),how to do it (sequential procedure), the set of conditions under which particular actions should be taken (conditionalized action), and the set of transformationsthat a particular object should go through (data flow)” [Pennington, 1987b]. To-gether with an additional abstraction (operations), a total of five abstractions

structure the information present in a program in different ways:

• Function – A decomposition of the program into a goal hierarchy ac-cording to the major program functions or outputs, without specifyinghow the goals are achieved. In this hierarchy, a goal is recursively dividedinto subgoals.

• Data Flow – Structures information according to the transformationsapplied to a data object. While there are evident relationships betweenthe transformations and the goals in the functional abstraction, one needsadditional information to group goals into higher order goals. This infor-mation is not present in a data flow abstraction. What is present, is anexplicit description of the changes to a data object.

• Control Flow – Explicit description of the sequence in which actionsoccur.

• Operations – Detailed actions corresponding to a single statement, orless, in case a single command executes multiple actions.




• State (Conditionalized actions) – Structures information accordingto actions that will be performed when a set of conditions is established,and also which conditions will be fulfilled after the action. This structureallows to find out easily when an action will be performed, but also whathappens when a set of conditions is established.

What is essential about these abstractions is that it is infeasible to simultane-ously structure a program text according to multiple abstractions. Nonetheless,complete comprehension requires an understanding of all abstractions, as wellas the relationships between them.

Analogue to the theory of text comprehension, Pennington suggests the pres-ence of two different mental representations, each according to a different typeof knowledge: (i) the program model; and (ii) the situation model.

The program model representation stresses text structure knowledge, repre-senting knowledge about the control flow constructs (based on building blocksfor sequencing, iteration and conditionals). The program model describes therelationships between different program parts and the operations contained inthese parts. Therefore, this representation is mostly based on control flow andoperations abstractions.

The situation model representation focuses on plan knowledge, representing

knowledge about plans. Plans describe typical manners of achieving goals (e.g.,sorting, or taking the average of a series), and involve both functions and rolesfor other plans. The situation model representation is mostly based on dataflow and function abstractions.

State abstractions are explicit in neither types of representation, and areassumed to be generally difficult to extract from the program text.

Thus, these abstractions can be used to assess the effectiveness of a bottom-up comprehension attempt for procedural languages.

Pennington’s model in an Object-Oriented contextDue to fundamental differences between the object-oriented paradigm and theprocedural paradigm, the validity of employing Pennington’s model to reasonabout bottom-up comprehension of object-oriented source code is a highly de-batable subject. We polarize this debate in either a perspective on using Pen-nington’s mental model for programs in the object-oriented paradigm based onits commonalities with the procedural paradigm, or conversely, on their differ-ences.




On one hand, the methods of organization available in the object-orientedparadigm are a superset of these of the procedural paradigm. As the five abstrac-tions present in the program and situation model are based upon these commonmethods of organization, the mental model of object-oriented programs can be(partially) evaluated using these five abstractions. This perspective has beensupported by, e.g., [Ramalingam and Wiedenbeck, 1997,Davies, 2000,Engebret-son and Wiedenbeck, 2002].

On the other hand, the object-oriented paradigm extends the proceduralparadigm through fundamental differences as, e.g., the advanced encapsulationof data and functions and the concept of inheritance. These additional abstrac-

tions are known to have a considerable impact on cognitive activities [Or-Bachand Lavy, 2004]. Thus, it is reasonable to assume that the mental model repre-sentations of procedural programs differs from that of object-oriented programs.

In this dissertation, we adhere to the perspective of commonalities withthe procedural paradigm, stating that the key abstractions of function, dataflow, control flow, operations and state are most likely present in mental modelrepresentations of object-oriented programs. Nonetheless, we realize that theseabstractions might be affected by additional methods of organization. E.g.,control-flow abstractions might be challenged by the use of inheritance, sincethe principle of polymorphism introduces a potential difference between the

static type of an object, as read from the source code, and its dynamic type, atrun-time. Thus, we emphasize that our evaluation using the five abstractionsdescribed in Pennington’s model does not necessarily form an evaluation of thecomplete mental model of object-oriented programs.

Supporting bottom-up comprehension

Key comprehension principles which support structuring the information con-tained in the program text (thereby constructing the according mental modelrepresentation), are (i) beacons ; and (b) chunking .

• Beacons are recognition points that index into knowledge [von Mayrhauserand Vans, 1995]. Mostly, beacons are names that are semantically as-sociated with a specific programming concept, and help their recogni-tion [Wiedenbeck and Scholtz, 1989,Crosby et al., 2002].

• Chunking is the composition of lower level structures into higher levelabstraction structures. Such a composition strategy allows the readerto trade off when to zoom in, based on the names of the chunks that al-ready serve as beacons. For the person performing the actual composition,




chunking is a means to introduce abstraction, for example, by recognizingthat a specific sequence of mathematical operations signifies the calcula-tion of the tax amount for a given product price and tax rate.

3.2.2 Top-down comprehension

A top-down comprehension strategy is mostly applied when the code or problemdomain is familiar. In terms of top-down comprehension, the task of understand-ing a program consists of “constructing, or reconstructing, enough information about the modeling domains that bridge between problem and executing program

to perform the requested task ” [Brooks, 1978]. This bridging is mostly non-trivial as the knowledge which the initial developer had about the entities andrelationships in the problem or application domain has been encoded in a pro-gramming language. To comprehend a program, one needs to be able to relate,link, match or map entities, their attributes and the operations that manipu-late these attributes, as well as relationships between these entities present inthe source code with the set of entities, actions involving these entities, andrelationships between entities present in the problem domain. Brooks used histheory to stimulate the construction of adequate documentation.

[O’Brien and Buckley, 2001] differentiate between two types of top-down

comprehension. An expectation-based process (e.g., as discussed by [Brooks,1983]) starts with the formulation of pre-generated hypotheses, followed by try-ing to confirm or refute the hypotheses (and their refinements) by scanning thecode, finally leading to their confirmation (or refutation). These hypothesesmight originate from expertise or documentation, or even from other program-mers [O’Brien and Buckley, 2001]. The verification of these hypotheses is sup-ported by beacons, and their refinement ends when an associated code segmentis found.

In contrast, an inference-based process (e.g., as discussed by [Soloway andEhrlich, 1984]) starts with scanning the code first, then inferring hypotheseswhich are thereafter validated. Therefore, the inference-based process is a com-bination of a top-down and a bottom-up approach.

Supporting top-down comprehension

[Biggerstaff et al., 1993] refer to bridging the problem and executing programas the concept assignment problem , stressing that “there is no algorithm (or,equivalently, no set of inference rules) that allow us to compute this mapping [between the domains of ”mathematics and data manipulation” and any appli-




cation domain] with complete confidence”. In contrast, the programmer canmerely use fuzzy reasoning supported by different kinds of clues that can sup-port discovering concepts. In [Biggerstaff et al., 1993] these clues are suggestedto be:

• Natural language tokens – These correspond to beacons, and can befound names and comments.

• Proximity and grouping – Definitions of concepts which are relatedare grouped together.

• Design conventions – Structural relationships indicative for a particulardesign.

• Domain design conventions – These refer to structural relationshipsamong the concepts in the application domain, e.g., through compositionor delegation.

• Previous solution states – The recognition of one concept can facili-tate the recognition of another concept through the exploitation of rela-tionships between the concepts in the problem domain and relationshipsdetected in the code.

• Weight of evidence – Combinations of clues strengthen the likelyhoodthat the hypothesized mapping is valid.

These clues mostly support an inference based process.To support the recognition of concepts, Biggerstaff et al. propose two tasks:

(i) the identification of important entities and relations; and (ii) the assignmentof these entities and relationships to domain concepts and relations. Amongothers, these tasks differ w.r.t. to the need of application domain knowledge.

Identification of important entities and relations – In this task, onelooks for different types of clues to discover related statements. E.g., one candetect so called data-groups which might represent some domain concept, yetthis representation is still to be recognized.

Assignment to domain concepts and relations – This task requires do-main knowledge, and exploits (i) the meanings of natural language tokens (bea-cons); (ii) recognition of associated concepts; (iii) relationships present in the




code that correspond to relationships in the domain; and (iv) the presence of apattern of relationships at the domain level [Biggerstaff et al., 1993].

These two tasks support the two criteria which Brooks stated to be requiredfor complete understanding of a program [Brooks, 1978]:

1. information about a knowledge domain, consisting of “basic set of objects,including their properties and relationships, the set of operations that can be performed on these objects, and the order in which these operations takeplace”.

2. “information about the relationship between objects and operators in onedomain and those in a nearby domain ”.

Accordingly, these two criteria can be used to verify the effectiveness of atop-down comprehension attempt.

3.2.3 Summary

The overview presented in this chapter suggests the following evaluation meth-ods for program comprehension:

• To assess the effectiveness of a bottom-up comprehension attempt, we canverify the accuracy of the two mental model representations presentedby [Pennington, 1987b].

• To assess the effectiveness of a top-down comprehension attempt, we canverify the accuracy of knowledge on the relations between the knowledgedomains of the source code and problem doman, as discussed by [Brooks,1978].

3.2.4 Structure of Part IIn this part, we investigate the use of two existing reengineering patterns thatextensively use refactoring techniques w.r.t. their effect on program compre-hension. This part is structured as follows.

In Chapter 4, we introduce the Refactor to Understand reverse engineeringpattern. This pattern uses refactorings to introduce abstraction. The empiricalevaluation of this pattern’s contribution to bottom-up program comprehensionis reported in Chapter 5.




A similar structure is employed for the second reengineering pattern. Wepresent the Split Up God Class pattern in Chapter 6. This pattern uses refac-torings to introduce encapsulation . Our empirical evaluation of the contributionof this pattern to top-down comprehension is presented in Chapter 7.

Together, these four chapters discuss the application of refactoring for bottom-up and top-down comprehension. We discuss our findings and lessons learnedin Chapter 8.



Chapter 4

The Refactor toUnderstand Pattern

In this chapter, we present a reverse engineering pattern claimed to supportprogram comprehension. This claim will be validated in the next chapter.

4.1 Introduction

The Refactor to Understand reverse engineering pattern was introduced in [De-meyer et al., 2002]. This pattern is typical for reverse engineering in that it doesnot directly intend to improve the code base itself, but rather the maintainer’sunderstanding. Its purpose is to expose the design of cryptic code. Conse-quently, less emphasis is put on regression testing, and more on the compositionand verification of hypotheses concerning the code.

Refactor to Understand is based on two key principles for improving programcomprehension, being (i) the introduction of beacons as indexes into knowledge;

and (ii) the chunking of low-level structures into higher-level abstractionsBeacons are recognition points that index into knowledge [von Mayrhauser

and Vans, 1995]. Mostly, beacons are names that are semantically associatedwith a specific programming concept. Current literature on beacons has fo-cused on their recognition [Wiedenbeck and Scholtz, 1989,Crosby et al., 2002],and therefore, uses beacons for top-down comprehension. However, when intro-ducing beacons, we stimulate their recognition by future code readers. Conse-quently, we expect the introduction of beacons to stimulate bottom-up compre-

27



28 CHAPTER 4. THE REFACTOR TO UNDERSTAND PATTERN

hension.Chunking is the composition of lower level structures into higher level ab-

straction structures. Such a composition strategy allows the reader to trade off when to zoom in, based on the names of the chunks that already serve as bea-cons. For the person performing the actual composition, chunking is a means tointroduce abstraction, e.g., by recognizing that a specific sequence of mathemat-ical operations signifies the calculation of the tax amount for a product priceand tax rate. Therefore, we expect that extracting statements into methodssupports bottom-up comprehension.

Introducing beacons and chunking are both used to test hypotheses con-

cerning the code. The formulation of hypotheses, checking whether they aretrue or false, and the consequential revision is known as code cognition [vonMayrhauser and Vans, 1995]. Therefore, we regard Refactor to Understand asa cognition technique, serving the same goal as the traditional Read to Under-stand approach. This goal is to construct a mental model of the source code.

4.2 Pattern Description

The following description of the Refactor to Understand pattern is quoted from[Demeyer et al., 2002]:

“Iteratively rename and refactor the code to introduce meaningful names and to make sure the structure of the code reflects what thesystem is actually doing. Run regression tests after each changeif they are available, or else compile often to check whether your changes make sense. Decide what to do with the code after you haverefactored it.”

[Demeyer et al., 2002] suggests the following guidelines to iteratively makedesign decisions more explicit in thecode:

• Rename attributes to convey roles. Use attribute usages to discoverthe role an attribute plays.

• Rename attributes to convey intent. Use method invocations andattribute usages inside the method to find out the name associated withthe responsibility provided by a method.

• Rename classes to convey purpose. Use method invocations and classinstantiations by clients to discover a class’s purpose.



4.2. PATTERN DESCRIPTION 29

• Replace conditional branches by methods. Extract bodies of condi-tional branches into private methods with intention-revealing names.

• Define method bodies with same level of abstraction. Extract codeblocks from a long method to balance the level of abstraction of methods.

The relationship between these guidelines and key principles in bottom-upcomprehension stimulates our interests in validating the Refactor to Understandpattern.

4.2.1 Research QuestionThe Refactor to Understand pattern aims to improve the maintainer’s under-standing of the code. However, to the best of our knowledge, this pattern hasnot been empirically tested. Therefore, it is unclear whether the pattern iseffective in improving program comprehension.

In this context, we assume that the program to be understood is unfamiliar tothe maintainer, thereby suggesting the use of a bottom-up approach as discussedby [Pennington, 1987a]. Accordingly, we ask ourselves whether the Refactorto Understand pattern stimulates the construction of the abstractions of theprogram and situation model proposed in Pennington’s model.

Summarizing, we pose the following research questions w.r.t. the Refactorto Understand pattern:

1. Effectivity – How does the Refactor to Understand pattern improve pro-gram comprehension? Is the construction of a mental model, as describedby Pennington’s model, supported?

2. Efficiency – Does the application of the Refactor to Understand patternrequire more effort than mere code reading?

These research questions will be addressed in the next chapter.



30 CHAPTER 4. THE REFACTOR TO UNDERSTAND PATTERN



Chapter 5

Validating Refactor toUnderstand

This chapter is based on a previously published paper [Du Bois et al., 2005].

In this chapter, we report on our efforts towards validating the Refactor toUnderstand pattern1. As we are unaware of any previous efforts regarding such

validation, we consider this work as explorative and therefore restricted withregards to the degree to which strong conclusions can be drawn.

As a means for validation, we chose a research method that optimizes con-trol over the application of our technique. This is required to ensure that anyobserved effects can be attributed only to the selected technique, and that theapplied technique corresponds to the technique described in the previous chap-ter. Therefore, we have chosen to employ controlled experiments.

5.1 Introduction

To evaluate the mental model representations of programmers adhering to abottom-up approach for program comprehension, Pennington asked closed ques-tions about the abstractions in the program and situation model [Pennington,1987a]. However, a disadvantage of using closed questions is that these canonly confirm or reject the presence of an abstraction. Therefore, we suggest to

1The experimental material used in this chapter is publicly available athttp://www.lore.ua.ac.be/Research/Artefacts/refactor2Understand

31



32 CHAPTER 5. VALIDATING REFACTOR TO UNDERSTAND

use open questions, which, in combination with a consistent rating scheme, canresult in a more fine grained image of the extent to which the abstraction hastaken place.

Table 5.1: Questions for evaluating abstractions

Abstraction – QuestionFunction – What is the overall functionality?

Pennington’s example question: Will an average be com-

puted?Data Flow – Where does a data object get updated?

Pennington’s example question: Will the value of variablex affect the value of variable y?

Control Flow – Describe the sequence of execution.Pennington’s example question: Is the last record in file xcounted in variable y?

Operations – What does a particular line of code compute?Pennington’s example question: Is variable x initialized tozero?

State – What is the content of a data object at a particular pointin execution?Pennington’s example question: When label x is reached,will variable y have a particular known value?

Evaluation questions for each of the five abstractions discussed in Pennington’s model [Pen-

nington, 1987a].

Table 5.1 presents typical generic questions for evaluating the different ab-stractions of Pennington’s model. These questions have been composed bytranslating the example questions proposed by Pennington to an open ques-tion form [Pennington, 1987a], with exception of the control flow abstraction,as part of the the program model:

• Control flow – Pennington’s example question was very similar to thequestion for the function abstraction, which is essential for the situationmodel. In contrast, the program model stresses the structure of the text(e.g., by illustrating constructs for sequencing, iteration and conditionals),and this should be reflected in the control flow question. Therefore, we



5.2. RESEARCH HYPOTHESES 33

ask the participants to describe the control flow of a piece of code using agraphical representation or in pseudo-code notation.

The generic questions presented in Table 5.1 will be instantiated for thedifferent code segments provided to the participants. Such instantiation incor-porates a demarcation of the scope of interest and a reference to a particularmethod, variable or attribute.

For a clear, objective accuracy rating we differentiated between the followingfour distinct categories (inspired by [Vokac et al., 2004]):

• Wrong answer: Assignment not understood, no answer given or plainwrong answer.

• Right idea: The response contains the essence of a good solution, but isnot worked out properly.

• Almost correct: The response is lacking minor details, or these minordetails are wrong.

• Correct: The response is flawless.

It is obvious to see that accuracy rated this way is at least ordinal, since theratings can be ranked. However, there is also a difference in distance among theanswers. Accordingly, we rated a wrong answer as 0, an answer which containsthe right idea with 5, answer which is almost correct with 8, and a correctanswer as a 10. Such a rating is commonly applied in education. We did notdistinguish between responses in the same accuracy category, as such differenceswould be quite subjective.

Therefore, the accuracy measurement is interval scale, which allows us tocalculate means and standard deviations on these measurements, as well asapply common statistical techniques. Moreover, we also performed an analysison the ordinal data, which distinguished the same significant differences.

5.2 Research Hypotheses

A comprehension technique should be most supportive for code fragments whichare hard to comprehend. When trying to understand a program which is un-familiar, programmers employ a bottom-up comprehension approach, readingthe source code line-by-line and trying to chunk multiple statements into higher




order abstractions. One of the factors which can disturb this process is delocal-ization .

Delocalization refers to the distribution of pieces of code that are conceptu-ally related across non-contiguous parts of a program [Soloway et al., 1988]. Oneof the ways in which delocalization can occur is when part of some specific func-tionality is delegated to another method located in another class, requiring theprogrammer to navigate to the source of this other class. Such delocalizationis typically quantified using coupling indicators. In code fragments exhibit-ing extensive coupling, a programmer has to switch between different classesfrequently. As each class defines a context in which methods are specified, navi-

gating between classes incorporates a context switch. This relationship betweencoupling and the effort required to understand a class is confirmed by [McGregorand Kamath, 1995].

Accordingly, we expect that code fragments which are extensively coupledare harder to understand. We will therefore test Refactor to Understand underrepresentative degrees of coupling.

We hypothesize that the Refactor to Understand pattern stimulates the con-struction of abstractions relevant for the program and situation model. Accord-ingly, we formulate null hypotheses with regard to the pattern’s effectivity andefficiency, as measured using the generic program comprehension questions pre-

sented in Table 5.1. As we have reasons to expect that the effect of a programcomprehension technique is dependent on the degree of coupling of the codefragment to be understood, we specialize these null hypotheses for each degreeof coupling:

• H 0,accuracy,X,Y – Refactor to Understand does not increase the accuracyof answers to questions regarding abstraction X for code fragments whichexhibit a degree of coupling Y.

• H 0,time,X,Y – Refactor to Understand does not reduce the response time of answers to to questions regarding abstraction X for code fragments which

exhibit a degree of coupling Y.

Rejecting H0,accuracy,X,Y would lead to the acceptance of the alternativehypothesis, which states that Refactor to Understand increases comprehensionaccuracy with regard to the creation of abstraction X in the code part with de-gree of coupling Y. Furthermore, the rejection of both the accuracy and the timenull hypotheses would demonstrate that the information required to answer thequestion is more readily available in memory, and therefore, that the achieved



5.3. EXPERIMENTAL SET-UP 35

program comprehension would also be readily available for comprehension re-lated tasks.

Our experimental set-up is explorative in nature. Consequently, we set thesignificance criterion α to 0.10, which is common for exploratory experimentsin the domain of software engineering (e.g., [Pfahl, 2001,Johansson et al., 2001,Khoshgoftaar et al., 2006]). In other words, we can only accept group differenceswhen the probability of a difference as extreme as the one observed is less than10% ( p < 0.10).

5.3 Experimental Set-Up

The experiment presented in this chapter was replicated after its initial execu-tion. This replication was required for two reasons. First, the initial executiondid not randomize the experimental tasks, thereby introducing a threat to in-ternal validity through possible learning and fatigue effects. Second, the poolof available participants possessing the appropriate skill set is quite limited.Therefore, we replicated the original experiment using participants with a verysimilar profile.

5.3.1 Experimental Design

As an experimental design, we used a crossed factorial design with two factors(see Table 5.2). As a between-subjects factor, the program comprehension tech-nique has two levels, being Refactor to Understand and Read to Understand.This means that participants were assigned to a group, and were not allowedto switch between the comprehension technique. As a within-subjects factor,the degree of coupling of the program under study has three levels, being none,moderate and high.

As dependent variables, we measure the response accuracy and response

time of answers on comprehension questions for each of the five abstractionsas described by [Pennington, 1987a]. Subjects themselves wrote timestampsindicating the time measurement incorporates time for reading the question,time for solving the question by reconstructing the mental model representation(potentially looking back at the code), and time for writing down the answer.As the questions and associated answers were quite short (answers took about3 lines), the number of seconds it took to provide the answer (absolute scale) isa good indicator for the time to solve the question.




Table 5.2: Experimental variables

Variable type Name Values Scale

Independent

Program compr.technique

Refactor to Understandnominal

Read to Understand

Degree of CouplingNo

ordinalModerate

High

DependentResponse accuracy

{0, 5, 8, 10

}interval

Response time [0,1200] sec absolute

Accordingly, code fragments were selected which were representative for eachof the degrees of coupling. Each of the three code fragments were used in oneout of the three experimental tasks.

5.3.2 Experimental Participants

A total of twenty final (fourth) year Master level Computer Science studentsparticipated in the original experiment and its replication. The participantswere divided into two groups: a treatment and a control group. Participants inthe treatment group apply Refactor to Understand. In the control group, par-ticipants apply Read to Understand – the traditional comprehension technique.

In April 2004, 12 students participated in the original experiment in thecontext of a course on Object-Oriented Reengineering. This course is optionalin the Computer Science curriculum at the University of Antwerp. These finalyear students had substantial experience with Object-Oriented development.At the time the experiment took place, students were familiar with the Object-Oriented Reengineering Patterns defined in [Demeyer et al., 2002] during one

introductory and three lab sessions.In March 2005, 8 final year Computer Science students participated in the

replication of the experiment, in conditions identical to these of the originalexperiment.

Students were motivated to participate in the experiment because it wouldintroduce them to issues specific to understanding fragments of a large unknownsoftware system.

One week prior to the experiment, the students participated in the so called




Refactoring Lab Session 2. During this session, a real-life scenario is simulatedin which a development team has implemented initial requirements for a sys-tem, received requests for extra functionality, and decides to call in refactoringexpertise to prepare the task of adding the newly requested functionality. Thissession familiarized all students with the environment used, and the techniquesapplied in the experiment.

As a countermeasure for systematic performance differences between the twogroups, we chose to form blocks of participants with similar estimated perfor-mance. This estimation was based on grades on the course which resembles theexperimental assignment most closely. Each block consisted of a pair of partic-

ipants, which were randomly distributed over the two groups. As a result, foreach participant in the treatment group (Refactor to Understand), a matchingparticipant is present in the control group (Read to Understand).

Therefore, we feel assured that (i) the overall performance of the groups canbe expected to be equal; and (ii) each participant matches up to its counterpartin the other group.

5.3.3 Experimental Procedure

At the beginning of the experiment, an introduction to the experimental pro-

cedure was given. Guidelines were provided for the comprehension techniqueto be applied by subjects in the treatment and control group (see Figure 5.1).These guidelines contained as a common part the generic questions (see Table5.1) for the five categories of comprehension being target of inquiry at the endof each task. Therefore, all participants knew which kind of questions would beasked in each of the three tasks.

These guidelines were adapted from [Demeyer et al., 2002], and are practi-cal directions for stimulating comprehension principles. More specifically, theycan be translated in program comprehension terminology as (i) introduce bea-cons; and (ii) introduce chunks. Both renaming and extracting methods are

automated as refactorings and required only the typing of the associated key-binding and the new name of the program entity.

After this introduction, the three tasks were started. At the beginning of each task, a task sheet was provided to the participants. These sheets areillustrated in Figures 5.2, 5.3 and 5.4 for respectively task 1 (NC), 2 (MC) and3 (HC).

2A reusable course package has been composed which is publicly available athttp://www.lore.ua.ac.be/Research/Artefacts/refactoringLabSession




Rea to Un erstan

Goal

! Gain understanding in (without writing in the source code)

! Control Flow: what is the sequence of execution?! State : what is the content of a data object?! Operations: what does the code compute?! Data Flow: where does a data object get updated?! Function: what is the overall functionality?

Refactor to Understand

Goal

! Gain understanding in! Control Flow: what is the sequence of execution?! State : what is the content of a data object?! Operations: what does the code compute?! Data Flow: where does a data object get updated?! Function: what is the overall functionality?

Guidelines

! Spend your time wisely, no beautification

! Iteratively rename attributes/methods/classes to introduce meaningfulnames (CTRL+SHIFT+R).

! Extract methods or local variables to make the code structure reflect whatthe system is actually doing. (CTRL+SHIFT+M/L)

Figure 5.1: Guidelines for the Refactor to Understand experiment

Context

Class SearchPattern

in package org.eclipse.jdt.internal.core.search.matching

contains a method createMethodPattern

Task

U s e t h e a p p o i n t e d c o m p r e h e n s i o n t e c h n i q u e

(either Read to Understand or Refactor to Understand) to dig into the while-loop at the beginning of this method. After 30 minutes, you will be asked toanswer a number of questions about this piece of code.

Figure 5.2: Task sheet for task 1




Context

Class IndexAllProjects

in package org.eclipse.jdt.internal.core.search.indexingcontains a method execute

Task

U s e t h e a p p o i n t e d c o m p r e h e n s i o n t e c h n i q u e(either Read to Understand or Refactor to Understand) to dig into theexecute-method until after the large if-else-statement in which new

subclasses of IResourceProxyVisitor are declared anonymously (line 162).After 20 minutes, you will be asked to answer a number of questions aboutthis piece of code.


Each task was divided into two parts. A code reading/refactoring part anda question answering part.

First, the participants were asked to apply their appointed comprehensiontechnique. This means that half of the students read the source code and werenot allowed to change it (e.g. by refactoring or by writing comments in the code),while the other half was stimulated to apply refactorings. All students usedthe Eclipse Integrated Development Environment3 (version 2.3), with which

the students were familiar. The students applying refactorings were asked tocommit their changes to CVS4 (Concurrent Versioning System) frequently.

Second, a sheet with five questions (one for each abstraction from Penning-ton’s model) was provided, and the students were given 15 minutes to answerthe open questions in handwriting on draft paper, possibly using the sourcecode. Participants were asked to write down a time stamp before reading aquestion, and after answering the question, providing us with the response timefor each question.

Participants were informed when they had five more minutes to continueon answering the questions. After fifteen minutes, the participants were asked

to finish their questions, and the task sheets and corresponding answers werecollected.

The experimental replication differed with the original experiment what con-cerns the order in which the comprehension questions and the code fragmentswere presented to the participants (see Table 5.3). In the original experiment,the question and task order was identical for all participants. All participants

3http://www.eclipse.org4http://www.nongnu.org/cvs/




Context

Class SurroundWithTryCatchRefactoringin package org.eclipse.jdt.internal.corext.refactoring.surroundcontains a method addEdits(TextChange, TextBuffer)

Task

U s e t h e a p p o i n t e d c o m p r e h e n s i o n t e c h n i q u e(either Read to Understand or Refactor to Understand) to dig into theaddEdits method and the methods of the same class it calls. After 30 minutes,you will be asked to answer a number of questions about this piece of code.


first worked on the code fragment with no coupling, then on the moderatelycoupled code fragment, and finally on the highly coupled code fragment. More-over, the order in which the questions was asked was also identical for all tasks,namely {function, control flow, operations, data flow, state}. In the experimen-tal replication, both the order of the tasks and the questions was randomized.

Table 5.3: Task order across experimental executions

Experiment Participant Pair Task order

Original PP1–6 NC – MC – HC

Replication

PP1 MC – NC – HCPP2 MC – HC – NCPP3 HC – NC – MCPP4 NC – HC – MC

Representation of the order in which the code fragments were presented to the pairs of

experimental participants. Each pair consisted of one participant from the Refactor

to Understand group, and a matched participant from the Read to Understand group.

NC signifies the code fragment with No Coupling . MC signifies the code fragment

with Moderate Coupling . HC signifies the code fragment with High Coupling .

At the end of the experiment, a post-experiment questionnaire was filled inby all subjects (see Appendix A, Figures A.1 and A.2).

5.3.4 Experimental Tasks

The experiment consisted of three tasks. Each task required the comprehensionof a given piece of code, after which the participants were asked to answer a set




of comprehension questions. At the beginning of each task, a task sheet wasprovided to the participants. These sheets are illustrated in Figures 5.2, 5.3 and5.4 for respectively task 1 (NC), 2 (MC) and 3 (HC).

The pieces of code which had to be comprehended across the three taskswere extracts from the Eclipse Platform (version 2.1.3), which is mostly knownas an Integrated Development Environment for Java. More specific, the selectedpieces of code originated from the org.eclipse.jdt.internal package, whichcontains a total of 721 classes over more than 140 thousands lines of code.

To study the effect of Refactoring to Understand under different degrees of coupling, source code fragments were chosen to vary from no coupling in the

first task, over moderate coupling in the second task, to high coupling in thelast task. We set out to select code fragments which varied regarding coupling,yet were about similar w.r.t. other properties. As illustrated in Table 5.4,perfect similarity is unfeasible in practice. The table depicts the cumulatedLines of Code (LOC), Number of Methods (NOM), Number of Local Variables(NLV) and Cyclomatic Complexity (CC) values, which also vary but not tothe extent as the coupling properties Message Passing Coupling (MPC) andCoupling Between Object Classes (CBO).

Table 5.4: Properties of the code fragments

Property No Moderate HighCoupling Coupling Coupling

Lines of Code 109 102 76Nr of Methods 1 1 4

Nr of Local Variables 18 24 38Cyclomatic Complexity 27 5 14

Message Passing Coupling 0 42 61Coupling Between Object classes 0 10 30

Size, complexity and coupling properties of the code fragments used respectively in

tasks 1 (no coupling), 2 (moderate coupling) and 3 (high coupling).

As can be read from the MPC and CBO values, the code fragment with nocoupling (NC) was fully self-contained, and did not depend on other classes. Themoderately coupled code fragment (MC) has about the same length, yet has asimpler control flow and collaborates with some other classes. Finally, the highlycoupled code fragment (HC) implements its functionality by collaboration withmany different classes.




5.3.5 Comprehension Questions

The set of questions for task 1, 2 and 3 are displayed in the Figures 5.5, 5.6 and5.7 respectively.

We note that it is generally infeasible to compose questions which involveonly a single abstraction (e.g., knowledge on the control flow abstraction) with-out implicitly evaluating other abstractions (e.g., knowledge on the operationsabstraction). Therefore, the resulting data will not be completely independent.I.e., if a participant would be unable to build up the program model represen-tation (requiring the abstractions control flow and operations) then we would

expect the situation model representation (requiring the abstractions functionand data flow) to also be incomplete. Nonetheless, these implicit dependenciesdo not hinder in assessing each abstraction as present in the participants’ mentalrepresentation.

In the first and third task, respectively for the non-coupled (NC) and thehighly coupled code fragment (HC), the operation question provided in thereplication differed from the operation question in the original experiment. Inthe first task, this difference is as follows:

Original: Describe the characteristics of all the different input composi-tions which the scanner considers invalid .

Replication: Describe the characteristics of all the different input com-positions which the scanner considers valid .

For the third task, the question in the replication was merely a part of thequestion of the original experiment:

Original: Describe in your own words when and how the change param-eter is modified in method addEdits.

Replication: What is the meaning of the statement at line 207 in methodaddImportEdit: change.addTextEdit("", edit);.

As a consequence, the data with regard to the operations question for NCand HC in the experimental replication cannot be compared with the data of the original experiment.

Following, we describe our arguments for stating that a question primarilytests an abstraction. We restrict our discussion to those questions who differfrom the generic form as presented in Table 5.1.

For task 1, (the code fragment which exhibits no coupling), the questionsregarding the program model differ slightly from their generic form:




Your name: __________________________

Questions: 1. Time when starting to read this question: _____ h ____m ____s

[Function] Describe in your own words what functionality is implemented in

the while loop.Time when finished answering this question: _____ h ____m ____s

2. Time when starting to read this question: _____ h ____m ____s

[Control Flow] Draw a state chart illustrating the execution of the while-loopof method createMethodPattern in class SearchPattern.

! Draw a node for each state. Use the names of the states as written in

the code itself. Differentiate between initial and final states.! Draw a directed labelled edge (arrow with label X) between states when

the scanner shifts from the source-state to the target-state at event X.

Use the following schematic notation:

Time when finished answering this question: _____ h ____m ____s

3. Time when starting to read this question: _____ h ____m ____s

[Operations] Describe the characteristics of all the different inputcompositions which the scanner considers invalid.Time when finished answering this question: _____ h ____m ____s

4. Time when starting to read this question: _____ h ____m ____s[Data Flow] Describe briefly when the value of variable parameterTypes is

updated.Time when finished answering this question: _____ h ____m ____s

5. Time when starting to read this question: _____ h ____m ____s[State] In the first case-branch of the first switch-statement you will find the

statement declaringType += tokenSource + selector;

Describe briefly the value of variable declaringType after this statement.Time when finished answering this question: _____ h ____m ____s

NameOfInitialState

NameOfNextState1 NameOfNextState2

Character X Character Y

Character Z

FinalState1 FinalState2

Figure 5.5: Comprehension questions for task 1




Your name: _________________________________________

Questions:

1. Time when starting to read this question: ___ h ___ m ___ s[Operations] Describe the need for the final variable OK, which is declared at thebeginning of the try-block in the execute method.Time when finished answering this question: ___ h ___ m ___ s

2. Time when starting to read this question: ___ h ___ m ___ s

[Control Flow] Write a pseudo-code summary of how the execute method performs itscore functionality. Do not simply refer to syntactical operations, but describe specificsemantics.Use the following pseudo-code convention:

Write shoppingList

Drive to shoppingMarket

Take shoppingCart

ForEach item in shoppingList

If itemInReduction

Add 2 of item to shoppingCart

ElseIf itemNotSoldOut


Mark item as bought

Pay items bought

…Time when finished answering this question: ___ h ___ m ___ s

3. Time when starting to read this question: ___ h ___ m ___ s[State] The condition of the if-else statement is “if (max == 0)”. Describe briefly thevalue of variable max when it is evaluated in this condition.Time when finished answering this question: ___ h ___ m ___ s

4. Time when starting to read this question: ___ h ___ m ___ s[Function] Describe in your own words the functionality implemented in the if-else

statement.Time when finished answering this question: ___ h ___ m ___ s


[Data Flow] Describe briefly when the variable “indexedFileNames “ of typeSimpleLookupTable is updated.

Time when finished answering this question: ___ h ___ m ___ s





Your name: _________________________________________

Questions:

1. Time when starting to read this question: ___ h ___ m ___ s[Data Flow] Describe in your own words what is added to/removed from variablehandleDeclarationStatements of type List in method addEdits, and how it contributes to

the overall functionality.Time when finished answering this question: ___ h ___ m ___ s


[Function] Describe in your own words the functionality implemented in the addEditsmethod.Time when finished answering this question: ___ h ___ m ___ s

3. Time when starting to read this question: ___ h ___ m ___ s[Operations] What is the meaning of the statement at line 207 in methodaddImportEdit: change.addTextEdit(“”, edit);.


4. Time when starting to read this question: ___ h ___ m ___ s[Control Flow] Write a pseudo-code summary of how the addEdits method performs itsfunctionality. Do not simply refer to syntactical operations, but describe specific

semantics.Use the following pseudo-code convention:

Write shoppingList

Drive to shoppingMarket

Take shoppingCart

ForEach item in shoppingList

If itemInReduction


ElseIf itemNotSoldOut


Mark item as bought

Pay items bought

…



[State] Describe accurately the composition of the value of variable codeBlock when it isused in the last statement of method addEdits. This variable of typeCompositeCodeBlock is declared after the for-loop (line 195).Time when finished answering this question: ___ h ___ m ___ s





• Control Flow – We asked the participant to illustrate the execution of aspecified while loop. This while loop implemented a state machine, using asingle switch statement (with 3 non-default cases), followed by the retrievalof a new value used in the switch variable. We therefore argued that thecontrol flow (sequence of actions) described inside this while loop wouldbe best represented using a state chart. State charts allow the participantsto focus on the sequence of events by: (i) indicating the initial state; (ii)specifying which events can occur when; and finally (iii) indicating finalstates. Therefore, in this particular case, the description of the controlflow and of the state (conditionalized actions) are identical.

• Operations – We asked the participant to describe characteristics of inputwhich lead to an (in)valid result at the end of the switch statement. Thisquestion differs from the general question in that it requires the interpre-tation of the semantics of more than only a single statement. Therefore,this question implicitly requires the presence of a control flow abstraction,describing the sequence of actions. However, our data indicated that, evenin the case a participant did not understand the control flow, he was stillable to understand the detailed actions, as asked for in the operationsquestion.

Accordingly, we do not consider the deviations from program model ques-tions for task 1 with their generic to be a threat to validity.

In task 2, one question differs slightly from their generic form:

• Operations– We asked the participant to explain the need for a specifiedvariable. Since, after its initialization, this variable was only used at oneline of code, this question is merely of a form to alternative the genericquestion.

Summarizing, the questions used for all three tasks were either mere instan-tiations of the generic questions for an abstraction, or equivalent variations.

We therefore consider these questions valid tests for assessing the participants’mental representations.

5.4 Data Analysis

In this section, we analyze the data gathered in the experiment. First, we dis-cuss how we processed the raw material provided by the experiment. Second,we discuss our observations on the application of the Refactor to Understand



5.4. DATA ANALYSIS 47

pattern. Thereafter, we discuss group differences with regard to our hypothe-ses concerning the accuracy and time of answers on program comprehensionquestions.

5.4.1 Analysis Procedure

The experiment provided us with three information sources for each of the threetasks.

1. Question sheets indicating the time stamps.

2. Answers to the five open questions.

3. For the participants of the Refactor to Understand group: different ver-sions of the modified source code as recorded by the versioning system(CVS).

4. The post-experiment questionnaire.

The handwritten time stamps were used to calculate response times in sec-onds.

The answers to the five open questions were evaluated by the author usinga fixed rating scheme. The fact that the author evaluated the answers himself

is not considered a threat to validity, as the sheets did not indicate to whichgroup the participant belonged. Therefore, no systematic differences could havebeen introduced during evaluation.

The rating scheme, mentioned in section 5.1, was used to categorize answers.This categorization was based on a solution key, which indicated under whatconditions an answer would fall into a category.

Correct: Only answers which were flawless were categorized as correct. Theseanswers were rated a score of 10.

Almost Correct: In case the answer was missing minor details, or these minor

details were wrong, the answer was categorized as almost correct. Theseanswers were rated a score of 8.

As an example, let us consider the question on data flow for the first task(see Figure 5.5). We consider the initialization or size adjustment as aminor detail in the updates to this array variable. In case the initializationor size adjustment were left out, or were wrong, the answer was categorizedas almost correct. Assignments of values to the cells of this array, however,were not considered as minor details.




Right Idea: In case the answer was partly true, yet missing major details,or these major details were wrong, the answer was categorized as havingthe right idea, and accordingly, rated a score of 5. Let us illustrate thisprinciple according to the same example. In case at least one assignmentto the cells of the array was described correctly, the answer was categorizedas exhibiting the right idea.

Wrong: In case an answer did not satisfy the criteria for the category rightidea, the answer was categorized as wrong, and assigned a score of 0.

For the Refactor to Understand group participants, the adherence to thepattern was assessed by counting the number of refactorings applied.

5.4.2 Applications of Refactorings

Table 5.5 displays the number of refactorings applied by each of the subjects

in the refactoring group. This data is relevant as it allows to characterize thespecific treatment as applied by the members of the treatment group.

For the tasks on the code fragments with no and moderate coupling, onesubject did not apply any refactorings. However, searching for refactoring op-portunities still steered their comprehension, and therefore, we still categorizethem in the treatment group.

Over the tasks, there was a difference in the applications of refactorings. Therelative frequency of applications of the refactorings Rename variable/method was respectively 17% for the code with no coupling; 32% for the moderatelycoupled code; and 63% for the highly coupled code. A potential explanation

of these frequency differences is that in code fragments that contain more localvariables or use more different classes, there are more opportunities to applythe Rename variable/method refactoring.

Table 5.5 indicates that the Refactor to Understand pattern was indeedapplied. However, it was not applied extensively, as can be observed fromthe limited number of refactorings. Therefore, it is reasonable to assume thatmore extensive application of this reverse engineering pattern will lead to moreextreme group differences.




Table 5.5: Application of refactorings

Coupling ida #Rename #Extract Methods1 0 2s2 1 1

No s3 0 0 Coupling s4 0 1

s5 1 2s6 0 2

avg 0.33 1.33

s1 0 0 s2 5 1

Moderate s3 0 4Coupling s4 0 2

s5 1 3s6 1 1

avg 1.17 1.83 s1 4 1s2 1 0

High s3 0 2

Coupling s4 2 0s5 1 3s6 3 0

avg 1.83 1a Signifies the identification number of the participant, of which

the table represents the number of applications of the Rename

variable/method and Extract Method refactorings.




5.4.3 H 0,accuracy – Differences in response accuracy

Table 5.6: Comparison of the response accuracy between groups

No Moderate HighRepa Coupling Coupling Coupling

ControlFlow

O 4.7 < 5.5, p=.8184 6.2 > 5.2, p=.6686 6.8 > 4.0, p=.0878

R 5.8 = 5.8, p=N/A 6.3 > 2.5, p=.0288 9.0 > 7.5, p=.0908

O∪R 5.1 < 5.6, p=.8283 6.2 > 4.1, p=.0842 7.7 > 5.4, p=.0337

Operations

O 6.5 > 4.7, p=.2551 6.0 > 2.5, p=.1261 6.3 < 6.8, p=.5778

R 5.3 < 8.3, p=.9880 8.8 > 3.8, p=.0459 6.0 > 3.3, p=.1206O∪R not allowed 7.1 > 3.0, p=.0218 not allowed

FunctionO 7.7 > 6.3, p=.2598 6.7 > 4.7, p=.2314 8.5 > 4.7, p=.0560

R 7.8 > 7.0, p=.3618 5.8 > 3.3, p=.1392 6.3 > 3.8, p=.1955

O∪R 7.7 > 6.6, p=.2132 6.3 > 4.1, p=.1026 7.6 > 4.3, p=.0266

Data FlowO 4.7 < 5.8, p=.8898 3.3 > 1.7, p=.6291 5.5 > 4.7, p=.2484

R 3.8 < 5.0, p=.6412 3.3 > 1.7, p=.2837 8.3 > 7.5, p=.3765

O∪R 4.3 < 5.5, p=.8198 3.3 > 1.7, p=.2255 6.6 > 5.8, p=.2288

StateO 5.0 < 6.3, p=.7887 6.7 = 6.7, p=.6291 9.0 > 6.4, p=.1418

R 1.3 < 3.3, p=.7328 9.0 > 5.8, p=.0761 8.0 > 7.7, p=.2500

O∪R 3.3 < 4.8, p=.8478 7.6 > 6.1, p=.1151 8.8 > 6.9, p=.1879

a Rep signifies the experimental replication. O stands for Original experiment, R stands for Repli-

cation experiment and O ∪U stands for the unification of the data from the original experiment

and it’s replication.

Each cell in the table is specified as X • Y , p=Z in which X and Y represent the average

accuracy of the participants of respectively the Refactor to Understand or Read to Understand

group. The • symbol represents the order between these averages, which can be either of {<, =,

>}. Z signifies the statistical significance of a one-sided paired Student t-test between these two

groups, telling us the probability of a group difference as extreme as the one indicated in case

the null hypothesis is true. This null hypothesis states that the Refactor to Understand group

does not respond more accurate than the Read to Understand group.

Table 5.6 depicts the average response accuracy for both groups, in theformat Refactor to Understand group • Read to Understand group. The •symbol represents the order between these group averages, and can be eitherof {<, =, >}. The p-value for the associated one-sided paired Student t-testis also provided. This test is typically used to verify the probability that twodata sets originate from the same population. A paired t-test means that in




comparing these two data sets, each element is uniquely paired with another onefrom the other set. Finally, a one-sided t-test means that our null hypothesisis directional, since we try to refute that the Refactor to Understand groupresponds less then or equally accurate as the Read to Understand group.

For each abstraction, the table shows the averages for the original experiment(Rep = O), the experimental replication (Rep = R) and overall (Rep = O ∪ R).

We will discuss the observed differences for each of the levels of couplingseparately:

No coupling – The Refactor to Understand group answered less accurately forall but the questions on function and operations abstractions. With regardto function accuracy, the Refactor to Understand group outperformed theRead to Understand group.

We remark that the operations questions on the moderately and highlycoupled code fragment differed from the question of the original experi-ment. We can observe that changing these questions had a considerableeffect on the results. Therefore, we remain inconclusive about the groupdifferences on operations accuracy with regard to these code fragments.

Moderate coupling – The Refactor to Understand group responded more ac-curate on the questions on all abstractions. Significant group differenceswere noted w.r.t. both abstractions of the program model (control flow,p=.0842; operations, p=.0218). The group differences w.r.t. the function(p=.1026) and state (p=.1151) abstractions were close to being significant.

High coupling – For all abstractions except the operations abstractions, theresponse accuracy of the Refactor to Understand group was higher. Thisgroup difference was significant for the control flow (p=.0337) and function

(p=.0266) abstraction questions.

Our results w.r.t. responses on the operations question were contradictingbetween the original experiment and the replication. As in the case of the code fragment with no coupling, we cannot compare these results asthe operations question was altered in the experimental replication. Wetherefore remain inconclusive what concerns the group differences w.r.t.the operations abstraction.




Table 5.7: Data loss w.r.t. accuracy observations

No Moderate HighRep Coupling Coupling Coupling

Data FlowO 0 – 3R 0 – 1

O ∪ R 0 – 4

StateO 1 – 2 0 – 3 0 – 1R 2 – 1

O∪

R 1 – 2 0 – 3 2 – 2

Represents the number of observations missing from the data set, reported in

the format Refactor to Understand – Read to Understand .

Table 5.7 discusses the data loss w.r.t. accuracy observations. This dataloss is due to two reasons: (i) the questions were asked in a fixed order, withdata flow and state questions being the two last questions; and (ii) due to timerestrictions on the experimental session, we were forced to limit the amount of time available for answering the questions. We will discuss the threat to validityassociated with this loss in the Threats to Validity section 5.6.

Table 5.8: Rejection of H 0,accuracy,X,Y

No Moderate HighCoupling Coupling Coupling

Control Flow R ROperations R

Function AR RData Flow

State AR

Represents the rejection of the null hypotheses H 0,accuracy,X,Y ,in which X stands for an abstraction present in the mental rep-

resentation and Y stands for a degree of coupling for which this

rejection was demonstrated. R stands for Rejected (p < .10), and

AR stands for Almost Rejected (.10 < p < .12).

Summarizing, Table 5.8 illustrates the rejection of null hypotheses as sup-ported by our observations. This means that abstractions of both the program




and situation model have been shown to be more accurate for the Refactorto Understand group in the task on the moderately and highly coupled codefragment.

5.4.4 H 0,time – Differences in response time

We will discuss the observations with regard to the time required for partic-ipants to respond to the comprehension questions in the same manner as wedid for accuracy. Group differences regarding the time for answering programcomprehension questions are reported in Table 5.9.

No coupling – The Refactor to Understand group answered the questionsslower for all but the questions on operations and state abstractions. Withregard to the time required to answer the state question, the observationsfrom the replication contradicted with those from the original experiment.However, the group difference in the replication was merely 20 seconds,which can be safely neglected.

We note that the contradicting group differences between the original ex-periment and its replication which were previously observed for responseaccuracy w.r.t. the operations question were also observed for response

time. This was due to altering the question.

Moderate coupling – The response times of both groups were similar on allbut the control flow and data flow questions. For the control flow ab-straction, the group differences as observed in the original experimentcontradicted with those observed in its replication. However, the groupdifference in the original experiment was merely 40 seconds on a totalresponse time of 6.5 minutes. Due to this marginal difference, this con-tradiction can be neglected.

With regard to the data flow question, the Refactor to Understand group

responded significantly faster than the Read to Understand group (p=.0621).High coupling – The Refactor to Understand group responded faster to the

question on control flow and slower on the question on state. For functionand data flow abstractions, the observations from the experimental repli-cation contradicted these of the original experiment. These contradictionscannot be neglected. However, we have found no systematic differencesbetween the original experiment and its replication which might explainthese contradictions.




Table 5.9: Comparison of the response time between groups

No Moderate HighRepa Coupling Coupling Coupling

ControlFlow

O 402 > 362, p=.7042 366 < 409, p=.3066 322 > 321, p=.5047

R 417 > 377, p=.6860 518 > 417, p=.7001 389 < 412, p=.1861

O∪R 408 > 368 p=.7840 427 > 412, p=.5690 349 < 357 p=.4415

OperationsO 236 > 205, p=.6655 113 = 113, p=.5036 128 < 165, p=.2171

R 196 < 235, p=.2507 180 < 207, p=.3310 206 < 160, p=.6639

O∪

R not allowed 140 < 150, p=.3620 not allowed

FunctionO 172 > 168, p=.5383 182 < 190, p=.4587 109 < 201, p=.0908

R 122 > 99, p=.6054 178 > 171, p=.5320 240 > 74, p=.9900

O∪R 152 > 141, p=.6202 180 < 182, p=.4857 161 < 150, p=.5750

Data FlowO 132 > 111, p=.8779 81 < 101, p=.2443 123 < 151, p=.1118

R 177 > 148, p=.6373 63 < 128, p=.1229 309 > 257, p=.6555

O∪R 150 > 126, p=.7868 75 < 114, p=.0621 198 > 194, p=.5332

StateO 165 < 216, p=.3031 76 < 79, p=.4459 200 >158, p=.9742

R 173 > 152, p=.6838 96 > 83, p=.5610 135 > 124, p=.5882

O∪R 168 < 184, p=.2054 84 > 81, p=.5331 184 > 145, p=.9137

Table 5.10: Data loss w.r.t. time observations

No Moderate HighRep Coupling Coupling Coupling

Data FlowO 0 – 3R 1 – 1

O ∪ R 1 – 4

StateO 1 – 2 0 – 3 0 – 1R 2 – 1

O ∪ R 1 – 2 0 – 3 2 – 2Represents the number of observations missing from the data set, reported in

the format Refactor to Understand – Read to Understand .

The data loss w.r.t. response time observations was very similar to that of accuracy observations. In fact, there was only a single additional loss, due to aparticipant who did not write down a time stamp in the experimental replication




after responding a data flow question. Again, we refer to the Threats to Validitysection 5.6 for a discussion on the associated threats to validity.

Summarizing, Table 5.11 illustrates the rejection of null hypotheses w.r.t.time as supported by our observations. The table indicates that a single ab-straction of the situation model has been shown to be more directly availablefor the Refactor to Understand group in the task, yet this has been observedonly for the moderately coupled code fragment.

Table 5.11: Rejection of H 0,time,X,Y

No Moderate HighCoupling Coupling Coupling

Control FlowOperations

FunctionData Flow R

State

Represents the rejection of the null hypotheses H 0,time,X,Y , in

which X stands for an abstraction present in the mental repre-

sentation and Y stands for a degree of coupling for which this

rejection was demonstrated. R stands for Rejected (p < .10).

5.4.5 Post-experiment questionnaire

After the experiment, a questionnaire was handed out, which was an adaptationfrom [Briand et al., 2001]. Closed questions were asked about motivation, adher-ence to guidelines, understanding of requirements, approach to answering thequestions, accuracy estimation, reasons for not completing, code quality esti-mate and perceived difficulty of questions on the three tasks. The questionnaire

is illustrated in Appendix A in Figures A.1 and A.2.We observed no problems with motivation nor clarity of questions, nor with

the subjectively evaluated comprehensibility of the code. On a scale from 1(barely comprehensible) to 10 (easily comprehensible), the quality of the codewas rated an average of 7.1 by the Refactor to Understand group and 6.3 forthe Read to Understand group. This difference was not significant.

There was a noteable difference regarding the difficulty of the tasks. Thequestions on the code fragment with no coupling were considered more difficult




than those on the moderately coupled fragment (p=0.0609), which on theirturn were found more difficult than the questions on the highly coupled codefragment (p=0.1412). This difference w.r.t. subjectively evaluated difficultymight explain why the comprehension accuracy on the highly coupled codefragments is highest for both groups.

5.5 Interpretation of Results

To discuss the results of this exploratory experiment, we describe our findings

for the two factors under study: (i) the comprehension techniques Read toUnderstand and Refactor to Understand; and (ii) the degree of coupling of thecode fragments to be understood.

5.5.1 Comprehension Technique as a Factor

In this experiment, we verified whether the reverse engineering pattern Refac-tor to Understand can help improve program comprehension. In two out of three experimental tasks, the Refactor to Understand group demonstrated sig-nificantly higher accuracy w.r.t. abstractions for both the program and thesituation model. We interpret these results as a confirmation that the applica-tion of Refactor to Understand did indeed support the construction of the twomental model representations relevant for bottom-up comprehension.

Since we did not observe that the significantly higher abstraction accuracyalso led to faster response times, we cannot claim that these mental modelrepresentations are more readily available.

Table 5.12 depicts the average comprehension accuracy over the three tasks.Since the operations question was altered in the replication, we leave this ab-straction out.

As can be read from the table, the overall largest group differences were ob-

served regarding function and control flow, being the main abstractions of therespectively the situation and the program model. Differences on state compre-hension were smaller, and non-existing w.r.t. data flow. Thus, on average, theRefactor to Understand group outperformed the Read to Understand group.

Summarizing, our results support the hypothesis that Refactoring to Un-derstand supports bottom-up comprehension. Concretely, two out of three ex-perimental tasks demonstrated higher accuracy of the two main mental modelrepresentations.



5.5. INTERPRETATION OF RESULTS 57

Table 5.12: Average comprehension accuracy

Refactor Readto Understand to Understand

Control Flow 6.3 > 5.0Function 7.2 > 5.0

Data Flow 4.7 = 4.7State 6.5 > 5.9

This table represents the average comprehension accuracy between

groups across the three tasks. We thereby discuss the main effect of the factor Program comprehension technique.

5.5.2 Degree of Coupling as a Factor

We introduced the degree of coupling factor to test the comprehension tech-niques under the assumption that the highly coupled code fragment would bemore difficult to comprehend. However, the results from our post-experimentquestionnaire clearly indicate the opposite, namely that the participants foundthe task on the non-coupled code fragment more difficult than that of the mod-erately coupled fragment, which on its turn was found more difficult than thehighly coupled code fragment.

This difference in perceived difficulty might be partially explained by thecyclomatic complexity, which is highest for the non-coupled code fragment.Moreover, the code size of the highly coupled code fragment was about onefifth smaller than the size of the moderately coupled fragment.

Nonetheless, this would lead to the interpretation that the Refactor to Un-derstand pattern did not significantly support the mental representations for thetask which was perceived as most difficult. However, in both the original exper-iment and its replication, we consistently observed higher accuracy with regardto the function abstraction for the Refactor to Understand group, which is es-

sential for the situation model. While this group difference was not significant(p=.2132), the fact that this difference was observed for the situation model isremarkable. The reason for this is that the situation model is generally consid-ered to be a mental representation which is constructed only after the programmodel representation. It is therefore unclear whether the Refactor to Under-stand program provided no support whatsoever for bottom-up comprehensionin the task which was perceived as most difficult.

The assumption that the effect of Refactor to Understand is dependent on




the degree of coupling is supported in two ways: (i) the usage of refactoringsvaried over the degrees of coupling; and (ii) the effect of Refactor to Understanddiffered over the degrees of coupling.

The degree of coupling affects the application of Refactor to Understandin the relative usage of refactorings. To comprehend the non-coupled codefragment, mostly Extract Method was applied, while for the highly coupled codefragment, mostly renames were applied (see Table 5.5). When comparing theproperties of the code fragments (see Table 5.4), an intuitive explanation wouldbe that the highly coupled fragment contained more opportunities to renamevariables and methods. This difference in properties can itself be explained by

the difference in degree of coupling, as a highly coupled implementation wouldrely on the collaboration of many instances, which would be reflected in morelocal variables, and therefore, in more rename opportunities.

Between the code fragments, a variation in the group differences was ob-served. The application of Refactor to Understand led to more accurate programand situation models for both the moderately and highly coupled code. This wasnot the case for the code fragment with no coupling. While this might suggestan interaction between the program comprehension technique factor and thedegree of coupling factor, this has still to be confirmed in further experiments.

5.6 Threats to Validity

This work was set up as an exploratory experiment. Therefore, there are severelimitations to generalizability of its results. Moreover, practical restrictions didnot permit the ideal set-up. For clarity, we specify the main threats to validity.

5.6.1 Internal Validity

Internal validity is the degree to which the experimental setup allows to ac-curately attribute an observation to a specific cause rather than to alternative

causes. Specific set-up deficiencies make it difficult to infer clear conclusions.The threats we have identified are:

• Maturation effects can occur due to processes within subjects which changeas time passes. In the original experiment, the question and task orderposed a threat to learning and fatigue effects. Therefore, the questionand task order was randomized in the experimental replication. As theobservations of the replication confirmed these of the original experiment,we can state that the task order did form a threat to validity.



5.6. THREATS TO VALIDITY 59

• Attrition refers to the fact that participants in an experiment sometimesfail to complete the outcome measures [Shadish et al., 2002]. As the timeduring which questions could be answered was limited, some participantswere unable to answer the last questions. Moreover, in the original ex-periment, the order of the questions was identical across the three tasks.Accordingly, the missing data were all observations on data flow and statecomprehension.

Consequently, it is possible that our inability to detect significant groupdifferences regarding data flow and state comprehension is due to this dataloss. E.g., even when merely 6 paired observations could be used to eval-uate group differences w.r.t. the accuracy of the data flow abstraction inthe moderately coupled code fragment, the p-value was almost significant(p=.1151). Moreover, the group difference w.r.t. response time on thisabstraction for the same code fragment was statistically significant. Theseobservations indicate the likelihood that at least H 0,accuracy,dataflow,MC

might also have been rejected in case the data loss did not occur.

• An instrumentation effect can occur when any instrument used varied overthe experimental tasks. We paid attention to find code fragments whichare as similar as possible while varying in degree of coupling. The compre-

hension tasks were identical, and the open questions for each comprehen-sion category were based on templates. However, even while applying allthese precautions, we could observe in the results of the post-experimentquestionnaire that there was a significant group difference regarding subjective evaluation of the difficulty of the tasks. More specifically, the taskson the highly coupled fragment were found significantly easier, and thoseon the fragment with no coupling were found significantly harder. As weare unable to prove that this difference in subjective difficulty of the taskswas due to the degree of coupling, we are inconclusive about the extent of this threat.

A clear instrumentation effect is present for the operations question, whichwas changed in the experimental replications for the tasks on the non-coupled and highly coupled code fragment. Accordingly, we have left outthe operations question in the discussion of results.

5.6.2 External Validity

External validity is the degree to which research results can be generalizedoutside the experimental setting or population under study. As an exploratory




study, this work was designed more towards investigating interesting phenomenathan to be generalizable.

• As we are unaware of any studies on the distribution of coupling measuresacross software systems, we are unable to make a hard claim that our codefragments are representative w.r.t. the degree of coupling. Nonetheless,the coupling measures for our code fragments clearly present differentorders of magnitude. E.g., the number of classes used was 0, 10 and 30 inrespectively the non-coupled, moderately and highly coupled fragment.

Our code fragments were clearly not representative w.r.t. the size of wholesoftware systems. However, one has to take into account that the bottom-up comprehension process is merely triggered in case code appears tobe directly relevant [Koenemann and Robertson, 1991]. Therefore, weshould evaluate whether the size of these code fragments is representativeby comparing them against programs used in experiments w.r.t. bottom-up comprehension. E.g., Pennington herself used program segments of exactly 15 lines of code [Pennington, 1987b]. [Ramalingam and Wieden-beck, 1997] used identical programs as [Corritore and Wiedenbeck, 1991],which count about 30 lines of code. The program used by [Fix et al., 1993]was somewhat larger and counted 135 lines of code. We therefore arguethat our code fragments were representative w.r.t. the size of programsused in these kinds of experimental settings. However, we make no claimsw.r.t. the generalizability of our results to applications of the Refactor toUnderstand pattern on much larger code fragments.

• Our participants were last year computer science students. The experi-ment took place in the second semester, in an optional course on ObjectOriented Reengineering. It is likely that these students are not represen-tative for the population of last year computer science students, as theirchoice for this course might be an indicator of special interests and earlier

expertise. Neither can we generalize our conclusions to the population of professional software engineers. Surely, there is little difference betweenthese students and junior software engineers. However, more experiencedsoftware engineers have been shown to apply different comprehension pro-cesses (e.g., as described by [Pennington, 1987b, Fix et al., 1993,Canforaet al., 1996]). It is therefore unclear whether such clear group differencesas observed using our student participants would also be present whenusing professional programmers.



5.7. CONCLUSION 61

5.7 Conclusion

These findings provide the first empirical support for the general claim thatthe process of refactoring can improve the understanding of software systems[Fowler, 1999], illustrated in higher accuracy of both the program and the situ-ation model as mental representations of the source code. We have found someindications that the Refactor to Understand pattern might be most effective incode fragments which exhibit some degree of coupling, yet remain inconclusiveon this subject.

Significant differences were observed w.r.t. control flow and function abstrac-

tions. These abstractions are required for constructing the two mental modelrepresentations which have been shown to be essential for complete comprehen-sion [Pennington, 1987a]:

• The program model , stressing knowledge on the text structure, is improvedthrough significantly higher accuracy of control flow knowledge;

• The situation model , stressing knowledge on goals in the problem domain,is improved through significantly higher accuracy of function knowledge.

Therefore, these results confirm that the introduction of beacons – recogni-

tion points that index into knowledge – and chunks – higher level abstractionsof lower level structures – through renaming program elements and extractingmethods supports the creation of mental abstractions relevant in the context of bottom-up comprehension.



Chapter 6

The Split Up God ClassPattern

In this chapter, we present a reengineering pattern addressing class decomposi-tion. While the improvement of comprehensibility is not the main objective of this reengineering pattern, it is one of the claimed benefits. This claim will be

validated in the next chapter.

6.1 Introduction

The Split Up God Class reengineering pattern was introduced in [Demeyer et al.,2002]. This pattern addresses the god class anti-pattern [Riel, 1996,Brown et al.,1998], which grows naturally in evolving systems. A high rate of source codeadaptations tends to introduce design flaws such as misplaced responsibilities.Ultimately, some classes take the form of black holes, accumulating and attract-ing ever more responsibilities. These god classes are considered to be the main

targets for reorganization, and the preferred approach to resolve them is to ex-tract data classes, and move associated behavior to them [Demeyer et al., 2002].In other words, the Split Up God Class pattern is an encapsulation technique.

The object-oriented paradigm introduced the encapsulation of related pro-cedures and data into conceptual groupings called object classes. These en-capsulations provide abstraction structures that are expected to support theconstruction of a mental model. God classes are incohesive groupings of un-related data and behaviour, thereby making it harder for the maintainer to

63



64 CHAPTER 6. THE SPLIT UP GOD CLASS PATTERN

reconstruct abstractions in his mental model.Split Up God Class introduces two kinds of abstractions. At the system

level, one can identify controllers that exhibit more methods and less data, andentities, exhibiting more data and less methods [Jacobson et al., 1992]. This dis-tinction is promoted in design patterns such as the Entity-Boundary-Controllerpattern [Jacobson et al., 1992], the Model-View-Controller pattern [Krasnerand Pope, 1988], the Presentation-Abstraction-Controller pattern [Buschmannet al., 1996] and the Use-Case controller pattern [Larman, 2001]. Split Up GodClass disentangles a set of responsibilities and data into controllers and entities,and extracts classes accordingly.

By splitting up a god class in controllers and entities, abstractions are in-troduced, which are expected to make it easier for the maintainer to constructa mental model.

6.2 Pattern Description

The following stepwise description of the Split Up God Class pattern is quotedfrom [Demeyer et al., 2002]:

“The solution relies on incrementally moving behavior away from the god class. During this process, data containers will become moreobjectlike by acquiring the functionality that the god class was performing on their data. Some new classes will also be extracted from the god class.”

Transforming a god class is not a single step operation. A suggested proce-dure is to:

1. transform the god class into a light-weight god class

2. transform the light-weight god class into a facade that delegates behaviorto its acquaintances

3. direct clients to the refactored data containers and the new objects

4. remove the facade

Each of these steps consists themselves of a number of operations. In theremainder of this section, we will elaborate on their peculiarities.



6.2. PATTERN DESCRIPTION 65

Transform the god class into a light-weight god class. A light-weight god class is one in which the attributes are extracted to data containers, whichare themselves responsible for the initialization and hiding of the data. Afterthis transformation, most of the attributes of the god class will be replaced byinstances of the extracted data containers.

Transform the light-weight god class into a facade that delegates be-havior to its acquaintances. This step is performed by identifying those(portions of) god class methods which interact intensively with a data con-tainer. As these methods provide a service on top of the data container, movingthem to the associated data container encapsulates the associated business logic.Doing so, the data containers are promoted to collaborators of equal value.

In order to shield clients from these changes, the move operation shouldleave behind a delegator method. After iteratively moving behavior to the datacontainers, the god class will consist of delegator methods and an (or possiblymultiple) initialization method. At this stage, we have two possibilities: (i) theinitialization represents the preparation of a semantical relationship between theencapsulated god class data; (ii) there is no real semantical relationship betweenthe encapsulated objects. An example of a semantical relationship can be foundin case the data container can only exist in the context of the god class.

In case there is no real semantical relationship, the data containers are usefulin isolation, and therefore, the initialization method can most likely be dividedto form the future constructor methods of the former data containers.

In contrast, when there is a semantical relationship being prepared in theinitialization method, than the god class can be regarded as a Builder [Gammaet al., 1994] (or, since it contains the data, an Object Mother [Schuh and Punk,2001]).

Direct clients to the refactored data containers and the new objects.Clients might shortcut the indirection of using the facade. However, while each

delegator method does not implement any responsibilities itself, it does deter-mine the runtime instance onto which the service will be requested. In otherwords, the delegator method indirectly changes the state of an attribute of thegod class. A precondition to bypassing the delegator method is that there is onlya single client manipulating the god class attribute via the delegator method.Multiple clients would cause consecutive state changes of the same attribute of the god class. In that case, the attribute cannot be moved to a client.

This description stresses the iterative and incremental nature of splitting a




god class. One of the benefits of this chain of transformations is that improve-ments with regard to program comprehension are not postponed until the laststep. E.g. the extraction of data containers immediately introduces abstrac-tions. Moreover, one might assume that the consequential identification of themethods interacting with these abstractions makes it easier to recognize theresponsibilities associated with these abstractions. In other words, this patternshould not be regarded as a single fix, but rather as a roadmap.

6.3 Illustrative Scenario

Consider the problem domain in which the following procedure for filteringincoming mails into appropriate mailboxes applies:

1. Collect the mailheaders of all mails awaiting filtering.

2. Collect the filters to be applied.

3. Apply each filter on all mails awaiting filtering.

(a) Evaluate the headerfield-values of the current mail.

(b) Move the mail to the target mailbox in case of a match.

4. Move unfiltered mails to the inbox.

A common class decomposition for fulfilling the filtering procedure is:

Decomposition A – The software design consists of a single class. This godclass governs the flow of control and manages the internal representationof domain entities. This decomposition is illustrated in Figure 6.1.

The responsibilities of the god class can be incrementally redistributed ei-ther to collaborating classes – if present – or to new classes that are pulledout of the god class. To ensure behavioral equivalence of the resulting classdecompositions, the transformations applied are refactorings [Fowler, 1999].

Decomposition B – Two filter classes are extracted from the god class: onefor filtering according to the equality of a header field with a given string,and one according to the mere presence of a string in a header field. Thisextraction of two controller classes is done using the refactoring ReplaceMethod with Method Object on the two filtering methods from the originalgod class (step 3). This decomposition is illustrated in Figure 6.2.



6.3. ILLUSTRATIVE SCENARIO 67

IncomingMsgFilter

-fMailsMsgsHeaderParser : MessageHeaderParser

-fChangedMailboxNames : LinkedList

-fFilterComparationOperator : String

-sIncomingMsgsMailbox : String

-fTargetBoxDirectory : String

-fMailsToBeFiltered : Vector

-fHeaderFieldName : String

-fForbiddenString : String

-sFiltersFile : String

Figure 6.1: Decomposition A

Decomposition C – The vector in which the mail header field values arestored (step 1) is extracted and encapsulated in a mail header entity class.Using different terminology, this class would be categorized as an entity,model, or abstraction class. The transformation used is similar to theIntroduce Parameter Object refactoring. This decomposition is illustratedin Figure 6.3.

A benefit of factoring out controllers is that they deal with fewer issues. Abenefit of factoring out entities is that these provide a clear and encapsulatedrepresentation of a domain entity.

The refactoring scenario from decomposition A to C would be considered anadequate disentangling of the initial god class. Nonetheless, to anticipate futureneeds of reusability and flexibility, the extraction of controller and entity classesmight continue.

Decomposition D – The action which is to be applied by a filter (step 3b) isextracted in a filter action class. This delegation to a new controller class

requires the application of the Extract Method and Replace Method with Method Object refactorings. This decomposition is illustrated in Figure6.4.

Decomposition E – The representation of a mail header field as consisting of a key and value pair (step 3a) is extracted and encapsulated in a headerfield class. Once again, the extraction of this entity class is done using arefactoring similar to Introduce Parameter Object . This decomposition isillustrated in Figure 6.5.




IncomingMsgFilterController


-fChangedMailboxNames : LinkedList-fFilterComparationOperator : String


-fTargetBoxDirectory : String-fMailsToBeFiltered : Vector

-fHeaderFieldName : String-fForbiddenString : String


EqualityFilter

-fHeaderFieldName : String-fForbiddenString : String-fTargetMailbox : String

ContainedStringFilter


-fTargetMailbox : String

Figure 6.2: Decomposition B

The newly introduced controller and entity classes in respectively decom-

position D and E bear little responsibilities. Accordingly, their weight in theoverall class hierarchy is very small. The transformations to decompositionsD and E might be considered over-engineering. Yet, as over-engineering is notuncommon in practice (e.g., see [Fichman and Moses, 1999]), these refactoringsteps are quite realistic.

Because the god class decompositions were derived by applying behavior-preserving refactorings, they only differ w.r.t. their internal organization.

6.3.1 Research questions

The Split Up God Class pattern stimulates encapsulation, thereby providing

abstraction structures that are expected to support the construction of a mentalrepresentation. Therefore, we ask ourselves the following research questions:

1. Effectivity – Do some god class decompositions allow to achieve higherprogram comprehension accuracy than others?

2. Efficiency – Do some decompositions allow to achieve comprehension fasterthan others?











MailHeader

-fHeaderFieldsIndicationForCurrentMail : Vector

EqualityFilter

-fHeaderFieldName : String-fForbiddenString : String-fTargetMailbox : String



-fTargetMailbox : String

Figure 6.3: Decomposition C











MailHeader


EqualityFilter

-fFilterAction : MoveMailFilterAction


-fCurrentMailIndex : int


-fFilterAction : MoveMailFilterAction


-fCurrentMailIndex : int

MoveMailFilterAction

-fTargetMailbox : String-fIsApplied : boolean

1

1

1

1

Figure 6.4: Decomposition D




EqualityFilter

-fHeaderFieldFilterPair : HeaderFieldNameAndValuePair-fFilterAction : MoveMailFilterAction-fCurrentMailIndex : int


-fHeaderFieldFilterPair : HeaderFieldNameAndValuePair-fMailsMsgsHeaderParser : MessageHeaderParser






-fHeaderFieldFilterPair : HeaderFieldNameAndValuePair-fFilterAction : MoveMailFilterAction-fCurrentMailIndex : int

MailHeader


HeaderFieldNameAndValuePair

-fHeaderFieldName : String-fValue : String

MoveMailFilterAction

-fTargetMailbox : String-fIsApplied : boolean

1

1

1

1

1

1

1

1

1

1

Figure 6.5: Decomposition E



Chapter 7

Validating Split Up GodClass

This chapter is based on a previously published paper [Du Bois et al., 2006].In this chapter, we present the results of three controlled experiment replica-

tions with the aim to contribute to the validation of the Split Up God Class pat-

tern1. We evaluate whether the Split Up God Class pattern facilitates top-downcomprehension, which has been shown to be applied in case programmers needto understand a code fragment that is familiar, or when the problem domain towhich the code fragment contributes a solution is familiar [von Mayrhauser andVans, 1995].

7.1 Introduction

To evaluate the mental representation of programmers adhering to a top-downapproach for program comprehension, we test the criteria which Brooks pro-

posed for complete understanding. These criteria require information about:(i) knowledge domains consisting of objects, relations among objects, opera-tions which manipulate these properties and relationships between objects; and(ii) relationships between objects and operators in one domain and those in anearby domain [Brooks, 1978]. We argue that this knowledge can be testedusing the following two assignments:

1The experimental material used in this chapter is publicly available athttp://www.lore.ua.ac.be/Research/Artefacts/SE2006ReplicationPkg

73



74 CHAPTER 7. VALIDATING SPLIT UP GOD CLASS

Map variables/attributes to concepts described in the problem do-main – Variables represent the objects present at the knowledge domain de-fined by the source code. To test the availability of information about therelationship with objects present in the problem domain, we can ask a personto localize variables/attributes in the source code that represent a given conceptdescribed in the problem domain. E.g., in the context of a mail client, we canask a person to localize the attribute representing the To header-field of a mail.

Map method execution steps to actions described in the problem do-main – Methods represent the operators which manipulate the attributes of classes in the source code. As these methods correspond to (parts of) scenario’sin the problem domain, steps in the execution of a method correspond to ac-tions in the problem domain. Therefore, to test the availability of informationabout the relationship between operators in the source code and operators inthe problem domain, we can ask a person to localize method execution stepsthat represent a given action described in the problem domain. E.g., we canask a person to localize the method execution step representing the action of physically sending a mail to a mail-server.

Accordingly, these two tasks verify whether a person’s mental representationof a program contains information about the the relationship with the problem

knowledge domain.To initiate the construction of a mental model using a top-down compre-

hension approach, pre-generated hypotheses about the problem domain are re-quired. Therefore, before asking a person to map variables, attributes or methodexecution steps, one has to assure that the person is at least familiar with theproblem knowledge domain.

These two assignments allow to evaluate the result of a top-down compre-hension approach, and therefore, can be used to verify whether the Split UpGod Class pattern supports top-down comprehension. Accordingly, we evaluatethe performance of a person applying these two assignments using the following

attributes:

Task accuracy: A task is not required to be completed successfully in orderto be declared as finished by the person executing it. I.e., the personexecuting it might assume wrongfully that he has performed it successfully,or the time frame reserved for finishing the task might have passed.

Accordingly, when asked to map an attribute or method execution step toa given concept or action described in the problem domain, three possible



7.2. RESEARCH HYPOTHESES 75

outcomes exist: (i) the information item (attribute or method executionstep) is accurately localized; (ii) the wrong information item is localized;or (iii) no information item was localized. The first option indicates com-prehension of the attribute or method execution step, while the secondand third options do not. Accordingly, for such tasks, task accuracy is abinary attribute, which can be either accurate, or inaccurate.

Task duration: The time it takes a person to localize an information itemindicates the ease with which a (partial) mapping between the sourcecode and the problem domain is created. As this mapping is essential for

a complete understanding of the program, for such tasks, the task duration allows to estimate comprehensibility w.r.t. to a subset of the program andthe problem domain.

However, in comparing the durations of two persons performing a task, onehas to take into account task accuracy. E.g., in case one person accuratelyperformed a task, while another person did not, it is invalid to comparethe performance of these two persons merely using the task durations. Itis only valid to compare the task durations of tasks performed accurately.

Evidently, task duration and task accuracy are influenced by factors other

than merely the properties of the source code. Examples of such factors arethe skills and expertise (or even mental condition) of the person performing thetask, the tools provided to support the task, etc. Therefore, it is essential tocontrol the conditions in which task performance is evaluated in order to ensurethat merely those factors of interest can be the cause of differences w.r.t. taskaccuracy and duration.

7.2 Research Hypotheses

In our efforts to validate the Split Up God Class, we compare the comprehen-

sibility of students working on alternative decompositions of a god class in asoftware system from a familiar problem domain. To be specific, we expectthat the performance of students working on different god class decompositionsdiffer. Consequently, we state the following null hypotheses:

H0,accuracy – The ability to accurately map variables/attributes and methodexecution steps to respectively concepts and actions described in the prob-lem domain does not differ w.r.t. the god class decomposition.




H0,time – The time required to accurately map variables/attributes and methodexecution steps to respectively concepts and actions described in the prob-lem domain does not differ w.r.t. the god class decomposition.

It has been shown that the skills of a developer applying maintenance tasksinteracts with the effect that a design decomposition has on maintenance perfor-mance [Arisholm and Sjøberg, 2004]. Thus, the skills of a maintainer attemptingto understand a software system might influence the effect of a god class de-composition on the effort required to understand the class. As the Split UpGod Class pattern allows to manipulate the decomposition of a god class, we

ask ourselves whether the effect of the Split Up God Class pattern on programcomprehensibility is influenced by the experience of the maintainer attemptingto understand the system. In the population of master-level students, this ex-perience is mostly determined by the curriculum of the university at which thestudent is enrolled.

Accordingly, we incorporate the institution at which a student is enrolled asa factor which might interact with the effect of a god class decomposition onthe comprehensibility of part of a software system.

7.3 Experimental Set-Up

In this section, we specify the variables incorporated in the experimental design,characterize the participants and elaborate on the experimental procedure.

7.3.1 Experimental Design

Similar to the validation of the Refactor to Understand pattern, the experimen-tal design is a crossed factorial design with two factors, incorporating a pretestand a posttest. Table 7.1 illustrates the experimental variables manipulated orobserved in this experiment.

The independent variables subject to experimental control are:

IV1– Class Decomposition: This ordinal variable indicates the number of classes which were extracted from the god class to derive class decomposi-tions A–E, presented in the illustrative refactoring scenario in the previouschapter. Therefore, the possible values are {A,B,C,D,E}.

IV2 – Institution: The experiment was replicated with students enrolled indifferent institutions (see Table 7.2), providing a nominal variable. Pos-sible values are {MAS1,MAS2,MAS3}. This variable is incorporated as




curriculum differences are a potential cause of variation, and can therebyprovide an explanation for differences in individual performance.

Table 7.1: Experimental variables

Variable type Name Values Scale

Independent

Class decomposition {A,B,C,D,E} ordinal

InstitutionMAS1

nominalMAS2MAS3

DependentPMV [0,100]%

absolutePMS [0,100] %ET [0,3600] sec

Evidently, the institution variable could only be controlled by the participantselection procedure. To control the class decomposition variable, we assignedparticipants to a god class decomposition (A–E).

The dependent variables being observed are:

PMV – Percentage of accurately Mapped Variables: Measured as the per-centage of variables/attributes that are localized by a participant andmatch with the requested domain concepts. The total number of vari-ables/attributes to be localized is two for the pretest and eight for theposttest. This variable is used to indicate the ability of participants tomap variables/attributes to concepts described in the problem domain .

PMS – Percentage of accurately Mapped Steps: Measured as the per-centage of requested information items for which a correct step in exe-cution was found – even if the wrong attribute is printed. This variable isused to indicate the ability of participants to map steps in the execution

of methods to actions described in the problem domain .

ET – Execution Time: Measured as the time frame between the point atwhich the change request is read and the point at which the task is finished,in seconds.

Participants are randomly assigned to one of five groups (A to E). Eachgroup applies two change localization tasks. The first task is identically appliedby all groups, and provides pretest observations. The second task, however, is




applied for each group on a different class decomposition, and provides posttest observations, incorporating manipulation of the experimental factor class de-composition.

7.3.2 Experimental Participants

The same set-up was applied in five replications, employing a total of sixty-threemaster-level computer science students (see Table 7.2).

As the names of the institutions are of no value within the context of this

paper, we have encoded them.

Table 7.2: Replications of the experiment

Replication Institution Curriculum #Subjects1 MAS1 CS 92 MAS1 CS 53 MAS2 ICT 204 MAS3 CS 145 MAS3 CS 15

Total 63

1–2 In October 2004, fourteen third year mathematics and computer science(CS) students (four years master-level) participated in the context of acrash-course on the open source Integrated Development EnvironmentEclipse. This course is optional in the third year of the four years masterlevel (mathematics and) computer science curricula at the University of Antwerp, Belgium. An experimental session was organized for 9 computerscience and 5 mathematics and computer science students separately. Asthird year students, they are moderately experienced in object-oriented

software development in Oberon and C++. However, these students haveno experience with maintenance.

3 In November 2004, twenty last year students industrial engineering in ICT-electronics (four years master-level) participated in the context of a manda-tory course on distributed software in Java at the Karel de Grote Hogeschool,Belgium. These students have limited experience with object-orientedsoftware development in C++ and Java.




4–5 In March 2005, twenty-nine last year computer science students (four yearsmaster-level) participated in the context of a mandatory course on soft-ware evolution at the University of Mons-Hainaut, Belgium. As last yearstudents, they are experienced in object-oriented software development inScheme and Java. These students previously extended an existing sys-tem in a project assignment and therefore have minor experience with thetasks at hand.

The Karel de Grote Hogeschool is a university of professional education(hogeschool in Dutch), contrary to the universities of Antwerp and Mons-Hainaut

who provide research-oriented education. Before the Bachelor-Master reforma-tion in Europe, professional education led to the bachelor level while research-oriented education led to the master level.

There is a clear distinction between the curricula of MAS1 and MAS3 stu-dents (computer science) and the ICT-electronics curriculum of the MAS2 stu-dents. The latter are less focused on software engineering and mostly targethardware and network design as well as data communication.

7.3.3 Experimental Procedure

Each experimental replication incorporated participants of a single institution.At the beginning of each replication, participants were randomized across ex-perimental groups, resulting in the distribution illustrated in Table 7.3.

Table 7.3: Participant assignment

Class Decom-position

InstitutionTotal

MAS1 MAS2 MAS3

A 2 4 6 12B 3 4 5 12

C 4 4 6 14D 3 4 6 13E 2 4 6 12

Total 14 20 29 63

Assignment of participants across experimental groups. Each cell

represents a group of participants working on a particular god class

decomposition (A–E) and originating from a particular institution

(MAS1–MAS3).




After assigning participants to groups, an introduction to the experimentalprocedure was given. Participants were told that they were required to fulfillmaintenance assignments which would demonstrate the complexity of under-standing and modifying a software system written by someone else. Therefore,participants were unaware of the purpose of the experiment.

It was said that two assignments would be given, and the first assignmentwas then introduced in detail. Each participant received a sheet containing thefirst task, illustrated in Figure 7.1. The sheet for the second task is illustratedin Figure 7.2. For both tasks, the same sheet format was adhered to.

Each task required participants to output information at a particular mo-

ment in execution. Therefore, each task implicitly required participants to firstcomprehend the code fragment, and afterwards to introduce changes in orderto ensure the printing of information to output.

We posed no time limitations on the tasks. However, participants weremotivated themselves to finish quickly, and the sight of a participant finishingcontributed to this motivation, which is a natural effect in such experiments.However, if a participant wished to continue finishing the task, he was notrestricted to do so.

All replications were performed under identical conditions using identicalmaterial. Participants used the Eclipse IDE to perform both tasks, using the

integrated CVS functionality. As the participants of MAS3 were used to Frenchcourse material, we had the task sheets translated to French.




• Use the Eclipse-icon on the Desktop to launch Eclipse• Open the Java project named “E”. This project contains the implementation of

an email client.• Read the following Change Request, and afterwards execute it.

Change Request

Name

Scope Class org.gjt.fredde.communication.MailSender

Context description Mails that are to be sent to a mail-server are placed in a

mailbox where they wait to be submitted.The sendMails() method in class MailSender constitutes thetrigger for sending these mails. This method retrieves themails from the mailbox-file, and triggers the submission of smtp-commands for these mails.

Additionalinformation

An email-message consists of an email-header and an email-body. The email-header contains header-field pairs,consisting of a name and a value of a header-field. For example:

From: Jan Janssen <[email protected]>

To: [email protected]

Content-Type: text/html

Subject: Uitnodiging

Assignment Write the header-fields (name and value) of each mail tostandard output at the moment it is being sent. Use thefollowing output-format:

To: <email-adress of the addressee(s))>

Subject: <mail subject>

---

... (next output-block)

Before starting theassignment

Write your name in comment on the first line of the classMailSender, and commit the project to CVS. Write the currenttime below, using the system clock to the lower-right of your screen (double-click).

Timestamp of assignment start

h m s (example: 8h 05m 12s)

Timestamp of assignment end

h m s

Figure 7.1: Pretest task




• Use the Eclipse-icon on the Desktop to launch Eclipse.

• Use the Java project named “E”. This project consists of an implementation of an email client.

• Read the following Change Request, and afterwards execute it.

Change Request

Name

Scope Package org.gjt.fredde.filtering

Context description Mails which were retrieved from the mail-server are placed ina mailbox where they wait to be filtered. The filtermails()method in the class IncomingMsgFilterController

constituties the trigger for filtering these mails. This methodretrieves the mails from the mailbox-file, as well as theconfigured filters from the filter-file, and triggers theapplication of the filter on the mails.

Additionalinformation

An email-message consists of an email-header and an email-body. The email-header contains header-field pairs,consistent of a name and a value of a header-field. For example:

From: Jan Janssen <[email protected]>

To: [email protected]

Content-Type: text/html

Subject: Invitation

Assignment Write the header-fields (name and value) and the attributesof a mail filter to standard output at the moment a mail isbeing filtered. Use the following example output-format:

From=<from header-field value>

To=<to header-field value>

Subject=<subject header-field value>

Reply-To=<reply-to header-field value >

Filtered Header Field Name=<one of

{from,to,subject,reply}>

Filtering Method=<one of {equal,contains>

Filtering String=<string whose presence in the field

value triggers the filter>

Moved Mail To=<indicator of the mailbox where the mail

will be moved to after filtering, e.g. boxes/trash>

---... (next output-block)

Before starting theassignment

Write your name in comment on the first line of the classIncomingMsgFilterController, and commit the project toCVS. Write the current time below, using the systeem clockto the lower-right of your screen (double-click).

Timestamp of assignment start

h m s (example: 9h 40m 12s)

Timestamp of assignment end

h m s

Figure 7.2: Posttest task




7.3.4 Experimental Tasks

The change requests (illustrated in Figures 7.1 and 7.2) consist of the followingelements:

Scope – Delimits the code fragment in which changes are to be applied.

Context description – Introduces the problem domain, and provides a highlevel overview of the function of the main method. This context descrip-tion ensures the presence of pre-generated hypotheses, which starts anexpectation-based top-down comprehension process.

Additional information – Elaborates on objects present in the problem do-main. To be specific, the concept of an email message and its relation withemail header fields is discussed. This section ensures that the participanthas information about the knowledge domain at the level of the problemdomain. Consequently, the process of top-down comprehension is limitedto gathering information about the knowledge domain at the level of thesource code, and the mapping between these two knowledge domains.

Assignment – Describes what is required from the participant. The assign-

ment dictates the concepts and actions present in the problem domain forwhich the participant has to localize associated variables/attributes andmethod execution steps.

By asking the participant to write information to output, we implicitlyask participants to localize an attribute. By asking the participant towrite information at a particular action, we implicitly ask participants tolocalize a method execution step.

Administrative – Reminds participants to write their name in the sourcecode, and to indicate the time stamp before starting and after finishingthe task.

The first task (see Figure 7.1) formed the pretest, which is identical for allparticipants. This means that the source code on which the students apply thefirst change request is identical. Therefore, for the pretest, the class decompo-sition factor is held constant, and the only difference between groups is due tothe institution factor. This pretest is introduced to evaluate the equivalence of experimental groups, i.e., to verify that we do not systematically assign high-performant participants to some god class decompositions and low-performant




participants to others. Performance equivalence between groups at the pretestare confirmed in data analysis.

The second task (see Figure 7.2) formed the posttest, which differed betweenexperimental groups. Participants assigned to different god class decompositions(A–E) therefore had to comprehend and change different class decompositions.However, these decompositions were behaviorally equivalent, as described in theprevious chapter.

The software system used in the experiment is an open source Java mailclient (Yamm v0.9.1), which consists of 13KLOC over 66 classes. This softwaresystem was chosen for the following two reasons. First, the knowledge domain

of the application domain of a mail client is very well-known by all participants.This familiarity is required to stimulate a top-down comprehension process. Asa second argument, the system is a typical example of continual extension, whichleads naturally to the fostering of god classes. The god class responsible for thefiltering procedure is therefore a natural and realistic god class.

The source code fragments to be understood and changed for both tasks arecharacterized in Table 7.4. The code fragments are of similar size, expressedin non-comment lines of code. Both code fragments originate from differentpackages of the same software system, which is an open source implementationof a mail client in Java.

Table 7.4: Properties of the code fragments used

PropertyCode fragment

Pretest Posttest

Non-comment Lines of Code 240 274Number of Attributes 16 8Number of Methods 13 11

Properties of the source code fragments for each of the two

experimental tasks.

In order to prepare the posttest, we moved the god class responsible for thefiltering procedure to a separate package, thereby forming decomposition A. Bykeeping all extracted classes in this package, we had a means to clearly boundthe part of source code of interest for the assignments.

Each task (pretest or posttest) requires a number of information items tobe printed at a certain moment in execution. For the pretest, two informationitems had to be printed, and for the posttest assignment, 8 items were requestedto be printed.




We observed all participants applying the following steps:

1. Read the change request.

2. Navigate to the class or package specified as the scope of the change re-quest. Navigate further to the method indicated in the change requestas the trigger for the scenario of interest. For the pretest, this was themethod MailSender.sendMails, and for the posttest, this was methodIncomingMsgFilterController.filterMails .

3. Browse through the source code delimited by the scope indicated in thechange request, in search for code fragments associated with the high leveloverview description of the function of the main method presented in thechange request.

4. Simulate the execution of the main method by following the call graph.

5. Recognize variables/attributes representing one of the concepts requestedin the change request, and recognize points in the execution of a methodcorresponding to the action described in the change request.

Through the delegation of control to different methods, potentially in

different classes, there are multiple locations in the source code that cor-respond to a particular moment in the execution of an algorithm. Ac-cordingly, there are potentially multiple execution steps which correspondwith a given action in the problem domain.

E.g., the line of code immediately before a method invocation, and thefirst line of code in the invoked method correspond to the same action.However, the required information items might not be visible in all of these locations. E.g. in case the information items are private attributesfor which there are no accessor methods, these are only accessible in themethods of the class defining these attributes, and not in their clients.

Therefore, in these cases, only some of the multiple execution steps cor-responding to a given action can be used to print particular requestedinformation items.

6. Once an adequate method execution step has been found, a print-statementis written to standard output, in which the variable or attribute is printed.In case no adequate method execution step was found, participants markedthe variable or attribute in question with comments or printed it at amethod execution step which they thought was most appropriate.




These steps were applied for each of the information items requested, ulti-mately leading to the completion of the task.

The posttest was started only once all participants finished the pretest.

7.4 Data Analysis

In this section, we report the analysis of the data used to answer our two researchquestions. First, we describe the analysis procedure. Secondly, we characterizethe collected data. Finally, we report on the analyses used to test the hypothe-

ses.

7.4.1 Analysis Procedure

The main sources of information collected during the experiment were the mod-ified software systems and the time stamps.

For both the pretest and posttest, the author evaluated the participants’solutions himself according to the following rules.

Task accuracy – The two dependent variables related to task accuracy arethe percentage of mapped variables/attributes (PMV) and the percentage

of mapped method execution steps (PMS):

PMV – Participants indicated that they had localized a variable or at-tribute by either printing it to standard output, or by writing a com-ment indicating the concept in the problem domain with which thevariable/attribute corresponded.

For each information item requested (respectively 2 and 8 for thepretest and the posttest), the evaluation procedure applied by theauthor categorized the solution as follows. In case the localized vari-able/attribute corresponds to the requested concept, a score of one isadded to the total score. In case the localized variable/attribute does

not correspond, or in case there is no variable/attribute localized forthe requested concept, nothing is added to the total score.

After evaluating all information items requested, to calculate the per-centage of accurately mapped variables/attributes (PMV value), thetotal score is divided by the number of information items requested.E.g., if a participant has a score of 1 on the pretest and 5 on theposttest, the PMV value of the pretest and posttest are respectively12 = 0.5 and 5

8 = 0.625.




PMS – Participants indicated that they had localized a method execu-tion step by writing a print-statement at that line of code. This print-statement followed the output-format indicated in the task sheet.In this output-format, a variable/attribute was filled in in case theparticipant had localized the corresponding variable or attribute, orotherwise a string indicating (s)he was unable to localize the variable.

For each task, there is only a single action to be mapped againstmethod execution steps. However, the printing of requested infor-mation items needs to be distributed across different execution stepscorresponding to the same requested action, because not all vari-ables/attributes are visible at all scopes, e.g., in the cases of privateattributes, or variables defined in different methods.

For each information item requested, the author categorized the so-lution according to the following principle. In case the method ex-ecution step, indicated to be the location at which the requestedinformation item should be printed, corresponds to the requested ac-tion, a score of one is added to the total score. In case the localizedmethod execution step does not correspond to the requested action,or no such method execution step is indicated for the informationitem, nothing is added to the total score.

Once again, after evaluating all information items requested, the to-tal score was divided by the number of information items requestedto calculate the percentage of accurately mapped method executionsteps (PMS value).

Task duration – The only dependent variable related to task duration is theexecution time (ET), calculated as the number of seconds between thestart of the task and the finishing of the task. The execution time was

calculated from the time stamps which were hand-written by the partici-pants on the task sheets.

7.4.2 Descriptive statistics

Table 7.5 describes the mean and standard deviation of our observations in boththe pretest and the posttest.




Table 7.5: Descriptive statistics (N=63)

Pretest PosttestMeasure Mean StdDev. Mean StdDev.

PMV 96.0% 16.3% 86.2% 21.4%PMS 93.6% 19.0% 41.2% 43.4%ET 1284 535 2471 799

We discuss the observations for the pre- and posttest separately:

Pretest – The data indicates that most of the participants had no problemslocalizing variables/attributes and method execution steps for the pretest(mean PMV=96% and mean PMS=93.6%). The average execution timewas about 20 minutes.

Posttest – Somewhat lower accuracy and longer execution times were expectedfrom the posttest. Most of the participants were able to localize a largepart of the attributes (mean PMV=86.2%), yet unable to localize the cor-rect method execution steps (mean PMS=41.2%). The average executiontime was about twice the duration of the pretest, at about 40 minutes.

When comparing the posttest values with the pretest values, we observelower PMV, PMS and ET posttest values, as expected. Moreover, these differ-ences are quite large, and in fact all significant at the 99% level. This meansthat the probability of such an extreme difference between the pretest and theposttest without any actual difference between them is less then 1%.

These differences can be explained by the difference in task difficulty . Whileit is non-trivial to define the difficulty of a task, we can clearly see that theposttest required more items to be localized than the pretest. More specific,the posttest required participants to localize information about the mailheader,the filter and the action to be applied by the filter, which in total requires 8

attributes to be localized. In contrast, the pretest only requires 2 attributes tobe localized, both related to a mailheader.

When we zoom in on the posttest observation w.r.t. PMS, we observe thatthe standard deviation (43.4%) is larger than the actual mean (41.2%). Thisfinding could only be observed in the possttest observations of PMS, and per-sists even within groups of participants from the same institution working onthe same god class decomposition. Such variation decreases the sensitivity of tests for differences between different experimental groups. Accordingly, our




statistical tests for null-hypotheses H0,PMS and H0,PMS−ET will suffer from alack of power. We will take this lack of power into account in the interpreta-tion of results. Nonetheless, for completeness, we do provide the results of thestatistical tests on the PMS observations.

7.4.3 Statistical tests

Table 7.6 illustrates the statistical tests which will be used for testing the nullhypotheses. These tests are Analysis of Variance tests that test whether twoor more samples originate from the same population. The principle applied

in this test is the following. In case differences between samples are largerthan differences among samples, it is probable that these samples come fromdifferent populations. To verify which type of Analysis of Variance to apply,we have to investigate the distribution of the observations. Data exhibiting anormal distribution can be tested using the parametric Analysis of Variance,while otherwise non-parametric tests are required.

Contrary to the pre- and posttest observations of ET, the PMV and PMSobservations deviate from normality. Both pretest and posttest observations of PMV are skewed significantly to the high end of the scale, and exhibit a clearpeak. The pretest observations of PMS demonstrated similar deviations from

normality. Its associated posttest observations exhibit a flat distribution.Accordingly, the ET observations can be tested using the parametric one-wayAnalysis of Variance (ANOVA). In contrast, PMV and PMS observations willbe tested using the non-parametric variant, being the Kruskal-Wallis one-wayAnalysis of Variance [Coolican, 2004]. This test ranks the observations beforecomparing them.

Table 7.6: Statistical tests

Null hypotheses Req. DV1 Statistical test

H0,PMV PMVKruskal-Wallis one-way Analysis of Variance

H0,PMS PMSH0,PMV −ET ET one-way Analysis of Variance (ANOVA)H0,PMS−ET

This table describes the statistical tests used for testing the null hypotheses.1 Required Dependent Variable signifies the dependent variable to be compared between groups. For

H0,PMV −ET and H0,PMS−ET , only those observations with resp. PMV=100% or PMS=100%

are included.




7.4.4 H0,accuracy – Differences in task accuracy

Table 7.7 illustrates the significance of group differences at the pre- and posttest.Performance differences between participants from different institutions are plau-sible (p=.144), as can be expected. In contrast, the results w.r.t. the pretestconfirm that there were no significant systematic differences between groupsworking on different god class decompositions (A–E). This means that the ran-domization of participants ensured the equivalence of our experimental groups.

Table 7.7: Test of group differences w.r.t. accuracy

FactorPretest Posttest

PMV PMS PMV PMS

Decomposition .445 .898 .089* .719Institution .144 .297 .353 .271Interaction .213 .119 .078* .314

Represents the significance of the Kruskal-Wallis Analysis

of Variance, reporting on the main effect of the Decompo-

sition and Institution factors, and their interaction.

The question we address in this section is: Do some decompositions allow toachieve higher comprehension accuracy than others? In the discussion of thisquestion, we will differentiate between the ability to map variables/attributesand to map steps in the execution of a method.

Ability to map variables/attributes to concepts described in the prob-lem domain (PMV) – There were significant differences between the groupsworking on different god class decompositions (p=.089). This effect of the de-composition factor interacts significantly with the effect of the institution factor(p=.078), indicating that participants from some institutions had more difficul-ties in mapping attributes than participants from other institutions.

Figure 7.3 illustrates the mean value of PMV posttest observations per com-bination of the decomposition and institution factors. The line referred to inthe legend as Overall illustrates the main effect of the decomposition factor.The results of the institutions differ with regard to the god class decompositionat which the ability of participants to map attributes was highest, as indicatedby the different trends across different institutions. The results of the replica-tions with computer science students (MAS1 and MAS3) demonstrate absolutedifferences between class decompositions of more than 30 PMV. This means




0

10

20

30

40

50

60

70

80

90

100

A B C D E

Class Decomposition

M e a n P M V f

o r p o s t t e s t o b s e r v a t i o n s

MAS3 MAS2 MAS1 Overall

The Y-axis represents the mean percentage of localized attributes (PMV value) across thedifferent class decompositions as observed in the posttest.

Figure 7.3: Posttest PMV observations

that, for some decompositions, participants were able to localize an additionalone third of the attributes in relation to other decompositions. Observed PMVdifferences between ICT-electronics students (MAS2) working on different classdecompositions were smaller, differing at most 15 PMV.

Ability to map method execution steps to actions described in theproblem domain (PMS) – Before discussing the results, we remark thatthe descriptive statistics previously indicated that statistical tests w.r.t. theability to localize method execution steps (PMS) would suffer from lack of power.This means that, even if there would actually be differences between the groupsworking on different god class decompositions, there is merely a small probabilitythat our test will be able to confirm this difference. We indeed do not observesignificant differences.




0

10

20

30

40

50

60

70

80

90

100

A B C D E

Class Decomposition

M e a n P M S f

o r p o s t t e s t o b s e r v a t i o n s


The Y-axis represents the mean percentage of localized method execution steps (PMS value)across the different class decompositions as observed in the posttest.

Figure 7.4: Posttest PMS observations

Figure 7.4 presents the mean posttest PMS observations across god classdecompositions, specified for each institution and overall. While groups weregenerally unable to correctly perform the assignment, for each institution, weobserve a single decomposition for which the group of participants was able toachieve an accuracy higher than 60%. For the participants of MAS1, MAS2

and MAS3, these were respectively decompositions D, E and B. However, noconsistent trends can be observed. Once again, we attribute this to the largeperformance differences within groups, making it difficult to evaluate differencesbetween groups.

Summarizing, these observations allow us to reject H0,PMV . In contrast, wemust accept H0,PMS.

Alternatively, one can also describe group differences w.r.t. accuracy byevaluating the ratio of participants able to map all attributes (PMV=100%)




or steps in the execution of a method (PMS=100%). Accordingly, this ratio of participants is illustrated in respectively Figures 7.5 and 7.6.

0

10

20

30

40

50

60

70

80

90

100

A B C D E

Class Decomposition

F r e q u e n c y o f o b s e r v a t i o n s

w i t h P M V = 1 0 0 %


Figure 7.5: Frequency of observations with PMV=100%

The god class decompositions for which most participants were able to mapall attributes (see Figure 7.5) differs between institutions. For the computer

science students (MAS1 and MAS3), the decomposition for which the leastnumber of participants was able to localize all attributes was the original godclass decomposition A. In contrast, decomposition A was the decompositionfor which most MAS2 participants (the ICT students) were able to localize allattributes.

Since participants were generally unable to localize method execution steps,there are few participants who localized all method execution steps, as illus-trated in Figure 7.6.




0

10

20

30

40

50

60

70

80

90

100

A B C D E

Class Decomposition

F r e q u e n c y o f o b s e r v a t i o n s w i t h P M S = 1 0 0 %


Figure 7.6: Frequency of observations with PMS=100%

7.4.5 H0,time – Differences in task duration

The question we address in this section is Do some decompositions allow toachieve comprehension faster than others? To discuss this question, two ANOVAmodels were composed with factors decomposition, institution and their interac-tion: one for the observations of participants who mapped all attributes (α=.10,R2=.463, Adj. R2=.136) and one for those who mapped all method execution

steps (α=.10, R2=.634, Adj. R2=.085). Table 7.8 provides the significance of the ANOVA test statistic.

The results in Table 7.8 are visualized in Figure 7.7. This figure confirmsthat the mean execution time of different institutions follows the same trendacross decompositions, rejecting an interaction effect between the decompositionand institution factors. Differences in the time it took participants to map allattributes reach up to 16 minutes between decompositions D and E, comparedto an overall mean execution time of 37 minutes. This means that it took




participants in the group working on god class decomposition E 1.5 times longerto map all attributes compared to the group working on god class decompositionD. These differences, resulting from the main effect of the decomposition factor,are almost significant (p=.106).

Table 7.8: Test of group differences w.r.t. time

FactorPMV-ET1 PMS-ET2

Sign. Power Sign. Power

Decomposition .106 .683 .542 .265

Institution .265 .396 .235 .395Interaction .893 .260 .967 .114

Represents the significance of the Analysis of Variance, re-

porting on the main effect of the Decomposition and Insti-

tution factors, and their interaction.1 PMV-ET signifies the execution time of the observations

of participants that managed to localize all attributes

(PMV=100%).2 Analogue, PMS-ET signifies the execution time of those ob-

servations of participants managed to localize all method

execution steps (PMS=100%).

Few participants were able to map all the method execution steps, explainingthe lack of data points in Figure 7.8. Therefore, the power of our tests for groupdifferences is very low, as can be observed in Table 7.8. Accordingly, we areunable to discover group differences w.r.t. the time required to map all methodexecution steps.

Summarizing, we must accept H0,PMV −ET and H0,PMS−ET .

Table 7.9: Rejection of H0,accuracy and H0,time

H0,accuracy H0,time

H0,PMV H0,PMS H0,PMV −ET H0,PMS−ET

R AR

Represents the rejection of the null hypotheses. R stands

for Rejected (p < .10), and AR stands for Almost Rejected

(.10 < p < .12).

Table 7.9 summarizes the confirmation or refutation of the null hypotheses.




0

600

1200

1800

2400

3000

3600

A B C D E

Class Decomposition

M e a n E T i n s e c

f o r r e s u l t s w i t h P M V = 1 0 0 %


Figure 7.7: Mean ET of observations with PMV=100%

H0,PMV −ET , discussing group differences w.r.t. task durations for those partic-ipants who were able to accurately map all variables/attributes, was very closeto being significant (p=.106). Therefore, our data indicates considerable groupdifferences both w.r.t. task accuracy and w.r.t. task duration.


After analyzing the collected data we are able to reflect upon the two researchquestions.

Do some decompositions allow to achieve higher comprehension ac-curacy than others? When we assess comprehension accuracy by asking tomap attributes and method execution steps to respectively concepts and actiondescribed in the problem domain, our data indeed confirms the presence of sig-



7.5. INTERPRETATION OF RESULTS 97

0

600

1200

1800

2400

3000

3600

A B C D E

Class Decomposition

M e a n E T i n s e c

f o r r e s u l t s w i t h P M V = 1 0 0 %


Figure 7.8: Mean ET of observations with PMS=100%

nificant differences. While our data does not allow the conclusive interpretationof differences w.r.t. the ability to map method execution steps, we have observedsignificant higher comprehension accuracy with regard to the relation betweenvariables and attributes localized in the source code and concepts described inthe problem domain.

However, our data does not suggest an objective notion of “optimal com-

prehensibility”. On the contrary, while students with a computer science back-ground had more difficulties comprehending the original god class decomposi-tion A, ICT-electronics students experienced less difficulties. It appears thatdifferences in comprehensibility of the god class decompositions as perceivedby the computer science students were larger than as evaluated by the ICT-electronics students. We interpret this finding as a confirmation that advancedobject-oriented software engineering training can induce a preference towardsparticular styles of class decomposition.




Do some decompositions allow to achieve comprehension faster thanothers? We did observe differences between the god class decompositions con-cerning the time it took participants to localize all attributes. The statisticalsignificance of these differences approximated the preset significance criterion(p=.106). Curiously, while the class decomposition for which students demon-strated optimal comprehensibility differed between institutions (interaction ef-fect), such an interaction could not be observed w.r.t. the time it took to localizeall attributes. When we would regard those students being able to localize allattributes as performant students, this finding could suggest that there are fewsystematical differences w.r.t. class decomposition preference between the se-

lection of performant students across different institutions.


There are severe limitations to the extent at which our results can be attributedto the specified cause, and the extent in which these results can be generalized.For clarity, we specify the main threats to validity.

7.6.1 Internal Validity

Internal validity is the degree to which the experimental setup allows to accu-rately attribute an observation to a specific cause rather than alternative causes.The threats we have identified are the following.

• Maturation might have affected participant performance due to the ap-plication of a pretest. However, randomized distribution of participantsacross groups should ensure that this effect does not lead to systematicgroup differences.

• The risk of an instrumentation effect was minimized through the use of adecidedly objective categorization of the participant’s result using a clear

evaluation procedure.

7.6.2 External Validity

External validity is the degree to which research results can be generalizedoutside the experimental setting or population under study.

• Characteristics of the problem domain at hand and the associated exper-imental tasks are that the concepts used were very simple, and familiar



7.7. CONCLUSION 99

to all participants. Therefore, it is unclear whether systematic differencesw.r.t. comprehensibility arise when the problem domain is more complexin terms of the number of entities, relationships, and their properties.

• The experiment reported in this work was performed in a laboratory set-ting with computer science students. Consistency of the observed effectover different institutions suggest that our findings can be generalizedto the population of computer science students in general. However, acommon characteristic of this population is their perspective on optimaldecompositions, as most of the books providing examples are considered

standard reading material. Therefore, it is unclear whether the observedeffect would reoccur in case professional software maintainers would beused, as their experience with alternative decompositions might have stim-ulated a comprehension process that is more robust to variability in classdecompositions.

7.7 Conclusion

This experiment has been set up to verify whether god class decompositioncan facilitate comprehension. As one of the indicators of comprehensibility,

the ability to map attributes in the class hierarchy with domain concepts wassignificantly affected by the decomposition and its interaction with the institution from which the participant was enrolled . Moreover, this increased accuracy wasnot compensated by longer execution times of the comprehension task.

Our findings lead to two conclusions:

1. Improving comprehensibility is within the grasp of a single programmeror maintainer preparing for future change requests, as demonstrated usingour illustrative refactoring scenario. This approach is in contrast with themore traditional perspective on the need for massive reengineering efforts

for attaining improvements in external quality characteristics. Small scalerefactoring during development can therefore be regarded as a comple-mentary strategy to a separate preventive maintenance phase, differingboth in required investments and resulting returns.

2. We are reluctant to accept the concept of an optimal class decomposition with respect to comprehensibility, since one of the factors which interactswith the class decomposition is the particular education of the subjectperforming the comprehension task. This observation has been previously




demonstrated by [Arisholm and Sjøberg, 2004], and suggests that guide-lines for the reorganization of software systems should take into accountthe particular skills and expectations of the people maintaining the system.To be more precise, it is important to either adjust the organization of thesoftware system to the methods of organization preferred by the peoplemaintaining it, or to make these people accustomed to these methods of organization, e.g., by training.

This work does not provide guidelines on how to improve comprehensibilityusing refactorings. However, our conclusions can motivate software engineer-

ing researchers, practitioners and tool developers to study and support ways inwhich comprehensibility improvements can be achieved using controlled refac-torings.



Chapter 8

Summary

In this chapter, we summarize our findings and lessons learned with regard tothe investigation of program comprehension improvements by refactoring.

8.1 Findings

Program comprehension models typically distinguish between a bottom-up anda top-down approach. We have evaluated the support of two patterns usingrefactorings w.r.t. both of these program comprehension models.

Bottom-up comprehension: The physical application of two refactorings,Rename Variable/Method and Extract Method, has been shown to stimu-late bottom-up comprehension. This application of refactoring is known asthe Refactor to Understand pattern [Demeyer et al., 2002]. These refac-torings are targeted towards conveying the roles of variables, attributesandconditional branches, the intentions of methods and the purposes of classes [Demeyer et al., 2002].

We observed that essential abstractions, present in the mental model rep-resentations typical for bottom-up comprehension, are more accurate forstudents applying the Refactor to Understand pattern than these for stu-dents applying the traditional reading technique. These findings indicatethat the Refactor to Understand pattern stimulates the construction of knowledge required for a complete understanding. These requirements in-volve knowledge on both the text structure and the goals in the problemdomain.

101



102 CHAPTER 8. SUMMARY

Accordingly, our findings indicate that the Refactor to Understand patterncan support bottom-up comprehension.

Top-down comprehension: Alternative decompositions of a god class havebeen shown to stimulate top-down comprehension. This refactoring usedfor decomposing a god class is known as the Split Up God Class pattern[Demeyer et al., 2002], and is applied by subsequently applying refactor-ings which stimulate encapsulation, e.g., Extract Class, Extract Method,Replace Method with Method Object and Introduce Parameter Object.

We observed that accurate knowledge on relations between the knowledge

domain of the source code and the problem domain differed significantlybetween groups of students working on different god class decompositions.These knowledge domains consist of entities, their attributes, operationsthat manipulate these attributes, and relationships between these entities.The ability to relate these knowledge domains is essential for a completeunderstanding of the program [Brooks, 1978].

We observed that, for some god class decompositions, students were able toaccurately map more attributes to concepts described in the source code.Moreover, we have found that the ability of students to comprehend agod class decomposition was significantly affected by the institution from

which the student was enrolled. This finding confirms earlier work by [Ar-isholm and Sjøberg, 2004], and indicates that software engineering trainingcan induce a preference towards particular styles of class decomposition.

Accordingly, our findings indicate that the Split Up God Class patterncan support top-down comprehension.

8.2 Lessons Learned

In this section, we discuss three subjects which we regard as particularly relevant

in continuations of this line of research.

Assessing program comprehension – We are unaware of any standardswith regard to assessing program comprehension. This lack has been previ-ously indicated by [Rajlich and Cowan, 1997]. Accordingly, to ensure thatfindings between research works can be related to each other, we reused previ-ous ways in which comprehension was tested (e.g., by reusing the way in whichPennington evaluated bottom-up comprehension [Corritore and Wiedenbeck,



8.2. LESSONS LEARNED 103

1991,Bergantz and Hassell, 1991,Ramalingam and Wiedenbeck, 1997,Sajaniemiand Navarro-Prieto, 2005]), or we attempted to follow the suggestions of authorsdiscussing essential characteristics of complete understanding (e.g., as discussedby [Brooks, 1978]). In the future, we would like to engage in discussions in howstandards for assessing program comprehension might be composed.

Estimating task difficulty – In the validation of both the Refactor to Un-derstand and the Split Up God Class patterns, we have found that it is non-trivial to estimate the difficulty or complexity of a task assigned to experimental

participants. When using such tasks to assess program comprehension, the ac-curacy of the estimation of task difficulty affects the sensitivity w.r.t. programcomprehension differences. E.g., if task performance is measured on an integerscale from 0 to 10, and in case the experimental task is so difficult that it isvery unlikely for participants to score higher than 5, then the experimental testitself will only collect data points that score between 0 and 5. Accordingly, thesensitivity of the experimental test is reduced by half.

We are unaware of any systematic means of estimating the difficulty of theexperimental tasks applied in the experiments discussed in this part of the thesis,other than by performing a rigorous pilot study. In a pilot study, the experi-mental set-up is tried out on a set of participants with a profile similar to the

population of interest. The purpose of a pilot study is to assess the adequacyof the experimental test. I.e., instructions provided to the participants mightbe unclear and suggested tools might be perceived as non-user-friendly. A pilotstudy can be used to estimate the task difficulty, e.g., by evaluating the averagetime required to solve the task, and the average accuracy with which the taskis solved.

In our experiments, a rigorous pilot study was not performed. In case arigorous pilot study had been performed, we are confident that the followingissues would have been prevented. First, in the validation of the Refactor toUnderstand experiment, systematic data loss w.r.t. abstractions data flow and

state would have been prevented. Second, in the validation of the Split Up GodClass pattern, the pilot study would have indicated that the posttest task w.r.t.the localization of method execution steps was too difficult. In both cases, thiswould have prevented the presence of data points which are unusable for furtherprocessing.

Students as experimental subjects – In both validations, we used studentsin our controlled experiments. While this involves limitations to the extent in




which the results of our study can be generalized, we have experienced benefitsof this choice. I.e., since we either had control over the curricilum of studentsourselves, or had detailed insight in the contents of this curriculum, we couldensure that the participants possessed an adequate skill set. Controlling thisskill set was essential in the validation of the Refactor to Understand pattern.



Part II

Coupling and Cohesion

Improvements

105



Chapter 9

Quality-Driven Refactoring

9.1 Introduction

Quality driven refactoring is the process of optimizing quality attributes whilepreserving behavior. This part of the thesis envisions a state of the art in whicha refactoring tool provides a maintainer with suggestions on which refactoringsto apply where to improve specified quality attributes. Such a process is anapplication of an optimization problem, i.e., an exploration of the design spacein search of a solution which is optimal with regard to a stated fitness function.This fitness function evaluates the software solution in terms of desired qualityattributes.

In general, there are two approaches towards quality driven refactoring.First, one can apply the brute force method, in which one does not know before-hand how the application of a refactoring will affect the fitness function. Thisapproach consists of trying out a refactoring, and rolling back in case this pathis undesirable. Second, one can employ a-priori knowledge to be able to look

ahead and estimate the outcome of following a particular path of refactoringsteps. A-priori knowledge can be defined as the prediction of the outcome of aparticular event, given a description of both the event itself and the context inwhich the event takes place.

The brute force method (i.e., as applied by [Seng et al., 2005]) can resultin a description of the effect of a refactoring or sequence of refactorings ap-plied in a particular context. However, this approach does not allow to predictwhether similar effects can be observed in a different context, as the relationship

107



108 CHAPTER 9. QUALITY-DRIVEN REFACTORING

between the effect of the refactoring and the context in which it is applied isundocumented. Such documentation is what the a-priori knowledge represents.Therefore, this part of the thesis elaborates on an approach to quality drivenrefactoring research based on a-priori knowledge rather than a brute force ap-proach.

We define a-priori refactoring knowledge as a formalization of the outcomeof a particular refactoring in function of the context in which it is applied.

Formalization of a refactoring – A refactoring is typically formalized by

specifying a pre- and postcondition [Opdyke, 1992, Roberts, 1999, Tichelaar,2001, O Cinneide, 2001]. The postcondition specifies the guarantees that willbe fulfilled in case the requirements specified in the precondition have beenmet. This means that the outcome of the refactoring is undefined in case therefactoring is applied in a context in which the precondition is not met. To infor-mally illustrate the specification of a refactoring, we consider the specification of the Move Method refactoring. Among others, the Move Method postconditionguarantees that the method to be moved will be contained in the target classafter applying the refactoring, when the precondition is met, requiring that themethod to be moved is a non-overriding, non-overridden method implementedby the source class, for which no similarly signatured method exists in the target

class hierarchy.

Formalization of the context in which a refactoring is applied – Thecontext in which a refactoring is applied is a model, which corresponds to astructure described in a meta-model. A meta-model specifies the entities andrelationships which can be described in a model. Therefore, the context in whicha refactoring is applied can be formalized using a meta-model and operationson the entities and relationships which the meta-model describes. Examplesof these operations are the cardinality of the set of instances of an entity or arelationship (e.g., the number of classes), the selection of instances satisfying

particular properties (e.g., the set of classes which have no attributes) and thestatement of the existence of an instance (e.g., there exists a class c satisfyingparticular properties).

The pre- and postcondition of a refactoring are expressed in terms of theformalization of the context in which it is applied. I.e., among others, the MoveMethod precondition requires that the method to be moved does not referencenon-public sibling attributes. This condition can be formalized in terms of theexistence of a class in which the method to be moved is contained, the existence



9.1. INTRODUCTION 109

of a non-public attribute contained in this class, and the existence of a referencerelationship between the method to be moved and this non-public attribute.

Outcome of a refactoring – The outcome of a refactoring can be describedas a translation of the postcondition of a refactoring in terms of given functionsof the context in which it is applied. E.g., the outcome of the Move Methodrefactoring in terms of the size of the source class in numbers of methods can bedescribed by translating the expression “the source class will no longer containthe method to be moved after refactoring” to “the number of methods of the

source class will be decreased with one after applying Move Method”. In thiscase, part of the a-priori Move Method knowledge w.r.t. the size of the sourceclass is that it will reduce the number of methods of the source class with one.

Applications of a-priori refactoring knowledge in a maintenance con-text – Current refactoring tools provide support in the application of thetransformation, thereby guaranteeing the postcondition in case the preconditionis met. However, it is currently unclear which refactoring steps a maintainershould apply in order to improve a (set of) quality attribute(s). This meansthat any attempt to quality driven refactoring is dependent upon the skills of

the maintainer suggesting the refactoring.This work attempts to reduce the effort required by the maintainer to the

specification of quality attributes in need of optimization. I.e., it should besufficient for a maintainer to specify that he would like to optimize coupling andcohesion while keeping complexity within a reasonable margin. An advancedrefactoring tool could then devise a sequence of refactorings, which, together,result in an alternative composition of the given software system that satisfiesthe stated optimization goals.

While the above application scenario suggests a fully-automatic quality drivenrefactoring process, we reduce our ambition to stimulating the awareness of the

outcome of a refactoring with regard to interesting quality attributes. Thiswould support the more modest goal of a manual quality driven refactoringprocess.

Contribution of this part – In this part of the thesis, we elaborate on ameans to construct a-priori refactoring knowledge, and demonstrate this con-struction process on a selected set of refactorings and coupling and cohesionmetrics.



110 CHAPTER 9. QUALITY-DRIVEN REFACTORING

As a concrete result, we present impact tables, which specify a-priori knowl-edge on the effect of a refactoring on a set of key metrics for coupling andcohesion dimensions. These impact tables can be used to devise guidelines onthe context in which to apply a refactoring to optimize coupling and cohesion.By formalizing these guidelines as extensions of the precondition of a refactor-ing, additional postconditions can be guaranteed that refine the more generalpostcondition of the refactoring. We call such refined refactorings refactoring variants. In the next chapters, we will demonstrate how such variants can bederived, thereby progressing a small step towards quality driven refactoring.

9.1.1 Structure of Part II

The remainder of this part is organized as follows:

Chapter 10 presents the impact tables of a selected set of formalized refactor-ings and coupling and cohesion metrics. The impact derivation processitself, used to compose the impact tables, is discussed in Appendix B.These impact tables provide prediction formulae which specify how a met-ric value will be affected by a refactoring.

Chapter 11 validates the accuracy of the impact tables.

Chapter 12 exploits the impact table of one refactoring – Move Method – todevise a Move Method variant. This variant is demonstrated to optimizecoupling and cohesion.



Chapter 10

Predicting Quality Impacts

In this chapter, we formalize the effect of three selected refactorings on a selectedset of metrics for coupling and cohesion. These formalizations are restructured inimpact tables, containing formulae which can be used to predict the metric valueafter refactoring. The impact derivation process underlying the composition of these impact tables is presented in Appendix B.

This chapter is organized as follows. First, we introduce a meta-model, whichis used to formalize metrics and refactorings. Second, we present the associatedimpact tables, which are the result of a formal derivation. These impact tableswill be validated in the next chapter.

10.1 Meta-model

In this section, we recapitulate a meta-model proposed in [Briand et al., 1996,Briand et al., 1997]. This meta-model will be used in the next sections toformalize a set of refactorings and coupling and cohesion metrics.

The meta-model allows to describe the following predicates:

System – An object-oriented system consists of a set of classes C . There canexist inheritance relationships between classes such that for each class c ∈ C ,we define:

• Parents(c) ⊂ C as the set of parent classes of class c as defined by itsinheritance relationships.

111



112 CHAPTER 10. PREDICTING QUALITY IMPACTS

• Children(c) ⊂ C as the set of child classes of class c as defined by itsinheritance relationships.

• Ancestors(c) ⊂ C as the closure of Parents(c)

• Descendents(c) ⊂ C as the closure of Children(c)

Methods – For each class c ∈ C , we define:

• M IN H (c) as the set of methods that c inherits from Parents(c).

• M OV R(c) ⊂ M INH (c) as the set of methods inherited by c but which coverrides (provides a method implementation for).

• M NEW (c) as the set of methods declared in c which c did not inheritfrom Parents(c). Therefore, we have M NEW (c) ∩ M IN H (c) = ∅ andM NEW (c) ∩ M OV R(c) = ∅.

• M D(c) as the set of methods declared in the scope of c, i.e.: (i) methodsthat c inherits but does not override M IN H (c) \M OV R(c); or (ii) methodsthat c declares as virtual (in Java terms: abstract).

•M I (c) as the set of methods implemented in c, i.e.: (i) methods that c

overrides M OV R(c); or (ii) methods that c declares as non-virtual, werenot inherited and therefore provides an implementation for M NEW (c).Therefore, we have M I (c) = M OV R(c) ∪ M NEW (c).

• M (c) = M D(c) ∪ M I (c) = M INH ∪ M OV R(c) ∪ M NEW (c) as the set of allmethods of c. Note that M D(c) ∩ M I (c) = ∅.

• M (C ) = ∪c∈C M (c) as the set of all methods of the system.

• For each m ∈ M (C ), we define P ar(m) as the set of non-return parametersof method m.

• M PUB(C ) as the set of methods that are defined with public visibility inthe system.

Method invocations – For each class c, for each method m ∈ M I (c), wedefine:

• MI (m) as the set of method invocations contained in m. For each methodinvocation i ∈ MI (m), the method called is referred to as target(i).



10.1. META-MODEL 113

Attributes – Similar to methods, we define, for each class c ∈ C :

• AD(c) as the set of attributes inherited by c from Parents(c).

• AI (c) as the set of attributes implemented in class c.

• A(c) = AD(c) ∪ AI (c) as the set of all attributes of c.

• A(C ) = ∪c∈C A(c) as the set of all attributes of the system.

• APUB(C ) as the set of attributes that are defined with public visibility in

the system.

Attribute references – For each class c, for each method m ∈ M I (c), wedefine:

• AT R(m) as the set of attribute references contained in m. For each at-tribute reference atr ∈ AT R(m), the attribute referenced is referred to astarget(atr).

Types – We define the following sets of types:

• BT as the set of built-in types provided by the programming language(also known as primitive types)

• U DT as the set of user-defined types of global scope (e.g., enumerations).However, these are not classes.

• T = BT ∪ UDT ∪ C as the set of all available types.

• For each attribute a ∈ A(C ), we define T (a) ∈ T as the type of a.

• For each method m ∈ M (C ) and each parameter p ∈ P ar(m), we defineT ( p)

∈T as the type of parameter p, and T (m)

∈T as the return-type of

method m.

10.1.1 Analysis functions

In order not to expose the reader to too much detail, we merely describe thoseanalysis functions suggested by [Briand et al., 1996, Briand et al., 1997] thatwill be used in the remainder of this chapter.

∀m1, m2 ∈ M (C ), ∀c ∈ C :




• SI M (m1) = ∪i∈MI (m1)target(i), or the set of methods statically invokedby m1. Let m1 ∈ M I (c) and m2 ∈ M (C ). Then m2 ∈ SI M (m2)⇐⇒ ∃i ∈ MI (m1) | m2 = target(i).

• NSI (m1, m2) =| {i ∈ MI (m1) | target(i) = m2} |, or the number of static invocations from m1 to m2.

• P IM (m1) = {m3 ∈ M (C ) | m3 ∈ SI M (m1) ∨ ∃m2 ∈ SI M (m1) ∧ m3

overrides m2}, or the set of methods that m1 invokes due to polymorphism.

•NP I (m1, m2) =

| {i

∈MI (m1)

|m2 = target(i)

∨m2 overrides target(i)

} |,

or the number of polymorphic invocations by m1 to m2.

• AR(m) = ∪atr∈ATR(m1) target(atr), or the set of attributes referenced bym1.

• uses(m1, c) =

M I (c) ∩ P IM (m1)

∪ AI (c) ∩ AR(m1)

= ∅, or we

say that a method m1 uses a class c if and only if m1 invokes a methodimplemented by c (possibly due to polymorphism), or m1 references anattribute implemented by c.

10.2 Selection of Metrics

Coupling and cohesion are very wide concepts, signifying different kinds of de-pendencies and interrelationships. By detecting groups of measures describingsimilar phenomena, [Briand and Wust, 2001] identified 5 coupling and 2 cohe-sion dimensions. In this subsection, we discuss each dimension and provide aformalization of a single indicative metric for it.

The selection of a single indicative metric causes a threat to validity, as itintroduces a bias towards the particular aspects of the phenomena which themetric quantifies. While it is unfeasible to eliminate this threat to validity, we

choose to at least make this threat explicit by clarifying potential causes of selection bias for each of the dimensions of coupling and cohesion employed inthis chapter.

10.2.1 Import Coupling

Import coupling indicates the usage of methods from other classes by a givenclass. The dependency on the signature and result of these methods increases



10.2. SELECTION OF METRICS 115

the likelihood and impact of change ripples. Metrics related to import couplingare presented in Table 10.1.

Table 10.1: Metrics indicating import coupling

Acronym ExplanationMPC Message passing coupling.PIM Polymorphically invoked methods.

OMMIC Import coupling based on method-invocations to classes unre-lated by inheritance.

AMMIC Import coupling based on method-invocations to ancestorclasses.

ICP Information-flow-based coupling.IH-ICP Information-flow-based coupling to ancestor classes.

NIH-ICP Information-flow-based coupling to classes unrelated by inher-itance.

Acronyms of metrics related to import coupling, cited from [Briand and Wust, 2001].

Different aspects of import coupling provide a finer-grained categorizationof the measures:

• weight of a dependency – both the number of invocations (MPC, OMMIC)and the number of parameters (ICP) increase the weight of a dependency.

• relationship with the class providing the methods invoked – the providingclass can be an ancestor (IH-ICP, AMMIC), not an ancestor (OMMIC,NIH-ICP) or either (ICP, MPC, PIM).

• nature of the dependency – the dependency can hold at compile time(MPC, AMMIC, OMMIC) or at runtime (PIM, ICP series).

As a key indicator of import coupling, we select the metric Message Passing Coupling (MPC), calculating the number of static invocations from all methodscontained in a given class to methods contained in other classes. Its formaldefinition is provided in [Briand et al., 1996]:

M P C (c) =

m1∈M I(c)

m2∈SIM (m1)\M I(c)

NSI (m1, m2)

The MPC measure has three characteristics. This metric takes into ac-count both inheritance-related classes and unrelated classes, does not weight




the strength of coupling (e.g., based on parameters) and concentrates on com-pile time dependencies only.

Accordingly, in case the passing of arguments or the set of methods overrid-ing the invoked methods are regarded as considerable factors in the strength of connections, this metric is not well suited as an indicator.

10.2.2 Export Coupling

Export coupling indicates the set of responsibilities provided by a class. Theseresponsibilities do not all have be provided by the method, but can also incor-

porate those delegated to other classes. Metrics related to Export Coupling arepresented in Table 10.2.

Table 10.2: Metrics indicating export coupling

Acronym ExplanationRFCi Response set for a class.

OMMEC Export coupling based on method-invocations to classes unre-lated by inheritance.

OCMEC Export coupling based on parameter-instantiations in classes

unrelated by inheritance.OCAEC Export coupling based on attribute-instantiation in classes un-related by inheritance.

Acronyms of metrics related to export coupling, cited from [Briand and Wust, 2001].

The dependencies characterized as export coupling can be divided into twomain groups:

• Method based – The most intuitive manner of providing responsibilities ishaving methods that can be invoked by clients (RFC1, OMMEC). How-ever, by publishing a method, change ripples from delegated responsibili-

ties in other classes are also exposed to clients (RFC∞).

• Class based – A more subtle way of providing responsibilities is by pro-viding a class declaration which clients can instantiate. Such usage of theclass definition is noted for attributes (OCAEC) and method parameters(OCMEC).

The metric Export coupling based on method-invocations to classes unre-lated by inheritance (OMMEC) quantifies the number of static invocations from




methods contained in classes other than the ancestors or descendants of a givenclass, to methods contained in the given class. It’s formal definition is providedin [Briand et al., 1996]:

OMMEC (c)=

c2∈Others(c)

m1∈M I (c2)

m2∈

SIM (m1)∩(M NEW (c)∪M OV R(c)

NSI (m1, m2)

In which Others(c) = C − {c} ∪ Ancestors(c) ∪ Descendants(c)

OMMEC is an indicator for method-based export coupling, as it focuses

on the invocation of methods as the major form of coupling, rather than cou-pling caused by the instantiation of external classes in method parameters orattributes.

Accordingly, in case the instantiation of external classes is regarded as aconsiderable factor in the strength of connections, we advice to incorporate twoadditional metrics, respectively focusing on the instantiation through attributes(OCAEC) and method parameters (OCMEC).

10.2.3 General Coupling

General coupling is concerned with bidirectional coupling between classes. In-dications provided by general coupling measures are an aggregation (or mix)of indications on import and on export coupling. Metrics related to GeneralCoupling are presented in Table 10.3.

Table 10.3: Metrics indicating general coupling

Acronym ExplanationCBO Coupling between object classes.CBO’ Coupling between object classes unrelated by inheritance.

Acronyms of metrics related to general coupling, cited from [Briand and Wust, 2001].

The two indicators of general coupling differ with regard to the incorpora-tion of inheritance related classes (CBO) and general coupling exclusively withclasses unrelated to inheritance (CBO’).

The metric Coupling Between Object classes (CBO) is calculated as thenumber of classes used by or using a given class. A uses relationship can beimplemented using a method invocation or an attribute reference. CBO is for-malized in [Briand et al., 1996] as:




CBO(c) =CBOSet(c)

with CBOSet(c)

=

d ∈ C \{c} | m1∈M I(c)uses(m1, d)∨md∈M I (d)

uses(md, c)

As it is unclear when the inclusion of classes related by inheritance wouldbe undesirable, we do not consider this as a threat to validity.

10.2.4 Aggregation Import Coupling

Aggregation import coupling indicates the dependency of a given class on other

classes based on the aggregation (or composition) relationship using attributes.Metrics related to Aggregated Import Coupling are presented in Table 10.4.

Table 10.4: Metrics indicating aggregated import coupling

Acronym ExplanationDAC Data Abstraction Coupling.

OCAIC Import coupling based on attribute instantiation from classesunrelated by inheritance.

Acronyms of metrics related to aggregated import coupling, cited from [Briand and

Wust, 2001].

The aggregation or composition relationship can be refined with regard towhether the aggregated element type might be related by inheritance (DAC) ornot (OCAIC).

The metric Data Abstraction Coupling (DAC) counts the set of other classeswhich are the declared static type of a given class’s attributes. Or formally, asprovided in [Briand et al., 1996]:

DAC (c) =| a | a ∈ AI (c) ∧ T (a) ∈ C \ {c} |

DAC is characteristic in that it also incorporates coupling to inheritancerelated classes. Again, we do not consider this as a threat to validity.

10.2.5 Cohesion

When methods use the same attributes, they are considered to belong together.We differentiate between non-normalized and normalized cohesion, in which thelatter normalizes the result with regard to the number of methods of the class.Metrics related to cohesion are presented in Table 10.5.




Table 10.5: Metrics indicating cohesion

Acronym ExplanationLCOM1–5 Lack of cohesion in methods.

Co Connectivity.TCC Tight class cohesion.LCC Loose class cohesion.ICH Information-flow-based cohesion.RCI Ratio of cohesive interactions.

NRCI Neutral ratio of cohesive interactions.

PRCI Pessimistic ratio of cohesive interactions.ORCI Optimistic ratio of cohesive interactions.

Acronyms of metrics related to cohesion, cited from [Briand and Wust, 2001].

The set of cohesion measures can be classified based upon many differentcriteria [Briand et al., 1998]. The impact of one criterion is closely related tothe subject of transformations: does the measure take into account indirectconnections or not.

• Direct connections only – These measures state that a method accesses

an attribute only in case of a direct access. This means that a methodwhich use an accessor for a specific attribute is not regarded as accessingthe attribute. These measures are LCOM1, Co, LCOM2, LCOM5, TCCand ICH.

• Indirect connections – These measures state that a method accesses anattribute when it either directly accesses it, or when it invokes anothermethod which accesses it (potentially even after a sequence of invocations).These measures are LCOM3, LCOM4, LCC, RCI, NRCI, PRCI and ORCI.

Non-normalized Cohesion – The Lack of Cohesion in Methods 1 (LCOM1)

metric is defined as the number of couplings of methods which do not sharereferences to attributes in the same class. Formally, it is defined in [Briandet al., 1997] as:

LCOM 1(c) =LCOM 1Set(c)

with LCOM 1Set(c)

={m1, m2} | m1, m2 ∈ M I (c) ∧ m1 = m2

∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅




LCOM1 is characteristic in that it disregards indirect attribute accesses.Our argument is that there is a semantical difference between a direct andan indirect attribute access: an method accessing an attribute in an indirectmanner is merely an indirect client of the encapsulated data. The question istherefore whether indirect clients are also considered to be cohesive with theproviding class. In case the answer is yes, we advise to use LCOM3.

Normalized Cohesion – The selected metric Lack of Cohesion in Methods5 (LCOM5) is defined formally in [Briand et al., 1997] as:

LCOM 5(c) = |M I(c)|−1

|AI (c)|P

a∈AI (c)|{m1|m1∈M I(c)∧a∈AR(m1)}||M I(c)|−1

As is LCOM1, LCOM5 is characteristic in that it disregards indirect at-tribute accesses. One of the possible alternatives is LCC.

Table 10.6: Selected metrics.

Dimension Metric

ImportCoupling

Message Passing Coupling – MP C (c)=

m1∈M I(c)m2∈SIM (m1)\M I(c)N SI (m1, m2)

ExportCoupling

Export coupling based on method invocations from classesunrelated by inheritance – OMMEC (c)=

c2∈Others(c)

m1∈M I(c)

m2∈SIM (m1)∩(M NEW (c)∪M OV R(c)

NSI (m1, m2)

GeneralCoupling

Coupling between object classes – CBO(c)=d ∈ C \ {c} | m1∈M I(c)

uses(m1, d)

∨md∈M I(d)uses(md, c)

AggregatedImport

Data Abstraction Coupling – DAC (c)=| a | a ∈ AI (c) ∧ T (a) ∈ C \ {c} |

Coupling

NormalizedCohesion

Lack of cohesion in methods – LCOM 5(c)

=|M I(c)|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)∧a∈AR(m1)}|

|M I(c)|−1

Non-normalizedCohesion

Lack of Cohesion in methods – LCOM 1(c)={m1, m2} | m1, m2 ∈ M I (c) ∧ m1 = m2

∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅Formal description of the selected indicative class metrics for each of the dimensions of

coupling and cohesion.



10.3. SELECTION OF REFACTORINGS 121

10.2.6 Summary

Summarizing, we have selected a single indicative metric for each of 5 couplingand 2 cohesion dimensions. Table 10.6 recapitulates their acronyms and formal-izations.

10.3 Selection of Refactorings

In this section, we formalize a selected set of refactorings in terms of the meta-

model presented by [Briand et al., 1996, Briand et al., 1997]. Accordingly, theformalizations of pre- and postconditions will form merely a subset of thoserequired for the implementation of the refactorings. I.e., the implementationmight incorporate more entities and relationships then merely the ones presentin the meta-model presented earlier. However, w.r.t. the selected meta-model,the formalizations are claimed to be complete, which is sufficient to reasonabout these refactorings w.r.t. their effect on the selected coupling and cohesionmetrics.

The objective of our selection is to investigate those refactorings which re-distribute responsibilities either within the class or in between classes. Thisredistribution is the main principle to address coupling and cohesion issues.

For a population as vast and as diverse as the population of refactorings, itis infeasible to be representative. Moreover, this population is ever growing, asevery day, software engineers are describing more source code transformationssatisfying the definition of a refactoring.

Accordingly, we do not have the ambition to generalize the results of oursmall set of selected refactorings to other refactorings. Rather, we acknowledgethat properties of refactorings are specific to the selected refactoring.

In contrast, our selection criteria aims to “compose a small set of refactoringswhich redistribute responsibilities by manipulating method interactions within or between classes”. Therefore, we choose to select 3 refactorings which are

categorized in Martin Fowler’s refactoring catalogue in the categories Composing Methods and Moving features between objects [Fowler, 1999]:

Extract Method: This refactoring is supported in most popular refactoringtools (e.g., in refactoring such as tools Eclipse, IntelliJ Idea, RefactorIT,JRefactory and XRefactory). Extract Method supports the goal of re-sponsibility redistribution by enabling the disentangling of multiple re-sponsibilities from a single method.




Move Method: This refactoring as well is supported in the refactoring toolsmentioned earlier. The Move Method refactoring is fundamental to re-sponsibility redistribution by enabling the migration of methods betweenclasses.

Replace Method with Method Object: To the best of our knowledge, thisrefactoring is not supported by current refactoring tools. Nonetheless, itsupports the goal of responsibility redistribution by moving the body of amethod which entwines multiple responsibilities to a separate class. Thesuggested procedure to continue disentangling these responsibilities (as

indicated by [Fowler, 1999]), is to extract methods and move them tomore appropriate classes.

Without empirical studies on the usage of refactorings in an industrial con-text, it is hard to quantify the practical importance of these refactorings. Nonethe-less, the support of Extract Method and Move Method in most current refactor-ing tools indicates that these refactorings are popular operations. This cannotbe stated of the the Replace Method with Method Object operation.

Through a meta-analysis of the dependencies between Fowler’s 72 refactor-ings, [Wheeldon and Counsell, 2003] searched for core refactorings, upon whichmany other refactorings depend. The three most important of these core refac-torings are Extract Method, Move Field and Move Method. Accordingly, ourselection of three refactorings comprises a basic set of transformations whichprovide fundamental support for redistributing responsibilities. In the nextsubsections, we present their pre- and postconditions expressed in the samemeta-model as in which the selected refactorings were formalized.

10.3.1 Notation

The notation used for the formalization of the pre- and postcondition of thethree selected refactorings is similar to the one employed in [Roberts, 1999].

The value of a predicate of entities or relations before applying the refactoringis referred to in the predicate’s usual notation. E.g., we refer to the set of methods implemented by a class c before refactoring as M I (c). In contrast,to refer to the value of a predicate after applying the refactoring, we write anaccent behind the predicate. E.g., we refer to the set of methods implementedby a class c after refactoring as M I (c).

A refactoring’s postcondition is expressed as the specification of the value of predicates after applying the refactoring in terms of the value of these predicates




before applying the refactoring. E.g., to indicate that a refactoring will causea class c to implement a new method m, the postcondition of this refactoringspecifies that M I (c) = M I (c) ∪{m}. This means that refactoring will cause theset of implemented methods of class c to be expanded with a new method m.

10.3.2 Extract Method

Extract Method extracts a set of statements appearing in one or more methodsinto a new method. Its signature is:

ExtractMethodC c,M ms,P(MI ) I,P(AT R) A, for which:

• c is the class in which the method is to be extracted;

• ms is the method from which the statements will be extracted;

• I ∪A characterizes the set of statements S that will be extracted. I repre-sents the set of method invocations, and A represents the set of attributereferences.

It is important to note that our formal specification of Extract Method tar-gets the extraction of a single instance of a set of statements to a separatemethod. In contrast, current refactoring tools (e.g., incorporated in the Eclipse

IDE) detect duplicate instances of this set of statements and replace all theseduplications with a method invocation to the separated method. Most likely,such a multi-instance Extract Method application will affect coupling and co-hesion indicators differently than the single instance Extract Method discussedin this work.

Precondition

The precondition for Extract Method requires that the given method ms isimplemented by the given class c, and that the given sets of method invocationsI and attribute references A are contained in ms. Or formally:

• ms ∈ M I (c)

• I ⊂ MI (ms)

• A ⊂ AT R(ms)

Additional preconditions which are unrelated to our study are:

• The set of statements S should be uninterupted by statements outside S ;




Postcondition

The postcondition is extracted from the informal description provided in [Fowler,1999]. The postcondition poses that, after applying Extract Method, c will im-plement a new method mt which contains the method invocations and attributereferences selected from ms. The selected part of ms will be replaced with asingle method invocation to mt. Or formally:

• M (C ) = M (C ) ∪ {mt}, in which mt represents a the newly extractedmethod

• M NEW (c) = M NEW (c) ∪ {mt}• MI (mt) = I

• AT R(mt) = A

• MI (ms) =

MI (ms) \ I ∪ i, in which i is a new method invocation from

ms to mt, i.e., target(i) = mt. Therefore, MI (ms) = M I (ms) \ m ∈MI (ms) |∃m1 ∈

MI (ms) \ I

: target(m1) = m

• AT R(ms) = AT R(ms) \ A, and therefore, AR(ms) = AR(ms) \

a ∈AR(ms) |∃a1 ∈

AT R(ms) \ A

: target(a1) = a

An additional postcondition, unrelated to our study, is that the set of pa-rameters of mt is determined by the number of local variables of ms that arereferenced and/or updated in S . As our selected coupling and cohesion metricsdo not involve parameters, this postcondition can be disregarded in our study.

10.3.3 Move Method

Move Method moves a method from one class to another, possibly adding aparameter when resources of the original class are used:

MoveMethod

C cs, M m, C ct

, for which

• cs signifies the class from which the method will be moved, also referredto as the source class;

• m signifies the method which will be moved;

• ct signifies the class to which the method will be moved, also referred toas the target class;




Precondition

The Move Method precondition requires that the target class ct is different fromthe source class. The given method m should be a public method, implemented(and not overridden) by the source class, invoking only public methods andreferencing only public attributes of the source class. Otherwise, these methodsand attributes will no longer be visible when the method is moved. Additionally,the method to be moved may not be overridden itself in descendants of thesource class, and the inheritance hierarchy of the target class may not declare amethod with a signature similar to m. Formally, this precondition is described

as:• cs = ct

• m ∈ M NEW (cs) ∩ M PUB(cs)

or m is a public method implemented by

cs

• M (cs) ∩ SI M (m) ⊂ M PUB(cs), or m is only allowed to invoke publicmethods of its source class.

• A(cs) ∩ AR(ms) ⊂ APUB(cs), or ms is only allowed to reference publicattributes of its source class.

• m is not overridden in Descendants(cs)

• ∃mt ∈ c∈Descendants(ct)∪{ct}

: mt ∈ M (c) ∧ mt has the same signatureas m.

Postcondition

The postcondition is extracted from the informal description provided in [Fowler,1999]. The postcondition states that the Move Method refactoring will cause mto be no longer implemented by the source class cs, but by the target class ct.Formally, we have:

• m ∈ M I (cs)

• m ∈ M I (ct)

An additional postcondition unrelated to our study is that, after the methodis moved, its parameter set will be expanded with an additional parameter ps

in case m invokes a method or references an attribute implemented by cs, withT ( ps) = cs. This additional parameter would be required to be able to enablethese invocations and references.




10.3.4 Replace Method with Method Object

Replace Method with Method Object creates a new class, which has only onemethod and a constructor. The local variables and parameters of the methodare promoted to attributes of the newly created class. Its signature is:

RMWMO

C cs, M ms,P(LV ) L

, for which

• cs signifies the class from which the method will be replaced;

• ms signifies the method which will be replaced;

• L signifies the set of local variables L contained in ms.

Precondition

The precondition for Replace Method with Method Object requires that themethod to be replaced is implemented by the source class, and does only invokeor reference public methods and attributes of the source class.

• ms ∈ M I (cs)

•M (cs)

∩SI M (ms)

⊂M PUB(C ), or ms does not invoke non-public meth-

ods of it’s source class.

• A(cs) ∩ AR(ms) ⊂ APUB(C ), or ms does not reference non-public at-tributes of it’s source class.

Postcondition

The postcondition is extracted from the informal description provided in [Fowler,1999]. The postcondition stipulates that the refactoring will cause the introduc-tion of a new class ct, implementing two new methods: a constructor mct and amethod mt similar in name to the method to be replaced ms. The constructor

will have copies of the parameters of ms and an additional parameter to passthe original instance of the source class to.

The newly created class ct will declare an attribute for each local variable of ms, for each parameter of ms, and additionally, an attribute as a reference tothe original instance of the source class.

The constructor mct of the newly created class ct will be responsible forinitializing those attributes which are copies of the parameters of method ms

with the corresponding values of its parameters. Therefore, the constructor will




contain one attribute reference for each of these attributes. The constructormct will invoke no methods.

The new method mt of the newly created class ct is in fact the methodwhich will replace the method body of ms. Accordingly, mt will reference allthe attributes which ms did. Furthermore, mt will have no parameters, as thenewly created class ct provides an attribute as a copy of each parameter of ms.Thus, mt will additionally reference all attributes declared by the newly createdclass ct. Also, method mt will perform all method invocations which ms did.Thus, if ms invoked itself, mt will mimic this behavior by also invoking ms (andnot itself, which might otherwise change behavior due to potential polymorphic

calls to methods overriding ms).Finally, the replacement of the method body of ms is performed through the

removal of all attribute references from ms, and the replacement of all methodinvocations from ms with two new method invocations: one to the constructormct of the newly created class ct and one to the method mt replacing its methodbody.

• C = C ∪ {ct}, in which ct represents the newly created class

• M (C ) = M (C ) ∪ {mt, mct}, in which mt represents the replaced methodand mct represents the constructor

• M NEW (ct) = {mt, mct}• P ar(mt) = ∅• P ar(mct) = LP ∪{ ps}, in which LP represents a set of parameters which

correspond by type to P ar(ms). Moreover, ps represents an additionalparameter for the source class. I.e., T ( ps) = cs.

• A(C ) = LA ∪ P A ∪ {as}, in which LA represents a set of attributeswhich correspond by type to the set of local variables L contained in ms.

P A represents a set of attributes which correspond by type to P ar(ms)Moreover, as represents an additional attribute for the source class. Thus,T (as) = cs.

• AI (ct) = LA ∪ P A ∪ {as}

• AT R(mct) =

a∈AI(ct)\{LA} new ATR(mct, a) where new ATR(mct, a)

represents the creation of a new attribute reference from method mct toattribute a.




Therefore, AR(mct) = AI (ct) \ LA, or the new constructor mct will ini-

tialize all attributes of ct, accept the ones that represents the previouslocal variables. These will be initialized by mt.

• MI (mct) = ∅, or the new constructor will not invoke any other methods.

• AT R(mt) =

a∈AI(ct)∪AR(ms)

new ATR(mt, a).

Therefore, AR(mt) = AI (ct)∪AR(ms), or the new method mt will behave

like the former ms with regard to attribute references, but it will additionalreference attributes instead of local variables or parameters.

• MI (mt) = MI (ms), or the new method mt will behave like the formerms with regard to method invocations.

• AT R(ms) = ∅, or the method to be replaced will no longer contain at-tribute references

Therefore, AR(ms) = ∅, or the former method ms will no longer referenceattributes. This is taken over by the new method mt.

• MI (ms) = {mi1, mi2}, in which mi1 is a method invocation from theformer method ms to the constructor mct to instantiate an object of type

ct, and mi2 is a method invocation from ms to the new method mt. I.e.,target(mi1) = mct and target(mi2) = mt.

10.4 Quality Impact Prediction

In this section, we present the impact tables specifying the prediction of thevalue of the selected coupling and cohesion metrics as affected by the threeselected refactorings.

These impact tables are composed through a formal derivation process. Wedecide to present this derivation process in Appendix B. We argue that it is

better to postpone the presentation of this process until the exploitation of theimpact tables is discussed in Chapter 12 in a case study. This order will betterclarify the relevance of the derivation process itself.

Accordingly, we first present the impact tables themselves. In the nextchapter (Chapter 11), the validation of these impact tables is presented. Sub-sequently, in Chapter 12, we discuss the exploitation of the validated impacttables for a refinement of a refactoring variant, optimizing the selected couplingand cohesion metrics. Only after this goal has been achieved, we feel that the



10.4. QUALITY IMPACT PREDICTION 129

time is right to discuss the formal derivation process itself, which otherwisemight burden the understanding of the path towards refactoring variants.


Table 10.8 summarizes the effect of applying Extract Method on the selected setof indicative metrics for the different dimensions of coupling and cohesion. Thiseffect description states that a single-instance Extract Method application (notreplacing duplicate statements) does not affect coupling. In contrast, cohesionis potentially reduced, due to the introduction of a new method.

Table 10.7: Impact table for Extract Method

Prediction formula

MPC pred(c) = MPCbef (c)OMMEC pred(c) = OMMECbef (c)

CBO pred(c) = CBObef (c)DAC pred(c) = DACbef (c)

LCOM5 pred(c) = t1.LCOM5bef (c) + t2 + t3with t1 = |M I(c)|−1

|M I(c)|

t2 =

a∈AI(c)∩AR(ms)|∃a1∈ATR(ms)\A

:target(a1)=a

|AI (c)|.|M I(c)|

t3 =|AI(c)\

Satr∈A target(a)|

|AI(c)|.|M I(c)|

LCOM1 pred(c) = LCOM1bef (c) + t1 + t2 + t3with t1 =

{m1, ms} | m1 ∈ M I (c) \ {ms}∧

AR(m1) ∩ AR(ms) ∩ AI (s) = ∅∧AR(m1) ∩ AR(ms) ∩ AI (c)

⊆

atr∈A target(atr)

\atr∈ATR(ms)\Atarget(atr)

t2 ={m1, mt} | m1 ∈ M I (c) \ {ms}∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅

t3 ={ms, mt} |

atr∈ATR(ms)\A

target(atr)

∩atr∈A target(atr) ∩ AI (c) = ∅Formal description of the effect of applying Extract Method on class metrics.

The potentially harmful effect w.r.t. cohesion can be explained as follows.Extract Method makes the relationship between the extracted set of statements




and the other methods of the current class more explicit. Therefore, if theextracted statements are unrelated to the current class, this will become visiblein reduced cohesion. In such cases, the extracted method is typically moved to amore appropriate host in a new refactoring step, e.g., using Move Method. Thisin fact demonstrates a typical strategy for redistributing functionality betweenclasses: first disentangle existing responsibilities and then redistribute themacross the class hierarchy.

We discuss the predicted effect on coupling metrics for normalized and non-normalized cohesion separately:

Normalized cohesion – The Lack of Cohesion in Methods metric LCOM5 isan inverse cohesion metric. Accordingly, its value indicates the extent towhich cohesion is violated. Thus, the increase predicted by Table 10.7based on the two terms t2 and t3 signifies an actual decrease in cohesion.However, the prediction formula also indicates that the Extract Methodrefactoring might, in some cases, improve cohesion, as indicated by termt1 (≤ 1).

The second term, t2, calculates the number of attributes, implemented byclass c, which are referenced in the method m from which statements willbe extracted. From this set of attributes, t2 selects those attributes which

are not referenced in the remaining statements of m. This set thereforeindicates the set of attributes which method m will no longer referenceafter the Extract Method is applied. The size of term t2 is relative to thenumber of attributes and methods implemented by c.

The third term, t3, calculates the number of attributes, implemented byclass c, which the extracted statements do not reference. This set indicatesthe set of attributes which the new method mt will not reference, afterthe Extract Method is applied. Again, the size of this term is relative tothe number of attributes and methods implemented by c.

Term t1 (always ≤ 1) indicates that, in case the extracted and remain-

ing statements both reference all the attributes implemented by class c,then a resulting increase in cohesion is relative to the number of methodsimplemented by c. E.g., if class c implements two methods m1 and m2,and m1 consists of two blocks of statements b1, b2 which both reference allattributes implemented by c, then the extraction of either block b1 or b2will reduce the lack of cohesion of class c by half.

Non-normalized cohesion – The non-normalized variant of Lack of Cohe-sion in Methods, metric LCOM1, is also an inverse cohesion metric. The




prediction formula mentioned in Table 10.7 predicts the LCOM1 metricvalue to be increased after applying the Extract Method refactoring, dic-tated in three terms t1, t2 and t3.

Table 10.8: Impact description for Extract Method.

Metric Value after refactoring

M P C (c) Will remain unchanged.OMMEC (c) Will remain unchanged.

CBO(c) Will remain unchanged.DAC (c) Will remain unchanged.

LCOM 5(c) Will be(t2) increased proportionate to the number of sibling

attributes which the remaining statements do notreference;

(t3) and additionally increased proportionate to thenumber of sibling attributes which the extractedstatements do not reference.

LCOM 1(c) Will be(t1) increased with the number of sibling methods

which share references to sibling attributes with theextracted statements, but not with the remainingstatements;

(t2) and additionally increased with the number of sib-ling methods which do not share references to sib-ling attributes with the extracted statements;

(t3) and additionally increased with 1 in case the re-maining statements do not share references to sib-

ling attributes with the extracted statements.

Summarizing description of the effect of Extract Method on class metrics.

The first term, t1, represents the number of methods implemented by classc with which the original method m shared attribute references beforerefactoring. In case the remaining statements no longer share referenceswith these methods, an increase in lack of cohesion is introduced.




Term t2 dictates a similar increase in lack of cohesion, corresponding tothe number of methods (excluding the original method m), with whichthe extracted statements do not share attribute references.

Lastly, term t3 specifies that, in case the extracted and remaining state-ments do not share attribute references, than after refactoring, the originalmethod and the newly created method will not be cohesive.

This effect description is summarized in Table 10.8.

10.4.2 Move Method

The impact table of Move Method is presented in Table 10.9. We discuss eachprediction formula separately:

MPC: The Message Passing Coupling value is predicted to be decreased with aterm t1, and increased with a term t2. The decrease is due to the methodinvocations contained in the method to be moved, which will no longerdepart from the source class (t1). The increase, as represented by t2,indicates that, in case the other methods of the source class cs invoke themethod to be moved, then these method invocations will be consideredoutgoing invocations after the move operation.

OMMEC: The value of the selected metric for export coupling is also pre-dicted to be both increased and decreased. Similar to the effect of MoveMethod on import coupling, after the method is moved, method invoca-tions involving this method will be considered invocations to or from adifferent class. Term t1 describes a decrease of OMMEC with the numberof method invocations from methods implemented by classes other thanthe source class cs to the method to be moved m. In contrast, methodinvocations from m to the other methods of the source class will be added

to the OMMEC metric value after refactoring (t2).

CBO: The impact table specifies that the Coupling Between Objects metricvalue will be altered by the Move Method refactoring in three ways, for-malized in terms t1, t2 and t3.

First, classes other than the source and target class that were coupledexclusively to the source class via the method to be moved m will nolonger be incalculated in the CBO metric value after refactoring (t1).




Table 10.9: Impact table for Move Method

Prediction formula

MPC pred(cs) = MPCbef (cs) - t1 + t2with t1 =

m2∈SIM (m)\M I(cs)

NSI (m, m2)

t2 =

m1∈M I(cs)\{m} NSI (m1, m)

OMMEC pred(cs) = OMMECbef (cs) - t1 + t2with t1 =

c2∈Others(cs)

m1∈M I(c2)

NSI (m1, m)

t2 = m2∈SIM (m)∩(M NEW (cs)∪M OV R(c))\{m}NSI (m, m2)

CBO pred(cs) = CBObef (cs) - t1 - t2 + t3

with t1 =

x ∈ C \ {cs, ct}

|

uses(m, x) ∨ ∃md ∈ M I (x) : m ∈ P IM (md)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x) ∧

∀md ∈ M I (x) :

(M I (cs) \ {m}) ∩ P IM (md)

∪(AI (cs) ∩ AR(md))

= ∅

t2 =

x ∈ {ct} |

uses(m, ct) ∨ ∃md ∈ M I (ct) : m ∈ P IM (md)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, ct) ∧∀md ∈ M I (ct) :

(M I (cs) \ {m}) ∩ P IM (md) ∪(AI (cs) ∩ AR(md))

= ∅

t3 =

x ∈ {ct} |

ms∈M I (cs)\{m}

m ∈ P IM (ms)

∨

M I (cs) \ {m} ∩ P IM (m) = ∅

∧ ¬uses(ct, cs)

DAC pred(cs) = DACbef (cs)

LCOM5 pred(cs) = t1.

LCOM5bef (c) - t2

with t1 = |M I(c)|−1

|M I(

c)|−2t2 = |AI(cs)\AR(m)|

|AI(cs)|.|M I(cs)|−1

LCOM1 pred(c) = LCOM1bef (c) - t1

with t1 =m1 | m1 ∈

M I (cs) \ {m} ∧m1 = m∧AR(m1) ∩ AR(m) ∩ AI (cs)

= ∅

Formal description of the effect of applying Move Method on class metrics.

Second, term t2 describes a similar consequence, but then specified for




the target class. In case method m was the only cause of coupling fromthe source class to the target class, then the target class will no longer becoupled to the source class via m.

Lastly, in case the target class was not coupled to the source class, thismight be altered after the Move Method refactoring. Term t3 specifiesthat this will occur in case the other methods of the source class invokethe method to be moved m, or in case m invokes the other methods of thesource class.

DAC: The Data Abstraction Coupling metric value is predicted not to be af-fected by the Move Method refactoring. This can be explained by the factthat the Move Method refactoring does not create or remove attributes,and nor does it change the type of attributes implemented by the sourceclass.

The prediction formulae w.r.t. the selected cohesion metrics can be inter-preted as follows:

LCOM5: The normalized lack of cohesion variant is predicted to be affected bytwo terms, t1 and t2. The first term, t1, is a multiplication factor (always≥ 1). Accordingly, it dictates that the effect of applying Move Methodon a class which has only few methods will be larger than an equivalentapplication on a class with many methods.

The second term, t2, calculates the number of attributes implemented bythe source class cs that are not referenced by the method to be moved.Again, the size of this term is relative to the number of attributes andmethods implemented by c.

LCOM1: The prediction formula for the non-normalized lack of cohesion vari-ant is predicted to be decreased with the number of other methods imple-mented by the source class that do not share references with the methodto be moved.

Once again, we summarize the description of the predicted effect in a sepa-rate table, namely Table 10.10.




Table 10.10: Impact description for Move Method.


MP C (cs) Will be decreased with the number of static invocationsfrom the method to be moved to external methods; andadditionally increased with the number of static invocationsfrom the other methods implemented by the source class tothe method to be moved.

OMMEC (cs) Will be decreased with the number of static invocationsfrom methods implemented by classes not contained in thesource class’ inheritance hierarchy to the method to bemoved (t1); and additionally increased with the numberof static invocations from the method to be moved to othernew or overridden methods from the source class (t2).

CBO(cs) Will be (t1) decreased with the number of classes (= ct)coupled to the source class exclusively by the method tobe moved; (t2) additionally decreased with 1 in case thetarget class is coupled to the source class exclusively by themethod to be moved, which may in that case also not invokeor reference other methods or attributes from the source

class; and (t3) additionally increased with 1 in case thetarget class is not coupled to the source class, and either:(i) any sibling method uses the method to be moved; or(ii) the method to be moved uses any sibling method orattribute.

DAC (cs) Will remain unchanged.

LCOM 5(cs) Will be decreased proportionate to the number of attributesimplemented by the source class, which the method to bemoved does not reference (t2).

LCOM 1(cs) Will be decreased with the number of methods implemented

by the source class that do not share references to siblingattributes with the method to be moved (t1).

Summarizing description of the effect of Extract Method on class metrics.


Table 10.11 stipulates how the Replace Method with Method Object refactoringwill affect the selected coupling and cohesion metrics.




MPC: The selected metric for import coupling, Message Passing coupling, ispredicted to be decreased with (t1) the number of invocations from themethod to be replaced (ms). Additionally, as the method body of thismethod will be replaced with an invocation to the constructor of the newlycreated class ct, and an invocation to the new method of ct, two newinvocations will be incalculated in the MPC metric value after refactoring.

Table 10.11: Impact table for Replace Method w Method Object

Prediction formula

MPC pred(cs) = MPCbef (cs) - t1 + 2with t1 =


NSI (ms, m2)

OMMEC pred(cs) = OMMECbef (cs) + t1with t2 =

m2∈

SIM (ms)∩(M NEW (cs)∪M OV R(cs)

NSI (ms, m2)

CBO pred(cs) = CBObef (cs) - t1 + 1

with t1 =x ∈ C \ {cs} | uses(ms, x)

∧mc∈(M I(cs)\{ms})¬uses(mc, x) ∧¬uses(x, cs)


LCOM5 pred(cs) = LCOM5bef (c) + t1with t1 = |AR(ms)∩AI (cs)|

|AI(cs)|.|M I (cs)|−1

LCOM1 pred(cs) = LCOM1bef (c) + t1

with t1 ={m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅Formal description of the effect of applying Replace Method with Method Object

on class metrics.

OMMEC: The prediction formula for OMMEC states that (t1) the number of

method invocations from the method to be replaced ms to other methodsof the source class cs will be added to the OMMEC metric value.

CBO: As the Replace Method with Method Object refactoring incorporatesthe creation of a new class and its usage by the source class, a fixed valueof 1 will be added to the CBO metric value after refactoring. However, (t1)the number of classes used only by ms and not by the other methods of thesource class will decrease the value of the CBO metric, on the conditionthat the methods of these classes do not use the source class.




DAC: As was the case for the two other refactorings, neither is the ReplaceMethod with Method Object predicted to affect the Data AbstractionCoupling metric. Once again, this can be explained by the fact that thismetric does not affect the attributes of the source class.

Lastly, we discuss the prediction formulae w.r.t. the selected coupling met-rics:

Table 10.12: Impact description for Replace Method with Method Object


MP C (cs) Will be decreased with the number of static invocationsfrom ms to methods implemented by classes other than cs

(t1); and additionally increased with 2OMMEC (cs) Will be increased with the number of static invocations

from ms to new and overriding sibling methods(t2).CBO(cs) Will be decreased with the number of classes for which ms is

the single cause of coupling (t1); and additionally increased with 1

DAC (cs) Will remain unchanged.

LCOM 5(cs) Will be increased proportionate to the number of sibling

attributes, which ms references (t1).LCOM 1(cs) Will be increased with the number of sibling methods that

share references to sibling attributes with ms (t1).

Summarizing description of the effect of applying Replace Method with Method Object

on class metrics.

LCOM5: The LCOM5 metric value is predicted to be increased with a singleterm t1. This term calculates the number of attributes implemented bythe source class, which the method to be replaced references. Term t1

is relative to the number of attributes and methods implemented by thesource class, indicating that this effect is relative to the size of a class.

LCOM1: After performing the Replace Method with Method Object refac-toring, the LCOM1 metric value is predicted to be increased with (t1)the number of other methods implemented by the source class that shareattribute references with the method to be replaced ms. This can be ex-plained by the fact that, after refactoring, the method body of ms will nolonger contain attribute references.




A summary of the predicted effect of Replace Method with Method Objectis provided in Table 10.12.

Accordingly, we have presented three impact tables, which we will validatein the next chapter.



Chapter 11

Validating PredictedImpacts

In this chapter, we report on the validation of the impact tables presented inthe previous chapter. These impact tables provide formalizations of a-prioriknowledge w.r.t. the effect of applying a refactoring on indicative metrics for

coupling and cohesion. As a means for validation, we compare the values of the selected metrics before and after refactoring with the value predicted by theimpact tables.

11.1 Introduction

For each of the three refactorings discussed in the previous chapter, we validatethe associated impact table according to the following stepwise procedure:

1. Collect a set of refactoring candidates, satisfying the precondition of the

refactoring. These candidates are characterized by the parameters men-tioned in the signature of the formalized refactorings. E.g., the signatureof the Extract Method refactoring is defined as ExtractMethod

C cs, M

ms,P(MI ) I,P(AT R) A

. Extract Method candidates are thereforecharacterized by a specification of a class cs, a method ms, and a set of method invocations I and attribute references A. A refactoring candi-date provides these arguments, which satisfy the precondition of ExtractMethod as specified in the previous chapter. In other words, refactoring

139



140 CHAPTER 11. VALIDATING PREDICTED IMPACTS

candidates indicate where a refactoring can be applied.

2. Select a set of refactoring candidates. For each refactoring, our selectionconsists of ten refactoring candidates. This selection provides a variationof the different terms described by the predicted metric impact. Eachprediction describes the value of a metric after refactoring as a formula of the metric value before refactoring, plus and/or minus a number of terms.These terms consist of queries for which the cardinality of the result setis taken. By assuring that different candidates have different values forthese terms (e.g., some have a value of zero for a term, while others do

not), we can verify the accuracy of the prediction formula under differentconditions, thereby strengthening the validation.

3. Collect the metric values of the classes associated with the selected refac-toring candidates. This collection provides the metric values before refac-toring. For each metric Metric, the value before refactoring is referred toas Metricbef .

4. Calculate the different terms of the prediction formulae in the impact tablefor the code fragment associated with the refactoring candidate before

refactoring.

5. Apply the selected refactoring candidates. For this step, we use theEclipse IDE (v3.2M4). Eclipse provides automated support for the Ex-tract Method and Move Method refactorings. In contrast, we apply Re-place Method with Method manually as this refactoring is not automatedin Eclipse. The transformation process for this refactoring is dictated bythe specification of the Replace Method with Method Object refactoring,as presented in the previous chapter.

6. Collect the metric values of the classes associated with the selected refac-

toring candidates. This collection provides the metric values after refac-toring. For each metric Metric, the value after refactoring is referred toas Metricaft.

7. Apply the prediction formula by substituting the calculated values forthe different terms (step 4). For each metric Metric, substituting thesecalculated terms provides the predicted value after refactoring, referred toas Metric pred.



11.1. INTRODUCTION 141

8. Verify that the predicted value after refactoring is equal to the actual valueafter refactoring, i.e., that Metric pred = Metricaft. This step is reportedin the validation tables reported on in the next section.

This procedure leads to the validation of each prediction formula presentedin the impact tables for Extract Method (Table 10.7), Move Method (Table10.9) and Replace Method with Method Object(10.11). In case we found thatMetric pred = Metricaft, this was due to a defect in the impact derivationpresented in Chapter B, which was then corrected, followed by a restart of thevalidation procedure.

11.1.1 System Under Study

To collect refactoring candidates, we analyze software systems that are likely tocontain many refactoring candidates. As systems under study, we selected twosystems written in Java: (i) the open source UML modeling tool ArgoUML1;and (ii) a toy-example used frequently in software engineering research, entitledthe LAN simulation [?]:

ArgoUML v0.19.8 was released in November 2005, about 11 years after itsinitial design. We select ArgoUML because it is a software system of reasonable

size (ArgoUML contains about 1300 classes) and has a considerable develop-ment history. The project started in 1994 and provides monthly releases. Thesemonthly releases demonstrate a process of continuous extension, in which op-portunities for refactoring are likely to be found. Therefore, we expect to haveno problems detecting refactoring candidates.

The LAN Simulation v2.0 is a toy example consisting of 5 classes, writtenin Java. We collect refactoring candidates in this software system in case a spe-cific combination of term values is uncommon in practice. For example, part of the precondition of the Replace Method with Method Object refactoring requires

that the method to be moved does not reference non-public attributes. However,the prediction formulae for the selected cohesion metrics incorporate referencesto attributes in their terms. Therefore, in order to exploit variation in theseterms, we adapted the source code of the LAN simulation. These artificiallycreated refactoring candidates enable us to validate the prediction formulae forthe Replace Method with Method Object refactoring in the uncommon case of a class having public attributes referred by its methods.

1http://www.argouml.tigris.org




Accordingly, these software systems provide us with candidates for the threeselected refactorings.

11.1.2 Measurement Instrument

As a means to collect the metric values before and after refactoring, as well asthe values for the terms mentioned in the prediction formulae, we implementedtwo tools.

First, a tool was implemented to transform an Abstract Syntax Tree (AST)representation of a software system to a representation in an implementation

of the metamodel discussed in section 10.1 (originating from [Briand et al.,1996, Briand et al., 1997]). The tool is implemented as an Eclipse plugin, andemploys the AST representation provided by the Eclipse Java DevelopmentTools (JDT) as the input for the transformation. Accordingly, we applied thetool to construct a representation of both ArgoUML and the LAN simulationas instances of the metamodel described in section 10.1.

A second tool was implemented to calculate the selected coupling and cohe-sion metrics on the representations of ArgoUML and the LAN simulation. Asthis metamodel was identical to the metamodel in which the metrics were for-malized, we are confident that the metric definitions are implemented correctly.

This metric tool is used to collect the metric values before and after refactoring,and also to calculate the value of the terms specified in the prediction formulae.

11.2 Data Analysis

In this section we present the data collected for validating the impact tables.The validation is based on the calculation of the following values:

Metricbef : Metric value before applying the refactoring.

Metricaft

: Actual metric value after applying the refactoring. In case Metricaftequals Metricbef , we indicate this by writing a tilde (∼). Otherwise, we

write the actual value.

Metric pred: Prediction of the metric value after applying the refactoring. Thisprediction is dictated by the formulae in the impact table of each refac-toring. In case Metric pred equals Metricaft, we indicate this by writing acheck mark (

√). In the rare event where this is not the case, we write the

actual predicted value.




ti: Value of the i-th term of a prediction formula.

For each selected refactoring, we verify that, for each selected metric, itholds that Metric pred = Metricaft. In other words, we verify that the predictedvalue equals the actual value after applying the refactoring. We demonstratethis equality in tables illustrating the calculation of Metric pred.


The impact table which is validated in this subsection is specified in the previous

chapter in Table 10.7 and informally described in Table 10.8.

Effect on coupling metrics – The Extract Method refactoring is predictednot to affect the selected coupling metrics. Tables 11.1 – 11.4 illustrate theresult of the validation for these predictions. The rows in each table signifyeither the value of the metric before (Metricbef ) or after (Metricaft) applyingthe refactoring candidate. The last row provides the prediction of the value of the metric after refactoring (Metric pred). A table confirms the accuracy of theprediction of the effect of a refactoring on a metric in case the Metric pred rowis filled with

√marks.

As illustrated in Table 11.1, the predicted value corresponds to the actualvalue after refactoring for all Extract Method candidates except candidate 8. ForExtract Method candidate 8, we observe that MPC pred=45, which is not equalto the actual value 42. For this Extract Method candidate, Eclipse detected aduplicate of the extracted statements in the constructor, and therefore replacedthese statements as well with a method call. As this duplicate consisted of threemethod invocations to external classes, the value of MPC after refactoring wasreduced with three.

Table 11.1: MPC impact validation for Extract Method.

Metric 1 2a 2b 3 4 6 7 8 9 10MPCbef 37 10 264 53 30 25 69 45 23 45MPCaft ∼ ∼ ∼ ∼ ∼ ∼ ∼ 42 ∼ ∼MPC pred

√ √ √ √ √ √ √45

√ √

Validation of the prediction formula for the effect of Extract Method

w.r.t. MPC, stating that: MPCpred = MPCbef . A ∼ symbol in the

MPCaft row indicates that MPCaft=MPCbef . A√

symbol in the

MPCpred row indicates that MPCpred=MPCaft .




Table 11.2: OMMEC impact validation for Extract Method.

Metric 1 2a 2b 3 4 6 7 8 9 10

OMMECbef 1 0 380 2 2 0 25 7 8 12OMMECaft ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼OMMEC pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Extract Method w.r.t.

OMMEC, stating that: OMMECpred = OMMECbef .

Table 11.3: CBO impact validation for Extract Method.

Metric 1 2a 2b 3 4 6 7 8 9 10

CBObef 20 157 187 31 17 18 17 37 229 68CBOaft ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼CBO pred

√ √ √ √ √ √ √ √ √ √


CBO, stating that: CBOpred = CBObef .

Table 11.4: DAC impact validation for Extract Method.

Metric 1 2a 2b 3 4 6 7 8 9 10

DACbef 0 1 19 1 1 1 7 3 10 3DACaft ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼DAC pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Extract Method

w.r.t. DAC, stating that: DACpred = DACbef .

Accordingly, Extract Method candidate 8 demonstrates that the predictionsaccording to the impact tables are invalid in case the application of the refactor-ing violates the specification of the refactoring in terms of its pre- and postcon-ditions. More specific, the Extract Method specification specified the extraction

of a single set of statements, without duplicates. The extraction of duplicatesets of statements (as applied for candidate 8) is a different refactoring, which(potentially) has a different effect on coupling and cohesion metrics.

Effect on cohesion metrics – The same set of Extract Method candidatesis used to validate the accuracy of the impact table w.r.t. the effect of ExtractMethod on cohesion metrics. Tables 11.5 and 11.6 illustrate the different termsin the formulae for predicting respectively LCOM5 and LCOM1.




Table 11.5: LCOM5 impact validation for Extract Method

1 2a 2b 3 4 6 7 8 9 10

t112

23

7980

45

56

45

1819

1112

1112

1213

LCOM5bef NaN 1.5 .945 1 1 1 .896 .886 .98 .861+t2

00 0 0 1

5 0 0 1152 0 1

120 0+t3

00

13

221760 0 1

6 0 7152

112

9120

239

LCOM5aft ∼ 1.33 .95 ∼ ∼ .8 .901 .896 .982 .846LCOM5 pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Extract Method w.r.t. LCOM5:LCOM5pred(c) = t1.LCOM5bef (c) + t2 + t3.

These tables are to be interpreted similarly to the previous tables:

Table 11.5: Aside rows for the value of LCOM5 before and after applying theExtract Method candidate, the table also contains rows which signify thethree terms of the formula for LCOM5 as provided in impact table 10.7.This formula states that the Lack of Cohesion in Methods value of theclass in which the Extract Method is applied is multiplied with a term t1and then potentially increased with two terms t2 and t3. E.g., for Extract

Method candidate 3, we have LCOM5 pred(c) = t1.LCOM5bef (c) + t2 +t3 = 4

5 .1 + 15 + 0 = 1 = LCOM5aft(c).

Table 11.6: LCOM1 impact validation for Extract Method

1 2a 2b 3 4 6 7 8 9 10

LCOM1bef 1 3 2716 10 15 10 154 60 54 70+t1 0 0 0 0 0 0 2 0 0 0+t2 1 2 78 4 5 4 16 11 9 11+t3 1 1 1 1 1 0 1 1 1 0

LCOM1aft 3 6 2795 15 21 14 173 72 64 81LCOM1 pred

√ √ √ √ √ √ √ √ √ √


LCOM1, stating that: LCOM1pred(c) = LCOM1bef (c) + t1 + t2 + t3.

Table 11.6: The formula for predicting the value of LCOM1 after applying therefactoring requires the addition of three terms t1, t2 and t3 to the valueof LCOM1 before refactoring. E.g., for Extract Method candidate 3, we




have LCOM1 pred(c) = LCOM1bef (c) + t1 + t2 + t3 = 10+ 0 +4 +1 = 15= LCOM1aft(c).

Thus, the application of the ten selected Extract Method candidates confirmsthe accuracy of impact Table 10.9.

11.2.2 Move Method

The impact table which is validated in this subsection is specified in the previous

chapter in Table 10.9 and informally described in Table 10.10.

Effect on coupling metrics – The Move Method refactoring is predicted toaffect all coupling metrics except Data Abstraction Coupling (DAC).

Table 11.7: MPC impact validation for Move Method

124 71 155 163 A B C D E F

MPCbef 9 18 1 25 144 94 4 9 43 72-t1 -9 -9 -1 -1 -92 0 -3 0 -4 -10

+t2 0 0 0 0 1 0 1 0 0 1

MPCaft 0 9 0 24 53 ∼ 2 ∼ 39 63MPC pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Move Method w.r.t. MPC,

stating that MPCpred = MPCbef - t1 + t2.

We discuss each coupling metric separately:

Table 11.7: The prediction formula for the Message Passing Coupling valuedescribes that, after applying Move Method, some method invocations willno longer depart from the source class (t1), and that method invocationsfrom other methods in the source class cs to the method which is movedwill be considered invocations to a method from a different class (t2).We illustrate the application of Move Method candidate 71. For thiscandidate, we have MPCbef (cs) = MPCbef (cs) - t1 + t2 = 18 − 9 + 0 = 9= MPCaft(cs).




Table 11.8: OMMEC impact validation for Move Method

124 71 155 163 A B C D E F

OMMECbef 1 4 0 164 16 6 16 2 13 3-t1 -1 0 0 0 -1 -1 0 0 -4 0

+t2 0 0 0 0 0 2 0 1 0 0

OMMECaft 0 ∼ ∼ ∼ 15 7 ∼ 3 9 ∼OMMEC pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Move Method w.r.t. OM-

MEC, stating that: OMMECpred = OMMECbef - t1 + t2.

Table 11.8: Similarly, the Move Method refactoring is predicted to affect theselected metric for export coupling according to two changes. First, themethod invocations from other classes to the method to be moved willno longer arrive in the source class (t1). Second, method invocationsfrom the method which is moved to the other methods in the sourceclass will be considered new incoming method invocations (t2). For MoveMethod candidate A, this calculation goes as follows: OMMEC pred(cs) =OMMECbef (cs) - t1 + t2 = 16 − 1 + 0 = 15 = OMMECaft(cs)

Table 11.9: CBO impact validation for Move Method

124 71 155 163 A B C D E F

CBObef 3 15 4 47 66 39 25 11 9 18-t1 -2 -1 0 0 0 0 -3 0 0 0-t2 -1 -1 -1 -1 0 0 0 0 -1 0

+t3 0 0 0 0 1 1 1 0 0 1

CBOaft 0 13 3 46 67 40 23 ∼ 8 19CBO pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Move Method w.r.t.

CBO, stating that: CBOpred = CBObef - t1 - t2 + t3.

Table 11.9: The impact table specifies that the Coupling Between Objectclasses value will be decreased with the number of methods exclusivelycoupled to the source class via the method to be moved (t1), which mightalso apply for the target class (t2). Term t3 signifies that a value of 1will be subsequently added in case the method to be moved and the othermethods of the source class invoke one another. For example, for Move




Method application 71, we have: CBO pred(cs) = CBObef (cs) - t1 - t2 +t3 = 15 − 1 − 1 + 0 = 13 = CBOaft(cs).

Table 11.10: The Data Abstraction Coupling value is predicted not to be af-fected by the Move Method refactoring. Accordingly, the predicted valueis equal to the value before refactoring.

Table 11.10: DAC impact validation for Move Method

124 71 155 163 A B C D E F

DACbef 0 1 16 5 2 1 0 0 1 1DACaft ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼DAC pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Move Method w.r.t.

DAC, stating that: DACpred = DACbef .

Effect on cohesion metrics – The validation of the effect of Move Methodon the two selected cohesion metrics is discussed in two tables:

Table 11.11: The Lack of Cohesion in Methods variant LCOM5 is predicted

to be decreased proportionate to the number of sibling attributes notreferenced by the method to be moved (t2). The fact that this effect isrelative to the number of methods in the source class is made explicitthrough a multiplication factor (t1). As an example, we consider MoveMethod candidate 71: LCOM5 pred(cs) = t1.

LCOM 5 pred(cs) - t2

= 4

3 .

1

- 14

= 1 = LCOM5aft(cs).

Table 11.11: LCOM5 impact validation for Move Method

124 71 155 163 A B C D E F

t1 0−1

43

0−1

3029

1716

1514

21

54

109

76

LCOM5bef NaN 1 NaN .913 .871 .905 NaN NaN 1 .714-t2

00 -14

160 - 1

30 - 585 - 7

10500

00 - 1

10 -17LCOM5aft ∼ 1 ∼ .910 .863 .898 ∼ ∼ ∼ .667LCOM5 pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Move Method w.r.t. LCOM5, stating

that: LCOM5pred = t1.`

LCOM5bef - t2´

.




Table 11.12: The non-normalized LCOM1 variant is specified to be affectedby the Move Method refactoring through a decrease with the number of other methods in the source class with which the method to be moveddid not share attribute references (t1). E.g., for Move Method candidateA, we have: LCOM1 pred(cs) = LCOM1bef (cs) - t1 = 130 − 17 = 113 =LCOM1aft(cs).

Table 11.12: LCOM1 impact validation for Move Method

124 71 155 163 A B C D E F

LCOM1bef 0 10 0 312 130 111 3 15 55 25-t1 0 -4 0 -30 -17 -15 -2 -5 -10 -7

LCOM1aft ∼ 6 ∼ 282 113 96 1 10 45 18LCOM1 pred

√ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Move Method w.r.t. LCOM1,

stating that: LCOM1pred = LCOM1bef - t1.

Summarizing, our results regarding the effect of the ten selected Move Methodcandidates confirm the correctness of impact Table 10.9.


The impact table which is validated in this subsection is specified in the previouschapter in Table 10.11 and informally described in Table 10.12.

The Replace Method with Method Object precondition dictates, among oth-ers, that the method which will be replaced may not reference non-public at-tributes. Therefore, to incorporate refactoring candidates that provide differentvalues for the terms w.r.t. the cohesion metrics, we require methods that ref-erence public attributes. As this is uncommon, five out of the eleven selected

refactoring candidates were artificially created using the LAN simulation case.These candidates are notated as L1–L5.

These five artificial candidates all originate from the same class. Accordingly,for all metrics, the value of the metric before applying the refactoring (Metric pre)is equal for L1 to L5.

Effect on coupling metrics – We discuss the effect of Replace Method withMethod Object separately for each metric:




Table 11.13: The Message Passing Coupling metric value is predicted to bedecreased with the number of invocations from the method to be replacedto other classes (t1). Subsequently, the value of two has to be added toincorporate two new calls: one to the constructor of the new class, andone for the delegation to the method in the new class. When we apply thisformula for Replace Method with Method Object candidate 7a, we have:MPC pred(cs) = MPCbef (cs) - t1 + 2 = 80 − 9 + 2 = 73 = MPCaft(cs).

Table 11.13: MPC impact validation for Replace Method w Method Object

1 3 5a 7a 7b 8a L1 L2 L3 L4 L5MPCbef 25 27 7 80 36 6 120

-t1 0 0 -4 -9 -5 -2 -6 -12 -9 -15 -11+2 2

MPCaft 27 29 5 73 33 ∼ 116 110 113 107 111MPC pred

√ √ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Replace Method with Method

Object w.r.t. MPC, stating that: MPCpred = MPCbef - t1 + 2.

Table 11.14: The prediction formula for the selected export coupling met-

ric specifies an increase of the OMMEC value after applying the Re-place Method with Method Object refactoring equal to the number of method invocations from the method to be replaced to sibling methods(t1). For Replace Method with Method Object candidate 7a, this yields:OMMEC pred(cs) = OMMECbef (cs) + t1 = 16+1 = 17 = OMMECaft(cs).

Table 11.14: OMMEC impact validation for Replace Method w Method Ob- ject

1 3 5a 7a 7b 8a L1 L2 L3 L4 L5

OMMECbef 158 11 17 16 0 0 41

+t1 1 0 0 1 0 1 3 1 1 1 1OMMECaft 159 ∼ ∼ 17 ∼ 1 44 42 42 42 42OMMEC pred

√ √ √ √ √ √ √ √ √ √ √


Object w.r.t. OMMEC, stating that: OMMECpred = OMMECbef + t1.

Table 11.15: The Replace Method with Method Object refactoring is pre-dicted to affect the Coupling Between Object classes with a decrease of the




number of classes to which the method to be replaced is exclusively cou-pled (t1); and a subsequent addition of 1 for the use of the newly createdclass. Accordingly, for Replace Method with Method Object candidate7b, we have: CBO pred(cs) = CBObef (cs) - t1 + 1 = 34 − 2 + 1 = 33 =CBOaft(cs).

Table 11.15: CBO impact validation for Replace Method w MethodObject

1 3 5a 7a 7b 8a L1 L2 L3 L4 L5

CBObef 47 18 51 66 34 15 13-t1 0 0 0 0 -2 -2 0 0 0 0 0+1 1

CBOaft 48 19 52 67 33 14 14 14 14 14 14CBO pred

√ √ √ √ √ √ √ √ √ √ √


Object w.r.t. CBO, stating that: CBOpred = CBObef + 1 - t1.

Table 11.16: The Data Abstraction Coupling value is predicted not to be af-fected by the Replace Method with Method Object refactoring. Accord-

ingly, for each refactoring candidate, the predicted value is equal to thevalue before refactoring.

Table 11.16: DAC impact validation for Replac e Method w MethodObject

1 3 5a 7a 7b 8a L1 L2 L3 L4 L5

DACbef 5 2 2 2 30 2 0 3 3 3 3DACaft ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼ ∼DAC pred

√ √ √ √ √ √ √ √ √ √ √

Validation of the prediction formula for the effect of Replace Method with

Method Object w.r.t. DAC, stating that: DACpred = DACbef .

Effect on cohesion metrics – Finally, we discuss the effect of ReplaceMethod with Method Object w.r.t. the two cohesion metrics:

Table 11.17: The Lack of Cohesion in Methods variant LCOM5 is specifiedto be increased proportionate to the number of sibling methods which




share sibling attribute references with the method to be replaced (t1).E.g., for Replace Method with Method Object candidate L3, we haveLCOM5 pred(cs) = LCOM5bef (cs) + t1 = .636+ 2

33 = .697 = LCOM5aft(cs).

Table 11.17: LCOM5 impact validation for Replace Method with Method Object

1 3 5a 7a 7b 8a L1 L2 L3 L4 L5

LCOM5bef .913 .972 .667 .998 .788 NaN .636

+t1 0 0 0 0 0 0233

133

233

133

233

LCOM5aft ∼ ∼ ∼ ∼ ∼ ∼ .697 .667 .697 .667 .697

LCOM5 pred

√ √ √ √ √ √ √ √ √ √ √

Application of the prediction formula for LCOM5 after refactoring, stating that LCOM5pred

=LCOM5bef + t1.

Table 11.18: Lastly, the prediction of the LCOM1 value after the applica-tion of Replace Method with Method Object dictates an increase by thenumber of sibling methods with which the method to be replaced sharessibling attribute references. As an example, for Replace Method with

Method Object candidate L5, we have LCOM1 pred(cs) = LCOM1bef (cs)+ t1 = 32 + 6 = 38 = LCOM1aft(cs).

Table 11.18: LCOM1 impact validation for Replace Method with MethodObject

1 3 5a 7a 7b 8a L1 L2 L3 L4 L5

LCOM1bef 312 168 15 230 70 98 32+t1 0 0 0 0 0 0 9 6 9 6 6

LCOM1aft ∼ ∼ ∼ ∼ ∼ ∼ 41 38 41 38 38LCOM1 pred√ √ √ √ √ √ √ √ √ √ √

Application of the prediction formula for LCOM1 after refactoring, stating that

LCOM1pred =LCOM1bef + t1.

Summarizing, the demonstrated application of the eleven selected ReplaceMethod with Method Object candidates corroborates the accuracy of impactTable 10.11.



11.3. THREATS TO VALIDITY 153


With regard to internal validity, a potential selection bias is present, as theauthor selected the refactoring candidates and performed the evaluation him-self. However, strict selection criteria were composed as to select a limited setof refactorings that vary with regard to values for the different terms in theprediction formulae. Accordingly, the accuracy of the effect prediction is testedunder different conditions, as present in a representative open-source softwaresystem (ArgoUML). Moreover, additional artificial refactoring candidates werecreated to test the accuracy of the prediction in those cases which are uncom-

mon in practice. Therefore, we do not consider the procedure for selection tobe a threat.

Evidently, a validation according to ten refactoring candidates cannot beconsidered a solid proof of the accuracy of the impact tables. There is indeedan inherent possibility that there does exist a refactoring candidate for whichthe predictions would not correspond to the actual value. However, aside thevalidation presented in this chapter, the stepwise formal derivation of the impacttables has been incorporated in Appendix B. This stepwise procedure followsthe principles of common mathematical refinements, which further reduces thelikelihood of errors made in the composition of the prediction formulae.

Theoretically, there is a possibility that the implementation of the metric toolused in the validation contained defects. However, standard software engineeringpractices were applied to test for such defects. Moreover, the implementation of the metric tool using a software structure representation identical to the meta-model in which the metrics themselves were formalized reduces the probabilityof defects.

With regard to external validity, we stress that the prediction formulae areonly stated to provide accurate results in case the applied refactoring corre-sponds to the pre- and postconditions specified in the previous chapter. In thevalidation, we demonstrated the application of an Extract Method candidatewhich deviates from this specification. In such cases, the prediction formulacannot be applied. However, in cases where the pre- and postconditions are infact satisfied, the formulae do consistently provide accurate results.

11.4 Conclusion

In this chapter, ten candidates were applied for each of the three selected refac-torings. The predicted effect corresponded to the actual change in metric values.




Accordingly, we state that the impact tables provide a valid prediction.The prediction formulae indicate the conditions under which a coupling or

cohesion metric will be increased or decreased. Moreover, the formulae also allowto calculate the exact value of this increase or decrease. Therefore, the formu-lae provide a-priori knowledge w.r.t. to the effect of the selected refactoringson the selected metrics. This knowledge can be used to filter those refactoringcandidates which do not satisfy the expectations of a maintainer, e.g., by re-quiring that coupling is reduced and cohesion is increased. The application of this a-priori knowledge will be demonstrated in the next chapter.



Chapter 12

Case Study: Move MethodVariant

In this chapter, we demonstrate the exploitation of a-priori knowledge w.r.t. theimpact of a refactoring on coupling and cohesion indicators. As an illustrativeexample, we elaborate a variant of the Move Method refactoring, and apply it

on the ArgoUML software system.

12.1 Introduction

The goals of the case study presented in this chapter are twofold:

• First, this case study demonstrates the exploitation of the impact tablesvalidated in the previous chapter to identify refinements (named variantsin the remainder of this chapter) of a refactoring. This refactoring variantattempts to optimize a set of quality indicators.

• Second, this case study assesses the applicability of the devised refactoringvariant, providing sufficient information as to allow the derivation of socalled patch refactorings which themselves are not directed towards opti-mizing quality attributes, but rather serve to fulfill the preconditions of refactorings that do.

Table 12.1 recapitulates the prediction formulae as mentioned in the impacttable for Move Method represented in Table 10.9. For each formula, the table

155



156 CHAPTER 12. CASE STUDY: MOVE METHOD VARIANT

describes the conditions under which the optimization of the coupling or co-hesion metric is optimal. These conditions are described by specifying whichterms to be minimized, and which to be maximized.

The optimization of coupling is achieved through a decrease to a minimalvalue, while the optimization of cohesion is achieved through an increase toa maximal value. However, as the selected cohesion metrics indicate lack of cohesion , their optimization is expressed in terms of a decrease.

The table is constituted by evaluating the signs (+ or -) of the different termsof each of the prediction formulae. In case a metric value is to be minimized,the terms to be maximized are those terms which contribute negatively to the

metric value after refactoring (terms with a sign -), and the terms to be mini-mized are those which contribute positively (terms with a sign +). In contrast,when the metric value is to be maximized, we maximize the terms contributingpositively, and minimize those contributing negatively. However, as none of thecoupling nor cohesion metrics are optimized by maximization, the latter case isnot illustrated.

Table 12.1: Move Method impact optimization table.

Prediction formulaOptimization conditionMaximize Minimize

MPC pred = MPCbef - t1 + t2 t1 t2OMMEC pred = OMMECbef - t1 + t2 t1 t2CBO pred = CBObef - t1 - t2 + t3 t1, t2 t3DAC pred = DACbef — —LCOM5 pred = t1.

LCOM5bef - t2

t2 t1

LCOM1 pred = LCOM1bef - t1 t1 —

Indication of which terms to maximize, and which to minimize in order to optimize

the coupling and cohesion metrics as affected by the Move Method refactoring.

Accordingly, to specify a Move Method variant that optimizes coupling andcohesion, we introduce additional conditions as specified in the second columnof Table 12.1.

12.2 Notation

To describe the Move Method variant, we present the specification of additionalconditions in a special notation. This notation was employed to specify the input



12.2. NOTATION 157

for a code generator. This code generator is entitled MotMot1. The authors of MotMot describe their tool as follows:

“MoTMoT stands for Model driven, Template based, Model Trans- former. It is a compiler from visual model transformations to repos-itory manipulation code. The compiler takes models conforming to a UML profile for Story Driven Modeling (SDM) as input and outputsJMI code.”

JMI2 is a specification that defines how metadata can be queried and ma-nipulated in the Java programming language. Accordingly, MotMot takes story diagrams as an input, and generates corresponding Java code which queries andmanipulates representations of software systems. The structure of this repre-sentation conforms to the meta-model presented in section 10.1.

Table 12.2 depicts the notation which is adhered to in this chapter, whenspecifying story diagrams as input for MotMot. A story diagram is described asan activity diagram consisting of states. State transitions, indicated by unidi-rectional arrows, indicate the state that is triggered after the current state iscompleted. The initial state represents the start of the story, and similarly, a final state represents the end of a story. A final state returns execution to thecontext in which the story was initiated. Between the initial and the final state,different types of states specify the type of activity performed in this state. Wedifferentiate between loop and code states.

Loop states trigger the collection of a set of tuples, consisting of instancesof entities and relations which satisfy a set of conditions. E.g., a loop statecan trigger the collection of classes implementing a given interface. The resultof this collection will provide tripples, consisting of the given interface, a classimplementing this interface, and the implementation relation between the in-terface and the class. Each time a tuple is found, the state transition labeled

each time indicates the state that is triggered. This state can be consideredas the loop body in traditional programming languages. Within this loop body,the instances of entities and relations within the result tuple can be read ormanipulated.

1MotMot was created through a collaboration between Pieter Van Gorp, Hans Schippersand Olaf Muliawan. For more information, visit http://www.fots.ua.ac.be/motmot

2http://java.sun.com/products/jmi/




Table 12.2: Story Driven Modeling (SDM) notation.

Type Explanation

State

statePurpose

Initial state

Final state

Loop state

<<loop>>

statePurpose

{jcmtg.constraint=constraintStatement,

jcmtg.transprimitive=NameOfTransformationPrimitive}

stateInsideLoop

stateAfterLoop

<<each time>>

Code state

<<code>>

statePurpose

Conditionalstate

stateInCaseConditionalIsFalsestateInCaseConditionalIsTrue

<<code>>

conditional

[condition] [!condition]

Comments

Note

Notations employed in the story diagrams described in this chapter.

Code states trigger the execution of a code statement. This code statementoperates on instances of entities and relations present in the context of the codestate. E.g., a code state can specify a print-statement which writes the valueof an entity to standard output. A conditional state can be used as a selector



12.3. SPECIFYING THE MOVE METHOD VARIANT 159

for the next state. Conditional states specify guards on the state transitionsdeparting from this state. A guard specifies a condition, which can be eithersatisfied or dissatisfied, and controls the state transitions departing from thecode state. Thus, a code state corresponds to an if-else statement in traditionalprogramming languages.

12.3 Specifying the Move Method Variant

Before specifying additional constraints that assure the optimization of coupling

and cohesion measures, we translate the pre- and postconditions of the generalMove Method refactoring to story diagrams.The Move Method refactoring moves a method from one class to another,

possibly adding a parameter when resources of the original classes are used.The precondition involves three model-element instances: (i) msrc, the method

to be moved; (ii) csrc, the source class; and (iii) ctrg , the target class.

• Figure 12.1 portrays the precondition w.r.t. relationship between themethod to be moved (msrc) and the class from which it will be moved(source class csrc). This condition represents part the precondition of theMove Method refactoring as presented in the previous chapter. The eight

states specified in the story diagram displayed in Figure 12.1 specify thatthe method to be moved . . .

1. . . . must not be a constructor.

2. . . . must be a public method, implemented by the source class.

3. . . . must not reference non-public sibling attributes.

4. . . . must not reference attributes of outer classes. This conditionmight occur in case the source class is an inner class.

5. . . . must not invoke non-public sibling methods.

6. . . . must not invoke methods of outer classes.7. . . . must not override a method implemented by its ancestors.

8. . . . must not be overridden by a method implemented by its descen-dants.

In case these eight negative conditions are satisfied, the precondition w.r.t.the relationship between the method to be moved and the source class issatisfied.




<<loop>>

Retrieve Reference to Outer Type Attribute

{jcmtg.transprimitive=retrieveOuterTypeAttrRef}

<<loop>>

Retrieve Reference to Non-Public Sibling Attribute

{jcmtg.transprimitive=retrieveNonPublicAttributeAccess}

<<loop>>

Retrieve Call to Outer Type Method

{jcmtg.transprimitive=retrieveOuterTypeMethodCall}

<<loop>>

Retrieve Call to Non-Public Sibling Method

{jcmtg.transprimitive=retrieveNonPublicMethodCall}

<<code>>Overrides a supertype method?

<<code>>

Is not a constructor?

<<code>>

Is public method?

<<code>>

Return false bis

<<code>>

Return -false-

<<code>>

Is overridden?

<<code>>

Return _false_

<<code>>

Return false

boolean isOverridden = !aMethod.getOverridingMethods().isEmpty();

boolean overrides = !aMethod.getOverriddenMethods().isEmpty();

TRUE

FALSE

[isOverridden]

[!isPublic]

[isConstructor]

[overrides]

[true]

[true]

[true]

[true]

<<each time>>

[false]

<<each time>>

[false]

<<each time>>

[false]

<<each time>>

[false]

[!isOverridden]

[!overrides]

[!isConstructor]

[isPublic]

Figure 12.1: Move Method source class precondition story diagram

• Figure 12.2 portrays the precondition w.r.t. relationship between themethod to be moved msrc and the class to which it will be moved (targetclass ctrg). This condition states that the target class must be editable(i.e., may not be a library class whose source code cannot be modified),and the target class hierarchy must not implement a method with a similar




signature.

<<code>>

Does the target class hierarchy implements a similar signature?

<<code>>

Is the target class editable?

be.ac.ua.lore.refactorings.PreconditionVerifier pv = new be.ac.ua.lore.refactorings.PreconditionVerifier();boolean classHierarchyImplementsSignature = pv.typeDeclaresSignature(aMethod, aClass).booleanValue()|| pv.typeInheritsMethodWithSimilarSignature(aMethod, aClass).booleanValue()|| pv.subHierarchyDeclaresMethodSignature(aMethod, aClass).booleanValue();

boolean isEditable =!(aClass instanceof MlibraryClass);

TRUE

FALSE

[!isEditable]

[isEditable]

[classHierarchyImplementsSignature]

[!classHierarchyImplementsSignature]

Figure 12.2: Move Method target class precondition story diagram

Together the story diagrams described in Figures 12.1 and 12.2 specify theprecondition of the Move Method refactoring specified in Chapter 10.

12.3.1 Refining the precondition

By specifying additional preconditions, we design a Move Method variant . Theprecondition of this variant is stricter then the precondition of the general MoveMethod refactoring. Accordingly, this variant can provide more specific guar-antees in its postcondition.

In Table 12.1, the conditions were specified under which the applicationof Move Method will optimize the value of the selected coupling and cohesionmetrics for the source class. We describe these conditions for each metric, inpreparation of the formulation of additional preconditions:




Message Passing Coupling: According to our prediction formula, the MPCmetric value is optimized in case the method to be moved contains manymethod invocations to other classes (quantified by term t1), and is prefer-ably not called by the other methods implemented in the source class.The latter condition is quantified by term t2.

Export Coupling: The OMMEC metric value is optimally effected in case themethod to be moved is called frequently by methods from other classes(t1), and preferably does not invoke other methods implemented in thesource class (quantified by t2).

Coupling Between Object classes: The CBO metric value is optimally re-duced when the method to be moved constitutes the only form of couplingwith many other classes (t1), and preferably also forms the only form of coupling with the target class (t2). Preferably, the method to be movedand the other methods of the source class should not invoke one another(t3).

Data Abstraction Coupling: As the DAC metric value is predicted not tobe affected, this metric value cannot be optimized using the Move Methodrefactoring.

Lack of Cohesion in Methods, normalized: The metric value of LCOM5is predicted to be optimized in case the method to be moved references veryfew, preferably none, of the sibling attributes of the source class (t2). Anoptimal reduction of the LCOM5 metric value is achieved when the MoveMethod refactoring is applied in a source class containing few methods,as the effect of the Move Method refactoring on LCOM5 is relative to thenumber of methods of the source class.

Lack of Cohesion in Methods, non-normalized: Moving methods whichshare very few, preferably none, attribute references with sibling meth-

ods from the source class (as quantified by t1) will optimize the reductionof the LCOM1 metric value.

These guidelines for optimizing the effect of Move Method on the selectedcoupling and cohesion metrics w.r.t. the source class can be summarized asfollows: (i) the method to be moved should be incohesive with the source class;and (ii) this method should encapsulate coupling to the source class. We specifythese two conditions in additional story diagrams, which can be considered as




qualitative preconditions, in that they specify the preconditions under whichcoupling and cohesion will be optimized:

• Figure 12.3 specifies an additional qualitiative precondition. This condi-tion specifies that the method to be moved should be incohesive with thesource class. The states in the story diagram therefore describe that . . .

1. . . . the other methods of the source class must not be invoked by themethod to be moved.

2. . . . the attributes of the source class must not be referenced by themethod to be moved.

3. . . . the other methods of the source class must not invoke the methodto be moved.

• Figure 12.4 specifies a second additional qualitative precondition. Thiscondition specifies that the method to be moved should encapsulate cou-pling to the target class, using states specifying negative conditions. Thesenegative conditions specify that . . .

1. . . . other methods implemented by the source class must neither in-voke methods of the target class, be invoked by methods from thetarget class, nor reference attributes of the target class.

2. . . . attributes implemented by the source class must not be referencedby methods of the target class.

In case these additional qualitative preconditions are satisfied, the MoveMethod variant will guarantee additional qualitative postconditions, discussedin the next subsection.

12.3.2 Resulting qualitative postcondition

The additional qualitative preconditions specified in the previous subsectionstimulate the optimization of the selected coupling and cohesion metrics. Thisoptimization guarantees to optimize particular terms in the prediction formulaefor the metric values, described in Table 12.3. The terms which are guaranteedto be zero are those terms advised in Table 12.1 to be minimized. The termsare guaranteed to be non-zero are those terms advised to be maximized.




<<loop>>

Retrieve called public method of class

{jcmtg.transprimitive=retrieveStaticallyInvokedPublicMethod,

jcmtg.constraint=publicMethod != aMethod}

<<loop>>

Retrieve called method from superHierarchy of class

{jcmtg.transprimitive=retrieveCalledSuperHierarchyMethod,

jcmtg.constraint=(methodCalled != aMethod)

&&(pv.subHierarchyContains(aType, aClass)).booleanValue()}

<<loop>>

Retrieve referenced public attribute of class

{jcmtg.transprimitive=retrieveReferencedPublicAttribute}

{jcmtg.transprimitive=retrieveCallerMethodFromClass,

jcmtg.constraint=callerMethod != aMethod}

<<loop>>

Retrieve caller-method from class

<<code>>

Prepare PreconditionVerifier

<<code>>

Return false quattro

<<code>>

Return false tris

<<code>>

Return false bis

<<code>>

Return false

TRUE

FALSE

[true]

[true]

[false]

<<each time>>

[false]

<<each time>>

[false]

<<each time>>

[false]

<<each time>>

[true]

[true]

Figure 12.3: Qualitative precondition on msrc and csrc

Accordingly, we can substitute these fixed values to refine the effect of theMove Method variant. Table 12.4 describes the impact table of the MoveMethod variant presented in this chapter. Terms which are guaranteed to bezero by the Move Method variant are left out, and in prediction formulae forwhich fixed valued terms can be guaranteed (e.g., CBO and LCOM1), these




<<loop>>

Retrieve Reference from targetClass

{jcmtg.transprimitive=retrieveReferenceFromTargetClass}

<<loop>>

Retrieve Reference to targetClass

{jcmtg.transprimitive=retrieveReferenceToTargetClass}

<<loop>>

Retrieve Sibling Method

{jcmtg.transprimitive=retrieveSiblingMethod,

jcmtg.constraint=!siblingMethod.equals(aMethod)}

<<loop>>

Retrieve Call from targetClass

{jcmtg.transprimitive=retrieveCallFromTargetClass}

<<loop>>

Retrieve Call to targetClass

{jcmtg.transprimitive=retrieveCallToTargetClass}

<<loop>>

Retrieve Sibling Attributes

{jcmtg.transprimitive=retrieveSiblingAttribute}

<<code>>

Initialize a Query Engine

<<code>>

Return false quattro

<<code>>

Return false tris

<<code>>

Return false bis

<<code>>

Return false

TRUE

FALSE

<<failure>>

[true]

[true]

[true]

<<each time>>

<<each time>>

[true]

<<each time>>

[false]

[false]

<<each time>>

[false]

<<each time>>

<<success>>

[false]

<<each time>>

Figure 12.4: Qualitative precondition on msrc and ctrg

terms are substituted by their fixed value.

Table 12.3: Move Method variant effect description.

Prediction formula Fixed term values

MPC pred = MPCbef - t1 + t2 t2 = 0OMMEC pred = OMMECbef - t1 + t2 t2 = 0CBO pred = CBObef - t1 - t2 + t3 t2 = 1, t3 = 0DAC pred = DACbef —

LCOM5 pred = t1.

LCOM5bef - t2

—LCOM1 pred = LCOM1bef - t1 t1 =

| M I (cs) | −1

Specification of the fixed values guaranteed by the two additional qualitative

preconditions for the Move Method variant.

Once again, we stress that the prediction formulae in this table only applyin case both the preconditions of the general Move Method refactoring and thetwo additional qualitative preconditions are satisfied.




Table 12.4: Impact table for the Move Method variant.

Prediction formula

MPC pred(cs) = MPCbef (cs) - t1with t1 =


NSI (m, m2)

OMMEC pred(cs) = OMMECbef (cs) - t1with t1 =

c2∈Others(cs)

m1∈M I(c2)

NSI (m1, m)

CBO pred(cs) = CBObef (cs) - t1 - 1

with t1 = x

∈ C

\ {cs, ct

} | uses(m, x)

∨ ∃md

∈M I (x) : m

∈P IM (md)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x) ∧

∀md ∈ M I (x) :

(M I (cs) \ {m}) ∩ P IM (md)

∪(AI (cs) ∩ AR(md))

= ∅


LCOM5 pred(cs) = t1.

LCOM5bef (c) - t2

with t1 = |M I(c)|−1|M I(c)|−2

t2 = |AI(cs)\AR(m)|

|AI(cs)|.

|M I(cs)|−1

LCOM1 pred(c) = LCOM1bef (c) - t1with t1 =m1 | m1 ∈

M I (cs) \ {m} ∧m1 = m∧AR(m1) ∩ AR(m) ∩ AI (cs)

= ∅

Formal description of the effect of applying Move Method variant on the value of metrics of the

source class.

Table 12.4 thus predicts that the (aggregated) import and export couplingmetrics will either remain unchanged or decrease, and similar for the lack of cohesion. Moreover, the Coupling Between Object classes metric, indicative forgeneral coupling, is guaranteed to be decreased with at least 1.

12.4 Data Collection

In this section, we collect data to verify two criteria required for a useful refac-toring variant. First, a refactoring variant should indeed optimize the couplingand cohesion metrics. Second, a refactoring variant should not be too artificialas to be inapplicable in realistic software systems.

Accordingly, we first validate the accuracy of the impact table for the Move



12.4. DATA COLLECTION 167

Method variant. Subsequently, we analyse the applicability of the Move Methodvariant on ArgoUML.

12.4.1 Validating predicted impacts

To validate the accuracy of the impact table of the described Move Methodvariant (see Table 12.4), we reuse four refactoring candidates presented in thevalidation of the general Move Method refactoring in Chapter 11. These candi-dates were selected to satisfy the additional qualitative preconditions which theMove Method variant requires. Therefore, these candidates are also candidates

for the Move Method variant.

Table 12.5: Variant impact validation.

Metric Predicted term valueValue for candidate124 71 155 163

MPC pred t2 = 0√ √ √ √

OMMEC pred t2 = 0√ √ √ √

CBO pred t2 = 1√ √ √ √

t3 = 0√ √ √ √

DAC pred —LCOM5 pred —LCOM1 pred t1 =

| M I (cs) | −1 √ √ √ √

Validation of the prediction formula for the effect of the Move Method variant w.r.t.

the fixed terms in the prediction formulae.

Table 12.5 illustrates the value of the terms predicted to have a fixed valueby the impact table for the Move Method variant (see Table 12.4). In casethe value of a term, as calculated for a particular Move Method refactoringcandidate, is equal to the predicted term value, this is indicated using a check

mark (√).The table confirms that the terms predicted by the impact table for the Move

Method variant (Table 12.4) to have a fixed value do indeed have the predictedvalue. E.g., for Move Method refactoring candidate 155, we observe that theactual value of term t2, as mentioned in the prediction formula for CBO, equalsthe fixed value 1, as predicted.

Thus, we summarize that the Move Method variant presented in this chapterindeed optimizes the selected coupling and cohesion metrics.




12.4.2 Applicability of the Move Method variant

0

0.2

0.4

0.6

0.8

1

1160 1180 1200 1220 1240 1260 1280 1300 1320 1340 1360

R a t i o

Classes

Ratio of Move Method candidates per class

(1) m_src and c_src(2) 1 and m_src and c_trg

(3) 2 and qualPre m_src and c_trg(4) 3 and qualPre m_src and c_src

Figure 12.5: Move Method variant applicability in ArgoUML v0.19.8

The optimization of coupling and cohesion metrics as guaranteed by theMove Method variant presented in this chapter can be exploited in two ways:

• In case a considerable number of refactoring candidates satisfying the ad-

ditional preconditions of the refactoring variant can be detected, the refac-toring variant can be considered useful to optimize coupling and cohesionmetrics.

• In contrast, if only a very limited number of refactoring candidates canbe detected, there are few cases in which the refactoring variant can beexploited. Accordingly, if this is the case, it is interesting to verify whichpatch refactorings can be applied to manipulate the satisfaction of thepreconditions of the refactoring variant.



12.4. DATA COLLECTION 169

Figure 12.5 illustrates the degree to which refactoring candidates can befound that satisfy each of the preconditions of the Move Method variant dis-cussed in this chapter. The X-axis represents the set of classes present inArgoUML v0.19.8, containing a total of 1362 classes. The Y-axis representsthe ratio of methods in a class that satisfies the (set of ) precondition(s). I.e.,in case all the methods of a class satisfying the (set of) precondition(s) of theMove Method variant, the Y-value will be 1. Similarly, in case only half of themethods of a class satisfying the (set of) precondition(s), the Y-value will be0.5.

Each line represented in Figure 12.5 indicates a precondition, as explained

by the legend. The earlier the line rises on the Y-axis, the more classes weredetected containing at least one method satisfying the associated preconditions.The conditions associated with each of the lines are discussed in the followingoverview:

First line: The first line represents the ratio of methods satisfying the pre-condition specified in the story diagram illustrated in Figure 12.1. Thiscondition describes the required relationship between the method to bemoved and the class from which it will be moved.

In ArgoUML v0.19.8, 168 candidates are detected to satisfy this condition,

representing 12.3% of the classes.

Second line: The second line represents the ratio of methods satisfying twoconditions. First, the condition specified in the first line is required, andadditionaly, the precondition specified in the story diagram illustrated inFigure 12.2 is required to be satisfied. The latter condition dictates therequired relationship between the method to be moved and the class towhich the method will be moved. Thus, the second line quantifies thenumber of classes on which the general Move Method refactoring can beapplied, as specified in Chapter 10.

98 Classes, or 7.2% of all classes, satisfy this condition. Accordingly, abouthalf of the classes satisfying the condition represented in the first line con-tain at least one method satisfying the general Move Method precondition.

Third line: The third line again represents an additional condition, which isto be combined with the conditions indicated by the first two lines. Theadditional condition is specified in the story diagram depicted in Figure12.3, specifying that the method to be moved should be incohesive withthe method from which it will be moved.




The number of classes satisfying this condition is 47, constituting 3.5%of the classes. This means that for about half of the classes in which thegeneral Move Method refactoring variant can be applied, at least one of the methods in these classes is incohesive.

Fourth line: The fourth line requires the complete precondition of the MoveMethod variant to be satisfied. Additionally to the requirements of thethird line, this condition requires that the method to be moved encapsu-lates coupling to the target class, as illustrated in the story diagram inFigure 12.4.

9 Classes satisfy the condition specified in this condition, encounting formerely 0.7% of the classes in ArgoUML v0.19.8. Thus, we observe that,for ArgoUML v0.19.8, the Move Method variant presented in this chaptercan be applied on merely one tenth of the classes in which the generalMove Method refactoring can be applied.

Accordingly, this observation leads us to assume that the presented MoveMethod variant is ten times less applicable then the general Move Method refac-toring. If this assumption is correct, then for nine out of ten Move Methodcandidates, the selected coupling and cohesion metrics will not be optimized incase the Move Method refactoring is actually applied.


The observation of the poor applicability of the Move Method variant suggeststhat there is indeed a need for patch refactorings which prepare the applicationof the Move Method variant. The availability of such patch refactorings couldpotentially support the exploitation of coupling and cohesion improvements forconsiderably (potentially 9 times) more Move Method candidates.

Nonetheless, our results also demonstrate that, in case the preconditions of

the Move Method variant are in fact satisfied, the optimization of the selectedcoupling and cohesion metrics do occur.

12.6 Conclusion

In this chapter, we have exploited the predicted effect of the Move Methodrefactoring on coupling and cohesion metrics to refine a Move Method variant.The claim that this Move Method variant optimizes the selected coupling and



12.6. CONCLUSION 171

cohesion metrics has been validated. However, through a detection of classessatisfying the additional preconditions required by the Move Method variant, ina representative software system (ArgoUML v0.19.8), we observe that the MoveMethod variant is rarely applicable.

The main conclusion of this chapter is that it is indeed possible to deviserefactoring variants which improve internal program quality metrics. However,these refactoring variants can not frequently be applied. We hypothesize thatthe lack of application candidates can be addressed using refactorings that ma-nipulate the source code as to satisfy the preconditions of the refactoring vari-ant. Thus, this conclusion suggests that it is interesting to also investigate

refactorings that themselves do not improve quality as indicated by couplingand cohesion metrics, yet serve as stepstones towards quality improvement.



Chapter 13

Summary

In this chapter, we summarize the findings with regard to the investigation of coupling and cohesion improvements by refactoring. Subsequently, we describethe limitations of this research approach, and enlist the lessons learned this partof the dissertation.

13.1 Findings

In this part of the thesis, we evaluated the effect of three selected refactoringson indicative metrics of coupling and cohesion. Our analysis demonstrated thatthe impact of the selected refactorings on either coupling or cohesion was non-trivial. I.e., it is infeasible to generalize that any application of a refactoringeither improves or impaires one of these internal quality characteristics.

Accordingly, instead of stating that a refactoring has a partical impact on ametric, we found that, more often than not, the effect of a refactoring on a metricis described by an impact spectrum . An impact spectrum limits the impact on a

metric within particular boundaries. These boundaries can be both narrow andwide. An example of a narrow impact spectrum is a description which predictsthat a metric will be increased or remain unchanged, but cannot decrease. Incontrast, a wide impact spectrum states that a metric might be increased orremain unchanged, yet might also be decreased. Thus, the concept of an impactspectrum clarifies that the particular impact of the refactoring will depend onthe context in which the refactoring is applied.

The impact spectrum, describing the effect of a refactoring on a metric, is

173




formalized as a prediction formula. This prediction formula specifies differentterms which are added or subtracted from the value of the metric before refac-toring. Each of these terms is specified as the cardinality of the resultset of aquery on the context in which the refactoring is applied. I.e., the conditionsexpressed in this query specify under which conditions the term will have aparticular value.

As an example, let us consider the effect of the Move Method refactoring onthe Message Passing Coupling (MPC) metric. The impact spectrum for MPCis defined as:

MPC pred(cs) = MPCbef (cs) - t1 + t2with t1 =


NSI (m, m2)

and t2 =


This impact spectrum specifies that the Move Method refactoring can eitherimprove or impair the MPC value, specified respectively by terms t1 and t2.When we investigate one of these terms, say t1, we observe that it states theconditions under which the MPC value will be decreased, and that it additionalspecifies the extent of this decrease. In this example, term t1 states that, incase method m invokes methods implemented by classes other than cs, then the

MPC value will be decreased with the number of these method invocations.These prediction formulae thus specify the conditions required for a partic-ular effect to occur (e.g., a decrease of the MPC value). We call this knowledgea-priori knowledge on the effect of a refactoring, as it allows to predict theoutcome of applying a refactoring before it has been applied.

In the last chapter, we have demonstrated the exploitation of such a-prioriknowledge by refining the associated refactoring. This refinement narrows downthe set of conditions under which the refactoring will have an optimal effect. Inthe case of an effect specified in terms of coupling and cohesion, an optimal effectis achieved when coupling is minimized and cohesion is maximized. Therefore,we specify additional preconditions, which, for the same refactoring, allow to

guarantee additional postconditions. These extended pre- and postconditionsdefine a variant of the more general refactoring. The additional postconditionsof this refactoring variant are of a qualitative nature, in that they specify theimpact on coupling and cohesion as a narrow impact spectrum. In other words,while the general refactoring specifies a wide interval of potential effects (e.g., aMPC metric value change specified in the interval ]−∞,+∞[), the refactoringvariant specifies a narrow interval of potential effects (e.g., a MPC metric valuespecified in the interval ]−∞,0]). Thus, the exploitation of a-priori knowledge



13.2. LIMITATIONS 175

allows to specify refactoring variants which optimize internal quality character-istics.

A drawback of these refactoring variants is that they are inherently less ap-plicable than the general refactoring which they refine. This calls out for thedefinition of so called patch refactorings, which themselves do not address theoptimization of quality characteristics. However, these patch refactorings serveto prepare for the application of a refactoring variant. I.e., the postcondition of such patch refactorings corresponds to the precondition of the refactoring vari-ant, thereby assuring the applicability of the refactoring variant. Accordingly,the concept of patch refactorings theoretically enable the improvement of the

applicability of a quality optimizing refactoring variant.

13.2 Limitations

The derivation of a-priori knowledge is limited by the expressive power of themeta-model used to formalize the studied refactorings. Evidently, if the meta-model does not allow to express the presence of an entity or a relation betweenentities (e.g., Exceptions or the throwing of exceptions by a method), it isinfeasible to express metrics regarding this entity or these relations (e.g., thenumber of exceptions thrown by a method), and it is equally infeasible to predict

the effect of any refactoring on such a metric. Accordingly, our approach topredicting the impact of a refactoring on a quality characteristic is limited bythe expressiveness of the meta-model.

A more pragmatic limitation is the effort required to apply the impact deriva-tion process explained in Appendix B. This required effort is mostly determinedby the complexity of the postcondition of the refactoring, and of the complexityof the formalization of the metric. I.e., if the metric refers to many differ-ent analysis functions (e.g., the set of methods implemented by a class) andthe postcondition specifies changes to many different analysis functions, then alarge number of substitutions will have to be applied in order to relate the value

of the metric after refactoring to the value of the metric before refactoring.



Chapter 14

Further Work

This chapter describes interesting continuations of the research proposed in thisthesis.

14.1 Extensions

In this thesis, we have restricted our attention in two ways. First, we havedemarcated the set of quality characteristics to coupling and cohesion. Accord-ingly, the impact tables specified in this thesis do not provide information w.r.t.other relevant quality characteristics as complexity. We therefore do not claimour refined Move Method variant to optimize quality in general, yet restrict itsguarantees to the selected set of metrics.

In case other quality characteristics, such as complexity, are incorporatedin the impact specification, one could investigate the potential trade-offs whichare inherent to any optimization problem. E.g., it is theoretically possible thatimprovements in coupling and cohesion tend to impair complexity. These com-

plex relationships among quality characteristics can be investigated using theimpact derivation process presented in this thesis.

Second, we have selected a small set of refactorings. Accordingly, we canprovide no claims about the effect of other refactorings, e.g., Extract Class, onthe selected coupling and cohesion metrics. However, in the introduction of thisthesis, we indicated that it is possible to compose the lower level refactoringsas studied in this thesis (e.g., Extract Method and Move Method). It has beenshown that the postconditions of these compositions can be derived from the set

177



178 CHAPTER 14. FURTHER WORK

of postconditions of the constituting refactorings [O Cinneide, 2001]. Thus, itwould be interesting to verify to which extent the impact specifications of theseconstituting refactorings can be reused in the impact derivation process for thecomposite refactoring.

14.2 Tool Integration

We envision the application of the results of this research in three differentscenario’s:

1. A maintainer might desire to optimize a set of quality characteristics.However, it is non-trivial to assess how to improve these quality char-acteristics while preserving the behavior of the existing software system.Accordingly, an advanced refactoring tool could evaluate the preconditionsof a set of refactoring variants, and present a list of refactoring candidatesfor which the tool can guarantee that these will improve the desired qualitycharacteristics.

2. A code smell refers to a structural property of part of a software system,which is known to be undesireable in certain circumstances. Code smell

detectors (e.g., PMD1) allow to quantify the presence of code smells, andare used to assess the degree to which a software system exhibits theseundesireable characteristics.

The precondition of a quality characteristic optimizing refactoring variantcan be regarded as a code smell. I.e., this precondition expresses thecondition in which a more optimal software solution can be formed. As itis mostly undesireable to have a sub-optimal solution, the availability of acode smell detector that quantifies the number of refactoring candidatescan allow to assess the extent to which the current software system deviatesfrom its optimal form. Evidently, optimal has to be considered relative

w.r.t. the quality characteristics incorporated in the postcondition of therefactoring variant.

3. In the introduction, we described an alternative research approach forcomposing guidelines on how to apply refactorings in order to improvequality characteristics. We termed this alternative approach the brute force method , as it consists of exploring all alternative solutions for a given

1http://pmd.sourceforge.net



14.2. TOOL INTEGRATION 179

software design until a (local or global) optimum is found. Accordingly,this approach consideres the optimization of quality attributes to be asearch problem, in which each step is defined as the application of a singlerefactoring. This approach is advocated in [Seng et al., 2005].

A pragmatic limitation of this search based quality optimization approachis the lack of a-priori knowledge with regard to the effect of progressing asingle step, i.e., of applying a refactoring. This lack of knowledge requiresto perform each step, and backtracking in case the step turned out to beundesireable. However, this a-priori knowledge is exactly what the impacttables presented in this thesis provide. Therefore, the application of theimpact tables proposed in this research into the search based approach canprovide a lookahead . This lookahead can predict the outcome of a seriesof steps, without the need for applying them physically. Accordingly, theintegration of the results of this research into the search based approachcan theoretically reduce the time required to achieve a (local or global)optimum.



180 CHAPTER 14. FURTHER WORK



Chapter 15

Conclusions

In this chapter, we present our conclusions w.r.t. the study of quality improve-ments by refactoring. Our study was comprised of two parts, focusing respec-tively on program comprehension and coupling and cohesion improvements. Adiscussion of our contributions w.r.t. the evaluation of program comprehensionimprovements by refactoring was discussed in Chapter 8. For a summary of the

results of our research w.r.t. coupling and cohesion improvements, we refer toChapter 13.

15.1 Conclusions

The research presented in this dissertation targeted the validation of commonclaims about the effect of refactoring on software quality. Accordingly, we dis-cuss our conclusions in terms of the confirmation or refutation of these claims.

15.1.1 Program Comprehension ImprovementsOne of the claimed benefits of refactoring has been that it “makes softwareeasier to understand ” [Fowler, 1999]. This support has been previously clarifiedto be provided in two ways. First, one can physically apply refactorings toreflect hypotheses about the purpose of the code, and second, one can applyrefactoring to make the code better communicate its purpose.

We conclude that these claimed benefits can indeed occur. In fact, we val-idated two patterns, Refactor to Understand and Split Up God Class, both

181



182 CHAPTER 15. CONCLUSIONS

introduced by [Demeyer et al., 2002]. We have observed that these patterns re-spectively support the construction of a mental representation during bottom-upcomprehension, and the discovery of relations between the source code and theproblem domain during top-down comprehension. These observations therebyclearly confirm the claim that refactoring can be used to make software easierto understand.

15.1.2 Coupling and Cohesion Improvements

Another claimed benefit of refactoring has been to “improve the design of soft-

ware“, by redistributing parts of the code to the “right” places [Fowler, 1999].Our initial assumption, that refactoring can both improve and impair softwaredesign, has been confirmed through a formal analysis of the effect of refactor-ings on coupling and cohesion as criteria to quantify design quality. Our analysisclarifies how a selected set of refactorings can be used to optimize coupling andcohesion, yet also indicates that, more often than not, these quality character-istics are not at all improved by the application of a refactoring. Therefore, werefined under which conditions these refactorings can indeed improve the designof software.

15.1.3 General ConclusionsWe conclude that, in particular circumstances, refactoring can indeed be usedto improve software quality. However, more research is needed on guidelinesthat clarify the context in which a refactoring is best applied, discuss the trade-offs which are inherent to any optimization problem, and guide the process of applying refactorings by distinguishing essential and optional steps.



Appendix A

Experimental Material

In this chapter, we publish the post-experiment questionnaire used in the con-trolled experiment described in Chapter 5.

A.1 Refactor to Understand

At the end of the Refactor to Understand experiment, a questionnaire washanded out, which was an adaptation from [Briand et al., 2001]. Closed ques-tions were asked about motivation, adherence to guidelines, understanding of requirements, approach to answering the questions, accuracy estimation, reasonsfor not completing, code quality estimate and perceived difficulty of questionson the three tasks. The questionnaire consists of two pages. Figure A.1 depictsthe first page, and Figure A.2 the second.

183



184 APPENDIX A. EXPERIMENTAL MATERIAL

[email protected] SRe2LIC study 29/03/2004

Motivation and performance debriefing questionnaire

The information you provide in this questionnaire may be very valuable to us.

Please answer each question as honestly as you can. Anything you write down willbe treated confidentially. Thank you.

Your name: _________________________________________________________

1. Estimate how motivated you were to perform well in the study.

Not Poorly Fairly Well Highly

1 2 3 4 5

2. Estimate how rigorous you adhered to the comprehension techniqueguidelines:

a. Read to Understand: no writing in the source codeb. Refactor to Understand: no beautification

Not adhered to Not always adhered to Rigorously adhered to

1 2 3

3. Estimate how well you understood what was required of you.

Not Poorly Fairly Well Highly

1 2 3 4 5

4. What approach did you adopt when receiving the questions?(tick only once)

Re-read the code while thinking about the tasks

Straight into the tasks, re-reading the code as required Straight into the tasks, not re-reading the code

Other – please specify: _________________________________________

___________________________________________________________

5. Estimate the accuracy (in %) of your answers.

0 - 20 21 - 40 41 - 60 61 - 80 81 - 100

1 2 3 4 5

Figure A.1: Page 1 of the debriefing questionnaire



A.1. REFACTOR TO UNDERSTAND 185

[email protected] SRe2LIC study 29/03/2004

6. If you could not complete all the tasks, please indicate why.(tick only once)

Ran out of time

Did not fully understand the task Did not fully understand the code Other – please specify: _________________________________________

___________________________________________________________

7. On a scale of 1 to 10 estimate, in terms of comprehensibility, thequality of the code to which the tasks referred.(1 – barely comprehensible; 10 – easily comprehensible)

Please specify your estimate number: _________

8. Estimate the difficulty of the questions of Task 1 on methodSearchPattern::createMethodPattern.

Too difficult Quite difficult Fairly solvable Quite easy Too easy

1 2 3 4 5

9. Estimate the difficulty of the questions of Task 2 on method

IndexAllPattern::execute.


1 2 3 4 5

10. Estimate the difficulty of the questions of final Task 3 on methodSurroundWithTryCatchRefactoring::addEdits.


1 2 3 4 5

11. Having performed the tasks, would you do anything differentnext time around?

Please specify : _________________________________________________

12. Any additional comments?

Thanks once again.

Figure A.2: Page 2 of the debriefing questionnaire



186 APPENDIX A. EXPERIMENTAL MATERIAL



Appendix B

Formal Impact Derivation

In this appendix chapter, we present the impact derivation of the selected refac-torings Extract Method, Move Method and Replace Method with Method Ob-

ject. This derivation results in impact tables that specify their effect on a se-lected set of coupling and cohesion metrics. These impact tables were presentedin Chapter 10 and validated in Chapter 11. Their application is demonstrated inChapter 12, where these tables were used to refine the Move Method refactoringto a form which optimizes coupling and cohesion.

B.1 Introduction

In this appendix, we do not recapitulate the pre- and postconditions of the

refactorings. For these formal descriptions, we refer to Chapter 10.The notation adhered to in the impact derivation process is the same nota-

tion used for the specification of the postcondition of each of the refactorings inChapter 10, which is similar to the one in [Roberts, 1999]. When a predicateof entities or relations is provided, the value of this predicate always refers tothe value before applying the refactoring. E.g., we refer to the set of methodsimplemented by a class c before refactoring as M I (c). In contrast, to refer to thevalue of a predicate after applying the refactoring, we write an accent behind

187



188 APPENDIX B. FORMAL IMPACT DERIVATION

the predicate. E.g., we refer to the set of methods implemented by a class cafter refactoring as M I (c).

The derivation proces proceeds according to the following steps. First, theformalization of the metric value is adapted as to reflect the state after therefactoring is applied. This adaptation requires the replacement of all predicatesused in the formalization of the metric by their postcondition equivalents. I.e.,if a metric formalization would be defined as | M I (c) |, it would be adapted to| M I (c) |, in which M I (c) signifies the number of methods implemented by classc before refactoring and M I (c) represents the number of methods implementedby c after refactoring.

Second, as the postcondition of each refactoring expresses the value of thepredicates in terms of their values before refactoring, we can substitute eachpostcondition predicate. E.g., if the postcondition specified that M I (c) =M I (c)\{ms}, then we substitute references to M I (c) by

M I (c)\{ms}

. These

substitutions are performed iteratively, and constitute the main part of thederivation process.

Once all the postcondition predicates are substituted, we rewrite the result-ing formula until we can relate it to the metric formalization before applyingthe refactoring.

Example – Let us consider the hypothetical case of a metric entitled Number of Methods (NOM), which is defined on a class c as NOM (c) =| M I (c) |. Ac-cordingly, to reflect the value of the metric Number of Methods after refactoring,we adapt the formula to:

NOM (c) =| M I (c) |Let us now consider a refactoring RemoveMethod(C c, M m), which is de-

fined by the following pre- and postcondition:

Precondition: m ∈ M I (c)

Postcondition: M I (c) = M I (c) \ {ms}

To derive the impact of the refactoring RemoveMethod on the metric Num-ber of Methods, we then substitute the predicates used in the metric formulawith their postcondition equivalent as dictated by the postcondition of the refac-toring. Accordingly, we substitute M I (c) by

M I (c) \ {ms}

, which provides:

NOM (c) =M I (c) \ {ms}



B.2. EXTRACT METHOD 189

At this moment, all the postcondition predicates are substituted. Thus, wetry to rewrite the resulting formula until we can relate it to the metric for-malization before applying the refactoring. Accordingly, we attempt to relateNOM (c) to | M I (c) |. This is performed through rewrite rules based on prin-ciples from set theory.

One of these principles states that, for two sets A and B, with B ⊆ A, wehave: | A \ B |=| A | − | B |. As the precondition of the RemoveMethod refac-toring tells us that m ∈ M I (c), we know that {m} ⊆ M I (c), and therefore, therewrite rule is applicable. Accordingly, we can rewrite the Number of Methodsmetric value after refactoring to:

N OM (c) =| M I (c) | − | {m} |Since the definition of NOM states that N OM (c) =| M I (c) |, we can relate

this expression to NOM (c) as follows:

N OM (c) = N OM (c)− | {m} |Finally, since the cardinality of a set containing only a single element is 1,

we can rewrite this to:

N OM (c) = N OM (c)−

1

This example illustrates the derivation process which is applied to derive theimpact of the three selected refactorings (Extract Method, Move Method andReplace Method with Method Object) on the selected coupling and cohesionmetrics.

B.2 Extract Method

In Chapter 10, the signature of the Extract Method refactoring was specifiedas:

ExtractMethod

C c,M ms,P(MI ) I,P(AT R) A

for which:

• c is the class in which the method is to be extracted;

• ms is the method from which the statements will be extracted;




• I ∪A characterizes the set of statements S that will be extracted. I repre-sents the set of method invocations, and A represents the set of attributereferences.

These arguments for the Extract Method signature are used in the followingimpact derivation.

B.2.1 Import Coupling

We can express the value of the Message Passing Coupling metric after applyingthe Extract Method refactoring as:

MP C (c) =

m1∈M I(c)

m2∈SIM (m1)\M

I(c) NSI (m1, m2)

Since M I (c) = M I (c) ∪ {mt}, we have:

=

m1∈M I(c)∪{mt}

m2∈SIM (m1)\

M I(c)∪{mt}

NSI (m1, m2)

When we split the first term we have:

=

m1∈M I(c)m2∈SIM (m1)\M I(c)∪{mt}NSI (m1, m2)

+

m2∈SIM (mt)\M I(c)∪{mt}

NSI (mt, m2)

Since A \ (B ∪ C ) = (A \ B) \ A ∩ (C \ B)

, we can rewrite the first term:

=

m1∈M I(c)

m2∈

SIM (m1)\M I(c)

\SIM (ms)∩({mt}\M I (c))

NSI (m1, m2)

+


NSI (mt, m2)

Since {mt} ∈ M I (c) ∧ {mt} ∈ SI M (ms), we can rewrite the first term asfollows:

=

m1∈M I(c)


\{mt} NSI

(m1, m2)+


NSI (mt, m2)

We can then split the first term using

x∈A\B f (x) =

x∈A f (x)−x∈A∩B f (x):

=

m1∈M I(c)


NSI (m1, m2)

−m1∈M I(c)

NSI (m1, mt)

+


NSI (mt, m2)




Since M I (c) =

M I (c) \{ms}∪{ms}, we can rewrite the first and second term

as follows:

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+

m2∈SIM (ms)\M I(c)NSI (ms, m2)

−m1∈M I(c)\{ms}

NSI (m1, mt)

−NSI (ms, mt)+

m2∈SIM (mt)\M I (c)∪{mt}

NSI (mt, m2)

Since

• ∀m1 ∈ M I (c) \ {ms} : mt ∈ M I (m1)

• N SI (ms, mt) = 1

we can simplify to:

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+


− 0 − 1 +


NSI (mt, m2)

Since ∀m1 ∈ M I (c) \ {ms} : SI M (m1) = SI M (m1) ∧∀m2 ∈ SI M (m1) :NSI (m1, m2) = NSI (m1, m2), we have:

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+


− 0 − 1 +


NSI (mt, m2)

SinceSI M (ms) =

SI M (ms)\m1 ∈ SI M (ms) |∃mi ∈

MI (ms)\I

: target(mi) =

m1 ∪ {mt}, we can rewrite the second term as follows:

M P C (c) =

m1∈M I(c)\{ms}

m2∈SIM (m1)\M I (c)

NSI (m1, m2)

+

m2∈

SIM (ms)\

m1∈SIM (ms)|∃mi∈

MI (ms)\I

:target(mi)=m1

∪{mt}

\M I(c)

N SI (ms, m2)− 0 − 1 +

m2∈SIM (mt)\

M I(c)∪{mt}

NSI (mt, m2)

And since mt ∈ M I (c), we have:




=

m1∈M I(c)\{ms}


NSI (m1, m2)

+

m2∈SIM (ms)\


MI (ms)\I

:target(mi)=m1

\M I(c)

NSI (ms, m2)

+ NSI (ms, mt)− 0 − 1 +

m2∈SIM (mt)\

M I(c)∪{mt}

N SI (mt, m2)

Since NSI (ms, mt) = 1, we have:

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+

m2∈SIM (ms)\


MI (ms)\I

:target(mi)=m1\M I(c)

NSI (ms, m2)

+ 1 − 0 − 1 +


N SI

(mt, m2)

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+

m2∈SIM (ms)\


MI (ms)\I

:target(mi)=m1

\M I(c)

NSI (ms, m2)

+


NSI (mt, m2)

Since (A \ B) \ C = (A \ C ) \ B, we can rewrite the second term as follows:

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+

m2∈SIM (ms)\M I(c)\m1∈SIM (ms)|∃mi∈MI (ms)\I :target(mi)=m1NSI (ms, m2)

+


NSI (mt, m2)

Since

x∈A\B f (x) =

x∈A f (x) −x∈A∩B , we can split the second term as

follows:

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+

m2∈SIM (ms)\M I(c)

N SI (ms, m2)

−m2∈SIM (ms)|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

+

m2∈SIM (mt)\

M I(c)∪{mt}

NSI (mt, m2)

Since ∀m2 ∈ SI M (ms) \ M I (c)

: NSI (ms, m2) = NSI (ms, m2), we can

rewrite the second term to:

=

m1∈M I(c)\{ms}


NSI (m1, m2)

+


N SI (ms, m2)

−m2∈

SIM (ms)\M I(c)

|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

+


NSI (mt, m2)




We can then unify the first and the second term as follows:

=

m1∈M I(c)

m2∈SIM (m1)\M I (c)

NSI (m1, m2)

−m2∈

SIM (ms)\M I(c)

|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

+

m2∈SIM (mt)\M I (c)∪{mt}

NSI (mt, m2)

= M P C (c)−


|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

+

m2∈SIM (mt)\M I (c)∪{mt}NSI (mt, m2)

SinceSI M (ms) =

SI M (ms)\m1 ∈ SI M (ms) |∃mi ∈

MI (ms)\I

: target(mi) =

m1

∪ {mt}, we can rewrite the third term as follows:

= M P C (c)−


|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

+

m2∈

SIM (ms)\


MI (ms)\I

:target(mi)=m1

∪{mt}

\M I(c)∪{mt}

N SI (mt, m2)

= M P C (c)−m2∈

SIM (ms)\M I(c)

|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

+

m2∈SIM (ms)\


MI (ms)\I

:target(mi)=m1

\M I(c)

N SI (mt, m2)

= M P C (c)−


|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

+


|∃mi∈

MI (ms)\I

:target(mi)=m2

NSI (ms, m2)

= M P C (c)

Which means that after applying Extract Method, MP C (c) will remainunchanged.

B.2.2 Export Coupling

The value of the OMMEC metric after applying the Extract Method is expressedas:




OMMEC (c) =

c2∈Others(c)

m1∈M

I(c2)

m2∈SIM (m1)∩(M

NEW (c)∪M

OV R(c) NSI (m1, m2)

Since Others(c) = Others(c), we have:

=

c2∈Others(c)

m1∈M

I(c2)

m2∈

SIM (m1)∩(M

NEW (c)∪M

OV R(c) NSI (m1, m2)

Since M NEW (c) = M NEW (c) ∪ {mt}, and M OV R(c) = M OV R(c), we have:

= c2∈Others(c)m1∈M I(c2)m

2∈SIM

(m

1)∩(M NEW (

c)∪{

mt}∪

M OV R(

c) NSI (m1, m2)

=

c2∈Others(c)

m1∈M

I(c2)

m2∈


NSI (m1, m2)

+

c2∈Others(c)

m1∈M

I(c2)

mt∈SIM (m1)

N SI (m1, mt)

Since ∀c2 ∈ Others(c) : M I (c2) = M I (c2), we have:

=

c2∈Others(c)

m1∈M I(c2)

m2∈


NSI (m1, m2)

+

c2∈Others(c)

m1∈M I(c2)

mt∈SIM (m1)

N SI (m1, mt)

Since

∀c2

∈Others(c),

∀m1

∈M I (c2) : MI (m1) = MI (m1), we have:

=

c2∈Others(c)

m1∈M I(c2)

m2∈


NSI (m1, m2)

+

c2∈Others(c)

m1∈M I(c2)

mt∈SIM (m1)

NSI (m1, mt)

=

c2∈Others(c)

m1∈M I(c2)

m2∈


NSI (m1, m2)+

0

= OMMEC (c)

Which means that after applying Extract Method, OMMEC (c) will remain

unchanged.

B.2.3 General Coupling

The Coupling Between Object classes metric value after applying the ExtractMethod is expressed as:

CBO(c) =CBOSet(c)

with CBOSet(c) =




=

d ∈ C \{c} | m1∈M

I(c) uses(m1, d)∨md∈M

I(d) uses(md, c)

Since C = C and M I (c) = M I (c) ∪ {mt}, we have:

=

d ∈ C \ {c} | m1∈M I(c)∪{mt}

uses(m1, d) ∨md∈M I(d)uses(md, c)

When we refine uses(md, c), we have:

=

d ∈ C \ {c} | m1∈M I(c)∪{mt} uses

(m1, d)

∨md∈M I(d)

M I (c) ∩ P IM (md)

∪ AI (c) ∩ AR(md)

= ∅

Since ∀d ∈ C \ {c}, ∀md ∈ M I (d) :

• AI (c) = AI (c)

• M I (d) = M I (d)

• P IM (md) = P IM (md)

• AR(md) = AR(md)

we have:

=

d ∈ C \ {c} | m1∈M I(c)∪{mt}

uses(m1, d)

∨md∈M I(d)

(M I (c) ∪ {mt}) ∩ P IM (md)

∪ AI (c) ∩ AR(md) = ∅

Since ∀md ∈ M (C ) : mt ∈ P IM (md), we have:

=

d ∈ C \ {c} | m1∈M I(c)∪{mt} uses(m1, d)

∨md∈M I(d)

M I (c) ∩ P IM (md)

∪ AI (c) ∩ AR(md) = ∅

=

d ∈ C \ {c} | m1∈M I(c)∪{mt}

uses(m1, d)

∨md∈M I(d)uses(md, c)




We can split the set in two parts:

=

d ∈ C \ {c} | ms∈M I(c)∪{mt}

uses(ms, d)

∪

d ∈ C \ {c} | md∈M I(d)uses(md, c)

We will now focus on the first term, to prove that it equals

d ∈ C \ {c} |

m1∈

M I(

c)

uses(m1, d) and that therefore, CBOSet(c) = CBOSet(c).

d ∈ C \ {c} | m1∈M I (c)∪{mt}

uses(m1, d)

=

d ∈ C \ {c} |

m1∈M I(c)∪{mt}

M I (d) ∩ P IM (m1)

∪ AI (d) ∩ AR(m1)

= ∅

Since ∀d ∈ C \ {c} : M I (d) = M I (d) ∧ AI (d) = AI (d), we have:

=

d ∈ C \ {c} |

m1∈M I(c)∪{mt}

M I (d) ∩ P IM (m1)

∪ AI (d) ∩ AR(m1) = ∅

Since:

• ∀m1 ∈ M I (c) \ {ms} : P IM (m1) = P IM (m1) ∧ AR(m1)AR(m1)

• P IM (ms)∪P IM (mt) = P IM (ms)∧AR(ms)∪AR(mt) = AR(ms)

we have:

=

d ∈ C \ {c} |

m1∈M I(c)

M I (d) ∩ P IM (m1)

∪ AI (d) ∩ AR(m1) = ∅

=

d ∈ C \ {c} | m1∈M I (c)

uses(m1, d)




And therefore CBOSet(c)

=

d ∈ C \ {c} | ms∈M I(c)

uses(ms, d)

∪

d ∈ C \ {c} | md∈M I(d)uses(md, c)

=

d ∈ C \ {c} | ms∈M I(c)

uses(ms, d) ∨md∈M I (d)uses(md, c)

= CBOSet(c)

Which means that after applying Extract method, CBO will remain un-changed.

B.2.4 Aggregation Import Coupling

The value of the Data Abstraction Coupling metric after applying the ExtractMethod refactoring is described as:

DAC (c) =| {a | a ∈ AI (c) ∧ T (a) ∈ C \ {c}} |

Since C = C , AI (c) = AI (c), and ∀a ∈ AI (c) : T (a) = T (a), we have:

= | {a | a ∈ AI (c) ∧ T (a) ∈ C \ {c}} |= DAC (c)

B.2.5 Normalized Cohesion

We describe the value of the Lack of Cohesion in Methods metric variant 5 afterapplying Extract Method as:

LCOM 5(c)

=|M I (c)|− 1

|AI(c)|

Pa∈A

I(c)|{m1|m1∈M I(c)∧a∈AR(m1)}|

|M I(c)|−1

Since AI (c) = AI (c) and M I (c) = M I (c) ∪ {mt}, we have:

=|M I (c)∪{mt}|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)∪{mt}

∧a∈AR(m1)}|

|M I(c)∪{mt}|−1

Since mt ∈ M I (c), we have | M I (c) ∪ {mt} |=| M I (c) | +1:




=|M I(c)|+1−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)∪{mt}

∧a∈AR(m1)}|

|M I (c)|+1−1

Since M I (c) ∪ {mt} =

M I (c) \ {ms} ∪ {ms} ∪ {mt}

, we have:

=|M I(c)|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)\{ms}

∧a∈AR(m1)}|

|M I(c)|

−1

|AI (c)|

Pa∈AI (c)

|{m1|m1∈{ms}∧a∈AR(ms)}|

|M I (c)|

− −1+ 1|AI (c)|

Pa∈AI (c)

|{m1|m1∈{mt}∧a∈AR(mt)}|

|M I(c)|

Since

a∈AI(c) | {m1 | m1 ∈ {mx} ∧ a ∈ AR

(mx)} |=| AI (c) ∩ AR

(mx) |, wehave:

=|M I(c)|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)\{ms}

∧a∈AR(m1)}|

|M I(c)|

−1

|AI (c)||AI(c)∩AR(ms)|

|M I (c)|

− −1+ 1|AI (c)|

|AI(c)∩AR(mt)|

|M I(c)|

Since

• ∀m1 ∈ M I (c) \ {ms} : AR(m1) = AR(m1)

• AR(ms) = AR(ms)\a ∈ AR(ms) |∃a1 ∈ AT R(ms)\A

: target(a1) =

a

• AR(mt) =

a∈A target(a)

we rewrite to:

=|M I(c)|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)\{ms}

∧a∈AR(m1)}|

|M I(c)|

−1

|AI (c)||AI(c)∩

AR(ms)\

a∈AR(ms)|∃a1∈

ATR(ms)\A

:target(a1)=a

|

|M I(c)|

− −1+

|AI (c)∩Satr∈A target(a)|

|AI (c)||M I(c)|

Since A ∩ (B \ C ) = (A ∩ B) \ (A ∩ B ∩ C ), we have | A ∩ (B \ C ) |=| A ∩ B |− | A ∩ B ∩ C | and therefore can rewrite the second term as follows:

=|M I(c)|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)\{ms}

∧a∈AR(m1)}|

|M I(c)|

−1

|AI (c)||AI(c)∩AR(ms)

|

|M I(c)|




+1

|AI (c)||


:target(a1)=a

|

|M I (c)|

− −1+|AI (c)∩

Satr∈A target(a)|

|AI (c)|

|M I (c)|

At this moment, we can unify the first and second term:

=|M I (c)|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)∧a∈AR(m1)}|

|M I(c)|

+1

|AI (c)||


:target(a1)=a

|

|M I (c)|

−−1+

|AI (c)∩Satr∈A target(a)|

|AI(c)|

|M I (c)|

Since x−yz

= z−1z

. x−yz−1 , we have:

= |M I (c)|−1|M I (c)|

.|M I(c)|−

1|AI (c)|

Pa∈AI (c)

|{m1|m1∈M I(c)∧a∈AR(m1)}|

|M I(c)|−1

+1

|AI (c)||


:target(a1)=a

|

|M I (c)|

− −1+|AI (c)∩

Satr∈A target(a)|

|AI (c)|

|M I (c)|

= |M I (c)|−1

|M I (c)|

LCOM 5(c)

+1

|AI (c)||


:target(a1)=a

|

|M I (c)|

− −1+|AI (c)∩

Satr∈A target(a)|

|AI (c)|

|M I (c)|

Since −1 = −|AI(c)||AI(c)|

, we can rewrite the last term as:

= |M I (c)|−1|M I (c)|

LCOM 5(c)

+1

|AI (c)||


:target(a1)=a

|

|M I (c)|

−−|AI (c)|+|AI (c)∩

Satr∈A target(a)|

|AI (c)|

|M I (c)|

Since −(− | A | + | A ∩ B |) =| A | − | A ∩ B | =| A \ B |, we have:

= |M I (c)|−1|M I (c)|

LCOM 5(c)

+|


:target(a1)=a

|

|AI(c)|.|M I(c)|

+|AI(c)\

Satr∈A target(a)|

|AI(c)|.|M I(c)|




Which means that after applying Extract Method, LCOM 5 will be increasedwith a factor proportionate to the number of attributes which the remaining partof ms does not reference, and additionally increased with a factor proportionateto the number of attributes which the extracted part of ms does not reference.

B.2.6 Non-normalized Cohesion

The value of the Lack of Cohesion in Methods metric variant 1 after applyingExtract Method is described as:

LCOM 1(c) =LCOM 1Set(c)

with LCOM 1Set(c)

={m1, m2} | m1, m2 ∈ M I (c) ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ A

I (c) = ∅

Since M I (c) = M I (c) ∪ {mt}, and AI (c) = AI (c), we have:

={m1, m2} | m1, m2 ∈ M I (c) ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅}

∪ {m1, mt

} |m1

∈M I (c)

∧AR(m1) ∩ AR(mt) ∩ AI (c) = ∅Since AR(mt) =

atr∈A target(atr), we have:

={m1, m2} | m1, m2 ∈ M I (c) ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅}∪ {m1, mt} | m1 ∈ M I (c)∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅

When we split the first term using M I (c) =

M I (c) \ {ms} ∪ {ms}, we have:

={m1, m2} | m1, m2 ∈ M I (c) \ {ms} ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅}∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧AR(m1) ∩ AR(ms) ∩ AI (c) = ∅}∪ {m1, mt} | m1 ∈ M I (c)∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅

Since AR(ms) = AR(ms) \ (AR(mt) \ AR(ms)), we have:




={m1, m2} | m1, m2 ∈ M I (c) \ {ms} ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅}∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧AR(m1) ∩ AR(ms) \ (AR(mt) \ AR(ms))

∩ AI (c) = ∅}∪ {m1, mt} | m1 ∈ M I (c)∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅

Since X ∩ (Y \ Z ) = ∅⇔ X ∩ Y \ (X ∩ Y ∩ Z ) = ∅⇔ X ∩ Y ⊆ X ∩ Y ∩ Z

we can rewrite the second term as follows:

={m1, m2} | m1, m2 ∈ M I (c) \ {ms} ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅}∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧

AR(m1) ∩ AR(ms) ∩ AI (c) ⊆

AR(mt) \ AR(ms)

∪ {m1, mt} | m1 ∈ M I (c)∧AR(m1)

∩atr∈A target(atr)

∩AI (c) =

∅Since X ⊆ Y

⇔ (X = ∅) ∨ (X = ∅) ∧ (X ⊆ Y )

we can rewrite the second term as follows:

={m1, m2} | m1, m2 ∈ M I (c) \ {ms} ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅}∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧AR(m1)

∩AR(ms)

∩AI (c) =

∅ ∨AR(m1) ∩ AR(ms) ∩ AI (c) = ∅∧AR(m1) ∩ AR(ms) ∩ AI (c)

⊆ AR(mt) \ AR(ms)

∪ {m1, mt} | m1 ∈ M I (c)∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅

Since {x | a ∧ (b ∨ c)} = {x | a ∧ b}∪{x | a ∧ c}, we can split up the second termas follows:




={m1, m2} | m1, m2 ∈ M I (c) \ {ms} ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅}∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧AR(m1) ∩ AR(ms) ∩ AI (c) = ∅∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧

AR(m1) ∩ AR(ms) ∩ AI (c) = ∅∧AR(m1) ∩ AR(ms) ∩ AI (c)

⊆ AR(mt) \ AR(ms)

}∪ {m1, mt} | m1 ∈ M I (c)∧AR(m1) ∩

atr∈A target(atr) ∩ AI (c) = ∅

Since ∀m1 ∈ M I (c) \ {ms} : AR(m1) = AR(m1), we have:

={m1, m2} | m1, m2 ∈ M I (c) \ {ms} ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧AR(m1) ∩ AR(ms) ∩ AI (c) = ∅}∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧


⊆ AR(mt) \ AR(ms)

}∪ {m1, mt

} |m1

∈M I (c)

∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅At this moment we can unify the first and second term:

={m1, m2} | m1, m2 ∈ M I (c) ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (c) = ∅∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧


⊆ AR(mt) \ AR(ms)

}∪ {

m1, mt

} |m1

∈M I (c)

∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅}= LCOM 1Set(c)

∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧AR(m1) ∩ AR(ms) ∩ AI (c) = ∅

∧AR(m1) ∩ AR(ms) ∩ AI (c) ⊆

AR(mt) \ AR(ms)}

∪ {m1, mt} | m1 ∈ M I (c)∧AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅




We once again divide M I (c) into M I (c) \ {ms} and {ms}:

= LCOM 1Set(c)∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧


⊆ AR(mt) \ AR(ms)

}∪ {m1, mt} | m1 ∈ M I (c) \ {ms}∧AR(ms) ∩atr∈A target(atr) ∩ AI (c) = ∅}∪ {ms, mt} | AR(ms) ∩atr∈A target(atr) ∩ AI (c) = ∅

Once again, we apply the rule that ∀m1 ∈ M I (c) \ {ms} : AR(m1) = AR(m1),so that we can rewrite the first and third term to:

= LCOM 1Set(c)∪ {m1, ms} | m1 ∈ M I (c) \ {ms}∧


⊆ AR(mt) \ AR(ms)

}∪ {m1, mt} | m1 ∈ M I (c) \ {ms}∧AR(m1) ∩ A

atr∈A target(atr) ∩ AI (c) = ∅

∪ {ms, mt} | AR(ms) ∩atr∈A target(atr) ∩ AI (c) = ∅Since

• AR(ms) =

atr∈ATR(ms)\Atarget(atr):

• AR(mt) =

atrA target(atr):

we have:

= LCOM 1Set(c)∪{m1, ms} | m1 ∈ M I (c) \ {ms}∧

AR(m1) ∩ AR(ms) ∩ AI (c) = ∅∧AR(m1)∩AR(ms)∩AI (c)

⊆ atrA target(atr)\atr∈ATR(ms)\A

target(atr)}

∪ {m1, mt} |m1 ∈ M I (c) \ {ms} ∧ AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅∪ {ms, mt} |

atr∈ATR(ms)\Atarget(atr) ∩atr∈A target(atr) ∩ AI (c) = ∅

Since these parts are disjunct, we can state that LCOM 1(c) =| LCOM 1Set(c) |:




= LCOM 1(c)+ | {m1, ms} | m1 ∈ M I (c) \ {ms}∧

AR(m1) ∩ AR(ms) ∩ AI (c) = ∅∧AR(m1)∩AR(ms)∩AI (c)

⊆ atrA target(atr)\atr∈ATR(ms)\A

target(atr)}

+ | {m1, mt} |m1 ∈ M I (c) \ {ms} ∧ AR(m1) ∩atr∈A target(atr) ∩ AI (c) = ∅ |+ | {ms, mt} |

atr∈ATR(ms)\Atarget(atr) ∩atr∈A target(atr) ∩ AI (c) = ∅ |

Which means that after applying Extract Method, LCOM 1(c) will be in-creased with:

• the number of methods m1 ∈ M I (c) which share references to attributesimplemented by c with ms, but not with the remaining part;

• the number of methods m1 ∈ M I (c) which do not share references toattributes implemented by c with the extracted part of ms;

• 1 in case the remaining part of ms does not share references to attributesimplemented by c with the extracted part of ms.



B.3. MOVE METHOD 205

B.3 Move Method


The Message Passing Coupling metric value after applying Move Method isdefined as:

M P C (cs) =

m1∈M I(cs)

m2∈SIM (m1)\M

I(cs)

NSI (m1, m2)

= m1∈M I(cs)\{m}m2∈SIM (m1)\(M I(cs)\{m}) NSI (m1, m2)

Since A \ (B \ C ) = (A \ B) ∪ (A ∩ C ), this can be rewritten to:

=

m1∈M I(cs)\{m}

m2∈(SIM (m1)\(M I(cs))∪(SIM (m1)∩{m}) N SI (m1, m2)

As

x∈A∪B f (x) =

x∈A f (x)

+

x∈B f (x)−

x∈(A∩B) f (x)

, we canseparate the parts as follows:

=

m1∈M I(cs)\{m}

m2∈SIM (m1)\M I(cs)

NSI (m1, m2)

+ m1∈M I(cs)\{m}m2∈SIM (m1)∩{m} NSI (m1, m2)

−m1∈M I(cs)\{m}

m2∈

SIM (m1)\M I(cs)

∩SIM (m1)∩{m}

NSI (m1, m2)

At this time we will demonstrate in a sub-proof that the last term (LT) isequal to zero and can therefore be dropped.

Subproof – Since:

• A \ (B ∪ C ) = (A \ B) ∩ (A \ C )

•M I (cs) = M I (cs)

\ {m

} ∪ {m

}we can rewrite

SI M (m1) \ M I (cs)

to

SI M (m1) \ M I (cs) \ {m}

∩ SI M (m1) \ {m}:

and so we rewrite

SI M (m1) \ M I (cs) ∩ SI M (m1) ∩ {m} to:

=

SI M (m1) \ M I (cs) \ {m}

∩ SI M (m1) \ {m} ∩ SI M (m1) ∩ {m}




Since (A \ B) ∩ (A ∩ B) = ∅, we haveSI M (m1) \ {m} ∩ SI M (m1) ∩ {m} = ∅

and therefore:

=

SI M (m1) \ M I (cs) \ {m}

∩ ∅

As A \ ∅ = ∅, our last term reduces to:

LT =

m1∈M I(cs)\{m}

m2∈∅

N SI (m1, m2) = 0

Q.E.D. (subproof)

As the last term can be dropped, we can simplify to:

=

m1∈M I(cs)\{m}


NSI (m1, m2)

+

m1∈M I(cs)\{m}

m2∈SIM (m1)∩{m} NSI (m1, m2)

Because ∀m1 | m ∈ SI M (m1) ⇔ NSI (m1, m) = 0, the latter can be simplifiedto:

= m1∈M I(cs)\{m}


NSI (m1

, m2

)

+


Taking into account that:

• x∈A\B f (x) =

x∈A f (x)

− x∈A∩B f (x)

• M I (cs) ∩ {m} = {m}

we can split the first term as follows:

= m1∈M I(cs)m2∈SIM (m1)\M I (cs)NSI (m1, m2)

−m1∈{m}

m2∈SIM (m1)\M I(cs) NSI (m1, m2)

+


Since this leaves the first term equal to MP C (cs), and since

x∈{y} f (x) = f (y)we have:

= MP C (cs) −m2∈SIM (m)\M I(cs)

NSI (m, m2)

+





This means that, after applying the Move Method, the Message Passing Cou-pling of the source class will:

• increase in case

m1∈M I (cs)\{m} NSI (m1, m) >

m2∈SIM (m)\M I(cs)NSI (m, m2)

• reduce in case

m1∈M I(cs)\{m} N SI (m1, m) <

m2∈SIM (m)\M I(cs)NSI (m, m2)

• remain equal in case

m1∈M I(cs)\{m} NSI (m1, m) =

m2∈SIM (m)\M I (cs)NSI (m, m2)

B.3.2 Export Coupling

The selected export coupling metric (OMMEC) value after applying Move Methodis described as:

OMMEC (cs)

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈

SIM (m1)∩(M

NEW (cs)∪M

OV R(cs)

N SI (m1, m2)

Since:

• Others(cs) = C \

Ancestors(cs) ∪ Descendants(cs)

= Others(cs)

we have:

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈SIM (m1)∩(M

NEW (cs)∪M

OV R(cs)

NSI (m1, m2)

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈SIM (m1)∩(M

NEW (cs)∪M

OV R(cs)

NSI (m1, m2)

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈

SIM (m1)∩

(M NEW (cs)\{m})∪M OV R(cs)

NSI (m1, m2)

Since (A \ B) ∪ C = (A ∪ C ) \ (B \ C ), we have:M NEW (cs) \ {m} ∪ M OV R(cs)

=

M NEW (cs) ∪ M OV R(cs) \ {m} \ M OV R(cs)

=

M NEW (cs) ∪ M OV R(cs) \ {m}




Moreover, since A ∩ (B \ C ) = (A ∩ B) \ C , we have:

SI M (m1) ∩ (M NEW (cs) ∪ M OV R(cs)) \ {m}=

SI M (m1) ∩ (M NEW (cs) ∪ M OV R(cs) \ {m}

And therefore OMMEC (cs)

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈SIM (m1)∩(M NEW (cs)∪M OV R(cs)\{m}NSI (m1, m2)

Since:

• ∀c ∈ Others(cs) \ {ct}

: M I (c) = M I (c)

• M I (ct) = M I (ct) ∪ {m}we have:

=

c2∈Others(cs)

m1∈M I(c2)

m2∈

SIM (m1)∩(M NEW (cs)∪M OV R(cs)

\{m}

NSI (m1, m2)

+

m2∈

SIM (m)∩(M NEW (cs)∪M OV R(cs)

\{m}

NSI (m, m2)

Since

x∈(A\B) f (x) =

x∈A f (x) −x∈B f (x) +

x∈(B\A) f (x), we have:

=

c2∈Others(cs)

m1∈M I(c2)

m2∈SIM (m1)∩(M NEW (cs)∪M OV R(cs)

NSI (m1, m2)

−

c2∈Others(cs)m1∈M I(c2)

NSI (m1, m)

+

c2∈Others(cs)

m1∈M I(c2)m2∈

{m}\


NSI (m1, m)

+

m2∈


\{m}

NSI (m, m2)

= OMMEC (cs)−

c2∈Others(cs)

m1∈M I(c2)

NSI (m1, m)




+

c2∈Others(cs)

m1∈M I(c2)

m2∈

{m}\


NSI (m1, m)

+

m2∈


\{m}

NSI (m, m2)

Since m ∈ (M NEW (cs) ∪ M OV R(cs), we have:

= OMMEC (cs)

−c2∈Others(cs)

m1∈M I(c2) N SI (m1, m)

+

c2∈Others(cs)

m1∈M I(c2)

m2∈

{m}\SIM (m1)

NSI (m1, m)

+

m2∈


\{m}

NSI (m, m2)

Finally, since ∀m1 ∈ M (C ) : m ∈ SI M (m1) ⇐⇒ NSI (m1, m) = 0, we have:

= OMMEC (cs)−

c2∈Others(cs)

m1∈M I(c2)

N SI (m1, m)

+m2∈


\{m}

NSI (m, m2)

Which means that OMMEC will be decreased with static invocations frommethods implemented in classes other than cs to m, but will be increased withthe static invocations from m to the methods (different from m) which cs im-plements.

This leaves us with three possibilities of the effect of the Move Methodrefactoring on OMMEC :

• OMMEC will decrease when

c2∈Others(cs)

m1∈M I(c2) NSI (m1, m)>

m2∈


\{m}

NSI (m, m2)

• OMMEC will remain unchanged whenc2∈Others(cs)

m1∈M I(c2)

NSI (m1, m)

=

m2∈


\{m}

NSI (m, m2)




• OMMEC will increase whenc2∈Others(cs)

m1∈M I(c2)

NSI (m1, m)

<

m2∈


\{m}

NSI (m, m2)


The Coupling Between Object classes metric value after applying Move Methodis defined as:

CBO(cs) =CBOSet(cs)

with

CBOSet(cs) =

d ∈ C \ {cs} | uses(cs, d) ∨ uses(d, cs)

When we rewrite uses(c, d) as

mc∈M I(c)uses(mc, d) with

∀mc ∈ M I (c) : uses(mc, d) ⇔

M I (d) ∩ P IM (mc)∪ AI (d) ∩ AR(mc)

= ∅we have:

=

d ∈ C \ {cs} | ms∈M I (cs) uses(ms, d) ∨md∈M I(d) uses(md, cs)

When comparing CBO(cs) with CBO(cs), we have three possibilities:

1.CBOSet(cs)

<CBOSet(cs)

, or a decrease after refactoring

2.CBOSet(cs)

=CBOSet(cs)

, or a status-quo after refactoring

3.CBOSet(cs)

>CBOSet(cs)

, or an increase after refactoring

This means that we can reason about the effect of applying the Move Methodrefactoring on CBO(cs) by comparing CBOSet(cs) with CBOSet(cs).

The general strategy of the proof goes as follows:

• First, we demonstrate that either CBOSet(cs) \ CBOSet(cs) is empty,or contains ct in proof A.

• Second, we demonstrate that CBOSet(cs) \ CBOSet(cs) can contain ct,but other classes as well in proof B.




Proof A – First, we pay our attention to

CBOSet(cs)\CBOSet(cs)\{ct}.

We demonstrate that this set is empty, and afterwards demonstrate the condi-tion under which {ct} will b e contained in this set in a different subproof,thereby showing that CBOSet(cs) \ CBOSet(cs) = [{ct}.

Let’s take a class x ∈ CBOSet(cs)\CBOSet(cs)

\{ct}. This can be rephrasedto:

x ∈

d ∈ C \ {cs} |

ms∈M I(cs)

uses(ms, d) ∨md∈M I(d) uses(md, cs)

\ d ∈ C \ {cs} | ms∈M I(cs) uses(ms, d) ∨md∈M I(d) uses(md, cs)

Therefore, the following condition must hold:

⇔

ms∈M I(cs)

uses(ms, x) ∨md∈M I(x) uses(md, cs)

∧ x ∈

d ∈ C \ {cs} |

ms∈M I(cs)uses(ms, x) ∨md∈M I(x)

uses(md, cs)

We can rephrase the second term by negating it:

⇔

ms∈M I(cs)


∧x ∈

d ∈ C \{cs} |

ms∈M I(cs)¬uses(ms, x)∧md∈M I(x)

¬uses(md, cs)

Now we can focus on x, with x = cs:

⇔

ms∈M I(cs)


∧ ms∈

M I(

cs) ¬

uses(ms, x)∧m

d∈M I(

x) ¬

uses(md, cs)Since (a ∨ b) ∧ (c ∧ d) = (a ∧ c ∧ d) ∨ (b ∧ c ∧ d) we can reshuffle the parts asfollows:

⇔

ms∈M I(cs)

uses(ms, x)∧ms∈M I(cs)¬uses(ms, x)∧md∈M I(x)

¬uses(md, cs)

∨

md∈M I(x)uses(md, cs)∧ms∈M I (cs)

¬uses(ms, x)∧md∈M I(x)¬uses(md, cs)




We rewrite uses(ms, x) by going back to its definition, knowing that x ∈{cs, ct}:

⇔

ms∈M I(cs)

M I (x) ∩ P IM (ms)

∪ A

I (x) ∩ AR(ms) = ∅

∧

ms∈M I(cs)

¬uses(ms, x) ∧md∈M I (x)¬uses(md, cs)

∨

md∈M I(x)

M I (cs) ∩ P IM (md)

∪ AI (cs) ∩ AR(md)

= ∅

∧

ms∈M I(cs) ¬uses(ms, x) ∧md∈M I (x) ¬uses(md, cs)

Since ∀x ∈ C \ {cs, ct}

, it holds that:

• M I (x) = M I (x)

• AI (x) = AI (x)

• ∀mx ∈ M I (x) :

P IM (mx) = P IM (mx) ∧ AR(mx) = AR(mx)

And therefore we have:

⇔

ms∈M I(cs)

M I (x) ∩ P IM (ms)

∪ AI (x) ∩ AR(ms)

= ∅

∧

ms∈M I(cs)¬uses(ms, x) ∧md∈M I (x)

¬uses(md, cs)

∨

md∈M I (x)


∪ A

I (cs) ∩ AR(md) = ∅

∧

ms∈M I(cs)

¬uses(ms, x) ∧md∈M I (x)¬uses(md, cs)

Since

• AI (cs) = AI (cs)

• M I (cs) = M I (cs) \ {m}

• ∀ms ∈ M I (cs) :

P IM (ms) = P IM (ms) ∧ AR(ms) = AR(ms)

we have:




⇔

ms∈M I(cs)\{m}

M I (x)∩P IM (ms)∪AI (x)∩AR(ms)

= ∅

∧

ms∈M I (cs)¬uses(ms, x) ∧md∈M I(x)

¬uses(md, cs)

∨

md∈M I(x)

(M I (cs) \ {m}) ∩ P IM (md)

∪ AI (cs) ∩ AR(md) =

∅

∧ms∈M I(cs)¬uses(ms, x) ∧md∈M I(x)

¬uses(md, cs)

This simplification shows us that we can translate the first broken down term

back:

⇔

ms∈M I(cs)\{m} uses(ms, x)∧ms∈M I(cs)¬uses(ms, x)∧md∈M I(x)

¬uses(md, cs)

∨

md∈M I(d)

M I (cs) \ {m}∩ P IM (md)

∪ AI (cs) ∩ AR(md) =

∅

∧ms∈M I(cs)¬uses(ms, x) ∧md∈M I(x)

¬uses(md, cs)

To make it more easy to reference certain terms of this expression, we map it

to (a ∧ c ∧ d) ∨ (b ∧ c ∧ d). This allows to combine the parts as follows:

• a ∧ c is false, since the latter states that ∀ms ∈ M I (cs) : ¬uses(ms, x)while the former states that ∀ms ∈ M I (cs) \ {m} : uses(ms, x). It isimpossible for both to be true.

• b ∧ d is false, since the latter states that ∀md ∈ M I (x) : ¬uses(md, cs)while the former states that ∀md ∈ M I (x) : uses(md, cs \ {m}). It isimpossible for both to be true.

Therefore we have:

⇔ (false) ∨ (false) ⇔ false

This means that our assumption was wrong and that x /∈ CBOSet(cs) \

CBOSet(cs) \ {ct}. In other words, we have:

CBOSet(cs) \ CBOSet(cs)

\ {ct} = ∅




This leaves us to demonstrate under which condition ct ∈ CBOSet(cs) \

CBOSet(cs)

.

ct ∈

d ∈ C \ {cs} |

ms∈M I(cs)

uses(ms, d) ∨md∈M I(d) uses(md, cs)

\

d ∈ C \ {cs} |

ms∈M I (cs)uses(ms, d) ∨md∈M I(d)

uses(md, cs)

We apply the same strategy as for the general x, and come to:

⇔ ms∈M

I(cs) uses(ms, ct)∧ms∈M I(cs) ¬uses(ms, ct)∧md∈M I(ct) ¬uses(md, cs)

∨

md∈M I(ct)uses(md, cs)∧ms∈M I(cs)

¬uses(ms, ct)∧md∈M I(ct)¬uses(md, cs)

⇔ ms∈

M I(cs)\{m}

M I (ct)∪{m}∩P IM (ms)∪AI (ct)∩AR(ms)

=

∅

∧ms∈M I(cs)¬uses(ms, ct) ∧md∈M I(ct)

¬uses(md, cs)

∨md∈M I(ct)∪{m}

M I (cs)\{m}∩P IM (md)

∪

AI (cs)∩AR(md)

=

∅


¬uses(md, cs)

=

x ∈ {ct} |

ms∈

M I(cs)\{m}

m ∈ P IM (ms)

∨

M I (cs) \ {m} ∩ P IM (m) = ∅


¬uses(md, cs)

=

x ∈ {ct} | ms∈M I(cs)\{m}

m ∈ P IM (ms)

∨

M I (cs) \ {m} ∩ P IM (m) = ∅

∧ ¬uses(ct, cs)

Since we already demonstrated that

CBOSet(cs) \ CBOSet(cs) \ {ct} = ∅,

we can conclude that:




• CBOSet(cs) \ CBOSet(cs)

=

x ∈ {ct} |

ms∈

M I(cs)\{m}

m ∈ P IM (ms)

∨

M I (cs) \ {m} ∩ P IM (m) = ∅

∧ ¬uses(ct, cs)

Which means that, after applying Move Method, CBOSet(cs) will be ex-

panded with ct in case ct was not coupled to cs; and either (a) any siblingmethod uses m; or (b) m uses any sibling method or attribute.Q.E.D. (end of proof A)

Proof B – Second, we pay our attention to CBOSet(cs) \ CBOSet(cs), anddemonstrate that it can contain classes, among which ct.

Assuming that x ∈ CBOSet(cs) \ CBOSet(cs)

, we have:

x ∈

d ∈ C \ {cs} |

ms∈M I(cs)uses(ms, d) ∨md∈M I(d)

uses(md, cs)

\ d ∈ C \ {cs} | ms∈M I(cs) uses

(ms, d) ∨md∈M I(d) uses

(md, cs)

Once again, we rewrite this to (with x = cs):

⇔

ms∈M I(cs)uses(ms, x) ∨md∈M I(x)

uses(md, cs)

∧ms∈M I(cs)

¬uses(ms, x) ∧md∈M I(x) ¬uses(md, cs)

And re-apply the rule (a ∨ b) ∧ (c ∧ d) = (a ∧ c ∧ d) ∨ (b ∧ c ∧ d) to reshuffle theparts as follows:

⇔ ms∈M I(cs) uses(ms, x)∧ms∈M

I(cs) ¬uses(ms, x)∧md∈M

I(x) ¬uses(md, cs)

∨

md∈M I(x)uses(md, cs)∧ms∈M

I(cs)

¬uses(ms, x)∧md∈M I(x) ¬uses(md, cs)

⇔

∃ms ∈ M I (cs) : uses(ms, x)

∧ ∃ms ∈ M I (cs) : uses(ms, x)∧ ∃md ∈ M I (x) : uses(md, cs)




∨

∃md ∈ M I (x) : uses(md, cs)

∧ ∃ms ∈ M I (cs) : uses(ms, x)∧ ∃md ∈ M I (x) : uses(md, cs)

Since M I (cs) = M I (cs) \ {m}, we have:

⇔

∃ms ∈ M I (cs) : uses(ms, x)

∧ ∃ms

∈M I (cs)

\ {m

}: uses(ms, x)

∧ ∃md

∈M

I

(x) : uses(md, cs)∨


∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)∧ ∃md ∈ M I (x) : uses(md, cs)

As this moment, we will differentiate between x = ct and x = ct.

Assumption 1: x = ct – Since we then have that M I (x) = M I (ct) = M I (ct)∪{m}, we have x = ct ∈ CBOSet(cs) \ CBOSet(cs):

⇔

∃ms ∈ M I (cs) : uses(ms, ct)

∧ ∃ms ∈ M I (cs)\{m} : uses(ms, ct)∧ ∃md ∈ M I (ct)∪{m} : uses(md, cs)

∨

∃md ∈ M I (ct) : uses(md, cs)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, ct)

∧ ∃md ∈ M I (ct) ∪ {m} : uses(md, cs)

Since ∀m1 ∈ M (C ) : uses(m1, ct) ⇐⇒ uses(m1, ct) ∨ m ∈ P IM (m1)

, we

have:

⇔


∧ ∃ms ∈ M I (cs) \ {m} :

uses(ms, ct) ∨ m ∈ P IM (ms)





∨


∧ ∃ms ∈ M I (cs) \ {m} :

uses(ms, ct) ∨ m ∈ P IM (ms))


Since ∀md ∈ M (C ) : uses(md, cs)

⇐⇒

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩ AR(md) = ∅

,

we have ct ∈ CBOSet(cs) \ CBOSet(cs):

⇔


∧ ∃ms ∈ M I (cs) \ {m} :


∧ ∃md ∈ M I (ct) ∪ {m} :

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩

AR(md) = ∅

∨


∧ ∃ms ∈ M I (cs) \ {m} :


∧ ∃md ∈ M I (ct) ∪ {m} :

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩

AR(md) = ∅

⇔

uses(m, ct)

∧ ∃ms ∈ M I (cs) \ {m} :


∧∀md ∈ M I (ct)∪{m} :

(M I (cs)\{m})∩P IM (md)∪(AI (cs)∩AR(md)) =

∅∨∃md ∈ M I (ct) : m ∈ P IM (md)

∧ ∃ms ∈ M I (cs) \ {m} :


∧∀md ∈ M I (ct)∪{m} :

(M I (cs)\{m})∩P IM (md)∪(AI (cs)∩AR(md)

=

∅

Which means that after applying the Move Method refactoring, the generalcoupling between cs and ct will be broken if and only if all the methods imple-




mented by ct do not use cs without m, and nor does m, and all the methodsimplemented by cs except m do not use ct nor m, and:

• either m uses m and/or ct;

• or there exists a method implemented by ct which uses m

Assumption 2: x = ct – Thus x ∈ {cs, ct}. Since we then have that M I (x) =M I (x), we have x ∈

CBOSet(cs) \ CBOSet(cs)

:

⇔ ∃ms

∈M I (cs) : uses(ms, x)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)∧ ∃md ∈ M I (x) : uses(md, cs)

∨


∧ ∃ms ∈ M I (cs)\{m} : uses(ms, x)∧ ∃md ∈ M I (x)∪{m} : uses(md, cs)

Since ∀x ∈ C \ {cs, ct}:

• ∀m1 ∈ M I (cs) \ {m} : uses(m1, x) ⇔ uses(m1, x) and also M I (x) =M I (x)

• ∀md ∈ M I (x) : uses(md, cs)

⇔

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩ AR(md)) = ∅

we have x ∈ CBOSet(cs) \ CBOSet(cs)

:

⇔

uses(m, x)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧ ∃md ∈ M I (x) :

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩ AR(md)) =

∅

∨

∃md ∈ M I (x) : m ∈ P IM (md)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧ ∃md ∈ M I (x) :

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩ AR(md)) =

∅




⇔

uses(m, x)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧ ∀md ∈ M I (x) :

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩ AR(md))

=

∅

∨

∃md ∈ M I (x) : m ∈ P IM (md)

∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧ ∀md ∈ M I (x) :

(M I (cs) \ {m}) ∩ P IM (md) ∪ (AI (cs) ∩ AR(md))

=

∅

Which means that after applying the Move Method refactoring, the generalcoupling between cs and x ∈ C \ {cs, ct} will be broken if and only if allthe methods implemented by x do not use cs without m, and all the methodsimplemented by cs except m do not use ct nor m, and:

• m uses x;

•or there exists a method implemented by x which uses m

We therefore have seen that CBOSet(cs) \ CBOSet(cs):

=

x ∈ C \ {cs, ct}

|

uses(m, x)∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧∀md ∈ M I (x) :

(M I (cs) \{m})∩ P IM (md) ∪ (AI (cs) ∩ AR(md))

= ∅

∨∃md ∈ M I (x) : m ∈ P IM (md)∧ ∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧∀md ∈ M I (x) :

(M I (cs)\{m})∩P IM (md)∪(AI (cs)∩AR(md))

= ∅

∪ x ∈ {ct} |

uses(m, ct)

∧ ∀ms ∈ M I (cs) \ {m} : ¬uses(ms, ct) ∨ m ∈ P IM (ms)

∧∀md ∈ M I (ct)∪{m} : (M I (cs)\{m})∩P IM (md)∪(AI (cs)∩AR(md)) =

∅

∨∃md ∈ M I (ct) : m ∈ P IM (md)

∧ ∀ms ∈ M I (cs) \ {m} : ¬uses(ms, ct) ∨ m ∈ P IM (ms)


∅




Which can be shortened using (a ∧ c ∧ d) ∨ (b ∧ c ∧ d) = (a ∨ b) ∧ (c ∧ d):

=

x ∈ C \ {cs, ct}

|


∧

∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧∀md ∈ M I (x) :


= ∅

∪ x ∈ {ct} |


∧∀ms ∈ M I (cs) \ {m} : ¬


∧∀md ∈ M I (ct)∪{m} : (M I (cs)\{m})∩P IM (md)∪(AI (cs)∩AR(md)) =∅

Summarizing, we have demonstrated that after applying the Move Methodrefactoring:

• CBO(cs) can remain constant when there exists no class which is coupledto m but not to the other methods implemented by cs. With method m1 is coupled to class c1 we mean that m1 invokes methods or referencesattributes implemented by c1, or that the c1 implements methods whichcall m1 (potentially through polymorphism).

• CBO(cs) can decrease when there do exists such classes.

End of proof BAt this moment, we have demonstrated:

• CBOSet(cs)\CBOSet(cs), which signifies what is added to CBOSet(cs)after applying Move Method. Let us call this X.

• CBOSet(cs)\CBOSet(cs), which signifies what is removed from CBOSet(cs)after applying Move Method. Let us call this Y.

We therefore can construct CBOSet(cs) as CBOSet(cs) = (CBOSet(cs) \Y ) ∪ X And since X ⊆ CBOSet(cs) and X ∩Y = ∅, we have CBO(cs) =| CBOSet(cs) |

= CBO(cs)− | Y | + | X |= CBO(cs)

−x ∈

C \ {cs, ct} |





∧

∃ms ∈ M I (cs) \ {m} : uses(ms, x)

∧∀md ∈ M I (x) :


= ∅

−x ∈ {ct}

|


∧∀ms ∈ M I (cs) \ {m} : ¬uses(ms, ct) ∨ m ∈ P IM (ms)


∅

+

x ∈ {ct} |

ms∈M I(cs)\{m}

m ∈ P IM (ms)

∨

M I (cs) \ {m} ∩ P IM (m) = ∅

∧ ¬uses(ct, cs)

Which means that, after applying Move Method, CBO(cs) will be:

• decreased with the number of classes (= ct) which were coupled to cs

exclusively by m

• and additionally decreased with 1 in case ct was coupled to cs exclusivelyby m and m does not use the remainder of cs.

• and additionally increased with 1 in case ct was not coupled to cs, and either (a) any sibling method uses m; or (b) m uses any sibling methodor attribute.

B.3.4 Aggregation Import Coupling

The Data Abstraction Coupling metric value after applying Move Method isdefined as:

DAC (cs) =| {a | a ∈ AI (cs) ∧ T (a) ∈ C \ {cs}} |

Since C = C , AI (cs) = AI (cs) and ∀a ∈ AI (cs) : T (a) = T (a), we have:

= | {a | a ∈ AI (cs) ∧ T (a) ∈ C \ {cs}} |= DAC (cs)





The metric value after applying Move Method of the selected normalized cohe-sion metric is:

LCOM 5(cs) =|M I(cs)|−

1|AI(cs)|

Pa∈A

I(cs)

|{m1|m1∈M I(cs)∧a∈AR(m1)}|

|M I(cs)|−1

=|(M I(cs)\{m}|− 1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈(M I(cs)\{m})∧a∈AR(m1)}|

|(M I (cs)\{m})|−1

=

|M I(cs)|−1−1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈(M I(cs)\{m})∧a∈AR(m1)}|

|M I (cs)|−2

=|M I(cs)|−1−

1|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈M I(cs)∧a∈AR(m1)}|

|M I(cs)|−2

−1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈{m})∧a∈AR(m1)}|

|M I (cs)|−2

=|M I(cs)|−

1|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈M I (cs)∧a∈AR(m1)}|

|M I(cs)|−2

− 1+ 1|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈{m})∧a∈AR(m1)}|

|M I(cs)|−2

= |M I(cs)|−1

|AI (cs)|P

a∈AI (cs)|{m1|m1∈M I (cs)∧a∈AR(m1)}||M I(cs)|−2

+1− 1

|AI (cs)||AI(cs)∩AR(m)|

|M I(cs)|−2

Since xy

− zy

= y+1y

x

y+1 − zy+1

, we have:

= |M I(cs)|−1|M I(c)|−2

|M I (cs)|−1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈M I(cs)∧a∈AR(m1)}|

|M I(c)|−1

− 1− 1|AI (cs)|

|AI(cs)∩AR(m)|

|M I(cs)|−1

= |M I(cs)|−1|M I(cs)|−2

LCOM 5(cs) − 1− |AI (cs)∩AR(m)|

|AI (cs)|

|M I(cs)|−1

Since 1 = |AI(cs)||AI(cs)|

, we have:

= |M I(cs)|−1|M I(cs)|−2

LCOM 5(cs) −

|AI (cs)|−|AI (cs)∩AR(m)|

|AI (cs)|

|M I(cs)|−1

Since | A | − | A ∩ B |=| A \ B | on the condition that B ⊆ A, we have:




= |M I (cs)|−1|M I (cs)|−2

LCOM 5(cs) −

|AI (cs)\AR(m)||AI (cs)|

|M I(cs)|−1

= |M I (cs)|−1|M I (cs)|−2

LCOM 5(cs) − |AI (cs)\AR(m)|


This means that applying the Move Method refactoring can increase or de-crease LCOM 5, depending on | M I (c) | and the number of attributes which mreferences. When we hold the number of methods factor constant, we find thatthe less attributes m will reference, the higher the decrease will be.


The metric value after applying Move Method of the selected non-normalizedcohesion metric is:

LCOM 1(cs) =LCOM 1Set(cs)

with LCOM 1Set(cs)

={m1, m2} | m1, m2 ∈ M I (cs) ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ A

I (cs) = ∅= {

m1, m2

} |m1, m2

∈M I (cs)

\ {m

} ∧m1

= m2

∧AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅={m1, m2} | m1, m2 ∈ M I (cs) ∧ m1 = m2∧AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅ \{m1, m} | m1 ∈ M I (cs) \ {m}∧ m1 =m∧AR(m1) ∩ AR(m) ∩ AI (cs) = ∅

= LCOM 1Set(cs) \ {m1, m} | m1 ∈ M I (cs) \ {m} ∧ m1 = m∧AR(m1) ∩ AR(m) ∩ AI (cs) = ∅

And therefore LCOM 1(cs)

=LCOM 1Set(cs) \ {m1, m} | m1 ∈ M I (cs) \ {m} ∧ m1 = m∧AR(m1) ∩ AR(m) ∩ AI (cs) = ∅

= | LCOM 1Set(cs) | −{m1, m} | m1 ∈ M I (cs) \ {m} ∧ m1 = m∧AR(m1) ∩ AR(m) ∩ AI (cs) = ∅

= | LCOM 1Set(cs) | −m1 | m1 ∈ M I (cs) \ {m} ∧ m1 = m∧AR(m1) ∩ AR(m) ∩ AI (cs) = ∅




= LCOM 1(cs) − m1 | m1 ∈ M I (cs) \ {m} ∧ m1 = m∧AR(m1) ∩ AR(m) ∩ AI (cs) = ∅

Which means that after applying Move Method, LCOM 1(cs) will be de-creased with the number of methods implemented by cs which do not sharereferences to attributes implemented by cs with method m.



B.4. REPLACE METHOD WITH METHOD OBJECT 225

B.4 Replace Method with Method Object


We can express the value of the Message Passing Coupling metric after applyingthe Replace Method with Method Object refactoring as:

M P C (cs) =

m1∈M I(cs)

m2∈SIM (m1)\M

I(cs)

NSI (m1, m2)

Since M I (cs) = M I (cs), we have:

=

m1∈M I(cs)


N SI (m1, m2)

When we separate ms from M I (cs), we have:

=

m1∈M I(cs)\{ms}

m2∈SIM (m1)\M I (cs)

NSI (m1, m2)

+

m2∈SIM (m1)\M I (cs)NSI (ms, m2)

Since ∀m1 ∈ M I (cs) \ {ms}

, it holds that MI (m1) = MI (m1), we have:

=

m1∈M I(cs)\{ms}

m2∈SIM (m1)\M I(cs) NSI (m1, m2)

+

m2∈SIM (m1)\M I (cs)NSI (ms, m2)

The postcondition also specifies that MI (ms) = {mi1, mi2}, with mi1, mi2method invocations from ms for which it holds that target(mi1) = mct, target(mi2) =mt. Therefore, we can write SI M (ms) = {mct, mt}. Consequently, we canwrite MP C (cs):

=

m1∈M I(cs)\{ms}


NSI (m1, m2)

+m2∈{mct,mt}\M I(cs)NSI (ms, m2)

=

m1∈M I(cs)\{ms}


NSI (m1, m2)

+

m2∈{mct,mt}NSI (ms, m2)

Since we know that M I (ms) = {mct, mt}, we can rewrite the last term to:

=

m1∈M I(cs)\{ms}


NSI (m1, m2)

+2




When we subsequently add and remove the set of method invocations fromms to methods implemented by other classes, we have:

=

m1∈M I(cs)\{ms}


NSI (m1, m2)

+2+

m2∈SIM (m1)\M I(cs)NSI (m1, m2)

−m2∈SIM (m1)\M I(cs)

NSI (m1, m2)

When we unify the first and third term, we have:

=

m1∈M I(cs)

m2∈SIM (m1)\M I (cs) NSI (m1, m2)+2−

m2∈SIM (m1)\M I(cs)NSI (m1, m2)

At this time, we recognize that we can replace the first term by M P C (cs):

= MP C (cs)−

m2∈SIM (m1)\M I(cs)NSI (m1, m2) +2

B.4.2 Export CouplingThe selected export coupling metric value after applying Replace Method withMethod Object is:

OMMEC (cs)

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈SIM (m1)∩(M

NEW (cs)∪M

OV R(cs)

N SI (m1, m2)

Since Others(cs) = Others(cs) ∪ {ct}, we have:

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈

SIM (m1)∩(M

NEW (cs)∪M

OV R(cs)

NSI (m1, m2)

+

m1∈M I(ct)

m2∈

SIM (m1)∩(M

NEW (cs)∪M

OV R(cs)

NSI (m1, m2)

Since M NEW (cs) = M NEW (cs) and M OV R(cs) = M OV R(cs):

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈


NSI (m1, m2)

+

m1∈M I(ct)

m2∈


NSI (m1, m2)




Since M NEW (ct) = {mt, mct}:

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈


NSI (m1, m2)

+

m2∈SIM (mt)∩(M NEW (cs)∪M OV R(cs)

NSI (mt, m2)

+

m2∈SIM (mct)∩(M NEW (cs)∪M OV R(cs)

NSI (mct, m2)

Since M I (mct) = ∅, we have:

= c2∈Others(cs)m1∈M I(c2)m

2∈SIM

(m

1)∩(M NEW (

cs)∪

M OV R(

cs) NSI (m1, m2)

+

m2∈SIM (mt)∩(M NEW (cs)∪M OV R(cs)

NSI (mt, m2)

Since M I (mt) = M I (ms), we have:

=

c2∈Others(cs)

m1∈M

I(c2)

m2∈


NSI (m1, m2)

+

m2∈SIM (ms)∩(M NEW (cs)∪M OV R(cs)

NSI (ms, m2)

Since ∀c2 ∈ Others(cs) : M I (c2) = M I (c2), and ∀m1 ∈ M I (c2) : M I (m1) =MI (m1) we have:

=

c2∈Others(cs)

m1∈M I(c2)

m2∈


NSI (m1, m2)

+


N SI (ms, m2)

= OMMEC (cs)+


N SI (ms, m2)

Which means that after applying Replace Method with Method Object,OMMEC (cs) will be increased with the number of static invocations from ms

to new and overridden methods implemented by cs.


Informally – The number of classes by which cs is used or which cs usesitself will alter depending on the number of classes which ms used but the othermethods in M I (cs) did not. Moreover, CBO(cs) will contain ct.




Formally –

The CBO metric value after applying Replace Method with Method Objectis:

CBO(cs) =| CBOSet(cs) | with CBOSet(cs)

=

d ∈ C \{cs} |

mc∈M I(cs)

uses(mc, d)∨md∈M I(d)uses(md, cs)

Our tactic for formally deriving the impact is the following. We first split

up CBOSet(cs) in two parts. A part not involving ms, and a part involvingms.

=

d ∈ C \{cs} |

mc∈

M I(cs)\{ms}

∪{ms}

uses(mc, d)∨md∈M I(d)uses(md, cs)

=

d ∈ C \ {cs} |

mc∈M I(cs)\{ms}

uses(mc, d) ∨ uses(ms, d)

∨md∈M I(d)


∪ AI (cs) ∩ AR(md) = ∅

=

d ∈ C \ {cs} |

mc∈M I(cs)\{ms}

uses(mc, d) ∨ uses(ms, d)

∨md∈M I(d)

(M I (cs) \ {ms}) ∩ P IM (md)

∪ AI (cs) ∩ AR(md) = ∅

∨md∈M I(d)

ms ∈ P IM (md)

Since {x ∈ X | a ∨ b} = {x ∈ X | a} ∪ {x ∈ X | b}, we can rewrite CBOSet(cs)to:

=

d ∈ C \ {cs} |

mc∈M I(cs)\{ms}uses(mc, d)

∨md∈M I(d)

(M I (cs)\{ms})∩P IM (md)

∪AI (cs)∩AR(md) = ∅

∪

d ∈ C \ {cs} | uses(ms, d) ∨md∈M I(d)

ms ∈ P IM (md)

The two parts therefore are:




• A part that is due to M I (cs) \ {ms}. This part will be called A, and isdescribed by

d ∈ C \ {cs} |

mc∈M I (cs)\{ms}uses(mc, d)

∨md∈M I (d)



We will demonstrate that this part will remain unchanged, aside the con-ditional inclusion of ct.

• A part that is due to ms. This part will be called B, and is described by


ms ∈ P IM (md)

We will demonstrate that this part will be affected.

At this time we will demonstrate in a sub-proof that A = A[∪ct].

Subproof – We first start by expanding A:

=

d ∈ C \ {cs} |

mc∈M

I(cs)\{ms}

uses(mc, d)

∨md∈M I(d)(M I (cs)

\{ms

})

∩P IM (md)∪

AI (cs)

∩AR(md)

=

∅Since C = C ∪ {ct}, we have:

=

d ∈ C \ {cs} |

mc∈M

I(cs)\{ms}

uses(mc, d)

∨md∈M I(d)


∪AI (cs)∩AR(md)

= ∅

∪

d ∈ {ct} |

mc∈M I(cs)\{ms}

uses(mc, ct)

∨md∈M

I

(ct)(M I (cs)

\{ms

})

∩P IM (md)∪

AI (cs)

∩AR(md)

=

∅It is trivial to derive the following from the postcondition: ∀c ∈ C \ {cs}, ∀m ∈M I (c), it holds that:

• M I (c) = M I (c)

• AI (c) = AI (c)

• P IM (m) = P IM (m)




• AR(m) = AR(m)

which gives:

=

d ∈ C \ {cs} |

mc∈M I(cs)\{ms}

uses(mc, d)

∨md∈M I(d)



∪

d ∈ {ct} |

mc∈M I(cs)\{ms}uses(mc, ct)

∨md∈M I(ct)



Since ∀mc ∈ M I (cs)\{ms}

: uses(mc, ct) = false, we can rewrite the second

term as follows:

=

d ∈ C \ {cs} |

mc∈M I(cs)\{ms}

uses(mc, d)

∨md∈M I(d)



∪d∈ {

ct

} |false

∨md∈M I(ct)



Since M I (ct) = {mct, mt}, and:

• ∪m∈M I(ct)

P IM (m)∩M I (cs)\{ms}

= P IM (ms)∩M I (cs)\{ms}

• ∪m∈M I(ct)

AR(m) ∩ AI (cs)

= AI (ms) ∩ AI (cs)

we can make the second part conditional (marked with square brackets):

=

d ∈ C \ {cs} |

mc∈M I(cs)\{ms}

uses(mc, d)

∨md∈M I(d)



∪ c ∈ {ct} |

P IM (ms) ∩ M I (cs) \ {ms} ∪ AI (ms) ∩ AI (cs)

= ∅




Since ∀d ∈ C \{cs}, ∀mc ∈ M I (cs)\{ms} : uses(mc, d) = uses(mc, d), we have:

=

d ∈ C \ {cs} |

mc∈M I (cs)\{ms}

uses(mc, d)

∨md∈M I (d)



∪ c ∈ {ct} |


= ∅

As this first term is identical to A, we have:

= A∪c ∈ {ct} |

P IM (ms) ∩ M I (cs) \ {ms}

∪ AI (ms) ∩ AI (cs) = ∅

Q.E.D. (Subproof)Summarizing, we have just demonstrated the condition under which A = A,

and under which A = A ∪ {ct}.At this time we will demonstrate in a new sub-proof the condition under

which B = B.

Subproof – We first start by expanding B

:

=


ms ∈ P IM (md)

Since C = C ∪ {ct}, we can write:

=


ms ∈ P IM (md)

∪ d ∈ {ct} | uses(ms, ct) ∨md∈M

I(ct)

ms ∈ P IM (md)

As the postcondition states that ms invokes both methods from ct, we have:

=


ms ∈ P IM (md)

∪ {ct}

Since ∀d ∈ C \ {cs} : uses(ms, d) = false, and since ∀d ∈ C \ {cs}, ∀md ∈M I (d) : P IM (md) = P IM (md):

=

d ∈ C \ {cs} | false ∨md∈M I(d)

ms ∈ P IM (md)

∪ {ct}




=

d ∈ C \ {cs} |

md∈M I(d)

ms ∈ P IM (md)

∪ {ct}

Since {x ∈ X | f (x)} = {x ∈ X | f (x) ∨ g(x)} \ {x ∈ X | f (x) ∧ ¬g(x)}, wehave:

=

d ∈ C \ {cs} | uses(ms, d) ∨ md∈M

I(d)

ms ∈ P IM (md)

\ d ∈C \ {cs} | uses(ms, d)

∪ d ∈ C \ {cs} | uses(ms, d) ∧md∈M I(d)

ms ∈ P IM (md)

∪ {ct}

=

B \

d ∈ C \ {cs} | uses(ms, d)∪ d ∈ C \ {cs} | uses(ms, d) ∧md∈M I(d)

ms ∈ P IM (md)

∪ {ct}Since (X \ Y ) ∪ Z = (X ∪ Z ) \ (Y \ Z ), we can rewrite to:

=

B∪d ∈ C \{cs} | uses(ms, d)∧md∈M I (d)

ms ∈ P IM (md)

\d ∈

C \ {cs} | uses(ms, d) ∧md∈M I(d)

ms ∈ P IM (md)

∪ {ct}

As

d ∈ C \ {cs} | uses(ms, d) ∧ md∈M I(d)

ms ∈ P IM (md)

⊂ B we cansimplify to:

=

B \ d ∈ C \ {cs} | uses(ms, d) ∧md∈M I(d)

ms ∈ P IM (md)

∪ {ct}

Which means that after refactoring, B will be reduced with all classes whichare unidirectionally coupled from ms but themselves implement no methodswhich call ms. However, ct will be added to B.

Q.E.D. (Subproof)When we combine the results of the subproofs for A and for B, we CBOSet=

= A ∪ B

= A∪c ∈ {ct} |


= ∅∪

B \ d ∈ C \ {cs} | uses(ms, d) ∧md∈M I(d)

ms ∈ P IM (md)

∪ {ct}

=

A ∪

B \d ∈ C \{cs} | uses(ms, d) ∧md∈M I(d)

ms ∈ P IM (md)

∪ {ct}




Since X ∪ (Y \ Z ) = (X ∪ Y ) \ (Y ∩ Z ) \ X

, we have:

=

(A ∪ B)

\

B∩d ∈ C \{cs} | uses(ms, d)∧md∈M I (d)

ms ∈ P IM (md)

\A

∪ {ct}

Since A ∪ B = CBOSet(cs), we have:

=

CBOSet(cs)

\

B∩d ∈ C \{cs} | uses(ms, d)∧md∈M I (d)

ms ∈ P IM (md)

\A

∪ {ct}

=

CBOSet(cs)

\


ms ∈ P IM (md)

∩ d

∈C

\ {cs

} |uses(ms, d)

∧md∈M I(d) ms

∈P IM (md) \

A∪ {ct}

=

CBOSet(cs)

\


ms ∈ P IM (md)

∩ d ∈ C \ {cs} | uses(ms, d) ∧md∈M I(d)

ms ∈ P IM (md)

\

d ∈ C \ {cs} |

mc∈M I (cs)\{ms}uses(mc, d)

∨ md∈

M I(

d)(M I (cs)

\ {ms

})∩

P IM (md) ∪ AI (cs)

∩AR(md)

=

∅

∪ {ct}

=

CBOSet(cs)

\

d ∈ C \ {cs} | uses(ms, d)




∧md∈M I(d)

ms ∈ P IM (md)

∧mc∈(M I(cs)\{ms}

¬uses(mc, d)

∧md∈M I(d)


∪AI (cs)∩AR(md)

= ∅

∪ {ct}Since | A \ B | =| A | − | B | on the condition that B ⊆ A, we have CBO(cs)

= | CBOSet(cs) |− | d ∈ C \ {cs} | uses(ms, d)

∧md∈M I(d)

ms ∈ P IM (md)

∧mc∈(M I(cs)\{ms}¬uses(mc, d)

∧md∈M I(d)

(M I (cs) \ {ms}) ∩ P IM (md)


= ∅ |+ | {ct} |

= CBO(cs)− | d ∈ C \ {cs} | uses(ms, d)

∧md∈M I(d)

ms ∈ P IM (md)

∧mc∈(M I(cs)\{ms}

¬uses(mc, d)

∧md∈M I(d) (M I (cs) \ {ms}) ∩ P IM (md)∪ AI (cs) ∩ AR(md) = ∅ |+ 1

= CBO(cs)− | d ∈ C \ {cs} | uses(ms, d)∧mc∈(M I(cs)\{ms}

¬uses(mc, d)

∧md∈M I(d)



= ∅ |+ 1

= CBO(cs)− | d ∈ C \ {cs} | uses(ms, d)

∧mc∈(M I(cs)\{ms}¬uses(mc, d) ∧ ¬uses(x, cs)

|+ 1

Which means that ct is added to CBOSet(cs), and that all the classes forwhich ms was the single cause of general coupling are removed.

B.4.4 Aggregated Import Coupling

The Data Abstraction Coupling metric value after applying Replace Methodwith Method Object is:




DAC (cs) =| {a | a ∈ AI (cs) ∧ T (a) ∈ C \ {cs}} |

Since C = C , AI (cs) = AI (cs) and ∀a ∈ AI (cs) : T (a) = T (a):

= | {a | a ∈ AI (cs) ∧ T (a) ∈ C \ {cs}} |= DAC (cs)

Which means that after applying Replace Method with Method Object,DAC (cs) will remain unchanged.


The Lack of Cohesion in Methods metric variant 5 value after applying ReplaceMethod with Method Object is:

LCOM 5(cs) =|M I(cs)|−

1|AI(cs)|

Pa∈A

I(cs)

|{m1|m1∈M I(cs)∧a∈AR(m1)}|

|M I(cs)|−1

Since M I (cs) = M I (cs) and AI (cs) = AI (cs), we have:

=|M Ics)|−

1|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈M I(cs)∧a∈AR(m1)}|

|M I(cs)|−1

= |M Ics)|−

1

|AI (cs)|P

a∈AI (cs)|{m1|m1∈M I (cs)\{ms}

∧a∈AR

(m1)}||M I(cs)|−1

−1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈{ms}∧a∈AR(ms)}|

|M I (cs)|−1

Since ∀m1 ∈ M I (cs) \ {ms}

: AR(m1) = AR(m1), and since AR(ms) = ∅we

have:

=|M Ics)|−

1|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈M I (cs)\{ms}

∧a∈AR(m1)}|

|M I(cs)|−1− 0

Since x = x + y − y, we have:

=|M Ics)|−

1

|AI (cs)|

P

a∈AI (cs)|{m1|m1∈M I (cs)\{ms}∧a∈AR(m1)}|

|M I(cs)|−1

−1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈{ms}∧a∈AR(ms)}|

|M I(cs)|−1

+1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈{ms}∧a∈AR(ms)}|

|M I(cs)|−1

=|M Ics)|−

1|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈M I(cs)∧a∈AR(m1)}|

|M I(cs)|−1

+1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈{ms}∧a∈AR(ms)}|

|M I(cs)|−1




= LCOM 5(cs)

+1

|AI (cs)|

Pa∈AI (cs)

|{m1|m1∈{ms}∧a∈AR(ms)}|

|M I (cs)|−1

= LCOM 5(cs) + |AR(ms)∩AI(cs)|


Which means that after applying Replace Method with Method Object,

LCOM 5(cs) will be increased proportionate to the number of attributes whichms references.


The Lack of Cohesion in Methods metric variant 1 value after applying ReplaceMethod with Method Object is:

LCOM 1(cs) =LCOM 1Set(cs)

with LCOM 1Set(cs)

={m1, m2} | m1, m2 ∈ M I (cs) ∧ m1 = m2

∧

AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅

Since M I (cs) = M I (cs) and A

I (cs) = AI (cs), we have:

={m1, m2} | m1, m2 ∈ M I (cs) ∧ m1 = m2

∧ AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅

Since M I (cs) =

M I (cs) \ {ms} ∪ {ms}, we have:

={m1, m2} | m1, m2 ∈

M I (cs) \ {ms} ∧ m1 = m2

∧ AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅

∪ {m1, ms

} |m1

∈ M I (cs)

\ {ms

}∧ AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅Since AR(ms) = ∅, and ∀m2 ∈

M I (cs) \ {ms}

: AR(m2) = AR(m2), wehave:

={m1, m2} | m1, m2 ∈

M I (cs) \ {ms} ∧ m1 = m2

∧ AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅∪ {m1, ms} | m1 ∈

M I (cs) \ {ms}




={m1, m2} | m1, m2 ∈ M I (cs) ∧ m1 = m2

∧ AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅\ {m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧ AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅∪ {m1, ms} | m1 ∈

M I (cs) \ {ms}

=

LCOM 1Set(cs) \ {m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧ AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅∪ {m1, ms} | m1 ∈

M I (cs) \ {m}

When we refer to the latter as (A \ B) ∪ C ), we can state that B ⊆ C , andtherefore this equals to A ∪ C = A ∪ (C \ A).

= LCOM 1Set(cs) ∪ {m1, ms} | m1 ∈ M I (cs) \ {m} \ LCOM 1Set(cs)

Let us focus on

{m1, ms} | m1 ∈ M I (cs) \ {m} \ LCOM 1Set(cs)

which

we symbolize as C \ LCOM 1Set(cs)

C \LCOM 1Set(cs) ={m1, ms} | m1 ∈

M I (cs)\{m}\LCOM 1Set(cs)

=

C \ (LCOM 1Set(cs) ∩ C )

={m1, ms} | m1 ∈

M I (cs) \ {m}\ LCOM 1Set(cs) ∩ {m1, ms} | m1 ∈

M I (cs) \ {m}={m1, ms} | m1 ∈

M I (cs) \ {m}\ {m1, m2} | m1, m2 ∈ M I (cs) ∧ m1 = m2

∧ AR(m1) ∩ AR(m2) ∩ AI (cs) = ∅∩ {m1, ms} | m1 ∈

M I (cs) \ {m}={m1, ms} | m1 ∈

M I (cs) \ {m}\ {m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧ AR(m1

)∩

AR(ms

)∩

AI

(cs

) =∅∩ {m1, ms} | m1 ∈

M I (cs) \ {m}={m1, ms} | m1 ∈

M I (cs) \ {m}\ {m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧ AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅={m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧ AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅




And therefore:

LCOM 1Set(cs) = LCOM 1Set(cs) ∪ (C \ LCOM 1Set(cs))

= LCOM 1Set(cs) ∪{m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧ AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅Since LCOM 1(cs) =| LCOM 1Set(cs) |, we have:

LCOM 1(cs) = LCOM 1(cs)+ | {m1, ms} | m1 ∈ M I (cs) ∧ m1 = ms

∧ AR(m1) ∩ AR(ms) ∩ AI (cs) = ∅ |Which means that after applying Replace Method with Method Object,

LCOM 1(cs) will be increased with the number of methods implemented by cs

which shared attribute references with ms.



Bibliography

[Arisholm and Sjøberg, 2004] Arisholm, E. and Sjøberg, D. I. K. (2004). Evalu-ating the effect of a delegated versus centralized control style on the maintain-ability of object-oriented software. IEEE Trans. Softw. Eng., 30(8):521–534.

[Beck and Cunningham, 1989] Beck, K. and Cunningham, W. (1989). A lab-oratory for teaching object oriented thinking. In OOPSLA ’89: Conferenceproceedings on Object-oriented programming systems, languages and applica-tions, pages 1–6, New York, NY, USA. ACM Press.

[Berard, 1993] Berard, E. V. (1993). Essays on Object-Oriented Software Engi-neering . Prentice-Hall, Inc., Englewood Cliffs, New Jersey.

[Bergantz and Hassell, 1991] Bergantz, D. and Hassell, J. (1991). Informationrelationships in prolog programs: how do programmers comprehend function-ality? Int. J. Man-Mach. Stud., 35(3):313–328.

[Biggerstaff et al., 1993] Biggerstaff, T. J., Mitbander, B. G., and Webster, D.(1993). The concept assignment problem in program understanding. In ICSE ’93: Proceedings of the 15th international conference on Software Engineer-ing , pages 482–498, Los Alamitos, CA, USA. IEEE Computer Society Press.

[Briand et al., 2001] Briand, L. C., Bunse, C., and Daly, J. W. (2001). A con-trolled experiment for evaluating quality guidelines on the maintainability of object-oriented designs. IEEE Trans. Software Engineering , 27(6):513–530.

[Briand et al., 1996] Briand, L. C., Daly, J., and Wust, J. (1996). A unifiedframework for coupling measurement in object-oriented systems. TechnicalReport ISERN-96-14, Fraunhofer Institute for Experimental Software Engi-neering, Kaiserslautern, Germany.

239



240 BIBLIOGRAPHY

[Briand et al., 1997] Briand, L. C., Daly, J., and Wust, J. (1997). A unifiedframework for cohesion measurement in object-oriented systems. TechnicalReport ISERN-97-05, Fraunhofer Institute for Experimental Software Engi-neering, Kaiserslautern, Germany.

[Briand et al., 1998] Briand, L. C., Daly, J., and Wust, J. (1998). A unifiedframework for cohesion measurement in object-oriented systems. Empirical Software Engineering , 3(1):65–117.

[Briand and Wust, 2001] Briand, L. C. and Wust, J. (2001). The impact of

design properties on development cost in object-oriented system. IEEE Trans.Software Engineering , 27(11):963–986.

[Brooks, 1978] Brooks, R. (1978). Using a behavioral theory of program com-prehension in software engineering. In ICSE ’78: Proceedings of the 3rd in-ternational conference on Software engineering , pages 196–201, Piscataway,NJ, USA. IEEE Press.

[Brooks, 1983] Brooks, R. (1983). Towards a theory of the comprehension of computer programs. International Journal of Man-Machine Studies, 18:543–554.

[Brown et al., 1998] Brown, W. J., Malveau, R. C., McCormick, III, H. W., andMowbray, T. J. (1998). AntiPatterns: refactoring software, architectures, and projects in crisis. John Wiley and Sons, Inc.

[Buschmann et al., 1996] Buschmann, F., Meunier, R., Rohnert, H., Sommer-lad, P., and Stal, M. (1996). Pattern-Oriented Software Architecture — ASystem of Patterns. John Wiley and Sons.

[Canfora et al., 1996] Canfora, G., Mancini, L., and Tortorella, M. (1996). Aworkbench for program comprehension during software maintenance. In Pro-

ceedings of the International Workshop on Program Comprehension , pages30–39.

[Chapin, 1988] Chapin, N. (1988). Software maintenance life cycle. In Proceed-ings of the International Conference on Software Maintenance, pages 6–13.

[Chung et al., 2000] Chung, L., Nixon, B., Yu, E., and Mylopoulos, J. (2000).Non-Functional Requirements in Software Engineering . Kluwer AcademicPublishers.



BIBLIOGRAPHY 241

[Coad and Yourdon, 1991] Coad, P. and Yourdon, E. (1991). Object-Oriented Design . Yourdon Press.

[Coolican, 2004] Coolican, H. (2004). Research Methods and Statistics in Psy-chology, fourth edition . Hodder Arnold.

[Corritore and Wiedenbeck, 1991] Corritore, C. and Wiedenbeck, S. (1991).What do novices learn during program comprehension? International Journal of Human-Computer Interaction , 3(2):199–222.

[Crosby et al., 2002] Crosby, M. E., Scholtz, J., and Wiedenbeck, S. (2002). Theroles beacons play in comprehension for novice and expert programmers. InProceedings of the 14th Workshop of the Psychology of Programming Interest Group.

[Davies, 2000] Davies, S. P. (2000). Expertise and the comprehension of object-oriented programs. In Blackwell, A. and Bilotta, E., editors, Collected Pa-pers of the 12th Annual Workshop of the Psychology of Programming Interest Group (PPIG-12), pages 61–66.

[Demeyer et al., 2002] Demeyer, S., Ducasse, S., and Nierstrasz, O. (2002).

Object-Oriented Reengineering Patterns. Morgan Kaufmann and DPunkt.

[Deursen and Moonen, 2002] Deursen, A. and Moonen, L. (2002). The videostore revisited - thoughts on refactoring and testing. In Marchesi, M.and Succi, G., editors, Proceedings of the 3nd International Conferenceon Extreme Programming and Flexible Processes in Software Engineering (XP2002), pages 71–76. University of Cagliari.

[Du Bois and Demeyer, 2003] Du Bois, B. and Demeyer, S. (2003). Accommo-dating changing requirements with EJB. In Proc. 9th Int’l Conf. on Object Oriented Information Systems, OOIS 2003 .

[Du Bois et al., 2004] Du Bois, B., Demeyer, S., and Verelst, J. (2004). Refac-toring – improving coupling and cohesion of existing code. In WCRE , pages144–151.

[Du Bois et al., 2005] Du Bois, B., Demeyer, S., and Verelst, J. (2005). Doesthe “refactor to understand” reverse engineering pattern improve programcomprehension? In CSMR, pages 334–343.



242 BIBLIOGRAPHY

[Du Bois et al., 2006] Du Bois, B., Demeyer, S., Verelst, J., Mens, T., and Tem-merman, M. (2006). Does God Class Decomposition Affect Comprehensibil-ity? In IASTED International Multi-Conference on Software Engineering ,pages 346–355.

[Engebretson and Wiedenbeck, 2002] Engebretson, A. and Wiedenbeck, S.(2002). Novice comprehension of programs using task-specific and non-task-specific constructs. In HCC ’02: Proceedings of the IEEE 2002 Symposia on Human Centric Computing Languages and Environments (HCC’02), page 11,Washington, DC, USA. IEEE Computer Society.

[Fichman and Moses, 1999] Fichman, R. G. and Moses, S. A. (1999). An in-cremental process for software implementation. Sloan Management Review ,40(2):39–52.

[Fix et al., 1993] Fix, V., Wiedenbeck, S., and Scholtz, J. (1993). Mental rep-resentations of programs by novices and experts. In CHI ’93: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 74–79,New York, NY, USA. ACM Press.

[Fowler, 1999] Fowler, M. (1999). Refactoring: Improving the Design of Existing Code. Addison-Wesley.

[Gamma et al., 1994] Gamma, E., Helm, R., Johnson, R., and Vlissides, J.(1994). Design Patterns: Elements of Reusable Object-Oriented Languagesand Systems. Addisson-Wesley.

[Griswold, 1991] Griswold, W. (1991). Program Restructuring as an Aid toSoftware Maintenance. PhD thesis, University of Washington.

[Jacobson et al., 1992] Jacobson, I., M.Christerson, Jonsson, P., and Over-gaard, G. (1992). Object-Oriented Software Engineering — A Use CaseDriven Approach . Addisson-Wesley.

[Johansson et al., 2001] Johansson, E., Wesslen, A., Bratthall, L., and Host,M. (2001). The importance of quality requirements in software platformdevelopment - a survey. hicss, 09:9057.

[Kataoka et al., 2002] Kataoka, Y., Imai, T., Andou, H., and Fukaya, T. (2002).A quantitative evaluation of maintainability enhancement by refactoring. InProc. Int’l Conf. Software Maintenance, pages 576–585. IEEE Computer So-ciety Press.



BIBLIOGRAPHY 243

[Khan et al., 1996] Khan, M. K., Rashid, M. A., and Lo, B. W. (1996). Atask-oriented software maintenance model. Malaysian Journal of Computer Science, 9(2):36–42.

[Khoshgoftaar et al., 2006] Khoshgoftaar, T. M., Seliya, N., and Sundaresh, N.(2006). An empirical study of predicting software faults with case-basedreasoning. Software Quality Control , 14(2):85–111.

[Kniesel and Koch, 2004] Kniesel, G. and Koch, H. (2004). Static compositionof refactorings. Sci. Comput. Program., 52(1-3):9–51.

[Koenemann and Robertson, 1991] Koenemann, J. and Robertson, S. P. (1991).Expert problem solving strategies for program comprehension. In CHI ’91:Proceedings of the SIGCHI conference on Human factors in computing sys-tems, pages 125–130, New York, NY, USA. ACM Press.

[Krasner and Pope, 1988] Krasner, G. E. and Pope, S. T. (1988). A cookbookfor using the model-view-controller user interface paradigm in smalltalk-80.J. Object-Oriented Programming , pages 26–49.

[Lange et al., 2005] Lange, C., Du Bois, B., Chaudron, M. R., and Demeyer,

S. (2005). An experimental investigation of uml modeling conventions. TUEindhoven CS-Report 06-14, to appear in UML/Models 2006.

[Larman, 2001] Larman, C. (2001). Applying UML and Patterns: An Introduc-tion to Object-Oriented Analysis and Design and the Unified Process. PrenticeHall PTR, Upper Saddle River, NJ, USA.

[Mantyla et al., 2004] Mantyla, M., Vanhanen, J., and Lassenius, C. (2004).Bad smells - humans as code critics. In ICSM , pages 399–408.

[McConnell, 1993] McConnell, S. (1993). Code complete: a practical handbook

of software construction . Microsoft Press, Redmond, WA, USA.

[McGregor and Kamath, 1995] McGregor, J. D. and Kamath, S. (1995). A psy-chological complexity measure at the domain analysis phase for an object-oriented system. Technical report, Clemson University.

[O Cinneide, 2001] O Cinneide, M. (2001). Automated Application of Design Patterns: a Refactoring Approach . PhD thesis, University of Dublin, TrinityCollege.



244 BIBLIOGRAPHY

[O’Brien and Buckley, 2001] O’Brien, M. P. and Buckley, J. (2001). Inference-based and expectation-based processing in program comprehension. In IWPC ’01: Proceedings of the 9th International Workshop on Program Comprehen-sion , page 71, Washington, DC, USA. IEEE Computer Society.

[Opdyke, 1992] Opdyke, W. (1992). Refactoring Object-Oriented Frameworks.PhD thesis, University of Illinois at Urbana-Champaign.

[Or-Bach and Lavy, 2004] Or-Bach, R. and Lavy, I. (2004). Cognitive activi-ties of abstraction in object orientation: an empirical study. SIGCSE Bull.,36(2):82–86.

[Page-Jones, 1992] Page-Jones, M. (1992). Comparing techniques by means of encapsulation and connascence. Commun. ACM , 35(9):147–151.

[Parnas, 1978] Parnas, D. L. (1978). Designing software for ease of extensionand contraction. In ICSE ’78: Proceedings of the 3rd international conferenceon Software engineering , pages 264–277, Piscataway, NJ, USA. IEEE Press.

[Pennington, 1987a] Pennington, N. (1987a). Comprehension strategies in pro-gramming. In Proc. 2nd Workshop on Empirical Studies of Programmers,pages 100–112. Ablex Publishing, Norwood, N.J.

[Pennington, 1987b] Pennington, N. (1987b). Stimulus structures and mentalrepresentations in expert comprehension of computer programs. CognitivePsychology , 19:295–341.

[Pfahl, 2001] Pfahl, D. (2001). An Integrated Approach to Simulation-Based Learning in Support of Strategic and Project Management in Software Or-ganisation . PhD thesis, Department of Computer Science, Univer- sity of Kaiserslautern.

[Rajlich and Cowan, 1997] Rajlich, V. and Cowan, G. S. (1997). Towards stan-

dard for experiments in program comprehension. In WPC , pages 160–161.

[Ramalingam and Wiedenbeck, 1997] Ramalingam, V. and Wiedenbeck, S.(1997). An empirical study of novice program comprehension in the impera-tive and object-oriented styles. In ESP ’97: Papers presented at the seventh workshop on Empirical studies of programmers.

[Riel, 1996] Riel, A. J. (1996). Object-Oriented Design Heuristics. Addison-Wesley Publishing Company.



BIBLIOGRAPHY 245

[Roberts, 1999] Roberts, D. (1999). Practical Analysis for Refactoring . PhDthesis, University of Illinois at Urbana-Champaign.

[Sahraoui et al., 2000] Sahraoui, H. A., Godin, R., and Miceli, T. (2000). Canmetrics help to bridge the gap between the improvement of oo design qualityand its automation? In Proc. International Conference on Software Mainte-nance, pages 154–162.

[Sajaniemi and Navarro-Prieto, 2005] Sajaniemi, J. and Navarro-Prieto, R.(2005). An investigation into professional programmers’ mental represen-tations of variables. In International Workshop on Program Comprehension ,

pages 55–64.

[Schuh and Punk, 2001] Schuh, P. and Punk, S. (2001). Objectmother: Easingtest object creation in xp. XP Universe Conference.

[Seng et al., 2005] Seng, O., Bauer, M., Biehl, M., and Pache, G. (2005). Search-based improvement of subsystem decompositions. In GECCO ’05: Proceed-ings of the 2005 conference on Genetic and evolutionary computation , pages1045–1051, New York, NY, USA. ACM Press.

[Shadish et al., 2002] Shadish, W. R., Cook, T. D., and Campbell, D. T. (2002).

Experimental and Quasi-Experimental Designs for Generalized Causal Infer-ence. Houghton Mifflin.

[Simon et al., 2001] Simon, F., Steinbruckner, F., and Lewerentz, C. (2001).Metrics based refactoring. In Proc. European Conf. Software Maintenanceand Reengineering , pages 30–38. IEEE Computer Society Press.

[Soloway and Ehrlich, 1984] Soloway, E. and Ehrlich, K. (1984). Empiricalstudies of programming knowledge. IEEE Trans. Software Engineering , SE-10(5):595–609.

[Soloway et al., 1988] Soloway, E., Lampert, R., Letovsky, S., Littman, D., and

Pinto, J. (1988). Designing documentation to compensate for delocalizedplans. Commun. ACM , 31(11):1259–1267.

[Stevens et al., 1974] Stevens, W. P., Myers, G. J., and Constantine, L. L.(1974). Structured design. IBM Systems Journal , 13(2):115–139.

[Tahvildari and Kontogiannis, 2002a] Tahvildari, L. and Kontogiannis, K.(2002a). On the role of design patterns in quality-driven re-engineering. InCSMR, pages 230–240.



246 BIBLIOGRAPHY

[Tahvildari and Kontogiannis, 2002b] Tahvildari, L. and Kontogiannis, K.(2002b). A software transformation framework for quality-driven object-oriented re-engineering. In ICSM ’02: Proceedings of the International Con- ference on Software Maintenance (ICSM’02), page 596, Washington, DC,USA. IEEE Computer Society.

[Tahvildari et al., 2003] Tahvildari, L., Kontogiannis, K., and Mylopoulos, J.(2003). Quality-driven software re-engineering. J. Syst. Softw., 66(3):225–239.

[Tichelaar, 2001] Tichelaar, S. (2001). Modeling Object-Oriented Software for

Reverse Engineering and Refactoring . PhD thesis, University of Bern.

[Tokuda and Batory, 2001] Tokuda, L. and Batory, D. (2001). Evolving object-oriented designs with refactorings. Automated Software Engg., 8(1):89–120.

[van Deursen et al., 2003] van Deursen, A., Marin, M., and Moonen, L. (2003).Aspect mining and refactoring. In Proceedings of the First International Workshop on REFactoring: Achievements, Challenges, Effects (REFACE03).University of Waterloo, Canada.

[van Emden and Moonen, 2002] van Emden, E. and Moonen, L. (2002). Java

quality assurance by detecting code smells. In Proceedings of the 9th Working Conference on Reverse Engineering . IEEE Computer Society Press.

[Vokac et al., 2004] Vokac, M., Tichy, W., Sjøberg, D. I. K., Arisholm, E., andAldrin, M. (2004). A controlled experiment comparing the maintainabilityof programs designed with and without design patterns replication in a realprogramming environment. Empirical Softw. Engg., 9(3):149–195.

[von Mayrhauser and Vans, 1995] von Mayrhauser, A. and Vans, A. M. (1995).Program comprehension during software maintenance and evolution. IEEE Computer , 28(8):44–55.

[Wake, 2003] Wake, W. C. (2003). Refactoring Workbook . Addison-WesleyLongman Publishing Co., Inc., Boston, MA, USA.

[Wheeldon and Counsell, 2003] Wheeldon, R. and Counsell, S. (2003). Makingrefactoring decisions in large-scale java systems: an empirical stance. CoRR,cs.SE/0306098.

[Wiedenbeck and Scholtz, 1989] Wiedenbeck, S. and Scholtz, J. (1989). Bea-cons an initial program comprehension. SIGCHI Bull., 21(1):90–91.



BIBLIOGRAPHY 247

thesis bart du bois

Documents