Oppgaven er ikke lenger tilgjengelig

Safer Refactorings

Refactorings are a common tool of the trade for programming. In general, they are assumed to be equivalent transformations of a program, to improve the quality of the source code with regard to a concrete or subjective software metric, such as coupling. Alas, some seemingly intuitive refactorings do NOT preserve the original semantics. Especially for OO programs, proving a particular refactoring as correct is a complex, if not even infeasible task, e.g. in the presence of virtual method calls. We look at particular refactorings, and suggest to encode the assumptions necessary for their correctness in the form of assertions.

While this does not directly preclude the developer from applying "wrong" refactorings, it makes the necessary assumptions explicit.

A simple example:

  class C                            class C        class X
    X x;            transform into     X x;
     main() {       ==============>    main() {       f() {
       x.m();                            x.f();         m(); n();
       x.n();                          }              }
    }

To ascertain that m() does not change the attribute 'x' of the calling object c (which would mean that the original "x.n()" goes to a different target from "x.m()"), we introduce an additional parameter that is used in the newly introduced method 'f' to assert the intended behaviour:

main() { x.f(this) }
  f(C that) { m(); assert that.x == this; n()
}

This transformation does not prevent the erroneous application of the transformation, but allows to reason about it (using 3rd party systems like the JML tools, or the KeY system), or develop a sufficient number of test cases. This improved refactoring could e.g. be integrated Eclipse's LTK Refactoring for Java programs, and contributed to the Open Source community. Future work could include source code repository mining (e.g. CVS/SVN/... repositories of open source software projects), and finding out if a particular refactoring has been applied, and give an indication as to its correctness.

A prospective student would familiarise himself with refactoring as they are implemented in common IDEs (Eclipse, IntelliJ, NetBeans, MS Visual Studio) and from literature (Design Pattern-book, see below). In a survey, each refactoring/pattern is classified whether it produces an equivalent program with regard to effects commonly found in OO programs, such as so-called aliasing (above), or virtual method calls.

Some of the necessary infrastructure (code for analysis of Java fragments within Eclipse, finding candidates through heuristics etc.) has already been used in an earlier Master's thesis which was deemed Very Good in 2014, see below.

Requirements:

  • interest and experience in object-oriented programming languages
  • maybe a bit of compiler construction :-)

Bibliography:

Utfyllende informasjon

  • A presentation I gave on that topic (without demo):
Emneord: refactoring, programming languages, object-orientation
Publisert 22. sep. 2014 16:25 - Sist endret 13. apr. 2018 10:27

Veileder(e)

Omfang (studiepoeng)

60