2. Index
Related Work
– Assertions
– Design by Contract
– Refactoring
A novel refactoring classification
– Classification
– ARS
Self Encapsulate Field
Proof of Concept Application
Conclusions
Future Work
4. Assertions (I)
“Assertions are formal constraints on software
system behavior that are commonly written as
annotations of the source text. The primary goal in
writing assertions is to specify what a system is
supposed to do rather than how it is to do it.”
(Rosenblum)
From the above citation:
– State variables of a program in execution.
– Matches with OO paradigm
5. Assertions (II)– Why to use them
A way of documentation (better than comments)
Save a lot of the debugging time
Define the specifications of a OO program
Certain code confidence (more key properties covered with
them, greater degree of confidence)
– Problems:
How to decide whether an assertion is useful or not? (how many times
it is raised? Is there any other criterion?)
How to measure assertion correctness?
6. Design by Contract (DbC)
Represents the relationships between a class and its clients as a formal
agreement
Contract: “If the client guarantees certain preconditions, the supplier establishes
certain results. Otherwise the supplier does not guarantee nothing” (Meyer)
Correctness defined by DbC
– A code is not correct by itself, but respect its specification
– Class is correct only if its implementation is consistent with the Preconditions,
Postconditions and Class Invariant
– If a class is equipped with assertions it is possible to define formally what it means for
the class to be correct
Meyer describes some rules in order to guarantee the correctness of assertions
7. Refactoring in OO Software
Refactoring: behaviour-preserving transformations during
maintenance (Fowler 99)
There are manual and automatable refactorings
Refactoring only addresses modifications to the class structure
of an application
Improves the maintenance of a software project
Automatable refactorings need to hold some preconditions in
order to apply a refactoring properly
8. A novel refactoring classification
Classification
ARS
– Self Encapsulate Field
– Proof of Concept Application
9. A novel refactoring classification (I)
We can classify refactorings in three main
categories depending on how they affect
assertions:
– Trivial Assertion Maintenance
We don’t do anything (ex: Rename Refactoring)
variableX = 10;
assert(variableX > 0);
X = 10;
assert(x>0);
10. A novel refactoring classification (II)
– Manual refactorings (require assertion
redefinition)
We are not able to automate them because:
– We need to know the meaning of what the developer
wants to do
– The functionality of some assertions have changed
Prompt the developer (like compilation warnings)
Ex: Remove Parameter Refactoring
Function method(int a, int b, int c)
assert(a+b+c != 0); //Precondition
11. A novel refactoring classification (III)
– Automatable refactorings (require changes)
It is possible to automate the assertion maintenance
We add some steps to the refactorings: ARS
The criterion for assertion correctness: Design by
Contract (DbC)
– Even the code was not following Design by Contract, if we
guarantee the new changes will follow it, we can
guarantee the correctness of the resulting assertions
– With the help of Meyer’s assertion rules
We gave a small pattern in order to classify
and maintain any refactoring
12. ARS
We described and demonstrated formally the
assertion maintenance through the following
refactorings:
– Pull Up Field
Trivial Assertion Maintenance
– Pull Up Method
Automatable
– Self Encapsulate Field
Automatable
For a matter of time, we are going to focus the
presentation in Self Encapsulate Field
13. Self Encapsulate Field (I)
Encapsulate a field, creating its setting and getting
methods
ARS: Added in Fowler’s steps:
A
+ Field: type
A
- Field: type
type get_field()
set_field(type)
1) Create getting and setting methods for the field
a. Add a precondition to the setting method which checks
whether the value we are going to assign is inside the range
of allowed values for the field according to the CI. This can
be extracted from the CI
b. Add a postcondition to the setting method to check whether
the value of the field has been changed for the one passed
in the setting method
c. Add a precondition and a postcondition to the getting
method to check whether the variable we are going to return
is the correspondent field
d. Add the checking of the Class Invariant before the ending of
14. Self Encapsulate Field (II): Data
Extraction from Predicates
We demonstrated formally that we could extract the setting
method precondition from the Class Invariant
We show those steps which we also demonstrated:
I. Forging a Binary Tree from the CI predicate
II. Mark the leaves where the filed apperars
III. Applying ASR and OSR substitution rules to the tree
o AND Substitution Rule (ASR)
In an AND node substitute a branch for TRUE if:
1) None of its sub-branches has a marked leaf
2) None of its branch predecessors is an OR node
o OR Substitution Rule (OSR)
In an OR node substitute the whole node for TRUE if:
1) None of its branches and sub-branches have a marked leaf
2) None of its branch predecessors is an OR node
IV. Logical Simplification of the result tree
V. Replace field for the setting parameter name
VI. Reconstructing the Precondition from the tree
15. Self Encapsulate Field (III): Data
Extraction from Predicates
We give an example to show how it works. Let us suppose we
want to encapsulate Year field:
CI = Title ≠ null AND
(Director ≠ null →
directorsDatabase.exists(Director)) AND
(hasIntValue(Year) AND intValue(Year)>0 AND
intValue(Year) <= getCurrentYear())
Movie
Title: String
Director: String
Year: char[4]
getTitle(): String
getDirector(): String
AND
AND
AND
NOT Title ≠ null
NOT Director ≠ null
directorsDatabase.exists(Director)
OR
ANDhasIntValue(Year)
intValue(Year)>0 intValue(Year)<=getCurrentYear()
set_year(char[4] theYear)
16. Self Encapsulate Field (IV): Data
Extraction from Predicates
Following the steps we reach the precondition
AND
ANDhasIntValue(theYear)
intValue(theYear)>0
intValue(theYear)<=getCurrentYear()
Pre = hasIntValue(theYear) AND
intValue(theYear)>0 AND
intValue(theYear) <=
getCurrentYear()
AND
AND
ANDhasIntValue(theYear)
intValue(theYear)>0
intValue(theYear)<=getCurrentYear()
AND
NOT Title ≠ null
NOT Director ≠ null
directorsDatabase.exists(Director)
OR
ASR
OSR
set_year(char[4] theYear)
17. Proof of Concept Application
We implemented an application to demonstrate that the procedure of extraction
the precondition of a setting method from a CI predicate is viable
19. Conclusions
We classified the refactorings in terms of their assertion
maintenance:
– Trivial Refactorings
– Automatable refactorings
– Manual Refactorings
We designed a pattern to help classifying other refactorings
We classified many of the current refactorings and also we have
formally described and demonstrated some of them
We described and demonstrated a procedure to extract the
precondition of a setting method from the class invariant
We implemented an small proof of concept application in order to
demonstrate the procedure is viable
Data extraction from logical predicates also useful for AI
applications
20. Future Work
Improve the data extraction from predicates procedure
– CNF optimization (Sheridan’s Compact Conversion Algorithm)
– Simplify by reducing logical predicates (Circumscription of a
predicate theory)
Integrate the implemented package, and the rest of
demonstrated automatable refactorings, into an existing
refactoring tool
Further research to classify and maintain more
refactorings, helped with the pattern given in this
dissertation
