Content uploaded by Ralph Johnson
Author content
All content in this area was uploaded by Ralph Johnson on May 22, 2015
Content may be subject to copyright.
A preview of the PDF is not available
Refactoring Object-Oriented Frameworks
Abstract and Figures
This thesis defines a set of program restructuring operations (refactorings) that support the design, evolution and reuse of object-oriented application frameworks. The focus of the thesis is on automating the refactorings in a way that preserves the behavior of a program. The refactorings are defined to be behavior preserving, provided that their preconditions are met. Most of the refactorings are simple to implement and it is almost trivial to show that they are behavior preserving. However, for a few refactorings, one or more of their preconditions are in general undecidable. Fortunately, for some cases it can be determined whether these refactorings can be applied safely. Three of the most complex refactorings are defined in detail: generalizing the inheritance hierarchy, specializing the inheritance hierarchy and using aggregations to model the relationships among classes. These operations are decomposed into more primitive parts, and the power of these operations is discussed from the perspectives of automatability and usefulness in supporting design. Two design constraints needed in refactoring are class invariants and exclusive components. These constraints are needed to ensure that behavior is preserved across some refactorings. This thesis gives some conservative algorithms for determining whether a program satisfies these constraints, and describes how to use this design information to refactor a program.
Figures - uploaded by Ralph Johnson
Author content
All figure content in this area was uploaded by Ralph Johnson
Content may be subject to copyright.
... Refactoring is the process of modifying the structure of a program while preserving its functional behaviour [33]. The term refactoring was first introduced by Opydyke [33] in 1992, and the concept goes back at least to the fold/unfold system proposed by Burstall and Darlington [12] in 1977. ...
... Refactoring is the process of modifying the structure of a program while preserving its functional behaviour [33]. The term refactoring was first introduced by Opydyke [33] in 1992, and the concept goes back at least to the fold/unfold system proposed by Burstall and Darlington [12] in 1977. The main aims of refactoring are to increase code quality, programming productivity, and code reuse, which leads to increased productivity and programmability. ...
Cyber attacks become more and more prevalent every day. An arms race is thus engaged between cyber attacks and cyber defences. One type of cyber attack is known as a side channel attack, where attackers exploit information leakage from the physical execution of a program, e.g. timing or power leakage, to uncover secret information, such as encryption keys or other sensitive data. There have been various attempts at addressing the problem of side-channel attacks, often relying on various measures to decrease the discernibility of several code variants or code paths. Most techniques require a high-degree of expertise by the developer, who often employs ad hoc, hand-crafted code-patching in an attempt to make it more secure. In this paper, we take a different approach: building on the idea of ladderisation, inspired by Montgomery Ladders. We present a semi-automatic tool-supported technique, aimed at the non-specialised developer, which refactors (a class of) C programs into functionally (and even algorithmically) equivalent counterparts with improved security properties. Our approach provides refactorings that transform the source code into its ladderised equivalent, driven by an underlying verified rewrite system, based on dependent types. Our rewrite system automatically finds rewrit-ings of selected C expressions, facilitating the production of their equivalent ladderised counterparts for a subset of C. Using our tool-supported technique, we demonstrate our approach on a number of representative examples from the cryptographic domain, showing increased security. CCS CONCEPTS • Software and its engineering → Semantics; Integrated and visual development environments; • Security and privacy → Intru-sion/anomaly detection and malware mitigation.
... Having pending actions, i.e., those actions that should have been done because the triggers are satisfied, and outdated comments may have impact on program comprehension, and maintenance [28,41]. Additionally, having comments written in an informal way presents a challenge for some software engineering tools, such as refactorings [12,29,30], as those tools may not know how to manipulate code snippets and identifiers embedded in comments [38]. ...
... Program transformations. Actions available in T I are closely related to behavior-preserving transformations, i.e., refactorings [12,29,30,45]. Most relevant work is that on scripting refactorings [21,49,50], i.e., providing simple building blocks that can be composed in sophisticated transformations. ...
Natural language elements, e.g., todo comments, are frequently used to communicate among the developers and to describe tasks that need to be performed (actions) when specific conditions hold in the code repository (triggers). As projects evolve, development processes change, and development teams reorganize, these comments, because of their informal nature, frequently become irrelevant or forgotten. We present the first technique, dubbed TrigIt, to specify triggeraction todo comments as executable statements. Thus, actions are executed automatically when triggers evaluate to true. TrigIt specifications are written in the host language (e.g., Java) and are evaluated as part of the build process. The triggers are specified as query statements over abstract syntax trees and abstract representation of build configuration scripts, and the actions are specified as code transformation steps. We implemented TrigIt for the Java programming language and migrated 20 existing trigger-action comments from 8 popular open-source projects. We evaluate the cost of using TrigIt in terms of the number of tokens in the executable comments and the time overhead introduced in the build process.
... Secure refactoring is similar to traditional refactoring, but secure refactoring warns programmers of the security issues [1] [7]. Therefore, the importance of refactoring is sustaining external behavior. ...
Security is a significant issue in software systems. The initially secure design of a software system could be at risk of a refactoring transformation. Consequently, via a refactoring transformation, the software could be considered vulnerable, and the refactoring process can undergo security-aware refactoring. This work deals with three security approaches to assist programmers in refactoring their software systems while simultaneously sustaining or possibly improving the security of their software system. In addition, this work deals with security-aware refactoring at the design stage rather than refactoring that requires a full source code. The main aim of this work is to provide programmers with knowledge about secure refactoring processes to improve the long-term maintainability of the software system in a secure way while sustaining the external behavior of the system.
... Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure [16,45]. Refactoring is performed for various reasons [16]. ...
Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. Not only researchers, but also practitioners, need to know about past refactoring instances performed in a software development project. So far, a number of techniques have been proposed for automatic detection of refactoring instances. Those techniques have been presented in various international conferences and journals, however, it is difficult for researchers and practitioners to grasp the current status of studies on refactoring detection techniques. In this survey paper, we review various refactoring detection techniques, especially techniques based on change history analysis. First, we give the definition and categorization of refactoring detection methods in this paper, and then introduce refactoring detection techniques based on change history analysis. Finally, we discuss possible future research directions for refactoring detection.
Resumo. Motivação: Ferramentas para detecção de anomalias de código podem ser classificadas em interativas e não interativas. Embora a abordagem interativa pareça ser promissora, nenhum conhecimento existe sobre seu impacto na eficácia de detecção de anomalias. Objetivo: Avaliar a eficácia da detecção interativa, observando o impacto da mesma nas atividades de detecção de anomalias de código e refatoração. Método: Serão testadas hipóteses relacionadas à utilização da técnica de detecção interativa a partir de um experimento controlado com 14 programadores. Resultados: Os resultados sugerem que a técnica de detecção interativa pode ser utilizada para apoiar a atividade de detecção de anomalias visto que os programadores tendem a identificar um número alto de ocorrências. Conclusões: Embora a detecção interativa contribua para elevar o número de anomalias encontradas, o uso dessa técnica pode elevar o número de falsos positivos. Consequentemente, tal abordagem pode induzir os programadores a realizarem refatorações desnecessárias. Observações das atividades dos participantes também sugerem que a detecção interativa parece ser muito sensível à eficácia do mecanismo subjacente de detecção de anomalias. Abstract. Background: Tools for detection of code anomalies can be classified into interactive and non-interactive. Although the interactive approach seems promising, there is no knowledge about their impact on the effectiveness of code anomalies detection. Goal: Evaluate the effectiveness of interactive detection, observing their impact on code anomalies detection and code refactoring activities. Method: Hypotheses regarding the use of interactive detection approach will be tested from a controlled experiment with 14 programmers. Results: The results suggest that the technique of interactive detection can be used to support the activity of code anomalies detection since programmers tend to identify a high number of occurrences of these anomalies. Conclusions: Although the interactive detection contributes to increase the number of code anomalies found, the use of this technique can increase the number of false positives. Consequently, this approach can induce programmers to perform refactoring unnecessary. Observations of the participants' activities also suggest that interactive detection seems to be very sensitive to the effectiveness of the underlying mechanism of code anomalies detection.
Refactoring is a program transformation that restructures existing code without altering its behaviour and is a key practice in popular software design movements, such as Agile. Identification of potential refactoring opportunities is an important step in the refactoring process. In large systems, manual identification of useful refactoring opportunities requires a lot of effort and time. Hence, there is a need for automatic identification of refactoring opportunities. However, this problem has not been addressed well for many non-trivial refactorings. Two such non-trivial, yet popular refactorings are “Replace Type Code with Subclass” (SC) and “Replace Type Code with State” (ST) refactorings. In this paper, we present new approaches to identify SC and ST refactoring opportunities.
Our proposed approach is based around the notion of control-fields. A control-field is a field of a class that exposes the different underlying behaviors of the class. Each control-field can lead to a possible SC/ST refactoring of the associated/interacting classes. We first present a formal definition of control-fields and then present algorithms to identify and prune them; each of these pruned control-fields represents a refactoring opportunity. Further, we present a novel flow- and context-sensitive analysis to classify each of these refactoring opportunities into one of the SC and ST opportunities. We have implemented our proposed approach in a tool called Auto-SCST, and demonstrated its effectiveness by evaluating it against eight open-source Java applications.
Dynamic features offered by programming languages provide greater flexibility to the programmer (e.g., dynamic constructions of classes and methods) and reduction of duplicate code snippets. However, the unnecessary use of dynamic features may detract from the code in many ways, such as readability, comprehension, and maintainability of software. Therefore, this paper proposes 20 refactorings that replace dynamic instructions with static ones. In an evaluation on 28 open-source Ruby systems, we could refactor 743 of 1,651 dynamic statements (45%).
Refactoring has become a valuable activity during the software development lifecycle, because it can be induced by different causes, like new requirements or quality improvement. In code-based development contexts this activity has been widely studied, whereas in model-driven ones, where models are first-class development entities, there are many issues yet to be tackled. In this paper we present a metamodel that supports the specification of pre- and post- conditions of model refactoring actions, and the automated derivation and verification of such conditions in specific modeling languages. Our work is aimed at helping users to implement refactoring actions in the adopted modelling language by providing an environment for guaranteeing the feasibility of refactoring actions. Our primary focus is on the definition of applicable sequences of refactoring actions, rather than on the user-driven step-by-step application of refactoring actions. As an example, we illustrate the applicability of our metamodel for UML models refactoring.
Many have sought a software design process that allows a program to be derived systematically from a precise statement of requirements. It is proposed that, although designing a real product in that way will not be successful, it is possible to produce documentation that makes it appear that the software was designed by such a process. The ideal process and the documentation that it requires are described. The authors explain why one should attempt to design according to the ideal process and why one should produce the documentation that would have been produced by that process. The contents of each of the required documents are outlined.
This paper discusses the organization of software that is inherently complex because of very many arbitrary details that must be precisely right for the software to be correct. We show how the software design technique known as information hiding, or abstraction, can be supplemented by a hierarchically structured document, which we call a module guide. The guide is intended to allow both designers and maintainers to identify easily the parts of the software that they must understand, without reading irrelevant details about other parts of the software. The paper includes an extract from a software module guide to illustrate our proposals.
The Source Code Control System (SCCS) is a software tool designed to help programming projects control changes to source code. It provides facilities for storing, updating, and retrieving all versions of modules, for controlling updating privileges for identifying load modules by version number, and for recording who made each software change, when and where it was made, and why. This paper discusses the SCCS approach to source code control, shows how it is used and explains how it is implemented.
