A Model-driven Approach to Refactoring

1
A Model-driven Approach to Refactoring

• Tiago Massoni
• Software Productivity Group
• UFPE

2
Software Evolution

• Need to evolve
• Synchronism with ever-changing business
• Adaptive, perfective and corrective evolution
• But, in general, evolution degenerates structure!
• The more you change, the harder to change again

3
Improving Evolution

• Program refactoring
• Clean-up before further changes
• Improves O.O. programs keeping observable
  behavior
• Tool support
• Model refactoring
• Abstraction
• Cheaper design exploration
• Model-driven development
• Automated traceability is needed
• But hard to achieve in practice

4
Round-trip Engineering refactoring programs

• Rather concrete models
• Business rules from programs get lost

Program Refactoring
P1
P2
5
Round-trip Engineering refactoring models
Model Refactoring

• User-edited source code and regeneration are
  problematic
• MDA tools have similar
• problems

P1
P2
6
Contributions

• Structural model-based approach to refactorings
• Basis primitive laws for Alloy (on-going work)
• Definition of an analogous program transformation
  for each Alloy law
• Sequence of law applications in ROOL
• Given ROOL programs in conformance to an Alloy
  model
• Alloy laws conditions are sufficient to reason
  about the analogous transformation on ROOL
• Result reasoning of joint refactoring by
  considering only model refactorings

7
Contributions

• Make the results from our work available to
  UMLers
• Semantics for UML class diagrams
• Translational semantics based on Alloy
• Denotational semantics, using the same semantic
  model as Alloy
• Benefits Automatic analysis, laws, formal
  refactoring, model-based program refactoring

8
Content

• Laws
• Alloy
• ROOL
• Our approach to model-based refactoring
• UML Semantics

9
Algebraic Laws

• Define a notion of equivalence between language
  constructs
• Programs
• Models
• Define two semantics-preserving transformations
  (proven)
• Restructuring and stepwise development
• Clarify language constructs
• Axiomatic semantics

10
Laws for Alloy

• Alloy Modeling language
• Signatures (sets), relations and predicate logic
• Automatic analysis
• Laws for Alloy
• Composed to form coarse-grained laws
• Refactorings
• Based on an equivalence notion for object models
• Alphabet (S) and view (v)

11
Example Applying the Pull Up Relation Law
no (Account-ChAcc).x
x
Account
ChBook
Account


S,v
r
ChAcc
ChAcc
ChBook

S Account,ChAcc,ChBook,r v r ? x
12
Laws of Programming

• Formally define program transformations
• Laws for imperative programming Hoare et al.,
  Morgan
• Laws for object-oriented programming ROOL

13
ROOL

• Refinement Object-Oriented Language
• Formal object-oriented programming language
• Similar to Java, although sequential with a copy
  semantics
• A comprehensive set of primitive laws
• Laws for commands and classes
• Relative completeness normal form
• Proven to be behavior-preserving

14
Laws for ROOL

• Class Refinement
• Based on traditional data refinement
• Refinement by internal representation change
• Coupling invariant relate representations
• Extended to consider refinement of class
  hierarchies
• Laws composed to prove formal refactorings

15
Conformance of Programs to Alloy

• We delimit our notion of conformance
• Structures (signatures and relations) are
  implemented in the program
• Constraints from the model are satisfied at
  certain points during programs execution
• Model define invariants on how the heap of the
  object-oriented program will be organized at
  these points

16
Combining Laws Push Down Relation
checks
Account
ChBook

