Refactorings without names

Steimann, Friedrich; Pilgrim, Jens von

doi:10.1145/2351676.2351726

Cited by 15 publications

(11 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…We adopt a recently proposed interface [32] where to achieve a refactoring, a programmer simply performs some of the desired changes by hand, yielding an initial and modified program. Given these two programs, our tool employs a novel synthesis engine that automatically searches for a suitable sequence of refactorings that performs (at least) those changes.…”

Section: Overviewmentioning

confidence: 99%

“…For instance, previous work [25,32] has discussed swapping two names, e.g., transforming field declarations String s1; String s2; to String s2; String s1;, changing uses of s1 and s2 appropriately. One cannot apply the RENAME refactoring to first change s1 to s2 or viceversa, since a name conflict arises.…”

Section: Overviewmentioning

confidence: 99%

“…To address this, we propose to combine a user interface in the style of Steimann et al's ad hoc refactorings [32] with a novel synthesis engine based on synthesis from examples [9]. As a result, a developer performs an automated refactoring using the following process:…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Refactoring with synthesis

Raychev

Schäfer

Sridharan

et al. 2013

Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages &Amp; Application

View full text Add to dashboard Cite

Refactoring has become an integral part of modern software development, with wide support in popular integrated development environments (IDEs). Modern IDEs provide a fixed set of supported refactorings, listed in a refactoring menu. But with IDEs supporting more and more refactorings, it is becoming increasingly difficult for programmers to discover and memorize all their names and meanings. Also, since the set of refactorings is hard-coded, if a programmer wants to achieve a slightly different code transformation, she has to either apply a (possibly non-obvious) sequence of several built-in refactorings, or just perform the transformation by hand.We propose a novel synthesis system which addresses these limitations. Our system employs a recently proposed refactoring interface, in which a refactoring is achieved via three simple steps: the programmer first indicates the start of a code refactoring phase; then she performs some of the desired code changes manually; and finally, she asks the tool to complete the refactoring.Given the initial and modified programs, our synthesis system completes the refactoring by first extracting the difference between the starting program and the modified version, and then synthesizing a sequence of refactorings that achieves (at least) the desired changes. To enable scalable synthesis, we introduce local refactorings, which allow for first discovering a refactoring sequence on small program fragments and then extrapolating it to a full refactoring sequence.We implemented our approach as an Eclipse plug-in, with an architecture that is easily extendable with new refactorings. The experimental results are encouraging: with only minimal user input, the synthesizer was able to quickly discover complex refactoring sequences for several challenging realistic examples.

show abstract

Section: Overviewmentioning

confidence: 99%

Section: Overviewmentioning

confidence: 99%

See 1 more Smart Citation

Refactoring with synthesis

Raychev

Schäfer

Sridharan

et al. 2013

Proceedings of the 2013 ACM SIGPLAN International Conference on Object Oriented Programming Systems Languages &Amp; Application

View full text Add to dashboard Cite

show abstract

“…Due to space limitations, we only give a very brief recap of constraint-based refactoring; for more detailed accounts on it, we refer the reader to [10,11,13,14,18].…”

Section: Constraint-based Refactoringmentioning

confidence: 99%

Model/code co-refactoring: An MDE approach

Pilgrim

Ulke

Thies

et al. 2013

2013 28th IEEE/ACM International Conference on Automated Software Engineering (ASE)

Self Cite

View full text Add to dashboard Cite

Model-driven engineering suggests that models are the primary artefacts of software development. This means that models may be refactored even after code has been generated from them, in which case the code must be changed to reflect the refactoring. However, as we show neither re-generating the code from the refactored model nor applying an equivalent refactoring to the generated code is sufficient to keep model and code in sync -rather, model and code need to be refactored jointly. To enable this, we investigate the technical requirements of model/code corefactoring, and implement a model-driven solution that we evaluate using a set of open-source programs and their structural models. Results suggest that our approach is feasible.

show abstract

“…As has been pointed out in[22], the difference between the kind of a refactoring and its particular application dissolves when ad hoc refactorings, that is, refactorings which have not been standardized and which can perform arbitrary changes, are considered 7. In theory, the constraints can be generated from the constraint rules and the program to be refactored alone.…”

mentioning

confidence: 99%

From well-formedness to meaning preservation: model refactoring for almost free

Steimann

2013

Softw Syst Model

Self Cite

View full text Add to dashboard Cite

Modelling languages such as the UML specify well-formedness as constraints on models. For the refactoring of a model to be correct, it must take these constraints into account and check that they are still satisfied after the refactoring has been performed-if not, execution of the refactoring must be refused. By replacing constraint checking with constraint solving, we show how the role of constraints can be lifted from permitting or denying a tentative refactoring to computing additional model changes required for the refactoring to be executable. Thus, to the degree that the semantics of a modelling language is specified using constraints, refactorings based on these constraints are guaranteed to be meaning preserving. To be able to exploit constraints available in the form of a language's well-formedness rules for refactoring, we present a mapping from these rules to the constraint rules required by constraint-based refactoring. Where there are no gaps between well-formedness and (static) semantics of a modelling language, these mappings enable structural refactorings of models at no extra cost; where there are, we identify ways of detecting and filling the gaps.

show abstract

Refactorings without names

Cited by 15 publications

References 3 publications

Refactoring with synthesis

Refactoring with synthesis

Model/code co-refactoring: An MDE approach

From well-formedness to meaning preservation: model refactoring for almost free

Contact Info

Product

Resources

About