Roberts, D., Brant, J., Johnson, R.: A refactoring tool for smalltalk. In: Theory and Practice of Object Systems. Volume 3. (1997) 253 -- 263  Home/Search   Document Not in Database   Summary   Related Articles   Check

....evolution at a high level, we propose to use refactoring transformations [16] that automate many common design transitions and reduce the likelihood of errors. While such transformations have been shown to support the introduction of design pattern instances in object oriented applications [17, 19], we are not aware of their usage to support the evolution of design pattern instances. Providing such support in an intuitive and seamless way will be the main contribution of this paper. To this extent, we will use the technique of declarative metaprogramming. 2. Declarative metaprogramming ....

....as extractSuperclass) to the software, the predicate transform is needed. The implementation of transform looks as follows: transform( Transformation) checkPrecondition( Transformation) call( T ransformation) These high level software transformations are similar to the idea of refactorings [16, 17], except that we do not require our transformations to be behaviour preserving. This is because we want to be able to express any kind of evolution of the software, even if this evolution does not preserve the original behaviour or structure. Nevertheless, we have borrowed the idea of ....

[Article contains additional citation context not shown here]

D. Roberts, J. Brant, and R. Johnson. A refactoring tool for smalltalk. Journal of Theory and Practice of Object Systems 3(4), pages 253--263, 1997.

....large and complicated software. To perform maintenance tasks, developers must first accurately identify defects in the software design. Systems [5, 25, 26, 33, 43] exist to visualize software using high level representations to help the identification. Then, developers may use refactoring [13, 22, 35] to eliminate defects and to improve the overall software quality. Refactoring decreases the cost of maintenance and facilitates modification in response to changing requirements. However, there is a general lack of tools for automating the task of identifying design defects. # This work is ....

....because of the multiple points of view available. In the presented classification, we do not intend to give an exhaustive view on design defects but to o#er a common framework to be discussed, enriched, and evolved. 2. 1: The basis We establish the current classification from the literature [1, 5, 9, 10, 12, 13, 16, 19, 20, 21, 22, 27, 29, 35, 38, 39, 40, 41, 42], based on the scope of the design defects inside an object oriented applications. It distinguishes among design defects involving the internal structure of a class, design defects involving interactions among classes, and design defects relating to the application semantics. We retain these three ....

D. Roberts, J. Brant, and R. Johnson. A refactoring tool for Smalltalk, 1999.

....into class collaborations, because redistribution of functionality reveals how classes interact with each other. In object oriented development, changes are accomplished by means of so called refactorings [Opdy92b] Fowl99a] Refactoring operations such as provided by the Refactoring Browser [Robe97a] reorganise a class hierarchy by shifting responsibilities between classes, and redistributing instance variables and methods. Thus, to reverse engineer object oriented software, we must identify which refactorings have been applied and this will help us understanding how and to a certain ....

....loaded in Microsoft Access and Microsoft Excel for post processing. We validate the applicability of the heuristics via an experiment involving three case studies: the VisualWorks framework ( Haun95a] Howa95a] the HotDraw framework ( Beck94a] John92a] and finally the Refactoring Browser ([Robe97a]) These case studies have been selected because they satisfy the following criteria. Accessible. The source code for the different versions of these frameworks are publicly accessible, thus other researchers can reproduce or falsify our results. Representative. Each of the three case ....

[Article contains additional citation context not shown here]

Don Roberts, John Brant and Ralph E. Johnson, "A Refactoring Tool for Smalltalk," Journal of Theory and Practice of Object Systems (TAPOS), vol. 3, no. 4, 1997, pp. 253-263.

....into class collaborations, because redistribution of functionality reveals how classes interact with each other. In object oriented development, changes are accomplished by means of so called refactorings [Opdy92b] Fowl99a] Refactoring operations such as provided by the Refactoring Browser [Robe97a] reorganise a class hierarchy by shifting responsibilities between classes, and redistributing instance variables and methods. Thus, to reverse engineer object oriented software, we must identify which refactorings have been applied and this will help us understand how and to a certain ....

....loaded in Microsoft Access and Microsoft Excel for post processing. We validate the applicability of the heuristics via an experiment involving three case studies: the VisualWorks framework ( Haun95a] Howa95a] the HotDraw framework ( Beck94a] John92a] and finally the Refactoring Browser ([Robe97a]) These case studies have been selected because they satisfy the following criteria. Accessible. The source code for the different versions of these frameworks are publicly accessible, thus other researchers can reproduce or falsify our results. Representative. Each of the three case ....