no (Account ChAcc).checks
SavAcc
ChAcc
//Any other class Chbook cb new ChBook Account
acc ... if acc is ChAcc -gt acc.checks cb ...
abstract class Account pub checksChBook ... meth
m (pds ... a self.checks ...
class ChAcc extends Account new self.checks
new ChBook ...
class SavAcc extends Account new self.checks
null ...
17
Combining Laws

• Source code in conformance with the structural
  model
• Law application on the model is OK
• But several program constructs prevent program
  refactoring
• Usual pre-conditions are not fullfilled

Satisfies heap invariants
18
Example Push Down Relation
checks
Account
Account
ChBook
ChBook

checks

SavAcc
ChAcc
SavAcc
ChAcc
no (Account ChAcc).checks
19
Our Approach

• Define a sequence of transformations that are
  analogous to the modeling law
• Fixing those red fragments
• Then pushing down the attribute
• Fixing the fragments
• Transfer the model invariant to the program
• Use ROOL laws to rewrite those code fragments
• Defining an analogous transformation
• Tactics language
• Step-by-step guiding the rewritings in a formal
  way

20
Our Approach
class SavAcc extends Account new self.checks
null ...

• Assumption
• self is SavAcc self.checks null
• Applying model invariant
• selfltAccount and !(selfltChAcc)gt self.checks
  null
• self.checksnull self.checks null
• Simple specification
• self.checksself.checksnull,self.checksnull
• Trivially
• skip

21
Our Approach
//Any other class Chbook cb new ChBook Account
acc ... if acc is ChAcc -gt acc.checks cb ...

• Assumption (law is test true)
• if acc is ChAcc -gt acc is ChAcc acc.checks
  cb
• Introduce cast
• if acc is ChAcc -gt ((ChAcc)acc).checks cb

22
Our Approach
abstract class Account pub checksChBook ... meth
m (pds ... a self.checks ...

• Considering two distinct cases
• self is ChAcc or !(self is ChAcc)
• This leads to an if statement
• if (self is ChAcc) -gt a ((ChAcc)self).checks
• !(self is ChAcc)-gt a null

23
Push Down Attribute Transformation

• Push Down Attribute (M1 model, P1 program, A
  attribute)
• if P1 not structured as M1
• id(P1)
• else
• if A.modifier pri
• apply ltpri-pubgt
• for each writing violation
• case 1(as in SavAcc) replace by skip
• case 2(as in other class) specialized
  casting
• ...
• for each reading violation
• case 1(as in Account)replace by an if stat.
• ...
• apply ltmove attribute to superclass(right-left)(A
  )gt
• if old(A.modifier) pri
• apply ltself-encapsulate-field(A)gt

24
Example Push Down Relation
Account
ChBook
checks

SavAcc
ChAcc
//Any other class Chbook cb new ChBook Account
acc ... if acc is ChAcc -gt ((ChAcc)acc).check
s cb ...
abstract class Account meth m (pds ... if
(self is ChAcc)-gt a ((ChAcc)self).checks
!(self is ChAcc)-gt a null ...
class SavAcc extends Account new skip ...
class ChAcc extends Account pub
checksChBook new self.checks new ChBook ...
25
Benefits of our Solution

• Application of refactoring to models
• Automatic replication to source code
• No need for manual updates or round-trip
• Model constraints are maintained
• Smart refactorings
• Based on the models constraints

26
Benefits of our Solution

• Possible composition of laws
• Application of refactoring just as possible in
  models
• For each modeling law ? two correspondent program
  transformations
• Tool support
• May be used to horizontal consistency between
  views of a model
• Class diagrams driving changes to interaction
  diagrams

27
Possible Limitations

• We rely on conformance of source code
• Hard to check automatically
• Identifying potential problems (red fragments)
• Efficiently implementable?
• We have to change the program in unexpected
  ways
• Renaming, self-encapsulate field
• Alloys references and ROOLs copy semantics
• To be investigated

28
Assumptions

• Constrained conformance
• How models are implemented (alphabet may help)
• Tactics language
• Not sure if its the best representation
• Transfer the results to Java
• Aliasing
• Fitting model-based refactoring into evolution
  process
• What about evolutionary changes that are not
  refactoring?

29
UML Translational Semantics
fact BankProperties Account ChAcc all
aAccountlone a.accs bk accs sig Bank
accs set Account sig Account bk set
Bank sig ChAcc extends Account
30
UML Translational Semantics

• A set of translation rules
• Representing class diagrams with OCL by using
  Alloy
• Tool support for translation
• Benefits
• Alloys automatic analysis to UML
• Leveraging work with Alloy
• Laws and refactoring
• Equivalence notion
• Model-based refactoring

31
UML Translational Semantics

• Possible limitations
• Translational semantics may not work well
• Some UML concepts are not representable in Alloy
• Alternative Provide a denotational semantics to
  class diagrams, using same semantic model as
  Alloy
• Dependency on UML standards and the Alloy
  Analyzer API

32
Status

• Three modeling laws have been addressed
• Correspondent program transformations in tactics
  format
• Approaches to conformance have been investigated
• Aim Investigate the whole set of modeling laws
• Translation rules from UML to Alloy have been
  defined in detail
• Currently developing tool support
• Analysis of limitations in order to assess the
  need for an alternative approach

33
A Model-driven Approach to Refactoring

• Tiago Massoni
• Software Productivity Group
• UFPE

34
Another Example Introduce Relation
owned
Customer
Customer
Car
Car

owned exp

• Pre-conditions
• To introduce owned as relevant (in S), it must
  depend on pre-defined relations (or be empty), as
  recorded in the view by owned exp
• Customer itself or its family do not declare any
  relation named owned

35
Applying transformation to program

• We must not only introduce the attribute
• We should also make the program conform to the
  invariant (ownedexp)
• We identified three basic ways to define a new
  relevant relation
• exp empty
• exp another relation r
• exp a composition of relations s.t (using an
  auxiliar signature)
• Solution Apply class refinement
• coupling invariant based on the invariant owned
  exp

36
Applying transformation to program

• exp empty
• Add new attribute to Customer
• CI self.owned null
• Augment constructor
• self.owned null

• exp t
• Add new attribute to Customer
• CI self.t self.owned
• Maintain reads, guards and method calls to t
• For each write, augment assignment
• self.t,self.owned a,a

37
Applying transformation to program
owned
Car
Customer
s
t
Aux

• exp s.t
• Add new attribute to Customer
• CI !(self.snull)gt self.ownedself.s.t,
• self.ownednull
• Maintain reads, guards and method calls to
  self.s, self.s.t
• For each write to self.s.t, augment assignment
• self.s.t,self.owned a,a

38
Applying transformation to program

• For each write to self.s, augment specialized
  assignment
• if !(anull)-gt self.s,self.owned a, a.s
  (anull)-gt self.s,self.owned a,null

owned
Car
Customer
s
t
Aux
39
Thesis

• Hypothesis
• For each relation Rm M-gtM
• found a relation Rp P-gtP
• Theres a conformance relation CONF P-gtM
• Thesis
• (all m1,m2M, p1P
• (p1,m1) in CONF (m1,m2) in Rm)
• gt
• (some p2P
• p1 ! p2 (p1,p2) in Rp (p2,m2) in CONF)