Department of Computer Science Tokyo Institute of Technology - - PowerPoint PPT Presentation

department of computer science tokyo institute of
SMART_READER_LITE
LIVE PREVIEW

Department of Computer Science Tokyo Institute of Technology - - PowerPoint PPT Presentation

Natthawute Sae-Lim, Shinpei Hayashi, and Motoshi Saeki Department of Computer Science Tokyo Institute of Technology INTRODUCTION 2 Code smell [1] An indicator of a design flaw or a problem in the source code One of the factors that cause


slide-1
SLIDE 1

Natthawute Sae-Lim, Shinpei Hayashi, and Motoshi Saeki

Department of Computer Science Tokyo Institute of Technology

slide-2
SLIDE 2

INTRODUCTION

2

slide-3
SLIDE 3

Code smell[1]

An indicator of a design flaw or a problem in the source code

One of the factors that cause technical debt Increases code component’s fault-proneness Refactoring

Duplicated Code

(Extract Method)

[1] M. Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999. 3

slide-4
SLIDE 4

Problem

4

The number of code smell is

  • verwhelming
slide-5
SLIDE 5

Code Smells Prioritization

5 [J. ASE 2016]

An Approach to Prioritize Code Smells for Refactoring

Vidal et al.

[SBSE 2013]

Prioritization of Code Anomalies based on Architecture Sensitiveness

Arcoverde et al.

[MTD 2015]

Towards a Prioritization of Code Debt: A Code Smell Intensity Index

Fontana et al. [ICSE 2016]

Technical Debt Prioritization using Predictive Analytics

Codabux et al.

[ICPC 2016]

Context-Based Code Smells Prioritization for Prefactoring

Sae-Lim et al.

slide-6
SLIDE 6

CONTEXT-BASED CODE SMELLS PRIORITIZATION

6

slide-7
SLIDE 7

Method A() { _____ _____ }

Problem

7

Method B() { _____ _____ _____ }

Blob

Method C() { _____ }

. . .

Code smell detection results

1st 50th 100th

I need to implement feature X in method A()

Relevant !

Method A() { _____ _____ }

Problem : Results from existing smell detector do not fit in this situation

. . .

Blob Blob

slide-8
SLIDE 8

Goal

8

Our technique

Smells that are relevant to developers’ context Original code smell detection result Proposed code smell detection result 1st 2nd 3rd nth . . . 1st 2nd 3rd nth . . .

slide-9
SLIDE 9

Approach overview

Bug 123 When click… Bug 123 When click… Bug 123 When click…

Change descriptions

Main() xxx;;

Source code

Scoring

1… 2… 3…

Prioritized smells List of modules List of smells Code smell detection TraceLab[1] Impact analysis

[2]

[1] B. Dit, E. Moritz, and D. Poshyvanyk, “A TraceLab-based Solution for Creating, Conducting, and Sharing Feature Location Experiments,”, ICPC2012 9 [2] https://www.intooitus.com/products/infusion

slide-10
SLIDE 10

Empirical Study

10

Our technique can prioritize code smells occurring in the modules that are going to be modified

ArgoUML JabRef jEdit muCommander

Code smells

Prioritize

1… 2… 3…

Prioritized smells Code smells Modification- based oracle VCS Compare

Conclusion

slide-11
SLIDE 11

Software change process[1]

Initiation Concept Location Impact Analysis Prefactoring Actualization Postfactoring Conclusion

[1] V. Rajlich, Software Engineering: The Current Practice. Chapman and Hall/CRC, 2011 Identify a module to be modified Identify a full set

  • f modules to be

modified Modify source code 11

Interaction History Version Control System

Referred Modules Modified Modules

slide-12
SLIDE 12

Mylyn

12

Task and application lifecycle management (ALM) framework for Eclipse.

slide-13
SLIDE 13

Mylyn

13

<InteractionEvent Delta="null" EndDate="2009-09-08 18:34:51.838 PDT" Interest="1.0" Kind="edit" Navigation="null" OriginId="org.eclipse.jdt.ui.CompilationUnitEditor" StartDate="2009-09-08 18:34:51.838 PDT" StructureHandle="=org.eclipse.mylyn.internal.context. ui{IContextUiHelpIds.java" StructureKind="java” />

Developer selects text in editor

slide-14
SLIDE 14

Software change process[1]

Initiation Concept Location Impact Analysis Prefactoring Actualization Postfactoring Conclusion

[1] V. Rajlich, Software Engineering: The Current Practice. Chapman and Hall/CRC, 2011 Identify a module to be modified Identify a full set

  • f modules to be

modified Modify source code 14

Interaction History Version Control System

Referred Modules Modified Modules

?

slide-15
SLIDE 15

Software change process[1]

Initiation Concept Location Impact Analysis Prefactoring Actualization Postfactoring Conclusion

[1] V. Rajlich, Software Engineering: The Current Practice. Chapman and Hall/CRC, 2011 Identify a module to be modified Identify a full set

  • f modules to be

modified Modify source code 15

Interaction History Version Control System

Referred Modules Modified Modules

?

Is our technique useful for referred context?

slide-16
SLIDE 16

EMPIRICAL STUDY

16

slide-17
SLIDE 17

Overview

17

Compare

1… 2… 3…

Prioritized smells Code smells Code smells Reference- based oracle Modification- based oracle VCS Interaction History Compare

Subject: MylynTask 3.07-3.21

slide-18
SLIDE 18

Result

18

uIs our technique useful for referred modules?

0.66 0.78

0.2 0.4 0.6 0.8 1 Modification-based Reference-based nDCG

Our technique can be useful to support both modified modules and referred modules

slide-19
SLIDE 19

Top 10 results

Rank Smell Type Class Name #RI #MI 1 God TasksUiInternal

7 4

2 God TasksUiPlugin

9 3

3 God TaskListIndex

3 1

4 God AbstractTaskEditorPage

3 2

5 God TaskDataManager

4 2

6 God TracRepositoryConnector

1 1

7 God AttachmentUtil

4 1

8 God SynchronizeTasksJob

3

9 Data TaskData

3

10 God BugzillaRepositoryConnector

2

19

#RI = Number of referring issues #MI = Number of modifying issues

slide-20
SLIDE 20

CONCLUSION

20

slide-21
SLIDE 21

Messages

Context-based code smells prioritization Modified Context Referred Context Can support both types of context

21