recommending refactorings based on team co-maintenance patterns

Post on 27-Nov-2014

557 Views

Category:

Presentations & Public Speaking

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

Refactoring aims at restructuring existing source code when undisciplined development activities have deteriorated its comprehensibility and maintainability. There exist various approaches for suggesting refactoring opportunities, based on diff erent sources of information, e.g., structural, semantic, and historical. In this paper we claim that an additional source of information for identifying refactoring opportunities, sometimes orthogonal to the ones mentioned above, is team development activity. When the activity of a team working on common modules is not aligned with the current design structure of a system, it would be possible to recommend appropriate refactoring operations|e.g., extract class/method/package|to adjust the design according to the teams' activity patterns. Results of a preliminary study conducted in the context of extract class refactoring show the feasibility of the approach, and also suggest that this new refactoring dimension can be complemented with others to build better refactoring recommendation tools.

TRANSCRIPT

04/09/2023

Recommending Refactorings based on Team Co-

Maintenance Patterns

Gabriele Sebastiano Nikolaos Massimiliano Rocco Gerardo

Bavota Panichella Tsantalis Di Penta Oliveto Canfora

04/09/2023

Outline

Context and Motivations- Software Development- Team based Refactoring (TBR) for restructuring

source code

Case Study- User Study: releases of the Android APIs

Results- Evaluation of TBR and comparison with the state of the art

04/09/2023

Refactoring is…

‘‘…a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior’’. [Fowler 1999]

04/09/2023

Refactoring Sources of Information

- Refactoring operation need to capturing relation between code components.

- Various are the explored sources of information:

- Structural (Static and Dynamic);

- Semantic;

- Historical.

04/09/2023

Structural Information

- calls between methods, shared attributes, call relationships occurring during program execution.

Pros: - precise

information;- easy to capture;- always available.Cons:- may be imprecise;- may miss some kinds of dependencies.

04/09/2023

Semantic Information

04/09/2023

Semantic Information

- Textual similarity between code components.

04/09/2023

Semantic Information

Pros: - easy to capture;- always available.Cons:- Assumption that

terms are consistently used in the code

- Textual similarity between code components.

04/09/2023

Historical Information

Fabio Palomba et al. in ‘’Detecting bad smells in source code using change history information.’’’  - ASE 2013.

04/09/2023

Historical Information

Fabio Palomba et al. in ‘’Detecting bad smells in source code using change history information.’’’  - ASE 2013.

04/09/2023

Historical Information

Fabio Palomba et al. in ‘’Detecting bad smells in source code using change history information.’’’  - ASE 2013.

Pros: - precise information.Cons:- too strong to capture.

04/09/2023

Are we Missing other Kinds of Dependencies?

04/09/2023

Software development is a very human intensive activity….

Are we Missing other Kinds of Dependencies?

04/09/2023

Social Dimension

Time interval considered

04/09/2023

Social Dimension

Time interval considered

04/09/2023

Team-based Refactoring Opportunity

04/09/2023

Extract Class

Team-based Refactoring Opportunity

04/09/2023

Our ContributionTeam Based Refactoring (TBR):Information derived from teams to identify refactoring opportunities.

04/09/2023

Our Contribution

1) Teams identification

2) Detection of Refactoring opportunities (e.g. extract class refactoring)

Team Based Refactoring (TBR):Information derived from teams to identify refactoring opportunities.

04/09/2023

Teams Identification

Time

04/09/2023

Teams Identification

Time

Time window considered

04/09/2023

Teams Identification

Time

Time window considered

Class 1

Class 3

Class 2

Class 4

04/09/2023

Teams Identification

Time

Time window considered

Class 1

Class 3

Class 2

Class 4

04/09/2023

Teams Identification

Time

Time window considered

Class 1

Class 3

Class 2

Class 4

04/09/2023

Teams Identification

Time

Time window considered

Class 1

Class 3

Class 2

Class 4

04/09/2023

Teams Identification

Time

Time window considered

Class 1

Class 3

Class 2

Class 4

Ward's hierarchical clustering

04/09/2023

Detection of Refactoring Opportunities

Time window considered

1) Existence of a set of methods owned by a Team

Class 1

Class 3

Class 2

Class 4

04/09/2023

Detection of Refactoring Opportunities

Time window considered

1) Existence of a set of methods owned by a Team

2) Splitting classes with many responsabilities

Class 1

Class 2

Class 4Class 3

Class 2 –a)

Class 2 –b)

04/09/2023

Detection of Refactoring Opportunities

Time window considered

1) Existence of a set of methods owned by a Team

2) Splitting classes with many responsabilities

Class 2 –a)

Class 2 –b)

Class 1

Class 3

Class 2

Class 4

04/09/2023

Case Study

Goal: evaluate and compare the quality of the refactoring solutions identified by TBR with approaches based on more traditional sources.

Research questions:

• RQ1: Is the information derived from teams useful to identify refactoring opportunities?

• RQ2: Is the information derived from teams complementary to the sources of information typically exploited to identify refactoring opportunities?

04/09/2023

Context

•Objects:

•Subjects:

2 PhD students1 Industrial developer

Project from Andr. Api Period KLOC

framework-opt-telephony

Aug 2011-Jan 2013 73-78

framework-base Oct 2008-Jan 2013 534-1,043

framework-support Feb 2011-Nov 2012 58-61

sdk Oct 2008-Jan 2013 14-82

tool-base Nov 2012-Jan 2013 80-134

04/09/2023

RQ1: Is the information derived from teams

useful to identify refactoring opportunities?

Medium/Low perceived effort

Useful Refactoring solutions

78%

74%

22%

26%

NO YES

04/09/2023

RQ1: Is the information derived from teams

useful to identify refactoring opportunities?

Medium/Low perceived effort

Useful Refactoring solutions

78%

74%

22%

26%

NO YES

04/09/2023

RQ1: Is the information derived from teams

useful to identify refactoring opportunities?

Medium/Low perceived effort

Useful Refactoring solutions

78%

74%

22%

26%

NO YES

RQ2: TBR complementarity with other sources typically used for identifying refactoring

opportunities

Evaluation: MoJoFM

RQ2: TBR complementarity with other sources typically used for identifying refactoring

opportunities

Evaluation: MoJoFM

C1 C2

1

2 34

1

2 54

6

MoJoFM = 0 move + 0 join = 0= 1= 21 move 2 move

3

6

5

RQ2: TBR complementarity with other sources typically used for identifying refactoring

opportunities

Evaluation: MoJoFM

C1 C2

1

24

1

2 54

MoJoFM = 2 move + 0 join = 2= 3= 41 join2 join

63

3

6

5

3 move = 5

5

RQ2: TBR complementarity with other sources typically used for identifying refactoring

opportunities

Evaluation: MoJoFM

C1 C2

1

24

1

2 54

MoJoFM = 3 move + 3 join = 5= 63 join

3

6

5

63

max(∀ mno(Ci,Cj)max(∀ mno(Ci,Cj)

Structural U Semantic U Historical

Structural Semantic Historical0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

70%

30%

43%35%

RQ2: TBR complementarity with other sources typically used for identifying refactoring

opportunities

Structural U Semantic U Historical

Structural Semantic Historical0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

70%

30%

43%35%

30%

RQ2: TBR complementarity with other sources typically used for identifying refactoring

opportunities

04/09/202341

Conclusion

04/09/202342

Conclusion

04/09/202343

Conclusion

04/09/202344

Conclusion

04/09/202345

Conclusion

top related