Refactoring

Program . . .
Refactoring: . . .
Our approach . . .
Source-to- . . .
Formal . . .
(Pattern- . . .
An example
Future directions Refactoring for Comprehension
Conclusions
Home Page
Gustavo Villavicencio
Facultad de Matemática Aplicada
Print Universidad Católica de Santiago del Estero
Title Page
Santiago del Estero, Argentina

JJ II

J I

Page 1 of 22

Go Back

Full Screen

Close
Refactoring
Program . . .
Refactoring: . . .
Our approach . . . 1. Refactoring
Source-to- . . .
Formal . . .
(Pattern- . . .
Concept from external link
An example
Refactoring is about “improving the design of existing code”
Future directions
and as such, it has been practised as long as programs have been
Conclusions
written. The term refactoring specifically refers to a common
Home Page
activity in programming and software maintenance: changing
Print
the structure of a program without changing its semantics.

Title Page Or maybe more precise, restructuring [1]

JJ II
Restructuring is the transformation from one representation
J I form to another at the same relative abstraction level, while
preserving the subject system’s external behavior (functionality
Page 2 of 22
and semantics).
Go Back

Full Screen

Close
Refactoring
Program . . .
Refactoring: . . .
Our approach . . .
Source-to- . . .
Formal . . .
2. Program comprehen-
(Pattern- . . .
An example
sion/Program Understand-
Future directions
Conclusions
ing/Reverse Engineering
Home Page
Reverse engineering is the process of analyzing a subject system
Print to
Title Page • identify the system’s components and their interrelation-
ships and
JJ II

J I
• create representations of the system in another form or at
higher level of abstraction
Page 3 of 22

Go Back

Full Screen

Close
Refactoring
Program . . .
Refactoring: . . .
Our approach . . .
3. Refactoring: Some tech-
Source-to- . . .
Formal . . .
niques (HaRe)
(Pattern- . . .
An example
• Structural refactorings: Generalisation
Future directions
Conclusions
• Renaming a definition
Home Page
• Changing the scope of a definition
Print
• Adding/Removing an argument
Title Page

JJ II Weakness:
J I
• Techniques applied in isolated and intuitive way
Page 4 of 22

Go Back
We are looking for a systematic refactoring strategy
Full Screen

Close
Refactoring 4. Our approach for refactoring
Program . . .
Refactoring: . . .
Our approach . . .
(1)
Source-to- . . . Pointwise notation / Subsidiary pointfree denotation
Formal . . . (2)
(Pattern- . . .  
Solution pointwise denotation
o (3)
Solution pointfree denotation
An example
Future directions
Figure 1: The reverse program calculation process
Conclusions
Home Page
• Phase (1): Source-to-source transformations
Print
– removing parameter accumulation
Title Page
• Phase (2): Formal refactoring
JJ II
– point-free calculus
J I – pattern driven
Page 5 of 22 • Phase (3): Reimplementation
Go Back – Haskell
Full Screen
– VDM-SL

Close
Refactoring 5. Source-to-source transformations
Program . . .
Refactoring: . . . During our experimentation we found that one of the most
Our approach . . . useful source-to-source transformation is removing parameter
Source-to- . . . accumulation. We show an example from [3].
Formal . . .
(Pattern- . . . reset0t([],test0,(possum,negsum)) = ([],test0,(possum,negsum))
reset0t(n:l,test0,(possum,negsum)) =
An example reset0t(l,test0,set_sum(n,test0,(possum,negsum)))
Future directions set_sum(n,test0,(ps,ns)) =
Conclusions if n==0 and test0 then
if ps>ns then
Home Page (0,ns)
else
Print (ps,0)
else
(ps,ns)
Title Page
Figure 2: Program example with two accumulation parameters
JJ II

J I
reset0tt([],test0) = (0,0)
Page 6 of 22 reset0tt(n:l,test0) = set_sum(n,test0,reset0tt(l,test0))

Go Back Figure 3: Program after removing accumulators

Full Screen

Close
Refactoring So, figure 3 may be handled by mutual recursion law, etc.
Program . . .
Refactoring: . . .
Our approach . . .
Source-to- . . .
Formal . . .
(Pattern- . . .
An example
Future directions
Conclusions
Home Page

Print

Title Page

JJ II

J I

Page 7 of 22

Go Back

Full Screen

Close
Refactoring 6. Formal Refactoring
Program . . .
Refactoring: . . . Many laws and properties applied during the refactoring
Our approach . . . phase are taken from the point-free calculus. But, here, for not
Source-to- . . . to be tedious, we show some of these related to co-product
Formal . . . and exponential only.
(Pattern- . . .
An example
Future directions 6.1. Co-product
Conclusions
To combine functions as f : C ←− A and g : C ←− B, we need
Home Page
injectors
Print

i1 i2
Title Page
A / A+Bo B
JJ II
defined as
J I

Page 8 of 22 i1 a = (t1 , a)
(1)
i2 b = (t2 , b)
Go Back

Full Screen Therefore, we combine f and g as follow

Close
Refactoring
Program . . . [ f, g] ( + B −→ C
A
:
Refactoring: . . . x = i1 a ⇒ f a
de f (2)
[ f, g] x =
Our approach . . . x = i2 b ⇒ g b
Source-to- . . .
operator named either. By mean of this, we define the co-
Formal . . . product of functions
(Pattern- . . .
An example de f
Future directions
f + g = [i1 · f, i2 · g] (3)
Conclusions Properties
Home Page
• Cancellation
Print
[ f, g] · i1 = f
(4)
Title Page [ f, g] · i2 = g
JJ II • Reflection
J I
[i1 , i2 ] = idA+B (5)
Page 9 of 22
• Fusion
Go Back

Full Screen f · [g, h] = [ f · g, f · h] (6)

Close
Refactoring • Absorption
Program . . .
Refactoring: . . .
[ f, g] · (i + j) = [ f · i, g · j] (7)
Our approach . . .
Source-to- . . . • Functor
Formal . . .
(Pattern- . . . ( f · g) + (i · j) = ( f + i) · (g + j) (8)
An example
Future directions • Functor-id
Conclusions
Home Page idA + idB = idA+B (9)
Print

6.2. Exponential
Title Page

To combine functions f : C × A −→ B and g : A −→ B . . . we

JJ II
“frozen” the C argument
J I

Page 10 of 22
fc : A −→ B
Go Back
de f
fc a = f (c, a)
Full Screen

Close
Refactoring thus, we have f c is a value of type B, but fc ∈ BA is a function!
Program . . .
Refactoring: . . . de f
BA = {g|g : A −→ B} (10)
Our approach . . .
Source-to- . . . From here, we design the apply operator
Formal . . .
(Pattern- . . . ap : BA × A −→ B
An example
de f
Future directions ap( f, a) = fa
Conclusions • Cancellation
Home Page
ap
BA × / f = ap · ( f × id) (11)
Print O A xx; B
xx
f ×id xxx
Title Page xx f
C×A
JJ II
• Reflexion
J I
ap
BA × / ap = idBA (12)
O A x; B
Page 11 of 22
xx
xx
Go Back
idBA ×id
xxx ap
x
Full Screen
BA × A

Close
Refactoring • Fusion
Program . . .
ap
Refactoring: . . .
BA × / g · ( f × id) = g · f (13)
O A ;B
Our approach . . . xxx

D
xx

Source-to- . . .
g×id
xxx g

Formal . . . C ×O A

g·( f ×id)

(Pattern- . . . f ×id

An example

D×A
Future directions
Conclusions • Absorption
Home Page
ap
DA × / DO f · g = fA · g (14)
Print O A
f A ×id f
Title Page ap
BA × /
O A w; B
JJ II www
ww
g×id
www g
w
J I
C×A
Page 12 of 22
where we use another functional combinator
Go Back

de f
Full Screen ( f A )g = f · g (15)
Close
Refactoring • Functor
Program . . .
Refactoring: . . .
(g · h) = gA · hA (16)
Our approach . . .
Source-to- . . . • Functor-id
Formal . . .
(Pattern- . . . idA = id (17)
An example
Future directions
Conclusions
Home Page

Print

Title Page

JJ II

J I

Page 13 of 22

Go Back

Full Screen

Close
Refactoring
Program . . .
Refactoring: . . .
Our approach . . .
Source-to- . . .
Formal . . .
(Pattern- . . .
7. (Pattern-driven) Formal Refactoring
An example
The calculated patterns lead the transformational process.
Future directions
Conclusions
• For list
Home Page

h|h|iNil = h1
Print (18)
h|h|iCons = h∗2 · τA,L · (id × h|h|i)

Title Page
• For Binary tree

JJ II (|h|)Lea f a = h1 a
(19)
(|h|) Join t1 t2 = h∗2 · ψ · ((|h|) × (|h|))(t1 , t2 )
J I

Page 14 of 22

Go Back

Full Screen

Close
Refactoring
Program . . .
Refactoring: . . .
Our approach . . .
Source-to- . . .
Formal . . .
(Pattern- . . .
An example 8. An example
Future directions
Conclusions
The example use a list datatype involving the
Home Page
monad State. But more experiments we have
Print
carried out on binary tree, for example, and
Title Page handling other side effects.
JJ II

J I

Page 15 of 22

Go Back

Full Screen

Close
Refactoring A commutative diagram is often used as a graphical tool to
Program . . . get a quick view of the function we are interested in.
Refactoring: . . .
Our approach . . .
Source-to- . . .
Lo
in
Formal . . . 1 + Int × L (20)
(Pattern- . . . h|sms|i id+id×h|sms|i
 
An example
(Int × S)S o ((1 + Int × Int) × S)S o 1 + Int × (Int × S)S
Future directions (h×idS )∗ δLInt

Conclusions
Home Page

Print

Title Page

JJ II

J I

Page 16 of 22

Go Back

Full Screen

Close
Refactoring The pattern-driven calculational/transformational process ap-
Program . . . plying, among others, properties and laws from the point-
Refactoring: . . . free calculus.
Our approach . . .
Source-to- . . .
Formal . . .
h|sms|i · in
(Pattern- . . .
= {(20)}
An example
Future directions
h × id • δLInt · (id + id × h|sms|i)
Conclusions = {distribution law definition}
Home Page i1 , b
h × id • [b i2 • τInt,L ] · (id + id × h|sms|i)
Print
= {kleisli composition definition}
i1 , b
(h × id)∗ · [b i2 • τInt,L ] · (id + id × h|sms|i)
Title Page
= {(6)}
∗ ∗
JJ II
i1 , (h × id) · b
[(h × id) · b i2 • τInt,L ] ·
J I (id + id × h|sms|i)
= {lifting functor definition}
Page 17 of 22
∗ ∗
[(h × id) · (unit · i1 ), (h × id) · (unit · i2 ) • τInt,L ] ·
Go Back
(id + id × h|sms|i)
Full Screen = {associativity and second kleisli triple property}
Close
Refactoring [(h × id) · i1 , (h × id) · i2 • τInt,L ] ·
Program . . .
(id + id × h|sms|i)
Refactoring: . . .
= {(14) in reverse}
Our approach . . .
Source-to- . . .
[(h × id) · (i1 × id), (h × id) · (i2 × id) • τInt,L ] ·
Formal . . . (id + id × h|sms|i)
(Pattern- . . . = {“bi-distribution” of × with respect to composition in reverse}
An example [(h · i1 ) × (id · id), (h · i2 ) × (id · id) • τInt,L ] ·
Future directions
(id + id × h|sms|i)
Conclusions
= {identity and h definition}
Home Page
[([0, +] · i1 ) × id, (([0, +] · i2 ) × id) • τInt,L ] ·
(id + id × h|sms|i)
Print

Title Page = {(4)}

JJ II [0 × id, (+ × id) • τInt,L ] · (id + id × h|sms|i)
= {(7) and kleisli composition definition}
J I
[0 × id, (+ × id)∗ · τInt,L · (id × h|sms|i)]
Page 18 of 22

Since in = [Nil, Cons] we can conclude that

Go Back

Full Screen

Close
Refactoring sms l = \s -> mfoldL(return 0, \x y -> do {c <- tick;
return(x+y)}) l
Program . . .
Refactoring: . . . Figure 7: sms function refactored by mfoldL operator
Our approach . . .
Source-to- . . . nmfoldL :: Monad m => (m a, b -> m a -> m a) -> [b] -> m a
nmfoldL (h1,h2) = mfl
Formal . . . where mfl [] = h1
(Pattern- . . . mfl (a:as) = h2 (a) (mfl as)

An example Figure 8: mfold operator for lists without distribution law

Future directions
Conclusions
Home Page

h|sms|iNil = 0 × idS
Print (21)
h|sms|i(Cons) = (+ × idS )∗ · τInt,L · (id × h|sms|i)
Title Page

Matching (21) and (18) . . .

JJ II

J I

Page 19 of 22
8.1. An alternative refactoring
But, in this case, we can show another way to refactor leaded
Go Back
by other pattern.
Full Screen

Close
Refactoring sms = \s -> nmfoldL(return 0,\e r -> do {c <- tick;
x <- r; return(e+x)})
Program . . .
Refactoring: . . . Figure 9: sms refactored by nmfoldL operator
Our approach . . .
Source-to- . . .
Formal . . .
(Pattern- . . .
An example
Future directions
Conclusions
Home Page
9. Future directions
Print • To analyze more complex cases involving monad
Title Page transformers
JJ II • To apply more abstract patterns as mentioned by
J I [2]
Page 20 of 22
• Patterns for specific domain problems?
Go Back
• Funtional setting for reengineering imperative
Full Screen
code?
Close
Refactoring
Program . . .
Refactoring: . . .
Our approach . . .
Source-to- . . .
Formal . . .
(Pattern- . . .
An example
Future directions
10. Conclusions
Conclusions
Home Page
• The refactoring process is pattern driven
Print • We can calculate specification
Title Page
• The patterns are calculated . . . not designed
JJ II

J I

Page 21 of 22

Go Back

Full Screen

Close
Refactoring References
Program . . .
Refactoring: . . . [1] E.J. Chikofsky and J. H. Cross II. Reverse engineering and design
Our approach . . . recovery: a taxonomy. IEEE Software, 7(1):13–17, 1990.
Source-to- . . .
[2] Jeremy Gibbons. Design patters as higher-order datatype generic
Formal . . .
programs. In Workshop on Generic Programming, Portland, Oregon,
(Pattern- . . . USA, September. ACM SIGPLAN.
An example
Future directions [3] G. Villavicencio. Reverse program calculation by conditioned slicing.
Conclusions In Proceedings of the 7th European Conference on Software Maintenance
Home Page and Reengineering, pages 368–378, Benevento, Italy, March 2003. IEEE
CS Press, California, USA.
Print

Title Page

JJ II

J I

Page 22 of 22

Go Back

Full Screen

Close