with Search-Based Recommendation 1 Motivation Architectural - - PowerPoint PPT Presentation

▶
with search based recommendation
SMART_READER_LITE
LIVE PREVIEW

with Search-Based Recommendation 1 Motivation Architectural - - PowerPoint PPT Presentation

Dec 04, 2022 247 likes •681 views

Interactive and Guided Architectural Refactoring with Search-Based Recommendation 1 Motivation Architectural refactoring for solving technical debts An ideal design in mind A solution consisting of lots of low-level refactorings

slide-1
SLIDE 1

Interactive and Guided Architectural Refactoring with Search-Based Recommendation

1

slide-2
SLIDE 2

Motivation

  • Architectural refactoring for solving technical debts

– An ideal design in mind – A solution consisting of lots of low-level refactorings

Industrial architectural refactoring involves over 800 low-level refactoring steps [Tokuda & Batory, ASE’99].

  • Existing Approaches: fully automatic (optimize metrics)

– Metrics can hardly represent the design in mind – Users never in control

2

slide-3
SLIDE 3

Our solution: Refactoring Navigator

3

slide-4
SLIDE 4

Our solution: Refactoring Navigator

  • Input:

– Source: Current code implementation – Destination: A user-specified intended design

  • Output:

– A sequence of refactoring steps, developers can accept or reject

  • Give control back to the user:

– User provides target design – Use human feedback to improve recommendation

4

slide-5
SLIDE 5

Motivating Example: A Bus Monitor System

  • Main features:

– Receives dynamic bus operational information; – Show the operational information

  • n GUI;

– Update the bus operational information on different views in real time.

5

slide-6
SLIDE 6

Source: the code implementation

BusMonitor MapView TableView CurveView

Prob

  • blem

m 2: 2: God Class Problem m 1: 1: Inconv conveni enient ent Extensio xtension

6

slide-7
SLIDE 7

Destination: desired design

Monitor GUI Bus Data Abstract View Concrete View

7

slide-8
SLIDE 8

8

BusMonitor MapView TableView CurveView

Monitor GUI Bus Data Abstract View Concrete View

source destination ination refactoring ring path user r feedback ck

slide-9
SLIDE 9

9

BusMonitor MapView TableView CurveView

Monitor GUI Bus Data Abstract View Concrete View

source destination ination refactoring ring path user r feedback ck

slide-10
SLIDE 10

Gap between Source and Destination

Monitor GUI Bus Data Abstract View Concrete View

`

BusMonitor MapView TableView CurveView

10 10

slide-11
SLIDE 11

Step 1: move updateMapView() from BusMonitor to MapView

Monitor GUI Bus Data Abstract View Concrete View

`

BusMonitor MapView TableView CurveView updateMapView(…)

11 11

slide-12
SLIDE 12

Step 2: move updateTableView() from BusMonitor to TableView

Monitor GUI Bus Data Abstract View Concrete View

`

BusMonitor MapView TableView CurveView updateTableView(…)

12 12

slide-13
SLIDE 13

Monitor GUI Bus Data Abstract View Concrete View

`

BusMonitor MapView TableView CurveView AbstractView

Step 3: pull up update*View() from *View to a new abstract view; move it to Abstract View

updateTableView(…) updateMapView(…) updateView(…) updateCurveView(…)

13 13

User rejected

slide-14
SLIDE 14

Refactoring Navigator suggests another path…

14 14

slide-15
SLIDE 15

New Step 3: move updateCurveView() from BusMonitor to CurveView

Monitor GUI Bus Data Abstract View Concrete View