[Article contains additional citation context not shown here]

Don Roberts, John Brant and Ralph E. Johnson, "A Refactoring Tool for Smalltalk," Journal of Theory and Practice of Object Systems (TAPOS), Vol. 3(4), 1997.

....the whole reverse engineering team should be able to gain back that time by applying the tool in their daily working practices. The paper starts with an overview of the hybrid reverse engineering approach (Section 2) Afterwards, we report on a case study (i.e. the SMALLTALK Refactoring Browser [29]) which illustrates the feasibility of the approach for program understanding and problem detection (Section 3) Next, we briefly present CodeCrawler, which is the platform we have developed to experiment with various combinations of metrics and program visualisations (Section 4) Then we discuss ....

....potential problems (Section 3.2) Finally, to counter the potential critique that one case study is little evidence for supporting the claim, we say a few words on some other experiments with industrial systems. The particular software system used in our experiment is the Refactoring Browser [29] which is well known throughout the SMALLTALK community. To give an idea about the size of the system: the Refactoring Browser consists of 166 classes (not counting the meta classes) 2365 methods, 365 instance variables, 2198 instance variable accesses and 9780 method invocations. Reporting ....

D. Roberts, J. Brant, and R. E. Johnson. A refactoring tool for smalltalk. Journal of Theory and Practice of Object Systems (TAPOS), 3(4):253 -- 263, 1997.

