Results 1 - 10
of
28
Finding Refactorings via Change Metrics
- IN PROCEEDINGS OF OOPSLA ’2000 (INTERNATIONAL CONFERENCE ON OBJECT-ORIENTED PROGRAMMING SYSTEMS, LANGUAGES AND APPLICATIONS
, 1999
"... ..."
Automatic Inheritance Hierarchy Restructuring and Method Refactoring
- In Proc. of the eleventh annual conference on Object-oriented programming systems, languages, and applications
, 1996
"... Most object-oriented programs have imperfectly designed inheritance hierarchies and imperfectly factored methods, and these imperfections tend to increase with maintenance. Hence, even objectoriented programs are more expensive to maintain, harder to understand and larger than necessary. Automatic r ..."
Abstract
-
Cited by 67 (0 self)
- Add to MetaCart
Most object-oriented programs have imperfectly designed inheritance hierarchies and imperfectly factored methods, and these imperfections tend to increase with maintenance. Hence, even objectoriented programs are more expensive to maintain, harder to understand and larger than necessary. Automatic restructuring of inheritance hierarchies and refactoring of methods can improve the design of inheritance hierarchies, and the factoring of methods. This results in programs being smaller, having better code re-use and being more consistent. This paper describes Guru, a prototype tool for automatic inheritance hierarchy restructuring and method refactoring of Self programs. Results from realistic applications of the tool are presented. 1 Introduction Factoring shared methods into classes and shared code into methods allows systems to be compact and improves consistency, making them more easily understood and less expensive to maintain. Manually designing inheritance hierarchies and methods ...
Component-Oriented Software Technology
, 1995
"... Modernsoft aresystE0 are increasingly requiredt be open and dist ibut81 Suchsyst08 are opennot only int erms ofnet orkconnectR06 andint0 operabilit support forhet1 ogeneous hardware andsoft are plat orms,but above all, int2 ms of evolving and changingrequirement . Alt169, object,7 ient3 t331,7E8 off ..."
Abstract
-
Cited by 50 (9 self)
- Add to MetaCart
Modernsoft aresystE0 are increasingly requiredt be open and dist ibut81 Suchsyst08 are opennot only int erms ofnet orkconnectR06 andint0 operabilit support forhet1 ogeneous hardware andsoft are plat orms,but above all, int2 ms of evolving and changingrequirement . Alt169, object,7 ient3 t331,7E8 offers some relief,t o a largeext27 t he languages,met2R8 andtd,2 fail t addresstd needs of opensystE3 becausetc y donot escape from tadit192, models of soft are development tpm assume syst, requirement t be closed and st ble.We argue te, open systE8 requirement can only beadequat7E addressed byadopt9, a component,t ient0 as opposedt a purelyobject3E ient2 soft are development approach, byshift7, emphasis away from programming and t wards generalizedsoft arecomposit739 1.1 IntrotrWk5k There has been ac8P8("NP( trend in the development of softwareapplic("NP( away from crom"5 proprietary systems towardsso-c)55( open systems. This trendce be largely attributed to the rapid advancE inc")PPFE hardware tec)F5E"N that have vastlyincy"H5F the cAAF("N)5jjF power available to end-userapplic"P(HHj With new possibilitiescos new needs: in order to survive,c"))AAF" ve businesses must be able to effec) vely exploit newtecP"N)P( as itbecj() available, so existingapplicP)Pjj must be able to work with new, independently developed systems. Wec) see, then, that open systems must be "open" in at least three important ways [49]: 1. Topology: openapplic)E"NE run onc)jEH("NEj networks. 2. PlatF'"A the hardware and software platforms are heterogeneous. 3. EvolutAD' requirements are unstable andc"P(AA)"N ccP(A *In ObjectADL/F/"t Softct CompositL/ , O. Nierstrasz and D. Tsic5A"NE) (Ed.),Prentic Hall, 1995, pp. 3-28. For more information, please see:http://iamw3(0(0(0(0(w157(158(159 4 Componen...
A Meta-model for Language-Independent Refactoring
, 2000
"... Refactoring ---transforming code while preserving behaviour --- is currently considered a key approach for improving object-oriented software systems. Unfortunately, all of the current refactoring tools depend on language-dependent refactoring engines, which prevents a smooth integration with mainst ..."
Abstract
-
Cited by 41 (14 self)
- Add to MetaCart
Refactoring ---transforming code while preserving behaviour --- is currently considered a key approach for improving object-oriented software systems. Unfortunately, all of the current refactoring tools depend on language-dependent refactoring engines, which prevents a smooth integration with mainstream development environments. In this paper we investigate the similarities between refactorings for Smalltalk and Java, derive a language-independent meta-model and show that it is feasible to build a languageindependent refactoring engine on top of this meta-model. Our feasibility study is validated by means of a tool prototype which uses the same engine to refactor both Smalltalk and Java code. Using our approach we minimize the language -dependent part of refactoring tools, providing a standard way for programmers and tools to perform refactorings no matter what language they work in. 1. Introduction Refactoring is defined as "changing a system to improve its internal structure withou...
Modeling Object-Oriented Software for Reverse Engineering and Refactoring
, 2001
"... The increased popularity of the object-oriented paradigm has also increased the interest in object-oriented reengineering. First of all, object-oriented software systems suffer from similar maintainability problems as traditional procedural systems, displaying the need for reengineering techniques t ..."
Abstract
-
Cited by 36 (1 self)
- Add to MetaCart
The increased popularity of the object-oriented paradigm has also increased the interest in object-oriented reengineering. First of all, object-oriented software systems suffer from similar maintainability problems as traditional procedural systems, displaying the need for reengineering techniques tailored to deal with ob- ject-oriented code. Secondly, the increased importance of iterative development processes make reengi- neering techniques valuable in forward engineering, and thus for all paradigms that software is developed in.
Reengineering requires tool support to deal with the large amounts of information and the wide variety of tasks to be performed. An important consideration in building tool environments for reengineering is what information must be provided and how this information is modelled. Design choices have a consider- able impact not only on the ability to support reengineering tasks, but also on issues such as scalability and tool interoperability. Several metamodels exist that model software for the purposes of reengineering. How- ever, they generally lack a discussion of the relevance of information for reengineering and the trade-offs of modeling alternatives.
This thesis presents FAMIX, a language-independent metamodel for modelling object-oriented soft- ware for reengineering purposes. We discuss the exact contents of the metamodel, including its relevance for reengineering and how the metamodel supports the different object-oriented languages through its lan- guage-independent core. We also discuss the infrastructural design decisions of FAMIX by placing it into a design space for infrastructural aspects of reengineering repositories and metamodels. The design space presents multiple interdependent aspects, their design alternatives and how these impact issues such as scal- ability, extensibility and information exchange.
We validate the ability of FAMIX to support reengineering on a language-independent level in two ways. First, we present Moose, a reengineering tool environment with a repository based on FAMIX. Moose serves as a foundation for multiple reengineering tools and has been applied to reverse engineer several large industrial case studies. Secondly, we define a set of fifteen low-level refactorings in terms of the infor- mation available in FAMIX. Refactoring requires sufficient, complete and 100% correct information as well as a clear interpretation of the supported languages in the language-independent core of the metamod- el, in order to correctly perform transformations on the language-specific code level. As such the refactor- ings provide an in-depth validation of the language independence of FAMIX.
Object-Oriented Software Evolution
- IEEE Transactions on Software Engineering
, 1993
"... We review propagation patterns for describing object-oriented software at a higher level of abstraction than the one used by today's programming languages. A propagation pattern defines a family of programs from which we can select a member by giving a class dictionary graph which details the stru ..."
Abstract
-
Cited by 35 (17 self)
- Add to MetaCart
We review propagation patterns for describing object-oriented software at a higher level of abstraction than the one used by today's programming languages. A propagation pattern defines a family of programs from which we can select a member by giving a class dictionary graph which details the structure of behavior through part-of and inheritance relationships between classes. The paper introduces three concepts: evolution histories, growth-plans and a propagation directive calculus. Evolution histories describe a sequence of development phases of an object-oriented program, each phase being executable and therefore testable. To keep the programs flexible and short, we describe them in terms of propagation patterns. Each phase of an evolution history is tested in small steps which are constrained by class dictionary graphs belonging to a growth-plan. Propagation directives are useful both for describing propagation patterns and growth-plans and therefore we endow propagation di...
On Automatic Class Insertion with Overloading
, 1996
"... Several algorithms [Cas92, MS89, Run92, DDHL94a, DDHL95, GMM95] have been proposed to automatically insert a class into an inheritance hierarchy. But actual hierarchies all include overriden and overloaded properties that these algorithms handle either very partially or not at all. Partially handled ..."
Abstract
-
Cited by 26 (10 self)
- Add to MetaCart
Several algorithms [Cas92, MS89, Run92, DDHL94a, DDHL95, GMM95] have been proposed to automatically insert a class into an inheritance hierarchy. But actual hierarchies all include overriden and overloaded properties that these algorithms handle either very partially or not at all. Partially handled means handled provided there is a separate given function f able to compare overloaded properties [DDHL95, GMM95]. In this paper, we describe a new version of our algorithm (named Ares) which handles automatic class insertion more efficiently using such a function f . Although impossible to fully define, this function can be computed for a number of well defined cases of overloading and overriding. We give a classification of such cases and describe the computation process for a well-defined set of nontrivial cases. The algorithm preserves these important properties: - preservation of the maximal factorization of properties - preservation of the underlying structure (Galois lattice) of t...
Design Guidelines for Tailorable Frameworks
- Communications of the ACM
, 1997
"... Factory [3] Figure 7 hypermediacontext object, representing the system conf7 f-135 resolver path hypermedia context activate(anchor) determineResolver(anchor) resolveToDocument(anchor) createDocument(docSpec) resolveToDocSpec(anchor) targetDocument activated() anchor edit() resolveToAn ..."
Abstract
-
Cited by 24 (3 self)
- Add to MetaCart
Factory [3] Figure 7 hypermediacontext object, representing the system conf7 f-135 resolver path hypermedia context activate(anchor) determineResolver(anchor) resolveToDocument(anchor) createDocument(docSpec) resolveToDocSpec(anchor) targetDocument activated() anchor edit() resolveToAnchor(anchor) createAnchor(anchSpec) resolveToAnchorSpec(anchor) targetAnchor select() 7. Design Guidelinesfo Tailoines Framewoes This single hypermedia context object provides the framework hot spot in which an OO programmer can tailor the system configuration without altering the rest of the system. Thus, the third guideline addresses the extensibility requirement. Conclusion The ro osed design guidelines cover only some of the state of the art in framework design. But because of the way they are formulated, they fit nicely with the other techniques available today ---i.e., design atterns, o en im lementations, class refactoring---making them es ecially attractive. The fact that t...
Semi-automatic Update of Applications in Response to Library Changes
, 1996
"... Software libraries provide leverage in large part because they are used by many applications. As Parnas, Lampson and others have noted, stable interfaces to libraries isolate the application from changes in the libraries. That is, as long as there is no change in a library's syntax or semantics, app ..."
Abstract
-
Cited by 21 (0 self)
- Add to MetaCart
Software libraries provide leverage in large part because they are used by many applications. As Parnas, Lampson and others have noted, stable interfaces to libraries isolate the application from changes in the libraries. That is, as long as there is no change in a library's syntax or semantics, applications can use updated libraries simply by importing and linking the new version. However, libraries are indeed changed from time to time and the tedious work of adapting the application source to the library interface changes becomes a burden to multitudes of programmers. This paper introduces an approach and a toolset intended to reduce these costs. Specifically, in our approach a library maintainer annotates changed functions with rules that are used to generate tools that will update the applications that use the updated libraries. Thus, in exchange for a small added amount of work by the library maintainers, costs to each application maintainer can be reduced. We present the basic ap...
Classes vs. Prototypes - Some Philosophical and Historical Observations
- Journal of Object-Oriented Programming
, 1996
"... In this paper we take a rather unusual, non-technical approach and investigate object-oriented programming and the prototype-based programming field from a purely philosophical viewpoint. Some historical facts and observations pertaining to objects and prototypes are presented, and conclusions based ..."
Abstract
-
Cited by 16 (0 self)
- Add to MetaCart
In this paper we take a rather unusual, non-technical approach and investigate object-oriented programming and the prototype-based programming field from a purely philosophical viewpoint. Some historical facts and observations pertaining to objects and prototypes are presented, and conclusions based on those observations are derived.