`

BusMonitor MapView TableView CurveView updateCurveView(…)

15 15

slide-16
SLIDE 16

Monitor GUI Bus Data Abstract View Concrete View

BusMonitor MapView TableView CurveView AbstractView

Step 4: pull up update*View() from *View to a new abstract view; move it to Abstract View

updateTableView(…) updateMapView(…) updateView(…) updateCurveView(…)

16 16

slide-17
SLIDE 17

Step 5: extract a BusData class; move it to Bus Data module

Monitor GUI Bus Data Abstract View Concrete View

BusMonitor MapView TableView CurveView AbstractView BusData

17 17

slide-18
SLIDE 18

1.Target Design Construction Target Model 2.Source Model Extraction 3.Reflexion Model Generation 4.Refactoring Path Calculation Source Model Source Code Reflexion Model Recommendations 5.User Examination User Feedback Accepted Recommendations 6.Recommended Step Execution

Approach

18 18

slide-19
SLIDE 19

1.Target Design Construction Target Model 2.Source Model Extraction 3.Reflexion Model Generation 4.Refactoring Path Calculation Source Model Source Code Reflexion Model Recommendations 5.User Examination User Feedback Accepted Recommendations 6.Recommended Step Execution

Approach

Key Step teps

19 19

slide-20
SLIDE 20

1.Target Design Construction Target Model 2.Source Model Extraction 3.Reflexion Model Generation 4.Refactoring Path Calculation Source Model Source Code Reflexion Model Recommendations 5.User Examination User Feedback Accepted Recommendations 6.Recommended Step Execution

Approach

20 20

slide-21
SLIDE 21

Reflexion Model Generation

  • A reflexion model:

– Source Model – Target Model – Mapping from source model to target model

Monitor GUI Bus Data Abstract View Concrete View

`

BusMonitor MapView TableView CurveView

21 21

slide-22
SLIDE 22

Mapping Source Model to Target Design

Monitor GUI Bus Data Abstract View Concrete View

BusMonitor MapView TableView CurveView

22 22

slide-23
SLIDE 23

Design-Implementation Difference Representation in Reflexion Model

Monitor GUI Bus Data Abstract View Concrete View

BusMonitor MapView TableView CurveView BusData

Conforma rmance nce Divergenc ence Absence ce

23 23

slide-24
SLIDE 24

1.Target Design Construction Target Model 2.Source Model Extraction 3.Reflexion Model Generation 4.Refactoring Path Calculation Source Model Source Code Reflexion Model Recommendations 5.User Examination User Feedback Accepted Recommendations 6.Recommended Step Execution

Approach Overview

24 24

slide-25
SLIDE 25

Refactoring Path Calculation

  • Aim:

– Improve the conformance of reflexion model

  • A search-based method

– Try various refactoring operations on source model to find the solution.

Monitor GUI Bus Data Abstract View Concrete View