....external behaviour [5] Especially when automated by a tool, refactoring is an easy, quick and safe way to improve software systems at the code level. Recently, refactoring has been gaining widespread acceptance, as for example illustrated by the increasing popularity of the Refactoring Browser [7] (an almost ubiquitous Smalltalk tool) the growing success of Fowler s refactoring catalogue [5] and the explicit integration of refactoring into a software development method (namely Extreme Programming [9] Due to this growing demand, one may safely assume that refactoring tools will soon ....

....the first solution, although it works, produces unclear (a same name conveys similar behaviour and a relation between the methods, which in this case does not need to be true at all) and therefore low quality code. The second option is very hard to check in practice. The Refactoring Browser [7] detects a few cases by checking if two syntax trees are equal with possibly different parameter and local variable names. Additionally to the above arguments the stricter approach is easier to check and to abstract from the specific languages. Roberts [10] includes an extensive discussion about ....

[Article contains additional citation context not shown here]

D. Roberts, J. Brant and R. E. Johnson, "A Refactoring Tool for Smalltalk," Theory and Practice of Object Systems (TAPOS) , vol. 3, no. 4, 1997, pp. 253-263.

....the vocabulary used inside the software system is essential to understand it and communicate about it with other developers. This pattern helps to acquire such a vocabulary. Known Uses While writing this pattern, one of our team members applied it to reverse engineer the Refactoring Browser [RBJ97] The person was not familiar with Smalltalk, yet was able to identify code smells such as Large Constructs and Duplicated Code . Even without Smalltalk experience it was possible to get a feel for the system structure by a mere inspection of class interfaces. Also, a special hierarchy browser ....

D. Roberts, J. Brant, and R. E. Johnson. A refactoring tool for smalltalk. Journal of Theory and Practice of Object Systems (TAPOS), 3(4):253--263, 1997.

....a method and patching all places where it is invoked. The idea is to combine several low level refactorings to improve the design of a class hierarchy, thus refactorings fit our definition of a round trip engineering. See the Ph.D. work of Opdyke for the early definitions of refactoring [12] and [16] for a description of a fullfledged refactoring tool. Refactorings are applicable in practice, as is illustrated by [4] Data Model Requirements. A refactoring tool is an example of a tool that modifies the source code, thus should know about the exact source code location of data model entities. ....

Don Roberts, John Brant, and Ralph E. Johnson. A refactoring tool for smalltalk. Journal of Theory and Practice of Object Systems (TAPOS), 3(4):253--263, 1997.

....been developed in a rush and which has yet to undergo its first redesign. We did this to see if the results of our experiments would differ and in what way they would do that. 6.3. 1 Refactoring Browser The Refactoring Browser is a widely used tool for the implementation of Smalltalk programs [ROBE 97] We took it as a case study because it is an application which has gone through several refactorings and redesigns and has been written by some very experienced programmers. This quality of implementation should thus be visible in such a system. It is a medium sized application as we can see in ....

D. Roberts, J. Brant, and R. E. Johnson. A Refactoring Tool for Smalltalk. Journal of Theory and Practice of Object Systems (TAPOS), vol. 3, no. 4, pages 253--263, 1997. (p 35)

....and patching all places where it is invoked. The idea is to combine several low level refactorings to improve the design of a class hierarchy, thus refactorings fit our definition of a round trip engineering. See the Ph.D. work of Opdyke for the early definitions of refactoring [Opdy92b] and [Robe97a] for a description of a Why FAMIX and not UML 6 19 full fledged refactoring tool. Refactorings are applicable in practice, as is illustrated by [Fowl99a] Data Model Requirements. A refactoring tool is an example of a tool that modifies the source code, thus should know about the exact ....

Don Roberts, John Brant and Ralph E. Johnson, "A Refactoring Tool for Smalltalk," Journal of Theory and Practice of Object Systems (TAPOS), vol. 3, no. 4, 1997, pp. 253-263. Why FAMIX and not UML ? 16 / 19

....software maintenance, bloating up source code and complicating the extermination of errors. Tool support exists that helps to identify the duplicated code [JP93, Bak92, BYM 98, DRD99] Refactorings are a way to transform an application [OJ92] in a behavior preserving manner. Refactoring tools [RBJ97] support the elementary operations to transform code. Duplication is one important aspect of code where refactorings can be used to improve the source code. Very few tools, however, support corrections of systems plagued by duplicated code. In [Bak97, BYM 98] macro extraction from source ....

Don Roberts, John Brant, and Ralph E. Johnson. A refactoring tool for smalltalk. Journal of Theory and Practice of Object Systems (TAPOS), 3(4):253--263, 1997.

....or simply wrong. Example . Here will follow a running example ( same example throughout the whole reverse engineering patterns) 11. Read all the Code in One Hour Known Uses While writing this pattern, one of our team members applied it to reverse engineer the Refactoring Browser [Robe97a]. The person was not familiar with Smalltalk, yet was able to identify code smells such as Large Constructs and Duplicated Code . Even without Smalltalk experience it was possible to get a feel for the system structure by a mere inspection of class interfaces. Also, a special hierarchy browser ....

....to normal refactoring it is not required to run regression tests after each change, since your improvements will probably not make it into the actual system. Steps The typical refactorings applied during this iterative restructuring are Rename Attributes, Rename Methods, and Extract Methods ([Robe97a], Fowl99a] It certain cases the decomposition will not compile and then you may need to use Inline Self Sends on certain methods and subsequently apply Extract Methods. Prepare Reengineering 44. Following guidelines will help you to find out where and how to apply small scale refactorings to ....

[Article contains additional citation context not shown here]

Don Roberts, John Brant and Ralph E. Johnson, "A Refactoring Tool for Smalltalk," Journal of Theory and Practice of Object Systems (TAPOS), vol. 3, no. 4, 1997, pp. 253-263.

....practices. To summarize our goal is to identify useful combination of simple graphs enriched with metric information that reengineers can reproduce easily. The paper starts with an overview of the approach (section 4) Afterwards, we report on a case study (i.e. the Smalltalk Refactoring Browser [24]) which illustrates the feasibility of a hybrid reverse engineering tool (section 3) Next, we quickly present CodeCrawler a platform we have developed to experiment with various combinations of metrics and program visualizations we provide, then we discuss the advantages and limitations of our ....

....how our approach helps to gain a fast overview of an application and to focus on the possible problematic parts. 3 A Reverse Engineering Scenario We present a short scenario involving our graphical reverse engineering tool. As case study for our experiment we took the Refactoring Browser [24] which is well known throughout the Smalltalk community. However, please note that we run some other experiments on real industrial case studies implemented with C and SMALLTALK in the context of the Famoos Esprit Project but due to non disclosure agreements we cannot present them here. 3.1 ....

D. Roberts, J. Brant, and R. E. Johnson. A refactoring tool for smalltalk. Journal of Theory and Practice of Object Systems (TAPOS), 3(4):253--263, 1997. 10

....and the design history of the UIUC Choices software system [May89] These transformations were termed refactorings. Implementations of Opdyke s refactorings for C were developed by Tokuda and Batory [Tok95, Tok99] and Schultz [Sch98b] An implementation for Smalltalk was developed by Roberts [Rob97]. Roberts offered Smalltalk specific design criteria for a program transformation tool. One criteria which also applied to C software is that users should be allowed to name new entities introduced through transformations. Opdyke first claimed that a series of refactorings could be used to ....

....patterns [Tok95] and Pree s hot spot meta patterns [Tok99] as target states for software 13 restructuring efforts. Refactorings have been used alter existing designs. Winsen used refactorings (primarily renaming) to make design patterns more explicit [Win96] Tokuda and Batory [Tok95] Roberts [Rob97], and Shultz [Sch98b] added design patterns to evolve an application s design. Fowler proposed a set of manual refactorings for evolving an application s design. An example is introduce null object which replaces checks for a null object pointer with an object which performs the null case ....

[Article contains additional citation context not shown here]

D. Roberts, J. Brant, R. Johnson. A Refactoring Tool for Smalltalk. In Theory and Practice of Object Systems, Vol. 3 Number 4, 1997.

....details to automation. Banerjee and Kim proposed a set of schema evolutions for evolving object oriented database schemas [Ban87] and Opdyke proposed a list of primitive refactorings for object oriented languages [Opd92] Roberts implements many of these refactorings for the Smalltalk language [Rob97]. In addition to previous refactorings, we have 2. The term automated in this paper refers to a refactoring s programmed check for enabling conditions and its execution of all source code changes. The choice of which refactorings to apply is always made by a human. ConcreteSubclass1 ....

....structure to pointer C Refactorings procedure to method structure to class Design Pattern Refactorings add factory method create iterator composite decorator procedure to command singleton Table 1: Object oriented refactorings 1. Ban87] 2. Opd92] 3. Tok95] 4. [Rob97] Base Derived Base iv instance variables iv from Derived iv Figure 3.1: Using pull up variable to move Derived to Base a superclass. Banerjee and Kim describe 19 object oriented database schema transformations of which we implement 12 as automated refactorings 3 : Three other ....

