Algebraic reasoning for object-oriented programming

Abstract

We present algebraic laws for a language similar to a subset of sequential Java that includes inheritance, recursive classes, dynamic binding, access control, type tests and casts, assignment, but no sharing. These laws are proved sound with respect to a weakest precondition semantics. We also show that they are complete in the sense that they are sufficient to reduce an arbitrary program to a normal form substantially close to an imperative program; the remaining object-oriented constructs could be further eliminated if our language had recursive records. This suggests that our laws are expressive enough to formally derive behaviour preserving program transformations; we illustrate that through the derivation of provably-correct refactorings.

Extracting and Evolving Code in Product Lines with Aspect-Oriented Programming

“…Refactoring preconditions are a subtle issue in object-orientation [7,8] and in aspect-orientation [12]. Accordingly, the preconditions of some refactorings we present have improved slightly since our previous work, and the current work has been updated accordingly.…”

“…The process of defining programming laws and showing how these can be used to derive refactorings has also been addressed for for object-oriented languages [7]. Such research additionally formally proves not only the completeness of such set of laws, but also the correctness of each law, by relying on a weakest precondition semantics [9].…”

Laws of Programming for References

“…On the other hand, any variable or field having some K as its declared type does not store an object instance of K but a reference to it. This is the main difference of our language with respect to [6,8] where a copy semantics is adopted and variables/fields hold full objects.…”

“…Previous work [6,8] defines theories for objectorientation useful to prove transformations of programs such as refactorings. However, the language used in these works has copy semantics, lacking the concept of reference and, thus, restricting the refactorings that can be characterized.…”

A Minimal Set of Refactoring Rules for Object-Z

“…To bridge this gap between specification and implementation, specification refactoring rules have been proposed [7,8,9,11,2,5]. These allow the structure of a specification to be incrementally transformed to represent a given design.…”