`

BusMonitor MapView TableView CurveView

Monitor GUI Bus Data Abstract View Concrete View

BusMonitor MapView TableView CurveView AbstractView BusData

25 25

slide-26
SLIDE 26

Refactoring Path Calculation

  • Define basic refactoring operations to transform reflexion

model.

  • Quantify the conformance of a reflexion model.
  • Search algorithm w.r.t user feedback.

26 26

slide-27
SLIDE 27

Basic Refactorings

  • Move method

– Move a method from one class to another

  • Pull up field/method

– Extract and move similar fields/methods from multiple classes to their super class or interface.

  • Extract class (Tsantalis, N. and A. Chatzigeorgiou, JSS’11)

– Decompose a large class into smaller classes with higher cohesion

27 27

slide-28
SLIDE 28

Quantify reflexion model conformance

  • Metrics for a reflexion model, model

– Inconsistency

𝑶𝒕𝒖𝒔 = 𝑩𝒄𝒕 𝒏𝒑𝒆𝒇𝒎 + ෍

𝒆∈𝑬𝒋𝒘(𝒏𝒑𝒆𝒇𝒎)

|𝑻𝒔𝒅(𝒆)|

The e set of a absence ce edge in The e set of dive vergence ence edge in The e set of c code relation tion supporting ting a dive vergenc ence edge edge

A B

X

contr tribut ibute e 1 Suppose e X invokes es metho hods ds in Y 3 time mes, s, Z acces ess s fields s in Y 5 times, es, con

  • ntr

tribut ibute e 3+5=8 +5=8

A B

X Y Z

28 28

slide-29
SLIDE 29

Quantify reflexion model conformance

  • Metrics for a reflexion model, model

– Inconsistency – Lexical conformance

 Average lexical similarity

– Design quality metrics

Cohesion and coupling metrics

  • Overall metrics:

𝑶𝒕𝒖𝒔 = 𝑩𝒄𝒕 𝒏𝒑𝒆𝒇𝒎 + ෍

𝒆∈𝑬𝒋𝒘(𝒏𝒑𝒆𝒇𝒎)

|𝑻𝒔𝒅(𝒆)| 𝑻𝒋𝒏𝒎𝒇𝒚_𝒃𝒘𝒉 ∈ [𝟏, 𝟐) 𝑬𝑹𝒃𝒘𝒉 ∈ [𝟏, 𝟐) 𝑮𝒔𝒇𝒈 = −𝑶𝒕𝒖𝒔 − 𝑬𝑹𝒃𝒘𝒉 − 𝑻𝒋𝒏𝒎𝒇𝒚_𝒃𝒘𝒉 29 29

slide-30
SLIDE 30

Incorporating User Feedback

  • User feedback

– Reject refactorings – Accept refactorings

  • Rationale

– Refactorings similar to rejected refactorings should get penalty, while those similar to accepted refactoring should get reward.

30 30

slide-31
SLIDE 31

User feedback incorporation

  • Basic fitness for a refactoring (i.e., reflexion model

transformed by this refactoring) is:

  • If the refactoring is similar to m accepted refactoring and

n rejected refactoring, then

𝑮𝒔𝒇𝒈 = −𝑶𝒕𝒖𝒔 − 𝑬𝑹𝒃𝒘𝒉 − 𝑻𝒋𝒏𝒎𝒇𝒚_𝒃𝒘𝒉 𝑭𝒘𝒃𝒔𝒇𝒈 = 𝑮𝒔𝒇𝒈 × (𝟐 − 𝜷)𝒏× (𝟐 + 𝜸)𝒐

Reward ra rate te Penalty alty ra rate

31 31

slide-32
SLIDE 32

Search algorithm w.r.t user feedback

  • Hill-climbing algorithm

Curr rrent nt reflexion xion model Neig ighb hbors s (result ulted d reflexion xion models by applyin ing refactori rings) Detect ect all basic c refactor

  • rin

ing

  • pportunit

unities ies in the e source ce model

32 32

slide-33
SLIDE 33

Search algorithm w.r.t user feedback

  • Hill-climbing algorithm

Curr rrent nt reflexion xion model Best t neighb hbori

  • ring

ng reflexion xion model (with th highest hest conformance) rmance)

33 33

slide-34
SLIDE 34

Search algorithm w.r.t user feedback

  • Hill-climbing algorithm

Local l optima ma Escape (sub)optima ptimal l reflexion xion model

34 34

slide-35
SLIDE 35

Search algorithm incorporating user feedback

  • Hill-climbing algorithm

A r refactoring ring solut utio ion n consists sists of a a n numb mber er of refactoring ring step teps

35 35

slide-36
SLIDE 36

Tool: Refactoring Navigator

36 36

slide-37
SLIDE 37

Empirical Evaluation

37 37

slide-38
SLIDE 38

Controlled Experiment Settings

  • Subject system

– Written by an undergraduate student – Scope: 15 classes, 1 interface, 121 methods, 23 fields, 1010 LOC.

  • Participants

– 18 students are divided into equivalent groups:

Experimental group (EG): complete Refactoring Navigator Control group (CG): incomplete Refactoring Navigator (without recommendation) and JDeodorant plugin.

  • Task: Asked them to refactor subject system towards a

given design

38 38

slide-39
SLIDE 39

Experimental Results

Experimental Group (with complete Refactoring Navigator) Control Group (with incomplete Refactoring Navigator) Completion Time 13.3 36.4 #Passed Test Case 50.0 36.4 #LOC Edited Manually 6.0 354.1

39 39

Fas aster Saf afer Eas asier

slide-40
SLIDE 40

Replicating An Industrial Case Study

  • History and Scale

– Lifespan of 8 years, consisting of 40K LOC, 148 classes

  • Refactoring scope

– 8 classes of 5,823 LOC

  • Design problem:

– God Class – Entangling dependencies

40 40

slide-41
SLIDE 41

Refactoring Result

41 41

Before Refactoring After Refactoring #Conformance Dependency 9 27 #Divergence Dependency 10 3 #Absence Dependency 11

slide-42
SLIDE 42

Take-home message

  • Utilizing reflexion model and search-based technique is

promising to automate architectural refactoring.

  • Incorporating user feedback generates intuitive results
  • Future work: Supporting more types of basic refactorings

can improve our approach.

42 42