[Article contains additional citation context not shown here]

D. Roberts, J. Brant, R. Johnson. A Refactoring Tool for Smalltalk. In Theory and Practice of Object Systems, Vol. 3 Number 4, 1997.

No context found.

Roberts, D., Brant, J., Johnson, R.: A refactoring tool for smalltalk. In: Theory and Practice of Object Systems. Volume 3. (1997) 253 -- 263

No context found.

D. Roberts, J. Brant, R. Johnson, "A Refactoring Tool for Smalltalk," J. Theory and Practice of Object Systems, Vol. 3, No. 4, 1997, pp. 253-263.

No context found.

D. Roberts, J. Brant, and R. Johnson, "A refactoring tool for Smalltalk," Theory and Practice of Object Systems, vol. 3, no. 4, pp. 253--263, 1997.

No context found.

D. Roberts, J. Brant, and R.E. Johnson, "A Refactoring Tool for Smalltalk," Theory and Practice of Object Systems (TAPOS), vol. 3, no. 4, pp. 253-263, 1997.

No context found.

D. Roberts, J. Brant, and R.E. Johnson, "A Refactoring Tool for Smalltalk," Theory and Practice of Object Systems, vol. 3, no. 4, pp. 3942, 1997.

No context found.

D. Roberts, J. Brant, and R. E. Johnson, "A refactoring tool for Smalltalk," Theory and Practice of Object Systems (TAPOS), vol. 3, no. 4, pp. 253--263, 1997.

No context found.

D. Roberts, J. Brant, and R. Johnson, "A refactoring tool for Smalltalk," Theory and Practice of Object Systems, vol. 3, no. 4, pp. 253--263, 1997.

No context found.

D. Roberts, J. Brant and R. Johnson, "A Refactoring Tool for Smalltalk", TAPOS, vol. 3, no. 4, 1997, pp. 253-263, http://st-www.cs.uiuc.edu/~droberts/tapos/TAPOS.htm

No context found.

D. Roberts, J. Brant and R. Johnson, "A Refactoring Tool for Smalltalk", TAPOS, vol. 3, no. 4, 1997, pp. 253-263, http://st-www.cs.uiuc.edu/~droberts/tapos/TAPOS.htm

No context found.

D. Roberts, J. Brant, and R. Johnson, "A refactoring tool for Smalltalk," Theory and Practice of Object Systems, vol. 3, no. 4, pp. 253--263, 1997.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC